[00:39] popey: it's not entirely uncommon, but it's nevertheless a misconfiguration [00:40] 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 === Guest22703 is now known as jbicha === jbicha is now known as Guest72586 === Guest72586 is now known as jbicha_ [01:25] 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:25] Launchpad bug 960688 in livecd-rootfs (Ubuntu) "Slideshow not enabled by default at the pre-installed images" [Undecided,New] [01:26] Asking you too because of your ARM work for livefs/pre-installed image stuff. [01:27] Or anybody else who has worked on the livefs stuff, opinions welcome. [01:27] TheMuso: Looking. [01:27] Thanks,. [01:28] 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] infinity: Ok, I suspected that this should be fixed elsewhere, thanks for confirming. === dendro-afk is now known as dendrobates [01:33] 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] * Allow fallback from oem-config-slideshow to ubiquity-slideshow for [01:34] cases where the former doesn't exist. [01:34] * infinity looks. [01:34] TheMuso: Cause, in the ARM case, we don't actually want the oem-config slideshow, it's not an OEM install. [01:34] Right. [01:34] So its not a bug. [01:35] TheMuso: Well, it's a bug if the slideshow's not showing at all. [01:35] Right. [01:38] rsalveti: See above re your bug about the slideshow on arm pre-installed images. [01:39] TheMuso: Oh, I think stgraber may have broken this yesterday. In a patch I reviewed. That's embarassing. [01:39] heh ok. :) [01:39] Or not... [01:39] * infinity scratches his head. [01:40] infinity: slideshow is not showing at all [01:40] rsalveti: There's really no slideshow on ARM right now? [01:40] Jinx. [01:40] and there's not any oem specific thing at this slideshow [01:40] it's provided by ubiquity any way [01:40] rsalveti: It's mean to possibly have OEM-specific stuff, hence the fallback. [01:40] it's just enabled by default because the package is not isntalled by default at the pre-installed images [01:40] rsalveti: (I realise it mostly doesn't right now) [01:40] I just added both because during natty I believe we were using them [01:41] rsalveti: Trust me, this used to work properly not long ago, oem-config-slideshow* doesn't need to be there. [01:41] on oneiric I don't remember what happened [01:41] On oneiric, it uses ubiquity-slideshow. [01:41] Or are you saying that's not being installed either? [01:41] Cause that would be a seed issue. [01:41] infinity: yup, not even installed [01:42] It's in the live seed... [01:42] as livecd-rootfs requests oem-installer during the config step, I just added the slide show there [01:42] 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] don't know if it should be part of the live seed [01:42] S'ok, I'll sort it out. [01:42] It *is* in the live seed. [01:42] Something's gone pear-shaped. [01:43] hm, so another issue then [01:43] ubiquity-slideshow, that is. [01:44] hm, it might be the case that ubiquity-slideshow is installed [01:44] Thanks guys, can now move onto pilotting other stuff. :) [01:44] let me check it again [01:44] O ubiquity-slideshow-ubuntu [01:44] rsalveti: If it is, then it should work, but I can see if we broke it. [01:44] I'm sure ubiquity-slideshow-ubuntu is not [01:45] infinity: shouldn't we also install ubiquity-slideshow-ubuntu or ubiquity-slideshow-kubuntu? [01:45] depending on the flavor? [01:46] The live seeds take care of that. [01:46] 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] 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] rsalveti: And no, oem-config-slideshow shouldn't be. ;) [01:49] infinity: perfect :-) [01:49] it was in the past, that why I got confused :-) [01:50] apt-cadconrad@shiva:~$ apt-cache show ubiquity-slideshow-ubuntu | grep ^Task [01:50] Task: ubuntu-live, ubuntu-usb-live, edubuntu-usb-live, ubuntustudio-dvd-live [01:50] ^-- It clearly should be. [01:50] rsalveti: You're dead positive it's not? [01:50] I kinda don't want to wipe my Panda to test. :P [01:51] (But I suspect I might have to) [01:51] infinity: http://paste.ubuntu.com/893117/ [01:52] Bizarre. [01:52] this is with the latest daily image [01:52] for omap4 [01:52] Yeahp, I'll hunt it down. [01:54] rsalveti: Although, we haven't had a successful image for two days, maybe it was transient. [01:54] infinity: got from http://cdimage.ubuntu.com/daily-preinstalled/20120320.1/ [01:55] don't know if it's just a copy of an older image [01:55] rsalveti: It's just a copy of an older one. :P [01:55] or the latest one generated today [01:55] Looks like we have issues thanks to clutter... [01:55] great [01:55] hahah [01:56] I really think we shouldn't be copying older images to show as the current one when it fails :-) [01:56] rsalveti: Want to fix the ARM clutter-gst FTBFS? [01:56] infinity: is that the one blocking the images? [01:57] rsalveti: Looks like. [01:57] rsalveti: clutter-gst -> empathy -> sad panda. [01:57] infinity: ok, let me check [01:57] infinity: where can I find the image build logs [01:57] ? [01:57] don't know if it changed again [01:57] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ [01:57] great, thanks [01:59] * infinity does some local testing to see if he can reproduce the "no slideshow" thing anyway. [02:00] ubiquity-slideshow-ubuntu definitely gets pulled in with ubuntu-live^ here. [02:00] So, I think I'll have to wait for the images to be buildable again and do an end-to-end test. [02:00] yeah [02:01] * infinity assigns your bug to me, so no one else tries to fix it. :P [02:03] Man. I ignore the FTBFS list for a week, and everything goes to crap. [02:03] 7 packages... === vorian is now known as v [02:18] slangasek: You around? [02:20] infinity: clutter-gst seems to be related with opengles, will check the bug [02:21] infinity: able to test a patch, backported to stable branch 2.6.27.y? [02:22] jk-: If 2.6.27 can boot a precise userspace without exploding, sure. [02:22] jk-: My G3's not wildly flexible on what sort of testing I can do. :P [02:23] oh, btw, the yacht club called, they want their boat anchor back [02:24] jk-: What are you testing? Just backporting that SMP-on-old-cores fix through the ages? [02:24] yeah, sending a fix for the 2.6.27.y longterm stable branch, and would like to test it first [02:24] 2.6.27 isn't dead upstream yet? [02:24] (there has been a slight change to powerpc/smp.c, so I needed to rework the fix) [02:25] it's still being maintained in stable [02:25] Oh, it was 2.6.32 that Greg KH recently announced he was washing his hands of. [02:25] I'm getting my ancient kernels confused. [02:26] last commit to .32 was on the 17th [02:26] Although, there's some hefty sarcasm with .27 releases... [02:27] "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] infinity: might be a good match for your machine then? :D [02:27] jk-: *glare* === dendrobates is now known as dendro-afk === jalcine is now known as Guest84963 === JackyAlcine is now known as jalcine [03:07] @pilot out === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [03:27] 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] ugh how do I even search for a bug for this [03:48] ok so in precise, stupid alt+gr key failed, I don't even know what this is [03:48] 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] I can't tell if bug #781100 is this or not [03:54] Launchpad bug 781100 in unity (Ubuntu) "Unity overrides compose key setting" [Undecided,Confirmed] https://launchpad.net/bugs/781100 [03:57] Bluefoxicy: Try setting them in /etc/default/keyboard? [03:58] Bluefoxicy: (for instance, I have XKBOPTIONS="compose:menu" for my compose) [04:02] infinity: this is not a regression? Not being able to set compose/altgr in keyboard settings? [04:05] Unity's key layout conflicts with other things too. Bug #940562 [04:05] Launchpad bug 940562 in unity (Ubuntu) "Global hotkeys of amarok for rating conflict with Unity (Meta-1 to Meta-5) " [Undecided,New] https://launchpad.net/bugs/940562 [04:05] Bluefoxicy: To be fair, I've never tried. Heck, I just now found the GUI settings. :P [04:05] Bluefoxicy: The options aren't gone, just remarkably well hidden. [04:06] Bluefoxicy: Settings -> Keyboard, see "Layout Settings" on the bottom left, then select your variant, and click Options. [04:18] infinity: aha. Finally. it used to be a separate tab. hmm mine are checked, lemme uncheck and recheck ... ßëëéü [04:18] Qa'pla! [04:19] k then I won't file a bug for this. [04:20] 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] (gnome-keyboard-settings, or something equally creatively named, I'd imagine) [04:22] 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] infinity: mmmmnope [04:34] slangasek: Apparently not. ;) [04:35] 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] infinity: sure :) [04:36] slangasek: http://paste.ubuntu.com/893202/ [04:36] infinity: and all of those interfaces are present and working? [04:36] slangasek: Perhaps something's a sad panda about eth1 and wlan0 not being explicitly configured? [04:36] not at all [04:36] slangasek: Yes, they all are present and functional. [04:36] infinity: ls -l /run/network, please [04:37] -rw-r--r-- 1 root root 34 Mar 20 01:07 ifstate [04:37] -rw-r--r-- 1 root root 0 Mar 20 08:05 ifup.br0 [04:37] -rw-r--r-- 1 root root 0 Mar 20 08:05 ifup.eth0 [04:37] -rw-r--r-- 1 root root 0 Mar 20 08:05 ifup.lo [04:37] -rw-r--r-- 1 root root 0 Mar 20 01:07 ifup.tun0 [04:38] I'm guessing ntpdate happened in there somewhere, given the 7 hour skew. :P [04:38] heh [04:39] 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] slangasek: Oh, the directory is there, I just omitted it from the paste. [04:40] oh [04:40] I figured you wanted the timestamps on interfaces, my bad. :P [04:40] (It's also 1:07) [04:40] in that case, /etc/init/failsafe.conf should have cleared the screen post haste [04:41] oh wait [04:41] this is that other race condition I spotted the other day [04:41] Well, note the (if we assume it's a timezone shift) 2 minute difference between the first 3 interfaces and the last. [04:42] the order of events you're seeing is 'net-device-up IFACE=lo'; 'static-network-up'; 'filesystem' [04:42] Given that I live in -7, it seems likely it's just a timezone shift. [04:42] so failsafe isn't yet started when 2) happens, so isn't stopped [04:42] so when 3) happens, it's started [04:43] It makes sense as a race, I only see it about half the time. [04:43] Maybe more than half, I haven't rebooted enough to confirm. But "often enough". [04:43] complicated filesystem setup on this machine? [04:44] Nope. Just root. [04:44] slangasek: There is, however, the udev storm. ;) [04:44] ah [04:44] oh, wait [04:44] slangasek: So, that could be causing serious delays. [04:45] 2 minutes fits perfectly; you have an 'auto' network device that's not event-drive [04:45] +n [04:45] tun0 [04:45] hmm, or does it [04:45] How else does one auto a virtual iface? [04:45] no, that's the right way to do it, I was just getting ahead of myself in the diagnosis [04:46] however, udev is implicated in /etc/init/networking.conf [04:46] so your udev storm could actually play a part [04:47] 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] There must be a saner way. [04:48] Unless I really am not getting my interfaces for two minutes... [04:48] 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] I just find the 2 minutes between the last two interfaces, both of which are virtual, kinda odd. [04:49] I suppose hostapd could be choking for 2 minutes? [04:50] no [04:50] the br0 interface is brought up immediately because you have bridge_ports configured correctly :) [04:50] Gah, it still drives me nuts that lightdm doesn't write to wtmp/utmp. [04:51] 0 users, my ass... [04:51] (/lib/udev/rules.d/40-bridge-network-interface.rules) [04:52] 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] slangasek: If taking out the udev storm fixes this too, fair enough. [04:53] 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] yeah, I don't know why it would've regressed recently [04:54] you could try booting with --verbose and get a look at the timing / ordering of the upstart jobs [04:54] Which would be better for spellcheck? hunspell or aspell? [04:55] jalcine: Or myspell! [04:55] oi, the options, lol. [04:55] jalcine: are you asking about which you should integrate in a program, or which you should use yourself? [04:56] jalcine: hunspell's probably the most feature-rich, libaspell has a nice API and is blindingly fast. [04:56] the former, slangasek [04:56] And I don't know much about myspell. [04:56] Well, I just need to spellcheck a few words for a dictation application of mine. [04:56] hunspell is the best for localized spellcheck support [04:57] that's a deal closer. [04:57] Thanks :) [04:57] the others tend to assume languages that work like English [04:57] So, English? [04:57] infinity: they can cope with most European languages... just not Hungarian, Basque, and Finnish ;) [04:58] I can't cope with Hungarian either, and I spent 5 years trying. [04:58] I can curse quite convincingly, though. [04:58] (My ex-wife's grandmother wasn't exactly lady-like) [04:58] Heh [04:59] slangasek: Oh, booting with --verbose would require being able to type "e", wouldn't it? [05:00] slangasek: That's right out unless I buy a new keyboard. ;) [05:00] * slangasek squints [05:00] or modify the boot args over the network? :) [05:00] The array of keys from 2 to 4 down to x through v don't work. :P [05:00] slangasek: BootX, I haven't sorted out how the heck I can modify it's config from Linux. [05:00] infinity: so...you couldn't type...4/7 of the characters in verbose? [05:01] slangasek: I have a feeling it requires some sort of resource editor. [05:01] wait, 5! [05:01] infinity: ah right, I forgot about that bit of masochism [05:02] 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] But yeah, anyone have an old ADB keyboard with all the keys working? ;) [05:03] I might :P [05:03] Every kernel upgrade on that machine is a small anxiety attack due to the complete inability to use the console. :P [05:03] not that I've tried it in a while [05:04] It might just need me to unscrew it and clean it, I suppose. [05:04] Or could be a cold solder connection. [05:05] The machine already has a PSU being held together with electrical tape, may as well get dirtier. [05:05] (And, entertainingly, it's still the most stable computer I own) [05:06] And hunspell comes with an example, let's go :) [05:06] Thanks guys, again. [05:08] slangasek: I commend you, by the way, for not making any snide comments about that tunnel's use. [05:08] you can safely assume I didn't parse it fully ;) [05:17] Kind of wish everything had a CMake module. [05:17] Hence my writing one if I don't find one :) === jalcine is now known as jalcine_ === tkamppeter_ is now known as tkamppeter [07:06] Good morning [07:07] morgan [07:07] und morgen [07:43] hi there, is anyone from here part of the sru team?, I'll like someone could nominate bug #953753 for oneiric [07:43] Launchpad bug 953753 in klavaro (Ubuntu) "Klavaro is not completely translated even when the .po is completely translated" [Undecided,Fix released] https://launchpad.net/bugs/953753 [07:43] actually need someone from the SRU team to say if it's SRU acceptable [07:44] chilicui1: I added an oneiric task; seems ok for an SRU [07:45] 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] chilicui1: no, someone needs to prepare a patch and upload it, then we'll review it [07:46] pitti: there's a patch attached, I wasn't sure about the size/type of it, hence i suggested asking you [07:46] I've attached a patch for oneiric in the report [07:47] ah, I subscribed sponsors [07:48] ok, great, thanks a lot =) === smb` is now known as smb [08:00] infinity, hello [08:01] infinity, is it possible to restart https://launchpad.net/~ricotz/+archive/ppa/+build/3302242 ? [08:02] ricotz: cancelled PPA builds cannot be restarted [08:03] micahg, yeah, you said so some time ago, i was hoping there is still some way [08:03] #launchpad would be more appropriate, but I think you'll get the same answer [08:04] micahg, ok [08:08] good morning [08:12] 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] 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] 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] it would be more productive to help untangle it than to comment about the importance! [09:04] 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] 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] Anything with 413 dupes is causing a LOT of irritation out there. [09:07] But it's very likely not in fact a single problem with 414 occurrences. [09:08] It's sort of like a bug saying "my compiler exited non-zero". :-) [09:08] So it's misleading to treat it as 414 reports of something that's definitely all the same problem. [09:13] 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] Wouldn't there be 1000's since *2007* if it was systematic.. Clearly there is something which differentiates these people.. [09:17] .. i've hit that bug, but i think it was my own fault. [09:17] Since dpkg isn't also locked, it has to be something that uses debconf outside of maintainer scripts. Doesn't it? [09:17] nice! [09:18] 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] 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] jdthoodEtrawsfyn: Cool. Can you tell which other process has it open? [09:18] jdthoodEtrawsfyn: PErhaps do a "ps -efl" and pastebin the result. [09:19] soren: I think next cycle, consider porting debconf into gconf :) [09:19] Method of reproducing: while : ; do dpkg-reconfigure ; done & update-manager # Then agree to Install Updates [09:20] Hm... Doesn't dpkg-reconfigure lock the dpkg database? I guess it might not. [09:20] Nope, it doesn't. [09:21] 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] Otherwise, I've just lost a bit more faith in human kind. [09:22] particularly running it in a while true loop :) [09:22] I don't see why that's necessary. [09:22] I just ran it, and left it with an open prompt. [09:22] That'd do it. [09:23] 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] 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. === zyga is now known as zyga-afk [09:24] 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] (Not to be confused with jdthoodPtriffid which is jdthood logged in from triffid using Pidgin.) [09:33] 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] apw: new LP feature; yes, it's the same format [09:34] apw: WI tracker looks in both [09:34] apw: we'll use whiteboard for precise (no reaason to change them all), and the new one for Q [09:36] 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] apw: it should, yes; I haven't tested it [09:38] pitti, thanks :) [09:40] apw, the work items box is a new feature developed by linaro; but we're not switching to it until uds. [09:41] bryceh, yep, i see it does validation, nice [09:59] 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] Do we now conclude that both dpkg-reconfigure and tasksel have bugs? [10:00] ... 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] ev, hi, bug #960757 is high on the retracers list, you might want to have a look [10:10] Launchpad bug 960757 in whoopsie-daisy (Ubuntu) "whoopsie crashed with SIGSEGV in g_object_newv()" [Medium,Confirmed] https://launchpad.net/bugs/960757 === tomreyn_ is now known as tomreyn [10:36] jdthoodEtrawsfyn: I'm not sure what the bug would be in that case. [10:36] jdthoodEtrawsfyn: tasksel uses debconf. [10:36] jdthoodEtrawsfyn: So does lots of packages' maintainer scripts. [10:36] jdthoodEtrawsfyn: If you try to use both at the same time, you'll get locking issues. [10:36] jdthoodEtrawsfyn: This is not a bug. This is expected behaviour. [10:38] 414 people didn't expect it, so there's still a problem. [10:38] You don't know that 414 people were running tasksel. [10:39] And even if they were: The problem might be their expectations. Not a bug in the software. [10:40] Two people can't drive the same car at the same time. That doesn't mean the car is broken. [10:40] 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] If they are actively using two things that use debconf at the same time, this is what will happen. [10:41] Now, if something has used debconf earlier and for some reason still keeps a handle open, *that [10:41] 's* ab ug. [10:41] a bug, even. [10:42] ...and at least one of those bug reports seems to be something along those lines. [10:43] 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] Daviey: I'd say that's a perfect analogy :) [10:45] 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] That would be fun, though. [10:50] 9/ws 24 [10:58] cjwatson: hi; any chance to talk to you for 5-10 minutes? it's about images built with live-build [10:59] cjwatson, the latest precice kernel contains those dm changes you requested, thats poped it into new [10:59] (the new udeb) === zyga-afk is now known as zyga === dendro-afk is now known as dendrobates [11:15] hey guys, who are the patch pilots? [11:16] 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] Kaleo: none right now. But any ubuntu developer who wants to do it, can [11:16] tumbleweed: ok, thanks [11:16] gema: For all we know, only 1 person is doing anything wrong (and has wrong expectations). [11:17] gema: The remaining 413 might be seeing an actual bug. [11:17] soren: ahh, ok, I misread you , then [11:18] gema: Or there might actually be 414 all doing it wrong and having wrong expectations. We just don't know. :) [11:19] soren: ack, it'd be good if we could follow up with some of them on how to reproduce [11:19] soren: if they can actually reproduce it [11:28] . [11:31] cjwatson: OK, I've posted my findings to #349469. [11:31] /ws 24 [11:43] 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] cjwatson: So my question really is, how do you debug these ubiquity hanging issues? === MacSlow is now known as MacSlow|lunch === _salem is now known as salem_ === smb` is now known as smb === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [12:47] ivoks: please just ask your question ... [12:48] 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] IIRC --debug was enough to show the general location of the hang [12:53] seb128: indeed, I'm on it this morning. [12:53] thanks for the heads up [12:54] ev, yw [12:54] err where this morning is the US/Eastern timezone that Foundations is working in today [12:54] ;-) [12:55] astraljava: I can't give you a general "how to debug everything" guide, though, since debugging is a creative process [12:58] 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] cjwatson: but the kernel is there; everything looks good [13:00] 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] s/creating/extracting [13:01] sounds plausible, could you prepare a patch? [13:01] yes [13:01] also in general try comparing piece by piece against the official images [13:02] i would love to do that; i just don't know where official images are :) [13:02] not images by it self, but rather config/ generated by lb [13:02] the configuration is in livecd-rootfs [13:03] (ignore the legacy livecd.sh there) [13:03] maybe i'm using it wrong, but i used /usr/share/livecd-rootfs/live-build/auto/config for config [13:03] of course, i export project and arch before building [13:04] i've only tried building lubuntu and that failed [13:04] well, build finished; kernel couldn't boot [13:04] then download the lubuntu image from cdimage.ubuntu.com and compare your self-built image with that to see what's different [13:05] yeah, that's my next step [13:05] cjwatson: thank you for your time! [13:10] 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 === beuno_ is now known as beuno === v is now known as vorian [13:28] cjwatson: that gzip/lzma issue is already fixed in lp:live-build (commits 1940 and 2105) [13:28] ivoks: ok, please raise a bug in Ubuntu and assign to me, to backport that [13:36] cjwatson: i've reported it, but LP doesn't allow me to assign it to you (bug 961166) [13:36] Launchpad bug 961166 in live-build (Ubuntu) "lb_binary_disk doesn't check compression of the initramfs" [Undecided,New] https://launchpad.net/bugs/961166 [13:37] ivoks: I've done so, thanks === Guest10799 is now known as tobin === tobin is now known as Guest70213 === dendrobates is now known as dendro-afk === jalcine_ is now known as Guest38311 === webjadmin_ is now known as Guest97056 === yofel_ is now known as yofel [14:12] cjwatson: Yeah, that'll do, thanks! I don't need to load everything in at once. Thanks a bunch! :) === dendro-afk is now known as dendrobates [14:35] 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] cjwatson: it does make me wonder how we build ubuntu images at all atm :) [14:39] ivoks: they're called initrd.lz and vmlinuz in our images. perhaps you aren't using livecd-rootfs' auto/build script [14:39] cjwatson: i am not [14:40] though I forget how the renaming to initrd.lz works for us [14:42] that's odd, but I'll have to defer looking at this for today [14:43] at least i know where to go from [14:43] thanks for the help and guidance [15:13] 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] on first blush it looks like a bug in the gnetworkmonitor code [15:14] but sure [15:15] ev, oh, isn't that code in glib-networking and not glib? [15:15] hum, maybe not [15:16] ev, I can ask desrt to have a look if you think it's a gio issue [15:16] by all means [15:16] I haven't completely ruled out it being my fault [15:16] but I wouldn't mind another set of eyes on it, especially as I cannot reproduce it locally yet [15:17] but https://launchpadlibrarian.net/97677128/Stacktrace.txt looks like it's happening entirely within glib [15:17] so unless I'm corrupting memory, I suspect it's a bug there [15:17] oh and cheers :) [15:30] ev, desrt looked at it and said [15:30]