November 2017 - openSUSE Packaging - openSUSE Mailing Lists

Re: [opensuse-packaging] systemsmanagement:puppet has no bugowner
by Adrian Schröter 09 Nov '17

09 Nov '17

On Mittwoch, 8. November 2017, 19:21:33 CET wrote Vojta Dziewiecki: > Hello, > Kristýna replaced me as the package maintainer about 3 years ago. You can > remove me, as I am not willing to work on the package in my free time > anyway. It is the best when you remove yourself then. thank you adrian > 2017-11-07 9:07 GMT+01:00 Adrian Schröter <adrian(a)suse.de>: > > > On Dienstag, 7. November 2017, 09:01:02 CET wrote Mathias Homann: > > > systemsmanagement:puppet has no bugowners, and when one tries to file a > > bug on > > > bugzilla one gets this: > > > > > > > > > > > > Assignee: > > > *jatan11@please-enter-an-email-address* did not match anything > > > > > > > > > Can someone please see to that? > > > > The project has multiple bugowners, not a good idea anyway. > > Using a group would make more sense here. > > > > However, I have removed the first entry with an invalid email > > adress now, so the next person will be taken. > > > > Kristyna, Nanuk, Theo, Wojtek, you could create some mailing > > list somewhere and we could found a group if you want > > to have multiple official bugowners. > > > > Otherwise Kristyna will get the bugzilla reports now ;) > > > > -- > > > > Adrian Schroeter > > email: adrian(a)suse.de > > > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB > > 21284 (AG Nürnberg) > > > > Maxfeldstraße 5 > > 90409 Nürnberg > > Germany > > > > > > > > > -- Adrian Schroeter email: adrian(a)suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Questioning systemd tmpfiles.d packaging guidelines
by Thorsten Kukuk 08 Nov '17

08 Nov '17

Hi, background: with Richards move of the rpm db to /usr, we are now looking at and cleaning up the content and subvolume mess in /var. And, if you take snapshots, rollback and transactional-updates serious, not everything in /var is accessible during upgrade. A solution for some of the problems is tmpfiles.d. So I converted two packages as PoC to use tmpfiles.d, and it works fine, except that rpmlint now reports a lot of policy violations. And I'm questioning, if this checks are really correct or what the idea behind this was. So my problems: 1. We call systemd-tmpfiles with the full path to the tmpfiles configuration. And this is documented in this way in our wiki, too. But: if I read the manual page correct, this is the wrong way. If you specify the full path to the config file as argument, adjusted configuration files in /etc done by the sysadmin are ignored. Why do we force every packager to ignore changes made by the admin here? 2. We tell the packager to add %ghost entries for every file, so that rpm -qf works. I can understand the reason, but in my experience, this %ghost entries always create problems later during update or deinstallation. Additional, rpm tries to mess around with this files during update/de-installation, but not always this files are accessible at this time. And if I can add the files to the package list, in most cases I don't need tmpfiles.d, but could add them directly to the file list. My dream: rpm -qf is looking at tmpfiles.d, if it does not find the file in the RPM database. Knowing that tmpfiles is creating this file and which configuration file is much, much more helpfull! I would like to see at least the full path to the configuration file changed to only the name of the configuration file. And maybe somebody has a better idea how to track tmpfiles.d config file changes except %ghost entries in RPM. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Status of devel:languages:perl:CPAN-* repositories?
by Bjoern Voigt 07 Nov '17

07 Nov '17

I branched and fixed the package perl-grepmail from devel:languages:perl:CPAN-G repository: https://build.opensuse.org/package/show/home:bjoernv:branches:devel:languag… But as I wanted to submit the package I got the following error message: "Unable to submit: The target project devel:languages:perl:CPAN-G is not accepting requests because: If you want to fix a package - submit it to devel:languages:perl" In devel:languages:perl there is no such package. What is the correct update process here? Greetings, Björn -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] RFC: changing RPM's default scriptlet locale
by jan matejek 06 Nov '17

06 Nov '17

Fellow mortals, more and more packages need their locale to be set to something more sensible than C. This hit me while switching packages over to Python 3. Python gets its encoding from locale, so by default, it won't decode UTF-8 unless the appropriate encoding is set. Right now, when gtk-doc is switched to use Python 3, it won't build UTF-8 documentation. This could be changed in gtk-doc itself (although that is impractical), but perhaps a better way is to change the default locale for spec scriptlets. Right now the macros set it to C. We could switch that to "C.UTF-8", "en_US.UTF-8", or export a special RPM variable that could be overriden in your spec file. Still, the default should be something with UTF-8 in it. I'm now trying to build a Ring 1 staging project with this change. So far I have seen one failure related to it: with en_US.UTF-8, bash ranges (like [a-z]) are case-insensitive and match more than intended. That could be solved by changing the expression, or by setting locale to C.UTF-8. Thoughts, comments? regards m.

7 16

[opensuse-packaging] Python 2/3 and update-alternatives
by Thomas Schraitle 06 Nov '17

06 Nov '17

Hi, I'm wondering, why the python packages for version 2 and 3 don't use the update-alternatives script. Any reason for this? I haven't found anything in the package itself nor on mailing lists. Probably I've missed some. Maybe this was on purpose as Python2 isn't a complete replacement for Python3 (and vice versa). On the other side, I assume, not all Java runtime environments are always compatible. However, still, you can use this: # update-alternatives --display java java - auto mode link best version is /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java link currently points to /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java link java is /usr/bin/java [...] # update-alternatives --display python update-alternatives: error: no alternatives for python (executed on openSUSE Tumbleweed) Bug? Feature? Design decision? Hope someone can enlighten me. :)) Thanks! -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX Products GmbH (o< Maxfeldstrasse 5 /\\ Documentation Specialist 90409 Nuernberg, Germany _\_v http://www.suse.com | HRB 21284 SUSE LINUX GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4