[00:29] <slangasek> YokoZar: any luck with ia32-libs multiarching?
[00:35] <directhex> wow, that sounds nice & easy
[00:36] <slangasek> hmm?
[00:38] <RAOF> directhex: Shouldn't be *that* hard, right?  “Just” pull in /usr/lib/i386-whatever-triplet/ :)
[00:44] <YokoZar> slangasek: I took a look at it and it looks a bit difficult.  But it needs to be done, possibly before release even.  Mind if I pass this off to you?
[00:46] <YokoZar> slangasek: Although if it's as simple as "also look in (32-bit-triplet) and copy all libs there to /usr/lib32" then maybe I'm mistaken...
[00:46] <YokoZar> slangasek: hopefully there aren't any non-relative-path surprises and such in there
[00:46] <Laney> stgraber: I just noticed that the DMB isn't an administrator of ~edubuntu-dev
[00:54] <RAOF> Laney: Is it possible to get the DMB to vote on my application via email or something?  Staying up/waking up to attend a meeting that doesn't happen or doesn't get 'round to me is getting kinda old :)
[00:54] <psusi> anyone have any idea why on earth reinstalling nautilus would reset apps/metacity/general/button_layout back to the old menu:minimize,maximize,close setting?
[00:57] <slangasek> YokoZar: it really is as simple as "also look in {/usr,}/lib/i386-linux-gnu/ and copy all libs there to /usr/lib32"
[00:58] <Laney> RAOF: Yeah, I feel for you, and was thinkign about that earlier. I wonder if we could instead 'invite' applicants to a particular meeting so that they can actually know when they will be interviewed...
[00:58] <slangasek> YokoZar: but if you want me to look at it I can
[00:58] <ion> ia32-libs “multiarching” doesn’t mean “destroying forever”? :-P
[00:58] <Laney> RAOF: If you mail the DMB list then we'll work something out though (and it will let me raise this issue)
[00:58] <slangasek> ion: not in one cycle it doesn't
[00:58] <slangasek> ion: not given how long ia32-libs has been allowed to fester and continue accumulating libs
[00:59] <ion> aye
[01:02] <slangasek> $ dpkg -L ia32-libs|grep -c 'lib32/[^/]\+\.so'
[01:02] <slangasek> 743
[01:02] <slangasek> :P
[01:19] <Chipzz> slangasek: wtf? :p
[01:19] <Chipzz> does that include the symlinks too?
[01:19] <slangasek> YokoZar: if you do want me to look at it, please say so explicitly :)
[01:19] <slangasek> Chipzz: it includes whatever that regexp matches, I didn't filter too hard
[01:19] <Chipzz> slangasek: ah, so prolly /3 then :)
[01:20] <slangasek> yeah, dpkg -L doesn't distinguish between files and links
[01:20] <Chipzz> ~250 libs, still pretty bad :/
[01:21] <broder> an upstart task triggers stopped/stopping events when the exec/script block exits, right?
[01:21] <slangasek> dpkg -c ~archive/pool/universe/i/ia32-libs/ia32-libs_20090808ubuntu9_amd64.deb |grep -c '^-.*lib32/[^/]\+\.so'
[01:21] <slangasek> 248
[01:21] <slangasek> broder: yes
[01:22] <broder> hmm...i think i need to get better logs to figure out what's going on, then
[01:23] <slangasek> broder: actually, no, sorry
[01:23] <slangasek> broder: I confused myself - a task is "started" when the job finishes
[01:23] <slangasek> and not before
[01:25] <broder> so a task goes to the "starting" state, then it runs and stays in "starting", then goes to "started" when it finishes running?
[01:28] <slangasek> broder: yes
[01:30] <slangasek> er... maybe
[01:30] <slangasek> ok, I don't know ;)
[01:30] <broder> haha, ok :)
[01:30] <slangasek> if I look at jobs that are tasks that definitely ran at boot time, they're in state 'stop/waiting'
[01:30] <broder> i'll harrass SpamapS and the other people working on the upstart cookbook to figure out and clarify
[01:31] <broder> right, that's what i was looking at
[01:31] <slangasek> and those jobs should, barring bugs, emit stopping/stopped events at the end
[01:31] <broder> as a guess, maybe tasks skip the running, pre-stop, stopping, killed, and post-stop states and go straight from spawned to waiting?
[01:32] <slangasek> could be, but I think that would be inconsistent with the use of 'post-stop' scripts in several of the jobs
[01:32] <broder> ok, you've officially got me digging through source code now, so report back on what i find :)
[01:41] <broder> ugh. i might not have acquired enough of the upstart zen to know what's going on here
[01:44] <broder> ah - but the logs might clarify what's going on
[01:46] <broder> or maybe not, because all of the tasks in the normal boot happen before syslog is up
[01:47] <broder> but certainly tasks transition through the running -> stopping -> killed -> post-stop -> waiting series of states
[01:57] <YokoZar> slangasek: how's your bandwidth?  Can you upload the 800+ meg source package?
[01:57] <slangasek> if I have to
[01:57] <slangasek> I'd rather just send you a patch ;)
[01:57] <YokoZar> slangasek: That works best for me :)
[01:57] <slangasek> a patch does?
[01:57] <YokoZar> yeah
[01:57] <slangasek> ok
[01:58] <YokoZar> Then I'll add the libraries I need and make a huge upload overnight
[02:10] <psusi> it seems to me like prefixing patches with a number is a carryover from dpatch... or should 3.0 (quilt) patches also be numbered?
[02:11] <broder> psusi: i tend to prefer them because it makes the order obvious just from "ls" instead of having to look at the series file. but there's no technical requirement. though obviously if you're patching somebody else's package you should follow existing style
[02:12] <psusi> broder, does order really matter?
[02:12] <broder> psusi: sometimes. usually it's something like ubuntu is changing something that debian already changed
[02:12] <psusi> I mean yea, sometimes it does, but when you're just doing an ls to see what's there, do you normally care about the order?
[02:14] <broder> it's no less valid of an order than the mostly arbitrary order imposed by the names of the patches
[02:20] <RAOF> Bah.  Stupid interaction of 3.0(quilt) and vcs!
[02:23] <RoAkSoAx> win 24
[02:24] <RAOF> ETOOMANYIRCCHANNELS
[02:24] <ion> lose 25
[03:51] <RAOF> @pilot out
[04:06] <ScottK> RAOF: Is there any other kind of 3.0(quilt)/VCS interaction defined?
[05:58] <twb> Who has point for LibreOffice packaging: Debian or Ubuntu?  That is, who syncs from whom?
[06:05] <jmg> hi all
[06:06] <jmg> any reason i wouldnt be able to use fglrx on casper with persistent changes
[06:07] <jmg> i really desperately need it or the radeondump tool which doesnt appear to be included anywhere in the earchive
[06:47] <slangasek> YokoZar: bug #744767
[07:44] <broder> slangasek: man, that multiarch command sequence from your blog is *awesome*
[07:45] <slangasek> disclaimer: running it on your desktop eats your desktop.  Enabling multiarch at all on your desktop eats update-manager and anything else that uses python-apt
[07:45] <broder> haha. cest la vie
[07:45] <slangasek> although for the former issue, I have all the needed bits in ppa now
[07:46] <infinity> Isn't the death of python-apt pretty much the result of nearly any and all toolchain fiddling in the history of... Ever?
[07:46] <infinity> (Well, packaging toolchain... And occasionally C++... And... Yeah, I'll stick with "all")
[07:46] <slangasek> module gtk+2.0, which the buildds won't give me for another 2 hours or so
[07:46] <slangasek> s/module/modulo/
[07:46] <slangasek> infinity: heh
[07:47] <broder> slangasek: if you need help, i'm hoping to be able to take friday off of work to go to jono's global jam
[07:49] <slangasek> broder: we're at kind of a curious point where there's not much more to usefully do until dpkg 1.16.0 hits unstable
[07:49] <broder> sure, just figured i'd throw it out there
[07:49] <StevenK> infinity: Your bitterness is showing
[07:49] <StevenK> Er, more showing
[07:50] <slangasek> nothing else can (or should) go into natty now during the freeze; I'm done putzing around in my ppa now that I have everything there needed to install flashplugin; and nothing happens in Debian with it until the bootstrap kicks off
[07:50] <slangasek> so because I'm out of major things to do for multiarch, that's the time I'll blog instead ;)
[07:50] <infinity> StevenK: Rumours of my bitterness have been greatly exaggerated for comedic effect.
[07:52] <StevenK> infinity: No, they haven't. :-)
[07:55] <pitti> Good morning
[07:57]  * slangasek waves to pitti 
[07:58] <broder> hmm...what's the best way to test a priori if plymouth is going to be able to use the graphical vs. text theme? look for /dev/dri?
[07:59]  * infinity pokes pitti with a stick.
[08:07] <cdbs> dholbach: Good morning
[08:07] <dholbach> good morning
[08:07] <dholbach> hey cdbs
[08:09] <infinity> dholbach: Hai.
[08:09] <dholbach> hey infinity
[08:09] <dholbach> infinity, MAN - long time no see
[08:09]  * dholbach hugs infinity
[08:09]  * infinity hugs dholbach.
[08:09] <infinity> I've decided to come back to annoy you.
[08:09] <dholbach> hahaha, awesome :)
[08:15] <soren> infinity: Dude!
[08:16] <infinity> soren: *wave*
[08:16] <infinity> sabdfl: I've lost track, are you in a disconnect storm, or actually joining the channel? :P
[08:16] <infinity> sabdfl: If the latter, "hi".
[08:16] <pitti> hey infinity, how are you?
[08:17] <sabdfl> infinity: adventures in multi-device connectivity here :-)
[08:17] <sabdfl> how are you, long time no speak
[08:17] <infinity> pitti: Alive and well.  And I think this is more than I've typed in #ubuntu-devel in two years.
[08:17] <pitti> lol, yes
[08:17] <infinity> sabdfl: See above? :)
[08:17] <sabdfl> timezones still seem unchanged ;-)
[08:17] <soren> I'm sure we can pull up some stats on that.
[08:17] <sabdfl> hey soren
[08:17] <soren> sabdfl: o/
[08:18] <soren> sabdfl: I though you were in a very different timezone these days
[08:18] <didrocks> good morning
[08:18] <soren> thought, even.
[08:18] <soren> Specifically, one that does not warrant being awake right now :)
[08:19] <infinity> sabdfl: And yeah, I'm still timezone challenged.  I don't imagine this is something that will ever change.
[08:20]  * mvo waves to infinity
[08:21] <infinity> mvo!
[08:21] <infinity> Okay, now I'm getting all sentimental.
[08:39] <YokoZar> slangasek: universe libs only in ia32-libs yes?
[08:40] <slangasek> YokoZar: hmm?
[08:40] <YokoZar> slangasek: eg can I add gstreamer0.10-plugins-ugly or just gstreamer0.10-plugins-good
[08:41] <slangasek> oh, do you mean *main* only rather than universe? :)
[08:41] <slangasek> there are both main and universe libs in ia32-libs
[08:41] <YokoZar> err no I mean "not multiverse"
[08:41] <slangasek> neither of those are in multiverse
[08:42] <slangasek> ia32-libs is in universe, so you can't add anything from multiverse to it, yes
[08:42] <slangasek> not that I think you should really add anything more to it at all, but hey
[08:42] <YokoZar> but ugly plugins are in universe you say
[08:42] <slangasek> yes, the good/bad/ugly split of the packages has to do with code quality and support, not freeness
[08:43] <YokoZar> ok that makes me feel better
[08:46] <dholbach> RAOF, happy patch pilot day
[08:48] <pitti> ogra_: did you want to keep rhythmbox on the armel ubuntu-netbook images? If so, can you please seed it appropriately?
[08:48] <pitti> ogra_: if not, I'll add it to supported (it currently wants to go to universe, but we want to keep it in main until the next LTS)
[08:51] <sabdfl> soren: no, i'm trying to narrow my timezones! where did you think i was?
[08:51] <soren> sabdfl: I heard a rumour about US East coast. New York or something.
[08:53] <sabdfl> ah, yes, i have bought a place there, it's about as far from GMT as I'd like to live
[08:53] <sabdfl> going to take a while to get it fixed up though
[08:53] <sabdfl> i'm concentrating on Isle of Man and Cape Town at the moment
[08:53] <sabdfl> and my little tropical love affair
[08:56] <soren> sabdfl: Sounds lovely!
[09:03] <tkamppeter> slangasek, hi
[09:41] <YokoZar> Why are there binaries for libx264-98 still in archive when source package x264 provides libx264-106 instead now?
[09:43] <mok0> I have written a system for disk quotas that makes use of libnotify. When your disk quotas are exceeded, you get a pop-up warning and is prompted to clean up your disk usage. I am looking for other ubuntu-devs that might help take it a step further for inclusion in Ubuntus server infrastructure	
[09:43] <pitti> YokoZar: see http://people.canonical.com/~ubuntu-archive/nbs.html
[09:43] <pitti> YokoZar: the old packages still have rdepends, they need some transition uploads
[09:44] <YokoZar> pitti: in this case, all on ppc...
[09:44] <RAOF> Man, libx264.  Because ABIs are hard! :)
[09:45] <ohsix> yes
[09:46] <ohsix> ffmpeg too D:
[09:46] <mvo> dpm: is bug #744831 something that should be on langpack-o-matic or is it in the right place?
[09:46] <ohsix> RAOF: both are windows centric and assume you do a source checkout and use it as is in your software
[10:37] <janimo> does it make sense to have upstream bugs open in LP  (Also affects project ) if the Ubuntu packages have been fixed for all series involved?
[10:38] <janimo> for instance linaro/ubuntu gcc has fixes not yet upstream, so we have a gcc bugtask open on some bugs
[10:38] <janimo> ex: https://bugs.launchpad.net/gcc/+bug/398403
[10:41] <janimo> doko, ^ ?
[10:43] <doko> hmm, linaro uses a project linaro-tracking ... (or something like this)
[10:43] <doko> lool: ^^^
[10:46] <cjwatson> infinity: hi!  awesome.
[10:46] <dpm> mvo, yeah, I think langpack-o-matic would be the right place for bug 744831, pitti, what do you think?
[10:47] <ogra_> ogra@panda:~$ archdetect
[10:47] <ogra_> armel/unknown
[10:47]  * ogra_ scratches head
[10:48] <ogra_> i thought we had panda support in archdetect
[10:48] <pitti> dpm, mvo: erk, because packagekit moved; yeah, need some extra replaces, I think
[10:49] <pitti> mvo: how much does this break update-manager? (didn't it use to ignore file overwrites, or retry a few times?)
[10:49] <pitti> asking because rebuilding all -base packs will take a looong time
[10:50] <pitti> bug updated
[10:54] <ogra_> bah, cpuinfo strings changed
[10:54] <mvo> pitti: its only a issue for people upgrading manually so not beta1 critical
[10:55] <pitti> mvo: ok, thanks; milestoned to b2 now
[10:56] <mvo> thanks
[11:03] <ricotz> hello, is there something wrong with apt or ubuntu repo? it seems apt doesnt recognize if the package lists have really changed and downloads all lists everytime.
[11:06] <lool> janimo: Sorry, not sure what you're trying to solve
[11:07] <janimo> lool, to reduce the number of bugs listed as needing attention in ubuntu, while triaging
[11:07] <lool> doko: I think linaro-tracking is a bit of a hack to track which upstream commits fix the bug; it's more of a trick
[11:07] <lool> janimo: If the bug is fixed in the Ubuntu package you certainly should close the Ubuntu task
[11:07] <janimo> even if our packages are fixed, if there's an also affects project with upstream bugtracker open ticket, we get that bug listed
[11:08] <tkamppeter> pitti, can you upload CUPS from BZR, to get the fix/workaround for bug 710881 into the beta? Thanks.
[11:08] <lool> janimo: That sounds like a bug in the script?
[11:08] <pitti> tkamppeter: doesn't sound critical for the beta release (not important enough to delay it, anyway)
[11:08] <pitti> tkamppeter: I'll upload it after b1
[11:08] <janimo> lool, LP ui, not sure what script is involved
[11:08] <lool> janimo: Can you give me a sample URL?
[11:09] <janimo> LP for instance this appears in the list of bugs of armel-porters https://bugs.launchpad.net/gcc/+bug/398403
[11:09] <pitti> ricotz: hm, confirmed here
[11:09] <janimo> even if it is only a Gcc 4.3 upstream task involved
[11:10] <ricotz> pitti, ok ;), so it is an apt or archive problem
[11:11] <lool> janimo: But where did you get this bug from?
[11:11] <lool> janimo: it seems to me you're searching all bugs in launchpad tagged armel instead of just the Ubuntu ones?
[11:11] <htorque> pitti, ricotz, maybe bug 677733?
[11:11] <lool> janimo: Technically, this bug is still open upstream
[11:12] <janimo> lool, I think I went to armel ubuntu porters and listed bugs associated to them
[11:12] <janimo> indeed it is still open upstream
[11:13] <janimo> I find upstream/debian bugtasks useful until we do not have a fix ourselves as somethign to track and pick a fix from
[11:13] <janimo> when we have it fixed I see no point in keeping that open, especially since upstream/debian do not use LP for bugtracking
[11:13] <janimo> it is noise
[11:15] <pitti> ogra_: libuqpanel0 unity-2d-default-settings binaries (from unity-2d) want to go into universe; don't you need the settings one in a seed somewhere?
[11:16] <ogra_> pitti, our settings are in unity-2d itself, both are transitional packages ...
[11:16] <lool> janimo: So perhaps you want to write some launchpadlib script which queries bugs for ~ubuntu-armel and excludes the ones where there are only tasks open on projects which don't use Launchpad for tracking bugs?
[11:17] <lool> janimo: In the worst case, you could have a project blacklist if that's not exposed by the API
[11:17] <pitti> unity-2d-default-settings |        0.4 | natty/universe | source
[11:17] <pitti> unity-2d-default-settings | 3.8.1-0ubuntu1 |         natty | all
[11:17] <pitti> oh, fun
[11:17] <janimo> lool, ah certainly. I just with LP UI itself was cleaner
[11:17] <ogra_> pitti, i'm not really sure what to do with them, only people using natty already or people that used the PPA earlier could have these packages
[11:17] <pitti> ogra_: ^ i. e. universe has a newer version than main
[11:17] <pitti> ogra_: so if at all they are ok in universe
[11:17] <ogra_> why is 0.4 newer than 3.8 ?
[11:17] <pitti> ogra_: but I'd like to remove the unity-2d-default-settings source package then
[11:18] <pitti> ogra_: sorry, ignore me
[11:18] <janimo> lool, I can only image the irrelevant bugtasks if people would be conscious enough and add a lot of affects opensuse/fedora buglinks to all issues :)
[11:18] <ogra_> yes, that definitely can go
[11:18] <pitti> ogra_: ok, thanks
[11:18] <lool> janimo: ?
[11:19] <ogra_> pitti, thanks for the heads-up :)
[11:19] <lool> janimo: Keep in mind the bug tracker is just a tool, you don't need to actually log all issues against all projects in the bug tracker, you always have the option to just fix the bug and not 'track' it; that's true for upstream/downstream and across distros too  :-)
[11:19] <pitti> ogra_: done; while I have you, are you the right person to ask about the linux-tools-omap4 and x-loader-omap3-overo packages on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
[11:19] <janimo> lool, many bugs presumable affect other distros. There's a possibility in LP to link to similar bugs in their respective trackers. If done, even if Ubuntu gets fixed, the bug remains open until all linked projects/distroes are fixed as well
[11:20] <ogra_> the latter should be in universe
[11:20] <pitti> ogra_: moved
[11:20] <ogra_> for linux-tools, i guess you need to ask the kernel team if we need them
[11:20] <ogra_> i'll happily seed them if so
[11:20] <janimo> lool, I agree. That is why I think tracking has value until you actually track development elsewhere and waiting for a fix, and those need to be closed when Ubuntu package is fixed.
[11:22] <lool> janimo: Sure, sometimes it's the other way around: people using LP just care about the upstream part of the bug and not the downstream ones; you're in the specific case that you only care about the Ubuntu state and you didn't particularly filter for it; the Launchpad web UI might not give you the right thing out of the box, but you can create your own custom report to work around this?
[11:22] <lool> I'm pretty sure you could search Ubuntu bugs where ubuntu-armel is sub-ed though
[11:22] <janimo> lool, https://bugs.launchpad.net/~ubuntu-armel this is what I looked at. It still lists issues which are either not closed upstream, or which LP cannot figure out if they are closed or not
[11:23] <lool> janimo: http://goo.gl/b8Xk1
[11:25] <lool> janimo: Basically you're asking for "all project Launchpad knows about"; you can filter with "just Ubuntu" or come up with something more precise (perhaps Ubuntu and some list of projects you care about), or blacklist (all Launchpad projects except the ones which don't track bugs in Launchpad); the latter isn't an option in the search, but perhaps you could ask for that to be added (it sounds a bit too specific though)
[11:25] <janimo> lool, thanks. I never bookmarked/created custom reports. I guess I still expect LP to be intuitive to use by default :) . For instance ubuntu-armel should not be shown a valgrind bug which is fixed in Ubuntu
[11:25] <tkamppeter> pitti, OK.
[11:26] <lifeless> janimo: we're working on it :)
[11:26] <janimo> lifeless, good to know :)
[11:28] <lool> janimo: Well, you're the one who knows "ubuntu-armel" only cares for Ubuntu
[11:29] <lool> janimo: The link I pasted doesn't list it, does it?
[11:29] <janimo> lool, it does not indeed
[11:29] <lool> janimo: I went to bugs.launchpad.net/ubuntu, hit Advanced search and put "ubuntu-armel" in Subscriber; that's it
[11:30] <lool> Of course now you're going to tell me you miss the other projects you care about and which track bugs in Launchpad  :-)
[11:32] <janimo> lool, not really. I miss an easy to use interface which does not need advanced search by default. I am sure not all the things I expect from LP UI needs reading the user's mind to be more useful
[11:33] <janimo> actually the also affects project by default is what seems most redundant to me. Along with bugs appearing more than once in lists because of it. It makes sense for LP to keep track, but from a UI PoV I find that less helpful
[11:33] <jibel> pitti, is there a way to stop the retracer aggregating all kind of unrelated ubiquity failures to bug 652916
[11:34] <lool> janimo: Ok; I guess this is quite far away from gcc/gcc-linaro/Ubuntu gcc at this point and more of a discussion you should have with Launchpad folks
[11:35] <janimo> right
[11:35] <pitti> jibel: you mean all those debconf bugs have a different cause?
[11:36] <pitti> jibel: I guess the best option would be to catch the error in ubiquity and then raise a more specific error (e. g. including the package name that is being configured, etc.)
[11:36] <pitti> shana: here?
[11:36] <shana> pitti: morning!
[11:36] <jibel> pitti, I reviewed some a them and a common pattern is that when there's a faulty media, memory corruption, no space left, ... ubiquity triggers this error
[11:37] <pitti> shana: morning, how are you?
[11:37] <pitti> shana: I just finished building webkit svn trunk again (this time with introspection enabled), and had a look
[11:37] <shana> pitti: a bit coffee-deprived, but otherwise good
[11:37] <pitti> shana: to my surprise, glib:signal name="hovering-over-link" is actually in the .gir *twice*
[11:37] <pitti> shana: once with wrong dummy argument names, the second one is the correct one
[11:37] <shana> sorry about not opening the bug yet, soc has been siphoning all of my time
[11:38] <shana> pitti: orly??
[11:38] <shana> hmmm
[11:38] <pitti> shana: but both have <type name="utf8"/> which seems fine?
[11:38] <cjwatson> pitti: unfortunately the thing that notices is on the other side of a pipe from what could provide more information
[11:38] <cjwatson> pitti: the error means "the debconf frontend I was talking to fell over"
[11:38] <shana> pitti: <type name="utf8" is not enough, that's a generic name, it should have c:type="gchar*"
[11:39]  * shana opens up gir files
[11:39] <pitti> shana: why?
[11:39] <pitti> cjwatson: is there any way we could extract more useful information out of this after the crash happened?
[11:40] <shana> pitti: this is what the one I have on the system (webkit 1.2.5) has for that signal: https://gist.github.com/892145
[11:40] <pitti> shana: (btw, only gchar* is translated to "utf8", so you can actually assume that)
[11:40] <shana> of course, I can map those new type names, I guess
[11:41] <pitti> shana: do you depend on always having the c:type one?
[11:41] <shana> pitti: I did, since every single entry on the gir file has one
[11:41] <pitti> shana: ok; I guess as a first step I'll track down why it appears twice
[11:41] <shana> it's a standard on every parameter on every method, every type, everything
[11:42] <cjwatson> pitti: the problem is that multiple python processes crash; we get useful tracebacks from the other one ...
[11:42] <pitti> cjwatson: ah, we do? so perhaps we should just generally ignore this crash on the ubiquity side then?
[11:43] <shana> pitti: take a look at the gist again, I added a comment with other entries on the gir file
[11:43] <pitti> cjwatson: the ubiquity hook is in the apport source, so I could tweak stuff there
[11:43] <cjwatson> pitti: maybe, DebconfCommunicator is started in a load of different place
[11:43] <cjwatson> s
[11:43] <shana> pitti: utf8 is mapped as gchar* in some places, gchararray in others
[11:43] <cjwatson> actually, it's pretty odd that that particular one is relevant to anything
[11:44] <cjwatson> pitti: I'm not absolutely certain, but on the whole I suspect ignoring that one would improve our bugs
[11:44] <pitti> shana: ok, I'll have a look at the ctypes ones as well, but that sounds a little out of my current knowledge
[11:44] <shana> pitti: since we map native types when invoking native methods (mono does that by default and gtk-sharp adds some extra layers), that info is important
[11:45] <pitti> cjwatson: we currently only have a mechanism for saying "sorry can't report this", we can't silently analyze and discard a crash
[11:45] <pitti> cjwatson: but I guess that would already be an improvement
[11:45] <cjwatson> in this case, what *actually* happened was that usermod segfaulted and then a chain of dominoes fell over
[11:46] <shana> pitti: if you need help, let me know what's the fastest way to generate a .gir file from the webkit sources (I have them here, but I haven't poked at the makefiles yet to know what does what)
[11:46] <cjwatson> I don't agree with jibel's triaging of that as an X crash, but I also don't want to have to unpick all the duplicates
[11:47] <pitti> shana: I did "./configure --enable-introspection" and then just "make"; it auto-parallelizes, so it built pretty quick; and once you have a built tree, building the updates should be fast
[11:47] <shana> I think my tree is built
[11:47] <shana> at least I think I left it building at one point
[11:47]  * shana pokes
[11:48] <cjwatson> pitti: I suppose I could try to have ubiquity itself log and discard all instances of that; it may be a bit tricky
[11:49] <cjwatson> pitti: ah, here - there may be a genuine bug here in that that debconf-communicator instance isn't shut down properly
[11:49] <cjwatson> normally it isn't a problem, but if something else goes wrong, it produces spurious crap like that
[11:51] <cjwatson> pitti: I've fixed that in ubiquity bzr now
[11:51] <ara> checkbox package has a set of questions for debconf priority medium, but I cannot force it to ask me the questions using dpkg-reconfigure -p
[11:51] <ara> any ideas?
[11:51] <pitti> cjwatson: cheers
[11:52] <cjwatson> ara: try with DEBCONF_DEBUG=developer set in the environment and post the resulting stderr
[11:52] <cjwatson> ara: I bet the questions are marked as seen
[11:52] <cjwatson> (actually, ignore that last line)
[11:52]  * ara tries
[11:53] <infinity> ara: Why the -p?  dpkg-reconfigure defaults to low.  Not even sure what the behaviour is with -p and no priority specified.
[11:54] <ara> infinity, -pmedium, that's it
[11:56] <pitti> shana: ah, there are indeed two different signals; one for the WebFrame class, the other for the WebView class
[11:56] <cjwatson> infinity: (syntax error)
[11:56] <pitti> shana: and the webview one simply isn't annotated; I'll add that
[11:57] <infinity> cjwatson: Remembered off the top of your head, or attempted for curiosity? :P
[11:57] <cjwatson> guessed and checked for curiosity :-)
[11:57] <shana> pitti: ah yes, you're right, now I see it
[11:58] <cjwatson> I suspected it was getopt required-option, and thus that the package name would be interpreted as a priority; this turns out to be the case
[11:58] <pitti> shana: so I wonder why g-i is clever enough to deduce the "utf8" from the G_TYPE_STRING, but doesn't also add the c:type
[11:58] <shana> pitti: and why it could before but now it doesn't
[11:59] <shana> not exactly sure what's going on there
[11:59] <shana> and this webkit was built when I was on lucid, darn
[11:59] <pitti> shana: but Gtk-3.0.gir doesn't have c:types for it signals eitehr
[11:59] <shana> pitti: that scares me a bit more
[12:00] <pitti> shana: would you mind asking about that in #introspection?
[12:00] <ara> DEBCONF_DEBUG=developer sudo dpkg-reconfigure -pmedium checkbox > /tmp/stderr 2>&1
[12:00] <ara> and the file is empty
[12:00] <shana> jumping there now
[12:00] <pitti> shana: (just saw that you joined; I'll listen and learn)
[12:03] <cjwatson> ara: s/DEBCONF_DEBUG=developer sudo/sudo DEBCONF_DEBUG=developer/
[12:03] <pitti> shana: that looks better :) http://paste.ubuntu.com/586811/
[12:03] <shana> awesomesauce!
[12:03] <shana> that looks indeed much better :)
[12:04]  * pitti does the svn diff from hell
[12:04] <pitti> shana: http://people.canonical.com/~pitti/tmp/WebKit-1.0.gir
[12:04] <shana> ah, svn
[12:04] <pitti> shana: ^ freshly built with the patch
[12:04]  * shana looks
[12:04] <pitti> shana: yeah, svn :/ slow as hell, no local commit and format-patch, etc.
[12:05] <pitti> *ugh* *ugh* clapping stones together, grabbing club
[12:05] <shana> with svn repos I work with git locally and push with git svn
[12:05] <shana> otherwise I'd go nuts :P
[12:05] <pitti> shana: so the "p0" stuff on hovering-over-link was not a general error, but just a missing annotation, and these are straightforward to add
[12:06] <shana> nodnod
[12:06] <shana> good to hear
[12:06] <shana> the c:type is annoying, hopefully it's a bug and not a feature
[12:06] <pitti> shana: for the c:type stuff, deferring to the g-i gurus; does that actually block you, or could you infer a gchar* from a type="utf8"?
[12:06] <ara> http://pastebin.ubuntu.com/586813/
[12:06] <shana> I could, but then on other types there'll be more problems
[12:06] <pitti> shana: (since that's what g-i defines according to http://live.gnome.org/GObjectIntrospection/Annotations)
[12:06] <cjwatson> broder: have you got anywhere with rewriting grub hwmatch in C?
[12:06] <shana> like <type name="DOMCSSRule" c:type="WebKitDOMCSSRule*"/>
[12:07] <shana> utf8 might be straightforward, but other types certainly aren't
[12:07] <shana> I can do reverse lookups on other places where the type is defined correctly so I don't have to "guess"
[12:07] <pitti> right
[12:08] <pitti> shana: when you file the bug upstream, would you mind passing on http://people.canonical.com/~pitti/tmp/webkit.annotate-hovering-over-link.patch ?
[12:08] <shana> but seeing as all other types have a corresponding c:type, I'd like to know what makes glib:signals so special
[12:08] <shana> pitti: sure
[12:08] <pitti> shana: well, for normal methods g-i reads the function prototype
[12:09] <pitti> shana: for signals it needs to parse the g_signal_new() constructor
[12:09] <shana> pitti: thanks for the time, most appreciated :D
[12:09] <pitti> shana: i. e. it's two different code paths; that might explain why they behave differently
[12:09] <shana> pitti: I see, interesting
[12:10] <shana> maybe it's really a bug that slipped in
[12:10] <shana> I really hope it is
[12:10] <shana> otherwise my xslt is going to take twice as long to convert the .gir
[12:11] <shana> and I'm worried that utf8 is represented with two different native types there
[12:12] <shana> if I have to do lookups to get the types from other parts of the file, if I hit the wrong one, it might cause problems
[12:12]  * shana frets
[12:12] <shana> oh well
[12:12] <pitti> *ugh* *ugh* clapping stones together, grabbing clubhttps://bugzilla.gnome.org/enter_bug.cgi?product=glib ("introspection" component), then it's also easier to point to on IRC
[12:12] <shana> hahaha
[12:12] <pitti> ouch, what happened here
[12:12] <shana> svn strikes back
[12:12] <pitti> would you mind filing this at https://bugzilla.gnome.org/enter_bug.cgi?product=glib ("introspection" component), then it's also easier to point to on IRC
[12:13]  * shana opens bugs
[12:14] <pitti> shana: can you even pass arbitrary objects through signals? Don't they need to be defined in terms of existing G_TYPE_*?
[12:14] <pitti> ah, ignore me
[12:14] <pitti> of course you can use G_TYPE_FROM_CLASS(...)
[12:14] <shana> nod
[12:15] <ara> cjwatson, http://pastebin.ubuntu.com/586813/
[12:15] <pitti> but I guess at this point g-i's parser might give up
[12:15] <ara> any clues?
[12:15] <cjwatson> ara: well, it's simply not asking the questions
[12:15] <shana> pitti: maybe, but it worked before, so at some point the parser was happy with signals
[12:15] <cjwatson> I mean, it's not even trying
[12:16] <pitti> shana: ah, good to know
[12:16] <pitti> shana: so for now, let's just hope you won't need the really complicated signals :)
[12:16] <infinity> ara: You're not asking for input, just doing gets?
[12:16] <cjwatson> ara: ah - checkbox.config bug.  change 'configure' to 'configure|reconfigure' - or just remove the case entirely
[12:16] <shana> pitti: there's always ways around it, I'm just hoping I don't have to hack it :)
[12:17] <ara> cjwatson, cool, I will try that, thanks a lot
[12:17] <cjwatson> ara: http://paste.ubuntu.com/586814/
[12:17] <shana> the parameter names were the more problematic thing for me, so I'm happy :)
[12:17] <infinity> ara: Ahh, yes, all the db_inputs happen in configure. :)
[12:20] <pitti> shana: there are 5 more instances, I'll fix them as well; give me some minutes
[12:41] <shana> pitti: c:type bug -> https://bugzilla.gnome.org/show_bug.cgi?id=646080
[12:41]  * shana pats ubottu 
[12:45] <pitti> shana: subscribed, thanks!
[12:45] <pitti> shana: (still working on a more complete annotation patch)
[12:46] <shana> :)
[12:56] <pitti> $ grep '="p0"' WebKit-1.0.gir
[12:56] <pitti> $
[12:56] <pitti> shana: ^ *grin*
[12:56] <shana> :D
[12:56] <shana> yay!
[12:57] <pitti> shana: http://people.canonical.com/~pitti/tmp/webkit.missing-signal-annotations.patch is the new, more complete patch (still pretty cheesy, it should actually be documented properly, but at least the names are now alright)
[12:57] <pitti> shana: http://people.canonical.com/~pitti/tmp/WebKit-1.0.gir updated as well, in case you want to run your script against it
[12:58] <pitti> shana: I'm happy to subscribe to your webkit upstream bug, let me know the URL
[12:58] <pitti> and with that, late lunch o'clock
[12:58] <shana> great!
[12:58] <shana> was just opening the bug
[13:00] <pitti> shana: ah, ok; I'll make some additional notes when attaching the patch
[13:01] <mr_pouit> slangasek: (if it's not already on your todo list:) libxklavier would probably benefit a rebuild against the multiarchified glib, as its .pc currently contains "-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include" (it's @GLIB_CFLAGS@ replaced during the package build)...
[13:05] <shana> pitti: https://bugs.webkit.org/show_bug.cgi?id=57328
[13:06] <shana> pitti: i haven't attached the patch
[13:09] <dpm> ev, pitti, do you think you could have a look at bug 630927? On every release it seems to get fixed but then it appears again. I've just marked a duplicate for Natty, and I could confirm it happens again myself
[13:35] <doko> janimo, slangasek: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-arm-natty.html
[13:49] <shana> daaaamn, properties are missing c:type too
[13:49] <shana> gnn
[13:54] <tseliot> pitti: I know exactly what's going on in the last comment in LP: #522061 . Shall I commit a patch?
[14:00] <tseliot> s/patch/fix/
[14:03] <cjwatson> broder: actually, I might try working on it nowish ...
[14:08] <hggdh> mvo: ping re. jenkins
[14:10] <mvo> hggdh: does he work for us (just kidding ;)
[14:10] <mvo> hggdh: on the phone, but what is the question
[14:11] <ogra_> mvo, we really need to find someone to introduce you to jenkins next UDS
[14:11] <hggdh> mvo: I might be able to help you on using jenkins
[14:11] <mvo> hggdh: excellent
[14:14] <mvo> hggdh: we should talk about it at uds, the auto-upgrade-tester could use some love
[14:14] <hggdh> mvo: deal
[14:15] <pitti> re
[14:15] <pitti> tseliot: oh, what is it? I haven't had time to investigate the recent comment yet
[14:15] <pitti> tseliot: please commit away
[14:16] <tseliot> pitti: I've just added the patch to the bug report together with a brief explanation. I'll commit the small fix
[14:20] <tseliot> pitti: committed
[14:21] <pitti> shana: followed up with the patch and some remarks; thanks!
[14:22] <shana> awesome, thanks!
[14:22] <pitti> tseliot: ah, good catch; thanks!
[14:23] <tseliot> pitti: np
[14:32] <ev> dpm: added to my list of thinks to look at. Thanks
[14:32] <shana> this day is definitely going sideways
[14:33] <shana> pitti: oh, good thing you added the comment about the missing names, i just realized I pasted just half the info I wanted on the webkit bug :P
[14:34] <shana> on a positive note, it seems that a bit of replacing yields a decently complete gir file
[14:34] <pitti> shana: you mean crowbaring c:types into the gir for known types? :-)
[14:35] <shana> known and unknown types, just guessing on some, but oh well, should work :)
[14:36] <shana> fortunately, most types are also used on methods, where there's ctypes
[14:36] <pitti> shana: I wonder what pygi does to figure out the types
[14:36] <shana> not sure, but as soon as webkit finished building I'm going to find out
[14:36] <pitti> apparently that doesn't complain
[14:36] <shana> it's probably assuming the type name
[14:37] <shana> not sure
[14:39] <shana> I can fake types, but there's no one way to go about it
[14:39] <shana> utf8 can be gchar* or gchararray, gulong and friends are the same, GObject.Object is Object. Gtk.Menu is GtkMenu, DOMNode is WebKitDOMNode*
[14:40] <shana> and that's just the patterns I know
[14:41] <shana> we have c glue code in some places and handle conversions on the type, so pretending one is the other is just asking for trouble, unfortunately
[15:01] <stgraber> Laney: I can certainly fix that
[15:07] <m4n1sh> abhinav-: ping
[15:07] <abhinav-> m4n1sh, pong :)
[15:08] <m4n1sh> abhinav-: can you come to #zeitgeist?
[15:08] <abhinav-> ok sure
[15:09] <stgraber> Laney: I invited dmb into edubuntu-dev. Will give admin rights as soon as it's approved.
[15:09] <stgraber> Laney: not sure if we can approve it ourselves or if we need a TB member (owner of DMB) to do it
[15:09] <stgraber> at least I haven't received a mail yet and can't find an obvious way of doing it in LP
[15:10] <ScottK> I don't htink yo ucan.
[15:10] <ScottK> (if if I spelled it right, you still can't)
[15:18] <stgraber> cjwatson: can you do it ? (approve ubuntu dmb as a member of edubuntu-dev) ^
[15:22] <pitti> cjwatson: ^ I can deal with it
[15:23] <pitti> stgraber: done
[15:24] <cjwatson> thanks
[15:25] <stgraber> pitti: thanks
[15:26] <stgraber> Laney: ok, added to edubuntu-dev and made it an admin
[15:31] <tseliot> cjwatson, pitti: is it safe to upload packages in Natty now i.e. will they just queue up? Or shall I wait until beta 1 is released? Just double checking
[15:31] <cjwatson> they'll queue up
[15:32] <tseliot> cjwatson: ok, thanks
[15:32] <Laney> stgraber: thanks
[15:32] <tseliot> my memory is still good enough ;)
[15:34] <pitti> mvo: langpack file overwrite fixed in langpack-o-matic; will do new -base packs for beta-2 anyway
[15:35] <mvo> thanks!
[15:42] <bdmurray> dpm: does bug 630927 need to be targetted to natty or anything?
[15:52] <dpm> hi bdmurray, yeah, I'd suggest targetting it to natty, I thought it had been fixed in the previous releases, but it seems to come back every time
[15:54] <bdmurray> dpm: do you recall where it had been fixed before?
[15:56] <dpm> bdmurray, I'd say both on lucid and maverick, but that's only from memory. Let me see if there was another bug report...
[16:03] <dpm> bdmurray, jaunty: bug 337748. I can recall at least a more recent version, but I can't find any bug for that
[16:06] <dpm> bdmurray, ah, found it: Lucid - bug 527623
[16:07] <cjwatson> anything that old is probably a different problem
[16:07] <cjwatson> language support bugs keep permuting themselves
[16:07] <cjwatson> note also bug 741304 which could easily be related
[16:19] <shana> pitti: well phew, it's a regression
[16:20] <pitti> shana: yeah, I followed #introspection
[16:20] <EtienneG> guys, I was wondering: is there any way to verify the authenticity of the installer images?  There's checksum, but no GPG sig, and they're not in the Release file.
[16:21] <cjwatson> EtienneG: https://bugs.launchpad.net/launchpad/+bug/431790
[16:22] <EtienneG> cjwatson, I see, thanks for the pointer!
[16:29] <cjwatson> broder: how about http://paste.ubuntu.com/586919/ ?
[17:29] <dbarth> jelmer: ping? do you have time for a question about git sub-modules?
[17:29] <dbarth> i'm trying to import compiz-plugins-main, which is made of sub modules; if ever that can be supported with some of the tools available
[18:02] <jelmer> dbarth: hi
[18:32] <willy_1977> I'm after a few pointers on helping out with a gnome-utils bug and wondered where best to direct my queries i.e. where to start :p
[18:33] <willy_1977> bug #743176
[18:34] <dbarth> jelmer: hi
[18:34] <dbarth> (sorry missed the pong)
[18:35] <dbarth> jelmer: so any hope or workaround for mirroring a set of git sub-modules? i've tried with the development-subtree format
[18:35] <dbarth> jelmer: but then it failed with a stack trace when i tried to bzr pull the git module
[18:36] <dbarth> jelmer: i have another workaround anyway, by importing a tarball; but would be nice to know if there is a supported method to do better at this stage
[18:36] <jelmer> dbarth: fastimport/fastexport should work with git submodules and will just ignore them as far as I know.
[18:37] <dbarth> jelmer: ahah, ok, nice
[18:37] <dbarth> jelmer: i'll follow this track
[18:38] <jelmer> dbarth: bzr-git should work with submodules if you use development-subtree, but development-subtree is a development format (as the name suggests) so using it in production is generally a bad idea, and it's still unpolished.
[18:40] <dbarth> jelmer: hmm, i got this error when trying https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/745070
[18:40] <dbarth> jelmer: but anyway, right, it's not a production format for now, so i'll look at fastimport/export
[18:40] <dbarth> thanks again
[18:41] <jelmer> no problem
[19:10] <GrueMaster> mvo: Ping.  Any update on bug 533031?
[19:25] <mvo> GrueMaster: I have not seen a update to the ticket, once I get access to a mirror I can run the extraction. probably best to nudge IS about it
[19:26] <GrueMaster> sigh.  ok
[19:27] <mvo> GrueMaster: sorry for that
[19:27] <GrueMaster> np.
[19:28] <GrueMaster> Would like to get this fixed for release though.
[19:31] <GrueMaster> Looks like the last note I have is from March 17 from Colin.
[19:34] <mvo> thats the last I have as ell
[20:18] <highvoltage> n/win2 0
[20:40] <broder> cjwatson: you don't want to initialize match inside the hwmatch_iter function, do you?
[20:40] <cjwatson> oh, probably not
[20:41] <cjwatson> wants to be initialised outside that
[20:41] <cjwatson> fixed
[20:41] <cjwatson> oh, and I should grub_file_close somewhere
[20:43] <broder> also, i totally didn't know (but should have expected) that grub had a built-in regex engine. before i forgot about the rewrite, i was putting it off for a while because i expected it would require a larger chunk of time to deal with that
[20:43] <broder> anyway, really sorry i didn't get to it - work sort of consumed my life for the last few months
[20:47] <broder> cjwatson: i can't speak the correctness of your use of the grub libraries, but the logic looks correct to me
[20:48] <cjwatson> broder: it was only added about a year ago
[20:49] <cjwatson> broder: no problem, it didn't take quite as much time as I expected either ...
[20:49] <cjwatson> I was expecting half a day or so's work, it was more like an hour
[20:50] <cjwatson> broder: OK, I'll toss that into the Ubuntu package post-beta-1, then - thanks for the review
[21:01] <broder> cjwatson: i'll try to make a point of doing some testing
[21:12] <slangasek> broder: so hey, I did think of a multiarch-related task that'll need help this week
[21:13] <slangasek> broder: I've fixed up the packages in main that have .la files that referenced other .la's that have moved for multiarch, but we've got a good number of them in universe that still need to be touched
[21:57] <broder> slangasek: that totally sounds like something i could do
[21:59] <broder> hmm...is there a known issue with ubiquity in maverick? this is the second time i've gotten a segfault in libapt-pkg.so
[21:59] <ScottK> kklimonda is pretty good with that kind of thing too.
[21:59] <broder> might be connected to checking the "download updates" box
[22:01] <broder> slangasek: and when i find those, it's just a no-change rebuild, right?
[22:04] <slangasek> broder: "find" - I have the full list, let me post it
[22:04] <slangasek> broder: and you can do a no-change rebuild, or you can fix up the packaging to clean up the .la files according to Policy 10.2, depending on how much time you want to invest
[22:04] <slangasek> but there are >100 affected packages, so... :)
[22:04]  * micahg has libmpd already
[22:06] <slangasek> broder: http://people.canonical.com/~vorlon/broken-srcs-universe.txt
[22:06] <broder> slangasek: the rule of thumb for getting rid of .las is roughly that i can get rid of them as long as nothing that build-deps on the package also ships .las, right?
[22:07] <slangasek> broder: yes; in practice I've found it easier to just apply the dependency_libs sed trick to all affected packages
[22:07] <slangasek> (easier than tracking down revdeps and looking for .la files)
[22:09] <broder> hmm, ok, i like that plan better. because actually getting rid of the .la files would require a bunch of rebuilds in the opposite direction of fixing the multiarch issue :)
[22:10] <seb128> seems that clean those would be better to do at a cycle start though
[22:10] <slangasek> anyway, it's great to clean up the underlying .la issue for as many of these as we can, but since each of these causes FTBFS for their own reverse-deps, it's more important that we get them rebuilt
[22:10] <slangasek> seb128: are you concerned that cleaning them will break other things?
[22:10] <seb128> note that the GNOME stack is mostly clean of those for a while, we start on that for a while
[22:10] <slangasek> yep :)
[22:11] <seb128> slangasek, no, GNOME ones are already cleaned as I said ;-)
[22:11] <slangasek> heh
[22:11] <seb128> we have as a policy to not ship a .la for new desktop libs for some time
[22:11] <seb128> and clean-la was easy to use for cdbs sources
[22:12] <slangasek> yeah, though it seems that clean-la in cdbs has never made it upstream...
[22:12] <seb128> "upstream"?
[22:12] <seb128> debian is upstream for cdbs or I'm missing something?
[22:12] <slangasek> yes
[22:13] <slangasek> and Debian doesn't have the clean-la.mk, last I looked
[22:13] <seb128> oh, it's in gnome-pkg-tools
[22:13] <slangasek> right - it's implemented both places :)
[22:13] <slangasek> only the gnome-pkg-tools one is in Debian
[22:13] <seb128> well, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082
[22:14] <slangasek> yep
[22:14] <slangasek> so I've been adding a hand-written rule when fixing this in cdbs-using packages, since adding build-deps to gnome-pkg-tools for everything is not appropriate :)
[22:14] <slangasek> (and because these changes should be upstreamed to Debian ASAP)
[22:14] <seb128> but when we had those discussions previously Keybuk argued that .la were useful and should not be cleaned
[22:15] <seb128> it has been hard to get a consensus on what to do
[22:15] <slangasek> oh, Keybuk's right
[22:15] <slangasek> it would be good to keep the .la files around for static linking
[22:15] <slangasek> but nobody has ever fixed libtool upstream to DTRT for the dynamic linking case, so we do what we can - we fix it in the packaging
[22:16] <slangasek> (to avoid having to patch every single upstream source that uses libtool)
[22:16] <seb128> wouldn't be easier or better to put ressources on fixing libtool? ;-)
[22:16] <slangasek> have you ever looked at libtool's source?
[22:16] <seb128> or upstream doesn't want it to be "fixed" for some reason
[22:16] <seb128> i.e like don't agree on what fixed would be
[22:16] <seb128> hum, no, and I don't think I want ;-)
[22:17] <slangasek> I think upstream has looked into the abyss, and reproduced what they saw in the form of shell code; I don't know if they agree or not on what "fixed" should be, it's hard to get coherent answers out of them ;P
[22:18] <seb128> ;-)
[22:18] <seb128> anyway it seems that after this round of cleaning we can start the next cycle the other way around and start dropping those if we want
[22:20] <slangasek> that would be good... let's do it in Debian though, I don't want a thousand deltas for libtool :)
[22:22] <seb128> slangasek, indeed, and again I wonder why I'm talking there, the things I deal with are already out of those issues ;-)
[22:23]  * slangasek grins
[22:37] <kklimonda> slangasek: so for now rebuilding all the packages should be enough? And then we can revisit it in oneiric?
[22:37] <slangasek> kklimonda: sure
[22:38] <slangasek> time allowing I think cleaning .la files is also ok, but there's no requirement to
[22:38] <slangasek> I think it will save a little bit of time overall in the end
[22:40] <kklimonda> slangasek: ok, I'll see how much time can I put into this :)
[22:40] <slangasek> kklimonda: cheers!
[22:41] <slangasek> kklimonda: which end of the alphabet are you starting from? :)
[22:42] <kklimonda> I'll start with g :)
[22:42] <broder> kklimonda: if you give me a sec, i'm working on a graph so we can make sure we get the dependency order right
[22:42] <kklimonda> broder: sure, I'm not going to start tonight anyway. It's too late for that :)
[22:43] <broder> kklimonda: cool. i'm taking work off on friday to jam, so i'll catch up with you then
[22:43] <slangasek> tkamppeter: hi there - did you need something from me earlier, or was it the cups upload that pitti is taking care of?
[22:44] <slangasek> mr_pouit: so with libxklavier, why is it substituting variables into its .pc file from another .pc file, instead of using the Required field that's there for this purpose?
[22:46] <tkamppeter> slangasek, the CUPS uplod is only a workaround, I wanted to make you aware of the real bug in libpng, it is about bug 710881.
[22:47] <slangasek> tkamppeter: ah - please note that I don't know anything about libpng, I've only touched the package for library packaging issues
[22:47] <tkamppeter> slangasek, CUPS uses libpng to load PNG images, principally this works fine as long as the PNGs are RGBA,
[22:48] <tkamppeter> slangasek, sorry, I looked at the last thrree changelog entries and they were all from you. I wanted to make our libpng guru aware.
[22:49] <slangasek> tkamppeter: yep, I understand how you drew that conclusion :)
[22:50] <tkamppeter> slangasek, the CUPS package I can prinicipally upload by myself (what I do when pitti is on vacation), but usually I let pitti upload it to keep a sync between Debian and Ubuntu (pitti is the Debian maintainer of CUPS).
[22:50] <slangasek> sure
[22:54] <tkamppeter> slangasek, seems that libpng is not really maintained by Ubuntu but only synced/merged from Debian.
[22:55] <slangasek> yes
[22:55] <slangasek> you're best off discussing this with upstream
[23:11] <hv> is there a channel for unity?
[23:12] <TheMuso> hv: You want #ayatana.
[23:12] <hv> thanks