| === salem_ is now known as _salem | ||
| 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 | 03:40 |
| pitti | utlemming, smoser: hmm - http://cloud-images.ubuntu.com/wily/20150511/ says "vivid-*"? | 04:01 |
| dholbach | good morning | 06:18 |
| Unit193 | LocutusOfBorg1: Howdy. | 06:39 |
| === thegodfather is now known as fabbione | ||
| === vrruiz_ is now known as rvr | ||
| LocutusOfBorg1 | hi Unit193 | 09:18 |
| LocutusOfBorg1 | can anybody please retry casablanca/wily? | 09:20 |
| LocutusOfBorg1 | thanks | 09:20 |
| xnox | slangasek: congrats on level-up! =) | 09:20 |
| 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:34 |
| 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:35 |
| smoser | pitti, talk to utlemming about it, but they're still getting wily builds going. | 09:40 |
| pitti | smoser: ok, thanks (I pinged him as well); just wanted to make sure that this is known | 09:41 |
| 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:44 |
| 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:45 |
| 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 :) | 09:46 |
| pitti | sil2100: tested with one package: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5060036/+listing-archive-extra | 10:00 |
| pitti | seems to work | 10:01 |
| * pitti scriptifies it | 10:01 | |
| LocutusOfBorg1 | ping, can anybody please retry casablanca? the newer gcc-5 might have fixed the build failure :) | 10:21 |
| pitti | LocutusOfBorg1: done | 10:23 |
| LocutusOfBorg1 | thanks :) | 10:23 |
| LocutusOfBorg1 | https://launchpad.net/ubuntu/+source/casablanca/2.4.0-2/+build/7389439 | 10:33 |
| LocutusOfBorg1 | doko_, ^^^ actually the new libstdc++ and gcc-4.9 makes the build fail | 10:34 |
| 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) | 10:37 |
| cjwatson | pitti: ddebs should be fixed now | 11:10 |
| pitti | cjwatson: \o/ cheers | 11:10 |
| === MacSlow is now known as MacSlow|lunch | ||
| mdeslaur | slangasek: happy birthday! :) | 11:36 |
| === ralsina_ is now known as ralsina | ||
| === MacSlow|lunch is now known as MacSlow | ||
| caribou | Is there a way to be sure that an upstart job terminates before RUNLEVEL is emited ? | 13:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| smoser | in trusty. | 13:58 |
| xnox | smoser: echo "manual" > /etc/init/pollinate.override | 13:59 |
| xnox | smoser: .override is the right extension... | 13:59 |
| smoser | xnox, bah. | 14:01 |
| smoser | thank you very much | 14:01 |
| didrocks | slangasek is spamming wily for his birthday :) | 14:27 |
| didrocks | I guess someone has found the "publish all silos" button | 14:27 |
| seb128 | didrocks, or rather syncing the overlay ppa to wily? | 14:28 |
| seb128 | or pocket copying it over | 14:28 |
| Laney | timely ... | 14:28 |
| didrocks | seb128: I guess you are right | 14:29 |
| 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:34 |
| 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:44 |
| 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:45 |
| mdeslaur | slangasek: hehe | 14:46 |
| pitti | oh dear, the interweb is wrong.. https://xkcd.com/386/ | 14:47 |
| === bdmurray_ is now known as bdmurray | ||
| cjwatson | slangasek: happy 70th birthday, then | 14:50 |
| slangasek | :-) | 14:50 |
| === MacSlow is now known as MacSlow|errand | ||
| === dholbach_ is now known as dholbach | ||
| 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:07 |
| 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:08 |
| slangasek | noted :) | 15:09 |
| 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:10 |
| 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:25 |
| shadeslayer | rbasak: do you reckon docker.io can be backported to utopic? | 15:30 |
| shadeslayer | bah | 15:32 |
| shadeslayer | needs new libdevmapper1.02.1 | 15:32 |
| shadeslayer | :( | 15:32 |
| fginther | utlemming, pitti, yes, thanks | 15:36 |
| === matsubara_ is now known as matsubara | ||
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| shadeslayer | thanks to you too :) | 15:51 |
| 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:52 |
| 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:53 |
| rbasak | shadeslayer: try http://people.canonical.com/~rbasak/docker-wip/docker.io_1.6.0+dfsg1+revendor-0ubuntu0.14.04.1~dev1.dsc | 15:56 |
| rbasak | That embeds the build deps, which is no longer the plan, but I think it builds OK on Trusty. | 15:57 |
| shadeslayer | rbasak: trying, though this is on utopic | 15:59 |
| rbasak | shadeslayer: I'm not aware of any reason it should fail on Utopic. | 16:00 |
| shadeslayer | ok | 16:00 |
| pitti | stgraber, infinity, kees, slangasek, mdeslaur: TB meeting now, right? | 16:01 |
| mdeslaur | pitti: yep | 16:01 |
| 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:04 |
| ubottu | Debian bug 784726 in src:docker.io "docker.io: CVE-2015-3627 CVE-2015-3629 CVE-2015-3630 CVE-2015-3631" [Grave,Fixed] | 16:04 |
| shadeslayer | oh | 16:05 |
| shadeslayer | hm, thank | 16:05 |
| shadeslayer | *thanks | 16:05 |
| shadeslayer | rbasak: seems to have built, thanks | 16:11 |
| hallyn | infinity: arges: when you talk about SRUing the kvm-on-all-arches bug, is bug 1369785 what you are talking about? | 16:29 |
| ubottu | bug 1369785 in qemu (Ubuntu) "kvm modules not autoloaded on ppc64el" [High,Fix released] https://launchpad.net/bugs/1369785 | 16:29 |
| 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:32 |
| infinity | hallyn: But that autoload bug is also important. | 16:33 |
| infinity | s/kvm package/qemu-kvm package/ | 16:33 |
| 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:34 |
| arges | infinity: so whose responsibility would it be to disable smt? qemu? | 16:35 |
| arges | or the user | 16:35 |
| 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:36 |
| arges | yea | 16:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| hallyn | fun | 16:41 |
| hallyn | ok, thanks, hopefully after ODS i can dig in | 16:41 |
| infinity | Oh, FFS. Thanks, IBM. | 16:41 |
| 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:42 |
| === dpm is now known as dpm-afk | ||
| 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:45 |
| 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:46 |
| 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:49 |
| 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:50 |
| 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:51 |
| infinity | Actually, wait, did we get it right? | 16:52 |
| 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:53 | |
| infinity | Okay, no, it's still not quite right in vivid. :P | 16:56 |
| infinity | And, indeed, with the upstart->systemd switch in vivid, it's actually actively broken on vivid. | 16:58 |
| hallyn | hm, why does pull-lp-source not know about wily yet | 17:02 |
| hallyn | (on my wily laptop) | 17:02 |
| infinity | hallyn: Because you need to upgrade? | 17:11 |
| infinity | hallyn: I'd assume your distro-info-data is out of date. | 17:12 |
| hallyn | hm, i updated yesterday... one more for good measure | 17:16 |
| === Spr0cket- is now known as Spr0cket | ||
| infinity | hallyn: Works for me with distro-info-data 0.27 | 17:27 |
| hallyn | infinity: bah. now it works. but distro-info was last updated on may 10. weird | 17:30 |
| hallyn | oh, well, it works, happy :) | 17:31 |
| === adrian is now known as alvesadrian | ||
| === MacSlow|errand is now known as MacSlow | ||
| jdstrand | bdmurray, arges: hey, I was wondering if someone could look at bug #1450642. I fixed the version issue last week | 17:57 |
| ubottu | bug 1450642 in libseccomp (Ubuntu Vivid) "seccomp missing many new syscalls" [Undecided,In progress] https://launchpad.net/bugs/1450642 | 17:57 |
| === stth is now known as stth_ | ||
| === stth_ is now known as stth__ | ||
| === stth__ is now known as stth | ||
| arges | jdstrand: taking a look | 18:10 |
| arges | jdstrand: so would this be worth backporting to trusty, since we'll be supporting lts-vivid at some point | 18:17 |
| 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:18 |
| 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:22 |
| 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:23 |
| jdstrand | well, the software works-- it is just denied when run under certain seccomp filters (like on snappy) | 18:24 |
| arges | jdstrand: ack. | 18:24 |
| arges | jdstrand: ok accepted into vivid-proposed | 18:25 |
| jdstrand | thanks! | 18:25 |
| infinity | jdstrand: Which kernel headers are available when you build software have no relation to wich syscalls you can use at runtime... | 18:30 |
| 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:31 |
| 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:32 |
| jdstrand | libseccomp's use on trusty is mostly limited to lxc. but they use a blacklist, so it too shouldn't be needed | 18:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| irl | ok, so can you remove the address? | 18:38 |
| infinity | irl: On it. | 18:38 |
| 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:39 |
| infinity | irl: It's removed from his account. We'll discuss blacklisting out of band. | 18:40 |
| irl | ok | 18:41 |
| === kees_ is now known as kees | ||
| speck84 | hiya guys can somebody tell me how can i set my html5 app into portrait mode only? | 20:49 |
| 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:51 |
| speck84 | here are the pro's | 20:52 |
| dobey | speck84: #ubuntu-app-devel is the channel you want i think | 20:57 |
| speck84 | thx dobey but is a back to forward thing they told me to come here | 20:58 |
| 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 | 20:59 |
| 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:01 |
| cjwatson | infinity: I don't believe so, other than syntactic validity. Trying to blacklist lists is probably doomed to failure ... | 21:35 |
| infinity | cjwatson: Perhaps, yes. | 22:26 |
| 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. | 22:28 |
| === doko_ is now known as doko | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!