From rdieter at math.unl.edu Sat Mar 1 01:28:05 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 29 Feb 2008 19:28:05 -0600
Subject: [Fedora-packaging] %bits macro?
In-Reply-To: <47C87DB6.5090006@cora.nwra.com>
References: <47C87DB6.5090006@cora.nwra.com>
Message-ID: <47C8B125.2040705@math.unl.edu>
Orion Poplawski wrote:
> It might me useful to have a %bits macro automatically set to 32 or 64
> as appropriate. Does this seem useful or is there a better way?
shrug, I usually use something like:
%define bits 32
%if "%{_lib}" == "lib64"
%define bits 64
%endif
From katzj at redhat.com Sat Mar 1 01:31:46 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 29 Feb 2008 20:31:46 -0500
Subject: [Fedora-packaging] %bits macro?
In-Reply-To: <47C8B125.2040705@math.unl.edu>
References: <47C87DB6.5090006@cora.nwra.com> <47C8B125.2040705@math.unl.edu>
Message-ID: <1204335106.10483.2.camel@aglarond.local>
On Fri, 2008-02-29 at 19:28 -0600, Rex Dieter wrote:
> Orion Poplawski wrote:
> > It might me useful to have a %bits macro automatically set to 32 or 64
> > as appropriate. Does this seem useful or is there a better way?
>
> shrug, I usually use something like:
> %define bits 32
> %if "%{_lib}" == "lib64"
> %define bits 64
> %endif
That doesn't cover all the cases -- neither alpha nor ia64 use lib64
Jeremy
From rdieter at math.unl.edu Sat Mar 1 01:59:40 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 29 Feb 2008 19:59:40 -0600
Subject: [Fedora-packaging] %bits macro?
In-Reply-To: <1204335106.10483.2.camel@aglarond.local>
References: <47C87DB6.5090006@cora.nwra.com> <47C8B125.2040705@math.unl.edu>
<1204335106.10483.2.camel@aglarond.local>
Message-ID: <47C8B88C.9060504@math.unl.edu>
Jeremy Katz wrote:
> On Fri, 2008-02-29 at 19:28 -0600, Rex Dieter wrote:
>> Orion Poplawski wrote:
>>> It might me useful to have a %bits macro automatically set to 32 or 64
>>> as appropriate. Does this seem useful or is there a better way?
>> shrug, I usually use something like:
>> %define bits 32
>> %if "%{_lib}" == "lib64"
>> %define bits 64
>> %endif
>
> That doesn't cover all the cases -- neither alpha nor ia64 use lib64
Joy. I assume lib64 is only used when multilib is required then?
-- Rex
From katzj at redhat.com Sat Mar 1 02:01:13 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 29 Feb 2008 21:01:13 -0500
Subject: [Fedora-packaging] %bits macro?
In-Reply-To: <47C8B88C.9060504@math.unl.edu>
References: <47C87DB6.5090006@cora.nwra.com> <47C8B125.2040705@math.unl.edu>
<1204335106.10483.2.camel@aglarond.local>
<47C8B88C.9060504@math.unl.edu>
Message-ID: <1204336873.10483.15.camel@aglarond.local>
On Fri, 2008-02-29 at 19:59 -0600, Rex Dieter wrote:
> Jeremy Katz wrote:
> > On Fri, 2008-02-29 at 19:28 -0600, Rex Dieter wrote:
> >> Orion Poplawski wrote:
> >>> It might me useful to have a %bits macro automatically set to 32 or 64
> >>> as appropriate. Does this seem useful or is there a better way?
> >> shrug, I usually use something like:
> >> %define bits 32
> >> %if "%{_lib}" == "lib64"
> >> %define bits 64
> >> %endif
> >
> > That doesn't cover all the cases -- neither alpha nor ia64 use lib64
>
> Joy. I assume lib64 is only used when multilib is required then?
Yes[1]
Jeremy
[1] Ignoring the absolute atrocity that is the x86 on ia64 stuff. Which
really... too disgusting for words
From notting at redhat.com Sat Mar 1 02:03:11 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 29 Feb 2008 21:03:11 -0500
Subject: [Fedora-packaging] %bits macro?
In-Reply-To: <47C8B88C.9060504@math.unl.edu>
References: <47C87DB6.5090006@cora.nwra.com> <47C8B125.2040705@math.unl.edu>
<1204335106.10483.2.camel@aglarond.local>
<47C8B88C.9060504@math.unl.edu>
Message-ID: <20080301020311.GE18154@nostromo.devel.redhat.com>
Rex Dieter (rdieter at math.unl.edu) said:
>> That doesn't cover all the cases -- neither alpha nor ia64 use lib64
>
> Joy. I assume lib64 is only used when multilib is required then?
More or less, yes.
Bill
From rc040203 at freenet.de Sat Mar 1 06:01:12 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 01 Mar 2008 07:01:12 +0100
Subject: [Fedora-packaging] %bits macro?
In-Reply-To: <1204323274.8099.110.camel@cutter>
References: <47C87DB6.5090006@cora.nwra.com>
<1204321850.4065.22.camel@localhost.localdomain>
<1204322560.3446.396.camel@beck.corsepiu.local>
<1204323274.8099.110.camel@cutter>
Message-ID: <1204351272.3446.400.camel@beck.corsepiu.local>
On Fri, 2008-02-29 at 17:14 -0500, seth vidal wrote:
> On Fri, 2008-02-29 at 23:02 +0100, Ralf Corsepius wrote:
> > On Fri, 2008-02-29 at 16:50 -0500, Tom "spot" Callaway wrote:
> > > On Fri, 2008-02-29 at 14:48 -0700, Orion Poplawski wrote:
> > > > It might me useful to have a %bits macro automatically set to 32 or 64
> > > > as appropriate. Does this seem useful or is there a better way?
> > >
> > > I'm not aware of a better way, this would be quite useful IMHO.
> >
> > A better way would be to rewrite any code requiring such tricks to not
> > require them.
> >
> > In modern C/C++ there hardly is any need for such band-aids (cf.
> > stdint.h, inttypes.h, limits.h)
>
> But this would be handy if we can use it during the build.
>
> We could do little tricks like:
>
> Requires: foo.%bits
> Provides: foo.%bits
>
> and it would let us get rid of multilib file-requires like:
>
> /usr/lib[64]/libgcj.so.9
Why would this be helpful?
All you do this way, is to replace one "natural/direct"
"Requires/Provides" with another, "artificial/indirect"" one.
I don't see how this would be helpful.
Ralf
From eric.tanguy at univ-nantes.fr Sat Mar 1 09:07:22 2008
From: eric.tanguy at univ-nantes.fr (Tanguy Eric)
Date: Sat, 01 Mar 2008 10:07:22 +0100
Subject: [Fedora-packaging] how to handle mimetype
Message-ID: <1204362442.3184.9.camel@bureau.maison>
I'm trying to package scidavis http://scidavis.sourceforge.net/ and i
would like the files generated by it (*.sciprj and *.sciprj.gz) will be
associated to scidavis and opened in it when i double-click on their.
So i put a desktop file in /usr/share/applications :
[Desktop Entry]
Encoding=UTF-8
Name=SciDAVis
Comment=Scientific Data Analysis and Visualization
Comment[de]=Visualisierungs- und Datenanalyseprogramm
Comment[fr]=Outil d'analyse scientifique de donn?es
Icon=scidavis
Exec=scidavis %f
Terminal=0
Type=Application
Categories=Science;Graphics;X-Fedora;
MimeType=application/x-scidavis
X-Desktop-File-Install-Version=0.13
and a xml file in /usr/share/mime/packages :
Scidavis project
Scidavis project
after this i run
update-mime-database /usr/share/mime
update-desktop-database
but the problem is that when i create a sciprj file using scidavis the
mime-type associated in nautilus is text/html
Someone could help me to clarify this ?
Thanks
Eric
From dominik at greysector.net Sat Mar 1 12:22:03 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 1 Mar 2008 13:22:03 +0100
Subject: [Fedora-packaging] %bits macro?
In-Reply-To: <1204323274.8099.110.camel@cutter>
References: <47C87DB6.5090006@cora.nwra.com>
<1204321850.4065.22.camel@localhost.localdomain>
<1204322560.3446.396.camel@beck.corsepiu.local>
<1204323274.8099.110.camel@cutter>
Message-ID: <20080301122203.GB2959@ryvius.greysector.net>
On Friday, 29 February 2008 at 23:14, seth vidal wrote:
>
> On Fri, 2008-02-29 at 23:02 +0100, Ralf Corsepius wrote:
> > On Fri, 2008-02-29 at 16:50 -0500, Tom "spot" Callaway wrote:
> > > On Fri, 2008-02-29 at 14:48 -0700, Orion Poplawski wrote:
> > > > It might me useful to have a %bits macro automatically set to 32 or 64
> > > > as appropriate. Does this seem useful or is there a better way?
> > >
> > > I'm not aware of a better way, this would be quite useful IMHO.
> >
> > A better way would be to rewrite any code requiring such tricks to not
> > require them.
> >
> > In modern C/C++ there hardly is any need for such band-aids (cf.
> > stdint.h, inttypes.h, limits.h)
>
> But this would be handy if we can use it during the build.
>
> We could do little tricks like:
>
> Requires: foo.%bits
> Provides: foo.%bits
Well, you can do that even now:
Provides: foo(%_target_cpu)
Requires: foo(%_target_cpu)
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
From rjones at redhat.com Sat Mar 1 15:05:48 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Mar 2008 15:05:48 +0000
Subject: [Fedora-packaging] New draft packaging guidelines for OCaml
Message-ID: <20080301150548.GA10317@amd.home.annexia.org>
I've started a page for updating the packaging guidelines.
https://fedoraproject.org/wiki/PackagingDrafts/OCaml
At the moment it's a straight copy of the packaging guidelines except
that I've updated 'ocaml-foolib.spec' from my private copy of that
file.
Some ideas:
- how useful is the whole '%opt' stuff now that we have native
compilation on every Fedora architecture?
- use of chrpath and strip
- should we finally distribute ocaml-find-requires/provides with
upstream RPM? They haven't changed in a long time.
- note about some common rpmlint errors:
https://bugzilla.redhat.com/show_bug.cgi?id=433783
- ISO-8859-1 - should we ban it from *.ml & *.mli files?
https://bugzilla.redhat.com/show_bug.cgi?id=434694
- camlp4/camlp5 syntax extensions are a bit different from a
distribution point of view. They usually don't need a -devel
package, and they require *.cmo files to be distributed.
And sometimes they should be noarch.
https://bugzilla.redhat.com/show_bug.cgi?id=435431
https://bugzilla.redhat.com/show_bug.cgi?id=435299
https://bugzilla.redhat.com/show_bug.cgi?id=435293
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From rjones at redhat.com Sat Mar 1 15:38:11 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Mar 2008 15:38:11 +0000
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080301150548.GA10317@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
Message-ID: <20080301153811.GA10706@amd.home.annexia.org>
On Sat, Mar 01, 2008 at 03:05:48PM +0000, Richard W.M. Jones wrote:
> I've started a page for updating the packaging guidelines.
>
> https://fedoraproject.org/wiki/PackagingDrafts/OCaml
>
> At the moment it's a straight copy of the packaging guidelines except
> that I've updated 'ocaml-foolib.spec' from my private copy of that
> file.
>
> Some ideas:
>
> - how useful is the whole '%opt' stuff now that we have native
> compilation on every Fedora architecture?
>
> - use of chrpath and strip
>
> - should we finally distribute ocaml-find-requires/provides with
> upstream RPM? They haven't changed in a long time.
>
> - note about some common rpmlint errors:
> https://bugzilla.redhat.com/show_bug.cgi?id=433783
>
> - ISO-8859-1 - should we ban it from *.ml & *.mli files?
> https://bugzilla.redhat.com/show_bug.cgi?id=434694
>
> - camlp4/camlp5 syntax extensions are a bit different from a
> distribution point of view. They usually don't need a -devel
> package, and they require *.cmo files to be distributed.
> And sometimes they should be noarch.
> https://bugzilla.redhat.com/show_bug.cgi?id=435431
> https://bugzilla.redhat.com/show_bug.cgi?id=435299
> https://bugzilla.redhat.com/show_bug.cgi?id=435293
And while I remember:
- ocaml-pcre-devel pulls in ocaml-pcre and pcre.
However it doesn't pull in pcre-devel, so you cannot actually
'devel'op software with this package: programs will fail to link
because of missing -lpcre. This may be a general problem with
all our packages which use C libs, although for some reason
I've only hit it with this one.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From j.w.r.degoede at hhs.nl Sat Mar 1 15:48:02 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 01 Mar 2008 16:48:02 +0100
Subject: [Fedora-packaging] New draft packaging guidelines for OCaml
In-Reply-To: <20080301150548.GA10317@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
Message-ID: <47C97AB2.2080108@hhs.nl>
Richard W.M. Jones wrote:
> I've started a page for updating the packaging guidelines.
>
> https://fedoraproject.org/wiki/PackagingDrafts/OCaml
>
> At the moment it's a straight copy of the packaging guidelines except
> that I've updated 'ocaml-foolib.spec' from my private copy of that
> file.
>
> Some ideas:
>
> - how useful is the whole '%opt' stuff now that we have native
> compilation on every Fedora architecture?
>
Keep in mind that people are working hard to get secondary arches of the
ground, so I vote to keep it in.
> - use of chrpath and strip
>
I don't see this anywhere in:
https://fedoraproject.org/wiki/PackagingDrafts/OCaml
Explain?
> - should we finally distribute ocaml-find-requires/provides with
> upstream RPM? They haven't changed in a long time.
>
+1
> - note about some common rpmlint errors:
> https://bugzilla.redhat.com/show_bug.cgi?id=433783
>
Good work on trying to get rpmlint ocaml aware, but how is this relevant for
the guidelines, other then maybe adding a section about which warnings may be
ignored
> - ISO-8859-1 - should we ban it from *.ml & *.mli files?
> https://bugzilla.redhat.com/show_bug.cgi?id=434694
>
I wouldn't do that if the language explicitly allows using non ascii codes in
identifiers, and also dictates use of a certain codepage for this, then we
should respect this.
> - camlp4/camlp5 syntax extensions are a bit different from a
> distribution point of view. They usually don't need a -devel
> package, and they require *.cmo files to be distributed.
> And sometimes they should be noarch.
> https://bugzilla.redhat.com/show_bug.cgi?id=435431
Erm I don't see any .cmo files in the filelist for this one?
Regards,
Hans
From rjones at redhat.com Sat Mar 1 15:49:59 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Mar 2008 15:49:59 +0000
Subject: [Fedora-packaging] New draft packaging guidelines for OCaml
In-Reply-To: <47C97AB2.2080108@hhs.nl>
References: <20080301150548.GA10317@amd.home.annexia.org>
<47C97AB2.2080108@hhs.nl>
Message-ID: <20080301154959.GA10783@amd.home.annexia.org>
On Sat, Mar 01, 2008 at 04:48:02PM +0100, Hans de Goede wrote:
> I don't see this anywhere in:
> https://fedoraproject.org/wiki/PackagingDrafts/OCaml
>
> Explain?
Sorry, I should have been clearer: these are problems I've identified.
I haven't edited the page yet :-)
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From rjones at redhat.com Sat Mar 1 15:58:15 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Mar 2008 15:58:15 +0000
Subject: [Fedora-packaging] New draft packaging guidelines for OCaml
In-Reply-To: <47C97AB2.2080108@hhs.nl>
References: <20080301150548.GA10317@amd.home.annexia.org>
<47C97AB2.2080108@hhs.nl>
Message-ID: <20080301155815.GB10783@amd.home.annexia.org>
On Sat, Mar 01, 2008 at 04:48:02PM +0100, Hans de Goede wrote:
> Richard W.M. Jones wrote:
>> - camlp4/camlp5 syntax extensions are a bit different from a
>> distribution point of view. They usually don't need a -devel
>> package, and they require *.cmo files to be distributed.
>> And sometimes they should be noarch.
>> https://bugzilla.redhat.com/show_bug.cgi?id=435431
>
> Erm I don't see any .cmo files in the filelist for this one?
This one is a bit different from the other two syntax extensions.
He's building a standalone preprocessor (/usr/bin/deriving) using an
undocumented[1] feature of camlp4. I don't know if this is just his
personal preference or if there's some reason behind it.
Most camlp4 & camlp5 extensions are distributed as '*.cmo' files,
usually 'pa_*.cmo' where 'pa' stands for parser, and they get
dynamically loaded into the rest of camlp4 at runtime.
Rich.
[1] http://stuff.mit.edu/afs/sipb/project/ocaml/src/current/camlp4/Camlp4Bin.ml
Well, all of the new camlp4 is undocumented, just this one even less.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From richardfearn at gmail.com Sat Mar 1 16:44:26 2008
From: richardfearn at gmail.com (Richard Fearn)
Date: Sat, 1 Mar 2008 16:44:26 +0000
Subject: [Fedora-packaging] Packaging ncdu for Fedora
Message-ID: <212718d80803010844h46f75159u37876320238009a1@mail.gmail.com>
Hello,
I'm considering packaging ncdu[1] for Fedora. It uses the MIT licence,
which according to the Fedora licensing page[2] is a 'good' licence.
It required ncurses-devel for compilation.
Before I get started, is anyone aware of any issues with packaging
this software? Has it been rejected in the past?
Thanks
Richard Fearn
[1] http://dev.yorhel.nl/ncdu/
[2] http://fedoraproject.org/wiki/Licensing
From tcallawa at redhat.com Sat Mar 1 16:59:19 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sat, 01 Mar 2008 11:59:19 -0500
Subject: [Fedora-packaging] Packaging ncdu for Fedora
In-Reply-To: <212718d80803010844h46f75159u37876320238009a1@mail.gmail.com>
References: <212718d80803010844h46f75159u37876320238009a1@mail.gmail.com>
Message-ID: <1204390759.3729.2.camel@localhost.localdomain>
On Sat, 2008-03-01 at 16:44 +0000, Richard Fearn wrote:
> Hello,
>
> I'm considering packaging ncdu[1] for Fedora. It uses the MIT licence,
> which according to the Fedora licensing page[2] is a 'good' licence.
> It required ncurses-devel for compilation.
>
> Before I get started, is anyone aware of any issues with packaging
> this software? Has it been rejected in the past?
I'm not aware of any issues with it, nor has it been rejected in the
past.
~spot
From rjones at redhat.com Sat Mar 1 17:01:08 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Mar 2008 17:01:08 +0000
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080301153811.GA10706@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
Message-ID: <20080301170108.GA11487@amd.home.annexia.org>
On Sat, Mar 01, 2008 at 03:38:11PM +0000, Richard W.M. Jones wrote:
> On Sat, Mar 01, 2008 at 03:05:48PM +0000, Richard W.M. Jones wrote:
> > I've started a page for updating the packaging guidelines.
> >
> > https://fedoraproject.org/wiki/PackagingDrafts/OCaml
> >
> > At the moment it's a straight copy of the packaging guidelines except
> > that I've updated 'ocaml-foolib.spec' from my private copy of that
> > file.
> >
> > Some ideas:
> >
> > - how useful is the whole '%opt' stuff now that we have native
> > compilation on every Fedora architecture?
> >
> > - use of chrpath and strip
> >
> > - should we finally distribute ocaml-find-requires/provides with
> > upstream RPM? They haven't changed in a long time.
> >
> > - note about some common rpmlint errors:
> > https://bugzilla.redhat.com/show_bug.cgi?id=433783
> >
> > - ISO-8859-1 - should we ban it from *.ml & *.mli files?
> > https://bugzilla.redhat.com/show_bug.cgi?id=434694
> >
> > - camlp4/camlp5 syntax extensions are a bit different from a
> > distribution point of view. They usually don't need a -devel
> > package, and they require *.cmo files to be distributed.
> > And sometimes they should be noarch.
> > https://bugzilla.redhat.com/show_bug.cgi?id=435431
> > https://bugzilla.redhat.com/show_bug.cgi?id=435299
> > https://bugzilla.redhat.com/show_bug.cgi?id=435293
>
> And while I remember:
>
> - ocaml-pcre-devel pulls in ocaml-pcre and pcre.
> However it doesn't pull in pcre-devel, so you cannot actually
> 'devel'op software with this package: programs will fail to link
> because of missing -lpcre. This may be a general problem with
> all our packages which use C libs, although for some reason
> I've only hit it with this one.
And:
- certain binaries should not be stripped
https://bugzilla.redhat.com/show_bug.cgi?id=435559
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From eric.tanguy at univ-nantes.fr Sat Mar 1 19:16:49 2008
From: eric.tanguy at univ-nantes.fr (Tanguy Eric)
Date: Sat, 01 Mar 2008 20:16:49 +0100
Subject: [Fedora-packaging] how to handle mimetype
In-Reply-To: <1204362442.3184.9.camel@bureau.maison>
References: <1204362442.3184.9.camel@bureau.maison>
Message-ID: <1204399009.6432.2.camel@bureau.maison>
Le samedi 01 mars 2008 ? 10:07 +0100, Tanguy Eric a ?crit :
> I'm trying to package scidavis http://scidavis.sourceforge.net/ and i
> would like the files generated by it (*.sciprj and *.sciprj.gz) will be
> associated to scidavis and opened in it when i double-click on their.
>
> So i put a desktop file in /usr/share/applications :
> [Desktop Entry]
> Encoding=UTF-8
> Name=SciDAVis
> Comment=Scientific Data Analysis and Visualization
> Comment[de]=Visualisierungs- und Datenanalyseprogramm
> Comment[fr]=Outil d'analyse scientifique de donn?es
> Icon=scidavis
> Exec=scidavis %f
> Terminal=0
> Type=Application
> Categories=Science;Graphics;X-Fedora;
> MimeType=application/x-scidavis
> X-Desktop-File-Install-Version=0.13
>
> and a xml file in /usr/share/mime/packages :
>
> xmlns="http://www.freedesktop.org/standards/shared-mime-info">
>
> Scidavis project
>
>
>
>
> Scidavis project
>
>
>
>
> after this i run
> update-mime-database /usr/share/mime
> update-desktop-database
>
> but the problem is that when i create a sciprj file using scidavis the
> mime-type associated in nautilus is text/html
>
> Someone could help me to clarify this ?
>
> Thanks
>
> Eric
>
>
Modifying /usr/share/mime/packages/scidavis.xml like this :
Scidavis project
Projet Scidavis
works except that i would like to associate an icon to this type of file and i don't achieve it.
Any more help ?
Thanks
Eric
From dominik at greysector.net Sat Mar 1 21:47:23 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 1 Mar 2008 22:47:23 +0100
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080301170108.GA11487@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
Message-ID: <20080301214722.GE2959@ryvius.greysector.net>
On Saturday, 01 March 2008 at 18:01, Richard W.M. Jones wrote:
[...]
> And:
>
> - certain binaries should not be stripped
> https://bugzilla.redhat.com/show_bug.cgi?id=435559
I assume that using ocamlc -custom is absolutely necessary there.
My guess is this is either a bug in strip (stripping what it shouldn't)
or in ocamlc (generating invalid ELF objects).
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
From rjones at redhat.com Sat Mar 1 21:59:53 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Mar 2008 21:59:53 +0000
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080301214722.GE2959@ryvius.greysector.net>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080301214722.GE2959@ryvius.greysector.net>
Message-ID: <20080301215953.GA13403@amd.home.annexia.org>
On Sat, Mar 01, 2008 at 10:47:23PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Saturday, 01 March 2008 at 18:01, Richard W.M. Jones wrote:
> [...]
> > And:
> >
> > - certain binaries should not be stripped
> > https://bugzilla.redhat.com/show_bug.cgi?id=435559
>
> I assume that using ocamlc -custom is absolutely necessary there.
> My guess is this is either a bug in strip (stripping what it shouldn't)
> or in ocamlc (generating invalid ELF objects).
It's kind of a gross bug in ocamlc. It appends the bytecode to the
end of the executable and writes a trailer after that, and at runtime
it reads its own bytecode from /proc/self/exe.
Yuck!
Luckily it only does this with the -custom option, and it turns out
that such binaries are quite rare. I only found a problem in 2 out of
68 OCaml-built binaries that we ship in Fedora.
There's some background and commentary from upstream in the Debian
bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900
Anyhow we ought to ship native code versions of everything we possibly
can. It's silly shipping slow old bytecode when you've got a native
code compiler that's almost as fast as C. Maybe this should be
another packaging guideline?
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From dominik at greysector.net Sat Mar 1 22:28:05 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 1 Mar 2008 23:28:05 +0100
Subject: [Fedora-packaging] Packaging truecrypt for Fedora (licencing
question)
Message-ID: <20080301222805.GF2959@ryvius.greysector.net>
I have the package here:
Spec URL: http://rathann.fedorapeople.org/review/truecrypt.spec
SRPM URL: http://rathann.fedorapeople.org/review/truecrypt-5.0a-1.src.rpm
but the licence is a bit of a mess. It's a collection of licences, including:
* TrueCrypt Licence Version 2.4: doesn't allow distributing patched versions
and calling them TrueCrypt. Otherwise it's similar to BSD with advertising
clause.
* Licence agreement for Encryption for the Masses: similar to the above
* SSLeay licence
* some BSD licence (alternatively GPL)
* some attribution only licence
* another BSD-like licence
Is this acceptable for Fedora?
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
From fedora at leemhuis.info Sun Mar 2 12:53:58 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 02 Mar 2008 13:53:58 +0100
Subject: [Fedora-packaging] packaging ramspeed,
which uses the "The Alasir Licence" (TAL)
Message-ID: <47CAA366.70804@leemhuis.info>
Hi Spot, all
I was wondering if I should package ramspeed,
http://www.alasir.com/software/ramspeed/
for Fedora. But It uses a odd license -- "The Alasir Licence" (TAL)
http://www.alasir.com/licence/TAL.txt
I couldn't find it on
http://fedoraproject.org/wiki/Licensing#SoftwareLicenses
See below for the text. What do you guys think, is it acceptable for Fedora?
Is the "the software (the whole or a part of it) is prohibited from being sold or
leased in any form or manner with the only possible exceptions: [...]" part a
problem?
Cu
knurd
---
The Alasir Licence
This is a free software. It's provided as-is and carries absolutely no
warranty or responsibility by the author and the contributors, neither in
general nor in particular. No matter if this software is able or unable to
cause any damage to your or third party's computer hardware, software, or any
other asset available, neither the author nor a separate contributor may be
found liable for any harm or its consequences resulting from either proper or
improper use of the software, even if advised of the possibility of certain
injury as such and so forth.
The software isn't a public domain, it's a copyrighted one. In no event
shall the author's or a separate contributor's copyright be denied or violated
otherwise. No copyright may be removed unless together with the code
contributed to the software by a holder of the respective copyright. A
copyright itself indicates the rights of ownership over the code contributed.
Back and forth, the author is defined as the one who holds the oldest
copyright over the software. Furthermore, the software is defined as either
source or binary computer code, which is organised in the form of a single
computer file usually.
The software (the whole or a part of it) is prohibited from being sold or
leased in any form or manner with the only possible exceptions:
a) money may be charged for a physical medium used to transfer the software;
b) money may be charged for optional warranty or support services related to
the software.
Nevertheless, if the software (the whole or a part of it) is desired to
become an object of sale or lease (the whole or a part of it), then a separate
non-exclusive licence agreement must be negotiated from the author. Benefits
accrued should be distributed between the contributors or likewise at the
author's option.
Whenever and wherever the software is distributed, in either source or
binary form, either in whole or in part, it must include the complete
unchanged text of this licence agreement unless different conditions have been
negotiated. In case of a binary-only distribution, the names of the copyright
holders must be mentioned in the documentation supplied with the software.
This is supposed to protect rights and freedom of those who have contributed
their time and labour to free software development, because otherwise the
development itself and this licence agreement are of a very little sense.
Nothing else but this licence agreement grants you rights to use, modify
and distribute the software. Any violation of this licence agreement is
recognised as an action prohibited by an applicable legislation.
From rdieter at math.unl.edu Sun Mar 2 14:26:21 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 02 Mar 2008 08:26:21 -0600
Subject: [Fedora-packaging] packaging ramspeed, which uses the "The Alasir
Licence" (TAL)
In-Reply-To: <47CAA366.70804@leemhuis.info>
References: <47CAA366.70804@leemhuis.info>
Message-ID: <47CAB90D.3080000@math.unl.edu>
Thorsten Leemhuis wrote:
> for Fedora. But It uses a odd license -- "The Alasir Licence" (TAL)
> http://www.alasir.com/licence/TAL.txt
> I couldn't find it on
> http://fedoraproject.org/wiki/Licensing#SoftwareLicenses
>
> See below for the text. What do you guys think, is it acceptable for Fedora?
> Is the "the software (the whole or a part of it) is prohibited from being sold or
> leased in any form or manner with the only possible exceptions: [...]" part a
> problem?
Imo, that clause is a deal-breaker for fedora.
-- Rex
From tibbs at math.uh.edu Sun Mar 2 22:35:39 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 02 Mar 2008 16:35:39 -0600
Subject: [Fedora-packaging] Requires(missingok)
Message-ID:
I saw a review ticket for a package which uses Requires(missingok):
which I have not seen before. Some searching turned up the kismet and
python-docutils which currently use this idiom.
What is this actually supposed to do? I can understand what
Requires(hint) might do, but Requires(missingok) sounds more like it
wouldn't actually do anything if the dependency is not present, which
would make me wonder as to the point of having it at all.
Do we want Requires(missingok) in Fedora packages?
- J<
From skvidal at fedoraproject.org Sun Mar 2 23:34:28 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sun, 02 Mar 2008 18:34:28 -0500
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To:
References:
Message-ID: <1204500868.326.4.camel@cutter>
On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
> I saw a review ticket for a package which uses Requires(missingok):
> which I have not seen before. Some searching turned up the kismet and
> python-docutils which currently use this idiom.
>
> What is this actually supposed to do? I can understand what
> Requires(hint) might do, but Requires(missingok) sounds more like it
> wouldn't actually do anything if the dependency is not present, which
> would make me wonder as to the point of having it at all.
>
> Do we want Requires(missingok) in Fedora packages?
>
no - at least for yum it is not supported.
-sv
From j.w.r.degoede at hhs.nl Mon Mar 3 08:28:41 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 03 Mar 2008 09:28:41 +0100
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <1204500868.326.4.camel@cutter>
References:
<1204500868.326.4.camel@cutter>
Message-ID: <47CBB6B9.10106@hhs.nl>
seth vidal wrote:
> On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
>> I saw a review ticket for a package which uses Requires(missingok):
>> which I have not seen before. Some searching turned up the kismet and
>> python-docutils which currently use this idiom.
>>
>> What is this actually supposed to do? I can understand what
>> Requires(hint) might do, but Requires(missingok) sounds more like it
>> wouldn't actually do anything if the dependency is not present, which
>> would make me wonder as to the point of having it at all.
>>
>> Do we want Requires(missingok) in Fedora packages?
>>
>
> no - at least for yum it is not supported.
>
Is there any way of softdependencies supported by yum? Is this planned for the
the future, for plugin basd apps it would be nice to be able to hint to the end
user that certain optional plugins (with perhaps some hefty deps) would be good
to install, then in beginning user mode (== default) yum could treat these as
harddeps, and more advanced users could reconfigure the behavior to for example
ask the user, or just not install soft-deps.
Regards,
Hans
From pmatilai at laiskiainen.org Mon Mar 3 08:44:15 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 3 Mar 2008 10:44:15 +0200 (EET)
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <1204500868.326.4.camel@cutter>
References:
<1204500868.326.4.camel@cutter>
Message-ID:
>
> On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
>> I saw a review ticket for a package which uses Requires(missingok):
>> which I have not seen before. Some searching turned up the kismet and
>> python-docutils which currently use this idiom.
>>
>> What is this actually supposed to do? I can understand what
>> Requires(hint) might do, but Requires(missingok) sounds more like it
>> wouldn't actually do anything if the dependency is not present, which
>> would make me wonder as to the point of having it at all.
>>
>> Do we want Requires(missingok) in Fedora packages?
>>
>
> no - at least for yum it is not supported.
Rpm doesn't support that either as of 4.4.2.x, but the parsing of
Requires(foo) attributes is somewhat broken so it doesn't report the error
as such in all cases (yes, it's a bug of course).
Requires(missingok) means just as much to rpm 4.4.2.x as
Requires(arbitraryjunk)
- Panu -
From j.w.r.degoede at hhs.nl Mon Mar 3 08:40:06 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 03 Mar 2008 09:40:06 +0100
Subject: [Fedora-packaging] Blocking reviews on to be written guidelines?
Message-ID: <47CBB966.2040705@hhs.nl>
Hi All,
Yesterday I wrote a mail to the devel list asking to swap some reviews. One of
the persons who responded is Konrad Meyer. The 2 packages he wants me to review
in return are both java packages.
His message got a reply from Lubomir Kundrak, stating that he has a couple fo
java packages under review too, which are currently blocked on F-GUIDELINES,
because the java packaging guidelines are not finished.
I find this somewhat strange and leading to chicken and eggs problems. I find
the current situation with ocaml where with the initial pakage submissions some
draft guidelines (which I helped write a little) were written and then used
during review, moving forward with a best foot forward concept.
I find blocking packages waiting for guidelines counter productive, both in
general and esp. because often first more experience is needed to write
definitive guidelines.
The only important guideline to get right from the start is the naming rules,
as to avoid lots of renames later, which we did with ocaml.
So do we really want package reviews to be stalled waiting for guidelines
issues other then legal ones (which ofcourse must stall until resolved) ?
Esp, with java packages I find this strange as we already have lots of java
packages in the distro, giving plenty example how we currently do java things,
and this seems to work well.
Regards,
Hans
From nicolas.mailhot at laposte.net Mon Mar 3 09:06:26 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 3 Mar 2008 10:06:26 +0100 (CET)
Subject: [Fedora-packaging] Blocking reviews on to be written guidelines?
In-Reply-To: <47CBB966.2040705@hhs.nl>
References: <47CBB966.2040705@hhs.nl>
Message-ID: <23059.192.54.193.59.1204535186.squirrel@rousalka.dyndns.org>
Le Lun 3 mars 2008 09:40, Hans de Goede a ?crit :
> Esp, with java packages I find this strange as we already have lots of
> java
> packages in the distro, giving plenty example how we currently do java
> things, and this seems to work well.
The 'problem' with java packages is that the packaging guidelines have
largely been defined outside Fedora (since part of the platform was
historicaly closed), and there's been a drive to rewrite history and
start from scratch instead of trying to work with the original third
party repository to update those rules (if needed).
Given that those rules were written by a very small number of persons
in a short time, on the usual FLOSS rule of "those who do the work
call the shots", I find it very strange to see all this negative
activity, when all it would take to get the third party repository to
evolve (again, if there is a technical need) would be to discuss the
technical problems on its list and propose eventual Fedora-friendly
solutions there. (also this third party has some cause to be angered
since some trivial problems introduced Fedora-side have been simering
for a long time).
Or else admit there is not problem and agree the current de facto
rules are fine.
--
Nicolas Mailhot
From rjones at redhat.com Mon Mar 3 10:57:34 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 3 Mar 2008 10:57:34 +0000
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <47CBB6B9.10106@hhs.nl>
References:
<1204500868.326.4.camel@cutter> <47CBB6B9.10106@hhs.nl>
Message-ID: <20080303105734.GA21964@amd.home.annexia.org>
On Mon, Mar 03, 2008 at 09:28:41AM +0100, Hans de Goede wrote:
> seth vidal wrote:
>> On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
>>> I saw a review ticket for a package which uses Requires(missingok):
>>> which I have not seen before. Some searching turned up the kismet and
>>> python-docutils which currently use this idiom.
>>>
>>> What is this actually supposed to do? I can understand what
>>> Requires(hint) might do, but Requires(missingok) sounds more like it
>>> wouldn't actually do anything if the dependency is not present, which
>>> would make me wonder as to the point of having it at all.
>>>
>>> Do we want Requires(missingok) in Fedora packages?
>>>
>>
>> no - at least for yum it is not supported.
>>
>
> Is there any way of softdependencies supported by yum? Is this planned for
> the the future, for plugin basd apps it would be nice to be able to hint to
> the end user that certain optional plugins (with perhaps some hefty deps)
> would be good to install, then in beginning user mode (== default) yum
> could treat these as harddeps, and more advanced users could reconfigure
> the behavior to for example ask the user, or just not install soft-deps.
Worth comparing what Debian do:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From anyremote at mail.ru Mon Mar 3 11:58:35 2008
From: anyremote at mail.ru (Mike F)
Date: Mon, 03 Mar 2008 14:58:35 +0300
Subject: [Fedora-packaging] Packaging J2ME java midlets for Fedora. Is it
possible ?
Message-ID:
Hi all
I was wondering if I should package J2ME java midlet for Fedora.
In general, J2ME midlets is java software which should be uploaded to cell phone to work.
Instead of ordinary J2SE java software J2ME midlet can not be compiled with IcedTea of Sun JDK only.
It need to installSun WTK or toolkits from other vendors (Nikia, Motorola...) in addition to do that.
These toolkits are free downloadable, but are not open source.
So, is it ever possible to package J2ME midlet for Fedora ?
Thanks
Mikhail
From nicolas.mailhot at laposte.net Mon Mar 3 12:04:33 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 3 Mar 2008 13:04:33 +0100 (CET)
Subject: [Fedora-packaging] Packaging J2ME java midlets for Fedora. Is
it possible ?
In-Reply-To:
References:
Message-ID: <41160.192.54.193.59.1204545873.squirrel@rousalka.dyndns.org>
Le Lun 3 mars 2008 12:58, Mike F a ?crit :
> So, is it ever possible to package J2ME midlet for Fedora ?
If your stack is not 100% FLOSS you need to incubate at JPackage (or
any other third-party repo) till legal problems are fixed and you can
be accepted @fedora
--
Nicolas Mailhot
From skvidal at fedoraproject.org Mon Mar 3 14:20:35 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 03 Mar 2008 09:20:35 -0500
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <47CBB6B9.10106@hhs.nl>
References:
<1204500868.326.4.camel@cutter> <47CBB6B9.10106@hhs.nl>
Message-ID: <1204554035.326.6.camel@cutter>
On Mon, 2008-03-03 at 09:28 +0100, Hans de Goede wrote:
> Is there any way of softdependencies supported by yum? Is this planned for the
> the future, for plugin basd apps it would be nice to be able to hint to the end
> user that certain optional plugins (with perhaps some hefty deps) would be good
> to install, then in beginning user mode (== default) yum could treat these as
> harddeps, and more advanced users could reconfigure the behavior to for example
> ask the user, or just not install soft-deps.
>
Since rpm doesn't support it, it doesn't really matter.
-sv
From skvidal at fedoraproject.org Mon Mar 3 14:26:10 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 03 Mar 2008 09:26:10 -0500
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <20080303105734.GA21964@amd.home.annexia.org>
References:
<1204500868.326.4.camel@cutter> <47CBB6B9.10106@hhs.nl>
<20080303105734.GA21964@amd.home.annexia.org>
Message-ID: <1204554370.326.12.camel@cutter>
On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
> > Is there any way of softdependencies supported by yum? Is this planned for
> > the the future, for plugin basd apps it would be nice to be able to hint to
> > the end user that certain optional plugins (with perhaps some hefty deps)
> > would be good to install, then in beginning user mode (== default) yum
> > could treat these as harddeps, and more advanced users could reconfigure
> > the behavior to for example ask the user, or just not install soft-deps.
>
> Worth comparing what Debian do:
>
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
>
you'll note debian doesn't specify behavior. So much in fact b/c, last
time I checked, apt just lists out suggests/recommends to the terminal
w/o doing anything with them.
Seriously - these are the hard questions to answer:
1. if foo suggests bar, baz and quux and the user is using -y in yum or
using kickstart to install do we:
a. automatically install them
b. automatically ignore them
c. something in between?
2. If foo suggest bar, baz, quux and the user has asked to remove foo
do we:
a. automatically remove them
b. automatically ignore them
c. something in between?
If we do A in both cases then they're just dependencies and should be
left that way.
If we do B then they're nothing to the user and don't matter
Now, the first question is: "But what about interactive modes, couldn't
you prompt and ask the user what to do?" The problem is installing rpms
is a non-interactive business and we have to have a sensible answer for
the non-interactive modes before anything else. Moreover, if we have a
sensible answer for non-interactive why would we bug the user to ask
them what to do along the way if our answer is sensible?
-sv
From rjones at redhat.com Mon Mar 3 15:04:15 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 3 Mar 2008 15:04:15 +0000
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <1204554370.326.12.camel@cutter>
References:
<1204500868.326.4.camel@cutter> <47CBB6B9.10106@hhs.nl>
<20080303105734.GA21964@amd.home.annexia.org>
<1204554370.326.12.camel@cutter>
Message-ID: <20080303150415.GA25881@amd.home.annexia.org>
On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
> On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
> > Worth comparing what Debian do:
> >
> > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
>
> you'll note debian doesn't specify behavior. So much in fact b/c, last
> time I checked, apt just lists out suggests/recommends to the terminal
> w/o doing anything with them.
Even just listing them out is (IMHO) a good thing. Sometimes on
Debian I'll see a suggestion that looks worthwhile, kill the apt-get,
and start it again with the extra package. Of course what Debian is
then missing is an explanation of what the extra package does and why
it enhances the requested package, eg:
yum install foo
foo suggests bar
bar: with this package you will be able to foo bars as well
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From skvidal at fedoraproject.org Mon Mar 3 15:08:38 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 03 Mar 2008 10:08:38 -0500
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <20080303150415.GA25881@amd.home.annexia.org>
References:
<1204500868.326.4.camel@cutter> <47CBB6B9.10106@hhs.nl>
<20080303105734.GA21964@amd.home.annexia.org>
<1204554370.326.12.camel@cutter>
<20080303150415.GA25881@amd.home.annexia.org>
Message-ID: <1204556918.326.18.camel@cutter>
On Mon, 2008-03-03 at 15:04 +0000, Richard W.M. Jones wrote:
> On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
> > On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
> > > Worth comparing what Debian do:
> > >
> > > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
> >
> > you'll note debian doesn't specify behavior. So much in fact b/c, last
> > time I checked, apt just lists out suggests/recommends to the terminal
> > w/o doing anything with them.
>
> Even just listing them out is (IMHO) a good thing. Sometimes on
> Debian I'll see a suggestion that looks worthwhile, kill the apt-get,
> and start it again with the extra package. Of course what Debian is
> then missing is an explanation of what the extra package does and why
> it enhances the requested package, eg:
>
> yum install foo
>
> foo suggests bar
> bar: with this package you will be able to foo bars as well
>
so the above does nothing for the most useful case of anaconda, then.
-sv
From tcallawa at redhat.com Mon Mar 3 15:15:02 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 03 Mar 2008 10:15:02 -0500
Subject: [Fedora-packaging] Blocking reviews on to be written guidelines?
In-Reply-To: <23059.192.54.193.59.1204535186.squirrel@rousalka.dyndns.org>
References: <47CBB966.2040705@hhs.nl>
<23059.192.54.193.59.1204535186.squirrel@rousalka.dyndns.org>
Message-ID: <1204557302.3726.4.camel@localhost.localdomain>
On Mon, 2008-03-03 at 10:06 +0100, Nicolas Mailhot wrote:
> The 'problem' with java packages is that the packaging guidelines have
> largely been defined outside Fedora (since part of the platform was
> historicaly closed), and there's been a drive to rewrite history and
> start from scratch instead of trying to work with the original third
> party repository to update those rules (if needed).
>
Really, the problem is this:
1. No one has proposed any serious Java packaging guidelines for Fedora.
If someone were to take the JPackage guidelines and propose them as the
Fedora packaging guidelines, it would be a start at least, right now,
we've got nothing.
2. The Java packages that we have currently are rather inconsistent on
how they package, and many of them are badly bitrotted for a variety of
reasons, so we can't just "keep on doing what we've been doing".
Thus, the hold. When someone presents a set of reasonable guidelines for
Java packages, we'll help knock them into shape and lift the hold. Very
few of us on the FPC have any Java experience, so we're relying on the
community with Java interest/experience to fill this void.
~spot
From tcallawa at redhat.com Mon Mar 3 15:15:58 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 03 Mar 2008 10:15:58 -0500
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <1204556918.326.18.camel@cutter>
References:
<1204500868.326.4.camel@cutter> <47CBB6B9.10106@hhs.nl>
<20080303105734.GA21964@amd.home.annexia.org>
<1204554370.326.12.camel@cutter>
<20080303150415.GA25881@amd.home.annexia.org>
<1204556918.326.18.camel@cutter>
Message-ID: <1204557358.3726.6.camel@localhost.localdomain>
On Mon, 2008-03-03 at 10:08 -0500, seth vidal wrote:
> On Mon, 2008-03-03 at 15:04 +0000, Richard W.M. Jones wrote:
> > On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
> > > On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
> > > > Worth comparing what Debian do:
> > > >
> > > > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
> > >
> > > you'll note debian doesn't specify behavior. So much in fact b/c, last
> > > time I checked, apt just lists out suggests/recommends to the terminal
> > > w/o doing anything with them.
> >
> > Even just listing them out is (IMHO) a good thing. Sometimes on
> > Debian I'll see a suggestion that looks worthwhile, kill the apt-get,
> > and start it again with the extra package. Of course what Debian is
> > then missing is an explanation of what the extra package does and why
> > it enhances the requested package, eg:
> >
> > yum install foo
> >
> > foo suggests bar
> > bar: with this package you will be able to foo bars as well
> >
>
> so the above does nothing for the most useful case of anaconda, then.
I think Anaconda will have to treat soft deps as hard deps.
~spot
From pertusus at free.fr Mon Mar 3 15:31:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 3 Mar 2008 16:31:15 +0100
Subject: [SPAM] Re: [Fedora-packaging] Blocking reviews on to be written
guidelines?
In-Reply-To: <47CBB966.2040705@hhs.nl>
References: <47CBB966.2040705@hhs.nl>
Message-ID: <20080303153115.GE2683@free.fr>
On Mon, Mar 03, 2008 at 09:40:06AM +0100, Hans de Goede wrote:
> Hi All,
>
> I find blocking packages waiting for guidelines counter productive, both in
> general and esp. because often first more experience is needed to write
> definitive guidelines.
It depends on the package. Some packagers just want to have their
package in fedora and don't care much about quality. Those kind of
submissions should be blocked before there are established guidelines.
But packages submitted by packagers willing to improve java in fedora,
and not only to have their package accepted should indeed be used to
flesh out the guidelines.
--
Pat
From tibbs at math.uh.edu Mon Mar 3 16:10:06 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 03 Mar 2008 10:10:06 -0600
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <1204557358.3726.6.camel@localhost.localdomain>
References:
<1204500868.326.4.camel@cutter> <47CBB6B9.10106@hhs.nl>
<20080303105734.GA21964@amd.home.annexia.org>
<1204554370.326.12.camel@cutter>
<20080303150415.GA25881@amd.home.annexia.org>
<1204556918.326.18.camel@cutter>
<1204557358.3726.6.camel@localhost.localdomain>
Message-ID:
>>>>> "TC" == Tom \"spot\" Callaway writes:
TC> I think Anaconda will have to treat soft deps as hard deps.
Or it (and yum) could ignore them completely and push the entire off
to some additional application which gives you the current set of
suggestions for what you have installed.
- J<
From tibbs at math.uh.edu Mon Mar 3 16:13:17 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 03 Mar 2008 10:13:17 -0600
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To:
References:
<1204500868.326.4.camel@cutter>
Message-ID:
>>>>> "PM" == Panu Matilainen writes:
PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of
PM> Requires(foo) attributes is somewhat broken so it doesn't report
PM> the error as such in all cases (yes, it's a bug of course).
What really bothers me is that we already know what Requires(post),
Requires(pre) and such mean. So going by that, Requires(hint) or
Requires(missingok) would indicate a dependency for the %hint or
%missingok scriptlets. Which, uh, they don't.
I know that rpm specfile syntax isn't clean by any stretch of the
imagination, but I can't see the motivation for taking something which
actually made sense and shovelling in a load of turds for no reason.
- J<
From skvidal at fedoraproject.org Mon Mar 3 16:16:04 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 03 Mar 2008 11:16:04 -0500
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To:
References:
<1204500868.326.4.camel@cutter>
Message-ID: <1204560964.326.28.camel@cutter>
On Mon, 2008-03-03 at 10:13 -0600, Jason L Tibbitts III wrote:
> >>>>> "PM" == Panu Matilainen writes:
>
> PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of
> PM> Requires(foo) attributes is somewhat broken so it doesn't report
> PM> the error as such in all cases (yes, it's a bug of course).
>
> What really bothers me is that we already know what Requires(post),
> Requires(pre) and such mean. So going by that, Requires(hint) or
> Requires(missingok) would indicate a dependency for the %hint or
> %missingok scriptlets. Which, uh, they don't.
>
> I know that rpm specfile syntax isn't clean by any stretch of the
> imagination, but I can't see the motivation for taking something which
> actually made sense and shovelling in a load of turds for no reason.
+!
-sv
From skvidal at fedoraproject.org Mon Mar 3 16:18:57 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 03 Mar 2008 11:18:57 -0500
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <1204560964.326.28.camel@cutter>
References:
<1204500868.326.4.camel@cutter>
<1204560964.326.28.camel@cutter>
Message-ID: <1204561137.326.30.camel@cutter>
On Mon, 2008-03-03 at 11:16 -0500, seth vidal wrote:
> On Mon, 2008-03-03 at 10:13 -0600, Jason L Tibbitts III wrote:
> > >>>>> "PM" == Panu Matilainen writes:
> >
> > PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of
> > PM> Requires(foo) attributes is somewhat broken so it doesn't report
> > PM> the error as such in all cases (yes, it's a bug of course).
> >
> > What really bothers me is that we already know what Requires(post),
> > Requires(pre) and such mean. So going by that, Requires(hint) or
> > Requires(missingok) would indicate a dependency for the %hint or
> > %missingok scriptlets. Which, uh, they don't.
> >
> > I know that rpm specfile syntax isn't clean by any stretch of the
> > imagination, but I can't see the motivation for taking something which
> > actually made sense and shovelling in a load of turds for no reason.
>
> +!
>
or +1, even. you know, without the sticky shift key :/
-sv
From rjones at redhat.com Mon Mar 3 16:53:09 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 3 Mar 2008 16:53:09 +0000
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080301170108.GA11487@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
Message-ID: <20080303165309.GA31502@amd.home.annexia.org>
On Sat, Mar 01, 2008 at 05:01:08PM +0000, Richard W.M. Jones wrote:
> On Sat, Mar 01, 2008 at 03:38:11PM +0000, Richard W.M. Jones wrote:
> > On Sat, Mar 01, 2008 at 03:05:48PM +0000, Richard W.M. Jones wrote:
> > > I've started a page for updating the packaging guidelines.
> > >
> > > https://fedoraproject.org/wiki/PackagingDrafts/OCaml
> > >
> > > At the moment it's a straight copy of the packaging guidelines except
> > > that I've updated 'ocaml-foolib.spec' from my private copy of that
> > > file.
> > >
> > > Some ideas:
> > >
> > > - how useful is the whole '%opt' stuff now that we have native
> > > compilation on every Fedora architecture?
> > >
> > > - use of chrpath and strip
> > >
> > > - should we finally distribute ocaml-find-requires/provides with
> > > upstream RPM? They haven't changed in a long time.
> > >
> > > - note about some common rpmlint errors:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=433783
> > >
> > > - ISO-8859-1 - should we ban it from *.ml & *.mli files?
> > > https://bugzilla.redhat.com/show_bug.cgi?id=434694
> > >
> > > - camlp4/camlp5 syntax extensions are a bit different from a
> > > distribution point of view. They usually don't need a -devel
> > > package, and they require *.cmo files to be distributed.
> > > And sometimes they should be noarch.
> > > https://bugzilla.redhat.com/show_bug.cgi?id=435431
> > > https://bugzilla.redhat.com/show_bug.cgi?id=435299
> > > https://bugzilla.redhat.com/show_bug.cgi?id=435293
> >
> > And while I remember:
> >
> > - ocaml-pcre-devel pulls in ocaml-pcre and pcre.
> > However it doesn't pull in pcre-devel, so you cannot actually
> > 'devel'op software with this package: programs will fail to link
> > because of missing -lpcre. This may be a general problem with
> > all our packages which use C libs, although for some reason
> > I've only hit it with this one.
>
> And:
>
> - certain binaries should not be stripped
> https://bugzilla.redhat.com/show_bug.cgi?id=435559
And:
- Clarify where documentation should go. Currently my practice has
been to put just the license file (if any) in the main package's %doc,
and the license file plus all other documentation & examples in
the devel subpackage. This duplicates (only) the license file, but
that seems acceptable since we shouldn't distribute software without
its license.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From tcallawa at redhat.com Mon Mar 3 16:57:40 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 03 Mar 2008 11:57:40 -0500
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080303165309.GA31502@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
Message-ID: <1204563460.3726.60.camel@localhost.localdomain>
On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
> - Clarify where documentation should go. Currently my practice has
> been to put just the license file (if any) in the main package's %doc,
> and the license file plus all other documentation & examples in
> the devel subpackage. This duplicates (only) the license file, but
> that seems acceptable since we shouldn't distribute software without
> its license.
-devel packages should Require the main package, thus, there really
isn't any need for the duplicate license copy.
~spot
From j.w.r.degoede at hhs.nl Mon Mar 3 18:24:00 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 03 Mar 2008 19:24:00 +0100
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <1204563460.3726.60.camel@localhost.localdomain>
References: <20080301150548.GA10317@amd.home.annexia.org> <20080301153811.GA10706@amd.home.annexia.org> <20080301170108.GA11487@amd.home.annexia.org> <20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
Message-ID: <47CC4240.4060104@hhs.nl>
Tom "spot" Callaway wrote:
> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
>
>> - Clarify where documentation should go. Currently my practice has
>> been to put just the license file (if any) in the main package's %doc,
>> and the license file plus all other documentation & examples in
>> the devel subpackage. This duplicates (only) the license file, but
>> that seems acceptable since we shouldn't distribute software without
>> its license.
>
> -devel packages should Require the main package, thus, there really
> isn't any need for the duplicate license copy.
>
+1
Regards,
Hans
From a.badger at gmail.com Mon Mar 3 18:41:05 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 03 Mar 2008 10:41:05 -0800
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To:
References:
Message-ID: <47CC4641.3050403@gmail.com>
Jason L Tibbitts III wrote:
> I saw a review ticket for a package which uses Requires(missingok):
> which I have not seen before. Some searching turned up the kismet and
> python-docutils which currently use this idiom.
>
Just a note: I've removed the missingok from python-docutils in rawhide
as it seems to be plainly wrong.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL:
From rjones at redhat.com Mon Mar 3 19:50:46 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 3 Mar 2008 19:50:46 +0000
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <1204563460.3726.60.camel@localhost.localdomain>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
Message-ID: <20080303195046.GA31815@amd.home.annexia.org>
On Mon, Mar 03, 2008 at 11:57:40AM -0500, Tom spot Callaway wrote:
> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
>
> > - Clarify where documentation should go. Currently my practice has
> > been to put just the license file (if any) in the main package's %doc,
> > and the license file plus all other documentation & examples in
> > the devel subpackage. This duplicates (only) the license file, but
> > that seems acceptable since we shouldn't distribute software without
> > its license.
>
> -devel packages should Require the main package, thus, there really
> isn't any need for the duplicate license copy.
But you could still just install the main package and not devel, and
then you are in the situation where Fedora has distributed a binary
and basically removed the licensing information. It doesn't feel like
the right thing to do to me (but IANAL).
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From tibbs at math.uh.edu Mon Mar 3 20:09:58 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 03 Mar 2008 14:09:58 -0600
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080303195046.GA31815@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org>
Message-ID:
>>>>> "RWMJ" == Richard W M Jones writes:
RWMJ> But you could still just install the main package and not devel,
Which is why the license file goes in the base package. What you
don't need is the second copy in -devel, becauase -devel will bring in
the main package which has the license.
Now, there have even been cases where one srpm generates multiple
packages which have no dependencies; even then, it's not necessary to
include the license in all of them.
- J<
From j.w.r.degoede at hhs.nl Mon Mar 3 20:10:07 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 03 Mar 2008 21:10:07 +0100
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080303195046.GA31815@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org> <20080301153811.GA10706@amd.home.annexia.org> <20080301170108.GA11487@amd.home.annexia.org> <20080303165309.GA31502@amd.home.annexia.org> <1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org>
Message-ID: <47CC5B1F.5000804@hhs.nl>
Richard W.M. Jones wrote:
> On Mon, Mar 03, 2008 at 11:57:40AM -0500, Tom spot Callaway wrote:
>> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
>>
>>> - Clarify where documentation should go. Currently my practice has
>>> been to put just the license file (if any) in the main package's %doc,
>>> and the license file plus all other documentation & examples in
>>> the devel subpackage. This duplicates (only) the license file, but
>>> that seems acceptable since we shouldn't distribute software without
>>> its license.
>> -devel packages should Require the main package, thus, there really
>> isn't any need for the duplicate license copy.
>
> But you could still just install the main package and not devel, and
> then you are in the situation where Fedora has distributed a binary
> and basically removed the licensing information. It doesn't feel like
> the right thing to do to me (but IANAL).
>
No Spot means it the other way around, keep the license in the main package and
drop it from the -devel one as that requires the main package anyways.
Regards,
Hans
From bruno at postle.net Mon Mar 3 22:18:32 2008
From: bruno at postle.net (Bruno Postle)
Date: Mon, 3 Mar 2008 22:18:32 +0000
Subject: [Fedora-packaging] Requires(missingok)
In-Reply-To: <47CBB6B9.10106@hhs.nl>
References:
<1204500868.326.4.camel@cutter> <47CBB6B9.10106@hhs.nl>
Message-ID: <20080303221831.GF25624@postle.net>
On Mon 03-Mar-2008 at 09:28 +0100, Hans de Goede wrote:
>
> Is there any way of softdependencies supported by yum? Is this planned
> for the the future, for plugin basd apps it would be nice to be able to
> hint to the end user that certain optional plugins (with perhaps some
> hefty deps) would be good to install
Surely this information already exists in the database?
A gimp plugin already has a 'Requires: gimp', so it ought to be
possible to select the gimp in some (imaginary) GUI and be offered
add-on packages that would be useful with the gimp.
`repoquery --whatrequires gimp` really does return a good list of
add-ons, and the advantage is that the gimp packager doesn't need to
list all possible past and future plugins.
--
Bruno
From rjones at redhat.com Mon Mar 3 22:18:43 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 3 Mar 2008 22:18:43 +0000
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <47CC5B1F.5000804@hhs.nl>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org>
<47CC5B1F.5000804@hhs.nl>
Message-ID: <20080303221843.GA2098@amd.home.annexia.org>
On Mon, Mar 03, 2008 at 09:10:07PM +0100, Hans de Goede wrote:
> Richard W.M. Jones wrote:
>> On Mon, Mar 03, 2008 at 11:57:40AM -0500, Tom spot Callaway wrote:
>>> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
>>>
>>>> - Clarify where documentation should go. Currently my practice has
>>>> been to put just the license file (if any) in the main package's %doc,
>>>> and the license file plus all other documentation & examples in
>>>> the devel subpackage. This duplicates (only) the license file, but
>>>> that seems acceptable since we shouldn't distribute software without
>>>> its license.
>>> -devel packages should Require the main package, thus, there really
>>> isn't any need for the duplicate license copy.
>>
>> But you could still just install the main package and not devel, and
>> then you are in the situation where Fedora has distributed a binary
>> and basically removed the licensing information. It doesn't feel like
>> the right thing to do to me (but IANAL).
>>
>
> No Spot means it the other way around, keep the license in the main package
> and drop it from the -devel one as that requires the main package anyways.
Right, got it now.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From rc040203 at freenet.de Tue Mar 4 04:22:06 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 04 Mar 2008 05:22:06 +0100
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080303221843.GA2098@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org> <47CC5B1F.5000804@hhs.nl>
<20080303221843.GA2098@amd.home.annexia.org>
Message-ID: <1204604526.3446.485.camel@beck.corsepiu.local>
On Mon, 2008-03-03 at 22:18 +0000, Richard W.M. Jones wrote:
> On Mon, Mar 03, 2008 at 09:10:07PM +0100, Hans de Goede wrote:
> > Richard W.M. Jones wrote:
> >> On Mon, Mar 03, 2008 at 11:57:40AM -0500, Tom spot Callaway wrote:
> >>> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
> >>>
> >>>> - Clarify where documentation should go. Currently my practice has
> >>>> been to put just the license file (if any) in the main package's %doc,
> >>>> and the license file plus all other documentation & examples in
> >>>> the devel subpackage. This duplicates (only) the license file, but
> >>>> that seems acceptable since we shouldn't distribute software without
> >>>> its license.
> >>> -devel packages should Require the main package, thus, there really
> >>> isn't any need for the duplicate license copy.
> >>
> >> But you could still just install the main package and not devel, and
> >> then you are in the situation where Fedora has distributed a binary
> >> and basically removed the licensing information. It doesn't feel like
> >> the right thing to do to me (but IANAL).
> >>
> >
> > No Spot means it the other way around, keep the license in the main package
> > and drop it from the -devel one as that requires the main package anyways.
This is the "simplified rule-of-thumb", however there also are
situations where this isn't "entirely right".
e.g.
- application licenses may differ from library licenses (e.g. apps
GPL'ed, libraries LGPL'ed).
- run-time licenses may differ from devel-licenses (e.g. library uses
GPL as umbrella, while individual files in a devel-package (often
headers) are covered by less restrictive licenses, such as BSD.)
- library licenses may differ from source-code licenses (e.g. library is
using LGPL as umbrella, but individual files being used inside of a
library are covered by less restrictive licenses).
Ralf
From panemade at gmail.com Wed Mar 5 06:04:36 2008
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Wed, 5 Mar 2008 11:34:36 +0530
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <47CC5B1F.5000804@hhs.nl>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org>
<47CC5B1F.5000804@hhs.nl>
Message-ID:
Hi all,
On Tue, Mar 4, 2008 at 1:40 AM, Hans de Goede wrote:
> Richard W.M. Jones wrote:
> > On Mon, Mar 03, 2008 at 11:57:40AM -0500, Tom spot Callaway wrote:
> >> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
> >>
> >>> - Clarify where documentation should go. Currently my practice has
> >>> been to put just the license file (if any) in the main package's %doc,
> >>> and the license file plus all other documentation & examples in
> >>> the devel subpackage. This duplicates (only) the license file, but
> >>> that seems acceptable since we shouldn't distribute software without
> >>> its license.
> >> -devel packages should Require the main package, thus, there really
> >> isn't any need for the duplicate license copy.
> >
> > But you could still just install the main package and not devel, and
> > then you are in the situation where Fedora has distributed a binary
> > and basically removed the licensing information. It doesn't feel like
> > the right thing to do to me (but IANAL).
> >
>
> No Spot means it the other way around, keep the license in the main package and
> drop it from the -devel one as that requires the main package anyways.
>
I prefer to see this documented in guidelines instead to discuss
this on fedora-packaging or say on fedora-devel list. I assume same
will be applied for other %doc files AUTHORS ChangeLog README that is
not to include them if they are same files already included in main
package right?
Regards,
Parag.
From tibbs at math.uh.edu Wed Mar 5 06:14:10 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 05 Mar 2008 00:14:10 -0600
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To:
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org>
<47CC5B1F.5000804@hhs.nl>
Message-ID:
>>>>> "PN" == Parag N(????) writes:
PN> I prefer to see this documented in guidelines instead to discuss
PN> this on fedora-packaging or say on fedora-devel list. I assume
PN> same will be applied for other %doc files AUTHORS ChangeLog README
PN> that is not to include them if they are same files already
PN> included in main package right?
Well, the existing guidelines already cover this by explicitly banning
duplicates in the %files list. I see the current discussion as
addressing the question of whether there are any permissible
exceptions to that, and whether the guidelines need to be modified to
allow them. That is obviously on topic for this list.
- J<
From rc040203 at freenet.de Wed Mar 5 06:21:50 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 05 Mar 2008 07:21:50 +0100
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To:
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org> <47CC5B1F.5000804@hhs.nl>
Message-ID: <1204698110.23165.20.camel@beck.corsepiu.local>
On Wed, 2008-03-05 at 11:34 +0530, Parag N(????) wrote:
> Hi all,
> On Tue, Mar 4, 2008 at 1:40 AM, Hans de Goede wrote:
> > Richard W.M. Jones wrote:
> > > On Mon, Mar 03, 2008 at 11:57:40AM -0500, Tom spot Callaway wrote:
> > >> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
> > >>
> > >>> - Clarify where documentation should go. Currently my practice has
> > >>> been to put just the license file (if any) in the main package's %doc,
> > >>> and the license file plus all other documentation & examples in
> > >>> the devel subpackage. This duplicates (only) the license file, but
> > >>> that seems acceptable since we shouldn't distribute software without
> > >>> its license.
> > >> -devel packages should Require the main package, thus, there really
> > >> isn't any need for the duplicate license copy.
> > >
> > > But you could still just install the main package and not devel, and
> > > then you are in the situation where Fedora has distributed a binary
> > > and basically removed the licensing information. It doesn't feel like
> > > the right thing to do to me (but IANAL).
> > >
> >
> > No Spot means it the other way around, keep the license in the main package and
> > drop it from the -devel one as that requires the main package anyways.
> >
> I prefer to see this documented in guidelines instead to discuss
> this on fedora-packaging or say on fedora-devel list. I assume same
> will be applied for other %doc files AUTHORS ChangeLog README that is
> not to include them if they are same files already included in main
> package right?
Well things aren't that simple. License/copyright files are special.
They are legal documents. Most other %doc files are informational
documents [1].
Whether to include AUTHORS, ChangeLog in a main (== run-time in most
cases) package is very arguable. In most cases, including them in a
main-package hardly makes any sense (They typically contain information
which is non-interesting to ordinary users).
READMEs are yet another class of file. They may contain all kind of
information. You will want to look into them to judge "if" and "where"
to add them.
Also, consider that breaking %doc into pieces technically isn't always
easy or feasible.
So, I am in favor to leave such decisions to a packager's discretion.
Ralf
[1] Interesting corner case: Is it legal to %doc (and therefore to allow
not installing them due to --exclude-docs) legal documents?
... Just wondering ;)
From panemade at gmail.com Wed Mar 5 07:05:18 2008
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Wed, 5 Mar 2008 12:35:18 +0530
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To:
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org>
<47CC5B1F.5000804@hhs.nl>
Message-ID:
Hi,
On 05 Mar 2008 00:14:10 -0600, Jason L Tibbitts III wrote:
> >>>>> "PN" == Parag N(????) writes:
>
> PN> I prefer to see this documented in guidelines instead to discuss
> PN> this on fedora-packaging or say on fedora-devel list. I assume
> PN> same will be applied for other %doc files AUTHORS ChangeLog README
> PN> that is not to include them if they are same files already
> PN> included in main package right?
>
> Well, the existing guidelines already cover this by explicitly banning
> duplicates in the %files list. I see the current discussion as
> addressing the question of whether there are any permissible
> exceptions to that, and whether the guidelines need to be modified to
> allow them. That is obviously on topic for this list.
Yes. Review guidelines already covered them. But I think I confused
and assumed that we need to add now explicitly some text like "keep
the license file in the main package and drop it from the -devel one
as that requires the main package anyways." at
http://fedoraproject.org/wiki/Packaging/Guidelines#head-9bbfa57478f0460c6160947a6bf795249488182b
Like we already have "for example API documentation belongs in the
-devel subpackage, not the main one" written in Documentation section
in Packaging Guidelines Page. So how about mentioning similar for
license file inclusion?
Anyway it may also looks like duplication of guideline rules at 2 places.
Thanks,
Parag.
From tcallawa at redhat.com Wed Mar 5 12:42:11 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 05 Mar 2008 07:42:11 -0500
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <1204698110.23165.20.camel@beck.corsepiu.local>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org> <47CC5B1F.5000804@hhs.nl>
<1204698110.23165.20.camel@beck.corsepiu.local>
Message-ID: <1204720931.2921.2.camel@localhost.localdomain>
On Wed, 2008-03-05 at 07:21 +0100, Ralf Corsepius wrote:
> [1] Interesting corner case: Is it legal to %doc (and therefore to
> allow
> not installing them due to --exclude-docs) legal documents?
> ... Just wondering ;)
Yes, because open source/free licenses do not require that you agree to
them before using the software.
~spot
From bradbell at seanet.com Wed Mar 5 13:13:56 2008
From: bradbell at seanet.com (Brad Bell)
Date: Wed, 05 Mar 2008 05:13:56 -0800
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <20080304170039.0DE8B6183DA@hormel.redhat.com>
References: <20080304170039.0DE8B6183DA@hormel.redhat.com>
Message-ID: <47CE9C94.2060804@seanet.com>
fedora-packaging-request at redhat.com wrote:
> Send Fedora-packaging mailing list submissions to
> fedora-packaging at redhat.com
>
.
.
.
>
> Tom "spot" Callaway wrote:
>
>> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
>>
>>
>>> - Clarify where documentation should go. Currently my practice has
>>> been to put just the license file (if any) in the main package's %doc,
>>> and the license file plus all other documentation & examples in
>>> the devel subpackage. This duplicates (only) the license file, but
>>> that seems acceptable since we shouldn't distribute software without
>>> its license.
>>>
>> -devel packages should Require the main package, thus, there really
>> isn't any need for the duplicate license copy.
>>
>>
The cppad package is totally C++ include files. There is a cppad-devel
and cppad-doc subpackage, but there is no main package. So the rule
above does not apply in this case.
From rc040203 at freenet.de Wed Mar 5 13:32:37 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 05 Mar 2008 14:32:37 +0100
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <1204720931.2921.2.camel@localhost.localdomain>
References: <20080301150548.GA10317@amd.home.annexia.org>
<20080301153811.GA10706@amd.home.annexia.org>
<20080301170108.GA11487@amd.home.annexia.org>
<20080303165309.GA31502@amd.home.annexia.org>
<1204563460.3726.60.camel@localhost.localdomain>
<20080303195046.GA31815@amd.home.annexia.org> <47CC5B1F.5000804@hhs.nl>
<1204698110.23165.20.camel@beck.corsepiu.local>
<1204720931.2921.2.camel@localhost.localdomain>
Message-ID: <1204723957.3615.5.camel@beck.corsepiu.local>
On Wed, 2008-03-05 at 07:42 -0500, Tom "spot" Callaway wrote:
> On Wed, 2008-03-05 at 07:21 +0100, Ralf Corsepius wrote:
> > [1] Interesting corner case: Is it legal to %doc (and therefore to
> > allow
> > not installing them due to --exclude-docs) legal documents?
> > ... Just wondering ;)
>
> Yes, because open source/free licenses do not require that you agree to
> them before using the software.
Well, there are these "license/copyright-clause must not be removed"
cases ... admitted, in most cases such kind of doc are in inlined ...
Ralf
From rjones at redhat.com Wed Mar 5 13:48:41 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 5 Mar 2008 13:48:41 +0000
Subject: [Fedora-packaging] Some licenses which need checking
Message-ID: <20080305134841.GA24897@amd.home.annexia.org>
I'm trying to package a Unicode library which contains lots of
different " to Unicode" mappings files.
https://bugzilla.redhat.com/show_bug.cgi?id=253564
I've got some questions:
(1) Codepage 932 is an MS extension to Shift JIS. The file that is
shipped in the source package is derived from this one:
http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
Note that we also ship essentially the same set of mappings in other
Fedora packages, eg:
/usr/share/xemacs-21.5-b28/etc/unicode/unicode-consortium/CP932.TXT
/usr/share/cups/charmaps/windows-932.txt
There's no license information but it was my understanding (IANAL)
that simple lists of facts like this couldn't be monopolized in the
US.
(2) The package ships Unicode data with the license below. Is it OK?
http://www.unicode.org/Public/3.2-Update/UnicodeData-3.2.0.html#UCD_Terms
(3) The package contains locales from the IBM ICU project. The
license for this looks like BSD to me, so is this OK?
http://source.icu-project.org/repos/icu/icu/trunk/license.html
(4) Finally there is one file whose license is described like this:
The file allkey.txt [sic] is obtained from Unicode Consortium Web site.
Its copyright is owned by Unicode Consortium. Its use, reproduction,
distribution are permitted under the term of
http://www.unicode.org/copyright.html
where the link goes to a long-winded and confusing page. The file
itself is just a list of facts
(http://www.annexia.org/tmp/allkeys.txt).
Ancillary question:
(5) If it turns out that some files aren't safe to distribute, do I
need to remove them from the source tarball, and if so how?
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From nicolas.mailhot at laposte.net Wed Mar 5 14:01:23 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 5 Mar 2008 15:01:23 +0100 (CET)
Subject: [Fedora-packaging] Some licenses which need checking
In-Reply-To: <20080305134841.GA24897@amd.home.annexia.org>
References: <20080305134841.GA24897@amd.home.annexia.org>
Message-ID: <56009.192.54.193.59.1204725683.squirrel@rousalka.dyndns.org>
Le Mer 5 mars 2008 14:48, Richard W.M. Jones a ?crit :
> I'm trying to package a Unicode library which contains lots of
> different " to Unicode" mappings files.
Many packages ship unicode.org data (perl is another one). It would be
really nice to have a reference package that provided this data for
the rest of the system (and was updated with unicode.org revision,
since right now you can have different apps with different versions of
the same files).
When I had the same problem as you I chickened out and added a
builddep on the perl files, since I needed only two of them and only
at build time, and didn't want to do the legal legwork on stuff
already approved as part of another package.
Regards,
--
Nicolas Mailhot
From tcallawa at redhat.com Wed Mar 5 14:39:17 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 05 Mar 2008 09:39:17 -0500
Subject: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
In-Reply-To: <47CE9C94.2060804@seanet.com>
References: <20080304170039.0DE8B6183DA@hormel.redhat.com>
<47CE9C94.2060804@seanet.com>
Message-ID: <1204727957.3586.2.camel@localhost.localdomain>
On Wed, 2008-03-05 at 05:13 -0800, Brad Bell wrote:
> The cppad package is totally C++ include files. There is a cppad-devel
> and cppad-doc subpackage, but there is no main package. So the rule
> above does not apply in this case.
Yep. Exceptions abound. :)
~spot
From rjones at redhat.com Wed Mar 5 18:14:47 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 5 Mar 2008 18:14:47 +0000
Subject: [Fedora-packaging] UPDATED: New draft packaging guidelines for OCaml
In-Reply-To: <47C97AB2.2080108@hhs.nl>
References: <20080301150548.GA10317@amd.home.annexia.org>
<47C97AB2.2080108@hhs.nl>
Message-ID: <20080305181332.GA28092@amd.home.annexia.org>
https://fedoraproject.org/wiki/PackagingDrafts/OCaml
Diff from the previous version:
https://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=diff&rev2=2&rev1=1
Comments etc. welcome.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From j.w.r.degoede at hhs.nl Wed Mar 5 18:43:40 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 05 Mar 2008 19:43:40 +0100
Subject: [Fedora-packaging] UPDATED: New draft packaging guidelines for
OCaml
In-Reply-To: <20080305181332.GA28092@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org> <47C97AB2.2080108@hhs.nl>
<20080305181332.GA28092@amd.home.annexia.org>
Message-ID: <47CEE9DC.1030307@hhs.nl>
Richard W.M. Jones wrote:
> https://fedoraproject.org/wiki/PackagingDrafts/OCaml
>
> Diff from the previous version:
> https://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=diff&rev2=2&rev1=1
>
> Comments etc. welcome.
>
Looks very good,
FPC, I would like to suggest we discuss (and maybe approve) this on our next
meeting.
Regards,
Hans
From j.w.r.degoede at hhs.nl Wed Mar 5 18:44:16 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 05 Mar 2008 19:44:16 +0100
Subject: [Fedora-packaging] UPDATED: New draft packaging guidelines for
OCaml
In-Reply-To: <20080305181332.GA28092@amd.home.annexia.org>
References: <20080301150548.GA10317@amd.home.annexia.org> <47C97AB2.2080108@hhs.nl>
<20080305181332.GA28092@amd.home.annexia.org>
Message-ID: <47CEEA00.6010200@hhs.nl>
Richard W.M. Jones wrote:
> https://fedoraproject.org/wiki/PackagingDrafts/OCaml
>
> Diff from the previous version:
> https://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=diff&rev2=2&rev1=1
>
> Comments etc. welcome.
>
> Rich.
>
p.s.
Rich, in my last mail I sortof assumed that this is ready for FPC discussion,
is it?
From ville.skytta at iki.fi Wed Mar 5 19:26:11 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 5 Mar 2008 21:26:11 +0200
Subject: [Fedora-packaging] Re: UTF-8 package names
In-Reply-To: <1204076617.3446.187.camel@beck.corsepiu.local>
References: <47C459A9.7020609@gmail.com>
<1204063124.5684.43.camel@localhost.localdomain>
<1204076617.3446.187.camel@beck.corsepiu.local>
Message-ID: <200803052126.12272.ville.skytta@iki.fi>
On Wednesday 27 February 2008, Ralf Corsepius wrote:
> On Tue, 2008-02-26 at 16:58 -0500, Simo Sorce wrote:
> > If this is really a usability problem I am sure that the proposal to
> > provide an alternate ASCII only name (need rules to determine how you
> > get from non-ASCII to ASCII) is a very good one, even if copy&paste, or
> > other UIs can be used as well.
>
> In bugzilla, I had proposed the opposite:
Me too.
> Mandate ASCII-only _package names_ (=> ASCII-only file names), but
> additionally allow alternative (utf-8) "Provides" if desired.
This still gets my +1. I have no problem with fixing infrastructure for more
UTF-8 awareness though.
> This would allow GUI tools to display these utf-names, while it would
> help keep things simple for command-line tools.
I can't think of a use case where it would be desirable for GUI tools to
display anything else but the package's real name as its name. Dunno if this
is what you meant.
From rc040203 at freenet.de Thu Mar 6 04:23:24 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 06 Mar 2008 05:23:24 +0100
Subject: [Fedora-packaging] Re: UTF-8 package names
In-Reply-To: <200803052126.12272.ville.skytta@iki.fi>
References: <47C459A9.7020609@gmail.com>
<1204063124.5684.43.camel@localhost.localdomain>
<1204076617.3446.187.camel@beck.corsepiu.local>
<200803052126.12272.ville.skytta@iki.fi>
Message-ID: <1204777404.7674.9.camel@beck.corsepiu.local>
On Wed, 2008-03-05 at 21:26 +0200, Ville Skytt? wrote:
> On Wednesday 27 February 2008, Ralf Corsepius wrote:
> > On Tue, 2008-02-26 at 16:58 -0500, Simo Sorce wrote:
>
> > > If this is really a usability problem I am sure that the proposal to
> > > provide an alternate ASCII only name (need rules to determine how you
> > > get from non-ASCII to ASCII) is a very good one, even if copy&paste, or
> > > other UIs can be used as well.
> >
> > In bugzilla, I had proposed the opposite:
>
> Me too.
>
> > Mandate ASCII-only _package names_ (=> ASCII-only file names), but
> > additionally allow alternative (utf-8) "Provides" if desired.
>
> This still gets my +1. I have no problem with fixing infrastructure for more
> UTF-8 awareness though.
So do I.
> > This would allow GUI tools to display these utf-names, while it would
> > help keep things simple for command-line tools.
>
> I can't think of a use case where it would be desirable for GUI tools to
> display anything else but the package's real name as its name.
Neither do I.
> Dunno if this is what you meant.
What I meant was, to allow people to install packages using their "real"
non-ASCII file names (e.g. yum install ?collier-fonts).
As these people had proposed using installer GUIs, I had been referring
to GUI-tools in the sentence above.
Ralf
From j.w.r.degoede at hhs.nl Sun Mar 9 16:24:57 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 09 Mar 2008 17:24:57 +0100
Subject: [Fedora-packaging] Blocking reviews on to be written guidelines?
In-Reply-To: <1204557302.3726.4.camel@localhost.localdomain>
References: <47CBB966.2040705@hhs.nl> <23059.192.54.193.59.1204535186.squirrel@rousalka.dyndns.org>
<1204557302.3726.4.camel@localhost.localdomain>
Message-ID: <47D40F59.5000402@hhs.nl>
Tom "spot" Callaway wrote:
> On Mon, 2008-03-03 at 10:06 +0100, Nicolas Mailhot wrote:
>> The 'problem' with java packages is that the packaging guidelines have
>> largely been defined outside Fedora (since part of the platform was
>> historicaly closed), and there's been a drive to rewrite history and
>> start from scratch instead of trying to work with the original third
>> party repository to update those rules (if needed).
>>
> Really, the problem is this:
>
> 1. No one has proposed any serious Java packaging guidelines for Fedora.
> If someone were to take the JPackage guidelines and propose them as the
> Fedora packaging guidelines, it would be a start at least, right now,
> we've got nothing.
>
Well, we have:
http://fedoraproject.org/wiki/PackagingDrafts/Java
But I must agree that that still needs some work. And there also is:
http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage
But thats seems somewhat incomplete too.
> 2. The Java packages that we have currently are rather inconsistent on
> how they package, and many of them are badly bitrotted for a variety of
> reasons, so we can't just "keep on doing what we've been doing".
>
Well, most java packages which I've seen seem to just be copy copies of
jpackage packages and / or based on the jpackage template, and those looked ok
(to me).
> Thus, the hold. When someone presents a set of reasonable guidelines for
> Java packages, we'll help knock them into shape and lift the hold. Very
> few of us on the FPC have any Java experience, so we're relying on the
> community with Java interest/experience to fill this void.
>
Well, I guess one of my first tasks as a new FPC member will be getting the
java package guidelines into shape then, I'll contact Lubomir Kundrak about
this, as he seems to be trying to get:
http://fedoraproject.org/wiki/PackagingDrafts/Java
Into shape.
I still believe it would be ok to continue with reviewing java packages on a
best foot forward notion until the guidelines are finished though. I believe
that holding packages up for formal reasons like this (other then legal
formalities) tends to frustrate contributers, and thats the last thing we want
to do.
Thanks & Regards,
Hans
From tcallawa at redhat.com Sun Mar 9 17:23:58 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sun, 09 Mar 2008 13:23:58 -0400
Subject: [Fedora-packaging] Blocking reviews on to be written guidelines?
In-Reply-To: <47D40F59.5000402@hhs.nl>
References: <47CBB966.2040705@hhs.nl>
<23059.192.54.193.59.1204535186.squirrel@rousalka.dyndns.org>
<1204557302.3726.4.camel@localhost.localdomain>
<47D40F59.5000402@hhs.nl>
Message-ID: <1205083438.2956.74.camel@localhost.localdomain>
On Sun, 2008-03-09 at 17:24 +0100, Hans de Goede wrote:
> I still believe it would be ok to continue with reviewing java
> packages on a
> best foot forward notion until the guidelines are finished though. I
> believe
> that holding packages up for formal reasons like this (other then
> legal
> formalities) tends to frustrate contributers, and thats the last thing
> we want
> to do.
The flip side of this is if we let packages pass review without any
guidelines on which to base the review by, then there is no real
motivation for those packagers (or anyone) to generate the guidelines.
~spot
From j.w.r.degoede at hhs.nl Sun Mar 9 18:25:59 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 09 Mar 2008 19:25:59 +0100
Subject: [Fedora-packaging] Blocking reviews on to be written guidelines?
In-Reply-To: <1205083438.2956.74.camel@localhost.localdomain>
References: <47CBB966.2040705@hhs.nl> <23059.192.54.193.59.1204535186.squirrel@rousalka.dyndns.org> <1204557302.3726.4.camel@localhost.localdomain> <47D40F59.5000402@hhs.nl>
<1205083438.2956.74.camel@localhost.localdomain>
Message-ID: <47D42BB7.5040205@hhs.nl>
Tom "spot" Callaway wrote:
> On Sun, 2008-03-09 at 17:24 +0100, Hans de Goede wrote:
>> I still believe it would be ok to continue with reviewing java
>> packages on a
>> best foot forward notion until the guidelines are finished though. I
>> believe
>> that holding packages up for formal reasons like this (other then
>> legal
>> formalities) tends to frustrate contributers, and thats the last thing
>> we want
>> to do.
>
> The flip side of this is if we let packages pass review without any
> guidelines on which to base the review by, then there is no real
> motivation for those packagers (or anyone) to generate the guidelines.
>
I disagree, take the ocaml guidelines for example, the initial draft was
written by Richard Jones and Me (well mostly Richard) when we were working on
getting a set of ocaml packages into Fedora (with Richard as Submitter and me
as Reviewer).
We started writing guidelines because we needed them to be able to do the
reviews, as too little was known about sensibly packaging ocaml stuff at that
time, and we didn't want to make irreversible (hard to reverse) mistakes.
The ocaml example proves that:
1) guidelines will be written when needed without the big: no approval before
guidelines are in place measure needed to motivate people
2) that its good to allow packages before (final) guidelines, to get experience
with all the involved issues
Regards,
Hans
From rjones at redhat.com Mon Mar 10 14:13:37 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 10 Mar 2008 14:13:37 +0000
Subject: [Fedora-packaging] rpaths to libraries in non-standard locations
(libperl.so in particular)
Message-ID: <20080310141337.GA1801@amd.home.annexia.org>
In one OCaml package:
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec
we link to libperl.so. libperl.so (the Perl runtime) lives in a
strange directory,
eg. /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
or /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
The normal, non-Fedora way to build this package is to include an
rpath in our library and programs so that they can always find
libperl.so at run time[1]. Obviously this rpath is stripped in the
current Fedora package.
So this forces the user of any perl4caml program to set
LD_LIBRARY_PATH explicitly to include the libperl.so directory[2].
http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544
My reading of the guidelines is that actually the Perl package is
wrong. It should include an /etc/ld.so.conf.d/perl.conf file giving
the correct path. On the other hand, maybe I should be allowed to
include an rpath in this situation because I really always want to be
linked to that particular libperl.so (not, say, a version from a
different Perl). Or yet another way to fix this would be for
libperl.so to go in a standard directory like %{_libdir}. That might
break Perl programs though.
What's the right way to solve this?
Rich.
*** Note [1] ***
# standard example from the package, as built by the package:
$ ldd examples/test.opt
linux-gate.so.1 => (0x00110000)
libperl.so => /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so (0x00968000)
libresolv.so.2 => /lib/libresolv.so.2 (0x008e3000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00905000)
libdl.so.2 => /lib/libdl.so.2 (0x0052a000)
libm.so.6 => /lib/libm.so.6 (0x004ff000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00249000)
libutil.so.1 => /lib/libutil.so.1 (0x04461000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00531000)
libc.so.6 => /lib/libc.so.6 (0x0038e000)
/lib/ld-linux.so.2 (0x0036b000)
# contains an rpath:
$ chrpath --list examples/test.opt
examples/test.opt: RPATH=/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE:/usr/local/lib
*** Note [2] ***
$ examples/test.bc
Fatal error: cannot load shared library dllperl4caml
Reason: libperl.so: cannot open shared object file: No such file or directory
# installed version of the library has had rpath removed:
$ ldd /usr/lib/ocaml/stublibs/dllperl4caml.so
linux-gate.so.1 => (0x00110000)
libperl.so => not found
libresolv.so.2 => /lib/libresolv.so.2 (0x0011b000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00130000)
libdl.so.2 => /lib/libdl.so.2 (0x0014a000)
libm.so.6 => /lib/libm.so.6 (0x0014f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00178000)
libutil.so.1 => /lib/libutil.so.1 (0x001ab000)
libpthread.so.0 => /lib/libpthread.so.0 (0x001af000)
libc.so.6 => /lib/libc.so.6 (0x001c9000)
/lib/ld-linux.so.2 (0x0036b000)
# so now you have to set LD_LIBRARY_PATH to run a program:
$ LD_LIBRARY_PATH=/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE examples/test.bc
this is loading the 'test.pl' script!
this is the 'return_one' function!
return_one returned 1
adder (3, 4) = 7
this is the 'return_array' function!
array returned: 1 2 3
this is the 'return_one' function!
return_one returned 1
closure returned 12
$a contains 3
TestClass.foo is 1
TestClass.foo is 2
sv_is_undef (undef) = true
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From rjones at redhat.com Mon Mar 10 14:15:15 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 10 Mar 2008 14:15:15 +0000
Subject: [Fedora-packaging] Couple of things I'd like to discuss at
tomorrow's Fedora Packaging meeting
Message-ID: <20080310141515.GB1801@amd.home.annexia.org>
[I don't know if this the right place to post agenda items ...]
(1) Review this:
https://fedoraproject.org/wiki/PackagingDrafts/OCaml
and if acceptable, propose that it be submitted to FESCO.
(2) Some complicated licenses I'm having problems with:
https://www.redhat.com/archives/fedora-packaging/2008-March/msg00059.html
(Actually I'd be happy if someone can just take a closer look at that
email).
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From rdieter at math.unl.edu Mon Mar 10 14:24:40 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 10 Mar 2008 09:24:40 -0500
Subject: [Fedora-packaging] rpaths to libraries in non-standard locations
(libperl.so in particular)
In-Reply-To: <20080310141337.GA1801@amd.home.annexia.org>
References: <20080310141337.GA1801@amd.home.annexia.org>
Message-ID: <47D544A8.3040703@math.unl.edu>
Richard W.M. Jones wrote:
> In one OCaml package:
> BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
> spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec
...
> On the other hand, maybe I should be allowed to
> include an rpath in this situation because I really always want to be
> linked to that particular libperl.so
This is a case where rpath usage is acceptable, imo.
-- Rex
From dominik at greysector.net Mon Mar 10 15:14:06 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 10 Mar 2008 16:14:06 +0100
Subject: [Fedora-packaging] rpaths to libraries in non-standard locations
(libperl.so in particular)
In-Reply-To: <47D544A8.3040703@math.unl.edu>
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
Message-ID: <20080310151406.GA27079@onizuka.greysector.net>
On Monday, 10 March 2008 at 15:24, Rex Dieter wrote:
> Richard W.M. Jones wrote:
> >In one OCaml package:
>
> > BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
> > spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec
> ...
> > On the other hand, maybe I should be allowed to
> > include an rpath in this situation because I really always want to be
> > linked to that particular libperl.so
>
> This is a case where rpath usage is acceptable, imo.
I wonder why libperl is not a proper library then. I see that it has no SONAME.
Are there any plans upstream to make it a proper library?
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
From tcallawa at redhat.com Mon Mar 10 15:18:09 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 10 Mar 2008 11:18:09 -0400
Subject: [Fedora-packaging] Couple of things I'd like to discuss at
tomorrow's Fedora Packaging meeting
In-Reply-To: <20080310141515.GB1801@amd.home.annexia.org>
References: <20080310141515.GB1801@amd.home.annexia.org>
Message-ID: <1205162289.2956.114.camel@localhost.localdomain>
On Mon, 2008-03-10 at 14:15 +0000, Richard W.M. Jones wrote:
> (2) Some complicated licenses I'm having problems with:
>
> https://www.redhat.com/archives/fedora-packaging/2008-March/msg00059.html
>
> (Actually I'd be happy if someone can just take a closer look at that
> email).
I'll look at them, but note that we do have a fedora-legal-list just for
this sort of thing:
http://www.redhat.com/mailman/listinfo/fedora-legal-list
~spot
From tcallawa at redhat.com Mon Mar 10 15:19:20 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 10 Mar 2008 11:19:20 -0400
Subject: [Fedora-packaging] rpaths to libraries in non-standard
locations (libperl.so in particular)
In-Reply-To: <20080310151406.GA27079@onizuka.greysector.net>
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
<20080310151406.GA27079@onizuka.greysector.net>
Message-ID: <1205162360.2956.116.camel@localhost.localdomain>
On Mon, 2008-03-10 at 16:14 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 10 March 2008 at 15:24, Rex Dieter wrote:
> > Richard W.M. Jones wrote:
> > >In one OCaml package:
> >
> > > BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
> > > spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec
> > ...
> > > On the other hand, maybe I should be allowed to
> > > include an rpath in this situation because I really always want to be
> > > linked to that particular libperl.so
> >
> > This is a case where rpath usage is acceptable, imo.
>
> I wonder why libperl is not a proper library then. I see that it has no SONAME.
> Are there any plans upstream to make it a proper library?
Not that I'm aware of. IMHO, this is a valid rpath exception case.
~spot
From mtasaka at ioa.s.u-tokyo.ac.jp Mon Mar 10 15:18:50 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Tue, 11 Mar 2008 00:18:50 +0900
Subject: [Fedora-packaging] rpaths to libraries in non-standard locations
(libperl.so in particular)
In-Reply-To: <47D544A8.3040703@math.unl.edu>
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
Message-ID: <47D5515A.60804@ioa.s.u-tokyo.ac.jp>
Rex Dieter wrote, at 03/10/2008 11:24 PM +9:00:
> Richard W.M. Jones wrote:
>> In one OCaml package:
>
>> BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
>> spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec
> ...
> > On the other hand, maybe I should be allowed to
> > include an rpath in this situation because I really always want to be
> > linked to that particular libperl.so
>
> This is a case where rpath usage is acceptable, imo.
>
> -- Rex
Only just a note that perl itself has rpath.
[tasaka1 at localhost ~]$ objdump --headers --private-headers /usr/bin/perl | grep RPATH
RPATH /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE
Regards,
Mamoru
From rjones at redhat.com Mon Mar 10 15:32:56 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 10 Mar 2008 15:32:56 +0000
Subject: [Fedora-packaging] Couple of things I'd like to discuss at
tomorrow's Fedora Packaging meeting
In-Reply-To: <1205162289.2956.114.camel@localhost.localdomain>
References: <20080310141515.GB1801@amd.home.annexia.org>
<1205162289.2956.114.camel@localhost.localdomain>
Message-ID: <20080310153256.GC1801@amd.home.annexia.org>
On Mon, Mar 10, 2008 at 11:18:09AM -0400, Tom spot Callaway wrote:
> On Mon, 2008-03-10 at 14:15 +0000, Richard W.M. Jones wrote:
>
> > (2) Some complicated licenses I'm having problems with:
> >
> > https://www.redhat.com/archives/fedora-packaging/2008-March/msg00059.html
> >
> > (Actually I'd be happy if someone can just take a closer look at that
> > email).
>
> I'll look at them, but note that we do have a fedora-legal-list just for
> this sort of thing:
>
> http://www.redhat.com/mailman/listinfo/fedora-legal-list
Oh I didn't see that. I'll move the discussion over there then.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From ville.skytta at iki.fi Mon Mar 10 21:40:54 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 10 Mar 2008 23:40:54 +0200
Subject: [Fedora-packaging] rpaths to libraries in non-standard locations
(libperl.so in particular)
In-Reply-To: <47D544A8.3040703@math.unl.edu>
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
Message-ID: <200803102340.55236.ville.skytta@iki.fi>
On Monday 10 March 2008, Rex Dieter wrote:
> Richard W.M. Jones wrote:
> > In one OCaml package:
> >
> > BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
> > spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec
>
> ...
>
> > On the other hand, maybe I should be allowed to
> > include an rpath in this situation because I really always want to be
> > linked to that particular libperl.so
>
> This is a case where rpath usage is acceptable, imo.
Agreed. Some kind of versioned dependency to perl or the library path (but I
suppose the latter would cause yum to download filelists) would be a good
thing to add so things won't break silently when files are moved around on
perl upgrades.
From a.badger at gmail.com Tue Mar 11 01:18:43 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 10 Mar 2008 18:18:43 -0700
Subject: [Fedora-packaging] rpaths to libraries in non-standard locations
(libperl.so in particular)
In-Reply-To: <200803102340.55236.ville.skytta@iki.fi>
References: <20080310141337.GA1801@amd.home.annexia.org> <47D544A8.3040703@math.unl.edu>
<200803102340.55236.ville.skytta@iki.fi>
Message-ID: <47D5DDF3.9020207@gmail.com>
Ville Skytt? wrote:
> On Monday 10 March 2008, Rex Dieter wrote:
>> Richard W.M. Jones wrote:
>>> In one OCaml package:
>>>
>>> BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
>>> spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec
>> ...
>>
>> > On the other hand, maybe I should be allowed to
>> > include an rpath in this situation because I really always want to be
>> > linked to that particular libperl.so
>>
>> This is a case where rpath usage is acceptable, imo.
>
> Agreed. Some kind of versioned dependency to perl or the library path (but I
> suppose the latter would cause yum to download filelists) would be a good
> thing to add so things won't break silently when files are moved around on
> perl upgrades.
>
+1 to both the rpath and Ville's suggestion.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL:
From wtogami at redhat.com Tue Mar 11 03:17:06 2008
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 10 Mar 2008 23:17:06 -0400
Subject: [Fedora-packaging] --excludedocs and packaging guidelines?
Message-ID: <47D5F9B2.30707@redhat.com>
So a while back there seems to have been agreement that runtime
shouldn't depend on anything marked as %doc because it could be not
installed in cases where --excludedocs is used. For this reason for
example, we moved the RPM GPG keys out of %doc.
http://fedoraproject.org/wiki/Packaging/Guidelines
But I don't see any such rule or even a suggestion in the packaging
guidelines. Should it be in there?
Furthermore I wonder if there should be any rule or suggestion of how
install-info should be used within a %post scriptlet. I see some
packages redirect the output of install-info to /dev/null, and
install-info's man page also describes a --quiet option. Might we
recommend in guidelines the use of this to suppress the warning that
happens when a package is installed with --excludedocs?
Warren Togami
wtogami at redhat.com
Installing: info ##################### [ 61/354]
install-info: No such file or directory for /usr/share/info/info-stnd.info
Installing: readline ##################### [ 70/354]
install-info: No such file or directory for /usr/share/info/history.info.gz
install-info: No such file or directory for
/usr/share/info/rluserman.info.gz
Installing: findutils ##################### [ 76/354]
install-info: No such file or directory for /usr/share/info/find.info.gz
Installing: sed ##################### [ 77/354]
install-info: No such file or directory for /usr/share/info/sed.info.gz
Installing: libidn ##################### [ 78/354]
install-info: No such file or directory for /usr/share/info/libidn.info.gz
Installing: parted ##################### [ 80/354]
install-info: No such file or directory for /usr/share/info/parted.info.gz
Installing: cpio ##################### [ 82/354]
install-info: No such file or directory for /usr/share/info/cpio.info.gz
Installing: tar ##################### [ 91/354]
install-info: No such file or directory for /usr/share/info/tar.info.gz
Installing: pinentry ##################### [ 93/354]
install-info: No such file or directory for /usr/share/info/pinentry.info
Installing: which ##################### [ 94/354]
install-info: No such file or directory for /usr/share/info/which.info.gz
Installing: cpp ##################### [ 95/354]
install-info: No such file or directory for /usr/share/info/cpp.info.gz
Installing: diffutils ##################### [124/354]
install-info: No such file or directory for /usr/share/info/diff.info.gz
Installing: coreutils ##################### [165/354]
install-info: No such file or directory for /usr/share/info/coreutils.info
Installing: dirmngr ##################### [191/354]
install-info: No such file or directory for /usr/share/info/dirmngr.info.gz
Installing: gnupg2 ##################### [192/354]
install-info: No such file or directory for /usr/share/info/gnupg.info
Installing: gnash ##################### [217/354]
install-info: No such file or directory for /usr/share/info/gnash_ref.info
install-info: No such file or directory for /usr/share/info/gnash_user.info
From opensource at till.name Tue Mar 11 10:04:32 2008
From: opensource at till.name (Till Maas)
Date: Tue, 11 Mar 2008 11:04:32 +0100
Subject: [Fedora-packaging] --excludedocs and packaging guidelines?
In-Reply-To: <47D5F9B2.30707@redhat.com>
References: <47D5F9B2.30707@redhat.com>
Message-ID: <200803111104.33461.opensource@till.name>
On Tue March 11 2008, Warren Togami wrote:
> So a while back there seems to have been agreement that runtime
> shouldn't depend on anything marked as %doc because it could be not
> installed in cases where --excludedocs is used. For this reason for
> example, we moved the RPM GPG keys out of %doc.
>
> http://fedoraproject.org/wiki/Packaging/Guidelines
> But I don't see any such rule or even a suggestion in the packaging
> guidelines. Should it be in there?
It is in the Review Guidelines:
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
| - MUST: If a package includes something as %doc, it must not affect the
| runtime of the application. To summarize: If it is in %doc, the program must
| run properly if it is not present.
Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL:
From rjones at redhat.com Tue Mar 11 10:05:56 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 11 Mar 2008 10:05:56 +0000
Subject: [Fedora-packaging] rpaths to libraries in non-standard
locations (libperl.so in particular)
In-Reply-To: <200803102340.55236.ville.skytta@iki.fi>
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
<200803102340.55236.ville.skytta@iki.fi>
Message-ID: <20080311100556.GA9689@amd.home.annexia.org>
On Mon, Mar 10, 2008 at 11:40:54PM +0200, Ville Skytt? wrote:
> Agreed. Some kind of versioned dependency to perl or the library
> path (but I suppose the latter would cause yum to download
> filelists) would be a good thing to add so things won't break
> silently when files are moved around on perl upgrades.
Yes ... This week's upgrade to Perl 5.10 should have broken the
dependency for ocaml-perl4caml. I'll rebuild it anyway and add a
dependency. Not sure whether to use MODULE_COMPAT:
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
or just the straight installed version of perl. Probably the latter
is better.
It shouldn't download any filelists ...
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From rjones at redhat.com Tue Mar 11 11:02:23 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 11 Mar 2008 11:02:23 +0000
Subject: [Fedora-packaging] rpaths to libraries in non-standard
locations (libperl.so in particular)
In-Reply-To: <20080311100556.GA9689@amd.home.annexia.org>
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
<200803102340.55236.ville.skytta@iki.fi>
<20080311100556.GA9689@amd.home.annexia.org>
Message-ID: <20080311110223.GB9689@amd.home.annexia.org>
On Tue, Mar 11, 2008 at 10:05:56AM +0000, Richard W.M. Jones wrote:
> On Mon, Mar 10, 2008 at 11:40:54PM +0200, Ville Skytt? wrote:
> > Agreed. Some kind of versioned dependency to perl or the library
> > path (but I suppose the latter would cause yum to download
> > filelists) would be a good thing to add so things won't break
> > silently when files are moved around on perl upgrades.
>
> Yes ... This week's upgrade to Perl 5.10 should have broken the
> dependency for ocaml-perl4caml. I'll rebuild it anyway and add a
> dependency. Not sure whether to use MODULE_COMPAT:
[...]
Actually that doesn't work. The best I could come up with was to
depend on the path of the rpath'd library.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From ville.skytta at iki.fi Tue Mar 11 19:54:57 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 11 Mar 2008 21:54:57 +0200
Subject: [Fedora-packaging] --excludedocs and packaging guidelines?
In-Reply-To: <47D5F9B2.30707@redhat.com>
References: <47D5F9B2.30707@redhat.com>
Message-ID: <200803112154.57743.ville.skytta@iki.fi>
On Tuesday 11 March 2008, Warren Togami wrote:
> Furthermore I wonder if there should be any rule or suggestion of how
> install-info should be used within a %post scriptlet. I see some
> packages redirect the output of install-info to /dev/null, and
> install-info's man page also describes a --quiet option. Might we
> recommend in guidelines the use of this to suppress the warning that
> happens when a package is installed with --excludedocs?
install-info's --quiet does not suppress errors resulting from files not
found.
Redirecting stderr to /dev/null sounds a bit draconian to me; testing whether
the info file exists before invoking install-info would be somewhat better.
But the somewhat annoying part of that is that currently we'd need to test if
the gzipped info file exists which is hardcoding assumptions about what
happens under the hood outside of the specfile's control into the specfile
(would break if the system rpm is configured to not compress info files at
all or use something else than gzip for compressing them) instead of just
invoking install-info (without the .gz suffix! install-info handles that
internally) on the target info file.
So I suppose the recommended way would call for a macro, let's say
%install_info foo
...which would expand into something like (%1=foo):
for suf in .gz .bz2 "" ; do # + other suffixes auto-handled by install-info
if [ -f %{_infodir}/%1.info$suf ] ; then
/sbin/install-info %{_infodir}/$1.info %{_infodir}/dir || :
break
fi
done
...and a similar one that does install-info --delete for removing it.
From j.w.r.degoede at hhs.nl Tue Mar 11 20:20:51 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 11 Mar 2008 21:20:51 +0100
Subject: [Fedora-packaging] --excludedocs and packaging guidelines?
In-Reply-To: <200803112154.57743.ville.skytta@iki.fi>
References: <47D5F9B2.30707@redhat.com>
<200803112154.57743.ville.skytta@iki.fi>
Message-ID: <47D6E9A3.80803@hhs.nl>
Ville Skytt? wrote:
> On Tuesday 11 March 2008, Warren Togami wrote:
>
>> Furthermore I wonder if there should be any rule or suggestion of how
>> install-info should be used within a %post scriptlet. I see some
>> packages redirect the output of install-info to /dev/null, and
>> install-info's man page also describes a --quiet option. Might we
>> recommend in guidelines the use of this to suppress the warning that
>> happens when a package is installed with --excludedocs?
>
> install-info's --quiet does not suppress errors resulting from files not
> found.
>
> Redirecting stderr to /dev/null sounds a bit draconian to me; testing whether
> the info file exists before invoking install-info would be somewhat better.
>
> But the somewhat annoying part of that is that currently we'd need to test if
> the gzipped info file exists which is hardcoding assumptions about what
> happens under the hood outside of the specfile's control into the specfile
> (would break if the system rpm is configured to not compress info files at
> all or use something else than gzip for compressing them) instead of just
> invoking install-info (without the .gz suffix! install-info handles that
> internally) on the target info file.
>
> So I suppose the recommended way would call for a macro, let's say
>
> %install_info foo
>
> ...which would expand into something like (%1=foo):
>
> for suf in .gz .bz2 "" ; do # + other suffixes auto-handled by install-info
> if [ -f %{_infodir}/%1.info$suf ] ; then
> /sbin/install-info %{_infodir}/$1.info %{_infodir}/dir || :
> break
> fi
> done
>
> ...and a similar one that does install-info --delete for removing it.
>
If we start introducing macro's for common scriplets (which I'm in favor of)
can we then please check how they are called in suse / mandrake and try to use
the same names to make spec file sharing easier?
Regards.
Hans
From notting at redhat.com Tue Mar 11 20:27:54 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 11 Mar 2008 16:27:54 -0400
Subject: [Fedora-packaging] --excludedocs and packaging guidelines?
In-Reply-To: <47D6E9A3.80803@hhs.nl>
References: <47D5F9B2.30707@redhat.com>
<200803112154.57743.ville.skytta@iki.fi> <47D6E9A3.80803@hhs.nl>
Message-ID: <20080311202754.GB17539@nostromo.devel.redhat.com>
Hans de Goede (j.w.r.degoede at hhs.nl) said:
>> ...and a similar one that does install-info --delete for removing it.
>
> If we start introducing macro's for common scriplets (which I'm in favor
> of) can we then please check how they are called in suse / mandrake and try
> to use the same names to make spec file sharing easier?
If we're going to *that* much effort, why not just instrument RPM or yum
to do this sort of thing automatically?
Bill
From j.w.r.degoede at hhs.nl Tue Mar 11 20:30:10 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 11 Mar 2008 21:30:10 +0100
Subject: [Fedora-packaging] --excludedocs and packaging guidelines?
In-Reply-To: <20080311202754.GB17539@nostromo.devel.redhat.com>
References: <47D5F9B2.30707@redhat.com> <200803112154.57743.ville.skytta@iki.fi>
<47D6E9A3.80803@hhs.nl>
<20080311202754.GB17539@nostromo.devel.redhat.com>
Message-ID: <47D6EBD2.9020107@hhs.nl>
Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said:
>>> ...and a similar one that does install-info --delete for removing it.
>> If we start introducing macro's for common scriplets (which I'm in favor
>> of) can we then please check how they are called in suse / mandrake and try
>> to use the same names to make spec file sharing easier?
>
> If we're going to *that* much effort, why not just instrument RPM or yum
> to do this sort of thing automatically?
>
For certain stuff:
-ld.so.cache
-icon-cache
Teaching rpm todo this would actually be a very good idea, esp. because it also
will be a huge performance win, since these caches then only need to be updated
once in a 20 package install instead of doing the update once for every package.
Regards,
Hans
From mefoster at gmail.com Wed Mar 12 13:28:15 2008
From: mefoster at gmail.com (Mary Ellen Foster)
Date: Wed, 12 Mar 2008 14:28:15 +0100
Subject: [Fedora-packaging] rpaths to libraries in non-standard locations
(libperl.so in particular)
In-Reply-To: <1205162360.2956.116.camel@localhost.localdomain>
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
<20080310151406.GA27079@onizuka.greysector.net>
<1205162360.2956.116.camel@localhost.localdomain>
Message-ID:
On 10/03/2008, Tom spot Callaway wrote:
> On Mon, 2008-03-10 at 16:14 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > On Monday, 10 March 2008 at 15:24, Rex Dieter wrote:
> > > > On the other hand, maybe I should be allowed to
> > > > include an rpath in this situation because I really always want to be
> > > > linked to that particular libperl.so
> > >
> > > This is a case where rpath usage is acceptable, imo.
> >
> > I wonder why libperl is not a proper library then. I see that it has no SONAME.
> > Are there any plans upstream to make it a proper library?
>
> Not that I'm aware of. IMHO, this is a valid rpath exception case.
Does this also hold for Java native packages that need libjava.so and
its friends (which are under /usr/lib/jvm/java/.../$arch/...) ?
MEF
--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen
and ICCS, School of Informatics, University of Edinburgh
From tcallawa at redhat.com Wed Mar 12 13:53:09 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 12 Mar 2008 09:53:09 -0400
Subject: [Fedora-packaging] rpaths to libraries in non-standard
locations (libperl.so in particular)
In-Reply-To:
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
<20080310151406.GA27079@onizuka.greysector.net>
<1205162360.2956.116.camel@localhost.localdomain>
Message-ID: <1205329989.2998.15.camel@localhost.localdomain>
On Wed, 2008-03-12 at 14:28 +0100, Mary Ellen Foster wrote:
> On 10/03/2008, Tom spot Callaway wrote:
> > On Mon, 2008-03-10 at 16:14 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > > On Monday, 10 March 2008 at 15:24, Rex Dieter wrote:
> > > > > On the other hand, maybe I should be allowed to
> > > > > include an rpath in this situation because I really always want to be
> > > > > linked to that particular libperl.so
> > > >
> > > > This is a case where rpath usage is acceptable, imo.
> > >
> > > I wonder why libperl is not a proper library then. I see that it has no SONAME.
> > > Are there any plans upstream to make it a proper library?
> >
> > Not that I'm aware of. IMHO, this is a valid rpath exception case.
>
> Does this also hold for Java native packages that need libjava.so and
> its friends (which are under /usr/lib/jvm/java/.../$arch/...) ?
Maybe. I'm not a java expert at all. Might be something to keep in mind
for the folks drafting the Java guidelines.
~spot
From dominik at greysector.net Wed Mar 12 14:18:22 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 12 Mar 2008 15:18:22 +0100
Subject: [Fedora-packaging] rpaths to libraries in non-standard
locations (libperl.so in particular)
In-Reply-To: <1205329989.2998.15.camel@localhost.localdomain>
References: <20080310141337.GA1801@amd.home.annexia.org>
<47D544A8.3040703@math.unl.edu>
<20080310151406.GA27079@onizuka.greysector.net>
<1205162360.2956.116.camel@localhost.localdomain>
<1205329989.2998.15.camel@localhost.localdomain>
Message-ID: <20080312141822.GA3379@ryvius.greysector.net>
On Wednesday, 12 March 2008 at 14:53, Tom spot Callaway wrote:
> On Wed, 2008-03-12 at 14:28 +0100, Mary Ellen Foster wrote:
> > On 10/03/2008, Tom spot Callaway wrote:
> > > On Mon, 2008-03-10 at 16:14 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > > > On Monday, 10 March 2008 at 15:24, Rex Dieter wrote:
> > > > > > On the other hand, maybe I should be allowed to
> > > > > > include an rpath in this situation because I really always want to be
> > > > > > linked to that particular libperl.so
> > > > >
> > > > > This is a case where rpath usage is acceptable, imo.
> > > >
> > > > I wonder why libperl is not a proper library then. I see that it has no SONAME.
> > > > Are there any plans upstream to make it a proper library?
> > >
> > > Not that I'm aware of. IMHO, this is a valid rpath exception case.
> >
> > Does this also hold for Java native packages that need libjava.so and
> > its friends (which are under /usr/lib/jvm/java/.../$arch/...) ?
>
> Maybe. I'm not a java expert at all. Might be something to keep in mind
> for the folks drafting the Java guidelines.
Should we add a note to the general guidelines that exceptions to "no rpath"
rule might be possible in special cases like perl?
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
From tibbs at math.uh.edu Thu Mar 13 18:19:28 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 13 Mar 2008 13:19:28 -0500
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
Message-ID:
During the FESCo meeting, there was some question with regards to
ocaml multilib-osity-ness. I will admit to not fully understanding
what's up here, but can we address this and either fix it or provide
some response to fesco to assuage their concerns?
Here's the relevant portion of the IRC log from the FESCo meeting:
[13:01] *** bpepple sets the channel topic to "FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-March/msg00995.html".
[13:01] dwmw2_AVF, and i'm guessing it's probably not enough ;)
[13:01] * notting is here
[13:01] FPC had proposals for Ocaml and tcl. any objections to them?
[13:01] no objections here.
[13:01] no
[13:01] no
[13:01] none here either.
[13:01] caillon: about 100 merkinpesos
[13:01] ocaml packages require: ocaml
[13:02] library packages, I mean
[13:02] not ocaml of the same arch
[13:02] * nirik is fine with the ocaml guidelines.
[13:02] * bpepple notes that jeremy didn't have any objections either.
[13:02] I think they should require ocaml of the _same_ arch.
[13:02] otherwise it's broken
[13:02] other than that, fine,.
[13:02] --> giallu has joined this channel (n=giallu at 81-174-9-68.dynamic.ngi.it).
[13:03] "Rationale: OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes)."
[13:03] wow, quality.
[13:03] it's because of the way interprocedural optimisation happen, iirc.
[13:03] <-- peters-tx has left this server ("Leaving").
[13:04] Yeah, ocaml is rather messed up.
[13:04] if they fix it to require stuff of the correct arch, fine. Else, -1 broken.
[13:04] dwmw2_AVF: How can you do arch-specific requires?
[13:04] RPM doesn't actually support that.
[13:04] fix one of the rpm bugs on the multilib tracker :)
[13:04] or virtual provides
[13:05] * dgilmore is here
[13:05] I can send it back to the submitter, I guess.
[13:05] does ocamel even get multilibbed?
[13:06] it has various libraries and accompanying devel subpackages
[13:06] <-- Renault has left this server (Remote closed the connection).
[13:07] main ocaml itself isn't multilib it seems like... but some ocaml packages are.
[13:07] so it doesn't do any automagic arch specific requires/provides like c libraries do?
[13:08] --> Renault has joined this channel (n=couretca at AToulon-151-1-147-206.w86-209.abo.wanadoo.fr).
[13:08] f13: looks to be all hashes
[13:08] no
[13:08] and we don't get the core compiler in both versions either (nor -m32/-m64 support).
[13:08] There is some requires/provides magic, but those are turned on in the individual spec files.
[13:08] ocaml seems to be overly complex
[13:09] I think I'm about to be dragged out for food. I vote for sending this proposal back to have its multilib issues sorted out.
[13:09] I will send a rejection message out to the submitter and fedora-packaging.
[13:09] yeah, seems like a trap
[13:09] I accidentally wrote a ppc64 back end for its compiler. It's _definitely_ complex :)
[13:09] 'accidentally'?
[13:09] tibbs: cool. thanks.
[13:10] Do note also that these were merely alteration to existing ocaml guidelines.
[13:10] tibbs: will do.
[13:10] I don't think the original, accepted guidelines are any better on this issue.
[13:10] dwmw2_AVF: you should write a sparc64 one also :)
[13:11] So we're basically rejecting good changes because the original document has something that someone doesn't like.
[13:11] Which is... kind of backwards.
[13:11] I don't mind approving it with a "please improve it further" comment
[13:11] we can accept the fixes, but we should ask them to also go off and fix our issues
[13:11] if it's considered progress
[13:11] +0
From rjones at redhat.com Thu Mar 13 18:46:37 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 13 Mar 2008 18:46:37 +0000
Subject: [Fedora-packaging] Re: FESCo notes on OCaml guidelines change
In-Reply-To:
References:
Message-ID: <20080313184637.GA10411@amd.home.annexia.org>
On Thu, Mar 13, 2008 at 01:19:28PM -0500, Jason L Tibbitts III wrote:
> During the FESCo meeting, there was some question with regards to
> ocaml multilib-osity-ness. I will admit to not fully understanding
> what's up here, but can we address this and either fix it or provide
> some response to fesco to assuage their concerns?
Yes, I just read through this and to be honest I don't understand
exactly what the issue is. I turn off multilib on all the machines I
manage by excluding *.i?86 packages -- it causes more trouble than
it's worth.
My only general remark is this: It is _always_ preferred to build 64
bit binaries in OCaml if possible, even on reasonable architectures
like ppc64 where there are no extra registers. The reason is to do
with the maximum length of strings and arrays which is a mere 16 MB on
32 bit archs, effectively unlimited on 64 bit. You can in my
experience easily hit the 16 MB limit doing things like parsing large
XML documents or slurping in files. Upstream have said they won't fix
this because they consider 32 bit architectures as legacy[1] ...
So how should I change the draft to make this clear?
Rich.
[1] http://caml.inria.fr/pub/ml-archives/caml-list/2006/05/564ba833a1e582df77f59ad3e67f0bd3.en.html
PS. "ocaml seems to be overly complex" & other comments. OCaml
emphasises software safety over other concerns. The idea is that
software shouldn't break. I know, it's a novel idea ... If you get to
fly on the Airbus A380, for example, the flight control software was
checked by automatic theorem provers written in OCaml (the code itself
isn't written in OCaml mind you).
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From rdieter at math.unl.edu Thu Mar 13 19:01:56 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 13 Mar 2008 14:01:56 -0500
Subject: [Fedora-packaging] Re: FESCo notes on OCaml guidelines change
References:
Message-ID:
Jason L Tibbitts III wrote:
> During the FESCo meeting, there was some question with regards to
> ocaml multilib-osity-ness. I will admit to not fully understanding
> what's up here, but can we address this and either fix it or provide
> some response to fesco to assuage their concerns?
> [13:10] I don't think the original, accepted guidelines are any
better on this issue.
> [13:11] So we're basically rejecting good changes because the
original document has something that someone doesn't like.
> [13:11] Which is... kind of backwards.
The comments weren't relevant directly to what was being voted on, so,
backwards/offtopic +1 here too. ??
-- Rex
From tibbs at math.uh.edu Thu Mar 13 19:12:43 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 13 Mar 2008 14:12:43 -0500
Subject: [Fedora-packaging] Re: FESCo notes on OCaml guidelines change
In-Reply-To:
References:
Message-ID:
>>>>> "RD" == Rex Dieter writes:
RD> The comments weren't relevant directly to what was being voted on,
RD> so, backwards/offtopic +1 here too. ??
I included the entire FESCo discussion on the topic. I'm sorry if you
didn't want to see all of it, but I would rather be criticized for
including too much than for editing something out.
I am really beginning to think that it would be far better for me to
simply not volunteer to summarize these meetings and forward
information between the committees, because either someone doesn't
like the format, someone thinks I included too much, or someone thinks
I included too little.
- J<
From rdieter at math.unl.edu Thu Mar 13 19:18:57 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 13 Mar 2008 14:18:57 -0500
Subject: [Fedora-packaging] Re: FESCo notes on OCaml guidelines change
In-Reply-To:
References:
Message-ID: <47D97E21.5000305@math.unl.edu>
Jason L Tibbitts III wrote:
>>>>>> "RD" == Rex Dieter writes:
>
> RD> The comments weren't relevant directly to what was being voted on,
> RD> so, backwards/offtopic +1 here too. ??
>
> I included the entire FESCo discussion on the topic.
To be clear, I was mostly agreeing with you (I think) in that I consider
the *objections* to be backwards/offtopic to the voting issue as presented.
-- Rex
From tcallawa at redhat.com Thu Mar 13 23:26:29 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 13 Mar 2008 19:26:29 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To:
References:
Message-ID: <1205450789.3179.19.camel@localhost.localdomain>
On Thu, 2008-03-13 at 13:19 -0500, Jason L Tibbitts III wrote:
> I will admit to not fully understanding
> what's up here, but can we address this and either fix it or provide
> some response to fesco to assuage their concerns?
>
Grumble, grumble. I really hate it when dwmw2 uses mostly unrelated
issues as a soapbox.
The simple fact is that we cannot do arch-specific requires without file
dependencies, and since ocaml doesn't "link" to any shared libraries,
we'd be really fudging it here. We could solve the problem by adding a
Requires: %{_libdir}/ocaml on arch-specific ocaml packages, but it will
mean that every ocaml program installs slowly. Or, we could hack around
this with %{_bitsize} macro defines and provides (believe it or not, I'd
actually prefer this).
Either way, I don't think it prevents these updates from going in, and
should be handled as a separate issue.
~spot
From tibbs at math.uh.edu Fri Mar 14 00:34:38 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 13 Mar 2008 19:34:38 -0500
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <1205450789.3179.19.camel@localhost.localdomain>
References:
<1205450789.3179.19.camel@localhost.localdomain>
Message-ID:
>>>>> "TC" == Tom \"spot\" Callaway writes:
TC> Either way, I don't think it prevents these updates from going in,
TC> and should be handled as a separate issue.
I agree, and you'll note that I believe that he was convinced that
this wasn't a new issue with the guidelines changes. (Hence the change
to +0 at the end of the log.)
Of course, we should still try to address the issue. Is there
actually a demonstrable problem here? What can go wrong without some
arch-specific dependencies on the main ocaml package? Can you have
just the 32-bit ocaml installed on a 64-bit machine and install a
64-bit module without rpm/yum complaining about dependency problems or
pulling in the 64-bit ocaml package? (No 64-bit machine I can afford
to screw with at the moment.)
- J<
From tcallawa at redhat.com Fri Mar 14 02:08:16 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 13 Mar 2008 22:08:16 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To:
References:
<1205450789.3179.19.camel@localhost.localdomain>
Message-ID: <1205460496.11075.10.camel@localhost.localdomain>
On Thu, 2008-03-13 at 19:34 -0500, Jason L Tibbitts III wrote:
> Of course, we should still try to address the issue. Is there
> actually a demonstrable problem here? What can go wrong without some
> arch-specific dependencies on the main ocaml package? Can you have
> just the 32-bit ocaml installed on a 64-bit machine and install a
> 64-bit module without rpm/yum complaining about dependency problems or
> pulling in the 64-bit ocaml package? (No 64-bit machine I can afford
> to screw with at the moment.)
Yes, this is hypothetically possible, see:
[spot at localhost ~]$ rpm -q ocaml-findlib-1.2.1-2.fc9.x86_64 --requires
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(VersionedDependencies) <= 3.0.3-1
/bin/sh
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
ocaml(Array) = aa8e3cd5824f9bb40b93fcd38d0c95b5
ocaml(Big_int) = 992d682669507b99e689b5a2188c0b9a
ocaml(Buffer) = f6cef633ea14963b84b79c4095c63dc3
ocaml(Char) = e98bc9c9e918a84b3c1a5a122d42fac1
ocaml(Consistbl) = 47f9cdffda6ba2de99c8e9f0c0c1b34d
ocaml(Digest) = a5dd2d89492338578de12105e88c803f
ocaml(Env) = 6d0215253b3fde95601c34944cacb607
ocaml(Filename) = 633a1e7f590ff5e95124293dbef3b476
ocaml(Format) = 35fe566f7a37d8991a5c822bd1463949
ocaml(Hashtbl) = 083f2c94b44ff4e0b3220aaea6a783b4
ocaml(Ident) = ba1acc56fc179d27bd55278cbc2abf40
ocaml(Lexing) = b1793496643444d3762dd42bebe2cfe3
ocaml(List) = da1ce9168f0408ff26158af757456948
ocaml(Location) = eed044ad1204a633caad97bdd9048f8c
ocaml(Longident) = 46fb8aad4fb2c12a0f301b02d8139f07
ocaml(Map) = dedde7683d54ae7db1eb97cc868dd047
ocaml(Nat) = 0ea20dd1cc4533fd519b5542a89feb87
ocaml(Num) = cfa2705c9c6d6f5a56b83f91fc630d2a
ocaml(Obj) = 5cfae708052c692ea39d23ed930fd64d
ocaml(Outcometree) = 6674fbd870cb2522aca4d851f3559202
ocaml(Path) = d8bc8e7163bac3a9a0a93f1cb07092d1
ocaml(Pervasives) = 8ba3d1faa24d659525c9025f41fd0c57
ocaml(Primitive) = 43a2770aed8fbcc536ab39d717fe9a7b
ocaml(Printf) = 5dbbf45a03b54e6dbfcf39178d0d6341
ocaml(Ratio) = 7067125cce206dd2bbe93918ba7bdfe9
ocaml(Set) = 7da14e671a035f12386ace3890018ef3
ocaml(Sort) = 089a51dd8ddc078e57acf2f80b7c06f6
ocaml(Stream) = 21a833e12efd34ea0c87d8d9da959809
ocaml(String) = 2c162ab314b2f0a2cfd22d471b2e21ab
ocaml(Sys) = 0da495f5a80f31899139359805318f28
ocaml(Topdirs) = 2d07b01227af22b60aee18498198c35e
ocaml(Toploop) = ead8879d71c4d5137fe5100fdd682a0b
ocaml(Types) = df897aed3fc89c2129322c17067857b8
ocaml(Warnings) = abcb1589615da86f20f475b0ed3bbabc
ocaml(runtime) = 3.10.1
[spot at localhost ~]$ rpm -q ocaml.x86_64 --provides
ocaml(compiler) = 3.10.1
ocaml(Ocamlbuild) = df8d0c74d80342ca6057bad41bde8971
ocaml(Ocamlbuild_executor) = 846552307267a7beccbeafa1f378a030
ocaml(Ocamlbuild_pack) = 70dd242c6e6bb93e89d226308888f9ba
ocaml(Ocamlbuild_plugin) = 14eaca3963ed1f73c1da0680370a802c
ocaml(Ocamlbuild_unix_plugin) = 91f524a8cc2f4e0cd69f3ef83c774116
ocaml = 3.10.1-2.fc9
So, ocaml.i386 would resolve this dependency just as well as
ocaml.x86_64, but I doubt it would work. yum is going to try to resolve
this dependency with the ocaml.x86_64 by default, but if you had somehow
manually installed ocaml.i386 only, it would then install ocaml addons
as x86_64 packages.
~spot
From tibbs at math.uh.edu Fri Mar 14 03:53:19 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 13 Mar 2008 22:53:19 -0500
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <1205460496.11075.10.camel@localhost.localdomain>
References:
<1205450789.3179.19.camel@localhost.localdomain>
<1205460496.11075.10.camel@localhost.localdomain>
Message-ID:
I guess I'm really having trouble coming to grips with multilib,
because I see that the ocaml modules are not multilib while the -devel
packages are. In fact, the only ocaml i386 packages I see in current
rawhide x86_64 are -devel packages of modules. Is something broken
with the rawhide repo generation, am I just confused as to how you
could ever install those -devel modules without matching arch versions
of the non-devel packages, or are we perhaps seeing the problem under
discussion in action?
- J<
From notting at redhat.com Fri Mar 14 04:13:52 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Mar 2008 00:13:52 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To:
References:
<1205450789.3179.19.camel@localhost.localdomain>
<1205460496.11075.10.camel@localhost.localdomain>
Message-ID: <20080314041352.GA17564@nostromo.devel.redhat.com>
Jason L Tibbitts III (tibbs at math.uh.edu) said:
> I guess I'm really having trouble coming to grips with multilib,
> because I see that the ocaml modules are not multilib while the -devel
> packages are. In fact, the only ocaml i386 packages I see in current
> rawhide x86_64 are -devel packages of modules. Is something broken
> with the rawhide repo generation, am I just confused as to how you
> could ever install those -devel modules without matching arch versions
> of the non-devel packages, or are we perhaps seeing the problem under
> discussion in action?
Packages are pulled in as multilib either from being named -devel,
or bevcause they package something obviously determinable as a 'library'.
I suspect the modules don't appear to be libraries.
Bill
From cra at WPI.EDU Fri Mar 14 04:25:49 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 14 Mar 2008 00:25:49 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <20080314041352.GA17564@nostromo.devel.redhat.com>
References:
<1205450789.3179.19.camel@localhost.localdomain>
<1205460496.11075.10.camel@localhost.localdomain>
<20080314041352.GA17564@nostromo.devel.redhat.com>
Message-ID: <20080314042549.GR19936@angus.ind.WPI.EDU>
On Fri, Mar 14, 2008 at 12:13:52AM -0400, Bill Nottingham wrote:
> Jason L Tibbitts III (tibbs at math.uh.edu) said:
> > I guess I'm really having trouble coming to grips with multilib,
> > because I see that the ocaml modules are not multilib while the -devel
> > packages are. In fact, the only ocaml i386 packages I see in current
> > rawhide x86_64 are -devel packages of modules. Is something broken
> > with the rawhide repo generation, am I just confused as to how you
> > could ever install those -devel modules without matching arch versions
> > of the non-devel packages, or are we perhaps seeing the problem under
> > discussion in action?
>
> Packages are pulled in as multilib either from being named -devel,
> or bevcause they package something obviously determinable as a 'library'.
>
> I suspect the modules don't appear to be libraries.
Is there something wrong with the process that pulls in multilib then?
sane-backends-libs-gphoto2 x86_64 repo deps have been broken for a
long time due to missing the i386 package in the x86_64 repo. For
reference, here are the contents of the two packages:
>rpm -qvpl sane-backends-libs-gphoto2-1.0.19-7.fc9.x86_64.rpm
lrwxrwxrwx 1 root root 25 Mar 10 12:53 /usr/lib64/sane/libsane-gphoto2.so.1 -> libsane-gphoto2.so.1.0.19
-rwxr-xr-x 1 root root 37248 Mar 10 12:53 /usr/lib64/sane/libsane-gphoto2.so.1.0.19
>rpm -qvpl sane-backends-libs-gphoto2-1.0.19-7.fc9.i386.rpm
lrwxrwxrwx 1 root root 25 Mar 10 12:58 /usr/lib/sane/libsane-gphoto2.so.1 -> libsane-gphoto2.so.1.0.19
-rwxr-xr-x 1 root root 33772 Mar 10 12:58 /usr/lib/sane/libsane-gphoto2.so.1.0.19
From notting at redhat.com Fri Mar 14 04:28:55 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Mar 2008 00:28:55 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <20080314042549.GR19936@angus.ind.WPI.EDU>
References:
<1205450789.3179.19.camel@localhost.localdomain>
<1205460496.11075.10.camel@localhost.localdomain>
<20080314041352.GA17564@nostromo.devel.redhat.com>
<20080314042549.GR19936@angus.ind.WPI.EDU>
Message-ID: <20080314042855.GA19198@nostromo.devel.redhat.com>
Chuck Anderson (cra at WPI.EDU) said:
> Is there something wrong with the process that pulls in multilib then?
> sane-backends-libs-gphoto2 x86_64 repo deps have been broken for a
> long time due to missing the i386 package in the x86_64 repo. For
> reference, here are the contents of the two packages:
Those aren't in the system directories, so they're not considered.
Only things in /usr/{lib,lib64}, or in a package that contains a
ld.so.conf.d file, are pulled in.
Bill
From j.w.r.degoede at hhs.nl Fri Mar 14 07:50:48 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 14 Mar 2008 08:50:48 +0100
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <1205460496.11075.10.camel@localhost.localdomain>
References: <1205450789.3179.19.camel@localhost.localdomain>
<1205460496.11075.10.camel@localhost.localdomain>
Message-ID: <47DA2E58.5070502@hhs.nl>
Tom "spot" Callaway wrote:
> On Thu, 2008-03-13 at 19:34 -0500, Jason L Tibbitts III wrote:
>
>> Of course, we should still try to address the issue. Is there
>> actually a demonstrable problem here? What can go wrong without some
>> arch-specific dependencies on the main ocaml package? Can you have
>> just the 32-bit ocaml installed on a 64-bit machine and install a
>> 64-bit module without rpm/yum complaining about dependency problems or
>> pulling in the 64-bit ocaml package? (No 64-bit machine I can afford
>> to screw with at the moment.)
>
> Yes, this is hypothetically possible, see:
>
> [spot at localhost ~]$ rpm -q ocaml-findlib-1.2.1-2.fc9.x86_64 --requires
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(VersionedDependencies) <= 3.0.3-1
> /bin/sh
> libc.so.6()(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libc.so.6(GLIBC_2.3)(64bit)
> libc.so.6(GLIBC_2.3.4)(64bit)
> libc.so.6(GLIBC_2.4)(64bit)
> libdl.so.2()(64bit)
> libdl.so.2(GLIBC_2.2.5)(64bit)
> libm.so.6()(64bit)
> libm.so.6(GLIBC_2.2.5)(64bit)
> ocaml(Array) = aa8e3cd5824f9bb40b93fcd38d0c95b5
> ocaml(Big_int) = 992d682669507b99e689b5a2188c0b9a
> ocaml(Buffer) = f6cef633ea14963b84b79c4095c63dc3
> ocaml(Char) = e98bc9c9e918a84b3c1a5a122d42fac1
> ocaml(Consistbl) = 47f9cdffda6ba2de99c8e9f0c0c1b34d
> ocaml(Digest) = a5dd2d89492338578de12105e88c803f
> ocaml(Env) = 6d0215253b3fde95601c34944cacb607
> ocaml(Filename) = 633a1e7f590ff5e95124293dbef3b476
> ocaml(Format) = 35fe566f7a37d8991a5c822bd1463949
> ocaml(Hashtbl) = 083f2c94b44ff4e0b3220aaea6a783b4
> ocaml(Ident) = ba1acc56fc179d27bd55278cbc2abf40
> ocaml(Lexing) = b1793496643444d3762dd42bebe2cfe3
> ocaml(List) = da1ce9168f0408ff26158af757456948
> ocaml(Location) = eed044ad1204a633caad97bdd9048f8c
> ocaml(Longident) = 46fb8aad4fb2c12a0f301b02d8139f07
> ocaml(Map) = dedde7683d54ae7db1eb97cc868dd047
> ocaml(Nat) = 0ea20dd1cc4533fd519b5542a89feb87
> ocaml(Num) = cfa2705c9c6d6f5a56b83f91fc630d2a
> ocaml(Obj) = 5cfae708052c692ea39d23ed930fd64d
> ocaml(Outcometree) = 6674fbd870cb2522aca4d851f3559202
> ocaml(Path) = d8bc8e7163bac3a9a0a93f1cb07092d1
> ocaml(Pervasives) = 8ba3d1faa24d659525c9025f41fd0c57
> ocaml(Primitive) = 43a2770aed8fbcc536ab39d717fe9a7b
> ocaml(Printf) = 5dbbf45a03b54e6dbfcf39178d0d6341
> ocaml(Ratio) = 7067125cce206dd2bbe93918ba7bdfe9
> ocaml(Set) = 7da14e671a035f12386ace3890018ef3
> ocaml(Sort) = 089a51dd8ddc078e57acf2f80b7c06f6
> ocaml(Stream) = 21a833e12efd34ea0c87d8d9da959809
> ocaml(String) = 2c162ab314b2f0a2cfd22d471b2e21ab
> ocaml(Sys) = 0da495f5a80f31899139359805318f28
> ocaml(Topdirs) = 2d07b01227af22b60aee18498198c35e
> ocaml(Toploop) = ead8879d71c4d5137fe5100fdd682a0b
> ocaml(Types) = df897aed3fc89c2129322c17067857b8
> ocaml(Warnings) = abcb1589615da86f20f475b0ed3bbabc
> ocaml(runtime) = 3.10.1
>
> [spot at localhost ~]$ rpm -q ocaml.x86_64 --provides
> ocaml(compiler) = 3.10.1
> ocaml(Ocamlbuild) = df8d0c74d80342ca6057bad41bde8971
> ocaml(Ocamlbuild_executor) = 846552307267a7beccbeafa1f378a030
> ocaml(Ocamlbuild_pack) = 70dd242c6e6bb93e89d226308888f9ba
> ocaml(Ocamlbuild_plugin) = 14eaca3963ed1f73c1da0680370a802c
> ocaml(Ocamlbuild_unix_plugin) = 91f524a8cc2f4e0cd69f3ef83c774116
> ocaml = 3.10.1-2.fc9
>
> So, ocaml.i386 would resolve this dependency just as well as
> ocaml.x86_64, but I doubt it would work. yum is going to try to resolve
> this dependency with the ocaml.x86_64 by default, but if you had somehow
> manually installed ocaml.i386 only, it would then install ocaml addons
> as x86_64 packages.
>
Proposal for a simple fix: don't make ocaml multilib, so the x86_64 repo should
only contsain x86_64 ocaml packages.
This can simply be fixed by blacklisting all ocaml-*-devel packages from having
their i386 version dragged in in a multilib repo composition, AFAIK just
blacklisting the ocaml-*-devel packages should be enough to get an x86_64 repo
with only 64 bits ocamls stuff.
Regards,
Hans
From rjones at redhat.com Fri Mar 14 08:22:43 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 14 Mar 2008 08:22:43 +0000
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <1205450789.3179.19.camel@localhost.localdomain>
References:
<1205450789.3179.19.camel@localhost.localdomain>
Message-ID: <20080314082243.GA23617@amd.home.annexia.org>
On Thu, Mar 13, 2008 at 07:26:29PM -0400, Tom spot Callaway wrote:
> The simple fact is that we cannot do arch-specific requires without file
> dependencies, and since ocaml doesn't "link" to any shared libraries,
I don't know if this is relevant, but OCaml programs do link to C
shared libraries, eg:
$ ldd /usr/bin/virt-top
libvirt.so.0 => /home/rjones/local/lib/libvirt.so.0 (0x00002aaaaaad3000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x0000003b9be00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003b87400000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003b87800000)
libc.so.6 => /lib64/libc.so.6 (0x0000003b87000000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003b94a00000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x000000374d400000)
libz.so.1 => /lib64/libz.so.1 (0x0000003b88000000)
libgnutls.so.13 => /usr/lib64/libgnutls.so.13 (0x0000003b9de00000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x000000365b400000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003babe00000)
libxenstore.so.3.0 => /usr/lib64/libxenstore.so.3.0 (0x000000367cc00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003b85e00000)
libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x0000003b9d600000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x0000003b9d200000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003b90e00000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003b92600000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003b87c00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003b8f600000)
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From rjones at redhat.com Fri Mar 14 09:07:38 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 14 Mar 2008 09:07:38 +0000
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To:
References:
<1205450789.3179.19.camel@localhost.localdomain>
Message-ID: <20080314090738.GB23617@amd.home.annexia.org>
On Thu, Mar 13, 2008 at 07:34:38PM -0500, Jason L Tibbitts III wrote:
> Of course, we should still try to address the issue. Is there
> actually a demonstrable problem here? What can go wrong without some
> arch-specific dependencies on the main ocaml package? Can you have
> just the 32-bit ocaml installed on a 64-bit machine and install a
> 64-bit module without rpm/yum complaining about dependency problems or
> pulling in the 64-bit ocaml package? (No 64-bit machine I can afford
> to screw with at the moment.)
I think I'm starting to understand the problem here. Take as an
example the ocaml-curses library.
The Rawhide repository[1] contains three packages related to this
library:
ocaml-curses-0.1-7.20020319.fc9.x86_64.rpm
ocaml-curses-devel-0.1-7.20020319.fc9.i386.rpm
ocaml-curses-devel-0.1-7.20020319.fc9.x86_64.rpm
The ocaml-curses-devel.i386 RPM is completely useless. The base OCaml
compiler would never even get so far as to look in its install
directory /usr/lib, because it is configured to always look in
/usr/lib64. There is no concept of the -m32/-m64 switch as in gcc.
It will always build only a single type of binary.
The way the dependencies are set up, the user could request
ocaml-curses-devel.i386 (they'd have to request it explicitly on
x86-64, presumably implicitly on ppc64??) and yum would install
ocaml-curses-devel.i386, ocaml-curses.x86_64 and ocaml.x86_64 [2].
This would not give them a working curses development environment.
For that they'd need ocaml-curses-devel.x86_64.
I don't understand how to exclude or remove those i386 packages from
being built and placed in the repository, but if you give me some clue
I can update the guidelines appropriately.
Rich.
[1] http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os/Packages/
[2] Tested on a Rawhide machine:
# yum install ocaml-curses-devel.i386
development 100% |=========================| 2.4 kB 00:00
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package ocaml-curses-devel.i386 0:0.1-7.20020319.fc9 set to be updated
--> Processing Dependency: ocaml-curses = 0.1-7.20020319.fc9 for package: ocaml-curses-devel
--> Running transaction check
---> Package ocaml-curses.x86_64 0:0.1-7.20020319.fc9 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================
Package Arch Version Repository Size
=============================================================================
Installing:
ocaml-curses-devel i386 0.1-7.20020319.fc9 development 39 k
Installing for dependencies:
ocaml-curses x86_64 0.1-7.20020319.fc9 development 56 k
Transaction Summary
=============================================================================
Install 2 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 95 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): ocaml-curses-devel 100% |=========================| 39 kB 00:00
(2/2): ocaml-curses-0.1-7 100% |=========================| 56 kB 00:00
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing: ocaml-curses ######################### [1/2]
error: failed to stat /home/rjones/.gvfs: Permission denied
Installing: ocaml-curses-devel ######################### [2/2]
Installed: ocaml-curses-devel.i386 0:0.1-7.20020319.fc9
Dependency Installed: ocaml-curses.x86_64 0:0.1-7.20020319.fc9
Complete!
# rpm -qa | grep ocaml-curses
ocaml-curses-devel-0.1-7.20020319.fc9.i386
ocaml-curses-0.1-7.20020319.fc9.x86_64
Note that the native code compiler can't find curses:
$ cat test.ml
open Curses ;; initscr ()
$ ocamlc -I +curses mlcurses.cma test.ml -o test
$ ocamlopt -I +curses mlcurses.cmxa test.ml -o test
Cannot find file mlcurses.cmxa <---- broken!
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From rdieter at math.unl.edu Fri Mar 14 14:12:59 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 14 Mar 2008 09:12:59 -0500
Subject: [Fedora-packaging] Re: RFC: mass rebuild results
References: <47DA8FBC.6040503@redhat.com>
Message-ID:
Karsten Hopp wrote:
> In my opinion rebuilding packages outside of mock should give me packages
> with the same features than the original ones.
Not a 100% reasonable expectation, imo (esp when on a multilib'd buildhost).
That's part of the point of using the minimalist buildroots that mock
provides.
> Should I even bother to start filing the most obvious bugs
Yes(!), especially if your rebuilds highlights missing parts (functionality,
documentation, etc...).
-- Rex
From ivazqueznet at gmail.com Fri Mar 14 14:24:50 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 14 Mar 2008 10:24:50 -0400
Subject: [Fedora-packaging] Re: RFC: mass rebuild results
In-Reply-To:
References: <47DA8FBC.6040503@redhat.com>
Message-ID: <1205504690.8284.60.camel@ignacio.lan>
On Fri, 2008-03-14 at 09:12 -0500, Rex Dieter wrote:
> Karsten Hopp wrote:
>
>
> > In my opinion rebuilding packages outside of mock should give me packages
> > with the same features than the original ones.
>
> Not a 100% reasonable expectation, imo (esp when on a multilib'd buildhost).
> That's part of the point of using the minimalist buildroots that mock
> provides.
>
> > Should I even bother to start filing the most obvious bugs
>
> Yes(!), especially if your rebuilds highlights missing parts (functionality,
> documentation, etc...).
I was going to write a long and winding followup to the original post,
but I think the following response to this post sums up my position:
+1
--
Ignacio Vazquez-Abrams
PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From tcallawa at redhat.com Fri Mar 14 20:10:26 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 14 Mar 2008 16:10:26 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <20080314082243.GA23617@amd.home.annexia.org>
References:
<1205450789.3179.19.camel@localhost.localdomain>
<20080314082243.GA23617@amd.home.annexia.org>
Message-ID: <1205525426.2850.0.camel@localhost.localdomain>
On Fri, 2008-03-14 at 08:22 +0000, Richard W.M. Jones wrote:
> On Thu, Mar 13, 2008 at 07:26:29PM -0400, Tom spot Callaway wrote:
> > The simple fact is that we cannot do arch-specific requires without file
> > dependencies, and since ocaml doesn't "link" to any shared libraries,
>
> I don't know if this is relevant, but OCaml programs do link to C
> shared libraries, eg:
Yes, but it doesn't link to any "ocaml" provided shared libraries.
~spot
From pmatilai at laiskiainen.org Sat Mar 15 15:46:12 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 15 Mar 2008 17:46:12 +0200 (EET)
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <1205450789.3179.19.camel@localhost.localdomain>
References:
<1205450789.3179.19.camel@localhost.localdomain>
Message-ID:
On Thu, 13 Mar 2008, Tom \spot\ Callaway wrote:
> On Thu, 2008-03-13 at 13:19 -0500, Jason L Tibbitts III wrote:
>> I will admit to not fully understanding
>> what's up here, but can we address this and either fix it or provide
>> some response to fesco to assuage their concerns?
>>
> Grumble, grumble. I really hate it when dwmw2 uses mostly unrelated
> issues as a soapbox.
>
> The simple fact is that we cannot do arch-specific requires without file
> dependencies, and since ocaml doesn't "link" to any shared libraries,
Ooh, my favorite subject... (in general, not just ocaml)
> we'd be really fudging it here. We could solve the problem by adding a
> Requires: %{_libdir}/ocaml on arch-specific ocaml packages, but it will
> mean that every ocaml program installs slowly. Or, we could hack around
> this with %{_bitsize} macro defines and provides (believe it or not, I'd
> actually prefer this).
I think the size of a bit (bitsize) is always one, no? :)
This is precisely my hangup (as silly as it is) with adding
"bitness-specific" requires to rpm - nobody has come up with a *good* name
for it. Good as in "Oh yes, that's it! How come I didn't think of that!"
We'll be stuck with the thing forever once introduced, so I'd prefer
something I like over something I can kinda live with.
%{_bits}, %{_bitness}, %{_bitsize}, %{_wordsize} and similar have been
suggested before. While any of them would work for this purpose, they're
awfully limited in terms of what they express, and make noarch an odd
special case: noarch is not really "zero bits".
Linux kernel uses the term "personality" for this purpose, and *that* is
the type of abstraction I'm after here. It covers a far broader question
than just "how many bits":
- noarch is not a weird special case, it's simply "any personality"
- "How many bits" becomes "matching personality"
- What if next year somebody comes up with a machine that supports x86_64,
x86 and say, ppc32 natively? With just number of bits, you'd be out of
luck trying to express "I want the 32bit ppc package."
Taken a bit further: rpm could add system provides (similar to rpmlib
provides) of the personalities that the hardware natively supports.
Packages build for x86 would depend on the personality they where build
for added automatically. Think of emulators providing the personalities
they support, eg qemu on PPC providing personality(x86).
Or use "abi" instead of "personality", if nothing else it's shorter to
type and covers the same idea.
What the spec etc syntax for that would be I dunno, maybe just
"Requires: foo%{_abi}" which would expand to foo(), eg
foo(ppc32). Or something like that.
Does that make sense to others, or am I just out to luch as usual? ;)
- Panu -
From jkeating at redhat.com Sat Mar 15 16:47:27 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 15 Mar 2008 12:47:27 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To:
References:
<1205450789.3179.19.camel@localhost.localdomain>
Message-ID: <1205599647.3340.35.camel@localhost.localdomain>
On Sat, 2008-03-15 at 17:46 +0200, Panu Matilainen wrote:
>
> Or use "abi" instead of "personality", if nothing else it's shorter to
> type and covers the same idea.
>
> What the spec etc syntax for that would be I dunno, maybe just
> "Requires: foo%{_abi}" which would expand to foo(), eg
> foo(ppc32). Or something like that.
>
> Does that make sense to others, or am I just out to luch as usual? ;)
Well I like personality because it does match other things that are
trying to express the same thing.
I don't like abi because we're already using that for things like
python(abi) to express a certain level of ABI from an application stack
rather than a CPU.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From pmatilai at laiskiainen.org Sat Mar 15 17:32:29 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 15 Mar 2008 19:32:29 +0200 (EET)
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <1205599647.3340.35.camel@localhost.localdomain>
References:
<1205450789.3179.19.camel@localhost.localdomain>
<1205599647.3340.35.camel@localhost.localdomain>
Message-ID:
On Sat, 15 Mar 2008, Jesse Keating wrote:
> On Sat, 2008-03-15 at 17:46 +0200, Panu Matilainen wrote:
>>
>> Or use "abi" instead of "personality", if nothing else it's shorter to
>> type and covers the same idea.
>>
>> What the spec etc syntax for that would be I dunno, maybe just
>> "Requires: foo%{_abi}" which would expand to foo(), eg
>> foo(ppc32). Or something like that.
>>
>> Does that make sense to others, or am I just out to luch as usual? ;)
>
>
> Well I like personality because it does match other things that are
> trying to express the same thing.
>
> I don't like abi because we're already using that for things like
> python(abi) to express a certain level of ABI from an application stack
> rather than a CPU.
Agreed, "abi" is bad, it's much too overloaded with different meanings in
several domains. I'm not hung about "personality" either, but at least
it's a good example of the kind of term I'm shopping for.
- Panu -
From skvidal at fedoraproject.org Sat Mar 15 17:28:26 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 15 Mar 2008 13:28:26 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To:
References:
<1205450789.3179.19.camel@localhost.localdomain>
Message-ID: <1205602106.1816.69.camel@cutter>
On Sat, 2008-03-15 at 17:46 +0200, Panu Matilainen wrote:
> This is precisely my hangup (as silly as it is) with adding
> "bitness-specific" requires to rpm - nobody has come up with a *good* name
> for it. Good as in "Oh yes, that's it! How come I didn't think of that!"
> We'll be stuck with the thing forever once introduced, so I'd prefer
> something I like over something I can kinda live with.
>
> %{_bits}, %{_bitness}, %{_bitsize}, %{_wordsize} and similar have been
> suggested before. While any of them would work for this purpose, they're
> awfully limited in terms of what they express, and make noarch an odd
> special case: noarch is not really "zero bits".
%{_arch_personality}
that let's people know personality doesn't mean 'clever, witty, good
with children'.
-sv
From pmatilai at laiskiainen.org Sun Mar 16 11:09:01 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sun, 16 Mar 2008 13:09:01 +0200 (EET)
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <1205599647.3340.35.camel@localhost.localdomain>
References:
<1205450789.3179.19.camel@localhost.localdomain>
<1205599647.3340.35.camel@localhost.localdomain>
Message-ID:
On Sat, 15 Mar 2008, Jesse Keating wrote:
> On Sat, 2008-03-15 at 17:46 +0200, Panu Matilainen wrote:
>>
>> Or use "abi" instead of "personality", if nothing else it's shorter to
>> type and covers the same idea.
>>
>> What the spec etc syntax for that would be I dunno, maybe just
>> "Requires: foo%{_abi}" which would expand to foo(), eg
>> foo(ppc32). Or something like that.
>>
>> Does that make sense to others, or am I just out to luch as usual? ;)
>
>
> Well I like personality because it does match other things that are
> trying to express the same thing.
>
> I don't like abi because we're already using that for things like
> python(abi) to express a certain level of ABI from an application stack
> rather than a CPU.
Actually... isn't this thing we're talking about called "instruction set
architecture"?
Requires: foo%{_isa}
Now that'd be a compact, to-the-point technical term which doesn't need
extra qualifiers to point out we're not talking about anybody's mental
qualities.
- Panu -
From jkeating at redhat.com Sun Mar 16 12:18:40 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 16 Mar 2008 08:18:40 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To:
References:
<1205450789.3179.19.camel@localhost.localdomain>
<1205599647.3340.35.camel@localhost.localdomain>
Message-ID: <1205669920.3651.2.camel@localhost.localdomain>
On Sun, 2008-03-16 at 13:09 +0200, Panu Matilainen wrote:
>
> Requires: foo%{_isa}
>
> Now that'd be a compact, to-the-point technical term which doesn't need
> extra qualifiers to point out we're not talking about anybody's mental
> qualities.
Yes, but I purged all my ISA machines long ago... (:
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From rpjday at crashcourse.ca Sun Mar 16 16:23:31 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Sun, 16 Mar 2008 12:23:31 -0400 (EDT)
Subject: [Fedora-packaging] any reason why "sdcc" package transforms pgms to
non-standard names?
Message-ID:
i'm not sure if this question is too package-specific for this list,
but i'll take my chances.
for the sake of building "openwrt" on my f8 system, i installed the
"sdcc" (small device c compiler) package. and yet, when i try to
build openwrt, i get:
...
Checking 'sdcc'... failed.
firmwarehotplug: firmwarehotplug requires the SDCC Cross Compiler (sdcc).
...
a quick check of the pre-built tarballs at sdcc.sourceforge.net
shows that the binaries have names like sdcc, sdcpp and so on. but
note the names in the fedora package as installed by yum:
$ rpm -ql sdcc | grep bin
/usr/bin/sdcc-as-gbz80
/usr/bin/sdcc-as-hc08
/usr/bin/sdcc-as-z80
/usr/bin/sdcc-aslink
/usr/bin/sdcc-asx8051
/usr/bin/sdcc-link-gbz80
/usr/bin/sdcc-link-hc08
/usr/bin/sdcc-link-z80
/usr/bin/sdcc-makebin
/usr/bin/sdcc-packihx
/usr/bin/sdcc-s51
/usr/bin/sdcc-savr
/usr/bin/sdcc-sdcc
...
note the additional "sdcc-" prefix that's clearly(?) been added for
the sake of fedora packaging. i'm not sure if this was done to avoid
some sort of name conflict, but it obviously causes the openwrt build
error.
is this kind of transformation relatively common? the build from
the sdcc home page itself uses the regular names, so why is the fedora
packaging rewriting those? does this happen often?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
From tcallawa at redhat.com Sun Mar 16 17:35:30 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sun, 16 Mar 2008 13:35:30 -0400
Subject: [Fedora-packaging] any reason why "sdcc" package transforms
pgms to non-standard names?
In-Reply-To:
References:
Message-ID: <1205688930.3203.0.camel@localhost.localdomain>
On Sun, 2008-03-16 at 12:23 -0400, Robert P. J. Day wrote:
> is this kind of transformation relatively common? the build from
> the sdcc home page itself uses the regular names, so why is the fedora
> packaging rewriting those? does this happen often?
Its not common, nor is it mandated by the packaging guidelines, except
in cases of binary namespace conflicts. I think it would be worthwhile
to ask the sdcc maintainer what the reasoning is for this.
~spot
From tibbs at math.uh.edu Sun Mar 16 17:37:00 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 16 Mar 2008 12:37:00 -0500
Subject: [Fedora-packaging] any reason why "sdcc" package transforms pgms
to non-standard names?
In-Reply-To:
References:
Message-ID:
>>>>> "RPJD" == Robert P J Day writes:
RPJD> is this kind of transformation relatively common?
Yes, it is. See http://fedoraproject.org/wiki/Packaging/Conflicts
We don't generally want packages which conflict because they include
the same binaries; when some package contains any files which are
generically named and located in standard directories. Renaming or
relocation is the standard solution.
Dealing with this situation in a package that depends on things which
have been renamed isn't usually too difficult, although in this case I
don't know what the simplest solution is. One almost wishes for a
directory containing symlinks that you could add to the head of $PATH.
- J<
From j.w.r.degoede at hhs.nl Sun Mar 16 18:25:08 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 16 Mar 2008 19:25:08 +0100
Subject: [Fedora-packaging] any reason why "sdcc" package transforms pgms
to non-standard names?
In-Reply-To:
References:
Message-ID: <47DD6604.6090106@hhs.nl>
Jason L Tibbitts III wrote:
>>>>>> "RPJD" == Robert P J Day writes:
>
> RPJD> is this kind of transformation relatively common?
>
> Yes, it is. See http://fedoraproject.org/wiki/Packaging/Conflicts
>
> We don't generally want packages which conflict because they include
> the same binaries; when some package contains any files which are
> generically named and located in standard directories. Renaming or
> relocation is the standard solution.
>
> Dealing with this situation in a package that depends on things which
> have been renamed isn't usually too difficult, although in this case I
> don't know what the simplest solution is. One almost wishes for a
> directory containing symlinks that you could add to the head of $PATH.
>
And such a directory is a standard part of the Fedora sdcc package:
rpm -ql sdcc
/usr/libexec/sdcc/as-gbz80
/usr/libexec/sdcc/as-hc08
/usr/libexec/sdcc/as-z80
/usr/libexec/sdcc/aslink
/usr/libexec/sdcc/asx8051
/usr/libexec/sdcc/link-gbz80
/usr/libexec/sdcc/link-hc08
/usr/libexec/sdcc/link-z80
/usr/libexec/sdcc/makebin
/usr/libexec/sdcc/packihx
/usr/libexec/sdcc/s51
/usr/libexec/sdcc/savr
/usr/libexec/sdcc/sdcc
/usr/libexec/sdcc/sdcclib
/usr/libexec/sdcc/sdcdb
/usr/libexec/sdcc/sdcpp
/usr/libexec/sdcc/shc08
/usr/libexec/sdcc/sz80
/usr/share/doc/sdcc-2.6.0
/usr/share/doc/sdcc-2.6.0/INSTALL.txt
/usr/share/doc/sdcc-2.6.0/README.fedora
So the solution is to:
1) rtfm, aka README.fedora, where this is described
2) do "export PATH=/usr/libexec/sdcc:$PATH" before trying to build
openwrt and / or add this to your .bashrc
Regards,
Hans
From rpjday at crashcourse.ca Sun Mar 16 18:56:32 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Sun, 16 Mar 2008 14:56:32 -0400 (EDT)
Subject: [Fedora-packaging] any reason why "sdcc" package transforms pgms
to non-standard names?
In-Reply-To: <1205688930.3203.0.camel@localhost.localdomain>
References:
<1205688930.3203.0.camel@localhost.localdomain>
Message-ID:
On Sun, 16 Mar 2008, Tom "spot" Callaway wrote:
> On Sun, 2008-03-16 at 12:23 -0400, Robert P. J. Day wrote:
>
> > is this kind of transformation relatively common? the build
> > from the sdcc home page itself uses the regular names, so why is
> > the fedora packaging rewriting those? does this happen often?
>
> Its not common, nor is it mandated by the packaging guidelines,
> except in cases of binary namespace conflicts. I think it would be
> worthwhile to ask the sdcc maintainer what the reasoning is for
> this.
okeley dokeley. thanks.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
From rpjday at crashcourse.ca Sun Mar 16 19:24:14 2008
From: rpjday at crashcourse.ca (Robert P. J. Day)
Date: Sun, 16 Mar 2008 15:24:14 -0400 (EDT)
Subject: [Fedora-packaging] any reason why "sdcc" package transforms pgms
to non-standard names?
In-Reply-To: <47DD6604.6090106@hhs.nl>
References:
<47DD6604.6090106@hhs.nl>
Message-ID:
On Sun, 16 Mar 2008, Hans de Goede wrote:
> Jason L Tibbitts III wrote:
> > > > > > > "RPJD" == Robert P J Day writes:
> >
> > RPJD> is this kind of transformation relatively common?
> >
> > Yes, it is. See http://fedoraproject.org/wiki/Packaging/Conflicts
> >
> > We don't generally want packages which conflict because they
> > include the same binaries; when some package contains any files
> > which are generically named and located in standard directories.
> > Renaming or relocation is the standard solution.
> >
> > Dealing with this situation in a package that depends on things
> > which have been renamed isn't usually too difficult, although in
> > this case I don't know what the simplest solution is. One almost
> > wishes for a directory containing symlinks that you could add to
> > the head of $PATH.
i assumed something like this was going on. but after a quick check,
i'm still curious:
1) who's the fedora packager for sdcc? "rpm -qi sdcc" doesn't seem to
refer to a particular person. it lists packager simply as "fedora
project."
2) is there a way to find out what package it was conflicting with,
and how? i imagine once i learn who the packager is, that part will
be easy to figure out.
> And such a directory is a standard part of the Fedora sdcc package:
> rpm -ql sdcc
>
> /usr/libexec/sdcc/as-gbz80
> /usr/libexec/sdcc/as-hc08
> /usr/libexec/sdcc/as-z80
> /usr/libexec/sdcc/aslink
> /usr/libexec/sdcc/asx8051
> /usr/libexec/sdcc/link-gbz80
> /usr/libexec/sdcc/link-hc08
> /usr/libexec/sdcc/link-z80
> /usr/libexec/sdcc/makebin
> /usr/libexec/sdcc/packihx
> /usr/libexec/sdcc/s51
> /usr/libexec/sdcc/savr
> /usr/libexec/sdcc/sdcc
> /usr/libexec/sdcc/sdcclib
> /usr/libexec/sdcc/sdcdb
> /usr/libexec/sdcc/sdcpp
> /usr/libexec/sdcc/shc08
> /usr/libexec/sdcc/sz80
> /usr/share/doc/sdcc-2.6.0
> /usr/share/doc/sdcc-2.6.0/INSTALL.txt
> /usr/share/doc/sdcc-2.6.0/README.fedora
>
ah, i hadn't even noticed that. yes, that should solve the problem,
thanks.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
From opensource at till.name Sun Mar 16 19:35:26 2008
From: opensource at till.name (Till Maas)
Date: Sun, 16 Mar 2008 20:35:26 +0100
Subject: [Fedora-packaging] any reason why "sdcc" package transforms pgms
to non-standard names?
In-Reply-To:
References:
<47DD6604.6090106@hhs.nl>
Message-ID: <200803162035.31372.opensource@till.name>
On Sun March 16 2008, Robert P. J. Day wrote:
> i assumed something like this was going on. but after a quick check,
> i'm still curious:
>
> 1) who's the fedora packager for sdcc? "rpm -qi sdcc" doesn't seem to
> refer to a particular person. it lists packager simply as "fedora
> project."
You find this information in the Fedora Package Database:
https://admin.fedoraproject.org/pkgdb/packages/name/sdcc
Or the changelog of the rpm can give you some hints (use --changelog in your
query).
Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL:
From j.w.r.degoede at hhs.nl Sun Mar 16 20:15:11 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 16 Mar 2008 21:15:11 +0100
Subject: [Fedora-packaging] any reason why "sdcc" package transforms pgms
to non-standard names?
In-Reply-To:
References:
<47DD6604.6090106@hhs.nl>
Message-ID: <47DD7FCF.5010507@hhs.nl>
Robert P. J. Day wrote:
>
> 2) is there a way to find out what package it was conflicting with,
> and how? i imagine once i learn who the packager is, that part will
> be easy to figure out.
>
I'm not the packager, but I have reviewed the package when it first hit Fedora,
there were no actual conflicts that I know if, its just that names like
"as-z80" and even more so makebin are just too generic. So we (Trond, the
packager and me) decided it would be better to avoid any possible conflicts
from the start.
Regards,
Hans
From rc040203 at freenet.de Sun Mar 16 16:55:14 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 16 Mar 2008 17:55:14 +0100
Subject: [Fedora-packaging] any reason why "sdcc" package transforms
pgms to non-standard names?
In-Reply-To:
References:
Message-ID: <1205686514.14969.12.camel@beck.corsepiu.local>
On Sun, 2008-03-16 at 12:23 -0400, Robert P. J. Day wrote:
> i'm not sure if this question is too package-specific for this list,
> but i'll take my chances.
>
> for the sake of building "openwrt" on my f8 system, i installed the
> "sdcc" (small device c compiler) package. and yet, when i try to
> build openwrt, i get:
>
> ...
> Checking 'sdcc'... failed.
>
> firmwarehotplug: firmwarehotplug requires the SDCC Cross Compiler (sdcc).
> ...
>
> a quick check of the pre-built tarballs at sdcc.sourceforge.net
> shows that the binaries have names like sdcc, sdcpp and so on. but
> note the names in the fedora package as installed by yum:
>
> $ rpm -ql sdcc | grep bin
> /usr/bin/sdcc-as-gbz80
> /usr/bin/sdcc-as-hc08
> /usr/bin/sdcc-as-z80
> /usr/bin/sdcc-aslink
> /usr/bin/sdcc-asx8051
> /usr/bin/sdcc-link-gbz80
> /usr/bin/sdcc-link-hc08
> /usr/bin/sdcc-link-z80
> /usr/bin/sdcc-makebin
> /usr/bin/sdcc-packihx
> /usr/bin/sdcc-s51
> /usr/bin/sdcc-savr
> /usr/bin/sdcc-sdcc
> ...
>
> note the additional "sdcc-" prefix that's clearly(?) been added for
> the sake of fedora packaging. i'm not sure if this was done to avoid
> some sort of name conflict, but it obviously causes the openwrt build
> error.
I can't comment about this particular case, but ...
> is this kind of transformation relatively common?
Not in Fedora and not necessarily on Linux, in general practice,
however: yes.
It can very often be found on non-linux OS when a tool's name would
clash with "native" tools's names (e.g. make -> gmake).
> the build from
> the sdcc home page itself uses the regular names, so why is the fedora
> packaging rewriting those?
To avoid potential name clashes with other tools.
Things like aslink, makebin are simply too risky (rsp. their names are
unfortunately chosen by sdcc's upstream).
> does this happen often?
No, only when necessary.
Ralf
From notting at redhat.com Mon Mar 17 15:08:33 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 17 Mar 2008 11:08:33 -0400
Subject: [Fedora-packaging] FESCo notes on OCaml guidelines change
In-Reply-To: <1205602106.1816.69.camel@cutter>
References:
<1205450789.3179.19.camel@localhost.localdomain>
<1205602106.1816.69.camel@cutter>
Message-ID: <20080317150833.GM28943@nostromo.devel.redhat.com>
seth vidal (skvidal at fedoraproject.org) said:
> that let's people know personality doesn't mean 'clever, witty, good
> with children'.
Because of course, *that* describes RPM.
Bill
From rjones at redhat.com Tue Mar 18 09:12:14 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 18 Mar 2008 09:12:14 +0000
Subject: [Fedora-packaging] Re: UPDATED: New draft packaging guidelines for
OCaml
In-Reply-To: <1205480992.16203.40.camel@shinybook.infradead.org>
References: <20080301150548.GA10317@amd.home.annexia.org>
<47C97AB2.2080108@hhs.nl>
<20080305181332.GA28092@amd.home.annexia.org>
<1205480992.16203.40.camel@shinybook.infradead.org>
Message-ID: <20080318091214.GA3286@amd.home.annexia.org>
On Fri, Mar 14, 2008 at 08:49:51AM +0100, David Woodhouse wrote:
> It doesn't address multilib. For example, the -devel packages should
> require ocaml of the _same_ architecture, not just "ocaml".
>
> In particular, the example that "ocaml-pcre-devel needs an explicit
> 'Requires: pcre-devel'" is wrong, because an i386 pcre-devel package
> would satisfy that, while not being particularly useful for an x86_64
> ocaml-pcre-devel.
Right -- I now understand the problem. See for example my email here:
https://www.redhat.com/archives/fedora-packaging/2008-March/msg00105.html
What I _don't_ understand is how to fix this ... Obviously bug 235755
("rpm doesn't allow 'Requires: foo.%{ARCH}'") would be an ideal fix.
In the absence of that can someone suggest a workable scheme?
I can add file deps, I think, to solve this:
In ocaml-pcre-devel:
Requires: %{_libdir}/ocaml/pcre/ (get the right ocaml-pcre)
Requires: %{_libdir}/libpcre.a (instead of pcre-devel)
would seem to fix this, at the cost of downloading the filelists.
> Because of bug #235755 you may need to use virtual provides or
> file-based dependencies to express the dependencies correctly.
> Unless we put 235755 on the F9Blocker... :)
For reference:
https://bugzilla.redhat.com/show_bug.cgi?id=235755
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
From pertusus at free.fr Tue Mar 18 22:24:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 18 Mar 2008 23:24:20 +0100
Subject: [Fedora-packaging] a proposal to register virtual provides
Message-ID: <20080318222420.GB2698@free.fr>
Hello,
I propose to have virtual provides mandatorily registered, and to
advertise using parentheses in virtual provides:
http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
This is for discussion, but also for ratification.
--
Pat
From tcallawa at redhat.com Tue Mar 18 22:35:27 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 18 Mar 2008 18:35:27 -0400
Subject: [Fedora-packaging] a proposal to register virtual provides
In-Reply-To: <20080318222420.GB2698@free.fr>
References: <20080318222420.GB2698@free.fr>
Message-ID: <1205879727.3071.34.camel@localhost.localdomain>
On Tue, 2008-03-18 at 23:24 +0100, Patrice Dumas wrote:
> Hello,
>
> I propose to have virtual provides mandatorily registered, and to
> advertise using parentheses in virtual provides:
>
> http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
>
> This is for discussion, but also for ratification.
Thanks for the draft. I've added it to PackagingDrafts/DraftsTodo so it
will be on our agenda. Please remember to add future drafts to that
table!
~spot
From pertusus at free.fr Wed Mar 19 22:13:50 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 19 Mar 2008 23:13:50 +0100
Subject: [Fedora-packaging] crypto in fedora
Message-ID: <20080319221350.GB2635@free.fr>
Hello,
Recently the issue of crypto and crypto export in fedora/EPEL was raised
about beecrypt. This is something that has never been discussed as far
as I remember. It should of course be checked with legal.
My question is, does crypto software need a specific treatement in
fedora? (And if yes, what is a crypto software?)
--
Pat
From tcallawa at redhat.com Wed Mar 19 22:33:01 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 19 Mar 2008 18:33:01 -0400
Subject: [Fedora-packaging] Drafts for next Tuesday
Message-ID: <1205965981.23340.39.camel@localhost.localdomain>
This goes out specifically to the Fedora Packaging Committee Members,
but is certainly open for comments from all.
We've got a lot of drafts that are queued up for next Tuesday's meeting,
so it would be very helpful if you read them all well in advance:
As always, this list is pulled from
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo (which embeds the
table from http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo ):
ASCII Naming Guidelines (spot) :
http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
Perl Guidelines (spot) :
http://fedoraproject.org/wiki/PackagingDrafts/Perl
InitDir location (spot) :
http://fedoraproject.org/wiki/PackagingDrafts/InitDir
Eclipse Plugin Guidelines (spot) :
http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
OpenOffice.org extensions guidelines (Caolan McNamara) :
http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
Secure BuildRoot (Lubomir Kundrak) :
http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
Register VirtualProvides (Patrice Dumas) :
http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
SysV-style Initscript Guidelines (spot) :
http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
I don't have the Java Guidelines draft on the list yet, but I hope that
it will be ready by next Tuesday:
http://fedoraproject.org/wiki/PackagingDrafts/Java
Next Tuesday will undoubtedly be a longer meeting than normal, so please
be prepared.
Thanks,
~spot
From smooge at gmail.com Wed Mar 19 22:48:52 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 19 Mar 2008 16:48:52 -0600
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <20080319221350.GB2635@free.fr>
References: <20080319221350.GB2635@free.fr>
Message-ID: <80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com>
On Wed, Mar 19, 2008 at 4:13 PM, Patrice Dumas wrote:
> Hello,
>
> Recently the issue of crypto and crypto export in fedora/EPEL was raised
> about beecrypt. This is something that has never been discussed as far
> as I remember. It should of course be checked with legal.
>
> My question is, does crypto software need a specific treatement in
> fedora? (And if yes, what is a crypto software?)
>
As far as I know crypto has always needed special treatment in Fedora.
Most encryption software is considered 'controlled' for export by
several nations (I think United States, France, Russia, China, etc).
What Red Hat has to do is fill out paperwork with the United States
Commerce department whenever new software with encryption is added to
Fedora or RHEL. This paperwork is on file and then allows various
mirrors to get the software though if inside the US they are required
to put up a listing like:
230-Due to U.S. Exports Regulations, all cryptographic software on this
230-site is subject to the following legal notice:
230-
230- This site includes publicly available encryption source code
230- which, together with object code resulting from the compiling of
230- publicly available source code, may be exported from the United
230- States under License Exception "TSU" pursuant to 15 C.F.R. Section
230- 740.13(e).
230-
230-This legal notice applies to cryptographic software only. Please see
230-the Bureau of Export Administration (http://www.bxa.doc.gov/) for more
230-information about current U.S. regulations.
like mirrors.kernel.org. I have been told that similar rules are in
place for other countries dealing with encryption.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
From notting at redhat.com Thu Mar 20 02:58:01 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 19 Mar 2008 22:58:01 -0400
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205965981.23340.39.camel@localhost.localdomain>
References: <1205965981.23340.39.camel@localhost.localdomain>
Message-ID: <20080320025801.GC21237@nostromo.devel.redhat.com>
Tom spot Callaway (tcallawa at redhat.com) said:
> InitDir location (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/InitDir
Should this just be merged into the later draft?
> SysV-style Initscript Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
Sooooooooo....
1) I'm of the opinion that LSB headers should be optional. There is no
requirement in the LSB for any system scripts to be LSB compliant, and
it can cause issues with ordering.
2) Various times it is stated that:
...
Note: Fedora's init daemons (sysvinit, upstart) do not currently use
non-system boot facilities defined in the line when ordering
initscripts. Fedora packagers must ensure that they have priority ordering
set correctly in the chkconfig header.
...
This is incorrect. What happens is that on script enablement (chkconfig --add)
and script activation/deactivation (chkconfig on/chkconfig off) the LSB
dependencies are read, and the start and stop priorities of the scripts
are then adjusted to satisfy those dependencies.
What this means:
- dependencies are honored (albeit in a static mechanism)
- if you use LSB headers, your start and stop priority may end up being
different than what's in the chkconfig: line
This is the same for both upstart (as it is implemented now) and sysvinit.
3) Standardizing on try-restart when we have generally accepted use of
'condrestart' seems problematic.
Bill
From rc040203 at freenet.de Thu Mar 20 03:52:15 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 20 Mar 2008 04:52:15 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205965981.23340.39.camel@localhost.localdomain>
References: <1205965981.23340.39.camel@localhost.localdomain>
Message-ID: <1205985135.14969.310.camel@beck.corsepiu.local>
On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
> This goes out specifically to the Fedora Packaging Committee Members,
> but is certainly open for comments from all.
>
> We've got a lot of drafts that are queued up for next Tuesday's meeting,
> so it would be very helpful if you read them all well in advance:
>
> As always, this list is pulled from
> http://fedoraproject.org/wiki/Packaging/GuidelinesTodo (which embeds the
> table from http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo ):
>
> ASCII Naming Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
IMO, this proposal is not strict enough.
1. I think, we need to restrict package names to
a-z, A-Z, 0-9, -, _
cf.:
http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.5._Name_Tag
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Package
2. I do not agree to the "When Upstream Naming is outside ..." section.
This section is unnecessarily/avoidable adding confusion for
maintainers. Non-ASCII names have always been banned rsp. technically
impossible ever since Linux exists => this is a non-issue.
> Perl Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/Perl
> InitDir location (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/InitDir
> Eclipse Plugin Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
> OpenOffice.org extensions guidelines (Caolan McNamara) :
> http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
> Secure BuildRoot (Lubomir Kundrak) :
> http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
> Register VirtualProvides (Patrice Dumas) :
> http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
> SysV-style Initscript Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
>
> I don't have the Java Guidelines draft on the list yet, but I hope that
> it will be ready by next Tuesday:
> http://fedoraproject.org/wiki/PackagingDrafts/Java
>
> Next Tuesday will undoubtedly be a longer meeting than normal, so please
> be prepared.
Friday, Sunday, Monday are public holidays in Germany (Easter).
I'll be off next week (vacation) and therefore will likely not be able
to attend due to other commitments.
Ralf
From rc040203 at freenet.de Thu Mar 20 05:22:39 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 20 Mar 2008 06:22:39 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205965981.23340.39.camel@localhost.localdomain>
References: <1205965981.23340.39.camel@localhost.localdomain>
Message-ID: <1205990560.14969.340.camel@beck.corsepiu.local>
On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
> This goes out specifically to the Fedora Packaging Committee Members,
> but is certainly open for comments from all.
>
> We've got a lot of drafts that are queued up for next Tuesday's meeting,
> so it would be very helpful if you read them all well in advance:
Due to the fact, I'll likely not be able to attend on Tuesday,
preliminary comments/answers/votes interspersed.
> ASCII Naming Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
Already replied in a separate mail.
> Perl Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/Perl
Generally OK, but I am missing a section on perl subdirectory directory
ownership.
My vote: 0 without such a section, +1 with such a section.
Also, I do not agree upon the section on "Makefile.PL vs. Build.PL",
but ... this is nothing new. I would prefer leaving the choice to the
maintainer and not to explicitly recommend Build.PL.
> InitDir location (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/InitDir
0, I don't understand what this draft is trying to say and which
problems it is trying to solve. Could you explain?
> Eclipse Plugin Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
0, no opinion on this.
> OpenOffice.org extensions guidelines (Caolan McNamara) :
> http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
OK for FC > 9, not OK for FC < 9
The unopkg concerns still apply
- /usr/bin/unopkg is not available for FC < 9
Updating the FC8/7 packages to provide them won't help, because users
might not have "updates" installed.
- Also, I am not sure if /usr/bin is the appropriate location to install
unopkg. /usr/sbin/ might be more appropriate.
> Secure BuildRoot (Lubomir Kundrak) :
> http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
+1.
OK as a recommendation for Fedora < 10, but should not be made mandatory
before Fedora 10 (or even later), IMO.
Should this proposal be accepted, rel-eng should implement it into all
packages during a mass-rebuild, may-be accompanied with rpm's upstream
implementing it as "default buildroot" into (FC10's) rpm.
> Register VirtualProvides (Patrice Dumas) :
> http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
-1
Not clear enough. Many packages apply virtual provides not covered by
these lists (e.g. alternate package names, obsoletes/provides, legacy
provides etc.) This proposal doesn't specify which class of virtual
provides it is aiming at.
> SysV-style Initscript Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
+1, Seems OK to me.
> I don't have the Java Guidelines draft on the list yet, but I hope that
> it will be ready by next Tuesday:
> http://fedoraproject.org/wiki/PackagingDrafts/Java
0, for now, no opinion on that. I don't see any obvious mistake/flaw,
but I am not sufficiently knowledgeable on java to be able to comment on
details.
Ralf
From nicolas.mailhot at laposte.net Thu Mar 20 07:31:13 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 20 Mar 2008 08:31:13 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205985135.14969.310.camel@beck.corsepiu.local>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
Message-ID: <1205998273.15397.3.camel@rousalka.dyndns.org>
Le jeudi 20 mars 2008 ? 04:52 +0100, Ralf Corsepius a ?crit :
> 2. I do not agree to the "When Upstream Naming is outside ..." section.
>
> This section is unnecessarily/avoidable adding confusion for
> maintainers. Non-ASCII names have always been banned rsp. technically
> impossible ever since Linux exists => this is a non-issue.
That's blatantly false. They've not been "banned", otherwise the
document would not be written today, and they've not been "impossible".
What changed is that the 8-bits encoding that passed through before are
being replaced by an encoding that lifts all the translating/regional
incompatibility problems and adds some technical requirements that could
be taken care of.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL:
From nicolas.mailhot at laposte.net Thu Mar 20 07:38:52 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 20 Mar 2008 08:38:52 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205985135.14969.310.camel@beck.corsepiu.local>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
Message-ID: <1205998732.15397.9.camel@rousalka.dyndns.org>
Le jeudi 20 mars 2008 ? 04:52 +0100, Ralf Corsepius a ?crit :
> On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
> > ASCII Naming Guidelines (spot) :
> > http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
>
> IMO, this proposal is not strict enough.
>
> 1. I think, we need to restrict package names to
> a-z, A-Z, 0-9, -, _
If FPC goes that way I'll ask for a-z O-9 - only. Casing breaks on
Windows mirrors and FAT USB sticks and this kind of incompatibity has
been one of the main arguments for writing this guideline. And there's
no need for _ when you have - and are asking people to rewrite names
anyway.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL:
From rc040203 at freenet.de Thu Mar 20 08:20:09 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 20 Mar 2008 09:20:09 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205998273.15397.3.camel@rousalka.dyndns.org>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
<1205998273.15397.3.camel@rousalka.dyndns.org>
Message-ID: <1206001209.14969.361.camel@beck.corsepiu.local>
On Thu, 2008-03-20 at 08:31 +0100, Nicolas Mailhot wrote:
> Le jeudi 20 mars 2008 ? 04:52 +0100, Ralf Corsepius a ?crit :
>
> > 2. I do not agree to the "When Upstream Naming is outside ..." section.
> >
> > This section is unnecessarily/avoidable adding confusion for
> > maintainers. Non-ASCII names have always been banned rsp. technically
> > impossible ever since Linux exists => this is a non-issue.
>
> That's blatantly false.
I guess I don't have to mention that I whole heartily disagree.
> They've not been "banned", otherwise the
> document would not be written today,
This document has been written, because you and your ?collier-fonts
package submissing are challenging what had been "common sense" to most
experienced users, so far.
> and they've not been "impossible".
You still seem to refuse to understand the issue.
Installing your package is technically close to impossible to many
users, because they are not able to type/read/display its name
May-be you don't see this problem, because "?" is common in your
culture - To others, it's unreadable, undisplayable "fly dirt" (German
hacker slang for unreadable, undisplayable characters), "Greek" as
Englishmen might be calling it.
> What changed is that the 8-bits encoding that passed through before are
> being replaced by an encoding that lifts all the translating/regional
> incompatibility problems and adds some technical requirements that could
> be taken care of.
I disagree. SuSE and Debian have it right.
Fedora is once more about to make a (IMNSHO) faulty decision.
Ralf
From pertusus at free.fr Thu Mar 20 09:00:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 20 Mar 2008 10:00:15 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205990560.14969.340.camel@beck.corsepiu.local>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205990560.14969.340.camel@beck.corsepiu.local>
Message-ID: <20080320090015.GC2578@free.fr>
On Thu, Mar 20, 2008 at 06:22:39AM +0100, Ralf Corsepius wrote:
>
> > Register VirtualProvides (Patrice Dumas) :
> > http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
> -1
>
> Not clear enough. Many packages apply virtual provides not covered by
> these lists (e.g. alternate package names, obsoletes/provides, legacy
> provides etc.) This proposal doesn't specify which class of virtual
> provides it is aiming at.
Thanks for the input, I completly forgot about those since they are
outside of the scope, though alternate names is at the limit... I am indeed
focused on alternate functionalities or similar provides. I'll update.
--
Pat
From nicolas.mailhot at laposte.net Thu Mar 20 09:10:21 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 20 Mar 2008 10:10:21 +0100 (CET)
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1206001209.14969.361.camel@beck.corsepiu.local>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
<1205998273.15397.3.camel@rousalka.dyndns.org>
<1206001209.14969.361.camel@beck.corsepiu.local>
Message-ID: <41174.192.54.193.59.1206004221.squirrel@rousalka.dyndns.org>
Le Jeu 20 mars 2008 09:20, Ralf Corsepius a ?crit :
>
> On Thu, 2008-03-20 at 08:31 +0100, Nicolas Mailhot wrote:
>> Le jeudi 20 mars 2008 ? 04:52 +0100, Ralf Corsepius a ?crit :
>>
>> > 2. I do not agree to the "When Upstream Naming is outside ..."
>> section.
>> >
>> > This section is unnecessarily/avoidable adding confusion for
>> > maintainers. Non-ASCII names have always been banned rsp.
>> technically
>> > impossible ever since Linux exists => this is a non-issue.
>>
>> That's blatantly false.
> I guess I don't have to mention that I whole heartily disagree.
You can disagree all you want that's a plain fact hard. I did the
tests and you didn't. In fact they show a the breakage when it happens
is in the upper layers bolted over rpm in the recent years, and I
doubt this was a conscious design decision of the people who wrote
them.
You could probably shove an 8-bit iso-8859-1 name (which is not the
same thing as 7-bit ASCII) through the whole infrastructure today and
it wouldn't blink.
>> They've not been "banned", otherwise the
>> document would not be written today,
> This document has been written, because you and your ?collier-fonts
> package submissing are challenging what had been "common sense" to
> most
> experienced users, so far.
>
>> and they've not been "impossible".
> You still seem to refuse to understand the issue.
>
> Installing your package is technically close to impossible to many
> users, because they are not able to type/read/display its name
Nevertheless the plain fact is that they've not been impossible and
they've not been banned before.
> May-be you don't see this problem, because "?" is common in your
> culture - To others, it's unreadable, undisplayable "fly dirt" (German
> hacker slang for unreadable, undisplayable characters), "Greek" as
> Englishmen might be calling it.
I perfectly understand the problem, which is why I object to you
pretending it's something else to shore up your arguments.
>> What changed is that the 8-bits encoding that passed through before
>> are
>> being replaced by an encoding that lifts all the
>> translating/regional
>> incompatibility problems and adds some technical requirements that
>> could
>> be taken care of.
> I disagree. SuSE and Debian have it right.
Which again are soft policies, not the impossibility you pretend in
your message.
--
Nicolas Mailhot
From pertusus at free.fr Thu Mar 20 09:23:08 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 20 Mar 2008 10:23:08 +0100
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com>
References: <20080319221350.GB2635@free.fr>
<80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com>
Message-ID: <20080320092308.GE2578@free.fr>
On Wed, Mar 19, 2008 at 04:48:52PM -0600, Stephen John Smoogen wrote:
> On Wed, Mar 19, 2008 at 4:13 PM, Patrice Dumas wrote:
> > Hello,
> >
> > Recently the issue of crypto and crypto export in fedora/EPEL was raised
> > about beecrypt. This is something that has never been discussed as far
> > as I remember. It should of course be checked with legal.
> >
> > My question is, does crypto software need a specific treatement in
> > fedora? (And if yes, what is a crypto software?)
> >
>
> As far as I know crypto has always needed special treatment in Fedora.
> Most encryption software is considered 'controlled' for export by
> several nations (I think United States, France, Russia, China, etc).
> What Red Hat has to do is fill out paperwork with the United States
> Commerce department whenever new software with encryption is added to
> Fedora or RHEL.
Then we have to register crypto packages somewhere such that the people
in charge can do the paperwork, isn't it? Don't we need a guideline
here?
--
Pat
From jkeating at redhat.com Thu Mar 20 11:47:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Mar 2008 07:47:41 -0400
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <20080320092308.GE2578@free.fr>
References: <20080319221350.GB2635@free.fr>
<80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com>
<20080320092308.GE2578@free.fr>
Message-ID: <1206013661.4449.16.camel@localhost.localdomain>
On Thu, 2008-03-20 at 10:23 +0100, Patrice Dumas wrote:
> Then we have to register crypto packages somewhere such that the people
> in charge can do the paperwork, isn't it? Don't we need a guideline
> here?
I actually need to prep a guideline that has all packages with crypto
technology block FE-LEGAL (if that's still the alias). We'll use that
to get an audit of the code to make sure its either not new crypto, or
if it is, alert the appropriate people for export filings.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From pertusus at free.fr Thu Mar 20 12:00:25 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 20 Mar 2008 13:00:25 +0100
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <1206013661.4449.16.camel@localhost.localdomain>
References: <20080319221350.GB2635@free.fr>
<80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com>
<20080320092308.GE2578@free.fr>
<1206013661.4449.16.camel@localhost.localdomain>
Message-ID: <20080320120025.GA9603@free.fr>
On Thu, Mar 20, 2008 at 07:47:41AM -0400, Jesse Keating wrote:
> On Thu, 2008-03-20 at 10:23 +0100, Patrice Dumas wrote:
> > Then we have to register crypto packages somewhere such that the people
> > in charge can do the paperwork, isn't it? Don't we need a guideline
> > here?
>
> I actually need to prep a guideline that has all packages with crypto
> technology block FE-LEGAL (if that's still the alias). We'll use that
> to get an audit of the code to make sure its either not new crypto, or
> if it is, alert the appropriate people for export filings.
Looks good.
There are other questions that should be answered, however, in my opinion
(with external sources of information if possible, no need to be fedora
centric).
What is the criteria for being a crypto technology? It is easy to spot
many packages that are not crypto, but for others it is not very clear
to me. For example at which point a math library becomes a crypto
library? And what about an applicatin that compute hashes? Also does the
registration need to be done each time there is a new release or once
for all?
--
Pat
From rc040203 at freenet.de Thu Mar 20 08:26:41 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 20 Mar 2008 09:26:41 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205998732.15397.9.camel@rousalka.dyndns.org>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
<1205998732.15397.9.camel@rousalka.dyndns.org>
Message-ID: <1206001602.14969.365.camel@beck.corsepiu.local>
On Thu, 2008-03-20 at 08:38 +0100, Nicolas Mailhot wrote:
> Le jeudi 20 mars 2008 ? 04:52 +0100, Ralf Corsepius a ?crit :
> > On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
>
> > > ASCII Naming Guidelines (spot) :
> > > http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
> >
> > IMO, this proposal is not strict enough.
> >
> > 1. I think, we need to restrict package names to
> > a-z, A-Z, 0-9, -, _
Adding '.' (to cater openoffice) would match what had been practice ever
since.
> If FPC goes that way I'll ask for a-z O-9 - only. Casing breaks on
> Windows mirrors and FAT USB sticks and this kind of incompatibity has
> been one of the main arguments for writing this guideline. And there's
> no need for _ when you have - and are asking people to rewrite names
> anyway.
Sorry, I can't take this remark serious.
From jkeating at redhat.com Thu Mar 20 14:39:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Mar 2008 10:39:00 -0400
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <20080320120025.GA9603@free.fr>
References: <20080319221350.GB2635@free.fr>
<80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com>
<20080320092308.GE2578@free.fr>
<1206013661.4449.16.camel@localhost.localdomain>
<20080320120025.GA9603@free.fr>
Message-ID: <1206023940.3173.18.camel@localhost.localdomain>
On Thu, 2008-03-20 at 13:00 +0100, Patrice Dumas wrote:
> Looks good.
>
> There are other questions that should be answered, however, in my opinion
> (with external sources of information if possible, no need to be fedora
> centric).
>
> What is the criteria for being a crypto technology? It is easy to spot
> many packages that are not crypto, but for others it is not very clear
> to me. For example at which point a math library becomes a crypto
> library? And what about an applicatin that compute hashes? Also does the
> registration need to be done each time there is a new release or once
> for all?
These are all good questions, and we need to get Steve Grubb plugged in
here to answer some of these.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From rjones at redhat.com Thu Mar 20 14:42:26 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 20 Mar 2008 14:42:26 +0000
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <1206013661.4449.16.camel@localhost.localdomain>
References: <20080319221350.GB2635@free.fr>
<80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com>
<20080320092308.GE2578@free.fr>
<1206013661.4449.16.camel@localhost.localdomain>
Message-ID: <20080320144226.GA26912@amd.home.annexia.org>
On Thu, Mar 20, 2008 at 07:47:41AM -0400, Jesse Keating wrote:
> On Thu, 2008-03-20 at 10:23 +0100, Patrice Dumas wrote:
> > Then we have to register crypto packages somewhere such that the people
> > in charge can do the paperwork, isn't it? Don't we need a guideline
> > here?
>
> I actually need to prep a guideline that has all packages with crypto
> technology block FE-LEGAL (if that's still the alias). We'll use that
> to get an audit of the code to make sure its either not new crypto, or
> if it is, alert the appropriate people for export filings.
Hate to be difficult, but what about a package like ocaml-cryptokit
which originates outside the US?
http://pauillac.inria.fr/~xleroy/software.html#cryptokit
(I don't think that particular package has anything which could be
described as "new crypto").
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
From rdieter at math.unl.edu Thu Mar 20 15:00:12 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 20 Mar 2008 10:00:12 -0500
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <20080320144226.GA26912@amd.home.annexia.org>
References: <20080319221350.GB2635@free.fr> <80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com> <20080320092308.GE2578@free.fr> <1206013661.4449.16.camel@localhost.localdomain>
<20080320144226.GA26912@amd.home.annexia.org>
Message-ID: <47E27BFC.7040300@math.unl.edu>
Richard W.M. Jones wrote:
> Hate to be difficult, but what about a package like ocaml-cryptokit
> which originates outside the US?
irrelevant, I think. What matters (most) is who's distributing the
crypto binaries and from where => fedora, USA
-- Rex
From jkeating at redhat.com Thu Mar 20 16:31:23 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Mar 2008 12:31:23 -0400
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <200803201227.00550.sgrubb@redhat.com>
References: <20080319221350.GB2635@free.fr> <20080320120025.GA9603@free.fr>
<1206023940.3173.18.camel@localhost.localdomain>
<200803201227.00550.sgrubb@redhat.com>
Message-ID: <1206030683.3173.30.camel@localhost.localdomain>
On Thu, 2008-03-20 at 12:27 -0400, Steve Grubb wrote:
> We have a tool that does a pretty good job of spotting crypto. It relies on
> some keywords that people usually use when writing crypto libraries. Of
> course they could name functions and variables in Portuguese and we would
> miss it. :)
>
What is this tool, is it opensource, and then is it in Fedora?
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From smooge at gmail.com Thu Mar 20 17:06:44 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Thu, 20 Mar 2008 11:06:44 -0600
Subject: [Fedora-packaging] crypto in fedora
In-Reply-To: <20080320120025.GA9603@free.fr>
References: <20080319221350.GB2635@free.fr>
<80d7e4090803191548k3618752r5df869ad92ba0d9b@mail.gmail.com>
<20080320092308.GE2578@free.fr>
<1206013661.4449.16.camel@localhost.localdomain>
<20080320120025.GA9603@free.fr>
Message-ID: <80d7e4090803201006x6553cf8bn555f1f20fa4c8e18@mail.gmail.com>
On Thu, Mar 20, 2008 at 6:00 AM, Patrice Dumas wrote:
> On Thu, Mar 20, 2008 at 07:47:41AM -0400, Jesse Keating wrote:
> > On Thu, 2008-03-20 at 10:23 +0100, Patrice Dumas wrote:
> > > Then we have to register crypto packages somewhere such that the people
> > > in charge can do the paperwork, isn't it? Don't we need a guideline
> > > here?
> >
> > I actually need to prep a guideline that has all packages with crypto
> > technology block FE-LEGAL (if that's still the alias). We'll use that
> > to get an audit of the code to make sure its either not new crypto, or
> > if it is, alert the appropriate people for export filings.
>
> Looks good.
>
> There are other questions that should be answered, however, in my opinion
> (with external sources of information if possible, no need to be fedora
> centric).
>
> What is the criteria for being a crypto technology? It is easy to spot
> many packages that are not crypto, but for others it is not very clear
> to me. For example at which point a math library becomes a crypto
> library? And what about an applicatin that compute hashes? Also does the
> registration need to be done each time there is a new release or once
> for all?
>
>
Back in 2001, it needed to be done everytime there was an update to
the code (eg everytime we patched kerberos openssh and put it out.. a
new fax was sent to DoC in Washington and the mirror push had to wait
until then.) However I am not sure if we had to do it with coreutils
(md5sum).. but I am not sure if patching that ever came up. I was
mostly on the "crap remove this from the mirrors, someone pushed too
early" end of things.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
From tcallawa at redhat.com Thu Mar 20 19:20:52 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 20 Mar 2008 15:20:52 -0400
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <20080320025801.GC21237@nostromo.devel.redhat.com>
References: <1205965981.23340.39.camel@localhost.localdomain>
<20080320025801.GC21237@nostromo.devel.redhat.com>
Message-ID: <1206040852.27297.15.camel@localhost.localdomain>
On Wed, 2008-03-19 at 22:58 -0400, Bill Nottingham wrote:
> Tom spot Callaway (tcallawa at redhat.com) said:
> > InitDir location (spot) :
> > http://fedoraproject.org/wiki/PackagingDrafts/InitDir
>
> Should this just be merged into the later draft?
Yes, and it is now merged into that draft. :)
> 1) I'm of the opinion that LSB headers should be optional. There is no
> requirement in the LSB for any system scripts to be LSB compliant, and
> it can cause issues with ordering.
Indeed, I agree with this. I've amended the draft to make it very clear
that LSB headers are optional.
> This is incorrect.
(lots of good text snipped)
Thanks for the correction. I've fixed the mistakes and added a section
which is essentially your explanation on how LSB Provides work in
Fedora.
> 3) Standardizing on try-restart when we have generally accepted use of
> 'condrestart' seems problematic.
Agreed. Its now all condrestart.
Thanks for taking the time to review this,
~spot
From rdieter at math.unl.edu Thu Mar 20 19:33:40 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 20 Mar 2008 14:33:40 -0500
Subject: [Fedora-packaging] Re: Drafts for next Tuesday
References: <1205965981.23340.39.camel@localhost.localdomain>
<20080320025801.GC21237@nostromo.devel.redhat.com>
Message-ID:
Bill Nottingham wrote:
> Tom spot Callaway (tcallawa at redhat.com) said:
>> InitDir location (spot) :
>> http://fedoraproject.org/wiki/PackagingDrafts/InitDir
>
> Should this just be merged into the later draft?
>
>> SysV-style Initscript Guidelines (spot) :
>> http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
"Packages with SysV-style initscripts must put any them
into /etc/rc.d/init.d." vs. LSB's standard of /etc/init.d ?
See also recently filed:
"packaging policy on init scripts violates LSB standard"
http://bugzilla.redhat.com/438357
I personally doubt the pain to properly fix is worth it (flip-flop
dir/symlink of /etc/rc.d/init.d /etc/init.d), but I wanted to raise the
point for discussion.
-- Rex
From tcallawa at redhat.com Thu Mar 20 19:34:52 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 20 Mar 2008 15:34:52 -0400
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205990560.14969.340.camel@beck.corsepiu.local>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205990560.14969.340.camel@beck.corsepiu.local>
Message-ID: <1206041692.27297.21.camel@localhost.localdomain>
On Thu, 2008-03-20 at 06:22 +0100, Ralf Corsepius wrote:
> > Perl Guidelines (spot) :
> > http://fedoraproject.org/wiki/PackagingDrafts/Perl
> Generally OK, but I am missing a section on perl subdirectory directory
> ownership.
>
> My vote: 0 without such a section, +1 with such a section.
I've added a section to the draft that reflects what the general
guidelines already have. Please let me know if you feel this is
sufficient.
> > InitDir location (spot) :
> > http://fedoraproject.org/wiki/PackagingDrafts/InitDir
> 0, I don't understand what this draft is trying to say and which
> problems it is trying to solve. Could you explain?
This draft has been absorbed into a section in the SysVInitScript draft.
I've also tried to make it more clear.
> > OpenOffice.org extensions guidelines (Caolan McNamara) :
> > http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
> OK for FC > 9, not OK for FC < 9
>
> The unopkg concerns still apply
> - /usr/bin/unopkg is not available for FC < 9
> Updating the FC8/7 packages to provide them won't help, because users
> might not have "updates" installed.
The guidelines could always add a Require for the specific update n-v-r
to ensure that users do have the updates installed.
> > Secure BuildRoot (Lubomir Kundrak) :
> > http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
> +1.
>
> OK as a recommendation for Fedora < 10, but should not be made mandatory
> before Fedora 10 (or even later), IMO.
This draft is specifically targeted for F10 and later. There is no
intention to do mass rebuilds to enforce this in F9 or older.
~spot
From tibbs at math.uh.edu Thu Mar 20 23:07:51 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 20 Mar 2008 18:07:51 -0500
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1206001209.14969.361.camel@beck.corsepiu.local>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
<1205998273.15397.3.camel@rousalka.dyndns.org>
<1206001209.14969.361.camel@beck.corsepiu.local>
Message-ID:
>>>>> "RC" == Ralf Corsepius writes:
RC> Fedora is once more about to make a (IMNSHO) faulty decision.
Wow, someone has a device to predict the future. I hope I get to
borrow it occasionally.
- J<
From tcallawa at redhat.com Fri Mar 21 03:25:09 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 20 Mar 2008 23:25:09 -0400
Subject: [Fedora-packaging] one more draft
Message-ID: <1206069909.27297.68.camel@localhost.localdomain>
I've added another draft to the todo list:
http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
I doubt we'll get to it on Tuesday, but we'll get to it eventually.
~spot
From rc040203 at freenet.de Fri Mar 21 03:37:27 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 21 Mar 2008 04:37:27 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To:
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
<1205998273.15397.3.camel@rousalka.dyndns.org>
<1206001209.14969.361.camel@beck.corsepiu.local>
Message-ID: <1206070647.14969.389.camel@beck.corsepiu.local>
On Thu, 2008-03-20 at 18:07 -0500, Jason L Tibbitts III wrote:
> >>>>> "RC" == Ralf Corsepius writes:
>
> RC> Fedora is once more about to make a (IMNSHO) faulty decision.
>
> Wow, someone has a device to predict the future.
We are talking about "here and now" - The damage to Fedora allowing
utf-8 and chars like $`, etc. in package names does is immediate.
From nicolas.mailhot at laposte.net Fri Mar 21 07:53:47 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 21 Mar 2008 08:53:47 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1206070647.14969.389.camel@beck.corsepiu.local>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
<1205998273.15397.3.camel@rousalka.dyndns.org>
<1206001209.14969.361.camel@beck.corsepiu.local>
<1206070647.14969.389.camel@beck.corsepiu.local>
Message-ID: <1206086027.9760.34.camel@rousalka.dyndns.org>
Le vendredi 21 mars 2008 ? 04:37 +0100, Ralf Corsepius a ?crit :
> On Thu, 2008-03-20 at 18:07 -0500, Jason L Tibbitts III wrote:
> > >>>>> "RC" == Ralf Corsepius writes:
> >
> > RC> Fedora is once more about to make a (IMNSHO) faulty decision.
> >
> > Wow, someone has a device to predict the future.
> We are talking about "here and now" - The damage to Fedora allowing
> utf-8 and chars like $`, etc. in package names does is immediate.
Well, you're one of those who raised a stink and now as a result we're
likely to get a badly written authoritative guideline that explicitely
allows practices much worse than the ones you were complained about (for
a package you had no interest in regardless of its naming). Me, I've
always been in favour of authorising full utf-8 as soon as our tools
were fixed, and let packagers use their best judgement.
But anyway some comments on the proposal:
> While Fedora is an international community, for consistency and
> usability, there needs to be a common character set for package
> naming.
Neat, however the distribution already has a common character set we
enforce everywhere else, that's UTF-8 (even default character set in
some package tools like comps files), and this rationalization could
apply just as well to UTF-8. Why is it that after weeks of flames we
proponents of writing this guideline can not come with a clear
rationale?
(note that the first version of the proposal was even worse and called
for translating package names in English ; I don't think stuff like
libcaca is in any English dictionnary)
> Specifically, all Fedora packages must be named using only the 94
> printable characters defined by ASCII. These characters are displayed
> here:
At least the author was careful enough to forbid non-printable
characters. But a screenshot is insufficient as definition ? a cyrillic
A would fit right in.
> Fedora packagers are strongly suggested to avoid using
> non-AlphaNumeric characters from the printable ASCII character set
> whenever possible, but they are permitted.
Since there is no clear rationale in the spec it's difficult to judge if
this kind of clause helps achieving the actual aim. Nevertheless I'll
note that:
? space is a printable ASCII character and it's not being forbidden in
the guideline. Need I point out how completely irrational it is to worry
about what packagers might do if allowed UTF-8 and then bless space?
? & <> and friends are going to wreak much more havoc than allowing
UTF-8 and letting packagers use their good judgement to determine how
much UTF-8 is reasonable would ever had
? if the rationale was to be mirror, and FTP-safe (one of the arguments
advanced on the list) I'll note there are very common limited platforms,
and very common storage media, which are unable to handle casing safely,
so allowing mixed-case names is dangerous (and if the limited platform
is not justifying the guideline I don't see what does)
I'll state it again:
1. ?If we write a restrictive guideline, at least select correct
restrictions.
2. ?If no one can be bothered writing correct clear restrictions, do not
burden packagers with half-baked ones.
3. If we want a permissive guideline, stating that
a. package names are UTF-8 encoded like the rest of the distro,
b. that packagers should ?use their good judgement to determine how
much UTF-8 is reasonable,
c. that infra has the mandate to fix our unicode bugs
d. and that it can embargo anything outside the basic latin block till
it's done
? is just as fine and does not reek of prejudice like this version.
Regards,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL:
From pertusus at free.fr Fri Mar 21 22:41:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 21 Mar 2008 23:41:34 +0100
Subject: [Fedora-packaging] a proposal to register virtual provides
In-Reply-To: <20080318222420.GB2698@free.fr>
References: <20080318222420.GB2698@free.fr>
Message-ID: <20080321224134.GB2544@free.fr>
On Tue, Mar 18, 2008 at 11:24:20PM +0100, Patrice Dumas wrote:
> Hello,
There is an updated version for the ProvidesList draft, thanks to Ralf
input:
https://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
Any feedback welcomed.
--
Pat
From Axel.Thimm at ATrpms.net Sat Mar 22 14:28:03 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 22 Mar 2008 16:28:03 +0200
Subject: [Fedora-packaging] /srv (was: one more draft)
In-Reply-To: <1206069909.27297.68.camel@localhost.localdomain>
References: <1206069909.27297.68.camel@localhost.localdomain>
Message-ID: <20080322142803.GC15647@puariko.nirvana>
Hi,
On Thu, Mar 20, 2008 at 11:25:09PM -0400, Tom spot Callaway wrote:
> I've added another draft to the todo list:
> http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
"It is important to note that a Fedora package, once installed, and
run by a user, can use /srv as a default location for data. The
package simply cannot own any directories or files in /srv."
one could read that like "the packager could hardwire a /srv location
into the package, he just needs to hide it from rpmdb".
Maybe better:
"It is important to note that a Fedora package, once installed, and
run by a user, can use /srv as a default location for data according
to the user's input. The package simply cannot own any directories or
files or otherwise assume any predefined hierarchies under /srv."
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From ville.skytta at iki.fi Sun Mar 23 15:35:45 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Mar 2008 17:35:45 +0200
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1206040852.27297.15.camel@localhost.localdomain>
References: <1205965981.23340.39.camel@localhost.localdomain>
<20080320025801.GC21237@nostromo.devel.redhat.com>
<1206040852.27297.15.camel@localhost.localdomain>
Message-ID: <200803231735.45646.ville.skytta@iki.fi>
On Thursday 20 March 2008, Tom "spot" Callaway wrote:
> On Wed, 2008-03-19 at 22:58 -0400, Bill Nottingham wrote:
>
> > 3) Standardizing on try-restart when we have generally accepted use of
> > 'condrestart' seems problematic.
>
> Agreed. Its now all condrestart.
-1
Instead, just use try-restart in all examples, and add a note that condrestart
should/must for the time being be included in all scripts as an alias to
try-restart.
From ville.skytta at iki.fi Sun Mar 23 15:40:47 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Mar 2008 17:40:47 +0200
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205985135.14969.310.camel@beck.corsepiu.local>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
Message-ID: <200803231740.48269.ville.skytta@iki.fi>
On Thursday 20 March 2008, Ralf Corsepius wrote:
> On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
>
> > ASCII Naming Guidelines (spot) :
> > http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
>
> IMO, this proposal is not strict enough.
>
> 1. I think, we need to restrict package names to
> a-z, A-Z, 0-9, -, _
Seconded, except I think in addition to those listed, "." (eg. openoffice.org)
and "+" (eg. gcc-c++) should be fine.
From ville.skytta at iki.fi Sun Mar 23 15:48:26 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Mar 2008 17:48:26 +0200
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <200803231740.48269.ville.skytta@iki.fi>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
<200803231740.48269.ville.skytta@iki.fi>
Message-ID: <200803231748.26692.ville.skytta@iki.fi>
On Sunday 23 March 2008, Ville Skytt? wrote:
> On Thursday 20 March 2008, Ralf Corsepius wrote:
> > On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
> > > ASCII Naming Guidelines (spot) :
> > > http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
> >
> > IMO, this proposal is not strict enough.
> >
> > 1. I think, we need to restrict package names to
> > a-z, A-Z, 0-9, -, _
>
> Seconded, except I think in addition to those listed, "." (eg.
> openoffice.org) and "+" (eg. gcc-c++) should be fine.
Forgot to note that for the record, like I've always been, I'd still be all
for going all lowercase, but I fear trying to push this could create a fuss
which would endanger passing of the whole draft.
From ville.skytta at iki.fi Sun Mar 23 16:22:47 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Mar 2008 18:22:47 +0200
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1205965981.23340.39.camel@localhost.localdomain>
References: <1205965981.23340.39.camel@localhost.localdomain>
Message-ID: <200803231822.47893.ville.skytta@iki.fi>
On Thursday 20 March 2008, Tom "spot" Callaway wrote:
> Perl Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/Perl
1) cpanspec should be pushed further down in the draft.
2) Versioned MODULE_COMPAT_ Requires:
"This is to ensure that all perl modules are built against the appropriate
version of perl."
This rationale is wrong - it doesn't ensure that, but that packages have a
dependency to a perl that uses stuff from dirs versioned with that version
number.
3) ExtUtils::Build doesn't exist AFAIK, did you mean Module::Build?
> Eclipse Plugin Guidelines (spot) :
> http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
> OpenOffice.org extensions guidelines (Caolan McNamara) :
> http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
These look mostly sane, will need to read them some more though.
> Secure BuildRoot (Lubomir Kundrak) :
> http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
-1 to any buildroot suggestion that doesn't propose implementing it internally
in rpm aiming for eventual deprecation and elimination of the BuildRoot tag
(and related "rm -rf"'s) in specfiles.
Anyway, specific to the submitted draft, both alternatives cause buildroot
trashing even with innocent "rpm -q --specfile foo.spec" or "rpmbuild -bp
foo.spec" or "rpmbuild -bs foo.spec".
Additionally, the second makes dangerous assumptions which can wreak havoc
in %clean when one overrides the build root (eg. %buildroot in ~/.rpmmacros).
> Register VirtualProvides (Patrice Dumas) :
> http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
+1 to the general idea, however I'm somewhat uncertain about
server(port_name), it needs more explanation. Consider for example the
tomcat5 package: it's configured to use port 8080 by default. I don't think
server(webcache) would describe it well at all. Also, changing servers to
run in non-default ports is pretty common and kind of breaks the "contract"
of server(port_name), but perhaps that's just a documentation issue.
From ville.skytta at iki.fi Sun Mar 23 16:26:35 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Mar 2008 18:26:35 +0200
Subject: [Fedora-packaging] one more draft
In-Reply-To: <1206069909.27297.68.camel@localhost.localdomain>
References: <1206069909.27297.68.camel@localhost.localdomain>
Message-ID: <200803231826.35535.ville.skytta@iki.fi>
On Friday 21 March 2008, Tom "spot" Callaway wrote:
> I've added another draft to the todo list:
> http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
>
> I doubt we'll get to it on Tuesday, but we'll get to it eventually.
If this passes, it needs a statement what to do with packages that already
use /srv in a way that conflicts with the draft. /srv/foo is typically data,
potentially lots and lots of it, so auto-migrations are practically out of
the question and manual ones are possibly nontrivial amounts of admin work.
Therefore I'd suggest letting them stay as is.
From nicolas.mailhot at laposte.net Sun Mar 23 16:43:06 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 23 Mar 2008 17:43:06 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <200803231748.26692.ville.skytta@iki.fi>
References: <1205965981.23340.39.camel@localhost.localdomain>
<1205985135.14969.310.camel@beck.corsepiu.local>
<200803231740.48269.ville.skytta@iki.fi>
<200803231748.26692.ville.skytta@iki.fi>
Message-ID: <1206290586.25215.8.camel@rousalka.dyndns.org>
Le dimanche 23 mars 2008 ? 17:48 +0200, Ville Skytt? a ?crit :
> Forgot to note that for the record, like I've always been, I'd still be all
> for going all lowercase, but I fear trying to push this could create a fuss
> which would endanger passing of the whole draft.
So you advocate bowing to a group of people that raised a fuss, and not
doing what you think is the right thing because others people may raise
a fuss? Where is the engineering in that? Or should we dispense with the
whole FPC thing and just do online polls?
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL:
From Axel.Thimm at ATrpms.net Sun Mar 23 18:02:22 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sun, 23 Mar 2008 20:02:22 +0200
Subject: [Fedora-packaging] Re: one more draft
In-Reply-To: <200803231826.35535.ville.skytta@iki.fi>
References: <1206069909.27297.68.camel@localhost.localdomain>
<200803231826.35535.ville.skytta@iki.fi>
Message-ID: <20080323180222.GA20734@puariko.nirvana>
On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skytt? wrote:
> On Friday 21 March 2008, Tom "spot" Callaway wrote:
> > I've added another draft to the todo list:
> > http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
> >
> > I doubt we'll get to it on Tuesday, but we'll get to it eventually.
>
> If this passes, it needs a statement what to do with packages that already
> use /srv in a way that conflicts with the draft. /srv/foo is typically data,
> potentially lots and lots of it, so auto-migrations are practically out of
> the question and manual ones are possibly nontrivial amounts of admin work.
> Therefore I'd suggest letting them stay as is.
Which packages are these? Maybe they can check whether they are being
upgraded (from a package evr polluting /srv) or freshly installed. In the
latter case they should behave as every other package, e.g. not assume
anything about /srv.
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From pertusus at free.fr Sun Mar 23 20:01:03 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 23 Mar 2008 21:01:03 +0100
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <200803231822.47893.ville.skytta@iki.fi>
References: <1205965981.23340.39.camel@localhost.localdomain>
<200803231822.47893.ville.skytta@iki.fi>
Message-ID: <20080323200103.GD2529@free.fr>
On Sun, Mar 23, 2008 at 06:22:47PM +0200, Ville Skytt? wrote:
>
> > Register VirtualProvides (Patrice Dumas) :
> > http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
>
> +1 to the general idea, however I'm somewhat uncertain about
> server(port_name), it needs more explanation. Consider for example the
You mean on
http://fedoraproject.org/wiki/VilleSkytt?/VirtualProvides
There is no mention of server(port_name) on
http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
It is explained on
http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
I had understood that it had been ratified, but I may be wrong.
I wanted to wait for the guideline to have find a new home with a more
definitive content, but I can add the link right now on
http://fedoraproject.org/wiki/VilleSkytt?/VirtualProvides
> tomcat5 package: it's configured to use port 8080 by default. I don't think
> server(webcache) would describe it well at all. Also, changing servers to
8080 is used for too much stuff to be usefull in a Requires, in my
opinion. Still should be server(webcache) is a server listening on
localhost on this port wants to have this ability provided, in case it
would have make sense.
> run in non-default ports is pretty common and kind of breaks the "contract"
> of server(port_name), but perhaps that's just a documentation issue.
Also the server may not be started.
--
Pat
From ville.skytta at iki.fi Sun Mar 23 20:08:08 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Mar 2008 22:08:08 +0200
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <1206290586.25215.8.camel@rousalka.dyndns.org>
References: <1205965981.23340.39.camel@localhost.localdomain>
<200803231748.26692.ville.skytta@iki.fi>
<1206290586.25215.8.camel@rousalka.dyndns.org>
Message-ID: <200803232208.08537.ville.skytta@iki.fi>
On Sunday 23 March 2008, Nicolas Mailhot wrote:
> Le dimanche 23 mars 2008 ? 17:48 +0200, Ville Skytt? a ?crit :
> > Forgot to note that for the record, like I've always been, I'd still be
> > all for going all lowercase, but I fear trying to push this could create
> > a fuss which would endanger passing of the whole draft.
>
> So you advocate bowing to a group of people that raised a fuss,
Personally, I'm surprised that the the thing in question is something that
even needs much discussion, and further I don't think people advocating
sticking with a subset of ASCII are necessarily the fussier side in this
debate.
> and not
> doing what you think is the right thing because others people may raise
> a fuss? Where is the engineering in that?
It's called incremental engineering. I'd rather get a subset of possible
improvements in smaller digestible chunks than none at all.
> Or should we dispense with the
> whole FPC thing and just do online polls?
I believe that way we'd get more folks' opinions voiced and counted which is
good, but would also practically be left without the work the FPC does when
working with drafts after they're submitted and before they're voted on which
is a bigger drawback than using polls would be good for.
From ville.skytta at iki.fi Sun Mar 23 20:20:10 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Mar 2008 22:20:10 +0200
Subject: [Fedora-packaging] Re: one more draft
In-Reply-To: <20080323180222.GA20734@puariko.nirvana>
References: <1206069909.27297.68.camel@localhost.localdomain>
<200803231826.35535.ville.skytta@iki.fi>
<20080323180222.GA20734@puariko.nirvana>
Message-ID: <200803232220.10502.ville.skytta@iki.fi>
On Sunday 23 March 2008, Axel Thimm wrote:
> On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skytt? wrote:
> > On Friday 21 March 2008, Tom "spot" Callaway wrote:
> > > I've added another draft to the todo list:
> > > http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
> > >
> > > I doubt we'll get to it on Tuesday, but we'll get to it eventually.
> >
> > If this passes, it needs a statement what to do with packages that
> > already use /srv in a way that conflicts with the draft. /srv/foo is
> > typically data, potentially lots and lots of it, so auto-migrations are
> > practically out of the question and manual ones are possibly nontrivial
> > amounts of admin work. Therefore I'd suggest letting them stay as is.
>
> Which packages are these?
vdr (maintained by yours truly) is one. There's easily tens or hundreds of
gigabytes of DVB recordings in /srv/vdr.
> Maybe they can check whether they are being
> upgraded (from a package evr polluting /srv) or freshly installed. In the
> latter case they should behave as every other package, e.g. not assume
> anything about /srv.
I suppose that's possible (didn't think of that, thanks), but will lead to
more or less fragile config file modifications in scriptlets. I'm leaning on
the side of calling these modifications uglier than just leaving the data
where it is in /srv especially because there's no certainty how this issue
will be treated in the future (the draft contains things like "unclear"
and "At this time").
From Axel.Thimm at ATrpms.net Sun Mar 23 20:48:28 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sun, 23 Mar 2008 22:48:28 +0200
Subject: [Fedora-packaging] Re: one more draft
In-Reply-To: <200803232220.10502.ville.skytta@iki.fi>
References: <1206069909.27297.68.camel@localhost.localdomain>
<200803231826.35535.ville.skytta@iki.fi>
<20080323180222.GA20734@puariko.nirvana>
<200803232220.10502.ville.skytta@iki.fi>
Message-ID: <20080323204828.GA22114@puariko.nirvana>
On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skytt? wrote:
> On Sunday 23 March 2008, Axel Thimm wrote:
> > On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skytt? wrote:
> > > On Friday 21 March 2008, Tom "spot" Callaway wrote:
> > > > I've added another draft to the todo list:
> > > > http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
> > > If this passes, it needs a statement what to do with packages that
> > > already use /srv in a way that conflicts with the draft. /srv/foo is
> > > typically data, potentially lots and lots of it, so auto-migrations are
> > > practically out of the question and manual ones are possibly nontrivial
> > > amounts of admin work. Therefore I'd suggest letting them stay as is.
> >
> > Which packages are these?
>
> vdr (maintained by yours truly) is one. There's easily tens or hundreds of
> gigabytes of DVB recordings in /srv/vdr.
>
> > Maybe they can check whether they are being upgraded (from a
> > package evr polluting /srv) or freshly installed. In the latter
> > case they should behave as every other package, e.g. not assume
> > anything about /srv.
>
> I suppose that's possible (didn't think of that, thanks), but will
> lead to more or less fragile config file modifications in
> scriptlets.
Why fragile? It either checks whether a previous vdr config told vdr
to put files there or looks whether /srv/vdr exists.
> I'm leaning on the side of calling these modifications uglier than
> just leaving the data where it is in /srv
As said if the data is there leave it there. If it is a new install
then have the user decide where he needs his data being placed in. So
you'll keep legacy users happy and a clean /srv in new
installs. Wiring in /srv/vdr forever would break any site using
/srv// setups (like mine ;).
> especially because there's no certainty how this issue will be
> treated in the future (the draft contains things like "unclear" and
> "At this time").
These attributes including the "poor wording" are just spot's POV on
the FHS' stand on /srv. In fact the /srv hierarchy has been beaten to
death in various groups, be it FHS or LSB and the outcome is always
that no standard can or should dictate what the setup should look like
as it already diverges in typical single and multiple instance setups.
IOW there will never be any further detailed specification from any
standard on how to have users treat their data layout. But maybe some
further rationale should be added to the FHS to make readers
understand why there should be no vendor given contraints on the
layout. Changes in the FHS are real slow, though (see my libexec
standardization attempts a long while back).
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From tcallawa at redhat.com Sun Mar 23 22:25:33 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sun, 23 Mar 2008 18:25:33 -0400
Subject: [Fedora-packaging]
http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming amended
Message-ID: <1206311133.4438.24.camel@localhost.localdomain>
I've made another pass at changing the ASCIINaming draft.
To sum it up, I couldn't come up with a good reason for the other
"special" characters to ever appear, and if someone ever did come up
with a valid reason, well, that's what exceptions (and amending
guidelines) are for. Now, only A-Z,a-z,0-9,+-._ are permitted.
FPC members, please re-read this one before Tuesday:
http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
Thanks,
~spot
From jkeating at redhat.com Sun Mar 23 22:32:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 23 Mar 2008 18:32:53 -0400
Subject: [Fedora-packaging]
http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming amended
In-Reply-To: <1206311133.4438.24.camel@localhost.localdomain>
References: <1206311133.4438.24.camel@localhost.localdomain>
Message-ID: <1206311573.10058.14.camel@localhost.localdomain>
On Sun, 2008-03-23 at 18:25 -0400, Tom "spot" Callaway wrote:
> I've made another pass at changing the ASCIINaming draft.
>
> To sum it up, I couldn't come up with a good reason for the other
> "special" characters to ever appear, and if someone ever did come up
> with a valid reason, well, that's what exceptions (and amending
> guidelines) are for. Now, only A-Z,a-z,0-9,+-._ are permitted.
>
> FPC members, please re-read this one before Tuesday:
>
> http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
I'm no longer in the FPC, but I will say that I like this proposal. The
only thing I would change would be to add a suggest when
translating/transliterating to see what (if any) other distributions
have done for said package to maintain some sort of consistency when
upstream refuses to provide one.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
From a.badger at gmail.com Mon Mar 24 03:39:42 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 23 Mar 2008 20:39:42 -0700
Subject: [Fedora-packaging]
http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming amended
In-Reply-To: <1206311573.10058.14.camel@localhost.localdomain>
References: <1206311133.4438.24.camel@localhost.localdomain>
<1206311573.10058.14.camel@localhost.localdomain>
Message-ID: <47E7227E.7080509@gmail.com>
Jesse Keating wrote:
> On Sun, 2008-03-23 at 18:25 -0400, Tom "spot" Callaway wrote:
>> I've made another pass at changing the ASCIINaming draft.
>>
>> To sum it up, I couldn't come up with a good reason for the other
>> "special" characters to ever appear, and if someone ever did come up
>> with a valid reason, well, that's what exceptions (and amending
>> guidelines) are for. Now, only A-Z,a-z,0-9,+-._ are permitted.
>>
>> FPC members, please re-read this one before Tuesday:
>>
>> http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
>
> I'm no longer in the FPC, but I will say that I like this proposal. The
> only thing I would change would be to add a suggest when
> translating/transliterating to see what (if any) other distributions
> have done for said package to maintain some sort of consistency when
> upstream refuses to provide one.
>
I would like to see this addition as well. My position is that
transliterating from unicode at the distro level is going to be much
pain. The more cross-distro/packagers collaboration there is the less
of a problem this is.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL:
From ville.skytta at iki.fi Mon Mar 24 08:40:30 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 24 Mar 2008 10:40:30 +0200
Subject: [Fedora-packaging] Re: one more draft
In-Reply-To: <20080323204828.GA22114@puariko.nirvana>
References: <1206069909.27297.68.camel@localhost.localdomain>
<200803232220.10502.ville.skytta@iki.fi>
<20080323204828.GA22114@puariko.nirvana>
Message-ID: <200803241040.30981.ville.skytta@iki.fi>
On Sunday 23 March 2008, Axel Thimm wrote:
> On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skytt? wrote:
>
> > I suppose that's possible (didn't think of that, thanks), but will
> > lead to more or less fragile config file modifications in
> > scriptlets.
>
> Why fragile? It either checks whether a previous vdr config told vdr
> to put files there or looks whether /srv/vdr exists.
Previous config doesn't tell vdr anything, it uses compile time defaults,
ditto would most likely the new one. Deciding something based on
whether /srv/vdr exists is exactly the kind of fragility I mean. As is the
fact that we don't have a tool that could be reliably used to modify sourced
shell scripts (/etc/sysconfig/vdr) in the first place. Etc. There's a reason
why doing things like this is frowned upon.
> > I'm leaning on the side of calling these modifications uglier than
> > just leaving the data where it is in /srv
>
> As said if the data is there leave it there.
Just in case it wasn't clear, I meant leaving not only the data there but the
package and its dir ownerships as is too.
> If it is a new install
> then have the user decide where he needs his data being placed in.
They can already configure it in /etc/sysconfig/vdr. Making it mandatory to
configure it manually is not something I'm going to inflict on users, stuff
needs to work out of the box to the extent possible. Users already need to
create channels.conf manually, that's bad enough.
> > especially because there's no certainty how this issue will be
> > treated in the future (the draft contains things like "unclear" and
> > "At this time").
>
> These attributes including the "poor wording" are just spot's POV on
> the FHS' stand on /srv.
Sounds like the draft needs some work.
In addition to the above, I think "don't touch anything in /srv but feel free
to make default configs tell apps to store data somewhere there" (which is
how I read the draft in a nutshell) doesn't sound good. For typical cases,
the only practical difference to creating and owning the data dir(s) there
would be that users would have to create them manually with the correct
ownerships and permissions.
From Axel.Thimm at ATrpms.net Mon Mar 24 10:07:21 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Mon, 24 Mar 2008 12:07:21 +0200
Subject: [Fedora-packaging] Re: one more draft
In-Reply-To: <200803241040.30981.ville.skytta@iki.fi>
References: <1206069909.27297.68.camel@localhost.localdomain>
<200803232220.10502.ville.skytta@iki.fi>
<20080323204828.GA22114@puariko.nirvana>
<200803241040.30981.ville.skytta@iki.fi>
Message-ID: <20080324100721.GB23225@puariko.nirvana>
On Mon, Mar 24, 2008 at 10:40:30AM +0200, Ville Skytt? wrote:
> On Sunday 23 March 2008, Axel Thimm wrote:
> > On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skytt? wrote:
> >
> > > I suppose that's possible (didn't think of that, thanks), but will
> > > lead to more or less fragile config file modifications in
> > > scriptlets.
> >
> > Why fragile? It either checks whether a previous vdr config told vdr
> > to put files there or looks whether /srv/vdr exists.
>
> Previous config doesn't tell vdr anything, it uses compile time defaults,
> > If it is a new install then have the user decide where he needs
> > his data being placed in.
>
> They can already configure it in /etc/sysconfig/vdr.
That's what I mean. Whatever the hardwired defaults at compile time
the /etc/sysconfig/vdr takes precedence. So the package's scripts can
easily autoadjust to whatever situation. For correctness sake (imagine
someone calling vdr manually) the compile time defaults should be w/o
any /srv bits.
> > As said if the data is there leave it there.
>
> Just in case it wasn't clear, I meant leaving not only the data there but the
> package and its dir ownerships as is too.
But that would be wrong. One of the main FHS aspects is that a package
should not remove anything (e.g. not own anything) beneath /srv. And
that's what the draft also tried to map into the guidelines.
Just to reiterate: The /srv/vdr folder currently breaks all
/srv/ setups.
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From ville.skytta at iki.fi Mon Mar 24 15:23:00 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 24 Mar 2008 17:23:00 +0200
Subject: [Fedora-packaging] Re: one more draft
In-Reply-To: <20080324100721.GB23225@puariko.nirvana>
References: <1206069909.27297.68.camel@localhost.localdomain>
<200803241040.30981.ville.skytta@iki.fi>
<20080324100721.GB23225@puariko.nirvana>
Message-ID: <200803241723.01116.ville.skytta@iki.fi>
On Monday 24 March 2008, Axel Thimm wrote:
> Whatever the hardwired defaults at compile time
> the /etc/sysconfig/vdr takes precedence. So the package's scripts can
> easily autoadjust to whatever situation.
Good to hear you know better; I expect to see code to back that up if the
draft passes with a mandate to change the dirs :)
> But that would be wrong. One of the main FHS aspects is that a package [...]
We already do some things "wrong" wrt the FHS, for example /etc/rc.d/init.d
and /usr/libexec. I'm not aware of much movement in getting those fixed
although unlike /srv, they don't deal directly with user data and could
conceivably be easier and safer to fix. (Right, this is not a reason to
allow more wrongdoings, but they're in the same boat of kinda "this is how
things have been traditionally done, and we don't think it's worth the
trouble to change these particular cases".)
> Just to reiterate: The /srv/vdr folder currently breaks all
> /srv/ setups.
Sure, if you happen to have a dir called vdr there for some other
purpose. Similar things could be said about /var/lib/vdr or /var/spool/vdr.
From tibbs at math.uh.edu Mon Mar 24 16:13:19 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 24 Mar 2008 11:13:19 -0500
Subject: [Fedora-packaging] Drafts for next Tuesday
In-Reply-To: <200803231822.47893.ville.skytta@iki.fi>
References: <1205965981.23340.39.camel@localhost.localdomain>
<200803231822.47893.ville.skytta@iki.fi>
Message-ID:
>>>>> "VS" == Ville Skytt?