[00:29] YokoZar: any luck with ia32-libs multiarching? [00:35] wow, that sounds nice & easy [00:36] hmm? [00:38] directhex: Shouldn't be *that* hard, right? “Just” pull in /usr/lib/i386-whatever-triplet/ :) [00:44] 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] 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] slangasek: hopefully there aren't any non-relative-path surprises and such in there [00:46] stgraber: I just noticed that the DMB isn't an administrator of ~edubuntu-dev [00:54] 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] 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] 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] 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] YokoZar: but if you want me to look at it I can [00:58] ia32-libs “multiarching” doesn’t mean “destroying forever”? :-P [00:58] RAOF: If you mail the DMB list then we'll work something out though (and it will let me raise this issue) [00:58] ion: not in one cycle it doesn't [00:58] ion: not given how long ia32-libs has been allowed to fester and continue accumulating libs [00:59] aye [01:02] $ dpkg -L ia32-libs|grep -c 'lib32/[^/]\+\.so' [01:02] 743 [01:02] :P === yofel_ is now known as yofel [01:19] slangasek: wtf? :p [01:19] does that include the symlinks too? [01:19] YokoZar: if you do want me to look at it, please say so explicitly :) [01:19] Chipzz: it includes whatever that regexp matches, I didn't filter too hard [01:19] slangasek: ah, so prolly /3 then :) [01:20] yeah, dpkg -L doesn't distinguish between files and links [01:20] ~250 libs, still pretty bad :/ [01:21] an upstart task triggers stopped/stopping events when the exec/script block exits, right? [01:21] dpkg -c ~archive/pool/universe/i/ia32-libs/ia32-libs_20090808ubuntu9_amd64.deb |grep -c '^-.*lib32/[^/]\+\.so' [01:21] 248 [01:21] broder: yes [01:22] hmm...i think i need to get better logs to figure out what's going on, then [01:23] broder: actually, no, sorry [01:23] broder: I confused myself - a task is "started" when the job finishes [01:23] and not before [01:25] so a task goes to the "starting" state, then it runs and stays in "starting", then goes to "started" when it finishes running? === dendro-afk is now known as dendrobates [01:28] broder: yes [01:30] er... maybe [01:30] ok, I don't know ;) [01:30] haha, ok :) [01:30] if I look at jobs that are tasks that definitely ran at boot time, they're in state 'stop/waiting' [01:30] i'll harrass SpamapS and the other people working on the upstart cookbook to figure out and clarify [01:31] right, that's what i was looking at [01:31] and those jobs should, barring bugs, emit stopping/stopped events at the end [01:31] 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] could be, but I think that would be inconsistent with the use of 'post-stop' scripts in several of the jobs [01:32] ok, you've officially got me digging through source code now, so report back on what i find :) [01:41] ugh. i might not have acquired enough of the upstart zen to know what's going on here [01:44] ah - but the logs might clarify what's going on [01:46] or maybe not, because all of the tasks in the normal boot happen before syslog is up [01:47] but certainly tasks transition through the running -> stopping -> killed -> post-stop -> waiting series of states [01:57] slangasek: how's your bandwidth? Can you upload the 800+ meg source package? [01:57] if I have to [01:57] I'd rather just send you a patch ;) [01:57] slangasek: That works best for me :) [01:57] a patch does? [01:57] yeah [01:57] ok [01:58] Then I'll add the libraries I need and make a huge upload overnight [02:10] 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] 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] broder, does order really matter? [02:12] psusi: sometimes. usually it's something like ubuntu is changing something that debian already changed [02:12] 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] it's no less valid of an order than the mostly arbitrary order imposed by the names of the patches [02:20] Bah. Stupid interaction of 3.0(quilt) and vcs! [02:23] win 24 [02:24] ETOOMANYIRCCHANNELS [02:24] lose 25 === 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 [03:51] @pilot out === 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: [04:06] RAOF: Is there any other kind of 3.0(quilt)/VCS interaction defined? === tumbleweed_ is now known as tumbleweed === 50UAAGBPG is now known as Amaranth === ssweeny_ is now known as ssweeny [05:58] Who has point for LibreOffice packaging: Debian or Ubuntu? That is, who syncs from whom? [06:05] hi all [06:06] any reason i wouldnt be able to use fglrx on casper with persistent changes [06:07] i really desperately need it or the radeondump tool which doesnt appear to be included anywhere in the earchive === _LibertyZero is now known as LibertyZero [06:47] YokoZar: bug #744767 [06:47] Launchpad 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/744767 [07:44] slangasek: man, that multiarch command sequence from your blog is *awesome* [07:45] 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] haha. cest la vie [07:45] although for the former issue, I have all the needed bits in ppa now [07:46] 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] (Well, packaging toolchain... And occasionally C++... And... Yeah, I'll stick with "all") [07:46] module gtk+2.0, which the buildds won't give me for another 2 hours or so [07:46] s/module/modulo/ [07:46] infinity: heh [07:47] 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] 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] sure, just figured i'd throw it out there [07:49] infinity: Your bitterness is showing [07:49] Er, more showing [07:50] 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] so because I'm out of major things to do for multiarch, that's the time I'll blog instead ;) [07:50] StevenK: Rumours of my bitterness have been greatly exaggerated for comedic effect. [07:52] infinity: No, they haven't. :-) [07:55] Good morning [07:57] * slangasek waves to pitti [07:58] 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. === JamieBen1ett is now known as JamieBennett [08:07] dholbach: Good morning [08:07] good morning [08:07] hey cdbs [08:09] dholbach: Hai. [08:09] hey infinity [08:09] infinity, MAN - long time no see [08:09] * dholbach hugs infinity [08:09] * infinity hugs dholbach. [08:09] I've decided to come back to annoy you. [08:09] hahaha, awesome :) [08:15] infinity: Dude! [08:16] soren: *wave* [08:16] sabdfl: I've lost track, are you in a disconnect storm, or actually joining the channel? :P [08:16] sabdfl: If the latter, "hi". [08:16] hey infinity, how are you? [08:17] infinity: adventures in multi-device connectivity here :-) [08:17] how are you, long time no speak [08:17] pitti: Alive and well. And I think this is more than I've typed in #ubuntu-devel in two years. [08:17] lol, yes [08:17] sabdfl: See above? :) [08:17] timezones still seem unchanged ;-) [08:17] I'm sure we can pull up some stats on that. [08:17] hey soren [08:17] sabdfl: o/ [08:18] sabdfl: I though you were in a very different timezone these days [08:18] good morning [08:18] thought, even. [08:18] Specifically, one that does not warrant being awake right now :) [08:19] 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] mvo! [08:21] Okay, now I'm getting all sentimental. === smb` is now known as smb [08:39] slangasek: universe libs only in ia32-libs yes? [08:40] YokoZar: hmm? === javalogger is now known as apachelogger [08:40] slangasek: eg can I add gstreamer0.10-plugins-ugly or just gstreamer0.10-plugins-good [08:41] oh, do you mean *main* only rather than universe? :) [08:41] there are both main and universe libs in ia32-libs [08:41] err no I mean "not multiverse" [08:41] neither of those are in multiverse [08:42] ia32-libs is in universe, so you can't add anything from multiverse to it, yes [08:42] not that I think you should really add anything more to it at all, but hey [08:42] but ugly plugins are in universe you say [08:42] yes, the good/bad/ugly split of the packages has to do with code quality and support, not freeness [08:43] ok that makes me feel better [08:46] RAOF, happy patch pilot day [08:48] ogra_: did you want to keep rhythmbox on the armel ubuntu-netbook images? If so, can you please seed it appropriately? [08:48] 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] soren: no, i'm trying to narrow my timezones! where did you think i was? [08:51] sabdfl: I heard a rumour about US East coast. New York or something. [08:53] ah, yes, i have bought a place there, it's about as far from GMT as I'd like to live [08:53] going to take a while to get it fixed up though [08:53] i'm concentrating on Isle of Man and Cape Town at the moment [08:53] and my little tropical love affair [08:56] sabdfl: Sounds lovely! === tkamppeter_ is now known as tkamppeter [09:03] slangasek, hi === lool- is now known as lool [09:41] Why are there binaries for libx264-98 still in archive when source package x264 provides libx264-106 instead now? [09:43] 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] YokoZar: see http://people.canonical.com/~ubuntu-archive/nbs.html [09:43] YokoZar: the old packages still have rdepends, they need some transition uploads [09:44] pitti: in this case, all on ppc... [09:44] Man, libx264. Because ABIs are hard! :) [09:45] yes [09:46] ffmpeg too D: [09:46] dpm: is bug #744831 something that should be on langpack-o-matic or is it in the right place? [09:46] Launchpad bug 744831 in language-pack-as (Ubuntu) "file overwrite error" [Undecided,New] https://launchpad.net/bugs/744831 [09:46] RAOF: both are windows centric and assume you do a source checkout and use it as is in your software === doko_ is now known as doko === shana` is now known as shana [10:37] 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] for instance linaro/ubuntu gcc has fixes not yet upstream, so we have a gcc bugtask open on some bugs [10:38] ex: https://bugs.launchpad.net/gcc/+bug/398403 [10:38] Ubuntu 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:41] doko, ^ ? [10:43] hmm, linaro uses a project linaro-tracking ... (or something like this) [10:43] lool: ^^^ [10:46] infinity: hi! awesome. [10:46] mvo, yeah, I think langpack-o-matic would be the right place for bug 744831, pitti, what do you think? [10:46] Launchpad bug 744831 in language-pack-as (Ubuntu Natty) "file overwrite error on upgrade from maverick -> natty" [Undecided,New] https://launchpad.net/bugs/744831 [10:47] ogra@panda:~$ archdetect [10:47] armel/unknown [10:47] * ogra_ scratches head [10:48] i thought we had panda support in archdetect [10:48] dpm, mvo: erk, because packagekit moved; yeah, need some extra replaces, I think [10:49] mvo: how much does this break update-manager? (didn't it use to ignore file overwrites, or retry a few times?) [10:49] asking because rebuilding all -base packs will take a looong time [10:50] bug updated [10:54] bah, cpuinfo strings changed [10:54] pitti: its only a issue for people upgrading manually so not beta1 critical [10:55] mvo: ok, thanks; milestoned to b2 now [10:56] thanks [11:03] 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] janimo: Sorry, not sure what you're trying to solve [11:07] lool, to reduce the number of bugs listed as needing attention in ubuntu, while triaging [11:07] 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] janimo: If the bug is fixed in the Ubuntu package you certainly should close the Ubuntu task [11:07] 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] pitti, can you upload CUPS from BZR, to get the fix/workaround for bug 710881 into the beta? Thanks. [11:08] Launchpad 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/710881 [11:08] janimo: That sounds like a bug in the script? [11:08] tkamppeter: doesn't sound critical for the beta release (not important enough to delay it, anyway) [11:08] tkamppeter: I'll upload it after b1 [11:08] lool, LP ui, not sure what script is involved [11:08] janimo: Can you give me a sample URL? [11:09] LP for instance this appears in the list of bugs of armel-porters https://bugs.launchpad.net/gcc/+bug/398403 [11:09] Ubuntu 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] ricotz: hm, confirmed here [11:09] even if it is only a Gcc 4.3 upstream task involved [11:10] pitti, ok ;), so it is an apt or archive problem [11:11] janimo: But where did you get this bug from? [11:11] janimo: it seems to me you're searching all bugs in launchpad tagged armel instead of just the Ubuntu ones? [11:11] pitti, ricotz, maybe bug 677733? [11:11] Launchpad bug 677733 in apt (Ubuntu) "Download of the same lists" [Undecided,New] https://launchpad.net/bugs/677733 [11:11] janimo: Technically, this bug is still open upstream [11:12] lool, I think I went to armel ubuntu porters and listed bugs associated to them [11:12] indeed it is still open upstream [11:13] 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] 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] it is noise [11:15] 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] pitti, our settings are in unity-2d itself, both are transitional packages ... [11:16] 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] janimo: In the worst case, you could have a project blacklist if that's not exposed by the API [11:17] unity-2d-default-settings | 0.4 | natty/universe | source [11:17] unity-2d-default-settings | 3.8.1-0ubuntu1 | natty | all [11:17] oh, fun [11:17] lool, ah certainly. I just with LP UI itself was cleaner [11:17] 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] ogra_: ^ i. e. universe has a newer version than main [11:17] ogra_: so if at all they are ok in universe [11:17] why is 0.4 newer than 3.8 ? [11:17] ogra_: but I'd like to remove the unity-2d-default-settings source package then [11:18] ogra_: sorry, ignore me [11:18] 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] yes, that definitely can go [11:18] ogra_: ok, thanks [11:18] janimo: ? [11:19] pitti, thanks for the heads-up :) [11:19] 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] 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] 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] the latter should be in universe [11:20] ogra_: moved [11:20] for linux-tools, i guess you need to ask the kernel team if we need them [11:20] i'll happily seed them if so [11:20] 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] 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] I'm pretty sure you could search Ubuntu bugs where ubuntu-armel is sub-ed though [11:22] 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] janimo: http://goo.gl/b8Xk1 [11:25] 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] 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] pitti, OK. [11:26] janimo: we're working on it :) [11:26] lifeless, good to know :) [11:28] janimo: Well, you're the one who knows "ubuntu-armel" only cares for Ubuntu [11:29] janimo: The link I pasted doesn't list it, does it? [11:29] lool, it does not indeed [11:29] janimo: I went to bugs.launchpad.net/ubuntu, hit Advanced search and put "ubuntu-armel" in Subscriber; that's it [11:30] 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] 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] 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] pitti, is there a way to stop the retracer aggregating all kind of unrelated ubiquity failures to bug 652916 [11:33] Launchpad 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/652916 [11:34] 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] right [11:35] jibel: you mean all those debconf bugs have a different cause? [11:36] 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] shana: here? [11:36] pitti: morning! [11:36] 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] shana: morning, how are you? [11:37] shana: I just finished building webkit svn trunk again (this time with introspection enabled), and had a look [11:37] pitti: a bit coffee-deprived, but otherwise good [11:37] shana: to my surprise, glib:signal name="hovering-over-link" is actually in the .gir *twice* [11:37] shana: once with wrong dummy argument names, the second one is the correct one [11:37] sorry about not opening the bug yet, soc has been siphoning all of my time [11:38] pitti: orly?? [11:38] hmmm [11:38] shana: but both have which seems fine? [11:38] pitti: unfortunately the thing that notices is on the other side of a pipe from what could provide more information [11:38] pitti: the error means "the debconf frontend I was talking to fell over" [11:38] pitti: shana: why? [11:39] cjwatson: is there any way we could extract more useful information out of this after the crash happened? [11:40] 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] shana: (btw, only gchar* is translated to "utf8", so you can actually assume that) [11:40] of course, I can map those new type names, I guess [11:41] shana: do you depend on always having the c:type one? [11:41] pitti: I did, since every single entry on the gir file has one [11:41] shana: ok; I guess as a first step I'll track down why it appears twice [11:41] it's a standard on every parameter on every method, every type, everything [11:42] pitti: the problem is that multiple python processes crash; we get useful tracebacks from the other one ... [11:42] cjwatson: ah, we do? so perhaps we should just generally ignore this crash on the ubiquity side then? [11:43] pitti: take a look at the gist again, I added a comment with other entries on the gir file [11:43] cjwatson: the ubiquity hook is in the apport source, so I could tweak stuff there [11:43] pitti: maybe, DebconfCommunicator is started in a load of different place [11:43] s [11:43] pitti: utf8 is mapped as gchar* in some places, gchararray in others [11:43] actually, it's pretty odd that that particular one is relevant to anything [11:44] pitti: I'm not absolutely certain, but on the whole I suspect ignoring that one would improve our bugs [11:44] 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] 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] 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] cjwatson: but I guess that would already be an improvement [11:45] in this case, what *actually* happened was that usermod segfaulted and then a chain of dominoes fell over [11:46] 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] 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] 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] I think my tree is built [11:47] at least I think I left it building at one point [11:47] * shana pokes [11:48] 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] pitti: ah, here - there may be a genuine bug here in that that debconf-communicator instance isn't shut down properly [11:49] normally it isn't a problem, but if something else goes wrong, it produces spurious crap like that [11:51] pitti: I've fixed that in ubiquity bzr now [11:51] 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] any ideas? [11:51] cjwatson: cheers [11:52] ara: try with DEBCONF_DEBUG=developer set in the environment and post the resulting stderr [11:52] ara: I bet the questions are marked as seen [11:52] (actually, ignore that last line) [11:52] * ara tries [11:53] ara: Why the -p? dpkg-reconfigure defaults to low. Not even sure what the behaviour is with -p and no priority specified. [11:54] infinity, -pmedium, that's it [11:56] shana: ah, there are indeed two different signals; one for the WebFrame class, the other for the WebView class [11:56] infinity: (syntax error) [11:56] shana: and the webview one simply isn't annotated; I'll add that [11:57] cjwatson: Remembered off the top of your head, or attempted for curiosity? :P [11:57] guessed and checked for curiosity :-) [11:57] pitti: ah yes, you're right, now I see it [11:58] 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] 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] pitti: and why it could before but now it doesn't [11:59] not exactly sure what's going on there [11:59] and this webkit was built when I was on lucid, darn [11:59] shana: but Gtk-3.0.gir doesn't have c:types for it signals eitehr [11:59] pitti: that scares me a bit more [12:00] shana: would you mind asking about that in #introspection? [12:00] DEBCONF_DEBUG=developer sudo dpkg-reconfigure -pmedium checkbox > /tmp/stderr 2>&1 [12:00] and the file is empty [12:00] jumping there now [12:00] shana: (just saw that you joined; I'll listen and learn) [12:03] ara: s/DEBCONF_DEBUG=developer sudo/sudo DEBCONF_DEBUG=developer/ [12:03] shana: that looks better :) http://paste.ubuntu.com/586811/ [12:03] awesomesauce! [12:03] that looks indeed much better :) [12:04] * pitti does the svn diff from hell [12:04] shana: http://people.canonical.com/~pitti/tmp/WebKit-1.0.gir [12:04] ah, svn [12:04] shana: ^ freshly built with the patch [12:04] * shana looks [12:04] shana: yeah, svn :/ slow as hell, no local commit and format-patch, etc. [12:05] *ugh* *ugh* clapping stones together, grabbing club [12:05] with svn repos I work with git locally and push with git svn [12:05] otherwise I'd go nuts :P [12:05] 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] nodnod [12:06] good to hear [12:06] the c:type is annoying, hopefully it's a bug and not a feature [12:06] 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] http://pastebin.ubuntu.com/586813/ [12:06] I could, but then on other types there'll be more problems [12:06] shana: (since that's what g-i defines according to http://live.gnome.org/GObjectIntrospection/Annotations) [12:06] broder: have you got anywhere with rewriting grub hwmatch in C? [12:06] like [12:07] utf8 might be straightforward, but other types certainly aren't [12:07] I can do reverse lookups on other places where the type is defined correctly so I don't have to "guess" [12:07] right [12:08] 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] but seeing as all other types have a corresponding c:type, I'd like to know what makes glib:signals so special [12:08] pitti: sure [12:08] shana: well, for normal methods g-i reads the function prototype [12:09] shana: for signals it needs to parse the g_signal_new() constructor [12:09] pitti: thanks for the time, most appreciated :D [12:09] shana: i. e. it's two different code paths; that might explain why they behave differently [12:09] pitti: I see, interesting [12:10] maybe it's really a bug that slipped in [12:10] I really hope it is [12:10] otherwise my xslt is going to take twice as long to convert the .gir [12:11] and I'm worried that utf8 is represented with two different native types there [12:12] 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] oh well [12:12] *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] hahaha [12:12] ouch, what happened here [12:12] svn strikes back [12:12] 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] shana: can you even pass arbitrary objects through signals? Don't they need to be defined in terms of existing G_TYPE_*? [12:14] ah, ignore me [12:14] of course you can use G_TYPE_FROM_CLASS(...) [12:14] nod [12:15] cjwatson, http://pastebin.ubuntu.com/586813/ [12:15] but I guess at this point g-i's parser might give up [12:15] any clues? [12:15] ara: well, it's simply not asking the questions [12:15] pitti: maybe, but it worked before, so at some point the parser was happy with signals [12:15] I mean, it's not even trying [12:16] shana: ah, good to know [12:16] shana: so for now, let's just hope you won't need the really complicated signals :) [12:16] ara: You're not asking for input, just doing gets? [12:16] ara: ah - checkbox.config bug. change 'configure' to 'configure|reconfigure' - or just remove the case entirely [12:16] pitti: there's always ways around it, I'm just hoping I don't have to hack it :) [12:17] cjwatson, cool, I will try that, thanks a lot [12:17] ara: http://paste.ubuntu.com/586814/ [12:17] the parameter names were the more problematic thing for me, so I'm happy :) [12:17] ara: Ahh, yes, all the db_inputs happen in configure. :) [12:20] shana: there are 5 more instances, I'll fix them as well; give me some minutes === MacSlow is now known as MacSlow|lunch [12:41] pitti: c:type bug -> https://bugzilla.gnome.org/show_bug.cgi?id=646080 [12:41] Gnome 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:45] shana: subscribed, thanks! [12:45]