[00:07] <TheMuso> @pilot in
[00:07] <cjwatson> shadeslayer: http://qa.ubuntuwire.com/ftbfs/#kubuntu is probably simplest
[03:06] <TheMuso> @pilot out
[03:26] <darkxst> TheMuso, Thanks!
[03:34] <TheMuso> darkxst: np
[05:44] <pitti> Good morning
[06:01] <pitti> doko_: do you happen to have an idea about bug 1270025? i. e. is calling "dot -c" in postinst the right thing to do?
[06:03] <pitti> vila: FTR, I can reliably reproduce bug 1269886 locally; you can't?
[06:04] <darkxst> hey pitti
[06:05] <darkxst> would autopilot work with gnome-shell?
[06:07] <Noskcaj> darkxst, Should do. Check "autopilot launch gnome-shell"
[06:07] <Noskcaj> Since it's gtk3 it should introspect
[06:08] <darkxst> Noskcaj, gnome-shell doesnt really use standard gtk3 widgets though
[06:09] <Noskcaj> darkxst, good point. As long as it will launch without error via autopilot, it should work. It might be a bit more complex though
[06:11] <pitti> darkxst: yes, I don't see why not
[06:11] <pitti> Noskcaj: hey
[06:11] <Noskcaj> hey pitti
[06:11] <pitti> Noskcaj: wrt. the libgweather transition: don't worry; some bits were done yesterday, and the two remaining ones are new versions of evolution and evolution-data-server which are prepared (but blocked by the "don't change the phone" ban ATM)
[06:12] <Noskcaj> ok
[06:13] <darkxst> well It launches but getting a ton of unsupported type warnings
[06:14] <darkxst> although they seem to be standard GTK bits,
[06:14] <Noskcaj> darkxst, Provided it's nothing like Gtk-Message: Failed to load module "autopilot", you're good
[06:15] <pitti> darkxst: yes; that warning is already silenced in trunk, but it's been a while since we released AP
[06:15] <wolter> Is unity launcher api on topic in this channel?
[06:15] <pitti> darkxst: in fact we are trying to, currently held up by bug 1270025
[06:16] <pitti> darkxst: FTR, autopilot can only introspect simple property types (int, string, float, flags, enums, etc.); it has some special cases for GtkTextBuffer, but for properties of other class types it can't do introspection
[06:17] <pitti> darkxst: btw, if you need a particular property and there is a sensible way to represent it as a string, please file a bug against autopilot-gtk
[06:17] <darkxst> pitti, I really just want a test to make sure gnome-shell has loaded properly
[06:17] <pitti> darkxst: so I guess you just want to check that you can find a few representative widgets and ensure that they are visible?
[06:18] <darkxst> yes
[06:18] <pitti> you can also check their globalRect for plausible values
[06:18] <pitti> darkxst: does gnome-shell run in xvfb? (i. e. with software rendering)
[06:19] <pitti> darkxst: then this could become an autopkgtest, and we'd immediately know when it breaks due to a new upload
[06:19] <darkxst> it certainly runs with software rendering
[06:20] <darkxst> and yes that would be better, because once gnome-shell breaks, so does gdm ;(
[06:20] <pitti> darkxst: note you need to run xvfb like that: xvfb-run -s "-screen 0 1024x768x24" <program>
[06:20] <pitti> (without that it runs in 8bpp which doesn't work with rendering)
[06:21] <pitti> that's a common trap, in case you don't know
[06:21] <darkxst> pitti, that gives XRANR missing
[06:22] <darkxst> which makes gnome-shell unhappy
[06:22] <pitti> ah :/
[06:22] <pitti> darkxst: the other day there was a  patch floating on the upstream ML for adding xrandr support to Xvfb; but it seems it never got accepted :/
[06:22] <pitti> https://launchpad.net/~pitti/+archive/ppa/ still has an xorg-server package with that patch
[06:23] <pitti> but that was for raring
[06:23] <pitti> darkxst: X.org with the dummy driver does know xrandr, that might work better
[06:23] <darkxst> how do I run that?
[06:24] <pitti> darkxst: https://git.gnome.org/browse/gnome-settings-daemon/tree/tests/gsdtestcase.py#n202
[06:25] <pitti> darkxst: you can skip the copy part
[06:26] <pitti> $ Xorg -config xorg-dummy.conf -logfile /tmp/log :5
[06:26] <pitti> $ DISPLAY=:5 xrandr
[06:26] <pitti> Screen 0: minimum 320 x 240, current 1024 x 768, maximum 1024 x 768
[06:26] <pitti> darkxst: ^ something like that
[06:27] <pitti> the rest of that code just does the synchronization and error handling
[06:28] <pitti> tjaalton, mlankhorst, RAOF: would you happen to know anything about the fate of http://lists.x.org/archives/xorg-devel/2013-January/035114.html ? it works nicely, but it seems it got zero replies
[06:28] <pitti> (in a year)
[06:29] <RAOF> My guess: nobody X-ish cares enough about xvfb.
[06:29] <RAOF> Particularly since the dummy drivers exist.
[06:29] <pitti> yeah, see above, but it's two magnitudes harder to set up than xvfb-run
[06:30] <pitti> Xvfb is still the #1 tool to run tests during project and package build, or is there something better these days?
[06:31] <RAOF> pitti: Really, we should just add a wrapper script that implements xvfb-ish
[06:32] <RAOF> As a regular server + dummy conf.
[06:32] <pitti> RAOF: I guess that would look similar to above gsdtestcase.py function
[06:32] <RAOF> Note: Not volunteering to implement said server :)
[06:32] <pitti> I'm happy to do that, it's not particularly difficult
[06:33] <RAOF> Right.
[06:33] <pitti> but again, if it stays Debian/Ubuntu specific it's still not something you could put into upstream test suites
[06:33] <pitti> like in gnome-settings-daemon and the like
[06:34] <RAOF> Ideally you'd do it in something that you can do signals and fd passing in; if you pass in a fd X will write the display it's found and if you set SIGUSR1 to ignore the server will raise that once it's ready.
[06:35] <RAOF> That's something that could be either upstreamed to xorg or as a trivial extra project.
[06:35] <RAOF> It's probably just big enough to be a project you could get everyone to depend upon for their unittests :)
[06:35] <pitti> hm; all that instead of applying this rather small patch..
[06:36] <pitti> xvfb-run already implements all that logic, after all (and it's far from trivial)
[06:36] <RAOF> Mostly.
[06:36] <pitti> perhaps I should temporarily subscribe, and poke on the list for a review?
[06:37] <RAOF> Could work.
[06:39] <darkxst> hmm, xorg segfaulted when I launched xrandr ;(
[07:06] <wolter> Is there a complete Unity Launcher API somewhere?
[07:06] <wolter> I want to do a Pomodoro timer but I can't find stuff on connecting actions to dbusmenu items
[07:09] <pitti> doko_: ah no, the *.postinst/*.postrm scripts just weren't updated for libgvc5-config-update -> libgvc6-config-update, doing
[07:12] <tjaalton> pitti: yeah, I don't see why it couldn't be accepted upstream, and master is open again
[07:59] <vila> pitti: haven't tried reproducing locally yet, my hands are full :-( I strongly suspect this bug to be a test-only issue given the past similar test transient failures caused by that MP. I.e. I'm a bit afraid about spending time diagnosing more precisely and ending up with the same conclusion :-/ So if you have a way to just skip this test for the time being, that sounds like the most pragmatic thing to do
[08:03] <pitti> vila: bzr selftest has an -x, that should work?
[08:03] <vila> pitti: yup
[08:03] <vila> pitti: you can add that thanks to dep8 right ?
[08:04] <pitti> yes, in debian/tests/testsuite
[08:04] <vila> pitti: I dislike excluding tests instead of turning them into expected failures, but again, that's the most pragmatic here :-/
[08:05] <dholbach> good morning
[08:05] <pitti> vila: well, the next upload can't be done without fixing it, as the package will fail to build, so that's ok
[08:05] <pitti> hey dholbach
[08:05] <dholbach> hey pitti
[08:05] <vila> pitti: ionce I get to the point where I can add a trusty chroot to http://babune.ladeuil.net:24842/ it will show up again anyway
[08:05] <vila> pitti: so nothing will be lost
[08:05] <pitti> vila: ack, thanks
[08:10] <vila> pitti: FTR, it pisses me off to not be able to look at that more closely. On a more positive side, is there a way to have bazaar@lists.canonical.com mailed when such a failure happens ? (Don't worry about not being subscribed, I'll white list when it'll happen)
[08:11] <pitti> vila: hm, after I hit dput it occurred to me that this probalby won't work -- the test will fail during package build so that never gets into trusty; I'll have to ignore it during package build as well
[08:11] <pitti> vila: usually the last uploader gets mailed for them
[08:12] <pitti> plus jibel and me for all of them
[08:12] <pitti> we don't currently have a more flexible way of subscribing, sorry
[08:12] <vila> pitti: no idea who the uploader is this way, ha, too bad, never mind
[08:12] <pitti> vila: so for now I do the  "ping vila" approach if I see a failure :)
[08:12] <vila> s/way/day/
[08:12] <vila> pitti: ok ;-D
[08:14] <zyga> good morning
[08:15] <doko_> pitti, thanks
[08:16] <doko> slangasek, I assume the qt5 update will still take a while?
[08:24] <mlankhorst> morning
[09:45] <zyga> can anyone confirm that python3.3-coverage program from python3-coverage package crashes on import
[09:45] <darkxst> oh gah, what will happen with modemmanager 1.0 in -proprosed, pretty sure there are rdepends that are non-trivial to port to the new api;(
[09:49] <zyga> what?
[09:49] <zyga> barry, doko: is python3.4 the default python now?
[09:49] <seb128> doko, e-d-s failing to build ... you commented saying it uses hardening without the corresponding build-depends, but even with hardening-wrapper installed the configure hits the same "Error in `/usr/bin/ld.bfd.real': corrupted double-linked list"
[09:49] <zyga> python3-coverage has shebang of python3.4
[09:50] <doko> seb128, can you sbeattie how to properly build with hardening-wrapper and pie?  the problem is that configure calls gcc with -static -fpie
[09:51] <doko> in the past this did work by chance
[09:51] <seb128> sbeattie, hey
[09:51] <doko> zyga, you can answer this question yourself by building in a trusty chroot
[09:52] <zyga> doko: I am running trusty and I actually followed your test rebuild archive
[09:52] <zyga> doko: I'm trying to understand if this is a bug or is it expected
[09:53] <doko> zyga, depends on what the build-dependencies are. in general, we do not want to have version specific shebangs. python3 should it be
[09:53] <zyga> doko: python3 is still 3.3 for me, so it seems the coverage package is broken
[09:54] <zyga> doko: I think coverage might be a bit special there as you want to use specific coverage if invoked as specific pythonX.Y-coverage script, it just seems those scripts are generated incorrectly (or patched incorrectly, maybe)
[09:54] <zyga> (specific python version, not coverage version, sorry)
[09:54] <doko> zyga, I'll have a look later, or I'll ask barry to have a look
[10:24] <pitti> barry: would you mind looking into the mailman autopkgtest failures? there are a lot of failed tests (reproducible with run-adt-test locally, so it's not a DC/networking issue)
[10:33] <apachelogger> how do I find out why a package is being held in trusty-proposed?
[10:35] <Laney> apachelogger: https://wiki.ubuntu.com/ProposedMigration is useful
[10:35] <Laney> there's two links at the end of the first section which contain the output
[10:36] <apachelogger> thanks
[10:38] <doko> jamespage, b-d golang-go [amd64 armhf i386]
[10:38] <jamespage> doko, for juju-core? not just yet
[10:38] <doko> ?
[10:38] <doko> it's dep-wait on the other archs ...
[10:39] <jamespage> doko, yes - and it will continue to be until I have done the work to package a separate go tool for use with gccgo
[10:39] <doko> ahh, ok
[10:39] <jamespage> doko, davecheney has something working from mainline golang with gccgo - once he's happy with that I'll package and upload
[10:40] <jamespage> doko, for now I'm building with both for existing archs so people can test it out and compare/contrast
[14:15] <barry> pitti: i can look
[14:15] <barry> zyga: what's up?
[14:19] <zyga> barry: hey
[14:19] <zyga> barry: I think python3-coverage is busted
[14:19] <zyga> barry: first off, python3-coverage is running python3.4
[14:19] <zyga> barry: then python3.3-coverage throws ImportError that is really odd
[14:20] <zyga> barry: this is on 3.7+dfsg.1-4
[14:20] <barry> zyga: yep, looks like they are.  can you file bugs and send me the #s
[14:20] <zyga> barry: certainly, filing now
[14:25] <zyga> barry: https://bugs.launchpad.net/ubuntu/+source/python-coverage/+bug/1270167
[14:26] <seb128> cjwatson, hey, what determines if the grub menu should be open on boot (out of the grub config)? (I guess it writes a file somewhere that is cleaned after a successful boot to do the "open on next boot in the previous boot didnt work")
[14:26] <seb128> cjwatson, I'm asking because playing with your new grub I managed to land in a position where it displays the menu at every boot now
[14:26] <barry> zyga: subscribed.  i'll double check on debian - i'm in regular contact with the maintainer
[14:27] <cjwatson> seb128: right, it sets a flag using save_env before booting, which is cleared by /etc/init.d/grub-common when we get to the end of rc2
[14:27] <cjwatson> using grub-editenv
[14:27] <seb128> cjwatson, the only thing I did is to hammer ctrl/shift to open the menu and ctrl-alt-suppr some of the boots on plymouth beause I didn't manage to open the menu
[14:27] <cjwatson> seb128: check whether /etc/init.d/grub-common is actually being called at boot
[14:28] <seb128> what's the easiest way to see that? logs?
[14:28] <cjwatson> hack it to write to some file of your choice
[14:28] <zyga> barry: https://bugs.launchpad.net/ubuntu/+source/python-coverage/+bug/1270168
[14:28] <zyga> barry: thanks a lot
[14:28] <seb128> ok
[14:29] <zyga> barry: looks like some of the multi-version magic went wrong, I read the debian packaging but it was pretty comples for what is otherwise setup.py install
[14:29] <zyga> complex
[14:29] <seb128> cjwatson, otherwise, if that's me pressing shift that leads to open the menu, I think that it opens with the 10s timeout on manual trigger when it used to open without timeout
[14:29] <seb128> cjwatson, or my testing/setup might just be buggy
[14:29] <cjwatson> seb128: you might also try "grub-editenv /boot/grub/grubenv list" after boot to see what that says
[14:29] <seb128> cjwatson, on the good news side, boots works fine, as do recovery mode etc (my setup is a "boring" 1 disk, 1 OS, no uefi though)
[14:30] <seb128> $ grub-editenv /boot/grub/grubenv list
[14:30] <seb128> $
[14:30] <cjwatson> seb128: timeout handling has changed around a bit, I may have to double-check that.  wouldn't be a blocker though
[14:30] <cjwatson> seb128: pastebin /boot/grub/grub.cfg?
[14:31] <seb128> cjwatson, http://paste.ubuntu.com/6768202/
[14:31] <zyga> stgraber: hey, pastebinit *stilL* uses /usr/bin/env python shebang, it will still be broken in every python3 virtualenv :-(
[14:32] <cjwatson> seb128: and /etc/default/grub please?
[14:32] <seb128> cjwatson, http://paste.ubuntu.com/6768212/
[14:36] <cjwatson> seb128: Hmm, looks like 569766e4 broke this
[14:36] <cjwatson> seb128: Could you mention this in the bug?  I'll have to try to chase this down upstream
[14:39] <seb128> cjwatson, done, I'm not sure what details are useful but I guess you will fill those?
[14:40] <seb128> cjwatson, let me know if you need more debug infos from my system
[14:40] <cjwatson> Nope, I basically just need to think very hard about the timeout stuff, again
[14:52] <barry> 5ols
[14:53] <seb128> cjwatson, was your "commit id creating the issue" comment about the 10s timeout on manual opening or about the menu opening on boot?
[14:53] <seb128> cjwatson, the grub-common script is correctly called and it seems the flag is not set from a "list" call, so I guess the menu is opening for another reason (doesn't happen anymore after downgrading to the trusty version)
[14:56] <seb128> on that note, time for some exercice, be back in 1h
[15:07] <cjwatson> seb128: they're the same thing
[15:33] <cjwatson> seb128: (Looking at it, I think I'm not quite correct in blaming upstream - the upstream change is trying to preserve previous upstream behaviour, and I dropped a little bit too much of the Ubuntu patch set)
[15:40] <stgraber> zyga: I'm pretty sure the release I made yesterday uses /usr/bin/python3
[15:41] <zyga> stgraber: ah, sorry then, it's probably not on my development box yet
[15:42] <stgraber> zyga: yeah, I don't take care of the packaging myself, I'm just the upstream for that one. I notified the Debian maintainer but it hasn't been uploaded yet.
[16:34] <cjwatson> seb128: OK, figured it out, fixed for the next upload
[16:34] <seb128> cjwatson, great, thank you!
[16:36] <cjwatson> thanks for the testing
[16:47] <brendand> doko, my packages build is failing seemingly because python3.4 is in py3versions, but python3.4 is not there
[16:47] <brendand> doko, in trusty
[16:47] <doko> brendand, is the package b-d on the python3-all / python3-all-dev package?
[16:48] <brendand> doko, no - python3 (>= 3.2),
[16:48] <doko> brendand, which package?
[16:49] <brendand> doko, it's checkbox-certification. it's only in a PPA
[16:49] <brendand> doko, so it should b-d on python3-all?
[16:50] <doko> brendand, yes
[16:52] <rbasak> chiluk: please could you see if bug 1270151 is a possible -proposed regression on mysql-server-5.5 5.5.34-0ubuntu0.12.04.2, or just user error?
[16:52] <chiluk> rbasak ... sure
[16:54] <chiluk> rbasak doesn't look like it.
[16:54] <rbasak> chiluk: thanks. Often users misconfigure mysql and then apport files postinst failure bugs because the service doesn't start. So it could be that. I just noticed that it's from -proposed.
[16:54] <chiluk> I'll verify the upload now though.
[16:54] <rbasak> Thanks!
[16:55] <chiluk> rbasak, sure thing... I was pretty careful with that upload... so I don't have much faith that this is a regression.
[16:55] <cjwatson> Grr.  Why does https://launchpad.net/ubuntu/+source/ruby-gettext/3.0.3-2/+build/5470350 fail but https://launchpad.net/~cjwatson/+archive/ppa/+build/5473079 (identical build in a PPA, identical set of build-dependencies installed, same version of launchpad-buildd) succeed?
[16:55] <cjwatson> Kernels differ but the chances of that affecting locale-ish tests seem fairly remote
[16:55] <cjwatson> I guess I can try hitting it with LC_ALL=C.UTF-8 but I'm a bit reluctant to do that without some way to reproduce the problem
[16:57] <cjwatson> Maybe if I try a devirt PPA ...
[17:06] <chiluk> rbasak I was able to install 12.04.1 and upgrade to 12.04.2 without issue.
[17:06] <rbasak> chiluk: thank you for verifying, and for doing the work!
[17:07] <chiluk> rbasak it is entirely possible that he does not have enough free disk space
[17:07] <chiluk> and the post script is failing due to the new check for free space.
[17:07] <chiluk> rbasak.. I also don't speek french.. so I'm not entirely sure what the error messages are saying.
[17:08] <rbasak> chiluk: it's a postinst failure.
[17:08] <rbasak> chiluk: postinst returned error status 1
[17:08] <chiluk> rbasak.. I gathered that much.. I was more curious what MySQLConf.etc.mysql.my.cnf: Error: [Errno 2] Aucun fichier ou dossier de ce type: '/etc/mysql/my.cnf'
[17:08] <chiluk>  means
[17:09] <rbasak> Oh
[17:09] <rbasak> Hmm
[17:09] <tarpman> chiluk: no such file or directory
[17:09] <chiluk> well there's your problem.
[17:09] <tarpman> ENOENT
[17:09] <rbasak> OK so that's the user.
[17:09] <rbasak> Thanks
[17:09]  * rbasak learns a little more French
[17:10] <chiluk> I wouldn't expect it to function before the upgrade either.
[17:10] <rbasak> That seems likely. I just wanted to be sure. That makes it clear, and I'm now confident it's not a regression. Thanks!
[17:10] <chiluk> Google translate = "Any file or folder of this type:"  ... not as helpful
[17:11] <rbasak> (and thanks tarpman)
[17:11] <tarpman> :)
[17:11] <rbasak> Usually I guess the translations but I didn't spot that one.
[17:12] <infinity> cjwatson: devirts are far more likely to have, as some point, had lp-buildd restarted or upgraded by hand, rather than started by init.
[17:12] <infinity> cjwatson: Which leads to the locale environment leak issue you fixed in bzr but we haven't rolled out.
[17:12] <cjwatson> Yeah, I was half-thinking that
[17:12] <cjwatson> The failure reproduces in a devirt PPA
[17:13] <cjwatson> So I should maybe just try to get that lp-buildd rolled out early next week rather than bothering with an upload.
[17:13] <infinity> cjwatson: Well, I think a package that fails its testsuite due to locale issues is still buggy.
[17:13] <infinity> cjwatson: It's nice for buildds to provide a consistently sane environemnt, but that's no excuse for shoddy packaging either. :P
[17:14] <infinity> (And easy enough to test locally by just building in C, C.UTF-8 and en_US.UTF-8 and seeing what explodes)
[17:14] <cjwatson> I'd be more worried about that if the failure reproduced with sbuild locally
[17:14] <cjwatson> But let's try it if I force LC_ALL=C
[17:15] <infinity> I'd be inclined to test locally in a chroot I can control and know the state of, rather than throwing random hammers at buildds who's environment I'm guessing at.
[17:15] <infinity> whose*
[17:16] <cjwatson> I'm only throwing random hammers out of desperation at being unable to reproduce the failure locally
[17:16] <infinity> I ran into one of these a while back that was confusing as all heck to track down.
[17:16] <infinity> cjwatson: I bet I can reproduce.  Lemme look.
[17:16] <cjwatson> That's obviously where I started
[17:16] <cjwatson> OK.  Note that you need to have a bootstrap ruby-gettext in the chroot
[17:16] <cjwatson> (Or available via apt sources)
[17:16] <infinity> Check.  The one from your PPA should do, I guess.
[17:18] <cjwatson> Yeah, or the one from Debian
[17:24] <infinity> cjwatson: Okay, I apologize for questioning your science.  Not only can I not reproduce, but I'm officially confused.
[17:29] <cjwatson> infinity: I wonder what lp-buildd's env on the builders in question actually says
[17:30] <infinity> Throw something at a devirt with "printenv" and "locale" in debian/rules, and aim it at toyol, so we're debugging the same machine?
[17:31] <cjwatson> Or I could ask a webop
[17:31] <infinity> Well, that doesn't get you the env during a package build.
[17:32] <cjwatson> Finding the env of lp-buildd would probably do
[17:32] <infinity> Probably.
[17:32] <stgraber> infinity: pushing procenv to that buildd should do the trick
[17:33] <cjwatson> Let me do that quickly then
[17:34] <infinity> Already done.
[17:34] <cjwatson> k
[17:34] <infinity> Well, once process-upload hears me.
[17:35] <cjwatson> Copies are usually a bit quicker :)
[17:35] <infinity> Yeah, I wasn't thinking.
[17:39] <infinity> https://launchpad.net/~adconrad/+archive/ppa/+build/5473272
[17:40] <infinity> And in case i386ness matters:
[17:40] <infinity> https://launchpad.net/~adconrad/+archive/ppa/+build/5473275
[17:44] <infinity> Hrm, and can't reproduce when mirroring that env either.
[17:44] <infinity> Double-U Tee Eff.
[17:46] <cjwatson> infinity: I can
[17:46] <cjwatson> -       dh_auto_install
[17:46] <cjwatson> +       LANG=C LANGUAGE=en_GB: LC_ALL=C dh_auto_install
[17:46] <cjwatson> reproduces it in sbuild
[17:46] <infinity> cjwatson: Huh.  Didn't seem to break it here when I just set that in my chroot env.  But yay.
[17:47] <infinity> Oh.  Balls.  My science was probably crap.
[17:47] <infinity> I used debuild, which I bet cleanses.
[17:49] <cjwatson> changing LC_ALL to C.UTF-8 is indeed sufficient
[17:49] <infinity> cjwatson: Or unsetting LANGUAGE would probably also do.
[17:50] <cjwatson> Still fails one test if I do that
[17:50] <infinity> Fun.
[17:51]  * cjwatson uploads, let's see
[18:05] <infinity> cjwatson: It would appear that you don't win.
[18:05] <cjwatson> https://launchpad.net/ubuntu/+source/ruby-gettext/3.0.3-2ubuntu1/+build/5473400  argh
[18:05] <cjwatson> I give up, it's dinnertime anyway.  Feel free to continue beating on it if you get a chance ...
[20:06] <jtaylor> can one force push scipy out of proposed?
[20:06] <jtaylor> its a minor test failure, and a new upstream release is due in a few days where I will skip it
[20:06] <jtaylor> but py3.4 scipy helps for rdepends
[20:07] <jtaylor> oh wait builds are against proposed anyway
[20:07] <jtaylor> so nevermind, didn'T think about that
[20:30] <hallyn> all right this sandbox-upgrade-testing script is getting on my nerves.  It's killing my nested kvm with copying host to destination...
[22:16] <infinity> cjwatson: ruby-gettext hammer applied and forwarded to Debian.