[01:58] <mdeslaur> infinity, slangasek: I've put some test packages that enable amd64 flash here, and would really appreciate your invaluable comments, especially for the oneiric version : https://launchpad.net/~mdeslaur/+archive/64bitflash
[04:14] <pitti> Good morning
[04:15] <ajmitch> morning pitti
[05:17] <pitti> ev: congrats, bcmwl wifi is now rather painless indeed!
[05:17] <pitti> ev: seems it's one tiny step away from perfection :) (bug 872119)
[05:52] <micahg> @pilot in
[07:07] <dholbach> good morning
[08:00] <ev> pitti: argh. that one is entirely my fault and will take all of two seconds to fix
[08:00] <pitti> ev: not a dealbreaker; it makes it a whole lot more easy to use broadcom cards :)
[08:01] <pitti> ev: does that only affect bcmwl, or other wifi (such as intel), too?
[08:03] <ev> pitti: the copying of network-manager's brain to the installed system is broken, so it'll affect any card
[08:03] <ev> so the user will have to re-enter their wifi password
[08:03] <ev> and they'll all see that error dialog
[08:04] <pitti> ev: that more or less just copies /etc/NetworkManager/system-connections/*, or is there more to it?
[08:08] <ev> pitti: correct
[09:21] <micahg> @pilot out
[09:22] <ev> @pilot in
[11:08] <tumbleweed> can someone in ubuntu-branches please reject https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107
[11:08] <tumbleweed> and mark https://code.launchpad.net/~jtaylor/ubuntu/natty/meld/meld-sru/+merge/72410 as merged (or whatever we do for SRUs targetted at the release branch)
[11:15] <tumbleweed> https://code.launchpad.net/~jtaylor/ubuntu/natty/pycryptopp/sru-811721/+merge/75850 is also uploaded
[11:18] <tumbleweed> https://code.launchpad.net/~rye/ubuntu/natty/bindwood/update-firefox-6-compat-fix/+merge/76055 appears to be rejected
[11:22] <doko> Laney, did you sort out the cairo-dock debian/upstream miscommunication?
[11:28] <tumbleweed> cjwatson / james_w: two more to mark Merged: https://code.launchpad.net/~brunoqc/ubuntu/natty/lfm/lfm-fix-786491/+merge/77859 https://code.launchpad.net/~jtaylor/ubuntu/natty/singularity/fix-576504/+merge/78286
[11:28] <tumbleweed> that's it
[11:39] <Laney> doko: no, we should get on that as well
[14:19] <pitti> tumbleweed: done all but the bindwood one; what's with that one?
[14:34] <tumbleweed> pitti: I guess micahg is the pbest person to answer that one, but I'm assuming the fix is going into a different sourcepackage...
[14:41] <slangasek> jamespage: before setting plymouth:debug, were you able to reproduce bug #849414 consistently?
[14:42] <jamespage> slangasek: I was able to; however I appear to have stopped hitting that issue
[14:42] <slangasek> jamespage: so reverting plymouth:debug doesn't cause it to reappear either? :(
[14:43] <jamespage> slangasek, I running with it off now with no issues
[14:43] <jamespage> slangasek, so I was thinking about what had changed; I was getting an ugly text based splash when I saw the issue
[14:44] <slangasek> ah
[14:44] <jamespage> setting debug turned that off - and the issue went away
[14:44] <slangasek> that's helpful info :)
[14:44] <slangasek> right, I don't think setting debug turned it off, I think something else I did turned it off :)
[14:44] <slangasek> and your debug change just happened to coincide with other initramfs fixes
[14:44] <jamespage> slangasek, quite possibly
[14:46] <slangasek> jamespage: you could try re-breaking the graphics display by removing the plymouth-theme-ubuntu-logo package
[14:46] <jamespage> slangasek, sure - give me a couple of minutes
[14:47] <jamespage> slangasek, do you want me to turn debug on as well?
[14:48] <slangasek> jamespage: I'd try first without turning on debug (in case it's timing-sensitive), then if that reproduces the issue, turn on debug
[14:48] <jamespage> slangasek, ack
[14:54] <jamespage> slangasek, hmm - not able to reproduce
[14:55] <slangasek> jamespage: and it was 100% reproducible before?
[14:55] <jamespage> slangasek, yes - I turned debug mode on an off and the came and went
[14:55] <slangasek> jamespage: can I get apt logs, plus a big "here's where I turned on debugging" arrow, to try to work out what else changed on your system?
[14:55] <slangasek> jamespage: also, what's your video?
[15:00] <jamespage> slangasek, video is ATI Mobility Radeon HD 5400 Series
[15:01] <slangasek> jamespage: binary video drivers?
[15:05] <jamespage> slangasek, digging logs now
[15:05] <jamespage> slangasek, not sure whether its relevant but when I got the issues I had a really low res text based splash as well
[15:05] <jamespage> when I just tested it was much higher res
[15:05] <jamespage> slangasek, http://paste.ubuntu.com/706151/
[15:06] <jamespage> slangasek, I think I first saw this issue on the 04/11 (indeed that is the date of the crash file that jhunt and I looked at earlier)
[15:06] <jamespage> I turned debug mode on then  - and did a few reboots and could not reproduce
[15:06] <slangasek> oh heh
[15:07] <slangasek> higher res> so you've got vesafb loading and a framebuffer console, that's going to change things for sure
[15:07] <jamespage> slangasek, thats what I figured
[15:07] <slangasek> jamespage: this is with the cryptsetup package installed, right?
[15:07] <jamespage> slangasek, no
[15:07] <slangasek> hmm
[15:08] <slangasek> not sure why you would have gotten plymouth text without vesafb in that case
[15:08] <slangasek> are you using binary drivers?
[15:08] <jamespage> slangasek, yes
[15:09] <jamespage> slangasek, just to prove it - https://launchpadlibrarian.net/81898994/firegl-crash.jpg
[15:10] <slangasek> :-)
[15:10] <jamespage> thats from a diff bug
[15:11] <jamespage> looking at what i wrote on bug 865984
[15:12] <hallyn_> slangasek: if you get a moment, can smoser and I ping you about a glibc bug and the likelyhood of it being considered fixable by upstream?
[15:12] <jamespage> I appear to have had a vesafb/framebuffer console until shortly before the 04/11
[15:13] <jamespage> I raised that bug the same day I did the plymouth debug stuff
[15:17] <slangasek> hallyn_: just ask directly please :-)
[15:19] <cnd> seb128, is there still time to get the libgrip fix into oneiric? or should it be an sru?
[15:20] <seb128> cnd, sru
[15:20] <cnd> ok
[15:20] <seb128> cnd, which is fine we already got a stack of srus uploaded
[15:20] <seb128> including compiz
[15:20] <cnd> ok
[15:20] <cnd> I'll prepare an sru upload then
[15:21] <pitti> Laney: wow, I wouldn't have expected breezy to top the upload score -- we had way fewer devs back then
[15:21] <pitti> Laney: well, maybe we uploaded 25 sets of langpacks :)
[15:22] <Laney> yeah, not sure what that is about
[15:22] <Laney> let me do the last query but s/oneiric/breezy/
[15:22] <pitti> actually, it would be interesting to filter out all language-pack-* stuff
[15:22] <Laney> the data is all in udd ;-)
[15:23] <tseliot> slangasek: I'm seeing a lot of complaints on arm from apps such as gconf and metacity looking for gconfd-2 in /usr/lib/i386-linux-gnu/libgconf2-4/ instead of using /usr/lib/arm-linux-gnueabi/libgconf2-4/. There must be something wrong with my multi-arch setup here. Any ideas? (not a symlink works around the problem)
[15:24] <hallyn_> mdeslaur: Bug 871847, I assume needs to wait for an SRU at this point?  :)
[15:25] <hallyn_> slangasek: ok, i'm about to be afk for a few mins, but the problem basically is that grantpt in glibc starts out with a check for whether /dev/pts/{ptnum} is a valid slave.  WIth /dev/pts being hardcoded.  So if you call grantpt on /chroot/dev/pts/0, and /dev/pts/0 does not exist, the call will fail.
[15:25] <mdeslaur> hallyn_: yep, universe just went into freeze
[15:25] <hallyn_> mdeslaur: zounds!
[15:25] <hallyn_> ok, thanks :)
[15:25] <Laney> pitti: I don't think langpacks appear in -changes?
[15:26] <pitti> Laney: they don't
[15:26] <Laney> then they wouldn't be in these stats
[15:26] <pitti> Laney: ah, it's based on -changes@, not soyuz
[15:26] <hallyn_> slangasek: this is only a problem when using a newly cloned devpts, so i'm not sure if glibc will deem that valid?
[15:26] <Laney> right
[15:26] <Laney> maybe autosyncs were announced back then?
[15:26] <slangasek> tseliot: uh? i386-linux-gnu vs. arm-linux-gnueabi, what's that about?  You're saying you have an arm system, with i386 packages installed?
[15:26] <pitti> Laney: was just going to say :)
[15:26] <hallyn_> slangasek: the workaround is doable but hacky - gotta fork, unshare a new mounts ns (with privilege), bind-mount /dev/pts, and then do the grantpt
[15:27] <pitti> Laney: right, see https://lists.ubuntu.com/archives/breezy-changes/2005-April/thread.html
[15:27] <bdmurray> stgraber: should bug 813065 be Fix Released - comment 9 leads me to think no
[15:27] <slangasek> hallyn_: why do you call grantpt against a chroot?
[15:27] <pitti> for the other months, too
[15:27] <slangasek> I don't think I understand the problem, sorry
[15:27] <Laney> let me exclude that then
[15:27] <tseliot> slangasek: no, they're all for arm
[15:27] <hallyn_> slangasek: libvirt's parent process sets up /dev/pts/0 in the container's rootfs as a console for 'virsh console' to connect to
[15:28] <Laney> a much different picture emerges
[15:28] <stgraber> bdmurray: comment #9 was before Steve sent me a merge proposal fixing it properly which got merged and uploaded (comment #10)
[15:28] <hallyn_> slangasek: though in any case, since thamanpage doesn't mention anything, glibc definately is *wrong*.
[15:28] <Laney> pitti: http://paste.debian.net/135733/
[15:28] <slangasek> tseliot: but you said "There must be something wrong with my multi-arch setup here" - have you *done* some special multiarch setup?
[15:28] <bdmurray> stgraber: okay then what is going on with bug 871936?
[15:29] <pitti> Laney: still respectable, compared to warty and hoary
[15:29] <hallyn_> slangasek: (but glibc might demand the manpage fix rather than the code fix :)
[15:29] <Laney> it's actually remaining fairly steady
[15:29] <stgraber> bdmurray: I'm not sure, maybe slangasek has an idea but AFAIK ubiquity-dm now does the right thing, it may simply be an nvidia specific flicker bug
[15:29] <tseliot> slangasek: no, I did nothing at all to set up multiarch. It's just that somehow apps are looking for that path
[15:29] <Laney> but oneiric moves up to fifth :-)
[15:30] <slangasek> hallyn_: heh, indeed... I don't know, sorry
[15:30] <hallyn_> slangasek: nm, i guess i should join the m-l rather than bug you about it :)  thanks
[15:31] <slangasek> tseliot: what's the exact error message?
[15:31] <tseliot> slangasek: "failed to activate configuration server: Failed to execute program /usr/lib/i386-linux-gnu/libgconf2-4/gconfd-2: Success
[15:31] <bdmurray> stgraber: okay the patch didn't seem hardware specific to me
[15:31] <tseliot> slangasek: this comes from gnome-settings-daemon, metacity, etc.
[15:32] <stgraber> bdmurray: indeed, it fixes flickerless for any graphic card that does work correctly with flickerless
[15:32] <stgraber> bdmurray: which AFAIK isn't the case of nvidia
[15:33] <hallyn_> heh, i see, there really is no m-l
[15:33] <slangasek> tseliot: does i386-linux-gnu show up anywhere in config files under $HOME?
[15:33] <hallyn_> libc-alpha it is.  (weird name)
[15:34] <seb128> slangasek, tseliot: I know what it is
[15:34] <slangasek> seb128: oh?
[15:34] <seb128> slangasek, well, maybe not
[15:34] <seb128> slangasek, /usr/share/dbus-1/services/org.gnome.GConf.service is in gconf2-common which is arch all
[15:35] <seb128> but "Exec=/usr/lib/libgconf2-4/gconfd-2" there
[15:35] <slangasek> jamespage: when you said "04/11", you meant "04/10", right?
[15:35] <slangasek> seb128: hmm
[15:36] <jamespage> slangasek, hrm - yep
[15:36] <tseliot> seb128, slangasek: but then how would it look for i386-linux-gnu ?
[15:36] <seb128> tseliot, the arch all is built on i386
[15:36] <seb128> so it would have the i386 path
[15:36] <slangasek> tseliot: I don't know; and I've not seen such an error on amd64
[15:36] <seb128> but that doesn't seem to be it
[15:36] <seb128> the .service has non multiarch paths
[15:36] <seb128> that was just an idea, ignore me ;-)
[15:36] <tseliot> seb128, slangasek: having a hardcoded path shouldn't be too good anyway
[15:38] <ogra_> slangasek, i think i saw the same issue being discussed in #linaro this weekend
[15:38] <ogra_> there must be a bug open for it already
[15:38] <seb128> tseliot, ogra_, slangasek: is linaro or somebody shipping a multiarched version of gconf?
[15:38] <seb128> our libgconf is not on multiarch
[15:39] <tseliot> that's a good question
[15:39] <seb128> but it seems the service in arch all binary would lead to that question if somebody did a multiarch build without changing it to arch any
[15:39] <ogra_> seb128, no idea, i think they are still working on switching their image builds to oneiric
[15:39] <seb128> that's the only way I could explain it
[15:39] <ogra_> (linaro is one release behind since they do monthly releases)
[15:39] <seb128> question->error
[15:40] <seb128> ogra_, well, we need multiarched gconf
[15:40] <seb128> so that's not being "behind"
[15:40] <tseliot> slangasek: and no, I can't find any references to i386 in $HOME
[15:40] <slangasek> jamespage: are you sure you don't have cryptsetup installed?
[15:40] <seb128> it seems somebody has a custom multiarch version of gconf
[15:40] <ogra_> the error showed up for them after switching to oneiric
[15:40] <slangasek> tseliot: hmm
[15:40] <seb128> ogra_, can you ask them their version of gconf?
[15:40] <ogra_> i didnt follow that deeply, but i know they opened a bug
[15:40] <jamespage> slangasek, yes - http://paste.ubuntu.com/706181/
[15:41] <slangasek> seb128: what do you mean by "multiarched gconf"?  We should only have one copy of the daemon running...
[15:41] <tseliot> ogra_: right, I can only reproduce the problem in oneiric
[15:41] <seb128> slangasek, the service is dbus activated, if the path was multiarch specific but they have a .service in arch:all that would lead to such issues
[15:41] <slangasek> ok
[15:41] <seb128> slangasek, dbus would be trying to spawn the i386 location
[15:42] <slangasek> right; so when multiarching gconf, the daemon should be split out of the library package...
[15:42] <seb128> or the .service should be in an arch:all binary
[15:42] <seb128> so it gets the right location for each arch
[15:43] <tseliot> the latter sounds easier
[15:43] <seb128> slangasek, the daemon is already splitted out of the library
[15:43] <seb128> the issue is that the dbus service which has the service location is in gconf2-common arch:all
[15:43] <seb128> we should just move the .service with the daemon when we multiarch it
[15:44] <seb128> well, that's just guess work on what their issue is, but "/usr/lib/i386-linux-gnu/libgconf2-4/" doesn't make sense if gconf has not been changed for multiarch
[15:44] <seb128> so I guess somebody did that work in a ppa or something
[15:46] <seb128> ogra_, tseliot, slangasek:
[15:46] <seb128> https://blueprints.launchpad.net/linaro-ubuntu/+spec/multiarch-porting-11.09
[15:46] <seb128> "Convert to multiarch, gconf: DONE"
[15:47] <seb128> so yeah, "linaro bug" I guess
[15:47] <ogra_> seb128, i dont see that bug here and have no issues
[15:47] <ogra_> i just saw it being discussed by the linaro gusy
[15:47] <seb128> ogra_, well that didn't land in Ubuntu for sure
[15:47] <ogra_> *guys
[15:47] <seb128> ogra_, their workitem is DONE so I guess they have their own version somewhere
[15:47] <seb128> in any case not an Oneiric issue ;-)
[15:47] <ogra_> oh, its a linaro spec
[15:47]  * ogra_ missed that
[15:49] <ogra_> there it is
[15:49] <ogra_> bug 871892
[15:50] <tseliot> ogra_, seb128, slangasek: that's the exact bug that I'm seeing here
[15:50] <seb128> tseliot, what do you use? linaro or Ubuntu?
[15:51] <ogra_> it was actually discussed yesterday ...
[15:51] <tseliot> seb128: ubuntu
[15:51] <seb128> tseliot, dpkg -l | grep gconf
[15:51] <ogra_> seb128, linaro builds their oneiric images from our archive plain, no additions but HW bits yet
[15:51] <ogra_> they only start to work on oneiric this week
[15:52] <seb128> ogra_, that doesn't make sense, gconf is not multiarch in Ubuntu, if it was I would knew it
[15:52] <ogra_> seb128, right
[15:52] <tseliot> seb128: it doesn't seem to return anything
[15:52] <seb128> tseliot, you don't have gconf installed? how did you do your install?
[15:52] <ogra_> seb128, i dont kno wabout multiarch, what i know is that linaro only starts working on a release once ubuntu released it
[15:52] <seb128> we still have a stack of things in the default install using it
[15:52] <ogra_> so atm what they use should be plain ubuntu
[15:53] <ogra_> since they only switched image builds to oneiric this week
[15:53] <seb128> ogra_, well with their own layer or ppa on top I guess
[15:53] <ogra_> for kernel and bootloaders,. yep
[15:53] <seb128> ogra_, seeing  https://blueprints.launchpad.net/linaro-ubuntu/+spec/multiarch-porting-11.09 they need multiarch conversions over what oneiric has
[15:53] <ogra_> but no desktop bits yet
[15:54] <ogra_> right, that might be, i can only comment on what i observed ... i dont work in linaro :)
[15:54] <tseliot> seb128: apt-cache show gconf shows the installed size among other things
[15:54] <tseliot> seb128: err... gconf2
[15:54] <seb128> tseliot, how did you do your install? it's puzzling that you don't have gconf installed... are you sure you didn't type dpkg -l | grep gconf?
[15:55] <seb128> type->typo
[15:56] <tseliot> seb128: yes, I typed it 3 times. I used our installer (which is probably the same as linaro)
[15:56] <ogra_> no
[15:57] <ogra_> linaro doesnt use any installer, they just install a metapackage in a chroot and tar that up
[15:57] <tseliot> ogra_: we're doing something similar, through the usual live-helper though
[15:58] <ogra_> well, ubuntu installs tasks etc ... might get you minimally different results
[16:16] <seb128> slangasek, just for the record it's indeed a linaro ppa with a multiarched version which has the .service in the arch all binary
[16:17] <seb128> slangasek, i.e not an Ubuntu bug (tseliot get the issue on a custom build, not on an Ubuntu install)
[16:17]  * tseliot nods
[16:25] <slangasek> seb128: ah, heh
[16:25] <slangasek> jamespage: did you for any reason set FRAMEBUFFER=y manually in your initramfs config?
[16:26] <jamespage> slangasek: no - I've not touched it
[16:27] <slangasek> jamespage: mmk
[16:27] <stgraber> SpamapS: I just posted the generate /etc/network/interfaces to bug 870214
[16:27] <stgraber> SpamapS: is it normal that the boot waits for 2 minutes with a /etc/network/interfaces like this one?
[16:28] <slangasek> jamespage: oh - could you try setting 'gfxpayload=text' manually in your /boot/grub/grub.cfg, instead of the default gfxpayload=$linux_gfx_mode?
[16:28] <jamespage> slangasek: OK
[16:28] <SpamapS> stgraber: it is normal that it would be waited on if eth0 doesn't exist
[16:29] <SpamapS> stgraber: since we're waiting for the full configuration of eth0. While its waiting, has eth0 been initialized by the kernel?
[16:29] <stgraber> SpamapS: hmm, I don't know for jamespage's setup, but I'm pretty sure eth0 existed in his case
[16:29] <stgraber> SpamapS: it's netboot with root on iscsi, so yes eth0 is initialized by ipconfig in the initramfs
[16:30] <SpamapS> Hm, so is it possible that we never get an 'ifup eth0' for that?
[16:30] <SpamapS> I would have thought 'ifup -a' would catch it in /etc/init/networking.conf
[16:32] <stgraber> sadly my test environment here lets me install over iscsi but not boot from it (I'm missing my usual PXE server ;))
[16:32] <stgraber> oh, actually I guess I can extract the kernel and initrd and have kvm boot that directly
[16:32] <jamespage> stgraber, SpamapS: I still have one of the test images locally if you want me to poke it in any way
[16:33] <slangasek> SpamapS, stgraber: there should still be a network-device-add event which should still cause upstart to trigger an 'ifup eth0' - but what happens if you run 'ifup eth0' for this?
[16:33] <SpamapS> I'd guess then that the problem is ifup -a doesn't, for whatever reason, see eth0 as needing to come up.. and so doesn't execute the if-up.d jobs.
[16:33] <slangasek> it's not even an ifup -a
[16:33] <slangasek> it's /etc/init/network-interface.conf
[16:33] <SpamapS> Oh so you still get the network-device-added ?
[16:33] <slangasek> of course
[16:33] <slangasek> that comes from udev from coldplugging
[16:33] <SpamapS> well then wtf :)
[16:34] <SpamapS> is it possible thats happening before virtual-filesystems ?
[16:34] <slangasek> no
[16:34] <SpamapS> ah right, udev starts on virtual filesystems
[16:37] <stgraber> jamespage: is commented the two lines for eth0 in /etc/network/interfaces fixing the issue for you?
[16:38] <stgraber> (looking for a workaround)
[16:38] <jamespage> stgraber: rings a bell - lemme try
[16:39] <stgraber> slangasek, SpamapS, jamespage: Current discussion here (with Daviey) is that we could probably just release note the workaround for now, then SRU a fix if that doesn't involve changing /etc/network/interfaces, otherwise just have it fixed for P
[16:40] <stgraber> assuming commenting these lines workarounds the issue for jamespage
[16:40] <jamespage> stgraber: I don't think that its an issue thats going to impact alot of people so thats prob fine
[16:41] <jamespage> slangasek, just tried gfxpayload=text == no seg fault
[16:41] <stgraber> jamespage: yeah, it's also a case where if you boot a server, you'll already wait 5 minutes for your BIOS, waiting 2 minutes for your first boot shouldn't be too bad (assuming you know the workaround and apply it then)
[16:41] <slangasek> jamespage: did you get the 640x480 text again?
[16:42] <jamespage> slangasek, I think so - ssd so boots fast - lemme double check
[16:43] <jamespage> stgraber: commenting the entries in /etc/network/interfaces works around the issue for me
[16:44] <stgraber> SpamapS: ok, so we at least have a workaround
[16:45] <slangasek> stgraber: why do we want this 'manual' entry in /e/n/i?
[16:47] <stgraber> slangasek: I can't think of a good reason for that, though I still think "inet manual" should work as it's valid syntax
[16:48] <slangasek> should work, but it's meant for interfaces where you're going to actually *do* something via up/down rules
[16:48] <slangasek> AFAICS this is a misuse of it; so if we can fix the bug by dropping that generated entry...
[16:48] <jamespage> slangasek: double checked - did boot in 640x480 text mode
[16:48] <slangasek> jamespage: and still no crash?  Great, I'll mark the bug as fixed ;P
[16:49] <jamespage> slangasek: no crash
[16:49] <stgraber> slangasek: well, then I'll be happy to file another bug when I upgrade my servers where I have "inet manual" with a post-up and pre-down entry
[16:49] <stgraber> as they'll be affected by the same bug with a config that actually does something
[16:49] <slangasek> stgraber: or open an ifupdown task to go with the open-iscsi one
[16:50] <slangasek> and we can fix open-iscsi pre-release, and fix ifupdown post-release
[16:50] <SpamapS> slangasek: agreed on that, an empty manual entry is a place holder we don't need
[16:50] <SpamapS> Could it be that ifupdown agrees, and ignores it?
[16:51] <slangasek> dunno, testing
[16:52] <andreasn> jcastro, ping
[16:52] <jcastro> andreasn: hi
[16:52] <slangasek> SpamapS: I do see if-up.d scripts being run for my ifup of a manual interface, anyway
[16:59] <slangasek> SpamapS: and 'ifup foo' gets me a static-network-up event, so... dunno
[16:59] <slangasek> stgraber: ^^
[16:59] <SpamapS> what about the upstart udev bridge
[17:00] <slangasek> stgraber: I'd suggest throwing some debugging into /etc/network/if-up.d/upstart to dump to a per-interface log file and see what's going on
[17:00] <SpamapS> is it racing with udev ?
[17:00] <SpamapS> like..
[17:00] <SpamapS> it starts on starting udev ..
[17:00] <stgraber> jamespage: can you try that ^
[17:00] <SpamapS> but does it return before its actually bridging?
[17:00] <slangasek> SpamapS: no, it always starts *before* udev and sits waiting on the netlink socket
[17:00] <slangasek> er
[17:00] <slangasek> SpamapS: I hope not :P  I guess I can look
[17:00]  * SpamapS peeks at it too
[17:00] <stgraber> slangasek: still working on getting my laptop back into a usable stage (for some reason my last reboot broke something) and then I'll try to get a complete iscsi setup for testing
[17:01] <slangasek> stgraber: ok :)
[17:02] <SpamapS> slangasek: no, as I would have expected, it adds the udev monitor before daemonizing
[17:03] <slangasek> SpamapS: right - I think we would be hearing about more things broken than just this, otherwise :)
[17:04] <SpamapS> if booting with --verbose , do we see the network-device-added event ?
[17:11] <slangasek> stgraber, SpamapS: I've changed my mind; there are legitimate corner case reasons why we want the entry for the interface... so network-manager doesn't even try to touch it :P
[17:11] <slangasek> stgraber: so I don't think we should change open-iscsi for release, but instead just SRU ifupdown (once we figure out what the problem is!)
[17:12] <stgraber> slangasek: sounds good. I'll mark the bug as invalid for open-iscsi, we already have a task for ifupdown and the release notes
[17:16] <hallyn_> smoser: I emailed the glibc-alpha m-l about the grantpt issue.  We'll see what they say
[17:16] <jamespage> stgraber, I logged some debug output with the manual entry in /e/n/i present and commented - neither generates any log data for eth0 from  /etc/network/if-up.d/upstart
[17:16] <hallyn_> (I'm expecting a spanking, tbh, but hopefully not)
[17:16] <jamespage> only get a file for lo
[17:17] <stgraber> SpamapS: ^
[17:17] <smoser> hallyn_, link ?
[17:19] <hallyn_> smoser: http://www.cygwin.com/ml/libc-alpha/2011-10/msg00008.html
[17:24] <SpamapS> jamespage: can you boot with --verbose and look in /var/log/boot.log for the net-device-added event ?
[17:24] <jamespage> SpamapS, sure
[17:24] <slangasek> stgraber, jamespage, SpamapS: I notice that open-iscsi installs an if-up.d hook of its own
[17:24] <slangasek> which sorts lexically before upstart
[17:25] <slangasek> I wonder if it's broken?
[17:25] <SpamapS> the lo hook fired...
[17:26] <slangasek> well, the hook special-cases lo ;)
[17:26] <stgraber> slangasek: oh, actually, the upstart script shipped by open-iscsi looks like it could break the boot
[17:26] <slangasek> oh excellent
[17:27] <slangasek> Oh dear
[17:27] <stgraber> I didn't even notice that thing before but that can explain a lot of things ;)
[17:27] <stgraber> http://paste.ubuntu.com/706245/
[17:28] <stgraber> I'm guessing that as the interface is already in /run/network/ifstate, it's going to be entirely ignored by ifupdown and so we won't get the event...
[17:28] <slangasek> yes, it forcibly bypasses if-up.d, it writes to /run/network/ifstate without locking, and it fails to use a proper 'instance' declaration for network-interface
[17:29] <stgraber> I'm wondering if just removing it would be enough
[17:29] <slangasek> stgraber: so it looks like an open-iscsi-specific failure after all
[17:29] <stgraber> jamespage: can you try that? ^
[17:29] <jamespage> stgraber: just doing the verbose boot - one second
[17:30] <slangasek> cjwatson: you seem to have written /etc/init/iscsi-network-interface.conf; do you recall why you were trying to prevent /etc/network/if-up.d scripts from being run for an iscsi interface?
[17:31] <stgraber> slangasek: we are going for dinner now, if it's confirmed that it works fine without the upstart job, I'll just remove it and upload to -proposed
[17:31] <slangasek> bug #457767
[17:31] <slangasek> stgraber: enjoy :)
[17:31] <SpamapS> slangasek: I would concurr with stgraber's assessment, this script does look like its our culprit.
[17:32] <SpamapS> slangasek: or, your assessment, somebody's
[17:32] <slangasek> SpamapS: yep - question is how we fix it... we shouldn't just drop it without taking care on upgrade to make sure users don't have configuration for the interface in /etc/network/interfaces that's going to cause the system to blow up on next boot
[17:33] <SpamapS> yeah this bug-ectomy requires some delicate scalpel work
[17:34] <SpamapS> I'm not sure why the author wanted to avoid the *.d scripts
[17:34] <slangasek> "the author" being cjwatson
[17:34] <SpamapS> ok, so we can ask him. :)
[17:35] <SpamapS> because that is precisely the issue we have, is that they were avoided
[17:35] <slangasek> yep
[17:37] <jamespage> SpamapS, stgraber, slangasek: --verbose boot - http://paste.ubuntu.com/706249/
[17:38] <slangasek> jamespage: yep, that's consistent with our theory.  kill /etc/init/iscsi* and try again?
[17:39] <jamespage> slangasek, appears to be much happier
[17:40] <jamespage> stgraber: ^^
[17:40] <jamespage> no network failsafe and I can see log data for eth0 as well as lo
[17:43] <slangasek> jamespage: thanks; can you send that info to the bug?
[17:46] <jamespage> slangasek, done
[17:46] <slangasek> jamespage: cheers :)
[17:46] <jamespage> np
[17:51] <SpamapS> slangasek: I don't see anything in the default server install that would be "bad" during if-up.. I was thinking though, don't we need to make sure eth0 is never brought down?
[17:52] <slangasek> SpamapS: certainly
[17:53] <SpamapS> I don't think it will be brought down but wondering if maybe some scripts down/up the interface.
[17:55] <slangasek> nothing should for interfaces not explicitly configured to have such things done
[17:55] <slangasek> (e.g., bridge interfaces)
[17:55] <SpamapS> just trying to reason why we'd want to avoid those scripts
[17:55] <SpamapS> a lot of them make some pretty strong assumptions
[17:56] <SpamapS> though one might be able to argue that most iSCSI root boxes don't share the iscsi interface with the general network connection... it should still be possible
[17:57] <slangasek> well, as cjwatson admits in his comment, this is a layering violation... and now it's biting us :)
[18:44] <slangasek> jamespage: I've struck out as far as finding anything in your apt log that will explain it; the only relevant change I see is fglrx, and the only effect that had should have been reproducible with the gfxpayload change.  Could you try downgrading fglrx to version 2:8.881-0ubuntu3, to see if it does bring back the segfault?
[18:52] <hallyn_> smoser: do you mind if i fwd your testcase for the libvirt pty probelm to the m-l?
[18:56] <smoser> oh sure, they'll have a field day.
[18:56] <smoser> :)
[18:57] <hallyn_> do you have your latest version somewhere?
[18:59] <hallyn_> otherwise i can just use the first version, that's fine.
[19:00] <smoser> i ended up trashing the instance that had your iprovements
[19:01] <smoser> https://gist.github.com/1251979 is where ih ad what i had.
[19:01] <hallyn_> smoser: thanks much
[19:09] <micahg> pitti: what was the question for me, I seem to have missed it?
[20:18] <micahg> pitti: it seems that librpc-xml-perl was demoted prematurely
[20:19] <micahg> pitti: oh, nevermind..
[20:47] <micahg> cjwatson: when we merge dpkg for P, are we going to get the hardening flags emitted like Debian is doing?
[20:50] <cjwatson> slangasek,SpamapS,stgraber: all I can really say from this vantage is that it caused a problem at the time, as noted in the comment in the script; I'm having trouble parsing my comment about /etc/network/*.d/ scripts, so it's entirely possible I was just confused
[20:51] <cjwatson> micahg: I intend to keep the flags in the environment for precise, because otherwise we'll have to convert too many packages to avoid lossage
[20:51] <micahg> cjwatson: i.e. different behavior than Debian?
[20:51] <cjwatson> micahg: for P, yes
[20:52] <cjwatson> although packages that have been converted to the new scheme in Debian shouldn't break; at worst, they'll have the flags specified twice
[20:52] <micahg> cjwatson: is this for stuff we already have in our environment or everything?  My concern is that Debian is starting to abandon hardening-wrapper usage and starting to use the dpkg buildflags
[20:53] <cjwatson> micahg: packages that ask for dpkg-buildflags output will get it, don't worry
[20:53] <micahg> cjwatson: awesome, thanks :)
[20:53] <cjwatson> I'm just not going to remove stuff that wew already have in our environment
[20:53] <cjwatson> not until Q
[20:53] <micahg> yeah, that makes sense for an LTS
[20:54] <cjwatson> stgraber: it's possible I regarded manual as a hack and didn't want to depend on it
[20:54] <cjwatson> but I don't appear to have recorded my thought process very clearly, sorry
[20:54] <micahg> cjwatson: maybe we should just leave it in the env unless it'll break stuff, ideally we do want hardening by default (but we can save that discussion for UDS Q :))
[20:54] <cjwatson> stgraber: I am a little concerned that there may be upgraded systems around that don't use the manual method
[20:54] <cjwatson> micahg: the things in the environment at the moment aren't hardening
[20:55] <micahg> ah
[20:55] <cjwatson> they're default optimisation settings and -Wl,-Bsymbolic-functions
[20:55] <cjwatson> we want to migrate to dpkg-buildflags in the long term because it offers more flexibility
[20:56] <cjwatson> for example it will make it easier to test-build the world with different compiler flags without having to use a compiler wrapper
[20:57] <SpamapS> cjwatson: its probably worth a review of the other methods and if-up.d scripts to see if they do anything we might perceive as dangerous to an iSCSI root.. if we can't find anything.. maybe just axe the upstart job.
[20:59] <cjwatson> actually
[21:00] <cjwatson> so the problem was that if you did an install with the installer acquiring its network settings by DHCP, before my hack in partman-iscsi, it got 'iface eth0 inet dhcp'
[21:00] <cjwatson> then when you did 'ifup eth0', it ran dhclient, which tore the interface down and set it back up again
[21:00] <cjwatson> and the world imploded
[21:00] <cjwatson> I think you should ignore my comment about .d scripts, it seems to be a red herring
[21:01] <kees> micahg: yeah, the trick is watching for packages that convert from hardening-wrapper/-includes to dpkg-buildflags to make sure they include +pie,+bindnow
[21:01] <cjwatson> so what this upstart job does is force ifup to do nothing for that interface, even if /etc/network/interfaces is misconfigured
[21:01] <cjwatson> removing that *might* be safe, but I would prefer to have say an 'ifpretendup' interface in ifupdown
[21:02] <cjwatson> or 'ifup --pretend' or whatever
[21:02] <micahg> kees: right, that's what I was asking about in my meek way :)
[21:02] <cjwatson> which would force the interface to be considered up (in ifstate) but not actually do any work
[21:03] <cjwatson> then we could use that in the upstart job (and fix the instance bug) and it would then be able to emit the right upstart event
[21:04] <cjwatson> although a temporary hack that might do the job for now would be to emit that event by hand
[21:04] <cjwatson> not the right fix but it would kill the delay
[21:04] <cjwatson> and should be no worse than what was there before
[21:05] <kees> micahg: I'd like to figure out some way to do build regression testing in Debian and Ubuntu that would alert when a package suddely stopped building with a flag or something, but it's seriously non-trivial to get right
[21:06]  * jdstrand waves to kees
[21:06] <kees> hi jdstrand! :)
[21:06] <micahg> kees: emit the build flags at build time, then have LP parse the logs and fail if there's a regression?
[21:06] <jdstrand> :)
[21:06] <kees> micahg: yeah, but right now the bulk of that isn't visible in ubuntu's builds since we enforce it in the compiler without flags
[21:07] <ajmitch> you'd want to build the same source both with & without flags to narrow the cause of build failures down
[21:08] <stgraber> cjwatson: http://paste.ubuntu.com/706334/ for the workaround?
[21:10] <slangasek> stgraber: that doesn't solve the issue.  If we're going to try to use this as a workaround, we ought ta have this job just call /etc/network/if-up.d/upstart with the right args
[21:10] <slangasek> (net-device-up is not the event we care about, it's static-networking-up)
[21:10] <hallyn_> smoser: well...  resposne was not unexpected but still unfortunate :)   pls let me know if my patched libvirt worked for you
[21:11] <cjwatson> yeah, may as well not add *more* layering violations I guess
[21:11] <cjwatson> does my proposed interface extension to ifup sound reasonable longer-term though?
[21:12] <cjwatson> (static-network-up not static-networking-up ...)
[21:12] <slangasek> cjwatson: what does "pretend" give you that just getting the interface properly set as "manual" would not?
[21:12] <slangasek> because the upstart hook may not be the only one we care about running
[21:13] <slangasek> I dunno, would we want avahi-autoipd to run?
[21:13] <cjwatson> may be misnamed, what I want it to do is not actually do the main body of manipulating the interface
[21:13] <cjwatson> I'm happy for it to run all the hook scripts
[21:13] <cjwatson> (as I say I think my two-year-old comment was misleading)
[21:14] <slangasek> well, perhaps not unless we FIX that hook.. again... since it's adding a stupid route instead of bringing up an address
[21:14] <stgraber> cjwatson, slangasek: http://paste.ubuntu.com/706338/
[21:14] <cjwatson> useless use of env :-)
[21:14] <stgraber> oh, indeed ;)
[21:14] <slangasek> :)
[21:14] <slangasek> otherwise, provided that works I think it looks good
[21:14] <cjwatson> do we need to handle ipv6?
[21:15] <cjwatson> appreciating the irony of me asking stgraber this
[21:15] <slangasek> :-)
[21:15] <slangasek> the hook doesn't distinguish by addrfam
[21:15] <cjwatson> I'm guessing open-iscsi is far too stupid to handle ipv6
[21:15] <stgraber> haven't seen any hardware doing IPv6 PXE yet
[21:15]  * ajmitch didn't think PXE was specced yet for ipv6
[21:15] <cjwatson> it is
[21:15] <cjwatson> well, ish
[21:15] <ajmitch> oh? that's useful
[21:15] <cjwatson> it is in uefi, I'm not sure about bios
[21:16] <cjwatson> although only a uefi version nobody has yet
[21:16] <cjwatson> so still chocolate teapot level of usefulness
[21:16] <stgraber> jamespage: still around?
[21:17] <slangasek> regardless, the upstart hook fires once for each interface and doesn't care about address family; no point trying to make the open-iscsi job fancy
[21:17] <jamespage> stgraber, yep - running iscsi root tests :-)
[21:17] <stgraber> jamespage: awesome. Can you move the upstart script back into /etc/init, revert the changes to /etc/network/interfaces (so we have the inet manual in there) and apply this diff: http://paste.ubuntu.com/706339/?
[21:18] <jamespage> stgraber, just cooking one now - no problem
[21:18] <stgraber> jamespage: then try again but with "inet dhcp" instead of "inet manual" and check that it works too and finally with the two lines commented again
[21:18] <stgraber> that should cover most of the use cases ;)
[21:27] <jamespage> stgraber: all three of those test cases work great with the patch applied
[21:27] <jamespage> \o/
[21:29] <stgraber> yeah!
[21:31] <smoser> hallyn_, tested your suggested patch
[21:31] <smoser> http://paste.ubuntu.com/706342/
[21:31] <smoser> is what i get
[21:31] <stgraber> skaet, slangasek, cjwatson: Should I push that fix to -proposed and if Daviey really wants it we copy it and rebuild server?
[21:31] <smoser> you should be able to easily recreate this now that we know how to make it so that /dev/pts/0 wont be availalble.
[21:34] <cjwatson> stgraber: yes please
[21:34] <cjwatson> 22:26 <slangasek> stgraber: ^^ so open-iscsi to -proposed please :)
[21:34] <cjwatson> (#ubuntu-release)
[21:36] <bdrung_> andersk: mozilla-devscripts fixed
[21:43] <ev> @pilot out
[21:44] <andersk> bdrung_: Alright, trying that.
[21:45] <hallyn_> smoser: ok, don't know why, that's gonna be lower priority
[21:45] <bdrung_> andersk: how long will your test take?
[21:45] <andersk> bdrung_: Almost done, I think.
[21:46] <andersk> I recompiled xul-ext-lightning after adding ‘Breaks: ${xpi:Breaks}’ to all its debian/control stanzas, and ended up with what appears to be the right thing.
[21:47] <andersk> And the result installs and works.
[21:48] <bdrung_> andersk: last chance to prevent the upload of m-d 0.29
[21:49] <andersk> I say ship it!  :-)
[21:50] <achiang> when does DIF usually occur relative to opening the archive?
[21:52] <micahg> achiang: 7-9 weeks in
[21:52] <achiang> micahg: ok, thanks
[21:53] <achiang> 7-9 weeks to get a new package in then. :-/
[21:53] <micahg> achiang: no, you can request new stuff up to feature freeze, DIF is the automatic sync
[21:53] <achiang> oh, how long is feature freeze?
[21:54] <micahg> achiang: 2 months before release
[21:54] <achiang> micahg: ok thanks
[21:54] <micahg> achiang: the earlier the better though :)
[21:54] <achiang> micahg: yes, it's a somewhat tricky package, and i'm going the debian route
[21:55] <achiang> micahg: if i can't get it into debian before feature freeze, is there an ubuntu way to get it into universe?
[21:56] <micahg> achiang: sure, REVU is still open for the moment
[21:56] <bdrung_> but the debian way is the easier way
[21:57] <achiang> bdrung_: yes, i got my package's dependency into debian just last week
[21:57] <achiang> bdrung_: but that took a while. i'm concerned about this new package i'm working on
[21:57] <bdrung_> achiang: what package?
[21:58] <achiang> bdrung_: https://forge.betavine.net/scm/?group_id=76 -- wader-core is a drop-in, API compatible replacement for ModemManager
[21:58] <achiang> bdrung_: it supports Vodafone modems really well
[21:58] <Laney> you can probably ask the same sponsor to look at this one
[21:59] <achiang> Laney: yes, that was my plan
[22:07] <sammy> anyone using auth-update-config and authing from ldap?
[22:08] <sammy> supposedly its changes to common-password in pam.d should allow using passwd to change ldap passwords. everything else is running smoothly
[22:09] <sammy> nm google is my friend :)
[22:21] <bdrung_> andersk: released :)
[22:24] <andersk> Cool.  How are we going to handle rebuilding the extension packages against the new version?
[22:26] <bdrung_> andersk: it requires manual work (adding ${xpi:Breaks})
[22:26] <bdrung_> andersk: m-d will be synced to precise. for which release do you need this feature?
[22:27] <andersk> bdrung_: I dunno, is oneiric likely to see Firefox 8 or Thunderbird 8 as an SRU?
[22:28] <bdrung_> yes
[22:31] <andersk> The status quo seems to be that a Thunderbird 8 SRU in oneiric will break Lightning, like Thunderbird 7 did during the dev cycle, and it would be nice to have the package manager detect that before it causes a real problem.
[22:32] <micahg> andersk: we'll be SRUing lightning at the same time
[22:33] <bdrung_> micahg: will you SRU mozilla-devscripts too?
[22:33] <bdrung_> micahg: or just patch the heavy stuff in?
[22:33] <micahg> bdrung_: not planning on it
[22:43] <chrisccoulson> What feature in mozilla-devscripts?
[23:42] <bdrung_> chrisccoulson: m-d 0.29 adds a ${xpi:Breaks}