Meeting Reminder: April 1, 2008
by Tom Callaway
Just a reminder to FPC members: We will meet tomorrow, April 1, 2008 to
try to work through more of the pending drafts.
Sadly, this is not an April Fools joke.
Thanks,
~spot
16 years
Java packaging guidelines draft
by Andrew Overholt
Hi,
A whole bunch of people helped write the Java packaging guidelines draft
currently on the wiki:
http://fedoraproject.org/wiki/PackagingDrafts/Java
All of the questions and comments and TODOs that were on the page have
been taken care of. I'm sure there are going to be questions and
complaints, but we now feel it's in a state worthy of first draft
presentation.
I've added it to the agenda for the next FPC meeting, but discussion
before then may help get issues dealt with.
Note that we've moved the section on Java webapps to a separate page as
we (myself and Tom Fitzsimmons) feel it is too involved of a section to
include in the Java guidelines themselves. Some also feel it should be
considered in light of general guidelines for web applications. It's
been moved here:
http://fedoraproject.org/wiki/PackagingDrafts/JavaWebApps
Thanks go to Tom Fitzsimmons, Matt Wringe, David Walluck, Permaine
Cheung, Deepak Bhole, Lillian Angel, Nicolas Mailhot, Ville Skyttä,
Jason Tibbets, Lubomir Kundrak, Hans de Goede, Colin Walters, Fernando
Nasser, Gary Benson, Andrew Haley, and others who I'm forgetting.
Andrew
16 years
http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming amended
by Tom Callaway
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
16 years, 1 month
crypto in fedora
by Patrice Dumas
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
16 years, 1 month
Re: [Fedora-packaging] crypto in fedora
by Jesse Keating
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?
16 years, 1 month
Re: UPDATED: New draft packaging guidelines for OCaml
by Richard W.M. Jones
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
16 years, 1 month
FESCo notes on OCaml guidelines change
by Jason L Tibbitts III
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] <caillon> dwmw2_AVF, and i'm guessing it's probably not enough ;)
[13:01] * notting is here
[13:01] <bpepple> FPC had proposals for Ocaml and tcl. any objections to them?
[13:01] <f13> no objections here.
[13:01] <warren> no
[13:01] <tibbs> no
[13:01] <bpepple> none here either.
[13:01] <dwmw2_AVF> caillon: about 100 merkinpesos
[13:01] <dwmw2_AVF> ocaml packages require: ocaml
[13:02] <dwmw2_AVF> library packages, I mean
[13:02] <dwmw2_AVF> 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] <dwmw2_AVF> I think they should require ocaml of the _same_ arch.
[13:02] <dwmw2_AVF> otherwise it's broken
[13:02] <dwmw2_AVF> other than that, fine,.
[13:02] --> giallu has joined this channel (n=giallu(a)81-174-9-68.dynamic.ngi.it).
[13:03] <notting> "Rationale: OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes)."
[13:03] <notting> wow, quality.
[13:03] <dwmw2_AVF> it's because of the way interprocedural optimisation happen, iirc.
[13:03] <-- peters-tx has left this server ("Leaving").
[13:04] <tibbs> Yeah, ocaml is rather messed up.
[13:04] <dwmw2_AVF> if they fix it to require stuff of the correct arch, fine. Else, -1 broken.
[13:04] <tibbs> dwmw2_AVF: How can you do arch-specific requires?
[13:04] <tibbs> RPM doesn't actually support that.
[13:04] <dwmw2_AVF> fix one of the rpm bugs on the multilib tracker :)
[13:04] <dwmw2_AVF> or virtual provides
[13:05] * dgilmore is here
[13:05] <tibbs> I can send it back to the submitter, I guess.
[13:05] <f13> does ocamel even get multilibbed?
[13:06] <dwmw2_AVF> it has various libraries and accompanying devel subpackages
[13:06] <-- Renault has left this server (Remote closed the connection).
[13:07] <nirik> main ocaml itself isn't multilib it seems like... but some ocaml packages are.
[13:07] <f13> so it doesn't do any automagic arch specific requires/provides like c libraries do?
[13:08] --> Renault has joined this channel (n=couretca(a)AToulon-151-1-147-206.w86-209.abo.wanadoo.fr).
[13:08] <notting> f13: looks to be all hashes
[13:08] <dwmw2_AVF> no
[13:08] <dwmw2_AVF> and we don't get the core compiler in both versions either (nor -m32/-m64 support).
[13:08] <tibbs> There is some requires/provides magic, but those are turned on in the individual spec files.
[13:08] <dgilmore> ocaml seems to be overly complex
[13:09] <dwmw2_AVF> 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] <tibbs> I will send a rejection message out to the submitter and fedora-packaging.
[13:09] <f13> yeah, seems like a trap
[13:09] <dwmw2_AVF> I accidentally wrote a ppc64 back end for its compiler. It's _definitely_ complex :)
[13:09] <notting> 'accidentally'?
[13:09] <bpepple> tibbs: cool. thanks.
[13:10] <tibbs> Do note also that these were merely alteration to existing ocaml guidelines.
[13:10] <bpepple> tibbs: will do.
[13:10] <tibbs> I don't think the original, accepted guidelines are any better on this issue.
[13:10] <dgilmore> dwmw2_AVF: you should write a sparc64 one also :)
[13:11] <tibbs> So we're basically rejecting good changes because the original document has something that someone doesn't like.
[13:11] <tibbs> Which is... kind of backwards.
[13:11] <dwmw2_AVF> I don't mind approving it with a "please improve it further" comment
[13:11] <dgilmore> we can accept the fixes, but we should ask them to also go off and fix our issues
[13:11] <dwmw2_AVF> if it's considered progress
[13:11] <dwmw2_AVF> +0
16 years, 1 month
