Am 21.06.19 um 20:28 schrieb Luca Beltrame:

Il giorno Fri, 21 Jun 2019 20:09:54 +0200 Stefan Seyfried 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:29 schrieb Axel Braun:

Its not running amok - it just wants to have every patch listed separate...

I'm not going to do that. It's completely insane. -- 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

Il giorno Fri, 21 Jun 2019 20:30:49 +0200 Stefan Seyfried 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

Il giorno Fri, 21 Jun 2019 20:43:00 +0200 Stefan Seyfried 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.

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. -- 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 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:43:00PM +0200, Stefan Seyfried wrote:

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

There are even worse things, e.g. SLE package maintainers being repeatedly asked to spam Factory package changelogs with fake entries listing bugzilla and FATE ids which were never relevant for the Factory package (and which openSUSE users cannot see anyway). This policy of doing crazy and completely senseless things just to appease some bots is getting more and more annoying. 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 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

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

On 6/22/19 4:00 PM, Stefan Seyfried wrote:

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.

Some maintainers are tweaking lots of packages to reach the goal of a larger general change without having to ask all the maintainers to actually do the work. So looking into a package is not only caused by breakage. I agree with Richard here: You should look at this with less ego. Ciao, Michael. -- 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

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

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 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 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, Jun 24, 2019 at 4:35 AM Michal Kubecek wrote:

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.

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.

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. -- 真実はいつも一つ！/ 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

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

On Mon, 24 Jun 2019 17:03:16 +0930 Simon Lees wrote:

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.

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? Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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, 2019-06-24 at 04:59 -0400, Neal Gompa wrote:

On Mon, Jun 24, 2019 at 4:35 AM Michal Kubecek 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 , 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 Mon, Jun 24, 2019 at 04:59:22AM -0400, Neal Gompa wrote:

On Mon, Jun 24, 2019 at 4:35 AM Michal Kubecek 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. 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).

...

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. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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). -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- 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 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 Tue, Jun 25, 2019 at 10:58:40AM -0400, Neal Gompa wrote:

On Tue, Jun 25, 2019 at 5:39 AM Michal Kubecek wrote:

...

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.

Well, my experience is exactly the opposite. *Any* systemd problem I was interested in ended up in the same way: our engineers described the problem, explained why is it a problem, proposed a solution and the answer from systemd upstream was always the same: no way, we did it like this, it's The Right Way(TM), you have to live with it. Unlike you, I can't blame our developers that they stopped trying after such experience.

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.

That's pure nonsense. Our developers work with upstream closely - where the upstream is open to cooperation. Unfortunately, systemd is a schoolbook example of a project where it's not the case. Another example that comes to my mind was glibc in the times of Ulrich Drepper autocracy but that has become much better since that era ended.

...

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.

Are you sure you know what you are talking about? Please take a closer look at our kernel-source git repository, at the way it works, at the way each patch is annotated. Do you really think tracking changes in that repository is somehow "hidden", "dodging the auditing process" or less transparent than if we tried to use standard "Patch" and "%patch" machinery? (If that were feasible at all, that is.) When I was working in L3, I've been handling issues with various packages and for kernel, it was usually much easier to find out where does a patch come from, who, when and why added it or its upstream status. And this was thanks to the way kernel packages are maintained. Getting the same level of efficiency was impossible for packages maintained only in OBS, even if the patch count was way lower. 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.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

Am 27.06.19 um 15:29 schrieb Dominique Leuenberger / DimStar:

I doubt it - the OP is not 'not able to cope with the request of adding patches'

That's not entirely correct. I was not willing to clutter the changelog with IMHO useless stuff. Of course the new maintainer now is free to do that.

So, I'd say: don't go waste time writing such an obscure service.

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

Am Freitag, 28. Juni 2019, 12:57:31 CEST schrieb Axel Braun:

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

+1

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

I feel with Dominique. Not closing requests twice will have a good chance to get to the maintainer sometimes, who hopefully will act with more empathy than any bot out there... Guys, if we really get this realized, I would be more than happy, I would be proud of this project (that I really love wholeheartedly).. Cheers, Pete -- 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 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 Sat, 29 Jun 2019 21:15:23 +0930 Simon Lees 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

On 30/06/2019 08:16, Michal Suchánek wrote:

On Sat, 29 Jun 2019 21:15:23 +0930 Simon Lees 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.

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, it'd be awesome if obs was smart enough to prefill the patch name in the .changes file though. -- 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 Sun, Jun 30, 2019 at 9:20 AM 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).

I largely agree with Stefan, but I also see why we can't do it right now. The OBS VCS is deficient in this regard, and pretty much all other distributions use a proper SCM system (Fedora with Pagure[1][2] on Dist-Git[3], Mageia with Dist-SVN, Ubuntu with Launchpad Bazaar, Debian with developer's choice of VCS, etc.). This makes it much easier for anyone to do common actions against the sources and determine provenance, reasoning, etc. Consequently, in those distributions, it is not required to list out every patch in the changelog like openSUSE does. While there are workflows currently where you can use OBS with Git, they're not that good. I've personally developed some tooling that allows me to minimize my interactions with the OBS VCS and work entirely from a proper Dist-Git for $DAYJOB, but it's an uncommon workflow for openSUSE folks. [1]: https://pagure.io/pagure [2]: https://pagure.io/pagure-dist-git [3]: https://github.com/release-engineering/dist-git -- 真実はいつも一つ！/ 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

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, 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 15:44, Michal Kubecek wrote:

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.

Although i'm on the review team generally others are handling most of the work and I only really step in to help when the queue gets really long, so I spend far more time submitting packages then I do reviewing them.

...

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.

I'm interested to here some of these new rules, because I don't recall discussing them here, I also don't recall rewriting any spec files in the last two years, I even have some RS-232 related packages that I have been maintaining for 2+ years and haven't had to change yet (and hadn't changed for a while before that). I don't think we should be rewriting spec files for no good reason, that's just a waste of time. -- 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

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)? ----------------------------------------------------------------------

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? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - HRB 21284 (AG Nuernberg) GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah -- 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 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, Jul 1, 2019 at 4:06 AM 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".

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

In the first couple of years of my packaging software for openSUSE (2015-2017), that happened to me too. I almost stopped because of it. It wasn't that my specs were ugly or didn't conform to the style guides or didn't following the informational guidelines. It was that I used cross-distro methods to package software rather than leveraging openSUSE-specific macros. I do this because I'm maintaining almost identical specs across distributions, and it's a lot easier for me to keep things up to date if the mechanics of them are the same across the board. Part of this is also because I rely on my fedmsg and Red Hat Bugzilla notifications from release-monitoring.org to let me know when to update stuff, and then I update everywhere (Fedora, Mageia, and openSUSE). That seems to have leveled off a bit lately, except with Python and Ruby modules. The latter *must* be packaged differently because openSUSE is grossly incompatible with everyone else for Ruby packaging, and the former is because portable packaging is not permitted unless there's something broken with the openSUSE-style singlespec for that package or there's no real point to doing it that way (like if it only works for one version of Python, as an example). -- 真実はいつも一つ！/ 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

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

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 ;)

Yet somehow noone feels the urge to do so and even SUSE employees often do not. You may underestimate the scale of the problem as people who already gave up do not come to discuss the problem to openSUSE mailing lists ("Survivorship Bias"). I thought there are two ways you can handle this information: either realize that the way things work today drives some packagers (potential as well as actual) away and start to think how much of the rules are really about quality and how much is just formalism for someone's convenience; or just wave hand and say that rules are perfect and those people don't understand it and you don't care about them. Somehow, you found third way, even worse than I could imagine: try to beat those people with company policy (which does not really apply to boot) and suggest them to talk to their managers about inability to comply. That's really sad and disappointing (though, I have to admit, consistent with some previous experiences). Michal Kubecek -- 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 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

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 Mon, Jul 1, 2019 at 8:43 AM Jan Engelhardt 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. -- 真実はいつも一つ！/ 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

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

Am 01.07.19 um 12:43 schrieb Richard Brown:

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.

Michal did at no point imply that he was not open to collaboration and contribution. Just because a package is not submitted to Factory, this does not mean it is not open for contribution. Heck, I even received submitrequests for home:seife:testing, a project with a big fat warning "do not use, specially customized packages" ;-) and I accepted them. -- 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 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 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, 1 Jul 2019 at 15:56, Stefan Seyfried 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 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". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 01/07/2019 21:46, Neal Gompa wrote:

On Mon, Jul 1, 2019 at 12:53 AM Simon Lees wrote:

...

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.

Wait a tick here... This looks like that at no point can packagers submit proposed updates with the desired updateinfo content (what you and OBS call patchinfo is known as updateinfo[1]).

Yep this is true, in a SLE context its always created by the maintenance team because they have further specific bugs to make patchinfo's more readable, for example all security bugs should be written in past tense and some others. -- 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, 02 Jul 2019 02:10:29 +0200, Simon Lees wrote:

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.

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 :) thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

On Tue, 2 Jul 2019 at 08:29, Takashi Iwai 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. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 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. 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... Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 - - 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 ;-)

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 ;-) When removing patches, looking up bugs doesn't make too much sense IMHO. (Removing patches typically happens when updating to the next upstream release which has the fix already included.) Besides that - _if_ you implement that bugzilla lookup, please make it a warning only. There might be reasons to keep a bug open even if it is fixed in Tumbleweed, for example because you also have to do a maintenance update for Leap. Regards, Christian Boltz --

postmap: fatal: open /etc/postfix/virtual: No such file or directory Also mal ehrlich: Was könnte diese ausgesprochen kryptische, vermutlich streng verschlüsselte Meldung wohl bedeuten...? Erdstrahlung? Die Illuminaten? [> Thore und Jan P. Kessler in postfix-users]

-- 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: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. Bluez will be harder to drop ;-) -- 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 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