[00:04] <bluefoxicy> why is empathy retarded and pidgin broken?
[00:05] <bluefoxicy> empathy:  because if you get a message from someone not on your buddy list, there should definitely be no way to talk to them.
[00:08] <RAOF> There's a bug # for that, I presume?
[00:08] <RAOF> That sounds like pretty obnoxious behaviour, and I don't think I've hit it.
[00:14] <bluefoxicy> RAOF:  if someone messages you do you get a new tab?
[00:14] <bluefoxicy> or does their username flash in your buddy list?
[00:15] <RAOF> The latter, last time I checked.
[00:17] <bluefoxicy> RAOF:  and which username flashes when someone not on your buddy list messages you?
[00:18] <RAOF> No idea.
[00:19] <RAOF> I presume that for you the answer is “none”.  And is there a bug report for this?
[00:29] <bluefoxicy> RAOF:  there shall be soon.
[00:59] <lifeless> I need a 'which package to file on' consult
[01:00] <lifeless> ugprading grub-pc in a UEC instance, the AMI is running a slightly older lucid
[01:01] <lifeless> I get this - http://paste.ubuntu.com/400297/
[01:01] <lifeless> and its looping, its gone around 30 or 40 times now
[01:03] <amstan> Lauraxia: hi
[01:03] <Lauraxia> hi
[01:03] <amstan> Lauraxia: what's new?
[01:35] <psusi> woohoo!  first try patching e2defrag to handle the new larger size inodes and it works!
[01:51] <lifeless> StevenK: ping
[02:12] <xnox> how long does it take between debian upload & update on launchpad.net/debian/+source/package?
[02:12]  * xnox can't wait to request sync
[02:30] <slangasek> xnox: from 1 to 7 hours, since Debian's publisher only runs 4x daily
[02:38] <xnox> slangasek, thankx =(((((((((
[02:39] <StevenK> lifeless: Pong
[02:39] <xnox> 2 hours to go then.
[02:39] <lifeless> StevenK: hey
[02:40] <lifeless> StevenK: so, see scroll back for me chatting with slangasek; are you subscribed to ubuntu-archive, or the appropriate list I should email for an opinion ?
[02:41] <StevenK> lifeless: What time roughly, since I didn't see it at a glance, and yes, I am
[02:43] <lifeless> 07:14
[02:47] <StevenK> lifeless: Right, I think file permissions are important, at least in the short term, since that is how we currently stop people grabbing broken stuff when it's critical
[02:51] <lifeless> StevenK: how hard would it be to simply start using rm ?
[02:52] <soren> I /think/ there's a rationale for the current approach on the wiki somewhere.
[02:52] <lifeless> StevenK: I don't see it being more than 's/chmod 000/rm/' in your blacklist script
[02:52] <soren> lifeless: Possibly on one of the DWCIU sub-pages.
[02:53] <lifeless> https://wiki.ubuntu.com/FoundationsTeam/Specs/LucidUpdateManagerStopTheLine ?
[02:53] <soren> lifeless: No.
[02:53] <lifeless> right, have read it now ;)
[02:54] <soren> I forget what the rationale is, though. Something about mirrors, I think.
[02:54] <lifeless> mirrors propogate deletes though
[02:54] <lifeless> and cached things in e.g. squid will equally become inaccessible when a file goes, as when the access bits change.
[02:55]  * soren didn't write the wiki page, nor come up with the rationale :)
[02:55] <lifeless> sure
[02:55] <lifeless> I appreciate the pointer, but I can't find the rationale
[02:55] <soren> You found the relevant DWCIU page?
[02:56] <lifeless> StevenK: so /where/ do I discuss this? implementing support for permissions is easy; but propogating a mode 000 file is /impossible/
[02:56] <lifeless> I'm frankly amazed that rsync doesn't blow up in everyones face
[02:56] <lifeless> soren: no
[02:57] <soren> lifeless: Hm. Well, I obviously can't help you find it. :)
[02:57] <soren> lifeless: that is, if it's there at all. This may all be a figment of my imagination.
[02:58] <StevenK> Doesn't rsync just go "Argh, can't read, skipping" ?
[03:08] <lifeless> soren: oh, internal wiki ?
[03:08] <lifeless> StevenK: which implies that mirrors that didn't have the file already *won't get it*, so it acts like its been deleted.
[03:10] <soren> lifeless: Indeed.
[03:11] <lifeless> what does DWCIU expand to then ?
[03:11] <lifeless> StevenK: and if thats the case, then why not just delete from day one ? :)
[03:12] <soren> lifeless: DealingWithCrisisInUbuntu
[03:12] <StevenK> lifeless: I'm not sure, it's always been the case to chmod 0000 the file, not delete
[03:16] <lifeless> q/win goto StevenK
[03:17] <lifeless> so
[03:17] <lifeless> I've found the doc
[03:17] <lifeless> and it explicitly says that we can't mirror because rsync will blow up
[03:20] <lifeless> StevenK: As I see it, deleting, or replacing with a zero-length file, should be friendlier to the mirror process, propogate further with less issues, and be functionally equivalent
[03:21] <StevenK> lifeless: Then I'd suggest asking elmo why it's chmod 0000 rather than rm
[03:21] <lifeless> ok
[03:21] <lifeless> will do
[03:21] <lifeless> elmo: ^
[03:51] <lamont> meh. that whole notification thing in the upper right of my screen?  interferes with what I'm using that part of the real estate for.. how movable/killable is that, I wonder?
[03:53] <stgraber> lamont: right click + unlock + right click + move should do the trick. Removing it should also fallback to the old behavior.
[03:53] <stgraber> lamont: or you mean notify-osd ? (too much notifications in that corner ;))
[03:54] <lamont> it covers up several channels in xchat.
[03:54] <lamont> more of an irritation - it started with karimc, after all
[03:55] <lifeless> lamont: remove notify-osd
[03:55] <stgraber> ok, so that's notify-osd. Removing notify-osd should fallback to notification-daemon (the old notification system) though it'll likely uninstall ubuntu-desktop so I'd be careful with that
[03:57] <stgraber> or actually, IIRC notification-daemon takes priority on notify-osd (I had that "bug" happening a few times at customers), so installing notification-daemon + logout/login should revert to the old notification system (<= jaunty)
[04:10] <lamont> ta
[04:12] <wgrant> StevenK, lifeless: Why do you play with the file at all?
[04:12] <wgrant> Don't you really want to delete the broken package and revive the old one?
[04:15] <lifeless> wgrant: I don't play with it :P. and yes.
[04:17] <wgrant> I've heard of this thing called Soyuz. It's pretty cool, and just about lets you do that.
[04:18] <wgrant> (and I wish people would stop trying to work around it)
[04:36] <lifeless> wgrant: the internal process doc uses soyuz commands
[04:36] <lifeless> wgrant: and says 'a future soyuz command to reinstate old version of same package' or something approx == to that
[04:36] <lifeless> wgrant: so I think its mischaracterisation to say working around it; soyuz is not the end of the deployment process
[04:37] <wgrant> Playing around in archives generated by Soyuz because nobody has spent 10 minutes to write the Soyuz tool -- that *is* working around Soyuz.
[04:39] <wgrant> (it's probably <10 minutes, actually. it just needs a fix in copy-package.py to look at deleted versions as well)
[05:29] <xnox> I'm cross-compiling gcc as a debian package. Any ideas how can I modify debian/rules to play around with binary target without cleaning & rebuilding it?
[05:29] <xnox> Cause build target takes forever on my machine
[05:30] <persia> xnox: Why cross-compile?
[05:31]  * xnox has nothing to do.....
[05:31] <xnox> I'm trying to build mingw-w64 toolchain bootstrapped from scratch without mingw32 dependencies without using pre-build binaries
[05:31] <persia> xnox: Have you considered unmetdeps, NBS, or RCBugs?
[05:32] <StevenK> lamont: No fair uploading livecd-rootfs without commiting your changes to the bzr branch
[05:32] <xnox> persia, good point
[05:33] <xnox> the real goal is to make mingw-w64 awesome on ubuntu/debian
[05:36]  * hyperair finds it interesting that aptitude in a lucid chroot takes up 50% CPU on a dual core machine just to install things.
[05:36] <hyperair> it's almost like aptitude is busy-waiting for something..
[05:37] <hyperair> ah damnit, it is >_>
[05:37] <hyperair> wait4(27698, 0x7fffa041e688, WNOHANG, NULL) = 0
[05:37] <hyperair> pselect6(36, [0 35], NULL, NULL, {1, 0}, {[], 8}) = 1 (in [0], left {0, 999996927})
[05:37] <hyperair> repeated endlessly
[05:37] <hyperair> this is ridiculous
[06:04] <pitti> Good morning
[06:09] <cooloney> hi, does anybody know how does NetworkManager know this "<info>  (eth0): driver 'fec' does not support carrier detection"?
[06:35] <slangasek> cjwatson: I think in all the rush last week, we didn't pick a chair for this week's foundations meeting? :)
[06:46] <spm> slangasek: a chartreuse comfy leather chair perhaps?
[06:47] <slangasek> I didn't know leather came in chartreuse
[06:49] <spm> you haven't seen the chartreuse cows? tho tbh, possibly not; they blend in well with some grasses. evolution at work - camouflage.
[06:51] <slangasek> must be an .au thing :)
[06:52] <spm> possibly - I heard some noise that it was a defence against Yowies and/or drop-bears. But well... you do wonder at some of the tales... Drop Bears work off vibrations; the colours wouldn't stop them. and Yowies are smell. so...
[07:08] <micahg> is there a trigger to get something to appear in Software Center after changing the .desktop file?
[07:09] <persia> You have to wait for an update to app-install-data
[07:09] <micahg> persia: ah, does that rebuild it?
[07:09] <micahg> or is it stored there?
[07:10] <persia> dpkg -L app-install-data will tell you more than I could explain :)
[07:12] <micahg> persia: ok, so if I update the desktop, the next time the package is spun, it'll be picked up then
[07:12] <persia> That's been my experience.
[07:12] <micahg> persia: k
[07:12] <persia> (although I think we ought find a better way than storing duplicate copies of 2500 .desktop files to handle this :) )
[07:15] <micahg> persia: i modified the .desktop in that package and it didn't help
[07:17] <persia> micahg: What are you attempting to accomplish?
[07:17] <micahg> persia: I wanted to verify that Thunderbird will be added under Mail
[07:17] <persia> What is your Categories value?
[07:18] <micahg> persia: now: Application;Network;Email;
[07:18] <persia> Ah, that's why.
[07:18] <micahg> I added Email as I saw that in the other programs that appeared
[07:18] <persia> You want "Office;Network;Email"  See http://standards.freedesktop.org/menu-spec/latest/apa.html
[07:20] <micahg> persia: nope, that didn't do it
[07:22] <micahg> persia: is there a guide to the software center categories?
[07:23] <ion> See “See http://standards.freedesktop.org/menu-spec/latest/apa.html”
[07:24] <persia> micahg: Not to my knowledge, but I've a tendency to go source diving before looking very hard.
[07:24] <ion> Are you sure the software center is reading your updated desktop file? It may have a cache of some kind.
[07:24] <dholbach> good morning
[07:24] <micahg> ion: that's what I'm wondering
[07:24] <ion> Hi dholbach
[07:24] <dholbach> hi ion
[07:24] <ion> update-software-center, anyone?
[07:24] <micahg> found the cache :)
[07:26] <micahg> actually not :(
[09:19] <cjwatson> slangasek: hm, possibly not.  are you volunteering? :)
[09:25] <pecisk> hi people, It is known bug in Gwibber that it doesn't honor GNOME proxy settings. Well, I have investigated and find out, that it uses pycurl and it is very easy to patch for this. Question is - if we want to get this feature into Lucid, it is a) new feature or b) fixed bug?
[09:27] <mvo> that is a bugfix
[09:30] <pitti> pecisk: sounds like a bug fix to me
[09:30] <pecisk> pitti: cool, then I will work on patch and will let you know where to get it and test it
[09:32] <pitti> pecisk: please let kenvandine know; I'm not that attached to gwibber
[09:32] <pitti> pecisk: thanks for fixing this!
[09:32] <pecisk> ok :)
[09:32] <pecisk> np
[09:52] <nipas> Hello!
[09:53] <nipas> I have 10.04 beta installed, with all updates. Since my first update after a clean beta 1 install , the boot logo does not show correctly
[09:53] <nipas> Is this a common bug?
[09:53] <Keybuk> depends what you think correctly is
[09:53] <Keybuk> and what you actually see
[09:53] <pecisk> nipas: nvidia graphics card?
[09:53] <nipas> yes
[09:54] <pecisk> nipas: it is known bug with plymouth, people working on it
[09:54] <nipas> aha, ok
[09:54] <pecisk> one sec, will provide bug numbers
[09:54] <Keybuk> err
[09:54] <Keybuk> pecisk: what's a known bug?
[09:55] <pecisk> Keybuk: plymouth and nvidia
[09:55] <Keybuk> no it isn't
[09:55] <pecisk> no? :)
[09:55] <Keybuk> no.
[09:55] <nipas> I just wanted to be sure that it is reported :)
[09:56] <Keybuk> nipas: you haven't reported anything yet
[09:56] <Keybuk> you just said the logo does not show "correctly" ?
[09:56] <nipas> nop
[09:56] <Keybuk> for all I know, that means you think the logo should have more dancing monkeys
[09:56] <nipas> not thit bug
[09:56] <nipas> this*
[09:56] <nipas> yes
[09:56] <nipas> i can see graphics
[09:56] <nipas> , but
[09:56] <nipas> there is no backround
[09:57] <nipas> (that urple backround)
[09:57] <Keybuk> perhaps you could take a photo of what you see?
[09:57] <pecisk> nipas: you can see mouse moving and nothing else?
[09:57] <nipas> I can do that with a photo camera
[09:57] <pecisk> do it
[09:57] <nipas> ok
[09:57] <nipas> I will be back in 2-3 mins
[10:00] <nipas> will send a link
[10:01] <nipas> it is being uploaded on imageshack
[10:02] <nipas> http://img535.imageshack.us/img535/7742/dsc07208.jpg sorry about the quality
[10:03] <Keybuk> that looks normal?
[10:03] <nipas> no
[10:03] <nipas> of cource
[10:03] <nipas> course*
[10:04] <nipas> sth goes wrong
[10:04] <Keybuk> looks fine to me
[10:04] <nipas> fine??
[10:04] <pecisk> nipas: it is disk check, not sure what a problem is :)
[10:04] <nipas> it wasn't like that when booting from the live cd
[10:04] <nipas> and before the update
[10:05] <Keybuk> that's because you hadn't installed evil, proprietary, binary, non-free, freedom hating drivers when you booted the Live CD
[10:05] <Keybuk> you only did that after you installed
[10:05] <Keybuk> because you like 3D more than you like freedom
[10:05] <Keybuk> :p
[10:05] <pecisk> hhehe
[10:05] <nipas> aha heh
[10:05] <nipas> and now what i'm supposed to do?
[10:05] <pecisk> nipas: well, I don't quite get where is the problem. this is disk check, let it pass and it shouldn't bother you anymore for a while
[10:05] <Keybuk> feel free to write to your nvidia support representative and ask them to add a true-colour frame-buffer API to their crap stupid idiotic driver :p
[10:06] <pecisk> :D
[10:06] <nipas> you 're right....
[10:06] <nipas> it might be isc check.....
[10:07] <nipas> It also happens on shutdown
[10:07] <pecisk> just let it pass and try again clean booting process
[10:08] <nipas> ok , will do it now
[10:08] <nipas> brb
[10:16] <nipas> I removed the nvidia driver and now,
[10:17] <pecisk> and?
[10:17] <nipas> at the first reboot there was no splash screen
[10:17] <nipas> at the following 3 reboots
[10:17] <nipas> i could not even
[10:17] <nipas> enter login screen
[10:17] <Keybuk> sounds like the driver wasn't removed
[10:18] <nipas> I could see some random colora
[10:18] <nipas> now i selected the previous kernel and managed to login
[10:18] <nipas> ...
[10:19] <nipas> no there is no driver installed
[10:19] <nipas> what a mess..
[10:20] <nipas> what do you suggest?
[10:20] <Keybuk> I don't suggest anything
[10:20] <nipas> :p
[10:20] <Keybuk> people on #ubuntu may be able to help more
[10:21] <pecisk> nipas: #ubuntu+1
[10:21] <nipas> just entered :)
[10:21] <pecisk> go, ask your question again
[10:21] <nipas> I try to do sth first...
[10:21] <pecisk> in that channel
[10:22] <nipas> have a nC day
[10:22] <pecisk> see ya
[10:22] <nipas> cya
[10:22]  * pecisk sights
[10:24] <Keybuk> welcome to my life ;-)
[10:35] <bdrung> persia: can ubuntu-sponsors be a member of ubuntu-{main,universe}-sponsors?
[10:54] <lamont> StevenK: it's more one of forgetting to push it back.  done
[10:55] <StevenK> lamont: Thanks!
[11:09] <ogra> lamont, so did you succeed ?
[11:10] <ogra> lamalex, the network issues are very likely caused by the NIC driver only being half implemented, see bug 457878
[11:10] <lamont> ogra: successfully got network, totally failed to have a disk, other than seeing it in dmesg.
[11:11] <lamont> reads return EOF on inital read of the device
[11:11] <lamont> iz plugged directly into the board
[11:11] <ogra> directly like the SATA interface ?
[11:11] <lamont> yes
[11:11] <ogra> well, thats USB as well :)
[11:11] <ogra> just pretends to be SATA
[11:12] <ogra> but doesnt give you any advantage over a plain USB disk
[11:12] <lamont> so we've been told
[11:12] <ogra> i havnet seen any issues with it though, butu i use external power, it might be a prob if you power the disk from the board
[11:13] <lamont> ogra: ok.  he should be at the DC in the next hour or so, at which point we'll be able to swap things around
[11:13] <lamont> we'll try external power
[11:13]  * ogra has a real 5 1/4" disk attached, power coming from an ATX supply ... i only got an SSD with proper interface a week ago
[11:14] <lamont> any reason not to use the beta1 image?
[11:14] <ogra> no reason at all :)
[11:14] <ogra> the kernel might even be better
[11:14] <lamont> cool
[11:15] <ogra> the karmic and jauntyx kernels both were forward/backports of the BSP patches, lucid is actually the plain BSP kernel and the ubuntu patches being ported instead
[11:15] <ogra> so you can expext better results with it
[11:15] <ogra> and expecially there is a fix for the PHY NIC issue in the pipe atm
[11:16] <ogra> which i suspect to solve a lot of ethernet issues
[11:16] <ogra> though note that i dont know how well the netinst image is tested in lucid
[11:34] <pecisk> kenvandine: here? I have question about bug fix for gwibber
[11:38] <pecisk> /whois pecisk
[11:38] <pecisk> yah, sorry
[11:38] <persia> bdrung: Ideally not, because that would create a loop (as both those teams are members of ubuntu-sponsors).
[11:39] <stgraber> cjwatson: ping
[11:40] <stgraber> cjwatson: seems like Edubuntu DVD built before the i386 LTSP chroot was built (or something similar) causing a build failure for amd64.
[11:41] <bdrung> persia: but then i can't unsubscribe ubuntu-{main,universe}-sponsors
[11:41] <stgraber> cjwatson: oh, nevermind, just saw -release ;)
[11:41] <persia> bdrung: I know.  It's a bug.  We're hoping it goes away soon, because all the docs and tools have been updated to point at ubuntu-sponsors.  Just ask for help, and someone else will unsubscribe.
[12:10] <dmart> cjwatson: Hi there, I've been playing with the klibc build configuration for armel.  Are there tests I can run?  make test builds a lot of test binaries, but I can't see how the binaries should be invoked or what the expected results should be.  Some segfault if not supplied with the proper args.
[12:18] <asac_> dmart: do you see the same segfaults with default options?
[12:22] <sladen> YokoZar: is it not in the 'signing-party' package?
[12:34] <kenvandine> pecisk, pong
[12:36] <cjwatson> dmart: I think in practice testing will involve installing it, building an initramfs, and booting ...
[12:37] <cjwatson> dmart: you could try fstype on a filesystem as well (we should replace this with blkid, but)
[12:37] <pecisk> kenvandine: I have a patch for Gwibber to honor GNOME proxy settings, can I attach it to this bug and you will review it? https://bugs.edge.launchpad.net/gwibber/+bug/259830
[12:37] <kenvandine> pecisk, sure
[12:37] <kenvandine> thx
[12:37] <kenvandine> pecisk, of if you have a bzr branch, propose it for merging
[12:38] <pecisk> kenvandine: I would do that, but I'm behind firewall and bzr stuff doesn't work correctly, so I better of with patch. It is one file anyway.
[12:41] <kenvandine> pecisk, a patch is fine
[12:42] <kenvandine> pecisk, thx!
[12:49] <kenvandine> pecisk, ping me when you attach that patch, i am anxious to check it out
[12:49] <pecisk> kenvandine: sure thing :)
[12:50] <kenvandine> thx
[12:50] <pecisk> I'm testing it to be sure that it works nicely
[12:50] <StevenK> lamont: Still can't see your changes at lp:~ubuntu-core-dev/livecd-rootfs/trunk
[12:51] <lamont> prolly because I pushed them the wrong place
[12:53] <lamont> bzr push
[12:53] <lamont> Using saved push location: bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/
[12:53] <lamont> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/.bzr/)
[12:53] <lamont> is not compatible with
[12:53] <lamont> CHKInventoryRepository('file:///srv/mix.mmjgroup.com/src/Others/livecd-rootfs/livecd-rootfs/.bzr/repository/')
[12:53] <lamont> different rich-root support
[12:53] <lamont> thoughts?
[12:53] <lamont> bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/livecd-rootfs/lucid/ is where the tree _is_ pushed
[13:01] <cjwatson> lamont: I've hit the "Upgrade this branch" button on https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk.  Wait for the "An upgrade of this branch is in progress" message to go away from the top of that web page, and then try again
[13:01] <lamont> ah. doh
[13:01] <lamont> thanks
[13:01] <dmart> asac_: For the particular test program (fnmatch) the crash is just caused by deferencing argv[1] etc. -- providing options solves it.  The tests all build, but there is no definition of how to run them etc. that I can see...
[13:02] <dmart> cjwatson: I'll try installing the debs and rebuilding the initramfs
[13:03] <lamont> afk for those few minutes
[13:08] <ari-tczew> please review SRU bug 421684 before intrepid EOL which is going
[13:14] <cjwatson> lamont: it's upgraded now
[13:24] <didrocks> seb128: cjwatson: as Compiz doesn't show the "as username" string, I will be in favor of removing the functionality from metacity. (upstream is also wondering about that: http://blogs.gnome.org/metacity/2010/02/08/as-superuser-considered-harmful/). What do you think?
[13:24] <Ng> if one were booting a lucid beta ISO in a VM (Parallels on OSX specifically) and the initramfs said it was unable to find a medium containing a live file system, would one confirm bug #543875 or file a new one? (that bug is about real hardware)
[13:24] <lamont> cjwatson: why yes, yes it is.  ta.  and diverged.. le sigh
[13:24] <seb128> didrocks, +1
[13:24] <cjwatson> didrocks: fine by me, I don't think Thomas will mind
[13:25] <didrocks> seb128: cjwatson: ok, doing it so and reporting it in upstream bug report too
[13:25] <cjwatson> lamont: if you branched from the automatic import, then it probably has no revisions in common at all
[13:26] <cjwatson> didrocks: thanks!
[13:26] <cjwatson> Ng: always better to file a new one
[13:26] <didrocks> y/w ;)
[13:26] <cjwatson> Ng: that's just a generic symptom of "errr - hardware detection failed, somewhere"
[13:26] <lamont> cjwatson: very true, that
[13:26] <lamont> I'm thinking I'll just do one commit of love, though
[13:27] <Ng> cjwatson: is there any particular arrangement of options which will yield a more useful amount of information to debug? I'm about a hundred miles away from this system and I'm unlikely to have much opportunity to capture stuff from it later
[13:27] <dmart> cjwatson: sorry - I've been away for a while... What did you mean by trying fstype on a filesystem, how does this relate to klibc?
[13:28] <cjwatson> Ng: https://wiki.ubuntu.com/DebuggingCasper
[13:28] <cjwatson> $ dpkg -L klibc-utils | grep fstype
[13:28] <cjwatson> /usr/lib/klibc/bin/fstype
[13:28] <cjwatson> dmart: ^- is how it relates to klibc
[13:28] <cjwatson> it's an executable klibc ships that is used in some situations during boot, although not in all situations IIRC
[13:29] <Ng> cjwatson: fantastic, thanks
[13:29] <dmart> cjwatson: ah, OK
[13:29] <cjwatson> $ sudo /usr/lib/klibc/bin/fstype /dev/sda5
[13:29] <cjwatson> FSTYPE=ext3
[13:29] <cjwatson> FSSIZE=50001444864
[13:30] <dmart> cjwatson: That seems to work for me
[13:31] <dmart> cjwatson: Do you know anything about the homebrew dynamic linking system in klibc?  This could have arch-specific risks, but I'm not sure what to review
[13:31] <cjwatson> dmart: nothing, I'm afraid
[13:31] <cjwatson> dmart: if it works well enough for booting, IMO that's good enough
[13:32] <primes2h> pitti: Hello. giving a look at this https://bugs.edge.launchpad.net/ubuntu/+source/udev/+bug/536914 could you give me a quick suggestion about it so I can make a patch for itplease ? It's really trivial but I need a small hint.
[13:32] <dmart> cjwatson: OK.  I'll have a quick dig, but I've no special reason to believe it doesn't work.  I'll build an initramfs and try booting it.
[13:32] <lamont> StevenK: pushed, and 1.109 uploaded
[13:34] <StevenK> lamont: I was about to upload one as well
[13:34] <pitti> primes2h: sure, I followed up on the bug report
[13:39] <StevenK> lamont: The changelog and control disagree. :-P
[13:40] <lamont> gah
[13:40] <lamont> yeah - fix that pls?
[13:40] <lamont> or shall I?
[13:40] <StevenK> lamont: Sure, I can fix
[13:41] <primes2h> pitti: Thanks a lot.
[14:00] <mvo> Riddell: hi, do you think you (or someone from kubuntu) could check bug #546024 ?
[14:01] <Riddell> mvo: yes can do
[14:23] <barry> mvo: or anybody else.  any thoughts on updating update-manager's trunk branch to 2a format?
[14:24] <mvo> barry: just go for it
[14:24] <barry> mvo: awesome, thanks
[14:25] <barry> mvo: ah, i can't.  'm not a member of ~ubuntu-core-dev
[14:30] <pitti> barry: want me to run it?
[14:31] <barry> pitti: that would be great
[14:31] <pitti> is that still lp:/~ubuntu-core-dev/update-manager/karmic ? (there's no /lucid)
[14:31] <barry> pitti: actually i was thinking trunk branch, e.g. 'bzr upgrade lp:update-manager'
[14:31] <pitti> barry: running
[14:31] <pitti> ah, /main
[14:32] <pitti> mvo: you should fix Vcs-Bzr: :)
[14:32] <barry> pitti: but i'm always so confused about the relationships between upstream trunks in launchpad and ubuntu release branches.  i wish there was a better relationship between the two.  but i digress (gotta talk w/ james_w about that ;)
[14:32] <pitti> barry: there is in fact: lp:ubuntu/update-manager ;)
[14:33] <barry> pitti: yeah ;)
[14:33] <barry> pitti: actually, i guess you should upgrade that one too
[14:33] <pitti> barry: that's 2a already
[14:34] <pitti> package branches are quite recent
[14:34] <pitti> and mostly come from the auto-importer
[14:34] <barry> cool
[14:34] <pitti> committer: Bazaar Package Importer <james.westby@ubuntu.com>
[14:34] <pitti> yep
[14:34] <pitti> I guess mvo isn't actually using that
[14:34] <pitti> barry: upgrade in progress (had to remove the old backup.bzr on the server first)
[14:35] <barry> pitti: cool.  i'm sure it'll take a little while.  can you ping me when it's done?
[14:35] <pitti> sure
[14:35] <barry> thanks!
[14:35] <pitti> you're welcome
[14:36] <mvo> I don't use lp:ubuntu/update-manager
[14:38] <mvo> pitti: Vcs-Bzr points to lp:~ubuntu-core-dev/update-manager/main
[14:42] <primes2h> pitti: ehm... What does it mean #define KEY_SCREENLOCK          KEY_COFFEE in keymaps file? Should it be numeric?
[14:42] <primes2h> KEY_COFFEE ? :-)
[14:42] <robbiew> mvo: ping
[14:43] <pitti> mvo: ah, sorry, I have additional karmic deb-src in apt, and just saw the last output
[14:43] <pitti> primes2h: KEY_COFFEE is defined numerically, and KEY_SCREENLOCK is an alias
[14:43] <mvo> robbiew: pong
[14:43] <mvo> pitti: no worries :)
[14:44] <mvo> james_w: you can make lp:ubuntu/update-manager and lp:~ubuntu-core-dev/update-manager/main have a common history so that they can be merged? can I do that myself too? is there a process to follow (file a ticket, bug?)
[14:44] <primes2h> pitti: Oh, sorry. I didn't catch it just a line above.
[14:46] <james_w> mvo: I think there's already a bug open for it
[14:47] <mvo> james_w: is there anything I can do/help with?
[14:47] <james_w> mvo: afraid not
[14:47] <mvo> ok, no worries, its not urgent
[14:48] <mvo> I know you have *tons* to do
[14:48] <barry> james_w: istm that this will be a common theme for packages now.  do you have A Plan for how to address that in general?
[14:49] <james_w> barry: a long term plan for the general case, but this case is easier, with just a couple of kinks to work out
[14:50] <barry> james_w: cool.  i've been thinking about the general case more and it's hurting my brain ;)
[14:52]  * mvo brains is already hurting even without thinking about this particular problem
[14:52] <ogra> seb128, hey, i'm trying to write a CD from rhythmbox, i installed the cdwriter plugin but it seems to not show up anywhere
[14:53] <cjwatson> barry: so, I'm doing the "argh, action for today's meeting I haven't followed up on" thing - I basically want https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs?field.milestone=21447 with an extra "assignee" column (and probably removing "heat"), so I'm actually just having a go at doing that myself
[14:53] <cjwatson> barry: unless there's a really easy secret way to do this with Launchpad :-)
[14:53] <seb128> ogra: dunno, is it on in gconf-editor?
[14:54] <barry> cjwatson: not that i know of
[14:54]  * ogra didnt check gconf-editor ... i dont see it in the plugins list in RB
[14:54] <barry> cjwatson: sounds good though
[14:54] <ogra> seb128, active and hidden are checked
[14:55]  * ogra tunrs off hidden
[14:55] <seb128> ogra; that's ok
[14:55] <seb128> the hidden is to show it in the ui or not
[14:55] <ogra> uh, and RB doesnt like that i unchecked it
[14:56] <seb128> dunno open a bug if there is none yet
[15:04] <lamont> which gconf-edit key do I want to tweak to get multi-pixel wide window borders?
[15:16] <cjwatson> barry: ridiculously raw first cut: http://people.canonical.com/~cjwatson/ubuntu-10.04-beta-2.html
[15:16] <cjwatson> not sortable for some reason
[15:16] <cjwatson> oh, the original page isn't sortable either
[15:17] <cjwatson> well then, that should do, now to produce the same thing for lucid as a whole
[15:17] <barry> cjwatson: +1
[15:17] <barry> cjwatson: upload the script somewhere?
[15:20] <cjwatson> barry: http://people.canonical.com/~cjwatson/tmp/task-assignments.py (haven't run this version yet so may be broken, takes a while)
[15:20] <cjwatson> *cough* at the massive cargo-culting from LP
[15:21] <barry> cjwatson: ;)
[15:23] <cjwatson> I should probably run it in the DC rather than shipping a bazillion JSON requests back and forward over ADSL
[15:33] <pitti> barry: conversion just finished
[15:33] <barry> pitti: thanks
[15:35] <cjwatson> barry: moved that to http://people.canonical.com/~cjwatson/task-assignments/ubuntu-10.04-beta-2.html, and the script is in that directory too
[15:35] <cjwatson> lucid.html not so happy though!
[15:45] <bdrung> can a ubuntu-release member have a look at bug #544075?
[15:47] <sebner> bdrung: eclipse \o/
[15:48] <bdrung> sebner: FYI: http://overbenny.wordpress.com/2010/03/19/eclipse-3-5-2-1-in-debian-unstable/
[15:50] <iulian> bdrung: Looking.
[15:50] <sebner> bdrung: yeah, I wanted to ask you if you will sync it so I'd have build it from Debian source myself but it's not that urgent and if we bug the archive-admins enough we'll have it soon :P
[15:51] <bdrung> iulian: thanks
[15:51] <sebner> cjwatson: ^^^
[15:52] <ari-tczew> MOTU SRU, please more activity until end of march, because intrepid is going to EOL
[15:54] <pitti> ari-tczew: "more activity"?
[15:54] <ari-tczew> pitti, yea, take a look sometimes
[15:54] <pitti> all queues are empty, and everythign verified got moved to updates
[15:54] <pitti> ari-tczew: the SRU team isn't responsible for verifying updates
[15:54] <ari-tczew> huh? I'm waiting to review
[15:55] <sistpoty|work> maybe motu-sru vs. ubuntu-sru mismatch?
[15:55] <pitti> (it's the same team now)
[15:56] <Laney> ari-tczew: what bug are you talking about?
[15:56] <sistpoty|work> (yes, but not everyone may know... like I see things in the queue for motu-release here and then ;))
[15:56] <ari-tczew> Laney bug 421684
[15:56]  * sebner waves at sistpoty|work :)
[15:57] <pitti> ari-tczew: erm, you just submitted that 18 hours ago..
[15:57] <sistpoty|work> hi sebner
[15:57] <iulian> bdrung: Accepted.
[15:58] <bdrung> iulian: thanks.
[15:58] <ari-tczew> pitti: I know, but I'm impatient because there is no time
[15:58] <pitti> ari-tczew: "no time"?
[15:58] <sebner> bdrung: yeah, now we need a archive-admin. Let's ask pitti :P
[15:59] <pitti> ari-tczew: karmic has been out there for 4 months, it hardly makes a difference whether we push SRUs a day earlier or later?
[15:59] <bdrung> sebner: eithar that or i do it by myself.
[15:59] <pecisk> kenvandine: ping? :)
[15:59] <pecisk> kenvandine: https://bugs.edge.launchpad.net/gwibber/+bug/259830
[15:59] <pitti> sebner: hm?
[15:59] <pecisk> kenvandine: patch is there
[15:59] <sebner> bdrung: nah, I consider this bad pratice
[16:00] <kenvandine> pecisk, thx
[16:00] <sebner> pitti: do you mind to sync bug #544075?
[16:00] <pitti> speaking of impatience... :)
[16:00] <ari-tczew> pitti, omfg! I'm wrong! mistake intrepid with karmic shit, nevermind :P
[16:00] <sebner> *hrhrhrhr*
[16:01] <pitti> ari-tczew: SRUs for intrepid are pretty much closed anyway now
[16:01] <cjwatson> ari-tczew: and in any case, a release about to go EOL means we do less work on it, not more
[16:01] <sebner> pitti: I still prefer (if time allows) archive admins sync >>>> manual sync upload (with your script)
[16:01] <cjwatson> no point doing lots of hard work when it's about to go away anyway
[16:01] <sebner> cjwatson++
[16:01] <pitti> also, intrepid is so old now that any bug that is in it is hardly important enough now to get fixed
[16:01] <pecisk> kenvandine: will be here for some ten mins, if you have any questions, then to home, will be back at after half and hour
[16:02] <pitti> people have either upgraded to a newer version, or abandoned Ubuntu, or learned to live with the bug
[16:02] <kenvandine> pecisk, looks straight forward... i just wish there was a way we could do that without importing gconf in the backend :/
[16:02] <pitti> sebner: right, but syncs are much more efficient to be done in batches during regular archive days
[16:02] <pecisk> kenvandine: why?
[16:02] <kenvandine> pecisk, we desparately want to keep the service light
[16:02] <pecisk> well
[16:02] <pecisk> it is your decision :)
[16:02] <kenvandine> and not gnome specific
[16:02] <pitti> sebner: anyway, syncing now
[16:03] <kenvandine> pecisk, i don't see any other way though...
[16:03] <sebner> pitti: hrm, yes but in reality this is something between 1 and 10 days tells my experience. Thanks! :)
[16:03] <pecisk> kenvandine: if you keep this for Ubuntu only, then python-gconf is already in deps
[16:03] <ari-tczew> pitti, cjwatson: so security updates are too not necessary? for intrepid
[16:03] <sebner> bdrung: see ;)
[16:03] <kenvandine> pecisk, yeah... the dep is the least of it, it is memory footprint
[16:03] <pitti> ari-tczew: they are
[16:03] <pitti> ari-tczew: but usually not SRUs any more
[16:03] <kenvandine> pecisk, but really there is no straight forward way to do that any other way
[16:03] <bdrung> great
[16:04] <ari-tczew> okay, thanks! and I'm waiting for response to SRU for karmic :)
[16:04] <pecisk> kenvandine: you can grep gconf xmls, but it will take much more resources
[16:04] <kenvandine> pecisk, ideally gnome settings like proxy info would just automatically be exported in your login shell so the whole desktop has access to it
[16:04] <kenvandine> eeww
[16:04] <pitti> kenvandine: it is
[16:04] <pitti> kenvandine: $http_proxy
[16:04] <pitti> GNOME sets that
[16:05] <kenvandine> pitti, not in a terminal
[16:05] <pitti> so that it's working with wget and just about any other program
[16:05] <pitti> kenvandine: sure it does
[16:05] <kenvandine> really?
[16:05] <pitti> if not, that's a bug
[16:05] <pecisk> pitti: no, it doesn't
[16:05] <kenvandine> then why is this even an issue :)
[16:05] <pitti> pecisk: WFM..
[16:05] <kenvandine> pitti, how are you testing it?
[16:05] <pecisk> pitti: I am siting behind nice firewall without any other access than proxy, and I have tested this well :)
[16:05] <kenvandine> gnome-terminal gets it from gconf, i think
[16:06] <jdstrand> ari-tczew: fyi, intrepid is fully supported until the end of April
[16:06] <pitti> system -> prefs -> proxy
[16:06] <pitti> select my "proxoid" profile (for my G1)
[16:06] <pitti> open terminal
[16:06] <pitti> $ echo $http_proxy
[16:06] <pitti> http://localhost:8080/
[16:06] <kenvandine> pitti, how about from like xterm?
[16:07] <ari-tczew> jdstrand, ah until end of April? okay, thanks! :)
[16:07] <pitti> kenvandine: doesn't work in xterm for me
[16:07] <pecisk> hmmm
[16:07] <pecisk> pitti, you're right
[16:07] <Laney> kenvandine and pitti: We talked about this earlier
[16:07] <kenvandine> yea... gnome-terminal sets that up for you
[16:07] <kenvandine> Laney, i know :)
[16:08] <pecisk> kenvandine: but it doesn't let Gwibber work anyway
[16:08] <pitti> but why doesn't the proxy thing just export it to the entire session..
[16:08] <Laney> you have to read it from gconf on a per app basis basically
[16:08] <pitti> that would work so much better
[16:08] <Laney> pitti: mvo gave some reasons in scrollback
[16:08] <pitti> I don't think we should fix each and every program to work with that
[16:08] <kenvandine> pitti, it would solve lots of potential for problems...
[16:08] <Laney> kenvandine: did you try libproxy?
[16:08] <Laney> that was the suggestion
[16:08] <kenvandine> no
[16:09] <Laney> it's supposed to abstract all of this
[16:09] <mvo> pitti: see scrollback, I'm not opposed at all, we just need to think about the corner cases
[16:09] <Laney> scrollback in #ubuntu-desktop
[16:09] <kenvandine> Laney, can you get at libproxy from python?
[16:09] <pitti> mvo: you mean opposed to exporting $http_proxy to the session?
[16:09] <Laney> kenvandine: yeah there are binding
[16:09] <Laney> s
[16:09] <pitti> mvo: I actually thought that's what it would do anyway
[16:09] <bdrung> pitti: thanks
[16:10] <kenvandine> mvo, i can't think of a case where you wouldn't want that
[16:10] <kenvandine> if you set it for your desktop, you likely need it
[16:10] <pecisk> pitti: if proxy has auth, how http_proxy looks like then? http://user:password@host:port/
[16:10] <Laney> I have to set it for work and then unset when I get home
[16:10] <kenvandine> Laney, yeah... but you do that via gnome right?
[16:10] <Laney> yep
[16:10] <pitti> pecisk: I don't know, probably?
[16:11] <kenvandine> pecisk, yes
[16:11] <Laney> apps won't be able to tell when the env var changes, so they'll have to be relaunched
[16:11] <kenvandine> humm
[16:11] <Laney> not that that's any worse than the current situation where they don't work at all
[16:11] <kenvandine> that is ugly
[16:11] <pecisk> kenvandine: in nutshell, I think reading it from gconf would be proper and easier way to do this, but that's just me :)
[16:11] <kenvandine> sure
[16:11] <kenvandine> pecisk, for now... i just wonder how much memory that takes :)
[16:11]  * kenvandine will profile
[16:11] <Laney> but maybe the libproxy api supports events for this
[16:12] <kenvandine> i do know the libproxy author :)
[16:15] <pecisk> kenvandine: will do profiling now or later? :)
[16:15] <kenvandine> pecisk, soonish :)
[16:15] <kenvandine> fixing a u1music store bug atm
[16:16] <pecisk> kenvandine: ok, you will be here after 2 hours?
[16:16] <kenvandine> pecisk, yup
[16:16] <pecisk> nice
[16:16] <pecisk> see ya later
[16:16] <kenvandine> pecisk, give me a ping when you get back
[16:16] <kenvandine> thx for the patch!
[16:17] <pecisk> np ;)
[16:34] <mrenouf> Packaging question: I've got a couple custom packages. I'd like a new version of one to replace the other. Each "Conflicts" with the other, and the new one is marked with "Replaces" the other. The other one does get uninstalled, but it seems to remain selected, aptitude prompts be to resolve a conflict by putting things back (reinstall the removed one, downgrade the other). How can I prevent it ending up in this state?
[16:34] <pitti> Keybuk: do you plan to update udev to a new upstream version in lucid still? or should I start cherrypicking keymap changes to the ubuntu package?
[16:35] <Keybuk> pitti: no, kay changed something fundamental that I don't want to include in lucid
[16:36] <Keybuk> can't remember what that is, but I remember reading the patch and putting the safety catch on the upload button ;)
[16:36] <pitti> ok
[16:36] <Keybuk> so yes, backport keymap fu
[16:36] <pitti> Keybuk: would you mind if I backport a bug fix or two, and some rules for keymaps?
[16:36] <pitti> ok, that's fine
[16:36] <pitti> the next bzr merge should get along with it
[16:36] <Keybuk> (though 151 is still the latest)
[16:37] <pitti> Keybuk: at least it means that I don't need to coordinate with you any more to do the git-> bzr dance :)
[16:37] <mrenouf> sorry if this is not the right place ;-) #ubuntu was no help
[16:37] <pitti> Keybuk: okay, thanks
[16:38] <Keybuk> pitti: yeah, you only need that for new upstream versions
[16:38] <cjwatson> pitti: should bug 445852 be assigned to you?
[16:38] <Keybuk> the *day* that they get the udev import into lp working, I'm going to cheer very loudly
[16:38] <Keybuk> so loudly that for a brief moment, you won't be able to hear elmo laugh
[16:38] <pitti> lol
[16:38] <pitti> Keybuk: what about StevenK?
[16:39] <pitti> cjwatson: uh, I'll have a look at this, yes
[16:41] <Keybuk> pitti: nothing is that loud
[16:41] <Keybuk> pitti: that's the libatasmart bug that Lennart claims is deliberate behaviour, or something
[16:41] <pitti> Keybuk: that, too?
[16:41] <Keybuk> even though it's not doing the same thing as smartmontools
[16:41] <Keybuk> and if it was doing the same thing as smartmontools, it wouldn't kill people's SSD
[16:41] <pitti> Keybuk: I recently fixed the libatasmart bug that says "OMGyourdriveisbroken!!"
[16:42] <pitti> where lennart said it'd be deliberate
[16:42] <Keybuk> this is the libatasmart that *causes* you to say OMG MY DRIVE IS BROKEN!
[16:42] <pitti> I haven't seen that one yet
[16:42] <Keybuk> in the bugzilla bug
[16:42] <highvoltage> Keybuk: I couldn't find the text-fallback theme settings in the theme script, where would I find that?
[16:42] <Keybuk> highvoltage: the what?
[16:42] <Keybuk> pitti: read through the bug, and see the associated kernel.org and fd.o bugs
[16:42] <Keybuk> basically libatasmart does something invalid and invasive to the SSD that can kill the firmware of some of them
[16:43] <Keybuk> (it ended up on udev at one point, so I aided in debugging back then, and traced it to devkit-disks)
[16:43] <pitti> Keybuk: yes, will do; as I said, I haven't seen #445852 yet; I just dealt with bug 438136 the othher day
[16:43] <Keybuk> yeah
[16:43] <Keybuk> bug #445852 is more fun
[16:43] <Keybuk> popey has the smouldering remains of some hardware iirc
[16:43] <Keybuk> (he first alerted me to it)
[16:44] <popey> :)
[16:44] <popey> its fixed now after maximum prejudice with dd
[16:44] <popey> although if I did install karmic, it would break again
[16:44] <Keybuk> popey: does it not break on lucid?
[16:44] <highvoltage> Keybuk: sorry, I'm talking about plymouth
[16:44] <Keybuk> highvoltage: yes, but I didn't understand your question
[16:44] <popey> i dont know, I haven't installed clean karmic on it
[16:45] <popey> due
[16:45] <popey> gah
[16:45] <popey> s/karmic/lucid
[16:45] <popey> i upgraded from a fixed karmic install to lucid
[16:45] <highvoltage> Keybuk: for the edubuntu theme, it still shows the purple background and "Ubuntu" in the text fallback mode, how can I change the background and text for the fallback mode?
[16:45] <Keybuk> highvoltage: you can't
[16:46] <highvoltage> Keybuk: ok
[16:46] <Keybuk> you could write an edubuntu-text theme that had a different background color and text ;)
[16:46] <highvoltage> Keybuk: would you mind if I file a feature request for that for lucid+1?
[16:46] <Keybuk> highvoltage: only if you also supply a patch <g>
[16:47] <highvoltage> Keybuk: sounds like an interesting project, I might just take you up on that
[16:47] <Keybuk> there might be a way to do it
[16:47] <Keybuk> themes in plymouth are ini files
[16:47] <Keybuk> if there's a way to add custom fields to those ini files, and source them from the plugin that actually draws it
[16:47] <Keybuk> then we could make ubuntu-text pick up the colours and text from its theme ini
[16:47] <Keybuk> so we'd have one ubuntu-text.so
[16:47] <Keybuk> but /lib/plymouth/themes/ubuntu-text
[16:47] <Keybuk> and /lib/plymouth/themes/edubuntu-text
[16:47] <Keybuk> which both just contained an ini file that re-used the same plugin
[16:47] <Keybuk> if you can find out, that would be AWESOME!
[16:50] <pitti> Keybuk: is lp:~ubuntu-core-dev/udev/ubuntu still "the" branch? or did you switch to lp:ubuntu/udev now?
[16:50] <Keybuk> I think lp:ubuntu/udev
[16:50] <Keybuk> but I may have pushed to both
[16:51] <davmor2> meh wifi isn't connecting, it's showing AP but not connecting to them after yesterdays kernel update.  BCM wifi card using sta driver.
[16:51] <pitti> for lp:ubuntu/udev we should drop vcs-bzr:
[16:51] <Keybuk> pitti: right, but last time I pushed there, the branch vanished again
[16:51] <Keybuk> so I haven't "definitely" pished yet ;)
[16:51] <Keybuk> ah
[16:51] <Keybuk> no
[16:51] <Keybuk> lp:ubuntu/udev has been overwritten *again*
[16:51] <Keybuk> so carry on using lp:~ubuntu-core-dev/udev/ubuntu
[16:51] <pitti> Keybuk: ack
[16:52] <Keybuk> all the time the udev import fails, it seems the importer retaliates by wiping and restarting
[16:52] <pitti> Keybuk: there is a magic "bzr mark-uploaded" (or so) command
[16:52] <pitti> I'm not sure what it does, though
[16:52] <pitti> I didn't need to use it for the last couple of uploads I did with package branches
[16:52] <cjwatson> mark-uploaded => bzr tag $(top thing from debian/changelog)
[16:52] <Keybuk> yes
[16:52] <Keybuk> it doesn't help ;)
[16:52] <Keybuk> it still wipes branches every now and then
[16:53] <pitti> cjwatson: ah, is that like debcommit -r?
[16:53] <Keybuk> but only if they're problem branches
[16:53] <cjwatson> pitti: yes
[16:53] <pitti> cjwatson: ah, that's why I don't need it then
[16:53] <pitti> dch -r/debcommit -r is hardwired in my fingers by now
[16:53] <mdz> Keybuk: I've been helping mfrey isolate a race which causes mountall to stall waiting for the root filesystem to be mounted. can I run a theory by you for sanity checking?
[16:54] <Keybuk> mdz: of course
[16:54] <Keybuk> is this different to "the kernel calls the root filesystem /dev/root, and there's no symlink for that in udev" bug?
[16:55] <mdz> Keybuk: I looked at that one, and yes, this looks different
[16:55] <mdz> Keybuk: what I think is happening is that it's missing udev events while blocking in ply_event_loop_run()
[16:56] <Keybuk> event queue overflowing?
[16:56] <Keybuk> or because it's blocking, it's not actually waiting for events?
[16:56] <mdz> Keybuk: because it's blocking in ply_event_loop_process_pending_events, which I don't think will wake up if there are udev evetns
[16:56] <mdz> because it's only polling on the plymouth fd
[16:56] <mdz> and not the udev monitor fd
[16:57] <Keybuk> right, but when it comes out of that poll - it should see the pending udev events, right?
[16:57] <mdz> Keybuk: it blocks there forever without timing out
[16:57] <Keybuk> yes
[16:57] <Keybuk> it's waiting for you to press a key in plymouth ;-)
[16:57] <Keybuk> this is a bug
[16:57] <Keybuk> we shouldn't do it that way at all
[16:57] <Keybuk> but I was in a rush when I wrote that code
[16:57] <Keybuk> better code is on my To Fix list this week
[16:58] <Keybuk> (about to get kicked out of coffee shop - but on IRC at __keybuk :p)
[16:58] <mdz> Keybuk: should I open a bug? do you want to describe the fix and maybe one of us can take a stab at a patch?
[16:58] <mdz> __keybuk: ^^
[16:58] <__keybuk> Sure
[16:59] <mdz> __keybuk: on plymouth?
[16:59] <__keybuk> Though bear in mind that all the Plymouth code in mountall is going to change anyway
[16:59] <mdz> or mountall?
[16:59] <__keybuk> No on mountall
[16:59] <__keybuk> The epoll fd of Plymouth can be stuffed into libnih's own main loop
[16:59] <__keybuk> So mountall never needs to block on it
[17:00] <mdz> __keybuk: how ought it to work? should it run nih_main_loop instead of ply_event_loop_run?
[17:00] <__keybuk> This also fixes the waits for a filesystem that shows up while waiting issue
[17:00] <mdz> __keybuk: in fact I think it already does watch the plymouth fd
[17:00] <__keybuk> It should not block at all
[17:00] <__keybuk> It should put a message up, and deal with key events in the normal main loop
[17:01] <mdz>         NIH_MUST (nih_io_add_watch (NULL, *(int *)ply_event_loop,
[17:01] <mdz>                                     NIH_IO_READ,
[17:01] <mdz>                                     (NihIoWatcher)ply_event_loop_process_pending_events,
[17:01] <mdz>                                     ply_event_loop));
[17:01] <__keybuk> Right that's what it should use
[17:01] <__keybuk> Rather than a separate one for the prompts
[17:03] <mdz> __keybuk: so I think I know how to get rid of the ply_event_loop_run call, but I don't know how to avoid ply_event_loop_process_pending_events blocking
[17:03] <__keybuk> That should never block
[17:03] <__keybuk> If it does Plymouth has a bug
[17:03] <cjwatson> barry: lp:~ubuntu-foundations-team/+junk/task-assignments - feel free to commit directly
[17:04] <__keybuk> It will only get called when the epoll fd polls true
[17:04] <__keybuk> And that means epoll_wait should not block on that fd
[17:04] <mdz> __keybuk: I agree, though it would be nice if this could be coded more defensively
[17:04] <mdz> since it ends up stalling the boot if there is a bug
[17:05] <__keybuk> I think fixing the bug is better than assuming the code is buggy
[17:05] <mdz> __keybuk: which reminds me...I noticed along the way that if plymouth exits while we are blocked in this state, mountall remains blocked
[17:05] <mdz> so there are surely other cases where this could be triggered, e.g. a plymouth crash
[17:06] <mdz> I'm not sure whether that's because epoll() is blocking, or it's not noticing the error when it does
[17:06] <__keybuk_> Oops
[17:07] <mdz> __keybuk_: did you miss my previous few messages?
[17:07] <__keybuk_> Probably
[17:07] <mdz> __keybuk_: pasted to /query
[17:07] <doko> ttx: https://bugs.launchpad.net/ubuntu/+source/netbeans/+bug/544459 any opinion on this? applications getting their updates (not just extensions and plugins) over the web and shadowing parts of the system libs?
[17:08] <__keybuk_> Probably neither l
[17:08] <highvoltage> __keybuk_: sorry I was away a bit, I'll check it out, thanks for the insight
[17:08] <__keybuk_> Epoll will go true cause fd polls true for Reading etc
[17:09] <__keybuk_> Plymouth runs epoll twice
[17:09] <__keybuk_> Argh
[17:09] <__keybuk_> It sounds more like Plymouth runs epoll twice
[17:11] <__keybuk> If select/poll/epoll had bugs, we'd know about them ;)  they'd affect more than half-finished code I wrote on a train :p
[17:11] <mdz> __keybuk: so...bug on mountall (should avoid calling blocky libply function) and bug on plymouth (function shouldn't be quite so blocky)?
[17:11] <__keybuk> I'd blame my code in mountall first :)
[17:12] <__keybuk> Mountall has to call into Plymouth to process events - so a "should avoid" bug is nonsense
[17:13] <mdz> __keybuk: so...bug on plymouth (ply_event_loop_process_pending_events shouldn't block) and leave mountall using ply_event_loop_run()?
[17:13] <__keybuk> Right
[17:13] <__keybuk> And make sure mountall is actually behaving
[17:14] <__keybuk> Which it definitely isn't in many paths
[17:14] <mdz> and there are at least two cases in which it can block, one of which is unknown and the other is when the plymouthd process exits
[17:14] <mdz> the unknown one may be when it's waiting for a keystroke, but I haven't confirmed
[17:14] <__keybuk> The "boredom" code is definitely wrong
[17:15] <__keybuk> Fd close > I may not have set a handler for that
[17:25] <__keybuk> Mountall is next on my todo list after Plymouth
[17:25] <AnAnt> ah, 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
[17:27] <AnAnt> or who can I ask ?
[18:11] <pecisk_> kenvandine, I am back :)
[18:11] <kenvandine> hey
[18:12] <kenvandine> looks like libproxy is much lighter weight and we could easily use your existing patch with slight modifications
[18:12] <kenvandine> if we went the libproxy way
[18:12] <kenvandine> just instead of using gconf to get it, use libproxy to get the values
[18:13] <pecisk_> kenvandine, libproxy can get values from GNOME proxy settings?
[18:14] <kenvandine> yes
[18:14] <kenvandine> it is like 1/3 the size, memory wise
[18:14] <kenvandine> pecisk_, and it isn't dependent on gnome... i think it works in other environments
[18:14] <pecisk_> nice :)
[18:16] <pecisk_> kenvandine, it won't make gwibber depend on libproxy?
[18:16] <pecisk_> on python-libproxy I mean
[18:16] <kenvandine> it would, but we ship with that anyway
[18:16] <pecisk_> allright then
[18:16] <kenvandine> well we could just include enough libproxy code in gwibber for now
[18:16] <kenvandine> license is friendly to do that, and it is super small
[18:18] <pecisk_> :)
[18:23] <pecisk_> kenvandine, ok, seems fairly easy, I will try to modify patch right now
[18:23] <kenvandine> pecisk_, awesome... thx!
[18:34] <ccheney> how do you manually create a deb with ar?
[18:35] <ccheney> assuming i have the three pieces already? control.tar.gz  data.tar.lzma  debian-binary
[18:35]  * ccheney is trying to test a change in install scripts and didn't want to rebuild OOo to do it
[18:36]  * ccheney bets he probably added the files in wrong order
[18:37] <ccheney> yea order of files matters, must be in order of: debian-binary control.tar.gz data.tar.lzma
[18:48] <Caesar> slangasek: before I do the work to write up a FFe for rsyslog, what's the likelihood of it being approved?
[18:50] <highvoltage> Caesar: well, usually you'd put the rationale/risks/etc in the FFe, how would he be able to tell you that without having seen that?
[18:51] <Caesar> highvoltage: it's true
[18:52] <highvoltage> Caesar: there's a lot of packages going through every day, I think that if the reasons are sound there's a good chance
[18:52] <Caesar> The reasons that I'm being asked to do it relate to the current version being old, and the version currently in Debian testing is the last development change to that branch
[18:52] <Caesar> Bugfixes only from here on
[18:54] <Caesar> I'll go ahead and write up an FFe as time permits
[18:59] <beuno> pitti, hi  :)   who do I talk to about aptitude segfaulting all the time in lucid?
[19:00] <beuno> I've reported the bug with the dump attached, but I rarely can due to things to being up to date
[19:00] <beuno> which is usually why I'm running aptitude  :)
[19:10] <slangasek> Caesar: I assume that you will be giving me a clear FFe that presents a reasonable analysis of the tradeoffs, and that it is likely both to be approved and to be approved quickly.
[19:10] <slangasek> :-)
[19:14] <Caesar> slangasek: I'll do my best
[19:14] <cody-somerville> For lp #507238, does the fallback text theme also have alternatives support?
[19:16] <jdstrand> ttx, kirkland: I am working on a merge of libvirt 0.7.7-4 as part of my apparmor work this cycle (the plan was to work off newer code and backport my work to 0.7.5-5ubuntu15 which is in lucid now)
[19:16] <jdstrand> ttx, kirkland: that said, I looked at http://libvirt.org/news.html 0.7.6 and 0.7.7 do not offer many new features, but offer a ton of bugfixes. are you interested in 0.7.7 for lucid?
[19:17] <jdstrand> ttx, kirkland: if not, that's fine, I just thought since I was doing a merge anyway, you might be interested
[20:16] <okn> hi eveyone
[20:16] <okn> I looking for help
[20:17] <okn> to develop wubi-like software for another linux distro
[20:17] <okn> namely pardus
[21:46] <Some_Person> Why does gdm conflict with usplash?
[21:50] <slangasek> Some_Person: because usplash and gdm no longer play well together on the question of VT management (and won't in the future, plymouth now owns this at boot time)
[21:51] <Some_Person> So I can't ditch plymouth and use usplash instead
[21:51] <slangasek> any attempt at doing so would fail horribly for reasons deeper than gdm
[21:52] <superm1> would it be worthwhile removing it from the archive then too to prevent allowing people to break so bad?
[21:53] <slangasek> superm1: probably; though perhaps we should explicitly push plymouth a bit farther down the stack before doing so (e.g., mountall doesn't currently depend on it)
[22:01] <cjwatson> okn: I explained this in depth to somebody else just a day or two ago, so rather than me repeating it, I'd recommend you read the logs - they're on irclogs.ubuntu.com, this channel, you should only have to look back a couple of days
[22:28] <okn> cjwatson: thx
[22:30] <arpu> hello
[22:30] <arpu> anyone can help me find out the problem on this bug https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/531556
[22:31] <arpu> same problem on intel grafic card
[22:36] <Some_Person> slangasek: Why would replacing plymouth with usplash fail horribly? That's what karmic used
[22:38] <slangasek> Some_Person: a) I guess you haven't seen the bug list for karmic, b) the software hasn't stood still since then, and a fair amount of code has changed since karmic to use plymouth to the exclusion of usplash, precisely to fix the bugs on that list :)
[22:38] <jbebel> cjwatson or superm1, Are ubiquity plugins the new method of adding custom hooks to oem-config?  And is there any relatively simple method of converting old oem-config hooks to ubiquity plugins?
[22:38] <Some_Person> slangasek: You're right, I have not seen the bug list
[22:39] <Some_Person> slangasek: But what about all the people with plymouth not working?
[22:39] <lifeless> Some_Person: we should fix those bugs
[22:39] <cjwatson> jbebel: you can still add post-install hooks as before, and that's still the simplest approach for noninteractive hooks
[22:40] <cjwatson> jbebel: if that worked for you before, you shouldn't need to change.  plugins allow you to do interactive things
[22:40] <Pretto> what is the package for shutdown option in the memenu?
[22:40] <jbebel> We need these to be interactive.  For instance, this is where we get the users real password and apply it to LUKS.
[22:41] <slangasek> Some_Person: the only place where plymouth is known to outright not work is on nvidia with the nouveau driver and multiple displays; everything else should be at various stages of "working", and getting better
[22:41] <jbebel> relating to the email you should have received about preseeding a default crypto password.
[22:41] <Some_Person> On my intel graphics, I don't see plymouth on boot but do on shutdown
[22:41] <cjwatson> jbebel: Ubiquity/Plugins on the wiki has the interface docs, but ev and superm1 have done much more than I on that
[22:42] <slangasek> Some_Person: bug #535108 - there's a one-liner you can use to force the boot splash on startup, and the expense of boot speed
[22:42] <cjwatson> Some_Person: on hdds, we don't show the splash until after ureadahead has finished, because the alternative approach slows down boot
[22:43] <cjwatson> Some_Person: we have a plan for lucid+1 that will fix that, but it requires a newer kernel and is generally too intrusive for lucid
[22:43] <jbebel> I didn't write the previous oem-config hooks, but it looks like we dropped some things into oem_config/components and oem_config/frontend which asked the questions for us.
[22:43] <jbebel> This was for hardy.
[22:44] <cjwatson> jbebel: ah, so not the post-install hooks I was thinking of then.  you'll need to migrate those, but I don't know of a howto
[22:44] <jbebel> right.  We have a post-install hook as well, but it's the interactive part I need to migrate.
[22:44] <cjwatson> your component should turn into the main plugin file, and you'd migrate the frontend changes into PageGtk etc. classes in the plugin file
[22:45] <Some_Person> cjwatson: I did notice that the live CD's splash seems to work
[22:45] <cjwatson> Some_Person: yes, the live CD starts the splash in the initramfs instead because that typically takes much longer and live CD boot speed isn't critical
[22:45] <cjwatson> and we don't do ureadahead on the live CD anyway
[22:45] <jbebel> Ok.  Thanks.  I'll read through the doc and experiment.
[22:46] <Some_Person> cjwatson: Is the speed difference really noticible?
[22:46] <slangasek> Some_Person: yes - the liveCD uses the equivalent of the one-liner change in that bug
[22:46] <cjwatson> Some_Person: yes, it can be
[22:47] <Some_Person> So this will not be fixed with lucid's release
[22:47] <cjwatson> Some_Person: you basically end up doing nothing else for a bit except waiting for the framebuffer to come up (can take seconds) or else ruining ureadahead's perf by doing something else while it's running
[22:47] <slangasek> the fact that boot splash doesn't show up on every boot on all systems will not be fixed for lucid, no
[22:48] <cjwatson> on the upside the lucid+1 plan is *really* cute
[22:48] <Some_Person> What's the plan for lucid+1?
[22:48] <slangasek> however, slightly more importantly, the boot splash *will* show up reliably when you need to interact with the boot scripts because, say, your hard drive needs surgery
[22:49] <cjwatson> we should be able to run in graphical mode all the way from the bootloader, and in many cases without a mode switch
[22:49] <cjwatson> using efifb with handoff to a kms driver as necessary
[22:51] <cjwatson> we won't have to change bootsplash system to do this, so we won't lose the reliability benefits of multiplexing I/O through plymouth
[22:52] <Some_Person> Another big question: why do 2 old themes still in the repos require a now-unsupported GTK+ theme engine?
[22:54] <RAOF> cjwatson: Then all we'll need is some hardware that supports EFI?
[22:55] <barry> RAOF: like a mac?
[22:55] <RAOF> barry: And aren't they shiny! :)
[22:55] <barry> RAOF: they are indeed
[22:59] <cjwatson> RAOF: that's what I thought initially, but it turns out I was wrong
[22:59] <cjwatson> RAOF: probing efifb from scratch requires EFI, yes, but actually running it only requires a simple linear framebuffer region in memory
[23:00] <cjwatson> RAOF: so if grub2 sets up efifb's screen information structures in memory at boot (it already knows how to do this), then it works on non-EFI systems too
[23:00] <ttx> jdstrand: about libvirt, I think it's interesting, but I'd wait for kirkland's advice -- I know he planned to work on libvirt soon
[23:00] <cjwatson> RAOF: the thing we're missing in lucid is handing off from efifb to a KMS driver
[23:00] <RAOF> cjwatson: Sweet!  That sounds surprisingly simple.
[23:01] <cjwatson> RAOF: this is what gfxpayload=keep in grub2 does, and is why lots of people are raving about it
[23:01] <cjwatson> it's just not *quite* ready for general use yet
[23:01]  * ttx disappears
[23:01] <RAOF> Aaah.
[23:01] <cjwatson> but apparently it's fixed in 2.6.33
[23:01] <RAOF> Does that mean I'd miss out on Keybuk's awesome text-mode plymouth theme, though? :)
[23:01] <cjwatson> afraid so ;-)
[23:01] <RAOF> Awwwww!
[23:02] <petn-randall> Hello, I've found a way to squash two bugs in Lucid, how do I get to upload the packages? I've got a launchpad account
[23:02] <slangasek> you can console yourself by installing grub-invaders
[23:02] <petn-randall> Is there some mentoring program like in Debian?
[23:02] <cjwatson> (also I'm definitely not willing to switch how the boot framebuffer works a few weeks before release!)
[23:03] <RAOF> Is that what I think it is?  Space invaders from the bootloader?
[23:03] <cjwatson> petn-randall: https://wiki.ubuntu.com/SponsorshipProcess is probably a decent place to start
[23:04] <petn-randall> thx
[23:04] <cjwatson> grub-invaders> it's actually booted from GRUB, rather than running in GRUB directly
[23:04] <cjwatson> it's multiboot-compliant, hence the grub- prefix
[23:07] <petn-randall> hmmm .... how can I sign up as a MOTU developer with upload rights?
[23:07] <petn-randall> Is this a lengthy process like becoming a DD?
[23:08] <cjwatson> it's on the same general order of magnitude as joining Debian, but I think usually somewhat quicker
[23:08] <cjwatson> https://wiki.ubuntu.com/UbuntuDevelopers
[23:09] <cjwatson> (that's maybe not the best entry point, but it's one I had to hand)
[23:10] <petn-randall> ok, I'll work my way through from there, thanks again cjwatson :)
[23:10] <petn-randall> cu
[23:24] <slangasek> bryceh: bug #545832 has just come in; it appears users who are using the fglrx driver still see the radeon KMS driver used at boot time - probably a kernel bug, do you know for sure / have you seen this bug before?
[23:26] <barry> slangasek, bryceh i saw some problems with my radeon when i upgraded to lucid.  switched to using the xorg-server-edgers ppa (or whatever it was called).  that fixed things, with a small glitch here and there
[23:26] <slangasek> barry: what sort of problems?
[23:26] <bryceh> slangasek, weird, probably more a question for tseliot though
[23:27] <bryceh> or apw maybe
[23:27] <barry> slangasek: system crash after getting purple splash screen
[23:27] <slangasek> bryceh: I was hoping you could channel him since he logs off in the evening :-)
[23:27] <RAOF> That'll be a failure of the fglrx packgae to properly blacklist radeon, surely?
[23:28] <bryceh> RAOF, yeah that's what I'm thinking
[23:28] <slangasek> ah, it adds blacklists? ok
[23:28] <slangasek> "it" --> "nvidia"
[23:28] <barry> dont ask me, i know so little about this stuff ;)  but i'm willing to be a guinea pig for anything you want to test.  i'd like to not use the ppa packages if possible
[23:28] <slangasek> barry: do you have fglrx installed?
[23:29] <bryceh> it's possible people can louse up their systems if they manually install things without updating initramfs
[23:29] <barry> slangasek: is there an easy test of that?
[23:29] <barry> bryceh: i just did update-manager -d :)
[23:29] <slangasek> barry: 'dpkg -l fglrx', I believe :)
[23:29] <bryceh> afaik as long as you use update-manager it should blacklist radeon for fglrx
[23:30] <bryceh> tseliot would know better
[23:30] <barry> slangasek: ah :) no, not installed
[23:30] <bryceh> barry, aha
[23:30] <slangasek> bryceh: hrm, would've thought that's jockey's job to do the blacklisting, or the package itself, not u-m
[23:30] <bryceh> barry, did you uninstall it yourself or did it get uninstalled by the upgrader?
[23:30] <barry> bryceh: i've been meaning to ping you about this since i upgraded last week but have just been kind of swamped ;)
[23:31] <bryceh> slangasek, specifically (IIRC) it's in the post-inst script of the package
[23:31] <barry> bryceh: i had some weird stuff going on when i upgraded because it had some nvidia stuff loaded.  i think i might have uninstalled fglrx
[23:31] <bryceh> slangasek, so update-manager and jockey should both be triggering the same thing
[23:32] <barry> bryceh: ftr, i have an HD 4670
[23:32] <slangasek> bryceh: heh, quite
[23:32] <bryceh> barry, ah then that is probably what happened
[23:32] <barry> bryceh: but i don't think i did that until *after* i noticed the crashes
[23:32] <bryceh> the upgrader is not super smart about cleaning up situations where the user manually installed/uninstalled stuff
[23:32] <barry> bryceh: iow, update-manager -d; reboot; crash; boot from live cd; chroot + fix; reboot
[23:33] <slangasek> bryceh: I'm not aware of any cases where the upgrader itself isn't smart about this; are bugs filed an update-manager?
[23:35] <barry> bryceh, slangasek: /me -> dinner.  if you need a guinea pig i can check back later or tomorrow and retry standard packages