From rjones at redhat.com Thu Oct 1 22:41:28 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 1 Oct 2009 23:41:28 +0100 Subject: [Fedora-packaging] Package Guildelines / Review Guidelines: .la archives must/should not contradiction In-Reply-To: <4AB19D02.7030201@gmail.com> References: <20090916231652.GC23876@genius.kawo2.rwth-aachen.de> <4AB19D02.7030201@gmail.com> Message-ID: <20091001224128.GA8172@amd.home.annexia.org> On Wed, Sep 16, 2009 at 07:20:50PM -0700, Toshio Kuratomi wrote: > I believe it should be a MUST with exceptions. Review Guidelines are > more succinct and therefore less prone to a slip up when being written > up. Even then, there have been times when a Review Guideline uses the > uppercase, bold '''MUST''' to show that it's a MUST but then used should > in the sentence describing what needs to be done. > > The only current exception is: > """ > Note that if you are updating a library in a stable release (not devel) > and the package already contains *.la files, removing the *.la files > should be treated as an API/ABI change > """ There's also an exception for these in the MinGW guidelines, although (in hindsight) it's wrong and we've been removing the *.la files in those packages. http://fedoraproject.org/wiki/Packaging/MinGW#Libraries_.28DLLs.29 http://fedoraproject.org/wiki/MinGW/Packaging_issues#.2A.la_files Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From rjones at redhat.com Thu Oct 1 22:50:07 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 1 Oct 2009 23:50:07 +0100 Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: <4AC139B4.9030508@cora.nwra.com> References: <4AC139B4.9030508@cora.nwra.com> Message-ID: <20091001225007.GB8172@amd.home.annexia.org> On Mon, Sep 28, 2009 at 04:33:24PM -0600, Orion Poplawski wrote: > I package plplot which ships bindings for oodles of languages, among > them perl and ocaml. The ocaml packaging guidelines suggest: > > %global _use_internal_dependency_generator 0 > %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh > %global __find_provides /usr/lib/rpm/ocaml-find-provides.sh > > to add the required ocaml Requires/Provides. However, this breaks the > automatic perl (and other?) generation for the perl sub-package. > > How should this be handled? Is there a way to add the > ocaml-find-requires/provides to the normal list of providers? Shouldn't > this be done automatically by the build system? Yes - really those should be pushed into upstream RPM. However that isn't done at the moment. The reason for having the alternate dependency generator is to make dependencies of the form: ocaml(Module) = MD5 where MD5 is the md5sum of the dependent Module's interface (use 'ocamlobjinfo plplot.cma' to discover this). This avoids the dreaded 'interface mismatch' error, and ensures that only a consistent set of packages can be installed together, which is good news if you are developing OCaml software that uses plplot. If you are willing to have the occasional inconsistent package set, you can just as easily forgo the above and simply add explicit dependencies on any packages you need, plus the ABI, eg: Requires: ocaml-foo Requires: ocaml(runtime) = 3.11.1 This is still how Debian package things, although they are moving slowly to a system which is similar (but different in the details) from the one we use in Fedora. In Debian you still get 'interface mismatch' errors. Really we need to get the OCaml dep generator into upstream RPM ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From michael.silvanus at gmail.com Fri Oct 2 23:09:24 2009 From: michael.silvanus at gmail.com (Michel Alexandre Salim) Date: Fri, 2 Oct 2009 19:09:24 -0400 Subject: [Fedora-packaging] Static-only library: clarification Message-ID: <615c05430910021609m5752c85fo6b5672dc7a920ac8@mail.gmail.com> I'm currently reviewing a request for Telepathy-Qt4, which currently only provides a static library: https://bugzilla.redhat.com/show_bug.cgi?id=520663 It seems to me there are two different options: - rename package to telepathy-qt4-static -- might cause administrative hassle if and when upstream enables dynamically-linked libraries - keep it as before, and just leave the main package empty. Make -devel virtually Provides: -static. Should the -doc subpackage depend on -devel? Should it be called -devel-doc or -static-doc, or just -doc? Thanks, -- Michel Alexandre Salim From jussilehtola at fedoraproject.org Fri Oct 2 23:32:02 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sat, 03 Oct 2009 02:32:02 +0300 Subject: [Fedora-packaging] Static-only library: clarification In-Reply-To: <615c05430910021609m5752c85fo6b5672dc7a920ac8@mail.gmail.com> References: <615c05430910021609m5752c85fo6b5672dc7a920ac8@mail.gmail.com> Message-ID: <1254526322.2960.12.camel@localhost> On Fri, 2009-10-02 at 19:09 -0400, Michel Alexandre Salim wrote: > I'm currently reviewing a request for Telepathy-Qt4, which currently > only provides a static library: > > https://bugzilla.redhat.com/show_bug.cgi?id=520663 > > It seems to me there are two different options: > - rename package to telepathy-qt4-static -- might cause administrative > hassle if and when upstream enables dynamically-linked libraries This is not really an option. (You, too, can patch the software to build dynamically instead; it often is the least path of resistance.) > - keep it as before, and just leave the main package empty. Make > -devel virtually Provides: -static. AFAIK this is what is usually done in case there are no shared libraries. Of course the static library can be put in a separate -static package, but then one would have to make the -devel package require it in any case if there is no shared library available..? > Should the -doc subpackage depend on -devel? Should it be called > -devel-doc or -static-doc, or just -doc? In 99.9% of the cases, plain -doc will do. I would break it in parts only if the documentation is ridiculously big, say, like kdelibs-apidocs (281MB compressed, 628MB uncompressed, and still it's in one package!!). That is: if a user bothers to install -doc separately, then it's assumed that s/he wants to get all the documentation, and is not bothered if there's a bit of something extra on the side. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From limb at jcomserv.net Sat Oct 3 01:16:18 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 2 Oct 2009 20:16:18 -0500 Subject: [Fedora-packaging] Static-only library: clarification In-Reply-To: <1254526322.2960.12.camel@localhost> References: <615c05430910021609m5752c85fo6b5672dc7a920ac8@mail.gmail.com> <1254526322.2960.12.camel@localhost> Message-ID: <2f1ca1904cf4426ce5ac7fb4cda4e68a.squirrel@secure.jcomserv.net> > On Fri, 2009-10-02 at 19:09 -0400, Michel Alexandre Salim wrote: >> I'm currently reviewing a request for Telepathy-Qt4, which currently >> only provides a static library: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=520663 >> >> It seems to me there are two different options: >> - rename package to telepathy-qt4-static -- might cause administrative >> hassle if and when upstream enables dynamically-linked libraries > > This is not really an option. (You, too, can patch the software to build > dynamically instead; it often is the least path of resistance.) Alternatively, though I prefer the above, if you do keep it static, keep the package/SRPM name telepathy-qt4 and put the libs in a -static subpackage, which should obviate some of the issues later. >> - keep it as before, and just leave the main package empty. Make >> -devel virtually Provides: -static. > > AFAIK this is what is usually done in case there are no shared > libraries. Of course the static library can be put in a separate -static > package, but then one would have to make the -devel package require it > in any case if there is no shared library available..? Correct. >> Should the -doc subpackage depend on -devel? Should it be called >> -devel-doc or -static-doc, or just -doc? > > In 99.9% of the cases, plain -doc will do. I would break it in parts > only if the documentation is ridiculously big, say, like kdelibs-apidocs > (281MB compressed, 628MB uncompressed, and still it's in one package!!). > > That is: if a user bothers to install -doc separately, then it's assumed > that s/he wants to get all the documentation, and is not bothered if > there's a bit of something extra on the side. If the docs are small (a few MB or less, YMMV), no subpackage is really needed, though you still can if you want to. -J > -- > Jussi Lehtola > Fedora Project Contributor > jussilehtola at fedoraproject.org > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- in your fear, seek only peace in your fear, seek only love -d. bowie -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sat Oct 3 17:37:28 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 03 Oct 2009 10:37:28 -0700 Subject: [Fedora-packaging] Small change to Beware of RPath Message-ID: <4AC78BD8.9090905@gmail.com> fabiand on IRC let me know that there's a minor change that could be made to the Beware of RPath section of the Guidelines to make things easier for packagers: [10:23:07] regarding an wiki page i can not edit: packaging:guidelines#beware_of_rpath [10:23:57] it should be recommended to use %{_arch} not using 32 or 64 as a suffix for files in /etc/ld.so.conf, because it is easy to use %{a_arch} but not easy to get 64 or 32 https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath It would change this: {{{ If you are storing a library in a non-standard location (e.g. /usr/lib/foo/), you should include a custom config file in /etc/ld.so.conf.d/. For example, if I was putting 32 bit libraries of libfoo in /usr/lib/foo, I would want to make a file called "foo32.conf" in /etc/ld.so.conf.d/, which contained the following: /usr/lib/foo Make sure that you also make a 64bit version of this file (e.g. foo64.conf) as well (unless the package is disabled for 64bit architectures, of course). }}} To this:: {{{ If you are storing a library in a non-standard location (e.g. %{_libdir}/foo/), you should include a custom config file in /etc/ld.so.conf.d/. For example, if I was putting 32 bit libraries of libfoo in /usr/lib/foo and 64 bit libraries in /usr/lib64/foo I would want to make a file called "foo%{_arch}.conf" in /etc/ld.so.conf.d/, which contained the following on 32 bit: /usr/lib/foo and on 64 bit: /usr/lib64/foo That could be done in the specfile with echo %{_libdir}/foo > %{buildroot}%{_sysconfdir}/ld.so.conf.d/foo%{_arch}.conf }}} If this looks like a good change I'll put it on the agenda for the next meeting. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From pmatilai at laiskiainen.org Sun Oct 4 08:03:33 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sun, 4 Oct 2009 11:03:33 +0300 (EEST) Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: <20091001225007.GB8172@amd.home.annexia.org> References: <4AC139B4.9030508@cora.nwra.com> <20091001225007.GB8172@amd.home.annexia.org> Message-ID: On Thu, 1 Oct 2009, Richard W.M. Jones wrote: > On Mon, Sep 28, 2009 at 04:33:24PM -0600, Orion Poplawski wrote: >> I package plplot which ships bindings for oodles of languages, among >> them perl and ocaml. The ocaml packaging guidelines suggest: >> >> %global _use_internal_dependency_generator 0 >> %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh >> %global __find_provides /usr/lib/rpm/ocaml-find-provides.sh >> >> to add the required ocaml Requires/Provides. However, this breaks the >> automatic perl (and other?) generation for the perl sub-package. >> >> How should this be handled? Is there a way to add the >> ocaml-find-requires/provides to the normal list of providers? Shouldn't >> this be done automatically by the build system? > > Yes - really those should be pushed into upstream RPM. However that > isn't done at the moment. > > The reason for having the alternate dependency generator is to > make dependencies of the form: > > ocaml(Module) = MD5 > > where MD5 is the md5sum of the dependent Module's interface (use > 'ocamlobjinfo plplot.cma' to discover this). This avoids the dreaded > 'interface mismatch' error, and ensures that only a consistent set of > packages can be installed together, which is good news if you are > developing OCaml software that uses plplot. > > If you are willing to have the occasional inconsistent package set, > you can just as easily forgo the above and simply add explicit > dependencies on any packages you need, plus the ABI, eg: > > Requires: ocaml-foo > Requires: ocaml(runtime) = 3.11.1 > > This is still how Debian package things, although they are moving > slowly to a system which is similar (but different in the details) > from the one we use in Fedora. In Debian you still get 'interface > mismatch' errors. > > Really we need to get the OCaml dep generator into upstream RPM ... I seem to recall commenting on this earlier (like at least a year ago :) but just as well I might've just intended to comment... anyway. I would've pulled it to RPM upstream ages ago if it didn't have Fedora packaging specifics bolted in: if [ -n "$emit_compiler_version" ]; then # Every OCaml program depends on the version of the # runtime which was used to compile it. echo "ocaml(runtime) = `cat /usr/lib*/ocaml/fedora-ocaml-release`" fi I suppose there's a reason why this is not generated with "ocaml -version" or "ocamlrun -version" as needed? - Panu - From rjones at redhat.com Sun Oct 4 22:38:52 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 4 Oct 2009 23:38:52 +0100 Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: References: <4AC139B4.9030508@cora.nwra.com> <20091001225007.GB8172@amd.home.annexia.org> Message-ID: <20091004223852.GA32000@amd.home.annexia.org> On Sun, Oct 04, 2009 at 11:03:33AM +0300, Panu Matilainen wrote: > I seem to recall commenting on this earlier (like at least a year ago :) > but just as well I might've just intended to comment... anyway. > I would've pulled it to RPM upstream ages ago if it didn't have Fedora > packaging specifics bolted in: > > if [ -n "$emit_compiler_version" ]; then > # Every OCaml program depends on the version of the > # runtime which was used to compile it. > echo "ocaml(runtime) = `cat /usr/lib*/ocaml/fedora-ocaml-release`" > fi > > I suppose there's a reason why this is not generated with "ocaml > -version" or "ocamlrun -version" as needed? Yes, I can't remember why we did that either :-( I've changed it in the OCaml package in Fedora 13, we should give it a few more months to see if anything breaks. http://cvs.fedoraproject.org/viewvc/devel/ocaml/ocaml-find-requires.sh?r1=1.4&r2=1.5 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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/ From tcallawa at redhat.com Tue Oct 6 00:58:09 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 05 Oct 2009 20:58:09 -0400 Subject: [Fedora-packaging] Small change to Beware of RPath In-Reply-To: <4AC78BD8.9090905@gmail.com> References: <4AC78BD8.9090905@gmail.com> Message-ID: <4ACA9621.4060608@redhat.com> On 10/03/2009 01:37 PM, Toshio Kuratomi wrote: > fabiand on IRC let me know that there's a minor change that could be > made to the Beware of RPath section of the Guidelines to make things > easier for packagers: > > [10:23:07] regarding an wiki page i can not edit: > packaging:guidelines#beware_of_rpath > [10:23:57] it should be recommended to use %{_arch} not using > 32 or 64 as a suffix for files in /etc/ld.so.conf, because it is easy to > use %{a_arch} but not easy to get 64 or 32 That's not true. %{__isa_bits} will return either 32 or 64, depending on the platform arch. ~spot From a.badger at gmail.com Tue Oct 6 01:20:15 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 Oct 2009 18:20:15 -0700 Subject: [Fedora-packaging] Small change to Beware of RPath In-Reply-To: <4ACA9621.4060608@redhat.com> References: <4AC78BD8.9090905@gmail.com> <4ACA9621.4060608@redhat.com> Message-ID: <4ACA9B4F.8000806@gmail.com> On 10/05/2009 05:58 PM, Tom "spot" Callaway wrote: > On 10/03/2009 01:37 PM, Toshio Kuratomi wrote: >> fabiand on IRC let me know that there's a minor change that could be >> made to the Beware of RPath section of the Guidelines to make things >> easier for packagers: >> >> [10:23:07] regarding an wiki page i can not edit: >> packaging:guidelines#beware_of_rpath >> [10:23:57] it should be recommended to use %{_arch} not using >> 32 or 64 as a suffix for files in /etc/ld.so.conf, because it is easy to >> use %{a_arch} but not easy to get 64 or 32 > > That's not true. %{__isa_bits} will return either 32 or 64, depending on > the platform arch. > %{__isa_bits} requires a relatively recent rpm, though? I didn't find it EL-5's rpm --showrc but did in F-11's. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Tue Oct 6 01:36:19 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 05 Oct 2009 21:36:19 -0400 Subject: [Fedora-packaging] Small change to Beware of RPath In-Reply-To: <4ACA9B4F.8000806@gmail.com> References: <4AC78BD8.9090905@gmail.com> <4ACA9621.4060608@redhat.com> <4ACA9B4F.8000806@gmail.com> Message-ID: <4ACA9F13.8070003@redhat.com> On 10/05/2009 09:20 PM, Toshio Kuratomi wrote: > %{__isa_bits} requires a relatively recent rpm, though? I didn't find > it EL-5's rpm --showrc but did in F-11's. Yeah. I suppose it doesn't matter if we use %{_arch} instead, although %{__isa_bits} is much cleaner. ~spot From pmatilai at laiskiainen.org Tue Oct 6 09:43:13 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 6 Oct 2009 12:43:13 +0300 (EEST) Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: <20091004223852.GA32000@amd.home.annexia.org> References: <4AC139B4.9030508@cora.nwra.com> <20091001225007.GB8172@amd.home.annexia.org> <20091004223852.GA32000@amd.home.annexia.org> Message-ID: On Sun, 4 Oct 2009, Richard W.M. Jones wrote: > On Sun, Oct 04, 2009 at 11:03:33AM +0300, Panu Matilainen wrote: >> I seem to recall commenting on this earlier (like at least a year ago :) >> but just as well I might've just intended to comment... anyway. >> I would've pulled it to RPM upstream ages ago if it didn't have Fedora >> packaging specifics bolted in: >> >> if [ -n "$emit_compiler_version" ]; then >> # Every OCaml program depends on the version of the >> # runtime which was used to compile it. >> echo "ocaml(runtime) = `cat /usr/lib*/ocaml/fedora-ocaml-release`" >> fi >> >> I suppose there's a reason why this is not generated with "ocaml >> -version" or "ocamlrun -version" as needed? > > Yes, I can't remember why we did that either :-( > > I've changed it in the OCaml package in Fedora 13, we should give it a > few more months to see if anything breaks. > > http://cvs.fedoraproject.org/viewvc/devel/ocaml/ocaml-find-requires.sh?r1=1.4&r2=1.5 Okay... added upstream now and integrated with the internal dependency generator too so you dont need to fiddle with that in specfile, plus the external dependency generator misses some fairly important dependency bits. http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=82e7dd702013d3679fda438333de30afdec17a4f http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=15fb8ccb41ce4cc02c78508b936fb74f7165683c - Panu - From rjones at redhat.com Tue Oct 6 15:07:45 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 6 Oct 2009 16:07:45 +0100 Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: References: <4AC139B4.9030508@cora.nwra.com> <20091001225007.GB8172@amd.home.annexia.org> <20091004223852.GA32000@amd.home.annexia.org> Message-ID: <20091006150745.GA19053@amd.home.annexia.org> On Tue, Oct 06, 2009 at 12:43:13PM +0300, Panu Matilainen wrote: > On Sun, 4 Oct 2009, Richard W.M. Jones wrote: > >> On Sun, Oct 04, 2009 at 11:03:33AM +0300, Panu Matilainen wrote: >>> I seem to recall commenting on this earlier (like at least a year ago :) >>> but just as well I might've just intended to comment... anyway. >>> I would've pulled it to RPM upstream ages ago if it didn't have Fedora >>> packaging specifics bolted in: >>> >>> if [ -n "$emit_compiler_version" ]; then >>> # Every OCaml program depends on the version of the >>> # runtime which was used to compile it. >>> echo "ocaml(runtime) = `cat /usr/lib*/ocaml/fedora-ocaml-release`" >>> fi >>> >>> I suppose there's a reason why this is not generated with "ocaml >>> -version" or "ocamlrun -version" as needed? >> >> Yes, I can't remember why we did that either :-( >> >> I've changed it in the OCaml package in Fedora 13, we should give it a >> few more months to see if anything breaks. >> >> http://cvs.fedoraproject.org/viewvc/devel/ocaml/ocaml-find-requires.sh?r1=1.4&r2=1.5 > > Okay... added upstream now and integrated with the internal dependency > generator too so you dont need to fiddle with that in specfile, plus > the external dependency generator misses some fairly important > dependency bits. > > http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=82e7dd702013d3679fda438333de30afdec17a4f > http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=15fb8ccb41ce4cc02c78508b936fb74f7165683c Just a question about this: If we need to pass extra options to the dependency scripts (as in the example specfile below), can we still do that? http://cvs.fedoraproject.org/viewvc/devel/ocaml-pxp/ocaml-pxp.spec?revision=1.11&view=markup Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From pmatilai at laiskiainen.org Tue Oct 6 17:45:38 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 6 Oct 2009 20:45:38 +0300 (EEST) Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: <20091006150745.GA19053@amd.home.annexia.org> References: <4AC139B4.9030508@cora.nwra.com> <20091001225007.GB8172@amd.home.annexia.org> <20091004223852.GA32000@amd.home.annexia.org> <20091006150745.GA19053@amd.home.annexia.org> Message-ID: On Tue, 6 Oct 2009, Richard W.M. Jones wrote: > On Tue, Oct 06, 2009 at 12:43:13PM +0300, Panu Matilainen wrote: >> On Sun, 4 Oct 2009, Richard W.M. Jones wrote: >> >>> On Sun, Oct 04, 2009 at 11:03:33AM +0300, Panu Matilainen wrote: >>>> I seem to recall commenting on this earlier (like at least a year ago :) >>>> but just as well I might've just intended to comment... anyway. >>>> I would've pulled it to RPM upstream ages ago if it didn't have Fedora >>>> packaging specifics bolted in: >>>> >>>> if [ -n "$emit_compiler_version" ]; then >>>> # Every OCaml program depends on the version of the >>>> # runtime which was used to compile it. >>>> echo "ocaml(runtime) = `cat /usr/lib*/ocaml/fedora-ocaml-release`" >>>> fi >>>> >>>> I suppose there's a reason why this is not generated with "ocaml >>>> -version" or "ocamlrun -version" as needed? >>> >>> Yes, I can't remember why we did that either :-( >>> >>> I've changed it in the OCaml package in Fedora 13, we should give it a >>> few more months to see if anything breaks. >>> >>> http://cvs.fedoraproject.org/viewvc/devel/ocaml/ocaml-find-requires.sh?r1=1.4&r2=1.5 >> >> Okay... added upstream now and integrated with the internal dependency >> generator too so you dont need to fiddle with that in specfile, plus >> the external dependency generator misses some fairly important >> dependency bits. >> >> http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=82e7dd702013d3679fda438333de30afdec17a4f >> http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=15fb8ccb41ce4cc02c78508b936fb74f7165683c > > Just a question about this: If we need to pass extra options to the > dependency scripts (as in the example specfile below), can we still do > that? For now, you can override the macros much like before, the only difference being the macro to override: instead of %__find_requires and %__find_provides, you'd now override %__ocaml_requires and %__ocaml_provides. Another, perhaps nicer option would be adding per-script optional option-macros for these, something like: %__ocaml_provides %{_rpmconfigdir}/ocaml-find-provides.sh %{?ocaml_find_provides_opts} So in spec you'd just have to set the provides/requires options if necessary, instead of redefining the entire thing. Similar mechanism could be useful for other similar dep extractors too. - Panu - From tcallawa at redhat.com Tue Oct 6 17:52:57 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 06 Oct 2009 13:52:57 -0400 Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: References: <4AC139B4.9030508@cora.nwra.com> <20091001225007.GB8172@amd.home.annexia.org> <20091004223852.GA32000@amd.home.annexia.org> <20091006150745.GA19053@amd.home.annexia.org> Message-ID: <4ACB83F9.7020603@redhat.com> On 10/06/2009 01:45 PM, Panu Matilainen wrote: > Another, perhaps nicer option would be adding per-script optional > option-macros for these, something like: > > %__ocaml_provides %{_rpmconfigdir}/ocaml-find-provides.sh > %{?ocaml_find_provides_opts} That would be very nice. :) ~spot From tcallawa at redhat.com Tue Oct 6 19:30:56 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 06 Oct 2009 15:30:56 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting on Wednesday, October 7, 2009 (1600 UTC) Message-ID: <4ACB9AF0.2080203@redhat.com> We should have an FPC meeting tomorrow, October 7, 2009. 1600 UTC, #fedora-meeting. Here's a rough agenda for the next meeting: * RPath Relaxation: https://fedoraproject.org/wiki/RPath_Packaging_Draft * Directory Ownership: https://fedoraproject.org/wiki/User:Notting/DirectoryDraft * Common Voice Data Framework: https://fedoraproject.org/wiki/PackagingDrafts/CommonVoiceData As a reminder, if you want to get something on FPC's agenda, the process is documented here: https://fedoraproject.org/wiki/Packaging:Committee#Guideline_Change_Procedure Thanks in advance, ~spot From andrew at beekhof.net Wed Oct 7 06:55:51 2009 From: andrew at beekhof.net (Andrew Beekhof) Date: Wed, 7 Oct 2009 08:55:51 +0200 Subject: [Fedora-packaging] Small change to Beware of RPath In-Reply-To: <4AC78BD8.9090905@gmail.com> References: <4AC78BD8.9090905@gmail.com> Message-ID: On Sat, Oct 3, 2009 at 7:37 PM, Toshio Kuratomi wrote: > fabiand on IRC let me know that there's a minor change that could be > made to the Beware of RPath section of the Guidelines to make things > easier for packagers: > > [10:23:07] regarding an wiki page i can not edit: > packaging:guidelines#beware_of_rpath > [10:23:57] it should be recommended to use %{_arch} not using > 32 or 64 as a suffix for files in /etc/ld.so.conf, because it is easy to > use %{a_arch} but not easy to get 64 or 32 > > https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath > Just read the above link, can someone explain "we do not permit the use of rpath in Fedora" in the context of libperl.so? I had been using 'chrpath --delete' for my package (pacemaker) but was forced to drop it because the binaries couldn't find the perl shared lib. If Perl has some sort of exception then ideally it should be mentioned on that page. -- Andrew From rjones at redhat.com Wed Oct 7 13:27:58 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 7 Oct 2009 14:27:58 +0100 Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: <20091006150745.GA19053@amd.home.annexia.org> References: <4AC139B4.9030508@cora.nwra.com> <20091001225007.GB8172@amd.home.annexia.org> <20091004223852.GA32000@amd.home.annexia.org> <20091006150745.GA19053@amd.home.annexia.org> Message-ID: <20091007131632.GA26214@amd.home.annexia.org> On Tue, Oct 06, 2009 at 04:07:45PM +0100, Richard W.M. Jones wrote: > Just a question about this: If we need to pass extra options to the > dependency scripts (as in the example specfile below), can we still do > that? > > http://cvs.fedoraproject.org/viewvc/devel/ocaml-pxp/ocaml-pxp.spec?revision=1.11&view=markup I should probably add that the need to use the '-i' option is really a hack to workaround a bug in the script. The problem is that if an OCaml library has submodules, like: Module Module.Submodule1 Module.Submodule2 then ocaml-find-requires will export Requires digests for Module, Submodule1 and Submodule2. (It should only export them for Module). ocaml-find-provides will only make digests for Module, so you get broken dependencies. Adding -i Submodule1 -i Submodule2 in this case is a hack to say "those are submodules, don't export them". I tried a long time ago to resolve this with upstream but didn't get anywhere as it seems like a subtle problem with the implementation of modules-vs-submodules which I don't fully understand. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From pmatilai at laiskiainen.org Thu Oct 8 08:42:08 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 8 Oct 2009 11:42:08 +0300 (EEST) Subject: [Fedora-packaging] Ocaml sub-package issue In-Reply-To: <20091007131632.GA26214@amd.home.annexia.org> References: <4AC139B4.9030508@cora.nwra.com> <20091001225007.GB8172@amd.home.annexia.org> <20091004223852.GA32000@amd.home.annexia.org> <20091006150745.GA19053@amd.home.annexia.org> <20091007131632.GA26214@amd.home.annexia.org> Message-ID: On Wed, 7 Oct 2009, Richard W.M. Jones wrote: > On Tue, Oct 06, 2009 at 04:07:45PM +0100, Richard W.M. Jones wrote: >> Just a question about this: If we need to pass extra options to the >> dependency scripts (as in the example specfile below), can we still do >> that? >> >> http://cvs.fedoraproject.org/viewvc/devel/ocaml-pxp/ocaml-pxp.spec?revision=1.11&view=markup > > I should probably add that the need to use the '-i' option is really a > hack to workaround a bug in the script. > > The problem is that if an OCaml library has submodules, like: > > Module > Module.Submodule1 > Module.Submodule2 > > then ocaml-find-requires will export Requires digests for Module, > Submodule1 and Submodule2. (It should only export them for Module). > ocaml-find-provides will only make digests for Module, so you get > broken dependencies. > > Adding -i Submodule1 -i Submodule2 in this case is a hack to say > "those are submodules, don't export them". > > I tried a long time ago to resolve this with upstream but didn't get > anywhere as it seems like a subtle problem with the implementation of > modules-vs-submodules which I don't fully understand. Sure it's a workaround, but look at the hoops perl packagers are jumping through because of defiences in perl.[req|prov]... Anyway, upstream rpm now permits passing arbitrary options to the dep extractor scripts by simply defining language and dependency-specific _opts macros, eg %define __ocaml_requires_opts -i Submodule1 %define __perl_provides_opts -e notimplemented Whatever the scripts do or dont do with the options is up to them. - Panu - From richmattes at gmail.com Fri Oct 9 02:58:12 2009 From: richmattes at gmail.com (Rich Mattes) Date: Thu, 08 Oct 2009 22:58:12 -0400 Subject: [Fedora-packaging] Unsponsored Comaintainer? Message-ID: <4ACEA6C4.4000904@gmail.com> Hello, I'm new the packaging thing. I've been reading through all the rules and guidelines, and preparing some new packages to submit. I was wondering if it's possible to become a co-maintainer on an existing package if you're still unsponsored. I've spoken to the current owner of the package and he's more than happy to have me help out, but I don't know if I have to submit my own package for review and become sponsored first. Thanks, Rich Mattes From tibbs at math.uh.edu Fri Oct 9 03:16:19 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 08 Oct 2009 22:16:19 -0500 Subject: [Fedora-packaging] Unsponsored Comaintainer? In-Reply-To: <4ACEA6C4.4000904@gmail.com> (Rich Mattes's message of "Thu, 08 Oct 2009 22:58:12 -0400") References: <4ACEA6C4.4000904@gmail.com> Message-ID: >>>>> "RM" == Rich Mattes writes: RM> I was wondering if it's possible to become a co-maintainer on an RM> existing package if you're still unsponsored. No, you must be sponsored in order to become a member of the packager group and thus gain access to CVS and other infrastructure for packagers. Your options, thus, are: 1) Help out by doing testing and supplying patches and such, without the ability to commit them yourself. (You can still do test builds and such; all users who have completed the CLA can do scratch builds in koji.) 2) Submit a package and go through the regular review and sponsorship route. 3) Convince a sponsor to sponsor you without submitting a package. Sponsors (for the packager group, at least) have wide discretion in who they sponsor. Most will still want to see some evidence that you understand the basics of packaging for Fedora. Having done some of #1 may help. - J< From panemade at gmail.com Tue Oct 13 03:06:36 2009 From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=) Date: Tue, 13 Oct 2009 08:36:36 +0530 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? Message-ID: Hi all, I want to know that is there really any compulsion on posting md5sum instead sha1sum? Review Guidelines said "Reviewers should use md5sum for this task." I have started posting sha1sum for source in package review. Regards, Parag. From tcallawa at redhat.com Tue Oct 13 03:27:05 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 12 Oct 2009 23:27:05 -0400 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: References: Message-ID: <4AD3F389.1080805@redhat.com> On 10/12/2009 11:06 PM, Parag N(????) wrote: > Hi all, > I want to know that is there really any compulsion on posting > md5sum instead sha1sum? Review Guidelines said "Reviewers should use > md5sum for this task." I have started posting sha1sum for source in > package review. No. At the time they were written, md5sum was the norm, no more, no less. ~spot From mclasen at redhat.com Tue Oct 13 05:13:42 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 Oct 2009 01:13:42 -0400 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: References: Message-ID: <1255410822.2121.0.camel@planemask> On Tue, 2009-10-13 at 08:36 +0530, Parag N(????) wrote: > Hi all, > I want to know that is there really any compulsion on posting > md5sum instead sha1sum? Review Guidelines said "Reviewers should use > md5sum for this task." I have started posting sha1sum for source in > package review. That part of the review guidelines has always struck me as bizarre. After all, wouldn't it seem even better to compare the actual tarballs with each other, byte-by-byte, than relying on a checksum ? From rc040203 at freenet.de Tue Oct 13 06:05:42 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Oct 2009 08:05:42 +0200 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <1255410822.2121.0.camel@planemask> References: <1255410822.2121.0.camel@planemask> Message-ID: <4AD418B6.4050000@freenet.de> On 10/13/2009 07:13 AM, Matthias Clasen wrote: > On Tue, 2009-10-13 at 08:36 +0530, Parag N(????) wrote: >> Hi all, >> I want to know that is there really any compulsion on posting >> md5sum instead sha1sum? Review Guidelines said "Reviewers should use >> md5sum for this task." I have started posting sha1sum for source in >> package review. > > That part of the review guidelines has always struck me as bizarre. > After all, wouldn't it seem even better to compare the actual tarballs > with each other, byte-by-byte, than relying on a checksum ? Well, this is only one part of the story. You are right, to verify a submitted package's contents against "external sources" (e.g. upstream), md5sums don't provide more information than a "byte-by-byte" comparison would provide [1]. But there is another aspect: Fedora's applies md5sums as their checksums for "binaries" in its CVS (cf. a file named "sources" in packages checked out from CVS). I.e. to be able to verify whether the files from a "just imported *.src.rpm" matches with those inside of the *.src.rpm having been reviewed, a review would have to contain md5sums. => Unless CVS changes to apply sha1sums, sha1sums in reviews would void the latter point. Ralf [1] In cases upstreams ship "detached md5sum files" (many upstreams do), it's common practice to consider a match between the md5sums from the upstream md5sum file and those generated from the files inside of an src.rpm to be sufficient. Whether md5sums are safe enough to justify this amount of trust, is a different issue. From christoph.wickert at googlemail.com Wed Oct 14 01:05:00 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 14 Oct 2009 03:05:00 +0200 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: References: Message-ID: <1255482300.16734.3.camel@wicktop.localdomain> Am Dienstag, den 13.10.2009, 08:36 +0530 schrieb Parag N(????): > Hi all, > I want to know that is there really any compulsion on posting > md5sum instead sha1sum? Review Guidelines said "Reviewers should use > md5sum for this task." I have started posting sha1sum for source in > package review. As mentioned in your review: IMO it doesn't make a difference, but it must be obvious to other people what you used. > Regards, > Parag. Regards, Christoph From panemade at gmail.com Wed Oct 14 02:05:57 2009 From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=) Date: Wed, 14 Oct 2009 07:35:57 +0530 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <1255482300.16734.3.camel@wicktop.localdomain> References: <1255482300.16734.3.camel@wicktop.localdomain> Message-ID: Hi, On Wed, Oct 14, 2009 at 6:35 AM, Christoph Wickert wrote: > Am Dienstag, den 13.10.2009, 08:36 +0530 schrieb Parag N(????): >> Hi all, >> ? ?I want to know that is there really any compulsion on posting >> md5sum instead sha1sum? ?Review Guidelines said "Reviewers should use >> md5sum for this task." I have started posting sha1sum for source in >> package review. > > As mentioned in your review: IMO it doesn't make a difference, but it > must be obvious to other people what you used. Thanks. I will mention that I am using sha1sum. > >> Regards, >> Parag. > > Regards, > Christoph > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From cweyl at alumni.drew.edu Wed Oct 14 03:47:39 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 13 Oct 2009 20:47:39 -0700 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <1255410822.2121.0.camel@planemask> References: <1255410822.2121.0.camel@planemask> Message-ID: <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> On Mon, Oct 12, 2009 at 10:13 PM, Matthias Clasen wrote: > On Tue, 2009-10-13 at 08:36 +0530, Parag N(????) wrote: >> Hi all, >> ? ?I want to know that is there really any compulsion on posting >> md5sum instead sha1sum? ?Review Guidelines said "Reviewers should use >> md5sum for this task." I have started posting sha1sum for source in >> package review. > > That part of the review guidelines has always struck me as bizarre. > After all, wouldn't it seem even better to compare the actual tarballs > with each other, byte-by-byte, than relying on a checksum ? Um. An easily reproducible, cryptographically strong checksum? :) -Chris -- Chris Weyl Ex astris, scientia From nicolas.mailhot at laposte.net Wed Oct 14 07:55:19 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Oct 2009 09:55:19 +0200 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> Message-ID: <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> Le Mer 14 octobre 2009 05:47, Chris Weyl a ?crit : > > On Mon, Oct 12, 2009 at 10:13 PM, Matthias Clasen wrote: >> That part of the review guidelines has always struck me as bizarre. >> After all, wouldn't it seem even better to compare the actual tarballs >> with each other, byte-by-byte, than relying on a checksum ? > > Um. An easily reproducible, cryptographically strong checksum? :) This is one test I never do, nothing will stop the packager from changing the packaged archive as soon as the review is finished, so the whole thing is a major waste of time for everyone involved IMHO (as is posting specs in addition to SRPMs BTW. -- Nicolas Mailhot From rc040203 at freenet.de Wed Oct 14 08:24:50 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Oct 2009 10:24:50 +0200 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> Message-ID: <4AD58AD2.608@freenet.de> On 10/14/2009 09:55 AM, Nicolas Mailhot wrote: > > > Le Mer 14 octobre 2009 05:47, Chris Weyl a ?crit : >> >> On Mon, Oct 12, 2009 at 10:13 PM, Matthias Clasen wrote: > >>> That part of the review guidelines has always struck me as bizarre. >>> After all, wouldn't it seem even better to compare the actual tarballs >>> with each other, byte-by-byte, than relying on a checksum ? >> >> Um. An easily reproducible, cryptographically strong checksum? :) > > This is one test I never do, nothing will stop the packager from changing the > packaged archive as soon as the review is finished, ACK. > so the whole thing is a > major waste of time for everyone involved IMHO Agreed. > (as is posting specs in > addition to SRPMs BTW. Not agreed. Many packaging issues can be easily be found in specs, without downloading with the actual *.src.rpm. Ralf From braden at endoframe.com Wed Oct 14 09:01:14 2009 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 14 Oct 2009 05:01:14 -0400 Subject: [Fedora-packaging] %doc removal behavior Message-ID: <1255510874.24159.1910.camel@localhost> I'm trying to move some API docs to a -doc subpackage. I'd like to install these docs to /usr/share/doc/%{name}-%{version} (which corresponds to where "make install" puts them); so I do %files doc %doc %{_docdir}/%{name}-%{version}/manual instead of %files doc %doc doc/manual However, I'd like to leave README and similar in the main package, where I have %files %doc README NEWS COPYING.LESSER The problem I'm running into is that in the course of packaging the docs for the main package, rpm does rm -rf %{_docdir}/%{name}-%{version} So, when it subsequently tries to package the docs for the -doc subpackage, the "manual" subdirectory (that was put there by "make install") has been blown away. What can I do here? Is it possible to suppress the "rm -rf" that %doc does? -- Braden McDaniel From jussilehtola at fedoraproject.org Wed Oct 14 09:38:47 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 14 Oct 2009 12:38:47 +0300 Subject: [Fedora-packaging] %doc removal behavior In-Reply-To: <1255510874.24159.1910.camel@localhost> References: <1255510874.24159.1910.camel@localhost> Message-ID: <1255513127.22222.2.camel@politzer.theorphys.helsinki.fi> On Wed, 2009-10-14 at 05:01 -0400, Braden McDaniel wrote: > The problem I'm running into is that in the course of packaging the docs > for the main package, rpm does > > rm -rf %{_docdir}/%{name}-%{version} > > So, when it subsequently tries to package the docs for the -doc > subpackage, the "manual" subdirectory (that was put there by "make > install") has been blown away. > > What can I do here? Is it possible to suppress the "rm -rf" that %doc > does? Just use %doc to place the files in %{_docdir}, e.g. %doc doc/* If the files that should be placed in %doc don't exist in the buildroot, you can move them there in %install, e.g. make install DESTDIR=%{buildroot} # Move the documentation here mv %{buildroot}%{_docdir}/%{name}-%{version} installeddocs %files %doc installeddocs/* -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From limb at jcomserv.net Wed Oct 14 13:06:10 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 14 Oct 2009 08:06:10 -0500 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <4AD58AD2.608@freenet.de> References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> <4AD58AD2.608@freenet.de> Message-ID: <4AD5CCC2.90203@jcomserv.net> Ralf Corsepius wrote: > On 10/14/2009 09:55 AM, Nicolas Mailhot wrote: >> >> >> Le Mer 14 octobre 2009 05:47, Chris Weyl a ?crit : >>> >>> On Mon, Oct 12, 2009 at 10:13 PM, Matthias >>> Clasen wrote: >> >>>> That part of the review guidelines has always struck me as bizarre. >>>> After all, wouldn't it seem even better to compare the actual tarballs >>>> with each other, byte-by-byte, than relying on a checksum ? >>> >>> Um. An easily reproducible, cryptographically strong checksum? :) >> >> This is one test I never do, nothing will stop the packager from >> changing the >> packaged archive as soon as the review is finished, > ACK. > >> so the whole thing is a >> major waste of time for everyone involved IMHO > Agreed. Sort of. I think of it as CYA for the reviewer. If something bad slips in, at least it's documented that it was good when I checked it, and the responsibility then falls on the packager. > >> (as is posting specs in >> addition to SRPMs BTW. > Not agreed. Many packaging issues can be easily be found in specs, > without downloading with the actual *.src.rpm. True. I always wget both, install the SRPM and diff the specs, and ask about any differences if the packager goofed. Though I certainly see your point, especially for extremely large pacakges, like games with huge globs of data (i.e. wesnoth), etc. > > Ralf > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- in your fear, seek only peace in your fear, seek only love -d. bowie From rc040203 at freenet.de Wed Oct 14 13:36:54 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Oct 2009 15:36:54 +0200 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <4AD5CCC2.90203@jcomserv.net> References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> <4AD58AD2.608@freenet.de> <4AD5CCC2.90203@jcomserv.net> Message-ID: <4AD5D3F6.7050605@freenet.de> On 10/14/2009 03:06 PM, Jon Ciesla wrote: > Ralf Corsepius wrote: >> On 10/14/2009 09:55 AM, Nicolas Mailhot wrote: >>> (as is posting specs in >>> addition to SRPMs BTW. >> Not agreed. Many packaging issues can be easily be found in specs, >> without downloading with the actual *.src.rpm. > True. I always wget both, install the SRPM and diff the specs, and ask > about any differences if the packager goofed. Though I certainly see > your point, especially for extremely large pacakges, like games with > huge globs of data (i.e. wesnoth), etc. Another aspect, at least I use these *.specs for: I use them as a "sneak-preview" to decide on whether I would want to get involved into a review or if I would prefer to abstain from it. Ralf From tibbs at math.uh.edu Wed Oct 14 17:55:07 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 14 Oct 2009 12:55:07 -0500 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> (Nicolas Mailhot's message of "Wed, 14 Oct 2009 09:55:19 +0200") References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> This is one test I never do, nothing will stop the packager from NM> changing the packaged archive as soon as the review is finished, so NM> the whole thing is a major waste of time for everyone involved IMHO Perhaps I'd consider agreeing if doing the comparison hadn't turned up real issues. Perhaps you haven't done sufficient reviews to come across a case like that, but I have. - J< From nicolas.mailhot at laposte.net Wed Oct 14 18:04:16 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Oct 2009 20:04:16 +0200 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> Message-ID: <6538cdb964dc01c100c4e2376a44dc67.squirrel@arekh.dyndns.org> Le Mer 14 octobre 2009 19:55, Jason L Tibbitts III a ?crit : > >>>>>> "NM" == Nicolas Mailhot writes: > > NM> This is one test I never do, nothing will stop the packager from > NM> changing the packaged archive as soon as the review is finished, so > NM> the whole thing is a major waste of time for everyone involved IMHO > > Perhaps I'd consider agreeing if doing the comparison hadn't turned up > real issues. Perhaps you haven't done sufficient reviews to come across > a case like that, but I have. This is something for the BADURL script or autoqa, IMHO. The ROI on doing it manually, and only on the initial submission, is pretty low. -- Nicolas Mailhot From tibbs at math.uh.edu Wed Oct 14 18:56:04 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 14 Oct 2009 13:56:04 -0500 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: <6538cdb964dc01c100c4e2376a44dc67.squirrel@arekh.dyndns.org> (Nicolas Mailhot's message of "Wed, 14 Oct 2009 20:04:16 +0200") References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> <6538cdb964dc01c100c4e2376a44dc67.squirrel@arekh.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> This is something for the BADURL script or autoqa, IMHO. The ROI on NM> doing it manually, and only on the initial submission, is pretty NM> low. Well, so far I've caught many, many instances of improper URLs, several cases where the packager had modified the tarball and not realized that was problematic, and a few instances where the tarball needed to be modified but the packager hadn't documented the reasons or the necessary changes in accordance with our guidelines. All of those are things that need to be done in review, before the import, because the point is to actually check the packages before they're imported to guard against errors where the packager simply isn't aware of the proper way to do things. Letting crap get in and then mailbombing the packager with autoqa mail (which doesn't even exist at this point) isn't friendly to either the packager or the distribution. But of course we have no QA on actual package reviews, so I guess you're welcome to simply skip the step, or pretty much do whatever you want. And in any case, it's only a few keystrokes to run this after unpacking the srpm: #!/bin/sh mkdir source cd source spectool -g ../*spec for i in *; do sha256sum $i sha256sum ../$i done and only a further few seconds to look at the output, so the investment is rather low regardless of what you think the return is. - J< From nicolas.mailhot at laposte.net Wed Oct 14 19:09:29 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Oct 2009 21:09:29 +0200 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> <6538cdb964dc01c100c4e2376a44dc67.squirrel@arekh.dyndns.org> Message-ID: Le Mer 14 octobre 2009 20:56, Jason L Tibbitts III a ?crit : > >>>>>> "NM" == Nicolas Mailhot writes: > > NM> This is something for the BADURL script or autoqa, IMHO. The ROI on > NM> doing it manually, and only on the initial submission, is pretty > NM> low. > > Well, so far I've caught many, many instances of improper URLs, several > cases where the packager had modified the tarball and not realized that > was problematic, and a few instances where the tarball needed to be > modified but the packager hadn't documented the reasons or the necessary > changes in accordance with our guidelines. So what? It's a check tha -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Oct 14 19:17:43 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Oct 2009 21:17:43 +0200 Subject: [Fedora-packaging] Is md5sum compulsion in review instead sha1sum? In-Reply-To: References: <1255410822.2121.0.camel@planemask> <7dd7ab490910132047q7260207dmf9267e4cdb6a94d6@mail.gmail.com> <9013c8d5db6e92bc85293687edc47c33.squirrel@arekh.dyndns.org> <6538cdb964dc01c100c4e2376a44dc67.squirrel@arekh.dyndns.org> Message-ID: <888c1a3b7125fafc1fedcc55b391f17c.squirrel@arekh.dyndns.org> Le Mer 14 octobre 2009 20:56, Jason L Tibbitts III a ?crit : > >>>>>> "NM" == Nicolas Mailhot writes: > > NM> This is something for the BADURL script or autoqa, IMHO. The ROI on > NM> doing it manually, and only on the initial submission, is pretty > NM> low. > > Well, so far I've caught many, many instances of improper URLs, several > cases where the packager had modified the tarball and not realized that > was problematic, and a few instances where the tarball needed to be > modified but the packager hadn't documented the reasons or the necessary > changes in accordance with our guidelines. All of those are things that > need to be done in review, before the import, because the point is to > actually check the packages before they're imported to guard against > errors where the packager simply isn't aware of the proper way to do > things. I'm sure I don't need to remind you that last time I asked to add something to the checklist FPC/FESCO argued is was too long already and even if there were many many cases where it caused problems later on it was not worth listing it explicitely. The checksum test is clearly in the same category (and even less worth it because it's already checked automatically). > Letting crap get in and then mailbombing the packager with > autoqa mail (which doesn't even exist at this point) isn't friendly to > either the packager or the distribution. Well I'm afraid I've now spent quite a long time writing a mailbomber, because I was told the checklist is of-limits for rules that only catch marginal problems. I really do not see what makes the checksum test any more special or useful. -- Nicolas Mailhot From braden at endoframe.com Wed Oct 14 19:36:07 2009 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 14 Oct 2009 15:36:07 -0400 Subject: [Fedora-packaging] %doc removal behavior In-Reply-To: <1255513127.22222.2.camel@politzer.theorphys.helsinki.fi> References: <1255510874.24159.1910.camel@localhost> <1255513127.22222.2.camel@politzer.theorphys.helsinki.fi> Message-ID: <4AD62827.7010309@endoframe.com> On 10/14/09 5:38 AM, Jussi Lehtola wrote: > On Wed, 2009-10-14 at 05:01 -0400, Braden McDaniel wrote: >> The problem I'm running into is that in the course of packaging the docs >> for the main package, rpm does >> >> rm -rf %{_docdir}/%{name}-%{version} >> >> So, when it subsequently tries to package the docs for the -doc >> subpackage, the "manual" subdirectory (that was put there by "make >> install") has been blown away. >> >> What can I do here? Is it possible to suppress the "rm -rf" that %doc >> does? > > Just use %doc to place the files in %{_docdir}, e.g. > %doc doc/* The problem with that is that it does *not* put the files in %{_docdir} when it is used for a subpackage. Instead, the files are put in /usr/share/doc/subpackagename-%{version}. I don't want that. -- Braden McDaniel e-mail: Jabber: From jussilehtola at fedoraproject.org Wed Oct 14 21:07:04 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Thu, 15 Oct 2009 00:07:04 +0300 Subject: [Fedora-packaging] %doc removal behavior In-Reply-To: <4AD62827.7010309@endoframe.com> References: <1255510874.24159.1910.camel@localhost> <1255513127.22222.2.camel@politzer.theorphys.helsinki.fi> <4AD62827.7010309@endoframe.com> Message-ID: <1255554424.17396.5.camel@localhost> On Wed, 2009-10-14 at 15:36 -0400, Braden McDaniel wrote: > On 10/14/09 5:38 AM, Jussi Lehtola wrote: > > Just use %doc to place the files in %{_docdir}, e.g. > > %doc doc/* > > The problem with that is that it does *not* put the files in %{_docdir} > when it is used for a subpackage. Instead, the files are put in > /usr/share/doc/subpackagename-%{version}. I don't want that. Sorry, I must have misread your question. If you only use %docs with absolute paths, then rpm doesn't seem to remove %{_docdir}. If you use paths relative to the builddir, then rm -rf is run. For example %files %defattr(-,root,root,-) %doc A %files doc %defattr(-,root,root,-) %doc %{_docdir}/%{name}-%{version}/B does not work (fails with file B not found), but %files %defattr(-,root,root,-) %doc %{_docdir}/%{name}-%{version}/A %files doc %defattr(-,root,root,-) %doc %{_docdir}/%{name}-%{version}/B works just fine. PS. This list is actually off-topic for this kind of discussion, next time mail fedora-devel-list instead. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From braden at endoframe.com Thu Oct 15 06:13:29 2009 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 15 Oct 2009 02:13:29 -0400 Subject: [Fedora-packaging] %doc removal behavior In-Reply-To: <1255554424.17396.5.camel@localhost> References: <1255510874.24159.1910.camel@localhost> <1255513127.22222.2.camel@politzer.theorphys.helsinki.fi> <4AD62827.7010309@endoframe.com> <1255554424.17396.5.camel@localhost> Message-ID: <1255587209.3166.16.camel@localhost> On Thu, 2009-10-15 at 00:07 +0300, Jussi Lehtola wrote: > On Wed, 2009-10-14 at 15:36 -0400, Braden McDaniel wrote: > > On 10/14/09 5:38 AM, Jussi Lehtola wrote: > > > Just use %doc to place the files in %{_docdir}, e.g. > > > %doc doc/* > > > > The problem with that is that it does *not* put the files in %{_docdir} > > when it is used for a subpackage. Instead, the files are put in > > /usr/share/doc/subpackagename-%{version}. I don't want that. > > Sorry, I must have misread your question. > > If you only use %docs with absolute paths, then rpm doesn't seem to > remove %{_docdir}. If you use paths relative to the builddir, then rm > -rf is run. Ah, lovely. Thanks. > PS. This list is actually off-topic for this kind of discussion, next > time mail fedora-devel-list instead. I'm sorry. I wasn't sure if this was exclusively for policy discussion; and a look at previous traffic here didn't make it obvious. But I'll direct future queries of this sort to fedora-devel-list. -- Braden McDaniel From ville.skytta at iki.fi Sat Oct 17 10:33:29 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 17 Oct 2009 13:33:29 +0300 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines Message-ID: <200910171333.29486.ville.skytta@iki.fi> https://fedoraproject.org/wiki/Packaging:Python %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} These no longer work with Python 3 due to "print" changes. They should be replaced with something like these that work with both Python 2 and 3 (already done in spectemplate-python.spec in rpmdevtools git): %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import *; import sys; sys.stdout.write(get_python_lib())")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import *; import sys; sys.stdout.write(get_python_lib(1))")} From dmalcolm at redhat.com Sat Oct 17 14:36:40 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Sat, 17 Oct 2009 10:36:40 -0400 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines In-Reply-To: <200910171333.29486.ville.skytta@iki.fi> References: <200910171333.29486.ville.skytta@iki.fi> Message-ID: <1255790200.20812.14.camel@brick> On Sat, 2009-10-17 at 13:33 +0300, Ville Skytt? wrote: > https://fedoraproject.org/wiki/Packaging:Python > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print get_python_lib()")} > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > > These no longer work with Python 3 due to "print" changes. They should be > replaced with something like these that work with both Python 2 and 3 (already > done in spectemplate-python.spec in rpmdevtools git): > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from > distutils.sysconfig import *; import sys; > sys.stdout.write(get_python_lib())")} > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from > distutils.sysconfig import *; import sys; > sys.stdout.write(get_python_lib(1))")} At first glance, yes, the change you suggest does generalize those fragments of python code so they work with both python 2 and python 3 (it removes the trailing newline implicitly generated by "print", but AIUI that's getting discarded in the macro handling) However, I think it's going to be a long time until it's sane to make %{__python} be python 3 rather than python 2. I'm hoping we will have parallel-installable python 2 and python 3 stacks [1], with separate packages, probably separate srpms, so perhaps we need alternative formulations where we define python3_sitelib and python3_sitearch? Not sure yet. Your proposed change does ease migration, so a cautious "+1" from me. Dave [1] https://fedoraproject.org/wiki/Features/Python3F13 From martin.gieseking at uos.de Sun Oct 18 11:50:20 2009 From: martin.gieseking at uos.de (Martin Gieseking) Date: Sun, 18 Oct 2009 13:50:20 +0200 Subject: [Fedora-packaging] .gz suffix of compressed man pages in spec files Message-ID: <4ADB00FC.7050500@uos.de> Hi, during the review process of gtrayicon (https://bugzilla.redhat.com/show_bug.cgi?id=524605) the question was raised whether or not the .gz suffix of compressed manual pages should be omitted in a spec file. Since rpm automatically compresses man pages in a transparent process, I prefer to avoid appending the explicit suffix and use asterisks instead. On the other hand, adding .gz doesn't hurt as long as the compression method stays unchanged. So my question is: Is it up to the packager to either use %{_mandir}/man1/foo.1.gz or %{_mandir}/man1/foo.1*? I couldn't find any recommendation on this in the Fedora guidelines. Regards, Martin From cra at WPI.EDU Sun Oct 18 15:09:13 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 18 Oct 2009 11:09:13 -0400 Subject: [Fedora-packaging] .gz suffix of compressed man pages in spec files In-Reply-To: <4ADB00FC.7050500@uos.de> References: <4ADB00FC.7050500@uos.de> Message-ID: <20091018150913.GF9100@angus.ind.WPI.EDU> On Sun, Oct 18, 2009 at 01:50:20PM +0200, Martin Gieseking wrote: > So my question is: Is it up to the packager to either use > %{_mandir}/man1/foo.1.gz or %{_mandir}/man1/foo.1*? I couldn't find any > recommendation on this in the Fedora guidelines. IMO, * should be used so that if/when we change to bzip2 or xz or some other compression method you won't have to update spec files. From rc040203 at freenet.de Sun Oct 18 15:46:39 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 18 Oct 2009 17:46:39 +0200 Subject: [Fedora-packaging] .gz suffix of compressed man pages in spec files In-Reply-To: <20091018150913.GF9100@angus.ind.WPI.EDU> References: <4ADB00FC.7050500@uos.de> <20091018150913.GF9100@angus.ind.WPI.EDU> Message-ID: <4ADB385F.6080808@freenet.de> On 10/18/2009 05:09 PM, Chuck Anderson wrote: > On Sun, Oct 18, 2009 at 01:50:20PM +0200, Martin Gieseking wrote: >> So my question is: Is it up to the packager to either use >> %{_mandir}/man1/foo.1.gz or %{_mandir}/man1/foo.1*? Formally, yes, it's up to the packager. >> I couldn't find any >> recommendation on this in the Fedora guidelines. > > IMO, * should be used so that if/when we change to bzip2 or xz or > some other compression method you won't have to update spec files. Agreed. *.specs which use *.gz will break, should Fedora switch to a different compression. ... other distros did so many years, ago. Ralf From tgl at redhat.com Sun Oct 18 16:21:45 2009 From: tgl at redhat.com (Tom Lane) Date: Sun, 18 Oct 2009 12:21:45 -0400 Subject: [Fedora-packaging] .gz suffix of compressed man pages in spec files In-Reply-To: <4ADB385F.6080808@freenet.de> References: <4ADB00FC.7050500@uos.de> <20091018150913.GF9100@angus.ind.WPI.EDU> <4ADB385F.6080808@freenet.de> Message-ID: <7212.1255882905@sss.pgh.pa.us> Ralf Corsepius writes: > On 10/18/2009 05:09 PM, Chuck Anderson wrote: >> IMO, * should be used so that if/when we change to bzip2 or xz or >> some other compression method you won't have to update spec files. > Agreed. *.specs which use *.gz will break, should Fedora switch to a > different compression. > ... other distros did so many years, ago. I remember being told that the specfile should be agnostic as to whether manpage compression is used at all, let alone what kind it is. "*" accomplishes that (and ".*" doesn't, so it's still easy to get it wrong). If this isn't spelled out in the guidelines, it probably should be, because sooner or later a specfile that uses ".gz" is going to break. regards, tom lane From martin.gieseking at uos.de Sun Oct 18 20:44:22 2009 From: martin.gieseking at uos.de (Martin Gieseking) Date: Sun, 18 Oct 2009 22:44:22 +0200 Subject: [Fedora-packaging] .gz suffix of compressed man pages in spec files In-Reply-To: <7212.1255882905@sss.pgh.pa.us> References: <4ADB00FC.7050500@uos.de> <20091018150913.GF9100@angus.ind.WPI.EDU> <4ADB385F.6080808@freenet.de> <7212.1255882905@sss.pgh.pa.us> Message-ID: <4ADB7E26.9040700@uos.de> Am 18.10.2009 18:21, schrieb Tom Lane: > Ralf Corsepius writes: >> On 10/18/2009 05:09 PM, Chuck Anderson wrote: >>> IMO, * should be used so that if/when we change to bzip2 or xz or >>> some other compression method you won't have to update spec files. > >> Agreed. *.specs which use *.gz will break, should Fedora switch to a >> different compression. > >> ... other distros did so many years, ago. > > I remember being told that the specfile should be agnostic as to whether > manpage compression is used at all, let alone what kind it is. > "*" accomplishes that (and ".*" doesn't, so it's still easy to get it > wrong). If this isn't spelled out in the guidelines, it probably should > be, because sooner or later a specfile that uses ".gz" is going to > break. Thank you all for the clarification and for confirming my initial thought. I agree that it would be helpful to add a note on the recommended man patterns to the guidelines. Regards, Martin From martin.gieseking at uos.de Mon Oct 19 16:34:31 2009 From: martin.gieseking at uos.de (Martin Gieseking) Date: Mon, 19 Oct 2009 18:34:31 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? Message-ID: <4ADC9517.8040908@uos.de> Hi, according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 packages shouldn't get names that are general terms like "parser" or "smtp". If this is actually the case, "ascii" is probably an inappropriate name too. Should the package requested in https://bugzilla.redhat.com/show_bug.cgi?id=523799 therefore be prefixed or renamed even if "ascii" is the upstream name? Or is it OK as is, after all? Regards, Martin From limb at jcomserv.net Mon Oct 19 16:49:19 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 19 Oct 2009 11:49:19 -0500 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADC9517.8040908@uos.de> References: <4ADC9517.8040908@uos.de> Message-ID: <4ADC988F.6070408@jcomserv.net> Martin Gieseking wrote: > Hi, > > according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 > packages shouldn't get names that are general terms like "parser" or > "smtp". If this is actually the case, "ascii" is probably an > inappropriate name too. > Should the package requested in > https://bugzilla.redhat.com/show_bug.cgi?id=523799 > therefore be prefixed or renamed even if "ascii" is the upstream name? > Or is it OK as is, after all? > > Regards, > Martin > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging I vote rename. I've not looked at the review, and I've no idea what the package does. And googling it might be tricky. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From christoph.wickert at googlemail.com Mon Oct 19 17:09:50 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 19 Oct 2009 19:09:50 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADC9517.8040908@uos.de> References: <4ADC9517.8040908@uos.de> Message-ID: <1255972190.2824.2.camel@wicktop.localdomain> Am Montag, den 19.10.2009, 18:34 +0200 schrieb Martin Gieseking: > Hi, > > according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 > packages shouldn't get names that are general terms like "parser" or > "smtp". The reason is outlined at https://fedoraproject.org/wiki/Packaging_tricks#Use_of_common_namespace Regards, Christoph From rc040203 at freenet.de Mon Oct 19 17:15:14 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Oct 2009 19:15:14 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADC9517.8040908@uos.de> References: <4ADC9517.8040908@uos.de> Message-ID: <4ADC9EA2.6010209@freenet.de> On 10/19/2009 06:34 PM, Martin Gieseking wrote: > Hi, > > according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 > packages shouldn't get names that are general terms like "parser" or > "smtp". If this is actually the case, "ascii" is probably an > inappropriate name too. > Should the package requested in > https://bugzilla.redhat.com/show_bug.cgi?id=523799 > therefore be prefixed or renamed even if "ascii" is the upstream name? > Or is it OK as is, after all? Well, Debian has this package under it's original name. However, IMO, the better question would be: Why should Fedora ship it? Ralf From limb at jcomserv.net Mon Oct 19 17:29:28 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 19 Oct 2009 12:29:28 -0500 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADC9EA2.6010209@freenet.de> References: <4ADC9517.8040908@uos.de> <4ADC9EA2.6010209@freenet.de> Message-ID: <4ADCA1F8.8050706@jcomserv.net> Ralf Corsepius wrote: > On 10/19/2009 06:34 PM, Martin Gieseking wrote: >> Hi, >> >> according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 >> packages shouldn't get names that are general terms like "parser" or >> "smtp". If this is actually the case, "ascii" is probably an >> inappropriate name too. >> Should the package requested in >> https://bugzilla.redhat.com/show_bug.cgi?id=523799 >> therefore be prefixed or renamed even if "ascii" is the upstream name? >> Or is it OK as is, after all? > > Well, Debian has this package under it's original name. > > However, IMO, the better question would be: Why should Fedora ship it? > > Ralf > > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging I think it's functions are aptly handled by Google. That said, there might be offline uses, etc. Besides, we have a whole SIG centered around packages of dubious utility. http://fedoraproject.org/wiki/SIGs/Games -- in your fear, seek only peace in your fear, seek only love -d. bowie From martin.gieseking at uos.de Mon Oct 19 17:36:31 2009 From: martin.gieseking at uos.de (Martin Gieseking) Date: Mon, 19 Oct 2009 19:36:31 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <1255972190.2824.2.camel@wicktop.localdomain> References: <4ADC9517.8040908@uos.de> <1255972190.2824.2.camel@wicktop.localdomain> Message-ID: <4ADCA39F.5090706@uos.de> Am 19.10.2009 19:09, schrieb Christoph Wickert: > Am Montag, den 19.10.2009, 18:34 +0200 schrieb Martin Gieseking: >> according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 >> packages shouldn't get names that are general terms like "parser" or >> "smtp". > > The reason is outlined at > https://fedoraproject.org/wiki/Packaging_tricks#Use_of_common_namespace Christoph, thanks for pointing out the page I was looking for. As I take it, the package should actually be renamed or prefixed. Am 19.10.2009 19:15, schrieb Ralf Corsepius: > However, IMO, the better question would be: Why should Fedora ship it? Are there any reasons against this tool or does Fedora already provide a similar utility? I think it could be quite handy for some people. Regards, Martin From martin.gieseking at uos.de Tue Oct 20 15:15:03 2009 From: martin.gieseking at uos.de (Martin Gieseking) Date: Tue, 20 Oct 2009 17:15:03 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADC9EA2.6010209@freenet.de> References: <4ADC9517.8040908@uos.de> <4ADC9EA2.6010209@freenet.de> Message-ID: <4ADDD3F7.6070504@uos.de> Am 19.10.2009 19:15, schrieb Ralf Corsepius: > On 10/19/2009 06:34 PM, Martin Gieseking wrote: >> according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 >> packages shouldn't get names that are general terms like "parser" or >> "smtp". If this is actually the case, "ascii" is probably an >> inappropriate name too. >> Should the package requested in >> https://bugzilla.redhat.com/show_bug.cgi?id=523799 >> therefore be prefixed or renamed even if "ascii" is the upstream name? >> Or is it OK as is, after all? > > Well, Debian has this package under it's original name. Sorry for bothering again. I'm still not sure whether renaming of package "ascii" is required or just recommended. Does Ralf's remark about Debian indicate that Fedora could ship the package under its original name too? I'm a bit confused. :) Regards, Martin From rc040203 at freenet.de Tue Oct 20 16:03:20 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Oct 2009 18:03:20 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADDD3F7.6070504@uos.de> References: <4ADC9517.8040908@uos.de> <4ADC9EA2.6010209@freenet.de> <4ADDD3F7.6070504@uos.de> Message-ID: <4ADDDF48.4040107@freenet.de> On 10/20/2009 05:15 PM, Martin Gieseking wrote: > Am 19.10.2009 19:15, schrieb Ralf Corsepius: >> On 10/19/2009 06:34 PM, Martin Gieseking wrote: >>> according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 >>> packages shouldn't get names that are general terms like "parser" or >>> "smtp". If this is actually the case, "ascii" is probably an >>> inappropriate name too. >>> Should the package requested in >>> https://bugzilla.redhat.com/show_bug.cgi?id=523799 >>> therefore be prefixed or renamed even if "ascii" is the upstream name? >>> Or is it OK as is, after all? >> >> Well, Debian has this package under it's original name. > > > Sorry for bothering again. I'm still not sure whether renaming of > package "ascii" is required or just recommended. Does Ralf's remark > about Debian indicate that Fedora could ship the package under its > original name too? Actually, my position is ambivalent. On one hand it seems silly to me to force a tool's name incompatibility between Debian and Fedora, on the other hand, the wish to add this package [1] to Fedora also seems silly to me ;) > I'm a bit confused. :) Well, actually, I don't have much of a problem with this package's name -- I have a problem with this package! Ralf [1] This package seems around since 1990, nobody seems to have missed since then and appears to be poorly supported by its upstream (Last update in 2005, despite it has no reasonable build-system/Makefiles) From limb at jcomserv.net Tue Oct 20 16:29:58 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 20 Oct 2009 11:29:58 -0500 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADDDF48.4040107@freenet.de> References: <4ADC9517.8040908@uos.de> <4ADC9EA2.6010209@freenet.de> <4ADDD3F7.6070504@uos.de> <4ADDDF48.4040107@freenet.de> Message-ID: <4ADDE586.9020906@jcomserv.net> Ralf Corsepius wrote: > On 10/20/2009 05:15 PM, Martin Gieseking wrote: >> Am 19.10.2009 19:15, schrieb Ralf Corsepius: >>> On 10/19/2009 06:34 PM, Martin Gieseking wrote: >>>> according to https://bugzilla.redhat.com/show_bug.cgi?id=522988#c14 >>>> packages shouldn't get names that are general terms like "parser" or >>>> "smtp". If this is actually the case, "ascii" is probably an >>>> inappropriate name too. >>>> Should the package requested in >>>> https://bugzilla.redhat.com/show_bug.cgi?id=523799 >>>> therefore be prefixed or renamed even if "ascii" is the upstream name? >>>> Or is it OK as is, after all? >>> >>> Well, Debian has this package under it's original name. >> >> >> Sorry for bothering again. I'm still not sure whether renaming of >> package "ascii" is required or just recommended. Does Ralf's remark >> about Debian indicate that Fedora could ship the package under its >> original name too? > > Actually, my position is ambivalent. > > On one hand it seems silly to me to force a tool's name > incompatibility between Debian and Fedora, on the other hand, the wish > to add this package [1] to Fedora also seems silly to me ;) > >> I'm a bit confused. :) > > Well, actually, I don't have much of a problem with this package's > name -- I have a problem with this package! > > Ralf > > [1] This package seems around since 1990, nobody seems to have missed > since then and appears to be poorly supported by its upstream (Last > update in 2005, despite it has no reasonable build-system/Makefiles) Not to bikeshed, but it's also tiny. Since you won't be maintaining it, don't have to review it and don't have to install it, what's that harm in it's inclusion? > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- in your fear, seek only peace in your fear, seek only love -d. bowie From rc040203 at freenet.de Tue Oct 20 16:57:47 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Oct 2009 18:57:47 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADDE586.9020906@jcomserv.net> References: <4ADC9517.8040908@uos.de> <4ADC9EA2.6010209@freenet.de> <4ADDD3F7.6070504@uos.de> <4ADDDF48.4040107@freenet.de> <4ADDE586.9020906@jcomserv.net> Message-ID: <4ADDEC0B.1020004@freenet.de> On 10/20/2009 06:29 PM, Jon Ciesla wrote: > Ralf Corsepius wrote: >> On 10/20/2009 05:15 PM, Martin Gieseking wrote: >>> Am 19.10.2009 19:15, schrieb Ralf Corsepius: >>>> On 10/19/2009 06:34 PM, Martin Gieseking wrote: >> [1] This package seems around since 1990, nobody seems to have missed >> since then and appears to be poorly supported by its upstream (Last >> update in 2005, despite it has no reasonable build-system/Makefiles) > Not to bikeshed, but it's also tiny. Since you won't be maintaining it, > don't have to review it and don't have to install it, what's that harm > in it's inclusion? The actual harm is "waste of resources". However, my actual points behind this: Is Fedora supposed to be a "hardly useful" packages cult which adopts any package? Provided the quality of certain packages and how certain reviews are being performed, at least I can't deny this thought. Ralf From kparal at redhat.com Wed Oct 21 10:56:26 2009 From: kparal at redhat.com (Kamil Paral) Date: Wed, 21 Oct 2009 06:56:26 -0400 (EDT) Subject: [Fedora-packaging] new tool: rpmguard - print important differences between RPMs In-Reply-To: <54723383.938161256122543756.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <238111468.938181256122586110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi, I have created a simple tool called rpmguard for checking differences between RPM packages. It is very similar to rpmdiff, but it prints only important changes, not all. Therefore it can be used every time a new package is built to easily see if something hasn?t went completely wrong. Read more on: http://kparal.wordpress.com/2009/10/21/rpmguard-print-important-differences-between-rpms/ Any comments welcome! Kamil From omer at mrgc.com.pk Wed Oct 21 12:52:48 2009 From: omer at mrgc.com.pk (Syed Omer Farooq) Date: Wed, 21 Oct 2009 17:52:48 +0500 Subject: [Fedora-packaging] new tool: rpmguard - print important differencesbetween RPMs References: <238111468.938181256122586110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <044ABCF3DDD54618B694F5B11790A3BF@pstech01> pls enhance the email server in fedora like exchange or lotus but unfortunately no improvement in email server in fedora ----- Original Message ----- From: "Kamil Paral" To: Cc: ; Sent: Wednesday, October 21, 2009 3:56 PM Subject: [Fedora-packaging] new tool: rpmguard - print important differencesbetween RPMs > Hi, > > I have created a simple tool called rpmguard for checking differences > between RPM packages. It is very similar to rpmdiff, but it prints only > important changes, not all. Therefore it can be used every time a new > package is built to easily see if something hasn?t went completely wrong. > > Read more on: > http://kparal.wordpress.com/2009/10/21/rpmguard-print-important-differences-between-rpms/ > > Any comments welcome! > > Kamil > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From Jochen at herr-schmitt.de Thu Oct 22 17:15:24 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 22 Oct 2009 19:15:24 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <4ADDEC0B.1020004@freenet.de> References: <4ADC9517.8040908@uos.de> <4ADC9EA2.6010209@freenet.de> <4ADDD3F7.6070504@uos.de> <4ADDDF48.4040107@freenet.de> <4ADDE586.9020906@jcomserv.net> <4ADDEC0B.1020004@freenet.de> Message-ID: <0LrGGm-1M4hbP37SW-012wWb@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 20 Oct 2009 18:57:47 +0200, you wrote: >Is Fedora supposed to be a "hardly useful" packages cult which adopts >any package? Provided the quality of certain packages and how certain >reviews are being performed, at least I can't deny this thought. There was a request on http://fedoraproject.org/wiki/PackageMaintainers/WishList and because it's a tiny package you may not need a lot of time for maintainmence. For the naming discussion, because Debian use the same name as upstream and Debeian has more packages as Fedora, I see no problem to use the upstream package name for it. At least, of course I have wrote a mail to upstream fo suggest a rename of this package. But until now I haven't got any response. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) Charset: us-ascii wj8DBQFK4JM8T2AHK6txfgwRAu7NAKCfelOj71rj885HYl1zjXs5RzyK7QCgo+nv wnG80SByeLABizVzKk4YYfA= =d3G1 -----END PGP SIGNATURE----- From rc040203 at freenet.de Thu Oct 22 17:40:17 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Oct 2009 19:40:17 +0200 Subject: [Fedora-packaging] Is "ascii" a valid package name? In-Reply-To: <0LrGGm-1M4hbP37SW-012wWb@mrelayeu.kundenserver.de> References: <4ADC9517.8040908@uos.de> <4ADC9EA2.6010209@freenet.de> <4ADDD3F7.6070504@uos.de> <4ADDDF48.4040107@freenet.de> <4ADDE586.9020906@jcomserv.net> <4ADDEC0B.1020004@freenet.de> <0LrGGm-1M4hbP37SW-012wWb@mrelayeu.kundenserver.de> Message-ID: <4AE09901.7050809@freenet.de> On 10/22/2009 07:15 PM, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 20 Oct 2009 18:57:47 +0200, you wrote: > >> Is Fedora supposed to be a "hardly useful" packages cult which adopts >> any package? Provided the quality of certain packages and how certain >> reviews are being performed, at least I can't deny this thought. > > There was a request on > > http://fedoraproject.org/wiki/PackageMaintainers/WishList OK, it's someone's pony ... > and because it's a tiny package you may not need a lot of time > for maintainmence. > > For the naming discussion, because Debian use the same name as > upstream and Debeian has more packages as Fedora, I see no > problem to use the upstream package name for it. > > At least, of course I have wrote a mail to upstream fo suggest a > rename of this package. But until now I haven't got any response. Are you seriously expecting an answer? Ralf From sherry151 at gmail.com Thu Oct 22 18:51:05 2009 From: sherry151 at gmail.com (Rangeen Basu) Date: Fri, 23 Oct 2009 00:21:05 +0530 Subject: [Fedora-packaging] Garbage Collection of fc12 build [X-Post] Message-ID: Hi The fc12 build of one of my packages has been tagged with trashcan and will be deleted by koji. Does this mean that the package will be removed from the fc12 repository? If so then how can it be saved as it is a part of the fedora electronic lab and must not be removed at this point. -- Regards Rangeen Basu Roy Chowdhury Fedora Ambassador sherry151 at gmail.com Sent from Bangalore, KA, India From tibbs at math.uh.edu Thu Oct 22 20:00:50 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 22 Oct 2009 15:00:50 -0500 Subject: [Fedora-packaging] Garbage Collection of fc12 build [X-Post] In-Reply-To: (Rangeen Basu's message of "Fri, 23 Oct 2009 00:21:05 +0530") References: Message-ID: >>>>> "RB" == Rangeen Basu writes: RB> The fc12 build of one of my packages has been tagged with RB> trashcan and will be deleted by koji. You mean "one of your builds", not "one of your packages". RB> Does this mean that the package will be removed from the fc12 RB> repository? It means the build will be deleted. It was probably either a scratch build or was never pushed to any release. I'm sure that you could get more information about why the build is being deleted if you gave some information about the build itself. - J< From sherry151 at gmail.com Fri Oct 23 06:08:35 2009 From: sherry151 at gmail.com (Rangeen Basu) Date: Fri, 23 Oct 2009 11:38:35 +0530 Subject: [Fedora-packaging] Garbage Collection of fc12 build [X-Post] In-Reply-To: References: Message-ID: Below are the details. I am a little new to packaging and am not sure what unreferenced exactly means. > >?I'm sure that you could get > more information about why the build is being deleted if you gave some > information about the build itself. > The following build(s) are unreferenced and have been marked for deletion. They will be held in the trashcan tag for a grace period. At the end of that period they will be deleted permanently. This garbage collection is a normal part of build system operation. Please see the following url for more information: http://fedoraproject.org/wiki/Koji/GarbageCollection Build: archmage-0.2.3-1.fc12 http://koji.fedoraproject.org/koji/buildinfo?buildID=105650 Build: gnusim8085-1.3.5-4.fc12 http://koji.fedoraproject.org/koji/buildinfo?buildID=105348 If you would like to protect any of these builds from deletion, please refer to the document linked above for instructions. -- Regards Rangeen Basu Roy Chowdhury Fedora Ambassador sherry151 at gmail.com From tibbs at math.uh.edu Fri Oct 23 15:27:16 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 23 Oct 2009 10:27:16 -0500 Subject: [Fedora-packaging] Garbage Collection of fc12 build [X-Post] In-Reply-To: (Rangeen Basu's message of "Fri, 23 Oct 2009 11:38:35 +0530") References: Message-ID: >>>>> "RB" == Rangeen Basu writes: RB> Build: archmage-0.2.3-1.fc12 Not in any release; the current version in f12 is archmage-0.2.3-2.fc12. RB> Build: gnusim8085-1.3.5-4.fc12 Not in any release; the current version in f12 is gnusim8085-1.3.5-5.fc12. The build system doesn't keep every version ever built; that would grow without bound. It deletes builds which are no longer needed, and since those builds you list have been superseded by newer builds, there's simply no reason to continue to store them. The actual record of what was in that version is available from CVS, and you could rebuild that version from a checkout if you really needed to. - J< From sherry151 at gmail.com Fri Oct 23 17:15:01 2009 From: sherry151 at gmail.com (Rangeen Basu) Date: Fri, 23 Oct 2009 22:45:01 +0530 Subject: [Fedora-packaging] Garbage Collection of fc12 build [X-Post] In-Reply-To: References: Message-ID: > RB> Build: archmage-0.2.3-1.fc12 > > Not in any release; the current version in f12 is archmage-0.2.3-2.fc12. > > RB> Build: gnusim8085-1.3.5-4.fc12 > > Not in any release; the current version in f12 is > gnusim8085-1.3.5-5.fc12. > > The build system doesn't keep every version ever built; that would grow > without bound. ?It deletes builds which are no longer needed, and since > those builds you list have been superseded by newer builds, Thank you. I understand now. -- Regards Rangeen Basu Roy Chowdhury Fedora Ambassador sherry151 at gmail.com From mefoster at gmail.com Sat Oct 24 14:21:23 2009 From: mefoster at gmail.com (Mary Ellen Foster) Date: Sat, 24 Oct 2009 15:21:23 +0100 Subject: [Fedora-packaging] Using Debian packaging bits in Fedora packages Message-ID: I was just wondering -- is there a policy on using bits of Debian packages in Fedora packages? As a concrete example, if Debian has already packaged a Java library and has written a build.xml file (essentially, a Makefile) for building it, am I allowed to include that file in my package? Should I apply the whole Debian patch (complete with upstream URL) and then copy the build.xml to where it needs to be, or can I just grab the build.xml file itself and include it as a source? Thanks for any suggestions, MEF -- Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/ Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab School of Mathematical and Computer Sciences, Heriot-Watt University Heriot-Watt University is a Scottish charity registered under charity number SC000278 From tibbs at math.uh.edu Sat Oct 24 16:01:03 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 24 Oct 2009 11:01:03 -0500 Subject: [Fedora-packaging] Using Debian packaging bits in Fedora packages In-Reply-To: (Mary Ellen Foster's message of "Sat, 24 Oct 2009 15:21:23 +0100") References: Message-ID: >>>>> "MEF" == Mary Ellen Foster writes: MEF> I was just wondering -- is there a policy on using bits of Debian MEF> packages in Fedora packages? Why wouldn't you? Unless those bits are somehow non-free (which would be surprising given their source) or somehow something else restricts you from using them, you should try to make things as easy as possible on yourself and not duplicate work needlessly. Do credit the original source in comments in your spec even if you can't provide a full URL, just so folks who know where it came from if they happen to look at the package. - J< From Axel.Thimm at ATrpms.net Sat Oct 24 16:05:14 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 24 Oct 2009 19:05:14 +0300 Subject: [Fedora-packaging] Re: Using Debian packaging bits in Fedora packages In-Reply-To: References: Message-ID: <20091024160514.GB14436@victor.nirvana> On Sat, Oct 24, 2009 at 03:21:23PM +0100, Mary Ellen Foster wrote: > I was just wondering -- is there a policy on using bits of Debian > packages in Fedora packages? You mean a policy like "Not stealing from `antagonist' projects"? I don't think there is. As long as the general requirements are OK (licenses, not forbidden items, etc.) you can use any bits you need. > As a concrete example, if Debian has already packaged a Java library > and has written a build.xml file (essentially, a Makefile) for > building it, am I allowed to include that file in my package? Should > I apply the whole Debian patch (complete with upstream URL) and then > copy the build.xml to where it needs to be, or can I just grab the > build.xml file itself and include it as a source? Whatever makes more sense from a technical POV, but keep any author info pointing to Debian intact (e.g. add your own if you modify something, but don't remove any other author). You could even honour the import in a %changelog like to make it easier to identify the origin. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sagarun at gmail.com Sat Oct 24 17:00:08 2009 From: sagarun at gmail.com (Arun SAG) Date: Sat, 24 Oct 2009 22:30:08 +0530 Subject: [Fedora-packaging] Using Debian packaging bits in Fedora packages In-Reply-To: References: Message-ID: Hi, On Sat, Oct 24, 2009 at 7:51 PM, Mary Ellen Foster wrote: > >Should I apply the whole Debian patch > >(complete with upstream URL) > Debian uses dpatch , how it can be applied in fedora? Any dpatch to diff converters available? I have a situation here https://bugzilla.redhat.com/show_bug.cgi?id=530090 ; -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.skytta at iki.fi Sat Oct 24 20:55:13 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Sat, 24 Oct 2009 23:55:13 +0300 Subject: [Fedora-packaging] Using Debian packaging bits in Fedora packages In-Reply-To: References: Message-ID: <200910242355.13946.ville.skytta@iki.fi> On Saturday 24 October 2009, Arun SAG wrote: > Debian uses dpatch , how it can be applied in fedora? Hard to tell without seeing the *.dpatch contents in question, but I've seen several ones that can be applied with the regular patch command just like any other patch/diff. From sean at middleditch.us Sat Oct 24 23:02:09 2009 From: sean at middleditch.us (Sean Middleditch) Date: Sat, 24 Oct 2009 16:02:09 -0700 Subject: [Fedora-packaging] updated F12 dependent packages Message-ID: <4AE38771.7000909@middleditch.us> Hey everyone, I've got two packages in F12, libtelnet and clc, where clc is dependent on a specific version of libtelnet. I pushed libtelnet 0.12 into F12-updates-testing, but I cannot get clc in. The new version of clc has a hard dependency on libtelnet 0.12, but the repo for F12 hasn't rebuilt. According to Koji, it can't rebuild the repo because now clc won't build due to the old version only building against 0.11. How the hell am I supposed to push the update clc and fix the repo building? From jussilehtola at fedoraproject.org Sat Oct 24 23:17:01 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 25 Oct 2009 02:17:01 +0300 Subject: [Fedora-packaging] updated F12 dependent packages In-Reply-To: <4AE38771.7000909@middleditch.us> References: <4AE38771.7000909@middleditch.us> Message-ID: <1256426221.5420.2.camel@localhost> On Sat, 2009-10-24 at 16:02 -0700, Sean Middleditch wrote: > Hey everyone, > > I've got two packages in F12, libtelnet and clc, where clc is dependent > on a specific version of libtelnet. I pushed libtelnet 0.12 into > F12-updates-testing, but I cannot get clc in. The new version of clc > has a hard dependency on libtelnet 0.12, but the repo for F12 hasn't > rebuilt. According to Koji, it can't rebuild the repo because now clc > won't build due to the old version only building against 0.11. > > How the hell am I supposed to push the update clc and fix the repo building? You need to file a request for a buildroot override for libtelnet in F-12 at https://fedorahosted.org/rel-eng/ Once libtelnet 0.12 has been tagged in the buildroot, you can build the new version of clc, and then push them both as updates at once (or ask them to be tagged in the final release of F-12). -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From sean at middleditch.us Sat Oct 24 23:31:50 2009 From: sean at middleditch.us (Sean Middleditch) Date: Sat, 24 Oct 2009 16:31:50 -0700 Subject: [Fedora-packaging] updated F12 dependent packages In-Reply-To: <1256426221.5420.2.camel@localhost> References: <4AE38771.7000909@middleditch.us> <1256426221.5420.2.camel@localhost> Message-ID: <4AE38E66.1080208@middleditch.us> On 10/24/2009 04:17 PM, Jussi Lehtola wrote: > On Sat, 2009-10-24 at 16:02 -0700, Sean Middleditch wrote: >> How the hell am I supposed to push the update clc and fix the repo building? > > You need to file a request for a buildroot override for libtelnet in > F-12 at > https://fedorahosted.org/rel-eng/ > > Once libtelnet 0.12 has been tagged in the buildroot, you can build the > new version of clc, and then push them both as updates at once (or ask > them to be tagged in the final release of F-12). Alright, I made the ticket. Thanks, Jussi! I recall having seen something about that before in the Wiki, but it's not explained at all in the Package Update Page at http://fedoraproject.org/wiki/Package_update_HOWTO that I see. I've run into a LOT of missing, inaccurate, or just impossible to find documentation regarding packaging in the Wiki, and given that I'm one of the people who lacks the information, I'm not exactly in the position to add and reorganize the information there. Maybe there should be a Wiki Cleanup Day or something to sort out all the old cruft, properly organize the rules and policies, and make those new package and update guides clean, readable, complete, and awesome. From vpivaini at cs.helsinki.fi Sun Oct 25 12:24:28 2009 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sun, 25 Oct 2009 14:24:28 +0200 Subject: [Fedora-packaging] Errors in Packaging:Python#Byte_Compiled_Files Message-ID: <1256473468.1915.7.camel@poytakone.lan> Hi, I'm adding a Python interface to a package of mine and was reading https://fedoraproject.org/wiki/Packaging:Python#Byte_Compiled_Files where it says: %install install -d %{python_sitelib}/foo install -pm 0644 foo.py %{python_sitelib}/foo/ but you can't actually use %{python_sitelib} on it's own in %install. I think those instructions should be something like: %install install -d $RPM_BUILD_ROOT%{python_sitelib}/foo install -pm 0644 foo.py $RPM_BUILD_ROOT%{python_sitelib}/foo/ -- Ville-Pekka Vainio From dtimms at iinet.net.au Sun Oct 25 14:04:53 2009 From: dtimms at iinet.net.au (David Timms) Date: Mon, 26 Oct 2009 01:04:53 +1100 Subject: [Fedora-packaging] app wants runtime help file in /usr/share/help Message-ID: <4AE45B05.5070002@iinet.net.au> Hi, an app I maintain recently gained a help menu. It expects to find the single help.html file in /usr/share/help (ie: make install helpdir=%{buildroot}%{_datadir}/help ) This folder seems to be owned by rarian, and hence doesn't seem to make sense as location to place this help file. Is the best approach to patch the src so that it expects to find the help file in a better location ? What would that location be ? ie. maybe: make install helpdir=%{buildroot}%{_datadir}/%{name} , and then adjust src to look there ? Cheers, David Timms From a.badger at gmail.com Sun Oct 25 14:20:34 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 25 Oct 2009 07:20:34 -0700 Subject: [Fedora-packaging] Errors in Packaging:Python#Byte_Compiled_Files In-Reply-To: <1256473468.1915.7.camel@poytakone.lan> References: <1256473468.1915.7.camel@poytakone.lan> Message-ID: <20091025142034.GE3204@clingman.lan> On Sun, Oct 25, 2009 at 02:24:28PM +0200, Ville-Pekka Vainio wrote: > Hi, > > I'm adding a Python interface to a package of mine and was reading > https://fedoraproject.org/wiki/Packaging:Python#Byte_Compiled_Files > where it says: > > %install > install -d %{python_sitelib}/foo > install -pm 0644 foo.py %{python_sitelib}/foo/ > > but you can't actually use %{python_sitelib} on it's own in %install. > I think those instructions should be something like: > > %install > install -d $RPM_BUILD_ROOT%{python_sitelib}/foo > install -pm 0644 foo.py $RPM_BUILD_ROOT%{python_sitelib}/foo/ > Fixed. Thank you very much for reporting. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From itamar at ispbrasil.com.br Sun Oct 25 14:41:10 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Sun, 25 Oct 2009 12:41:10 -0200 Subject: [Fedora-packaging] Errors in Packaging:Python#Byte_Compiled_Files In-Reply-To: <20091025142034.GE3204@clingman.lan> References: <1256473468.1915.7.camel@poytakone.lan> <20091025142034.GE3204@clingman.lan> Message-ID: why not install -Dpm 0644 foo.py $RPM_BUILD_ROOT%{python_sitelib}/foo/foo.py just in one line. like: >> >> %install >> install -d $RPM_BUILD_ROOT%{python_sitelib}/foo >> install -pm 0644 foo.py $RPM_BUILD_ROOT%{python_sitelib}/foo/ >> ------------ Itamar Reis Peixoto e-mail/msn/google talk/sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From sunil.sahoo at artificialmachines.com Mon Oct 26 07:21:23 2009 From: sunil.sahoo at artificialmachines.com (sunil.sahoo at artificialmachines.com) Date: Mon, 26 Oct 2009 00:21:23 -0700 (PDT) Subject: [Fedora-packaging] Help need to create rpm package for my java pplication Message-ID: <14757.123.252.208.121.1256541683.squirrel@webmail.artificialmachines.com> Hi all, I have created a java application. Now I need to create rpm package for that application. Also I want to put desktop shortcut and icon also. means if i go to Applications and click on shortcut then my original program will start. Actually I have created an rpm file it works fine, But I was unable to get how to do for desktop shortcut and icon for that application I need your help Thanks Sunil Kumar Sahoo From rc040203 at freenet.de Mon Oct 26 07:37:30 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 26 Oct 2009 08:37:30 +0100 Subject: [Fedora-packaging] app wants runtime help file in /usr/share/help In-Reply-To: <4AE45B05.5070002@iinet.net.au> References: <4AE45B05.5070002@iinet.net.au> Message-ID: <4AE551BA.6000703@freenet.de> On 10/25/2009 03:04 PM, David Timms wrote: > Hi, an app I maintain recently gained a help menu. It expects to find > the single help.html file in /usr/share/help > (ie: > make install helpdir=%{buildroot}%{_datadir}/help > ) > > This folder seems to be owned by rarian, and hence doesn't seem to make > sense as location to place this help file. This sounds like a blatant bug in rarian to me ;-) > Is the best approach to patch the src so that it expects to find the > help file in a better location ? > What would that location be ? > > ie. maybe: > make install helpdir=%{buildroot}%{_datadir}/%{name} No, because this would only change the directory of installation, but would not change the application's expectiations (the application's built-in directory). I.e. the application would still look into $(datadir)/help while the files it expects to find are located elsewhere. > , and then adjust src to look there ? Exactly. You have to change the sources to make the app look into the modified installation directory. How to implement this depends on a package's configuration/makefile details. In some cases it would be necessary to patch the sources. In some cases it's possible to override values at "configuration-time" or make-time. I.e. there are chances %configure helpdir=%{_datadir}/%{name} make make install DESTDIR="..." might work. or %configure make helpdir="%{_datadir}/%{name}" make helpdir="%{_datadir}/%{name}" DESTDIR="..." install will work. Ralf From rakesh.pandit at gmail.com Mon Oct 26 09:34:03 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Mon, 26 Oct 2009 15:04:03 +0530 Subject: [Fedora-packaging] Help need to create rpm package for my java pplication In-Reply-To: <14757.123.252.208.121.1256541683.squirrel@webmail.artificialmachines.com> References: <14757.123.252.208.121.1256541683.squirrel@webmail.artificialmachines.com> Message-ID: 2009/10/26 Sunil wrote: [..] > > Actually I have created an rpm file it works fine, But I was unable to get > how to do for desktop shortcut and icon for that application > [..] I guess you are asking about how to accommodate desktop file in your spec. https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files ^^^ This has all details. -- Rakesh Pandit https://fedoraproject.org/ freedom, friends, features, first From dtimms at iinet.net.au Mon Oct 26 13:05:02 2009 From: dtimms at iinet.net.au (David Timms) Date: Tue, 27 Oct 2009 00:05:02 +1100 Subject: [Fedora-packaging] app wants runtime help file in /usr/share/help In-Reply-To: <4AE551BA.6000703@freenet.de> References: <4AE45B05.5070002@iinet.net.au> <4AE551BA.6000703@freenet.de> Message-ID: <4AE59E7E.8040908@iinet.net.au> On 10/26/2009 06:37 PM, Ralf Corsepius wrote: > This sounds like a blatant bug in rarian to me ;-) Although, there was a bz requesting that rarian own that folder. I thought I might be missing some knowledge about whether a help file for an app could/should live there. > In some cases it's possible to override values at "configuration-time" > or make-time. I hoped there would be, but alas, the source code needed to be modified. I placed the file in %{buildroot}%{_datadir}/%{name}. I take it from Ralf's answer, that this is an acceptable/suitable place to put it ? AIUI, it couldn't go in %doc dir ? And should the folder include the version (or does it that only apply to %doc location ?). Thanks, DaveT. From rc040203 at freenet.de Mon Oct 26 13:16:22 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 26 Oct 2009 14:16:22 +0100 Subject: [Fedora-packaging] app wants runtime help file in /usr/share/help In-Reply-To: <4AE59E7E.8040908@iinet.net.au> References: <4AE45B05.5070002@iinet.net.au> <4AE551BA.6000703@freenet.de> <4AE59E7E.8040908@iinet.net.au> Message-ID: <4AE5A126.4000808@freenet.de> On 10/26/2009 02:05 PM, David Timms wrote: > On 10/26/2009 06:37 PM, Ralf Corsepius wrote: >> This sounds like a blatant bug in rarian to me ;-) > Although, there was a bz requesting that rarian own that folder. I > thought I might be missing some knowledge about whether a help file for > an app could/should live there. Well, the question would be: Is /usr/share/help an acceptable directory to be owned by an arbitrary application? IMO, it is not. It's a too general directory name to allow an arbitrary application to own it and fill it with some "non-standardized files". >> In some cases it's possible to override values at "configuration-time" >> or make-time. > I hoped there would be, but alas, the source code needed to be modified. > > I placed the file in %{buildroot}%{_datadir}/%{name}. > > I take it from Ralf's answer, that this is an acceptable/suitable place > to put it ? > > AIUI, it couldn't go in %doc dir ? > And should the folder include the version (or does it that only apply to > %doc location ?). Which package are we talking about? Are the sources rsp. your packaging publicly available somewhere? Ralf From sanjay.ankur at gmail.com Mon Oct 26 20:06:00 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Tue, 27 Oct 2009 01:36:00 +0530 Subject: [Fedora-packaging] Help need to create rpm package for my java pplication In-Reply-To: <14757.123.252.208.121.1256541683.squirrel@webmail.artificialmachines.com> References: <14757.123.252.208.121.1256541683.squirrel@webmail.artificialmachines.com> Message-ID: <1256587560.8271.0.camel@localhost> On Mon, 2009-10-26 at 00:21 -0700, sunil.sahoo at artificialmachines.com wrote: > Hi all, > I have created a java application. Now I need to create rpm > package for that application. Also I want to put desktop shortcut > and icon also. means if i go to Applications and click on shortcut > then my original program will start. > > > Actually I have created an rpm file it works fine, But I was unable to get > how to do for desktop shortcut and icon for that application > > I need your help > > > Thanks > Sunil Kumar Sahoo hey, Please have a look here[1]. It should be sufficient :) [1] https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files -- regards, Ankur From dtimms at iinet.net.au Tue Oct 27 11:00:24 2009 From: dtimms at iinet.net.au (David Timms) Date: Tue, 27 Oct 2009 22:00:24 +1100 Subject: [Fedora-packaging] app wants runtime help file in /usr/share/help In-Reply-To: <4AE5A126.4000808@freenet.de> References: <4AE45B05.5070002@iinet.net.au> <4AE551BA.6000703@freenet.de> <4AE59E7E.8040908@iinet.net.au> <4AE5A126.4000808@freenet.de> Message-ID: <4AE6D2C8.5090004@iinet.net.au> On 10/27/2009 12:16 AM, Ralf Corsepius wrote: >> AIUI, it couldn't go in %doc dir ? >> And should the folder include the version (or does it that only apply to >> %doc location ?). > Which package are we talking about? Are the sources rsp. your packaging > publicly available somewhere? It's dvbcut: http://cvs.rpmfusion.org/viewvc/rpms/dvbcut/devel/?root=free http://dvbcut.svn.sourceforge.net/viewvc/dvbcut/trunk/ Cheers, DaveT. From richard.hellier at stfc.ac.uk Tue Oct 27 16:16:14 2009 From: richard.hellier at stfc.ac.uk (richard.hellier at stfc.ac.uk) Date: Tue, 27 Oct 2009 16:16:14 -0000 Subject: [Fedora-packaging] Help please? How do I express a dependency on a Perl module not installed in a standard place within an RPM spec file? Message-ID: Hi, Situation I have is this: (a) I have a bunch of perl scripts that use a perl module (say Foo) that is not installed on the "package build machine" (b) On the target machine, the FOO module was "hand installed" in antiquity in /opt/foo In the perl scripts, I have: Use lib qw{/opt/foo/lib}; Use Foo::Bar; SO - I can build the package fine but when I try to install it, I get the messages: error: Failed dependencies: perl(Foo::Bar) is needed by some-package-1.1.1-1.noarch Any ideas, please, how I can "teach" the spec file that the required perl module lives in a certain place on the target machine? Thanks! Richard. -- Scanned by iCritical. -------------- next part -------------- An HTML attachment was scrubbed... URL: From limb at jcomserv.net Tue Oct 27 16:53:18 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 27 Oct 2009 11:53:18 -0500 Subject: [Fedora-packaging] Help please? How do I express a dependency on a Perl module not installed in a standard place within an RPM spec file? In-Reply-To: References: Message-ID: <4AE7257E.7070408@jcomserv.net> richard.hellier at stfc.ac.uk wrote: > > Hi, > > Situation I have is this: > > (a) I have a bunch of perl scripts that use a perl module (say Foo) > that is not installed on the ?package build machine? > > (b) On the target machine, the FOO module was ?hand installed? in > antiquity in /opt/foo > > In the perl scripts, I have: > > Use lib qw{/opt/foo/lib}; > > Use Foo::Bar; > > SO ? I can build the package fine but when I try to install it, I get > the messages: > > error: Failed dependencies: > > perl(Foo::Bar) is needed by some-package-1.1.1-1.noarch > > Any ideas, please, how I can ?teach? the spec file that the required > perl module lives in a certain place on the target machine? > > Thanks! > > Richard. > > > -- > Scanned by iCritical. > > > ------------------------------------------------------------------------ > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > Um. . .don't? Put the module in a package. Or, use a file Requires, but I think it'll still look for it in the system Perl places. -- in your fear, seek only peace in your fear, seek only love -d. bowie From paul at city-fan.org Tue Oct 27 16:56:54 2009 From: paul at city-fan.org (Paul Howarth) Date: Tue, 27 Oct 2009 16:56:54 +0000 Subject: [Fedora-packaging] Help please? How do I express a dependency on a Perl module not installed in a standard place within an RPM spec file? In-Reply-To: References: Message-ID: <4AE72656.2080106@city-fan.org> On 27/10/09 16:16, richard.hellier at stfc.ac.uk wrote: > Hi, > > Situation I have is this: > > (a) I have a bunch of perl scripts that use a perl module (say Foo) that > is not installed on the ?package build machine? > > (b) On the target machine, the FOO module was ?hand installed? in > antiquity in /opt/foo > > In the perl scripts, I have: > > Use lib qw{/opt/foo/lib}; > > Use Foo::Bar; > > SO ? I can build the package fine but when I try to install it, I get > the messages: > > error: Failed dependencies: > > perl(Foo::Bar) is needed by some-package-1.1.1-1.noarch > > Any ideas, please, how I can ?teach? the spec file that the required > perl module lives in a certain place on the target machine? > > Thanks! > > Richard. Why don't you just create a perl-Foo package to properly package the module? If there's some really really good reason why you can't do that, you can fix the requires: https://fedoraproject.org/wiki/Packaging/Perl#Filtering_Requires:_and_Provides On recent Fedoras you can also use this scheme: http://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFiltering Paul. From loupgaroublond at gmail.com Wed Oct 28 15:49:10 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 28 Oct 2009 16:49:10 +0100 Subject: [Fedora-packaging] Using Debian packaging bits in Fedora packages In-Reply-To: References: Message-ID: <7f692fec0910280849i651cc562u8b21b5cb78c7cfcf@mail.gmail.com> 2009/10/24 Mary Ellen Foster : > I was just wondering -- is there a policy on using bits of Debian > packages in Fedora packages? As a concrete example, if Debian has > already packaged a Java library and has written a build.xml file > (essentially, a Makefile) for building it, am I allowed to include > that file in my package? Should I apply the whole Debian patch > (complete with upstream URL) and then copy the build.xml to where it > needs to be, or can I just grab the build.xml file itself and include > it as a source? > > Thanks for any suggestions, Not only is thsi a good idea, but there are ways to take this further. We had a little distro mini summit at the Google Summer of Code Mentor Summit, and i think the one big takeaway impression i had is that we would all like to see more cooperation between distros. With that in mind, why not also email the debian maintainer(s) and let him/her/them know you're copying their file. Then offer to collaborate in the future. If you can at least keep each other informed about possible changes either of you need to make, it means we'll have better and more consistent packages in both Fedora and Debian. -Yaakov From mkent at magoazul.com Thu Oct 29 17:48:27 2009 From: mkent at magoazul.com (Matthew Kent) Date: Thu, 29 Oct 2009 10:48:27 -0700 Subject: [Fedora-packaging] ruby/rubygem packagers - advice needed Message-ID: Having some difficulty deciding on the right path for this package, need some advice. ohai - http://wiki.opscode.com/display/ohai/Home "Ohai detects data about your operating system. It can be used standalone, but it's primary purpose is to provide node data to Chef." - Written in Ruby. - Available as a rubygem. - No standalone install via tar.gz + setup.rb yet. - 6 dependencies. All currently packaged as rubygem-* packages. 5 of which I'm the maintainer. - Available in Debian/Ubuntu as 'ohai', packaged from source and uses no rubygems at all. - require 'rubygems' has been removed from the codebase, only time it's loaded now is when the user installs via gems and it generates the little /usr/bin/ohai wrapper. Options: a) Package as rubygem-ohai from .gem Pro - Easiest method, rubygem-* dependencies work as is. Pro - As there is no setup.rb yet this may ease maintenance. Con - Different from Debian naming. ohai is also very similar to the 'facter' package that puppet uses, should be positioned in the same way. Con - Can only use what's carried in the gem, eg: man page isn't. Would have to carry as a separate Source. Could have unit tests removed from the gem in the future if they grow too large (upstream did this for another gem they produce). b) Package as ohai from a checkout of the git tag, dependencies on rubygem-* packages Pro - Common package name with other distros. Pro - Have access to install all content, including the man page. Con - Handcrafted %install. Con - Have to forever patch lib/ohai to load rubygems so the dependencies resolve. c) Package as ohai from a checkout of the git tag, dependencies on non gem ruby-* packages Pro - Common package name with other distros. Pro - Have access to install all content, including the man page. Pro - No need to patch to load rubygems. Con - Handcrafted %install. Con - Will need to produce non gem sub packages for every dependency, immediately adding 4 additional rpms to the repos. d) ? This decision making process is much the same for my main goal of packaging Chef (http://wiki.opscode.com/display/chef/Home) but has bigger implications as it has way more dependencies, needs init scripts, it's own user, etc. Stuff that is probably beyond the scope of rubygem-* packages (?). I'm leaning toward option c) as I like the idea of using the unmodified source in it's entirety, which once a setup.rb is added upstream won't be that bad. I'm interested to hear any thoughts on potentially generating a bunch more ruby-* packages though. Thoughts? - Matt From tcallawa at redhat.com Thu Oct 29 18:46:47 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 29 Oct 2009 14:46:47 -0400 Subject: [Fedora-packaging] ruby/rubygem packagers - advice needed In-Reply-To: References: Message-ID: <4AE9E317.7050001@redhat.com> On 10/29/2009 01:48 PM, Matthew Kent wrote: > I'm interested to hear any thoughts on potentially > generating a bunch more ruby-* packages though. I wouldn't lose sleep over adding 4 more ruby packages. ~spot From dmalcolm at redhat.com Thu Oct 29 22:27:35 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 29 Oct 2009 18:27:35 -0400 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <4AC50044.6090804@gmail.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> Message-ID: <1256855255.3731.3394.camel@brick> (Resurrecting the "Proposal: Python 3 in Fedora 13" thread; see: https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html and https://fedoraproject.org/wiki/Features/Python3F13 ) On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote: > On 10/01/2009 10:15 AM, David Malcolm wrote: [snip] > > "Naming convention" proposal: > > How does this sound: > > - an rpm with a "python-" prefix means a python 2 rpm, of the > > "default" python 2 minor version (for Fedora this will be the most > > recent stable upstream minor release, for EPEL it will be the minor > > release of 2 that came with the distro, so 2.4 for EPEL5) > > > > - an rpm with a "python3-" prefix means a python 3 rpm, of the > > "default" python 3 minor version (for Fedora this will be the most > > recent stable upstream release) > > > > What about packages without a "python-" prefix? Proposal: If upstream > > has a naming convention for python2 vs python3, use it. Otherwise, add > > a "python3-" prefix to make things clear. I'm not sure about the > > details here. Examples? > > > +1 to the basics. There are a lot of details to work out: Current naming conventions for Python packages are in https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28python_modules.29 I rather like the idea of standardizing on a "python3-" prefix for _all_ Python 3 module packages and subpackages, even if this leads to inconsistencies with their counterparts in the python 2 stack. It would make the "threeness" of the packages stand out more. (NB: I hope that we'll eventually be in a place where we can cut over embedders and users of python (e.g. gedit, gdb, mod_python etc) from 2 to 3; I'm _not_ suggesting we do anything to their names. Obviously such a move is a long way off) > This seems fine even though it's a bit redundant: python3-pygtk2 and > python3-pygpgme. We could combine: - the "always use a python3-" rule I invented just above (ahem) and - the "When in doubt, use the name of the module that you type to import it in a script" advice from the python module guidelines. This would make the above examples be "python3-gtk" and "python3-gpgme" > What to do with things that have python in their suffix: > gstreamer-python => gstreamer-python3? Or python3-gstreamer? Or > python3-gstreamer-python? Most of these are subpackages of existing > packages. Again, following the combination of the two rules above: "python3-gstreamer" > A cornercase is the gnome-python2 package. These are python bindings to > gnome2. gnome-python2 is the upstream name. For python3, do we want > python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? >From my reading of "rpm -qi gnome-python2", the upstream name is "gnome-python", so perhaps "python3-gnome" is the thing to use here? Thoughts? Dave From dmalcolm at redhat.com Thu Oct 29 22:35:04 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 29 Oct 2009 18:35:04 -0400 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines In-Reply-To: <1255790200.20812.14.camel@brick> References: <200910171333.29486.ville.skytta@iki.fi> <1255790200.20812.14.camel@brick> Message-ID: <1256855704.3731.3404.camel@brick> On Sat, 2009-10-17 at 10:36 -0400, David Malcolm wrote: > On Sat, 2009-10-17 at 13:33 +0300, Ville Skytt? wrote: > > https://fedoraproject.org/wiki/Packaging:Python > > > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from > > distutils.sysconfig import get_python_lib; print get_python_lib()")} > > > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from > > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > > > > > These no longer work with Python 3 due to "print" changes. They should be > > replaced with something like these that work with both Python 2 and 3 (already > > done in spectemplate-python.spec in rpmdevtools git): > > > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from > > distutils.sysconfig import *; import sys; > > sys.stdout.write(get_python_lib())")} > > > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from > > distutils.sysconfig import *; import sys; > > sys.stdout.write(get_python_lib(1))")} > [snip] > Your proposed change does ease migration, so a cautious "+1" from me. [snip] Did the change to the guidelines happen, and did the rpmdevtools template get updated? From jdennis at redhat.com Thu Oct 29 22:42:51 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 29 Oct 2009 18:42:51 -0400 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <1256855255.3731.3394.camel@brick> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> Message-ID: <4AEA1A6B.10601@redhat.com> On 10/29/2009 06:27 PM, David Malcolm wrote: > I rather like the idea of standardizing on a "python3-" prefix for _all_ > Python 3 module packages and subpackages, even if this leads to > inconsistencies with their counterparts in the python 2 stack. It would > make the "threeness" of the packages stand out more. > > Thoughts? Initially this sounds good to me. Because python 2 and python 3 are incompatible it's probably important we separate them at the packaging level, this seems like a good approach as any (even with some warts on the corner cases). However package maintainers might not like the idea of having to maintain double the number of their packages for an interim period and I could see them wanting to have just one package that installs into both the python2 and python3 library locations. Also perhaps we don't want to inflate the number of python packages by 2x. Having not followed this discussion from it's outset I'm wondering if we might want to consider allowing a single python package to support both python versions. I'm sure there are multiple reasons why this is a horrible idea, but I thought I would throw it out for consideration and let it get shot down :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dmalcolm at redhat.com Fri Oct 30 00:15:01 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 29 Oct 2009 20:15:01 -0400 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <4AEA1A6B.10601@redhat.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <4AEA1A6B.10601@redhat.com> Message-ID: <1256861701.3731.3552.camel@brick> On Thu, 2009-10-29 at 18:42 -0400, John Dennis wrote: > On 10/29/2009 06:27 PM, David Malcolm wrote: > > > I rather like the idea of standardizing on a "python3-" prefix for _all_ > > Python 3 module packages and subpackages, even if this leads to > > inconsistencies with their counterparts in the python 2 stack. It would > > make the "threeness" of the packages stand out more. > > > > Thoughts? > > Initially this sounds good to me. Because python 2 and python 3 are > incompatible it's probably important we separate them at the packaging > level, this seems like a good approach as any (even with some warts on > the corner cases). > > However package maintainers might not like the idea of having to > maintain double the number of their packages for an interim period and I > could see them wanting to have just one package that installs into both > the python2 and python3 library locations. Also perhaps we don't want to > inflate the number of python packages by 2x. Having not followed this > discussion from it's outset I'm wondering if we might want to consider > allowing a single python package to support both python versions. I'm > sure there are multiple reasons why this is a horrible idea, but I > thought I would throw it out for consideration and let it get shot down :-) My original proposal [1] was that python 3 should be entirely separate from python 2 As a trial run, I took a packaged python module and got it to build with python 3. See: https://bugzilla.redhat.com/show_bug.cgi?id=531648 This is the separate-srpm approach, it would live as a separate package in CVS. As an experiment, I tried hacking up the same module's specfile so that one build generates both 2 and 3 subpackages. You can see the result here: https://bugzilla.redhat.com/show_bug.cgi?id=531895 This approach requires the package to work with both python 2 and 3, which requires both an upstream maintainer and a downstream Fedora packager that care about both 2 and 3, working from a single source tree. For supporting both 2 and 3 with a single built RPM (or something involving symlinked .py files?) I don't think that's possible: we don't want to add a python3 dependency to python 2 modules, and the precompiled bytecode optimization of imports requires version-specific .pyc/.pyo files - see bug 531117 (automating this in rpmbuild) and bug 531102 (adding a test to rpmlint to verify that it got it correct). Dave [1] See: https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html and https://fedoraproject.org/wiki/Features/Python3F13 From ville.skytta at iki.fi Fri Oct 30 06:34:05 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 30 Oct 2009 08:34:05 +0200 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines In-Reply-To: <1256855704.3731.3404.camel@brick> References: <200910171333.29486.ville.skytta@iki.fi> <1255790200.20812.14.camel@brick> <1256855704.3731.3404.camel@brick> Message-ID: <200910300834.07136.ville.skytta@iki.fi> On Friday 30 October 2009, David Malcolm wrote: > Did the change to the guidelines happen, Not yet I suppose, at least it's not in https://fedoraproject.org/wiki/Packaging:Python > and did the rpmdevtools template get updated? Yes, but there's no release out with the updated one yet. http://git.fedoraproject.org/git/rpmdevtools.git/?p=rpmdevtools.git;a=commitdiff;h=7fed3b8faf69eb927b865132902a0e1f07baeef6 From a.badger at gmail.com Sat Oct 31 01:48:54 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 30 Oct 2009 18:48:54 -0700 Subject: [Fedora-packaging] Python 3 compatibility update to Python guidelines In-Reply-To: <200910171333.29486.ville.skytta@iki.fi> References: <200910171333.29486.ville.skytta@iki.fi> Message-ID: <20091031014854.GA21217@clingman.lan> On Sat, Oct 17, 2009 at 01:33:29PM +0300, Ville Skytt? wrote: > https://fedoraproject.org/wiki/Packaging:Python > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print get_python_lib()")} > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > > These no longer work with Python 3 due to "print" changes. They should be > replaced with something like these that work with both Python 2 and 3 (already > done in spectemplate-python.spec in rpmdevtools git): > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from > distutils.sysconfig import *; import sys; > sys.stdout.write(get_python_lib())")} > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from > distutils.sysconfig import *; import sys; > sys.stdout.write(get_python_lib(1))")} > Any reason not to do it this way? %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from. distutils.sysconfig import *; print (get_python_lib())")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from. distutils.sysconfig import *; print(get_python_lib(1))")} Also, dmalcolm, could we get these macros into the python and python3 (when revewied) package so we don't have to add them as boilerplate to every package? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: