Re: Bugzilla Outage/Upgrade - 2010-01-09
Hi, On Mon, Jan 4, 2010 at 11:01 PM, Ricky Zhou wrote: > Outage Notification - 2010-01-09 02:00 UTC > > There will be an outage starting at 2010-01-09 02:00 UTC, which will last > approximately 3 hours. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2010-01-09 02:00 UTC' > > Affected Services: > > bugzilla.redhat.com > > Unaffected Services: > > Buildsystem > CVS / Source Control > Database > DNS > Fedora Hosted > Fedora People > Fedora Talk > Mail > Mirror System > Torrent > Translation Services > Websites > > Ticket Link: > > https://fedorahosted.org/fedora-infrastructure/ticket/1900 > > Reason for Outage: > > Red Hat IT will be performing a bugzilla upgrade from version 3.2 to 3.4. > Does this update restricts bugzilla password length? Regards, Parag. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
Kevin Kofler: > Ouch, we weren't aware of all these issues when we approved common-lisp- > controller in FESCo. :-( It was "sold" to us as something great and working > perfectly. I wasn't aware that it didn't actually work at all at this time > and I strongly doubt the rest of FESCo was either. It makes no sense to have > a packaging guideline mandate using something which doesn't work. Jerry James: > The alternative to common-lisp-controller, for libraries at least, is > to have lots of subpackages:... > I can see why Debian went with > common-lisp-controller It helps keep insanity at bay. Common-lisp-controller would probably be very helpful for libraries if it *did* work. But it appears that mandating it was premature. Jerry James: > But I think we need to have an escape clause for applications, and > also for libraries that take a significant amount of time/space to > compile. No escape clause needed for applications. The 2nd sentence of: https://fedoraproject.org/wiki/Packaging:Lisp "This document does not describe conventions and customs for application programs that are written in Common Lisp." I think it should be backed down until it's *really* fixed (awakening upstream as necessary). --- David A. Wheeler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto and comps
On Fri, 08 Jan 2010 21:42:06 +0100 Kevin Kofler wrote: > Jens Petersen wrote: > > In F12 we shipped yum-presto in @gnome-desktop - a kind of a > > compromise I guess. Presto/deltarpm is very useful for machines > > with low net connectivity to mirrors but enough resources to > > rebuild rpms. > > > > But yum-presto is not a desktop package at all and certainly does > > not belong in the gnome-desktop group. [1] > > +1 > > In fact, we voted in FESCo that it should be added to one of the base > groups instead (@base, I guess). It makes no sense to have it in > @gnome-desktop nor in the KDE .ks file (which is where it is at the > moment – for KDE, it's in the .ks because we refused to add it to > @kde-desktop as it has nothing to do with KDE). I guess I would be fine with it being in @base or something. We can always - it in the Xfce kickstart or any other spin that doesn't want it by default. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: possible improvements ?
On Sat, 2010-01-09 at 13:06 +1100, David Timms wrote: > On 09/01/10 00:32, Rawhide Report wrote: > > Compose started at Fri Jan 8 08:15:04 UTC 2010 > > > > Broken deps for i386 > > -- > ... > >ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 > >ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 > >ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 > >ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 > >ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 > >ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > >ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > >ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > >ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 > >ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 > >ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 > >ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 > >ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 > >ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 > >ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 > >ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 > >ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 > >ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 > >ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > >ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > > Hi, I noticed that some broken ones are duped (usually together), making > it look like there is nearly twice as many as there really is. > Would sort -u dedupe those ? > > Also, it could be cleaner and easier to read to invert or summarize the > unsatisfied requires like: > > Broken dependencies: > ghc-HTTP-devel-4000.0.6-6.fc13.i686 > ghc-cairo-devel-0.10.1-5.fc12.i686 > ghc-fgl-devel-5.4.2.2-1.fc12.i686 > ghc-gconf-devel-0.10.1-5.fc12.i686 > ghc-cgi-devel-3001.1.7.1-3.fc13.i686 > all require ghc = 0:6.10.4, which is not available. > > or > ghc-doc = 0:6.10.4 is not available, but is required by: >ghc-HTTP-doc-4000.0.6-6.fc13.i686 >ghc-cgi-doc-3001.1.7.1-3.fc13.i686 >ghc-fgl-doc-5.4.2.2-1.fc12.i686 > > It might be nice to see the headings indented, and the package n-v-r-a > info not indented, (since long package names, makes for more difficult > to read emails, due to replies inserting quoting (> ) characters and > oveflowing a single line. > > Also the report subject could include say '-' separators between y, m, > day, like 2010-01-08 (which is another variant of the iso format that > still sorts by date nicely ;) > Reviewing patches. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: possible improvements ?
On 09/01/10 00:32, Rawhide Report wrote: Compose started at Fri Jan 8 08:15:04 UTC 2010 Broken deps for i386 -- ... >ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 >ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 >ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 >ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 >ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 >ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 >ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 >ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 >ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 >ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 >ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 >ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 >ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 >ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 >ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 >ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 >ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 >ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 >ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 >ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 Hi, I noticed that some broken ones are duped (usually together), making it look like there is nearly twice as many as there really is. Would sort -u dedupe those ? Also, it could be cleaner and easier to read to invert or summarize the unsatisfied requires like: Broken dependencies: ghc-HTTP-devel-4000.0.6-6.fc13.i686 ghc-cairo-devel-0.10.1-5.fc12.i686 ghc-fgl-devel-5.4.2.2-1.fc12.i686 ghc-gconf-devel-0.10.1-5.fc12.i686 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 all require ghc = 0:6.10.4, which is not available. or ghc-doc = 0:6.10.4 is not available, but is required by: ghc-HTTP-doc-4000.0.6-6.fc13.i686 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 ghc-fgl-doc-5.4.2.2-1.fc12.i686 It might be nice to see the headings indented, and the package n-v-r-a info not indented, (since long package names, makes for more difficult to read emails, due to replies inserting quoting (> ) characters and oveflowing a single line. Also the report subject could include say '-' separators between y, m, day, like 2010-01-08 (which is another variant of the iso format that still sorts by date nicely ;) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads-up: %define vs %global in specs
On Thu, Jan 07, 2010 at 11:54:14AM +0200, Panu Matilainen wrote:
> On Tue, 5 Jan 2010, Panu Matilainen wrote:
>
> >
> >For the impatient:
> >
> >Starting with today's rawhide, the these kind of constructs in
> >specs no longer "work":
> > %{?!foo: %define foo bar}
> >For the generally desired effect, the above simply becomes:
> > %{?!foo: %global foo bar}
> >
> >This is already recommended by the Fedora guidelines, but packages
> >which haven't been updated to follow the guideline might need
> >revising:
> >https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
>
> FYI, this change broke font package macros.
>
> I've reverted the macro scoping "fix" until I have a chance to
> properly investigate the breakage (possibly some quirk related to
> %{lua: ...} macros).
>
I've updated the %global preferred over %define section to say that the bug
is fixed in F13 so people should definitely avoid %{?!foo: %define [..]}
type constructs. If this doesn't make it back in in time for F13, let me
know and I'll update for when we do fix it.
-Toshio
pgpQ0BB97yeJS.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
Please do so. Entirely too many general users click-enable rawhide and never even see the comments in the .repo file at all. They are never presented a warning or anything of the sort. Split it into an optional package, and anyone that understands what it is will easily be able to install. -dj On Wed, Jan 6, 2010 at 9:47 PM, Kevin Fenzi wrote: > Greetings. > > I'd like to propose splitting out > the /etc/yum.repos.d/fedora-rawhide.repo file into a > fedora-release-rawhide subpackage which is NOT installed by default or > shipped on the live media. > > I wrote up this using the Feature template, but I don't guess it's > really that much of a feature: > > https://fedoraproject.org/wiki/Features/RawhideRepoSubpackage > > (except in that it needs coordination across the distro and docs > updates, etc). > > Thoughts? > > (either here or the talk page of the above wiki link). > > Thanks, > > kevin > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
On Fri, Jan 8, 2010 at 1:29 PM, Kevin Kofler wrote: > Ouch, we weren't aware of all these issues when we approved common-lisp- > controller in FESCo. :-( It was "sold" to us as something great and working > perfectly. I wasn't aware that it didn't actually work at all at this time > and I strongly doubt the rest of FESCo was either. It makes no sense to have > a packaging guideline mandate using something which doesn't work. The alternative to common-lisp-controller, for libraries at least, is to have lots of subpackages: trivial-features-ccl trivial-features-clisp trivial-features-cmu trivial-features-ecl trivial-features-gcl trivial-features-sbcl And you also have to keep trivial-features-src around in case someone buys an Allegro license. I can see why Debian went with common-lisp-controller for that case. It helps keep insanity at bay. But I think we need to have an escape clause for applications, and also for libraries that take a significant amount of time/space to compile. If we're going to use it for (some) libraries, then we also need to fix it so that it works on as many CLs as possible. A number greater than zero would be good. :-) Some kind of response to the fix I suggested for SBCL in https://bugzilla.redhat.com/show_bug.cgi?id=499182 would be nice, too. I guess I should make that an actual patch instead of a suggested sed operation. :-) H, I just looked upstream to see if this has been fixed, and found that the last CVS checkin was 4 years ago. That isn't encouraging. Is upstream dead, or could it be awakened if shouted at? -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
Jerry James wrote: > One of the first issues we'll have to face is the use of > common-lisp-controller. Ouch, we weren't aware of all these issues when we approved common-lisp- controller in FESCo. :-( It was "sold" to us as something great and working perfectly. I wasn't aware that it didn't actually work at all at this time and I strongly doubt the rest of FESCo was either. It makes no sense to have a packaging guideline mandate using something which doesn't work. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto and comps
Jens Petersen wrote: > In F12 we shipped yum-presto in @gnome-desktop - a kind of a compromise I > guess. Presto/deltarpm is very useful for machines with low net > connectivity to mirrors but enough resources to rebuild rpms. > > But yum-presto is not a desktop package at all and certainly does not > belong in the gnome-desktop group. [1] +1 In fact, we voted in FESCo that it should be added to one of the base groups instead (@base, I guess). It makes no sense to have it in @gnome-desktop nor in the KDE .ks file (which is where it is at the moment – for KDE, it's in the .ks because we refused to add it to @kde-desktop as it has nothing to do with KDE). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
Till Maas wrote: > I would like to have this with a slight modificiation. If a package > FTBFS for at least a certain amount of time (e.g. two weeks) at the time > of Beta, then every provenpackager may just fix the bugs for another > certain amount of time (e.g. another two weeks) and if nobody fixes it > then it should be dropped. Provenpackagers can already do that. Please just do it! > Or maybe we could have some kind of "neglected packages task force", that > may just in general fix bugs in packages that are not fixed by the > original maintainer. +1. I've been unofficially part of such a force in the past, and fixed a lot of FTBFS, broken dependency etc. bugs. Alex Lancaster also helped a lot with broken deps. But I can only do so much fixing on my own. Any help welcome! So I'd welcome an official task force being instated for this. > The advantage over becoming co-maintainer of certain packages is then, > that one does not get all the noise about bugs that are already been taken > care of by the original maintainer. Yeah, I surely can't comaintain all the packages I fix, they're way too many. Making things pass basic packaging-level QA (builds and has no broken deps) does not and should not require signing up to sort out any and all issues with the package. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request begs
> rinputd - A server for receiving input events over the network > https://bugzilla.redhat.com/show_bug.cgi?id=553705 > I'm taking this for review, it's just too cool not to... > Jarod Wilson > ja...@redhat.com > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Come back
Le vendredi 08 janvier 2010 19:17:48, Thomas Moschny a écrit : > As it has been updated last more than three months ago, it needs a new > review, iirc. See > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages#Claiming_ > Ownership_of_a_Retired_Package Mamoru Tasaka already told me that a new review was needed. So, I opened a new review request: https://bugzilla.redhat.com/show_bug.cgi?id=553739 -- Les pages de manuel Linux en français http://manpagesfr.free.fr signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, 07 Jan 2010 18:28:26 +0100, Jesse Keating wrote: > Is anybody out there making use of the following targets? I wanted to use this one: > unused-fedora-patches but it does not work, it works only for kernel; fix has been ignored: https://fedorahosted.org/fedora-infrastructure/ticket/1881 Regards, Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request begs
> libcrystalhd - Broadcom Crystal HD device interface library > https://bugzilla.redhat.com/show_bug.cgi?id=553717 > > I just got the driver for these cards merged into the linux kernel > staging tree a few days ago. Now we need the device interface library to > talk to the thing and add support to apps to use it. This is a hardware > h.264, mpeg2 and vc1 decoder board. That's right. 100% free and > open-source drivers and libs from Broadcom, and they give us a way to > decode digital video on Fedora w/o violating any codec patents, since > the decoding is done entirely in hardware (this is pretty similar to the > mpeg2 decoder on the Hauppauge WinTV PVR-350 in that respect). I'll grab this one because I started looking at packaging it up the other day, so if someone else has done the work I was going to do the least I can do it review it :-) Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Review request begs
So I know lots of people submit these sort of begs offering to do reviews in return, but... I'm a wee bit way too tied up to do any reviews in return right now, so I'm asking for reviewers to look at these simply because they're awesome packages we want in the distro... :) rinputd - A server for receiving input events over the network https://bugzilla.redhat.com/show_bug.cgi?id=553705 Neat little daemon that listens for a network connection from something such as the remotux app for iphone/ipod touch, and feeds received data through the linux kernel input subsystem. Basically, remotux turns the touchscreen into a trackpad, complete with tap-to-click, scrolling, etc., and you can pop up the standard keyboard and use it for, well, keyboard input. libcrystalhd - Broadcom Crystal HD device interface library https://bugzilla.redhat.com/show_bug.cgi?id=553717 I just got the driver for these cards merged into the linux kernel staging tree a few days ago. Now we need the device interface library to talk to the thing and add support to apps to use it. This is a hardware h.264, mpeg2 and vc1 decoder board. That's right. 100% free and open-source drivers and libs from Broadcom, and they give us a way to decode digital video on Fedora w/o violating any codec patents, since the decoding is done entirely in hardware (this is pretty similar to the mpeg2 decoder on the Hauppauge WinTV PVR-350 in that respect). Please and thank you, etc., etc. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Meeting Summary/logs for (20100108) FESCo meeting
Full logs at: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/fesco.2010-01-08-16.59.html http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/fesco.2010-01-08-16.59.txt http://meetbot.fedoraproject.org/fedora-meeting/2010-01-08/fesco.2010-01-08-16.59.log.html Meeting started by nirik at 16:59:54 UTC (full logs). Meeting summary init process (nirik, 17:00:27) New Chair (nirik, 17:04:53) Meeting time (nirik, 17:06:52) AGREED: Will try and come up with a better time/day for meeting and announce it early next week. (nirik, 17:12:38) #298 Revoke Paul Johnsons pacakger access and put him on probation. - (nirik, 17:13:54) #278 Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname (nirik, 17:15:19) #299 Feature: AtSpiTwo - https://fedoraproject.org/wiki/Features/AtSpiTwo (nirik, 17:19:11) AGREED: The AtSpiTwo feature is accepted. (nirik, 17:21:55) https://labs.codethink.co.uk/index.php/p/qt-atspi2/ (Kevin_Kofler, 17:22:05) (the Qt implementation) (Kevin_Kofler, 17:22:08) #300 Feature: BetterWebcamSupportF13 - https://fedoraproject.org/wiki/Features/BetterWebcamSupportF13 (nirik, 17:22:27) AGREED: The BetterWebcamSupportF13 feature is approved. (nirik, 17:25:18) #291: Man pages Packaging Guideline (nirik, 17:26:01) Open Floor (nirik, 17:28:20) #225 Bugzilla 484855 - Mediawiki Fedora-only patch (nirik, 17:39:23) AGREED: ajax will take a look at the issue for FESCo (nirik, 17:52:03) Open Floor (again) (nirik, 17:54:35) http://whenisgood.net/fesco-meeting (cwickert, 18:01:17) Meeting ended at 18:36:29 UTC (full logs). kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Come back
2010/1/8 Alain Portal : > I just took ownership of kbackup as it was orphan. > As there is a long time that I didn´t contribute to the Fedora Project, can > somebody tell me how to update the package and ask for F-10 and F-11 branches? As it has been updated last more than three months ago, it needs a new review, iirc. See http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages#Claiming_Ownership_of_a_Retired_Package - Thomas -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Thu, 7 Jan 2010 22:36:59 + (UTC) Zing wrote: > What makes you think these same users won't then also edit and enable > rawhide at this point? It's not much of a stretch to think these > seemingly innocent users might see this "rawhide" package, install, > and then also enable it; in fact, ISTM, a package that they don't > have that promises some type of newest whizbang gadgets that they're > missing out on might entice more of this class of user. :( Because it won't be on the live media that many of the install from, or the default groups that would be choosen from the dvd install. Which is more likely: 1. I am going to enable all the repos I can, oh look, something called rawhide is already here. I'll just enable it. 2. I am going to enable all the repos I can, ok. Now I am going to randomly look through the almost 19,000 packages for some that might have repo files to enable. > Might I suggest: > > $ chattr +i /etc/yum.repos.d/fedora-rawhide.repo > > just kidding, well, half-kidding :) I don't want to lock rawhide in a cabinet in the basement with a 'beware of leopard' sign on it. I just don't want it to be in the same packet of stuff that everyone who comes into the store gets by default. ;) kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE : split transmission into subpackages: Request for review
On Fri, 2010-01-08 at 18:49 +0530, Ankur Sinha wrote: > hi, > > wrt https://bugzilla.redhat.com/show_bug.cgi?id=550976 > > I've built the sub packages and have put them up here with the spec. > > http://ankursinha.fedorapeople.org/transmission/ > > Can someone please review these? You should: - post your changes as patches, to make it easier to see what's changed - have -libs for the common library bits stuff - keep the GTK+ front-end in the main package (which would avoid upgrade problems with transmission disappearing from people's menus on upgrade, and having to change comps) - split out the command-line bits into a sub-package Cheers -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Come back
Le vendredi 08 janvier 2010 16:26:14, Jaroslav Reznik a écrit : > F-10 branch is EOL (you probably thought F-11, F-12), for F-11/F-12 > branches see [1]. Yes, of course ;-) > Nice to have you back! Thanks -- Les pages de manuel Linux en français http://manpagesfr.free.fr signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Come back
Le vendredi 08 janvier 2010 16:11:32, Andrea Musuruane a écrit : > On Fri, Jan 8, 2010 at 3:51 PM, Alain Portal wrote: > > Hi, > > > > I just took ownership of kbackup as it was orphan. > > As there is a long time that I didn´t contribute to the Fedora Project, > > can somebody tell me how to update the package and ask for F-10 and F-11 > > branches? > > https://fedoraproject.org/wiki/CVS_admin_requests#Package_Change_Requests_for_existing_packages Thanks -- Les pages de manuel Linux en français http://manpagesfr.free.fr signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Fri, 08 Jan 2010 12:17:02 +0100, Thomas Janssen wrote: > 2010/1/7 Zing : >> On Thu, 07 Jan 2010 14:02:24 -0700, Kevin Fenzi wrote: >> >>> On Thu, 07 Jan 2010 15:24:05 +0100 >>> Till Maas wrote: >>> You propose that the repo should be enabled by default if the package is installed. I don't like this. This make it a lot easier to break a system with Rawhide, if one installs the repo file, e.g. only to be able to easily download the src.rpm files with yumdownloader or to query it with repoquery, but not to actually install the unsigned packages from it. >>> >>> How many folks do this? I suppose this is a downside... we could also >>> ship it with default disabled, so you would need to install and then >>> enable it. >> >> What makes you think these same users won't then also edit and enable >> rawhide at this point? > > Because the type of users we speak of, just enable *blindly* whatever > repo is available by a *default* installation. Those type of users > *dont* read at all, neither descriptions coming with a package nor > websites. So the barrier is much higher for them to break their boxen. Well, yeah, my question was rhetorical... I guess my point was the barrier can't get high enough for the class of user we're talking about. I get a little grumpy when we make changes for these type of people. sorry. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
On Fri, Jan 8, 2010 at 2:15 AM, Alexander Kahl wrote: > Please see my reply to David's post; do you know whether there is a > standardized SIG founding procedure? I looked around and found this: https://fedoraproject.org/wiki/Defining_projects It sounds like we should tell the Fedora Project Board that we are forming, and appoint someone to send them regular status reports. We should also tell the Packaging Committee that we have identified some problems with the current Lisp packaging guidelines and plan to submit revisions to those guidelines. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Come back
On Friday 08 January 2010 15:51:28 Alain Portal wrote: > Hi, > > I just took ownership of kbackup as it was orphan. > As there is a long time that I didn´t contribute to the Fedora Project, can > somebody tell me how to update the package and ask for F-10 and F-11 > branches? F-10 branch is EOL (you probably thought F-11, F-12), for F-11/F-12 branches see [1]. Nice to have you back! > An uptodate srpm successfully build in mock on my laptop (F-12) and in koji > -- scratch for f11, f12 and f13. > > Regards > Jaroslav [1] http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package_Change_Requests_for_existing_packages -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Come back
On Fri, Jan 8, 2010 at 3:51 PM, Alain Portal wrote: > Hi, > > I just took ownership of kbackup as it was orphan. > As there is a long time that I didn´t contribute to the Fedora Project, can > somebody tell me how to update the package and ask for F-10 and F-11 branches? https://fedoraproject.org/wiki/CVS_admin_requests#Package_Change_Requests_for_existing_packages Bye, Andrea. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Come back
Hi, I just took ownership of kbackup as it was orphan. As there is a long time that I didn´t contribute to the Fedora Project, can somebody tell me how to update the package and ask for F-10 and F-11 branches? An uptodate srpm successfully build in mock on my laptop (F-12) and in koji -- scratch for f11, f12 and f13. Regards -- Les pages de manuel Linux en français http://manpagesfr.free.fr signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto occasionally goes into "eternal" loop looking for deltas
On Thu, 7 Jan 2010, James Antill wrote:
On Thu, 2010-01-07 at 21:19 +0200, Jonathan Dieter wrote:
On Thu, 2010-01-07 at 20:44 +0200, Pekka Pietikainen wrote:
Presto is one of the best things ever, but occasionally it ends up not
finding the delta files from any of the mirrors in the mirror list and just
loops through them without making any progress. --disablepresto works
a-ok, I think yum clean all; yum update also did the trick once.
Still, this can probably be made a lot better. It shouldn't do that even if the
mirrors
are out-of-sync. Maybe add some logic that just disables
presto if the deltas are nowhere to be found after a few attempts? Anyone
else even see this happen?
Yeah, see https://bugzilla.redhat.com/show_bug.cgi?id=540140. To
summarize, the problem is that new updates have been pushed to the
server between the time you loaded primary.sqlite and prestodelta.xml.
When you run 'yum clean metadata' or 'yum clean all' it removes the
outdated cached primary.sqlite and downloads the newer version.
The bug has been closed as WONTFIX because there have only been a few
reports; I wouldn't mind revisiting that decision if someone has a
clever way of fixing it. (And I'm not convinced that checking n mirrors
and then giving up is the solution.)
The plugin could require yum >= 3.2.25, and then do something like (in
config or prereposetup):
for repo in repos:
repo.mdpolicy.append('prestodelta')
...which would auto download presto MD when yum gets new repomd/primary.
People might complain though :) ... another kind of fix would be for the
plugin to call ".cleanExpireCache()" if the MD fails to download.
The nice server side fix is to keep around more than one complete set
of MD (possible now we have unique MD filenames), so there would have to
be two updates within the client side cache timeout. But I'm not sure
how easy that is.
But not all the drpms would be kept so if a largish number of them
changed
-sv
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
Till Maas writes: > Would you please provide more instructions about how to implement it and > how to use it? quilt has builtin support for spec files. You only need to run "quilt setup foo.spec". Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Fri, 2010-01-08 at 14:43 +0100, Till Maas wrote: > On Thu, Jan 07, 2010 at 02:02:24PM -0700, Kevin Fenzi wrote: > > On Thu, 07 Jan 2010 15:24:05 +0100 > > Till Maas wrote: > > > > > You propose that the repo should be enabled by default if the package > > > is installed. I don't like this. This make it a lot easier to break a > > > system with Rawhide, if one installs the repo file, e.g. only to be > > > able to easily download the src.rpm files with yumdownloader or to > > > query it with repoquery, but not to actually install the unsigned > > > packages from it. > > > > How many folks do this? I suppose this is a downside... we could also > > ship it with default disabled, so you would need to install and then > > enable it. > > I guess the use of repoquery for rawhide is quite common for Fedora > developers who want to inspect the impact of updating their packages. > Also I guess at least the selective installation of some Rawhide package > might be quite common to verify bugfixes. IMHO developers and debuggers can install the additional package.. > Imho the danger of accidently breaking the system is a lot higher if > there is a package that will auto-destruct the system with the next yum > update than it is with the current setup, where a manual change of a > config file is required. You don't have to edit the config file, it's enough to run yum with --enablerepo=rawhide (or --enablerepo=* !). +1 for branching, with default disabled. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, Jan 06, 2010 at 03:59:14PM -0500, Owen Taylor wrote: > On Wed, 2010-01-06 at 16:00 +0100, nodata wrote: > > I'd like to suggest an enhancement for Fedora 13: nothing should ever > > steal focus from the window I am typing in. If I am typing in a shell > > window, or in a word processor, or an e-mail, nothing should ever take > > keyboard focus away from that window. > > > > Clearly I'm missing something, otherwise we would have this, hence the > > posting to the list :) > > I'm not sure what you are missing, but I know what I'm missing here - a > description of when exactly focus was stolen from you that was a > problem. > > In almost all cases, if you are typing into one application in Fedora, > and a window pops up from another application and steals away your > focus, and your typing goes to the wrong place, that's a bug that should > be filed against one of: I just realised that not only focus stealing when typing, but also when reading is annoying. E.g. here firefox just crashed, so I restarted it and while it opened all its tabs and windows, I wanted to read mails. But then firefox steals the focus several times for its windows. Is this something that is supposed to happen? Regards Till pgpSFXiFZNjpp.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, Jan 07, 2010 at 07:47:10PM +0100, Enrico Scholz wrote: > Jonathan Underwood writes: > > > I have used make patch quite a bit when developing patches. I guess > > it's just a wrapper around gendiff though, so it maybe redundant i.e. > > in my use case I could have been using gendiff. > > fwiw, 'gendiff' does not retain comments in patches and fails when one > file is touched by multiple patches. I wrote a wrapper around 'quilt' > which is used like Iirc there is a rediff target to keep the comments in a spec. gendiff works with multiple patches if one only wants to modify the last patch and the patches are applied with the right backup-suffixes in %patch. > > | %apply -n23 -p1 > > This expands to > > | quilt import -p 1 %PATCH23 > | quilt push -f > > resp. > > | %patch23 -p1 > > on systems without this macro. Refreshing and developing of patches is > very easy in this way. Would you please provide more instructions about how to implement it and how to use it? Regards Till pgpIFCjyNs1uS.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, Jan 07, 2010 at 09:28:26AM -0800, Jesse Keating wrote:
> As I proceed to port our make system over into fedpkg, I've ran across a
> couple targets that are giving me pause.
>
> Is anybody out there making use of the following targets?
> patch
I use this quite often to generate patches, but unluckily it only works
if the tarball is extracted into a dir called %{name}-%{version}.
I believe there is also a "rediff" target, which just renegerates a
patch and copies the comment above the patch.
> unused-patches
I use this to easily get a list of patches I can "cvs remove" after I
removed them from the spec.
Regards
Till
pgptxnl3ULAbr.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Thu, Jan 07, 2010 at 02:02:24PM -0700, Kevin Fenzi wrote: > On Thu, 07 Jan 2010 15:24:05 +0100 > Till Maas wrote: > > > You propose that the repo should be enabled by default if the package > > is installed. I don't like this. This make it a lot easier to break a > > system with Rawhide, if one installs the repo file, e.g. only to be > > able to easily download the src.rpm files with yumdownloader or to > > query it with repoquery, but not to actually install the unsigned > > packages from it. > > How many folks do this? I suppose this is a downside... we could also > ship it with default disabled, so you would need to install and then > enable it. I guess the use of repoquery for rawhide is quite common for Fedora developers who want to inspect the impact of updating their packages. Also I guess at least the selective installation of some Rawhide package might be quite common to verify bugfixes. Imho the danger of accidently breaking the system is a lot higher if there is a package that will auto-destruct the system with the next yum update than it is with the current setup, where a manual change of a config file is required. > > It will probably also auto break systems that just > > install everything, which is also not nice. > > I don't think it's possible to 'install everything'. > There are a number of packages in the collection that conflict. > Or do you have some other meaning for 'everything'? I believe that I have read about people installing everything except for conflicting packages to find some packaging bugs, e.g. non explicit conflicts. Regards Till pgpUnhCKsqc6m.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20100108 changes
Compose started at Fri Jan 8 08:15:04 UTC 2010 Broken deps for i386 -- PyKDE-3.16.6-1.fc13.i686 requires sip-api(6) >= 0:6.0 R-hdf5-1.6.9-5.fc13.i686 requires hdf5 = 0:1.8.3 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 avogadro-libs-1.0.0-3.fc13.i686 requires sip-api(6) >= 0:6.0 cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-
RFE : split transmission into subpackages: Request for review
hi, wrt https://bugzilla.redhat.com/show_bug.cgi?id=550976 I've built the sub packages and have put them up here with the spec. http://ankursinha.fedorapeople.org/transmission/ Can someone please review these? Thanks, regards, Ankur -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
2010/1/7 Zing : > On Thu, 07 Jan 2010 14:02:24 -0700, Kevin Fenzi wrote: > >> On Thu, 07 Jan 2010 15:24:05 +0100 >> Till Maas wrote: >> >>> You propose that the repo should be enabled by default if the package >>> is installed. I don't like this. This make it a lot easier to break a >>> system with Rawhide, if one installs the repo file, e.g. only to be >>> able to easily download the src.rpm files with yumdownloader or to >>> query it with repoquery, but not to actually install the unsigned >>> packages from it. >> >> How many folks do this? I suppose this is a downside... we could also >> ship it with default disabled, so you would need to install and then >> enable it. > > What makes you think these same users won't then also edit and enable > rawhide at this point? Because the type of users we speak of, just enable *blindly* whatever repo is available by a *default* installation. Those type of users *dont* read at all, neither descriptions coming with a package nor websites. So the barrier is much higher for them to break their boxen. It would be even better to install (disabled) the rpmfusion repos. Because enough of them think they might get what they miss if they enable rawhide. The closed source drivers for their video cards and nonfree codecs to play their music and movies. So at least a big +1 to have the rawhide repo in a different package and get it installed disabled if one wants/needs it. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2010 04:27 PM, Jerry James wrote: > On Wed, Jan 6, 2010 at 2:32 AM, Alexander Kahl > wrote: >> Thanks for the offer; currently I'm busy with getting GNUnet through the >> review, ccl can be next on the list but I'm unsure whether it wouldn't >> be better if we'd focus on packaging most commonly used CL libs like >> Alexandria first. ATM Debian (and its brown derivative) seems to be the >> no. 1 distro of choice for CL devs and I'd like to change that. > > I have a handful of candidate CL library packages, including alexandria, here: > > http://jjames.fedorapeople.org/ Nice! I'd add bordeaux-threads, cl-patron, cl-ppcre and some other as soon as the issues mentioned below are resolved. > The problem is that I followed the packaging guidelines, and thus used > common-lisp-controller which, as I mentioned, doesn't work for any CL > engine currently available in Fedora. I think we have to fix that > first. > >> Are you (or is anyone else here) interested in founding a Common Lisp SIG? > > Yes, I think we need to do so. Count me in. Please see my reply to David's post; do you know whether there is a standardized SIG founding procedure? - - Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktG958ACgkQVTRddCFHw12gmQCfcLbnC7mit17eA9ktEHGd2RAz LJkAniDgJUlQCwu4GHvLkRM9QycWD92+ =Wtzs -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, On 01/06/2010 06:34 PM, David A. Wheeler wrote: > On 01/04/2010 05:29 PM, Jerry James wrote: >> One of the first issues we'll have to face is the use of >> common-lisp-controller. >> First, it postpones compilation to the first time the application is >> executed by a particular Common Lisp engine. For the application I >> packaged, PVS [2], compilation takes a significant amount of time. >> This approach may be fine for small libraries and applications, but >> will it really scale up to the some of the big applications people >> want to package? > > No. That'd be rediculous; big CL applications can take a LONG time to > compile, > and compilation usually requires lots of memory (even if the final > application doesn't). this is identical to my experience. > Fedora has lots of applications written in many other compiled languages > like C and C++, and they aren't distributed *only* as source code. Instead, > people expect that when they download the binary they'll get a pre-compiled, > ready-to-go version. I think the same should be true for big Common Lisp (CL) > applications. (...) Definitely - but I'd rather see CL as a compiled language that permits the equivalent of static linking only (worst drawback) so the resulting binaries are huge since they contain every dependency including the actual lisp machine itself. This could in fact be the weakest point arguments could attack; I don't see an obvious solution here either as FASL is the closest it can get to prepare a freshly started lisp machine up to the desired state but that still requires dependency resolution, lots of memory, disk activity and cpu cycles etc. The only known alternative to me is gcl and ecl using C as intermediate language for compilation but gcl lacks even basic threading and ecl doesn't provide some POSIX related standard featured expected from compiled languages either. So the question remains whether Fedora devs and users would tolerate big CL app binaries. > Alexander Kahl: >> Are you (or is anyone else here) interested in founding a Common Lisp SIG? > > I'm interested. Is there a standardized process for founding SIGs? Or just add some wiki pages, set up a mailing list and spread some propaganda so folks will join? - - Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktG9wMACgkQVTRddCFHw13qZACgpnCOT8PH45rMIlztwqSgCUnQ nIIAoIyGSLFIIyZs09tqG23dLDOdDslg =MwAw -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
