packaging July 2012

packaging@lists.fedoraproject.org

24 participants
14 discussions

Get paid to package! (Etherpad Lite)
by Rich Jones 20 Feb '13

20 Feb '13

Hey all! I didn't post this bounty, but it came across our system and it seems like you guys might be able to earn a quick bit of money on this one: http://gun.io/contracts/16/rpm-based-install-for-etherpad-lite-on-rhel-128 Any takers? -- Rich Jones Director, Gun.io

7 6

Distributing prebuilt bios roms with QEMU
by Cole Robinson 31 Jul '12

31 Jul '12

Hi all, QEMU release tarballs contain a handful of prebuilt roms that enable various features and emulation targets. We currently don't package any of these roms. For things like seabios, sgabios, vgabios, and ipxe, we can chuck out the prebuilt data and depend on natively built Fedora packages. However a handful of the roms require building on non-x86 (ppc, sparc32/64, s390). Being able to package the prebuilt roms would enable us to distribute working qemu-system-{ppc*,sparc*,s390*} Does this sound reasonable, and if so, what's the process for getting this approved? I'm looking at: http://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-buil… http://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware And it sounds like this is a reasonable case for exception, but just want to confirm. Here's all the details I can gather about the roms: /usr/share/qemu/openbios-ppc /usr/share/qemu/openbios-sparc32 /usr/share/qemu/openbios-sparc64 Usage : Needed for emulation of certain machines for those architectures. Source : http://git.qemu.org/openbios.git License : GPLv2 http://git.qemu.org/?p=openbios.git;a=blob;f=COPYING /usr/share/qemu/slof.bin Usage : Needed for PPC pSeries emulation Source : http://git.qemu.org/SLOF.git License : BSD http://git.qemu.org/?p=SLOF.git;a=blob;f=LICENSE /usr/share/qemu/palcode-clipper Usage : Needed for s390 emulation Source : http://repo.or.cz/w/qemu-palcode.git License : GPLv2 http://repo.or.cz/w/qemu-palcode.git/blob/HEAD:/COPYING /usr/share/qemu/s390-zipl.rom Usage : Needed for s390 emulation Source : http://repo.or.cz/w/s390-tools.git License : GPl http://repo.or.cz/w/s390-tools.git/blob/HEAD:/LICENSE /usr/share/qemu/ppc_rom.bin Usage : Needed for PPC PREP emulation Source : https://github.com/tycho/openhackware License : GPLv2 https://github.com/tycho/openhackware/blob/master/COPYING And some compiled device trees. Maybe these just count as program data though? /usr/share/qemu/bamboo.dtb Usage : Needed for PPC bamboo machine. Source : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=a… License : GPLv2 /usr/share/qemu/petalogix-ml605.dtb /usr/share/qemu/petalogix-s3adsp1800.dtb Usage : Needed for microblaze emulation Source : Hmm, actually I can't seem to find any canonical source :( Thanks, Cole

5 10

May binaries be built from generated "source" code?
by Björn Persson 30 Jul '12

30 Jul '12

The Packaging Guidelines require that all binary programs and libraries be built from source code. How should this requirement be interpreted when some of the "source code" is itself automatically generated from other sources? GTKada is an Ada binding to GTK+. In the latest version, some of the Ada files in the source tarball have been generated by a program that is included in the tarball. Future versions will have even more generated code. The input to the code generator is a GIR file, which as far as I understand is some kind of XML representation of the GTK+ API. The GIR file has in turn been generated from the C source code of GTK+. The GIR file is included in the GTKada tarball, but the GTK+ source is not. Now I'm trying to figure out whether I can build the GTKada package from the distributed generated Ada code, or whether I have to run the code generation as a part of the build, possibly using the GIR file from the GTK+ package instead of the one in the GTKada tarball. There are two reasons for the requirement listed in the guidelines: · "Security: Pre-packaged program binaries and program libraries not built from the source code could contain parts that are malicious, dangerous, or just broken. Also, these are functionally impossible to patch." The generated Ada code is nicely formatted and legible, and no harder to review than hand-written source code. It would be possible to patch it, although such a patch would of course not be upstreamable. · "Compiler Flags: Pre-packaged program binaries and program libraries not built from the source code were probably not compiled with standard Fedora compiler flags for security and optimization." This obviously doesn't apply to generated code that hasn't yet been through a compiler. Thus, none of the stated reasons seem to be relevant to this case, and I can see only one thing that could mean that I have to run the code generation as a part of the build, namely the term "source code". My question is: Is it required that all the steps in the process from the actual source code to binary code take place on Fedora's build servers, or is it sufficient that binaries are built from human-readable code even if that code isn't the actual source code? In other words: Should I read "source code" literally, as "the ultimate source code written by human programmers", or is it OK, for the purpose of this requirement, to read it as "human-readable code in a textual programming language"? Björn Persson

3 4

refuse an upgrade?
by Paul Wouters 25 Jul '12

25 Jul '12

Hi, Is there an accepted/allowed method for refusing an upgrade in %pre ? Say there is a package foo for which we only released version 2.x. An upgrade from 1.x to 2.x would not work due to database migration issues. A third party ships 1.x versions. I would like our 2.x package to refuse to do an upgrade from an 1.x package.

2 2

.desktop file - desktop-file-install - recent changes ?
by Development discussions related to Fedora 24 Jul '12

24 Jul '12

The F18 rebuild-all picked up a problem in my package tnef: + desktop-file-install --dir=/builddir/build/BUILDROOT/tnef-1.4.8-6.2.fc18.i386/usr/share/kde4/services /builddir/build/SOURCES/tnefextract.desktop /builddir/build/BUILDROOT/tnef-1.4.8-6.2.fc18.i386/usr/share/kde4/services/tnefextract.desktop: error: file contains key "Type" in group "Desktop Action tnefExtractToSubfolder", but keys extending the format should start with "X-" /builddir/build/BUILDROOT/tnef-1.4.8-6.2.fc18.i386/usr/share/kde4/services/tnefextract.desktop: error: key "Actions" is present in group "Desktop Entry", but the type is "Service" while this key is only valid for type "Application" Error on file "/builddir/build/SOURCES/tnefextract.desktop": Failed to validate the created desktop file RPM build errors: ----- The source .desktop file: [Desktop Entry] Type=Service X-KDE-Priority=TopLevel X-KDE-ServiceTypes=KonqPopupMenu/Plugin,application/vnd.ms-tnef Name=tnef tools Comment=tnef archive tool menu Icon=archive-extract Actions=tnefExtractToSubfolder; [Desktop Action tnefExtractToSubfolder] Type=Application Name=Extract TNEF (email attachment) Archive Exec=tnef.sh "%f" Icon=archive-extract ----- In F15/16/ this created a kde file association for winmail.dat files in the file manager, and a menu entry to "Extract TNEF Archive". Where can I find information on how this works now, or is desktop-file-validate/install tripping up ?

2 2

Re: [Fedora-packaging] packaging Digest, Vol 89, Issue 10
by benedikt＠schaefer-flieden.de 23 Jul '12

23 Jul '12

My EMail address has changed to b.schaefer(a)flieden.org Your EMail was forwarded to my new address! Please send all mail on my new address!

1 0

RPM macros
by Vít Ondruch 23 Jul '12

23 Jul '12

Hi, I noticed that in revised haskell guidelines [1], there is mentioned the ghc-rpm-macros package, which provides macros.ghc file, which in turns provides some useful macros for packaging of Haskell packages. In Ruby, we provide similar macro files in ruby-devel and rubygems-devel subpackages respectively. Perl has their macros directly in the rpm package itself. This seems to be a bit inconsistent to me. So my question is: shouldn't we standardize some best practices with regards of RPM macros? For example for Ruby, we placed the macros into -devel subpackages, because we believe that it is just development dependency. Any opinions? Vit [1] http://lists.fedoraproject.org/pipermail/packaging/2012-July/008527.html

7 11

clarification: python2 modules allowed to go into python2-foo?
by Thomas Spura 18 Jul '12

18 Jul '12

Hi, currently we are discussing, if it makes more sense to provide a python-ipython package or a python2-ipython package, because we are restructuring the package structure of ipython anyway right now [1]. The current python guidelines [2] don't mention, if new python2 providing modules still must/may/should be in a python-foo package, or if it would be better to put them directly into an python2-foo package. Reasoning for python2-foo: When /usr/bin/python will provide python3, this means, that the normal python-foo MUST be build with python3 as python needs to refer to the current default /usr/bin/python --version. Reasoning for python-foo: The majority of modules providing python modules have a python-foo structure. So when switching to /usr/bin/python = python3, it would also make sense to ONLY do that with the main python package, but all python-foo package still provide python2 modules and when you want to have python3 modules, you MUST require python3-foo. The drawback is, that you cannot rely on "The package which is named python-foo will be build with the default python interpreter." I'd vote for python2-foo for new packages and renaming the old python-foo packages unless they build for $current supported python versions (atm: python2 AND python3) at the same time (and python3-foo for python3 modules etc). That pythonX-foo package, where X is the first digit of the default python interpreter MUST provide python-foo. This will allow us to be ready for python3,python4,python5,python4711... What is your opinion towards this? Greetings, Tom P.S.: For the case of ipython, we can still leave it at ipython without any pythonX- in front of it to avoid this, but it would be great to have a general guidelines for this and I'm happy to help renaming old packages/move forward to python4711. [1] http://fedoraproject.org/wiki/Features/IPython_0.13 [2] http://fedoraproject.org/wiki/Packaging:Python

3 2

Re: [Fedora-packaging] Script-Tools, which location?
by Simon A. Erat 12 Jul '12

12 Jul '12

First of all, whats the acronym FHS standing for? You asked for a better explanation, i hope i can deliver it. Script-Tools has several purposes and ideas behind its creation. 1) At first it was designed to be distributed as tarball, i want to keep this option, as this allows an easy port/install to any other linux distro. (just extract anywhere of your choice and run from there) 2) Easy - Reusability 3) Easy - Set and forget As i was told, Fedora doesnt allow to install packages at custom locations, allthough it describes how-to in the docs... weird imho... If i take this as a fact, and refer to your saying, /usr/share/%name is ment for read-only files, it would be a good match after all, as i currently save any data in $HOME/bin/$USER-libs, and offering $HOME/bin/$USER-scripts to be used for custom scripts using the functions which Script-Tools provides. But... as i will going to get the use of /usr/bin for the start-script, i wonder if $HOME/bin/$USER-libs|*-scripts is acceptable, specialy since none of them are required. However, i'll have to rewrite the dev section, so it stores the project|rpm|sourceforge info somewhere in $HOME/.config or so? > That sounds a bit like a design mistake. Can you tell why you think you > would need a directory structure below /usr/bin and not elsewhere? After a rethought, the only thing that could be placed in /usr/bin would be the starting script, and those files in $stDir/scripts. And that file can refer to /usr/share/%name to find all sub-folders /files. The other 'single' scripts, which until now reside in $stDir/scripts do not use the functions the Script-Tools provide, so that wouldnt be a problem. Placing the main script (or a symlink) to /usr/bin would also no longer need /etc/profile.d/%name.sh. Got to say, i start liking this idea, until now i didnt feel comfortable doing so, as i thought "its just my script, nothing high-end-professional/required". Gosh this is more of a chat than an explanation, i'm sorry. 2012/7/12 <packaging-request(a)lists.fedoraproject.org> > Message: 6 > Date: Thu, 12 Jul 2012 13:00:15 +0200 > From: Michael Schwendt <mschwendt(a)gmail.com> > To: packaging(a)lists.fedoraproject.org > Subject: Re: [Fedora-packaging] Script-Tools, which location? > Message-ID: <20120712130015.5b0810e8(a)gmail.com> > Content-Type: text/plain; charset=US-ASCII > > On Thu, 12 Jul 2012 00:53:03 +0200, Simon A. Erat wrote: > > > Heyas > > > > As i'm new to packaging, specificly to linux, i am a little confused at > > this moment. > > > > I have my scripts (kind of framework, but for any enduser they are just > > tools) which i'd like to be shiped with Fedora, however, until now i was > > thinking like: > > My Package = Additional Software = /usr/share/%name. > > It cannot be generalized like that. When deciding where to store files, > one must tell what type of files they are. Skimming over the FHS can help > to find the proper location, as the packaging for Fedora can get a lot > more trouble-some, if a software project installs into uncommon locations > or violates the FHS even. /usr/share/ is for architecture-independent > read-only data files. > > > Now that i had opened a Review Request ( > > https://bugzilla.redhat.com/show_bug.cgi?id=835089), someone asked my > whe i > > didnt pack my scripts into /usr/bin. > > /usr/bin sounds reasonable. > > At least, it should be easily possible for your project to store small > scripts in /usr/bin, which know about their home directory, from where to > load supporting files (including additional hidden scripts not to make > available in $PATH). > > > Allthought i like this idea, i do not feel that this would be 'clean', as > > my script tools base upon a directory structure, while there are no > > directories in /usr/bin. > > That sounds a bit like a design mistake. Can you tell why you think you > would need a directory structure below /usr/bin and not elsewhere? > > > From the same person i was told that /etc/profile.d/%name.sh would not > be a > > good solution as it wont work with csh, zsh, with which i agree, but > > couldnt think of a better solution until now. > > That's inaccurate. Adjusting $PATH via profile.d scripts is a good > solution for *some* projects, e.g "ccache", but it ought to be an exception > (and there's a reason why "ccache" does it like that). It doesn't sound > correct/ideal/elegant for your scripts. > > > Now the idea came up to place the 'base-script' (st) in /usr/bin, while > > everything else would be in a folder somewhere. However, this has a hughe > > drawback, as it (the script tools) wont work in this mixed up (split > away) > > environment. > > As above, a design mistake? > > > Until now, one could have been sure, that in any case if i move the > > directory the scripts tools are in, anywhere else, one could just execute > > the main script and everything kept working. > > The scripts would stay in /usr/bin, be available for execution by every > user, and if you moved anything at all with an update of the software in > an update of the RPM package, you would replace the script files. Why would > the new files not work anymore (or not know about changed directories)? > > > This was achieved by symlinking the actualy path to /usr/share/%name, of > > course only if it wasnt installed there using rpm/yum (default). > > Perhaps you could explain in more detail what problem you're trying to > solve? > > > Further, it takes some use of 'configuration' files, uses some sort of > > templates and lots of other stuff. > > That's not unusual. > > -- > Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 > loadavg: 0.19 0.36 0.49 > > > ------------------------------ > > -- > packaging mailing list > packaging(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/packaging > > End of packaging Digest, Vol 89, Issue 6 > **************************************** > -- Simon A. Erat (sea) Switzerland ---------------- FAS: sea IRC: seasc

2 1

Script-Tools, which location?
by Simon A. Erat 12 Jul '12

12 Jul '12

Heyas As i'm new to packaging, specificly to linux, i am a little confused at this moment. I have my scripts (kind of framework, but for any enduser they are just tools) which i'd like to be shiped with Fedora, however, until now i was thinking like: My Package = Additional Software = /usr/share/%name. Now that i had opened a Review Request ( https://bugzilla.redhat.com/show_bug.cgi?id=835089), someone asked my whe i didnt pack my scripts into /usr/bin. Allthought i like this idea, i do not feel that this would be 'clean', as my script tools base upon a directory structure, while there are no directories in /usr/bin. >From the same person i was told that /etc/profile.d/%name.sh would not be a good solution as it wont work with csh, zsh, with which i agree, but couldnt think of a better solution until now. ---------- All above here is the actual question ---------- Now the idea came up to place the 'base-script' (st) in /usr/bin, while everything else would be in a folder somewhere. However, this has a hughe drawback, as it (the script tools) wont work in this mixed up (split away) environment. Until now, one could have been sure, that in any case if i move the directory the scripts tools are in, anywhere else, one could just execute the main script and everything kept working. This was achieved by symlinking the actualy path to /usr/share/%name, of course only if it wasnt installed there using rpm/yum (default). Now after all this crapy text (its past midnight here), according to the feedback (very little) i have recieved so far, i do need feedback/info, from someone capable handling complex bash script structures across folders, using other scripts are libraries, offering the users to write their own libs and scripts. Further, it takes some use of 'configuration' files, uses some sort of templates and lots of other stuff. It is NOT an easy task, to review, or to understand how it works, or to actualy give any kind of advice. I do know and understand this, thus i would appreciate any usefull feedback even more for the very same reason. For more info about this package, please have a look at http://sea.hostingsociety.com/?p=Script-Tools&stc= many, but not all, things are explained there, or at least try to be there. Have i mentioned, i lack of feedback/questions so i could not write the readme appropriate to the 'demand' of explanation. Where would be the proper place to put/package my script tools to? Thank you in advance for any hints, advices, questions or suggestions. Kind regards ~sea~ -- Simon A. Erat (sea) Switzerland ---------------- FAS: sea IRC: seasc

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2012