[00:00] ok, I might some day [00:01] slangasek, infinity, you're the only ones ~active at this hour with "access to snakefruit", if you're around, could I please ask for a re-run of the regression here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity8 (https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests) [00:13] Saviq: looking [00:13] thanks [00:26] Saviq: ok, running: http://autopkgtest.ubuntu.com/running.shtml === shuduo-afk is now known as shuduo [05:41] jdstrand: I hinted apparmor [07:49] good morning [08:55] jdstrand: apparmor is still trapped by perl, but I hope we get that in RSN [08:56] cjwatson: php5 landed, uwsgi is a valid candidate [09:33] looking for a package/software-compoennt that uses kbuild that isnt kernel, uboot, busybox... anyone knows? [09:34] oh vbox [09:34] seems the only one using the kbuild package from archive in build-depends [09:34] of course doesnt mean that others have their kbuild inline [09:35] anyonw knows any smallish piece of soft let me know! [09:35] thanks [09:39] cjwatson: ok to steal your sbuild merge? [10:31] xnox: So what's the grub situation with s390x? Do we need it at all? [10:33] Odd_Bloke, this is not the bootloader you are looking for =) there is no grub on s390x as far as I can see =) [10:34] Odd_Bloke, there is /etc/zipl.conf and well zipl. [10:35] xnox: OK, cool; that's what I figured. :) [10:35] Odd_Bloke, there is this magic bootmap file. [10:35] Odd_Bloke, http://paste.ubuntu.com/14418965/ [10:36] so given the config file, zipl generates bootmap file, which can include the kernel+initrd+parameters inside it, or reference them on disk... magically. [10:36] and somehow this bootmap file is found by z/VM OS on disk and manages to be "executed" as the intial programme, by the inital programme loader.... aka "boot". [10:37] xnox: Would that zipl.conf work generally (it looks like it to me)? If not, do we have a good way of generating them? [10:38] Odd_Bloke, we don't currently have a good way to generate them (e.g. for cloud images / non-standard things) [10:38] Odd_Bloke, the d-i installer writes out a slightly longer version.... https://sources.debian.net/src/zipl-installer/0.0.28/debian/zipl-installer.postinst/ [10:38] which has default, timeout and both /boot/vmlinuz and /boot/vmlinuz.old "boot menu options" [10:39] OK. [10:40] Odd_Bloke, i wanted to write something like update-zipl, that would do something similar to our update-grub, and eg. detect all kernels and generate "Ubuntu", "Ubuntu recovery", and then all available kernels [normal|recovery] boot options. [10:40] Odd_Bloke, but i have not done something like that yet. [10:41] But once we find the right configuration, it doesn't need to have values plugged in for each different image build, which is good. :) [10:41] to me, that would be handy, and like useful / ubuntu-like. On the other hand average s390x user, is capable of modifying zipl.conf and booting a different kernel =) [10:41] xnox: Yeah, that would be handy. [10:41] good morning [10:41] or like figure out "this is unconfigured cloud-image, maybe i should add "cloud-init-first-boot-ever" param to the kernel cmdline..." [10:42] xnox: What would that be needed for? === _salem is now known as salem_ [10:43] Odd_Bloke, on first initramfs boot, determine available NIC and DASD drive and activate that, and store the results of such activation on disk. [10:44] Odd_Bloke, at the moment, instead of like activating all the things that are discovered... we do nothing, or like activate only the nic's / drives that users chose to configure at install time, or later by tweaking sysconfig-hardware. [10:44] Oh, OK; the "cloud-init" bit threw me off. ;) [10:45] "something-not-installed-with-d-i-but-debootstrapped-like-thing" [10:48] xnox, what does it happen if I run a syncpackage boost-defaults? [10:49] LocutusOfBorg1, permission denied =) cause it's in main ;-) [10:49] xnox, ok, the question actually is: can it be syncable? [10:50] I did a debdiff, but I'm confused [10:50] LocutusOfBorg1, do you understand the split between main and universe, and what are the requirements for main? [10:50] (usually boost-defaults are updated in ubuntu slightly ahead of debian) [10:51] xnox, sorry, not a native speaker :) [10:51] yes, I understand that I can't sync it, because of main, and not universe [10:51] not that. [10:51] and I also understand that boost transitioned before in ubuntu rather than in debian [10:51] LocutusOfBorg1, in general, in ubuntu, why do we have main/restricted/universe/multiverse and what are the differences between them? [10:52] Laney: sure, go ahead, thanks [10:52] yes, I know the differences, and I also know I can only touch universe :) [10:52] LocutusOfBorg1, looking at it, i think boost-defaults can in fact be synced, let me double check things. [10:52] cjwatson: ta [10:53] and hooray for working --arch [10:53] LocutusOfBorg1, yeah, it could be synced. [10:53] xnox, the question is more "general", I'm looking to possible things to sync, and I want to be sure that just a little debdiff and looking at changes is the correct thing to check [10:53] lets discard the "main" thing please :) [10:53] right. [10:53] I'll learn to check that as soon as I get many permission denied :) [10:54] LocutusOfBorg1, yes boost-defaults is syncable at the moment. And instead of syncpackage, you can do e.g. requestsync =) [10:54] xnox, I use requestsync since a lot of time actually :) [10:54] LocutusOfBorg1, and then somebody (a core-dev) can sponsor that for you. [10:54] BTW the question is also: https://packages.qa.debian.org/b/boost-defaults.html [10:54] I did a debdiff between unstable and xenial [10:54] and then I looked at the patch on BTS (right corner, at the bottom) [10:54] they look different [10:55] yes.... [10:55] oh the script didn't run after the last debian upload [10:55] the one online looks out of date. [10:55] fine then [10:55] yes, indeed [10:55] there is the last debian entry missing [10:55] maybe that should be reported somewhere.... [10:56] cjwatson, is patches.ubuntu.com healthy at the moment? or does it only generate a patch once, and that's it? [10:56] so the lesson learned today is: do not look at patches.ubuntu.com, but do the job yourself :) [10:56] thanks a lot [10:56] LocutusOfBorg1, i think the patch might be odd, because ubuntu boost-defaults is a "fork" rather than on top of a debian revision. [10:57] because we did a 0ubuntu1, before ...1 version was available in debian. [10:57] yes, probably mergechangelogs doesn't work with that [10:58] xnox: it's failing - I'll fix it up this morning [10:59] xnox: (I knew about it already by mail notification but haven't had a chance to poke it yet) [10:59] BTW boost in ubuntu should be finally fixed <-- doko [10:59] it migrated [11:07] ta [11:37] doko, will you retry the build failed because of boost? [11:40] LocutusOfBorg1, done for the one I know of [11:40] thaks [11:40] thanks [11:47] xnox: patches.u.c should sort itself out in a bit [11:47] thanks a lot =) [11:56] oh well, I can act as sponsor, but I can't unsubscribe sponsors-team from the bug reports :) [11:56] you could join the team if you ask an admin [11:57] lets do little steps :) [11:57] but I will eventually [12:03] xnox: any objection to me demoting insighttoolkit4 and its three revdeps (elastix, itksnap, plastimatch) to -proposed temporarily to detach them from the perl transition? [12:04] I'm pretty bored of waiting [12:13] cjwatson, I have no objection in *removing* them :) [12:14] that transition is sooooo bad [12:14] * LocutusOfBorg1 speaking on the debian side [12:14] well, that's a different argument :) [12:15] * LocutusOfBorg1 was just jocking [12:24] xnox: I'm stealing your ldb merge [12:24] seb128: I'm stealing your samba merge [12:25] you feef [12:25] heh [12:29] stealing work is always nice :) [12:30] funny how people never steal my work :P [12:30] pitti: I meant to ask you about what's going on with e.g. http://autopkgtest.ubuntu.com/packages/o/openafs/xenial/s390x/ - there are a couple of packages that fail like that, and it's notable that they work fine when the trigger is linux-meta. no kernel in the autopkgtest chroot maybe? [12:31] xnox: https://launchpad.net/~daniel-thewatkins/+livefs/ubuntu/xenial/cpc/+build/48062 \o/ [12:31] xnox: So those don't contain any zipl stuff etc.; they're effectively just what we produce for the other arches. [12:33] Odd_Bloke, excellent. [12:33] Odd_Bloke, i guess i could grab disk1 and mangle it, until it becomes bootable? [12:33] Odd_Bloke, and then report back to you? =) [12:34] xnox: Yeah, having a clear set of changes to make would be good. [12:34] xnox: Because the build process is 'upload to PPA, build, wait for publish, kick off livefs build, wait', which isn't the most nimble way to iterate. :p [12:42] xnox: did you see my insighttoolkit4 question above? [12:42] xnox: So am I OK to leave the cloud images until I hear back from you? [12:42] cjwatson, i have not. [12:42] 12:03 xnox: any objection to me demoting insighttoolkit4 and its three revdeps (elastix, itksnap, plastimatch) to -proposed temporarily to detach them from the perl transition? [12:42] 12:04 I'm pretty bored of waiting [12:42] cjwatson, i want to demote insighttoolkit4 with fire =) [12:43] xnox: right :-) I'll take care of that then, thanks [12:43] it pretty much made mono transition non-trivial 2 month affair, instead of it being trivial. [12:44] xnox: (I'll wait until this afternoon though - I'm going out in an hour or so, and if there's a decent chance that perl will land I want to be around to disable the publisher to make sure that it all lands in one go) [12:48] mind you, at this rate autopkgtests will take an hour or two to catch up anyway. sod it [12:51] done [12:58] cjwatson: right -- linux-meta* triggers actually do install that kernel, so that dkms modules have something to build against; but the default lxc containers don't have a kernel [12:59] cjwatson: I think the fix for that would either be to install the default kernel headers (but this would still fail if dkms modules don't work against that, which does happen), or perhaps better, ignore linux-meta* triggers when determining "ever passed" [13:02] cjwatson: I filed that as bug 1531488 [13:02] bug 1531488 in Auto Package Testing "ignore linux-meta triggers for "ever passed"" [Medium,In progress] https://launchpad.net/bugs/1531488 [13:02] thanks [13:05] cjwatson: we are still waiting on insighttoolkit, I presume? [13:05] oh my, https://launchpad.net/ubuntu/+source/insighttoolkit4/4.8.1-1ubuntu4/+build/8449963 only started an hour ago [13:07] ah, nevermind, saw backscroll above [13:25] pitti: yep, hopefully once the current autopkgtest backlog clears a bit we should be good [13:25] (need libmath-bezier-perl/armhf) [13:37] cjwatson, your upload looks correct, thanks [13:38] (cc Mirv) [13:38] (though it's unrelated to Qt 5.6, the circular dependency coming in Qt 5.6 is unrelated thing) [13:39] s/unrelated thing/a different thing/ to not repeat myself :) [13:54] cjwatson, infinity the maas image build process makes a few changes to a cloud image build. that all is hoped to be moved to buildd and thus running native at some point. wrt "misconfigured chroot", i'm not sure what you mean. the chroot has functional networking (apt-get update works), and also in that particular one, sys and proc and even dev are mounted. additionally, the same set of things work happily doing native chroot (i [13:54] e amd64 -> amd64) without qemu-static. so yes, i think its qemu-static related, and i was confused by that also as it does not seem likely. [14:04] so, a package taking over the only binary of another package just reached the release pocket. do you confirm me that old source is going to disappear automagically from xenial? (and what about the open bugs against it?) [14:06] or is there a cruft report, similar to what debian has, and a human process it every so often? [14:06] python-udiskie, pencil ^^^ [14:07] e.g. with udiskie in -release I think https://launchpad.net/ubuntu/+source/python-udiskie should disappear [14:23] mapreri: it isn't automatic, but isn't a problem and will be dealt with by an archive admin before release usually. It should appear in this report: http://people.canonical.com/~ubuntu-archive/nbs.html [14:24] mapreri: the bugs will need to be handled separately. Please close or reassign with a suitable comment as appropriate. [14:30] mmm rbasak I don't see udiskie here [14:44] pitti: hi!, re apparmor> thanks! [14:48] infinity: Before the holidays you were going to see if the latest powerpc image I had produced was bootable. I don't know if you got anywhere with that then, but there's one for you to test here, if you have the time: https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/48068 [15:00] Hi! Are Ubuntu bugs in launchpad marked as per their difficulty? I'm new to Ubuntu. Where can I find some easy bugs to squish? [15:02] no, difficulty to fix things is subjective. [15:03] but there are some trivial low hanging fruit type bugs that are tagged in a certain way, iirc [15:03] Girish: some projects (not all) add a "bite-size" or similar tag to small, easy bugs [15:04] Girish: is there perhaps something like a spelling mistake you've noticed in your day-to-day use of Ubuntu? [15:04] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize [15:04] though some of those are obviously not "bite sized" [15:06] there's also the "verification-needed" tag, which is on things that have a proposed fix in the proposed pocket, and they need testing and verification that the fix is good or not [15:10] Cool. Thanks will check them out. [15:34] rbasak,mapreri: NBS only covers binaries, not obsolete sources, for which there is unfortunately no cruft report. Otherwise you're correct. [15:35] mapreri: That said, for packages that were removed from Debian and are unmodified in Ubuntu, we'll generally pick up the removal as a result of following along with removals from Debian unstable. [15:35] cjwatson: pencil was never in debian [15:36] cjwatson: and I just added a delta to pencil2d to build a transitional package and take it over (pencil2d being pencil's maintained fork) [15:37] right, file a bug and subscribe ubuntu-archive for the removal, then [15:37] cjwatson: cool, thanks [15:43] pitti: autopkgtest sad? http://autopkgtest.ubuntu.com/running.shtml says "[an error occurred while processing this directive] [15:43] " [15:44] cjwatson: currently at it [15:44] cjwatson: the page had some leftovers, I had to restart the collector; it will start showing stuff once the first request comes in again (queues are empty ATM) [15:44] I'll also re-run the tmpfails etc. [15:44] at least armhf has finally caught up \o/ [15:46] hmm, "no route to host", cloud troubles again? [15:52] pitti: ah good, thanks. check #is-outage, there've been various PS4.5 outages [15:52] it seems to work again right now, let's see for how long [15:54] pitti: excuses seems a little confused about the state of libmath-bezier-perl triggered from perl [15:54] test in progress, but it's not on running.shtml and http://autopkgtest.ubuntu.com/packages/libm/libmath-bezier-perl/xenial/armhf/ has a most recent run >four hours ago [15:54] running.shtml is back (with retrying regresisons with apt pinning) [15:54] cjwatson: yep, next britney run will re-trigger them [15:55] they fell victim to repeated tmpfails and giving up [15:55] ah :-/ [15:55] all workers repeatedly failed due to "no route to host" (amqp server), and some noise [15:56] cjwatson: FYI, in those cases I wait until britney is not running (or running --print-uninst), and remove proposed-migration/data/xenial-proposed/autopkgtest/pending.json (britney's cache which tests it already triggered in previous runs) [15:56] this re-requests all "in progress" [15:57] ok, I'd been steering clear of doing that since there's an admonition in the wiki page not to do that in general :) [15:57] ugly, and I'm slowly detecting them better, but there are still cases which we don't reliably detect as "tmpfail" [16:12] pitti: would it maybe make sense to just force-badtest libmath-bezier-perl/0.01-2 ? the most recent armhf test in fact also ran against perl 5.22, and it's going to take aaaages to get round to it [16:14] pitti: could you please also bump the version of your sbuild hint to 0.67.0-2ubuntu1 ? [16:15] I'm trying to figure out the right way to fix bug 798414 — namely, if you have a separate /boot partition and just do automatic updates, you'll eventually fill up /boot and have to resolve it manually. [16:15] bug 798414 in initramfs-tools (Ubuntu) "update-initramfs should produce a more helpful error when there isn't enough free space" [Medium,Triaged] https://launchpad.net/bugs/798414 [16:15] cjwatson: done [16:15] The cleanest solutions involve some more logic outside of dpkg that manages your kernel packages, ensuring that you have, idk, latest, current-running, and a few previous. [16:15] but I don't know if we do that anywhere else in the project, and there is very possibly a solution I'm just not thinking of. [16:15] pitti: the sbuild part? thanks [16:16] cccccceefhjhcgefnfufdjeuvjjbuvkkbdtuvllcufej [16:16] lfaraone: things are hooked up nowadays so that that's how apt-get autoremove will behave [16:16] lfaraone: although some people report that not working, I think possibly because they've used "partial upgrade" in u-m [16:16] cjwatson: hm. would it be safe to run autoremove automatically? [16:17] difficult [16:17] this e.g. caused tech support questions from my mother. :P [16:17] maybe it would be possible to write a python-apt program that did the kernel parts automatically? [16:17] cjwatson: done> yes, bumping the sbuild hint [16:18] cking: is bug 1527460 fixed in xenial? [16:18] bug 1527460 in fwts (Ubuntu) "fwts PCIe ASPM tests are throwing Segmentation fault" [High,In progress] https://launchpad.net/bugs/1527460 [16:18] cjwatson: sure. i'd be interested in working on that… would that be something that would run as a separate cron, or is there an existing project I should integrate it with? [16:18] cjwatson: ah, overlooked the libmath-bezier-perl/0.01-2 thing, sorry; added the hint [16:20] pitti: cool cool, thanks [16:20] lfaraone: I don't know, I'm afraid [16:20] there are some apt cron jobs, perhaps there [16:23] arges, it will be on the fwts 16.01.00 release [16:32] Hi, I have a question about Upstart .override files. I /etc/init/cups.conf "respawn" is set and I want to de-activate respawning in the /etc/init/cups.override file, for on-demand use of CUPS. How do I proceed? [16:37] cjwatson: darn, we actually need both sbuild hints [16:38] cjwatson: but at this point it might actually be easier to force-skiptest perl? [16:38] as this is quite a whack-a-mole game [16:39] pitti: sbuild/armhf is running at the moment, which should make that not a problem [16:39] cjwatson: added the skiptest [16:40] bbl [16:40] pitti: though I was considering suggesting the same thing, so yeah === juliank0 is now known as juliank [17:04] pitti,infinity,slangasek: please could you "force-skiptest libfilesys-df-perl/0.92-5build2" and "force-skiptest exim4/4.86-7ubuntu2" - same reason as perl, it's because the force-badtested sbuild failure is for an older version on armhf and we can't have both versions [17:05] sbuild/armhf has restarted several times, so I'm not hopeful of it working [17:08] cjwatson: I can give it a jab. [17:08] thanks [17:08] infinity: you are adding the hints? ok [17:09] Done. [17:09] great [17:10] Odd_Bloke: What am I trying to boot? disk1.img? [17:11] infinity: Yep, think so. [17:11] infinity: (I mean, you tell me :p) [17:14] cjwatson: sbuild/armhf repeatedly causes the container to fail rebooting, that's also what makes the workers so slow [17:15] will look at that tomorrow [17:15] orig: 307+0: a-66:a-34:a-33:i-33:p-36:p-34:s-71 [17:15] end: 300+0: a-65:a-34:a-33:i-33:p-36:p-34:s-65 [17:16] disabling publisher so that that will all land in one chunk [17:18] Odd_Bloke: I assume it'll fail to boot completely due to cloud-init weirdness or something, but we're just looking to see if bootloader->kernel->init work? [17:18] * infinity is downloading. [17:21] Odd_Bloke: And nope. Dumps me to a grub shell. [17:22] infinity: Hmph; could you pastebin the command you're running so I can test future iterations myself? [17:22] Odd_Bloke: http://paste.ubuntu.com/14422052/ [17:23] Odd_Bloke: Adjust cores and memory to taste and not overload whatever host you're using. :P [17:23] slangasek: so the Xubuntu devs tell me they're still waiting to hear back from you on https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 [17:54] in qemu, the init scripts were moved at version 1:2.3+dfsg-4ubuntu1 from qemu-system-x86 to qemu-system-common. The defaults file was accidentally not moved, so it simply didn't exist between 1:2.3+dfsg-4ubuntu1 and now. [17:54] at 1:2.3+dfsg-4ubuntu1, qemu-system-common B/R qemu-system-x86 [17:54] so now if i put the defaults file into qemu-system-common, do i need to again B/R qemu-system-x86? [17:55] i.e. if someone has preexisting defaults file and upgrades, is the default file rightnow just orphaned, or is it seenas belonging to qemu-system-x86 in the latest version? [17:56] dpkg -S says it belongs to qemu-system-x86, so i guess that's my answer [18:06] mhall119, slangasek: the requested changes have not been made still. https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167/comments/714269 commented to remind about that, and explain in more details. [18:08] infinity, >_< 30 GB of RAM =) fun. === henrix_ is now known as henrix [18:29] though a test run with handbuild pkg suggests it's fine [18:33] xnox: Uh, that's not really what we're aiming for here, though. It's not really a "normal desktop" and "Super featurefull desktop" which is what you're/that's implying, it's "Normal desktop" and "OK lets strip everything out except the DE itself", which then implies the user actually knows how to add whatever backends he needs. [18:33] Unit193, ...... this is exactly what desktop vs dvd used to be =) [18:34] No it's not. [18:34] So, 'desktop' was actually missing a load of stuff? [18:34] Unit193, one bigger than the other. adding a new product, is extra un-necessory complexity, when dvd/desktop already exist. [18:34] desktop was always a complete desktop, dvd just had "more stuff". [18:34] No browser, office suite, some gvfs backends missing, etc? [18:34] stgraber: ^ do yo uknow offhand? mainly i can't figure why dpkg -S is telling me the file still belongs to qemu-system-x86 [18:34] (with my tst pkgs that didn't happen) [18:35] hallyn: Regarding your upgrade question, keep in mind that we support upgrades from trusty. :P [18:36] infinity: right but -common already B/R a recent versin of -x86, though that is handled [18:36] infinity, Unit193: i agree with slangasek on the merge proposal: mv desktop dvd; touch desktop. Rather than create a "core" variant for _everything_ =) [18:36] hallyn: And orphaned conffiles will still belong to the package that orphaned them unless you use rm_conffile. [18:36] s/though/so/ [18:36] * xnox hates core, it's overloaded term by now three times over [18:36] hallyn: Or if their Replaced by shipping it in another package. [18:36] ok, so when they're replaced by shipping in another package dpkg won't complain? [18:36] s/their/they're/ ... Wow, thanks internet. [18:37] xnox: Can't we rename dvd to core then? :P And, at least we did this right before trusty hit, and based it off of something even older than that so it's not just following the trend! :P [18:37] hallyn: sounds like the orphaned without rm_conffile case [18:37] hallyn: It will complain if there are changes to the file. [18:37] so better to update the B/R version numbers? [18:37] Unit193, there is core already in other parts of the things, that means a tarball without a kernel. i'm not sure which parts of things build it though. [18:37] hallyn: Updating B/R versions is correct in your current context. [18:38] ok thx [18:38] hallyn: There's a lot more pain involved in "properly" moving conffiles between packages, but that depends on level of carefactor and odds that people have edited it. [18:38] (odd that my hand-built test packages behaved differently, but i probably just messed them up) [18:38] Unit193, you really do not want a tarball without a kernel =) which at one point was based of lubuntu on armhf or some such. [18:39] xnox: Hah, not really. But dvd/desktop is certainly not what we're aiming for either, it's the opposite. [18:40] Unit193, image if current xubuntu download button on your website from xenial on points to -dvd-.iso. That's the new "Xubuntu" [18:40] xnox: core was never lubuntu. [18:40] Unit193, image that minimal xubuntu, with just de and not much else (aka code name core) is the download called -desktop-.iso. (aka desktop-only) [18:40] !info lubuntu-core [18:40] lubuntu-core (source: lubuntu-meta): Lubuntu Desktop environment - minimal installation. In component universe, is optional. Version 0.62 (wily), package size 3 kB, installed size 14 kB (Only available for i386; amd64; powerpc; armhf) [18:40] Unit193, do you under stand what i'm trying to do? [18:41] xnox: I understand, I don't like. [18:42] Unit193, for both *buntu-minimal would have been a better name.... [18:43] xnox: I don't exactly disagree, but at least that hit before all the Ubuntu Core stuff hit the fan so it's not trying to use the advertisement. [18:44] I still like xubuntu-lite, if you're bikeshedding names, but really, it's a whole lot of who cares. [18:44] We've been around and around with this for months. [18:45] xnox: The problem with the desktop/dvd proposal is that it implies that Xubuntu-desktop is actually a full desktop. At least, if you're being consistent with Ubuntu history. It doesn't fix confusion, just shifts it. [18:46] xnox: ubuntu-desktop versus dvd was never about one being minimal/crippled and one being complete, it was about one fitting on a CD and one having extra stuff. [18:46] Unit193, btw do you really want to images? [18:47] as far as I remember e.g. edubuntu has a ubiquity plugin and offers a choice of DE's. [18:47] infinity: Or xubuntu-bare. :D Oh the implications! [18:47] * Unit193 ducks. [18:47] all i want is 🍺 [18:47] wouldn't you want a single xubuntu-desktop.iso and a page/tick-box "install just minimal DE bare lite core fizz buzz" [18:48] dobey, .... AND A LOLLIPOP! [18:48] xnox: i guess those two things don't go well together. that's why they come in separate packages [18:50] xnox: Actually, Ubuntu Studio has been working on that. But no, not as far as I've ever heard. [18:50] infinity: Thanks very much, btw! [19:18] xnox: did you ever report LP: #1526613 upstream to cpython or cython? [19:18] Launchpad bug 1526613 in python3.5 (Ubuntu) "ftbfs asyncio test failure with 3.5.1-2, used to pass with 3.5.0-2" [Undecided,New] https://launchpad.net/bugs/1526613 [21:41] cjwatson: wheeee! ^5s [21:41] * Laney got email about some ancient uploads migrating :) [21:43] excuses is still big, but nowhere near as bad as it was at the beginning of the week [21:44] perl and php were a good chunk of it [21:44] task for tomorrow: go-faster stripes for armhf === salem_ is now known as _salem === jgrimm is now known as jgrimm-afk === jgrimm-afk is now known as jgrimm [23:39] why does software center use a light green text on a white background anyway? === TheMuso` is now known as TheMuso