Re: plasma desktop broken again :(
Gents, I enjoy KDE5 desktop (testing / unstable) since quite some weeks now. Quite usable it is! Thanks for your efforts, I will use it, thereby helping to mature it. Many, many, thanks. Luc 2015-10-31 14:38 GMT+01:00 Martin Steigerwald : > Am Freitag, 30. Oktober 2015, 17:57:03 CET schrieb Matthias Bodenbinder: > > Full acknowledge! > > > > I am not an early adopter. If I would be somebody who likes bleeding edge > > software with all the risks I would be using sid.I am using debian > testing > > because it is supposed to be a good compromise. > > > > I am personally not in agreement with statements like "stuff happens". > This > > "love it or leave it" attitude is preventing any continuous improvement > > discussion. And this is for sure: The release process "unstable -> > testing" > > has room for improvement. > > The *issues* are known. > > But a discussion done *here* isn´t going to change anything. > > A discussion about testing on debian-devel may lead to some changes, > especially if you would propose a constructive alternative and also offer > to > help out to make it happen. > > If you do that, first refer to old discussions about always releaseable > testing. This really is no new topic at all. > > Its a volunteer effort, so unless you volunteer to help, you can complain > as > much as you want, and it is your perfect right to do so, yet, whether > someone > else steps up to fix your complaints is *completely* out of your control. > It > is every contributor´s perfect right to choose how to allocate the time > spend > on Debian work. You have no moral right to decide on how others choose to > spend their free time. And in my view when I complain I often find myself > feeling miserable afterwards, cause I see that my complaining doesn´t > facilitiate change. > > There are only a few people doing this packaging work in their free time. > As > to my knowledge about no one is being paid for this work. From my > impressions > at DebConf I surely got that they work to with best intentions and to the > best > of their abilities. You can even just monitor #debian-qt-kde IRC channel > for a > while to see what I mean. No one intends to break anything for anyone. Yet, > its a complex matter and people do mistakes at times and due to the way > migrations of packages into testing works the results at times are > basically > unpredictable. > > From what I gathered so far, I´d even basically recommend to use unstable > for > some time at the moment, at it seems to be far less affected and fixes > seem to > come through much quicker. Then settle back to testing at another time. > > And in general if testing/unstable is too bumpy for you, use *stable* until > later. > > We are still in the development phase for next Debian stable. Debian > packagers > want to get in what they want to see in next Debian stable. Nothing has > been > frozen yet, so in case you want a slower ride: Wait longer after release of > stable till you switch to testing or unstable. > > You can still use tried and tested KDE SC 4.14 if you want it. So if it is > to > bumpy to you, use *stable*. > > That said I may probably stop discussing here again as in the time I spend > answering here I could have worked on helping the Qt/KDE team to move > forward. > I have been busy with lots of other stuff and I didn´t help much. But fully > aware of that I also didn´t complain, cause I do understand that the > current > team works to the best of their abilities and I feel gratitude for that. So > unless I see opportunities to help constructively I mostly remain quiet to > let > others do their work without urging them spend additional time with my not > so > constructive feedback. > > > And yes, before I close: Testing/unstable has been bumby in the last > months. > But the libstcd++ ABI transitions was and still is one of the biggest > transitions Debian ever had. One packager told me that the last time such a > big transition happened for KDE/Plasma was about 10 years ago. Added to > that > it wasn´t / isn´t the only transition. > > Thanks, > -- > Martin > > -- Luc Castermans mailto:luc.casterm...@gmail.com
Re: plasma desktop broken again :(
Am Freitag, 30. Oktober 2015, 17:57:03 CET schrieb Matthias Bodenbinder: > Full acknowledge! > > I am not an early adopter. If I would be somebody who likes bleeding edge > software with all the risks I would be using sid.I am using debian testing > because it is supposed to be a good compromise. > > I am personally not in agreement with statements like "stuff happens". This > "love it or leave it" attitude is preventing any continuous improvement > discussion. And this is for sure: The release process "unstable -> testing" > has room for improvement. The *issues* are known. But a discussion done *here* isn´t going to change anything. A discussion about testing on debian-devel may lead to some changes, especially if you would propose a constructive alternative and also offer to help out to make it happen. If you do that, first refer to old discussions about always releaseable testing. This really is no new topic at all. Its a volunteer effort, so unless you volunteer to help, you can complain as much as you want, and it is your perfect right to do so, yet, whether someone else steps up to fix your complaints is *completely* out of your control. It is every contributor´s perfect right to choose how to allocate the time spend on Debian work. You have no moral right to decide on how others choose to spend their free time. And in my view when I complain I often find myself feeling miserable afterwards, cause I see that my complaining doesn´t facilitiate change. There are only a few people doing this packaging work in their free time. As to my knowledge about no one is being paid for this work. From my impressions at DebConf I surely got that they work to with best intentions and to the best of their abilities. You can even just monitor #debian-qt-kde IRC channel for a while to see what I mean. No one intends to break anything for anyone. Yet, its a complex matter and people do mistakes at times and due to the way migrations of packages into testing works the results at times are basically unpredictable. From what I gathered so far, I´d even basically recommend to use unstable for some time at the moment, at it seems to be far less affected and fixes seem to come through much quicker. Then settle back to testing at another time. And in general if testing/unstable is too bumpy for you, use *stable* until later. We are still in the development phase for next Debian stable. Debian packagers want to get in what they want to see in next Debian stable. Nothing has been frozen yet, so in case you want a slower ride: Wait longer after release of stable till you switch to testing or unstable. You can still use tried and tested KDE SC 4.14 if you want it. So if it is to bumpy to you, use *stable*. That said I may probably stop discussing here again as in the time I spend answering here I could have worked on helping the Qt/KDE team to move forward. I have been busy with lots of other stuff and I didn´t help much. But fully aware of that I also didn´t complain, cause I do understand that the current team works to the best of their abilities and I feel gratitude for that. So unless I see opportunities to help constructively I mostly remain quiet to let others do their work without urging them spend additional time with my not so constructive feedback. And yes, before I close: Testing/unstable has been bumby in the last months. But the libstcd++ ABI transitions was and still is one of the biggest transitions Debian ever had. One packager told me that the last time such a big transition happened for KDE/Plasma was about 10 years ago. Added to that it wasn´t / isn´t the only transition. Thanks, -- Martin
Re: plasma desktop broken again :(
Am Freitag, 30. Oktober 2015, 10:20:58 CET schrieb Gary Dale: > On 30/10/15 04:49 AM, Tim Ruehsen wrote: > > On Friday 30 October 2015 00:09:31 Gary Dale wrote: > >> On 29/10/15 04:54 PM, Brad Rogers wrote: > >>> On Thu, 29 Oct 2015 09:54:22 -0400 > >>> Gary Dale wrote: > >>> > >>> Hello Gary, > >>> > And not wanting to rehash that old argument, the current system is > clearly not working. Surely all the bright people maintaining Debian > >>> > >>> Debian is run by humans. Humans, being humans, make mistakes. It's > >>> been admitted that libqt5x11extras5 v5.5.1 getting into testing was not > >>> ideal. Also, reference to this being a corner case. IOW, a situation > >>> that was difficult, if not impossible, to foresee. > >>> > can come up with something better? > >>> > >>> It works the way *they* want it, mistakes notwithstanding. If you don't > >>> like that method of migration, then maybe Debian testing isn't for you. > >>> Breakage happens in testing. By and large, not frequently, but it does > >>> happen. Also, it's not usually such a major issue. To paraphrase a > >>> well known English saying; "Stuff happens". > >> > >> Yes, but it's been happening a LOT this time around. I've been running > >> Debian Testing for over a decade and don't recall seeing this many major > >> fails ever. > >> > >> If my memory serves me, KDE4 didn't make it into Testing until it was > >> reasonably complete and stable - somewhere after 4.2 wasn't it? Until > >> then Testing still had KDE3. Why the push to get KDE5 out when it is > >> still having massive teething problems? > > > > Because we (unstable and/or testing users) want it ASAP :-) > > > > Breakages happen all the way, but you should be able to apply workarounds > > to recover - in this case downgrading libqt5x11extras5. > > If you don't want (or can't) do that, unstable (and maybe testing) is not > > a good choice for you. > > > > The 'brute force' method would be to use btrfs + snapshots before each > > upgrade (e.g. done by a little script that automatically removes old > > shapshots). > > > > That is the burden to unstable users - but it also is kind of fun. > > > > Regards, > > > > Tim > > I can understand why "unstable" users may want it, but that doesn't > those of us using testing are a different breed. We want to help get > things ready for the next stable release. That means helping to identify > bugs that could cause problems for people wanting stable software. Which you can´t do unless you actually receive the new stuff for installing. Any testing on KDE SC 4.14 does not serve much of a purpose anymore, as upstream switched over already. Debian as usual has been later than other distributions, waiting for things to settle a bit, but at some time there is the time to switch over. And yes, I do think upstream Plasma 5 and KDE Frameworks, especially KDEPIM needs further stabilizition work. And that slowing development speed a bit in favor for more bug fixing could be beneficial. > We're not in this for the excitement/fun. We're the people who use our > computers a lot and need stuff that is basically working. That's why we > make good bug reporters. However we can't report bugs on software that > doesn't work at all. I am running Plasma 5 on Unstable for months now and it basically worked *most* of the time *just* fine. And if it didn´t work it often didn´t take more than a day or two to work again. From what I read here I get the impression that testing users tend to have much more issues due to package migration issues. Maybe how testing is created needs adjustments, I don´t know. I just notice that it seems that testing users seem to have more issues than unstable users when looking at this list. *Or* unstable users don´t write to the list about issues, but instead just fix / work-around on their own. That said: No amount of "this should be different" talk on this list will make any changes happen. Actual work on the change will do. Thanks, -- Martin
Re: plasma desktop broken again :(
Am Freitag, 30. Oktober 2015, 00:09:31 CET schrieb Gary Dale: > On 29/10/15 04:54 PM, Brad Rogers wrote: > > On Thu, 29 Oct 2015 09:54:22 -0400 > > Gary Dale wrote: > > > > Hello Gary, > > > >> And not wanting to rehash that old argument, the current system is > >> clearly not working. Surely all the bright people maintaining Debian > > > > Debian is run by humans. Humans, being humans, make mistakes. It's > > been admitted that libqt5x11extras5 v5.5.1 getting into testing was not > > ideal. Also, reference to this being a corner case. IOW, a situation > > that was difficult, if not impossible, to foresee. > > > >> can come up with something better? > > > > It works the way *they* want it, mistakes notwithstanding. If you don't > > like that method of migration, then maybe Debian testing isn't for you. > > Breakage happens in testing. By and large, not frequently, but it does > > happen. Also, it's not usually such a major issue. To paraphrase a > > well known English saying; "Stuff happens". > > Yes, but it's been happening a LOT this time around. I've been running > Debian Testing for over a decade and don't recall seeing this many major > fails ever. > > If my memory serves me, KDE4 didn't make it into Testing until it was > reasonably complete and stable - somewhere after 4.2 wasn't it? Until > then Testing still had KDE3. Why the push to get KDE5 out when it is > still having massive teething problems? Hey, Plasma is at 5.4 already. Debian Qt/KDE team didn´t start with the first releases of Plasma 5 and KDE Frameworks. I think the first was 5.3 and KDE Frameworks 5.13. But at one time it is necessary to start pulling in the new stuff so there is enough time to test and stabilize it enough for next stable. And thats what unstable and testing really is about. While I agree that always releasable testing would be fine, I do think it is challenging to get there without slowing down development of Debian up to a point where stable cannot be stable anymore cause stuff have not had enough testing time. And shipping Debian 9 with KDE SC 4.14 and kdelibs 4.11 isn´t an option either as these are unmaintained upstream meanwhile. Ciao, -- Martin
Re: plasma desktop broken again :(
On 30/10/15 11:10 AM, Diederik de Haas wrote: On Friday 30 October 2015 10:20:58 Gary Dale wrote: I can understand why "unstable" users may want it, but that doesn't those of us using testing are a different breed. We want to help get things ready for the next stable release. That means helping to identify bugs that could cause problems for people wanting stable software. And that's exactly what has happened here. A (single) component entered testing when it shouldn't have (only together with the other pieces that are needed). I understand that it's frustrating mostly because the impact is rather big, but the actual problem is rather small. However we can't report bugs on software that doesn't work at all. The GUI/Plasma didn't work. It is indeed a lot harder to figure out and report on _what_ is broken when the tools you're (most) familiar with aren't working at that time. That's why you need IMO to be rather proficient to do things on the CLI in order to run testing (and even more so for unstable). The incredible stability of testing (and unstable) of recent years is both a blessing, but also a curse as it has distorted the ideas/expectations of those releases. When you're running testing you need to be able to fix a non-working GUI using CLI tools only. That means keeping old versions of packages available so you can downgrade in case things fail. Either you keep old versions around in a location of your own or use /var/cache/apt/ (thus be very careful with 'aptitude clean/autoclean') or know how you can get packages from snapshot.debian.org _without_ the use of gui tools/browsers. In this regard you can say that users of unstable have it easier because they can downgrade to the testing versions of packages rather easily (I always have both testing and unstable in my sources.list). Debian has always had incredible stability in the stable release but Testing hasn't been that way in Stretch. It's been far worse than testing anything I can recall since Potato. Why the push to get KDE5 out when it is still having massive teething problems? Plasma 5 didn't enter testing after 5.4 iirc so that's a lot more conservative then with KDE4. But because of KDE Frameworks 5 there are now a LOT more (but smaller) packages and thus figuring out the exact (packaging) relationships has become more complex and as you've noticed, some of those issues only pop up when a component enters testing without the ones that that component also needs. My suggestion is to take this as a learning opportunity and figure out, when things are working fine, how to deal with a situation when things break like they just have been. While these breakages should occur less and less over the release cycle of stretch, expect them not to be over just yet. One way to deal with it could be to add the unstable sources to your APT config (but default to testing), so you can upgrade more packages to their newer version and report whether that would solve the issue. Version numbers reflect progress, not stability. I've been using various frameworks since the 1980s so I tend to associate them with stability, not crashes. When I developed a framework for a particular MS-DOS product, I was able to document when it would break previous code built using it and let people know what needed to be done to fix their code. When I was making major changes to the framework, I wouldn't release it until I was sure it was stable. Debian packaging has the ability to automate version compatibility checking. When library code is changing rapidly like it apparently is now, why not use the version checking to tie particular packages to specific library versions? Once things quiet down, you can revert to a looser version checking.
Re: plasma desktop broken again :(
Am 30.10.2015 um 15:20 schrieb Gary Dale: > I can understand why "unstable" users may want it, but that doesn't those of > us using testing are a different breed. We want to help get things ready for > the next stable release. That means helping to identify bugs that could cause > problems for people wanting stable software. > > We're not in this for the excitement/fun. We're the people who use our > computers a lot and need stuff that is basically working. That's why we make > good bug reporters. However we can't report bugs on software that doesn't > work at all. > > Full acknowledge! I am not an early adopter. If I would be somebody who likes bleeding edge software with all the risks I would be using sid.I am using debian testing because it is supposed to be a good compromise. I am personally not in agreement with statements like "stuff happens". This "love it or leave it" attitude is preventing any continuous improvement discussion. And this is for sure: The release process "unstable -> testing" has room for improvement. Matthias
Re: plasma desktop broken again :(
Hi Carlos, Am Freitag 30 Oktober 2015, 11:09:30 schrieb Carlos Kosloff: > Thanks for answer, but I am in testing, anybody tried that, or should I > be the first to take the plunge? I've just updated testing. My SDDM starts up properly again, and I can log in / out / back in / out again into/from Plasma5. This was on a VM, so not fully in real life. > > On 10/30/2015 10:59 AM, Tim Ruehsen wrote: > > On Friday 30 October 2015 10:28:45 Carlos Kosloff wrote: > >> Apart from that, OK to run a full dist-upgrade now, unholding > >> libqt5x11extras5? > > I did it a few hours ago (on unstable), works smoothly so far. > > > > Tim HTH, Christian -- kernel concepts GmbH Tel: +49-271-771091-11 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part.
Re: plasma desktop broken again :(
I'll dist-upgrade my testing when I am back home. Just a few hours from now... but maybe someone else already knows. Tim On Friday 30 October 2015 11:09:30 Carlos Kosloff wrote: > Thanks for answer, but I am in testing, anybody tried that, or should I > be the first to take the plunge? > > > > On 10/30/2015 10:59 AM, Tim Ruehsen wrote: > > On Friday 30 October 2015 10:28:45 Carlos Kosloff wrote: > >> Apart from that, OK to run a full dist-upgrade now, unholding > >> libqt5x11extras5? > > > > I did it a few hours ago (on unstable), works smoothly so far. > > > > Tim
Re: plasma desktop broken again :(
On Friday 30 October 2015 10:20:58 Gary Dale wrote: > On 30/10/15 04:49 AM, Tim Ruehsen wrote: > > On Friday 30 October 2015 00:09:31 Gary Dale wrote: > >> On 29/10/15 04:54 PM, Brad Rogers wrote: > >>> On Thu, 29 Oct 2015 09:54:22 -0400 > >>> Gary Dale wrote: > >>> > >>> Hello Gary, > >>> > And not wanting to rehash that old argument, the current system is > clearly not working. Surely all the bright people maintaining Debian > >>> > >>> Debian is run by humans. Humans, being humans, make mistakes. It's > >>> been admitted that libqt5x11extras5 v5.5.1 getting into testing was not > >>> ideal. Also, reference to this being a corner case. IOW, a situation > >>> that was difficult, if not impossible, to foresee. > >>> > can come up with something better? > >>> > >>> It works the way *they* want it, mistakes notwithstanding. If you don't > >>> like that method of migration, then maybe Debian testing isn't for you. > >>> Breakage happens in testing. By and large, not frequently, but it does > >>> happen. Also, it's not usually such a major issue. To paraphrase a > >>> well known English saying; "Stuff happens". > >> > >> Yes, but it's been happening a LOT this time around. I've been running > >> Debian Testing for over a decade and don't recall seeing this many major > >> fails ever. > >> > >> If my memory serves me, KDE4 didn't make it into Testing until it was > >> reasonably complete and stable - somewhere after 4.2 wasn't it? Until > >> then Testing still had KDE3. Why the push to get KDE5 out when it is > >> still having massive teething problems? > > > > Because we (unstable and/or testing users) want it ASAP :-) > > > > Breakages happen all the way, but you should be able to apply workarounds > > to recover - in this case downgrading libqt5x11extras5. > > If you don't want (or can't) do that, unstable (and maybe testing) is not > > a good choice for you. > > > > The 'brute force' method would be to use btrfs + snapshots before each > > upgrade (e.g. done by a little script that automatically removes old > > shapshots). > > > > That is the burden to unstable users - but it also is kind of fun. > > > > Regards, > > > > Tim > > I can understand why "unstable" users may want it, but that doesn't > those of us using testing are a different breed. We want to help get > things ready for the next stable release. That means helping to identify > bugs that could cause problems for people wanting stable software. Me too, I have unstable at work (ouch, don't you laugh at me, please) and testing at home (so wife & kids don't run into too many problems). > We're not in this for the excitement/fun. We're the people who use our > computers a lot and need stuff that is basically working. Basically, I work on unstable. I am a positive character, that's why challenges, work, life, everything is *fun* to me. Depends on how you define fun, of course. I agree on the *basically working* part. But your machine was always doing that - just the desktop/ui-apps did not start. > That's why we make good bug reporters. However we can't report bugs on software that doesn't work at all. $ reportbug ... Also, please read again my previous email (about snapshots and/or downgrading). These are just tools to help you and me in case of havoc - they really help to keep frustration away. Tim
Re: plasma desktop broken again :(
On Friday 30 October 2015 10:20:58 Gary Dale wrote: > I can understand why "unstable" users may want it, but that doesn't > those of us using testing are a different breed. We want to help get > things ready for the next stable release. That means helping to identify > bugs that could cause problems for people wanting stable software. And that's exactly what has happened here. A (single) component entered testing when it shouldn't have (only together with the other pieces that are needed). I understand that it's frustrating mostly because the impact is rather big, but the actual problem is rather small. > However we can't report bugs on software that doesn't work at all. The GUI/Plasma didn't work. It is indeed a lot harder to figure out and report on _what_ is broken when the tools you're (most) familiar with aren't working at that time. That's why you need IMO to be rather proficient to do things on the CLI in order to run testing (and even more so for unstable). The incredible stability of testing (and unstable) of recent years is both a blessing, but also a curse as it has distorted the ideas/expectations of those releases. When you're running testing you need to be able to fix a non-working GUI using CLI tools only. That means keeping old versions of packages available so you can downgrade in case things fail. Either you keep old versions around in a location of your own or use /var/cache/apt/ (thus be very careful with 'aptitude clean/autoclean') or know how you can get packages from snapshot.debian.org _without_ the use of gui tools/browsers. In this regard you can say that users of unstable have it easier because they can downgrade to the testing versions of packages rather easily (I always have both testing and unstable in my sources.list). > Why the push to get KDE5 out when it is still having massive teething > problems? Plasma 5 didn't enter testing after 5.4 iirc so that's a lot more conservative then with KDE4. But because of KDE Frameworks 5 there are now a LOT more (but smaller) packages and thus figuring out the exact (packaging) relationships has become more complex and as you've noticed, some of those issues only pop up when a component enters testing without the ones that that component also needs. My suggestion is to take this as a learning opportunity and figure out, when things are working fine, how to deal with a situation when things break like they just have been. While these breakages should occur less and less over the release cycle of stretch, expect them not to be over just yet. One way to deal with it could be to add the unstable sources to your APT config (but default to testing), so you can upgrade more packages to their newer version and report whether that would solve the issue. signature.asc Description: This is a digitally signed message part.
Re: plasma desktop broken again :(
Thanks for answer, but I am in testing, anybody tried that, or should I be the first to take the plunge? On 10/30/2015 10:59 AM, Tim Ruehsen wrote: On Friday 30 October 2015 10:28:45 Carlos Kosloff wrote: Apart from that, OK to run a full dist-upgrade now, unholding libqt5x11extras5? I did it a few hours ago (on unstable), works smoothly so far. Tim
Re: plasma desktop broken again :(
On Friday 30 October 2015 10:28:45 Carlos Kosloff wrote: > Apart from that, OK to run a full dist-upgrade now, unholding > libqt5x11extras5? I did it a few hours ago (on unstable), works smoothly so far. Tim
Re: plasma desktop broken again :(
Agreed, I use advanced computers which simply would not work in stable, sometimes not even in testing, kernel too old. I had to install more advanced kernel from siduction, until I could get a suitable one in testing. So for me, to use testing is simply a matter of having software that will recognize advanced graphic and sound cards. Bug reports in testing I submit as many as I can. Apart from that, OK to run a full dist-upgrade now, unholding libqt5x11extras5? On 10/30/2015 10:20 AM, Gary Dale wrote: I can understand why "unstable" users may want it, but that doesn't those of us using testing are a different breed. We want to help get things ready for the next stable release. That means helping to identify bugs that could cause problems for people wanting stable software. We're not in this for the excitement/fun. We're the people who use our computers a lot and need stuff that is basically working. That's why we make good bug reporters. However we can't report bugs on software that doesn't work at all.
Re: plasma desktop broken again :(
On 30/10/15 04:49 AM, Tim Ruehsen wrote: On Friday 30 October 2015 00:09:31 Gary Dale wrote: On 29/10/15 04:54 PM, Brad Rogers wrote: On Thu, 29 Oct 2015 09:54:22 -0400 Gary Dale wrote: Hello Gary, And not wanting to rehash that old argument, the current system is clearly not working. Surely all the bright people maintaining Debian Debian is run by humans. Humans, being humans, make mistakes. It's been admitted that libqt5x11extras5 v5.5.1 getting into testing was not ideal. Also, reference to this being a corner case. IOW, a situation that was difficult, if not impossible, to foresee. can come up with something better? It works the way *they* want it, mistakes notwithstanding. If you don't like that method of migration, then maybe Debian testing isn't for you. Breakage happens in testing. By and large, not frequently, but it does happen. Also, it's not usually such a major issue. To paraphrase a well known English saying; "Stuff happens". Yes, but it's been happening a LOT this time around. I've been running Debian Testing for over a decade and don't recall seeing this many major fails ever. If my memory serves me, KDE4 didn't make it into Testing until it was reasonably complete and stable - somewhere after 4.2 wasn't it? Until then Testing still had KDE3. Why the push to get KDE5 out when it is still having massive teething problems? Because we (unstable and/or testing users) want it ASAP :-) Breakages happen all the way, but you should be able to apply workarounds to recover - in this case downgrading libqt5x11extras5. If you don't want (or can't) do that, unstable (and maybe testing) is not a good choice for you. The 'brute force' method would be to use btrfs + snapshots before each upgrade (e.g. done by a little script that automatically removes old shapshots). That is the burden to unstable users - but it also is kind of fun. Regards, Tim I can understand why "unstable" users may want it, but that doesn't those of us using testing are a different breed. We want to help get things ready for the next stable release. That means helping to identify bugs that could cause problems for people wanting stable software. We're not in this for the excitement/fun. We're the people who use our computers a lot and need stuff that is basically working. That's why we make good bug reporters. However we can't report bugs on software that doesn't work at all.
Re: plasma desktop broken again :(
On Friday 30 October 2015 00:09:31 Gary Dale wrote: > On 29/10/15 04:54 PM, Brad Rogers wrote: > > On Thu, 29 Oct 2015 09:54:22 -0400 > > Gary Dale wrote: > > > > Hello Gary, > > > >> And not wanting to rehash that old argument, the current system is > >> clearly not working. Surely all the bright people maintaining Debian > > > > Debian is run by humans. Humans, being humans, make mistakes. It's > > been admitted that libqt5x11extras5 v5.5.1 getting into testing was not > > ideal. Also, reference to this being a corner case. IOW, a situation > > that was difficult, if not impossible, to foresee. > > > >> can come up with something better? > > > > It works the way *they* want it, mistakes notwithstanding. If you don't > > like that method of migration, then maybe Debian testing isn't for you. > > Breakage happens in testing. By and large, not frequently, but it does > > happen. Also, it's not usually such a major issue. To paraphrase a > > well known English saying; "Stuff happens". > > Yes, but it's been happening a LOT this time around. I've been running > Debian Testing for over a decade and don't recall seeing this many major > fails ever. > > If my memory serves me, KDE4 didn't make it into Testing until it was > reasonably complete and stable - somewhere after 4.2 wasn't it? Until > then Testing still had KDE3. Why the push to get KDE5 out when it is > still having massive teething problems? Because we (unstable and/or testing users) want it ASAP :-) Breakages happen all the way, but you should be able to apply workarounds to recover - in this case downgrading libqt5x11extras5. If you don't want (or can't) do that, unstable (and maybe testing) is not a good choice for you. The 'brute force' method would be to use btrfs + snapshots before each upgrade (e.g. done by a little script that automatically removes old shapshots). That is the burden to unstable users - but it also is kind of fun. Regards, Tim
Re: plasma desktop broken again :(
On 29/10/15 04:54 PM, Brad Rogers wrote: On Thu, 29 Oct 2015 09:54:22 -0400 Gary Dale wrote: Hello Gary, And not wanting to rehash that old argument, the current system is clearly not working. Surely all the bright people maintaining Debian Debian is run by humans. Humans, being humans, make mistakes. It's been admitted that libqt5x11extras5 v5.5.1 getting into testing was not ideal. Also, reference to this being a corner case. IOW, a situation that was difficult, if not impossible, to foresee. can come up with something better? It works the way *they* want it, mistakes notwithstanding. If you don't like that method of migration, then maybe Debian testing isn't for you. Breakage happens in testing. By and large, not frequently, but it does happen. Also, it's not usually such a major issue. To paraphrase a well known English saying; "Stuff happens". Yes, but it's been happening a LOT this time around. I've been running Debian Testing for over a decade and don't recall seeing this many major fails ever. If my memory serves me, KDE4 didn't make it into Testing until it was reasonably complete and stable - somewhere after 4.2 wasn't it? Until then Testing still had KDE3. Why the push to get KDE5 out when it is still having massive teething problems?
Re: plasma desktop broken again :(
On 29/10/15 04:21 PM, Lisandro Damián Nicanor Pérez Meyer wrote: On Thursday 29 October 2015 16:04:31 Gary Dale wrote: [snip] Non the less if you have good ideas to help the bright people to improve the system believe me we are eager to know them :) [snip] If a new version of a dependency breaks something, then the dependency version should be marked in the main package. In this case you seem to be saying that the main package requires a version < whatever the new library package is. Surely someone along the line should have recognized the potential breakage when they "improved" the qt5x11extras5 package and created a new version of the main package to stop the library from being updated. Correct! That was what qtbase-abi-x-y-z was meant to do... until we found this corner case :) Not knowing the details of the packages, I am accepting your explanation that a single package created all this mayhem with KDE programs. Well, at least some part of it. There might be other bugs around. This makes it all the more obvious that the package should not have been let out without the main packages. Doesn't anyone keep a Debian/testing machine to look for these problems? I keep my machines in sid to see nothing breaks there, which is the first step. We are really two people (plus some more packagers that from time to time push some fix) behind Qt, so if you want to help us by testing testing (aka testing stretch), you are most welcomed :) Beware that in order to catch this one you would need to do your own britney to migrate packages and test. Well I am testing Stretch but I can't help test KDE when I can't get into it. :) I haven't been using sid because this is my main workstation. Everything else is running Jessie because I need it to work. Can't you create a virtual machine to run stretch to see if migrating breaks something?
Re: plasma desktop broken again :(
On Thu, 29 Oct 2015 09:54:22 -0400 Gary Dale wrote: Hello Gary, >And not wanting to rehash that old argument, the current system is >clearly not working. Surely all the bright people maintaining Debian Debian is run by humans. Humans, being humans, make mistakes. It's been admitted that libqt5x11extras5 v5.5.1 getting into testing was not ideal. Also, reference to this being a corner case. IOW, a situation that was difficult, if not impossible, to foresee. >can come up with something better? It works the way *they* want it, mistakes notwithstanding. If you don't like that method of migration, then maybe Debian testing isn't for you. Breakage happens in testing. By and large, not frequently, but it does happen. Also, it's not usually such a major issue. To paraphrase a well known English saying; "Stuff happens". -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" Tired of doing day jobs with no thanks for what I do Do Anything You Wanna Do - Eddie & The Hotrods pgpysIBIqtecj.pgp Description: OpenPGP digital signature
Re: plasma desktop broken again :(
On Thursday 29 October 2015 16:04:31 Gary Dale wrote: [snip] > > Non the less if you have good ideas to help the bright people to improve > > the system believe me we are eager to know them :) [snip] > If a new version of a dependency breaks something, then the dependency > version should be marked in the main package. In this case you seem to > be saying that the main package requires a version < whatever the new > library package is. Surely someone along the line should have recognized > the potential breakage when they "improved" the qt5x11extras5 package > and created a new version of the main package to stop the library from > being updated. Correct! That was what qtbase-abi-x-y-z was meant to do... until we found this corner case :) > Not knowing the details of the packages, I am accepting your explanation > that a single package created all this mayhem with KDE programs. Well, at least some part of it. There might be other bugs around. > This > makes it all the more obvious that the package should not have been let > out without the main packages. Doesn't anyone keep a Debian/testing > machine to look for these problems? I keep my machines in sid to see nothing breaks there, which is the first step. We are really two people (plus some more packagers that from time to time push some fix) behind Qt, so if you want to help us by testing testing (aka testing stretch), you are most welcomed :) Beware that in order to catch this one you would need to do your own britney to migrate packages and test. -- If you realize that you are in a hole... stop digging. Anonimous, thanks to ScottK. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: plasma desktop broken again :(
Sorry Gary for sending it to your private mail, my mistake! On Thursday 29 October 2015 09:54:22 Gary Dale wrote: [snip] > > That's not how migration from sid works. As well you know. > > And not wanting to rehash that old argument, the current system is > clearly not working. Surely all the bright people maintaining Debian can > come up with something better? Hi Gary! The problem with qt5x11extras5 migrating before anything else in the Qt stack never happened to us before in the whole Qt 5 series, and we can't fix what's not broken. Non the less if you have good ideas to help the bright people to improve the system believe me we are eager to know them :) Kinds regards, Lisandro. -- Must it be assumed that because we are engineers beauty is not our concern, and that while we make our constructions robust and durable we do not also strive to make them elegant? Is it not true that the genuine conditions of strength always comply with the secret conditions of harmony? Gustave Eiffel, 1887 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: plasma desktop broken again :(
On 28/10/15 05:41 PM, Brad Rogers wrote: On Wed, 28 Oct 2015 17:27:04 -0400 Gary Dale wrote: Hello Gary, I realize that KDE is going through a lot of changes right now, but can't stuff be kept out of testing until it is somewhat usable? That's not how migration from sid works. As well you know. And not wanting to rehash that old argument, the current system is clearly not working. Surely all the bright people maintaining Debian can come up with something better?
Re: plasma desktop broken again :(
On Wed, 28 Oct 2015 17:27:04 -0400 Gary Dale wrote: Hello Gary, >I realize that KDE is going through a lot of changes right now, but >can't stuff be kept out of testing until it is somewhat usable? That's not how migration from sid works. As well you know. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" A friend of a friend he got beaten I Predict A Riot - Kaiser Chiefs pgphRFyAXu5uu.pgp Description: OpenPGP digital signature