Am 21.06.19 um 20:28 schrieb Luca Beltrame:

Il giorno Fri, 21 Jun 2019 20:09:54 +0200 Stefan Seyfried <stefan.seyfried@googlemail.com> ha scritto:

...

https://build.opensuse.org/request/show/711379

Please, someone override factory-auto. It's running amok.

Why? You didn't do what it asked you to do (and IMO it asks that for a good reason).

I mentioned that I removed the patches 01-42. The script does not understand it. But OK, let's drop VDR. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 21.06.19 um 20:36 schrieb Luca Beltrame:

Il giorno Fri, 21 Jun 2019 20:29:21 +0200 Stefan Seyfried <stefan.seyfried@googlemail.com> ha scritto:

...

I mentioned that I removed the patches 01-42. The script does not understand it.

Seriously, is it this hard to list all the patch files in the changes? A simple "Dropped patches: <list of all patch files>" would have been sufficient *and* it would have taken you *less* than starting this thread.

You mean a changelog entry like * Dropped patches: vdr-2.4.0-01-fix-svdrp-modt-recflag.diff vdr-2.4.0-02-fix-invalid-locking-sequence.diff vdr-2.4.0-03-fix-locking-channel-display.diff vdr-2.4.0-04-fix-locking-channel-display-2.diff vdr-2.4.0-05-fix-shutdown.diff vdr-2.4.0-06-fix-channel-switch.diff vdr-2.4.0-07-fix-disabling-mtd.diff vdr-2.4.0-08-add-multi-frontend-support.diff vdr-2.4.0-09-fix-multi-frontend-access.diff vdr-2.4.0-10-fix-missing-epg.diff vdr-2.4.0-11-fix-peerdemo-udp-port.diff vdr-2.4.0-12-fix-empty-pat.diff vdr-2.4.0-13-fix-shutdown-2.diff vdr-2.4.0-14-fix-eitscan.diff vdr-2.4.0-15-fix-skincurses.diff vdr-2.4.0-16-fix-nit-transponder-processing.diff vdr-2.4.0-17-fix-nit-sdt-trigger.diff vdr-2.4.0-19-add-eac3-from-other-sources.diff vdr-2.4.0-20-fix-logging-inactive-transponders.diff vdr-2.4.0-21-fix-libsi.diff vdr-2.4.0-22-fix-sort-recordings.diff vdr-2.4.0-23-fix-patch-16.diff vdr-2.4.0-24-fix-drop-caps.diff vdr-2.4.0-25-fix-channels-menu.diff vdr-2.4.0-26-fix-shared-ca-pids.diff vdr-2.4.0-27-fix-mtd-map-sid.diff vdr-2.4.0-28-fix-mtd-checksum.diff vdr-2.4.0-29-fix-compiler-warning.diff vdr-2.4.0-30-fix-ci-sendanswer.diff vdr-2.4.0-31-fix-invalid-lock-sequence.diff vdr-2.4.0-32-fix-remote-timers-lstt-550.diff vdr-2.4.0-34-fix-repeat-kbd.diff vdr-2.4.0-35-add-workaround-rst.diff vdr-2.4.0-36-fix-assert-free-disk-space.diff vdr-2.4.0-37-chg-max-pixmap-size.diff vdr-2.4.0-38-chg-playerbufsize.diff vdr-2.4.0-39-fix-card-index-vs-device-number.diff vdr-2.4.0-40-fix-wrong-variable-name.diff vdr-2.4.0-41-chg-skins-message-to-queue.diff vdr-2.4.0-42-fix-nit-dvbs2-backwards-compatibility-mode.diff Would really be better than - update to 2.4.1: - all upstream patches integrated, for details, see /usr/share/doc/packages/vdr/HISTORY - remove integrated patches vdr-2.4.0-01..42 I, as someone who takes some pride in its packages, refuse to create such a braindead changelog. I'd rather have the package not included in {Leap,Factory}. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 21.06.19 um 20:52 schrieb Luca Beltrame:

Il giorno Fri, 21 Jun 2019 20:43:00 +0200 Stefan Seyfried <stefan.seyfried@googlemail.com> ha scritto:

...

Would really be better than - update to 2.4.1:

Yes. Because it actually tracks all the files that have been changed. This is even more important for packages that ship a lot of up/downstream patches.

No, as lined out in the other mail, in this case it is totally fine, looking at the last ~20 changelog entries, to mention that all the patches that had been mentioned in those entries have now been removed again, because they are what the new version consists of.

...

I, as someone who takes some pride in its packages, refuse to create such a braindead changelog. I'd rather have the package not included in {Leap,Factory}.

Are you implying that all the other packagers, including those who actually are on this mailing list, don't take "pride" in their packaging? Just asking.

No, they probably just have different standards wrt "beauty" (which is in the eye of the beholder, of course). Or they just deem their changelogs as "nobody really will read this, anyway" (which might be true). I, for my packages, want sane, usable changelogs. If that means, the package can not be part of Factory, so be it. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Jun 21, 2019 at 08:36:28PM +0200, Luca Beltrame wrote:

Il giorno Fri, 21 Jun 2019 20:29:21 +0200 Stefan Seyfried <stefan.seyfried@googlemail.com> ha scritto:

...

I mentioned that I removed the patches 01-42. The script does not understand it.

Seriously, is it this hard to list all the patch files in the changes? A simple "Dropped patches: <list of all patch files>" would have been sufficient *and* it would have taken you *less* than starting this thread.

And this is exactly what is wrong - and has been wrong for few years - with request handling in both openSUSE and SLE. For anyone except the bot, the entry saying "drop all patches" is way more useful and way more easier to process than list of patches which that someone would have to carefully go through and check if it's really all of them or if there is one or two missing. So the crucial question is: are we writing the logs for people or for the bot? I have to admit that my experience in last few years is that the latter seems much more likely. And I'm not happy about it at all. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 22/06/2019 13:05, Andrei Borzenkov wrote:

21.06.2019 23:08, Michal Kubecek пишет:

...

On Fri, Jun 21, 2019 at 08:36:28PM +0200, Luca Beltrame wrote:

...

Il giorno Fri, 21 Jun 2019 20:29:21 +0200 Stefan Seyfried <stefan.seyfried@googlemail.com> ha scritto:

...

I mentioned that I removed the patches 01-42. The script does not understand it.

Seriously, is it this hard to list all the patch files in the changes? A simple "Dropped patches: <list of all patch files>" would have been sufficient *and* it would have taken you *less* than starting this thread.

And this is exactly what is wrong - and has been wrong for few years - with request handling in both openSUSE and SLE. For anyone except the bot, the entry saying "drop all patches" is way more useful

"All" depends on context which is not known at the time someone actually reads changelog. It is pretty easy to grep changelog for patch name to see when it has been added and removed. It requires careful reading to understand whether specific patch added years ago is covered by "all" in this case. Because there may be many "all" in different points of time.

Yeah if I need to go back in 3 years and work out the lifespan of a patch, its far easier to just search the changelog for all instances of the patch, Its something I have to do on occasion with packages i'm not necessarily the maintainer of and rules like this make it much easier. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 22/06/2019 18:33, Stefan Seyfried wrote:

Am 22.06.19 um 10:46 schrieb Simon Lees:

...

Yeah if I need to go back in 3 years and work out the lifespan of a patch, its far easier to just search the changelog for all instances of the patch, Its something I have to do on occasion with packages i'm not necessarily the maintainer of and rules like this make it much easier.

Look at the specific case here.

All "custom" patches named something like vdr-${version_introduced}-${purpose_of_patch}.patch

All upstream patches named vdr-${curr_ver}-${%02d,count}-${purpose}.patch

It is quite easy, even years later, to see what "removed integrated upstream patches vdr-${cur_ver}-01..42" is supposed to describe.

A valid criticism would have been to ask "can you distinguish your custom patches better, by renaming them?", something I'll do in the future whenever I have to touch one of these patches.

No my criticism of what you'd like to do is intentional, as someone who spends a lot of time looking at small things across many many packages I appreciate the fact that there are certain rules all packages follow to make them the same, one such rule is if I am dealing with a large changes file I can put a patches filename into the search field of my editor and find when the patch was added / removed, I don't want to have to skim 5000 lines of a changes file manually to find vdr-${cur_ver}-01..42"vdr-${cur_ver}-01..42" even if yes having 40 patches listed in a changes file doesn't look as "pretty" changes files should be about function over prettyness. But I guess we are going to have to agree to disagree, although if as others have said more people agree with you then me the rule could be changed. But don't dismiss the way it is now and not allowing exceptions as completely illogical there is at least a small amount of logic behind it. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 22.06.19 um 13:02 schrieb Richard Brown:

I need to be able to know when a patch was added, and when it was removed. Such changes are one of the most likely causes of packaging or functional problems with a package.

And now go ahead and tell me, when was the last time that you had to look up one of "my" packages because of breakage.

I need to be able to look that up using simple things like filenames in changelogs.

Oh yeah, and next you tell me that you are doing this with automated tools that need to have every single patch listed? The changelog entry was completely clear, there was no room for misinterpretation, and it was much more efficient than 42 lines of patch names. Let's stop it here. Just accept the droprequests and these changelogs will never bother you again. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 22.06.19 um 13:02 schrieb Richard Brown:

I need to be able to know when a patch was added, and when it was removed. Such changes are one of the most likely causes of packaging or functional problems with a package.

And now go ahead and tell me, when was the last time that you had to look up one of "my" packages because of breakage.

I need to be able to look that up using simple things like filenames in changelogs.

Oh yeah, and next you tell me that you are doing this with automated tools that need to have every single patch listed? The changelog entry was completely clear, there was no room for misinterpretation, and it was much more efficient than 42 lines of patch names. Let's stop it here. Just accept the droprequests and these changelogs will never bother you again. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 22/06/2019 13.02, Richard Brown wrote:

I need to be able to know when a patch was added, and when it was removed.

technically, while the patch files were dropped, the patch was not removed, but only moved into the upstream tarball. And that is something the bot (currently) cannot understand and causes frustration for packagers. And also changelogs that are less readable than they could be. So, we have these rules. However, it should be possible to discuss and improve these rules to find the sweet spot where everyone can get work done. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/06/2019 12.16, Christian Boltz wrote:

Just as a crazy idea - could we teach the bot to understand wildcards? With that, we could have a changelog entry like

- removed upstream patches backport-[0-4][0-9]-*

Nice idea. It would then need some known+documented keyword like "patches" in front of it. Btw: Technically, that is a glob, not a regexp. Should it then also support backport-{foo,bar,baz}.patch style lists? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, 2019-06-27 at 15:08 +0200, Marcus Hüwe wrote:

Just to add another idea: instead of "fixing"/extending the existing bot, we could also introduce a new obs-service-doc_patch service:

- a "localonly" service which is automatically executed during "osc ci" - for each removed patch, a corresponding line is added to the *.changes file (so that the bot is happy) (unless a corresponding line/entry, which makes the bot happy, already exists) - for each added patch: analogous

Advantage: - the vdr maintainer could be happy because he can keep his changelog style (at least when adding _new_ entries) - the factory bot is happy

Writing such a service should be (probably) trivial.

Would this help?

I doubt it - the OP is not 'not able to cope with the request of adding patches' (he even received a changelog fixup by a community member for not having to do it himself - request was declined). So he will as much object a script adding the changelogs as he objected doing it himself or having somebody else do it. So, I'd say: don't go waste time writing such an obscure service. Cheers Dominique

On Sat, 22 Jun 2019 13:02:10 +0200 Richard Brown <RBrownCCB@opensuse.org> wrote:

On Sat, 22 Jun 2019 at 12:09, Simon Lees <sflees@suse.de> wrote:

...

No my criticism of what you'd like to do is intentional, as someone who spends a lot of time looking at small things across many many packages I appreciate the fact that there are certain rules all packages follow to make them the same, one such rule is if I am dealing with a large changes file I can put a patches filename into the search field of my editor and find when the patch was added / removed, I don't want to have to skim 5000 lines of a changes file manually to find vdr-${cur_ver}-01..42"vdr-${cur_ver}-01..42" even if yes having 40 patches listed in a changes file doesn't look as "pretty" changes files should be about function over prettyness. But I guess we are going to have to agree to disagree, although if as others have said more people agree with you then me the rule could be changed. But don't dismiss the way it is now and not allowing exceptions as completely illogical there is at least a small amount of logic behind it.

+1

As a release engineer who has regular cause to analyse, debug, and assist on dozens, if not hundreds of packages across the distribution, almost all of which are nominally maintained by other people, there is no way I want to learn all the various anachronistic standards of hundreds of different packagers.

"vdr-${cur_ver}-01..42" might make sense for the VDR maintainer, but there are thousands of packages and they all need to work together and I don't have the time or the inclination to learn every maintainers quirky way of documenting what they're doing.

I need to be able to know when a patch was added, and when it was removed. Such changes are one of the most likely causes of packaging or functional problems with a package. I need to be able to look that up using simple things like filenames in changelogs. Any alternative standard requires more work for maintainers, because I'm going to be less able to help with their package, and with so many packages in the distro, anyone with a package at the bottom of the pile is likely to find it dropped before I can help fix it.

I am not a bot, and the rule that is enforced by the factory-auto bot is for the benefit of contributors like myself and the others like me who work across the entire distribution rather than treating a handful of packages like private little fiefdoms.

Please look at this topic with less ego, and more consideration of the needs of collaboration with others please.

So why don't you as release engineers use OBS to tell you which patch was added and removed when? The patches are added and removed in OBS so OBS already tracks them. No need to duplicate the information in the package changelog. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Freitag, 28. Juni 2019, 02:59:50 CEST schrieb Simon Lees:

On 27/06/2019 23:07, Michal Suchánek wrote:

...

So why don't you as release engineers use OBS to tell you which patch was added and removed when?

OBS's ability to search history is poor to non existent atleast from the webui, where as its quite quick and simple to open the changelog in your browser and hit ctrl+f. I didn't try using obs to search for a patch for rather a long time, so there is a chance its better, but thats just my past experience.

So, this nicely resembles this issues grounds. Due to technical deficits, the system pushes the burden to handle those deficits on the shoulders of packagers/contributors, up to a level, where it *actively* scares them away (due to inflexibility). Such technology defeats its purpose. Where other projects harvest this result due to human incompetence (to cooperate, demonstrate respect, show empathy) like Debian or the Linux Kernel, we do that with numb scripts and numb policy. Either you come up with technology, that *replaces* contributors, or adjust the technology to cooperate with the hands, that it feeds (on an acceptable level). With all due respect, but if I would have to weight the proponents and opponents in this discussion on pure technical grounds, I would weight Seifes' contributions much higher, than those of the proponents. Of course , I'm biased. I'm just a poor openSUSE packager. You proponents might do other valuable work for the project, but from a packager perspective, I see Seifes' contributions everywhere... See, the plain result of this stiff policy is: we lost the maintainer of a subsystem, that isn't very popular, but for those, that use it, it is *essential*. Again, I'm using VDR since 15 years, and guess what, always with openSUSE and its predecessors. I had painful times, translating the debian builds to something palatable for rpm. If nobody steps up, I will take (co-)maintainership of the vdr project, but I would prefer to keep it in the project area and remove it from the distribution, as Stefan strives, since I'm surely not able to sustain the load. It's poor and sad to see, that humanity was defeated by stiff technology/ policy. In fact, like it or not, all humans (who care about openSUSE), suffer from a net loss here. (Read Seifes' signature again) Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday, 28 June 2019 11:23 Dominique Leuenberger / DimStar wrote:

Actually, I want to weigh in here: if said maintainer would not have started off the rambling bot-vs-bot fight and approached the release team like other packagers did in the past: there would very likely have been no issue at all in granting the exception to have the changelog mention 'all patches removed' or similar. We did have such things, especially for packages where the number of patches did grow high and a release managed to squash them all.

First: if you read Stefan mails carefully, you will notice that's what Stefan already tried to do in the most natural way: reopen the request with comment explaining why he believes his changelog entry should be accepted even if the bot disagrees. The fact that such attempt results in request being closed again by the bot within minutes is something that I find personally way worse than the blind and mindless bot rule itself. And any hope that someone notices such reopen and acts upon it is in vain. Second: In the past, I tried to contact responsible people directly when the most natural way didn't work. All I got was various people repeating the mantra "Bot is good, bot knows what it's doing, do what the bot told you." on and on. (Quite a lot like this thread - except that unlike here, there were only the people tied to the system.) Only in one case I won eventually but it took _months_ of effort, spending hours writing to different people, endless frustration and despair. Honestly, I can't blame Stefan for not having the patience. I have to fully support what Hans-Peter wrote: this mindless bot driven management drives maintainers and potential maintainers away from the distribution. It's not only Stefan, I know other people, including SUSE employees who tell me "I'm perfectly happy maintaining the package in my home project but I don't have time and patience for the bureaucracy and constant pestering I would face if I submitted it to Factory. I would love to tell them things are not that bad - but unfortunately I can't. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 2019-06-28 11:51, Michal Kubecek wrote:

On Friday, 28 June 2019 11:23 Dominique Leuenberger / DimStar wrote:

Stefan already tried to do in the most natural way: reopen the request with comment explaining why he believes his changelog entry should be accepted even if the bot disagrees. The fact that such attempt results in request being closed again by the bot within minutes is something that I find personally way worse

Action item #1: Make bot not close requests twice. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2019-06-28 at 12:57 +0200, Axel Braun wrote:

Am Freitag, 28. Juni 2019, 12:49:07 CEST schrieb Jan Engelhardt:

...

On Friday 2019-06-28 11:51, Michal Kubecek wrote:

...

On Friday, 28 June 2019 11:23 Dominique Leuenberger / DimStar wrote:

Stefan already tried to do in the most natural way: reopen the request with comment explaining why he believes his changelog entry should be accepted even if the bot disagrees. The fact that such attempt results in request being closed again by the bot within minutes is something that I find personally way worse

Action item #1: Make bot not close requests twice.

+1

fine by me

and send a mail to a factory maintainer to look and potentially override the bot decision

Thanks, but no thanks - having the bot ask for somebody else for a review instead of doing it himself is sufficient and already triggers mails. There is really no need to spam my inbox with MORE mails coming from the bot directly :) Cheers Dominique

On Fri, 2019-06-28 at 17:59 +0200, Axel Braun wrote:

...

Thanks, but no thanks - having the bot ask for somebody else for a review instead of doing it himself is sufficient and already triggers mails. There is really no need to spam my inbox with MORE mails coming from the bot directly :)

So the Bot tells you already once it rejects a SR?

Yes, it does; granted, I ignore the bots mails when it declines requests, but I also get an email when a user reopens the requests. Cheers Dominique

On Friday, 28 June 2019 12.49.07 CEST Jan Engelhardt wrote:

On Friday 2019-06-28 11:51, Michal Kubecek wrote:

...

On Friday, 28 June 2019 11:23 Dominique Leuenberger / DimStar wrote:

Stefan already tried to do in the most natural way: reopen the request with comment explaining why he believes his changelog entry should be accepted even if the bot disagrees. The fact that such attempt results in request being closed again by the bot within minutes is something that I find personally way worse

Action item #1: Make bot not close requests twice.

I guess that should go into https://github.com/openSUSE/openSUSE-release-tools/issues And I assume https://github.com/openSUSE/openSUSE-release-tools/blob/2b58c022db9094c87879... is the code line with the according check? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Jun 30, 2019 at 04:55:03PM +0930, Simon Lees wrote:

On 28/06/2019 19:21, Michal Kubecek wrote:

...

I have to fully support what Hans-Peter wrote: this mindless bot driven management drives maintainers and potential maintainers away from the distribution. It's not only Stefan, I know other people, including SUSE employees who tell me "I'm perfectly happy maintaining the package in my home project but I don't have time and patience for the bureaucracy and constant pestering I would face if I submitted it to Factory. I would love to tell them things are not that bad - but unfortunately I can't.

Maybe there is a few people in SUSE that feel this way, and do this with there personal projects in there spare time, but everything that SUSE employees do on SUSE's time should be making its way into factory as per SUSE's open source policy.

Well, I wasn't talking about some people's interpretation of certain vaguely formulated policies, I was talking about what things are like in real life. And I tried to tell you what is the real life fallout of some of the policies you advocate for so strongly. It's good to see that you understand there is a problem; but what makes me sad is that you took it from the wrong end again. Rather that thinking about what Factory maintainers could change so that they would not drive potential (and real) packagers away from Factory, your first thought is "Hey, they should not do that on company time!" Disappointing... So if I package, say, Google's packetdrill for openSUSE and SLE so that I and other people can use it for our work but do not feel like going through the ordeal of getting it to Factory and keeping it there, I'm the bad guy. If I didn't do anything, everything would be much better. Is that really what you wanted to say? Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday, 1 July 2019 7:31 Simon Lees wrote:

On 01/07/2019 02:45, Michal Kubecek wrote:

...

Well, I wasn't talking about some people's interpretation of certain vaguely formulated policies, I was talking about what things are like in real life. And I tried to tell you what is the real life fallout of some of the policies you advocate for so strongly. It's good to see that you understand there is a problem; but what makes me sad is that you took it from the wrong end again. Rather that thinking about what Factory maintainers could change so that they would not drive potential (and real) packagers away from Factory, your first thought is "Hey, they should not do that on company time!" Disappointing...

Well that's not what I was trying to do I was more trying to point out that while what you describe might happen in parts of SUSE its not what SUSE is doing in most places and what SUSE as a company is encouraging its employees to do.

Unlike you, I don't dare to guess how big the two parts are and which of them deserves the term "most places". What I'm certain of is that in the parts I'm in closest contact with, it often feels I'm one of the very few who still bother. But if you still insist that what you are doing is for the greater good and we just don't understand it, feel free to go on imposing more loops for others to hop through to make your work easier, keep tightening the screws and driving people away from the project. If the previous paragraph sounds harsh, it's only because you don't hear what some other people say about openSUSE and Factory and their policies and rules and the way they are enforced. It might come as an unpleasant surprise to you (you as plural, not singular). Make no mistake, I'm not happy about that and I would really appreciate if their attitude were different. But as I said, I can't really blame them.

...

So if I package, say, Google's packetdrill for openSUSE and SLE so that I and other people can use it for our work but do not feel like going through the ordeal of getting it to Factory and keeping it there, I'm the bad guy. If I didn't do anything, everything would be much better. Is that really what you wanted to say?

I will disagree that it is an ordeal into getting something into factory, other then the wait on legal reviews I don't tend to have issues at most fixing stuff to be correct generally takes me 5 minutes, maybe that's just because I do it so often that I naturally write packages that comply with our rules, or maybe the kinds of packages I write are different and therefore don't have the same issues.

That's one part of the problem: you are one of the people enforcing the rules so that it's no surprise you find them natural and desirable. One might even notice that the "overall consent" that Stefan is completely wrong and that the he just doesn't understand was from people like that.

If you have examples of "bureaucracy" that you think could be reduced or removed this list is the place to discuss them, although this thread was about a bot blocking a certain style rather then causing someone significantly more effort.

And this is another: whatever example I come with - and the incident which started this thread is a striking example in my (our) eyes - you are going to say it's not an example, it's just a rule and it's a good rule and makes the project better. I might mention that every few months there is a new arbitrary and unnecessary style rule that requires people to rewrite their specfiles and often requires breaking build against SLE (and sometimes even Leap) versions which are still supported; I might even list some really crazy examples; but I have pretty good idea what the reply would be. So I guess I don't have any example - or rather none that you would accept as an example. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 01/07/2019 17:03, Johannes Meixner wrote:

Hello,

On Jul 1 08:14 Michal Kubecek wrote (excerpt):

...

I don't dare to guess how big the two parts are and which of them deserves the term "most places".

Because those who are driven away do no longer count their percentage shrinks while the percentage of those who are left increases until only the latter part is left.

Cf.

https://lists.opensuse.org/opensuse-packaging/2017-07/msg00079.html --------------------------------------------------------------------- In general it seems to be good when openSUSE RPM ... files are in compliance with a reasonable openSUSE standard.

But on the other hand enforcing it could be a hindrance for openSUSE contributors ...

What is more important for openSUSE: Be open for others (and accept diversity) or be uniform (to make maintenance easier)?

Perhaps only for openSUSE core packages (whatever that exactly means - perhaps packages that are also in SLE ?) the RPM spec files and the RPM changelogs must be in compliance with a standard to make maintenance easier?

This is a thread about a certain tool that can be used to clean up spec files, when dealing with a really old package it can be quite useful, but we have no policy that says you must run it and many of the things that it does are helpful rather then policy because at times they can be unhelpful. Personally I don't have the service installed because it can break some things and especially when dealing with maintenance updates it makes changes that are unhelpful, having said that there are times when I need to clean something up and I'll clone it from git and run it manually on a spec file.

---------------------------------------------------------------------

and

https://lists.opensuse.org/opensuse-packaging/2017-07/msg00095.html --------------------------------------------------------------------- What is the benefit for openSUSE users and contributors to enforce a special openSUSE uniformity ... ... What is more important for openSUSE: Be open and accept diversity or enforce uniformity?

Yeah I care less about this one, at the same time I don't recall having to do any work to fix it, the people that care about it did that. So I don't see it as a major issue, the project decided by vote how it should be and i'm happy to respect that I see no reason not to have it uniform and hopefully all the templates etc have been updated so unless you write something from scratch, which you shouldn't it won't be an issue for you. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 01/07/2019 07.31, Simon Lees wrote:

If you have examples of "bureaucracy" that you think could be reduced or removed this list is the place to discuss them, although this thread was about a bot blocking a certain style rather then causing someone significantly more effort.

I remember some years ago kkaempf told the story how he packaged something to build for both Fedora and openSUSE. Fedora accepted the package, openSUSE didnt - because there were some (possibly openSUSE-only) macros that "could have been used". So by striving to have uniform, easy-to-maintain packages we get less packages. And less packagers, too. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 1 Jul 2019 at 10:41, Johannes Meixner <jsmeix@suse.de> wrote:

Hello,

On Jul 1 10:06 Bernhard M. Wiedemann wrote:

...

I remember some years ago kkaempf told the story how he packaged something to build for both Fedora and openSUSE. Fedora accepted the package, openSUSE didnt - because there were some (possibly openSUSE-only) macros that "could have been used".

https://lists.opensuse.org/opensuse-packaging/2017-07/msg00079.html ---------------------------------------------------------------------- In general it seems to be good when openSUSE RPM spec files are in compliance with a reasonable openSUSE standard.

But on the other hand enforcing it could be a hindrance for openSUSE contributors to use ready-made RPM spec files from whatever upstream projects also for openSUSE RPMs with only some minor openSUSE-specific adaptions to get software easily built also for openSUSE.

What is more important for openSUSE: Be open for others (and accept diversity) or be uniform (to make maintenance easier)?

Please don't misuse the important topic of diversity to further your agenda. If diversity is truly your goal, lets aim for diversity of opinions, genders, cultures, etc, not a diversity in package quality.

...

So by striving to have uniform, easy-to-maintain packages we get less packages. And less packagers, too.

In general uniformity does not make life easier for free openSUSE contributors but perhaps uniformity is mainly useful for some special SUSE maintenance people?

The current processes are open to anyone, and the standards have been established through regular iterations by the the diverse openSUSE community, who are also responsible for their implementation. openSUSE's level of engineering excellence is repeatedly cited as a reason many of our users are drawn to our offerings. We should never put that at risk. I notice many of the complainants against the status quo in this thread are SUSE employees who are either expressing opinions or relaying the opinions of others that do not comply with SUSE's Open Source Policy. https://opensource.suse.com/suse-open-source-policy I would recommend that those employees contact their management to discuss their inability to comply or disinterest in following company policy. The benefit or lack thereof a publicly announced company policy is best not discussed on any mailing-list. I would also point out that if the openSUSE community reduced its level of quality and uniformity in the codebase, there is a significant chance that openSUSE's usefulness to SUSE would be directly impacted. An openSUSE with less reliable package quality would require significant extra work by SUSE, probably requiring significantly more effort by the very same employees advocating here for openSUSE to be less consistent in its quality controls. I seems logical to me for both the benefit of SUSE & openSUSE that as much of that work possible should be done early, in the open, and distributed as part of a broader community. I think the only sensible path forward would be for those unhappy with the status quo would be to contribute to improving the automation so it's easier and smoother for contributors while still enforcing openSUSE's current standards. Such contributions are probably best done in the form of pull requests to https://github.com/openSUSE/openSUSE-release-tools rather than continuing this thread. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 1 Jul 2019 at 12:28, Michal Suchánek <msuchanek@suse.de> wrote:

On Mon, 1 Jul 2019 11:05:20 +0200 Richard Brown <RBrownCCB@opensuse.org> wrote:

...

On Mon, 1 Jul 2019 at 10:41, Johannes Meixner <jsmeix@suse.de> wrote:

...

...

...

So by striving to have uniform, easy-to-maintain packages we get less packages. And less packagers, too.

In general uniformity does not make life easier for free openSUSE contributors but perhaps uniformity is mainly useful for some special SUSE maintenance people?

The current processes are open to anyone, and the standards have been established through regular iterations by the the diverse openSUSE community, who are also responsible for their implementation. openSUSE's level of engineering excellence is repeatedly cited as a reason many of our users are drawn to our offerings. We should never put that at risk.

I notice many of the complainants against the status quo in this thread are SUSE employees who are either expressing opinions or relaying the opinions of others that do not comply with SUSE's Open Source Policy.

https://opensource.suse.com/suse-open-source-policy

I would recommend that those employees contact their management to discuss their inability to comply or disinterest in following company policy. The benefit or lack thereof a publicly announced company policy is best not discussed on any mailing-list.

I would also point out that if the openSUSE community reduced its level of quality and uniformity in the codebase, there is a significant chance that openSUSE's usefulness to SUSE would be directly impacted.

I think there is a misrepresentation of SUSE company policy here. Contributions to openSUSE might be desirable but I see no policy that would require that opensource tools used internally by employees should be submitted to openSUSE.

Quoting from the policy: "Our approach to Open Source is “Open Source first, upstream first”. " "We develop in the open and publish our code as Open Source. SUSE products are fully Open Source. There are only rare exceptions where we don’t release code as Open Source. Our development model is designed around Open Source to make it easy for our engineers to produce and contribute to Open Source software." "When SUSE starts new projects we usually publish them as Open Source. The standard place for that is GitHub. We have two principal organizations there: SUSE and openSUSE. For projects which are exclusively maintained by SUSE and where we - as a company - intend to take full responsibility of the project, SUSE is the organization to use. To create new projects under the SUSE organization, contact the administrators of the organization at github-owners@suse.de. For projects which have maintainers or co-maintainers from the community who are not employed by SUSE, or for projects which are open to this model, openSUSE is the organization to use. For openSUSE you can reach the administrators by writing to the public mailing list opensuse-project@opensuse.org." "No matter where the project lives, it will be open for collaboration and contributions from the community under the conditions of the chosen license. The GitHub organization only reflects the model of maintainership." "When packaging new Open Source software or adding changes to existing packages follow the “Factory First” model. “Factory” is the common code stream all our distributions are based on. It is the immediate source for openSUSE Tumbleweed and it eventually ends up in openSUSE Leap and the SUSE Linux Enterprise distributions. This is a continuation of the “Upstream First” principle on the distribution level. It reduces maintenance effort and leverages the community. “Factory First” extends to other SUSE products. Packages for all products should generally come from the common code stream our distributions are based on. So for packages you need in any products contribute them to factory first." or to give a more TL;DR version 1- Almost all code developed by SUSE should be open source 2- All that open source code should be open for collaboration and contributions 3- SUSE-centric locations like github.com/SUSE should only be used when SUSE intends to take full responsibility of the codebase. Else openSUSE-centric locations like github.com/openSUSE should be used. 4- Anything ended up in SLE or SLE based products should be following Factory First I think the vast majority of the internal tools you are discussing currently do not comply with at least one of the four points above, and until those tools are compliant with SUSE's own public policy, I consider that a hindrance to openSUSE. We can split hairs about whether or not SUSE should actively submit the tools to openSUSE - I can agree the policy is not clear on that, but it's debating semantics as long as those tools are not open for collaboration and contribution. If the tools were being handled in compliance with SUSE's Open Source policy then openSUSE could adopt them regardless of what you or I wanted ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 1 Jul 2019 at 13:19, Michal Kubecek <mkubecek@suse.cz> wrote:

On Monday, 1 July 2019 12:43 Richard Brown wrote:

...

1- Almost all code developed by SUSE should be open source 2- All that open source code should be open for collaboration and contributions 3- SUSE-centric locations like github.com/SUSE should only be used when SUSE intends to take full responsibility of the codebase. Else openSUSE-centric locations like github.com/openSUSE should be used. 4- Anything ended up in SLE or SLE based products should be following Factory First

I think the vast majority of the internal tools you are discussing currently do not comply with at least one of the four points above, and until those tools are compliant with SUSE's own public policy, I consider that a hindrance to openSUSE.

We can split hairs about whether or not SUSE should actively submit the tools to openSUSE - I can agree the policy is not clear on that, but it's debating semantics as long as those tools are not open for collaboration and contribution.

I'm afraid you are talking about something different than what I and (the other) Michal meant. We were not talking about internal tools. This was about projects which are open source and publicly available (e.g. on Github) but which do not have packages in Factory.

Many of these projects have actually working and sometimes even well maintained packages for openSUSE and SLE but they are kept in someone's home project (sometimes even in a project which otherwise serves as Factory devel project) but that someone doesn't feel having to deal with Factory review process and bots is worth the extra convenience of having the package "in the distribution".

Fair enough, so then lets talk about non-Factory packages. If a package has not been sent through the Factory process, then it hasn't had the necessary quality or legal reviews, the very reviews which are enforced by the bots being discussed in this thread. The quality reviews are essential for the package to be considered suitable for openSUSE / SUSE in a trademark/copyright sense, which is essential for ensuring the brands remain popular. Our brand is a topic our lists have shown a great interest in lately so I think it's safe to say that regardless as to whether the Project keeps its name or not, the consensus is that the Project shouldn't take unnecessary risks with it's brand. Redistributing unchecked packages, would be a significant risk with potentially catastrophic consequences. The legal reviews are even more important, given the responsibility which SUSE / the openSUSE Project take when redistributing software under various licenses, including the GPL. It risks this projects very existence if we were to inappropriately redistribute software with incompatibly, incompletely, or otherwise non-compliantly with the source code licenses of our packages. What people do in their home project is their own business, but as there is no guarantee a home project package is legally sound, nor that it will be there tomorrow [1], I consider it frankly irresponsible to suggest that approach to software distribution is acceptable. If a package hasn't gone through the Factory process, ie. it is not in either Tumbleweed or Leap, then the package cannot, should not, and must not be considered an output of the openSUSE Project and therefore it's quality and legal correctness cannot be attested to. And I'm pretty sure our users only want software that works and that they can use and redistribute legally... or am I way off the mark with that? [1] https://en.opensuse.org/Terms_of_site#Open_Build_Service_.28the_.E2.80.9CBui... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

It is the norm for tools that are not practical to distribute in a release. Either because you always need the latest version regardless of codestream or because it does not make sense for people other than SUSE employees to use them. The only change your policies make is adding to the list tools that might have been practical to have in a release but due to technical difficulties with keeping them there they fell out or never got in to start with.

It's not the norm for openSUSE nor the SUSE SLE department... ;)

...

If a package hasn't gone through the Factory process, ie. it is not in either Tumbleweed or Leap, then the package cannot, should not, and must not be considered an output of the openSUSE Project and therefore it's quality and legal correctness cannot be attested to.

And I'm pretty sure our users only want software that works and that they can use and redistribute legally... or am I way off the mark with that?

Then let's focus the review on quality of the software and legal issues and not on formalism like listing patch files in the changelog.

Formalism like listing patches is something which makes automated review of quality and legal issues significantly more practable. Without formal tracking of patches, there can easily be changes that invalidate such quality or legal reviews. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/07/2019 02:15, Jan Engelhardt wrote:

On Monday 2019-07-01 18:27, Richard Brown wrote:

...

...

Then let's focus the review on quality of the software and legal issues and not on formalism like listing patch files in the changelog.

Formalism like listing patches is something which makes automated review of quality and legal issues significantly more practable. Without formal tracking of patches, there can easily be changes that invalidate such quality or legal reviews.

This could be implemented as a forced local source service, that is, the same tech that adds # Copyright (c) 2019 SUSE LINUX GmbH, Nuernberg, Germany. to every spec file that is lacking it. That local source service should be able to tell what files have been added and which are deleted, and augment .changes by an autogenerated entry that contains the desired line "Added xx.diff", "Removed xx.diff".

Unfortunately as I stated somewhere else, at the moment in terms of security / bug fixes this isn't complete enough, there needs to be a mapping from patch name to bug number in the .changes file and this is somewhat harder to automate. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 2 Jul 2019 at 08:29, Takashi Iwai <tiwai@suse.de> wrote:

...

Unfortunately as I stated somewhere else, at the moment in terms of security / bug fixes this isn't complete enough, there needs to be a mapping from patch name to bug number in the .changes file and this is somewhat harder to automate.

Hmm.. how it can be different? This is about *.changes, not about patchinfo. I don't understand why the automatic tracking of patch files can be worse.

It really sounds as if you mandate the submission of a hand-written tax declaration at each time -- even if the whole transactions have been tracked online -- just because the tax officer prefers reading the printed papers :)

Simon is talking about the fact that in addition to the patch itself, the motivation for the patch (such as the CVE#/BOO#/BSC# etc) needs to be tracked also. https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_markup_.... And as smart as any automated tool could be, I'm pretty sure it's not going to be able to read the mind of the contributors to know which bug/security ID was the motivation for adding a patch. Automatically handling the removal of the patch should be relatively easier though - assuming the ID is already present the tooling could actually look up the Bug ID and confirm whether or not the bug is closed before allowing the removal of the patch from the specfile - and that could be a nice improvement that'll stop tons of fixed bugs being left open when maintainers forget to close them ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/07/2019 18:12, Takashi Iwai wrote:

On Tue, 02 Jul 2019 10:34:15 +0200, Richard Brown wrote:

...

On Tue, 2 Jul 2019 at 08:29, Takashi Iwai <tiwai@suse.de> wrote:

...

...

Unfortunately as I stated somewhere else, at the moment in terms of security / bug fixes this isn't complete enough, there needs to be a mapping from patch name to bug number in the .changes file and this is somewhat harder to automate.

Hmm.. how it can be different? This is about *.changes, not about patchinfo. I don't understand why the automatic tracking of patch files can be worse.

It really sounds as if you mandate the submission of a hand-written tax declaration at each time -- even if the whole transactions have been tracked online -- just because the tax officer prefers reading the printed papers :)

Simon is talking about the fact that in addition to the patch itself, the motivation for the patch (such as the CVE#/BOO#/BSC# etc) needs to be tracked also. https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_markup_....

And as smart as any automated tool could be, I'm pretty sure it's not going to be able to read the mind of the contributors to know which bug/security ID was the motivation for adding a patch.

That's a different problem. You must put some bugzilla or CVE reference to the changelog, yes. That's mandatory.

However, the mapping between the patch file and the bugzilla/CVE doesn't have to rely on the changelog. Even from the current OBS, you can deduce the changelog entry revision ID as well as the revision ID of patch changes. That is, if the changelog entry contains a bug/CVE reference, this mapping can be obtained automatically from OBS, too.

The problem is some packages may have multiple bug/CVE fixes in one update, and often these bug numbers won't be referenced in the patch because commonly the patch is a direct copy or rebase from upstream and CVE numbers may exist yet or be applicable. Putting CVE's in patch filenames seems pretty common but isn't everywhere, on the other hand I don't recall seeing bugzilla numbers in patch names often. So we could mandate that patch names contain a CVE or bugzilla number where appropriate but I don't think that is the best solution. Teaching osc to ask so it knows could work, then it could do the generation, or packagers could continue listing bug + CVE next to patch names in the changelog. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/07/2019 19:57, Takashi Iwai wrote:

On Tue, 02 Jul 2019 12:02:45 +0200, Simon Lees wrote:

...

On 02/07/2019 18:12, Takashi Iwai wrote:

...

On Tue, 02 Jul 2019 10:34:15 +0200, Richard Brown wrote:

...

On Tue, 2 Jul 2019 at 08:29, Takashi Iwai <tiwai@suse.de> wrote:

...

...

Unfortunately as I stated somewhere else, at the moment in terms of security / bug fixes this isn't complete enough, there needs to be a mapping from patch name to bug number in the .changes file and this is somewhat harder to automate.

Hmm.. how it can be different? This is about *.changes, not about patchinfo. I don't understand why the automatic tracking of patch files can be worse.

It really sounds as if you mandate the submission of a hand-written tax declaration at each time -- even if the whole transactions have been tracked online -- just because the tax officer prefers reading the printed papers :)

Simon is talking about the fact that in addition to the patch itself, the motivation for the patch (such as the CVE#/BOO#/BSC# etc) needs to be tracked also. https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_markup_....

And as smart as any automated tool could be, I'm pretty sure it's not going to be able to read the mind of the contributors to know which bug/security ID was the motivation for adding a patch.

That's a different problem. You must put some bugzilla or CVE reference to the changelog, yes. That's mandatory.

However, the mapping between the patch file and the bugzilla/CVE doesn't have to rely on the changelog. Even from the current OBS, you can deduce the changelog entry revision ID as well as the revision ID of patch changes. That is, if the changelog entry contains a bug/CVE reference, this mapping can be obtained automatically from OBS, too.

The problem is some packages may have multiple bug/CVE fixes in one update, and often these bug numbers won't be referenced in the patch because commonly the patch is a direct copy or rebase from upstream and CVE numbers may exist yet or be applicable. Putting CVE's in patch filenames seems pretty common but isn't everywhere, on the other hand I don't recall seeing bugzilla numbers in patch names often. So we could mandate that patch names contain a CVE or bugzilla number where appropriate but I don't think that is the best solution. Teaching osc to ask so it knows could work, then it could do the generation, or packagers could continue listing bug + CVE next to patch names in the changelog.

But how can you assure this mapping granularity by the changelog? The bot won't help in this regard, because it checks only whether the patches are added / deleted in some entries.

Packages are still manually reviewed by human eyes, the bots just save reviewers time by filtering and rejecting requests that clearly don't follow the guidelines.

More I hear, more convinced I am, that the missing piece is about the meta data handling that should be tied with the file tracking, which definitely has nothing to do with the rpm changelog itself. We're relying too much on the abused text entries...

Yeah agreed, although in some distro's RPM changelogs are intended for developers only, so if openSUSE wants to follow this the info is relevant for changelogs, but it would be good if obs knew about it and auto filled it. But the discussion on what changelogs are for was happening in a different subthread so lets leave that there. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/07/2019 04:13, Christian Boltz wrote:

Hello,

Am Dienstag, 2. Juli 2019, 10:34:15 CEST schrieb Richard Brown:

...

Simon is talking about the fact that in addition to the patch itself, the motivation for the patch (such as the CVE#/BOO#/BSC# etc) needs to be tracked also. https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_ma rkup_.28also_called_.22Tagging_patches.22.29

And as smart as any automated tool could be, I'm pretty sure it's not going to be able to read the mind of the contributors to know which bug/security ID was the motivation for adding a patch.

That's not a reason to force packagers to do everything manually ;-)

Nobody said that the changelog should be written completely automatically (would be perfect, but I'm afraid AI didn't go that far yet).

Nevertheless, "osc vc" could pre-populate the changelog with added, removed and changed patches (saving the packager copy&paste from "osc status"), like it already pre-populates the line with the packager's mail address and the timestamp.

"osc vc" could generate something like this:

------------------------------------------------------------------- Tue Jul 2 18:34:03 UTC 2019 - Pack Ager <packager@example.com>

-

- added fix-foo patch - removed whatever.patch - updated another.patch

-------------------------------------------------------------------

The packager can/should then still edit these lines, for example move the patch names to related hand-written comments and/or add bug and CVE references.

(In theory, a packager can also edit the autogenerated line with the mail address and timestamp, for example if nobody should see that you package after midnight ;-)

Its in UTC anyway, its pretty common for me to be editing packages at midnight yesterday according to the changelog :-), I do like this idea as a short term solution (I like the idea in the other thread more as a long term solution and that one actually resolves the issue in the original post)

...

Automatically handling the removal of the patch should be relatively easier though - assuming the ID is already present the tooling could actually look up the Bug ID and confirm whether or not the bug is closed before allowing the removal of the patch from the specfile - and that could be a nice improvement that'll stop tons of fixed bugs being left open when maintainers forget to close them ;)

I'd hope that _adding_ (not removing) a patch is meant to fix a bug ;-)

Unfortunately your hopes do not always meet with reality -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 1 Jul 2019 at 15:56, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

Am 01.07.19 um 13:34 schrieb Richard Brown:

...

If a package hasn't gone through the Factory process, ie. it is not in either Tumbleweed or Leap, then the package cannot, should not, and must not be considered an output of the openSUSE Project and therefore it's quality and legal correctness cannot be attested to.

open build service.

Not considered an output of the openSUSE Project? -- Stefan Seyfried

For the purposes of legal indemnity, license responsibility, and trademark, the official answer is "No" on the grounds that the packages are not legally or quality reviewed by openSUSE, and are signed by the OBS: private key Fingerprint 660f d3f9 f166 02a3 722a bf6d e842 0ab8 c5c2 19e7 as opposed to the openSUSE Private Key: 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284 The Open Build Service is considered an output of the OBS Team, who obviously contribute to the openSUSE Project, but that doesn't make their work 'ours' in a legal sense. I would be interested in seeing that change. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 1 Jul 2019 at 12:43, Richard Brown <RBrownCCB@opensuse.org> wrote:

or to give a more TL;DR version

1- Almost all code developed by SUSE should be open source 2- All that open source code should be open for collaboration and contributions 3- SUSE-centric locations like github.com/SUSE should only be used when SUSE intends to take full responsibility of the codebase. Else openSUSE-centric locations like github.com/openSUSE should be used. 4- Anything ended up in SLE or SLE based products should be following Factory First

I think the vast majority of the internal tools you are discussing currently do not comply with at least one of the four points above, and until those tools are compliant with SUSE's own public policy, I consider that a hindrance to openSUSE.

We can split hairs about whether or not SUSE should actively submit the tools to openSUSE - I can agree the policy is not clear on that, but it's debating semantics as long as those tools are not open for collaboration and contribution. If the tools were being handled in compliance with SUSE's Open Source policy then openSUSE could adopt them regardless of what you or I wanted ;)

I also want to add that at least in the SLE Department, there is a concerted effort to comply with this policy. This can be seen most obviously in https://github.com/openSUSE/openSUSE-release-tools Which is not only home to many of the bots and automation that led to this thread, but is the same home for many of the bots and automation used by SLE Of course, in the SLE context, most of the time the bots are just confirming that the bots have run properly in the openSUSE context, before then applying any additional SLE criteria - there isn't much..as you can see by examining the sources. That is one of the benefits for both SUSE and openSUSE when SUSE departments really do comply with the wording and the spirit of SUSE's Open Source Policy..both organisations gain the benefits of the work motivated in either. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 01.07.19 um 11:05 schrieb Richard Brown:

Please don't misuse the important topic of diversity to further your agenda. If diversity is truly your goal, lets aim for diversity of opinions,

...as long as it is not the opinion that listing all patch names explicitly in the .changes file is a bad joke... :-P -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2019-07-01 10:06, Bernhard M. Wiedemann wrote:

On 01/07/2019 07.31, Simon Lees wrote:

...

If you have examples of "bureaucracy" that you think could be reduced or removed this list is the place to discuss them, although this thread was about a bot blocking a certain style rather then causing someone significantly more effort.

I remember some years ago kkaempf told the story how he packaged something to build for both Fedora and openSUSE. Fedora accepted the package, openSUSE didnt - because there were some (possibly openSUSE-only) macros that "could have been used".

Sounds a bit vague, but oh well. If you still write `make install DESTDIR=..` in 2019, of course you will be pointed to %make_install. Or to a spec formatter, whichever comes first. openSUSE has a large(?) German involvement, and, stereotypically, we like everything so neat and tidy that it appears bureaucratic to others. But it _is_ tidy, and we are held to such standards if and when they matter (mostly when U+1F4A9 hits a rotating metal blade device ;-).

So by striving to have uniform, easy-to-maintain packages we get less packages. And less packagers, too.

And yet, openSUSE is among the distros with the highest package counts (whether that is good or bad, I'll put aside), so the situation is not too bad. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2019-07-01 15:18, Neal Gompa wrote:

Bad example, %make_install is a standard rpm macro and has been for many years.

And still people... "forget" to use it.

An example is the difference between using %systemd_post and %service_add_post. The former is the cross-distro one implemented in systemd upstream[1]. The latter is the openSUSE specific variant[2]. I use the former, and some people use the latter. In openSUSE, the systemd macros are adjusted to account for openSUSE weirdness as needed. From my point of view, there's virtually no reason for me to use the SUSE-only macro.

%service_* implements some form of upgrade migration, and %systemd_* does not, because that project has... "different priorities" to say it nice.

In fact, I would go so far as to say we should disallow it unless you're packaging sysvinit scripts (which you shouldn't be doing anyway!).

In this age, certainly. But it was different a few years ago.

...

And yet, openSUSE is among the distros with the highest package counts (whether that is good or bad, I'll put aside), so the situation is not too bad.

It has the lowest number of source packages among the major RPM-based Linux distributions. Binary package numbers mean absolutely nothing, since everyone does package splits differently, and even openSUSE is inconsistent on how it does package splits for various reasons.

Source packages likewise don't mean anything, because we are, for example, collecting the 6000-or-so texlive packages in 26 source packages.

* Fedora: 22,003 (current rawhide) * Mageia: 14,672 (core only) * openSUSE: 12,135 (openSUSE:Factory)

I counted 34000 last time (with OBS - as is a fair comparison when everyone else also includes AUR and whatnot). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, 29 Jun 2019 21:15:23 +0930 Simon Lees <sflees@suse.de> wrote:

Hi

On 28/06/2019 18:13, Hans-Peter Jansen wrote:

...

Am Freitag, 28. Juni 2019, 02:59:50 CEST schrieb Simon Lees:

...

On 27/06/2019 23:07, Michal Suchánek wrote:

...

So why don't you as release engineers use OBS to tell you which patch was added and removed when?

OBS's ability to search history is poor to non existent atleast from the webui, where as its quite quick and simple to open the changelog in your browser and hit ctrl+f. I didn't try using obs to search for a patch for rather a long time, so there is a chance its better, but thats just my past experience.

So, this nicely resembles this issues grounds. Due to technical deficits, the system pushes the burden to handle those deficits on the shoulders of packagers/contributors, up to a level, where it *actively* scares them away (due to inflexibility).

Such technology defeats its purpose.

Where other projects harvest this result due to human incompetence (to cooperate, demonstrate respect, show empathy) like Debian or the Linux Kernel, we do that with numb scripts and numb policy.

Either you come up with technology, that *replaces* contributors, or adjust the technology to cooperate with the hands, that it feeds (on an acceptable level).

With all due respect, but if I would have to weight the proponents and opponents in this discussion on pure technical grounds, I would weight Seifes' contributions much higher, than those of the proponents. Of course , I'm biased. I'm just a poor openSUSE packager. You proponents might do other valuable work for the project, but from a packager perspective, I see Seifes' contributions everywhere...

See, the plain result of this stiff policy is: we lost the maintainer of a subsystem, that isn't very popular, but for those, that use it, it is *essential*. Again, I'm using VDR since 15 years, and guess what, always with openSUSE and its predecessors. I had painful times, translating the debian builds to something palatable for rpm.

If nobody steps up, I will take (co-)maintainership of the vdr project, but I would prefer to keep it in the project area and remove it from the distribution, as Stefan strives, since I'm surely not able to sustain the load.

It's poor and sad to see, that humanity was defeated by stiff technology/ policy. In fact, like it or not, all humans (who care about openSUSE), suffer from a net loss here. (Read Seifes' signature again)

As someone who works on SUSE's packaging team and therefore does a lot of packaging, i'm going to broadly disagree with this. In my eyes these standards and guidelines are no different to software projects that have coding style guidelines. These are common across both commercial and open source projects and its almost impossible to find one that everyone agrees with 100% because much of it is personal taste but people put there personal taste aside to create a uniform set of rules. Sure occasionally they alienate people who can't stand to put there personal style and preference aside to use what the project has decided on but many projects see the uniformity that these rules bring as a bigger upside.

Like openSUSE's bots its quite common for these rules to be enforced by git commit hooks or git integration hooks that block merging requests that don't comply. So in short this is common practice in many projects, in each of those you will find people that think the way its done is dumb in some ways but accept such things as the cost of making everything somewhat unified.

Please don't muddle the issue. This rule exists only to paper over OBS deficiency. The storage which OBS uses for the package files is specific to OBS, is not searchable, cannot be mirrored to developer machine to process offline, etc. You would not need to uniformly mark patch changes in the changelog if the information was readily available from the storage backend that holds the package files. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 30.06.19 um 09:30 schrieb Simon Lees:

Maybe for packages I work on all the time, but when i'm not it'd still be far quicker and easier for me to pull it out of the changelog on the web ui,

The "Changelog in the web ui" shows the commit message. I personally would be much less opposed putting lots of patchnames into the commit message, but commit messages are not enforced *at all*. Then your workflow would be git-osc log => /patchname git-osc show $VERSION_HASH and you would immediately see where and when the patch was removed by whom, including all context. In case of a patch added it would just be git-osc blame foo.spec => /patchname git-osc show $VERSION_HASH This would be the place they belong to: someone doing maintenance work can look for them, search them (hopefully), and normal users can still get clean package changelogs (in the .changes file). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30/06/2019 22:50, Stefan Seyfried wrote:

Am 30.06.19 um 09:30 schrieb Simon Lees:

...

Maybe for packages I work on all the time, but when i'm not it'd still be far quicker and easier for me to pull it out of the changelog on the web ui,

The "Changelog in the web ui" shows the commit message. I personally would be much less opposed putting lots of patchnames into the commit message, but commit messages are not enforced *at all*.

Then your workflow would be

git-osc log => /patchname git-osc show $VERSION_HASH

and you would immediately see where and when the patch was removed by whom, including all context.

In case of a patch added it would just be

git-osc blame foo.spec => /patchname git-osc show $VERSION_HASH

This would be the place they belong to: someone doing maintenance work can look for them, search them (hopefully), and normal users can still get clean package changelogs (in the .changes file).

Some of this comes back to a question of who should .changes files be aimed at and I guess more broadly if we had a good vcs do we actually need manually generated changelogs, with the right vcs these days we could almost just ship a URL + revision. In the context of SLE / Leap updates currently the changelog is not the best place for end users to read about changes because the maintenance team takes the changes entry and converts it into a _patchinfo, which partly involves taking the .changes entry and making it more readable for end users, this info is then presented nicely in tools like the yast updater. I think the big issue here is that since the invention of tumbleweed .changes files have to cater for both users and developers so you trying to write a neat tidy changelog for users to read which minimizes the importants of specific patches which I as a developer maybe interested in. Perhaps instead we should be looking at creating a different system for developers to put the information that's important to users like we currently have for _patchinfo files and generate a .changes / obs history entry from that and other info automatically. Potentially the hardest thing here is lining up patch filenames with bugzilla / CVE entries, because generally the main reason I'd continue to currently look in a changes file is because generally you can see which patch in a change corresponds to which bug, it's very common to take patches directly from upstream git repo's and as such they won't contain the openSUSE specific bug number, currently the most reliable way to find this info is by looking at the .changes file which should list the patch name and bug number in the same line. This is something that needs to be done by the packager but isn't info that is useful for end users. Sometimes its easy to guess because some packagers put the CVE or bug number in the patch name, or above the PatchX: line in the spec file and sometimes the patch description will contain bsc# or boo# but we have no constant rule here so its hard to automate. Maybe one solution would be for osc to prompt you to enter a bugzilla number when you add a .patch file, then the changes file could be generated from the provided "user info" and other data. Maybe it could even be dropped, but this would require "git-osc" or whatever it became being able to accurately track changes across branches and projects where needed. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2019-07-01 14:16, Neal Gompa wrote:

Perhaps it'd be better if we could untangle the information that the changelog provides and split out the user-facing parts into the updateinfo, because that's the stuff people can _see_ from the tools (dnf updateinfo, zypper patch, YaST, Spacewalk/Uyuni, Foreman, etc.). It's much easier to access and act on, as well.

Hm. It is quite the reverse for me: * zypper dup/up * let it install * if something broke, check `rpm -q --changelog xyz` for a mention I am not sure `zypper patch` is still "useful" after the update has already been applied; let alone that it is not implemented for Tumbleweed where updates don't come as OBS maintenance_updates, but as regular new files-on-a-mirror. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 01/07/2019 22:16, Neal Gompa wrote:

On Mon, Jul 1, 2019 at 8:43 AM Jan Engelhardt <jengelh@inai.de> wrote:

...

On Monday 2019-07-01 14:16, Neal Gompa wrote:

...

Perhaps it'd be better if we could untangle the information that the changelog provides and split out the user-facing parts into the updateinfo, because that's the stuff people can _see_ from the tools (dnf updateinfo, zypper patch, YaST, Spacewalk/Uyuni, Foreman, etc.). It's much easier to access and act on, as well.

Hm. It is quite the reverse for me: * zypper dup/up * let it install * if something broke, check `rpm -q --changelog xyz` for a mention

I am not sure `zypper patch` is still "useful" after the update has already been applied; let alone that it is not implemented for Tumbleweed where updates don't come as OBS maintenance_updates, but as regular new files-on-a-mirror.

updateinfo != maintenance updates model. Nothing in particular about updateinfo requires that model. Admittedly, I'm not sure if OBS forces that model for generating updateinfo, but I was hoping not...

As for zypper patch, I would imagine there's a way to list applied patches like there is for listing applied advisories in DNF.

I'm not sure if it lists patches by patch name, but they contain meta data to easily list bug and CVE numbers + titles. Which unlike patch names should make sense to developers. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Simon Lees composed on 2019-06-22 19:39 (UTC+0930): ...

I don't want to have to skim 5000 lines of a changes file manually to find vdr-${cur_ver}-01..42"vdr-${cur_ver}-01..42" even if yes having 40 patches listed in a changes file doesn't look as "pretty" changes files should be about function over prettyness.

So how is function over form different with fonts for a basic installtion??? You marked https://bugzilla.opensuse.org/show_bug.cgi?id=992519 onerous font package requirements fixed, after I filed it on your request. https://lists.opensuse.org/opensuse-factory/2016-08/msg00133.html Nothing was changed that amounts to improvement: ## TW host t2240 # zypper ll # | Name | Type | Repository ---+--------------------------+---------+----------- 6 | adobe-source*fonts | package | (any) 7 | apparmor* | package | (any) 9 | cantarell-font* | package | (any) 11 | firewal* | package | (any) 13 | glibc-local? | package | (any) 14 | google-opensans-font* | package | (any) 16 | hack-font* | package | (any) 18 | intlfonts* | package | (any) 32 | noto-sans* | package | (any) 33 | os-prober | package | (any) # zypper -v dup Verbosity: 2 Initializing Target Checking whether to refresh... Computing upgrade... 7 Problems: Problem: ghostscript-9.27-2.3.i586 requires apparmor-abstractions, but this requirement cannot be provided Problem: gtk3-metatheme-adwaita-3.28-1.6.noarch requires cantarell-fonts, but this requirement cannot be provided Problem: libyui-ncurses9-2.50.4-2.3.i586 requires glibc-locale, but this requirement cannot be provided Problem: plasma5-integration-plugin-5.16.0-1.1.i586 requires hack-fonts, but this requirement cannot be provided Problem: yast2-qt-branding-openSUSE-84.87.20180403-1.5.noarch requires adobe-sourcesanspro-fonts, but this requirement cannot be provided Problem: ghostscript-x11-9.27-2.3.i586 requires ghostscript = 9.27-2.3, but this requirement cannot be provided Problem: ghostscript-9.27-2.3.i586 requires apparmor-abstractions, but this requirement cannot be provided not installable providers: apparmor-abstractions-2.13.2-9.2.noarch[OSS] Solution 1: Following actions will be done: deinstallation of ghostscript-9.27-2.2.i586 deinstallation of groff-full-1.22.4-2.3.i586 deinstallation of cups-filters-1.22.5-1.3.i586 deinstallation of OpenPrintingPPDs-ghostscript-4.0.0.2-4.6.noarch deinstallation of gxditview-1.22.4-2.3.i586 deinstallation of OpenPrintingPPDs-postscript-4.0.0.2-4.6.noarch Solution 2: keep obsolete ghostscript-9.27-2.2.i586 Solution 3: remove lock to allow installation of apparmor-abstractions-2.13.2-9.2.noarch[OSS] Solution 4: break ghostscript-9.27-2.3.i586 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4 Problem: gtk3-metatheme-adwaita-3.28-1.6.noarch requires cantarell-fonts, but this requirement cannot be provided not installable providers: cantarell-fonts-0.111-1.4.noarch[OSS] Solution 1: deinstallation of gtk3-metatheme-adwaita-3.28-1.5.noarch Solution 2: keep obsolete gtk3-metatheme-adwaita-3.28-1.5.noarch Solution 3: remove lock to allow installation of cantarell-fonts-0.111-1.4.noarch[OSS] Solution 4: break gtk3-metatheme-adwaita-3.28-1.6.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4 Problem: libyui-ncurses9-2.50.4-2.3.i586 requires glibc-locale, but this requirement cannot be provided not installable providers: glibc-locale-2.29-6.3.i586[OSS] Solution 1: Following actions will be done: deinstallation of libyui-ncurses9-2.50.4-2.2.i586 deinstallation of yast2-4.2.3-1.3.i586 deinstallation of libyui9-3.4.2-3.3.i586 deinstallation of libyui-ncurses-pkg9-2.48.9-2.3.i586 deinstallation of autoyast2-installation-4.2.0-1.3.noarch deinstallation of yast2-add-on-4.1.12-1.3.noarch deinstallation of yast2-auth-client-4.1.1-1.3.noarch deinstallation of yast2-bootloader-4.2.1-1.3.i586 deinstallation of yast2-configuration-management-4.1.6-1.3.noarch deinstallation of yast2-control-center-4.1.8-1.3.i586 deinstallation of yast2-country-4.1.12-1.3.i586 deinstallation of yast2-firstboot-4.1.7-1.3.noarch deinstallation of yast2-installation-4.2.4-1.3.noarch deinstallation of yast2-ldap-4.1.0-1.4.i586 deinstallation of yast2-metapackage-handler-4.1.0-1.3.noarch deinstallation of yast2-network-4.2.2-1.3.noarch deinstallation of yast2-nfs-client-4.1.5-1.3.noarch deinstallation of yast2-nfs-server-4.1.0-1.3.noarch deinstallation of yast2-packager-4.2.7-1.3.i586 deinstallation of yast2-pam-4.2.3-1.3.noarch deinstallation of yast2-printer-4.1.1-1.3.i586 deinstallation of yast2-proxy-4.1.0-1.3.noarch deinstallation of yast2-samba-client-4.2.1-1.3.noarch deinstallation of yast2-samba-server-4.1.3-1.4.noarch deinstallation of yast2-security-4.1.2-1.4.noarch deinstallation of yast2-services-manager-4.1.15-1.3.noarch deinstallation of yast2-slp-4.1.0-1.4.i586 deinstallation of yast2-sound-4.1.1-1.5.i586 deinstallation of yast2-storage-ng-4.2.16-1.3.i586 deinstallation of yast2-update-4.2.2-1.3.i586 deinstallation of yast2-users-4.2.1-1.3.i586 deinstallation of yast2-ycp-ui-bindings-4.1.0-1.6.i586 deinstallation of libyui-qt9-2.49.16-2.3.i586 deinstallation of libyui-qt-pkg9-2.45.27-2.3.i586 deinstallation of libyui-qt-graph9-2.44.9-3.3.i586 deinstallation of libksuseinstall1-4.14.38-7.4.i586 deinstallation of yast2-control-center-qt-4.1.8-1.3.i586 deinstallation of yast2-ruby-bindings-4.2.1-1.3.i586 deinstallation of yast2-python3-bindings-4.1.1-1.3.i586 deinstallation of yast2-perl-bindings-4.1.0-1.3.i586 deinstallation of patterns-base-x11-20190206-5.3.i586 remove lock to allow removal of kdm-4.11.22-15.1.i586 deinstallation of libkde4-4.14.38-7.4.i586 deinstallation of yast2-hardware-detection-4.1.0-1.3.i586 deinstallation of yast2-country-data-4.1.12-1.3.i586 deinstallation of yast2-transfer-4.1.0-1.4.i586 deinstallation of kwin-4.11.22-17.3.i586 deinstallation of krandr-4.11.22-17.3.i586 deinstallation of kdelibs4-core-4.14.38-7.4.i586 deinstallation of kdelibs4-4.14.38-7.4.i586 deinstallation of kdebase4-workspace-libs-4.11.22-17.3.i586 deinstallation of kdebase4-workspace-liboxygenstyle-4.11.22-17.3.i586 deinstallation of kdebase4-workspace-addons-4.11.22-17.3.i586 deinstallation of kdebase4-runtime-17.08.3-6.7.i586 deinstallation of kde4-kgreeter-plugins-4.11.22-17.3.i586 Solution 2: keep obsolete libyui-ncurses9-2.50.4-2.2.i586 Solution 3: remove lock to allow installation of glibc-locale-2.29-6.3.i586[OSS] Solution 4: break libyui-ncurses9-2.50.4-2.3.i586 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4 Problem: plasma5-integration-plugin-5.16.0-1.1.i586 requires hack-fonts, but this requirement cannot be provided not installable providers: hack-fonts-3.003-1.4.noarch[OSS] Solution 1: Following actions will be done: remove lock to allow installation of hack-fonts-3.003-1.4.noarch[OSS] remove lock to allow installation of noto-sans-fonts-20170919-3.3.noarch[OSS] Solution 2: Following actions will be done: deinstallation of plasma5-integration-plugin-5.15.5-1.2.i586 deinstallation of frameworkintegration-plugin-5.58.2-1.3.i586 deinstallation of plasma5-workspace-5.16.0-1.1.i586 deinstallation of plasma5-session-5.16.0-1.1.noarch deinstallation of plasma5-desktop-5.16.0-1.1.i586 Solution 3: keep obsolete plasma5-integration-plugin-5.15.5-1.2.i586 Solution 4: break plasma5-integration-plugin-5.16.0-1.1.i586 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4 Problem: yast2-qt-branding-openSUSE-84.87.20180403-1.5.noarch requires adobe-sourcesanspro-fonts, but this requirement cannot be provided not installable providers: adobe-sourcesanspro-fonts-2.045-1.1.noarch[OSS] Solution 1: Following actions will be done: remove lock to allow installation of adobe-sourcesanspro-fonts-2.045-1.1.noarch[OSS] remove lock to allow installation of google-opensans-fonts-20180610-1.4.noarch[OSS] Solution 2: Following actions will be done: deinstallation of yast2-qt-branding-openSUSE-84.87.20180403-1.2.noarch deinstallation of yast2-theme-4.2.2-1.3.noarch deinstallation of yast2-x11-4.1.0-1.4.i586 Solution 3: keep obsolete yast2-qt-branding-openSUSE-84.87.20180403-1.2.noarch Solution 4: break yast2-qt-branding-openSUSE-84.87.20180403-1.5.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4 Problem: ghostscript-x11-9.27-2.3.i586 requires ghostscript = 9.27-2.3, but this requirement cannot be provided not installable providers: ghostscript-9.27-2.3.i586[OSS] Solution 1: deinstallation of ghostscript-x11-9.27-2.2.i586 Solution 2: keep obsolete ghostscript-x11-9.27-2.2.i586 Solution 3: remove lock to allow installation of apparmor-parser-2.13.2-9.2.i586[OSS] Solution 4: break ghostscript-x11-9.27-2.3.i586 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4 Resolving dependencies... Computing distribution upgrade... Force resolution: No Computing upgrade... Problem: man-2.8.4-3.3.i586 requires glibc-locale, but this requirement cannot be provided not installable providers: glibc-locale-2.29-6.3.i586[OSS] Solution 1: deinstallation of man-2.8.4-3.2.i586 Solution 2: keep obsolete man-2.8.4-3.2.i586 Solution 3: remove lock to allow installation of glibc-locale-2.29-6.3.i586[OSS] Solution 4: break man-2.8.4-3.3.i586 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/c] (c): 4 Applying solution 4 Resolving dependencies... Computing distribution upgrade... Force resolution: No Computing upgrade... Problem: mtools-4.0.23-1.4.i586 requires glibc-locale, but this requirement cannot be provided not installable providers: glibc-locale-2.29-6.3.i586[OSS] Solution 1: Following actions will be done: deinstallation of mtools-4.0.23-1.3.i586 deinstallation of gfxboot-4.5.50-1.3.i586 deinstallation of gfxboot-branding-openSUSE-84.87.20180403-1.5.noarch Solution 2: keep obsolete mtools-4.0.23-1.3.i586 Solution 3: remove lock to allow installation of glibc-locale-2.29-6.3.i586[OSS] Solution 4: break mtools-4.0.23-1.4.i586 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/c] (c): 4 Applying solution 4 Resolving dependencies... Computing distribution upgrade... Force resolution: No Computing upgrade... The following 323 items are locked and will not be changed by any action: Available: ... Installed: ... Run 'zypper locks -s' to see the complete list of locked items. The following NEW package is going to be installed: libevent-2_1-10 2.1.10-1.1 The following 6 packages are going to be REMOVED: libcupscgi1 2.3b4-3.3 libcupsmime1 2.3b4-3.3 libcupsppdc1 2.3b4-3.3 libevent-2_1-8 2.1.8-3.3 libiptc0 1.8.2-2.2 pciutils-ids 20180625-1.1 The following 9 packages are going to be upgraded: ghostscript 9.27-2.2 -> 9.27-2.3 ghostscript-x11 9.27-2.2 -> 9.27-2.3 gtk3-metatheme-adwaita 3.28-1.5 -> 3.28-1.6 hwdata 0.314-1.1 -> 0.323-1.3 libyui-ncurses9 2.50.4-2.2 -> 2.50.4-2.3 man 2.8.4-3.2 -> 2.8.4-3.3 mtools 4.0.23-1.3 -> 4.0.23-1.4 plasma5-integration-plugin 5.15.5-1.2 -> 5.16.0-1.1 yast2-qt-branding-openSUSE 84.87.20180403-1.2 -> 84.87.20180403-1.5 9 packages to upgrade, 1 new, 6 to remove. Overall download size: 17.0 MiB. Already cached: 0 B. After the operation, 1.2 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): y committing Checking for file conflicts: ....................................................................................[done] Warning: Checking for file conflicts requires not installed packages to be downloaded in advance in order to access their file lists. See option '--download-in-advance' in the zypper manual page for details. The following 10 packages had to be excluded from file conflicts check because they are not yet downloaded: ... ...CommitResult (total 15, done 15, error 0, skipped 0, updateMessages 0) Checking for running processes using deleted libraries... There are some running programs that might use files deleted by recent upgrade. You may wish to check and restart some of them. Run 'zypper ps -s' to list these programs. Core libraries or services have been updated. Reboot is required to ensure that your system benefits from these updates. # # uname -a Linux gb250 5.0.13-1-default #1 SMP Sun May 5 15:48:04 UTC 2019 (b11e2d7) x86_64 x86_64 x86_64 GNU/Linux # zypper -v dup Verbosity: 2 Initializing Target Checking whether to refresh metadata for MozillaLegacy Checking whether to refresh metadata for MozillaTW Checking whether to refresh metadata for Non-OSS Checking whether to refresh metadata for OSS Checking whether to refresh metadata for Update Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... Force resolution: No Computing upgrade... Problem: libyui-ncurses9-2.50.4-2.3.x86_64 requires glibc-locale, but this requirement cannot be provided not installable providers: glibc-locale-2.29-6.3.i586[OSS] glibc-locale-2.29-6.3.x86_64[OSS] Solution 1: Following actions will be done: remove lock to allow installation of glibc-locale-2.29-6.3.i586[OSS] install glibc-locale-2.29-6.3.i586 despite the inferior architecture Solution 2: Following actions will be done: deinstallation of libyui-ncurses9-2.50.4-2.1.x86_64 deinstallation of yast2-sysconfig-4.1.2-1.4.noarch deinstallation of yast2-security-4.1.2-1.4.noarch deinstallation of yast2-proxy-4.1.0-1.3.noarch deinstallation of yast2-pam-4.2.3-1.3.noarch deinstallation of yast2-nfs-server-4.1.0-1.3.noarch deinstallation of yast2-nfs-client-4.1.5-1.3.noarch deinstallation of yast2-network-4.2.2-1.3.noarch deinstallation of yast2-metapackage-handler-4.1.0-1.3.noarch deinstallation of yast2-journal-4.2.0-1.3.noarch deinstallation of yast2-auth-client-4.1.1-1.3.noarch Solution 3: keep obsolete libyui-ncurses9-2.50.4-2.1.x86_64 Solution 4: remove lock to allow installation of glibc-locale-2.29-6.3.x86_64[OSS] Solution 5: break libyui-ncurses9-2.50.4-2.3.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/5/c] (c): 5 Applying solution 5 Resolving dependencies... Computing distribution upgrade... Force resolution: No Computing upgrade... Problem: man-2.8.4-3.3.x86_64 requires glibc-locale, but this requirement cannot be provided not installable providers: glibc-locale-2.29-6.3.i586[OSS] glibc-locale-2.29-6.3.x86_64[OSS] Solution 1: Following actions will be done: remove lock to allow installation of glibc-locale-2.29-6.3.i586[OSS] install glibc-locale-2.29-6.3.i586 despite the inferior architecture Solution 2: deinstallation of man-2.8.4-3.1.x86_64 Solution 3: keep obsolete man-2.8.4-3.1.x86_64 Solution 4: remove lock to allow installation of glibc-locale-2.29-6.3.x86_64[OSS] Solution 5: break man-2.8.4-3.3.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/5/c] (c): 5 Applying solution 5 Resolving dependencies... Computing distribution upgrade... Force resolution: No Computing upgrade... Problem: mtools-4.0.23-1.4.x86_64 requires glibc-locale, but this requirement cannot be provided not installable providers: glibc-locale-2.29-6.3.i586[OSS] glibc-locale-2.29-6.3.x86_64[OSS] Solution 1: Following actions will be done: remove lock to allow installation of glibc-locale-2.29-6.3.i586[OSS] install glibc-locale-2.29-6.3.i586 despite the inferior architecture Solution 2: Following actions will be done: deinstallation of mtools-4.0.23-1.2.x86_64 deinstallation of gfxboot-branding-openSUSE-84.87.20180403-1.5.noarch Solution 3: keep obsolete mtools-4.0.23-1.2.x86_64 Solution 4: remove lock to allow installation of glibc-locale-2.29-6.3.x86_64[OSS] Solution 5: break mtools-4.0.23-1.4.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/5/c] (c): 5 Applying solution 5 Resolving dependencies... Computing distribution upgrade... Force resolution: No Computing upgrade... Problem: rpm-build-4.14.2.1-5.4.x86_64 requires glibc-locale, but this requirement cannot be provided not installable providers: glibc-locale-2.29-6.3.i586[OSS] glibc-locale-2.29-6.3.x86_64[OSS] Solution 1: Following actions will be done: remove lock to allow installation of glibc-locale-2.29-6.3.i586[OSS] install glibc-locale-2.29-6.3.i586 despite the inferior architecture Solution 2: Following actions will be done: deinstallation of rpm-build-4.14.2.1-5.1.x86_64 deinstallation of rpmrebuild-2.14-1.4.noarch Solution 3: keep obsolete rpm-build-4.14.2.1-5.1.x86_64 Solution 4: remove lock to allow installation of glibc-locale-2.29-6.3.x86_64[OSS] Solution 5: break rpm-build-4.14.2.1-5.4.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/5/c] (c): 5 Applying solution 5 Resolving dependencies... Computing distribution upgrade... Force resolution: No Computing upgrade... The following 154 items are locked and will not be changed by any action: Available: ... Installed: ... Run 'zypper locks -s' to see the complete list of locked items. The following NEW package is going to be installed: libevent-2_1-10 2.1.10-1.1 The following package is going to be REMOVED: libevent-2_1-8 2.1.8-3.2 The following 4 packages are going to be upgraded: libyui-ncurses9 2.50.4-2.1 -> 2.50.4-2.3 man 2.8.4-3.1 -> 2.8.4-3.3 mtools 4.0.23-1.2 -> 4.0.23-1.4 rpm-build 4.14.2.1-5.1 -> 4.14.2.1-5.4 4 packages to upgrade, 1 new, 1 to remove. Overall download size: 1.8 MiB. Already cached: 0 B. After the operation, additional 32.8 KiB will be used. Continue? [y/n/v/...? shows all options] (y): y committing ... Checking for running processes using deleted libraries... There are some running programs that might use files deleted by recent upgrade. You may wish to check and restart some of them. Run 'zypper ps -s' to list these programs. Core libraries or services have been updated. Reboot is required to ensure that your system benefits from these updates. # df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc7 8061880 4722900 2912996 62% / # zypper ll | grep fonts 5 | adobe-source*-fonts | package | (any) 6 | agfa-fonts | package | (any) 18 | intlfonts* | package | (any) 19 | kde-oxygen-fonts | package | (any) # rpm -qa | grep fonts | grep noarch | sort agfa-fonts-2003.03.19-94.noarch dejavu-fonts-2.37-1.8.noarch fonts-config-20190119-1.2.noarch google-droid-fonts-20121204-5.12.noarch liberation-fonts-1.07.4-2.3.noarch linux-libertine-fonts-5.3.0-8.11.noarch xorg-x11-fonts-7.6-35.3.noarch xorg-x11-fonts-core-7.6-35.3.noarch # zypper -v dup ... Problem: yast2-qt-branding-openSUSE-84.87.20180403-1.2.noarch requires adobe-sourcesanspro-fonts, but this requirement cannot be provided not installable providers: adobe-sourcesanspro-fonts-2.020-1.11.noarch[OSS] Solution 1: Following actions will be done: remove lock to allow installation of adobe-sourcesanspro-fonts-2.020-1.11.noarch[OSS] remove lock to allow installation of google-opensans-fonts-20180610-1.3.noarch[OSS] Solution 2: Following actions will be done: deinstallation of yast2-qt-branding-openSUSE-84.87.20180403-1.1.noarch deinstallation of yast2-theme-4.2.2-1.2.noarch deinstallation of kdebase3-SuSE-lang-11.3-100.1.noarch Solution 3: keep obsolete yast2-qt-branding-openSUSE-84.87.20180403-1.1.noarch Solution 4: break yast2-qt-branding-openSUSE-84.87.20180403-1.2.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4 ... The following 30 packages are going to be upgraded: ... yast2-qt-branding-openSUSE 84.87.20180403-1.1 -> 84.87.20180403-1.2 30 packages to upgrade, 1 to downgrade, 4 new, 4 to remove, 1 to change vendor. Overall download size: 24.3 MiB. Already cached: 81.1 MiB. After the operation, additional 2.0 MiB will be used. Note: System reboot required. Continue? [y/n/v/...? shows all options] (y): y committing ... Checking for running processes using deleted libraries... There are some running programs that might use files deleted by recent upgrade. You may wish to check and restart some of them. Run 'zypper ps -s' to list these programs. Core libraries or services have been updated. Reboot is required to ensure that your system benefits from these updates. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Brüns composed on 2019-06-22 19:16 (UTC+0200):

Felix Miata wrote:

...

Simon Lees composed on 2019-06-22 19:39 (UTC+0930): ...

...

vdr-${cur_ver}-01..42"vdr-${cur_ver}-01..42" even if yes having 40 patches listed in a changes file doesn't look as "pretty" changes files should be about function over prettyness.

...

So how is function over form different with fonts for a basic installtion??? You marked

Stop highjacking threads to spread your personal issues issues ...

The thread Ignacio started as I interpret it is about perceived bloat caused by arguably miscategorized requires, prettiness trumping functionality, connecting unconnected dots that should be connected, disconnecting dots that should not be connected, IMO a macroscopic topic. Quoting OP: "I really want to openSUSE to improve in this matter." This was my intent as well, not so much because of personal preference as because of fonts' inherent accessibility/usability issues. ...

...

Problem: ghostscript-9.27-2.3.i586 requires apparmor-abstractions, but this ... Solution 3: remove lock to allow installation of apparmor-abstractions-2.13.2-9.2.noarch[OSS] Solution 4: break ghostscript-9.27-2.3.i586 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4

The correct choice matching upstream openSUSE would have been (3). You chose

On the contrary, if apparmo* is not already installed, there is no reason I can imagine to introduce apparmor-* as a consequence of an update to another app that that particular installation has no use for (ghostscript).

otherwise, which you are free to do, but please stop bothering other people with issues you have with your home grown distribution, which less and less resembles anything that can be honestly called openSUSE.

It's part of a secondary process of keeping manageable too many unique openSUSE installations to keep track of, spending as little time as possible waiting for updates and upgrades to things never used, or diversions interfering with isolation of problems missed by upstream, or robotic QA, which can be no better than the coders of the robots. Robots don't test what they are not programmed to test. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, Am Sonntag, 23. Juni 2019, 01:46:09 CEST schrieb Felix Miata:

Stefan Brüns composed on 2019-06-22 19:16 (UTC+0200):

...

Felix Miata wrote:

...

...

Problem: ghostscript-9.27-2.3.i586 requires apparmor-abstractions, but this ...

...

...

Solution 3: remove lock to allow installation of apparmor-abstractions-2.13.2-9.2.noarch[OSS] Solution 4: break ghostscript-9.27-2.3.i586 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4

The correct choice matching upstream openSUSE would have been (3). You chose On the contrary, if apparmo* is not already installed, there is no reason I can imagine to introduce apparmor-* as a consequence of an update to another app that that particular installation has no use for (ghostscript).

There's a reason for this dependency - since some months, we have an AppArmor profile for ghostscript and it's helper scripts (ps2pdf etc.). Yes. technically ghostscript also works without the AppArmor profile, but you'll lack protection against evil files that trigger executing another program unintentionally. I'm probably biased on this ;-) but I'd argue that something that makes ghostscript more secure clearly qualifies for a "Requires". Regards, Christian Boltz --

Weil es seit Jahrzehnten ging? Ich denke wir beide haben sehr unterschiedliche Definitionen von "geht". Ne Pferdekutsche "geht" auch, trotzdem fahren die meisten eher Auto. [> Stephan von Krawczynski und Michael Meyer in opensuse-de]

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 24/06/2019 02:59, Stasiek Michalski wrote:

On nie, cze 23, 2019 at 7:19 PM, Christian Boltz <opensuse@cboltz.de> wrote:

...

Hello,

Am Sonntag, 23. Juni 2019, 01:46:09 CEST schrieb Felix Miata:

...

 Stefan Brüns composed on 2019-06-22 19:16 (UTC+0200):  > Felix Miata wrote:

...

 >> Problem: ghostscript-9.27-2.3.i586 requires apparmor-abstractions,  >> but this  ...

 >> Solution 3: remove lock to allow installation of  >> apparmor-abstractions-2.13.2-9.2.noarch[OSS] Solution 4: break  >> ghostscript-9.27-2.3.i586 by ignoring some of its dependencies  >> Choose from above solutions by number or skip, retry or cancel  >> [1/2/3/4/s/r/c] (c): 4 Applying solution 4  >  > The correct choice matching upstream openSUSE would have been (3).  > You chose  On the contrary, if apparmo* is not already installed, there is no  reason I can imagine to introduce apparmor-* as a consequence of an  update to another app that that particular installation has no use  for (ghostscript).

There's a reason for this dependency - since some months, we have an AppArmor profile for ghostscript and it's helper scripts (ps2pdf etc.). Yes. technically ghostscript also works without the AppArmor profile, but you'll lack protection against evil files that trigger executing another program unintentionally. I'm probably biased on this ;-) but I'd argue that something that makes ghostscript more secure clearly qualifies for a "Requires".

Wouldn't it be better to split the package into apparmor addon and do Suppliments: (apparmor and ghostscript) over that? I don't really see a reason why ghostscript itself should require apparmor, if the user doesn't have it already installed.

Remember that default packages, especially the ones that aren't required for proper functionality of the system, might not be installed on user's system.

I agree this is probably a much better way to achieve pretty much the same result -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 24/06/2019 18:36, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 24/06/2019 04.54, Simon Lees wrote:

...

On 24/06/2019 02:59, Stasiek Michalski wrote:

...

On nie, cze 23, 2019 at 7:19 PM, Christian Boltz <opensuse@cboltz.de> wrote:

...

Hello,

Am Sonntag, 23. Juni 2019, 01:46:09 CEST schrieb Felix Miata:

...

Stefan Brüns composed on 2019-06-22 19:16 (UTC+0200):

...

Felix Miata wrote:

...

...

> Problem: ghostscript-9.27-2.3.i586 requires > apparmor-abstractions, but this ...

...

> Solution 3: remove lock to allow installation of > apparmor-abstractions-2.13.2-9.2.noarch[OSS] Solution 4: > break ghostscript-9.27-2.3.i586 by ignoring some of its > dependencies Choose from above solutions by number or > skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying > solution 4

The correct choice matching upstream openSUSE would have been (3). You chose On the contrary, if apparmo* is not already installed, there is no reason I can imagine to introduce apparmor-* as a consequence of an update to another app that that particular installation has no use for (ghostscript).

There's a reason for this dependency - since some months, we have an AppArmor profile for ghostscript and it's helper scripts (ps2pdf etc.). Yes. technically ghostscript also works without the AppArmor profile, but you'll lack protection against evil files that trigger executing another program unintentionally. I'm probably biased on this ;-) but I'd argue that something that makes ghostscript more secure clearly qualifies for a "Requires".

Wouldn't it be better to split the package into apparmor addon and do Suppliments: (apparmor and ghostscript) over that? I don't really see a reason why ghostscript itself should require apparmor, if the user doesn't have it already installed.

Remember that default packages, especially the ones that aren't required for proper functionality of the system, might not be installed on user's system.

I agree this is probably a much better way to achieve pretty much the same result

The computer admin should have the choice to not install apparmor or ghostcript, for whatever reasons.

We are not talking about changing that, were talking about only installing the ghostscript apparmor profile if apparmor is actually installed when you install ghostscript, thus making the install lighter. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 6/24/19 11:30 AM, Simon Lees wrote:

We are not talking about changing that, were talking about only installing the ghostscript apparmor profile if apparmor is actually installed when you install ghostscript, thus making the install lighter.

IMHO the packages should ship their own AppArmor profiles maintained by the packager so that Christian does not have to update AppArmor profiles after application changes. Ciao, Michael.

Am 24.06.19 um 11:30 schrieb Simon Lees:

We are not talking about changing that, were talking about only installing the ghostscript apparmor profile if apparmor is actually installed when you install ghostscript, thus making the install lighter.

Saving a whopping.... one moment, let me count.... seife@strolchi:~> rpm -ql ghostscript|grep appar /etc/apparmor.d/ghostscript seife@strolchi:~> rpm -ql ghostscript|grep appar|xargs ls -l -rw-r--r-- 1 root root 1788 Jun 12 18:43 /etc/apparmor.d/ghostscript 1788 Bytes! Having this file lying around, even if no apparmor is installed, is probably still less bloat than the increase of metadata size due to yet-another-subpackage. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 24 Jun 2019 12:24:50 +0930 Simon Lees <sflees@suse.de> wrote:

On 24/06/2019 02:59, Stasiek Michalski wrote:

...

On nie, cze 23, 2019 at 7:19 PM, Christian Boltz <opensuse@cboltz.de> wrote:

...

Hello,

Am Sonntag, 23. Juni 2019, 01:46:09 CEST schrieb Felix Miata:

...

 Stefan Brüns composed on 2019-06-22 19:16 (UTC+0200):  > Felix Miata wrote:

...

 >> Problem: ghostscript-9.27-2.3.i586 requires apparmor-abstractions,  >> but this  ...

 >> Solution 3: remove lock to allow installation of  >> apparmor-abstractions-2.13.2-9.2.noarch[OSS] Solution 4: break  >> ghostscript-9.27-2.3.i586 by ignoring some of its dependencies  >> Choose from above solutions by number or skip, retry or cancel  >> [1/2/3/4/s/r/c] (c): 4 Applying solution 4  >  > The correct choice matching upstream openSUSE would have been (3).  > You chose  On the contrary, if apparmo* is not already installed, there is no  reason I can imagine to introduce apparmor-* as a consequence of an  update to another app that that particular installation has no use  for (ghostscript).

There's a reason for this dependency - since some months, we have an AppArmor profile for ghostscript and it's helper scripts (ps2pdf etc.). Yes. technically ghostscript also works without the AppArmor profile, but you'll lack protection against evil files that trigger executing another program unintentionally. I'm probably biased on this ;-) but I'd argue that something that makes ghostscript more secure clearly qualifies for a "Requires".

Wouldn't it be better to split the package into apparmor addon and do Suppliments: (apparmor and ghostscript) over that? I don't really see a reason why ghostscript itself should require apparmor, if the user doesn't have it already installed.

Remember that default packages, especially the ones that aren't required for proper functionality of the system, might not be installed on user's system.

I agree this is probably a much better way to achieve pretty much the same result

It isn't. Ghostscript needs apparmor to be reasonably secure. A security flaw pointed out in ghostscript was fixed by writing this apparmor profile. For it to be effective you need apparmor even if you did not have it to start with. That's are requirement in my book. If you really know what you are doing you can use ghostscript without apparmor but that's not what the default should be regardless of installing recommends or not. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 25 Jun 2019 22:11:36 +0930 Rodney Baker <rodney.baker@iinet.net.au> wrote:

On Monday, 24 June 2019 22:26:53 ACST Michal Suchánek wrote: [...]

...

...

I agree this is probably a much better way to achieve pretty much the same result

It isn't. Ghostscript needs apparmor to be reasonably secure. A security flaw pointed out in ghostscript was fixed by writing this apparmor profile. For it to be effective you need apparmor even if you did not have it to start with. That's are requirement in my book.

Sounds more like a workaround than a fix. A proper fix would have been to fix the vulnerability in ghostscript, rather than using a sledgehammer to crack a walnut (unless there was absolutely no other way to mitigate the risk).

Ghostscript is a postscript interpreter. The document can contain arbitrary program. If the standard was not designed with security in mind and documents commonly rely on features that are by design insecure there is no other way. That said, I am not familiar with the particular vulnerability this change is trying to address. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 25/06/2019 15.01, Martin Wilck wrote:

On Tue, 2019-06-25 at 22:11 +0930, Rodney Baker wrote:

...

On Monday, 24 June 2019 22:26:53 ACST Michal Suchánek wrote: [...]

That's the point - ghostscript is considered more or less unfixable. Quoting from the non-public bug where the apparmor profile was introduced: "With the current set of ghostscript security issues and likely more coming, we should audit the current users of ghostscript and remove it where it is not strictly necessary, or at least confine it using apparmor. [...] Basically processing untrusted input with ghostscript is a hopeless case and should be disabled." Yet ghostscript is at the heart of Linux printing, so it couldn't simply be ditched. Thus using apparmor is only logical - it confines ghostscript from an external, security-focused point of view.

Is that the reason why printing is switching to PDF? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 25/06/2019 16.22, Michal Suchánek wrote:

On Tue, 25 Jun 2019 16:15:44 +0200 "Carlos E. R." <> wrote:

...

On 25/06/2019 15.01, Martin Wilck wrote:

...

On Tue, 2019-06-25 at 22:11 +0930, Rodney Baker wrote:

...

On Monday, 24 June 2019 22:26:53 ACST Michal Suchánek wrote: [...]

...

That's the point - ghostscript is considered more or less unfixable. Quoting from the non-public bug where the apparmor profile was introduced: "With the current set of ghostscript security issues and likely more coming, we should audit the current users of ghostscript and remove it where it is not strictly necessary, or at least confine it using apparmor. [...] Basically processing untrusted input with ghostscript is a hopeless case and should be disabled." Yet ghostscript is at the heart of Linux printing, so it couldn't simply be ditched. Thus using apparmor is only logical - it confines ghostscript from an external, security-focused point of view.

Is that the reason why printing is switching to PDF?

heh, what a joke.

Initially PDF was well-defined format carrying data (rather than programming language like postscript). This did not allow for nifty ticks (like tiny postscript raytracer that generates detailed image) but allowed for interpretation of the data securely with well-defined resource usage. Then Adobe added forms, JavaScript support, embedded 3D drawings, and whatnot.

Yes, but by not having javascript support we are usually safe. I don't know if printers that support PDF support javascript? The thing is, CUPS has switched to PDF. But my printer speaks ps, not PDF, so... example: LO outputs PDF --> CUPS, which converts to PS. Better (for me) for LO to output PS instead, which it can do. Right? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 23/06/2019 00:18, Felix Miata wrote:

Simon Lees composed on 2019-06-22 19:39 (UTC+0930): ...

...

I don't want to have to skim 5000 lines of a changes file manually to find vdr-${cur_ver}-01..42"vdr-${cur_ver}-01..42" even if yes having 40 patches listed in a changes file doesn't look as "pretty" changes files should be about function over prettyness.

So how is function over form different with fonts for a basic installtion???

Because its apparently not immediately obvious, the installer and package changelogs have two very different roles and thus we expect very different things from them, one is a users first impression of the distro so its very important that it looks good to give first impressions, the other is a tool for developers so it is more important that the required information is presented in an easy format. The installer requiring a font seems perfectly reasonable to me, users can't change it anyway. If you are genuinely interested in a less bloated system probably a much better question to ask is why do you need to have the installer on your system in the first place, once its run it no longer really has a use. So if you want it fixed that is the way i'd do it. And a general reminder if you have a dispute with another contributor and can't resolve it directly, this is not the place to complain, the correct place for that is the board. So if you feel that my decision to mark that bug as won't fix is not right, thats where you should go not here. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, 22 Jun 2019 10:46:17 +0200, Simon Lees wrote:

On 22/06/2019 13:05, Andrei Borzenkov wrote:

...

21.06.2019 23:08, Michal Kubecek пишет:

...

On Fri, Jun 21, 2019 at 08:36:28PM +0200, Luca Beltrame wrote:

...

Il giorno Fri, 21 Jun 2019 20:29:21 +0200 Stefan Seyfried <stefan.seyfried@googlemail.com> ha scritto:

...

I mentioned that I removed the patches 01-42. The script does not understand it.

Seriously, is it this hard to list all the patch files in the changes? A simple "Dropped patches: <list of all patch files>" would have been sufficient *and* it would have taken you *less* than starting this thread.

And this is exactly what is wrong - and has been wrong for few years - with request handling in both openSUSE and SLE. For anyone except the bot, the entry saying "drop all patches" is way more useful

"All" depends on context which is not known at the time someone actually reads changelog. It is pretty easy to grep changelog for patch name to see when it has been added and removed. It requires careful reading to understand whether specific patch added years ago is covered by "all" in this case. Because there may be many "all" in different points of time.

Yeah if I need to go back in 3 years and work out the lifespan of a patch, its far easier to just search the changelog for all instances of the patch, Its something I have to do on occasion with packages i'm not necessarily the maintainer of and rules like this make it much easier.

Although seife wanted to stop discussion, I'd still like to add one point: I'd love to have a better alternative for tracking the code in rpm sources. The main problem is that we're (ab)using rpm changelog for several different purposes. That is, we mess up the rpm changelog contents with both the feature change / bug fix descriptions and the patch change tracking, a la manual VCS. The former is essential, while the latter is useless for non-developers. As many people already suggested, admittedly, this policy itself is useful and helps for development. Sometimes indicating the added patches helps, indeed. However, overall, relying only on this is definitely no best option: why can't I check the patch changes more simply like "git log some.patch"? And, why do I have to write and edit manually all patch changes in *.changes, which is very error-prone? All these pains show the lack of a proper VCS in the process. The bot, which initiated the discussion, merely surfaces such problems due to this policy enforcement. So, I hope that the discussion won't end up with "policy is policy" or "bot actually helps" type of arguments. Neither stopping bot nor stopping policy enforcement would make things better, because then we'll lose either the correctness or the trackability. OTOH, we shouldn't turn our eyes away from the unsatisfying situation, too. This might be a good opportunity to reconsider what's missing. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 23/06/2019 23:15, Hans-Peter Jansen wrote:

Am Sonntag, 23. Juni 2019, 10:15:55 CEST schrieb Takashi Iwai:

...

So, I hope that the discussion won't end up with "policy is policy" or "bot actually helps" type of arguments. Neither stopping bot nor stopping policy enforcement would make things better, because then we'll lose either the correctness or the trackability. OTOH, we shouldn't turn our eyes away from the unsatisfying situation, too. This might be a good opportunity to reconsider what's missing.

Thanks Takashi San, this is the first valuable response in this thread, and one, that (hopefully) not risen Seife's frustrations even more. I highly value Stefan's contributions, not only as a VDR user since 2004 (my family cannot watch TV without it). And as such, I feel really bad in the face of this poor discussion otherwise.

Another sign of improperness in the development process is the revision management. I see failures in the revision display much too often, something that surpasses the changelog abuse significantly from my POV.

The sad reality is however, making obs's version control system much better probably isn't something most people can do in there spare time. Which means the only way its likely to be fixed is if we convince the obs team that its important enough to be worked on. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2019-06-24 at 14:51 +0200, Michal Suchánek wrote:

It can and has been done but the very OBS team has rejected it. That's why we have a bot tracking patch changes when the package storage mechanism used by OBS should be able to do that. I mean the patch was checked into OBS and then later removed. Why can't OBS tell us when it happened, and what were the other package files at the time?

Some simple scripting around "osc log" and "osc rdiff" should provide the data in question. Or am I missing something? Something along the lines of for x in $(seq 2 12); do echo === $x osc rdiff -r$((x-1)):$x openSUSE:Factory vdr | cat done | egrep '^=== |^[+-]Patch[0-9]*:' It could arguably be made a easier and more reliable, but it can be done today. Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 2019-06-25 at 12:13 +0200, Michal Suchánek wrote:

On Tue, 25 Jun 2019 11:13:19 +0200 Martin Wilck <mwilck@suse.com> wrote: iles at the time?

...

Some simple scripting around "osc log" and "osc rdiff" should provide the data in question. Or am I missing something?

Many package revisions cannot be 'expanded'.

Right. I noted that. I used to consider it a bug, but I never digged further.

...

Something along the lines of

for x in $(seq 2 12); do echo === $x osc rdiff -r$((x-1)):$x openSUSE:Factory vdr | cat done | egrep '^=== |^[+-]Patch[0-9]*:'

It could arguably be made a easier and more reliable, but it can be done today.

And if it can be done why don't the mass-change scripts do it instead of parsing the changelogs?

Don't ask me ...

Because parsing changelogs is much faster and more reliable than querying OBS I suspect.

The information is there somewhere in OBS. Maybe hidden in some way, or difficult to retrieve by complex link patterns, but in general it should be available, und should ultimately be more reliable than the human-maintained .changes file, even if the bot tries to enforce the rules. The one thing an open source project should avoid most is pissing off its volunteer contributors, and it seems we're failing at that. If the bot detects that changelog entries are missing for added or removed patches, why doesn't it simply insert them? Regards, Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Jun 23, 2019 at 10:15:55AM +0200, Takashi Iwai wrote:

Although seife wanted to stop discussion, I'd still like to add one point: I'd love to have a better alternative for tracking the code in rpm sources.

The main problem is that we're (ab)using rpm changelog for several different purposes. That is, we mess up the rpm changelog contents with both the feature change / bug fix descriptions and the patch change tracking, a la manual VCS. The former is essential, while the latter is useless for non-developers.

As many people already suggested, admittedly, this policy itself is useful and helps for development. Sometimes indicating the added patches helps, indeed. However, overall, relying only on this is definitely no best option: why can't I check the patch changes more simply like "git log some.patch"? And, why do I have to write and edit manually all patch changes in *.changes, which is very error-prone? All these pains show the lack of a proper VCS in the process.

More and more packages work around the problem in one of two ways: 1. RPM source is tracked in a git repository and export the OBS sources from there (e.g. kernel, samba). They usually also pack all patches into one or multiple tarballs and apply them using a script. While the primary purpose is to avoid ugly and impractical handling of many Patch and %patch lines in specfile (I was told about autosetup some time ago but it only helps with one half of that - and the less annoying one), it also, as a bonus, hides the patches from OBS bots. 2. Complete tarball snatshot from a normal git repository is exported as a tarball into RPM source and there are no patches at all. With no patches, there is nothing to track and nothing for the bot to check. What both these approaches have in common is that with no usable version control in OBS, they move the actual package maintenance somewhere else (in a git repository) and only export the result into OBS. The downside is that there may be people (and bots) unaware of the fact who tend to modify the package in OBS rather than applying the changes to the place where the package is actually maintained. While it would be nice to be able to track packages in OBS reasonably, I'm not sure it's something we can expect for real. Reportedly, someone already did a git based OBS years ago when OBS was new but the OBS guys refused to use his work as they saw no use for it. :-( To do the same again today would be probably way more complicated both from technical and organizational point of view. So maybe the solution is to do exactly the opposite: forget about OBS version "control" completely and start recommending one of the two models described above (or maybe both) as the standard way to use for packages with non-trivial maintenance. And maybe add some framework to make them a bit easier. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2019-06-24 at 04:59 -0400, Neal Gompa wrote:

On Mon, Jun 24, 2019 at 4:35 AM Michal Kubecek <mkubecek@suse.cz> wrote:

...

More and more packages work around the problem in one of two ways:

1. RPM source is tracked in a git repository and export the OBS sources from there (e.g. kernel, samba). They usually also pack all patches into one or multiple tarballs and apply them using a script. While the primary purpose is to avoid ugly and impractical handling of many Patch and %patch lines in specfile (I was told about autosetup some time ago but it only helps with one half of that - and the less annoying one), it also, as a bonus, hides the patches from OBS bots.

2. Complete tarball snatshot from a normal git repository is exported as a tarball into RPM source and there are no patches at all. With no patches, there is nothing to track and nothing for the bot to check.

What both these approaches have in common is that with no usable version control in OBS, they move the actual package maintenance somewhere else (in a git repository) and only export the result into OBS. The downside is that there may be people (and bots) unaware of the fact who tend to modify the package in OBS rather than applying the changes to the place where the package is actually maintained.

I hate both of these options. I already hate the fact that some of the core packages are doing this, because it also means we're forking packages. Once you start doing that, it becomes really easy disconnect from upstream. We've had this problem for *years* with systemd, for example. I worry that it may also happen with dracut since it switched to this model.

Part of the reason why patching has so much friction is to *reduce* patching and to force *communicating* with upstream instead. If patching is annoying, you're hopefully going to work with upstream to fix issues there. But I think that's gone wrong, because what people are doing instead is just figuring out ways to hide patching.

Quite to the contrary, I find that maintaining packages in git encourages working closely with upstream. I am a big fan of Michal's option 2). Fork upstream repo on github or gitlab, maintain a factory branch which is following upstream with a few bug fixes and a few SUSE specific patches, works neatly. Moreover, it facilitates maintaining maintenance branches for SLE and Leap by cherry-picking important fixes from upstream, which is essential for the long-lived distros, where we can't follow upstream all the time. A URL-link to the a repo, plus a commit ID, provides much quicker and deeper insight into the source code changes made than any changelog entry you could think of. Added the bonus that more people are familiar with git/github than osc/OBS, I find this much more appealing than the traditional rpm %patch way of doing things. The only exception IMO is patches that are SUSE-specific and unlikely to ever be taken by upstream (think a feature that upstream dropped and SUSE still supports for some reason). IMO %patch is basically a relict from ancient times when upstream packages were distributed as tarballs exclusively. Regards Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 25, 2019 at 5:39 AM Michal Kubecek <mkubecek@suse.cz> wrote:

On Mon, Jun 24, 2019 at 04:59:22AM -0400, Neal Gompa wrote:

...

On Mon, Jun 24, 2019 at 4:35 AM Michal Kubecek <mkubecek@suse.cz> wrote:

...

More and more packages work around the problem in one of two ways:

1. RPM source is tracked in a git repository and export the OBS sources from there (e.g. kernel, samba). They usually also pack all patches into one or multiple tarballs and apply them using a script. While the primary purpose is to avoid ugly and impractical handling of many Patch and %patch lines in specfile (I was told about autosetup some time ago but it only helps with one half of that - and the less annoying one), it also, as a bonus, hides the patches from OBS bots.

2. Complete tarball snatshot from a normal git repository is exported as a tarball into RPM source and there are no patches at all. With no patches, there is nothing to track and nothing for the bot to check.

What both these approaches have in common is that with no usable version control in OBS, they move the actual package maintenance somewhere else (in a git repository) and only export the result into OBS. The downside is that there may be people (and bots) unaware of the fact who tend to modify the package in OBS rather than applying the changes to the place where the package is actually maintained.

I hate both of these options. I already hate the fact that some of the core packages are doing this, because it also means we're forking packages. Once you start doing that, it becomes really easy disconnect from upstream. We've had this problem for *years* with systemd, for example. I worry that it may also happen with dracut since it switched to this model.

Part of the reason why patching has so much friction is to *reduce* patching and to force *communicating* with upstream instead. If patching is annoying, you're hopefully going to work with upstream to fix issues there. But I think that's gone wrong, because what people are doing instead is just figuring out ways to hide patching.

I might partly agree with this if OBS were used only for Factory packages. For those packages, we should indeed try to minimize the number of patches. I said "partly" because there are packages where the discussion with upstream is... difficult. You mentioned systemd - that's one illustrative example, glibc used to be another. Then there are packages where upstream is effectively dead etc.

You say upstream is difficult, I say downstream doesn't talk to upstream much. Admittedly, my patch load as systemd maintainer in Mageia is nowhere near as big as openSUSE's is now, it was worse when I started. I've upstreamed useful changes from Mageia into systemd upstream (including our improvements to the upstream rpm macros, which openSUSE still doesn't use...) Honestly, this is your own (openSUSE's) fault. I've seen little evidence of communication with upstreams until *very* recently. At least the situation with dracut is improving. Or perhaps I'm more influenced by my beginnings... To me, maintenance of a package begins with introducing myself to upstream and sending fixes/suggestions there to make it better. That was a consequence of how I started out as a Fedora packager. I realize that most other communities don't value that and don't have a directive to try to work with upstream.

However, the main problem with your vision is that OBS is not used only for Factory packages. It's also used for Leap packages and for SLE packages. For these we cannot simply wave hand and say "patching should be hard" (because we need those fixes) or "talk to upstream" (because most of the patches are upstream backports).

And you know what? Those backports should be visible. Hiding them behind git snapshot things rather than declaring the patch set just means you're trying to dodge the auditing process. If the process for handling backport patching in changelogs is too onerous, then let's fix that. It is so frustrating trying to figure out how openSUSE has broken something because they've forked packages and done weird things without any way to figure out what's going on. If I could, I'd ban this practice.

...

...

While it would be nice to be able to track packages in OBS reasonably, I'm not sure it's something we can expect for real. Reportedly, someone already did a git based OBS years ago when OBS was new but the OBS guys refused to use his work as they saw no use for it. :-( To do the same again today would be probably way more complicated both from technical and organizational point of view.

It is not complex from a technical point of view. I spoke to the OBS guys about at oSC this year, and I've been doing it for four years at $DAYJOB. I've implemented Fedora-style Dist-Git (packaging Git). I demonstrated a bit of how this looks at oSC with Pagure[1]. There were quite a few people who liked the idea, and if I get an OBS working on Fedora, we'd do it that way anyway, because OBS' VCS sucks.

[1]: https://youtu.be/wastUxOT6IQ?t=1420

...

So maybe the solution is to do exactly the opposite: forget about OBS version "control" completely and start recommending one of the two models described above (or maybe both) as the standard way to use for packages with non-trivial maintenance. And maybe add some framework to make them a bit easier.

No. If the process for the normal way is broken, let's fix the process. If the tooling is crappy, let's fix the tools. Workarounds only add more pain down the road.

Well, if you can make OBS switch to git as a version control backend, I'll be more than happy. Until then, I'm going to stick with the workarounds for packages requiring non-trivial patch management. I'm not holding my breath but it would be nice to be surprised.

We'll see, I guess... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il giorno Fri, 21 Jun 2019 20:30:49 +0200 Stefan Seyfried <stefan.seyfried@googlemail.com> ha scritto:

I'm not going to do that. It's completely insane.

You may want to tell that to all the other packagers who actually do the same thing. Feel free to challenge the policy (with a little more substance than "completely insane"): but I don't see the point to not abide by it until it is into effect. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 04.10.19 um 09:52 schrieb İsmail Dönmez:

Hi,

On 04 Oct 09:48, Stefan Seyfried wrote:

...

Am 21.06.19 um 20:09 schrieb Stefan Seyfried:

...

https://build.opensuse.org/request/show/711379

Please, someone override factory-auto. It's running amok.

The same is happening again with https://build.opensuse.org/request/show/734517 and this time the patch is neatly mentioned in the change log.

https://build.opensuse.org/request/show/734919

Do we still have to work around the artificial stupidity? Then I'll solve this better, once and for all. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 04.10.19 um 10:45 schrieb İsmail Dönmez:

As a developer I couldn't grep for the patch name either, why not help fellow human beings either?

Is there a real life usecase for "grep the patch name from the foobar.changes"? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04 Oct 10:58, Stefan Seyfried wrote:

Am 04.10.19 um 10:45 schrieb İsmail Dönmez:

...

As a developer I couldn't grep for the patch name either, why not help fellow human beings either?

Is there a real life usecase for "grep the patch name from the foobar.changes"?

Are you really asking this question? Of course, sometimes I work on stuff with 10 years of changes and I do this regularly. ismail -- Aus so krummem Holze, als woraus der Mensch gemacht ist, kann nichts ganz Gerades gezimmert werden. — Immanuel Kant SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer (HRB 247165, AG München)

On Fri, 2019-10-04 at 11:41 +0200, Stefan Seyfried wrote:

...

Are you really asking this question? Of course, sometimes I work on stuff with 10 years of changes and I do this regularly.

Then you will be delighted that you can use "git log" / "git blame" in the future instead of grepping bluez.changes.

Grepping "git log" will only be useful if we make it absolutely mandatory for the log messages to include the patch filenames being removed. Which I'm sure you'll whine about just as much as doing so in the .changes file, given it's exactly the same amount of work for exactly the same reasons. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg HRB 247165, AG München GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Freitag, 4. Oktober 2019, 12:21:28 CEST schrieb Michal Kubecek:

On Friday, 4 October 2019 12:13 Richard Brown wrote:

...

Grepping "git log" will only be useful if we make it absolutely mandatory for the log messages to include the patch filenames being removed.

I doubt that's what Stefan meant, rather something like

git log [-p] -- <patch-file>

which is more convenient and more reliable without requiring specially formated commit messages or log entries.

Which is getting interesting, if you don't know the name of a removed file beforehand. That's what Richard is thinking of, and I ask myself... Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org