[04:44] <tzero> http://askubuntu.com/questions/3446/how-to-create-and-administer-multi-architecture-ppas <- is this still relevant for releasing a PPA package with multiple distribution support?
[05:27] <cpaelzer> good morning
[05:29] <rbasak> o/
[05:29] <rbasak> Happy New Year!
[05:29] <Unit193> Happy new ears, rbasak!
[05:49] <rbasak> Unit193: sorry, can you speak up? :-)
[05:51] <cpaelzer> happy eraly bird year rbasak
[07:01] <pitti> Good morning, and happy new year!
[07:02] <cpaelzer> hi pitti, a happy new year to you as well
[07:03] <pitti> hey cpaelzer, wie gehts? gut reingerutscht?
[07:08] <cpaelzer> pitti: jepp, alles im Lot - heute is mail/bug prozesstag um zu erfassen was überhaupt los ist
[07:10] <pitti> amen :)
[07:47] <rbasak> cpaelzer: somehow I managed to catch up already! I guess it's different from vacation at any other time because everyone else was off as well.
[07:47] <rbasak> squid3 merge next I think. But sleep first.
[08:56] <Mirv> doko: could bug #1653529 (armhf only, multiple definition of `__bss_start' etc on linking) be a gcc problem? no such problem on Debian on same package when it compiled two weeks ago.
[08:58] <Mirv> I see gcc-6 6.3.0 as a recent upload so that leads me to thinking that
[11:12] <caribou> Is there a rationale behind allowing both Full disk encryption together with /home + swap encryption at the same time ?
[11:13] <caribou> I mean, shoudn't /home + swap encryption be disabled if full disk encryption was previously selected during installation ?
[11:14] <rbasak> I don't know of any rationale (before my time), but there are some functional differences. With FDE with ecryptfs, your home directory is locked when you're not logged in, for example.
[11:14] <rbasak> You'd lose that with FDE only.
[11:16] <caribou> rbasak: well, LP: #1307003 kinda outline one reason : multiple users on one FDE
[11:52] <xnox> finished reading bug mail. #2017goals
[11:53] <Odd_Bloke> * xnox is done for the year.
[11:55]  * Laney had a suspiciously low amount of bug mail over the hols
[11:58] <xnox> all my evenings for the rest of the week will be busy with adult lego from ikea, 2 wardrobes.
[12:11] <ahasenack> hi guys, question. A discarded -proposed upload (i.e., it failed verification), should the new upload be based on it, or is the discarded one really discarded?
[12:12] <ahasenack> i ask because I made a new upload, ignoring the failed -proposed package, but launchpad is showing me a diff between the discarded failed proposed package and my upload, instead of a diff between what's in -updates and my upload
[12:24] <xnox> ahasenack, usually one should superseed and use -vLAST_UPDATES_OR_RELEASE_VERSION to include the full changelog, including failed attempts.
[12:24] <xnox> that's what i do.
[12:24] <ahasenack> xnox: what's that -v option? Who gets it?
[12:25] <ahasenack> xnox: also, in the general case, how would I know there was a failed -proposed package? I usually just go to packages.ubuntu.com, check what's in <distro>-updates and base on that. Or use pull-lp-sources
[12:26] <xnox> debuild -S -sa -v1.0-1
[12:26] <xnox> when building 1.0-1ubuntu0.2 (a fix up for the failed 1.0-1ubuntu0.1 sru)
[12:27] <xnox> such that all changelog entries are included in the .changes file /since/ 1.0-1 (last good one/shipped)
[12:44] <cpaelzer> has anybody a hint what on this proposed migration is still blocking https://launchpad.net/ubuntu/+source/dpdk/16.07.2-0ubuntu0.16.10.1 (belongs to bug 1647945)
[12:50] <seb128> cpaelzer, best to check with the SRU team but it's likely that it's just that the SRU team has been in holidays and not copying updates, should be back to business this week
[12:53] <cpaelzer> seb128: people in holidays is the best case that could happen for the package and the people - thanks
[12:54] <seb128> cpaelzer, yw!
[12:57] <seb128> cpaelzer, though http://people.canonical.com/~ubuntu-archive/pending-sru.html has an autopkg regression for openvswitch listed so that might turn out to be an issue once people are back...
[13:08] <cpaelzer> seb128: thanks for pointing that out - that very likely is a transient issue not related as the dpdk test succeeds
[13:08] <seb128> right
[13:08] <cpaelzer> seb128: but it is good to be aware
[13:09] <cpaelzer> jamespage: please let me know if you think that is somethinh on the dpdk end of things^^
[13:32] <FourDollars> How to see the debug messages of indicator-power?
[13:39] <seb128> FourDollars, what version of Ubuntu?
[13:39] <FourDollars> seb128: Ubuntu 16.04
[13:39] <seb128> FourDollars, the log should be in the upstart job log, in .cache/upstart/indicator-power.log
[13:40] <seb128> FourDollars, you can also stop the service using "stop indicator-power" and start it by hand
[13:40] <FourDollars> seb128: I saw it. Thx a lot. :D
[13:41] <seb128> FourDollars, yw!
[14:03] <kirkland> caribou: I use ecryptfs on top of full encrypted luks/dmcrypt root disk
[14:04] <kirkland> caribou: rbasak: the difference is that there is one system wide passphrase/key for the full disk encryption, where as ecryptfs has per-user passphrases/keys
[14:04] <caribou> kirkland: yeah, I do that too; I was just curious as why both encrypted HOME as we set it up & full disk encryption could be used
[14:04] <caribou> kirkland: the per-user situation is what I was after
[14:05] <kirkland> caribou: yeah, that's roughly it;  provides a little bit of separation between alice and bob and carol on the same system
[14:05] <caribou> kirkland: but there is a bug in Trusty which, if you use both, will wipe out the /dev/mapper/cryptswap1
[14:05] <kirkland> caribou: oh, interesting, that should be fixed, then
[14:05] <caribou> kirkland: no LP yet but I'm on it
[14:06] <kirkland> caribou: conflicting management of swap?
[14:06] <caribou> kirkland: think so
[14:16] <caribou> kirkland: problem in trusty looks like LP: #953875 that never got completed fixed for Trusty
[14:17] <caribou> kirkland: even with encrypted $HOME only
[14:18] <caribou> kirkland: from what I remember from before xmas, it's the offset= handling in /etc/crypttab that is still missing
[15:31] <jamespage> cjwatson, hello - is there a way to switch to source of a git repo import on launchpad?
[15:31] <jamespage> I can find it in the UI
[15:31] <cjwatson> jamespage: I don't quite understand the question.  Can you rephrase?
[15:31] <henrix> barry: i'm seeing all trusty linux ADT tests failing for armhf.  any idea if there's anything going on?
[15:31] <jamespage> cjwatson, ok best illustrated with an example
[15:31] <jamespage> https://code.launchpad.net/~openstack-snappers/snap-glance/+git/snap-glance
[15:31] <jamespage> import from github.com/openstack-snaps/snap-glance
[15:31] <henrix> barry: i'm looking here: http://people.canonical.com/~kernel/status/adt-matrix/trusty-linux-meta.html
[15:32] <jamespage> I want to switch that to github.com/openstack/snap-glance
[15:32] <jamespage> as the repo has now moved to a new org
[15:32] <dobey> jamespage: you don't see "(+) Edit import source or review import" on that page under the list of successful imports?
[15:32] <cjwatson> jamespage: ah, it's probably restricted to ~vcs-imports.  I can change it for you
[15:32] <cjwatson> jamespage: Is it the same repository, just moved?
[15:32] <dobey> oh
[15:33] <jamespage> cjwatson, yup - I have a few others to switch as well - are you ok todo those as well (only about 6 total)
[15:33] <barry> henrix: i don't know, but looking at the bbswitch log, it seems like it might be a dependency issue?
[15:33] <cjwatson> jamespage: done that one, and sure, just give me a list
[15:34] <jamespage> cjwatson, ack
[15:34] <jamespage> https://code.launchpad.net/~openstack-snappers/snap-keystone/+git/snap-keystone
[15:34] <jamespage> https://code.launchpad.net/~openstack-snappers/snap-neutron/+git/snap-neutron
[15:34] <jamespage> https://code.launchpad.net/~openstack-snappers/snap-nova/+git/snap-nova
[15:34] <jamespage> https://code.launchpad.net/~openstack-snappers/snap-hypervisor/+git/snap-nova-hypervisor
[15:35] <barry> henrix: but it's not all armhf though, right?
[15:35] <henrix> barry: iirc, a MISS means the test didn't get executed at all so there shouldn't exist any logs.
[15:35] <jamespage> cjwatson, ^^ thats all of them
[15:35] <jamespage> thankyou
[15:35] <cjwatson> jamespage: all done, though s/snap-hypervisor/snap-nova-hypervisor/ in that last URL
[15:36] <jamespage> ah yes - my bad
[15:36] <jamespage> cjwatson, ta
[15:36] <cjwatson> np
[15:37] <henrix> barry: i've tried a 'retry' but i still don't see them being run
[15:40] <barry> henrix: off-hand i'm not sure what's going on.  my stack is a bit deep with post-vaca catch up, but i'll see if i can investigate further in a bit with my meager pitti-fu ;)
[15:40] <henrix> barry: oh, you were looking at the ppc64el FAIL.  yeah, that's ok and it has always failed.  i was looking at all the MISS for armhf
[15:41] <henrix> barry: ack, thanks!
[16:40] <infinity> henrix: "miss" usually doesn't mean the test never ran, it means the versions don't match what Andy's expecting.
[16:41] <infinity> henrix: So, if adt triggers kernel_1 against dkms_1, and then dkms_2 is uploaded, Andy's matrix demands that kernel_1 be tested against dkms_2 to be considered good, and logs it as a "miss".
[16:42] <infinity> henrix: Smacking the retry is all that's needed, but beware queue depths, etc.  You're not going to see instant results.
[16:42] <infinity> barry: ^
[16:42] <infinity> barry: The kernel team's matrix is another level of "whee" on top of the britney stuff.
[16:44] <infinity> henrix: Although, for stable uploads, there shouldn't generally be that many misses, so it's possible either a queue is super long, or got flushed.
[16:45] <infinity> henrix: Oh, and now I've caught up to reality (and your complaint) that it's only armhf.  Yeah, looks like a queue exploded somewhere.  Hrm.
[16:45] <henrix> infinity: ah!  thanks for clarifying.  i've retried a few, but none of the trusty armhf seem to have changed anything.  i'll keep an eye on it and see if there are changes.  it's odd that _all_ armhf are MISS
[16:46] <infinity> henrix: Indeed, armhf might just be buggered right now.  That'll need a deeper dive.
[16:47] <henrix> infinity: ok, it is possible that this has happen already in the last cycle and i just failed to notice :-/
[16:47] <infinity> Heh.
[16:47] <henrix> (last cycle was... well.. hmm.. that)
[16:47] <infinity> Indeed, looking at the matrix, it doesn't seem to be an uncommon situation of late.
[16:48] <infinity> Not an ideal one either, but...
[16:48] <henrix> infinity: there's only the lxc ones that are new, but they are MISS in all archs
[16:49] <henrix> infinity: note that lts-x has the same issue (i.e. armhf MISS)
[16:49] <infinity> henrix: Yeah.  Something's definitely goofy.
[16:50] <infinity> henrix: On the other hand, these aren't useful runtime tests (armhf runs in containers on aarch64 hosts), so the only tests that would be interesting are the dkms compile tests.
[16:50] <infinity> henrix: Which seem unlikely to break on armhf and no other arch.
[16:50] <infinity> henrix: So, from the POV of "our testing sucks anyway", you're likely safe to ignore this for this cycle.  We should look into WTF, though.
[16:51] <infinity> (We should also sort out how to make the armhf tests actually boot armhf VMs...)
[16:52] <henrix> infinity: agreed.  who shall i keep bothering regarding this?
[16:52] <infinity> henrix: In theory, barry, me, Laney (and, when he's back, Andy), in practice, we have some catch up to do to be adequate pitti replacements.
[16:53] <stgraber> infinity, kees, mdeslaur, slangasek: TB meeting in 7
[16:53] <mdeslaur> ack
[16:53] <infinity> stgraber: Can't make me.
[16:53]  * infinity refuses to start 2017.
[16:53]  * slangasek nods
[16:53] <Laney> Mmm.
[16:53] <slangasek> infinity: enjoy your prolonged 2016
[16:53] <infinity> slangasek: Is that not what 2017 promises to be anyway? :/
[16:54] <infinity> Well, actually, it promises to be worse.
[16:56] <ogra_> more artists dieing ?
[16:57] <dobey> time is an illusion anyway
[16:57] <dobey> lunch time doubly so
[17:09] <Laney> infinity: henrix: I rm-ed pending.json for trusty - should cause the 'in progress' requests to be requeued
[17:09] <Laney> There were some similar lost requests for zesty/armhf too, which I did the same for this morning
[17:10] <Laney> No guarantee they'll work, but at least they should get queued and run
[17:10] <henrix> Laney: cool, thanks!  i'll keep an eye and see what happens
[17:12] <infinity> Laney: Do you have plans to continue development on the autopkgtest infra, or is in maintenance mode for now?
[17:13] <infinity> Though, I guess my armhf-on-VMs thing will really come down to teaching scalingstack how to do that, not really an autopkgtest thing.
[17:13] <Laney> infinity: I want to find time to work on it
[17:13] <infinity> Laney: I want to find a lot of extra time too.  I also know how well that doesn't usually work. :)
[17:17] <Laney> infinity: I'll do me best
[17:18] <Laney> Still trying to puzzle out how all of it hangs together too
[17:18] <Laney> I've got basically NFC about the kernel bit
[17:18] <infinity> Laney: The kernel bit is a disgusting hack directly in britney.
[17:18] <infinity> Laney: One that should be removed Very Soon.  I'll have a chat with Andy about it when he gets back.
[17:18] <Laney> I'm sort of aware how they get queued
[17:18] <Laney> but not of any big picture there
[17:19] <infinity> Laney: It should become largely unnecessary with the new Testsuite-Triggers stuff.  Maybe.  If we do it right.
[17:19] <infinity> Laney: Well, how they get queued it the only picture that matters to you.  The rest is handled outside our infra, by the kernel team.
[17:19] <infinity> s/it the/is the/
[17:20] <infinity> But the disgusting hack we use to queue it all should be replaced.
[17:20] <Laney> I'd quite like to understand the usecase
[17:20] <Laney> But not urgent
[17:21] <infinity> I'm pretty intimately familiar with how things happen on the britney side (and the kernel team's stuff too), it's everything on the other side of the MQ that's a black box to me.
[17:21] <infinity> And I feel like it shouldn't be.
[17:21] <infinity> Request goes in, [stuff!], results!
[17:22] <Laney> Cool - add us together and we make 50% of a pi_tti :P
[17:23] <slangasek> ... and I'll form the head?
[17:25] <cjwatson> develicons!  pi_tti in disguise!
[19:58] <pitti> Laney, infinity: kernel> that was a result of looong discussions with apw.. basically, we want to trigger everything off linux-meta so that apt pinning DTRT, and introduce a fake linux → linux-meta dep so that linux doesn't propagate before linux-meta
[19:58] <pitti> that's basically it
[19:58] <pitti> plus some extra synthethic deps to trigger things like lxc for new kernels, which should be replaced with Testsuite-Triggers:
[21:52] <pdeee> rbasak, do you think you'll have time to review RAOF's Certbot SRU packages
[21:52] <pdeee> ?
[21:55] <rbasak> pdeee: I will, but please give me a week at least - it was my first day back from vacation today.
[21:55] <pdeee> rbasak, of course. Happy 2017!
[22:38] <barry> infinity, Laney we should huddle some time re: autopkgtest infra moving forward.  i am powering up my clone army for this
[22:38] <tsimonq2> pitti: BTW while you're here, good luck going forward :)