[04:15] RAOF: can you copy chromium to precise-security as well? [04:17] micahg: It wasn't already? Urgh. [04:18] * micahg didn't see it on the list [04:21] whoever synced sinfo, thank you. [04:22] infinity: was that you? ^ [04:23] xnox: 'twas jbicha on 6/30 [04:24] thanks jbicha for sinfo sync [04:24] micahg: ok, but how did you find out? =) [04:25] xnox: quantal-changes :) [04:26] micahg: lp lists it here: https://launchpad.net/~jbicha/+synchronised-packages but not [04:26] https://launchpad.net/ubuntu/+source/sinfo/0.0.46-1 [04:26] =( [04:26] * xnox should start subscribing to quantal-changes.... [04:26] xnox: https://lists.ubuntu.com/archives/quantal-changes/2012-June/003787.html [04:28] xnox: has ev brought you my DVI cable? :) [04:29] slangasek: nope =) will get him tomorrow [04:29] ev: take my DVI cable to work with you! :) [04:30] slangasek: At your leisure, could I get your opinion on https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/978012 [04:30] Ubuntu bug 978012 in e2fsprogs "Please SRU micro bug fix release of e2fsprogs 1.42.4-3ubuntu1 (main) from Quantal (main)" [High,Confirmed] [04:30] slangasek: RAOF needs more work from me [04:30] RAOF: as long as you understand that "my leisure" is likely to only be 18 hours or so from now [04:31] after my recent experience with mdadm... [04:31] sru [04:31] slangasek: That's fine; I just want to get it on your radar. [04:39] xnox: yeah, it would be nice if LP would list who requested the sync on that version page [04:41] jbicha: there's already a bug for that [04:41] micahg: "there is an app for that" vs "there is a bug for that" [04:41] * xnox *sigh* [04:50] jbicha: bug 861488 [04:50] Launchpad bug 861488 in launchpad "Mention sync requester on package version page" [High,In progress] https://launchpad.net/bugs/861488 [05:04] RAOF: I looked at it when it was first filed, and the rationale all seemed sensible then. Haven't revisited it, though. [05:05] infinity: Agreed, except possibly for the "makes my life easier" bit. It's just a sizable chunk of diff for a critical package. [05:20] RAOF: Yeah, give this one to me. I was watching it earlier, but didn't notice Ted's updated comments more recently. [05:20] RAOF: I'm in a reasonable position to review, though. [05:20] infinity: Excellent. [05:20] This is an outcome I was hoping for. === Guest65630 is now known as Ursinha === Ursinha is now known as Guest68258 [06:33] RAOF: howdy ho, I've uploaded a new upstream microrelease (ugh) of libmusicbrainz to precise-proposed. the current version became obsolete when Musicbrainz changed their web api after precise release :/ [06:33] bug 1005075 [06:33] Launchpad bug 1005075 in libmusicbrainz "Libmusicbrainz fails to parse metadata after recent MusicBrainz API update" [High,In progress] https://launchpad.net/bugs/1005075 [06:34] the fix was in the 4.0.3 release, but it depended on other stuff from the earlier bugfix snapshots [06:34] so little reason to backport [06:35] Hurray for web APIs [06:35] yeah [06:40] Race of the jobqueues: will libmusicbrainz get a launchpad diff before alioth has processed my SSH key? [06:41] I'm afraid the diff looks scarier than it actually is [06:41] since the package has the api docs in it too [06:43] most of it is in schema & tests [06:43] actual source changes aren't that huge :) [06:47] RAOF: ^^ [06:47] Ack. [07:00] tjaalton: You don't happen to know if any rdepends will FTBFS if they use deprecated functions? [07:01] RAOF: the only one is sound-juicer, I'll try to rebuild it [07:01] all others still use libmb3 [07:06] tjaalton: Also, how sure are you this doesn't break ABI? [07:06] RAOF: I take upstream's word for it :) [07:06] sound-juicer built fine [07:07] * RAOF is not going to take upstream's word that they've managed to somehow not break their C++ ABI ☺ [07:08] Especially since they've added fields to classes and changed some signatures. [07:08] ok, if you can add a comment there and I'll ask andy to reply [07:09] would that suffice? [07:09] I'd prefer diffing the set of exported symbols, but I'm not sure what tools we have to ensure C++ ABI. [07:14] me neither [07:16] Commented. [07:18] thanks [08:36] slangasek: will have to do it tomorrow. I didn't see your message until just now. [08:36] RAOF: andy replied, so looks like it is safe abi wise [08:37] ev: well I didn't forget my NERF gun, so watch out ;-) [08:37] hahaha [08:42] hmm, no images and no build failure mails is worrying === yofel_ is now known as yofel [09:36] ogra_: No images and no failures usually means things are still building. [09:37] ogra_: (Which seems likely, given the number of BuildLiveCDs I see) [09:37] Poor celbalrai. [09:38] =) [09:38] Yeah, [09:38] Also, I'm not seeing --f ext4 on those precise builds. [09:39] I suspect the if [ "$IMAGE_TYPE" = "daily-preinstalled" ]; bit isn't doing what it was meant to. [09:40] infinity, we only have one preinstalled image left [09:41] ogra_: Not in precise. [09:41] well, apart from server [09:41] oh [09:41] right [09:41] Methinks you broke that. [09:42] did i ? [09:43] Well, I see 3 precise builds going, and none of them has -f ext4 [09:43] oh, i might actually [09:43] well, the server building in quantal, not the precise builds [09:46] Actually, how is that broken? [09:46] * infinity scratches his head. [09:47] Those are buildlive daily-live processes. [09:47] Not daily-preinstalled. [09:47] server ? [09:47] there should be a server preinstalled build [09:47] which my recent changes to etc/default-arches accidentially disable [09:47] Not server. [09:48] * daily-preinstalled maverick-precise armel+omap armel+omap4 [09:48] that should cover it [09:48] mx5, omap4, omap currently. All precise/ubuntu. [09:49] We shouldn't even have precise armhf builds at all, according to crontab. [09:50] Well, we wouldn't, if they weren't being triggered as daily-live jobs. [09:50] looking at etc/default-arches i dont see how thats possible [09:53] cdimage@nusakan:~/cdimage$ bin/default-arches ubuntu daily-live precise [09:53] amd64 amd64+mac i386 powerpc [09:53] Certainly seems to DTRT. So, WTF triggered all those builds? [09:55] The timing of them matches with the precise daily-live cronjob. [09:55] Bother. [09:56] well, the quantal buildlive run is only 1h earlier [09:56] are yousure it is not that one ? [09:56] I'm sure. [09:56] weird [09:56] The quantal one also spawned a BuildLiveCD. [09:56] Which is, y'know, quantal. [09:57] And an hour earlier. :P [09:57] yeah yeah [09:58] Meh, I should be sleeping, not trying to reason at 4am. [11:05] apw, ping [11:07] cjwatson, apw, I can not find amd64 and i386 desktop images in cdimage.u.c. Any idea why and where they are? :) [11:08] psivaa, for which release [11:08] apw,sorry for quantal [11:09] apw, http://cdimage.ubuntu.com/daily-live/current/ [11:09] He's not wrong, they seem to have walked away. [11:10] psivaa, indeed they seem to be missing, i assume they failed to build last night [11:10] If they failed to build, it would copy the images from the previous day. [11:10] This is something more insidious. [11:10] apw, ack, but i would have thought in that case the latest successful image be present there [11:13] Normally it is. [11:13] I think it's just been failing for long enough that they got expired. [11:14] apw, infinity, cjwatson ack and thanks :) [11:14] And yet the livefs build here was fine. [11:14] It's not just livefs. [11:14] The whole world is missing x86. [11:15] server/daily, for instance. [11:15] Ah, I see [11:15] But thank god we have powerpc builds of everything. We're saved. [11:15] no entry data.tar.gz in archive [11:15] debian-cd isn't too clever [11:16] Trying to unpack a goofy .deb? [11:16] data.tar.xz [11:16] Or, rath... Yeah. [11:16] grub? [11:16] Probably syslinux. [11:16] (or some other bootloa..) [11:16] * cjwatson goes to attempt to modernise that code. [11:17] * infinity tries once more to nap. [11:22] Should be fixed. Trying an updated build now. === doko__ is now known as doko [15:11] ev: ok ;) [16:00] could someone let libzapojit through the new queue? it's needed for gnome-documents [16:04] cjwatson: the smoke testing failed on the new build, not sure why, though [16:04] cjwatson: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-amd64_default/71/console [16:04] cjwatson: that'd be 20120703.1 [16:16] it seems it tries to quit smoking [16:16] so many broken pipes [16:17] Having trouble making sense of that :) [16:17] Does it fail manually? [16:17] stdout not available somehow ? [16:17] cjwatson: it does, look at bug 1020574 [16:17] Launchpad bug 1020574 in ubiquity "installing ubuntu on virtualbox" [Critical,Confirmed] https://launchpad.net/bugs/1020574 [16:17] OK, approaching end of day but I'll see if I can have a quick look [16:17] cjwatson: haven't tried HW, though [16:19] cjwatson: I don't blame you for not being able to make sense of that log, I have trouble as well, there are more logs that may be interesting on jenkins , though [16:19] cjwatson: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/55/artifact/55/test-results/ [16:21] Might as well reproduce locally [16:21] cjwatson: plugininstall.py seems to give a systemerror [16:21] cjwatson: 32: Broken pipe [16:21] Yeah, I can see that [16:21] haha, I am glad I am looking in the right place :D [16:22] But as ogra_ suggests that implies some file descriptor or other going away but is very very unspecific [16:23] and it could be anywhere down the chain [16:23] My guess would be an apt/python-apt regression from the uploads on 2012-06-29, but it will need disentangling [17:31] jbicha: Out of curiosity, do you do a large number of manual syncs to pad the numbers, or because you can't wait for the autosyncs? :) [17:53] infinity: most of my syncs weren't autosyncable because they had Ubuntu changes [17:54] jbicha: Ahh. There just seems to be a lot of them. ;) [17:55] infinity, hey! [17:55] infinity, will you do a round of SRU reviews today since you were off yesterday? ;-) [17:55] yeah, I grabbed the easier ones, there won't be near as many for a while [17:55] seb128: I might do a few. What's on your hitlist? [17:57] infinity, gwibber, apport (follow up for the current version which is failing verification), software-center and ubuntu-sso-client (they fix some of the top reported issues on errors.ubuntu.com), ubuntuone-client [17:57] infinity, check with bdmurray maybe before doing review, I tried to nudge him about some of those as well earlier ;-) [17:57] bdmurray: ^ === Ursinha is now known as Ursinha-lunch [18:00] seb128: software center has a couple of bugs not fixed in quantal afaict see #ubuntu-devel [18:00] can we stop being religious about those? [18:00] I'm sure mvo will do an upload to quantal soon enough with the fixes in the Vcs [18:01] oh I see the bugs do have upstream branches attached [18:03] doh, one day I will stop doing ctrl-R on xchat text entry [18:04] heh [18:27] Hrm. sru-accept's '-s' switch doesn't seem to work as advertised. [18:27] How so? [18:27] Erm. [18:27] Nevermind. [18:27] Brain and eyes disagreeing. [18:28] OK :) [18:28] I want -p PACKAGE, but I'm so used to -s/S being for SOURCEPKG. [18:28] La la la. [18:28] Ah, yeah. Let's use long options for everything. :-P [18:30] Entertainingly, this give me a URL of ubuntu/+source/None/1.2.3-1 [18:30] SMRT. [18:31] infinity: I fixed the none url thing what revno are you on? [18:31] bdmurray: The current. [18:31] bdmurray: Oh. [18:31] bdmurray: Current NOW, wasn't on the first accept. :P [18:31] infinity: ah ha [18:32] bdmurray: What will it do if I call it without -p now? :) [18:32] infinity: not give a url for the build [18:32] Ahh. [18:33] So, given that we only expect sru-accept to be called by people with queue privs (right?), can we not make it actually do the accepting too? Which would then let us just feed series/packagename, and not have to specify version, cause it can yank it from the queue, and do the accept? [18:34] (This also would make it feel more in line with sru-release) [18:35] infinity: accepting my packages before I've even written the proper SRU blurbs? :) [18:35] slangasek: Quick, what's the regression potential? [18:35] slangasek: OH GOD, HOW DO I TEST?! [18:35] infinity: see bug description for the answer [18:35] slangasek: I think we're covered. [18:37] slangasek: On the other hand, testing this could be a problem. [18:37] 1) go back in time; start mysqld [18:37] slangasek: Unless you set up a fake stratum-1 server as your upstream and set your clocks back. [18:37] alternatively, 1) fake a leap second, yeah [18:38] Though, in one of the lkml threads, there was a quick PoC for faking the leap second, I think. [18:38] So, no need to involve ntp. [18:38] Assuming you consider the synthetic test to be equivalent. [18:38] ah, can you lay your hands on the relevant mail and stick a pointer in the bug description? [18:39] I do consider the synthetic test equivalent, provided it triggers the futex-spinning issue in the first place [18:39] Should do. Let me see if I can dig it up. It was attached to the new-and-improved kernel patch. [18:41] * slangasek hehs, noticing that the one machine he has mysqld running on doesn't seem to be affected... except mythbackend [18:42] https://lkml.org/lkml/2012/7/3/37 [18:42] * infinity slaps that in the bug. [18:43] ta [18:43] It's under your Test Case bit now. [18:44] "Dear Mr. Graber, During the night of 30.06.2012 to 01.07.2012 our internal monitoring systems registered an increase in the level of IT power usage by approximately one megawatt. The reason for this huge surge is the additional switched leap second which can lead to permanent CPU load on Linux servers." <- is what I got this morning from my DC hosting provider :) [18:45] stgraber: Nice. [18:45] * slangasek raises an eyebrow [18:45] stgraber: herzner? [18:45] presumably that's not a 1MW increase in your personal power usage :) [18:46] Given that we've already been down this road a few years ago, this seems like a bit of egg-on-face situation for Linux in general. [18:46] RedHat having to amend their "we fixed it" announcements with "no, really, we mean it this time" is fun. [18:46] elmo: yeah [18:48] stgraber: http://imgur.com/a/ykoup/noscript <-- pics because it happened [18:48] well, the architecture of how we're handling leap seconds on Linux is fundamentally wrong... the kernel and filesystems should be keeping time with a monotonically incrementing time_t, and it should be glibc's problem to fix up the display :P [18:48] wait what [18:48] *all* the problems we have with leap seconds are a result of this architecture bug [18:49] that's not really an increase of a megawatt then? it just went over a megawatt? [18:49] elmo: That graph was a lot more impressive before I realise it wasn't based at 0. [18:49] * highvoltage is dissapointed [18:49] slangasek: To be fair, we do what POSIX tells us to do WRT time_t. [18:49] slangasek: Not that that's necessarily right. [18:50] we disobey posix, quite happily, elsewhere [18:50] infinity: which part of POSIX? [18:50] slangasek: I do appreciate the Google solution to the problem, though. I wonder if they've upstreamed that and I can toggle it in my ntp.conf. [18:50] tumbleweed: not really [18:50] not in such a fundamental way, sure [18:51] infinity: do the accepting - I'll do that once I've got a bit more of my queue API work landed [18:51] tumbleweed: the kernel adheres quite closely to POSIX, and so does glibc [18:51] awesome, just have aptitude SIGSEGV on me :) [18:51] * micahg taps foot for fix for ntp issue :)... [18:51] slangasek: If I recall, the POSIX definition of "seconds since the epoch" doesn't actually match with real seconds (ie: doesn't account for leap seconds), but is rather just a function of number of days since the epoch, times 86400. [18:52] infinity: ah, cute [18:52] so yeah, can we fix POSIX kthx [18:54] infinity: which should actually be in a couple of days [18:54] * infinity crosses his eyes trying to double-check the version comparison of "5.0.0ubuntu20.10.04.6". [18:55] BTW, I don't think it's related to mysql/java processes, I seem have crashes all over the place (thunderbird, firefox, aptitude) [18:55] s/related/limited to/ [18:55] micahg: Oh, it's not directly related to either. [18:55] bdmurray: how does bug #1020529 fit as a dupe of bug #887892? [18:55] Launchpad bug 1020529 in udev "package udev 173-0ubuntu4.2 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1 (dup-of: 887892)" [Undecided,New] https://launchpad.net/bugs/1020529 [18:55] Launchpad bug 887892 in udev "lucid->oneiric upgrades fail udev upgrade: unrecognized option '--convert-db'" [High,Fix released] https://launchpad.net/bugs/887892 [18:55] micahg: It's just that some things tickle the bug more reliably than others. :P [18:55] bdmurray: is that maybe a typoed bug #? [18:56] * micahg manually grabs base-files to hopefully end this nightmare [18:56] bdmurray: (bug #937196 seems more likely) [18:56] Launchpad bug 937196 in apt "10.04 LTS -> 12.04 upgrade failed: ifupdown depends on upstart and initscripts but they are not configured" [High,Confirmed] https://launchpad.net/bugs/937196 [18:57] slangasek: That same output is in the term log for the first bug. [18:57] slangasek: there is a pattern for unrecognized option '--convert-db' [18:58] micahg: Have you been intentionally letting it spin until we pushed out a fix? [18:58] infinity: sort of :) [18:58] micahg: If so, thanks for being a guinea pig? [18:59] bdmurray: ah, ok - I had only looked at VarLogDistupgradeTermlog [18:59] * infinity fixed all his systems when he first noticed it. [19:00] Though, while all the servers I admin had the issue, the hilarious bit is that I noticed it first on my laptop. Because it was burning my knee. [19:00] * slangasek wonders why VarLogDistupgradeTermlog and VarLogDistupgradeApttermlog are even separate files [19:00] True story. [19:01] I don't know, I just wish I could consistently click on them and have them always do the same thing. [19:02] for some reason my laptop was the only system I admin not to be affected, my current guess is that the ifupdown ntpdate hook triggered soon after the leap second was added, updating the system time properly [19:02] Some zipped, some not, open in browser, open file-roller, hurts my brain. [19:02] stgraber: Or your laptop doesn't run ntp? [19:03] stgraber: Most don't. [19:03] (why mine does was examined shortly after the bug hit me, and ntp is now uninstalled) [19:04] a computer without ntp? heresy [19:04] slangasek: I stopped to think about just how useful ntp probably isn't on a machine that spends ~50% of the day suspended, and.. Well. Yeah. [19:04] Bye, ntpd. [19:05] infinity: oh, I thought I had ntp running on that one too but apparently not, that explains it then [19:05] infinity: but then how will the system know what time it is when it wakes up! [19:06] slangasek: ntpdate? Also, batteries? ;) [19:06] might have ntpd back on there soon though as I'm moving back to using kerberos (well, samba4) for authentication and well, kerberos is still picky about time... [19:06] slangasek: ntpdate gets me close enough, I'm sure, and if the all-magical HPET timer is so crap that it can't keep consistent time over the 2 or 3 hours between naps, I think this machine has bigger problems. [19:07] stgraber: Yeah, krb's a sticking point. I don't use it internally. [19:07] yes, kerberos is meant to be used topically [19:07] So, for me, consistent time on my laptop is just about time not going backward, and generally going forward at a sane rate. The hardware can handle that. [19:07] (I hope) [19:08] infinity: is your laptop using UTC then? (otherwise the going backward part might still happen ;)) [19:08] stgraber: It's UTC at the hardware level, like any sane UNIX machine. [19:09] stgraber: Timezones are purely for display purposes. Unless you're DOS. [19:09] see above re: monotonic clocks :P [19:10] slangasek: Yeah. There was a good write-up somewhere about your complaint. Maybe I'll find it again later. [19:10] infinity: right, DST isn't messing with the system time, just with everything else :) [19:11] slangasek: We even *have* the right timezone sets (though we don't use them) for adding the :60 second instead of repeating :59, but it's due to the internally inconsistent POSIX "hey, what exactly is time_t anyway?" issues that we don't. [19:11] grmble [19:11] so [19:11] seriously [19:11] how do we get POSIX fixed? [19:11] Time machine. [19:11] Except, then you'll go into an infinite loop. [19:12] *rimshot* [19:12] :P [19:12] cjwatson: efilinux uploaded [19:12] * infinity runs to the store to caffeinate. [19:26] seb128, bdmurray: right, let me double check the state of quantal, but its either in bzr or already in quantal and maybe the bug did not get closed for some reason :/ [19:32] mvo: being in bzr was good enough for me this time [19:32] mvo, hey, thanks ... aptdaemon SRU testing, did you find anyone? Sorry to be nagging about it but it's in proposed for 19 days [19:33] stgraber: I just got a conffile prompt from netbase about /etc/services... In an sbuild chroot. I have a hard time believing I modified it by hand. [19:34] infinity: hmm, I didn't get that on my test upgrades, any chance you saved the delta? [19:35] stgraber: It was in an overlay, so yeah, the original state is still around. [19:35] stgraber: I'll poke you with details once I'm done doing what I was actually doing. [19:35] ok [19:36] seb128: I know, gary is on vac right now and I didn't find time yet, I will try again tomorrow [19:36] seb128: and no worries, its not naging, its important :) [19:36] mvo, thanks [19:36] * mvo hugs seb128 [19:36] * seb128 hugs mvo back [19:36] bdmurray: thanks a lot [19:41] infinity: schroot itself has an annoying tendency to overwrite /etc/services as part of the chroot setup [19:41] it does /etc/services, /etc/protocols, and a few other things [19:41] slangasek: Oh, that seems silly. [19:41] yes, I agree [19:41] I've taken to just blindly hammering the enter key when they come up [19:41] feel free to respond more productively than I have, by filing a bug or something :) [19:42] Well, for sbuild builds, it just skips the conffile prompt anyway. [19:42] But why it's replacing it at all is a mystery. [19:42] nss something something [19:43] /etc/schroot/default/nssdatabases [19:43] honestly, why would anyone think there are relevant differences in /etc/protocols between host and guest [19:44] Or services, in 99% of cases. [19:44] And, yet, it doesn't copy nsswitch.conf [19:44] Which one would think might be more useful. [19:44] * infinity shrugs. [19:44] * infinity just edits that file and moves on with life. [19:44] except that nsswitch.conf requires additional package installations [19:45] so copying that would be even MORE insane [19:45] slangasek: Perhaps, yes. :) [19:45] Well, copying it by default would be insane. [19:45] Perfectly sane to have a commented-out suggestion in there. [19:45] "If you use nss-db to keep the base system and chroots in sync, install it in your chroots, and uncomment the following mess" [19:46] Or something. [19:46] Anyhow. I don't do that anymore. [20:12] Daviey: glance SRU has been pending verification for 20 days; is anyone responsible for validating these fixes? (bugs #981332, #983829, #980872) [20:12] Launchpad bug 981332 in glance "Content-Length and Transfer-Encoding are mutually exclusive HTTP headers" [Undecided,In progress] https://launchpad.net/bugs/981332 [20:12] Launchpad bug 983829 in glance "[sru] notify_kombu incorrect message format for logging" [Undecided,In progress] https://launchpad.net/bugs/983829 [20:12] Launchpad bug 980872 in glance "[sru] 'unhashable type' when sending notifications via Qpid" [Undecided,In progress] https://launchpad.net/bugs/980872 [20:15] Daviey: similar situation for keystone (bugs #959294, #998137) [20:15] Launchpad bug 959294 in keystone "[SRU] Can't delete users" [Undecided,Fix committed] https://launchpad.net/bugs/959294 [20:15] Launchpad bug 998137 in keystone "[SRU] Keystone user tenant membership not always removed" [Undecided,Fix committed] https://launchpad.net/bugs/998137 [20:16] slangasek: Yes.. we waited for all of the openstack sru's to get accepted before pursing it. Then, because nova had a pending security update, that was made the priority [20:16] hmm, ok [20:16] We wanted to make sure the process was sound, and will target the rest this week [20:16] ok cool [20:16] nova was undoubtedly the hardest, so these should be easier [20:17] anyone want to smoke test the libreoffice SRU on armhf? [20:17] (bug #919659) [20:17] Launchpad bug 919659 in libreoffice "SRU LibreOffice 3.5.4 for precise (was: Can't open/save document or spreadsheet with password, when mozilla profile has an absolute path)" [High,Fix committed] https://launchpad.net/bugs/919659 [20:35] * slangasek squints. why am I getting a wrong (sbin-less) path in my schroots all of a sudden? [20:37] slangasek: bug #984390 ? [20:37] Launchpad bug 984390 in shadow "$PATH is taken from login.defs not /etc/environment" [Medium,Triaged] https://launchpad.net/bugs/984390 [20:38] infinity: how is shadow at all involved in running of schroot? [20:38] slangasek: Does it not su to your user? [20:38] (Or some equivalent) [20:38] infinity: this worked before the latest schroot upgrade [20:39] so whatever it's doing, it's doing something new and argh [20:39] Oh. Hrm. See, I'd never noticed one way or the other. [20:39] slangasek: And, wait. Which schroot upgrade? [20:39] looks like schroot calls setuid directly [20:39] infinity: the one on 29Jun [20:40] I'm /assuming/ it's the schroot update that was to blame [20:40] slangasek: In quantal? I'm running precise's schroot and have no sbin in my path when I schroot. [20:40] really? [20:40] Really. [20:40] I'm sure I always had it [20:40] I would've noticed this long before now if I didn't [20:40] (base)adconrad@cthulhu:~$ echo $PATH [20:40] /home/adconrad/build/ubuntu-archive-tools:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games [20:40] (base)adconrad@cthulhu:~$ schroot [20:40] (quantal-amd64)adconrad@cthulhu:~$ echo $PATH [20:40] /home/adconrad/build/ubuntu-archive-tools:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games [20:40] yeah, and what's that lightdm junk in there, too :P [20:41] You may have been setting it explicitly in your .bashrc before? [20:41] no [20:41] (Which is why my schroot PATH helpfully has ubuntu-archive-tools in it, but no sbin...) [20:42] still WFM [20:42] (quantal-amd64)root@raleigh:/srv/home/laney# echo $PATH [20:42] /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 [20:42] I actually am appending a few things to my path in .bashrc, and that part's working; but the base path is wrong and wasn't before [20:42] Laney: when doing schroot as non-root? [20:42] Laney: Non-root is the key. [20:42] oh, yes. Silly c-r. [20:43] Does NOT wfm! [20:43] Although, that X11-having path isn't the one from login.defs either. [20:43] Cause what we needed was this bug in a new flavour. [20:44] oh, har [20:44] X11, wtf [20:45] which is not in *any* file under /etc, host or guest [20:45] slangasek: I think it might be a compiled-in default for pam_env. [20:46] I'll hear no more of this calumny [20:47] I wonder if we could perhaps set PATH in a few more places, just to spice up our lives a bit. [20:49] so this path is hard-coded in schroot [20:50] Hahaha. [20:50] Well, that's not new, then. [20:50] Since it's equally broken here. [20:50] yeah, it's not [20:51] but it only started becoming an issue for me [20:51] But why doesn't even "su - adconrad" from a root schroot session DTRT? [20:51] so something else changed [20:51] I'd expect that to get the readenv=1 from pam.d/su [20:51] er, but wait, it *is* new [20:51] Oh, no, that goes back to the shadow bug. [20:51] Derp. [20:52] ah, no, just code moving around [20:52] grr [20:56]