=== salem_ is now known as _salem [03:40] Good morning [03:40] Howdy. [03:40] smoser: cool, thanks! updating util-linux then with adjusting the package in breaks: and versioning it [04:01] utlemming, smoser: hmm - http://cloud-images.ubuntu.com/wily/20150511/ says "vivid-*"? [06:18] good morning [06:39] LocutusOfBorg1: Howdy. === thegodfather is now known as fabbione === vrruiz_ is now known as rvr [09:18] hi Unit193 [09:20] can anybody please retry casablanca/wily? [09:20] thanks [09:20] slangasek: congrats on level-up! =) [09:34] pitti: ok, fixing that ddeb-retriever crash is now waiting for RT#81133 [09:34] cjwatson: thanks; I'm glad we don't lose ddebs any more :) [09:34] (LP rollout including r17493 which adds build.source_package_name) [09:34] pitti: indeed, it will just be delayed but should catch up fine [09:35] 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] pitti, talk to utlemming about it, but they're still getting wily builds going. [09:41] smoser: ok, thanks (I pinged him as well); just wanted to make sure that this is known [09:44] 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] vrr, sil2100: but I figure that might not be what we want? should the updates be uploaded to the overlay PPA? [09:45] (automatically) [09:46] pitti: hey! I think touch langpacks could go directly to the overlay as this is what was happening for RTM [09:46] So I suppose it might make sense here as well [09:46] sil2100: right, my toughts [09:46] +1 on that :) [10:00] sil2100: tested with one package: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5060036/+listing-archive-extra [10:01] seems to work [10:01] * pitti scriptifies it [10:21] ping, can anybody please retry casablanca? the newer gcc-5 might have fixed the build failure :) [10:23] LocutusOfBorg1: done [10:23] thanks :) [10:33] https://launchpad.net/ubuntu/+source/casablanca/2.4.0-2/+build/7389439 [10:34] doko_, ^^^ actually the new libstdc++ and gcc-4.9 makes the build fail [10:37] I'm going to upload with g++5 forced in the b-d [10:37] (of course if this is ok for you) [11:10] pitti: ddebs should be fixed now [11:10] cjwatson: \o/ cheers === MacSlow is now known as MacSlow|lunch [11:36] slangasek: happy birthday! :) === ralsina_ is now known as ralsina === MacSlow|lunch is now known as MacSlow [13:54] Is there a way to be sure that an upstart job terminates before RUNLEVEL is emited ? [13:55] caribou: doesn't "start on starting rc RUNLEVEL=[2345]" do that? [13:55] pitti: no, I didn't get much luck with this one when you suggested last week [13:55] caribou: and "task" [13:56] pitti: ^ [13:56] ah :) [13:56] xnox: so start on starting rc RUNLEVEL=[2345] and task ? [13:56] caribou: no [13:56] task [13:56] start on starting rc RUNLEVEL=[2345] [13:56] ah, ok let me try that... [13:57] caribou: this way "started" will only be emitted, when the thing exits. [13:57] caribou: aka systemd Type=oneshot RemainAfterExit=true [13:57] xnox: good as the task is kdump & it will trigger a reboot [13:57] hey. what am i doing wrong.... [13:57] echo "manual" > /etc/init/pollinate.conf.override [13:57] but job still runs [13:58] in trusty. [13:59] smoser: echo "manual" > /etc/init/pollinate.override [13:59] smoser: .override is the right extension... [14:01] xnox, bah. [14:01] thank you very much [14:27] slangasek is spamming wily for his birthday :) [14:27] I guess someone has found the "publish all silos" button [14:28] didrocks, or rather syncing the overlay ppa to wily? [14:28] or pocket copying it over [14:28] timely ... [14:29] seb128: I guess you are right [14:34] oh, I'm just copying my two uploads from the PPA to wily, is this being done en masse now? [14:34] pitti: seems so from -changes [14:44] 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] slangasek: well, happy birthday anyway, you've used up your one birthday wish for the year. [14:44] slangasek: oh, then I won't say congrats :) [14:44] :-) [14:45] slangasek: google can't be wrong, so happy birthday anyway! :p [14:45] slangasek: google also tells me you're 23, I gather that's a lie too? [14:45] heh [14:45] slangasek, congrats, your birthday officially got updated to today ;-) [14:45] wait what, i'm not older than slangasek ?! phhhh [14:45] mdeslaur: it does? that's interesting, because I told google I was born in 1945 [14:46] slangasek: hehe [14:47] oh dear, the interweb is wrong.. https://xkcd.com/386/ === bdmurray_ is now known as bdmurray [14:50] slangasek: happy 70th birthday, then [14:50] :-) === MacSlow is now known as MacSlow|errand === dholbach_ is now known as dholbach [15:07] 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] slangasek: I assume we just remove them manually? [15:07] pitti: oh I assumed they would have failed to upload. if not, then yes we should manually remove [15:08] slangasek: I guess they would have, but copy-package doesn't seem to do that check apparently [15:08] Copies are allowed to go backwards [15:08] You're meant to check :) [15:09] noted :) [15:10] 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] pitti: s/vivid/wily for future builds of Wily [15:25] pitti: the next builds should be okay [15:25] utlemming: :) thanks for preparing wily images, much appreciated [15:25] fginther: ^ FYI (for autopkgtest CI) [15:30] rbasak: do you reckon docker.io can be backported to utopic? [15:32] bah [15:32] needs new libdevmapper1.02.1 [15:32] :( [15:36] utlemming, pitti, yes, thanks === matsubara_ is now known as matsubara [15:47] 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] shadeslayer: what's your issue exactly? [15:48] rbasak: I just tried to install the willy package on utopic [15:48] hoping it would work ;) [15:48] but clearly not, rebuilding it now [15:48] shadeslayer: oh, I see. Rebuilding it should work I think. [15:48] rbasak: and hurray @ backporting \o/ [15:48] rbasak: yeah [15:48] kind of sucks that docker doesn't provide arm packages [15:49] It should work on arm. [15:49] yeah it does [15:49] Vivid supports ppc64el too - IBM enabled it. So general cross-platform support should be there. [15:49] nice [15:50] shadeslayer: I'd appreciate some help with testing when it hits trusty-proposed if you're up for that. [15:50] let me check [15:50] Maybe in a week or two. [15:50] rbasak: yeah can do [15:50] Thanks! I'll ping you when it hits -proposed. [15:50] cool [15:51] thanks to you too :) [15:52] rbasak: https://paste.kde.org/paykz2byz [15:52] shadeslayer: oh yeah, sorry. I forgot about that. [15:52] utopic has 1-1 apparently [15:53] rbasak: reckon just downgrading the deps wil lwork [15:53] 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] I'm not sure downgrading them will work - I think various things need newer features. [15:53] ah [15:53] shadeslayer: I can give you a work in progress diff that embeds the dependencies if you want it. [15:53] yes plz [15:56] shadeslayer: try http://people.canonical.com/~rbasak/docker-wip/docker.io_1.6.0+dfsg1+revendor-0ubuntu0.14.04.1~dev1.dsc [15:57] That embeds the build deps, which is no longer the plan, but I think it builds OK on Trusty. [15:59] rbasak: trying, though this is on utopic [16:00] shadeslayer: I'm not aware of any reason it should fail on Utopic. [16:00] ok [16:01] stgraber, infinity, kees, slangasek, mdeslaur: TB meeting now, right? [16:01] pitti: yep [16:04] 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:04] Debian bug 784726 in src:docker.io "docker.io: CVE-2015-3627 CVE-2015-3629 CVE-2015-3630 CVE-2015-3631" [Grave,Fixed] [16:05] oh [16:05] hm, thank [16:05] *thanks [16:11] rbasak: seems to have built, thanks [16:29] infinity: arges: when you talk about SRUing the kvm-on-all-arches bug, is bug 1369785 what you are talking about? [16:29] bug 1369785 in qemu (Ubuntu) "kvm modules not autoloaded on ppc64el" [High,Fix released] https://launchpad.net/bugs/1369785 [16:32] hallyn: "kvm-on-all-arches" sounds like a description of having a functional /bin/kvm (and the kvm package) on all arches. [16:32] hallyn: So other packages can depend on and rely on it. [16:33] hallyn: But that autoload bug is also important. [16:33] s/kvm package/qemu-kvm package/ [16:34] hallyn: infinity we would probably need to do ppc64_cpu --smt=disable (or whatever the command is) [16:34] before modprobing that module? or would that be something we do when we launch the actual instance [16:34] arges: It's not required to have the module loaded, just to actually start akvmish qemu. [16:34] s/akvmish/a kvmish/ [16:35] infinity: so whose responsibility would it be to disable smt? qemu? [16:35] or the user [16:36] arges: I'm not sure we're ever sorted out exactly who should be perpetrating the hack. [16:36] arges: Ultimately, it's a qemu bug that requires it, but it's a Very Hard bug to fix. [16:37] yea [16:38] 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] sounds like i'm out of my depth [16:38] * hallyn needs to gethisself a p8 box :) [16:38] hallyn: You and me both. [16:38] : ) [16:38] Lemme double-check that /usr/sbin/ppc64_cpu doesn't explode nastily when run on a machine that doesn't support it. [16:39] ok - sounds like i need to make this something to look into separately, and not part of today's SRU [16:39] yea i think we should make qemu work similar to amd64 [16:39] hallyn: Yeah, I think we'll want one big "ppc packaging fixes" roundup SRU. [16:40] 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] fun [16:41] ok, thanks, hopefully after ODS i can dig in [16:41] Oh, FFS. Thanks, IBM. [16:42] Can't even call ppc64_cpu unconditionally. Exits non-zero on non-SMT CPUs. [16:42] I guess we can just || true it and carry on with life. === dpm is now known as dpm-afk [16:45] hallyn: so back to your bug... should we be SRU'ing that to T/U/V? [16:45] should i target it as such [16:46] V should be all fixed, except for the SMT thing we were just discussing. [16:46] The goal would be to make T and U look like V. [16:46] ok adjustin [16:49] 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] hallyn: Nothing will ever satisfy me. [16:50] snickers? [16:50] hehe [16:50] Maybe! [16:50] 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] And we should also fix the smt-disabling thing while we're at it. [16:51] which isn't yet fixed in vivid/wily right? [16:51] deep fried bacon snickers? [16:51] ok, thx, i'll make a note of all this for in ... a few weeks [16:52] Actually, wait, did we get it right? [16:53] 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] Okay, no, it's still not quite right in vivid. :P [16:58] And, indeed, with the upstart->systemd switch in vivid, it's actually actively broken on vivid. [17:02] hm, why does pull-lp-source not know about wily yet [17:02] (on my wily laptop) [17:11] hallyn: Because you need to upgrade? [17:12] hallyn: I'd assume your distro-info-data is out of date. [17:16] hm, i updated yesterday... one more for good measure === Spr0cket- is now known as Spr0cket [17:27] hallyn: Works for me with distro-info-data 0.27 [17:30] infinity: bah. now it works. but distro-info was last updated on may 10. weird [17:31] oh, well, it works, happy :) === adrian is now known as alvesadrian === MacSlow|errand is now known as MacSlow [17:57] bdmurray, arges: hey, I was wondering if someone could look at bug #1450642. I fixed the version issue last week [17:57] bug 1450642 in libseccomp (Ubuntu Vivid) "seccomp missing many new syscalls" [Undecided,In progress] https://launchpad.net/bugs/1450642 === stth is now known as stth_ === stth_ is now known as stth__ === stth__ is now known as stth [18:10] jdstrand: taking a look [18:17] jdstrand: so would this be worth backporting to trusty, since we'll be supporting lts-vivid at some point [18:18] is it backwards compatible with 3.13/3.16? [18:18] how do i remove unity completely and use gnome classic as default? [18:22] 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] so I don't think it is actually required [18:22] this bug is the inverse of that though [18:23] 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] well, the software works-- it is just denied when run under certain seccomp filters (like on snappy) [18:24] jdstrand: ack. [18:25] jdstrand: ok accepted into vivid-proposed [18:25] thanks! [18:30] jdstrand: Which kernel headers are available when you build software have no relation to wich syscalls you can use at runtime... [18:31] 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] 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] just cause the kernel happens to now all of a sudden support it [18:31] 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] jdstrand: But yeah, a fair point that software we ship shouldn't be using syscalls that don't appear in 3.13 [18:32] gotcha [18:32] jdstrand: Out-of-archive software, OTOH. I guess that depends on seccomp's use cases. [18:33] libseccomp's use on trusty is mostly limited to lxc. but they use a blacklist, so it too shouldn't be needed [18:34] (ie, the new ones just magically are allowed) [18:34] 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] hi, anyone here a launchpad admin of some sort? [18:34] need some help with someone claiming email addresses that do not belong to them [18:34] they appear to be impersonating the debian hamradio team [18:35] irl: Context? [18:35] https://launchpad.net/~frank-duron [18:35] we got an email to our mailing list saying he was merging the account [18:35] and now debian-hams@lists.d.o shows on his page [18:36] A valid reason for lists to be moderated. [18:36] which it shouldn't do, because i've never heard of him [18:36] infinity: that would make life difficult [18:36] massively difficult [18:37] 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] (Same for signing up for mailing lists, etc) [18:38] ok, so can you remove the address? [18:38] irl: On it. [18:39] and maybe bar the address from being used? [18:39] in fact, could you bar @lists.debian.org from being any kind of authority on who owns the address [18:39] 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] s/sign // [18:40] irl: It's removed from his account. We'll discuss blacklisting out of band. [18:41] ok === kees_ is now known as kees [20:49] hiya guys can somebody tell me how can i set my html5 app into portrait mode only? [20:51] speck84: perhaps #ubuntu-touch is more appropriate? [20:51] they sent me here [20:51] oh :) [20:51] carry on then [20:51] cheers [20:52] here are the pro's [20:57] speck84: #ubuntu-app-devel is the channel you want i think [20:58] thx dobey but is a back to forward thing they told me to come here [20:59] anyway somebody just know it I still digging the gogle [20:59] I can't immagin noone ever faced with this situationn before [20:59] no, ubuntu-app-devel didn't tell you to come here [21:01] 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] infinity: I don't believe so, other than syntactic validity. Trying to blacklist lists is probably doomed to failure ... [22:26] cjwatson: Perhaps, yes. [22:28] 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. === doko_ is now known as doko