[00:01] <TheMuso> @pilt in
[00:01] <udevbot> Error: "pilt" is not a valid command.
[00:01] <TheMuso> @pilot in
[00:39] <mwhudson> is there a guide somewhere for "how to build an ubuntu kernel with this extra patch i want to test"?
[00:39] <infinity> mwhudson: Apply patch, build package.
[00:39]  * mwhudson finds that the link to https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel was purple already
[00:40] <mwhudson> infinity: so easy
[00:40] <infinity> mwhudson: If you want a different version number and don't want to futz with ABI check ignore stuff, just change the top version in debian.master/changelog and debian/changelog instead of adding a new entry, and voila.
[00:40] <mwhudson> i guess i need to find out if the patch set i care about applies to 3.13
[00:41] <mwhudson> unless utopic has a newer kernel already i supose
[00:41] <infinity> mwhudson: utopic is 3.15
[00:41] <mwhudson> oh shiny
[00:41] <infinity> Way to keep up. ;)
[00:42] <mwhudson> is 3.16 out yet?
[00:42] <infinity> 3.15 isn't out yet...
[00:42] <mwhudson> haha
[00:42] <mwhudson> ok
[00:42] <mwhudson> but it's well into rcs?
[00:42] <infinity> Yeah, rc8.
[00:43] <mwhudson> hm i wonder if it has the patch i want already
[00:43] <mwhudson> (psci support in kvm)
[00:43] <infinity> Do you have the commit?
[00:43] <mwhudson> not to hand no
[00:43] <mwhudson> last i heard it was in kvm-next
[00:48] <mwhudson> it was queued on apr 30 http://www.spinics.net/lists/kvm-arm/msg09229.html
[00:48] <mwhudson> but doesn't seem to be in linus' tree yet
[00:48] <mwhudson> i guess it's waiting for 3.16
[01:06] <mwhudson> gruh, patch series doesn't apply
[01:06] <mwhudson> (to linus tip even)
[01:06] <mwhudson> i hope i don't have to understand this!
[02:35] <mwhudson> woop i have some hacked up kernel debs of my very own
[02:36] <TheMuso> If any SRU reviewers are around, mind having a look at bug 1308771, and its lack of a specific test case, given a language specific bug, and the difficulty in possibly finding someone to test the fix who knows the language in question?
[02:38] <TheMuso> I guess my question is would you let that fix through?
[03:59] <TheMuso> @pilot out
[07:59] <jamespage> @pilot in
[09:25] <jamespage> cjwatson, infinity: please could one of you take a look at the debdiff on https://bugs.launchpad.net/ubuntu/+source/finish-install/+bug/1320327
[09:25] <jamespage> it looks reasonable to me - but wanted someone with better knowledge of this package to review before I sponsor
[09:35] <rbasak> In a shell script wrapper, I need to get from the line: "$@" to the equivalent line inside: su -c '...' ...
[09:35] <rbasak> ie. shell quote the whole "$@" into a single thing that the shell will then interpret as normal, if that makes sense.
[09:35] <rbasak> Is there a standard way to do this?
[09:40] <cjwatson> jamespage: looking
[09:40] <cjwatson> rbasak: I'm sure it is possible but su's interface is dreadful for this.  Is there any way you can use a different tool that doesn't require requoting?
[09:41] <cjwatson> rbasak: (and doesn't involve creating a new PAM session, etc.)
[09:41] <cjwatson> rbasak: if you're just trying to switch from root to some other user in a maintainer script or something, then there's a pattern in man-db.postinst that you could use
[09:42] <cjwatson> jamespage: looks fine, matches the fix that went upstream
[09:43] <jamespage> cjwatson, indeed - thanks for the second pair of eyes!
[09:44] <rbasak> cjwatson: thanks. Are you referring to the Perl invocation in run_mandb? I can use that I think. I'm in a dep8 test, and I need to switch from root to another user, set a new HOME but maintain PWD and call another script that runs as a normal user.
[09:45] <rbasak> On a second look, I'm not sure I see the bit in man-db.postinst you mean
[09:49] <xnox> rbasak: is this not appropriate "HOME=/bar sudo -E -u user cmd --cmd-args" ? no quoting for target command, can change env variables, and preserves PWD, doesn't do login shell.
[09:49] <cjwatson> rbasak: The perl invocation, yes.
[09:50] <cjwatson> That's simpler than sudo.
[09:50] <cjwatson> And fewer things can go wrong.
[09:51] <rbasak> Re-reading the Perl guessing what $(, $), $< and $> might mean I understand it now - thanks.
[09:51] <cjwatson> I do wish we had something in coreutils or util-linux or something that *just* did user-switching (and maybe group-switching) without any of the other gubbins, for use as a primitive operation.
[09:51] <rbasak> Is there anything that won't be switched, but might be in a login shell that hit PAM?
[09:52] <rbasak> I want to test juju as a normal user here, but need the test to run as root for some setup. I'm just concerned that I'm testing exactly what a local user would get.
[09:52] <rbasak> So I was going for a login shell that then called juju, but having to change PWD made it awkward.
[09:53] <rbasak> (because PWD is where the dep8 test resources are)
[09:56] <cjwatson> 
[09:56] <xnox> reading perlvar manpage, that perl invocation is very nice. =) would be less cryptic, if expanded var names would be used e.g. $REAL_USER_ID instead of $<. I guess I didn't do any amount of perl to learn about those vars to date.
[09:57] <rbasak> xnox: I think there's a "use English;" thing (or something like that). But it's been many years since I touched Perl
[09:57] <rbasak> It would make the whole snippet quite a bit longer though
[09:58] <xnox> rbasak: as per spec, you also have $ADT_TMP which should be used. So you can e.g. change directory to $ADT_TMP and set $HOME to that location as well and run anything you like.
[09:58] <rbasak> Yeah I'd have to do some refactoring though.
[09:59] <rbasak> What I have are a couple of different wrappers, and multiple test definitions. Some use the wrappers, and some don't.
[09:59] <rbasak> So the wrappers need to find the original test files currently, and AFAICS the only way to know the location of those are with the PWD.
[10:00] <xnox> "use English;" -> reminds me of Pulp Fiction "do you speak it"
[10:00] <rbasak> So the thing that is called on the "other side" needs to be handed the directory somehow. If it's one of my tests directly, then I'll need to refactor the test to pick it up from a different environment env or something
[10:02] <rbasak> Or some kind of "sh -c 'cd /... && ...'" type thing, and that's when the quoting starts getting horrible.
[10:40] <rbasak> I've ended up doing:
[10:40] <rbasak> sudo -iu jujutest sh <<EOT
[10:40] <rbasak> cd "$PWD"
[10:40] <rbasak> $@
[10:40] <rbasak> EOT
[10:41] <rbasak> This gives me the login shell I wanted. It doesn't quote $@ properly I don't think, but in my case I don't think I need it.
[10:44] <jamespage> @pilot out
[11:10] <cjwatson> doko: Mind if I sync perl?  It has a different fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746890 than the one you applied, but apparently one preferred by upstream
[11:10] <doko> cjwatson, sure
[11:10] <cjwatson> thanks
[11:39] <mdeslaur> @pilot in
[11:59] <rbasak> mdeslaur: hi! While you're piloting, I noticed bug 1189939 in my bugmail this morning that I think needs another look, and noticed you sponsored it last time. Would you mind? Else I'm fine to look at it - I flagged it in my mail already.
[12:00] <mdeslaur> rbasak: sure, I'll handle it, thanks
[12:00] <rbasak> Thanks!
[12:26] <nectarys> How do I get the Skype status icon on the main bar of ubuntu?
[12:51] <Chipaca> nectarys: I think you want to ask in #ubuntu; this channel is more for app devs
[12:52] <Chipaca> sorry, i meant for ubuntu dev questions
[12:58] <GunnarHj> rbasak: Hi Robie
[13:02] <rbasak> GunnarHj: pong. Sorry I haven't had a chance to look yet - I did see that you updated the bug.
[13:03] <GunnarHj> rbasak: Ok, I just wanted to make sure that you saw it. Please take your time.
[14:00] <caribou> Q: with a list of packages & versions, which would be the most effective (and network inexpensive) way to confirm that all those package/version tuple are on official archives ?
[14:00] <caribou> for a given release
[14:01] <caribou> I mean, I could do apt-cache on the package & compare versions, but there might be a more cost effective way of doing this
[14:01] <caribou> my goal is to identify packages that would not be part of our official archives
[14:02] <cjwatson> rmadison
[14:03] <cjwatson> or "apt-cache policy" to check the candidate URL
[14:04] <caribou> cjwatson: I'm talking about a list of more then 1000 packages, so rmadison on each one of them would be radical
[14:04] <caribou> maybe there is no way of doing it without querying the remote archive
[14:05] <caribou> just for a bit of context, I'm investigating a problem on a system & just found out that one of the libraries doesn't come from one of our archives
[14:05] <cjwatson> well I gave two answers so you could try the other one :)
[14:05] <cjwatson> (also fwiw rmadison can take multiple packages in one go)
[14:06] <cjwatson> (you'd have to write a script to correlate/compare the output though)
[14:07] <cjwatson> apt-cache policy is probably better though in that it will introduce less confusion with out-of-date packages and the like
[14:07] <caribou> cjwatson: ok, I'll check that one out
[14:07] <caribou> cjwatson: thanks
[14:08] <rbasak> caribou: I would download the packages files and process them with grep-dctrl, sort, uniq, comm, etc.
[14:09] <caribou> rbasak: I had that in mind too; my problem will be to deal with various versions of the same package
[14:09] <rbasak> Hmm.
[14:10] <rbasak> Maybe apt-cache policy like Colin says then? chdist is useful to do that on multiple releases at once.
[14:10] <rbasak> And some xargs-fu to speed it up.
[14:11] <rbasak> I'm wondered about some tooling around this kind of task before. Two jobs ago I had a Postgres db with a debian version number comparison function I wrote
[14:11] <caribou> rbasak: hmm, chdist is interesting
[14:11] <rbasak> Then SQL provides a more powerful query language to that.
[14:12] <cjwatson> tbl-dctrl + join is worth considering too, by way of poor man's SQL
[14:13] <caribou> rbasak: my idea is to have some tools to process the output of sosreport & identify potential problems
[14:13] <caribou> rbasak: that's the big picture
[14:16] <rbasak> Oooh. I didn't know about tbl-dctrl. Thanks!
[14:22] <mvo> caribou: python-apt should be up for the task as well, it sounds pretty straightforward (sorry for being a bit late to the reply-party :)
[14:22] <caribou> mvo: that would be even better !
[14:24] <mvo> caribou: so you have a given release (say trusty) and want to feed it a list of (pkgname, ver) and see if that is a version that is in the archive?
[14:24] <caribou> mvo: exactly
[14:25] <caribou> mvo: but the ver value may not be the latest version available in the archive, but one that was officially published
[14:26] <cjwatson> xnox: Could you merge emacs24, please?  It needs to be rebuilt for libgnutls-deb0-28 anyway, I have somewhat limited internet here so it'd be nice to avoid downloading its .orig.tar.bz2, and I see that the latest Debian upload fixes several security issues
[14:43] <cjwatson> xnox: (I've uploaded all the rest of the libgnutls-deb0-28 transition BTW; guess we'll see whether it all builds)
[14:44] <mvo> caribou: http://paste.ubuntu.com/7602161/ - a very quick sketch what I have in mind, run: "printf '2vcard 0.5-3\napt 1.0'" | python checker.py" for a quick demo you certainly want to improve plus the fallback to changelogs.u.c
[14:47] <caribou> mvo: thank you so much! that will get me started !
[14:55] <mvo> caribou: your welcome, let me know in what way you get the data and I can look at the changelogs.u.c stuff too
[15:36] <mdeslaur> @pilot out
[17:01] <rbasak> infinity, jamespage: so I uploaded juju-core 1.18.4, which FTBFS on powerpc. But it hasn't changed much since Trusty in theory, and I can't reproduce on our porters.
[17:01] <rbasak> Any hints?
[17:01] <rbasak> Could this be a toolchain regression of some sort?
[17:01] <rbasak> https://launchpad.net/ubuntu/+source/juju-core/1.18.4-0ubuntu1/+build/6076908
[17:01] <rbasak> I have retried once.
[17:03] <rbasak> I guess I'll worry about it on Monday
[17:03]  * rbasak EODs
[17:03] <infinity> rbasak: You can't reproduce on an up-to-date porter chroot?  That's a bit suspect.
[17:03] <infinity> rbasak: That might point to gccgo doing something POWER7-specific that sulfur can't deal with.
[17:03]  * infinity gives it a retry on sagari to see.
[17:04] <rbasak> Thanks
[17:04] <rbasak> Oh one catch. I didn't think to dist-upgrade the porter.
[17:04]  * rbasak does that now
[17:07] <rbasak> It succeeded on the porter again. I didn't see the dist-upgrade pull in anything relevant anyway. Some perl and python.
[17:07] <rbasak> Failed on sagari
[21:08] <rcj> When marking verification as failed for an SRU and pushing a new change for sponsorship, do I need to rev the version or can it stay the same?
[21:11] <ScottK>  rcj: if it was in proposed you need to bump the version.
[21:12] <rcj> ScottK, thanks, that's exactly what I needed to know.