[03:54] <pitti> Good morning
[03:55] <pitti> slangasek: yes, I'm beige; "jack" was already there (wondered about that myself), I just appended another transition; thanks for cleaning up
[03:55] <pitti> slangasek: I'm using the ben pages, and it indeed has lcmaps-plugins-voms; not sure how it got dropped, probably just mouse copy&paste error
[03:56] <pitti> doko: http://autopkgtest.ubuntu.com/packages/k/kservice/wily/i386/ WDYM install error? KSycocaThreadTest fails
[03:57] <pitti> slangasek: crystalspace> ack, can do; that's what I did with bombono-dvd, that works better I guess
[03:57] <pitti> Laney: ^ FYI, as you also did some
[03:58] <pitti> slangasek: yes, I removed the broken rebuild from wily-proposed and used demote-to-proposed, but then realized that this doesn't work well as it goes back to -release immediately
[03:58] <pitti> so just removing from wily sounds easier and better
[04:10] <slangasek> pitti: ah yes, demotion with binaries also has that problem :)
[04:11]  * pitti marks petsc++ as finished, feel++  is in -proposed
[04:48] <pitti> oh, where did sflphone go on the pad?
[04:49] <pitti> ah, slangasek demoted to -proposed; anyway, I have a fix now
[05:16] <slangasek> pitti: no objection to it being fixed of course, but it didn't look to me like something that should be allowed to continue blocking
[05:16] <pitti> slangasek: fully agreed, I just wondered for a second where the pad entry had gone
[05:17] <pitti> (it was rightfully removed -- just a bit of confusion there)
[05:17] <pitti> slangasek: "unbuilt/uninstallable" is holding up too much stuff, I'm dialing this back in britney now
[05:17] <pitti> as per u-r@ discussion
[05:25] <ricotz> good morning
[05:25] <ricotz> pitti, hi, small fix regarding the icu transition http://paste.debian.net/plain/291826
[05:26] <pitti> ricotz: ah thanks; could this just be committed to http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qt4-x11.git ?
[05:26] <pitti> an entire upload for (an essentially useless) Suggests: seems a bit exaggerated
[05:28] <ricotz> pitti, I see, and yeah should be fixed there too
[05:30] <ricotz> mitya57, hi, could you take a look at this ^
[05:44] <pitti> slangasek: sorry, uploaded duplicate rebuild of bisonc++ and ccbuild
[05:45] <slangasek> pitti: if that's a duplicate of something I did, don't worry, I'd rather have you be TIL than me ;)
[05:45] <pitti> slangasek: yes, you uploaded http://people.canonical.com/~ubuntu-archive/transitions/html/html/bobcat-g++5.html recently and I missed that
[05:46] <slangasek> pitti: "recently" as in within the past half hour, I think
[05:46] <pitti> I ^Ced my transition uploads after I realized the unexpected build2
[05:46] <pitti> slangasek: right; not much harm, just in case you wonder
[05:46] <slangasek> I'm mostly just spamming the 'mass-rebuild' button here
[05:46] <pitti> I earn the FTBFSes then :)
[05:47] <pitti> yeah, me too; was going over the remaining ones
[05:47] <slangasek> which at least turns up FTBFSes somewhere that people can see them without having to hunt - e.g. I think most of the bobcat revdeps FTBFS, judging by my inbox
[05:48] <slangasek> oh perhaps it's not as bad as all that
[05:48] <slangasek> guncat
[05:49] <slangasek> with pthreads fail
[05:52] <didrocks> stupid question but git-buildpackage in wily doesn't have the buildpackage command anymore? (it only has the bash completion) and it seems no other package has it, known?
[05:53] <pitti> didrocks: sure, "gbp buildpackage"
[05:53] <pitti> didrocks: the old aliases were removed in wily indeed
[05:53] <pitti> didrocks: it's now "gbp <verb>", no gbp-verb or git-verb any more
[05:54] <didrocks> pitti: ok, didn't know the other alias was deprecated, thanks!
[07:21] <dholbach> good morning
[07:51] <mitya57> ricotz: Will commit later today, thanksa
[07:52] <mitya57> The last 'a' should have been '!'
[08:12] <ricotz> mitya57, thanks
[08:51] <infinity> Sarvatt: Was your verification of LP: #1471213 on vivid or trusty+lts-vivid?
[08:58] <mitya57> ricotz, here you go: http://anonscm.debian.org/cgit/pkg-kde/qt/qt4-x11.git/commit/
[09:02] <seb128> @pilot in
[09:05] <infinity> seb128: Hey, since you're being community-oriented today, can you chase up the verification-failed on the SRU you uploaded for LP: #1440157 ?
[09:05] <infinity> seb128: Probably user error, but would be nice to confirm.
[09:06] <seb128> infinity, shrug, it was verification-done, can't we just ignore that user? ;-)
[09:08] <infinity> seb128: Possibly.
[09:10] <seb128> infinity, I've asked for some details
[09:14] <ttx> wgrant, cjwatson: Hi! Any idea why launchpadlib 1.10.3 was not uploaded to https://pypi.python.org/pypi/launchpadlib ? Just an oversight ?
[09:15] <wgrant> ttx: The only significant change was some pretty broken Python 3 support. We'll be releasing 1.10.4 soonish.
[09:15] <wgrant> I can't recommend using the Python 3 support in 1.10.3
[09:16] <ttx> wgrant: ah ok, makes sense.
[09:16] <ttx> wgrant: I'll wait for that before turning my py3 test jobs on
[09:25] <Odd_Bloke> If the bzr packaging branches for a package haven't been updated after an upload, what can I do to refresh them?
[09:25] <wgrant> Odd_Bloke: Which package?
[09:26] <Odd_Bloke> wgrant: cloud-init
[09:26] <wgrant> Hah
[09:26] <Odd_Bloke> (vivid, trusty, precise)
[09:26] <Odd_Bloke> Well, and maybe wily, but I'm doing backports so I don't care. :p
[09:26] <wgrant> Odd_Bloke: Any particular reason you're still using UDD?
[09:26] <wgrant> It basically only works for a given package once.
[09:26] <wgrant> We strongly discourage its continued use. It is barely on life support.
[09:27] <wgrant> We intend to replace it with something git-based in the relatively near term.
[09:27] <Odd_Bloke> wgrant: I really want version control so backporting multiple fixes is less painful.
[09:27] <Odd_Bloke> (Of the "dget ...; OH GOD ITS ALL GONE" variety)
[09:27] <wgrant> Odd_Bloke: You're probably better off maintaining your own branches in that case. The Bazaar implementation of UDD has some pretty fundamental flaws that prevent it from being reliably usable.
[09:28] <wgrant> Lessons that will be learnt from in any future replacement.
[09:28] <Odd_Bloke> OK, cool.
[09:28] <Odd_Bloke> My sponsor normally takes debdiffs anyway, so we probably aren't using it fully. :p
[09:30] <wgrant> Yeah
[09:30] <wgrant> cloud-init in particular has been broken since 2013.
[09:30] <wgrant> It's not unfixable, but it will unfix itself pretty quickly if I fix it.
[09:33] <seb128> bdmurray, seems like you maintain ubuntu-release-upgrader, could you update it to work the new pep8 in wily? it fails some tests because the new version is stricter, which is blocking webkitgtk or pyqt5 in wily-proposed
[09:34] <Odd_Bloke> Well, I'm more than happy to use my own git branches to track stuff. :)
[09:34] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/u/ubuntu-release-upgrader/20150813_000449@/log.gz
[11:14] <doko> wait, arm64 buildds almost idle? did we finish?
[11:15] <pitti> doko: heh, not quite yet :) http://people.canonical.com/~ubuntu-archive/transitions/
[11:16] <pitti> doko: I just had to stop pegging them for some hours do catch up with some other stuff
[11:16] <pitti> and we are getting into the "fewer rebuilds, more manual fixing work" zone
[11:17]  * Laney is fixing some K things to shrink the pending stuff that's blocking unity
[11:19] <doko> pitti, new dpkg arrived, could merge debhelper now?
[11:23] <pitti> doko: yes, currently looking at the dpkg test regressions
[11:24] <pitti> doko: running some package builds with new debhelper now, then I'll upload
[11:32] <pitti> doko: uploaded
[11:33] <Laney> ICE ICE baby
[11:34] <pitti> Laney: you booked a German hi-speed train? :-)
[11:34] <Laney> think of a worse kind of ICE :P
[11:34] <Laney> although I will be getting one of those soon!
[11:34] <pitti> Laney: they have enough of Internal Climate_control Errors, trust me :)
[11:35] <pitti> although I've been lucky this summer apparently
[11:35] <davmor2> https://www.youtube.com/watch?v=rog8ou-ZepE
[11:36] <pitti> davmor2: oh the sound of our youth :)
[11:37] <pitti> I think this came out when I was 10
[11:37] <davmor2> pitti: that's not the sound of my youth this is the sound of my youth https://www.youtube.com/watch?v=TLV4_xaYynY
[11:50] <mdeslaur> seb128, doko: I've looked at bug 1448548 , the openjdk rules file is broken
[11:51] <mdeslaur> or, maybe I'm reading that wrong
[11:51]  * mdeslaur looks again
[11:52] <seb128> mdeslaur, hey, well, I don't understand the intend
[11:52] <seb128> so I can't tell if it's right
[11:53] <seb128> there is a limited list of ubuntu series for some reasons
[11:53] <seb128> which are all unsupported ones
[11:53] <mdeslaur> yeah, I read it backwards, it's _not_ enabling cautious-launcher for those old releases which didn't have it
[11:53] <mdeslaur> the issue is ifeq ($(java_launcher),cautious-launcher)
[11:53] <mdeslaur> it's not equal as it's missing the parameters
[11:55] <mdeslaur> or maybe not....perhaps I should actually drink my morning coffee before saying a bunch of stupid things
[11:56] <seb128> lol
[12:08] <doko> Laney, do you look at the remaining kde autopkg test failures? might want to coordinate with Riddell
[12:10] <Laney> doko: mmm, hi Riddell!
[12:11] <doko> mdeslaur, ifneq (,$(findstring cautious-launcher, $(java_launcher)))
[12:11] <doko> fixed it
[12:11] <mdeslaur> doko: yeah, I was just compiling with exactly that change to test
[12:12] <mdeslaur> doko: can you push that to your trees for the next security update?
[12:12] <doko> mdeslaur, yes
[12:12] <mdeslaur> doko: cool, thanks
[12:30] <dragos> hi
[12:30] <dragos_> hi
[12:30] <dragos_> how r u
[12:30] <dragos> good
[12:31] <dragos_> 2 xchat on  pc running at the same time
[12:32] <dragos> cool
[12:33] <dragos_> ya ik
[12:34] <dragos_> dragos and dragos_ is the same user
[12:34] <dragos_> dragos_
[12:34] <dragos_> dragos
[12:34] <dragos_> dragos
[12:34] <dragos_> dragos
[12:34] <dragos_> dragos
[12:34] <dragos_> soory
[12:36] <Laney> dude
[12:42] <pitti> barry: are you tracking the "Illegal instruction (core dumped)
[12:42] <pitti> barry: in http://autopkgtest.ubuntu.com/packages/p/pytables/wily/amd64/ ?
[13:10] <barry> pitti: thanks for the pointer; hadn't seen that yet
[13:51] <seb128> cyphermox, hey, why did you subscribe sponsors to https://code.launchpad.net/~mathieu-tl/ubuntu/wily/grub2/lp1097570/+merge/260228 ? you can upload grub yourself right?
[13:53] <cyphermox> seb128: I'm not sure why it got in the list, I think it's just because I filed the merge at all
[13:53] <seb128> cyphermox, are you waiting for specific reviewers?
[13:54] <cyphermox> no, not really. let me get that off the list
[13:56] <seb128> thanks
[13:56] <seb128> @pilot out
[14:22] <doko> Mirv, remember the libllvm v5 changes when you backport new llvm versions. for 3.5 and 3.6 you have to drop these changes, for 3.7 you have to *add* something else, e.g. v4. and change the wily version to replace/conflict these
[14:26] <Mirv> doko: do you mean tjaalton?
[14:26] <Mirv> too many Timo:s
[14:26] <doko> yeah, sorry
[14:27] <doko> tjaalton, ^^^
[14:31] <tjaalton> doko: whaat?
[14:32] <tjaalton> maybe mlankhorst did the previous ones, i can't remember doing those :)
[14:33] <tjaalton> doko: 3.7 will be useful for newer mesa and amdgpu driver though
[14:33] <tjaalton> you mean backports to trusty?
[14:36] <doko> tjaalton, yes, you must not use the same library name as used in wily-proposed
[14:37] <pitti> doko: does that then mean that we need to add another Conflicts:/Replaces: to the wily version?
[14:37] <tjaalton> doko: mesa in proposed?
[14:37] <tjaalton> i'm just confused :)
[14:37] <doko> pitti, for libllvm3.7? maybe
[14:42] <tjaalton> doko: so is there something I need to do right now?
[14:43] <doko> tjaalton, no, just remember when you backport. I'll add the Conflicts/Replaces for libllvm3.7 (libllvm3.7v4), so you should use exactly that name for your backports
[14:43] <tjaalton> doko: ah, ok
[14:50] <pitti> apw: ah, kicad is running into the same boost error; so waiting on your fix
[14:52] <apw> pitti, yeah waiting on some test builds in my boost PPA, seems feel is very large
[15:01] <mdeslaur> cjwatson: I am going to steal your net-snmp merge
[15:49] <mterry> doko, arg, you were working on pinba-engine-mysql at the same time I was.  put your name on it  :)
[15:49] <mterry> doko, but awesome, good work  :)
[15:50] <doko> mterry, sorry, and now looking at qwt
[15:50] <doko> this pad is always timing out ...
[15:50] <mterry> doko, I know, right
[15:56] <barry> pitti: i can't get pytables to core dump locally :/  all dep-8 tests pass just fine here
[15:57] <doko> seb128, was it intended to build gnome-bluetooth without the new bluez?
[15:59] <seb128> doko, you mean? bluez was uploaded
[16:00] <seb128> doko, or you mean build order? in which case yes, gnome-bluetooth doesn't build-depends on bluez, it uses its dbus api, so it's runtime depends
[16:00] <doko> ok
[16:08] <doko> zyga, still there?
[16:08] <zyga> doko: yes
[16:08] <zyga> doko: want to know about the plainbox FTBFS issue?
[16:09] <doko> zyga, not to know, just a fix =)
[16:10] <zyga> doko: a quick fix is to disable tess, I tracked that down to about a dozen silent test failures on earlier pythons, I started fixing them but I'll need one more day
[16:11] <doko> ok, then I'll leave that
[16:15] <mterry> doko, I'm looking at kdegraphics-mobipocket, which is now missing one of its symbols and dpkg-gensymbols errors out during build.  I see for okular, you just uploaded a new version with a symbols file that had the #MISSING lines in it.  How do I test whether any rdeps were using the specific symbol that is missing in my kdegraphics case before uploading it with an updated symbols file?
[16:25]  * doko hides (already uploaded)
[16:27] <doko> mterry, these are destructor symbols, which GCC 5 doesn't emit anymore. In general, you can ignore these (that's what the kde symbols tool is doing).
[16:28] <mterry> doko, OK great.  Will upload with modified symbols file then
[16:29] <doko> mterry, I already did :-/
[16:29] <mterry> doko, oh I see, that's why you hid  ;)
[16:29] <mterry> doko, thanks  :)
[16:29] <mterry> doko, you monster
[16:30]  * mterry goes on lunch break, after successfully fixing two gcc5 failures  ;)
[16:37] <Laney> Riddell: ScottK: Do you know if opengtl & libqtgtl are still relevant?
[16:37] <Laney> FTBFS, seem to have been removed from fedora saying they are obsolete
[16:37] <Riddell> hmm, krita isn't it?  let me look
[16:38] <Laney> don't see any rdeps
[16:39] <Laney> if you confirm then would you please remove them from wily+wily-proposed? :)
[16:41] <Riddell> Laney: you could be right, asking upstream
[16:42] <doko> Laney, Riddell: https://bugs.launchpad.net/ubuntu/+source/opengtl/+bug/1483000
[16:42] <Laney> thx
[16:42] <Laney> we're so four days behind
[16:43] <Riddell> doko: that should say 15.10?
[16:43] <doko> yeah
[16:48] <seb128> kirkland, hey, is there any chance you could review https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940?  there is a patch waiting for review since january 1st...
[16:49] <kirkland> seb128: sure, looking now...
[16:50] <kirkland> seb128: ugh, backslashes in user names?
[16:50] <seb128> kirkland, thanks
[16:51] <seb128> that's how AD works apparently
[16:51] <seb128> don't ask me, I know little about that ;-)
[16:51] <kirkland> seb128: hmm, I'd be curious to have pitti's and slangasek's take on the pam parts of this patch
[16:52] <seb128> slangasek, pitti, ^ (https://launchpadlibrarian.net/193837670/45_44.diff)
[16:52] <kirkland> pitti: slangasek: there's a patch posted on Launchpad for ecryptfs, on this bug: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940?
[16:52] <kirkland> pitti: slangasek: which adds support to ecryptfs, to allow for backslashes and dollar signs in user names
[16:52] <kirkland> pitti: slangasek: for active directory and samba support
[16:53] <kirkland> pitti: slangasek: that sounds scary to me
[16:55] <kirkland> seb128: okay, marked triaged/low, asked for comments from slangasek, pitti, and tyhicks
[16:55] <kirkland> seb128: my initial inclination is pretty hesitant
[16:55] <kirkland> seb128: I also have no environment (active directory) where I could test this
[16:55]  * jdstrand notes tyler is on holiday until tuesday
[16:56] <kirkland> jdstrand: thanks
[16:57] <seb128> kirkland, ok, thanks, at least the submitter has some activity (we should maybe also unsubscribe sponsors if that's too technical for ubuntu sponsoring and should be let to the ecryptfs team or something
[16:57] <kirkland> seb128: ack
[16:57] <kirkland> seb128: yes, agreed, that's not something that a general ubuntu sponsor should upload, as there are potentially serious security implications
[16:58] <barry> slangasek: i'm confused.  http://people.canonical.com/~ubuntu-archive/transitions/html/python3.4-5.html has gcc-python-plugin failing for all archs, but if you look at the build logs, everything is built just fine.  it's not the page being out of date, so what's going on?
[16:59] <barry> ditto python-aoihttp
[17:00] <Laney> barry: Do they match the 'bad' line?
[17:03] <barry> Laney: hmm.  i think it doesn't bug i'm not positive i'm reading the bad line correctly
[17:04] <Laney> laney@nightingale> apt-cache show python3-aiohttp | grep Depends                                                                                                                                ~/temp
[17:04] <Laney> Depends: python3 (<< 3.5), python3 (>= 3.4~), python3-chardet, libc6 (>= 2.4)
[17:04] <Laney> seems to match bad
[17:05] <barry> Laney: hmm, i guess so.  okay, thanks, probably a no-change rebuild would fix that
[17:05] <Laney> that's usually what the transition tracker is telling you to do
[17:05] <Laney> in the best case, anyway. :P
[17:05] <barry> ;)
[17:06] <barry> Laney: thanks
[17:06] <slangasek> barry: wasn't python-aiohttp on the list of ftbfs packages?
[17:07] <barry> slangasek: i think i was just misinterpreting the page.  i'll investigate
[17:08] <slangasek> barry: confirmed; python-aiohttp was ftbfs in your ppa
[17:08] <barry> yep
[17:19] <slangasek> kirkland, seb128: backslashes and dollarsigns are certainly valid in usernames... but why is that bundled with a new pam config?  that doesn't look to me like something we should add to the package, there are already separate modules for dynamically creating home directories and his auto-enable-ecryptfs script encodes a lot of policy
[17:20] <kirkland> slangasek: thanks, agreed;  can you add a comment to that effect to the bug?
[17:20] <slangasek> yes
[17:23] <slangasek> kirkland: also they have a setup script that's passing the user's password on the commandline...
[17:33] <jdstrand> pitti: hey, I'm trying to run unmodified click-apparmor autopkgtests in a wily chroot using only packages from the archive (on a vivid host)
[17:34] <jdstrand> pitti: and I am seeing this: http://paste.ubuntu.com/12072798/
[17:34] <jdstrand> pitti: the autopkgtest is creating a click file and trying to install it, but that is failing with a sandbox failure
[17:34] <jdstrand> pitti: have you seen that before? if not, how would I go about resolving this?
[17:38] <jdstrand> jibel: ^
[18:00] <jdstrand> pitti, jibel: ginore me for the moment-- this might be a symptom of a bad chroot
[18:05] <jdstrand> hmm, no
[18:06]  * jdstrand scratches head
[18:33] <doko> Laney, slangasek: why is http://people.canonical.com/~ubuntu-archive/transitions/html/proj.html  zygrib still shown there, when it's not in the release pocket?
[18:34] <slangasek> doko: because the tracker doesn't care about -proposed vs. release, it cares about "newest binary".
[18:35] <doko> ahh, ok
[18:36] <slangasek> doko: this does tie into the discussion from last night, that if we're removing a package from wily we should leave it source-only in wily-proposed instead of leaving stale binaries there; I'll delete these now since they date back to an earlier transition failure
[18:37] <jdstrand> pitti, jibel: yes, at a loss. I'm still poking, but I could use some help with: Sandbox failure: 'click install' not permitted to write-open '/dev/pts/25'
[18:39] <slangasek> doko: removed the old package; this at least takes zygrib off the "urgent fixme" list in favor of the "we need to clean up -proposed" list
[19:10] <doko> apw, are you still looking at kicad?
[19:15] <apw> doko, i am looking at feel, which nearly built before the netowkr outage bust the builds ... pitti tells me kicad has the same issue, if so i'll confirm that in my boost ppa
[19:16] <doko> ta
[19:26]  * doko welcomes slangasek to the club of empty library package uploaders ;p
[19:29] <infinity> doko: But, was it libgcc?
[19:29] <infinity> doko: Cause I think the only person who could top that would be me shipping a libc6 with no libc.
[19:29] <slangasek> doko: was it d-shlibs?
[19:29] <slangasek> cuz d-shlibs
[19:33] <jdstrand> pitti, jibel: I filed bug #1484661
[19:34] <doko> slangasek, just saw mterry's changelog about bobcat
[19:35] <mterry> it's easy to do  :)
[19:41] <slangasek> doko, mterry: ah, lovely.  yes, the batch script didn't catch that case I'm afraid
[19:41] <slangasek> er though it should have
[19:41] <slangasek> sed -i -e"s/\([ |,=/]\)$oldpkg\([ |,:]\|$\)/\1$newpkg\2/g" debian/rules
[19:41] <slangasek> must've been an upload from an early revision of the script
[19:41] <slangasek> oh of course it was because alphabet
[19:41] <slangasek> sorry :/
[19:57] <bdmurray> seb128: I sorted out the ubuntu-release-upgrader pep8 issues, thanks
[20:00] <doko> which -dev package could have dropped dependencies on some multimedia packages such that asterisk ftbfs?
[20:01] <seb128> bdmurray, thanks!
[20:25] <doko> barry, https://bugs.launchpad.net/ubuntu/+source/ubuntu-sso-client/+bug/1484680   not sure if others will pick that up
[20:27] <barry> doko: ack.  looks shallow from first glance
[20:46] <doko> found the first ICE after changing the default ...
[21:07] <seb128> could somebody overwrite/retry the buggy bootest that makes the bluez update not considered?
[21:26] <doko> mterry, there seems to be a new boost.m4 somewhere which fixes this. didn't find the master source yet
[21:26] <mterry> doko, oh yeah?  thanks for fixing that in another package, I would never have figured that out on my own  :)
[21:27] <doko> d-shlibs should die
[21:29] <mterry> doko, I'd never seen it before.  Took me a bit to figure out why I had an empty package
[21:30] <mterry> doko, reading debdiffs for idle fun?  :)
[21:30] <doko> mterry, no, it was the -P in the changelog which spotted my interest =)
[21:31] <mterry> doko, beyond reading the man page for cpp, I wasn't entirely clear why boost suddenly started dying without -P
[21:31] <mterry> obviously linemarkers bugged it out
[21:31] <mterry> Just a weird change to happen
[21:33] <infinity> seb128: It's failing its own autopkgtest as well, that seems more dire?
[21:34] <seb128> infinity, hum, right, i'm going to look at that tomorrw, thanks for pointing it out ;-)
[21:39] <mterry> Can I get a NEW for libmems's v5 transition?
[21:39]  * mterry wants to push button on progressivemauve's rebuild before heading out
[21:40] <mterry> infinity, ^ ?
[21:45] <doko> slangasek, does your script fixes this now? http://launchpadlibrarian.net/214411099/libmsn_4.2.1-0ubuntu3_4.2.1-0ubuntu4.diff.gz
[21:47] <infinity> mterry: Still building on armhf, patience. :P
[21:47] <mterry> infinity, but I want it now!!!
[21:48] <mterry> infinity, fair enough, I have to jet though, will have to settle for pushing button in the morning  :)
[21:50] <infinity> mterry: Packaging looks good though, and so do the built binaries, will accept as soon as it's built.
[22:01] <slangasek> doko: no; and also your patch does not fix it...
[22:01] <doko> ?
[22:02] <slangasek> doko: you have the right package but the wrong -V argument ;)
[22:02] <doko> slangasek, hmm, at least kopete builds now
[22:02] <infinity> doko: You just made packages depend on the wrong package, unless you have a versioned provides.
[22:04] <doko> ahh, I see
[22:04] <infinity> And a versioned provides would completely break the point of renaming the library package, so I hope you don't have one.
[22:04] <doko> killing the kopete builds
[22:06] <doko> still wondering why the command succeeds with an unknown package
[22:08] <infinity> doko: The string you pass to -V isn't (and shouldn't be) validated, as you can have a package-foo-alt whose shlibs declares a dep on package-foo, or whatever.
[22:09] <infinity> doko: It's one of those 'enough rope' sort of interfaces.
[22:09] <doko> no, but slangasek's original upload called with -p <package not in control file>
[22:10] <infinity> Oh.  That one should have broken, depending on how debhelper stuff was called, yeah. ;)
[22:33] <slangasek> doko: yes, the original upload (from my original script) was buggy, the new upload was also buggy, but it seems we're converging now.  The latest version of my script still wouldn't DTRT here but the Debian release team have enough hints in that thread that they can fix it up for their own usage to address these bugs - I'm not futzing with it in Ubuntu anymore because the damage is done and anythin
[22:33] <slangasek> g that's broken is going to need manual attention now
[22:39] <doko> slangasek, which thread?
[22:42] <slangasek> doko: debian-devel
[22:45] <doko> which... don't ;-P
[23:29] <slangasek> so who keeps blindly retrying asterisk builds on amd64 and generating mail for me? :)
[23:32] <doko> slangasek, me. see my question on -devel/-release. anyway, afk now
[23:33] <doko> and finished the coinutils-g++5 transition by "blindly retrying"
[23:35] <slangasek> doko: I'm not seeing any question on any devel fwiw
[23:39] <doko> slangasek, hmm, maybe not sent. I was asking if some -dev package dropped dependencies on other -dev packages