[01:27] bryceh: btw - 803012 [01:27] bug 803012 [01:27] Launchpad bug 803012 in xserver-xorg-video-intel "Intel driver incorrectly renders some UI elements" [Medium,Fix released] https://launchpad.net/bugs/803012 [01:27] bryceh: I just saw the same symptoms on my natty nvidia machine [01:27] bryceh: dunno what that means. [01:34] lifeless: Presumably with nouveau? [01:35] RAOF: nup [01:35] proprietary foo [01:37] That's almost certainly a different bug, then? [01:37] dunno [01:37] same symptoms [01:37] wondering if its a userspace issue at heart (classic mode fail?) [01:38] lifeless, so little X code is shared between -nvidia and anything else that if it is the same bug, that points to perhaps something non-X/non-kernel involved [01:39] lifeless, X bugs frustratingly often show identical symptoms on two different drivers but are ultimately very different bugs underneath [01:39] lifeless, probably the right thing to do would be to test oneiric (or a backport of this -intel fix). That would be more definitive. [01:40] k [01:40] hows oneiric fs stability atm ? [01:40] the /run bugs from last week were fairly bad, but that should be solved now [01:46] I haven't hit any fs bugs (barring the /run amazement). AFAIK the ecryptfs bug is gone. [01:48] I put the patch in for natty sru as well, so if you don't want to upgrade yet, should be available in natty-proposed whenever the buildd's are done [03:11] bryceh and RAOF ... saw x come down today and I decided to be brave. so far no problems...anything I should be looking for? [03:12] and RAOF, I've been using nouveau ever since the rally...no problems to mention... [03:12] jasoncwarner_: Not really; that was just the xorg metapackage. [03:12] jasoncwarner_: Cool. [03:13] RAOF nouveau was such a non-issue I forgot I was using it ;) [03:14] The xorg package updated fine? It didn't hit a file conflict in xorg-server? [03:16] RAOF: no, everything seemed to go just fine..rebooted and everything...though now I hvae to reboot because I wanted to test nvidia driver again... [03:16] be back [03:17] I wonder if that makes my local problem self inflicted :) [03:25] * RAOF heads off for a run and lunch. [04:33] RAOF: hrm seems I got the conflict when updating a chroot here. [04:33] RAOF: trying to overwrite '/usr/share/doc/xorg', which is also in package xserver-xorg 1:7.6+7ubuntu2 [04:45] Good morning [04:51] hi, could I have someone look at https://code.launchpad.net/~jbicha/ubuntu/oneiric/transmission/transmission-2.32/+merge/67772 [04:59] jbicha: ah, can do [05:00] jbicha: hm, current source package's Vcs-Bzr: says that it uses lp:ubuntu/transmission, not the old ubuntu-desktop branch any more [05:01] but *shrug*, as long as that one is up to date.. the ubuntu:transmission one will be auto-updated [05:02] jbicha: no, lp:~ubuntu-desktop/transmission/ubuntu is outdated, it's for maverick [05:03] pitti: oh, then I think there might be changes I've missed then [05:04] I can't remove the old ubuntu-desktop branch unfortunately [05:04] pitti: hmm? [05:05] so I should rebranch off ubuntu:transmission, right? [05:06] the ubuntu-desktop branches are more convenient, except that Launchpad doesn't expect them [05:06] good morning [05:07] didrocks: howdy [05:07] Morning didrocks [05:07] hey jbicha, RAOF! [05:07] Morning pitti, didrocks. [05:07] jbicha: right [05:08] morning TheMuso [05:08] hey didrocks [05:08] guten morgen pitti :) [05:08] jbicha: sorry for the wasted time :/ [05:08] hey TheMuso, how are you? [05:14] pitti: Not too bad thanks, yourself? [05:15] pretty good, thanks [05:27] hey, there's a bug with the xorg metapackage [05:27] looks like the version we got from debian does some symlinking magic which breaks when it gets updated [05:28] https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/812665 [05:28] Ubuntu bug 812665 in xorg "package xorg 1:7.6 7ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/doc/xorg', which is also in package xserver-xorg 1:7.6 7ubuntu2" [Undecided,New] [05:54] session restart, brb [05:56] pitti: bug 812665 looks to be a result of the documentation-linker having a namespace clash. [05:56] Launchpad bug 812665 in xorg "package xorg 1:7.6 7ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/doc/xorg', which is also in package xserver-xorg 1:7.6 7ubuntu2" [Undecided,New] https://launchpad.net/bugs/812665 [05:57] The xserver-xorg now ships the documentation in /usr/share/doc/xorg, but the auto-linker has kindly symlinked /usr/share/doc/xorg (in the xorg package) to x11-common. [05:57] With hilarious consequences! [05:58] uh, eww indeed [05:59] RAOF: but we never symlink entire directories [05:59] is that something the xorg package does itself? [05:59] because dpkg handles directories specially, pkgbinarymangler only symlinks individual files [05:59] lrwxrwxrwx 1 root root 10 2011-03-03 18:16 /usr/share/doc/xorg -> x11-common [05:59] this isn't pkgbinarymangler's doing [06:02] Ah, ok. [06:03] So now I get to work out what *is* symlinking that directory! [06:04] Oh, my. [06:06] RAOF: I get teh symlink when building locally without any mangling [06:06] Yeah, it's some crazy-arse preinst magic. [06:06] RAOF: how about this: [06:06] for p in $$(dh_listpackages -i -N$$t); do \ [06:06] rm -rf debian/$$p/usr/share/doc/$$p; \ [06:06] ln -s $$t debian/$$p/usr/share/doc/$$p; \ [06:06] Indeed, you have found ite :) [06:06] :) [06:08] Hah. With the even more hilarious consequences that dpkg now thinks /usr/share/doc/xorg actually exists! [06:09] one should avoid shipping directory symlinks like the plage [06:10] platue [06:10] plague [06:10] (gosh) [06:10] at some point they *will* shoot you into the foot [06:10] Because dpkg gets all narky on you. [06:10] Although, to be fair, the problem's not the symlink in this case. The problem is the namespace conflict. [06:10] and you need all sorts of black preinst magic if you ever want to get rid of them again :) [06:10] yes, right [06:11] Preinst magic like “is this a link? If so, rm -rf it.”? :) [06:11] "rm" should be enough, but yes [06:11] and checking that it points to the right place, handling aborted package upgrades and put it back then, etc. [06:12] Yeah. xorg doesn't do any of that pansy sanity checking. [06:12] but I'm not suggesting to actually remove the link now [06:12] If someone's stupid enough to symlink /usr/share/doc/xorg to /, they deserve all they get! [06:12] I guess it's easiest to just drop the duplicate file? [06:12] That's what it does *right now* [06:16] Hm. That doesn't seem to have come from debian. Are we dancing the ‘I hope you haven't symlinked /usr/share/doc/{x11-common,xorg,xserver-xorg} anywhere you care about’ fandango in Ubuntu diff? [06:16] I think we can safely assume that the user didn't tamper with these links [06:17] /usr/share/doc/ must have the property that users can rm -rf it entirely without anything breaking [06:17] Yeah. It'd suck to have accidentally replaced a symlink in there at some point in the distant past, though. [06:18] Ah, yes. This *is* Ubuntu diff. In fact, it's an oldschool pre-pkgbinarymangler symlink-the-docs hack. [06:18] ah [06:18] From brave-old 2007 [06:19] When men were real men, and symlinking doc directories was real men's work. :) [06:19] so either we do the preinst bits of removing the links and drop all the manual symlinking [06:19] lol [06:19] and let the mangler figure it out [06:19] I'm super-inclined to let pkgbinarymangler take this problem off my hands. [06:19] erm, no either [06:20] we can't ship the same symlink in two packages, period [06:20] RAOF: my gut feeling is "drop all this, remove all symlinks in preinst, and drop the preinst bits after the next LTS" [06:21] That's what I'm thinking, too. [06:43] is it safe for me to remove .pc, drop in the new upstream source, and then quilt push the patches I want? [06:44] jbicha: depends if you have applications/libraries dependending on your .pc file [06:45] I'm working on transmission and I've not done much with .pc stuff [06:45] I tried quilt pop but it said it couldn't remove cleanly [06:46] jbicha: don't just remove .pc [06:46] jbicha: I suggest theh following: [06:46] check out ubuntu:pkgname [06:46] quilt pop -a [06:46] and then rm -r .pc (which should now be empty) [06:46] you can commit that as "unapply patches" [06:47] applied patches in bzr are excruciatingly hard to maintain, and against common practice IMHO [06:47] so in my branches I don't apply them [06:47] (they also break merge-upstream) [06:48] well I had like 200 something conflicts when I tried to merge with the Debian bzr [06:48] what if quilt pop complains about not being able to remove cleanly? [06:50] mvo: hey, how are you? [06:50] is quilt pop -a -f ok? [06:50] -f fixes everything! [06:51] jbicha: if quilt pop -a in a cleanly checked out tree doesn't work, then something has gone seriously wrong :( [06:51] jbicha: did you try this _after_ merging with debian? [06:52] * didrocks looks for a wiki page to show jbicha quilt best practices [06:52] well I did bzr revert and I hadn't made any commits [06:52] but I'll do a bzr branch again to make sure [06:52] jbicha: if it gets too complicated, just use apt-get source and merge the old way with diffing debian/ .. [06:53] pitti: well quilt pop -a -f worked, I just didn't know if it was a good idea [06:53] I don't know either [06:54] if the patches don't apply, they need to be fixed either way [06:54] but then the bzr branch is horribly inconsistent, as in this case you couldn't even have built the source package for uploading [06:54] pitti: I guess something has gone seriously wrong :-) [06:54] jbicha: if you like to read some documentation to understand how quilt works, you can have a look there, it seems quite nice: http://www.shakthimaan.com/downloads/glv/quilt-tutorial/quilt-doc.pdf [06:55] didrocks: hey, good morning [06:56] pitti: but all I really need to do is to get a clean source tree, it doesn't matter whether I use quilt pop or do it manually, right? [06:56] jbicha: right, but how do you get it if the patches don't unapply? [06:57] just plopping in the source & removing .pc :-) [07:19] Morning all! [07:25] hey Sweetshark [07:30] good morning everyone [07:31] * bryceh waves === tkamppeter_ is now known as tkamppeter [07:32] hey chrisccoulson! good evening bryceh [07:33] heya didrocks [07:33] Hey hey chrisccoulson! [07:34] hi RAOF and didrocks, how are you? [07:34] chrisccoulson: I'm fine thanks! Yourself? [07:35] didrocks, yeah, good thanks, but a bit tired [07:39] hey chrisccoulson [07:39] morning bryceh [07:39] I'm pretty good. Going for a run before lunch has offset the 7:30 start :) [07:40] hi pitti, how are you? [07:40] hi pitti [07:41] chrisccoulson: I'm great, thanks! [08:04] jibel: hey, FYI, with the new compiz, I tagged the regression to 0.9.5.0: https://bugs.launchpad.net/ubuntu/+source/compiz/+bugs?field.tag=0.9.5.0 [08:10] didrocks: can you please fix "achuni" in https://launchpad.net/ubuntu/+spec/desktop-o-oneconf? [08:10] pitti: ok, should have mispelled the launchpad name, taking a look in a sec [08:16] hey [08:16] bonjour seb128 [08:16] hey pitti, how are you? [08:16] I'm fine, thanks! how about yourself? [08:17] pitti, I'm fine thanks, a bit tired, got used to go late to bed and I have difficulties to get started in the mornings ;-) [08:18] hey seb128 [08:19] didrocks, hey, nothing like a compiz abi break to start the day? ;-) [08:19] seb128: exactly! Where is the fun otherwise? :-) [08:23] pitti: round 2 https://code.launchpad.net/~jbicha/ubuntu/oneiric/transmission/transmission-2.32/+merge/68347 [08:24] jbicha: did I mention that I hate UDD branches? :-) [08:25] morning [08:25] hey rodrigo_ [08:26] pitti: I was going to do it as a ~ubuntu-desktop branch... ;-) [08:27] hey seb128, how are you? [08:27] actually the end result was the same except for the changelog entries & dropping a lot of upstreamed patches [08:29] chrisccoulson, hey, I'm starting being awake and I think I'm good thanks, how are you? [08:29] seb128, pretty much the same, but i feel less awake ;) [08:30] you know what you need right... [08:30] coffee!!! [08:31] heh :-) [08:31] and bacon! [08:31] jono: ^ [08:31] lol [08:31] ;-) [08:32] I wouldn't have done it if he was around don't worry ;-) [08:32] you didn't get breakfast yet? you should start with that ;-) [08:32] rules 1- get breakfast before starting IRC [08:32] or you might still be typing on IRC an hour later without coffee and starving [08:33] heh [08:37] an IRC diet? [08:39] seb128: btw, my server down while at Dublin was due to the power supply which died… [08:42] didrocks, oh ok [08:44] pitti, thanks for doing desktop sponsoring! ;-) [08:44] no worries :) [08:47] pitti: thank you [08:47] jbicha: thanks to you! [08:47] morning [08:48] salut huats [08:48] salut didrocks [08:51] lut huats [08:51] salut seb128 [09:16] man, this g-o-a package doesn't want to build [09:20] pitti: looks like transmission needs a mir for libminiupnpc and libnatpmp [09:21] rodrigo_, need help with it? [09:26] extra mirs again... [09:30] jbicha, do you know if those are optional or mandatory depends? [09:30] jbicha, is there any chance you would like to write the mirs for those? ;-) [09:32] seb128: those libs are actually in the transmission tarball & Debian is using a patch to override them with distro-maintained versions [09:32] yeah, security team doesn't like much bundled copy of system libraries [09:32] and I can write the mirs probably tomorrow [09:32] it means you have to track and fix all copies when there is an issue, which doesn't really make sense [09:32] jbicha, thanks! [09:33] jbicha, no hurry for those, but we better use the system libs if we can [09:33] seb128, the security team must hate me then ;) [09:34] ups [09:35] don't ctrl-W in xchat :p [09:35] lol [09:35] they probably hate all the web browsers maintainers indeed [09:35] heh :) [09:35] security team is just a bunch of haters :p [09:36] but still we are glad to have them ;-) [09:38] g'ah, i wish that linking thunderbird wasn't so painful [09:39] my machine just grinds to a halt every time [09:39] i need more RAM :) [09:43] seb128, yeah, will probably push for a review, as I don't know what's making it fail [09:43] rodrigo_, ok [09:44] seb128, I'll try a little bit more 1st, as the error it is showing is supposed to be fixed with the patch I added, so not sure what's wrong really [09:44] rodrigo_, ok, but feel free to push, I can have a glance maybe I spot something [09:44] seb128, ok [09:46] seb128, lp:~rodrigo-moya/gnome-online-accounts/3_1_1_release [09:47] seb128, it gives an error about undefined symbols, which all are in libgoa-1.0.la, that's why I add the 01_git... patch [09:48] rodrigo_, your rules doesn't use autoreconf.mk [09:48] rodrigo_, so the patch will be useless, you need to run automake to update the makefile.in [09:48] hmm, does it need to if you don't patch configure.ac? [09:49] rodrigo_, well, you patch makefile.am [09:49] you need a makefile.am->makefile.in [09:49] which is automake [09:49] ok, trying... [09:50] rodrigo_, yeah, builds fine with it [09:51] seb128, ok, that was it :) [09:51] ok then, I thought autoreconf was only needed if you patched configure, but I understand it better now :) [09:51] seb128, thanks! [09:51] rodrigo_, yw [09:52] rodrigo_, usually autoreconf is useful if you patch any configure.in,ac or makefile.am [09:52] it does run autoconf, automake, aclocal, etc [09:52] right, makes sense [09:52] ./configure && make use configure and makefile.in [09:53] the other option is to patch the makefile.in in your patch [09:53] but usually those are less fun since the makefile.in is autogenerated it's likely that the patch will be less trivial and not apply to new versions [09:54] rodrigo_, your changelog version needs a revision [09:55] seb128, ok [09:59] jbicha: or disable upnp? [10:00] pitti: I haven't looked to see what those libraries do, but isn't UPNP important for torrents working across NAT? [10:01] jbicha: ah, so the previous version used the internal libs, but already had the functinoality? [10:01] that would make the MIRs easier [10:06] mvo, meet bschaefer, he's the awesome dude that has added CJK support to xapian (or is adding), he has some questions for Software Centre [10:08] mvo: Hello, my question is that it looks like the software center uses the term generator along with the parse query, but does it use the same libxapian as unity-place-applications? [10:10] bschaefer: hello! yes it does use the same libxapian, but its using the python bindings when unity-places-application is using the c++ lib [10:10] bschaefer: should not make a difference though of course [10:10] bschaefer: hello btw :) [10:10] bschaefer: I'm just leaving for lunch, I will be back in ~45min or so [10:11] mv: Alright I might have to email you then, as it is late here haha, ( -8 PST ) [10:11] mvo:* [10:12] * mvo nods and vanishes [10:13] (the xapian testsuite is huge) [10:14] didrocks: only the xapian-core matters [10:14] bschaefer: right, but the package runs everything :-) [10:15] didrocks: yeah I never liked compiling it at first haha, but it seems error free so far :) [10:16] re [10:16] bah, new compiz is really slow to display things [10:16] wb seb128 [10:17] seb128: ah, it's not only me swapping then [10:17] like my session takes 15 seconds to get a background when it was taking 3 seconds before [10:17] I restarted several times thinking it was stucked [10:17] never get any stuck session, but I have the impression that compiz is slower, yeah [10:17] opening anything display a dialog with wrong geometry and no decoration for 2-3 seconds [10:17] then it gets updated as it should [10:18] 12:17:43 seb128 | opening anything display a dialog with wrong geometry and no decoration for 2-3 seconds [10:18] happens for anything, apport dialog, gedit, nautilus [10:18] -> half a second here, I reported it [10:18] well here it's 2-3 seconds on a modern i5 box [10:18] seb128: want to confirm bug #812711 ? [10:18] Launchpad bug 812711 in compiz "Some dialogs jumps before appearing" [Undecided,New] https://launchpad.net/bugs/812711 [10:18] but using intel, I guess video matters over cpu for that issue [10:18] seb128: see, for once, my box is better than yours :) [10:20] didrocks, done [10:20] thanks :) [10:20] 2-3s is scary though [10:21] do you want to file one with the general slowiness? [10:21] didrocks, I've updated the title and raised the setting [10:22] didrocks, it's not slow otherwise, like workspace switch etc have no issue [10:22] seb128: looks good [10:22] hum, the slowliness at startup you get? [10:22] I just think something is resources expensive in the mapping and where a dialog takes 3 seconds the background takes 15 seconds [10:22] well imho it's the same issue [10:22] but there is no dialog at session login? [10:22] just proportional to how much there is to render [10:23] no, but it's not specific to dialogs [10:23] hum, that will do it with the wall window otherwise [10:23] which doesn't seem to be the case [10:23] well, let's wait for smspillaz to comment, if he thinks it's a different issue I will open a new bug [10:23] or DBO [10:23] as you wish :) [10:24] seb128: we stopped adding unity master tag btw [10:24] but I think the background is just a nautilus ui element and getting the same issue [10:24] maybe, anyway, windows are slow to drag in the expo mode as well [10:24] didrocks, oh ok, well I don't do it in a systematic way, I just want a bug showing up on unity lists [10:25] seb128: I added the 0.9.5.0 tag on compiz bugs for all regression from this upgrade [10:25] ok [10:25] should be easy to find them back [10:25] https://bugs.launchpad.net/ubuntu/+source/compiz/+bugs?field.tag=0.9.5.0 (current list) [10:26] ok [10:27] is there a spec describing the unity dialog behaviour somewhere? [10:27] like what should happen in the file-selector too small to be used case [10:27] seb128: nothing from what I know, I just saw some screenshots and I would like to know for that case as well [10:27] I filed bug #812712 for that one so that we don't loose this issue [10:28] Launchpad bug 812712 in compiz "Can't get normal modal dialog size" [Undecided,New] https://launchpad.net/bugs/812712 [10:29] right, I noticed [10:29] the issue is not new with 0.9.5 though [10:29] well maybe the fixed size is new [10:29] no, see my comment :) [10:29] but opening the dialog is a too small to be used geometry is buggy and was already buggy in the previous version [10:29] is->in [10:30] "This isn't linked to 0.9.5.0 properly, but from the new unity dialog, just keeping it there to see if a solution is possible" [10:30] but I didn't find a spec say if the unity dialog should go out of the container in those case [10:30] or if the geometry should get updated [10:30] as this is part 2 of unity dialogs (the u-w-d side), I think it's fine to track it there [10:30] anyway, the current behavior is buggy, and we need design feedback [10:31] didrocks, it's sort of bug #805975 [10:31] Launchpad bug 805975 in unity "Modal dialog size too small if it belongs to other modal window" [Undecided,New] https://launchpad.net/bugs/805975 [10:31] yeah, same issue in nested dialogs, not sure it should be fixed the same way, pointing to it on the bug report [10:32] done [10:32] thanks [10:32] thanks for finding the ref :) [10:37] bschaefer: some test failed. Trying without the patches to ensure it's the cause of the issues [10:38] tests* [10:42] didrocks: hmm, which ones failed? [10:43] bschaefer: Running test: flintdatabaseformaterror3... FAILED [10:44] in apitest [10:44] bschaefer: but let me confirm first it's the patch creating an artifact in the API there [10:44] Yeah I went to straight to testing on dash I am running them right now. I knew I was forgetting something.. [10:44] will be long, the testsuite is long :-) [10:44] yeah haha [10:45] bah [10:46] smspillaz, didrocks: u-w-d segfaulted [10:46] #0 0x0805cabf in remove_frame_window () [10:46] No symbol table info available. [10:46] #1 0x0805cde7 in window_closed () [10:46] seb128: I won my personal bet! I was sure you will get a crash within a day :) [10:47] didrocks, :) [10:49] will open the bug with a debug stacktrace [10:49] but after lunch [10:49] bbl [10:49] seb128: enjoy [10:56] didrocks: well I am going to let this run, I am pretty tired right now so I cant help much anyway. If you could send me email about any other fails I will spend tomorrow trying to fix it [10:57] didrocks: @ brandontschaefer@gmail.com [10:57] bschaefer: sure, will do! Thanks again for your work there! Have a good night :-) [10:58] didrocks: You too, and hopefully everything works out haha. [10:59] bschaefer: let's hope so :) [11:09] oh, new decorator segfault [11:10] seb128, oh, i just realized that i can turn off gconf support in firefox at build time already [11:10] http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/925 [11:10] :-) [11:10] chrisccoulson, \o/ [11:10] chrisccoulson, what about gnomevfs? ;-) [11:10] oh, in the same commit [11:10] seb128, i turned that off last cycle ;) [11:11] seb128: no decorator segfault? [11:11] oh new* [11:11] * didrocks will soon buy glasses [11:11] didrocks, yeah, it did it again [11:11] seb128: oh do you get it? [11:12] didrocks, yes, the stacktrace before was from me already [11:12] got it twice since I upgraded [11:12] is there any special way for you to trigger it or it's just random? [11:12] didrocks, but I learn something on the way [11:13] starting unity-window-decorator makes compiz hang for quite some seconds [11:13] so maybe the slowness issue is a decorator one [11:13] seb128: yeah, more than possible as it's all linked to the unity dialog part 2 [11:14] seb128: can you try with gtk-w-d ? [11:14] just to ensure [11:14] didrocks, rather random but not totally, I got it first on an apport dialog autoopening and now when doing send&receive in evolution [11:14] so maybe it has to do with dialogs autoopening or focus stealing prevention or something, will try to figure if I find a reliable way to trigger it [11:15] seb128, ok, I think g-o-a is now ready for a review, so feel free to look at lp:~rodrigo-moya/gnome-online-accounts/3_1_1_release [11:15] I'll do some g-c-c building with it in the mean time [11:15] hum, interesting :) [11:15] didrocks, g-w-d doesn't hang compiz for a while [11:15] and compiz seems snappier again [11:15] so yeah, I bet it's unity dialog's updat [11:15] e [11:15] rodrigo_, ok, looking [11:15] ok, will make sense, the core didn't change that much otherwise [11:16] great, I will keep the gtk decorator for now ;-) [11:16] seb128: come on, come to play the slow game! :-) [11:17] * didrocks tries to build xapian in a pbuiler just in case… [11:17] is that a drinking game? ;-) [11:17] I fear it's not that fun :) [11:17]