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 :

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 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/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.

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.

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

Am 2. Juli 2022 13:10:09 MESZ schrieb Stefan Seyfried :

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 7/2/22 13:24, Eric Schirra wrote:

Am 2. Juli 2022 13:10:09 MESZ schrieb Stefan Seyfried :

...

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.

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.

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 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.

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

Am 2. Juli 2022 12:31:06 MESZ schrieb Ben Greiner :

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