| === 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 | ||
| pitti | Good morning | 07:42 |
|---|---|---|
| didrocks | Guten Tag pitti :) | 07:55 |
| hyperair | hmm there seems to be a race condition between the panel appearing and notify-osd | 10:07 |
| hyperair | if notify-osd gets started before the panel gets to load, then notify-osd covers the panel | 10:08 |
| hyperair | otherwise it's fine. | 10:08 |
| seb128 | bug #332094 | 10:08 |
| ubottu | Launchpad bug 332094 in notify-osd "Jaunty: notifications overlap top panel " [Undecided,Confirmed] https://launchpad.net/bugs/332094 | 10:08 |
| didrocks | hi seb128 & hyperair | 10:08 |
| seb128 | lut didrocks | 10:08 |
| hyperair | didrocks: hello | 10:08 |
| seb128 | didrocks: congrats on your first official upload ;-) | 10:09 |
| didrocks | seb128: you spy at me? :) | 10:09 |
| seb128 | didrocks: not only at you don't worry ;-) | 10:10 |
| didrocks | ^^ | 10:10 |
| didrocks | 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:11 |
| seb128 | didrocks: no clue about python, ask on #ubuntu-devel | 10:13 |
| seb128 | or rather no clue about the new python policy specifics | 10:13 |
| didrocks | ok, I will ask to doko, IIRC | 10:13 |
| seb128 | good idea | 10:13 |
| didrocks | and see with him if all gnome-python* packages needs to be updated | 10:13 |
| didrocks | seb128: btw, when you will have time, mvo told me he hadn't the time to sponsor nautilus-sendto | 10:14 |
| seb128 | didrocks: I think he's just on holidays today, I will let it for him on monday there is no hurry | 10:14 |
| seb128 | brb, trying to remove an xorg workaround | 10:15 |
| didrocks | seb128: perfect. And when you will have time, remember that there is this horrible merge + update on gnome-python-extras that stuck me :) | 10:27 |
| seb128 | didrocks: what is perfect? how are you stucked on this one? | 10:28 |
| didrocks | seb128: perfect regarding the last sentence (waiting for mvo has there is no hurry ;)) | 10:28 |
| seb128 | ah ok | 10:28 |
| didrocks | seb128: do ou remember the missing doc thing? | 10:28 |
| didrocks | you* | 10:29 |
| seb128 | oh that | 10:29 |
| seb128 | did you contact upstream about having htmls in the tarball? ;-) | 10:29 |
| didrocks | you ask me and I posted the diff file somewhere | 10:29 |
| didrocks | because I first can't workaround it, the issue may be something else | 10:29 |
| didrocks | (before contacting upstream) | 10:29 |
| seb128 | right, it slipped from my todolist | 10:30 |
| seb128 | where is the dsc now? ;-) | 10:30 |
| didrocks | seb128: http://www.didrocks.fr/temp/gnome-python-extras_2.25.3-0ubuntu1.dsc | 10:31 |
| seb128 | well, if the html are not in the tarball you should bug upstream anyway since that's a bug | 10:31 |
| didrocks | a temp file not really temporary is always useful :) | 10:31 |
| didrocks | seb128: of course. I just want a confirmation first :) | 10:31 |
| crevette | seb128, about games on linux I would suggest you World of goo -> http://2dboy.com/games.php | 10:32 |
| crevette | :) | 10:32 |
| didrocks | some people were playing it during the bug jam (O_o). Seems to be a very good game :) | 10:33 |
| seb128 | didrocks: you didn't add the --enable-gtk-doc to the configure option ... | 10:33 |
| didrocks | 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:34 |
| didrocks | 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:40 |
| seb128 | didrocks: I'm not reviewing that today just looking at your build issue | 10:41 |
| didrocks | seb128: ok, thanks :) | 10:41 |
| seb128 | didrocks: not sure how to fix it, --enable-docs make the html being built but it breaks on "unable to parse" errors | 10:52 |
| seb128 | didrocks: you should really ask upstream to build and include the htmls | 10:53 |
| seb128 | didrocks: you can comment the api documentation installation for now | 10:56 |
| seb128 | ok, lunch time | 10:59 |
| seb128 | bbl | 10:59 |
| asac | lool: did you encounter the alt+paste issue again after taking the browser.jar? | 10:59 |
| didrocks | seb128: you mean python-gnome2-extras-doc.install ? | 10:59 |
| didrocks | FAIL :) | 10:59 |
| didrocks | seb128: you mean python-gnome2-extras-doc.install ? | 10:59 |
| seb128 | didrocks: what FAIL? | 10:59 |
| seb128 | didrocks: whatever is installing those you should be able to figure no? ;-) | 10:59 |
| didrocks | seb128: you had quit when I posted my last sentence :) | 11:00 |
| seb128 | I think that's the .install, I close the directory now and I've to go | 11:00 |
| seb128 | closed | 11:00 |
| seb128 | could be the rules that depends of packages | 11:00 |
| seb128 | anyway really going now, be back in an hour or so | 11:00 |
| didrocks | ok, will test this :) | 11:00 |
| seb128 | I just restarted to reply to a comment | 11:00 |
| didrocks | have a good lunch! | 11:00 |
| seb128 | thanks, you too! | 11:00 |
| lool | 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:15 |
| asac | lool: ok. | 11:19 |
| === hggdh|away is now known as hggdh | ||
| kenvandine[work] | MacSlow: ping | 13:17 |
| MacSlow | kenvandine[work], what's up? | 13:19 |
| kenvandine[work] | hey, which bug is it for metacity+compositing problem? | 13:20 |
| kenvandine[work] | i have a box here that is working fine... | 13:20 |
| MacSlow | kenvandine[work], test once more :) | 13:21 |
| kenvandine[work] | it has been fine for a week :) | 13:21 |
| MacSlow | kenvandine[work], it's non-deterministic | 13:21 |
| MacSlow | kenvandine[work], switch metacity's compositor on and off while some bubbles are being displayed | 13:22 |
| kenvandine[work] | 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 |
| kenvandine[work] | ok | 13:22 |
| MacSlow | kenvandine[work], e.g. use the script from notify-osd/src/send-test-notifications.sh | 13:22 |
| kenvandine[work] | MacSlow: seems fine | 13:23 |
| kenvandine[work] | turned it off and on 4 times | 13:23 |
| kenvandine[work] | 12 times... all good | 13:24 |
| MacSlow | kenvandine[work], are you running notify-osd trunk or the package from the jaunty repo? | 13:26 |
| kenvandine[work] | neither | 13:26 |
| MacSlow | ? | 13:26 |
| kenvandine[work] | this isn't on ubuntu | 13:27 |
| kenvandine[work] | on foresight | 13:27 |
| MacSlow | kenvandine[work], so it is trunk? | 13:27 |
| MacSlow | kenvandine[work], you did "bzr co lp:notify-osd" at some point? | 13:27 |
| kenvandine | 13:28 | |
| kenvandine | https://edge.launchpad.net/ubuntu/jaunty/+source/notify-osd/0.8-0ubuntu4/+files/notify-osd_0.8-0ubuntu4.tar.gz | 13:28 |
| kenvandine | from that tarball | 13:28 |
| MacSlow | 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 |
| kenvandine[work] | sure | 13:30 |
| kenvandine[work] | just hoping to help narrow the scope :) | 13:30 |
| pitti | hey kenvandine[work] | 13:40 |
| kenvandine[work] | hey pitti | 13:40 |
| seb128 | hello guys | 13:40 |
| kenvandine[work] | hey seb128! | 13:41 |
| seb128 | kenvandine[work]: hello | 13:41 |
| seb128 | kenvandine[work]: you should really change your nickname to not have [] chars | 13:41 |
| kenvandine[work] | does that bug you? | 13:41 |
| seb128 | that's really annoying to type on some kayboard layouts where you need to use modifiers for those chars ;-) | 13:42 |
| kenvandine[work] | ah | 13:42 |
| seb128 | well let's say I will stop using your nickname soon | 13:42 |
| kenvandine[work] | :) | 13:42 |
| seb128 | having to use a modifier to enter a nickname is extra work I'm too lazy to do often ;-) | 13:42 |
| === kenvandine[work] is now known as kenvandine2 | ||
| seb128 | thanks | 13:42 |
| seb128 | or _work would work too ;-) | 13:42 |
| === kenvandine2 is now known as kenvandine_wk | ||
| seb128 | and yeah, stupid french layout ;-) | 13:43 |
| kenvandine_wk | :) | 13:43 |
| asac | i never understood why anyone would append [work] | 13:43 |
| asac | ;) | 13:43 |
| seb128 | asac: you are working all the time that's why ;-) | 13:43 |
| asac | probably ;) | 13:43 |
| kenvandine_wk | i guess my name is an array | 13:43 |
| kenvandine_wk | :) | 13:43 |
| seb128 | 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 | 13:44 |
| === asac is now known as asac_drinking_co | ||
| === asac_drinking_co is now known as asac | ||
| asac | too bad | 13:44 |
| seb128 | lol | 13:44 |
| asac | keepnick didnt allow me to change my nick ;) | 13:44 |
| kenvandine_wk | seb128: yeah... i will do that | 13:44 |
| seb128 | 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:44 |
| kenvandine_wk | ok, thx | 13:45 |
| asac | yeah ... and only subscribing sponsors will give credit to the sponsor and help him get up on hall-of-fame | 13:45 |
| asac | ;) | 13:45 |
| pitti | kenvandine_wk: are you very busy ATM? if not, do you feel up to a little packaging training today? | 13:46 |
| seb128 | kenvandine_wk: how busy are you next week? ;-) | 13:46 |
| kenvandine_wk | pitti: i wanted to talk to you about that... | 13:46 |
| kenvandine_wk | seb128: depends on the uif stuff | 13:46 |
| kenvandine_wk | i think i have time to help with stuff | 13:46 |
| seb128 | 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:46 |
| seb128 | kenvandine_wk: ok, we tend to assign work there so just ask if you feel like doing some updates | 13:47 |
| kenvandine_wk | seb128: i would love to help with that | 13:47 |
| kenvandine_wk | will there be bugs created for each package? how do we manage that? | 13:48 |
| seb128 | 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:48 |
| seb128 | 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 |
| seb128 | ie having a list of all packages, series to watch, usual updates if there is any (to not hijack those) | 13:49 |
| seb128 | and then let people claim free updates by some way | 13:49 |
| seb128 | updates- > updaters | 13:50 |
| kenvandine_wk | i would that that wouldn't be hard to do in LP | 13:50 |
| seb128 | 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 |
| seb128 | probably not | 13:50 |
| seb128 | we should have usually updaters and "claim so work" lists in bzr somewhere | 13:51 |
| seb128 | and then we just need a webspace to host a page and a cron job updating it | 13:51 |
| kenvandine_wk | i am surprised it isn't all scripted :) | 13:52 |
| kenvandine_wk | seb128: in foresight land, we have a script called speedbump | 13:52 |
| kenvandine_wk | that bumps all of foresight | 13:52 |
| kenvandine_wk | all of gnome rather | 13:52 |
| seb128 | I don't want automatic update | 13:53 |
| seb128 | the recent gtk update make gdm crash for people who had non-xrandr-friendly drivers for example | 13:53 |
| kenvandine_wk | we do it in a devel branch, so it doesn't break peopel | 13:53 |
| seb128 | and detecting abi or api changes or soname changes and updating the packaging automatically is not trivial | 13:54 |
| seb128 | as is not detecting new files to install in binaries | 13:54 |
| seb128 | ie many case where thing could go wrongly | 13:54 |
| seb128 | or build-depends changes | 13:54 |
| seb128 | ie new requirements in the configure | 13:54 |
| Laney | seb128: you could integrate this into norsetto's script? | 13:54 |
| seb128 | we could automate some of those but that's non-trivial | 13:54 |
| seb128 | Laney: right, the webpage he worked on is a good start | 13:55 |
| kenvandine_wk | seb128: true... i guess that is easier for foresight, with conary | 13:56 |
| kenvandine_wk | we can do diffs after the build for dep changes... etc | 13:56 |
| kenvandine_wk | which is SO handy | 13:56 |
| seb128 | kenvandine_wk: deps are not an issue it's using ldd calls and rdepends | 13:57 |
| seb128 | kenvandine_wk: the issue is to know what to install to build | 13:57 |
| kenvandine_wk | oh... dpkg takes a list of files to install? | 13:57 |
| seb128 | 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:57 |
| seb128 | kenvandine_wk: yes, that's why you have {Depends:shlibs] usually in the control | 13:58 |
| seb128 | kenvandine_wk: that basically do a ldd and look to what package shilbs all those libs after build | 13:58 |
| seb128 | shlibs- > ships | 13:58 |
| seb128 | that's only for C though | 13:59 |
| seb128 | we don't have a similar system for python for example | 13:59 |
| seb128 | and build-depends are still manually specified since automatically parsing configure requirement is not easy | 13:59 |
| seb128 | especially as said that the requirements can depend on the build option | 14:00 |
| kenvandine_wk | yeah, that part is hard | 14:00 |
| kenvandine_wk | for buildReqs | 14:00 |
| seb128 | does conary manage to automate those? | 14:00 |
| asac | shlibs also does some magic for finding good lower bounds for the depends ;) | 14:01 |
| kenvandine_wk | seb128: mostly | 14:02 |
| kenvandine_wk | seb128: about 90% | 14:02 |
| kenvandine_wk | seb128: what's useful though is doing a diff on the deps after the build | 14:03 |
| kenvandine_wk | so comparing libgnome=2.24.1 to libgnome=2.24.2 | 14:03 |
| kenvandine_wk | you can do a diff and see what deps changed, which can be very enlightening :) | 14:03 |
| asac | kenvandine_wk: we dont do strict versioning | 14:04 |
| kenvandine_wk | yeah... conary is very strict | 14:04 |
| seb128 | kenvandine_wk: debian does depends automatically and you can debdiff binaries too | 14:04 |
| asac | sounds stale ;) | 14:04 |
| kenvandine_wk | well... conary do no versioned deps | 14:04 |
| kenvandine_wk | soname deps | 14:04 |
| kenvandine_wk | etc | 14:04 |
| seb128 | how do you assure that the required version is installed then? | 14:05 |
| asac | so it doesnt care about versions at all? | 14:05 |
| kenvandine_wk | if the soname is satisfied | 14:06 |
| kenvandine_wk | one package provides soname: ELF32/libgobject-2.0.so.0(SysV x86) | 14:06 |
| kenvandine_wk | another one requires soname: ELF32/libgobject-2.0.so.0(SysV x86) | 14:06 |
| seb128 | kenvandine_wk: the source has no knowledge of the soname required | 14:06 |
| kenvandine_wk | it's satisfied | 14:06 |
| seb128 | the configure depends on a version | 14:07 |
| seb128 | and the source use symbols | 14:07 |
| seb128 | but the soname doesn't matter there | 14:07 |
| kenvandine_wk | sure, pkgconfig, etc | 14:07 |
| seb128 | no | 14:07 |
| seb128 | pkgconfig has no soname clue | 14:07 |
| seb128 | the soname is a pure libtool thing | 14:07 |
| kenvandine_wk | no, but version needs | 14:07 |
| kenvandine_wk | yes | 14:07 |
| kenvandine_wk | conary doesn't do that for you before you build it | 14:07 |
| seb128 | well, it can't guess | 14:08 |
| seb128 | that's not because you use a version to build that previous version would be enough | 14:08 |
| asac | kenvandine_wk: adding new symbols without breaking ABI/API will not bump the major soname version | 14:08 |
| kenvandine_wk | yeah, so then you get a failure and have to look at the logs | 14:08 |
| asac | so you can have binaries build that require a new minor version | 14:08 |
| asac | objdump -x /usr/lib/libglib-2.0.so | grep SONA SONAME libglib-2.0.so.0 | 14:10 |
| asac | i think the SONAME has been stable for long time ... even though new symbols where added | 14:11 |
| asac | you need SONAME + minimum version to get accurate depends | 14:11 |
| seb128 | in fact the debian system is quite clever | 14:12 |
| seb128 | I doubt conary does much better now | 14:12 |
| asac | the old one was clever | 14:12 |
| asac | the new (symbols) is quite perfect even | 14:12 |
| seb128 | the current debian tools have tracking of what symbols have been added in which version | 14:12 |
| seb128 | so you know exactly what version you need by looking at the symbols you use | 14:12 |
| asac | right. my point was just that: | 14:12 |
| asac | 15:06 < kenvandine_wk> one package provides soname: ELF32/libgobject-2.0.so.0(SysV x86) | 14:12 |
| asac | 15:06 < kenvandine_wk> another one requires soname: ELF32/libgobject-2.0.so.0(SysV x86) | 14:13 |
| asac | is flawed ;) | 14:13 |
| * asac keeps out of this now ;) | 14:13 | |
| seb128 | yeah, I don't want to start a distro troll eithe | 14:14 |
| seb128 | either | 14:14 |
| * asac still waiting for a phone number for a call that ws supposed to start 15 minutes ago | 14:15 | |
| rickspencer3 | morning all | 14:39 |
| rickspencer3 | ArneGoetje: asac: bryce: calc: kenvandine_wk: pitti: Riddell: did you guys see the new hire announcements from HR today? | 14:40 |
| rickspencer3 | any one notice that addition of a certain tseliot to the list? | 14:40 |
| tseliot | ;) | 14:40 |
| * rickspencer3 congratulates tseliot | 14:41 | |
| kenvandine_wk | rickspencer3: wow... | 14:41 |
| seb128 | hello rickspencer3 | 14:41 |
| kenvandine_wk | hey tseliot | 14:41 |
| seb128 | tseliot: congrats ;-) | 14:41 |
| tseliot | thanks :-) | 14:41 |
| kenvandine_wk | welcome tseliot | 14:41 |
| asac | rickspencer3: i tried to spot someone for our team, but it was a long list ;). seems i missed him | 14:41 |
| asac | welcome tseliot | 14:42 |
| rickspencer3 | tseliot: is joining the OEM team | 14:42 |
| rickspencer3 | which will be great for us | 14:42 |
| Riddell | please fix all my X problems :) | 14:42 |
| asac | ah ;) | 14:42 |
| rickspencer3 | we'll have an X representative over there | 14:42 |
| tseliot | yes, it's what I'll have to do ;) | 14:42 |
| rickspencer3 | and it'll help the teams work ever more closely in synch | 14:43 |
| * pitti hugs tseliot | 14:43 | |
| pitti | rickspencer3: I heard it a few days ago indeed | 14:43 |
| tseliot | yes, some of you knew it in advance | 14:44 |
| dobey | heh | 14:45 |
| === rickspencer3 is now known as rickspencer3-afk | ||
| tedg | 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:47 |
| dobey | tseliot: congrats :) | 14:50 |
| tseliot | thanks everyone :-) | 14:51 |
| crevette | tedg, mvo is off today | 14:51 |
| tedg | crevette: I figured. But I was hoping someone else had an answer. :) | 14:52 |
| tedg | By away from keyboard, I meant really away. :) | 14:52 |
| james_w | tedg: you mean detect whether a restart is currently required? | 14:55 |
| tedg | james_w: Yes. | 14:55 |
| james_w | tedg: I would assume you have a kernel installed :-) | 14:56 |
| james_w | tedg: /var/run/reboot-required is the file that is created by packages when an upgrade requires a restart | 14:56 |
| tedg | james_w: Okay, so if that exists, then someone wants a reboot. Cool, thanks! | 14:57 |
| james_w | tedg: that's the basics, there may be more to it, such as detecting which packages requested it, but I'm not sure | 14:57 |
| tedg | james_w: I don't need to know that, so I'm good there :) | 14:58 |
| tedg | james_w: BTW, while I have you on the line. Why do some packages not exist in package-import? | 14:58 |
| tedg | Like some have older releases, but not Jaunty. | 14:59 |
| tedg | Is it just a time thing? | 14:59 |
| james_w | tedg: they probably crashed the importer | 15:00 |
| tedg | 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 |
| james_w | tedg: if there are specific ones you are interested in I can look at/fix them | 15:00 |
| james_w | there's around 100 of those packages | 15:00 |
| tedg | james_w: I don't remember which package it was, but I just noticed it the other day and was curious. | 15:01 |
| james_w | 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:01 |
| tedg | 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. | 15:02 |
| === rickspencer3-afk is now known as rickspencer3 | ||
| * tedg hates patches and especially debdiffs and thinks they should only be used as "compiled" files. | 15:03 | |
| tedg | 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:13 |
| james_w | tedg: I'd be interested to see it | 15:14 |
| tedg | james_w: The script is "bzr-patch-build" https://code.launchpad.net/~ted-gould/fast-user-switch-applet/ubuntu-packaging-jaunty | 15:17 |
| tedg | 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 |
| james_w | heh | 15:19 |
| james_w | not what I expected to see in there :-) | 15:19 |
| tedg | Just to be curious, what'd you expect? | 15:20 |
| james_w | interesting though, thanks a lot | 15:20 |
| james_w | no idea, just not json :-) | 15:20 |
| james_w | it makes for a neat description though | 15:20 |
| * james_w files that one away in his head for later | 15:20 | |
| hyperair | 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:20 |
| tedg | hyperair: gnome-settings-daemon | 15:21 |
| hyperair | hmm okay | 15:21 |
| hyperair | time to go digging around for patches in there | 15:21 |
| hyperair | and maybe backport just the patch | 15:21 |
| tedg | hyperair: Yeah, that should be possible. If you have questions, davidbarth may be able to answer them. He wrote the patch. | 15:21 |
| hyperair | cool | 15:22 |
| tedg | 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:23 |
| james_w | isn't the brightness g-p-m? | 15:24 |
| tedg | hyperair: ^ | 15:24 |
| tedg | james_w: correct, the volume is gsd. | 15:24 |
| hyperair | james_w: aah probably. thanks | 15:25 |
| tedg | I think the pop-ups in Intrepid for both are in gsd though. | 15:25 |
| hyperair | i wish the bug regarding gsd and media keys not respecting priority would get fixed already though =\ | 15:25 |
| hyperair | i mean SRU'd | 15:25 |
| james_w | didrocks, Laney: http://revu.ubuntuwire.com/p/evolution-mapi is now advocated if someone has a chance to look | 15:42 |
| didrocks | james_w: I will do it tonight :) | 16:10 |
| james_w | great, thanks | 16:11 |
| didrocks | james_w: if I advocate it. Then, I sponsor it? | 16:11 |
| james_w | yeah | 16:11 |
| james_w | if you ask for changes then advocate the new one | 16:11 |
| james_w | and I'll look tomorrow if you don't find someone else tonight | 16:12 |
| james_w | the only issue I see is that the lib package name doesn't match the SONAME, but that's not critical | 16:12 |
| didrocks | ok, I will ping you tomorrow in this case :) | 16:12 |
| james_w | great | 16:12 |
| Laney | what about sendto-universe? | 16:12 |
| Laney | do we want two +1s for that? | 16:12 |
| didrocks | Laney: seb only ask for one | 16:13 |
| didrocks | Laney: so, you can handle it :) | 16:13 |
| Laney | hot | 16:13 |
| didrocks | Laney: if you want, I can review it as well | 16:13 |
| Laney | that dependency on nautilus-sendto concerns me | 16:13 |
| Laney | I think we need to find a way of saying that it must be the same upstream version | 16:13 |
| james_w | Build-Depends, or Depends? | 16:14 |
| Laney | depends | 16:14 |
| james_w | you can do that | 16:14 |
| Laney | do tell | 16:15 |
| james_w | substvars | 16:15 |
| Laney | >= ${source:upstream-version}, << ${...}+ or so? | 16:15 |
| james_w | UPSTREAM_VERSION="$(dpkg-parsechangelog | sed -n -e '/^Version: /s/^Version: //p')" | 16:16 |
| james_w | echo $UPSTREAM_VERSION > debian/package.substvars during binary | 16:16 |
| james_w | err | 16:16 |
| james_w | source:upstream-version $UPSTREAM_VERSION I mean | 16:17 |
| didrocks | I have to go and see an RMS conference, see you guys :) | 16:17 |
| james_w | something like that anyway | 16:17 |
| Laney | I thought that substvar already existed by default | 16:17 |
| Laney | but how to actually specify the depends? | 16:17 |
| james_w | then ">= ${source:upstream-version}~, << ${source:upstream-version}~" as you suggest | 16:17 |
| james_w | with the pacakge names of course | 16:17 |
| james_w | ah, I didn't think it was there by default | 16:18 |
| james_w | or you could just do it by hand on each upstream release :-) | 16:18 |
| Laney | why ~? | 16:18 |
| james_w | ah, source:Upstream-Version | 16:19 |
| james_w | so that "2.0~beta1" would satisfy | 16:19 |
| james_w | you can leave it off either end depending on upstream's policies | 16:19 |
| james_w | 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 |
| Laney | I'll play in a sec | 16:20 |
| Laney | just going home, brb | 16:20 |
| pitti | kenvandine_wk: hm, so you want bug 331571 uploaded? | 16:27 |
| ubottu | Launchpad bug 331571 in evolution "disable Mail Notification eplugin by default" [Low,Confirmed] https://launchpad.net/bugs/331571 | 16:27 |
| pitti | kenvandine: I thought that wouldn't DTRT? | 16:27 |
| kenvandine | pitti: i thought we agreed it would... ?? | 16:28 |
| pitti | kenvandine: ah, so that does just hide the applet, but leaves the plugin running? | 16:29 |
| kenvandine | pitti: yes | 16:29 |
| crevette | hey | 16:29 |
| pitti | kenvandine: ok, sounds good then | 16:30 |
| kenvandine | pitti: it disables the icon in the notification area, but does load the plugin | 16:30 |
| kenvandine | ok | 16:30 |
| pitti | kenvandine: so that won't work with stracciatella-session then | 16:30 |
| pitti | 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:30 | |
| pitti | kenvandine[work]: see comment 3 | 16:31 |
| kenvandine[work] | certainly a lot more work... have you put much thought into a general way to handle gconf changes from upstream? | 16:32 |
| kenvandine[work] | i suspect there are quite a few gconf keys we change | 16:32 |
| kenvandine[work] | might be nice to have it load a different set of gconf defaults based on session | 16:32 |
| pitti | do we? I'm not aware of so many | 16:32 |
| kenvandine[work] | i don't know... but i would suspect so | 16:32 |
| pitti | well, probably not a completely parallel set, but some keys | 16:32 |
| kenvandine[work] | so perhaps a generic way of handling that instead of hacking each package | 16:33 |
| hggdh | kenvandine, are you going to propose this fix upstream? | 16:33 |
| pitti | hggdh: it's not really a fix | 16:33 |
| pitti | that gconf change is a workaround hack for the indicator applet | 16:33 |
| pitti | so it wouldn't be suitable upstream | 16:33 |
| kenvandine[work] | right | 16:33 |
| pitti | unless they accept that the indicator applet becomes the new standard, of course | 16:33 |
| kenvandine[work] | :) | 16:34 |
| kenvandine[work] | maintaining the patch for gconf is probably much easier than a larger patch to the plugin itself | 16:34 |
| pitti | right, no doubt about that (although the "larger patch" should not be bigger than 5 lines either) | 16:35 |
| kenvandine[work] | maybe | 16:35 |
| kenvandine[work] | i can look at doing that too | 16:35 |
| hggdh | ok, OK. I thought we were effectively disabling the plugin | 16:35 |
| pitti | kenvandine[work]: something like http://bazaar.launchpad.net/~ubuntu-core-dev/indicator-applet/ubuntu/revision/135 | 16:35 |
| kenvandine[work] | hggdh: no... we don't want to do that | 16:35 |
| pitti | 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 |
| kenvandine[work] | true | 16:36 |
| pitti | kenvandine[work]: and if we ask $GDMSESSION (which is admittedly an equally hackish thing), we don't have above issues | 16:36 |
| pitti | and we'd at least use hacks which are consistent :) | 16:36 |
| pitti | kenvandine[work]: seriously, I dont' think that this $GDMSESSION thing is the final answer to this | 16:37 |
| kenvandine[work] | pitti: but... if someone disables the indicator-applet and wants to use the default, we want it to be there too | 16:37 |
| pitti | but it's unintrusive, and thus can easily be reverted and replaced with a better solution, once we have one | 16:37 |
| pitti | kenvandine[work]: right | 16:37 |
| kenvandine[work] | hacking the gconf key lets the user enable them if they like | 16:37 |
| pitti | true that | 16:37 |
| kenvandine[work] | less likely to piss someone off :) | 16:38 |
| pitti | kenvandine[work]: but if they do, then it will stay there forever | 16:38 |
| kenvandine[work] | i would hate to get a flame about how ubuntu makes decisions for them.. yada yada | 16:38 |
| kenvandine[work] | pitti: yes | 16:38 |
| kenvandine[work] | so either way it isn't great... | 16:38 |
| pitti | and we'd land in the very situation I was trying to avoid | 16:38 |
| pitti | kenvandine[work]: ideally, the upstream applet could check whether indicator-applet is running | 16:39 |
| hggdh | well... upstream evo is easily approachble, and seb and I have a good rapport with them | 16:39 |
| kenvandine[work] | pitti: that might be upstreamable | 16:39 |
| kenvandine[work] | but a little harder to do in a sane way i think | 16:39 |
| === kenvandine[work] is now known as kenvandine_wk | ||
| pitti | kenvandine_wk: oh, btw, it's "indicator-applet running" and "$GDMSESSION != stracciatella" | 16:43 |
| pitti | bah, 3v1l h4cks | 16:43 |
| kenvandine_wk | yeah... i know | 16:43 |
| kenvandine_wk | pitti: but i think anything we do will be evil hacks... at least until/if the indicator makes it upstream | 16:44 |
| kenvandine_wk | pitti: my initial thought is gconf patch is more flexible for the user... but not opposed to something more intrusive for now | 16:45 |
| pitti | kenvandine_wk: flexible yes, but then we'll only rely on the user to configure it | 16:46 |
| kenvandine_wk | yeah, i know | 16:46 |
| pitti | and changing gconf default is much more intrusive than silently hiding itself based on runtime checks | 16:46 |
| kenvandine_wk | want me to create a patch based on the session? | 16:46 |
| pitti | intrusive wrt. the changes we have to revert later, not in terms of lines of code, of course | 16:47 |
| kenvandine_wk | i was mostly thinking about user experience... if they want to enable it | 16:47 |
| pitti | kenvandine_wk: well, I'd like us to find an approach we are all happy about first | 16:47 |
| pitti | kenvandine_wk: you want to retain the possibility to use both applets at the same time? | 16:47 |
| kenvandine_wk | not necessarily at the same time.. just thinking about people that might not use the indicator | 16:48 |
| kenvandine_wk | personally i don't think the built in mail notifier is as good :0 | 16:48 |
| kenvandine_wk | i like the indicator | 16:48 |
| * kenvandine_wk -> lunch | 16:51 | |
| mpt | pitti, is there any reasonable way for Ubuntu to tell whether a storage device is the sort of thing that is "disconnected" (e.g. USB key) vs. "ejected" (e.g. SD card)? | 17:02 |
| pitti | mpt: yes, there is | 17:03 |
| pitti | mpt: hal calls those "removable" (media, like CD or sd card readers) vs. "hotpluggable" (usb stick, camera) | 17:03 |
| mpt | Awesome! | 17:03 |
| pitti | mpt: if you know the device name or the hal URI, you can ask hal for the properties | 17:03 |
| pitti | mpt: plug in an USB key and do "lshal | grep removable" | 17:04 |
| pitti | (that's of course not the implementation, but for seeing how it looks in the DB) | 17:04 |
| mpt | good good | 17:05 |
| * mpt discovers that Nautilus has an "Open Autorun Prompt" button :-( | 17:06 | |
| asac | i think there are quite a few users that wouldnt understand what "Open Autorun Prompt" means ;) | 17:10 |
| asac | what does that do ;)? | 17:10 |
| mpt | exactly | 17:11 |
| mpt | It runs whatever is specified in the volume's autorun.inf | 17:12 |
| asac | wow | 17:12 |
| asac | "Kick Off This Thing. Go!" | 17:13 |
| mpt | or to be precise, it opens a confirmation alert asking if you want to run whatever's specified in the autorun.inf | 17:13 |
| asac | yeah ;) | 17:13 |
| mpt | (hence the "prompt" par) | 17:13 |
| mpt | t | 17:13 |
| mpt | I wonder if it's conditional depending on whether wine is installed | 17:13 |
| asac | heh | 17:14 |
| asac | maybe its a wine extension to nautilus even | 17:14 |
| hyperair | davidbarth: regarding your patch for notify-osd in gsd, how did you manage to make it build without patching Makefile.in? | 17:20 |
| mpt | Another fun Nautilus message: "Cannot display location "smb://[blah@blah]" "DBus error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)" | 17:23 |
| * mpt thinks that should have an icon of a bus with a flat tire | 17:24 | |
| davidbarth | hyperair: seb128 fixed that for me i think ;) | 17:26 |
| hyperair | damn he's not here | 17:27 |
| hyperair | i can't figure out where to change | 17:27 |
| hyperair | if Makefile.in isn't patched, then surely it has to be regenerated | 17:27 |
| davidbarth | yes, it's probably a packaging patch to call autoconf/make at the right time | 17:28 |
| davidbarth | apt-get source | 17:28 |
| davidbarth | you should see that there | 17:28 |
| hyperair | i don't see anywhere where autoconf/make is called! | 17:28 |
| hyperair | i mean debian/rules doesn't seem to call it | 17:28 |
| hyperair | i'm on intrepid, so i dget'd the package | 17:29 |
| james_w | hyperair: g-s-d calls autoreconf at build time, in jaunty at least | 17:29 |
| james_w | no | 17:29 |
| hyperair | james_w: where's that | 17:29 |
| james_w | it's got an autoreconf patch, that's it | 17:29 |
| james_w | if intrepid has one then regenerate it | 17:29 |
| james_w | if not then create one | 17:30 |
| hyperair | autoreconf patch? | 17:30 |
| hyperair | why wasn't it added in debian/rules | 17:30 |
| hyperair | ooh i see it now | 17:31 |
| hyperair | james_w: thanks. i'll look into this. | 17:32 |
| hyperair | the patch sure adds a lot of unnecessary stuff to Makefile.in | 17:34 |
| asac | hyperair: usually autoreconf patches are not rally minimal. thats ok as you have to recreate it on every new version anyway | 17:36 |
| hyperair | asac: yeah, so i noticed. why not add autoreconf to debian/rules? | 17:36 |
| hyperair | asac: i think cdbs has some method of ensuring that autoconf/make is called | 17:37 |
| hyperair | i used it for one of my packages | 17:37 |
| dashua | Testing notify-osd trunk and lost brightness and audio notifications. Reverted back to the old GNOME style. Is that known? | 17:37 |
| asac | hyperair: problem with just letting cdbs do it is that there is no way to get back to clean state | 18:00 |
| asac | unless you dont ship a dist tarball | 18:00 |
| asac | (e.g. without Makefile.in and configure) | 18:00 |
| hyperair | i see | 18:01 |
| hyperair | good point | 18:01 |
| asac | e.g. i auto gen stuff in NM, but i just export directly from svn/bzr/git | 18:01 |
| asac | so i can just remove the generated files during clean: and all is fine | 18:01 |
| hyperair | but on the other hand, an autoreconf stuff makes quite a huge patch | 18:01 |
| asac | if you use a make dist tarball, you need to use a patch | 18:01 |
| hyperair | i mean diff.gz | 18:01 |
| hyperair | i guess i should relook my bansheelyricsplugin package. | 18:01 |
| asac | yeah. thats why i try to get rid of them ;) | 18:01 |
| asac | not sure if thats best practice ;) | 18:01 |
| hyperair | no wait... | 18:01 |
| dobey | yeah. the having to do that sucks | 18:01 |
| hyperair | aha. i couldn't use a patch for that | 18:02 |
| asac | actually i think there are a few that dont like that approach | 18:02 |
| hyperair | you see, ./configure is called before patching is done =p | 18:02 |
| hyperair | and the author conveniently left out the Makefile.in | 18:02 |
| asac | they say that depending on auto tools during build is bad for porters from what i understood | 18:02 |
| * hyperair headdesks | 18:02 | |
| asac | hyperair: no. for me ./configure is run after patching | 18:02 |
| asac | i think everything else is a bug | 18:02 |
| hyperair | seriously? | 18:02 |
| hyperair | no i think ./configure is run before and after | 18:02 |
| asac | i thin kthe gnome packages have a strange behaviour in that they run configure during clean ;) | 18:03 |
| hyperair | i think it's cdbs =\ | 18:03 |
| asac | hyperair: i guess the before is from clean: in gnome packages | 18:03 |
| hyperair | hmm | 18:03 |
| asac | hyperair: i use cdbs for NM and mozilla packages with autotools generation and everything | 18:03 |
| hyperair | that was a gnome package too | 18:03 |
| asac | it doesnt do that for me | 18:03 |
| hyperair | and yeah it ran, and failed | 18:03 |
| asac | and i also had painful experiences with gnome packages | 18:03 |
| hyperair | simply because Makefile.in was missing | 18:03 |
| asac | because of that | 18:03 |
| hyperair | also i think i know why configure is run before clean.. you need Makefile's to clean | 18:03 |
| hyperair | how about ripping out the unneeded hunks? | 18:04 |
| hyperair | a minimal Makefile.in patch | 18:04 |
| asac | in gnome packages it was impossible to patch new configure --options | 18:04 |
| asac | if you used them in rules | 18:04 |
| hyperair | eh? | 18:04 |
| asac | because in clean configure would be run without patch and the --option hence didnt exist | 18:04 |
| asac | and it failed and you ended up in an endless loop | 18:04 |
| hyperair | heheh | 18:04 |
| hyperair | ouch | 18:04 |
| asac | was no fun | 18:04 |
| hyperair | yeah, it's pretty painful | 18:04 |
| hyperair | i think it's the same for all packages using cdbs isn't it | 18:05 |
| asac | i guess usually folks dont patch in new configure options though | 18:05 |
| asac | so its pretty much corner case ;) | 18:05 |
| asac | hyperair: no its not | 18:05 |
| asac | its definitly gnome related | 18:05 |
| hyperair | are you sure? | 18:05 |
| asac | hyperair: i am 100% sure that my packages dont run configure on clean | 18:05 |
| hyperair | but configure must definitely be called before make for all autotools stuff | 18:05 |
| hyperair | if you don't have a Makefile, you can't make clean | 18:05 |
| hyperair | or distclean | 18:05 |
| asac | hyperair: well. if you dont have a makefile, you should just assume that the tarball is clean | 18:06 |
| asac | and dont run make clean | 18:06 |
| hyperair | hmm | 18:06 |
| hyperair | then it's a bug in cdbs | 18:06 |
| hyperair | the gnome parts anyway | 18:06 |
| asac | hyperair: its a gnome cdbs particuliarity. i think its ok, except for the case where you need to patch configure like i said above | 18:07 |
| hyperair | yeah, then it's a bug right? | 18:07 |
| hyperair | bah. i'm getting empty notify-osd dialogs for my volume | 18:08 |
| hyperair | and brightness... seems to be not handled by gsd | 18:08 |
| hyperair | yeah my brightness thing still shows up as the default GNOME one | 18:08 |
| bryce | rickspencer3, tseliot: great news :-) | 18:10 |
| * hyperair likes the new login screen | 18:12 | |
| * kenvandine_wk does too | 18:13 | |
| hyperair | blargh. i need to use the human theme or the volume thing doesn't work! | 18:14 |
| hyperair | damnit! | 18:14 |
| hyperair | imo the new icons should go into the default fallback | 18:15 |
| hyperair | where can i get a list of the icon names? | 18:21 |
| dobey | there's a bug on that already | 18:24 |
| dobey | should be fixed soonish i think | 18:24 |
| dobey | if you're talking about the notify-osd icons anyway | 18:24 |
| chrisccoulson | mpt - can you spare a few minutes? | 18:26 |
| mpt | chrisccoulson, depends what for. :-) I'm pretty busy | 18:28 |
| chrisccoulson | it doesn't matter too much. i noticed you're subscribed to bug 333269 now. i made a suggestion a few days ago to pop up a tomboy note instead of a notification, but i had no feedback. i just wanted to get your thoughts really - i have a patch now which is complete enough to be tested as well | 18:29 |
| ubottu | Launchpad bug 333269 in gnome-screensaver "[jaunty] leave message does not use new notify system" [Undecided,Confirmed] https://launchpad.net/bugs/333269 | 18:29 |
| hyperair | hmm inheriting from human did the trick | 18:29 |
| hyperair | but i think notify-osd should ship its own icon | 18:30 |
| mpt | chrisccoulson, that would be a bit odd. What happens if Tomboy isn't installed? | 18:30 |
| hyperair | and fall back to it | 18:30 |
| chrisccoulson | if tomboy isnt installed, it falls back to a notification | 18:31 |
| mpt | a bubble? | 18:31 |
| chrisccoulson | it uses the fallback, because the screensaver demands that it never expires | 18:31 |
| chrisccoulson | that was the motivation for suggesting another alternative | 18:32 |
| chrisccoulson | the good thing about having it export the message to a note, is that you can close the note and act on it whenever you want, similar to how you might handle someone leaving a post-it on your desk | 18:32 |
| hyperair | chrisccoulson: that sounds pretty cool actually | 18:35 |
| hyperair | but not everyone uses tomboy, even if it is installed | 18:35 |
| mpt | It is a cool design | 18:35 |
| hyperair | perhaps check if tomboy is running | 18:35 |
| chrisccoulson | that doesn't matter. tomboy ships a dbus service, and my patch will use that to start tomboy | 18:35 |
| hyperair | and if so, add a new tomboy note | 18:35 |
| hyperair | yeah but what if the user doesn't want to use tomboy | 18:36 |
| hyperair | then i think it'd fine to fall back to the dialog approach | 18:36 |
| chrisccoulson | if the user doesn't want to use it, my patch is gconf configurable;) | 18:36 |
| hyperair | not everyone likes staring into the gconf | 18:36 |
| hyperair | i don't really like it | 18:36 |
| chrisccoulson | i've been maintaining the patch in bzr : https://code.edge.launchpad.net/~chrisccoulson/gnome-screensaver/tomboy-note-integration. feel free to try it out:) | 18:37 |
| hyperair | though i do some digging now and then | 18:37 |
| hyperair | why don't you just check if tomboy is running? | 18:37 |
| hyperair | if tomboy is running, then obviously the user is using tomboy | 18:37 |
| hyperair | otherwise, the user isn't | 18:37 |
| hyperair | simple. | 18:37 |
| hyperair | don't force the user to have to turn it off if they don't use tomboy | 18:37 |
| mpt | I was thinking there should be a "While you were out" window that listed each message with a timestamp | 18:37 |
| dobey | hyperair: what theme are you using? | 18:38 |
| hyperair | dobey: black-white | 18:38 |
| dobey | oh | 18:38 |
| chrisccoulson | mpt - that could be possible too | 18:38 |
| hyperair | dobey: i just made it inherit from human | 18:38 |
| dobey | yeah | 18:38 |
| hyperair | dobey: but yeah, i imagine many people use themes that don't inherit from human, and it'd break | 18:38 |
| hyperair | having notify-osd depend on human-icon-theme doesn't look like a very nice move | 18:40 |
| hyperair | imo these icons should be default, and overridable | 18:40 |
| dobey | no, the answer is to follow the themeable app specific icons stuff | 18:43 |
| dobey | but there's a bug, and that information is provided there :) | 18:43 |
| hyperair | dobey: number? | 18:44 |
| dobey | lp bug #334472 | 18:44 |
| ubottu | Launchpad bug 334472 in notify-osd "Inherit human-icon-theme so that gnome-icon-theme and all icon-themes which depend on it have access to the notification-* icons used by notify-osd. (dup-of: 331311)" [Wishlist,Confirmed] https://launchpad.net/bugs/334472 | 18:44 |
| ubottu | Launchpad bug 331311 in notify-osd "volume/brightness notifications are blank (all black)" [Undecided,Confirmed] https://launchpad.net/bugs/331311 | 18:44 |
| hyperair | somehow i don't think that's a good idea either =\ | 18:49 |
| hyperair | notify-osd will hopefully eventually go upstream. | 18:49 |
| hyperair | right? | 18:49 |
| hyperair | in that case, you wouldn't want to force users to have human-icon-theme (or face having a blank black notification) | 18:49 |
| dobey | huh? | 18:51 |
| dobey | this doesn't force users to have human-icon-theme | 18:51 |
| hyperair | sure it does | 18:51 |
| dobey | how so? | 18:51 |
| hyperair | if you don't have human-icon-theme installed, you can inherit from it | 18:51 |
| dobey | hicolor != human | 18:51 |
| hyperair | ^ | 18:51 |
| dobey | nothing should be inheriting from human | 18:51 |
| dobey | especially not gnome | 18:52 |
| hyperair | sorry, i was looking at the bug you just mentioned | 18:52 |
| hyperair | the title | 18:52 |
| dobey | (also, gnome won't ever inherit from human) | 18:52 |
| hyperair | https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/331311/comments/27 <-- this seems acceptable | 18:52 |
| ubottu | Ubuntu bug 331311 in notify-osd "volume/brightness notifications are blank (all black)" [Undecided,Confirmed] | 18:52 |
| dobey | (nor will tango) | 18:52 |
| hyperair | good | 18:52 |
| dobey | <- 'upstream' | 18:52 |
| hyperair | yes yes | 18:53 |
| dobey | https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/334472/comments/2 was what i was referring to as being the correct solution | 18:53 |
| ubottu | Ubuntu bug 334472 in notify-osd "Inherit human-icon-theme so that gnome-icon-theme and all icon-themes which depend on it have access to the notification-* icons used by notify-osd. (dup-of: 331311)" [Wishlist,Confirmed] | 18:53 |
| hyperair | aha | 18:53 |
| hyperair | okay | 18:53 |
| hyperair | but that's marked duplicate =p | 18:54 |
| dobey | eh | 18:54 |
| dobey | there are lots of related bug reports i guess :) | 18:54 |
| hyperair | yeah | 18:54 |
| dobey | it is marked 'Invalid' for gnome-icon-theme, and was added to notify-osd instead | 18:54 |
| dobey | which is correct | 18:54 |
| hyperair | mhmm | 18:54 |
| hyperair | yep | 18:54 |
| hyperair | so has it been fixed in trunk? | 18:55 |
| hyperair | also is there some way i can subscribe to notify-osd releases? | 18:55 |
| hyperair | i'm currently maintaining a ppa for intrepid | 18:55 |
| hyperair | after the final (i think) addition -- gnome-power-manager, the whole new notifications system should be ported over to intrepid. | 18:55 |
| dobey | i don't know if it's actually been fixed or not | 18:56 |
| dobey | i guess kwwii or dholbach (neither of which are around now) would be able to answer :) | 18:56 |
| hyperair | heh yeah | 18:56 |
| dobey | and the icons will be black with my new theme anyway | 18:57 |
| tedg | chrisccoulson: ping | 21:00 |
| === asac_ is now known as asac | ||
| chrisccoulson | hi tedg, sorry, i was away having dinner | 21:38 |
| tedg | chrisccoulson: No problem, I just replied on list :) | 21:39 |
| chrisccoulson | thanks, i just read it. yeah, that makes sense. | 21:40 |
| chrisccoulson | and also, even if it did do the saving, it would only work for the user who called the shutdown action. it still wouldn't work for other users who might be logged in to the system (but inactive) | 21:41 |
| tedg | chrisccoulson: Yes, mccann had some interesting ideas on that: http://fedoraproject.org/wiki/Desktop/Whiteboards/InhibitApis | 21:42 |
| tedg | Basically using ConsoleKit to send a signal to all sessions. | 21:43 |
| tedg | It'd be interesting see a version of GNU Screen using it too :) | 21:43 |
| chrisccoulson | yeah, using consolekit to send a signal to all sessions sounds neat | 21:44 |
| * hyperair thinks that the indicator-applet seems a lot like another notification area applet | 22:08 | |
| Laney | grrrrrrr | 22:45 |
| chrisccoulson | ?? | 22:45 |
| Laney | I was going to rant, then changed my mind | 22:47 |
| chrisccoulson | lol | 22:47 |
| Laney | nobody wants to hear about pop-under windows | 22:47 |
| Laney | suffice to say: | 22:47 |
| chrisccoulson | i love ranting. what did you want to rant about? | 22:47 |
| * Laney shakes his fist at them | 22:47 | |
| chrisccoulson | ah | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!