=== allquixotic_ is now known as allquixotic
=== vibhav is now known as Guest25507
=== cpg is now known as cpg|away
=== cpg|away is now known as cpg
=== cpg is now known as cpg|away
=== amitk is now known as amitk-afk
[05:51] <sgnb> is there an equivalent of snapshot.debian.org for Ubuntu?
[05:54] <infinity> Nope.
[05:54] <micahg> sgnb: no, but almost all binaries should be available on launchpad on the source package's page
[05:55] <infinity> micahg: Well, to a point.  We reserve the right to reap old cruft that no longer has ties to any active publishing record.
[05:55] <infinity> (But yes, most of it's still available)
[05:55] <micahg> right, hence, almost :)
[05:55] <infinity> One could probably do nasty DB/API walks to construct snapshots.
[05:55] <infinity> I wouldn't recommend it.
[05:56] <sgnb> ok
[05:57] <infinity> sgnb: If you're looking for old versions of a package, micahg's pointing you in the right direction.  lp.net/ubuntu/+source/<package> will link to all the previous versions, which in turn link to all the binary builds, etc.
[05:58] <infinity> sgnb: But snapshots of the archive, date-based (which is snapshot.debian.net's way cooler feature that no one uses) aren't something we provide.
[05:58] <micahg> well, add a /+changelog on the end of that
[05:58] <infinity> Actually, +publishinghistory
[05:59] <micahg> well, either would work
[05:59] <micahg> the later is probably less likely to time out
[05:59] <infinity> Sure, but one of them's readable. ;)
[06:00] <sgnb> infinity: well, I do use it (date-based snapshots), when I don't know in which package is the bug I'm investigating... fortunately, it's not the case this time
[06:04] <infinity> sgnb: Yeah.  Like I said, it would be conceivably possible to do date-based reconstruction from LP, but not trivial.  Would be neat if someone with stupid amounts of disk space decided to do it as a third-party service.
[06:06] <infinity> Actually, if they were happy with only ever providing the things we didn't purge from the librarian, they wouldn't need disk space at all, just to write an intelligent proxy/redirect shim that reconstructed history and aimed people at the right librarian entries.
[06:06] <infinity> But if they want to keep history that we might/will purge, yeah, disk space.
=== cpg|away is now known as cpg
[08:07] <hrw> hello
[08:13] <pitti> Good morning
=== amitk-afk is now known as amitk
[09:08] <tumbleweed> infinity: I seem to remember broder doing some date-based snapshots (backed on LP)
[09:13] <xclaesse> is there known Quantal bug that prevent laptop from going back from sleep?
[09:14] <seb128> xclaesse, what kernel version do you use?
[09:15] <xclaesse> 3.5.0-5-generic
[09:15] <seb128> xclaesse, yes, it's fixed in -6
[09:16] <xclaesse> seb128, awesome, thx :)
[09:16] <seb128> yw!
[09:17] <xclaesse> The following packages have been kept back:
[09:17] <xclaesse>   cups-filters gedit gedit-common libimobiledevice-dev libnet-dns-perl
[09:17] <xclaesse>   libsignon-glib-dev libsignon-glib1 linux-headers-generic linux-image-generic
[09:17] <xclaesse>   signond signond-dev
[09:17] <xclaesse> so it doesn't wan't to upgrade to -6 yet
[09:19] <seb128> xclaesse, yeah, not sure why, you can apt-get install it manually, lot of people did it, seems to work fine
[09:21] <xclaesse> k, thx
[09:21] <xclaesse> seb128, btw I think gedit-plugins needs an update as well
[09:22] <xclaesse> otherwise upgrading gedit will remove the plugins
[09:22] <seb128> xclaesse, it does, in fact the packaging forces both to me in the same serie and there is no gedit-plugins 3.5 tarball yet, I need to check if 3.4 works with gedit 3.5 and relax the depends if it does
[09:24] <xclaesse> ok
=== cking_ is now known as cking
=== Guest25507 is now known as vobhav
=== vobhav is now known as vibhav
=== vibhav is now known as Guest54522
=== mcclurmc is now known as mcclurmc_away
=== Guest54522 is now known as vibhav
[10:06] <tjaalton> did chkconfig get removed from quantal?
[10:07] <tjaalton> ..without checking reverse deps
=== zyga is now known as zyga-afk
[10:10] <tjaalton> ScottK: ^
=== cpg is now known as cpg|away
=== mcclurmc_away is now known as mcclurmc
=== zyga-afk is now known as zyga
=== _salem is now known as salem_
[13:01] <ScottK> tjaalton: It's possible I screwed up.  Suggestion on how to proceed?
[13:01] <tjaalton> ScottK: i fix freeipa-client to not need chkconfig ;)
[13:01] <ScottK> tjaalton: Thanks.
[13:01] <tjaalton> guess that's the way to go anyway
[13:02] <tjaalton> doesn't matter if it's broken on quantal for now
[13:02] <ScottK> tjaalton: Any chance you could look at system-config-audit as well?
[13:02] <ScottK> That seems to be the other one.
[13:02] <brendand> does anyone know if there is a way with Qt to find out about the palette used by the current theme?
[13:02] <tjaalton> ScottK: I might
[13:03] <ScottK> tjaalton: If it turns out you can't, please let me know.
[13:03] <brendand> i notice that gnome-control-center changes the color of the top button area when the theme changes. i want to do something similar
[13:03] <tjaalton> ScottK: sure thing, I'll take a look at it later
[13:03] <ScottK> Thanks.
[13:06] <pitti> apw: hey Andy, how are you?
[13:06] <pitti> apw: I noticed your kmod PPA, nice! how is that working?
[13:07] <pitti> seb128: ^ FYI
[13:08] <seb128> pitti, danke (talking to didrocks so I didn't get to ask on IRC)
[13:11] <apw> pitti, it was working pretty well for me, i am intending on revisiting it this afternoon, as we should switch sooner rather than later.  the only thing we really holding us back was the lack of map suppoer which i have found nothing using
[13:11] <pitti> apw: yeah, the text based maps are fairly obsolete
[13:11] <ev> mpt: out of a small sample of 50 reports (it takes 20 minutes to run this code for that size), only 3 had the most recent version of the package and its dependencies installed at the time of the report
[13:11] <apw> pitti, the other wrinkle is that if we switch versioning for module-init-tools makes backing out hard
[13:11] <pitti> apw: that'd be great, then we can update udev as well
[13:12] <pitti> apw: at worst we can epoch it?
[13:12] <mpt> ev, wow
[13:12] <apw> pitti, so its my priority to sort out the testing and recommendation today i hope
[13:12] <ev> mpt: I'll do a bigger sample later, when the launchpad team isn't looking. But yeah, we have work to do :)
[13:12] <pitti> apw: at some point we'll need to switch anyway, and there won't be many new versions for this any more, so an epoch shouldn't hurt too much
[13:12] <pitti> apw: splendid
[13:13] <apw> pitti, that takes the pressure off.  my testing so far is all positive, i'll get some more done and check its up to date with debian again
[13:13] <pitti> apw: many thanks
[13:13] <seb128> pitti, apw: great, thanks!
[13:42] <brendand> seb128 - is the fixed accountservice package for this bug in -proposed yet? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1021293
[13:42] <ubottu> Launchpad bug 1021293 in ubiquity (Ubuntu Precise) "Ubuntu 12.04 install stalls when doing apt-get upgrade" [High,In progress]
[13:46] <seb128> brendand, yes, https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=account
[13:46] <infinity> brendand: It's in the queue, I'll be reviewing it today.
[13:47] <infinity> Although...
[13:47] <infinity> seb128: Can you reupload it with -v0.6.15-2ubuntu9.1  ?
[13:48] <infinity> seb128: So we get reference to the bug from the previous proposed upload too?
[13:48] <infinity> Or...
[13:48] <infinity> seb128: Or, I guess I can just promote 9.2 before I accept 9.3
[13:48] <seb128> infinity, sure, I was thinking the new one would go in when the old one moves over to updates
[13:49] <infinity> seb128: Yeah, I hadn't realised it was close to being "of age" and all properly verified and stuff.
[13:49] <infinity> seb128: Since it is, I can just promote it today.
[13:49] <seb128> infinity, it's not "of age", it's 4 days old
[13:50] <infinity> seb128: Yes, I said close.
[13:50] <seb128> ok your call
[13:50] <seb128> I can reupload if you prefer
[13:51] <infinity> seb128: The 9.2 upload is tiny, easily-audited, "obviously sane", and has been verified.
[13:51] <infinity> seb128: Making it wait 3 more days would be pointless beaurocracy with no value.
[13:52] <jamespage> mterry, do you have a moment to discuss bug 1017972 and what I'm proposing with the libunwind test suite?
[13:52] <ubottu> Launchpad bug 1017972 in libunwind (Ubuntu) "[MIR] google-perftools, libunwind" [Medium,Incomplete] https://launchpad.net/bugs/1017972
[13:53] <mterry> jamespage, hello sure
[13:53] <jamespage> mterry, great!
[13:53] <infinity> mterry: Oh hey, you're around.  I had a minor nit to pick with you. ;)
[13:53] <mterry> infinity, :)  /me hides
[13:54] <jamespage> mterry, OK; so I've been digging around upstream with regards to the libunwind test suite
[13:54] <infinity> mterry: I don't even remember what package it was now, but if you fix an RC bug in Ubuntu and the Debian maintainer is "QA", please find a DD to just do a QA upload of the thing instead.
[13:54] <mterry> jamespage, so libunwind's upstream seems silly, to have known test failures, but not skip those tests on those arches...  ;-/
[13:54] <jamespage> mterry, yes - I agree - it does seem a little insane
[13:54] <infinity> mterry: (Which I did for some FTBFS fix you did last week, and then synced over your fix)
[13:55] <mterry> infinity, you mean rather than going the normal route of filing a bug?  you're saying just to save paperwork?
[13:56] <infinity> mterry: No point filing an RC bug if anyone is allowed to upload the package (which is the definition of "maintained by QA"), so just upload.
[13:56] <mterry> jamespage, so google-perftools is all sorted right?
[13:56] <infinity> mterry: Or, in your case, since you're not a DD, ask someone else to. :)
[13:56] <mterry> jamespage, and the plan for libunwind is to enable just amd64?
[13:56] <infinity> mterry: But, sure, if you can't find someone to upload, file a bug.
[13:56] <infinity> mterry: Just that "upload to Debian, sync, and never worry about the delta" is much nicer from your POV.
[13:56] <mterry> infinity, filing a bug is my way of finding a DD.  :)
[13:57] <jamespage> mterry - google-perftools is pending a fix of bug 1028038; at which point I can enable the test suite and its all good...
[13:57] <ubottu> Launchpad bug 1028038 in eglibc (Ubuntu Precise) "sscanf always calls realloc/causes deadlock in google-perftools" [High,Triaged] https://launchpad.net/bugs/1028038
[13:57] <mterry> (and, I thought, the normal way)
[13:57] <jamespage> mterry, for libunwind; enabling the amd64 test suite only - with one fix, two workarounds and 2 test disabled...
[13:57] <infinity> mterry: You work with a ton of DDs.  Just sayin'. ;)
[13:58] <infinity> jamespage: That fix should be happening RSN.
[13:59] <mterry> jamespage, well, given the craziness of upstream tests, one arch is better than none.  hopefully it can act as a sometimes-canary-in-the-coalmine
[13:59] <jamespage> infinity, thats great - thanks
[13:59] <mterry> jamespage, is upstream amenable to making it so that the suite skips known-failures?
[13:59] <mterry> that way we could just enable the whole thing and not worry
[13:59] <mterry> jamespage, (for the future, not as a blocker here)
=== Guest52991 is now known as mfisch
[14:00] <jamespage> mterry, I think they would be - developers appear to be a bit arch-centric upstream
[14:00] <jamespage> the x86_64 guy has been pretty responsive; I note that alot of the ARM work has been done by folk at linaro
=== mfisch is now known as Guest54314
[14:01] <jamespage> so I think having something in the Makefile structure that allows know issues to be ignored would probably be well received
[14:01] <jamespage> mterry, I'll come up with something and proposed upstream...
[14:03] <mterry> jamespage, ok cool.  But regardless, plan seems fine for MIR
[14:03] <jamespage> mterry, great - thx for the feedback
[14:03] <mterry> jamespage, thanks for your awesome work on this!
[14:04] <jamespage> mterry, its been fun - I've not done much low level c/c++ for at least a decade
[14:04] <jamespage> (had to dredge up some really old knowledge that I had forgotten)
=== Guest54314 is now known as mfisch
=== Quintasan_ is now known as Quintasan
[16:03] <janimo> slangasek, thanks for the cdv reviews, I'll shortly upload a new version
[16:21] <jderose> mhall119: who did you think i should pester about this? https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1022515
[16:21] <ubottu> Launchpad bug 1022515 in couchdb (Ubuntu) "Please sync (sort of) couchdb 1.2.0-1 from Debian unstable" [Undecided,Confirmed]
[16:22] <mhall119> seb128: ^^ can you look at jderose's couchdb sync request?
[16:24] <jderose> mhall119: thanks :)
[16:24] <seb128> mhall119, sorry, out of day, I'm at GUADEC, I will have a look tomorrow
=== Zdra is now known as xclaesse
=== deryck is now known as deryck[lunch]
=== mcclurmc is now known as mcclurmc_away
[16:54] <smoser> jodh, around?
[16:58] <slangasek> janimo: sounds good :)
=== dendro-afk is now known as dendrobates
[17:23] <janimo> slangasek, what do you think of starting with a clean changelog - a single entry - since it will be the first publically available release? I am not sure what the best practices are when moving a package from PPA or NEW to Ubuntu and when the history is not really important
[17:24] <slangasek> janimo: I think condensing to a single changelog entry is generally preferred
[17:24] <janimo> slangasek, great, will do that then. We'll also probably go with uploading the latest minor code drop from Intel that occured while these were in NEW
[17:28] <janimo> slangasek, also -0ubuntu1 feels odd given it is unlikely these will go to debian in this form but I hear it is recommended to use ubuntu versions nonetheless
[17:28] <slangasek> that would be my recommendation still, yes
[17:40] <jbicha> any core dev want to sponsor ubuntu-docs upload for Precise & Quantal? bug 1019441
[17:41] <ubottu> Launchpad bug 1019441 in Ubuntu Translations "Please update the ubuntu-docs Precise package with translations for 12.04.1" [High,Triaged] https://launchpad.net/bugs/1019441
=== shadeslayer is now known as shadeslayer_
=== shadeslayer_ is now known as shadeslayer
[17:50] <bdmurray> mterry: would you mind looking at bug 1029764?
[17:50] <ubottu> Launchpad bug 1029764 in update-manager (Ubuntu) "update-manager seems to have an unnecessary recommends on gir1.2-unity-5.0" [Low,Triaged] https://launchpad.net/bugs/1029764
[17:51] <mterry> bdmurray, sure
=== deryck[lunch] is now known as deryck
[18:07] <highvoltage> tumbleweed: congratulations!
[18:09] <jodh> smoser: howdi
[18:09] <smoser> jodh, thanks for responding, but i've figured out the problem wasn't what i was going to bother you with
[18:09] <smoser> :)
[18:09] <micahg> hrm, sponsorship queue isn't refreshing
[18:10] <micahg> bdmurray: ^^ do you still have access to fix this?
[18:10] <bdmurray> micahg: I don't know actually
[18:12] <bdmurray> micahg: it doesn't look like it
=== cpg|away is now known as cpg
[19:11] <tumbleweed> highvoltage: thanks
[20:03] <jderose> for an SRU, do i propose for merging into precise or precise-updates (in my case, libav have a new package in precise-updates already)?
[20:03] <slangasek> jderose: precise-updates; but because of this ambiguity, I consider best practice to skip UDD for SRUs and just send debdiffs to bug reports
[20:04] <jderose> slangasek: okay, thanks. and in the changelog entry, should the distro be precise or precise-updates?
[20:04] <slangasek> precise-proposed
[20:04] <slangasek> :)
[20:05] <jderose> ah, okay :)
[20:05] <jderose> slangasek: much thanks! I'm still pretty green when it comes to this workflow, so I appreciate the help :)
[20:05] <slangasek> no problem
[20:06] <slangasek> jderose: btw, were you following any documentation about this?  I have an action item to clean up the recommendations around SRU workflow
[20:07] <jderose> well, the thing i really needed the most help with is quilt, so i was reading this - https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[20:07] <jderose> i was trying to do things UDD just because i like the idea of it :P
=== cpg is now known as cpg|away
=== cpg|away is now known as cpg
[20:18] <cnd> I'm trying to compile a program that links against libxml and it fails to link with the error: /usr/lib/x86_64-linux-gnu/libxml2.so: undefined reference to `gzopen64@ZLIB_1.2.3.3'
[20:19] <cnd> I think the issue is that the gzopen64 symbol doesn't actually have the ZLIB_1.2.3.3 version on it
[20:19] <cnd> I don't see a version when I use readelf -a
[20:20] <cnd> I can't imagine I'm the first or only person to have seen this, so I'm not sure what I'm doing wrong
=== cpg is now known as cpg|away
[20:21] <jderose> slangasek: would you mind glancing at this debdiff, see if i did things correctly? https://bugs.launchpad.net/ubuntu/+source/libav/+bug/937561
[20:21] <ubottu> Launchpad bug 937561 in libav (Ubuntu) "H264 MOV files from Canon DSLR resolution reported as 1920x1088" [Medium,In progress]
[20:21] <jderose> debdiff - https://launchpadlibrarian.net/111492829/libav_0.8.3-0ubuntu0.12.04.1_to_libav_0.8.3-0ubuntu0.12.04.2.debdiff
[20:21] <slangasek> sure
[20:21] <cnd> nm
[20:22] <cnd> I didn't actually have zlib1g-dev install
[20:22] <slangasek> cnd: you shouldn't need it
[20:22] <cnd> slangasek: then I'm not sure why it was failing
[20:23] <slangasek> I'm not either :)
[20:23] <slangasek> but libxml2.so.2 is linked against libz.so.1, which gives ld all the information it should need to traverse the lib deps and find the symbol
[20:23] <Laney> IIRC some versions of zlib were busted
[20:23] <Laney> did installing the -dev upgrade the shared lib too?
[20:24] <cnd> Laney: oh right
[20:24] <cnd> yes, it was upgraded
[20:24] <slangasek> cnd: hmm, what was the previous version?
[20:24] <cnd> Preparing to replace zlib1g:amd64 1:1.2.3.4.dfsg-3ubuntu4 (using .../zlib1g_1%3a1.2.7.dfsg-13_amd64.deb)
[20:24] <slangasek> that implies that the shlibs / symbols for zlib1g are wrong
[20:25] <slangasek> the symbols file has:
[20:25] <slangasek>  gzopen64@ZLIB_1.2.3.3 1:1.2.3.3
[20:25] <slangasek> (on amd64)
[20:25] <slangasek> so if that's incorrect, it should really get fixed
[20:26] <cnd> that's not what the lib had before I upgraded
[20:26] <cnd> let me check again
[20:26] <cnd> slangasek: yeah, it now has the symver on it
[20:26] <cnd> so the old package I had was borked
[20:27] <slangasek> well, and the old package is the one from precise
[20:27] <slangasek> so it's fairly important that we get the versioned dependencies right here :)
[20:27] <cnd> heh
[20:27] <slangasek> though in point of fact I think the missing symbol *version* is non-fatal at runtime
[20:28] <cnd> slangasek: I'm not *too* familiar
[20:28] <cnd> but I would guess that if it looks for a symbol with a specific version at compile time
[20:28] <cnd> then it is probably hard coded to look for that symbol
[20:28] <cnd> right?
[20:28] <cnd> otherwise it would only have a dependency on the symbol without the version
[20:29] <slangasek> not sure I understand your question
[20:30] <slangasek> note that in this case, your application is *NOT* using gzopen64; the linker is merely doing sanity-checking on the recursive dependencies of the libraries
[20:30] <slangasek> and it seems to be doing it differently than ld.so itself would
[20:30] <cnd> yeah, that may be
[20:31] <cnd> I was thinking that: why would libxml2 depend specifically on symbol@version rather than just symbol unless it really was hard coded to use that specific symbol?
[20:31] <slangasek> because that's how versioned symbols work
[20:32] <cnd> ok
[20:32] <slangasek> when libxml2 was built, the version of the gzopen64 symbol it linked against was ZLIB_1.2.3.3
[20:32] <slangasek> so the linker encoded that information
[20:32] <lifeless> memoisation FTW.
[20:32] <cnd> that's not how I expected it to work, I guess
[20:32] <slangasek> however, at *runtime*, ld.so will fall back on an unversioned symbol if it can't find one with version ZLIB_1.2.3.3
[20:32] <slangasek> no, that's exactly how it's supposed to work
[20:33] <slangasek> there appear to be two bugs
[20:33] <slangasek> one is ld not knowing to fall back to the unversioned symbol
[20:33] <slangasek> the other is zlib1g having the wrong versioned dependency for its versioned symbol
[20:34] <slangasek> jderose: it looks like this bug is not yet fixed in quantal, which is a prerequisite for an SRU.  Could you please prepare a debdiff for that as well and I'll sponsor it in?  (The actual debdiff looks spot-on)
[20:35] <jderose> slangasek: yeah, i was just working on it for quantal also... so should i attach the quantal debdiff to the same bug?
[20:35] <slangasek> jderose: yes; or you can use UDD for quantal if you prefer, that's much more straightforward
[20:36] <jderose> okay, i'll try that then... thanks! :)
[20:36] <slangasek> i.e., UDD for quantal is more straightforward than UDD for SRU - but it's entirely your call if you prefer to use UDD or a debdiff
[20:36] <jderose> gotcha
[20:37] <stgraber> slangasek: we were discussing bug 1031065 with smoser over in #ubuntu-server. You might be interested by that one as it seems to be a race hitting the new overlay cloud instances pretty much systematically (haven't managed to get one booting without the bug yet...)
[20:37] <ubottu> Launchpad bug 1031065 in resolvconf (Ubuntu) "/sbin/resolvconf -a depends on /run/resolvconf/interface but it may not exist" [Undecided,New] https://launchpad.net/bugs/1031065
[20:37] <soren> mdz: Sorry about not replying to your e-mail. Yes, I'd be happy to chair the next meeting. I wonder, though, why it's scheduled for today? The meetings are usually fortnightly. Is there anything out of the ordinary about today?
[20:40] <slangasek> stgraber, smoser: hrmm.  backing up a bit, what is causing resolvconf to be called for interfaces before udev is started?
[20:40] <slangasek> stgraber, smoser: because /etc/init/resolvconf.conf is 'start on mounted MOUNTPOINT=/run', which is strictly earlier than 'start on virtual-filesystems' (udev)
[20:41] <smoser> slangasek, we believe it is being run by network-interface
[20:42] <stgraber> though network-interface depends on an event from upstart-udev-bridge and so depends on "starting udev"
[20:43] <slangasek> smoser: yeah, that can't happen
[20:43] <slangasek> smoser: not unless something else is playing silly buggers with udev
[20:44] <smoser> slangasek, no silly burgers in that regarund that i'm aware of.
[20:45] <smoser> here is mountall --debug output from overlay: http://paste.ubuntu.com/1120170/ , normal: /tmp/mountall-debug-normal.txt
[20:46] <slangasek> smoser: I see nothing out of the ordinary there
[20:46] <stgraber> slangasek: so far what I managed to confirm is that at the time the dhclient hook is called, /run/resolvconf doesn't exist yet, that the interface is brought up through network-interface.conf (I disabled networking.conf) and that the race seems to hit at every boot
[20:46] <stgraber> (if it's indeed a race)
[20:47] <smoser> slangasek, what is it that would guarantee network-interface.conf to not run until /run is mounted?
[20:48] <slangasek> I don't suppose the udev from the initramfs is somehow still running?
[20:48] <slangasek> smoser: see comment on the bug
[20:49] <smoser> slangasek, i can check that.
[20:52] <stgraber> smoser: looks like I managed to break that EC2 instance quite badly ;) mind killing it and giving me a fresh one? :)
[20:52] <smoser> stgraber, i might hvae killed you.
[20:52] <smoser> new one coming.
[20:55] <smoser> stgraber, ubuntu@ec2-184-72-155-176.compute-1.amazonaws.com
[20:55] <smoser> its brand new fresh.
[20:55] <smoser> you'll have to install overlayroot
[20:56] <smoser> and change /etc/overlayroot.conf to have 'overlayroot="tmpfs"'
[20:56] <smoser> then reboot
[20:57] <smoser> slangasek, to determine if "udev from initramfs is somehow still running", i can just look at pid numbers, right?
[20:57] <slangasek> smoser: that should do; or else 'lsof'
[20:58] <smoser> what would lsof show me?
[21:00] <slangasek> smoser: if the exe of the process matches the one on the filesystem
[21:01] <stgraber> slangasek, smoser: looks like my initial try was wrong, networking.conf is what's bringing eth0 online and there's no udev running at that point
[21:01] <slangasek> stgraber: hmm!
[21:02] <slangasek> is local-filesystems being emitted before virtual-filesystems?
[21:02] <stgraber> slangasek: http://paste.ubuntu.com/1120257/
[21:02] <smoser> http://paste.ubuntu.com/1120258/
[21:02] <smoser> it would appear udev not still running.
[21:02] <stgraber> that's the result of "ps faux" placed at the beginning of the dhclient hook
[21:02] <jderose> slangasek: this okay? https://code.launchpad.net/~jderose/ubuntu/quantal/libav/fix-937561-q/+merge/117341
[21:02] <slangasek> the local filesystems are certainly all mounted before the virtual mounts get done
[21:02] <smoser> note, slangasek all i did was 'ps -w > /dev/.initramfs/ps-w.txt' in the initramfs and the show pids.
[21:03] <slangasek> I thought mountall was supposed to not emit local-filesystems until after virtual-filesystems, though
[21:03] <smoser> the man page states that explicitly, slangasek
[21:03] <smoser> (man local-filesystems)
[21:03] <slangasek> jderose: looks perfect
[21:04] <jderose> cool, i'll learn this stuff yet :P
[21:04] <slangasek> smoser: right, that must be where I got the idea ;)
[21:08] <smoser> i have to run
[21:09] <stgraber> [    6.714904] virtual
[21:09] <stgraber> [    6.753640] local
[21:09] <stgraber> so assuming my test worked, local is indeed properly emitted after virtual
[21:10] <stgraber> (the above is the result of two upstart jobs, one starting on local-filesystems, the other on virtual-filesystems, each printing local or virtual to /dev/kmsg)
[21:10] <slangasek> stgraber: well, virtual-filesystems and local-filesystems are signals, so there's no guaranteed ordering of the jobs that start on each ;)
[21:11] <slangasek> but there *is* guaranteed ordering of jobs starting on mounted /run
[21:14]  * stgraber adds a similar check for resolvconf and networking and reboots
[21:16] <stgraber> [    4.598897] networking
[21:16] <stgraber> [    5.016864] init: cloud-init-nonet main process (241) killed by TERM signal
[21:16] <stgraber> [    5.632677] resolvconf
[21:16] <stgraber> [    5.955406] virtual
[21:16] <stgraber> [    5.989643] local
[21:17] <stgraber> ubuntu@ip-10-202-249-151:~$ grep -r 'start networking' /etc/init/
[21:17] <stgraber> /etc/init/cloud-init-nonet.conf:   start networking >/dev/null
[21:17] <stgraber> smoser: ^
[21:18] <stgraber> "start on mounted MOUNTPOINT=/ and stopped cloud-init-local" with clout-init-local being "start on mounted MOUNTPOINT=/"
[21:18] <stgraber> so basically as soon as / is mounted, "start networking" is directly triggered by cloud-init-nonet bypassing the start condition
[21:26] <slangasek> jderose: as an aside, if you add debian/changelog and your source changes at the same time, you can use 'debcommit' to get everything committed to bzr with a commit message based on debian/changelog - and with automatic bug references added to the bzr branch
[21:27] <jderose> slangasek: ah, okay. but my changelog wasn't wrong, was it? I just didn't do it the best way?
[21:33] <slangasek> jderose: changelog is fine, just offering a hint of a shortcut for UDD
[21:34] <jderose> slangasek: i don't seem to have the 'debcommit' command (on precise)... what package provides this plugin?
[21:34] <slangasek> jderose: it's a standalone command, not a bzr plugin - part of devscripts
[21:34] <jderose> ah, okay... i was trynig to `bzr debcommit` :P
[21:36] <slangasek> I guess it would make sense for 'bzr commit' to do the same thing under the covers if bzr-builddeb is installed... dunno if it does something like that currently
[21:36] <jderose> i have builddeb installed, commit didn't seem to do anything special
=== cpg|away is now known as cpg
[21:50] <slangasek> jderose: btw, I see that Debian also has libav 0.8.3 now; I don't suppose you would be interested in merging Debian's changes into quantal?
[21:50] <jderose> slangasek: sure... so i'd just start with the debian package from bzr, and then add my patch?
[21:51] <slangasek> jderose: well, you would start with lp:ubuntu/libav and do a 'bzr merge lp:debian/libav' and fix it up from there
[21:51] <jderose> okay, so there are ubuntu-specific changes that i need to preserve?
[21:52] <slangasek> I don't know if there are or aren't ;)
[21:52] <jderose> gotcha, guess i'll find out :)
[21:52] <slangasek> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: slangasek
[22:23] <jderose> slangasek: so merge in from debian creates some fairly crazy conflicts that i'm having a hard time understanding what to do with just yet
[22:23] <jderose> slangasek: but the channel topic makes me thing you might be the person i should pester about this also - https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1022515
[22:23] <jderose> :)
[22:23] <ubottu> Launchpad bug 1022515 in couchdb (Ubuntu) "Please sync (sort of) couchdb 1.2.0-1 from Debian unstable" [Undecided,Confirmed]
[22:25]  * slangasek grins
[22:28] <slangasek> jderose: having a look at the couchdb bug; in the meantime, could you please update the description on bug #937561 to comply with https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ?
[22:28] <ubottu> Launchpad bug 937561 in libav (Ubuntu Precise) "H264 MOV files from Canon DSLR resolution reported as 1920x1088" [Medium,In progress] https://launchpad.net/bugs/937561
[22:29] <jderose> sure
[22:30] <slangasek> smoser: so why *was* cloud-init-nonet calling 'start networking' directly?
[22:30] <shbk2> hello , guys! maybe someone know what can be a reason of this http://stackoverflow.com/questions/11730181/linux-module-compilng-missed-folder-asm
[22:38]  * ogra_ wonders if anyone has ever seen a kernel lock up hard once you add break=bottom to the cmdline 
[22:39] <slangasek> ogra_: I've seen a system wind up with no usable console, which is kinda the same thing?
[22:40] <ogra_> right, we had no proper console until very late in the initrd ... thats why i wanted to see it booting with the break statement to actually look at the initrd
[22:40] <ogra_> it seems ot keep the grub gfx screen up until very late in the boot
[22:41] <slangasek> right, you've probably managed to boot in a scenario that has no console in the initramfs ;)
[22:41] <ogra_> and the whole thing takes up to 90sec to boot from a 90MB/s disk
[22:41] <ogra_> though jibel said he has seen 3 minute boots as well on that HW
[22:42] <slangasek> try setting GRUB_GFXPAYLOAD_LINUX=text ?
[22:42] <ogra_> will do so tomorrow, we finished already but i plan to invest an hour into inspecting that
[22:43] <slangasek> keeping the grub screen up until the drm driver takes over is by design... and it generally works except when you want to debug things happening before the drm drivers get loaded
[22:43] <ogra_> that HW makes me curious ... many of my arm devices are faster
[22:43] <ogra_> but looking at the specs of the components there is really no reason to be slow
[22:43] <infinity> If it's taking 90s, it's probably breaking on a wait-for-root.
[22:43] <infinity> And getting stuck in the "we'll just sit here for 60s twiddling our thumbs" trap.
[22:44] <ogra_> wait-for-root actually only seems to take 1-2 sec in the bootchart
[22:44] <infinity> My firewall does that.
[22:44] <ogra_> there was a 30sec ureadahead ... so we removed ureadahead completely for a test ...
[22:44] <infinity> Or is that wait-for-network?  I dunno.  Wait-for-something.
[22:44] <ogra_> which didnt change anything (didnt get slower either though)
[22:44] <infinity> In my case, it's because I have a driver that throws udev into an infinite loop. :P
[22:45] <ogra_> yeah, my SIS based FW does that too
[22:45] <ogra_> booting takes over 5min on that HW
[22:45] <ogra_> but i usually dont reboot it and if it runs its fine ... its a firewall after all
[22:46] <ogra_> but 90sec or more on a modern macbook pro is just laughable
[22:47] <ogra_> this sprint will actually make me blog again ... so many funny things ...
=== dendrobates is now known as dendro-afk
[23:17] <slangasek> jderose: so I'm still looking at the couchdb merge; it's a non-trivial update which is taking me a while to verify
[23:17] <slangasek> jderose: your branch also doesn't appear to include an actual merge of the Debian packaging, which means I won't be using that branch directly so as not to lose the UDD branch history here
[23:18] <jderose> slangasek: yeah, i know... thanks
[23:20] <jderose> slangasek: so the UDD history from Ubuntu is kinda nonsense as the ubuntu package was carrying like 20k lines in debian/patches
[23:20] <jderose> slangasek: and that ubuntu package is a dead end road that isn't being maintained by any canonical folks now... so in my opinion, having a low, easy to understand delta with the debian package is the important thing
[23:21] <jderose> i'm trying to talk the debian maintainer into accepting this split so ubuntu can start syncing from debian, carry no ubuntu specific changes... but that hasn't happen yet
[23:26] <slangasek> jderose: I agree that we want to reduce the delta; I just am not going to create a UDD branch history that doesn't reflect this being am erge :)
[23:28] <jderose> slangasek: gotcha... so how should i do that? or, is there something i need to do to prepare what i have for review?
[23:31] <slangasek> jderose: at this point it's a matter of me running the bzr merge here, fixing up the conflicts (in progress), and then comparing with your branch and working through any differences between the two
[23:32] <jderose> slangasek: okay, thanks! sorry that i didn't do things the right way UDD-wise
[23:32] <slangasek> no worries
[23:33] <slangasek> jderose: so one thing I notice up to this point is the dropping of all the spidermonkey and couchio patches
[23:33] <slangasek> are those merged upstream?
[23:34] <jderose> yes, i believe so
[23:34] <slangasek> ok cool
[23:35] <slangasek> it definitely looks like most of the delta goes away just as part of a merge... it's just a bit of a manual merge to get there
[23:36] <jderose> slangasek: when you're resolving big merge conflicts in UDD... how do you go about it? i'm a bit lost as to where to even start with libav :)
[23:37] <slangasek> jderose: 'bzr conflicts'; pick one, look at it, figure out what the right answer is, make that change, 'bzr resolve $foo'
[23:37] <slangasek> all the real complexity is in "figure out what the right answer is" ;)
[23:38] <jderose> slangasek: yeah, i was hoping there was some `bzr magic-helper-gnome` command that i just didn't know about :P
=== dendro-afk is now known as dendrobates
[23:55] <slangasek> jderose: couchio-fix-0001-replicator_redirect_atts.patch doesn't seem to be upstreamed, but otoh the source file it points at (couch_rep_httpc.erl) has disappeared.  how confident are you that dropping this isn't going to cause regressions?
[23:56] <slangasek> in fact, several of these patches are in that scenario
[23:59] <jderose> slangasek: very confident in that case... 1.2.0 brings a completely rewritten replicator... and that just happens to be something that i test like crazy almost daily :)
[23:59] <slangasek> ok