[05:51] <sunweaver> MATE 1.12 will soon arrive in Ubuntu 16.04... http://sunweavers.net/blog/node/30
[06:41] <pitti> Good morning, and happy new year!
[07:21] <pitti> cjwatson, Laney: I had http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#perl be a "valid candidate" several times over the holidays, but update_output.txt was full of alleged uninstallability; I tried in a -proposed chroot and it all worked
[07:22] <pitti> cjwatson, Laney: may it be that britney objects to the removal of perl-modules (replaced by perl-modules-5.22), and this needs hinting?
[08:06] <dholbach> good morning
[08:07] <dholbach> @pilot in
[09:37] <xnox> doko, happy new year! The boost1.54 trusty, arm64 build log has this in it:
[09:37] <xnox> virtual memory exhausted: Cannot allocate memory
[09:37] <xnox> in a few targets. maybe we should disable parallel build on arm64 for it?
[09:38] <xnox> Logan, i was off until 2016, hence the _2016 nick ;-)
[09:39] <xnox> spinxsearch delta could be moved to debian now, now that it is maintained no? plus something rather uses sphinxsearch. possibly like the location auto-identification webapp. might need to be tested.
[09:52] <didrocks> cjwatson: hey! happy new year. Once you have time to have a look: http://paste.ubuntu.com/14398330/ (this is why grub isn't themed anymore in xenial). Tell me if you prefer a formal bug report
[10:31] <jamespage> cjwatson, hey - ok if I pickup your libqb merge? just having a run through HA related bits for 16.04
[10:54] <LocutusOfBorg1> hi folks!
[10:55] <LocutusOfBorg1> can anybody please retry this build? https://launchpad.net/ubuntu/+source/dspdfviewer/1.14-1/+build/8407197
[10:55] <LocutusOfBorg1> I presume it was failing due to some toolchain problem
[10:56] <LocutusOfBorg1> pitti, welcome back! to be nitpicking, you sponsored more than 12 packages to me :) Just you didn't look to this link I guess https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsoree=LocutusOfBorg&sponsoree_search=name
[10:56] <LocutusOfBorg1> but who cares :)
[10:56] <LocutusOfBorg1> welcome back
[10:57] <pitti> LocutusOfBorg1: ah indeed, so I was missing https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Martin+Pitt&sponsor_search=name&sponsoree=LocutusOfBorg&sponsoree_search=name
[10:57] <pitti> LocutusOfBorg1: happy new year too!
[10:58] <pitti> LocutusOfBorg1: build retried
[11:02] <LocutusOfBorg1> thanks! and thanks dholbach for the sync :)
[11:02] <LocutusOfBorg1> it is nice to have you all back
[11:11] <rbasak> doko: are you back today? About bug 1527865. Disabling LLDB entirely for i386 seems better to me than total FTBFS - at least an incremental improvement. And it's reported fixed on 3.8 so shouldn't have any ongoing maintenance burden. So are you happy for me to sponsor LocutusOfBorg1's comment 7 debdiff?
[11:12] <rbasak> LocutusOfBorg1: have you build tested that in a PPA, please?
[11:12] <jtaylor> will 16.04 still get glibc 2.22?
[11:12] <jtaylor> I'd love to have libmvec available in the LTS
[11:13] <LocutusOfBorg1> rbasak, I had, but I deleted due to space issues
[11:13] <LocutusOfBorg1> well, testing something disabled is difficult
[11:14] <LocutusOfBorg1> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/8743215
[11:14] <rbasak> OK. As long as it builds (and doesn't regress builds on other archs), I'm happy with that debdiff.
[11:15] <rbasak> I trust that your debdiff shouldn't regress any other archs in any way, except for latent bugs which for a development release I think is OK to risk on balance.
[11:15] <LocutusOfBorg1> it  should affect only i386, if this is what you care
[11:16] <rbasak> right.
[11:16] <LocutusOfBorg1> BTW if 3.8 will be the default fox xenial, we can also don't care too much
[11:16] <rbasak> LocutusOfBorg1: maybe ask for more PPA space BTW? I don't know what Launchpad's policies are on this, but as you are helping fix LLVM I think that would be a fair request.
[11:17] <rbasak> don't care too much> this also paves the way for an SRU to 15.10 to do the same thing, if you're interested in driving that?
[11:17] <LocutusOfBorg1> rbasak, the problem has been that I uploaded 6 llvm in a row, not sure how long the space of the previous one is freeded because of superceeded sources
[11:17] <LocutusOfBorg1> sure rbasak why not
[11:18] <rbasak> 6 llvm in a row> perfectly reasonable if you're working on fixing llvm :)
[11:24] <LocutusOfBorg1> rbasak, yes, but I guess the resources aren't freeded as soon as a new one is uploaded, so you need 4 times the space
[11:25] <rbasak> LocutusOfBorg1: I'm suggesting that you ask for 4 times the space :)
[11:25] <rbasak> LocutusOfBorg1: I appreciate you helping with this, and I don't want to see you inconvenienced.
[11:28] <LocutusOfBorg1> rbasak, actually I did the other builds on another ppa with more space https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+builds?build_state=built
[11:28] <LocutusOfBorg1> :)
[11:28] <LocutusOfBorg1> but I'm asking some more space
[11:41] <cjwatson> pitti: No, that's just a binary package.  More likely the autohint is missing some subset of the sources required for the transition ...
[11:42] <cjwatson> didrocks: thanks, will apply that or something similar once I get my feet under me :)
[11:43] <cjwatson> jamespage: libqb> no problem
[11:43] <jamespage> cjwatson, ta
[11:43] <pitti> cjwatson: ah, can that be added manually somehow?
[11:44] <pitti> cjwatson: we have an alpha-1 blocker ATM anyway, but that should be gone by tomorrow, and then I guess we should finish this
[11:44] <cjwatson> didrocks: shouldn't we try both paths for the sake of partial upgrades?
[11:44] <cjwatson> pitti: well, it relies on working out where the problem is first ;-)
[11:59] <jamespage> doko, xnox: good morning - how do we feel about pdf doc generation in Ubuntu main using fop? its currently broken (impacting on the s390 port for xmlstarlet which is blocking ceph migration) due to mismatching xmlgraphics - I've looked at merging fop 2.0 from debian, but it has a un-avoidable dependency onto something that's going to try to pull maven into main
[12:00] <jamespage> there are a handful of packages in main that use fop for pdf generation
[12:00] <xnox> aaaaaah =) jamespage, happy new year to you too! =)
[12:00] <jamespage> xnox, happy new year!
[12:00] <Odd_Bloke> xnox: PDF generation?  I'm having flashbacks... :p
[12:01] <jamespage> erlang, x11proto-core and xorg-docs BD on fop for this purpose
[12:01] <jamespage> and we have two reverse-recommends that could be dropped to suggests
[12:02] <jamespage> xmlto and libbatik-java
[12:02] <jamespage> vs ~160 package MIR for maven...
[12:02] <jamespage> I'm not sure why I've not just done this already...
[12:05] <xnox> jamespage, i'm a bit slow. what are you proposing? demoting fop to universe?
[12:05] <xnox> + sync new fop?
[12:05] <jamespage> xnox, yeah
[12:05] <jamespage> and a small delta on 5 packages to support that
[12:07] <xnox> jamespage, and then what? xmlto, erlang, xorg end up without docs?
[12:08] <jamespage> xnox, they end up without PDF docs - they still get htmls ones...
[12:10] <doko> jamespage, is fop the only thing pulling maven?
[12:10] <jamespage> doko, there are a few other deltas across main packages to avoid that right now
[12:11] <xnox> it seems to me that over the years, all that jamespage does is constantly avoid maven. when will the day come that we will not be able to avoid maven?
[12:11] <xnox> and has the delta of keeping maven away, is really worth maintaining?
[12:12]  * xnox is sure MIR team will love 160+ packages to review =)
[12:13] <rbasak> slangasek: mariadb-10.0 FTBFS on s390x (only). It's in universe and looked after in Ubuntu by the Debian maintainer, in sync with Debian and doesn't FTBFS on Debian buildds.
[12:13] <rbasak> slangasek: can you suggest how he should approach fixing this, please?
[12:13] <rbasak> I wonder if it's an environment issue.
[12:14] <rbasak> I see things like "InnoDB: Error: pthread_create returned 11" in some of the test failures.
[12:14] <xnox> rbasak, i can look into that. we have toolchain differences from debian on s390x, fyi
[12:14] <rbasak> xnox: I'd appreciate that, thanks. You can find otto in #debian-mysql on OFTC if you need him.
[12:15] <xnox> rbasak, but, mariadb-10.0 is ftbfs in xenial-release too on s390x, thus why would it matter? is it blocking something from being installable?
[12:15] <jamespage> xnox, doko: I'm not sure we have the resources to deal with the MIR and subsequent support overheads
[12:15]  * jamespage certainly spends alot less time of java bits these days...
[12:16] <rbasak> xnox: apparently it once succeeded, so the failure blocks proposed-migration: https://launchpad.net/ubuntu/+source/mariadb-10.0/10.0.22-4/+build/8448317
[12:16] <tumbleweed> do we document anything about our s390x port anywhere? I don't ever recall it even being announced
[12:17] <xnox> rbasak, it means there is NBS in proposed, and one should ask release team, to decruft mariadb-10.0 on s390x, in proposed =)
[12:17] <didrocks> cjwatson: yeah, it can be changed to do dual path detection, that makes sense, I wasn't in favor of adding a Breaks: against plymouth << path_change_version, but dual path sounds good. Want me to do it?
[12:17] <rbasak> xnox: I'd be fine with that, too, if that's acceptable.
[12:18] <xnox> rbasak, however, other things may have ended up building against it already. let me check.
[12:22] <cjwatson> didrocks: yeah, if you have time, please
[12:22] <didrocks> cjwatson: sure (will finish some other tasks first and will do)
[12:24] <rbasak> xnox: thank you for the help. Is it OK to point otto directly to you if in future he needs any more assistance with s390x for mariadb-10.0 in Ubuntu?
[12:26] <xnox> rbasak, yes.
[12:27] <xnox> rbasak, all things s390x i should be able to help with.
[12:29] <doko> jamespage, xnox: basically agrred, but if we come to a point where it makes more effort to keep things out of main ... we have to keep the component mismatches clear, and this one is unresolved now for more than two months ...
[12:32] <jamespage> doko, huh - the one blocking component mismatches is not the one I'm talking about either...
[12:32] <doko> jamespage, rbasak: ok, and who is supposed to fix this one?
[12:37] <didrocks> cjwatson: I just went for the easy solution (no need to use a for loop or anything else, rather added a deprecation note): http://paste.ubuntu.com/14399150/
[12:40] <cjwatson> didrocks: pushed to git, thanks
[12:40] <didrocks> thanks :)
[12:40] <cjwatson> doko: some of this should simplify once libbusiness-isbn-perl manages to be promoted
[12:41] <cjwatson> er, moved to release, that is
[12:50] <rbasak> doko: which one? jamespage's question or my question?
[13:05] <xnox> yeah, i made two uploads. let's see if they will build =)
[13:05]  * xnox goes to grab more coffee
[13:13] <doko> dholbach, please upload the boost1.58 mpi source package too when uploading boost1.58
[13:13] <dholbach> LocutusOfBorg1: ^ do you know about this?
[13:18] <Odd_Bloke> doko: hallyn: One of our partners is asking us about qemu 2.5. I notice that it has landed in stretch and sid; do you have any plans to get it merged for xenial?
[13:22] <LocutusOfBorg1> dholbach, what exactly?
[13:23] <dholbach> LocutusOfBorg1: what doko said
[13:23] <dholbach> LocutusOfBorg1: I uploaded your boost1.58 merge
[13:23] <LocutusOfBorg1> oh I see
[13:23] <LocutusOfBorg1> so next time just a plain sync?
[13:24] <LocutusOfBorg1> do you want an ubuntu2 with the patch reverted? so we enable it right now?
[13:25] <dholbach> doko: ^ can you maybe explain?
[13:26] <LocutusOfBorg1> now the merge is done, so sync is not possible anymore
[13:30] <doko> dholbach, a sync would end up in dep-wait. the mpi boost has to have the very same version number
[13:31] <dholbach> LocutusOfBorg1: ^
[13:33] <doko> Odd_Bloke, I'm not a qemu stakeholder, better ask hallyn about it
[13:34] <Odd_Bloke> doko: Ack; just saw your name on the last merge so thought I'd check in with you. :)
[13:37] <dholbach> @pilot out
[14:13] <xnox> doko, are there ftbfs results somewhere I can start looking at?
[14:23] <doko> xnox, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151218.1-xenial-baseline-xenial.html (yes, need to announce that)
[14:23] <xnox> doko, tah.
[14:36] <mitya57> doko, there are some failures without logs, ie https://launchpad.net/ubuntu/+archive/test-rebuild-20151218.1-xenial-baseline/+build/8562576
[14:36] <LocutusOfBorg1> doko, mpi-defaults is the same as debian I see
[14:36] <LocutusOfBorg1> so dholbach can sync the package then?
[14:44] <doko> LocutusOfBorg1, no, you don't understand
[14:47] <doko> https://launchpad.net/ubuntu/+source/boost-mpi-source1.58 needs an update
[14:48] <doko> mitya57, given back. I surely can give back these one more time, but then you don't have *any* build logs
[14:55] <dasjoe> cjwatson: I couldn't find any info about whether it's acceptable to send "git request-pull" formatted mails to Debian's bugtracker, so I hope the mail is useful to you
[14:57] <mterry> slangasek, do you mind subscribing foundations to libtest-mockmodule-perl bugs (for MIR bug 1529744).  Happy 2016, btw :)
[14:58] <cjwatson> dasjoe: it's not particularly helpful, but I can always ignore it ...
[14:58] <dasjoe> cjwatson: hah, okay
[14:58] <cjwatson> dasjoe: (I'm going to have to apply things in a different way than you're trying to do)
[14:59] <dasjoe> cjwatson: right, sorry for the noise, then :)
[15:19] <bobbyz> Hi guys.  Does anyone know how the debian-cd_info.tar.gz file is built (e.g. http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/cdrom/)?  The contents of that file are extracted and used to generate the boot files for the ubuntu live CD as part of the tools/boot/*/boot-* scripts in the lp:~ubuntu-cdimage/debian-cd/ubuntu project.  However, I can't find the build scripts that put together this
[15:19] <bobbyz>  debian-cd_info.tar.gz  file
[15:20] <cjwatson> they're in the debian-installer source package
[15:20] <bobbyz> cjwatson thanks!  I'll take a look there
[15:21] <smoser> infinity, is there anything i can do to help move hwe-w installer kernels into -updates ?
[15:22] <smoser> bug 1511497 . I can test and post results of a amd64 install if you'd like on that bug or anywhere else.
[15:32] <flexiondotorg> xnox, I've just seen your commit in the Ubuntu MATE seeds - Drop NBS gnome-control-center-shared-data.
[15:33] <flexiondotorg> What does NBS mean? And is there something replace gnome-control-center-shared-data?
[15:33] <LocutusOfBorg1> doko, I admit I'm lost, so drop the boost-mpi-source1.58 and sync boost-1.58 is fine? why did you split it?
[15:34] <didrocks> flexiondotorg: https://wiki.ubuntu.com/UbuntuDevelopment/NBS
[15:34] <pitti> LocutusOfBorg1: probably to keep mpi in universe, as boost itself is in main?
[15:35] <flexiondotorg> didrocks, xnox It would seem I just need unity-control-center-faces now :-)
[15:36] <xnox> LocutusOfBorg1, no no no no.
[15:36] <flexiondotorg> didrocks, Thanks for the learning :-)
[15:36] <xnox> LocutusOfBorg1, mpi is in universe.
[15:37] <xnox> LocutusOfBorg1, that's why we have each boost split into two source packages - one to build most of boost, in main. and another one in universe to build mpi portions.
[15:37] <xnox> LocutusOfBorg1, and there is loads of logic in debian/rules to update -mpi split package.
[15:38] <xnox> LocutusOfBorg1, if you sync boost, it will never build.
[15:38] <xnox> flexiondotorg, oh, really.
[15:38] <xnox> flexiondotorg, =) well, please fix that up. sorry about it, I didn't really get what the #Faces comment meant =)))))
[15:38] <flexiondotorg> xnox, Yeah, I just had gnome-control-center-shared-data in UBuntu MATE for faces.
[15:39] <flexiondotorg> Already push updated seeds for Ubuntu MATE :-)
[15:41] <dholbach> LocutusOfBorg1: I think both source packages need to be updated and have the same versions and everything (we have it because of the main/universe split)
[15:42] <xnox> dholbach, correct =)
[15:58] <TJ-> Anyone available to consider this improvement to cryptsetup/initramfs-tools key-file integration? bug 1494851
[16:21] <infinity> smoser: Some verification on LP: #1524366 would be helpful.  I was going to run some test installs today on a couple of arches, but if you want to do x86 for me while I do PPC, that would be lovely.
[16:22] <smoser> infinity, sweet. i was hoping you'd point me at your bug
[16:22] <smoser> thanks. i'm' in process of doingv amd64 and will do i386 for fun
[16:26] <infinity> smoser: Ta.
[17:01] <LocutusOfBorg1> ack xnox :) thanks a lot!
[17:01] <LocutusOfBorg1> wilco
[17:09] <LocutusOfBorg1> seems so easy then, sorry I didn't see the target mismatch
[17:18] <slangasek> mterry: done
[17:19] <mterry> slangasek, cheers!
[17:19] <slangasek> hallyn: did you still have questions about pam-auth-update?
[17:33] <hallyn> slangasek: nope, thx
[18:06] <mapreri> now, why can't I change lp #1306960 (in pencil2d) back to in progress...
[18:07] <mapreri> does it need ~ubuntu-bugcontrol superpowers that too?
[18:16] <mitya57> mapreri, I've just done it
[18:17] <mapreri> mitya57: thanks.
[18:17] <mitya57> I think only bugcontrol can reopen bugs, yes
[18:17] <mapreri> I should probably stop wasting everybody's time and get my motu hat too, umpf
[18:20] <mitya57> ++!
[18:54] <LocutusOfBorg1> cjwatson, stupid feature request (stupid to say, not to implement, sorry for that)
[18:54] <LocutusOfBorg1> e.g.
[18:54] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1530949
[18:54] <LocutusOfBorg1> build uploading on ppa:costamagnagianfranco/locutusofborg-ppa
[18:55] <LocutusOfBorg1> I would really appreciate (maybe my sponsors too) something that converts ppa:blah/blah2
[18:55] <LocutusOfBorg1> into https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/
[18:55] <LocutusOfBorg1> or something similar :)
[18:55] <LocutusOfBorg1> an a href would be awesome
[18:55] <lamont> what did I just change by freshening xenial, that alt-a is now getting eaten by something instead of passed through to gnome-term and therefore irssi
[18:56] <lamont> ah, nm
[18:56] <tarpman> LocutusOfBorg1: maybe not exactly what you want, but there's http://pad.lv/ppa/costamagnagianfranco/locutusofborg-ppa
[18:57] <LocutusOfBorg1> tarpman, sure, it is already really nnice
[18:57] <LocutusOfBorg1> maybe the regex is easy to implemtn
[18:57] <sarnold> tarpman: oh, nice, that ought to be amenable to a firefox search thingy..
[18:57]  * tarpman <3 pad.lv
[19:07] <stgraber> infinity: dmb meeting now in #ubuntu-meeting
[19:45] <doko> why are the linux autopkg tests still marked as fail?
[19:48] <doko> pitti, ^^^
[20:05] <elbrus> pitti: just thought to let you know: I will look into the autopkgtest failure of dbconfig-common myself, but it will take a few days because I first want to straighten out a CVE issue in one of my packages.
[20:13] <sarnold> LocutusOfBorg1: congratulations :)
[20:14] <LocutusOfBorg1> thanks!
[20:14] <LocutusOfBorg1> :)
[22:01] <ESphynx> hey guys, is there a way to request a rebuild on a ubuntu package that failed on a particular architecture?
[22:05] <ginggs> ESphynx: which package?
[22:07] <ESphynx> ginggs: https://launchpad.net/ubuntu/+source/ecere-sdk -- the amd64 build failed, strangely
[22:12] <ginggs> ESphynx: retrying... please check whether it fails the same way and file a bug if it does
[22:16] <ESphynx> ginggs: I am both upstream and maintainer
[22:16] <ESphynx> will certainly keep an eye on it :) Thank you.
[22:16] <ESphynx> (I strongly doubt it will)
[22:18] <ginggs> ESphynx: you are welcome
[22:26] <ESphynx> ginggs: it failed again :S
[22:26] <ESphynx> cat: ./usr/share/ecere/samples/3D/terrainCameraDemo/res/aircraft/06: No such file or directory -- This seems to be the problem
[22:27] <ESphynx> There's a PNG file named '06 17 09.png' (with spaces)
[22:27] <ESphynx> this funky PNG optimization stuff seems new?
[22:27] <ESphynx> pkgstripfiles: PNG optimization -- There seems to be a failure to handle those spaces
[22:27] <ginggs> PNG optimization has been around for a couple of releases now
[22:27] <ESphynx> But why would it only affect amd64?
[22:28] <ginggs> only amd64 because that's where the arch:all packages are built as well
[22:28] <ESphynx> ah. that explains
[22:28] <ESphynx> those resources are not new from the last version that built though
[22:29] <ginggs> notice that the arch:all and arch:amd64 packages were not built on the debian buildds https://buildd.debian.org/status/package.php?p=ecere-sdk&suite=unstable
[22:30] <ESphynx> Changing the actual content of PNG files does seem way over-reaching to me (as an upstream)
[22:30] <mhall119> slangasek: ping
[22:30] <ginggs> they were built by the uploader - sometimes this causes problems e.g. buildds have no network access, missing build-depends
[22:31] <ESphynx> ginggs: But I was referring to this previous version that built https://launchpadlibrarian.net/222298118/buildlog_ubuntu-xenial-amd64.ecere-sdk_0.44.11-0ubuntu2_BUILDING.txt.gz
[22:31] <mhall119> slangasek: a couple of things: (1) I sent emails to the TB and DMB lists from the CC about this cycle's regular catchup meeting, but they're waiting for moderation, can you let them through?
[22:31] <dobey> it didn't have a png file with spaces in its name?
[22:31] <ESphynx> dobey: it did have that same exact file
[22:32] <ESphynx> 06 17 09.png
[22:32] <mhall119> slangasek: (2) The Xubuntu developers said there is some outstanding issue with their xubuntu-core packages, that there might have been some concern about the name which was preventing it from getting into the archives, do you know anything about that?
[22:33] <ESphynx> could those 'cat' be new things that were recently added?
[22:34] <dobey> looks like maybe how png optimization is run was changed
[22:35] <ESphynx> dobey: seems like it's failing to treat spaces safely :P
[22:37] <dobey> ESphynx: i suspedt trying to build the same source on sid might have the same issue?
[22:37] <doko> ESphynx, dobey: yes, I changed that last month to run in parallel. There might be a bug then ... the source is in pkgbinarymangler
[22:38] <ESphynx> dobey: possible... I confess my pbuilder failed to upgrade
[22:39] <doko> dobey, pkgbinarymangler is Ubuntu only
[22:40] <dobey> ESphynx: ^^ ah, seems like you should file a bug against pkgbinarymangler then, per doko's comment
[22:40] <dobey> doko: ok, wasn't sure if it was something ubuntu specific, or a change in the build tools in debian too.
[22:41] <doko> dobey, ESphynx: I'm afk now. see the optimize_pngs function in pkgstripfiles
[22:46] <ESphynx> dobey: so it is ubuntu specific?
[22:46] <ESphynx> could you guys please file the bug?
[22:47] <ESphynx> you might be more familiar with those deiban/ubuntu tools :)
[22:47] <ESphynx> https://bugs.launchpad.net/ubuntu/+source/pkgbinarymangler -- Would this be the place?
[22:49] <ESphynx> Is it this line?  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkgbinarymangler/wily/view/head:/pkgstripfiles#L103
[22:49] <dobey> that package is the place, yes
[22:50] <dobey> well, no, that's the code in wily
[22:50] <dobey> https://code.launchpad.net/~ubuntu-core-dev/pkgbinarymangler/ubuntu is the upstream trunk code
[22:50] <dobey> lol, or not
[22:51] <ESphynx> http://bazaar.launchpad.net/~ubuntu-core-dev/pkgbinarymangler/ubuntu/files -- all gone? lol
[22:51] <dobey> ok, you probably need to pull-lp-source pkgbinarymangler then
[22:51] <dobey> because there is no lp:ubuntu/pkgbinarymangler branch
[22:52] <ESphynx> I'm sure other packages would suffer from this :P
[22:52] <dobey> at least, no bzr branch
[22:52] <dobey> anyway, file the bug
[22:52] <dobey> and include the few lines from the build log, showing the error
[22:53] <ESphynx> I can do that much
[22:53] <doko> dobey, ESphynx: uploaded a fix, please retry once it's published
[22:54] <ESphynx> doko: thank you. should I still file a bug? lol
[22:54] <ESphynx> I don't have permissions to retry the build
[22:54] <dobey> i guess not
[22:54] <ESphynx> but I keep an eye on it
[22:54] <ESphynx> thanks guys for the prompt support.
[22:54] <dobey> just ask for another rebuild then
[22:55] <ESphynx> ginggs, dobey could you please request another rebuild once pkgbinarymangler is published?
[22:56] <dobey> i have to go
[22:56] <dobey> so no :)
[22:56] <ESphynx> cheers dobey