[00:13] <slangasek> bdmurray: curious - maybe it's fixed by the freetype upload which changes various bits surrounding font metrics
[00:27] <roaksoax> jdstrand: still around?
[00:28] <jdstrand> roaksoax: yes
[00:29] <ScottK> micahg: Did you ever get a chance to look into blueman?
[00:31] <roaksoax> jdstrand: quick question about creating a user for MAAS.
[00:31] <roaksoax> jdstrand: so the daemons already run as 'maas' user, WSGI for MAAS code also runs as 'maas' user. Do we need to create a home dir for the user? or can we not have a home dir?
[00:33] <micahg> ScottK: not yet
[00:34] <jdstrand> roaksoax: if it doesn't need a home dir, then no. You can specify /nonexistent as the home dir, but be sure to use --no-create-home
[00:34] <ScottK> OK
[00:35] <roaksoax> jdstrand: awesome, thanks
[00:35] <jdstrand> np
[01:04] <micahg> ScottK: blueman needs a merge, but the dh_python2 conversion was wrong, I'll file a Debian bug
[01:04] <micahg> they also transitioned to python-gi
[01:19] <ScottK> Thanks.
[02:06] <jsjgruber-x-p> I'm trying to build an app for my ppa that won't build on launchpad, but does with pbuilder-dist lucid . It has a  build-depends as follows:
[02:06] <jsjgruber-x-p> Build-Depends:
[02:06] <jsjgruber-x-p>  debhelper (>= 6),
[02:06] <jsjgruber-x-p>  python,
[02:06] <jsjgruber-x-p>  python (>= 2.6.6-3~) | python-support
[02:06] <jsjgruber-x-p> it doesn't build because it can't get the  python without trying to get the python-support instead. Is what I want reasonable?
[02:08] <micahg> jsjgruber-x-p: #ubuntu-packaging is better for random PPA build failures
[02:09] <jsjgruber-x-p> ok, thanks
[02:33] <infinity> @pilot out
[03:19] <msvb> Morning folks.
[04:53] <pitti> Good morning
[04:54] <ajmitch> morning pitti
[04:54] <RAOF> Morning pitti
[05:54] <astraljava> Hi gang, I'm trying to sort out our (Studio) bzr branches in better shape, and Micah kindly pointed out some errors with fields in debian/control. What's the proper URI for Vcs-Bzr field? Should it be 'lp:ubuntustudio-default-settings', 'lp:~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio' or the long form
[05:54] <astraljava> 'https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio'?
[05:59] <infinity> astraljava: Most seem to use the http:// URI.
[06:03] <astraljava> infinity: Ok, I'll fix ours to comply with that, then. Thank you!
[07:17] <smoser> anyone seen this ?
[07:17] <smoser> walking through installer from yesterday's iso
[07:17] <smoser> it just hang as soon as i enter the user info and hit continue
[07:18] <smoser> (i did have encrypted home)
[07:18] <smoser> er.. did select.
[07:18] <smoser> walking through installer from yesterday's iso
[07:19] <dholbach> good morning
[07:21] <dholbach> RAOF, happy birthday! :)
[07:27] <msvb> Happy birthday RAOF.
[07:28] <micahg> what's supposed to replace pcretest in the new multiarch pcre3 packages (this was dropped 2 releases ago)?
[07:28] <RAOF> dholbach, msvb: Thanks.
[07:31] <slangasek> micahg: why do you need a replacement?
[07:31] <micahg> slangasek: I've got package testing for UTF-8 support in PCRE
[07:31] <slangasek> ah
[07:32] <slangasek> can you just bundle the source as part of your test?
[07:32] <slangasek> or put it in the pcre package's own build-time test suite?
[07:32] <micahg> of the pcretest script?  probably
[07:32] <slangasek> (cf. the original bug report requesting pcretest, bugs.debian.org/162998)
[07:36]  * micahg wonders why this works in Debian
[07:59] <infinity> micahg: Sure.
[07:59] <infinity> So.
[08:00] <infinity> Why did GLIB drop that feature, or is the test for it just broken?
[08:00] <infinity> Cause either that's a glib regression, or goffice is doing something stupid.
[08:01] <infinity> (Or is it a bug and not a feature that it's looking for?  But then it wouldn't make sense to include pcre if glib isn't buggy?)
[08:01] <infinity> Confusing.
[08:01] <micahg> hmm, according to the docs it should be there
[08:02] <micahg> ah, it's the include most likely has changed
[08:02] <infinity> micahg: Could it... Yeah.
[08:02] <infinity> micahg: I was just about to suggest single include madness.
[08:02] <doko> pitti, ping
[08:03] <pitti> hello doko
[08:03] <infinity> micahg: I bet <glib/gregex.h> throws errors.
[08:03] <doko> pitti, the jockey-gtk crash did hit me yesterday
[08:06] <pitti> what is "the" jockey crash?
[08:06] <pitti> doko: is there a bug # for this with details?
[08:08] <doko> pitti, bug 804662
[08:09] <jamespage> @pilot in
[08:09] <pitti> doko: can you please file it again? it seems to be a slightly different crash
[08:12] <micahg> infinity: /me bangs head on desk (I forgot to try a rebuild :), was the single include nonsense)
[08:19] <jamespage> hmm - guess the bot knew that I'm actually piloting tomorrow
[08:19]  * jamespage goes for more coffee
[08:23] <Riddell> < Riddell> shell scriptage help needed: http://paste.kde.org/456044/
[08:23] <Riddell> that breaks on first line if more than one .pot file exists
[08:23] <Riddell> how do I get it to test for .pot file existing without breaking on more than one?
[08:24] <bryceh> Riddell, wouldn't   for file in po/*pot; sed "s/charset...   work?
[08:25] <slangasek> only if you set shopt nullglob
[08:25] <slangasek> if no files match po/*pot, you try to sed a file literally named "po/*pot"
[08:26] <slangasek> Riddell: for file in po/*pot; do if [ "$file" != 'po/*pot' ]; then sed [...]; fi; done
[08:26] <jussi> so patch pilot bot is missing because the  srever went down yesterday for some unkown reason. I need tsimpson to resstart that one (and tell me how to do it), so whoever the patch pilot today is, please adjust the topic manually.
[08:26] <Riddell> bryceh: not if the directory is empty
[08:27] <jussi> jamespage: could you direct my earlier comment to whomever is the patchpilot today?
[08:27] <bryceh> ls -l po/*pot 2> /dev/null && for file in po/*pot; do echo $file ; done
[08:29] <Riddell> if [ "$(ls -A po/)" ]; then  this seems to do it nicely
[08:30] <Riddell> every time I use bash I end up wanting to rewrite in python :)
[08:30] <slangasek> ah, but that's not bash
[08:30] <slangasek> if you were using bash, you *could* do shopt nullglob, and then you wouldn't have to check ;)
[08:38] <smoser> hey, i'm trying to run the installer (several times now) on a new laptop
[08:38] <infinity> if [ "$1" = deconfigure ]; then
[08:38] <infinity>     :; # blah, do something useful with ldso
[08:38] <infinity> fi
[08:38] <smoser> when i come to the point of adding a new user.
[08:38] <infinity> This is why I shouldn't read other people's maintainer scripts...
[08:38] <smoser> as soon as i click continue, ubiquity goes to 100% cpu
[08:38] <smoser> i'm choosing a separate /home partition and to format it.
[08:38] <smoser> is this  known?
[08:42] <RAOF> smoser: Are you perhaps running into bug #966294?
[08:43] <smoser> RAOF, that could be
[08:50] <smoser> RAOF, thank you!
[08:50] <smoser> i removed the ucvideo.ko module
[08:50] <smoser> (and then rm'd it for good measure)
[08:50] <smoser> and i'm moving on
[09:18] <pitti> Riddell:
[09:18] <pitti> +if [ "$(ls -A po/)" ]; then
[09:19] <pitti> Riddell: I think it would be more robust to use [ -n "$(ls ..)" ]
[09:19] <pitti> Riddell: also, there seems to be a missing "fi" in http://launchpadlibrarian.net/101498692/pkg-kde-tools_0.14.2ubuntu4_0.14.2ubuntu5.diff.gz ?
[09:23] <Riddell> pitti: fix uploaded
[09:36] <Adri2000> where can I find old isos? (specifically I'm looking for precise beta 1 isos)
[09:53] <Adri2000> (tried old-releases.u.c but it doesn't have precise isos)
[09:56] <cjwatson> Adri2000: we archive them to tape I think, but they aren't available anywhere public (or even easily Canonical-accessible)
[09:56] <jibel> pitti, how much memory is required to setup the virtual device in udisks test ? The test fails with 'cannot allocate memory' when modprobing scsi_debug. The highest dev_size_mb I could set with 2GB of virtual memory was 112
[09:57] <pitti> jibel: that's a good question, I'm not really sure about it
[09:57] <pitti> jibel: I would expect that 2.5 GB should be enough then, as it requests 300 MB
[10:03] <Adri2000> cjwatson: argh :/ ok... (wanted to debug an X regression post beta 1, would have been useful in order to track down the culprit packages)
[10:04] <jibel> pitti, ok, I'll start with 2.5 and increase until it passes.
[10:05] <pitti> jibel: merci
[10:05] <pitti> jibel: I'm preparing a new udisks uplaod with the missing dependencies
[10:08] <jibel> pitti, ok, thanks. postgresql test failed but it looks like a bug in autopkgtest which expand '+' to '%2B' in the package name
[10:11] <pitti> yeah, I wondered about that, it didn't even get to the tests there
[10:14] <cjwatson> yay, precise-adt-ubiquity passed
[10:15] <stgraber> cool!
[10:18] <sam-c> hello devs
[10:19] <pitti> jibel: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-adt-upower/lastSuccessfulBuild/ looks weird -- did that succeed actually, or was this a test environ failure?
[10:19] <sam-c> when does beta 12.10 start?
[10:20] <cjwatson> sam-c: https://wiki.ubuntu.com/QReleaseSchedule
[10:21] <GirlyGirl> sam-c: Its release schedule isn't finalised yet
[10:22] <cjwatson> the details haven't; you can reasonably expect it not to be too far off the above wiki page though, maybe with a week or two's shift here and there
[10:23] <jibel> pitti, it succeeded but publication to the public jenkins is slow
[10:23] <pitti> jibel: ah, I see; great to see it works now!
[10:24] <jibel> so it syncs results from the parent job first then children jobs many minutes later
[10:24] <sam-c> thanks lets hope 12.04 is a success!
[11:08] <pitti> jibel: nice, it's there now
[11:27] <doko> infinity, will you address bug 929219 before the release?
[11:28] <infinity> doko: Yeah, testing an upload now.
[11:28] <infinity> doko: Just getting a few more fixes in at the same time.
[11:29] <doko> thanks
[11:46] <ev> Am I going blind or is there no mapping (via python-apt) from a package in the cache to the path in /var/apt/cache/archives?
[11:50] <mvo> ev: there is no obvious one, iirc you need to create a acquire object, load the package into it and then you can get it via the destfilename :/
[11:50] <ev> ow
[11:50] <mvo> give me a sec (or some more and I can try to create a short example)
[11:50] <ev> mvo: cheers
[11:51] <ev> (background: I'm trying to see if any Conflicts or Replaces are already in /var/cache/apt/archives)
[11:52] <mvo> I'm not sure I understand, why is this relevant? I guess its something with ubiquity :) ?
[11:52] <ev> it looks like apt.apt_pkg.parse_depends(candidate.record['Conflicts']) will get me half way there, then presumably apt.apt_pkg.check_dep() with the destfilename version parsed out?
[11:52] <ev> mvo: apport-retrace speedup...
[11:53] <ev> mvo: https://code.launchpad.net/~ev/apport/reunpack_to_sandbox/+merge/101643 - we unpack the debs we need for retracing to a sandbox using dpkg -x. With my speedup change we cache this sandbox between runs.
[11:53] <ev> But now we need to be careful to handle replaces/depends and virtual packages therein
[11:57] <ev> oh and handling that is easy enough for the simple case. But when the Replaces and Conflicts packages have versions, then I need to parse that out (using parse_depends I guess, as above) and compare that against something in /var/cache/apt/archives - and this is where I'm stuck :)
[11:57] <mvo> ev: I see, interessting! here is a small example http://paste.ubuntu.com/926289/
[11:58] <mvo> ev: fetcher.items should always only have 1 entry with this code (auto_fix and auto_inst false) so the loop is not really needed
[12:01] <glenn> lo
[12:01] <ev> mvo: is there anything in python-apt that would then rip the version out of that path? So if I was trying to get the versions of all the packages in /var/cache/apt/archives
[12:02] <ev> I dug around and didn't see anything
[12:02] <Guest64148> how can i make sure that my package build from, would also use my dependency package from source?
[12:03] <glenn__> how can i make sure that my package build from source, would also use my dependency package from source?
[12:03] <glenn__> its a deb file on my hd
[12:03] <glenn__> is that easy? :)
[12:05] <glenn__> only thing im finding is the control file
[12:26] <pitti> apw: do we still need the bcm43xx stuff, given that we automatically install wl these day?
[12:26] <pitti> s
[12:27] <jamespage> does the data in the command-not-found-data package normally get updated just before release?
[12:27] <apw> pitti, not sure they 100% overlap to be honest
[12:27] <pitti> jamespage: yes, usually before every milestone
[12:28] <jamespage> pitti, thought that was the case.
[12:32] <pitti> apw: ah, that was it: https://launchpad.net/ubuntu/+source/linux-firmware/1.77
[12:33] <pitti> apw: /lib/firmware/phanfw.bin is the biggest file in it (1.8 MB), so that caused quite some growth
[12:34] <pitti> anyway, I suppose we can't just drop that, but at some point we need a way to split that into smaller packages
[12:34] <pitti> in 12.10 we'll get bigger images, but we need to squeeze something for 12.04
[12:35] <apw> pitti, well the problem is they are mostly firmware for things we care about, video, network, camera, that sort of thing
[12:35] <pitti> yes, I know
[12:35] <apw> pitti, it is possible that we have some old firmware in here, stuff that can never be loaded
[12:35] <pitti> right, that's what I thought, hence my question
[12:35] <apw> pitti, will discuss some potentials for ripping out for now with tim
[12:35] <pitti> in a 27 MB compressed hog there must be _something_ we can get rid of
[12:37] <pitti> apw: thanks!
[12:37] <pitti> I'll have a look at wallpapers
[12:38] <pitti> sladen: so, wallpapers grew a bit, and by yet unknown means we need to free 1.2 MB
[12:39] <pitti> sladen: do you want me to shrink down some wallpapers, or do you want to have a look?
[12:40] <seb128> pitti, it's Cimi who handled that update no?
[12:41] <pitti> not sure, sladen talked to me about it last
[12:41] <seb128> ok
[12:42] <pitti> sladen: e. g. the original Shoes.jpg (1.0 MB) looks exactly the same to my eye as my reduced Shoes2.jpg with 570 kB
[12:42] <ogra_> micahg, do you care for the lubuntu seeds ? seems audacious is blocking it on armhf and given that nobody seems to be able to fix the gles issue that blocks it i was wondering if you could do an arch specific seed hack to omit the audacious requirement on arm arches for now
[12:43] <seb128> Cimi, hey
 sladen: e. g. the original Shoes.jpg (1.0 MB) looks exactly the same to my eye as my reduced Shoes2.jpg with 570 kB
[12:43] <seb128> pitti, ^ meet Cimi, artwork master ;-)
[12:43] <pitti> Cimi: hello
[12:43] <Cimi> we both know each other seb128 :)
[12:43] <pitti> Cimi: so is it you or sladen that I should ask about ubuntu-wallpapers?
[12:43] <seb128> :-p
[12:43] <Cimi> pitti, I did the package/compression, sladen uploaded it
[12:44] <Cimi> pinky, which is the big file to you?
[12:45] <pitti> Cimi: there is no particular file, I'm just looking at ls -lSr
[12:45] <pitti> and starting with the biggest one
[12:45] <pitti> Cimi: trying to reclaim the growth of the latest version
[12:45] <Cimi> http://paste.ubuntu.com/926344/
[12:45] <pitti> (assuming that I am pinky)
[12:45] <Cimi> pitti, they all seem pretty well compressed
[12:46] <pitti> Sand.jpg compresses less well
[12:46] <pitti> Cimi: but compressing Shoes.jpg (see above) and perhaps some others would help a lot
[12:46] <Cimi> pitti, which walls are yoi looking at???
[12:46] <seb128> pitti, do you look at a different set?
[12:46] <pitti> apt-get source ubuntu-wallpapers..
[12:46] <seb128> pitti, there is no shoes or sand in the wallpapers
[12:47] <Cimi> http://paste.ubuntu.com/926344/
[12:47] <pitti> ah, we don't ship Shoes in u-w-precise, I see
[12:47] <seb128> pitti, ubuntu-wallpapers has all the old wallpapers as well but those are not installed by default
[12:47] <pitti> it's just in the source
[12:47] <seb128> pitti, they are in i.e -oneiric
[12:48] <Cimi> u-w is 2.8
[12:48] <Cimi> less than oneiric
[12:49] <Cimi> I think I did a great job here
[12:50] <pitti> Cimi: right, I missed that the source has -oneiric etc.
[12:50] <pitti> so, any other ideas what we can throw out again?
[12:50] <Cimi> pitti, we have 2.8 now
[12:50] <Cimi> pitti, really, how much do you want to shrink here?
[12:50] <pitti> no, I mean in general, not (just) wallpapers
[12:51] <pitti> i386 grew by 2 MB since beta-2, and we need to shrink it by 1.2 MB
[12:52]  * pitti looks at telepathy-salut, that grew by 0.2 MB
[12:52] <pitti> libreoffice-common grew by 0.6 MB
[12:52] <pitti> Sweetshark: ^ any idea for a diet?
[12:54] <Cimi> pitti, ubuntu-wallpapers deb was 2.4MB in oneiric and is 2.4MB in precise
[12:54] <Cimi> pitti, I did my best to keep the same size
[12:54] <pitti> Cimi: again, I'm not blaming you for anything
[12:55] <pitti> Cimi: you did a great job there
[12:55] <Cimi> pitti, ok
[12:55] <pitti> I just asked the channel for ideas what we can shrink again :)
[12:55] <Cimi> pitti, only solution I have is to remove wallpapers
[12:55] <Cimi> pitti, which works but it's not ideal with the community
[12:55] <seb128> it's not ideal for Ubuntu users either
[12:56] <seb128> users like the selection ;-)
[12:56] <pitti> at this point few things that we can do are "ideal"
[12:56] <Cimi> seb128, which wallpaper do you like most?
[12:58] <Cimi> pitti, we're not shipping the gnome wallpapers, right?
[12:58]  * apw wonders if ubuntu users like to have firmware for their hardware more or less than pretty backgrounds
[12:58] <apw> pitti, ok we may be able to strip some bnx2 firmware pretty easily but we have near zero way of knowing if thats going to cause problems
[12:59] <Cimi> apw, I would never sacrifice HW compatibility for stupid walls
[12:59] <Sweetshark> pitti: hmmm, 3.5.1-1ubuntu5 already seemed to be bigger
[12:59] <pitti> libreoffice-common (Δ 0.6 MB - 3.5.1-1ubuntu1: 20.9 MB   3.5.2-2ubuntu1: 21.5 MB)
[13:00] <Cimi> maybe libreoffice ships stuff we can compress
[13:00] <Cimi> pitti, all JPG/PNG can be compressed
[13:00] <Cimi> even loseless
[13:00] <Sweetshark> pitti: ha!
[13:01] <Sweetshark> pitti: it was readding the ugly presentationm templates again!
[13:01] <pitti> Sweetshark: win!
[13:01] <Sweetshark> (between 3.5.1-1ubuntu4 and 3.5.1-1ubuntu5)
[13:01] <pitti> Sweetshark: ah, so that's not the .6 MB from above?
[13:01] <pitti> oh wait, it could very well be
[13:01] <sladen> cimi: pitti: wallpapers is ~2.7 MB.  we were 2.5 MB last time, but we snarfed the extra after Kaleo uploaded a u-f-f without shipping Medium
[13:01] <Sweetshark> yes, it is
[13:02] <Cimi> sladen, looks like 2.4 from the website
[13:02] <Sweetshark> pitti: 3.5.2 didnt change from 3.5.1-1ubuntu5 in size.
[13:02] <Cimi> sladen, unless default wallpaper stais in a separate package from community
[13:02] <pitti> Sweetshark: that's /usr/lib/libreoffice/share/template/common/layout ?
[13:03] <sladen> Cimi: yes, default wallpaper is now in u-w, and community wallpapers in u-w-p
[13:03] <Cimi> sladen, ah ok, found mistake
[13:04] <sladen> pitti: any new packages, or just bulging at the waist in the existing packaging?
[13:05] <pitti> sladen: just the latter
[13:05] <pitti> we added gtk2-engines-pixbuf since beta-2 (0.1 MB)
[13:05] <Cimi> pitti, I can probably remove the dep from light-themes
[13:05] <seb128> no you can't
[13:06] <seb128> it was added for a reason, it spammed xsession-errors with warning without it
[13:06] <seb128> we still have gtk2 apps
[13:06] <Sweetshark> pitti: no, /usr/lob/libreoffice/share/template/en-US/presnt/*.otp
[13:06] <Cimi> seb128, is used by light-themes gtk2
[13:06] <Cimi> seb128, for old gnome-panel, old gedit, old ubuntuone gtk
[13:07] <Cimi> seb128, if I remove those, it should stop spamming
[13:07] <seb128> Cimi, nothing for firefox, tb?
[13:07] <Cimi> seb128, no
[13:07] <Cimi> seb128, let me try
[13:08] <ogra_> hmm, did dpkg --set-selections stop working in precise ?
[13:08]  * pitti runs through http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/desktop.depends again with a fine comb
[13:08]  * ogra_ cat get it to install anything
[13:08] <ogra_> *cant
[13:11] <ogra_> oh, silly me ... nevermind
[13:12] <pitti> seb128: I suppose we need rarian-compat still?
[13:12] <Cimi> seb128, pitti  lp:~cimi/light-themes/remove-pixbuf-dep-shrink-size
[13:13] <pitti> I thought we need taht?
[13:13] <Cimi> seb128, you could try removing pixbuf and running apps
[13:14] <pitti> seb128: it pulls in docbook-xml
[13:14] <seb128> pitti, is that a runtime thing? I though it was for builds
[13:14] <pitti> seb128: yes, that's what I was wondering
[13:14] <pitti> seb128: rarian-compat is explicitly seeded
[13:14] <seb128> pitti, that seems wrong
[13:17] <pitti> seb128: the only place where this would possibly be relevant is yelp, right?
[13:17] <seb128> pitti, yes
[13:17] <seb128> pitti, will old style documentation
[13:17] <seb128> pitti, maybe check with jbicha?
[13:17] <seb128> or maybe mterry knows about it
[13:18] <pitti> rarian-compat plus docbook-xml are 430 kB
[13:18] <seb128> I know he has been packaging the new yelp-xsl, etc
[13:18] <Cimi> seb128, pitti are all documentation packages assets compressed with optipng/optijpeg?
[13:18] <pitti> Cimi: yes, pkgbinarymangler does that
[13:18] <Cimi> ok
[13:18] <pitti> Cimi: for all packages, not just documentation
[13:18] <pitti> Cimi: we also optimize SVGs
[13:18]  * mterry reads
[13:18] <pitti> all that bought us some 8 MB in past cycles
[13:18] <Cimi> pitti, watch out from PNG
[13:19] <seb128> mterry, do you know if rarian-compat is a build-time only thing or use by yelp at runtime?
[13:19] <Cimi> pitti, I tried optipng with something different than -o0
[13:19] <seb128> mterry, i.e if we need it on the CD
[13:19] <Cimi> pitti, and was clearly degrading the image
[13:19] <mterry> seb128, AFAIK just build time.
[13:19] <seb128> ok, what I though as well
[13:19] <seb128> pitti, let's try dropping it :p
[13:19] <seb128> I didn't have scrollkeeper or rarian-compat installed for some months and no issue
[13:20] <seb128> but I don't use documentation a lot
[13:20] <pitti> it's a hard dep of ubunt-desktop
[13:20] <Cimi> seb128, did you have a look at my branch?
[13:20]  * pitti tries to purge it
[13:21] <pitti> ... and yelp works just fine
[13:21] <pitti> seb128, mterry ^
[13:21] <seb128> pitti, try old style documentations, those which still have an omf
[13:21] <Cimi> cool
[13:21] <pitti> ok, I'll unseed it
[13:21] <seb128> pitti, the new world order doesn't use rarian-compat for sure
[13:21] <seb128> i.e yelp-xsl yelp-tools are used nowadays
[13:22] <pitti> e. g. gnome-search-tool
[13:22] <Cimi> seb128, lp:~cimi/light-themes/remove-pixbuf-dep-shrink-size
[13:22] <seb128> Cimi, that looks fine to me
[13:23] <seb128> kenvandine, hey, what do you think about lp:~cimi/light-themes/remove-pixbuf-dep-shrink-size ?
[13:23] <pitti> seb128: works just fine
[13:23] <seb128> kenvandine, we are looking for CD space
[13:23]  * kenvandine looks
[13:23] <Cimi> seb128, kenvandine only think will break is ubuntuone control panel gtk
[13:23] <seb128> pitti, ok, I though it was a build time thing so that seems to confirm it, great, kill it!
[13:23] <Cimi> seb128, buttons will be unthemed
[13:23] <Cimi> seb128, but "who cares in 12.04"
[13:23] <pitti> seb128: *happy*
[13:23] <Cimi> we have the qt one
[13:23] <seb128> Cimi, we deprecated the gtk panel
[13:23] <Cimi> seb128, indeed
[13:23] <seb128> pitti, ;-)
[13:24] <kenvandine> how much space does it save?
[13:24] <pitti> kenvandine: 0.1 MB, not much
[13:25] <Cimi> MP https://code.launchpad.net/~cimi/light-themes/remove-pixbuf-dep-shrink-size/+merge/101735
 we added gtk2-engines-pixbuf since beta-2 (0.1 MB)
[13:25] <pitti> but it's half of what's left to do, assuming that LibO gets fixed
[13:25] <Cimi> pitti, my branch also removes some small assets so it should be slightly more
[13:25] <pitti> ah, nice
[13:25] <kenvandine> looks fine to me
[13:26] <kenvandine> we need to get rid of that stuff sooner or later anyway
[13:26] <Cimi> let's do it now
[13:26] <kenvandine> Cimi, i approved it
[13:26] <kenvandine> you merge to trunk and i'll upload
[13:26] <Cimi> kenvandine, I'll merge
[13:27] <herton> pitti, hi, now that Maverick is EOL, I think these packages from this tracking bugs will not go anymore to -updates, bugs 967065 and 967066, correct? I'll mark this bugs as invalid if so
[13:30] <Cimi> kenvandine, when you package, remember to remove pixbuf dep
[13:30] <hallyn> hey guys - I'm curious, does whoopsie[1784]: segfault at 0 ip 00000000004050a2 sp 00007fff367e5488 error 4 in whoopsie[400000+9000]
[13:30] <hallyn> mean anything to anyone?
[13:30] <kenvandine> Cimi, done
[13:30] <kenvandine> Cimi, is there a bug report related to this?
[13:30] <Cimi> kenvandine, no
[13:30] <Cimi> seb128, ^
[13:30] <Cimi> you love bug reports
[13:31] <seb128> Cimi, kenvandine: that's fine, just upload ;-)
[13:31] <kenvandine> just checking
[13:32] <pitti> herton: ah, thanks
[13:35] <stgraber> ev: ^ (whoopsie segfault)
[13:37] <pitti> hah, I found another 330 kB
[13:37] <pitti> $ cat /usr/share/hwdata/pci.ids /usr/share/hwdata/usb.ids  | gzip -9 | wc -c
[13:37] <pitti> 334112
[13:38] <pitti> we can symlink them to the versions from usb-utils/pci-utils
[13:43] <kenvandine> seb128, pitti, Cimi: light-themes uploaded
[13:43] <seb128> kenvandine, thanks
[13:43] <kenvandine> pitti, the .deb is 8K smaller
[13:43] <pitti> kenvandine: plus teh dropped dep?
[13:44] <pitti> kenvandine: thanks
[13:44] <kenvandine> yeah
[13:44] <pitti> kenvandine: so why was the dep added in teh first place?
[13:44] <kenvandine> someone added it because it caused messages to get spammed to the console
[13:44] <seb128> kenvandine, pitti: some of the old gtk2 theming file were using the pixbuf
[13:45] <seb128> that was leading the .xsession-errors spamming
[13:45] <kenvandine> it was bug 762167
[13:47] <ev> hallyn: you should have a /var/crash/*whoopsie*.crash file
[13:48] <ev> hallyn: please run ubuntu-bug /var/crash/*whoopsie*.crash and file a new bug
[13:48] <hallyn> ev: no, it wasn't me
[13:48] <hallyn> ev: it was in a qemu-kvm bug which had no qemu-kvm msgs in syslog, only whoopsie ones
[13:48] <hallyn> i've marked it as affecting whoopsie, hold on lemme find the bug # in lp
[13:49] <hallyn> ev: bug 959964
[13:50] <hallyn> I'm just wondering ifthat points to anything wrong on the host that would explain both qemu-kvm and whoopsie userspace errors
[13:51] <ev> ah, phew
[13:52] <pitti> mterry: oh, we need to disable the whole gnome-keyring test suite, not just the test(s) which cause the hang?
[13:52] <ev> looks like they hit the memory corruption bug in whoopsie from march
[13:52] <ev> it's not a new one
[13:52] <pitti> mterry: can you reproduce the hang, actually? I had assumed it was due to the buildds running hardy kernels
[13:52] <ev> but it wont explain the qemu issue
[13:56] <hallyn> drat :)
[13:56] <hallyn> I was hoping the qemu issue was some kernel resource problem causing pthread clone failure
[13:56] <hallyn> thanks
[13:56] <pitti> Sweetshark: can you make the change to drop them again?
[14:00] <mterry> pitti, no I can't reproduce
[14:00] <mterry> pitti, I disabled the whole suite.  I believe I saw different tests hanging (?)
[14:00] <mterry> pitti, but it's possible I could have been more targetted
[14:02] <pitti> mterry: I'm a bit worried about testing SRUs and point releases, on different arches
[14:02] <pitti> mterry: do you know if this ever affected armel/armhf?
[14:02] <pitti> if it is only affecting i386/amd64, there is even more reason to believe it's due to the hardy kernel
[14:03] <mterry> pitti, I only know of it happening on i386, but I don't have the full history of problems with the package
[14:03] <mterry> pitti, one thing that didn't bother me about it is that the tests were ignored on failure anyway
[14:03] <mterry> pitti, with || true.  So I didn't figure they were doing us much good to begin with
[14:04] <pitti> mterry: ah, good point
[14:26] <barry> doko: https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/979923
[14:30] <seb128> does anyone knows how to make automake not complain about
[14:30] <seb128> nobase_pkgdata_PYTHON
[14:30] <seb128> it does "Makefile.am:15: `pkgdatadir' is not a legitimate directory for `PYTHON'"
[14:31] <seb128> using "nobase_pkgpython_PYTHON" works but I don't want to move those files from /usr/share to /usr/lib just before the hard freeze
[14:33] <seb128> unping, desrt helped me using a temporary variable :p
[14:34] <doko> barry, comment added
[14:37] <barry> doko: thanks
[14:49] <rbasak> cyphermox: around? I have a fix for the libical arm ftbfs. I've attached a debdiff to bug 979846. Please can you take a look/sponsor?
[14:49] <cyphermox> wow, you rock!
[14:49] <cyphermox> sure, I'll do this now
[14:49] <cyphermox> thanks a lot for looking into this
[14:51] <dupondje> doko: around ?
[14:56] <doko> dupondje, ?
[14:57]  * ogra_ wonders how you set font sizes etc for gtk-3.0 apps if you dont use gnome nowadays ... .config/gtk-3.0/settings.ini doesnt seem to have any effect 
[14:58] <dupondje> doko: your still checking opensc? I see you uploaded a fix for it yesterday. Cause I would like to merge the newest version from debian. Cause current version in ubuntu is broken for alot of smartcards
[15:01] <davmor2> ogra_: You use the force,  go on try concentrate really really hard ;)
[15:01] <ogra_> haha
[15:02] <ogra_> well, the only thinng i read everywhere is that .config/gtk-3.0/settings.ini thing
[15:02] <ogra_> and that should essentially behave like a .gtkrc ... but it seems it doesnt
[15:02] <doko> dupondje, I wouldn't mind, but you'll need a FFe, and somebody to review and sponsor it
[15:02] <seb128> ogra_, stop not using GNOME
[15:02] <ogra_> seb128, lol
[15:02] <seb128> ogra_, what did you put in there?
[15:03] <ogra_> ogra@amun:~$ cat .config/gtk-3.0/settings.ini
[15:03] <ogra_> [Settings]
[15:03] <ogra_> gtk-font-name = Ubuntu 8
[15:03] <ogra_> but it uses Sans 11 everywhere
[15:03] <ogra_> well, in all gtk apps
[15:04] <dupondje> doko: ok thx! I know, but it could be usefull to have a working version instead of the current :D
[15:04]  * ogra_ really dislikes our font size chouces on netbooks btw ... way to big for the small screens
[15:05] <ogra_> *choices
[15:06] <doko> +1
[15:06] <dholbach> maybe you two need glasses :-P
[15:07] <dholbach> oh, too big - nevermind
[15:07] <ogra_> hehe
[15:07]  * dholbach maybe needs glasses
[15:07] <ogra_> :)
[15:07]  * ogra_ hugs dholbach 
[15:07] <ogra_> ...and ...
[15:07]  * dholbach hugs ogra_
[15:07] <ogra_> @pilot in
[15:07] <dholbach> yeeeehaw
[15:07] <ogra_> whats up with the bots recently ?
[15:08] <seb128> ogra_, with what application did you try?
[15:08] <ogra_> seb128, firefox and sylpheed
[15:08] <seb128> ogra_, they are not gtk3
[15:09] <ogra_> and xchat ...
[15:09] <seb128> neither
[15:09] <ogra_> oh
[15:09] <seb128> it would help if you tried a gtk3 app :p
[15:09] <ogra_> hmm, well, i care more for the apps i use (like the three above) ... thats all gtk-2 still ?
[15:10] <seb128> yes
[15:10] <seb128> gtkrc still work, that didn't change
[15:10] <seb128> if you want to tweak gtk2
[15:10] <ogra_> ah, great
[15:10] <ogra_> thanks seb128
[15:10] <seb128> ogra_, yw
[15:11] <ogra_> and sorry for the noise ... i should have checked the deps
[15:11] <seb128> no worry ;-)
[15:12]  * doko brings some glasses for dholbach at uds
[15:13] <dholbach> doko, shot glasses? :-P
[15:13] <ogra_> stay away from doko if he brings shot glasses ... !
[15:13]  * ogra_ remembers some bad hangovers caused by that 
[15:14]  * doko can't remember ...
[15:14] <ogra_> lol
[15:14] <dholbach> ogra_, yeah, that's probably wise
[15:14]  * ogra_ would still like to know whats up with the bot
[15:14] <stgraber> ogra_: should be added to jono's intro slide, if you want to avoid hangovers, stay away from doko during UDS
[15:14] <ogra_> @pilot in
[15:14] <apw> cjwatson, ever heard of any limits to teh size of root and that affecting grub?  we are getting 'out of space' when reading grub.cfg on one of our boxes 'sometimes' after running update-grub
[15:15] <ogra_> stgraber, only if he has shot glasses with him, otherwise its safe
[15:15] <apw> cjwatson, yet when we boot by hand the kernels open fine, and the file is fine in /boot/grub/from the booted system
[15:15] <doko> stgraber, that's the kernel team, can't beat them with hangovers ...
[15:16] <stgraber> doko: true ;)
[15:19] <cjwatson> apw: no intrinsic limits, but sometimes there are bugs in grub's fs implementations
[15:19] <apw> cjwatson, actually the grub.cfg has part of itself at LBA >32bit ...
[15:20] <apw> cjwatson, see the #ubuntu-kernel for the fibmap
[15:20] <cjwatson> that would be one plausible reason; either there's an fs impl bug where it isn't 64-bit-clean, or the relevant BIOS calls are failing
[15:20] <apw> cjwatson, /me suspects the bios ... hmm
[15:20] <cjwatson> it could well be either
[15:20] <cjwatson> BIOS or UEFI?
[15:20] <apw> legacy ...
[15:21] <cjwatson> the BIOS calls we use are allegedly 64-bit-clean
[15:21] <cjwatson> but I gather that it's not at all clear whether the BIOS implementors test this
[15:21] <apw> cjwatson, so the recommendation would be to have a /boot for this machine
[15:22] <cjwatson> yes, that would be sensible
[15:22] <apw> cjwatson, do you know what a flag of bios_grub on a partition means?
[15:23] <apw> 16:21:46      tgardner |  1      1049kB  2097kB  1049kB                        bios_grub                              │ awe_
[15:24] <cjwatson> apw: http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation, subsection on GPT
[15:24] <cjwatson> but that's for the GRUB image itself, don't confuse it with /boot
[15:25] <cjwatson> ogra_: it's OK as long as you don't let doko pour
[15:25] <ogra_> haha, true !
[15:25] <cjwatson> I was distinctly bleary one morning
[15:26]  * ogra_ remembers ... though you blamed me for it !
[15:27] <cjwatson> maybe it was your fault then, I forget :-)
[15:27] <cjwatson> that might be something to do with the GLASS FULL OF WHISKY
[15:27]  * ogra_ giggles 
[15:34] <bkerensa> cyphermox: you around?
[15:34] <cyphermox> bkerensa: yes
[15:35] <bkerensa> cyphermox: how did you want me to collect the pulseaudio logs for https://bugs.launchpad.net/bugs/972063
[15:35] <cyphermox> ah you have two choices
[15:36] <cyphermox> bkerensa: you can use pacmd and the "set-log-level 3" command to enable logging, then unpair and repair your device
[15:37] <cyphermox> or kill pulseaudio and start it again fast enough with the logging enabled ;)
[15:37] <cyphermox> the logs will be in /var/log/syslog
[15:44] <bkerensa> cyphermox: excellent I have attached those logs to the bug... let me know if you need any more info
[15:44] <bkerensa> hope to have bluetooth working :)
[15:53] <vibhav> cyphermox: ping
[15:53] <cyphermox> vibhav: pong
[15:54] <vibhav> cyphermox: Most of the bugs we worked on mbpi are fixed, how do we bring them into Ubuntu?
[15:54] <cyphermox> vibhav: already done. I uploaded a new revision two days ago
[15:55] <vibhav> ah
[15:55] <vibhav> thanks'
[16:10] <ogra_> @pilot in
[16:12] <stgraber> ogra_: ;)
[16:12] <stgraber> ogra_: you know you can change the topic yourself, right?
[16:13] <ogra_> indeed i know that... wanted to know if the bug is back
[16:13] <ogra_> err
[16:13] <ogra_> s/bug/bot/
[16:13] <ogra_> piloting has really bad sideefects
[16:15] <ogra_> micahg, did you see my lubuntu ping above ?
[16:15] <micahg> ogra_: no, let me look
[16:16] <ogra_> micahg, well, i can quickly repeat... lubuntu-desktop is uninstallable on arm atm, i was wondering if someone from the lubuntu people (assuming you are among them) unseed audacious for armem/armhf to work around that
[16:16] <micahg> ogra_: I don't personally care for them, but I believe core-dev has commit access, I'd suggest talking to the lubuntu team in #lubuntu to see what they'd like here
[16:17] <ogra_> i doubt anyone will fix the GLES issues with audacious in time, just undeeding it for arm would at least make the task installable
[16:17] <ogra_> (and i think arm is a pretty good lubuntu target ;) )
[16:19] <micahg> ogra_: sounds good, but they might want an alternate in its place, please discuss with them in #lubuntu
[16:20] <ogra_> in there already :)
[16:21] <bdmurray> Is there an archive admin who can let my upload of update-manager for oneiric-propsoed through?
[16:22] <vibhav> bdmurray: Has it been sponsered?
[16:22] <ogra_> micahg, oh, and also, do you know why there is no metapackage for lubuntu-desktop ? i can only find a task
[16:23] <micahg> ogra_: it doesn't exist on armhf, I guess no one updated the -meta properly
[16:23] <micahg> or germinate blew up during generation
[16:33] <pitti> infinity: OOI, why do we have so many armel PPA buildds?
[16:38] <doko> infinity, http://people.canonical.com/~doko/tmp/gcc-4.6.debdiff
[17:06] <jtaylor> doko: will the argparse regression be fixed soon?
[17:19] <doko> jtaylor, not anymore today, away now
[17:26] <jtaylor> I'll reopen the bug so its not forgotten
[17:30] <ogra_> @pilot out
[17:30] <ogra_> or not :P
[17:32] <larsduesing> A small question - where to put sort of wishlist/thoughts about getting a package better in Q* ?
[17:32] <larsduesing> in a "bug"?
[17:44] <ScottK> Yes.
[17:52] <yofel> slangasek: where should I put the splash update?
[17:52] <slangasek> yofel: lp:ubuntu/plymouth, or a merge proposal thereon
[17:52] <yofel> coming
[20:38] <slangasek> anyone here understand what's going on with rosetta in bug #978724?  because having to rebuild .pot files at build time is definitely the wrong answer
[20:52] <seb128> slangasek, not sure, I can check with dpm tomorrow, launchpad should the pot which is available at the end of the build
[20:52] <slangasek> seb128: right, that was my understanding
[20:53] <slangasek> seb128: is there a better view than https://translations.launchpad.net/ubuntu/precise/+imports?field.filter_status=all&field.filter_extension=pot for finding the files?
[20:54] <seb128> slangasek, I see nothing weird on https://translations.launchpad.net/ubuntu/precise/+source/update-notifier/+pots/update-notifier/+admin
[20:54] <seb128> slangasek, different issue but update-notifier has buggy intltool usage
[20:54] <seb128> https://launchpadlibrarian.net/101084855/buildlog_ubuntu-precise-i386.update-notifier_0.119ubuntu6_BUILDING.txt.gz
[20:55] <seb128> it has a bunch of
[20:55] <seb128> "/usr/bin/intltool-merge ../po/da.po ../po/de.po ../po/el.po ../po/es.po ../po/fi.po ../po/fr.po ../po/hu.po ../po/ja.po ../po/pl.po ../po/pt_BR.po ../po/ro.po ../po/sv.po ../po/zh_CN.po
[20:55] <seb128> Usage: intltool-merge [OPTION]... PO_DIRECTORY FILENAME OUTPUT_FILE"
[20:55] <slangasek> hmm
[20:55] <seb128> oh
[20:56] <seb128> slangasek, debuild clean remove the pot
[20:56] <ahasenack> hi, can somebody please nominate this bug for lucid, natty and oneiric? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/978884
[20:56] <slangasek> seb128: hah
[20:56] <slangasek> seb128: ok, thanks, I'll fix
[20:56] <seb128> slangasek, yw
[20:59] <slangasek> seb128: where do you see that though?  I don't see it in the log
[21:00] <seb128> slangasek, I noticed that locally when trying to rebuild it, maybe it's not the issue on the buildds
[21:00] <slangasek> mmk
[21:01] <seb128> slangasek, oh
[21:01] <seb128> slangasek, pkgstriptranslations: update-notifier is blacklisted, not stripping
[21:01] <seb128> slangasek, I wonder if that's due to that
[21:01] <seb128> slangasek, I bet it is
[21:02] <slangasek> they shouldn't be stripped
[21:02] <slangasek> and I didn't think rosetta relied on pkgstriptranslations for pots
[21:03] <seb128> yeah, me neither
[21:03] <slangasek> ok, I'll try to dig there, thanks
[21:03] <seb128> slangasek, I would say, do an upload to a ppa with a ls po at the end of the build just to see if the pot is still there
[21:03] <seb128> slangasek, I will check with dpm tomorrow, but it's weird indeed
[21:04] <seb128> slangasek, meanwhile I can upload the current template if you want using the web ui
[21:07] <slangasek> seb128: oh!  that would be swell, thanks
[21:12] <seb128> slangasek, done
[21:12] <slangasek> ta!
[21:16] <roadmr> hey! does anyone have a minute to have a look at this merge request? it's been reviewed by translators, the release team and is marked as sponsored. https://code.launchpad.net/~roadmr/ubuntu/precise/checkbox/0.13.7/+merge/101783 thanks!
[21:28] <bkerensa> cyphermox: did you see anything odd in that log?
[21:28] <micahg> ahasenack: I'm reluctant to give you the tasks without SRU approval as there's no Microrelease exception from what I can see
[21:30] <micahg> ahasenack: you probably should apply for this for landscape: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[22:11] <bdmurray> where does details in system settings come from?
[22:12] <stgraber> bdmurray: gnome-control-center I'd guess
[22:19] <bdrung> doko: more multiarch fun: bug #980351
[22:19] <doko> bdrung, https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[22:21] <bdrung> thanks
[23:02] <maxb> Is there anyone who can moderate my ubuntu-devel@ email, subject "Request for advice - subversion FTBFS in precise
[23:03] <maxb> ? - it's a little bit time critical since it's discussing things to be done before release
[23:03] <micahg> maxb: have you talked to Daviey yet about 1.6.18, does it fix the issue?
[23:03] <maxb> micahg: No, it does not fix the FTBFS
[23:04] <maxb> So, fixing the FTBFS becomes something we probably want to do anyway, whether or not we get 1.6.18 in
[23:04] <micahg> indeed
[23:06] <maxb> I'm uncertain whether an upstream fix for the FTBFS for 1.6.x will be forthcoming or not, or whether the advice will be to stick with APR << 1.4.6 if you care about the testsuite for 1.6.x
[23:07] <maxb> And even if there is an upstream fix, it will likely be in the form of a *massive* patch adding sorting of results all over the testsuite
[23:08]  * micahg wonders why Debian wouldn't have the same issue
[23:08] <maxb> micahg: I expect they will
[23:08]  * maxb goes looking for a Debian rebuild test
[23:13] <bkerensa> mpt: What is your proposal for Bug #962974
[23:14] <maxb> Can't find a recent Debian full archive rebuild by googling, but I'm sure the same problem holds true
[23:28] <ahasenack> micahg: landscape-client has an exception: https://wiki.ubuntu.com/StableReleaseUpdates#Landscape
[23:29] <micahg> ahasenack: ah, ok, I"ll give you the tasks then :)
[23:29] <ahasenack> micahg: thanks
[23:29] <micahg> ahasenack: done
[23:30] <ahasenack> micahg: thanks a lot
[23:30] <micahg> ahasenack: sorry, I would've done it yesterday had I remembered it had an exception
[23:30] <ahasenack> micahg: np
[23:31] <ahasenack> I'm persistent :)