Packages with missing %check
by Alexander Todorov
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...
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
9 years, 9 months
Re: [Fedora-packaging] Packages with missing %check
by Dridi Boukelmoune
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
9 years, 9 months
Future of gridgengine package
by Orion Poplawski
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
9 years, 9 months
May I file 1000 bugs aka upstream test suite tracking
by Alexander Todorov
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
9 years, 9 months
Re: [Fedora-packaging] Setting secure-file-priv in my.cnf
by Honza Horak
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...
> 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
9 years, 9 months
Packaging:JavaScript correct macro?
by Jamie Nguyen
-----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-----
9 years, 9 months
Bodhi new package "Details" text
by Shawn Iwinski
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
9 years, 9 months
Summary/Minutes from today's FPC Meeting (2014-02-20 17:00 - 19:00 UTC)
by James Antill
======================
#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-...
.
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
9 years, 9 months
Re: [Fedora-packaging] Downstream .so versioning
by Honza Horak
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
9 years, 9 months
