[00:49] <slangasek> cjwatson: hmm, so adt-run is not working as I'm expecting... adt-virt-schroot is refusing to do anything sensible with Restrictions: needs-root, do you have any idea about this? http://paste.ubuntu.com/7036025/
[01:16] <psusi> what the heck runs udisksd?  it doesn't seem to be an upstart or rc job
[01:19] <hallyn> Daviey: bdmurray: since the full libvirt 1.1.1 maint tree seems to scare people, I've uploaded a new saucy libvirt for SRU with a small subset of the patches.  Please reject the older 1.1.1-0ubuntu8.6 and accept the newer
[01:27] <slangasek> psusi: dbus
[01:29] <psusi> slangasek, in response to what and how does it know to do that?  and is there a way to get it to log the output?
[01:30] <psusi> /etc/dbus-1/system.d/org.freedesktop.Udisks2.conf doesn't seem to mention an executable or anything
[01:31] <psusi> ahh, there it is... /usr/share/dbus-1-system-services
[01:31] <slangasek> yep, that'll be it :)
[01:32] <psusi> so is there a way to get it to log the debug output, and... isn't it wrong to have that activate on demand?  It is supposed to set system policies like standby timers that should be done at boot, whether or not a dbus client calls on udisks
[01:33] <psusi> and why doesn't it remain a child of the dbus process?
[01:41] <ahoneybun_> so the 2012 nexus 7 is no longer being worked on?
[02:23] <infinity> doko: I CCed you on a glibc bug that appears to (maybe) be a GCC bug, based on jtaylor's investigation.
=== robert_ancell_ is now known as robert_ancell
[06:02] <pitti> Good morning
[07:03] <happyaron> cjwatson: ibus-pinyin-db-android is still there, while ibus-pinyin-db-open-phrase is gone. the latter does not have reverse-depdens.
[07:23] <Noskcaj> Can someone please check http://metadata.ftp-master.debian.org/changelogs/main/t/tiff/unstable_changelog ? Is it a worthwhile sync?
[07:39] <dholbach> good morning
[07:39] <aswininm> very good morning:)
[07:42] <pitti> RAOF: hey Chris, how are you? thanks for your umockdev work!
[07:42] <pitti> RAOF: do you want to work on other things, or should I do a 0.7 release now?
[07:43] <RAOF> That's a good question.
[07:45] <RAOF> pitti: I think I'm good for the moment. :)
[07:51] <pitti> RAOF: ok; do you want/need a release now?
[07:52] <RAOF> Yes please.
[08:04] <pitti> RAOF: done, and uploaded to sid; will sync this evening when it's imported
=== rpadovani is now known as WebbyIT
=== RAOF_ is now known as RAOF
[08:36] <Noskcaj> pitti, Is there anything in particular you want me to do before you change your comment on https://wiki.ubuntu.com/Noskcaj#MOTU ?
[08:37] <Noskcaj> I'm hoping to be able to run for MOTU again this month or next, depending on if i can get the relevant testimonies.
[08:48] <pitti> Noskcaj: I guess I just need to review/sponsor more from you :)
[08:48] <Noskcaj> well sponsor queue is at 60 packages. But you've sponsored more of my packages since the testimonial
[08:59] <Noskcaj> A sync of libsigc++-2.0 might be worthwhile. I haven't got time to properly test build tonight though
[08:59] <Noskcaj> g'night
=== soren_ is now known as soren
[09:11] <seb128> just for info the desktop iso build fails because of
[09:11] <seb128> http://launchpadlibrarian.net/168350693/webbrowser-app_0.23%2B14.04.20140219-0ubuntu1_0.23%2B14.04.20140304-0ubuntu1.diff.gz
[09:11] <seb128> that made webbrowser-app depends on some universe binaries
[09:11] <seb128> that's being worked on (likely to lead to a revert)
[09:13] <Laney> umm
[09:16] <xnox> hallyn: what's up? which changes by xnox in the archive =)?!
[09:36] <cjwatson> slangasek: adt-virt-schroot only offers the root-on-testbed capability if your username is in root-users or one of your groups is in root-groups in the schroot config for it
[09:38] <cjwatson> happyaron: No, ibus-pinyin-db-android is no longer built by ibus-pinyin.  See https://launchpadlibrarian.net/167756163/ibus-pinyin_1.4.0-2ubuntu3_1.5.0-1ubuntu1.diff.gz where you can quite clearly see it being removed
[09:38] <cjwatson> happyaron: If you mean that was a mistake, OK, please revert the relevant bit then :-)
[09:39] <tjaalton> uh, so I have union-overlay-directory set to a tmpfs, but sbuild still builds pkgs on the hd
[09:39] <tjaalton> what am I missing?
[09:41] <tjaalton> only the chroot is copied to the overlay
[09:42] <tjaalton> or such
[09:43] <tjaalton> /var/lib/sbuild/build then
[09:47] <tjaalton> that was it
=== herb_ is now known as herb
=== ogra_` is now known as ogra
=== WebbyIT is now known as rpadovani
[10:55] <mapreri> pitti: autopkg test is funny: I run the tests 5 times, and I obtain 5 different results :S
[10:55] <pitti> mapreri: you mean sometimes it starts up and sometimes not?
[10:56] <pitti> mapreri: could very well be a bug in the test as well that it doesn't properly wait for the startup, etc.
[10:59] <mapreri> pitti: could you re-run the tests on jenkins? I'm curios... anyway, also in debian the tests fails: http://ci.debian.net/#package/varnish
[11:00] <pitti> mapreri: ran it again
[11:01] <pitti> mapreri: but it was really stable until the previous version, see history on https://jenkins.qa.ubuntu.com/job/trusty-adt-varnish/
=== wgrant_ is now known as wgrant
[11:03] <mapreri> I see
[11:03] <pitti> mapreri: run 31 done, also failed (but with slightly different results indeed)
[11:08] <pitti> mapreri: debian/tests/ changed significantly in 3.0.5-1 indeed
[11:09] <pitti> mapreri: I suppose debian/tests/run-tests needs some code to wait for varnish to actually start up (with some reasonable timeout); right now the package gets installed, and apparently the postinst finishes before the daemon is fully running?
[11:11] <mapreri> pitti: maybe. I should do some tests.
[11:14] <mapreri> pitti: all the tests were completely rewritten. I'm new to this tests, let me understand what they really do, I'll ping you when I have results.
[11:14] <pitti> mapreri: great, thanks! yeah, I don't know them either, I'm afraid; I don't even know what varnish is or does so far :)
[11:15] <mapreri> :)
=== MacSlow is now known as MacSlow|lunch
=== dcmorton_ is now known as dcmorton
=== Trevinho__ is now known as Trevinho
=== mnepton is now known as mneptok
=== ValicekB_ is now known as ValicekB
=== Sweetsha1k is now known as Sweetshark
=== _salem is now known as salem_
[12:16] <pitti> jodh: oh, your pbuilder update collided with slangasek's
[12:17] <pitti> jodh: reopened the MP, can you please merge? your version is better I think
[12:19] <kilian> hi
[12:19] <kilian> is there any official statement where apt-cache show takes its knowledge about Supported: and Origin: from?
[12:20] <kilian> I've tried to find any notion of these two in the official packaging guides but failed
[12:20] <kilian> looks like these values appear just right out of nowhere :-?
[12:25] <geser> kilian: apt knows it from the package lists (/var/lib/apt/lists/*) and those lists are generated by the archive part of LP
=== tkamppeter_ is now known as tkamppeter
[12:36] <xnox> kilian: indeed they are generated by LP at archive publication/generation. Please note that Supported fields are at the moment are not correct for trusty* suites, and there are discussions around what they should be and a merge proposal against launchpad to correct them.
[12:43] <kilian> geser: I guess I could override that entry with a simple line in debian/control then?
[12:43] <kilian> geser: for a local archive
[12:44] <kilian> xnox: thanks for the explanation.. is there any URL where to read up on this?
[12:45] <xnox> kilian: no, you shouldn't add it to debian/control.
[12:45] <xnox> kilian: depending on how you generate your archive, you should be using archive-overrides to add extra fields.
[12:46] <kilian> xnox: I can't really see anything in apt-ftparchive .. so where would I be adding that?
[12:46] <xnox> kilian: e.g. apt-ftparchive supports override files.
[12:46] <xnox> kilian: read $ man apt-ftparchive, look for "override"
[12:47] <kilian> xnox: ok, will check that.. thanks
[12:47] <xnox> kilian: but why would you want/need those fields? they are not-required, and are meaningless, unless /you/ attach a meaning to them.
[12:47] <kilian> ..which is exactly what I want to look at for a purely local repo and a local server farm
[12:48] <kilian> i.e. pull that into monitoring and shut up the moaning about missing entries for my private packages
[12:48] <kilian> xnox: or asked around the other way.. is there any frontend tool that I could use to ask my system which packages are out of support for an LTS release?
[12:48] <xnox> kilian: it's invalid to require/mandate those fields, as none of the Debian packages / Debian archives have them.
[12:48] <kilian> in some sort of an easy approach?
[12:49] <kilian> xnox: I know
[12:49] <xnox> kilian: yeah, i believe there is a tool for that.
[12:49] <kilian> cool, what's its name? ;-)
[12:50] <cjwatson> ubuntu-support-status
[12:51] <kilian> cjwatson: thanks. and that's part of which package?
[12:51] <xnox> yeah that =) couldn't remember / find it.
[12:51] <cjwatson> kilian: update-manager-core
[12:52] <kilian> excellent. thanks!
=== smoser` is now known as smoser
=== achiang` is now known as achiang
=== MacSlow|lunch is now known as MacSlow
=== Snow-Man_ is now known as Snow-Man
[13:34] <jodh> pitti: done, thanks.
[13:41] <pitti> jodh: and uploaded, take II :)
[13:41] <pitti> thanks
=== josepht_ is now known as josepht
=== Pici` is now known as Pici
[14:18] <pitti> superm1: is dell-recovery still actually being used?
=== barry` is now known as barry
[14:20] <superm1> pitti: yep
[14:20] <pitti> superm1: thanks
[14:20] <superm1> sure.  been busy with other stuff so haven't had much time to look at it with regard to 14.04 though
[14:20] <pitti> superm1: I'm reviewing the remaining rdepends of udisks 1, so including it in bug 1288253
[14:20] <ubottu> bug 1288253 in dell-recovery (Ubuntu) "Eliminate udisks 1 from Ubuntu" [High,Triaged] https://launchpad.net/bugs/1288253
[14:21] <superm1> ick, so that'll be some work to transition then
[14:33] <pitti> jodh: "Jenkins Fixed - trusty-adt-pbuilder-ppc64el 4" \o/
[14:34] <jodh> pitti: yay! :)
[14:34] <Laney> do we still have migrates-when-autopkgtests-fail bugs?
[14:35] <pitti> Laney: yes, we do
[14:36] <pitti> Laney: we now have some britney tests which reproduce some bugs (https://code.launchpad.net/~canonical-platform-qa/britney/tests/+merge/207982)
[14:36] <pitti> Laney: and I started to look into britney to fix some bugs (started with https://code.launchpad.net/~pitti/britney/britney2-autopkgtest-fixes/+merge/208657)
[14:37] <Laney> pitti: ah, I thought that stuff was in, thanks for the pointers
[14:38] <Laney> Don't know if this particular problem is covered there, mind
[14:40] <cjwatson> I'm reviewing it now
[14:41] <pitti> Laney: no, it's probably not; we found several other cases where things can (and probably do) go haywire in adt-britney; jibel is rewriting and greatly simplifying those, with tests
[14:45] <Laney> OK
[14:45] <Laney> Not that I'm complaining in this instance since it means I don't have to fix all of the ubuntuone tests ;-)
[14:45] <pitti> Laney: which package are you looking at/
[14:46] <pitti> ?
[14:46] <Laney> pitti: ubuntuone-sso-client
[14:46] <Laney> I think it triggered -control-panel and -client, which failed
[14:50] <cjwatson> pitti: I think invalidate_dep is the wrong method to call here; it will result in some redundant "Depends: ..." output in the excuses with a broken link, which I don't think adds anything over the existing "unsatisfiable Depends:" output.  Normally invalidate_dep is called much later and I don't think it makes sense to drag it in here.
[14:50] <cjwatson> pitti: Can I suggest http://paste.ubuntu.com/7038848/ on top of your commit as an alternative implementation of this?
[14:50] <cjwatson> pitti: It'd be worth running through the tests of course
[14:51] <cjwatson> pitti: sorry, that's not on top of yours, that's against current production
[14:51] <pitti> cjwatson: oh, thanks; I don't really have a "feeling" how britney should work yet
[14:51] <pitti> cjwatson: ack
[14:51] <cjwatson> pitti: it is twisty.  I'd apologise for it except most of it isn't mine :-)
[14:52] <pitti> cjwatson: ah, so the excuse.invalidate_dep(block_txt.strip()) (which was kind of the gist of it) was ok?
[14:53] <cjwatson> pitti: well, no, I pulled that out and did it differently by returning a value from excuse_unsat_deps
[14:53] <cjwatson> pitti: I think I forgot a bit though, let me recheck
[14:53] <pitti> cjwatson: hm, the test still fails with that patch
[14:54] <cjwatson> pitti: http://paste.ubuntu.com/7038873/ should be better
[14:54] <cjwatson> I wasn't actually using the return value properly :)
[14:55] <cjwatson> the second-to-last hunk there is the most important bit
[14:56] <pitti> Does not request a test for an uninstallable package ... ok
[14:56] <pitti> cjwatson: yay, that does it
[14:57] <pitti> cjwatson: does the test run for you?
[14:57] <cjwatson> pitti: can you try without the last hunk of that (run_autopkgtest = False in invalidate_excuses), which I've just noticed is pointless as it's called too late?
[14:58] <cjwatson> pitti: how do I run it?
[14:58] <pitti> $ tests/autopkgtest.py
[14:58] <pitti> I needed to create a britneymodule.so -> lib/britneymodule.so symlink
[14:58] <pitti> otherwise britney doesn't work
[14:59] <pitti> cjwatson: still works without the last hunk, yes
[15:00] <cjwatson> It passes that test here, but I get other failures, http://paste.ubuntu.com/7038900/
[15:00] <cjwatson> known?
[15:00] <lamont> was it a conscious decision to make gnome terminals come up as 79x21 instead of 80x24?
[15:00] <pitti> cjwatson: yes, these are other bugs that I found
[15:01] <pitti> cjwatson: the first three reproduce the gccgo-4.9 issue that we had
[15:01] <lamont> on the bright side, they've stopped extending below the bottom of the screen
[15:01] <pitti> cjwatson: the last one is not very important, I just stumbled over it when writing those
[15:02] <cjwatson> ok, well anyway, I'll apply this diff and merge the combination
[15:02]  * cjwatson dumps this conversation into the MP
[15:02] <pitti> cjwatson: I kept the MPs separate as you may not like the tests in its current form, while the fix might be valid; or vice versa, which is what happened now
[15:04] <pitti> cjwatson: I can also look into the gccgo-4.9 problem (no tests run if new source takes over existing binary), I just needed today to do the usual post-holiday catch up
[15:04] <pitti> cjwatson: back in 20 mins
[15:04] <cjwatson> Yeah, I'm mostly working on click at the moment but ...
[15:04] <cjwatson> pitti: OK, merged, should be effective as of the next p-m run
[15:04] <cjwatson> thanks!
[15:05] <hallyn> xnox: you'd made a change to vm-builder (in january) to convert to dh-python2.  I did the next upload based on the lp:~vmbuilder-dev/vmbuilder/packaging tree which didn't have that.
[15:06] <hallyn> xnox: (i reintroduced your changes;  should have checked archive first)
[15:12] <cjwatson> pitti: Looks *almost* right in production except that it's not quite doing the right thing for single-arch unsat deps - let me fix that
[15:12] <cjwatson> That's just an idiot mistake from me
[15:12] <cjwatson> (fixed)
[15:14] <cjwatson> zul: there's a dependency typo in manila that's preventing it migrating to trusty, FYI - s/pyhon/python/
[15:15] <zul> cjwatson: ack ill fix it
[15:15] <cjwatson> ta
[15:16] <cjwatson> zul: also tempest, I think Depends: python-prb should be python-pbr to match Build-Depends?
[15:16] <zul> cjwatson: right :(
[15:16] <cjwatson> zul: in fact there's already a python-pbr in Depends as well, maybe it's just a duplicate
[15:17] <zul> ok ill have a look
[15:24] <Laney> can I help to moderate ubuntu-devel?
[15:30] <cjwatson> That sounds like a fine idea, it could use more people with a bit of time
[15:55] <seb128> hum
[15:55] <seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-control-center
[15:55] <seb128> unity-control-center (14.04.3+14.04.20140303-0ubuntu1 to 14.04.3+14.04.20140305.1-0ubuntu1)
[15:55] <seb128>     Maintainer: Ubuntu Desktop Team
[15:55] <seb128>     0 days old
[15:55] <seb128>     Not considered"
[15:56] <seb128> why is it not considered?
[15:56] <seb128> shouldn't there be a reason in that snippet?
[15:56] <smoser> anyone else seeing this ? i just dist-upgraded (last one was maybe yesterday) and rebooted (last one was long ago).
[15:56] <smoser> and now 'vi myfile.<tab>' does not tab complete!
[15:59] <smoser> hm.. and now its working.
[15:59] <smoser> very odd.
[15:59] <seb128> smoser, no such issue here
[15:59] <smoser> must be luser error.
[16:00] <smoser> ugh. i'm pretty sure something changed. it must be selectively completing now.
[16:02] <smoser> hm.. it seems its busted ~/ resolution
[16:08] <smoser> seb128, just fyi ^ https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1288314
[16:08] <ubottu> Launchpad bug 1288314 in bash (Ubuntu) "bash completion broken with '~' expansion" [Undecided,New]
[16:11] <smoser> jodh, around ?
[16:11] <jodh> smoser: yo
[16:11] <smoser> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1284164
[16:11] <ubottu> Launchpad bug 1284164 in upstart (Ubuntu) "~/.cache/upstart grows enormous" [Undecided,New]
[16:11] <smoser> i thought you'd suggested / implied that my dbus.log would be truncated on log out and log in
[16:11] <smoser> is that not true?
[16:12] <jodh> smoser: on login, yes.
[16:12] <smoser> well, it is not true (as i've just done that and still have ~ 400M :)
[16:12] <jodh> smoser: what happens when you run "start logrotate" as your user?
[16:12] <smoser> $ start logrotate
[16:12] <smoser> logrotate start/running, process 9556
[16:12] <smoser> still big fat dbus.log
[16:12] <cjwatson> seb128: there should, wonder if that's a regression from my/pitti's work today
[16:13] <smoser> jodh, where does that job live ?
[16:13] <jodh> smoser: so the log hasn't been compressed? If not, logrotate is likely not installed or in the PATH.
[16:13] <jodh> smoser: /usr/share/upstart/sessions/logrotate.conf
[16:14] <smoser> $ dpkg-query --show logrotate
[16:14] <smoser> logrotate	3.8.7-1ubuntu1
[16:14] <smoser> $ which logrotate
[16:14] <smoser> /usr/sbin/logrotate
[16:14] <jodh> smoser: cat ~/.cache/upstart/logrotate.log ?
[16:14] <smoser> $ file ~/.cache/upstart/dbus.log
[16:14] <smoser> /home/smoser/.cache/upstart/dbus.log: ASCII text, with very long lines, with CRLF line terminators, with escape sequences
[16:15] <smoser> error: bad top line in state file /home/smoser/.cache/logrotate/status
[16:15] <smoser> (64 lines like that)
[16:15] <jodh> smoser: maybe delete that status file then?
[16:15] <smoser> i'd say so :)
[16:16] <smoser> nice:
[16:16] <smoser> $ ls -l /home/smoser/.cache/logrotate/status
[16:16] <smoser> -rw-r--r-- 1 smoser smoser 385 May 31  2013 /home/smoser/.cache/logrotate/status
[16:16] <smoser>  file /home/smoser/.cache/logrotate/status
[16:16] <smoser> /home/smoser/.cache/logrotate/status: data
[16:16] <seb128> cjwatson, should I open a bug about that somewhere?
[16:16] <smoser> ie, file doens' tknow what that thing is.
[16:16] <cjwatson> seb128: no, it's ok, I'm looking into it now
[16:16] <seb128> cjwatson, thanks
[16:17] <smoser> jodh, removal of that file and then running it again does get logrotate happy.
[16:17] <seb128> gar, ctrl-R on the wrong screen
[16:17] <jodh> smoser: bug in logrotate then maybe?
[16:17] <smoser> maybe, yeah
[16:18] <jodh> xnox, slangasek: would be good to get lp:~jamesodhunt/ubuntu/trusty/upstart/periodic-logrotate reviewed. I'd call that a bugfix :)
[16:22] <slangasek> cjwatson: isn't this a bug in adt-virt-schroot?  Shouldn't it know that if I'm running as uid=0, then the root-on-testbed capability is there?
[16:23] <slangasek> jodh: ack
[16:26] <nemo> So. I was rather surprised that the ubuntu maintained package, libumfpack5.4.0 had no -dev package
[16:26] <nemo> is that normal?
[16:26] <nemo> (was trying to build the colorize plugin for gimp)
[16:27] <slangasek> nemo: the corresponding -dev package is libsuitesparse-dev, found by 'apt-cache showsrc libumfpack5.4.0 | grep Binary'
[16:28] <cjwatson> slangasek: Possibly; does schroot have a bypass in its logic for uid=0?
[16:28] <cjwatson> i.e. can you do schroot -c thingy -u root?
[16:28] <cjwatson> I thought that root had to be in root-users for that
[16:28] <slangasek> cjwatson: I'm not set up to do schroot -c thingy -u root - but if I'm already root, why would it need to be -u root?
[16:29] <nemo> slangasek: ah. TIL. thanks.
[16:29] <slangasek> cjwatson: more to the point, the manpage actually says "If your user is not allowed to do that, you need to run adt-run as root instead"
[16:29] <cjwatson> well, whatever, my point is that schroot is doing its own access control which isn't necessarily aligned with what unix would normally say
[16:29] <nemo> slangasek: never encountered that before.
[16:29] <slangasek> cjwatson: except it's *not* doing any access control here :)
[16:29] <cjwatson> anyway, if adt-virt-schroot doesn't line up with what schroot permits, then indeed that would be an adt-virt-schroot bug
[16:30] <slangasek> if you're root, you get to run the command, and you get root inside the chroot, EOT
[16:30] <cjwatson> it's still up to schroot whether it lets you
[16:31] <cjwatson> but it is true that it does
[16:42] <cjwatson> seb128: should be fixed, I made a mistake affecting binaries with empty Depends
[16:44] <seb128> cjwatson, k, thanks for fixing it!
[16:50] <roaksoax> slangasek: howdy! Do you have some time to review this FFe? https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1281881
[16:50] <ubottu> Launchpad bug 1281881 in maas (Ubuntu) "[FFe] Standing FFe for 14.04 features" [Critical,New]
[16:53] <slangasek> roaksoax: not at the moment... ask #ubuntu-release?
[16:54] <roaksoax> will do thanks
[17:01] <slangasek> pitti: so per the above discussion, I have a patch for adt-virt-schroot to make it DTRT when run as root... How do you prefer this submitted?  BTS?
=== dbarth_ is now known as dbarth-onair
[17:21] <quadrispro> hello everybody
[17:36] <smoser> is there any existing tools for listing all packages available?
[17:37] <smoser> rmadison doesn't seem to want me to give it '--regex=.*'
[17:37] <smoser> i'm guessing i can use python-apt to reasonably easily do what i want, but figure there might be something already.
[17:39] <slangasek> smoser: grep Package: /var/lib/apt/lists/*Packages?  I don't think there's a tool
=== tyhicks` is now known as tyhicks
[17:41] <Laney> `grep-aptavail -ns Package .'?
[17:49] <StevenK> grep-dctrl ?
=== dbarth-onair is now known as dbarth
[18:04] <smoser> can i rely on 'Filename' having 'universe' or 'multiverse' in it to be correct ?
[18:04] <smoser> wrt grep-aptavail ?
[18:09] <sarnold> apt-cache pkgnames ?
[18:10] <sarnold> smoser: apt-cache madison <foo> knows main/universe/multiverse
[18:11] <smoser> yeah i was just hoping to get it from one place.
[18:16] <xnox> slangasek: tkamppeter: i have fixed cups with socket activation. Not uploading now, as i have to run to volleyball. Will test up and upload into the archive late tonight or tomorrow.
[18:31] <tkamppeter> xnox, great, thanks.
=== Logan_ is now known as Logan-
[18:46] <seb128> jamespage: hey, do you still plan to look at https://bugs.launchpad.net/ubuntu/precise/+source/iscsitarget/+bug/1262712?
[18:46] <ubottu> Launchpad bug 1262712 in iscsitarget (Ubuntu Precise) "[SRU] Backport iscsitarget 1.4.20.3+svn490 into Precise" [High,Triaged]
[18:46] <jamespage> seb128, I do and I've sucked at looking at it so far
[18:47] <seb128> jamespage: thanks, just checking because it's the older item in the sponsoring queue
[18:47] <jamespage> seb128, I think the approach is just fine; but I wanted to test it out myself before final ack which I've not found time todo yet
[18:47] <seb128> no worry, if it's still on your todolist at least it's not lost ;-)
=== Logan- is now known as Logan_
=== FJKong is now known as FJKong_afk
[20:08] <mapreri> pitti: I can't reproduce the issue -.- I also write a short pbuilder hook (http://goo.gl/exXIbN) to call adt after the build, but the tests now are always successful :S
[20:09] <mapreri> what do you suggest to try now? I'm very new to autopkgtest, maybe I'm missing something...
=== jtaylor_ is now known as jtaylor
=== salem_ is now known as _salem
=== rww_ is now known as rww
=== _salem is now known as salem_
=== bfiller is now known as bfiller_afk
=== hggdh_ is now known as hggdh
=== salem_ is now known as _salem
=== juliank0 is now known as juliank
=== bradm1 is now known as bradm
[23:27] <slangasek> cjwatson: archaeology time :)  do you know if there's still a reason for the laptop-detect package to be seeded?  It seemed to be wanted in support of xresprobe, which is no longer seeded at all