[00:15] <ccheney> NCommander: ok
[00:36] <psusi> how do you like that... mke2fs now defaults to using the 256 byte inodes... I really need to fix e2defrag to understand those...
[00:41] <quentusrex> Anyone know of a 'very' stable network driver?
[00:41] <quentusrex> forcedeth and r8169 so far have proved unstable for me.
[00:51] <j^> http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx lists Canonical Limited as licensee of h264 anyone around who knows more about that?
[00:52] <Keybuk> quentusrex: tg3 works for me
[00:53] <Keybuk> quentusrex: the e1000 family are probably the best
[01:00] <psusi> wow... starting with a clean filesystem then restoring a dump of my stable karmic root fs, e2fsck reports only 4.2% fragmentation.... after defragmentation, dumping the fs went from 2:14 to 1:24, taring the fs went from 5:10 to 4:09
[01:00] <quentusrex> Keybuk, any idea who or how to debug an unstable driver issue?
[01:00] <Keybuk> no idea
[01:01]  * psusi really needs to get defrag working on ext4
[01:02] <TheMuso> psusi: I thought file fragmentation was not such an issue on ext filesystems.
[01:02] <psusi> TheMuso, uh-huh....
[01:03] <psusi> strange thing is that e2fsck reports only 0.2% fragmentation on the original karmic filesystem... dumping and restoring to a clean fs should give LOWER fragmentation...
[01:05] <Keybuk> because it's talking about inode fragmentation
[01:05] <Keybuk> not data fragmentation
[01:06] <psusi> what do you mean?
[01:06] <Keybuk> do you know the difference between the two?
[01:07] <psusi> if a file's data is in 2 non contiguous chunks, fsck counts it as fragmented.... it used to count it as fragmented if it was in two chunks because its indrect block was in the middle, which I would not consider fragmented... but it seems they have fixed that
[01:07] <Keybuk> sooooorta
[01:08] <psusi> since it now reports 0.0% fragmentation after an e2defrag run, but it used to say otherwise since the indirect blocks were interleaved with the data
[01:11] <psusi> so what do you mean by inode fragmentation?
[01:14] <Keybuk> look it up ;)
[01:14] <Keybuk> bed for me
[01:17]  * psusi has fun digging into debugfs
[02:08] <ccheney> TheMuso: fragmentation can be a huge issue especially if you do any torrent transfers
[02:09] <ccheney> TheMuso: i've had isos so fragmented i couldn't burn them without constantly running the buffer out
[02:10] <TheMuso> ccheney: ah ok.
[02:10] <jdong> yep, agreed with ccheney
[02:10] <jdong> if you have extremely slow growing files like torrents mixed with other ordinary write traffic, ext*fs fails at preventing fragmentation
[02:10] <jdong> when I used ext3/4, after a torrent is done I'd cp it once before playing.
[02:11] <jdong> on my 5400rpm laptop hard drive at times the fragmentation was so bad I couldn't play a movie file in realtime
[02:11] <psusi> looks like the lucid beta 1 iso I downloaded and am still seeing diwth transmission only has 16 fragments.... not bad at all
[02:12] <jdong> ext4 helped a lot with delayed allocation if you've got no other IO traffic at the time.
[02:12] <jdong> but if you mix in other write traffic or out-of-memory pressure, you're back to square one.
[02:12] <jdong> in my experience, XFS has been the best filesystem at preventing fragmentation in torrent-like workloads
[02:12] <jdong> though it has a wealth of other caveats, of course.
[02:14] <lifeless> jdong: there is an API you can use to tell the os the file size
[02:14] <psusi> weird.... if I restore a dump to a clean fs it shows some fragmentation under e2fsck... copying the original fs the dump was taken from to the same clean fs with cp -a and fsck shows 0.0% fragmentation
[02:14] <lifeless> which torrent should ue.
[02:14] <psusi> of course the cp takes about twice as long as restoring the dump...
[02:15] <jdong> lifeless: yeah, nowadays torrent clients are using it more; wasn't the case 2-ish ubuntu releases ago
[02:21] <psusi> I just wish restore was a true inverse of dump
[02:32] <lamont> I remember when pluggable devices automatically mounted for me...
[02:32] <lamont> what did I break when I upgraded to lucid?
[02:33] <lamont> this time, at least I have a ck session
[02:49] <lamont> start: Unknown job: squid
[02:49] <lamont> did we mean to kill squid?
[02:51] <lifeless> lamont: try squid2/squid3 perhaps?
[02:52] <lamont> start: Unknown job: squid2
[02:52] <lamont> 2.7 is installed, and I'd kind of expect apt-get install squid to actually succeed in launching the process
[02:53] <ScottK> Interesting theory.
[02:53] <lamont> https://bugs.edge.launchpad.net/ubuntu/+source/squid/+bug/523621 seems relevant to my interests
[02:54] <ScottK> At least we've established no one cares.
[02:54] <lifeless> lamont: is there an old style script ?
[02:55] <lamont> dpkg --contents /var/cache/apt/archives/squid_2.7.STABLE7-1ubuntu9_amd64.deb | grep init.d
[02:55] <lamont> drwxr-xr-x root/root         0 2010-03-22 08:45 ./etc/init.d/
[02:55] <lamont> lrwxrwxrwx root/root         0 2010-03-22 08:45 ./etc/init.d/squid -> /lib/init/upstart-job
[02:55] <lamont> lrwxrwxrwx 1 root root 21 2010-03-22 20:50 /etc/init.d/squid -> /lib/init/upstart-job
[02:55] <lamont> the package is delivering what doesn't work
[02:57] <ScottK> Working is highly overrated.  That's well accepted these days.  The important thing is it uses Upstart.
[02:57] <lamont> yeah - reopened bug 523621
[02:58] <lamont> and stuffed it back to confirmed
[02:58] <lamont> -console output
[02:58] <lamont>  expect fork
[02:58] <lamont> -respawn
[02:58] <lamont> I wonder if that was important
[03:00] <stgraber> lamont: are you starting it in a chroot or on a regular system ?
[03:00] <lamont> plain old regular out in the real root box
[03:00] <lamont> was working before upgrading to 1ubuntu9 today
[03:00] <stgraber> lamont: the initial bug report was about running it in a chroot which doesn't work with upstart unless using the workaround Chuck posted in the bug report
[03:01] <stgraber> so that explains why that bug report was marked Won't fix but the upstart job being broken still remains a bug to be fixed :)
[03:01] <lamont> ah, true.  it's a poorly titled bug
[03:01] <lamont> meh.  filing a new bug then
[03:02] <stgraber> yeah, you need to read the first line of the bug report ... title should have been updated accordingly
[03:02] <ScottK> It's not clear to me that anyone verified zul's fix works
[03:02] <ScottK> So it may well have been prematurely wontfixed since lamont had the same problem outside a chroot.
[03:03] <stgraber> ScottK: indeed, though it's true that "start squid" shouldn't work in a chroot and zul's procedure be followed to have squid installed in the chroot (though it'll have to be manually started if one wants it to actually run in the chroot)
[03:04] <lamont> and the prior version worked just fine, -1ubuntu9 regressed.  bug 544760 - go ahead and install it...
[03:04] <lamont> just try
[03:07]  * stgraber looks
[03:07] <lamont> fwiw, having a mixture of "upstart bitching about using init.d" and "init.d only not yet upstart" jobs on the system is going to be a royal annoyance
[03:09] <stgraber> found the issue
[03:09] <stgraber> now trying to fix it ;)
[03:09] <lamont> and now to file my fun "nah, I didn't need to actually work on monday" bugset
[03:10] <stgraber> was that thing even tested ? the upstart job is simply invalid ...
[03:10] <stgraber> lamont: http://pastebin.com/ZCWNRwkw
[03:10] <stgraber> I'll upload a fixed package in a few min, would be great if you could confirm the fix
[03:12] <stgraber> ok, I have -0ubuntu10 ready to upload with the fix
[03:13] <fcuk112> ;/wc
[03:19] <stgraber> lamont: ?
[03:22] <lamont> stgraber: sure
[03:22] <lamont> sorry for the delay there
[03:22] <lamont> was filing bugs
[03:22] <lamont> 544762 544763 544764
[03:22] <lamont> 3 _IN_A_ROW_!
[03:23] <lamont> stgraber: where u got the fix?
[03:23] <lamont> bouncing back and forth a bit, so kinda laggy
[03:24] <stgraber> lamont: I wrote a few upstart job for LTSP recently, simply looked at the script and saw that something was a bit off ...
[03:26] <lamont> heh
[03:29] <lamont> stgraber: any clues on my "why don't removable media drives mount anymore"?  or even what package to throw that against?
[03:31] <stgraber> lamont: I'm guessing it's somewhere between udev => udisks => gvfs
[03:31] <persia> lamont: Start with nautilus, although the issue may live in udisks or udev
[03:31]  * persia is certain it's not gvfs
[03:32] <lamont> ta
[03:36] <stgraber> lamont: btw, as you're around :) I see in the livefs build logs that the LTSP squashfs is building correctly, any idea of when it'll start being included in Edubuntu's DVD .iso ?
[03:37] <lamont> when the bugtask gets done by the cdimage builder
[03:37] <lamont> added the task to the bug earlier today when I was chatting with cjwatson about it
[03:38] <stgraber> oh, looks like I have some backlog in my LP mailbox ;)
[03:39] <lamont> https://bugs.edge.launchpad.net/ubuntu-cdimage/+bug/531546 <-- stgraber
[03:39] <stgraber> thanks
[03:40]  * lamont prepares and uploads 1.108
[03:56] <ccheney> any inkscape experts around to look at bug 529625 ?
[03:56] <ccheney> it appears to be a bug in inkscape causing openclipart to not be compilable anymore
[03:56] <ccheney> it spews seemingly forever, I killed the build after a 10GB logfile
[03:57] <ccheney> the previous build log was apparently 500KB
[04:22] <git__> hi
[04:22] <git__> has anyone created a file versioning plugin for nautilus?
[04:22] <git__> i don't want to duplicate effort by writing my own
[04:26] <lamont> sigh.  so what updated today to break my ability to log into my bank
[04:26] <lamont> gonna bet on "java" in some form
[04:38] <persia> lamont: That would probably be openjdk then, as that was a recent rebuild.
[04:41] <lamont> it's also possible that it's apparmor being mean to it,  since I have it somewhat locked down
[04:43]  * lamont sleeps
[05:49] <xnox> Is "package (<= 2.20.1+), package (>= 2.20.1~)" good way to depend on a particular upstream release version?
[05:50] <xnox> Such that 2.20.2 nor 2.20.0 won't work
[06:21] <persia> xnox: It ought work, yes.
[06:21] <xnox> persia, thanks =) i've been testing with --compare-versions but wasn't 100% convinced
[06:54] <pitti> Good morning
[06:55] <StevenK> pitti: Morning
[06:57] <micahg> pitti: does adding apps to the proper category in software center require an FFe or UiFe?
[06:59] <pitti> micahg: fixing a wrong category? neither, I think
[06:59] <micahg> pitti: how about adding a missing category
[06:59] <pitti> same case
[06:59] <micahg> pitti: ok, thanks
[07:04] <pitti> zul: I uploaded a new nut which unbreaks the udevadm trigger, as discussed in bug 535152
[07:18] <dholbach> good morning
[07:19] <StevenK> dholbach: Hi! I got an e-mail about my membership in u-m-s expiring, can you fix?
[07:19] <dholbach> hey StevenK
[07:19] <dholbach> StevenK: no, but I'll add you to ubuntu-sponsors :)
[07:20] <dholbach> StevenK: done
[07:21] <StevenK> dholbach: \o/ Thanks!
[07:22] <dholbach> anytime :)
[07:24] <xnox> dholbach, good morning =) do you know how many students slots was ubuntu allocated in gsoc - tentatively ? =)))))
[07:25] <dholbach> xnox: no
[07:25] <dholbach> I don't - sorry
[07:26] <xnox> =( kk thanks
[07:47] <cjwatson> oh, smeg, uploaded d-i last night and forgot to change the seeds
[10:03] <glatzor> cjwatson, hello, could you please have a look at debian bug #575070 of debconf. the new exclusive lock on file databases breaks debconf support in aptdaemon/software-center
[10:05] <cjwatson> glatzor: why aren't you using a separate database?
[10:05] <lifeless> bug 522225
[10:06] <cjwatson> glatzor: oh, I see
[10:07] <glatzor> cjwatson, DEBCONF_DB_REPLACE doesn't work :(
[10:07] <glatzor> cjwatson, and the non-root deconf-communicate even doesn't want to write to the database at all
[10:07] <cjwatson> yeah, that's nasty
[10:14] <cjwatson> glatzor: fixed in svn
[10:14] <glatzor> cjwatson, that was fast :) thanks a lot
[10:14]  * mvo hugs cjwatson 
[10:19]  * cjwatson wonders why that bug doesn't show up on debconf's bug list
[10:22] <cjwatson> glatzor: would appreciate it if you could try debconf 1.5.30 once it's available (uploaded)
[10:22] <glatzor> cjwatson, I already tested the svn version and it seems to work
[10:22] <glatzor> cjwatson, thanks a lot once again
[10:28] <Laney> cjwatson: I removed that mailing list from the ~mono team. Could you set ~ubuntu-cli-mono-dev to have ubuntu-mono@l.u.c as its contact address now, please?
[10:28] <Laney> (well, ajmitch did it actually)
[10:28] <Laney> I'll create a script to subscribe to all the packages soon
[10:30]  * jelmer cheers on james_w
[10:30] <jelmer> james_w: thanks for syncing cabal
[10:31] <Laney> http://orangesquash.org.uk/~laney/haskell-installability/i386.png
[10:31] <Laney> lookin gooooooooooood
[10:32] <chrisccoulson> Laney - that makes my eyes hurt ;)
[10:33] <Laney> heh, I just look at it zoomed out
[10:34] <dholbach> mvo: would it make sense to add archive.canonical.com and ppa.launchpad.net to /etc/squid-deb-proxy/mirror-dstdomain.acl?
[10:35] <dholbach> mvo: if squid-deb-proxy-client is installed, will it fall back to "regular http" if the proxy can't deliver?
[10:37] <cjwatson> Laney: LP still won't let me
[10:37]  * cjwatson asks #launchpad
[10:42] <Laney> cheers
[10:43]  * Laney rips off edit_acl.py
[10:55] <mvo> dholbach: archive.c.c I think makes sense, not sure about ppa
[11:06] <dholbach> mvo: what about the other question? :)
[11:06] <dholbach> mvo: will apt fallback to regular http if the proxy doesn't do "ppa.launchpad.net" for example?
[11:09] <davmor2> pitti: what would stop my camera showing up at all?  Is is a dbus thing I want to file a bug but I'm not sure against what.
[11:13] <davmor2> pitti: infact scrap that, things just got weirder my camera is showing up as a media player in RB rather than as a camera
[11:27] <tkamppeter> pitti, hi
[11:30] <znh> Hello. Are there any plans for releasing Firefox 3.6? It fixes a serious remote exploit bug.. My 9.10 only offers 3.5.8
[11:39] <pitti> davmor2: can you please do "ubuntu-bug storage" with the camera? that'll collect all the necessary info for me
[11:39] <pitti> hi tkamppeter
[11:40] <davmor2> pitti: np's thanks
[11:54] <lool> mvo: Heya; when creating a pbuilder env today, I got: /usr/lib/apt/methods/http: symbol lookup error: /usr/lib/apt/methods/http: undefined symbol: _Z14maybe_add_authR3URISs
[11:54] <lool> mvo: I'm quite surprized that /usr/lib/apt/methods/http breaks -- it's from the apt package and should move with the rest of the APT ABI?!
[11:55] <tkamppeter> pitti, it is about HPLIP FTBFS, our buildds does not identify itself as a Ubuntu box with lsb_release and so a Ubuntu-only patch does not work.
[11:55] <pitti> tkamppeter: they should
[11:55] <pitti> tkamppeter: I have many packages which rely on that
[11:56] <pitti> tkamppeter: did you add an lsb-release build dependency?
[11:59] <davmor2> pitti: bug 544994, I've assigned it to you and added a snapshot of it showing up in rb and not nautilus.
[11:59] <tkamppeter> pitti, no, I did not, I simply assumed that it is standard.
[12:00] <Keybuk> 15 conflicts encountered.
[12:00] <Keybuk> zsh: exit 1     bzr merge lp:plymouth
[12:00] <Keybuk> *cry*
[12:00] <pitti> davmor2: thanks
[12:04] <lool> mvo: Apparently specific to cowbuilder, worked with pbuilder so I've used that
[12:04] <geser> pitti: is apport tested with the new 1.0 LP API? as the beta API is EOL in April 2011. A quick grep shows that apport/crashdb_impl/launchpad.py still uses "transitionTo..."
[12:05] <pitti> geser: oh, did that change?
[12:05] <pitti> geser: I'm usually testing against staging, but unfortunately +storeblob is terminally broken on staging, so the test suite doesn't work any more
[12:06] <geser> pitti: the beta API is still available but only till April 2011 (EOL of karmic), the 1.0 API is supposed to stay till EOL of lucid (April 2015) [see https://edge.launchpad.net/+apidoc/]
[12:09] <pitti> geser: would you mind creating/assigning a bug to me about it? (I've been knee-deep in gdm/gsd keyboard code for 4 hours now, and want to finish this first)
[12:09] <geser> pitti: the main difference between the "beta" and "1.0" API is that the removal of mutator methods (for e.g. status, importance, assignee)
[12:09] <geser> pitti: sure
[12:09] <pitti> geser: danke
[12:17] <mvo> lool: very odd indeed
[12:17] <mvo> lool: reproducable?
[12:23] <lool> mvo: No, but I upgraded my system in the meantime
[12:23] <lool> I had already updated this morning though
[12:23] <lool> This is really werid
[12:23] <lool> mvo: I don't know what happened the first ime
[12:24] <lool> sudo cowbuilder --create --distribution lucid was how I got it
[12:24] <Keybuk> note-to-self ... teach slangasek about "sending patches upstream" :p
[12:29] <matumba> davmor2, just confirmed bug 544994
[12:32] <pabs3> where would I complain about unsolicited email from Canonical?
[12:35] <highvoltage> pabs3: would that be an email to test landscape perhaps?
[12:35] <pabs3> yes
[12:43] <cjwatson> pabs3: apparently this was only meant to have been sent to people who were current candidates for jobs at Canonical, but was mistakenly sent to rather more people than that; the Landscape people are looking into it
[12:43] <cjwatson> pabs3: (it has nothing to do with me ...)
[12:44] <directhex> pabs3, yours is the second complaint i've seen
[12:44] <libv> why would this interest even current candidates?
[12:44]  * pabs3 agrees with libv
[12:44] <highvoltage> 4th I've seen, but I just pasted them all what cjwatson said :)
[12:45] <elmo> it wasn't meant to be sent to current candidates
[12:45] <highvoltage> (mistakes happen)
[12:45] <libv> i also wasted time on this, not knowing what it was.
[12:45] <davmor2> matumba: Thanks :)
[12:46] <pabs3> cjwatson: thanks for the info, I'll refrain from mailing abuse@c.o and mark
[12:50] <cjwatson> current candidates> oh, ok
[12:52] <cjwatson> highvoltage: I've accepted the invitation for developer-membership-board to join edubuntu-dev; can you make it an admin?
[12:54] <blackxored> Hello guys, I've received an invitation for Landscape through mail, what's the meaning of it, Pici told me it was a mistake of some sort, can you enlighten me with this?
[12:54] <highvoltage> cjwatson: done
[12:54] <cjwatson> highvoltage: thanks
[12:55] <directhex> blackxored, <cjwatson> apparently this was only meant to have been sent to people who were current candidates for jobs at Canonical, but was mistakenly sent to rather more people than that; the Landscape people are looking into it
[12:55] <cjwatson> I was wrong about "current candidates", I'm told, but I don't have further details
[12:55] <blackxored> directhex, thanks
[12:56] <ogra> Riddell, can you let u-boot-omap out of binary NEW ?
[12:56] <Keybuk> silly xorg-edgers PPA
[12:58] <highvoltage> Keybuk: do you perhaps happen to know how to dry-run plymouth to test a theme?
[12:58] <Keybuk> sure
[12:58] <Keybuk> plymouthd ; plymouth --show-splash
[12:58] <Keybuk> :D
[12:58] <Riddell> ogra: accepted!
[12:59]  * ogra hugs Riddell 
[12:59] <ogra> just in time for mobile meeting :)
[13:00] <Keybuk> highvoltage: try it in X ... you may be surprised
[13:02] <highvoltage> Keybuk: ok :)
[13:04] <highvoltage> Keybuk: nice, thanks!
[13:06] <Keybuk> plymouth quit to get rid of it, obviosuly
[13:07] <Keybuk> you have two windows of different sizes so you can make sure your theme works with multi-head
[13:09] <sivang> hi all, I am trying to registera new blueprint
[13:09] <highvoltage> Keybuk: ah, clever!
[13:09] <sivang> choosing hte Ubuntu project says it is too wide and I Have to narrow my search
[13:10] <sivang> what is the correct project name for hte operating system project?
[13:10] <tkamppeter> pitti, thanks, new HPLIP is uploaded and did not give any FTBFS.
[13:11] <sivang> anybody knows if davd ben simon lurks around here ?
[13:11] <sivang> *david
[13:21] <cjwatson> stgraber: where does the LTSP squashfs need to go on the Edubuntu DVD?
[13:22] <nigelb> pitti: are you aware that python throws up a small error while apport attaches the hardware information (only seen on cli)?
[13:24] <mrand> I asked in upstart and they recommended I move here.... Is  $LANG  an acceptable (and expected to be future supported) way to support locales in upstart?  If not, could someone recommend something else?  This is in reference to this potential patch for MythTV that is attached to https://bugs.launchpad.net/bugs/541042
[13:24] <stgraber> cjwatson: ltsp/i386.img would be great
[13:25] <stgraber> highvoltage: ^ just so you know where it'll be ;)
[13:25] <highvoltage> stgraber: ok thanks
[13:26] <cjwatson> stgraber: that's the path from the root of the image?  how about amd64 images?
[13:26] <cjwatson> stgraber: is it necessary to put the architecture name in the image filename?
[13:31] <highvoltage> cjwatson: for now we're going to stick with only i386 images for the live infrastructure, if someone needs amd64 they'll have to install
[13:31] <cjwatson> so I should do this only for the i386 Edubuntu DVD image?
[13:32] <highvoltage> cjwatson: the i386 chroot will work on the amd64 disc (or at least, there's no reason why it shouldn't), so we'd like it on the amd64 discs as well
[13:32] <highvoltage> right stgraber?
[13:32] <cjwatson> hmm.  cross-architecture stuff might be tricky.
[13:32] <cjwatson> I'll see what I can do
[13:32] <highvoltage> cjwatson: many people use amd64 servers with i386 ltsp chroots, it's a common use case.
[13:33] <highvoltage> cjwatson: ah you meant from a built perspective? sorry I think I'm with you now.
[13:33] <highvoltage> (s/built/build/)
[13:33] <cjwatson> that's what I mean, yes
[13:39] <stgraber> cjwatson: it's the i386.img for both amd64 and i386, so path is the same on both
[13:40] <stgraber> looks like highvoltage was a lot faster than me on that one ;)
[13:43] <highvoltage> stgraber: there shouldn't be any build issues right? you'd just have to pass --arch for the debootstrap on the amd64 build host?
[13:43] <cjwatson> nah, will just fetch the i386 build for the amd64 CD build too
[13:44] <cjwatson> no point building it twice if it's just the same
[13:45] <highvoltage> that sounds good.
[13:46] <stgraber> highvoltage: sure we could build it twice but we'll save quite a few mins of build time if we don't
[13:56]  * Keybuk crosses his fingers and does the "please don't crash my X server" dance
[14:01] <Keybuk> COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
[14:01] <Keybuk> Xorg       1027 root    5u   CHR    4,7      0t0 1302 /dev/tty7
[14:01] <Keybuk> lt-plymou 18140 root    0u   CHR    4,7      0t0 1302 /dev/tty7
[14:01] <Keybuk> lt-plymou 18140 root    1u   CHR    4,7      0t0 1302 /dev/tty7
[14:01] <Keybuk> lt-plymou 18140 root    2u   CHR    4,7      0t0 1302 /dev/tty7
[14:01] <Keybuk> hmm
[14:01] <Keybuk> I wonder if there's a magic lsof flag to tell me which of those is the process group leader for the tty
[14:03] <psusi> you mean between 1027 and 18140?  ps should tell you no?
[14:08] <mrand> Keybuk: ps -f lists parent PID
[14:09] <Keybuk> no, that tells you their pgid ;)
[14:09] <Keybuk> I want to know which one is controlling that terminal
[14:12] <doko_> smoser, any feedback on 542395?
[14:20] <smoser> doko_, i will test right now. i'm at a hotel with 40k download cap
[14:20] <smoser> spent last night downloading
[14:20] <smoser> :)
[14:21] <doko_> smoser: thanks, no haste!
[14:25] <smoser> doko_, fixed. thank you.
[14:26] <doko_> smoser: ok, closing
[14:26] <smoser> already did.
[14:30] <cjwatson> stgraber,highvoltage: er, yeah, so ignore the Edubuntu DVD build I just did please, it turns out it helps to use the correct squashfs
[14:30] <cjwatson> rebuilding ...
[14:31] <highvoltage> ok
[14:43] <rafiyr> Does the 10.04 installer account for ssd block sizes when partitioning and setting up file systems?
[14:43] <highvoltage> Keybuk: # #2c001e --> 0.16, 0.00, 0.12 <- how does that conversion work!?
[14:46] <Keybuk> highvoltage: ask tseliot ;-)
[14:46] <highvoltage> Keybuk: ok :)
[14:46] <Keybuk> though it's roughly right isn't it?
[14:47] <highvoltage> I'm not sure what 0.16 means. afaik 2c = 44.
[14:47] <Keybuk> 0.16 means 0.16
[14:47] <Keybuk> 16%
[14:47] <Keybuk> etc.
[14:47] <highvoltage> ah! got it
[14:48] <tseliot> highvoltage: I'm pretty sure I put this bit of information in the code but anyway, you need the rgb values
[14:49] <Keybuk> tseliot: though, 2c isn't 0.16 ;-)
[14:49] <tseliot> highvoltage: and then you'll have to divide them by 256
[14:49] <highvoltage> tseliot: heh, it seems mentioned everywhere in the theme except where I was working on atm (the background colours), I'll add it there for the edubuntu theme just in case someone wonders again
[14:49] <tseliot> example: #ffffff => RGB 255 255 255 => 1 1 1
[14:50] <tseliot> :-)
[14:51] <Riddell> apw: linux-meta-qcm-msm for main or universe?
[14:52] <tseliot> Riddell: news on the kubuntu bootsplash theme?
[14:53] <pitti> kirkland: http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
[14:53] <pitti> kirkland: I caught up! :-)
[14:53] <Riddell> tseliot: we have some designs, nothing final yet.  maybe it's worth making the package now with a filler logo to get the technical side sorted?
[14:54] <tseliot> Riddell: it's bug ##507238
[14:54] <tseliot> bug #507238
[14:55] <tseliot> Keybuk: I won't upload my smooth transition patch for kdm (which I need to clean up anyway) until you upload your fix for plymouth so that quit and deactivate work correctly when X fails
[14:55] <Riddell> bryceh: do we want wacom-tools back in the archive?  removal log says "renamed to xf86-input-wacom"
[14:57] <cjwatson> rafiyr: yes, though it's a first attempt at doing so and it may be wrong
[14:58] <Keybuk> tseliot: that should be today
[14:58] <Keybuk> I have it merged in my working tree
[14:58] <Keybuk> and I'm just fixing your plugin ;-)
[14:58] <rafiyr> cjwatson: thanks.
[14:59] <tseliot> Keybuk: nice. Do you mean the 16 colours renderer or my theme?
[14:59] <Keybuk> tseliot: your theme
[14:59] <Keybuk> adding Window.GetX() + to various bits where you center them
[14:59] <Keybuk> to be fair, Charlie only realised that this was needed yesterday
[15:00] <cjwatson> rafiyr: are you having problems with it?
[15:00] <Keybuk> but damn you for being insufficiently prescient :p
[15:00] <tseliot> Keybuk: hehe. Why is that necessary? In case of multiple heads?
[15:00] <Keybuk> tseliot: yup!
[15:00] <rafiyr> cjwatson: not yet.  Just planning for a new machine, wanted to know if I should prepartition or let the installer have a go at it.
[15:01] <Keybuk> multiple heads that are hardware offset
[15:01] <Keybuk> ie. one overlapping the other
[15:01] <Keybuk> plymouth gives you one big screen with two windows then
[15:01] <Keybuk> apparently
[15:01] <cjwatson> rafiyr: it should basically work it out - if nothing else, if it can't figure out anything better, it tends to align things to 1MiB boundaries now
[15:01] <cjwatson> which is better for most SSDs, slightly less friendly to 1980s-era Winchester hard disks, and makes little difference on anything else :-)
[15:02] <rafiyr> cjwatson: Good to know.  mostly thinking about performance.
[15:02] <rafiyr> cjwatson: ya wouldn't be so good to give the first 1MB to the partition table and boot block on my 5MB drive.
[15:03] <tseliot> Keybuk: BTW the version of plymouth I've been working with didn't have getters for coordinates yet, so no GetX(), etc. That would allow me to clean up my code a bit
[15:03] <rafiyr> cjwatson:  Though I mostly just keep the 14" platters hanging on the wall instead of trying to run bloated systems like linux off them.
[15:04] <Keybuk> tseliot: is all pushed if you want to play
[15:04] <Keybuk> plymouthd;plymouth --show-splash works just fine in X now
[15:04] <Keybuk> so you can send messages, get keys, etc.
[15:04] <cjwatson> rafiyr: was more thinking about the fact that disks that really had 63-sector cylinders tended to like partitions to be aligned on them
[15:04] <Keybuk> and see the different effect on the two "heads"
[15:05] <cjwatson> rafiyr: which is why most people's /dev/sda1 is 32.5KiB from the start of the disk
[15:05] <tseliot> Keybuk: very nice. The only problem with the X renderer, from what I remember, was that hiding the splash would freeze X as plymouth seemed to mess with drm
[15:06] <rafiyr> cjwatson: fair point.
[15:06] <Keybuk> tseliot: I fixed that :p
[15:06] <Keybuk> (current lucid has the fix)
[15:07] <tseliot> Keybuk: fantastic. We should add your photo to the Ubuntu logo in the bootsplash :-)
[15:08] <tseliot> (but then you would have to render it in 16 colours :-P )
[15:09] <Keybuk> haha, why my photo?
[15:09] <tseliot> because without you plymouth in Lucid would still be in a rather sorry state ;)
[15:10] <Keybuk> as long as I get the credit, and someone else gets the blame :p
[15:10] <tseliot> let's rename it as it Plybuk or PlyScott :-P
[15:11] <matumba> a bit OT: how about not naming the purple color PLY_TERMINAL_COLOR_BLACK? :P
[15:11] <kusum> cjwatson: Hello SIr
[15:12] <Keybuk> matumba: because it's black
[15:12] <Keybuk> matumba: we don't invent a new terminal colour called PURPLE and use that
[15:12] <Keybuk> matumba: we reprogram the VGA to make the existing black colour more purple ;-0
[15:12] <matumba> Keybuk, i see
[15:13] <kusum> matumba: Keybuk : Hello
[15:13] <cjwatson> kusum: hello?
[15:13] <Keybuk> matumba: http://people.canonical.com/~scott/purple.py
[15:13] <Keybuk> matumba: ^ run on a text VT
[15:13] <Keybuk> kusum: hello
[15:14] <Keybuk> tseliot: so OOI
[15:14] <Keybuk> tseliot: is the background supposed to be #2c001e or #27001d ?
[15:14] <kusum> cjwatson: Could you give me some guidelines on how to go about it
[15:15] <tseliot> Keybuk: let me check
[15:15] <cjwatson> kusum: I don't know how Pardus is organised.  We integrated Wubi into the Ubuntu installer so that Wubi just had to set up a preseed file and then press go
[15:16] <cjwatson> kusum: but the expertise required for the changes I made was expertise in the Ubuntu installer, not expertise in Wubi
[15:16] <cjwatson> kusum: since I don't know how the Pardus installer works, I'm not well-placed to advise on what you would need to do to it
[15:16] <kirkland> pitti: woohoo!
[15:17] <kusum> Could you tell me your primary changes you made in Ubuntu installer?
[15:17] <cjwatson> kusum: you need something that can automatically create loop-mounted filesystem images on NTFS and install the operating system into those; and you need something that can deal with booting from that (sufficiently recent version of grub2, but you need to be careful with the integration; also something in your initramfs)
[15:17] <cjwatson> kusum: mainly writing the 'partman-auto-loop' component to do the automatic partitioning and loop-mounted-image creation
[15:18] <cjwatson> kusum: and tweaking the boot loader installation component to handle slight differences in the configuration file it needed to write
[15:18] <kusum> now that will differ for pardus or can i port partman-auto-loop directly to pardus?
[15:19] <cjwatson> I have no idea what installation system pardus uses
[15:19] <Keybuk> right, time to read the update-alternatives man page again
[15:19] <Keybuk> if you don't hear from me within a couple of hours, send rescue parties
[15:19] <cjwatson> unless it's pretty closely based on the Debian or Ubuntu installer, you'll have to rewrite it
[15:20] <kusum> cjwatson: so partman-auto-loop works while ubuntu installation is in progress ??
[15:20] <cjwatson> similarly, unless Pardus' initramfs framework is initramfs-tools, you'll have to rewrite the stuff that deals with booting off a Wubi-created image
[15:20] <cjwatson> yes
[15:21] <kusum> how does it know when the installation has taken place via wubi and when a normal installation is being taken place?
[15:21] <cjwatson> Wubi tells it, using a preseed file (which is the standard way to automate the Debian/Ubuntu installer)
[15:22] <cjwatson> if you aren't using d-i as your installation system, you'd have to invent some other way
[15:22] <kusum> ohh ok
[15:23] <kusum> do you have some idea about what happens on windows when wubi starts till the restart option is pressed?
[15:23] <lamont> asac: I was recovering from my lucid upgrade yesterday
[15:23] <tseliot> Keybuk: I think it's #2c001e why are you asking?
[15:23] <cjwatson> kusum: very little - Agostino Russo did most of the Windows-side stuff
[15:24] <kusum> cjwatson: Can you tell me the best way i can reach him ??
[15:24] <Keybuk> tseliot: because that's not what you render ;-)
[15:24] <Keybuk> tseliot: you render 27001d ;-)
[15:24] <cjwatson> kusum: I don't like giving out other people's contact details, but I'm sure if you hunt around in the Wubi source code you'll find him
[15:24] <tseliot> Keybuk: some rounding madness perhaps?
[15:24] <Keybuk> tseliot: no, I just think you can't add ;-)
[15:24] <tseliot> let me check
[15:25] <asac> lamont: hi
[15:25] <Keybuk> tseliot: 2e=44 44/256 = 0.17*something*
[15:25] <cjwatson> him -> his e-mail address
[15:25] <asac> lamont: all fine now? ;)
[15:25] <tseliot> Keybuk: it could be :-P
[15:25] <kusum> cjwatson: i did contact him on his gmail
[15:25] <kusum> no reply
[15:25] <cjwatson> kusum: that's the only address I've ever used; he's probably just busy
[15:25] <cjwatson> kusum: he hasn't been around a great deal recently
[15:25] <kusum> I wish to apply for this project in Google summer of Code 2010
[15:25] <lamont> asac: fine is a relative term.  my home directory is now roughly 280GB smaller
[15:26] <lamont> some would consider this a positive thing
[15:26] <kusum> so any details like you just mentioned would be of really great help to me for getting selected
[15:26] <lamont> in fact, that's the one thing left for me to do - recreate the home partition and migrate /home off this root to that one.  though maybe I won't until I've verified that I can tell d-i to put /home $THERE without formatting the partition.
[15:27] <cjwatson> kusum: it looks like Pardus uses its own entirely custom installer, so my suggestion would be to get very familiar with how it handles partitioning configuration and boot loader installation
[15:28] <kusum> cjwatson: Thanks  a ton for patiently telling me everything
[15:28] <tseliot> Keybuk: right, it was definitely a typo (as I don't do any kind of calculation myself when I'm tired)
[15:28] <cjwatson> kusum: you can download the wubi, lupin, and partman-auto-loop components from launchpad.net and study them to figure out roughly how they work
[15:28] <kusum> cjwatson: yes i will do that
[15:28] <cjwatson> maybe the Ubuntu version of grub-installer too
[15:29] <asac> lamont: poor thing your /home ;). so i guess no new builders anytime soon? if you could get one up i would like to try one build that fails because of thumb2 SIGILL on our current builders
[15:29] <asac> otherwise i can just upload with -marm
[15:29] <lamont> asac: assuming I can get it to do something, builder today.
[15:29] <asac> we decided that that was good enough for libplist
[15:29] <tseliot> Keybuk: also, I have some experience with alternatives (see nvidia, fglrx), so if you have doubts on update-alternatives, just let me know
[15:29] <asac> lamont: cool. i will wait. ;)
[15:29] <lamont> when they power up, these boards should spew at the serial, yes?
[15:29] <asac> lamont: let me know if youz want to run a pipecleaning build ;)
[15:30] <cjwatson> asac: has anyone sent this klibc patch upstream, and is it ready to upload or not?  (presumably for upstream inclusion it might need conditionals or something, since I assume it breaks older arm chips?)
[15:30] <asac> lamont: yes. you need to tweak kernel command line though
[15:30] <lamont> asac: what's your favorite package these days
[15:30] <lamont> asac: I meant from boot rom...
[15:30] <asac> lamont: libplist ... a give back on more modern builders should help
[15:30] <asac> lamont: yes. boot rom gives you console
[15:30] <asac> on serial
[15:30] <asac> cjwatson: let me check
[15:30] <lamont> right.  off to do the investigative stuff.
[15:31] <lamont> 9600 8N1? or what speed?
[15:31] <asac> cjwatson: what patch are you talking about? is that in the package or just in a bug?
[15:32] <asac> lamont: 115200 works for us
[15:32] <cjwatson> asac: the one you filed as bug 527720
[15:33] <cjwatson> I'm not sure why you filed a bug rather than just uploading it, but I assumed that maybe this was because it needed some kind of review or something?
[15:33] <lamont> asac: ta
[15:34] <stgraber> cjwatson: that build would be 23.2 right ?
[15:37] <cjwatson> stgraber: it would be, but it fails
[15:38] <cjwatson> failed
[15:38] <asac> cjwatson: bx is safe for armv4t and above
[15:38] <asac> thats pretty old stuff
[15:41] <cjwatson> asac: could you send it upstream?  klibc@zytor.com
[15:46] <Keybuk> cjwatson: if I do Recommends: plymouth-theme-ubuntu-logo | plymouth-theme - will germinate do the right thing?
[15:47] <cjwatson> what do you want the right thing to be? :)
[15:47] <Keybuk> include that package on the CD
[15:47] <cjwatson> then yes
[15:47] <Keybuk> while allowing people to remove it and replace it with silly animated stars
[15:48] <cjwatson> not Depends, given the alternative dep?
[15:48] <cjwatson> you want it to be entirely removable as well?
[15:48] <Keybuk> I'm going to make Plymouth a Depends of mountall
[15:48] <Keybuk> but people still should be able to remove the themes
[15:48] <Keybuk> if you remove its themes, it'll go back to just ordinary text mode
[15:48] <cjwatson> hmm
[15:48] <cjwatson> debootstrap doesn't follow Recommends
[15:48] <Keybuk> ah, meh
[15:48] <cjwatson> I'd recommend that you seed a plymouth theme package explicitly
[15:49] <Keybuk> right
[15:49] <Keybuk> that makes sense
[15:49] <ccheney> anyone familiar with inkscape that could look at bug 529625?
[15:53] <lamont> asac: 115200 gives me line noise
[15:54] <asac> strange. then i guess i am looking at the bootloader output
[15:54] <asac> do you have a SD card inserted
[15:54] <asac> ?
[15:54] <lamont> could be "no"
[15:54] <lamont> were they shipped with them?
[15:55] <lamont> or do we need to get them?
[15:55] <asac> lamont: you need to get one, yes.
[15:55] <asac> lamont: they also came with one, but not with our
[15:55] <asac> lamont: without SD card this thing shouldnt stay on at all?
[15:55] <asac> does it stay on?
[15:55] <lamont> ah, right.  so I do all the magic and love, write the sd card, then stuff it in the machine and boot?
[15:55] <asac> yep
[15:55] <lamont> how big?
[15:55] <asac> lamont: ogra can give you a bootable image
[15:56] <asac> either installer image (from our cdimage server)
[15:56] <asac> lamont: 4G is what we usualy use to be safe
[15:56] <lamont> ah, cool
[15:56] <asac> lamont: i would suggest to take the alternate installer ... want to install lucid right away?
[15:57] <asac> or rather karmic? (i think lucid would be better if you dont mind that its not final yet)
[15:57] <lamont> lucid
[15:57] <lamont> assuming I can just dist-upgrade it once installed
[15:57] <asac> lamont: you can either use installer and install it on harddisk or get a special image from ogra, so the main system stays on SD
[15:57] <lamont> well, make that: I assert that I can dist-upgrade it once installed, regardless of the karmic vs lucid discussion
[15:57] <lamont> hard disk
[15:57] <asac> you then mount the builder disk from there
[15:58] <ogra> lamont, how about http://ports.ubuntu.com/ubuntu-ports/dists/karmic/main/installer-armel/current/images/imx51/netboot/babbage-TO2/babbage-TO2-sd.img
[15:58] <ogra> :)
[15:58] <asac> lamont: yes, you can dist-upgrade ... even if you use a sd
[15:58] <lamont> that's a win
[15:58] <ogra> thats d-i netinst .... just dd to an SD card
[15:58] <lamont> ogra: so write that image to the SD, stuff it in, and it should boot into the installer?
[15:58] <ogra> yep
[15:58] <lamont> ta
[15:58] <lamont> dd to card, yes?
[15:58] <asac> yeah
[15:58] <ogra> yep
[15:59] <ogra> the card will be re-used as bootfloppy
[15:59] <ogra> dont pull it out after the install :)
[15:59] <unggnu> hi all
[15:59] <cjwatson> asac: hm, you seem to have missed a few instances of code matching 'mov.*pc'
[15:59] <asac> cjwatson: we are checking something here atm
[15:59] <asac> cjwatson: currently its build with armv4 etc.
[15:59] <unggnu> Is it a known "bug" that with the standard theme of Lucid Firefox URL suggestions are hardly readable?
[15:59] <lamont> ogra/asac: once installed on the HD, does the SD card need to remain?
[15:59] <ogra> yes
[15:59] <asac> cjwatson: so we might not need it if there is a rason its using that
[16:00] <lamont> unggnu: it's even a filed bug
[16:00] <ogra> it is turned into a bootfloppy
[16:00] <unggnu> blue und dark grey isn't so great
[16:00] <lamont> ogra: ah, so the install process overwrites the SD card?
[16:00] <cjwatson> oh, maybe not, some of this is in an ifdef
[16:00] <ogra> right
[16:00] <unggnu> lamont, ok
[16:00] <asac> on a call now
[16:00] <lamont> ogra: ta
[16:01] <cjwatson> asac: I'm getting confused by the fact that half of your patch is a unified diff and half of it is a context diff, I think. :-)
[16:01] <asac> cjwatson: yes. ignore that for now. i will sort that and let you know ;)
[16:02] <cjwatson> asac: ok, please just go ahead and upload once you're happy with it, and send it upstream
[16:02] <asac> yep
[16:02] <asac> will do
[16:04] <unggnu> lamont, Do you have the bug number?
[16:04] <asac> cjwatson: we are unsure about the whole options currently used. when is klibc exactly used?
[16:04] <cjwatson> unggnu: google 'ubuntu firefox blue grey site:bugs.launchpad.net' - first hit
[16:05] <cjwatson> asac: in the initramfs
[16:05] <cjwatson> bug 532259
[16:05] <unggnu> cjwatson, I used the bug tracker search :/
[16:06] <unggnu> thx anyway
[16:10] <lamont> ogra: them bits want to go on p1 or the non-partition base of the card?
[16:10] <ogra> the bootloader, kernel and initramfs, yes
[16:11] <lamont> ogra: so the .img file... do I just stuff that on /dev/mmcblk0 or on ...p1?
[16:11] <ogra> mmcblk0
[16:11] <ogra> just dd it to the device
[16:12] <lamont> cool.  I suspected such
[16:13]  * cjwatson sighs and runs edubuntu-dvd again
[16:21] <highvoltage> cjwatson: thanks!
[16:23] <unggnu> Is there an ubuntu channel for the music store?
[16:25] <jcastro> unggnu: #u1msbeta
[16:26] <unggnu> thx
[16:29] <cjwatson> stgraber,highvoltage: http://cdimage.ubuntu.com/edubuntu/dvd/20100323.4/ - would appreciate testing (it might not have the i386 image yet, but it's on the master machine so it should get round to it)
[16:39] <highvoltage> cjwatson: ok, starting an rsync...
[16:50] <mathiaz> cjwatson: hi
[16:50] <mathiaz> cjwatson: I'm trying to run a preseed -server install using the beta1 amd64 iso
[16:51] <mathiaz> cjwatson: I run into an warning: debootstrap warning
[16:51] <mathiaz> cjwatson: Warning: restricted/binary-amd64/Packages was corrupt
[16:51] <kusum> mathiaz: Can you tell me what exactly a preseed file does?
[16:52] <mathiaz> cjwatson: I'm using a local http webserver where I've exploded the content of the beta1 server iso
[16:52] <mathiaz> cjwatson: using bsdtar
[16:53] <kusum> mathiaz: Hello
[16:53] <mathiaz> kusum: https://help.ubuntu.com/9.10/installation-guide/amd64/appendix-preseed.html
[16:53] <cjwatson> mathiaz: um, no idea, I have to say I've never supported exploding a CD image like that although people keep trying to do it
[16:54] <cjwatson> mathiaz: you'll have to trace through the files it's downloading and try to figure out which checksum it's comparing against, I think
[16:54] <kusum> mathiaz: thank you
[16:57] <mathiaz> cjwatson: I guess I'll have to run the installation in debugging mdoe?
[16:58] <mathiaz> cjwatson: the syslog I have doesn't seem to mention anything with mismatch checksum
[16:59] <cjwatson> mathiaz: debugging mode probably won't help, you'll have to figure out what command it's running and dig into it from there
[16:59] <cjwatson> get the debootstrap source and search for the error message there (it's in the 'get' function, look for CORRUPTFILE)
[17:00] <mathiaz> cjwatson: ok - thanks for the pointer
[17:00] <cjwatson> maybe put 'set -x' at the top of /usr/share/debootstrap/functions to get a shell trace
[17:01] <cjwatson> mvo: any news on whether the python-apt FFe is going to happen?
[17:05] <Sarvatt> cjwatson: if you remember the the grub2 gfx-payload=keep efifb problem from a month or two ago, once lucid+1 has a new kernel it shouldn't be a problem anymore because efifb was fixed in .33 to properly handoff to a KMS fb
[17:06] <cjwatson> Sarvatt: still not sure it makes a whole lot of sense to cause efifb to start when the system *isn't EFI*
[17:06] <mvo> cjwatson: the exception got granted, I will upload today
[17:07] <bdrung_> i am member of ubuntu-sponsor, but i can't unsubscribe ubuntu-{main,universe}-sponsor.
[17:07] <mvo> cjwatson: the bzr tree is ready, I just need to silence the deprecation warnings by default now
[17:08] <cjwatson> mvo: cool, thanks
[17:15] <cjwatson> seb128: is there any chance that bug 519035 could be fixed for lucid?  it particularly affects the installer.  I tried to apply Thomas' patch to test this out, but I think I screwed something up - see the upstream bug trail
[17:16] <seb128> cjwatson, in a meeting right now but I will try to have a look later
[17:16] <cjwatson> seb128: mm, actually, the upstream bug I'm thinking of is https://bugzilla.gnome.org/show_bug.cgi?id=605137, which merely asks for a way to turn it off, not quite the same as that Ubuntu bug
[17:16] <seb128> I didn't touch that package for ages though
[17:16] <cjwatson> seb128: but a way to turn it off would be lovely
[17:16] <seb128> so if you or mvo just want to back out to change or whatever please do
[17:17] <cjwatson> ok, is didrocks the person to talk to?
[17:17] <seb128> we sort of don't have a maintainer for this one, or nobody really active on it, so I guess it's first one who has a free slot for it sort of thing
[17:18] <ccheney> after looking at the inkscape bug list it looks like it is in pretty bad shape with the number of high heat crasher bugs
[17:18] <cjwatson> hm, ok, I don't know how I feel about backing it out totally
[17:18] <didrocks> cjwatson: can maybe have a look at it on Thursday
[17:18] <asac> cjwatson: so discussing this in -arm we wondered why klibc is in ubuntu at all? seems curently klibc uses a complete different abi for arm - is it really worth investigating rather than moving the stuff that still build depends on it to glibc?
[17:18] <cjwatson> although compiz has no such superuser notification, I think
[17:18] <cjwatson> didrocks: thanks
[17:18] <cjwatson> asac: too much effort to unwind its use from the initramfs
[17:18] <asac> dmart  summon ;)
[17:19] <didrocks> cjwatson: not sure how it works, I'll just give it a try :)
[17:19] <seb128> cjwatson, no compiz doesn't, I would just drop it
[17:19] <dmart> cjwatson: On #ubuntu-arm we're discussing klibc.  It looks like it may be unused in the initramfs, and built with incompatible compiler options from the distro defaults for armel.  Do you know the background to why klibc is present / needed?
[17:19] <cjwatson> dmart: it is most certainly used in the initramfs.
[17:20] <asac> cjwatson: what is that? we need to double check that that is using the same options at least
[17:20] <cjwatson> not as extensively as it used to be, but it's used
[17:20] <asac> i see dmraid, rootskel and cowdancer
[17:20] <asac> as the only build-rdepends
[17:20] <cjwatson> if you don't have klibc in your Ubuntu initramfs, your initramfs will (if nothing else) fail to chain to upstart
[17:21] <cjwatson> some of the programs from klibc-utils are used in core initramfs code
[17:21] <cjwatson> /usr/share/initramfs-tools/init:264:exec run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >${rootmnt}/dev/console 2>&1
[17:21] <cjwatson> for instance
[17:21] <cjwatson> eventually we'd like to get rid of that, quite possibly by moving to dracut or similar - I don't feel good about trying to unpick that stuff after beta though
[17:22] <ogra> but couldnt run-init and friends just link against glibc ?
[17:22] <cjwatson> run-init is part of the klibc source code
[17:22] <cjwatson> sure, you could rewrite it, and you'd have to track down all the new bugs
[17:22] <ogra> ah
[17:22] <ion> keybuk: I wonder, could Plymouth launch the text plugin ASAP and just switch to a FB plugin when a FB becomes available?
[17:22] <cjwatson> I'd have been happy to take that on at the start of a release cycle
[17:22] <cjwatson> but definitely not for lucid
[17:22] <Keybuk> ion: how would that help?
[17:23] <cjwatson> dmart: in this case, does it really matter if it's using a different ABI?  it's a couple of small programs that don't really interact with much else
[17:23] <ion> keybuk: The screen would say ‘Ubuntu 10.04’ or whatever instead of being blank with just a cursor for several seconds.
[17:23] <cjwatson> they're essential in and of themselves, but ...
[17:24] <Keybuk> ion: *shrug* I'd rather shorten the several seconds
[17:24] <asac> cjwatson:  for stuff that build-depends against on it we need to check that they use the same abi etc at least (if they link against it)
[17:24] <bdrung_> can someone unsubscribe ubuntu-main-sponsors from bug #544904?
[17:24] <asac> cjwatson: but thanks. we will check those now
[17:26] <cjwatson> the rootskel dep is for code not used in Ubuntu
[17:26] <ion> keybuk: Until we have magic filesystem block reordering, we’ll probably need ureadahead, and as long as computers have HDDs, ureadahead needs to defer everything else, and as long as that happens, we’ll have the uncomfortable period of screen being blank.
[17:26] <dmart> cjwatson: We could have an incompatible ABI for klibc and the binaries built on it, but I'd prefer if we could synchronise with the defaults --- otherwise there's a problem keeping compile options in sync between klibc and its build-rdepends.
[17:26] <Keybuk> ion: no ;)
[17:26] <dmart> asac, shall we give the lucid defaults a try for this and see how we get on?
[17:26] <asac> dmart: yes. lets try that .. see -arm
[17:27] <asac> if nothing works we just need to remember to review all rdepends
[17:27] <cjwatson> the dmraid dependency is, I think, stale
[17:27] <cjwatson> I can't say I care about cowdancer, and haven't looked
[17:27] <cjwatson> and klibc-utils will certainly be built with the same compiler options as libklibc
[17:27] <lamont> asac: is it supposed to say something after finding the USB hub and freeing init memory?
[17:27] <asac> right. what does "stale" mean?
[17:27] <cjwatson> so I think we're fine
[17:28] <lamont> please tell me it doesn't require dhcp
[17:28] <cjwatson> asac: dmraid has a klibc configure option, but I don't think we ever turn it on
[17:28] <asac> lamont: are you at bootloader ?
[17:28] <asac> or booted?
[17:28] <cjwatson> bdrung_: done, do you want to subscribe ubuntu-sponsors?
[17:28] <lamont> Freeing init memory: 176K
[17:28] <lamont> usb 1-1: new high speed USB device using fsl-ehci and address 2
[17:28] <lamont> u
[17:28] <lamont> and 7 ports on the usb hub.
[17:28] <lamont> and full-stop
[17:29] <bdrung_> cjwatson: nope. i acked it.
[17:29] <asac> lamont: you might need to add console=ttymxc0,115200  to the kernel line
[17:30] <lamont> ah, can I interrupt the boot process to get control to do that?
[17:30] <asac> lamont: i think its ctrl-c
[17:30] <asac> ogra: ^^ how to aboard bbg boot?
[17:30] <asac> lamont: i think its printed on the serial line what to do
[17:30] <ogra> yeah ctrl-c
[17:30] <lamont> woot
[17:31] <ogra> i think redboot even says so
[17:31] <asac> it tells you something like "3.00 seconds (hit ctrl-c for a prompot)"
[17:31] <bdrung_> cjwatson: if you want to unsubscribe ubuntu-main-sponsors and subscribe ubuntu-sponsor take these: https://bugs.launchpad.net/~ubuntu-main-sponsors
[17:31] <lamont> ok... now that I'm sitting at the redboot prompt... what do I type?
[17:31] <lamont> (iz wiki page I should read?)
[17:31] <ogra> you shouldnt even have to be there at all
[17:32] <lamont> well, lack of network might have something to do with it.  no dhcp
[17:32] <lamont> nor can I fix that
[17:32] <lamont> not this month anyway
[17:32] <ogra> if the thing doesnt boot the redboot prompt wont help you
[17:32] <lamont> well, I get as far as freeing init memory and device discovery.. then it just sits
[17:32] <ogra> the point is that d-i and its initrd.gz are contained in the SD img
[17:33] <ogra> it should get you to a d-i screen
[17:33] <ogra> oh, hmm
[17:33] <lamont> well, then.  let me say 'reset' and see how much better it does.
[17:33] <ogra> do you have a DVI capable monitor around ?
[17:33] <lamont> heh.  not a chance
[17:33] <ogra> it might default to DVI
[17:34] <ogra> so lets do that
[17:34] <ogra> at the redboot prompt type fconfig
[17:34] <ogra> hit enter
[17:34] <ogra> it goes to "do you want to run a bootscript"
[17:34] <lamont> do these things at least power on on power application?
[17:34] <ogra> i dont think the new ones do
[17:35] <ogra> but they dont crash :)
[17:35] <ogra> so the power issue is a lot less critical
[17:36] <lamont> ok.  remote hands have cycled it again for me.
[17:37] <lamont> ogra: so... I do want to update the config at the end of all those questions, having dropped console=tty0 from the string
[17:38] <lamont> ?
[17:38] <lamont> oh, look.  DI
[17:39] <ogra> :)
[17:40] <cjwatson> Sarvatt: actually, having looked at the efifb code, it might not be so bad, it doesn't really seem to do anything EFI-specific once it's set up properly
[17:41] <cjwatson> Sarvatt: so thanks
[17:41] <cjwatson> bdrung_: certainly not doing that by hand in the web interface, but I'll have a look via the API
[17:42] <bdrung_> cjwatson: you could extent the script to support ubuntu-universe-sponsors, too
[17:43] <cjwatson> bdrung_: somebody else could, I'm not a member of u-u-s
[17:46] <mrand> I asked in upstart and they recommended I move here.... Is  $LANG  an acceptable (and expected to be future supported) way to support locales in upstart?  If not, could someone recommend something else?  This is in reference to this potential patch for MythTV that is attached to https://bugs.launchpad.net/bugs/541042
[17:46] <lamont> ogra: lunch for me, then I have a little bit of network config to do to make the machine have connectivity, then should be happy happy
[17:47] <ogra> lamont, it might be that you need multiple runs of the network setup, the NIC is a bit nasty to bring up in the d-i env
[17:47] <ogra> its not integrated with the kernels PHY layer ...
[18:02] <AnAnt> Hello, regarding plymouth theme, will there be some technique (such as update-alternatives) to ease branding ?
[18:02] <highvoltage> AnAnt: yep, there is
[18:03] <AnAnt> highvoltage: how ?
[18:03] <highvoltage> AnAnt: for Lucid, you'll run something like /usr/sbin/plymouth-set-default-theme --rebuild-initrd edubuntu-logo
[18:03] <highvoltage> AnAnt: that replaces the symlink in /lib/plymouth to that theme
[18:03] <highvoltage> AnAnt: in Lucid+1 it will probably be changed to use alternatives
[18:03] <AnAnt> highvoltage: I see, thanks
[18:04] <highvoltage> you're welcome
[18:04] <AnAnt> ok, another question, it seems that xsplash isn't used anymore, why is it still installed in lucid ?
[18:05] <highvoltage> probably a bug.
[18:06] <cjwatson> it's not still installed in new installations, as far as I can see
[18:06] <cjwatson> but nothing conflicts with it, so it doesn't necessarily get removed
[18:07] <highvoltage> cjwatson: when I do an apt-cache rdepends xplash, I see a bunch of desktop meta-packages that depend on it, could that information perhaps be outdated?
[18:07] <AnAnt> cjwatson: it is in beta1 live CD
[18:08] <cjwatson> AnAnt: it's not in current dailies
[18:08] <AnAnt> ah, that's good !
[18:08] <cjwatson> dropped in ubuntu-seeds/ubuntu.lucid r1677
[18:09] <mathiaz> cjwatson: so it seems that the Release on the isos includes a reference to the Packages file
[18:09] <mathiaz> cjwatson: however the size of the Packages file is zero and is not included on the iso
[18:09] <mathiaz> cjwatson: I'm referring to the -server beta1 iso
[18:11] <cjwatson> mathiaz: the Packages files on the CDs only include the packages that are actually on the CD; furthermore, Packages itself is never included, as Packages.gz is sufficient and we need to save space
[18:11] <cjwatson> mathiaz: so what you've described so far is as expected
[18:12] <mathiaz> cjwatson: ok
[18:14] <cjwatson> mathiaz: did you get that set -x trace of debootstrap?
[18:16] <mathiaz> cjwatson: well - it's in the installer
[18:17] <mathiaz> cjwatson: so I'm not sure how I can set debootstrap to run with set -x in the installer
[18:18] <cjwatson> mathiaz: edit /usr/share/debootstrap/functions before it runs
[18:18] <cjwatson> say, while it's sitting at a partitioning screen
[18:18] <mathiaz> cjwatson: ah ok.
[18:19] <mathiaz> cjwatson: I think I'll just hit the enter key for now
[18:39] <cjwatson> bdrung_: practically all of those were in something other than Ubuntu (probably just old bug tasks).  I'm working through them
[18:46] <cjwatson> bdrung_: in an lp-shell session, I entered http://paste.ubuntu.com/400105/, and then I'm just doing convert(lp.distributions['ubuntu']); convert(lp.projects['compiz']), etc.  I couldn't find an equivalent of ~person/+subscribedbugs across all distributions/projects, but TBH I didn't look very hard.
[18:46] <smoser> pitti, are you around ? I've got an apport suggested change i'd like you to take a look at
[18:47] <smoser> http://paste.ubuntu.com/400107/
[18:48] <jdstrand> kirkland: hey. I see you fixed bug #545302 (thanks! :). fyi, examples/apparmor/libvirt-qemu did not need to be patched as it is installed as documentation (and quilt is in use)
[18:51] <kirkland> jdstrand: ah, okay, sorry
[18:51] <jdstrand> kirkland: no worries, just fyi
[18:52] <kirkland> jdstrand: i was trying to get a fix published ASAP
[18:52]  * jdstrand nods
[18:52] <kirkland> jdstrand: b/c i think a lot of libvirt/kvm users were DoA
[18:52] <jdstrand> sure
[18:52] <cjwatson> mvo: did you notice that fglrx-modaliases is in restricted now?  causes update-manager to dep-wait ...
[18:52] <kirkland> jdstrand: i don't need to undo that change, do i?
[18:53] <mvo> cjwatson: oh, thanks. I did not notice
[18:54] <mvo> why are the aliases in restricted?
[18:54] <cjwatson> that I haven't looked into
[18:55] <mvo> who moved it there?
[18:57] <davmor2> mvo: Uncle Bulgaria from the wombles
[18:57] <cjwatson> mvo: I don't think it's explicitly logged :(
[18:58] <mvo> cjwatson: thakns, I will ask around to figure out more then
[18:58] <mvo> thanks even
[18:59] <barry> james_w: optimistic ping
[19:00] <james_w> barry: surprising pong
[19:01] <barry> james_w: wow, hi!  i've been doing a little more udd and had a couple of questions for you, if you have some time
[19:01] <james_w> of course
[19:01] <barry> james_w: thumper asked me to package lazr.enum for him, and i need the practice so i gave it a try.  there were two things (so far ;) that makes it a bit painful.  was wondering if you had ideas about how to improve things
[19:01] <cjwatson> bdrung_: all done for main
[19:02] <barry> 1) python setup.py --command-packages=stdeb.command sdist_dsc is painful
[19:03] <barry> 2) debian/watch for launchpad download tarballs is painful
[19:03] <barry> james_w: ^^.  there's an open bug on #2 but nothings been done about it
[19:03] <james_w> 1) I'm not familiar with what that does, could you expand?
[19:03] <james_w> 2) open bug on LP or uscan?
[19:04] <barry> james_w: #1 is setuptools plugin that creates the debian directory, but it puts it in an inconvenient place and the results need some hackery
[19:04] <barry> james_w: #2 on lp
[19:04] <barry> james_w: bug 231797
[19:05] <barry> james_w: i'm thinking it would be nice to have 'bzr debi' or some such to build the debian/ directory template maybe?
[19:05] <james_w> bzr dh-make
[19:06] <james_w> but that uses dh_make rather than stdeb to build the template
[19:06] <barry> james_w: ah, that exists?
[19:06] <james_w> if they are significantly different then we should improve on that
[19:06] <james_w> yeah, in lucid
[19:06] <barry> james_w: nice.  i didn't know about that.  will try
[19:07] <james_w> pass it a tarball
[19:07] <james_w> if upstream has a bzr branch then run it in a copy of that too
[19:08] <barry> james_w: so i would have to build or download the tarball first?
[19:08] <james_w> yes, currently
[19:08] <james_w> well
[19:08] <james_w> it takes http/ftp/sftp/etc. URLs too
[19:08] <cjwatson> bug 231797 is a *closed* bug
[19:08] <barry> james_w: e.g. if i just 'bzr branch lazr.enum' i just have a source branch.  i can build the tarball easily w/ python setup.py
[19:08] <cjwatson> with a working example at the end
[19:09] <barry> cjwatson: yeah.  the solution is just fairly well buried (non obvious)
[19:09] <cjwatson> it sort of sucks that you need to type much of the URL twice
[19:09] <barry> cjwatson: yep
[19:09] <james_w> barry: do you not want to work from http://launchpad.net/lazr.enum/trunk/1.1.2/+download/lazr.enum-1.1.2.tar.gz ?
[19:10] <barry> james_w: in this particular case, it's probably fine.  just wondering for general case when there's only a source branch and no download available
[19:10] <james_w> in that case you have to build a tarball yourself
[19:10] <pitti> ev: wrt bug 503808, any particular reason why usb-creator suppresses crashes like that instead of letting them be filed through apport?
[19:10] <pitti> smoser: looking
[19:10] <smoser> thanks.
[19:10] <barry> james_w: cool
[19:11] <barry> james_w, cjwatson thanks.  let me try 'bzr dh_make' and i'll update the wiki
[19:11] <james_w> barry: I could add support for generating one with "bzr export", but we don't have a solution yet for where that isn't enough (e.g python setup.py sdist doing more than just tarballing the contents)
[19:11] <james_w> please file a bug on the issue
[19:11] <barry> james_w: cool.  will do
[19:11] <pitti> smoser: hm, I'm not sure how useful that is -- attachments get compressed during upload anyway
[19:12] <pitti> smoser: what's your use case?
[19:12] <smoser> pitti, they do ?
[19:12] <smoser> if htye get compressed during upload then you're right, not needed.
[19:13] <pitti> smoser: well, binary attachments do
[19:13] <pitti> pure text files aren't
[19:13] <pitti> (by default)
[19:13] <smoser> oh.
[19:13] <smoser> ok. so the log files that i want to attahc are massive (dozens of Meg) and plaintext
[19:13] <smoser> what would you suggest ?
[19:14] <pitti> smoser: however, you don't actually need to reimplement it, problem_report.py has that built in already
[19:14] <pitti> smoser: you can do
[19:15] <pitti> report['FooFile'] = ('/tmp/foo.log', True)
[19:15] <pitti> which will force compression of that file
[19:15] <barry> cjwatson, james_w i reopened bug 231797 on launchpad with a suggestion for improvement
[19:16] <pitti> smoser: python -c 'import problem_report; help(problem_report.ProblemReport)'
[19:16] <pitti> smoser: and look for "write"
[19:16] <james_w> thanks barry
[19:19] <smoser> pitti, i think i'm missing something. i guess i dont understand how i should use that.
[19:19] <smoser> are you suggesting i use it from the eucalyptus apport hook, or utilize it rather than my gzip code in read_file... ie do you think apport needs to be changed?
[19:20] <barry> james_w: what's the package name for bzr-dh-make?  i'm not finding it
[19:20] <mathiaz> cjwatson: hi - has the iscsi component of the installer changed since beta1?
[19:20] <pitti> smoser: the euca hook can just use that syntax (a tuple with a path, instead of a string value)
[19:20] <james_w> barry: it's in bzr-builddeb
[19:20] <barry> james_w: ah! thx
[19:21] <pitti> smoser: (I just commented on the bug)
[19:22] <smoser> pitti, thanks.
[19:25] <cjwatson> mathiaz: no
[19:25] <mathiaz> cjwatson: trying to install from the archive using netboot
[19:25] <mathiaz> cjwatson: the installer isn't able to find any block devices
[19:26] <mathiaz> cjwatson: however /dev/sda is there
[19:26] <cjwatson> mathiaz: have you run 'login to iscsi targets'?
[19:26] <cjwatson> oh, if it's there then you shouldn't need to
[19:26] <cjwatson> mathiaz: sorry, I need to go out right now, I'll be back in a bit
[19:26] <mathiaz> cjwatson: ok
[19:27] <mathiaz> cjwatson: I've restarted the installer with a default debconf priority
[19:27] <mathiaz> cjwatson: and I saw the screen where there is a list of driver that should be listed
[19:27] <mathiaz> cjwatson: stating that no block device had been found
[19:34] <kirkland> slangasek: http://people.canonical.com/~kirkland/libplymouth2.png
[19:35] <kirkland> slangasek: was this expected to have been fixed?
[19:38] <barry> james_w: bug 545361
[19:39] <james_w> thanks
[19:42] <lamont> ogra/asac: so... about this network that doesn't seem to like me so much
[19:42] <lamont> is it the address assignment, or the link up bit that is lacking?  or both?
[19:52] <slangasek> kirkland: bug #540091
[19:58] <kirkland> slangasek: thanks
[20:09] <jdstrand> seb128: hi! I recently upgraded a system from karmic to lucid and noticed that the gdm theme was still karmic's. I had to dpkg --purge gdm and then install from scratch. I did make some gdm gconf changes prior before upgrading
[20:09] <jdstrand> seb128: is this a known issue?
[20:10] <bdrung_> cjwatson: thanks
[20:12] <lamont> sd 0:0:0:0: [sda] Attached SCSI disk
[20:12] <lamont> ogra/asac: how come d-i doesn't see the drive, when the firmware and kernel clearly do?
[20:13] <mathiaz> lamont: which version of the d-i are you trying out?
[20:14] <okn> hi everyone
[20:14] <okn> I looking for someone who can help me
[20:14] <okn> about wubi-installer
[20:14] <lamont>  http://ports.ubuntu.com/ubuntu-ports/dists/karmic/main/installer-armel/current/images/imx51/netboot/babbage-TO2/babbage-TO2-sd.img <-- mathiaz
[20:14] <lifeless> slangasek: ipng
[20:14] <slangasek> lifeless: opng
[20:15] <lamont> so.. how come my mouse is about an inch above where the arrow is on the screen (when I highlight text in xchat for cut-n-waste)?
[20:15] <mathiaz> lamont: ah - karmic.
[20:15] <lamont> oh gar
[20:15] <lifeless> slangasek: there was a recent bug about a package in the mirror system with noone-can-read-permissions; I'm curious why we didn't just delete the package
[20:15] <mathiaz> lamont: I don't know then.
[20:16] <slangasek> lifeless: physically delete it from the mirrors?
[20:16] <lamont> mathiaz: any reason not to use lucid?
[20:16] <lifeless> slangasek: yeah
[20:16] <okn> I am trying to develop a wubi like software for pardus
[20:16] <mathiaz> lamont: oh - I tried to use the latest netboot install from lucid
[20:17] <lifeless> https://bugs.edge.launchpad.net/lmirror/+bug/542409 is why I'm asking
[20:17] <okn> which is another linux distro
[20:17] <mathiaz> lamont: and it seems that it's not able to find block devices
[20:17] <lamont> ah, ok
[20:17] <mathiaz> lamont: using beta-1 netboot install works
[20:17] <lamont> URL?
[20:17] <slangasek> lifeless: primarily because, while we were in the process of sorting it, there were still references to the file both in the Packages files and in the db; a 404 isn't all that much more friendly to the package manager than a 403
[20:18] <lamont> ah
[20:18] <lifeless> slangasek: ok; I guess I mean 'is it a big deal if you did not have the option of a 403'
[20:19] <slangasek> lifeless: there are designs for a way to mark a bad package out-of-band so that it's mirroring-safe, but those are Not For Lucid
[20:19] <slangasek> lifeless: arguably, we already don't have the option of a 403 where most mirrors are concerned, because if it's chmod 000 mirrors have a hard time retrieving it :P
[20:20] <lifeless> slangasek: I've written a replacement for rsync, for mirroring things like the ubuntu archive; it doesn't currently support file modes.
[20:20] <lifeless> slangasek: If file modes are important for the Ubuntu archive, I'll make supporting them a critical bug, to get it to beta testing level; if they aren't, I won't - this is what I'm trying to assess.
[20:21] <slangasek> lifeless: is this going to land in our tier-one mirrors any time soon?
[20:22] <lifeless> slangasek: jpds is very excited by it; for all its a personal project of time its moving pretty quickly. So 'perhaps'.
[20:22] <lifeless> s/time/mine/
[20:22] <jpds> Hi.
[20:22] <lifeless> jpds: hi :)
[20:23] <slangasek> lifeless: right; then we should feel out with the rest of the team (ubuntu-archive + soyuz) whether people are comfortable with 'rm' instead of 'chmod 000' here, but I can't see any technical reason it wouldn't work
[20:23] <lifeless> slangasek: thanks
[20:24] <jpds> slangasek: It will do with, and once I've tested the crap out of it. ;)
[20:24] <lifeless> slangasek: they can always say 'must have modes', at this point your assessment is sufficient.
[20:24] <jpds> with time*
[20:24] <slangasek> jpds: EPARSE - "it will do with"?
[20:25] <jpds> slangasek: ^--.
[20:25] <slangasek> ah
[20:26] <slangasek> jpds: I'm not asking whether the switch to lmirror will be accepted, I'm asking whether people will find removing files that are still referenced in the db to be ugly / messy
[20:26] <slangasek> if we change our minds, it's a pain to get the files back on disk
[20:26] <jpds> Ah, right.
[20:29] <crimsun> jdstrand: WRT gdm, it doesn't appear to be known (I checked the bugzilla and launchpad entries), but I can confirm your symptom
[20:29] <jdstrand> crimsun: ok. I'll file a bug
[20:30] <lifeless> slangasek: so the key thing is that we'd need a mode like 400, or else the mirror code itself won't be able to propogate the bad file.
[20:30] <lifeless> slangasek: what list[s] should I query this on?
[20:31] <slangasek> lifeless: ubuntu-archive is the list, but I'm not subscribed to it and am not sure who else on the team is.  Grab the list of team members from https://launchpad.net/~ubuntu-archive/+members ?
[20:35] <seb128> jdstrand, "known" in the sense there is a bug a bug about it
[20:35] <seb128> jdstrand, it should not happen if you never changed your config though
[20:35] <seb128> jdstrand, did you ever run gconftool manually or sudo gnome-appearance-properties before?
[20:35] <seb128> sudo -u gdm
[20:35] <seb128> rather
[20:36] <seb128> I didn't confirm on the upgrade test I did there
[20:36] <jdstrand> seb128: I just found bug #532659
[20:36] <seb128> .gconf is not shipped by the package
[20:36] <jdstrand> seb128: I made gconf changes to disable sound, but never touched the theme
[20:36] <seb128> I have to check
[20:37] <seb128> it might be that playing with the accessiblity option on the login screen write a key or something
[20:37] <seb128> since it changes the theme
[20:37] <jdstrand> seb128: this was on two systems-- my desktop and my netbook
[20:37] <seb128> otherwise I don't know why you would have had a custom config there
[20:38] <jdstrand> I didn't even know there was a new gdm theme until I did a fresh install on my laptop...
[20:38] <seb128> ok, it's clearly an issue for quite some user
[20:38] <seb128> users
[20:38] <seb128> but I don't know why yet
[20:38] <jdstrand> then I was like "oh, hey, why doesn't my desktop have that?"
[20:38] <seb128> I will try to play on a karmic box to see what action can write that config
[20:38] <seb128> you never ran gnome-appearance-properties for the gdm user right?
[20:39] <seb128> ie sudo -u gdm gnome-appearance-properties
[20:39] <seb128> do you remember if you clicked on the login screen accessibility icon at some point?
[20:39] <seb128> it changes the theme to the accessibility one
[20:39] <jdstrand> seb128: I am totally unaware of that command, so I would have to give a tentative 'no'
[20:39] <seb128> it's possible that when turning that on and off let the theme set an user one
[20:40] <jdstrand> seb128: I don't think I ever played with accessibility, but I'm not sure. it's possible on the desktop, less so on the netbook
[20:40] <seb128> ok thanks
[20:41] <jdstrand> seb128: I did use the methods in bug #437429 to disable sound though
[20:41] <seb128> jdstrand, I will ping you back later if I've other questions
[20:41] <seb128> I will try if one of those commands does trigger some other settings writting in the user config
[20:41] <jdstrand> sudo -u gdm gconftool-2 --set ...
[20:41] <seb128> jdstrand, k, that might be useful, I will check on that later, thanks!
[20:42] <jdstrand> seb128: on the netbook I also adjusted /apps/gdm/simple-greeter/disable_user_list, but not on the desktop
[20:42] <jdstrand> bug #445123
[20:42] <seb128> jdstrand, so basically you did use sudo -u gdm gconftool to set some gconf keys for the login screen but not the themes ones
[20:42] <jdstrand> seb128: sure! thanks for looking into it
[20:43] <seb128> jdstrand, I will check if that could have some side effects
[20:43] <seb128> jdstrand, you're welcome
[20:43] <seb128> I've to go now
[20:43] <seb128> bbl
[20:55] <cody-somerville> oh god. I'm getting all the edubuntu bugsquad bug email now.
[20:57] <cody-somerville> highvoltage, Why is Ubuntu Core Development Team a member of edubuntu-developers?
[20:58] <cody-somerville> highvoltage, can you set a contact address for either the edubuntu developers team or edubuntu bugsquad team so that I don't get edubuntu bug mail?
[21:02] <slangasek> cody-somerville: so that core-dev has commit access to the seeds when needed
[21:02] <pitti> cody-somerville: eww, yes; /me blacklists
[21:03] <pitti> but for a general solution, edubuntu-dev would need a contact address indeed
[21:03] <tkamppeter> pitti, I did the "bzr push"now.
[21:04] <YokoZar> Whatever happened to the caff package in Lucid?
[21:04] <pitti> tkamppeter: thanks
[21:04] <YokoZar> for key signing?
[21:04] <YokoZar> (hoping I'm not doing something dumb like misremembering the name)
[21:04] <cnd> anyone know what gnome-power-manager does for suspend outside of actually calling pm-suspend?
[21:05] <cnd> I have an issue where calling pm-suspend manually works fine in lucid, but closing the laptop lid leaves the backlight off on resume
[21:06] <lifeless> cnd: what happens if you configure gpm to do nothing on lid closes, call pm-suspend and close the lid quickly ?
[21:06] <cnd> lifeless: not sure, got an idea?
[21:06] <highvoltage> cody-somerville: eek, ok, will do
[21:06] <cnd> I'm booted into karmic, so I can't test easily right now
[21:07] <highvoltage> cody-somerville: I set a contact address, you shouldn't get edubuntu-bug spam anymore
[21:07] <cody-somerville> highvoltage, merci
[21:09] <cody-somerville> highvoltage, also, I think the DMB should probably be the owner of edubuntu-dev instead of a member as its theoretically possible that non core-devs could be a member of DMB and AFAIK being a member of the DMB shouldn't grant you any extra upload permissions.
[21:10] <dmb> ok
[21:10] <geser> cody-somerville: it's not only theoretical, I'm a DMB member but no core-dev
[21:11] <cody-somerville> geser, ugh
[21:12] <cody-somerville> actually you are
[21:12] <cody-somerville> DMB is a member of core-dev :P
[21:12] <asac> lamont: on bbg the driver doesnt give carrier detect yet - if thats what you wondered about
[21:12] <highvoltage> heh. so then it's not theoritically possible!
[21:12] <asac> so you manually have to connect if you use NM
[21:15] <asac> lamont: i dont know about netboot
[21:15] <asac> maybe thats broken
[21:16] <asac> lamont: sorry if thats the case. let me check with folks what works best for beta1
[21:22] <AnAnt> Hello, what's the license of the ubuntu-logo plymouth artwork ? I don't see anything explicit about it in /usr/share/doc/plymouth/copyright
[21:24] <cody-somerville> cjwatson, ^^ Is it intended by the TB for membership on the DMB to implicitly grant Ubuntu core developer status?
[21:27] <cody-somerville> geser, And I think you should apply for core-dev :P
[22:26] <chrisccoulson> hey seb128
[22:26] <chrisccoulson> i've been looking at this terminal profile issue this evening, and i think i've got a slightly better solution for it now
[22:28] <seb128> chrisccoulson, hey
[22:28] <seb128> which one?
[22:29] <chrisccoulson> the issue we discussed in the team meeting earlier about overwriting config on upgrades
[22:30] <chrisccoulson> i've got a solution which involves adding no extra profile, and implementing it all in the gtk theme instead
[22:30] <chrisccoulson> well, i will have that solution in about 30 minutes ;)
[22:30] <seb128> sorry the "which one" was not clear, it was a "which solution" ;-)
[22:31] <seb128> good!
[22:36] <Riddell> bryceh: ping
[22:57] <lamont> asac: yeah - the current issue is that the fw sees sda, but dd of the device finishes with the first read, 0 bytes, EOF, kthx
[23:18] <cjwatson> YokoZar: I think you're looking for signing-party
[23:19] <YokoZar> cjwatson: indeed I am.  And command-not-found could have told me that if I had thought of it
[23:19] <cjwatson> cody-somerville: can't speak for the whole TB, but (a) I think the current situation is a bug (b) I would expect DMB members to be responsible enough not to abuse their access
[23:22] <cody-somerville> cjwatson, I agree. However, once we get rid of components it'll be very easy I imagine to accidentally upload a package you shouldn't have access to but do.
[23:30] <cjwatson> cody-somerville: sure, we should certainly fix it