=== Guest72010 is now known as balloons
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[07:17] <pitti> Good morning
[07:27] <elfy> pitti: you staying long enough for a good morning :p
[07:28] <pitti> elfy: heh; sorry, saw a kswapd complaint on my server this morning, so I had to reboot it (sigh, 200 days uptime gone :) )
[07:28] <elfy> :)
[07:28] <pitti> and then the fsck kicked in, so it took a while
[07:28] <elfy> ha ha ha
[08:38] <pitti> rbasak: wrt. bug 1266811, I want to take a look at this now; but I'm still stunned how you can run lxc as user on system-wide images
[08:38] <ubot5> bug 1266811 in autopkgtest (Ubuntu) "--unbuilt-tree fails with adt-virt-lxc" [Undecided,New] https://launchpad.net/bugs/1266811
[08:38] <pitti> rbasak: do you have some ~/.lxcwhatever that defines lxc.lxcpath to the system one (/var/lib/lxc) or something?
[08:41] <pitti> rbasak: and adt-virt-lxc doesn't allow me to specify a -P option to propagate to lxc-start
[08:56] <jibel> pitti, you can specify lxcpath in ~/.config/lxc.conf
[08:56] <jibel> actually ~/.config/lxc/lxc.conf
[09:00] <pitti> I haven't yet tried per-user containers, that seems to be something new in trusty
[09:00] <pitti> but I didn't have the impression that rbasak was even using them
[09:03] <rbasak> pitti: I'm not doing anything special. On a fresh VM, apt-get install lxc. Then use sudo for everything. That's all.
[09:03] <rbasak> Unless something changed I didn't notice, that still works. The only thing I had to do for adt-virt-lxc is "chmod 755 /var/lib/lxc" recently in Trusty since that changed.
[09:04] <pitti> rbasak: right, but if you run "lxc-start" as user (not root), then it wants to use containers in ~, not in /var/lib/lxc/
[09:04] <rbasak> pitti: I use sudo for everything lxc. Including lxc-start. adt-virt-lxc does this too.
[09:04] <pitti> rbasak: right, I asked stgraber about the permissions, he said it was deliberate for security reasons
[09:04] <pitti> rbasak: you don't in e. g. bug 1266811
[09:04] <ubot5> bug 1266811 in autopkgtest (Ubuntu) "--unbuilt-tree fails with adt-virt-lxc" [Undecided,New] https://launchpad.net/bugs/1266811
[09:05] <rbasak> When I wrote adt-virt-lxc, I understood lxc to not handle not running as root yet, but that it would in the future.
[09:05] <pitti> rbasak: and last week you said something about using "--gain-root=sudo" to run adt-itself as user
[09:05] <rbasak> So I had it run sudo for everything, thinking that we could just drop that later.
[09:05] <pitti> rbasak: ok, then I apparently misunderstood that then
[09:05] <rbasak> --gain-root=sudo is something completely different.
[09:05] <rbasak> It's about what's happening *inside* the container.
[09:05] <rbasak> The other bits are about outside the container, in the host.
[09:05] <pitti> rbasak: ok, thanks
[09:06] <rbasak> bug 1266811 is I think an issue inside the container, so I don't think it has anything to do with whether lxc runs as root or not.
[09:06] <ubot5> bug 1266811 in autopkgtest (Ubuntu) "--unbuilt-tree fails with adt-virt-lxc" [Undecided,New] https://launchpad.net/bugs/1266811
[09:07] <rbasak> My steps to reproduce bug 1266811 should work in a fresh VM.
[09:07] <rbasak> With no other settings.
[09:07] <pitti> rbasak: ack, I'll try and reproduce it; I was just still wondering about how you run adt-run as user
[09:07] <pitti> this actually ought to work in trusty somehow now (I didn't play around with per-user containers yet)
[09:07] <rbasak> Yeah. Perhaps the sudo can be dropped from inside adt-virt-lxc now.
[09:08] <rbasak> (but --gain-root=sudo would still remain for the guest)
[09:08] <davmor2> Morning all
[09:10] <elfy> good morning davmor2
=== vrruiz_ is now known as rvr
[09:39] <pitti> rbasak: hm, I tried with various different combinations now, and it always works (i. e. all combinations except the "run adt-run as user" that you have in the report, and it might be that this is the crucial difference)
[09:39] <pitti> rbasak: do you still get this with current apache2 and autopkgtest?
[09:39] <pitti> rbasak: also, why the "(cd apache-2.4.6 && quilt push -a)"? pull-lp-source unpacks the source and applies the quilt patches, as dpkg-source does that
[09:41]  * pitti tries with an older autopkgtest
[09:55] <slickymaster> morning all
[10:03] <rbasak> Trying now
[10:14] <rbasak> pitti: re: quilt, you're right. In my actual problem case I had popped the patches, and so needed to push them back. The reduced test case doesn't need it. Also, there was a minor typo in reproduction steps (apache -> apache2). I've amended these.
[10:14] <pitti> rbasak: yeah, I figured out the apache[2] thing, that was quite obvious
[10:14] <rbasak> pitti: I've also found a bug in the code that calls lxc-info - it should be called with sudo, like everything else, to be consistent with the other lxc calls
[10:15] <pitti> rbasak: ah, that would do the trick for running adt-run as user
[10:15] <rbasak> pitti: with that change, it seems that adt-virt-lxc works again in the way I use it (with the chmod 755 workaround in the bug description too)
[10:15] <rbasak> Trying to reproduce now.
[10:16] <rbasak> (waiting for apache2 build)
[10:16] <pitti> rbasak: you mean lxc-config; indeed, I'll fix that
[10:16] <rbasak> Ah, yes. Thanks!
[10:17] <pitti> hardcoding sudo there is quite a bummer (won't work for Debian at all), but for now it's fairly Ubuntu specific anyway
[10:17] <rbasak> Yeah all of the sudo lxc calls are bad. The next time I can sit down to properly work on this, I hope to understand the non-root lxc stuff, and get rid of all of them.
[10:18] <pitti> yay adt-run as user, much nicer
[10:18] <pitti> (but FWIW, apache2 still works; at least way past the point of failure that you had)
[10:19] <pitti> rbasak: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=d18bc1
[10:20] <pitti> rbasak: sorry about breaking that
[10:20] <rbasak> No problem. Looks good - thanks.
[10:20] <rbasak> I failed to reproduce the original problem on 2.6. Trying 2.5.5 now.
[10:23] <pitti> rbasak: likely got fixed with http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=95524d85298
[10:23] <rbasak> That looks likely
[10:25] <pitti> oh, hang on, that was in 2.5.2 already
[10:25] <pitti> there were no tree ownership fixes since 2.5.5
[10:26] <rbasak> I can't reproduce in 2.5.5 now.
[10:27] <rbasak> I'll try 2.5.5 from scratch one more time. If I still can't do it, I'll mark the bug Invalid.
[10:27] <pitti> is it theoretically possible you had < 2.5.2 at that time?
[10:28] <rbasak> It's possible, but I can't think how, given that I noted the version when I filed the report.
[10:28] <pitti> on 2014-01-07, autopkgtest 2.5.4 was in trusty
[10:28] <rbasak> Unless I picked the version up from the wrong instance or something
[10:28] <pitti> ah no, 2.5.5; I misread +publishinghistory
[10:29] <pitti> except that 2.5.5 got terribly broken by the new base-passwd, which required http://launchpadlibrarian.net/162062420/autopkgtest_2.5.5_2.5.6.diff.gz
[10:30] <pitti> and that landed on Jan 07 (and broke pretty much eveyrthing in autopkgtest and other places)
[10:31] <pitti> although the pastebin output doesn't support that theory
[10:39] <rbasak> pitti: got it. It reproduces if apache2-2.4.6 is 700. I guess that was the case when I did it (because of my workflow).
[10:40] <rbasak> pitti: reproduced on both 2.5.5 and 2.6. I'll amend the bug.
[10:41] <pitti> rbasak: thanks, that's it then
[10:42] <rbasak> pitti: sorry about that. Next time I'll reproduce on a fresh VM before filing.
[10:43] <pitti> rbasak: no worries; thanks for your efforts!
[10:58] <pitti> rbasak: yep, perfectly reproducible
[11:00] <pitti> rbasak: FWIW, I still don't know what the --gain-root=sudo is for; for building packages, fakeroot ought to suffice?
[11:00] <rbasak> pitti: fakeroot would be fine, except that it isn't installed in cloud images by default.
[11:01] <pitti> rbasak: right, but autopkgtest installs it when building packages
[11:01] <rbasak> pitti: also, fakeroot shouldn't even be necessary, given that adt-run gets root in the container anyway
[11:01] <pitti> yes, but it builds packages as user (if it has a suggested user)
[11:01] <rbasak> pitti: "autopkgtest installs it when building packages" is that a newer thing? When I wrote adt-virt-lxc, I had to use --gain-root=sudo since it tried and failed to use fakeroot by default
[11:02] <pitti>         if (opts.user or
[11:02] <pitti>                 'root-on-testbed' not in testbed.caps):
[11:02] <pitti>             opts.gainroot = 'fakeroot'
[11:02] <pitti>             build_essential += ['fakeroot']
[11:02] <pitti> rbasak: let me git blame, but it's been around for fairly long
[11:03] <rbasak> pitti: "yes, but it builds packages as user (if it has a suggested user)" - it should only run "debian/rules build" as the suggested user. It should not run "debian/rules binary" with a fakerooted suggested user if it has root already.
[11:03] <pitti> rbasak: it's in 2.2.2 already, i. e. < quantal
[11:03] <pitti> (and presumably much earlier)
[11:03] <rbasak> pitti: root-on-testbed is in testbed.caps in the case of adt-virt-lxc. Not sure about the default of opts.user, but I started to need --gain-root when I added suggested-user=ubuntu.
[11:04] <pitti> rbasak: hm, it does though:
[11:04] <pitti>             opts.user_wrap(opts.gainroot + ' debian/rules binary'),
[11:05] <rbasak> pitti: yeah, but that's backwards.
[11:05] <rbasak> pitti: it's dropping root that it already has, and then tries to get it back with opts.gainroot.
[11:05] <rbasak> pitti: instead it should just use the root is has in the first place.
[11:05] <rbasak> (if it does)
[11:05] <pitti> perhaps
[11:05] <rbasak> That would bring the build closer to buildds, right?
[11:05] <pitti> but with fakechroot it's still using less privileges
[11:05] <pitti> and packages must build with that anyway
[11:06] <pitti> rbasak: I'm not sure how the buildds handle that
[11:06] <pitti> rbasak: anyway, it's a side issue, I was mostly curious why you use that option; it's unrelated to that permission bug
[11:06] <rbasak> AIUI, policy says that "debian/rules binary" *must* have root. fakeroot is a non-policy compliant hack that happens to work. That's my understanding. I could be wrong.
[11:06] <pitti> ah, perhaps; it seems to be pretty much the standard practice these days, though
[11:06] <rbasak> Yeah, it's just an aside. The short answer is that without --gain-root=sudo (or installing fakeroot in the container), adt-virt-lxc didn't work at all at the time I submitted it.
[11:07] <rbasak> It certainly is standard practice, and works well enough. But for edge case bugs, it would be nice if we could build closer to policy.
[11:08] <rbasak> If we can get uvtool working with raw stdio serial channels, then it would be great to be able to easily reproduce a precise policy-compliant environment.
=== _salem is now known as salem_
[11:10] <rbasak> pitti: incidentally, I find the manpage very confusing and ambiguous whenever I'm trying to understand what the different --built-tree, --unbuilt-tree, --source and --binary options will actually do in terms of build or no build, where the build dependencies will come from, and what test dependencies will be fulfilled and where they will come from.
[11:10] <rbasak> I'm not sure how to make that better, since I don't really understand what the options do.
[11:11] <pitti> rbasak: yeah, same with me; I was just beginning to experiment what they actually do, I'll think about how to write that in the manpage
[11:11] <rbasak> I'm sure there's some logic to it - I just haven't managed to understand.
[11:11] <pitti> rbasak: hm, it does though:1175557
[11:11] <pitti> WTF
[11:11] <pitti> I did an initial followup to bug 1175557
[11:11] <ubot5> bug 1175557 in autopkgtest (Ubuntu) "adt-run fulfills dependencies with --built-tree contrary to the manpage" [High,New] https://launchpad.net/bugs/1175557
[11:12] <pitti> sometimes pressing the middle mouse button in weechat to paste a bug number has some very weird effect
=== chihchun is now known as chihchun_afk
[12:37] <pitti> rbasak: OMGhack :( http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=e271f770
[12:37] <rbasak> pitti: ah, great. Thank you!
[12:40] <pitti> rbasak: OOI, what's insufficient about lxc-wait -s RUNNING ?
[12:40] <pitti> does that already flip to RUNNING while the early boot is still going on?
[12:40] <rbasak> Right
[12:40] <pitti> i. e. that doesn't check the runlevel?
[12:41] <rbasak> My early attempts with adt-virt-lxc were unreliable because the /tmp cleaner started work after adt-run had copied stuff to /tmp
[12:41] <rbasak> bug 1266808 if you're not looking at it already
[12:41] <ubot5> bug 1266808 in lxc (Ubuntu) "No mechanism to wait until a started container is ready and has finished booting" [Wishlist,Triaged] https://launchpad.net/bugs/1266808
[12:42] <rbasak> Also bug 1258113 is relevant here
[12:42] <ubot5> bug 1258113 in cloud-init "Cannot determine boot-finished state reliably" [Medium,Triaged] https://launchpad.net/bugs/1258113
[12:42] <rbasak> But in the case of the ubuntu-cloud lxc template, I think arranging for cloud-init to write to /dev/lxc via userdata would be fine.
[12:43] <rbasak> Or, adt-virt-lxc could be configured to be able to use either mechanism. boot-finished for cloud-init containers, and plain lxc-wait (with /dev/lxc support added) for all containers generically.
[12:43] <rbasak> That way the use case of the user overriding userdata would still work.
[12:44] <pitti> right, I was just thinking about a mechanism which doesn't depend on cloud-init/upstart/etc., so that this doesn't get limited to Ubuntu containers
[12:44] <pitti> LXC works with just about anything, and it's useful to have e. g. a Debian or Fedora container for testing
[12:44] <rbasak> /dev/lxc then
[12:44] <rbasak> The LXC template will have to arrange that
[12:44] <pitti> yes, that part is fine
[12:45] <rbasak> Actually, thinking about it, no need to use boot-finished in the LXC case at all.
[12:45] <pitti> I was wondering when to signal the "ready", whether that should look at the runlevel, or just try upstart/systemd/sysv in succession,e tc.
[12:45] <rbasak> The LXC template could arrange a /dev/lxc write outside of cloud-init
[12:45] <rbasak> I don't think a runlevel is sufficient.
[12:46] <rbasak> I think it should happen right at the end. Ie. the equivalent of /etc/rc2.d/99signal-lxc
[12:46] <rbasak> The LXC template could arrange that. upstart for Ubuntu; rc.d for Debian.
[13:52] <balloons> good morning all
[13:53] <DanChapman> good morning balloons
[14:44] <elopio> hello everybody!
[14:48] <davmor2> morning elopio
[14:49] <davmor2> belated morning balloons
[14:49] <balloons> davmor2, it's afternoon for yourself ;p
[14:50] <davmor2> balloons: it's always morning on the t'interwebz
[14:50] <balloons> just follow the sun
[14:50] <davmor2> balloons: that's what the clouds for right?
[14:50] <balloons> ¿cómo estás elopio?
[14:51] <balloons> davmor2, clouds are so UK'ers don't have to see the sun in winter
[14:51] <balloons> wretched yellow ball
[14:51] <davmor2> balloons: there was me thinking it just meant we had more storage than the rest of the world
[14:52] <balloons> well.. there might be that too..
[14:53] <elopio> balloons: pura vida. ¿vos?
[14:54] <elopio> morning davmor2.
[14:54] <elopio> hey davmor2, you are doing exploratory testing for every new phone image, right?
[14:54] <davmor2> elopio: not every but most yes
[14:55] <davmor2> elopio: currently I get a ping saying x image will hopefully be promoted please dogfood it
[14:55] <balloons> elopio, bueno. "pura vida" es interesante
[14:55] <davmor2> elopio: they are currently not promoting any so I am just testing 150
[14:55] <elopio> davmor2: that's what I was wondering :) And do they tell you what's new? or you just try it to burst into flames?
[14:57] <davmor2> elopio: we have a set of tests here https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ai33BkOcORLLdE4xLTFtSE80ZkpITXZ3aV85cWtPX2c#gid=0 that we run through on every image we test and then some random tests at the end to try and find faults
[14:59] <elopio> davmor2: got it. But, lets say we want you to do some exploratory on a specific part of the next image. Can I just ping you and tell you what's new?
[14:59] <elopio> You shouldn't explore that section every time because it will have autopilot tests. It's just a one time exploratory to catch what we and the developers couldn't catch during the reviews.
[15:00] <davmor2> elopio: what you after breaking
[15:00] <davmor2> testing I meant testing honest
[15:00] <elopio> davmor2: just thinking for now...
[15:00] <elopio> davmor2: for example, some big changes on edge gestures are coming soon.
[15:01] <elopio> some big changes on app headers
[15:01] <davmor2> elopio: yes people do, the other thing we do is test things that have been fixed to ensure they are and haven't broken anything new
[15:01] <elopio> purchasing apps from the click scope.
[15:01] <davmor2> elopio: yeah so any thing like that and can poke with a cattle prod and see what happens
[15:02] <elopio> davmor2: awesome.
[15:04] <davmor2> popey: is aware of them too so I'm sure we the maniacs will be testing when it lands anyway and maybe adding tests to the spreadsheet for things that break for future reference
[15:04] <davmor2> elopio: ^ popey is aware even
[15:08] <balloons> aways blame popey.. rule #1
[15:08] <popey> \o/
[15:10] <davmor2> balloons: you fool rule 1 of the blame popey club is you don't talk about the blame popey club
[15:10] <balloons> true
=== bfiller is now known as bfiller_afk
[19:02]  * elopio goes to real life for a while.
[19:02] <elopio> They have natural light.
[19:03] <balloons> the sunshine is a lie!
=== bfiller_afk is now known as bfiller
[20:14] <Letozaf_> balloons, hi
[20:14] <balloons> Letozaf_, hello
[20:15] <Letozaf_> balloons, saw you guys found a solution to the locales problem on calendar app
[20:15] <Letozaf_> balloons, you unset the current locale
[20:15] <balloons> Letozaf_, that was all Olivier, but yes he did :-)
[20:16] <Letozaf_> balloons, ok so I should just test the autopilot tests on my box to see if this works right ?
[20:16] <Letozaf_> balloons, all the changes I had done have no sense now
[20:17] <balloons> yea, give them a whirl on your box
[20:17] <balloons> and yes, I think he did what we wanted/tried to do in a simpler way, lol
[20:17] <Letozaf_> balloons, :D yes
[21:14] <elopio> balloons: it's real! http://i.huffpost.com/gen/1568770/original.jpg
[21:14] <elopio> I could feel the heat when getting closer.
[21:14] <balloons> elopio, ;-)
[21:14] <balloons> Suddenly living at a lower latitude isn't so bad is it?
=== salem_ is now known as _salem