I just realized that I will not be able to attend the meeting today (for some reason I thought it was at 1, not at 2). Here are the notes that I had for things that could be discussed today. I hope someone else can do the cheering/dancing/leading. Chris are you going to be there ?
Matthias
Anyway, here are my notes:
test2 status
• what desktop features are in and testable ? ∘ animated backgrounds ∘ bluetooth printing, browsing, smsing ∘ pulseaudio ∘ codecbuddy ∘ policykit - not much there yet, need to check with david, intlclock, gnome-device-manager still missing ∘ lots of quirks for suspend/resume and keyboard handling ∘ new theme (partially) ∘ bigboard • which desktop features are not yet in ? ∘ new NM ∘ xulrunner
desktop spin status (from booting a spin built with yesterdays rawhide) • udev slow • tries to set up lvm - why ? • rpcbind/statd/idmapd - should be turned off • autofs too • do we want rhgb on the livecd ? • starting avahi fails - needs to be after NM ? • dhcdbd should go out with the new NM • avoid getty on vt1 ?
volunteers needed
• test2 feature testing and bug hunt • side-by-side comparison to ubuntu, opensuse, etc
wiki
• SIGs/Desktop vs Desktop is confusing to me, can we have just one ?
On Wed, 05.09.07 10:39, Matthias Clasen (mclasen@redhat.com) wrote:
??? pulseaudio
Uh oh. The meetings are usually pretty late here in Germany. Today it's too late for me to attend.
Sorry, Lennart
On Wed, 2007-09-05 at 17:01 +0200, Lennart Poettering wrote:
On Wed, 05.09.07 10:39, Matthias Clasen (mclasen@redhat.com) wrote:
??? pulseaudio
Uh oh. The meetings are usually pretty late here in Germany. Today it's too late for me to attend.
Thats fine. I didn't really want to talk much about PA, just pointed it out as one of the new, testable features in test2.
But the general problem of "meeting too late for Europe" should maybe be discussed. Maybe we can come up with an alternative time, or alternate between early/late or somesuch. Matej complained as well...
Matthias
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
• what desktop features are in and testable ?
Some more new, testworthy things that have come up after I sent out this mail:
- the vinaigre vnc client
- new compiz and -fusion (I think Kristian may send out a more detailed mail about how the packaging looks now, and what needs to be installed to get the most bling for the buck)
- new appearance capplet
On Wed, 2007-09-05 at 11:31 -0400, Matthias Clasen wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
• what desktop features are in and testable ?
Some more new, testworthy things that have come up after I sent out this mail:
- the vinaigre vnc client
vinagre. Same liquid, but the Spanish version of it :)
On Wed, 2007-09-05 at 16:43 +0100, Bastien Nocera wrote:
On Wed, 2007-09-05 at 11:31 -0400, Matthias Clasen wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
• what desktop features are in and testable ?
Some more new, testworthy things that have come up after I sent out this mail:
- the vinaigre vnc client
vinagre. Same liquid, but the Spanish version of it :)
Note that it might make sense to actually have it listed in comps if we want people to use it and know about it (hint, hint ;-)
Jeremy
On Wed, 2007-09-05 at 11:55 -0400, Jeremy Katz wrote:
On Wed, 2007-09-05 at 16:43 +0100, Bastien Nocera wrote:
On Wed, 2007-09-05 at 11:31 -0400, Matthias Clasen wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
• what desktop features are in and testable ?
Some more new, testworthy things that have come up after I sent out this mail:
- the vinaigre vnc client
vinagre. Same liquid, but the Spanish version of it :)
Note that it might make sense to actually have it listed in comps if we want people to use it and know about it (hint, hint ;-)
This is not quite clear to me. What is the current policy wrt to comps ? List everything ? Or only selected stuff ?
Le mercredi 05 septembre 2007 à 21:47 +0530, Rahul Sundaram a écrit :
Matthias Clasen wrote:
This is not quite clear to me. What is the current policy wrt to comps ? List everything ? Or only selected stuff ?
Selected stuff.
I'd say everything that can be used directly by humans. You don't have to make your entry mandatory or default-on
On Wed, 05.09.07 16:43, Bastien Nocera (bnocera@redhat.com) wrote:
On Wed, 2007-09-05 at 11:31 -0400, Matthias Clasen wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
??? what desktop features are in and testable ?
Some more new, testworthy things that have come up after I sent out this mail:
- the vinaigre vnc client
vinagre. Same liquid, but the Spanish version of it :)
I am quite sure that it is actually the Portuguese version, given that Jonh Wendell is Brazilian.
Lennart
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
I just realized that I will not be able to attend the meeting today (for some reason I thought it was at 1, not at 2). Here are the notes that I had for things that could be discussed today. I hope someone else can do the cheering/dancing/leading. Chris are you going to be there ?
Matthias
Anyway, here are my notes:
test2 status
• what desktop features are in and testable ? ∘ bluetooth printing, browsing, smsing
I've added docs on how it works, and how to test the new Bluetooth features: http://fedoraproject.org/wiki/Releases/FeatureBluetooth#head-5f18054be16b849...
I've not added the audio docs yet, as this is still in flux, and I need to see how it's going to integrate with Pulse, if at all.
Cheers
PS: Great UTF-8-ness btw :)
On Wed, 2007-09-05 at 18:10 +0100, Bastien Nocera wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
I just realized that I will not be able to attend the meeting today (for some reason I thought it was at 1, not at 2). Here are the notes that I had for things that could be discussed today. I hope someone else can do the cheering/dancing/leading. Chris are you going to be there ?
Matthias
Anyway, here are my notes:
test2 status
• what desktop features are in and testable ? ∘ bluetooth printing, browsing, smsing
I've added docs on how it works, and how to test the new Bluetooth features: http://fedoraproject.org/wiki/Releases/FeatureBluetooth#head-5f18054be16b849...
I've added most of the Bluetooth stuff to the default comps for F8 as well. Thanks Jeremy for mentioning it.
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
desktop spin status (from booting a spin built with yesterdays rawhide) • udev slow
I've noticed this too, but haven't gotten around to investigating what in our rules is slow.
• tries to set up lvm - why ?
rc.sysinit always tries to enable any LVM that's present. Unfortunately, it doesn't look like we can do a check with blkid for devices which are PVs and only do it if there are PVs present.
We're going to want this more-so in the future because we're going to be enabling available swaps[1] unless explicitly requested otherwise. This will help a lot of users who's hardware is a little less good to actually run the live image and not die a slow death of no memory being available
• rpcbind/statd/idmapd - should be turned off • autofs too
Should they just be off booting from the live image or after the install as well? Although rpcbind might be worth leaving around -- eventually, it'd be nice if the other rpc-based services could auto-start as needed. Then we could just start rpcbind and if you do an nfs mount and need locking, lockd would start. And so on. So activation for old crummy services.
The other approach would be to set up rpcbind to run from xinetd and run xinetd by default :)
• do we want rhgb on the livecd ?
There were a surprising number of requests for it.
• starting avahi fails - needs to be after NM ?
Yeah, not sure what's up with this...
• dhcdbd should go out with the new NM
*nod*
• avoid getty on vt1 ?
If this is wanted, someone should throw together the little bit of scripting needed to modify the inittab from the live initscript. Even just get me the bit of shell and I can put it in the initscript.
There was another small tweak that we were going to do in the initscript to one of the defaults and now I've forgotten what it was. Anyone else remember?
Jeremy
[1] Thought I had committed and pushed this last week, but apparently I forgot to push it, so it's not in yesterday's builds.
Jeremy Katz (katzj@redhat.com) said:
• avoid getty on vt1 ?
If this is wanted, someone should throw together the little bit of scripting needed to modify the inittab from the live initscript. Even just get me the bit of shell and I can put it in the initscript.
vt1, or vt1-6? Don't forget you'll need to signal init if you do this.
Bill
Jeremy Katz wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
desktop spin status (from booting a spin built with yesterdays rawhide) • udev slow
I've noticed this too, but haven't gotten around to investigating what in our rules is slow.
Hmm, I do not experience that... maybe some rules from another package?
Harald Hoyer wrote:
Jeremy Katz wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
desktop spin status (from booting a spin built with yesterdays rawhide) • udev slow
I've noticed this too, but haven't gotten around to investigating what in our rules is slow.
Hmm, I do not experience that... maybe some rules from another package?
I noticed that F7-livecd took about 3 minutes to fully boot on my system under qemu (with kqemu). And that ubuntu 7.04 took maybe 20 seconds longer than that. But that f8t1 took *15* minutes. Specifically, udev took 20 seconds (reliably +/-3s) on f7-livecd, but f8t1 udev took ~65seconds.
I also recall that f8t1 seemed equally bad on native hardware, though I didn't do as detailed a test.
This seems like a great time to harp on an idea I've been advocating on fedora-livecd-list for years now- Fully automated regression testing using qemu.
Think about it- every night, a rawhide livecd is built. One that has a simple (or complex) automated regression test added to it. I'm thinking a great start would be - gdm-autologin, firefox opening local release notes, and then a shell script which runs vmstat waiting for all io to settle, followed by a screenshot and a shutdown.
Basically what you would have would be this headless dedicated regression build server, posting the timing results of the test, and the screenshot every night.
Then you could immediately see when something checked into rawhide starts seriously impacting system performance (in a good, or more likely bad way).
The ways to add more complexity to the tests, and the automated verification of the tests, are endless and endlessly valuable IMHO.
<steps off soap box>
-dmc
P.S.- yes, I'll perhaps get around to it eventually, but at this rate with my todo list and other priorities, not for quite some time.
Douglas McClendon schrieb:
Harald Hoyer wrote:
Jeremy Katz wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
desktop spin status (from booting a spin built with yesterdays rawhide) • udev slow
I've noticed this too, but haven't gotten around to investigating what in our rules is slow.
Hmm, I do not experience that... maybe some rules from another package?
I noticed that F7-livecd took about 3 minutes to fully boot on my system under qemu (with kqemu). And that ubuntu 7.04 took maybe 20 seconds longer than that. But that f8t1 took *15* minutes. Specifically, udev took 20 seconds (reliably +/-3s) on f7-livecd, but f8t1 udev took ~65seconds.
ah... live-cd ... haven't tried that.. will have a look
Harald Hoyer schrieb:
Douglas McClendon schrieb:
Harald Hoyer wrote:
Jeremy Katz wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
desktop spin status (from booting a spin built with yesterdays rawhide) • udev slow
I've noticed this too, but haven't gotten around to investigating what in our rules is slow.
Hmm, I do not experience that... maybe some rules from another package?
I noticed that F7-livecd took about 3 minutes to fully boot on my system under qemu (with kqemu). And that ubuntu 7.04 took maybe 20 seconds longer than that. But that f8t1 took *15* minutes. Specifically, udev took 20 seconds (reliably +/-3s) on f7-livecd, but f8t1 udev took ~65seconds.
ah... live-cd ... haven't tried that.. will have a look
No problem here on a real system (not qemu/kqemu) with todays rawhide live cd. So either s.th. got fixed or it is a qemu/kqemu problem.
On 9/7/07, Douglas McClendon dmc.fedora@filteredperception.org wrote:
Think about it- every night, a rawhide livecd is built. One that has a simple (or complex) automated regression test added to it.
I don't think anyone has looked at boot time regression tests.
As for the firefox+screenshot testing - see: http://people.redhat.com/zcerza/dogtail/
But yeah I think everyone would love to see this - right now Fedora's testing is fairly minimal and improving that would greatly benefit the project.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Douglas McClendon wrote:
I noticed that F7-livecd took about 3 minutes to fully boot on my system under qemu (with kqemu). And that ubuntu 7.04 took maybe 20 seconds longer than that. But that f8t1 took *15* minutes. Specifically, udev took 20 seconds (reliably +/-3s) on f7-livecd, but f8t1 udev took ~65seconds.
I also recall that f8t1 seemed equally bad on native hardware, though I didn't do as detailed a test.
This seems like a great time to harp on an idea I've been advocating on fedora-livecd-list for years now- Fully automated regression testing using qemu.
One thing to remember is that rawhide kernels often have debugging features turned on that can slow things down compared to the release kernels. You'll want to make sure your regression tests take that into account.
- -Toshio
Toshio Kuratomi wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Douglas McClendon wrote:
I noticed that F7-livecd took about 3 minutes to fully boot on my system under qemu (with kqemu). And that ubuntu 7.04 took maybe 20 seconds longer than that. But that f8t1 took *15* minutes. Specifically, udev took 20 seconds (reliably +/-3s) on f7-livecd, but f8t1 udev took ~65seconds.
I also recall that f8t1 seemed equally bad on native hardware, though I didn't do as detailed a test.
This seems like a great time to harp on an idea I've been advocating on fedora-livecd-list for years now- Fully automated regression testing using qemu.
One thing to remember is that rawhide kernels often have debugging features turned on that can slow things down compared to the release kernels. You'll want to make sure your regression tests take that into account.
That's OK, as the main thing is the tests would tell you relative boot times. (i.e. today's rawhide is faster/slower than yesterdays).
But, to the horrible 15 minute performance I saw with f8t1 under qemu- does that fall into the issue you mentioned? I.e. are those debugging features turned on in f8t1? how about f8t2? What is the quickest way to determine if they are turned on or not?
Thanks,
-dmc
On Wed, 2007-09-05 at 16:14 -0400, Jeremy Katz wrote:
On Wed, 2007-09-05 at 10:39 -0400, Matthias Clasen wrote:
desktop spin status (from booting a spin built with yesterdays rawhide) • udev slow
I've noticed this too, but haven't gotten around to investigating what in our rules is slow.
• tries to set up lvm - why ?
rc.sysinit always tries to enable any LVM that's present. Unfortunately, it doesn't look like we can do a check with blkid for devices which are PVs and only do it if there are PVs present.
The right answer here is most likely to move all LVM (and md for that matter too) setup away from /etc/rc.sysinit and into udev rules. I think upstream md already has this (check the udev rules in the upstream tarball) and SUSE got the patch for devicemapper/lvm to do similar. You probably want these fixes too in mainline Fedora I think. Just another piece of the puzzle of moving Fedora into the dynamic event driven world. [1]
(This whole thing raises some other interesting questions with one being "do we want RAID auto-assembly?" and I think the answer there for Fedora Desktop is "yes" and maybe perahps "yes, but only for arrays created on this hostname [2]" for mainline Fedora.)
[1] : Don't mean to sound harsh but it is really a bug that we do this at init time only; for example it fails with hotplug. I have a nice eSATA enclosure with 5x500GB disks in RAID5 where hotplugging the array works just fine. It should show up on my GNOME desktop if I boot up a live CD on the system to which it is attached.
[2] : I think this is the default for mdadm
Should they just be off booting from the live image or after the install as well? Although rpcbind might be worth leaving around -- eventually, it'd be nice if the other rpc-based services could auto-start as needed. Then we could just start rpcbind and if you do an nfs mount and need locking, lockd would start. And so on. So activation for old crummy services.
The other approach would be to set up rpcbind to run from xinetd and run xinetd by default :)
My opinion is that we should just turn it off by default (both in the image and in the resulting install) and maybe also fix the UI tools to check that it's enabled. You may want to keep it on in mainline Fedora.
Cheers, David
Matthias Clasen (mclasen@redhat.com) said:
desktop spin status (from booting a spin built with yesterdays rawhide) • udev slow
Any tracing? It shouldn't be that much slower on live than normal; iirc, it's ~5 seconds (which is slow, but not AARGH slow.)
• tries to set up lvm - why ?
Jeremy answered this one.
• rpcbind/statd/idmapd - should be turned off
rpcbind you probably want (or, to have it started automatically if needed.)
• autofs too
Just nuke the package.
Bill
Matthias Clasen wrote:
• side-by-side comparison to ubuntu, opensuse, etc
Depending on how streamlined you want the installation to be, here is something to consider
http://en.revilinux.org/2007/09/ark-linux-h2o-20071.html
Single click installation. A single screen asks for language, keyboard and timezone settings and off you go. Two users created by default (root and normal) and both with passwords disabled and autologin is enabled by default for the normal user. You can set passwords post installation if necessary. They use a module that allows you to run administration tools without the root password. This seems like Policy Kit with permissive settings.
A potential enhancement would be to preselect a timezone and keyboard settings based on geoip but still allow the user to customize it if necessary.
Rahul
On 9/5/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Matthias Clasen wrote:
• side-by-side comparison to ubuntu, opensuse, etc
Depending on how streamlined you want the installation to be, here is something to consider
Yeah, that's pretty close to right.
I would allow people to type in their real name and autogenerate a unix username from that (like guest-account[1] does), but if they choose not to just pick some default.
Colin Walters wrote:
Yeah, that's pretty close to right.
I would allow people to type in their real name and autogenerate a unix username from that (like guest-account[1] does), but if they choose not to just pick some default.
Is this for Fedora 8? How are you planning on handling passwords? Sudo?
Rahul
Colin Walters wrote:
I would allow people to type in their real name and autogenerate a unix username from that (like guest-account[1] does), but if they choose not to just pick some default.
Guest account and the ideas surrounding letting users take pics of themselves via a cam reminded me of a few things
* Cheese - For taking pics of themselves via a cam
* Good photo management application - f-spot might be a good choice but pulls in mono
* Desktop search - beagle or tracker
* Video editing - pick one of
http://digital-filmmaking.blogspot.com/2007/08/video-editing-options-for-lin...
* SELinux guest user policy looks very useful if exposed nicely. http://danwalsh.livejournal.com/10461.html.
Rahul
Rahul Sundaram wrote:
Colin Walters wrote:
I would allow people to type in their real name and autogenerate a unix username from that (like guest-account[1] does), but if they choose not to just pick some default.
Guest account and the ideas surrounding letting users take pics of themselves via a cam reminded me of a few things
- Cheese - For taking pics of themselves via a cam
I have submitted a package review request at
https://bugzilla.redhat.com/show_bug.cgi?id=281891
Reviews welcome.
Rahul
desktop@lists.fedoraproject.org
-
Bastien Nocera -
Bill Nottingham -
Colin Walters -
David Zeuthen -
Douglas McClendon -
Harald Hoyer -
Jeremy Katz -
Lennart Poettering -
Matthias Clasen -
Nicolas Mailhot -
Rahul Sundaram -
Toshio Kuratomi