[05:17] <cpaelzer> good morning
[06:03] <alexlist> doko_: good morning :)
[06:03] <alexlist> doko_: we're running into an issue that we found fixed in Debian, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808205 but it seems it hasn't made it into an SRU for Wily yet...
[07:34] <pitti> Good morning
[07:37] <pitti> doko_: the rationale is https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/038985.html
[07:38] <pitti> doko_: i. e. we want to test packages in isolation as otherwise too much stuff got blocked because of unrelated breakage in other packages
[07:38] <pitti> doko_: if a package from -proposed can't work with a dependency from -release, that normally indicates a missing dependency, or the versioning is not strict enough
[07:39] <pitti> doko_: so for those cases we need to either fix the dependencies or do a manual run-autopkgtest with *both* packages as the trigger
[08:21] <Wagaaa> Hello?
[08:23] <Wagaaa> Hello?
[08:23] <dholbach> good morning
[08:23] <seb128> hey dholbach
[08:24] <dholbach> hi seb128
[08:27] <Wagaaa> I have a question
[08:28] <Wagaaa> I'm a developer of a Linux team
[08:29] <Wagaaa> I would to create a Debian-based System
[08:31] <Wagaaa> But we don't know how to change OS Name
[08:32] <mgedmin> Wagaaa, perhaps https://wiki.debian.org/Derivatives/Guidelines#De-.2FRe-branding will be helpful
[09:17] <rbasak> Caribou: FYI, I just started reviewing your new clamav merge.
[09:18] <Caribou> rbasak: perfect, let me know if I can help
[09:19] <rbasak> Caribou: did you push your latest to LP?
[09:19] <rbasak> I only see stuff based on 0.98.7+dfsg-1 still
[09:20] <Caribou> rbasak: yes, there is a merge-v2 branch & the old tags points to the new branch
[09:20] <rbasak> Caribou: https://git.launchpad.net/~louis-bouchard/ubuntu/+source/clamav/refs/ - I see no merge-v2 branch.
[09:20] <rbasak> Am I looking in the wrong place?
[09:21] <Caribou> rbasak: let me check
[09:21] <rbasak> Ah, I found https://git.launchpad.net/~louis-bouchard/test/refs/?h=merge
[09:21] <rbasak> I guess that's not intentional but I can use that if it's up to date?
[09:23] <Caribou> rbasak: friday's mistake, I pushed it to a test repo & then forgot to update the main one
[09:24] <Caribou> it's there : https://git.launchpad.net/~louis-bouchard/test
[09:24] <Wagaaa> Hello！
[09:24] <Caribou> rbasak: let me push it to the original one
[09:25] <Caribou> rbasak: I just uploaded it in the right place & forced updated the tags
[09:26] <Wagaaa> How ti change Debian-installer's head picture?
[09:28] <rbasak> Caribou: OK, thanks!
[10:05] <alexlist> doko_: https://bugs.launchpad.net/binutils/+bug/1545653
[10:24] <pitti> doko_: I did a mass retry of all regressions against all of -proposed, that should mop up those
[10:24] <pitti> l
[10:24] <doko_> alexlist, can't be the issue. 15.10 has binutils 2.25.1
[10:25] <doko_> pitti, well, then we need to upload every transition with tightened build-depends, introducing thousands more ubuntu deltas. not feasable
[10:26] <pitti> doko_: not b-deps, binary deps; anyway, of course we don't want that big ubuntu delta, so I guess we'll need to re-try those manually
[10:27] <pitti> we can't have it both ways, isolated and ignoring sloppy dependencies
[10:29] <doko_> well, but having to chase this manually isn't a good way either
[10:49] <pete-woods> pitti: hey, I've got some stuck autopkgtests for one of my landings, that have been running quite some time (https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-070/excuses.html)
[10:49] <pete-woods> ppc64el on indicator-network seems to be the kicker
[10:54] <pitti> pete-woods: right, network-mananger is blacklisted on vivid/ppc64el as it keeps killing the instances; I'll add a corresponding hint for it to britney (same as for systemd)
[10:54] <pitti> err, not "same as", just add it
[10:55] <pitti> pete-woods: done, next run should pick this up and move to "valid candidate"
[10:55] <pete-woods> pitti: awesome, thanks
[10:55] <cjwatson> jamespage: could you revert the bogus changes to https://bugs.launchpad.net/charms/+source/glance/+bug/1496011 ?  I'm warning the user
[10:55] <pete-woods> I assume when you say "next run", this thing is another cronbeast that ticks every so often
[10:56] <pete-woods> picking up whatever has changed
[10:56] <pete-woods> as opposed to requiring some input from me?
[11:00] <jamespage> cjwatson, done
[11:00] <cjwatson> ta
[11:05] <Mirv> pete-woods: yes, he means that, it updates more or less hourly
[11:05] <Mirv> pete-woods: probably within 20 minutes or so. and then the train might take another 0-15 mins to notice it.
[11:08] <pete-woods> Mirv: sounds good :)
[11:09] <seb128> dgadomski, pitti, bug #1545302 claims to be a regression from the ifconfig per interface change
[11:20] <pitti> seb128: thanks for pointing out
[11:20] <seb128> pitti, yw!
[11:20] <pitti> dgadomski: could you please have a look at that patch, see if it makes sense, and forward it to Debian too?
[11:27] <pitti> doko_: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openmpi is valid candidate now, FYI (but still some uninstallability on upate_output)
[11:31] <doko_> pitti, numpy not considered. please override the remaining tests
[11:31] <pitti> i. e. we'll leave pyresample broken
[11:32] <pitti> doko_: hinted
[11:32] <doko_> I updated to the last upstream, but don't want to investigate
[11:35] <doko_> pitti, for python-scipy as well?
[11:38] <pitti> done
[12:05] <doko_> seb128, did you e-d-s upload trigger a transition?
[12:13] <Wagaaa> Hello
[12:14] <Wagaaa> I have a question about make a Debian-based system
[12:16] <davmor2> Wagaaa: whats the question
[12:16] <Wagaaa> How to change Debian-installer's head picture
[12:18] <Wagaaa> I could find live
[12:18] <Wagaaa> sorry
[12:18] <Wagaaa> live installer. undeb file
[12:18] <davmor2> Wagaaa: this won't be the right channel then, if you ask on #ubuntu a dev there might be able to help,  but at a guess you change the image file
[12:19] <ogra_> probably #ubuntu-installer ?
[12:19] <Wagaaa> no
[12:20] <Wagaaa> but the debian channel asked me to find another channel
[12:20] <ogra_> (i mean you shoudl probably ask in that channel)
[12:21] <Wagaaa> oh
[12:21] <Wagaaa> I see
[12:30] <dgadomski> seb128, pitti: thanks, I'm on it
[12:36] <doko_> pitti, please override the palabos autopkg tests. don't care about s390x, and fails on all other archs
[12:48] <kickinz1> rbasak, so I filled the MIR bug: https://bugs.launchpad.net/ubuntu/+source/pps-tools/+bug/1545699
[13:16] <pitti> doko_: done (some minutes ago)
[13:16] <rbasak> kickinz1: thanks!
[13:42] <Mirv> pitti: I had a vague idea something like 3 hours runime would autoabort autopkgtest but this one has been running for over 5 hours? http://autopkgtest.ubuntu.com/running.shtml#pkg-dolphin
[13:42] <Mirv> an always-failed test
[13:42] <pitti> Mirv: it probably was auto-retried several times due to some cloud failures
[13:43] <Mirv> pitti: yeah but it claims this particular run has been there for >5h
[13:43] <pitti> right, it counts the time from the first try
[13:43] <Mirv> oh...
[13:43] <Mirv> ok then, nothing to see here
[13:43] <pitti> if it runs significantly longer, I'll dig into the logs, but for now this can be ignored
[13:49] <kickinz1> rbasak, doko, is dovecot merge urgent before FF? Or should I take another more urgent merge before?
[14:31] <Mirv> pitti: what about these VirtSubProc.Timeout:s on armhf that still just stay there - http://autopkgtest.ubuntu.com/running.shtml#pkg-libkscreen and http://autopkgtest.ubuntu.com/running.shtml#pkg-libqapt ?
[14:32] <Mirv> maybe they'll eventually abort too
[14:34] <doko> kickinz1, that would be the new upstream version 2.2.21, so not a merge. is squid3 now merged?
[14:38] <kickinz1> doko, for squid3, I don't know; seems rbasak is working on it.
[14:38] <pitti> Mirv: no, I need to clean those up, thanks; I thought I already worked around those, but apparently I missed a few sopts
[14:38] <pitti> spots
[14:40] <rbasak> doko, kickinz1: I'm switching back to the squid3 merge next. It's non-trivial. I expect to be done by FF still.
[14:40] <kickinz1> rbasak, thanks for the update.
[14:42] <pitti> Mirv: hm, they locked up too hard, I can't clean them up without interrupting the other tests; is that blocking you somehow?
[14:42] <pitti> oh, for Qt
[14:43]  * pitti reboots the worker, the other tests will then have to restart
[14:58] <Mirv> pitti: ok, good that all my pings are not useless :)
[14:59] <Mirv> pitti: those two are blocking qtbase from migrating from xenial-proposed, but it's not in a hurry
[14:59] <pitti> Mirv: I retried them; the timed out ones are orphaned at running.html due to the way I killed them, so you can ignore them now
[15:09] <Mirv> ok
[15:30] <pitti> Mirv: Qt landed
[15:38] <pitti> jdstrand: can I ask you to do the apparmor merge in my stead? you know the package much better than I do
[15:39] <Mirv> pitti: ack, I noticed
[16:13] <Caribou> rbasak: I've just replied to your merge review & would have a few things to discuss when you get a chance
[16:20] <rbasak> Caribou: I replied. Looks good! Thanks.
[16:20] <kickinz1> rbasak, Can you create a new/debian branch into amavisd-new on ubuntu-server-dev, so I can rebase my logical delta on this one?
[16:21] <rbasak> kickinz1: ack
[16:21] <kickinz1> rbasak, thanks
[16:22] <doko> pitti, you can remove the unblocks for kblog and ktnef
[16:23] <pitti> doko: oh? their latest runs still failed
[16:23] <Caribou> rbasak: FYI, I re-introduced the cast on (unsigned long) & refreshed the patch. I'm sending an email to the pkg-devel mailing list for further details.
[16:24] <Caribou> rbasak: I'll drop the armhf exception as well & do a test rebuild. It it goes through fine, I'll upload w/o the test
[16:24] <Caribou> rbasak: & also fix the changelog for more precision
[16:29] <rbasak> kickinz1: done, along with the standard tags and branches.
[16:31] <rbasak> Actually import/1_2.10.1-1ubuntu1 is wrong. It should be upload/1_2.10.1-1ubuntu1
[16:31]  * rbasak fixes
[16:32] <kickinz1> Thanks!
[16:32] <kickinz1> rbasak, ^
[16:32] <rbasak> np
[16:42] <cpaelzer> hi, I have a package that will drop two conffiles - removing was fine and works like a charm via package.maintscript
[16:42] <cpaelzer> we discussed and wanted to check in postinst if a .dpkg-bak was created indicating user config might be lost and wanted to e.g. show a debconf info or so
[16:43] <cpaelzer> eventually the user should be made aware like "sorry, but due to ... you have to convert your old config in X into the new format"
[16:43] <cpaelzer> is there any packet did something like that in the past that I could refer to when writing that?
[16:45] <doko> pitti, uploaded kcalcore
[16:52] <rbasak> cpaelzer: perhaps the "flags" warning in src:mysql-5.6? It's far from a shining example of best practice packaging, but it does demonstrate the mechanics of it I think.
[16:53] <doko> finally, the whole openmpi/-science mess migrated
[16:53] <ginggs> \o/
[16:57] <cpaelzer> rbasak: thanks I'll look into that
[17:06] <doko> pitti, Laney, seb128, willcooke: aspell-he needs a MIR, or argue four weeks who will do it ... translators or desktop
[17:07] <Laney> why would a dictionary need MIR?
[17:08] <doko> ok, you just started day 1 out of 30 arguing ...
[17:10] <Laney> doko: I would just subscribe the desktop team and promote it, or do you really care for some data files?
[17:12] <doko> Laney, sure, open a MIR, and just write what you said. is this that difficult?
[17:13] <doko> I used to maintain all the dicionaries as part of OOo packaging. and these should be looked at by LO packaging now
[17:13] <Laney> Just promote it and I'll subscribe the team
[17:13] <Laney> I'm busy doing other things so if you want paperwork you will have to wait a bit
[17:14] <cjwatson> Wow, way to start a discussion with open hostility
[17:15] <doko> cjwatson, what? I'm pointing out issues for migration, and every time I'm said I should "trade" in some of the stuff, doing it myself?
[17:16] <cjwatson> If I got a message like the above then it would go straight to the bottom of my list
[17:17] <doko> this started on -desktop
[17:20] <Laney> doko: the team is subscribed now
[17:30] <doko> Laney, https://bugs.launchpad.net/ubuntu/+source/aspell-he/+bug/1545803 , did stop doing other things, wrote the minimal MIR and promoted it
[17:32] <Laney> cool, thanks!
[17:33] <flexiondotorg> Laney, the Debian pkg-mate team have taken over maintainership of libwnck
[17:33] <flexiondotorg> The changes I dicsused with you a few weeks back are now all complete and in Debian unstable.
[17:34] <flexiondotorg> https://packages.debian.org/source/sid/libwnck
[17:34] <flexiondotorg> Laney, is this just a matter of 'requestsync' for Ubuntu?
[17:35] <Laney> flexiondotorg: That's the way to request a sync, if we don't need any delta
[17:35] <Laney> check the diff against our package to be sure
[17:35] <flexiondotorg> Laney, Thanks.
[17:36] <flexiondotorg> I think Ubuntu and Debian had diverged sometime ago.
[17:42] <mapreri> doko: wow, thanks for making the whole openmpi migrate!
[17:42] <tkamppeter> Any Debian packaging expert here? I need to give a binary package another version number than its source package has.
[17:43] <mapreri> now I just need to make the debian release team firing the needed rebuilds in s390x for mpich → openmpi...
[17:43] <cjwatson> dh_gencontrol -- -vBLAH
[17:43] <cjwatson> but be careful :)
[17:45] <tkamppeter> cjwatson, thanks, and how do I direct this only to selected binary packages?
[17:46] <cjwatson> dh_gencontrol -pPKG -- ...
[17:47] <tkamppeter> cjwatson, what do I write into the override_dh_gencontrol: rule in the debian/rules file if xxx should get the source's version number and the yyy package the alternative version number?
[17:48] <cjwatson> tkamppeter: so this should always be in terms of a transformation rule, not a fixed alternative version number, otherwise rebuilds are unnecessarily painful
[17:49] <cjwatson> tkamppeter: you probably want something like $(shell dpkg-parsechangelog -SVersion | sed ...) to compute the alternative version number
[17:49] <cjwatson> and substitute that into the dh_gencontrol call
[17:50] <tkamppeter> cjwatson, what I want to do is the following:
[17:50] <tkamppeter> cjwatson, the cups-filters package is currently version 1.8.2-1 and all its binary packages which it already had before should have the same version number.
[17:52] <tkamppeter> cjwatson, I am adding two new binary packages to cups-filters, names cups-filters-lsb and cups-filters-invalid-mta which should make LSB-based printer driver packages keep installable on Ubuntu as Debian has dropped the packages lsb and lsb-invalid-mta.
[17:52] <flexiondotorg> Laney, comparing the packages there are several keys differences.
[17:53] <flexiondotorg> Laney, Ubuntu has two patches that are not in the Debian packages.
[17:53] <tkamppeter> cjwatson, the package cups-filters-lsb should provide lsb and replace the former lsb package, the cups-filters-invalid-mta should replace the lsb-invalid-mta package (providing it).
[17:53] <flexiondotorg> And the Debian package has has quite a restructure during the update.
[17:53] <flexiondotorg> How to proceed?
[17:53] <juliank> tkamppeter: I don't see why you would want different version numbers yet
[17:53] <cjwatson> tkamppeter: this is sounding like you want versioned provides, not different version numbers
[17:54] <tkamppeter> cjwatson, problem is that the lsb source package is already at version 4.1.... and cups-filters is version 1.8.2.
[17:54] <cjwatson> the actual version of the cups-filters-lsb package etc. doesn't matter here
[17:54] <juliank> Unversioned provides do not match any version comparison
[17:54] <juliank> So you need provides: lsb (= 4.1)
[17:54] <juliank> basically
[17:54] <cjwatson> yeah
[17:55] <Laney> flexiondotorg: Merge if the patches are still needed
[17:55] <doko> mapreri, I had some sourceful uploads for these openmpi changes. If you could forward these changes to debian, I would appreciate it. the openmpi transition tracker should have these
[17:55] <Laney> flexiondotorg: Or get them applied in Debian. :)
[17:55] <tkamppeter> cjwatson, I simply want to replace the dropped lsb and lsb-invalid-mta packages.
[17:55] <cjwatson> tkamppeter: version number's still irrelevant
[17:55] <cjwatson> tkamppeter: if you were actually emitting binary packages called "lsb" and "lsb-invalid-mta", then it would matter
[17:55] <flexiondotorg> Laney, OK, I can investigate getting them merged in Debian.
[17:55] <flexiondotorg> But, clearly the packages have diverged anyway.
[17:56] <flexiondotorg> How exactly does the merging work in this case?
[17:56] <juliank> tkamppeter: If you don't actually need to satisfy versioned depends, unversioned provides would be OK as well. Then do provides/replaces and possibly breaks
[17:56] <cjwatson> tkamppeter: but you're saying that's not what you plan to do, you plan to use Provides, so your binary versions don't matter and you can just leave them at the default.  (Are you sure you need Replaces?)
[17:56] <juliank> breaks being the part to remove old lsb packages
[17:56] <tkamppeter> cjwatson, LSB-based printer drier packages depend on "lsb" and I am no sure whther there are some which have a versioned dependency like "lsb (>=3.1)".
[17:56] <Laney> flexiondotorg: A merge is just "take the Debian package and apply this diff on top of it"
[17:56] <Laney> flexiondotorg: your task is to work out how to preserve the changes on top of the new package structure
[17:56] <cjwatson> tkamppeter: right, but even so, overriding the version number of cups-filters-lsb will complicate your life and achieve nothing, so don't :-)
[17:56] <flexiondotorg> Laney, but that would destroy the ubuntu changelog?
[17:57] <doko> barry, jtaylor, tumbleweed: python3.4 noew removed
[17:57] <Laney> flexiondotorg: merge-changelog(1) :)
[17:57] <Laney> (ubuntu-dev-tools)
[17:57] <flexiondotorg> Laney, thanks.
[17:57] <barry> doko: gone, gone? :)  even minimal?  \o/
[17:57] <tumbleweed> doko: \o/
[17:57] <juliank> tkamppeter: You are probably looking for Provides: lsb (= 4.X+reallycups), Replaces: lsb, Breaks: lsb (<< 4.X+reallycups)
[17:57] <cjwatson> tkamppeter: unless you plan to call your binary packages literally "lsb" and "lsb-invalid-mta" (which you probably don't need to given that versioned provides exist), then you likely just need versioned provides as juliank says
[17:57] <flexiondotorg> Laney, I'll try and get started here but I may need some guidance.
[17:57] <juliank> Replaces & Breaks if you want to replace the old packages
[17:57] <juliank> and have them removed
[17:58] <Laney> flexiondotorg: If this is just a matter of keeping some patches then it is easy - merge-changelog, quilt import, write new changelog, done
[17:58] <flexiondotorg> Laney, maybe easy for someone who has done this before :-)
[17:59] <Laney> Working out the logical delta is the hard part :)
[17:59] <tkamppeter> cjwatson, so with a versioned provides I can stisfy the "Depends: lsb (>= 4.0)" in the driver package?
[17:59] <flexiondotorg> Logical delta?
[17:59] <juliank> tkamppeter: That's the entire point of versioned provides.
[17:59] <Laney> Previous changes and what needs to be kept
[17:59] <flexiondotorg> Well, the source is unchanged.
[17:59] <cjwatson> tkamppeter: yeah, you can have Package: cups-filters-lsb Version: 1.8.2-2 Provides: lsb (= 4.whatever)
[17:59] <flexiondotorg> It is the packaging that has changed/diverged.
[18:00] <juliank> tkamppeter: Without versioned provides, you could not satisfy any versioned dependency on lsb unless your package was literally called "lsb".
[18:00] <flexiondotorg> And the patches are easily retained.
[18:00] <Laney> Yeah
[18:00] <Laney> So you need to work out if the packaging did anything before that it doesn't do now that we need to keep
[18:00] <Laney> or the converse. :)
[18:00] <tkamppeter> juliank, what does the "+reallycups" in your example mean?
[18:00] <Laney> I would guess probably not
[18:01] <juliank> tkamppeter: Just to differentiate your version from the last lsb package version, if you like to :)
[18:01] <flexiondotorg> Laney, The Debian packaging can just be used.
[18:01] <Laney> Luckily I am patch piloting tomrorrow so can look at your diff
[18:01] <juliank> Could be useful for breaks
[18:01] <flexiondotorg> Retain 2 ubuntu pactches and merge-changelog.
[18:01] <flexiondotorg> Laney, no time pressure then ;-)
[18:01] <Laney> That's likely
[18:01] <Laney> Better if you could drop even that and sync. :P
[18:01] <Laney> but I have NFI about those patches
[18:02] <flexiondotorg> NFI/
[18:02] <doko> barry, can you upload a python-pip with the added breaks/replaces?
[18:03] <mapreri> doko: for sure I do try to integrate everything when uploading team maintained stuff and syncing later.  I'm going to try having a better look at all packages the following days.
[18:03] <Laney> no fine idea
[18:03]  * flexiondotorg nods
[18:03] <mapreri> I'm also happy to NMU, so ^^
[18:03] <doko> barry: (<< 22.1)
[18:03] <doko> barry: oops, (<< 20.1)
[18:03] <tkamppeter> cjwatson, juliank, thanks for the help. I will try it.
[18:04] <barry> doko: sure, i can update it.  thanks
[18:04] <barry> doko: are you going to upload a new setuptools soon?  if so, thanks, and please ignore my bug follow up
[18:05] <doko> barry, yes, not building the -whl anymore
[18:05] <doko> but you need the breaks/replaces
[18:06] <barry> doko: yep, will upload momentarily.  will you close #814571 or do you want me to with python-pip?
[18:10] <doko> barry, please do it with python-pip when you add the Breaks/Replaces
[18:10] <barry> doko: ack
[18:13] <flexiondotorg> Laney, with changelog version, should I just rev the -0ubuntux suffix and target xenial?
[18:14] <Laney> flexiondotorg: it's <debianversion>ubuntu1
[18:14] <flexiondotorg> Laney, The ubuntu package currently has epoch but debian doesn't.
[18:15] <flexiondotorg> Retain epoch in Ubuntu?
[18:15] <Laney> Yep
[18:15] <flexiondotorg> OK
[18:15] <Laney> Make sure any versions in debian/control (etc) hav eit
[18:17] <flexiondotorg> The debian version is; 2.30.7-5 and the last ubuntu version is 1:2.30.7-0ubuntu5
[18:17] <flexiondotorg> Laney, so should the new ubuntu version should be 1:2.30.7-5ubuntu1?
[18:17] <Laney> Seems OK
[18:17] <flexiondotorg> Thanks.
[18:18] <Laney> Got to go now
[18:18] <Laney> byeeee
[18:29] <sil2100> Yaay, the libjsoncpp transition got unblocked \o/
[18:32] <barry> doko: python-pip 8.0.2-7 uploaded
[18:32] <doko> barry, setuptools was accepted
[18:36] <doko> barry, what is the plan with libpies? just drop the python2.7 loader?
[18:40] <barry> doko: i have a patch in debian bts that splits the py2 and py3 loaders into separate binary packages.  the idea was to then adjust dependents to Depend on the correct one.  there are still a few py2 packages iirc.  but there's been zero activity on the debian bug so i think we should just move ahead in ubuntu
[18:41] <doko> barry, how many rdeps are there?
[18:41] <barry> doko: i forget.  let me find the bug comment
[18:42] <barry> doko: https://bugs.launchpad.net/ubuntu/+source/libpeas/+bug/1440504/comments/6
[18:44] <doko> barry, lets go ahead, so we can finish this before the feature freeze
[18:44] <barry> doko: +1  it's on my plate for this week
[19:27] <flexiondotorg> Can someone here give me a hand with updating an existing patch in a package.
[19:27] <flexiondotorg> I can't figure how to use quilt to achieve this.
[19:28] <flexiondotorg> First time I've had to do this so would appreciate the help :-)
[19:30] <doko> tjaalton, llvm now defaults to 3.8 in xenial
[19:30] <tjaalton> doko: yes, and mesa switched to it last week :)
[19:31] <doko> now lets see how many version can be demoted ...
[20:10] <mapreri> can you retry this?  with the mpi-defaults change it works https://launchpad.net/ubuntu/+source/ruby-mpi/0.3.0-1build4/+build/8923547
[20:11] <ginggs> retrying
[20:12] <mapreri> ta
[20:57] <doko> cjwatson, your recent python-cryptography sync ftbfs. looks like a missing b-d. the devscripts ftbfs as well. can you have look at these, or should I?
[20:59] <doko> cyphermox, mterry: feedback on lp: #1545854 appreciated
[21:05] <cyphermox> doko: that's something I wish was in collab-maint or something ;)
[21:39] <robert_ancell_> beuno, https://bugs.launchpad.net/rnr-server/+bug/1540635
[21:48] <Saviq> pitti, if you're still here, any idea about the "In progress" run here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-api ? it looks stuck - the i386 run completed 2h ago and there's nothing in http://autopkgtest.ubuntu.com/running.shtml
[21:53] <Saviq> slangasek, maybe you could have a look please ↑?
[22:13] <Saviq> infinity, maybe you have an idea ↑ about the stuck autopkgtest?
[22:23] <robert_ancell> Chipaca, https://bugzilla.gnome.org/show_bug.cgi?id=727563
[22:53] <Saviq> robert_ancell, hey, I saw you guys reverted nautilus a few days ago, do you know why the icon layout would get screwed a bit? my icons are some 25% smaller by default (Ctrl+0) now, and if I Ctrl+=, the spacing between the bigger ones is just huge
[22:53] <robert_ancell> Saviq, sorry, I didn't work on that, not sure
[22:54] <Saviq> robert_ancell, nw, will talk to seb tomorrow
[22:54] <Saviq> have a good day :)
[22:55] <robert_ancell> Saviq, will do!
[23:24] <cjwatson> doko: I'll look at them
[23:24] <cjwatson> doko: python-cryptography was blocking six
[23:24] <cjwatson> (due to autopkgtests)
[23:25] <cjwatson> doko: python-cryptography looks more like python3-pytest being broken, but I thought that was already fixed ...
[23:26] <cjwatson> hmm
[23:27] <cjwatson> doko: OK, python-cryptography is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814622, not my problem :-)
[23:27] <cjwatson> (see end of bug log)
[23:27] <cjwatson> should be fine once that finally gets fixed one way or another
[23:32] <Saviq> cjwatson, do you have power over autopkgtests? could you help with un-stucking the In progress run here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-api ? it's been like that for a good 4h now
[23:34] <cjwatson> Saviq: if I can remember how
[23:34] <cjwatson> IRC logs to the rescue
[23:34] <Saviq> cjwatson, maybe https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration will help
[23:35] <cjwatson> Saviq: yeah, I found it; should unstick in a bit
[23:37] <Saviq> thanks