[02:00] <rsalveti> tjaalton: seems -omap 4.1 is working as expected at panda
[02:00] <rsalveti> didn't have any issue with it
[02:01] <rsalveti> tjaalton: saw it's available at debian packaging git tree, but not yet pushed to debian
[02:01] <rsalveti> tjaalton: want to manually sync it?
[03:58] <tjaalton> rsalveti: ok, will do. also, is unity working for you on the panda?
[04:04] <robert_ancell> @pilot out
[05:14] <pitti> Godo morning
[05:44] <pitti> (erk, and hapy tpying!)
[05:44] <RAOF> Goodo!
[06:21] <dholbach> good morning
[06:30] <trijntje> Hi all, can someone tell me where translations for the package gcr show up? I'm trying to complete the translations but I'm not sure about a number of strings
[06:31] <trijntje> these strings to be specific: https://translations.launchpad.net/ubuntu/quantal/+source/gcr/+pots/gcr/nl/+translate?batch=10&field.alternative_language-empty-marker=1&old_show=all&show=untranslated&start=0
[06:39] <dholbach> freeflying, happy birthday! :)
[06:45] <sarnold> trijntje: the 'gcr' package's Homepage field points here: https://live.gnome.org/GnomeKeyring
[06:45] <sarnold> the Description says, in part, "This package contains the certificate viewer and prompter service."
[06:49] <trijntje> sarnold: thanks, I'll try asking in the gcr irc channel
[07:32] <freeflying> dholbach: thanks :)
[07:39] <hrw> wookey: I switched to PKG_IGNORE_CURRENTLY_BUILDING=1 in 1.57 version. It replaced NO_PKG_MANGLE=1 and gave us ddebs
[07:42] <hrw> wookey: can give you #linaro irc log of my discussion with lool about that switch.
[07:52] <lool> hrw: This is fairly old, right?  ISTR we had to patch pkgbinarymangler, but that should be all in Ubuntu precise at least
[07:52] <hrw> lool: it was natty time
[07:53] <lool> yeah
[07:53] <lool> I thought maverick, but whatever, it's "old"  :-)
[07:57] <infinity> And today's confusingly useless use of cat award goes to:
[07:57] <infinity> cat /build/buildd/sssd-1.9.1/debian/sssd.upstart.in > /build/buildd/sssd-1.9.1/debian/sssd.upstart
[07:59] <tjaalton> no idea why cat instead of cp :)
[08:00] <infinity> tjaalton: No idea why a .in at all, if it's not mangled on its way to being the real deal.
[08:00] <tjaalton> infinity: it's the same line on debian too, there's an initscript for debian
[08:00] <tjaalton> cat $(CURDIR)/debian/sssd.$(INIT).in > $(CURDIR)/debian/sssd.$(INIT)
[08:01] <infinity> tjaalton: Seven kinds of special. :)
[08:01] <cjwatson> Maybe it was mangled once and somebody didn't undo it enough *shrug*
[08:02] <infinity> Yeah, did an 's/sed "expression"/cat/', assuming they may need to bring the sed back some day?  Dunno.
[08:02] <infinity> Just rather entertaining.
[08:02] <infinity> (The things one notices while watching build logs at 2am)
[08:16] <tjaalton> well, is it allowed for packages to ship upstart files on debian? and would it then include both upstart and sysv initscripts on ubuntu?
[08:16] <tjaalton> I'd gladly get rid of that hack
[08:18] <infinity> tjaalton: Oh, I see what you're doing now.  Selecting one or the other, check.
[08:18] <tjaalton> right
[08:18] <tjaalton> instead of a diff
[08:18] <infinity> tjaalton: I do believe it's perfectly reasonable to ship foo.upstart in debian/, and vorlon's submitted many a patch to do that, but I'm no expert on what the status of that is.
[08:18] <infinity> slomo: ^
[08:18] <infinity> slangasek: ^
[08:19] <infinity> slomo: Ignore that, tab completion fail.
[08:19] <slangasek> it's now valid in unstable; until recently it wasn't
[08:19] <tjaalton> I recall there being a policy update about that..
[08:19] <tjaalton> ah
[08:19] <slangasek> (unstable and testing)
[08:20] <tjaalton> slangasek: ping re acpi-tools review, what to do with them :)
[08:20] <tjaalton> acpi-support
[08:20] <slangasek> tjaalton: whimper; ENOTIME for the next couple of days, do whatever you think is best
[08:21] <tjaalton> slangasek: cool, I'll just upload, it's a no-brainer
[08:21] <infinity> tjaalton: If it's a no-brainer, any one of us no-brains will happily review it in the queue. ;)
[08:21] <tjaalton> infinity: heh, understood :)
[08:22] <tjaalton> bug 804109, fwiw
[08:22] <pitti> RAOF, infinity: can I bribe one of you to review the SRU upload for bug 1016121? the crowd is getting angry :)
[08:24] <infinity> pitti: Sure.  I accept bribery in the form of kittens.
[08:24] <infinity> pitti: (It's my SRU day in ~6h anyway, but I'll check this one now)
[08:26] <pitti> infinity: http://cdn.memegenerator.net/instances/400x/28050481.jpg
[08:26] <infinity> pitti: Straightforward enough to me and, as an added bonus, I know exactly what that patch does. :P
[08:27] <pitti> infinity: meeow!
[08:27]  * pitti purrs happily
[08:27] <infinity> pitti: Oh, wow, a custom lolcat just for me.  I feel special.
[08:28] <infinity> pitti: And accepted.
[08:29] <pitti> cheers!
[09:02] <pitti> xdatap1: so is that one patch you pointed out enough for you, or do you actually need the quantal ubuntu-defaults-builder in precise?
[09:02] <pitti> in the latter case, why don't you just use the quantal pacakge as it is?
[09:03] <xdatap1> pitti, we use the amazon cloud for building the images, so using the standard package from archive would be better.
[09:04] <pitti> xdatap1: quantal's version also has some adjustments for newer live-build, so I don't know whether it'd actually work with the precise live-build version
[09:04] <xdatap1> pitti, also we are planning to continue using precise cloud instances for building the CD, so we would need ubuntu-defaults-build to move on with the new features
[09:04] <pitti> xdatap1: I guess for now it might be best if we target individdual bug fixes that you need to precise, and I wrap them up in the next SRU?
[09:05] <xdatap1> pitti, if this is better I'm fine with it. But as far I can see all the changes from 0.31 to 0.38 makes sense in precise
[09:06] <xdatap1> pitti, on the same context, we need also the patch from this: https://bugs.launchpad.net/bugs/1062423
[09:06] <pitti> xdatap1: e. g. 0.32 says "Adjust for live-build interface changes." which looks quantal only
[09:07] <xdatap1> pitti, mmm, yes, you're right
[09:09] <xdatap1> pitti, let's recap then. Patches for bug #1016121 , bug #1048207, bug #1062423 and if possible Bug #1029279 but I'm using a workaround for this so it's not urgent
[09:11] <pitti> xdatap1: 1016121 is in -proposed; marked 1048207 for next SRU round; 1062423 looks like a missing dependency?
[09:11] <pitti> xdatap1: i. e. you need syslinux-themes-quantal
[09:11] <pitti> if you want to build quantal images
[09:14] <xdatap1> pitti, correct me if I'm wrong, I wouln't have all syslinux-themes-<version> packages in Precise in the future, don't I? So wouldn't make sense pointing to syslinux-themes-precise for all the version I build?
[09:14] <cjwatson> xdatap1: You really need to build quantal images in a quantal system - it's totally unsupported to do otherwise
[09:14] <pitti> xdatap1: no, you need to install them from quantal
[09:14] <cjwatson> xdatap1: Why not use a quantal chroot?
[09:15] <pitti> but as I said before, it's really easier to just take the quantal pacakge
[09:15] <pitti> at least live-build, u-d-b and syslinux-themes-* for the target releas
[09:15] <cjwatson> xdatap1: We build all Ubuntu images in a host system that's, oh, I don't even know what it is, one of precise/lucid/hardy
[09:15] <cjwatson> xdatap1: With chroots matching the release we're building
[09:16] <xdatap1> phone, brb
[09:22] <xdatap1> back
[09:24] <xdatap1> cjwatson, pitti: let me rephrase the topic. The Italian team builds these localized images with ubuntu-defaults-build. From this cycle we try to use amazon cloud instances because building in local machine and then upload on the server it's way too long, takes nearly two hours
[09:24] <pitti> xdatap1: right, but surely you can install some additional packages there from the target release?
[09:26] <xdatap1> cjwatson, pitti : ubuntu-defaults-build do create a chroot for the target version. The bug #1029279 imho depends on the fact that the script ss looking for the directory on the host system and not inside the chroot.
[09:26] <xdatap1> cjwatson, pitti : btw the general problem is. May we continue to update ubuntu-defaults-build on precise so that we can keep using precise for building next versions?
[09:27] <pitti> xdatap1: as I said, that's not enough -- you also need live-build, the syslinux theme, and possibly some dependencie of those
[09:29] <xdatap1> pitti, so the short answer is "probably no"? I mean, it appears difficult to build a precise+3 on precise, don't you think?
[09:29] <cjwatson> xdatap1: I think it's a waste of time
[09:29] <pitti> right
[09:29] <cjwatson> xdatap1: I know ubuntu-defaults-builder creates a chroot - I mean that you should have another level of chroot to run ubuntu-defaults-builder in
[09:29] <cjwatson> That will be so much less hassle for you and us
[09:30] <cjwatson> And it will (modulo setup) work fine because it matches what we do
[09:32] <xdatap1> the steps would be, then: precise cloud image -> ubuntu+n chroot -> ubuntu-defaults-build -> ubuntu+n chroot -> iso
[09:32] <xdatap1> at the end it would have two chroots
[09:32] <xdatap1> is it correct?
[09:34] <xnox> xdatap1: yes.
[09:35] <xnox> xdatap1: the last chroot is "implementation detail" of how to create an livecd-iso.
[09:37] <xdatap1> ok. I need to think about it. As far I can see it's not sustainable for us in the long run. :\
[09:38] <xdatap1> unless I create something that makes it automatic...
[09:40] <xnox> xdatap1: there is sbuild juju charm that can create the first chroot. With small changes you can make the whole process as quick as: juju deploy livecd-build. and wrap your current build script in `schroot -c $target-distro`
[09:41] <xnox> xdatap1: and juju will bring your livecd building instanace up, set it up and download the scripts you want, and clean up afterwards.
[09:41] <xdatap1> xnox, thanks, I'll check for it. The problem is that quantal is next week
[09:41] <xnox> xdatap1: for added bonus you will then be able to use it not only with EC2 but locally with lxc containers....
[09:42] <xnox> xdatap1: yeah, I see.
[09:42] <xnox> xdatap1: but... I am running quantal on EC2. There are quantal ec2 images published for each milestone. Use those?!
[09:43] <xdatap1> pitti, anyway, we'll need the patch for bug #1048207 because it affects also precise builds and we'll need it for the point release
[09:43] <pitti> right
[09:44] <xdatap1> pitti, thanks, you're an hero!
[09:46] <xdatap1> xnox, quantal ec2 images? where is it? I can't find it in the list
[09:47] <xnox> xdatap1: http://iso.qa.ubuntu.com/qatracker/milestones/238/builds filter on the left for "Ubuntu Server EC2" only, for the quantal beta-2 milestone. The ami's are listed per region/arch in the right hand column.
[09:47] <cjwatson> xdatap1: I can't believe it wouldn't be sustainable.  It involves a tiny amount of sysadmin effort once every six months to create the new chroots; they can be simple enough that you can keep them up to date automatically
[09:48] <cjwatson> xdatap1: Again, this isn't a theoretical exercise, it's what we do in production and it's easy
[09:48] <xnox> cjwatson: i think they do tear down and back up the EC2 instance ;-) so really they should puppetize / jujufy / etc it.
[09:48] <cjwatson> If you have no persistent storage, indeed, it would be a bit more effort
[09:48] <xnox> xdatap1: maybe there is a better way to find devel EC2 amis... but I don't know.
[09:49] <cjwatson> But not desperately much
[10:01] <xdatap1> with the last hint xnox gave me I should have solved. I'll check it out. Thanks ;)
[11:02] <wookey> where is the equivalent of Debian's PTS for ubuntu? How do I find out if gcc-4.7_4.7.2-3ubuntu1 is headed for quantal or not?
[11:03]  * wookey is having much fun with multiarch and compiler version skew across arches
[11:03] <cjwatson> https://launchpad.net/ubuntu/+source/gcc-4.7
[11:04] <cjwatson> Can't tell you intent, but then nor can the PTS
[11:04] <wookey> right. cheers
[11:04] <cjwatson> You'd have to ask doko
[11:06] <doko> it's meant for -updates, not uploaded to -proposed to avoid accidential migration before the release. found in the ubuntu-toolchain-r/ppa PPA
[11:06] <wookey> OK. but right yes _ i just found the PPA, which should solve my problem if it has arm builds too - ah yes it does.
[11:07] <doko> wookey, there is bug, the packages don't build Go. but I assume you don't care
[11:07] <wookey> I've got apt in a right state - interesting to see if it can sort itself out
[11:07] <wookey> doko: correct :-)
[11:08] <wookey> PPAs are a really good idea :-)
[11:34] <BadDesign> Is there a repo that has a built GCC 4.7.2 ?
[11:34] <doko> seb128, did you have a chance to look at libgtk2-perl?
[11:35] <BadDesign> https://launchpad.net/~ubuntu-toolchain-r/ seems no to have it yet
[11:35] <seb128> doko, I had a look but I didn't manage to figure what is wrong (yet ... then got sidetracked in "need to land before freeze" issues)
[11:36] <BadDesign> for precise, Ubuntu 12.04, I mean.
[11:40] <doko> not yet. buildd resources are needed elsewhere
[11:44] <BadDesign> mda
[11:48] <zyga> pitti: udisks2 support landed in checkbox
[11:49] <zyga> pitti: with GUdev help
[11:49] <pitti> zyga: yay you!
[11:49] <zyga> pitti: thanks a lot for helping me out :)
[11:49] <pitti> no worries
[11:50] <zyga> pitti: I hope that we can soon fix usb-creator too
[12:05] <rsalveti> tjaalton: unity is working fine for me
[12:06] <tjaalton> rsalveti: on stock quantal?
[12:06] <rsalveti> tjaalton: yes
[12:07] <rsalveti> a few bugs, like a black line at the top of the screen, but working
[12:07] <tjaalton> huh, doesn't work at all here, compiz crashes
[12:08] <tjaalton> rsalveti: what dri driver do you have? llvmpipe isn't actually built atm, and it doesn't seem to work either
[12:09] <rsalveti> tjaalton: well, I'm using the pvr-omap4 driver
[12:09] <tjaalton> right
[12:09] <rsalveti> don't think llvmpipe would work at this point on arm
[12:09] <rsalveti> not enough to be called as usable
[12:09] <tjaalton> nope
[12:10] <ogra_> what i was wondering though is why cant we fall back to swrast
[12:10] <ogra_> shouldnt that just kick in
[12:10] <tjaalton> that's what happens now, and compiz crashes
[12:10] <ogra_> (i know it wont be usable but iu would actually expect more than a dead screen)
[12:10] <ogra_> ah, so its compiz
[12:11] <rsalveti> I don't think we ever got compiz working with swrast with opengles
[12:12] <ogra_> yeah, i wasnt aware its the client side thats at fault :)
[12:13] <jdstrand> seb128: hey, what changed recently that makes everything want write access to dconf? I know about pam-xdg-support but the thing is, applications that never needed @{HOME}/.../dconf/user (eg, evince (bug #1062531)) now need it
[12:18] <seb128> jdstrand, it's weird, nothing should have changed out of the location of the db... I need to check with desrt
[12:19] <seb128> jdstrand, but on that evince bug: apparmor="DENIED" operation="open"  name="/run/user/<user>/dconf/user"
[12:19] <seb128> jdstrand, doesn't "open" mean it's having issue to access it to read?
[12:21] <seb128> jdstrand, I think the evince error message is buggy (checking)
[12:22] <jdstrand> seb128: it could be access(), it could be open()
[12:22] <seb128> jdstrand, yeah, that errors is displayed when "  fd = open (filename, O_RDWR | O_CREAT, 0600);" fails
[12:22] <jdstrand> it could be creat()
[12:22] <jdstrand> seb128: is that in library code or in evince?
[12:23] <seb128> jdstrand, it's in libdconf
[12:23] <seb128> d-conf's client library
[12:23] <jdstrand> sigh
[12:24] <seb128> jdstrand, the way dconf works is that the daemon is only used for write, reading is done through direct mmaping of the db by the client through the lib
[12:24] <jdstrand> I'm tempted to just add a deny rule
[12:24] <seb128> jdstrand, do we need to restrict /run/user/<user> access at all?
[12:25] <seb128> we don't restrict ~/.config access do we?
[12:25] <mdeslaur> jdstrand: all gnome apps will need that directory, it's for d-conf shared memory...it should go in the gnome abstraction
[12:26] <jdstrand> well that's great
[12:26] <mdeslaur> jdstrand: the glib g_get_user_runtime_dir() now returns that directory now that the env var exists
[12:26] <jdstrand> cause that's yet another hole in the profile since, you know, know the confined application can write to gsettings
[12:26] <jdstrand> evnce worked just fine without the denial prior to this though
[12:26] <seb128> mdeslaur, it's not only GNOME, gsettings is a glib level api (so could be used by e.g qt or KDE clients)
[12:27] <jdstrand> s/, know/now/
[12:27] <mdeslaur> jdstrand: that's because when the new env var isn't set, it defaulted to the user cache directory in his home
[12:27] <seb128> jdstrand, well, it was writing to gsettings, the db was just in ~/.config, how is that different?
[12:27] <mdeslaur> jdstrand: but that's less than ideal, as the directory isn't cleaned up on reboot
[12:27] <jdstrand> mdeslaur: I understand-- evnice doesn't have access to the oroginal value
[12:29] <jdstrand> apparmor_parser -p /etc/apparmor.d/usr.bin.evince|grep dconf
[12:29] <jdstrand> returns nothing
[12:29] <jdstrand> and there were no apparmor complaints
[12:29] <jdstrand> today, there are apparmor complaints
[12:30] <mdeslaur> jdstrand: well, you had @{HOME}/** rw,
[12:30] <seb128> jdstrand, I don't understand the issue ... it was in .config which is not restricted in access, so it's normal there were no complain?
[12:30] <jdstrand> this is true
[12:31] <seb128> jdstrand, shouldn't just /run/user/<user> be whitelisted the same way?
[12:31] <seb128> it's technically part of the user's owned dirs
[12:31] <mdeslaur> jdstrand: /run/user/$USER is the new place where apps will put all their temp stuff
[12:33] <jdstrand> seb128: my point was that I thought it *was* restricted in access. it isn't just evince-- it was a bunch of things. I have several profiles that are not shipped in ubuntu that all of a sudden need the access. I need to look at this more
[12:33]  * jdstrand sighs again
[12:33] <seb128> :-(
[12:33] <jdstrand> (it shouldn't be in the gnome abstraction, cause we don't want to expand write access, but I'll fix the profiles)
[12:34] <mdeslaur> jdstrand: It should probably go in the user-tmp abstraction
[12:34] <seb128> jdstrand, you technically don't need write access there?
[12:34] <mdeslaur> jdstrand: huh? it's a temp dir? why wouldn't apps get write access in there?
[12:35] <jdstrand> seb128: we don't want the gnome abstraction itself to have the write access, no. maybe in another abstraction. but that doesn't matter for this. we'll figure something out
[12:35] <seb128> jdstrand, well, why do you need "write"? the client lib is only reading the db, the writes go through dbus to the service
[12:35] <Riddell> pitti: ok with this change to apport? http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/2103?start_revid=2103
[12:36] <jdstrand> seb128: filename, O_RDWR | O_CREAT will file if not given 'w'
[12:36] <jdstrand> s/will file/will fail/
[12:37] <seb128> oh, I see, right :-(
[12:38] <jdstrand> seb128: are you planning an upload of evince anyway?
[12:39] <seb128> jdstrand, no, I've nothing planned for it
[12:41] <jdstrand> ok
[12:44] <pitti> Riddell: sure, if that works for you; I'll apply it to trunk, and check with the test suite
[12:50] <doko> barry, talked with jdstrand about getting python3.3 into main already in quantal (needed in r anyway). reason is to build python3-stdlib-extensions for 3.3. we should then strive to get rid of 3.2 in r
[12:50] <doko> will start the opening of r with 3.3 as a supported version
[13:07] <danimo> notification area people: ping?
[13:08] <danimo> looks like there is a pretty bad bug with QSystemTray in 12.04
[13:08] <danimo> related to the way SNI treats menus with separators
[13:32] <smoser> slangasek, could you take a look at https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1060296
[13:33] <ev> mpt: as it turns out, we're inserting quite a few package failures into the database. For 20120928 there were 97395 12.04 crashes and 2107 package installation failures. We don't get a signature for these yet, so they wont appear on the front page.
[13:33] <ev> mpt: http://poppy-dev.local - I'm running that back-population in the background
[13:33] <ev> so you should slowly see past days appear
[13:33] <mpt> ev, what's a "package failure"? installation?
[13:33] <ev> yes
[13:35] <mpt> ev, so they haven't been showing up in the table, but have they been showing up in the graph?
[13:35] <ev> mpt: correct, but not showing them in the graph is being fixed right now
[13:35] <xnox> ev: thunderbird and rhythmbox have their "own" crash dialogs (thunderbird tries to report to mozilla, rhythmbox want to restart itself). and those don't seem to be getting through to whoopsi and apport, do they?
[13:35] <ev> xnox: correct; we filter those out in apport
[13:35] <mpt> ev, so are there any examples of package installation failures in the poppy-dev table? Nothing jumps out at me.
[13:35] <xnox> =(
[13:36] <ev> xnox: see /etc/apport/blacklist.d
[13:36] <ev> mpt: no, package installation failures wont show up in the table yet
[13:36]  * xnox would report to launchpad, but not mozilla....
[13:36] <ev> feel free to come over if I am being confusing :)
[13:36] <chrisccoulson> xnox, why? feel free to report to launchpad, but your bug won't get fixed
[13:36] <ev> xnox: Mozilla is much better equipped to handle problems in Firefox than we are
[13:37] <chrisccoulson> indeed :)
[13:37] <chrisccoulson> they have a lot more people looking at crashes than we do
[13:37] <mpt> ev, even so, we should be collecting them for statistical purposes
[13:37] <chrisccoulson> (ie, they have more than one person looking at firefox crashes) ;)
[13:37] <mpt> (Firefox and Thunderbird crashes, I mean)
[13:37] <xnox> but they do not have the same privacy as we do.
[13:38] <ev> mpt: agreed
[13:38] <ev> filing a bug for that now
[13:38] <xnox> but... rhythmbox hiding it's own crashes?
[13:40] <ev> xnox: hm? Elaborate please.
[13:40] <barry> doko: +1 from me.  also: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-python33
[13:41] <ev> mpt: thoughts on getting two dialogs for firefox crashes?
[13:41] <ev> seeing as how Mozilla will pop up one as well
[13:41] <mpt> One with a broken icon
[13:41] <mpt> I am familiar with it
[13:42] <mpt> and one that never, ever, works for me
[13:42] <mpt> but I digress
[13:43] <mpt> ev, ideally we'd just hook in to theirs
[13:43] <ev> mpt: please feel free to update https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1064395 with your thoughts
[13:44] <josh__> Any idea if there will be fix for fglrx Bug #1058040 in final Ubuntu 12.10 release? Or we will have to use open source drivers? Thanks.
[13:44] <xnox> ev: when rhythmbox crashes, it shows a rhythmbox crash saying "rhythbox crashed <quit> <restart>" and no apport / whoopsie dialogs. Can you check if you have rhythmbox crashes over the year?
[13:44] <xnox> maybe it has been crashing at decoding mp3 and that's blacklisted though =/
[13:44] <seb128> xnox, ev: rb shouldn't block apport, some software do because they trap the signal to do custom handling, we usually patch those to restore the signal to not hijack apport
[13:45] <seb128> xnox, ev: or said differently "that's a bug"
[13:45] <ev> :)
[13:45]  * xnox did seb128 join us?! =)
[13:45] <seb128> xnox, well, go on https://errors.ubuntu.com/ and enter "rhythmbox" in the text entry
[13:45] <ev> xnox: https://errors.ubuntu.com/?package=rhythmbox
[13:45] <seb128> quite some rb issues there
[13:46] <xnox> hmm...
[13:46] <ev> damn, seb128  beat me to it :)
[13:46] <ev> but yeah, seems like we're getting reports for it
[13:46] <seb128> ev, your solution is nicer though, one click away and I learnt something ;-)
[13:46] <ev> seb128: yeah, I really need to document (beyond the old post to ubuntu-devel) the URL parameters
[13:47] <ev> or rather, just make the URL change to match the selected filter
[13:47] <ev> so you learn them all the same
[13:47] <ev> I think mpt suggested that a while back
[13:47] <cjwatson> Yeah, I wish more pages did that
[13:47] <seb128> xnox, I get an apport dialog if I kill -11 $(pidof rhythmbox)
[13:48] <seb128> ev, yeah, I like when urls reflect your queries ;-)
[13:48] <seb128> it also makes firefox's awesome more awesome
[13:48] <seb128> since it remembers the things you query most about and rank them higher
[13:48] <ev> sounds like we have consensus :) - adding to my todo list
[13:48] <ev> oh nice
[13:48]  * xnox same with chromium....
[13:48] <mpt> ev, yes, in bug 1020580 (should that be a separate bug?)
[13:48] <cjwatson> I don't generally remember URLs any more; I bang bits of them into firefox and it reads my mind
[13:49] <ev> mpt: yeah, probably
[13:49] <ev> as we can consider permanent URLs done
[13:49] <ev> cjwatson: hahaha
[13:50]  * xnox can see a new "virus" popping up which clears user search history.... that will be pain.
[13:50] <mpt> ev, reported bug 1064398
[13:51] <ev> mpt: thanks
[13:55] <seb128> ev, what does "red background" means again? and greyed background?
[13:55] <seb128> ev, it would be really good to have a color code somewhere on the page for people like me who can't make sense of the color code ;-)
[13:56] <stgraber> dholbach: heya
[13:57] <stgraber> dholbach: I'm looking at libxml2 in the queue, it's introducing a new binary package without any FFe or even any bug linked to it at all. Do we actually need that udev in Ubuntu?
[13:57] <stgraber> *udeb
[13:57] <dholbach> stgraber: I didn't create the udeb
[13:57] <dholbach> stgraber: that must be something automatic during the build
[13:57] <cjwatson> it's had a udeb for ages, I thought
[13:58] <stgraber> http://launchpadlibrarian.net/119213170/libxml2_2.8.0%2Bdfsg1-5_2.8.0%2Bdfsg1-5ubuntu1.diff.gz
[13:58] <ev> red/pink -> possible regression
[13:58] <ev> grey -> not showing up in the latest version yet
[13:58] <doko> stgraber, it's just autogenerated when built on ubuntu
[13:58] <ev> seb128: indeed, it's on my list :)
[13:58] <doko> WITH_UDEB := $(shell dpkg-vendor --derives-from Ubuntu && echo yes)
[13:58] <doko> ifdef WITH_UDEB
[13:58] <doko> $(if $(shell grep -q libxml2-udeb debian/control || echo yes),$(shell cat debian/control.udeb >> debian/control))
[13:58] <doko> TARGETS += udeb
[13:58] <doko> else
[13:58] <doko> $(if $(shell grep -q libxml2-udeb debian/control && echo yes),$(shell sed -i /libxml2-udeb/,\$$d debian/control))
[13:58] <cjwatson> there's certainly a udeb in the archive right now
[13:58] <doko> export DH_OPTIONS = -Nlibxml2-udeb
[13:58] <doko> endif
[13:58] <seb128> ev, oh ok, I though pink was that, I wouldn't have guessed the grey one ;-)
[13:58] <seb128> ev, thanks
[13:58] <dholbach> stgraber: so it looks like it's business as usual :)
[13:59] <cjwatson> yeah, that looks like autoregenerated control file
[13:59]  * Laney does a sad about libxml2 going out of sync
[13:59] <cjwatson> generated control is a curse from the pits of hell
[13:59] <dholbach> Laney, the change is forwarded
[13:59] <stgraber> hmm, ok, so it's just the diff being confusing...
[13:59] <smoser> doko, roaksoax says you moved freeipmi to main earlier today. is this transient: http://paste.ubuntu.com/1269287/
[13:59] <ev> seb128: sure thing
[14:00] <cjwatson> smoser: something is odd because freeipmi-common is missing from the archive at the current version
[14:00] <smoser> right. i hvae no idea how i would fix such a thing. i'm guessing you do.
[14:00] <Daviey> Candidate: 1.1.5-3 == not current version.
[14:00] <smoser> right.
[14:00]  * cjwatson checks build logs
[14:01] <cjwatson> I strongly suspect that somebody overrode it between components twice in one publisher cycle
[14:01] <cjwatson> And thereby caused Launchpad to forget that it exists
[14:01] <Daviey> cjwatson: That will be me and doko doing the operation concurrently
[14:01] <cjwatson> Yeah, it's Superseded
[14:01] <doko> smoser, should be
[14:01] <cjwatson> Concurrently isn't a problem if you both do the same thing
[14:02] <cjwatson> Daviey: Somebody needs to do a no-change upload of freeipmi to resurrect this
[14:02] <doko> ouch
[14:02] <Daviey> cjwatson: for reference, is the a LP bug to track this feature?
[14:02] <chrisccoulson> mpt - did you report a bug for the broken icon? ;)
[14:02] <cjwatson> There is, somewhere - it's well-known by the relevant people
[14:03] <cjwatson> It's obviously not a feature :-P
[14:03] <mpt> ev, seb128: red/pink can also mean "private bug report"
[14:03] <cjwatson> I think it's either bug 180218 or related to it
[14:03] <seb128> mpt, same color for "potential regression" and "private bug"?
[14:03] <cjwatson> Ah, bug 347279 is clearer
[14:04] <mpt> seb128, I discovered that only by accident :-)
[14:04] <cjwatson> Perhaps
[14:04] <Daviey> uploaded.
[14:04] <seb128> mpt, I see ;-)
[14:04] <mpt> for example bug 1030456
[14:04] <mpt> indeed
[14:05] <mpt> chrisccoulson, no, I was never quick enough to get a screenshot :-)
[14:06] <davmor2> mpt: screencast it?
[14:07] <mpt> good idea
[14:07] <mpt> Now, how to trigger a bug in Firefox/Thunderbird...
[14:07] <chrisccoulson> mpt, heh, it doesn't matter too much. i'll send a patch upstream for it in a bit. it's probably only a 1-line fix
[14:07] <chrisccoulson> mpt, crashme ;)
[14:07] <chrisccoulson> mpt http://code.google.com/p/crashme/
[14:08] <chrisccoulson> it even allows you to pick the type of crash to trigger
[14:08] <mpt> oh cool
[14:13] <mpt> ok, got a screencast
[14:20] <mpt> chrisccoulson, reported bug 1064423
[14:21] <chrisccoulson> mpt, thanks
[14:21] <mpt> chrisccoulson, now what should I do about the error report submission never working? Any obvious troubleshooting steps?
[14:22] <mpt> Every time, it's "There was a problem submitting your report.", both in Firefox and Thunderbird
[14:22] <chrisccoulson> mpt - are you sure the submission doesn't work? you don't get any feedback
[14:22] <mpt> and then the window disappears half a second later
[14:25] <chrisccoulson> mpt, do you have any reports in about:crashes?
[14:26] <chrisccoulson> the missing icon is my fault btw, we don't install it in the package
[14:26] <chrisccoulson> i thought you were referring to the icon on the launcher :)
[14:26] <mpt> chrisccoulson, yes, going back to January last year -- but that I can remember, it has *always* said "There was a problem submitting your report"
[14:27] <chrisccoulson> mpt, hmmm, do you use a proxy by any chance?
[14:27] <mpt> chrisccoulson, and when I follow any of the links, crash-stats.mozilla.com gives me a 404 error.
[14:27] <mpt> chrisccoulson, no, I'm at the Canonical office
[14:29] <seb128> mpt, well I guess Canonical has some proxying going on there
[14:30] <chrisccoulson> i should come in to the canonical office one day
[14:30] <chrisccoulson> mpt - ok, the icon fix was a trivial fix: http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/1396
[14:31] <mpt> seb128, elmo says no it doesn't :-)
[14:31] <mpt> chrisccoulson, \o/
[14:33] <mpt> seb128, reported bug 1064436 about the pink.
[14:35] <tkamppeter> seb128, hi
[14:35] <seb128> mpt, thanks
[14:35] <seb128> tkamppeter, hey, how are you?
[14:36] <mpt> chrisccoulson, would you like a bug report about the failed submissions? (Or should I report that at b.m.o instead?)
[14:36] <chrisccoulson> mpt, you can report it to launchpad for now
[14:38] <chrisccoulson> mpt - i guess you have libcurl3 installed?
[14:41]  * mpt wonders why "apt-cache show" doesn't show whether the package is actually installed
[14:41] <tkamppeter> seb128, fine, I want to ask you about bug 1014852. I cannot reproduce it. According to the original poster it happened right after restarting the system but /usr/lib/cups/driver/openprinting-ppds is not executed during system start.
[14:41] <mpt> chrisccoulson, yes, it's installed
[14:42] <seb128> tkamppeter, "after restarting" might be when the user get notified about the issue, it doesn't mean it's when it happened
[14:43] <mpt> chrisccoulson, reported bug 1064445
[14:43] <chrisccoulson> thanks
[14:44] <tkamppeter> seb128, what is different to my system is that the user has /usr/bin/python3.2mu and I have /usr/bin/python3. What is the difference between the two.
[14:44] <smoser> Daviey, you uploaded?
[14:45] <cjwatson> smoser: and I accepted
[14:45] <cjwatson> if you mean freeipmi
[14:45] <smoser> yes
[14:45] <seb128> tkamppeter, python3.2-minimal: /usr/bin/python3.2mu
[14:45] <smoser> thanks.
[14:45] <cjwatson> tkamppeter: python3 is a symlink to python3.2 which is a symlink to python3.2mu
[14:45] <cjwatson> in other words: nothing
[14:46] <smoser> my mirror just hadnt been updated i guess.
[14:46] <cjwatson> tkamppeter: looking only at the top line of the traceback, the difference is almost certainly locale
[14:46] <cjwatson> tkamppeter: Try with LC_ALL=C
[14:46] <seb128> tkamppeter, $ LANG=en_US python3 /usr/lib/cups/driver/openprinting-ppds list  > /dev/null
[14:46] <smoser> is there any way that those builds can be bumped in priority
[14:46] <seb128> seems to trigger it
[14:46] <smoser> i know i'm being impatient. but "start in 54 minutes"
[14:47] <seb128> or C as cjwatson said
[14:47] <cjwatson> smoser: ARM has a lot of work to do to catch up
[14:47] <smoser> cjwatson, fair enough.
[14:47] <cjwatson> smoser: I've rescored but I don't know how much difference it will makek
[14:47] <cjwatson> A bit
[14:48] <chrisccoulson> mpt, do you have a ~/.mozilla/firefox/Crash\ Reports/submit.log file?
[14:49] <mpt> chrisccoulson, yes. Except for the very first, every line is of the form "[Wed 17 Aug 2011 12:43:10 BST] Crash report submission failed: Failure when receiving data from the peer"
[14:50] <tkamppeter> seb128, cjwatson, it seems that it requires a "XXX.UTF-8" locale, on standard (non-UTF-8) locales it works. Is there a way in Python to ignore the system's locale and use ones own, for example always "en_US.UTF-8"?
[14:52] <cjwatson> tkamppeter: no; you could arrange to start it with LC_ALL=C.UTF-8 or something, but that's really the wrong answer as this is exposing a bug in this Python code
[14:52] <cjwatson> It's assuming a particular default encoding
[14:52] <cjwatson> But I don't have time to teach this now, too much critical-path stuff :(
[14:53] <jcastro_> Laney, I can confirm HP sent me a bill for September btw.
[14:53] <Laney> :(
[14:53] <Laney> lfaraone|sh: ^
[14:56] <chrisccoulson> mpt, thanks. i might have to give you a custom build to try, with more verbose output from libcurl
[14:56] <mpt> sure
[15:54] <cr3> could someone point me to a common process for maintaining the debian/changelog file? I tend to keep the next version at the top of the file, with a section for each person and a bullet for each merge request. the problem is that when a person submits two merge requests, the second one has a conflict because of the second entry in the changelog file :(
[16:02] <ScottK> cr3: The problem is that bzr doesn't handle debian/changelog's well.
[16:02] <ScottK> I think it's going to hurt no matter how you do it.
[16:02] <pitti> they are usually trivial to resolve
[16:04] <cr3> pitti: ... by a human :)
[16:06] <cr3> ScottK: would it work better if every entry had its own minor-minor version, and all those minor-minor versions would be collapsed when releasing the minor version?
[16:07] <ScottK> I don't know, but what you're doing is the right way to do a changelog
[16:07] <ScottK> Personally, I'd be worried someone would forget to consolidate them.
[16:07] <cr3> ScottK: unfortunately, it's causing lots of time doing busy work that I would rather spend doing productive work :(
[16:08] <cjwatson> cr3: bzr-builddeb comes with a plugin that automatically resolves changelog merges
[16:08] <cjwatson> or there are other tools such as dpkg-mergechangelog
[16:09] <cjwatson> (bzr-builddeb uses dpkg-mergechangelogs under the covers, in fact)
[16:11] <cr3> cjwatson: thanks, I'll definately have a look!
[16:35] <pitti> cr3, cjwatson: TBH I find that this makes things worse
[16:35] <pitti> it definitively tries (I usually don't get conflicts)
[16:36] <pitti> but it's not very good at it, cleaning up its result usually takes me longer than a simple conflict resolution would
[16:36] <slangasek> smoser: bug #1060296> I'm going to need access to a machine to reproduce this on; could you get me an instance today?
[16:37] <smoser> slangasek, i can do that right now.
[16:41] <cjwatson> pitti: certainly I prefer resolving the conflicts, but apparently cr3 doesn't )
[16:41] <cjwatson> :)
[16:42] <cr3> pitti: do you mean bzr-builddeb/dpkg-mergechangelogs makes things worse? I'm playing with it and it doesn't seem to be doing much: dpkg-mergechangelogs debian/changelog.BASE debian/changelog.THIS debian/changelog.OTHER :(
[16:42] <mitya57> cjwatson: can it happen that grub2 asks where to install itself during precise->precise upgrades?
[16:42] <mitya57> bug 1064483
[16:43] <cjwatson> mitya57: well, since you're asking, it clearly does.  It shouldn't normally, unless devices have been moved around
[16:43] <cr3> cjwatson: the reason resolving conflicts has become particularly annoying is after integrating tarmac into the review process, which handles running unit tests and merging when they pass. the merging part is failing often enough that it's causing lots of noise
[16:44] <cjwatson> mitya57: But I can't look at it now
[16:44] <Laney> cr3: A workflow I like is to have something else generate the changelog from the commit messages
[16:44] <Laney> (a workflow that I have with git-buildpackage, so no code for bzr I'm afraid)
[16:45] <cr3> Laney: that might work with git that supports something like folding commits, I think, but doesn't work as well with bzr when making one change with several commits
[16:46] <Laney> Well, you can have metadata to ignore particular changes
[16:46] <Laney> or the inverse
[16:46] <mitya57> cjwatson: so I'll ask the reporter whether they had touched their devices :/
[16:46] <cjwatson> mitya57: the leading - indicates some kind of odd bug I guess
[16:47] <cjwatson> Dunno, sorry, no mental bandwidth
[16:48] <smoser> slangasek, ubuntu@ec2-50-16-176-255.compute-1.amazonaws.com
[16:48] <smoser> and i just noticed that the problem persists after a reboot, and cloud-init will not modify /etc/fstab on second boot.
[17:32] <cr3> barry: quick python question for you: map() returns a list in python2 and an iterator in python3, so I started wondering if there was a naming convention to obviate when the caller should expect to receive a list or an iterator?
[17:36] <slangasek> smoser: this VM doesn't have / listed in /etc/mtab at all; that wasn't the symptom you supported?
[17:37] <slangasek> smoser: s/supported/reported/
[17:38] <slangasek> smoser: is the rootfs being mounted rw by the initramfs?  (didn't we have a discussion about this previously?)
[17:42] <cjwatson> Daviey,smoser: freeipmi is all built and published everywhere now; I just demoted the stray binaries on component-mismatches
[17:45] <smoser> slangasek, i would not think it is mounted rw.
[17:45] <smoser> http://paste.ubuntu.com/1269682/
[17:45] <smoser> thats console output of that instance
[17:47] <slangasek> smoser: ok
[17:48] <smoser> console shows
[17:48] <smoser> [    3.223291] EXT4-fs (xvda1): re-mounted. Opts: (null)
[17:52] <cjwatson> Does anyone know nvidia well enough to know whether http://paste.ubuntu.com/1269699/ is the right fix for a build failure?
[17:53] <pitti> hm, tseliot, but he's offline already
[17:54] <xnox> cjwatson: looks correct. haven't seen the build-failure though.
[17:54]  * xnox was fighting with pycuda once
[17:55] <xnox> cjwatson: this is pycuda... hmm.
[17:55] <cjwatson> It doesn't seem to result in /usr/lib/nvidia-current/ being hardwired into binaries, which I think is good given that my main worry was interop with nvidia-current-updates
[17:55] <cjwatson> So I think this is probably good
[17:57] <xnox> cjwatson: note my post to debian-devel. after it's build it will not be installable.
[17:58] <cjwatson> Surely if you have nvidia-current installed it does the ld.so.conf.d thing
[17:58] <cjwatson> And you might have to narrow down "my post to debian-devel" for me
[17:58] <slangasek> smoser: thanks, I see what's happening now
[17:59] <cjwatson> Oh, you mean ubuntu-devel
[18:00] <cjwatson> xnox: How's it uninstallable, then?  I just did 'dpkg -i *.deb; apt-get -f install' on my test debs in a clean chroot
[18:00] <cjwatson> And apt is happily downloading stuff rather than throwing an error
[18:03] <xnox> cjwatson: and the recommendation to s/opencl-icd/nvidia-current|fglrx/
[18:03] <xnox> cjwatson: yes. ubuntu-devel.
[18:03] <cjwatson> xnox: pycuda's dependencies don't mention opencl anywhere
[18:04] <xnox> cjwatson: wait, cuda is nvidia specific. it's the opencl which is not installable right now.
[18:04] <xnox> cjwatson: pycuda will be fine, indeed.
[18:04] <cjwatson> Right.  I don't really care about nvidia, just trying to fix build failures :)
[18:04] <ogra_> heh
[18:05] <cjwatson> OK, uploading this, thanks
[18:05] <xnox> cjwatson: do you agree with the tumbleweed's suggestion about opencl?! or is there a long history behind different package names in ubuntu/debian for these "graphics card" related packages?
[18:05] <cjwatson> xnox: I know nothing about the nvidia packaging in Ubuntu
[18:05] <cjwatson> xnox: You want tseliot for that
[18:06] <xnox> ok.
[18:21] <barry> @pilot in
[18:21] <ara> pitti, ping?
[18:22]  * ara knows is already  a bit late for pitti
[19:11] <slangasek> smoser: did I brick the VM? :)
[19:12] <smoser> slangasek, maybe.
[19:12] <smoser> it takes 4 minutes to get an update dconsole log
[19:13] <smoser> http://paste.ubuntu.com/1269837/ is what it shows right now.
[19:14] <smoser> cjwatson, does install set hardware clock ?
[19:14] <smoser> if so, where does it get its time from?
[19:16] <cjwatson> https://wiki.ubuntu.com/HardwareClock
[19:16] <cjwatson> When we wrote that wiki page we understood it
[19:16] <cjwatson> I've long since paged it out
[19:17] <slangasek> smoser: spiff.  so, it's been 4 minutes now; any sign of what it's doing?
[19:19] <smoser> http://paste.ubuntu.com/1269858/
[19:19] <smoser> General error mounting filesystems
[19:21] <slangasek> smoser: neat.  ok, let's see if I can figure out where that segfault came from, since that didn't happen here
[19:21] <smoser> slangasek, i can get you back to that system if you'd like.
[19:21] <smoser> if that would help
[19:22] <smoser> or i can just get you another
[19:22] <slangasek> smoser: I think the problem is only going to be reproducible at boot due to the nature of the race I'm trying to fix; so whatever's easiest for ou
[19:22] <slangasek> you
[19:22] <slangasek> oh, I see the bug, meh
[19:23] <slangasek> I misspelled 'mnt' - too many vowels
[19:23] <slangasek> smoser: so, I have another package to test as soon as there's a vm to test it on
[19:24] <smoser> ubuntu@ec2-54-242-41-174.compute-1.amazonaws.com
[19:24] <smoser> slangasek,
[19:24] <slangasek> ta
[19:28] <slangasek> smoser: ok, fixed
[19:34] <slangasek> smoser: dunno if you want to pick up that mountall .deb from the VM and put it through further exercising before I upload?
[19:36] <slangasek> seb128: your update-notifier upload reintroduced bug #1003100
[19:37] <smoser> slangasek, you have a diff ?
[19:37] <seb128> slangasek, "reintroduced"? :-(
[19:37] <seb128> slangasek, well, I've no code change ... is that a buggy translation?
[19:37] <slangasek> seb128: yes
[19:37] <seb128> slangasek, I basically copied the launchpad po files over the source and uploaded
[19:38] <seb128> slangasek, sorry about that, do you know why that was not fixed on launchpad as well by then to avoid that sort of issue? or how I could have seen that before uploading?
[19:38] <slangasek> seb128: unfortunately we have no sane way of marking that string as not-for-translation
[19:38] <seb128> :-(
[19:39] <slangasek> seb128: it probably wasn't fixed on launchpad because the process for getting such things fixed is opaque to me
[19:39] <seb128> slangasek, it's easy enough, it's "get $translator to edit the string"
[19:39] <seb128> slangasek, or "tell dpm and let him do magic" ;-)
[19:39] <slangasek> right, so who's $translator?
[19:40] <slangasek> this is what I mean by opaque :)
[19:43] <seb128> well
[19:43] <seb128> did you open a bug on language-pack-(gnome-)$locale?
[19:44] <slangasek> no; does that do any good?
[19:44] <seb128> well, it usually gets you a translator to fix the string on launchpad for you ;-)
[19:44] <slangasek> ok
[19:44] <seb128> can you give me the string,locale to fix?
[19:46] <slangasek> seb128: " $packages", and quite a few locales it seems :/
[19:46] <seb128> slangasek, do you have the diff or revision of the previous fix?
[19:46] <slangasek> ast gl hr ko nl pl pt_BR pt ro ru sq tr uk
[19:46] <seb128> urg
[19:46] <seb128> should we just revert my update?
[19:47] <slangasek> there are some legitimate translation updates in there too
[19:47] <slangasek> I'll hand-revert each of these
[19:48] <seb128> slangasek, thanks, and sorry about break it ... I tested before upload but only in french ... do you have any idea how to regression test that in the futur?
[19:50] <slangasek> seb128: AIUI it shouldn't be locale-dependent at all; the template that this gets applied to is a .desktop-style file containing all the translations
[19:50] <slangasek> so I would expect the error to show everywhere
[19:51] <seb128> slangasek, hum, I did dpkg -i the debs here without issues and installed upgrades since
[19:51] <slangasek> yeah, the bug only triggers when there's a notification to be sent
[19:51] <slangasek> which is only in case of failure
[19:51] <seb128> ok
[19:51] <slangasek> maybe I can quickly extend the test suite to check the template
[19:51] <seb128> it seems like the sort of things that could have a test in the source
[19:52] <slangasek> yeah
[19:52] <slangasek> ultimately the darn string needs to somehow be marked as not-for-translation, but last time I looked at this I couldn't come up with a supported way to do that
[19:56] <cjwatson> I thought I vaguely remembered suggesting one
[19:56] <cjwatson> Maybe not
[19:57] <cjwatson> I might be able to prod each of those in LP
[19:57] <cjwatson> Though that's quite a lot of URLs to click through
[19:58] <seb128> well, if you have the string number it's just replacing $string in the URL
[19:58]  * cjwatson is a translations admin for hysterical raisins
[19:58] <seb128> I think the string number is the same between locales
[19:58] <cjwatson> Oh, good point
[20:00] <cjwatson> That makes it only slightly less laborious :-)
[20:03] <Daviey> cjwatson: thanks muchly
[20:04] <ev> pitti: any idea what could be causing this? https://pastebin.canonical.com/76089/ - unfortunately I can't reproduce it, but it's in a code path entirely from inside apport-retrace. That is, by this point daisy has already written the crash report for apport-retrace to process.
[20:04] <ev> pitti: http://paste.ubuntu.com/1269950/  is the obvious solution, but seems a bit hammer-ish
[20:05] <cjwatson> slangasek: I've fixed all those in Launchpad; how well it'll stick I don't know
[20:05] <ev> err sledgehammer, that is
[20:06] <ev> but maybe we should do that anyway to guard against failing to properly encode elsewhere?
[20:09] <ev> I can't see a gap in apport's encoding either
[20:12] <slangasek> cjwatson: thanks; I'm nearly there on a test case in the source, had to reboot because I made lvm unhappy
[20:20] <slangasek> smoser: sorry, no time to split the patch out; if the binary .deb's not useful to you as-is, I'll just upload it to the queue
[20:26] <smoser> slangasek, thats fine.
[20:51] <barry> cjwatson: do you have any opinion on bug 1064279?  you changed the build-dep on libtk-img to libtiff-dev (i.e. libtiff5-dev) but that apparently broke libtk-img.  the patch suggests reverting that (which i still need to test).  your changes doesn't provide a rationale
[20:55] <sam-c> on bet ubuntu studio now
[20:55] <sam-c> on beta
[20:56] <sam-c> waiting for 12.10
[21:07] <jtaylor> barry: probably simplest to revert it
[21:07] <jtaylor> upstream has not ported to tiff5
[21:07] <jtaylor> and I guess its a bit too late to do it ourselfs
[21:07] <barry> jtaylor: that's what i'm thinking.  i'm just testing it now
[21:08] <jtaylor> I can test to, I'm using ds9 pretty much daily
[21:08] <jtaylor> nice that its in the archive now
[21:10] <slangasek> seb128: ok, update-notifier uploaded, now with test suite actually run at build time (!) and with a test that bails if the translations are broken
[21:12] <jtaylor> barry: ds9 works fine with the change reverted
[21:12] <barry> jtaylor: cool, thanks for the confirmation
[21:14] <seb128> slangasek, excellent, thanks a lot for that ;-) and sorry for breaking it...
[21:17] <cjwatson> barry: we were trying to mass-convert the archive to tiff5
[21:17] <barry> cjwatson: ah, thanks.  i've uploaded the patched package
[21:17] <cjwatson> barry: are there any rdepends?  be careful ...
[21:18] <barry> Reverse-Depends
[21:18] <barry> [21:18] <barry> * libtk-img-dev
[21:18] <barry> * mcu8051ide
[21:18] <barry> * saods9
[21:18] <barry>  
[21:18] <barry> and this does fix saods9
[21:19] <barry> libtk-img-dev has no r-d itself
[21:19] <jtaylor> cjwatson: no rdepend links depends on libtiff
[21:19] <jtaylor> should be fine
[21:20] <jtaylor> hm wait is apt-cache rdepends  recursive?
[21:20] <jtaylor> -r
[21:20] <barry> jtaylor: reverse-depends but that's not recursive afaict
[21:21] <cjwatson> no
[21:21] <cjwatson> you have to do actual analysis
[21:21]  * barry thinks someone should file a bug :)
[21:24] <jtaylor> hm ugly, but at least not so many rdeps
[21:34] <jtaylor> ok all rdepends don't link tiff
[21:35] <cjwatson> ok
[21:36] <jtaylor> didn't check dlopen though
[22:10] <alexcunn> is anyone here in charge of the beginners dev group?
[23:12] <TheMuso> @pilot in
[23:58] <barry> @pilot out