From vondruch at redhat.com Tue Jul 10 11:29:44 2012 From: vondruch at redhat.com (=?ISO-8859-2?Q?V=EDt_Ondruch?=) Date: Tue, 10 Jul 2012 13:29:44 +0200 Subject: [Fedora-packaging] RPM macros Message-ID: <4FFC1228.3060409@redhat.com> 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 From vondruch at redhat.com Tue Jul 10 12:11:53 2012 From: vondruch at redhat.com (=?UTF-8?B?VsOtdCBPbmRydWNo?=) Date: Tue, 10 Jul 2012 14:11:53 +0200 Subject: [Fedora-packaging] RPM macros In-Reply-To: <4FFC1688.7090907@city-fan.org> References: <4FFC1228.3060409@redhat.com> <4FFC1688.7090907@city-fan.org> Message-ID: <4FFC1C09.6030907@redhat.com> Dne 10.7.2012 13:48, Paul Howarth napsal(a): > On 07/10/2012 12:29 PM, Vít Ondruch wrote: >> 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? > > Perl has the macros in the main perl package rather than the > perl-devel package because arch-independent perl module builds often > don't need perl-devel - the packaging split is more fine-grained for > perl and tends to become finer with each release as more and more bits > are split out into their own subpackages since they have their own > lives upstream. Thank you for your clarification. Actually, it is similar for Ruby. Arch-independent packages do not require -devel package because of build, but because of macros. And I find it more reasonable then to have /etc/rpm/macros.ruby in my runtime system, where I have no use for this file. Vit From bjorn at xn--rombobjrn-67a.se Thu Jul 12 23:49:23 2012 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Fri, 13 Jul 2012 01:49:23 +0200 Subject: [Fedora-fr-list] =?iso-8859-1?q?Compte-rendu_de_la_r=E9union_du_?= =?iso-8859-1?q?1_novembre_2009?= In-Reply-To: References: Message-ID: <201207130149.23771.bjorn@xn--rombobjrn-67a.se> Simon A. Erat wrote: > First of all, whats the acronym FHS standing for? The Filesystem Hierarchy Standard: http://www.pathname.com/fhs/pub/fhs-2.3.html It's linked from the Packaging Guidelines, which I hope you read before you made your package: https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout > 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) It's easier to do that if you give your relocatable directory tree an FHS-like structure, with a prefix that can be set to "/usr", "/usr/local", "/opt/Simon's-script-tools" or anything else, and place scripts in $prefix/bin, read-only data in $prefix/share et cetera. You may still find that you need to make your scripts capable of adapting a bit to different directory layouts. > 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. You shouldn't make subdirectories under $HOME/bin any more than under /usr/bin. Although users' home directories are less standardized than system directories, $HOME/bin is typically used for the users' own programs that they want to be able to run from a command prompt. Programs in subdirectories wouldn't be found unless the users added the subdirectories to PATH. Also, anything that ends with "libs" seems like a bad name for a directory to save data in. Björn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mmaslano at redhat.com Wed Jul 18 07:41:37 2012 From: mmaslano at redhat.com (=?UTF-8?B?TWFyY2VsYSBNYcWhbMOhxYhvdsOh?=) Date: Wed, 18 Jul 2012 09:41:37 +0200 Subject: =?UTF-8?Q?Re=3A_=5BFedora=2Dfr=2Dlist=5D_Compte=2Drendu_de_la_r=C3=A9union_du_?= =?UTF-8?Q?1_novembre_2009?= In-Reply-To: <4FFC1228.3060409@redhat.com> References: <4FFC1228.3060409@redhat.com> Message-ID: <500668B1.8090904@redhat.com> On 07/10/2012 01:29 PM, Vít Ondruch wrote: > 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 It depends what you need to do. Part of Perl macros is in a special package perl-srpm-macros, which is required by redhat-rpm-config. We should have all macros defined in perl-srpm-macros in buildroot everytime, which was one of our issues during annual rebuild. Marcela From dan at danny.cz Tue Jul 24 20:24:38 2012 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 24 Jul 2012 22:24:38 +0200 Subject: [Fedora-packaging] Distributing prebuilt bios roms with QEMU In-Reply-To: <20120724194842.GA5959@amd.home.annexia.org> References: <500EF313.4060800@redhat.com> <500EF6E0.1050300@redhat.com> <20120724194842.GA5959@amd.home.annexia.org> Message-ID: <1343161478.3005.55.camel@eagle.danny.cz> Richard W.M. Jones píše v Út 24. 07. 2012 v 20:48 +0100: > On Tue, Jul 24, 2012 at 03:26:24PM -0400, Tom Callaway wrote: > > I really do wish we could come up with a clever way to build these on > > the native platforms, but I also understand how difficult that is, and I > > really don't want to stonewall on that. > > On the BZ we discussed cross-compiling them. It would require > approx. 2 extra packages per architecture, ie. a cross gcc and a cross > binutils (since it's firmware, no libc is required of course). the cross-gcc and cross-binutils all(?) Linux kernel arches are already there, no libgcc yet, but it shouldn't be an issue for firmwares Dan From bjorn at xn--rombobjrn-67a.se Sun Jul 29 18:57:00 2012 From: bjorn at xn--rombobjrn-67a.se (=?ISO-8859-1?Q?Bj=F6rn?= Persson) Date: Sun, 29 Jul 2012 20:57 +0200 Subject: [Fedora-packaging] May binaries be built from generated "source" code? Message-ID: <1575009.Hf8WqyK1vx@hactar.xn--rombobjrn-67a.se> 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