[01:57] <hyperair> any ubuntu-release members present?
[01:57] <hyperair> https://bugs.launchpad.net/ubuntu/+source/glib-networking/+bug/981856 <-- i'm wondering if this deserves an Ffe
[01:57] <hyperair> FFe*
[02:04] <RAOF> It seems a little late for a FFe?
[02:19] <hyperair> RAOF: it's a bugfix, though
[02:19] <RAOF> Then it doesn't need a FFe
[02:19] <hyperair> RAOF: i was asking for a finalfreeze exception.
[02:20] <hyperair> it's in main.
[02:20] <RAOF> Ah.  Stupid overloaded initials :)
[02:20] <hyperair> ;-)
[02:35] <slangasek> hyperair: looks reasonable to me for an SRU, but not a freeze exception
[02:36] <slangasek> (assuming there's a reason to expect a file uri to work here at all?)
[02:37] <slangasek> looks like pac+file:// specified directly should work; is that what upstream recommends?
[02:57] <hyperair> slangasek: i'm pretty sure it doesn't, though.
[02:58] <slangasek> ah, too bad
[02:58] <hyperair> there's no way to use a local pac file without running a http server.
[02:58] <hyperair> not without said patch
[02:58] <hyperair> glib-pacrunner checks for protocols starting with http
[02:59] <hyperair> failing which it just uses wpad:// instead
[02:59] <slangasek> ok
[02:59] <hyperair> so this should still be an SRU then?
[02:59] <slangasek> yes
[03:03] <hyperair> okay then
[03:19] <ScottK> slangasek: Thanks.  I'm really glad you found something.
[03:20] <slangasek> it was easy to find, I just had to put my head to the bottom of the paper bag and look
[03:21] <jbicha> slangasek: don't keep your head in there too long...
[03:21] <slangasek> don't worry, there are air holes
[03:31] <shang> hi all, I have a uefi boot related issue, I was wondering if anyone knows any kernel parameter that I could try?
[04:28] <pitti> Good morning
[06:52] <dholbach> good morning
[06:53] <micahg> mvo: there's an apt fix in the sponsorship queue: Bug #985852
[06:58] <mvo> micahg: let me check
[07:55] <jibel> doko_, lucid main upgrade pass with python 2.7.3-0ubuntu2
[07:56] <pitti> jibel: \o/
[07:56] <pitti> that was the only one which failed again, right?
[07:56] <jibel> pitti, right
[07:58] <doko_> jibel, thanks for testing. however I don't understand why it did start to fail ...
[07:59] <doko_> pitti: this would require an update for python2.7...
[08:00] <htorque> hi all! do the dvd images still contain more than just the language packs? in that case i was wondering if anyone could give bug 873350 a little priority upgrade?
[08:00] <pitti> doko_: if it's upgrade only, a 0-day SRU will do fine
[08:00] <doko_> seb128, bug 960967 turned out to be a bug in eog, could you forward it, and maybe not use the internal jpeg copy?
[08:00] <pitti> but it can build in -proposed either way, and then we can fold it into the release if we're going to respin
[08:00] <seb128> doko_, oh, sorry about that, sure I will do!
[08:01] <micahg> htorque: #ubuntu-website would probably be a better place to poke
[08:01] <htorque> micahg: ah, thanks! didn't know that exists.
[08:06] <doko_> seb128, he has a package in https://launchpad.net/~tom-gall/+archive/packages/+packages
[08:07] <seb128> doko_, ok, I just read the comments, good work there, I will make sure it goes upstream and in the next point release (which will be SRUed to precise)
[08:42]  * infinity just spent way too long trying to sort out why a documented feature in gnupg wasn't working.
[08:43] <infinity> Turns out that it helps if the feature is implemented.
[08:52] <mvo> infinity: haha, the command-fd ?
[08:52] <infinity> mvo: No, %transient-key in batch mode.
[08:52] <infinity> mvo: Only implemented in 2.1, AFAICT, but documented ALL OVER.
[08:54] <mvo> aha
[08:54] <infinity> mvo: I thought I was going insane until I just broke down and read the source.
[08:55] <infinity> mvo: While that's touted as one of the "advantages" of FLOSS, I'm not sure I appreciate having to do it. ;)
[08:55] <mvo> well, at least you can :) and I find it often a really good strategy
[08:55] <Chipzz> reading the source and strace :)
[08:55] <mvo> (but yeah, matching documentation is actually prefered still ;)
[08:57] <infinity> Matching, or even outdated.  I was mind-numbingly confused by the documentation being AHEAD of the source.
[08:57] <infinity> That just ain't right.
[08:58] <micahg> infinity: in the mood for removals?
[08:59]  * micahg guesses he should just file a bug
[09:01] <infinity> micahg: No, I'm happy to take 'em without bugs, as long as they have justifications.
[09:01] <micahg> bug #986071
[09:03] <vibhav> Could somebody nominate https://bugs.launchpad.net/onboard/+bug/958385 for oneiric?
[09:04] <micahg> vibhav: why, where is it needed for oneiric?
[09:05] <vibhav> affects oneiric too
[09:05] <infinity> micahg: Done.
[09:08] <micahg> vibhav: done
[09:08] <vibhav> micahg: thanks!
[09:19] <vibhav> micahg: distroseries needs to be oneiric-proposed and the version 4.1, right?
[09:20] <micahg> vibhav: yes for series, no for version, grab the one from -updates
[09:22] <vibhav> so the version will be +1?
[09:22] <micahg> no
[09:23] <micahg> oh, yes, 0.96.1-0ubuntu0.2
[09:23] <vibhav> thanks
[09:46] <rbasak> pitti: you sponsored/uploaded https://bugs.launchpad.net/ubuntu/+source/ipsec-tools/+bug/947309/comments/11 but it doesn't seem to have appeared anywhere. Is something stuck, or did the upload fail?
[09:46] <pitti> rbasak: it's in https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
[09:46] <pitti> for ubuntu-sru review
[09:47] <rbasak> Ah OK, thanks
[10:20] <cjwatson> infinity: thanks for the writer2latex merge; beat me to it
[10:22] <infinity> cjwatson: Yeah, I grabbed the source and started on it, and then read the "Thanks for Colin" in the changelog, and wondered if you'd be grumpy that I stole your merge.
[10:22] <infinity> cjwatson: But I had momentum at that point. :P
[10:22] <infinity> s/for/to/
[10:28] <cjwatson> infinity: *shrug* I'd got as far as test-building my merge before I noticed you'd done it :)
[10:36] <apw> bryceh, slangasek, it is looking like the race we thought we are experiencing ought to be fixed by an upstream change already in the version in precise .. do we have a reproduce by ?
[11:05] <pitti> cyphermox, stgraber: hm, did we recently lose the "persistent rfkill" feature? I noticed that bluetooth is always on after booting again, even though I keep disabling it (I don't need it most of the time)
[11:17] <stgraber> pitti: hmm, no, it should work... anything interesting in /var/log/upstart/rfkill*.log ?
[11:18] <pitti> I don't have that file
[11:18] <pitti> nor any rotated ones
[11:19] <pitti> /var/lib/rfkill/saved-state is 0 bytes
[11:19] <stgraber> hmm, can you try to run rfkill-store manually?
[11:20] <stgraber> the script in /etc/init/rfkill-store.conf
[11:20] <pitti> $ sudo start rfkill-store
[11:20] <pitti> $ cat /var/lib/rfkill/saved-state
[11:20] <pitti> tpacpi_bluetooth_sw 1
[11:20] <pitti> phy0 0
[11:20] <pitti> that seems to work
[11:21] <pitti> when I enable BT in the indicator and run sudo start rfkill-restore it gets properly disabled again
[11:21] <pitti> so restoring seems to work, but storing not for some reason
[11:21] <pitti> stgraber: ok, thanks for the pointer; I'll have a closer look
[12:14] <lool> Hey there!  It's been multiple days in a row that I get a cron.daily email that /etc/cron.daily/update-notifier-common has triggered a download for flashplugin-installer; it seems to be output of a successful job, but it keeps doing it every night
[12:14] <lool> I googled the message, but I didn't find any bug for this
[12:14] <lool> did anyone else see this?
[12:15] <lool> Hmm now that I check closely, I see that it downloaded the same file on the 17th and the 18th, nothing on the 19th (but laptop was sleeping) and a new file on the 20th
[12:32] <pitti> ooh, is that what sends me cron mail about lost+found not existing?
[12:44] <lool> pitti: Not sure how it directly relates; I would think of some fsck job doing this rather than flashplayer/update-notifier
[12:44] <pitti> it started a few days ago
[12:45] <lool> there were a couple of update-notifier updates, but more like a week ago
[12:46] <lool> that said, I didn't update daily
[12:53] <lool> pitti: I actually received a flashplugin update yesterday, so that run seems legit; not sure what happened a couple of days ago; I'll see if it happens again tomorrow; it seems to be that recent update-notifier uploads might have caused output to be properly reported from the cron job, and now we might have to look at silencing it
[12:55] <lool> I have a successful stamp file, so at least it shouldn't trigger daily
[13:01] <lool> pitti: ah, I don't know if it relates but I think I have a bug in the timedelta handling in there; it is using os.times() which is an arbitrary base time which can also overflow and it's comparing that to a file modification time
[13:22] <popey> MacSlow: just fyi, i have recording hangouts perfect here
[13:25] <MacSlow> popey, good to know that it's just a magic combination of right settings... if you can write me a quick summary via email about your setup when you've some time, that would be greatly appreciated!
[13:25] <popey> will do
[13:26] <MacSlow> popey, sweet... thanks!
[13:26] <lool> pitti: Filed as LP #986183 with a proposed approach for the timestamp checks
[13:34] <pabs3> a few days ago I got a hash sum mismatch from apt with this URL, where should I report that? http://ports.ubuntu.com/dists/precise/universe/binary-powerpc/Packages.gz
[13:36] <cjwatson> Does it still mismatch?  It's probably a broken proxy.
[13:36] <cjwatson> Or very unlucky timing I guess.
[13:39] <pabs3> unlucky timing probably. in Debian we have a two-stage mirroring process that prevents that issue, I was surprised to see it on the official Ubuntu archive though
[13:41] <infinity> lool: You might want to talk to slangasek about your update-notifier woes when he wakes up, a lot of that it shiny new code of his.
[13:42] <infinity> pabs3: Two stage mirroring still allows a (small) window.
[13:42] <infinity> pabs3: The only way to actually fix it is to re-work the Packages/Release concept a bit (we have a bug about this, but it's going to take some bikeshedding)
[13:44] <rbasak> bug 972077
[13:45] <lool> infinity: It actually seems it was the broken flashplugin upload wiht only half the checksums updated that triggered the odd no-change redownload email; the regular behavior of update-notifier seems ok, except the failed hook time handling which is bogus (see bug)
[13:46] <lool> infinity: The only remaining wonder I have is why I'm getting this as a cron notification at all?  Shouldn't this run as part of the package update?
[13:46] <infinity> lool: Ahh, so it's all my fault.  Comforting! ;)
[13:47] <infinity> lool: It's vorlon's shiny new crack to allow async downloading of external tarballish packages.
[13:47] <infinity> lool: I'm not actually sure I understand the use-case, but people seemed to think it was important. :P
[13:49] <lool> infinity: ah so it's indeed on purpose; odd, I was expecting it would at least try the download immediately during the upgrade
[13:50] <infinity> lool: I think it's meant to do that too?  I dunno.
[13:50] <lool> slangasek: Is it intended that updating e.g. flashplugin triggers a download + email at the next cron.daily run?  in any case the failed download timestamp handling is bogus, see #986183
[13:50] <lool> infinity: maybe it does both and that's another bug
[13:53] <lool> infinity, slangasek: Indeed, I checked apt term.log and it shows the download of the latest version happening yesterday, and then I download it again from cron
[13:53] <infinity> lool: oops.
[14:14] <cr3> hi folks, what's that library that does openid integration on the desktop? I believe it uses dbus or something...
[14:15] <beuno> cr3, ubuntu-sso?
[14:17] <cr3> beuno: that sounds right, I'll have a look at it. thanks!
[14:20] <jibel> mvo, bug 986201 never seen it before
[14:23] <jsjgruber> When is/was the precise archive freeze?
[14:23] <cjwatson> A couple of weeks back.
[14:24] <jsjgruber> Did that include the Universe archive?
[14:25] <mvo> doko: can you help with 986201 ? it looks like a pycentral issue, check https://launchpadlibrarian.net/102687559/VarLogDistupgradeMainlog.txt
[14:32] <cjwatson> jsjgruber: no, that freezes, err, I forget, https://lists.ubuntu.com/archives/ubuntu-release/2012-April/001083.html suggests the 24th
[14:33] <jsjgruber> thanks
[14:33] <Laney> jsjgruber: Depends what you mean by "freeze". It's still open for bug fixes, yes.
[14:34] <jsjgruber> I've had a bug fix merge in for a while for a universe package and got word last night that it had to be a SRU.
[14:34] <Laney> from a sponsor?
[14:35] <jsjgruber> Right.
[14:36] <jsjgruber> He asked for better test information, too, so I'll do that and resubmit it.
[14:49] <doko> mvo: where can I get release-upgrader-python-apt (0.8.0ubuntu9~upgrader3) ?
[14:50] <slangasek> lool: the cron job should never be downloading unless there was some failure in processing previously
[14:51] <slangasek> lool: and there's a cron job because we deliberately don't fail the package install if the download fails, so we need some way to periodically retry the download so we don't just leave users with packages installed but unusable
[14:52] <slangasek> doko: lucid-updates
[14:53] <slangasek> apw: reproduce by> I think hallyn was seeing this one?
[14:54] <lool> slangasek: But the download seems to have worked fine: http://paste.ubuntu.com/938365/
[14:56] <lool> slangasek: flashplugin-installer was configured afterwards though; this was after unpacking but before configuring flashplugin-installer, but I would think that's ok?
[14:57] <slangasek> lool: that's a bit weird, certainly
[14:57] <slangasek> lool: oh wait, it happened *before* flashplugin-installer was configured? Haha, I fail
[14:57] <slangasek> lool: I know what happened... see if you can spot the bug in the flashplugin-installer postinst :-P
[14:58] <lool> slangasek: ah right, touch there
[14:58] <lool> just after installing
[14:58] <slangasek> not the touch... the rm
[14:58] <slangasek> which I guess needs to be moved to the preinst
[14:59] <lool> ah
[14:59] <slangasek> since we're unconditionally removing the stamp files on the assumption that the new version needs a redownload, but the ordering of the package configuration means it's already been downloaded
[14:59] <lool> yup, makes sense
[15:00] <lool> slangasek: Did you work on the update-notifier failed hook handling as well?
[15:00] <doko> mvo, hmm, the package does have the Python-Version attribute
[15:00] <slangasek> lool: I haven't worked on it yet, but I was vaguely aware of that problem
[15:00] <doko> mvo: do you know how to reproduce the issue?
[15:00] <slangasek> ("vaguely" meaning "I may or may not have put a comment in the source")
[15:01] <lool> slangasek: Ok; I was looking for someone able to test it properly to prepare an upload
[15:01] <slangasek> apw: correction, hallyn's bug was a different one; so the reproducers for this are random bug submitters fwiw (bug #982889, bug #966868)
[15:02] <slangasek> lool: I think those changes probably want test-suiting
[15:17] <jibel> mvo, doko I could reproduce it with a cdromupgrade and no network connection. bug 986233. trace is similar
[15:20] <doko> jibel, but it succeeds with network?
[15:22] <jibel> doko, it seems so, it's currently downloading the upgrades
[15:23] <mvo> jibel: oh, so maybe a outdated python-central? we can add "patch" support if we know what needs patching in pycentral to fix this
[15:23] <doko> jibel, so to reproduce: install lucid from the alternate, upgrade to lucid-updates, then take it offline and then do the upgrade with the alternate precise CD?
[15:26] <jibel> doko, correct
[15:27] <doko> jibel, can you see if the new python-central is unpacked before the release-upgrader-python-apt package is configured?
[15:30] <doko> mvo, jibel: we might want the fix for: +  * Fix up for multiarch dpkg: /var/lib/dpkg/info/$pkg.list is now no longer
[15:30] <doko> +    guaranteed to exist, it may be /var/lib/dpkg/info/$arch/$pkg.list
[15:30] <doko> +    (Steve Langasek).
[15:32] <jibel> doko, here is the sequence from dpkg.log
[15:32] <jibel> paste.ubuntu.com/938420
[15:33] <mvo> doko: its instaled pretty much before anything else
[15:36] <cjwatson> doko: well, it's $pkg:$arch.list now
[15:36] <cjwatson> we don't want $arch/$pkg.list since that's not the current multiarch layout :)
[15:51] <doko> mvo: is PYCENTRAL_NO_DPKG_QUERY set for the upgrade?
[15:53] <cjwatson> doko: I'm fixing the pymvpa build now
[15:53] <mvo> doko: yes
[15:54] <doko> cjwatson: so I should check for $pkg.list and $pkg:$arch.list ?
[15:54] <mvo> doko: but from the bugreport it seems like pycentral is unhappy about the missing(?) Python-version field - or is that a red-hering?
[15:55] <doko> mvo: read backlog, the attribute is there
[15:55] <cjwatson> doko: yes, well, if you can't use an actual published interface instead
[15:55] <cjwatson> (i.e. dpkg-query -L)
[15:56] <doko> cjwatson, right, used by default, unless you set PYCENTRAL_NO_DPKG_QUERY, which the installer does
[15:56] <doko> mvo: do you remember why we did this?
[15:56] <cjwatson> ah
[15:57] <cjwatson> bizarre, speed issue or something?
[15:57] <doko> I think that is a left-over for the previous lts upgrade, when we didn't have the -L option in dpkg-query
[15:58] <cjwatson> that'd be a surprise, it's been there forever
[15:58] <doko>   * pycentral.py:
[15:58] <doko>     - if the PYCENTRAL_NO_DPKG_QUERY environment is set
[15:58] <doko>       pycentral will not use dpkg-query (needed for
[15:58] <doko>       dapper->hardy upgrades where dpkg-query might be
[15:58] <doko>       confused about triggers information in the status
[15:58] <doko>       file)
[15:58] <cjwatson> ah
[15:58] <doko>  -- Michael Vogt <michael.vogt@ubuntu.com>  Wed, 21 Nov 2007 15:25:03 +0100
[15:59] <doko> mvo: how do you want to fix this? just not setting the env var?
[15:59] <mvo> doko: if you feel like this is the right approach, that is fine with me
[16:00] <doko> mvo: yes, I think so
[16:00] <mvo> doko: we could add a patch to the releas-upgrader that patches pycentral before it starts too
[16:00] <mvo> doko: ok, then I will upload with that disabled
[16:00] <doko> mvo: no, no
[16:00] <doko> mvo: where do you set the PYCENTRAL_NO_DPKG_QUERY env var?
[16:01] <mvo> doko: right when it starts
[16:01] <doko> mvo: so just don't set it
[16:02] <mvo> ok
[16:02] <doko> cjwatson, I'll fix the direct lookup anyway
[16:03]  * cjwatson nods
[16:09] <apw> slangasek, ok the failure in libdrm there is reporting the correct open, ie. it opened successfully so we did not hit the EAGAIN issue...
[16:24] <apw> bryceh, you any idea where i'd find the code which reports the SetVer error for this bug ?
[16:42] <doko> mvo, will you fix update-manager, or should I upload the fix?
[16:42] <mvo> doko: I just uploaded it
[16:42] <doko> ok
[16:43] <dupondje> barry: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/850264 doesn't this fix your issue ?
[16:55] <pitti> slangasek: thanks for pointing out bug 937249; I tracked it down, uploading SRU now
[16:55] <slangasek> pitti: sweet, thanks
[16:55] <pitti> that was a funny one
[16:55] <slangasek> pitti: and yes, I'm using a non-standard icon theme here too :)
[16:56] <pitti> it was really lucky to not crash with the standard ubuntu themes
[16:56] <pitti> because they don't use an icon cache, being SVG only
[16:56] <pitti> (or at least not a system-wide one)
[16:58] <vibhav> Could somebody nominate https://bugs.launchpad.net/ubuntu/+source/pan/+bug/364732 for currently supported Ubuntu releases?
[17:03] <slangasek> mvo: still around?  We're looking at this u-m upload right now; since it only affects LTS->LTS upgrades, using an image that we aren't going to be pressing to CD, we might ask to do this as an SRU instead of pushing it into .0.  If so, do you have time to reupload to -proposed today or would you like me to take care of it?
[17:05] <vibhav> Also, is it compulsary for me to create patches for packages that have the source format '1.0'
[17:05] <vibhav> OR shall I just prepare a raw debdiff?
[17:09] <barry> dupondje: hmm, i'll give it a try.  maybe slangasek has an opinion (on whether the fix for bug 850264 should be expected to also fix bug 924079)
[17:09] <slangasek> barry, dupondje: it is not expected to
[17:10] <slangasek> 924079 is about package ordering
[17:10] <slangasek> 850264 is about wrong resolution of deps
[17:10] <cjwatson> vibhav: if it doesn't have some kind of patch system, you should just change the source directly rather than introducing a patch system in an Ubuntu delta
[17:11] <barry> slangasek: okay cool.  note the feedback from mvo (channeled through me) in the latter bug
[17:11] <SpamapS> can somebody please explain this seemingly insane patch to me: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/python-virtualenv/precise/view/head:/debian/patches/pep3147-dist-packges.patch ?
[17:11] <SpamapS> tumbleweed: perhaps you can actually. ^^
[17:12] <tumbleweed> SpamapS: how is that insane?
[17:12] <SpamapS> tumbleweed: a giant block of uuencoded text with no explanation on how to regenerate it?
[17:12] <SpamapS> also, I just say it *seems* insane to me
[17:12] <tumbleweed> I sorted that out upstream :)
[17:12] <SpamapS> it may be perfectly sane
[17:13] <tumbleweed> basically the block of uuencoded text is the same as the readable diff around it
[17:13] <tumbleweed> virtualenv embeds lots of things inside virtualenv.py
[17:14] <tumbleweed> it now has everything that it embeds, and the scripts to update it, in the source tarball, so this kind of thing can be done more sanely
[17:14] <SpamapS> tumbleweed: right, and it looks like its been applied in the new release. But its just that the patch itself offers no way to refresh it.
[17:14] <SpamapS> tumbleweed: since I have your attention, I was going to cherry pick the fix for bug 986227 .. but then I saw that 1.7.1.2 is out and includes it...
[17:15] <SpamapS> tumbleweed: If I were to update it in the DPMT svn tree, would you be up for sponsoring it? Then I can just sync
[17:15] <tumbleweed> sure
[17:15]  * tumbleweed seems to be a virtualenv uploader these days
[17:17] <SpamapS> tumbleweed: thanks .. I'll poke you when its updated in the tree
[17:17] <tumbleweed> SpamapS: bin/rebuild-script.py btw
[17:18]  * tumbleweed wishes a virtualenv upstream would review https://github.com/pypa/virtualenv/pull/231
[17:32] <apw> 555555555555555555555555555555555555555
[17:32]  * cjwatson decrements apw
[17:33] <apw> 555555555555555555555555555555555555554
[17:33] <apw> damnable keyboard, never had _that_ happen before
[17:34] <cjwatson> bottles of beer on the wall
[17:34] <cjwatson> sounds like a kernel team night out really
[18:07] <roaksoax> jdstrand: howdy!
[18:08] <roaksoax> jdstrand: i've attached the apparmor profile to bug #975442
[18:08] <roaksoax> jdstrand: I'd appreciate your review. Thanks! https://launchpadlibrarian.net/102704100/usr.bin.cobblerd
[18:09] <jdstrand> roaksoax: thanks! why is dac_override needed?
[18:10] <jdstrand> roaksoax: beyond that, it looks good :)
[18:11] <jdstrand> roaksoax: I'll respong in the bug
[18:11] <jdstrand> respond
[18:14] <roaksoax> jdstrand: TBH, the reason why I added dac_override was becaose of this:  apparmor="DENIED" operation="capable" parent=1 profile="/usr/bin/cobblerd" pid=32110 comm="cobblerd" capability=1  capname="dac_override
[18:19] <apw> hallyn, slangasek, ok i cannot _see_ any way this can occur, i have therefore shoved some debug in the drm setversion ioctl to see if we see anything ... see the bug for a link
[18:21] <jdstrand> roaksoax: hmmm, I see it is calling os.setuid(100)
[18:21] <slangasek> apw: so the EAGAIN is only on open?  I had inferred it was when trying to use the dev rather than open it
[18:21] <apw> slangasek, only on open indeed.  after that it is out of the picture
[18:21] <apw> slangasek, anyhow if we can get some testing i've added lots of dmesg cruft for it
[18:22] <jdstrand> roaksoax: commented in the bug
[18:22] <slangasek> apw: right - hallyn isn't likely to be able to help here, IIRC we re-triaged his issue as a binary driver problem rather than a drm one
[18:23] <apw> slangasek, well if its reproducible we may find it, if not, hey ... we should not worry so much
[18:24] <apw> slangasek, its very odd.  its almost like we are doing ioctls on the drm stub, which btw is impossible
[18:26] <slangasek> apw: *we* can't reproduce it so far; but people with particular hardware configs can
[18:27] <apw> slangasek, ok then we rely on them to test, and after a long discussion with upstream we have little clue as to the cause ... hense the debug kernels
[18:35] <roaksoax> jdstrand: uhmmm adding the deny still causes the daemon to start
[18:36] <roaksoax> jdstrand: uhmmm adding the deny still causes the daemon to not start
[19:15] <jdstrand> roaksoax: did you see my last comment-- it's good to go :)
[19:47] <bryceh> apw, you mean the -intel race condition bug? seems we traced the error message down to a routine in libdrm
[19:50] <slangasek> bryceh: so there's reason to believe it's userspace-side?
[19:51] <bryceh> slangasek, the code that notices the kernel driver is missing/borked/unready is userspace-side, yes.
[19:51] <slangasek> bryceh: hmm, so there's already code for this and it's not working right?
[19:53] <bryceh> slangasek, the code is an assert, and it's working fine (that's the problem *grin*)
[19:53] <slangasek> heh
[19:54] <slangasek> but if that changes... doesn't this still amount to user-side polling for the driver to be ready?
[19:55] <bryceh> slangasek, how do you mean?
[19:55] <slangasek> fundamentally, we don't *want* to be trying to open the drm device until the kernel's ready
[19:55] <bryceh> slangasek, right
[19:55] <slangasek> we *want* the kernel to tell us when it's ready, but that's not what it's doing
[19:55] <bryceh> right
[19:56] <slangasek> which is why we're hitting an assert... so ideally, we would still fix this on the kernel side?
[19:56] <bryceh> slangasek, yes
[19:56] <bryceh> slangasek, maybe context of my initial comment was missing...  apw had earlier in the scrollback asked me where I'd traced the error that we were getting.  So I said we traced it as far as libdrm.
[19:56] <slangasek> ah
[19:57] <slangasek> sorry, I was assuming I had full context since he'd highlighted me as well :)
[19:57] <bryceh> slangasek, who's on first?
[19:59] <bryceh> slangasek, are you following apw's discussion with airlied on the patch?
[19:59] <slangasek> no
[19:59] <slangasek> is that on the freedesktop bug or somewhere else?
[19:59] <bryceh> it's not on the bug, I think it's lkml, lemme dig it up
[20:00] <bryceh> linux-kernel@vger.kernel.org
[20:00] <bryceh> Subject: [PATCH 0/1] [RFC] DRM locking issues during early open
[20:01] <bryceh> slangasek, https://lkml.org/lkml/2012/4/19/245
[20:04] <bryceh> slangasek, https://lkml.org/lkml/2012/4/19/252 is daniel vetter's reply, worth looking at
[20:18] <roaksoax> jdstrand: i made two additions to the apparmor profile, which are: /var/www/cobbler/ w, and /var/log/cobbler/ r,
[20:18] <jdstrand> roaksoax: ack, sounds fine :)
[20:20] <roaksoax> jdstrand: quick packaging review if you like: http://paste.ubuntu.com/938830/
[20:24] <apw> bryceh, i have posted some test kernels, as the issue is differnet, the hole we carried that patch for was inadvertantly closed by the BKL conversion to drm_global_mutex
[20:25]  * slangasek nods
[20:25] <jibel> all the upgrades from oneiric to precise failed with
[20:25] <jibel> SystemError: E:This installation run will require temporarily removing the essential package python-minimal due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option., E:Internal Error, Could not early remove python-minimal
[20:25] <jibel> filing a bug
[20:30] <jibel> bug 986374
[20:32]  * slangasek squints
[21:18] <Caesar> slangasek: I'm trying to do some archaeology on pciutils (1:3.1.8-2ubuntu1), where you moved the shared libraries to /lib
[21:18] <Caesar> The bug number in the changelog looks incorrect
[21:20] <slangasek> Caesar: sigh - not a wrong bug #, but a private bug
[21:20] <slangasek> Caesar: and not one I can make public, sorry - but I can answer any questions you have
[21:22] <Caesar> slangasek: just trying to understand the reasoning behind the change
[21:24] <slangasek> Caesar: the biosdevname tool needs to be called from udev, so should be on the rootfs regardless of the admin's local partitioning choices
[21:24] <slangasek> and it depends on libpci
[21:24] <Caesar> slangasek: thanks
[21:24] <Caesar> Sort of related, what causes ldconfig to get run after the libraries move?
[21:25] <slangasek> the sort of thing we'd stop worrying about come FedoraUsrMove, I guess :)
[21:25] <Caesar> :-(
[21:25] <bdmurray> slangasek: looking at bug 964115 could free space in /tmp be an issue?
[21:25] <slangasek> Caesar: policy says each library package calls ldconfig from its postinst
[21:26] <Caesar> slangasek: that's what I thought
[21:26] <Caesar> libpci3 doesn't though
[21:27] <slangasek> bdmurray: I suppose it could be... is that what the log points to?
[21:27] <slangasek> Caesar: /var/lib/dpkg/info/libpci3:amd64.postinst shows it for me here?
[21:27] <slangasek> (dh_makeshlibs goodness)
[21:28] <Caesar> slangasek: *facepalm*
[21:28] <Caesar> I was looking at the pre-debhelpered postinst
[21:28] <slangasek> :)
[21:28] <Caesar> Thanks for your time
[21:29] <slangasek> n/p
[21:40] <jeinor> good evening :) anyone have time to perhaps help out on a Ubuntu boot problem (ARM, kernelproblem, Ubuntu Core)?
[21:41] <slangasek> jeinor: I think you're unlikely to learn anything here you haven't already learned.  Have you tried #ubuntu-arm?
[21:42] <jeinor> slangasek: hi there :) thanks for all the help and answer yesterday
[21:43] <jeinor> slangasek: really helpful. I actually got a bit further after your advice, but I'm stuck again now. It seems I can't say anything after joining #ubuntu-arm, you have any idea why? only registered users?
[21:43] <jeinor> slangasek: "cannot send to channel #ubuntu-arm"
[21:45] <slangasek> perhaps so
[21:45] <slangasek> the channel mode has a bit I'm not familiar with ("c")
[21:46] <slangasek> what's the next point you're stuck at?
[21:46] <slangasek> (also, have you considered registering?  it's free ;)
[21:47] <jeinor> slangasek: currently using the webchat.freenode.net, I should perhaps install a client..
[21:47] <stgraber> IIRC 'c' is just the color/bold/... filtering mode
[21:48] <slangasek> ok then
[21:48] <jeinor> slangasek: I got the output we were looking for yesterday from the USB serial cable (used putty to connect to ttyS0)
[21:48]  * slangasek nods
[21:49] <jeinor> slangasek: it boots til the point where it should continue in rootfs (I think). It tries to mount the rootfs partition (or so I believe), but fails
[21:49] <jeinor> slangasek: the error message is "cannot open root device mmcblk02p or unknown-block(0,0)
[21:50] <slangasek> did your original install have an initramfs?
[21:50] <slangasek> and do you still have that?
[21:51] <jeinor> I'm not sure. The original install had a boot partiton and a root fs partition. Both on a SD card. It used a 2.6-kernel, which I am now replacing with kernel 3.3.1, but I'm still using the same kernel command line.
[21:51] <jeinor> the original install booted Ubuntu 10.04 with X fine, and if that requires an initramfs it had one
[21:51] <jeinor> I'll google what that is as we speak :)
[21:53] <slangasek> and you haven't changed the contents of the boot partition at all?
[21:53] <jeinor> I have replaced the /boot/uImage with a new kernel. I compiled 3.3.1 to replace the old 2.6 kernel, and then replaced that on the boot partition.
[21:54] <slangasek> the initramfs is actually separate from the kernel commandline, and passed directly via the bootloader
[21:54] <slangasek> ah, well
[21:54] <slangasek> there's the problem
[21:54] <slangasek> your new kernel doesn't have the driver for the root disk
[21:54] <slangasek> so the firmware can load the kernel off the disk, but then the kernel can't see the disk
[21:54] <slangasek> you should probably get 12.04 working with the vendor-provided kernel first
[21:55] <jeinor> that makes sense. The reason I tried with the 3.3.1 kernel was that I got a looping error message about a "udev, function not implemented" or similar when trying to run ubuntu core using the old 2.6 kernel
[21:56] <jeinor> I figured Ubuntu Core required some functionality not existing in my 2.6 kernel
[21:57] <slangasek> that's possible
[21:57] <slangasek> in that case, upgrading the kernel is necessary... but it's also tricky
[21:57] <slangasek> you're pretty much on your own about making sure you get the right kernel config
[21:57] <jeinor> ok. I actually got the kernel configuration from a forum thread where a user with the same hardware had got it running.
[21:57] <slangasek> and who knows if the upstream kernel even works on this device?
[21:58] <Shinobi> I'm installing 12.04 in VBox and getting guru meditation errors inconsistently.
[21:58] <jeinor> That's why I thought there had to be something wrong with my kernel command line
[21:58] <slangasek> you might want to poke that forum thread to see if that user had an initramfs... if so, you need to generate an initramfs to go with your kernel
[21:59] <jeinor> according to him (the thread is here, if you're interested: http://www.solid-run.com/phpbb/viewtopic.php?f=9&t=493), he just replaced the /boot/uImage and he was up and running
[21:59] <slangasek> hmm
[21:59] <slangasek> well, I'd press *him* for details on the right kernel commandline :)
[21:59] <jeinor> he doesn't mention any initramfs, but perhaps that's obvious if you know what you're doing :)
[21:59] <jeinor> guess who the last person is who wrote in that thread ;)
[22:01] <jeinor> I guess I'll just have to have patience (meaning I will bang my head in the wall trying everything I can think of until he answers)
[22:01] <jeinor> really appreciate your answers and help here though, thanks a lot
[22:02] <slangasek> sure
[22:02] <slangasek> you should really register and get on #ubuntu-arm :)
[22:02] <jeinor> yea, that seems like the best next step. I'll get right into that.
[22:24] <jeinor> slangasek: I actually think the drivers for the SD card reader is setup correctly, it says in the log it finds /dev/mmc0 and /dev/mmc1 (that must be my boot partition and rootfs partion)
[22:24] <jeinor> partition*
[22:25] <jeinor> I just think the kernel loads the wrong one when it tries to mount mmcblk0p2
[22:25] <slangasek> mmcblk0p2 is the root partition; the "p2" means partition 2
[22:26] <slangasek> and the raw disk should be /dev/mmcblk0, not /dev/mmc0, I think
[22:26] <slangasek> but I don't have anything in front of me I can check that against
[22:32] <jeinor>  hmm, you're probably right. But there seems to be something wrong with the way I change the kernel command line. That's probably why it didn't work yesterday as well.
[22:33] <jeinor> I just tried adding --verbose, and that makes the whole process halt when trying to find /boot/uImage. I think there's something I don't understand about u-boot
[22:53] <jeinor> slangasek: aha! apparently I couldn't just change the kernel command line arguments the way I did, it had no effect. I had to regenerate the file /boot/boot.scr using mkimage.
[22:54] <jeinor> slangasek: after doing that, it starts picking up my new kernel command line args. That explains why nothing happened when I added --verbose or removed console= yesterday
[22:54] <jeinor> didn't help to change it to /dev/mmc1 though, still can't find the rootfs :/
[22:54] <slangasek> yes, whatever /dev/mmc1 refers to, it's not your root partition
[22:55] <jeinor> you're right
[22:57] <jeinor> I'm starting to think you're right about the missing drivers.. when it says "here are the available partitions:" it lists none
[23:14] <slangasek> bdmurray: any idea then why edward.donovan is seeing users directed to bug #628104, if there's no bug pattern?
[23:14] <bdmurray> slangasek: nothing utterable
[23:14] <slangasek> clearly users are seeing this error, but I think we need to get a clean backtrace
[23:14] <slangasek> hmm
[23:16] <bdmurray> I've tried recreating it a few times without luck
[23:19] <slangasek> is there anything we've overlooked so far that would explain the users being sent to that particular bug?
[23:26] <bdmurray> slangasek: maybe a bugpattern pointing a duplicate which redirects to that?  I don't see one though
[23:26] <slangasek> hmm
[23:27] <bdmurray> there is a pattern for similar bug 707990
[23:27] <bdmurray> but that matches on DBusException in the title
[23:32]  * slangasek nods