Re: [systemd-devel] question
On Wed, Sep 14, 2011 at 6:44 AM, Tom Lane t...@redhat.com wrote: Rahul Sundaram methe...@gmail.com writes: On 09/14/2011 09:55 AM, Genes MailLists wrote: Honestly, if systemd updates has 5% of users failing on an update to the software - we should dump the thing immediately and go back to upstart. That is insanely high bug rate for core code which is (or should be) pretty simple. Get real. Nobody is dumping anything Really? To my mind, systemd is still on trial ... and it's failing. I think there's a significant probability we'll go to something else in a release or three. Not seeing anything failing here ... it works fine for me and many others. As for go to something else as long as this something is not = 30 years old (or a renamed version of something that is 30+ years old). It will fail in the same way (for people that can't stand changes). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Štěpán Kasal
Hello, I'm particularly interested in package halevt, I have released the ownership of this one in pkgdb, in case that helps you in short-time perspective. Note I have not done anything but the clicks in pkgdb (sending mail to fedora-devel?). Have a nice day, Stepan Kasal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
2011/9/14 Tom Lane t...@redhat.com: =?ISO-8859-2?Q?Micha=B3_Piotrowski?= mkkp...@gmail.com writes: 2011/9/14 Tom Lane t...@redhat.com: Certainly postgresql.init was never exactly lean-and-mean, so it seems like it ought to have been doing more work than the unit file requires. Are you sure you were comparing apples to apples as far as the state of the database, kernel disk cache, etc goes? I copied the service to /etc/systemd/system and changed PGDATA variable, then I enabled the service and rebooted. After boot I checked system boot time with systemd-analyze - I saw that it starts slow, so I disabled it and deleted from /etc/systemd/system. After another reboot again checked boot time with systemd-analyze. I'll check tomorrow how repeatable is native service boot time. I'd suggest first timing some rounds of manual service postgresql start, service postgresql stop to see what things look like without all the other noise involved in a system boot. Ok, I made four series of tests: - start/stop an old init script - start/stop an old init script with dropping caches - should simulate system booting - start/stop service file - start/stop service file with dropping caches In each series of tests were repeated five times. series 1 - start - 2.2+ sec series 1 - stop - 1.2+ sec series 2 - start - 2.4+ sec series 2 - stop - 1.3+ sec series 3 - start - 3.1+ sec series 3 - stop - 1.1+ sec series 4 - start - 4.2+ sec series 4 - stop - 1.1+ sec Results are reproducible. === old init script === time sudo systemctl start postgresql.service real0m2.248s user0m0.012s sys 0m0.022s time sudo systemctl stop postgresql.service real0m1.288s user0m0.007s sys 0m0.027s time sudo systemctl start postgresql.service real0m2.252s user0m0.014s sys 0m0.020s time sudo systemctl stop postgresql.service real0m1.282s user0m0.012s sys 0m0.021s time sudo systemctl start postgresql.service real0m2.230s user0m0.006s sys 0m0.028s time sudo systemctl stop postgresql.service real0m1.273s user0m0.012s sys 0m0.021s time sudo systemctl start postgresql.service real0m2.232s user0m0.007s sys 0m0.028s time sudo systemctl stop postgresql.service real0m1.266s user0m0.010s sys 0m0.023s time sudo systemctl start postgresql.service real0m2.246s user0m0.011s sys 0m0.023s time sudo systemctl stop postgresql.service real0m1.277s user0m0.007s sys 0m0.026s === old init script + echo 1 drop_caches === time sudo systemctl start postgresql.service real0m2.586s user0m0.013s sys 0m0.034s time sudo systemctl stop postgresql.service real0m1.393s user0m0.009s sys 0m0.034s time sudo systemctl start postgresql.service real0m2.492s user0m0.014s sys 0m0.032s time sudo systemctl stop postgresql.service real0m1.391s user0m0.009s sys 0m0.036s time sudo systemctl start postgresql.service real0m2.598s user0m0.009s sys 0m0.037s time sudo systemctl stop postgresql.service real0m1.385s user0m0.011s sys 0m0.031s time sudo systemctl start postgresql.service real0m2.563s user0m0.015s sys 0m0.031s time sudo systemctl stop postgresql.service real0m1.384s user0m0.015s sys 0m0.029s time sudo systemctl start postgresql.service real0m2.581s user0m0.016s sys 0m0.030s time sudo systemctl stop postgresql.service real0m1.391s user0m0.010s sys 0m0.035s === systemd service === time sudo systemctl start postgresql.service real0m3.167s user0m0.008s sys 0m0.025s time sudo systemctl stop postgresql.service real0m1.124s user0m0.014s sys 0m0.020s time sudo systemctl start postgresql.service real0m3.180s user0m0.009s sys 0m0.024s time sudo systemctl stop postgresql.service real0m1.121s user0m0.008s sys 0m0.025s time sudo systemctl start postgresql.service real0m3.164s user0m0.012s sys 0m0.022s time sudo systemctl stop postgresql.service real0m1.112s user0m0.006s sys 0m0.027s time sudo systemctl start postgresql.service real0m3.161s user0m0.014s sys 0m0.019s time sudo systemctl stop postgresql.service real0m1.130s user0m0.010s sys 0m0.024s time sudo systemctl start postgresql.service real0m3.174s user0m0.011s sys 0m0.022s time sudo systemctl stop postgresql.service real0m1.123s user0m0.008s sys 0m0.026s === systemd service + echo 1 drop_caches === time sudo systemctl start postgresql.service real0m4.320s user0m0.014s sys 0m0.030s time sudo systemctl stop postgresql.service real0m1.196s user0m0.012s sys 0m0.033s time sudo systemctl start postgresql.service real0m4.289s user0m0.008s sys 0m0.037s time sudo systemctl stop postgresql.service real0m1.204s user0m0.011s sys 0m0.033s time sudo systemctl start postgresql.service real0m4.284s
Re: what if native systemd service is slower than old sysvinit script?
2011/9/14 Adam Williamson awill...@redhat.com: On Tue, 2011-09-13 at 20:37 -0400, Tom Lane wrote: =?ISO-8859-2?Q?Micha=B3_Piotrowski?= mkkp...@gmail.com writes: 2011/9/14 Tom Lane t...@redhat.com: Certainly postgresql.init was never exactly lean-and-mean, so it seems like it ought to have been doing more work than the unit file requires. Are you sure you were comparing apples to apples as far as the state of the database, kernel disk cache, etc goes? I copied the service to /etc/systemd/system and changed PGDATA variable, then I enabled the service and rebooted. After boot I checked system boot time with systemd-analyze - I saw that it starts slow, so I disabled it and deleted from /etc/systemd/system. After another reboot again checked boot time with systemd-analyze. I'll check tomorrow how repeatable is native service boot time. I'd suggest first timing some rounds of manual service postgresql start, service postgresql stop to see what things look like without all the other noise involved in a system boot. yeah; it may well be starting at a different point in the process now it's being ordered as a systemd-native service rather than via lsb deps. did the *overall* startup time increase by a corresponding amount? I sent the results of tests for simple daemon start/stop. I see no point in testing boot speed in this case, but of course I can do some tests later if you think that the results may be useful. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/13/2011 11:03 PM, Michał Piotrowski wrote: Hi 2011/9/13 Tom Lanet...@redhat.com: (This isn't new with 9.1, btw --- the last version or so of 9.0 for F16 was the same, since we switched over to native systemd files.) I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service First of all you cant reliably measure startup performance between legacy sysv init script and a native systemd unit since either one of those might be doing less/more. So I wonder if it makes sense to convert in such case? Yes systemd is bringing more to the table then just startup speed which by the way is completely irrelevant in server environment. I personally look at the boot decrease as an side effect not an feature. We are still a long way from actually deliver that degreased boot time out of the box into the hands of the desktop end users or perhaps I should rather say there is room for plenty of improvements in that regard. Once we have done that it willl highlight other issues such as the log into the desktop time which currently is taking longer time for me ( Gnome it might be faster on other *DE ) than it takes to booting the operating system. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Virtualization Test Day for F16 and Xen
On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote: Hi, Hello, Virtualization Test day is expected to be on September 15th this year ([1]https://fedorahosted.org/fedora-qa/ticket/232). So that's tomorrow! Luckily Xen Hackathon (@Munich) event is just happening, so hopefully we can get some more testing from people in that event. We are willing to help test [2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too little information about test methods ([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us to setup test environment, and would be good to have some info in advance. Regards, I just added some Xen related mailinglists to the CC list, so we can get more feedback. Thanks, -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-HTML-FormatText-WithLinks-AndTables
perl-HTML-FormatText-WithLinks-AndTables has broken dependencies in the F-16 tree: On x86_64: perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the F-16 tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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: what if native systemd service is slower than old sysvinit script?
On 09/14/2011 10:56 AM, Steve Clark wrote: Thats right! Just wave your hands and say it is all ok that systemd is slower now but it is doing so much more and we will make it better in the future...! I never said that what I said was it's irrelivent the startup time of a service on a service platform which you should actually know yourself if are used to run servers in a proper production deployment not in your garage at back home. This was a simple test to start postgresql - what else needs to be done! An simple test to measure this reliably is to strip down the legacy sysv init script to the start up command only and have a strip down unit file to the startup command only. Then time the startup of either. I would be surprised if there was any measurable difference by all means since this seems so important to you test it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/14/2011 01:42 AM, Adam Williamson wrote: Honestly, if systemd updates has 5% of users failing on an update to the software - we should dump the thing immediately and go back to upstart. That is insanely high bug rate for core code which is (or should be) pretty simple. Rahul was presenting a theoretical example, not an *expectation* that a systemd update would break things for 5% of users. I realize, but that was indeed part of the point of my reply - lets avoid making up things (with or without hyperbole) - and best we can, stick to facts and real issues. More helpful would be people who have tested the newer systemd on F15 to give us a better sample of what, if anything, got worse and/or better as a consequence. Also, I'd be curious if LP felt the risk was high or negligible - since his thoughts should carry more weight on this topic. I assume he would not think 5% of users would have un-bootable systems. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/14/2011 04:35 AM, Jóhann B. Guðmundsson wrote: On 09/13/2011 11:03 PM, Micha? Piotrowski wrote: Hi 2011/9/13 Tom Lanet...@redhat.com: (This isn't new with 9.1, btw --- the last version or so of 9.0 for F16 was the same, since we switched over to native systemd files.) I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service First of all you cant reliably measure startup performance between legacy sysv init script and a native systemd unit since either one of those might be doing less/more. So I wonder if it makes sense to convert in such case? Yes systemd is bringing more to the table then just startup speed which by the way is completely irrelevant in server environment. I personally look at the boot decrease as an side effect not an feature. We are still a long way from actually deliver that degreased boot time out of the box into the hands of the desktop end users or perhaps I should rather say there is room for plenty of improvements in that regard. Once we have done that it willl highlight other issues such as the log into the desktop time which currently is taking longer time for me ( Gnome it might be faster on other *DE ) than it takes to booting the operating system. JBG Thats right! Just wave your hands and say it is all ok that systemd is slower now but it is doing so much more and we will make it better in the future...! This was a simple test to start postgresql - what else needs to be done! -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/14/2011 05:13 PM, Genes MailLists wrote I realize, but that was indeed part of the point of my reply - lets avoid making up things (with or without hyperbole) - and best we can, stick to facts and real issues. You are ignoring the real issue. Since you don't seem to understand my point yet but let me rephrase it. Any update has a risk. A major new version of a init system is a substantial risk in an update. You shouldn't push it as an update unless there is a substantial justification for taking that risk. Since even a minor problem in a init system can result in a system that you can't easily recover from, the question always is not why not but why. The goal of the update policy is to ask that question. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, 14 Sep 2011 08:35:47 + Jóhann B. Guðmundsson johan...@gmail.com wrote: 2011/9/13 Tom Lanet...@redhat.com: ... I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service First of all you cant reliably measure startup performance between legacy sysv init script and a native systemd unit since either one of those might be doing less/more. As far as I understand it, systemd follows a dependendy dag, starting every node (service) as soon as possible. There is no guarantee that this will _always_ finish everything sooner than some other, arbitrary ordering. In this kind of environment, usually it will go faster, but not always. -- Bernd Stramm bernd.str...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/14/2011 11:50 AM, Rahul Sundaram wrote: On 09/14/2011 05:13 PM, Genes MailLists wrote I realize, but that was indeed part of the point of my reply - lets avoid making up things (with or without hyperbole) - and best we can, stick to facts and real issues. You are ignoring the real issue. Since you don't seem to understand my point yet but let me rephrase it. Any update has a risk. A major new version of a init system is a substantial risk in an update. You shouldn't push it as an update unless there is a substantial justification for taking that risk. Since even a minor problem in a init system can result in a system that you can't easily recover from, the question always is not why not but why. The goal of the update policy is to ask that question. Users that require newer bits that we ship in GA can just rebuild the relevant components from srpm in koji and ofcourse they get to keep the broken bits by doing so. And FYI to all those that gloriously want to upgrade and claim that it's bug free or they ( all of what two people ) not encountered any issues inetd-style socket activation is borked in .35 ( users need to downgrade to .34 or add StandardOutput=socket if they cant wait until 36 goes out ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, Sep 14, 2011 at 01:03:04AM +0200, Michał Piotrowski wrote: Hi 2011/9/13 Tom Lane t...@redhat.com: (This isn't new with 9.1, btw --- the last version or so of 9.0 for F16 was the same, since we switched over to native systemd files.) I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service So I wonder if it makes sense to convert in such case? (I know that it is not about boot speed, it can start slower if needed.) Is systemd boot actually any faster? There seems to be no noticable difference in boot times for me over whatever we were using in F14. ie. both methods still takes ages, far longer than should be necessary. Rich. -- 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://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, Sep 14, 2011 at 4:22 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Sep 14, 2011 at 01:03:04AM +0200, Michał Piotrowski wrote: Hi 2011/9/13 Tom Lane t...@redhat.com: (This isn't new with 9.1, btw --- the last version or so of 9.0 for F16 was the same, since we switched over to native systemd files.) I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service So I wonder if it makes sense to convert in such case? (I know that it is not about boot speed, it can start slower if needed.) Is systemd boot actually any faster? There seems to be no noticable difference in boot times for me over whatever we were using in F14. ie. both methods still takes ages, far longer than should be necessary. My laptop (using a Samsung ssd) booted up in 14-16 seconds on F14. Now (F15) it boots up in 7-8 seconds. Which is a rather huge boost. (Not using lvm or any fancy stuff). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
2011/9/14 Jóhann B. Guðmundsson johan...@gmail.com: On 09/14/2011 10:56 AM, Steve Clark wrote: This was a simple test to start postgresql - what else needs to be done! An simple test to measure this reliably is to strip down the legacy sysv init script to the start up command only and have a strip down unit file to the startup command only. Then time the startup of either. Why? The current numbers show that the service file is _slower_ even when the old init script is supposedly doing much more work in shell. If anything, stripping the unessential parts should make the service file _even slower_ in relative terms. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen
On Wed, Sep 14, 2011 at 10:25:23AM -0400, Konrad Rzeszutek Wilk wrote: On Wed, Sep 14, 2011 at 02:25:52PM +0300, Pasi Kärkkäinen wrote: On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote: Hi, Hello, Virtualization Test day is expected to be on September 15th this year ([1]https://fedorahosted.org/fedora-qa/ticket/232). Cool. So that's tomorrow! Luckily Xen Hackathon (@Munich) event is just happening, so hopefully we can get some more testing from people in that event. We are willing to help test [2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too little information about test methods It really ought to be parallel to what you would do with KVM/QEMU. Basically the same steps - but I am not sure how well does libvirt work with xm/xl nowadays. Or the virt-manager - but it suppose to interact with magically. libvirt support for xm/xend *should* work, and there's also the libvirt libxl driver written by Jim Fehlig from Novell/SUSE. Is there a KVM/QEMU/libvirt help test Wiki? I saw this: https://fedoraproject.org/wiki/Getting_started_with_virtualization and it kind of parallels it, albeit I didn't see anything about setting the network which sometimes is the biggest pain point: http://www.fedoraforum.org/forum/showthread.php?t=268427 When you install libvirt it'll automatically create/start a bridge called virbr0, which is an host-internal bridge with dnsmasq running and configured to provide dhcp server with private ip range, dns relay and NAT on that bridge. So that's good enough for trying some VMs or running VM netboot installs. ([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us to setup test environment, and would be good to have some info in advance. There are known bugs in FC15/FC16 that have been filled some time ago that folks will sadly run into: 728775, 658387 and 668063 Fortunatly the bugs have patches attached and the files to be modified are shell scripts. Yep, links here: https://bugzilla.redhat.com/show_bug.cgi?id=728775 https://bugzilla.redhat.com/show_bug.cgi?id=658387 https://bugzilla.redhat.com/show_bug.cgi?id=668063 -- Pasi Regards, I just added some Xen related mailinglists to the CC list, so we can get more feedback. Thanks, -- Pasi ___ Xen-devel mailing list xen-de...@lists.xensource.com http://lists.xensource.com/xen-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/14/2011 02:22 PM, Richard W.M. Jones wrote: Is systemd boot actually any faster? There seems to be no noticable difference in boot times for me over whatever we were using in F14. ie. both methods still takes ages, far longer than should be necessary. We arent optimising the default desktop install live or otherwise for an actual desktop install. It's currently aimed at Generic or Corporate installs. This is my HP Pavilion DM1 laptop bootup time with rooms for improvement after minor tweaking on rotating media with no loss of functionality what so ever. # systemd-analyze Startup finished in 5761ms (kernel) + 11938ms (userspace) = 17700ms I'm assuming the kernel time improves once we turn off debugging in it. Afaik none of the *DE groups are properly tweaking things for their target audience. Anything above 4 seconds on ssd's would I consider unacceptable ( I think Lennart and Kay are booting around s14s second on those ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
=?ISO-8859-2?Q?Miloslav_Trma=E8?= m...@volny.cz writes: 2011/9/14 Jóhann B. Guðmundsson johan...@gmail.com: An simple test to measure this reliably is to strip down the legacy sysv init script to the start up command only and have a strip down unit file to the startup command only. Then time the startup of either. Why? The current numbers show that the service file is _slower_ even when the old init script is supposedly doing much more work in shell. If anything, stripping the unessential parts should make the service file _even slower_ in relative terms. Yes. The unit file is already stripped down: it does nothing except pg_ctl start. The init script had accumulated a whole lot of perhaps-unnecessary sanity-checking, which frankly I'd rather have kept but the systemd mantra seems to be no shell scripting so I didn't. Michal's numbers look pretty damning, and I find it remarkable that the systemd advocates seem to have managed not to read them, let alone admit that they suggest something's seriously wrong. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, Sep 14, 2011 at 7:28 AM, Tom Lane t...@redhat.com wrote: Michal's numbers look pretty damning, and I find it remarkable that the systemd advocates seem to have managed not to read them, let alone admit that they suggest something's seriously wrong. Michal's numbers look intriguing. I look forward to watching the discussion that unfolds in the upstream mailinglist and see if someone can trackdown an optimization based on those numbers. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/14/2011 04:31 PM, drago01 wrote: On Wed, Sep 14, 2011 at 4:22 PM, Richard W.M. Jonesrjo...@redhat.com wrote: On Wed, Sep 14, 2011 at 01:03:04AM +0200, Michał Piotrowski wrote: Hi 2011/9/13 Tom Lanet...@redhat.com: (This isn't new with 9.1, btw --- the last version or so of 9.0 for F16 was the same, since we switched over to native systemd files.) I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service So I wonder if it makes sense to convert in such case? (I know that it is not about boot speed, it can start slower if needed.) Is systemd boot actually any faster? Not from my personal experience. There seems to be no noticable difference in boot times for me over whatever we were using in F14. ie. both methods still takes ages, far longer than should be necessary. My laptop (using a Samsung ssd) booted up in 14-16 seconds on F14. Now (F15) it boots up in 7-8 seconds. Which is a rather huge boost. (Not using lvm or any fancy stuff). My netbook boots up F14 in ca. 60 secs, while F15 boots up in 62 secs. I'd call this below measurement accuracy. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
Am 13.09.2011 23:58, schrieb Rahul Sundaram: On 09/14/2011 02:59 AM, Sérgio Basto wrote: So Fedora guys what you are waiting for ? update systemd please , should I open a report in bugzilla ? I can explain each of your examples but since systemd upstream developer is also the Fedora maintainer, I think he is in a better position to judge when to update. Fedora follows http://fedoraproject.org/wiki/Updates_Policy better position to judge is relative yes, updates may introduce new bugs / problems but nobody cared about all this before release systemd and some releases before pulseaudio for the GA release and what here happens is we release and hope it will work good enough, fninish what we released will happen somewhere in time in some release later it would be better these careful not introduce problems would happen before release and not two releases later signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
Am 14.09.2011 06:52, schrieb Rahul Sundaram: It is a small number of people repeating bringing up high risk and frankly silly ideas like updating to a major new version of a core component in a update without sufficient justification for taking that risk if fedora has a problem with updates for components like systemd this components should be thrown out with much more care than it happended with systemd - if you throw me unfinished beta-components on my system you are responsilbe to bring also umprovements to me or hold back your stuff until it is ready would fedora have been waiting for F17/F18 until systemd is really ready we would not have this problem - but after forcing everybody with new intel-hardware (sandy bridge) update to F15 because even the network does not work with the outdated F14 kernel and force a switch to systemd at the same time and then force the users to upgrade again to F16 as soon as possible to get systemd updated is simply the wrng way and if such decisions will happen too often so terrible wrong fedora will lose reputation over the time signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
Am 14.09.2011 14:16, schrieb Jóhann B. Guðmundsson: And FYI to all those that gloriously want to upgrade and claim that it's bug free or they ( all of what two people ) not encountered any issues inetd-style socket activation is borked in .35 ( users need to downgrade to .34 or add StandardOutput=socket if they cant wait until 36 goes out) it is a hughe difference upgrade to some rawhide stuff or leave F15 until now 10 releases behind and the next 8 months with all the missing features and problems as it was released! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/14/2011 03:37 AM, Reindl Harald wrote: better position to judge is relative Not really. Noone is in a better position to judge the impact of updates more than the upstream developers who also maintain the component in Fedora. yes, updates may introduce new bugs / problems but nobody cared about all this before release systemd and some releases before I think everyone has heard your opinion on this. There isn't a purpose to repeating this so many times. It has nothing to do with updates at all Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
2011/9/14 Jóhann B. Guðmundsson johan...@gmail.com: On 09/14/2011 02:22 PM, Richard W.M. Jones wrote: Is systemd boot actually any faster? There seems to be no noticable difference in boot times for me over whatever we were using in F14. ie. both methods still takes ages, far longer than should be necessary. We arent optimising the default desktop install live or otherwise for an actual desktop install. It's currently aimed at Generic or Corporate installs. This is my HP Pavilion DM1 laptop bootup time with rooms for improvement after minor tweaking on rotating media with no loss of functionality what so ever. # systemd-analyze Startup finished in 5761ms (kernel) + 11938ms (userspace) = 17700ms I'm assuming the kernel time improves once we turn off debugging in it. Afaik none of the *DE groups are properly tweaking things for their target audience. Anything above 4 seconds on ssd's would I consider unacceptable ( I think Lennart and Kay are booting around s14s second on those ) I use ssd. Startup finished in 1819ms (kernel) + 2495ms (initrd) + 8013ms (userspace) = 12328ms The slowest part is 3633ms mysqld.service 2288ms postgresql.service old versions that are better than native services. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
Michał Piotrowski wrote: Ok, I made four series of tests: - start/stop an old init script - start/stop an old init script with dropping caches - should simulate system booting - start/stop service file - start/stop service file with dropping caches Just to be clear. This is done on an F15 system using the postgresql systemd based service file from the F16 branch? I'd like to do some followup testing on my systems and I want to make sure I'm doing as faithful comparison of the init configs you tested. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/14/2011 11:28 AM, Tom Lane wrote: =?ISO-8859-2?Q?Miloslav_Trma=E8?=m...@volny.cz writes: 2011/9/14 Jóhann B. Guðmundssonjohan...@gmail.com: An simple test to measure this reliably is to strip down the legacy sysv init script to the start up command only and have a strip down unit file to the startup command only. Then time the startup of either. Why? The current numbers show that the service file is _slower_ even when the old init script is supposedly doing much more work in shell. If anything, stripping the unessential parts should make the service file _even slower_ in relative terms. Yes. The unit file is already stripped down: it does nothing except pg_ctl start. The init script had accumulated a whole lot of perhaps-unnecessary sanity-checking, which frankly I'd rather have kept but the systemd mantra seems to be no shell scripting so I didn't. Michal's numbers look pretty damning, and I find it remarkable that the systemd advocates seem to have managed not to read them, let alone admit Don't confuse we with facts! I've already made up my mind! ;-) that they suggest something's seriously wrong. regards, tom lane -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Štěpán Kasal
On Wed, 14 Sep 2011 08:58:11 +0200 Stepan Kasal ka...@ucw.cz wrote: Hello all, Therefore I'd like to ask FESCo to mass-orphan all packages owned by him. Should I open a ticket? yes, it is true that I'm not able to find any time to do my duties as a package maintainer. I agree that mass orphaning of the packages is a reasonable solution. I would be grateful if you could help me with that. Could one of you file a ticket for this? I guess in infrastructure trac and we will get it taken care of. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, Sep 14, 2011 at 5:34 PM, Ralf Corsepius rc040...@freenet.de wrote: On 09/14/2011 04:31 PM, drago01 wrote: On Wed, Sep 14, 2011 at 4:22 PM, Richard W.M. Jonesrjo...@redhat.com wrote: On Wed, Sep 14, 2011 at 01:03:04AM +0200, Michał Piotrowski wrote: Hi 2011/9/13 Tom Lanet...@redhat.com: (This isn't new with 9.1, btw --- the last version or so of 9.0 for F16 was the same, since we switched over to native systemd files.) I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service So I wonder if it makes sense to convert in such case? (I know that it is not about boot speed, it can start slower if needed.) Is systemd boot actually any faster? Not from my personal experience. There seems to be no noticable difference in boot times for me over whatever we were using in F14. ie. both methods still takes ages, far longer than should be necessary. My laptop (using a Samsung ssd) booted up in 14-16 seconds on F14. Now (F15) it boots up in 7-8 seconds. Which is a rather huge boost. (Not using lvm or any fancy stuff). My netbook boots up F14 in ca. 60 secs, while F15 boots up in 62 secs. I'd call this below measurement accuracy. What kind of disk is that? For a mechanical drive any gain from parallel startup would get killed by disk seeks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
2011/9/14 Jef Spaleta jspal...@gmail.com: Michał Piotrowski wrote: Ok, I made four series of tests: - start/stop an old init script - start/stop an old init script with dropping caches - should simulate system booting - start/stop service file - start/stop service file with dropping caches Just to be clear. This is done on an F15 system using the postgresql systemd based service file from the F16 branch? Exactly. F15, PostgreSQL 9.0 and just service file from PostgreSQL 9.1. Root filesystem and database are on SSD and Ext4. I'd like to do some followup testing on my systems and I want to make sure I'm doing as faithful comparison of the init configs you tested. Please post your results I am curious if this is repeatable on other systems. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On Wed, 2011-09-14 at 07:43 -0400, Genes MailLists wrote: Also, I'd be curious if LP felt the risk was high or negligible - since his thoughts should carry more weight on this topic. I assume he would not think 5% of users would have un-bootable systems. No developer ever thinks their change is going to break anything for anyone. It's the QA Law of What Could Possibly Go Wrong. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, 2011-09-14 at 15:22 +0100, Richard W.M. Jones wrote: On Wed, Sep 14, 2011 at 01:03:04AM +0200, Michał Piotrowski wrote: Hi 2011/9/13 Tom Lane t...@redhat.com: (This isn't new with 9.1, btw --- the last version or so of 9.0 for F16 was the same, since we switched over to native systemd files.) I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service So I wonder if it makes sense to convert in such case? (I know that it is not about boot speed, it can start slower if needed.) Is systemd boot actually any faster? There seems to be no noticable difference in boot times for me over whatever we were using in F14. ie. both methods still takes ages, far longer than should be necessary. At present I'd say on average not hugely. AFAIK no-one's really worked on boot speed optimization since right after I came on board at RH: https://fedoraproject.org/wiki/Test_Day:2009-02-19 (man, it's so much harder to find test days from back when we didn't put the subject in the page name...) overall boot speed is a pretty chaotic equation, with a lot more than just the init system involved. I think it's fair to say that, all other things being equal in an ideal world, it may be possible to make things faster with systemd than with upstart, but it's by no means a given, and there are likely other things we can do that will have a more significant impact on boot speeds. We could do another such test event for F17, but to be really effective it needs buy-in from a developer in the position to understand the results and do something about it, like Lennart and Harald. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, 2011-09-14 at 11:28 -0400, Tom Lane wrote: Michal's numbers look pretty damning, and I find it remarkable that the systemd advocates seem to have managed not to read them, let alone admit that they suggest something's seriously wrong. Tests of a single service on a single system in an unknown configuration? Why, that's certainly a great reason to panic! It's an interesting result that's worth looking into, but I don't think calling it 'damning' is helping the tone of the debate. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, 2011-09-14 at 18:23 +0200, drago01 wrote: What kind of disk is that? For a mechanical drive any gain from parallel startup would get killed by disk seeks. There is no real 'gain' from parallel startup when switching from upstart to systemd, especially in the F15 case where almost all the initscripts used are still the same. It seems to often be forgotten that upstart already did parallelization, this is not something new we're getting with systemd. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, 2011-09-14 at 17:47 +0200, Michał Piotrowski wrote: 2011/9/14 Jóhann B. Guðmundsson johan...@gmail.com: On 09/14/2011 02:22 PM, Richard W.M. Jones wrote: Is systemd boot actually any faster? There seems to be no noticable difference in boot times for me over whatever we were using in F14. ie. both methods still takes ages, far longer than should be necessary. We arent optimising the default desktop install live or otherwise for an actual desktop install. It's currently aimed at Generic or Corporate installs. ... Anything above 4 seconds on ssd's would I consider unacceptable ( I think Lennart and Kay are booting around s14s second on those ) I use ssd. Startup finished in 1819ms (kernel) + 2495ms (initrd) + 8013ms (userspace) = 12328ms The slowest part is 3633ms mysqld.service 2288ms postgresql.service old versions that are better than native services. I think Johann's 1-4s scenario assumes a basic desktop configuration and a tweaked startup config aimed at such a system. Such a system would not have two big database engines starting up, but zero. =) The lowest I've seen on my system, which is quick and has a third-gen SSD in it, is 8s, but I haven't made any tweaks to startup config at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
2011/9/14 Michał Piotrowski mkkp...@gmail.com Exactly. F15, PostgreSQL 9.0 and just service file from PostgreSQL 9.1. Root filesystem and database are on SSD and Ext4. Okay... brace yourself. I just ran this test on my non-SSD ext4 based F15 system and I get the opposite result on start...repeatably. On my system the systemd based start up in the admittedly simple service postgresql start testing is consistently faster by about a second. And just as interesting... my sysinit times are slower than yours, that's a real head scratcher for me. If my db test was less overall work to init for some reason I'd expect my numbers to be faster than yourse in both cases. I have no off the top of my head theory that could explain that except that your low level disk i/o is significantly different than mine. Both variants of service postgresql stop is within a 1/10 of a second in my testing I can give you the screen log captures for my tests if you desire to review my actions but here here is the summary for my simple timing test: And admittedly I'm using a simply initiated postgres db. It could be that your real world database initialization workload is more intensive than my test and the disk i/o is now a limiting factor in a different way. And of course my numbers do not discount what your seeing as my test is as anecdotal as your is. Your numbers may still be indicative of a more nuanced problem that can be resolved and its good to have your numbers as a starting point for a discussion around understanding optimization issues (like disk i/o). We just can't jump to conclusions about why you are seeing what your are seeing. I hope my numbers serve as a cautionary reminder to those others on this list that benchmarking disk io intensive tasks can be very complex and very system dependent. Certain other people in this discussion are being overly bombastic and seem to have forgotten this fact. I hope for all our sakes they can find a way to ratchet down the hyperbole and look at these sort of issues with a more clinical approach. Okay so here's my summary of the quick tests. Please if you have an updated methodology for me to test, let me know. I'm willing to reuse a specially crafted pgsql database if you feel that will help you. Though I'd think we wan't to do that sort of deep dive comparison off list until we are ready to publish some summaries after we both feel comfortable with the test runs. -jef == SysVinit: service postgresql status postgresql.service - LSB: start and stop PostgreSQL server Loaded: loaded (/etc/rc.d/init.d/postgresql) Active: inactive (dead) CGroup: name=systemd:/system/postgresql.service time service postgresql start real0m2.329s user0m0.028s sys 0m0.046s time service postgresql stop real0m1.281s user0m0.035s sys 0m0.096s time service postgresql start real0m2.242s user0m0.031s sys 0m0.038s time service postgresql stop real0m1.235s user0m0.031s sys 0m0.036s = Systemd based: status postgresql.service postgresql.service - PostgreSQL database server Loaded: loaded (/lib/systemd/system/postgresql.service) Active: inactive (dead) CGroup: name=systemd:/system/postgresql.service time service postgresql start real0m1.141s user0m0.019s sys 0m0.019s time service postgresql stop real0m1.146s user0m0.017s sys 0m0.017s time service postgresql start real0m1.153s user0m0.016s sys 0m0.019s time service postgresql stop real0m1.144s user0m0.026s sys 0m0.014s -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 737885] perl-DateTime-TimeZone-1.37 is available
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=737885 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-09-14 12:56:36 EDT --- Package perl-DateTime-TimeZone-1.37-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-DateTime-TimeZone-1.37-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.37-1.fc16 then log in and leave karma (feedback). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 738383] New: perl-Mozilla-CA: stop shipping own certificate bundle
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Mozilla-CA: stop shipping own certificate bundle https://bugzilla.redhat.com/show_bug.cgi?id=738383 Summary: perl-Mozilla-CA: stop shipping own certificate bundle Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: high Priority: medium Component: perl-Mozilla-CA AssignedTo: ppi...@redhat.com ReportedBy: tho...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Description of problem: perl-Mozilla-CA comes with certificate bundle generated from nss/mozilla certdata.txt. It's the same source that is used to build ca-bundle.crt form ca-certificates. We should not duplicate those bundles, as that makes it more difficult to deal with updates when some CA needs to be removed (think of recent DigiNotar). Additionally, Mozilla-CA upstream is not currently generating their bundle correctly and are adding certs that are flagged as untrusted in nss/mozilla: https://rt.cpan.org/Public/Bug/Display.html?id=70967 We should really consider making perl-Mozilla-CA require ca-certificates and use that bundle instead. -- 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: what if native systemd service is slower than old sysvinit script?
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= mkkp...@gmail.com writes: Ok, I made four series of tests: - start/stop an old init script - start/stop an old init script with dropping caches - should simulate system booting - start/stop service file - start/stop service file with dropping caches In each series of tests were repeated five times. series 1 - start - 2.2+ sec series 1 - stop - 1.2+ sec series 2 - start - 2.4+ sec series 2 - stop - 1.3+ sec series 3 - start - 3.1+ sec series 3 - stop - 1.1+ sec series 4 - start - 4.2+ sec series 4 - stop - 1.1+ sec Results are reproducible. I tried to replicate these results on my own F15 laptop, and could not --- the service file method doesn't really seem significantly faster than the init script, but it's not slower either. Here's what I did: 1. Install the postgresql-9.1.0 RPMs (rebuilt for F15 of course) and do postgresql-setup initdb. 2. Set log_line_prefix = '%m %p ' and log_connections = on in postgresql.conf, so that log messages will be timestamped. Also set timezone and log_timezone to desired values (I use 'US/Eastern'); if you don't do that, the server startup time is increased significantly while Postgres tries to figure out the system timezone setting. 3. As root, do date --rfc-3339=ns ; systemctl start postgresql.service ; date --rfc-3339=ns 4. Note the time from the first date output to the database system is ready to accept connections message getting logged (in the appropriate file under /var/lib/pgsql/data/pg_log, if you haven't changed any other logging settings). Stop and restart a few times to get a good average. 5. Install the F15 version of postgresql.init (be sure to adjust the PGVERSION setting near the top of the file to be 9.1.0). 6. Start it that way a few times, note the same elapsed time. I'm seeing numbers consistently around 0.3 second for the unit file, and a bit less consistent but maybe 0.35 - 0.5 second for the script. Note that the time for the service to report itself ready after the database has started is likely to be quite a bit different between the two methods, but that is not systemd's fault. The init script just launches the postmaster, sleeps for 2 seconds, and then reports OK if it sees the postmaster has created a PID file. The unit file uses pg_ctl, which actually waits till it can make a successful connection to the postmaster, sleeping 1 second between tries. So it's a bit of a crapshoot which will be longer, though if you are starting from a clean database shutdown I'd expect pg_ctl to usually come back after the first sleep. So I'm not sure what's happening on Michal's machine, but from here I don't see anything egregiously wrong with systemd's performance on this test. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, Sep 14, 2011 at 6:54 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2011-09-14 at 18:23 +0200, drago01 wrote: What kind of disk is that? For a mechanical drive any gain from parallel startup would get killed by disk seeks. There is no real 'gain' from parallel startup when switching from upstart to systemd, Well we never had upstart (it was just a renamed sysvinit i.e we didn't use any of its parallel startup stuff). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, 2011-09-14 at 19:43 +0200, drago01 wrote: On Wed, Sep 14, 2011 at 6:54 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2011-09-14 at 18:23 +0200, drago01 wrote: What kind of disk is that? For a mechanical drive any gain from parallel startup would get killed by disk seeks. There is no real 'gain' from parallel startup when switching from upstart to systemd, Well we never had upstart (it was just a renamed sysvinit i.e we didn't use any of its parallel startup stuff). hum, I thought we were using its ability to parallel start things based on LSB deps. oh well. it's certainly *capable* of that, anyway. so parallelization is not a systemd win. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, Sep 14, 2011 at 1:06 PM, Tom Lane t...@redhat.com wrote: Here's what I did: ... 4. Note the time from the first date output to the database system is ready to accept connections message getting logged Tom, your methodology is sound. You're too kind to say but given the completion criteria of both init V script and systemd unit file, comparing their run times is a complete waste of time. The same is likely to be true with any long-lived network service. Thanks for steering the discussion towards something sane and productive. I'm seeing numbers consistently around 0.3 second for the unit file, and a bit less consistent but maybe 0.35 - 0.5 second for the script. Makes sense. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/14/2011 12:41 PM, Adam Williamson wrote: On Wed, 2011-09-14 at 07:43 -0400, Genes MailLists wrote: Also, I'd be curious if LP felt the risk was high or negligible - since his thoughts should carry more weight on this topic. I assume he would not think 5% of users would have un-bootable systems. No developer ever thinks their change is going to break anything for anyone. It's the QA Law of What Could Possibly Go Wrong. ;) Also worth noting is that LP has been traveling almost non-stop for about a week now. I spoke to him in person today, and he hasn't had a chance to really look at this thread at all yet. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Štěpán Kasal
Alle mercoledì 14 settembre 2011, Kevin Fenzi ha scritto: On Wed, 14 Sep 2011 08:58:11 +0200 Stepan Kasal ka...@ucw.cz wrote: Hello all, Therefore I'd like to ask FESCo to mass-orphan all packages owned by him. Should I open a ticket? yes, it is true that I'm not able to find any time to do my duties as a package maintainer. I agree that mass orphaning of the packages is a reasonable solution. I would be grateful if you could help me with that. Could one of you file a ticket for this? I guess in infrastructure trac and we will get it taken care of. Thanks Štěpán and Kevin, I created the Fedora Infrastructure ticket: https://fedorahosted.org/fedora-infrastructure/ticket/2950 Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 16 feels slow
Hi Fedora people. I have just installed F16 on my Asus 522 (a netbook) and everything works regarding hw. Good work everybody! However, compared to F15 everything feels really slow. Typing this has a delay of about .5 seconds for every character in Evolution, and logging into Gnome Shell takes a couple of minutes. Moving to another workspace takes a couple of seconds. Does anyone else get the same performance and is it expected to improve? I can not see that anything is hogging power in the system monitor, but there might be something I do not know that is slowing this machine down. Any info is appreciated! /Andreas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 4:02 PM, Andreas Tunek andreas.tu...@gmail.com wrote: Hi Fedora people. I have just installed F16 on my Asus 522 (a netbook) and everything works regarding hw. Good work everybody! However, compared to F15 everything feels really slow. Typing this has a delay of about .5 seconds for every character in Evolution, and logging into Gnome Shell takes a couple of minutes. Moving to another workspace takes a couple of seconds. Does anyone else get the same performance and is it expected to improve? I can not see that anything is hogging power in the system monitor, but there might be something I do not know that is slowing this machine down. Any info is appreciated! Try the 3.1-rc6 kernel sitting in bodhi waiting to be pushed to f16 stable. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 16:03:38 -0400, Josh Boyer jwbo...@gmail.com wrote: Try the 3.1-rc6 kernel sitting in bodhi waiting to be pushed to f16 stable. While I don't have hard numbers running that kernel seems to help. My rawhide system was so slow that I rebuilt that kernel (though probably I could have just used it) for f17 and am now seeing a lot of improvement there. The slow down is so bad for f17 at this time, that I plan to use kernels without debugging for the time being. I don't remember past rawhide kernels being this much slower. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, 2011-09-14 at 15:01 -0500, Bruno Wolff III wrote: On Wed, Sep 14, 2011 at 16:03:38 -0400, Josh Boyer jwbo...@gmail.com wrote: Try the 3.1-rc6 kernel sitting in bodhi waiting to be pushed to f16 stable. While I don't have hard numbers running that kernel seems to help. My rawhide system was so slow that I rebuilt that kernel (though probably I could have just used it) for f17 and am now seeing a lot of improvement there. The slow down is so bad for f17 at this time, that I plan to use kernels without debugging for the time being. I don't remember past rawhide kernels being this much slower. They weren't; see my numbers in the related bug (https://bugzilla.redhat.com/show_bug.cgi?id=735268 ). The debug overhead appears to have gotten much heavier in 3.1. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 13:46:40 -0700, Adam Williamson awill...@redhat.com wrote: They weren't; see my numbers in the related bug (https://bugzilla.redhat.com/show_bug.cgi?id=735268 ). The debug overhead appears to have gotten much heavier in 3.1. I added myself to that bug, though I wasn't really seeing that much of a slow down in graphics. (I have an rv280 which might not have the issue that later radeon cards were having.) My issue seems to be related to disk I/O. I am not sure if it is heavier cpu use in journalling, raid or encryption or if the actual I/O is slower. But it seems that I/O heavy activities such as yum updates and kernel builds are taking several times longer than they were a few weeks ago (in rawhide). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 13:28, Bruno Wolff III br...@wolff.to wrote: On Wed, Sep 14, 2011 at 13:46:40 -0700, Adam Williamson awill...@redhat.com wrote: They weren't; see my numbers in the related bug (https://bugzilla.redhat.com/show_bug.cgi?id=735268 ). The debug overhead appears to have gotten much heavier in 3.1. I added myself to that bug, though I wasn't really seeing that much of a slow down in graphics. (I have an rv280 which might not have the issue that later radeon cards were having.) My issue seems to be related to disk I/O. I am not sure if it is heavier cpu use in journalling, raid or encryption or if the actual I/O is slower. But it seems that I/O heavy activities such as yum updates and kernel builds are taking several times longer than they were a few weeks ago (in rawhide). I'm using the latest rawhide kernel. During times of heavy I/O the system becomes very unresponsive. The cursor will stop moving long enough to count to between 5 and 10. I know it happens with heavy network I/O so it might be the particular driver in my case. Not sure if the slow-down is true for other types of I/O. This has been true for all of the recent rawhide kernels. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, 2011-09-14 at 14:00 -0700, darrell pfeifer wrote: On Wed, Sep 14, 2011 at 13:28, Bruno Wolff III br...@wolff.to wrote: On Wed, Sep 14, 2011 at 13:46:40 -0700, Adam Williamson awill...@redhat.com wrote: They weren't; see my numbers in the related bug (https://bugzilla.redhat.com/show_bug.cgi?id=735268 ). The debug overhead appears to have gotten much heavier in 3.1. I added myself to that bug, though I wasn't really seeing that much of a slow down in graphics. (I have an rv280 which might not have the issue that later radeon cards were having.) My issue seems to be related to disk I/O. I am not sure if it is heavier cpu use in journalling, raid or encryption or if the actual I/O is slower. But it seems that I/O heavy activities such as yum updates and kernel builds are taking several times longer than they were a few weeks ago (in rawhide). I'm using the latest rawhide kernel. During times of heavy I/O the system becomes very unresponsive. The cursor will stop moving long enough to count to between 5 and 10. I know it happens with heavy network I/O so it might be the particular driver in my case. Not sure if the slow-down is true for other types of I/O. This has been true for all of the recent rawhide kernels. The 'fix' for the F16 kernel is simply that, with the rc6 build, debugging has been disabled. debugging is never disabled in Rawhide kernels, so if debugging overhead is your problem, no Rawhide kernel is going to cure it. To check if this is the case, just grab the latest F16 kernel - *not* the latest Rawhide kernel - and see if that improves things. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 14:16:16 -0700, Adam Williamson awill...@redhat.com wrote: The 'fix' for the F16 kernel is simply that, with the rc6 build, debugging has been disabled. debugging is never disabled in Rawhide kernels, so if debugging overhead is your problem, no Rawhide kernel is going to cure it. To check if this is the case, just grab the latest F16 kernel - *not* the latest Rawhide kernel - and see if that improves things. I think the degree of slow down now, compared with the past, makes this issue a bug. If things are like they are now, I won't be running debug kernels on my rawhide systems. It costs me too much time. It would be nice to know why things changed, as maybe some adjustments could be made (or a bug fixed) so that debug kernels can provide useful information without making such a big impact. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 03:59:02PM -0500, Bruno Wolff III wrote: I think the degree of slow down now, compared with the past, makes this issue a bug. If things are like they are now, I won't be running debug kernels on my rawhide systems. It costs me too much time. It would be nice to know why things changed, as maybe some adjustments could be made (or a bug fixed) so that debug kernels can provide useful information without making such a big impact. my last comment from the bug asked for someone to provide perf output. If we can at least narrow it down to which option is causing people pain, maybe we can start to investigate why. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/14/2011 12:35 PM, Reindl Harald wrote: Am 14.09.2011 14:16, schrieb Jóhann B. Guðmundsson: And FYI to all those that gloriously want to upgrade and claim that it's bug free or they ( all of what two people ) not encountered any issues inetd-style socket activation is borked in .35 ( users need to downgrade to .34 or add StandardOutput=socket if they cant wait until 36 goes out) it is a hughe difference upgrade to some rawhide stuff or leave F15 until now 10 releases behind and the next 8 months with all the missing features and problems as it was released! Reindl now let me tell you about my day.. I had ping Toshio regarding FPC might want to update their socket section to include xinetd ( since maintainers had shown concern both regarding to packaging this and what was the general policy with regards to converted xinetd socket/services ) which he of course brought up on their next meeting which was today... When I had time to look at irc from $dayjob I noticed that I had been ping and what awaits me was this... abadger1999: He's on what could only be usefully termed a crusade. It's actually somewhat damaging, but as long as nobody thinks that they're mandated to pay attention to him, it shouldn't hurt anything in the long run. So apparently me converting xinetd and packages that provide xinetd related files ( 33 packages including xinetd itself which produced 50+ unit files ) puts me on a somekind of crusade against xinetd and nobody should be paying attention to my work ( that was a whole ( last ) weekend I spent working on and off it ). Understandable Jason might have reach that conclusion if I had proposed the removal of xinetd itself but I have never made such an proposal. So Reindl by all means continue drag your rants into $next_releases it does not get any worse than this for people that what to improve your unfortunate experience and prevent others from experiencing it. By the way for those of you that were thinking about joining the migration process and lending a hand I strongly recommend against it unless you got the stomach for it. Talk about hostile work environment you ungrateful people. Thanks for making my day ( yet again ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non-responsive Maintainer: Andreas Osowski (th0br0)
Hello, all. I have been trying to contact Andreas Osowski (CC-ed) about updating Almanah to upstream 0.8.0 (bug 720544 [1]). I have pinged him twice on this bug report (once on August 19 and again on September 3). I also emailed him directly just over two days ago; but have unfortunately received no response to any of these inquiries. I also attempted to contact him on IRC (user th0br0 on Freenode); but his WHOIS shows him unavailable (Auto Away at Fri Jul 8 23:14:02 2011). He is not listed on the Vacation wiki page [2]; and his user info page [3] shows his current status as Active. According to Koji, his last activity was a rebuild of the mumble package, dated September 12. In accordance with the Fedora Non-responsive Maintainer Policy [4], does anyone know an alternative method to contact Andreas? Thank you, and regards. [1] https://bugzilla.redhat.com/show_bug.cgi?id=720544 [2] https://fedoraproject.org/wiki/Vacation [3] https://admin.fedoraproject.org/accounts/user/view/th0br0 [4] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers P.S. Andreas, if you're out there, please let us know! :-) -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: Andreas Osowski (th0br0)
Hello all, sorry for this small hassle, I was planning to answer Peter's last e-mail tomorrow as I was unable to do so today. @Peter: The update is the first thing on my todo list for tomorrow together with a rebuild of mumble for F16 rawhide. - Andreas On Wed, Sep 14, 2011 at 11:50 PM, Peter Gordon pe...@thecodergeek.comwrote: Hello, all. I have been trying to contact Andreas Osowski (CC-ed) about updating Almanah to upstream 0.8.0 (bug 720544 [1]). I have pinged him twice on this bug report (once on August 19 and again on September 3). I also emailed him directly just over two days ago; but have unfortunately received no response to any of these inquiries. I also attempted to contact him on IRC (user th0br0 on Freenode); but his WHOIS shows him unavailable (Auto Away at Fri Jul 8 23:14:02 2011). He is not listed on the Vacation wiki page [2]; and his user info page [3] shows his current status as Active. According to Koji, his last activity was a rebuild of the mumble package, dated September 12. In accordance with the Fedora Non-responsive Maintainer Policy [4], does anyone know an alternative method to contact Andreas? Thank you, and regards. [1] https://bugzilla.redhat.com/show_bug.cgi?id=720544 [2] https://fedoraproject.org/wiki/Vacation [3] https://admin.fedoraproject.org/accounts/user/view/th0br0 [4] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers P.S. Andreas, if you're out there, please let us know! :-) -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
Adam Williamson (awill...@redhat.com) said: Well we never had upstart (it was just a renamed sysvinit i.e we didn't use any of its parallel startup stuff). hum, I thought we were using its ability to parallel start things based on LSB deps. oh well. it's certainly *capable* of that, anyway. so parallelization is not a systemd win. upstart can parallelize native upstart services; it doesn't do anything with sysv/LSB scripts. In upstart, they were launched from /etc/rc.d/rc, just as before. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On Wed, 14 Sep 2011 21:48:48 + Jóhann B. Guðmundsson johan...@gmail.com wrote: ...snip... When I had time to look at irc from $dayjob I noticed that I had been ping and what awaits me was this... abadger1999: He's on what could only be usefully termed a crusade. It's actually somewhat damaging, but as long as nobody thinks that they're mandated to pay attention to him, it shouldn't hurt anything in the long run. ...snip... I'd like to note that Toshio (abadger1999 on IRC) did in fact not say this. It was someone else answering them. That said, I'd refer to the following from the excellent freenode catalysts page ( http://freenode.net/catalysts.shtml ): Open-minded. It's easy to make assumptions about other people's motivations. When you decide someone is behaving maliciously, you've made an assumption about their motivation which may be difficult to disprove. Try to make your assumptions about other people's motivations as positive as possible. Careful. Everything you say will be interpreted by the users with whom you interact. Consider how your remarks will be interpreted before you make them. Make sure the message you convey is the one you intend. Courteous. Even under time pressure, courtesy costs little and impresses people a lot. It's not about whether working with the person is easy or difficult; it's about setting the right tone. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 17:28:10 -0400, Dave Jones da...@redhat.com wrote: On Wed, Sep 14, 2011 at 03:59:02PM -0500, Bruno Wolff III wrote: I think the degree of slow down now, compared with the past, makes this issue a bug. If things are like they are now, I won't be running debug kernels on my rawhide systems. It costs me too much time. It would be nice to know why things changed, as maybe some adjustments could be made (or a bug fixed) so that debug kernels can provide useful information without making such a big impact. my last comment from the bug asked for someone to provide perf output. If we can at least narrow it down to which option is causing people pain, maybe we can start to investigate why. I'll try to run the perf stuff over the weekend. Kernel compiles are pretty slow on my hardware, so I am not going to run through all possible config options, though I can try a couple if there are some prime suspects. (Normally it's a couple of hours to build one, but the last one took all night.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Resolved] Re: Non-responsive Maintainer: Andreas Osowski (th0br0)
On 09/14/2011 02:57 PM, Andreas Osowski wrote: Hello all, sorry for this small hassle, I was planning to answer Peter's last e-mail tomorrow as I was unable to do so today. @Peter: The update is the first thing on my todo list for tomorrow together with a rebuild of mumble for F16 rawhide. Thanks for the heads-up, Andreas. Good to hear that you're alright and working on it. I'll calm down now. =) -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On 09/14/2011 10:32 PM, Kevin Fenzi wrote: I'd like to note that Toshio (abadger1999 on IRC) did in fact not say this. It was someone else answering them. Oh no he would never in fact Toshio has been one of the more helpful person to me always and he is one of the person I look for inspiration within the project so I'm truly sorry Toshio if this came out that way I thought that was clear that it was Jason that said this so from the bottom of my heart please accept my apologies. So to prevent any misunderstanding it was Jason that said this. ( as the meeting log show ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proventesters weekly meetup
Greetings. In some of the recent discussions of issues with the current updates policy, one idea that was suggested was to try and get proventesters to meet up say once a week. This would allow us to discuss and look at pending critical path updates that need testing or security updates or other testing matters. So, while I don't know that I have time long term to run a weekly proventester meeting, I'd like to try and start one and see if it takes off or is useful and/or if someone is willing to help run them moving forward. I'd suggest an agenda something like: * List out/go over critpath updates that are in testing. Can we add test cases? Can we just sit there and test that thing or confirm we already did test and it add karma? Do we know someone who uses/has the needed setup? * Look at pending security updates and do the same * Bring up any other updates that maintainers shout out on or a proventester wants help testing. I'd like to try next tuesday (2011-09-20) or wed (2011-09-21), but I guess I should see if there is enough interest first. So, proventesters: Any interest in a weekly meetup? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] question
On Wed, 2011-09-14 at 09:05 +0200, Reindl Harald wrote: and force a switch to systemd at the same time and then force the users to upgrade again to F16 as soon as possible to get systemd updated is simply the wrong way I agree! other piece of email : And FYI to all those that gloriously want to upgrade and claim that it's bug free or they ( all of what two people ) not encountered any issues inetd-style socket activation is borked in .35 ( users need to downgrade to .34 or add StandardOutput=socket if they cant wait until 36 goes out ). So Fedora 15, should go to systemd .34 . Put in updates-testing, do some testing and push to updates. EOL of Fedora 15 is more than 6 months, and shouldn't have a beta release of systemd, if systemd enter in a early stage in Fedora 15 , should be upgradeable ... ( I think). So what is the point in have a early stage of a software, if we don't update with bug fixes and features done. Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proventesters weekly meetup
On 09/15/2011 12:19 AM, Kevin Fenzi wrote: Greetings. In some of the recent discussions of issues with the current updates policy, one idea that was suggested was to try and get proventesters to meet up say once a week. This would allow us to discuss and look at pending critical path updates that need testing or security updates or other testing matters. So, while I don't know that I have time long term to run a weekly proventester meeting, I'd like to try and start one and see if it takes off or is useful and/or if someone is willing to help run them moving forward. I'd suggest an agenda something like: * List out/go over critpath updates that are in testing. Can we add test cases? Can we just sit there and test that thing or confirm we already did test and it add karma? Do we know someone who uses/has the needed setup? * Look at pending security updates and do the same * Bring up any other updates that maintainers shout out on or a proventester wants help testing. I'd like to try next tuesday (2011-09-20) or wed (2011-09-21), but I guess I should see if there is enough interest first. So, proventesters: Any interest in a weekly meetup? +1, also I would add to agenda: * Exchange ideas/tips on how-to test some pkg, etc... * Review the current test-cases (eg: I wrote/fixed a bunch of testcases but I'm not sure if they'll be correct in the future) Thanks, -- Athmane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: When are Qemu SPARC/PPC coming back?
On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: The context for this question can be found here: http://lists.fedoraproject.org/pipermail/virt-maint/2011-March/002289.html https://bugzilla.redhat.com/show_bug.cgi?id=679179 What I'm not fine with is that there seems to be no desire to bring these packages back. I spoke with several Red Hat virt people and the consensus was that SPARC/PPC don't work. I beg to differ. I am building asm software on them right now. They are an invaluable software testing platform, even with their relative age. So in short, can we please bring back SPARC/PPC? I realize that we'll need a bit of build system magickery, but I really think its worth it. No. Not magickery. Basically, it needs a build-able openbios or SLOF (in the ppc case). And since Fedora doesn't provide cross compilation, that is going to be hard to do in this case. As I see it, there is likely one option. It is possible that we leverage the secondary architecture builders for PPC and SPARC and natively build the code, then allow an exception for i686/x86_64 packages to use that natively built openbios/slof. It would need FESCo approval, but exceptions for bootstrapping have been granted before. All of this is predicated on someone stepping forward to do the work. So far, we've found people that don't want to do the work but we need to work the opposite angle. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: When are Qemu SPARC/PPC coming back?
On Wed, Sep 14, 2011 at 8:13 PM, Josh Boyer jwbo...@gmail.com wrote: On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: The context for this question can be found here: http://lists.fedoraproject.org/pipermail/virt-maint/2011-March/002289.html https://bugzilla.redhat.com/show_bug.cgi?id=679179 What I'm not fine with is that there seems to be no desire to bring these packages back. I spoke with several Red Hat virt people and the consensus was that SPARC/PPC don't work. I beg to differ. I am building asm software on them right now. They are an invaluable software testing platform, even with their relative age. So in short, can we please bring back SPARC/PPC? I realize that we'll need a bit of build system magickery, but I really think its worth it. No. Not magickery. Basically, it needs a build-able openbios or SLOF (in the ppc case). And since Fedora doesn't provide cross compilation, that is going to be hard to do in this case. As I see it, there is likely one option. It is possible that we leverage the secondary architecture builders for PPC and SPARC and natively build the code, then allow an exception for i686/x86_64 packages to use that natively built openbios/slof. It would need FESCo approval, but exceptions for bootstrapping have been granted before. All of this is predicated on someone stepping forward to do the work. So far, we've found people that don't want to do the work but we need to work the opposite angle. No. Not magickery. ... Fedora doesn't provide cross compilation ... How is this not magickery? Heck, even the build them natively and allow other arches to use them is magickery... Of course, there is a second option, and one that require far less work: use the binaries that qemu provides. Yes, I know its evil and all that (and I agree). Except that in this case the binaries are made form open code that's just hard to build (and absent investment in infrastructure, won't get any easier) and for which upstream already does the hard work. Further these binary firmwares are actually running in an emulator and as such the possible damage is approaching 0. Will it be harder to debug? Maybe, but I doubt it. In fact, you could make an argument that shipping the upstream bios builds is the best way to get upstream support for our build. I'm happy for this issue to go to FESCo, but I don't think this issue should be dropped. Having the ability to test software on the not-so-obscure PPC and SPARC (seriously, we ship sh4/m68k, but not these two?) is a really important feature, the lack of which will cost people real money (or worse, they'll just go to Debian/Ubuntu who seem to have no problem packaging it). And lastly, lest I just seem like I'm asking for stuff for free, let me know what I can do to help. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: When are Qemu SPARC/PPC coming back?
On Wed, Sep 14, 2011 at 8:45 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: On Wed, Sep 14, 2011 at 8:13 PM, Josh Boyer jwbo...@gmail.com wrote: On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: The context for this question can be found here: http://lists.fedoraproject.org/pipermail/virt-maint/2011-March/002289.html https://bugzilla.redhat.com/show_bug.cgi?id=679179 What I'm not fine with is that there seems to be no desire to bring these packages back. I spoke with several Red Hat virt people and the consensus was that SPARC/PPC don't work. I beg to differ. I am building asm software on them right now. They are an invaluable software testing platform, even with their relative age. So in short, can we please bring back SPARC/PPC? I realize that we'll need a bit of build system magickery, but I really think its worth it. No. Not magickery. Basically, it needs a build-able openbios or SLOF (in the ppc case). And since Fedora doesn't provide cross compilation, that is going to be hard to do in this case. As I see it, there is likely one option. It is possible that we leverage the secondary architecture builders for PPC and SPARC and natively build the code, then allow an exception for i686/x86_64 packages to use that natively built openbios/slof. It would need FESCo approval, but exceptions for bootstrapping have been granted before. All of this is predicated on someone stepping forward to do the work. So far, we've found people that don't want to do the work but we need to work the opposite angle. No. Not magickery. ... Fedora doesn't provide cross compilation ... How is this not magickery? Heck, even the build them natively and allow other arches to use them is magickery... Not it's not. You build them as noarch. It's not magic at all. Of course, there is a second option, and one that require far less work: use the binaries that qemu provides. Yes, I know its evil and all that (and I agree). Except that in this case the binaries are made form open code that's just hard to build (and absent investment in infrastructure, won't get any easier) and for which upstream already does the hard work. Further these binary firmwares are actually running in an emulator and as such the possible damage is approaching 0. Will it be harder to debug? Maybe, but I doubt it. In fact, you could make an argument that shipping the upstream bios builds is the best way to get upstream support for our build. You could try and get an exception from FESCo for that, yes. I'm not sure it would be approved until someone actually tries building them first. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: When are Qemu SPARC/PPC coming back?
On Wed, Sep 14, 2011 at 9:12 PM, Josh Boyer jwbo...@gmail.com wrote: On Wed, Sep 14, 2011 at 8:45 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: On Wed, Sep 14, 2011 at 8:13 PM, Josh Boyer jwbo...@gmail.com wrote: On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: The context for this question can be found here: http://lists.fedoraproject.org/pipermail/virt-maint/2011-March/002289.html https://bugzilla.redhat.com/show_bug.cgi?id=679179 What I'm not fine with is that there seems to be no desire to bring these packages back. I spoke with several Red Hat virt people and the consensus was that SPARC/PPC don't work. I beg to differ. I am building asm software on them right now. They are an invaluable software testing platform, even with their relative age. So in short, can we please bring back SPARC/PPC? I realize that we'll need a bit of build system magickery, but I really think its worth it. No. Not magickery. Basically, it needs a build-able openbios or SLOF (in the ppc case). And since Fedora doesn't provide cross compilation, that is going to be hard to do in this case. As I see it, there is likely one option. It is possible that we leverage the secondary architecture builders for PPC and SPARC and natively build the code, then allow an exception for i686/x86_64 packages to use that natively built openbios/slof. It would need FESCo approval, but exceptions for bootstrapping have been granted before. All of this is predicated on someone stepping forward to do the work. So far, we've found people that don't want to do the work but we need to work the opposite angle. No. Not magickery. ... Fedora doesn't provide cross compilation ... How is this not magickery? Heck, even the build them natively and allow other arches to use them is magickery... Not it's not. You build them as noarch. It's not magic at all. Of course, there is a second option, and one that require far less work: use the binaries that qemu provides. Yes, I know its evil and all that (and I agree). Except that in this case the binaries are made form open code that's just hard to build (and absent investment in infrastructure, won't get any easier) and for which upstream already does the hard work. Further these binary firmwares are actually running in an emulator and as such the possible damage is approaching 0. Will it be harder to debug? Maybe, but I doubt it. In fact, you could make an argument that shipping the upstream bios builds is the best way to get upstream support for our build. You could try and get an exception from FESCo for that, yes. I'm not sure it would be approved until someone actually tries building them first. Care to walk me through the process? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Wed, 14.09.11 01:03, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi 2011/9/13 Tom Lane t...@redhat.com: (This isn't new with 9.1, btw --- the last version or so of 9.0 for F16 was the same, since we switched over to native systemd files.) I used this service file on F15 and it starts slower 4214ms postgresql.service if we compare with an old SysVinit script 2469ms postgresql.service So I wonder if it makes sense to convert in such case? (I know that it is not about boot speed, it can start slower if needed.) I am currently travelling, so I don't have the peace to fully read and reply to this thread, but let me clear up a few things: a) don't misunderstand systemd-analyze, the times reported by it are wallclock times, and hence parallelization increases these values since the jobs are influenced by others (while decreasing the overall time). the values are interesting in comparison to other values from the same boot, but even then need to be read with a grain of salt. b) systemd doesn't really do anything that was computation intensive. so there's no real reason for the slowdown, and definitely fixable. I am not sure what pgsql is doing there on startup... might be something on those scripts, not necessarily systemd at fault. As long as this is a problem for pg only and nothing else this is a strong indication for this. Either way, I don't want to point fingers, and I don't really know what's going on, but what I actually do know is that the currently available measurement data is not useful, we need to investigate this further and then figure out what's really going on and where there's something to fix. I'll look into this in detail next week. Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum S3 plugin
So, I gather no one can shed some light on this? anyone? bueller? The bug (point #2) doesn't really stop the plugin from working, but it is annoying. Any help would be much appreciated On Fri, Sep 09, 2011 at 01:03:24PM -0700, Jorge Gallegos wrote: (to both cloud@ and devel@) I was interested in a yum plugin to support S3, and discovered [1]this forum post, where Seth and James basically gave their thumbs up. The author (Robert Mela, even though he's not the original author either) made it work and there was some feedback provided, which I incorporated, along with a bunch of small improvements in my [2]github branch. Robert says in the forum post that he'll be happy if someone shepherds this into completion and I'm more than happy to try. Right now the plugin works, is a bit more aligned with the yum plugin architecture I think (I'd really like it to be true :) and also allows you to set the S3 credentials on a global, per-repo or using environment variables. There are 2 things I want to complete/need help with: - Package it as an RPM: I have a half-finished spec for this and I should have no problems finishing as long as I can deal with the item below: - Fix an annoying bug where the plugin creates an empty yum cachedir in the current directory. This is because the way the plugin works, it creates a copy of the original repo with a different grabber based on boto/urllib2 and then copies the rest of the attributes. However when the [3]new repo is created, basecachedir is empty. Can any of you fine people spot a way around that? it's been bugging me for a good week now. thoughts? comments? suggestions? let me know :) Cheers ~kad PS if you're asking yourselves: Why would you need this plugin if you can create websites off an S3 bucket? the answer is: using S3 offers more granularity to share, instead of just opening up the contents of the bucket to the entire world. [1] http://www.bluequartz.us/phpBB2/viewtopic.php?p=568109sid=d3462de3a07fc65561c69f5b940ac6df [2] https://github.com/thekad/yum-s3-plugin/tree/v1.1.x [3] https://github.com/thekad/yum-s3-plugin/blob/v1.1.x/s3.py#L228 pgp8Ua5Wve8KX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On 09/14/2011 06:23 PM, drago01 wrote: On Wed, Sep 14, 2011 at 5:34 PM, Ralf Corsepiusrc040...@freenet.de wrote: My netbook boots up F14 in ca. 60 secs, while F15 boots up in 62 secs. I'd call this below measurement accuracy. What kind of disk is that? It's ca. 3 years old WD Scorpio Blue 160 GB ( WD1600BEVT) in a first generation Atom N270 (32bit only) based netbook w/ 2GB RAM. For a mechanical drive any gain from parallel startup would get killed by disk seeks. Sure, slow disks certainly are a factor contributing to slow bootup times. In general, there are other factors coming into play, such as parallel startup using more memory, parallelization not providing many advantages on systems with a small number of CPU cores, hard synchronisation points in the bootup process, poorly configured services, ... and finally ... bugs. Anyway, some more figures: On the same machine, bootup times when booting from a (slow) external (IDE) USB2 HD: - Fedora 15/i386: ca. 135 secs. - Ubuntu 11.04/i386: ca. 70 secs. [Here bootup time: Wirst watch measured time from grub prompt to login screen] It shows the effect of slow disks (60secs w/ internal HD vs. 2.15 minutes w/ USB HD), but raises questions on why Ubuntu appears to be so much faster in this configuration. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-HTML-FormatText-WithLinks-AndTables/f16] Rebuild against Perl 5.14
commit 4ba6f339a41970b71c2554b01951466147e7ba32
Author: Petr Písař ppi...@redhat.com
Date: Tue Sep 13 18:15:04 2011 +0200
Rebuild against Perl 5.14
perl-HTML-FormatText-WithLinks-AndTables.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTML-FormatText-WithLinks-AndTables.spec
b/perl-HTML-FormatText-WithLinks-AndTables.spec
index d8e8171..9b3b781 100644
--- a/perl-HTML-FormatText-WithLinks-AndTables.spec
+++ b/perl-HTML-FormatText-WithLinks-AndTables.spec
@@ -1,6 +1,6 @@
Name: perl-HTML-FormatText-WithLinks-AndTables
Version:0.01
-Release:2%{?dist}
+Release:2%{?dist}.1
Summary:Converts HTML to Text with tables in tact
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Sep 13 2011 Petr Pisar ppi...@redhat.com - 0.01-2.fc16.1
+- Rebuild against Perl 5.14
+
* Sun Jun 26 2011 Rüdiger Landmann r.landm...@redhat.com 0.01-2
- rm duplicate Requires
- verify license
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
