| pitti | Good morning | 06:01 |
|---|---|---|
| === _salem is now known as salem_ | ||
| === King_InuYasha is now known as Son_Goku | ||
| === sunweaver is now known as IonicBSc | ||
| === IonicBSc is now known as sunweaver | ||
| === salem_ is now known as _salem | ||
| Bluefoxicy | awesome | 11:44 |
| Bluefoxicy | vendor incompatibilities and fragmentation | 11:44 |
| * Bluefoxicy manually edits /etc/libvirt/qemu/*.xml because 16.10 breaks thanks to a machine type of "pc-i440fx-vivid" instead of just "pc" | 11:45 | |
| sarnold | Bluefoxicy: please talk with cpaelzer if something feels wrong; he's put a lot of effort into making libvirt nice, including some machine type changes | 11:49 |
| sarnold | Bluefoxicy: oh, I'm sorry, it's Christian Ehrhardt | 11:51 |
| sarnold | Bluefoxicy: see e.g. https://lists.ubuntu.com/archives/ubuntu-server/2016-September/007411.html | 11:52 |
| Bluefoxicy | sarnold: nice | 11:59 |
| Bluefoxicy | sarnold: the problem with all that is eventually they apparently drop support for machine types, so a machine created 5 releases ago suddenly stops working unless you tinker with it. There's nothing that says, "Oh, it's like 3 releases back; should we change it to -xenial?" | 12:03 |
| Bluefoxicy | then you get to -yak and it's dropped -vivid and it goes "OMG WHAT IS THIS?!" | 12:03 |
| Bluefoxicy | I'll have to file a bug or raise this on the devel-discuss list for further comment | 12:04 |
| rbasak | Bluefoxicy: FYI cpaelzer is out today and tomorrow so I expect he may not reply until Monday. | 12:18 |
| rbasak | Bluefoxicy: but please do raise your concerns on the thread. Feedback appreciated. | 12:19 |
| Bluefoxicy | rbasak: I might need to use gmane or something to respond to that thread on ubuntu-server since i'm not subscribed | 12:20 |
| Bluefoxicy | "We're going through a complete rebuild, so some things are very broken. Please see our blog at http://home.gmane.org/ for news." XD | 12:21 |
| coreycb | rbasak, hello, would you by any chance be able to accept nova 2:13.1.1-0ubuntu1.1 into xenial-updates? bug 1608934 | 12:21 |
| ubottu | bug 1608934 in nova (Ubuntu Xenial) "ephemeral/swap disk creation fails for local storage with image type raw/lvm" [High,Fix committed] https://launchpad.net/bugs/1608934 | 12:21 |
| Bluefoxicy | anyway, I have to go to what is allegedly "work" now | 12:21 |
| Bluefoxicy | so I'll do that later, after I finish reading web comics for 8 hours. | 12:21 |
| sarnold | Bluefoxicy: actually it's probably sad news about gmane :( https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ | 12:23 |
| rbasak | Bluefoxicy: I moderate the list fairly regularly so that shouldn't be a problem - I can let it through. I can also add you to the whitelist when I do that. | 12:39 |
| rbasak | Bluefoxicy: in general, if you don't want to subscribe to a mailman list but post to it, you can subscribe and immediately disable deliveries. Then you don't hit moderation even if it's subscriber-only. No need for ubuntu-server though. | 12:40 |
| rbasak | coreycb: I don't have the powers yet. Sorry! | 12:40 |
| coreycb | rbasak, np :) | 12:41 |
| rbasak | gmane> :-( | 12:41 |
| coreycb | pitti, hello, would you by any chance be able to accept nova 2:13.1.1-0ubuntu1.1 into xenial-updates? bug 1608934 | 12:41 |
| ubottu | bug 1608934 in nova (Ubuntu Xenial) "ephemeral/swap disk creation fails for local storage with image type raw/lvm" [High,Fix committed] https://launchpad.net/bugs/1608934 | 12:41 |
| pitti | coreycb: not right now; can do another SRU shift tonight, but if it's urgent please ask around for others | 12:42 |
| coreycb | pitti, it's not urgent, later would be fine | 12:42 |
| xnox | Laney, http://baturin.org/docs/iproute2/#Delete a link | 13:04 |
| smoser | nacc, fixing | 13:26 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| TheMuso | Anybody have any idea why sbuild is slow for me? I'm using directory based chroots with overlay fs and have both tmpfs and disk based overlay chroots set up. Sbuild takes ages to start downloading deps and building... This on yakkety. | 13:38 |
| sarnold | 'ages to start' sounds vaguely like dns; there's six second delays if there's failures talking to dns servers in /etc/resolv.conf | 13:39 |
| smoser | TheMuso, i've seen similar behavior | 13:40 |
| TheMuso | Nope, not that. I have the same problem at home on another box. Sbuild used to be rather quick in processing build deps required and downloading/buidling. | 13:40 |
| smoser | not debugged. i suspected kernel upgrade. :-( | 13:40 |
| smoser | it seems really slow on yakkety. | 13:40 |
| TheMuso | smoser: Hrm possible... I think I saw it ona 4.4 kernel, but don't have that kernel here to test with. Something to test when xenial has 4.8 I suspect. | 13:40 |
| smoser | although i can't rule out sarnold's suggestion. | 13:40 |
| pitti | TheMuso: archive.u.c. seems quite loaded these days, I also get long hangs tryign to download Pacakges.gz or debs (after DNS resolution) | 13:41 |
| TheMuso | pitti: This is before even starting to download deps, and when at home, I use a mirror in Australia. | 13:41 |
| smoser | i dont think its archive related. | 13:41 |
| smoser | yeah. | 13:41 |
| pitti | well, I wrote it off as post-release slowness; maybe it indeed is something else | 13:41 |
| smoser | sarnold's suggestion seems plausible to me | 13:41 |
| smoser | with addition / usage of systemd-resolvd | 13:42 |
| TheMuso | Well, I am here at the sprint using archive.conference... and its still slow. | 13:42 |
| pitti | the other day I had three dozen dnsmasq instances spawned by NM which made DNS slow -- can you check? | 13:42 |
| TheMuso | i.e I changed my chroots to use archive.conference directly. | 13:42 |
| sarnold | 12 packets transmitted, 8 received, 33% packet loss, time 11041ms | 13:42 |
| sarnold | ow | 13:42 |
| TheMuso | Still one instance. | 13:42 |
| * sarnold hugs mosh | 13:42 | |
| TheMuso | i.e only one instance of dnsmasq. | 13:43 |
| TheMuso | I don't *think* its network, unless sbuild does a lot of network stuff at the beginning while its working out deps to download. | 13:44 |
| TheMuso | And I think its not even schroot created, because I can update my chroots just as quickly as I have been able to in the past. | 13:45 |
| TheMuso | related* | 13:45 |
| TheMuso | Anyway, I *may* have a 4.4 kernel on my yakkety install at home, so will check when I get back and test if so. | 13:45 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| pitti | TheMuso: oh right -- when I start sbuild, my load goes up to 50; might be another fallout of bug 1626436 | 14:27 |
| ubottu | bug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Medium,Triaged] https://launchpad.net/bugs/1626436 | 14:27 |
| === lucas_ is now known as lucas | ||
| smoser | pitti, around ? | 15:48 |
| smoser | https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=ifupdown | 15:48 |
| smoser | what shal i do about that ? i can just upload it to zesty.. | 15:49 |
| pitti | smoser: yeah, sounds better now; we have a new gcc, binutils etc, and zesty is fully open | 15:50 |
| pitti | so we shouldn't do binary copies any more at this point (just for the 0-day ones) | 15:50 |
| smoser | pitti, then go ahead and NACKK that | 15:53 |
| pitti | smoser: why that? the fix is good? | 15:54 |
| smoser | becuse i would update the ubuntu3 to zesty | 15:55 |
| smoser | so the one in yakket-proposed need to have version adjusted | 15:55 |
| smoser | no ? | 15:55 |
| pitti | smoser: or just upload to zesty as ubuntu4? | 15:56 |
| pitti | smoser: I mean, I'm fine with rejecting if you prefer "nicer" version numbers, but I don't think it's a requirement | 15:57 |
| * pitti needs to go AFK for a bit | 15:57 | |
| smoser | pitti, thats fine too. | 16:02 |
| smoser | i'll upload as ubuntu4 "no change rebuild" ? | 16:02 |
| pitti | smoser: or "* upload to zesty" (and use -v to include the previous record) | 16:10 |
| smoser | pitti, i dont understnd that. i need the new version, right? | 16:11 |
| nacc | rbasak: do we want upload/ tags to be annotated to the developer or the uploader? | 16:18 |
| sinzui | hallyn: Do you have any sight into this lxc1 error on s390x? https://pastebin.canonical.com/168526/ | 16:22 |
| rbasak | nacc: the person running the importer, I think. | 16:33 |
| rbasak | Since it's both a confirmation of the version but also how it was done. | 16:33 |
| sinzui | stgraber: ^ mayeb you have insight into https://pastebin.canonical.com/168526/ | 16:33 |
| rbasak | Whereas a commit tries to be exactly what the person uploaded. | 16:33 |
| stgraber | sinzui: you shouldn't use pastebin.canonical.com for public pastes | 16:35 |
| nacc | rbasak: ack, the upload tag itself is created outside the importer, though | 16:35 |
| nacc | rbasak: import tags will be annotated to the user running the importer, to be clear | 16:35 |
| nacc | rbasak: but upload tags are part of the review process now, in theory | 16:35 |
| sinzui | stgraber: sorry, the paste has circulated. I can redo in ubuntu. nothing secret in it | 16:35 |
| stgraber | sinzui: if you want hallyn to be able to see it, you'd have to since he's not at Canonical anymore :) | 16:36 |
| stgraber | sinzui: anyway, that error usually comes from lack of seccomp support in the kernel | 16:36 |
| sinzui | stgraber: well that aligns with the fact we got a new kernel | 16:36 |
| sinzui | stgraber: do you recommend I look for a downgrade? | 16:37 |
| stgraber | sinzui: I'm looking at something real quick, it could be that this is caused by LXC 2.0.5 now supporting seccomp on s390x | 16:38 |
| stgraber | just confirming that it's indeed something that was "fixed" in 2.0.5 (lack of seccomp support on s390x) which could cause this regression | 16:38 |
| sinzui | stgraber: 2.0.5-0ubuntu1~ubuntu16.04.1 was installed recently | 16:38 |
| stgraber | sinzui: right, confirmed that s390x seccomp support was added to LXC 2.0.5, previous one was skipping seccomp entirely which would explain why it was working | 16:39 |
| stgraber | sinzui: checking when s390x seccomp support was added to the kernel, to see if it's just a missing config in our kernel that'd fix that cleanly or if we'd need it backported to 4.4 which would be a bit more annoying | 16:40 |
| stgraber | hmm, that was the 3.6 kernel supposedly, so a bit confused as to why we wouldn't have it in our 4.4 | 16:41 |
| stgraber | sinzui: config-4.4.0-45-generic is what you're running right? | 16:42 |
| stgraber | hmm, so I see it enabled in that kernel, not sure what's going on then | 16:43 |
| sinzui | stgraber uname-a says 4.4.0-45-generic | 16:43 |
| stgraber | ok, let me reboot my s390x system to run on that kernel and LXC and see what's going on | 16:43 |
| stgraber | sinzui: reproduced the issue here | 16:46 |
| sinzui | I suppose I could cheer | 16:47 |
| stgraber | sinzui: you can workaround it by putting a file with lxc.seccomp= in /usr/share/lxc/config/common.conf.d/, that should get you going again | 16:48 |
| sinzui | stgraber: I will try | 16:48 |
| stgraber | sinzui: got one of my guys looking at it now | 16:49 |
| sinzui | thank you stgraber : have a working container. I will let the build scripts try to do the same | 16:51 |
| stgraber | obviously once we sort it out, it'll be good to remove that file as seccomp is a useful security feature | 16:52 |
| stgraber | but since 2.0.4 didn't support it at all, it's no worse at least :) | 16:52 |
| smoser | Subject: [ubuntu/zesty-proposed] ifupdown 0.8.13ubuntu4 (Waiting for approval) | 16:54 |
| smoser | is that by design ? | 16:54 |
| smoser | "waiting for approval" | 16:55 |
| stgraber | smoser: see topic, not open yet | 17:02 |
| smoser | fudge. | 17:03 |
| smoser | well, i have two waitin for approval. | 17:04 |
| stgraber | slangasek: looks like LP is returning those OOPS right now, turned off cron | 17:29 |
| stgraber | slangasek: trying to get an LP URL from import-images | 17:29 |
| stgraber | slangasek: ok, so LP does return a 500, so someone will need to fix the importer to properly detect and deal with those, since apparently urlretrieve doesn't trigger an exception on those | 17:33 |
| stgraber | slangasek: the URL that's failing to import is https://git.launchpad.net/~device-release/turbo/+git/device_tarball/plain/device.tar.xz?h=candidate | 17:33 |
| stgraber | sil2100: FYI ^ | 17:33 |
| stgraber | so current state is cron disabled and sil2100's e-mail address marked as the target for cron mail when re-enabled | 17:34 |
| * stgraber gets back to being off | 17:35 | |
| nacc | slangasek: have a quick q for you re: a package in 16.04 that was technically unmaintained upstream at the time (mkstutil). There is LP: #1568714 for it, and a fix provided. However, that fix is not what upstream did (because upstream removed the feature completely (https://sourceforge.net/p/msktutil/code/ci/19066f9777a19b6fda8c62e7774b4bb2157eb32a/)). I feel like there are three options: 1) SRU the | 17:35 |
| ubottu | Launchpad bug 1568714 in msktutil (Ubuntu Xenial) "stack smashing detected ***: msktutil terminated for version 0.5.1+git8158aa2b-1" [Undecided,New] https://launchpad.net/bugs/1568714 | 17:35 |
| nacc | maintained version from yakkety back to xenial; 2) just take the submitted patch, although it's not identical to upstream's changes, as it has been tested to fix the issue; 3) backport the upstream fix, but that changes the supported features for the package (even if the supported feature was arguably buggy per upstream). | 17:35 |
| nacc | slangasek: not urgent to provide input, but any advice you could give on which would be preferred would be appreciate it | 17:35 |
| stgraber | sinzui: status update is that it's not a LXC or kernel bug, xenial's libseccomp was patched to add s390x support but apparently incorrectly so, so LXC detects support, uses it but then the library fails to set things up somehow. We're still digging and will most likely send a SRU for libseccomp in xenial | 17:39 |
| koike | cjwatson, hey, you are one of the grub2 maintainers right? In debian we need to create a monolithc version of grub in the arquives to be able to sign it with all its modules, is it ok if I change the packages like grub-efi-amd64-bin_2.02~beta3-1_amd64.deb to build a monolithic version of grub? Or maybe to create something like grub-efi-monolithic-amd64-bin_2.02~beta3-1_amd64.deb ? | 17:40 |
| koike | cjwatson, so I would like your opinion about the solution before I start working on it | 17:49 |
| slangasek | stgraber: AFAICS the HTTP code isn't even returned at all by urlretrieve(), I don't see it as part of the returned headers struct | 17:55 |
| slangasek | nacc: was this upstream feature usable at all, or was it completely broken by the above bug? | 17:56 |
| nacc | slangasek: it's hard to say; the above bug is a stack smash that makes the tool itself unusable regarldess of the feature (ldaps + tls). It seems like the upstream feature (ldaps + tls) never worked, though. | 17:57 |
| slangasek | nacc: I don't object to an SRU that removes a broken and unusable feature in order to leave the package usable for other purposes. I would object to an SRU removing a feature that might be broken for some people in some circumstances, but usable in others | 17:58 |
| nacc | slangasek: ack, that makes sense, i'll do some more examination | 17:59 |
| sinzui | stgraber: Is there a bug I can track so that I know when to remove my hack? | 18:08 |
| stgraber | sinzui: we'll file one on LP once we're sure where the problem is | 18:18 |
| stgraber | slangasek: right, but my (clearly wrong) expectation was that it'd raise an exception as it does for the other error cases (timeouts and such) | 18:18 |
| smoser | why does this not work? | 18:43 |
| smoser | 18:43 | |
| smoser | # hostnamectl status | 18:43 |
| smoser | in a container doesnt work. | 18:44 |
| smoser | horay | 18:44 |
| stgraber | smoser: looks like a systemd thing | 18:50 |
| stgraber | Oct 20 18:49:36 yak systemd[6322]: systemd-hostnamed.service: Failed at step NETWORK spawning /lib/systemd/systemd-hostnamed: Permission denied | 18:50 |
| stgraber | [62189.667647] audit: type=1400 audit(1476989376.082:576): apparmor="DENIED" operation="file_lock" profile="lxd-yak_</var/lib/lxd>" pid=19491 comm="(ostnamed)" family="unix" sock_type="dgram" protocol=0 addr=none | 18:50 |
| stgraber | so maybe an apparmor bug actually because I can't think of why our profile would block this | 18:51 |
| jgrimm | stgraber, smoser: confirmed xenial container behaves that way. trusty container worked tho | 18:54 |
| stgraber | jgrimm: would make sense since trusty wasn't using systemd | 18:55 |
| jgrimm | yep | 18:55 |
| stgraber | jgrimm: running hostnamed directly by hand works fine too | 18:55 |
| smoser | stgraber, running hostnamed ? | 18:56 |
| stgraber | smoser: in a shell, run "/lib/systemd/systemd-hostnamed", in another, run hostnamectl :) | 18:56 |
| slangasek | xnox: yay, new jitsi is dep-wait ;) | 18:58 |
| smoser | what a pit | 18:59 |
| smoser | pita | 18:59 |
| pitti | smoser: yes, but use -v...ubuntu2 to include the ubuntu3 revision to | 19:12 |
| smoser | pitti, i did. thanks | 19:13 |
| * pitti goes for a round of SRU review | 19:27 | |
| pitti | cyphermox: so your initramfs-tools 0.125ubuntu6.1 in the unapproved queue refers to bug 1631474 which is already closed (fixed by the previous SRU) | 19:41 |
| ubottu | bug 1631474 in initramfs-tools (Ubuntu Zesty) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [High,Fix committed] https://launchpad.net/bugs/1631474 | 19:41 |
| pitti | cyphermox: typoed the bug #? if the reversion should use the same bug, can you please reopen and adjust the description? | 19:41 |
| cjwatson | koike: no, don't do that, I'll be switching on the Ubuntu patch set to implement signed GRUB builds as soon as Debian has the necessary signing implementation in place; you'd be wasting your time working on it since it's already implemented | 22:08 |
| koike | cjwatson, but in Ubuntu the grub2 package doesn't publish a monolithic version, does it? To make grub-signed build reproducible we need this available, so grub-signed can depend on it | 22:10 |
| cjwatson | koike: yes it does, debian/build-efi-images produces that as a custom upload | 22:11 |
| cjwatson | koike: I'm not going to add another binary package, it's already complicated enough! | 22:11 |
| cjwatson | koike: we shouldn't need another binary package for reproducibility, we just need grub-mkimage's output to be reproducible given the same inputs | 22:12 |
| cjwatson | koike: which if it's not the case today shouldn't be far off | 22:13 |
| cjwatson | koike: I'm totally happy to take patches to improve reproducibility BTW, I think that's an excellent goal, just want to make direction clear | 22:15 |
| koike | cjwatson, sure, thanks for your feedback, I am checking some other things that I am not entirely sure about, I'll also get some opinion at #debian-efi too | 22:17 |
| cjwatson | koike: the other thing I want to do is integrate Mathieu's Ubuntu patches for better MOK integration, which I think can be done in Debian as well now and would make it possible to require signed kernels | 22:18 |
| cjwatson | but ETIME | 22:18 |
| koike | cjwatson, I see, ETIME is a problem indeed. Could you send me a link to these patches (I am having some trouble finding them) | 22:24 |
| cjwatson | koike: I think they're in people/cyphermox/<somethingorother> in the Debian git repository, though not sure if they're up to date; the current Ubuntu source package can be found at https://launchpad.net/ubuntu/+source/grub2 | 22:26 |
| cjwatson | I'm hoping I can nag cyphermox into submitting them in a form I can easily apply :) | 22:26 |
| cjwatson | (possibly simpler after rebasing on 2.02~beta3-1) | 22:26 |
| cyphermox | there is that | 22:27 |
| cyphermox | you mean the patches for the new shim filenames? | 22:27 |
| cjwatson | cyphermox: I meant the whole mokutil workflow with the extra debconf questions and such | 22:27 |
| cyphermox | ah, ok | 22:27 |
| cyphermox | that's removed from grub, actually. here's hoping there isn't anything left | 22:28 |
| cyphermox | all moved to shim-signed | 22:28 |
| cjwatson | and obviously anything else that seems relevant, I'd like to get back in sync but of course with cherry-picked patches and such it's a fair bit of source to compare | 22:28 |
| cyphermox | if beta3 is ready in the git branch I can get you the other patches ready | 22:29 |
| cjwatson | cyphermox: it's in unstable, though indeed in git too | 22:29 |
| cyphermox | ok, I hadn't noticed, been busy with other things | 22:30 |
| cyphermox | I'll want to get beta3 in zesty anyway though | 22:30 |
| === salem_ is now known as _salem | ||
| nacc | is it a known bug in `apt-get changelog that when a source package lives in main but has binaries published in universe (e.g., qemu), it tries to load a changelog from universe? | 22:43 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| nacc | I noticed just now that there is a 'new' -u option for rmadison to look at the debian new queue. Is the ubuntu new queue exposed similarly? | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!