=== hggdh is now known as hggdh|away === bluesmoke_ is now known as Amaranth === hyperair is now known as asylum_personnel === asylum_personnel is now known as hyperair [07:42] Good morning [07:55] Guten Tag pitti :) [10:07] hmm there seems to be a race condition between the panel appearing and notify-osd [10:08] if notify-osd gets started before the panel gets to load, then notify-osd covers the panel [10:08] otherwise it's fine. [10:08] bug #332094 [10:08] Launchpad bug 332094 in notify-osd "Jaunty: notifications overlap top panel " [Undecided,Confirmed] https://launchpad.net/bugs/332094 [10:08] hi seb128 & hyperair [10:08] lut didrocks [10:08] didrocks: hello [10:09] didrocks: congrats on your first official upload ;-) [10:09] seb128: you spy at me? :) [10:10] didrocks: not only at you don't worry ;-) [10:10] ^^ [10:11] seb128: I have a question on gnome-python... well, as there is a new python version, how to manage concurrent version? as there is one which need /usr/lib/python*/dist-packages and the other one site-packages. Do I only depends on say, 2.6? [10:13] didrocks: no clue about python, ask on #ubuntu-devel [10:13] or rather no clue about the new python policy specifics [10:13] ok, I will ask to doko, IIRC [10:13] good idea [10:13] and see with him if all gnome-python* packages needs to be updated [10:14] seb128: btw, when you will have time, mvo told me he hadn't the time to sponsor nautilus-sendto [10:14] didrocks: I think he's just on holidays today, I will let it for him on monday there is no hurry [10:15] brb, trying to remove an xorg workaround [10:27] seb128: perfect. And when you will have time, remember that there is this horrible merge + update on gnome-python-extras that stuck me :) [10:28] didrocks: what is perfect? how are you stucked on this one? [10:28] seb128: perfect regarding the last sentence (waiting for mvo has there is no hurry ;)) [10:28] ah ok [10:28] seb128: do ou remember the missing doc thing? [10:29] you* [10:29] oh that [10:29] did you contact upstream about having htmls in the tarball? ;-) [10:29] you ask me and I posted the diff file somewhere [10:29] because I first can't workaround it, the issue may be something else [10:29] (before contacting upstream) [10:30] right, it slipped from my todolist [10:30] where is the dsc now? ;-) [10:31] seb128: http://www.didrocks.fr/temp/gnome-python-extras_2.25.3-0ubuntu1.dsc [10:31] well, if the html are not in the tarball you should bug upstream anyway since that's a bug [10:31] a temp file not really temporary is always useful :) [10:31] seb128: of course. I just want a confirmation first :) [10:32] seb128, about games on linux I would suggest you World of goo -> http://2dboy.com/games.php [10:32] :) [10:33] some people were playing it during the bug jam (O_o). Seems to be a very good game :) [10:33] didrocks: you didn't add the --enable-gtk-doc to the configure option ... [10:34] seb128: I tested that and it's not working. I reverted it just before providing you the .dsc (ok, 10 days before, hard for you to remember this ^^) [10:40] remember also that I deliberatly keep the update in 3 steps in the changelog for easier understanding of what has been done. That needs to be merged for final upload [10:41] didrocks: I'm not reviewing that today just looking at your build issue [10:41] seb128: ok, thanks :) [10:52] didrocks: not sure how to fix it, --enable-docs make the html being built but it breaks on "unable to parse" errors [10:53] didrocks: you should really ask upstream to build and include the htmls [10:56] didrocks: you can comment the api documentation installation for now [10:59] ok, lunch time [10:59] bbl [10:59] lool: did you encounter the alt+paste issue again after taking the browser.jar? [10:59] seb128: you mean python-gnome2-extras-doc.install ? [10:59] FAIL :) [10:59] seb128: you mean python-gnome2-extras-doc.install ? [10:59] didrocks: what FAIL? [10:59] didrocks: whatever is installing those you should be able to figure no? ;-) [11:00] seb128: you had quit when I posted my last sentence :) [11:00] I think that's the .install, I close the directory now and I've to go [11:00] closed [11:00] could be the rules that depends of packages [11:00] anyway really going now, be back in an hour or so [11:00] ok, will test this :) [11:00] I just restarted to reply to a comment [11:00] have a good lunch! [11:00] thanks, you too! [11:15] asac: I couldn't reproduce on my amd64, but it's a regular mouse and doesn't have the emulate3rdbutton thing, I'll try on my laptop ASAP; just need to reboot it [11:19] lool: ok. === hggdh|away is now known as hggdh [13:17] MacSlow: ping [13:19] kenvandine[work], what's up? [13:20] hey, which bug is it for metacity+compositing problem? [13:20] i have a box here that is working fine... [13:21] kenvandine[work], test once more :) [13:21] it has been fine for a week :) [13:21] kenvandine[work], it's non-deterministic [13:22] kenvandine[work], switch metacity's compositor on and off while some bubbles are being displayed [13:22] but... the one that has been fine isn't jaunty... it is my foresight laptop with metacity 2.24... i was wondering if maybe a metacity bug has cropped up instead of notify-osd regression [13:22] ok [13:22] kenvandine[work], e.g. use the script from notify-osd/src/send-test-notifications.sh [13:23] MacSlow: seems fine [13:23] turned it off and on 4 times [13:24] 12 times... all good [13:26] kenvandine[work], are you running notify-osd trunk or the package from the jaunty repo? [13:26] neither [13:26] ? [13:27] this isn't on ubuntu [13:27] on foresight [13:27] kenvandine[work], so it is trunk? [13:27] kenvandine[work], you did "bzr co lp:notify-osd" at some point? [13:28] [13:28] https://edge.launchpad.net/ubuntu/jaunty/+source/notify-osd/0.8-0ubuntu4/+files/notify-osd_0.8-0ubuntu4.tar.gz [13:28] from that tarball [13:30] kenvandine, I'm working on more rendering code before the code drop in 90 min. I'll look into that after I build the PPA for today [13:30] sure [13:30] just hoping to help narrow the scope :) [13:40] hey kenvandine[work] [13:40] hey pitti [13:40] hello guys [13:41] hey seb128! [13:41] kenvandine[work]: hello [13:41] kenvandine[work]: you should really change your nickname to not have [] chars [13:41] does that bug you? [13:42] that's really annoying to type on some kayboard layouts where you need to use modifiers for those chars ;-) [13:42] ah [13:42] well let's say I will stop using your nickname soon [13:42] :) [13:42] having to use a modifier to enter a nickname is extra work I'm too lazy to do often ;-) === kenvandine[work] is now known as kenvandine2 [13:42] thanks [13:42] or _work would work too ;-) === kenvandine2 is now known as kenvandine_wk [13:43] and yeah, stupid french layout ;-) [13:43] :) [13:43] i never understood why anyone would append [work] [13:43] ;) [13:43] asac: you are working all the time that's why ;-) [13:43] probably ;) [13:43] i guess my name is an array [13:43] :) [13:44] kenvandine_wk: did you have patches pending upload, ie the evolution notification change? in which case it would be nice to subscribe ubuntu-main-sponsors to the bug === asac is now known as asac_drinking_co === asac_drinking_co is now known as asac [13:44] too bad [13:44] lol [13:44] keepnick didnt allow me to change my nick ;) [13:44] seb128: yeah... i will do that [13:44] kenvandine_wk: we tend to use http://people.ubuntu.com/~dholbach/sponsoring/index.html to review things waiting so if you don't subscribe the sponsors it's easy to overlook those [13:45] ok, thx [13:45] yeah ... and only subscribing sponsors will give credit to the sponsor and help him get up on hall-of-fame [13:45] ;) [13:46] kenvandine_wk: are you very busy ATM? if not, do you feel up to a little packaging training today? [13:46] kenvandine_wk: how busy are you next week? ;-) [13:46] pitti: i wanted to talk to you about that... [13:46] seb128: depends on the uif stuff [13:46] i think i have time to help with stuff [13:46] kenvandine_wk: GNOME 2.25.92 scheduled for next week, you can have some easy (or not) updates assigned to you if you want [13:47] kenvandine_wk: ok, we tend to assign work there so just ask if you feel like doing some updates [13:47] seb128: i would love to help with that [13:48] will there be bugs created for each package? how do we manage that? [13:48] kenvandine_wk: we have no tarball yet and we tend to assign those when people are around and ask according the list of things not updated yet so just ask when you are around and we will have some updates for you ;-) [13:49] kenvandine_wk: we suck at it right now, I keep track of the list and distribute work but we are thinking about a better workflow for a while and I want to do that this cycle [13:49] ie having a list of all packages, series to watch, usual updates if there is any (to not hijack those) [13:49] and then let people claim free updates by some way [13:50] updates- > updaters [13:50] i would that that wouldn't be hard to do in LP [13:50] so we would have "pitti is usually looking at gnome-mount so ping him before uploading but gconf-editor is free to claim by whoever wants to update it" [13:50] probably not [13:51] we should have usually updaters and "claim so work" lists in bzr somewhere [13:51] and then we just need a webspace to host a page and a cron job updating it [13:52] i am surprised it isn't all scripted :) [13:52] seb128: in foresight land, we have a script called speedbump [13:52] that bumps all of foresight [13:52] all of gnome rather [13:53] I don't want automatic update [13:53] the recent gtk update make gdm crash for people who had non-xrandr-friendly drivers for example [13:53] we do it in a devel branch, so it doesn't break peopel [13:54] and detecting abi or api changes or soname changes and updating the packaging automatically is not trivial [13:54] as is not detecting new files to install in binaries [13:54] ie many case where thing could go wrongly [13:54] or build-depends changes [13:54] ie new requirements in the configure [13:54] seb128: you could integrate this into norsetto's script? [13:54] we could automate some of those but that's non-trivial [13:55] Laney: right, the webpage he worked on is a good start [13:56] seb128: true... i guess that is easier for foresight, with conary [13:56] we can do diffs after the build for dep changes... etc [13:56] which is SO handy [13:57] kenvandine_wk: deps are not an issue it's using ldd calls and rdepends [13:57] kenvandine_wk: the issue is to know what to install to build [13:57] oh... dpkg takes a list of files to install? [13:57] kenvandine_wk: you can try to parse PKG_ calls in the configure but that's not the only way to claim requirements and some are conditional to some options [13:58] kenvandine_wk: yes, that's why you have {Depends:shlibs] usually in the control [13:58] kenvandine_wk: that basically do a ldd and look to what package shilbs all those libs after build [13:58] shlibs- > ships [13:59] that's only for C though [13:59] we don't have a similar system for python for example [13:59] and build-depends are still manually specified since automatically parsing configure requirement is not easy [14:00] especially as said that the requirements can depend on the build option [14:00] yeah, that part is hard [14:00] for buildReqs [14:00] does conary manage to automate those? [14:01] shlibs also does some magic for finding good lower bounds for the depends ;) [14:02] seb128: mostly [14:02] seb128: about 90% [14:03] seb128: what's useful though is doing a diff on the deps after the build [14:03] so comparing libgnome=2.24.1 to libgnome=2.24.2 [14:03] you can do a diff and see what deps changed, which can be very enlightening :) [14:04] kenvandine_wk: we dont do strict versioning [14:04] yeah... conary is very strict [14:04] kenvandine_wk: debian does depends automatically and you can debdiff binaries too [14:04] sounds stale ;) [14:04] well... conary do no versioned deps [14:04] soname deps [14:04] etc [14:05] how do you assure that the required version is installed then? [14:05] so it doesnt care about versions at all? [14:06] if the soname is satisfied [14:06] one package provides soname: ELF32/libgobject-2.0.so.0(SysV x86) [14:06] another one requires soname: ELF32/libgobject-2.0.so.0(SysV x86) [14:06] kenvandine_wk: the source has no knowledge of the soname required [14:06] it's satisfied [14:07] the configure depends on a version [14:07] and the source use symbols [14:07] but the soname doesn't matter there [14:07] sure, pkgconfig, etc [14:07] no [14:07] pkgconfig has no soname clue [14:07] the soname is a pure libtool thing [14:07] no, but version needs [14:07] yes [14:07] conary doesn't do that for you before you build it [14:08] well, it can't guess [14:08] that's not because you use a version to build that previous version would be enough [14:08] kenvandine_wk: adding new symbols without breaking ABI/API will not bump the major soname version [14:08] yeah, so then you get a failure and have to look at the logs [14:08] so you can have binaries build that require a new minor version [14:10] objdump -x /usr/lib/libglib-2.0.so | grep SONA SONAME libglib-2.0.so.0 [14:11] i think the SONAME has been stable for long time ... even though new symbols where added [14:11] you need SONAME + minimum version to get accurate depends [14:12] in fact the debian system is quite clever [14:12] I doubt conary does much better now [14:12] the old one was clever [14:12] the new (symbols) is quite perfect even [14:12] the current debian tools have tracking of what symbols have been added in which version [14:12] so you know exactly what version you need by looking at the symbols you use [14:12] right. my point was just that: [14:12] 15:06 < kenvandine_wk> one package provides soname: ELF32/libgobject-2.0.so.0(SysV x86) [14:13] 15:06 < kenvandine_wk> another one requires soname: ELF32/libgobject-2.0.so.0(SysV x86) [14:13] is flawed ;) [14:13] * asac keeps out of this now ;) [14:14] yeah, I don't want to start a distro troll eithe [14:14] either [14:15] * asac still waiting for a phone number for a call that ws supposed to start 15 minutes ago [14:39] morning all [14:40] ArneGoetje: asac: bryce: calc: kenvandine_wk: pitti: Riddell: did you guys see the new hire announcements from HR today? [14:40] any one notice that addition of a certain tseliot to the list? [14:40] ;) [14:41] * rickspencer3 congratulates tseliot [14:41] rickspencer3: wow... [14:41] hello rickspencer3 [14:41] hey tseliot [14:41] tseliot: congrats ;-) [14:41] thanks :-) [14:41] welcome tseliot [14:41] rickspencer3: i tried to spot someone for our team, but it was a long list ;). seems i missed him [14:42] welcome tseliot [14:42] tseliot: is joining the OEM team [14:42] which will be great for us [14:42] please fix all my X problems :) [14:42] ah ;) [14:42] we'll have an X representative over there [14:42] yes, it's what I'll have to do ;) [14:43] and it'll help the teams work ever more closely in synch [14:43] * pitti hugs tseliot [14:43] rickspencer3: I heard it a few days ago indeed [14:44] yes, some of you knew it in advance [14:45] heh === rickspencer3 is now known as rickspencer3-afk [14:47] It seems that mvo is afk, does anyone know how I can detect whether I've got packages installed that require restart? (kernel, etc.) [14:50] tseliot: congrats :) [14:51] thanks everyone :-) [14:51] tedg, mvo is off today [14:52] crevette: I figured. But I was hoping someone else had an answer. :) [14:52] By away from keyboard, I meant really away. :) [14:55] tedg: you mean detect whether a restart is currently required? [14:55] james_w: Yes. [14:56] tedg: I would assume you have a kernel installed :-) [14:56] tedg: /var/run/reboot-required is the file that is created by packages when an upgrade requires a restart [14:57] james_w: Okay, so if that exists, then someone wants a reboot. Cool, thanks! [14:57] tedg: that's the basics, there may be more to it, such as detecting which packages requested it, but I'm not sure [14:58] james_w: I don't need to know that, so I'm good there :) [14:58] james_w: BTW, while I have you on the line. Why do some packages not exist in package-import? [14:59] Like some have older releases, but not Jaunty. [14:59] Is it just a time thing? [15:00] tedg: they probably crashed the importer [15:00] Also, would it be possible to automate making branches for the patches? Like if I have "01_foo.patch" there'd be "jaunty-upstream" and "jaunty-upstream-01_foo"? [15:00] tedg: if there are specific ones you are interested in I can look at/fix them [15:00] there's around 100 of those packages [15:01] james_w: I don't remember which package it was, but I just noticed it the other day and was curious. [15:01] tedg: yeah, it would be possible. It's not exactly clear how that should work though, so it's a bit out of scope for now [15:02] james_w: Okay, it would just be handy for making patches that are further down the stack. I don't really want to patch upstream, I want to patch upstream+patches. I've just built those branches myself for now. === rickspencer3-afk is now known as rickspencer3 [15:03] * tedg hates patches and especially debdiffs and thinks they should only be used as "compiled" files. [15:13] james_w: BTW, I don't know if I've shown you this -- you might be interested (or more likely I've talked too long as it is) -- but I've done all the FUSA patches as branches and then have a small script to turn them into patches for packaging. It's worked well for me, but the problem I have is that when people post things as debdiffs they're hard to integrate back in. [15:14] tedg: I'd be interested to see it [15:17] james_w: The script is "bzr-patch-build" https://code.launchpad.net/~ted-gould/fast-user-switch-applet/ubuntu-packaging-jaunty [15:19] james_w: Not fancy, it just uses a bunch of json files to describe the branches, and then uses bzr to generate the patches from there. [15:19] heh [15:19] not what I expected to see in there :-) [15:20] Just to be curious, what'd you expect? [15:20] interesting though, thanks a lot [15:20] no idea, just not json :-) [15:20] it makes for a neat description though [15:20] * james_w files that one away in his head for later [15:20] i'm looking into backporting the whole set of the notify-osd functionality to intrepid in my ppa. which package should i be looking at for volume and brightness? [15:21] hyperair: gnome-settings-daemon [15:21] hmm okay [15:21] time to go digging around for patches in there [15:21] and maybe backport just the patch [15:21] hyperair: Yeah, that should be possible. If you have questions, davidbarth may be able to answer them. He wrote the patch. [15:22] cool [15:23] james_w: I don't know, I like json. It's simple and has associative arrays :) But, at my last job I did LOTS of Javascript. (system stuff, not web) [15:24] isn't the brightness g-p-m? [15:24] hyperair: ^ [15:24] james_w: correct, the volume is gsd. [15:25] james_w: aah probably. thanks [15:25] I think the pop-ups in Intrepid for both are in gsd though. [15:25] i wish the bug regarding gsd and media keys not respecting priority would get fixed already though =\ [15:25] i mean SRU'd [15:42] didrocks, Laney: http://revu.ubuntuwire.com/p/evolution-mapi is now advocated if someone has a chance to look [16:10] james_w: I will do it tonight :) [16:11] great, thanks [16:11] james_w: if I advocate it. Then, I sponsor it? [16:11] yeah [16:11] if you ask for changes then advocate the new one [16:12] and I'll look tomorrow if you don't find someone else tonight [16:12] the only issue I see is that the lib package name doesn't match the SONAME, but that's not critical [16:12] ok, I will ping you tomorrow in this case :) [16:12] great [16:12] what about sendto-universe? [16:12] do we want two +1s for that? [16:13] Laney: seb only ask for one [16:13] Laney: so, you can handle it :) [16:13] hot [16:13] Laney: if you want, I can review it as well [16:13] that dependency on nautilus-sendto concerns me [16:13] I think we need to find a way of saying that it must be the same upstream version [16:14] Build-Depends, or Depends? [16:14] depends [16:14] you can do that [16:15] do tell [16:15] substvars [16:15] >= ${source:upstream-version}, << ${...}+ or so? [16:16] UPSTREAM_VERSION="$(dpkg-parsechangelog | sed -n -e '/^Version: /s/^Version: //p')" [16:16] echo $UPSTREAM_VERSION > debian/package.substvars during binary [16:16] err [16:17] source:upstream-version $UPSTREAM_VERSION I mean [16:17] I have to go and see an RMS conference, see you guys :) [16:17] something like that anyway [16:17] I thought that substvar already existed by default [16:17] but how to actually specify the depends? [16:17] then ">= ${source:upstream-version}~, << ${source:upstream-version}~" as you suggest [16:17] with the pacakge names of course [16:18] ah, I didn't think it was there by default [16:18] or you could just do it by hand on each upstream release :-) [16:18] why ~? [16:19] ah, source:Upstream-Version [16:19] so that "2.0~beta1" would satisfy [16:19] you can leave it off either end depending on upstream's policies [16:20] be use ~ in bzr, as 1.13~beta1 will we API in-compatible with 1.12, but will be compatible with 1.13 [16:20] I'll play in a sec [16:20] just going home, brb [16:27] kenvandine_wk: hm, so you want bug 331571 uploaded? [16:27] Launchpad bug 331571 in evolution "disable Mail Notification eplugin by default" [Low,Confirmed] https://launchpad.net/bugs/331571 [16:27] kenvandine: I thought that wouldn't DTRT? [16:28] pitti: i thought we agreed it would... ?? [16:29] kenvandine: ah, so that does just hide the applet, but leaves the plugin running? [16:29] pitti: yes [16:29] hey [16:30] kenvandine: ok, sounds good then [16:30] pitti: it disables the icon in the notification area, but does load the plugin [16:30] ok [16:30] kenvandine: so that won't work with stracciatella-session then [16:30] kenvandine: is it hard to hide the applet based on $GDMSESSION, and leave the gconf key untouched? [16:30] * kenvandine[work] is hoping compiz sucks less on his intel 965 now [16:31] kenvandine[work]: see comment 3 [16:32] certainly a lot more work... have you put much thought into a general way to handle gconf changes from upstream? [16:32] i suspect there are quite a few gconf keys we change [16:32] might be nice to have it load a different set of gconf defaults based on session [16:32] do we? I'm not aware of so many [16:32] i don't know... but i would suspect so [16:32] well, probably not a completely parallel set, but some keys [16:33] so perhaps a generic way of handling that instead of hacking each package [16:33] kenvandine, are you going to propose this fix upstream? [16:33] hggdh: it's not really a fix [16:33] that gconf change is a workaround hack for the indicator applet [16:33] so it wouldn't be suitable upstream [16:33] right [16:33] unless they accept that the indicator applet becomes the new standard, of course [16:34] :) [16:34] maintaining the patch for gconf is probably much easier than a larger patch to the plugin itself [16:35] right, no doubt about that (although the "larger patch" should not be bigger than 5 lines either) [16:35] maybe [16:35] i can look at doing that too [16:35] ok, OK. I thought we were effectively disabling the plugin [16:35] kenvandine[work]: something like http://bazaar.launchpad.net/~ubuntu-core-dev/indicator-applet/ubuntu/revision/135 [16:35] hggdh: no... we don't want to do that [16:36] kenvandine[work]: my concern about patching gconf defaults is that it's (1) not dynamic, and (2) might not even work, if the user has a value set in its gconf tree [16:36] true [16:36] kenvandine[work]: and if we ask $GDMSESSION (which is admittedly an equally hackish thing), we don't have above issues [16:36] and we'd at least use hacks which are consistent :) [16:37] kenvandine[work]: seriously, I dont' think that this $GDMSESSION thing is the final answer to this [16:37] pitti: but... if someone disables the indicator-applet and wants to use the default, we want it to be there too [16:37] but it's unintrusive, and thus can easily be reverted and replaced with a better solution, once we have one [16:37] kenvandine[work]: right [16:37] hacking the gconf key lets the user enable them if they like [16:37] true that [16:38] less likely to piss someone off :) [16:38] kenvandine[work]: but if they do, then it will stay there forever [16:38] i would hate to get a flame about how ubuntu makes decisions for them.. yada yada [16:38] pitti: yes [16:38] so either way it isn't great... [16:38] and we'd land in the very situation I was trying to avoid [16:39] kenvandine[work]: ideally, the upstream applet could check whether indicator-applet is running [16:39] well... upstream evo is easily approachble, and seb and I have a good rapport with them [16:39] pitti: that might be upstreamable [16:39] but a little harder to do in a sane way i think === kenvandine[work] is now known as kenvandine_wk [16:43] kenvandine_wk: oh, btw, it's "indicator-applet running" and "$GDMSESSION != stracciatella" [16:43] bah, 3v1l h4cks [16:43] yeah... i know [16:44] pitti: but i think anything we do will be evil hacks... at least until/if the indicator makes it upstream [16:45]