[opensuse-packaging] misleading generated "bugfixes" comment in spec file
Hello, I am only the messenger: Internally at SUSE a developer was wondering about the automatically generated comment in our spec files: ------------------------------------------------------------------- # Please submit bugfixes or comments via http://bugs.opensuse.org/ # ------------------------------------------------------------------- It lead to a discussion at SUSE whether or not that comment actually makes sense in our spec files. One of the questions was that information whereto submit bugfixes or comments should be different for users of SUSE Linux Enterprise (SLE) products - for them it should not be http://bugs.opensuse.org/ but https://scc.suse.com/support/requests On the other hand any users (regardless of openSUSE or SLE) if they are looking for information whereto submit bugfixes or comments would normally not get the source RPM and therein read the comment in the spec file so that such a comment in the spec file is probably "mostly useless" and misleading or even plain wrong for SLE users. Therefore there is the proposal to no longer have that comment in the spec file at all because the spec file is not really the right place to provide such kind of information to users. Now my personal opinion: I agree to no longer have that comment in the spec file. I think what rpm reports for installed packages should show appropriate information to users. FYI what rpm reports for installed packages on openSUSE Tumbleweed and openSUSE Leap 42.1 versus SLES 12-SP1 and SLES 11 for the installed package "bash" that is used here only as an example: ------------------------------------------------------------ # cat /etc/os-release NAME=openSUSE VERSION="Tumbleweed" VERSION_ID="20160406" ... # rpm -qi bash ... Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/os-release NAME="openSUSE Leap" VERSION="42.1" ... # rpm -qi bash ... Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/os-release NAME="SLES" VERSION="12-SP1" ... # rpm -qi bash ... Packager : https://www.suse.com/ Vendor : SUSE LLC https://www.suse.com/ URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/SuSE-release SUSE Linux Enterprise Desktop 11 (i586) VERSION = 11 # rpm -qi bash ... Vendor : SUSE LINUX Products GmbH, Nuernberg, Germany Packager : http://bugs.opensuse.org URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On lundi, 18 avril 2016 15.55:31 h CEST Johannes Meixner wrote:
Hello,
I am only the messenger:
Cool we never shoot them, do we? ;-)
Internally at SUSE a developer was wondering about the automatically generated comment in our spec files: ------------------------------------------------------------------- # Please submit bugfixes or comments via http://bugs.opensuse.org/ # -------------------------------------------------------------------
It lead to a discussion at SUSE whether or not that comment actually makes sense in our spec files.
One of the questions was that information whereto submit bugfixes or comments should be different for users of SUSE Linux Enterprise (SLE) products - for them it should not be http://bugs.opensuse.org/ but https://scc.suse.com/support/requests
On the other hand any users (regardless of openSUSE or SLE) if they are looking for information whereto submit bugfixes or comments would normally not get the source RPM and therein read the comment in the spec file so that such a comment in the spec file is probably "mostly useless" and misleading or even plain wrong for SLE users.
Therefore there is the proposal to no longer have that comment in the spec file at all because the spec file is not really the right place to provide such kind of information to users.
Now my personal opinion:
I agree to no longer have that comment in the spec file.
I think what rpm reports for installed packages should show appropriate information to users.
FYI what rpm reports for installed packages on openSUSE Tumbleweed and openSUSE Leap 42.1 versus SLES 12-SP1 and SLES 11 for the installed package "bash" that is used here only as an example: ------------------------------------------------------------ # cat /etc/os-release NAME=openSUSE VERSION="Tumbleweed" VERSION_ID="20160406" ...
# rpm -qi bash ... Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/os-release NAME="openSUSE Leap" VERSION="42.1" ...
# rpm -qi bash ... Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/os-release NAME="SLES" VERSION="12-SP1" ...
# rpm -qi bash ... Packager : https://www.suse.com/ Vendor : SUSE LLC https://www.suse.com/ URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/SuSE-release SUSE Linux Enterprise Desktop 11 (i586) VERSION = 11
# rpm -qi bash ... Vendor : SUSE LINUX Products GmbH, Nuernberg, Germany Packager : http://bugs.opensuse.org URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------
Kind Regards Johannes Meixner
It make sense also for me. How we will integrate that, will be with spec-cleaner I guess. Changing that line will create a rebuild, but for Factory/TW it's normal stuff. For anything already released (no way) Promote the changes in devel repo yes Also we could advertise more the "report bug" button present on obs which affect directly the bug to the declared maintainer. -- Bruno Friedmann Ioda-Net S?rl www.ioda-net.ch Bareos Partner openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Apr 18 17:03 Bruno Friedmann wrote (excerpt):
On lundi, 18 avril 2016 15.55:31 h CEST Johannes Meixner wrote:
I am only the messenger:
Cool we never shoot them, do we? ;-)
not until you have that great new upcoming Yet another Shooting Tool ... whoops - wrong thread https://lists.opensuse.org/yast-devel/2016-04/msg00029.html ;-)
Now my personal opinion:
I agree to no longer have that comment in the spec file.
I think what rpm reports for installed packages should show appropriate information to users.
...
For anything already released (no way)
Of course only for future releases.
Also we could advertise more the "report bug" button present on obs which affect directly the bug to the declared maintainer.
Great that you mention that! I had totally forgotten about its existence. I did a quick build test in home:jsmeix:branches:Printing/cups that now has in cups.spec a BugUrl added, see https://build.opensuse.org/package/show/home:jsmeix:branches:Printing/cups I described it in cups.changes: --------------------------------------------------------------------- - Added BugUrl in spec file (shown wrapped here): https://bugzilla.opensuse.org/enter_bug.cgi?classification=7340 &product=openSUSE.org &component=3rd%20party%20software &assigned_to=jsmeix@suse.com &cc=tchvatal@suse.com&cc=werner@suse.com &short_desc=Printing/cups:%20Bug which is basically the value of the "ReportBug" button on the OBS Printing development project page for the "cups" package https://build.opensuse.org/package/show/Printing/cups BugUrl is supported since rpm version 4.8.0 (cf. http://www.rpm.org/wiki/Releases/4.8.0) which is provided since openSUSE:11.4 (i.e. nowadays everywhere except SLE11). --------------------------------------------------------------------- Currently one cannot submit a package with BugUrl to openSUSE because some "service" does not like it (long BugUrl shown wrapped here): --------------------------------------------------------------------- $ osc commit error: line 16: Unknown tag: BugUrl: https://bugzilla.opensuse.org/enter_bug.cgi?classification=7340 &product=openSUSE.org&component=3rd%20party%20software &assigned_to=jsmeix@suse.com&cc=tchvatal@suse.com&cc=werner@suse.com &short_desc=Printing/cups:%20Bug Aborting: service call failed: /usr/lib/obs/service/source_validator --outdir /tmp/tmp1EbM2K A service failed with error: 1 --------------------------------------------------------------------- Currently one must use "osc commit --noservice" to get it in: --------------------------------------------------------------------- $ osc commit --noservice Sending cups.changes Sending cups.spec Transmitting file data .. Committed revision 2. --------------------------------------------------------------------- I downloaded the resulting built cups RPM for Leap 42.1 system and got (the Bug URL is shown wrapped here): --------------------------------------------------------------------- # rpm -qip binaries/cups-2.1.3-193.1.x86_64.rpm ... Vendor : obs://build.opensuse.org/home:jsmeix URL : http://www.cups.org/ Bug URL : https://bugzilla.opensuse.org/ enter_bug.cgi?classification=7340 &product=openSUSE.org &component=3rd%20party%20software &assigned_to=jsmeix@suse.com &cc=tchvatal@suse.com&cc=werner@suse.com &short_desc=Printing/cups:%20Bug --------------------------------------------------------------------- I think it would really be nice if OBS somehow automatically could enforce a matching BugUrl setting in the spec file depending on the project where a package is built. I wonder whether the package developer/maintainer should be allowed to specify a BugUrl in the spec file (in particular for his own packages in his own home project he may like to specify his personal web page or mail address as BugUrl) or if always OBS should enforce the "right" BugUrl setting in the spec file depending on the project where it is built. In any case I think when there is no BugUrl in the spec file then OBS should automatically set an appropriate BugUrl. I think when such a RPM feature is there we should use it. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Apr 19 14:16 Johannes Meixner wrote (excerpt):
I did a quick build test in home:jsmeix:branches:Printing/cups that now has in cups.spec a BugUrl added, see https://build.opensuse.org/package/show/home:jsmeix:branches:Printing/cups
...
I downloaded the resulting built cups RPM for Leap 42.1 system and got (the Bug URL is shown wrapped here): --------------------------------------------------------------------- # rpm -qip binaries/cups-2.1.3-193.1.x86_64.rpm ... Vendor : obs://build.opensuse.org/home:jsmeix URL : http://www.cups.org/ Bug URL : https://bugzilla.opensuse.org/ enter_bug.cgi?classification=7340 &product=openSUSE.org &component=3rd%20party%20software &assigned_to=jsmeix@suse.com &cc=tchvatal@suse.com&cc=werner@suse.com &short_desc=Printing/cups:%20Bug ---------------------------------------------------------------------
I simply dropped that Bug URL value into my Firefox browser and - voila! - it perfectly created https://bugzilla.opensuse.org/show_bug.cgi?id=976188 all I had to do was to write the initial comment in that bug report! Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Johannes Meixner wrote:
[...]
Also we could advertise more the "report bug" button present on obs which affect directly the bug to the declared maintainer.
Great that you mention that!
I had totally forgotten about its existence.
I did a quick build test in
home:jsmeix:branches:Printing/cups
that now has in cups.spec a BugUrl added, see
https://build.opensuse.org/package/show/home:jsmeix:branches:Printing/cups
I described it in cups.changes: --------------------------------------------------------------------- - Added BugUrl in spec file (shown wrapped here): https://bugzilla.opensuse.org/enter_bug.cgi?classification=7340 &product=openSUSE.org &component=3rd%20party%20software &assigned_to=jsmeix@suse.com &cc=tchvatal@suse.com&cc=werner@suse.com &short_desc=Printing/cups:%20Bug
Interesting idea but the implementation needs to be improved IMO :-) The disadvantages of that way are a) again makes it hard to reuse the spec file for different products b) the assignees cannot be changed in binary packages floating around c) it duplicates information stored in OBS and Bugzilla So if we wanted to make use of this BugUrl feature of rpm in the future I think the right place to add the url to the spec file would be the build script. The build script mangles the spec file anyways so adding or overwriting BugUrl should be easy. Since a package is built for a specific product on a specific OBS instance also the information added can be product and OBS instance specific. That solves a). Instead of pointing to bugzilla directly, the url should point back to OBS then. OBS would need an additional route, let's say e.g. https://build.opensuse.org/package/report_bug/openSUSE:Factory/cups That route would then use the information stored in OBS to redirect to the right bug reporting tool, just like the "report bug" button now. That solves b) and c) as the actual configuration can be changed on server side even after a product is released. Last but not least the BugUrl information needs to end up in package metadata so zypper, YaST, gnome-software etc can make use of it. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On mercredi, 20 avril 2016 11.39:58 h CEST Ludwig Nussel wrote:
Johannes Meixner wrote:
[...]
Also we could advertise more the "report bug" button present on obs which affect directly the bug to the declared maintainer.
Great that you mention that!
I had totally forgotten about its existence.
I did a quick build test in
home:jsmeix:branches:Printing/cups
that now has in cups.spec a BugUrl added, see
https://build.opensuse.org/package/show/home:jsmeix:branches:Printing/cups
I described it in cups.changes: --------------------------------------------------------------------- - Added BugUrl in spec file (shown wrapped here): https://bugzilla.opensuse.org/enter_bug.cgi?classification=7340 &product=openSUSE.org &component=3rd%20party%20software &assigned_to=jsmeix@suse.com &cc=tchvatal@suse.com&cc=werner@suse.com &short_desc=Printing/cups:%20Bug
Interesting idea but the implementation needs to be improved IMO :-) The disadvantages of that way are
a) again makes it hard to reuse the spec file for different products b) the assignees cannot be changed in binary packages floating around c) it duplicates information stored in OBS and Bugzilla
So if we wanted to make use of this BugUrl feature of rpm in the future I think the right place to add the url to the spec file would be the build script.
The build script mangles the spec file anyways so adding or overwriting BugUrl should be easy. Since a package is built for a specific product on a specific OBS instance also the information added can be product and OBS instance specific. That solves a).
Instead of pointing to bugzilla directly, the url should point back to OBS then. OBS would need an additional route, let's say e.g. https://build.opensuse.org/package/report_bug/openSUSE:Factory/cups That route would then use the information stored in OBS to redirect to the right bug reporting tool, just like the "report bug" button now. That solves b) and c) as the actual configuration can be changed on server side even after a product is released.
Last but not least the BugUrl information needs to end up in package metadata so zypper, YaST, gnome-software etc can make use of it.
cu Ludwig
Get my +1 on the server side part and build automagically btw Johannes thanks for your invaluable experiments. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 18 April 2016, Johannes Meixner wrote:
Hello,
I am only the messenger:
Internally at SUSE a developer was wondering about the automatically generated comment in our spec files: ------------------------------------------------------------------- # Please submit bugfixes or comments via http://bugs.opensuse.org/ # -------------------------------------------------------------------
It lead to a discussion at SUSE whether or not that comment actually makes sense in our spec files.
One of the questions was that information whereto submit bugfixes or comments should be different for users of SUSE Linux Enterprise (SLE) products - for them it should not be http://bugs.opensuse.org/ but https://scc.suse.com/support/requests
On the other hand any users (regardless of openSUSE or SLE) if they are looking for information whereto submit bugfixes or comments would normally not get the source RPM and therein read the comment in the spec file so that such a comment in the spec file is probably "mostly useless" and misleading or even plain wrong for SLE users.
Therefore there is the proposal to no longer have that comment in the spec file at all because the spec file is not really the right place to provide such kind of information to users.
Now my personal opinion:
I agree to no longer have that comment in the spec file.
Good, BTW I also find it questionable that prepare_spec adds a SuSE copyright line and moreover it replaces the License. I don't think that's right.
I think what rpm reports for installed packages should show appropriate information to users.
FYI what rpm reports for installed packages on openSUSE Tumbleweed and openSUSE Leap 42.1 versus SLES 12-SP1 and SLES 11 for the installed package "bash" that is used here only as an example: ------------------------------------------------------------ # cat /etc/os-release NAME=openSUSE VERSION="Tumbleweed" VERSION_ID="20160406" ...
# rpm -qi bash ... Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/os-release NAME="openSUSE Leap" VERSION="42.1" ...
# rpm -qi bash ... Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/os-release NAME="SLES" VERSION="12-SP1" ...
# rpm -qi bash ... Packager : https://www.suse.com/ Vendor : SUSE LLC https://www.suse.com/ URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------ # cat /etc/SuSE-release SUSE Linux Enterprise Desktop 11 (i586) VERSION = 11
# rpm -qi bash ... Vendor : SUSE LINUX Products GmbH, Nuernberg, Germany Packager : http://bugs.opensuse.org URL : http://www.gnu.org/software/bash/bash.html ------------------------------------------------------------
Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, 2016-04-19 at 13:33 +0200, Ruediger Meier wrote:
BTW I also find it questionable that prepare_spec adds a SuSE copyright line and moreover it replaces the License. I don't think that's right.
It doesn't - It's called 'SUSE' - not SuSE :) (That's the case since 2004; let's get used to it) I don't see much trouble with the addition - any added copyright of the author remains in place if he decided to note one down. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 19 April 2016, Dominique Leuenberger / DimStar wrote:
On Tue, 2016-04-19 at 13:33 +0200, Ruediger Meier wrote:
BTW I also find it questionable that prepare_spec adds a SuSE copyright line and moreover it replaces the License. I don't think that's right.
It doesn't - It's called 'SUSE' - not SuSE :) (That's the case since 2004; let's get used to it)
At first SuSE should finish their stupid rename work ;) $ grep -r "SuSE" /usr | wc -l 3158 $ grep -r "SUSE" /usr | wc -l 2923 Why did they renamed it all? Such things do not make sense to me to me ... Choosing such ugly CamelCase name was a big mistake. But renaming was an even bigger mistake.
I don't see much trouble with the addition - any added copyright of the author remains in place if he decided to note one down.
It also replaces the license text written by the original author. It looks like the original copyright holder agrees with that license. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ruediger Meier píše v Út 19. 04. 2016 v 16:30 +0200:
On Tuesday 19 April 2016, Dominique Leuenberger / DimStar wrote:
On Tue, 2016-04-19 at 13:33 +0200, Ruediger Meier wrote:
BTW I also find it questionable that prepare_spec adds a SuSE copyright line and moreover it replaces the License. I don't think that's right.
It doesn't - It's called 'SUSE' - not SuSE :) (That's the case since 2004; let's get used to it)
At first SuSE should finish their stupid rename work ;)
$ grep -r "SuSE" /usr | wc -l 3158
$ grep -r "SUSE" /usr | wc -l 2923
Suprisingly most of this stuff is arcane unpacked changelogs and header files with copyrights. This stuff is not updated unless there is any other change. Which is quite fine. What is more important is that if you google SUSE or SuSE what kind of results you get. Luckily I see only three mentions of SuSE on first 10 google pages, where two of those are pages from 2003 and 2002 and one is download location for postgresql http://www.postgresql.org/download/ linux/suse/
Why did they renamed it all? Such things do not make sense to me to me ... Choosing such ugly CamelCase name was a big mistake. But renaming was an even bigger mistake.
I don't see much trouble with the addition - any added copyright of the author remains in place if he decided to note one down.
It also replaces the license text written by the original author. It looks like the original copyright holder agrees with that license.
Yes it does replace the license. If you disagree with the spec to be licensed MIT then your spec is not mostly acceptable for Factory. Thus either you accept it or do not contribute. Tomas
On Tuesday 19 April 2016, Tomas Chvatal wrote:
Ruediger Meier píše v Út 19. 04. 2016 v 16:30 +0200:
On Tuesday 19 April 2016, Dominique Leuenberger / DimStar wrote:
On Tue, 2016-04-19 at 13:33 +0200, Ruediger Meier wrote:
BTW I also find it questionable that prepare_spec adds a SuSE copyright line and moreover it replaces the License. I don't think that's right.
It doesn't - It's called 'SUSE' - not SuSE :) (That's the case since 2004; let's get used to it)
At first SuSE should finish their stupid rename work ;)
$ grep -r "SuSE" /usr | wc -l 3158
$ grep -r "SUSE" /usr | wc -l 2923
Suprisingly most of this stuff is arcane unpacked changelogs and header files with copyrights.
IMHO SUSE should have spent effort to update their copyright lines and comments in any project where they have added it. This is the work you have to do for renaming.
This stuff is not updated unless there is any other change. Which is quite fine.
What is more important is that if you google SUSE or SuSE what kind of results you get. Luckily I see only three mentions of SuSE on first 10 google pages, where two of those are pages from 2003 and 2002 and one is download location for postgresql http://www.postgresql.org/download/ linux/suse/
Why did they renamed it all? Such things do not make sense to me to me ... Choosing such ugly CamelCase name was a big mistake. But renaming was an even bigger mistake.
I don't see much trouble with the addition - any added copyright of the author remains in place if he decided to note one down.
It also replaces the license text written by the original author. It looks like the original copyright holder agrees with that license.
Yes it does replace the license. If you disagree with the spec to be licensed MIT then your spec is not mostly acceptable for Factory.
It's not about me. I'm sure that you would find spec files on OBS which were originally imported from other distros or from elsewhere. prepare_spec just changes licenses without caring for the original one.
Thus either you accept it or do not contribute.
How? prepare_spec does the change usually silently, after the patch is reviewed and ready for commit. It should ask if it's ok to change the license or even better it should not run by default at all. Personally I usually don't run prepare_spec automatically. cu, Rudi cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (6)
-
Bruno Friedmann -
Dominique Leuenberger / DimStar -
Johannes Meixner -
Ludwig Nussel -
Ruediger Meier -
Tomas Chvatal