slangasekYokoZar: any luck with ia32-libs multiarching?00:29
directhexwow, that sounds nice & easy00:35
RAOFdirecthex: Shouldn't be *that* hard, right?  “Just” pull in /usr/lib/i386-whatever-triplet/ :)00:38
YokoZarslangasek: 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:44
YokoZarslangasek: 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
YokoZarslangasek: hopefully there aren't any non-relative-path surprises and such in there00:46
Laneystgraber: I just noticed that the DMB isn't an administrator of ~edubuntu-dev00:46
RAOFLaney: 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
psusianyone 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:54
slangasekYokoZar: it really is as simple as "also look in {/usr,}/lib/i386-linux-gnu/ and copy all libs there to /usr/lib32"00:57
LaneyRAOF: 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
slangasekYokoZar: but if you want me to look at it I can00:58
ionia32-libs “multiarching” doesn’t mean “destroying forever”? :-P00:58
LaneyRAOF: If you mail the DMB list then we'll work something out though (and it will let me raise this issue)00:58
slangasekion: not in one cycle it doesn't00:58
slangasekion: not given how long ia32-libs has been allowed to fester and continue accumulating libs00:58
slangasek$ dpkg -L ia32-libs|grep -c 'lib32/[^/]\+\.so'01:02
=== yofel_ is now known as yofel
Chipzzslangasek: wtf? :p01:19
Chipzzdoes that include the symlinks too?01:19
slangasekYokoZar: if you do want me to look at it, please say so explicitly :)01:19
slangasekChipzz: it includes whatever that regexp matches, I didn't filter too hard01:19
Chipzzslangasek: ah, so prolly /3 then :)01:19
slangasekyeah, dpkg -L doesn't distinguish between files and links01:20
Chipzz~250 libs, still pretty bad :/01:20
broderan upstart task triggers stopped/stopping events when the exec/script block exits, right?01:21
slangasekdpkg -c ~archive/pool/universe/i/ia32-libs/ia32-libs_20090808ubuntu9_amd64.deb |grep -c '^-.*lib32/[^/]\+\.so'01:21
slangasekbroder: yes01:21
broderhmm...i think i need to get better logs to figure out what's going on, then01:22
slangasekbroder: actually, no, sorry01:23
slangasekbroder: I confused myself - a task is "started" when the job finishes01:23
slangasekand not before01:23
broderso a task goes to the "starting" state, then it runs and stays in "starting", then goes to "started" when it finishes running?01:25
=== dendro-afk is now known as dendrobates
slangasekbroder: yes01:28
slangaseker... maybe01:30
slangasekok, I don't know ;)01:30
broderhaha, ok :)01:30
slangasekif I look at jobs that are tasks that definitely ran at boot time, they're in state 'stop/waiting'01:30
broderi'll harrass SpamapS and the other people working on the upstart cookbook to figure out and clarify01:30
broderright, that's what i was looking at01:31
slangasekand those jobs should, barring bugs, emit stopping/stopped events at the end01:31
broderas a guess, maybe tasks skip the running, pre-stop, stopping, killed, and post-stop states and go straight from spawned to waiting?01:31
slangasekcould be, but I think that would be inconsistent with the use of 'post-stop' scripts in several of the jobs01:32
broderok, you've officially got me digging through source code now, so report back on what i find :)01:32
broderugh. i might not have acquired enough of the upstart zen to know what's going on here01:41
broderah - but the logs might clarify what's going on01:44
broderor maybe not, because all of the tasks in the normal boot happen before syslog is up01:46
broderbut certainly tasks transition through the running -> stopping -> killed -> post-stop -> waiting series of states01:47
YokoZarslangasek: how's your bandwidth?  Can you upload the 800+ meg source package?01:57
slangasekif I have to01:57
slangasekI'd rather just send you a patch ;)01:57
YokoZarslangasek: That works best for me :)01:57
slangaseka patch does?01:57
YokoZarThen I'll add the libraries I need and make a huge upload overnight01:58
psusiit seems to me like prefixing patches with a number is a carryover from dpatch... or should 3.0 (quilt) patches also be numbered?02:10
broderpsusi: 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 style02:11
psusibroder, does order really matter?02:12
broderpsusi: sometimes. usually it's something like ubuntu is changing something that debian already changed02:12
psusiI 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:12
broderit's no less valid of an order than the mostly arbitrary order imposed by the names of the patches02:14
RAOFBah.  Stupid interaction of 3.0(quilt) and vcs!02:20
RoAkSoAxwin 2402:23
ionlose 2502:24
=== asac_ is now known as asac
=== dendrobates is now known as dendro-afk
=== jamesh_ is now known as jamesh
=== dendro-afk is now known as dendrobates
RAOF@pilot out03:51
=== udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
ScottKRAOF: Is there any other kind of 3.0(quilt)/VCS interaction defined?04:06
=== tumbleweed_ is now known as tumbleweed
=== 50UAAGBPG is now known as Amaranth
=== ssweeny_ is now known as ssweeny
twbWho has point for LibreOffice packaging: Debian or Ubuntu?  That is, who syncs from whom?05:58
jmghi all06:05
jmgany reason i wouldnt be able to use fglrx on casper with persistent changes06:06
jmgi really desperately need it or the radeondump tool which doesnt appear to be included anywhere in the earchive06:07
=== _LibertyZero is now known as LibertyZero
slangasekYokoZar: bug #74476706:47
ubottuLaunchpad bug 744767 in ia32-libs (Ubuntu) "ia32-libs needs changes to cope with library packages installing to multiarch paths" [Undecided,New] https://launchpad.net/bugs/74476706:47
broderslangasek: man, that multiarch command sequence from your blog is *awesome*07:44
slangasekdisclaimer: running it on your desktop eats your desktop.  Enabling multiarch at all on your desktop eats update-manager and anything else that uses python-apt07:45
broderhaha. cest la vie07:45
slangasekalthough for the former issue, I have all the needed bits in ppa now07:45
infinityIsn'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
slangasekmodule gtk+2.0, which the buildds won't give me for another 2 hours or so07:46
slangasekinfinity: heh07:46
broderslangasek: if you need help, i'm hoping to be able to take friday off of work to go to jono's global jam07:47
slangasekbroder: we're at kind of a curious point where there's not much more to usefully do until dpkg 1.16.0 hits unstable07:49
brodersure, just figured i'd throw it out there07:49
StevenKinfinity: Your bitterness is showing07:49
StevenKEr, more showing07:49
slangaseknothing 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 off07:50
slangasekso because I'm out of major things to do for multiarch, that's the time I'll blog instead ;)07:50
infinityStevenK: Rumours of my bitterness have been greatly exaggerated for comedic effect.07:50
StevenKinfinity: No, they haven't. :-)07:52
pittiGood morning07:55
* slangasek waves to pitti 07:57
broderhmm...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:58
* infinity pokes pitti with a stick.07:59
=== JamieBen1ett is now known as JamieBennett
cdbsdholbach: Good morning08:07
dholbachgood morning08:07
dholbachhey cdbs08:07
infinitydholbach: Hai.08:09
dholbachhey infinity08:09
dholbachinfinity, MAN - long time no see08:09
* dholbach hugs infinity08:09
* infinity hugs dholbach.08:09
infinityI've decided to come back to annoy you.08:09
dholbachhahaha, awesome :)08:09
soreninfinity: Dude!08:15
infinitysoren: *wave*08:16
infinitysabdfl: I've lost track, are you in a disconnect storm, or actually joining the channel? :P08:16
infinitysabdfl: If the latter, "hi".08:16
pittihey infinity, how are you?08:16
sabdflinfinity: adventures in multi-device connectivity here :-)08:17
sabdflhow are you, long time no speak08:17
infinitypitti: Alive and well.  And I think this is more than I've typed in #ubuntu-devel in two years.08:17
pittilol, yes08:17
infinitysabdfl: See above? :)08:17
sabdfltimezones still seem unchanged ;-)08:17
sorenI'm sure we can pull up some stats on that.08:17
sabdflhey soren08:17
sorensabdfl: o/08:17
sorensabdfl: I though you were in a very different timezone these days08:18
didrocksgood morning08:18
sorenthought, even.08:18
sorenSpecifically, one that does not warrant being awake right now :)08:18
infinitysabdfl: And yeah, I'm still timezone challenged.  I don't imagine this is something that will ever change.08:19
* mvo waves to infinity08:20
infinityOkay, now I'm getting all sentimental.08:21
=== smb` is now known as smb
YokoZarslangasek: universe libs only in ia32-libs yes?08:39
slangasekYokoZar: hmm?08:40
=== javalogger is now known as apachelogger
YokoZarslangasek: eg can I add gstreamer0.10-plugins-ugly or just gstreamer0.10-plugins-good08:40
slangasekoh, do you mean *main* only rather than universe? :)08:41
slangasekthere are both main and universe libs in ia32-libs08:41
YokoZarerr no I mean "not multiverse"08:41
slangasekneither of those are in multiverse08:41
slangasekia32-libs is in universe, so you can't add anything from multiverse to it, yes08:42
slangaseknot that I think you should really add anything more to it at all, but hey08:42
YokoZarbut ugly plugins are in universe you say08:42
slangasekyes, the good/bad/ugly split of the packages has to do with code quality and support, not freeness08:42
YokoZarok that makes me feel better08:43
dholbachRAOF, happy patch pilot day08:46
pittiogra_: did you want to keep rhythmbox on the armel ubuntu-netbook images? If so, can you please seed it appropriately?08:48
pittiogra_: 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:48
sabdflsoren: no, i'm trying to narrow my timezones! where did you think i was?08:51
sorensabdfl: I heard a rumour about US East coast. New York or something.08:51
sabdflah, yes, i have bought a place there, it's about as far from GMT as I'd like to live08:53
sabdflgoing to take a while to get it fixed up though08:53
sabdfli'm concentrating on Isle of Man and Cape Town at the moment08:53
sabdfland my little tropical love affair08:53
sorensabdfl: Sounds lovely!08:56
=== tkamppeter_ is now known as tkamppeter
tkamppeterslangasek, hi09:03
=== lool- is now known as lool
YokoZarWhy are there binaries for libx264-98 still in archive when source package x264 provides libx264-106 instead now?09:41
mok0I 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 infrastructure09:43
pittiYokoZar: see http://people.canonical.com/~ubuntu-archive/nbs.html09:43
pittiYokoZar: the old packages still have rdepends, they need some transition uploads09:43
YokoZarpitti: in this case, all on ppc...09:44
RAOFMan, libx264.  Because ABIs are hard! :)09:44
ohsixffmpeg too D:09:46
mvodpm: is bug #744831 something that should be on langpack-o-matic or is it in the right place?09:46
ubottuLaunchpad bug 744831 in language-pack-as (Ubuntu) "file overwrite error" [Undecided,New] https://launchpad.net/bugs/74483109:46
ohsixRAOF: both are windows centric and assume you do a source checkout and use it as is in your software09:46
=== doko_ is now known as doko
=== shana` is now known as shana
janimodoes 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:37
janimofor instance linaro/ubuntu gcc has fixes not yet upstream, so we have a gcc bugtask open on some bugs10:38
janimoex: https://bugs.launchpad.net/gcc/+bug/39840310:38
ubottuUbuntu bug 398403 in gcc "[PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error" [Unknown,Confirmed]10:38
janimodoko, ^ ?10:41
dokohmm, linaro uses a project linaro-tracking ... (or something like this)10:43
dokolool: ^^^10:43
cjwatsoninfinity: hi!  awesome.10:46
dpmmvo, yeah, I think langpack-o-matic would be the right place for bug 744831, pitti, what do you think?10:46
ubottuLaunchpad bug 744831 in language-pack-as (Ubuntu Natty) "file overwrite error on upgrade from maverick -> natty" [Undecided,New] https://launchpad.net/bugs/74483110:46
ogra_ogra@panda:~$ archdetect10:47
* ogra_ scratches head10:47
ogra_i thought we had panda support in archdetect10:48
pittidpm, mvo: erk, because packagekit moved; yeah, need some extra replaces, I think10:48
pittimvo: how much does this break update-manager? (didn't it use to ignore file overwrites, or retry a few times?)10:49
pittiasking because rebuilding all -base packs will take a looong time10:49
pittibug updated10:50
ogra_bah, cpuinfo strings changed10:54
mvopitti: its only a issue for people upgrading manually so not beta1 critical10:54
pittimvo: ok, thanks; milestoned to b2 now10:55
ricotzhello, 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:03
looljanimo: Sorry, not sure what you're trying to solve11:06
janimolool, to reduce the number of bugs listed as needing attention in ubuntu, while triaging11:07
looldoko: I think linaro-tracking is a bit of a hack to track which upstream commits fix the bug; it's more of a trick11:07
looljanimo: If the bug is fixed in the Ubuntu package you certainly should close the Ubuntu task11:07
janimoeven if our packages are fixed, if there's an also affects project with upstream bugtracker open ticket, we get that bug listed11:07
tkamppeterpitti, can you upload CUPS from BZR, to get the fix/workaround for bug 710881 into the beta? Thanks.11:08
ubottuLaunchpad bug 710881 in libpng (Ubuntu) "cups: Test Page /usr/lib/cups/filter/bannertops failed, test page and banner pages do not get printed" [Medium,Confirmed] https://launchpad.net/bugs/71088111:08
looljanimo: That sounds like a bug in the script?11:08
pittitkamppeter: doesn't sound critical for the beta release (not important enough to delay it, anyway)11:08
pittitkamppeter: I'll upload it after b111:08
janimolool, LP ui, not sure what script is involved11:08
looljanimo: Can you give me a sample URL?11:08
janimoLP for instance this appears in the list of bugs of armel-porters https://bugs.launchpad.net/gcc/+bug/39840311:09
ubottuUbuntu bug 398403 in gcc "[PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error" [Unknown,Confirmed]11:09
pittiricotz: hm, confirmed here11:09
janimoeven if it is only a Gcc 4.3 upstream task involved11:09
ricotzpitti, ok ;), so it is an apt or archive problem11:10
looljanimo: But where did you get this bug from?11:11
looljanimo: it seems to me you're searching all bugs in launchpad tagged armel instead of just the Ubuntu ones?11:11
htorquepitti, ricotz, maybe bug 677733?11:11
ubottuLaunchpad bug 677733 in apt (Ubuntu) "Download of the same lists" [Undecided,New] https://launchpad.net/bugs/67773311:11
looljanimo: Technically, this bug is still open upstream11:11
janimolool, I think I went to armel ubuntu porters and listed bugs associated to them11:12
janimoindeed it is still open upstream11:12
janimoI find upstream/debian bugtasks useful until we do not have a fix ourselves as somethign to track and pick a fix from11:13
janimowhen we have it fixed I see no point in keeping that open, especially since upstream/debian do not use LP for bugtracking11:13
janimoit is noise11:13
pittiogra_: 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:15
ogra_pitti, our settings are in unity-2d itself, both are transitional packages ...11:16
looljanimo: 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:16
looljanimo: In the worst case, you could have a project blacklist if that's not exposed by the API11:17
pittiunity-2d-default-settings |        0.4 | natty/universe | source11:17
pittiunity-2d-default-settings | 3.8.1-0ubuntu1 |         natty | all11:17
pittioh, fun11:17
janimolool, ah certainly. I just with LP UI itself was cleaner11: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 packages11:17
pittiogra_: ^ i. e. universe has a newer version than main11:17
pittiogra_: so if at all they are ok in universe11:17
ogra_why is 0.4 newer than 3.8 ?11:17
pittiogra_: but I'd like to remove the unity-2d-default-settings source package then11:17
pittiogra_: sorry, ignore me11:18
janimolool, 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 go11:18
pittiogra_: ok, thanks11:18
looljanimo: ?11:18
ogra_pitti, thanks for the heads-up :)11:19
looljanimo: 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
pittiogra_: 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
janimolool, 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 well11:19
ogra_the latter should be in universe11:20
pittiogra_: moved11:20
ogra_for linux-tools, i guess you need to ask the kernel team if we need them11:20
ogra_i'll happily seed them if so11:20
janimolool, 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:20
looljanimo: 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
loolI'm pretty sure you could search Ubuntu bugs where ubuntu-armel is sub-ed though11:22
janimolool, 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 not11:22
looljanimo: http://goo.gl/b8Xk111:23
looljanimo: 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
janimolool, 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 Ubuntu11:25
tkamppeterpitti, OK.11:25
lifelessjanimo: we're working on it :)11:26
janimolifeless, good to know :)11:26
looljanimo: Well, you're the one who knows "ubuntu-armel" only cares for Ubuntu11:28
looljanimo: The link I pasted doesn't list it, does it?11:29
janimolool, it does not indeed11:29
looljanimo: I went to bugs.launchpad.net/ubuntu, hit Advanced search and put "ubuntu-armel" in Subscriber; that's it11:29
loolOf course now you're going to tell me you miss the other projects you care about and which track bugs in Launchpad  :-)11:30
janimolool, 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 useful11:32
janimoactually 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 helpful11:33
jibelpitti, is there a way to stop the retracer aggregating all kind of unrelated ubiquity failures to bug 65291611:33
ubottuLaunchpad bug 652916 in ubiquity (Ubuntu) "ubiquity-dm crashed with ValueError in command(): invalid literal for int() with base 10: ''" [Medium,Triaged] https://launchpad.net/bugs/65291611:33
looljanimo: 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 folks11:34
pittijibel: you mean all those debconf bugs have a different cause?11:35
pittijibel: 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
pittishana: here?11:36
shanapitti: morning!11:36
jibelpitti, 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 error11:36
pittishana: morning, how are you?11:37
pittishana: I just finished building webkit svn trunk again (this time with introspection enabled), and had a look11:37
shanapitti: a bit coffee-deprived, but otherwise good11:37
pittishana: to my surprise, glib:signal name="hovering-over-link" is actually in the .gir *twice*11:37
pittishana: once with wrong dummy argument names, the second one is the correct one11:37
shanasorry about not opening the bug yet, soc has been siphoning all of my time11:37
shanapitti: orly??11:38
pittishana: but both have <type name="utf8"/> which seems fine?11:38
cjwatsonpitti: unfortunately the thing that notices is on the other side of a pipe from what could provide more information11:38
cjwatsonpitti: the error means "the debconf frontend I was talking to fell over"11:38
shanapitti: <type name="utf8" is not enough, that's a generic name, it should have c:type="gchar*"11:38
* shana opens up gir files11:39
pittishana: why?11:39
pitticjwatson: is there any way we could extract more useful information out of this after the crash happened?11:39
shanapitti: this is what the one I have on the system (webkit 1.2.5) has for that signal: https://gist.github.com/89214511:40
pittishana: (btw, only gchar* is translated to "utf8", so you can actually assume that)11:40
shanaof course, I can map those new type names, I guess11:40
pittishana: do you depend on always having the c:type one?11:41
shanapitti: I did, since every single entry on the gir file has one11:41
pittishana: ok; I guess as a first step I'll track down why it appears twice11:41
shanait's a standard on every parameter on every method, every type, everything11:41
cjwatsonpitti: the problem is that multiple python processes crash; we get useful tracebacks from the other one ...11:42
pitticjwatson: ah, we do? so perhaps we should just generally ignore this crash on the ubiquity side then?11:42
shanapitti: take a look at the gist again, I added a comment with other entries on the gir file11:43
pitticjwatson: the ubiquity hook is in the apport source, so I could tweak stuff there11:43
cjwatsonpitti: maybe, DebconfCommunicator is started in a load of different place11:43
shanapitti: utf8 is mapped as gchar* in some places, gchararray in others11:43
cjwatsonactually, it's pretty odd that that particular one is relevant to anything11:43
cjwatsonpitti: I'm not absolutely certain, but on the whole I suspect ignoring that one would improve our bugs11:44
pittishana: ok, I'll have a look at the ctypes ones as well, but that sounds a little out of my current knowledge11:44
shanapitti: since we map native types when invoking native methods (mono does that by default and gtk-sharp adds some extra layers), that info is important11:44
pitticjwatson: we currently only have a mechanism for saying "sorry can't report this", we can't silently analyze and discard a crash11:45
pitticjwatson: but I guess that would already be an improvement11:45
cjwatsonin this case, what *actually* happened was that usermod segfaulted and then a chain of dominoes fell over11:45
shanapitti: 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
cjwatsonI 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 duplicates11:46
pittishana: 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 fast11:47
shanaI think my tree is built11:47
shanaat least I think I left it building at one point11:47
* shana pokes11:47
cjwatsonpitti: I suppose I could try to have ubiquity itself log and discard all instances of that; it may be a bit tricky11:48
cjwatsonpitti: ah, here - there may be a genuine bug here in that that debconf-communicator instance isn't shut down properly11:49
cjwatsonnormally it isn't a problem, but if something else goes wrong, it produces spurious crap like that11:49
cjwatsonpitti: I've fixed that in ubiquity bzr now11:51
aracheckbox package has a set of questions for debconf priority medium, but I cannot force it to ask me the questions using dpkg-reconfigure -p11:51
araany ideas?11:51
pitticjwatson: cheers11:51
cjwatsonara: try with DEBCONF_DEBUG=developer set in the environment and post the resulting stderr11:52
cjwatsonara: I bet the questions are marked as seen11:52
cjwatson(actually, ignore that last line)11:52
* ara tries11:52
infinityara: Why the -p?  dpkg-reconfigure defaults to low.  Not even sure what the behaviour is with -p and no priority specified.11:53
arainfinity, -pmedium, that's it11:54
pittishana: ah, there are indeed two different signals; one for the WebFrame class, the other for the WebView class11:56
cjwatsoninfinity: (syntax error)11:56
pittishana: and the webview one simply isn't annotated; I'll add that11:56
infinitycjwatson: Remembered off the top of your head, or attempted for curiosity? :P11:57
cjwatsonguessed and checked for curiosity :-)11:57
shanapitti: ah yes, you're right, now I see it11:57
cjwatsonI suspected it was getopt required-option, and thus that the package name would be interpreted as a priority; this turns out to be the case11:58
pittishana: 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:type11:58
shanapitti: and why it could before but now it doesn't11:58
shananot exactly sure what's going on there11:59
shanaand this webkit was built when I was on lucid, darn11:59
pittishana: but Gtk-3.0.gir doesn't have c:types for it signals eitehr11:59
shanapitti: that scares me a bit more11:59
pittishana: would you mind asking about that in #introspection?12:00
araDEBCONF_DEBUG=developer sudo dpkg-reconfigure -pmedium checkbox > /tmp/stderr 2>&112:00
araand the file is empty12:00
shanajumping there now12:00
pittishana: (just saw that you joined; I'll listen and learn)12:00
cjwatsonara: s/DEBCONF_DEBUG=developer sudo/sudo DEBCONF_DEBUG=developer/12:03
pittishana: that looks better :) http://paste.ubuntu.com/586811/12:03
shanathat looks indeed much better :)12:03
* pitti does the svn diff from hell12:04
pittishana: http://people.canonical.com/~pitti/tmp/WebKit-1.0.gir12:04
shanaah, svn12:04
pittishana: ^ freshly built with the patch12:04
* shana looks12:04
pittishana: yeah, svn :/ slow as hell, no local commit and format-patch, etc.12:04
pitti*ugh* *ugh* clapping stones together, grabbing club12:05
shanawith svn repos I work with git locally and push with git svn12:05
shanaotherwise I'd go nuts :P12:05
pittishana: so the "p0" stuff on hovering-over-link was not a general error, but just a missing annotation, and these are straightforward to add12:05
shanagood to hear12:06
shanathe c:type is annoying, hopefully it's a bug and not a feature12:06
pittishana: 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
shanaI could, but then on other types there'll be more problems12:06
pittishana: (since that's what g-i defines according to http://live.gnome.org/GObjectIntrospection/Annotations)12:06
cjwatsonbroder: have you got anywhere with rewriting grub hwmatch in C?12:06
shanalike <type name="DOMCSSRule" c:type="WebKitDOMCSSRule*"/>12:06
shanautf8 might be straightforward, but other types certainly aren't12:07
shanaI can do reverse lookups on other places where the type is defined correctly so I don't have to "guess"12:07
pittishana: 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
shanabut seeing as all other types have a corresponding c:type, I'd like to know what makes glib:signals so special12:08
shanapitti: sure12:08
pittishana: well, for normal methods g-i reads the function prototype12:08
pittishana: for signals it needs to parse the g_signal_new() constructor12:09
shanapitti: thanks for the time, most appreciated :D12:09
pittishana: i. e. it's two different code paths; that might explain why they behave differently12:09
shanapitti: I see, interesting12:09
shanamaybe it's really a bug that slipped in12:10
shanaI really hope it is12:10
shanaotherwise my xslt is going to take twice as long to convert the .gir12:10
shanaand I'm worried that utf8 is represented with two different native types there12:11
shanaif I have to do lookups to get the types from other parts of the file, if I hit the wrong one, it might cause problems12:12
* shana frets12:12
shanaoh well12: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 IRC12:12
pittiouch, what happened here12:12
shanasvn strikes back12:12
pittiwould 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 IRC12:12
* shana opens bugs12:13
pittishana: can you even pass arbitrary objects through signals? Don't they need to be defined in terms of existing G_TYPE_*?12:14
pittiah, ignore me12:14
pittiof course you can use G_TYPE_FROM_CLASS(...)12:14
aracjwatson, http://pastebin.ubuntu.com/586813/12:15
pittibut I guess at this point g-i's parser might give up12:15
araany clues?12:15
cjwatsonara: well, it's simply not asking the questions12:15
shanapitti: maybe, but it worked before, so at some point the parser was happy with signals12:15
cjwatsonI mean, it's not even trying12:15
pittishana: ah, good to know12:16
pittishana: so for now, let's just hope you won't need the really complicated signals :)12:16
infinityara: You're not asking for input, just doing gets?12:16
cjwatsonara: ah - checkbox.config bug.  change 'configure' to 'configure|reconfigure' - or just remove the case entirely12:16
shanapitti: there's always ways around it, I'm just hoping I don't have to hack it :)12:16
aracjwatson, cool, I will try that, thanks a lot12:17
cjwatsonara: http://paste.ubuntu.com/586814/12:17
shanathe parameter names were the more problematic thing for me, so I'm happy :)12:17
infinityara: Ahh, yes, all the db_inputs happen in configure. :)12:17
pittishana: there are 5 more instances, I'll fix them as well; give me some minutes12:20
=== MacSlow is now known as MacSlow|lunch
shanapitti: c:type bug -> https://bugzilla.gnome.org/show_bug.cgi?id=64608012:41
ubottuGnome bug 646080 in introspection "c:type is missing for parameters on glib:signal entries in the gir" [Normal,Unconfirmed]12:41
* shana pats ubottu 12:41
pittishana: subscribed, thanks!12:45
pittishana: (still working on a more complete annotation patch)12:45
=== hunger_ is now known as hunger
pitti$ grep '="p0"' WebKit-1.0.gir12:56
pittishana: ^ *grin*12:56
pittishana: 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
pittishana: http://people.canonical.com/~pitti/tmp/WebKit-1.0.gir updated as well, in case you want to run your script against it12:57
pittishana: I'm happy to subscribe to your webkit upstream bug, let me know the URL12:58
pittiand with that, late lunch o'clock12:58
shanawas just opening the bug12:58
pittishana: ah, ok; I'll make some additional notes when attaching the patch13:00
mr_pouitslangasek: (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:01
shanapitti: https://bugs.webkit.org/show_bug.cgi?id=5732813:05
ubottubugs.webkit.org bug 57328 in WebKit Gtk "Introspection: missing signal annotations" [Normal,Unconfirmed]13:05
shanapitti: i haven't attached the patch13:06
dpmev, 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 myself13:09
ubottuLaunchpad bug 630927 in Ubuntu Translations "Notification of missing language support not shown after installation" [High,Triaged] https://launchpad.net/bugs/63092713:09
dokojanimo, slangasek: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-arm-natty.html13:35
shanadaaaamn, properties are missing c:type too13:49
tseliotpitti: I know exactly what's going on in the last comment in LP: #522061 . Shall I commit a patch?13:54
cjwatsonbroder: actually, I might try working on it nowish ...14:03
hggdhmvo: ping re. jenkins14:08
mvohggdh: does he work for us (just kidding ;)14:10
mvohggdh: on the phone, but what is the question14:10
ogra_mvo, we really need to find someone to introduce you to jenkins next UDS14:11
hggdhmvo: I might be able to help you on using jenkins14:11
mvohggdh: excellent14:11
mvohggdh: we should talk about it at uds, the auto-upgrade-tester could use some love14:14
hggdhmvo: deal14:14
pittitseliot: oh, what is it? I haven't had time to investigate the recent comment yet14:15
pittitseliot: please commit away14:15
tseliotpitti: I've just added the patch to the bug report together with a brief explanation. I'll commit the small fix14:16
tseliotpitti: committed14:20
pittishana: followed up with the patch and some remarks; thanks!14:21
shanaawesome, thanks!14:22
pittitseliot: ah, good catch; thanks!14:22
tseliotpitti: np14:23
evdpm: added to my list of thinks to look at. Thanks14:32
shanathis day is definitely going sideways14:32
shanapitti: 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 :P14:33
shanaon a positive note, it seems that a bit of replacing yields a decently complete gir file14:34
pittishana: you mean crowbaring c:types into the gir for known types? :-)14:34
shanaknown and unknown types, just guessing on some, but oh well, should work :)14:35
shanafortunately, most types are also used on methods, where there's ctypes14:36
pittishana: I wonder what pygi does to figure out the types14:36
shananot sure, but as soon as webkit finished building I'm going to find out14:36
pittiapparently that doesn't complain14:36
shanait's probably assuming the type name14:36
shananot sure14:37
shanaI can fake types, but there's no one way to go about it14:39
shanautf8 can be gchar* or gchararray, gulong and friends are the same, GObject.Object is Object. Gtk.Menu is GtkMenu, DOMNode is WebKitDOMNode*14:39
shanaand that's just the patterns I know14:40
shanawe have c glue code in some places and handle conversions on the type, so pretending one is the other is just asking for trouble, unfortunately14:41
=== apachelogger is now known as thresh_fan_fan
=== chuck_ is now known as zul
=== MacSlow|lunch is now known as MacSlow
=== thresh_fan_fan is now known as apachelogger
stgraberLaney: I can certainly fix that15:01
m4n1shabhinav-: ping15:07
abhinav-m4n1sh, pong :)15:07
m4n1shabhinav-: can you come to #zeitgeist?15:08
abhinav-ok sure15:08
stgraberLaney: I invited dmb into edubuntu-dev. Will give admin rights as soon as it's approved.15:09
stgraberLaney: not sure if we can approve it ourselves or if we need a TB member (owner of DMB) to do it15:09
stgraberat least I haven't received a mail yet and can't find an obvious way of doing it in LP15:09
ScottKI don't htink yo ucan.15:10
ScottK(if if I spelled it right, you still can't)15:10
stgrabercjwatson: can you do it ? (approve ubuntu dmb as a member of edubuntu-dev) ^15:18
=== Dr_Who is now known as tgall_foo
pitticjwatson: ^ I can deal with it15:22
pittistgraber: done15:23
stgraberpitti: thanks15:25
stgraberLaney: ok, added to edubuntu-dev and made it an admin15:26
=== sconklin is now known as sconklin-afk
tseliotcjwatson, 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 checking15:31
cjwatsonthey'll queue up15:31
tseliotcjwatson: ok, thanks15:32
Laneystgraber: thanks15:32
tseliotmy memory is still good enough ;)15:32
pittimvo: langpack file overwrite fixed in langpack-o-matic; will do new -base packs for beta-2 anyway15:34
=== Quintasan_ is now known as Quintasan
bdmurraydpm: does bug 630927 need to be targetted to natty or anything?15:42
ubottuLaunchpad bug 630927 in Ubuntu Translations "Notification of missing language support not shown after installation" [High,Triaged] https://launchpad.net/bugs/63092715:42
dpmhi 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 time15:52
bdmurraydpm: do you recall where it had been fixed before?15:54
dpmbdmurray, I'd say both on lucid and maverick, but that's only from memory. Let me see if there was another bug report...15:56
=== sconklin-afk is now known as sconklin
dpmbdmurray, jaunty: bug 337748. I can recall at least a more recent version, but I can't find any bug for that16:03
ubottuLaunchpad bug 337748 in ubiquity (Ubuntu Jaunty) "[jaunty] ”Incomplete Language Support” message not shown anymore after installation" [High,Fix released] https://launchpad.net/bugs/33774816:03
=== jjohansen is now known as jj-afk
=== diwic is now known as diwic_afk
dpmbdmurray, ah, found it: Lucid - bug 52762316:06
ubottuLaunchpad bug 527623 in ubiquity (Ubuntu Lucid) "Notification of missing language support not shown after installation" [High,Fix released] https://launchpad.net/bugs/52762316:06
cjwatsonanything that old is probably a different problem16:07
cjwatsonlanguage support bugs keep permuting themselves16:07
cjwatsonnote also bug 741304 which could easily be related16:07
ubottuLaunchpad bug 741304 in ubiquity (Ubuntu Natty) "Language packs are not being installed for selected languages during oem-config" [High,Triaged] https://launchpad.net/bugs/74130416:07
shanapitti: well phew, it's a regression16:19
pittishana: yeah, I followed #introspection16:20
EtienneGguys, 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:20
cjwatsonEtienneG: https://bugs.launchpad.net/launchpad/+bug/43179016:21
ubottuUbuntu bug 431790 in Launchpad itself "debian-installer images aren't signed in the archive" [Low,Triaged]16:21
EtienneGcjwatson, I see, thanks for the pointer!16:22
cjwatsonbroder: how about http://paste.ubuntu.com/586919/ ?16:29
=== jj-afk is now known as jjohansen
=== herton is now known as herton_lunch
=== deryck is now known as deryck[lunch]
dbarthjelmer: ping? do you have time for a question about git sub-modules?17:29
dbarthi'm trying to import compiz-plugins-main, which is made of sub modules; if ever that can be supported with some of the tools available17:29
=== dendrobates is now known as dendro-afk
=== herton_lunch is now known as herton
=== dendro-afk is now known as dendrobates
jelmerdbarth: hi18:02
=== sforshee is now known as sforshee-lunch
=== dendrobates is now known as dendro-afk
=== deryck[lunch] is now known as deryck
=== sforshee-lunch is now known as sforshee
willy_1977I'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 :p18:32
willy_1977bug #74317618:33
ubottuLaunchpad bug 743176 in gnome-utils (Ubuntu) "Pink layer on taken screenshots (gnome-screenshot)" [Low,In progress] https://launchpad.net/bugs/74317618:33
dbarthjelmer: hi18:34
dbarth(sorry missed the pong)18:34
dbarthjelmer: so any hope or workaround for mirroring a set of git sub-modules? i've tried with the development-subtree format18:35
dbarthjelmer: but then it failed with a stack trace when i tried to bzr pull the git module18:35
dbarthjelmer: 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 stage18:36
jelmerdbarth: fastimport/fastexport should work with git submodules and will just ignore them as far as I know.18:36
dbarthjelmer: ahah, ok, nice18:37
dbarthjelmer: i'll follow this track18:37
jelmerdbarth: 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:38
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
dbarthjelmer: hmm, i got this error when trying https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/74507018:40
ubottuUbuntu bug 745070 in bzr (Ubuntu) "bzr crashed with AssertionError in create_from_tree(): Unknown kind 'tree-reference'" [Undecided,New]18:40
dbarthjelmer: but anyway, right, it's not a production format for now, so i'll look at fastimport/export18:40
dbarththanks again18:40
jelmerno problem18:41
=== dendro-afk is now known as dendrobates
GrueMastermvo: Ping.  Any update on bug 533031?19:10
ubottuLaunchpad bug 533031 in command-not-found (Ubuntu Natty) "command-not-found fails to work on ports architectures" [Low,In progress] https://launchpad.net/bugs/53303119:10
mvoGrueMaster: 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 it19:25
GrueMastersigh.  ok19:26
mvoGrueMaster: sorry for that19:27
GrueMasterWould like to get this fixed for release though.19:28
GrueMasterLooks like the last note I have is from March 17 from Colin.19:31
mvothats the last I have as ell19:34
=== mtaylor_ is now known as mtaylor
highvoltagen/win2 020:18
brodercjwatson: you don't want to initialize match inside the hwmatch_iter function, do you?20:40
cjwatsonoh, probably not20:40
cjwatsonwants to be initialised outside that20:41
cjwatsonoh, and I should grub_file_close somewhere20:41
broderalso, 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 that20:43
broderanyway, really sorry i didn't get to it - work sort of consumed my life for the last few months20:43
brodercjwatson: i can't speak the correctness of your use of the grub libraries, but the logic looks correct to me20:47
cjwatsonbroder: it was only added about a year ago20:48
cjwatsonbroder: no problem, it didn't take quite as much time as I expected either ...20:49
cjwatsonI was expecting half a day or so's work, it was more like an hour20:49
cjwatsonbroder: OK, I'll toss that into the Ubuntu package post-beta-1, then - thanks for the review20:50
brodercjwatson: i'll try to make a point of doing some testing21:01
slangasekbroder: so hey, I did think of a multiarch-related task that'll need help this week21:12
slangasekbroder: 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 touched21:13
=== bjf is now known as bjf[afk]
broderslangasek: that totally sounds like something i could do21:57
broderhmm...is there a known issue with ubiquity in maverick? this is the second time i've gotten a segfault in libapt-pkg.so21:59
ScottKkklimonda is pretty good with that kind of thing too.21:59
brodermight be connected to checking the "download updates" box21:59
broderslangasek: and when i find those, it's just a no-change rebuild, right?22:01
slangasekbroder: "find" - I have the full list, let me post it22:04
slangasekbroder: 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 invest22:04
slangasekbut there are >100 affected packages, so... :)22:04
* micahg has libmpd already22:04
slangasekbroder: http://people.canonical.com/~vorlon/broken-srcs-universe.txt22:06
broderslangasek: 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:06
slangasekbroder: yes; in practice I've found it easier to just apply the dependency_libs sed trick to all affected packages22:07
slangasek(easier than tracking down revdeps and looking for .la files)22:07
broderhmm, 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:09
seb128seems that clean those would be better to do at a cycle start though22:10
slangasekanyway, 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 rebuilt22:10
slangasekseb128: are you concerned that cleaning them will break other things?22:10
seb128note that the GNOME stack is mostly clean of those for a while, we start on that for a while22:10
slangasekyep :)22:10
seb128slangasek, no, GNOME ones are already cleaned as I said ;-)22:11
seb128we have as a policy to not ship a .la for new desktop libs for some time22:11
seb128and clean-la was easy to use for cdbs sources22:11
slangasekyeah, though it seems that clean-la in cdbs has never made it upstream...22:12
seb128debian is upstream for cdbs or I'm missing something?22:12
slangasekand Debian doesn't have the clean-la.mk, last I looked22:13
seb128oh, it's in gnome-pkg-tools22:13
slangasekright - it's implemented both places :)22:13
slangasekonly the gnome-pkg-tools one is in Debian22:13
seb128well, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=58608222:13
ubottuDebian bug 586082 in cdbs "clean-la.mk rules file" [Wishlist,Open]22:14
slangasekso 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
seb128but when we had those discussions previously Keybuk argued that .la were useful and should not be cleaned22:14
seb128it has been hard to get a consensus on what to do22:15
slangasekoh, Keybuk's right22:15
slangasekit would be good to keep the .la files around for static linking22:15
slangasekbut nobody has ever fixed libtool upstream to DTRT for the dynamic linking case, so we do what we can - we fix it in the packaging22:15
slangasek(to avoid having to patch every single upstream source that uses libtool)22:16
seb128wouldn't be easier or better to put ressources on fixing libtool? ;-)22:16
slangasekhave you ever looked at libtool's source?22:16
seb128or upstream doesn't want it to be "fixed" for some reason22:16
seb128i.e like don't agree on what fixed would be22:16
seb128hum, no, and I don't think I want ;-)22:16
slangasekI 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 ;P22:17
seb128anyway it seems that after this round of cleaning we can start the next cycle the other way around and start dropping those if we want22:18
slangasekthat would be good... let's do it in Debian though, I don't want a thousand deltas for libtool :)22:20
seb128slangasek, indeed, and again I wonder why I'm talking there, the things I deal with are already out of those issues ;-)22:22
* slangasek grins22:23
kklimondaslangasek: so for now rebuilding all the packages should be enough? And then we can revisit it in oneiric?22:37
slangasekkklimonda: sure22:37
slangasektime allowing I think cleaning .la files is also ok, but there's no requirement to22:38
slangasekI think it will save a little bit of time overall in the end22:38
kklimondaslangasek: ok, I'll see how much time can I put into this :)22:40
slangasekkklimonda: cheers!22:40
slangasekkklimonda: which end of the alphabet are you starting from? :)22:41
kklimondaI'll start with g :)22:42
broderkklimonda: if you give me a sec, i'm working on a graph so we can make sure we get the dependency order right22:42
kklimondabroder: sure, I'm not going to start tonight anyway. It's too late for that :)22:42
broderkklimonda: cool. i'm taking work off on friday to jam, so i'll catch up with you then22:43
slangasektkamppeter: hi there - did you need something from me earlier, or was it the cups upload that pitti is taking care of?22:43
slangasekmr_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:44
tkamppeterslangasek, 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:46
ubottuLaunchpad bug 710881 in libpng (Ubuntu) "cups: Test Page /usr/lib/cups/filter/bannertops failed, test page and banner pages do not get printed" [Medium,Confirmed] https://launchpad.net/bugs/71088122:46
slangasektkamppeter: ah - please note that I don't know anything about libpng, I've only touched the package for library packaging issues22:47
tkamppeterslangasek, CUPS uses libpng to load PNG images, principally this works fine as long as the PNGs are RGBA,22:47
tkamppeterslangasek, sorry, I looked at the last thrree changelog entries and they were all from you. I wanted to make our libpng guru aware.22:48
slangasektkamppeter: yep, I understand how you drew that conclusion :)22:49
tkamppeterslangasek, 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
=== bjf[afk] is now known as bjf
tkamppeterslangasek, seems that libpng is not really maintained by Ubuntu but only synced/merged from Debian.22:54
slangasekyou're best off discussing this with upstream22:55
hvis there a channel for unity?23:11
TheMusohv: You want #ayatana.23:12
=== sconklin is now known as sconklin-gone

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!