[00:00] <hrocha> merry christmas, bye
[00:02] <smiter> running 8.10 now spash screen comes up.. bar moves see a bunch of test on starting then screen goes blank. and i hear the drums
[00:04] <smiter> *text
[00:38] <funkyHat> I want to file a bug against the gnome shutdown thingy (the countdown timer or something), which package is that?
[00:39] <funkyHat> It's a feature suggestion, I think that if someone clicks on shutdown on the session indicator and then closes the lid of the laptop the system should shutdown, not (insert closing lid action)
[00:39] <funkyHat> Now that I think about it I'm guessing it's the session indicator...
[00:40] <chrisccoulson> funkyHat - yes, that's the session indicator, but it's more complicated than that
[00:40] <chrisccoulson> the session indicator has no way of knowing if your lid is closed
[00:40] <funkyHat> Yes I imagined that would be the case
[00:40] <funkyHat> I still think it's a valid bug though
[00:41] <chrisccoulson> yes, but i don't know which package it should go against
[00:41] <chrisccoulson> the changes required in the session indicator to do that would be non-trivial
[00:41] <funkyHat> Do you know which package the session indicator is in?
[00:41] <chrisccoulson> indicator-session?
[00:41] <chrisccoulson> that would be my guess :)
[00:41] <funkyHat> Ah, thanks :)
[00:42] <funkyHat> I suppose it could inhibit gdm and poll for a laptop lid status somehow
[00:42] <funkyHat> I don't know the ins and outs of it but it doesn't seem that complex. Unless inhibiting only applies to shutting down, not suspending
[00:43] <chrisccoulson> inhibiting and checking the status of the lid button are 2 completely different concepts though
[00:43] <chrisccoulson> and gdm has nothing to do with laptop lids either
[00:43] <chrisccoulson> thats gnome-power-manager
[00:44] <funkyHat> That's what I meant :)
[00:44] <funkyHat> I don't see why inhibiting and checking lid status need to be related concepts
[00:44] <chrisccoulson> they're not, but i got the impression that you thought they were
[00:45] <crimsun> I'm a bit perplexed why I received the e-mail for the sync request and an immediately subsequent rejection
[00:45] <funkyHat> Ah, no I just figured those were the two things that would need to be done to achieve this
[00:45] <chrisccoulson> anyway, it should be opened against indicator-session for now. indicator-session would need to get the lid button info from dk-power
[00:45] <crimsun> [ubuntu/lucid] haskell-src-exts 1.3.0-1 (Accepted) ... haskell-src-exts_1.3.0-1_source.changes rejected
[00:46] <funkyHat> Oh here it's already filed. bug 462318
[00:49] <funkyHat> Thanks chrisccoulson
[00:52] <Laney> crimsun: 21/12 23:06:33 <james_w> the flush seemed to reject all the packages, I'm not sure why
[00:52] <Laney> don't know where that leaves such packages
[00:52] <crimsun> Laney: thanks
[00:53] <james_w> on the ftpmaster
[00:53] <james_w> didn't you get an accept as well?
[00:53] <james_w> oh, yeah
[00:53] <james_w> it seems like it tried to accept twice
[00:53] <Laney> crimsun: heading towards new xmonad?
[00:53] <crimsun> Laney: would be nice but is fairly low on my priority list; feel free
[00:53] <chrisccoulson> siretart` - i have gnome-screensaver inhibiting working with VLC again \o/
[00:54] <Laney> good stuff. I wrote some UDD queries to get the state of the union earlier
[00:55] <Laney> good god, I haven't uploaded anything in almost a month
[00:56] <Laney> bad me
[01:02] <chrisccoulson> Laney - yes, bad you - you must be slacking :P
[02:01] <stgraber> hmm, looks like latest initramfs-tools and that mountall upload broke a lot of things (as in, not being able to debootstrap ;)). initramfs-tools conflicts with current mountall and the new mountall is stuck in depwait due to libplymouth-dev being in universe
[02:02] <stgraber> I guess I'll have to wait till tomorrow to get my LTSP server working ;)
[02:05]  * slangasek promotes plymouth to main
[02:06] <stgraber> oh, ok, that'll will the issue of course ;)
[02:15] <UnixDawg> hey guys
[02:16] <UnixDawg> having a issue with apache2 pkg on 9.10
[02:16] <UnixDawg> it installed a blank httpd.conf
[02:36] <slangasek> UnixDawg: that's expected behavior; please see #ubuntu for support
[06:42]  * StevenK blinks at how the base system is no longer debootstrapable
[06:42] <slangasek> I believe that should be fixed with the latest mountall build
[06:42] <slangasek> scream if it's not
[06:42] <slangasek> (mountall 2.0)
[06:44] <StevenK> My debootstrap a little while ago was still pulling down 1.1
[07:06] <LucidFox> Hmm, not sure if my question went through before the disconnection, so...
[07:06] <LucidFox> Is the 3.0 quilt format enabled in Ubuntu yet?
[07:07] <fabrice_sp> LucidFox, yes. Since a couple of  days
[07:08] <LucidFox> Whee!
[07:08] <LucidFox> Time to migrate my packages.
[07:14] <hyperair> what are the changes required to make a package use the 3.0 quilt format?
[07:18] <fabrice_sp> hyperair, http://wiki.debian.org/Projects/DebSrc3.0
[07:49] <dholbach> good morning
[07:53] <mvo> hey dholbach!
[07:54] <dholbach> hey mvo
[08:12] <LucidFox> Wmm, what about orig.tar.bz2? Is it supported now?
[08:14] <slangasek> part and parcel of v3, yes
[08:15] <pitti> Good morning
[08:15] <pitti> ScottK: rescore> sorry, was off for the night; still need any rescoring?
[08:15] <pitti> yay 3.0 source support \o/
[08:43] <hyperair> has anyone succeeded in using git-buildpackage with pristine-tar and multiple orig tarballs?
 part and parcel of v3, yes
[08:48] <LucidFox> And lzma? It's disabled in Debian, as I read, but what about Ubuntu?
[09:12] <ttx> pitti: could you bump build score on https://launchpad.net/ubuntu/+source/eucalyptus/1.6.2~bzr1103-0ubuntu4/+build/1410724 so that it has a chance to make it on the daily CD run ?
[09:13] <pitti> ttx: done
[09:13] <ttx> anyone knows why the amd64 builders are so crowded ?
[09:13] <ttx> pitti: thx!
[09:13] <mneptok> ttx: i blame Freemasonry
[09:13] <ttx> pitti: yesterday the build started around 10:30pm CET
[09:13] <ttx> mneptok: that always works.
[09:14] <slangasek> mneptok: that's Openmasonry to you
[09:15]  * mneptok gives slangasek the secret handshake
[09:35] <StevenK> slangasek: Okay, verified that mountall 2.0 fixes the base system, thanks.
[09:36] <LucidFox> Could an archive admin retry this build? https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.6.0-1ubuntu5/+build/1407295
[09:36] <LucidFox> I wonder why ld of all things segfaulted, though.
[09:37] <StevenK> LucidFox: You don't need to be an archive admin, just a core-dev
[09:37] <LucidFox> Ah.
[09:40] <slangasek> and that build shouldn't be retried
[09:40] <StevenK> Yeah, I didn't think so either, reading the log
[09:40] <slangasek> it's a known problem; someone who speaks qmake needs to figure out how to disable -Wl,--gc-sections on powerpc
[09:41] <StevenK> slangasek: Wow, --gc-sections causes ld to SEGV on ppc?
[09:41] <slangasek> StevenK: bug #498631
[09:42] <StevenK> slangasek: Ouch
[09:43] <LucidFox> Why does Qt try to build with -Wl,--gc-sections in the first place?
[09:44] <LucidFox> It's not standard qmake behavior, so upstream must have specifically enabled this.
[09:45] <StevenK> LucidFox: It probably is because upstream told it to do so.
[09:48]  * LucidFox apt-get sources
[09:49] <mok0> pull-lp-source
[09:50] <Mamarok> cjwatson: hi, any news on that glibc backport we talked about?
[09:55] <bigon> hi, dois the ubuntu archive support the 3.0 version of debian pkg with bz2 compression?
[09:55] <bigon> does*
[10:01] <LucidFox> bigon> Yes
[10:01] <LucidFox> Now it does
[10:01] <LucidFox> REVU doesn't support the 3.0 format, though. :/
[10:01] <LucidFox> Well, it uploads, but can't unpack.
[10:02] <bigon> LucidFox: thx
[10:34] <geser> ttx: thanks for this quick review
[10:34] <ttx> geser: no pb, it was a pleasure :)
[10:35] <geser> anyone interested in sponsoring a perl merge (bug #496556)? (sorry, it can't be currently merged with bzr)
[11:00] <ttx> pitti: 1.6.2~bzr1103-0ubuntu4 was published too late for the server ISO daily run to pick it up... i'll need a respin :/
[11:01] <pitti> ttx: no problem, they are cheap to build
[11:02] <ttx> pitti: cool then. btw if it's also cheap to give me power to trigger respin, then I'd stop bothering the release team for that
[11:04] <mr_pouit> is there an easy way to obtain x backtraces? here, x is crashing horribly because of xsplash, but no core is generated (Process 3029(Xorg) has RLIMIT_CORE set to 0)…
[11:06] <pitti> that requires an RT at least (you need a cdimage ssh accunt and some group permissions)
[11:06] <pitti> but it's not that much work, don't worry
[11:06] <pitti> yesterday's X should have enabled apport again
[11:06] <pitti> but the current kernel doesn't work with apport right now
[11:06] <pitti> due to bug 498525
[11:06] <pitti> and I don't know a good way how to circumvent this
[11:07] <ttx> pitti: it's not so much the work, it's more about the interrupt :) But OK, I'll keep bothering one of you guys :)
[11:07] <ttx> pitti: you already restarted it ?
[11:08] <pitti> ttx: ah, can do now (didn't interpret it as "please do now")
[11:08] <ttx> pitti: that's why I doublecheck :)
[11:08] <pitti> running
[11:08] <pitti> ETA 10 mins
[11:08] <ttx> pitti: thanks !
[11:18] <pitti> ttx: done
[11:18] <ttx> pitti: ok
[11:34] <mathiaz> ttx: how functional is the latest eucalyptus?
[11:34] <mathiaz> ttx: is it worth testing it?
[12:16] <directhex> hm, let's get this over with, then
[12:16] <directhex> which archive admins are about on his fine morn?
[12:16] <directhex> well, it's gone noon, but you get the idea
[12:18] <jpds> directhex: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
[12:19] <directhex> jpds, i'm more soliciting opinion than asking for action to be taken, so i didn't really think the day's hat-wearer mattered much
[12:25] <ttx> mathiaz: good question. The current daily (20091222.1) should start alright, I've yet to try to run an instance, though :)
[12:25] <ttx> mathiaz: you should have a more precise answer in 30 minutes
[12:27]  * Laney sprays directhex with asbestos
[12:31] <mathiaz> ttx: I'm actually testing from packages, rather than from iso
[12:32] <directhex> Laney, mmm cancerous fibres!
[12:32] <ttx> mathiaz: ok
[12:33] <mathiaz> ttx: have you also noticed issues in trying to restart eucalyptus-cloud?
[12:34] <mathiaz> ttx: starting eucalyptus-cloud is already slow
[12:34] <mathiaz> ttx: restart eucalyptus-cloud doesn't always work
[12:34] <ttx> mathiaz: yes, sometimes a process is left around
[12:34] <ttx> mathiaz: I hit that a few times
[12:45] <LucidFox> Heh, http://www.kdedevelopers.org/node/2736 has a perfect metaphor for grumbles about autotools to cmake migration.
[12:45] <LucidFox> "Them new shiny tools you are using ain't looking like my trusty old sledgehammer!"
[12:47] <Riddell> LucidFox: except the point of the blog is that sentence isn't true
[12:48] <LucidFox> I never claimed it was. I hate autohell.
[12:49] <LucidFox> I just don't like autotools adherents who are wary of cmake just because it's different.
[12:49] <Riddell> it always amazes me that there are people who still use it
[12:50] <directhex> LucidFox, there's a reason for en.wikipedia.org/wiki/Autohell
[12:52] <LucidFox> Yesterday, I wrote a fully feature-equal cmake replacement for gtkpod's build system, and committed it to git master. While one of the other developers argued for it, the reaction of the other one was, "Is it really worth it? What does it do better except Windows builds, which I don't care about anyway?"
[12:53] <LucidFox> So I wrote a long email explaining it. Think I should reproduce it on Planet Ubuntu.
[14:18] <siretart`> slangasek: since you are the last one who has touched cryptsetup: I've did a testinstall with today's alternate install daily with encrypted lvm. I ended up with an bootable system, but /boot does not contain any kernels, but /boot/grub
[14:18] <siretart`> slangasek: now I'm seriously confused what's going on here. how did that setup managed to work? and is this an installer or cryptsetup problem?
[14:18] <siretart`> s/work/boot/
[14:20] <siretart`> slangasek: oh, mystery solved. /boot was not mounted, and the root filesystem contains /boot/grub that is shadowed by the /boot mount
[14:21] <siretart`> still, not mounting /boot during startup seems pretty critical to me.. hmm.
[14:22] <ion> Get:35 http://fi.archive.ubuntu.com lucid/universe nexuiz-textures 2.5.2-3 [521MB]
[14:22] <ion> apt-sync would be nice right about here, especially since it’s just a packaging change. :-)
[14:23] <siretart`> ion: I think you've just found the largest package in the archive :-)
[14:24] <siretart`> hm. the missing /boot does not seem to be even deterministic. the 2nd boot went just fine... hmm
[14:30] <Chipzz> LucidFox: I very very very much doubt cmake gets all the cornercases right which autotools do get right
[14:30] <Chipzz> and quite frankly, replacing the build system of a project you don't own is IMO highly inappropriate
[14:36] <pitti> cjwatson, mdz, kees:
[14:37] <pitti> cjwatson, mdz, kees: will you be at the DMB? I'm afraid with the holiday season we won't have quorum today, so we might just skip this one
[14:37] <pitti> tseliot: are you here today?
[14:37] <tseliot> pitti: sure, I'm here
[14:37] <pitti> (your core-dev app is the only topic anyway)
[14:37] <mdz> pitti, I have another meeting at the same time, but I think it is unlikely to make quorum, so I expect to be able to join DMB a bit late
[14:37] <tseliot> oh
[14:38] <mdz> pitti, the other topic is the upcoming election, but I sent an email update to the list already
[14:38] <pitti> right, I noted that down as an "in progress" action point on https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
[14:39] <pitti> mdz: hm, is quorum == or > (number_of_team_members/2) ?
[14:39] <pitti> IOW, do we need 3 or 4 people?
[14:40] <mdz> pitti, 3 is sufficient IMO
[14:41] <pitti> mdz: I'll just wait for you and kees then
[14:46] <lamont> why does network mangler hate my eth0?
[14:47] <ScottK> pitti: If you get a quorum would you discuss the per-package uploader question please (for kubuntu-dev)
[14:47] <pitti> ScottK: please see my email response; I think it's already handled now, and in the unlikely event that some other DMB member objects, they can followup by mail
[14:47] <ScottK> pitti: OK.  Thanks.
[14:48] <pitti> ScottK: I updated the wiki page accordingly, so in the future we can just apply the privs for kubuntu-dev approved per-package uploaders
[14:48] <pitti> (it was really just a process inconsistency)
[14:48] <ScottK> pitti: OK.  Sounds good.
[14:52] <tseliot> pitti: maybe Keybuk can join the DMB meeting?
[14:56] <tseliot> Keybuk: how can I reproduce the plymouth bug (other than on boot)? What shall I do after I kill gdm and X?
[14:56] <Keybuk> tseliot: you can just stop gdm, then start plymouth from tty1
[14:57] <Keybuk> you'll note that Alt+F7 and Alt+F1 don't do what you'd expect
[14:57] <mathiaz> pitti: isn't hald supposed to go away in lucid?
[14:57] <Keybuk> though I debugged it with upstream late last night
[14:57] <Keybuk> and we worked out it
[14:57] <pitti> mathiaz: yes, mostly; it's currently not installed by default
[14:57] <tseliot> Keybuk: what did you find out?
[14:57] <Keybuk> tseliot: plymouth uses /dev/tty0 rather than /dev/tty7 to do most of its setup
[14:57] <Keybuk> (KD_GRAPHICS, VT_PROCESS, etc.)
[14:58] <Keybuk> but doesn't wait for the VT switch
[14:58] <tseliot> right, I noticed that
[14:58] <mathiaz> pitti: hm ok. The lucid UEC image has a bunch of hald-related processes around
[14:58] <tseliot> no?
[14:58] <Keybuk> so it ends up in a screwy situation
[14:58] <mathiaz> pitti: http://paste.ubuntu.com/344753/ <- these are supposed to go away in lucid right?
[14:58] <pitti> mathiaz: maybe it was an upgrade from a very early lucid snapshot?
[14:59] <tseliot> Keybuk: are you saying that it should use VT_WAITACTIVE instead?
[14:59] <stgraber> Keybuk: Is it possible something in the new mountall breaks LTSP boot ?
[14:59] <Keybuk> tseliot: a lot of things need to change
[14:59] <mathiaz> pitti: I don't think so - they're generated daily with vmbuilder
[14:59] <tseliot> to:-/
[14:59] <Keybuk> tseliot: needs to use the terminal decide rather than the console device for the setup
[14:59] <pitti> mathiaz: is that a server or desktop install?
[14:59] <Keybuk> needs to wait for the vt to be active
[14:59] <Keybuk> the drm renderer needs to not default to is_active = TRUE :p
[15:00] <mathiaz> pitti: server. ha - it's required by landscape-client
[15:00] <pitti> mathiaz: right, I discussed that with the landscape guys at UDS
[15:00] <mathiaz> pitti: http://paste.ubuntu.com/344757/
[15:00] <tseliot> Keybuk: are you or upstream going to work on it?
[15:00] <pitti> it's not used for any automatic data collection right now, just to have it
[15:00] <pitti> mathiaz: so it can effortlessly be replaced by an udev dump and DMI data
[15:01] <Keybuk> tseliot: I think halflife is going to do it
[15:01] <Keybuk> halfline even
[15:01] <mathiaz> pitti: ok - so the landscape knows what needs to be done
[15:01] <tseliot> Keybuk: yes, halflife is a game ;)
[15:05] <Keybuk> tseliot: http://bugs.freedesktop.org/show_bug.cgi?id=25749
[15:09] <tseliot> Keybuk: it's good to see that finally we know what's going on
[15:12] <Keybuk> tseliot: a quick fix would obviously be just to run plymouth and X on tty1 :p
[15:13] <pitti> oh,  I'd love to kill that hackish gdm patch to run X on vt7
[15:14] <Keybuk> pitti: we're actually not using it
[15:14] <Keybuk> well, sorry
[15:14] <Keybuk> we're using it if you don't have plymouth
[15:14] <Keybuk> which I guess is the default right now <g>
[15:14] <Keybuk> but when you do have plymouth we're using a different patch
[15:15] <Keybuk> which starts X "on the current vt"
[15:15] <tseliot> Keybuk: maybe we could use a spambot who can change the documentation regular expressiond and tell everyone not to to use ctrl+alt+f1 anymore to get to the command line :-P
[15:15] <tseliot> expressions
[15:17] <tseliot> Keybuk: and the current vt happens to be vt7 right?
[15:17] <Keybuk> tseliot: well, ish ;)
[15:18] <tseliot> ok, let's not be too specific: tty0
[15:18] <tseliot> ;)
[15:20] <Keybuk> lol
[15:26] <stgraber> Keybuk: for mountall weirdness debugging (as in LTSP), you still need: mountall --debug ?
[15:28] <Keybuk> yes
[15:29] <stgraber> Keybuk: http://pastebin.com/f1aabfe37
[15:30] <stgraber> Keybuk: line 311 might be interesting btw
[15:32] <Keybuk> stgraber: don't suppose you can install the previous mountall on there and get me --debug output to compare?
[15:33] <ion> How nice, the apt update broke aptitude. :-)
[15:33] <stgraber> Keybuk: btw, I just started with mountall as --debug (but still in daemon and called by upstart), I now get that "Assertion failed" at the end and then "mountall main process (390) killed by ABRT signal"
[15:33] <stgraber> and I'm stuck there
[15:34] <stgraber> I'll get the old mountall from LP and install it, won't be long
[15:39] <ttx> cjwatson: about usb network adapters support in installer, again -- Apparently most hardware now uses the asix minimodule. The ones I bought for UEC testing are "0b95:1780 ASIX Electronics Corp. AX88178" and don't appear to be supported right now
[15:39] <ttx> cjwatson: do you think it's an option to also support the asix minimodule ?
[15:40] <Keybuk> ttx: I suspect cjwatson is deep into the early christmas cheer, and you'll have more luck next year :p
[15:40] <ttx> bah
[15:40] <ttx> Keybuk: thanks for the tip
[15:40] <tseliot> :-)
[15:40] <stgraber> Keybuk: http://pastebin.com/f7949c1a9
[15:41] <ttx> that must be what they all call "holidays"
[15:41] <Keybuk> stgraber: great! *hauls our mentaldiff*
[15:45] <Keybuk> stgraber: oh, that's interesting
[15:49] <hifi> aptitude broke down, apt-get works: http://pastey.net/130533-1p4p
[15:49] <stgraber> Keybuk: btw, I just had to revert initramfs-tools too as otherwise it'd still hang even with the older mountall
[16:16] <ara> tseliot, felicitazioni!
[16:16] <tseliot> ara: grazie :-)
[16:24] <pitti> Riddell: if you accept approved SRUs, can you please use sru-accept.py from ubuntu-archive-tools? If you use the queuediff tool (also there), this will spit out the exact command line for this, too (package name, bug #s, etc.)
[16:24] <pitti> sru-accept.py takes care of the tags, subscriptions, and the call for testing with some useful links
[16:25] <Riddell> pitti: can do, I don't think I knew about that, is it on ArchiveAdministration?
[16:25] <pitti> Riddell: no, it's not right now (it's not a general archive admin task)
[16:31] <LaserJock> persia: ping
[16:31]  * ScottK waves to LaserJock
[16:31] <LaserJock> hi ScottK
[16:32] <persia> LaserJock: ?
[16:32] <ScottK> pitti: I didn't know about queuediff giving you the sru-accept command.  That's nice.
[16:34] <LaserJock> persia: just reading the DMB email, there was an item (I think yours) about naming for the specialist teams
[16:34] <LaserJock> persia: in the email it says also MOTU, but is MOTU considered a specialist team now?
[16:34] <persia> LaserJock: Well, except that "specialist" and "MOTU" don't quite match for most sane semantic matrices.
[16:35] <persia> So it was suggested to use "Ubuntu Developer (delegated teams)" to cover both cases.
[16:35] <persia> Err, "Ubuntu Developer (from delegated team)".  Oops.
[16:37] <Keybuk> stgraber: still about?
[16:39] <LaserJock> persia: why is the distinction needed?
[16:39] <LaserJock> just plain Ubuntu Developer doesn't work?
[16:40] <persia> Because there are also other classes of "Ubuntu Developer", like "per-package uploader", "contributing developer", "prospective developer".
[16:41] <persia> It doesn't actually mean much outside the context of the version of the page I'm drafting :)
[16:41]  * persia will try to pubish RSN, to reduce overall confusion
[16:44] <LaserJock> ok
[16:44] <LaserJock> I just wondered if MOTU was considered a specialist team
[16:45] <persia> I certainly don't think that makes sense, which is part of why I asked the question.
[16:45] <LaserJock> since that seems like the opposite of my understanding of the meaning
[16:45] <persia> Indeed :)
[16:45] <dmb> i see i'm very popular here
[16:45] <persia> dmb: Overlap with "Developer Membership Board"
[16:45] <dmb> :P
[16:47] <dmb> i still think i'm quite popular :)
[16:48]  * Keybuk remembers when we had someone on the channel called "spec" :)
[17:03] <ttx> pitti: before leaving, could you trigger a server ISO respin ?
[17:04] <ttx> or slangasek ^
[17:05] <maco> asac: is NM still expected to not-manage any interfaces that are configured in /etc/network/interfaces?
[17:07] <asac> maco: yes
[17:07] <RoAkSoAx> Keybuk, i was wondering how out-of-date is the merges.ubuntu.com/universe.html is?
[17:07] <asac> maco: if you run it with managed=false  that is
[17:08] <asac> in /etc/NetworkManager/nm-system-settings.conf
[17:08] <maco> asac: so its not *just* dependent upon the interfaces file, then?
[17:09] <asac> maco: not sure what you mean
[17:10] <asac> if you have an iface configured in interfaces ... and have NM in managed=false mode
[17:10] <asac> then its not managed
[17:10] <maco> asac: ok then i had it wrong :)
[17:10] <maco> thanks
[17:10] <asac> maco: managed=true is good :)
[17:10] <asac> if it has bugs, file them ;)
[17:10] <asac> and yes, odd stuff isnt supported yet.
[17:11] <maco> nah, i thought i only had to change the interfaces file to change whether nm would let me ifup or not
[17:11] <Keybuk> RoAkSoAx: weeks
[17:11] <maco> asac: well wstephenson says i should show you line 11 of http://paste.ubuntu.com/344828/
[17:12] <ttx> RoAkSoAx: it's an evil plan to move everyone to bzr merge-package
[17:12] <maco> asac: trying to figure out why knm thinks a connection that worked fine before is now an invalid connection
[17:12] <asac> maco: how does interfaces look like (remove the password)
[17:12] <RoAkSoAx> Keybuk, is it going to be updated anytime soon?
[17:13] <asac> maco: Dec 20 16:52:40 betty NetworkManager:    SCPluginIfupdown: management mode: unmanaged
[17:13] <asac> so you hvae managed=false
[17:13] <Keybuk> RoAkSoAx: no
[17:14] <RoAkSoAx> Keybuk, ok thanks :) bzr merge-package it is then :)
[17:14] <Keybuk> (MoM is having major issues with v3 format Debian source packages
[17:14] <Keybuk>  particuarly those that use quilt
[17:14] <Keybuk>  and nobody has any time to work on it)
[17:15] <maco> asac: ok. ooooooo wait now i think i get what youre saying. if that is managed=true THEN "is it configured in /etc/network/interfaces?" becomes relevant, but if its false, then itll *always* manage the devices?
[17:15] <asac> maco: almost correct ;) ...
[17:15] <asac> if managed=false -> any iface mentioned in interfaces is blacklisted, e.g. not managed
[17:16] <maco> ok thats not what its doing
[17:16] <asac> if managed=true -> configuration is parsed from interfaces and used as a system connection
[17:16] <asac> maco: i need to see the interfaces.
[17:16] <maco> managed=false but its still managing wlan0 such that i cannot ifup until i stop network-manager
[17:16] <asac> could be its choking because it has bad formatted parts or something
[17:16] <maco> does it dislike comments?
[17:17] <asac> maybe
[17:17] <asac> could be a bug
[17:17] <highvoltage> Keybuk: are there any bugs filed?
[17:17] <Keybuk> highvoltage: how would that help?
[17:17] <asac> maco: play around. it should support wpa-supplicant configs quite well ...
[17:17] <asac> or paste your interfaces ;)
[17:17] <maco> how about i email you my interfaces? :P
[17:17] <asac> maco: i guess you dont have key-mgmt
[17:18] <asac> ?
[17:18] <asac> or do you have that?
[17:18] <maco> i dont know what key-mgmt is, so im gonna guess no
[17:18] <asac> heh
[17:18] <asac> maco: try to add wpa-key-mgmt WPA-PSK
[17:19] <maco> where?
[17:19] <asac> maco: you have a wpa-psk line? and a wpa-ssid?
[17:19] <maco> yes
[17:19] <asac> just below one of those
[17:19] <asac> or above ;)
[17:19] <highvoltage> Keybuk: just interested to see what the issues are
[17:19] <Keybuk> highvoltage: I don't know what the issues are
[17:20] <Keybuk> not having time to work on it includes not having time to investigate
[17:20] <highvoltage> ouch
[17:22] <asac> maco: so now it works? ;)
[17:22] <maco> lemme restart nm and see what happens
[17:22] <asac> yeah. the error should go away
[17:22] <LaserJock> Keybuk: was the status of MoM announced on -devel or -devel-announce at some point?
[17:23] <asac> its arguably a bug that the blacklisting fails if the config is not complete enough
[17:24] <Keybuk> LaserJock: probably not
[17:24] <LaserJock> I've been pointing people to MoM when they ask about how to help with merges :(
[17:25] <maco> asac: yep, that works. i can ifup without killing nm now
[17:27] <Keybuk> LaserJock: you should have been pointing them to james_w's work
[17:27] <mpt> rmcbride, are you intending to use the "metadata" tag for other Ubuntu One bug reports?
[17:27] <Keybuk> bzr merge-package is much easier
[17:28] <rmcbride> mpt: we had been using it to track issues where we felt that metadata corruption or versioning might be an issue. Is this a problem?
[17:28] <LaserJock> well, i don't know how to use james_w's stuff yet so I wasn't going to put it on others
[17:28] <mpt> rmcbride, I ask because I was using it for package metadata problems: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=metadata
[17:28] <ScottK> Keybuk: We'd need an associated list of things needing merging too.
[17:28] <LaserJock> I *thought* MoM was the "official" source for merging
[17:28] <rmcbride> mpt: OK. We can discontinue using it for that purpose. Perhaps u1meta or something. I'll bring it up to the team and get a concensus for a different tag
[17:29] <Keybuk> LaserJock: how to use it *has* been sent to -devel or -devel-announce ;)
[17:29] <mpt> rmcbride, thank you, and sorry for the bother
[17:29] <rmcbride> mpt: no bother at all.
[17:29] <Keybuk> ScottK: such a thing should be based on the bzr imports though
[17:29] <Keybuk> basically it's a "for PACKAGE in *; do bzr missing" no ?
[17:29] <asac> maco: maybe file a bug ;) "blacklisting of ifupdown interfaces with incomplete config broken" ...
[17:30] <maco> :P
[17:30] <maco> sorry!
[17:30] <LaserJock> Keybuk: right, there was some info that I could never get to work
[17:30] <maco> thanks for the help
[17:30] <asac> maco: you can even switch to managed=true ;)
[17:30] <asac> and then NM honours those settings
[17:30] <LaserJock> Keybuk: but perhaps the TB should make some announcement or something if MoM is going to be official deprecated
[17:31] <Keybuk> LaserJock: what has the TB got to do with anything?
[17:31] <LaserJock> well, I just assumed that they would be a good body to say "heah, we're not going to use MoM anymore"
[17:31] <asac> maco: enjoy
[17:31] <maco> asac: am a bit confused as to why wpa-key-mgmt doesnt appear in the interfaces or wpa_supplicant manpages
[17:31] <ScottK> Keybuk: Certainly a list should be based on the bzr imports, but in order to switch to this work flow, we'd need that.
[17:32] <ScottK> It's a bit undiscoverable otherwise.
[17:32] <Keybuk> bzr co lp:ubuntu/$PKG; cd $PKG; bzr missing --theirs-only lp:debian/$PKG
[17:32] <Keybuk> ;)
[17:32] <Keybuk> ScottK: so get to it! :p
[17:32] <Keybuk> LaserJock: the TB never said to use MoM in the first place
[17:32] <asac> maco: not sure if the man pages show any config. checkout /usr/share/doc/wpasupplicant/README.modes.gz
[17:32] <ScottK> Keybuk: I certainly don't have enough familiarity with the new tools to work it out.
[17:32] <LaserJock> I suppose, but it's definately become the canonical source for merges
[17:33] <maco> asac: ok thanks
[17:33] <asac> maco: i think its arguably a bug in NM to require it. its guessable from the wpa-psk setting (so is kind of redundant)
[17:33] <Keybuk> LaserJock: feel free to help fix MoM if you like it :p
[17:33] <LaserJock> it's less than helpful when something like merges.ubuntu.com just becomes unreliable
[17:33] <asac> maco: so even a second bug here ;)
[17:34] <LaserJock> I personally don't care too much about MoM itself, I rarely used it
[17:34] <LaserJock> but I think it's helpful to be able to point people to merges.ubuntu.com and have it be reliable
[17:34] <maco> asac: what im getting is "i owe asac a beer next uds for annoying him with pebkac"
[17:34] <Keybuk> LaserJock: if you think that's useful, help make it reliable
[17:34] <asac> hehe. beer is always good ;)
[17:35] <asac> thx
[17:35] <LaserJock> Keybuk: I have no access to merges.ubuntu.com
[17:35] <ScottK> LaserJock: Sounds like we're back to the rationale for DaD
[17:35] <Keybuk> LaserJock: you don't need it, you have the source code
[17:36] <LaserJock> and I generally think it's the responsibility of the people who put up merges.ubuntu.com to maintain it
[17:36] <Keybuk> that would be me
[17:36] <Keybuk> and I've been trying to get someone else to maintain it for the best part of five years
[17:36] <Keybuk> and since nobody else wants to
[17:36] <Keybuk> and since I no longer have any time to do it myself
[17:36] <Keybuk> that's why it's fallen over
[17:36] <LaserJock> so maybe you should talk to your boss about it?
[17:37] <Keybuk> what makes you think I haven't? :)
[17:37] <ScottK> Keybuk: Does anyone else have rights to commit updates to the public site for m.u.c?
[17:37] <asac> first you need updates. deploying them doesnt feel like a blocker
[17:37] <Keybuk> ScottK: ubuntu-core-dev iirc
[17:37] <LaserJock> I mean, I don't care if you put up docs on using bzr or whatever
[17:38] <LaserJock> I just think it's difficult if tools people rely on become unreliable without any real notice or replacement
[17:38] <Keybuk> LaserJock: UDD is the future of this stuff
[17:38] <Keybuk> we've been pushing everyone to use that this cycle
[17:38] <ion> keybuk: It might be a good idea to put a huge banner saying “i’m broken kthxbye” to merges.ubuntu.com.
[17:38] <LaserJock> future sure
[17:38] <Keybuk> ion: I did, people whinged
[17:38] <LaserJock> but as ScottK points out
[17:38] <Keybuk> (in fact, I simply took it down)
[17:38] <LaserJock> we don't have a list of what to merge
[17:39] <Keybuk> SO WRITE ONE
[17:39] <Keybuk> sheesh
[17:39] <LaserJock> why would I?
[17:39] <Keybuk> because you seem to be upset about the lack of ione
[17:39] <elmo> LaserJock: why should Scott?
[17:39] <LaserJock> elmo: because he was maintaining merges.ubuntu.com
[17:39] <Keybuk> so?
[17:39] <elmo> LaserJock: and therefore he's obligated to evermore?
[17:39] <Keybuk> that doesn't mean I have anything to do with UDD
[17:39] <LaserJock> elmo: no, but he *is* obligated to make sure something gets handed over or something
[17:39] <elmo> LaserJock: no, he's not
[17:40] <elmo> LaserJock: unless you're signing his pay cheque I mean.  he ran a service.  he no longer has time to run the service.  if that bothers you, step up and help get it fixed
[17:40] <elmo> don't try and bully him into doing something about it
[17:40] <LaserJock> so people can just drop core services without notice or replacement and expect everybody else to pick up the pieces?
[17:40] <Keybuk> yesx
[17:40] <Keybuk> that's basically the open source way ;)
[17:40] <elmo> LaserJock: yes.  it's called being a volunteer
[17:41] <Keybuk> when one maintainer has no longer got any time, he abandons the projetc
[17:41] <Keybuk> but it was open source
[17:41] <Keybuk> so another maintainer can step up if they care about it
[17:41] <Keybuk> projects that nobody cares about die, but that's ok too
[17:41] <LaserJock> elmo: no, that's being a jerk to the people who relied on that service
[17:41] <elmo> LaserJock: sorry, but I think you're the one being a jerk
[17:41] <elmo> LaserJock: you don't get to make demands on people's time
[17:41]  * maco nods
[17:42] <LaserJock> I'm not making demands
[17:42] <Keybuk> you certainly don't get to make demands on people's time if you're unwilling to help
[17:42] <elmo> LaserJock: if Scott was actively blocking others from fixing this, I'd be in total agreement with you
[17:42] <elmo> but he's not
[17:42] <LaserJock> I'm saying he could of at least arranged with james_w to put up info on bzr merging or something
[17:42] <james_w> we discussed it
[17:42] <Keybuk> I suggested it to james_w
[17:42] <james_w> I agreed to provide a merge proposal to MoM to point people to bzr where appropriate
[17:42] <elmo> LaserJock: dude, you're still not getting this.  stop saying what Scott should or shouldn't have done.  it's not your call.  he's done what he's done.  be thankful for that.  if you want things to improve, you need to step up or convince someone who isn't Scott to step up
[17:43] <Keybuk> I actually suggested that if the code is in UDD, MoM would ignore it and just put instructions in the REPORT file
[17:43] <Keybuk> nobody's written that code
[17:43] <james_w> or replace it with something based entirely on bzr
[17:43] <james_w> however, I've not had time yet
[17:43] <Keybuk> LaserJock: if you want to write that code, go right ahead!
[17:43] <james_w> help would be welcome, and I can point you to the code you need
[17:44] <james_w> I'm not going to do it at least until I've worked out how to stop DoSing codehosting though
[17:44] <ScottK> elmo: I see your point, OTOH, if Canonical is going to suddenly abandon tools upon which the community depends, that's not so great either.
[17:44] <elmo> james_w: thank you ;-)
[17:44] <LaserJock> ScottK: that was my point
[17:44] <Keybuk> what's Canonical got to do with it?
[17:44] <Keybuk> Canonical is just one member of the Ubuntu community
[17:44] <Keybuk> as are its employees, just individual members of the Ubuntu community
[17:45] <LaserJock> MoM was Canonical's project as far as anybody knew
[17:45] <Keybuk> like any other member, its priorities can change
[17:45] <LaserJock> which was why it wasn't open sourced at the beginning
[17:45] <Keybuk> LaserJock: that doesn't mean nobody else can't take it over
[17:45] <Keybuk> it's been open sourced for years now
[17:45] <LaserJock> sure, sure, I'm not saying it can't be
[17:45] <LaserJock> but there aren't that many people with the skills needed
[17:45] <LaserJock> I certainly can't
[17:45] <Keybuk> really?
[17:45] <Keybuk> you don't know Python?
[17:45] <LaserJock> very little
[17:45] <ScottK> Keybuk: That's where the step back gracefully part of the CoC comes in.  "Sorry it's broke, good luck" doesn't qualify IMO.
[17:45] <Keybuk> there's nobody in the entire ubuntu community who knows Python?
[17:46] <Keybuk> I find that very hard to believe
[17:46] <LaserJock> there are for sure
[17:46] <LaserJock> but obviously none have stepped up
[17:46] <Keybuk> ScottK: you've clearly not read that
[17:46] <LaserJock> so MoM should be gracefully retired it seems
[17:46] <Keybuk> I've told people that I have no time for MoM
[17:46] <Keybuk> repeatedly
[17:46] <Keybuk> over and over again
[17:46] <Keybuk> and I've ensured that others can pick it up
[17:46] <elmo> ScottK: that's part of the leadership part of the CoC
[17:47] <elmo> ScottK: I think it's pretty disingenuous to compare developing a service to leadership
[17:47] <Keybuk> (the source is open, the entire core dev team have commit rights, and any commits anyone makes are automatically deployed in service)
[17:47] <ScottK> elmo: Even if it's not contractually relevant, I think the concept is similar.
[17:47] <ScottK> BTW, I didn't know commits were automatically deployed until now.
[17:47] <LaserJock> me neither
[17:48] <james_w> LaserJock: would you like to send a mail to ubuntu-devel asking for someone with some Python knowledge to help make the change?
[17:48] <LaserJock> I'm not sure why I should do it but I can if you'd like
[17:48] <LaserJock> I hardly ever use MoM
[17:48] <LaserJock> I don't know what's broken, what's not, etc.
[17:48] <ScottK> "I can push fixes and they work right away" is a lot more motivational than "Maybe it'll get reviewed and published someday"
[17:48] <asac> MoM is useless atm? or just partially broken?
[17:49] <ScottK> Not updating reliably I think.
[17:49] <Keybuk> not updating
[17:49] <LaserJock> like I said, I'm not against MoM going away if it's not working and people don't have time to maintain it
[17:49] <Keybuk> when MoM hits a problem, it falls over
[17:49] <Keybuk> and doesn't continue
[17:49] <ScottK> Keybuk: Are there error logs somewhere public?
[17:49] <Keybuk> so if you have a problem package, that package will block updates until whatever MoM issue is fixed
[17:49] <LaserJock> but it should be announced and it would be very helpful if some sort of transition was made for merges.ubuntu.com
[17:50] <Keybuk> ScottK: no, but you can run it on your own
[17:50] <elmo> LaserJock: then announce it
[17:50] <elmo> LaserJock: stop telling other people what they should or shouldn't have done
[17:50] <elmo> LaserJock: it's really quite odious
[17:50] <LaserJock> yes, as odious as telling me that I have to use bzr to merge or some such
[17:51] <james_w> you don't have to
[17:51] <Keybuk> you don't have to use anything
[17:51] <Keybuk> you can merge with pen and paper if you like
[17:51] <LaserJock> I'm saying there are expectations coming from the community for a tool like merges.ubuntu.com
[17:51] <elmo> LaserJock: good thing no one's doing that then !
[17:51] <ScottK> LaserJock: Don't worry, we've been promised that we can continue to use traditional development tools and ignore UDD if we want.
[17:52] <LaserJock> ok, look, I was not meaning to start a ruckus here. I was just wondering what the status of merges.ubuntu.com was considering that I've been pointing people there
[17:52] <LaserJock> we have the status, I can send an announcement email
[17:53] <maxb> james_w: Hi. I see you recently fixed the hardcoded 'james-w@'s in the UDD import-scripts - I noticed there is still one that got missed, though - I wasn't sure if you'd want a MP for something that trivial, or if you'd prefer to just fix it yourself?
[17:53] <asac> yeah. also i like the idea to add a warning to the MoM pages that the serice is currently unreliable and they should rather do A, B, C
[17:53] <stgraber> Keybuk: back from lunch, so I'm around now
[17:53] <james_w> maxb: I think I caught that one. Maybe I didn't push, sorry.
[17:53] <Keybuk> stgraber: still tracking down this mountall issue
[17:53] <maxb> james_w: check_marks.py, right?
[17:53] <Keybuk> stgraber: thought I might have a fix, but I just noticed something else in the log, so I'm not so sure
[17:53] <james_w> maxb: oh, ok
[17:54] <james_w> maxb: I'll grep now :-)
[17:54] <james_w> thanks maxb
[17:57] <smoser> anyone have a good idea on how to identify partitions in a xen guest? explicitly, i'd like to go through existing partitions (that show up in /proc/partitions) and figure out what is on them , as in if it is a swap partition or has filesystem data
[17:58] <Keybuk> blkid ?
[17:58] <smoser> i can't rely on the partiion type (ie, per fdisk -l) because xen block devices dont necisarrily have a partition table
[17:58] <smoser> Keybuk, rock. thank you.
[18:00] <RoAkSoAx> james_w, is it possible to do different kinds of diffs when using bzr merge-package, such as diff between new debian and new ubuntu and things like that?
[18:00] <james_w> RoAkSoAx: yes
[18:00] <james_w> you can use options to diff to do it
[18:00] <james_w> bzr diff --old lp:debian/sid/package for what you ask for
[18:01] <RoAkSoAx> james_w, awesome :). Btw.. is it detailed in any wikipage?
[18:02] <james_w> RoAkSoAx: no, but good point :-)
[18:02] <james_w> would you like to add a section to the end of https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging ?
[18:02] <RoAkSoAx> james_w, sure :)
[18:02] <james_w> thanks
[18:03] <fbond_> Hi.  I have a build script that calls apt-get install upstart upstart-compat-sysv.  It's failing because upstart-compat-sysv is a virtual package provided by upstart.  But this same script worked fine twelve days ago.  I'd like to identify what changed that would cause the failure to come up now.  Any ideas?
[18:03] <stgraber> Keybuk: ping me if you need more info or have something that I can test
[18:03] <fbond_> (Obviously, the problem is easy enough to correct, I just want to understand what's going on.)
[18:03] <fbond_> I'm using karmic, FWIW.
[18:04] <Keybuk> stgraber: the basic problem is that it's trying to remount /rofs ;)
[18:04] <ScottK> Adri2000: Do you still have any interest/time to work on MoM?  I can't spend a lot of time on development, but I could commit changes.
[18:04] <stgraber> Keybuk: hmm, doesn't seem like a good idea ;)
[18:06] <ion> fbond: It’s not the job of the build script to install build dependencies. Build deps should be listed in the control file. And as you said, upstart-compat-sysv is now provided by the upstart package.
[18:07] <fbond_> ion: Sorry, not a packaging script.  This is a script I'm using to build a disk image.
[18:08] <fbond> ion: I'm really just wondering why it worked less than two weeks ago but does not work anymore.
[18:10] <Keybuk> stgraber: oh, hmm, I see
[18:16] <Keybuk> I've found the change that did it ;)
[18:18] <LaserJock> james_w: what's a good URL to point people to regarding merging with bzr?
[18:18] <james_w> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
[18:20] <Adri2000> ScottK: no, sorry. currently I don't have enough time to do the debian/ubuntu packaging work I'd like to do, so no time to spend on developing MoM :(
[18:21] <ScottK> OK.  Thanks Adri2000.
[18:21] <Keybuk> stgraber: ok, around now?  would like you to test this if you can
[18:24] <stgraber> Keybuk: sure
[18:25] <Keybuk> stgraber: are you on i386?
[18:25] <LaserJock> james_w: ok, email sent. if somebody can moderate it on -announce it'll go there too
[18:25] <stgraber> Keybuk: yep
[18:26] <Keybuk> can you upgrade back to current mountall in archive, initramfs, etc.
[18:26] <Keybuk> then grab http://people.canonical.com/~scott/tmp/mountall - overwriting the binary in /sbin
[18:26] <Keybuk> and try with that
[18:26] <Keybuk> --debug output greatly appreciated
[18:32] <arand> ion: hifi: I put down the aptitude crash there as Bug #499543 sorry if duped..
[18:33] <hifi> oh, ion reported it too :)
[18:33] <hifi> I didn't put a report in yet, so no dupe from me
[18:33] <ion> arand: Thanks. I didn’t get around to reporting it yet.
[18:33] <ion> hifi: I didn’t report it, just mentioned it here. :-P
[18:33] <hifi> same here :p
[18:33] <hifi> though apt-get works fine if you didn't know
[18:34] <ion> Yeah, it does.
[18:34] <arand> mentioned that on the bug
[18:40] <stgraber> Keybuk: it worked !!
[18:40] <stgraber> Keybuk: want the debug output anyway ?
[18:40] <Keybuk> yes please
[18:43] <stgraber> Keybuk: http://pastebin.com/f2ec068e6
[18:45] <stgraber> now that it boots, let's send that through bootchart ;) A thin client can boot in a lot less than 10s for sure ! (reading a compressed minimal root system + minimal DM can't take long to load, only slow part is the DHCP request)
[18:46] <Keybuk> ok cool
[18:46] <Keybuk> that looks right
[18:47] <stgraber> thanks for giving me a booting thin client again :)
[18:48] <Keybuk> the same bug prevented the Live CD from booting too :p
[18:49] <fbond> ion: FWIW, I figured out that APT doesn't seem to care about installing both upstart and upstart-compat-sysv with only one version of upstart in the repos.  As soon as there is more than one version, it decides it's an error.
[18:49] <fbond> Not sure if that should be reported as a bug (shouldn't it be an error in both cases?).
[18:50] <UnixDawg> hey guys we have a issue in the apache2 package
[18:50] <UnixDawg> it seems php redirects are not working
[19:52] <Keybuk> james_w: argh!
[19:52] <Keybuk> I've just had another instance where the package importer has stamped over my branch
[19:53] <Keybuk> james_w: I'm starting to believe that it isn't safe to use these lp:ubuntu/* branches after all
[20:02] <james_w> Keybuk: which package?
[20:03] <Keybuk> james_w: plymouth
[20:04] <james_w> another one you push --overwrote?
[20:04] <Keybuk> yes
[20:04] <james_w> ok
[20:04] <james_w> won't happen again like that
[20:05] <Keybuk> ok
[20:05] <Keybuk> what about the cases where the branch got removed and hasn't come back?
[20:05] <Keybuk> e.g. ureadahead
[20:05] <Keybuk> (I was able to push plymouth over the top again)
[20:05] <james_w> I thought you had found ureadahead?
[20:06] <Keybuk> I have a working tree
[20:06] <Keybuk> but now there's nowhere to push to
[20:07] <alex-weej> since we moved to xplash /etc/gdm/Init/Default doesn't seem to run (or my xcalib line doesn't run) -- is there some way i can configure xsplash to run xcalib as soon as it starts X?
[20:07] <james_w> Keybuk: ah, ok
[20:07] <james_w> Keybuk: push it somewhere and send me the URL
[20:07] <slangasek> Keybuk: so on bug #493480, now I understand why mountall is unhappy but I still don't know how to make it happy.  The crypt-tmp filesystem has to be mounted somewhere in order to chmod 1777 the root directory; I realize now that /tmp is a bad place for this regardless because it's racy, but do you have any thoughts on a more appropriate place to do this?
[20:08] <Keybuk> slangasek: /var/lib/cryptsetup/somewhere ?
[20:08] <Keybuk> (that's how ureadahead mounts debugfs during the boot)
[20:08] <Keybuk> james_w: lp:~ubuntu-core-dev/ubuntu/lucid/ureadahead/lucid
[20:08] <slangasek> Keybuk: is there a sane way to do that without blocking on local-filesystems?
[20:09] <slangasek> hmm, /var/run/cryptsetup might do
[20:09] <Keybuk> slangasek: you could use local-filesystems and /var/run
[20:09] <slangasek> ack
[20:09] <slangasek> virtual-filesystems, I guess
[20:09] <cjwatson> Mamarok: I asked doko to look at it; I don't have any more recent status
[20:09] <Keybuk> err
[20:09] <Keybuk> yes
[20:09] <Keybuk> virtual
[20:09] <Keybuk> those things
[20:09] <Keybuk> ;)
[20:09] <Keybuk> mountall always defers to someone else running mount
[20:09] <slangasek> Keybuk: thanks, I'll get this cleared out ASAP then
[20:10] <Keybuk> if you mount something on a mount point it was expecting to, it assumes you know better
[20:10] <slangasek> heh
[20:10] <slangasek> what a silly thing to assume ;)
[20:10] <Keybuk> it kinda has to behave that way
[20:10] <Keybuk> since having mountall rearrange all the initramfs mounts would go badly
[20:10] <Keybuk> "but that UUID shouldn't be your root" etc.
[20:15]  * Keybuk is being nice with bugs today
[20:15] <Keybuk> I'm not marking a bug as invalid because mountall can't mount /proc/bus/usb
[20:16] <Keybuk> because the bug description has all the other problems along the way :p
[20:16] <Keybuk> once the user confirms that mountall fails to mount /proc/bus/usb *then carries on anyway*
[20:16] <Keybuk> then I'll mark it Invalid <g>
[20:18] <slangasek> heh
[20:19] <ion> keybuk: If we’re talking about the same bug report, his problem was that lucid’s CONFIG_USB_DEVICEFS was disabled in lucid’s kernel.
[20:19] <Keybuk> but the guy with the patched kernel and patched mountall is having no love from me
[20:19] <Keybuk> ion: yes
[20:19] <Keybuk> but the fact mountall then goes into an infinite loop, and segfaults, is unrelated :p
[20:19] <Keybuk> 2.1 should fix that, then I'll mark the bug as invalid :p
[20:21] <slangasek> Keybuk: udev itself depends on virtual-filesystems, without which none of the events happen that start these other jobs... is it reasonable to leave the dependency on virtual-filesystems implicit?
[20:22] <Keybuk> slangasek: as long as there's a dependency on udev ;)
[20:22] <Keybuk> (which includes the events emitted by udev)
[20:22] <slangasek> ok, cool
[20:39] <alex-weej> does xsplash have a script it executes when starting X?
[20:39] <alex-weej> i need to run xcalib
[20:39] <Keybuk> xsplash doesn't start X
[20:40] <alex-weej> ok then why doesn't my xcalib line in /etc/gdm/Init/Default work anymore? :(
[20:40] <Keybuk> are you using auto-login?
[20:40] <alex-weej> yes
[20:40] <Keybuk> that's why
[20:40] <alex-weej> i want it to start waaaay before login
[20:40] <Keybuk> add it to /etc/gdm/PreSession/Default too
[20:40] <Keybuk> (assuming it's ok to run it twice)
[20:40] <alex-weej> yes it is
[20:41] <Keybuk> gdm only runs Init/Default when displaying a greeter
[20:41] <alex-weej> i see
[20:41] <alex-weej> thanks, let me try then, brb!
[20:42] <Keybuk> slangasek: could you spin me some new i386 live cd images?
[20:44] <alex-weej> Keybuk, thanks, that appears to work. xsplash still seems slightly off colour but that might just be my eyes :)
[20:45] <alex-weej> macbook displays are pretty bad with default CLUT :/
[20:45] <Keybuk> I didn't think we even started xsplash in lucid
[20:45] <alex-weej> oh?
[20:47] <alex-weej> does anyone have any ideas on how to support restoring backlight levels on boot? default full brightness burns my face and my screen...
[20:47] <Keybuk> alex-weej: probably better off discussing that upstream on the devkit list
[20:48]  * alex-weej is slightly confused as to whether devkit even exists anymore
[20:48] <Keybuk> it doesn't
[20:48] <Keybuk> but the ML still does
[20:49] <alex-weej> ok that sounds a bit like you're asking me to go and ask the hardware shop for a can of stripy paint and a long stand
[20:49] <alex-weej> :P
[20:50] <Keybuk> Bikeshed Painting Party!
[20:53] <Keybuk> slangasek, cjwatson: could you spin me some new i386 live cd images?
[20:53] <cjwatson> Keybuk: queued up
[20:54] <Keybuk> thx
[20:54] <fbond> What is the mechanism by which lo is brought up in karmic?  I.e. what calls ifup at boot time?
[20:54] <Keybuk> fbond: dark rites
[20:55] <fbond> Keybuk: I figured as much. ;)
[20:55] <fbond> Keybuk: Does upstart do it directly?
[20:55] <Keybuk> kernelinithasabuiltindevicethatittellsudevaboutwhichresultsinanupstarteventoverthebridgeandthenupstartcallsifupwhichbringsitup
[20:55] <Keybuk> yes, basically
[20:56] <fbond> Keybuk: I would expect to see this in an upstart job definition ... ?
[20:56] <Keybuk> /etc/init/network-interface.conf
[20:57] <ScottK> Keybuk: Do you recall: Is the main page for MoM generated from the merge-o-matic code or is it a static page?
[20:57] <Keybuk> it's a static page generated from the merge-o-matic code
[20:57] <ScottK> OK.  Thanks.
[20:57] <fbond> Keybuk: What package contains that file?
[20:58] <Keybuk> fbond: rather than hand you that fish, I will teach you about "dpkg -S FILENAME"
[20:59] <fbond> Keybuk: Well of course I already know that.  I just don't have a full karmic system and packages.ubuntu.com didn't seem to know about it.
[20:59] <fbond> (I'm missing that file in the stripped down system I have.)
[20:59] <fbond> But nevermind, so long as it is in a package I'll get install a full system and track it down.
[20:59] <Keybuk> it comes from ifupdown
[21:00] <slangasek> ...which is a dependency of "ubuntu-minimal", so s/stripped down/broken/, there
[21:00] <fbond> slangasek: s/stripped down/really stripped down/, maybe.
[21:01] <slangasek> by your own admission it's broken, I'm pointing at why :)
[21:02] <Keybuk> "I hacked off my foot, and now I can't walk"
[21:03] <fbond> No need to be dramatic, ubuntu-minimal depends on some things I don't need.  I'll consider adding it anyway.
[21:05] <Keybuk> fbond: the basic point of ubuntu-minimal is it's the bits we think everyone needs <g>
[21:05] <Tm_T> I wonder what those bits he doesn't need are
[21:05] <fbond> Keybuk: Yeah, this is a specialized live system that runs in memory.  I need it as small as possible.
[21:06] <Keybuk> fbond: what did you have to remove?
[21:06] <fbond> Well, APT, anyway.
[21:07] <fbond> I'll make a build with ubuntu-minimal and see if it makes the image a lot bigger.  My constraints have loosened over the years.
[21:08] <fbond> (I used to have to run on machines with 128 (256? don't remember) MB RAM.)
[21:08]  * ScottK ran a full desktop on 256 as recently as Hardy, so that's not very constraining.
[21:09] <fbond> ScottK: Right, but you weren't running entirely from RAM.
[21:09] <fbond> My root is a union mount with tmpfs R/W.
[21:09] <ScottK> fbond: True.
[21:09] <Keybuk> that's what the Live CD does
[21:10] <fbond> Keybuk: Oh, sorry, R/O portion of root is squashfs in memory.
[21:10] <fbond> The whole system is in memory.  It gets PXE booted.
[21:10] <Keybuk> that actually doesn't really make much difference
[21:10] <Keybuk> the majority of memory is page cache anyway
[21:10] <ScottK> slangasek: Could I trouble you to look at kdepim in binary New?  Riddell seems to be away from his computer and that's all that's between us and having KDE 4.2 beta 2 done on i386 (the New packages should be accepted into Main).
[21:10] <Keybuk> though I guess you'd need to tweak the kernel to not try and double-cache everything :p
[21:11] <cjwatson> the live CD did use to have trouble running in 256MB; I think it manages now
[21:11] <fbond> Keybuk: That would be good, agreed.  Not sure I follow why having the entire root fs in memory doesn't make a difference?
[21:11] <Keybuk> fbond: because, as I said, it tends to end up in memory anyway via the page cache
[21:12] <Keybuk> I did some math once
[21:12] <cjwatson> although the live CD at least *can* page things out, which a PXE-booted system like that can't
[21:12] <fbond> Keybuk: Right, but with a block device backing it the cache can be dropped when RAM gets low.
[21:12] <cjwatson> only once?
[21:12] <Keybuk> over half the contents of the live CD end up in memory
[21:12] <fbond> Keybuk: As an optimization, not as the storage mechanism.
[21:12] <fbond> It's only cache, right?
[21:13] <Keybuk> well
[21:13] <Keybuk> ish ;)
[21:13] <slangasek> ScottK: yep, I'll have a look in a couple minutes
[21:14] <ScottK> Thanks.
[21:14] <Keybuk> the kernel is like a hillbilly
[21:14] <Keybuk> it behaves in strange ways
[21:40] <slangasek> siretart: "the screen remains dark at this point" - that's not bug #496765, you have a separate plymouth or kernel bug
[21:40] <slangasek> siretart: bug #496765 is about the /text of the prompt/ not being displayed, not about a blank screen
[21:41] <siretart> slangasek: oh, interesting. maybe there is something very weird going on with cirrus graphics?
[21:41] <siretart> that's what qemu/kvm is emulating
[22:10] <slangasek> ScottK: "MoM is already irrelevant" - it may currently be /broken/, but there's nothing else that gives me a merge todo list
[22:10] <ScottK> slangasek: It's lacking a maintainer.
[22:10] <ScottK> So there is nothing that gives you a merge TODO list.
[22:11] <slangasek> yes, and this is a problem
[22:11] <ScottK> slangasek: Thanks for kdepim, BTW.
[22:11] <slangasek> sure
[22:11] <wgrant> Also, didn't MoM generate patches.ubuntu.com?
[22:11] <ScottK> lucas is up for adding that to his list, just it's non-trivial to do it.
[22:11] <ScottK> (at least as I understand it, he can speak for himself)
[22:17] <slangasek> Keybuk: "plymouthd; plymouth --show-splash" - doesn't work for me at all here under X?
[22:34] <Keybuk> slangasek: as root?
[22:34] <Keybuk> siretart: plymouth does not support cirrus graphics
[22:34] <Keybuk> since we don't have Kernel Mode Setting for cirrus graphics
[22:35] <slangasek> Keybuk: yes, when run as non-root it just says "must run as root"
[22:35] <Keybuk> slangasek: and when run as root?
[22:35] <slangasek> Keybuk: it displays nothing
[22:35] <Keybuk> that's weird
[22:35] <Keybuk> I get two X windows ;)
[22:35] <slangasek> I don't
[22:36] <Keybuk> does plymouthd segfault for you?
[22:36] <slangasek> no
[22:36] <Keybuk> you're on i915 aren't you?
[22:36] <slangasek> yes
[22:36] <Keybuk> weird
[22:36] <Keybuk> you export your $DISPLAY and stuff with sudo?
[22:36] <Keybuk> and check there's no plymouthd running from pre-X ?
[22:37] <slangasek> yes, yes
[22:37] <Keybuk> hmm
[22:38] <Keybuk> you have /lib/plymouth/x11.so ?
[22:38] <slangasek> Keybuk: no :)
[22:38] <Keybuk> err, is it in a sub-directory?
[22:38] <slangasek> /lib/plymouth/renderers/x11.so
[22:38] <Keybuk> right that's what I meant
[22:38] <slangasek> ok
[22:39] <Keybuk> huh
[22:39] <Keybuk> can you strace plymouthd
[22:39] <slangasek> sure
[22:39] <Keybuk> when you show-splash, does it at least try and dlopen that?
[22:40] <slangasek> nope
[22:40] <slangasek> er, yes
[22:40] <Keybuk> does the dlopen work?
[22:41] <slangasek> looks like it; it successfully loads all the lib dependencies
[22:41] <Keybuk> that was going to be my next question; did I forget to include a dep?
[22:41] <siretart> Keybuk: could plymouth have some way to check for the presence of KMS and just print some error message so that our users don't have to find this out themselves? - What does fedora do for cirrus graphics?
[22:41] <slangasek> Keybuk: ldd -d -r says it's clean
[22:41] <Keybuk> siretart: they fallback to the text backend
[22:41] <siretart> sounds reasonable
[22:42] <Keybuk> slangasek: hmm, the only reason I can see that the renderer can fail to open is if gtk_init fails
[22:42] <Keybuk> and that's if you have no valid $DISPLAY or $XAUTHORITY ?
[22:42] <Keybuk> sanity check: do you see other dlopen()s for different renderers afterwards?
[22:42] <slangasek> Keybuk: not for other renderers; there's a subsequent open of /lib/plymouth/details.so
[22:42] <Keybuk> huh
[22:43] <slangasek> running other X apps as root works
[22:43] <Keybuk> ohh
[22:43] <Keybuk> you don't have "splash" on your cmdline, do you? :p
[22:43] <slangasek> heh; I don't
[22:44] <slangasek> well, I was going to reboot shortly anyway, shall I do that now? :)
[22:44] <Keybuk> sure
[22:44] <Keybuk> (the x11 renderer should so ignore that)
[22:44] <Keybuk> siretart: we actually plan to fallback to vga16fb
[22:44] <Keybuk> but not done that yet
[22:44] <Keybuk> plymouth doesn't work in general right now
[22:45] <Keybuk> so it's not the right time to fiddle with the specifics of non-kms stuff
[22:45] <fbond> Keybuk: Would I be able to convince you that upstart should depend on ifupdown or (and I think this is better) upstart ships network-interface.conf and it is modified to use ifconfig directly rather than ifup?
[22:46] <Keybuk> fbond: no, absolutely not
[22:46] <Keybuk> ubuntu-minimal depends on ifupdown
[22:46] <Keybuk> upstart does not require you have networking
[22:46] <Keybuk> upstart doesn't require you even have AF_INET compiled into your kernel
[22:46] <fbond> Well, it won't boot the system without it (using the default config)...
[22:46] <Keybuk> yes it will
[22:46] <Keybuk> just fine
[22:46] <Keybuk> you just won't have networking
[22:47] <ScottK> slangasek: Could I have a new Kubuntu netbook for i386?  I think it will work now and I'd like to make sure I didn't miss anything.
[22:48] <fbond> Keybuk: http://launchpadlibrarian.net/36606433/upstart_0.6.3-10_0.6.3-11.diff.gz
[22:48] <Keybuk> fbond: slangasek did that
[22:48] <fbond> The reason I ask is because my system would not boot because there was no net-device-up event...
[22:49] <fbond> Keybuk: So that change will be reverted?
[22:49] <Keybuk> ask him :)
[22:49] <fbond> slangasek: ?
[22:49] <Keybuk> but since you're not using an Ubuntu system ...
[22:49] <Keybuk> (since we explicitly define Ubuntu systems as having ubuntu-minimal installed <g>)
[22:50] <fbond> Well, it occurs to me that using ifconfig instead also avoid breakage due to /etc/network/interfaces badness...
[22:50] <fbond> (I've read the relevant bugs and have seen that this is a problem for some users.)
[22:56] <fbond> Keybuk: BTW, it's easy enough to fix my system without that change, I only bring i up because I think in a perfect world, installing upstart with the default config would leave you with a system that upstart can boot successfully.
[22:57] <fbond> (So whether my system is technically "Ubuntu" is not relevant to my point. ;)
[22:59] <slangasek> Keybuk: ok, so how do I work around mountall blocking on my NFS mounts at boot time now?
[22:59] <slangasek> since that was one of the longer "reboots" I've had to do this week :)
[23:00] <slangasek> Keybuk, fbond: I'm still researching why the upstart change is reported to break runlevels for people who *don't* have missing packages; if I can figure that out, I'm not going to revert the upstart change only for a use case that we don't support
[23:03] <slangasek> ScottK: kubuntu-netbook respinning
[23:03] <ScottK> slangasek: Thanks.
[23:04] <slangasek> Keybuk: confirmed, plymouthd shows me X windows now when booting with 'splash' :)
[23:04] <lamont> sigh.  schroot seems to really hate armel, or vice versa
[23:04]  * lamont kills the build before it takes out a 3rd armel box
[23:07] <Lutin> asac: yes ?
[23:08] <slangasek> Keybuk: 'plymouth quit' kills X, though :)
[23:17] <fbond> Keybuk: If your curious, adding ubuntu-minimal to my system increased the chroot size by only 12M, and the squashfs image by only 4M.  That's small enough to justify including it.
[23:18] <fbond> So I'm officially supported again. ;)
[23:25] <Keybuk> slangasek: yeah, sometimes :p
[23:26] <Keybuk> slangasek: err, mountall shouldn't block
[23:27] <Keybuk> don't suppose you can run "sudo mountall --debug --no-events" for me?
[23:30] <slangasek> Keybuk: well, if I run it from a booted system, it appears to mount everything quite happily.  Let me work on reproducing this
[23:30] <Keybuk> --debug >/dev/mountall.log 2>&1 in the upstart job?
[23:30] <Keybuk> only NFS mounts under /usr and /var are waited for
[23:42] <Mamarok> cjwatson: thanks for looking into it :)
[23:55] <slangasek> pitti: cryptsetup reuploaded to karmic-proposed, with a more complete fix for bug #475936; would love to have that processed so we can close the books on this one