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: 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: i386-class support changed in F-13?
On Wed, Jun 2, 2010 at 4:52 AM, Bruno Wolff III br...@wolff.to wrote: On Tue, Jun 01, 2010 at 22:43:25 +0200, Gland Vador glandva...@yahoo.com 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: 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 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: rebuild of packages dependent on perl
On 06/01/2010 07:08 PM, Chen Lei wrote: 2010/6/1 Marcela Mašláňovámmasl...@redhat.com: 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 If everything will be working as expected, then yes. I've already created page for perl as F-14 feature: https://fedoraproject.org/wiki/Features/perl5.12 Marcela -- 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 1, 2010 at 7:47 PM, Rahul Sundaram methe...@gmail.com wrote: 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. I will do. I'll gather up all the bits I have an add it to the ticket. Thanks, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wednesday 02 June 2010 06:12:48 Peter Lemenkov wrote: 2010/6/2 James Laska jla...@redhat.com: 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. +1. Nice idea. But I hope this is the first phase of auto QA development and we will see this integrated to Koji and other Fedora infrastructure in the future. Jaroslav -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On 06/02/2010 12:11 AM, seth vidal wrote: 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 package [release] 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 When owner of package opts-in and I as co-maintainer opt-out, who will get emails? Normally I would assume only owner and other co-maintainers (sans me), but since you mentioned emails are sent to pkgowner alias...Perhaps no one will get email? Please enlighten me. As a side note, I welcome this...and will probably turn it on for most of my packages. Thanks. -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On 06/02/2010 01:08 PM, Jaroslav Reznik wrote: +1. Nice idea. But I hope this is the first phase of auto QA development and we will see this integrated to Koji and other Fedora infrastructure in the future It would also be useful to be able to filter out bogus rpmlint warnings like missing buildroot definitions and so on which are obsolete. For some cases atleast, rpmlint should be fixed instead but in other instances, filtering out warnings so that I don't get mails on them would be useful. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On 02.06.2010 09:19, Peter Robinson wrote: On Tue, Jun 1, 2010 at 7:47 PM, Rahul Sundaram wrote: 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. I will do. I'll gather up all the bits I have an add it to the ticket. Thank you Peter, I hope a solution can be found before the obsolescence of F12. If needed, I'm ready to help. Regards, Glandvador. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On 06/01/2010 10:43 PM, 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], Unless rpmlint starts to use a massively cleaned up set of rules, its results are mostly noise. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Curiosity, Are Cursor Themes that Critical?
Why does: yum erase dmz-cursor-themes --snip-- Remove 211 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) Installed size: 854 M Is this ok [y/N]: n Although I use bluecureve yum erase bluecurve-cursor-theme Remove1 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) Installed size: 3.0 M Is this ok [y/N]: -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Curiosity, Are Cursor Themes that Critical?
On 06/02/2010 02:34 PM, Frank Murphy wrote: Why does: yum erase dmz-cursor-themes --snip-- Remove 211 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) Installed size: 854 M Is this ok [y/N]: n Although I use bluecureve yum erase bluecurve-cursor-theme Remove1 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) Installed size: 3.0 M Is this ok [y/N] The former is the default theme and has been added as a dependency to a core package. You are seeing a cascading set of dependencies as a result. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: timevariant GUI elements (Re: systemd (Was Re: tmpfs for strategic directories))
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: Sorry, I didn't manage to explain me well. I'm referring to the vertical bar which popups at the left of right of _every_ plasmoid. The thing with the close button and which you can drag around to move the plasmoid. It is basically a window title bar done vertically. The bad part is that it popups on mouse movement and creates active elements (buttons) just under your mouse by guessing that you want them. If you have a crowded screen with overlapping windows and plasmoids, you get this popups in your way when you just want to click on a near window. Tooltips in general have this problem (uncontrollable creation of obstructions), but in this case the tooltip even contains clickable elements, so you have to be careful to not click them by error. Be_careful = be_slow_and_think = bad_GUI_concept. The folder view popping up you cited is another bad example (but I was not thinking about that). You say it's only visualization, but it changes the context, in the sense that now my dropping the icon has a new meaning (something randomly changed under my pointer). If the change happens just an instant before I'm releasing the button, my jpg will not go into Friends, but into Friends/DiscardedPhotos. So what should I do? Be careful to not park my pointer on any active area while I'm thinking about where to place my jpg; and every folder is now an active area; my desktop has turned into minesweeper. :-) I think the original idea from Apple was to use the spacebar to enter the directory. That is perfectly acceptable. In my opinion every automatic element (popups and tooltips) should only be allowed to show inactive things (better yet if the obstruction is not complete, for example, by using partial opacity and, if we want to be smart, increasing the opacity when the mouse is near, for legibility). In no case this thing must have clickable items. In no case this thing must intercept clicks: if I click on it the click should go to the elements it is covering (that is where transparency helps), because those elements have earned my attention for some time, before the appearance of the little intruder. The mouse pointer should be blended _below_ the tooltip. Tooltips should just be semitransparent post-it notes attached to my monitor. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: culmus-fonts packaging bug / Non-responsive maintainer
On 2 June 2010 15:19, Michael Schwendt mschwe...@gmail.com wrote: http://bugzilla.redhat.com/570819 A ticket opened on March 5th, but Pravin Satpute just doesn't respond. I am not much clear how to fix it. We will discuss this bug in next fedora fonts meeting. I think we need some attention from upstream for this one. Thanks, Pravin S -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: syslog-ng
Hello, 2010-05-12 17:07 keltezéssel, Daniel J Walsh írta: I'm looking for information, how to get a package (in my case: syslog-ng) updated to the latest available version. First I tried to contact the original syslog-ng packagers directly, but I got no response at all. Here on the list I got some questions about the new syslog-ng version, but while I update my rawhide installation quite often, I still did not see an update for syslog-ng. Now I looked around on the Fedora wiki, how I could to the packaging work myself. I found a page with many interesting details: http://fedoraproject.org/wiki/PackageMaintainers/Join , but this seems to be for packagers joining to add a new package. How could I get an existing package upgraded? Bye, CzP Have you opened a bugzilla requesting the update? I think you need to sign up and work to become a provenpackager. I did not open a bugzilla request yet, but it does not seem to be appropriate any more, as syslog-ng and related libraries seem to be dropped from Fedora (it is the same on FC13 and rawhide): [r...@fedora13 ~]# yum install syslog-ng Loaded plugins: presto, refresh-packagekit Setting up Install Process Resolving Dependencies -- Running transaction check --- Package syslog-ng.i686 0:2.1.4-6.fc12 set to be updated -- Processing Dependency: libevtlog.so.0 for package: syslog-ng-2.1.4-6.fc12.i686 -- Processing Dependency: libnet.so.1 for package: syslog-ng-2.1.4-6.fc12.i686 -- Running transaction check --- Package eventlog.i686 0:0.2.7-4.fc12 set to be updated --- Package libnet.i686 0:1.1.4-3.fc12 set to be updated -- Finished Dependency Resolution Dependencies Resolved Package Arch Version RepositorySize Installing: syslog-ng i686 2.1.4-6.fc12 fedora 138 k Installing for dependencies: eventlogi686 0.2.7-4.fc12 fedora16 k libnet i686 1.1.4-3.fc12 fedora49 k Transaction Summary Install 3 Package(s) Upgrade 0 Package(s) Total download size: 204 k Installed size: 638 k Is this ok [y/N]: Exiting on user Command Complete! [r...@fedora13 ~]# So the question is modified: how can I get it (and the supporting packages) back into Fedora. I have now updated the syslog-ng spec file from Fedora 12 to syslog-ng version 3.1.1 and compiled with mock on FC12 FC13 and Rawhide. These packages work fine, except for SElinux, as there is an additional control socket now and some rlimit settings. I'll have a separate e-mail about it. And a bonus question, as I work now for the upstream developer of syslog-ng: what was the reason for dropping syslog-ng from the distribution? Bye, CzP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: syslog-ng
On 02/06/10 11:56, Peter Czanik wrote: --snip-- And a bonus question, as I work now for the upstream developer of syslog-ng: what was the reason for dropping syslog-ng from the distribution? Bye, CzP No idea but this is when rsyslog was mooted. http://www.redhat.com/archives/fedora-devel-list/2007-July/msg00941.html -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: culmus-fonts packaging bug / Non-responsive maintainer
Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00:
http://bugzilla.redhat.com/570819
A ticket opened on March 5th, but Pravin Satpute just doesn't
respond.
Does anyone know the languages involved here (lang=he, lang=yi)
and can fix this fonts package, please? Thanks in advance.
I will vote that this must be fixed in yum side (or fontconfig or rpm).
This provides is automatically generated by /usr/lib/rpm/fontconfig.prov
and this reads:
13 fcquery=/usr/bin/fc-query
14
15 [ -x $fcquery ] || exit 0
16
17 # filter out anything outside main fontconfig path
18 grep /usr/share/fonts/ |
19 while read fn; do
20 $fcquery --format '%{=pkgkit}' ${fn} 2 /dev/null
21 done
-
So:
$ fc-query --format '%{=pkgkit}' MiriamCLM-Bold.ttf
font(miriamclm)
font(מרים)
font(:lang=he)
font(:lang=yi)
Also:
[tasa...@localhost ~]$ rpm -q vlgothic-p-fonts
vlgothic-p-fonts-20100416-3.fc14.noarch
[tasa...@localhost ~]$ rpm -q --provides vlgothic-p-fonts | grep ゴシック
font(vlpゴシック)
So I guess this issue will affect other fonts related packages.
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: culmus-fonts packaging bug / Non-responsive maintainer
Mamoru Tasaka wrote, at 06/02/2010 08:12 PM +9:00:
Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00:
http://bugzilla.redhat.com/570819
A ticket opened on March 5th, but Pravin Satpute just doesn't
respond.
Does anyone know the languages involved here (lang=he, lang=yi)
and can fix this fonts package, please? Thanks in advance.
I will vote that this must be fixed in yum side (or fontconfig or rpm).
This provides is automatically generated by /usr/lib/rpm/fontconfig.prov
and this reads:
13 fcquery=/usr/bin/fc-query
14
15 [ -x $fcquery ] || exit 0
16
17 # filter out anything outside main fontconfig path
18 grep /usr/share/fonts/ |
19 while read fn; do
20 $fcquery --format '%{=pkgkit}' ${fn} 2 /dev/null
21 done
-
So:
$ fc-query --format '%{=pkgkit}' MiriamCLM-Bold.ttf
font(miriamclm)
font(מרים)
font(:lang=he)
font(:lang=yi)
Also:
[tasa...@localhost ~]$ rpm -q vlgothic-p-fonts
vlgothic-p-fonts-20100416-3.fc14.noarch
[tasa...@localhost ~]$ rpm -q --provides vlgothic-p-fonts | grep ゴシック
font(vlpゴシック)
So I guess this issue will affect other fonts related packages.
By the way מרים (\xd7\x9e\xd7\xa8\xd7\x99\xd7\x9d) itself seems a valid
UTF-8 string.
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: syslog-ng
Hello, 2010-06-02 12:56 keltezéssel, Peter Czanik írta: So the question is modified: how can I get it (and the supporting packages) back into Fedora. I have now updated the syslog-ng spec file from Fedora 12 to syslog-ng version 3.1.1 and compiled with mock on FC12 FC13 and Rawhide. Almost forgot, the sources are available at http://peter.czanik.hu/syslog-ng3.tgz rpmbuild -bs syslog-ng.spec is your friend, if you want a source rpm, I did not want to upload that for three releases... Bye, CzP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: On 06/01/2010 10:43 PM, 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], Unless rpmlint starts to use a massively cleaned up set of rules, its results are mostly noise. Which packages do you maintain where the output has become unmanageable? Thanks, James 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: Package maintainers -- want test results by mail?
On 06/02/2010 01:49 PM, James Laska wrote: On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: On 06/01/2010 10:43 PM, 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], Unless rpmlint starts to use a massively cleaned up set of rules, its results are mostly noise. Which packages do you maintain where the output has become unmanageable? Noise is managable, but ... * Just have a look at the output rpm produces on any arbitrary packages. 90% of the output it produces is just (silly) noise. * Just have a look into most package reviews: Many of them suffer from churn on the (silly) noise rpmlint produces. That's why I consider rpmlint's current ruleset not to be suiteable for automated QA. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of packages dependent on perl
On Tue, Jun 1, 2010 at 9:40 PM, Richard W.M. Jones rjo...@redhat.com wrote: 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 It seems simplest to pretend that SVt_RV still exists on the caml side; attached patch will do just that. -- Iain. SVt_RV.patch Description: Binary data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote: On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: On 06/01/2010 10:43 PM, 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], Unless rpmlint starts to use a massively cleaned up set of rules, its results are mostly noise. Which packages do you maintain where the output has become unmanageable? For myself, I really only think that the spell checks are intolerable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 08:25 -0400, Matthias Clasen wrote: On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote: On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: On 06/01/2010 10:43 PM, 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], Unless rpmlint starts to use a massively cleaned up set of rules, its results are mostly noise. Which packages do you maintain where the output has become unmanageable? For myself, I really only think that the spell checks are intolerable. I think a number of the checks are probably not useful - but I also think we'll learn more about which ones as we get feedback from packagers getting these emails. I think the goal is, of course, to reduce the noise out and focus on making sure the packagers know about the truly broken. :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100602 changes
Compose started at Wed Jun 2 08:15:11 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 bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Attachment::PatchReader) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Search::Quicksearch) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Extension) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Server) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Keyword) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Util) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Field::Choice) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::FlagType) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Flag) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Whine::Query) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Requirements) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Util) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Auth) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Mailer) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::JobQueue) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Constants) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Search) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::JobQueue::Runner) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Error) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Update) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Milestone) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Field) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Component) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Comment) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Auth::Verify::Stack) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Token) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Server::JSONRPC) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Version) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Attachment) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::CPAN) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Status) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Hook) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::DB) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Util) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Filesystem) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Server::XMLRPC) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::User) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Template) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::BugMail) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Chart) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Localconfig) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Product) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Whine::Schedule) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::CGI) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Extension::Example::Util) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Migrate) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Bug) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Classification) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Auth::Login::Stack) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::DB::Schema::Mysql) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Group) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Config::Common) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Series) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::User::Setting) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Config) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Search::Saved) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Constants) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Auth::Persist::Cookie) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::DB::Schema) bugzilla-contrib-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Filesystem) bugzilla-contrib-3.6-1.fc14.noarch requires perl(Bugzilla::Util) bugzilla-contrib-3.6-1.fc14.noarch requires perl(Bugzilla::User) bugzilla-contrib-3.6-1.fc14.noarch requires perl(Bugzilla::DB)
Re: syslog-ng
2010-06-02 14:02 keltezéssel, Petr Lautrbach írta: On 06/02/2010 12:56 PM, Peter Czanik wrote: Hello, 2010-05-12 17:07 keltezéssel, Daniel J Walsh írta: I'm looking for information, how to get a package (in my case: syslog-ng) updated to the latest available version. First I tried to contact the original syslog-ng packagers directly, but I got no response at all. Here on the list I got some questions about the new syslog-ng version, but while I update my rawhide installation quite often, I still did not see an update for syslog-ng. Now I looked around on the Fedora wiki, how I could to the packaging work myself. I found a page with many interesting details: http://fedoraproject.org/wiki/PackageMaintainers/Join , but this seems to be for packagers joining to add a new package. How could I get an existing package upgraded? Bye, CzP Have you opened a bugzilla requesting the update? I think you need to sign up and work to become a provenpackager. I did not open a bugzilla request yet, but it does not seem to be appropriate any more, as syslog-ng and related libraries seem to be dropped from Fedora (it is the same on FC13 and rawhide): You really should open bugzilla request. Done: https://bugzilla.redhat.com/show_bug.cgi?id=598961 [r...@fedora13 ~]# yum install syslog-ng ... Installing: syslog-ng i686 2.1.4-6.fc12 fedora 138 k Installing for dependencies: eventlogi686 0.2.7-4.fc12 fedora16 k libnet i686 1.1.4-3.fc12 fedora49 k So syslog-ng is still there. It wasn't just rebuilt since fc12 as there was no mass rebuild for fc13 and no update by package maintainer. Ah, good to know. I just teach sometimes Fedora/RHEL/CentOS, I never developed for it :-) I package for openSUSE and FreeBSD, where each little change triggers a rebuild of all dependent packages. Last changelog entry is from f12(-rawhide) times: * Tue Sep 15 2009 Ray Van Dolson ra...@fedoraproject.org - 2.1.4-8 - Adjust eventlog build requirement And a bonus question, as I work now for the upstream developer of syslog-ng: what was the reason for dropping syslog-ng from the distribution? It's still there, see https://admin.fedoraproject.org/pkgdb/acls/name/syslog-ng Which is very good news :) Thanks, bye, CzP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On 06/02/2010 02:36 PM, seth vidal wrote: On Wed, 2010-06-02 at 08:25 -0400, Matthias Clasen wrote: On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote: On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: On 06/01/2010 10:43 PM, 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], Unless rpmlint starts to use a massively cleaned up set of rules, its results are mostly noise. Which packages do you maintain where the output has become unmanageable? For myself, I really only think that the spell checks are intolerable. Agreed, these are the most annoying ones. I think a number of the checks are probably not useful - but I also think we'll learn more about which ones as we get feedback from packagers getting these emails. Well, then lets begin: # rpmlint yum yum.noarch: W: self-obsoletion yum-allow-downgrade 1.1.20-0 obsoletes yum-allow-downgrade yum.noarch: W: self-obsoletion yum-basearchonly = 1.1.9 obsoletes yum-basearchonly yum.noarch: W: self-obsoletion yum-plugin-allow-downgrade 1.1.22-0 obsoletes yum-plugin-allow-downgrade yum.noarch: W: self-obsoletion yum-skip-broken = 1.1.18 obsoletes yum-skip-broken yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/pkgtag_db.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/sqlitesack.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/update_md.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/rpmUtils/updates.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/failover.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/packages.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/i18n.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/rpmtrans.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/__init__.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/rpmUtils/transaction.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/share/yum-cli/output.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/share/yum-cli/yummain.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/share/yum-cli/utils.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/metalink.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/share/yum-cli/callback.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/repoMDObject.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/config.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/share/yum-cli/cli.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/rpmsack.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/Errors.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/rpmUtils/__init__.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/history.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/rpmUtils/arch.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/depsolve.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/share/yum-cli/yumcommands.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/callbacks.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/sqlutils.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/rpmUtils/oldUtils.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/rpmUtils/miscutils.py 0644L /usr/bin/python yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/packageSack.py 0644L /usr/bin/python 1 packages and 0 specfiles checked; 31 errors, 5 warnings. Or ... # rpmlint binutils binutils.x86_64: W: spelling-error %description -l en_US addr - add, adder, adds binutils.x86_64: W: shared-lib-calls-exit /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so e...@glibc_2.2.5 binutils.x86_64: W: shared-lib-calls-exit /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so _e...@glibc_2.2.5
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 14:10 +0200, Ralf Corsepius wrote: On 06/02/2010 01:49 PM, James Laska wrote: On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: On 06/01/2010 10:43 PM, 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], Unless rpmlint starts to use a massively cleaned up set of rules, its results are mostly noise. Which packages do you maintain where the output has become unmanageable? Noise is managable, but ... * Just have a look at the output rpm produces on any arbitrary packages. 90% of the output it produces is just (silly) noise. * Just have a look into most package reviews: Many of them suffer from churn on the (silly) noise rpmlint produces. It's a *lint tool. So, depending on one's perspective, all lint tools produce noise. If it's not useful to you, you can choose not to opt-in. Also, if you don't [co-]maintain any packages, this won't be an issue. That's why I consider rpmlint's current ruleset not to be suiteable for automated QA. Agreed, not all packages fit into a neat bucket. But if there are any specifics you can highlight, and if you are interested in making the output more meaningful to a package maintainer, we can start the discussion of how to address the problem. If we never use rpmlint, it won't get any better. Some previously discussed ideas include ... 1. Blacklist - add support so maintainers can specify which results to ignore 2. Only highlighting when rpmlint output regresses - this is intended to help maintainers of unruly packages or packages where rpmlint output has not been monitored/controlled since initial packaging 3. Addressing the concerns raised by the package Thanks, James 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: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 08:36 -0400, seth vidal wrote: I think the goal is, of course, to reduce the noise out and focus on making sure the packagers know about the truly broken. :) Another useful goal might be to only emit errors/warnings for which we can accompany the message with a link to the section in the packaging guidelines that explains how to avoid the problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 09:09 -0400, Kamil Paral wrote: - seth vidal skvi...@fedoraproject.org wrote: I just added autoqa-optout to fedorapeople. it does what you expect it to do and acts just like autoqa-optin Just a minor remark... please add --help. Thanks :) autoqa-optout with no arguments -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-upstart subpackage vs tranditional initscripts
Fedora have upstart as the /sbin/init daemon for a long time, but we still use the old 'SysVinit' scripts from /etc/rc.d/init.d and fedora packaging guideline have nothing about upstart. Is it right for the maintainer to provide two separate subpackages, one with the tranditional rc.d contents and one with an upstart scripts and make the -upstart subpackage have a higher priority over sysinit subpackage? yum list \*-upstart Loaded plugins: downloadonly, presto, refresh-packagekit Installed Packages clamav-scanner-upstart.noarch 0.96-1403.fc14 �...@rawhide Available Packages clamav-milter-upstart.noarch 0.96-1403.fc14 rawhide dhcp-forwarder-upstart.noarch 0.8-1300.fc13 rawhide ip-sentinel-upstart.noarch 0.12-1300.fc13 rawhide milter-greylist-upstart.noarch 4.2.4-1400.fc14 rawhide tor-upstart.noarch 0.2.1.25-1400.fc14 rawhide Regards, Chen Lei -- 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 02, 2010 at 08:19:24 +0100, Peter Robinson pbrobin...@gmail.com wrote: On Tue, Jun 1, 2010 at 7:47 PM, Rahul Sundaram methe...@gmail.com wrote: 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. I will do. I'll gather up all the bits I have an add it to the ticket. Thanks. This issue points out a gap in our QA testing. Fixing it now could end up being painful (if we need to rebuild lots of packages). Catching it earlier would have made that (lots of rebuilds) a lot more palatible. Also the process for changing which instructions gets used in generated code should be looked at. The gcc people should not just be deciding this in a vacuum. Even changing some instructions to emulation could potentially have big performance impacts. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On 06/02/2010 07:43 PM, Bruno Wolff III wrote: This issue points out a gap in our QA testing. Fixing it now could end up being painful (if we need to rebuild lots of packages). Catching it earlier would have made that (lots of rebuilds) a lot more palatible. Fedora 14 will have a new GCC and a mass rebuild anyway. So in this case, we can slip in a change if needed. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 598989] [abrt] crash in perl-Padre-0.50-4.fc13: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
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=598989 --- Comment #2 from Petr Pisar ppi...@redhat.com 2010-06-02 10:35:22 EDT --- Cannot reproduce on Linux to Linux (Xorg, putty or openssh for Linux, Fedora 13). Can you trigger the segfault always or is it random? Does it occur only when pressing F2 to open new window with help for given module or can you crash Padre with opening any other window? It looks more like gtk2 bug with interaction to Hummingbird Exceed X11 server. -- 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: culmus-fonts packaging bug / Non-responsive maintainer
On Wed, Jun 02, 2010 at 08:12:08PM +0900, Mamoru Tasaka wrote: Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00: http://bugzilla.redhat.com/570819 A ticket opened on March 5th, but Pravin Satpute just doesn't respond. Does anyone know the languages involved here (lang=he, lang=yi) and can fix this fonts package, please? Thanks in advance. I will vote that this must be fixed in yum side (or fontconfig or rpm). What's a commandline I can use to reproduce the warning? I can look at converting all of the data into bytes if I know how to test. -Toshio pgpZ0KMxWVsyn.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: culmus-fonts packaging bug / Non-responsive maintainer
Toshio Kuratomi wrote, at 06/02/2010 11:51 PM +9:00: On Wed, Jun 02, 2010 at 08:12:08PM +0900, Mamoru Tasaka wrote: Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00: http://bugzilla.redhat.com/570819 A ticket opened on March 5th, but Pravin Satpute just doesn't respond. Does anyone know the languages involved here (lang=he, lang=yi) and can fix this fonts package, please? Thanks in advance. I will vote that this must be fixed in yum side (or fontconfig or rpm). What's a commandline I can use to reproduce the warning? I can look at converting all of the data into bytes if I know how to test. Well, I just looked at the bug and I don't know how to reproduce this bug exactly. Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-PBS/devel perl-PBS-0.33-obsolete.patch, NONE, 1.1 perl-PBS.spec, 1.10, 1.11
Author: spot
Update of /cvs/pkgs/rpms/perl-PBS/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv4735
Modified Files:
perl-PBS.spec
Added Files:
perl-PBS-0.33-obsolete.patch
Log Message:
fix perl-PBS to build against latest torque (2.4.8)
perl-PBS-0.33-obsolete.patch:
PBS_wrap.c | 196 -
1 file changed, 196 deletions(-)
--- NEW FILE perl-PBS-0.33-obsolete.patch ---
diff -up perl-PBS-0.33/PBS_wrap.c.obsolete perl-PBS-0.33/PBS_wrap.c
--- perl-PBS-0.33/PBS_wrap.c.obsolete 2010-06-02 11:06:38.452350265 -0400
+++ perl-PBS-0.33/PBS_wrap.c2010-06-02 11:07:57.940350269 -0400
@@ -6173,196 +6173,6 @@ XS(_wrap_usepool) {
}
-XS(_wrap_pbs_err_to_txt_err_no_set) {
-char _swigmsg[SWIG_MAX_ERRMSG] = ;
-const char *_swigerr = _swigmsg;
-{
-struct pbs_err_to_txt *arg1 = (struct pbs_err_to_txt *) 0 ;
-int arg2 ;
-int argvi = 0;
-dXSARGS;
-
-if ((items 2) || (items 2)) {
-SWIG_croak(Usage: pbs_err_to_txt_err_no_set(self,err_no););
-}
-{
-if (SWIG_ConvertPtr(ST(0), (void **) arg1,
SWIGTYPE_p_pbs_err_to_txt,0) 0) {
-SWIG_croak(Type error in argument 1 of
pbs_err_to_txt_err_no_set. Expected _p_pbs_err_to_txt);
-}
-}
-arg2 = (int) SvIV(ST(1));
-if (arg1) (arg1)-err_no = arg2;
-
-
-XSRETURN(argvi);
-fail:
-(void) _swigerr;
-}
-croak(_swigerr);
-}
-
-
-XS(_wrap_pbs_err_to_txt_err_no_get) {
-char _swigmsg[SWIG_MAX_ERRMSG] = ;
-const char *_swigerr = _swigmsg;
-{
-struct pbs_err_to_txt *arg1 = (struct pbs_err_to_txt *) 0 ;
-int result;
-int argvi = 0;
-dXSARGS;
-
-if ((items 1) || (items 1)) {
-SWIG_croak(Usage: pbs_err_to_txt_err_no_get(self););
-}
-{
-if (SWIG_ConvertPtr(ST(0), (void **) arg1,
SWIGTYPE_p_pbs_err_to_txt,0) 0) {
-SWIG_croak(Type error in argument 1 of
pbs_err_to_txt_err_no_get. Expected _p_pbs_err_to_txt);
-}
-}
-result = (int) ((arg1)-err_no);
-
-ST(argvi) = sv_newmortal();
-sv_setiv(ST(argvi++), (IV) result);
-XSRETURN(argvi);
-fail:
-(void) _swigerr;
-}
-croak(_swigerr);
-}
-
-
-XS(_wrap_pbs_err_to_txt_err_txt_set) {
-char _swigmsg[SWIG_MAX_ERRMSG] = ;
-const char *_swigerr = _swigmsg;
-{
-struct pbs_err_to_txt *arg1 = (struct pbs_err_to_txt *) 0 ;
-char **arg2 = (char **) 0 ;
-int argvi = 0;
-dXSARGS;
-
-if ((items 2) || (items 2)) {
-SWIG_croak(Usage: pbs_err_to_txt_err_txt_set(self,err_txt););
-}
-{
-if (SWIG_ConvertPtr(ST(0), (void **) arg1,
SWIGTYPE_p_pbs_err_to_txt,0) 0) {
-SWIG_croak(Type error in argument 1 of
pbs_err_to_txt_err_txt_set. Expected _p_pbs_err_to_txt);
-}
-}
-{
-AV *tempav;
-I32 len;
-int i;
-SV **tv;
-
-if (!SvROK(ST(1)))
-croak(ST(1) is not an array.);
-if (SvTYPE(SvRV(ST(1))) != SVt_PVAV)
-croak(ST(1) is not an array.);
-tempav = (AV*)SvRV(ST(1));
-len = av_len(tempav);
-arg2 = (char **) malloc((len+2)*sizeof(char *));
-for (i = 0; i = len; i++) {
-tv = av_fetch(tempav, i, 0);
-arg2[i] = (char *) SvPV(*tv,PL_na);
-}
-arg2[i] = 0;
-}
-if (arg1) (arg1)-err_txt = arg2;
-
-
-{
-free(arg2);
-}
-XSRETURN(argvi);
-fail:
-{
-free(arg2);
-}
-(void) _swigerr;
-}
-croak(_swigerr);
-}
-
-
-XS(_wrap_pbs_err_to_txt_err_txt_get) {
-char _swigmsg[SWIG_MAX_ERRMSG] = ;
-const char *_swigerr = _swigmsg;
-{
-struct pbs_err_to_txt *arg1 = (struct pbs_err_to_txt *) 0 ;
-char **result;
-int argvi = 0;
-dXSARGS;
-
-if ((items 1) || (items 1)) {
-SWIG_croak(Usage: pbs_err_to_txt_err_txt_get(self););
-}
-{
-if (SWIG_ConvertPtr(ST(0), (void **) arg1,
SWIGTYPE_p_pbs_err_to_txt,0) 0) {
-SWIG_croak(Type error in argument 1 of
pbs_err_to_txt_err_txt_get. Expected _p_pbs_err_to_txt);
-}
-}
-result = (char **) ((arg1)-err_txt);
-
-ST(argvi) = sv_newmortal();
-SWIG_MakePtr(ST(argvi++), (void *) result, SWIGTYPE_p_p_char,0);
-XSRETURN(argvi);
-fail:
-(void) _swigerr;
-}
-croak(_swigerr);
-}
-
-
-XS(_wrap_new_pbs_err_to_txt) {
-char _swigmsg[SWIG_MAX_ERRMSG] = ;
-const char *_swigerr = _swigmsg;
-{
-struct pbs_err_to_txt
Re: i386-class support changed in F-13?
On Wed, Jun 2, 2010 at 2:39 AM, Peter Robinson pbrobin...@gmail.com 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. I believe this was the latest post of the NOPL emulation patch: http://lkml.org/lkml/2010/3/1/430 This is not the general instruction emulator mentioned, but a fix intended just for getting the Geode LX classed as i686. I haven't used this patch myself yet; my Geode LX machine runs an older Fedora, so it still works. I suppose I'll need to try the patch during the next upgrade until things are settled. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-05-27 x86_64
On Mon, 2010-05-31 at 12:43 -0500, Matt Domsch wrote: nphilipp: gegl,gtkimageview,ufraw these all built fine as scratch, probably affected by the segfaulting pkgconfig -- 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: i386-class support changed in F-13?
Hi,
On Wed, Jun 2, 2010 at 11:42 AM, Richard W.M. Jones rjo...@redhat.com wrote:
I wonder what the performance impact is. NOPL appears to be a
variable length NOP (no-op). Obviously a very useful instruction for
things like alignment, and gcc seems to stuff lots of them into the
code:
$ objdump -d /bin/ls | wc -l
16867
$ objdump -d /bin/ls | grep nopl | wc -l
369
369/16867 ~ 2%
This is not a very fair comparison because we'd want to know how
frequently NOPL is executed, but I hope it shows that these
instructions are not infrequent.
I recall checking this when F12 was declared to go i686 but retain
support for Geode LX CPUs. NOPLs were common in x86_64, but seemed to
be very infrequent in 32-bit land (which is what would run on a Geode
anyway).
To see if this is still the case, I downloaded and extracted F13's
32-bit coreutils, and no binary appears to contain a single NOPL.
(Though I get a similar result as your test with x86_64.)
objdump -d {,usr/}{,s}bin/* | grep -Fc nopl
0
Having said that, AMD Geodes are sloww anyway ...
I wouldn't exactly use it as a gaming rig, but a silent wireless
computer on 5W power can always be used for something.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 5:21 AM, Patrice Dumas pertu...@free.fr wrote: That being said, it seems that the new init system, systemd is already in the pipe. Doing a policy for an obsolete technology may be some time lost. Maybe even better would be preparing a policy for systemd scripts than doing a policy for upstart vs sysvinit. The only issue I really see is the high priority of the upstart config. Is that deliberately or is that just how it works out because of the package naming which influences the yum depresolution scoring. Whatever the reason I'm The existence of the subpackages aren't strictly a problem necessarily. But they definitely complicate thingsif we want to do more than just ensure the default init system config is installed on the system. Even if systemd becomes the default, I doubt upstart is going to disappear from the repository. Some people are going to want to use it and some maintainers will support it with native configs. The question is how do we make sure the correct init file that is compatible with the init system in use on the system is installed. Assuming moving forward a maintainer has the option to support sysinitv, upstart and systemd, what can be done to make sure the correct init configuration is loaded on the system? Other than including all the configs in the base package..I'm not sure I have a useful suggestion for a solution to selection. And even then, if you have the sysinitv installed side-by-side with the native upstart or systemd config is that going to cause a conflict? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
a11y stack change
Just a heads-up: As part of the ongoing march towards GNOME3, I have switched the accessibility stack to default to the dbus stack (at-spi2-core/at-spi2-atk/pyatspi) instead of the Corba stack (at-spi). Some initial testing shows that orca and caribou seem to work ok. One issue that I've noticed so far is that firefox is unwilling to pop up menus when accessibility is turned on. I am working with the aeccessibility team upstream to resolve this and other issues that will no doubt pop up. If you notice problems that look like they might be related to this change, please let me know. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 19:07 +0300, Ville Skyttä wrote: On Wednesday 02 June 2010, Matthias Clasen wrote: On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote: Which packages do you maintain where the output has become unmanageable? For myself, I really only think that the spell checks are intolerable. There have been some complaints about them. I don't personally think that they're quite intolerable and the noise level should decrease over time as the spell checker dictionaries used by Enchant evolve, but if there's clear consensus that they cause more harm than good, they can be disabled in future default rpmlint package configs. Until then, you can do for example: # Disable Enchant spell check: echo 'setOption(UseEnchant, False)' ~/.config/rpmlint # ...and if you want the internal feeble spell checker msgs gone too: echo 'addFilter(spelling-error)' ~/.config/rpmlint I can personally see the advantage to having warning possible to disable per-pkg/release by the package owners. So that various other powers that be can see what's being filtered out - but so the packager doesn't get annoyed by things which are not useful. heck - I could even see making it so the optin dir could have a 'filter' file with the filters in it - but I think that's a bit much engineering for a first run at things. Especially when the goal is to have a results database with better accounting of this info. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of packages dependent on perl
On Wed, Jun 02, 2010 at 02:25:17PM +0200, Iain Arnell wrote: On Tue, Jun 1, 2010 at 9:40 PM, Richard W.M. Jones rjo...@redhat.com wrote: 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 It seems simplest to pretend that SVt_RV still exists on the caml side; attached patch will do just that. Thanks Iain, I've pushed this upstream. 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 -- 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: culmus-fonts packaging bug / Non-responsive maintainer
On Thu, 03 Jun 2010 00:07:24 +0900, Mamoru wrote: Toshio Kuratomi wrote, at 06/02/2010 11:51 PM +9:00: On Wed, Jun 02, 2010 at 08:12:08PM +0900, Mamoru Tasaka wrote: Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00: http://bugzilla.redhat.com/570819 A ticket opened on March 5th, but Pravin Satpute just doesn't respond. Does anyone know the languages involved here (lang=he, lang=yi) and can fix this fonts package, please? Thanks in advance. I will vote that this must be fixed in yum side (or fontconfig or rpm). What's a commandline I can use to reproduce the warning? I can look at converting all of the data into bytes if I know how to test. Well, I just looked at the bug and I don't know how to reproduce this bug exactly. Most simple test-case: 1) use Fedora 13 2) yum -y install yum-utils 3) repoclosure -n -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 8:37 AM, Lennart Poettering mzerq...@0pointer.de wrote: Handling this with systemd is very easy: you can just drop in a file in /etc/init.d/foo *AND* /etc/systemd/system/foo.service from the same package. And then, if something that is not systemd is booted it will only see the init script. And if systemd is booted it will first look at the native service and ignore the init script if both exist. ALl that matters is that the foo part for both filenames is the same. Cool. When it comes time to put systemd in Fedora, please make sure to note that in the Featuring documentation for packager guidance. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
Once upon a time, Jeff Spaleta jspal...@gmail.com said: On Wed, Jun 2, 2010 at 8:37 AM, Lennart Poettering mzerq...@0pointer.de wrote: Handling this with systemd is very easy: you can just drop in a file in /etc/init.d/foo *AND* /etc/systemd/system/foo.service from the same package. And then, if something that is not systemd is booted it will only see the init script. And if systemd is booted it will first look at the native service and ignore the init script if both exist. ALl that matters is that the foo part for both filenames is the same. Cool. When it comes time to put systemd in Fedora, please make sure to note that in the Featuring documentation for packager guidance. That would require systemd to be installed though, since otherwise /etc/systemd doesn't exist (or every package that wants to drop a file in there has to own it). I guess the directory could be added to chkconfig or even filesystem. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: Well, then lets begin: # rpmlint yum yum.noarch: W: self-obsoletion yum-allow-downgrade 1.1.20-0 obsoletes yum-allow-downgrade [...] yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python [...] Or ... # rpmlint binutils binutils.x86_64: W: spelling-error %description -l en_US addr - add, adder, adds binutils.x86_64: W: shared-lib-calls-exit /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so e...@glibc_2.2.5 binutils.x86_64: W: shared-lib-calls-exit /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so _e...@glibc_2.2.5 binutils.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libopcodes-2.20.51.0.2-20.fc13.so /lib64/libz.so.1 binutils.x86_64: W: no-manual-page-for-binary ld.bfd binutils.x86_64: W: no-manual-page-for-binary ld.gold binutils.x86_64: W: dangerous-command-in-%post rm 1 packages and 0 specfiles checked; 0 errors, 7 warnings. Which of those messages do you consider noise and why? Most of them look valid to me, though they are indeed nits. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
about php-qa, phpUnderControl and meta packages
I am reposting this from fedora php-devel list to get a bigger audience. My questions are not that PHP specific: I got two questions regarding my effort to package more of the php-qa packages for fedora. I have made a package for phpUnderControl now, but to use it you still have to install CruiseControl by hand. phpUnderControl also patches the CruisceControl installation, so it isn't something that can easily packaged as an RPM. Does it still make sense to bring phpUnderControl into Fedora even though it requires an external software package? Second question: I would love to have a meta package which brings all of these packages ( phpunit, phpmd, phpcpd, phpdoc, phpcs, Mockery, ...) together and allows installation with one yum command. But as far as I could detect from the random posts it seems that meta packages are not really wanted on Fedora. An alternative is the comps list, but that doesn't allow for rapid changes and phpqa would be a bit specific. A third option would be to make something like phpUnderControl require all of these. The pear package already suggests some of them, but it isn't a hard require. My final goal is to make Fedora the best development environment for PHP, where you can get the full set-up of tools just with a few (or one) yum command. Ideally this would work on RHEL too, but I guess not before 6.0 and not for much after that because the shipped PHP release will too old again. With the Remi repository it would also work on older RHEL. Any suggestions are welcome :-) Cheers, Christof -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, Jun 02, 2010 at 01:25:01PM -0400, Matt McCutchen wrote: On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python Which of those messages do you consider noise and why? Most of them look valid to me, though they are indeed nits. Bash completion files are imho either always or never config files. So it is either an error that needs to be fixed or not worth a warning. And I doubt that python scripts in below /usr/lib/python2.6/site-packages usually need to be executable. Since yum works without any problems, these tons of errors are useless, too. And they make it only harder to find real errors. I did not think more about the other quoted rpmlint messages. Regards Till pgpKWg40VPXot.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 Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: And I doubt that python scripts in below /usr/lib/python2.6/site-packages usually need to be executable. Since yum works without any problems, these tons of errors are useless, too. And they make it only harder to find real errors. I did not think more about the other quoted rpmlint messages. It's complaining because the files have #! in them, likely to assist in self tests, but the files aren't marked as executable. That could actually be fixed upstream, either mark them as executable or remove the #!s. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Curiosity, Are Cursor Themes that Critical?
On Wed, Jun 02, 2010 at 02:42:08AM +0530, Rahul Sundaram said The former is the default theme and has been added as a dependency to a core package. You are seeing a cascading set of dependencies as a result. Should that be done through comps? It's not a really required for functionality of those packages since there's always the possiblity to fall back to the old builtin bitmap cursors right? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, Jun 02, 2010 at 10:46:51AM -0700, Jesse Keating wrote: On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: And I doubt that python scripts in below /usr/lib/python2.6/site-packages usually need to be executable. Since yum works without any problems, these tons of errors are useless, too. And they make it only harder to find real errors. I did not think more about the other quoted rpmlint messages. It's complaining because the files have #! in them, likely to assist in self tests, but the files aren't marked as executable. That could actually be fixed upstream, either mark them as executable or remove the #!s. I understand the rpmlint test, but I do not understand why this needs to be handled upstream or why this is any problem at all. Are there packages with executable files in the python-sitelib that need to be executable or are used by users of the installed package as executables? Regards Till pgp7eG5iYbcqM.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
Chen Lei wrote: Is it right for the maintainer to provide two separate subpackages, one with the tranditional rc.d contents and one with an upstart scripts and make the -upstart subpackage have a higher priority over sysinit subpackage? No. This is against our packaging guidelines. You'll notice that all the offending packages are by the same maintainer (you easily recognize them from the ridiculous Release versions). All those -upstart and -lsb subpackages must go away and the -sysv subpackages must be merged into the main package. Kevin Kofler -- 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 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-06-02 13:58:10 EDT --- perl-Software-License-0.101410-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Software-License'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-Software-License-0.101410-1.fc12 -- 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: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: On Wed, Jun 02, 2010 at 01:25:01PM -0400, Matt McCutchen wrote: On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash yum.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python Which of those messages do you consider noise and why? Most of them look valid to me, though they are indeed nits. Bash completion files are imho either always or never config files. So it is either an error that needs to be fixed or not worth a warning. The right thing to do is to file a bug against bash-completion to get that decision made and then implement it, either by marking the file as config or moving /etc/bash_completion.d to /usr/share. The warning is not wrong. -- Matt -- 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 #6 from Fedora Update System upda...@fedoraproject.org 2010-06-02 14:10:01 EDT --- perl-Software-License-0.101410-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Software-License'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-Software-License-0.101410-1.fc13 -- 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: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Tue 1 June 2010 8:48:02 am Paul Wouters wrote: 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. Halfway there, if you're up for testing: https://bugzilla.redhat.com/show_bug.cgi?id=598213#c3 Ryan -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == 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: -upstart subpackage vs tranditional initscripts
On Wed, 2010-06-02 at 20:00 +0200, Kevin Kofler wrote: Chen Lei wrote: Is it right for the maintainer to provide two separate subpackages, one with the tranditional rc.d contents and one with an upstart scripts and make the -upstart subpackage have a higher priority over sysinit subpackage? No. This is against our packaging guidelines. Where do you see that? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 10:46 -0700, Jesse Keating wrote: On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: And I doubt that python scripts in below /usr/lib/python2.6/site-packages usually need to be executable. Since yum works without any problems, these tons of errors are useless, too. And they make it only harder to find real errors. I did not think more about the other quoted rpmlint messages. It's complaining because the files have #! in them, likely to assist in self tests, but the files aren't marked as executable. That could actually be fixed upstream, either mark them as executable or remove the #!s. I've considered removing them in upstream just to shut rpmlint up. As irritating as that is. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 13:25 -0400, Matt McCutchen wrote: On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: Well, then lets begin: # rpmlint yum yum.noarch: W: self-obsoletion yum-allow-downgrade 1.1.20-0 obsoletes yum-allow-downgrade [...] Which of those messages do you consider noise and why? Most of them look valid to me, though they are indeed nits. The self obsolete ones are wrong, being able to do: Name: foo Provide: bar = 2 Obsolete: bar = 2 ...is completely legal and needed for rename/merging which is why yum has them. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
2010/6/3 Matt McCutchen m...@mattmccutchen.net: On Wed, 2010-06-02 at 20:00 +0200, Kevin Kofler wrote: Chen Lei wrote: Is it right for the maintainer to provide two separate subpackages, one with the tranditional rc.d contents and one with an upstart scripts and make the -upstart subpackage have a higher priority over sysinit subpackage? No. This is against our packaging guidelines. Where do you see that? -- Matt I'm not sure about whether ship upstart scripts violate our guidelines, but fedora package guideline has - Currently, only SystemV-style initscripts are supported in Fedora. http://fedoraproject.org/wiki/PackagingGuidelines#Initscripts Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 19:59 +0200, Till Maas wrote: On Wed, Jun 02, 2010 at 10:46:51AM -0700, Jesse Keating wrote: On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: And I doubt that python scripts in below /usr/lib/python2.6/site-packages usually need to be executable. Since yum works without any problems, these tons of errors are useless, too. And they make it only harder to find real errors. I did not think more about the other quoted rpmlint messages. It's complaining because the files have #! in them, likely to assist in self tests, but the files aren't marked as executable. That could actually be fixed upstream, either mark them as executable or remove the #!s. I understand the rpmlint test, but I do not understand why this needs to be handled upstream or why this is any problem at all. Are there packages with executable files in the python-sitelib that need to be executable or are used by users of the installed package as executables? *shrug* I suppose it's worth checking with upstream over it. And discussing whether that rpmlint rule should be removed in our build. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: -upstart subpackage vs tranditional initscripts
Lennart Poettering wrote: We wanted to make the transition from sysv to systemd very easy, and I think this is the simplemost scheme we could come up with. During a transition period packages should just ship both files and it'll work with both init systems. s/systemd/upstart/ This is not the first time this has been said. Even though there may not be an initiative to switch from sysv to upstart, why do you feel so strongly that people will switch from sysv to systemd? Are you going to implement a Fedora policy that bans sysv, say, in Fedora 16? That's about the only way you could make it happen. If you can make everyone move away from sysv to something else, then by all means I'll do my best to aid in patches, but I don't have much confidence since everything that has been said about systemd has been said of upstart a few years ago. Instead of reinventing the wheel time and time again, there are other features that deserve attention. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, Jun 02, 2010 at 07:59:22PM +0200, Till Maas wrote: On Wed, Jun 02, 2010 at 10:46:51AM -0700, Jesse Keating wrote: On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: And I doubt that python scripts in below /usr/lib/python2.6/site-packages usually need to be executable. Since yum works without any problems, these tons of errors are useless, too. And they make it only harder to find real errors. I did not think more about the other quoted rpmlint messages. It's complaining because the files have #! in them, likely to assist in self tests, but the files aren't marked as executable. That could actually be fixed upstream, either mark them as executable or remove the #!s. I understand the rpmlint test, but I do not understand why this needs to be handled upstream or why this is any problem at all. Are there packages with executable files in the python-sitelib that need to be executable or are used by users of the installed package as executables? I think that was a list of three ways to fix the issue. As for not fixing the issue at all, that is probably a valid fourth option in most cases where python-sitelib is involved. What follows is just how I handle things, not how they must be handled: I like to get rid of the #! lines where the file in question is never going to be run as a script (It's just classes and functions, there's nothing in it to actually run and do anything). I submit these upstream and they are generally merged quickly. Marking as executable can be done when the module could be run as a script by a knowledgable user (one that knows that /usr/ib/python2.6/site-packages/foo/profiler.py can also be invoked from the command line) to do something they want. When the shebang is to allow running some sort of unittest I generally just leave it alone (the end user won't want to run it and upstream does want to run the code when they're testing). I generally try to remove as many rpmlint warnings as I can so that I can more plainly tell when something actually has regressed but in most cases involving python-sitelib, you don't gain anything from dealing with this warning. -Toshio pgp7ti7QFPiz6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
On 06/01/2010 11:48 AM, Bill Nottingham wrote: 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)? Because upstream selected it's names before linux naming was anything like widespread. nss/nspr upstream was also unusual in considering binary compatibility breakage a sev 1 bug. It's expected that old apps run against new versions. One good side effect of this is there is no name colision in the libraries between Network Security Services and Name Switch Select, nor NSS's libssl3.so and openssl's libssl.so. bob smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
suggestion: rescue boot extension
Folks, There are various projects implementing LiveCD, rescue, or snapshotted updates. I would like to propose a feature in which some of the rescue/LiveCD bits are (optionally) installed to a spare volume during install such that there's always a rescue/Live boot option that can boot up to a recovery desktop without needing to grab media, etc. Modern disks are large and cheap (even some SSDs). I can't see a downside and it helps with all manner of botched updates. Snapshots help aswell, but there are many times where you just want something more than a single user boot to fix some breakage. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, 02.06.10 13:43, Michael Cronenworth (m...@cchtml.com) wrote: Lennart Poettering wrote: We wanted to make the transition from sysv to systemd very easy, and I think this is the simplemost scheme we could come up with. During a transition period packages should just ship both files and it'll work with both init systems. s/systemd/upstart/ This is not the first time this has been said. You are surprised that I believe in the software I am writing? 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: -upstart subpackage vs tranditional initscripts
Michael Cronenworth m...@cchtml.com writes: If you can make everyone move away from sysv to something else, then by all means I'll do my best to aid in patches, but I don't have much confidence since everything that has been said about systemd has been said of upstart a few years ago. Instead of reinventing the wheel time and time again, there are other features that deserve attention. Quite. As a packager looking on from the sidelines, this discussion leaves me wondering why I should expend my non-copious free time on implementing upstart^H^H^Hsystemd^H^H^Hmaybe something else next year init scripts. I'll just stick with the tested sysv ones, thanks. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, 02.06.10 15:27, Tom Lane (t...@redhat.com) wrote: Michael Cronenworth m...@cchtml.com writes: If you can make everyone move away from sysv to something else, then by all means I'll do my best to aid in patches, but I don't have much confidence since everything that has been said about systemd has been said of upstart a few years ago. Instead of reinventing the wheel time and time again, there are other features that deserve attention. Quite. As a packager looking on from the sidelines, this discussion leaves me wondering why I should expend my non-copious free time on implementing upstart^H^H^Hsystemd^H^H^Hmaybe something else next year init scripts. I'll just stick with the tested sysv ones, thanks. Well, while I do object to this kind of conservative thinking I am actually not opposed to the conclusion. i.e. it's fine if people just ship sysv in most cases. It's fine to have a slow transition. As long as the core packages have native scripts and even socket-based activation we already win a lot. But anyway, we probably should not continue the systemd discussion here, at this time. 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: FC13 nss-softokn-freebl update issues
Robert Relyea (rrel...@redhat.com) said:
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)?
Because upstream selected it's names before linux naming was anything
like widespread.
nss/nspr upstream was also unusual in considering binary compatibility
breakage a sev 1 bug. It's expected that old apps run against new versions.
One good side effect of this is there is no name colision in the
libraries between Network Security Services and Name Switch Select, nor
NSS's libssl3.so and openssl's libssl.so.
OK. Copying from the bug:
There are two 'simple' fixes for this that don't involve hotfixing the push
infrastructure:
1) For all nss/nspr packages that don't have .so symlinks in their devel
packages, add %{?_isa} to the requires in the devel packages.
See https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires for
a packaging draft for this.
For example, that would change, in nss-softokn-freebl-devel:
Requires: nss-softokn-freebl = %{version}-%{release}
to:
Requires: nss-softokn-freebl%{?_isa} = %{version}-%{release}
in nss-softokn-freebl-devel,
Requires: nss-softokn = %{version}-%{release}
to
Requires: nss-softokn%{?_isa} = %{version}-%{release}
in nss-softokn-devel, and so on.
The reason this is needed is that for most -devel pacakges, there is automatic
dependencies added on the proper library package due to following the '.so'
devel symlink to the main library. This doesn't work for nss/nspr, as the
-devel packages don't have these symlinks.
2) Wait for either of https://admin.fedoraproject.org/updates/glibc-2.12-2 or
https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed to
stable, as those will pull in the i686 nss-softokn-freebl through library
dependencies.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Jon Masters (jonat...@jonmasters.org) said: There are various projects implementing LiveCD, rescue, or snapshotted updates. I would like to propose a feature in which some of the rescue/LiveCD bits are (optionally) installed to a spare volume during install such that there's always a rescue/Live boot option that can boot up to a recovery desktop without needing to grab media, etc. Modern disks are large and cheap (even some SSDs). I can't see a downside and it helps with all manner of botched updates. Snapshots help aswell, but there are many times where you just want something more than a single user boot to fix some breakage. Hm. I can see the use of this, but I can also see issues with how you do updates for it sanely (if at all.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 15:54 -0400, Bill Nottingham wrote: Jon Masters (jonat...@jonmasters.org) said: There are various projects implementing LiveCD, rescue, or snapshotted updates. I would like to propose a feature in which some of the rescue/LiveCD bits are (optionally) installed to a spare volume during install such that there's always a rescue/Live boot option that can boot up to a recovery desktop without needing to grab media, etc. Modern disks are large and cheap (even some SSDs). I can't see a downside and it helps with all manner of botched updates. Snapshots help aswell, but there are many times where you just want something more than a single user boot to fix some breakage. Hm. I can see the use of this, but I can also see issues with how you do updates for it sanely (if at all.) Yea. I think you don't do updates for it in general. I think I agree with Seth that this is something Anaconda stuffs in place when it installs grub. Optionally, maybe you upgrade it once per release when you next run Anaconda, but basically it doesn't change. It's about get me booted to more than a command line to fix stuff, not latest glitz. That said, of course eventually you could have two of these images and allow for them to be upgraded, etc. etc. To start with though, I think there's a lot of value in pre-committing a couple hundred MB of disk space to having a rescue environment always on. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Hm. I can see the use of this, but I can also see issues with how you do updates for it sanely (if at all.) Why would you do updates for it? Your install CD/DVD to use for rescue boot doesn't get updated. I'd think you'd just install a pristine newer one verbatim if you had a reason to bother, like deciding to burn a new CD. Hence the nice automagic deployment feature would reserve two partitions (or whatevers) for the purpose, so you can install the new image on B and still have the option to boot A if the new one is bad. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote: Hm. I can see the use of this, but I can also see issues with how you do updates for it sanely (if at all.) Why would you do updates for it? Your install CD/DVD to use for rescue boot doesn't get updated. I'd think you'd just install a pristine newer one verbatim if you had a reason to bother, like deciding to burn a new CD. Hence the nice automagic deployment feature would reserve two partitions (or whatevers) for the purpose, so you can install the new image on B and still have the option to boot A if the new one is bad. So I'm willing to help out on this (once RHEL stuff calms down a bit). Do you think it's worth us putting together a wiki feature proposal? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 10:43 AM, Michael Cronenworth m...@cchtml.com wrote: Lennart Poettering wrote: If you can make everyone move away from sysv to something else, then by all means I'll do my best to aid in patches, but I don't have much confidence since everything that has been said about systemd has been said of upstart a few years ago. Instead of reinventing the wheel time and time again, there are other features that deserve attention. I think its really premature to talk about any situation where we forcibly drop sysv compatibility. Way way premature. It may never be possible in reality. You'll note that so far we haven't actually encouraged the use of upstart native scripts. It's difficult to see how one could lose confidence based on our upstart experience when the reality is we've barely moved away from sysv. We have just a few native upstart scripts. We've essentially been running upstart in sysv compatibility mode putting nearly zero demands on casual packagers to do anything with regard to making init scripts native. That's actually part of the problem with upstart, its lingered for so long in a sort of compatibility mode that its not clear what the realizable benefits actually are. I don't think I've seen any quantitative analysis of the impact of upstart native configs in any real deployment scenario. This is one of the things I'm looking forward to seeing in future systemd discussion. I fully expect that systemd integration to start in a sysv compatibility mode..but with real native configuration usage up front in enough components for us to work with so we can all get a taste of the impact. I fully anticipate systemd sysv compatibility mode as a priority to make sure no casual maintainer is forced to build native configs out of the gate on their own. i fully expect, and trust, that the people who really grok systemd are going to be heavily involved with ensuring the first set of native systemd services are exemplary examples for the rest of us to follow...and to do our best to break. If the wins are obvious, then work on native configs will snowball based on a desire to maximize the achievable benefits. All Lennart is saying is that systemd will have a better experience for packagers while we are navigating the switch-over period. We won't have to play games with subpackages..we ship both sysv and native systemd in the same package. Eventually Fedora project leadership may decide that native configs will be required for new packages or what not as a policy decision...but that discussion is a long long long way off. Let's just see if we can actually get systemd in early into F14 testing, relying on sysv compatibility primarily so we can feel comfortable that its been well tested. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wednesday 02 June 2010, James Antill wrote:
The self obsolete ones are wrong, being able to do:
Name: foo
Provide: bar = 2
Obsolete: bar = 2
...is completely legal and needed for rename/merging
Yes (assuming you mean Obsoletes: bar 2, not = 2).
which is why yum has them.
yum does not have them like that. The Provides in it are unversioned.
Obsoletes: yum-skip-broken = 1.1.18
Obsoletes: yum-basearchonly = 1.1.9
Obsoletes: yum-allow-downgrade 1.1.20-0
Obsoletes: yum-plugin-allow-downgrade 1.1.22-0
Obsoletes: yum-plugin-protect-packages 1.1.27-0
Provides: yum-skip-broken
Provides: yum-basearchonly
Provides: yum-allow-downgrade
Provides: yum-plugin-allow-downgrade
Provides: yum-protect-packages
Provides: yum-plugin-protect-packages
Fix: sed -i -e 's/\(Provides.*\)/\1 = %{version}-%{release}/' yum.spec
Self-obsoletion used to cause problems in various tools in the past. I don't
know if all of them contain workarounds nowadays, but on the other hand I
don't think I've ever seen an actual valid use case for self-obsoletion.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wednesday 02 June 2010, Matt McCutchen wrote: The right thing to do is to file a bug against bash-completion to get that decision made and then implement it, either by marking the file as config or moving /etc/bash_completion.d to /usr/share. The warning is not wrong. Moving to /usr/share is likely to happen in a not-too-distant-future bash- completion upstream release. /etc/bash_completion.d will however almost certainly be kept around for backwards compatibility for some time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: Jon Masters wrote: On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote: Hm. I can see the use of this, but I can also see issues with how you do updates for it sanely (if at all.) Why would you do updates for it? Your install CD/DVD to use for rescue boot doesn't get updated. I'd think you'd just install a pristine newer one verbatim if you had a reason to bother, like deciding to burn a new CD. Hence the nice automagic deployment feature would reserve two partitions (or whatevers) for the purpose, so you can install the new image on B and still have the option to boot A if the new one is bad. So I'm willing to help out on this (once RHEL stuff calms down a bit). Do you think it's worth us putting together a wiki feature proposal? Jon. Is it better to have a separate volume for this, or to just have a sort of rescue initramfs ...? Or if you are able to run a little bit of C code[1] and can read files from the root partition (as grub can), you can build one on the fly using binaries, libraries etc found on the root disk, which is what we do in libguestfs. Rich. [1] http://git.annexia.org/?p=febootstrap.git;a=blob;f=febootstrap-supermin-helper.c;hb=HEAD -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Richard W.M. Jones wrote: On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: Jon Masters wrote: On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote: Hm. I can see the use of this, but I can also see issues with how you do updates for it sanely (if at all.) Why would you do updates for it? Your install CD/DVD to use for rescue boot doesn't get updated. I'd think you'd just install a pristine newer one verbatim if you had a reason to bother, like deciding to burn a new CD. Hence the nice automagic deployment feature would reserve two partitions (or whatevers) for the purpose, so you can install the new image on B and still have the option to boot A if the new one is bad. So I'm willing to help out on this (once RHEL stuff calms down a bit). Do you think it's worth us putting together a wiki feature proposal? Jon. Is it better to have a separate volume for this, or to just have a sort of rescue initramfs ...? Or if you are able to run a little bit of C code[1] and can read files from the root partition (as grub can), you can build one on the fly using binaries, libraries etc found on the root disk, which is what we do in libguestfs. which then solves the how do I update it? problem. (of course if you're trying to recover from an update that borked your system, I guess you hope you didn't update the rescue recently!) -Eric Rich. [1] http://git.annexia.org/?p=febootstrap.git;a=blob;f=febootstrap-supermin-helper.c;hb=HEAD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wednesday 02 June 2010, Ralf Corsepius wrote: binutils.x86_64: W: spelling-error %description -l en_US addr - add, adder, adds This is a genuine bug, I'll try to have a look into and/or work around it. Enchant appears to tokenize addr2line into two words and naturally ends up flagging the addr part as a misspelling. On a quick look the rest of messages you posted seem to be something that should just be fixed in the respective packages, or flag potentially questionable things that packagers should double check, possibly with upstream. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 21:22 +0100, Richard W.M. Jones wrote: On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: Is it better to have a separate volume for this, or to just have a sort of rescue initramfs ...? Or if you are able to run a little bit of C code[1] and can read files from the root partition (as grub can), you can build one on the fly using binaries, libraries etc found on the root disk, which is what we do in libguestfs. I specifically think this is not the solution :) It's great for libguestfs, but the idea here is to have known-good binaries that can be used to recover a system - and that change very rarely indeed (on the same order as the physical media containing the installer) - when it is broken during an update or otherwise. If the system is already busticated, then building images from it will not help. A recovery initramfs could be used. It could just basically be the rescue mode anaconda bits in one image shoved in place to start. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: culmus-fonts packaging bug / Non-responsive maintainer
On Wed, Jun 02, 2010 at 06:49:53PM +0200, Michael Schwendt wrote: On Thu, 03 Jun 2010 00:07:24 +0900, Mamoru wrote: Toshio Kuratomi wrote, at 06/02/2010 11:51 PM +9:00: On Wed, Jun 02, 2010 at 08:12:08PM +0900, Mamoru Tasaka wrote: Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00: http://bugzilla.redhat.com/570819 Most simple test-case: 1) use Fedora 13 2) yum -y install yum-utils 3) repoclosure -n Thanks! patch for yum attached to the bug. -Toshio pgpMl4BxPR088.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On 06/02/2010 04:02 PM, Jon Masters wrote: That said, of course eventually you could have two of these images and allow for them to be upgraded, etc. etc. To start with though, I think there's a lot of value in pre-committing a couple hundred MB of disk space to having a rescue environment always on. Rescue environment aside, it'd be nice to avoid failing the upgrade because of insufficient space in /boot. I think 200 MB default /boot prove to be too small---perhaps 500 MB should be the new default? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 15:39 -0500, Eric Sandeen wrote: Jon Masters wrote: On Wed, 2010-06-02 at 21:22 +0100, Richard W.M. Jones wrote: On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: Is it better to have a separate volume for this, or to just have a sort of rescue initramfs ...? Or if you are able to run a little bit of C code[1] and can read files from the root partition (as grub can), you can build one on the fly using binaries, libraries etc found on the root disk, which is what we do in libguestfs. I specifically think this is not the solution :) It's great for libguestfs, but the idea here is to have known-good binaries that can be used to recover a system - and that change very rarely indeed (on the same order as the physical media containing the installer) - when it is broken during an update or otherwise. If the system is already busticated, then building images from it will not help. Totally depends on how it got busted. Yea, but why rebuild it unless you need to? I'm talking about being able to boot into a rescue environment. I don't really care which version of KDE/GNOME is available, only that some major change to Fedora is picked up in time. For example if this was around the time LUKS support was added, it would be useful to have that, but then such a major item would line up with a new Fedora release anyway and have Anaconda dependencies. I know Fedora is all about fast pace, but this is one time where it's a good idea not to move quickly :) And frankly, even Windows has a Safe Mode that often works to boot into a recovery environment. A recovery initramfs could be used. It could just basically be the rescue mode anaconda bits in one image shoved in place to start. This makes sense to me as a pretty simple solution to get going with. Ok. When I get a minute, I'll write this up and suggest that as a starting point to get something vaguely useful. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 15:39 -0500, Eric Sandeen wrote: The ability to create/update a rescue image would be very useful IMHO. If it was a ramfs that was writable, and you had say yum/rpm in there, you could update the running code and make use of a newer e2fsck... -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: suggestion: rescue boot extension
On Wed, 2010-06-02 at 16:47 -0400, Przemek Klosowski wrote: On 06/02/2010 04:02 PM, Jon Masters wrote: That said, of course eventually you could have two of these images and allow for them to be upgraded, etc. etc. To start with though, I think there's a lot of value in pre-committing a couple hundred MB of disk space to having a rescue environment always on. Rescue environment aside, it'd be nice to avoid failing the upgrade because of insufficient space in /boot. I think 200 MB default /boot prove to be too small---perhaps 500 MB should be the new default? It does seem to be the default in RHEL now, and makes sense. Still, that's a separate topic for another thread I think (/boot). Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 02, 2010 at 01:43:10PM -0500, Michael Cronenworth wrote: Lennart Poettering wrote: We wanted to make the transition from sysv to systemd very easy, and I think this is the simplemost scheme we could come up with. During a transition period packages should just ship both files and it'll work with both init systems. s/systemd/upstart/ This is not the first time this has been said. Even though there may not be an initiative to switch from sysv to upstart, why do you feel so strongly that people will switch from sysv to systemd? Are you going to implement a Fedora policy that bans sysv, say, in Fedora 16? That's about the only way you could make it happen. Well one of the reasons that we are still using sysvinit compatibility for upstart is that people have been actively told not to switch to native upstart scripts. So our current situation is not really an indicator of what to expect with a new init system where we actively tell people to switch. -Toshio pgpHxgmAx0npU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Eric Sandeen wrote: Is it better to have a separate volume for this, or to just have a sort of rescue initramfs ...? Seems like the latter is more flexible but then I'm no boot process wizard. Good suggestion. Another one: What about LVM snapshots? and/or btrfs snapshots? Either way would be less wasteful than a whole partition that would be obsolete in a few weeks and may or may not have to deal with byte growing pains if the initial size is too small years down the road. Another scenario: Your Fedora 14 rescue boot partition was built against kernel 2.6.34, but the root file system of your Fedora 18 installation is of a new experimental file system only found in kernel 2.6.38. The rescue partition is wasted space at this point. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Thu, Jun 03, 2010 at 02:30:23AM +0800, Chen Lei wrote: 2010/6/3 Matt McCutchen m...@mattmccutchen.net: On Wed, 2010-06-02 at 20:00 +0200, Kevin Kofler wrote: Chen Lei wrote: Is it right for the maintainer to provide two separate subpackages, one with the tranditional rc.d contents and one with an upstart scripts and make the -upstart subpackage have a higher priority over sysinit subpackage? No. This is against our packaging guidelines. Where do you see that? -- Matt I'm not sure about whether ship upstart scripts violate our guidelines, but fedora package guideline has - Currently, only SystemV-style initscripts are supported in Fedora. hshiottp://fedoraproject.org/wiki/PackagingGuidelines#Initscripts This is intended to tell people that SystemVinit scripts are mandatory for services managed by the init system. But providing native upstart as an addition (or initng, minit, etc) is not prohibited by this. -Toshio pgpOKc163P3Oa.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: deluge and flags sub package
On Wed, 2010-06-02 at 00:56 +0530, Rahul Sundaram wrote: I will work with Ankur Sinha and probably do this for Rawhide in the next couple of days. Peter Gordon, let me know if you have any objections This sounds good to me - please go ahead with your changes. (Apologies about the unavailability over the past several weeks. Final projects and trips with family/friends have consumed most of my time. I'm back and ready to rock some Fedora packages, though! ^_~) -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me 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: FC13 nss-softokn-freebl update issues
On 06/02/2010 12:51 PM, Bill Nottingham wrote:
Robert Relyea (rrel...@redhat.com) said:
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)?
Because upstream selected it's names before linux naming was anything
like widespread.
nss/nspr upstream was also unusual in considering binary compatibility
breakage a sev 1 bug. It's expected that old apps run against new versions.
One good side effect of this is there is no name colision in the
libraries between Network Security Services and Name Switch Select, nor
NSS's libssl3.so and openssl's libssl.so.
OK. Copying from the bug:
There are two 'simple' fixes for this that don't involve hotfixing the push
infrastructure:
1) For all nss/nspr packages that don't have .so symlinks in their devel
packages, add %{?_isa} to the requires in the devel packages.
See https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires for
a packaging draft for this.
For example, that would change, in nss-softokn-freebl-devel:
Requires: nss-softokn-freebl = %{version}-%{release}
to:
Requires: nss-softokn-freebl%{?_isa} = %{version}-%{release}
in nss-softokn-freebl-devel,
Requires: nss-softokn = %{version}-%{release}
to
Requires: nss-softokn%{?_isa} = %{version}-%{release}
in nss-softokn-devel, and so on.
The reason this is needed is that for most -devel pacakges, there is automatic
dependencies added on the proper library package due to following the '.so'
devel symlink to the main library. This doesn't work for nss/nspr, as the
-devel packages don't have these symlinks.
2) Wait for either of https://admin.fedoraproject.org/updates/glibc-2.12-2 or
https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed to
stable, as those will pull in the i686 nss-softokn-freebl through library
dependencies.
Thank you Bill.
Elio
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 16:04 -0500, Michael Cronenworth wrote: Eric Sandeen wrote: Is it better to have a separate volume for this, or to just have a sort of rescue initramfs ...? Seems like the latter is more flexible but then I'm no boot process wizard. Good suggestion. Another one: What about LVM snapshots? and/or btrfs snapshots? This is already done. But it's very coarse. You get to unwind (possibly) a lot of stuff, and may not reboot the moment you finish the update. You also need to have /home on a separate volume, etc. etc. It's great, but it's not always what you need. So my suggestion is tangential to that. Either way would be less wasteful than a whole partition that would be obsolete in a few weeks and may or may not have to deal with byte growing pains if the initial size is too small years down the road. An initramfs is fine. I wasn't literally saying the only option was to keep a spare physical partition around. I was thinking that, if it were a volume, it would be an LVM volume that could be resized later. But I think the easiest option for now is simply a rescue initramfs on the /boot volume, and I suppose I see the point now about making a bigger /boot volume if this happens. That does make sense. This would be something you could choose not to have installed anyway IMO. Another scenario: Your Fedora 14 rescue boot partition was built against kernel 2.6.34, but the root file system of your Fedora 18 installation is of a new experimental file system only found in kernel 2.6.38. The rescue partition is wasted space at this point. When are we going to have a situation in which Fedora ships F14 with a new filesystem that works with Anaconda (and therefore a rescue image) to get installed, but doesn't work after the fact? Maybe you copied and created this by hand, but in that case you get to keep both pieces when it breaks. I'm talking about out-of-the box regular user issues :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Curiosity, Are Cursor Themes that Critical?
On Wed, 2010-06-02 at 11:50 -0600, Geoff Reedy wrote: On Wed, Jun 02, 2010 at 02:42:08AM +0530, Rahul Sundaram said The former is the default theme and has been added as a dependency to a core package. You are seeing a cascading set of dependencies as a result. Should that be done through comps? It's not a really required for functionality of those packages since there's always the possiblity to fall back to the old builtin bitmap cursors right? Right, I was about to say the same things. If there's not actually a hard dependency here - if no cursor theme package needs to be installed for the desktop to run - there should be no dependency, and the dmz theme should simply be listed in comps. If the dependency is just that *some* cursor theme needs to be installed, all cursor themes should provide something like 'cursor-theme' and the dependency should be on this virtual provide, not on any specific theme. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 598989] [abrt] crash in perl-Padre-0.50-4.fc13: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
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=598989 --- Comment #3 from Petr Pisar ppi...@redhat.com 2010-06-02 17:30:50 EDT --- It segfaulted here: 0x003deb46b954 +36: callq 0x3deb41c658 g_type_check_instance_c...@plt = 0x003deb46b959 +41: mov0x440(%rax),%rsi That means the gtk2 library tried to dereference return code of g_type_check_instance_c...@plt function at offset 0x440. And because rax was zero, the effective read address was 0x440. According memory mapping list, zeroth page was unmapped. Thus it's simple NULL pointer dereference in libgtk2++. I will check _gdk_x11_screen_process_owner_change() code in gdkscreen-x11.c later. -- 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: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote: On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: On 06/01/2010 10:43 PM, 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], Unless rpmlint starts to use a massively cleaned up set of rules, its results are mostly noise. Which packages do you maintain where the output has become unmanageable? One thing I'd dearly like to see suppressed in most cases is the spell checking. Most package descriptions need to use jargon which spell checkers just don't recognize. I just ran some random rpmlints to check how it's behaving these days, and here's my collection of 'spelling error' warnings: libdrm sK gpsd pre aside from this most of the output I get is pretty sane, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, 2010-06-02 at 09:13 -0500, Bruno Wolff III wrote: This issue points out a gap in our QA testing. Indeed, although there are _many_ gaps in our QA testing, and this is not news. =) We don't have the resources to test anywhere close to everything. The extent of claimed CPU arch support is just one of the things we're not equipped to test... (It does kind of surprise me that _no-one_ at OLPC managed to notice this before release, though. We do betas!) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 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). To handle different command line syntaxes I would apply some simple macro substitution to the command line in the .service file, replacing for example the string %listen_FDs% (or some other syntax) with the number of sockets. One daemon could then have the parameter --listen-fds=%listen_FDs%, another could have -sockets=%listen_FDs% and a third could have -q %listen_FDs%. 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[]. I'd be surprised if any of those programs are designed such that they have no way of passing parameters to their modules. 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. I'm afraid I don't understand what you mean with handle this. I thought at first that you meant that LISTEN_FDS should only be used for daemons that are known to clear it, but if that were the case you wouldn't have invented LISTEN_PID. Do you perchance mean that LISTEN_FDS should only be used in cases where all child processes will be killed if the daemon dies? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
