How are Tumbleweed Build Failures Caught? (e.g. FORTIFY_SOURCE=3)
All, I was following the "[TW] nextcloud desktop client uninstallable" thread and that brought up the question of how are these build failures being identified and handled in the rolling-release process and how are they slipping through? I ask because I'm not that familiar with the Tumbleweed QA process and am only familiar with how Arch does it. With Arch, there are two sets of repos: (1) "testing" - where new upstream packages and build system changes are introduced. Any build type failures are identified here and package remain in testing until the issue are resolved (along with any packages that depend on them) (2) the normal repos - when package hit here, all build and dependency issues have been resolved and the only corner cases that arise are the stray user hardware/software combinations, etc... I suspect openSUSE has a similar setup for Tumbleweed, but in the case of nextcloud client and Calibre the FORTIFY_SOURCE=3 somehow seems to have gotten by. Now this is just "growing pains" no different to handling build with jumps in gcc or glibc versions -- there are going to be issues to fix. My curiosity is where/how are these "growing pains" issues caught in the Tumbleweed process? -- David C. Rankin, J.D.,P.E.
Hi David et. al, On Fri, 2022-07-01 at 10:24 -0500, David C. Rankin wrote:
All,
I was following the "[TW] nextcloud desktop client uninstallable" thread and that brought up the question of how are these build failures being identified and handled in the rolling-release process and how are they slipping through?
I ask because I'm not that familiar with the Tumbleweed QA process and am only familiar with how Arch does it. With Arch, there are two sets of repos:
(1) "testing" - where new upstream packages and build system changes are introduced. Any build type failures are identified here and package remain in testing until the issue are resolved (along with any packages that depend on them)
(2) the normal repos - when package hit here, all build and dependency issues have been resolved and the only corner cases that arise are the stray user hardware/software combinations, etc...
I suspect openSUSE has a similar setup for Tumbleweed, but in the case of nextcloud client and Calibre the FORTIFY_SOURCE=3 somehow seems to have gotten by. Now this is just "growing pains" no different to handling build with jumps in gcc or glibc versions -- there are going to be issues to fix.
My curiosity is where/how are these "growing pains" issues caught in the Tumbleweed process?
Factory contains roughly 15k source packages by now. The entire project is built up of three 'layers': Ring0: Distro bootstrap. The core to get things building Ring1: 'The DVD' - things guaranteed not to break, mainly consists of the two main desktops KDE/GNOME plus a set of packages that must build at any moment. Ring0 + Ring1 is 3238 packages (as of now - numbers vary) Those packages are being forked into the 'Letter stagings' and, are rebuilt against anything in that staging project at the time, and then passed on to openQA. only when passsing, the change in the staging can be accepted. Now, as this is 'only' ~3k packages, this leaves a gap of like 12k packages. Those are only tested to build/install properly when they are submitted to Factory themselves - any later changes are not tested on cross-impact - so they can fail to build This is what happened to nextcloud-desktop now: it failed to build since Mid June. But it was still installable, so 'nobody seemed to care' Two weeks later, a new Qt version comes by; nextcloud-desktop still not building results in 'dependencies no longer being available' Striving for a 0-build fail would be a nice-to-have, but in the ~8 years as release manager I have never seen that. The closes to that must have been in the range of 20 failures (curretnly we are at ~200) Cheers, Dominique PS the doc model is also described at https://en.opensuse.org/openSUSE:Factory_development_model
On 7/1/22 10:46, Dominique Leuenberger / DimStar wrote:
Now, as this is 'only' ~3k packages, this leaves a gap of like 12k packages. Those are only tested to build/install properly when they are submitted to Factory themselves - any later changes are not tested on cross-impact - so they can fail to build
This is what happened to nextcloud-desktop now: it failed to build since Mid June. But it was still installable, so 'nobody seemed to care'
Two weeks later, a new Qt version comes by; nextcloud-desktop still not building results in 'dependencies no longer being available'
Striving for a 0-build fail would be a nice-to-have, but in the ~8 years as release manager I have never seen that. The closes to that must have been in the range of 20 failures (curretnly we are at ~200)
As my daughters would say "OMG, has it been 8 years already!" Unfortunately, I had been in this game a little longer than that. By the way, congratulations on doing a great job!! As the maintainer of a complicated package (VirtualBox) that frequently fails to build in its 3 homes of TW, Leap 15.3, and Leap 15.4, I get E-mails every time there is a build failure. If a maintainer ignores those warnings, or there is no active maintainer, then you can end up in the situation that nextcloud-desktop is in. Finally, as a maintainer nearing EOL (I'm 82), I implore people to become maintainers, particularly if you have a vested interest in a particular package. These things do not fix themselves, and bitrot is real. Is there a list of packages that need active maintainers other than Dimstar's "fails to build list?" If not, there should be. I am still well, but I think it would be in the best interests of our community if someone else took over VirtualBox while I am still around. When I took over, I was on my own. Fortunately, I got general help on some details of package building, but it would have been nice to have been able to consult with the previous maintainer. A README.build is being maintained, but that is imperfect. Larry
In ~6 years this was the first build Problem in nextcloud. And I don't understand this problem. There comes to problems together. Newer Qt and the cflags problem. New Qt would build new, I think. But than I comes the FORTIFY_SOURCE=3 problem. Regards Eric Am 1. Juli 2022 20:28:28 MESZ schrieb Larry Finger <Larry.Finger@lwfinger.net>:
On 7/1/22 10:46, Dominique Leuenberger / DimStar wrote:
Now, as this is 'only' ~3k packages, this leaves a gap of like 12k packages. Those are only tested to build/install properly when they are submitted to Factory themselves - any later changes are not tested on cross-impact - so they can fail to build
This is what happened to nextcloud-desktop now: it failed to build since Mid June. But it was still installable, so 'nobody seemed to care'
Two weeks later, a new Qt version comes by; nextcloud-desktop still not building results in 'dependencies no longer being available'
Striving for a 0-build fail would be a nice-to-have, but in the ~8 years as release manager I have never seen that. The closes to that must have been in the range of 20 failures (curretnly we are at ~200)
As my daughters would say "OMG, has it been 8 years already!" Unfortunately, I had been in this game a little longer than that. By the way, congratulations on doing a great job!!
As the maintainer of a complicated package (VirtualBox) that frequently fails to build in its 3 homes of TW, Leap 15.3, and Leap 15.4, I get E-mails every time there is a build failure. If a maintainer ignores those warnings, or there is no active maintainer, then you can end up in the situation that nextcloud-desktop is in.
Finally, as a maintainer nearing EOL (I'm 82), I implore people to become maintainers, particularly if you have a vested interest in a particular package. These things do not fix themselves, and bitrot is real.
Is there a list of packages that need active maintainers other than Dimstar's "fails to build list?" If not, there should be.
I am still well, but I think it would be in the best interests of our community if someone else took over VirtualBox while I am still around. When I took over, I was on my own. Fortunately, I got general help on some details of package building, but it would have been nice to have been able to consult with the previous maintainer. A README.build is being maintained, but that is imperfect.
Larry
On 7/1/22 13:28, Larry Finger wrote:
As my daughters would say "OMG, has it been 8 years already!" Unfortunately, I had been in this game a little longer than that. By the way, congratulations on doing a great job!!
As the maintainer of a complicated package (VirtualBox) that frequently fails to build in its 3 homes of TW, Leap 15.3, and Leap 15.4, I get E-mails every time there is a build failure. If a maintainer ignores those warnings, or there is no active maintainer, then you can end up in the situation that nextcloud-desktop is in.
Oh I've followed the Virtualbox saga well, especially your patch for 5.18 that has made it's way through the various distros. (I packaged VB 5.X for AUR) Problem with VB is Oracle is always 4-8 weeks behind in getting a new release out. (testing packages are usually usable within a week or so) The sheer volume of packages openSUSE/SuSE provide is incredible, and moving Python, gcc/glibc (and the kernel in the case of VB) make it a daunting challenge to keep everything up and running. (by the way, maintainer retirement doesn't begin until 85 :) -- David C. Rankin, J.D.,P.E.
On 7/1/22 17:00, David C. Rankin wrote:
(by the way, maintainer retirement doesn't begin until 85 :)
Noted. I did get a youngster (only 70) that has an interest in being trained. This is certainly a case where I am more than happy to train my replacement. At least I can be certain that he is not being paid more than I am. Larry
On 7/2/22 03:58, Larry Finger wrote:
On 7/1/22 10:46, Dominique Leuenberger / DimStar wrote:
Now, as this is 'only' ~3k packages, this leaves a gap of like 12k packages. Those are only tested to build/install properly when they are submitted to Factory themselves - any later changes are not tested on cross-impact - so they can fail to build
This is what happened to nextcloud-desktop now: it failed to build since Mid June. But it was still installable, so 'nobody seemed to care'
Two weeks later, a new Qt version comes by; nextcloud-desktop still not building results in 'dependencies no longer being available'
Striving for a 0-build fail would be a nice-to-have, but in the ~8 years as release manager I have never seen that. The closes to that must have been in the range of 20 failures (curretnly we are at ~200)
As my daughters would say "OMG, has it been 8 years already!" Unfortunately, I had been in this game a little longer than that. By the way, congratulations on doing a great job!!
As the maintainer of a complicated package (VirtualBox) that frequently fails to build in its 3 homes of TW, Leap 15.3, and Leap 15.4, I get E-mails every time there is a build failure. If a maintainer ignores those warnings, or there is no active maintainer, then you can end up in the situation that nextcloud-desktop is in.
Finally, as a maintainer nearing EOL (I'm 82), I implore people to become maintainers, particularly if you have a vested interest in a particular package. These things do not fix themselves, and bitrot is real.
Is there a list of packages that need active maintainers other than Dimstar's "fails to build list?" If not, there should be.
In Theory such a list would be really nice, but in reality some people know that they no longer have time and post a list of packages up for adoption to this list which would be the best starting point for such a list. In many other cases maintainers slowly drift a way or something else happens meaning they no longer have time and simply don't get to sending such an email. The only way we can really detect these cases is when a package stops building or a security but is raised and not dealt with in a timely manner. Using activity doesn't really work because for example I have some serial port related packages that haven't changed in 8 years because serial ports havn't changed and the packages just work. -- 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
On 7/1/22 10:46, Dominique Leuenberger / DimStar wrote:
Factory contains roughly 15k source packages by now.
The entire project is built up of three 'layers':
Ring0: Distro bootstrap. The core to get things building Ring1: 'The DVD' - things guaranteed not to break, mainly consists of the two main desktops KDE/GNOME plus a set of packages that must build at any moment.
Ring0 + Ring1 is 3238 packages (as of now - numbers vary)
Those packages are being forked into the 'Letter stagings' and, are rebuilt against anything in that staging project at the time, and then passed on to openQA. only when passsing, the change in the staging can be accepted.
Now, as this is 'only' ~3k packages, this leaves a gap of like 12k packages. Those are only tested to build/install properly when they are submitted to Factory themselves - any later changes are not tested on cross-impact - so they can fail to build
This is what happened to nextcloud-desktop now: it failed to build since Mid June. But it was still installable, so 'nobody seemed to care'
Two weeks later, a new Qt version comes by; nextcloud-desktop still not building results in 'dependencies no longer being available'
Striving for a 0-build fail would be a nice-to-have, but in the ~8 years as release manager I have never seen that. The closes to that must have been in the range of 20 failures (curretnly we are at ~200)
Cheers, Dominique
PS the doc model is also described at https://en.opensuse.org/openSUSE:Factory_development_model
Perfect Dominique, This is exactly the information that I was missing. That also explains the problems I had with FreeCAD on 15.4 and the ringed process. Part of the 12K that built and installed fine, but Segfaulted when any new/open file was tried. Ultimaker Cura 3D Printing packages was also part of the 12K that built fine, but install failed due to a missing python3-sentry-sdk which wouldn't have been seen as a build fail. (not TW, but presuming the lead-up to release for Leap is similar) Thanks for the help. -- David C. Rankin, J.D.,P.E.
Calibre build error has nothing to do with FORTIFY_SOURCE=3. There was an typo error. And nextcloud-desktop was build till cflags (opflags) was changed. Regards Eric Am 1. Juli 2022 17:24:33 MESZ schrieb "David C. Rankin" <drankinatty@suddenlinkmail.com>:
All,
I was following the "[TW] nextcloud desktop client uninstallable" thread and that brought up the question of how are these build failures being identified and handled in the rolling-release process and how are they slipping through?
I ask because I'm not that familiar with the Tumbleweed QA process and am only familiar with how Arch does it. With Arch, there are two sets of repos:
(1) "testing" - where new upstream packages and build system changes are introduced. Any build type failures are identified here and package remain in testing until the issue are resolved (along with any packages that depend on them)
(2) the normal repos - when package hit here, all build and dependency issues have been resolved and the only corner cases that arise are the stray user hardware/software combinations, etc...
I suspect openSUSE has a similar setup for Tumbleweed, but in the case of nextcloud client and Calibre the FORTIFY_SOURCE=3 somehow seems to have gotten by. Now this is just "growing pains" no different to handling build with jumps in gcc or glibc versions -- there are going to be issues to fix.
My curiosity is where/how are these "growing pains" issues caught in the Tumbleweed process?
-- David C. Rankin, J.D.,P.E.
On 01.07.22 20:05, Eric Schirra wrote:
Calibre build error has nothing to do with FORTIFY_SOURCE=3. There was an typo error.
And nextcloud-desktop was build till cflags (opflags) was changed.
...which apparently uncovered a calibre bug which is now papered over by reverting to FORTIFY_SOURCE=2 in the calibre spec file. I completely understand that you might not understand this, but the new features in newer compilers -- as tiresome it may be to fix the software bugs they uncover -- are not created to annoy you but they are created to make software better and more secure. If we don't want that, we could as well have stayed at gcc-2.95.3 as included in SUSE Linux Professional 7.2 (which, btw, compiled the kernel much faster than later 3.x versions... :-P) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am Samstag, 2. Juli 2022, 10:55:42 CEST schrieb Stefan Seyfried:
On 01.07.22 20:05, Eric Schirra wrote:
Calibre build error has nothing to do with FORTIFY_SOURCE=3. There was an typo error.
And nextcloud-desktop was build till cflags (opflags) was changed.
...which apparently uncovered a calibre bug which is now papered over by reverting to FORTIFY_SOURCE=2 in the calibre spec file.
please don't use calibre here as an example. Any other OSS project would happily accept feedback bout build fails with FORTIFY_SOURCE - but the guy behind calibre says that he won't support anyone using calibre from any other source than the binary packages he provides, so I don't know if he'd even read a report about build problems... cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am Samstag, 2. Juli 2022, 10:55:42 CEST schrieb Stefan Seyfried:
On 01.07.22 20:05, Eric Schirra wrote:
Calibre build error has nothing to do with FORTIFY_SOURCE=3. There was an typo error.
And nextcloud-desktop was build till cflags (opflags) was changed.
...which apparently uncovered a calibre bug which is now papered over by reverting to FORTIFY_SOURCE=2 in the calibre spec file.
I completely understand that you might not understand this, but the new features in newer compilers -- as tiresome it may be to fix the software bugs they uncover -- are not created to annoy you but they are created to make software better and more secure.
If we don't want that, we could as well have stayed at gcc-2.95.3 as included in SUSE Linux Professional 7.2 (which, btw, compiled the kernel much faster than later 3.x versions... :-P)
I'm tired of discussing any alleged improvements that actually only raise problems. You need manpower to fix them, but you don't actually have it. Then just leave out the "new" for now until it works. I see this approach in other areas and "companies" as well. It brings the user absolutely nothing. Yes I do not understand something. Namely, I don't understand that you introduce things for which you then later need even more people that you don't have. That's the only thing I don't understand. And as for calibre, you're completely wrong. Before you throw any assertions into the room here (there is probably also today's sense of time), look at the first themselves the spec-files. There is nothing in there that has to do with FORTIFY_SOURCE. The error was only a missing > character in a line. Oh and one more thing. If you install calibre and nextcloud-desktop for example over my repo it runs again for a while. The problem is the slow process from bug fixing to release among other things also by approval hiarachies etc. A SecurtiyFix can take more than a week. So you should work on the processes. Also on the processes at SUSE directly. Because there is also a lot wrong. So now you or others can again accusations, denunciations and claims, as I would have no idea or I would not understand something or whatever, throw into the room. This is probably also the today's life style and the today's togetherness. Contributes nothing to solution and lets critics and people with other opinion only unnecessary and false way in a bad light appear. Regards Eric
On 02.07.22 11:24, Eric Schirra wrote:
I'm tired of discussing any alleged improvements that actually only raise problems. You need manpower to fix them, but you don't actually have it. Then just leave out the "new" for now until it works.
Then just go back to linux-2.2.16.tar.gz or windows 95. Features? Security fixes? Who needs them anyway. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 2. Juli 2022 13:10:09 MESZ schrieb Stefan Seyfried <stefan.seyfried@googlemail.com>:
On 02.07.22 11:24, Eric Schirra wrote:
I'm tired of discussing any alleged improvements that actually only raise problems. You need manpower to fix them, but you don't actually have it. Then just leave out the "new" for now until it works.
Then just go back to linux-2.2.16.tar.gz or windows 95.
Features? Security fixes? Who needs them anyway.
Totally unqualified remarks. But I think you noticed that yourself the second time.
On 02.07.22 13:24, Eric Schirra wrote:
Am 2. Juli 2022 13:10:09 MESZ schrieb Stefan Seyfried <stefan.seyfried@googlemail.com>:
On 02.07.22 11:24, Eric Schirra wrote:
I'm tired of discussing any alleged improvements that actually only raise problems. You need manpower to fix them, but you don't actually have it. Then just leave out the "new" for now until it works.
Then just go back to linux-2.2.16.tar.gz or windows 95.
Features? Security fixes? Who needs them anyway.
Totally unqualified remarks. But I think you noticed that yourself the second time.
No, absolutely not. You declare the FORTIFY_SOURCE work of the toolchains as useless, calling it "alleged improvements that only raise problems" (which is a pretty hefty insult in itself btw), when in reality these features uncover quite some hidden (sometimes for a very long time...) subtle bugs which were not found before. Quite often these are the typical security bugs (buffer overruns and friends) about which everyone should be concerned. And yes, "my" packages and even software where I am upstream also sometimes suffers from such bugs and of course its often tiresome to fix those. But I cannot blame the new compiler for finding these bugs. And yes, sometimes it also reports false positives, but then there is always a way to just silence the warning for these cases. For my own software I most of the time (for the false positives) see that there is a way to improve the code to both satisfy the compiler checks and actually make the code more clear in what it does, so even those often lead to improvements in the code in question. It is similar to the time when (at work) colleagues introduced the requirement that every shell script must pass the "Shellcheck" linter before being accepted into production. In the beginning I was complaining (because Shellcheck really is anal retentive ;-)), but after it uncovered some really nasty edge cases in my scripts that had actually lead to spurious failures before nobody really understood, I nowadays look at it from a different angle. The same is IMO true for the FORTIFY_SOURCE features of gcc. Best regards, and have fun :-) Steafn -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 7/2/22 13:24, Eric Schirra wrote:
Am 2. Juli 2022 13:10:09 MESZ schrieb Stefan Seyfried <stefan.seyfried@googlemail.com>:
On 02.07.22 11:24, Eric Schirra wrote:
I'm tired of discussing any alleged improvements that actually only raise problems. You need manpower to fix them, but you don't actually have it. Then just leave out the "new" for now until it works.
Then just go back to linux-2.2.16.tar.gz or windows 95.
Features? Security fixes? Who needs them anyway.
Totally unqualified remarks. But I think you noticed that yourself the second time.
Sorry, Eric. But Stefan's answer is not just unqualified. It's an ironic statement to point out that your statement could be understood as overly broad and basically says: Never change a running system, no matter which improvements to security could be achieved. (I'm not in your head, so I do not claim to know what you really meant.) Personally I appreciate if security defaults are tightened. And yes, sometimes there will be a fall-out one has to deal with. The art is to keep this fall-out fairly small and detect fails ASAP. But there's won't be any progress without taking some risks. Ciao, Michael.
Am 2. Juli 2022 13:36:12 MESZ schrieb "Michael Ströder" <michael@stroeder.com>:
On 7/2/22 13:24, Eric Schirra wrote:
Am 2. Juli 2022 13:10:09 MESZ schrieb Stefan Seyfried <stefan.seyfried@googlemail.com>:
On 02.07.22 11:24, Eric Schirra wrote:
I'm tired of discussing any alleged improvements that actually only raise problems. You need manpower to fix them, but you don't actually have it. Then just leave out the "new" for now until it works.
Then just go back to linux-2.2.16.tar.gz or windows 95.
Features? Security fixes? Who needs them anyway.
Totally unqualified remarks. But I think you noticed that yourself the second time.
Sorry, Eric. But Stefan's answer is not just unqualified. It's an ironic statement to point out that your statement could be understood as overly broad and basically says: Never change a running system, no matter which improvements to security could be achieved. (I'm not in your head, so I do not claim to know what you really meant.)
Personally I appreciate if security defaults are tightened. And yes, sometimes there will be a fall-out one has to deal with. The art is to keep this fall-out fairly small and detect fails ASAP. But there's won't be any progress without taking some risks.
I know it was meant ironically. Nevertheless, his statement was wrong, because I did not say what he said in any words. I merely said that new things, which of course can be or are better and also safe, should only be used when they are, let's say, stable and do not pose a lot of problems. I see this in other areas as well. Old problems are not solved because they are too difficult or uninteresting. Instead, they take something new that is more hip, but doesn't have many functions yet or even bugs. I am not against new things. I certainly don't. But it should take you further and not create new problems. Regards Eric
On 7/2/22 14:49, Eric Schirra wrote:
I merely said that new things, which of course can be or are better and also safe, should only be used when they are, let's say, stable and do not pose a lot of problems. My standard answer to such a statement: Agreed, for whatever definition of "stable"... ;-)
For example: Do you consider a system with huge security holes, but which perfectly functions for you, as "stable"? Eventually many people do, until the time an attacker takes over. (Don't get me wrong. I do not assume you to be naive like this.) The real challenge is how to find out whether something reached some sort of stable state. You cannot really find out until you start using it in some form. And yes, testing Factory snapshots with openQA is already one form of using it but will never be 100% perfect. So some risks have to be accepted.
I see this in other areas as well. Old problems are not solved because they are too difficult or uninteresting. Instead, they take something new that is more hip, but doesn't have many functions yet or even bugs. Judging from Stefan's former postings here I don't think that he is blindly asking for new things.
I am not against new things. I certainly don't. But it should take you further and not create new problems. AFAICS nobody here disagrees with that.
Ciao, Michael.
On 02.07.22 14:49, Eric Schirra wrote:
Old problems are not solved because they are too difficult or uninteresting. Instead, they take something new that is more hip, but doesn't have many functions yet or even bugs.
I'm totally with you on this. (This development model even has a name, coined by Jamie Zawinski almost 20 years ago: The CADT Model, https://www.jwz.org/doc/cadt.html). But gcc / glibc development can IMHO certainly not be put into that drawer. They actually go for the difficult things, as most easy things in the field of creating toolchains is solved for quite some time. And the feature of "complain about broken software we compile if FORTIFY_SOURCE=x is given" is working stably and correct if it rejects broken software. (I will totally retract everything I wrote today if the failure in nextcloud-desktop is in fact due to a false positive).
I am not against new things. I certainly don't. But it should take you further and not create new problems.
If the new feature is detecting broken software, and the software is actually broken, then unfortunately this will unveil an existing problem, even if it looks like it "has created a new problem". Best regards and have fun, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 02.07.22 um 10:55 schrieb Stefan Seyfried:
On 01.07.22 20:05, Eric Schirra wrote:
Calibre build error has nothing to do with FORTIFY_SOURCE=3. There was an typo error.
And nextcloud-desktop was build till cflags (opflags) was changed.
...which apparently uncovered a calibre bug which is now papered over by reverting to FORTIFY_SOURCE=2 in the calibre spec file.
s/calibre/nextcloud-desktop/ and if you have ever dealt with any nextcloud related package, you won't have any hope that upstream will fix it soon, even if you report it. (Something I would expect from a responsible openSUSE package maintainer). BTW: https://github.com/nextcloud/desktop/issues/4690 To reiterate, the nextcloud-desktop package was failing to build in Factory for 2 weeks and in the devel project since May 20. There must have been plenty of automatic OBS Notifications about it as mentioned by Larry. If a maintainer chooses to ignore those there is no justification for them to whine about it on the Factory mailing list. Lest harassing other users in the OBS package comments. IMHO, even the failure to fix the build is not a big a problem as some seem to make it look here. It's not that users started to see crashes. It's just that zypper/rpm did the right thing and told the user that they can not update to the current snapshot, because Tumbleweed kept rolling with a new Qt version and left behind packages which could not keep up. - Ben
Am Samstag, 2. Juli 2022, 11:27:03 CEST schrieb Ben Greiner:
s/calibre/nextcloud-desktop/ and if you have ever dealt with any nextcloud related package, you won't have any hope that upstream will fix it soon, even if you report it. (Something I would expect from a responsible openSUSE package maintainer). BTW: https://github.com/nextcloud/desktop/issues/4690
If you are addressing me, since I am the maintainer, I find this statement an absolute impertinence. I do there in my spare time to help the general public and I have no time to fight with upstream in long discussions. For that there are paid employees of SUSE.
To reiterate, the nextcloud-desktop package was failing to build in Factory for 2 weeks and in the devel project since May 20. There must have been plenty of automatic OBS Notifications about it as mentioned by Larry. If a maintainer chooses to ignore those there is no justification for them to whine about it on the Factory mailing list. Lest harassing other users in the OBS package comments.
Another insinuation. I have not received any notification. And I would say I always respond quickly. Even to normal requests by mail. And that the package could not be built I have never ignored or bechlossen nothing to do. An insolence is this assertion. Again, it is the internal processes at openSUSE but also at SUSE that do not work and are very slow. And these are still pushed by my opinion of many wrong decisions.
IMHO, even the failure to fix the build is not a big a problem as some seem to make it look here. It's not that users started to see crashes. It's just that zypper/rpm did the right thing and told the user that they can not update to the current snapshot, because Tumbleweed kept rolling with a new Qt version and left behind packages which could not keep up.
This is how it looks. And further proof that internal processes don't work. Regards Eric
Am 02.07.22 um 11:41 schrieb Eric Schirra:
Am Samstag, 2. Juli 2022, 11:27:03 CEST schrieb Ben Greiner:
s/calibre/nextcloud-desktop/ and if you have ever dealt with any nextcloud related package, you won't have any hope that upstream will fix it soon, even if you report it. (Something I would expect from a responsible openSUSE package maintainer). BTW: https://github.com/nextcloud/desktop/issues/4690 If you are addressing me, since I am the maintainer, I find this statement an absolute impertinence. I do there in my spare time to help the general public and I have no time to fight with upstream in long discussions. For that there are paid employees of SUSE.
Absolutely not. Nobody tells you to do any work. But if you are not willing to properly maintain a package, then don't assume the role for the package. Even if you do, you should rather be thankful for any bug reports instead of harassing reporters.
To reiterate, the nextcloud-desktop package was failing to build in Factory for 2 weeks and in the devel project since May 20. There must have been plenty of automatic OBS Notifications about it as mentioned by Larry. If a maintainer chooses to ignore those there is no justification for them to whine about it on the Factory mailing list. Lest harassing other users in the OBS package comments. Another insinuation. I have not received any notification.
Which is completely on you, not on anything in "the internal process". Check your settings in https://build.opensuse.org/my/subscriptions Again, there is nothing wrong in don't willing to volunteer. But if you do, don't put the blame on others.
Again, it is the internal processes at openSUSE but also at SUSE that do not work and are very slow. And these are still pushed by my opinion of many wrong decisions.
Nonsense. Nothing is as fast as openSUSE Tumbleweed moving with upstream changes. You complain about Tumbleweed changing its packages too fast in one message and then on being too slow in the next.
On 7/2/22 12:31, Ben Greiner wrote:
Am 02.07.22 um 11:41 schrieb Eric Schirra:
Am Samstag, 2. Juli 2022, 11:27:03 CEST schrieb Ben Greiner:
s/calibre/nextcloud-desktop/ and if you have ever dealt with any nextcloud related package, you won't have any hope that upstream will fix it soon, even if you report it. (Something I would expect from a responsible openSUSE package maintainer). BTW: https://github.com/nextcloud/desktop/issues/4690
If you are addressing me, since I am the maintainer, I find this statement an absolute impertinence. I do there in my spare time to help the general public and I have no time to fight with upstream in long discussions. For that there are paid employees of SUSE.
Absolutely not. Nobody tells you to do any work. But if you are not willing to properly maintain a package, then don't assume the role for the package. Even if you do, you should rather be thankful for any bug reports instead of harassing reporters.
Calm down everybody. This personal fight does not help to solve any problem at all. Although I don't always agree with Eric in all details I can confirm that he does an enormous amount of work also on packages I'm using.
Nonsense. Nothing is as fast as openSUSE Tumbleweed moving with upstream changes. You complain about Tumbleweed changing its packages too fast in one message and then on being too slow in the next.
One of the things I'd like to be clarified at openSUSE project level is that following the old-fashioned mantra "Tumbleweed is experimental and Leap is for stable systems" sometimes leads to submit requests being declined by maintainers because the update is not compatible with Leap or is considered too new. IMHO this blocks progress in an inappropriate way. (I'm running *everything* on Tumbleweed. And these systems are all important for my daily work.) Ciao, Michael.
Am 2. Juli 2022 12:55:26 MESZ schrieb "Michael Ströder" <
Absolutely not. Nobody tells you to do any work. But if you are not willing to properly maintain a package, then don't assume the role for the package. Even if you do, you should rather be thankful for any bug reports instead of harassing reporters.
Calm down everybody. This personal fight does not help to solve any problem at all.
Although I don't always agree with Eric in all details I can confirm that he does an enormous amount of work also on packages I'm using.
I totally agree with you there. You don't always have to agree. But you should respect each other. I always miss that with him. And thank you for your words for my work.
Nonsense. Nothing is as fast as openSUSE Tumbleweed moving with upstream changes. You complain about Tumbleweed changing its packages too fast in one message and then on being too slow in the next.
One of the things I'd like to be clarified at openSUSE project level is that following the old-fashioned mantra "Tumbleweed is experimental and Leap is for stable systems" sometimes leads to submit requests being declined by maintainers because the update is not compatible with Leap or is considered too new. IMHO this blocks progress in an inappropriate way.
Years ago, I had always refused the parcels here too. But I revised my opinion because of what you said. It prevents the "advance" in Tumbleweed. But you can also build the packages so that they can be built for Leap and Tumbleweed. At least in the Devel tepos. It doesn't always work, but most of the time. It's just a little more effort. I now always handle it like this: if it is possible to build for Leap and Tumbleweed, then you should do it and it will be accepted. If it is not possible to build for Leap, it is also accepted. Example calibre. Builder in the Devel repos only for Tumbleweed in version 5.44.0. The last possible build for calibre in Leap is 4.23.0. this is then only in my home repo. Regards Eric
On 7/2/22 13:21, Eric Schirra wrote:
Am 2. Juli 2022 12:55:26 MESZ schrieb "Michael Ströder"
Although I don't always agree with Eric in all details I can confirm that he does an enormous amount of work also on packages I'm using. > I totally agree with you there. You don't always have to agree. But you should respect each other. I always miss that with him. Yes, but respect is not an unidirectional thing.
From my perspective Ben is also is doing much of the dirty work. And personally I appreciate that he was often the one answering my questions here in an informative and constructive way. So please, everybody should calm down and get back to cooperating in a constructive manner. Ciao, Michael.
Am 2. Juli 2022 12:31:06 MESZ schrieb Ben Greiner <code@bnavigator.de>:
Am 02.07.22 um 11:41 schrieb Eric Schirra:
Am Samstag, 2. Juli 2022, 11:27:03 CEST schrieb Ben Greiner:
s/calibre/nextcloud-desktop/ and if you have ever dealt with any nextcloud related package, you won't have any hope that upstream will fix it soon, even if you report it. (Something I would expect from a responsible openSUSE package maintainer). BTW: https://github.com/nextcloud/desktop/issues/4690 If you are addressing me, since I am the maintainer, I find this statement an absolute impertinence. I do there in my spare time to help the general public and I have no time to fight with upstream in long discussions. For that there are paid employees of SUSE.
Absolutely not. Nobody tells you to do any work. But if you are not willing to properly maintain a package, then don't assume the role for the package. Even if you do, you should rather be thankful for any bug reports instead of harassing reporters.
To reiterate, the nextcloud-desktop package was failing to build in Factory for 2 weeks and in the devel project since May 20. There must have been plenty of automatic OBS Notifications about it as mentioned by Larry. If a maintainer chooses to ignore those there is no justification for them to whine about it on the Factory mailing list. Lest harassing other users in the OBS package comments. Another insinuation. I have not received any notification.
Which is completely on you, not on anything in "the internal process". Check your settings in https://build.opensuse.org/my/subscriptions
Again, there is nothing wrong in don't willing to volunteer. But if you do, don't put the blame on others.
Again, it is the internal processes at openSUSE but also at SUSE that do not work and are very slow. And these are still pushed by my opinion of many wrong decisions.
Nonsense. Nothing is as fast as openSUSE Tumbleweed moving with upstream changes. You complain about Tumbleweed changing its packages too fast in one message and then on being too slow in the next.
Ben, I'm sorry to have to say this, but you always strike me as arogante and uncritical. Who unfortunately also lives in Swabia. For which I am ashamed. I have already stopped cooperating with several parcels because I was tired of it. These packages were always topical. After I stopped working on them, they always lag far behind. That's about the amount of work and good will. Stop ridiculing other opinions and making them out to be nonsense. I have private and business dealings with openSUSE and SUSE and can therefore allow myself a judgement. Regards Eric
participants (9)
-
Ben Greiner -
David C. Rankin -
Dominique Leuenberger / DimStar -
Eric Schirra -
Larry Finger -
Mathias Homann -
Michael Ströder -
Simon Lees -
Stefan Seyfried