Re: Broken dependencies: perl-Data-HexDump

[Iain Arnell]

On Fri, Sep 16, 2011 at 7:04 AM,   wrote:
>
>
> perl-Data-HexDump has broken dependencies in the rawhide tree:
> On x86_64:
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(lib)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(:MODULE_COMPAT_5.8.8)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(FileHandle)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(Exporter)
>        perl-Data-HexDump-0.02-2.el5.noarch requires /usr/bin/perl
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(vars)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(Carp)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(strict)
> On i386:
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(lib)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(:MODULE_COMPAT_5.8.8)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(FileHandle)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(Exporter)
>        perl-Data-HexDump-0.02-2.el5.noarch requires /usr/bin/perl
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(vars)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(Carp)
>        perl-Data-HexDump-0.02-2.el5.noarch requires perl(strict)
> Please resolve this as soon as possible.
>



WTF! Broken deps for el5 packages in rawhide? For a build that doesn't
exist in koji? And a package that's not branched for EPEL?

Mail headers show that this seems to come from some private build
infrastructure at tnsi.com:

> Received: from relaybrisbn.tnsi.com (relaybrisbn.tnsi.com [113.197.125.11])
>   by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8G56d5m006068
>   for ;
>   Fri, 16 Sep 2011 01:06:42 -0400

Might I suggest that someone tweak fedora/redhat mail infrastructure
to avoid forwarding mail purporting to come from
build...@fedoraproject.org if it hasn't actually been sent by our own
build system?

-- 
Iain.
-- 
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?

[Ralf Corsepius]

On 09/15/2011 06:11 PM, Michal Schmidt wrote:
> On 09/15/2011 05:54 PM, Ralf Corsepius wrote:
>> On 09/15/2011 09:42 AM, "Jóhann B. Guðmundsson" wrote:
>>> On 09/15/2011 05:25 AM, Ralf Corsepius wrote:
 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.
>>>
>>> Could you run systemd-analyze plot>bootup.svg and post it somewhere
>>> online
>>
>> See: http://corsepiu.fedorapeople.org/scratch/bootup-20110915.1.svg
>
>From the long delay before swap.target is reached it seems that your
> defined swap partition never comes up and systemd times out waiting on it.

Good catch! A bogus UUID for swap in /etc/fstab seems to have been the 
cause of this excessive bootup time.

After having fixed the UUID, bootup times of this configuration are now 
are at ca. 70 secs, i.e. at par with booting from internal HD.
Interestingly the Ubuntu setup had a similar UUID issue. After having 
fixed it there, booting Ubuntu now is at ca. 50 secs.

However, this questions the earlier claims related to the impact of 
disk-io speed on bootup times - If disk-io was the limiting factor on 
this HW, I'd expect booting from internal HD to be significantly faster 
than booting from an external USB-HD. Apparently this does not apply [1].

Ralf

[1] Both setups' configurations are similar, but I haven't checked the 
details, yet.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Re-introducing and package peer-review request

[David Nalley]

On Thu, Sep 15, 2011 at 7:48 PM, Al Reay  wrote:
> Hi everyone,
>
> I'm keen to help out with Fedora by helping to create RPM packages and do
> some testing when possible. I work for a television station in NZ and look
> after most of the RHEL systems around the place including their video on
> demand product. My interests include motorcycling and computer game
> development; I hope to release a MIT-licensed 3D game based on OGRE in a
> couple of years time. I'd also be interested in helping with the maintenance
> of packages like OGRE.
>
> The first RPM I've got is a TCP/IP load balancer. It's a really simple RPM
> and it should be all ready to go with a systemd service script included too.
> This request is kind of old as I still haven't managed to attract a proven
> packager to sponsor me.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=679980  <= the latest SRPM and
> SPEC file at the bottom of the comments
>
> I have so far only helped out by reviewing one other package
> https://bugzilla.redhat.com/show_bug.cgi?id=736717 but I've got more time
> now to share the love.
>

Al,

I'll pick up the review and take care of getting you sponsored. As
I've asked in the package review itself, feel free to pick up a few
more informal reviews.

Thanks,

--David
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [RPM] for Jokosher 0.11.5 (F15 noarch)

[Dariusz J. Garbowski]

On 15/09/11 04:00 PM, Rahul Sundaram wrote:
> On 09/16/2011 02:10 AM, Manuel Escudero wrote:
>>
>> RPM -
>> http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.noarch.rpm
>>
>> SRC.RPM -
>> http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.src.rpm
>>
>> it's a "noarch" package so it can be installed in both 32 and 64 bit
>> systems,
>
> Jokosher upstream seems inactive.  This type of software typically
> requires a active upstream to be maintained properly.

There is *some* activity on the bug tracker, as well as this post on 
2011-May-01:
https://answers.launchpad.net/jokosher/+question/155290

Dariusz
-- 
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]

On Thu, 2011-09-15 at 19:10 -0500, Michael Ekstrand wrote:
> On 09/15/2011 05:27 PM, Adam Williamson wrote:
> > On Thu, 2011-09-15 at 14:14 -0400, Bernd Stramm wrote:
> > 
> >> Many computers are booted very rarely, once a day or so, and then
> >> sit idle for very long periods of time. This is very wasteful. The
> >> reason people do this is because booting takes a long time compared to
> >> starting the set of applications they use. 
> >>
> >> If you could boot and start applications in say, 1/2 second, usage
> >> patterns would be completely different.
> > 
> > What you really want there, though, is efficient and reliable suspend,
> > not full power cycle. This is what everyone does with cellphones and
> > tablets.
> 
> Or bulletproof session management.

True. As far as GNOME goes, though, whenever you suggest 'bulletproof
session management', they say 'that's what suspend is for'...
-- 
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?

[Michael Ekstrand]

On 09/15/2011 05:27 PM, Adam Williamson wrote:
> On Thu, 2011-09-15 at 14:14 -0400, Bernd Stramm wrote:
> 
>> Many computers are booted very rarely, once a day or so, and then
>> sit idle for very long periods of time. This is very wasteful. The
>> reason people do this is because booting takes a long time compared to
>> starting the set of applications they use. 
>>
>> If you could boot and start applications in say, 1/2 second, usage
>> patterns would be completely different.
> 
> What you really want there, though, is efficient and reliable suspend,
> not full power cycle. This is what everyone does with cellphones and
> tablets.

Or bulletproof session management.  With an encrypted disk, putting the
data at rest is beneficial.

Alternatively, hibernate could work if it were much faster, but my
recent experience with hibernate is that a full boot is notably faster.
 Once everything is built on systemd units and it be parallelized...

- Michael

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re-introducing and package peer-review request

[Al Reay]

Hi everyone,

I'm keen to help out with Fedora by helping to create RPM packages and do
some testing when possible. I work for a television station in NZ and look
after most of the RHEL systems around the place including their video on
demand product. My interests include motorcycling and computer game
development; I hope to release a MIT-licensed 3D game based on OGRE in a
couple of years time. I'd also be interested in helping with the maintenance
of packages like OGRE.

The first RPM I've got is a TCP/IP load balancer. It's a really simple RPM
and it should be all ready to go with a systemd service script included too.
This request is kind of old as I still haven't managed to attract a proven
packager to sponsor me.

https://bugzilla.redhat.com/show_bug.cgi?id=679980  <= the latest SRPM and
SPEC file at the bottom of the comments

I have so far only helped out by reviewing one other package
https://bugzilla.redhat.com/show_bug.cgi?id=736717 but I've got more time
now to share the love.

Cheers
Al
-- 
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?

[Bernd Stramm]

On Thu, 15 Sep 2011 15:27:49 -0700
Adam Williamson  wrote:

> On Thu, 2011-09-15 at 14:14 -0400, Bernd Stramm wrote:
> 
> > Many computers are booted very rarely, once a day or so, and then
> > sit idle for very long periods of time. This is very wasteful. The
> > reason people do this is because booting takes a long time compared
> > to starting the set of applications they use. 
> > 
> > If you could boot and start applications in say, 1/2 second, usage
> > patterns would be completely different.
> 
> What you really want there, though, is efficient and reliable suspend,
> not full power cycle. This is what everyone does with cellphones and
> tablets.

Yes, usually a user would want to preserve the state of their work
across the periods of them they are not using the system, as opposed to
a cold boot that clears everything. That is also what is normally wanted
from overnight shutdowns of systems that run during the business day.

-- 
Bernd Stramm
bernd.str...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Fedora 16 Beta Release Candidate 1 (RC1) Available Now!

[Adam Williamson]

On Thu, 2011-09-15 at 18:05 +0200, Stefan Held wrote:
> Am Donnerstag, den 15.09.2011, 10:39 -0400 schrieb Andre Robatino: 
> > As per the Fedora 16 schedule [1], Fedora 16 Beta Release Candidate 1
> > (RC1) is now available for testing. 
> 
> Is there a deltaiso?

Yes, there are always are, here:

http://dl.fedoraproject.org/pub/alt/stage/deltaisos/

if this isn't in the announcement, it should be...
-- 
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: Virtualization Test Day for F16 and Xen

[Adam Williamson]

On Thu, 2011-09-15 at 10:10 -0500, W. Michael Petullo wrote:
> >> 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
> 
> The Fedora update system reports this is fixed in grub2-1.99-6.fc16.
> 
> > https://bugzilla.redhat.com/show_bug.cgi?id=658387
> 
> Peter Jones submitted a new grubby package yesterday. This seems to fix
> bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry
> if /etc/sysconfig/kernel contains "HYPERVISOR=/boot/xen.gz").
> 
> I have not yet tested this on Fedora 16. However, I did test on Fedora
> 15. In this case, bug #668063 is still in effect. That is, grubby creates
> most of a GRUB record, but the "module initramfs-..." entry is missing.
> 
> Has anyone yet tested this new grubby package on Fedora 16 yet? Does
> using GRUB 2 makes #668063 irrelevant?
> 
> > https://bugzilla.redhat.com/show_bug.cgi?id=668063
> 
> I just added some more description to this bug.

So, there's a meta-point here: we currently 'require' Beta releases to
boot as guests on Xen hosts:

"The release must boot successfully as a virtual guest in a situation
where the virtual host is running a supported Xen implementation"

I really don't have much knowledge of Xen and haven't followed this
discussion closely, but do any currently-known bugs prevent this? If so,
please flag them up so they can be considered as Beta blockers...thanks!
-- 
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?

[Adam Williamson]

On Thu, 2011-09-15 at 14:14 -0400, Bernd Stramm wrote:

> Many computers are booted very rarely, once a day or so, and then
> sit idle for very long periods of time. This is very wasteful. The
> reason people do this is because booting takes a long time compared to
> starting the set of applications they use. 
> 
> If you could boot and start applications in say, 1/2 second, usage
> patterns would be completely different.

What you really want there, though, is efficient and reliable suspend,
not full power cycle. This is what everyone does with cellphones and
tablets.
-- 
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?

[Adam Williamson]

On Thu, 2011-09-15 at 17:54 +0200, Ralf Corsepius wrote:
> On 09/15/2011 09:42 AM, "Jóhann B. Guðmundsson" wrote:
> > On 09/15/2011 05:25 AM, Ralf Corsepius wrote:
> >> 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.
> >
> > Could you run systemd-analyze plot>  bootup.svg and post it somewhere
> > online
> 
> See: http://corsepiu.fedorapeople.org/scratch/bootup-20110915.1.svg
> 
> FWIW: Though the log says 110s, the wrist watch measured bootup time is 
> ca. 120-140 secs.

OS-side boot measurement tools cannot know how long the BIOS/EFI and
bootloader stages of boot took.
-- 
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: [RPM] for Jokosher 0.11.5 (F15 noarch)

[Rahul Sundaram]

On 09/16/2011 02:10 AM, Manuel Escudero wrote:
>
> RPM -
> http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.noarch.rpm
>
> SRC.RPM -
> http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.src.rpm
>
> it's a "noarch" package so it can be installed in both 32 and 64 bit
> systems,

Jokosher upstream seems inactive.  This type of software typically
requires a active upstream to be maintained properly. 

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [RPM] for Jokosher 0.11.5 (F15 noarch)

[Michael Schwendt]

On Thu, 15 Sep 2011 16:39:23 -0500, RS (Richard) wrote:

> Here's the updated SRPM:
> http://hobbes1069.fedorapeople.org/jokosher/jokosher-0.11.5-1.fc15.src.rpm
> 
> So the question remains, instead of seeing if someone else will submit
> it, why not submit it yourself?

Notice that jokosher used to be included within the Fedora Package
Collection, but has been retired before Fedora 15 "due to no active
owner":

  http://pkgs.fedoraproject.org/gitweb/?p=jokosher.git
  http://bugz.fedoraproject.org/jokosher

If latest upstream release is 0.11, there will need to be an Epoch bump
as Fedora's last builds have been an 1.0 pre-release from upstream scm.

Further reading:

  https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
  https://fedoraproject.org/wiki/PackageMaintainers

-- 
Fedora release 16 (Verne) - Linux 3.1.0-0.rc6.git0.0.fc16.x86_64
loadavg: 0.04 0.04 0.05
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [RPM] for Jokosher 0.11.5 (F15 noarch)

[David Nalley]

On Thu, Sep 15, 2011 at 5:50 PM, Manuel Escudero  wrote:
>
>
> 2011/9/15 Richard Shaw 
>>
>> On Thu, Sep 15, 2011 at 3:40 PM, Manuel Escudero 
>> wrote:
>> > Hi there Fedora People!!
>> >
>> > One of my biggest passions in life is audio editing, so when I started
>> > using
>> > Linux I found this friendly (yet powerful) audio editor called
>> > "Jokosher".
>> > When I
>> > installed Fedora 15, I realized that jokosher wasn't added to the F15
>> > repos
>> > and I missed it a lot, so I built an RPM using the lastest source code
>> > the
>> > jokosher developers have on their website:
>> > http://www.jokosher.org/
>> > and now I want to share it with you guys, so if someone wants to
>> > add it to the official repos that might be awesome, the download
>> > links are down here:
>> > RPM -
>> >
>> > http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.noarch.rpm
>> > SRC.RPM -
>> >
>> > http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.src.rpm
>> > it's a "noarch" package so it can be installed in both 32 and 64 bit
>> > systems,
>> > Enjoy!
>>
>> I pulled the SRPM and gave it a look over. Pretty good overall! I'm
>> not sure how much you've packaged before but I couldn't find much
>> wrong with it. Here's what I did find:
>>
>> 1. Why is the license GPLv2+ "with exceptions"?
>> 2. I got rid of %clean and "rm -rf %{buildroot}" in %install. You
>> don't need those anymore.
>> 3. I got rid of a lot of the white space in the description and fixed
>> one spelling error (rpmlint is your friend).
>> 4. %exclude in %files for the Profiling.py file is not the way to go.
>> That works well for excluding files you want in a separate
>> sub-package. In this case because the file (nor the byte-compiled
>> versions) are needed at all, I used "rm -f
>> %{buildroot}%{python_sitelib}/Jokosher/Profiler.py*" in %install
>> instead.
>> 5. I changed the release to "1" since it's from the stable source
>> instead of a pre-release checkout.
>> 6. Added "python2-devel" as a build requirement[1].
>>
>> Here's the updated SRPM:
>> http://hobbes1069.fedorapeople.org/jokosher/jokosher-0.11.5-1.fc15.src.rpm
>>
>> So the question remains, instead of seeing if someone else will submit
>> it, why not submit it yourself?
>>
>> Thanks,
>> Richard
>>
>> [1] http://fedoraproject.org/wiki/Packaging:Python#BuildRequires
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>
> Hi Richard:
>
> I'm not much of a packager, just learned the basics experimenting
> with Kmess some time ago... What I did was pulling an old RPM from
> F14 with pretty old Source code and then Rebuild a new package with
> the lastest source code, making some very little changes to the spec file.
>
> Humm I might be interested in pulling it into the repos if I knew how
> to do that but I'm not informed about that topic very much, so Don't
> Know how to submit it :S
>


We have a page for that:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [RPM] for Jokosher 0.11.5 (F15 noarch)

[Manuel Escudero]

2011/9/15 Richard Shaw 

> On Thu, Sep 15, 2011 at 3:40 PM, Manuel Escudero 
> wrote:
> > Hi there Fedora People!!
> >
> > One of my biggest passions in life is audio editing, so when I started
> using
> > Linux I found this friendly (yet powerful) audio editor called
> "Jokosher".
> > When I
> > installed Fedora 15, I realized that jokosher wasn't added to the F15
> repos
> > and I missed it a lot, so I built an RPM using the lastest source code
> the
> > jokosher developers have on their website:
> > http://www.jokosher.org/
> > and now I want to share it with you guys, so if someone wants to
> > add it to the official repos that might be awesome, the download
> > links are down here:
> > RPM -
> >
> http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.noarch.rpm
> > SRC.RPM -
> >
> http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.src.rpm
> > it's a "noarch" package so it can be installed in both 32 and 64 bit
> > systems,
> > Enjoy!
>
> I pulled the SRPM and gave it a look over. Pretty good overall! I'm
> not sure how much you've packaged before but I couldn't find much
> wrong with it. Here's what I did find:
>
> 1. Why is the license GPLv2+ "with exceptions"?
> 2. I got rid of %clean and "rm -rf %{buildroot}" in %install. You
> don't need those anymore.
> 3. I got rid of a lot of the white space in the description and fixed
> one spelling error (rpmlint is your friend).
> 4. %exclude in %files for the Profiling.py file is not the way to go.
> That works well for excluding files you want in a separate
> sub-package. In this case because the file (nor the byte-compiled
> versions) are needed at all, I used "rm -f
> %{buildroot}%{python_sitelib}/Jokosher/Profiler.py*" in %install
> instead.
> 5. I changed the release to "1" since it's from the stable source
> instead of a pre-release checkout.
> 6. Added "python2-devel" as a build requirement[1].
>
> Here's the updated SRPM:
> http://hobbes1069.fedorapeople.org/jokosher/jokosher-0.11.5-1.fc15.src.rpm
>
> So the question remains, instead of seeing if someone else will submit
> it, why not submit it yourself?
>
> Thanks,
> Richard
>
> [1] http://fedoraproject.org/wiki/Packaging:Python#BuildRequires
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Hi Richard:

I'm not much of a packager, just learned the basics experimenting
with Kmess some time ago... What I did was pulling an old RPM from
F14 with pretty old Source code and then Rebuild a new package with
the lastest source code, making some very little changes to the spec file.

Humm I might be interested in pulling it into the repos if I knew how
to do that but I'm not informed about that topic very much, so Don't
Know how to submit it :S

-- 
Manuel Escudero
Linux User #509052
Twitter: @Jmlevick 
Blogger: Blog Xenode 
PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15  8481 B77B 00CA C1E1 0FA7
Xenode Systems - xenodesystems.com  - "Conéctate
a Tu Mundo"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [RPM] for Jokosher 0.11.5 (F15 noarch)

[Richard Shaw]

On Thu, Sep 15, 2011 at 3:40 PM, Manuel Escudero  wrote:
> Hi there Fedora People!!
>
> One of my biggest passions in life is audio editing, so when I started using
> Linux I found this friendly (yet powerful) audio editor called "Jokosher".
> When I
> installed Fedora 15, I realized that jokosher wasn't added to the F15 repos
> and I missed it a lot, so I built an RPM using the lastest source code the
> jokosher developers have on their website:
> http://www.jokosher.org/
> and now I want to share it with you guys, so if someone wants to
> add it to the official repos that might be awesome, the download
> links are down here:
> RPM -
> http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.noarch.rpm
> SRC.RPM -
> http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.src.rpm
> it's a "noarch" package so it can be installed in both 32 and 64 bit
> systems,
> Enjoy!

I pulled the SRPM and gave it a look over. Pretty good overall! I'm
not sure how much you've packaged before but I couldn't find much
wrong with it. Here's what I did find:

1. Why is the license GPLv2+ "with exceptions"?
2. I got rid of %clean and "rm -rf %{buildroot}" in %install. You
don't need those anymore.
3. I got rid of a lot of the white space in the description and fixed
one spelling error (rpmlint is your friend).
4. %exclude in %files for the Profiling.py file is not the way to go.
That works well for excluding files you want in a separate
sub-package. In this case because the file (nor the byte-compiled
versions) are needed at all, I used "rm -f
%{buildroot}%{python_sitelib}/Jokosher/Profiler.py*" in %install
instead.
5. I changed the release to "1" since it's from the stable source
instead of a pre-release checkout.
6. Added "python2-devel" as a build requirement[1].

Here's the updated SRPM:
http://hobbes1069.fedorapeople.org/jokosher/jokosher-0.11.5-1.fc15.src.rpm

So the question remains, instead of seeing if someone else will submit
it, why not submit it yourself?

Thanks,
Richard

[1] http://fedoraproject.org/wiki/Packaging:Python#BuildRequires
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [389-devel] Please review: Make all backend operations transaction aware

[Noriko Hosoi]

Rich Megginson wrote:
> http://rmeggins.fedorapeople.org/patches/0001-Make-all-backend-operations-transaction-aware.patch
ack.
--noriko

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

[RPM] for Jokosher 0.11.5 (F15 noarch)

[Manuel Escudero]

Hi there Fedora People!!

One of my biggest passions in life is audio editing, so when I started using
Linux I found this friendly (yet powerful) audio editor called "Jokosher".
When I
installed Fedora 15, I realized that jokosher wasn't added to the F15 repos
and I missed it a lot, so I built an RPM using the lastest source code the
jokosher developers have on their website:

http://www.jokosher.org/

and now I want to share it with you guys, so if someone wants to
add it to the official repos that might be awesome, the download
links are down here:

RPM -
http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.noarch.rpm

SRC.RPM -
http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.src.rpm

it's a "noarch" package so it can be installed in both 32 and 64 bit
systems,

Enjoy!

-- 
Manuel Escudero
Linux User #509052
Twitter: @Jmlevick 
Blogger: Blog Xenode 
PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15  8481 B77B 00CA C1E1 0FA7
Xenode Systems - xenodesystems.com  - "Conéctate
a Tu Mundo"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] Please review: Make all backend operations transaction aware

[Rich Megginson]

http://rmeggins.fedorapeople.org/patches/0001-Make-all-backend-operations-transaction-aware.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Abrt does not work in F16

[Jiri Moskovcak]

On 09/15/2011 09:29 PM, Andreas Tunek wrote:
> Hi Fedora!
>
> Currently, the abrt reporting program does not seem to work for me, when
> I try to submit to bugzilla I get
>
> Essential file 'duphash' is missing, can't continue..
> (exited with 1)
>
> Is this a known problem or is there anything wrong on my part?
>
> /Andreas
>

Are you trying to submit an old crash? Please file a bz ticket for this 
issue.

Thank you,
Jirka
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 728667] Please build for EPEL-6

[bugzilla]

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=728667

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-POE-Component-Client-D
   ||NS-1.051-1.el6
 Resolution||ERRATA
Last Closed||2011-09-15 15:34:20

-- 
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 728669] Please build for EPEL-6

[bugzilla]

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=728669

--- Comment #5 from Fedora Update System  2011-09-15 
15:36:50 EDT ---
perl-POE-Component-Client-Keepalive-0.2620-1.el6 has been pushed to the Fedora
EPEL 6 stable repository.

-- 
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 733820] Please build for EPEL-6

[bugzilla]

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=733820

--- Comment #3 from Fedora Update System  2011-09-15 
15:36:14 EDT ---
perl-Test-POE-Server-TCP-1.16-1.el6 has been pushed to the Fedora EPEL 6 stable
repository.

-- 
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 728669] Please build for EPEL-6

[bugzilla]

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=728669

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-POE-Component-Client-K
   ||eepalive-0.2620-1.el6
 Resolution||ERRATA
Last Closed||2011-09-15 15:36:55

-- 
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 733820] Please build for EPEL-6

[bugzilla]

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=733820

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Test-POE-Server-TCP-1.
   ||16-1.el6
 Resolution||ERRATA
Last Closed||2011-09-15 15:36:19

-- 
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 728668] Please build for EPEL-6

[bugzilla]

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=728668

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-POE-Component-Client-H
   ||TTP-0.895-1.el6
 Resolution||ERRATA
Last Closed||2011-09-15 15:35:56

-- 
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 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary

[bugzilla]

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=712886

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Gtk2-1.224-2.fc16  |perl-Gtk2-1.224-2.el6

-- 
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 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary

[bugzilla]

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=712886

--- Comment #12 from Fedora Update System  
2011-09-15 15:35:28 EDT ---
perl-Gtk2-1.224-2.el6 has been pushed to the Fedora EPEL 6 stable repository. 
If problems still persist, please make note of it in this bug report.

-- 
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 728668] Please build for EPEL-6

[bugzilla]

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=728668

--- Comment #6 from Fedora Update System  2011-09-15 
15:35:52 EDT ---
perl-POE-Component-Client-HTTP-0.895-1.el6 has been pushed to the Fedora EPEL 6
stable repository.  If problems still persist, please make note of it in this
bug report.

-- 
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 728667] Please build for EPEL-6

[bugzilla]

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=728667

--- Comment #5 from Fedora Update System  2011-09-15 
15:34:12 EDT ---
perl-POE-Component-Client-DNS-1.051-1.el6 has been pushed to the Fedora EPEL 6
stable repository.

-- 
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

Abrt does not work in F16

[Andreas Tunek]

Hi Fedora!

Currently, the abrt reporting program does not seem to work for me, when
I try to submit to bugzilla I get 

Essential file 'duphash' is missing, can't continue..
(exited with 1)

Is this a known problem or is there anything wrong on my part?

/Andreas

-- 
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?

[Genes MailLists]

On 09/15/2011 02:14 PM, Bernd Stramm wrote:
> On Thu, 15 Sep 2011 18:27:29 +0100

> 
> Many computers are booted very rarely, once a day or so, and then
> sit idle for very long periods of time. This is very wasteful. The
> reason people do this is because booting takes a long time compared to
> starting the set of applications they use. 
> 
> If you could boot and start applications in say, 1/2 second, usage
> patterns would be completely different.
> 

 Possibly for some. I think we need to divide things up into 4
categories (maybe there are more).


 In my view, for most scenarios startup time is not terribly important
at all - for testers and developers it probably can be far more
significant.

  Any speedups are great to have for most, but if the choice was speedup
boot/start times or speedup the GUI, or fix bugs or just about anything
else ... probably best to spend resources elsewhere ... (assuming
resources are fungible, which of course they aren't :-) )

   --
  (i) Server.
   --

  These run all the time - reboots are most often in maintenance
window (or evenings / weekends for home servers) primarily if not soely
for kernel updates.

   *** boot time pain more occasional fsck costs and not service startup

   Pain caused by O/S updates - rolling release model would be ideal
for these.

  --
 (ii) Desktop.
 --

   Often left on, but reboots may happen a little sooner on kernel
update. Some turn them off for power consumption or other reasons - not
sure what fraction.

   *** Startup time not too important except possibly for developers
- esp kernel devs.

 --
 (iii) laptop.
 --

   typically put into sleep mode for transportation (i.e. close
lid). Restart time is extremely fast. Reboots as for (ii).

   *** Similar to (ii)

  --
  (iv) Virtual Machines
  --

   (a) Server
   *** Rarely rebooted - otherwise same as (ii)

   (b) specific needs (e.g. program a remote which needs windows
   ** boot time not too significant.

   (c) Testing and development on VM's -

   *** boot time probably could be important
-- 
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?

[Bernd Stramm]

On Thu, 15 Sep 2011 18:27:29 +0100
"Richard W.M. Jones"  wrote:

> On Thu, Sep 15, 2011 at 10:16:29AM +0200, Jan F. Chadima wrote:
> > It amazes me how much energy people spend on it to save 3 seconds a
> > day. Of course, if the computer being turned daily. In the case of a
> > server time saving is even more amazing.
> 
> Virtualization changes things.
> 
> The way _I_ use Fedora involves booting it dozens of times a day (of
> course, I'm talking about a VM or a very small Fedora appliance).
> 
> In any case, why *not* make things faster?  The way things are now, I
> have computers that boot a hundred of times more *slowly* than the
> first computer I owned.  Yes they do hundreds of times more things,
> but they also have a processor that is orders of magnitude faster.
> 
> Rich.
> 

Many computers are booted very rarely, once a day or so, and then
sit idle for very long periods of time. This is very wasteful. The
reason people do this is because booting takes a long time compared to
starting the set of applications they use. 

If you could boot and start applications in say, 1/2 second, usage
patterns would be completely different.

-- 
Bernd Stramm
bernd.str...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: When are Qemu SPARC/PPC coming back?

[Richard W.M. Jones]

On Wed, Sep 14, 2011 at 07:29:09PM -0400, Nathaniel McCallum 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
> 
> So the summary is that openbios needs to be compiled on PPC/SPARC and
> then imported to the rest of the repos as noarch.

Did you look into how hard it would be to cross-compile it?  Sounds
better than some sort of build hackery, particularly for users who
might want to build the whole thing from source themselves.  Fedora
contains (multiple) cross-compilers so there is precedent for this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what if native systemd service is slower than old sysvinit script?

[Richard W.M. Jones]

On Thu, Sep 15, 2011 at 10:16:29AM +0200, Jan F. Chadima wrote:
> It amazes me how much energy people spend on it to save 3 seconds a
> day. Of course, if the computer being turned daily. In the case of a
> server time saving is even more amazing.

Virtualization changes things.

The way _I_ use Fedora involves booting it dozens of times a day (of
course, I'm talking about a VM or a very small Fedora appliance).

In any case, why *not* make things faster?  The way things are now, I
have computers that boot a hundred of times more *slowly* than the
first computer I owned.  Yes they do hundreds of times more things,
but they also have a processor that is orders of magnitude faster.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: what if native systemd service is slower than old sysvinit script?

[Jóhann B. Guðmundsson]

On 09/15/2011 04:11 PM, Michal Schmidt wrote:
> On 09/15/2011 05:54 PM, Ralf Corsepius wrote:
>> On 09/15/2011 09:42 AM, "Jóhann B. Guðmundsson" wrote:
>>> On 09/15/2011 05:25 AM, Ralf Corsepius wrote:
 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.
>>> Could you run systemd-analyze plot>bootup.svg and post it somewhere
>>> online
>> See: http://corsepiu.fedorapeople.org/scratch/bootup-20110915.1.svg
>From the long delay before swap.target is reached it seems that your
> defined swap partition never comes up and systemd times out waiting on it.

If you dont use any lvm, raid and encrypted devices, you can safely turn 
off all fedora-* services
( Anaconda (F16) finally offers desktop users an easy way to opt out 
from lvm without being partitioning experts )

#cd /lib/systemd/system
#for i in fedora-*; do ln -s /dev/null /etc/systemd/system/$i;done

We throw in udev-settle since it gets pulled in by the storage setup
#ln -s /dev/null /etc/systemd/system/udev-settle.service

If you want speed not eye candy you can disable plymouth

#cd /lib/systemd/system
#for i in plymouth-*; do ln -s /dev/null /etc/systemd/system/$i;done

Then proceeding disabling all the service you dont use.

#for i in service1 service2 service3 etc... ; do systemctl disable $i ;done

JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Matthew Garrett]

On Thu, Sep 15, 2011 at 11:19:24AM -0500, Ian Pilcher wrote:
> On 09/15/2011 09:59 AM, Matthew Garrett wrote:
> > We're talking about guest creation, aren't we? Why would you ever need 
> > to run grub-install against a guest image that already exists? And if 
> > you do, you're already going to have problems come F17. It's likely that 
> > grub will no longer exist, but F15 guests will still need it rather than 
> > grub2.
> 
> Ugh.  This sound like it will make it pretty difficult to maintain a
> system that dual-boots Fedora and RHEL/CentOS/SL (or any other grub 1-
> only distro).
> 
> Am I reading this wrong?

grub1 can be installed in a partition from the older OS and then 
chainbooted by grub 2, if that's you're preferred way of doing things.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Peter Jones]

On 09/15/2011 12:19 PM, Ian Pilcher wrote:
> On 09/15/2011 09:59 AM, Matthew Garrett wrote:
>> We're talking about guest creation, aren't we? Why would you ever need
>> to run grub-install against a guest image that already exists? And if
>> you do, you're already going to have problems come F17. It's likely that
>> grub will no longer exist, but F15 guests will still need it rather than
>> grub2.
>
> Ugh.  This sound like it will make it pretty difficult to maintain a
> system that dual-boots Fedora and RHEL/CentOS/SL (or any other grub 1-
> only distro).
>
> Am I reading this wrong?

You can still chain load effectively, or share the whole bootloader. You
just can't mix and match, which is effectively what libguestfs winds up
doing.

-- 
 Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Ian Pilcher]

On 09/15/2011 09:59 AM, Matthew Garrett wrote:
> We're talking about guest creation, aren't we? Why would you ever need 
> to run grub-install against a guest image that already exists? And if 
> you do, you're already going to have problems come F17. It's likely that 
> grub will no longer exist, but F15 guests will still need it rather than 
> grub2.

Ugh.  This sound like it will make it pretty difficult to maintain a
system that dual-boots Fedora and RHEL/CentOS/SL (or any other grub 1-
only distro).

Am I reading this wrong?

-- 

Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Steve Clark]

On 09/15/2011 12:01 PM, Matthew Garrett wrote:

On Thu, Sep 15, 2011 at 04:56:43PM +0100, Richard W.M. Jones wrote:


For grub1 guests, it has turned out not to matter which specific
version of grub [as long as it was grub1] was used, as apparently
grub-install updates all files needed in /boot/grub as appropriate.
Or at least we haven't come across a guest where this hasn't worked
(yet -- we could be in for a surprise).

The most obvious case where it can fail involves grub being effectively
unmaintained, and so various vendors have extended it in different ways.
You may end up with valid configuration files for one distribution that
can't be parsed by the grub for another. The assumption you're making is
fragile. It's even worse for grub2, since it has a built-in module
loader. Modules built for one version of grub aren't guaranteed (or even
really expected) to work when loaded into another.


Hmm... there isn't a version check to prevent this Seems sort of fragile.

I'm very interested in how to reinstall bootloaders *without* invoking
guest code.  Also in how to not break the bootloader when moving or
aligning the boot partition, which sometimes happens for reasons we
don't understand (but not on all grub1 guests, only on RHEL 5 era
grub1).

You're asking for the impossible. The only supportable bootloader for a
specific guest is the bootloader that matches the installed OS. If you
want to support grub2 on Ubuntu, for instance, you'll need Ubuntu's
grub2 - not Fedora's. The binary interface may have changed between
them.




--
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: what if native systemd service is slower than old sysvinit script?

[Michal Schmidt]

On 09/15/2011 05:54 PM, Ralf Corsepius wrote:
> On 09/15/2011 09:42 AM, "Jóhann B. Guðmundsson" wrote:
>> On 09/15/2011 05:25 AM, Ralf Corsepius wrote:
>>> 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.
>>
>> Could you run systemd-analyze plot>   bootup.svg and post it somewhere
>> online
>
> See: http://corsepiu.fedorapeople.org/scratch/bootup-20110915.1.svg

 From the long delay before swap.target is reached it seems that your 
defined swap partition never comes up and systemd times out waiting on it.

Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Fedora 16 Beta Release Candidate 1 (RC1) Available Now!

[Stefan Held]

Am Donnerstag, den 15.09.2011, 10:39 -0400 schrieb Andre Robatino: 
> As per the Fedora 16 schedule [1], Fedora 16 Beta Release Candidate 1
> (RC1) is now available for testing. 

Is there a deltaiso?

-- 

Stefan Held  VI has only 2 Modes:
obi unixkiste orgThe first one is for beeping all the time,
FreeNode: foo_barthe second destroys the text.
---
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Matthew Garrett]

On Thu, Sep 15, 2011 at 04:56:43PM +0100, Richard W.M. Jones wrote:

> For grub1 guests, it has turned out not to matter which specific
> version of grub [as long as it was grub1] was used, as apparently
> grub-install updates all files needed in /boot/grub as appropriate.
> Or at least we haven't come across a guest where this hasn't worked
> (yet -- we could be in for a surprise).

The most obvious case where it can fail involves grub being effectively 
unmaintained, and so various vendors have extended it in different ways. 
You may end up with valid configuration files for one distribution that 
can't be parsed by the grub for another. The assumption you're making is 
fragile. It's even worse for grub2, since it has a built-in module 
loader. Modules built for one version of grub aren't guaranteed (or even 
really expected) to work when loaded into another.

> I'm very interested in how to reinstall bootloaders *without* invoking
> guest code.  Also in how to not break the bootloader when moving or
> aligning the boot partition, which sometimes happens for reasons we
> don't understand (but not on all grub1 guests, only on RHEL 5 era
> grub1).

You're asking for the impossible. The only supportable bootloader for a 
specific guest is the bootloader that matches the installed OS. If you 
want to support grub2 on Ubuntu, for instance, you'll need Ubuntu's 
grub2 - not Fedora's. The binary interface may have changed between 
them.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Yum S3 plugin

[James Antill]

On Wed, 2011-09-14 at 21:48 -0700, Jorge Gallegos wrote:
> 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

 You'd probably have been better off mailing this to the yum devel ML
and not fedora-devel. Anyway...

> >  - 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.

 This is due to the switch you are doing on the repo. objects ... using
itermitems() seems like it's clever, to get all the data from the
swapped out repo. ... but that's actually inherited from the config.
object, so all you are setting are the config. options.
 The RHN plugin just manually sets .base_persistdir, IIRC, and that will
probably fix it for you too. For your usecase I'd be very tempted to not
do the swapout at all (as it requires a lot of testing/etc.) as all you
really need is to override the grab object and set a couple of things.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Richard W.M. Jones]

On Thu, Sep 15, 2011 at 04:25:41PM +0100, Matthew Garrett wrote:
> On Thu, Sep 15, 2011 at 04:21:36PM +0100, Richard W.M. Jones wrote:
> > On Thu, Sep 15, 2011 at 03:59:57PM +0100, Matthew Garrett wrote:
> > > We're talking about guest creation, aren't we?
> > 
> > No, we're talking about fixing and resizing existing guests, where
> > grub-install needs to be run to fix the bootloader.
> 
> So how do you ensure that the version you run is the same version as the 
> package installed in the guest? Having those not match is an invitation 
> for bizarre failure down the line.

Well, this is interesting.

We're planning to snoop out whether the guest is using grub1 or grub2.
Previously this hasn't worked at all for (eg) Ubuntu guests.  This is
why providing grub2 in Fedora is great for us.

For grub1 guests, it has turned out not to matter which specific
version of grub [as long as it was grub1] was used, as apparently
grub-install updates all files needed in /boot/grub as appropriate.
Or at least we haven't come across a guest where this hasn't worked
(yet -- we could be in for a surprise).

I'm very interested in how to reinstall bootloaders *without* invoking
guest code.  Also in how to not break the bootloader when moving or
aligning the boot partition, which sometimes happens for reasons we
don't understand (but not on all grub1 guests, only on RHEL 5 era
grub1).

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?

[Ralf Corsepius]

On 09/15/2011 09:42 AM, "Jóhann B. Guðmundsson" wrote:
> On 09/15/2011 05:25 AM, Ralf Corsepius wrote:
>> 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.
>
> Could you run systemd-analyze plot>  bootup.svg and post it somewhere
> online

See: http://corsepiu.fedorapeople.org/scratch/bootup-20110915.1.svg

FWIW: Though the log says 110s, the wrist watch measured bootup time is 
ca. 120-140 secs.

Ralf


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Richard W.M. Jones]

On Thu, Sep 15, 2011 at 10:46:34AM -0400, Peter Jones wrote:
> On 09/15/2011 10:27 AM, Richard W.M. Jones wrote:
> >libguestfs, as I guess is well known, uses tools from the host in
> >order to manage guests.
>
> Honestly I don't think this is that well known, and looking at it
> I'm amazed this passed package review.  Why aren't you guys using
> any of the tools we've got to build images from packages instead of
> installing things on the host?  This is terribly bad behavior.

I'm assuming you mean 'appliance-creator'?  This tool isn't really
suitable; it's doing something quite different from what libguestfs
needs/uses.  They're solving different problems.

I'd suggest that you familiarize yourself with how libguestfs goes
about it first.  It's pretty well documented and I've included some
links below.  Then if there specific packaging issues that could be
solved better then I'm very interested to know.

Rich.

For an overview of what libguestfs is:
http://libguestfs.org/

For an overview of the supermin appliance that we use and how it
is made:
http://libguestfs.org/febootstrap.8.html
http://libguestfs.org/febootstrap-supermin-helper.8.html
https://rwmj.wordpress.com/2010/12/10/tip-creating-throwaway-appliances-with-febootstrap/
https://rwmj.wordpress.com/2009/10/22/supermin-appliance-now-in-febootstrap/

For some more specifics on the internals of libguestfs:
http://libguestfs.org/guestfs.3.html#internals

-- 
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: grub / grub2 conflicts

[Richard W.M. Jones]

I will simply say that this is not my view of what happened.  In any
case I hope we can be more excellent about this now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Peter Jones]

On 09/15/2011 11:16 AM, Richard W.M. Jones wrote:
> On Thu, Sep 15, 2011 at 10:46:34AM -0400, Peter Jones wrote:
>> On 09/15/2011 10:27 AM, Richard W.M. Jones wrote:
>>> So I propose that we drop this conflicts and fix grubby instead.
>>
>> We certainly can't do that without at least first fixing other problems.
>
> Could you explain (preferably with a full list of bugs) what you were
> trying to solve with the conflicts line in the spec file?  The only
> bugs I've seen so far describe problems in grubby, and this appears to
> be a workaround for them.  However it may be I don't have the full
> picture.

You're correct that this initially was added to work around a problem in
grubby, and I fully intend to further investigate that, as I said above. But
the fact remains that having multiple bootloaders installed, especially with
such similarly named tools, is a *bad idea*.

>>> However the maintainer of grub is unwilling to do this, which is why
>>> I've escalated this issue here.
>>
>> I've been asking you to explain why you need this and you stopped
>> participating in the conversation and started this thread instead.
>
> Since you starting swearing at me on IRC, I thought it better that we
> discuss this in technical terms, and mailing lists are in any case a
> better forum for technical discussions than chat.

Nice try - but the (somewhat reasonable) swearing was *after* you decided
to stop participating in the conversation and decided to move the discussion
elsewhere instead of helping to find the best way to solve the problem.

In no way is walking away from an ongoing conversation with relevant other
people who are trying to help you an appropriate response. At best it's just
rude. That's why after you did that, I said that you were being an asshole.
I apologize if my language offended you; I was frustrated that you began
behaving in an uncooperative manor when Matthew and I were trying to analyze
the full scale of the problem and find possible solutions to it. I should
have behaved more excellently towards you, even after you refused to answer
our questions.

-- 
 Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Matthew Garrett]

On Thu, Sep 15, 2011 at 04:21:36PM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 15, 2011 at 03:59:57PM +0100, Matthew Garrett wrote:
> > We're talking about guest creation, aren't we?
> 
> No, we're talking about fixing and resizing existing guests, where
> grub-install needs to be run to fix the bootloader.

So how do you ensure that the version you run is the same version as the 
package installed in the guest? Having those not match is an invitation 
for bizarre failure down the line.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Richard W.M. Jones]

On Thu, Sep 15, 2011 at 03:59:57PM +0100, Matthew Garrett wrote:
> We're talking about guest creation, aren't we?

No, we're talking about fixing and resizing existing guests, where
grub-install needs to be run to fix the bootloader.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Richard W.M. Jones]

On Thu, Sep 15, 2011 at 10:46:34AM -0400, Peter Jones wrote:
> On 09/15/2011 10:27 AM, Richard W.M. Jones wrote:
> >So I propose that we drop this conflicts and fix grubby instead.
> 
> We certainly can't do that without at least first fixing other problems.

Could you explain (preferably with a full list of bugs) what you were
trying to solve with the conflicts line in the spec file?  The only
bugs I've seen so far describe problems in grubby, and this appears to
be a workaround for them.  However it may be I don't have the full
picture.

> >However the maintainer of grub is unwilling to do this, which is why
> >I've escalated this issue here.
> 
> I've been asking you to explain why you need this and you stopped
> participating in the conversation and started this thread instead.

Since you starting swearing at me on IRC, I thought it better that we
discuss this in technical terms, and mailing lists are in any case a
better forum for technical discussions than chat.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
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 / dom0 testing instructions

[Pasi Kärkkäinen]

On Wed, Sep 14, 2011 at 05:45:39PM +0300, Pasi Kärkkäinen wrote:
> > 
> > > >([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.
> > 

Ok, so some basic steps to test Xen dom0 functionality in Fedora 16:

- Install Fedora 16 Beta TC2 host, to become Xen dom0. Installable ISO images 
available here:
  http://alt.fedoraproject.org/pub/alt/stage/16-Beta.TC2/Fedora/ 

  (and LIVE ISO's here: 
http://alt.fedoraproject.org/pub/alt/stage/16-Beta.TC2/Live/).

- Disk partitioning on the host: First partition should be /boot as ext3, 
  for the rest of the disk use LVM volume group, and remember to leave free 
space in the 
  volume group so you can later after installation create LVM volumes for the 
VMs.
  See these tutorials for an example about disk partitioning:

  http://wiki.xen.org/xenwiki/Fedora13Xen4Tutorial
  http://wiki.xen.org/xenwiki/RHEL6Xen4Tutorial

- After Fedora 16 is installed and everything works properly on baremetal, 
including Internet access,
  proceed to installing Xen and virtualization related packages:

  yum install xen xen-hypervisor xen-runtime libvirt virt-manager virt-viewer 
xorg-x11-xauth

- Enable automatic start of xend and libvirtd

  chkconfig xend on
  chkconfig libvirtd on

  chkconfig --list xend
  chkconfig --list libvirtd

- Add a suitable grub entry for Xen.

This grub entry is just an example, keep your own root device uuids/names etc 
and modify to suit your setup:

menuentry 'Xen dom0, Fedora Linux 3.1.0-rc6' --class fedora --class gnu-linux 
--class gnu --class os {
load_video
insmod part_gpt
insmod ext2
set root='(hd0,gpt2)'
search --no-floppy --fs-uuid --set=root 
6b84e53a-8a3a-4465-ac5a-c1c98758e448
multiboot   /xen-4.1.gz placeholder dom0_mem=1024M loglvl=all 
guest_loglvl=all console_to_ring cpuidle=xen
echo'Loading Linux 3.1.0-rc6 ...'
module  /vmlinuz-3.1.0-rc6 root=/dev/mapper/VolGroup00-lv_root ro 
rd.md=0 rd.dm=0  KEYTABLE=us debug loglvel=8 rd.lvm.lv=VolGroup00/lv_swap 
SYSFONT=latarcyrheb-sun16  rd.luks=0 rd.lvm.lv=VolGroup00/lv_root 
LANG=en_US.UTF-8
echo'Loading initial ramdisk ...'
module  /initramfs-3.1.0-rc6.img
}

grub entries will be automatically generated later, but currently grub/grubby 
does not have all required patches to do it automatically.


- Reboot to Xen dom0!

- Verify Xen and xend works:

  xm info
  xm list

- Verify you have a bridge called "virbr0" (use: "brctl show"). It should get 
created by libvirtd.
  There should be a "dnsmasq" process running for virbr0 providing that bridge 
a DHCP server with private IPs,
  dns relay and NAT to internet, so you can use it for VM network installations.

- Install a Fedora 15 Xen PV domU:

  First create a new LVM volume for the VM:
  lvcreate -L30G -nf15_disk1 /dev/VolGroup00

  (Replace VolGroup00 with your VG name.. use "vgdisplay" to check.)

  Start actual installation:
  virt-install -d -n f15 -r 1024 --vcpus=1 -f /dev/VolGroup00/f15_disk1 --vnc 
-p -l 
"ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/15/Fedora/x86_64/os/";

  (replace the URL with your local Fedora mirror site).
  virt-install will open a virt-viewer (VNC) graphical window of the guest 
console (pvfb) where you can do the Fedora installation as usual.

- Install and test various other types of VMs, both PV and HVM.
- Try using file: disk backend (image files) aswell.
- Try using graphical "virt-manager" GUI to install Xen VMs.

- Disable automatic start of xend, reboot, and test xl / libxl, 
  also with virt-manager/virt-install.


That should get you started with testing. 

Btw. I noticed some issues installing F16 Alpha Xen PV domU, so F16 needs some 
more investigation/debugging before F16 final.

-- Pasi

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtualization Test Day for F16 and Xen

[W. Michael Petullo]

>> 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

The Fedora update system reports this is fixed in grub2-1.99-6.fc16.

> https://bugzilla.redhat.com/show_bug.cgi?id=658387

Peter Jones submitted a new grubby package yesterday. This seems to fix
bug #658387 (i.e., new-kernel-pkg creates a Dom0-style grub.cfg entry
if /etc/sysconfig/kernel contains "HYPERVISOR=/boot/xen.gz").

I have not yet tested this on Fedora 16. However, I did test on Fedora
15. In this case, bug #668063 is still in effect. That is, grubby creates
most of a GRUB record, but the "module initramfs-..." entry is missing.

Has anyone yet tested this new grubby package on Fedora 16 yet? Does
using GRUB 2 makes #668063 irrelevant?

> https://bugzilla.redhat.com/show_bug.cgi?id=668063

I just added some more description to this bug.

-- 
Mike

:wq
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Matthew Garrett]

On Thu, Sep 15, 2011 at 03:36:55PM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 15, 2011 at 03:31:49PM +0100, Matthew Garrett wrote:
> > On Thu, Sep 15, 2011 at 03:27:16PM +0100, Richard W.M. Jones wrote:
> > 
> > > So I propose that we drop this conflicts and fix grubby instead.
> > 
> > No. It is not sane to have multiple bootloaders installed on one 
> > machine.
> 
> There's an interesting verbal trick there.  "multiple bootloaders" are
> not installed.  Multiple versions of the grub RPM package are
> installed.  Only one bootloader would be installed on the host.

grub and grub2 are different packages with approximately no code in 
common. They're different bootloaders. We don't support having multiple 
different bootloaders installed.

> > Just install the grub package in the guest, and chroot into the guest if 
> > you need to run grub-install there.
> 
> Running tools from out of the guest is insecure.  There are several
> ways in which a guest could exploit the host if we did this.  See
> "Security" here for some issues:
> 
> http://libguestfs.org/guestfs.3.html#running_commands

We're talking about guest creation, aren't we? Why would you ever need 
to run grub-install against a guest image that already exists? And if 
you do, you're already going to have problems come F17. It's likely that 
grub will no longer exist, but F15 guests will still need it rather than 
grub2.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Peter Jones]

On 09/15/2011 10:36 AM, Richard W.M. Jones wrote:
> On Thu, Sep 15, 2011 at 03:31:49PM +0100, Matthew Garrett wrote:
>> On Thu, Sep 15, 2011 at 03:27:16PM +0100, Richard W.M. Jones wrote:
>>
>>> So I propose that we drop this conflicts and fix grubby instead.
>>
>> No. It is not sane to have multiple bootloaders installed on one
>> machine.
>
> There's an interesting verbal trick there.  "multiple bootloaders" are
> not installed.  Multiple versions of the grub RPM package are
> installed.  Only one bootloader would be installed on the host.

It's really not useful or reasonable to think of grub and grub2 as "multiple
versions of the same bootloader" - they don't share tools, for example. But
even so, multiple versions of the same bootloader doesn't make sense either.

>> Requiring the ability to do so adds a significant amount of
>> extra complexity to the tools associated with it for no useful benefit.
>
> The useful benefit was outlined in the original email.

It really wasn't - it's still unclear why anybody would choose to do things
that way. On the face it's a completely wrong choice.

>> Just install the grub package in the guest, and chroot into the guest if
>> you need to run grub-install there.
>
> Running tools from out of the guest is insecure.  There are several
> ways in which a guest could exploit the host if we did this.  See
> "Security" here for some issues:
>
> http://libguestfs.org/guestfs.3.html#running_commands

"I wrote a web page about my opinions" does not make them fact. But even if we
took as given that it's somehow better not to use packages in the guest, it's
still not a reason to have the packages *unpacked and installed* on the host
system. Doing this introduces many more chances for exploitation and plain old
corruption and errors. At the very least it should be using raw, non-installed
packages on the host rather than installed ones. Which, by the way, Fedora
already has tools to accomplish.

-- 
 Peter

Power corrupts.  Absolute power is kind of neat.
-- John Lehman, Secretary of the Navy, 1981-1987
-- 
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?

[Bill Nottingham]

Steve Clark (scl...@netwolves.com) said: 
> Is there a reason Fedora "starts a bunch of stuff that pretty much nobody
> would use in a typical desktop system" ?

One example of a synchronization point is the LVM/dmraid/etc. startup. If
we were able to conclusively determine that there weren't any of these
devices to start, we wouldn't have to have that synchronization point and
tool execution.

We're working on a way to properly assemble this stuff as it comes in if
needed, but we're not there yet.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: When are Qemu SPARC/PPC coming back?

[Tom Callaway]

On 09/14/2011 07:29 PM, Nathaniel McCallum 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
> 
> So the summary is that openbios needs to be compiled on PPC/SPARC and
> then imported to the rest of the repos as noarch. Spot spoke with Josh
> Boyer who noted that PPC was prep-only (no longer true) and concluded
> based upon this two person conversation that PPC should be dropped
> since it wasn't useful for Fedora purposes (mainly the PPC port). No
> conversation was had about SPARC (which had the same problem) and it
> was dropped as well. In short, the bug didn't get very wide attention
> and support was dropped for two features in order to push the Beta
> release. All of this I'm actually fine with.
> 
> 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? 

At least for SPARC, there is no reason to enable it. It simply does not
work at all for SPARC64, and it doesn't do anything useful on SPARC32.

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Peter Jones]

On 09/15/2011 10:27 AM, Richard W.M. Jones wrote:
> This is about:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=737261
> "F16 TC2 DVD grub/grub2 conflict"
>
> The grub package in F16 has a "Conflicts: grub2" line.  There are no
> actual file conflicts, but this was added in order to workaround some
> bugs in grubby, including:

As mjg59 said - it's really not reasonable to have multiple bootloaders
installed on a system (especially by default, as you're essentially asking!)
It greatly increases the complexity in our tooling, as well as greatly
increasing the chances somebody accidentally bricks a box by running tools
for the bootloader they're not using.

> - https://bugzilla.redhat.com/show_bug.cgi?id=725185
> - https://bugzilla.redhat.com/show_bug.cgi?id=731226
>
> Now the problem is that libguestfs provides a way for people to use
> grub-install (and in the future grub2-install) on guests.  Think for
> example if you had a mix of Fedora 15 and Fedora 16 guests on your
> host.
>
> libguestfs, as I guess is well known, uses tools from the host in
> order to manage guests.

Honestly I don't think this is that well known, and looking at it I'm amazed
this passed package review.  Why aren't you guys using any of the tools we've
got to build images from packages instead of installing things on the host?
This is terribly bad behavior.

>  This is done so that we don't have to
> separately package all the tools, which would be a security headache
> (if there's a security issue discovered in grub-install, just updating
> the host package is enough to fix it -- you don't have to track down a
> separate copy statically bundled in libguestfs).

Trading half of one security problem (since you're not eliminating the
problem of security bugs already being installed in a guest) for the
problem of installing lots of extra packages on the host?  Not a win.

> Even if you don't care about libguestfs, you might well wish to
> loop-mount an old guest and run grub-install --root-directory=...  on
> it.

Nice strawman, but in that case grub-install will already be on any properly
installed guest.

> So I propose that we drop this conflicts and fix grubby instead.

We certainly can't do that without at least first fixing other problems. It'd
also be good to think about how we can fix libguestfs's terrible behavior.

> However the maintainer of grub is unwilling to do this, which is why
> I've escalated this issue here.

I've been asking you to explain why you need this and you stopped
participating in the conversation and started this thread instead. There are
a number of problems with this, not least that it's not how engineering
"escalations" even work.  In any case, I *still* haven't said I'm unwilling
to remove the conflicts (though we do need to debug the real problem and see
if it's solvable first), though in general I think it's a correct thing to
have there. I wanted to understand why you needed it first. You've been
mighty uncooperative at getting your own problem solved.

-- 
 Peter

Power corrupts.  Absolute power is kind of neat.
-- John Lehman, Secretary of the Navy, 1981-1987
-- 
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?

[Martin Langhoff]

2011/9/15 Michał Piotrowski :
> 2011/9/14 Tom Lane :
>> 3. As root, do
>> date --rfc-3339=ns ; systemctl start postgresql.service ; date --rfc-3339=ns
>
> with dropped cache
>
> date --rfc-3339=ns ; systemctl start postgresql.service ; date --rfc-3339=ns
> 2011-09-15 08:44:40.348239703+02:00
> 2011-09-15 08:44:44.651134587+02:00
>
> without dropped cache
> date --rfc-3339=ns ; systemctl start postgresql.service ; date --rfc-3339=ns
> 2011-09-15 08:45:38.388010217+02:00
> 2011-09-15 08:45:42.633229665+02:00

Note that those timings are not interesting -- you are comparing
apples to watermelons. Got to take #4 into consideration for a useful
reading.

(Read Tom's original email to the end for an explanation -- the init
script and service units exit on very peculiar conditions. So timing
their wallclock is a waste of time.)

>> 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.

So, what are your timings following step 4?

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

[Test-Announce] Fedora 16 Beta Release Candidate 1 (RC1) Available Now!

[Andre Robatino]

As per the Fedora 16 schedule [1], Fedora 16 Beta Release Candidate 1
(RC1) is now available for testing. Please see the following pages for
download links and testing instructions. In general, official live
images arrive a few hours after the install images: see the links below
for updates. When they appear, the download directory should be the same
as that for install images, except with the trailing "/Fedora/" replaced
by "/Live/".

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Security Lab:

https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test

Ideally, all Alpha and Beta priority test cases for Installation [2],
Base [3], Desktop [4], and Security Lab [5] should pass in order to meet
the Beta Release Criteria [6]. Help is available on #fedora-qa on
irc.freenode.net [7], or on the test list [8].

Create Fedora 16 Beta release candidate (RC) - live and traditional
https://fedorahosted.org/rel-eng/ticket/4923

F16 Beta Blocker tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713564

F16 Beta Nice-To-Have tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713565

[1] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/QA:Security_Lab_validation_testing
[6] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria
[7] irc://irc.freenode.net/fedora-qa
[8] https://admin.fedoraproject.org/mailman/listinfo/test



signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Richard W.M. Jones]

On Thu, Sep 15, 2011 at 03:31:49PM +0100, Matthew Garrett wrote:
> On Thu, Sep 15, 2011 at 03:27:16PM +0100, Richard W.M. Jones wrote:
> 
> > So I propose that we drop this conflicts and fix grubby instead.
> 
> No. It is not sane to have multiple bootloaders installed on one 
> machine.

There's an interesting verbal trick there.  "multiple bootloaders" are
not installed.  Multiple versions of the grub RPM package are
installed.  Only one bootloader would be installed on the host.

> Requiring the ability to do so adds a significant amount of 
> extra complexity to the tools associated with it for no useful benefit. 

The useful benefit was outlined in the original email.

> Just install the grub package in the guest, and chroot into the guest if 
> you need to run grub-install there.

Running tools from out of the guest is insecure.  There are several
ways in which a guest could exploit the host if we did this.  See
"Security" here for some issues:

http://libguestfs.org/guestfs.3.html#running_commands

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[Matthew Garrett]

On Thu, Sep 15, 2011 at 03:27:16PM +0100, Richard W.M. Jones wrote:

> So I propose that we drop this conflicts and fix grubby instead.

No. It is not sane to have multiple bootloaders installed on one 
machine. Requiring the ability to do so adds a significant amount of 
extra complexity to the tools associated with it for no useful benefit. 
Just install the grub package in the guest, and chroot into the guest if 
you need to run grub-install there.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

grub / grub2 conflicts

[Richard W.M. Jones]

This is about:

https://bugzilla.redhat.com/show_bug.cgi?id=737261
"F16 TC2 DVD grub/grub2 conflict"

The grub package in F16 has a "Conflicts: grub2" line.  There are no
actual file conflicts, but this was added in order to workaround some
bugs in grubby, including:

- https://bugzilla.redhat.com/show_bug.cgi?id=725185
- https://bugzilla.redhat.com/show_bug.cgi?id=731226

Now the problem is that libguestfs provides a way for people to use
grub-install (and in the future grub2-install) on guests.  Think for
example if you had a mix of Fedora 15 and Fedora 16 guests on your
host.

libguestfs, as I guess is well known, uses tools from the host in
order to manage guests.  This is done so that we don't have to
separately package all the tools, which would be a security headache
(if there's a security issue discovered in grub-install, just updating
the host package is enough to fix it -- you don't have to track down a
separate copy statically bundled in libguestfs).

Even if you don't care about libguestfs, you might well wish to
loop-mount an old guest and run grub-install --root-directory=...  on
it.

So I propose that we drop this conflicts and fix grubby instead.

However the maintainer of grub is unwilling to do this, which is why
I've escalated this issue here.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 16 feels slow

[Simo Sorce]

On Wed, 2011-09-14 at 14:16 -0700, Adam Williamson 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.

FWIW I dloaded rc6 an although my machine wasn't especially slow it is
now very snappy and I can finally enjoy my SSD as I should have.

Also with the debug kernels my machine used to go in thermal shutdown
2/3 times a day while compiling or yum installing.

It hasn't happened so far.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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?

[Jan F. Chadima]

On Sep 15, 2011, at 1:13 PM, drago01 wrote:

> On Thu, Sep 15, 2011 at 1:10 PM, Jan F. Chadima  wrote:
>> 
>> On Sep 15, 2011, at 1:02 PM, drago01 wrote:
>> 
>>> On Thu, Sep 15, 2011 at 12:10 PM, Jan F. Chadima  
>>> wrote:
 
 On Sep 15, 2011, at 11:03 AM, drago01 wrote:
 
> On Thu, Sep 15, 2011 at 10:16 AM, Jan F. Chadima  
> wrote:
>> [...]
>> . When watching the load of the virtual machine that starts with systemd 
>> it is clear to me that the total CPU consumption is significantly 
>> greater than in the case of upstart one.
> 
> That's the whole point of doing things in parallel ... the CPU is
> actually being *used* hence the higher CPU consumption. When you have
> work to do you want to throw all resources at it. To get back to your
> digger analogy ... when you employ 10 workers you'd rather want all of
> them to work not one doing all the work and the other 9 just sitting
> around.
 
 better is 1 working and 9 sitting than 10 injured :)
>>> 
>>> Well why not fire the other 9 and save money then? ;)
>> 
>> so cut off the remanding cores from the CPU, save only one, good luck :D
> 
> No I mean either write software to take advantage of them (i.e use
> them) or save money and buy slower / cheaper CPUs because you prefer
> software that does not use the available resources when needed.
> I prefer the former you seem to prefer the later ;)

If your only goal is to boot up and the to switch off or to crash … then you 
have to parallelize  boot.
I prefer to load the system by the applications ….. And I have no care on 10 
second longer boot 
Monitor the duration of the boot is ridiculous if uptime is more than a few 
hours.
Time spent discussing about the absurdity of systemd is fair enough for more 
than a year everyday classical boot sequence


> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Jan F. Chadima
jchad...@redhat.com



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: non-responsive icon theme maintainer

[Pierre-Yves Chibon]

On Thu, 2011-04-21 at 22:14 +0200, Johannes Lips wrote:
> Hello,
> 
> I tried to reach the maintainer of elementary-icon-theme.noarch for 
> several times now.[1] So far I didn't receive any notice if he even read 
> the mails from bugzilla.
> I don't feel the need to take over the package but if no one else wants 
> to do it. I am ok with caring for it.
> https://bugzilla.redhat.com/show_bug.cgi?id=684664
> 

I think we should consider orphaning all the packages owned by this
maintainer.

He has a bug opened against the Faenza icon theme since January on which
he never replied: https://bugzilla.redhat.com/show_bug.cgi?id=670435
He last activities on Bodhi and Koji are one year old:
https://admin.fedoraproject.org/updates/user/tajidinabd
http://koji.fedoraproject.org/koji/userinfo?userID=1464 

$ pkgdb-cli list --user tajidinabd
   elementary-icon-themeicons from the Elementary Project
   faenza-icon-themeicon theme for Equinox GTK theme
   itools   command line tools for The Islamic
Tools and Libraries Project
   xmldb-apiXML:DB API for Java
   xom  XML Pull Parser
   xpp3 XML Pull Parser
Total: 6 packages

I just sent an email directly to his archlinux.us email address asking
if he wishes to resign from his maintainer duties or if he is just busy.
Let's see if he replies.

Pierre
-- 
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?

[Ralf Corsepius]

On 09/15/2011 11:03 AM, drago01 wrote:
> On Thu, Sep 15, 2011 at 10:16 AM, Jan F. Chadima  wrote:
>> [...]
>> . When watching the load of the virtual machine that starts with systemd it 
>> is clear to me that the total CPU consumption is significantly greater than 
>> in the case of upstart one.
>
> That's the whole point of doing things in parallel ... the CPU is
> actually being *used* hence the higher CPU consumption. When you have
> work to do you want to throw all resources at it.

Not quite. One normally wants to get a job done _reasonably_ and 
_reliable_ within the possibilities of _available resources_.

Wrt. system bootup, this means, I don't care much on whether booting 
takes 40 or 80 seconds and don't care whether booting is parallelised, 
nor do I actually care about which init system is being used.

However, resource requirements, usability and reliabilty are a concern 
to me. That said, /me feels similarly to Gnome3, systemd still has a 
long way ahead to mature.

Ralf

-- 
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?

[drago01]

On Thu, Sep 15, 2011 at 1:10 PM, Jan F. Chadima  wrote:
>
> On Sep 15, 2011, at 1:02 PM, drago01 wrote:
>
>> On Thu, Sep 15, 2011 at 12:10 PM, Jan F. Chadima  wrote:
>>>
>>> On Sep 15, 2011, at 11:03 AM, drago01 wrote:
>>>
 On Thu, Sep 15, 2011 at 10:16 AM, Jan F. Chadima  
 wrote:
> [...]
> . When watching the load of the virtual machine that starts with systemd 
> it is clear to me that the total CPU consumption is significantly greater 
> than in the case of upstart one.

 That's the whole point of doing things in parallel ... the CPU is
 actually being *used* hence the higher CPU consumption. When you have
 work to do you want to throw all resources at it. To get back to your
 digger analogy ... when you employ 10 workers you'd rather want all of
 them to work not one doing all the work and the other 9 just sitting
 around.
>>>
>>> better is 1 working and 9 sitting than 10 injured :)
>>
>> Well why not fire the other 9 and save money then? ;)
>
> so cut off the remanding cores from the CPU, save only one, good luck :D

No I mean either write software to take advantage of them (i.e use
them) or save money and buy slower / cheaper CPUs because you prefer
software that does not use the available resources when needed.
I prefer the former you seem to prefer the later ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Time-Piece-MySQL/f16] Do not provide private perl(Time::Piece)

[Petr Pisar]

Summary of changes:

  b951bea... Do not provide private perl(Time::Piece) (*)

(*) This commit already existed in another branch; no separate mail sent
--
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?

[Jan F. Chadima]

On Sep 15, 2011, at 1:02 PM, drago01 wrote:

> On Thu, Sep 15, 2011 at 12:10 PM, Jan F. Chadima  wrote:
>> 
>> On Sep 15, 2011, at 11:03 AM, drago01 wrote:
>> 
>>> On Thu, Sep 15, 2011 at 10:16 AM, Jan F. Chadima  
>>> wrote:
 [...]
 . When watching the load of the virtual machine that starts with systemd 
 it is clear to me that the total CPU consumption is significantly greater 
 than in the case of upstart one.
>>> 
>>> That's the whole point of doing things in parallel ... the CPU is
>>> actually being *used* hence the higher CPU consumption. When you have
>>> work to do you want to throw all resources at it. To get back to your
>>> digger analogy ... when you employ 10 workers you'd rather want all of
>>> them to work not one doing all the work and the other 9 just sitting
>>> around.
>> 
>> better is 1 working and 9 sitting than 10 injured :)
> 
> Well why not fire the other 9 and save money then? ;)

so cut off the remanding cores from the CPU, save only one, good luck :D


> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Jan F. Chadima
jchad...@redhat.com



-- 
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?

[drago01]

On Thu, Sep 15, 2011 at 12:10 PM, Jan F. Chadima  wrote:
>
> On Sep 15, 2011, at 11:03 AM, drago01 wrote:
>
>> On Thu, Sep 15, 2011 at 10:16 AM, Jan F. Chadima  wrote:
>>> [...]
>>> . When watching the load of the virtual machine that starts with systemd it 
>>> is clear to me that the total CPU consumption is significantly greater than 
>>> in the case of upstart one.
>>
>> That's the whole point of doing things in parallel ... the CPU is
>> actually being *used* hence the higher CPU consumption. When you have
>> work to do you want to throw all resources at it. To get back to your
>> digger analogy ... when you employ 10 workers you'd rather want all of
>> them to work not one doing all the work and the other 9 just sitting
>> around.
>
> better is 1 working and 9 sitting than 10 injured :)

Well why not fire the other 9 and save money then? ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Mojolicious/f16] (2 commits) ...Upstream update 1.98

[Yanko Kaneti]

Summary of changes:

  d047ed8... Upstream update 1.92 (*)
  19353f8... Upstream update 1.98 (*)

(*) This commit already existed in another branch; no separate mail sent
--
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?

[drago01]

On Thu, Sep 15, 2011 at 12:45 PM, Steve Clark  wrote:
> On 09/15/2011 02:07 AM, drago01 wrote:
>
> On Thu, Sep 15, 2011 at 7:25 AM, Ralf Corsepius  wrote:
>
> On 09/14/2011 06:23 PM, drago01 wrote:
>
> On Wed, Sep 14, 2011 at 5:34 PM, Ralf Corsepius  wrote:
>
> 
>
> 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.
>
> Do they both start the same services? Unless you "tweaked" your fedora
> installation where we start a bunch of stuff that pretty much nobody
> would use in a typical desktop system that is to be expected.
>
> Is there a reason Fedora "starts a bunch of stuff that pretty much nobody
> would use in a typical desktop system" ?

Well one of the reasons is "every time someone tries to remove a
service ends up in a flamefest with no outcome" ;)
(ex. search the list archives for MTA, which is the most prominent one).
-- 
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?

[Steve Clark]

On 09/15/2011 02:07 AM, drago01 wrote:

On Thu, Sep 15, 2011 at 7:25 AM, Ralf Corsepius  wrote:

On 09/14/2011 06:23 PM, drago01 wrote:

On Wed, Sep 14, 2011 at 5:34 PM, Ralf Corsepiuswrote:





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.

Do they both start the same services? Unless you "tweaked" your fedora
installation where we start a bunch of stuff that pretty much nobody
would use in a typical desktop system that is to be expected.

Is there a reason Fedora "starts a bunch of stuff that pretty much nobody
would use in a typical desktop system" ?

Fedora is certainly not targeted at the server/enterprise target, being on the 
bleeding edge and all.


--
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: what if native systemd service is slower than old sysvinit script?

[Jan F. Chadima]

On Sep 15, 2011, at 11:03 AM, drago01 wrote:

> On Thu, Sep 15, 2011 at 10:16 AM, Jan F. Chadima  wrote:
>> [...]
>> . When watching the load of the virtual machine that starts with systemd it 
>> is clear to me that the total CPU consumption is significantly greater than 
>> in the case of upstart one.
> 
> That's the whole point of doing things in parallel ... the CPU is
> actually being *used* hence the higher CPU consumption. When you have
> work to do you want to throw all resources at it. To get back to your
> digger analogy ... when you employ 10 workers you'd rather want all of
> them to work not one doing all the work and the other 9 just sitting
> around.

better is 1 working and 9 sitting than 10 injured :)


> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Jan F. Chadima
jchad...@redhat.com



-- 
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?

[drago01]

On Thu, Sep 15, 2011 at 10:16 AM, Jan F. Chadima  wrote:
> [...]
>. When watching the load of the virtual machine that starts with systemd it is 
>clear to me that the total CPU consumption is significantly greater than in 
>the case of upstart one.

That's the whole point of doing things in parallel ... the CPU is
actually being *used* hence the higher CPU consumption. When you have
work to do you want to throw all resources at it. To get back to your
digger analogy ... when you employ 10 workers you'd rather want all of
them to work not one doing all the work and the other 9 just sitting
around.
-- 
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?

[Jan F. Chadima]

It amazes me how much energy people spend on it to save 3 seconds a day. Of 
course, if the computer being turned daily. In the case of a server time saving 
is even more amazing. My 4 years old daughter no longer believes the merman, 
but many technically educated IT specialists still believe in lossless 
parallelization.  There is always a resource, which must be accessed 
sequentially. Is it a case of hardware such as CPU core, or a software resource 
with a semaphore. Changing processes of this resource is always spent some 
extra time. The school teaches that when a workman digs a well in 10 days, then 
2 workers for 5 days and 240 workers per hour.  And it is the mistake sytemd 
authors. When watching the load of the virtual machine that starts with systemd 
it is clear to me that the total CPU consumption is significantly greater than 
in the case of upstart one. And so much power to lose synchronization and the 
result is yet uncertain. I can only say: if I only have 3 free secon
 ds a day, I will watch with pleasure as my service accrues sequentially.


Jan F. Chadima
jchad...@redhat.com



-- 
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?

[Jóhann B. Guðmundsson]

On 09/15/2011 05:25 AM, Ralf Corsepius wrote:
>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.

Could you run systemd-analyze plot > bootup.svg and post it somewhere 
online

Thanks
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?

[Michał Piotrowski]

2011/9/14 Jef Spaleta :
>
>
> 2011/9/14 Michał Piotrowski 
>>
>> 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.

It seems to me that the database settings or database content has
nothing to do with my test results. Yesterday I removed all databases
(it's only development system) and I did the whole setup again.
Results are the same. So I came to the conclusion that it must be
relevant to some other factor. Thanks for sending your test results.
Later I'll try to work out this problem.

>
> -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
> real    0m2.329s
> user    0m0.028s
> sys 0m0.046s
>
>
> time service postgresql stop
> real    0m1.281s
> user    0m0.035s
> sys 0m0.096s
>
> time service postgresql start
> real    0m2.242s
> user    0m0.031s
> sys 0m0.038s
>
> time service postgresql stop
> real    0m1.235s
> user    0m0.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
> real    0m1.141s
> user    0m0.019s
> sys 0m0.019s
>
>
> time service postgresql stop
> real    0m1.146s
> user    0m0.017s
> sys 0m0.017s
>
> time service postgresql start
> real    0m1.153s
> user    0m0.016s
> sys 0m0.019s
>
> time service postgresql stop
> real    0m1.144s
> user    0m0.026s
> sys 0m0.014s
>
>
>
>
> --
> 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]

2011/9/14 Tom Lane :
> =?ISO-8859-2?Q?Micha=B3_Piotrowski?=  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".

I did the same thing, just with PGSQL 9.0

>
> 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.

I also changed these parameters

>
> 3. As root, do
> date --rfc-3339=ns ; systemctl start postgresql.service ; date --rfc-3339=ns

with dropped cache

date --rfc-3339=ns ; systemctl start postgresql.service ; date --rfc-3339=ns
2011-09-15 08:44:40.348239703+02:00
2011-09-15 08:44:44.651134587+02:00

without dropped cache
date --rfc-3339=ns ; systemctl start postgresql.service ; date --rfc-3339=ns
2011-09-15 08:45:38.388010217+02:00
2011-09-15 08:45:42.633229665+02:00


>
> 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.
>

Ok, this is good news, because it seems that this behavior only occurs
on my system. Also Jef Spaleta can not repeat this behavior of
service.

> 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.

I tried to figureout what is happening with strace. I don't see any
significant difference between start with an old init script and
service file. I wonder just what's going on with "Resource temporarily
unavailable" - it seems to me that if I use service, it wait's a bit
longer (but I'm not able to measure time, so it can only be an
impression).

ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f1ef78cea90) = 3934
sendmsg(3, {msg_name(0)=NULL,
msg_iov(2)=[{"l\1\0\1$\0\0\0\1\0\0\0\240\0\0\0\1\1o\0\31\0\0\0/org/fre"...,
176}, {"\22\0\0\0postgresql.service\0\0\7\0\0\0repl"..., 36}],
msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 212
poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL,
msg_iov(1)=[{"l\2\1\1'\0\0\0\1\0\0\0\17\0\0\0\5\1u\0\1\0\0\0\10\1g\0\1o\0\0"...,
2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_CMSG_CLOEXEC) = 71
recvmsg(3, 0x7fffe59f6a10, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource
temporarily unavailable)
sendmsg(3, {msg_name(0)=NULL,
msg_iov(2)=[{"l\1\0\1\27\0\0\0\2\0\0\0\227\0\0\0\1\1o\0\31\0\0\0/org/fre"...,
168}, {"\22\0\0\0postgresql.service\0", 23}], msg_controllen=0,
msg_flags=0}, MSG_NOSIGNAL) = 191
poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL,
msg_iov(1)=[{"l\4\1\1+\0\0\0\2\0\0\0\203\0\0\0\1\1o\0\31\0\0\0/org/fre"...,
2048}], msg_controll