| -queuebot:#ubuntu-release- Unapproved: snap-confine (xenial-proposed/main) [1.0.38-0ubuntu0.16.04.10 => 1.0.41-0ubuntu2~16.04.1] (no packageset) | 01:03 | |
| -queuebot:#ubuntu-release- New sync: gnome-2048 (yakkety-proposed/primary) [3.22.0-1] | 04:30 | |
| === cpaelzer_ is now known as cpaelzer | ||
| flocculant | infinity: Xubuntu have an issue with coming back from suspend - it appears to unlock, but then we're stuck with a blank screen and seemingly only way is to stop and start lightdm, we will not be releasing Final Beta in that state (unlikely anything to fix it will happen in a day and a bit) bug 1622303 | 05:48 |
|---|---|---|
| ubot5` | bug 1622303 in light-locker (Ubuntu) "Fails to unlock/ resume to black screen" [Undecided,Confirmed] https://launchpad.net/bugs/1622303 | 05:48 |
| flocculant | s/suspend/suspend or lock | 06:58 |
| sil2100 | slangasek: thanks for the zeromq3 changes! Will forward them to the snapshot part and then upstream, as you said | 08:03 |
| -queuebot:#ubuntu-release- New source: wine (yakkety-proposed/primary) [1.8.4-1ubuntu1] | 08:24 | |
| -queuebot:#ubuntu-release- New binary: plasma-discover [amd64] (yakkety-proposed/universe) [5.7.5-0ubuntu1] (kubuntu) | 08:54 | |
| -queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] (20160921) has been added | 09:10 | |
| -queuebot:#ubuntu-release- Builds: Lubuntu Alternate powerpc [Yakkety Beta 2] (20160921) has been added | 09:10 | |
| -queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Beta 2] (20160921) has been added | 09:10 | |
| infinity | flocculant: I'd like you to participate in the Beta all the same. Maybe we can get it fixed in time, maybe not, but the more testing you can do, even if you don't release with the milestone, the better shape we'll be in to figure out how to move forward for release. | 09:13 |
| -queuebot:#ubuntu-release- Unapproved: dovecot (xenial-proposed/main) [1:2.2.22-1ubuntu2 => 1:2.2.22-1ubuntu2.1] (ubuntu-server) | 09:33 | |
| seb128 | hum | 09:34 |
| seb128 | https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule was listing beta freeze for the 22th | 09:34 |
| seb128 | that's tomorrow not today | 09:34 |
| -queuebot:#ubuntu-release- Unapproved: gnat (yakkety-proposed/universe) [6.1ubuntu1 => 6.1ubuntu2] (no packageset) | 09:41 | |
| infinity | seb128: Beta is the 22nd, freeze is before. | 09:51 |
| seb128 | the wiki table is confusing then | 09:51 |
| infinity | seb128: It probably should have had a (Tues) on it. | 09:51 |
| seb128 | yeah | 09:51 |
| infinity | The wiki table is indeed confusing. | 09:51 |
| infinity | Anyhow, we have yet another kernel (and, thus, a respin) coming, so if you had something that should make the ISOs, you're probably in luck. | 09:52 |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] (20160921) has been added | 09:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] (20160921) has been added | 09:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] (20160921) has been added | 09:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Beta 2] (20160921) has been added | 09:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] (20160921) has been added | 09:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] (20160921) has been added | 09:57 | |
| seb128 | the unity8 session? ;-) | 09:57 |
| seb128 | there are still MIRs behing reviewed so that's probably for after beta now... | 09:58 |
| seb128 | which is a bit crazy | 09:58 |
| infinity | seb128: Well, it's not the default session, so it's not as crazy as it could be. :P | 10:01 |
| seb128 | that's a good way to look at it ;-) | 10:01 |
| Laney | [FFe] Switch default session to Unity 8 for 16.10 | 10:04 |
| Laney | Oops, meant to type that into Launchpad. | 10:04 |
| infinity | Laney: DENIED. | 10:04 |
| -queuebot:#ubuntu-release- Unapproved: accepted gnat [source] (yakkety-proposed) [6.1ubuntu2] | 10:07 | |
| shadeslayer | infinity: yeah table is indeed confusing, I thought the freeze was tomorrow and uploaded Plasma 5.7.5 | 10:17 |
| shadeslayer | so I think Kubuntu will probably require a respin too | 10:18 |
| === jamespag` is now known as jamespage | ||
| -queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3~rc4ubuntu1 => 1.3] (core) (sync) | 10:23 | |
| -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Yakkety Beta 2] (20160921) has been added | 10:41 | |
| -queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Yakkety Beta 2] (20160921) has been added | 10:41 | |
| davmor2 | infinity: oh you're about did you move or do you just not sleep? | 10:45 |
| Laney | Well | 10:45 |
| Laney | laney@snakefruit:~$ /home/ubuntu-archive/bin/chdist apt-cache yakkety-proposed-amd64 show unity8-desktop-session | grep-dctrl -s Package,Task . | 10:45 |
| apw | davmor2, he is in and out i think | 10:45 |
| Laney | Package: unity8-desktop-session | 10:45 |
| Laney | Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb | 10:45 |
| Laney | That wasn't supposed to happen | 10:45 |
| Laney | seb128: ^- I think that it needs to be undone | 10:46 |
| davmor2 | infinity: can you add netboot when you are in again please to the final beta I'll hit it now and mark it up after. | 10:46 |
| seb128 | Laney, it's only a recommends is that going to create any issue? | 10:46 |
| infinity | davmor2: There'll be a new netboot sometime later today. Better to focus your current testing on ISOs, if you could, since they usually require more pain to fix when you find bugs. :P | 10:46 |
| Laney | it's going to try to install everything with Task: ubuntu-desktop | 10:46 |
| seb128 | did we do the change wrong or why is that an issue? | 10:47 |
| seb128 | Steve said we should do that and it shouldn't create problems for the iso build | 10:47 |
| Laney | I thought it would be ignored for task generation but it's not | 10:47 |
| infinity | Of course it's not ignored for task generation. | 10:48 |
| infinity | But what's the intent here? | 10:48 |
| davmor2 | infinity: like I'm going to find bugs, I'll see if hardware detection is working today or not ;) | 10:48 |
| Laney | Why is it of course? | 10:48 |
| Laney | To get component-mismatches to show the state | 10:48 |
| Laney | But not to make an unbuildable image | 10:48 |
| infinity | Laney: It's not unbuildable. | 10:48 |
| infinity | Laney: Why would it be? | 10:49 |
| infinity | Laney: Think it through. If the images were built with all components, it would work fine. If they're not (and they're not), it'll still work fine, since we can't read task headers we don't have. | 10:50 |
| Laney | Ok | 10:50 |
| Laney | I thought that the part that made the list had all components enabled | 10:50 |
| -queuebot:#ubuntu-release- Unapproved: dbus-test-runner (yakkety-proposed/universe) [15.04.0+15.10.20151002-0ubuntu1 => 15.04.0+16.10.20160906-0ubuntu1] (no packageset) (sync) | 10:50 | |
| infinity | Of course, having stuff in task: ubuntu-desktop and in universe is sick and wrong and needs fixing ASAP, but it won't affect the current images. | 10:50 |
| -queuebot:#ubuntu-release- Unapproved: unity8-desktop-session (yakkety-proposed/universe) [1.0.13+16.10.20160809-0ubuntu1 => 1.0.13+16.10.20160919-0ubuntu1] (no packageset) (sync) | 10:50 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dbus-test-runner [sync] (yakkety-proposed) [15.04.0+16.10.20160906-0ubuntu1] | 10:52 | |
| -queuebot:#ubuntu-release- Unapproved: accepted unity8-desktop-session [sync] (yakkety-proposed) [1.0.13+16.10.20160919-0ubuntu1] | 10:52 | |
| shadeslayer | infinity: is it alright if I upload Frameworks 5.26 too? it's been tested by the kubuntu devs for a week or so now | 10:56 |
| infinity | shadeslayer: You can upload whatever you like. It'll get stuck in a queue for review anyway. :P | 10:56 |
| shadeslayer | infinity: heh ok :D | 10:57 |
| infinity | shadeslayer: But yeah, if the implication is that your beta is pointless without this stuff, get it in. | 10:57 |
| shadeslayer | infinity: yeah, the idea is to have the latest bugfix of things in | 10:58 |
| shadeslayer | infinity: can you also accept Plasma 5.7.5 ? | 10:58 |
| shadeslayer | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 10:58 |
| shadeslayer | I can give you a list of things to accept | 10:58 |
| infinity | shadeslayer: A bunch of it isn't even built yet. | 10:59 |
| flocculant | infinity: of course :) | 10:59 |
| shadeslayer | infinity: right, when its done I meant :) | 10:59 |
| shadeslayer | infinity: http://paste.ubuntu.com/23210986/ | 10:59 |
| shadeslayer | is what I have | 11:00 |
| cjwatson | Laney: It depends how germinate is run. The germinate run that builds Task headers in the archive has all components enabled. The germinate run that happens as part of image builds doesn't necessarily (depends on flavour). | 11:00 |
| infinity | cjwatson: Less about germinate in this case, actually, and more about which components are enabled in the chroot when livecd-rootfs builds the task install list. | 11:01 |
| Laney | It does something like apt-cache dumpavail | grep-dctrl <stuff> IIRC | 11:02 |
| Laney | With an amazing number of backslashes | 11:02 |
| infinity | All the backslashes. | 11:02 |
| infinity | But yeah, point stands that if all components were enabled, it would work, and if they weren't, it would still work. ;) | 11:02 |
| infinity | Cause it can't read task headers it doesn't have. | 11:02 |
| cjwatson | infinity: Well, yeah, those two things have to be in sync or weird stuff will happen. | 11:03 |
| infinity | shadeslayer: Uhh, this plasma-discover upload is insane. :P | 11:03 |
| infinity | shadeslayer: Transitional packages with no dependencies are exactly 100% useless. | 11:03 |
| cjwatson | Incidentally the older I get the more I think tasks were probably a mistake. | 11:03 |
| * shadeslayer looks | 11:04 | |
| Laney | Well I misremembered that the grep-dctrl was happening outside the chroot to catch this kind of thing and make image builds fail | 11:04 |
| Laney | cjwatson: Do tell | 11:04 |
| cjwatson | We wanted them for auto-install marking I think, but they're arguably counterproductive for that. | 11:04 |
| infinity | shadeslayer: The real problem is that where plasma-discover "Breaks: plasma-discover-private, plasma-discover-updater", that should be a Conflicts. | 11:04 |
| cjwatson | And they're actively painful for point releases. | 11:04 |
| shadeslayer | infinity: looking into it | 11:05 |
| cjwatson | (Due to it being impossible to remove Task headers from the release suite) | 11:05 |
| infinity | shadeslayer: Package frontends will read Conflict/Replaces (the pair together) as "bump off these packages in favour of the new one". | 11:05 |
| shadeslayer | indeed thosse can be dropped | 11:05 |
| cjwatson | If I were doing it again I'd probably just use metapackages throughout; and it might be worth attempting to switch to those. | 11:05 |
| infinity | shadeslayer: Though, if plasma-discover itself wasn't on the system before, then keeping breaks/replaces as is, but making the transitional packages actually depend on plasma-discover is the better option. :P | 11:05 |
| shadeslayer | let me check other places | 11:05 |
| infinity | cjwatson: Yeah, I've been edging in that direction. The problem with metapackages is the unwieldly amount of hinting one needs in the image build process because not all flavours are the same. | 11:06 |
| -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Yakkety Beta 2] (20160921) has been added | 11:06 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Yakkety Beta 2] (20160921) has been added | 11:06 | |
| shadeslayer | well, one would not install plasma-discover-private by it's own tbh | 11:06 |
| infinity | cjwatson: But, as you note, I need to do that for point releases anyway, so... | 11:06 |
| cjwatson | And I think that would probably be easier if we didn't have to fix quite so many mistakes post-release. | 11:07 |
| cjwatson | Tasks let us do a bit more hinting at the seed level, but all that needs to be at least somewhat in sync with apt's behaviour anyway. | 11:07 |
| cjwatson | And it's just all too complex to understand. | 11:07 |
| infinity | cjwatson: The hinting will always be necessary, since one can't divine how to resolve all alt deps, and each flavour has a preference that can't be codified in the dpkg deps. | 11:07 |
| cjwatson | Right, but that could possibly just live in the metapackage. | 11:08 |
| cjwatson | Maybe. | 11:08 |
| infinity | cjwatson: But yeah, not sure how to really make "apt-get install task" and "apt-get install task^" match. Would be nice. | 11:08 |
| infinity | Perhaps a re-engineering of the whole mess would be in order if anyone had that magic time thing. | 11:08 |
| cjwatson | Since apt will install all the immediate deps of the metapackage first and then try to fix broken deps after that, I think. | 11:08 |
| infinity | It will, more or less. That's essentially how my hinting works. | 11:09 |
| cjwatson | s/will install/will mark for install/ | 11:09 |
| infinity | I hint some + and some - (dep and conflict, I guess), then everything else. | 11:09 |
| infinity | Most of the hints can be expressed negatively, which is slightly more elegant for image builds, but doesn't work at all for metapackages, since we then can't install two flavours at once. | 11:10 |
| cjwatson | I certainly wouldn't rule out that some packages might have to be fixed/reengineered/whatever. | 11:10 |
| infinity | Yeah. | 11:10 |
| cjwatson | But I think it might be worth it for eliminating a bit of the image build process that like three people understand. | 11:10 |
| infinity | I don't like what installing tasks does for autoremove. | 11:10 |
| infinity | That's my biggest complaint. | 11:11 |
| acheronuk | shadeslayer: I would not install plasma-discover at all. It's a POS | 11:11 |
| infinity | People get a bunch of library cruft from installing with our live images. | 11:11 |
| infinity | acheronuk: Not a helpful statement. | 11:11 |
| cjwatson | The original idea was that apt would remember that you'd installed the task, but AFAIK that never happened. | 11:11 |
| cjwatson | I mean specifically the task rather than all its pieces. | 11:12 |
| infinity | cjwatson: It might have. We stopped using apt's task install feature. | 11:12 |
| infinity | cjwatson: You converted it to evil. | 11:12 |
| acheronuk | shadeslayer: santa_ was trying to sort dist-upgrade issues on discover with his changes | 11:12 |
| cjwatson | Indeed. | 11:12 |
| acheronuk | infinity: sorry | 11:13 |
| cjwatson | But I think auto-marking didn't work right even before that. | 11:13 |
| acheronuk | discover is just a pain at the best of times :/ | 11:13 |
| infinity | cjwatson: Yeah, I'm pretty sure you're right. | 11:14 |
| shadeslayer | acheronuk: that's not the issue here | 11:14 |
| infinity | cjwatson: Cause I think I introduced my linux-headers unmarking hack before you perpetrated your evil. I think. | 11:14 |
| -queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3~rc4ubuntu1 => 1.3] (core) (sync) | 11:14 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Beta 2] (20160921) has been added | 11:22 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Beta 2] (20160921) has been added | 11:22 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Yakkety Beta 2] (20160921) has been added | 11:23 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Yakkety Beta 2] (20160921) has been added | 11:23 | |
| xnox | infinity, so we will have kernel respin of the world for final beta? | 11:25 |
| xnox | 474 & 4.8.0-11.12 is no good on s390x =/ | 11:26 |
| mardy | pitti: I need an archive admin to get approval on a package, do you have some time? | 11:26 |
| infinity | xnox: Yes. Your s390x fix is working through the sausage factory. | 11:26 |
| xnox | win =) | 11:26 |
| xnox | i'll get the ketchup ready | 11:26 |
| Laney | Sounds like there's a sausage party coming up | 11:27 |
| -queuebot:#ubuntu-release- Unapproved: rejected apt [sync] (yakkety-proposed) [1.3] | 11:28 | |
| mardy | seb128: or do you? (5 lineas up ^) | 11:28 |
| seb128 | mardy, you should share the secret package name that needs review ;-) | 11:31 |
| infinity | seb128: That takes half the fun out of it. | 11:32 |
| mardy | seb128: the request is "please do binNEW pre-review on the account-plugin-mcloud binary package in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+sourcepub/6844940/+listing-archive-extra" (no idea what that means :-) ) | 11:32 |
| seb128 | mardy, let me look | 11:33 |
| seb128 | mardy, the packaging looks fine but you would need a FFe to land that new feature in yakkety | 11:36 |
| mardy | seb128: OK, I'll file it | 11:36 |
| seb128 | thanks | 11:36 |
| -queuebot:#ubuntu-release- New: accepted plasma-discover [amd64] (yakkety-proposed) [5.7.5-0ubuntu1] | 11:36 | |
| seb128 | or just update the bug you used in the changelog to be the ffe | 11:37 |
| seb128 | mardy, ^ | 11:37 |
| -queuebot:#ubuntu-release- Unapproved: accepted apt [sync] (yakkety-proposed) [1.3] | 11:37 | |
| mardy | seb128: oh, good idea | 11:37 |
| -queuebot:#ubuntu-release- Unapproved: blktap-dkms (yakkety-proposed/universe) [2.0.93-0.7ubuntu1 => 2.0.93-0.7ubuntu2] (no packageset) | 11:39 | |
| -queuebot:#ubuntu-release- Unapproved: accepted blktap-dkms [source] (yakkety-proposed) [2.0.93-0.7ubuntu2] | 11:40 | |
| pitti | mardy: re from lunch, seems seb128 already reviewed it? | 11:44 |
| pitti | seb128: FWIW, FFEs for binNEW is mostly just "find an archive admin to review it"; (but doesn't hurt to have a paper trail of course) | 11:45 |
| mardy | pitti: yep, thanks anyway | 11:46 |
| mardy | seb128: added the FFe info to bug 1587282 | 11:47 |
| ubot5` | bug 1587282 in account-plugins (Ubuntu) "create online-account plugin for cmcc mcloud" [Undecided,New] https://launchpad.net/bugs/1587282 | 11:47 |
| seb128 | mardy, thanks | 11:47 |
| -queuebot:#ubuntu-release- Unapproved: gvfs (yakkety-proposed/main) [1.28.2-1ubuntu1 => 1.28.2-1ubuntu2] (ubuntu-desktop) | 11:50 | |
| -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Yakkety Beta 2] (20160921) has been added | 11:59 | |
| -queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Yakkety Beta 2] (20160921) has been added | 11:59 | |
| -queuebot:#ubuntu-release- Unapproved: openjdk-9 (yakkety-proposed/universe) [9~b134-2ubuntu1 => 9~b136-1] (no packageset) (sync) | 12:14 | |
| -queuebot:#ubuntu-release- Unapproved: accepted openjdk-9 [sync] (yakkety-proposed) [9~b136-1] | 12:14 | |
| wxl | infinity: Lubuntu desktop images for final beta are missing | 13:14 |
| davmor2 | infinity: meh still not finding the bcmwl driver for the wifi on the dell xps13 | 13:17 |
| davmor2 | infinity: okay weirder still ubuntu-drivers list show both the intel-microcode and the bcmwl-kernel-source | 13:19 |
| davmor2 | infinity: I am wondering if this is maybe an upstart vs systemd userland issue maybe? | 13:19 |
| lamont | dear kind release team.... I'd really really really like to get 1621615 1229458 and 1621507 into the beta... OTOH, they touch, um, things. | 13:33 |
| lamont | thoughts? kthx | 13:33 |
| apw | bug #1621615 | 13:34 |
| ubot5` | bug 1621615 in cloud-init (Ubuntu) "network not configured when ipv6 netbooted into cloud-init" [Undecided,New] https://launchpad.net/bugs/1621615 | 13:34 |
| lamont | cyphermox: your input on that would be a good thing | 13:34 |
| apw | bug #1229458 | 13:34 |
| ubot5` | bug 1229458 in MAAS "grubnetx64.efi tftp client does not work over ipv6" [High,Confirmed] https://launchpad.net/bugs/1229458 | 13:34 |
| apw | bug #1621507 | 13:34 |
| ubot5` | bug 1621507 in isc-dhcp (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507 | 13:34 |
| lamont | apw: grub2, initramfs-tools, etc. :/ | 13:34 |
| lamont | tbf, none of that is uploaded yet | 13:34 |
| lamont | and all of it is targeting SRU to xenial | 13:35 |
| apw | i'd say get it uploaded then we can consider it from the queue as presumably you will be uploading it after beta either way | 13:35 |
| lamont | and, amazingly, lets one netboot into an iscsi-root in an ipv6-only environment.. How was this not a thing for linux in the 90s, I do not know. | 13:36 |
| apw | lamont, are those all independant as well ? | 13:36 |
| lamont | initramfs-tools depends (I believe) on iproute2 and isc-dhcp (that's how the ipv6 config is done), cloud-init is independent (just adds checking for vars that the new initramfs-tools et al actually populate for ipv6, ditto iscsi (don't ask why iscsi is the package that writes resolv.conf in this use-case... it causes crying) | 13:38 |
| lamont | grub2 is independent of all of it | 13:38 |
| lamont | apw: it's down to confirming a thing or 3 this morning, with the goal being to upload during the US day today... and then I saw the beta freeze email, so I came with hat in hand before stuffing the queue with "WTF ARE THESE JONES" packasge | 13:43 |
| lamont | that is, we're close to claiming readiness | 13:43 |
| -queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (yakkety-proposed) [1.28.2-1ubuntu2] | 13:52 | |
| davmor2 | cyphermox, infinity: assigned it to ubiquity for now as I can't figure out which layer under it is not installing the package https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1626108 | 14:02 |
| ubot5` | Ubuntu bug 1626108 in ubiquity (Ubuntu) "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,New] | 14:02 |
| davmor2 | jibel: ^ | 14:03 |
| -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Yakkety Beta 2] (20160921) has been added | 14:04 | |
| -queuebot:#ubuntu-release- Builds: Lubuntu Desktop powerpc [Yakkety Beta 2] (20160921) has been added | 14:04 | |
| cyphermox | davmor2: that's next on my list after I'm done with lamont's stuff and shim | 14:04 |
| -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Yakkety Beta 2] (20160921) has been added | 14:04 | |
| davmor2 | cyphermox: awesome stuff | 14:06 |
| davmor2 | infinity: just to cheer you up that will need a respin across the board when cyphermox fixes it :) | 14:07 |
| cyphermox | if only I could remember why it's broken from cycle to cycle. | 14:09 |
| davmor2 | cyphermox: last time it didn't show stuff up in ubuntu-drivers list this time it does but just isn't installing them | 14:10 |
| cyphermox | ok | 14:10 |
| cyphermox | well, I'll look | 14:10 |
| cyphermox | how do you currently reproduce this? | 14:10 |
| davmor2 | cyphermox: so I'm assuming something lower down or ubiquity isn't launching ubuntu-driver or whatever the tool it triggers is called | 14:11 |
| davmor2 | cyphermox: I'll setup a new live session if you need me to run anything I can do it straight away | 14:14 |
| -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Beta 2] (20160921) has been added | 14:14 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Beta 2] (20160921) has been added | 14:14 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Beta 2] (20160921) has been added | 14:14 | |
| -queuebot:#ubuntu-release- Unapproved: isc-dhcp (yakkety-proposed/main) [4.3.3-5ubuntu13.1 => 4.3.3-5ubuntu14] (core) | 14:14 | |
| davmor2 | cyphermox: obviously I can't give you access cause you know dell xps only has wifi ;) | 14:14 |
| wxl | infinity: cancel that ping | 14:16 |
| -queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (xenial-proposed) [1:2.2.22-1ubuntu2.1] | 14:23 | |
| -queuebot:#ubuntu-release- Unapproved: openjdk-9 (yakkety-proposed/universe) [9~b136-1 => 9~b136-1ubuntu1] (no packageset) | 14:25 | |
| -queuebot:#ubuntu-release- Unapproved: accepted openjdk-9 [source] (yakkety-proposed) [9~b136-1ubuntu1] | 14:30 | |
| cyphermox | davmor2: well what I meant was which drivers; maybe I have an old box here that can reproduce the issue | 14:31 |
| davmor2 | cyphermox: dell xps 13 broadcom wifi is what is struggling but it isn't installing the intel-microcode either on the installed system | 14:32 |
| cyphermox | ok | 14:32 |
| davmor2 | cyphermox: it worked last week so something changed between Fridays and Tuesdays image | 14:33 |
| cyphermox | err, ok | 14:34 |
| -queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu3 => 0.125ubuntu4] (core) | 14:34 | |
| cyphermox | lamont: initramfs-tools and isc-dhcp: ^ | 14:34 |
| lamont | ack | 14:35 |
| cyphermox | lamont: since you more or less did code review of those by commenting on my bugs previously, you also know about the general idea of what they do | 14:35 |
| davmor2 | cyphermox: I didn't do a fresh install on Monday as I was confirming a bunch of stuff for willcooke so friday was my last clean install | 14:35 |
| lamont | cyphermox: true | 14:35 |
| -queuebot:#ubuntu-release- Unapproved: accepted ntp [source] (xenial-proposed) [1:4.2.8p4+dfsg-3ubuntu5.2] | 14:36 | |
| davmor2 | cyphermox: and then I did one late last night when I hit the issue. | 14:36 |
| cyphermox | ok | 14:37 |
| -queuebot:#ubuntu-release- Unapproved: accepted davical [source] (xenial-proposed) [1.1.4-1ubuntu1.1] | 14:40 | |
| -queuebot:#ubuntu-release- Unapproved: accepted awstats [source] (xenial-proposed) [7.4+dfsg-1ubuntu0.1] | 14:43 | |
| coreycb | hello release team, we have a late bump that is required for ceilometer in yakkety to python-pbr 1.10.0 . upstream ceilometer has moved to a new ceilometer-api binary (removed the old one) which supports different args than the older version. | 14:47 |
| coreycb | the new python-pbr would fix this but it has quite a few rdepends | 14:47 |
| smb | pitti, stgraber, I would highly appreciate if one of you could look at bug 1621618 and in case there is still something missing, let me know. Won't go on the ISO but still I would rather get this out sooner than too late. | 14:47 |
| ubot5` | bug 1621618 in xen (Ubuntu) "[FFE Yakkety] Upgrade to Xen 4.7" [High,In progress] https://launchpad.net/bugs/1621618 | 14:47 |
| coreycb | for reference, bug 1626006 | 14:47 |
| ubot5` | bug 1626006 in ceilometer (Ubuntu) "wsgi_script based ceilometer-api binary does not support the same CLI arguments as console_script version" [High,New] https://launchpad.net/bugs/1626006 | 14:47 |
| -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.5] | 14:51 | |
| pitti | smb: replied | 15:10 |
| smb | pitti, thanks a lot | 15:11 |
| sergiusens | pitti is a Recommends enough to trigger an autopackage test for reverse dependency testing? | 15:16 |
| slangasek | infinity: nusakan's ftp mirror is failing to get updated; it's 5 days out of date right now. any idea why? | 15:17 |
| slangasek | no logs from rsync attempts over the past days either | 15:22 |
| coreycb | pitti, hi, would you be ok an exeception for the openstack pbr issue above? | 15:29 |
| coreycb | *with an | 15:29 |
| -queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.2 => 1.3.1-1ubuntu10.3] (ubuntu-server, virt) | 15:32 | |
| -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.15.2 => 2.15.2ubuntu1] (desktop-core, ubuntu-server) | 15:34 | |
| -queuebot:#ubuntu-release- Unapproved: accepted backuppc [source] (xenial-proposed) [3.3.1-2ubuntu3.1] | 15:35 | |
| pitti | sergiusens: not ATM, but that does sound like a good idea; mind filing a bug against "britney"? | 15:35 |
| sergiusens | sure thing | 15:35 |
| sergiusens | thanks | 15:35 |
| sakrecoer | hello, ubuntu studio still hasn't got an entry on the iso tracker, i'm not sure why. but then again, we would realy like to have this uploaded for testing: https://bugs.launchpad.net/ubuntustudio/+bug/1624690 | 15:37 |
| ubot5` | Ubuntu bug 1624690 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe/FFe] Please upload ubuntustudio-default-settings" [Undecided,New] | 15:37 |
| sakrecoer | as in, if it is possible to have it uploaded in time, we will need a respin | 15:38 |
| sergiusens | pitti fwiw, LP: #1593148 already exists :-) | 15:40 |
| ubot5` | Launchpad bug 1593148 in britney "trigger tests for reverse-recommends dependencies" [Low,Triaged] https://launchpad.net/bugs/1593148 | 15:40 |
| pitti | sergiusens: ah :) | 15:41 |
| slangasek | sergiusens: snapcraft -> snap-confine would be an artificial recommends anyway, right? if you're adding an artificial package relationship, might as well use the one that's currently supported :) | 15:50 |
| -queuebot:#ubuntu-release- Unapproved: pay-service (yakkety-proposed/universe) [15.10+16.10.20160816.1-0ubuntu1 => 15.10+16.10.20160825-0ubuntu1] (no packageset) (sync) | 15:50 | |
| -queuebot:#ubuntu-release- Unapproved: unity-scope-click (yakkety-proposed/universe) [0.1.1+16.10.20160808-0ubuntu1 => 0.1.1+16.10.20160920.1-0ubuntu1] (no packageset) (sync) | 15:50 | |
| -queuebot:#ubuntu-release- Unapproved: accepted unity-scope-click [sync] (yakkety-proposed) [0.1.1+16.10.20160920.1-0ubuntu1] | 15:51 | |
| seb128 | there is a stack of things on http://people.canonical.com/~ubuntu-archive/component-mismatches.svg which are colored white but used to be in main so should be yellow | 15:52 |
| ginggs | could i bug someone to process wine from yakkety NEW please? | 15:52 |
| seb128 | should the old MIR bugs be set back to fix released to fix commited to help with the overview | 15:52 |
| seb128 | or is that not needed? | 15:52 |
| pitti | cyphermox: about http://launchpadlibrarian.net/285799523/initramfs-tools_0.125ubuntu3_0.125ubuntu4.diff.gz - do we even have dhclient in the initrd? mine doesn't, and I don't see any i-t script which would install it | 16:00 |
| pitti | cyphermox: also, doesn't that store its lease file somewhere in /var where we wouldn't find it any more after pivoting, and is a lot slower than ipconfig? | 16:01 |
| pitti | ^ IOW, not something I dare to accept for beta | 16:01 |
| pitti | oh, that would be the dhclient upload after that -- but i-t at least needs a versioned dependency then | 16:02 |
| pitti | (or Breaks: rather, we don't want to pull isc-dhcp into every installation) | 16:02 |
| -queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (yakkety-proposed) [0.125ubuntu4] | 16:04 | |
| cyphermox | err, what? | 16:09 |
| cyphermox | we have isc-dhcp in every install anyway? | 16:09 |
| cyphermox | (it's in minimal) | 16:10 |
| cyphermox | the "slower than ipconfig" is something that we'll just have to deal with if it's true, as ipconfig can't do IPv6; and I don't think the lease file not being carried over is a big deal, you would get the lease back once you ask for it again as NM or ifupdown or systemd-networkd starts (since the server knows what it handed out) | 16:14 |
| -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.3] | 16:18 | |
| -queuebot:#ubuntu-release- Unapproved: postgresql-common (yakkety-proposed/main) [175build1 => 175ubuntu1] (kubuntu, ubuntu-server) | 16:18 | |
| -queuebot:#ubuntu-release- Unapproved: cups (yakkety-proposed/main) [2.2.0-1 => 2.2.0-2] (core) (sync) | 16:24 | |
| -queuebot:#ubuntu-release- New: accepted gnome-2048 [sync] (yakkety-proposed) [3.22.0-1] | 16:25 | |
| -queuebot:#ubuntu-release- New: accepted wine [source] (yakkety-proposed) [1.8.4-1ubuntu1] | 16:26 | |
| pitti | cyphermox: no, it's Priority: important, and on a desktop only NM needs it -- and that depends: shouldn't even be there | 16:27 |
| pitti | cyphermox: (Debian dropped it already, it's a Recommends: now; NM has a builtin fallback) | 16:27 |
| pitti | cyphermox: also, it needs to be versioned, as new i-t with older isc-dhcp-client would render your system unbootable | 16:28 |
| pitti | only NM aside from the metapacakge of course, but we can't require that to be installed in every cloud instance or container | 16:28 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-touch-meta (yakkety-proposed/universe) [1.283 => 1.284] (no packageset) | 16:28 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-touch-meta [source] (yakkety-proposed) [1.284] | 16:29 | |
| -queuebot:#ubuntu-release- New binary: gnome-2048 [ppc64el] (yakkety-proposed/none) [3.22.0-1] (no packageset) | 16:30 | |
| -queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-3-g80f5ec4-0ubuntu1 => 0.7.8-4-g970dbd1-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server) | 16:30 | |
| -queuebot:#ubuntu-release- New binary: gnome-2048 [amd64] (yakkety-proposed/none) [3.22.0-1] (no packageset) | 16:31 | |
| cyphermox | pitti: sorry, I'm not quite following. so what change do you want? I'm not doing this out of the blue, this is driven by a MAAS requirement that IPv6 netbooting works. I don't really see another way to go about it | 16:31 |
| -queuebot:#ubuntu-release- New binary: gnome-2048 [arm64] (yakkety-proposed/none) [3.22.0-1] (no packageset) | 16:32 | |
| pitti | cyphermox: i-t needs to Breaks: isc-dhcp-client (<< your_new_version) at least | 16:32 |
| ginggs | thanks for processing wine, whomever you are :) | 16:32 |
| pitti | cyphermox: as otherwise you are generating an initramfs that calls dhclient without installing it | 16:32 |
| cyphermox | that I totally agree with, I just thought you meant something more | 16:33 |
| -queuebot:#ubuntu-release- New binary: gnome-2048 [i386] (yakkety-proposed/none) [3.22.0-1] (no packageset) | 16:34 | |
| -queuebot:#ubuntu-release- New binary: gnome-2048 [armhf] (yakkety-proposed/none) [3.22.0-1] (no packageset) | 16:38 | |
| -queuebot:#ubuntu-release- Unapproved: ldb (yakkety-proposed/main) [2:1.1.26-1ubuntu3 => 2:1.1.26-1ubuntu4] (core) | 16:38 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Yakkety Beta 2] (20160921) has been added | 16:38 | |
| -queuebot:#ubuntu-release- New binary: gnome-2048 [powerpc] (yakkety-proposed/none) [3.22.0-1] (no packageset) | 16:43 | |
| -queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (xenial-proposed) [0.2.3-0ubuntu1~16.04] | 16:49 | |
| pitti | cyphermox: well, I actually did, like storing the lease, etc. -- but I figured then that this isn't important as we don't currently do it with ipconfig either | 16:50 |
| mapreri | could somebody ignore src:diffoscope autopkgtests? They are only tests issues, code actually work… | 16:50 |
| cyphermox | pitti: right | 16:50 |
| -queuebot:#ubuntu-release- New: accepted gnome-2048 [amd64] (yakkety-proposed) [3.22.0-1] | 16:51 | |
| cyphermox | pitti: the lease is known by the server too, you'd get the same IP if you request it after | 16:51 |
| -queuebot:#ubuntu-release- New: accepted gnome-2048 [armhf] (yakkety-proposed) [3.22.0-1] | 16:51 | |
| -queuebot:#ubuntu-release- New: accepted gnome-2048 [powerpc] (yakkety-proposed) [3.22.0-1] | 16:51 | |
| -queuebot:#ubuntu-release- New binary: gnome-2048 [s390x] (yakkety-proposed/universe) [3.22.0-1] (no packageset) | 16:51 | |
| -queuebot:#ubuntu-release- New: accepted gnome-2048 [arm64] (yakkety-proposed) [3.22.0-1] | 16:51 | |
| -queuebot:#ubuntu-release- New: accepted gnome-2048 [ppc64el] (yakkety-proposed) [3.22.0-1] | 16:51 | |
| cyphermox | except maybe on ipv6, due to the DUID | 16:51 |
| -queuebot:#ubuntu-release- New: accepted gnome-2048 [i386] (yakkety-proposed) [3.22.0-1] | 16:51 | |
| -queuebot:#ubuntu-release- New: accepted gnome-2048 [s390x] (yakkety-proposed) [3.22.0-1] | 16:51 | |
| -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.12.1-0ubuntu7~16.04] | 16:51 | |
| pitti | cyphermox: so then the remaining thing is that in principle you could remove isc-dhcp-client on such a system and then break your boot, but that might well fall into the "don't do that then" class :) | 16:52 |
| pitti | which just leaves the Breaks: | 16:52 |
| cyphermox | yeah | 16:52 |
| -queuebot:#ubuntu-release- New binary: wine [i386] (yakkety-proposed/universe) [1.8.4-1ubuntu1] (no packageset) | 16:52 | |
| cyphermox | the don't do that class is covered by the other options you can use to still run ipconfig, until we remove it entirely | 16:52 |
| pitti | cyphermox: I guess eventually we want to put netplan/networkd into the initrd, this puts its state into /run which cleanly gets transitioned into the root fs | 16:55 |
| -queuebot:#ubuntu-release- Unapproved: qemu (yakkety-proposed/main) [1:2.6.1+dfsg-0ubuntu3 => 1:2.6.1+dfsg-0ubuntu4] (ubuntu-server, virt) | 17:01 | |
| -queuebot:#ubuntu-release- New binary: docker.io [amd64] (xenial-proposed/universe) [1.12.1-0ubuntu7~16.04] (no packageset) | 17:02 | |
| -queuebot:#ubuntu-release- Unapproved: python-pbr (yakkety-proposed/main) [1.8.0-4.1ubuntu1 => 1.10.0-0ubuntu1] (ubuntu-desktop, ubuntu-server) | 17:03 | |
| slangasek | "built-in fallback"> wut | 17:04 |
| slangasek | we certainly shouldn't be using multiple dhcp client implementations, NM should be using isc-dhcp consistently | 17:04 |
| -queuebot:#ubuntu-release- New binary: wine [powerpc] (yakkety-proposed/universe) [1.8.4-1ubuntu1] (no packageset) | 17:05 | |
| pitti | well, it's still achingly slow, I see why people want to not use it | 17:05 |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.15.2ubuntu1] | 17:08 | |
| cyphermox | slangasek: I don't know that NM has any built-in implementation of dhcp | 17:11 |
| -queuebot:#ubuntu-release- New binary: wine [arm64] (yakkety-proposed/universe) [1.8.4-1ubuntu1] (no packageset) | 17:12 | |
| -queuebot:#ubuntu-release- Unapproved: dm-writeboost (yakkety-proposed/universe) [2.2.3-1 => 2.2.3-1ubuntu1] (no packageset) | 17:13 | |
| slangasek | pitti: sure, so let's fix that there in the right place, not work around it selectively for desktop | 17:13 |
| -queuebot:#ubuntu-release- Unapproved: accepted dm-writeboost [source] (yakkety-proposed) [2.2.3-1ubuntu1] | 17:14 | |
| lamont | can someone smack cloud-init past the freeze marker? | 17:17 |
| lamont | brb | 17:17 |
| ginggs | wine amd64 build was successful but upload failed: wine_1.8.4-1ubuntu1_all.deb: Version older than that in the archive. 1.8.4-1ubuntu1 <= 1:1.6.2-0ubuntu15 :( | 17:19 |
| ginggs | what can we do about that? | 17:19 |
| apw | i thought that wine upload had renamed those packages to wine-something to avoid that | 17:20 |
| apw | "Replace package wine with wine-stable. Needed for the transition to a | 17:21 |
| apw | 0-epoch in the version number. | 17:21 |
| apw | and indeed the changelog claimsso | 17:21 |
| slangasek | lamont: I see no cloud-init on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html; can you clarify what needs smacking? | 17:22 |
| slangasek | ginggs: right, you can use a different binary name, or you can add an epoch. epochs are forever | 17:22 |
| slangasek | lamont: ah, in the unapproved queue, right. checking | 17:23 |
| slangasek | lamont: cloud-init accepted | 17:24 |
| -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-4-g970dbd1-0ubuntu1] | 17:25 | |
| ginggs | apw, slangasek: thanks, going to double check on that. Is removal of the offending package an option (provided all the necessary breaks/replaces are in place?) | 17:27 |
| apw | ginggs, an option to achieve a reset of the epoch ? | 17:29 |
| lamont | slangasek: sorry for the unclarity there | 17:29 |
| lamont | thanks | 17:29 |
| lamont | cyphermox: I'm going to stay hands-off on your changes | 17:30 |
| slangasek | lamont: the fault is mine for being oblivious to how the freeze is being managed ;P | 17:30 |
| lamont | heh | 17:30 |
| slangasek | (or the fault is infinity's, for insisting on freezing the queue when we can block things in proposed-migration instead ;) | 17:30 |
| cjwatson | removal of the offending package doesn't do anything to cause users doing a dist-upgrade to get the correct new version installed | 17:31 |
| lamont | slangasek: if you let it into -proposed, then you have to supersede it to get something in after a compropmise is reached. | 17:31 |
| apw | cjwatson, by the looks of things the intent is to use breaks/replaces/conflicts to throw wine off while replacing it with wine-stable, and then sometime after 18.04 transition back to wine ... | 17:32 |
| apw | but to do that the wine transitional would have to have a real binary version above those in the archive currently, i make no comment on whether this will work | 17:34 |
| ginggs | apw, cjwatson: i meant removing the old package to allow the new one into the archive. maybe the solution here is just not to build a wine package, all it does is depend on wine-stable | 17:35 |
| apw | it is not clear how that one would help transition people unless it has a higher binary version (which can differ from the source) than the archive | 17:37 |
| apw | even if the old was replaced with that, the people with an existing package would think theirs was newer and not update | 17:38 |
| cjwatson | ginggs: that's what I'm saying, we don't generally do that because the purpose of this check is to protect against client problems | 17:39 |
| -queuebot:#ubuntu-release- Unapproved: address-book-app (yakkety-proposed/universe) [0.2+16.10.20160913-0ubuntu1 => 0.2+16.10.20160920-0ubuntu1] (no packageset) (sync) | 17:40 | |
| -queuebot:#ubuntu-release- Unapproved: address-book-service (yakkety-proposed/universe) [0.1.2+16.10.20160908-0ubuntu1 => 0.1.2+16.10.20160920-0ubuntu1] (no packageset) (sync) | 17:41 | |
| -queuebot:#ubuntu-release- Unapproved: buteo-syncfw-qml (yakkety-proposed/universe) [0.1+15.10.20151008-0ubuntu1 => 0.1+16.10.20160919-0ubuntu1] (no packageset) (sync) | 17:41 | |
| -queuebot:#ubuntu-release- Unapproved: accepted buteo-syncfw-qml [sync] (yakkety-proposed) [0.1+16.10.20160919-0ubuntu1] | 17:41 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] has been updated (20160921.1) | 17:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] has been updated (20160921.1) | 17:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] has been updated (20160921.1) | 17:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Beta 2] has been updated (20160921.1) | 17:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] has been updated (20160921.1) | 17:57 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] has been updated (20160921.1) | 17:57 | |
| lamont | slangasek: so... about my favorite thing to hate this month... | 18:04 |
| lamont | the changes that cyphermox is stuffing through, along with a couple others, actually allow you to netboot ipv6 with an iscsi-root (bug 1621515 and bug 1621507) | 18:04 |
| ubot5` | bug 1621515 in Ironic "[RFC] DRAC: get progress after submitting set_bios_config request" [Wishlist,Fix released] https://launchpad.net/bugs/1621515 | 18:04 |
| ubot5` | bug 1621507 in isc-dhcp (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507 | 18:04 |
| lamont | slangasek: strong preference would be to have them _IN_ the beta | 18:05 |
| lamont | with the exception of the change in initramfs-tools (and the introduction of isc-dhcp), it's all "if this variable that nothing previously set is set, then do things for ipv6" | 18:06 |
| cyphermox | initramfs-tools should reappear shortly, I did the upload already | 18:06 |
| -queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu3 => 0.125ubuntu4] (core) | 18:06 | |
| slangasek | lamont: there was discussion upscroll about this between pitti and cyphermox; I'm unsure if there was a conclusion that changes were needed to the packages currently in the queue | 18:06 |
| lamont | the initramfs-tools change is to use isc-dhcp rather than klibc's ipconfig, which we're all confident is a good thing, but would love to have a WIDE exposer to | 18:06 |
| slangasek | right, that | 18:06 |
| lamont | slangasek: the conclusion was that cyphermox was fixing his badness, I thought. :D | 18:07 |
| cyphermox | slangasek: pitti was asking about a Breaks I've added. | 18:07 |
| slangasek | k | 18:07 |
| lamont | slangasek: my request is that once pitti and cyphermox are all good with it, that we release cloud-init, open-iscsi, isc-dhcp, and initramfs-tools into the beta. | 18:09 |
| * slangasek nods | 18:09 | |
| slangasek | which pitti has the power to do | 18:09 |
| slangasek | but is also going to be EOD | 18:09 |
| lamont | cyphermox: and I believe that we're addressing the klibc part of 1621507 by stabbing it in the face, yes? | 18:09 |
| cyphermox | that initramfs-tools upload includes the Breaks pitti wanted, I didn't get a review for isc-dhcp. | 18:10 |
| cyphermox | lamont: no, the klibc part of bug 1621507 will be for laterz | 18:10 |
| ubot5` | bug 1621507 in isc-dhcp (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507 | 18:10 |
| cyphermox | well, we're not using it for dhcp, but it still may be used for other things, and I'm not willing to break other people's possibly very outdated and broken ways of netbooting by only allowing dhclient | 18:11 |
| cyphermox | or at least, not this late in the cycle, etc. etc. | 18:11 |
| lamont | cyphermox: I was referring only to the whole configure_networking() change for dhcp, but yeah | 18:11 |
| cyphermox | yeah, for dhcp we don't use ipconfig/klibc anymore. | 18:12 |
| cyphermox | early in Z I'd get back to my spreadsheet and try to quickly stab klibc off the initramfs. | 18:12 |
| -queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.1.3-0ubuntu4.1 => 2.1.3-0ubuntu4.2] (ubuntu-cloud, ubuntu-server) | 18:13 | |
| sergiusens | slangasek given LP: #1593148 and LP: #1626121 (even though it might not have directly caught this bug), I would like to take up on your offer to at least temporarily add the adt triggers you mentioned | 18:13 |
| ubot5` | Launchpad bug 1593148 in britney "trigger tests for reverse-recommends dependencies" [Low,Triaged] https://launchpad.net/bugs/1593148 | 18:13 |
| ubot5` | Launchpad bug 1626121 in Snappy "snap-confine causes Segmentation fault" [Critical,In progress] https://launchpad.net/bugs/1626121 | 18:13 |
| -queuebot:#ubuntu-release- Unapproved: python-django (yakkety-proposed/main) [1.8.7-1ubuntu6 => 1.8.7-1ubuntu7] (ubuntu-server) | 18:17 | |
| sakrecoer | hi, the ubuntustudio 64-bit failed 2 hours ago, but there is still no buildlog to be found. | 18:31 |
| sakrecoer | slangasek: i'm told you might know what is going on. :) | 18:32 |
| slangasek | sakrecoer: which build log are you looking for? | 18:40 |
| sakrecoer | slangasek: the one for the failed 64bit iso: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio/ | 18:41 |
| slangasek | cyphermox: I think we should stab klibc off the initramfs this cycle as part of this, rather than leaving everyone with larger initramfs for release | 18:42 |
| cyphermox | slangasek: I'll be happy to, I just didn't forsee it as getting the priority | 18:43 |
| slangasek | sakrecoer: ok, that's the launchpad build log that's missing, I can't help with that; you'd need wgrant or cjwatson most likely | 18:43 |
| slangasek | cyphermox: bigger initramfs impacts boot speed for everyone; boot speed is a priority :) | 18:44 |
| cyphermox | what I meant by my comment before is that it's rather easy to complete the work from where I left it w/r/t removing klibc; just need to continue making sure none of the bits it provides are being used | 18:44 |
| cyphermox | fair enough | 18:44 |
| cjwatson | sakrecoer: seems to be repeatedly crashing the builder; dunno why | 18:45 |
| sakrecoer | slangasek, cjwatson, is there anywhere else where we can see a log of what is going on? | 18:46 |
| cyphermox | slangasek: then I'll chalk this up not too far down my todo list, just after that new shim we need and checking out davmor's issue with the third-party drivers. | 18:46 |
| sakrecoer | else as in, not launchpad log? | 18:46 |
| cjwatson | sakrecoer: no, the failure is precisely that the builder crashes and so LP can't retrieve the log from it. you'd have to either reproduce locally with the right livecd-rootfs setup, or retry the build and hope that you can spot the problem in the logtail by repeatedly reloading | 18:46 |
| slangasek | sergiusens: fwiw the p-m autopkgtest special casing lives in git+ssh://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu, autopkgtest.py if you want to raise an MP | 18:47 |
| cjwatson | somebody reported this with another livefs build earlier today as well. has livecd-rootfs or live-build changed recently? | 18:47 |
| slangasek | livecd-rootfs has changed, yes | 18:48 |
| sergiusens | thanks | 18:49 |
| slangasek | cjwatson: infinity landed a change to use a different kernel for powerpc64; but that seems unlikely to be causing this crash | 18:49 |
| slangasek | likewise live-build | 18:50 |
| sakrecoer | slangasek: i'm more instrested in having an ISO than the log :) | 18:50 |
| sakrecoer | cjwatson ^ | 18:50 |
| slangasek | so, the previous ubuntustudio image build 22 hours ago succeeded | 18:51 |
| sakrecoer | seems so, yes. | 18:51 |
| slangasek | we can try building again, but if cjwatson says the builders are repeatedly crashing, that may not be productive | 18:51 |
| cjwatson | don't let me stop you trying, as long as you give up after a while :) | 18:52 |
| sakrecoer | cjwatson, slangasek: can the one that build 22h be a release candidate for beta2? | 18:52 |
| sakrecoer | build 22h *ago | 18:52 |
| flocculant | I think the problem for people like me and sakrecoer is if we hit rebuild on the tracker - that's already showing as rebuilding - we're not sure it's really doing it and nor are we sure wew're making a situation worse | 18:53 |
| cjwatson | sakrecoer: not my decision | 18:53 |
| cjwatson | flocculant: slangasek is certainly able to poke it manually | 18:53 |
| flocculant | cjwatson: ack | 18:54 |
| sakrecoer | yes, flocculant pinpoint my concern.. | 18:54 |
| cjwatson | I don't think you're going to be making it worse, but it may indeed not help | 18:54 |
| slangasek | flocculant, sakrecoer: you would see whether or not it's doing it from that launchpad page, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio/ | 18:55 |
| cjwatson | it's not very clear what could have caused this; it could be something like out-of-memory | 18:55 |
| cjwatson | or out of disk space on the builder, which is known to cause fairly catastrophic failures | 18:56 |
| slangasek | sakrecoer: it's probably not useful to release the 22-hours-ago image for beta, it has the 4.4 kernel on it | 18:56 |
| cjwatson | though I think the latter results in a hang, not a crash like this | 18:56 |
| cjwatson | so yeah, throw it back against the wall and see what happens | 18:56 |
| sakrecoer | slangasek, cjwatson: alright, i'll hit respin on the tracker and touch some wood then :) | 18:57 |
| slangasek | I wonder if the ubuntustudio xenial builds are also dead | 18:57 |
| slangasek | sakrecoer: no | 18:57 |
| slangasek | sakrecoer: I have already triggered a rebuild | 18:57 |
| sakrecoer | ok :) thank you slangasek ! | 18:57 |
| slangasek | sorry, guess I wasn't clear that I was doing that | 18:58 |
| slangasek | cjwatson: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntustudio/+build/76141 ? "estimated finish" + "currently building" + link to build log | 18:58 |
| cjwatson | there are some partial-crash states that can do that | 18:59 |
| cjwatson | or possibly it's still gathering the build | 18:59 |
| cjwatson | 2016-09-21 17:50:54+0000 [HTTP11ClientProtocol,client] Grabbing file: livecd.ubuntustudio-dvd.squashfs (http://lcy01-28.lcy01.scalingstack.ppa:8221/filecache/186b80aa79ef7edbe24fa58fbe8b9e7ab026a1e2) | 19:00 |
| cjwatson | hmm | 19:01 |
| * cjwatson asks for a buildd-manager restart just in case it's confused | 19:02 | |
| -queuebot:#ubuntu-release- Unapproved: irssi (yakkety-proposed/main) [0.8.19-1ubuntu1 => 0.8.19-1ubuntu2] (core) | 19:06 | |
| ginggs | cjwatson, apw: so the reason we still have a wine 1:1.6.2-0ubuntu15 in the archive, is because the new wine1.6 package hasn't migrated yet, and the reason for that is is depends on the new wine-stable packages. if the old wine binary package was removed from the archive, then the new wine source package would go into the archive and both would migrate. | 19:07 |
| * Ukikie raises eyebrow. | 19:07 | |
| cjwatson | slangasek,sakrecoer: ok, so a buildd-manager restart seems to have helped, that may have been the problem | 19:08 |
| ginggs | cjwatson, apw: when upgrading, the old wine package is removed, as can be seen from the install log in comment #52 of LP: #1558480 | 19:08 |
| ubot5` | Launchpad bug 1558480 in wine1.6 (Ubuntu) "[FFe] Transition from src:wine1.6 to src:wine from Debian" [High,Triaged] https://launchpad.net/bugs/1558480 | 19:08 |
| cjwatson | ginggs: if the wine binary package is not intended to remain installed, it should be removed | 19:09 |
| cjwatson | ginggs: (from the archive) | 19:09 |
| cjwatson | ginggs: I'm not prepared to wind versions backwards in release suites, pretty much no matter what the argument :) | 19:10 |
| cjwatson | ginggs: that is, the conclusion I'm drawing from your argument so far is that you should stop building a wine binary package | 19:10 |
| ginggs | cjwatson, apw: ok, so the new wine binary package is only there for people who have never had wine installed and just want to do 'apt-get install wine' and expect it to work | 19:11 |
| sakrecoer | thank you cjwatson! | 19:11 |
| * sakrecoer still crossing fingers | 19:11 | |
| cjwatson | ginggs: at this point I don't think I can do anything other than repeat myself, sorry, so I'm bowing out of this conversation | 19:11 |
| ginggs | cjwatson, apw: I think it is safe for us to drop it then, and they will just have to do 'apt-get install wine-stable' instead. | 19:12 |
| cjwatson | you are not going to persuade me to make the version of a binary package in a release suite go backwards | 19:12 |
| cjwatson | you could always make wine's version number be higher, though I don't know what the consequences would be. | 19:12 |
| cjwatson | (note that it is not strictly required for the version of a binary package to be identical to the version of the source package that generates it) | 19:13 |
| cjwatson | anyway, dinner | 19:13 |
| ginggs | cjwatson: thanks | 19:13 |
| cjwatson | (dh_gencontrol -pwine -- -v<overridden-version> or some such, probably computed with the aid of dpkg-parsechangelog) | 19:14 |
| cyphermox | davmor2: ok, I think I see what's wrong on the desktop daily | 19:24 |
| davmor2 | cyphermox: \o/ | 19:24 |
| cyphermox | davmor2: looks like despite what is configured in polkit, we don't get access to NetworkManager, or to install the packages for ubuntu-drivers | 19:24 |
| davmor2 | cyphermox: I blame pitti bound to be his fault ;) | 19:25 |
| cyphermox | I have no idea whose fault it is, but it looks wrong. we shouldn't have to click anythign special to be able to run this in the installer | 19:26 |
| cyphermox | davmor2: can you confirm that if you start ubiquity via 'sudo ubiquity' in a terminal things behave correctly? looks that way to me anyway | 19:30 |
| davmor2 | cyphermox: sure give me 2 seconds | 19:31 |
| davmor2 | cyphermox: I'm not seeing any change for wifi on installed system or live cd | 19:40 |
| davmor2 | cyphermox: you are just running sudo ubiquity right no options or anything? | 19:41 |
| flexiondotorg | infinity, Just a head up. | 19:53 |
| flexiondotorg | MATE Desktop 1.15.1 is currently in the Yakkety archive. It is a development release. | 19:53 |
| flexiondotorg | MATE 1.16 is being announced tomorrow. | 19:54 |
| flexiondotorg | So I'll be bumping all of MATE in the coming days. | 19:54 |
| -queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.172 => 3.173] (ubuntu-desktop, ubuntu-server) | 19:59 | |
| dobey | hi, can someone on release team please let pay-service through the UNAPPROVED queue? the upload was fixes for the MIR review, and i don't think it's been seeded yet? | 20:16 |
| cyphermox | davmor2: indeed no extra options, I can get the wifi connected and the packages (intel-microcode) appear to be installed | 20:17 |
| davmor2 | cyphermox: whats the md5sum of your image lets makes sure we are both on the same version | 20:18 |
| cyphermox | 95c23e02a129237414d99ac6f91b65ce | 20:18 |
| cyphermox | davmor2: I doubt that would make much of a difference | 20:18 |
| davmor2 | cyphermox: nope they are the same but it was worth a double check to be sure :) | 20:19 |
| davmor2 | cyphermox: dpkg -l | grep intel shows intel-gpu-tools, libdrm-intel, xserver-xorg-video-intel and dpkg -l | grep bcmwl shows nothing thats on the installed system | 20:28 |
| davmor2 | cyphermox: anything else you'd like me to try? | 20:40 |
| -queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.17+16.10.1ubuntu3 => 2.18+16.10] (no packageset) | 20:40 | |
| -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.18+16.10] | 20:41 | |
| -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.17 => 2.18] (no packageset) | 20:41 | |
| -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.15.2+16.10.2 => 2.15.2+16.10.3] (desktop-core, ubuntu-server) | 20:55 | |
| -queuebot:#ubuntu-release- Unapproved: accepted irssi [source] (yakkety-proposed) [0.8.19-1ubuntu2] | 20:59 | |
| * davmor2 calls it a night cyphermox if there is anything you want me to test just send me a mail and I'll catch you tomorrow | 21:03 | |
| dobey | hmm | 21:04 |
| slangasek | dobey: yeah, I'm not sure why pay-service isn't getting auto-accepted; accepting now | 21:10 |
| dobey | slangasek: thanks! | 21:11 |
| -queuebot:#ubuntu-release- Unapproved: accepted pay-service [sync] (yakkety-proposed) [15.10+16.10.20160825-0ubuntu1] | 21:11 | |
| -queuebot:#ubuntu-release- Unapproved: accepted address-book-app [sync] (yakkety-proposed) [0.2+16.10.20160920-0ubuntu1] | 21:12 | |
| -queuebot:#ubuntu-release- Unapproved: accepted address-book-service [sync] (yakkety-proposed) [0.1.2+16.10.20160920-0ubuntu1] | 21:13 | |
| slangasek | infinity, stgraber: ^^ why were these packages not auto-accepted? They're not yet on any image | 21:14 |
| infinity | slangasek: They're seeded in desktop. | 21:15 |
| infinity | slangasek: Not on images only due to their being in universe still, but they *are* seeded. :/ | 21:15 |
| slangasek | infinity: ok, so it's pulled via the unity8-desktop-session change, ack | 21:16 |
| slangasek | that's not unreasonable and I'll keep hand-accepting, thanks | 21:16 |
| slangasek | (but for some reason 'seeded-in-ubuntu' gives a different answer) | 21:16 |
| infinity | seeded-in-ubuntu may well still be working off old data while ubuntuwire is being recovered. | 21:17 |
| infinity | It didn't even work yesterday, so this is progress. :P | 21:17 |
| slangasek | http://ubuntuqa.tblwd.org/seeded.json.gz | 21:18 |
| slangasek | is what it's pointed at | 21:18 |
| infinity | Which is an old backup, yes. | 21:18 |
| slangasek | so maybe that's not updated at the same frequency as usual, or maybe it's just normal lag, yes | 21:18 |
| stgraber | maybe the backend for seeded-in-ubuntu should be moved to snakefruit, it should have all the needed bits on disk already so could generate the data pretty quickly (would also make the checks by the auto-accept script much faster) | 21:19 |
| slangasek | alternatively, maybe we can figure out how to run that without it having to be on the privileged box of doom ;) | 21:21 |
| stgraber | yeah, though snakefruit has the advantage of having all the right bits on disk and knowing when to trigger updates. I'd certainly agree that we could do with a separate role account on snakefruit just for bits that actually do need the ubuntu-archive LP creds. | 21:23 |
| stgraber | speaking of which, LP is throttling auto-accept it looks like... | 21:23 |
| stgraber | At least 6 queries/external actions issued in 0.13 seconds OOPS-8e4956c456ad405f5ab34b3896926396 | 21:23 |
| stgraber | seeing a few similar entries in the log | 21:24 |
| infinity | We should probably move all the ubuntu-dev-tools web services into the Canononical DC, but I don't think anyone's ever stepped up to offer a path forward for that. | 21:24 |
| infinity | But we rely too heavily on seeded-in-ubuntu and reverse-depends, at least, for them to have downtime. | 21:24 |
| -queuebot:#ubuntu-release- Unapproved: accepted postgresql-common [source] (yakkety-proposed) [175ubuntu1] | 21:25 | |
| stgraber | actually, just a single oops, so hopefully just a one time glitch, will ping LP folks if I see more of that in the log | 21:25 |
| -queuebot:#ubuntu-release- Unapproved: accepted ldb [source] (yakkety-proposed) [2:1.1.26-1ubuntu4] | 21:25 | |
| tumbleweed | infinity: it's not an old backup, there's a cron job | 21:26 |
| tumbleweed | but also, ubuntuwire is back | 21:26 |
| tumbleweed | slangasek: yeah, I had no idea what the cron frequency was, so it was almost certainly different | 21:27 |
| tumbleweed | tying that to publishes wolud be nice | 21:27 |
| tumbleweed | and hosting it at canonical obviously :P | 21:27 |
| infinity | tumbleweed: Yeah, I noticed ubuntuwire was back. | 21:27 |
| infinity | (thanks!) | 21:28 |
| apw | infinity, did the cowboy get reverted ? | 21:28 |
| infinity | tumbleweed: I assume the generation scripts for the seeded and reverse-dep services are pretty simple? | 21:28 |
| slangasek | oh yay, cancelling my wrapper scripts for seeded and revdeps :) | 21:28 |
| infinity | apw: Probably not. Go for it. | 21:28 |
| tumbleweed | infinity: fairly. reverse-deps is a bit more complex (and doesn't understand some of the modern dependency qualifiers) | 21:29 |
| infinity | slangasek: Note that seeded-in-ubuntu still won't tell you about fallout from unity8-desktop-session, I suspect it's taking components into account or something. | 21:29 |
| slangasek | infinity: "path forward"> so if someone created a charm for those services and wrapped them in a mojo spec, it would be straightforward for Foundations to own that | 21:29 |
| apw | infinity, and ripped | 21:29 |
| infinity | apw: Ta. | 21:29 |
| infinity | slangasek: Charming them implies a dists mirror for each one too, which is likely why stgraber was suggesting we just dump them on snakefruit. | 21:30 |
| tumbleweed | https://bazaar.launchpad.net/~stefanor/+junk/reverse-deps/view/head:/update-rdepends.py - hairy ugly sql for performance | 21:30 |
| tumbleweed | seeded in ubuntu is far simpler: https://bazaar.launchpad.net/~stefanor/+junk/ubuntu-seeded-packages/view/head:/update.py | 21:31 |
| tumbleweed | err, no, the complex DB structure in reverse-depends was for database size. otherwise I would have used a flatter schema | 21:32 |
| slangasek | infinity: yeah, I think we would want to have a shared nova volume for the dists mirror instead | 21:33 |
| infinity | slangasek: That could be a good first step to charming up a lot of archive-reports, yeah. | 21:34 |
| infinity | (which is where this stuff would fit in the current world order) | 21:35 |
| -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-14.15] (core, kernel) | 21:36 | |
| slangasek | hmmm can a nova volume actually be shared, though | 21:36 |
| slangasek | I guess you might have to resort to swift for sharing | 21:36 |
| infinity | slangasek: Dunno. But it would only need to be r/o to all services using it, and r/w to the mirror service that gets triggered. | 21:36 |
| slangasek | or else run all the related charms on a single unit | 21:36 |
| infinity | slangasek: So, there should be a way to make that work, somehow. | 21:37 |
| infinity | slangasek: Or that, yeah. | 21:37 |
| slangasek | unless someone wants to volunteer to maintain an nfs server in prodstack | 21:37 |
| infinity | *shudder* | 21:37 |
| infinity | Actually, nfs for r/o data isn't the worst option. | 21:37 |
| infinity | But probably also not the best. :P | 21:37 |
| infinity | slangasek: This isn't me committing just yet, but it would be an interesting project to see what one can do with relations. | 21:40 |
| infinity | slangasek: Cause, ideally, the r/w mirror service would trigger all the related microservices to do their thing after each mirror pulse, emulating the monolithic archive-reports cronjob. | 21:40 |
| -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-14.15] | 21:41 | |
| * slangasek nods | 21:42 | |
| infinity | slangasek: And, obviously, in a juju-perfect world, adding a microservice should be as simple as declaring a relationship to the mirror service and Bob's your uncle. | 21:42 |
| -queuebot:#ubuntu-release- New: accepted wine [arm64] (yakkety-proposed) [1.8.4-1ubuntu1] | 22:11 | |
| -queuebot:#ubuntu-release- New: accepted wine [powerpc] (yakkety-proposed) [1.8.4-1ubuntu1] | 22:11 | |
| -queuebot:#ubuntu-release- New: accepted wine [i386] (yakkety-proposed) [1.8.4-1ubuntu1] | 22:11 | |
| santa_ | infinity: hi | 22:12 |
| santa_ | infinity: regarding the plasma.discover issue with xenial -> yakkety dist-upgrades I re-tested again the solution with metapackages and it seems it doesn't work anymore here, so I figures out a different solution https://paste.kde.org/pyt0a2bvv | 22:13 |
| santa_ | * figured | 22:14 |
| infinity | santa_: Erm, that doesn't make much sense either. | 22:18 |
| infinity | santa_: Isn't the goal to have the two old packages removed on upgrade? | 22:18 |
| infinity | santa_: I'd expect something like this: http://paste.ubuntu.com/23213525/ | 22:20 |
| -queuebot:#ubuntu-release- Unapproved: cups-filters (yakkety-proposed/main) [1.11.3-0ubuntu1 => 1.11.4-0ubuntu1] (desktop-core, ubuntu-server) | 22:21 | |
| santa_ | infinity: well, the idea is also removing the transtionals, but the important part is the conflicts. let me re-paste to show the "serious" diff | 22:22 |
| santa_ | commit 5e362c8de89256b27f62334659bace4e407ec8e1 | 22:22 |
| santa_ | Author: José Manuel Santamaría Lema <panfaust@gmail.com> | 22:22 |
| santa_ | Date: Wed Sep 21 22:47:31 2016 +0200 | 22:22 |
| santa_ | Drop transitional packages, use Conflicts against python3-aptdaemon.pkcompat. | 22:22 |
| santa_ | diff --git a/debian/changelog b/debian/changelog | 22:22 |
| santa_ | index 794047f..49e688d 100644 | 22:22 |
| santa_ | --- a/debian/changelog | 22:22 |
| santa_ | +++ b/debian/changelog | 22:22 |
| santa_ | @@ -1,3 +1,14 @@ | 22:22 |
| santa_ | +plasma-discover (5.7.5-0ubuntu2) UNRELEASED; urgency=medium | 22:23 |
| santa_ | + | 22:23 |
| santa_ | + * plasma-discover now Conflicts against python3-aptdaemon.pkcompat, without | 22:23 |
| santa_ | + this apt-get would want to remove plasma-discover while upgrading from | 22:23 |
| santa_ | + xenial to yakkety. | 22:23 |
| santa_ | + * Drop transitional dummy packages plasma-discover-private and | 22:23 |
| santa_ | + plasma-discover-updater because the above solution is the one which actually | 22:23 |
| santa_ | + works. | 22:23 |
| cjwatson | santa_: Please use paste.ubuntu.com next time. | 22:23 |
| santa_ | + | 22:23 |
| santa_ | + -- José Manuel Santamaría Lema <panfaust@gmail.com> Wed, 21 Sep 2016 22:40:54 +0200 | 22:23 |
| santa_ | + | 22:23 |
| santa_ | plasma-discover (5.7.5-0ubuntu1) yakkety; urgency=medium | 22:23 |
| santa_ | 22:23 | |
| santa_ | [ Philip Muškovac ] | 22:23 |
| santa_ | diff --git a/debian/control b/debian/control | 22:23 |
| santa_ | index 1b08d04..00ca3f5 100644 | 22:23 |
| santa_ | --- a/debian/control | 22:23 |
| santa_ | +++ b/debian/control | 22:23 |
| santa_ | @@ -51,6 +51,7 @@ Depends: appstream (>= 0.8), | 22:23 |
| santa_ | qml-module-qtgraphicaleffects, | 22:23 |
| santa_ | ${misc:Depends}, | 22:23 |
| santa_ | ${shlibs:Depends} | 22:23 |
| santa_ | +Conflicts: python3-aptdaemon.pkcompat | 22:23 |
| santa_ | Breaks: libmuon (<< 4:5.6), | 22:23 |
| santa_ | muon-discover (<< 4:5.5.3a), | 22:23 |
| santa_ | muon-notifier (<< 4:5.5.3a), | 22:23 |
| santa_ | @@ -95,24 +96,6 @@ Description: Discover software manager suite (common data files) | 22:23 |
| santa_ | This package contains data files shared by various parts of the | 22:23 |
| santa_ | Discover suite. | 22:23 |
| santa_ | 22:23 | |
| santa_ | -Package: plasma-discover-private | 22:23 |
| santa_ | -Architecture: all | 22:23 |
| infinity | ... | 22:23 |
| santa_ | -Section: oldlibs | 22:23 |
| santa_ | -Priority: extra | 22:23 |
| santa_ | -Depends: ${misc:Depends} | 22:23 |
| santa_ | -Description: Transitional package plasma-discover-private | 22:23 |
| santa_ | - This is a transitional package for plasma-discover-private and can safely be | 22:23 |
| santa_ | - removed. | 22:23 |
| santa_ | - | 22:23 |
| santa_ | -Package: plasma-discover-updater | 22:23 |
| santa_ | -Architecture: all | 22:24 |
| santa_ | -Section: oldlibs | 22:24 |
| santa_ | -Priority: extra | 22:24 |
| santa_ | -Depends: ${misc:Depends} | 22:24 |
| santa_ | -Description: Transitional package plasma-discover-updater | 22:24 |
| -queuebot:#ubuntu-release- Unapproved: cups (yakkety-proposed/main) [2.2.0-1 => 2.2.0-2] (core) (sync) | 22:24 | |
| santa_ | - This is a transitional package for plasma-discover-updater and can safely be | 22:24 |
| santa_ | - removed. | 22:24 |
| santa_ | - | 22:24 |
| santa_ | Package: muon-discover | 22:24 |
| santa_ | Architecture: all | 22:24 |
| santa_ | Section: oldlibs | 22:24 |
| santa_ | ugh | 22:24 |
| santa_ | sorry | 22:24 |
| santa_ | I meant to use paste bin | 22:24 |
| santa_ | cjwatson: yes, it was an accident, I tought I was pasting the pastebin link, sorry | 22:24 |
| santa_ | infinity: https://paste.kde.org/pezttjezs | 22:24 |
| infinity | santa_: Okay, slightly better, but one thing you should still change, then. | 22:24 |
| santa_ | ok, what is it? | 22:25 |
| infinity | santa_: The Breaks/Replace from p-d to p-d-private and p-d-updater should be Conflicts/Replaces. | 22:25 |
| infinity | santa_: That'll hint frontends to consider completely removing the old packages. | 22:25 |
| santa_ | oh well, that came from debian | 22:25 |
| infinity | santa_: (ie: just move those two packages from Breaks to Conflicts) | 22:25 |
| infinity | santa_: Yeah, most DDs don't seem to understand dpkg relations any better than most UDs. :P | 22:26 |
| santa_ | that's tricky sometimes | 22:26 |
| infinity | santa_: Breaks/Replaces is for file takeover, Conflicts/Replaces is for whole package takeover. | 22:26 |
| santa_ | I wasn't aware, I used to use transitional packages + versioned Breaks/Replaces. godd to know | 22:27 |
| santa_ | * good | 22:27 |
| infinity | santa_: If you were keeping the transitionals, versioned B/R would be correct. | 22:27 |
| infinity | santa_: Since you're effectively keeping the transitional installed, but moving the files. | 22:27 |
| infinity | santa_: But without the transitionals, when the goal is total removal of the old packages, Conflicts is correct. | 22:28 |
| santa_ | ah, ok. I get you | 22:28 |
| santa_ | so, I will rebuild the thing once again, let's hope it works | 22:28 |
| infinity | santa_: Otherwise, seems sane enough. Can't be worse than the current version, where the transitionals do literally nothing. ;) | 22:29 |
| santa_ | when I tested, aparently it worked. not today | 22:29 |
| santa_ | I guess I did something wrong when testing | 22:30 |
| infinity | We all do. | 22:30 |
| infinity | Being too close to the solution never helps. | 22:30 |
| infinity | (Hence the value in review and QA being other people) | 22:30 |
| infinity | santa_: Another nice way to remember when to use Conflicts and Breaks is whether or not the correct expression should be versioned. | 22:33 |
| santa_ | yeah | 22:33 |
| infinity | santa_: So, say I'm moving a file from A to B, but want both to be installed (like in a transitional, or just shuffling packaging around), it's versioned, and thus breaks. | 22:33 |
| infinity | santa_: But in a case where you want the packages to not coexist ever, it's unversioned, and a conflict. | 22:34 |
| santa_ | yeah I maded that ones a lot of times | 22:34 |
| santa_ | so the conflicts/breaks to take over a package ... should be ... unversioned, right? | 22:34 |
| infinity | Conflicts/Replaces | 22:34 |
| infinity | Should be unversioned, though versioned doesn't hurt. | 22:34 |
| infinity | The only reason to version it would be if you think those packages may come back some day and bite you. :P | 22:35 |
| infinity | But if they're gone for good, it should be unversioned, ideally. | 22:35 |
| santa_ | ok, and yes I meant replaces | 22:35 |
| infinity | Makes apt think a tiny bit harder when it's versioned and doesn't need to be, but it's not world-ending. | 22:35 |
| infinity | santa_: I suspect the real confusion for most people is the meaning of Replaces, because it does double-duty. | 22:38 |
| infinity | santa_: On its own (or with a Breaks, which is more correct now that we have Breaks), it means "I'm overwriting some files", but with Conflicts, it means "I'm taking over this package entirely, make it go away". | 22:38 |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.15.2+16.10.3] | 22:39 | |
| infinity | dpkg could probably do with a few more relationships to avoid having the tuples. :P | 22:39 |
| infinity | But oh well. | 22:40 |
| slangasek | flocculant, sakrecoer: ubuntustudio build never finished (same problem again on the buildds), retrying again now that the buildd manager stuff should be fixed | 22:42 |
| santa_ | infinity: I'm going to test this https://paste.kde.org/psrnwmiea any other suggestion? | 22:51 |
| slangasek | infinity, cyphermox: so the problem with the mirroring was a stale cronjob that had been hanging around since right after the system booted, which had a record in etc/.build-image-set-pids. As long as there is any existing entry in that file when multipidfile.held() is called, sync_local_mirror() will do nothing but "wait for the mirror to sync", which only tries to take a lock - and if it | 22:51 |
| slangasek | succeeds in taking the lock it thinks everything's hunky-dory | 22:51 |
| cjwatson | It's possible I cleared one lock and forgot to clear the other; sorry | 22:52 |
| slangasek | infinity, cyphermox: in short, lib/cdimage/build.py:sync_local_mirror() does not in any way ensure that the ftp mirror is up to date | 22:52 |
| cjwatson | FWIW multipidfile could be improved in this regard (it wasn't possible with semaphore, but is with multipidfile) | 22:52 |
| cjwatson | It could fairly easily do a kill(pid, 0) on each to see if it's still alive | 22:53 |
| slangasek | cjwatson: I don't think the problem was clearing of stale lockfiles. the pids listed there were all running | 22:53 |
| cjwatson | Not perfect but there's at least some probability that it would handle the reboot case | 22:53 |
| cjwatson | Must have been a pid collision in that case | 22:53 |
| slangasek | the problem is that, if there's always at least one pid listed there due to a process running, all the later jobs assume that the first one took care of getting it an up-to-date mirror | 22:53 |
| slangasek | cjwatson: the problematic one was a pid that had genuinely been running since shortly after reboot | 22:54 |
| cjwatson | Yeah, but if the first run went "oh, all these pids are stale" and ditched them, that would help in at least some cases | 22:54 |
| slangasek | but anyway, the current logic is subject to a failure that, if we had no gaps in time when there was not a running job, the ftp mirror is never updated | 22:54 |
| cjwatson | This is basically a necessary failure mode in supporting parallel builds; the game is to make it as unlikely as possible | 22:55 |
| slangasek | cjwatson: why do we not have each build unconditionally rerun the sync upon taking the lock? | 22:55 |
| cjwatson | Because then it might sync under the feet of another build and cause chaos | 22:55 |
| slangasek | right | 22:56 |
| cjwatson | The current code guarantees that the mirror does not change during a build | 22:56 |
| slangasek | we have byhash sources available now, I think, yes? | 22:56 |
| infinity | I generally manually sync the mirror when doing milestones (and definitely final releases) anyway. | 22:56 |
| cjwatson | For some suites | 22:56 |
| infinity | But it's definitely suboptimal for dailies. | 22:56 |
| slangasek | infinity: as of my morning, the mirror was 6 days out of date | 22:57 |
| infinity | slangasek: Yeah, I forgot to do it (see: generally) for last night's respin. | 22:57 |
| slangasek | k | 22:57 |
| infinity | Though I also knew there was another respin coming. | 22:57 |
| infinity | Yay, kernel. :/ | 22:57 |
| wxl | another respin yay | 22:58 |
| slangasek | cjwatson: which suites lack byhash? ones that we still build for? | 22:58 |
| wxl | so i assume we're going to delay release until friday then? | 22:58 |
| infinity | As for the "if we have back-to-back jobs, it'll never update" issue, that would be papered over by stopping the staggered cron madness and just doing everything in parallel at one specific time. | 22:58 |
| infinity | Then the machine would be (hopefully) guaranteed idle for some chunks. | 22:59 |
| infinity | But that's not a solution, just a bandaid. | 22:59 |
| cjwatson | slangasek: trusty-updates | 22:59 |
| infinity | cjwatson: We don't build trusty anymore. | 22:59 |
| cjwatson | ah | 22:59 |
| slangasek | infinity: the only kernel issue I'm aware of is the one that affects cloud images only; were there other kernel issues warranting respins more generally? | 22:59 |
| cjwatson | maybe it's tolerable then | 22:59 |
| infinity | Last point release was a month ago. | 22:59 |
| infinity | slangasek: s390x no worky. | 22:59 |
| slangasek | infinity: right | 22:59 |
| cjwatson | I don't think back-to-back jobs are the issue, anyway. | 23:00 |
| cjwatson | nusakan doesn't do so much that there aren't some occasions when a build starts and is the only one legitimately running. | 23:00 |
| infinity | No, in practice, back-to-back jobs haven't been a big issue, it's just a potential issue with the locking method. | 23:00 |
| cjwatson | If it's locked for six days, it's confused, not too busy. | 23:00 |
| * infinity nods. | 23:00 | |
| slangasek | cjwatson, infinity, cyphermox: so it seems to me that having sync_local_mirror always do a --no-delete rsync in the parallel builds case would give better behavior | 23:00 |
| slangasek | cjwatson: indeed | 23:01 |
| slangasek | but a more graceful failure would be nice :) | 23:01 |
| cjwatson | Wait, we actually do test for PID existence in multipidfile anyway. | 23:01 |
| cjwatson | So apparently I thought of that. | 23:01 |
| cjwatson | We could also have the locking mechanisms ignore locks older than system uptime. | 23:01 |
| slangasek | in this case it really wasn't | 23:01 |
| cjwatson | It was the first time it ran. | 23:02 |
| slangasek | the process was alive, and had been dawdling since the 12th | 23:02 |
| cjwatson | Which process? | 23:02 |
| slangasek | pid 29869, which I've since killed | 23:02 |
| cjwatson | I mean which image build | 23:02 |
| infinity | slangasek: With trusty out of the way, a --no-delete on parallel builds would indeed seem reasonable. | 23:03 |
| infinity | Well. Hrm. | 23:03 |
| slangasek | cjwatson: it's out of scrollback now, but I /think/ it was a kubuntu build | 23:03 |
| infinity | Maybe not that reasonable, though. | 23:03 |
| infinity | The way I do a milestone build is to literally run them *all* in parallel. | 23:03 |
| infinity | That shouldn't trigger 10 rsyncs all competing. | 23:03 |
| cjwatson | Hm, yes, http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu/yakkety/daily-live-20160912.log suggests being stuck. | 23:04 |
| cjwatson | OK, if it was genuinely a stuck build then fine, but I would contend that nobody noticing a stuck build (or it timing out by itself) for a week is also a problem | 23:05 |
| infinity | Yeah, I don't disagree with that assertion. | 23:05 |
| slangasek | infinity: they wouldn't need to compete, they would each take the lock first before syncing... and a bit of extra time spent checking that there's nothing to sync is surely better in the general case than having the last-scheduled livefs build wind up with a non-matching apt pool, say | 23:06 |
| cjwatson | You could easily have been confused in six months instead when nusakan ran out of disk space. | 23:06 |
| slangasek | heh | 23:06 |
| slangasek | yes, timeout would also be good | 23:06 |
| infinity | slangasek: But we also want consistency through the life of a build. by-hash doesn't actually solve that. | 23:07 |
| infinity | slangasek: As in, if I germinate against the archive, then you update it, then I do debian-cd things against the new archive, Packages has changed. | 23:07 |
| slangasek | infinity: --no-delete sync + byhash does, surely? | 23:07 |
| slangasek | ah | 23:07 |
| slangasek | because there's no build-local apt cache | 23:07 |
| slangasek | ho-hum | 23:08 |
| infinity | Right, by-hash only solves a world where you apt-get update once and never again, and that's your authoritative source for all things. | 23:08 |
| cjwatson | I think the bit that failed to time out here is probably tracker_set_rebuild_status. | 23:08 |
| infinity | But we operate directly on the Packages files, not an apt list archive. | 23:08 |
| cjwatson | Since there was lots of other failed-to-contact-tracker noise around the same time. | 23:08 |
| slangasek | infinity: ok | 23:09 |
| infinity | Anyhow, I do agree that not noticing a stuck build is really the more interesting problem. :P | 23:09 |
| cjwatson | So maybe that's enough information for somebody to insert a timeout. | 23:09 |
| cjwatson | Also perhaps there should be a watchdog of some kind for the whole build. | 23:09 |
| santa_ | infinity: last patch I pasted works, I will try convince someone to sponsor the upload, any objections? | 23:09 |
| cjwatson | cdimage.osextras.run_bounded exists already; not sure what would happen if you tried running the entire build inside it, but it's perhaps worth trying. | 23:10 |
| infinity | santa_: That looks good to me, indeed. | 23:11 |
| cjwatson | (Or indeed cdimage/bin/kill-after, for crontab purposes) | 23:11 |
| cjwatson | Probably better for cdimage.build to apply it to itself though, if you're taking that route | 23:11 |
| * infinity thinks it might be shawarma time. | 23:12 | |
| slangasek | http://www.shawarmageddon.com/ | 23:13 |
| infinity | slangasek: I... Just.... Wow. Road trip? | 23:14 |
| slangasek | I was mad to learn that Reno got that name before Portland managed to | 23:15 |
| infinity | slangasek: I've never considered Reno cool in any way, this is upsetting my world view. | 23:16 |
| * infinity -> food. | 23:17 | |
| cjwatson | Mine's a falafel wrap and a crimson death. I accept deliveries. | 23:23 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (yakkety-proposed/universe) [0.68 => 0.69] (ubuntugnome) | 23:41 | |
| * xnox spies with a little eye a working kernel | 23:43 | |
| tsimonq2 | xnox: good stuff! | 23:49 |
| -queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu474 => 20101020ubuntu475] (core) | 23:49 | |
| * tsimonq2 spots with a little eye an email with the subject "[yakkety] linux 4.8.0-14.15 uploaded (ABI bump)" | 23:50 | |
| xnox | slangasek, infinity - debian-installer uploaded, diff already generated. | 23:50 |
| xnox | please accept and then i'll test the d-i bits as soon as they are built on s390x. then it should be good to go. | 23:51 |
| tsimonq2 | somebody should change the topic here | 23:51 |
| tsimonq2 | s/beta 1/final beta/ | 23:51 |
| marco-parillo | I see the first release candidates for Beta 2 are up. http://iso.qa.ubuntu.com/qatracker/milestones/367/builds I have tested the live ISO. How likely will there be a re-spin tomorrow? That way I reduce the number of installs I try. | 23:51 |
| -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu475] | 23:52 | |
| slangasek | xnox: done | 23:52 |
| === slangasek changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1 | Archive: feature freeze, final beta freeze | Yakkety Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis | ||
| slangasek | marco-parillo: likely | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
