[08:44] <seb128> hello everybody
[08:54] <ajmitch> hello seb128
[08:54] <seb128> hey ajmitch, it has been a while, how are you?
[08:55] <ajmitch> good, how are you?
[08:55] <seb128> good thanks
[08:55] <seb128> buse as usual ;-)
[08:55] <ajmitch> how's intrepid going?
[08:55] <ajmitch> heh, so am I :)
[08:55] <seb128> intrepid looks good imho, still quite some bugs that would be nice to fix though
[08:56] <seb128> but we are getting there ;-)
[08:56]  * ajmitch was running into a bug recently that was forwarded upstream awhile ago - the missing desktop icons
[08:56] <ajmitch> rather hard to track down what was going wrong there :)
[08:57] <seb128> which one?
[08:57] <ajmitch> bug 218070
[08:58] <ajmitch> race conditions, possibly, pretty much only happened with a cd in the drive
[08:58]  * ajmitch should update to the latest packages first
[08:59] <didrocks> morning o/
[08:59] <ajmitch> hi
[09:00] <seb128> hey didrocks
[09:00] <seb128> slomo: hey, could you look at bug #279800?
[09:14] <slomo> seb128: sure
[09:14] <seb128> slomo: thanks ;-)
[09:15] <slomo> i can't reproduce it though, this needs a backtrace ;)
[09:17] <seb128> slomo: ok, I though the bug was not very useful but that was in case you knew about a similar issue ;-)
[09:18] <slomo> seb128: well, i run banshee since ~2 hours with latest gstreamer today... and many hours yesterday without a single problem ;)
[09:19] <seb128> slomo: maybe the bug is amd64 specific, or maybe you play mp3 and the guy ogg
[09:29] <seb128> asac, lool, pitti: could anybody look to the babl and gegl mir so the new gimp which has been uploaded on monday can build? ;-)
[09:32] <pitti> oh, sure
[09:34] <seb128> pitti: sorry for nagging about this one it would just be nice to give the new version testing before intrepid ;-)
[09:34] <pitti> seb128: no need to be, you are totall yright
[09:36] <pitti> didrocks: FYI, some fields in the MIR aren't filled out, and in "Dependencies" you don't need to specify the binaries of the source package you are filing the MIR on; it should list the dependencies that this package *has*, and whether they are in main
[09:36] <pitti> didrocks: (no problem here, just for the future)
[09:36] <davmor2> seb128: ping me when it's in I'm smoke testing till RC I can play around with it for a bit :)
[09:37] <seb128> ok
[09:38] <seb128> pitti: can I make apport catch any crash on the system easily? ie local binaries ones too
[09:40] <pitti> seb128: not with an option; however, you can hack /usr/share/apport/apport and drop the paragraph on line 258ff
[09:40] <seb128> pitti: ok thanks
[09:40] <pitti> seb128: or just enable core dumps, that might suffice for your needs
[09:41] <pitti> since for unpackaged binaries, there isn't a lot what apport would give you on top of a core dump
[09:41] <seb128> right
[09:41] <pitti> (ulimit -c unlimited)
[10:29] <didrocks> pitti: thx. I will note it :)
[10:46] <Ng> presumably when I plug in a removable storage device and hal sends out the dbus notification, it's nautilus that should pick up on that and mount it?
[10:46] <seb128> who wants to do the totem-pl-parser and totem new version updates?
[10:47] <Ng> (still trying to figure out why my machine at home isn't doing that. hal sees it, sends the dbus notification, and me calling gnome-mount by hand works, so it seems like it's the nautilus stage which isn't working)
[10:47] <seb128> Ng: depending of the device, it should rather ask what you want to do
[10:47] <Ng> seb128: I have Music Player set to Open Folder
[10:49] <Ng> hmm, I didn't actually check if hal was reporting the ipod as an audio player, but it ought to
[10:49] <seb128> Ng: that's working for me, I doubt nautilus is buggy there but maybe it doesn't find the matching properties for the device
[10:50] <Ng> I'm pretty much certain it's something wrong with that install, since it works fine on my laptop
[10:51] <Ng> it would just be nice to be able to debug it enough to fix it, rather than have to apply nuclear reinstall options ;)
[10:52] <Ng> I was able to monitor hal and dbus to ensure they were behaving correctly, but I don't know of a way to do that with nautilus
[10:52] <seb128> Ng: lshal --monitor and plug the device? also lshal > log before and after plugin it and copy the diff somewhere
[10:53] <Ng> I'll give those a try when I get home, but even if it wasn't showing up as an audio player it should still have mounted, right?
[10:53] <Ng> (fwiw it gets an ipod icon, so something clearly knows it's an ipod)
[10:55] <seb128> Ng: not really, the nautilus code filter on properties, it'll do the audio player action only if the right capabilities are set
[10:55] <Ng> but if that capability was missing it would just look like USB storage?
[10:55] <seb128> Ng: what ipod model do you have?
[10:55] <Ng> 80gb classic
[10:56] <seb128> Ng: it can have a correct icon set but wrong capabilities
[10:56] <Ng> hrm
[10:56] <seb128> the icon is also a property
[10:57] <Ng> I wonder if one can manipulate the power state of a USB port such that it seems like a device has been ejected/inserted, because then I could leave the ipod at home and be able to experiment from here ;)
[10:58] <pitti> Ng: I believe that's possible with some fiddling
[10:58] <pitti> Ng: you can use the "bind" and "unbind" sysfs properties to attach/detach the device from the usb-storage driver
[10:58] <Ng> ooh
[10:59] <seb128> slomo: ok, good informations on the gstreamer build issue now
[10:59] <seb128> slomo:
[10:59] <seb128> #0  gst_registry_binary_cache_finish (registry=<value optimized out>, cache=0x0, success=0) at gstregistrybinary.c:353
[10:59] <seb128> 353	    g_remove (cache->tmp_location);
[10:59] <seb128> (gdb) bt
[10:59] <seb128> #0  gst_registry_binary_cache_finish (registry=<value optimized out>, cache=0x0, success=0) at gstregistrybinary.c:353
[10:59] <seb128> #1  0x400b0928 in gst_registry_binary_write_cache (registry=0x92ae808,
[10:59] <seb128>     location=0x92af2a0 "/root/.gstreamer-0.10/registry.i486.bin") at gstregistrybinary.c:841
[11:00] <seb128> #2  0x4004457f in scan_and_update_registry (default_registry=0x92ae808,
[11:00] <seb128>     registry_file=0x92af2a0 "/root/.gstreamer-0.10/registry.i486.bin", write_changes=1, error=0x0) at gst.c:761
[11:00] <seb128> #3  0x400451b5 in ensure_current_registry (error=0xbfecc7d0) at gst.c:823
[11:00] <seb128> #4  0x400468eb in init_post (context=0x9295880, group=0x92962b0, data=0x0, error=0xbfecc7d0) at gst.c:1096
[11:00] <seb128> #5  0x40193803 in IA__g_option_context_parse (context=0x9295880, argc=0x0, argv=0x0, error=0xbfecc7d0)
[11:00] <seb128>     at /build/buildd/glib2.0-2.18.1/glib/goption.c:1796
[11:00] <seb128> #6  0x40045fa6 in gst_init_check (argc=0x0, argv=0x0, err=0xbfecc7d0) at gst.c:434
[11:03] <seb128> slomo: cache=0x0 so cache->tmp_location == crash
[11:03] <slomo> thanks
[11:05] <pitti> Ng: e. g. if you look into /sys/bus/usb/drivers/usb-storage, you have symlinks to the bound devices
[11:05] <pitti> Ng: if you write the name of one of them to "unbind" or "bind", you can detach/attach it
[11:05]  * pitti tests
[11:05] <slomo> seb128: that one is easy to fix... but unfortunately it's only called when something else before goes really wrong
[11:06] <Ng> pitti: nice. I don't want to take up too much time with this though - my busted install isn't yous guys' problem, especially right before a release :)
[11:06] <slomo> seb128: ah... non-writable home? :)
[11:07] <slomo> seb128: could you try again with a patch in a few minutes? :)
[11:07] <seb128> slomo: well, building under a standard user not using sudo so it tries accessing the wrong directory
[11:07] <seb128> slomo: sure
[11:08] <pitti> Ng: echo -n '1-8.4:1.0' | sudo tee  unbind
[11:09] <pitti> Ng: that works for me (in that dir), after doing the same with "bind", the USB stick appears like just being plugged in
[11:09] <pitti> Ng: the -n is important, though :)
[11:09] <slomo> seb128: http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/gst/gstregistrybinary.c.diff?r1=1.36&r2=1.37
[11:09] <pitti> anyway, lunch o'clock
[11:09] <slomo> seb128: if it works i'll upload a new version to debian with this patch ;)
[11:12] <seb128> slomo: that fixed the debuild binary which was breaking, I'll do a full build to be sure next but the patch makes sense and seems to work, new debian revision using it would be welcome ;-) I'm wondering why it didn't break on the debian buildds though
[11:13] <Ng> pitti: cool thanks :)
[11:14] <slomo> seb128: because most of them have writable home... it probably failed on some, i didn't check yet
[11:15] <seb128> slomo: ok
[11:22] <seb128> Ng: let's take this discussion there maybe to not flood #gnome-hackers ;-)
[11:22] <Ng> sure
[11:23] <seb128> Ng: those softwares have gtk fileselectors
[11:23] <Ng> but they don't work very well for this
[11:23] <seb128> why ?
[11:23] <seb128> the patch I pointed just do the transparent mapping to give those applications which don't understand gvfs uris a .gvfs fuse local url
[11:24] <seb128> the gvfs mount is transparently used in this case
[11:24] <Ng> yeah so that patch will fix one of the OOo problems (which is that it does very badly when yo ulaunch it on a remote file)
[11:24] <seb128> when using nautilus or a gtk fileselector
[11:24] <Ng> as I mentioned, firefox3 doesn't seem to show remote shares for whatever reason (and yes, I have failed to file a bug about this since it was brought to my attention on friday)
[11:25] <seb128> so now in which case on a standard ubuntu desktop to you open non local files using something which is not nautilus or a gtkfilechooser?
[11:25] <seb128> that's a firefox bug
[11:25] <seb128> well not really, as said they probably set the fileselector to local mode which made sense in a gnome-vfs context
[11:26] <seb128> since they don't use gnomevfs and were not able to deal with those locations
[11:26] <Ng> in a standard ubuntu desktop that doesn't happen, I have to admit that, but that's simply because everything there is a GNOME app. My point is really that we're spending all this effort dancing around making things work for non-GNOME apps when one change would instantly fix everything
[11:27] <Ng> I could just say "go to Remote/workshare" and it would always work in everything
[11:27] <seb128> what efforts are we doing?
[11:27] <seb128> you can already do that
[11:27] <seb128> what you ask is to symlink .gvfs to some non hidden directory
[11:27] <Ng> not necessarily "we", but someone is patching OOo, firefox, thunderbird to use these things
[11:27] <seb128> the issue is that it adds a directory GNOME users should not have to know about
[11:28] <seb128> what things?
[11:28] <Ng> gvfs
[11:28] <seb128> no
[11:28] <seb128> again, those applications not using gvfs will be given a .gvfs fuse directory
[11:28] <seb128> in a transparent way
[11:28] <Ng> only on launching though
[11:28] <seb128> no application patching is required
[11:28] <seb128> no
[11:28] <seb128> on fileselector use or launching
[11:29] <seb128> how do you open files if you don't use nautilus or a gtkfileselector?
[11:30] <Ng> those are generally the only ways for normal users
[11:30] <seb128> slomo: the patch works fine gstreamer0.10 built correctly
[11:30] <Ng> and if both launching and fileselector stuff will work transparently then that will cure a lot of the problems
[11:31] <Ng> I think it's a shame that it doesn't work in a generic way for non-gnome stuff, but since I'm not putting any code or money in, I don't get a say on that ;)
[11:31] <seb128> Ng: right, that's what the upstream bugs I pointed are about ;-)
[11:31] <slomo> seb128: perfect, thanks for getting a backtrace :)
[11:31] <seb128> slomo: and thanks for fixing it ;-)
[11:31] <seb128> Ng: you are just debating over the .gvfs naming there apparently
[11:32] <seb128> Ng: the upstream view is that GNOME users should not have to know about mounts or mountpoint and not have this extra directory which is confusing
[11:32] <seb128> Ng: the mounts are just listed in the sidebar, place menu, etc
[11:33] <seb128> Ng: I think it's fair to optimize the GNOME user experience for people using GNOME, now if you have an installation where you use lot of non GNOME applications which don't have a gtkfileselector just symlink .gvfs to some other directory
[11:33] <Ng> seb128: nothing would stop the Places menu showing the things that are in ~/Remote/, or the fileselctor sidebar having a section labelled "Remote" which did the same thing
[11:34] <seb128> Ng: right, they just feel that would be confusing rather than bring something to expose the directory
[11:34] <Ng> well I certainly look forward to seeing the patched versions :)
[11:34] <seb128> Ng: because people would then have to understand mountpoint, and why a remote server is a local directory too
[11:35] <Ng> err, but right now all remote servers look like local directories
[11:35] <seb128> Ng: in the current case they don't have remote server showed as local directories
[11:35] <seb128> no they don't
[11:35] <Ng> sure they do
[11:35] <seb128> they are special location in the sidebar
[11:35] <Ng> nobody knows that the sidebar shows bookmarks
[11:35] <Ng> they look like folders, they even have the same icon
[11:35] <seb128> they have drive icons and not folder ones
[11:35] <Ng> nope, because people use bookmarks to get to them
[11:36] <Ng> otherwise they don't persist
[11:36] <seb128> Ng: http://bugzilla.gnome.org/show_bug.cgi?id=555332
[11:36] <seb128> Ng: that gives a connect server feature equivalent to what gnomevfs had
[11:36] <seb128> Ng: we are getting there ;-)
[11:37] <Ng> aha, good :)
[11:37] <Ng> well in that case I might as well pull out my last problem and hope there's a bug for that too ;)
[11:38] <Ng> changing network connections :)
[11:38] <seb128> changing? you mean editing?
[11:38] <seb128> there is a bug but I don't think it's being worked at the moment
[11:38] <Ng> people whip out an ethernet cable and roam onto wireless and gvfs doesn't seem to notice immediately that it needs to discard existing connections and reconnect
[11:38] <seb128> ah
[11:38] <seb128> it should be using network-manager ;-)
[11:39] <Ng> afaik NM sends dbus events when it changes networks, so gvfs ought to be able to notice and reconnect
[11:39] <seb128> right, there is a wishlist open about that
[11:39] <Ng> ok
[11:39] <Ng> well then I'll just go back to my corner and wait ;)
[11:40] <Ng> thanks seb, I feel re-assured that the smart people working on this aren't all mad :)
[11:40] <asac> pitti: langpack o matic ... could we pass 8.04 for hardy exports and 8.10 for intrepid to the po processor?
[11:41] <asac> or is there another way i can easily guess that?
[11:42] <seb128> Ng: you're welcome ;-)
[11:47] <Ng> ooh actually one more thing, but not related to gvfs this time - can we have remote printer discovery enabled by default? :)
[11:48] <Ng> afaics it only opens a port on 127.0.0.1:631, but I dunno if there are other security implications in having cups accepting broadcast traffic
[11:51] <pitti> Ng: opening UDP 631 for discovery is ok, but we need to adapt the GUI printer dialogs accordingly
[11:52] <pitti> Ng: to clearly separate locally configured, trustworthy printers, from the potentially malicious autodetected network ones
[11:52] <Ng> pitti: ah right
[11:53] <pitti> asac: yes, we can pass the release as an extra command line option
[11:59] <asac> pitti: ok. lets look into this after release i guess.
[11:59] <asac> pitti: anyway,  i rolled out the fix for bug 268674 to rookery
[11:59] <pitti> asac: nice, thanks
[11:59] <asac> doing a final test run right now
[11:59] <asac> will let you know in 5 minutes or so
[12:00] <pitti> asac: depends, do you need the 8.04/8.10 argument right now to produce correct updates for both hardy and intrepid?
[12:02] <asac> pitti: we can live without it because ffox is 3.0.x in hardy and intrepid
[12:02] <asac> pitti: only problem is that i cannot have a different whitelist/blacklist for 8.04/8.10
[12:03] <asac> pitti: but that should be OK for now ... unless we get complains now.
[12:04] <asac> pitti: so ... can you do a langpack processing run for intrepid? i got a quick verification from Mirv on the "fi" langpack, but getting broader feedback would be nice :)
[12:04] <asac> pitti: or should i ask Arne?
[12:07] <asac> pitti: i've some strange things going on with NM which I currently think come from consolekit/policykit (havent tracked this down completely). how sure are we that both versions work perfectly together?
[12:10] <pitti> asac: langpacks are handled by Arne now
[12:10] <pitti> asac: but yes, we urgently need new intrepid packs, I spoke about that with Arne
[12:10] <pitti> asac: CK/PK should work fine, they haven't changed recently except for some bug fixes
[12:10] <pitti> asac: CK itself has a few crashes, so if nm doesn't work, it might be due to not having a CK session
[12:12] <asac> pitti: yeah. the crashes definitly struck me :) ... but i still think there is more bustage. but if you dont know anything i will look ... maybe its just a "normal" NM bug ;)
[12:13] <asac> pitti: doesnt console kit persist its session so when it crashes/restarts the session can still be used?
[12:13] <pitti> asac: no, it only keeps them in memory; if you restart CK, all sessions are obliviated
[12:13] <asac> ouch
[12:13] <asac> ;)
[12:14] <pitti> (ouch++)
[12:14] <james_w> hey pitti, on the subject of PK, have you seen bug 275432?
[12:14] <asac> too bad that one cannot propagate environment changes to child processes
[12:15] <asac> so we could at least update the XDG_ session or something
[12:15] <pitti> james_w: no, I didn't; looking
[12:15] <james_w> it's only really a problem in minimal environments
[12:19] <pitti> james_w: right, this circular CK/PK dependency has caused a lot of discussion upstream, but it should only actually matter if you use the shutdown/reboot scripts
[12:19] <pitti> so that dependency isn't reflected as a package Depends:
[12:19] <pitti> james_w: indeed it should complain less verbosely if the PK files aren't present, I think
[12:20] <james_w> yeah, I was thinking that
[12:20] <james_w> it would be possible to write to code so they are still watched by inotify, even if not present
[12:20] <james_w> I'll report it to Debian and upstream today shall I?
[12:21] <pitti> james_w: please do, yes
[12:21] <james_w> sure
[12:21] <pitti> james_w: in fact, I wonder what CK's business is with watching PK's config files
[12:22] <pitti> I don't see a reason why it should do that in the first place, do you?
[12:22] <james_w> no, this is code in libpolkit
[12:23] <james_w> ck calls polkit_context_init() which sets up the watches
[12:23] <james_w> which seems valid to me
[12:30] <pitti> oh, sure, sorry
[13:49] <didrocks> do we need to ask for a build for each gimp plugins? (when libgimp2.0 will be updated to 2.6)
[13:58] <seb128> didrocks: why, is that required?
[14:00] <didrocks> seb128: in my mind, all gimp plugins were rebuilt from libgimp 2.2 -> 2.4 transition
[14:01] <didrocks> (IIRC)
[14:01] <seb128> didrocks: could be that they broke the compatibility then but not between the new versions
[14:02] <seb128> crevette: do you have a sponsoring request bug for your g-u-s update?
[14:02] <didrocks> seb128: ok, that's better if the compatibility is assured :)
[14:03] <crevette> seb128: no
[14:03] <seb128> didrocks: I didn't try but better to look at if things are working before asking for a rebuild
[14:03] <seb128> crevette: you should ;-)
[14:03] <crevette> actually I'm trying to make it work with Bluez 4 at least
[14:03] <crevette> yeah
[14:03] <didrocks> seb128: we'll see on monday (time for all librairies and gimp to be updated and built) :)
[14:03]  * crevette is in a Bluez fury these days
[14:04] <seb128> didrocks: what libraries? the new gimp already built and is in intrepid
[14:04] <seb128> crevette: that's cool but open a sponsoring request if you want your new version update uploaded
[14:05] <crevette> seb128: yeah, just trying the version I'm building in ppa
[14:05] <didrocks> libgimp2.0 will not be updated to 2.6?
[14:06] <seb128> didrocks: ???
[14:06] <seb128> didrocks:
[14:06] <seb128> $ apt-cache showsrc gimp
[14:06] <seb128> Package: gimp
[14:06] <seb128> Binary: libgimp2.0, gimp, gimp-data, libgimp2.0-dev, libgimp2.0-doc, gimp-dbg
[14:06] <seb128> didrocks: a source package can build several binaries if that's the question you are asking there
[14:07] <didrocks> $ rmadison libgimp2.0
[14:07] <didrocks> ... snip ...
[14:07] <didrocks> libgimp2.0 | 2.4.7-1ubuntu1 |      intrepid | amd64, i386
[14:07] <seb128> and gimp?
[14:07] <didrocks> 2.6.0-1ubuntu1
[14:07] <didrocks> oh, for source
[14:08] <seb128> the gimp binary
[14:08] <didrocks> 2.4.7-1ubuntu1 for binary
[14:08] <seb128> it looks like the new binaries have not been published yet
[14:08] <seb128> or that your mirror is lagging
[14:08] <didrocks> yes, probably :)
[14:09] <didrocks> (my company cache is awful, it will not update even if new pages are available)
[14:09] <didrocks> (and I use the archive.ubuntu.com mirror)
[14:10] <seb128> didrocks: weird, the new binaries should be published there, maybe for the next update
[14:11] <didrocks> yes, hence our misunderstanding :)
[15:51] <ember> seb128 mind if i update plparser and tomboy?
[15:52] <seb128> ember: you can do tomboy, somebody is already working on the totem updates
[15:52] <ember> oki, thanks.
[16:11] <slomo> seb128: apart from the banshee crasher new gstreamer stuff works fine?
[16:11] <seb128> slomo: yes, and -3 built fine on i386
[16:11] <slomo> seb128: also, i heard that ffmpeg is in main now... i guess gst-ffmpeg should be in main too then? ;)
[16:12] <seb128> I didn't know that ffmpeg was in main if that's not an error gst-ffmpeg could go there too ;-)
[16:21] <Keybuk> I always think Banshee is almost, but not quite, appropriately named
[16:21] <Keybuk> according to legend, the scream of the Banshee signifies an impending death
[16:21] <Keybuk> whereas any sound from Banshee signifies *its* impending death
[16:30] <dobey> haha
[16:30] <dobey> there is good reason why i use rbox now instead of banshee :)
[16:48] <crevette> seb128: hey
[16:48] <seb128> re crevette
[16:48] <crevette> seb128: did you use NM to connect to GPRS / 3G networks ?
[16:48] <crevette> I would like to test with SFR
[16:48] <seb128> crevette: no, I've no gprs or 3g devices
[16:48] <crevette> ah, I've one on my laptop so I wanted to test
[16:49] <seb128> there is a wiki page about that no?
[16:49] <crevette> I've seen a lot of threads about SFR usb key
[16:49] <crevette> http://forum.ubuntu-fr.org/viewtopic.php?pid=2111610 ah too bad for him
[16:50] <crevette> it seems the 3G usb key works without any tweaks
[16:58]  * crevette is happier and happier of the Linux desktop quality
[17:06] <crevette> asac: around ?
[17:06] <crevette> salut huats
[17:06] <huats> hey crevette
[17:06] <huats> :)
[17:06] <asac> crevette: not really :-P
[17:07] <huats> hello asac :)
[17:07] <huats> and seb128 of course :)
[17:07] <seb128> lut huats
[17:07] <crevette> asac: are you aware of an issue were the button "Ok" keeps unsensitive when you edit parameter of a connection in NM ?
[17:08] <crevette> I try editing my default 3G connection to add parameter but I can't press the button
[17:16] <asac> crevette: usually that means that your settings are not complete
[17:16] <asac> or invalid
[17:17] <crevette> asac: I field all them to test
[17:17] <crevette> I hav one combox empty I don't know why
[17:18] <asac> crevette: which is that?
[17:18] <crevette> band
[17:18] <crevette> not sure if this is the right name in english
[17:19] <asac> crevette: did you use the wizard to create that connection?
[17:20] <crevette> I chose the profile among the list, ibrought pre-defined parameters
[17:20] <crevette> I did that few days/weeks ago, but didn't look closely until today
[17:20] <asac> crevette: ok. then remove the whitespace in your DNS list
[17:20] <asac> thats a bug in the wizard atm (or the applet whatever you like more)
[17:21] <crevette> doesn't change a thing
[17:21] <crevette> I can perhaps delete the profile
[17:21] <crevette> let's do tahr
[17:21] <crevette> that
[17:21] <asac> crevette: no thats not the problem
[17:21] <asac> start nm-connection-editor from terminal
[17:21] <asac> wait till things have settled
[17:21] <asac> then open the connection and see if you see anything
[17:22] <asac> crevette: most likely if you filled all fields you entered something else now that isnt legal
[17:22] <asac> syntax wise
[17:22] <crevette> ehy, I've some warning when starting
[17:22] <crevette> and other when editing the profile
[17:22] <asac> in the beginning it was most likely the dns whitepace
[17:22] <asac> crevette: dont call it profile please
[17:23] <asac> its a connection ;)
[17:23] <crevette> ah sorry
[17:23] <asac> crevette: trash that thing. then create a new onw
[17:23] <asac> and remove the whitespace in dns
[17:23] <crevette> ah this time the whitespace fixed the issue
[17:23] <asac> crevette: right
[17:23] <asac> crevette: and i am sure that when filling the other fields you made another syntax error ;)
[17:23] <asac> obviously a usability issue :)
[17:23] <crevette> are you intereste by some warning at start ?
[17:23] <asac> crevette: paste them
[17:23] <asac> if i am ill tell you :-D
[17:24] <crevette> asac: some icons beside field would be a plus I assume
[17:24] <asac> yeah. but if you start to do that kind of hint, then you also need to add an explanation ;)
[17:24] <asac> and that explanation needs a doc and so on :-D
[17:24] <asac> hehe
[17:24] <asac> but yeah. a icon would be quite nice i guess
[17:25] <crevette> wow taht pastebin plugin for Do is awesome
[17:25] <asac> crevette: pastebinit ... worked for a while for paste.ubuntu.com
[17:25] <asac> not sure if its not broken again :)
[17:27] <crevette> http://pastebin.ca/1222853
[17:28] <crevette> asac: I'm going to open a usability bug for NM upstream
[17:28] <asac> crevette: did you use a VPN connection in the past and now dont have the package installed anymore?
[17:28] <crevette> never I think
[17:28] <asac> crevette: yes, please open in launchpad and in upstream bug tracker
[17:28] <asac> crevette: against -applet
[17:28] <crevette> you want it in launchpad too ?
[17:28] <asac> crevette: i dont mind
[17:29] <asac> crevette: i usually will not receive mail from upstream trackers
[17:29] <asac> (or better said: i will not be able to read them regularly enough)
[17:29] <crevette> ah okay
[17:29] <asac> but its only important in case i have spare cycles and want to fix on my own
[17:29] <asac> so just post upstream
[17:29] <asac> i will proably remember ;)
[17:44] <crevette> asac: http://bugzilla.gnome.org/show_bug.cgi?id=555574 clear enough ?
[17:48] <crevette> asac: it seems the withespace cames back each time I edit the connection
[17:50] <asac> crevette: it comes back?
[17:50] <crevette> yep
[17:50] <asac> if that happens with wired/wireless too its definitly an applet bug
[17:50] <asac> we should file that too ;)
[17:50] <crevette> I don't have dns servers for wired/wireless
[17:50] <crevette> :)
[17:50] <crevette> at least not hard coded
[17:51] <crevette> if I delete and create again my GPRS connection, the space is here
[17:52] <crevette> and moreover the tooltips example has a space :)
[17:53] <crevette> and if I add 2 DNS servers with space between I've the same problem
[17:53] <crevette> it cames back
[17:53] <crevette> « The return of the whitespace »
[17:56] <asac> crevette: you can setup a new wired connection with wired + dns
[17:56] <asac> to test
[17:56] <crevette> asac: yeah it's what I did
[17:56] <asac> crevette: ok. its reproduciable in wired too?
[17:56] <crevette> yep
[17:56] <asac> crevette: http://paste.ubuntu.com/55340/ please test that
[17:57] <asac> i guess that should fix it
[17:57] <asac> let me know. i will send the patch to ML
[17:57] <asac> crevette: you can just apt-get source network-manager-applet ... then apply patch and build with debuild -b
[17:58] <asac> crevette: oh wait ;)
[17:59] <asac> crevette: http://paste.ubuntu.com/55344/
[17:59] <asac> thats the right one
[18:05] <crevette> okay I'll try it
[18:08]  * crevette is lazy and build it in ppa
[18:08] <crevette> cpu cycle is expensive
[18:08] <crevette> :)
[18:09] <asac> well ... ppa makes this test take 1h instead of 3 minutes ;)
[18:10] <asac> given that time is probably more expensive id oubt that this is a good deal :-D
[18:11] <cody-somerville> asac, why does the PPA make it take 1h instead of 3 minutes?
[18:15] <asac> cody-somerville: with some bad luck it takes ages to build. once finished, it take 1-30 minutes to publish
[18:15] <asac> given that one usually forgets to run apt-get update, apt-get instlal constantly one pprobably notices 1h after upload that it can be grabbed ;)
[18:16] <cody-somerville> asac, Why does it take so long for stuff to get built?
[18:16] <asac> cody-somerville: have you ever used the PPA? if you are out of luck you have two linux builds and a xulrunner and a openoffice build before you get cycles ;)
[18:17] <asac> but usually its starts quite instantly
[18:17] <asac> (now)
[18:17] <asac> still you have the huge publishing gab
[18:17] <asac> gap
[18:17] <cody-somerville> Yea, there is roughly 40 or so buildds now for PPAs
[18:18] <cody-somerville> So you don't experience delays anymore starting the build, just waiting for it to publish?
[18:19] <asac> cody-somerville: well. sometimes it takes some time even now
[18:19] <asac> cody-somerville: but publishing is definitly a big issue (at least it was till last week)
[18:19] <cody-somerville> any reason why?
[18:19] <cody-somerville> so its fixed now?
[18:19] <asac> cody-somerville: i think the publisher runs by a cronjob
[18:19] <cody-somerville> ok
[18:19] <asac> now in recent launchpad versions that coupled the publisher run with when things become available in launchpad
[18:19] <asac> so you cannot even grab the .deb before you can find them with apt-get
[18:19] <asac> cody-somerville: no not fixed
[18:19] <asac> i doubt it will be fixed ;)
[18:20] <asac> PPAs are just not made to do a "quick testbuild" ;)
[18:22]  * cody-somerville rubs his chin.
[18:44] <crevette> asac: around ?
[18:45] <asac> crevette: no
[18:45] <asac> :-P
[18:46] <crevette> asac: it works
[18:46] <crevette> I can close the dialog when there is a space between dns servers
[18:46] <crevette> when I open the dialog  the space is back but it is not a pb now
[18:47] <asac> crevette: thats true good.
[18:52] <asac> crevette: ok sent upstream
[18:52] <asac> thanks for testing
[18:53] <crevette> you're welcome
[18:53] <crevette> okay let's take a break
[18:53] <asac> lucky you ;)
[18:53] <asac> but well. i will stop now for a while too :-P
[18:53]  * crevette is more tired during in holidays than during worksdays
[18:53] <crevette> s/in/its/
[22:20] <seb128> didrocks: there?
[22:30] <norsetto> thx for your sponsoring seb128
[22:30] <seb128> norsetto: thank you for working on the updates ;-)
[22:31] <crevette> ah, I nees gnome-user-share sponsoring
[22:31] <crevette> need
[22:35] <seb128> crevette: did you open a bug?
[22:35] <crevette> seb128: not exactly :)
[22:36] <seb128> crevette: so no wonder that people don't sponsor your changes ;-)
[22:36] <crevette> I need to look how work Sponsoring
[22:36] <crevette> but i'm uncomfortable requesting sponsoring for something I can't test
[22:36] <seb128> crevette: just open a bug which has a debdiff and subscribe ubuntu-universe-sponsors
[22:37] <seb128> why can't you test it?
[22:38] <crevette> seb128: sending files over bluetooth doesn't work for me, it seems obex-data-server doesn't work
[22:38] <crevette> s/sending/receipt/
[22:39] <seb128> does the current intrepid version works?
[22:46] <crevette> seb128: no
[22:48] <dobey> seb128: hey. i made a new intltool release today, btw
[22:48] <seb128> dobey: I noticed and it's already in intrepid thank you ;-)
[22:52] <dobey> cool