[03:40] <pitti> Good morning
[03:40] <Unit193> Howdy.
[03:40] <pitti> smoser: cool, thanks! updating util-linux then with adjusting the package in breaks: and versioning it
[04:01] <pitti> utlemming, smoser: hmm - http://cloud-images.ubuntu.com/wily/20150511/ says "vivid-*"?
[06:18] <dholbach> good morning
[06:39] <Unit193> LocutusOfBorg1: Howdy.
[09:18] <LocutusOfBorg1> hi Unit193
[09:20] <LocutusOfBorg1> can anybody please retry casablanca/wily?
[09:20] <LocutusOfBorg1> thanks
[09:20] <xnox> slangasek: congrats on level-up! =)
[09:34] <cjwatson> pitti: ok, fixing that ddeb-retriever crash is now waiting for RT#81133
[09:34] <pitti> cjwatson: thanks; I'm glad we don't lose ddebs any more :)
[09:34] <cjwatson> (LP rollout including r17493 which adds build.source_package_name)
[09:34] <cjwatson> pitti: indeed, it will just be delayed but should catch up fine
[09:35] <cjwatson> pitti: I considered the workaround option of manually bumping the threshold past the offending build and setting it back later to retry, but this is safer
[09:40] <smoser> pitti, talk to utlemming about it, but they're still getting wily builds going.
[09:41] <pitti> smoser: ok, thanks (I pinged him as well); just wanted to make sure that this is known
[09:44] <pitti> vrr, sil2100: wrt. updating -touch langpacks automatically: where should these go? post-release they usually go into https://launchpad.net/~ubuntu-langpack/+archive/ubuntu/ppa/+index?field.series_filter=vivid and are SRUed to vivid once a month
[09:45] <pitti> vrr, sil2100: but I figure that might not be what we want? should the updates be uploaded to the overlay PPA?
[09:45] <pitti> (automatically)
[09:46] <sil2100> pitti: hey! I think touch langpacks could go directly to the overlay as this is what was happening for RTM
[09:46] <sil2100> So I suppose it might make sense here as well
[09:46] <pitti> sil2100: right, my toughts
[09:46] <sil2100> +1 on that :)
[10:00] <pitti> sil2100: tested with one package: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5060036/+listing-archive-extra
[10:01] <pitti> seems to work
[10:01]  * pitti scriptifies it
[10:21] <LocutusOfBorg1> ping, can anybody please retry casablanca? the newer gcc-5 might have fixed the build failure :)
[10:23] <pitti> LocutusOfBorg1: done
[10:23] <LocutusOfBorg1> thanks :)
[10:33] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/casablanca/2.4.0-2/+build/7389439
[10:34] <LocutusOfBorg1> doko_, ^^^ actually the new libstdc++ and gcc-4.9 makes the build fail
[10:37] <LocutusOfBorg1> I'm going to upload with g++5 forced in the b-d
[10:37] <LocutusOfBorg1> (of course if this is ok for you)
[11:10] <cjwatson> pitti: ddebs should be fixed now
[11:10] <pitti> cjwatson: \o/ cheers
[11:36] <mdeslaur> slangasek: happy birthday! :)
[13:54] <caribou> Is there a way to be sure that an upstart job terminates before RUNLEVEL is emited ?
[13:55] <pitti> caribou: doesn't "start on starting rc RUNLEVEL=[2345]" do that?
[13:55] <caribou> pitti: no, I didn't get much luck with this one when you suggested last week
[13:55] <xnox> caribou: and "task"
[13:56] <xnox> pitti: ^
[13:56] <pitti> ah :)
[13:56] <caribou> xnox: so start on starting rc RUNLEVEL=[2345] and task ?
[13:56] <xnox> caribou: no
[13:56] <xnox> task
[13:56] <xnox> start on starting rc RUNLEVEL=[2345]
[13:56] <caribou> ah, ok let me try that...
[13:57] <xnox> caribou: this way "started" will only be emitted, when the thing exits.
[13:57] <xnox> caribou: aka systemd Type=oneshot RemainAfterExit=true
[13:57] <caribou> xnox: good as the task is kdump & it will trigger a reboot
[13:57] <smoser> hey. what am i doing wrong....
[13:57] <smoser>  echo "manual" > /etc/init/pollinate.conf.override
[13:57] <smoser> but job still runs
[13:58] <smoser> in trusty.
[13:59] <xnox> smoser: echo "manual" > /etc/init/pollinate.override
[13:59] <xnox> smoser: .override is the right extension...
[14:01] <smoser> xnox, bah.
[14:01] <smoser> thank you very much
[14:27] <didrocks> slangasek is spamming wily for his birthday :)
[14:27] <didrocks> I guess someone has found the "publish all silos" button
[14:28] <seb128> didrocks, or rather syncing the overlay ppa to wily?
[14:28] <seb128> or pocket copying it over
[14:28] <Laney> timely ...
[14:29] <didrocks> seb128: I guess you are right
[14:34] <pitti> oh, I'm just copying my two uploads from the PPA to wily, is this being done en masse now?
[14:34] <didrocks> pitti: seems so from -changes
[14:44] <slangasek> xnox, mdeslaur, didrocks: actually I lied to Google about my birthday, this is the first time I've ever known them to pass this lie on to people.. :)
[14:44] <mdeslaur> slangasek: well, happy birthday anyway, you've used up your one birthday wish for the year.
[14:44] <pitti> slangasek: oh, then I won't say congrats :)
[14:44] <slangasek> :-)
[14:45] <didrocks> slangasek: google can't be wrong, so happy birthday anyway! :p
[14:45] <mdeslaur> slangasek: google also tells me you're 23, I gather that's a lie too?
[14:45] <didrocks> heh
[14:45] <seb128> slangasek, congrats, your birthday officially got updated to today ;-)
[14:45] <xnox> wait what, i'm not older than slangasek ?! phhhh
[14:45] <slangasek> mdeslaur: it does? that's interesting, because I told google I was born in 1945
[14:46] <mdeslaur> slangasek: hehe
[14:47] <pitti> oh dear, the interweb is wrong.. https://xkcd.com/386/
[14:50] <cjwatson> slangasek: happy 70th birthday, then
[14:50] <slangasek> :-)
[15:07] <pitti> slangasek: do you know what britney does with the packages which are newer in wily than in your copied wily-proposed packages? (top of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
[15:07] <pitti> slangasek: I assume we just remove them manually?
[15:07] <slangasek> pitti: oh I assumed they would have failed to upload.  if not, then yes we should manually remove
[15:08] <pitti> slangasek: I guess they would have, but copy-package doesn't seem to do that check apparently
[15:08] <cjwatson> Copies are allowed to go backwards
[15:08] <cjwatson> You're meant to check :)
[15:09] <slangasek> noted :)
[15:10] <cjwatson> pitti,slangasek: I can't quite remember the rules; if I were you I'd check publishing histories to make sure that there were no cases where there was already something in wily-proposed
[15:25] <utlemming> pitti: s/vivid/wily for future builds of Wily
[15:25] <utlemming> pitti: the next builds should be okay
[15:25] <pitti> utlemming: :) thanks for preparing wily images, much appreciated
[15:25] <pitti> fginther: ^ FYI (for autopkgtest CI)
[15:30] <shadeslayer> rbasak: do you reckon docker.io can be backported to utopic?
[15:32] <shadeslayer> bah
[15:32] <shadeslayer> needs new libdevmapper1.02.1
[15:32] <shadeslayer> :(
[15:36] <fginther> utlemming, pitti, yes, thanks
[15:47] <rbasak> shadeslayer: that's the plan. To Trusty too. I have 1.6.0 working on Trusty in testing, though not ready for upload yet. I didn't hit your libdevmapper issue though, so I'm a bit confused about that.
[15:47] <rbasak> shadeslayer: what's your issue exactly?
[15:48] <shadeslayer> rbasak: I just tried to install the willy package on utopic
[15:48] <shadeslayer> hoping it would work ;)
[15:48] <shadeslayer> but clearly not, rebuilding it now
[15:48] <rbasak> shadeslayer: oh, I see. Rebuilding it should work I think.
[15:48] <shadeslayer> rbasak: and hurray @ backporting \o/
[15:48] <shadeslayer> rbasak: yeah
[15:48] <shadeslayer> kind of sucks that docker doesn't provide arm packages
[15:49] <rbasak> It should work on arm.
[15:49] <shadeslayer> yeah it does
[15:49] <rbasak> Vivid supports ppc64el too - IBM enabled it. So general cross-platform support should be there.
[15:49] <shadeslayer> nice
[15:50] <rbasak> shadeslayer: I'd appreciate some help with testing when it hits trusty-proposed if you're up for that.
[15:50] <shadeslayer> let me check
[15:50] <rbasak> Maybe in a week or two.
[15:50] <shadeslayer> rbasak: yeah can do
[15:50] <rbasak> Thanks! I'll ping you when it hits -proposed.
[15:50] <shadeslayer> cool
[15:51] <shadeslayer> thanks to you too :)
[15:52] <shadeslayer> rbasak: https://paste.kde.org/paykz2byz
[15:52] <rbasak> shadeslayer: oh yeah, sorry. I forgot about that.
[15:52] <shadeslayer> utopic has 1-1 apparently
[15:53] <shadeslayer> rbasak: reckon just downgrading the deps wil lwork
[15:53] <rbasak> In my backport I started embedding the dependencies, but the conclusion is to push the build deps back to each stable release as well.
[15:53] <rbasak> I'm not sure downgrading them will work - I think various things need newer features.
[15:53] <shadeslayer> ah
[15:53] <rbasak> shadeslayer: I can give you a work in progress diff that embeds the dependencies if you want it.
[15:53] <shadeslayer> yes plz
[15:56] <rbasak> shadeslayer: try http://people.canonical.com/~rbasak/docker-wip/docker.io_1.6.0+dfsg1+revendor-0ubuntu0.14.04.1~dev1.dsc
[15:57] <rbasak> That embeds the build deps, which is no longer the plan, but I think it builds OK on Trusty.
[15:59] <shadeslayer> rbasak: trying, though this is on utopic
[16:00] <rbasak> shadeslayer: I'm not aware of any reason it should fail on Utopic.
[16:00] <shadeslayer> ok
[16:01] <pitti> stgraber, infinity, kees, slangasek, mdeslaur: TB meeting now, right?
[16:01] <mdeslaur> pitti: yep
[16:04] <rbasak> shadeslayer: btw, you might want to be aware of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784726. We expect to have 1.6.1 merged in wily this week, and when I prepare the backports for upload they will be 1.6.1.
[16:05] <shadeslayer> oh
[16:05] <shadeslayer> hm, thank
[16:05] <shadeslayer> *thanks
[16:11] <shadeslayer> rbasak: seems to have built, thanks
[16:29] <hallyn> infinity: arges: when you talk about SRUing the kvm-on-all-arches bug, is bug 1369785 what you are talking about?
[16:32] <infinity> hallyn: "kvm-on-all-arches" sounds like a description of having a functional /bin/kvm (and the kvm package) on all arches.
[16:32] <infinity> hallyn: So other packages can depend on and rely on it.
[16:33] <infinity> hallyn: But that autoload bug is also important.
[16:33] <infinity> s/kvm package/qemu-kvm package/
[16:34] <arges> hallyn: infinity we would probably need to do ppc64_cpu --smt=disable (or whatever the command is)
[16:34] <arges> before modprobing that module? or would that be something we do when we launch the actual instance
[16:34] <infinity> arges: It's not required to have the module loaded, just to actually start akvmish qemu.
[16:34] <infinity> s/akvmish/a kvmish/
[16:35] <arges> infinity: so whose responsibility would it be to disable smt? qemu?
[16:35] <arges> or the user
[16:36] <infinity> arges: I'm not sure we're ever sorted out exactly who should be perpetrating the hack.
[16:36] <infinity> arges: Ultimately, it's a qemu bug that requires it, but it's a Very Hard bug to fix.
[16:37] <arges> yea
[16:38] <infinity> arges: I wouldn't be against the init/systemd jobs doing an [ -x /usr/sbin/ppc64_cpu ] && disable_smt, under the assumption that if you have qemu-ppc installed *and* you're on a PPC host, you probably intend to use KVM at some point.
[16:38] <hallyn> sounds like i'm out of my depth
[16:38]  * hallyn needs to gethisself a p8 box :)
[16:38] <infinity> hallyn: You and me both.
[16:38] <arges> : )
[16:38] <infinity> Lemme double-check that /usr/sbin/ppc64_cpu doesn't explode nastily when run on a machine that doesn't support it.
[16:39] <hallyn> ok - sounds like i need to make this something to look into separately, and not part of today's SRU
[16:39] <arges> yea i think we should make qemu work similar to amd64
[16:39] <infinity> hallyn: Yeah, I think we'll want one big "ppc packaging fixes" roundup SRU.
[16:40] <infinity> hallyn: That said, I'm about 95% sure that LE hosts don't work on trusty's qemu anyway, without some patches backported from 2.1, which IBM has yet to identify.
[16:41] <hallyn> fun
[16:41] <hallyn> ok, thanks, hopefully after ODS i can dig in
[16:41] <infinity> Oh, FFS.  Thanks, IBM.
[16:42] <infinity> Can't even call ppc64_cpu unconditionally.  Exits non-zero on non-SMT CPUs.
[16:42] <infinity> I guess we can just || true it and carry on with life.
[16:45] <arges> hallyn: so back to your bug... should we be SRU'ing that to T/U/V?
[16:45] <arges> should i target it as such
[16:46] <infinity> V should be all fixed, except for the SMT thing we were just discussing.
[16:46] <infinity> The goal would be to make T and U look like V.
[16:46] <arges> ok adjustin
[16:49] <hallyn> arges: well, as i recall infinity was the one who had asked for this, so i just wanted to make sure he has what he needs.  so whatever satsifies him
[16:50] <infinity> hallyn: Nothing will ever satisfy me.
[16:50] <hallyn> snickers?
[16:50] <arges> hehe
[16:50] <infinity> Maybe!
[16:50] <infinity> Anyhow, I think the goal should be for the qemu-kvm packaging to look like vivid, since that seems to be where we finally got it mostly right for arm64/ppc64el.
[16:51] <infinity> And we should also fix the smt-disabling thing while we're at it.
[16:51] <hallyn> which isn't yet fixed in vivid/wily right?
[16:51] <mdeslaur> deep fried bacon snickers?
[16:51] <hallyn> ok, thx, i'll make a note of all this for in ... a few weeks
[16:52] <infinity> Actually, wait, did we get it right?
[16:53] <infinity> Oh.  I'm looking on an x86 system, and the builds are more "clever" than that.
[16:53]  * infinity grabs a ppc version of qemu-system-ppc
[16:56] <infinity> Okay, no, it's still not quite right in vivid. :P
[16:58] <infinity> And, indeed, with the upstart->systemd switch in vivid, it's actually actively broken on vivid.
[17:02] <hallyn> hm, why does pull-lp-source not know about wily yet
[17:02] <hallyn> (on my wily laptop)
[17:11] <infinity> hallyn: Because you need to upgrade?
[17:12] <infinity> hallyn: I'd assume your distro-info-data is out of date.
[17:16] <hallyn> hm, i updated yesterday... one more for good measure
[17:27] <infinity> hallyn: Works for me with distro-info-data 0.27
[17:30] <hallyn> infinity: bah.  now it works.  but distro-info was last updated on may 10.  weird
[17:31] <hallyn> oh, well, it works, happy :)
[17:57] <jdstrand> bdmurray, arges: hey, I was wondering if someone could look at bug #1450642. I fixed the version issue last week
[18:10] <arges> jdstrand: taking a look
[18:17] <arges> jdstrand: so would this be worth backporting to trusty, since we'll be supporting lts-vivid at some point
[18:18] <arges> is it backwards compatible with 3.13/3.16?
[18:18] <luist> how do i remove unity completely and use gnome classic as default?
[18:22] <jdstrand> arges: it should be backwards compatible-- it is just a list of calls that the library knows about. that said, that would need to be tested. that said, trusty userspace running with an lts-vivid kernel still had the userspace compiled on the lts-release kernel, so software won't know to use the new syscalls
[18:22] <jdstrand> so I don't think it is actually required
[18:22] <jdstrand> this bug is the inverse of that though
[18:23] <jdstrand> software compiled on a system with a new kernel headers (and therefore knowing about the new syscalls) not working because libseccomp wasn't updated
[18:24] <jdstrand> well, the software works-- it is just denied when run under certain seccomp filters (like on snappy)
[18:24] <arges> jdstrand: ack.
[18:25] <arges> jdstrand: ok accepted into vivid-proposed
[18:25] <jdstrand> thanks!
[18:30] <infinity> jdstrand: Which kernel headers are available when you build software have no relation to wich syscalls you can use at runtime...
[18:31] <arges> yea, my question is a user could build an app against lts-vivid headers too, so this may be useful for trusty/3.19
[18:31] <jdstrand> infinity: well, maybe I didn't explain it right, but software in trusty isn't going to just start using getrandom() (which was added later)
[18:31] <jdstrand> just cause the kernel happens to now all of a sudden support it
[18:31] <infinity> arges: We don't build userspace lts-vivid headers, which was jdstrand's point (linux-libc-dev is 3.13), but one can invoke syscalls directly that glibc/linux-libc-dev don't know about.
[18:32] <infinity> jdstrand: But yeah, a fair point that software we ship shouldn't be using syscalls that don't appear in 3.13
[18:32] <arges> gotcha
[18:32] <infinity> jdstrand: Out-of-archive software, OTOH.  I guess that depends on seccomp's use cases.
[18:33] <jdstrand> libseccomp's use on trusty is mostly limited to lxc. but they use a blacklist, so it too shouldn't be needed
[18:34] <jdstrand> (ie, the new ones just magically are allowed)
[18:34] <jdstrand> snappy uses a whitelist though, so the out of date libseccomp was causing some issues cause we'd get a denial and no way to allow it
[18:34] <irl> hi, anyone here a launchpad admin of some sort?
[18:34] <irl> need some help with someone claiming email addresses that do not belong to them
[18:34] <irl> they appear to be impersonating the debian hamradio team
[18:35] <infinity> irl: Context?
[18:35] <irl> https://launchpad.net/~frank-duron
[18:35] <irl> we got an email to our mailing list saying he was merging the account
[18:35] <irl> and now debian-hams@lists.d.o shows on his page
[18:36] <infinity> A valid reason for lists to be moderated.
[18:36] <irl> which it shouldn't do, because i've never heard of him
[18:36] <irl> infinity: that would make life difficult
[18:36] <irl> massively difficult
[18:37] <infinity> irl: Yeah, I know.  We can get the address removed again.  But it's a fundamental flaw with email validation of any sort.  Anyone who can recieve the email can clik the "yeahp, this worked" link.
[18:37] <infinity> (Same for signing up for mailing lists, etc)
[18:38] <irl> ok, so can you remove the address?
[18:38] <infinity> irl: On it.
[18:39] <irl> and maybe bar the address from being used?
[18:39] <irl> in fact, could you bar @lists.debian.org from being any kind of authority on who owns the address
[18:39] <infinity> cjwatson: Is there a blacklist of address patterns humans can't use?  Seems like allowing people to sign add mailing lists to their accounts is less than ideal.
[18:39] <infinity> s/sign //
[18:40] <infinity> irl: It's removed from his account.  We'll discuss blacklisting out of band.
[18:41] <irl> ok
[20:49] <speck84> hiya guys can somebody tell me how can i set my html5 app into portrait mode only?
[20:51] <sarnold> speck84: perhaps #ubuntu-touch is more appropriate?
[20:51] <speck84> they sent me here
[20:51] <sarnold> oh :)
[20:51] <sarnold> carry on then
[20:51] <speck84> cheers
[20:52] <speck84> here are the pro's
[20:57] <dobey> speck84: #ubuntu-app-devel is the channel you want i think
[20:58] <speck84> thx dobey but is a back to forward thing they told me to come here
[20:59] <speck84> anyway somebody just know it I still digging the gogle
[20:59] <speck84> I can't immagin noone ever faced with this situationn before
[20:59] <dobey> no, ubuntu-app-devel didn't tell you to come here
[21:01] <dobey> i am in there and you are not, and i see no previous conversation from you in there within the last couple of hours
[21:35] <cjwatson> infinity: I don't believe so, other than syntactic validity.  Trying to blacklist lists is probably doomed to failure ...
[22:26] <infinity> cjwatson: Perhaps, yes.
[22:28] <infinity> cjwatson: In this case, I don't think it was someone specifically adding foo@lists.d.o to his account anyway, it was a side-effect of the silly "create an account for every email address in Packages.gz" thing we did ten years ago, and then someone attempting to merge that account with his onw.