packaging July 2015

packaging@lists.fedoraproject.org

34 participants
32 discussions

RPM macro to match build arch
by Julien Enselme 06 Aug '15

06 Aug '15

Hi, I am in the process of packaging python-wsaccel (https://bugzilla.redhat.com/show_bug.cgi?id=1244517) This module contains C extensions and in order to launch the tests, I need to modify the python path so that the build module are found. The build directory to add to the path is like: build/lib.%{_os}-%{_target_cpu}-%{python3_version} This expression works fine with i686 and x64_84. However, on armv, %{_target_cpu} resolves to armv7hl whereas the folder is named lib.linux-armv7l-3.4. Previously, I tried the %{_host} macro but it extends to i386 instead of i686 for 32 bits build. Is there a macro that would correctly extends in all cases (x86_64, i686 and armv7l)? If not, I will use grep to get the proper folder name. Regards, -- Julien Enselme aka Jujens http://www.jujens.eu/

3 4

Help with private-shared-object-provides from rpmlint
by Dave Johansen 04 Aug '15

04 Aug '15

https://bugzilla.redhat.com/show_bug.cgi?id=1216279#c7 In the above review, rpmlint is outputting a private-shared-object-provides warning [1] and I don't understand what the issue is or how I go about fixing it. Any advice? Thanks, Dave [1]: https://fedoraproject.org/wiki/Common_Rpmlint_issues?rd=PackageMaintainers/…

3 9

vacation next week
by Orion Poplawski 31 Jul '15

31 Jul '15

I'll miss next weeks' meeting (Aug 6th). -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

1 0

Re: [Fedora-packaging] Darktable and Rawspeed
by Dominik 'Rathann' Mierzejewski 31 Jul '15

31 Jul '15

Hi, On Friday, 10 July 2015 at 09:35, Germano Massullo wrote: > Hi, I am Caterpillar, yesterday we were speaking about Darktable and > Rawspeed on Freenode. > I have a question: if Darktable's Rawspeed fork will be accepted to be > included in Fedora's repos, would it be possible to call it > "darktable-rawspeed" to distinguish and divide it from upstream Rawspeed? Well, ideally there should be just one canonical version of Rawspeed and it should come from the canonical upstream. Using a fork is allowed if original upstream is dead or unresponsive to bug reports, if it's compatible and if other projects have switched to it as well. I have provided some comments in your issue report on rawspeed's github: https://github.com/klauspost/rawspeed/issues/109 Could you please do the same in your report on darktable's redmine? I don't have an account there. http://redmine.darktable.org/issues/10582 Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

5 21

Summary/Minutes from today's FPC Meeting (2015-07-30 16:00 - 18:00 UTC)
by James Antill 30 Jul '15

30 Jul '15

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 16:00:39 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2015-07-30/fpc.2015-07-30… . Meeting summary --------------- * Roll Call (geppetto, 16:00:39) * Schedule (geppetto, 16:09:40) * LINK: https://lists.fedoraproject.org/pipermail/packaging/2015-July/010893.html (geppetto, 16:09:45) * #553 Spec file naming (geppetto, 16:09:55) * LINK: https://fedorahosted.org/fpc/ticket/553 (geppetto, 16:09:55) * ACTION: Spec file naming must match package (+1:6, 0:0, -1:0) (geppetto, 16:21:10) * #550 Darktable and Rawspeed internal library (geppetto, 16:21:53) * LINK: https://fedorahosted.org/fpc/ticket/550 (geppetto, 16:21:53) * ACTION: Without a timeline, or some other commitment from upstream we can't do much (too big to just ignore). (geppetto, 17:01:18) * Open Floor (geppetto, 17:01:23) * LINK: https://bugzilla.redhat.com/buglist.cgi?component=Package% 20Review&list_id=3682666&query_format=advanced&short_desc=darktable&short_desc_type=allwordssubstr (tibbs|w, 17:49:49) Meeting ended at 18:00:19 UTC. Action Items ------------ * Spec file naming must match package (+1:6, 0:0, -1:0) * Without a timeline, or some other commitment from upstream we can't do much (too big to just ignore). Action Items, by person ----------------------- * **UNASSIGNED** * Spec file naming must match package (+1:6, 0:0, -1:0) * Without a timeline, or some other commitment from upstream we can't do much (too big to just ignore). People Present (lines said) --------------------------- * tibbs|w (163) * geppetto (121) * Rathann (53) * tomspur (28) * orionp (14) * zodbot (12) * mbooth (8) * gbcox (5) * bochecha (3) * tibbs (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Re: [Fedora-packaging] jpopelka pushed to hplip (master). "merge hpijs into main package (#1033952#14)"
by Dominik 'Rathann' Mierzejewski 30 Jul '15

30 Jul '15

Hello, On Wednesday, 29 July 2015 at 18:56, notifications(a)fedoraproject.org wrote: > From 2ef869366f07cbddb2d5a9d91b5b3ac80a62a5a6 Mon Sep 17 00:00:00 2001 > From: Jiri Popelka <jpopelka(a)redhat.com> > Date: Wed, 29 Jul 2015 15:39:14 +0200 > Subject: merge hpijs into main package (#1033952#14) > > > diff --git a/hplip.spec b/hplip.spec > index 281d46e..87a98ee 100644 > --- a/hplip.spec > +++ b/hplip.spec [...] > +# hpijs was merged into main package in 3.15.7-2 > +Obsoletes: hpijs > +Provides: hpijs This is wrong. You should use versioned Obsoletes and Provides. Otherwise all kinds of mysterious side effects may occur. For example, triggers with conditions on hpijs don't work correctly anymore. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

2 1

Spec file naming
by Jason L Tibbitts III 29 Jul '15

29 Jul '15

I filed https://fedorahosted.org/fpc/ticket/553 to tighten up the naming of spec files. Currently the guidelines are a little loose with regards to this. I thought we tightened them up a long time ago, but I guess not. Here is the contents of the ticket to save you a click: I thought that at some point we tightened up the spec naming to absolutely require that the specfile for package asdfg be called asdfg.spec. However, the current guidelines say: The spec file should be named using the %{name}.spec scheme. This is to make it easier for people to find the appropriate spec when they install a src.rpm. There is normally no need to include the %{version} in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the %{name}.spec scheme (refer to Multiple Packages with the same base %name for details). In normal cases adding the version can cause the %spec file's history to be lost when a package's version is upgraded. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Spec_file_name On IRC today it was mentioned that fedpkg will look for any spec and pick the first one it finds (in os.istdir() order, so it's pretty much random). I'm thinking we should just tighten up the language here to say that you must call the spec %{name}.spec, and in addition move that section to the main guidelines. Or am I missing something? If there's a valid reason for having a differently-named spec file, I can think of what it would be. This would allow fedpkg to tighten up its method for finding the spec file, which would in turn allow people to check in other files named *.spec (for local edits or different compilation options, for example) without fear of fedpkg picking the wrong one. Proposed language: The spec file '''must''' be named <code>%{name}.spec</code>. That is, if your package is named <code>asdfg</code>, the spec file must be named <code>asdfg.spec</code>. Placed in a section "Spec Naming" just before "Spec Legibility" in the main guidelines page. - J<

4 4

Schedule for Thursday's FPC Meeting (2015-07-30 16:00 UTC)
by James Antill 29 Jul '15

29 Jul '15

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2015-07-30 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2015-07-30 09:00 Thu US/Pacific PDT 2015-07-30 12:00 Thu US/Eastern EDT 2015-07-30 16:00 Thu UTC <- 2015-07-30 17:00 Thu Europe/London BST 2015-07-30 18:00 Thu Europe/Paris CEST 2015-07-30 18:00 Thu Europe/Berlin CEST 2015-07-30 21:30 Thu Asia/Calcutta IST ------------------new day---------------------- 2015-07-31 00:00 Fri Asia/Singapore SGT 2015-07-31 00:00 Fri Asia/Hong_Kong HKT 2015-07-31 01:00 Fri Asia/Tokyo JST 2015-07-31 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #508 New GID for openstack-neutron .fpc 508 https://fedorahosted.org/fpc/ticket/508 #topic #550 Darktable and Rawspeed internal library .fpc 550 https://fedorahosted.org/fpc/ticket/550 = New business = #topic #553 Spec file naming .fpc 553 https://fedorahosted.org/fpc/ticket/553 = 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.

1 0

Python guidelines cleanup
by Jason L Tibbitts III 28 Jul '15

28 Jul '15

[Note that I've also posted a separate copy of this to the python-devel mailing list; I very rarely crosspost but I did want to make sure the relevant folks all saw a copy.] As many of you may be aware, FPC has been fielding several tickets surrounding python packaging lately, and the last one was a sizable reorganization that unfortunately was based on an older version of the guidelines. While merging it all together I just said screw it and cleaned up the page like I've always wanted to do. I suggest anyone who hasn't lost sanity due to this whole guidelines revision process pile onto: https://fedorahosted.org/fpc/ticket/552#comment:4 Here's the contents of that comment to save you a click. OK, this was a lot of stuff, and the more I worked on it, the more annoyed I became. Plus the wiki kept eating my edits and I kept getting lost in the overhuge page. So, I've probably gone too far in cleaning up but I'll present what I have and if people yell at me then I'll try something less ambitious. There are now three pages: https://fedoraproject.org/wiki/User:Tibbs/PythonCleanup2 https://fedoraproject.org/wiki/Packaging:Python_F21 https://fedoraproject.org/wiki/User:Tibbs/PythonAppendix The first page incorporates the following changes: * Notes that these guidelines apply only to F22+ and EPEL7. Points at the 2nd page for old guidelines. * Includes the information about not retiring python-version-specific subpackages in stable releases. * Makes BuildRequires: section much more succinct. * Makes sure python2-foo provide is versioned, mentions %python_provide macro. * Makes the macro table collapsible and collapsed by default. * Remove EL6-specific cruft (it's in the old guidelines page). * Move the parts of the byte compilation section that nobody ever uses off to the Appendix page. * Make the single-rpm single-dir case the default. Move the entire multiple-dir case to the appendix. * Completely remove %with_python3 from the example spec. We want people to build for python3. People just paste this in without knowing why they would ever need it. If you're using the new macros you can't just conditionalize for EL6 anyway. This really makes the spec look nice. Macro-izing the summary and description would make it look even nicer once the description gets longer than a line. * Uses a generic "example" module as an example. Two different approved proposals changed it to two different things; I just punted. * Puts the example spec all together without a bunch of text and admons and whatnot in the middle. * Moves the 2to3 section to the appendix. * Simply refers to the eggs section. That whole part at the bottom was quite awkward and I don't think most people even looked down that far. * Loads and loads of typo fixes, grammar fixes, and cleanups. The current main guideline page is now a bit over half the length it was and on the page it's less because of the collapsed macro table. I find it to be far more readable, and the sample spec no longer turns my stomach. The old guidelines page is just as it was before writing up the new macros, except that I added a short explanatory section at the top. The appendix page conveniently holds things which we probably should document but pretty much nobody would actually want to read without some specific reason. Functionally I do not believe I have gone beyond anything upon which we voted but I wanted to toss this out there and see if anyone yells before I copy it into place. Been trying to get this done for three days now and I think I'm finally there. - J<

1 0

Documentation packages and explicit Requires
by Michael Schwendt 26 Jul '15

26 Jul '15

After many years, there still is the occasional packager, who adds an explicit "Requires: %{name} = %{version}-%{release}" to a noarch -doc subpackage which contains files one can display with any suitable program (such as PDF, HTML or TXT files). I don't know why they do it. The "Requiring Base Package" guidelines leave enough freedom to not do it and even mention -libs subpackages as one example where the base dep is not "needed": https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package What do other packagers think about this? Can we please get rid of such bloat in plain Documentation packages? These dependencies pull in lots of stuff even if one only wants to peruse the documentation (e.g. when taking a brief look at an API or what an application can do).

8 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2015