=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== athairus is now known as afkthairus
[05:51] <doko> tedg, bdmurray: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1592649 please backport
[05:51] <ubottu> Launchpad bug 1592649 in whoopsie (Ubuntu) "whoopsie fails to build from source in xenial" [High,Confirmed]
[06:02] <pitti> Good morning
[06:07] <doko> rbasak, I see some build regressions with mysql-5.7 in xenial
[06:08] <pitti> nacc: this group already landed apparantly
[06:08] <pitti> nacc: I retried all the other php regressions now, maybe some of it will stick now
[06:18] <doko> pitti, https://launchpadlibrarian.net/265375370/buildlog_ubuntu-xenial-amd64.ubuntu-defaults-builder_0.54_BUILDING.txt.gz
[06:23] <doko> sil2100, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160614-xenial.html could you address the dbus-cpp ftbfs with the touch guys?
[06:23] <doko> barry, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160614-xenial.html could you look at the bzr ftbfs?
[06:24] <sil2100> doko: hey! Ok, will poke them, uh, dbus-cpp again...
[06:26] <pitti> doko: fix uploaded
[06:48] <doko> apw, could you have a look at https://launchpadlibrarian.net/265374798/buildlog_ubuntu-xenial-amd64.kmod_22-1ubuntu4_BUILDING.txt.gz ?  using ppa:ubuntu-toolchain-r/ppa
[06:49] <infinity> apw: ^-- That's fixed in Debian, just needs a merge.
[06:51] <doko> jamespage, https://bugs.launchpad.net/ubuntu/+source/migrate/+bug/1592663
[06:51] <ubottu> Launchpad bug 1592663 in migrate (Ubuntu) "migrate fails to build in xenial" [High,Confirmed]
[07:02] <doko> rbasak, https://bugs.launchpad.net/ubuntu/+source/python-pymysql/+bug/1592664
[07:02] <ubottu> Launchpad bug 1592664 in python-pymysql (Ubuntu) "python-pymysql fails to build on xenial and yakkety" [High,Confirmed]
[07:03] <slangasek> nacc: fyi I'm going to drop the delta to php-codesniffer to add nocheck/stage1 profiles; it's not worth carrying a delta to the package for, though it probably is worth someone taking the time to submit that patch upstream to Debian
[07:20] <jamespage> hmm fallout of the late-ish switch to mysql-5.7
=== _salem is now known as salem_
[07:35] <apw> infinity, doko, erp ok
[07:55] <doko> sil2100, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1592691
[07:55] <ubottu> Launchpad bug 1592691 in mir (Ubuntu) "mir fails to build in xenial" [High,Confirmed]
[07:55] <doko> sil2100, //bugs.launchpad.net/ubuntu/+source/unity/+bug/1592676
[08:00] <sil2100> doko: thanks, let me forward those further
[08:02] <cyphermox> xnox: am I still supposed to have to restart gpg-agent all the time
[08:04] <xnox> cyphermox, =((((((
[08:06] <doko> xnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20160614/+build/9977711
[09:13] <doko> xnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20160614/+build/9977711
[09:14] <doko> apw, https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1592722  please merge and backport
[09:14] <ubottu> Launchpad bug 1592722 in kmod (Ubuntu) "kmod fails to build in xenial (and yakkety)" [High,Confirmed]
=== salem_ is now known as _salem
[10:22] <Unit193> Looks like libtorrent somehow wasn't properly rebuilt against boost, no-change rebuild fixes the problem with it.
[10:38] <apw> doko, on it
[11:03] <rbasak> doko: will look - thanks.
=== hikiko is now known as hikiko|ln
[12:13] <doko> jamespage, could you have a look at https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1592793 ?
[12:13] <ubottu> Launchpad bug 1592793 in openvswitch (Ubuntu) "openvswitch fails to build in xenial on armhf" [High,Confirmed]
[12:14] <jamespage> doko, I should think so
=== hikiko|ln is now known as hikiko
[12:34] <LocutusOfBorg> abeato, hi, ping about ofono if you are interested :) (new version in Debian)
[12:36] <abeato> LocutusOfBorg, hey, thanks for the info, I saw a new upstream version too (we actually go there directly these days)
[12:36] <LocutusOfBorg> thanks for caring :)
[12:47] <rbasak> cpaelzer: I really appreciate your commentary in bug 1581839 (comment 3). Makes it much easier to review. Thank you.
[12:47] <ubottu> bug 1581839 in clamav (Ubuntu Xenial) "package clamdscan 0.98.7+dfsg-0ubuntu4 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/clamdscan.1.gz', which is also in package clamav-daemon 0.98.7+dfsg-0ubuntu0.14.04.1" [High,Triaged] https://launchpad.net/bugs/1581839
=== chrisccoulson_ is now known as chrisccoulson
[12:51] <Son_Goku> so who's the guy making all these random snapd packages for the distros
[12:52] <rbasak> Son_Goku: I'm not sure, but there's a separate #snappy channel.
[12:52] <Son_Goku> he's zyga on github, but who is he on IRC?
[12:52] <Son_Goku> ah
[12:52] <Son_Goku> thanks
[12:52] <cpaelzer> I'm sure - there is a #snappy channel
[12:52] <rbasak> cpaelzer: snap :-P
[12:52] <dobey> zyga is zyga
[12:52] <cpaelzer> I asked around there yesterday :-)
[12:53] <rbasak> cpaelzer: bug 1581839 looks good, just one question. I'm not sure what the right answer is.
[12:53] <ubottu> bug 1581839 in clamav (Ubuntu Xenial) "package clamdscan 0.98.7+dfsg-0ubuntu4 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/clamdscan.1.gz', which is also in package clamav-daemon 0.98.7+dfsg-0ubuntu0.14.04.1" [High,Triaged] https://launchpad.net/bugs/1581839
[12:53] <rbasak> cpaelzer: it's fairly comment when marking a Breaks/Replaces to suffix a ~, so that it catches backports as well. Eg. version X backported becomes X~something, so X~ is lower than them both, but X is not.
[12:53] <rbasak> common
[12:54] <cpaelzer> rbasak: yeah we talked about it, but since we are not targetting a specific "old" version we should be fine
[12:54] <rbasak> So, in this case, do we want 0.99+dfsg-1ubuntu1~ in case 0.99 is backported to Trusty, or would that be completely the wrong thing to do?
[12:55] <cpaelzer> rbasak: we are tarketting anything prior to the first version in the release
[12:55] <cpaelzer> rbasak: ah - I think I finally got you ...
[12:55] <cpaelzer> rbasak: you mean if a backport add 0.99 back ... hmm
[12:55] <cpaelzer> yeah I tihnk I neglected that case too early
[12:55] <rbasak> I guess one question is: if 0.99 does get backported to Trusty, then which way round will the manpages be in it?
[12:56] <rbasak> Though, Breaks/Replaces catching some extra stuff will do no real harm here.
[12:56] <cpaelzer> rbasak: we don't know for sure how the backport would be done, I'd expect to be the "new" way
[12:56] <cpaelzer> rbasak: and then it would already have made that transition
[12:56] <cpaelzer> rbasak: the "extra" breaks/replaces that will occur then shouldn't hurt us right?
[12:57] <rbasak> shouldn't hurt us right?> right
[12:57] <rbasak> would already have made that transition> assumes that the user has dist-upgraded Trusty before dist-upgrading to Xenial.
[12:57] <rbasak> Which may be a fair assumption to make, but if we can make it safer than we might as well I think.
[12:58] <rbasak> So, if my logic is right (and I'm really not sure, would appreciate you confirming), we should suffix ~.
[12:58] <cpaelzer> rbasak: I'm currently in a test fight with dpkg --compare-versions about this
[12:58] <rbasak> Actually my logic is a little flawed. It won't matter if the user upgrades from release pocket Trusty straight to Xenial, because then the B/R in Xenial will catch it anyway.
[12:58] <cpaelzer> rbasak: I'd recommend you http://www.justgohome.co.uk/blog/2015/01/ubuntu-package-versions.html but well, you should know :-)
[12:59] <rbasak> :-)
[12:59] <rbasak> I think a suffix ~ is only required if 0.99 is later backported to Trusty with Trusty (not Xenial) packaging.
[12:59] <rbasak> (so old manpage locations)
[13:00] <cpaelzer> rbasak: I also think ~ isn't required for the following reason
[13:00] <cpaelzer> rbasak: so 0.99~ is -lt than 0.99 as I thought - which also is reasonable as it "has to"  upgrade for e.g. changes .so linkage
[13:01] <cpaelzer> rbasak: that means no one will ever be able (without wreaking havoc) to insert anything not falling into <0.99 (without ~)
[13:01] <cpaelzer> rbasak: and that way the <0.99 will catch all cases we want
[13:01] <cpaelzer> my - probably even more flawed - thinking
[13:02] <cpaelzer> but that is 2/2 votes to go without ~ in this case
[13:02] <cpaelzer> And a backporter would have to explcitly make changes to "reapply" the old Trusty packaging
[13:03] <cpaelzer> if we have to choose that is not the one I'd consider likely
[13:04] <rbasak> I think it depends on how the Trusty updates are done. Whether they typically bump new upstream version without pulling in debian/ from newer releases, or whether they are full backports from the development release.
[13:05] <cpaelzer> rbasak: lets play this out if 0.99 gets backported it will become 0.99~ to ensure the upgrade path is working
[13:05] <doko> sil2100, for completeness: https://bugs.launchpad.net/ubuntu/+source/dbus-cpp/+bug/1592814
[13:05] <ubottu> Launchpad bug 1592814 in dbus-cpp (Ubuntu) "dbus-cpp fails to build on xenial" [High,Confirmed]
[13:05] <cpaelzer> rbasak: if the backport does the move then the backport has to do the same breaks/replaces to work
[13:06] <infinity> Trevinho: Congrats, your new unity-settings-daemon crashed for me after I upgraded. :P
[13:06] <cpaelzer> rbasak: if we come again with 0.99 in Xenial we will break/replace again - but that is not "wrong", just too much
[13:06] <cpaelzer> rbasak: but
[13:06] <cpaelzer> rbasak: if the backport doesn't move the files, our match with <0.99 (without ~) will be required
[13:07] <cpaelzer> rbasak: wo without ~ works in both cases, while with ~ will only work in one of two ways a potential backport could be done
[13:07] <cpaelzer> rbasak: right?
[13:07] <rbasak> cpaelzer: when you say <0.99 (without ~), do you mean (<< 0.99+dfsg-1ubuntu1)?
[13:10] <sil2100> doko: thanks, will forward it, but tvoss is on it already
[13:10] <cpaelzer> rbasak: yes
[13:11] <cpaelzer> rbasak: where in that version string would the ~ be insertded on a backport?
[13:11] <rbasak> 0.99+dfsg-1ubuntu1~ would be the alternative usually.
[13:12] <rbasak> But in this case, it looks like debian/ is never updated (except as necessary) when a new upstream is pulled in.
[13:13] <rbasak> (I did "git clone -b ubuntu/trusty-updates git://git.launchpad.net/~usd-import-team/ubuntu/+source/clamav
[13:13] <rbasak> " to look at the history - thanks nacc!)
[13:13]  * rbasak ponders
[13:13] <rbasak> This is a little mindbending :-/
[13:14] <cpaelzer> rbasak: trying to simplify that - I think we should "catch" as much as possible to be on the safe side. Appending a ~ makes a version "smaller". That means not adding it at the breaks/replaces catches more
[13:15] <rbasak> cpaelzer: thanks. You've just convinced me.
[13:15] <cpaelzer> I'll mark that day in my calendar :-)
[13:15] <rbasak> :-)
=== JanC is now known as Guest29167
=== JanC_ is now known as JanC
[13:17] <cpaelzer> dkms question - in a dkms package sources are placed in /usr/src/<packagename> which is good as I can rely upon that. Is there any sort of Variable I could use in the associated dkms conf file to refer to that path?
[13:17] <cpaelzer> or at least the package name (in case it ever changes)
[13:18] <cpaelzer> I have code that works fine for me writing the full path, but I'd like to be as adaptive as possible to have less chance to break in the future
[13:22] <infinity> Trevinho: Completely reproducible.  Lock->Fade->BacklightOff->USDCrashes->Fonts, etc go wonky.
=== _salem is now known as salem_
=== afkthairus is now known as athairus
[13:29] <cpaelzer> fyi -  found it in man dkms after reading a while - cancelling my former question
[13:44] <seb128> infinity, distro serie, unity-settings-daemon version, backtrace?
[13:48] <infinity> seb128: yakkety, filed a bug, network here sucks, looking for the bug #. :P
[13:49] <seb128> infinity, with the version that landed a few hours ago?
[13:49] <infinity> seb128: Aye.
[13:49] <seb128> https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1592816
[13:49] <ubottu> Error: launchpad bug 1592816 not found
[13:49] <seb128> k
[13:50] <seb128> Trevinho, ^
[13:50] <infinity> seb128: The xenial SRU version is lovely.  The yakkety version, less so.
[13:50] <seb128> yeah, we have a good stack of changes in that update
[13:50] <seb128> we were discussing SRUing some
[13:50] <seb128> but looks like we have some work to do first
[13:50] <infinity> *nod*
[13:51]  * infinity downgrades for now, before this drives him nuts.
[13:51] <seb128> though it's in the screensaver proxy which was not on the list of things we are looking at SRUing for this round
=== sil2100_ is now known as sil2100
[14:18] <LocutusOfBorg> hi does anybody know what is missing liquidsoap for migration?
[14:18] <LocutusOfBorg> is biniou testsuite, right?
[14:51] <nacc> pitti: thanks, i'll keep you posted
[14:51] <nacc> slangasek: agreed, i'm working on sending those up to debian in parallel
[14:55] <Trevinho> infinity: it's a pure upstream change, so not all my fault... And I didn't notice that before
[14:55] <Trevinho> infinity: however, easy to fix I guess
[14:55] <Trevinho> actually....
[14:59] <seb128> Trevinho, lying :p
[14:59] <Trevinho> seb128: check https://github.com/GNOME/gnome-settings-daemon/blob/master/plugins/power/gsd-power-manager.c no signal disconnection at all :)
[15:00] <Trevinho> which... I believe doesn't happen there because of some reason
[15:00] <Trevinho> At least there's not something different in there
[15:01] <Trevinho> in the idle management
[15:04] <seb128> Trevinho, https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=5614e2c7a275a092e1fcf43450d7f0c5730c14bd
[15:05] <seb128> Trevinho,
[15:05] <seb128> -                        ret = upower_kbd_toggle (manager, &error);
[15:05] <seb128> -                        if (!ret) {
[15:05] <seb128> +                        if (upower_kbd_toggle (manager, &error) < 0) {
[15:05] <seb128> Trevinho, you changed the return type so I guess we need those ret check changes as well?
=== salem_ is now known as _salem
[15:08] <Trevinho> seb128: oh, it seems os
[15:08] <Trevinho> so*
[15:09] <Trevinho> seb128: also noticed that ci-train has  a big  issue in generating bzr changelogs... No multilnes anymore in commits
[15:09] <Trevinho> I added on these the git commits I backported
[15:09] <seb128> oh?
[15:09] <Trevinho> robru: ^
[15:10] <seb128> example?
[15:10] <Trevinho> seb128: see https://code.launchpad.net/~3v1n0/unity-settings-daemon/kbd-brightness-update/+merge/295000 and compare with what we have in bzr log for trunk
[15:10] <Trevinho> just first line is taken
[15:10]  * Trevinho now wants to redo that :-@
[15:11] <rbasak> teward: I just commented on bug 918896. Here's a wider question for the channel. If we want to apply an Ubuntu delta to a version 1.0 source package, then is it OK to just throw quilt at it and bundle up the source package so that the applied quilt patch is effectively in the diff.gz? I've not seen it done this way before.
[15:11] <ubottu> bug 918896 in pymssql (Ubuntu Yakkety) "No data returned from MSSQL server" [High,Confirmed] https://launchpad.net/bugs/918896
[15:12] <seb128> Trevinho, oh, right :-/
[15:12] <rbasak> Usually I'd expect to use the packaging's patch system if there is one, or to not use a patching system at all when applying an Ubuntu delta (and just applying the patch wholesale)
[15:12] <teward> rbasak: the other option other than "not fixing it" is "replace it completely", or "remove it"
[15:13] <teward> because I already poked the Debian python modules team
[15:13] <teward> they aren't motivated to fix it
[15:13] <teward> and say "how about you prepare a team upload and we sponsor it"
[15:13] <teward> which doesn't help solve the problem
[15:14] <teward> the other is "do nothing" and NACK the suggested debdiff
[15:14] <Trevinho> seb128: you want me to backport the whole commit?
[15:14] <Trevinho> (plus a couple more linked in the same bug)?
[15:15] <teward> rbasak: if you have an alternative suggestion for fixing it let me know
[15:16] <teward> but that package?  Unmaintained since 2009 I think it was *checks logs*
[15:16] <seb128> Trevinho, your call, unsure if we need the property
[15:16] <seb128> Trevinho, the ret check might be enough
[15:16] <rbasak> teward: apply the patch without quilt. So "quilt -a", move fix-get-result.patch to /tmp or something, remove debian/patches and .pc, "patch -p1 < /tmp/...", and build the source package like that.
[15:16] <teward> rbasak: E:FTBFS: Changes in source package not reflected
[15:16] <teward> tried that
[15:16] <rbasak> teward: I'm not sure I'm correct in declining to sponsor what you provided though. I'd appreciate some feedback on that from someone else.
[15:16] <Trevinho> seb128: ok
[15:17] <teward> i'll rebuild/test again in sbuild shortly
[15:17] <teward> but failing that
[15:17] <rbasak> teward: that's odd. I'd expect it to not do that since it's source format 1.0.
[15:17] <teward> rbasak: first instinct was to say "Lets remove it"
[15:17] <teward> but the rdeps list becomes massive
[15:18] <teward> rbasak: i'm just as happy running `sudo pip install pymssql` everywhere instead - would rather have 2.1.2 from upstream than obsolete/broken 1.0.x from the repos)
=== _salem is now known as salem_
=== salem_ is now known as _salem
[15:59] <Trevinho> infinity: in few seconds you should get fixed packages at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014/+packages
[16:36] <teward> rbasak: following your advice now, to see if it all works as it should
[16:37] <teward> debuild -S didn't complain, but sbuild might, so we'll see
[16:40] <nacc> so ... is there a bug in `pull-debian-source`? specifically that it calls rmadison('debian', package, suite, 'source'), but the 4thparameter to rmadison() is the architecture?
[16:42] <nacc> this is in 16.04
[16:43] <nacc> oh nm, apparently, 'source' is a valid arch specificier :/
[17:20] <teward> rbasak: you can unsubscribe sponsors for now from that bug
[17:20] <teward> i'll readd when i get a chance to respin/test debdiffs
[17:20] <teward> in the manner you just stated
[17:36] <nacc> can someone rerun the php-horde-core -> php-horde-imp armhf test failure? it seems to be a testbed issue (timeout)
[17:36] <nacc> same with php-horde-mime -> php-horde-compress
[17:44] <ctpd> Can someone point me to the latest Xenial relase glibc sources.
[17:45] <nacc> ctpd: http://packages.ubuntu.com/xenial/glibc-source ?
[17:45] <rbasak> nacc: done
[17:46] <ctpd> nacc: thanks
[17:46] <nacc> rbasak: thanks!
[17:47] <nacc> also, i think the php-fxsl -> phpdox i386 failure needs to be rerun against the newer version of phpdox (where it passes everywhere else)
[17:51] <ctpd> Is the git branch (of Xenial release glibc) somewhere available (online)? Need the change history...
[17:53] <nacc> ctpd: i don't believe it's maintained in git; do you need more than the changelog provides?
[17:53] <ctpd> nacc: yes, the actual changes
[17:54] <nacc> ctpd: i can import the whole history of publishing (cf. ubuntu-server e-mails on the subject), but it won't be a normal git history, but a publishing history (you can use `git diff` etc, though)
[17:55] <ctpd> nacc: sounds like an overkill...
[17:57] <ctpd> in particular i have some doupts about some changes in bits/pthreadtypes.h. Would like to know more about the history before diving into discussions.
[17:58] <nacc> ctpd: http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.23-0ubuntu3/changelog doesn't mention any changes to that file in ubuntu
[18:00] <ctpd> nacc: ahh. ok... should get in contact with the debian guys then:
[18:00] <ctpd> * debian/patches/hurd-i386/local-pthread_types.diff: make it create a new     sysdep/mach/hurd/bits/pthreadtypes.h instead of modifying     bits/pthreadtypes.h.  Move from series.hurd-i386 to series.
[18:01] <nacc> ctpd: yep
[18:01] <morphis> stgraber: sorry, didn't saw your pong yesterday
[18:01] <ctpd> nacc: thx
[18:02] <morphis> stgraber: just wanted to check if you can tell me how far uid_map/gid_map support on 3.10 based kernel should be; should I be able to map uid/gid range I've added in /etc/subuid / /etc/subguid?
[18:02] <morphis> stgraber: (for user namespaces)
[18:03] <rbasak> nacc: I suggest you configure quilt as documented in https://wiki.debian.org/UsingQuilt. Eg. "-p ab" for quilt refresh. This reduces diff noise.
[18:04] <rbasak> (IMHO, this should be part of dep3 to save diff noise by standardising for everyone)
[18:06] <nacc> rbasak: fixing locally
[18:07] <rbasak> nacc: don't worry about fixing up this merge or anything. Not worth it. Looks like this package will have to have noisy quilt changes all the time anyway since the version number is embedded in path names :-/
[18:09] <rbasak> nacc: to confirm, you're happy for me to upload php-imagick from your tree now, right?
[18:09] <nacc> rbasak: yes please
[18:09] <rbasak> OK
[18:16] <nacc> rbasak: thanks! yeah there's a few packages that are like that in php (and the debian vcs also shows commits that are just rewriting the diffs)
[18:17] <nacc> i've also sent almost all of it to debian and once the newer imagemagick gets in debian, we can merge/sync that and drop our remaining delta
[18:20] <nacc> rbasak: not sure if you saw it earlier, but if you could also retrigger the php-fxsl -> phpdox build (it ran on i386 with an older phpdox)
[18:20] <rbasak> nacc: done. Sorry I missed it before.
[18:20] <nacc> rbasak: np!
[18:23] <rbasak> nacc: got time for a sync on the importer later? No urgent. Perhaps on the hour (37 minutes)?
[18:23] <rbasak> nacc: php-imagick uploaded BTW.
[18:46] <nacc> rbasak: i'm free now, i might have a contractor coming by during that sync up, but should only need to let them in to measure
[18:48] <teward> rbasak: wrt 918896, it works without the quilt patch, albeit Lintian is throwing some complaints
[18:49] <teward> i'll go test that built binary on Yakkety, and if all else works, replicate for other releases
[18:49] <teward> sponsors unsub'd until I can get to it
[18:54] <stgraber> morphis: non-existent basically
[18:56] <nacc> did something just happen to debian's package information? https://packages.debian.org/search?keywords=php-defaults
[18:56] <nacc> rmadison says it's there
[18:59] <rbasak> nacc: sorry, I was getting dinner. I'll fire up a Hangout now.
[18:59] <rbasak> teward: great, thanks!
[19:00] <nacc> rbasak: sounds good
[19:04] <rbasak> nacc: http://stackoverflow.com/a/4971817/478206
[19:22] <morphis> stgraber: ok, so I basically have just a single user I can map
[19:23] <morphis> stgraber: just https://paste.ubuntu.com/17376163/ wonders me then
[19:29] <robru> Trevinho: please file a bug against lp: bileto with what you expect the generated changelog to be
[19:38] <robru> Trevinho: don't forget you can supply your own changelog if you're unhappy with the one generated for you
[19:52] <morphis> stgraber: but I see what the trick is now with new[u,g]idmap
[20:03] <nacc> pitti: can you kick the php-defaults -> php-imagick tests now that the new php-imagick has landed in -proposed? (should be migrating to -release shortly)
[20:04] <nacc> or anyone else, really :)
[20:42] <juliank> Word is in: Google repos produce no warnings anymore!
[20:42] <juliank> (except Earth)
[20:42] <Unit193> \o/  Now if videolan will fix 'em.
[20:46] <nacc> heh, google-talkplugin now gets a hash sum mismatch :)
[20:46] <juliank> Yay!
[20:46] <nacc> exchange one warning for an error :)
[20:46] <tumbleweed> doesn't google earth require LSB stuff anyway?
[20:47] <Unit193> Noticed that, nacc.  Great stuff. :P
[21:18] <juliank> nacc: Tell mmoss@chromium.org, maybe in https://bugs.chromium.org/p/chromium/issues/detail?id=596074
[21:19] <nacc> juliank: thanks for the pointer
[21:37] <nacc> slangasek: i think we can delete php-zend-search from yakkety (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816684), that's what is holding up the php-zend* in proposed, afaict
[21:37] <ubottu> Debian bug 816684 in php-zend-search "Useless in Debian" [Serious,Open]
[22:57] <mwhudson> is there some way i can use copy-package to copy the newest version of a package in a distroseries? i.e. from -proposed if it's there, -updates if there, -release if not?
=== Serge is now known as Guest36294
=== kees_ is now known as kees
=== Guest36294 is now known as wtf_freenode
=== ]reed[ is now known as [reed]
=== dasjoe_ is now known as dasjoe
=== Cimi_ is now known as cimi
=== lynxman_ is now known as lynxman
=== bdrung_ is now known as bdrung
=== ikonia_ is now known as ikonia
[23:17] <cjwatson> mwhudson: not that I'm aware; would require a wrapper to go hunting
[23:18] <mwhudson> cjwatson: ack
[23:21] <mwhudson> cjwatson: next question i guess, how would that wrapper work? launchpadlib i guess
[23:21] <mwhudson> or grepping ~/.chdist/trusty/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_${suite}_*_binary-amd64_Packages
[23:22] <cjwatson> something with getPublishedSources I guess
[23:22] <mwhudson> unless i can get apt-cache to tell me the suite somehow
[23:22] <cjwatson> you can give it a series but not a pocket
[23:22] <cjwatson> I mean, you can give it a pocket as well but you don't have to
=== attente_ is now known as attente
=== southey is now known as foxtrot