[03:07] <micahg> arges: as commented in the bug, just reverse dependency install/run testing for precise and oneiric as well as install/run testing for the whois backport itself, thanks
[03:15] <infinity> cjwatson: Oh, that pi state may be a feature of the old sbuild, come to think of it.  Totally didn't think of that when I saw the grep ^ii
[03:15] <infinity> cjwatson: Yay verbosity. ;)
[03:55] <tjaalton> hallyn: excellent, thanks
[05:31] <StevenK> RAOF: xvfb-run makes me sad
[05:32] <RAOF> Whyso?
[05:32] <StevenK> jenkins@lptests-temp-k0hHY4M:~$ xvfb-run bash
[05:32] <StevenK> xvfb-run: error: Xvfb failed to start
[05:32] <StevenK> Some helpful information would be nice
[05:40] <RAOF> StevenK: Fair call.
[05:41] <RAOF> --error-file might help you.
[05:44] <StevenK> Fatal server error:
[05:44] <StevenK> Can't read lock file /tmp/.X99-lock
[05:44] <StevenK> That is roughly as helpful. :-)
[05:58] <RAOF> Whee!
[05:58] <RAOF> Yeah, that's not awesome.
[10:21] <Daviey> seb128: Are you able to provide a debian/watch for geary?
[10:22] <seb128> Daviey, I guess yes
[10:22] <Daviey> (currently, i cannot validate the orig src tarball)
[10:22] <seb128> Daviey, the tarball is coming from http://www.yorba.org/download/geary/0.2/geary-0.2.0.tar.xz
[10:23] <Daviey> seb128: ok, rejected this.. Can you add a watch file, and re-upload please?
[10:23] <seb128> sure
[10:24] <Daviey> seb128: (everything else looks good, will accept then)
[10:24] <seb128> Daviey, is that a new thing requiring a watch file? ;-) just curious, it feels weird :p
[10:25] <cjwatson> MIRs strongly suggest it; archive acceptance doesn't generally
[10:25] <Daviey> seb128: jdstrand was mostly the driver for this.  It's not a firm requirement but a best practice that AA's seem to be pushign for.  If a watch file isn't viable, then a debian/rules get-orig-source (or packaged-source) or a debian/Readme.source explaining how it was created.
[10:25] <cjwatson> the MIR team is pushing for it, not AAs
[10:26] <cjwatson> it wouldn't be practical to enforce something like that over the whole archive
[10:26] <Daviey> well, considering the complexity of most watch files.. I don't think it is a bad idea
[10:26] <cjwatson> I think many things are a good idea but wouldn't reject for their absence
[10:26] <Daviey> Note, i did ask if it was viable before rejecting
[10:26] <cjwatson> "accept with suggestions" is usually a better workflow
[10:30] <Riddell> what's the script to copy packages between PPAs?
[10:31] <cjwatson> copy-package
[10:31] <cjwatson> (in ubuntu-archive-tools)
[10:31] <seb128> Daviey, reuploaded with a watch ;-)
[10:32] <seb128> Daviey, should be in the queue in 3 minutes or so (next run)
[10:36] <Riddell> oh yes, I was trying ubuntu-dev-tools
[10:46] <mpt> ev, mvo introduced the recoverable errors on Sep 22. So it might explain a bit of the difference between 12.04 and Q, but probably not much of it.
[10:46] <ev> mpt: noted, cheers
[10:46] <mpt> ev, actually, Aug 22.
[10:46] <mpt> hm, so maybe it does explain much of it
[10:46] <ev> I've laid the groundwork for the like for like comparisons in RT 56497
[11:04] <pitti> zyga: apport crash in binary mode> if you are absolutely sure it's really the same bug, please reopen; otherwise, just file a new one
[11:04] <pitti> ev: py3-debian seems fine to me
[11:04] <ev> pitti: cheers
[11:04] <pitti> zyga, ev: (on holiday today)
[11:18] <darkxst> anyone able to sponsor my casper patches for ubuntu gnome remix?
[11:18] <darkxst> https://code.launchpad.net/~darkxst/casper/ubuntu-gnome-casper-tweaks/+merge/127634
[11:19] <cjwatson> stgraber: ^-
[11:22] <zyga> pitti: thanks
[11:53] <mdeslaur> @pilot in
[12:49] <jdstrand> cjwatson, seb128, Daviey: I have been pushing for a watch file as an AA where practical (eg, certainly not native packages). a watch file is gives us the only glimmer of a possibility to be able to do an integrity check of the archive
[12:49] <jdstrand> (systematically)
[12:50] <cjwatson> There's still no point in rejecting on it because Debian doesn't
[12:50] <cjwatson> Offer advice, certainly
[12:50] <seb128> jdstrand, hey, ok, fair enough, it's just something that wasn't flagged as important on my checklist until today, but that makes sense
[12:50] <jdstrand> I don't think I've ever rejecting on that reason alone
[12:50] <jdstrand> rejected
[12:50] <cjwatson> Right.  Daviey did
[12:51] <cjwatson> I guess what I'm saying is that having inconsistent standards based on non-agreed whims of individual AAs makes it unnecessarily difficult for uploaders
[12:51] <Daviey> I didn't just reject out of hand, I did check if it was reasonable to do first.
[12:51] <jdstrand> I might file a bug-- certainly give advice. I'd even phrase it as one of a list of things that needed to be fixed before being accepted
[12:51] <cjwatson> I wouldn't have rejected even after checking that it was reasonable to add the watch file.
[12:51] <cjwatson> I'd have let the uploader add it in a subsequent upload.
[12:51] <jdstrand> actually, we discussed this before
[12:52] <jdstrand> I forget if it was at a rally/sprint or a uds (not a session)
[12:52] <cjwatson> It came up at a rally in the context of MIRs only
[12:52] <jdstrand> right
[12:52] <jdstrand> ah, that was the other bit-- main only
[12:52] <cjwatson> Look, I'm not objecting to people trying to improve the archive
[12:52] <jdstrand> but I wasn't a mir reviewer at the time
[12:53] <jdstrand> I was pushing it as an aa
[12:53] <cjwatson> I'm just saying that archive rejections are an awfully heavy tool for doing so
[12:53] <Daviey> I know that I've been unsuccessful in getting debian sponsorship for NEW without a watch file on two occasions, but that is sponsors etiquette rather than polciy.
[12:53] <cjwatson> Sponsors can and should be stricter than the base requirements for archive acceptance
[12:54] <jdstrand> I would agree with that-- I also wouldn't nak something that went through Debian NEW (I would file a bug there). I do strongly encourage new Ubuntu uploads to have one though
[12:54] <cjwatson> I mean, a sponsor might reasonably ask you to fix typos in your package description, but it'd be ridiculous to reject for that
[12:54] <jdstrand> let me rephrase: I wouldn't nak something that went through Debian NEW based on lack of a watch file alone
[12:55]  * jdstrand nods
[12:55] <Daviey> I do like to check that what is in orig, is the true orig whilst reviewing.  Without one of the ways to get the source it does make life harder.  Considering the simplicity in most cases of writing a watch file, it also seems wise to promote it as a best pratice.
[12:55] <cjwatson> Lack of best practice != reject
[12:55] <cjwatson> That's all I'm saying
[12:55] <Daviey> If the consensus is different, then ok, i won;t do that
[12:55] <cjwatson> Otherwise I'd reject a LOT more and I don't think that would actually help
[12:55] <cjwatson> It would just reduce velocity and piss people off
[12:56] <jdstrand> Daviey: I whole-heartedly agree with checking the orig.tar.gz-- I have found cases where they were different (not ever malicious, but still)
[12:56] <jdstrand> I also agree that if other nakable things are wrong, listing the watch file as a requirement is ok. if it is only the watch file, a bug seems fine
[12:56] <jdstrand> eg, maybe treat it like lintian warnings
[12:57] <jdstrand> nakable-- that looks funny :)
[12:57] <cjwatson> We should probably have a fork of http://ftp-master.debian.org/REJECT-FAQ.html
[12:58] <jdstrand> yeah
[12:58] <jdstrand> I added it to my todo list
[12:58] <Daviey> cjwatson: Do you think a UDS session for this makes sense?  More of a standardisation healthcheck?
[12:59] <cjwatson> It's probably the kind of thing that would work better by e-mail
[12:59]  * jdstrand doesn't think it needs a session
[12:59] <jdstrand> cjwatson: +1
[13:00] <jdstrand> so, while I've added it to my todo list, there is a fairly good chance I will not get to it super-soon
[13:00] <Daviey> bah, these sort of threads rarely end in consensus IMO :).. but ok
[13:00] <jdstrand> (there is a good deal of understatement there ;)
[13:00] <cjwatson> Artificial consensus by doing it in a room while nobody's watching doesn't count :-)
[13:00] <cjwatson> If a session, it should at most be an exercise for gathering suggestions that form the agenda for a thread
[13:00] <cjwatson> IMO
[13:00] <jdstrand> Daviey: actually, I've had the opposite experience with ubuntu-archive
[13:01] <Daviey> Okay, i'll shuddup.
[13:01] <jdstrand> heh. I don't think that is quite what I said :P
[13:01] <jdstrand> but if it works...
[13:01] <jdstrand> ;)
[13:01] <Daviey> heh
[13:01]  * jdstrand hugs Daviey 
[13:03] <jdstrand> Daviey: seriously though, thanks for the careful reviews and bringing this up. it will (eventually) end up as something good for the team
[13:04] <Daviey> jdstrand: well, i certainly agree with the need for standardisation.  I know i found it frustrating when i was a newcomer.
[13:05]  * jdstrand nods
[13:08] <cjwatson> argh.  you know what annoys me?  build systems that don't stop on error
[13:08]  * cjwatson finds the real error message a few hundred lines back
[13:10] <Daviey> well, that is what confused me about bug 1052056, apparently it doesn't fail on error jdstrand ?
[13:11] <Daviey> (roaksox was looking to resolve that, i've not looked into it)
[13:11] <stgraber> darkxst, cjwatson: I'll take a look. I'm planning to spend some more time on casper today trying to reduce the bug count a bit.
[13:12] <cjwatson> Daviey: You mean the compiler warnings?
[13:13] <Daviey> cjwatson: roaksoax/doko made it sound like it wasn't reasonably failing on error.
[13:13] <jdstrand> Daviey: are you referring to the compiler warnings? those don't fail the build unless you build with -Werror
[13:14] <Daviey> http://irclogs.ubuntu.com/2012/10/02/%23ubuntu-server.html#t14:49
[13:14] <cjwatson> I don't see any warnings in https://launchpadlibrarian.net/108137937/buildlog_ubuntu-quantal-i386.freeipmi_1.1.5-3_BUILDING.txt.gz
[13:14] <cjwatson> Er, any errors, I mean
[13:15] <cjwatson> Right, I disagree that those warnings should fail the build
[13:15] <cjwatson> -Werror is a good thing for upstreams to use during development; it's highly questionable at a distribution scale
[13:15] <Daviey> I suspect it's misscommunication, jdstrand wanted the Warnings looked at.. and it was interrupted wrongly.
[13:15]  * jdstrand nods
[13:16] <cjwatson> And doko wasn't talking about the build system there, anyway; he was suggesting behaviour of the C code
[13:16] <jdstrand> doko summarized it pretty clearly in his initial response, fwiw
[13:16] <jdstrand> well, to me anyway, cause I knew what I wanted :)
[13:16] <Daviey> 3 way failure :).. i see that now, i've bothered looking at the warning :)
[13:17] <stgraber> darkxst: posted a comment about some problems in your MP
[13:17] <cjwatson> warn_unused_result is often worth fixing but has a fair few false positives too
[13:17] <cjwatson> And unfortunately there's been a bit of an arms race on how to silence it, so what seems like an obvious (void) cast doesn't actually work
[13:32] <herton> @pilot in
[13:38] <cjwatson> seb128: Hopefully upstream will respond quickly enough, but do you think we could pull in the fix for https://bugzilla.gnome.org/show_bug.cgi?id=685388 ?  Recent regression, not sure how many packages it affects ...
[13:42] <seb128> cjwatson, I've pinged David & lool for review but the patch looks fine to me so feel free to upload that to quantal
[13:43] <seb128> cjwatson, or I can backport it if you want
[13:44] <cjwatson> I'll upload it then, thanks
[13:44] <cjwatson> obscure bugs unearthed by +1 maint for the win
[13:45] <seb128> cjwatson, thanks for tracking it down ;-)
[13:46] <cjwatson> Any Ubuntu VCS for gnome-common?
[13:46] <seb128> cjwatson, no
[13:47] <cjwatson> OK
[13:47] <seb128> we avoid Vcses for easy packages that are often in sync with debian (which is the case of this one) since they get outdated when we do direct syncs
[13:48] <cjwatson> Fair enough
[13:54] <darkxst> stgraber, thanks, I have fixed it now
[13:59] <stgraber> darkxst: looks good, merging it now
[14:00] <stgraber> darkxst: hmm, one last thing actually, don't you need to run glib-compile-schemas after you change an override?
[14:01] <stgraber> darkxst: if so, you probably should move your .override change to 22desktop_settings where we already have code to change overrides and run a compile-schemas a single time
[14:02] <darkxst> stgraber, yes need compile schemas
[14:04] <stgraber> darkxst: ok, can you move that bit over to 22desktop_settings then?
[14:05] <darkxst> stgraber, yeh
[14:14] <darkxst> stgraber, done..
[14:19] <stgraber> darkxst: thanks. Merged. Will be uploaded later today.
[14:21] <rbasak> Is there a way to get apt-file to search d-i contents, or perhaps some other way to achieve the same thing?
[14:22] <rbasak> Right now I'm trying to find out how d-i reboots to debug a d-i rebooting problem. I've found finish-install, debian-installer-utils and rootskel. Ultimately it seems that I'm looking for reboot in the path, but I haven't found it yet
[14:23] <darkxst> stgraber, thanks
[14:24] <darkxst> jbicha, casper changes are merged
[14:31] <jbicha> cool, thanks darkxst & stgraber
[14:34] <mpt> ev, I just reported bug 1060989 because I could reproduce it reliably, but I think it's been happening for months
[14:36] <cjwatson> rbasak: finish-install/finish-install.d/99reboot -> /lib/debian-installer/exit which is in rootskel/src/lib/debian-installer/exit-linux
[14:37] <rbasak> cjwatson: thanks - but then exit-linux calls "reboot". On my system that's linked to upstart, but I presume not in d-i?
[14:37] <rbasak> cjwatson: and I was a bit surprised to find that busybox doesn't appear to provide one
[14:38] <cjwatson> $ dpkg -c /mirror/ubuntu/pool/main/b/busybox/busybox-udeb_1.19.3-7ubuntu1_i386.udeb | grep reboot
[14:38] <cjwatson> lrwxrwxrwx root/root         0 2012-05-01 06:10 ./sbin/reboot -> /bin/busybox
[14:39] <cjwatson> The busybox deb configuration isn't the same as the udeb configuration
[14:39] <rbasak> ah, ok
[14:40] <rbasak> Oddly, upstream's docs at http://busybox.net/downloads/BusyBox.html doesn't list reboot as a command either
[14:40] <rbasak> thanks!
[14:40] <cjwatson> I suspect that's not especially up to date
[14:41] <rbasak> especially?
[14:41]  * rbasak wonders how long busybox has supported reboot :-)
[14:42] <ogra_> it definitely has shutdown for a long time
[14:42] <cjwatson> Mm, but that page is generated
[14:42] <cjwatson> It probably depends on the configuration used in the relevant build ...
[14:42] <rbasak> From a busybox build that misses out reboot I'm guessing? :)
[14:43] <cjwatson> Presumably - that would be fairly normal if it's in use on a system with some other reboot
[14:43] <cjwatson> Dunno really
[14:43] <cjwatson> I wouldn't bother using that page for anything :)
[14:44] <lool> cjwatson: Yup, looks good; looking back at this 2007 patch I can see how I got it wrong back then, thanks for fixing
[14:46] <smoser> ok. i have a apparently stupid upstart question
[14:47] <smoser> upstart job : http://paste.ubuntu.com/1258106/
[14:54] <smoser> ok. better explained/demonstrated http://paste.ubuntu.com/1258126/
[14:54] <smoser> why does my upstart job not get respawned?
[14:55] <smoser> GAH
[14:56] <smoser> need 'respawn' by itself.
[14:56] <smoser> i was confused by "Default COUNT is 10. Default INTERVAL is 5 seconds."
[15:06] <mitya57> Hi ev (again)
[15:06] <mitya57> I've been added to bug-control, but errors.u.c shows me:
[15:06] <mitya57> OpenID failed OpenID authentication failed: Invalid openid.mode: '<No mode set>'
[15:06] <mitya57> Should I wait some time or is it a bug?
[15:08] <mitya57> Hm, this works for another report
[15:09] <mitya57> Ah, it works now, ignore all that :)
[15:09] <ev> :)
[15:09] <ev> mpt: cheers
[15:42] <mterry> ev, how does one associate a bug with an errors.ubuntu.com entry?
[15:43] <ev> mterry: click on the "Create" link on errors.ubuntu.com
[15:44] <mterry> ev, huh, don't see it.  Maybe I'm not in a group I would need to be
[15:44] <ev> mterry: does the problem start with "failed:"?
[15:44] <mterry> ev, no
[15:44] <ev> which one is it?
[15:45] <mterry> https://errors.ubuntu.com/bucket/?id=%2Fusr%2Flib%2Funity-scope-video-remote%2Funity-scope-video-remote%3AGError%3A%3Cmodule%3E%3Amain%3Afunction
[15:45] <mterry> ev, ^
[15:46] <ev> mterry: https://bugs.launchpad.net/ubuntu/+source/unity-scope-video-remote/+bug/1061038
[15:46] <ev> the Create links only appear on the front page
[15:46] <ev> but we should show them on the problem pages as well
[15:46] <mterry> ev, I was looking at bug 950862 too
[15:46] <ev> filing a bug for this now
[15:46] <mterry> ev, I don't see it on the front page either
[15:47] <ev> https://bugs.launchpad.net/errors/+bug/1061041
[15:48] <mterry> ev, OK, so two problems then: I don't see the create link on the front page and I want to be able to link a report and a bug, not create a new one
[15:48] <ev> mterry: so the plan for dealing with already existing bugs is still evovling
[15:48] <ev> evolving*
[15:48] <mterry> ev, ok
[15:48] <mterry> ev, oh now
[15:49] <ev> mterry: oh, and you wont see the create link on the front page unless you're logged in
[15:49] <ev> sorry about that
[15:49] <mterry> ev, aha.  I see them now, I'm an idiot
[15:49] <ev> mind is a bit mush as we're near the end of the day
[15:49] <ev> no, entirely my fault there
[15:49] <ev> it's confusing
[15:49] <mterry> ev, I had launchpad=false in the URL.  ahem
[15:49] <ev> that would do it as well :)
[15:50] <ev> launchpad=false isn't necessary anymore by the way
[15:50] <ev> it asynchronously loads the data from launchpad now
[15:50] <mterry> ev, yeah, seems snappier
[15:51] <mterry> ev, OK, so best way to link to an existing bug for someone like me seems to be to intentionally create a dup, then mark it as such.
[15:52] <mterry> ev, though then the page doesn't "follow the link" of the dup and use appropriate strikethrough or highlighting
[15:52] <ev> mpt: ^ remind me, did you have any thoughts on what the interface should look like for linking to an existing bug
[15:52] <ev> just "[create ] [ link ]" maybe?
[15:53] <mpt> ev, not really, except that it should look more different to a bug number than it does now :-)
[15:53] <mpt> (a chain icon? A "+" symbol?)
[15:53] <mpt> (or maybe both, one for Create and the other for Link)
[15:53] <ev> okay
[15:54] <ev> https://bugs.launchpad.net/errors/+bug/1061049
[16:30] <mdeslaur> @pilot out
[16:37] <Darxus> Is there a bzr branch containing the source for the released gtk packages anywhere?  An lp: branch of https://launchpad.net/ubuntu/+source/gtk+3.0/3.6.0-0ubuntu2 is exactly what I'm looking for, but I don't see it there.  Trying to do an automated daily build.
[16:38] <micahg> Darxus: should be lp:ubuntu/gtk+3.0
[16:39] <Darxus> micahg: That seems reasonable, but looks out of date.  Last update is in August, and there have been a bunch of releases since:  https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/gtk+3.0/quantal
[16:39] <micahg> lp:ubuntu/quantal-proposed/gtk+3.0 ATM
[16:39]  * micahg wonders if it's a UDD bug
[16:39] <mitya57> Darxus: also lp:~ubuntu-desktop/gtk/ubuntugtk3
[16:39] <mitya57> (debian-dir-only)
[16:40] <micahg> the desktop branch might be better
[16:41] <Darxus> Yeah, I know about the ubuntu-dekstop branch, but still need the upstream source.
[16:42] <Darxus> micahg: lp:ubuntu/quantal-proposed/gtk+3.0 also hasn't been updated since 2012-08-22.
[16:42] <micahg> Darxus: http://package-import.ubuntu.com/status/gtk+3.0.html#2012-09-06%2020:27:25.211657
[16:44] <Darxus> micahg: So lp:ubuntu/gtk+3.0 *should* have it, but the import is broken?
[16:44] <micahg> seems like it
[16:44] <Darxus> Thanks.
[16:45] <Darxus> Just like when I wanted to use the same stuff for spamassassin.  That was exactly what I was looking forward to / remembered, thanks.
[17:21] <infinity> soren: *pokity poke*
[17:21] <infinity> soren: Your qemu-kvm/precise upload for bug 997978 was superseded by a security upload with the same version.  Could you re-base and re-upload?
[17:22] <infinity> soren: And while you're at it, fix the LP: #1234 ref in the changelog so it actually lands in .changes (you missed the # character last time)
[17:23] <infinity> ubottu: I hate you so much right now.
[17:27] <Darxus> Heh.
[17:34] <zyga> hi
[17:34] <zyga> I need some help
[17:34] <zyga> on quantal current
[17:34] <zyga> both my machines are borked on boot
[17:34] <zyga> not getting to lightdm
[17:35] <zyga> lightdm itself works
[17:35] <zyga> but my screen is blank black on (fglrx/radon hd5450) and black+console text (gma500)
[17:36] <zyga> I have no idea what is crashing
[17:36] <zyga> X is not
[17:36] <zyga> as on fglrx/desktop I can run X alone and see cursors working
[17:36] <zyga> I suspected lightdm or unity greeter
[17:36] <zyga> but I don't knwo how to debug those
[17:36] <zyga> any hjnts please?
[17:38] <sarnold> zyga: do you have ssh? is there anything interesting in /var/log ?
[17:39] <zyga> I'm logged in to both macines via console
[17:39] <zyga> syslog, not much, let me re-check
[17:40] <zyga> ok, watching syslog now, I'll restart lightdm
[17:40] <sarnold> zyga: how about /var/log/Xorg.0.log?
[17:40] <sarnold> (or the other displays...)
[17:40] <sarnold> any EE lines? WW lines?
[17:40] <zyga> syslog -- nothing acpid and backlight noise
[17:40] <zyga> checking x
[17:41] <zyga> upon starting I briefly switch to vt7
[17:41] <zyga> then screen goes blank and reverts to vt7
[17:41] <zyga> in text mode
[17:41] <zyga> sarnold: it ends with 'server terminated sucessfully'
[17:42] <zyga> sarnold: I'm not sure how this part of boot works
[17:42] <dobey> is there any where to see an overview of package sets in ubuntu, showing the status of all the packages in that set?
[17:42] <micahg> dobey: define status?
[17:42] <sarnold> zyga: hrm, maybe your session starts, dies, and then X quits as it expects a short session to do?
[17:43] <zyga> ok
[17:43] <zyga> what gets started?
[17:43] <zyga> can I check any config files
[17:43] <zyga> and run it myself?
[17:43] <dobey> micahg: currently accepted versions in ubuntu at least would be a good start. unapproved queue and all would be nice too of course
[17:43] <sarnold> zyga: how about ~/.xsession-errors ?
[17:43] <zyga> is that still managed with xsession?
[17:43] <dobey> zyga: on the gma500, switch to vt1, log in, service lightdm restart
[17:44] <zyga> dobey: it does not help, I'm using this gma500 daily and it was working just fine
[17:44] <dobey> zyga: my gma500 laptop does the same thing since precise. and on it lightdm seems to show on only half of the screen until i restart it
[17:44] <zyga> dobey: on quantal it actually got usable :)
[17:44] <infinity> dobey: I know of no such report.
[17:44] <zyga> sarnold: so, gnome-panel crashes
[17:44] <dobey> zyga: i just upgraded to quantal on that machine, and no change. does the same thing for me :)
[17:44] <dobey> infinity: ok, thanks
[17:44] <zyga> actually there's a lot of errors there
[17:45] <zyga> I need to have a look
[17:45] <micahg> dobey: something like this? https://launchpad.net/ubuntu/quantal/+uniquepackages?field.name_filter=&field.package_type=all&field.package_type-empty-marker=1&field.packageset=146 (
[17:45] <micahg> dobey: that's ubuntu specific packages though
[17:45] <cjwatson> sigh, webkit/armel failed again
[17:46] <cjwatson> Laney: ^0
[17:46] <zyga> dobey: which machine do you have?
[17:46] <dobey> zyga: fujitsu u820
[17:47] <dobey> micahg: something like that, yeah. would be nice to have that work on all series too, and not just one at a time; but it's a start :)
[17:47] <zyga> dobey: hmm, I don't know that model, I'm using second gen vaio-p
[17:47] <dobey> zyga: it's not a common laptop. it's a 5.6" ultra-portable :)
[17:49] <zyga> dobey: I'll have to look it up, neither is mine, it's rather cool form-factor wise :)
[17:49] <dobey> yeah, just remembered the P is the 1600x900 weird one
[17:49]  * zyga uses an ipad to browse the web while some packages get downloaded 
[17:49] <dobey> err, 1600x800 even
[17:49] <zyga> 1900x768 IIRC
[17:49] <zyga> er
[17:49] <zyga> 1600x768
[17:50] <dobey> the one that looks like a wallet :)
[17:50] <micahg> slangasek: are you uploading all the metas or just ubuntu desktop for the pam-xdg support?
[17:51] <slangasek> micahg: was only uploading ubuntu-meta; I don't know what else other teams might have staged
[17:51] <micahg> ok, thanks
[17:54] <infinity> cjwatson: I think this is now down to trying to debug why the buildds hate us, rather than fiddling more and more with packaging.
[17:55] <infinity> cjwatson: I need to try to reproduce this locally, probably, since puppetting GSA through endless procfs tweaks to test in production sounds like it would get annoying to both of us pretty quickly.
[18:06] <Laney> Bah, yeah, probably for the best.
[18:28] <bryceh> is there a comprehensive listing of all the .deb's present on the precise ubuntu desktop image?
[18:30] <micahg> bryceh: manifest file?
[18:30] <micahg> wait, debs?
[18:31] <bryceh> micahg, well, the question is what packages are included in a generic ubuntu install as of 12.04.1
[18:31] <micahg> hrm, do an install then grab dpkg -l?
[18:32] <micahg> the manifest has what's in the squashfs AIUI
[18:32] <micahg> but that's not the same as installed
[18:35] <xnox> bryceh: and it depends on the installation type: langpacks, detected hardware, whether network was available and install updates was ticked as well as whether third-party proprietary was ticked.
[20:17] <cjwatson> infinity: OTOH I see qt4-x11 finally managed to build
[20:17] <infinity> cjwatson: Yeah, via magic or sheer luck.
[20:17] <infinity> cjwatson: I think that was the second try for both arches.
[20:18] <ScottK> I think armel went in one try, but I'm not sure.
[20:25] <Laney> pretty sure it did
[20:25] <barry> dobey: ping, re: bug 711162.  is this really a bug in dbus-python or can i remove the dbus-python bug task?
[20:27] <infinity> ScottK: Right, looking at the build timestamps, looks like armel went in one go, armhf took two.  So, sort of progress, but not really. :P
[20:27] <ScottK> A win is a win.
[20:27] <infinity> (At least it's built for now)
[20:27] <ScottK> But yeay, it could be better.
[20:27] <infinity> ScottK: Yeah, it's only a win from my perspective if we can reproducibly build the thing. :/
[20:29] <dobey> barry: i think it should probably be considered a bug in it. dbus should know the expected signature for the method being called already, and should be able to coerce an empty dict to match the method's signature. at least, that's how i'd expect the dbus API to work
[20:30] <dobey> barry: we've worked around it in u1 for now, but it might come up again in the future elsewhere. but it's your call if you want to drop dbus-python from that
[20:31] <barry> dobey: cool.  let me see if i can boil it down into something reportable upstream.  i'll leave the bug task alone for now
[20:38] <ScottK> infinity: Do you have an ETA in -proposed for the redo of your eglibc SRU?
[20:39] <infinity> ScottK: Today.
[20:39] <ScottK> Thanks.
[20:42] <barry> dobey: on further examination, i'm going to remove the bug task.  this isn't a bug in dbus, it's a deliberate refusal to guess when not enough information is available.  e.g. this comment:
[20:43] <barry> /* No items, so fail. Or should we guess "a{vv}"? */
[20:43] <barry> dobey: so, i suppose it would be a wishlist to do that guess, or an upstream bug in the documentation that signatures of empty dicts cannot be introspected.
[20:46] <dobey> barry: well i wouldn't say it guesses. it introspects the signature from the method being called, is my understanding. but i'm not going to bother arguing with upstream about it. like i said, do what you will. :)
[20:47] <barry> dobey: right, but in the case of empty dicts, introspection doesn't provide enough information to know the mapping.  so the refusal to guess is pythonically zen :)
[20:49] <dobey> barry: no, i don't mean introspecting from the caller. i mean introspecting from the server side. ie, it already knows the expected signature is ia{ss} or whatever for example. it could then coerce {} to be {"", ""} or just send whatever an acceptable equivalent is to mean empty. of course, if dbus has no way to send empy values at all, that's another issue.
[20:49] <dobey> but again, not a huge deal
[20:49] <dobey> just really annoying
[20:49] <barry> dobey: cool
[21:16] <Daviey> mdeslaur: dbus doesn't run it's test suite at build time?
[21:21] <mdeslaur> Daviey: I don't believe they work on the buildds, they require X and a bunch of stuff IIRC
[21:28] <Daviey> mdeslaur: ahh
[21:29] <mdeslaur> Daviey: I haven't looked closely at it though