[00:57] <barry> slangasek: are you still around?
[00:57] <slangasek> barry: yep!
[00:58] <barry> slangasek: i am seeing something very weird with dbus-python tests, which i think i've tracked down to a bug in oneiric's dbus.  i'm looking for a little sanity check if you have a few minutes
[00:58] <slangasek> barry: ok, what are you seeing?
[00:58] <barry> slangasek: it starts with this: https://bugs.freedesktop.org/show_bug.cgi?id=43303
[00:59] <barry> so the upshot is that this fails on oneiric but not wheezy
[00:59] <barry> slangasek: turning on DBUS_VERBOSE=1 gives some more information about what's happening
[01:00] <slangasek> interesting
[01:00] <barry> slangasek: what i think is going on is that dbus is finding the dbus-python's .service file *and* correctly parsing it/adding it, but then the function in dbus which does this is returning a FALSE status unconditionally, even though it should return a TRUE status
[01:00] <barry> slangasek: now, grab oneiric's source for dbus
[01:00] <slangasek> does the problem occur or not with precise/
[01:01] <barry> slangasek: that's a great question.  i haven't been able to set up an environment to test that yet
[01:01] <barry> slangasek: but, by looking at the code, i think the bug is obvious ;)
[01:01] <slangasek> oh
[01:01] <slangasek> well, let's just fix it then :)
[01:01] <barry> :)
[01:02] <slangasek> is it worth an SRU?  i.e., does it break things in practice besides the python-dbus test suite?
[01:02] <barry> slangasek: i'm still trolling through source package bugs, but i don't see a matcher yet.
[01:02] <barry> slangasek: but i think it only affects .service files in non-standard locations, so it's unlikely to affect normal operation
[01:03] <barry> slangasek: fwiw, the bug is in bus/activation.c, update_desktop_file_entry().  if you look at the bottom of the function, it turns FALSE unconditionally, but it should return retval (which would be set to TRUE in this case).
[01:03] <barry> slangasek: and in fact, on sid and precise, that's exactly what it does
[01:04] <barry> slangasek: i have verified that it works on sid, but i will definitely test precise next!
[01:04] <slangasek> ok
[01:04] <barry> slangasek: i don't know if the bug was upstream but i don't see any debian/patches that would affect it
[01:04]  * slangasek nods
[01:05] <slangasek> so provided that it's fixed now in precise, it probably makes more sense to just get you using precise and not bother with an SRU for this
[01:06] <barry> slangasek: agreed. unless there's a open bug on oneiric that could be caused by this
[01:06] <slangasek> not one that I've heard of... I guess the desktop team might've heard more
[01:06] <barry> i guess i know one thing i'll be doing on xmas break (upgrading my main desktop to precise :)
[01:06] <slangasek> :-)
[01:07] <barry> slangasek: ok cool.  anyway, thanks for letting me talk this out.
[01:07] <slangasek> no problem!
[01:07] <barry> have a good weekend!
[01:08] <slangasek> you too
[01:59] <barry> slangasek: well, i don't think that's the whole story, but i'm giving up for now :)
[02:34] <rubyplusplus> Anyone ever use the twitter bootstrap modal?  I was using it successfully, now I'm not sure what changed, but now it's showing onload
[05:43] <dnewkirk> #ubuntu-app-devel
[10:42] <ManDay> I guess you are a better audience for this question:
[10:44] <ManDay> Starting off from a debootstrap oneiric minimal chroot, I installed things like xfce4 and lightdm (and of course, all their dependencies) and also linux-generic and CASPER into that chroot and burned it onto an USB stick (not squashfs'ed). Now when I boot that USB stick, using the initrd of the linux-generic I get dropped into busybox with the prompt "(initramfs)". Why does it not boot normally? Is
[10:44] <ManDay> it because of casper?
[11:05] <ManDay> Judging from the init in the initrd, it provides $REASON which claims "No init found".
[11:08] <ManDay> Anyone?
[11:08] <ManDay> I think I might be missing a kernel parameter, but I wouldn't know which!
[11:09] <ManDay> Unless... of course...
[11:09] <ManDay> Yes, that must be it: If I don't casper-boot, I need to specify the root= explicity!
[11:19] <ManDay> Yes, that works.
[18:00] <yogi> I'm trying to load Precise Pangolin on a Dell 10 Mini (with the infamous Poulsbo chipset).  Both the alpha 1 and the daily are crashing on boot
[18:02] <yogi> the machine is locked stiff - there is a IRQ in the middle, native_smp_send_reschedule
[18:05] <penguin42> yogi: Report it then, I guess a screenshot of the oops is probably the most useful info from the crashed machine
[18:15] <yogi> UGH - attaching the screenshot crashed my Chrome with 25 tabs!
[18:17] <yogi> https://help.ubuntu.com/community/ReportingBugs is not helpful
[18:20] <penguin42> yogi: File it against linux, and attach the screenshot, also if you can boot something older on it then run apport-collect   and the bug number just to collect info about the hardware
[18:22] <yogi> Timeout error
[18:22] <yogi> Sorry, something just went wrong in Launchpad.
[18:23] <yogi> penguin42: I'm on https://bugs.launchpad.net/
[18:23] <yogi> what is the quickest way to submit a bug?
[18:23] <yogi> I understand the need to filter the incoming bugs somewhat
[18:23] <yogi> but there is not 'Submit a bug' button on the main page
[18:24] <yogi> I guess I should submit a ...   Nevermind!
[18:24] <penguin42> yogi: Just run ubuntu-bug linux     from something that boots
[18:25] <yogi> it asks me for admin password, on my other box
[18:29] <yogi> why wasn't I given the option to not attach all those log files?
[18:34] <Riddell> ScottK: who care about boost now?  libboost-graph1.46-dev doesn't depend on libboost-graph1.46.1
[18:39]  * Riddell reports bug 905772
[18:59] <debfx> Riddell: http://bugs.debian.org/651337
[19:00] <Riddell> that's the one
[19:02] <debfx> Riddell: does it cause a build failure?
[19:19] <Riddell> debfx: it did cause rocs to fail in the ninjas PPA until I added it
[19:47] <ScottK> Riddell: No one, really.  ajmitch pretends he doesn't care, but deep down inside, he does.
[21:39] <ajmitch> ScottK: trying to pin blame on me?
[21:40]  * Frostbite pins a tail on ajmitch 
[21:55] <ManDay> Casper hangs for more than a minute after it says "Running init-bottom". It then says  "* Stopping configure virtual network devices      Waiting for network configuration...         Waiting up to 60 more seconds for network configuration"      I've got no idea where this is coming from, GREPing through the scripts returned nothing. Any idea what to do?
[21:56] <broder> ManDay: check your /etc/network/interfaces file - it should only have a block for the lo interface
[21:56] <penguin42> ManDay: I could swear I saw a bug in the list for stuff to fix on PP along the lines of 'waiting to configure already configured network devices'
[21:57] <ManDay> broder: Has   auto lo    iface lo inet loopback
[21:58] <broder> ManDay: and nothing else? ok, i don't know then. but the waiting messages are coming from /etc/init/failsafe.conf
[21:58] <ManDay> penguin42: I'm not certain it's actually a bug in Casper. Could be that I negelected to give it somethign that it wants
[21:58] <ManDay> broder: Thanks, that's greatly helping me!
[21:58] <broder> ManDay: it's not capser. by the time you get to "Stopping configure virtual network devices", you're past casper code
[21:59] <ManDay> broder: It works without casper (meaning unsquashed, boot=local) though.
[22:00] <ManDay> broder: Weird script... It just has sleeps in it...
[22:01] <broder> ManDay: it's designed to delay the boot until manually configured interfaces in /etc/network/interfaces finish initializing
[22:01] <ManDay> I spot "initctl" in there. I did NOT follow the instructions of "CustomizedLiveCDFromScratch" which said something about replacing initctl
[22:01] <ManDay> These here:
[22:02] <ManDay> https://help.ubuntu.com/community/LiveCDCustomizationFromScratch#Make_the_ChRoot_Environment
[22:02] <ManDay> A bit further down
[22:02] <ManDay> Could it be related?
[22:03] <broder> no. you only need to move initctl out of the way while you're building the chroot; you should undo it before you squash the fs
[22:04] <ManDay> I wasn't planning on becoming an Upstart expert :-/
[22:04] <ManDay> I guess I'll just delete those sleeps and let it fall right through
[22:04] <ManDay> I have no clue what I'm actually doing, though
[22:06] <ManDay> I did not install any of casper-lupin, discover, laptop-detect, os-prober either, as the CustomizeLiveCDFromScratch Tutorial suggests. I guess that's not a problem, either?!
[22:08] <broder> those shouldn't matter. when you say you didn't follow the instructions about initctl, does that mean you didn't do the dpkg-divert step, or you didn't undo the dpkg-divert in the "Cleanup the ChRoot Environment" section?
[22:08] <ManDay> Neither, broder
[22:09] <ManDay> Since everything seemed to work and it wasn't really clear what those steps were good for (and the tutorial is a little aged, anyway) I didn't deem them necessary
[22:09] <broder> they are necessary to prevent random programs from the chroot getting left behind on your system
[22:09] <broder> but they shouldn't affect the output
[22:09] <ManDay> on MY system!? outside of the chroot?
[22:09] <broder> yes
[22:09] <ManDay> **** sake
[22:10] <ManDay> you mean running or actually persistent on disk?!
[22:10] <broder> http://upstart.ubuntu.com/cookbook/#run-upstart-in-a-chroot-environment
[22:10] <broder> running
[22:10] <ManDay> ok, not a problem them
[22:10] <ManDay> for a second I was dreaded ubuntu had shat into my perfect gentoo setup
[22:10] <ManDay> :P
[22:11] <broder> oh, if you're not using upstart outside of your chroot then yeah, it probably wouldn't matter
[22:11] <ManDay> nvm anyway, i just rememberd that i only did that on the first few tries. later on I always did that from a livecd enviroment
[22:14] <broder> and your live environment comes up once the wait in failsafe times out
[22:14] <broder> ?
[22:15] <ManDay> broder: Yeah. Goes straight into console with the "ubuntu" user that I set up, as casper should
[22:16] <ManDay> From thereon I can startx and everything and it works without an issue
[22:16] <broder> is the lo interface up when you get to the console?
[22:16] <ManDay> any more questions?
[22:16] <ManDay> cos I'll have to boot back into it to check
[22:17] <ManDay> so I'd rather check several things at once, if you require more info
[22:17] <ManDay> or wait,
[22:17] <broder> i guess...what's the status of the lo interface
[22:17] <ManDay> no, dont wait. For a second I thought I could use another computer, but that would complicate things
[22:17] <broder> and what does "sudo ifquery --list --allow auto" print out
[22:17] <ManDay> "ifquery" - never heard of
[22:17] <ManDay> ok, ill check that
[22:18] <ManDay> see you in a bit
[22:25] <ManDay> broder: ping
[22:25] <broder> ?
[22:25] <doko> damn libubuntuone
[22:26] <ManDay> That command returns   lo  eth0 eth1 eth2 ath0 wlan0    - suprisingly though, I only got ath0 and wlan0 - I don't have ethernet adapters.
[22:26] <ManDay> broder: ^
[22:26] <broder> well, that would be the problem. for some reason it's deciding that you need to be bringing up all of those interfaces before your networking is initialized
[22:27] <broder> you're really sure that your livecd's /etc/network/interfaces doesn't list any of those?
[22:27] <ManDay> another strange thing is that when I boot the FS with casper WICD (XFCE wlan client) only finds 2 networks - as opposed to a dozen when I boot "normally"
[22:27] <ManDay> that's all a little strange with casper
[22:27] <ManDay> it better should not mess so much with my system!
[22:28] <ManDay> broder: hold on I check again
[22:29] <ManDay> broder: positive
[22:29] <ManDay> it says here, verbatim
[22:29] <ManDay> # interfaces(5) file used by ifup(8) and ifdown(8)
[22:29] <ManDay> auto lo
[22:29] <ManDay> iface lo inet loopback
[22:29] <ManDay> (in the squashfs' etc/network/interfaces)
[22:30] <ManDay> let me check the initrd, too
[22:30] <broder> initrd shouldn't matter
[22:30] <ManDay> thought so. I'll check nonetheless
[22:31] <ManDay> yep. It's not even there in the initrd
[22:32] <broder> are /run and /var/run in the squashfs empty?
[22:32] <ManDay> latter has a symlink to former, and former is by far not empty
[22:33] <ManDay> dbus  do-not-hibernate  init.upgraded  lock  motd  network  utmp  wicd
[22:35] <broder> what's in /run/network?
[22:35] <ManDay> just let me understand what it's happing: It's after the point where Casper has invoked the native init, right? That init is Upstart which walks the /etc/init and brings up services as configured.
[22:35] <ManDay> Right?
[22:35] <broder> yes
[22:35] <ManDay> empty.
[22:36] <broder> hmm
[22:36] <ManDay> So and ONE of the services causes that delay. Which service is it?
[22:36] <broder> /etc/init/failsafe.conf is blocking the boot because it thinks you still have more network interfaces that need to be brought up
[22:36] <ManDay> "Failsafe" is the name of the service?!
[22:37] <broder> well, it's the name of the job
[22:38] <broder> it's intended to solve a problem on servers where the system was booting fast enough that old-style /etc/init.d/ scripts would get run before the network devices were initialized -  bug #580319
[22:38] <broder> and you're triggering this logic because ifquery is concluding that it eth0, eth1, eth2, ath0, and wlan0 are all statically configured interfaces
[22:38] <ManDay> I'm looking at that job's config and it seems rather unconditionally waiting  - there is no IF check whatsoever. It just has those couple of sleeps in there and the config of being started upon filesystem and "net-device-up" events...
[22:39] <broder> yes, but there's the "stop on static-network-up" at the top
[22:39] <ManDay> I'm wondering how things would have to work out so that Upstart does *not* stumble across those sleep's
[22:39] <ManDay> broder: Ah!
[22:39] <broder> when static-network-up gets emitted, upstart kills the job
[22:39] <ManDay> Understood
[22:40] <ManDay> so the problem is actually in static-network-up which does not get fired!
[22:40] <broder> right. static-network-up is fired off by /etc/network/if-up.d/upstart
[22:40] <ManDay> unhuh... I'm grep'ing like crazy ;)
[22:41] <broder> /etc/network/if-up.d/upstart is run by ifup, which is run by either /etc/init/network-interface.conf or /etc/init/networking.conf
[22:41] <ManDay> But the real question is why Casper affects this...
[22:42] <broder> it absolutely should not
[22:42] <broder> casper should be totally out of play at this point
[22:42] <SpamapS> ugh
[22:42] <SpamapS> I think I' about 10 minutes late from saving you guys .. well.. 10 minutes. ;)
[22:42] <broder> oh look! SpamapS! :)
[22:43] <SpamapS> You have, in fact, discovered the secret of static-network-up. Well done. ;)
[22:43] <broder> SpamapS: i knew that. my current question is why ifquery --list --allow auto is printing out 5 interfaces that aren't in /etc/network/interfaces
[22:43] <ManDay> broder: I'll unsquash again just to be absolutly sure I'm not telling you nonsense
[22:43] <SpamapS> the key is really not what /etc/network/interfaces says, but what ifquery says.
[22:43] <SpamapS> broder: something is likely messing with the ifstate file
[22:44] <broder> SpamapS: i was deliberately delaying fetching up the ifupdown source for as long as i could get away with :)
[22:44] <SpamapS> ManDay: whats in /run/network/ifstate ?
[22:44] <SpamapS> should be nothing but lo=lo
[22:45] <ManDay> SpamapS: Second. I'm currently trying this on another machine to see whether the results differ
[22:47] <ManDay> Same results there.
[22:47] <ManDay> SpamapS: You mean in the squashfs, or after I booted?
[22:47] <SpamapS> ManDay: at the point where ifquery --list --allow auto is printing 5 interefaces
[22:48] <ManDay> SpamapS: That would be after boot. I'll have to leave you again to check this.
[22:48] <ManDay> Be back in a second, I'll go online on another machine
[22:51] <ManDay> Which file did you want to know again?!
[22:52] <SpamapS> ManDay: /run/network/ifstate
[22:53] <ManDay> Has lo=lo wlan0=wlan0
[22:54] <ManDay> ifconfig only has lo and lwan0, too, if that matters
[22:55] <SpamapS> but does ifquery --list --allow auto show more?
[22:55] <ManDay> yes, it shows those 5 I mentioned
[22:55] <ManDay> eth0 to eth2, wlan0, lo, and ath0
[22:55] <ManDay> wlan0 and ath0 being two physically existance devices (wlan and bluetooth)
[22:55] <SpamapS> ok, can you do 'strace -e trace=open,stat ifquery --list --allow auto' and pastebin it?
[22:56] <ManDay> i don't have strace. I would have to install that which may take a while,
[22:56] <SpamapS> its pretty small
[22:56] <ManDay> in fact, it should take so long that i'd rather do it tomorrow
[22:56] <SpamapS> and its worth it to figure out where ifquery is getting its faulty information
[22:56] <ManDay> yes but i need to integrate it into the squashfs or something
[22:56] <SpamapS> Oh you're not able to write?
[22:57] <ManDay> SpamapS: Like what?
[22:57] <ManDay> well, i could get strace from my host system
[22:57] <SpamapS> sudo apt-get install strace
[22:57] <SpamapS> no?
[22:57] <ManDay> SpamapS: no, somehow, when I boot with casper my wireless doesn't pick up my home network
[22:57] <SpamapS> AH
[22:57] <ManDay> (it picks up other networks, but only 2)
[22:58] <SpamapS> can you hang on a second I'll try and dig through the code and see what else it might be consulting than ifstate and /etc/network/interfaces
[22:58] <ManDay> let me see whether the local strace of my gentoo host is compativle
[22:58] <SpamapS> what version is this btw?
[23:00] <ManDay> oneiric
[23:00] <SpamapS> ManDay: can you look at /etc/NetworkManager/nm-system-settings.conf ? Are those other 3 interfaces listed there?
[23:00] <ManDay> strace worked
[23:00] <ManDay> it opens:
[23:00] <broder> i think that's spelled /etc/NetworkManager/NetworkManager.conf these days, unless ifupdown is specifically looking at the old path
[23:01] <ManDay> /etc/ld.so.cache   /lib/x86_64-linux-gnu/libc.so.6   /etc/network/interfaces   and /var/run/network/ifstate
[23:02] <ManDay> SpamapS: I don't have NetworkManager
[23:02] <SpamapS> char *nm_system_settings = "/etc/NetworkManager/nm-system-settings.conf";
[23:02] <SpamapS> broder: from ifupdown. :p
[23:02] <broder> eww
[23:02] <SpamapS> ManDay: weird, so thats very confusing.
[23:03] <SpamapS> anyway, I have family stuff to attend to
[23:03] <ManDay> SpamapS: well, at least we have seen where ifquery got the faulty info from
[23:03] <SpamapS> but this may be a helpful clue as to why there are a few people out there with inexplicable waiting.
[23:03] <ManDay> /etc/network/interfaces
[23:03] <SpamapS> ManDay: are all 5 interfaces listed there?
[23:03] <ManDay> yes
[23:03] <SpamapS> OH
[23:03] <SpamapS> thats the problem
[23:03] <SpamapS> how did they get there?!
[23:03] <ManDay> casper
[23:03] <ManDay> what else :-/
[23:04] <ManDay> they are not in the squashfs
[23:04] <ManDay> or...
[23:04] <ManDay> ill just double and triple check
[23:04] <SpamapS> that does make sense I suppose
[23:04] <ManDay> dont want to pass out wrong info
[23:04] <SpamapS> but yes, that is the problem
[23:04] <SpamapS> I don't know anything about casper
[23:05] <SpamapS> but if it is generating an interfaces file that brings up *all* interfaces, then it will result in a long wait unless they all are up instantly
[23:05] <SpamapS> I'm starting to think that we need a 'nowait' group to put interfaces in for systems that don't use NetworkManager
[23:05] <SpamapS> so they can be brought up, but not waited on
[23:05] <SpamapS> anyway, I have to run
[23:05] <broder> SpamapS: might be able to abuse the "allow" syntax for that
[23:05] <Bert_2> Hi, I would like to ask some questions concerning possible incorrect dependencies of a package, is this the right channel ?
[23:05] <SpamapS> ManDay: definitely need to stop casper from making them 'auto', or the system will wait for them to come up, by design.
[23:06] <SpamapS> broder: I intend to actually
[23:06] <ManDay> according to broder casper is harmless...
[23:06] <ManDay> "wouldn't do such a thing"
[23:06] <ManDay> eh, broder ;P
[23:06] <SpamapS> It makes since that casper would do that, if it wasn't going to use NetworkManager
[23:06] <broder> .......oh god
[23:06] <ManDay> i can confirm that the file does not look like that on the squashfs
[23:06] <broder> where did /usr/share/initramfs-tools/init-bottom/23networking come from
[23:06] <SpamapS> But really all we've done is reinstate the old behavior of ifup in Debian past where it would wait until 'ifup -a' finished
[23:07] <SpamapS> anyway, I have to go
[23:07] <SpamapS> good luck!
[23:07] <ManDay> good bye SpamapS
[23:07] <ManDay> see you around
[23:07] <broder> ManDay: http://paste.ubuntu.com/773836/
[23:07] <broder> from /usr/share/initramfs-tools/init-bottom/23networking
[23:08] <ManDay> broder: Is that in the initrd?
[23:08] <broder> yeah
[23:08] <broder> i've never noticed that code before, but it is absolutely most definitely responsible for your problem
[23:08] <broder> and it's probably a bug that it's there
[23:08] <Bert_2> anyone ?
[23:10] <ManDay> broder: Looks like that's it.
[23:10] <ManDay> Curious how that has worked in the first place...
[23:10] <ManDay> Doesn't seem to happen with the "normal" LiveCD
[23:10] <broder> ManDay: installing NM is the easy solution. ln -s /bin/true /usr/sbin/NetworkManager might work as a substitute but i can't make any promises
[23:10] <broder> because the normal livecd has NM installed
[23:10] <ManDay> Meaning what? Does NM undo that?
[23:11] <ManDay> (Remove the IFs again)
[23:11] <broder> "[ ! -x /root/usr/sbin/NetworkManager ]"
[23:11] <broder> that code only runs if NM isn't there
[23:11] <ManDay> Oh, sorry, didn't look
[23:11] <ManDay> closely enough
[23:11] <ManDay> Okay. Want me to file a bug on it?
[23:12] <broder> probably. looks like that code dates back to dapper
[23:13] <Bert_2> Hi, I would like to ask some questions concerning possible incorrect dependencies of a package, is this the right channel ?
[23:14] <broder> !ask | Bert_2
[23:14] <Bert_2> Alright, so I get constant question about the Belgian ID application at the local computerclub
[23:15] <ManDay> Jeez broder , I'm sorry but I guess you will have to do this. Launchpad sends me arround in circles.
[23:15] <Bert_2> the BeID package that people install from softwarecenter doesn't install the requered smartcard-deamon and the driver for the smartcard-reader
[23:15] <broder> ManDay: there's a link at the bottom of the wiki page it bounces you to
[23:15] <Bert_2> therefor they can plug in their readers, install the app and sit there with the app open, claiming there is not smartcard-reader connected
[23:16] <Bert_2> that's why I think that beid-gui should have dependencies on pcscd and libacr38u and a few other packages
[23:16] <Bert_2> now is this a valid argument that I should file a bug about or is this just against the "rules" of dependencies ?
[23:16] <ManDay> broder: Got it
[23:17] <ManDay> broder: initramfs-scripts is an integral part of casper, is it not?
[23:17] <broder> ManDay: yes, but the bug here is in casper
[23:18] <ManDay> Ubuntu's pastebin is a pain in the ass, just by the way...
[23:19] <ManDay> Don't use it, please
[23:23] <ManDay> bug #905828
[23:24] <ManDay> Thank you broder
[23:32] <Bert_2> people, can someone please answer my question cause I'm going to bed soon...
[23:40] <Bert_2> oh well, I'll try again tomorrow
[23:52]  * doko demoted python-central, one more to go for python-support ...