[opensuse-packaging] Packagers breaking repositories ...
So it seems that right now someone is in the process of doing some upgrade work in KDE:Qt. Whoever it is has turned publishing off, which usually is a good idea... ...but in this case it leads to hundreds of packages in KDE:Framework, KDE:Extras, and KDE:Applications being rebuilt, and being published, and because publishing of KDE:Qt is turned off, being unable to be installed due to missing dependencies. The really bad part is, that *some* packages from those newly built ones *will* be installed, and some others will be downgraded to what's in the base distribution, leaving people with a general mish mash of librariy versions and potentially seriously broken desktops. So ... can someone **please** turn publishing in KDE:Qt back on? And for next time: whoever disables publishing in KDE:Qt for upgrading it, disable publishing (and building) in KDE:Frameworks5, KDE:Applications, and KDE:Extra. Thank you. *le sigh* Mathias -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 17/03/2019 02:02, Mathias Homann wrote:
So it seems that right now someone is in the process of doing some upgrade work in KDE:Qt. Whoever it is has turned publishing off, which usually is a good idea...
...but in this case it leads to hundreds of packages in KDE:Framework, KDE:Extras, and KDE:Applications being rebuilt, and being published, and because publishing of KDE:Qt is turned off, being unable to be installed due to missing dependencies. The really bad part is, that *some* packages from those newly built ones *will* be installed, and some others will be downgraded to what's in the base distribution, leaving people with a general mish mash of librariy versions and potentially seriously broken desktops.
So ... can someone **please** turn publishing in KDE:Qt back on?
And for next time: whoever disables publishing in KDE:Qt for upgrading it, disable publishing (and building) in KDE:Frameworks5, KDE:Applications, and KDE:Extra.
On the other hand this is why as a project we encourage people to use tumbleweed and not development repositories because we don't guarantee that the later will always be in a working state. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Dienstag, 19. März 2019, 02:15:48 CET schrieb Simon Lees:
On 17/03/2019 02:02, Mathias Homann wrote:
So it seems that right now someone is in the process of doing some upgrade work in KDE:Qt. Whoever it is has turned publishing off, which usually is a good idea...
...but in this case it leads to hundreds of packages in KDE:Framework, KDE:Extras, and KDE:Applications being rebuilt, and being published, and because publishing of KDE:Qt is turned off, being unable to be installed due to missing dependencies. The really bad part is, that *some* packages from those newly built ones *will* be installed, and some others will be downgraded to what's in the base distribution, leaving people with a general mish mash of librariy versions and potentially seriously broken desktops.
So ... can someone **please** turn publishing in KDE:Qt back on?
And for next time: whoever disables publishing in KDE:Qt for upgrading it, disable publishing (and building) in KDE:Frameworks5, KDE:Applications, and KDE:Extra.
On the other hand this is why as a project we encourage people to use tumbleweed and not development repositories because we don't guarantee that the later will always be in a working state.
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed. - nvidia and tumbleweed kernels - huge numbers of weird dependencies all of a sudden to name the last two that would have rendered both my computers dead in the water for me. Personally I consider TUMBLEWEED to be the "try if this works" development thing. Also: the openSUSE wiki *and* the KDE website both tell people to use the KDE:* repositories to have the latest official releases. Cheers MH -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann@openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, 19 Mar 2019 at 07:11, Mathias Homann <Mathias.Homann@opensuse.org> wrote:
Am Dienstag, 19. März 2019, 02:15:48 CET schrieb Simon Lees:
On 17/03/2019 02:02, Mathias Homann wrote:
So it seems that right now someone is in the process of doing some upgrade work in KDE:Qt. Whoever it is has turned publishing off, which usually is a good idea...
...but in this case it leads to hundreds of packages in KDE:Framework, KDE:Extras, and KDE:Applications being rebuilt, and being published, and because publishing of KDE:Qt is turned off, being unable to be installed due to missing dependencies. The really bad part is, that *some* packages from those newly built ones *will* be installed, and some others will be downgraded to what's in the base distribution, leaving people with a general mish mash of librariy versions and potentially seriously broken desktops.
So ... can someone **please** turn publishing in KDE:Qt back on?
And for next time: whoever disables publishing in KDE:Qt for upgrading it, disable publishing (and building) in KDE:Frameworks5, KDE:Applications, and KDE:Extra.
On the other hand this is why as a project we encourage people to use tumbleweed and not development repositories because we don't guarantee that the later will always be in a working state.
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels - huge numbers of weird dependencies all of a sudden
to name the last two that would have rendered both my computers dead in the water for me.
Personally I consider TUMBLEWEED to be the "try if this works" development thing.
You seem to be suggesting that Tumbleweed is somehow less supported or reliable than fricking devel repositories This is downright...well, the only words I have to describe my feelings on your point of view are not suitable for this mailinglist Devel Projects, such as everything in the KDE: repo, are less tested, less reviewed (including no legal review), and most certainly, without any shadow of a doubt, provided on a "try if it works" basis. There is no formal effort by the openSUSE Project to guarantee anything in any OBS repo outside of those beginning with "openSUSE:" is in an acceptable state. That is why they are referred to on software.opensuse.org as "Experimental packages". No one should have any expectation that something marked as "experimental" will always work, nor always be available. Tumbleweed on the other hand, as an official openSUSE: OBS project, has layers of code review (at least 4 eyes/2 persons), additional legal review, and levels of automated auditing and testing unrivalled by any other rolling release out there. It is always provided on a "it should always work" basis. It is not experimental. It is not the problem of the project or the KDE packagers if you refuse to accept this and instead use their development repositories to install software in a less optimal arrangement than the one they expend a great deal more effort on ensuring in openSUSE Tumbleweed. Sure, there is no problem to inform them when those repositories are not functioning, but your tone, attitude, and expectations are way out of line. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 2019-03-19 09:49, schrieb Richard Brown:
On Tue, 19 Mar 2019 at 07:11, Mathias Homann <Mathias.Homann@opensuse.org> wrote:
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels - huge numbers of weird dependencies all of a sudden
to name the last two that would have rendered both my computers dead in the water for me.
Personally I consider TUMBLEWEED to be the "try if this works" development thing.
You seem to be suggesting that Tumbleweed is somehow less supported or reliable than fricking devel repositories
I didn't say it was less supported. What I said is that I see a lot of "interesting" issues about tumbleweed, especially on the factory list, that make me think that I should not use tumbleweed on my home setup, since I have nvidia hardware and I want to be ableto actually use it. [...]
Devel Projects, such as everything in the KDE: repo, are less tested, less reviewed (including no legal review), and most certainly, without any shadow of a doubt, provided on a "try if it works" basis. There is no formal effort by the openSUSE Project to guarantee anything in any OBS repo outside of those beginning with "openSUSE:" is in an acceptable state. That is why they are referred to on software.opensuse.org as "Experimental packages". No one should have any expectation that something marked as "experimental" will always work, nor always be available.
https://de.opensuse.org/SDB:KDE_Plasma_5 points users towards KDE:Frameworks5, and according to that SDB page the *unstable* plasma is in KDE:Unstable:* To me that means that packagers should not break KDE:Frameworks5. KDE:Applications and KDE:Extras are a different matter, of course.
Tumbleweed on the other hand, as an official openSUSE: OBS project, has layers of code review (at least 4 eyes/2 persons), additional legal review, and levels of automated auditing and testing unrivalled by any other rolling release out there.
While that might be true, there is (at least to my knowledge) no official NVIDIA rpm for Tumbleweed, which is my personal dealbreaker.
It is always provided on a "it should always work" basis. It is not experimental.
It is not the problem of the project or the KDE packagers if you refuse to accept this and instead use their development repositories to install software in a less optimal arrangement than the one they expend a great deal more effort on ensuring in openSUSE Tumbleweed.
Let me point it out again: I am *not* installing from KDE:Unstable:*. I am installing KDE/Plasma from the officially suggested repositories as noted on the SDB page about Plasma5.
Sure, there is no problem to inform them when those repositories are not functioning, but your tone, attitude, and expectations are way out of line.
I'm sorry to hear that you feel that way.
On Tue, 19 Mar 2019 at 10:06, Mathias Homann <Mathias.Homann@opensuse.org> wrote:
https://de.opensuse.org/SDB:KDE_Plasma_5 points users towards KDE:Frameworks5, and according to that SDB page the *unstable* plasma is in KDE:Unstable:*
To me that means that packagers should not break KDE:Frameworks5. KDE:Applications and KDE:Extras are a different matter, of course.
Everything in any devel project (which all of the KDE: projects are) should be considered as Experimental Anything in a devel project which is also called Unstable, should be considered even more Experimental You should not expect anything in a devel Project to always work, period. That does not negate the fact that if people want to mess around building their own distribution by taking experimental stuff on their stable system, they can do so - that is what we have documented on the wiki. But be under no illusion that when you do that, you're building a system that is going to be less tested, less reviewed, and logic dictates, less reliable than Tumbleweed.
Tumbleweed on the other hand, as an official openSUSE: OBS project, has layers of code review (at least 4 eyes/2 persons), additional legal review, and levels of automated auditing and testing unrivalled by any other rolling release out there.
While that might be true, there is (at least to my knowledge) no official NVIDIA rpm for Tumbleweed, which is my personal dealbreaker.
Seriously? https://news.opensuse.org/2017/09/20/new-repository-caters-to-tumbleweeds-nv... https://www.reddit.com/r/openSUSE/comments/6slnlv/tumbleweed_gets_an_officia... https://en.opensuse.org/SDB:NVIDIA_drivers https://download.nvidia.com/opensuse/tumbleweed
It is always provided on a "it should always work" basis. It is not experimental.
It is not the problem of the project or the KDE packagers if you refuse to accept this and instead use their development repositories to install software in a less optimal arrangement than the one they expend a great deal more effort on ensuring in openSUSE Tumbleweed.
Let me point it out again: I am *not* installing from KDE:Unstable:*. I am installing KDE/Plasma from the officially suggested repositories as noted on the SDB page about Plasma5.
Let me point it out again - you're installing less tested, less reviewed, packages from an experimental repository who's primary function is preparing software for use in Tumbleweed. If you always expect it to work on Leap, or any other distribution of your choice, you need the sort of help I cant provide via a mailinglist. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Dienstag, 19. März 2019, 10:12:57 CET schrieb Richard Brown:
On Tue, 19 Mar 2019 at 10:06, Mathias Homann
<Mathias.Homann@opensuse.org> wrote:
https://de.opensuse.org/SDB:KDE_Plasma_5 points users towards KDE:Frameworks5, and according to that SDB page the *unstable* plasma is in KDE:Unstable:*
To me that means that packagers should not break KDE:Frameworks5. KDE:Applications and KDE:Extras are a different matter, of course.
Everything in any devel project (which all of the KDE: projects are) should be considered as Experimental
then the wiki should not point at those repos.
Anything in a devel project which is also called Unstable, should be considered even more Experimental
That's why I'm not using anything from *:Unstable.
You should not expect anything in a devel Project to always work, period. That does not negate the fact that if people want to mess around building their own distribution by taking experimental stuff on their stable system, they can do so - that is what we have documented on the wiki. But be under no illusion that when you do that, you're building a system that is going to be less tested, less reviewed, and logic dictates, less reliable than Tumbleweed.
Fully agree here - but like I already said several times: the SDB article about Plasma clearly advises to use KDE:Frameworks5 which to me means it *should* be stable enough for end users.
Tumbleweed on the other hand, as an official openSUSE: OBS project, has layers of code review (at least 4 eyes/2 persons), additional legal review, and levels of automated auditing and testing unrivalled by any other rolling release out there.
While that might be true, there is (at least to my knowledge) no official NVIDIA rpm for Tumbleweed, which is my personal dealbreaker.
Seriously?
https://news.opensuse.org/2017/09/20/new-repository-caters-to-tumbleweeds-nv idia-users/ https://www.reddit.com/r/openSUSE/comments/6slnlv/tumbleweed_gets_an_offici al_rpm_from_nvidia/ https://en.opensuse.org/SDB:NVIDIA_drivers https://download.nvidia.com/opensuse/tumbleweed
ok you got me there. I seriously did not know that. I'll give TW a serious try next time I reinstall a box here.
It is always provided on a "it should always work" basis. It is not experimental.
It is not the problem of the project or the KDE packagers if you refuse to accept this and instead use their development repositories to install software in a less optimal arrangement than the one they expend a great deal more effort on ensuring in openSUSE Tumbleweed.
Let me point it out again: I am *not* installing from KDE:Unstable:*. I am installing KDE/Plasma from the officially suggested repositories as noted on the SDB page about Plasma5.
Let me point it out again - you're installing less tested, less reviewed, packages from an experimental repository who's primary function is preparing software for use in Tumbleweed.
If you always expect it to work on Leap, or any other distribution of your choice, you need the sort of help I cant provide via a mailinglist.
My concern about TW is mainly based on what I see on the factory mailinglist - are you really telling me that the whole distribution is always being thoroughly tested between two snapshots? And not just with "smoke tests"? ...even when the two snapshots are only a day apart? OK that i wanna know more about. how are we doing that? Can I come see? Cheers MH -- gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Tuesday, March 19, 2019 10:32:33 AM CET Mathias Homann wrote:
My concern about TW is mainly based on what I see on the factory mailinglist - are you really telling me that the whole distribution is always being thoroughly tested between two snapshots? And not just with "smoke tests"?
...even when the two snapshots are only a day apart?
OK that i wanna know more about. how are we doing that? Can I come see?
https://en.opensuse.org/openSUSE:Factory_development_model https://en.opensuse.org/openSUSE:Development_Process You can see there that there are two kind of openQA tests. One for the staging projects. You can consider them smoke tests. Once the package move from staging to Factory there is an integration openQA test. This is a complete test and only if openQA says so, there is a release. So, during the live of a package you have it reviewed when is submitted to a devel project, reviewed again when submitted to Factory (tons of bots and developers), is tested by openQA during the staging process and tested again with the integration test in openQA. The coverage of openQA tests and the status of the releases candidates can be inspected here: https://openqa.opensuse.org/ Installing openQA is not easy, but contributing to the tests can be done from this repo: https://github.com/os-autoinst/os-autoinst-distri-opensuse Check the documentation of the project here: http://open.qa/documentation/ -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, 19 Mar 2019 at 10:32, Mathias Homann <Mathias.Homann@opensuse.org> wrote:
You should not expect anything in a devel Project to always work, period. That does not negate the fact that if people want to mess around building their own distribution by taking experimental stuff on their stable system, they can do so - that is what we have documented on the wiki. But be under no illusion that when you do that, you're building a system that is going to be less tested, less reviewed, and logic dictates, less reliable than Tumbleweed.
Fully agree here - but like I already said several times: the SDB article about Plasma clearly advises to use KDE:Frameworks5 which to me means it *should* be stable enough for end users.
The SDB Article does no such thing. There is no advice to use KDE:Frameworks5, just documentation on how people COULD if they wanted to. They should be well aware of the less supported nature of what they're doing. https://en.opensuse.org/SDB:KDE_repositories "This page lists and describes the available repositories containing KDE software and provides links. Most of them are maintained and supported by the openSUSE KDE Community team". Key phrases include "Most of them" - implying not everything is maintained nor supported. Also "the openSUSE KDE Community team" are NOT "the openSUSE Project" - the distinction should be clear, the Project as a whole tests more, reviews more, and supports more than any one team of community volunteers. "If you want test and/or use the latest release, you can use this repo. " - This is not saying people SHOULD use it, this is saying people CAN use it. "Note for openSUSE Leap users: Leap ships with a Qt LTS release, which is not recent enough for the newest Plasma. So to use KDE:Frameworks5, KDE:Qt5 is required. Some applications from third-party repos might not be installable as they require the specific version of Qt shipped with Leap. " The above notes should make it clear should be no expectation that the latest KDE Frameworks, Plasma, or Applications only work on Leap with significant effort, and some applications will not work.
My concern about TW is mainly based on what I see on the factory mailinglist
If you were subscribed to the opensuse-support@ mailinglist you would think that every openSUSE release is absolutely broken 100% of the time. And if you subscribe to the Ubuntu, Fedora, or Arch mailinglists, you would think likewise. the any development mailinglist is always going to have examples of when stuff goes wrong. Making any firm conclusion from such discussions is akin to choosing a doctor based on what you heard people talking about in the waiting room.
are you really telling me that the whole distribution is always being thoroughly tested between two snapshots? And not just with "smoke tests"?
...even when the two snapshots are only a day apart?
OK that i wanna know more about. how are we doing that? Can I come see?
Alberto already answered this pretty well, so I can cheekily just say 'Yes' There are even times we don't ship, not because we find any issues, but because we developed the next snapshot before we finished testing the last one. We don't mess around with Tumbleweed - it only ships when we're confident it works. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Mathias Homann schrieb:
Am Dienstag, 19. März 2019, 10:12:57 CET schrieb Richard Brown:
On Tue, 19 Mar 2019 at 10:06, Mathias Homann
<Mathias.Homann@opensuse.org> wrote:
https://de.opensuse.org/SDB:KDE_Plasma_5 points users towards KDE:Frameworks5, and according to that SDB page the *unstable* plasma is in KDE:Unstable:* [...] Fully agree here - but like I already said several times: the SDB article about Plasma clearly advises to use KDE:Frameworks5 which to me means it *should* be stable enough for end users.
Someone please update or delete that article then. It's from 2016... cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday, 19 March 2019 9:49 Richard Brown wrote:
You seem to be suggesting that Tumbleweed is somehow less supported or reliable than fricking devel repositories
Not necessarily. There are people who want their system as a whole stable (Leap style stable) but they need or want recent versions of specific subset of packages. For example, I'm running Leap 15.0 with recent git packages on my laptop because I'm using some recent features for my workflow (e.g. git range- diff). And I'm certainly not going to risk full Tumbleweed with all the breakages and subtle work environment changes. If the bleeding edge git package is broken, that's something I can live with; in the worst case, I can always revert to "known good" version (locally stored). But for the rest of the system, I want to minimize the risk of nasty surprises. Michal Kubecek -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 2019-03-19 10:47, schrieb Michal Kubecek:
On Tuesday, 19 March 2019 9:49 Richard Brown wrote:
You seem to be suggesting that Tumbleweed is somehow less supported or reliable than fricking devel repositories
Not necessarily. There are people who want their system as a whole stable (Leap style stable) but they need or want recent versions of specific subset of packages.
For example, I'm running Leap 15.0 with recent git packages on my laptop because I'm using some recent features for my workflow (e.g. git range- diff). And I'm certainly not going to risk full Tumbleweed with all the breakages and subtle work environment changes. If the bleeding edge git package is broken, that's something I can live with; in the worst case, I can always revert to "known good" version (locally stored). But for the rest of the system, I want to minimize the risk of nasty surprises.
Michal Kubecek
My sentiments exactly. The fact that I *can* frig around with everything and know how to do this shit does not mean that after work I have the time and energy left to actually do it. My personal work/play machine just has to work. Reliably. Which means that I prefer the linux version of any given game over the windows version, because of what mickeysoft did to the last couple of windows 10 updates... XD but that's a bit OT.
On 19/03/2019 20:58, Mathias Homann wrote:
Am 2019-03-19 10:47, schrieb Michal Kubecek:
On Tuesday, 19 March 2019 9:49 Richard Brown wrote:
You seem to be suggesting that Tumbleweed is somehow less supported or reliable than fricking devel repositories
Not necessarily. There are people who want their system as a whole stable (Leap style stable) but they need or want recent versions of specific subset of packages.
For example, I'm running Leap 15.0 with recent git packages on my laptop because I'm using some recent features for my workflow (e.g. git range- diff). And I'm certainly not going to risk full Tumbleweed with all the breakages and subtle work environment changes. If the bleeding edge git package is broken, that's something I can live with; in the worst case, I can always revert to "known good" version (locally stored). But for the rest of the system, I want to minimize the risk of nasty surprises.
Michal Kubecek
My sentiments exactly. The fact that I *can* frig around with everything and know how to do this shit does not mean that after work I have the time and energy left to actually do it. My personal work/play machine just has to work. Reliably. Which means that I prefer the linux version of any given game over the windows version, because of what mickeysoft did to the last couple of windows 10 updates... XD but that's a bit OT.
Well then you should stick to the standard repo's unless you want to "play around" and have stuff occasionally break. Sometimes not having the latest everything is the sacrifice you need to make to have something you never have to play with. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Dienstag, 19. März 2019, 11:34:15 CET schrieb Simon Lees:
On 19/03/2019 20:58, Mathias Homann wrote:
Am 2019-03-19 10:47, schrieb Michal Kubecek:
On Tuesday, 19 March 2019 9:49 Richard Brown wrote:
You seem to be suggesting that Tumbleweed is somehow less supported or reliable than fricking devel repositories
Not necessarily. There are people who want their system as a whole stable (Leap style stable) but they need or want recent versions of specific subset of packages.
For example, I'm running Leap 15.0 with recent git packages on my laptop because I'm using some recent features for my workflow (e.g. git range- diff). And I'm certainly not going to risk full Tumbleweed with all the breakages and subtle work environment changes. If the bleeding edge git package is broken, that's something I can live with; in the worst case, I can always revert to "known good" version (locally stored). But for the rest of the system, I want to minimize the risk of nasty surprises.
Michal Kubecek
My sentiments exactly. The fact that I *can* frig around with everything and know how to do this shit does not mean that after work I have the time and energy left to actually do it. My personal work/play machine just has to work. Reliably. Which means that I prefer the linux version of any given game over the windows version, because of what mickeysoft did to the last couple of windows 10 updates... XD but that's a bit OT.
Well then you should stick to the standard repo's unless you want to "play around" and have stuff occasionally break. Sometimes not having the latest everything is the sacrifice you need to make to have something you never have to play with.
there is that... but on the other hand, on the KDE bugtracker you get "use the latest version, your issue is fixed by now" a lot... cheers MH -- gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Tue, 19 Mar 2019 at 11:49, Mathias Homann <Mathias.Homann@opensuse.org> wrote:
Well then you should stick to the standard repo's unless you want to "play around" and have stuff occasionally break. Sometimes not having the latest everything is the sacrifice you need to make to have something you never have to play with.
there is that... but on the other hand, on the KDE bugtracker you get "use the latest version, your issue is fixed by now" a lot...
Indeed, it's a common occurrence from many, if not most upstreams these days So when you have KDE upstream saying that, and Qt, and systemd, and kernel, and mesa, and udev, and, and, and..at some point only logical conclusion is to give up the notion that 'stable' (in terms of time) releases are actually 'stable' (in terms of reliability). The reality is that software is dependant on other software. And modern software moves quickly. And it's the latest software the works best in the eyes of the people creating it. The chance of getting more than a handful of upstreams to agree on a release cadence is smaller a snowballs chance in hell. Then the question becomes how do you ship all these different bits of software at a suitable pace to minimise the "your issue is fixed already" factor, while making sure all the pieces are built consistently, tested together, and work. Luckily, this is an area which openSUSE has led for well over a decade. With OBS, openQA and more we have the tools. With our experience and policies we have the techniques. And all of this has come together to be made manifest in openSUSE Tumbleweed and it's derivatives. Leap is for people who don't need to keep up with that fast moving world, and that's fine. The world isn't black and white - individuals can do whatever they want on their individual machines, but they should realise they're taking their fate in their own hands and adding risk and complexity out of scope of the thoughts of the Project as a whole. In my view the most sensible answer if you want to keep up with the faster world we live in is through a rolling release like Tumbleweed. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
. Am 19. März 2019 08:11:50 GMT-03:00 schrieb Richard Brown <RBrownCCB@opensuse.org>:
In my view the most sensible answer if you want to keep up with the faster world we live in is through a rolling release like Tumbleweed.
+1 Runing TW for some years now on my main workhorse (without Nvidia) I had once a serious issue that could be fixed by rolling back and waiting for the next snapshot. For the rest , I enjoy the most up to date packages without hassle... Viele Grüße Axel -- Diese Nachricht wurde von meinem Android-Tablet mit K-9 Mail gesendet -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Mathias Homann schrieb:
Am Dienstag, 19. März 2019, 11:34:15 CET schrieb Simon Lees:
On 19/03/2019 20:58, Mathias Homann wrote:
Am 2019-03-19 10:47, schrieb Michal Kubecek:
On Tuesday, 19 March 2019 9:49 Richard Brown wrote:
You seem to be suggesting that Tumbleweed is somehow less supported or reliable than fricking devel repositories
Not necessarily. There are people who want their system as a whole stable (Leap style stable) but they need or want recent versions of specific subset of packages.
For example, I'm running Leap 15.0 with recent git packages on my laptop because I'm using some recent features for my workflow (e.g. git range- diff). And I'm certainly not going to risk full Tumbleweed with all the breakages and subtle work environment changes. If the bleeding edge git package is broken, that's something I can live with; in the worst case, I can always revert to "known good" version (locally stored). But for the rest of the system, I want to minimize the risk of nasty surprises.
Michal Kubecek
My sentiments exactly. The fact that I *can* frig around with everything and know how to do this shit does not mean that after work I have the time and energy left to actually do it. My personal work/play machine just has to work. Reliably. Which means that I prefer the linux version of any given game over the windows version, because of what mickeysoft did to the last couple of windows 10 updates... XD but that's a bit OT.
Well then you should stick to the standard repo's unless you want to "play around" and have stuff occasionally break. Sometimes not having the latest everything is the sacrifice you need to make to have something you never have to play with.
there is that... but on the other hand, on the KDE bugtracker you get "use the latest version, your issue is fixed by now" a lot...
Leap ships LTS versions of Plasma. The whole point of that is that upstream can backport fixes to that version and you do not have to use the latest developer version of KDE. Maybe not all developers have that in mind though. If there's important bugs that should be fixed in the KDE we have on Leap please just point that out in your bug reports so the developers backport the fix to the LTS branch. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels
Maybe somebody will realize at some point that dkms is a better option with a distro that changes kernels every week. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 2019-03-19 11:01, schrieb Stasiek Michalski:
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels
Maybe somebody will realize at some point that dkms is a better option with a distro that changes kernels every week.
AFAIK the nvidia drivers already use DKMS, and build "on the fly" when you install/upgrade the package. Problem is, Kernel 5.x did "something" that might break nvidia drivers... I've been told that it does not concern the desktop drivers, but what I've seen on the -factory list suggests otherwise. anyway, it's just so much more convenient for end users to get an automated package update to trigger the process than doing it manually - been there, done that for years until suse started having packages. This way all I have to do is click on the little rocket in ansible tower. Once. For X machines. ;) Cheers MH
Had anyone at SUSE tried to reach NVIDIA asking them for permission to use desktop drivers in openQA so failing to build kernel module of theirs would be soft fail at least? On Tue, Mar 19, 2019 at 1:25 PM Mathias Homann <Mathias.Homann@opensuse.org> wrote:
Am 2019-03-19 11:01, schrieb Stasiek Michalski:
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels
Maybe somebody will realize at some point that dkms is a better option with a distro that changes kernels every week.
AFAIK the nvidia drivers already use DKMS, and build "on the fly" when you install/upgrade the package. Problem is, Kernel 5.x did "something" that might break nvidia drivers...
I've been told that it does not concern the desktop drivers, but what I've seen on the -factory list suggests otherwise.
anyway, it's just so much more convenient for end users to get an automated package update to trigger the process than doing it manually - been there, done that for years until suse started having packages. This way all I have to do is click on the little rocket in ansible tower. Once. For X machines. ;)
Cheers MH
-- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 20/03/2019 03:04, Andrei Dziahel wrote:
Had anyone at SUSE tried to reach NVIDIA asking them for permission to use desktop drivers in openQA so failing to build kernel module of theirs would be soft fail at least?
The issue in some way is less a nvidia thing and more a kernel developer / licensing thing, in the past some kernel developers have felt that the nvidia driver violates the kernels licensing terms, as such openSUSE has respected the kernel developers with this opinion by not shipping / having nvidia drivers running within the openSUSE project. Atleast thats my recollection, I could remember wrong.
On Tue, Mar 19, 2019 at 1:25 PM Mathias Homann <Mathias.Homann@opensuse.org> wrote:
Am 2019-03-19 11:01, schrieb Stasiek Michalski:
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels
Maybe somebody will realize at some point that dkms is a better option with a distro that changes kernels every week.
AFAIK the nvidia drivers already use DKMS, and build "on the fly" when you install/upgrade the package. Problem is, Kernel 5.x did "something" that might break nvidia drivers...
I've been told that it does not concern the desktop drivers, but what I've seen on the -factory list suggests otherwise.
anyway, it's just so much more convenient for end users to get an automated package update to trigger the process than doing it manually - been there, done that for years until suse started having packages. This way all I have to do is click on the little rocket in ansible tower. Once. For X machines. ;)
Cheers MH
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
See, having them distributed separately is just fine (by me). What is not quite OK is that when kernel breaks NVIDIA kernel module, there seems to be no way for anyone to know that, except via tracking that rglinuxtech blog (/cc sndirtsch@suse: am I correct?). You guys probably do have an in-house SUSE-only OBS installation, do you? If so, it is feasible to set up continuous builds of https://build.opensuse.org/project/show/X11:Drivers:Video against https://build.opensuse.org/project/show/Kernel:HEAD in there, isn't it? On Wed, Mar 20, 2019 at 2:33 AM Simon Lees <sflees@suse.de> wrote:
On 20/03/2019 03:04, Andrei Dziahel wrote:
Had anyone at SUSE tried to reach NVIDIA asking them for permission to use desktop drivers in openQA so failing to build kernel module of theirs would be soft fail at least?
The issue in some way is less a nvidia thing and more a kernel developer / licensing thing, in the past some kernel developers have felt that the nvidia driver violates the kernels licensing terms, as such openSUSE has respected the kernel developers with this opinion by not shipping / having nvidia drivers running within the openSUSE project. Atleast thats my recollection, I could remember wrong.
On Tue, Mar 19, 2019 at 1:25 PM Mathias Homann <Mathias.Homann@opensuse.org> wrote:
Am 2019-03-19 11:01, schrieb Stasiek Michalski:
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels
Maybe somebody will realize at some point that dkms is a better option with a distro that changes kernels every week.
AFAIK the nvidia drivers already use DKMS, and build "on the fly" when you install/upgrade the package. Problem is, Kernel 5.x did "something" that might break nvidia drivers...
I've been told that it does not concern the desktop drivers, but what I've seen on the -factory list suggests otherwise.
anyway, it's just so much more convenient for end users to get an automated package update to trigger the process than doing it manually - been there, done that for years until suse started having packages. This way all I have to do is click on the little rocket in ansible tower. Once. For X machines. ;)
Cheers MH
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 2019-03-19 11:01, Stasiek Michalski wrote:
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels
Maybe somebody will realize at some point that dkms is a better option with a distro that changes kernels every week.
The rc phase of the kernel is on the order of 7 *weeks*. There is *that much* time between the API break, and the source release of these new APIs to the wider public -- and then probably *another* week until that all has passed the openSUSE machinery involving OpenQA and so on.
From when I built fglrx, nvidia (during the 96.x to 346.x-ish era), vmware and vbox modules, updating the source to new APIs was not hard. Certainly did not take seven weeks.
Maybe somebody will realize that nvidia has a terrible kernel development following procedure. Or, for the marketeers, "uncompetetive". Maybe if R&D spent less time on trying to cheat the benchmarks.. but I digress. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On mardi, 19 mars 2019 13.36:34 h CET Jan Engelhardt wrote:
On Tuesday 2019-03-19 11:01, Stasiek Michalski wrote:
On the third hand, all the stuff I read on the opensuse lists about tumbleweed and its "quirks" is why I'm *not* using tumbleweed.
- nvidia and tumbleweed kernels
Maybe somebody will realize at some point that dkms is a better option with a distro that changes kernels every week.
The rc phase of the kernel is on the order of 7 *weeks*. There is *that much* time between the API break, and the source release of these new APIs to the wider public -- and then probably *another* week until that all has passed the openSUSE machinery involving OpenQA and so on.
From when I built fglrx, nvidia (during the 96.x to 346.x-ish era), vmware and vbox modules, updating the source to new APIs was not hard. Certainly did not take seven weeks.
Maybe somebody will realize that nvidia has a terrible kernel development following procedure. Or, for the marketeers, "uncompetetive". Maybe if R&D spent less time on trying to cheat the benchmarks.. but I digress.
Maybe there too much urban legend. Nvidia works (especially the official rpm, thanks Stefan) in a reliable way. There's people on ML you can heard almost each time, but they have a mixture of bad practice (nvidia the hard way), and very old hardware (really old). Thanks openSUSE, and TW I can life safely on the edge, and my hardware is supported and working. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (12)
-
Alberto Planas Dominguez -
Andrei Dziahel -
Axel Braun -
Bruno Friedmann -
Jan Engelhardt -
Ludwig Nussel -
Mathias Homann -
Mathias Homann
-
Michal Kubecek -
Richard Brown -
Simon Lees -
Stasiek Michalski