[00:11] Amaranth: that happens when you poke at opengl sometimes :) [00:12] cj: nah, was xulrunner fail, reinstall fixed it === onestone_ is now known as onestone [02:10] so no help here eh? waited 30 mins in #ubuntu with no love === bluesmoke is now known as Amaranth === bluesmoke is now known as Amaranth === bluesmoke is now known as Amaranth === tkamppeter_ is now known as tkamppeter [08:31] asac: have you seen http://paste.ubuntu.com/104758/ ? this happend to me on a intrepid->jaunty upgrade [08:38] morning o/ [08:45] morning everyone [09:02] asac: together with http://paste.ubuntu.com/104760/ [09:05] asac: I think this is a side effect of dropping the 81_sonames.patch ? [09:06] asac: anyway, it seems to have made my upgrade unhappy :) [09:08] asac: bug #316941 [09:08] Launchpad bug 316941 in rhythmbox "[jaunty] Rhythmbox missing shared library libnss3.so.1d" [Undecided,New] https://launchpad.net/bugs/316941 [09:09] asac: you should have changed the binary name or conflicted on everything using the library that needs to be upgraded [09:10] hello asac and seb128 [09:10] lut huats [09:11] how are you seb128 ? [09:11] huats: good thanks, how are you? [09:11] great too! [09:17] seb128: any idea where should I look to try to fix the issue I am facing with python-gtk2-dbg, that is blocking for the deskbar-applet ? [09:18] (a missing symbol in the -dbg) [09:18] huats: the pygtk rules? [09:18] huats: it's likely that the non-dbg version gets installed as dbg for some reason [09:18] seb128: I'll have a look in that way [09:19] you can try to ping lool pochu or slomo about it maybe, we synced pygtk on debian this cycle so the bug is likely there too [09:20] ok [09:21] huats: Check your build log to see whether an automatic autoreconf is triggered; if that's the case you want the fixes we have in Debian SVN [09:22] huats: Actually I see a typo now [09:22] PYTHON=/usr/bin/python$* $(MAKE) -C dbg-build-$* [09:22] Fortunately it escaped hardy-updates [09:24] lool: hello btw ;) [09:26] lool: I'm testing it, to see if it works with that [09:26] huats: Just committed the fix in Debian's SVN [09:26] Don't know whether that was your issue [09:26] ok [09:27] an missing symbol [09:27] I can get you the steps to reproduce [09:27] (easy..) [09:31] lool: python-dbg -c "import gtk" doesn't work [09:31] lool: the version installed as dbg seems to be the non dbg one [09:33] seb128: the dbg .so and the non dbg one, at least differs (using to check diff) [09:33] I'm a bit busy to say the least; would you mind trying the version in the Debian experimental *SVN* and see if that helps? [09:33] This python dbg stuff keeps breaking every 2 months and takes me 2 days to fix [09:33] seb128: the idea is that there is a link [09:34] asac: ok so it seems to not work correctly? could you look at this bug and maybe ask whatever you need to debug the issue? [09:36] seb128: have you upgraded to latest nss? [09:36] asac: no, jaunty moves to quickly for me ;-) [09:36] I'll try to upgrade now [09:36] do you have this link? [09:36] asac@hector:~$ ls -l /usr/lib/libnss3.so.1d [09:36] lrwxrwxrwx 1 root root 10 2009-01-11 21:41 /usr/lib/libnss3.so.1d -> libnss3.so [09:38] asac: yes, that is working here [09:39] see ... all fine. damn [09:39] whats the problem for this guy [09:40] not sure, maybe ask the version he's running and if the symlink is there [09:40] i dont even know what to ask for ... now asked for upgrade temr.log [09:40] asac: where do you do the symlinking? [09:40] seb128: so ... the tricky thing here is that the link was flipped. [09:40] lool: sure [09:41] in previous version it was libnss3.so -> libnss3.so.1d ... and now we have libnss3.so.1d -> libnss3.so [09:41] so i move the files away in preinst [09:41] lool: to ease stuffs, I'm trying the newer in jaunty with that fix you just mentionned [09:41] so that the unpack doesnt do the wrong thing [09:41] i tested various upgrades and downgrades here, but nothing [09:41] but after that I'll have a look at the debian experimental for sure... [09:42] asac: that doesn't rely on a -dev to be installed right? [09:42] seb128: no. its really ugly i know. but thats where it comes from: [09:42] we took package with soname version patch from debian: [09:42] normal package has libnss3.so.1d [09:43] and -dev has link libnss3.so -> libnss3.so.1d [09:43] huats: The changes include autoreconf patches and changing PYTHON in a bunch of places [09:43] then complains came that upstream binaries dont work here [09:43] lool: ok [09:43] debian and ubuntu moved the link to the "normal" package [09:43] lool: so I will take right now the debian one [09:44] then upstream complained the binaries built in ubuntu are not compatible with upstream nss [09:44] i discussed this for a while and we found that the soname version was indeed senseless [09:45] so we ended up in this link flip [09:45] respin of all rdepends would fix this for sure [09:45] (and we could drop the link) [09:45] heh [09:45] asac: I see [09:46] yeah but well. [09:46] lets see what he answers [09:48] asac: just reproduce the failure here, stock intrepid->jaunty [09:49] mvo: ok so when you upgrade from intrepid? [09:49] asac: yes [09:50] asac: it looks like dpkg is screweing up for some reason during the upgrade - the symlinks from the new package are not there [09:50] mvo: yes i even looked at ldconfig output [09:50] asac: but when I manually install the same version again (dpkg -i /var/cache/apt ..) it works [09:50] which is a bit scary in fact as ldconfig seems to remove links (so it could be) [09:50] mvo: my current bet is that ldconfig is messing stuff up [09:50] asac: yeah, I suspect that its really ldconfig doing this [09:51] however, i looked at the code and when it spits out the "is not a symbolic link" [09:51] it sets no_remove=1 [09:51] asac: I file a bug and target it for alpha-3? [09:51] so the bug is 316452 [09:51] asac: aha, thanks [09:51] mvo: not sure if its the best to target for alpha-3 [09:52] i mean, I still dont understand where the issue happens [09:52] (if its not the ldconfig thing) [09:52] asac: I can reprodcue it here reliably, I will poke it a bit [09:53] mvo: how do you reproduce it post upgrade? [09:54] asac: I can not, I let the upgrade tester run, wait for the bug to appear and log into the system [09:54] mvo: cool [09:55] let me get the ldconfig code ... which definitly does link shuffline [09:57] bug #316452 [09:57] Launchpad bug 316452 in nss "[jaunty] last update broke some libraries (libnss3-1d, libnspr4-0d)" [Undecided,Confirmed] https://launchpad.net/bugs/316452 [09:57] ok see you milestoned it ;) [09:58] mvo: also nominating ;) woujld make this official? [09:58] asac: high or criticial (high should be enough, right?) [09:58] high is gok [09:58] ok [09:58] mvo: so: /usr/lib/xulrunner-1.9.0.5/xulrunner-bin: ... output [09:59] is already a consequence of the missing link [09:59] thtas in xulrunner postinst [09:59] it runs xulrunner-1.9 --version [09:59] (probably a bad idea) [10:00] well, this way at least we know that its broken :) [10:00] what i do in preinst of nss/nspr is to move the link and the old binary to a backup name [10:00] and in cased upgrade fails move it back [10:00] if it works remove the backup files in postinst [10:00] could be that there is a bug too [10:04] http://paste.ubuntu.com/104781/ ... thats ldconfig code [10:05] the error is printed in line 465 [10:05] err 468 [10:06] and a "unlink" in 485 [10:06] but if the error happens do_remove = 0 ... so it shouldnt do the unlink [10:08] asac: I haven't looked at the code yet (ldconfig) but is it maybe doing something silly when e.g. trying to cleanup all existing symlinks that are releated to the lib? [10:09] not sure ... i thought so, but i cannot se it ... at least not directly related to the error mesage [10:09] but probably that message is a red herring [10:16] mvo: how could it happen on upgrade from intrepid, but not from jaunty? [10:16] well ... assuming that it doesnt happen when you come from jaunty [10:16] as seb didnt see it; i didnt see it and fta didnt see it either [10:17] probably not much a technical difference, right? [10:17] asac: you could ask this user if he upgraded jaunty or intrepid [10:17] hmm [10:17] Hello! I'm running an (almost) up-to-date Jaunty here. [10:17] asac: just more churn [10:17] Earlier today I did an "aptitude safe-upgrade" [10:18] thats what the initial reporter says [10:18] lool: the current debian-svn is not fixing it [10:18] I mean the one in experimental [10:19] lool: I file a but on LP ? [10:19] s/but/bug/ [10:19] huats: do you want me to look at the issue? [10:20] fta: can you fix pastebinit in universe ;)? [10:20] seb128: sure [10:20] fta: your package works fine now that i installed it. any reason that didnt go to universe? [10:21] asac: I just checked the preinst/postinst, that looks all right [10:21] mvo: can you try to upgrade without the xulrunner-1.9 package installed? (so we can pin down that message as either the cause or the result) [10:21] i guess its result [10:21] but who knows if its the result-cause ;) [10:21] due to some rollback [10:22] seb128: just tell me if I can do anything... [10:23] huats: ok, I'll tell you if required [10:23] huats: you could try to debug it but apparently you already tried that ;-) [10:24] seb128: :) [10:25] huats: Is there an autoreconf running during the build? (grep for recheck) does pygobject have the issue? [10:26] lool: let me check [10:26] huats: pygobject has the same bug actually *sigh* [10:26] Committed [10:27] seb128: and lool : at the end of the build, the is that : [10:27] dpkg-shlibdeps: warning: symbol Py_InitModule4 used by debian/python-gtk2-dbg/usr/lib/python-support/python-gtk2-dbg/python2.5/gtk-2.0/pangocairo_d.so found in none of the libraries. [10:27] (and many others, but it is the missing symbol) [10:27] That's ok in itself [10:27] huats: the symbol is the non debug one [10:28] mvo: another idea would be to make ldconfig a no-opt script before upgrading ... but i guess its the new ldconfig which we would have to make a noopt [10:28] I only get the issue in pygtk; not pygobject [10:28] it should be Py_InitModule4TraceRefs rather [10:28] Now that doesn't mean pygobject is actually correctly built [10:28] lool: [10:28] $ python-dbg -c "import gobject" [10:28] [12115 refs] [10:28] I would say it is [10:29] seb128: Consider that _glib.so or unix.so or _gio.so can do some different ABI calls [10:31] seb128: Ok, I checked all of them it's fine [10:31] And it's not for pygtk-dbg [10:35] lool: I don't find the autoreconf, but I might be wrong [10:39] Ok, then no idea [10:39] asac: hm, right now (upgrade sitll running) I have libplc4.so.0d -> libplc4.so.0d.new-migration [10:40] hmm [10:40] thats not intended [10:40] and there is code in ldconfig [10:40] that remove stale symlinks [10:41] (everything with ".so." in them and and target for the link [10:41] asac: lets wait until ldconfig gets trigger here during the upgrade to confirm my theory [10:42] i do mv /usr/lib/$f.0d /usr/lib/$f.0d.new-migration in preinst [10:42] (nspr) [10:42] asac: most mysterious, a upgrade in a pbuilder chroot with just xulrunner-1.9 results in the correct behaviour [10:44] too bad. the only intrepid setup i have here already has the new package :/ [10:44] ok. so lets think ;) [10:45] when we start libplc4.so is a symlink to libplc4.so.0d .... now in preinst i mv libplc4.so libplc4.so.new-migration and libplc4.so.0d to libplc4.so.0d.new-migration [10:45] i dont really see how we can end up with libplc4.so.0d -> libplc4.so.0d.new-migration [10:46] so probably that link is already produced by ldconfig? [10:51] asac: I guess that makese sense [10:51] mvo: so i probably have to move that link to mktemp -d? [10:52] i mean instead of keeping it in a place where ldconfig finds the .new-migration file? [10:53] mvo: or maybe chmod 000 ;) [10:56] asac: maybe mktemp, I can try that here [10:56] mvo: oh i look at ldconfig [10:56] asac: or you give me a debdiff and I build the package [10:56] if (((strncmp (direntry->d_name, "lib", 3) != 0 [10:56] && strncmp (direntry->d_name, "ld-", 3) != 0) [10:56] || strstr (direntry->d_name, ".so") == NULL) [10:56] so maybe we can just prefix it [10:57] e.g. Xlibns [10:57] let us try that [10:58] asac: ok [10:59] asac: the auto upgrade tester can test based on a local repo (or a PPA), if you push it to your jaunty PPA I can test the change [11:11] mvo: ok uploaded to ~asac/+archive [11:12] http://pastebin.com/f6f29dc1a [11:12] http://pastebin.com/f6dc57bfe [11:12] mvo: ^^ [11:12] thats what i did ;) [11:15] https://edge.launchpad.net/~asac/+archive [11:15] all builds waiting for cycles :/ [11:16] mvo: which arch are you testing (so i can give you heads up when stuff is there) [11:16] i386? [11:18] huats, lool: ok, I found the pygtk dbg issue [11:18] seb128: great ! [11:18] asac: the auto upgrade tester can test based on a local repo (or a PPA), if you push it to your jaunty PPA I can test the change (not sure if you got that before I disconnected) [11:19] huats, lool: the patch on http://bugzilla.gnome.org/show_bug.cgi?id=556130 was in the intrepid version and has been dropped apparently [11:19] mvo: i got that ;) but i talked to you afterwards ;) [11:19] Gnome bug 556130 in general "bogus override of python includes in configure.ac" [Normal,Unconfirmed] [11:19] asac: I did not get the stuff afterwards [11:19] mvo: http://paste.ubuntu.com/104801/ [11:20] asac: thanks. I test on i386 [11:20] mvo: i will let you know ;) [11:20] asac: I can build local package too if it take too long [11:21] but I need to deal with fglrx/nvidia upgrades too [11:21] mvo: i think that would be better [11:21] ok [11:21] seb128: pfff [11:21] ppa takes about 30 minutes to make .debs available [11:21] after the build has finished [11:21] I misread the patch... I have looked at it, and thought it was a + (not a -).... [11:22] and I figure out it was included upstream [11:22] I could have save you time :( [11:22] mvo: can you take the patches from the pastebin or shall i poast them in pure form? [11:23] asac: I can take the .dsc from the ppa, no? [11:23] mvo: if they are available yet, then yes [11:23] mvo: otherwise its: http://people.ubuntu.com/~asac/tmp/nspr1.diff [11:23] http://people.ubuntu.com/~asac/tmp/nss1.diff [11:24] asac: it seems to be publish already? [11:24] including the debs :) [11:25] eh, no. build, but not published yet [11:26] mvo: after build has finished it takes 20-40 minutes to get published [11:27] which is sad ;) [11:27] before it took 20-40 minutes to start build, but close to zero publishing time [11:27] now its zero time till build starts and 20-40 minutes afterwards ;) [11:27] mvo: but well. maybe do something else [11:27] you hav eprobably other stuff to do [11:27] i currently feel positive that we have nailed this! [11:28] asac: thanks, I do the xorg stuff in the meantime [11:45] asac: the upgrade test with your ppa is now running, it will take ~30min to compelte, I think I go for lunch now [11:46] ok ... [11:46] * asac crosses fingers [11:46] mvo: enjoy. tausend dank! [11:46] asac: thanks :) [11:50] * asac really hopes that this is the last time he has to do something nasty like a lib-link-flip in /usr/lib/ ;) [12:03] asac: so far it looks *much* happerier (also not finished yet :) [12:04] asac: what does plds actually stands for? [12:11] heh ... really good question [12:12] 93% done and still going strong *go jaunty go* [12:13] hehe [12:15] mvo: nspr netscape portable runtime ... so PL could stand for "portable library" ;) [12:15] mvo: and the ds lib comes from the lib/ds/ tree ... might be something like "data structures" ;) [12:15] so in a README i found: character prefix, "PL_" (Portable Library). Internal function names [12:16] so first theory is true ;) [12:17] so we have nsprpub/lib/ds and nsprpub/lib/libc ... matching plds and plc ;) [12:23] asac: worked fine, please upload [12:25] thanks! [12:32] mvo: ok uploaded. i replaced the prefix with something more sensible ... lets hope that my sed-fu is good enough ;) [13:24] seb128: ok you fixed the bug :) [13:25] thanks :) [13:25] huats: you're welcome ;-) [13:26] seb128: so I return working on the deskbar update [13:26] good ;-) [13:26] sorry deskbar-applet [15:00] seb128, srag stated he forgot to update e-e Makefile.in to require 2.24.3 [15:01] hggdh: right, that was expected, the question is rather the other way around [15:02] hggdh: why e-e 2.24.2 crashes evo 2.24.3 [15:02] seb128, heh. I am still sleeping, sorry [15:02] hggdh: no problem, I did update e-e to 2.24.3 today but it needs to get accepted now [15:03] still they broke binary compatibility in some way or e-e 2.24.2 should still be working [15:03] * hggdh agrres... I asked about that yesterday, but did not get a full answer [15:03] seb128: I have put the deskbar-applet update on LP [15:03] huats: thanks [15:03] I will look again at the xchat-gnome now [15:04] huats: that one should be easier ;-) [15:04] (but the last time I checked there was something weird...) [15:04] not sure :) [15:05] seb128: I will start to think that didrocks asked you to give me some updates with issues ;) [15:05] ah ah [15:15] seb128, correct dependency is on e-d-s 2.24.3 [15:15] so ABI did change [15:15] in a stable version update... [15:29] (seb128: don't tell him, please) :) [15:30] didrocks: ok I won't ;-) [15:30] hehe [15:32] * didrocks is eager to have an update with an ABI break to have a look at librairies issues :p [15:49] didrocks: want some challenges? I've some tricky updates on my list ;-) [15:49] one of those being called GTK 2.15 ;-) [15:50] * seb128 kicks directfb [15:58] seb128: hum, GTK 2.15, seems fun :) [15:59] seb128: I won't be able to do them tonight (my company "celebration"), but tomorrow, why not having a deep look [15:59] after having played with gnome-games :) [15:59] didrocks: do gnome-games it's already non trivial, they started using clutter apparently [16:00] i thought the clutter dep was optional though? [16:00] seb128: there's a game that uses seed now as well [16:00] could be, I didn't try [16:06] didrocks, do you mean you work on ubuntu at work !!!! [16:06] * crevette calls didrocks' boss [16:07] lol [16:07] crevette: no, that's huats ;-) [16:07] seb128: thanks I will enjoy gnome-games so \o/ [16:08] crevette: and no. I am really working now. You have to call huats' one :) [16:13] :) [16:14] https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/315156 [16:14] hi all [16:14] Ubuntu bug 315156 in nautilus "Installs unnecessary desktop file" [Low,Triaged] [16:14] someone can say me if is rith to take it out or not === mvo_ is now known as mvo [17:02] mvo, hello [17:03] mvo, I updated my metacity branch to update changelog with the one dholbach uploaded, perhaps you're interested to pick it up ? [17:04] crevette: yes, thanks [17:05] crevette: he was quicker than me with the sponsoring [17:05] :) [17:05] crevette: what is the branch name again? [17:05] ah sorry [17:06] lp:~bmillemathias/metacity/ubuntu [17:07] crevette: thanks, merged [17:07] mvo, thanks [17:08] mvo, I have a dumb question, is it possible to have apt-get pick up latest revision when we get apt-get source metacity for instance and update debian/ [17:08] I don't know if it have so sense or not [17:09] s/it have so sense/it has some sense/ [17:10] maybe svn-buildpackage will help? [17:10] crevette: that was discussed in the past, if there is a vcs-bzr header, just use lp to get it [17:10] I think its a good idea [17:10] it just needs to get implemented :) (should not be too hard though) [17:11] mvo, so actually the line "Vcs-Bzr: http://code.launchpad.net/~ubuntu-core-dev/metacity/ubuntu" in control.in is not used at the time bieng [17:11] except to print a message [17:16] crevette: yes, just as a guide for the package maintainers, not to get the latest source [17:26] anyone finding the new volume control stuff frustrating? [17:29] * cj <3 lvm [17:29] oh, you mean audio volume, don't you? [17:30] crevette: I think you can use `debcheckout $package` to get the source from the Vcs-* header [17:34] debcheckout is in devscripts [17:35] pochu, I need to run that in the package source ? [17:36] seems rather simple :) [17:36] crevette: not necessarily, you can run it anywhere :) [17:37] yeah but I think this is more convenient [17:37] :) === asac_ is now known as asac === fta_ is now known as fta [22:10] macslow? [22:26] tretle, what's up? [22:26] hey [22:26] long time no blog :D lol [22:27] Yeah, I was wondering whether you could tell me whether any work has been done on the gdm side to implement clutter ui support? [22:27] tretle, some ... but not fully done [22:28] first thing is to put gdm 2.24.x in [22:29] is that not in jaunty yet? [22:31] also was your work on sparkle done in pigment, I was thinking of reusing some of the widgets to create a globe for the ubuntu live cd installer time zone selection. [22:31] tretle, gdm 2.24.x is planned for jaunty afaik [22:31] tretle, no ... sparkle is all plain OpenGL [22:32] ah nice [22:32] :D [22:33] so after gdm gets pushed into jaunty what pieces to the puzzel will be missing to integrate a clutter based ui? [22:36] hmmm.... seems 2.20.8 is currently being used in jaunty [22:37] MacSlow: are you that slow guy from linpeople? [22:41] ? [22:42] cj, no idea [22:42] tretle, a new greeter [22:44] so the new greater hasnt been started yet? is there any blueprints up or project page that I could keep up to date with? [22:44] there's one on wiki.ubuntu.com [22:45] tretle, https://wiki.ubuntu.com/DesktopTeam/Specs/GdmFaceBrowser [22:47] how much work will need to be done on creating a new greater? [22:48] tretle, lots [22:50] would it be the gdm guys working on it or you? [22:53] MacSlow: if you haven't been on 'freenode' since before '96 then it's probably not you :) [22:57] cj, hm I've been called MacSlow for as long as I can remember [22:57] '96 could be [22:58] MacSlow: your name sounds familiar :) [22:59] http://web.archive.org/web/19961109144913/http://www.linpeople.org/ [23:33] Hardy's gnome-icon-themes no longer builds from source in Hardy [23:33] icon-naming-utils (>= 0.8.7) but it is not installable [23:34] Hardy only has 0.8.6 [23:34] How it ever got compiled is a mystery to me [23:40] checking for intltool >= 0.40.0... 0.37.1 found [23:40] wtf [23:46] I'm a moron :P [23:46] nvm :) [23:46] * cody-somerville was trying to compile the intrepid version under hardy. [23:59] haha