| * Mirv recommends people to switch the side of the street if they see infinity walking towards them | 04:57 | |
| * acheronuk hands out a pile of stab proof vests just in case | 06:34 | |
| Mirv | not that I'd see any other blocker than the tag in the bug related to kernel 4.6 | 07:42 |
|---|---|---|
| * acheronuk glares at pesky tag | 07:53 | |
| Laney | please could someone remove unity-greeter/s390x from yakkety-proposed? | 10:17 |
| Laney | I just uploaded 16.10.2.2 with a build-dep on upstart so it doesn't come back | 10:18 |
| xnox | looking at unity8 adt test failure | 11:44 |
| xnox | it claims not able to find Lcov or gcovr | 11:44 |
| xnox | i guess it's a case of transitive adt test dependencies gone missing? | 11:44 |
| xnox | Mirv, is this something you can look into, or who should I ping about src:unity8 ? ^ | 11:44 |
| xnox | because apperantly my biometryd upload regressed unity8 adt | 11:45 |
| Laney | xnox: nah we need to run it with all-proposed | 11:46 |
| xnox | ah | 11:46 |
| Laney | once this $£"$"% gets migrated that won't be necessary any more | 11:46 |
| Laney | however... | 11:47 |
| Laney | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 | 11:47 |
| Laney | it got promoted without its deps? | 11:47 |
| Mirv | xnox: as Laney said | 11:47 |
| * xnox slowly backs away | 11:47 | |
| Mirv | ouch, how did that happen | 11:47 |
| Laney | https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1613638 | 11:49 |
| ubot5 | Launchpad bug 1613638 in unity8 (Ubuntu) "[MIR] unity8" [Undecided,Fix released] | 11:49 |
| Laney | jumped the gun? | 11:49 |
| Laney | I think it should be demoted again | 11:50 |
| Laney | doko's offline though | 11:50 |
| xnox | Laney, he is sending emails though.... | 11:52 |
| Laney | xnox: about promoting things? | 11:53 |
| xnox | Laney, just 1on1 emails about things i'm uploading (replies to changes mailing list) | 11:55 |
| xnox | he is online, just not on irc. | 11:55 |
| Laney | ok | 11:56 |
| * Laney emailzzzzzzzzzz | 11:56 | |
| flocculant | afternoon peeps - tested completely with xubuntu, half way through testing with ubuntu daily - seems no network on either daily today | 12:18 |
| flocculant | pitti: could the lack of network on the dailies (and the installed version) be something to do withhttp://changelogs.ubuntu.com/changelogs/pool/main/n/network-manager/network-manager_1.2.2-0ubuntu8/changelog ? | 12:24 |
| pitti | flocculant: this needs https://launchpad.net/ubuntu/+source/livecd-rootfs/2.427 too | 13:52 |
| pitti | flocculant: I noticed that e. g. the last ubuntu desktop dailies were still built with 426, so ethernet wouldn't work via NM indeed | 13:52 |
| pitti | flocculant: in theory tomorrow's dailies should be fine again, otherwise I'll investigate on Monday | 13:53 |
| Laney | pitti: flocculant: I've kicked a rebuild to verify | 13:55 |
| pitti | → oh, nice, thanks Laney: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu/+build/72979 | 13:58 |
| pitti | I uploaded both NM and livecd-rootfs yesterday at the same time, but apparently some odd timing somewhere | 13:58 |
| pitti | or I messed up the livecd-rootfs change, which is plausible :) | 13:59 |
| Laney | erm, hang on | 13:59 |
| Laney | https://launchpadlibrarian.net/279800397/buildlog_ubuntu_yakkety_amd64_ubuntu_BUILDING.txt.gz <- 2.427 | 13:59 |
| pitti | Laney: actually, the one from 5 hours ago was already using 247 | 14:00 |
| pitti | sorry, I looked this morning, and got the 20 hours old one | 14:00 |
| * pitti rsyncs | 14:00 | |
| Laney | I wonder if I got this one or the previous | 14:00 |
| pitti | I should also make this more verbose | 14:01 |
| pitti | this == http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1431 | 14:01 |
| Laney | I already had that one it seems | 14:01 |
| Laney | at least zsync thinks it's 100% complete | 14:01 |
| pitti | confirmed, no /etc/netplan/01-network-manager-all.yaml there | 14:03 |
| pitti | ogra_, infinity: do you happen to see why http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1431 would not actually do anything? AFAICS "chroot/" should be the live file system in construction, no? | 14:08 |
| pitti | my first guess is that this hook runs before installing ubuntu-desktop | 14:13 |
| pitti | I see hooks for ubuntu-core, cpc, desktop-next, and touch, but none for "plain" ubuntu/xubuntu etc. | 14:14 |
| ogra_ | pitti, we dont build yakkety ubuntu-core | 14:14 |
| pitti | ogra_: I want to do that when building desktop images, not -core | 14:14 |
| ogra_ | (please dont trigger any builds manually, we also stopped using cdimage for that and the publishing folders have placeholders we do not want deleted) | 14:14 |
| pitti | l | 14:15 |
| ogra_ | oops, i got tricked by ~ubuntu-core-dev :P | 14:15 |
| Laney | haha | 14:16 |
| pitti | ……………………ubuntu-touch:*|ubuntu-touch-custom:*|ubuntu-core:system-image|ubuntu-desktop-next:system-image|ubuntu-cpc:*) | 14:17 |
| pitti | …………………………………………cp -af /usr/share/livecd-rootfs/live-build/${PROJECT}/* \ | 14:17 |
| pitti | ………………………………………………………………config/ | 14:17 |
| pitti | oh, this might be the bit that installs hooks for those projects | 14:17 |
| ogra_ | pitti, look into adding a hook to live-build/$project/hooks instead | 14:17 |
| pitti | so apparently we just don't have any hooks for the desktop flavors (this isn't flavor specific at all) | 14:17 |
| ogra_ | well, then auto/build is fine but there the place you add it is essential | 14:18 |
| pitti | this applies to every kind of image build; so live-build/auto/build runs before installing packages, and there's no script which runs after? | 14:18 |
| pitti | ogra_: I added it at the very end, but it seems that auto/build is not actually the thing that installs packages? | 14:21 |
| Laney | pitti: I don't know about that - you can see in the log that "Checking size of /usr/share/doc" is in the log after packages are installed | 14:21 |
| Laney | but it's earlier in auto/build than your code | 14:22 |
| ogra_ | live-build/auto/build runs both, before and after | 14:22 |
| pitti | oh, so I did that *too* late | 14:22 |
| pitti | presumably after the squashfs | 14:23 |
| Laney | there's a mksquashfs after this script | 14:24 |
| ogra_ | it really depends ... | 14:24 |
| ogra_ | some projects roll their tarballs from within live-build/auto/build ... | 14:25 |
| pitti | http://paste.ubuntu.com/23070370/ | 14:25 |
| ogra_ | looking at the current code, you want to add it *before* line 203 | 14:25 |
| pitti | ogra_: thanks for the hint about "Checking size of doc/, to relate log output with the script | 14:26 |
| ogra_ | that was Laney :) | 14:26 |
| ogra_ | but yeah ... there are multipple subshell calls in the live-build/auto/build script | 14:26 |
| ogra_ | you want to be in the one above 203 | 14:27 |
| pitti | right, the above patch does that now | 14:27 |
| ogra_ | yeah, that should work | 14:28 |
| pitti | flocculant, Laney, ogra_: livecd-rootfs_2.428_source.changes uploaded; sorry about messing this up | 14:29 |
| pitti | Laney, ogra_: thanks for your help! | 14:29 |
| ogra_ | no worries | 14:29 |
| Laney | ah | 14:29 |
| Laney | it's the "lb binary" that you need to be before | 14:29 |
| Laney | maketh sense | 14:29 |
| * Laney didn't see that sneaky line there | 14:30 | |
| ogra_ | yeah .. the subshell braces make it really hard to read | 14:31 |
| infinity | pitti: Are you sure that doesn't belong in casper? | 15:01 |
| infinity | pitti: As in, is the plan for desktop systems to be all-nm-all-the-time, or was your intent to just do that for live sessions? | 15:02 |
| infinity | pitti: Well, actually, I guess that would be the plan for desktops as a default. But if server starts preinstalling NM, your hack goes sideways too. :) | 15:03 |
| ogra_ | well, but servers are supposed to also use the new infra, just not with NM ... at least the "mkdir /etc/netplan" is generic | 15:06 |
| ogra_ | probably the patch should be split ... | 15:06 |
| sil2100 | infinity: hey! Any news on our yakkety-proposed issues? ;) | 15:06 |
| infinity | sil2100: Every fixed bug pops up another. Next is fakeroot segfaulting on i386 and armhf. :/ | 15:07 |
| sil2100 | How I hate fakeroot | 15:09 |
| infinity | ogra_: I'd be more inclined to say this belongs in installers, where networking has always been. Which implies casper for the live session. | 15:09 |
| infinity | pitti: ^ | 15:09 |
| infinity | A rootfs can't make a one-size-fits-all choice here, probably. | 15:09 |
| ogra_ | hmm, indeed | 15:10 |
| infinity | sil2100: Not as much as I'm going to hate it by the time this day is over. :/ | 15:11 |
| infinity | sil2100: It's not exactly fun to debug. | 15:11 |
| infinity | sil2100: At least the kernel is sorted? One step forward, one back... | 15:13 |
| slangasek | Mirv: who did you talk to from the kernel team about their update landing in yakkety? | 15:28 |
| slangasek | infinity: why do we have both a blocking bug and a block hint for linux? Shouldn't the blocking bug be sufficient? | 15:28 |
| infinity | slangasek: The blocking bug is meant to go away in favour of the hint, I think. Or something. Andy, Brad, and I need to sort out the master plan there. :P | 15:29 |
| infinity | slangasek: Anyhow, it can be unblocked. But it won't go in. | 15:29 |
| slangasek | infinity: AIUI apw is on vacation currently; and linux is currently holding up the world because linux-tools; so I'd like to know who I'm blaming for things | 15:30 |
| Mirv | slangasek: no-one answered but infinity already earlier removed the arm64 problematic 4.6 kernel from proposed, replacing it with a 4.4 rebuild (only which didn't build with gcc6) | 15:30 |
| infinity | slangasek: You can blame me, it's my kernel, and I'm happy to release it. But, like I said, it won't go in anyway. d-i is FTBFS on two arches due to a fakeroot segv. | 15:30 |
| Mirv | slangasek: so the bug blocking tag actually talks about the 4.6 that is no more | 15:30 |
| slangasek | infinity: how does a d-i FTBFS block this? | 15:30 |
| infinity | slangasek: kernel can't migrate without d-i. | 15:31 |
| slangasek | because? | 15:31 |
| infinity | Because of dependencies? | 15:31 |
| slangasek | ok | 15:32 |
| infinity | slangasek: If you love debugging fakeroot, feel free to play along. I got pointers from Clint, but am just about to dive into it when waking up is complete. | 15:33 |
| slangasek | infinity: this is blocking the world. What's in "your kernel" that needs to go in? All we need is a rebuild of linux-tools against current binutils; could we bump the current linux aside, do a no-change rebuild of the kernel in yakkety, get that through, and then unpick the fakeroot thing? | 15:33 |
| slangasek | this transition has been blocking the world for weeks at this point | 15:34 |
| slangasek | and speaking of which, is the autoimporter turned off, so other things stop sneaking in from unstable and delaying us? | 15:34 |
| infinity | slangasek: That is a no-change rebuild, but with a new ABI to not clash with xenial. | 15:35 |
| slangasek | why does a no-change rebuild get a new ABI? | 15:35 |
| infinity | "to not clash with xenial". | 15:35 |
| infinity | And because ABI == package name == must be unique if you want signed modules to work. | 15:36 |
| pitti | infinity: as far as I understood slangasek back then, we wanted NM to manage all devices for "desktop" installs (where we pre-install NM), but if you apt install n-m on an existing system we don't want it to take over interfaces managed by networkd | 15:36 |
| pitti | infinity: so instead of trying to come up with a fuzzy definition of "what is desktop", I think "n-m is preinstalled" is what we actually want | 15:36 |
| slangasek | infinity: I don't follow how there's a clash with xenial | 15:36 |
| infinity | The concept of non-abi-bumping kernels went out the window with ephemeral signing keys. | 15:36 |
| pitti | infinity: and no, this isn't specific to the live system (thus not in casper) | 15:36 |
| slangasek | ugh | 15:36 |
| slangasek | infinity: then I think we should accept breaking installability of linux-tools while this wends its way through | 15:37 |
| slangasek | however, it seems address-book-app and indicators-client have reset | 15:37 |
| infinity | slangasek: Well, we can break linux-tools, or we can break server ISOs. | 15:38 |
| Laney | Somebody prematurely promoted unity8 | 15:38 |
| Laney | well, doko. :P | 15:38 |
| infinity | Someone should unpromote it? | 15:38 |
| Laney | I emailed him | 15:38 |
| Laney | do i | 15:38 |
| Laney | t | 15:38 |
| infinity | Bug? | 15:39 |
| infinity | Found it. | 15:40 |
| Laney | 'k | 15:40 |
| slangasek | infinity: are you demoting? I have it here from c-m | 15:40 |
| infinity | slangasek: I am. | 15:41 |
| slangasek | ok | 15:41 |
| slangasek | I'll write up the force hint | 15:41 |
| infinity | Err, wat? | 15:42 |
| slangasek | to break linux-tools? | 15:42 |
| infinity | I'd rather break server ISOs, to be honest. That has no visible archive impact. | 15:42 |
| infinity | ie: force the kernel in. | 15:42 |
| slangasek | both require a force hint | 15:42 |
| infinity | If you force the kernel, the rest will just flood in without hinting. | 15:42 |
| infinity | Am I not awake enough to use change-override correctly, or is LP busted today? | 15:43 |
| infinity | Oh, I can't spell universe. | 15:43 |
| infinity | Apparently. | 15:43 |
| ogra_ | ünivärse | 15:45 |
| infinity | I'm not Swedish. | 15:45 |
| pitti | ogra_: no, junivärs clearly | 15:45 |
| ogra_ | ! | 15:46 |
| infinity | pitti: Maybe. I dunno. Still feels like this belongs to installers, not to filesystem builders. | 15:46 |
| infinity | Our filesystems have never shipped a working network config. | 15:46 |
| infinity | Well, except for the live session NM case, I guess. | 15:47 |
| pitti | infinity: it's not configuring any network devices, just telling NM that it should manage all devices instaead of just wifi+wwan | 15:47 |
| infinity | pitti: Right, but if that config doesn't belong in the package, it belongs in the installer, generally. | 15:47 |
| pitti | infinity: alternatively we could put this into nm.postinst if there is some robust way for it to see if it installs into an OS image build or onto an actually running syste | 15:47 |
| pitti | m | 15:47 |
| slangasek | infinity: I've hinted the lot, linux included; this way if something else gets uploaded in the meantime we get to look at it rather than just randomly increasing the uninstallability count further | 15:48 |
| infinity | pitti: livecd-rootfs's job (well, before system-image and core came along, ignore their crazy hooks) is to provide a pristine image, not a working preinstalled image. | 15:48 |
| slangasek | infinity: and I've dropped the block-proposed tag from the bug | 15:48 |
| pitti | infinity: well, I wouldn't like to duplicate this logic into ubiquity, cloud-init, casper, and another handful of installers | 15:50 |
| pitti | refining nm.postinst sounds good, if we find a good test there | 15:50 |
| infinity | pitti: And, yet, that's what having multiple installers tends to mean. :/ | 15:50 |
| infinity | pitti: I don't see how it can reliably belong in a postinst either. | 15:50 |
| pitti | putting it into image builds seemed both robust and central to me | 15:51 |
| pitti | as that's what it is effectively -- policy based on the kind of image we build | 15:51 |
| infinity | pitti: Okay, ignore the desktop case for now. If I install a server ISO, configure a network (which is ifupdown today, but won't be Very Soon, I assume), I also need a netplan config that tells it to DTRT, right? | 15:52 |
| infinity | pitti: So, installers already need to know how to write that config. | 15:52 |
| infinity | pitti: Or, so I would think. | 15:52 |
| pitti | infinity: right, for the actual devices you configure | 15:52 |
| slangasek | the server iso doesn't need a netplan config to declare the renderer policy because it uses the default | 15:53 |
| pitti | right | 15:53 |
| slangasek | it just needs the netplan config for the devices that are configured | 15:53 |
| slangasek | and that obviously belongs in the installer | 15:53 |
| pitti | and the default NM behaviour is now "manage wifi and wlan, ignore everything else" | 15:53 |
| infinity | But... That's going to break upgrades. | 15:53 |
| slangasek | the desktop ISO needs something different; it needs the policy saying "NM owns all the devices", which is a policy related to the image you install from rather than the packages you have | 15:53 |
| pitti | but for desktops (or, IMHO, more precisely: images that ship NM by default) we want NM to manage everything | 15:53 |
| infinity | The "default" needs to be smarter than this. | 15:54 |
| infinity | Unless we don't intend to ever migrate people to netplan. | 15:54 |
| slangasek | infinity: upgrades won't have any netplan yaml on them so by default things will continue to do what they do | 15:54 |
| infinity | Given that probably 99% of our desktop users use NM for all interfaces. | 15:54 |
| pitti | also, upgrading NM disables the "restricted" policy | 15:54 |
| slangasek | the upgrade path doesn't need to land at the same time as the installer support. | 15:54 |
| slangasek | except for that bit that pitti mentions for NM | 15:55 |
| slangasek | we have actually worked through this already | 15:55 |
| pitti | install xenial NM, upgrade to y → NM manages everything | 15:55 |
| pitti | install yakkety NM → NM only manages wifi/wwan | 15:55 |
| pitti | and desktop images ship a policy snippet that tell it to again manage everything | 15:55 |
| infinity | And if I had an ifupdown config, and NM ignoring it? | 15:55 |
| infinity | (as it does) | 15:55 |
| pitti | that's how I understood the discussion at the Athens sprint | 15:55 |
| infinity | Anyhow. I didn't mean to go down the upgrade rabbit hole. | 15:55 |
| pitti | infinity: NM ignores devices that are configured in ifupdown | 15:56 |
| infinity | A config file that says which interfaces are managed by what is an installer config file. That's all I was arguing. | 15:56 |
| pitti | correct | 15:56 |
| infinity | If installers configure interfaces, they know which interfaces are configured by what. | 15:56 |
| pitti | well, a file that says "ens3 is configured like this" | 15:56 |
| infinity | The installer knows the inverse too. | 15:56 |
| pitti | the livecd-rootfs bit is generic policy, not particular interface config | 15:57 |
| infinity | It knows if you chose no manual configuration and, thus, are all-nm. | 15:57 |
| infinity | Or whatever. | 15:57 |
| infinity | pitti: What happens in a ubiquity install (hypotetically, I assume this hasn't landed yet) if I manually configure an interface? Is it going to inject a manual eth0 config into NM, or something netplan/systemdish, or...? | 15:58 |
| infinity | If the answer is anything other than "everything will always be network-manager", that config file doesn't belong on a pristing livefs. | 15:59 |
| infinity | pristine* | 15:59 |
| slangasek | what do you mean by "inject a manual eth0 config"? | 15:59 |
| slangasek | sorry | 15:59 |
| slangasek | what do you mean by "manually configure an interface"? | 15:59 |
| infinity | slangasek: Set up a static IP on my ethernet adapter. | 15:59 |
| infinity | slangasek: For instance. | 16:00 |
| slangasek | how? | 16:00 |
| pitti | right now ubiquity just copies the NM connections | 16:00 |
| infinity | Ask nicely? | 16:00 |
| pitti | not sure if that should stay or if this should somehow be converted to a netplan config (the former is much simpler obviously) | 16:00 |
| infinity | Oh, I guess ubiquity does just use NM for that anyway, doesn't it? It's not something I've done in a long time. | 16:00 |
| pitti | yes | 16:00 |
| pitti | d-i, subiquity etc. are different beasts | 16:01 |
| pitti | d-i currently writes /e/n/i, and should move to netplan | 16:01 |
| slangasek | pitti: yes, the latter is out of scope | 16:01 |
| pitti | same for subiquity, cloud-init etc. | 16:01 |
| slangasek | you twiddle nm-applet, you get a config in NM | 16:01 |
| slangasek | but nm-applet needs to first be told that it's allowed to mess with eth0, which by default in the package it wouldn't be | 16:01 |
| slangasek | to ensure the correct experience when installing NM on a non-desktop system | 16:01 |
| infinity | I really dislike this desktop/not-desktop split being anywhere but installers. | 16:02 |
| infinity | If I netboot d-i and install a desktop, I'll get a different experience. | 16:02 |
| pitti | right, then NM wouldn't manage ethernets by default | 16:03 |
| pitti | but that's independent of whether it's livecd-rootfs or the installer who writes that policy snippet | 16:03 |
| pitti | and you would currently have an /e/n/i for your ethernets, which you don't have with a desktop isntall | 16:04 |
| pitti | so in some way it's the same experience | 16:04 |
| infinity | Well, yes and no. I guess it's about mindset. If we say "this is an installer thing", then we fix the installers to do what we want, instead of saying "this ISO behaves this way". | 16:04 |
| slangasek | you will get a different experience anyway when netbooting d-i to install the desktop, because we do not support installing the desktop with d-i netboot. | 16:05 |
| Laney | We should turn off auto-sync | 16:05 |
| infinity | We should. | 16:05 |
| pitti | not just "we will", we already do (cf. getting an /e/n/i or not) | 16:05 |
| slangasek | where's the button for turning off autosync? | 16:05 |
| infinity | I overworked myself yesterday and forgot to freeze. | 16:06 |
| Laney | I think it's adding --dry-run in the crontab | 16:06 |
| Laney | Can do that | 16:06 |
| infinity | Yeah, snakefruit crontab. | 16:06 |
| Laney | And have done | 16:06 |
| Laney | happy DIF | 16:06 |
| infinity | slangasek: Unless "we don't support doing it that way" becomes "we acitively prohibit doing it that way", it's a pretty lousy argument, IMO. | 16:07 |
| infinity | But I'm also cranky. Obviously. | 16:07 |
| slangasek | Laney: thanks :) | 16:08 |
| Laney | I'll announce feature freeze too | 16:08 |
| Laney | brain isn't feeling up to very much else | 16:08 |
| infinity | Laney: My hero. | 16:08 |
| Laney | it's that or design a hook interface for the appstream generator | 16:09 |
| infinity | Laney: I'm sure it's still Thursday somewhere. | 16:09 |
| infinity | Like, in a gravity well or something. | 16:09 |
| slangasek | infinity: the argument is "it's more work to do it that way to facilitate this use case that *we do not support*" | 16:09 |
| jbicha | I wanted to upload bug 1613291 but I've been waiting this week for qt to migrate first, can I still upload today or do I need to wait until after Beta? | 16:12 |
| ubot5 | bug 1613291 in evolution-data-server (Ubuntu) "Update evolution stack to 3.22" [Wishlist,In progress] https://launchpad.net/bugs/1613291 | 16:12 |
| Laney | can you get the transition done over the weekend? | 16:13 |
| cjwatson | Oh, excellent, I think that may be the first time !me implemented DIF post-new-auto-sync | 16:14 |
| jbicha | yes, there's one CI train package (syncevolution in universe) though | 16:14 |
| Laney | Doesn't the train implement proper ACLs now? | 16:14 |
| Laney | If not, you can dput it and submit a merge proposal to reconcile trunk | 16:15 |
| jbicha | I don't have push rights to https://code.launchpad.net/~phablet-team/syncevolution/ubuntu but yes since it's in universe I can just force it in | 16:15 |
| jbicha | and evolution-rss needs to be removed as s_eb128 ack'd on the bug | 16:16 |
| Laney | You might be able to use CI train | 16:16 |
| Laney | which does have push access | 16:16 |
| jbicha | can you point me to where I should look to try that? | 16:17 |
| Laney | jbicha: https://wiki.ubuntu.com/citrain/LandingProcess#landing | 16:20 |
| Laney | you can get robr_u to look it over | 16:20 |
| Laney | infinity: you haz moderation | 16:21 |
| infinity | Laney: Looking. | 16:21 |
| infinity | Laney: And approved. | 16:22 |
| === Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1 | Archive: feature 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 | ||
| flocculant | pitti Laney and anyone else involved - thanks :) | 16:27 |
| pitti | flocculant: no guarantee that the next image builds will actually work, but much higher chance now :) I'll keep watching out | 16:28 |
| flocculant | pitti: well I'll look tomorrow and see what happens :) | 16:29 |
| Laney | looks like Things just went in | 16:30 |
| flocculant | okey doke | 16:30 |
| flocculant | I'll soon shout out if needed - then wait for Monday :D | 16:31 |
| pitti | Laney: ooh -- you mean THINGS really, like half of -proposed | 16:31 |
| pitti | yay! | 16:31 |
| flocculant | :) | 16:32 |
| pitti | Friday evening is the BEST time to break yakkety | 16:32 |
| Laney | pitti: the power of the force hint | 16:32 |
| infinity | Laney: While you're being captain helpful, what are the odds you'd be willing to be on deck for Beta2? | 16:38 |
| infinity | s/Beta2/Beta1/ | 16:38 |
| infinity | The one next week. :P | 16:38 |
| flocculant | I'm so glad we've ignored those this cycle ... | 16:38 |
| Laney | infinity: Could do, if someone flavourish is on the other side | 16:44 |
| infinity | Laney: I'll leave that between you and the flavours, then. :) | 16:45 |
| infinity | Laney: We made it very clear last time that if they don't get their act together, we're not playing. | 16:45 |
| * Laney grimaces | 16:45 | |
| Laney | flexiondotorg: Can you dig someone up to release manage beta 1 please? :) | 16:45 |
| jbicha | just to be clear, can I start the evolution transition now? | 16:47 |
| Laney | Assuming everything is test built and going to go smoothly, no objection from me | 16:48 |
| jbicha | yes, I'll just need an AA to remove evolution-rss | 16:50 |
| Mirv | wow, don't wake me up, this is better than my dreams about Qt usually | 16:50 |
| Mirv | is now the time when I go file FFe about Qt 5.7? it's about time to get up-to-date Qt release in to archives </funnyness> | 16:51 |
| Mirv | sil2100: the transition is happening, I can start cleaning the unfinished issues latest on Monday, but let's see this through now first before immediately publishing the pending stuff | 16:52 |
| Laney | Mirv: you can probably turn CI train publishing back on now, I guess | 16:53 |
| sil2100 | \o/ | 16:54 |
| Mirv | Laney: we accumulated some manual backlog during the last few days, it's better to clean that up before accepting uncontrolled publications | 16:54 |
| * Laney shrugs | 16:56 | |
| jbicha | Laney: is that a yes on evolution then? | 16:57 |
| ginggs | xnox: i'm not sure you are the right person to ask, can we remove boost1.58? i think there are a few things to decruft | 17:00 |
| Laney | jbicha: Yeah, just don't break stuff. :) | 17:01 |
| ginggs | slangasek: can we remove fpc and rdeps on powerpc? debian bug #834644 has been filed | 17:03 |
| ubot5 | Debian bug 834644 in ftp.debian.org "RM: fpc reverse dependencies [powerpc] -- ROM; fpc doesn't build anymore on powerpc" [Normal,Open] http://bugs.debian.org/834644 | 17:03 |
| Mirv | pitti: do you have some special place you use for monitoring "recent things moving from proposed to release pocket"? | 17:12 |
| pitti | Mirv: no, just working off excuses.html | 17:12 |
| pitti | and for my own uploads I obviously get ACCEPTED mails | 17:12 |
| * pitti waves, have a nice weekend everyone! | 17:14 | |
| Mirv | ok | 17:14 |
| Mirv | have a nice weekend, especially infinity for all the efforts in the last few days (even if some of it still continues) | 17:15 |
| Mirv | I may do a thing or two during the weekend since there's so much pending that has been waiting, including powerpc GCC6 fix for Qt apps | 17:16 |
| Mirv | inbox is reminding me of all the LXQt, KDE autopkgtest, packagekit, seed and other fixes that I needed to do in the past weeks (by giving the release pocket notifications). it was a really long journey. | 17:22 |
| slangasek | Newly uninstallable packages in testing: | 17:53 |
| slangasek | * amd64: debian-installer-udebs | 17:53 |
| slangasek | * arm64: debian-installer-udebs, gcc-snapshot | 17:53 |
| slangasek | * armhf: debian-installer-udebs | 17:53 |
| slangasek | * i386: debian-installer-udebs | 17:53 |
| slangasek | * powerpc: debian-installer-udebs | 17:53 |
| slangasek | * ppc64el: debian-installer-udebs | 17:53 |
| slangasek | * s390x: debian-installer-udebs | 17:53 |
| slangasek | tada | 17:53 |
| slangasek | Mirv, infinity, sil2100: ^^ hint done; linux can take a bit longer to un-pick | 17:53 |
| slangasek | ginggs: fpc> if there's an open bug for this, can you remind me the number? | 17:55 |
| sil2100 | Ooh! | 17:58 |
| slangasek | robru: ^^ was that the reason that publishing was disabled? Can this then be reverted now? | 18:11 |
| jbicha | infinity: do you want a tracking bug for the issue where germinate is still pulling in old pkgs that shouldn't be in Ubuntu GNOME's Y seed any more? if so, where would I file that bug? | 18:11 |
| ginggs | slangasek: is it LP: #1562480 ? | 18:16 |
| ubot5 | Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480 | 18:16 |
| slangasek | ginggs: LGTM, thanks | 18:18 |
| Mirv | slangasek: that was the reason, to give infinity the peace of untangling the problems while not getting more packages delaying the transition into yakkety. I've made a short backlog of todo items in the last few days http://pad.ubuntu.com/yakkety-pending-landings but I've handled the really manual stuff now so I think robru can now indeed restore the functionality | 18:33 |
| acheronuk | Mirv: http://paste.ubuntu.com/23071193/ | 18:43 |
| Mirv | acheronuk: :D looking good! nice that even upgrading from a variety of PPAs works | 18:45 |
| acheronuk | Mirv: yep, it even unblocked some ppa stuff that had built against proposed :) | 18:46 |
| superm1 | can an AA please axe that appstream-glib upload ^, it seems to be causing crashes and needs closer looking | 21:18 |
| superm1 | thanks | 21:18 |
| slangasek | superm1: done | 21:22 |
| superm1 | thanks | 21:23 |
| sergiusens | slangasek mind taking a look at that ^ please? | 22:11 |
| slangasek | sergiusens: accepted | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!