[01:16] <Kano> where is the shim package?
[05:05] <pitti> Good morning
[05:17] <pitti> infinity, RAOF: Can we release bug 1055944 now?
[05:18] <pitti> RAOF: I'm happy to do the package copies myself, but wanted to coordinate with an SRU team member first
[05:43] <pitti> RAOF, infinity: I'd appreciate if postgresql-8.4/precise could also be accepted (bug 1058218) as this breaks lucid->precise upgrades
[06:26] <dholbach> good morning
[06:37]  * pitti hugs dholbach, guten Morgen
[06:37]  * dholbach hugs pitti back :)
[07:30] <infinity> pitti: It's on my hitlist first thing in the morning if no one beats me to it.
[07:30] <pitti> infinity: cheers
[07:56] <xnox> Guten Morget!
[07:56] <xnox> Guten Morgen!
[07:56]  * xnox fail
[08:08] <astraljava> fails*
[08:08] <gema> x)
[08:24] <xnox> =(
[08:24]  * xnox needs more coffee =)
[08:30] <geser> any idea how to resolve the current situation around "ntfsprogs"? it's currently build by ntfs-3g (main) and linux-ntfs (universe). "ntfsprogs" from ntfs-3g is a transitional package but dropped in the latest upload in Debian (not merged yet) and "ntfsprogs" from linux-ntfs has a lower version.
[08:30] <geser> drop "ntfsprogs" in ntfs-3g and add an epoch to linux-ntfs or wait till the r-series? or something else?
[08:31] <xnox> geser: and ntfsprogs from linux-ntfs does not have an epoch?
[08:31] <geser> xnox: no
[08:31] <xnox> =(
[08:31]  * xnox is inclined to wait for r-series
[08:32] <geser> I found this when I uploaded a FTBFS fix for linux-ntfs which is now "Failed to upload" due to this
[08:32] <cjwatson> geser: I'll fix it up shortly.
[08:32] <cjwatson> xnox: I'm not.  This is a +1 maintenance issue.
[08:33] <xnox> ok.
[08:34] <cjwatson> We should possibly just remove linux-ntfs.
[08:35] <cjwatson> Though I'll need to check whether ntfs-3g really supersedes all of it.
[08:38] <geser> partclone and testdisk depend/build-depend on libntfs10/libntfs-dev from linux-ntfs
[08:40] <cjwatson> ntfs-3g provides the tools, but not the library.
[08:41] <cjwatson> So maybe we should drop the ntfsprogs/ntfsprogs-udeb binaries.
[08:43] <geser> ntfs-3g has also a library. perhaps check if testdisk/partclone can be build against them? (or build them without libntfs)
[08:45] <cjwatson> I'll check, but I'm doubtful.  I suspect the APIs are quite different.
[08:46] <Laney> "The disk drive for / is not ready yet or not present" but it is mounted when I drop to a shell?
[08:46]  * xnox has the same with /tmp for some reason.... and I am confused how can /tmp be missing....
[08:46] <xnox> on my machine /tmp is not a separate mount point =/
[08:48] <Laney> heh
[08:48] <Laney> I don't know how to get it to boot given this
[08:48] <cjwatson> testdisk appears to have ntfs-3g support
[08:51] <geser> partclone too, I'll test-build both with ntfs-3g
[08:51] <cjwatson> I'm test-building testdisk at the moment
[08:51] <cjwatson> Go ahead with partclone :-)
[08:52] <cjwatson> Laney: You might want to alert slangasek given his recent mountall work.
[08:52] <Laney> cjwatson: ah, good clue
[08:52] <Laney> I'll try downgrading that
[08:56] <cjwatson> geser: testdisk uploaded
[08:58] <geser> partclone builds too, will upload it soon
[09:03] <geser> partclone uploaded, feel free to kill linux-ntfs :)
[09:05] <pitti> cking: are you okay with my followup in https://code.launchpad.net/~colin-king/apport/acpi-tables-remove/+merge/127206 ?
[09:06] <pitti> cking: or do you want to remove the code for other reasons, e. g. it's not working well, etc.?
[09:25] <Laney> indeed, mountall 3.40 boots fine
[09:25] <Laney> xnox: ^ try that?
[09:26] <xnox> Laney: ok. I will. (well I'll downgrade now, and reboot when X will lock up next time ;-) )
[09:27] <mzanetti> hey. anyone here using a Nokia N9 with the HOTP auth?
[09:29] <xnox> mzanetti: mzanetti if this is related to launchpad/ubuntu-one SSO authentication try #launchpad. As your question doesn't seem to lead to developing ubuntu....
[09:29] <mzanetti> xnox: ok. thanks
[09:29] <Laney> doko_: do you want to look over qt4-x11 in canonical-arm-dev and copy to Q if it looks OK to you?
[09:30] <Laney> built on all except PPC, but I believe that will get the correct build record when copied
[09:30] <Laney> also I'll upload make-dfsg and webkit to the queue shortly (after restoring the symbols to -c4) for you to review
[09:31] <cjwatson> You know we're getting a workaround for the timeout issue ASAP, right?  (Not that I can see these uploads.)
[09:31] <Laney> oh, well that might help for qt
[09:32] <Laney> but not for webkit
[09:32] <Laney> try giving it back when the deployment happens
[09:34] <cjwatson> Yeah, will do
[09:34]  * cjwatson glares at the botched merge of libav-extra
[11:00] <tkamppeter> Anyone knows how to debug avahi-daemon?
[12:10] <pitti> tkamppeter: like any other plumbing daemon you should be able to run it in a terminal with avhi-daemon --debug; it also has a -k for killing an existing one
[12:13] <ogra_> hrm
[12:15]  * ogra_ struggles with a linker problem ... 
[12:16] <ogra_> so i havea non multiarch package (nvidia-tegra) ... that drops a confi into /etc/ld.so.conf.d/ ... runnin ldconfig -v i can see the path and the libs listed ... but running an app that makes use of a lib from there i see the app not parsing the path from the linker config when looking for the lib
[12:17] <ogra_> infinity, doko_ ^^^ any hint ?
[12:20] <ogra_> the postinst has: update-laternatives --force --install /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf arm-linux-gnueabihf_egl_conf /usr/lib/nvidia-tegra/ld.so.conf 9000
[12:20] <ogra_>  /usr/lib/nvidia-tegra/ld.so.conf points to  /usr/lib/nvidia-tegra
[12:21] <ogra_> so i'm a bit lost why the app doesnt find the lib
[12:22] <cjwatson> doko_: Please pay attention to reverse-dependencies when removing packages from quantal.
[12:22] <ogra_> (it worked with exactly the same setup in precise btw)
[12:23] <cjwatson> doko_: ldc <- libtango - what do you suggest?
[12:25] <doko_> cjwatson, removed ldc from the blacklist. will remove libtango from q as well. mentioning it in bug #935267
[12:26] <doko_> ohh, it's October, +1-maint over ;-)
[12:26] <cjwatson> Hence most of my uploads today :-)
[12:26] <doko_> you forgot mksh, fixing a ftbfs ;)
[12:27] <doko_> ogra_, does the app rely on the dynamic loader, or does it just use dlopen?
[12:28] <ogra_> doko_, i see it opening ld.so-cache at the top and then there are just open() calls apparently
[12:29] <ogra_> pointing to the usual places (/lib/$triplet and /usr/lib/$triplet)
[12:29] <cjwatson> doko_: Thanks for leaving things in a state where I could basically go straight to fixing build failures, though ;-)
[12:30] <wookey> doko_: have you done any work on updating the gcc packaging for aarch64/arm64?
[12:31] <wookey> (and eglibc and binutils)
[12:31] <doko_> wookey, no, a bit early, as long as the eglibc bits are missing
[12:31] <wookey> If not I'll have a go this week
[12:32] <doko_> binutils should be ready, maybe omitting arm64 in the -multilib build
[12:33] <wookey> ready in the quantal package, or debian unstable or some repo somewhere?
[12:33] <doko> quantal
[12:33] <wookey> OK ideal.
[12:33] <doko> wookey, are the eglibc bits released?
[12:33] <wookey> I understand so yes
[12:33] <wookey> I need to check exact status of what's released where to whom and in what versions
[12:35] <wookey> ah no, apparently it's not out in the real world yet - in a few days
[12:35] <doko> wookey, heh, first patches on glibc-alpha this morning
[12:35] <doko> wookey, are you at this arm64 sprint?
[12:35] <wookey> yes I am
[12:36] <wookey> and If I could get a packaged toolchain working it would make my life a lot easier, so thought I'd see where we were at
[12:36] <wookey> and I'll have people to hassle when it breaks :-)
[12:38] <doko> so, the glibc changes look safe to apply, even in quantal, and gcc-4.7 has the patch already included, but not applied.
[12:38] <wookey> OK, sounds promising.
[12:38] <doko> for gcc, it's probably only updating the packaging, disabling Go, etc
[12:39] <wookey> the glibc changes are for trunk presumably, not 2.16 - but you reckon they are reasonably compatible?
[12:40] <doko> the first patch just adds aarch64 files, the second patch defines some aarch64 constants. if this is all, it doesn't touch other archs
[12:41] <wookey> (for relases types:) I also have 25 patches for core packages that need simple config.guess,sub updates. Is it too late to stick thos in quantal?
[12:42] <cjwatson> Do you have a list?  It would be interesting if it overlapped with the set that could use rebuilding for armel/armv5
[12:42] <doko> not from my point of view, need to address the armel build too. could you paste this list?
[12:42] <cjwatson> heh, snap
[12:42] <wookey> sure hold on a mo
[12:44] <ogra_> wow, not even preloading the lib directly with LD_PRELOAD works
[12:45] <wookey> http://paste.ubuntu.com/1253817/
[12:45] <ogra_> aha, but setting LD:LIBRARY_PATH works
[12:45] <wookey> cjwatson: ^
[12:46] <ogra_> *LD_LIBRARY_PATH
[12:46]  * ogra_ doesnt get that
[12:46] <wookey> hmm db5.1 wqould be more use wouldn't it :-)
[12:46] <doko> hrw, could you have a look at the gcc-4.5 cross packages ftbfs in the q test rebuild, fix or remove?
[12:47] <cjwatson> We can certainly have a look; feel free to put the patch set somewhere downloadable
[12:47] <wookey> He's (hrw) probably on a train right now. Due here about 3:30pm (i.e 1.6hrs)
[12:49] <doko> wookey, for make please get in touch with Laney. he has another patch pending
[12:50] <wookey> who is laney?
[12:50] <Laney> erm
[12:51] <doko> another *ey
[12:51] <ogra_> grmbl, the setup is even identical on the panda for pvr-omap4 ...
[12:54] <doko> wookey, you want to update libffi too
[12:54] <wookey> yes, got that.
[12:54] <wookey> again not sure if there are backporting issues
[12:56] <ogra_> ldconfig -p shows the lib is in the chache :/
[12:58] <doko> cjwatson, I hope you didn't find any in main =)
[12:59] <cjwatson> doko: Any what?
[12:59] <doko> ogra_, is this arm?
[12:59] <doko> cjwatson, build failures
[12:59] <cjwatson> Oh, right.  Well, there were several left from the test rebuild
[12:59] <ogra_> doko, tegra, yes
[13:00] <cjwatson> But I've been mostly attacking them random-access based on whatever looks easiest :-)
[13:01] <doko> too many :-/
[13:03] <wookey> cjwatson: patches at http://wookware.org/software/patches/quantal/
[13:04] <cjwatson> wookey: OK, I'll look at those as time permits
[13:05] <ogra_> :q
[13:10] <cjwatson> wookey: The first one I happened to look at appears to be unnecessary, because the build process automatically links in current config.guess/sub
[13:11] <cjwatson> wookey: So I suspect your search is too broad
[13:12] <cjwatson> wookey: Ah, hmm, actually debian/rules was linking new versions to the wrong place.  I'll fix that instead.  (findutils)
[13:13] <doko> cjwatson, wookey: the overlap with the armel rebuild is findutils libnih module-init-tools nano patch
[13:14] <cjwatson> Yeah, I was looking at those first
[13:16] <pitti> cjwatson: ok if I move psql to -updates? (bug 1055944)
[13:17] <pitti> more and more people are pinging me about this
[13:18] <cjwatson> pitti: Yes, I think we were agreed on that the other da
[13:18] <cjwatson> y
[13:18] <pitti> it's been 7 days now anyway
[13:18] <pitti> ok, copying then
[13:28] <cjwatson> doko: Your armel rebuild list is rather out of date though - I'm using a fresh ist
[13:28] <cjwatson> *list
[13:29] <cjwatson> Just in case you were going to do any uploads based on yours
[13:31] <doko> cjwatson, known. could you paste your new one?
[13:39] <cjwatson> doko: http://people.canonical.com/~cjwatson/armel-rebuild updated hourly.  By binary package, sorry, was a lot easier to avoid false positives that way
[13:39] <cjwatson> doko: That's for main
[13:46] <cjwatson> Hmm, maybe I should filter by libc6 dependencies
[13:47] <cjwatson> That's a bit better
[13:48] <cjwatson> doko: That's basically just "not rebuilt since precise", BTW - lillypilly:~cjwatson/bin/armel-rebuild
[13:50] <hrw> re
[13:50] <hrw> doko: ok, let me look
[13:50] <hrw> doko: url to ftfbs?
[13:53] <ogra_> doko, do you know if anything changed wrt link handling for libs in the linker ?
[13:54] <ogra_> seems ldconfig gets me something like: libGLESv2.so -> libGLESv2.so.2
[13:54] <ogra_> while it shoudl eb the other way round
[13:54] <ogra_> (teh link in the dir is actually the other way round)
[13:55] <ogra_> i.e. libGLESv2.so.2 -> libGLESv2.so
[13:55] <ogra_> (though i dont get why LD_LIBRARY_PATH works )
[13:56] <ogra_> and no matter how i manually fiddle with links of that lib, it always ends up as libGLESv2.so in ldconfig
[13:57] <debfx> kenvandine: why have you uploaded qt4-x11 to -proposed?
[13:57] <kenvandine> to fix that medium font issue
[13:57] <kenvandine> let a few folks test it out
[13:58] <kenvandine> debfx, that bug was on the release teams list and wanted some more testing
[13:58] <debfx> right, but proposed isn't really for testing
[13:59] <ogra_> it is simple easier to reject it from -proposed in case issues are found
[13:59] <kenvandine> right
[13:59] <kenvandine> and we were in a freeze as well
[13:59] <kenvandine> it already had some PPA testing
[14:00] <ogra_> and it will cause archive skew if you uploads directly to main
[14:00] <xnox> ogra_: true but the version number is taken, such that you can't really reupload again with the same version number if it got accepted.
[14:00] <ogra_> xnox, if it got accepted all should be fine
[14:01] <tkamppeter> pitti, thanks. I tried this and the debug info is not much. It gives some (normal) output at startup and does not log anything more while running. When I start CUPS and it takes up all CPU it does not do any further logging.
[14:01] <cjwatson> kenvandine: please note that the release team will move things from -proposed to release when they're fully built, and won't wait for testing
[14:01] <xnox> ogra_: upload to -proposed -> accept -> purged -> new upload needs to be version++ which is ok, but confusing sometimes =)
[14:01] <pitti> tkamppeter: I guess you could run it under strace and see what happens?
[14:01] <cjwatson> (well, as long as they're installable)
[14:01] <ogra_> xnox, oh, i thought accepted into release :)
[14:01] <xnox> ogra_: ah =)
[14:01] <kenvandine> cjwatson, yeah, i know
[14:02]  * ogra_ starts to really get annoyed by that ldconfig issue 
[14:02] <kenvandine> it wouldn't have been at that point in the freeze last week, so if it wasn't NACK'd by the time b2 released, it should be good to promote
[14:02] <ogra_> package update work of 10 minutes now causes hours of debugging and i dont get anywhere :(
[14:02] <kenvandine> it had successful testing in the PPA and upstream approved the patch
[14:03] <kenvandine> but they only plan to merge it in qt5
[14:28] <tkamppeter> pitti, I am trying but under strace avahi's timimg seems to change and avahi gets immune. It never reaches 100% and normalizes within some seconds.
[14:28] <cjwatson> doko: http://people.canonical.com/~cjwatson/armel-rebuild is by source package now, if I didn't screw it up
[14:45]  * pitti chuckles on LP saying "Estimated finish 46 seconds ago"
[14:45] <ev> pitti: heads up in case you run into this one on the Launchpad retracers as well: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1059621
[14:45] <ev> confusing, since gnat-gps-common is a dependency of gnat-gps, so it presumably should be okay that it gets extracted first
[14:45] <pitti> ev: ah, thanks; I don't currently use those in the distro retracers, though
[14:46] <ev> ah, noted
[14:52] <smoser> this appears to be a fairly serious issue:
[14:52] <smoser> https://bugs.launchpad.net/ubuntu/+bug/1058517
[14:53] <smoser> basically unclean unmount of / on reboot after upgrade
[14:53] <smoser> (the bug summary is the original bug reporters)
[14:58] <smoser> anyone have thoughts there?
[15:05] <ev> pitti: actually, the bug is incorrectly titled. It should happen even without the --sandbox option, as it seems to be the result of using dpkg -x
[15:08] <mpt> ev, any chance of a rollout this week?
[15:10] <ogra_> doko, so i see a massive discrepancy here, if i copy the libs to /usr/lib or /lib or set LD_LIBRARY_PATH all is fine, even with the broken soname in the lib ... if i use a dir like /usr/lib/nvidia-tegra nothing works ...
[15:11] <ogra_> (ldconfig forces the broken soname which doesnt contain a version)
[15:15] <ev> mpt: yes - I'll sort one tomorrow
[15:16] <mpt> splendid
[15:30] <smoser> jodh, SpamapS either of you have thoughts on what could have gone wrong in bug https://bugs.launchpad.net/ubuntu/+bug/1058517
[15:30] <smoser> something is causing unclean mount of /
[15:36] <bryceh> could an archive or SRU admin accept nvidia-common and jockey from the upload queue?  These are needed for the Valve Steam release that happens in a few days.
[15:54] <SpamapS> cjwatson: have you already seen bug reports about upgrading grub-pc in an lxc container?
[15:54] <SpamapS> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
[15:54] <SpamapS> seems like we should probably decline to configure grub in lxc
[15:54] <cjwatson> No
[15:55] <cjwatson> Feel free to fix, I probably don't have bandwidth
[15:55] <cjwatson> (Well, suggest a patch to me anyway)
[15:56] <SpamapS> I'm trying to imagine a situation where grub needs to be configured inside a container
[15:57] <cjwatson> Building an image for booting elsewhere, perhaps
[15:57] <stgraber> I have grub installed in all my upgrade containers as those are running a full desktop system
[15:58] <stgraber> obviously grub can't actually do anything as it doesn't have write access to the block device (and shouldn't have) but it's still installed
[16:26] <utlemming> any unity dev's here? apt-get dist-upgrade on 12.10 B2 completely foobar'd me.
[16:26] <utlemming> no dash, launcher, or title-bar at the top of the screen. Just a lovely little compiz session.
[16:31] <xnox> utlemming: bug 1053288 or something like that?
[16:32] <utlemming> xnox: nope. I don't have a launcher either. alt-tab doesn't work, but that is likely because unity doesn't appear to even be running.
[16:33] <utlemming> xnox: the only unity component running is the unity-webapps-service
[16:33] <utlemming> I filed Bug #1059725
[16:33]  * xnox is not unity dev so it was just a guess.
[16:36] <cjwatson> utlemming: do you have quantal-proposed enabled, perchance?
[16:36] <utlemming> cjwatson: yup
[16:36] <cjwatson> utlemming: Yeah, you do.  Don't do that.
[16:37] <cjwatson> utlemming: Its purpose is to guard you against this kind of skew.
[16:37] <utlemming> cjwatson: I think that happened when I upgraded from precise :(
[16:38] <utlemming> cjwatson: is there any easy way to downgrade?
[16:39] <cjwatson> apt-get install compiz/quantal probably
[16:39] <cjwatson> Have to rescue crying baby.  Maybe somebody else can help if you can't figure it out
[16:40] <utlemming> interesting...it looks like the core problem is that unity isn't even installed
[16:49] <zyga> barry: ping
[16:49] <zyga> barry: where is pysetup in python3.3?
[16:54] <utlemming> xnox, cjwatson: looks like the problem was a downstream depedency on compiz uninstalled unity
[16:54] <utlemming> its fixed now
[16:55] <xnox> utlemming: don't use quantal-proposed. or $dev-proposed ever. we use it to prevent these sort of problems.
[16:55] <utlemming> xnox: I don't think that was intentional. I upgraded from precise, where I had proposed enabled. I might have re-enabled it, by accident, but I don't think that was intentional at all.
[16:56] <xnox> utlemming: did you upgrade by-hand or with upgrade-manager?
[16:56] <utlemming> upgrade-manager
[17:00] <xnox> Hmm....
[17:00] <xnox> ok, thanks.
[17:13] <geser> could someone reject my first switchsh upload from the unapproved queue? I forgot to mention the LP bug number in the first upload :(
[17:21] <cjwatson> utlemming: Yeah, that's what I said in my comment on the bug
[17:40] <cjwatson> geser: linux-ntfs removed now
[18:05] <stgraber> geser: I may have accepted the wrong one, sorry. I only found the duplicate after accepting the older one. If that's indeed the case, please manually close the bug.
[18:18] <geser> stgraber: I've closed the bug manually already.
[18:31] <slangasek> Laney: bug #1059471> does this machine have an initramfs, and can you modify /etc/init/mountall to call mountall with --verbose and capture the output somewhere useful (probably /run)?
[18:36] <Laney> slangasek: yes, and sure I'll do that later on tonight
[19:31] <infinity> @pilot in
[19:44] <lamont> anyone want to claim significant dnsmasq knowledge?
[19:45] <lamont> specifically, can I tell it that it's &*^)*(&^)*(& authoritative for its zone?
[19:45] <infinity> lamont: You probably want stgraber.
[19:45] <lamont> who is probably EOD
[19:46] <lamont> how about a nova expert?
[19:47] <stgraber> nope, I'm around (US/Canada eastern) though I actually have fairly limited dnsmasq knowledge (limited to using it as a local dns cache, not as authoritative DNS server)
[19:47] <lamont> smoser: about?
[19:47] <lamont> stgraber: ah, cool
[19:48] <lamont> stgraber: so the issue I'm trying to sort out... nova inserts things in to $SOMECACHE, which dnsmasq then happily serves up.  Sadly, NXDOMAIN answers then get forwareded off to the resovlers for the subnet, which turn around and ask NOVA aka dnsmasq for the answer... after 5 seconds we time out
[19:48] <lamont> smoser: ^^ in case you're wondering, that's the DNS timeout you've been complaining about
[19:49] <stgraber> I vaguely remember helping highvoltage workaround a similar potential loop in his setup.
[19:49] <smoser> yeah. and i've been complaining loudly
[19:49] <smoser> :)
[19:49] <lamont> stgraber: what I really want is nova to be authoritative for the *(^)^&)( zpones
[19:49] <stgraber> highvoltage: any chance you can pastebin your dnsmasq config?
[19:49] <smoser> lamont, you think that is more than a local configuration issue ?
[19:49] <smoser> ie, is it somethign that any ubuntu user is going to see?
[19:49] <lamont> smoser: I'd be absolutely pleased as punch to find that it's a config error, and that it's trivial to teach either nova or dnsmasq to be authoritative
[19:50] <stgraber> lamont: I remember my "fix" being fairly hackish but can't remember from the top of my head, hopefully highvoltage is around and can paste the config we ended up with
[19:50] <lamont> smoser: anyone who configures bind on a resolver to forward a zone to dnsmasq so that he can map and reverse openstack hostnames, yes.
[19:51] <lamont> stgraber: tell me where the config lives, and I can get it to you, yes
[19:51] <lamont> ls -l /etc/dnsm*
[19:51] <lamont> ls: cannot access /etc/dnsm*: No such file or directory
[19:51] <lamont> but I'm guessing it's the nova-dnsmasq, not the real one
[19:52] <highvoltage> stgraber: yep... coming up...
[19:53] <highvoltage> stgraber, dnsmasq.conf: http://paste.ubuntu.com/1254671/
[19:53] <highvoltage> (and then /etc/hosts.app799.com is just a usual hosts file)
[19:54] <stgraber> highvoltage: right, thanks found what I wanted
[19:54] <stgraber> lamont: I have no idea how openstack/nova works, but if you can get your hands on the config, you'll need something like:
[19:54] <stgraber> server=/1.17.172.in-addr.arpa/
[19:55] <stgraber> which in this case says that there's no "upstream" server for 1.17.172.in-addr.arpa
[19:55] <stgraber> that essentially makes dnsmasq authoritative for the zone
[20:06] <lamont> stgraber: am I reading this correctly, that dnsmasq (2.59-4), when run with --conf-file= will just run with the default arguments?
[20:07] <stgraber> lamont: that sounds right, yeah. In that mode it basically just uses whatever is on its command line + whatever hardcoded config it has
[20:19] <hallyn> tjaalton: any progress with new xserver for qxl bug?
[20:21] <hallyn> else, should i pursue pushing my patch for now?
[20:21] <hallyn> (my patch == just a subset of upstream git commits)
[20:21] <hallyn> (iow, not *my* p[atchs)
[20:23] <pitti> barry: ah, got it figured out -- how's http://pypi.python.org/pypi/python-dbusmock looking now? :-)
[20:29] <barry> pitti: it's a thing of beauty! :)
[20:29] <pitti> barry: and a pita to set up :)
[20:29] <barry> :)
[20:29] <pitti> barry: I guess one of these days I need to create a proper account and write a do-release script with the umpteen steps to upload metadata, tarballs, description to pypi and the tarball to LP
[20:30] <barry> pitti: yeah.  i usually `python setup.py sdist upload -s` then do the release on lp with the resulting tgz and asc files.  but it *is* a pita
[20:31] <pitti> barry: did you get the pypissh thingy to work?
[20:31] <pitti> barry: I guess you have an user/pwd, not using OpenID?
[20:32] <barry> pitti: nope
[20:32] <barry> pitti: i have both actually.  i usually log in with openid, but it is associated with my pypi user name
[20:32] <pitti> right now I need to sdist, then open the web page for creating a new release, upload PKG-INFO, then click through the files, upload tar and asc, and then reupload the description to be the README.rst
[20:32] <barry> ouch
[20:34] <pitti> anyway, c'est l'heure de dormier (just had TB meeting), bonne nuit!
[20:39] <kees> cjwatson: can you approve my email to devel-announce, please?
[20:49] <cjwatson> kees: done
[20:58] <tedg> kees, Not sure what date format you're using here ;-)  "Next meeting is 2012-19-15"
[20:59] <stgraber> tedg: 15th of July ;)
[20:59] <stgraber> tedg: more seriously, it's going to be 2012-10-15
[21:00] <tedg> Heh, yeah, I figured.  It was just funny.
[21:06] <kees> tedg: hah, whoops
[21:07] <kees> tedg: I found the one person reading the minutes! :)
[21:08] <tedg> kees, I verify everything you send me isn't an attempt at a buffer overflow ;-)
[21:08] <kees> lol
[21:08] <kees> did your calendar crash? :)
[21:08]  * cjwatson sends tedg a Langford basilisk
[21:09] <kees> tedg: we should totally meet on Smoterday Octember 32nd
[21:10] <bryceh> not in a leap year!
[21:10] <tedg> Heh
[21:13] <tjaalton> hallyn: I have -qxl ready in git, but it needs libspice-protocol-dev from experimental, so haven't actually build-tested it yet..
[21:15] <hallyn> tjaalton: that is built in ppa:serge-hallyn/virt, if that helps you easily build it
[21:16] <tjaalton> hallyn: well, you could upload -qxl there :)
[21:16] <tjaalton> hang on
[21:16] <tjaalton> or I could steal your stuff
[21:16] <hallyn> tjaalton: sure (it'll then supersede the patched source i was playing with, but that's ok)
[21:20] <popey> nope
[21:24] <toabctl> how is it possible that a lp branch of a ubuntu package is out of date? eg https://code.launchpad.net/ubuntu/+source/icu
[21:46] <tjaalton> hallyn: sigh, dpkg-source giving pain because of diff-ignore.. pushed the update to git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-qxl if you manage to build the source package..
[21:46] <tjaalton> too tired to fix that
[21:53] <hallyn> tjaalton: hm, i don't understand.  that is quite a bit older than the version i was doing (0.0.18~gitde66207-0ubuntu2~ppa2).  is there a branch i'm supposed to check out in there?
[22:56] <infinity> @pilot out