packaging November 2015

packaging@lists.fedoraproject.org

25 participants
16 discussions

[Fedora-php-devel-list] Change proposal: drop runtime dependency on PEAR
by Remi Collet 25 Jan '16

25 Jan '16

Hi, For now all our PECL extensions have a dependency on php-pear. PEAR is mostly dead and most user don't want to install it. (The project is not dead, it even work with PHP 7, but most users have switched to composer) In fact, the pecl command is only used in scriptlets for extension (un)registration (to allow manual pecl/pear usage). Really nothing is required at runtime. So I'd like to remove dependency on /usr/bin/pecl for PECL extension. Here is a proposal for new scriptlets # when pear installed alone, after us %triggerin -- %{?scl_prefix}php-pear if [ -x %{__pecl} ] ; then %{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || : fi # posttrans as pear can be installed after us %posttrans if [ -x %{__pecl} ] ; then %{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || : fi %postun if [ $1 -eq 0 -a -x %{__pecl} ] ; then %{pecl_uninstall} %{pecl_name} >/dev/null || : fi Notice: pear still required at build time for macro definition. Notice; this is already used to also fix a circular dep issue (php-pecl-jsonc => php-pear => php-cli => php-common => php-pecl-jsonc) Minor issue, /var/lib/pear/pkgxml (%{pecl_xmldir}) is own by php-pear. So we also need to move this directory to php-common to avoid unowned dir when pear is not installed. Comments, before opening a FPC ticket ? Remi.

2 3

Fwd: tex dependencies on EPEL
by Gianluca Sforna 04 Dec '15

04 Dec '15

Hi all, I am packaging a largish rpm here: https://bugzilla.redhat.com/show_bug.cgi?id=804125 and I've got to build its documentation from sources using tex. In Fedora land, I managed to find a simple way to specify which packages I need as Buildrequries, like this: BuildRequires: tex(titlesec.sty) BuildRequires: tex(framed.sty) BuildRequires: tex(threeparttable.sty) BuildRequires: tex(wrapfig.sty) BuildRequires: tex(upquote.sty) BuildRequires: tex(multirow.sty) But this apparently does not work in EPEL 6 (no deps found) or EPEL 7 (tex(upquote.sty) not found). So, any suggestion about how to proceed here? -- Gianluca Sforna http://morefedora.blogspot.com http://plus.google.com/+gianlucasforna - http://twitter.com/giallu

3 5

Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages
by Sérgio Basto 30 Nov '15

30 Nov '15

Switching to packaging(a)lists.fedoraproject.org On Ter, 2015-11-24 at 01:47 +0000, Sérgio Basto wrote: > On Seg, 2015-11-23 at 09:39 +0100, Dominik 'Rathann' Mierzejewski > wrote: > > On Sunday, 22 November 2015 at 00:46, Sérgio Basto wrote: > > > On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote: > > > > On Čt, 2015-11-19 at 20:59 +0000, Sérgio Basto wrote: > > > > > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III > > > > > wrote: > > > > > > > > > > > "SB" == Sérgio Basto <sergio(a)serjux.com> writes: > > > > > > > > > > > > SB> When we fix the .spec and don't change the source, we > > > > > > bump > > > > > > rightmost > > > > > > SB> version, when we change the source, we bump the left > > > > > > version, > > > > > > so > > > > > > we > > > > > > SB> can distinguish when we update the source and when we > > > > > > updated > > > > > > the > > > > > > SB> .spec, this contrast for me is important. > > > > > > > > > > > > For me, the simple rule that a Release: tag less than 1 > > > > > > implies > > > > > > prerelease software, while a Release: tag of 1 or greater > > > > > > implies > > > > > > a > > > > > > post-release package, is important. So far the proponents > > > > > > of > > > > > > this > > > > > > change haven't shown what things would actually look like > > > > > > after > > > > > > this > > > > > > change, so it's hard for me to come up with a reason to > > > > > > change my > > > > > > opinion. > > > > > > > > > > prerelease numbering can't begin with 0 and increased to 0.1 > > > > > because : > > > > > > > > > > next version of foo-0.b would be foo-0.1.b and "b">1 > > > > > > > > Nope, 1>"b" in rpm version compare. > > > > Even so, we shouldn't depend on upstream preserving sorting order > > in > > their pre-release suffixes. Numerical sorting is always monotonous. > > > > > If so, we could begging numeration with 0 for pre-release: > > > > > > foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a -> > > > foo- > > > 0.2.a.1 > > > > I don't understand why you want to introduce another level of > > numbering. > > What's wrong with the current guideline? > > I'd like improve for cases that upstream doesn't make a release and > the package stays forever in a pre-release, this happens a lot with > old projects that are half dead upstream, instead of have just one > counter, we have two counters, one when upstream change the source > other when we rebuild the package, it will be better readable, to > understand if the upstream had updates or not. In this link http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packag… where we read : Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag}%{?dist} And I'm proposing : 0[.%{X}].%{alphatag}[.%{Y}]%{?dist} is just better IMHO . > Best regards, > -- > Sérgio M. B. > > -- Sérgio M. B.

2 2

Naming of Python 3 binaries
by Juan Orti Alcaine 26 Nov '15

26 Nov '15

Hi, I'm reading the guidelines about the naming of conflicting python2/python3 binaries [1], and I have doubts about if it is up to date. It says: "The unversioned executable must be the python2 version.", is this still true? In the example shown some lines before, the unversioned binary goes to the python3 package. With python3 as the default I guess the unversioned binary should be the python3 one. [1] https://fedoraproject.org/wiki/Packaging:Python#Naming -- Juan Orti https://apuntesderootblog.wordpress.com/

5 6

How to package systemd user instance services?
by Tadej Janež 23 Nov '15

23 Nov '15

Hi! First a little context. I'm in the process of packaging bup [1] (review request [2]), a backup system based on the git packfile format. One of its sub-commands/functionalities is "bup web" [3], a web server for browsing through bup repositories. By default, "bup web" will show the bup repository stored in user's ~/.bup directory. Thus, it seems most appropriate to provide a systemd user instance service which a user can enable and start. Since the current systemd packaging guidelines [4] don't mention user instance services at all, I've researched this a bit and found that the systemd package ships /usr/lib/rpm/macros.d/macros.systemd file, which contains various "user" macros: - %_userunitdir - %systemd_user_post - %systemd_user_preun - %systemd_user_postun - %systemd_user_postun_with_restart My naive attempt at using them was to follow [4] and just replace all % systemd_* calls with appropriate %systemd_user_* calls (and %_unitdir with %_userunitdir). The SPEC file can be viewed here: https://github.com/tjanez/bup-package/blob/5f4abed/bup.spec However, this doesn't work as expected. This is the output of rpmlint: Rpmlint ------- Checking: bup-0.27-0.3.fc24.x86_64.rpm bup-web-0.27-0.3.fc24.x86_64.rpm bup-0.27-0.3.fc24.src.rpm bup.x86_64: W: spelling-error Summary(en_US) packfile -> pack file, pack-file, packsaddle [... trimmed spelling warnings ...] bup-web.x86_64: W: empty-%postun bup.src: W: spelling-error Summary(en_US) packfile -> pack file, pack-file, packsaddle [... trimmed spelling warnings ...] bup.src: E: specfile-error systemd_post: invalid option -- '-' bup.src: E: specfile-error error: Unknown option - in systemd_post() 3 packages and 0 specfiles checked; 2 errors, 15 warnings. Rpmlint (installed packages) ---------------------------- bup-web.x86_64: W: empty-%postun 3 packages and 0 specfiles checked; 0 errors, 1 warnings. I would appreciate help and feedback on this topic. Thanks and regards, Tadej [1] https://bup.github.io/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1222334 [3] http://bup.github.io/man/bup-web.html [4] https://fedoraproject.org/wiki/Packaging:Systemd

2 3

Self Introduction : Dhanesh Sabane
by Dhanesh Bhalchandra Sabane 22 Nov '15

22 Nov '15

Hello everyone, I am Dhanesh Sabane, a computer science student from Pune, Maharashtra, India. I've been a Linux user since 2011 and a Fedora fan boy since only a couple of months. It didn't take long for the Fedora community to woo me there after. :P I'm genuinely interested in being a integral part of the community and would love to establish liaison with other contributors. I've a FAS account [1] which, I'm sure, will fill up with a huge list of contributions with the help of the community. Fedora packaging has especially caught my eye and right after I'm done with my exams, I'll be looking forward to learning more about Packaging and contributing to the Fedora Project. I'll also be looking for mentors in the package maintainers field and I would really appreciate it if anyone is willing to take up that role. :P I'm currently associated with Mozilla as a*Firefox Student Ambassador* and as a*Support Volunteer*. You'll find my contribution story on my blog [2]. Looking forward to working in collaboration and helping the Fedora Project grow further. Until then, think open! 1.https://fedoraproject.org/wiki/User:Dhanesh95 2.https://openctrl.wordpress.com/category/mozilla/ -- Dhanesh Bhalchandra Sabane IRC : dhanesh95

2 2

Python C extensions permisions and rpmlint
by Sergio Pascual 20 Nov '15

20 Nov '15

Hello, I'm starting to use the new Python macros in my packages. Very good job, specfiles are much more cleaner now. One thing that doesn't change is the rpmlint error about .so files having mode 775 instead of 755 For example: E non-standard-executable-perm /usr/lib64/python2.7/site-packages/sep.so 775 I routinely do a chmod 755 after %install, but now that I'm using %py{2.3}_install, could this step be part of the macro? Or if the rpmlint error is inaccurate and 775 permisions are OK, fix rpmlint? Best, Sergio

3 2

Summary/Minutes from today's FPC Meeting (2015-11-19 17:00 - 17:50 UTC)
by James Antill 19 Nov '15

19 Nov '15

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 17:00:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2015-11-19/fpc.2015-11-19… . Meeting summary --------------- * Roll Call (geppetto, 17:00:22) * Schedule (geppetto, 17:04:03) * LINK: https://lists.fedoraproject.org/archives/list/packaging% 40lists.fedoraproject.org/thread/L3QD2JPSIIFN2M6BHLJJVLRHTYNR2LFN/ (geppetto, 17:04:07) * #579 Mention abipkgdiff and abidiff instead of abi-compliance-checker (geppetto, 17:04:40) * LINK: https://fedorahosted.org/fpc/ticket/579 (geppetto, 17:04:54) * ACTION: Dodji Will tweak the draft for the week after next. (geppetto, 17:36:24) * #558 Application/Library distinction and package splitting (geppetto, 17:39:49) * LINK: https://fedorahosted.org/fpc/ticket/558 (geppetto, 17:40:00) * Open Floor (geppetto, 17:45:46) Meeting ended at 17:51:29 UTC. Action Items ------------ * Dodji Will tweak the draft for the week after next. Action Items, by person ----------------------- * Dodji * Dodji Will tweak the draft for the week after next. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * Dodji (45) * geppetto (45) * Rathann (22) * orionp (13) * zodbot (10) * racor (7) * mbooth (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Schedule for Thursday's FPC Meeting (2015-11-19 16:00 UTC)
by James Antill 18 Nov '15

18 Nov '15

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2015-11-19 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2015-11-19 09:00 Thu US/Pacific PST 2015-11-19 12:00 Thu US/Eastern EST 2015-11-19 17:00 Thu UTC <- 2015-11-19 17:00 Thu Europe/London <- 2015-11-19 18:00 Thu Europe/Paris CET 2015-11-19 18:00 Thu Europe/Berlin CET 2015-11-19 22:30 Thu Asia/Calcutta IST ------------------new day---------------------- 2015-11-20 01:00 Fri Asia/Singapore SGT 2015-11-20 01:00 Fri Asia/Hong_Kong HKT 2015-11-20 02:00 Fri Asia/Tokyo JST 2015-11-20 03:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #558 Application/Library distinction and package splitting .fpc 558 https://fedorahosted.org/fpc/ticket/558 #topic #566 RPM file triggers .fpc 566 https://fedorahosted.org/fpc/ticket/566 #topic #567 Packaging Python 3 applications and modules for EPEL 7+ .fpc 567 https://fedorahosted.org/fpc/ticket/567 = New business = #topic #579 Mention abipkgdiff and abidiff instead of abi-compliance-checker .fpc NNN https://fedorahosted.org/fpc/ticket/NNN = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

2 2

For a cross-compiling toolchain, does it matter if /usr/bin/* links are symbolic or hard?
by Jonathan Dieter 16 Nov '15

16 Nov '15

I'm reviewing nacl-binutils (https://bugzilla.redhat.com/show_bug.cgi?i d=1270355), which has hard links from /usr/x86_64-nacl/* to /usr/bin/x86_64-nacl-*. According to https://fedoraproject.org/wiki/Pa ckaging_Cross_Compiling_Toolchains, these should be symlinks, and rpmlint complains about cross-directory-hard-links. Is there any reason to convert these to symlinks or can we just leave them as hard links? Thanks, Jonathan

4 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging November 2015