packaging December 2008

packaging@lists.fedoraproject.org

21 participants
17 discussions

Re: fontpackages template warnings
by Nicolas Mailhot 02 Jan '09

02 Jan '09

Le Mar 30 décembre 2008 16:37, Nicolas Mailhot a écrit : > > Le Mar 30 décembre 2008 15:29, Sarantis Paskalis a écrit : >> Hello, > > Hi, > > Thank you for adapting your packages and providing feedback! > >> I am converting my font packages to the new guidelines and hit some >> rpmlint warnings that appear to be template related. Specifically, >> I >> followed the /etc/rpmdevtools/spectemplate-fonts-multi.spec from >> fontpackages-devel that creates absolute symlinks between >> /etc/fonts/conf.d/$font.conf and >> /usr/share/fontconfig/conf.avail/$font.conf >> rpmlint moans about the absolute symlink and wants a relative one. >> I >> don't really have an opinion about that and could not find any >> fedora >> policy on this one [1]. > > I didn't find a simple (for me and packagers) way to create relative > symlinks here. Individual packages are not supposed to know the values > of the directory macros since FPC asked for them in part to hide > future value changes from individual packagers. drat, should have read your link before commenting. I'm not sure how ok it is to add a dep to symlinks for fontpackages-devel. It looks harmless enough, but is this package even in all our spins? I suppose if I change the templates to use the symlinks command to avoid the rpmlint warning, I need to notify FPC at least (even if it's a minor change, it's still a guidelines change) -- Nicolas Mailhot

3 5

Problems accessing Koji website.
by Henrique Junior 26 Dec '08

26 Dec '08

Hello, everyone. I am submitting my first package and found some difficulty accessing Koji's website[1]. As specified in the "PackageMaintainers /Join"[2], I've runned "fedora-setup package", creating the file ~/fedora-browser-cert.p12. Importing it to Firefox [3] I went to the Koji' page and get a first warning that said that Koji's page doesn't have a trusted certificate (Error code: sec_error_untrusted_issuer); continue adding an exception, the page to check my ssl certificate returned the following error: (Error code: ssl_error_revoked_cert_alert). Am I doing something wrong? Excuse me for the inconvenience. Happy new year to all. [1] - https://koji.fedoraproject.org/koji/login [2] - https://fedoraproject.org/wiki/PackageMaintainers/Join [3] - http://img267.imageshack.us/img267/3248/capturadetelakj3.png -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!"

1 0

Missing links in Packaging:Debuginfo
by Ville Skyttä 25 Dec '08

25 Dec '08

The "StackTraces" words in https://fedoraproject.org/wiki/Packaging:Debuginfo are no longer linked to https://fedoraproject.org/wiki/StackTraces

2 1

Usage of {_libdir} or {_lib} in noarch packages
by Karsten Hopp 22 Dec '08

22 Dec '08

I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages which erronously use {_libdir} or {_lib} in their spec files. rpmdiff shows this output: ./firstaidkit-0.2.2-5.fc11.noarch.rpm removed /usr/lib/firstaidkit removed /usr/lib/firstaidkit/plugins added /usr/lib64/firstaidkit added /usr/lib64/firstaidkit/plugins As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs Here is the list of offending packages I've found: Package Owner ------------------------ ntfs-config laxathom firstaidkit msivak terminus-font ndim gdeskcal pfj libopensync-plugin-synce awjb cohoba tjikkun gnome-schedule farnold common-lisp-controller green gcstar tian revisor-cli jsteffan jruby konradm Can we make it a policy to not use _libdir or _lib in noarch packages, please ? Karsten

9 13

Font package splitting clarification
by Nicolas Mailhot 22 Dec '08

22 Dec '08

[Drat. I *knew* I had forgotten to spam one list] Hi all, Since the discussion on font package splitting rules seems to be exhausted, and since no one stepped up with an obviously better proposal than mine, I've queued the following FPC-side: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_… I've tried to integrate all the exceptions that were brought up during the discussion and that were consensual, and to separate the rules from their rationale (so packagers in a hurry only need to read the first part). I've ended up with four simple master rules that should not be open to interpretation. Best regards, -- Nicolas Mailhot

1 0

Font package naming guidelines
by Nicolas Mailhot 22 Dec '08

22 Dec '08

Hi, Since there has been no more remarks on the clarified font package naming rules discussed as part of http://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes_(2008-1… I've queued the following for approval FPC-side: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_(2008-12-… Except for the comps changes which seem not baked yet, that concludes the fonts-related guidelines changes and clarifications that were proposed for F11. Sincerely, -- Nicolas Mailhot

1 0

Ownership of /usr/share/gnome/help
by Jason L Tibbitts III 15 Dec '08

15 Dec '08

Can someone tell me what package should own /usr/share/gnome/help, or if individual packages placing files there should own it? The latter seems to be the case, but that doesn't make a whole lot of sense to me. Is there any reason why /usr/share/gnome/help shouldn't just be owned by filesystem? It already owns /usr/share/gnome. Actually, it seems that several other packages own /usr/share/gnome too, which probably begs for some bugs to be filed. - J<

4 11

"ratify"
by Andrew Overholt 12 Dec '08

12 Dec '08

Hi, I couldn't find the meeting minutes for the most recent meeting but did find that my proposed changes to the Eclipse plugin packaging guidelines have the "ratify" status meaning they need to be run by FESCo. Does this mean I need to be present during a FESCo meeting? If they're passed by FESCo, will the changes be applied or do I need to do something? Thanks, Andrew

3 3

guidelines for dbus services
by Matthias Clasen 12 Dec '08

12 Dec '08

In the light of the recent dbus debacle, I think it would be very good to add a section about dbus services to the packaging guidelines. As we have painfully learned, an incorrect policy file for a third-party service can render the entire system bus unusable, or open it up to everybody, so it is important that packagers pay attention to the dbus policy files in their packages. I don't have a concrete proposal right now, but Colin made a good start at writing up some best practices here: http://lists.freedesktop.org/archives/dbus/2008-December/010717.html Matthias

2 1

Including a patched version of an upstream library -- advice?
by Mary Ellen Foster 12 Dec '08

12 Dec '08

So I decided to try upping my own review karma by trying to review some outstanding Java packages. Unfortunately, I seem to have chosen one with an "interesting" issue: https://bugzilla.redhat.com/show_bug.cgi?id=464013 The package in question is "findbugs-bcel": an alternative version of the bcel library (already in Fedora), including a fairly large patch from the developers of the "findbugs" package. There seems to be no hope of getting this patch into upstream bcel (e.g., https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2007-April/001880.html) There was a short discussion on this on fedora-devel-list last year: http://www.redhat.com/archives/rhl-devel-list/2007-September/msg00865.html What's the official policy here? I guess I should try to find a more straightforward package for my first review ... MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universität München and ICCS, School of Informatics, University of Edinburgh

2 1

Group tag for Java libraries and their documentation
by Mary Ellen Foster 10 Dec '08

10 Dec '08

Going by the options proposed by rpmlint, the only possible tag for any development library -- whatever language it's written in -- is "Development/Libraries". At the same time, there are lots of packages using "Development/Libraries/Java"; on my computer, rpm -q -g Development/Libraries/Java | wc -l yields 46 of them. I also have the same question about "Documentation" vs. "Development/Documentation" for javadoc packages -- rpmlint only accepts the former, but a nontrivial number of packages use the latter. So what's the official verdict on this? Thanks, MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universität München and ICCS, School of Informatics, University of Edinburgh

4 4

adding INSTALL="install -p" to %configure
by Till Maas 09 Dec '08

09 Dec '08

Hi, the current Guidelines recommend to preserve timestamps when adding commands that copy files to a spec file: https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps Currently this is often in reviews also checked for commands that are e.g. in upstreams Makefile. If you think that this should be done, can you please adjust the Guidelines to reflect this and add "INSTALL='install -p'" to %configure, to make this automatically happen for packages using autotools? Regards, Till

1 0

MinGW subpackages of OCaml packages
by Richard W.M. Jones 09 Dec '08

09 Dec '08

So as I mentioned before we have an OCaml Windows cross-compiler as part of the Fedora MinGW project: http://hg.et.redhat.com/misc/fedora-mingw--devel/ (click 'manifest' then 'ocaml' or the 'ocaml-*' subdirectories) mingw32-ocaml - the cross-compiler (native Fedora prog) mingw32-ocaml-calendar - cross-compiled OCaml Calendar library mingw32-ocaml-csv - cross-compiled OCaml CSV library mingw32-ocaml-curses - cross-compiled OCaml curses bindings mingw32-ocaml-extlib - cross-compiled OCaml extlib (library) mingw32-ocaml-findlib - (this just has a single config file) mingw32-ocaml-lablgl - cross-compiled OCaml OpenGL bindings mingw32-ocaml-lablgtk - cross-compiled OCaml Gtk bindings mingw32-ocaml-libvirt - cross-compiled OCaml libvirt bindings mingw32-ocaml-xml-light - cross-compiled OCaml XML library When we were doing the original packaging, we explored the option of building the MinGW packages as subpackages of the native Fedora packages, eg: the gnutls specfile would contain the '-n mingw32-gnutls' subpackage. This would have made it simpler to keep the packages in synch with native Fedora, but we felt that native packagers wouldn't be so happy about this. They wouldn't be expert in MinGW packaging, and would drop the MinGW subpackage at the first sign of trouble. However, since I'm in the unique position of maintaining most of the corresponding ocaml-* (native) and mingw32-ocaml-* (cross-compiled) packages, I would like to ask whether I can create the packages above and others in future as subpackages of the already approved ocaml-* native packages. I'm not looking for any exception to the relevant packaging guidelines, which I would try to follow (excepting any mistakes). If you want to see what some RPMs look like, see: http://www.annexia.org/tmp/mingw/fedora-10/x86_64/RPMS/ Thoughts? I set follow-ups to the fedora-packaging list. Rich.

4 10

Updates to Eclipse Plugin packaging guidelines
by Andrew Overholt 08 Dec '08

08 Dec '08

Hi, I have a few updates to the Eclipse Plugin packaging guidelines. They include some clarifications, typos, and updates for Eclipse 3.4.x. The only bit of real substance is modifying the template to note how we're using the dropins mechanism for plugin installation in 3.4.x and above. I've attached a diff 'cause I don't think I can commit it. Can someone else? Thanks, Andrew

5 6

Task work needed
by Jesse Keating 07 Dec '08

07 Dec '08

Some small busy work needed, somebody to ensure each Review Guideline item in http://fedoraproject.org/wiki/Packaging/ReviewGuidelines has a matching guideline entry in https://fedoraproject.org/wiki/Packaging/Guidelines (or subpages). Bonus points for creating links in the ReviewGuidelines to the matching rule in the Guidelines. Case in point; Can anybody tell me where the guideline exists for: - SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. ? (this is suddenly a lot more relevant as rpm picks up pkg-config deps automatically and is dragging in quite a lot of -devel packages on otherwise non-devel installs due to .pc file placement) -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

1 0

Error when building: gimptool-2.0: Permission denied
by Fabian Deutsch 07 Dec '08

07 Dec '08

Hey, I'm new to packaging packages and tried to build a new package for some gimp plugin. I can build the package local, but building it via koji fails with the following error: https://koji.fedoraproject.org/koji/getfile?taskID=985724&name=build.log Can some give me a hint what it migth be? Greetings fabian

1 1

Problems with the .info file
by Fabian Affolter 06 Dec '08

06 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, As I mentioned in the subject of this message, I have a problem with the .info file in a package. I'm able to build the package locally but mock fails. I guess that I missed something... Spec file (only the relevant parts): ... Requires(post): /sbin/install-info Requires(preun): /sbin/install-info ... %post /sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || : ... %preun if [ "$1" = 0 ]; then /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || : fi ... %files -f %{name}.lang %defattr(-,root,root,-) %doc AUTHORS ChangeLog COPYING NEWS README TODO %{_infodir}/%{name}.info.gz ... mock complains about installed but not packaged file '/usr/share/info/dir' . Did I miss a directory? Can please anybody give me a hint? Thanks in advance. Kind regards, Fabian SRPM: http://fab.fedorapeople.org/packages/SRPMS/wol-0.7.1-1.fc9.src.rpm SPEC: http://fab.fedorapeople.org/packages/SRPMS/wol.spec - -- Fingerprint: 2F6C 930F D3C4 7E38 6AFA 4EB4 E23C D2DD 36A4 397F Fedora always leads and never follows. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkk6yAMACgkQ4jzS3TakOX9pmQCfTOFxTL4XFBuGq4+par9+lJ41 NYQAn1/D9Ct29WNWLxFOz39hZhO19plX =J7BS -----END PGP SIGNATURE-----

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging December 2008