[00:25] <shadeslayer> hm, is ubuntu-defaults-image something different from live build?
[00:28] <shadeslayer> ah it's just a wrapper
[03:46] <tjaalton> slangasek: yeah, sounds good
[03:46] <slangasek> tjaalton: morning
[03:46] <slangasek> fwiw I'm still looking at the rpath issue
[03:49] <tjaalton> nice :)
[03:54] <pitti> Good morning
[04:01] <pitti> bdmurray: please use UNRELEASED, dch -r, and debcommit -r with apport's ubuntu branch, so that releases get tagged properly
[04:02] <pitti> bdmurray: I tagged ubuntu7 and ubuntu9 now
[04:04] <slangasek> which is to say, please run echo DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts on all development systems :)
[04:05] <pitti> *heavily agree*
[04:05] <pitti> I thought that finally became the default now?
[04:05] <slangasek> the devscripts default has finally been changed, yeah
[04:05] <slangasek> but it'll take a bit to propagate everywhere it needs to :P
[04:15] <tjaalton> slangasek: all I could find was commit 37c3cbe05380 that mentions that "libtool uses rpath instead of runpath for nonstandard prefixes". dunno if multiarch triplet matters here, maybe not
[04:16] <slangasek> tjaalton: it doesn't; the fact that we're copying from the build tree instead of DESTDIR may though, I'm looking to see if I can fix that
[04:17] <tjaalton> ahh right the dri-drivers?
[04:17] <slangasek> tjaalton: yeah
[04:58] <slangasek> tjaalton: the swrast dri driver is being built on !x86 but not installed anywhere; do you know why?
[05:00] <slangasek> looks like it might be a regression vs. unstable
[05:01] <tjaalton> could be
[05:01] <tjaalton> the llvmpipe driver is also called swrast
[05:01] <tjaalton> which one is it?-)
[05:04] <tjaalton> it's handled separately in rules
[05:07] <tjaalton> don't see why it wouldn't get copied there
[05:07] <tjaalton> btw, is it possible to echo to stderr from an upstart job?
[05:08] <tjaalton> ah got it
[05:08] <slangasek> tjaalton: the DRI one (i.e., the one being used on !x86) isn't getting installed
[05:09] <slangasek> so, I think my cleanup is correct
[05:09] <tjaalton> it should build the llvm one on armhf now
[05:11] <slangasek> tjaalton: where do you see anything that installs the swrast driver in the non-gallium case?
[05:11] <slangasek> anyway, doesn't matter, I'm deleting the special-handling of _dri.so in debian/rules now :)
[05:11] <tjaalton> build/dri/${DEB_HOST_MULTIARCH}/*_dri.so  usr/lib/${DEB_HOST_MULTIARCH}/dri
[05:11] <tjaalton> in libgl1-mesa.dri.install*in
[05:14] <slangasek> tjaalton: ah, right
[05:15] <tjaalton> before your cleanup anyway :)
[05:16] <slangasek> tjaalton: yeah... makes sense now that you say it, I was making the mistake of comparing my build tree which *does* have the gallium version, for the rules for installing when it doesn't :)
[05:16] <tjaalton> yeah it's confusing "at times"..
[05:16] <slangasek> anyway, this fix is looking good... and should reduce confusion :)
[05:16] <tjaalton> excellent
[05:31] <slangasek> tjaalton: ok, pushed - see if that looks sane to you?
[05:39] <tjaalton> slangasek: thanks, I'll check it in 20min
[06:09] <tjaalton> slangasek: yep, looks good
[06:53] <slangasek> tjaalton: libxatracker.so.1.0.0 doesn't seem to be a well-linked library; lots of undefined symbols, missing dependencies on -lm and -ldl
[07:02] <tjaalton> slangasek: so it seems, a regression from the earlier series
[07:03] <tjaalton> slangasek: did you try it on arm btw, would be nice to know if the llvmpipe swrast works at all
[07:03] <slangasek> tjaalton: just finished building here; I won't get to test it until tomorrow
[07:04] <tjaalton> ok
[07:14] <dholbach_> good morning
[07:14] <pitti> hey dholbach_
[07:14] <dholbach> hey pitti
[08:59] <pitti> there, apport support for package hooks in /opt
[08:59]  * pitti hugs dholbach
[09:23]  * dholbach hugs pitti back :)
[09:23] <seb128> doko, hey, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-dummy/+bug/949600 ... you wrote "the package itself looks ok for main.", does it mean the MIR is acked? (need it to run some tests)
[09:34] <ajmitch> pitti: thanks :)
[09:37] <pitti> RAOF, tjaalton: xserver-xorg-video-modesetting is not installable (http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html), which breaks image builds; is that known?
[09:37] <cjwatson> pitti: already fixed, see -release
[09:38] <pitti> BTW, we have http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html, so we can do such transitions in -proposed and only move to release once everything is ready
[09:38] <pitti> cjwatson: thanks
[09:41] <dholbach> 845533
[09:41] <dholbach> wrong window obviously :)
[09:43] <iainfarrell> dholbach: but what will we be granted access to? ;)
[09:43] <iainfarrell> are you ordering a huge number of buttons perhaps? :)
[09:44] <dholbach> iainfarrell, let me just have a few small secrets of my own :)
[09:44] <iainfarrell> dholbach: well ok … just this once :D
[10:55] <ev> mpt, mvo: I've replied to the merge.
[10:55] <ev> so excited!
[10:55] <ev> I need to make the changes on the backend to start accepting these
[10:56] <ev> but I'll get on that today
[11:26] <mr_pouit> seb128: dropping gtk2 support of indicator-sound right before feature freeze isn't very nice :(
[11:26] <mr_pouit> (as in, no time to reintroduce it)
[11:27] <FourDollars> Hi, I encounter some problem when executing `bzr branch lp:ubuntu/precise/totem`.
[11:29] <Laney> FourDollars: can you be slightly more specific? ;-)
[11:29] <seb128> mr_pouit, hum, better after feature freeze right?
[11:30] <seb128> mr_pouit, I wrote an email "System indicators will drop GTK2 support in quantal" to ubuntu-devel to July 29 ... it's not like it was not announced
[11:30] <seb128> mr_pouit, gtk2 support was already dropped from other indicators earlier in the cycle, that's just finishing that work
[11:30] <mitya57> Laney, FourDollars: confirmed
[11:30] <mitya57> bzr: ERROR: Revision {package-import@ubuntu.com-20120109161939-wfwd46cy3ytl1qq3} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
[11:30] <seb128> to July -> on July
[11:31] <FourDollars> Laney: When I execute `bzr branch lp:ubuntu/precise/totem`, it returns "bzr: ERROR: Revision {package-import@ubuntu.com-20120109161939-wfwd46cy3ytl1qq3} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".".
[11:31] <mr_pouit> seb128: (June, noy july anyway)
[11:31] <cjwatson> FourDollars: #bzr or #launchpad would be better to work on this
[11:31] <FourDollars> cjwatson: Thanks.
[11:32] <seb128> mr_pouit, oh, you are right ... well that's even earlier ;-)
[11:32] <mitya57> xnox: I can reproduce the build failure on neither up-to-date quantal chroot nor up-to-date debian sid :(
[11:32] <mitya57> xnox: can you?
[11:32] <seb128> mr_pouit, sorry but I don't think that was badly communicated or handled, you could have replied to the email if that was creating issue, I wrote it for that, so we could sort out problems early :-(
[11:32] <mr_pouit> seb128: It didn't seem to me that the thread was closed (micahg sent a list of used indicators, but you never replied)
[11:33] <xnox> mitya57: my host is amd64, I have tried quantal sbuild i386 & amd64. I can't reproduce either.
[11:33] <mr_pouit> seb128: anyway, we'll see with the release team for the exceptions to reintroduce the gtk2 indicators we need, I guess
[11:33] <seb128> mr_pouit, oh, I discussed it with micahg on IRC back then I think but forgot to follow up on the list :-(
[11:33] <mitya57> xnox: so there's something wrong on LP...
[11:34] <xnox> mitya57: I will ask on #ubuntu-release
[11:34] <seb128> mr_pouit, ok, that makes sense, I guess a ffe for that should be fine
[11:34] <mitya57> xnox: joined
[11:50] <micahg> seb128: you offered to upload the old stack renamed at the same time IIRC
[11:50] <seb128> micahg, I doubt I would ever do that, I said I was fine with the idea
[11:51] <seb128> micahg, we dropped gtk2 support because we don't have time to spend on gtk2 support, I doubt I would have offered to spend the same amonth of time bringing back old versions to universe for other flavors
[11:58] <micahg> hrm, I can't seem to find the conversation on IRC...
[12:04] <mvo> ev: awsome, thanks a lot, I address the excellent points later today :)
[12:38] <cjwatson> shadeslayer: new live-build/livecd-rootfs uploaded; with any luck it will even work
[12:44] <shadeslayer> cjwatson: thanks, will give it a spin later on tonight
[13:21] <rvr_> Hi. I updated to Quantal and have problems with nvidia, so I cannot log in Unity. I'm trying to use nouveau, but apparently there is some issue with it too.
[13:22] <rvr_> The nouveau driver loads. However, I think there is some issue with this: /dev/dri/card0: No such file or directory
[13:22] <Debolaz> rvr_: Graphics seems to be a big clusterfrack at the moment. It's being worked on. :)
[13:22] <rvr_> I booted Quantal from the install CD, and /dev/dri/card0 is created there
[13:32] <mlankhorst> :s
[13:32] <mlankhorst> rvr_: anything in xorg log?
[13:36] <rvr_> mlankhorst, X fallbacks to fb. I've tried to enable modeset in grub, but didn't fix it  http://paste.ubuntu.com/1160806/
[13:37] <mlankhorst> [    26.147] (EE) [drm] failed to open device
[13:37] <mlankhorst> [    26.216] (EE) [drm] failed to open device
[13:37] <rvr_> Yup
[13:37] <mlankhorst> anything in dmesg?
[13:38] <rvr_> mlankhorst, http://paste.ubuntu.com/1160810/
[13:39] <mlankhorst> [   22.885528] nouveau: `192MB' invalid for parameter `vmalloc'
[13:39] <mlankhorst> What does /proc/cmdline say?
[13:39] <rvr_> Yeah, that options is another thing I tried, without luck
[13:40] <mlankhorst> well it's causing nouveau not to load most likely..
[13:40] <rvr_> BOOT_IMAGE=/boot/vmlinuz-3.5.0-11-generic root=UUID=24acabd4-2fcb-49aa-9fb3-ce9e657d4465 ro quiet splash nomodeset vt.handoff=7
[13:41] <mlankhorst> lspci?
[13:41] <mlankhorst> sudo lspci -vvv
[13:42] <rvr_> http://paste.ubuntu.com/1160820/
[13:44] <mlankhorst> it can use nouveau, it just won't? What's going on there..
[13:44] <mlankhorst> is the nouveau module loaded?
[13:45] <rvr_> This displays nothing "sudo lsmod | grep -i nou"
[13:46] <mlankhorst> ok try sudo modprobe nouveau again
[13:46] <mlankhorst> no parameters
[13:46] <rvr_> Loaded
[13:46] <mlankhorst> anything in dmesg?
[13:46] <mlankhorst> did resolution change?
[13:47] <rvr_> I'm in the X session, let me reload it
[13:49] <nuclearbob> I've got a question about preseeding debian-installer if somebody can help with that
[13:50] <cjwatson> nuclearbob: shoot
[13:51] <nuclearbob> cjwatson, if I try to do a preseeded install from an alternate image that's a little old, I get a "no kernel modules were found" screen, and if I answer "yes" to continue the install without loading kernel modules, the install goes fine, so I want to know if I can preseed that answer
[13:51] <cjwatson> Not really; the installer is dead software walking at that point
[13:52] <nuclearbob> cjwatson, thanks, that's what I was afraid of
[13:52] <cjwatson> If it works it's by sheer luck but I really don't want to encourage you to rely on this
[13:52] <cjwatson> I mean, yes, technically you can preseed anna/no_kernel_modules to true
[13:52] <nuclearbob> cjwatson, is there a recommended way to finish the install in that situation?
[13:52] <cjwatson> But please don't
[13:52] <cjwatson> Get a newer working image
[13:53] <nuclearbob> good to know, thanks
[13:53] <cjwatson> I do not recommend doing anything with an image in this state other than using it as an rsync base for something better :)
[13:53] <ogra_> note that this happens occasionally during all development releases
[13:53] <cjwatson> Yeah, but if it happens with a current daily we do want to know about it so we can fix it
[13:54] <ogra_> (every time a new kernel abi is uploaded directly to the archive)
[13:54] <ogra_> well, we could upload kernel and d-i only to proposed
[13:54] <cjwatson> It's not usually necessary if the kernel is accepted vaguely mid-day-ish
[13:54] <ogra_> and keep it caged until everything is ready
[13:54] <ogra_> indeed
[13:55] <cjwatson> And actually it has nothing to do with kernel/d-i desync anyway
[13:55] <cjwatson> It has everything to do with d-i/seeds desync
[13:55] <rvr_> No luck
[13:55] <cjwatson> The old kernel binaries won't be removed until d-i has been rebuilt against the new ones, so there's no need to worry about staging the kernel and d-i simultaneously in -proposed
[13:55] <ogra_> ah, k
[13:56] <cjwatson> What happened this week was that Adam uploaded d-i and changed the seeds at the same time, which is usually plausible practice
[13:56] <cjwatson> Unfortunately d-i then failed to build due to something that took until the next day to fix
[13:58] <mlankhorst> rvr_: what does it say in dmesg?
[13:59] <rvr_> mlankhorst: Do I search anything specific?
[13:59] <mlankhorst> and erm.. echo 0000:01:00.0 > /sys/bus/pci/drivers/nouveau/bind
[13:59] <mlankhorst> as root
[14:01] <rvr_> bash: /sys/bus/pci/drivers/nouveau/bind: No such file or directory
[14:01] <rvr_> mlankhorst: Module is loaded
[14:02] <mlankhorst> find /sys -name nouveau?
[14:02] <mlankhorst> blegh let me check
[14:02] <rvr_> mlankhorst: http://paste.ubuntu.com/1160853/
[14:05]  * mlankhorst suspects the mxm_wmi is important somehow
[14:13] <rvr_> mlankhorst: :-/
[14:36] <mlankhorst> rvr_: well i have no idea why it wouldn't register t he pci ops, could you try removing all drm and nouveau modules and modprobe drm with drm.debug=ff ?
[14:53] <rvr_> mlankhorst, Ok, I'm finally using nouveau. I did two things. A) modprobe.d/nouveau-kms.conf "options nouveau modeset=1" B) Add Driver "nouveau" to default device in xorg.conf C) Removed nomodeset option in /etc/default/grub
[14:53] <rvr_> mlankhorst, Thanks for your help anyway :)
[14:54] <mlankhorst> why is nomodeset still default?!
[14:54] <rvr_> mlankhorst, I added it manually
[14:54] <mlankhorst> oh duh
[14:55] <mlankhorst> nouveau won't work without modeset, the fallback is gone for ages..
[14:55] <rvr_> mlankhorst, Without nomodeset wasn't working either, is something I tried (someone suggested that)
[14:56] <mlankhorst> but nouveau modeset should be the defualt
[14:56] <rvr_> The trick has been either Driver "nouveau" in xorg.conf and/or the modprobe rule
[14:56] <mlankhorst> can you isolate it please?
[14:57] <rvr_> Let's see
[14:59] <mlankhorst> the b part should be a noop so most likely a
[15:08] <kenvandine> barry, ping
[15:08] <barry> kenvandine: pong
[15:09] <kenvandine> barry, can you join #gwibber for a few minutes?
[15:12] <rvr_> mlankhorst, This is a mistery now. I removed both modprobe setting and xorg.conf line, and I still get nouveau. That leaves nomodeset at grub.
[15:12] <mlankhorst> yeah you shouldn't set nomodeset since it messes up grub..
[15:12] <rvr_> But I added it trying to get nouveau :-/
[15:13] <mlankhorst> nouveau has no nomodeset support any more..
[15:19] <rvr_> mlankhorst, Ok, now I know. I had a modprobe rule from nvdia that blacklisted nouveau. I removed that file, but still had nomodeset in grub.
[15:19] <mlankhorst> that's your problem..
[15:19] <rvr_> mlankhorst, Removing both settings allowed nouveau to load correctly
[15:29] <ambidextrvs> hi, could somebody help me to fix a booting issue in my computer with kernel 3.5.0-11? Am I in the correct forum, or where can I look for help?
[15:32] <debfx> infinity: do you have any objections to me merging clang 3.1? I have updated your arm patches but I don't know if they still work as expected.
[15:33] <infinity> debfx: They almost certainly don't work as expected, the merge is on my TODO, just hasn't been a top priority.  Bug me harder if I don't get to it in the next few days?
[15:34] <ambidextrvs> I would like to contribute debuggin the issue but I would like some help on where to look, or how to approach this issue.
[15:34] <debfx> ok :)
[16:20] <slangasek> jamespage: hi, more information needed on your bug #1028458; can you take a look?
[17:21] <cjwatson> barry: https://launchpad.net/ubuntu/+source/python-debian/0.1.21+nmu1ubuntu1
[17:21] <cjwatson> *phew*
[17:25] <dylan-m> Hey, before I go off filing bug reports and predicting the end of the world, is there some ongoing effort to bridge ubuntu-online-accounts and gnome-online-accounts? It feels like it could turn into a bit of a mess, but I'm probably missing something important :)
[17:25] <xnox> ev: there is no "admin1Codes.txt" anymore. There is admin2Codes.txt, but it doesn't look the same.
[17:25] <xnox> ev: maybe we can just get away with "admin1CodesASCII.txt" ?
[17:28] <xnox> ev: apperantly it's obsolete http://forum.geonames.org/gforum/posts/list/2902.page
[17:28] <xnox> ev: so i'll make use of ASCII only then.
[17:28] <ev> xnox: I have honestly no idea. It's been ages since I've looked at that code
[17:28] <ev> your guess is as good as mine :-/
[17:28] <xnox> =))))))
[17:28] <xnox> ok
[17:35] <xnox> ev: ERROR:  value too long for type character varying(6000)
[17:35]  * xnox giggles
[17:35] <xnox> shall I paste the name of that arabic village? =)
[17:38] <james_w> dylan-m, #ubuntu-webapps is where the people for that hang out, you'd probably have a better chance of an answer there
[17:38] <ev> xnox: probably shorter than some Welsh ones
[17:39] <slangasek> ev: nah, the longest Welsh fits... I bet Arabic is cheating because it's unicode
[17:39] <slangasek> llanfairleggomyeggopogostick is certainly < 6000 chars
[17:46] <ev> slangasek: :)
[17:47] <ev> Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch!
[17:48] <slangasek> Are you sure that's the right spelling?  I'm rather confident that I had it right the first time
[17:49] <ev> hahahaha
[17:49] <ev> you're probably right
[17:50] <ev> yay, specifying the value for fields in the URL on errors.ubuntu.com landed on trunk
[17:52] <ogra_> slangasek, FYI http://smspillaz.wordpress.com/2012/08/22/delivering-compiz-and-unity-on-the-next-wave-of-embedded-form-factors/ seems the upstream merge is done in time :)
[17:52] <slangasek> ogra_: hallelujah
[17:52] <slangasek> ev: ooh nice.  any documentation on how to use it?
[17:53] <ev> slangasek: once it's landed on production, yes
[17:53] <slangasek> ok :)
[17:53] <ev> it'll be in the next state of errors.ubuntu.com report
[17:59] <dylan-m> Ah, thanks james_w. I'll go listen in over there :)
[18:19] <adam_g> mdeslaur: ping
[18:19] <mdeslaur> adam_g: yes?
[18:20] <adam_g> mdeslaur: actually wait, maybe you're the wrong person to ask. but was wondering why bug #1025544 never made it to precise-proposed
[18:21] <mdeslaur> adam_g: sorry, I don't know...I uploaded it, and it's in the SRU team's hands
[18:21] <adam_g> mdeslaur: thanks
[18:26] <infinity> adam_g: Looks accepted to me.  *cough*
[18:28] <adam_g> infinity: according to where? https://launchpad.net/ubuntu/+source/sqlalchemy tells me there isn't anything new in -proposed or -updates, apparently im looking in the wrong place?
[18:28] <infinity> https://launchpad.net/ubuntu/+source/sqlalchemy/0.7.4-1ubuntu0.1
[18:28] <infinity> adam_g: (I accepted it seconds before I told you, hence the *cough*)
[18:29] <adam_g> :)
[18:29] <infinity> I have a soft spot for people named Adam.  Don't tell anyone.
[18:30] <adam_g> wellll in that case... :) maybe you can help with another head scratcher: bug #1021530
[18:30] <infinity> (Plus, I appreciate reviewing a 2-line and obvious code patch with a bazillion lines of test suite)
[18:33] <infinity> adam_g: The reason that seems to have failed to get proper notice is cause your 1ubuntu1.2 upload wasn't built with -v1ubuntu1, thus missing the previous changelog entry, thus not having the bug closure, thus faking out our tools.
[18:35] <infinity> adam_g: I'll promote it to -updates, cause it seems otherwise fine, but you'll have to close the bug yourself.
[18:36] <infinity> adam_g: The next time you have to overwrite an upload to -proposed with a newer version, do remember to build with -v(version_in_updates/release) so you get the full changelog represented in .changes.
[18:36] <adam_g> infinity: thats not entirely clear to me. the issue is that the original changelog that addressed the SRU bug was superceded by the FTBFS entry and no longer being tracked? or that my versinoing was wrong to begin with?
[18:36] <adam_g> ah
[18:37] <infinity> adam_g: Your versioning and changelog entries were both fine, but when you build with debuild or dpkg-buildpackage, you can pass "-v(old_version)", and everything between old_version and current_version lands in foo_source.changes
[18:37] <infinity> adam_g: Anyhow, released to updates, feel free to close the bug manually explaining such.
[18:37] <Laney> looks like it was sponsored by jamespage, btw.
[18:38] <adam_g> infinity: okay, thank you. makes sense, thanks for clarification
[18:38] <infinity> adam_g: Oh, and you can totally yell at your sponsor for that, Laney has a good point. ;)
[18:39] <infinity> (Note that I make this mistake constantly, so it's less of a yelling at and more a good-natured ribbing)
[18:39] <adam_g> 10-4
[18:40] <infinity> Or, y'know, when I do remember to use -v, I forgot to include the effin' epoch, and spam everyone with a few megabytes of libreoffice changelog.
[18:40] <infinity> Good times.
[18:41] <Laney> always page through your changes file!
[18:41]  * Laney runs
[18:41]  * Laney (to the pub)
[18:42] <infinity> Laney: Have you read a libreoffice changes file?  You tend to get bored with it long before you get to the actual changelog.
[18:42] <stgraber> infinity: I actually had to go through that .changes again today as I was scrolling through the latest working build of openoffice on LP to figure how long it usually takes on powerpc ;)
[18:43] <infinity> stgraber: *cough*
[18:44] <infinity> stgraber: I'm sure I could get a LOSA to do some revisionist history to the DB so /+changelog isn't hideous.
[19:03] <barry> cjwatson: nice
[20:13] <smoser> slangasek, stgraber it would seem our assumption that 'start networking' was no logner needed was invalid.
[20:13] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1031065
[20:14] <stgraber> smoser: well, it doesn't change the fact that doing "start networking" is wrong ;)
[20:15] <smoser> no. it does not. but i was hoping that it was fixed and that was no longer necessary.
[20:16] <slangasek> smoser: are you sure your problem isn't that static-network-up is emitted before cloud-init-nonet is started?
[20:16] <slangasek> ah, no, you check for that
[20:17] <smoser> hm..
[20:17] <smoser> juist thinking out loud.
[20:17] <smoser> i saw this issue in overlayroot development when i was failing to mount / as 'ro' in the initramfs.
[20:18] <smoser> that might give some information about what race brings this.
[20:18] <slangasek> stgraber: should there ever be network interfaces in the container case?
[20:18] <slangasek> maybe cloud-init-nonet itself should be checking for is-container
[20:18] <slangasek> (that's not the name, but)
[20:19] <stgraber> slangasek: not sure what you mean. If you're asking whether containers have standard network interfaces (ethX) and use ifupdown, then yes.
[20:19] <slangasek> no, that path should trigger network-interface-container, which emits net-device-added INTERFACE=lo, which triggers network-interface
[20:20] <slangasek> smoser: do you have an /etc/network/interfaces in this container, and does it specify the config for lo?
[20:21] <slangasek> smoser: if lo is not in /etc/network/interfaces, /etc/init/network-interface.conf brings the interface up and emits the net-device-up event as a failsafe, but the call to 'ifup' itself will be a no-op, so /etc/network/if-up.d/upstart is never called and so static-network-up isn't emitted
[20:24] <slangasek> smoser: does that description seem to fit what you're seeing / match what you have on disk?
[20:29] <smoser> slangasek, there is a /etc/network/interfaces, yes.
[20:29] <smoser> and it woudl be necessary.
[20:29] <smoser> as cloud-init utilizes static-network-up
[20:29] <smoser> which ... dont know if that woudl ever occur without it.
[20:29] <slangasek> smoser: the question wasn't if /etc/network/interfaces exists, it's if it contains a configuration stanza for lo
[20:30] <smoser> # The loopback network interface
[20:30] <smoser> auto lo
[20:30] <smoser> iface lo inet loopback
[20:30] <slangasek> ok
[20:31] <slangasek> smoser: could you run 'sudo initctl log-priority info' in the host, then run the 'sudo lxc-start', and attach the resulting syslog output?
[20:32] <smoser> slangasek, i just deleted instance. but i can do that in a bit.
[20:41] <slangasek> tjaalton: fwiw seems your change to enable swrast gallium on armhf isn't working quite right; I notice today that my package is misbuilt, and the log shows the dri swrast
[20:42] <slangasek> tjaalton: ah, spotted it; $(DEB_HOST_ARM_CPU) != armhf
[20:42] <slangasek> er, DEB_HOST_ARCH_CPU ;)
[20:43] <tjaalton> slangasek: ah, ok
[22:12] <slangasek> tjaalton: success - at least in terms of getting it to run
[22:12] <slangasek> (performance is something else entirely)
[23:59] <blaggard> hey, anyone home?