[00:35] <smoser> slangasek, i'm pretty sure its /run .
[00:35] <smoser> which is blocked on the mounting of /
[00:35] <smoser> but somehow on intel this works.
[00:38] <smoser> ie, the change that caused this failure was
[00:38] <smoser> /etc/init/cloud-init-local.conf
[00:38] <smoser> - start on mounted MOUNTPOINT=/
[00:38] <smoser> +start on mounted MOUNTPOINT=/ and mounted MOUNTPOINT=/run
[02:12] <slangasek> smoser: mmm.  Remind me the intended semantics of /etc/init/cloud-init-local.conf?  You don't /want/ to block the filesystem events from returning, right, you just want cloud-init-local to run only after / and /run are mounted?
[02:12] <slangasek> smoser: did you ever try 'start on mounted MOUNTPOINT=/ and virtual-filesystems'?
[07:22] <jamespage> doko: done (subscriptions)
[07:48] <wouter> hi -- https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule suggests Utopic is to be released today. Is that still on schedule?
[07:52] <mitya57> wouter: yes!
[07:54] <wouter> okay, thanks
[09:07] <hyperair> argh is the archive broken?
[09:07] <hyperair> my upgrade crashed out
[09:07] <hyperair> i've been running aptitude full-upgrade, and still have 1200+ packages to install
[09:07] <hyperair> at least it's progress ¬_¬"
[09:16] <flexiondotorg> Is it too late to request some sync requests from Debian?
[09:17] <flexiondotorg> There are some upstream fixes that landed in Debian a few hours ago for MATE.
[09:18] <hyperair> is that in main or universe?
[09:19] <hyperair> i think you can still request syncs for universe packages even after final freeze
[09:19] <flexiondotorg> hyperair, universe
[09:19] <hyperair> at least, it won't be impacting the iso images
[12:21] <pitti> cjwatson: argh, because I can't type; new one coming
[12:25] <pitti> nemo: you can use apport-unpack on the .crash file (see manpage)
[12:28] <nemo> pitti: ah. thanks
[12:28] <nemo> pitti: fortunately it turned out to be really really really easy to reproduce so they didn't need the bt
[12:28] <nemo> but I'll remember that
[12:29] <nemo> pitti: hm. where *is* the .crash ?
[12:29] <pitti> nemo: aside from that, the .crash is just a plain text file, so it's quite human readable
[12:29] <pitti> nemo: /var/crash/
[12:33] <nemo> pitti: oh nice. yeah. I can just copy and paste this
[12:33] <nemo> pitti: shame I couldn't just ctrl-c from the tool, but that might just be a limitation of the gtk widget
[12:34] <pitti> nemo: there's a nice close button in the window title bar :)
[12:36] <nemo> pitti: oh, I just mean if I ever run into an ubuntu user who hits a crash in our stuff, would be nice if I could just tell them to ctrl-c
[12:36] <nemo> but. nbd for me, that /var/crash thing is pretty much perfect
[12:37] <pitti> ctrl-c is spelled "Cancel" in GTK
[12:37] <nemo> hm.
[12:37] <nemo> that's how you copy in a fair number of gtk apps
[12:38] <nemo> in fact, some, like gedit/pluma don't even let you use the X copy ಠ_ಠ
[12:38] <nemo> pitti: oh. btw, if you're curious about the crash, it is kinda funny. http://www.fnordware.com/j2k/jp2samples.html  save the jp2 link to a MATE 1.8 or 1.10 desktop and you'll get an infinite series of crashes and respawns of caja
[12:39] <nemo> pitti: assertion in jp2 decoder - looks like they decided to move thumbnail generation into caja instead of keeping it in a separate process
[12:39] <nemo> presumably for performance
[12:39] <nemo> I mentioned it in #MATE so hopefully someone will fix it soon-ish
[12:39] <nemo> only way to make it stop infinitely crashing and respawning is to move the image off the desktop
[12:41] <nemo> I guess they could change the assertions to just aborting the thumbnail creation, but given how nutty image formats can be, thinking keeping this in a dedicated process might be safer in the long run. ah well.
[12:42] <flexiondotorg> nemo, I am on the MATE team. Whats up.
[12:43] <nemo> flexiondotorg: oh. are you in #MATE ? I mentioned it last night there and has been quiet since
[12:43] <nemo> flexiondotorg: but. what I mentioned above. http://www.fnordware.com/j2k/jp2samples.html
[12:43] <nemo> save the JP2 link to the Desktop results in infinite series of crashes of caja due to an assertion in jp2_dec
[12:43] <flexiondotorg> Yep.
[12:44]  * flexiondotorg goes testing in a VM...
[12:44] <nemo> flexiondotorg: I nattered on a bit in there about how screwed up image/video (and audio) decoding can be, and how this is probably best kept out of important user stuff
[12:44] <nemo> flexiondotorg: thumbnailer could be a dedicated process and such
[12:45] <flexiondotorg> nemo, Confirmed.
[12:47] <flexiondotorg> If you save it anywhere and view that folder it will crash Caja. Obvoiusly on the Desktop that create a burning fireball of death.
[12:47] <nemo> flexiondotorg: yeah. I figured anywhere would work too
[12:47] <nemo> flexiondotorg: I'd initially tried gdb --args caja /tmp
[12:47] <nemo> but, was too much of a pain to keep my main caja from taking over
[12:48] <nemo> that's why I dropped by here to find out how to get a trace from apport instead
[12:48] <flexiondotorg> nemo, apport trpped it in my VM.
[12:48] <nemo> yep
[12:50] <smoser> slangasek, wrt semantics of cloud-init-local. i want to block.
[12:50] <smoser> and i think virtual-filesystems would not block.
[12:51] <slangasek> smoser: right; and it doesn't work so well to block both events when one might be dependent on the other
[12:51] <nemo> flexiondotorg: by getting a trace from apport, I mean, I couldn't figure out how to copy a trace out of apport-gtk - that's why I came to #ubuntu-devel  and was told how to find the text in /var/crashes
[12:51] <nemo> er. /var/crash
[12:52] <flexiondotorg> nemo, What thumbnailer is used on your system?
[12:53] <nemo> flexiondotorg: ummmmm.  well, this is caja 1.8.1 so I'm gonna guess that the crash means the thumbnailer is caja
[12:53] <nemo> flexiondotorg: but in older versions and in gnome2, it was a separate process
[12:53] <nemo> gnome thumbnailer or something
[12:53] <smoser> slangasek, but why are they dependenton another ?
[12:53] <smoser> other than /run not existing (which it does).
[12:53] <nemo> flexiondotorg: for a large directory of images there was noticeable lag, probably due to repeated process respawn
[12:53] <nemo> flexiondotorg: I'm guessing that's why they decided to move it in-process
[12:54] <nemo> flexiondotorg: 'course that makes handling bad code a bit more interesting.
[12:54] <nemo> flexiondotorg: a single dedicated process that could be passed urls might be a compromise
[12:54] <smoser> slangasek, this would make sense to me, and i wouldn't have done the thing if it didnt work in intel.
[12:55] <nemo> flexiondotorg: perhaps easier than ensuring all image parsing is rigorous and safe - over the years it seems image parsing is constantly a source of insanity, esp for obscure formats, or effed up ones like TIFF
[12:56] <nemo> flexiondotorg: and, yeah, my recollection from messing around w/ AMP back in the day is that MP3 is just as much of a pain (the headers that is).  HTML is bad too - basically any format w/ a ton of implementers and a bit too broad a spec
[13:05] <barry> lool: this is kind of old, but LP: #1276347
[13:07] <roadmr> cjwatson: hey! I see ldlinux.c32 is now in the utopic netboot directory in archive.ubuntu.com, but according to my tests, 2 more files are also needed libcom32.c32 and libutil.c32, is it possible to also put them there?
[13:08] <cjwatson> roadmr: the Debian bug indicated that that was unnecessary because they are now found by a path search
[13:08] <cjwatson> we should dig into that if it is not in fact true
[13:08] <cjwatson> roadmr: but I cannot deal with this right now, I'm working on releasing 14.10
[13:09] <cjwatson> please hold until later
[13:10] <roadmr> cjwatson: oh ok, I'll test that, and no problem, I can wait. Release yay, thanks!
[13:17] <exarkun> Any chance anyone can comment one way or the other on whether the fix for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1274779 will ever appear in 14.04 or 14.10?
[13:36] <tjaalton> exarkun: what fix? upstream bug says it should be reopened
[13:37] <tjaalton> ah, fixed in 3.17.. you'll have to wait for that
[13:37] <tjaalton> unless the fixes are marked for stable@
[13:46] <exarkun> tjaalton: It sounds like that means it won't be backported.  Is my understanding correct?
[13:46] <exarkun> tjaalton: The fix will appear in whatever release of Ubuntu packages Linux 3.17, and not before?
[13:48] <Pwnna> has anyone have issues with cryptsetup in 14.04?
[13:48] <Pwnna> uhm. 14.10
[13:54] <tjaalton> exarkun: otherwise someone needs to backport it to 3.13/3.16
[14:04] <exarkun> tjaalton: Thanks.
[14:54] <rsalveti> pitti: hey, were you the one complaining about rtm for emulator?
[14:54] <rsalveti> it seems to be broken
[14:55] <rsalveti> unity-system-compositor is a defunct process here
[15:02] <pitti> rsalveti: yeah, we sat next to each other when I noticed :)
[15:02] <pitti> rsalveti: oh sorry, actually not -- that was sergiusens
[15:02] <rsalveti> pitti: yeah :-)
[15:02] <rsalveti> pitti: I think I got what is wrong
[15:02] <pitti> rsalveti: so I used ubuntu utoppic, that one still works (older unity or so)
[15:02] <pitti> rsalveti: in rtm, unity failed with some EGL_BLAH error
[15:02] <rsalveti> pitti: yeah
[15:02] <rsalveti> pitti: https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz
[15:02] <rsalveti> this is the reason
[15:02] <sergiusens> EGL_BAD_MATCH
[15:03] <rsalveti> I'm copying that over to rtm
[15:03] <pitti> 'zactly
[15:03] <pitti> rsalveti: oh, awesome
[15:48] <mdeslaur> slangasek: so, reinstalled and didn't check the "download updates" box, and it still downloaded a whole bunch of updates during install :P
[15:48] <mdeslaur> pretty curious
[15:49] <slangasek> hmmm
[15:49] <mdeslaur> just FYI
[15:49] <mdeslaur> I'll file a bug
[16:26] <slangasek> smoser: so what is the root filesystem device as listed in /etc/fstab, for your success vs. failure cases?
[16:27] <slangasek> smoser: I see root=/dev/vda on the kernel commandline for both, but maybe /etc/fstab differs
[16:27] <slangasek> smoser: in particular, if ppc64el lists something UUID= ish, mountall doesn't resolve that until udev announces the device's presence, which won't happen until virtual-filesystems is emitted
[16:28] <smoser> slangasek, both success and failure
[16:29] <smoser> $ cat /etc/fstab
[16:29] <smoser> LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
[16:30] <smoser> seemingly no change when i 'sed s,LABEL=cloudimg-rootfs,/dev/vda, /etc/fstab'
[16:31] <doko> jamespage, can the neutron-plugin-nuage neutron-plugin-opencontrail neutron-plugin-sriov-agent ceilometer-agent-ipmi be demoted? if not please seed
[16:32] <jamespage> doko, they can indeed
[16:32] <jamespage> be demoted that is
[16:32] <doko> ok
[16:32] <smoser> wait. strike that comment.
[16:33] <smoser> well. i had failed to actualy make the change. but the change doesn't seem to have affect.
[17:46] <zerick> Has anybody used travis-ci.org to build debian packages ?
[17:47] <geofft> zerick: paulproteus has some scripts to use pbuilder at https://github.com/paulproteus/travis-debcheck
[17:47] <geofft> haven't played with them myself. I hear they're incredibly fragile but also work way better than you'd expect
[17:48] <geofft> the use case is automated testing, not actually distributing the packages to anyone.
[17:53] <zerick> I see
[18:03] <slangasek> smoser: hmm ok
[18:05] <smoser> maybe its a rathole.
[18:05] <smoser> but i'm stuck on why this would be different per arch.
[18:05] <smoser> it could just be race condition and luck on intel i guess.
[18:18] <slangasek> smoser: is udev running at the point it gets stuck?
[18:24] <smoser> slangasek, you have a suggestion on how to know that ?
[18:26] <slangasek> smoser: hack the system to open a root shell somewhere that you can get access to it (VT?) in early boot
[18:28] <zbenjamin> tedg: ping
[18:29] <smoser> slangasek, not terribly easily. i'm just going to add a start on started job. and sleep N, then start printing debug info
[18:30] <tedg> zbenjamin, Howdy
[18:52] <slangasek> smoser: so on the x86 machine you're passing 'ro' on the commandline, but not on the power one?
[18:53] <smoser> same on both.
[18:54] <smoser> passing 'rw' "fixes"
[18:55] <smoser> slangasek, http://paste.ubuntu.com/8644088/
[18:55] <pitti> mvo_: I filed bug 1384864 about what we talked about this morning
[18:55] <smoser> that is with 'my-debug.conf' providing the debug output there (http://paste.ubuntu.com/8644091/)
[18:59] <mvo_> pitti: thanks, added and I am running the extraction again
[19:04] <pitti> mvo_: danke!
[19:05] <pitti> infinity: \o/
[22:03] <zbenjamin> tedg: already solved, we talked in the coffee break about the UbuntuAppLaunch python typelib
[22:21] <Mirv> doko: were you interested in gdb bugs as well? my vague memory served me poorly, but the "gcc" bug I mentioned was actually gdb bug #1332484. still there in utopic though, so there's nothing to backport.