[00:39] <cjwatson> popey: it's not entirely uncommon, but it's nevertheless a misconfiguration
[00:40] <cjwatson> popey: I blogged about it a while back, although the specific circumstances were different - http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-06-21-grub2-boot-problems.html
[01:25] <TheMuso> infinity: Does the debdiff in this bug look sane to you? Looks ok to me, but a second opinion from someone with livecd-rootfs experience would be nice. I'm happy to handle the bzr update and upload. https://launchpad.net/bugs/960688
[01:26] <TheMuso> Asking you too because of your ARM work for livefs/pre-installed image stuff.
[01:27] <TheMuso> Or anybody else who has worked on the livefs stuff, opinions welcome.
[01:27] <infinity> TheMuso: Looking.
[01:27] <TheMuso> Thanks,.
[01:28] <infinity> TheMuso: The fix doesn't belong in livecd-rootfs, IMO.  I already fixed this once last cycle, something's gone wrong.
[01:28]  * infinity tries to remember what was wrong last time.
[01:29] <TheMuso> infinity: Ok, I suspected that this should be fixed elsewhere, thanks for confirming.
[01:33] <infinity> TheMuso: Oh, maybe I fixed it last cycle by making oem-config just use the regular slideshow, and someone unfixed that.  *trying to recall*
[01:34] <infinity>   * Allow fallback from oem-config-slideshow to ubiquity-slideshow for
[01:34] <infinity>     cases where the former doesn't exist.
[01:34]  * infinity looks.
[01:34] <infinity> TheMuso: Cause, in the ARM case, we don't actually want the oem-config slideshow, it's not an OEM install.
[01:34] <TheMuso> Right.
[01:34] <TheMuso> So its not a bug.
[01:35] <infinity> TheMuso: Well, it's a bug if the slideshow's not showing at all.
[01:35] <TheMuso> Right.
[01:38] <TheMuso> rsalveti: See above re your bug about the slideshow on arm pre-installed images.
[01:39] <infinity> TheMuso: Oh, I think stgraber may have broken this yesterday.  In a patch I reviewed.  That's embarassing.
[01:39] <TheMuso> heh ok. :)
[01:39] <infinity> Or not...
[01:39]  * infinity scratches his head.
[01:40] <rsalveti> infinity: slideshow is not showing at all
[01:40] <infinity> rsalveti: There's really no slideshow on ARM right now?
[01:40] <infinity> Jinx.
[01:40] <rsalveti> and there's not any oem specific thing at this slideshow
[01:40] <rsalveti> it's provided by ubiquity any way
[01:40] <infinity> rsalveti: It's mean to possibly have OEM-specific stuff, hence the fallback.
[01:40] <rsalveti> it's just enabled by default because the package is not isntalled by default at the pre-installed images
[01:40] <infinity> rsalveti: (I realise it mostly doesn't right now)
[01:40] <rsalveti> I just added both because during natty I believe we were using them
[01:41] <infinity> rsalveti: Trust me, this used to work properly not long ago, oem-config-slideshow* doesn't need to be there.
[01:41] <rsalveti> on oneiric I don't remember what happened
[01:41] <infinity> On oneiric, it uses ubiquity-slideshow.
[01:41] <infinity> Or are you saying that's not being installed either?
[01:41] <infinity> Cause that would be a seed issue.
[01:41] <rsalveti> infinity: yup, not even installed
[01:42] <infinity> It's in the live seed...
[01:42] <rsalveti> as livecd-rootfs requests oem-installer during the config step, I just added the slide show there
[01:42] <rsalveti> but as I said at the bug, might not be the right place, just don't know what would be the right one
[01:42] <rsalveti> don't know if it should be part of the live seed
[01:42] <infinity> S'ok, I'll sort it out.
[01:42] <infinity> It *is* in the live seed.
[01:42] <infinity> Something's gone pear-shaped.
[01:43] <rsalveti> hm, so another issue then
[01:43] <infinity> ubiquity-slideshow, that is.
[01:44] <rsalveti> hm, it might be the case that ubiquity-slideshow is installed
[01:44] <TheMuso> Thanks guys, can now move onto pilotting other stuff. :)
[01:44] <rsalveti> let me check it again
[01:44] <rsalveti> O ubiquity-slideshow-ubuntu
[01:44] <infinity> rsalveti: If it is, then it should work, but I can see if we broke it.
[01:44] <rsalveti> I'm sure ubiquity-slideshow-ubuntu is not
[01:45] <rsalveti> infinity: shouldn't we also install  ubiquity-slideshow-ubuntu or  ubiquity-slideshow-kubuntu?
[01:45] <rsalveti> depending on the flavor?
[01:46] <infinity> The live seeds take care of that.
[01:46] <rsalveti> seems this package is what is really providing the slideshow in the end
[01:47]  * infinity curses livefs-build-log mirroring being broken again.
[01:49] <infinity> rsalveti: Anyhow.  Yes, I absolutely agree that it should be installed, no, I'm not sure why it isn't, yes, I'll sort it.
[01:49] <infinity> rsalveti: And no, oem-config-slideshow shouldn't be. ;)
[01:49] <rsalveti> infinity: perfect :-)
[01:49] <rsalveti> it was in the past, that why I got confused :-)
[01:50] <infinity> apt-cadconrad@shiva:~$ apt-cache show ubiquity-slideshow-ubuntu | grep ^Task
[01:50] <infinity> Task: ubuntu-live, ubuntu-usb-live, edubuntu-usb-live, ubuntustudio-dvd-live
[01:50] <infinity> ^-- It clearly should be.
[01:50] <infinity> rsalveti: You're dead positive it's not?
[01:50] <infinity> I kinda don't want to wipe my Panda to test. :P
[01:51] <infinity> (But I suspect I might have to)
[01:51] <rsalveti> infinity: http://paste.ubuntu.com/893117/
[01:52] <infinity> Bizarre.
[01:52] <rsalveti> this is with the latest daily image
[01:52] <rsalveti> for omap4
[01:52] <infinity> Yeahp, I'll hunt it down.
[01:54] <infinity> rsalveti: Although, we haven't had a successful image for two days, maybe it was transient.
[01:54] <rsalveti> infinity: got from http://cdimage.ubuntu.com/daily-preinstalled/20120320.1/
[01:55] <rsalveti> don't know if it's just a copy of an older image
[01:55] <infinity> rsalveti: It's just a copy of an older one. :P
[01:55] <rsalveti> or the latest one generated today
[01:55] <infinity> Looks like we have issues thanks to clutter...
[01:55] <rsalveti> great
[01:55] <rsalveti> hahah
[01:56] <rsalveti> I really think we shouldn't be copying older images to show as the current one when it fails :-)
[01:56] <infinity> rsalveti: Want to fix the ARM clutter-gst FTBFS?
[01:56] <rsalveti> infinity: is that the one blocking the images?
[01:57] <infinity> rsalveti: Looks like.
[01:57] <infinity> rsalveti: clutter-gst -> empathy -> sad panda.
[01:57] <rsalveti> infinity: ok, let me check
[01:57] <rsalveti> infinity: where can I find the image build logs
[01:57] <rsalveti> ?
[01:57] <rsalveti> don't know if it changed again
[01:57] <infinity> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/
[01:57] <rsalveti> great, thanks
[01:59]  * infinity does some local testing to see if he can reproduce the "no slideshow" thing anyway.
[02:00] <infinity> ubiquity-slideshow-ubuntu definitely gets pulled in with ubuntu-live^ here.
[02:00] <infinity> So, I think I'll have to wait for the images to be buildable again and do an end-to-end test.
[02:00] <rsalveti> yeah
[02:01]  * infinity assigns your bug to me, so no one else tries to fix it. :P
[02:03] <infinity> Man.  I ignore the FTBFS list for a week, and everything goes to crap.
[02:03] <infinity> 7 packages...
[02:18] <infinity> slangasek: You around?
[02:20] <rsalveti> infinity: clutter-gst seems to be related with opengles, will check the bug
[02:21] <jk-> infinity: able to test a patch, backported to stable branch 2.6.27.y?
[02:22] <infinity> jk-: If 2.6.27 can boot a precise userspace without exploding, sure.
[02:22] <infinity> jk-: My G3's not wildly flexible on what sort of testing I can do. :P
[02:23] <jk-> oh, btw, the yacht club called, they want their boat anchor back
[02:24] <infinity> jk-: What are you testing?  Just backporting that SMP-on-old-cores fix through the ages?
[02:24] <jk-> yeah, sending a fix for the 2.6.27.y longterm stable branch, and would like to test it first
[02:24] <infinity> 2.6.27 isn't dead upstream yet?
[02:24] <jk-> (there has been a slight change to powerpc/smp.c, so I needed to rework the fix)
[02:25] <jk-> it's still being maintained in stable
[02:25] <infinity> Oh, it was 2.6.32 that Greg KH recently announced he was washing his hands of.
[02:25] <infinity> I'm getting my ancient kernels confused.
[02:26] <jk-> last commit to .32 was on the 17th
[02:26] <infinity> Although, there's some hefty sarcasm with .27 releases...
[02:27] <infinity> "Linux 2.6.27.61 is out for those of you who feel that 2.6.32 is too new and "fancy" for your needs."
[02:27] <jk-> infinity: might be a good match for your machine then? :D
[02:27] <infinity> jk-: *glare*
[03:07] <TheMuso> @pilot out
[03:27] <micahg> infinity: both 2.6.27 and 2.6.32 are now maintained by the old-stable kernel maintainer and had releases last week: http://lwn.net/Articles/487020/rss
[03:46] <Bluefoxicy> ugh how do I even search for a bug for this
[03:48] <Bluefoxicy> ok so in precise, stupid alt+gr key failed, I don't even know what this is
[03:48] <Bluefoxicy> my right alt was  level 3 shift (graves, umlaut, etc) and my right meta windows key was compose (grossen, ae, etc) and now they're just normal and the configuration options have disappeared :|
[03:54] <Bluefoxicy> I can't tell if bug #781100 is this or not
[03:57] <infinity> Bluefoxicy: Try setting them in /etc/default/keyboard?
[03:58] <infinity> Bluefoxicy: (for instance, I have XKBOPTIONS="compose:menu" for my compose)
[04:02] <Bluefoxicy> infinity: this is not a regression?  Not being able to set compose/altgr in keyboard settings?
[04:05] <ScottK> Unity's key layout conflicts with other things too.  Bug #940562
[04:05] <infinity> Bluefoxicy: To be fair, I've never tried.  Heck, I just now found the GUI settings. :P
[04:05] <infinity> Bluefoxicy: The options aren't gone, just remarkably well hidden.
[04:06] <infinity> Bluefoxicy: Settings -> Keyboard, see "Layout Settings" on the bottom left, then select your variant, and click Options.
[04:18] <Bluefoxicy> infinity:  aha.  Finally.  it used to be a separate tab.  hmm mine are checked, lemme uncheck and recheck ... ßëëéü
[04:18] <Bluefoxicy> Qa'pla!
[04:19] <Bluefoxicy> k then I won't file a bug for this.
[04:20] <infinity> Bluefoxicy: The fact that yours were checked but didn't work may still be some curious gconf->gsettings migration issue or something, but it would be a more generic GNOME bug on whatever provides that dialog, not a unity bug.
[04:20] <infinity> (gnome-keyboard-settings, or something equally creatively named, I'd imagine)
[04:22] <infinity> Though, I'm not sure how committed we are to migrating user desktop tweaks completely, as opposed to just having a functional machine after upgrade.  You'd have to ask the desktop guys.
[04:33] <slangasek> infinity: mmmmnope
[04:34] <infinity> slangasek: Apparently not. ;)
[04:35] <infinity> slangasek: There was mention that the whole "Waiting for network config" business may relate to "broken" interfaces files.  Well, mine's not broken, since it clearly does the right thing for me, but perhaps you can look at it and see if something might consider it broken? :P
[04:35] <slangasek> infinity: sure :)
[04:36] <infinity> slangasek: http://paste.ubuntu.com/893202/
[04:36] <slangasek> infinity: and all of those interfaces are present and working?
[04:36] <infinity> slangasek: Perhaps something's a sad panda about eth1 and wlan0 not being explicitly configured?
[04:36] <slangasek> not at all
[04:36] <infinity> slangasek: Yes, they all are present and functional.
[04:36] <slangasek> infinity: ls -l /run/network, please
[04:37] <infinity> -rw-r--r-- 1 root root 34 Mar 20 01:07 ifstate
[04:37] <infinity> -rw-r--r-- 1 root root  0 Mar 20 08:05 ifup.br0
[04:37] <infinity> -rw-r--r-- 1 root root  0 Mar 20 08:05 ifup.eth0
[04:37] <infinity> -rw-r--r-- 1 root root  0 Mar 20 08:05 ifup.lo
[04:37] <infinity> -rw-r--r-- 1 root root  0 Mar 20 01:07 ifup.tun0
[04:38] <infinity> I'm guessing ntpdate happened in there somewhere, given the 7 hour skew. :P
[04:38] <slangasek> heh
[04:39] <slangasek> infinity: missing is the /run/network/static-network-up-emitted directory; maybe you can see why /etc/network/if-up.d/upstart would have failed to consider all interfaces up if all four interfaces are up?
[04:39] <infinity> slangasek: Oh, the directory is there, I just omitted it from the paste.
[04:40] <slangasek> oh
[04:40] <infinity> I figured you wanted the timestamps on interfaces, my bad. :P
[04:40] <infinity> (It's also 1:07)
[04:40] <slangasek> in that case, /etc/init/failsafe.conf should have cleared the screen post haste
[04:41] <slangasek> oh wait
[04:41] <slangasek> this is that other race condition I spotted the other day
[04:41] <infinity> Well, note the (if we assume it's a timezone shift) 2 minute difference between the first 3 interfaces and the last.
[04:42] <slangasek> the order of events you're seeing is 'net-device-up IFACE=lo'; 'static-network-up'; 'filesystem'
[04:42] <infinity> Given that I live in -7, it seems likely it's just a timezone shift.
[04:42] <slangasek> so failsafe isn't yet started when 2) happens, so isn't stopped
[04:42] <slangasek> so when 3) happens, it's started
[04:43] <infinity> It makes sense as a race, I only see it about half the time.
[04:43] <infinity> Maybe more than half, I haven't rebooted enough to confirm.  But "often enough".
[04:43] <slangasek> complicated filesystem setup on this machine?
[04:44] <infinity> Nope.  Just root.
[04:44] <infinity> slangasek: There is, however, the udev storm. ;)
[04:44] <slangasek> ah
[04:44] <slangasek> oh, wait
[04:44] <infinity> slangasek: So, that could be causing serious delays.
[04:45] <slangasek> 2 minutes fits perfectly; you have an 'auto' network device that's not event-drive
[04:45] <slangasek> +n
[04:45] <slangasek> tun0
[04:45] <slangasek> hmm, or does it
[04:45] <infinity> How else does one auto a virtual iface?
[04:45] <slangasek> no, that's the right way to do it, I was just getting ahead of myself in the diagnosis
[04:46] <slangasek> however, udev is implicated in /etc/init/networking.conf
[04:46] <slangasek> so your udev storm could actually play a part
[04:47] <infinity> It could indeed cause some delays, but I'm not sure why that should then trigger a script that forces me to twiddle my thumbs. ;)
[04:47] <infinity> There must be a saner way.
[04:48] <infinity> Unless I really am not getting my interfaces for two minutes...
[04:48] <slangasek> it does what it does to prevent accidentally trying to start network services before the network is up; and upstart doesn't know any better definition of "up" than "all 'auto' interfaces in /e/n/i present and accounted for"
[04:49] <infinity> I just find the 2 minutes between the last two interfaces, both of which are virtual, kinda odd.
[04:49] <infinity> I suppose hostapd could be choking for 2 minutes?
[04:50] <slangasek> no
[04:50] <slangasek> the br0 interface is brought up immediately because you have bridge_ports configured correctly :)
[04:50] <infinity> Gah, it still drives me nuts that lightdm doesn't write to wtmp/utmp.
[04:51] <infinity> 0 users, my ass...
[04:51] <slangasek> (/lib/udev/rules.d/40-bridge-network-interface.rules)
[04:52] <infinity> slangasek: Well, when I'm bored, I can throttle scsi_id/ata_id, or unplug the zip drive, and do a bunch of reboots.
[04:52] <infinity> slangasek: If taking out the udev storm fixes this too, fair enough.
[04:53] <infinity> Though I didn't start seeing this until quite recently, while the udev storm's been around longer.  That's all kinda wishy-washy, though, the machine's only rebooted on kernel updates.
[04:54] <slangasek> yeah, I don't know why it would've regressed recently
[04:54] <slangasek> you could try booting with --verbose and get a look at the timing / ordering of the upstart jobs
[04:54] <jalcine> Which would be better for spellcheck? hunspell or aspell?
[04:55] <infinity> jalcine: Or myspell!
[04:55] <jalcine> oi, the options, lol.
[04:55] <slangasek> jalcine: are you asking about which you should integrate in a program, or which you should use yourself?
[04:56] <infinity> jalcine: hunspell's probably the most feature-rich, libaspell has a nice API and is blindingly fast.
[04:56] <jalcine> the former, slangasek
[04:56] <infinity> And I don't know much about myspell.
[04:56] <jalcine> Well, I just need to spellcheck a few words for a dictation application of mine.
[04:56] <slangasek> hunspell is the best for localized spellcheck support
[04:57] <jalcine> that's a deal closer.
[04:57] <jalcine> Thanks :)
[04:57] <slangasek> the others tend to assume languages that work like English
[04:57] <infinity> So, English?
[04:57] <slangasek> infinity: they can cope with most European languages... just not Hungarian, Basque, and Finnish ;)
[04:58] <infinity> I can't cope with Hungarian either, and I spent 5 years trying.
[04:58] <infinity> I can curse quite convincingly, though.
[04:58] <infinity> (My ex-wife's grandmother wasn't exactly lady-like)
[04:58] <jalcine> Heh
[04:59] <infinity> slangasek: Oh, booting with --verbose would require being able to type "e", wouldn't it?
[05:00] <infinity> slangasek: That's right out unless I buy a new keyboard. ;)
[05:00]  * slangasek squints
[05:00] <slangasek> or modify the boot args over the network? :)
[05:00] <infinity> The array of keys from 2 to 4 down to x through v don't work. :P
[05:00] <infinity> slangasek: BootX, I haven't sorted out how the heck I can modify it's config from Linux.
[05:00] <broder> infinity: so...you couldn't type...4/7 of the characters in verbose?
[05:01] <infinity> slangasek: I have a feeling it requires some sort of resource editor.
[05:01] <broder> wait, 5!
[05:01] <slangasek> infinity: ah right, I forgot about that bit of masochism
[05:02] <infinity> slangasek: Works great, as long as I just close my eyes and La la la about using MacOS as the world's most bloated bootloader.
[05:03] <infinity> But yeah, anyone have an old ADB keyboard with all the keys working? ;)
[05:03] <slangasek> I might :P
[05:03] <infinity> Every kernel upgrade on that machine is a small anxiety attack due to the complete inability to use the console. :P
[05:03] <slangasek> not that I've tried it in a while
[05:04] <infinity> It might just need me to unscrew it and clean it, I suppose.
[05:04] <infinity> Or could be a cold solder connection.
[05:05] <infinity> The machine already has a PSU being held together with electrical tape, may as well get dirtier.
[05:05] <infinity> (And, entertainingly, it's still the most stable computer I own)
[05:06] <jalcine> And hunspell comes with an example, let's go :)
[05:06] <jalcine> Thanks guys, again.
[05:08] <infinity> slangasek: I commend you, by the way, for not making any snide comments about that tunnel's use.
[05:08] <slangasek> you can safely assume I didn't parse it fully ;)
[05:17] <jalcine> Kind of wish everything had a CMake module.
[05:17] <jalcine> Hence my writing one if I don't find one :)
[07:06] <pitti> Good morning
[07:07] <sladen> morgan
[07:07] <sladen> und morgen
[07:43] <chilicui1> hi there, is anyone from here part of the sru team?, I'll like someone could nominate bug #953753 for oneiric
[07:43] <micahg> actually need someone from the SRU team to say if it's SRU acceptable
[07:44] <pitti> chilicui1: I added an oneiric task; seems ok for an SRU
[07:45] <chilicui1> pitti: nice, so then, can I now suscribe the sru team?, or u'll take care of it?, sry, it's my first sru
[07:46] <pitti> chilicui1: no, someone needs to prepare a patch and upload it, then we'll review it
[07:46] <micahg> pitti: there's a patch attached, I wasn't sure about the size/type of it, hence i suggested asking you
[07:46] <chilicui1> I've attached a patch for oneiric in the report
[07:47] <pitti> ah, I subscribed sponsors
[07:48] <chilicui1> ok, great, thanks a lot =)
[08:00] <ricotz> infinity, hello
[08:01] <ricotz> infinity, is it possible to restart https://launchpad.net/~ricotz/+archive/ppa/+build/3302242 ?
[08:02] <micahg> ricotz: cancelled PPA builds cannot be restarted
[08:03] <ricotz> micahg, yeah, you said so some time ago, i was hoping there is still some way
[08:03] <micahg> #launchpad would be more appropriate, but I think you'll get the same answer
[08:04] <ricotz> micahg, ok
[08:08] <dholbach> good morning
[08:12] <jdthoodEtrawsfyn> Someone filed a bug which turns out to be a duplicate of #349469.  Looking at the latter I see that it has 413 duplicates dating back to 2007... and only Importance: Medium! Hmm.
[09:04] <cjwatson> jdthoodEtrawsfyn: that bug is really a symptom of something else, not a debconf bug - either user error in attempting to run multiple debconf frontends at once for the same database, or programming error in trying to do the same
[09:04] <cjwatson> so sure, lots of dups, which is because it's a single symptom of likely multiple causes that are very difficult to untangle
[09:04] <cjwatson> it would be more productive to help untangle it than to comment about the importance!
[09:04] <dholbach> DMB members: somebody pinged me and said the wiki agenda and dates had not been updated yet and wanted to make sure his application was on there - can somebody go and update the wiki? then I'll get back to him
[09:06] <jdthoodEtrawsfyn> cjwatson: I intend to help, despite the fact that the importance setting initially suggests to me that the bug isn't highly important.  ;)
[09:07] <jdthoodEtrawsfyn> Anything with 413 dupes is causing a LOT of irritation out there.
[09:07] <cjwatson> But it's very likely not in fact a single problem with 414 occurrences.
[09:08] <cjwatson> It's sort of like a bug saying "my compiler exited non-zero". :-)
[09:08] <cjwatson> So it's misleading to treat it as 414 reports of something that's definitely all the same problem.
[09:13] <soren> I'd be surprised if it were really more than 2-3 different problems, though. It seems likely that there are only a few things in that common use that uses debconf and doesn't close its handle properly.
[09:16] <Daviey> Wouldn't there be 1000's since *2007* if it was systematic.. Clearly there is something which differentiates these people..
[09:17] <Daviey>  .. i've hit that bug, but i think it was my own fault.
[09:17] <soren> Since dpkg isn't also locked, it has to be something that uses debconf outside of maintainer scripts. Doesn't it?
[09:17] <Daviey> nice!
[09:18] <jdthoodEtrawsfyn> I am able to reproduce the bug: "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable"
[09:18] <soren> Hm... I guess unless you call db_stop, but some daemon didn't close its fd's (one of which it might have inherited from debconf) on start.
[09:18] <soren> jdthoodEtrawsfyn: Cool. Can you tell which other process has it open?
[09:18] <soren> jdthoodEtrawsfyn: PErhaps do a "ps -efl" and pastebin the result.
[09:19] <Daviey> soren: I think next cycle, consider porting debconf into gconf :)
[09:19] <jdthoodEtrawsfyn> Method of reproducing: while : ; do dpkg-reconfigure <package-that-calls-debconf> ; done & update-manager # Then agree to Install Updates
[09:20] <soren> Hm... Doesn't dpkg-reconfigure lock the dpkg database? I guess it might not.
[09:20] <soren> Nope, it doesn't.
[09:21] <soren> I just kind of doubt that's the problem we're seeing here. One of those hundreds of people would have thought of mentioning that they were running "dpkg-reconfigure" in another terminal.
[09:21] <soren> Otherwise, I've just lost a bit more faith in human kind.
[09:22] <Daviey> particularly running it in a while true loop :)
[09:22] <soren> I don't see why that's necessary.
[09:22] <soren> I just ran it, and left it with an open prompt.
[09:22] <soren> That'd do it.
[09:23] <jdthoodEtrawsfyn> soren: dpkg-reconfigure was just my way of ensuring that debconf was being called at the moment update-manager started to Install Updates. If someone does "apt-get upgrade" then many debconf calls will result. If update-manager spontaneously starts while that is happening...
[09:23] <soren> I've you're savvy enough that you know dpkg-reconfigure exists, there's a fair chance you'd know to mention it in a bug report that complains about a locked debconf db.
[09:24] <soren> jdthoodEtrawsfyn: That shouldn't matter. apt-get upgrade will have locked other tihngs that update-manager will complain about (or step back from) way before we reach debconf land.
[09:24]  * soren looks at "jdthoodEtrawsfyn" and finds renewed gratitude for tab completion
[09:27] <jdthoodEtrawsfyn> (Not to be confused with jdthoodPtriffid which is jdthood logged in from triffid using Pidgin.)
[09:33] <apw> pitti, hey ... on blueprints there are now a new 'work items' box, is that in the same format as the old ?  and doe we stilll look in both?
[09:34] <pitti> apw: new LP feature; yes, it's the same format
[09:34] <pitti> apw: WI tracker looks in both
[09:34] <pitti> apw: we'll use whiteboard for precise (no reaason to change them all), and the new one for Q
[09:36] <apw> pitti, ok so we can ignore it for now and use the new one in Q, but if you do use the new one now it will work just fine too ... right?
[09:38] <pitti> apw: it should, yes; I haven't tested it
[09:38] <apw> pitti, thanks :)
[09:40] <bryceh> apw, the work items box is a new feature developed by linaro; but we're not switching to it until uds.
[09:41] <apw> bryceh, yep, i see it does validation, nice
[09:59] <jdthoodEtrawsfyn> soren: In one of the dupes (#380491) the submitter says that running tasksel (not as root) simultaneously with "dpkg --configure --pending" (as root) results in the error message.
[09:59] <jdthoodEtrawsfyn> Do we now conclude that both dpkg-reconfigure and tasksel have bugs?
[10:00] <jdthoodEtrawsfyn> ... different bugs, that is ... and that #380491 should be de-duped and reassigned to tasksel and I should file a new report against dpkg-reconfigure?
[10:10] <seb128> ev, hi, bug #960757 is high on the retracers list, you might want to have a look
[10:36] <soren> jdthoodEtrawsfyn: I'm not sure what the bug would be in that case.
[10:36] <soren> jdthoodEtrawsfyn: tasksel uses debconf.
[10:36] <soren> jdthoodEtrawsfyn: So does lots of packages' maintainer scripts.
[10:36] <soren> jdthoodEtrawsfyn: If you try to use both at the same time, you'll get locking issues.
[10:36] <soren> jdthoodEtrawsfyn: This is not a bug. This is expected behaviour.
[10:38] <jdthoodEtrawsfyn> 414 people didn't expect it, so there's still a problem.
[10:38] <soren> You don't know that 414 people were running tasksel.
[10:39] <soren> And even if they were: The problem might be their expectations. Not a bug in the software.
[10:40] <soren> Two people can't drive the same car at the same time. That doesn't mean the car is broken.
[10:40] <jdthoodEtrawsfyn> It looks as if they were all doing two things at once, both of which tried to run debconf. In many cases one of the things was update-manager starting spontaneously, so it's possibly not all cases of user stupidity.
[10:41] <soren> If they are actively using two things that use debconf at the same time, this is what will happen.
[10:41] <soren> Now, if something has used debconf earlier and for some reason still keeps a handle open, *that
[10:41] <soren> 's* ab ug.
[10:41] <soren> a bug, even.
[10:42] <soren> ...and at least one of those bug reports seems to be something along those lines.
[10:43] <Daviey> soren: Your analogy fails, If i'm driving a car.. and you try to drive it, the 'lock' is my slap in your face. :)
[10:43] <soren> Daviey: I'd say that's a perfect analogy :)
[10:45] <soren> At any rate, you won't pull over and start scratching your head wondering "what the heck is wrong with this car since we can't both drive it at the same time?"
[10:45] <soren> That would be fun, though.
[10:50] <nigelb> 9/ws 24
[10:58] <ivoks> cjwatson: hi; any chance to talk to you for 5-10 minutes? it's about images built with live-build
[10:59] <apw> cjwatson, the latest precice kernel contains those dm changes you requested, thats poped it into new
[10:59] <apw> (the new udeb)
[11:15] <Kaleo> hey guys, who are the patch pilots?
[11:16] <gema> soren: if 414 users reported a problem and their expectations are wrong, then the problem is in the documentation, isn't it? the expectations need to be reset. Since applications are expected to run concurrently on modern pcs, and they don't know about the internals of the implementation, their assumption is correct, our documentation is wrong
[11:16] <tumbleweed> Kaleo: none right now. But any ubuntu developer who wants to do it, can
[11:16] <Kaleo> tumbleweed: ok, thanks
[11:16] <soren> gema: For all we know, only 1 person is doing anything wrong (and has wrong expectations).
[11:17] <soren> gema: The remaining 413 might be seeing an actual bug.
[11:17] <gema> soren: ahh, ok, I misread you , then
[11:18] <soren> gema: Or there might actually be 414 all doing it wrong and having wrong expectations. We just don't know. :)
[11:19] <gema> soren: ack, it'd be good if we could follow up with some of them on how to reproduce
[11:19] <gema> soren: if they can actually reproduce it
[11:28] <vibhav> .
[11:31] <jdthoodEtrawsfyn> cjwatson: OK, I've posted my findings to #349469.
[11:31] <nigelb> 	/ws 24
[11:43] <astraljava> cjwatson: Hi there! Thanks for taking care of US's casper/jackd2 problem! However, I'm a little puzzled how you came to that conclusion. I'm trying to install yesterday's image, and it hangs, as it should since the fix didn't make it into those, but I don't see any mention of jackd2 in any casper-related logs. Only "/usr/bin/casper-reconfigure: package 'gnome-power-manager' is not installed"
[11:44] <astraljava> cjwatson: So my question really is, how do you debug these ubiquity hanging issues?
[12:47] <cjwatson> ivoks: please just ask your question ...
[12:48] <cjwatson> astraljava: I used 'ubiquity --debug' as a general "more debug output" thing, checked what processes were running when it hung, and eventually resorted to strace for the detailed work
[12:49] <cjwatson> IIRC --debug was enough to show the general location of the hang
[12:53] <ev> seb128: indeed, I'm on it this morning.
[12:53] <ev> thanks for the heads up
[12:54] <seb128> ev, yw
[12:54] <ev> err where this morning is the US/Eastern timezone that Foundations is working in today
[12:54] <seb128> ;-)
[12:55] <cjwatson> astraljava: I can't give you a general "how to debug everything" guide, though, since debugging is a creative process
[12:58] <ivoks> cjwatson: sorry about that; i've managed to build iso-hybrid image, image boots, syslinux kicks in, but then it complains that it can't load kernel; i get the same result with lubuntu (from livecd-rootfs) and lp:~ivoks/cloud-live/precise
[12:58] <ivoks> cjwatson: but the kernel is there; everything looks good
[13:00] <ivoks> cjwatson: one thing i've noticed is that lb_binary_disk assumes LB_INITRAMFS_COMPRESSION is gzip and uses zcat when creating initramfs, while it might be lzma
[13:01] <ivoks> s/creating/extracting
[13:01] <cjwatson> sounds plausible, could you prepare a patch?
[13:01] <ivoks> yes
[13:01] <cjwatson> also in general try comparing piece by piece against the official images
[13:02] <ivoks> i would love to do that; i just don't know where official images are :)
[13:02] <ivoks> not images by it self, but rather config/ generated by lb
[13:02] <cjwatson> the configuration is in livecd-rootfs
[13:03] <cjwatson> (ignore the legacy livecd.sh there)
[13:03] <ivoks> maybe i'm using it wrong, but i used /usr/share/livecd-rootfs/live-build/auto/config for config
[13:03] <ivoks> of course, i export project and arch before building
[13:04] <ivoks> i've only tried building lubuntu and that failed
[13:04] <ivoks> well, build finished; kernel couldn't boot
[13:04] <cjwatson> then download the lubuntu image from cdimage.ubuntu.com and compare your self-built image with that to see what's different
[13:05] <ivoks> yeah, that's my next step
[13:05] <ivoks> cjwatson: thank you for your time!
[13:10] <ogra_> rsalveti, universe and multiverse should be enabled by jasper, the slideshow i thought was fixed by a patch from infinity a while ago, i must admit i didnt check
[13:28] <ivoks> cjwatson: that gzip/lzma issue is already fixed in lp:live-build (commits 1940 and 2105)
[13:28] <cjwatson> ivoks: ok, please raise a bug in Ubuntu and assign to me, to backport that
[13:36] <ivoks> cjwatson: i've reported it, but LP doesn't allow me to assign it to you (bug 961166)
[13:37] <cjwatson> ivoks: I've done so, thanks
[14:12] <astraljava> cjwatson: Yeah, that'll do, thanks! I don't need to load everything in at once. Thanks a bunch! :)
[14:35] <ivoks> cjwatson: i found why it doesn't work; another bug in live-build in ubuntu; syslinux doesn't like long filenames for initrd and vmlinuz (commit 2100 in live-build); renaming them tu initrd.lz and vmlinuz makes wonders :)
[14:37] <ivoks> cjwatson: it does make me wonder how we build ubuntu images at all atm :)
[14:39] <cjwatson> ivoks: they're called initrd.lz and vmlinuz in our images.  perhaps you aren't using livecd-rootfs' auto/build script
[14:39] <ivoks> cjwatson: i am not
[14:40] <cjwatson> though I forget how the renaming to initrd.lz works for us
[14:42] <cjwatson> that's odd, but I'll have to defer looking at this for today
[14:43] <ivoks> at least i know where to go from
[14:43] <ivoks> thanks for the help and guidance
[15:13] <seb128> ev, why did you "also affect glib" on that whoopsie bug? adding a comment explaining why you reassign a bug would be welcome
[15:14] <ev> on first blush it looks like a bug in the gnetworkmonitor code
[15:14] <ev> but sure
[15:15] <seb128> ev, oh, isn't that code in glib-networking and not glib?
[15:15] <seb128> hum, maybe not
[15:16] <seb128> ev, I can ask desrt to have a look if you think it's a gio issue
[15:16] <ev> by all means
[15:16] <ev> I haven't completely ruled out it being my fault
[15:16] <ev> but I wouldn't mind another set of eyes on it, especially as I cannot reproduce it locally yet
[15:17] <ev> but https://launchpadlibrarian.net/97677128/Stacktrace.txt looks like it's happening entirely within glib
[15:17] <ev> so unless I'm corrupting memory, I suspect it's a bug there
[15:17] <ev> oh and cheers :)
[15:30] <seb128> ev, desrt looked at it and said
 seb128: my verdict here is memory corruption
[15:30] <seb128>  seb128: g_slice_alloc() is returning some bullshit
[15:30] <ev> seb128: cheers
[15:30] <seb128> yw ;-)
[16:42] <hrw> seb128: checked ubuntu-meta/amd64 for missing -dbgsym packages - only 21 entries found and few interesting questions
[16:52] <jbicha_> sladen: ping
[16:52] <sladen> jbicha_: yus
[16:52] <jbicha_> sladen: do you know when the default precise wallpaper will land?
[16:53] <jbicha_> or we could just keep the oneiric wallpaper ;)
[16:53] <sladen> jbicha_: ah, man, what happened, everyone has been asking in the last five minutes
[16:54] <jbicha_> sladen: that's probably my fault, I wanted it for screenshots for ubuntu-docs
[16:54] <sladen> jbicha_: if it does change it will be a subtle incremental change a la bug #741253 and bug #833990 before  (It's an LTS, so nothing drastic)
[16:55] <sladen> jbicha_: yeah, it will likely be subtle enough that unless it's actually a full-screen shot of the desktop it probably won't/shouldn't be noticable
[16:56] <jbicha_> it peaks through all of the Dash screenshots
[16:57] <jbicha_> I'm counting 5 screenshots in the bzr tree that show pretty much fullscreen of the wallpaper
[16:58] <sladen> jbicha_: I think Otto has been playing with a tweaking of the blue on one side, I guess the thing for the moment would be to highlight + itemise those
[16:58] <sladen> jbicha_: and we can stick those on the bug report so they get remade (if required) (if it happens)
[16:59] <sladen> major wallpaper change will probably be the next cycle as it builds up from scratch to another LTS
[16:59] <jbicha_> well I'd rather not redo the screenshots, could he really try to get it finalized this week?
[16:59] <sladen> jbicha_: hopefully the contest wallpapers should land at some point this week, and it would make sense to have them all go up together
[17:00] <sladen> jbicha_: (whether using the old packaging or your new packaging)
[17:01] <jbicha_> sladen: thank you
[17:03] <adam_g> ScottK: ping
[17:03] <adam_g> ScottK: disregard. :)
[17:04] <ScottK> OK
[17:29] <adam_g> any archive admins around? theres a nova upload sitting in https://launchpad.net/ubuntu/precise/+queue with a new binary package. is there anything i can do to help nudge this along? the new package (nova-consoleauth) contains just a script previously packaged in 'nova-console' plus a manpage and an upstart job
[17:39] <PaoloRotolo> Hi all!
[18:21] <cjwatson> hrw: uh - "none of them is using debhelper", but your list includes pcmciautils, which definitely does use debhelper (in fact, it uses dh)
[18:23] <cjwatson> ah, the problem is that the upstream build system calls strip
[19:32] <smoser> wondering if anyone here has thoughts...
[19:32] <smoser> bug 961226
[19:32] <smoser> right now, cloud-init runs a 'resize2fs' early in boot and blocks on it.
[19:32] <smoser> that patch bug suggests I dont need to block on it.
[19:33] <smoser> I dont have to, as ext3/4 suport online fs resize up.
[19:33] <smoser> but *should* i anyway. its one thing to support it, its another to do it under intense (first boot) disk io
[19:39] <smoser> slangasek, jodh ^ ?
[19:40] <slangasek> hmm
[19:40] <slangasek> is this being run from the initramfs?
[19:41] <smoser> no. this is part of the live filesystem.
[19:42] <broder> smoser: i've definitely done online ext3 resize while actively using my computer, though it probably wasn't quite as i/o intensive as first boot
[19:43] <mfisch> anyone know how to fix this (when I open a new terminal): *** VTE ***: Failed to load terminal capabilities from '/etc/termcap'
[19:43] <mfisch> also, don't update *vte* today
[19:44] <smoser> broder, oh yeah, it definitely works.
[19:44] <smoser> and i would generally consider fs (and fs-tool) developers to be conservative
[19:44] <smoser> so i trust its good.
[19:44] <smoser> good to not lose data
[19:45] <smoser> but i suspect its possible that during boot it might be (at least sometimes) better to just block on it.
[19:45] <smoser> or maybe i'm just making up non-sense.
[19:45] <broder> smoser: the rest of the boot process with cloud-init does things like install packages, right? what are the chances that that step's success is dependent on having the full disk space available to it?
[19:45] <smoser> well, it could install package, so yes, you have to assume it is.
[19:46] <smoser> broder, yeah, that is possible i guesss, but i bet realistically unlikely
[19:46] <smoser> ie, you'd be literally racing to fill up the disk before e2fs resize would grow it.
[19:47] <broder> right, or alternatively if people assume that they can start to shove data into the instance once the boot is finished
[19:49] <smoser> it seems like i should at lesat allow config option of turning it off.
[19:51] <broder> i wonder if it's better to block the rest of cloud-init from running, but not the rest of the boot (i.e. sshd would come up, but the cloud-init scripts wouldn't). but my experience has generally been that if you give people bad semantics they will fail to try to understand them
[19:51] <broder> (c.f. the rails attr_accessible thing)
[19:58] <smoser> broder, i've come to the conclusion of running it blocking by default.
[19:59] <smoser> and allowing user to non-block in config (user-data or system config)
[20:15] <ahasenack> SpamapS: hi, around? Can you sponsor another ladnscape-client upload? bugfix only
[20:32] <ahasenack> hi, can somebody sponsor an upload of mine? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/961131
[20:32] <ahasenack> it's bug fix only
[21:22] <ahasenack> SpamapS: hi, around? Can you sponsor another ladnscape-client upload? bugfix only
[21:30] <infinity> jbicha_: Disappearing symbols in clutter seems ungood...
[21:31] <jbicha_> infinity: http://git.gnome.org/browse/clutter/commit/?id=4da1c3efb8fcea58854
[21:32] <infinity> jbicha_: That doesn't seem to relate to the dropping of all the clutter_gdk symbols?
[21:32] <jbicha_> infinity: ah, you're talking about the ftbfs instead
[21:32] <infinity> Aye.
[21:33] <infinity> Though dropping any symbols in a stable SOVER is bad, if there were others you already fudged. :P
[21:34] <jbicha_> crazy part is it built locally fine, I think it just needs a configure flag
[21:34] <infinity> Configure flag or missing build-dep, if local went fine.
[21:34] <infinity> Perhaps something with *gdk*-dev in the name, based on the missing symbols. :P
[21:37] <infinity> jbicha_: Also, what are the odds that this new clutter (when fixed) will also fix bug 960893?
[21:37] <jbicha_> infinity: I'll have a look at it later tonight if the clutter build is still broken, I have to go now
[21:37] <jbicha_> I'd be surprised if that fixed ARM, but I don't understand ARM either
[21:42] <sbeattie> doko: are you planning another eglibc upload before beta 2 freeze?
[21:42] <doko> sbeattie, no
[21:43] <sbeattie> doko: hrm, can you push the patches for bug 953171?
[21:43] <infinity> sbeattie: I could be talked into it.
[21:43] <sbeattie> infinity: I would greatly appreciate it.
[21:46] <infinity> sbeattie: Sure, I'll do it later this afternoon/evening.
[21:46] <sbeattie> infinity: thanks!
[21:49]  * doko hurrays the eglibc takeover \o/
[21:49] <infinity> doko: :P
[21:50] <infinity> doko: Do you know if there have been discussions in Debian about switching back to glibc, BTW, now that upstream's had a change of management and process, and seems sane finally?
[21:51] <doko> not that I know of
[21:51] <infinity> Or are we just going to wait for eglibc to get absorbed by glibc and have it happen organically?
[21:59] <broder> there was a management/process change in glibc? did i miss an article or has this generally not been reported on yet?
[22:01] <infinity> It's not been widely publicised, to my knowledge.  I only know about it because jbailey pointed it out to me in passing.
[22:02] <infinity> But drepper no longer controls with an iron fist, and glibc upstream has been pulling in eglibc patches and closing the divergence window like mad.
[22:02] <broder> fascinating
[22:03] <infinity> I thought so too.
[22:05] <infinity> They've even been pulling "weird ports" patches, like Debian k*BSD stuff, which would have been unheard of a year ago.
[23:49] <cnd> slangasek, infinity: would switching a package to multi-arch run afoul of the feature freeze?
[23:49] <cjwatson> cnd: It requires a feature freeze exception, yes.
[23:50] <cnd> ok
[23:50] <cnd> I'll branch our packaging for precise then
[23:50] <cjwatson> Multiarching packages can cause things that depend on them to start failing.
[23:50] <cnd> yeah, makes sense
[23:57] <cjwatson> s/depend/build-depend/