[00:12] <cyphermox> doko: yes, was going to
[00:12] <cyphermox> I was never really involved in it though ;)
[00:46] <mwhudson> Setting up golang-go (2:1.5~snap~upstream201508020934gitc2db5f4ubuntu3) ...
[00:46] <mwhudson> update-alternatives: using /usr/lib/go/bin/go to provide /usr/bin/go (go) in auto mode
[00:46] <mwhudson> update-alternatives: warning: not replacing /usr/bin/go with a link
[00:46] <mwhudson> sounds bad
[00:47] <lifeless> win 31
[00:48] <infinity> mwhudson: You can't use alternatives unless all the packages particpating play along.
[00:48] <mwhudson> yeah
[00:48] <infinity> mwhudson: As in, no one can ship the actual path. :P
[00:49] <mwhudson> i'm just wondering which package isn't playing along
[00:49] <infinity> mwhudson: dpkg -S /usr/bin/go ?
[00:49] <mwhudson> infinity: on a builder? :-)
[00:49] <infinity> Well, install all the build-deps, then dpkg -S?
[00:49] <mwhudson> i think i know which package it must be though
[00:49] <infinity> But it's probably gccgo, or some wrapper.
[00:50] <mwhudson> nah not this time, i think it's my golang-x-tools package
[00:52] <mwhudson> yeah that's completely messed up
[02:22] <Logan> Noskcaj: you're frustrated that I did a merge for a package where I TIL and didn't realize that you had proposed a merge without asking me first? :P
[02:32] <Logan> (that was awkwardly phrased)
[04:27] <mwhudson> so my earlier hilarity was caused by a bit of rules that did approximately "cd directory; find -exec install \{} $(CURDIR)/debian/tmp/usr/bin/\{} \;"
[04:28] <mwhudson> and directory not existing
[04:28] <sarnold> owwwwwwww
[05:17] <pitti> Good morning
[05:17] <pitti> infinity: langpacks> erk, no -- still no full export on https://translations.launchpad.net/ubuntu/trusty/+language-packs
[05:17] <pitti> wgrant: ^ can you run this manually?
[05:18] <pitti> (I asked last Thursday, but it apparently fell through the cracks; shouldn't have used IRC, sorry)
[05:22] <wgrant> pitti: Sure, will get that kicked off.
[05:22] <pitti> wgrant: thanks
[05:28] <wgrant> pitti: It's running.
[05:28] <pitti> wgrant: yay; should be a handful of hours?
[05:28] <wgrant> pitti: I think so.
[05:28] <pitti> I'll check https://translations.launchpad.net/ubuntu/trusty/+language-packs every hour or so and then build new trusty langpacks
[05:30] <pitti> infinity: oops, this Thu already? do you still actually want the new packs?
[05:50] <Guest28692> Hi..
[05:50] <Guest28692> I was trying to join the ubuntu development team.. and I went to the link https://wiki.ubuntu.com/BeginnersTeam/Membership
[05:51] <Guest28692> It says that this page is deprecated it gave a link to https://lists.ubuntu.com/archives/ubuntu-beginners/2013-August/002541.html
[05:52] <Guest28692> and this link is broken..
[05:53] <Guest28692> am I going to the right link??
[05:54] <sarnold> Guest28692: looks like it, archive.org has a copy: https://web.archive.org/web/20140817091812/https://lists.ubuntu.com/archives/ubuntu-beginners/2013-August/002541.html
[05:56] <Guest28692> oh!!
[05:56] <Guest28692> it says the community is dead..
[05:57] <Guest28692> what should I do then??
[05:57] <Guest28692> It says it should check ##ubt-survivors
[05:57] <sarnold> it dpends on what you want to work on :)
[05:58] <Guest28692> I want start with testing packages..
[05:58] <Noskcaj> Logan, well now you say it like that...
[05:59] <Guest28692> I am C++ developer .. socket programming , system prgramming..
[05:59] <Guest28692> etc..
[06:00] <sarnold> Guest28692: aha :) cool
[06:02] <Guest28692> I am joining the ##ubt-survivors chat room and let's see what comes out of it
[06:02] <sarnold> Guest28692: there's a few different types of tests, tests during package builds (usually just upstream's tests), autopkgtest (which are more distribution-oriented..), doing stable release update tests to get updated packages into the archives...
[06:02] <sarnold> Guest28692: check this out http://packaging.ubuntu.com/html/auto-pkg-test.html
[06:02] <sarnold> Guest28692: and this https://wiki.ubuntu.com/StableReleaseUpdates
[06:03] <Guest28692> Hmm..
[06:09] <Guest28692> sarnold: One of my mentors suggested me to go this way.. what would you suggest me to do.. to have a head start..
[06:09] <infinity> pitti: Might be a bit late now.  I was expecting them Friday, so we could spot-check over the weekend.
[06:10] <sarnold> Guest28692: do whatever is fun enough that you'll want to work on it, and challenging enough so that you still enjoy it in a few months or years..
[06:10] <pitti> infinity: ok; if you don't have troubles with overflown images, it's not such a big deal -- we can SRU them after .2
[06:10] <infinity> pitti: But you know langpacks better than I.  If we can test them in any meaningful way before I inevitably have to respin images in a day or two, I'm all for fresh strings.  If not, let's not risk breaking the world.
[06:11] <infinity> pitti: Image size isn't really a concern, it's just nice to have better installer coverage.
[06:11] <infinity> pitti: Though, I guess that updates from the interwebs anyway if you're online when isntalling.
[06:11] <pitti> infinity: we can't test them automatically aside from me looking at binary debdiff and string diffs (but that won't be meaningful for most languages)
[06:11] <pitti> we have some manual test plan, but that'll get too tight as it depends on lots of community help
[06:12] <infinity> pitti: Kay, let's skip it.  I'd rather a few out of date strings than a catastrophe due to lack of timely testing.
[06:12] <pitti> ack
[06:12] <pitti> sorry for the bad timing
[06:12] <infinity> pitti: Life goes on.
[06:13] <infinity> pitti: I will quit ~we-love-pitti for two days before I rejoin.
[06:13]  * pitti breaks out in tears
[06:13] <infinity> Oh man, too much QA + dyslexia for tonight's hilarious misreading.
[06:13] <infinity> I saw "* pitti breaks out in tests"
[06:13] <pitti> oh, I'm breaking these too :)
[06:14] <sarnold> poor poor infinity
[06:14]  * pitti is currently rolling out britney, take II
[06:14] <pitti> this time with better preparation
[06:24] <infinity> tjaalton: This bug is all over the map, do you have any input (hah, input!) on the matter? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics-lts-vivid/+bug/1481104
[06:46]  * pitti drops the "Would be considered, but pitti disabled promotion for one run" local hack from britney.py and dives in fully
[07:11] <dholbach> good morning
[07:54] <tjaalton> infinity: can't check before my evening..
[07:55] <tjaalton> sounds weird though
[07:55] <tjaalton> no xserver log to show if the driver is loaded
[07:56] <tjaalton> and it should fall back to evdev
[08:06] <Laney> pitti: is this the big switch?
[08:06] <pitti> Laney: yes, it was
[08:06] <Laney> \o/!
[08:06] <pitti> and seems I didn't flunk it this time
[08:07] <Laney> I'll miss you, d-jenkins.ubuntu-ci
[08:07] <pitti> it still runs boottests :)
[08:07] <Laney> yeesh, those
[08:07] <pitti> we need to find someone who owns them these days and make them install the new worker
[08:08] <Laney> try f_ginther
[08:09] <Laney> They also need some improvements like unpacking/upgrading/repacking the image instead of trying to use apt on it directly
[08:11] <cjwatson> ari-tczew: not useful to have them on mom; they're in auto-sync output
[08:17] <ari-tczew> cjwatson: I had a case, there was a package with versioning -1fakesync1 and Debian released -2. In this case we don't know that package needs to be fakesynced. (someone just subscribed me to the bug report on LP)
[08:17]  * ari-tczew needs to go out
[08:32] <doko> seb128, Laney: is SweetShark available?
[08:32] <seb128> doko, he should be yes
[08:32] <seb128> having libreoffice/gcc5 issues?
[08:33] <Laney> don't see him on IRC
[08:33] <doko> yes, libcmis test failures
[08:35] <seb128> he might not be up yet
[08:35] <seb128> or there is an IRC split...
[08:42] <ochosi> doko: now he's around ;)
[08:44] <doko> ochosi, where?
[08:44] <ochosi> at least in #u-desktop
[09:10]  * doko thinks slangasek would make a perfect fit as a debian-med, debian-science and debian-chem maintainer =)
[09:11] <cjwatson> those sound like fighting words :-)
[09:14] <Laney> bdmurray: seems http://reqorts.qa.ubuntu.com/reports/rls-mgr/?C=M;O=D has stopped updating
[09:14] <Laney> (is that yours?)
[09:24] <Daviey> Laney / bdmurray: Seems that machine was upgraded to Trusty, as it broke one of the ubuntu-server reports that used a changed interface of python-apt. Could be related.
[09:26] <Laney> Daviey: Ah, good clue
[09:56] <Laney> ha
[09:56] <Laney> was just about to run slangasek's script, noticed dput at the end
[10:27] <pitti> Laney: I dia'ed together an initial overview on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure ; I'll flesh this out with description of every component in the next days
[10:31] <Laney> pitti: nice, thanks!
[10:43] <Laney> seb128: any tips before I start trying to upload renames?
[10:43]  * Laney has a big directory of source packages now
[10:43] <Laney> I guess test build, manually check the diff
[10:43] <Laney> but anything special about ordering?
[10:44] <Laney> or doko ^
[10:44] <doko> Laney, I think slangasek did test builds before upload
[10:45] <Laney> right
[10:45] <Laney> I'm just wondering if there is anything else I need to be aware of
[10:46]  * Laney wants a "build these packages in the cloud" script
[10:46] <Laney> submit request, go away, come back to lovely emails and SSHable instances for failure cases
[10:47] <Odd_Bloke> I've just emailed ubuntu-devel with a request for help validating an SRU; if someone could ACK it, it'd be appreciated.
[10:48] <Laney> Odd_Bloke: Approved, & note that you are allowed to self-verify SRUs
[10:49] <Odd_Bloke> Laney: Yeah, we don't have access to an appropriate environment :(; the person who helped us validate the upstream cloud-init fix has disappeared.
[10:50] <Odd_Bloke> Laney: (And thank you!)
[10:58] <Laney> icu seems to be stuck in haskhell
[11:06] <pitti> apw: wow, that initramfs-tools delta reads scary :)
[11:07] <Laney> that's a nice merge!
[11:09] <pitti> I'm quite some some delta is unnecessary now, but scary as this was let's land this first :)
[11:10] <pitti> apw: ah, so 0.119 runs fsck on the root fs by itself already, and thus /run/initramfs/fsck-root exists, and thus systemd-fsck-root.service doesn't get run
[11:10] <pitti> that's actually intended
[11:10] <pitti> so it seems the autopkgtest needs to be adjusted
[11:11] <doko> jamespage, python3-linecache2 - backports of the linecache module - Python 3.x
[11:11] <doko> seriously?
[11:11] <doko> same for python3-traceback
[11:29] <doko> d-shlibmove(1):
[11:29] <doko>        --c102
[11:29] <doko>               Add c102 suffix to package names, for C++ ABI transition.
[11:29] <doko>               Added in version 0.8
[11:29] <doko>        --ldbl
[11:29] <doko>               Add dbl suffix to package names.
[11:29] <doko>               Added in version 0.35
[11:29] <doko> \o/
[11:32] <doko> die, die, die ...
[11:34] <seb128> Laney, not really no
[11:36] <Laney> ok
[11:36] <Laney> I have a big sbuild making my computer cry atm
[11:37] <seb128> is there many renames remaning?
[11:38] <Laney> I have 86 dscs here
[11:38] <Laney> the script skipped packages with .symbols files
[11:38] <Laney> http://paste.ubuntu.com/11999484/
[11:40] <seb128> crazyness
[11:41] <Laney> those are ones people could help with
[11:41] <seb128> k
[11:41] <Laney> flac was just done in Debian
[11:41] <Laney> I see doko pinging about some others in #debian-ftp
[11:42] <Laney> doko: got a list so I can avoid uploading those?
[11:42] <seb128> I keep a note about that, but still fighting device issues and I want to deal with bluez5 this week
[11:42] <Laney> ok
[11:42] <doko> Laney, sorry, don't have one
[11:44] <doko> Laney, slangasek: skip llvm-toolchain-snapshot, we don't care, and it's -proposed only. qtwebkit-opensource-src and qttools-opensource-src were already done by Mirv. not sure about qt-gstreamer
[11:44] <doko> kdepimlibs is hopefully handled by Riddell / Kubuntu
[11:46]  * Mirv is not familiar with qt-gstreamer, not used by phone either
[11:46] <Laney> doko: edit http://pad.ubuntu.com/gcc-5-transition ?
[11:46] <Laney> delete/mark those lines or something
[11:48] <Laney> http://paste.ubuntu.com/11999517/ <- that's what the script gave me to upload
[11:50] <doko> Laney, projectm is already in experimental
[11:50] <Laney> ok thanks, deleting that one
[11:50] <pitti> apw: hm, new initramfs-tools doesn't provide the plymouth-y fsck integration we used to have
[11:50] <doko> maybe check the others too
[11:50] <Noskcaj> doko, I didn't get to pyicu today, will get it first thing tomorrow. It is just a version bump though AFAIK
[11:51] <pitti> apw: difficult thing that -- OTOH this is a rather obnoxiously difficult thing to do especially in initramfs, for an ever-waning benefit
[11:52] <pitti> apw: ext stopped doing regular fscks long ago (on new installs), and xfs, btrfs etc. don't do these either; so the more interesting question is what happens if the check fails
[11:52] <Laney> doko: what can I check? Depends "libstdc++6 (>= 5"?
[11:52]  * Laney will grep-dctrl
[11:52] <pitti> apw: we still need to keep the userspace fsck stuff for non-root partitions, but it seems with the "check root fs from initramfs" approahc we need to duplicate it?
[11:53] <Laney> bah, and NEW too
[11:53] <doko> Laney, maybe just if the package builds a binary ending with v5 ...
[11:54] <Laney> might not catch where transitions happened anwyay
[11:55] <Laney> qpdf is the only one in NEW that I have there, /me deletes that
[11:55] <Laney> and ScottK accepted that one (thanks)
[11:56] <ScottK> Actuall it wasn't me, we had a race condition on the FTP team and someone else accepted it while I was busy filing an RC bug for missing debian/copyright stuff.
[11:58] <Laney> OK, no thanks for you then. :P
[12:00] <ricotz> doko, do you have a log of your libreoffice ftbfs?
[12:01] <doko> ricotz, still ftbfs because of not yet rebuilt b-d's.  Ask Sweet5hark on #ubuntu-desktop, this guy doesn't want to cooperate here on this channel :-/
[12:02] <doko> ricotz, and I'm told that libcmis tests are failing, so if you want to have something for fixing ...
[12:02] <ricotz> doko, i pushed a rebuild to my ppa
[12:02] <ricotz> https://launchpad.net/~ricotz/+archive/ubuntu/ppa/+build/7756288
[12:02] <doko> ricotz, waste of resources ...
[12:03] <ricotz> doko, did you changed the packaging?
[12:03] <doko> ricotz, -> Sweet5hark
[12:03] <pitti> apw: ah, debian bug 783291 causes the "intra-OS" fsck to run again, that's why the test fails there
[12:03] <ricotz> doko, I am asking you, so you did a no-change rebuild?
[12:04] <ricotz> of 1:4.4.4~rc3-0ubuntu1
[12:04] <ricotz> (fyi the ppa build is 4.4.5~rc2)
[12:05] <doko> ricotz, no, I did not, because I trust the person telling me that b-d's aren't yet rebuilt
[12:05] <ricotz> doko, ok
[12:10] <jamespage> doko, this got discussed on the debian python ML - https://lists.debian.org/debian-python/2015/07/msg00006.html
[12:12] <jamespage> doko, I'm not sure I can read a consensus decision on whether the python3 versions of backports have a place or not; but as they use a different namespace, there are come compelling arguments both ways :-)
[12:13] <doko> jamespage, sure they have a different namespace, but in the past this was handled conditionally in the using code
[12:20] <apw> pitti, ahh ok, is there a fix on that one already ?
[12:20] <apw> pitti, and thanks
[12:21] <apw> pitti, ahh yes, there is a proposed work-around in there which i'll give a go
[12:25] <Laney> doko: http://paste.ubuntu.com/11999715/ <- should be packages needing rebuild/transition that are fixed in debian
[12:26] <doko> infinity, were you working on shellcheck?
[12:26] <Laney> i.e. sync/merge these
[12:27] <doko> Laney, ahh, csound is done
[12:27] <doko> and see slangasek rants^Bcomments on hdf5
[12:29] <Laney> heh
[12:32] <Laney> ahh, we don't have Source: for all binaries in our Packages files
[12:33] <cjwatson> Source defaults to Package if missing
[12:33] <Laney> Yeah, need to tweak the logic to know that
[12:34] <Laney> Know an easy way to do that with grep-dctrl?
[12:34] <Laney> or does grep-dctrl do it already?
[12:34] <Laney> -S
[12:34] <doko> cjwatson, shellcheck is maintained by the Debian Haskell group =) now wanted by d-shlibs and dh-exec
[12:35] <doko> do you want to write a MIR?
[12:35] <cjwatson> doko: no
[12:35] <doko> i feared that
[12:35] <cjwatson> doko: it's not my problem if somebody starts pulling it in :)
[12:35] <cjwatson> Laney: as you say
[12:36] <doko> ohh, and written in haskell, so I'll disable running the tests for these
[12:36] <Laney> no, that's for selecting input fields, not output
[12:36] <cjwatson> doko: disable tests for which packages?
[12:37] <doko> d-shlibs and dh-exec
[12:37] <cjwatson> right, that makes sense
[12:37] <cjwatson> Laney: -sSource:Package
[12:38] <cjwatson> "A field specification can contain a colon.  In such a case, the part up to the colon is taken as the name of the field to be shown, and the part after the colon is taken as the name of the field whose content is to be used if the field to be shown is empty."
[12:42] <Laney> Yeah, I think this works
[12:44] <doko> infinity, ohh, no that was bats
[13:03] <ricotz> I assume if a rebuild generates a hard-dep on "libstdc++6 (>= 5.2)" it requires a package-rename
[13:04] <ricotz> Laney, if you like you can add libixion
[13:06] <Laney> looks to be done in debian
[13:12] <sbeattie> pitti: do you know what's up with https://jenkins.qa.ubuntu.com/job/wily-boottest-apparmor/lastBuild/artifact/results/log/*view*/ ? Looks like a test infrastructure issue to me, can you re-run?
[13:12] <pitti> sbeattie: yes, I can re-run; besides keep hitting the retry button I don't know much about these boottests, I'm afraid
[13:13] <pitti> sbeattie: I'm working on the systemd test regression BTW
[13:13] <pitti> sbeattie: if it's urgent, I can ignore that and let apparmor propagate
[13:14] <pitti> it's the new initramfs-tools which breaks it, not apparmor
[13:14] <sbeattie> not urgent, just wanting to know if it's a legit failure.
[13:14] <pitti> sbeattie: the bootest just looks like a glitch; let's see if it works now
[13:16] <sbeattie> pitti: okay, thanks.
[13:17] <doko> kenvandine, just curious, why were the no-change rebuilds for platform-api necessary?
[13:17] <kenvandine> doko, it had a depends on libubuntu-location-service2
[13:18] <kenvandine> it was built before the transition to libubuntu-location-service3
[13:18] <kenvandine> doko, i think that's the culprit causing stuff to get removed in the boottests
[13:19] <doko> kenvandine, yes, but the problem that these two packages have direct cyclic build-dependency
[13:19] <kenvandine> doko, oh... that's not cool
[13:19] <doko> told tvoss about it
[13:20] <tvoss> doko, yup, wasn't aware that this is causing problems like this, sorry
[13:20] <tvoss> kenvandine, so does a rebuild of platform-api fix the issue?
[13:20] <kenvandine> i thought it would fix the depends issue
[13:20] <kenvandine> at least i thought it was simple :)
[13:22] <pitti> apw: fix for the "touch not found" bug? yes, it's attached to that bug and very simple; doesn't affect our cloud images as (I suppose) they have busybox, or something else which gets "/bin/touch" into the initramfs
[13:22] <pitti> apw: anyway, as far as the systemd-fsckd test goes, I'll just skip it iff /run/initramfs/fsck-root exists
[13:30] <pitti> sbeattie, apw: adjusted systemd fsckd test uploaded, so autopkgtest should succeed again
[13:31] <apw> pitti, ok, i'll get that fix applied as well when i am done fixing casper
[13:31] <pitti> apw: it's not urgent raelly
[13:31] <pitti> apw: I think the more "interesting" discussion is what we want to do with fsck and plymouht
[13:32] <apw> pitti, yeah, surely it is all perfect after all systemd is doing it now ...
[13:32] <pitti> apw: ?
[13:32] <pitti> (that's the point -- with current initramfs systemd can't do it any more :) )
[13:40] <pitti> sbeattie: that helped, re-run succeeded
[13:41] <ricotz> doko, https://paste.debian.net/plain/289042
[13:45] <apw> pitti, yeah, ok, so ... so we have a plan, or do we need to make one up
[13:45] <pitti> apw: I don't have a plan/good idea right now
[13:45] <pitti> apw: technically, fsck'ing the root fs in initramfs is a much more sensible thing to do than checking it from within an already mounted (although r/o) file system
[13:45] <pitti> but of course the initramfs env is very limited, so you can't do much fancy stuff
[13:46] <apw> but one needs a lot of heavy things hten, yeah that
[13:46] <pitti> unless you have cryptsetup or similar, we don't currently even have plymouht in the initramfs
[13:46] <pitti> I wouldn't mind putting it always there
[13:46] <pitti> but all the fsck <-> initramfs plumbing isn't there
[13:46] <doko> ricotz, thanks, uploaded
[13:46] <pitti> Debian never bothered about it, but apparently we do (or at least did) wrt. pretty boot
[13:47]  * pitti nods to didrocks
[13:50] <doko> ricotz, hmm, shlibs file was wrong. fixed
[13:52] <ricotz> doko, ah sorry
[13:54] <Laney> doko: why no bug for movit?
[13:56] <doko> Laney, forgot it? not sure, why I forgot some ...
[13:57] <Laney> dunno
[13:57] <Laney> and why no log for libcmis indicating that it needed fixing? :)
[13:58] <Laney> about to upload first batch anyway
[14:04] <doko> maybe it failed to build at this time?
[14:05] <Laney> just worried about missing things
[14:50] <bdmurray> Laney: I'm aware of the issue and it has to do with python-launchlib authorization tokens.
[14:54] <dannf> hallyn: i told infinity i'd look at an SRU'ing the qemu-kvm support for arm64/ppc64el/etc back to trusty (LP: #1389897), and i finally got around to preparing one. wanted to get your opinion it...
[15:01] <Laney> bdmurray: ack!
[15:05] <hallyn> dannf: will take a look, thx
[15:05] <hallyn> guess infinity gave up on me :)
[15:06] <dannf> hallyn: oh, heh. want me to push my patch and/or packages somewhere? it's just a cherry pick of the change in vivid
[15:11] <ricotz> Laney, was libwpg on your list?
[15:13] <Laney> ricotz: see http://pad.ubuntu.com/gcc-5-transition (no)
[15:13] <Laney> and that is because https://launchpad.net/ubuntu/+source/libwps/0.4.0-2ubuntu1
[15:15] <ricotz> Laney, alright
[15:15] <slangasek> doko, Laney: test builds before upload> hahano.  The script checks for symbols files, everything else is uploading and letting the builders sort it out.  For that, the build failure rate is fairly low ;P
[15:15] <bdmurray> cjwatson: I've forgotten how to create a token for launchpadlib that doesn't use "DESKTOP_INTEGRATION". Do you know?
[15:16] <Laney> slangasek: I feel overly worried about hitting dput ...
[15:16] <slangasek> Laney: the worst thing that can happen is that you're TIL
[15:17] <Laney> getting close to doing it
[15:19] <slangasek> Laney: do you have the last blacklist I posted on #-release?
[15:19] <Laney> slangasek: yep, and I added some more that the script cried about
[15:20] <slangasek> Laney: ok.  I should also post an updated version of the script
[15:20] <Laney> http://paste.ubuntu.com/12000702/
[15:20] <Laney> I've wrangled it a bit anyway
[15:21] <slangasek> well, http://paste.ubuntu.com/12000707/ regardless - I think the only change missing vs. the last I posted was handling the case of an unknown source package
[15:22]  * Laney nods
[15:22] <Laney> that's why I added those blacklist entries
[15:27] <hallyn> dannf: sure, either post a debdiff or whatever.  or if you're happy with it, i trust you, just push - up to you
[15:27] <dannf> hallyn: posted a debdiff
[15:28] <dannf> hallyn: i didn't see any regression fixes since the initial upload (though i did see some consolidation/rework) - that sound right to you?
[15:36] <hallyn> not understanding what you mean
[15:37] <hallyn> why did you remov ekvm-ipxe-precise from Suggests?
[15:37] <hallyn> doesn't exist on the other arches?
[15:38] <hallyn> oh, weird, that's only in contrl, not control-in
[15:40] <dannf> hallyn: ah - prepared the source package before i built it, probably should prepare a post-build one
[15:41] <hallyn> hm, apparently that debian/control has been out of date wrt the control-in for a bit;  i dont' see ipxe listd at all in control-in
[15:41] <dannf> hallyn: what i meant by my question was, do you recall any fixes that had to go in after the first patch you adapted from mwhudson/etc
[15:42] <hallyn> hm, yeah
[15:42]  * hallyn checks
[15:42] <dannf> i know that the patch went through iterations, but didn't notice any changes after it got uploaded
[15:42] <dannf> well, bugfix changes
[15:43] <hallyn> dannf: yeah kvm.powerpc can't use awk
[15:43] <hallyn> see 1:2.2+dfsg-5expubuntu4
[15:43] <dannf> ah, ok
[15:46] <hallyn> man there were a lot of uploads to vivid
[15:47] <hallyn> dannf: now, do you *not* need to also port init scripts to load a module at boot?
[15:47] <hallyn> no, we only need that for x86 for precise + cloud-archive, which doesn't make sense for ppc
[15:48] <dannf> it's not needed for arm64 - kvm can't be a module there
[15:48] <dannf> i dont' remember armhf - i think the same thing, but i'll doublecheck
[15:50] <hallyn> i don't htink anyone's gonna care there
[15:50] <hallyn> i wouldn't worry about it.  just remove awk from the powerpc kvm script, then all looks good to me - thanks!
[15:52] <pitti> doko, Laney: you use http://pad.ubuntu.com/gcc-5-transition with attaching your name to the thing your're working on? I plan to look at some FTBFSes tomorrow morning
[15:53] <Laney> pitti: yeah, I'm going to upload the chunk at the bottom
[15:53] <Laney> didn't look at any FTBFS ones yet
[15:53] <Laney> actually I did look at one which was libtool not found but I can't remember which package that was now :)
[15:54] <arges> infinity: mind if I take openldap merge
[15:54] <pitti> Laney: ack (and would you mind adding your name to the pad? lots of "unnamed")
[15:54] <pitti> Laney: you are purple?
[15:54] <Laney> I am purple and toothpaste green
[15:55] <pitti> :)
[15:55]  * pitti switches to yellow then
[15:55] <pitti> ack, 'nuff work for me to do tmw morning then
[15:56] <pitti> Laney: the symbols mangling stuff is mostly just build/patch/test rebuild, upload, i. e. just annoying, but not technically hard
[15:56] <pitti> Laney: or am I missing something tehre?
[15:56]  * pitti <- C++ n00b
[15:57] <pitti> Laney: did you already do the A-K batch? or pure coincidence that they all start with >= M?
[15:57] <kirkland> pitti: howdy!
[15:57] <kirkland> pitti: I applied and pushed your ecryptfs patches, thanks!
[15:57] <pitti> hey kirkland, how are you?
[15:57] <kirkland> pitti: I have a related question
[15:58] <pitti> kirkland: I saw your mail (and responded), thanks!
[15:58] <kirkland> pitti: well, thanks :-)
[15:58] <pitti> slangasek, kees, infinity, stgraber: TB meeting reminder
[15:59] <Laney> pitti: I would guess slangasek did those
[15:59] <Laney> and/or seb128
[15:59] <Laney> I've only done a couple but indeed I just updated the symbols file
[15:59] <Laney> and package names, etc
[15:59] <pitti> Laney: I meant in your "Test builds" section at the bottom
[16:00] <Laney> I responded to your questions in reverse order, sorry
[16:00] <pitti> Laney: oh, are these another batch of libs to rename, not just rebuilds against the renamed libs?
[16:00] <pitti> Laney: reverse order> ah, makes more sense now :)
[16:01] <Laney> and those test builds are all renames, yes
[16:01] <pitti> Laney: ah, I though all renames were in the PPA already
[16:02] <slangasek> pitti: no; no more ppa, this is all in wily-proposed
[16:02] <Laney> I don't think all the renames were ever in there
[16:02] <pitti> slangasek: right; I meant I thought we prepared *all* renames in the PPA
[16:02] <slangasek> correct, the ppa only included the phone stack renames
[16:02] <pitti> ah, ok
[16:04] <Laney> right, well, here goes debsign *_source.changes
[16:04] <kees> infinity: meeting?
[16:11] <pitti> apw, infinity: do you know what the linux_uefi thingy is about in https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text= ?
[16:11] <pitti> it seems our kernel is already way past that, can it just be rejected?
[16:12] <apw> pitti, cirtianly that is the contents of the linux-signed package, being signed with the efi key, if the in pocket version is later than that it is not clear there is any value in it, i can only assme that there was no linux-signed for that level
[16:13] <pitti> apw: yeah, we are at 4.1.0-3.3, and this one is for 4.1.0-2.2
[16:14] <apw> so i would assume the bits it is about to drop into dists would then be reaped
[16:14] <pitti> Laney: ack, so I'll watch out for a lot of binNEW tomorrow morning, to mop up what the American folks don't see any more during their day
[16:15] <Laney> pitti: there's going to be a zillion rebuilds to do too; check http://people.canonical.com/~ubuntu-archive/transitions/
[16:15] <Laney> I want to upload some haskell as a lot of icu seems to be haskellish stuff (unless cjwatson is going to?)
[16:16] <pitti> Laney: ah, thanks; added that link to the pad
[16:16] <Laney> thanks!
[16:16] <kirkland> pitti: are these patches supposed to solve the problem where people are repeatedly asked for their encrypted swap passphrase during an apt-get?
[16:17] <pitti> kirkland: not the upstream patches, but the post-install fixups I crowbared into the postinst
[16:17] <pitti> they shoudl clean up fstab/crypttab
[16:17] <pitti> but we had three different cases now, I woudln't be totally surprised (just really annoyed) if there's a fourth
[16:17] <slangasek> Laney: what's the section in the pad without a header listing packages like csound, geos, ...?
[16:18] <kirkland> pitti: hmm, can you drop me a patch for that?
[16:18] <Laney> slangasek: Things which are fixed (or at least rebuilt) in Debian but not Ubuntu
[16:18] <pitti> kirkland: it's all in wily
[16:19]  * kirkland extracts
[16:19]  * pitti waves good night
[16:19] <pitti> slangasek: ah, I would have interpreted it as the results of the above commands, i. e. stuff being transitioned in Debian?
[16:19] <kirkland> pitti: ah, https://launchpadlibrarian.net/211231394/ecryptfs-utils_107-0ubuntu1.1_107-0ubuntu3.diff.gz
[16:19] <slangasek> ah
[16:20] <pitti> kirkland: ah right, that also had an ages-old soname packaging fix
[16:20] <Laney> I saw that dok_o was pinging the FTP team to accept stuff
[16:20] <Laney> which meant that maintainers were uploading things and we shouldn't duplicate that work
[16:21] <slangasek> Laney: sure.  Any chance you could show unstable vs. experimental there?
[16:21] <pitti> i. e. ideally auto-sync will catch some of these?
[16:21]  * pitti waves good night for real
[16:22] <slangasek> Laney: I guess csound (which doko worked on yesterday) and hdf5 (which after working on the package yesterday I don't trust the maintainer's fix for) are via experimental only
[16:22] <slangasek> hdf5 is a new upstream soname in experimental-only
[16:23] <slangasek> I think I'll stick with my change for now
[16:23] <Laney> can you annotate the pad?
[16:23] <Laney> can look to split the list if that's useful
[16:26] <slangasek> done
[16:27] <Laney> haha
[16:27] <Laney> after all that I accidently uploaded the packages I knew would fail anyway :(
[16:30] <kirkland> pitti: okay, applied, now I'll do some testing
[16:42] <infinity> apw: there was a signed for -2.2, that is from the proposed->release copy.
[16:42] <infinity> apw: Which is supposed to happen without intervention, but breaks when the origin was a PPA. :/
[16:42] <apw> what a mess ;)
[16:43] <infinity> Yeah.  A bit.
[16:52] <cjwatson> bdmurray: pass a consumer_name
[16:53] <cjwatson> Laney: I was in the middle of working my way up that stack ...
[16:53] <cjwatson> having noticed that it was entangled with icu
[16:53] <Laney> well I don't want to step on your toes
[16:53] <Laney> I've just (hopefully) got agda out of the way
[16:53] <Laney> so feel free
[16:54] <cjwatson> Laney: ah, great.  I think the only direct entanglement was haskell-text-icu, which I uploaded earlier, and then it's just syncing the stack
[16:54] <Laney> [276 of 278] Compiling Agda.Interaction.InteractionTop ( src/full/Agda/Interaction/InteractionTop.hs, dist-ghc/build/Agda/Interaction/InteractionTop.o )
[16:54] <Laney> ghc: out of memory (requested 1048576 bytes)
[16:54] <Laney> oh no
[16:54] <cjwatson> Laney: it did that last version on armhf too
[16:55] <cjwatson> so that won't block anything
[16:55] <Laney> oh right
[16:55] <Laney> I thought it had built everywhere
[16:55] <Laney> nope
[16:55] <Laney> fair enough
[16:56] <cjwatson> I probably used some kind of hammer
[16:56] <Laney> I see depwait and then FTBFS
[16:57] <cjwatson> there we go, haskell-publicsuffixlist is happier now, which was the earlier failure
[16:58] <bdmurray> cjwatson: I've tried that and I still get a DESKTOP_INTEGRATION url when authorizing the token for the first time.
[16:59] <cjwatson> bdmurray: hm, you might need a credentials store
[16:59] <cjwatson> I'm not very familiar with this corner
[16:59] <ricotz> doko, jfyi https://launchpad.net/~ricotz/+archive/ubuntu/ppa/+sourcepub/5277318/+listing-archive-extra
[16:59] <bdmurray> Okay
[17:50] <slangasek> Laney: looks like packages got uploaded, thanks!  you'll track the build failures and record them in the pad for further divvying up?
[18:23] <Laney> slangasek: yup, already fixed a couple
[18:26] <slangasek> Laney, cjwatson: so is icu in hand and I shouldn't touch it?
[18:26] <slangasek> it jumped out at me as a main lib we probably wanted transitioned soon that looks like it needs some mass rebuilding
[18:28] <slangasek> umm why is xbmc-pvr-addons dep-wait on xbmc-addons-dev (>= 2:13.1~beta2+dfsg1~) when 2:13.2+dfsg1-4ubuntu1 is in wily? https://launchpad.net/ubuntu/+source/xbmc-pvr-addons/13.0+git20140512+g91cc731+dfsg1-2build1/+build/7758289
[18:28] <slangasek> (both packages in universe)
[18:29] <slangasek> ah, looks like it's a heuristic on the build log error message
[18:29] <slangasek> or... not?
[18:30] <slangasek> oh, it's only in *vivid*
[18:53] <hallyn> dannf: were you going to push the trusty qemu to archive yourself?
[18:53] <dannf> hallyn: yeah, unless you'd rather
[18:59] <dannf> hallyn: i've got a source package w/ the ppc/awk fix i'm about to push - let me know if i should wait
[19:03] <hallyn> dannf: nope, no reason to wait - thx much
[19:03] <hallyn> dannf: did you happen to run lp:qa-regression-testing test-qemu.py against it?
[19:05] <dannf> hallyn: nope, but i can
[19:16] <cjwatson> slangasek: the haskell bits are in hand anyway, yes
[19:16] <cjwatson> which I think is all of it
[19:17] <cjwatson> it's just tedious waiting for repeated layers to build
[19:44] <bdmurray> cjwatson: Oh, regarding consumer_name bug 755313
[19:45] <cjwatson> Heh, OK