[00:00]  * SpamapS installed originally from Xubuntu
[00:00] <SpamapS> I actually like Unity + Compiz when they work. A lot. Just tired of having to restart them because of some weird issue.
[00:00] <SpamapS> has been much better the last 2 weeks
[00:57] <micahg> SpamapS: there's always unity-2d
[00:58] <SpamapS> micahg: indeed, it does seem to survive longer than unity between weirdness/crashing
[01:46] <photon> hi. I am scanning through archive.ubuntulinux.org, and I noticed that some .deb files are fairly small (just a few kb), like http://archive.ubuntulinux.org/ubuntu/pool/multiverse/u/ubuntu-restricted-extras/. why is that? shouldn't they be megabytes given how much software is in them?
[01:52] <gusnan> photon, those are probably pseudo-packages, not containing much information themself, but just dependencies on other packages with the actual stuff.
[01:53] <TheMuso> That package in partiular is a metapackage, which pulls in other packages.
[01:53] <photon> I looked into the .deb archive and in /DEBIAN/control, there are only recommendations, not dependencies, and even those are far less than what apt-get install ubuntu-restricted-extras would install. so I'm confused
[01:54] <photon> maybe I'm looking int he wrong file.
[01:55] <TheMuso> Yes, recommends are installed by default, so the recommended packages get installed.
[01:55] <TheMuso> It means that you can remove one or more of the recommended packages, and the rest of the packages don't get removed with them.
[01:56] <photon> Got it.
[04:05] <pitti> Good morning
[04:06] <pitti> doko_: vala FTBFS> looking
[05:38] <didrocks> good morning
[07:30] <SpamapS> @pilot out
[07:30] <SpamapS> oops
[07:30] <micahg> heh
[07:32] <broder> could i get a core dev to do me a favor and accept the series nomination on bug #848687?
[07:39] <dholbach> good morning
[07:39] <SpamapS> broder: done
[07:41] <dholbach> pitti, it seems like we need to bring libgdamm4.0 back if we want glom buildable at all
[07:41] <pitti> dholbach: ah, glom isn't in Debian, so they could remove it
[07:42] <dholbach> yep
[07:42] <pitti> I guess someone can reupload it
[07:42] <broder> SpamapS: thanks :)
[07:42] <dholbach> pitti, ok - I'll have a look - seems like glom does not build - maybe a more recent version will fix it
[07:44] <micahg> dholbach: upstream commented as such, but one of the build depends was removed
[07:44] <pitti> presumably that very from above, libgdamm
[07:44] <dholbach> I think upstream has a PPA - I'll have a look how much of their work we can reuse
[07:44] <dholbach> I'll let you know
[07:44] <micahg> sorry, missed that somehow...
[07:45] <dholbach> pitti, maybe glom should be part of the please-update-these-desktop-packages overview, so we don't let old versions rot in the archive again :)
[07:45] <pitti> nah, it's in universe
[07:45] <pitti> a lot of universe packages are like that unfortunately :/
[07:46] <micahg> dholbach: shows up here where it belongs: http://qa.ubuntuwire.com/uehs/no_updated.html, unfortunately, we need more people looking here :)
[07:46] <dholbach> ok :)
[07:51]  * micahg actually thinks that page is out of date...
[07:51]  * micahg moves this to -motu
[08:44] <Laney> I have been trying to unblock glom in Debian for ages :(
[08:44] <Laney> current problem is jsogo refusing to maintain goocanvas properly
[08:46] <dholbach> Laney, what's the issue?
[08:52] <Laney> the current releases need a newer goocanvasmm which needs a newer goocanvas
[08:54] <dholbach> ah ok, for now, I guess I just get 1.18.3 into Ubuntu which is the latest stable and builds
[08:54] <dholbach> for P we can try something new
[08:54] <dholbach> is it hard to get a new goocanvas into Debian?
[08:54] <Laney> kind of is if the maintainer doesn't want to do it
[08:55] <Laney> would the 1.18 release work?
[08:56] <dholbach> yes, it looks good
[08:56] <dholbach> I'm just sorting out a few other small issues while I'm at it
[08:57] <dholbach> we just need to get gdamm4.0 added back to the archive
[08:57] <dholbach> but I uploaded it already
[09:35] <dholbach> can somebody get libgdamm4.0 out of NEW please? it was removed a bit too quickly (glom needs it)
[10:12] <pitti> dholbach: done
[10:12] <dholbach> thanks pitti
[10:13] <ogra_> dholbach, do you still need an armel testbuild ?
[10:13] <dholbach> ogra_, no it's all sorted
[10:13] <dholbach> thanks ogra_
[10:13] <ogra_> :)
[10:39]  * doko can't decide if the archive looks like a garbage dump or a mortuary ...
[10:40] <pitti> looks like a big city; shiny center, but some suburbs are really chabby
[10:40] <pitti> "shabby"
[10:41] <didrocks> pitti: I like this metaphor :)
[10:43] <ajmitch> pitti: does this mean that a bulldozer needs to be driven through some suburbs?
[10:44] <pitti> ajmitch: in some cases a bulldozer, in some cases a citizen's initiative with some mortar and paint :)
[10:45] <pitti> hildon or gnome 2 panel applets were definitively in the bulldozer class, but most packages have relatively easy fixes
[10:45] <ajmitch> it's sad to see the applets go :)
[11:06] <dholbach> can somebody bulldoze libgdamm4.0 out of binary new? :-P
[11:07] <doko> fun ...
[11:07] <doko> Checking if libc on this machine contains:
[11:07] <doko> grep: library_contents: No such file or directory
[11:07] <doko>   vsprintf: No, I don't think
[11:07] <doko> grep: library_contents: No such file or directory
[11:07] <doko>     _doprnt: NO, THIS IS A PROBLEM: NO VSPRINTF AND NO _DOPRNT
[11:07] <doko> SPIM WILL NOT RUN PROPERLY
[11:07] <doko> grep: library_contents: No such file or directory
[11:07] <doko>   vfprintf: No, I don't think
[11:07] <doko> grep: library_contents: No such file or directory
[11:07] <doko>     _doprnt: NO, THIS IS A PROBLEM: NO VFPRINTF AND NO _DOPRNT
[11:07] <doko> SPIM WILL NOT RUN PROPERLY
[11:07] <doko> grep: library_contents: No such file or directory
[11:07] <doko>   strtoul: No, I don't think
[11:07] <doko> grep: library_contents: No such file or directory
[11:07] <doko>   strtol: No, I don't think
[11:07] <doko> grep: library_contents: No such file or directory
[11:07] <doko>   memcpy: No, I don't think
[11:08] <cjwatson> doko: I'm guessing multiarch fallout
[11:08] <doko> sure, I just did "like" the grep approach
[11:09] <cjwatson> dholbach: one moment
[11:09] <dholbach> cjwatson, thanks muchly
[11:11] <doko> cjwatson, ahh, already done
[11:12] <cjwatson> ah, ok, cool
[11:13] <dholbach> fantastic, thanks
[11:44] <dholbach> nice, we're down from 661 to 560 FTBFS bugs today
[11:48] <nigelb> micahg: Congrats \o/
[12:05] <ScottK> Sweetshark: What are the odds of the LO FTBFS on i386 getting fixed today?  FYI, it's breaking amd64 live CD/DVD builds at the moment.
[12:06] <cjwatson> mvo: I could use help with bug 848907; I don't see why it should have broken recently
[12:09] <Sweetshark> ScottK: Im currently building with a fix. but LO has quite some buildtime ...
[12:11] <doko> siretart, ping
[12:11] <Sweetshark> ScottK: It just went past the critical corner, so its looking good.
[12:12] <mvo> cjwatson: is that reproducable?
[12:13] <cjwatson> mvo: I reproduced it after seeing a user report of the same thing, which he's experienced both yesterday and today
[12:13] <cjwatson> mvo: haven't yet figured out how to reproduce it from the command line
[12:14] <cjwatson> regfree crash suggests memory corruption of some kind, but getting valgrind into d-i is ... painful
[12:14] <mvo> cjwatson: right, but its reproducable by installing kubuntu in a vm with the altnerative CD?
[12:15] <cjwatson> that's all I did, yes
[12:16] <mvo> thanks, I will rsync me updated images and try it out then
[12:16] <cjwatson> I would expect Ubuntu to do the same thing; we haven't got to the flavour-specific parts of installation at this point
[12:16] <cjwatson> I just made a 10G disk image and did a use-entire-disk install
[12:16] <cjwatson> en_GB locale, otherwise all defaults
[12:17] <cjwatson> will try it under strace now
[12:17] <mvo> cjwatson: great, the rsync is running. you did the install inside kvm I assume? is there a chance to get a slightly better readable backtrace then from the screenshot ?
[12:17] <cjwatson> kvm yes; maybe, will try hacking about at base-installer
[12:17] <mvo> cjwatson: I can poke the code in the meantime, there were some changes in the cdrom autodetect code recently (~4 weeks ago) that might be the issue
[12:19] <cjwatson> mvo: I think this is recent though, I didn't see it when I was preparing the partman-crypto fix this guy was testing
[12:19] <cjwatson> mvo: I wonder if it's something to do with the recent eglibc upload (and hope it's not)
[12:21] <cjwatson> I think the backtrace must be being printked or something; I guess I'll just leave it on a sacrificial console
[12:27] <doko> Laney, did the comment should go to bug 831235?
[12:28] <Laney> yes
[12:28] <Sweetshark> ScottK: the fix is uploaded to chinstrap and waiting for sponsoring.
[12:28] <Laney> doko: as in, the Debian version builds fine
[12:29] <doko> Laney, yes transient build failure, you shouldn't upgrade gcj during a test rebuild ;)
[12:29] <Laney> the current one works?
[12:29] <cjwatson> mvo: reproduced, but the backtrace goes all over tty1 even if the current console is tty3 :-(
[12:30] <Laney> there were a lot of probems that we helped the maintainer with in Debian
[12:30] <doko> yes
[12:30]  * cjwatson extracts the strace
[12:30] <doko> still running
[12:30] <Laney> arch/indep issues
[12:31] <ejat> is this bugs 847591 still in progress ? or already fix but not release
[12:34] <ScottK> Sweetshark: Thanks.
[12:35] <cjwatson> mvo: http://people.canonical.com/~cjwatson/tmp/base-installer.trace.xz - probably includes lots of junk, I'm about to start having a look
[12:36] <cjwatson> that's attaching strace to bootstrap-base.postinst after run-debootstrap has been forked
[12:40] <cjwatson> I suspect it isn't helping that locale-gen removes /usr/lib/locale/C.UTF-8 which is owned by the libc-bin package
[12:40]  * cjwatson goes to fix that
[12:49] <Sweetshark> ScottK: uploaded (thanks pitti)
[12:54] <Laney> doko: you are right, it is transient. I can't get on https://buildd.debian.org/status/logs.php?pkg=gdcm&ver=2.0.17-3.1 to remind myself what the problem was.
[12:54] <Laney> get logs from*
[12:55] <doko> Laney, I had given it back: https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2693757
[12:55] <Laney> great
[12:55] <Laney> I just knew 3.1 failed and -4 did not, but, well it's not reproducible so "oh well".
[12:56] <Laney> oh, the red text gives you the log
[12:56] <Laney> that does not look like a link.
[13:37] <cjwatson> mvo: aha, reinstall libc-bin in /target after the crash and then apt segfaults again
[13:38] <cjwatson> mvo: better screenshot attached
[13:39] <cjwatson> so almost certainly due to:
[13:39] <cjwatson>   * debian/patches/localedata/locale-C.diff: Don't include ISO14651
[13:39] <cjwatson>     collation rules in C.UTF-8 locale.
[13:39] <cjwatson> but I don't know if this represents an eglibc bug or a wrong assumption in apt
[13:41]  * cjwatson installs gdb and valgrind to try to dig further
[13:42] <stgraber> micahg: can you confirm you are now on the DMB mailing-list?
[13:44] <mvo> nice cjwatson! that is really much more helpful
[13:49] <cjwatson> mvo: ... and now valgrind output attached
[13:52] <mvo> cjwatson: thanks, I wonder if the compilation error is new or maybe triggering the bug
[13:53] <achiang> pitti: good morning, thanks for sponsoring some of my patches. i see that you created bzr branches... should i have done that on my own to save time?
[13:54] <pitti> achiang: I did?
[13:54] <cjwatson> mvo: it doesn't happen in LC_ALL=C
[13:54] <achiang> pitti: well, someone created bzr branches. :) see LP: #770862 as an example
[13:55] <cjwatson> now, I wonder if I can recreate it in an unstable chroot
[13:55] <mvo> cjwatson: *ick* it doesn't?
[13:56] <cjwatson> mvo: indeed; that's why I was suspecting that localedata change
[13:56] <cjwatson> if I can recreate it in unstable, I'll ask debian-glibc about it
[13:56] <cjwatson> there's no rationale for the change
[13:57] <pitti> achiang: presumably the auto-importer
[13:57] <achiang> pitti: ah, interesting. ok, thanks, i won't worry about it then
[13:57] <dholbach> does the publisher run every now and then nowadays? seems like libgdamm4.0 still did not make it through binary new
[13:58] <cjwatson> it's crashing
[13:58] <dholbach> ah ok :/
[13:58] <cjwatson> I'll escalate
[13:58] <dholbach> thanks a lot cjwatson
[14:00] <mvo> cjwatson: thanks, what channel? I would like to follow this - fwiw I think there is  a potential double free (or delte in this case) in the code that it worth fixing
[14:01] <cjwatson> mvo: the mailing list
[14:01] <mvo> ok
[14:02] <hallyn> WTF?  alternate installer from sunday doesn't have a kernel it can install?
[14:03] <jdstrand> pitti: hi! it just occurred to me that we don't have an equivalent of gdm-guest-session for lightdm
[14:03] <ScottK> No.
[14:04] <ScottK> hallyn: Look at the newer one.
[14:04] <pitti> jdstrand: no, it's built into lightdm
[14:04] <jdstrand> pitti: oh? are there docs on that?
[14:04] <cjwatson> hallyn: see my discussion with mvo immediately above your question
[14:04] <hallyn> ScottK: ok, thanks
[14:05] <pitti> jdstrand: docs for what? it's in the indicator and also in the greeter
[14:05] <cjwatson> ScottK: actually that wasn't really it
[14:05] <cjwatson> ScottK: that broke something slightly different ...
[14:06] <ScottK> Oh?
[14:06] <jdstrand> pitti: sorry, I was not at all clear. I meant the apparmor profile
[14:06] <cjwatson> ScottK: the weekend problem was wrong udebs on the CD, but this is apt falling over when trying to install the kernel on the target system
[14:07] <cjwatson> or actually when trying to detect what to do
[14:07] <mvo> cjwatson: I have some code that may fix the issue, it certainly fixes the double free but I'm not sure if that is enough. it seems to be only triggered (the double free) if there is a error in the regexp compilation
[14:07] <pitti> jdstrand: hm, it ought to, but now that you mention it I can't see it
[14:08] <jdstrand> pitti: shall I file a bug?
[14:08] <pitti> jdstrand: please
[14:08] <jdstrand> ok
[14:08] <pitti> jdstrand: I discussed the four bugs you mentioned on Friday with Robert this morning, FYI
[14:08] <pitti> jdstrand: one is fixed, one committed, I just sent an MP for the third
[14:09] <jdstrand> pitti: I saw. thanks! I have updated our lists accordingly
[14:10] <hallyn> cjwatson: (sorry, i'm not sure which you're pointing to, but it sounds covered, so great :)
[14:11] <m4n1sh> provided with say -lzeitgeist-1.0 can I find out to which this shared library it will link to?
[14:11] <m4n1sh> means the actual file path
[14:11] <m4n1sh> or even the name would be enough
[14:13] <jdstrand> pitti: fyi, bug #849027
[14:17] <pitti> jdstrand: thanks, bumped accordingly
[14:18] <jdstrand> cool, thanks
[14:24] <mvo> cjwatson: if I upload a new version to my PPA will you be able to easy test if my fix is sufficient (assuming the double delete is actually the real problem here)
[14:26] <cjwatson> mvo: I think so
[14:26] <doko> njpatel, re bug 817691, do you really mean glibc, not glib2.0?
[14:31] <bdmurray> superm1: Would you please look at my comments in bug 816199 and reconsider the fix?
[14:32] <slangasek> ScottK: honeyd> ack; would you like me to take this one?
[14:32] <ScottK> slangasek: Yes.  Please.
[14:32] <slangasek> ok, will do
[14:32] <ScottK> Thanks.
[14:34] <mvo> cjwatson: I uploaded it to https://launchpad.net/~mvo/+archive/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=oneiric
[14:34] <mvo> cjwatson: its building currently
[14:34] <njpatel> doko, yeah, going by what we found on Google and the other bugs in firefox etc with the same trace
[14:35] <doko> njpatel, I'd rather assume some kind of memory corruption elsewhere. really doesn't look like eglibc's fault
[14:37] <njpatel> doko, it might well be, maybe gettext?
[14:38] <doko> njpatel, then why assign it to eglibc, both ubuntu and upstream?
[14:40] <njpatel> doko, because the crash is in getenv and we needed some opinions from people familiar with that? I can guess it's in gettext but it doesn't make it so...
[14:41] <njpatel> doko, if you have a better place let me know and I'll change it asap
[14:41] <njpatel> doko, did you look at the linked bug list for the other projects?
[14:43] <doko> njpatel, there is this one new report in unity, the other list are up to years old
[14:43] <njpatel> urgh, really? what the hell was I reading then :/
[14:43]  * njpatel looks
[14:44] <doko> njpatel, and the fact that every of these apps is using gtk, is not very assuring
[14:45] <njpatel> the top 8 reports are from 2011, most of them after june/july
[14:46] <njpatel>  doko it does seem gtk is involved in most of them
[14:47] <doko> njpatel, e.g. bug 278095 is about corruption of the env
[14:49] <njpatel> doko, yep, saw that, so unity-panel-service, gnome-keyring from O and evince and gnome-session from N
[14:50] <njpatel> doko, thanks, I'll move it back to unity for now and ask upstream gtk if they have any ideas
[14:54] <doko> pitti, didrocks, mterry, Sweetshark: any idea of the relevance of bug 725250?
[14:55] <slangasek> can someone tell me why the notification area seems to have completely disappeared from my panel due to an update sometime in the past couple of weeks?
[14:56] <pitti> doko: no, it's too broken for that
[14:56] <hallyn> ScottK: fwiw, today's alternate installer is no better :(
[14:56] <mterry> doko, yeah, I don't think it's prime time yet
[14:57] <pitti> doko: bug updated
[14:58] <cjwatson> hallyn: yeah, on it :-)
[15:00] <tjaalton> irc admins available? need the bot back on #ubuntu-x
[15:00] <tjaalton> bugbot that is
[15:01] <bdmurray> slangasek: bug 553745 has some mention of it occuring again in Oneiric - subsequently I've removed the bugpattern for it so we can get another crash report in
[15:01] <superm1> sure bdmurray
[15:01] <superm1> someone with buildd knowledge, is it actually possible to call apt-get source  to fetch a source package from ftpmaster.internal on a buildd during a build?
[15:02] <slangasek> bdmurray: right, was talking to Jason about that - thanks, will be happy when we can get more info
[15:07] <hallyn> cjwatson: great, thanks :)
[15:10] <bdmurray> pitti: Could you review / merge https://code.launchpad.net/~brian-murray/apport/ubiquity-dupe-sig-improvements/+merge/75050 ?
[15:12] <pitti> bdmurray: merged, thanks
[15:17] <pitti> Riddell: "Give david.wonderly access to upstream docs" is the only remaining WI for desktop-o-kubuntu-documentation-review; is that blocked, or just needs to happen?
[15:17] <Riddell> pitti: I've no idea, I'm not working on Kubuntu
[15:18] <Riddell> pitti: but David is DarkwingDuck on #kubuntu-devel
[15:18] <pitti> Riddell: right, but that sounded like an ACL issue
[15:18] <pitti> like adding him to a team or so
[15:18] <pitti> Riddell: I'm happy to postpone that one if you want, just reviewing leftover WIs
[15:19] <Riddell> I have no opinion, you should ask the kubuntu team
[15:19] <pitti> ok
[15:34] <mvo> cjwatson: any luck with the ppa version?
[15:35] <chrisccoulson> doko, hmmm, bug 831256 is a bit weird
[15:35] <chrisccoulson> i don't see how that fails :/
[15:41] <cjwatson> mvo: not yet, I was chasing things down in eglibc: see thread at http://lists.debian.org/debian-glibc/2011/09/msg00036.html
[15:48] <mvo> cjwatson: aha, nice!
[15:52] <cjwatson> but it's true that segfaulting is a bad response to regcomp failing
[15:52] <cjwatson> just a moment, testing
[15:54] <cjwatson> mvo: right.  that does indeed fix the segfault, thanks, and valgrind is now happy.  of course we still need to fix the eglibc bug since now the regexes are incorrectly not recognised, and I suspect this will break other things
[15:54] <cjwatson> hopefully aurel32 will reply quickly
[15:54] <ahasenack> hi, could someone please nominate https://bugs.launchpad.net/landscape-client/+bug/813477 for maverick and natty?
[15:55] <cjwatson> ahasenack: done
[15:55] <Laney> I would if the ... oh, never mind
[15:56] <mvo> cjwatson: yeah, much agreed, thanks a bunch for testing, I will upload the fix next
[15:58] <ahasenack> cjwatson: thanks
[16:08] <tjaalton> barry: ping re libfsobasics, libfsotransport; I believe these could be synced?
[16:14] <tjaalton> seems that libfsobasics is blacklisted currently, is there a way for me to see why?
[16:14] <slangasek> tjaalton: the blacklist is unfortunately not synced to anything public; let me look for ou
[16:14] <slangasek> you
[16:14] <tjaalton> slangasek: thanks
[16:15] <tjaalton> i know it ftbfs
[16:15] <slangasek> tjaalton: in fact, I don't see it in the blacklist - how did you determine that it's blacklisted?
[16:15] <Laney> https://launchpad.net/ubuntu/oneiric/+localpackagediffs?field.name_filter=libfsobasics&field.package_type=all&field.package_type-empty-marker=1
[16:15] <tjaalton> slangasek: I ran syncpackage
[16:15] <tjaalton> Laney: ooh
[16:15] <Laney> Launchpad autoblacklists when the Ubuntu version deviates AFAIK
[16:15] <slangasek> right, so you have to override
[16:15] <doko> chrisccoulson, given it back, and it did build. thanks
[16:16] <cjwatson> slangasek: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt FYI
[16:16] <slangasek> cjwatson: oh, ok
[16:16] <slangasek> cjwatson: where's the cronjob that syncs that?  I have trouble figuring out how things get to that directory
[16:16] <cjwatson> slangasek: cocoplum:~lp_archive/dak/cron.sync
[16:17] <cjwatson> but yeah, in this case it's more confusing UI from syncpackage
[16:17] <slangasek> got it
[16:18] <tjaalton> so, are the ffe-rules relaxed when fixing ftbfs bugs? :)
[16:18] <slangasek> no
[16:18] <tjaalton> damn
[16:18] <slangasek> exceptions may be more likely to be granted, but there's still a need for due diligence
[16:19] <infinity> (Unless you mean you've JUST fixed the FTBFS bug, which isn't a feature, and not subject to FF)
[16:19] <infinity> But yeah, "I've added 7 new features, and accidentally fixed a build failure at the same time" doesn't fly. :P
[16:19] <tjaalton> in these cases the packaging has been fixed too, but all our changes could be dropped as well
[16:19] <tjaalton> i'll file bugs then
[16:20] <bambee> Hi, plymouth is not shown at all on startup, except if I remove "vt.handoff=7" manually (also with CTRL+ALT+F1 during the boot process, it works). it works fine on reboot/shutdown. Any ideas ?
[16:20] <bambee> the system does not switch back to vt 1... it's strange :\
[16:21] <slangasek> how do you mean, "does not switch back to vt1"?
[16:26] <SpamapS> slangasek: so, the "wait for interfaces" change has ruffled some feathers. It seems that d-i always leaves behind a permanent 'auto ethX' after installation.. which means a lot of people are upgrading and then seeing a 2 minute delay
[16:28] <bambee> slangasek: I just wonder why I don't see anything (nouveau and kms work)
[16:29] <bambee> if I type "CTRL+ALT+F1" during the boot process, I see plymouth, otherwise I see nothing
[16:37] <slangasek> SpamapS: wait for interfaces> yep, caught that the other day in the mail trail.  Do you think it's feasible to clean that up on upgrade?  Or maybe we should exclude interfaces that are configured as merely auto/dhcp in favor of checking for NM running?
[16:37] <slangasek> bambee: you see plymouth during the boot process only when typing Ctrl+Alt+F1, *and* vt.handoff=7 is being passed?
[16:38] <cjwatson> I still think NM is a red herring; if NM was installed, then 'auto' lines would've been removed at the end of installation
[16:38] <slangasek> oh?
[16:38] <ScottK> slangasek: If it's relevant, bambee is on Kubuntu and it's not very good about transitions being invisible.
[16:39] <slangasek> ScottK: well, so far we're discussing flavor-neutral bits of the boot
[16:39] <ScottK> OK.
[16:39] <SpamapS> cjwatson: ok so there's already some intelligence there in NM's postinst?
[16:39] <ScottK> Just mentioning it because he may be seeing stuff that's normally not visible in Ubuntu.
[16:39] <cjwatson> SpamapS: I gave specifics in the bug
[16:39] <SpamapS> oh I haven't caught up yet
[16:40]  * SpamapS reads
[16:40] <bambee> slangasek: exactly
[16:40] <slangasek> cjwatson: do you have any suggestions on where to look next with bambee's handoff issue?  Sounds like something falling down in the junction between grub, kernel and plymouth
[16:42] <bambee> an interesting info: it works just fine with {kubuntu,ubuntu}-11.10-desktop-amd64 (the livecd), and it does not work on my system
[16:42] <cjwatson> maybe plymouth:debug=file:/run/plymouth.debug (assuming oneiric)
[16:43] <slangasek> bambee: could you try booting with that option, plus vt.handoff=7?
[16:43] <cjwatson> plymouth is supposed to display on vt7, not vt1
[16:43] <slangasek> indeed
[16:43] <bambee> slangasek: sure
[16:43] <SpamapS> cjwatson: I agree 100% with the position that a change in behavior at this change would be more harmful than good. I wonder if we can notify users in plymouth that the system is waiting for network configuration so, if nothing else, we know how to tell them to fix it when they report a slow boot.
[16:43] <cjwatson> (because otherwise the smooth transition from grub to plymouth wouldn't work)
[16:43] <cjwatson> SpamapS: that sounds straightforward and a good idea, yes
[16:43] <slangasek> bambee: two major differences between the live CD and an installed system are the boot loader used, and the fact that plymouth is always started in the initramfs for a liveCD
[16:44] <SpamapS> that should be easy to do in failsafe.conf
[16:44] <slangasek> bambee: you could eliminate one possible source of this noise by installing the cryptsetup package on your installed system, which will cause plymouth to be started from initramfs on the installed system
[16:46] <bambee> slangasek: trying with both (option+package), bbl
[16:52] <bambee> slangasek: well, nothing is generated in /run   (/run/plymouth.debug does not exist)
[16:52] <bambee> /proc/cmdline: BOOT_IMAGE=/vmlinuz-3.0.0-11-generic root=UUID=5b2e8c3c-eacf-494b-bb21-2363d0d235f2 ro plymouth:debug=file:/run/plymouth.debug quiet splash vt.handoff=7
[16:53] <slangasek> bambee: blast; that's somewhat consistent with my own experiences trying to get output from plymouth in oneiric, but I was hoping cjwatson had the magic recipe (/run vs. /var/log)
[16:54] <slangasek> bambee: so I'll take some time to hack on that today and see if I can figure out what's going on with logging.  In the meantime, can you try installing cryptsetup?
[16:54] <slangasek> (and rebooting, of course)
[16:54] <bambee> slangasek: sure, trying
[16:55] <cjwatson> maybe try /run/initramfs/plymouth.debug instead
[16:55] <cjwatson> historically I used /dev/.initramfs/plymouth.debug, actually, but nowadays somewhere under /run ought to work
[16:55] <cjwatson> I haven't debugged plymouth since the /run transition
[16:55] <slangasek> I thought the log only got written to disk when /etc/init/plymouth-log.conf fired
[16:56] <SpamapS> cjwatson: one last question.. does d-i call ifblacklist_migrate.sh ? I only see it called in n-m's postinst configure if we're coming from before 0.6.5-0ubuntu12 ..
[16:57] <bambee> cjwatson: trying too
[16:57] <bambee> reboot
[16:57]  * SpamapS can probably c/o d-i and confirm that if you don't know off the top of your head ;)
[16:57] <dobey> hrmm, no patch pilot atm?
[16:57] <cjwatson> SpamapS: yes, it does, that was why I mentioned it
[16:57] <cjwatson> SpamapS: netcfg
[16:57] <cjwatson> ./finish-install.d/55netcfg-network-manager:11:         sh /usr/lib/NetworkManager/ifblacklist_migrate.sh
[16:58] <SpamapS> cjwatson: ahh ok, thanks. :)
[16:58] <cjwatson> slangasek: true
[16:59] <cjwatson> slangasek: but that should happen as soon as the rootfs is writable
[16:59] <cjwatson> slangasek: actually, I don't think that applies to the debug log
[16:59] <cjwatson> plymouth-log is about /var/log/boot.log
[16:59] <slangasek> cjwatson: ok - I thought it did, I'll have a look at the code a bit later to confirm.  Anyway, it doesn't seem to work for me at all, possibly because the job races plymouth-stop
[17:00] <cjwatson> which interestingly appears to date from 2011-07-13 on mmy system, hmm
[17:00] <slangasek> maybe we should make 'plymouth quit' do a last-ditch attempt to write the logs
[17:00] <dobey> hrmm
[17:01] <dobey> should maybe ubuntu-sponsors be subscribed to all merge proposals into lp:~ubuntu-branches owned branches?
[17:01] <SpamapS> dobey: effectively sponsors are, because they show up in the sponsorship queue
[17:02] <ahasenack> SpamapS: hi, finally finished the other ubuntu releases for #813477, can you upload the missing Maverick and Natty packages?
[17:02] <dobey> SpamapS: do they get spammed by LP for them though? or do they just show up on the queue page? :)
[17:03] <SpamapS> dobey: the queue. I don't think I'd want to read all of ubuntu-sponsors' bugmail ;)
[17:04] <SpamapS> ahasenack: ACK, will take a look later today, in the middle of a few things.
[17:04] <ahasenack> SpamapS: ok, thanks
[17:04] <bambee> slangasek: even with cryptsetup installed, it does not work
[17:05] <dobey> SpamapS: well this isn't bug mail, it's code review mail. :)
[17:05] <slangasek> bambee: thanks, that eliminates one source of difference.  The remaining major difference is the bootloader itself, which again points to the grub+kernel vt handoff
[17:05] <bambee> cjwatson: plymouth produces no debug outputs here :\ (even with /var/log)
[17:05] <dobey> SpamapS: hopefully it's not as bad as bugs mail
[17:06] <SpamapS> dobey: the queue is, IMO, a much better way to approach it, as things are sorted by their age.. so right away you know which thing has been sitting in the queue the longest
[17:06] <SpamapS> email is an interrupt driven system and favors the squeaky wheels
[17:07] <bambee> slangasek: oh! I still have a 2.6.38 kernel here (just in case)
[17:07] <bambee> I could test with the 2.6.38....
[17:07] <cjwatson> bambee: "even with /var/log"> doesn't make sense
[17:08] <dholbach> can somebody please get the glom packages out of binary new?
[17:09] <slangasek> bambee: sure, that may also be a useful data point - even in the event that it works with the older kernel, this doesn't necessarily point to a kernel bug, but it at least gives us a place to look (i.e., git-bisect)
[17:11] <dobey> SpamapS: i take it you mean https://launchpad.net/ubuntu/oneiric/+queue ?
[17:12] <cjwatson> dobey: http://reports.qa.ubuntu.com/reports/sponsoring/
[17:13] <dobey> cjwatson: ah, ok
[17:17] <bambee> slangasek: it does not work with linux-image-2.6.38
[17:18] <bambee> I don't think it's kernel related... (it worked fine on natty with linux-image-2.6.38)
[17:18] <bambee> cjwatson: http://paste.ubuntu.com/688477/
[17:18] <bambee> (plymouth.debug)
[17:19] <cjwatson> dinner trumps plymouth debugging :-)
[17:41] <bambee> btw, "[ply-utils.c]                               ply_open_module:Could not load module "/lib/plymouth/renderers/x11.so": /lib/plymouth/renderers/x11.so: cannot open shared object file: No such file or directory"
[17:43] <Laney> bts --mbox show
[17:44] <Laney> arg, sorry
[18:13] <cjwatson> bambee: the X11 plugin isn't intended to be used there
[18:14] <cjwatson> bambee: so that part is a red herring
[18:14] <bambee> oh ok
[18:14] <cjwatson> bambee: hmm.  there really isn't anything obvious (to me) there.  it looks as though plymouth's internal logic is doing all the right things, but it's just talking to nouveau wrongly :-(
[18:16] <bambee> so , is it a problem with nouveau ? don't compute it worked just fine on natty with linux-image-2.6.38... and the kernel is still the same...
[18:16] <cjwatson> I wouldn't expect so; presumably it's dealing with X just fine
[18:17] <cjwatson> plymouth has a variety of horrible code to talk to each of the different framebuffer implementations in different ways, since at the time we first put that all together they all had different requirements
[18:17] <cjwatson> it seems quite plausible that nouveau's requirements have changed and our plymouth package hasn't kept up
[18:17] <bambee> mhhh
[18:26] <dobey> can i bug someone to PLEASE sponsor a critical fix asap? https://code.launchpad.net/~dobey/ubuntu/oneiric/couchdb/fix-780972/+merge/75238
[18:31] <cyphermox> dobey: looking at it now
[18:31] <dobey> cyphermox: thanks
[18:39] <slangasek> hallyn: do you know what hvm is?  (Bug #849224)
[18:39] <hallyn> hardware assisted virtualization?
[18:40] <hallyn> as in kvm
[18:40] <Laney> doko: do you want to give back fgarch or are you happy the vr removal will have fixed bug #749138?
[18:40] <hallyn> (or xen)
[18:40] <Laney> (can't reproduce it)
[18:41] <hallyn> slangasek: interesting.  we might need to talk to lool about that.  /usr/share/qemu is usually provided by qemu-common.
[18:41] <hallyn> presumably qemu-linaro shoudl be patched to look under/usr/share/qemu-linaro?
[18:41] <slangasek> hallyn: qemu-linaro *already* looks under qemu-linaro.  I don't know what the bug submitter is talking about, because "hvm domU" doesn't tell me what architecture this is...
[18:42] <hallyn> no, it doesn't :)
[18:45] <hallyn> slangasek: I also have no idea what v0.1.1-2ubuntu2 refers to
[18:46] <doko> Laney, given back
[18:46] <doko> could you close the report?
[18:47] <Laney> yep
[18:47] <slangasek> hallyn: ok, I'll not worry over it any more then, we'll wait for the response from the submitter - thanks :)
[18:47] <Laney> thanks
[18:47] <hallyn> np :)
[18:49] <DktrKranz> Laney: python-httplib2 uploaded in sid
[18:49] <Laney> \o/
[18:49] <Laney> cheers!
[18:50] <DktrKranz> :)
[18:58] <lool> slangasek: hvm: I think this is by opposition with pv; in the latter case, paravirtual, the kernel is aware that it's virtualized, while it's not the case in the hvm case (e.g. to run windows); I think this is xen terminology but might apply to kvm
[19:09] <cyphermox> dobey: done
[19:10] <dobey> cyphermox: thanks much!
[19:12] <slangasek> lool: ok - so in any case we have no idea what the submitter is doing
[19:20] <bdmurray> pitti: is there any chance bugpatterns.xml was out of date on people.canonical.com for a while?
[19:55] <bdrung> the ppa builder seems to have a problem on maverick: https://launchpadlibrarian.net/79806678/buildlog.txt.gz
[20:01] <bdmurray> slangasek: is there a multiarch tag in use?
[20:02] <slangasek> bdmurray: yes
[20:02] <bdmurray> and that tag is multiarch?
[20:03] <bdmurray> slangasek: and that tag is multiarch?
[20:04] <slangasek> bdmurray: yes - sorry, I thought that was the first question :)
[20:04]  * micahg added the multiarch tag to the wiki tags page
[20:05] <bdmurray> micahg: maybe it should be official
[20:06] <micahg> bdmurray: I thought I made it official already
[20:06] <micahg> indeed, it autocompletes
[20:06] <bdmurray> well neat
[20:11] <lool> slangasek: Sorry hadn't looked at the actual bug; seems like someone trying to run a piece of xen by hand which expects the keymaps in usr/share/qemu; let's wait for his reply indeed!
[21:14] <SpamapS> hmm, how does one make strings in upstart jobs translatable?
[21:40] <JanC> SpamapS: what do you mean by "strings in upstart jobs"?
[21:53] <SpamapS> JanC: I want to display a message to users when the system is waiting on something for a long time.
[21:55] <JanC> that doesn't sound like an upstart issue, but something service-specific?
[21:55] <SpamapS> JanC: no, its one of upstart's jobs
[21:56] <SpamapS> but even if it were, say, apache's.. how would one make it translatable?
[21:58] <SpamapS> the gettext cli program seems a likely candidate
[22:00] <JanC> in general, daemon/service-specific messages can only be translated "inside" the daemon, but for anything outside that gettext is an obvious tool of course
[22:11] <broder> SpamapS: wouldn't that be more plymouth's job?
[22:13] <SpamapS> $PLYMOUTH message --text="Waiting for network configuration..."
[22:13] <SpamapS> broder: not that I can see
[22:14] <broder> SpamapS: how does, uh, mountall handle this?
[22:14] <SpamapS> the burden lies on the origin of the literal string
[22:14] <SpamapS> broder: _()
[22:14]  * SpamapS assumes
[22:14] <broder> i feel like i've seen a way to access gettext from sh...
[22:15] <slangasek> SpamapS: by "make them translatable", do you mean "get them somewhere that they will be translated", or "get the right translated string into the upstart job"?
[22:16] <SpamapS> slangasek: both. :)
[22:16] <slangasek> the gettext commandline program should do for the latter
[22:17] <slangasek> plymouth message --text=$(gettext -d upstart-jobs "Waiting for network configuration...")
[22:17] <slangasek> or gettext -d upstart, if you can work out how to get it into upstart/po/upstart.pot in a semi-automatic fashion
[22:18] <SpamapS> There's a lot of pieces of the boot that are english only.. so I'll leave it in the "lets solve this soon" bin, and not do it now..
[22:19] <SpamapS> slangasek: the descriptions of all the upstart jobs would also be good to translate.. since they're used by the plymouth bridge
[22:20] <slangasek> SpamapS: hmm, ick :)
[22:20] <SpamapS> slangasek: seems like that would be much easier to do in a "semi automatic fashion" with dh_installinit
[22:20] <slangasek> not particularly
[22:21] <slangasek> dh_installinit runs when building binary packages
[22:21] <SpamapS> slangasek: but then we have to have upstart know to feed it through gettext at the right moment. :-P
[22:21] <SpamapS> slangasek: it could scan the init script it is installing, and produce the .pot, no?
[22:21] <slangasek> the problem you need to solve is extracting the strings so that they can be fed to something that interfaces with launchpad translations, which looks at *source* packages
[22:22] <slangasek> if LP Translations pulls .pot from binary packages at build time, I'm not aware of it
[22:22] <SpamapS> slangasek: err, not installing, but rather, the init script it is setting up to install
[22:22] <SpamapS> I see your point..
[22:22] <SpamapS> wrong stage of package building
[22:25] <slangasek> ScottK: the honeyd configure.in is making me angry
[22:25] <ScottK> ;-)
[22:25] <SpamapS> seriously, I think ESR may be right.. autoconf/automake need replacing. :-P
[22:25] <SpamapS> If for no other reason than to knock all the bad habits out of peoples heads
[22:26] <slangasek> I challenge you to show me a build system that doesn't encourage *worse* habits :)
[22:31] <slangasek> anyway, honeyd fix in hand now
[22:31] <ScottK> Cool.
[22:31] <slangasek> well, except for the subsequent unrelated build failure
[22:31] <TheMuso> /c/c
[22:38] <charlie-tca> TheMuso: bug 836798 seems to be still happening
[22:39] <TheMuso> charlie-tca: Yes I know, I am subscribed to it, I will get to it today.
[22:39] <charlie-tca> Okay
[22:39] <charlie-tca> Just want to make sure I didn't mess you up with it
[22:49] <slangasek> ScottK: hah; the other build failures are caused by API changes in libevent, which I see is precisely what puts honeyd on the NBS list
[22:49] <ScottK> Excellent.
[22:50] <ScottK> slangasek: If you want a break for something fun, have a glance at Debian 637509 and then remove it from Ubuntu.
[22:50] <slangasek> the latter is Debian bug #632765
[22:51] <slangasek> heh, dtc
[22:51] <slangasek> yeah, we can do that
[22:53] <slangasek> oh good, honeyd is by the same upstream author as libevent
[22:54] <slangasek> and is not ported to the new API
[22:54] <ScottK> Lovely.
[22:54] <ScottK> Only 13 RC bugs against dtc in Debian.
[22:56] <SpamapS> slangasek: /win 21
[22:56] <SpamapS> doh
[22:56]  * slangasek runs to the window to look!
[22:56] <SpamapS> shh don't tell anybody
[22:57] <SpamapS> everyone will want one
[23:04] <ScottK> Was it http://www.backcountry.com/sog-knives-double-headed-axe-w-nylon-sheath ?
[23:11] <slangasek> ScottK: bug #845481 is a treat
[23:12] <ScottK> slangasek: I think you'll like https://bugs.launchpad.net/ubuntu/+source/dtc/+bug/845481/comments/1
[23:12] <slangasek> heh
[23:15] <Seq> Hello. My boot times in oneiric have skyrocketed to about 2.5 minutes. Can anybody help me see why? Here is the bootchart: http://i.imgur.com/XS36E.png
[23:16] <SpamapS> Seq: bug 847782
[23:17] <SpamapS> Seq: I am about to propose a fix, that hopefully slangasek will take a look at for me. ;)
[23:18] <SpamapS> Seq: the short description is .. if you have interfaces in /etc/network/interfaces that aren't actually able to be configured, you should likely remove the line 'auto ethX' from that file so that the system won't wait for them or try to bring them up at boot.
[23:20] <SpamapS> slangasek: https://code.launchpad.net/~clint-fewbar/ubuntu/oneiric/upstart/add-plymouth-messages/+merge/75278 .. would you mind taking a peek?
[23:21] <Seq> Thanks. I've removed the 'auto eth0' line, although there was no actual configuration indicating it was dhcp.
[23:21] <SpamapS> Seq: so it had no configuration at all?
[23:22] <Seq> only an 'auto eth0' line, it did not have anything such as 'iface eth0 inet dhcp'
[23:22] <SpamapS> Seq: do you know why it might have been there?
[23:22] <SpamapS> Seq: do you have a physical eth0 ?
[23:23] <Seq> did the timeout value in /etc/failsafe.conf change recently? I mostly reboot when on wifi only, and I've been running oneiric for a few weeks now, rebooting every few days (mostly for kernel updates)
[23:23] <Seq> SpamapS: yes.
[23:23] <SpamapS> Seq: the timeout did raise from 30 -> 120 seconds about a week ago
[23:24] <Seq> That could be it. I probably haven't rebooted in a week
[23:24] <SpamapS> Seq: the proposed fix is just to display to the user that its waiting for network configuration..
[23:24] <ScottK> That's not much of a fix.
[23:24] <ScottK> (sorry)
[23:24] <SpamapS> Seq: but I suppose we should also make sure that the interfaces we're waiting for actually have configurations!
[23:25] <SpamapS> ScottK: your snark cuts me deep. ;)
[23:25] <Seq> That would be a good start. I ditched the 'auto' line so hopefully it gets skipped over. But when I disabled 'quiet' and 'splash', I didn't get any indication either, just that cupsd had started.
[23:26] <SpamapS> Seq: right, the MP I just linked to for slangasek has the messages bits added
[23:26] <SpamapS> its not in oneiric yet
[23:26] <ScottK> It's not really snark.  I've got a system that boots wicked fast and explaining to me why it's no longer fast once I upgrade it isn't going to make me into a happy user.
[23:27] <SpamapS> ScottK: can't make everybody happy. :)
[23:27] <SpamapS> Most users should *not* have these lines
[23:27] <SpamapS> But I think its worthwhile to also make it not wait on any interfaces that will clearly *never* come up.
[23:27] <ScottK> OTOH, compared to a UEC user upgrading to oneiric, only booting a bit slow is a detail.
[23:28] <ScottK> SpamapS: Agreed.
[23:28] <Seq> I've actually got an issue I'm planning on narrowing down tonight that causes my network to not work. Maybe it is related to bringing up an unconfigured interface..
[23:28] <SpamapS> Seq: I would expect that ifup would still bring it "up", just not give it an IP
[23:29] <SpamapS> Seq: which is actually what I'm testing right now
[23:29] <Seq> If I'm on wifi and connect my dock (which has ethernet plugged in), each device is configured and working, but my routes get a little messed up. I need to disable both in NM, then pick either one to start again
[23:29] <SpamapS> Seq: yeah maybe the auto line was borking your configs
[23:29] <slangasek> ScottK: bug #849544
[23:30] <ScottK> slangasek: Thanks.
[23:30] <Seq> SpamapS: Unfortunately I'm on that machine right now. I'm about to dock, so I may disappear for a second
[23:34] <SpamapS> so, as I suspected, if you have an 'auto ethX' line with no config, it comes up instantly
[23:34] <SpamapS> if the interface *exists*
[23:35] <SpamapS> one of the whole points of this is we're waiting for interfaces that may take 2 minutes to be detected..
[23:39] <SpamapS> Seq__: wb ;) so I tested auto eth1 with and without an eth1 attached to the system.. and without it.. you get the delay, but with it, you don't. This is desired behavior, as one thing we're waitign for is hardware detection that takes a long time.
[23:41] <seq> So you said I shouldn't get the delay if it has 'auth eth0' while disconnected?
[23:42] <seq> btw, I just tested again. If I have both network interfaces active, I lose speedy connectivity. Bringing up a web page takes minutes. If I have just one interface connected (either one) web pages load instantly
[23:43] <seq> this is not necessarily related to the boot issue
[23:47] <SpamapS> seq: are they both on the same network?
[23:47] <seq> Yes
[23:48] <seq> SpamapS: `route -n` > http://pastebin.com/3J11yM9u
[23:49] <SpamapS> seq: that is a little weird.. not sure why you'd see the slowdown.. but can't you just turn wlan off when you plugin to ethernet?
[23:49] <seq> If I recall, on previous releases the wifi route had a metric of 1, whereas the wired one was 0. They are both 0 here
[23:49] <SpamapS> seq: interesting indeed
[23:49] <seq> SpamapS: I could, but I'd prefer it just work magically like it used to.
[23:50] <SpamapS> seq: yeah it should be magical like that if they're essentially on the same network
[23:50] <seq> I'll try manually removing that route over wifi and adding it back with a metric of 1
[23:51] <seq> SpamapS: Also, disconnecting wifi would sever existing connections, which I don't necessarily want to happen
[23:51] <SpamapS> seq: as for your boot slowdown .. the issue isn't if its "connected" or "disconnected" .. but whether the hardware is present at all... if its not present, we wait.. in case it shows up (not entirely unlikely w/ servers ;)
[23:51] <seq> SpamapS: eth0 is always present, it just usually isn't connected
[23:51] <seq> I still had to wait 120 seconds
[23:52] <SpamapS> seq: if it was present, with no configuration, the system should have booted. I just tested that and we don't wait, because ifupdown brings it "up"
[23:52] <SpamapS> I wonder if there are situations where it doesn't show up until later. Hm.
[23:53] <seq> It didn't do that here. Is there something I can poke to get additional output?
[23:53] <seq> SpamapS: Never been a problem with it showing up before. It's just a standard e1000 on a standard intel chipset in a thinkpad
[23:53] <SpamapS> seq: if you want to pull the failsafe.conf from that branch and put it in /etc/init/failsafe.conf, that would at least tell you its waiting on network configuration..
[23:54] <seq> According to dmesg, it gets detected pretty quickly: [    2.213280] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 5c:ff:35:00:6b:05
[23:54] <SpamapS> http://bazaar.launchpad.net/~clint-fewbar/ubuntu/oneiric/upstart/add-plymouth-messages/view/head:/debian/conf/failsafe.conf
[23:55] <SpamapS> seq: it would actually be really interesting to see ls -l /run/network
[23:56] <cjwatson> why is there an auto line with no iface line anyway?  d-i won't do that
[23:56] <seq> Is there something better than pastebin to post this to?
[23:56] <SpamapS> cjwatson: I'm pretty sure we're going to dig up all the hacks and voodoo people have applied to their interfaces file with this change. ;)
[23:57] <cjwatson> the only places it writes auto, it writes iface straight afterward
[23:57] <SpamapS> seq: I like paste.ubuntu.com (easily accessed from cli with pastebinit)
[23:57] <seq> This is a fresh install on oneiric, and I do not touched the interfaces file on machines that I use NM on
[23:57] <cjwatson> seq: which installer?
[23:57] <seq> alternate, I use dmcrypt+lvm
[23:57] <cjwatson> I've audited the code and it never writes auto without writesing iface next
[23:57] <cjwatson> *writing
[23:58] <seq> Is there a log file I can check to see the install date?
[23:58] <cjwatson> so I'd like to see the exact original contents of /etc/network/interfaces plus /var/log/installer/syslog
[23:58] <SpamapS> cjwatson: perhaps more importantly, if there's only an 'auto ethX' line and it is detected, /etc/network/network-interface.conf brings it up.. so the system won't wait for that.
[23:58] <cjwatson> give me the latter and it has the install date in it plus lots more
[23:58] <slangasek> SpamapS: sent some comments on the merge request