Re: i386-class support changed in F-13?
On 06/02/2010 12:09 PM, Peter Robinson wrote: > It does work in F-12, the response for the lack of support in F-13 was > 'deal with it'. There is suppose to be a patch to emulate it in the > kernel but apparently it won't go upstream until its a generic infra > patch that can allow support of other emulated bits in other cpus in a > generic way. So its possible it will come back, but I don't hold up > hope of a quick resolution. Which leaves us in a big predicament as to > how we're going to support the 1.5 million odd XO-1s out there moving > forward. > Can you file a ticket with FESCo? Would be useful to track and resolve this issue. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-06-02 at 07:58 +0200, Kevin Kofler wrote: > Dave Airlie wrote: > > So does gdm use multiple X servers, I wasn't aware there was any other > > way. > > So what does it do exactly? Spawn a new X server on the same vterm? Or on a > different vterm? What KDM does is to spawn a new X server on a different > vterm. New X server on a different VT. I'm unaware of plans to make it operate any different, though that might not mean people have plans I don't know about. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, Jun 2, 2010 at 4:52 AM, Bruno Wolff III wrote: > On Tue, Jun 01, 2010 at 22:43:25 +0200, > Gland Vador wrote: >> On 05.04.2010 14:48, Dan Horák wrote: >> > >> > I was trying to install i686 variant of F-13 to an Alix board (2D13 with >> > Geode LX) and got into troubles. The kernel boots fine, but when it >> > should start initramfs the kernel panics. Everything works well when >> > using complete F-12 environment and when using F-12 kernel+initramfs >> > with F-13 rootfs the initramfs stuff runs well, but when I try to >> > manually chroot into the F-13 from the dracut shell I get an "Invalid >> > instruction" exception. I though last change in x86 CPU support was in >> > F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it >> > explicitly talks about Geode LX as still supported. So the question is >> > whether F-13 should still work on Geode LX? >> > >> >> Sorry to reopen this old topic, but the conclusion is not obvious. The >> F13 is out and it seems to have lost support for the Geode LX CPU >> (cf.http://sharkcz.livejournal.com/5708.html), due to the use of the >> NOPL instruction by GCC. >> >> Will this CPU be supported during F13 and above or should I search for a >> new distribution ? > > I don't believe there was any intentional change in supported CPUs for F13. > If it was supposed to work in F12, I think it is supposed to work in F13. > Did you file a bug against gcc? It does work in F-12, the response for the lack of support in F-13 was 'deal with it'. There is suppose to be a patch to emulate it in the kernel but apparently it won't go upstream until its a generic infra patch that can allow support of other emulated bits in other cpus in a generic way. So its possible it will come back, but I don't hold up hope of a quick resolution. Which leaves us in a big predicament as to how we're going to support the 1.5 million odd XO-1s out there moving forward. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100601 changes
On 1 June 2010 17:50, Rawhide Report wrote: > Compose started at Tue Jun 1 08:15:16 UTC 2010 > [..] > iaxclient-devel-2.1-0.5.beta3.fc13.i686 requires liboggz.so.1 > iaxclient-devel-2.1-0.5.beta3.fc13.i686 requires > liboggz.so.1(liboggz.so.0.2) [..] > libannodex-0.7.3-13.fc13.i686 requires liboggz.so.1 > libannodex-0.7.3-13.fc13.i686 requires liboggz.so.1(liboggz.so.0.2) > libfishsound-tools-0.9.1-4.fc12.i686 requires liboggz.so.1 > libfishsound-tools-0.9.1-4.fc12.i686 requires > liboggz.so.1(liboggz.so.0.2) Taken care. [..] > mod_annodex-0.2.2-11.fc12.i686 requires liboggz.so.1 Will get fixed day after tomorrow because it has a dependency for libannodex-devel which also needs re-build (above). [..] > sonic-visualiser-1.7.1-1.fc13.i686 requires liboggz.so.1 > sonic-visualiser-1.7.1-1.fc13.i686 requires > liboggz.so.1(liboggz.so.0.2) Taken care. -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Matt McCutchen wrote: > Please be careful not to take Lennart's remark out of context. A server > takes longer /than a desktop/ since it doesn't take full advantage of > systemd; it doesn't take longer than without systemd, because presumably > the SysV init emulation doesn't have a significant performance penalty. > There is no disadvantage of systemd here. Oh, of course, sorry for not having made that clear. > If you were just saying that it may be worth the effort at some point to > optimize server boot time, that point is taken. Right. That's what I really meant. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Dave Airlie wrote: > So does gdm use multiple X servers, I wasn't aware there was any other > way. So what does it do exactly? Spawn a new X server on the same vterm? Or on a different vterm? What KDM does is to spawn a new X server on a different vterm. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
2010/6/2 James Laska : > Greetings package maintainers, > > Want to get notification of any breakage in your just-built koji > packages? It would be great if rpmlint logs will be automatically generated on each koji build ans will be stored with oher koji build logs (in separate file(s)). This greatly helps in package reviewing. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Tue, Jun 01, 2010 at 22:43:25 +0200, Gland Vador wrote: > On 05.04.2010 14:48, Dan Horák wrote: > > > > I was trying to install i686 variant of F-13 to an Alix board (2D13 with > > Geode LX) and got into troubles. The kernel boots fine, but when it > > should start initramfs the kernel panics. Everything works well when > > using complete F-12 environment and when using F-12 kernel+initramfs > > with F-13 rootfs the initramfs stuff runs well, but when I try to > > manually chroot into the F-13 from the dracut shell I get an "Invalid > > instruction" exception. I though last change in x86 CPU support was in > > F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it > > explicitly talks about Geode LX as still supported. So the question is > > whether F-13 should still work on Geode LX? > > > > Sorry to reopen this old topic, but the conclusion is not obvious. The > F13 is out and it seems to have lost support for the Geode LX CPU > (cf.http://sharkcz.livejournal.com/5708.html), due to the use of the > NOPL instruction by GCC. > > Will this CPU be supported during F13 and above or should I search for a > new distribution ? I don't believe there was any intentional change in supported CPUs for F13. If it was supposed to work in F12, I think it is supposed to work in F13. Did you file a bug against gcc? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Tue, Jun 01, 2010 at 18:00:52 -0400, seth vidal wrote: > > > Can I opt in for all packages I am the owner or all packagers I co-maintain > > with one command? > > one command per pkg, yes. > > autoqa-optin pkgname devel F-14 F-13 F-12 EL-6 EL-5 EL-4 That answers my question. If mail would have been just sent to me, I would have prefered to have been able to optin for everything. But since it affects other people, I'll want to be selective about which ones I turn on. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, Jun 01, 2010 at 09:58:37PM +0200, Roberto Ragusa wrote: > Lennart Poettering wrote: > > On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote: > >> Well, I really do not want to flame anyone, but please consider that > >> the guy proposing the change already gave us pulseaudio, which promised the > >> "it will do anything you do now, just easier" feature too. > > > > Ah, turning this into something personal. Love you too. > > This is not a personal attack and I want to explain. > You will agree with me that pulseaudio caused a lot of complaints. > (we do not discuss if motivated or unmotivated, here) > That bad reputation unavoidably leads to weaker trust in your > promised guarantees. > > The most painful parts of PA were mainly the underestimation of both > "peculiar" use cases and impact of issues in related software (e.g. bugged > alsa drivers). It is only natural to be worried about the same things > (like lack of customizability) for this new init system. > > You *are* in a worse position than someone else when proposing > a revolution in some critical part of the system. That's no personal > offense. > On the positive side you are now well aware of the risks you > face, so you will probably play it better than someone else. Regardless of how this applies in this case, don't forget that digging your way out of a big mess is a different way to build trust. Sooner or later we all screw up, knowing how a person handles screwups can be quite valuable. > I hope your new init system will be a great success and help you > clean your name from the PA mess. I honestly hope so. > > >> We then discovered that some _trivial_ things where lost: > >> - having multiple independent sound cards > >> - having control of the mixer > >> - having sound with no user logged in > >> ... should I also mention latency, CPU usage, stability,...? > > > > You seem to have no idea what you are talking about. But anyway, let's > > not turn this into a discussion about PA. Don't need another one of those. > > I've been personally been burned by these issues, to the point of > going 90% of the way of removing PA from the system (I'm currently > running the unrecommended system-wide instance, I manually restart it > in some cases, I use often pasuspender and for some things I know > I have to turn if off completely). > > But I'm still on F10 and I read that pulseaudio has become better. > Maybe I will be positively surprised when upgrading to F13. for better or worse, released Fedora versions, especially <= N-1 don't tend to see a lot of updates. Developer manpower seems to shift quite early to rawhide and/or upstream and there's a few packages that only see token efforts once the next release is out. Staying on a particular release is unfortunately not the solution to get real fixes into your system. > >> Linux must NOT be Windows. > >> Linux must NOT be OS X. > > > > Well I for one think we can learn a lot from the competition. Open your > > eyes. There's a lot of good stuff in those other OS worlds, particularly > > in the designs of MacOS X. There's still so much they do better than we > > do. > > With "must NOT" I do not mean "we have to be far", I mean "we are not > obligated to be near". > > In recent times some stupid (IMHO) ideas have been adopted in Linux > just to copy what others do. Just as examples: the control of desktop > widgets in KDE4 (functional GUI elements modified by a mouse-over???), > the fast-user-switching approach (the Unix way is to have > multiple X servers). For every "stupid (IMHO) idea" there's people who disagree with the "stupid", "IMHO" and sometimes even the "idea" part. Long term, all this is evolutionary and some ideas die off, others prevail. Unlike in nature, it is steered evolution though and you can help steer away from ideas you deem bad by talking to the upstream developers. Venting on a distribution list won't do a lot of difference. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-06-02 at 02:33 +0200, Kevin Kofler wrote: > Roberto Ragusa wrote: > > In recent times some stupid (IMHO) ideas have been adopted in Linux > > just to copy what others do. Just as examples: the control of desktop > > widgets in KDE4 (functional GUI elements modified by a mouse-over???), > > I only know of 2 plasmoids triggering actions on mouse-over: > * the folder view's popping up of subfolders. This is not an active action, > it's just displaying stuff, I don't see how this is fundamentally different > from a tooltip. You don't actually CHANGE anything in the folders or files > without a mouse click, it just shows you stuff. > * Lancelot's clickless mode. While those are true actions (i.e. they're > active), this mode is a deliberate OPTION (i.e. it can be turned off) in a > plasmoid which is not shown by default, nor even INSTALLED by default (it's > in kdeplasma-addons). > > I don't think either is a real problem. > > > the fast-user-switching approach (the Unix way is to have > > multiple X servers). > > FWIW, KDE/KDM uses the "multiple X servers" approach. There are advantages > and drawbacks to either method. Unfortunately, the different approaches mean > user switching doesn't work with KDE under GDM nor with GNOME under KDM, > which is the only real problem I see in that area (and one of my semi-secret > plans is to try to fix this at some point one way or the other, but I'm way > too busy). So does gdm use multiple X servers, I wasn't aware there was any other way. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/6/2 Kevin Kofler : > Chen Lei wrote: >> The maintainer refuse some others to co-maintain tor package or help >> him to solve this issue. It's a bit complicated to fix this, fedora >> policy seems don't permit provenpackagers to commit a package if the >> maintainer are very unwilling to do so. It should be decided by fesco >> in which condition that a provenpackager can commit a package >> regardless the unwillingness of the package owner. > > FYI, FESCo decided on this particular issue that a provenpackager can fix > tor to comply with our initscripts guidelines for released Fedoras. (As far > as I know, the maintainer already fixed the Rawhide package.) > > Kevin Kofler > > No yet, as I known:), he only add a sysv initscripr to cvs, the package in rawhide still use -lsb and -upstart. Also the upstart subpackage works silly, it may need further optimization or obsolete from tor package. See http://koji.fedoraproject.org/koji/buildinfo?buildID=176044 http://koji.fedoraproject.org/koji/fileinfo?rpmID=1999845&filename=/etc/rc.d/init.d/tor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-06-02 at 02:50 +0200, Kevin Kofler wrote: > Lennart Poettering wrote: > > It's OK if a server takes a bit longer to boot. > > A longer boot time for your server means more downtime if you need to reboot > your server for whatever reason. Please be careful not to take Lennart's remark out of context. A server takes longer /than a desktop/ since it doesn't take full advantage of systemd; it doesn't take longer than without systemd, because presumably the SysV init emulation doesn't have a significant performance penalty. There is no disadvantage of systemd here. If you were just saying that it may be worth the effort at some point to optimize server boot time, that point is taken. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Tue, 2010-06-01 at 18:29 -0400, Sam Varshavchik wrote: > seth vidal writes: > > > > > I just added autoqa-optout to fedorapeople. > > > > it does what you expect it to do and acts just like autoqa-optin > > Would it be a good idea to mention these scripts somewhere in > http://fedoraproject.org/wiki/PackageMaintainers/Join? > > perhaps - this is intended to be a temporary mechanism for opting in to the results that autoqa currently has. The future is likely to be very different. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
Chen Lei wrote: > The maintainer refuse some others to co-maintain tor package or help > him to solve this issue. It's a bit complicated to fix this, fedora > policy seems don't permit provenpackagers to commit a package if the > maintainer are very unwilling to do so. It should be decided by fesco > in which condition that a provenpackager can commit a package > regardless the unwillingness of the package owner. FYI, FESCo decided on this particular issue that a provenpackager can fix tor to comply with our initscripts guidelines for released Fedoras. (As far as I know, the maintainer already fixed the Rawhide package.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering wrote: > It's OK if a server takes a bit longer to boot. A longer boot time for your server means more downtime if you need to reboot your server for whatever reason. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Roberto Ragusa wrote: > In recent times some stupid (IMHO) ideas have been adopted in Linux > just to copy what others do. Just as examples: the control of desktop > widgets in KDE4 (functional GUI elements modified by a mouse-over???), I only know of 2 plasmoids triggering actions on mouse-over: * the folder view's popping up of subfolders. This is not an active action, it's just displaying stuff, I don't see how this is fundamentally different from a tooltip. You don't actually CHANGE anything in the folders or files without a mouse click, it just shows you stuff. * Lancelot's clickless mode. While those are true actions (i.e. they're active), this mode is a deliberate OPTION (i.e. it can be turned off) in a plasmoid which is not shown by default, nor even INSTALLED by default (it's in kdeplasma-addons). I don't think either is a real problem. > the fast-user-switching approach (the Unix way is to have > multiple X servers). FWIW, KDE/KDM uses the "multiple X servers" approach. There are advantages and drawbacks to either method. Unfortunately, the different approaches mean user switching doesn't work with KDE under GDM nor with GNOME under KDM, which is the only real problem I see in that area (and one of my semi-secret plans is to try to fix this at some point one way or the other, but I'm way too busy). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
seth vidal writes: I just added autoqa-optout to fedorapeople. it does what you expect it to do and acts just like autoqa-optin Would it be a good idea to mention these scripts somewhere in http://fedoraproject.org/wiki/PackageMaintainers/Join? pgpF35QPUIyEW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Tue, 2010-06-01 at 16:43 -0400, James Laska wrote: > Greetings package maintainers, > > Want to get notification of any breakage in your just-built koji > packages? This includes results of rpmlint [1], rpmguard [2] and, if > applicable, initscript [3] tests. Good news, you can now opt-in to > receive test results by mail! > > All you have to do is: > > 1. Login to fedorapeople.org # ssh fedorapeople.org > 2. Run the command: autoqa-optin [] > > That's it! Thanks to Seth Vidal for the autoqa-optin script and > proposed changes to enable this feature. > I just added autoqa-optout to fedorapeople. it does what you expect it to do and acts just like autoqa-optin -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Tue, 2010-06-01 at 16:32 -0500, Bruno Wolff III wrote: > Who gets the email? What if I am a co-maintainer, do I get the email or > does it go to the package owner? we send the email to the pkgname-owner email address so all the folks on that alias get it. > Can I opt in for all packages I am the owner or all packagers I co-maintain > with one command? one command per pkg, yes. autoqa-optin pkgname devel F-14 F-13 F-12 EL-6 EL-5 EL-4 -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
Elio Maldonado (emald...@redhat.com) said: > Getting back to > >> (i.e., libfreebl3.so instead of libfreebl.so.3)? > > No danger of the name class I alluded for nss but we still want to preserve > the names so as not to break other dependent packages. I wonder if aliases > may help in any way. If we were to add, via the spec file, libfreebl.so.3 as > an alias to libfreebl3.so (and similarly with libnssdmb3.so and > linsoftoken3.so), would that help? I'm not sure it would really *help*, as it might cause confusion as some app would think that's the actual soname. I'm mainly curious as to the history of how the libraries ended up that way. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Tue, Jun 01, 2010 at 16:43:07 -0400, James Laska wrote: > Greetings package maintainers, > > Want to get notification of any breakage in your just-built koji > packages? This includes results of rpmlint [1], rpmguard [2] and, if > applicable, initscript [3] tests. Good news, you can now opt-in to > receive test results by mail! > > All you have to do is: > > 1. Login to fedorapeople.org # ssh fedorapeople.org > 2. Run the command: autoqa-optin [] > > That's it! Thanks to Seth Vidal for the autoqa-optin script and > proposed changes to enable this feature. Who gets the email? What if I am a co-maintainer, do I get the email or does it go to the package owner? Can I opt in for all packages I am the owner or all packagers I co-maintain with one command? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
Bill, Getting back to >> (i.e., libfreebl3.so instead of libfreebl.so.3)? No danger of the name class I alluded for nss but we still want to preserve the names so as not to break other dependent packages. I wonder if aliases may help in any way. If we were to add, via the spec file, libfreebl.so.3 as an alias to libfreebl3.so (and similarly with libnssdmb3.so and linsoftoken3.so), would that help? Elio - Original Message - From: "Elio Maldonado" To: "Development discussions related to Fedora" , "Robert Relyea" , "Kai Engert" Sent: Tuesday, June 1, 2010 1:32:43 PM GMT -08:00 US/Canada Pacific Subject: Re: FC13 nss-softokn-freebl update issues I don't know when the 3 suffix was added. It may have been due to versioning at some time but if I recall correctly we keep the 3 suffix to avoid a name class with with the other nss package (name switch service I believe). Bob or Kai can set me straight on this matter. Another thing that puzzles me if that this is a problem on F-13 but not on F-12. See comments in https://bugzilla.redhat.com/show_bug.cgi?id=596840 Elio - Original Message - From: "Bill Nottingham" To: "Development discussions related to Fedora" Sent: Tuesday, June 1, 2010 11:48:41 AM GMT -08:00 US/Canada Pacific Subject: Re: FC13 nss-softokn-freebl update issues Elio Maldonado (emald...@redhat.com) said: > Not sure but I strongly suspect a change made to nss.spec to be the cause. > See https://bugzilla.redhat.com/show_bug.cgi?id=596840#c7 It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr libraires) do not fit the normal library naming, so it's not explicitly pulled for multilib. For any update or release set that's composed with a package that explicitly requires a compat arch of nss-softokn-freebl (such as glibc, libpurple, pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13 updates has none of these, so it doesn't. We could add some hacks to mash to get it pulled in, but I must ask... why do all the NSS/NSPR libraries version their libraries in the library name instead of the so version (i.e., libfreebl3.so instead of libfreebl.so.3)? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
Elio Maldonado (emald...@redhat.com) said: > I don't know when the 3 suffix was added. It may have been due to versioning > at some time but if I recall correctly we keep the 3 suffix to avoid a name > class with with the other nss package (name switch service I believe). Bob or > Kai can set me straight on this matter. > > Another thing that puzzles me if that this is a problem on F-13 but not on > F-12. See comments in https://bugzilla.redhat.com/show_bug.cgi?id=596840 As I said... > For any update or release set that's composed with a package that explicitly > requires a compat arch of nss-softokn-freebl (such as glibc, libpurple, > pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13 > updates has none of these, so it doesn't. Both glibc and libpurple updates exist in F-12 updates. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-06-01)
Forgot to attach minutes: 19:00:03 #startmeeting FESCO (2010-06-01) 19:00:03 Meeting started Tue Jun 1 19:00:03 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:03 #meetingname fesco 19:00:03 #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:00:03 #topic init process 19:00:03 The meeting name has been set to 'fesco' 19:00:03 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:00:12 it's that time again 19:00:29 _o/ 19:00:35 * notting is here 19:00:36 i think so, brain, but if they called them sad meals, kids wouldn't buy them 19:00:40 cwickert indicated that he would not be making this meeting or likely the next 19:00:45 * SMParrish here 19:00:55 mclasen indicated that he would be a bit late. 19:02:01 welcome to the fun SMParrish, kylem 19:02:17 8-) 19:02:44 #info cwicket will be unable to attend. mclasen will be a bit late. 19:02:55 ok, I guess we can go ahead and get started... 19:03:01 #topic Elect Chair 19:03:06 it's storming pretty spectacularly here, so if the power cuts, so will my network access 19:03:17 I'm happy to keep chairing... but if someone else really wants to take over thats fine with me too. 19:03:31 I've no complaints with nirik's work 19:03:32 * notting is fine with nirik continuing 19:03:36 I'm +1 to keep you doing it 19:03:38 i'm happy with that if you want to continue. thanks for doing it. 19:03:49 +1 to keeping nirik in the hotseat 19:04:10 ok... 19:04:40 #agreed nirik will keep chairing for now. 19:04:48 #topic New meeting time? 19:04:58 So, how well does this time work for our new folks? 19:05:13 mclasen has a conflict at the beginning, so we might want to adjust based on what he can do... 19:05:19 SMParrish / kylem ? 19:05:30 Should be fine for me, new schedule should have me off on Tuesdays 19:05:43 from what he said, he has a conflict both at the beginning and at the end (of our longer meetings) 19:05:45 the time is fine for me (both for the foreseeable, and when i'm back in north america.) 19:05:59 Possibly best to run another of those whencanyoumakeit or whatever thingies? 19:06:17 whenisgood 19:06:42 yeah, I guess we can do that... 19:06:55 or the fine google wave thing. ;) 19:07:52 I can setup one I guess. 19:08:12 #action nirik will setup a whenisgood and will adjust next weeks meeting based on that. 19:08:37 groovy. 19:08:51 ok, anything else on this? or shall we move along... 19:09:34 next 19:10:08 sounds good 19:10:20 #topic #385 Zim / zim package issues. 19:10:20 .fesco 385 19:10:22 nirik: #385 (Zim / zim package issues.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/385 19:10:36 so, this is a bit of a fun one. 19:10:42 I summarized in the ticket. 19:10:52 (bong noises) 19:11:02 I don't have a problem with the guy forking this if that's really what he wants to do, but I think he should rename it as well, and leave the package tracking upstream. 19:11:10 I'm kindof betting he's not going to want to do that, though. 19:11:16 also what ajax said ;) 19:11:38 i looked at the bug and such earlier, i'm of the same opinion as peter... upstream had the name first, it should trump a fork. 19:11:49 * nirik nods. I agree. 19:11:57 I agree with pjones on this form and rename 19:11:58 What about the 'Zim' vs 'zim' rename? 19:12:00 s/form/fork 19:12:34 It seems like as Fedora we shouldn't really care if he forks it or not, but we want the package tracking what upstream does. And if he does fork it, he ought to pick something very distinct as the name for the new thing, just because it's kindof a dick move not to. 19:12:47 yeah, name the fork 'InvaderZim', or whatever. 19:12:53 users don't benefit from having name collisions (or almost collisions as in zim vs Zim) 19:12:59 agreed. 19:13:05 yeah, perl-zim should be renamed dib or something 19:13:08 IANAL (or on FESCO) but I think there would be trademark issues with keeping the name as well 19:13:32 ajax: or mvz 19:13:43 * mclasen apologizes for showing up late 19:13:49 sgallagh: only if there's a trademark, etc. but that's not really an issue for us. 19:13:58 ok, so, that leaves us with: a) reassign Zim to the new person who wants to maintain it, b) accept the 'zim' package review that obsoletes Zim, c) something else? 19:13:59 if he forks it, that really has nothing to do with fedora. 19:14:12 mclasen: welcome. No worries. 19:14:59 so, since i think i hear rough consensus: "zim", the new python thing, gets the right to the name in fedora. if the perl version forks, we'll name it something else, and we would encourage them to rename it to something unambiguous. 19:15:18 * nirik nods. I agree with that. 19:15:22 ditto. 19:15:25 yeah, that's what I'm saying. 19:15:31 * SMParrish agrees 19:15:45 me, nirik, pjones, kylem, smparrish. +5. 19:15:49
Summary/Minutes from today's FESCo meeting (2010-06-01)
=== #fedora-meeting: FESCO (2010-06-01) === Meeting started by nirik at 19:00:03 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-06-01/fesco.2010-06-01-19.00.log.html Meeting summary --- * init process (nirik, 19:00:03) * cwicket will be unable to attend. mclasen will be a bit late. (nirik, 19:02:44) * Elect Chair (nirik, 19:03:01) * AGREED: nirik will keep chairing for now. (nirik, 19:04:40) * New meeting time? (nirik, 19:04:48) * ACTION: nirik will setup a whenisgood and will adjust next weeks meeting based on that. (nirik, 19:08:12) * #385 Zim / zim package issues. (nirik, 19:10:20) * AGREED: The upsteam zim (python) should have that name in fedora. The forked version of Zim (perl) can rename itself to something else and get reviewed/imported seperately. (nirik, 19:16:06) * LINK: http://zim-wiki.org/downloads/ (nirik, 19:24:20) * AGREED: Python code is packaged as Zim, perl code must be renamed and coexist reasonably (nirik, 19:30:41) * AGREED: notify maintainers about [Zz]im being the python package and the fork gets a new name, revisit next week (nirik, 19:45:05) * #382 Implementing Stable Release Vision (nirik, 19:46:03) * LINK: https://fedoraproject.org/wiki/Stable_release_updates_vision (nirik, 19:53:53) * LINK: https://fedoraproject.org/wiki/Package_update_acceptance_criteria (nirik, 19:55:45) * AGREED: FESCo agrees with the board vision statement. (nirik, 20:22:31) * AGREED: will solicit more proposals and revisit/discuss more next week. (nirik, 20:22:50) * #351 Create a policy for updates - status report on implementation (nirik, 20:23:01) * LINK: https://fedoraproject.org/wiki/Package_update_acceptance_criteria (nirik, 20:24:23) * LINK: https://fedorahosted.org/rel-eng/ticket/3740 (abadger1999, 20:24:26) * LINK: https://fedorahosted.org/bodhi/ticket/433 (nirik, 20:25:32) * LINK: https://fedorahosted.org/bodhi/ticket/434 (nirik, 20:25:35) * FES tickets (nirik, 20:30:38) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 20:30:44) * New Meeting time redux (nirik, 20:37:00) * LINK: http://whenisgood.net/ee8prq (nirik, 20:37:05) * LINK: http://whenisgood.net/ee8prq/results/z5binx is the results (nirik, 20:38:00) * Open Floor (nirik, 20:38:13) Meeting ended at 20:48:30 UTC signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package maintainers -- want test results by mail?
Greetings package maintainers, Want to get notification of any breakage in your just-built koji packages? This includes results of rpmlint [1], rpmguard [2] and, if applicable, initscript [3] tests. Good news, you can now opt-in to receive test results by mail! All you have to do is: 1. Login to fedorapeople.org # ssh fedorapeople.org 2. Run the command: autoqa-optin [] That's it! Thanks to Seth Vidal for the autoqa-optin script and proposed changes to enable this feature. Thanks, James [1] https://fedorahosted.org/pipermail/autoqa-results/2010-April/013903.html [2] https://fedorahosted.org/pipermail/autoqa-results/2010-April/013904.html [3] https://fedorahosted.org/pipermail/autoqa-results/2010-May/020018.html signature.asc Description: This is a digitally signed message part ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Nightly live spins moving on to rawhide
With the release of Fedora 13, the nightly live composes will start tracking rawhide as of today (2010-05-31). See: http://alt.fedoraproject.org/pub/alt/nightly-composes/ For logs, images and more information. kevin signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On 05.04.2010 14:48, Dan Horák wrote: > > I was trying to install i686 variant of F-13 to an Alix board (2D13 with > Geode LX) and got into troubles. The kernel boots fine, but when it > should start initramfs the kernel panics. Everything works well when > using complete F-12 environment and when using F-12 kernel+initramfs > with F-13 rootfs the initramfs stuff runs well, but when I try to > manually chroot into the F-13 from the dracut shell I get an "Invalid > instruction" exception. I though last change in x86 CPU support was in > F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it > explicitly talks about Geode LX as still supported. So the question is > whether F-13 should still work on Geode LX? > Sorry to reopen this old topic, but the conclusion is not obvious. The F13 is out and it seems to have lost support for the Geode LX CPU (cf.http://sharkcz.livejournal.com/5708.html), due to the use of the NOPL instruction by GCC. Will this CPU be supported during F13 and above or should I search for a new distribution ? Regards, Glandvador -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Mail-Mbox-MessageParser/devel Mail-Mbox-MessageParser-1.5002-warning.patch, NONE, 1.1 perl-Mail-Mbox-MessageParser.spec, 1.19, 1.20
Author: pghmcfc
Update of /cvs/pkgs/rpms/perl-Mail-Mbox-MessageParser/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv28172
Modified Files:
perl-Mail-Mbox-MessageParser.spec
Added Files:
Mail-Mbox-MessageParser-1.5002-warning.patch
Log Message:
Fix used-only-once warning that breaks grepmail with perl 5.12.0
Mail-Mbox-MessageParser-1.5002-warning.patch:
MessageParser.pm |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- NEW FILE Mail-Mbox-MessageParser-1.5002-warning.patch ---
--- Mail-Mbox-MessageParser-1.5002/lib/Mail/Mbox/MessageParser.pm
2009-08-09 21:14:47.0 +0100
+++ Mail-Mbox-MessageParser-1.5002/lib/Mail/Mbox/MessageParser.pm
2010-06-01 21:28:41.820260814 +0100
@@ -293,8 +293,7 @@
dprint "Calling \"$filter_command\" to decompress file \"$file_name\".";
- use vars qw(*OLDSTDERR);
- open OLDSTDERR,">&STDERR" or die "Can't save STDERR: $!\n";
+ open my $OLDSTDERR,">&STDERR" or die "Can't save STDERR: $!\n";
open STDERR,">" . File::Spec->devnull()
or die "Can't redirect STDERR to " . File::Spec->devnull() . ": $!\n";
@@ -305,7 +304,7 @@
binmode $file_handle;
- open STDERR,">&OLDSTDERR" or die "Can't restore STDERR: $!\n";
+ open STDERR,">&", $OLDSTDERR or die "Can't restore STDERR: $!\n";
if (eof($file_handle))
{
Index: perl-Mail-Mbox-MessageParser.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Mail-Mbox-MessageParser/devel/perl-Mail-Mbox-MessageParser.spec,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -r1.19 -r1.20
--- perl-Mail-Mbox-MessageParser.spec 3 May 2010 02:05:12 - 1.19
+++ perl-Mail-Mbox-MessageParser.spec 1 Jun 2010 20:43:20 - 1.20
@@ -1,12 +1,13 @@
Summary: A fast and simple mbox folder reader
Name: perl-Mail-Mbox-MessageParser
Version: 1.5002
-Release: 4%{?dist}
+Release: 5%{?dist}
License: GPL+
Group: Development/Libraries
Url: http://search.cpan.org/dist/Mail-Mbox-MessageParser/
Source0:
http://search.cpan.org/CPAN/authors/id/D/DC/DCOPPIT/Mail-Mbox-MessageParser-%{version}.tar.gz
Source1: perl-module-version-filter
+Patch0:Mail-Mbox-MessageParser-1.5002-warning.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: grep, gzip, bzip2, /usr/bin/diff
@@ -23,6 +24,9 @@ information, GNU grep, or highly optimiz
%prep
%setup -q -n Mail-Mbox-MessageParser-%{version}
+# Fix used-only-once warning that breaks grepmail with perl 5.12.0
+%patch0 -p1
+
# Auto provides aren't clever enough for what Mail::Mbox::MessageParser does
%global provfilt /bin/sh -c "%{__perl_provides} | %{__perl} -n -s %{SOURCE1}
-lib=%{_builddir}/%{buildsubdir}/lib"
%define __perl_provides %{provfilt}
@@ -61,6 +65,9 @@ information, GNU grep, or highly optimiz
%{_mandir}/man3/Mail::Mbox::MessageParser::Perl.3pm*
%changelog
+* Tue Jun 1 2010 Paul Howarth 1.5002-5
+- Fix used-only-once warning that breaks grepmail with perl 5.12.0
+
* Mon May 03 2010 Marcela Maslanova - 1.5002-4
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: FC13 nss-softokn-freebl update issues
I don't know when the 3 suffix was added. It may have been due to versioning at some time but if I recall correctly we keep the 3 suffix to avoid a name class with with the other nss package (name switch service I believe). Bob or Kai can set me straight on this matter. Another thing that puzzles me if that this is a problem on F-13 but not on F-12. See comments in https://bugzilla.redhat.com/show_bug.cgi?id=596840 Elio - Original Message - From: "Bill Nottingham" To: "Development discussions related to Fedora" Sent: Tuesday, June 1, 2010 11:48:41 AM GMT -08:00 US/Canada Pacific Subject: Re: FC13 nss-softokn-freebl update issues Elio Maldonado (emald...@redhat.com) said: > Not sure but I strongly suspect a change made to nss.spec to be the cause. > See https://bugzilla.redhat.com/show_bug.cgi?id=596840#c7 It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr libraires) do not fit the normal library naming, so it's not explicitly pulled for multilib. For any update or release set that's composed with a package that explicitly requires a compat arch of nss-softokn-freebl (such as glibc, libpurple, pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13 updates has none of these, so it doesn't. We could add some hacks to mash to get it pulled in, but I must ask... why do all the NSS/NSPR libraries version their libraries in the library name instead of the so version (i.e., libfreebl3.so instead of libfreebl.so.3)? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-05-27 i386
On Tue, Jun 01, 2010 at 08:36:44PM +0100, Richard W.M. Jones wrote: > > Is this a second run after fixing the tmpfs problem? > > I looked at your logs and still see build failures for libguestfs > which are down to 'No space left on device' errors. the run with the tmpfs fix is still in progress. The logs you see now are from earlier. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 01.06.10 15:25, Bill Nottingham (nott...@redhat.com) wrote: > Lennart Poettering (mzerq...@0pointer.de) said: > > > > Requires=basic.target sockets.target dbus.socket > > > > After=basic.target sockets.target dbus.socket > > > > > > What does this goop mean and why is it necessary? > > > > basic.target encapsulates the early boot process (kinda the same stuff > > rc.sysinit currently does). The Requires= make sure that this is pulled > > in by dbus.service. The After= makes sure that it has finished before we > > fork dbus. > > How are these evaluated differently that you'd need to list both 'Requires' > and 'After', as opposed to just one? (I would think Requires would imply > After.) Well, in systemd ordering dependencies are independent of requirement independencies. Explanation: A requires B means that when A is started B is started too, at the same time. A after B means that when A is started and B is started as well, then B is started first and only when that finished A is started too. Now, if you combine both, then you get A requires B + A after B, which means that when A is started we first start B and when that is finished wwe load A too. There are use-cases for all three cases listed above, so we thought we cover this in just two dependency types, instead of three. (And in fact actually, since we have "requires" and "requisite" too, this saves us quite a few additional types) Now, since base.target is pulled in by the default boot target anyway, one could argue that in this case an After= would suffice, and the requires= is redundant. But uh, on a logical level base.target is actually required, so we should list both elements I think. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering wrote: > On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote: >> Well, I really do not want to flame anyone, but please consider that >> the guy proposing the change already gave us pulseaudio, which promised the >> "it will do anything you do now, just easier" feature too. > > Ah, turning this into something personal. Love you too. This is not a personal attack and I want to explain. You will agree with me that pulseaudio caused a lot of complaints. (we do not discuss if motivated or unmotivated, here) That bad reputation unavoidably leads to weaker trust in your promised guarantees. The most painful parts of PA were mainly the underestimation of both "peculiar" use cases and impact of issues in related software (e.g. bugged alsa drivers). It is only natural to be worried about the same things (like lack of customizability) for this new init system. You *are* in a worse position than someone else when proposing a revolution in some critical part of the system. That's no personal offense. On the positive side you are now well aware of the risks you face, so you will probably play it better than someone else. I hope your new init system will be a great success and help you clean your name from the PA mess. I honestly hope so. >> We then discovered that some _trivial_ things where lost: >> - having multiple independent sound cards >> - having control of the mixer >> - having sound with no user logged in >> ... should I also mention latency, CPU usage, stability,...? > > You seem to have no idea what you are talking about. But anyway, let's > not turn this into a discussion about PA. Don't need another one of those. I've been personally been burned by these issues, to the point of going 90% of the way of removing PA from the system (I'm currently running the unrecommended system-wide instance, I manually restart it in some cases, I use often pasuspender and for some things I know I have to turn if off completely). But I'm still on F10 and I read that pulseaudio has become better. Maybe I will be positively surprised when upgrading to F13. >> Linux must NOT be Windows. >> Linux must NOT be OS X. > > Well I for one think we can learn a lot from the competition. Open your > eyes. There's a lot of good stuff in those other OS worlds, particularly > in the designs of MacOS X. There's still so much they do better than we > do. With "must NOT" I do not mean "we have to be far", I mean "we are not obligated to be near". In recent times some stupid (IMHO) ideas have been adopted in Linux just to copy what others do. Just as examples: the control of desktop widgets in KDE4 (functional GUI elements modified by a mouse-over???), the fast-user-switching approach (the Unix way is to have multiple X servers). In conclusion, your innovation is certainly welcome in the Linux world, but disadvantages have to be properly weighted against advantages. If you only list advantages, people is rightly suspicious. You are trying to clarify things: I see you are replying to almost everyone on this thread and that effort has to be appreciated. You even replied to my mail, which you took for a personal attack (which, as I said as first sentence in this and the previous mail, was not). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of packages dependent on perl
On Tue, Jun 01, 2010 at 02:49:52PM +0200, Marcela Mašláňová wrote: > If your package didn't pass rebuild, we (Perl-SIG) will be happy if you > fix it by yourself. If you can't, don't panic. We'll be looking at > packages, which didn't pass. Also you can ask for help at: > perl-de...@lists.fedoraproject.org If anyone fancies having a go at fixing perl4caml .. Debian reported a bug compiling this with Perl 5.12 already: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578800 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-05-27 i386
Is this a second run after fixing the tmpfs problem? I looked at your logs and still see build failures for libguestfs which are down to 'No space left on device' errors. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering (mzerq...@0pointer.de) said: > > > Requires=basic.target sockets.target dbus.socket > > > After=basic.target sockets.target dbus.socket > > > > What does this goop mean and why is it necessary? > > basic.target encapsulates the early boot process (kinda the same stuff > rc.sysinit currently does). The Requires= make sure that this is pulled > in by dbus.service. The After= makes sure that it has finished before we > fork dbus. How are these evaluated differently that you'd need to list both 'Requires' and 'After', as opposed to just one? (I would think Requires would imply After.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
Elio Maldonado (emald...@redhat.com) said: > Not sure but I strongly suspect a change made to nss.spec to be the cause. > See https://bugzilla.redhat.com/show_bug.cgi?id=596840#c7 It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr libraires) do not fit the normal library naming, so it's not explicitly pulled for multilib. For any update or release set that's composed with a package that explicitly requires a compat arch of nss-softokn-freebl (such as glibc, libpurple, pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13 updates has none of these, so it doesn't. We could add some hacks to mash to get it pulled in, but I must ask... why do all the NSS/NSPR libraries version their libraries in the library name instead of the so version (i.e., libfreebl3.so instead of libfreebl.so.3)? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of packages dependent on perl
2010/6/1 Marcela Mašláňová : > Hello maintainers, > I started rebuild of packages dependent on perl. At the moment are packages > rebuilt in > test buildroot dist-f14-perltest. It's quite possible that some will fail > with new perl-5.12.0. > If your package didn't pass rebuild, we (Perl-SIG) will be happy if you fix > it by yourself. If you can't, don't panic. We'll be looking at packages, > which didn't pass. Also you can ask for help at: > perl-de...@lists.fedoraproject.org > > The main changes in perl are mentioned at: > http://perldoc.perl.org/5.12.0/perldelta.html > > Regards, > Marcela > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Will we have perl 5.12.1 in F14 since it was released several weeks ago? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Tue, Jun 01, 2010 at 01:35:20PM +0100, Ilyes Gouta wrote: > Hi, > > I'm still interested in seeing a linjpeg-turbo merger with ijg's own > code base. I'd say that the most performance boost brought in by > libjpeg-turbo is due to the specialized SIMD routines, which > theoretically can be easily merged. libjpeg-turbo has also some > weaknesses such as (as provided from the project's homepage): > Note: Due to the licensing of the two libraries, I think it's more likely that libjpeg-turbo can merge the changes occurring in ijg jpeg than ijg jpeg merging libjpeg-turbo changes. So it might be better for you to look at what libjpeg-8b provides, what the cost is in compatibility, and decide whether we should propose those features be merged into libjpeg-turbo. -Toshio pgp78qRlB8Uvh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/6/2 Paul Wouters : > On Tue, 1 Jun 2010, Bruno Wolff III wrote: > Does FESCO know you'd be willing to become the maintainer? >>> >>> I've definately talked to quite a few of them (online and in person) over >>> the years this has been going on. I even had a tor package made and >>> submitted it, but Enrico and my package crossed paths and his was a day >>> earlier, so his "personal" version instead of a "fedora" version got >>> accepted: >> >> The reason I asked is that they might be more willing to yank the package >> from the current maintainer if there is someone willing to step in and >> fix things rather than having to orphan it. > > I am willing to maintain or co-maintain it, and pull it into compliance > with fedora package guidelines. > > Paul > +1 for you. As the maintainer of vidalia and polipo, I really like to see tor fedora to be more compliance with Fedora package guideline and the tor package from upstream. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/6/1 Bruno Wolff III : >> I've definately talked to quite a few of them (online and in person) over >> the years this has been going on. I even had a tor package made and >> submitted it, but Enrico and my package crossed paths and his was a day >> earlier, so his "personal" version instead of a "fedora" version got >> accepted: > > The reason I asked is that they might be more willing to yank the package > from the current maintainer if there is someone willing to step in and > fix things rather than having to orphan it. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel I'd like to see that fesco can assign some co-maintainers for tor and maybe some more packages from Enrico. Regardless of violating fedora package guideline, his package style is quite strance, e,g, He add noarch documention to tor main package, then leave tor binary into -core subpackage, he also add an useless upstart conf as an alternatives to initsrcipt, the package layout is very different with tor upstream and other packages in fedora. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Tue, 1 Jun 2010, Bruno Wolff III wrote: >>> Does FESCO know you'd be willing to become the maintainer? >> >> I've definately talked to quite a few of them (online and in person) over >> the years this has been going on. I even had a tor package made and >> submitted it, but Enrico and my package crossed paths and his was a day >> earlier, so his "personal" version instead of a "fedora" version got >> accepted: > > The reason I asked is that they might be more willing to yank the package > from the current maintainer if there is someone willing to step in and > fix things rather than having to orphan it. I am willing to maintain or co-maintain it, and pull it into compliance with fedora package guidelines. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Tue, Jun 01, 2010 at 11:48:02 -0400, Paul Wouters wrote: > On Tue, 1 Jun 2010, Bruno Wolff III wrote: > > >>Fixing init scripts and %post is now left in the state "maintainer is too > >>busy to fix". In the past I already offered co-maintainership or taking > >>over the package due to my close relationship with upstream. It's a lame > >>excuse for leaving it in the current state, since that's the preference > >>of the maintainer, which violates fedora packagaging policies. > > > >Does FESCO know you'd be willing to become the maintainer? > > I've definately talked to quite a few of them (online and in person) over > the years this has been going on. I even had a tor package made and > submitted it, but Enrico and my package crossed paths and his was a day > earlier, so his "personal" version instead of a "fedora" version got > accepted: The reason I asked is that they might be more willing to yank the package from the current maintainer if there is someone willing to step in and fix things rather than having to orphan it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Tue, 1 Jun 2010, Bruno Wolff III wrote: >> Fixing init scripts and %post is now left in the state "maintainer is too >> busy to fix". In the past I already offered co-maintainership or taking >> over the package due to my close relationship with upstream. It's a lame >> excuse for leaving it in the current state, since that's the preference >> of the maintainer, which violates fedora packagaging policies. > > Does FESCO know you'd be willing to become the maintainer? I've definately talked to quite a few of them (online and in person) over the years this has been going on. I even had a tor package made and submitted it, but Enrico and my package crossed paths and his was a day earlier, so his "personal" version instead of a "fedora" version got accepted: https://bugzilla.redhat.com/show_bug.cgi?id=175799 https://bugzilla.redhat.com/show_bug.cgi?id=175433 https://bugzilla.redhat.com/show_bug.cgi?id=532373 I don't care who maintains it, as long as we can get the package up to spec so upstream does not feel they need to require to tell their users "don't use the fedora package, use our rpm". That, and the repeated tor discussions on package guidelines violations clearly shows a maintainer issue. I'm getting seriously tired of this tor package discussion every six months. Seriously, just rip out the childish %post crap, and remove all the non-fedora initscript sub package nonsense. This is not the Enrico Project. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 598539] perl-Padre-0.62 bump
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=598539 Petr Pisar changed: What|Removed |Added Depends on||598553 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 598539] perl-Padre-0.62 bump
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=598539 --- Comment #1 from Petr Pisar 2010-06-01 11:29:40 EDT --- Created an attachment (id=418683) --> (https://bugzilla.redhat.com/attachment.cgi?id=418683) CVS tree upgrade to 0.62-1. This is diff against devel CVS tree with 0.62 upgrade. A lot of work has been done to track all dependency changes. All required packages exists in dist-f14-perltest build target on Koji now except perl(PPIx::Regexp) >= 0.005. Fedora does not contain perl-PPIx-Regexp package yet. It must be created to solve this bug request. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 598539] perl-Padre-0.62 bump
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=598539 Petr Pisar changed: What|Removed |Added AssignedTo|mmasl...@redhat.com |ppi...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 598539] New: perl-Padre-0.62 bump
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Padre-0.62 bump https://bugzilla.redhat.com/show_bug.cgi?id=598539 Summary: perl-Padre-0.62 bump Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: ppi...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Target Release: --- Version 0.62 of Padre perl module has been released by upstream. Because current highest Fedora version (0.50) cannot be build against perl-5.12 (planned for Fedora 14) I propose to upgrade perl-Padre in F14 to 0.62 version. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 598539] perl-Padre-0.62 bump
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=598539 Petr Pisar changed: What|Removed |Added URL||http://search.cpan.org/dist ||/Padre/ -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: status of some packages ??
On 05/29/2010 07:25 PM, Xose Vazquez Perez wrote: > JBoss[1] is still a *big* deficit. Potential for f14/15 ? I'm pretty sure JBoss is still a no-go because of poor licensing, specifically: https://bugzilla.redhat.com/show_bug.cgi?id=479598 ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Wx-Perl-ProcessStream/devel .cvsignore, 1.4, 1.5 perl-Wx-Perl-ProcessStream.spec, 1.8, 1.9 sources, 1.4, 1.5
Author: ppisar
Update of /cvs/pkgs/rpms/perl-Wx-Perl-ProcessStream/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv12085
Modified Files:
.cvsignore perl-Wx-Perl-ProcessStream.spec sources
Log Message:
0.27 bump
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Wx-Perl-ProcessStream/devel/.cvsignore,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- .cvsignore 8 Feb 2010 11:39:49 - 1.4
+++ .cvsignore 1 Jun 2010 15:08:38 - 1.5
@@ -1 +1 @@
-Wx-Perl-ProcessStream-0.24.tar.gz
+Wx-Perl-ProcessStream-0.27.tar.gz
Index: perl-Wx-Perl-ProcessStream.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Wx-Perl-ProcessStream/devel/perl-Wx-Perl-ProcessStream.spec,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- perl-Wx-Perl-ProcessStream.spec 7 May 2010 11:07:27 - 1.8
+++ perl-Wx-Perl-ProcessStream.spec 1 Jun 2010 15:08:39 - 1.9
@@ -1,6 +1,9 @@
+# don't run test, because they need gtk display
+%define enable_test 0
+
Name: perl-Wx-Perl-ProcessStream
-Version:0.24
-Release:2%{?dist}
+Version:0.27
+Release:1%{?dist}
Summary:Access IO of external processes via events
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,10 +11,12 @@ URL:http://search.cpan.org/d
Source0:
http://www.cpan.org/authors/id/M/MD/MDOOTSON/Wx-Perl-ProcessStream-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl(Test::More)
+BuildRequires: perl(Archive::Tar)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Time::HiRes) >= 1.2
BuildRequires: perl(Wx) >= 0.5
-BuildRequires: perl(Archive::Tar)
+Requires: perl(Time::HiRes) >= 1.2
Requires: perl(Wx) >= 0.5
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
@@ -23,6 +28,7 @@ possible via STDIN.
%prep
%setup -q -n Wx-Perl-ProcessStream-%{version}
+chmod -x example/*
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -39,8 +45,9 @@ find $RPM_BUILD_ROOT -depth -type d -exe
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-# don't run test, because they need gtk display
-##make test
+%if %enable_test
+make test
+%endif
%clean
rm -rf $RPM_BUILD_ROOT
@@ -52,6 +59,11 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Jun 1 2010 Petr Pisar - 0.27-1
+- 0.27 bump (0.26 breaks API, do not backport to stable distributions)
+- Sort dependencies and parametrize make test
+- Remove executable bit from examples in documentation
+
* Fri May 07 2010 Marcela Maslanova - 0.24-2
- Mass rebuild with perl-5.12.0
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Wx-Perl-ProcessStream/devel/sources,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- sources 8 Feb 2010 11:39:49 - 1.4
+++ sources 1 Jun 2010 15:08:39 - 1.5
@@ -1 +1 @@
-b311a38e4d81f231d1c737501e2b0a63 Wx-Perl-ProcessStream-0.24.tar.gz
+cffddd4ac5118f5d1c6759cae4284e0e Wx-Perl-ProcessStream-0.27.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Mon, May 31, 2010 at 16:55:26 -0400, Paul Wouters wrote: > > Fixing init scripts and %post is now left in the state "maintainer is too > busy to fix". In the past I already offered co-maintainership or taking > over the package due to my close relationship with upstream. It's a lame > excuse for leaving it in the current state, since that's the preference > of the maintainer, which violates fedora packagaging policies. Does FESCO know you'd be willing to become the maintainer? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Tue, Jun 01, 2010 at 01:35:20PM +0100, Ilyes Gouta wrote: > Hi, Hello, > I'm still interested in seeing a linjpeg-turbo merger with ijg's own > code base. I'd say that the most performance boost brought in by > libjpeg-turbo is due to the specialized SIMD routines, which > theoretically can be easily merged. libjpeg-turbo has also some > weaknesses such as (as provided from the project's homepage): You are right, it will be better to join forces together with IJG. But as I wrote earlier, libjpeg-turbo is at my opinion far more ahead than IJG's source and is developed in more open-source manner. Additionally, as Tom Lane wrote, current maintainer of the IJG libjpeg doesn't care about API/ABI compatibility much. > 1. Worse chroma upsampling quality, where libjpeg-turbo is favoring > speed over accuracy when upsamling the chroma components This is not enabled by default, you have to explicitly specify this behavior (TJ_FASTUPSAMPLE parameter). > 2. JPEG's standard restart marker aren't properly handled, in favor of > a faster huffman decoding It is handled properly. When libjpeg-turbo hits restart marker then it must use slower huffman decoder which means 15% - 20% performance drop but is still much faster than IJG's libjpeg. > 3. Asymetric performance gain between 32bit and 64bit arch., which > means specific, per arch. code paths and not algorithmic and > architecture wise tweaks that could benefit all the architectures. Yes, usage of SSE is the main reason why libjpeg-turbo is much more faster than libjpeg. But as written on http://libjpeg-turbo.virtualgl.org/About/Performance, 32bit is slower due small number of registers; those registers are allocated by compiler, it's not assembler code, libjpeg-turbo is currently using same ASM code for both x86 and x64. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Template-Tiny-0.11.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Template-Tiny: 5bb697dff7ff41f6894906233b205560 Template-Tiny-0.11.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 01.06.10 05:53, Mike Fedyk (mfe...@mikefedyk.com) wrote: > On Tue, Jun 1, 2010 at 4:22 AM, Lennart Poettering > wrote: > > On Tue, 01.06.10 01:56, Mike Fedyk (mfe...@mikefedyk.com) wrote: > > > >> > KillMode=control-group → the entire cgroup is shot down > >> > KillMode=process-group → only the process group of the process we forked > >> > is shot down > >> > KillMode=process → only the process we forked is shot down > >> > KillMode=none → nothing is shot down > >> > >> And what is the default? > > > > KillMode=control-group for native services and KillMode=process-group > > for SysV services. > > > > Lennart > > > > Ok, the defaults look good. > > What type of cgroup are you using? Does it impede the use of lxc for > containers? Ie, the cgroup type that systemd needs to be able to be > nested inside a container in a whole OS virtualization (think VPS / > Virtual Private Server where each VPS has root in its container). > > I currently use openvz and lxc (which is similar but based on cgroups) > is getting close to feature pairity. systemd shouldn't get in the way > of being used within a container based on lxc... As Dhaval already pointed out we use our own, named hierarchy, independent of any controller. On top of that we use it recursively: i.e. if you run systemd it will create the service groups beneath the group it itself is running in. That means that systemd should not interfere with any other system (unless you tell it to do so, via some config item), and is nicely recursively stackable. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
> What type of cgroup are you using? Does it impede the use of lxc for > containers? Ie, the cgroup type that systemd needs to be able to be > nested inside a container in a whole OS virtualization (think VPS / > Virtual Private Server where each VPS has root in its container). > systemd uses a named hierarchy without mounting any other subsystem. So no, it does not impede the use of lxc for containers. Dhaval -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, Jun 1, 2010 at 4:22 AM, Lennart Poettering wrote: > On Tue, 01.06.10 01:56, Mike Fedyk (mfe...@mikefedyk.com) wrote: > >> > KillMode=control-group → the entire cgroup is shot down >> > KillMode=process-group → only the process group of the process we forked >> > is shot down >> > KillMode=process → only the process we forked is shot down >> > KillMode=none → nothing is shot down >> >> And what is the default? > > KillMode=control-group for native services and KillMode=process-group > for SysV services. > > Lennart > Ok, the defaults look good. What type of cgroup are you using? Does it impede the use of lxc for containers? Ie, the cgroup type that systemd needs to be able to be nested inside a container in a whole OS virtualization (think VPS / Virtual Private Server where each VPS has root in its container). I currently use openvz and lxc (which is similar but based on cgroups) is getting close to feature pairity. systemd shouldn't get in the way of being used within a container based on lxc... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rebuild of packages dependent on perl
Hello maintainers, I started rebuild of packages dependent on perl. At the moment are packages rebuilt in test buildroot dist-f14-perltest. It's quite possible that some will fail with new perl-5.12.0. If your package didn't pass rebuild, we (Perl-SIG) will be happy if you fix it by yourself. If you can't, don't panic. We'll be looking at packages, which didn't pass. Also you can ask for help at: perl-de...@lists.fedoraproject.org The main changes in perl are mentioned at: http://perldoc.perl.org/5.12.0/perldelta.html Regards, Marcela 389-ds-base ack amanda asterisk backup-manager clamtk claws-mail-plugins clive cluster code2html conmux cpan-upload crypto-utils cyrus-imapd dahdi-tools dnssec-tools docbook2X dxcc epylog exim fcgi foomatic freeradius frozen-bubble gg2 gitolite globus-common globus-gram-job-manager-scripts globus-gram-protocol gnumeric gpsdrive GraphicsMagick graphviz grepmail grid-packaging-tools gscan2pdf hyperestraier ikiwiki ImageMagick imvirt inkscape inn innotop irssi JSDoc krazy2 lcgdm libconcord liboping libprelude libpreludedb maatkit mailgraph mapserver mod_perlite mr munin MySQL-zrm nagios NaturalDocs netcdf-perl net-snmp nginx nocpulse-common ocaml-cil ocaml-perl4caml ocsinventory ocsinventory-agent OpenIPMI openser opensips openwsman p0rn-comfort pacemaker pcsc-perl Perlbal perlbrew pgp-tools pidgin pilot-link pisg po4a postgresql publican qdbm queuegraph remctl remoot renrot.2 rpmconf rpmorphan rrdtool rxvt-unicode samba4 skf smbldap-tools spamassassin Sprog stfl subversion suck swatch sysusage uuid vim virt-v2v xchat xchat-gnome xfconf xls2csv xmms2 Zim zinnia zoneminder -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Hi, I'm still interested in seeing a linjpeg-turbo merger with ijg's own code base. I'd say that the most performance boost brought in by libjpeg-turbo is due to the specialized SIMD routines, which theoretically can be easily merged. libjpeg-turbo has also some weaknesses such as (as provided from the project's homepage): 1. Worse chroma upsampling quality, where libjpeg-turbo is favoring speed over accuracy when upsamling the chroma components 2. JPEG's standard restart marker aren't properly handled, in favor of a faster huffman decoding 3. Asymetric performance gain between 32bit and 64bit arch., which means specific, per arch. code paths and not algorithmic and architecture wise tweaks that could benefit all the architectures. To me, 1. and 2. are a bit worrying, I don't want to scarify standard correctness over a 15% perf. boost. The only items that stands out are the SIMD routines which can be merged with the ijg's official libjpeg, and I think we should push in that direction instead. -Ilyes Gouta On Tue, Jun 1, 2010 at 12:00 PM, Adam Tkac wrote: > On Mon, May 31, 2010 at 12:51:56PM -0400, Orcan Ogetbil wrote: >> On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote: >> > On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote: >> >> >> >> I'm going to create a Fedora feature for this task. >> > >> > Done. You can check >> > http://fedoraproject.org/wiki/Features/libjpeg-turbo. >> > >> >> Thanks. Is there an SRPM we can give it a test? > > Yes, I just created it, check > http://atkac.fedorapeople.org/libjpeg-turbo. I also updated the > feature page because no package linked against current libjpeg needs > to be rebuilt, libjpeg-turbo is API/ABI compatible. You can simply > build & install libjpeg-turbo and you should immediately see > performance benefits. > > If you prefer to test libjpeg-turbo in more conservative way you can > build SRPM and then extract libjpeg.so from it > (`rpm2cpio libjpeg-turbo.rpm | cpio -id`) and simply LD_PRELOAD it. > > Regards, Adam > > -- > Adam Tkac, Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100601 changes
Compose started at Tue Jun 1 08:15:16 UTC 2010 Broken deps for i386 -- almanah-0.7.3-1.fc14.i686 requires libedataserver-1.2.so.12 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 banshee-1.6.1-1.fc14.i686 requires mono(Mono.Addins) = 0:0.4.0.0 banshee-1.6.1-1.fc14.i686 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 banshee-community-extensions-1.6.0-1.fc14.i686 requires mono(Mono.Addins) = 0:0.4.0.0 dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12 esperanza-0.4.0-6.fc13.i686 requires libxmmsclient++.so.3 esperanza-0.4.0-6.fc13.i686 requires libxmmsclient.so.5 f-spot-0.6.2-1.fc14.i686 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 f-spot-0.6.2-1.fc14.i686 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 f-spot-0.6.2-1.fc14.i686 requires mono(Mono.Addins) = 0:0.4.0.0 gbrainy-1.1-6.fc13.i686 requires mono(Mono.Addins) = 0:0.4.0.0 gbrainy-1.1-6.fc13.i686 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 gbrainy-1.1-6.fc13.i686 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 giggle-0.5-1.fc14.i686 requires libedataserver-1.2.so.12 gkrellxmms2-0.7.0-6.20090811git.fc13.i686 requires libxmmsclient.so.5 gnome-do-0.8.3.1-1.fc13.i686 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 gnome-do-0.8.3.1-1.fc13.i686 requires mono(Mono.Addins) = 0:0.4.0.0 gnome-launch-box-0.4-17.fc14.i686 requires libedataserver-1.2.so.12 gnome-phone-manager-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-telepathy-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-python2-evolution-2.30.0-5.fc14.i686 requires libedataserver-1.2.so.12 gxmms2-0.7.0-6.20090811git.fc13.i686 requires libxmmsclient.so.5 iaxclient-devel-2.1-0.5.beta3.fc13.i686 requires liboggz.so.1 iaxclient-devel-2.1-0.5.beta3.fc13.i686 requires liboggz.so.1(liboggz.so.0.2) kobby-1.0-0.3.b4.fc13.i686 requires libinfinity-0.3.so.0 kobby-1.0-0.3.b4.fc13.i686 requires libinftext-0.3.so.0 kphotoalbum-4.1.1-5.fc13.i686 requires libexiv2.so.6 libannodex-0.7.3-13.fc13.i686 requires liboggz.so.1 libannodex-0.7.3-13.fc13.i686 requires liboggz.so.1(liboggz.so.0.2) libfishsound-tools-0.9.1-4.fc12.i686 requires liboggz.so.1 libfishsound-tools-0.9.1-4.fc12.i686 requires liboggz.so.1(liboggz.so.0.2) libqinfinity-1.0-0.2.b4.fc13.i686 requires libinfinity-0.3.so.0 libqinfinity-1.0-0.2.b4.fc13.i686 requires libinftext-0.3.so.0 lxmusic-0.4.2-1.fc13.i686 requires libxmmsclient.so.5 merkaartor-0.15.3-1.fc13.i686 requires libexiv2.so.6 mod_annodex-0.2.2-11.fc12.i686 requires liboggz.so.1 plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch requires jakarta-commons-logging-javadoc qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) >= 0:1.2.4 sonic-visualiser-1.7.1-1.fc13.i686 requires liboggz.so.1 sonic-visualiser-1.7.1-1.fc13.i686 requires liboggz.so.1(liboggz.so.0.2) syncevolution-1.0beta3-2.fc14.i686 requires libedataserver-1.2.so.12 tasks-0.16-3.fc14.i686 requires libedataserver-1.2.so.12 themonospot-gui-qt-0.1.3-6.fc14.i686 requires mono(qt-dotnet) = 0:4.5.0.0 themonospot-gui-qt-0.1.3-6.fc14.i686 requires libqyotoshared.so.1 tomboy-1.2.1-1.fc14.i686 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 tomboy-1.2.1-1.fc14.i686 requires mono(Mono.Addins) = 0:0.4.0.0 tomboy-1.2.1-1.fc14.i686 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libcamel-provider-1.2.so.15 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libcamel-1.2.so.15 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libedataserver-1.2.so.12 vfrnav-0.4-1.fc13.i686 requires libgps.so.18 vifir-0.4-2.fc14.i686 requires libgps.so.18 viking-0.9.91-3.fc13.i686 requires libgps.so.18 Broken deps for x86_64 -- almanah-0.7.3-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) banshee-1.6.1-1.fc14.i686 requires mono(Mono.Addins) = 0:0.4.0.0 banshee-1.6.1-1.fc14.i686 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 banshee-1.6.1-1.fc14.x86_64 requires mono(Mono.Addins) = 0:0.4.0.0 banshee-1.6.1-1.fc14.x86_64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 banshee-community-extensions-1.6.0-1.fc14.x86_64 requires mono(Mono.Addins) = 0:0.4.0.0 dates-0.4.11-3.fc14.x8
Re: Fedora rawhide FTBFS status 2010-05-27 x86_64
Matt Domsch píše v Po 31. 05. 2010 v 12:43 -0500: > Fedora Fails To Build From Source Results for x86_64 > using rawhide from 2010-05-27 > > This is a full rebuild, the first for Fedora 14's rawhide. The > builders all have Fedora 13 installed. > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > cdcollect-0.6.0-10.fc13 (build/make) sharkcz > wxGTK-2.8.11-1.fc14 (build/make) sharkcz,sharkcz these 2 build fine in rawhide (both i386 and x86_64) using mock, they were probably affected by the segfaulting pkgconfig or broken buildroots Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote: > On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: > > > This suggests to me that environment variables isn't the right way to do > > this. > > Environment variables are good for parameters that should be available to > > many > > processes. Command line parameters are better when the parameter is only > > meant > > for one specific process. I can see how looking up two environment > > variables > > may be a smaller patch than adding a parameter to the program's command > > line > > parser, but I still think it should be done with command line > > parameters. > > This is a valid point and we have pondered this for a while and in the > end decided to use environ[] instead of argv[], simply because this > allows us to use the same code for handling it in all daemons, while > handling --listen-fds=xxx in argv would work for some daemons, but not > for others. (i.e. some don't do long getopt, others do it with one dash > only). Also, quite a few projects (rsyslog for example) implement socket > handling in loadable modules, where we have no access to argv[] but do > have access to environ[]. From looking at /etc/rsyslog.conf, rsyslogd already seems to have a means to pass configuration into its modules. Offering the same interface on the command line shouldn't rocket science. > > LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the > > original daemon is restarted but its children live on, then later some > > descendant process may get the same PID as the original daemon, and may try > > to > > handle LISTEN_FDS. The risk may be low, but I always prefer a solution that > > is > > guaranteed to work over one that mostly works. > > Well, this is purely theoretical, since LISTEN_FDS should normally only > be set for daemons that can actually handle this and hence as long as > these are running none of their children can get the same PID. Daemons are known to occasionally go down unplanned and as I read it, systemd is intended to restart them in that case. While child processes could then be killed off via the cgroup to which they belong, this is not always desirable, think of sshd and the children it forks for every login. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote: > On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: > > > This suggests to me that environment variables isn't the right way to do > > this. > > Environment variables are good for parameters that should be available to > > many > > processes. Command line parameters are better when the parameter is only > > meant > > for one specific process. I can see how looking up two environment > > variables > > may be a smaller patch than adding a parameter to the program's command > > line > > parser, but I still think it should be done with command line > > parameters. > > This is a valid point and we have pondered this for a while and in the > end decided to use environ[] instead of argv[], simply because this > allows us to use the same code for handling it in all daemons, while > handling --listen-fds=xxx in argv would work for some daemons, but not > for others. (i.e. some don't do long getopt, others do it with one dash > only). Also, quite a few projects (rsyslog for example) implement socket > handling in loadable modules, where we have no access to argv[] but do > have access to environ[]. From looking at /etc/rsyslog.conf, rsyslogd already seems to have a means to pass configuration into its modules. Offering the same interface on the command line shouldn't be rocket science. > > LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the > > original daemon is restarted but its children live on, then later some > > descendant process may get the same PID as the original daemon, and may try > > to > > handle LISTEN_FDS. The risk may be low, but I always prefer a solution that > > is > > guaranteed to work over one that mostly works. > > Well, this is purely theoretical, since LISTEN_FDS should normally only > be set for daemons that can actually handle this and hence as long as > these are running none of their children can get the same PID. Daemons are known to occasionally go down unplanned and as I read it, systemd is intended to restart them in that case. While child processes could then be killed off via the cgroup to which they belong, this is not always desirable, think of sshd and the children it forks for every login. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 01.06.10 01:56, Mike Fedyk (mfe...@mikefedyk.com) wrote: > > KillMode=control-group → the entire cgroup is shot down > > KillMode=process-group → only the process group of the process we forked is > > shot down > > KillMode=process → only the process we forked is shot down > > KillMode=none → nothing is shot down > > And what is the default? KillMode=control-group for native services and KillMode=process-group for SysV services. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Mon, May 31, 2010 at 12:51:56PM -0400, Orcan Ogetbil wrote: > On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote: > > On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote: > >> > >> I'm going to create a Fedora feature for this task. > > > > Done. You can check > > http://fedoraproject.org/wiki/Features/libjpeg-turbo. > > > > Thanks. Is there an SRPM we can give it a test? Yes, I just created it, check http://atkac.fedorapeople.org/libjpeg-turbo. I also updated the feature page because no package linked against current libjpeg needs to be rebuilt, libjpeg-turbo is API/ABI compatible. You can simply build & install libjpeg-turbo and you should immediately see performance benefits. If you prefer to test libjpeg-turbo in more conservative way you can build SRPM and then extract libjpeg.so from it (`rpm2cpio libjpeg-turbo.rpm | cpio -id`) and simply LD_PRELOAD it. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 597707] please update perl-Software-License to latest upstream release
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=597707 --- Comment #1 from Daniel Berrange 2010-06-01 05:48:36 EDT --- I'm fine with you updating Software::License to the newest upstream version & if you want to use pkgdb to request co-maintainer privs go ahead. If you don't beat me to it I'll find time todo an update in the next day or two. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 02:52 +0200, Lennart Poettering wrote: > On Wed, 26.05.10 14:47, Simo Sorce (sso...@redhat.com) wrote: > > > > environment variables are normally inherited when forking/execing. We > > > want to make sure that only the process we actually start ourselves > > > parses and handles LISTEN_FDS. We want to avoid that if this daemon > > > might spawn some other process, it might get confused into handling > > > LISTEN_FDS, although that env var wasn't actually intended for it. > > > > > > And hence we say that LISTEN_PID should be verified first, and only if > > > it matches LISTEN_FDS should be handled. > > > > If you are mandating behavior in daemons, wouldn't it be simpler to > > mandate the daemon unsets LISTEN_FDS ? > > Yes, our reference implementation actually does that. But we didn't want > to rely on that, simply because handling the environ[] array is so messy, > since memory allocation is not clear and the whole thing is not > thread-safe. In many case environ[] should probably be considered a > read-only data structure during runtime. I beg to differ, at least if we're talking about languages where you are able to just let a single thread run (not sure about Java): Simply document that the daemon should read and unset LISTEN_FDS (using unsetenv() instead of messing with environ manually) while there is only a single thread. That is, if you really must use environment variables for passing that information... Others have mentioned it already: The environment is for information that is meant to be long-lived and shared between processes, it should be feasible to pass this information via a command line option instead. Even more so if handling of the environment is so messy. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Project packages.acl.org.ua - Find Linux Packages
Hi, friends! Let me introduce a project for finding and downloading Linux software and packages. The project provides next features: * Large, daily updated database with RPM and DEB packages for well-known repositories of the Fedora, CentOS, RHEL, Debian, Ubuntu and OpenSuse distributions. * Packages browser by distribution, repository, packages group with the filtering support. * Detailed packages information (name, version, description, architecture, files, requires, etc.). * Detailed packages statistics by project, distribution, repository and packages group. * HTTP/FTP/RSYNC mirrors lists for the packages downloading. * Packages search by name, summary, description, requires, provides, files and directories. * URL shortcuts for the direct packages search. * Multilanguage interface. * Effective site navigation. * XHTML/CSS markup. The project is still under the development. All bugs, suggestions and comments please write to the forum (http://forum.acl.org.ua/). Project site: http://packages.acl.org.ua/ -- With best regards, Nikolay Ulyanitsky http://www.lystor.org.ua -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Mon, May 31, 2010 at 5:32 PM, Lennart Poettering wrote: > On Wed, 26.05.10 09:01, Jeff Spaleta (jspal...@gmail.com) wrote: > >> >> On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering >> wrote: >> > Well, that depends on configuration. >> >> > In systemd you can choose individually for each unit whether you want to >> > allow it to continue run processes on shut down, whether you want the >> > main process killed, the process group to be killed or the cgroup to be >> > killed. >> >> Do you have a service file example yet in systemd git that can be used >> to get an understanding of the various configuration options which >> determine what gets killed and what doesn't? > > Nope, not really. > > But it is as easy as this: when we stop a service the "KillMode=" option > controls whether and how any processes remaining after the "ExecStop=" > command (if there is such a command, and if there are any processes left) > is killed. > > KillMode=control-group → the entire cgroup is shot down > KillMode=process-group → only the process group of the process we forked is > shot down > KillMode=process → only the process we forked is shot down > KillMode=none → nothing is shot down > And what is the default? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
On Mon, May 31, 2010 at 06:58:37PM +0100, Ilyes Gouta wrote: > Hi Adam, Hello Ilyes, > > it also contains bunch of > > pure algorithmic enhancements so even if target platform doesn't > > support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg. > > Can you please give some details on this point? Yes, of course. This topic was discussed on tigervnc-devel ML, check those threads: http://www.mail-archive.com/tigervnc-de...@lists.sourceforge.net/msg00225.html http://www.mail-archive.com/tigervnc-de...@lists.sourceforge.net/msg00403.html As said there, libjpeg-turbo has nearly same performance as Intel's IPP. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Missing deltarpms?
- "Jonathan Dieter" wrote: > It seems that deltarpms aren't being kept from one push to another > for > Fedora 13 (and, also it seems, Fedora 11). For example, there's an > openoffice update, but though there were deltarpms when it first came > out, they've gone now. Where should I report the bug? I don't know what is the intended behavior, but this matters should fall under rel-eng I guess, so you can ask there: http://fedoraproject.org/wiki/ReleaseEngineering > > Jonathan > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Bugzappers Meeting Agenda for 2010-06-01
Event: Fedora Bug Triage Meeting Date: 2010-06-01 Time: 15:00 UTC Location: #fedora-meeting on irc.freenode.net We haven't had a meeting for a while, so let's go for it today! Don't have anything particular on the agenda, though. If anyone has a topic they'd like to discuss, please reply to this email to flag it up. We have some new members since the last meeting, it'd be great to see you new members there so we can welcome you. That's 'welcome' as in 'give you work' =) Additions or corrections to the agenda? Reply to this email. = Agenda = * follow ups * open floor Please do come out for the meeting - it'd be great to see more faces, and we don't bite, we promise! It's a great opportunity to raise any issues you've come across while bugzapping, or ask any questions you might have. See you there! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Archive-RPM/devel .cvsignore, 1.3, 1.4 perl-Archive-RPM.spec, 1.7, 1.8 sources, 1.3, 1.4
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Archive-RPM/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv15365
Modified Files:
.cvsignore perl-Archive-RPM.spec sources
Log Message:
* Thu Apr 29 2010 Marcela Maslanova - 0.05-2
- Mass rebuild with perl-5.12.0
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Archive-RPM/devel/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 14 Feb 2010 05:08:50 - 1.3
+++ .cvsignore 1 Jun 2010 07:26:16 - 1.4
@@ -1 +1 @@
-Archive-RPM-0.05.tar.gz
+Archive-RPM-0.06.tar.gz
Index: perl-Archive-RPM.spec
===
RCS file: /cvs/pkgs/rpms/perl-Archive-RPM/devel/perl-Archive-RPM.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- perl-Archive-RPM.spec 29 Apr 2010 17:59:04 - 1.7
+++ perl-Archive-RPM.spec 1 Jun 2010 07:26:16 - 1.8
@@ -1,6 +1,6 @@
Name: perl-Archive-RPM
-Version:0.05
-Release:2%{?dist}
+Version:0.06
+Release:1%{?dist}
# lib/Archive/RPM.pm -> LGPLv2+
# lib/Archive/RPM/ChangeLogEntry.pm -> LGPLv2+
License:LGPLv2+
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Archive-RPM/devel/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 14 Feb 2010 05:08:50 - 1.3
+++ sources 1 Jun 2010 07:26:16 - 1.4
@@ -1 +1 @@
-89ad4679034bc379942c76d72c8183af Archive-RPM-0.05.tar.gz
+84713eba698fcb30992846dee77a4dc6 Archive-RPM-0.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Archive-RPM-0.06.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-Archive-RPM: 84713eba698fcb30992846dee77a4dc6 Archive-RPM-0.06.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Missing deltarpms?
It seems that deltarpms aren't being kept from one push to another for Fedora 13 (and, also it seems, Fedora 11). For example, there's an openoffice update, but though there were deltarpms when it first came out, they've gone now. Where should I report the bug? Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 6/1/2010 5:45 AM, Lennart Poettering wrote: > Guys, nobody wants to take away configuration options. You can edit the > .service files too, and readjust things. You can even plug in shell > scripts here and there and wherever it suits you. > > There are not plans to make configuration of systemd depndent on gcc or > gdb. That is completely made up. > > Lennart > > Experience in Fedora says that radical changes, even when they achieve their goals, come at a cost. Let us say that we accept your main premises: systemd will be much faster, much more reliable, and a better expenditure of system resources. What we haven't seen from you is a list of what will be lost. 1) Is there anything that currently works which will suddenly stop working? (I am reminded of the cups discussion) 2) Are there tools that will be needed that don't exist yet (or worse, won't exist when systemd is rolled out). 3) Has there been a trial phase with system admins who don't frequent this list or your blog? They are likely to have needs that you haven't anticipated. 4) Is systemd compatible with the functionality of a rescue disk? (I am fishing because I don't know what to expect) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
