packaging February 2014

packaging@lists.fedoraproject.org

32 participants
28 discussions

Packages with missing %check
by Alexander Todorov 25 Feb '14

25 Feb '14

Hi guys, I have identified 551 packages on the Fedora 20 source DVD which are missing a %check section in their spec files but are very likely to have a test suite. See https://github.com/atodorov/fedora-scripts/blob/master/sample-data/fedora-2… For a few of them I already had bug open previously (will filter the list later when I run my scripts against latest Rawhide). I have the following questions: 1) Do we consider this a bug and if yes what priority do you give it? From last week discussions it looks like most people prefer to have tests executed in %check. 2) Last week Alexander Kurtakov brought up the issue of packages executing their test suite during build. How to detect such packages? OTOH we can have some false negatives (also see 3). 3) Another proposal (sorry don't remember who proposed it) was to have %check with a comment why the test suite is not executed (e.g. requires network) or why it is executed in %build. I support this as it makes it clear to the QA person what is happening. This comment can be later extended to explain why a particular package is missing test suite (e.g. man pages or packages containing data files). How about making %check a packaging requirement in all cases - run tests or add a comment explaining why not, how to run them (e.g. make test) or why there are no tests for this package. -- Alex

3 2

Re: [Fedora-packaging] Packages with missing %check
by Dridi Boukelmoune 25 Feb '14

25 Feb '14

On Tue, Feb 25, 2014 at 2:50 PM, Adam Jackson <ajax(a)redhat.com> wrote: > On Tue, 2014-02-25 at 12:45 +0200, Alexander Todorov wrote: > >> 1) Do we consider this a bug and if yes what priority do you give it? From last >> week discussions it looks like most people prefer to have tests executed in %check. > > I don't consider %check to be an appropriate way to run tests, so no, I > don't consider it a bug. Stating it broadly: we don't have a separate > phase for it in koji, which means we can't adequately set up tests in > general; and adding it to koji would be a mistake, because build > construction and build validation are fundamentally different phases. I'd rather not discard %check when (blind guess) most of the test suites fit well there. Unless you're testing the package from the outside (let's say integration tests), you don't need another hook for the tests. Even for integration tests %check might still be relevant if you manage to keep them self-contained. I'm not saying I'm against a hook for non %check-able test suites :) Dridi > This is an argument against %check, not against testing in general. We > should be relying on rpmbuild less, not more. rpm doesn't even have > anything like Requires(check), does it? > > - ajax > > -- > devel mailing list > devel(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

1 0

Future of gridgengine package
by Orion Poplawski 24 Feb '14

24 Feb '14

Hello - I'm the maintainer of the Fedora gridengine package. Originally this was Sun's gridengine project. With the acquisition of Sun by Oracle, it was taken closed source again and then finally acquired by Univa. Univa does have a gridengine repository here: https://github.com/gridengine/gridengine but it hasn't been touched since 2012-06-01. When Sun was bought, two different projects took on maintaining the code based on the last released open source version: - OpenGridScheduler - http://gridscheduler.sourceforge.net/ which is what I started packaging in Fedora. It's last release was GE2011p1 on 2012-07-09, and only one commit since then. - Son of Grid Engine - https://arc.liv.ac.uk/trac/SGE/ which as is turns out seems to be much more active - most recent release is sge-8.1.6.tar.gz on 2013-10-28. So, I think it's time to finally switch to Son of Grid Engine (esp. for EPEL7). My question is, to I bite the bullet and submit a new package "sge"? One hesitation is that the SGE project provides rpms as well with the "gridengine" name, despite the tarball being "sge": http://arc.liv.ac.uk/downloads/SGE/releases/8.1.6/ It's kind of the name people are used to. If I keep the gridengine name I'll need to add an epoch (version 2011.11p1 ---> 8.1.6). If I move to sge, I assume I can: Obsolete: gridengine <= 2011.11p1-16 Provides: gridengine = 2011.11p1-17 ? Suggestions? Just needing some motivation and moral support really to pull the trigger. Thanks, Orion -- 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

2 1

May I file 1000 bugs aka upstream test suite tracking
by Alexander Todorov 24 Feb '14

24 Feb '14

Hi guys, (note: devel, packaging and test lists) previously I've done a little experiment and counted how many packages are likely to have upstream test suites and how many don't: http://atodorov.org/blog/2013/12/24/upstream-test-suite-status-of-fedora-20/ In general around 35% do have test suites, the rest don't. My goal is to bring down the number of packages which ship without any sort of test suite inside their code base. The first step is to identify them and track them in Bugzilla. My question is: **Is everyone, especially package maintainers OK with me filing 1000+ bugs ?** Last time I did so (around 100 bugs) it got a few people unhappy so better ask this time! If you are unhappy seeing such many bugs and having your mailbox full with notifications from Bugzilla please reply with a better proposal and why do you consider it better. Thanks, Alex

7 16

Re: [Fedora-packaging] Setting secure-file-priv in my.cnf
by Honza Horak 24 Feb '14

24 Feb '14

Hi Norvald, generally, I like the idea about using secure-file-priv, but I don't like /var/spool very much, since even if FHS describes this one quite generally, it is not used that way in practice. I also don't think we have to use something different than /var/lib, just a new directory other than /var/lib/mysql could be used; something like /var/lib/mysql-common maybe? -- that directory would also be covered by the current SELinux context definition /var/lib/mysql(/.*), so daemon would be able to access that directory without adjusting the SELinux context rules. Since this is mostly a packaging issue, I'm cc'ing also Fedora's packaging list to see if someone else has some better idea. Regards, Honza On 02/18/2014 10:31 AM, Norvald H. Ryeng wrote: > Hi Honza, > > We're looking at security hardening the default installation, and one > thing that came up was the secure-file-priv option, see > https://dev.mysql.com/doc/refman/5.6/en/server-options.html#option_mysqld_s… > and > https://dev.mysql.com/doc/refman/5.1/en/privileges-provided.html#priv_file. > > LOAD DATA, LOAD FILE() and SELECT ... INTO OUTFILE will cause the server > to import or export data. Since the server runs as mysql:mysql, it can > read from and write to /var/lib/mysql, which is not a good idea. > Therefore, I suggest we set secure-file-priv in my.cnf. The question is > where to put the directory. A directory inside /var/lib/mysql will be > interpreted as a new database, so that won't work. > > One suggestion is /var/spool/mysql. Import and export data is not > exactly spool data, but it fits the description in the FHS: "/var/spool > contains data which is awaiting some kind of later processing. Data in > /var/spool represents work to be done in the future (by a program, user, > or administrator); often data is deleted after it has been processed." > > What do you think? > > We'll have to ask for an SELinux policy change for this, so I want to > make sure we pick the right place for this directory from the start. > > Regards, > > Norvald H. Ryeng

1 0

Packaging:JavaScript correct macro?
by Jamie Nguyen 23 Feb '14

23 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, According to '/usr/lib/rpm/macros.d/macros.web-assets', ${_webassetdir} is the correct macro to use. I see two references to ${_assetdir}, instead of %{_webassetdir}, within these sections: https://fedoraproject.org/wiki/Packaging:JavaScript#Install_Location https://fedoraproject.org/wiki/Packaging:Web_Assets#Install_Location I'm guessing this is a remnant of previous revisions of the guidelines? - -- Kind regards, Jamie Nguyen -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTCdgiAAoJELjjfGIAZiqm8n8QAJIRdrYUa0vDE7FjmVO2pzTq Bkh4NTl69+MgWzOUfAoIA6xWEmOzeCycBjJsZZuHY94tWpTJ5gZJv/NGSirVfpXp nF1nLSjs72+zpTgMmPTJhB2z8QJyTCz2z/NtP9yfwBr5CKybg03SGlKxFl/chPq0 KDRa3fXzv+Pw3S3+zLka3b+AMz+AKNKBD3NxcVlbQ6Shg5mXhLsLKHjmKLtq2+fH fCFA4W+S0zuS7q/y3Amv4STPNDGRZ+l0mVzEP+3eIiqAGd2mS65vhgN39GNHPXgj 65i7wLEbAm2ak+l/LUCavHZu6fUGLUXDDrTQYFdBCBcy6uSClFzs2e2zNbeY4jcu acl+d2He0p0MinK4b0DKCqnsrTnc/dXM6ShfARBcq+pVVybv7bcORO8dY6TD1sAg TyVqU/RIBcOLHhpUAsE5QQAJajVrO3hB3x2zMzEPqu0domcIMBDbDP9WZKPNITkK G9kWQqSPMjky9m3pLlosYxy1GRy48U55CIDbO4flusx1mwIR6yvfXEHpCCfFB4kJ WbAm6tuixXY9MkBbQMqO53UsoNS51kXZGafff0ARVIXTxqAsg6A8TD5jqeCFmbaQ 906U2K776Mjf2t0J8Tb0ZaMPaWDb6pogjJwAw7Hg3xTYBoorUan/iaE08k8OlSi8 7xcAurbF6abkHykLJMNw =iHN1 -----END PGP SIGNATURE-----

1 0

Bodhi new package "Details" text
by Shawn Iwinski 21 Feb '14

21 Feb '14

When releasing new packages in Bodhi, does the text in the "Details" section matter? I'm wondering if I need to do a bunch of tightly-coupled new releases separately or if I can do them all together. Shawn

2 1

Summary/Minutes from today's FPC Meeting (2014-02-20 17:00 - 19:00 UTC)
by James Antill 20 Feb '14

20 Feb '14

====================== #fedora-meeting-1: fpc ====================== Meeting started by abadger1999 at 17:00:12 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-20/fpc.2014-02-20… . Meeting summary --------------- * Roll Call (abadger1999, 17:00:19) * #339 software collections in Fedora (abadger1999, 17:02:32) * LINK: https://fedorahosted.org/fpc/ticket/339 (abadger1999, 17:02:36) * LINK: http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-Python2.4/ (abadger1999, 17:04:40) * LINK: http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-scl-utils/ (abadger1999, 17:04:50) * #382 Go Packaging Guidelines Draft (abadger1999, 17:05:13) * LINK: https://fedorahosted.org/fpc/ticket/382 (abadger1999, 17:05:19) * Have the version/release section simply point to the existing guidelines [propose updates to the existing guidelines if they should be clarified] (abadger1999, 17:14:19) * link to ""standard Fedora version conventions" is to the wrong page... should go to https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning (abadger1999, 17:15:17) * debuginfo/strip => Note that guidelines will change when tools catch up. Link to the bug reports for the tools doing the wrong thing. (abadger1999, 17:16:49) * create a %go_arches macro as mentioned in https://fedorahosted.org/fpc/ticket/382#comment:1 (abadger1999, 17:21:33) * either move the naming of programs section to the naming section or move the current naming section into the libraries section. (abadger1999, 17:22:53) * In Packaging Libraries, prepend it with "At this time"... the tooling may eventually reach a point where we do encourage people to develop against the system packages. (abadger1999, 17:25:49) * @mattdm: we'd like more info on the strip issues, bug links might provide that. (abadger1999, 17:31:31) * @mattdm, Can you point us to documentation that verifies that prebuilt libraries are tied to the exact minor release of the golang compiler? (abadger1999, 17:54:57) * #392 bundling expception for greenmail (abadger1999, 17:56:05) * LINK: https://fedorahosted.org/fpc/ticket/392 (abadger1999, 17:56:08) * greenmail's use of foedus considered a fork (which is allowed) (+1:5, 0:0, -1:0) (abadger1999, 18:41:46) * #390 Reserve static uid/gid for activemq (abadger1999, 18:48:03) * LINK: https://fedorahosted.org/fpc/ticket/390 (abadger1999, 18:48:09) * static uids for activemq approved (+1:5, 0:0, -1:0) (abadger1999, 18:55:09) * Open floor (abadger1999, 18:56:15) * LINK: https://fedorahosted.org/fpc/ticket/395 (willb, 18:56:46) Meeting ended at 19:01:29 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * abadger1999 (111) * tibbs|w (43) * Rathann (18) * rsquared (17) * geppetto (14) * limburgher (9) * SmootherFrOgZ (8) * zodbot (7) * willb (7) * racor (6) * rsquared_ (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Schedule for Thursday's FPC Meeting (2014-02-20 17:00 UTC)
by James Antill 19 Feb '14

19 Feb '14

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-02-20 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-02-20 09:00 Thu US/Pacific PST 2014-02-20 12:00 Thu US/Eastern EST 2014-02-20 17:00 Thu UTC <- 2014-02-20 17:00 Thu Europe/London <- 2014-02-20 18:00 Thu Europe/Paris CET 2014-02-20 18:00 Thu Europe/Berlin CET 2014-02-20 22:30 Thu Asia/Calcutta IST ------------------new day---------------------- 2014-02-21 01:00 Fri Asia/Singapore SGT 2014-02-21 01:00 Fri Asia/Hong_Kong HKT 2014-02-21 02:00 Fri Asia/Tokyo JST 2014-02-21 03:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 #topic #385 workarounds for rpm symlink <-> directory issue .fpc 385 https://fedorahosted.org/fpc/ticket/385 #topic #388 recommend %autosetup over %setup .fpc 388 https://fedorahosted.org/fpc/ticket/388 = New business = #topic #390 Reserve static uid/gid for activemq .fpc 390 https://fedorahosted.org/fpc/ticket/390 #topic #391 Exception for bundled libraries in icecat .fpc 391 https://fedorahosted.org/fpc/ticket/391 #topic #392 bundling expception for greenmail .fpc 392 https://fedorahosted.org/fpc/ticket/392 #topic #393 New Packaging Guidelines: Drupal 7 .fpc 393 https://fedorahosted.org/fpc/ticket/393 = 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/12 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 tha

2 1

Re: [Fedora-packaging] Downstream .so versioning
by Honza Horak 19 Feb '14

19 Feb '14

On 01/15/2014 04:16 PM, Jan Staněk wrote: > What should one do if the SW he is trying to package produce only > unversioned *.so files? I'm currently trying to package LMDB [1] as > possible alternative for BerkeleyDB in Fedora, and the hand-written > makefile produce only liblmdb.so. > > I'm trying to persuade the upstream to change it and start to do it > properly, however if that fails, what can I do with it on my end? First, I'd say we really should provide versioned soname every-time, if the library is considered a usual library that other packages can link against. The question is what downstream versioning schema to chose. (side note: versioned soname doesn't seem to be necessary in case of libraries loaded on runtime using dlopen -- usually extensions, where library version is usually checked as well during runtime) Looking around to some other projects (e.g. v8) people usually tend to use version of the package to be soname version of the library. However, I see some questions raised by that approach: Problem #1: It can happen that upstream can introduce soname versioning at some point (using x.y.z schema that doesn't correspond with project version) and it can result in having two libraries with the same soname (downstream's based on version and upstream's based on some other schema). Nothing very probable but still better to avoid. Solution: Using schema "0.version" for library soname should work the same as when we provide pre-release versions. Example: Upstream for package abc-1.2.3 provides unversioned library libabc.so, so we should provide versioned library libabc.so.0.1.2.3 downstream. Problem #2: Upstream usually keeps compatibility on *some* version level (sometimes it is major, sometimes minor version), but usually we are able to say which versions are expected to be compatible. That is what soname should correspond with and not blindly use first number as a soname. Solution: Use the soname scheme that correspond with upstream's compatibility scheme/policy. Example: Upstream of package abc-1.2.3 keeps compatibility for the minor version, so all versions of 1.2.x are compatible, while 1.3.x are generally not compatible with 1.2.x. We should then use soname libabc.so.0.1.2 (not just libabc.so.0.1). Result of such a package would be: * libabc.so.0.1.2.3 as an actual library file * link libabc.so -> libabc.so.0.1.2.3 * link libabc.so.0.1.2 -> libabc.so.0.1.2.3 * rpmbuild would generate an automatic provide libabc.so.0.1.2()(x86_64) I believe this should be somehow incorporated into packaging guidelines, but before creating a draft, I wanted to consult this publicly, so we can choose the best way. Regards, Honza

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2014