[00:11] <robert_ancell> doko, yeah, I think I have a solution for that, was just waiting to see if upstream agreed http://lists.x.org/archives/xorg-devel/2015-September/047504.html
[04:04] <FourDollars> Who can help me to change the bugs status of https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095? Changing "Trusty" of "network-manager (Ubuntu)" to "In Progress".
[04:09] <TJ-> From Fix Released to In Progress ?
[04:10] <FourDollars> Yes
[04:10] <FourDollars> Because it is not fixed.
[04:14] <TJ-> Done
[04:14] <FourDollars> Can we still fix the bug for wily now?
[04:14] <FourDollars> TJ-: Thx.
[04:16] <FourDollars> I have a patch for libmbim (Ubuntu) wily. It is reviewed and approved but still no "Fix-Commited" for wily.
[04:16] <FourDollars> s/Commited/Committed/
[04:17] <TJ-> I think you need to ping one of the core devs responsible for getting it out. I suppose beta freeze might be affecting things
[04:19] <FourDollars> OK.
[06:31] <pitti> Good morning
[06:31] <FourDollars> Good morning
[06:32] <FourDollars> Could you help me to change the bug status of modemmanager (Ubuntu) Trusty of https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095 from "	
[06:32] <FourDollars> Fix Released" to "In Progress"?
[06:38] <seb128> FourDollars, done
[06:39] <FourDollars> seb128: Thx
[06:39] <seb128> yw
[06:41] <FourDollars> seb128: There is still no bzr branch for trusty on https://code.launchpad.net/network-manager so I am going to attach the debdiif on https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095.
[06:41] <seb128> FourDollars, that makes sense
[06:42] <FourDollars> seb128: Could you help to release the libmbim for wily?
[06:42] <seb128> FourDollars, oh right, let me have a look
[06:42] <FourDollars> seb128: thx
[06:43] <seb128> yw!
[06:57] <FourDollars> seb128: Could you also help to review other patches for trusty?
[06:57] <seb128> FourDollars, depending on which components?
[06:58] <FourDollars> seb128: libmbim, network-manager and modemmanager.
[06:59] <seb128> FourDollars, n-m/modemmanager you probably want cyphermox
[06:59] <FourDollars> seb128: https://code.launchpad.net/~fourdollars/ubuntu/trusty/libmbim/1441095/+merge/273015, https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095/comments/56 and https://code.launchpad.net/~binli/ubuntu/trusty/modemmanager/lp1441095/+merge/272054.
[07:00] <FourDollars> seb128: OK
[07:03] <FourDollars> seb128: I think the trusty patches of libmbim and network-manager are pretty simple.
[07:06] <doko> mvo, https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.6ubuntu1
[08:03] <doko> jamespage, designate (1:1.0.0~b3-0ubuntu1 to 1:1.0.0~rc1-0ubuntu1)
[08:03] <doko> Maintainer: Ubuntu Developers
[08:03] <doko> Section: universe/misc
[08:03] <doko> 2 days old
[08:03] <doko> python-designate/amd64 unsatisfiable Depends: python-dnspython3 (>= 1.12.0)
[08:03] <doko> Not considered
[08:03] <jamespage> doko, urgh - ok lemme fix that up
[08:03] <jamespage> I thought I already did
[08:04] <doko>  python-dnspython3 isn't packaged
[08:07] <jamespage> doko, yes and its for py3 only
[08:08] <jamespage> doko, the dependency generation script we use needs a tweak
[08:09] <jamespage> doko, coreycb already fixed that but needed me to sponsor (I forgot)
[08:44] <doko> willcooke, Laney: I rejected the libreoffice upload, because it discards the changes made in 1:5.0.1-0ubuntu2. There is also no FFE accepted yet. LP: #1495512 is filed, but doesn't have any subscriber
[08:45] <Laney> doko: that upload says it is a bugfix release
[08:45] <Laney> s/upload/bug/
[08:45] <doko> Laney, then why file a FFE? ;p
[08:46] <pitti> coreycb: FYI, http://autopkgtest.ubuntu.com/packages/c/ceilometer/wily/amd64/ regressed, so it's stuck in -proposed
[08:46] <Laney> don't ask me, but it's not relevant as a reject reason
[08:46] <doko> I gave the reason
[08:46] <Laney> maybe the other part still stands :)
[08:47] <pitti> seb128: aptdaemon regressed, it
[08:47] <pitti> seb128: 's stuck in -proposed, FYI
[08:47] <seb128> pitti, ?
[08:47] <pitti> http://autopkgtest.ubuntu.com/packages/a/aptdaemon/wily/amd64/
[08:47] <seb128> pitti, the uploda that changed a one line to the lintian profile?
[08:47] <seb128> that seems buggy to me
[08:47] <pitti> nose.proxy.AssertionError: 'binary-file-compressed-with-upx' not found in 'Lintian check results for /t
[08:47] <Laney>     self.assertIn("binary-file-compressed-with-upx", trans.error.details)
[08:48] <Laney> ha
[08:48] <pitti> seb128: the failed test case does sound related to a lintian change, yes
[08:48] <seb128> that test was removed from lintian
[08:48] <seb128> not an aptdaemon issue...
[08:48] <pitti> ah, so do we need to drop that check from aptdaemon then?
[08:49] <seb128> urg
[08:49] <Laney> you need to fix aptdaemon's test yeah
[08:49] <pitti> did we get a new lintian yesterday? aptdeamon succeeded on Sep 29, and failed yesterday
[08:49] <seb128> yeah, it seems like a forgot a line
[08:49] <Laney> assumedly to exhibit a different lintian error so the test still does something
[08:49] <seb128> pitti, no, but aptdaemon's profile included that test which was not in lintian anymore
[08:49] <pitti> err no, lintian changed on Aug 17
[08:49] <seb128> and that lead software-center to claim packages were bad quality
[08:49] <seb128> let me do another aptdaemon upload to drop the test as well
[08:50] <pitti> seb128: ah, so the patch dropped it from the aptdaemon code but not its tests?
[08:50] <pitti> seb128: cool, thanks
[08:50] <seb128> right
[08:50] <seb128> local build worked
[08:50] <seb128> I guess those tests are not done on build
[08:50] <pitti> seb128: I thought aptdaemon would run its tests during package build too
[08:50] <pitti> weird
[08:51] <Laney> seb128: it would be better to change the test to use a different tag instead of dropping it
[08:51] <Laney> it does check something useful
[08:51] <seb128> Laney, please do the change if you have an idea how to do it :-)
[08:51] <Laney> look at one of the tags we are still erroring on and make a deb which has that
[08:52] <seb128> k, adding to my todo
[08:52] <seb128> I've 3 or 4 things ongoing though
[08:52] <seb128> so likely for later this afternoon
[08:52] <Laney> up to you, but I think it makes sense
[08:52] <Laney> :)
[08:52] <seb128> shrug, I wish the new glib would hit wily
[08:52] <seb128> gedit segfault 3 of 4 timesz
[08:52] <seb128> that drives me mad
[08:52] <Laney> already looking
[08:53] <seb128> thanks
[08:54] <seb128> pitti, thanks for pointing out the aptdaemon test issue!
[08:54] <Laney> bleh, we forgot to upload dbus-test-runner
[08:57] <pitti> seb128: no worries -- emulating the still missing email notifications :)
[09:02] <Laney> the personal touch is a nice one :P
[09:05] <pitti> Laney: *puts a cherry on top*
[09:05] <pitti> seb128: that's colord and dbus-test-runner/ppc64el only, right?
[09:06] <Laney> I retried those
[09:06] <seb128> pitti, was that meant for Laney? I'm not aware of those...
[09:06] <pitti> seb128: I meant what's holding up glib2.0, looking
[09:06] <seb128> oh ok, Laney is on it
[09:07] <seb128> FourDollars, libmbim uploaded to wily/trusty
[09:07] <pitti> dbus-test-runner seems very unstable on ppc, I'll fudge that
[09:08] <Laney> pitti: retried it already, let's see
[09:08] <Laney> I pinged ted_g in another channel to review it too
[09:08] <Laney> (larsu made a fix)
[09:10] <seb128> cyphermox, hey, could you have a look to bug #1448879 seems like you discarded a patch when syncing the new version
[09:10] <FourDollars> seb128: Cool~ Thx a lot. :D
[09:10] <seb128> FourDollars, yw!
[09:11] <Laney> pitti: passed that time
[09:11] <pitti> Laney: ah, your lucky day!
[09:11] <Laney> is Ted at this sprint you are at? ;-)
[09:12] <pitti> Laney: do you mean me? no
[09:13] <Laney> pitti: yeah - oh well
[09:13]  * Laney is using running.html
[09:13] <larsu> Laney: just merge it! :P
[09:14] <Laney> tempted
[09:14] <larsu> it's been long enough
[09:14]  * larsu is annoyed by long review times
[09:16]  * pitti fixes the bug that some armhf results are eternally "in progress" -- go time zones
[09:16] <Laney> uh?
[09:17] <pitti> Laney: http://autopkgtest.ubuntu.com/packages/o/oss4/wily/armhf/
[09:17] <pitti> Laney: look at the two topmost results -- the second one is newer than the first, but it wasn't considered
[09:17] <pitti> one of the workers was in PDT, and the others in UTC
[09:17] <pitti> I set it to UTC, but I also just pushed a worker fix to make the swift timestamps UTC
[09:17] <pitti> so that worker time zones stop mattering
[09:19] <Laney> ah, and it was storing just a bare time
[09:19] <Laney> nice
[09:24] <doko> coreycb, jamespage: looking at the ryu MIR ... may I ask to package python3-ryu as well, and to use python3 in ryu-bin?
[09:25] <Laney> rbasak: Hey, noticed that mariadb-10.0 is wily < vivid-security
[09:25] <Laney> ok to copy it up?
[09:31] <Laney> tseliot: this ^ situation applies to nvidia-346 too
[09:46] <dholbach> Laney, is the ubuntu-wallpapers upload good to go?
[09:47] <dholbach> Laney, if yes, do you think you could upload it? I have a bit of a bad connection here
[09:47] <Laney> OK
[09:47] <Laney> thanks
[09:47] <smb> pitti, Hi! To get back to the discussion we had yesterday (if sprint allows), the build of dahdi-dkms would use plain wget for downloads which should honor http[s]_proxy if set. I do not see a real change between the trusty and wily package in that area. Now the details of the failure would be in the dkms log which I have no idea how to get from an environment that fails...
[09:52] <tseliot> Laney: what situation?
[09:52] <Laney> tseliot: vivid > wily
[09:52] <tseliot> Laney: there's no nvidia-346 in wily, we have 352
[09:53] <Laney> tseliot: it's still in the archive
[09:54] <tseliot> Laney: yes, but it should be a transitional package provided by 352
[09:55] <Laney> so the old source packages should be removed?
[09:55] <tseliot> Laney: yep
[09:56] <ricotz> hello :)
[09:56] <Laney> tseliot: any chance you could file that? :)
[09:56] <tseliot> Laney: doesn't that happen automatically after a while?
[09:57] <Laney> don't think so
[09:57] <Laney> unless there's something I don't know
[09:57] <ricotz> is someone hit by some intltool/gettext failures on armhf builds recently? (qemu crashing while checking for it) happens for vivid and wily builds
[09:57] <tseliot> Laney: ok, I can file that request
[09:58] <Laney> thanks
[09:58] <pitti> smb: hm, don't we export the dkms log as an artifact? if not, we really should
[09:59] <cjwatson> ricotz: qemu-user-static fails on lots and lots and lots of things
[09:59] <pitti> smb: bah, seems we really don't
[09:59] <cjwatson> we're lucky it ever works
[10:00] <ricotz> cjwatson, I see, so if I retry it it might work at some point?
[10:00] <ricotz> cjwatson, although it seems pretty consistent and fails all the time afaics
[10:00] <smb> pitti, that log only exists for dkms builds obviously and in a bit of a complicated path. I guess its hard to squeeze those smarts into a generic thing
[10:01] <ricotz> cjwatson, just for reference https://launchpad.net/~ricotz/+archive/ubuntu/docky/+build/7992439
[10:01] <cjwatson> ricotz: well no, I'm saying that if qemu can't do it you may have to give up
[10:01] <cjwatson> there's a swathe of stuff it just can't manage
[10:01] <pitti> smb: oh wait -- our generic DKMS runner actually does export the logs, like in e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/i386/b/bcmwl/20150930_180209@/artifacts.tar.gz
[10:01] <ricotz> cjwatson, precise and trusty builds works (exactly same source packages)
[10:02] <cjwatson> ricotz: there may be differences in which syscalls it happens to tickle
[10:02] <cjwatson> ricotz: or use of threading
[10:02] <pitti> smb: dahdi-linux has its own debian/tests/, so it's not using the synthesized dkms tests
[10:02] <cjwatson> ricotz: hopefully we'll have a better system for virtualised armhf builds in a few months
[10:03] <ricotz> cjwatson, ok, this kind of autotools check isn't that uncommon since it is quite the default and probably hit a lot of other packages too
[10:03] <jamespage> doko, looking now
[10:04] <cjwatson> ricotz: *shrug* I'm sorry it's not something we can fix
[10:04] <cjwatson> ricotz: other than by replacing the existing system relying on qemu-user-static
[10:05] <ricotz> cjwatson, alright :\, thanks
[10:05] <cjwatson> ricotz: in some specific cases it *may* be possible to reproduce them locally and pare it down to a test case that could be sent to qemu upstream - but a lot of these come down to "qemu-user-static can't reliably support threaded code", and even for those that don't it's an awful lot of effort
[10:08] <ricotz> cjwatson, I see
[10:09] <cjwatson> ricotz: but we have arm64 hardware in place which will be used to build a replacement for the qemu-based builds - once the team working on it is done with building the cloud for power builds, I believe arm is next
[10:09] <pitti> smb: running dahdi-linux/trusty manually now, then I can ssh in and do stuff for you
[10:10] <smb> pitti, ah thanks. trying to look at the artifacts you mentioned but getting distracted by brother asking for ubuntu support... :-P
[10:12] <smb> oh wait missed that was for a different package
[10:17] <jamespage> doko, urg - no python3-formencode
[10:21] <pitti> Laney: glib> I filed bug 1501697 to keep track of this
[10:21] <pitti> Laney: i. e. glib is now held because we got a new unity8; that shouldn't re-run already succeeded tests
[10:21] <pitti> (just FYI)
[10:24] <pitti> smb: I'm now in a shell with the failed test
[10:25] <pitti> smb: make.log actually looks fine
[10:25] <smb> pitti, ok, so can you easily see in the mentioned dkms log whether it is ... oh
[10:25] <pitti> $ dkms status
[10:25] <seb128> Laney, pitti, ok, aptdaemon fix uploaded, it was easy, barry added  a patch to the package this cycle that was not needed/wrong with the lintian changes, dropping it and going back to upstream code makes things work
[10:25] <pitti> dahdi, 2.5.0.1+dfsg-1ubuntu4~14.04.3: added
[10:25] <pitti> seb128: yay
[10:25] <pitti> smb: but "added" isn't enough, is it? it shold be "installed" or so
[10:25] <Laney> pitti: thanks!; seb128: nice!
[10:25] <smb> pitti, added in that case is bad it should be installed
[10:25] <smb> pitti, yes
[10:26] <pitti> find /lib/modules -name '*dadhi*'
[10:26] <pitti> smb: nothing ^
[10:26] <pitti> Error!  Build of dahdi_vpmadt032_loader.ko failed for: 3.13.0-65-generic (x86_64)
[10:26] <smb> pitti, there should be that log file under /usr/src/... that got mentioned.
[10:26] <pitti> smb: that's on stderr ^ so perhaps another log or so?
[10:26] <pitti> smb: mentioned where?
[10:27] <Laney> ah, that reminds me
[10:27] <smb> pitti, normally in the build error ... though not /usr/src it seems ... /var/lib/dkms/dahdi/2.5.0.1+dfsg-1ubuntu4~14.04.3/build/make.log for some example
[10:27] <smb> pitti, version numbers may vary of course
[10:27] <pitti> smb: yes, that's what the stdout says; but tat make.log looks okay
[10:28] <pitti> smb: ah, no!
[10:28] <pitti> onnecting to downloads.digium.com (downloads.digium.com)|2001:470:e0d4::ee|:80... failed: Network is unreachable.
[10:28] <pitti> http://downloads.digium.com/pub/telephony/firmware/releases/dahdi-fwload-vpmadt032-1.25.0.tar.gz
[10:28] <pitti> smb: wget'ing this file works fine
[10:29]  * smb wibbles
[10:29] <pitti> smb: maybe the dkms env gets cleaned so that it doesn't see $http_proxy any more?
[10:29] <doko> jamespage, well, no surprise for a 2012 package ... but there is https://pypi.python.org/pypi/FormEncode/1.3.0
[10:29] <pitti> smb: and that got fixed in wily or so?
[10:29] <smb> pitti, hm... maybe but why not also when it does the wily build
[10:29] <smb> oh... so dkms
[10:29] <pitti> smb: /me diffs trusty vs. wily dkms
[10:30] <smb> pitti, maaaybe ... that would be evil indeed...
[10:30] <jamespage> doko, yeah - I'm just concerned this will snowball in impact
[10:30] <jamespage> formencode has a few reverse-depends
[10:30] <pitti> smb: hm no, there's nothing relevant at all
[10:30] <pitti> smb: so maybe in dahdi-linux itself
[10:31] <jamespage> doko, I'll commit my team to the work, but can we defer for wily and do in +1?
[10:31] <smb> pitti, i try to get that checked
[10:33] <pitti> smb: I checked ./drivers/dahdi/firmware/Makefile and I can't immediately see a difference either
[10:33] <doko> jamespage, sure
[10:34] <smb> pitti, yeah... unlikely the makefile... wonder about the dkms.conf maybe ...
[10:35] <pitti> smb: no relevant diff
[10:36] <pitti> smb: is that actually blocking stuff, or more like "I like green"?
[10:36] <pitti> smb: (it's
[10:36] <pitti> "always failed", thus sholdn't block stuff?)
[10:37]  * pitti runs "$ sudo dkms build dahdi/2.5.0.1+dfsg-1ubuntu4~14.04.3
[10:37] <smb> pitti, kinda. the current upload basically adds dep-8 because I thought its now working and so we can see when we break stuff with hwe kernels
[10:38] <pitti> smb: I'm heading for lunch, but I let the instance run for a bit
[10:38] <pitti> smb: if you can think of anything else which you'd like me to try there
[10:38] <smb> pitti, ok... reminds me to get food as well
[11:16] <dupondje> where is that cyphermox hiding :)
[11:18] <seb128> dupondje, likely in his bed, it's only 7am where he lives
[11:25] <TJ-> Is there a more appropriate channel for dealing with modification of the ISO images?
[11:30] <pitti> seb128: ah, glib2.0 is in
[11:43] <pitti> smb: I found a difference
[11:43] <pitti> smb: in the shell that I get on trusty there are no $*_proxy, but in the wily shell there are
[11:43] <smb> pitti, sorry otp kinda get back in a bit
[11:44] <pitti> smb: I'm not done debugging yet, I just excluded dkms and dahdi-linux themselves
[11:52] <pitti> smb: !
[11:52] <pitti> smb: the difference is that "sudo -i" uses /etc/environment in wily, but not trusty
[11:53] <smb> pitti, doh!
[11:53] <pitti> smb: the testbed has the proxy in /etc/environment, but the vars are unset for root
[11:56] <pitti> smb: so apparently we changed pam_environment somehow
[11:58] <pitti> smb: /etc/pam.d/sudo looks identical, though
[12:11] <dholbach> Laney, thanks for sponsoring
[12:12] <Laney> dholbach: might be 0.001% of the number of sponsorings you did for me back in the day :)
[12:13] <Mirv> Laney: not sure if you noticed, but you uploaded "vivid-security" mariadb-10.0 to wily https://lists.canonical.com/archives/wily-changes/2015-October/011123.html
[12:13] <Laney> Mirv: I copied it
[12:13] <Mirv> ok then
[12:49] <smb> pitti, Ok, now back. Sorry I was quite distracted. So maybe it sounds like one option may be to enhance the dkms part of dahdi with sourcing in /etc/environment before the build just in case for the the Trusty part. That should not hurt for "normal" builds outside the adt case either
[12:49] <seb128> pitti, re glib, great ;-)
[12:51] <pitti> smb: I was trying to move the env vars to /etc/profile as I source that in the test runner, but it still doesn't work
[12:52] <smb> pitti, Ah ... ok. Darn.
[12:53] <pitti> smb: so, I have a feeling that this is solvable somehow, I just don't have enough quiet time here to figure that out
[12:54] <smb> pitti, Yeah, we could ... erm you and me trying to help, work on this another day/week.
[12:56] <smb> pitti, The only thing I would avoid this to block is letting the added dep-8 testing upload out of proposed. Because the one that is pending after that would fix some build failure
[12:57] <pitti> smb: sorry, parse error; you want to release http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#dahdi-linux or not release it?
[12:58] <smb> pitti, maybe I should switch to German :-P I would release it.
[12:59] <smb> pitti, I got another upload (not uploaded yet) pending sponsorship when the current one is done
[12:59] <pitti> smb: can do, it's verified and 7 days
[12:59] <pitti> smb: released
[12:59] <smb> pitti, thanks a lot. I'll hassle me favourite sponsor about the follow up :)
[13:04] <cyphermox> dupondje: hey
[13:05] <doko> tdaitx, did you intend to keep the old libecap?
[13:07] <tdaitx> doko, squid 3.3 and 3.4 require libecap 0.20 (libecap2), only squid 3.5 can use libecap 1.0 (libecap3)
[13:07] <dupondje> cyphermox: hi, did you see my pm? :)
[13:08] <dupondje> cyphermox: https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1448879
[13:09] <doko> tdaitx, understood, so you want to remove the libecap in -proposed?
[13:09] <doko> and not merge squid?
[13:10] <tdaitx> doko, I agree that merging squid would be preferred, but when I started I was just trying to get the existing one to build, rbasak was working on the merge
[13:10] <tdaitx> since we don't have the merge yet I decided to finish and post my patches just in case
[13:11] <doko> ahh, ok, so lets wait
[13:18] <doko> pitti, could it be that the autopkg tests don't uses parallel builds?
[13:19] <seb128> dholbach, Laney
[13:19] <seb128> +Package: ubuntu-wallpapers-wily
[13:19] <seb128> +Description: Ubuntu 15.04 Wallpapers
[13:19] <seb128> that should be 15.10
[13:52] <seb128> bdmurray, pitti, what's the standard way to propose a change against the apport ubuntu packaging vcs? I would like to get review for http://paste.ubuntu.com/12631780/
[14:13] <pitti> doko: if this requires anything else than "dpkg-buildpackage -us -uc -b", then no; that's just what I'm calling
[14:14] <pitti> doko: do we need to call it with -j<numcpu>?
[14:14] <pitti> seb128: Vcs-Bzr: is up to date, so if you want do an MP or just commit (it
[14:14] <pitti> seb128: 's ~ubuntu-core-dev)
[14:14] <seb128> pitti, yeah, I've the right vcs, I just didn't figure out where to push
[14:15] <seb128> usually I push to ~user/project/somebranche
[14:15] <pitti> seb128: ah, is UbiquitySyslog a str, not a bytearray?
[14:15] <seb128> pitti, correct
[14:15] <pitti> seb128: you can use ~seb128/ubuntu/wily/apport/fix-foo
[14:15] <seb128> k
[14:15] <seb128> ubuntu/wily/source was the bit I was missing
[14:15] <pitti> seb128: ah, I see - I think this does some opportunistic decoding when reading a report
[14:15] <seb128> I knew if was something like that
[14:16] <seb128> pitti, btw aptdaemon just migrated to wily ;-)
[14:16] <pitti> seb128: très bien !
[14:20] <seb128> bdmurray, pitti, k, https://code.launchpad.net/~seb128/ubuntu/wily/apport/str_no_decoding/+merge/273075 for review
[14:21] <seb128> hum
[14:22] <seb128> https://code.launchpad.net/~seb128/ubuntu/wily/apport/str_no_decoding/+merge/273076 rather
[14:22] <pitti> seb128: looks like you branched off trunk, not the wily VCS?
[14:23] <seb128> pitti, no, it's just the launchpad ui that picked lp:ubuntu/apport as default
[14:23] <pitti> seb128: ah no, you proposed merging into lp:ubuntu/apport, which is the UDD autogenerated one
[14:23] <seb128> ^ fixes it
[14:23] <seb128> right
[14:23] <seb128> launchpad tricked me :p
[14:39] <hallyn> @pilot in
[14:41] <cjwatson> pitti: You want DEB_BUILD_OPTIONS=parallel=<number of cores>, as launchpad-buildd does, not -j.
[14:42] <pitti> cjwatson: ah, good
[14:43] <pitti> cjwatson: grep -c '^processor\b' /proc/cpuinfo
[14:43] <pitti> cjwatson: or something more elaborate?
[14:45] <cjwatson> pitti: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/sbuild-package#L64 is our code, pretty much that
[14:45] <pitti> cjwatson: ah, and you clamp it to 1, thanks
[14:46] <cjwatson> Just in case
[14:49] <pitti> doko: added that ^ to adt-run now, and restarted bintuils/amd64
[14:51] <pitti> cjwatson: thank you
[14:52]  * dholbach hugs hallyn
[14:52]  * pitti hugs hallyn too, for the same reason (whatever good one it is) and LXC
[14:53] <pitti> oh, patch pilot I figure :)
[14:53] <dholbach> :)
[14:53] <hallyn> \o :)
[14:54] <cjwatson> pitti: cool
[14:55] <pitti> meh, I attached it to the wrong place
[15:01] <seb128> dholbach, thanks for fixing the typo ;-)=
[15:02] <Laney> pitti: are these akonadi tmpfails you killing the workers?
[15:02] <pitti> Laney: I retried them
[15:02] <Laney> just checking
[15:02] <pitti> Laney: I don't really know what's going on there, the log files don't have an error but adt-run exited with 1
[15:03] <Laney> I thought it might have been you killing them to deploy the parallel stuff
[15:03] <pitti> Laney: not sure about the bintuils one running out of space
[15:03] <pitti> Laney: no, there's no need to restart the workers, that's a change in the autopkgtest tree only
[15:04] <Laney> the second akonadi/amd64 got ENOSPC too
[15:04] <pitti> Laney: oh -- that actually smells like the adt-run *host* getting out of spae
[15:04] <pitti> /dev/vda1       9.9G  3.7G  5.7G  40% /
[15:05] <pitti> Laney: when it copied down the rather sizable build tree between the test
[15:05] <pitti> Laney: that also explains akonadi
[15:05] <pitti> Laney: looks like I should redeploy the adt-run host as a bigger instance
[15:05] <pitti> but I'm not gonna do this today
[15:06] <pitti> Laney: we were running linux, bintuils, and glibc at the same time, and they all rebuild themselves
[15:06] <pitti> so, mystery solved
[15:07] <pitti> Laney: so please don't retry libo etc. yet, let's retry the big ones (linux etc.) serially
[15:10] <rcj> stub, can you look at bug #1473533?  I've nominated series for SRU.  I'm happy to scratch my own itch and get those SRUs done, but I can't approve the nominations.
[15:11] <cjwatson> rcj: I've approved the nominations for you.
[15:11] <rcj> cjwatson, thanks
[15:12] <rcj> then I can spend time fixing the root issue rather than hacking cloud stream generation code with a "fix"
[15:14] <Laney> pitti: OK, I'll let you serialise these :)
[15:18] <Laney> I guess you could use block storage instead of asking for a beefier instance too
[15:19] <pitti> Laney: ah, does that give me an additional virt disk to mount?
[15:20] <pitti> Laney: i. e. to not waste additional CPUs/RAM (which I won't be needing), just disk?
[15:20] <pitti> single-core 2GB is just fine otherwise, just 10 GB disk is too small
[15:20] <Laney> pitti: indeed
[15:20] <Laney> I'm sure you can ask for it with juju somehow, just don't ask me how to do it :)
[15:20] <pitti> Laney: do you happen to have some details... ok
[15:20] <Laney> hahaha
[15:21] <juliank> As nothing was moving with regard to syncing the python-apt 1.0 final release since I asked a few weeks ago, I now gone with a bug report in bug #1501805.
[15:22] <juliank> If this does not get done, we'll have the same problems as in vivid with the non-PEP440 version number, amongst other issues
[15:22] <Laney> juliank: seems sensible, I'm sure it'll get dealt with
[15:23]  * juliank hopes so, having that weird ~beta3.1 thing will do no good.
[15:24] <arges> cyphermox: hey for bug 1486931, leitao gave the commits. Do you want to just re-format the patch with updated DEP-3 info and i can review that?
[15:25] <Laney> pitti: https://jujucharms.com/docs/1.24/storage
[15:25] <cyphermox> arges: k
[15:26] <pitti> Laney: oh, nice!
[15:26] <pitti> Laney: ah, seems new in 1.24, we don't have that command yet on wendigo
[15:27] <pitti> Laney: but anyway, we have a cpu1-ram2-disk50 flavor, that souds fine
[15:27] <Laney> pitti: ah right, that's a shame
[15:28] <pitti> Laney: or use nova directly for hot-adding
[15:28] <Laney> pitti: You probably want it all contained in the charm though?
[15:29] <Laney> unless you can call nova directly there
[15:29] <pitti> Laney: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=4beddeae66989301a939f2eaa5d3fd63ff825fad
[15:29] <pitti> Laney: I mean for patching the existing setup without redeploying
[15:29] <pitti> I just need it to go quiet, then mount /tmp from that storage
[15:29] <Laney> nod
[15:29] <pitti> Laney: but I'll redeploy on Monday or so, when I'm not on a sprint
[15:30] <pitti> Laney: good opportunity to fix bug 1480962
[15:52] <rcj> cjwatson, How do I number the versions when backporting the fix in python-tz?  wily is 2014.10~dfsg1-0ubuntu2.  Would vivid be 2014.10~dfsg1-0ubuntu2~15.04.0 as they would have the same content?
[15:57] <slangasek> smb: I haven't seen a dpdk reupload yet for the debian/copyright fix, is that pending?
[15:57] <smb> slangasek, yeah sorry pending me getting my sh... iny things together and pack it up
[15:58] <slangasek> ok :)
[15:58] <cjwatson> rcj: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging has examples
[15:59] <smb> slangasek, meanwhile you could probably reject it from new if you happen to be looking that direction
[15:59] <slangasek> smb: done
[15:59] <smb> slangasek, ta
[16:00] <rcj> cjwatson, excellent. bookmarked!
[16:04] <chiluk> infinity any update on the netboot respin for the new kernel?  lp 1481490
[16:20] <alkisg> flexiondotorg: hi, we've talked the other day on #ubuntu-devel about an issue with fcitx and Greek keyboard layout
[16:20] <alkisg> It's still an issue, we can't properly type Greek unless we uninstall fcitx-bin, which is depended upon by ubuntu-mate-core
[16:21] <alkisg> So the end result is that Greeks can't properly use mate
[16:21] <flexiondotorg> alkisg, OK, understood.
[16:21] <flexiondotorg> alkisg, I have a fix for that I believe.
[16:21] <flexiondotorg> I'll get on it.
[16:21] <alkisg> flexiondotorg: I tried with beta2, mate and vanilla ubuntu. It happened on mate but not on ubuntu
[16:21] <flexiondotorg> I think if fcitx is move from -core to the live seed everything will work.
[16:21] <alkisg> Thank you flexiondotorg
[16:22] <flexiondotorg> alkisg, The idea of moving fcitx to the live seed is based on me poking through the ubuntu seeds.
[16:22] <flexiondotorg> alkisg, Question.  - https://ubuntu-mate.community
[16:22] <alkisg> Let me check if both those flavours behave the same in the live cd...
[16:22] <flexiondotorg> Oops.
[16:23] <alkisg> ?
[16:28] <alkisg> flexiondotorg: ubuntu beta 2 live CD has a whole lot of fcitx packages installed, but it does not have the issue
[16:28] <alkisg> mate only has fcitx-bin, and does have the issue
[16:28] <alkisg> I'm wondering if the issue is in ubuntu-mate-core, or of it has something to do with the window manager...
[16:28] <flexiondotorg> So Ubuntu MATE has the issue in the Live session?
[16:28] <alkisg> Yes
[16:29] <flexiondotorg> Oh, bother.
[16:29] <alkisg> (both in the live and installed)
[16:29] <flexiondotorg> OK. More thought required.
[16:29] <flexiondotorg> Worst case, I yanked fcitx from Ubuntu MATE completely.
[16:29] <flexiondotorg> Or figure out how to work around this issue.
[16:30] <flexiondotorg> alkisg, Please can you file a bug against Ubuntu MATE describing this problem?
[16:30] <flexiondotorg> https://bugs.launchpad.net/ubuntu-mate
[16:30] <flexiondotorg> I'll need a bug reference in any package changes I might have to make.
[16:30] <FourDollars> cyphermox: Hi. Could you help to review https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095/comments/56 and https://code.launchpad.net/~binli/ubuntu/trusty/modemmanager/lp1441095/+merge/272054 for trusty?
[16:30] <flexiondotorg> alkisg, Thanks for testing.
[16:30] <alkisg> flexiondotorg: sure, will do, I'll also test some more
[16:31] <flexiondotorg> Thank you.
[16:31] <flexiondotorg> I suspect fcitx is being detected as the default input handler.
[16:31] <cyphermox> FourDollars: did we not already land this?
[16:31] <flexiondotorg> But on Ubuntu iBus is probably the default detected.
[16:32] <cyphermox> oh, I see, it landed in wily
[16:32] <alkisg> flexiondotorg: here's an interesting test, in the live session: dpkg -r --force-all fcitx; service lightdm restart ==> solves the problem. The dpkg -r ==> to not uninstall ubuntu-mate-core but only fcitx
[16:33] <FourDollars> cyphermox: Yup, but not include trusty.
[16:33] <cyphermox> right
[16:33] <cyphermox> I'll review it a little later, I want to finish other fixes first :)
[16:33] <alkisg> flexiondotorg: you're probably right, ibus is installed in ubuntu, not in mate
[16:34] <alkisg> And running on the live session
[16:34] <FourDollars> Ok. Take your time. Thx in advance.
[16:34] <flexiondotorg> alkisg, MATE has isn't own input system.
[16:34] <flexiondotorg> And fcitx is "getting in the way".
[16:34] <alkisg> flexiondotorg: one of the reasons we want to use mate is because it still respects the xorg settings, while ubuntu doesn't
[16:35] <flexiondotorg> alkisg, I'll fix it for you :-)
[16:35] <alkisg> So grp:alt_shift_switch is respected in mate, overriden in ubuntu by ubuntu-settings-daemon
[16:35]  * alkisg files a bug...
[16:35] <cyphermox> FourDollars: won't you also need libmbim changes in trusty too?
[16:36] <FourDollars> cyphermox: Yes, I need it. Just missing.
[16:36] <cyphermox> FourDollars: do you want to do the merge proposal?
[16:36] <FourDollars> cyphermox: I thought seb128 had done it.
[16:37] <FourDollars> cyphermox: I did. Wait a minute. Let me show you the link.
[16:37] <cyphermox> ok
[16:38]  * FourDollars is working by a tablet.
[16:39] <alkisg> flexiondotorg: https://bugs.launchpad.net/ubuntu-mate/+bug/1501832
[16:39] <FourDollars> cyphermox: https://code.launchpad.net/~fourdollars/ubuntu/trusty/libmbim/1441095/+merge/273015
[16:40] <cyphermox> oh, great. Looks like seb128 already uploaded that
[16:40] <FourDollars> Cool.
[17:00] <pitti> apw: (CC: jibel): how far are we from killing the old dkms jobs? (jibel asked todya)
[17:04] <apw> pitti, i am waiting confirmation from bjf and smb that they are done with the old and using the new
[17:04] <smb> apw, confirmed
[17:04] <apw> (that you have stopped using dkms-matrix and that adt-matrix is supplying what you need; if anythign)
[17:05] <gQuigs> should I divide this removal request bug up by source pacakge ?  - https://bugs.launchpad.net/ubuntu/+source/glade-3/+bug/1496227
[17:05] <smb> apw, Yep I have not looked back to the old one for a while and concentrated on the new one. You may have noticed some attempts at least to improve stuff with adt/dep-8 :)
[17:06] <apw> smb, indeed, thought so, but best to be sure :)
[17:08] <smb> apw, sure-ack
[17:13] <pitti> apw, smb: cool, thanks
[17:14] <pitti> jibel: zap it!
[17:15] <pitti> jibel: and then we can drop a lot of cruft from lp:auto-package-testing :)
[17:15]  * pitti → food
[17:44] <hjd> hallyn: Hello. I have to admit I don't know whether sync/feature freeze expection requests fall in under path pilots, but if it does, could you please take a quick look at bug 1500112?
[17:47] <hallyn> hjd: i can't do ffe's,
[17:47] <hallyn> thta's a #ubuntu-release thing i think
[17:47] <hallyn> quesitonwould be how big is the debdiff.  if it doesn't do much beside fix that bug then it shouldn't need ffe
[17:58] <gQuigs> hmm... it is much cleaner separate ..   now just for dockmanager -https://bugs.launchpad.net/ubuntu/+source/dockmanager/+bug/1501859
[17:58] <jibel> pitti, apw \o/
[17:58] <jibel> thanks!
[18:09] <hjd> hallyn: The diff should be rather small, but I don't have experience with FFEs and the documentation said that when in doubt, check first. Didn't know there was an #ubuntu-release though, I'll try there. Thanks :)
[18:58] <infinity> chiluk: Doing it nowish.
[19:11] <cjwatson> hjd: I'll deal with it, thanks.  No need for an FFE.
[19:16] <chiluk> thanks infinity
[19:21] <hjd> cjwatson: Thank you :)
[19:49] <juliank> barry: I have a fix for the stderr thing in python-apt :)
[19:50] <barry> juliank: other than Restrictions: allow-stderr? :)
[19:50] <juliank> barry: Yes, catching the warning and checking it's a deprecation one :)
[19:51] <juliank> barry: http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=91d32c8
[19:51] <barry> juliank: cool!  if you upload that to unstable, i can resync and drop our delta.  maybe we can even do that before the release team approves my 1.0.0ubuntu1 upload :)
[19:52] <barry> juliank: lgtm!
[19:52] <juliank> barry: There are also some fixes by mvo: http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=92f7e29f55bc0f4bf7bf9cc78730814700fb2284 and http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=598bbabf7a97962426e70233430cda78182b453b pending for 1.0.1
[19:52] <juliank> I think they're fine too
[19:53] <barry> +1
[19:53] <barry> juliank: do you have an eta for 1.0.1 in unstable?
[19:53] <juliank> barry: I'll do it now
[19:53] <barry> juliank: awesome, thanks.  as soon as that gets picked up by lp i'll sync it
[19:54] <barry> juliank: and i think that can be a straight up syncpackage rather than a merge
[19:54] <juliank> Yeah
[19:57] <juliank> barry: At some point, I really need to switch the build system over to pybuild instead of the ugly hack from the pre-python3 helper times
[19:57] <barry> juliank: +1 :)
[19:57] <hallyn> sforshee: bug 1483796 , you see that perf regression yourself?
[19:58] <sarnold> doko: this is reported as a gcc5 issue: https://bugs.launchpad.net/bugs/1501634
[19:58] <sarnold> the patch inthe second url looks like good old fashioned broken code though, heh
[19:58] <juliank> barry: meh, dinstall just started on ftp-master.d.o., this will take a while...
[19:59] <barry> juliank: no worries.  i'm here for several more hours :)
[19:59]  * juliank not. Just paused the walking dead to do the 1.0.1 release :)
[20:00] <barry> juliank: wow! that's dedication.  i've been binge watching season 5 on netflix and am about 1/2 through.  i don't know that i'd pause it for that reason. :)
[20:00] <juliank> Nah, I'll be here for two hours.
[20:01] <juliank> barry: I started with the series yesterday, and am now at season 2 episode 2, 8 minutes in.
[20:01] <barry> food, maybe.  sleep, pshaw.  work, hahahah (but don't tell slangasek :)
[20:02] <doko> sarnold, should that be fixed in gnupg?
[20:02] <barry> juliank: just call in sick tomorrow and have a great, sleep deprived and freak out filled weekend! :)
[20:02] <juliank> barry: I'm a student, and I have holidays :)
[20:02] <barry> juliank: :)
[20:02] <doko> juliank, enjoy
[20:03] <juliank> Two semesters left until M.Sc. in CS is complete.
[20:04] <jrwren> juliank: congrats.
[20:07] <juliank> Dammit, gbp dch put mvo as the uploader in the changelog...
[20:07] <juliank> I'm not sure what that tool is thinking
[20:08] <juliank> It's tagged and uploaded now, so I won't fix it anymore.
[20:09] <juliank> or wait, I will
[20:13] <sforshee> hallyn: yes I do
[20:14] <doko> robert_ancell, https://launchpad.net/ubuntu/+source/xserver-xorg-video-siliconmotion/1:1.7.8-1ubuntu3/+build/7987052
[20:15] <robert_ancell> doko, yeah, I was waiting to see if that patch I sent to xorg-devel was considered correct
[20:15] <hallyn> sforshee: and you're using that patch locally?
[20:15] <robert_ancell> doko, is this a daily poke I get for having something FTBFS? ;)
[20:15] <barry> juliank: well, 1.0.0ubuntu1 got approved, but i'll still do the syncpackage when it's ready
[20:16] <doko> robert_ancell, sorry, I'm trying to get this automated ;-P
[20:16] <robert_ancell> hah
[20:16] <juliank> barry: OK, sorry about the wrong bug number, BTW, I only noticed this yesterday. Not sure how it slipped in
[20:16] <sforshee> hallyn: yep, it's much better
[20:16] <barry> juliank: no worries, but do you remember the correct bug #?
[20:18] <hallyn> sforshee: i see, it's upstream :)
[20:19] <hallyn> sforshee: i don't see you having nominated that for trusty,but you said all major releases - should i add trusty?
[20:19] <juliank> I tagged it fix committed yesterday, let me have a look
[20:19] <juliank> It's bug #1484470
[20:20] <sforshee> hallyn: I don't think trusty was affected
[20:21] <hallyn> oh, ok.
[20:21] <juliank> barry: The wrong number came direct from john apparently, not sure if there was another bug about it
[20:21] <sforshee> or maybe it was ... my description makes it sound like it is, but my memory says it wasn't
[20:22] <juliank> where john = John R. Lenton <john.lenton@canonical.com>
[20:22] <hallyn> sforshee: hm, it's fixed in the unstable package
[20:23] <hallyn> but i guess it's a bit late for something so drastic
[20:23] <barry> juliank: ah, cool no worries then
[20:23] <sforshee> hallyn: mutt in trusty seems fine
[20:23] <hallyn> not a soothing difference eiterh  226 files changed, 33071 insertions(+), 40447 deletions(-)
[20:23] <hallyn> so i guess i'll just cherrypick your patch into wily - thx
[20:23] <juliank> barry: I uploaded 1.0.1 a few minutes ago, BTW
[20:25] <juliank> Now we only need to wait for dak and its friends
[20:26]  * juliank is mostly back to walking dead now. But they're just talking in the woods
[20:39] <infinity> chiluk: And both uploaded/accepted/building.
[20:40] <infinity> chiluk: If you can turn around verification on that reasonably quickly, that would be lovely.
[20:41] <infinity> chiluk: And poke me directly when you do, since I need to make seed changes at the same time as d-i is copied, or dailies explode. :P
[20:42] <infinity> Oh, actually, trusty is building with proposed right now, I guess I need to make those seed changes today.
[20:42] <infinity> La la la.
[20:44] <kentb_> mwenning: thanks! (2 days late lol)
[20:57] <chiluk> ok infinity sorry I missed that earlier I'll verify now-ish.
[21:01] <chiluk> nm I see that it's still building
[21:14] <juliank> too many zombies, i'll get bad dreams...
[21:17] <mwenning> kentb_, :-)
[21:24] <Unit193> infinity: Get a chance to review some things? ;P
[21:29] <infinity> Unit193: I feel like that question is a trap.
[21:29] <infinity> Unit193: Which things?
[21:30] <Unit193> infinity: cdimage/livecd-rootfs/debian-cd reviews, Openbox debdiff (likely too late, I'm fine dropping it.). :D
[21:30] <infinity> Unit193: Bug#, MPs, where am I looking?
[21:31] <infinity> Unit193: (If I had context on this at one point and forgot, sorry, I'm a bit headless chickeny this week)
[21:32] <infinity> chiluk: trusty-proposed and vivid-proposed should have bits published now, at least for the architecture I suspect you planned to test. :P
[21:32] <Unit193> infinity: Yes sorry, I thought that might trigger a memory, it's not just me being vague: https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 - https://code.launchpad.net/~unit193/livecd-rootfs/xubuntu-core/+merge/267880 - https://code.launchpad.net/~unit193/debian-cd/xubuntu-core/+merge/267879 -
[21:32] <Unit193> https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/5397648/+listing-archive-extra
[21:33] <infinity> chiluk: 376.1 for vivid-proposed, 318.30 for trusty-proposed.
[21:33] <chiluk> infinity, ok.. I'll kick off a virt-install net-install.
[21:34] <infinity> Unit193: Ahh, core, right, that would triggered more flashbacks than "openbox". ;)
[21:34] <infinity> s/would/would have/
[21:34] <Unit193> But then you're thinking Snappy! :---D
[21:35] <chiluk> infinity the dates for the netboot images are still old http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
[21:35] <infinity> Unit193: So, was this a flavour you intended to release with 15.10?  We tend to try to stick by the rule "if you didn't participate in Beta 2, you don't participate in release".
[21:35] <infinity> Unit193: If you just want the commits in there to alpha test the whole thing with an eye to being able to release ISOs "officially" for 16.04, there's no reason we have to wait until after release to do that.
[21:36] <infinity> chiluk: Because you're looking in updates, not proposed.
[21:36] <chiluk> doh
[21:37] <Unit193> infinity: If that's the rule, then sure I think we can get this reviewed with XXX in mind.
[21:39] <infinity> Unit193: Like all rules, it's bendable, but it's a good rule, IMO, in that it makes sure that you had something that was at least half functional and QAable a month before release, and aren't wasting time (yours or others) on trying to fix the world in the last month when you should just be adding polish that that Beta. :)
[21:39] <infinity> s/that that/to that/
[21:41] <infinity> Unit193: I'd agree that xubuntu-core, the packageset, is a special case here, because it's a strict subset of things you already need to fix and ship for Xubuntu proper.
[21:41] <infinity> Unit193: But you'll still need to suck some resources to fix xubuntu-core the ISO product, unless it's magically perfect the first time.
[21:46] <Unit193> infinity: Right, and we've tested something unofficial a bit, but not using the exact infra so it'll likely be a bit odd.  If it's good enough, or close to it then it might be nice to fix but otherwise that'll come later.
[21:53] <sarnold> doko: yes, the proper fix is going to be in gnupg
[21:55] <chiluk> infinity netboot looks to be going along swimingly.. booted fine.. installing now.
[22:00] <Unit193> infinity: (The Openbox issue was another one I poked you about, though.)
[22:31] <chiluk> infinity netboot install completed successfully http://paste.ubuntu.com/12635027/  ... additionally I checked for the existence of the sfc module and it was there like we expected...
[23:01] <juliank> barry: I think I'll turn some warning display on by default for all warnings in the test suite, so such bugs do not happen only during autopkgtests
[23:02] <barry> juliank: +1
[23:02] <juliank> That's the second time this happened, which is two times more than I'd like
[23:02] <barry> juliank: still waiting for LP to pick up 1.0.1
[23:03] <juliank> barry: Probably happens only after the dinstall run finished, in about 5 hours?
[23:03] <juliank> or 4 hours
[23:03] <barry> juliank: yeah, not sure, but that seems likely.  if not tonight, tomorrow
[23:05] <mdeslaur> infinity: what created the weird dual partition tables on our iso media?
[23:05] <mdeslaur> s/created/creates/
[23:06] <infinity> chiluk: So, that tested one of 4 things. :)
[23:09] <infinity> mdeslaur: xorriso, with a bit of prep.
[23:09] <infinity> mdeslaur: http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/view/head:/tools/boot/wily/boot-amd64
[23:10] <mdeslaur> infinity: ah, cool, thanks
[23:49] <TJ-> infinity: re: cdimage - could we switch to the syslinux project's MBR isohdpfx_c.bin instead of isohdpfx.bin at some point, to provide a workaround for several buggy BIOS implementations? bug 277903