packaging October 2012

packaging@lists.fedoraproject.org

24 participants
18 discussions

Request for exception: seabios-bin on ppc64
by Richard W.M. Jones 17 Oct '12

17 Oct '12

[Bug: https://bugzilla.redhat.com/show_bug.cgi?id=866664] Here's the situation, since the bug doesn't explain it well. (1) qemu can run any architecture on any other architecture, using software emulation. eg. It can run x86_64 guest operating systems on top of ppc64 hosts (albeit not at full speed). (2) In order to run guests, you have to provide a BIOS (or some sort of other boot ROM), since most guests wouldn't be able to boot without BIOS services. This applies for all guests, but of particular interest to us are i686/x86_64 guests. (3) SeaBIOS is a free, open source PC BIOS implementation. It is what we use to provide services to i686/x86_64 PC guests. (4) Although qemu itself bundles some binary BIOSes, in Fedora we have chosen to recompile these from source. We now (on i686/x86_64) compile or cross-compile all ROMs from source. (5) 'seabios-bin' is the name of the RPM package that contains the SeaBIOS ROMs. I have no idea why (historical?) this package has '-bin' in the name, but the important point is that it is NOT a binary-only package. It is built from source. (6) In order to compile SeaBIOS you need a program called 'iasl' (part of the ACPICA.org project). This program is needed to compile the ACPI tables which are an integral part of the ROM data that is needed for i686/x86_64 guests to boot. (7) Unfortunately the iasl program, which runs fine on little-endian platforms, has endianness issues. Such that when you run it on a ppc64 host it produces big-endian ACPI tables, which are of course completely broken. 'iasl' itself is a very large program, and I do not know the scope of the fix for this issue -- it may be trivial, or it may require auditing every line of code. Therefore: We would like a packaging exception which would allow us to import the seabios-bin package (built on little-endian) into the ppc & ppc64 buildroots. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

3 10

RFD: C/C++ template packages
by Ralf Corsepius 15 Oct '12

15 Oct '12

Hi, Fedora carries some "C/C++" "template"/"header-only" packages (Packages which contain C/C++-headers only). Typically, these packages are being built "BuildArch: noarch". == These packages are supposed to be arch-independent. In reality, many of these packages often are wrapper headers, trying to wrap to something highly OS-/arch-dependent, from system-headers and compiler built-ins defines. I.e. though these packages are supposed to be arch-independent, there is no guarantee nor check whether these packages actually are arch-independent. I am proposing to: Proposal: All "C/C++-template/header-only packages" must be built using an "arch'ed BuildArch", with the resulting binary packages implemented as "Arch: noarch"-subpackages. Benefits: - This would assure such packages would be built on all architectures Fedora supports and not only the architecture noarch-packages are being built. - This would exercise potentially existing configuration-scripts on all architectures and would allow to exercise test-scripts rsp. coding examples (which can be regarded as compilation-checks) on all Fedora supported architectures. Comments, opinions? Ralf

2 2

Dependence on initscripts/chkconfig
by Milan Broz 10 Oct '12

10 Oct '12

Hi, there seems to be a lot of packages which still require initscripts and chkconfig. Majority of them are because of pre/post upgrade scriptlet (sysv->systemd). Example - rsyslog: %triggerpostun -n rsyslog-sysvinit -- rsyslog < 5.8.2-3 /sbin/chkconfig --add rsyslog >/dev/null 2>&1 || : Without removing these triggers it is impossible to get rid of these unnecessary dependences. (IMHO only *-sysv sub-packages should require it). It is quite important mainly for minimal install but there are many packages in the whole distro. But because Fedora supports only upgrade from N-1 version, I think there should be some guideline to remove these scriptlets after N+1 release. Can you provide some guidance what to do here now? Shouldn't be these triggers removed in rawhide (F19) now? Thanks, Milan

2 1

APT,YUM and package status
by Mohsen Pahlevanzadeh 08 Oct '12

08 Oct '12

Dear all, Recently, i'm writing a benchmark between APT and YUM, by default i didn't know yum and know apt, i didn't find the following status in the yum: ////////////////////////////////////// PACKAGE STATES not-installed The package is not installed on your system. config-files Only the configuration files of the package exist on the system. half-installed The installation of the package has been started, but not completed for some reason. unpacked The package is unpacked, but not configured. half-configured The package is unpacked and configuration has been started, but not yet completed for some reason. triggers-awaited The package awaits trigger processing by another package. triggers-pending The package has been triggered. installed The package is unpacked and configured OK. ////////////////////////////////////////////// Where can i find above feature or yum doesn't has them? --mohsen

5 8

[Guidelines Change] Change to the Packaging Guidelines
by Tom Callaway 08 Oct '12

08 Oct '12

A few minor changes to the Fedora Packaging Guidelines have been made: --- The Ruby Packaging guidelines were updated to reflect the fact that rubygem packages must have a Requires: rubygems, because that package (rubygems) owns the RubyGems? directory structure. https://fedoraproject.org/wiki/Packaging:Ruby#RubyGems --- The systemd Scriptlets for Fedora 18+ have had their corresponding scriptlet Requires adjusted from "systemd-units" to "systemd", since "systemd-units" is provided by the "systemd" package in Fedora 18+. There is still a separation in previous releases of Fedora (16/17), so packagers can choose to continue using the old Requires (systemd-units) if they are targeting multiple versions of Fedora with a single spec file. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_script… --- This guideline change was approved by the Fedora Packaging Committee (FPC). Many thanks to Vit Ondruch, Lennart Poettering, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~tom

1 0

Exceptions for packages placing files into /bin, /sbin, /lib or /lib64
by Jaroslav Skarvada 02 Oct '12

02 Oct '12

According to the packaging guidelines [1] packages for F17+ must not place files or directories into /bin, /sbin, /lib or /lib64. But it seems it is not possible with glibc [2] (and maybe others), thus I propose adding exceptions list to the guidelines thanks & regards Jaroslav [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout [2] https://bugzilla.redhat.com/show_bug.cgi?id=860579

4 3

mp3 source (but not compiled) in squeak package
by Matthew Miller 01 Oct '12

01 Oct '12

I'm sure I've seen discussion of this before, but I can't find it in the mailing list, and https://fedoraproject.org/wiki/Forbidden_items?rd=ForbiddenItems#MP3_Support doesn't spell it out. The Squeak VM package in Fedora includes the upstream source code for MP3 support, but disables actually building it. Is that okay, or does the tarball need to be sanitized? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

4 15

requiring a (non-specific) font?
by Matthew Miller 01 Oct '12

01 Oct '12

I happened to install Scratch onto a remove VM (on Fedora Infrastructure's new private cloud, in fact) where no fonts were installed. It runs, but Pango throws warnings about not having anything for 'latin' or 'common' -- and of course the UI has boxes where the menus and variables should be. I could require something generic, like 'font(:lang=en)', but that's likely to pull in a random decorative font. I could require some specific font, but that seems wrong. (Particularly since if a "better" match for latin or common happen to be installed, whatever I said is a requirement will actually be irrelevant.) Orrr, should I just not worry about this case? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2012