[04:01] <ScottK> pitti: What would you think about building calibre against the system libmspack?  I looked at the source and there's a compile time option in configure already.  The embedded copy is an alpha version of the current release that we have in the distro.
[05:50] <BruceMa> --help
[05:50] <BruceMa> test
[08:02]  * infinity grumbles about more binaries moving around in syslinux and fixes d-i yet again.
[08:14] <pitti> Good morning
[08:15] <pitti> ScottK: sounds good; the less we can use the bundled bits the better
[08:15] <pitti> ScottK: noted
[08:32] <dpm> morning pitti
[08:32] <dpm> mvo_, cjwatson, could one of you perhaps review https://code.launchpad.net/~dpm/click/add-i18n-tools/+merge/240082 ?
[08:32] <dpm> (and good morning)
[08:32] <pitti> hey dpm, how are you?
[08:33] <dpm> pitti, good good - did you have a good rest of sightseeing day in Washington? :)
[08:34] <pitti> dpm: yes, I did; I had a marvellous weekend
[08:34] <mvo_> dpm: hey, good morning. sure I'm happy to have a look. this probably needs to go to ubuntu-sdk-libs-dev as well (i.e. added to the seed)
[08:34] <dpm> awesome
[08:35] <dpm> thanks mvo_. Yes, let me know if there are more changes required.
[08:36] <mvo_> dpm: yeah, seeding, but I can do that :)
[08:36]  * dpm hugs mvo_
[09:11] <dpm> mvo_, I noticed you've got a click/devel series. Do you need me to rather submit the change there? Also, would it be possible to do a click release so that we can get the Qt Creator app templates working?
[09:16] <mvo_> dpm: yes, please submit against lp:click/devel
[09:26] <dpm> mvo_, ok, done -> https://code.launchpad.net/~dpm/click/add-i18n-tools/+merge/240085
[09:27] <mvo_> dpm: thanks
[09:35] <apachelogger> cjwatson: where does isolinux/bootlogo file on the utopic isos come from? it appears to be radically different from what I have in the gfxboot-theme-ubuntu package
[09:35] <apachelogger> cjwatson: http://paste.ubuntu.com/8744667/
[09:36] <pitti> ScottK: how do you mean "compile-time option in configure"? (calibre has a setup.py with no such thing); anyway, I'll check what it takes to build against the system one
[09:37] <apachelogger> cjwatson: also FWIW, the package one appears broken and doesn't actually manage to render a UI as can be seen when rolling an ISO with ubuntu-defaults-builder
[09:40] <xnox> apachelogger: in utopic, we gained new syslinux which cannot load external files, thus all files used by the theme need to be repacked into bootlogo file itself.
[09:43] <xnox> apachelogger: i'm not quite sure which piece of software was modified to do that, cjwatson would know. let me see if i can find the relevant code.
[09:44] <xnox> apachelogger: http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/revision/1898
[09:45] <cjwatson> yeah it's gfxboot-theme-ubuntu with cpio adjustments from tools/boot/utopic/boot-amd64 in debian-cd
[09:46] <cjwatson> couldn't do much about the awkwardness beyond idly cursing syslinux upstream
[09:46] <apachelogger> :O
[09:46] <apachelogger> ah yes, I must be blind, I searched that file like three times
[09:46] <apachelogger> xnox: thanks :)
[09:47] <apachelogger> cjwatson: I do wonder if live-build should be adjusted for that
[09:47] <cjwatson> possibly, yes
[09:48] <mvo_> cjwatson: do you mind if I make  a new click release? what we have in click/devel + adding 15.04
[09:53] <cjwatson> mvo_: go for it!
[09:56] <pitti> ScottK: meh, that's going to become a rather messy hackery; they include a python module which needs internal libraries that libmspack-dev doesn't ship
[09:56] <pitti> ScottK: and if we include the ones from upstream, we mix headers and .c from different versions
[10:07] <cjwatson> mvo_: hold add-i18n-tools though
[10:07] <cjwatson> mvo_: (I'll follow up in the ticket, just a quick warning that it's broken)
[10:08] <cjwatson> mvo_: one-line fix if you want to just tweak lp:click/devel
[10:08] <mvo_> cjwatson: that would be great
[10:09] <mvo_> cjwatson: what did I overlook?
[10:09] <cjwatson> see MP :)
[10:09]  * mvo_ checks
[10:10] <mvo_> thanks!
[10:15] <mvo_> pete-woods1: hi, do you mind if I do a (trivial) cmake-extras upload to add a multi-arch: foreign field? send a MP already, this would unblock  building the click chroot on 15.04
[10:18] <pete-woods1> mvo_: not a problem. I'll also ensure I'm subsrcibed to MRs for it
[10:21] <mvo_> pete-woods1: cool, thanks! I noticed the previous released where done using the train - but for this one liner it seems a bit overkill?
[10:21] <mvo_> doko__: do you know why dh-python dropped the multi-arch: foreign patch? we had it in trusty but it was overwrite by a sync in utopic. was this maybe a accident?
[10:22] <pete-woods1> mvo_: can you make another fix to it while you're at it?
[10:22] <mvo_> pete-woods1: sure
[10:24] <pete-woods1> mvo_: http://paste.ubuntu.com/8745159/
[10:27] <mvo_> pete-woods1: thanks, I create a MP for this as well so its easier for you to merge
[10:27] <pete-woods1> okay, cool
[10:34] <mvo_> pete-woods1: and the final MP, thanks!
[10:35]  * pitti tries to untangle the phpunit -> phpunit-comparator, php-doctrine-instantiator -> phpunit circular (build-) deps mess
[10:35] <pitti> go Debian with your binary uploads!
[10:36] <xnox> pitti: well, we can use a bootstrap repository.... =)
[10:40] <cjwatson> pitti: I can help rebootstrap things given sequencing instructions
[10:41] <cjwatson> by injecting binaries for use as build-deps
[10:41] <pitti> cjwatson: ah, I just uploaded a phpunit-comparator with temporarily dropping the phpunit build-dep
[10:41] <pitti> once phpunit becomes installable, I'll upload a fakesync again
[10:41] <cjwatson> ah, ok, for future reference no need to leave the debris in the archive :)
[10:41] <pitti> cjwatson: ok, good to know
[10:45] <LocutusOfBorg1> is anybody planning to transition jpeg-turbo with the debian one?
[10:48] <cjwatson> Noskcaj: you uploaded a new upstream release of gnuhealth a while back, which is now causing a bunch of other stuff to be stuck in -proposed due to strict dependencies on tryton-*; since then, gnuhealth has been removed from Debian.  are you actually interested in maintaining this package permanently in Ubuntu or can I remove it from Ubuntu to match Debian?
[10:48] <cjwatson> (I would prefer the last answer unless you have quite a strong interest ...)
[11:15] <caribou> is it possible to build a ppc64el package using sbuild/pbuilder ?
[11:16] <caribou> or do we need ppc64el h/w (virt) for that ?
[11:17] <caribou> investigating Bug: #1387594
[11:25] <cjwatson> caribou: You can try with qemu; mk-sbuild --arch=ppc64el should set that up
[11:25] <cjwatson> caribou: Results may be a bit variable though
[11:25] <cjwatson> Hm, I think that works on x86 now but ICBW, check
[11:26] <cjwatson> If mk-sbuild succeeds then it should be worth a try at least
[11:26] <caribou> cjwatson: I don't need a working package, just need to investigate why it builds with HAVE_LIBC_LOCK_H
[11:26] <caribou> cjwatson: thanks for the tip, will try
[11:28] <xnox> caribou: ... but if you want hardware access, you could access canonical or debian porter boxes.
[11:28] <xnox> (both have low barrier of entry)
[11:31] <caribou> xnox: I have access to some remote VMs, but a bad Internet connection atm
[11:31] <xnox> ok =(
[11:31] <caribou> xnox: so building locally would help out when my internet go crazy
[11:31] <caribou> xnox: but thanks for the info
[11:44] <brainwash> once again ubuntu is stuck with a vulnerable chromium-browser version. can the current version be synced from debian?
[11:44] <brainwash> bug 1386455
[12:05] <Tribaal> brainwash: I guess a sync request is in order, yes. Di dyou have a look at https://wiki.ubuntu.com/SyncRequestProcess ? Thanks for bringing this up
[12:07] <brainwash> Tribaal: I don't know if the package can be simply synced
[12:07] <didrocks> Riddell: hey, do you think there would be anything kde-side blocking a bluez5 transition?
[12:07] <Tribaal> brainwash: good point. Let me try with requestsync, and I'll link your bug
[12:10] <brainwash> Tribaal: thanks. I just noticed this bug report while browsing launchpad. it's not the first time that chromium-browser is not up-to-date in ubuntu
[12:10] <Tribaal> right, maybe
[12:10] <brainwash> now there is already a 3 week gap
[12:11] <Tribaal> well, that's precisely what that sync request process is for :)
[12:12] <cjwatson> I suspect there are non-trivial Ubuntu modifications, though it is incumbent on anyone making a sync request to analyse that
[12:12] <cjwatson> it's probably best to poke Chad Miller
[12:12] <cjwatson> or the security team
[12:13] <xnox> pitti:  about https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1386257 I've pushed two merge proposals:
[12:13] <Tribaal> cjwatson: they are subscribed to that bug already - do you think and IRC ping is in order?
[12:13] <xnox> https://github.com/tseliot/ubuntu-drivers-common/pull/11
[12:13] <xnox> and
[12:13] <xnox> https://code.launchpad.net/~xnox/ubuntu-seeds/ubuntu.vivid-seed-intel-microcode/+merge/240070
[12:14] <xnox> pitti: do you maintain / review ubuntu-drivers-common things? =) and if yes, can you review those two?
[12:14] <pitti> hey xnox
[12:14] <pitti> xnox: tseliot and me, yes
[12:15] <pitti> xnox: you can do the seed change yourself, I figure :)
[12:15] <cjwatson> Tribaal: I can't speak for them, but bug mail can be pretty overwhelming for anyone doing more than a small amount in Ubuntu, so I generally don't assume that's enough for people to have seen urgent things
[12:15] <cjwatson> I haven't been on top of my bug mail in years :-/
[12:16] <pitti> xnox: can we cover this with the usual "Modaliases:" magic to match on a particular CPU model, or does that need a custom handler?
[12:16] <xnox> pitti: sure, but i still want the review for sanity. i don't have as much time fixing world breakages any more. =)
[12:16] <Tribaal> cjwatson: alright, I'll send them a gentle nudge
[12:16] <Tribaal> :)
[12:16] <brainwash> Tribaal: great, thanks :)
[12:17] <xnox> pitti: i believe no modaliases are published for the /sys/devices/cpu, thus using a custom detect plugin. and static mapping of vendors -> package name.
[12:17] <xnox> the detect plugin checks for the first vendor_id in /proc/cpuinfo
[12:17]  * xnox notes, that i should check what happens in qemu-kvm.
[12:18] <pitti> xnox: responded to the seed MP
[12:18] <xnox> pitti: in particular, we'd want intel-microcode to be always be installed, even if there is no microcode update for a given cpu version. Because there might be one in the future pushed via updates, and updates don't rerun ubuntu-drivers as far as i can tell.
[12:19] <xnox> pitti: also there is no ubuntu-drivers integration on the d-i / server installs, is there? E.g. i thought it would be useful with all the GPU workloads these days, etc.
[12:19] <pitti> xnox: only really if we commit to maintaining this package
[12:20] <pitti> multiverse seems a bit fishy for that
[12:20] <pitti> especially for LTSes
[12:21] <xnox> pitti: intel-microcode has maintainance history and sru's.
[12:22] <xnox> pitti: essentially ~intel-team & ~canonical-kernel-team request/push/update microcodes. This is partially in response to TSX bug, where microcode was released to disable that feature on Haswells.
[12:22] <xnox> only to find out that nobody upgrades/installs microcode packages by default.
[12:22] <pitti> xnox: right, so these shoudl probably get MIRed to restricted then?
[12:23] <xnox> intel-microcode - yes.
[12:23] <xnox> amd64-microcode - added to the detector for completness, but I cannot vouch for maintaining that.
[12:24] <xnox> given my interests and allegiance these days =)
[12:42] <mvo_> cjwatson: do you want a final review of the click merge before I jump into the train? shouldn't be needed as its really striaghtforward
[12:49] <cjwatson> mvo_: looks fine, I approved it for form's sake or whatever
[12:49] <cjwatson> mvo_: and yay for ubuntu-sdk-libs[-dev]
[12:50] <mvo_> cjwatson: :) thanks!
[12:54] <apachelogger> cjwatson: more problems, apparently syslinux-themes-ubuntu-utopic is missing some c32 links (: at the very least ldlinux.c32 libutil.c32 libcom32.c32
[12:54] <apachelogger> I suppose the fix would be adding the links?
[12:58] <cjwatson> apachelogger: Sounds reasonable, please go ahead
[12:59] <cjwatson> (trying to move this sort of thing off to people who care about it more since I'm not going to be maintaining this stuff as of 2015 ...)
[12:59] <cjwatson> it's possible it might be better to consider those links as something that live-build adds rather than as part of the theme, I'm not totally sure
[13:00] <cjwatson> they don't really feel ideal as theme elements
[13:00] <cjwatson> but then the whole theme concept is a bit ropey here
[13:02] <apachelogger> yeah, ubuntu-cdimage adds them manually, which is why it doesn't have this issue, so perhaps it would be better to do the same in lb for the sake of consistency
[13:03] <apachelogger> then again, the entire post-chroot part of lb is so vastly different it probably doesn't matter anyway
[13:03] <jdstrand> brainwash: I've asked chad to comment on the bug
[13:12] <Tribaal> jdstrand: oh, thanks
[13:19] <jdstrand> Tribaal, brainwash: I do know there were some rather significant compiler issues this time around. I'll let chad comment. we've discussed how we can better react to this sort of thing in the future too
[13:23] <brainwash> jdstrand: thank you for getting involved :)
[13:24] <Tribaal> jdstrand: awesome, thanks a lot
[14:33] <mdeslaur> cjwatson: mind if I merge wget?
[14:33] <cjwatson> mdeslaur: please do
[14:34] <mdeslaur> cjwatson: thanks
[14:34] <cjwatson> right now I'm happy for core-devs to take any of my merges, as long as they do appropriate things with any of them that are in version control with Vcs-Bzr control fields (notably anything in d-i)
[14:51] <mvo_> any concerns about  a gnutls28 merge/upload for vivid?
[14:53] <LocutusOfBorg1> cjwatson, I was asking about wget :)
[14:54] <cjwatson> LocutusOfBorg1: You're also not a core-dev, AIUI?
[14:55] <cjwatson> I'm not happy for just anyone to grab my merges, but core-devs have proven themselves to know what they're doing :)
[14:55] <LocutusOfBorg1> nope, I'm not, but things might change, right? :)
[14:55] <LocutusOfBorg1> I'm in the debian DD process, I hope to have the same possibility for ubuntu soon
[14:56] <cjwatson> by that point I probably won't have much in the way of regular open merges left, so it shouldn't arise :)
[14:57] <cjwatson> at the moment I'm just trying to cut down the pile of stuff that I'm routinely responsible for a bit, in preparation for moving to LP
[14:57] <LocutusOfBorg1> I would like for now to have the possibility to upload packages I'm uploader/maintainer, like the dm.txt list in debian, I remember ubuntu has something similar, does it?
[14:57] <LocutusOfBorg1> what is LP?
[14:57] <cjwatson> Launchpad
[14:57] <LocutusOfBorg1> lp development? nice!
[14:57] <cjwatson> and https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage is what you're looking for
[14:58]  * xnox should do / give up my merges as well.
[14:58] <LocutusOfBorg1> yep, thanks, I read it a while ago, I'll reread, now that with the debian freeze I'm stuck :D
[14:59] <LocutusOfBorg1> btw do I have changes to see bug 1098729 fixed with your move? :)
[15:05] <LocutusOfBorg1> cjwatson, unfortunately that page you linked me gets me stuck
[15:05] <LocutusOfBorg1> it points to https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[15:05] <LocutusOfBorg1> but there is no mention about debian maintainers, only developers
[15:06] <cjwatson> dunno, ask the DMB
[15:09] <Laney> It is as written there
[15:11] <LocutusOfBorg1> slangasek, sorry I wasn't aware
[15:12] <LocutusOfBorg1> so how can find the DMB?
[15:15] <geser> LocutusOfBorg1: if you have questions you can also mail the devel-permissions mailing list which is read by the DMB
[15:16] <LocutusOfBorg1> seems legit, thanks!
[15:16] <LocutusOfBorg1> BTW how can I build a package that takes more than 50GB on ppa buildds? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/6520797
[15:17] <LocutusOfBorg1> :( i need to test gdcm build dependencies for the merge I did
[15:26] <pitti> ook; so gnome-shell fails because of mutter fails because of zenity fails because of gtk+3.0
[15:26]  * pitti untangles
[15:27] <caribou> slangasek: I've just put more notes into LP: #1387594
[15:28] <caribou> slangasek: so a PPA build returns a package that uses __libc_lock_lock which is not provided by libc
[15:28] <caribou> slangasek: the one in the archive does not make use of this symbol
[15:28] <mardy> Laney: hi! About https://code.launchpad.net/~laney/libaccounts-glib/libtool-and-gi/+merge/240116
[15:29] <slangasek> caribou: right, so that seems like the package now misbuilds on all archs, but wasn't noticed anywhere but ppc64el because that's the only place where the binaries were built recently?
[15:29] <caribou> slangasek: no, it seems to correctly build everywhere _but_ on ppc64el
[15:30] <mardy> Laney: the changes (except for those in debian/) need to land in https://code.google.com/p/accounts-sso/source/list?repo=libaccounts-glib first
[15:30] <caribou> slangasek: but when I build manally or through PPA build, I get the same build behavior than with ppc64el
[15:30] <caribou> slangasek: with the same source pkg
[15:30] <mardy> Laney: do you want to file a bug with the git patch? or I can do that for you, if you are busy
[15:30] <Laney> mardy: oh okay, I thought it was Ubuntu, can you commit there?
[15:30] <Laney> or do you want a separate review?
[15:31] <mardy> Laney: I can commit there, I just want to give you credit as the author. I'll use your @canonical.com e-mail, is that OK?
[15:32] <Laney> mardy: fine by me
[15:32] <Laney> thanks
[15:32] <caribou> slangasek: just checked i386 in the archive : it is correct (i.e. does not use __libc_lock_lock)
[15:33] <slangasek> caribou: what do you mean when you say it correctly builds everywhere but ppc64el?  The last upload to the archive was in 2012; if a rebuild in a ppa shows the same bug, that points to a build regression that's gone unnoticed
[15:33] <slangasek> to me, that sounds like it correctly /built/ everywhere, but that it /no longer/ correctly builds anywhere
[15:33] <caribou> slangasek: ah, "last upload to the archive was in 2012"
[15:34] <caribou> indeed, then that explains why I cannot rebuild it w/o the _libc_lock_lock
[15:35] <caribou> slangasek: so maybe good to put a note somewhere *not* to rebuild it, otherwise any system doing ldap authentication will fail to reboot :-/
[15:35] <slangasek> caribou: no, packages need to be rebuildable, please mark this bug critical
[15:35] <caribou> slangasek: already is; I'll tag it for all releases
[15:36] <caribou> slangasek: I suspect that it comes from another depend that picks up libc6-dev where /usr/include/x86_64-linux-gnu/bits/libc-lock.h comes from
[15:37] <caribou> libc-lock.h is where HAS_LIBC_LOCK_H  is defined
[15:39] <cjwatson> libc6-dev is build-essential
[15:39] <caribou> cjwatson: yep, noticed that
[15:39] <cjwatson> inherently
[15:41] <caribou> this is the define that picks it up :
[15:41] <caribou> if defined(HAVE_LIBC_LOCK_H) || defined(HAVE_BITS_LIBC_LOCK_H)
[15:44] <cjwatson> sounds like code that's been extracted from libc and improperly adjusted, perhaps.  guarding with _LIBC might be wise, though I haven't checked the context.
[15:46] <cjwatson> my understanding is that that interface is libc-internal and that nothing outside libc should be using it even if it's present.
[16:00] <bdmurray> mvo_: could you have a look at bug 1386354?
[16:00] <caribou> cjwatson: the upstream pristine tar file has those two #undef. It is changed by a quilt patch
[16:01] <LocutusOfBorg1> Laney, rebuilds for gdcm and upnpc done
[16:01] <LocutusOfBorg1> upnpc just a trivial patch
[16:01] <LocutusOfBorg1> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa
[16:01] <Laney> thanks, I'll look later today hopefully
[16:01] <cjwatson> caribou: such defines are usually detected at build time
[16:02] <LocutusOfBorg1> no problem ;)
[16:03] <LocutusOfBorg1> thanks to you!
[16:04] <mvo_> bdmurray: looking
[16:04] <mvo_> bdmurray: thanks
[16:06] <caribou> cjwatson: that looks interesting : http://anonscm.debian.org/viewvc/collab-maint/deb-maint/libnss-ldap/trunk/debian/patches/glibc-2.16.patch?view=log
[16:07] <caribou> cjwatson: Add glibc-2.16.patch to handle removal of __libc_lock_lock and similar symbols from libc (Closes: #727177).
[16:09] <cjwatson> caribou: looks plausible yes
[16:10] <cjwatson> so just needs a merge
[16:10] <caribou> cjwatson: the bug report is even more explicit : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727177
[16:12] <caribou> cjwatson: so 265-3 which is in unstable will be merged into vivid, then the specific patch for #727177 should be SRUed into the releases
[16:13] <cjwatson> makes sense
[16:14] <caribou> cjwatson: ok, will get to that first thing tomorrow morning
[16:15] <cjwatson> great
[16:19]  * caribou makes a note to go & check debian BTS more often for bugs not yet merged into Ubuntu
[16:20] <bdmurray> doko__: could you have a look at bug 1363785?
[16:25] <pitti> smoser: do you know when we'll get vivid cloud images?
[16:25] <smoser> utlemming, ^ ?
[16:26] <pitti> smoser: ah, right; sorry for being my favorite cloud ping guy :)
[16:26] <cjwatson> xnox: Could you merge pythonmagick (or tell me I can) for the imagemagick transition, please?
[16:28] <smoser> pitti, thats perfectly fine.
[16:28] <smoser> rcj also might know.
[16:29]  * xnox looks
[16:32] <xnox> cjwatson: hm, it should have been a sync by now, but looks like gccxml got split differently in debian now.
[17:37] <darthbunny> hello!
[17:38] <darthbunny> can anyone help me with a problem related to unity8 in ubuntu-desktop-next?
[17:50] <dobey> darthbunny: #ubuntu is the general support channel. you can maybe ask in #ubuntu-unity for unity-specific questions. but please just ask the question, don't ask to ask
[17:53] <Laney> neat, sponsor-patch checks if the bug is closed
[17:53] <Laney> and puts you in a subshell to fix the problem ♥
[17:53]  * Laney hugs bdrung 
[18:10] <Laney> LocutusOfBorg1: I uploaded miniupncpcpcpcponc
[18:10] <Laney> will try to get to some of the rdeps if it clears NEW soon
[18:10] <Laney> but I don't know how much I'll be around over the weekend
[18:10] <seb128> Laney, I can look at NEW and rdepends tomorrow
[18:11] <Laney> cool, thanks
[18:11] <Laney> bug #1387096 links to the ppa
[19:06] <bdmurray> mlankhorst: it'd be good if bug 1365695 had a test case although from a quick glance it looks like the bug is black screen
[19:18] <directhex> infinity: ping
[19:26] <rharper> if I wanted to debug an apt get install dependency error offline, what files off the host would I need to help figure that out at a later time?  /var/lib/apt ?
[19:44] <infinity> directhex: pongski.
[19:45] <ricotz> lol
[19:51] <ricotz> infinity, hi, is there an auto-sync from debian/experimental?
[19:52] <infinity> ricotz: Nope.
[19:53] <infinity> ricotz: We only autosync from sid, if you feel experimental is a better source for a specific package, you need to 'syncpackage -d experimental <foo>' manually.
[19:53] <infinity> ricotz: But that also implies some responsibility on your part to keep an eye on it and resync, at least until said version hits sid.
[19:54] <ricotz> infinity, ok, yeah i know, i was just wondering about a specific one but i guess Laney synced granite for the g-i MA transition
[19:55] <ricotz> infinity, will do when it comes to that, thanks
[19:56] <infinity> As we head into another Debian freeze, it's perhaps worth reopening the discussion about if it would be a good (or awful) idea to let people pin a sync source to experimental, but autosync so far are a pretty stateless thing, so that would be a bit of code to get right on the server side.
[20:02] <ScottK> pitti: Sounds painful.  I guess maybe consider it in Debian for Jessie +1.
[20:02] <ScottK> Thanks for looking.
[20:10] <mlankhorst> bdmurray: yeah black screen is pretty much it
[20:14] <bdmurray> mlankhorst: still it'd make things easier for the SRU team if we could find the SRU information easily
[22:26] <bdrung> Laney: :)
[23:09] <Logan_> infinity: sounds like a bad idea to me to pin sync sources to things other than unstable
[23:09] <Logan_> unless it's only in the more stable direction