| ruben23 | hi guys i have 50 PC unit want to used UNE to install, how to install them on a fastest way and all pc dont have disc drive..any suggestion...? | 00:26 |
|---|---|---|
| ruben23 | hi guys any idea..? | 00:29 |
| RAOF | ruben23: Not really a #ubuntu-desktop question, but I think you could probably netboot/netinst those - I'm fairly sure that you can script entirely if you can get the netbooks booting over PXE. Failing that, UNE is distributed as a USB stick image. | 00:32 |
| ruben23 | RAOF:is download and can be installed by default as USB..? | 00:41 |
| RAOF | ruben23: You can use “Startup Disk Creator” to create a bootable USB stick from an Ubuntu iso, such as the netbook iso. Further questions should probably be in a support channel, like #ubuntu | 00:44 |
| hallyn | ccheney: so the amd64 image i got from clicking 'start download' on http://www.ubuntu.com/desktop/get-ubuntu/download never worked for me, but the torrent from alternate downloads on the same page did. now i'm in business. | 04:42 |
| pitti | Good morning | 05:36 |
| robert_ancell | pitti, I'm not sure how reliably you can split the dconf binaries from the libraries. /usr/bin/dconf is the equivalent of gconftool. The other binaries form the daemon part of libdconf - I would expect there to require to be in sync | 07:33 |
| pitti | robert_ancell: then libdconf0 has to depend on it | 07:33 |
| pitti | but we still need to be able to install libdconf{0,1} in parallel | 07:34 |
| pitti | if the dbus backend is supposed to be soname specific as well, it needs to get a soname specific name | 07:34 |
| robert_ancell | pitti, since libexec directories aren't versioned this isn't possible is it? | 07:34 |
| pitti | like /usr/bin/dconf0 and /usr/share/dbus-1/services/dconf0.service | 07:34 |
| pitti | but I'd rather split it into a separate package, FWIW | 07:35 |
| robert_ancell | I don't think we'd achieve anything by splitting it | 07:35 |
| pitti | well, it's splitting or making file paths soname specific, as you prefer | 07:35 |
| robert_ancell | desrt, ^^ | 07:35 |
| pitti | but the latter looks both ugly and also is against the spirit of library packages | 07:36 |
| pitti | and the dbus API and library ABI can change independently, too | 07:36 |
| robert_ancell | I can see the value of splitting the tool out /usr/bin/dconf but the daemon and d-conf service are going to have to be versioned | 07:38 |
| pitti | that should be discussed with desrt then, before we change file paths on our own | 07:38 |
| robert_ancell | or do we assume the service is always backwards compatible? | 07:39 |
| pitti | once the dbus API changes, it won't; but that could be expressed with normal versioned package dependencies, too | 07:40 |
| didrocks | good morning | 08:03 |
| pitti | bonjour didrocks, how was the weekend? | 08:07 |
| pitti | mvo: guten Morgen! | 08:07 |
| pitti | mvo: would you mind updating the software-center app database list for maverick? (or did you already?) | 08:08 |
| mvo | hey pitti | 08:08 |
| didrocks | hey pitti, It was good but tiring (Ubuntu Party in Paris all over the week-end!), and you, did you enjoy your long week-end in Munich? | 08:08 |
| mvo | pitti: I trigger this now | 08:08 |
| didrocks | good morning mvo | 08:08 |
| mvo | hey didrocks | 08:08 |
| pitti | didrocks: yes, I did (I'm still in Munich) | 08:09 |
| pitti | mvo: danke! | 08:09 |
| didrocks | asac: same than the desktop one /desktop/gnome/background/picture_filename | 08:10 |
| mvo | pitti: is there a problem with the update-manager upload I did some days ago to lucid-proposed? or was there just no time to review it yet? | 08:31 |
| pitti | mvo: I guess the latter | 08:31 |
| pitti | SRU processing is a bit slow ATM, with Steve and me being in other teams now | 08:32 |
| mvo | ok, thanks | 08:33 |
| seb128 | hello there | 08:58 |
| pitti | bonjour seb128 | 08:59 |
| seb128 | pitti, hey, good afternoon to you | 09:00 |
| seb128 | it must be afternoon for you since you have been reviewed binary new 3 hours ago from now ;-) | 09:00 |
| * seb128 hugs pitti | 09:00 | |
| pitti | seb128: afternoon? | 09:01 |
| pitti | heh, got up at 6 :) | 09:01 |
| seb128 | see, 4 work hours = half a day | 09:01 |
| seb128 | ;-) | 09:01 |
| pitti | hehe | 09:01 |
| seb128 | I'm back in winter sleep mode with this weather | 09:02 |
| seb128 | it's windy and rainy and cold | 09:02 |
| pitti | here, too | 09:02 |
| pitti | over the weekend it was quite nice, though | 09:02 |
| didrocks | some sun here :-) | 09:03 |
| didrocks | (a shy one) | 09:03 |
| slomo | seb128: hi :) did you already work on a gtk3 package? ;) | 09:03 |
| seb128 | hey slomo | 09:04 |
| seb128 | slomo, no, and I've no inted to do that before some weeks, lot to do... | 09:04 |
| seb128 | slomo, do you plan to work on those? | 09:04 |
| slomo | seb128: not sure, i don't know what to do with all the gtk module, icons, etc debhelper stuff :) in general the update is easy though | 09:05 |
| seb128 | "easy" | 09:06 |
| seb128 | I'm not sure how transitions will be handle | 09:06 |
| seb128 | we will need gtk2 and gtk3 builds for lot of libraries | 09:07 |
| seb128 | slomo, well doing the packaging of gtk itself would be a first step | 09:07 |
| seb128 | would allow people to try it | 09:07 |
| seb128 | we can deal with themes, build magic, etc later | 09:08 |
| slomo | seb128: well, the gtk package is easy :) dependencies are not, especially because you can't have both gtks in the same process because gtk upstream doesn't like symbol versioning... | 09:09 |
| robert_ancell | seb128, doing the brasero debian merge, the plugins have moved from brasero to libbrasero-media0, do I just need to make libbrasero-media0 replace brasero? Do I need to version the replaces | 09:14 |
| seb128 | robert_ancell, usually << version_with_change | 09:15 |
| seb128 | robert_ancell, have you seen that pitti refused the d-conf binaries? | 09:15 |
| robert_ancell | seb128, does it require the version? | 09:15 |
| pitti | we discussed it | 09:15 |
| robert_ancell | yup, need to discuss with desrt what his plans are regarding versioning | 09:15 |
| seb128 | slomo, btw we will get d-conf uploaded to Debian so no need to duplicate the work | 09:16 |
| seb128 | robert_ancell, you want to version the binaries? | 09:16 |
| robert_ancell | no, I don't want to | 09:16 |
| seb128 | robert_ancell, usually we use versionned replaces because otherwise you will keep replacing files you might now want next time you do a such error | 09:16 |
| pitti | telepathy-mission-control-5: Depends: libmission-control-plugins0 (= 5.5.0-1) but it is not installable | 09:16 |
| pitti | E: Broken packages | 09:16 |
| pitti | hmm | 09:17 |
| robert_ancell | seb128, ah ok | 09:17 |
| slomo | seb128: i know :) thanks for packaging it | 09:17 |
| seb128 | slomo, np | 09:17 |
| seb128 | robert_ancell, pitti: ok, I'm not sure why we just don't get a -bin | 09:17 |
| robert_ancell | I'm not sure if it makes sense to split the binaries and library - I think they are effectively the same thing | 09:17 |
| seb128 | you could say the same for gconf | 09:17 |
| robert_ancell | I need to ask desrt if it will be possible to run two versions in the future | 09:17 |
| seb128 | it's fine to have a -bin | 09:18 |
| pitti | as I said, the d-bus API and library ABI (SONAME) could change independently | 09:18 |
| seb128 | you just need to make the depends strict | 09:18 |
| pitti | so a libdconf-bin seems fine | 09:18 |
| robert_ancell | I don't get it | 09:18 |
| robert_ancell | ok, I'm starting to get it | 09:18 |
| pitti | we need to allow installing libdconf{0,1} in parallel | 09:19 |
| seb128 | not putting the binaries in the library avoid binary conflicts on rename | 09:19 |
| seb128 | so you don't have to uninstall everything which depends on the old soname when installing one rebuild for the transition | 09:19 |
| robert_ancell | and this requires that the binaries will support older versions of the libraries | 09:19 |
| seb128 | it allows nice transitions | 09:19 |
| seb128 | otherwise everything need to be rebuilt together | 09:19 |
| seb128 | no it doesn't | 09:20 |
| seb128 | well it sort of does, but even if that's buggy you don't land in a situations were you need to rebuild everything in one upload run | 09:20 |
| robert_ancell | but you can never have two binary packages installed at the same time | 09:20 |
| seb128 | well you assume that a soname change will break communication between deamon and server | 09:21 |
| seb128 | it could just be changing parameters in a api of the library | 09:21 |
| seb128 | if it does break the protocole it makes no difference | 09:22 |
| seb128 | you have this installability period issue | 09:22 |
| seb128 | but if you doesn't you avoid having to rebuild GNOME in one hour | 09:22 |
| seb128 | since you can rebuild things over time without having to install everything not rebuilt | 09:23 |
| seb128 | so having a -bin might be of no use but is often a win | 09:23 |
| pitti | ah, mission-control was a main/universe problem, promoted | 09:23 |
| seb128 | pitti, danke | 09:23 |
| robert_ancell | are you talking about upgrading the lib package and the binary package at different times? | 09:23 |
| seb128 | not | 09:24 |
| seb128 | I'm speaking about having 60 GNOME binaries depending on libdconf-1 | 09:24 |
| seb128 | then having libdconf-2 coming because desrt changed abi | 09:24 |
| seb128 | in one case both libraries can't be installed together | 09:24 |
| seb128 | since they have same binaries | 09:24 |
| seb128 | so when you get 1 binary rebuild the 59 others will be to uninstall | 09:25 |
| seb128 | or you need to wait for the 60 to be rebuilt to upgrade | 09:25 |
| * robert_ancell draws this out | 09:25 | |
| seb128 | if both libraries can be installed together you don't have that issue | 09:25 |
| seb128 | you can rebuild over time | 09:25 |
| seb128 | since libdconf-1 is still there nothing need to be uninstalled | 09:25 |
| seb128 | well takes | 09:26 |
| seb128 | source1 Depends libdconf-1 | 09:26 |
| seb128 | source2 Depends libdconf-1 | 09:26 |
| seb128 | source3 Depends libdconf-1 | 09:26 |
| seb128 | you rebuild source1 so it depends on -2 | 09:26 |
| seb128 | if -2 conflicts with -1 | 09:26 |
| seb128 | (which it has to do if they have the same binaries) | 09:26 |
| robert_ancell | ok, but this sounds like desirable behaviour to me (rebuilding them all) *if* dconf does not support both libraries at once | 09:26 |
| seb128 | right | 09:27 |
| seb128 | as said you win nothing if it doesn't | 09:27 |
| seb128 | but if it does you win | 09:27 |
| robert_ancell | which is why I want to as desrt before making this change | 09:27 |
| seb128 | it might just be that the customer api change | 09:27 |
| seb128 | but the d-conf protocol doesn't | 09:27 |
| seb128 | ok | 09:27 |
| robert_ancell | because if he doesn't provide multi-versions support you could have 1 package installed using dconf-2 and 59 packages using dconf-1 and not working | 09:27 |
| seb128 | I'm not sure why | 09:27 |
| seb128 | it's either a no difference change or a win | 09:28 |
| seb128 | in which case we could use a Breaks | 09:28 |
| seb128 | and would have to rebuild everything | 09:28 |
| robert_ancell | but if we don't split it the one package would be held back until all 60 could be installed | 09:28 |
| seb128 | but usually libraries soname changes because one function parameter is added or something | 09:28 |
| seb128 | which doesn't break the backend communication | 09:29 |
| seb128 | robert_ancell, if we split that would be the same, we would just have to libdconf-1 breaks libdconf-2 | 09:29 |
| seb128 | or the other way around | 09:29 |
| robert_ancell | which would force only one to be installed right? | 09:30 |
| seb128 | yes | 09:30 |
| robert_ancell | ok, sure | 09:30 |
| seb128 | but as said by experience often the client api is what change | 09:30 |
| robert_ancell | so where does /usr/bin/gconf go (the equivalent of gconftool) - it's not the same sort of binary as the others | 09:30 |
| glatzor | morning mvo! | 09:31 |
| glatzor | mvo, I cleaned up the backend code of updatemanager in the glatzor branch today | 09:31 |
| seb128 | robert_ancell, in a d-conf binary? or ask desrt to version it with the soname | 09:31 |
| seb128 | robert_ancell, so it can go in the library | 09:31 |
| robert_ancell | seb128, then it should have a symlink right? How do you have a symlink that points to the latest version | 09:32 |
| seb128 | no symlink please | 09:32 |
| seb128 | I'm not sure to understand the question there | 09:32 |
| seb128 | ship it in libdconf-bin? | 09:32 |
| seb128 | or d-conf | 09:33 |
| robert_ancell | seb128, there is no d-conf package currently, it would just contain this one binary | 09:34 |
| mvo | hey glatzor | 09:34 |
| mvo | glatzor: sweet | 09:34 |
| mvo | glatzor: did you manage to catch the hang? | 09:34 |
| robert_ancell | seb128, so the dconf project provides a command-line tool which is dependant on a library (which other apps use) which is dependent on a d-bus daemon | 09:35 |
| seb128 | robert_ancell, usually there is libdconf<soname> libdconf-dev libdconf-bin | 09:35 |
| seb128 | you have the lib in libdconf and all the binaries in the bin | 09:35 |
| robert_ancell | seb128, yeah, I'm not sure where the tool should go, it feels more like a libdconf-backend and libdconf-bin | 09:35 |
| seb128 | yeah, maybe better to talk to desrt ;-) | 09:36 |
| seb128 | I'm not sure either | 09:36 |
| seb128 | I think I would do a d-conf binary with the server | 09:37 |
| seb128 | and a libdconf-bin with other random tools if there is some of those | 09:37 |
| seb128 | similar to gvfs | 09:38 |
| seb128 | lib, gvfs, gvfs-bin | 09:38 |
| robert_ancell | seb128, and you were always telling me not to make too many additional packages ;) | 09:39 |
| seb128 | you convinced me otherwise ;-) | 09:39 |
| robert_ancell | touche | 09:39 |
| pitti | (and perhaps the d-bus service?) | 09:40 |
| seb128 | would be with the d-conf binary | 09:42 |
| seb128 | no? | 09:43 |
| seb128 | robert_ancell, btw do you work on pygi as well? | 09:45 |
| seb128 | do you need some help with some update? | 09:46 |
| robert_ancell | seb128, haven't got it working yet. Any spare cycles are welcome :) | 09:48 |
| glatzor | mvo, I haven't seen any hangs | 09:48 |
| mvo | glatzor: ok, even better. maybe its just somehting odd on my system or a tranient failure. I give it a try this morning | 09:49 |
| robert_ancell | seb128, sorry, have to go, I've pushed pygi into my +junk if you want to play | 09:51 |
| seb128 | robert_ancell, ok thanks | 09:51 |
| seb128 | robert_ancell, have fun, see you tomorrow! | 09:52 |
| robert_ancell | seb128, I'll fix up dconf tomorrow morning, but it's in ~ubuntu-desktop/dconf/ubuntu if you want that too | 09:52 |
| seb128 | ok | 09:52 |
| seb128 | I would do it but seems we might have different opinions on it | 09:52 |
| seb128 | since you did the work I will let you change this one as you want rather | 09:53 |
| seb128 | ;-) | 09:53 |
| robert_ancell | and take the responsibility :) | 09:53 |
| seb128 | see you! | 09:53 |
| robert_ancell | ok, really must go | 09:53 |
| seb128 | lol | 09:53 |
| === MacSlow is now known as MacSlow|errand | ||
| mvo | glatzor: hm, if I run a "check for updates" and it returns from the installbackend the UI hangs afterwards. does that work for you? | 10:06 |
| mvo | glatzor: and in a strange way, in a futex() | 10:07 |
| didrocks | seb128: I'm remerging evo on debian, they have a fix for the crasher, apparently | 10:25 |
| seb128 | didrocks, ok, nice! | 10:25 |
| chrisccoulson | good morning everyone | 10:26 |
| pitti | hey chrisccoulson, how are you? | 10:28 |
| chrisccoulson | pitti - i'm good thanks, how are you? | 10:28 |
| pitti | I'm great, thanks | 10:29 |
| ara | chrisccoulson, I am preparing the call for testing for the firefox upgrade | 10:31 |
| chrisccoulson | hi ara - thanks | 10:31 |
| ara | chrisccoulson, hey | 10:31 |
| chrisccoulson | ara - mozilla pushed back the release date for firefox 3.6.4 btw (to 7th june i think) | 10:32 |
| chrisccoulson | which is good for us :) | 10:32 |
| ara | chrisccoulson, I have seen that only hardy seems more or less complete in terms of extensions (in the ppa) | 10:32 |
| ara | chrisccoulson, indeed :) | 10:32 |
| chrisccoulson | ara - yeah, that's right. we discussed on friday and decided that we will do hardy as a priority, and then we have to do karmic and jaunty at the same time too | 10:33 |
| ara | chrisccoulson, OK, when do you want people to start testing (and reporting back) in hardy? is hardy ready to go? | 10:33 |
| chrisccoulson | we were initially going to wait until we upgraded karmic, as firefox 3.5 is still supported, but we realised we would break jaunty -> karmic upgrades if we did that | 10:33 |
| chrisccoulson | hardy is pretty much ready to go, with the exception of a few extensions, so i think people can start testing it | 10:34 |
| ara | chrisccoulson, what about the apps depending on xulrunner 1.9? | 10:35 |
| chrisccoulson | ara - i've still got to port most of those yet (epiphany is done but not uploaded yet, as i've got to upload things in a specific order to make that work, and the builders were taking a long time on friday) | 10:37 |
| chrisccoulson | bit firefox is ready to test now | 10:37 |
| ara | chrisccoulson, OK, I think that I will then concentrate on hardy firefox + extensions. I will finish preparing it and I will pass it to you for review | 10:38 |
| chrisccoulson | thanks | 10:38 |
| ara | chrisccoulson, np | 10:38 |
| chrisccoulson | ara - jdstrand would also like to be involved in any discussions too | 10:38 |
| pitti | chrisccoulson, seb128: for the record, I checked the g-p-m merge with Debian, and there's nothing worth merging | 10:39 |
| ara | chrisccoulson, OK | 10:39 |
| pitti | we'll just keep it as ubuntu packaging | 10:39 |
| seb128 | ok | 10:39 |
| chrisccoulson | pitti - ok, cool. i've not started looking at maverick merges yet ;) | 10:39 |
| seb128 | hey chrisccoulson, how are you? | 10:39 |
| chrisccoulson | hey seb128 - i'm good thanks, but a little sore from gardening yesterday. how are you? | 10:40 |
| seb128 | I'm great! | 10:40 |
| seb128 | had a relaxing weekend ;-) | 10:40 |
| pitti | seb128: I just have three main merges left now (just did a few), I'll see to getting them done | 10:40 |
| seb128 | chrisccoulson, could you let me know when the hardy ppa is ready for testing? | 10:40 |
| seb128 | pitti, ok, nice, thanks! | 10:41 |
| seb128 | pitti, I "stole" some of yours previous week | 10:41 |
| pitti | ah, merci | 10:41 |
| chrisccoulson | seb128 - yeah, can do. did you look at the scrollback too? | 10:41 |
| seb128 | chrisccoulson, reading | 10:41 |
| seb128 | chrisccoulson, rick asked me to send the announce email when things are ready | 10:41 |
| seb128 | chrisccoulson, so basically hardy is ready for testing? | 10:42 |
| chrisccoulson | seb128 - ok. firefox and most of the extensions are ready to test, but there's still a handful of extensions to upload, and i still need to do most of the xulrunner rdepends too | 10:42 |
| seb128 | things which didn't get build yet can come over time right? | 10:42 |
| seb128 | ie we still keep the old xulrunner binaries? | 10:42 |
| chrisccoulson | seb128 - yeah, the new one installs in parallel | 10:43 |
| chrisccoulson | and then once hardy is done, i will get karmic and jaunty done too | 10:43 |
| seb128 | I'm not sure what to do with the announce now | 10:44 |
| seb128 | should we send it when hardy is ready for testing saying that karmic and jaunty will come later? | 10:44 |
| seb128 | or wait for everything to be there? | 10:44 |
| chrisccoulson | seb128 - yeah, we should announce hardy first, and people can test that whilst i'm doing karmic and jaunty | 10:45 |
| seb128 | ok | 10:45 |
| didrocks | seb128: you should have a look at dh-autoreconf package. It seems to do automatically what we want on calling autoreconf for us | 10:47 |
| didrocks | seb128: new e-d-s debian version is using it, I won't add it right now (it's in universe) | 10:47 |
| seb128 | didrocks, is that dh7? | 10:47 |
| didrocks | seb128: from the description, dh7 (not sure of 5), and cdbs integrated | 10:48 |
| seb128 | oh, nice | 10:48 |
| didrocks | "For CDBS users, a rule is provided to call the dh-autoreconf programs at the right time." | 10:48 |
| didrocks | they just add it as a build-dep and include /usr/share/cdbs/1/rules/autoreconf.mk | 10:48 |
| seb128 | didrocks, seems a good one to try | 10:58 |
| seb128 | didrocks, could you drop an email to robert-ancell about it? | 10:58 |
| seb128 | he might be interested | 10:58 |
| didrocks | seb128: sure, and we have then an example with e-d-s retaking what upstream does :) | 10:58 |
| didrocks | seb128: do you want me to make the MIR and try with e-d-s, or let robert_ancell doing it? | 10:59 |
| didrocks | (I'll be in favor of uploading e-d-s now, and then, change the packaging once the tool is MIRED) | 10:59 |
| seb128 | you can do it if you have time | 10:59 |
| seb128 | right | 10:59 |
| seb128 | do the upload now | 11:00 |
| didrocks | ok, I'll see if I have some time today to make the MIR. The changes will be easy to do + dropping an email to robert_ancell | 11:00 |
| seb128 | then it's up to you to see who between you guys want to do the mir etc | 11:00 |
| glatzor | mvo; do you have got a local link to the aptdaemon package inside of your source tree? | 11:00 |
| mvo | glatzor: not sure, I don't think so | 11:00 |
| glatzor | mvo, do you have got any plans regarding the Debian fork of update-manager? | 11:00 |
| didrocks | seb128: sweet, thanks :) | 11:00 |
| seb128 | didrocks, thank you! | 11:01 |
| mvo | glatzor: no plans right now, I would love to use it, but its currently a bit of a time problem | 11:01 |
| mvo | glatzor: and it needs work | 11:01 |
| glatzor | mvo, there is now also an aptdaemon backend lp:~glatzor/+junk/update-manager-aptdaemon | 11:01 |
| mvo | glatzor: oh, cool | 11:01 |
| glatzor | for the debian fork | 11:01 |
| mvo | glatzor: if sp helps with the missing bits (like meta-release support) then I think we can get somewhere | 11:02 |
| glatzor | mvo, but the terminal is not yet supported. requires some API changes since Debian's u-m only allows forking | 11:02 |
| mvo | glatzor: no luck with the hang? it just works for you? | 11:02 |
| mvo | glatzor: aha, ok. does it still need to run as root (I assume no?)? | 11:02 |
| glatzor | mvo, no problems here when I run u-m from my local source tree | 11:02 |
| glatzor | no | 11:03 |
| mvo | glatzor: odd, I really wonder whats wrong on my side then | 11:03 |
| glatzor | no need to run as root | 11:03 |
| mvo | cool | 11:03 |
| glatzor | mvo, by the way I added downloads sub progress support to aptdaemon and the gtkwidgets | 11:04 |
| mvo | glatzor: I check it out after lunch (the debian port of it) | 11:04 |
| glatzor | mvo, you have to currently hard code the aptdaemon backend, since the backendloader is not yet working in update-manager | 11:05 |
| didrocks | mvo: oh btw, I've implemented the dbus backend (just have to handle errors now) for oneconf between two runs. So now the CLI can access to both: direct module inclusion or dbus activated service. (I have to add some cache as some part too) | 11:05 |
| === MacSlow|errand is now known as MacSlow | ||
| mvo | didrocks: nice | 11:06 |
| * mvo is away for lunch | 11:07 | |
| didrocks | mvo: enjoy | 11:07 |
| mvo | thanks | 11:07 |
| glatzor | mvo, see you! | 11:07 |
| mvo | thanks glatzor! | 11:07 |
| huats | morning | 11:31 |
| === popey_ is now known as popey | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | is update-manager known to be broken in maverick right now? | 13:04 |
| seb128 | mvo, ^ do you know? | 13:04 |
| seb128 | it exit on a KeyError: 'days_go' there | 13:04 |
| mvo | seb128: let me check | 13:14 |
| mvo | seb128: not known to be broken | 13:14 |
| desrt | seb128: interesting question | 13:14 |
| mvo | seb128: can you give me the full backtrace please? | 13:14 |
| desrt | seb128: i suppose it makes sense to have the service in /usr/lib/dconf0/... | 13:14 |
| desrt | seb128: since i intend for the protocol to change | 13:14 |
| seb128 | desrt, so you would ship the library and service in the same binary? | 13:16 |
| seb128 | hey desrt btw | 13:16 |
| seb128 | mvo, http://paste.ubuntu.com/442247/ | 13:17 |
| mvo | thx | 13:18 |
| seb128 | mvo, np | 13:18 |
| seb128 | mvo, do you want a bug on launchpad about it? | 13:18 |
| mvo | seb128: no, thanks | 13:18 |
| mvo | seb128: I fix it here | 13:18 |
| seb128 | thanks | 13:18 |
| mvo | commited | 13:20 |
| seb128 | mvo, you rock! | 13:20 |
| mvo | seb128: thanks, btw, is maverick more usable now? for me libgtk in there was a bit unstable and caused all sorts of grief with metacity | 13:20 |
| mvo | I had to downgrade that to the lucid version | 13:20 |
| seb128 | there was no change in this regard no | 13:20 |
| mvo | ok | 13:21 |
| seb128 | I'm using compiz which doesn't have those issues | 13:21 |
| === almaisan-away is now known as almaisan | ||
| mvo | glatzor: it may well be a libglib2.0-0 problem, I'm downgrading that now | 13:35 |
| mvo | glatzor: the hang I see | 13:35 |
| mvo | glatzor: btw, I would like to add support to aptadmon to read/write /etc/apt/auth.conf for key storage. is that ok with you? | 13:35 |
| glatzor | mvo, I would accept a patch. | 13:39 |
| mvo | glatzor: cool, thanks. I will work on it probably this week | 13:41 |
| seb128 | chrisccoulson, ara_: how is the hardy update and call for testing going? Do you think we should send the announce email? | 13:46 |
| * pitti glares at shotwell in disbelief | 13:51 | |
| pitti | yes, ~/2010/05/31 is an excellent path to store my downloaded photos in | 13:52 |
| RAOF | Does the new shotwell handle RAW at all? | 13:53 |
| seb128 | pitti, seems your xdg photo dir is not set correctly? | 13:53 |
| RAOF | Hm. Why is shotwell priority:extra? | 13:53 |
| seb128 | RAOF, I've read a bug report saying it will in next version | 13:53 |
| seb128 | not sure, does the priority makes any practical difference? | 13:53 |
| pitti | seb128: probably | 13:54 |
| RAOF | seb128: I don't think it makes a particular difference. | 13:56 |
| ara_ | seb128, apparently the packages are more or less ready to go. I will try to finish infrastructure for testing today. I will let you know | 13:58 |
| === ara_ is now known as ara | ||
| seb128 | ara, thanks | 13:59 |
| desrt | seb128: yes. | 14:01 |
| desrt | seb128: but i'm not sure how the service could be versioned | 14:01 |
| desrt | seb128: unless we also version the dbus name, which doesn't make sense | 14:01 |
| pitti | desrt: only if it's also going to be changed | 14:01 |
| seb128 | desrt, seems we want a different binary for the service | 14:01 |
| pitti | it certainly shouldn't change together with the soname | 14:01 |
| seb128 | I mean d-conf binary with the server and dbus service | 14:02 |
| pitti | seb128++ | 14:02 |
| pitti | I really wouldn't like to see the dbus backend in the libdconf0 package, it just doesn't make sense | 14:02 |
| mvo | glatzor: yeah, u-m hang fixed, looks like it was a unneeded gtk.gdk.threads_init() | 14:04 |
| desrt | the library has basically zero stability at this point | 14:05 |
| desrt | but i guess by the stable release it will | 14:05 |
| desrt | the dbus protocol has no reason to ever be stable | 14:06 |
| desrt | sort of the same story with glib/gvfs i guess | 14:06 |
| seb128 | desrt, which means we want a d-conf and a libdconf tied to the same versions | 14:10 |
| desrt | is d-conf the /usr/bin one? | 14:10 |
| seb128 | yes | 14:11 |
| desrt | what is that package called? | 14:11 |
| seb128 | which will have the dbus service | 14:11 |
| seb128 | well I'm thinking d-conf | 14:11 |
| desrt | no. that doesn't make sense to me, at all | 14:11 |
| seb128 | which is the server and service | 14:11 |
| seb128 | why not? | 14:11 |
| desrt | i'd put the library and the libexec in the same package | 14:11 |
| desrt | with 'dconf-bin' or 'dconf-tools' (containing /usr/bin/d-conf) separate | 14:12 |
| seb128 | is the binary versioned with the soname? | 14:12 |
| desrt | alternatively: throw it all into one big package | 14:12 |
| pitti | ^ can't | 14:12 |
| seb128 | no | 14:12 |
| pitti | we need to be able to install two sonames in parallel | 14:12 |
| seb128 | we need library to not conflict on soname change | 14:12 |
| desrt | oh ya. that. | 14:12 |
| desrt | hmm. | 14:12 |
| desrt | well, you have trouble with respect to the gsettings backend anyway i guess | 14:13 |
| pitti | /usr/bin/dconf makes sense to have in a separate d-conf package, IMHO | 14:13 |
| desrt | that's definitely unversioned | 14:13 |
| seb128 | but what is the issue having the d-conf with the server and dbus dervice? | 14:13 |
| desrt | because /usr/bin/dconf should not normally be installed | 14:13 |
| seb128 | having a d-conf binary | 14:13 |
| seb128 | well dconf would be in libdconf-bin | 14:13 |
| desrt | ok. that makes sense. | 14:14 |
| desrt | why don't you just version the libexec? | 14:14 |
| seb128 | d-conf would be equivalent to gvfs | 14:14 |
| desrt | /usr/lib/dconf0/dconf-service | 14:14 |
| seb128 | where would be put the dbus service? | 14:14 |
| seb128 | be -> "we" | 14:14 |
| seb128 | I think it makes sense to have it with the actual binary | 14:15 |
| seb128 | we can tight libdconf and d-conf together with depends | 14:15 |
| pitti | desrt: we could, but then we'd also need to version the .service file | 14:15 |
| seb128 | we can tight libdconf and d-conf together with depends | 14:15 |
| seb128 | ups | 14:15 |
| mvo | glatzor: you rock, new u-m with aptdaemon as default is comming now | 14:15 |
| desrt | pitti: hum. | 14:15 |
| pitti | seb128: but then you again break parallel installability | 14:15 |
| * mvo hugs glatzor | 14:15 | |
| desrt | does gvfs have dbus api stability? | 14:15 |
| seb128 | pitti, well I mean the lib could depends on a d-conf recent enough | 14:16 |
| seb128 | desrt, dunno, in practice so far etc, not sure it's a garanty though | 14:16 |
| pitti | seb128: I mean, the old lib wouldn't work any more with a changed dbus api | 14:16 |
| seb128 | etc -> yes | 14:16 |
| desrt | what if you just blurred your eyes? | 14:16 |
| seb128 | pitti, we would use a Breaks then? | 14:16 |
| seb128 | pitti, there is no way around it if the dbus api changes | 14:17 |
| desrt | very few applications will be using dconf, in the end | 14:17 |
| pitti | seb128: right, but then you again defeat the purpose of parallel installability; we can just as well have everything in libdbusX and have the various X conflicts: each other | 14:17 |
| pitti | erm, libdconfX, of course | 14:17 |
| pitti | autofingers.. | 14:17 |
| seb128 | pitti, what I was saying this morning, we do it in a way were we could change the soname and have installability for both | 14:17 |
| * glatzor hugs mvo | 14:17 | |
| glatzor | thanks | 14:17 |
| seb128 | pitti, it pratice over time we could run in both situations | 14:18 |
| pitti | seb128: well, but installability != 'it actually works' | 14:18 |
| seb128 | pitti, no | 14:18 |
| pitti | if there is zero guarantee for dbus api stability, then we have to ship per-soname dbus backends | 14:18 |
| seb128 | we would use a Breaks in that doesn't work | 14:18 |
| pitti | or don't support parallel installability | 14:18 |
| desrt | pitti: that might not be so bad | 14:18 |
| seb128 | but that allow us to do it nicely if soname change but dbus not | 14:18 |
| seb128 | I would start on the basis that the dbus compatibility will stay | 14:19 |
| desrt | pitti: the only two apps that i know of that will use dconf will be part of the dconf source package | 14:19 |
| seb128 | we can use a breaks if required | 14:19 |
| desrt | i guess a more pressing concern is how to deal with glib<->dconf compatibility breaks | 14:20 |
| seb128 | pitti, so you could do a libdconf without soname? | 14:20 |
| seb128 | would | 14:20 |
| pitti | no, we need the soname | 14:20 |
| desrt | i don't think we do | 14:20 |
| pitti | we still need to ensure proper dependencies on soname changes | 14:20 |
| seb128 | right | 14:20 |
| seb128 | desrt, we need to know what needs a rebuild on soname change | 14:20 |
| pitti | i. e. we still need to bump it when the soname changes, and rebuild reverse dependencies | 14:20 |
| pitti | we just need to rebuild everything in lockstep | 14:20 |
| pitti | where "everything" is not that much apparently | 14:21 |
| desrt | "everything" is actually "nothing" | 14:21 |
| pitti | gsettings presumably? | 14:21 |
| desrt | no. the dependency is the other way around there | 14:21 |
| seb128 | desrt, well, same difference, we handle libraries in a coherent way | 14:21 |
| desrt | glib defines the API and dconf implements it | 14:21 |
| pitti | that makes it easier | 14:21 |
| desrt | not really | 14:22 |
| desrt | the glib API is unstable :) | 14:22 |
| seb128 | it shouldn't once you get 2.26 | 14:22 |
| seb128 | no? | 14:22 |
| pitti | ok, then new soname -> libdconf1 Conflicts: libdconf0 would be bearable | 14:22 |
| desrt | still unstable | 14:22 |
| seb128 | hum | 14:22 |
| seb128 | since when is glib not api and abi stable? | 14:22 |
| desrt | it's under a header guard | 14:22 |
| seb128 | I'm not sure that's a path we should go | 14:23 |
| seb128 | we being GNOME | 14:23 |
| seb128 | breaking glib compatibility over time | 14:23 |
| desrt | this is not application compatibility | 14:23 |
| desrt | this is similar to how gtk theme engine api changes over time | 14:23 |
| seb128 | they version the directory where those are installed | 14:23 |
| seb128 | and make clear when compatibility change | 14:23 |
| seb128 | ie they have an abi version in the directory | 14:24 |
| desrt | right. we only have one gio modules directory, unfortunately :/ | 14:24 |
| seb128 | hum | 14:25 |
| desrt | indeed! | 14:26 |
| seb128 | so what about libconf<soname> d-conf libdconf-bin | 14:26 |
| seb128 | the first one has the library only | 14:26 |
| seb128 | d-conf the service and server | 14:26 |
| seb128 | the bin the utility | 14:27 |
| desrt | and we really really really require the soname? | 14:27 |
| seb128 | it's how libraries are packaged over the archive, I'm not sure why you want to change that | 14:27 |
| ara | seb128, I am trying to get IS to point me to the new machine for the ISO tracker. It was moved during Lucid release testing, and it wasn't moved back. I was expecting to track testing there | 14:27 |
| seb128 | ara, ok | 14:27 |
| seb128 | ara: thanks for letting me know | 14:27 |
| seb128 | desrt, why do you install a public library if that's not one? | 14:27 |
| desrt | it is | 14:28 |
| desrt | it's just used by nothing so far :) | 14:28 |
| seb128 | so why don't you want to be shipped as one? | 14:28 |
| seb128 | it | 14:28 |
| desrt | call it dconf-service | 14:29 |
| desrt | and lock it to the version of the lib? | 14:29 |
| seb128 | "it"? | 14:29 |
| seb128 | being? | 14:30 |
| desrt | dconf-service | 14:30 |
| seb128 | what would you call dconf-service? | 14:30 |
| seb128 | the library binary? | 14:30 |
| desrt | no. the dbus service executable and desktop file | 14:30 |
| seb128 | that's what I suggested calling d-conf | 14:30 |
| desrt | right | 14:30 |
| desrt | that would work too i guess | 14:30 |
| seb128 | but I'm fine with dconf-service as well | 14:30 |
| * desrt prefers the more descriptive name | 14:31 | |
| seb128 | I'm just not sure what is your concern with have it | 14:31 |
| desrt | no. it seems fine | 14:31 |
| seb128 | libdconf<soname> dconf-service | 14:31 |
| desrt | and dconf-bin | 14:31 |
| seb128 | tied together with the depends | 14:31 |
| desrt | or -tools or whatever | 14:31 |
| seb128 | and libdconf-bin | 14:31 |
| seb128 | with the tools | 14:31 |
| desrt | i guess 'lib' should be dropped there | 14:31 |
| desrt | but otherwise i guess it makes sense | 14:31 |
| desrt | it just means i need to learn so versioning :) | 14:31 |
| seb128 | ok, thanks | 14:32 |
| seb128 | pitti, ^ | 14:32 |
| desrt | editor can go in dconf-bin, i guess? | 14:32 |
| desrt | (once it merges in-tree) | 14:32 |
| seb128 | right | 14:32 |
| seb128 | the bin can ship anything which is not the lib and service | 14:32 |
| seb128 | by service I mean server and dbus service | 14:33 |
| pitti | seb128: if the .so is in /usr/lib/dconf/ instead of /usr/lib/, that'd be fine; but how do other apps talk to it then? | 14:33 |
| seb128 | pitti, that's not what I suggested | 14:33 |
| seb128 | <seb128> libdconf<soname> dconf-service | 14:33 |
| seb128 | <seb128> tied together with the depends | 14:33 |
| desrt | pitti; if we call it libdconf0 and i learn to do proper versioning it can go in /usr/lib | 14:33 |
| seb128 | <seb128> and libdconf-bin | 14:33 |
| pitti | seb128: I see little point in packaging dconf-service separately if it doesn't have other consumers than the library and no stable dbus API, TBH | 14:34 |
| pitti | since it again breaks parallel installability | 14:34 |
| * desrt head explode | 14:34 | |
| desrt | just so you guys are clear: i'm happy with either way :D | 14:34 |
| pitti | desrt: :) | 14:35 |
| seb128 | ok | 14:35 |
| desrt | as long as 'apt-get install dconf-bin' gets /usr/bin/dconf and the editor | 14:35 |
| seb128 | pitti, well, how would you package those? | 14:35 |
| pitti | the big question is just how much we want and need to support more than one dconf version at the same time | 14:35 |
| desrt | pitti: not. | 14:35 |
| seb128 | pitti, do you suggest using one libdconf<soname> with the non versioned binaries and use conflicts? | 14:36 |
| pitti | if we have "unstable dbus API" + "few rdepends", then we can just ship the dbus stuff in libdconf0 and have the libdconfX conflicts each other; and /usr/bin/dconf could either go into libdconf-bin (if it has reverse rdepends) or just into the lib as well | 14:36 |
| seb128 | pitti, ok, let's do that then | 14:39 |
| seb128 | I don't like much having "Conflicts: libsoname1 libsoname2 libsoname3 etc" ;-) | 14:40 |
| desrt | dconf-editor will depend gtk | 14:40 |
| desrt | so probably we need a separate dconf-bin package | 14:40 |
| seb128 | but with some luck desrt will not change the soname every week | 14:40 |
| seb128 | desrt, right, I will do libdconf<soname> libdconf-dev (lib)dconf-bin | 14:40 |
| desrt | seb128: i'm actively breaking API/ABI without bumping soname as we speak | 14:40 |
| desrt | just so you know :) | 14:40 |
| seb128 | as long as nothing else depends on this abi | 14:40 |
| desrt | nothing yet | 14:40 |
| seb128 | "yet" | 14:40 |
| desrt | once things do, i'll behave | 14:40 |
| desrt | this is part of why i want to get dconf-editor in-tree ASAP :) | 14:41 |
| seb128 | what do you expect will depends on it? | 14:41 |
| desrt | dconf-editor. | 14:41 |
| seb128 | right | 14:41 |
| seb128 | ok, let's do that | 14:41 |
| seb128 | dconf-bin or libdconf-bin? | 14:41 |
| seb128 | dconf-bin I guess | 14:41 |
| seb128 | desrt, pitti: thanks | 14:41 |
| desrt | seb128: thanks to you :) | 14:41 |
| * pitti hugs seb128 and desrt, thanks | 14:42 | |
| pitti | dconf-bin sounds strange, but at this point it's nitpicking :) | 14:42 |
| seb128 | :-) | 14:42 |
| * seb128 hugs desrt and pitti | 14:42 | |
| seb128 | pitti, you like libdconf-bin better? | 14:42 |
| * desrt doesn't like that name :p | 14:42 | |
| pitti | that or just d-conf | 14:42 |
| desrt | dconf-tools works for me | 14:42 |
| pitti | or that | 14:42 |
| pitti | dconf-tools -> editor and /usr/bin/dconf CLI tool? | 14:43 |
| desrt | did you manage the other /usr/bin/dconf, btw? | 14:43 |
| desrt | pitti: yes | 14:43 |
| pitti | sold | 14:43 |
| seb128 | ok | 14:43 |
| desrt | what of the filename conflict? | 14:48 |
| pitti | we could either rename our's to /usr/bin/d-conf or just conflicts: to the old crappy other dconf | 14:49 |
| desrt | second sounds good | 14:49 |
| * desrt needs to pack | 14:52 | |
| seb128 | desrt, pitti: we conflict | 14:54 |
| desrt | it becomes extra funny when you decide that you want dconf-editor hard-depended on by ubuntu-desktop :) | 15:01 |
| didrocks | seb128: FYI bug #587908, the code is pretty simple and seems to do the right thing :) | 15:15 |
| ubot2 | Launchpad bug 587908 in dh-autoreconf (Ubuntu) "[MIR] dh-autoreconf (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/587908 | 15:15 |
| seb128 | didrocks, nice | 15:16 |
| didrocks | seb128: can you please new libedataserver1.2-13 (soname bump)? | 15:16 |
| didrocks | I'll send evolution then | 15:16 |
| didrocks | a non crashy one \o/ | 15:17 |
| seb128 | didrocks, ok | 15:17 |
| didrocks | thanks :) | 15:17 |
| * didrocks hugs seb128 | 15:17 | |
| seb128 | ;-) | 15:17 |
| * seb128 hugs didrocks ;-) | 15:17 | |
| === \vish is now known as vish | ||
| ara | seb128, would you mind reviewing https://wiki.ubuntu.com/Testing/Firefox3.6.4Upgrade? I will send the call when you're done | 16:08 |
| seb128 | chrisccoulson, ^ | 16:09 |
| seb128 | ara, I'm reading it now as well | 16:09 |
| seb128 | ara, should be have somewhat a special tag or something to track bugs on launchpad about this upgrade? | 16:12 |
| seb128 | ara, or do we count on the qa tracker to be enough? | 16:12 |
| ara | seb128, mmm, the qatracker is good to track bugs, but we could add a tag if you wish | 16:13 |
| seb128 | ara, ok, let's use the tracker then | 16:15 |
| seb128 | we can watch new bugs as well | 16:15 |
| seb128 | there is no special need for a tag | 16:15 |
| ara | seb128, mmm, but if they are filing bugs against the ppa, the usual way wouldn't work, would it? | 16:16 |
| ara | (like ubuntu-bug firefox) | 16:16 |
| seb128 | no that wouldn't | 16:16 |
| seb128 | I was rather thinking on how we keep tracking things once the security updates land | 16:17 |
| ara | seb128, ah, ok, but how do we tell people to add bugs if they are testing the ppa? | 16:17 |
| seb128 | those using the ppa can use the tracker, they will probably read instructions | 16:18 |
| ara | OK, so, only the tracker, not launchpad at all? | 16:18 |
| seb128 | yes | 16:19 |
| ara | yes, what? :D | 16:19 |
| seb128 | yes only the tracker | 16:19 |
| seb128 | sorry ;-) | 16:19 |
| seb128 | let's use the tracker for the call for testing | 16:19 |
| seb128 | ie your wikipage looks great | 16:19 |
| ara | seb128, OK, then we need to change the part of filing bugs | 16:19 |
| ara | seb128, I'll change that | 16:20 |
| seb128 | you can let it for the users who want but I guess most will use the tracker | 16:20 |
| ara | seb128, https://wiki.ubuntu.com/Testing/Firefox3.6.4Upgrade?action=diff&rev2=2&rev1=1 | 16:24 |
| seb128 | ara, thanks | 16:25 |
| seb128 | chrisccoulson, ^ works for you? | 16:25 |
| pitti | seb128: do you know how much libpango1.0-0 really needs defoma? I removed it on my small xfce box, and it works just fine; IOW, would you mind if I drop it to recommends? | 16:44 |
| seb128 | pitti, I would prefer not add diff over debian for that | 16:44 |
| seb128 | pitti, otherwise I don't know no | 16:45 |
| pitti | seb128: ok, fine; thanks | 16:45 |
| seb128 | pitti, but could you open a bug on the bts if you do the change? | 16:45 |
| seb128 | pitti, I'm fine having the diff for now | 16:45 |
| seb128 | I would just like to avoid being out of sync for ever due to it | 16:45 |
| pitti | seb128: I can also just file it in debian, and not touch it in maverick | 16:45 |
| seb128 | change it in maverick I would say | 16:46 |
| pitti | it's not urgent, I'm just trying to be a good downstream | 16:46 |
| seb128 | will make easier to run without it for testing | 16:46 |
| seb128 | pitti, hum | 16:46 |
| seb128 | libpango1.0-common.dirs:var/lib/defoma/pango.d | 16:47 |
| seb128 | libpango1.0-common.install:debian/defoma/pango.conf etc/defoma/config | 16:47 |
| seb128 | libpango1.0-common.install:debian/pango.defoma usr/share/defoma/scripts | 16:47 |
| pitti | right | 16:47 |
| ccheney | hmm it appears OOo wants to kick their 3.3 release out by Aug which is < 2mo from their planned branch date, in the past they had trouble doing that without large amount of bugs in < 5 months, hopefully the release won't be a disaster | 16:50 |
| ara | seb128, I need to go out now. I will reconnect in about 3 hours. Please, send me an email with what you decide with chrisccoulson | 16:50 |
| seb128 | ara, ok, thanks | 16:50 |
| === MacSlow is now known as MacSlow|dinner | ||
| chrisccoulson | hi ara / seb128 - sorry, it's been a public holiday here today so i've not been around much | 17:16 |
| chrisccoulson | just checking the scrollback | 17:16 |
| vish | seb128: hi , for the humanity SRU , is there anything else that needs to be done? | 17:19 |
| chrisccoulson | b'ah. i just uploaded the backported epiphany-browser to the PPA, and it doesn't build because it depends on the gnome-keyring version in hardy-updates | 17:21 |
| seb128 | vish, no, it's waiting for somebody to review the queue | 17:21 |
| seb128 | vish, try maybe pinged jdong, slangasek, cjwatson tomorrow | 17:21 |
| vish | seb128: oh , ok , thanks. | 17:21 |
| vish | will do | 17:21 |
| seb128 | chrisccoulson, hey | 17:21 |
| chrisccoulson | hi seb128 | 17:22 |
| seb128 | vish, thanks | 17:22 |
| seb128 | chrisccoulson, so tell me, what is the status for those updates? | 17:22 |
| chrisccoulson | seb128 - firefox and nearly all of the extensions are ready to test, and i started uploading some xulrunner rdepends (blam and the mono bindings are uploaded, and epiphany is uploaded but doesn't build in the PPA). micahg has been working on some other packages which i'm just about to review before i upload them | 17:25 |
| chrisccoulson | but i don't think there's any reason for people not to start testing it now | 17:25 |
| seb128 | chrisccoulson, ok, nice, I will probably send the announcement email tomorrow since ara didn't send the call for testing yet | 17:27 |
| chrisccoulson | seb128 - thanks, i should have even more of it ready by then | 17:28 |
| seb128 | chrisccoulson, you said mozilla delayed the update right? | 17:28 |
| chrisccoulson | seb128 - yeah, it was announced on one of their mailing lists last week, although they haven't updated https://wiki.mozilla.org/Releases/ just yet | 17:29 |
| seb128 | ok, so it gives us some margin for testing | 17:29 |
| seb128 | nice! | 17:29 |
| chrisccoulson | yeah, i'm quite glad too ;) | 17:30 |
| chrisccoulson | i was going to work today, but i thought i could do with a rest when i woke up this morning ;) | 17:30 |
| seb128 | chrisccoulson, did you look at https://wiki.ubuntu.com/Testing/Firefox3.6.4Upgrade? | 17:31 |
| seb128 | chrisccoulson, could you check if it's ok with you? | 17:32 |
| seb128 | pitti, could you reset the desktop team maverick workitems database? | 17:35 |
| chrisccoulson | seb128 - it looks mostly ok. there's a couple of minor errors which i can fix (we're also rolling it out to jaunty and karmic rather than jaunty and lucid, and 3.0.6 should be 3.6.4) | 17:35 |
| seb128 | pitti, the trend line is not really well adjusted but it should be fine starting now | 17:35 |
| seb128 | chrisccoulson, if you could fix the errors that would be nice, thanks! | 17:36 |
| seb128 | TheMuso, should https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-gnome3-accessibility-readiness be tracked for maverick or not? | 17:38 |
| seb128 | chrisccoulson, not for today but tomorrow when it's a work day, I've added a comment on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-chromium | 17:39 |
| chrisccoulson | seb128 - thanks | 17:39 |
| seb128 | chrisccoulson, ie we decided to review the decision at alpha3? (not sure now) | 17:39 |
| seb128 | would be nice to have that in the spec | 17:40 |
| seb128 | chrisccoulson, thank *you* ;-) | 17:40 |
| seb128 | didrocks, hey | 17:43 |
| didrocks | seb128: hey | 17:43 |
| seb128 | didrocks, is getting the new mutter in maverick on your todolist? | 17:43 |
| didrocks | seb128: no, but it can be :) | 17:43 |
| seb128 | didrocks, ok, so it should be now ;-) | 17:43 |
| didrocks | and I guess it is now :) | 17:43 |
| seb128 | didrocks, thanks! | 17:43 |
| didrocks | heh, no pb seb128 | 17:43 |
| seb128 | didrocks, we will need it to update gnome-shell | 17:44 |
| seb128 | didrocks, I figured you are best placed to try if it doesn't break other things | 17:44 |
| seb128 | ;-) | 17:44 |
| didrocks | seb128: sure, I have to see about the patches we have, and so on… so maybe tomorrow morning with a fresh brain and not ubuntu-party+1 day brain state will fit better :) | 17:44 |
| seb128 | lol | 17:45 |
| seb128 | no hurry, whenever you want during the week | 17:45 |
| LaserJock | didrocks: still around? | 18:09 |
| didrocks | LaserJock: not for long, but still there :) | 18:09 |
| didrocks | LaserJock: how are you btw? | 18:10 |
| LaserJock | didrocks: good thanks | 18:10 |
| LaserJock | didrocks: so I just rebooted my computer and .... netbook-launcher is way slicker | 18:10 |
| LaserJock | was that from an SRU? | 18:11 |
| didrocks | LaserJock: yeah, I've added CLUTTER_VBLANK=none | 18:11 |
| didrocks | LaserJock: http://www.clutter-project.org/docs/clutter/stable/running-clutter.html | 18:12 |
| LaserJock | well it's sweet! | 18:12 |
| didrocks | LaserJock: well, that's because netbook-launcher doesn't use any fancy clutter effects :) | 18:12 |
| didrocks | LaserJock: but at least, a lot of people using compiz with netbook-launcher can now without too many issues | 18:12 |
| LaserJock | interesting, so all of that is just from CLUTTER_VBLANK | 18:13 |
| fta | the new python2.6 makes rhythmbox crash in maverick: bug 587589, known? | 18:14 |
| ubot2 | Launchpad bug 587589 in rhythmbox (Ubuntu) "rhythmbox crashed with SIGSEGV in rb_python_module_load_with_gil() after last python2.6 upgrade in maverick (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/587589 | 18:14 |
| didrocks | LaserJock: exactly | 18:15 |
| LaserJock | didrocks: scrolling is interesting | 18:16 |
| didrocks | LaserJock: do you get some bugs with it? | 18:16 |
| === MacSlow|dinner is now known as MacSlow | ||
| LaserJock | well, when I drag the scrollbar it goes opposite | 18:17 |
| LaserJock | it makes sense for a drag-to-scroll | 18:17 |
| LaserJock | but when I drag the scrollbar itself down it goes up | 18:18 |
| LaserJock | basically it looks like the scrollbar doesn't do anything, it just shows you where you're at | 18:19 |
| didrocks | hum, I should have a deeper look there. I don't really see what you are describing, you mean about the left or right scrollbar? | 18:20 |
| LaserJock | right | 18:20 |
| LaserJock | I don't have a left scrollbar | 18:21 |
| didrocks | so, what you drag the scrollbar down, it scroll to show you the items which are in the bottom, right? | 18:21 |
| LaserJock | no | 18:22 |
| LaserJock | it goes up | 18:22 |
| didrocks | your current items goes up and you see those which are downside? (anyway, I'll give it a look tomorrow), almost time for dinner :) | 18:23 |
| LaserJock | well, the scrollbar follows the items | 18:24 |
| LaserJock | but when I drag down the scrollbar goes up | 18:25 |
| LaserJock | and vice versa | 18:25 |
| didrocks | LaserJock: ok, will be nice to fix :) | 18:26 |
| * didrocks goes to get some dinner, see you! | 18:26 | |
| LaserJock | didrocks: see ya | 18:26 |
| didrocks | LaserJock: see you ;) | 18:27 |
| * rickspencer3 throws gtk.TreeView to floor, stomps with boots, pulls out hair | 19:06 | |
| rickspencer3 | grrrrrrrr | 19:06 |
| fta | didrocks, does your last evolution-data-server include the fix for the attchment crash? | 19:14 |
| fta | didrocks, n-m, 2.30.1-5ubuntu1 < 2.30.1.2-3 :( | 19:18 |
| ara | chrisccoulson, hey, thanks for the caught typos in the call for testing wiki | 20:17 |
| ara | chrisccoulson, so, finally, it is going to be tomorrow, isn't it? | 20:17 |
| chrisccoulson | ara - no worries. i added another item to the testing instructions too | 20:18 |
| ara | chrisccoulson, cool, thanks | 20:18 |
| chrisccoulson | i spotted that because the epiphany upload i did depends on a package in hardy-updates, which we're not allowed to do in -security | 20:19 |
| ara | chrisccoulson, nice | 20:20 |
| ara | chrisccoulson, I will coordinate tomorrow with seb128 to send the call for testing | 20:21 |
| chrisccoulson | thanks | 20:21 |
| ara | well, then I call it a day, I just reconnected to see how things were looking | 20:23 |
| ara | chrisccoulson, cheers! | 20:23 |
| * ara doesn't put a face to chrisccoulson and hopes he will update his profile in the directory soon... | 20:24 | |
| chrisccoulson | heh, i keep being reminded about that ;) | 20:24 |
| chrisccoulson | i must get someone to take a photograph of me this week | 20:24 |
| ara | good night! | 20:25 |
| Sarvatt | is there any reason netbook-launcher draws to a window 1 pixel wider than the actual screen dimensions or is it just done to to work around drivers that assume drawing to a window the size of the screen is fullscreen so netbook-launcher gets priority always? one of the intel devs was trying UNE out and had problems with that and asked me about it | 20:58 |
| asac | chrisccoulson: usually self-cell-shot photos are the best ;) | 21:09 |
| === almaisan is now known as almaisan-away | ||
| didrocks | fta: evolution includes the fix, right | 22:24 |
| didrocks | fta: not evolution-data-server | 22:24 |
| didrocks | fta: more exactly, it's a workaround currently, not a proper fix | 22:24 |
| fta | didrocks, i see debian has a patch | 22:25 |
| fta | the workaround was to disable large-file, right? | 22:25 |
| didrocks | fta: yeah, I've integrated both (remerged from debian on e-d-s and evolution for taking it) | 22:25 |
| didrocks | fta: no, it's just checking for NULL pointer | 22:25 |
| didrocks | fta: but that doesn't fix that the pointer is NULL and shouldn't | 22:26 |
| fta | didrocks, ok so the debian bug shouldn't be closed either then | 22:26 |
| didrocks | at least, you can open your emails now without any crash | 22:26 |
| didrocks | fta: right, I've just followed debian closing this bug, I'll still track upstream | 22:26 |
| fta | didrocks, good, thanks | 22:28 |
| fta | didrocks, do you know anything about rhythmbox crashing on startup since the new python landed? | 22:29 |
| fta | didrocks, bug 587589 | 22:29 |
| ubot2 | Launchpad bug 587589 in rhythmbox (Ubuntu) "rhythmbox crashed with SIGSEGV in rb_python_module_load_with_gil() after last python2.6 upgrade in maverick (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/587589 | 22:29 |
| Sarvatt | well at any rate, netbook-launcher using a window 1 pixel larger than the screen resolution kills performance on intel because it makes it allocate buffers 2x larger than otherwise, and he suggested this was a bad choice - "<ickle> using a full 2D gaussian blur instead of 2x1D guassians, and an RLE blur will probably be better with the computer generated elements anyway..." | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!