[07:45] <mvo> asac: abut bug #289396 - is there a way to make firefox *not* do that?
[07:46] <mvo> asac: remove downloaded files opened with a application when ff closes?
[08:34] <crevette> hello
[09:08] <huats> morning everyone
[09:09] <seb128> lut huats
[09:11] <huats> hey seb128
[09:11] <huats> how are you ?
[09:14] <seb128> huats: good, you?
[09:15] <huats> great too :)
[09:15] <huats> I might a little time to do some stuffs today
[09:17] <didrocks> morning huats & seb128
[09:17] <huats> hey didrocks
[09:17] <seb128> lut didrocks
[09:23] <crevette> salut la jeunesse
[09:24] <huats> hey crevette
[09:25] <seb128> lut crevette
[09:25] <seb128> crevette: I fixed the directfb issue, gtk 2.15 might be uploaded today ;-)
[09:26] <crevette> salut huats & seb128 and didrocks
[09:26] <crevette> seb128, hoooo
[09:26] <seb128> I'm test building it now, let's see if there is some other errors
[09:26] <crevette> nice
[09:33] <didrocks> lut crevette
[10:34] <pitti> vuntz: bonjour
[10:34] <pitti> vuntz: what gettext domain field do you use in OpenSUSE in .desktop files?
[10:34] <pitti> vuntz: we have used X-Ubuntu-Gettext-Domain:, since Gettext-Domain: wasn't accepted into the spec
[10:34] <vuntz> pitti: guten tag
[10:35] <pitti> but now I'm discussing a modification of intltool-merge to do this
[10:35] <vuntz> let me check
[10:35] <vuntz> pitti: we use X-SUSE-Gettext-Domain
[10:35] <pitti> in the course of bug 123025
[10:36] <pitti> I have the gconf patch, but the intltool side is still missing
[10:36] <pitti> vuntz: . o O { it's really high time to get this accepted as Gettext-Domain:, duh }
[10:36] <vuntz> pitti: however, in our case, when the key is not present, we default to some domain
[10:37] <pitti> vuntz: with this gconf patch, I'd like to avoid further hacks in our build system and instead integrate it properly into intltool-merge
[10:37] <vuntz> and it turns out that in our infrastructure, we ship all the translations of desktop files in one domain
[10:37] <pitti> and danilo says for that we shoudl make it consistent with .desktop files as well
[10:37] <pitti> oh, surprising
[10:39] <vuntz> for gconf, hrm.
[10:39] <pitti> vuntz: danilos says, we might get X-GNOME-Gettext-Domain: upstream in intltool
[10:39] <seb128> we should use the same one domain trick, that would make easier to translate menu items for translators ;-)
[10:39] <pitti> then we could change our glib etc. packages to look for that in addition
[10:40] <pitti> vuntz: WDYT, would that work for your packages as well?
[10:40] <vuntz> yeah
[10:40] <vuntz> but we should probably sit down and work on a good mail for the xdg mailing list
[10:40] <vuntz> to get the key "upstream"
[10:41] <vuntz> pitti: now I wonder... I modified a bit the ubuntu patch, and killed one or two bugs, iirc
[10:41] <vuntz> pitti: did I send you my version of the patch?
[10:43] <seb128> vuntz: no
[10:43] <seb128> vuntz: you did use a different logic though no?
[10:44] <seb128> vuntz: you were speaking about cleaning the translations in packages and prefering the .desktop strings to the gettext one (ie reversed preference order compared to ubuntu)
[10:45] <vuntz> seb128: ah, yes, we do that
[10:45] <vuntz> I thought you did too
[10:45] <vuntz> don't remember exactly what you do :-)
[10:45] <seb128> vuntz: we just look in gettext before looking in the .desktop for translations
[10:45] <seb128> vuntz: ie language packs have the preference there
[10:46] <vuntz> vuntz@lyon ~/>wc -l /usr/share/applications/totem.desktop
[10:46] <vuntz> 21 /usr/share/applications/totem.desktop
[10:47] <vuntz> seb128: hrm, I need to check in a vm, but how can the user edit the desktop file?
[10:48] <pitti> vuntz: your approach to .desktop is pretty much what I use for gconf translations now
[10:48] <pitti> i. e. kill the existing translations from it and only use gettext
[10:49] <vuntz> nod
[10:49] <pitti> I wouldn't be opposed at all to use the same approach for .desktop
[10:49] <seb128> vuntz: we did patch the edit tools to change the Name= key rather than Name[locale]= if that's the question
[10:49] <pitti> then we'd use the same patch, and can possibly get it upstream
[10:50] <seb128> vuntz: this way the Name doesn't match what is in the gettext translations and the Name is used
[10:50] <seb128> vuntz: I've to admit I like your way
[10:50] <seb128> ie cleaning the .desktops and prefering the translations in those over gettext, that fix corner cases and edition
[10:51]  * pitti summons danilo
[10:51] <vuntz> seb128: ah, yes, I remember now. You already told me
[10:51] <seb128> pitti: what do you need danilo for there?
[10:51] <pitti> danilos: hello
[10:51] <seb128> hey danilos
[10:52] <danilos> hi pitti, seb128
[10:52] <pitti> I was discussing with danilos how to get the corresponiding changes into intltool-merge
[10:52] <vuntz> danilos: DUDE
[10:52] <danilos> seb128: he simply likes me, it's not that he needs me for anything
[10:52] <pitti> i. e. for gconf .schemas, don't put the translation into it, just the domain
[10:52] <danilos> vuntz: hi there :)
[10:52] <seb128> pitti: ok, dobey is the intltool maintainer btw
[10:52] <pitti> and for .desktops, just add X-GNOME-Gettext-Domain: instead of the translations
[10:52] <pitti> seb128: oh, I thought dobey and danilos?
[10:52] <seb128> pitti: +too then
[10:53] <danilos> seb128: you are just badly informed, dude
[10:53] <vuntz> pitti: in your scheme, is it the gconf server or the gconf client that reads the translations?
[10:53] <pitti> but of course I don't like to modify every upstream package's build system to enable that mode
[10:53] <seb128> danilos: every time I ping you about intltool you bounce me to dobey or bugzilla usually!
[10:53] <pitti> vuntz: it has been the server so far, and I kept it that way
[10:53] <danilos> seb128: that's because I am lazy, not because I am not a maintainer ;)
[10:53] <seb128> danilos: I see ;-)
[10:53] <danilos> seb128: or maybe because I am a lazy maintainer
[10:54] <seb128> slacker!
[10:54] <pitti> so I proposed something like INTLTOOL_EXTRA_ARGS=--only-add-domain inltool-merge ...
[10:54] <pitti> then we can define INTLTOOL_EXTRA_ARGS=--only-add-domain in our build systems, and inltool would just append those to its command line
[10:55] <pitti> the new option --only-add-domain would then add X-GNOME-Gettext-Domain: (.desktop)/<gettext_domain> (.schemas) instead of merging translatiosn
[10:55] <danilos> so, we can easily add the option to inltool to allow for something like this to happen, and then gradually extend all the intltool modes to support it
[10:56] <danilos> start with .desktop and .schema ones (so both SuSE and Ubuntu could drop whatever they are using to add X-*-Gettext-Domain) to them
[10:56] <pitti> vuntz: above schema should be what you are doing in suse, and it's what I'd like to do in Ubuntu as well
[10:56] <pitti> (right?)
[10:57] <pitti> oh, hang on
[10:57] <pitti> changing intltool-merge is a PITA
[10:57] <pitti> because for some reasons many upstreams bundle intltool-merge instead of using the system's
[10:58] <seb128> wasn"t that deprecated in some recent version?
[10:58] <vuntz> pitti: hrm, in our setup, we still need intltool to put translation in desktop files. We have a script that handles the part about trimming translations and adding what we want
[10:59] <vuntz> pitti: and unless everybody uses intltool, we'll have to stay this way
[10:59] <seb128> vuntz: why do you need to add those?
[10:59] <pitti> vuntz: that's what we currently do as well, in a cdbs (build system) rule which mangles the .desktop files
[10:59] <vuntz> seb128: that's the way our script works
[10:59] <seb128> vuntz: well, it would only behave this way when using --only-add-domain
[10:59] <danilos> seb128: it was deprecated, but only in a very recent version
[10:59] <pitti> it seems so much cleaner to do it in intlool itself, but if everyone ships ancient copies, that makes it impossible
[10:59] <vuntz> seb128: we wouldn't want to have one way for intltool-powered packages, and another one for other packages
[11:00] <seb128> pitti: GNOME doesn't
[11:00] <pitti> seb128: I looked at gconf and gnome-mount, both do
[11:00] <seb128> vuntz: right
[11:00] <seb128> pitti: weird
[11:00] <danilos> pitti: how old are gconf tarballs? do they make regular releases?
[11:00] <pitti> it's still 2.24.0
[11:00] <pitti> seems we don't have a 2.25 gconf yet?
[11:01] <seb128> I've it on my disk
[11:01] <pitti> seb128: heh, good test how well my patch ports to that :)
[11:01] <seb128> the tarball still has intltool-*.in though
[11:01] <vuntz> yeah, seb128 is slow to package
[11:01] <vuntz> he's getting old
[11:01]  * pitti hugs seb128
[11:01] <danilos> seb128: maybe it has a recent enough intltool, at least?
[11:01] <seb128> vuntz: no, I'm carreful with GNOME changes nowadays rather, too much screwing up there recently ;-)
[11:02] <pitti> danilos: not recent enough to have the feature we are currently planning :)
[11:02] <seb128> vuntz: my gnome-session dialogs look ugly now for example ;-)
[11:02] <vuntz> seb128: I read it, yeah
[11:02] <seb128> IT_PROG_INTLTOOL([0.35.0])
[11:02] <seb128> in gconf
[11:03] <danilos> seb128: that's the minimum version, not indication of what is being used
[11:03] <seb128> they should update to 0.4n
[11:03] <pitti> seb128: dialog> not using the theme, as it seems
[11:03] <seb128> danilos: where do you see the version they used
[11:03] <danilos> seb128: they are all 0 bytes in the tarball I just downloaded
[11:03] <danilos> seb128: you could see it in the file, if anything was there
[11:03] <seb128> danilos: right
[11:05] <danilos> seb128: so, for example, this is the particular feature (not having intltoolize install .in scripts inside the tarball) that Rodney worked on, so he'd have better grasp of that, and I'd likely point you at him :)
[11:05] <seb128> right ;-)
[11:06] <lool> pitti: intlool :)
[11:06] <pitti> lool: ?
[11:06] <pitti> oh, oops :)
[11:07] <pitti> seb128: could you put your gconf 2.25 package somewhere, so that I can port my patch and play with it?
[11:08] <danilos> seb128, pitti, vuntz: however, I believe the best bet is to start on this and get it done in GNOME 2.25
[11:08] <seb128> pitti: I didn't package it yet, I have the tarball only for now
[11:08] <pitti> seb128: ah, ok; nevermind
[11:08] <vuntz> danilos: it's getting late for 2.25
[11:08] <seb128> pitti: http://download.gnome.org/sources/GConf/2.25/GConf-2.25.0.tar.gz
[11:08] <seb128> pitti: you are welcome to do the update if you want ;-)
[11:08] <pitti> seb128: okay
[11:08] <danilos> vuntz: well, for 2.25 intltool at least
[11:09] <pitti> seb128: can as well do it
[11:09] <seb128> thanks
[11:09] <seb128> I'm still fighting gtk 2.15
[11:11] <pitti> seb128: yay, my patch still applies cleanly :)
[11:12] <pitti> seb128: okay, I'll test it and upload it once I'm satisfied
[11:12]  * crevette imagine seb128 as a knight fighting the GTK dragon
[11:13] <seb128> pitti: ok thank you
[11:14] <seb128> crevette: ;-)
[11:15] <pitti> seb128, danilos, vuntz: hm, so in order to get the feature rolled out, would you be mad at me if I used our build sytem rules instead of intltool modifications to change the .schemas files accordingly, until we get the feature into intltool and that lastest version into GNOME tarballs?
[11:16] <seb128> go for it
[11:17] <vuntz> pitti: if you want to test it soon, this makes sense
[11:18] <asac> any clue if its true that "Ctrl-Shift-B" is a reserved key combination in gtk+ ?
[11:19] <asac> mozilla has a comment in code that reads: "# Accel+Shift+A-F are reserved on GTK2
[11:19] <asac> "
[11:19] <danilos> pitti: yeah, just do it, we can integrate it upstream later
[11:20] <pitti> argh, GNOME again took over my F9 to F12 keys
[11:20] <pitti> *nnnng*
[11:20] <danilos> pitti: how are you going to get to your 12-th workspace now?
[11:20] <pitti> I use F9 for vim's pastetoggle, and F11 to get fullscreen in terminals
[11:37] <danilos> btw, I've found that with the new xdev keyboard driver, I get total mess sometimes (and totally unrelated mess on my laptop and my desktop)
[12:07] <tkamppeter> pitti, did you do your SRU session today already?
[12:08] <pitti> tkamppeter: not yet, still working on something
[12:56] <crevette> yeah mighty seb128_ beat the GTK monster
[12:56] <seb128_> crevette: ;-)
[12:56] <crevette> seb128_, I'll look to epiphany this week end of nobody tak it before
[12:56] <seb128_> you just need to talk to it nicely ;-)
[12:56] <crevette> MERCI !!!!
[12:57] <seb128_> crevette: ok, I was maybe going to do it but you can do that if you want
[12:57] <crevette> ah
[12:57] <crevette> as you want
[12:57] <crevette> if you do it I'll have it tonight
[12:57] <crevette> :)
[12:57] <seb128_> crevette: if you want to do it I will not say no ;-)
[12:57] <crevette> okay
[12:57] <crevette> take some rest :)
[12:58] <seb128_> crevette: I've many other things to do and I'm not tired so that's ok ;-)
[12:58] <seb128_> crevette: the update require quite some packaging changes since they stopped shipping the webkit backend in the same tarball
[12:59] <seb128_> crevette: let me know if you think that will not manage to do the required packaging changes
[13:01] <crevette> okay but I'll look it only tonight
[13:37] <kwwii> anyone know how to increase the system font size (trying to increase the size in gdm)
[13:37] <kwwii> ?
[13:42] <pitti> kwwii: shouldn't that be defined in the theme?
[13:42] <pitti> kwwii: I guess the only thing that'd help would be to tell X to use a different dpi, but ICBW
[13:42] <kwwii> pitti: for the labels it respects the size I set but for the text entry, date, clock and button label it doesn
[13:42] <kwwii> 't
[13:42] <kwwii> :-(
[13:44] <kwwii> pitti: I think it gets it somewhere else but I have no idea where
[13:44] <kwwii> and googling for this only results in several people complaining that it doesn't work when set in the theme
[13:58] <soren> asac: Did you get around to doing the firefox plugin database rebuild yet?
[14:03] <dobey> kwwii: i think the entries might have hardcoded size or something silly?
[14:04] <asac> soren: yes. i didnt get to it. you need a package from jaunty right?
[14:05] <kwwii> dobey: lol, I think that the gdmthemetester doesn't respect what is in the theme but gdm itself does
[14:05] <kwwii> I just booted my test system and the text seems larger at least
[14:05] <dobey> that is also a possibility
[14:09] <dobey> kwwii: we should really get rid of that awful dialog in nautilus
[14:11] <kwwii> I can confirm that the font sizes *do* change per theme in the real gdm but not in the gdmthemetester, in case anyone is intersted
[14:11] <kwwii> dobey: which one is that?
[14:11] <kwwii> dobey: oh, btw, I subscribed an icon-naming-utils bug to you today...your first ubuntu bug :-)
[14:12] <dobey> yeah, that's what i'm talking about
[14:12] <dobey> the link is there because evolution used stock_mail-priority-high
[14:12] <kwwii> dobey: yeah, no doubt...I guess the interface needs a rework
[14:12] <dobey> but really, users shouldn't be able to set arbitrary emblems for files
[14:13] <dobey> (tags are not emblems, also)
[14:13] <kwwii> especially because the _m in the name adds a hotkey to m
[14:13] <dobey> brb, i did nautilus --quit to test something the other day, so i need to log out/in
[14:13] <soren> asac: Yes, this is for Jaunty.
[14:17] <dobey> lovely
[14:17] <dobey> my desktop hard locked when i logged out :(
[14:23] <tseliot> kwwii, pitti: does the problem with dpi you were talking about have to do with point 13 of this page? https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-01-20
[14:23] <tseliot> "Try not allowing GNOME Settings Deamon to force DPI of 96, even if overriding value in xorg.cof "
[14:26] <dobey> kwwii: http://wayofthemonkey.com/index.php?date=2008-06-11
[14:26] <dobey> kwwii: see the second half of that blog about tags vs. emblems :)
[14:27] <mvo> seb128: could you please sync gnome-codec-install from debian/experimental?
[14:27] <mvo> (bug #320046)
[14:27] <seb128> mvo: oh yes, sorry I forgot yesterday
[14:28] <mvo> seb128: no problem
[14:30] <pitti> vuntz: gnome bug 568845 FYI
[14:31] <kwwii> dobey: I agree completely with that
[14:31] <vuntz> pitti: yeah, was trying to open it already ;-)
[14:32] <dobey> kwwii: awesome
[14:33] <tseliot> kwwii: please see my question above
[14:33] <vuntz> pitti: I'll look at this at some point. Thanks for working on this!
[14:33] <pitti> vuntz: cheers; my first pet-bug for jaunty :)
[14:34] <dobey> ah man, DPI
[14:34] <kwwii> tseliot: I have no idea - /me just an art fag
[14:34] <dobey> the bane of X
[14:34] <tseliot> kwwii: ok
[14:35] <dobey> that really shouldn't be called DPI in gnome or X
[14:35] <dobey> it should be called "random integer value which somehow screws with the sizes of your fonts"
[14:36] <dobey> in fact, i think i will go file a bug about that label in gnome
[14:36] <tseliot> dobey: ok, let correct the documentation then ;)
[14:36] <tseliot> s/let/let's/
[14:36] <dobey> tseliot: if it was actually DPI, it would behave inverse of how it does now
[14:37] <dobey> increasing the dpi should make the fonts appear smaller, not larger
[14:37] <dobey> there shouldn't be a DPI setting anywhere
[14:37] <tseliot> I didn't know what the symptoms were. This is why I asked
[14:38] <dobey> because it's not like you can somehow magically change the DPI of your monitor
[14:38] <loic-m> dobey: isn't increasing the dpi done to correct the dpi so it matches your screen?
[14:38] <dobey> loic-m: no
[14:39] <dobey> i mean, that's probably the idea
[14:39] <dobey> but it is certainly not the behavior
[14:39] <pitti> seb128: looking at ls -lSr /usr/share/gconf/schemas/, would you mind if I do no-change uploads of nautilus, gnome-power-manager, and metacity, to move them to the new gconf translation system (for testing everything)
[14:39] <tseliot> but you can change what the driver thinks the DPI of your monitor is
[14:39] <loic-m> dobey: I though that was the purpose, since you have other means to make the font/icons bigger
[14:39] <pitti> seb128: well, of course I tested it locally, but large-scale testing -> better
[14:39] <dobey> loic-m: the DPI setting doesn't effect icons, only fonts
[14:40] <seb128> pitti: not at all, just curious but why those? is that for anything using gconf to try?
[14:40] <pitti> seb128: those three are amongst the worst offenders, i. e. their .schema files are biggest
[14:40] <loic-m> dobey: that's because the desktop doesn't have resolution-independence, no? Isn't that what should be fixed in the first place?
[14:40] <seb128> pitti: ie if you have a doubt about breaking things maybe try a random application rather than something running in the standard session
[14:40] <pitti> seb128: https://bugs.edge.launchpad.net/ubuntu/+source/gconf/+bug/123025/comments/4
[14:41] <pitti> seb128: I don't have doubts about breaking nautilus, I tested that locally
[14:41] <dobey> tseliot: well you can change your resolution to something smaller, and use more of those dots on your monitor to represent 1 dot, but you can't really somehow really make it think the dpi is different
[14:41] <seb128> pitti: ok just upload then ;-)
[14:41] <pitti> seb128: but nautilus alone saves us .5 MB .deb size alone, plus another .5 MB in /var on the desktop CD
[14:41] <dobey> loic-m: not really, i think the dpi setting is more an artifact of before Xorg was smart, and because way back in the day monitors were mostly 75dpi, though there were some that were 96dpi
[14:41] <pitti> seb128: after three days of working on this stuff, I'd like to have something to show off ;)
[14:42] <seb128> pitti: do any change you want
[14:42] <pitti> seb128: okay, thanks
[14:42] <dobey> loic-m: these days, X just probes the monitor and gets the value via DDC or whatever
[14:42] <pitti> seb128: (new gconf uploaded, btw)
[14:42] <seb128> pitti: I'm working on intrepid for now
[14:42] <seb128> pitti: thanks
[14:42] <pitti> oh, how come?
[14:42] <dobey> loic-m: ie, "xdpyinfo|grep -i resolution" will give you the screen's resolution, not whatever you set in gconf/xorg.conf
[14:43] <seb128> pitti: doing backports for the samba browsing issue which is broken since hardy
[14:43] <seb128> pitti: the plan is to backport to intrepid now and later to hardy
[14:44] <pitti> ooooh
[14:44] <dobey> loic-m: in fact, i have the gconf setting set to something like 65 DPI
[14:44]  * pitti hugs seb128
[14:44]  * seb128 hugs pitti
[14:44] <dobey> which would mean I should have really huge fonts, if it were actually anything like DPI
[14:44] <tseliot> dobey: well, you can decide whether to use the EDID to compute the DPI of the X screen or not
[14:45] <dobey> tseliot: well it doesn't really matter
[14:45] <dobey> tseliot: your monitors native resolution will never change
[14:45] <tseliot> dobey: there's no doubt about that
[14:47] <dobey> so having some magical configuration is just silly
[14:47] <dobey> because it obviously isn't going to change the hardware
[14:48] <dobey> it should JFW already
[14:54] <loic-m> dobey: there's still time where the monitor has faulty info (I get the problem on a laptop) so the DPI is nice to have. If we want to use the DPI to make the fonts look bigger, shouldn't we use something else?
[14:55] <dobey> if you want to make the fonts look bigger, you should increase the font size i think
[14:55] <loic-m> dobey: The objective would be to have _all_ screens show a 12 font the same size, whetever the DPI, then people that want bigger fonts/icons just say so (and chose to +# the fonts, or set them manually
[14:56] <dobey> ugh
[14:59] <loic-m> s/whetever/whatever
[15:02] <kwwii> indeed point sizes are definite (1/72" is one point)
[15:06] <mvo> pitti: hi, what creates /var/crash? if i install apport in a jaunty pbuilder chroot it is not there
[15:07] <seb128> vuntz: do you do lot of backporting in opensuse? do you know if somebody backported federico fileselector changes to the current stable there?
[15:17] <vuntz> seb128: which changes?
[15:30] <seb128> vuntz: gnome bug #558776
[15:44] <fta2> seb128, could you please have a look at https://bugs.edge.launchpad.net/ubuntu/+bug/242244  I'm not sure where to assign it
[15:52] <pitti> mvo: heh, dpkg -S /var/crash says "update-notifier-common" :)
[15:52] <mvo> pitti: heh :)
[15:52] <pitti> mvo: but usually it is apport's init script
[15:53] <pitti> ./debian/apport.init:[ -e /var/crash ] || mkdir -p /var/crash
[15:53] <pitti> ./debian/apport.init:        chmod 1777 /var/crash
[15:53] <pitti> mvo: (sorry, was on a phone call)
[15:53] <mvo> pitti: right, thanks, that is fine, that expains why its not there in the chroot
[15:53] <pitti> mvo: if it helps you, I just stuff it into the package
[15:54] <mvo> its fine, I was just curious why it was missing there
[15:59] <seb128> fta2: talk to asac, this change is distro specific and has been added because firefox users were complaining about something
[16:00] <fta2> asac, ^^
[16:00] <seb128> fta2: I think the issue was than opening new tabs was moving firefox to your current workspace otherwise or something
[16:00] <seb128> than -> that
[16:00] <vuntz> seb128: we have some patch for this, but I'm not sure it's wroking well
[16:01] <fta2> seb128, imho, the current behavior is seriously broken
[16:01] <seb128> fta2: I think so too but asac made it look like all firefox users would hate us otherwise
[16:02] <fta2> asac, bad asac!
[16:02] <seb128> vuntz: could be the same patch as we have ;-)
[16:06] <asac> fedora has the same i think
[16:06] <asac> gtk has to provide an easy utility function to figure whether the window is on current active desktop or not
[16:07] <asac> so ffox can either call present or something else depending on that
[16:07] <asac> asking all apps to implement that isnt right. i think gedit does implement it and that code should be factored out somewhere so others can use it too
[16:12] <fta2> that won't fix the bug in years :(
[16:14] <asac> i think compiz behaviour is similar to metacity (it was metacity that changed here)
[16:15] <asac> window managers should agree imo if the toolkit doesnt provide a proper abstraction from that.
[16:15] <asac> anyway, i was not the one who didnt like firefox to zoom to current desktop
[16:20] <asac> but let me think abit about it again ... maybe i have other ideas now :) (completely forgot about this topic)
[16:43] <fta2> asac, should I assign the bug to you then?
[17:12] <seb128> pitti: do you have a minute to discuss a bug I want to fix in hardy?
[17:12] <seb128> pitti: bug #236953
[17:12] <seb128> pitti: the issue was a gvfs and http://svn.gnome.org/viewvc/gvfs?view=revision&revision=1974 fixes it
[17:13] <seb128> the change is non trivial though
[17:13] <seb128> pitti: other opinion is http://svn.gnome.org/viewvc/gedit/trunk/gedit/gedit.c?view=patch&r1=6516&r2=6515&pathrev=6516 which is a workaround
[17:13] <seb128> opinion -> option
[17:14] <seb128> pitti: do you think we should try the gvfs fix (it got tested in intrepid and might fix similar issues in some other softwares though gvfs is not used that much in hardy) or rather go with the workaround?
[17:16] <crevette> thanks seb128 to have include the extensive upstream changelog in the gtk update
[17:17] <seb128> crevette: is that an ironic comment? ;-)
[17:17] <crevette> no no no
[17:18] <crevette> I know this is not always easy to paste it, usually I have to format the sentences to fit well
[17:20] <crevette> wonderful epiphany depends on gtk-2.15.1
[17:20] <seb128> there is no such tarball yet
[17:21] <crevette> yeah I know, I'm asking on #epiphany
[17:23] <kwwii> hrm, which package is missing when I get this error: debian/rules:5: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory
[17:23] <kwwii> when running debuild
[17:23] <pitti> seb128: eww for the gvfs patch...
[17:23] <seb128> pitti: ok, you are for the gedit workaround too ;-)
[17:23] <pitti> seb128: the gedit one seems much safer?
[17:24] <seb128> yeah, I'm not sure why I asked, that seemed obvious to me too ;-)
[17:24] <pitti> seb128: so currently it is impossible to use ssh locations with gedit? it alwasy crashes? or just sometimes?
[17:24] <pitti> if it isn't that bad, then we perhaps shouldn't fix it in an SRU at all
[17:24] <seb128> pitti: when you play with the fileselector buttonbar to switch between directories it often crash
[17:25] <seb128> pitti: some users complained because it crashes with their modifications when they try to pick a directory where to save their work
[17:26] <pitti> seb128: right, for an editor that's especially bad
[17:26] <seb128> pitti: let's do the one liner workaround
[17:26] <pitti> I wouldn't be too concerned if it sometimes crashes nautilus, for example, since that will just restart itself and not damage documents
[17:26] <pitti> seb128: right
[17:26]  * pitti hugs the Gnome"fixit"minator
[17:27]  * seb128 hugs SRUapprovator ;-)
[17:38] <didrocks> Gnome"fixit"minator, SRUapprovator… quoted ^^
[17:44] <crevette> can someone confirm  that browsing "Windows network" in network in nautilus spawn an error
[17:44] <crevette> in jaunty
[17:44] <seb128> no
[17:45] <crevette> I have a lot of messages "tdb(unnamed): tdb_open_ex: could not open file /var/run/samba/unexpected.tdb: Aucun fichier ou dossier de ce type"
[17:45] <rugby471> hi guys, I have a problem, we are trying to fix a bug in xsane (ugly menu icon) and so we have chnaged the xsane.desktop file to have
[17:45] <rugby471> Icon=scanner
[17:45] <rugby471> rather than
[17:45] <rugby471> Icon=xsane
[17:46] <rugby471> this way it uses gnome-icon-theme's generic scanner icon
[17:46] <rugby471> however a tester is having a problem
[17:46] <rugby471> he has gnome-icon-theme installed, we can even see the scanner icon in the crrcet directory
[17:46] <rugby471> however it comes up with the gtk-0missing-image
[17:46] <rugby471> icon in the menu
[17:46] <rugby471> anyhelp?
[17:54] <seb128> re
[17:54] <seb128> crevette: what do you do exactly to get the error?
[17:54] <crevette> seb128: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/320547
[17:55] <crevette> I don't know if could be an upstream bug
[17:55] <seb128> crevette: could you open it on bugzilla too?
[17:55] <crevette> okay
[17:55] <seb128> crevette: it's for sure an upstream bug we have to patch to that code in jaunty
[17:55] <seb128> crevette: does smbclient works correctly?
[18:03] <crevette> seb128: do you know what are the switch to put to mimic gvfs ? I did a -L -W WORKGROUP -N but I am not sure this is good
[18:23] <seb128> crevette: use smbtree to browse the network
[18:25] <crevette> smbtree doesn't spawn error
[18:29] <seb128> does it list your workgroups and machines correctly?
[18:38] <crevette> I have no server active now
[18:38] <crevette> but even without server I surprised it spawn an error
[18:38] <crevette> I'll start it now, and see what happen
[18:38] <crevette> it = my server
[18:41] <asomething> seb128: Hi, I've got e-d-s packaged (Bug #320299) but ran into a problem with evo (Bug #320329)
[18:41] <asomething> seb128: for some reason the lp integration patch makes evo FTBFS, but it looks fine to me. I don't get it....
[18:43] <seb128> asomething: hi, I was looking at your eds upgrade, there is some issues
[18:44] <asomething> seb128: ya, i haven't tested at all since evo isn't building
[18:44] <asomething> seb128: let me know and i'll clean it up
[18:44] <seb128> asomething: there is no soname change in this version, not sure why you did one on the binaries
[18:46] <asomething> configure.in shows shows version bumps
[18:47] <asomething> seb128: i don't have much experience packaging libs, so this is a bot of a learning experience for me
[18:48] <seb128> asomething: that's a good exercise ;-)
[18:48] <seb128> asomething: the soname is the number after the .so in the installed library
[18:49] <seb128> asomething: evolution-data-server-2.25.5/debian/tmp/usr/lib/libebook-1.2.so.9.2.0 for example is libebook1.2-9
[18:50] <asomething> seb128: i assumed that if the FOO_CURRENT=# changed in configure.in the soname changes
[18:50] <seb128> asomething: the soname is basically current -age numbers
[18:52] <seb128> asomething: to request sponsoring you can subscribe ubuntu-main,universe-sponsors to the bug
[18:53] <asomething> seb128: ya, i din't want to subscribe sponsors untill I had both ready
[18:53] <seb128> asomething: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html if you want details about packaging libraries
[18:54] <seb128> asomething: the evolution build issue, it seems the configure is not correctly updated, what did you do to update the autoconf changes?
[18:54] <asomething> seb128: I ran autoreconf
[18:55] <seb128> asomething: where? in the source? or you use cdbs-edit-patch to update it?
[18:56] <seb128> asomething: it seems than the lpi changes were not applied when you ran autoconf which leads to the error
[18:57] <asomething> seb128: i think i see now, the lpi patch wasn't actually applied yet when autoreconf was run
[18:57]  * pochu waves!
[18:58] <asomething> seb128: thanks for the pointers, i should get this done pretty soon
[18:59] <pochu> asac: know what? I've found another broken thread, but this time it's not TB's fault. Looks like GMail is mangling the References when they contain "[]" ;)
[18:59] <pochu> (I think the mangled mail was sent using GMail, but am not sure)
[19:01] <seb128> hey pochu
[19:01] <pochu> hi seb128 :)
[19:01] <seb128> asomething: thank you for the work, that's quite some comments and things to learn in the same time so if you have question feel free to ask details
[19:01] <pochu> bah, gtg
[19:01] <pochu> bbl
[19:02] <seb128> pochu: you basically need to undo your soname changes for e-d-s and update the breaks version so e-d-s and evo are updated in the same run for users, otherwise the e-d-s upgrade would break evolution
[19:02] <seb128> ups
[19:02] <seb128> asomething: ^ the comment is for you
[19:03] <asomething> seb128: got it, =)
[19:03] <seb128> asomething: not sure how you edit the autoconf patch but go in the source directory, run cdbs-edit-patch patchname, run autoconf, remove the .cache directory it creates and exi
[19:04] <seb128> exi -> exit
[19:04] <seb128> when closing the cdbs-edit-patch environment the patch is updated
[19:04] <seb128> if the previous version doesn't apply just move it away before running cdbs-edit-patch
[19:09] <asac> pochu: did the patch work for you?
[19:35] <pochu> asac: I tried to applied to TB 2 but didn't build
[19:35] <pochu> asac: well, Icedove 2 ;)
[19:37] <asac> heh
[19:37] <asac> pochu: did it apply cleanly?
[19:39] <pochu> asac: nope
[19:40] <pochu> asac: http://pastebin.com/f68536176
[19:40] <pochu> asac: it failed because of the getter_Copies() argument IIRC
[19:41] <pochu> asac: if you want I can build it again and paste you the error.
[19:42] <asac> pochu: search for GetMessageId
[19:42] <asac> in the file
[19:42] <asac> there probably is other use of it
[19:42] <asac> and you should find the right pattern
[19:42] <asac> or wait
[19:42] <asac> let mec heck ;)
[19:43] <asac> pochu: on 1.8 brach they seem to use nsXPIDLCString messageId;
[19:43] <asac>  isntad of nsCString
[19:43] <asac> give that a try
[19:44] <asac> the GetMessageId invokation stays the same then
[19:44] <pochu> yeah that was one of the suggestion from the compiler
[19:44] <asac> likd http://mxr.mozilla.org/mozilla1.8/source/mailnews/db/msgdb/src/nsMsgHdr.cpp#803
[19:44] <asac> pochu: ^^
[19:44] <asac> ;)
[19:44] <asac> like there
[19:44] <pochu> cool :)
[19:44]  * pochu tries that
[19:45] <asac> but i think maybe we should really fix the threading algo
[19:45] <asac> so even already indexed stuff gets fixed
[19:45] <asac> but well ... in this way all new mail gets fixed
[19:45] <asac> or removing .msf index caches
[19:45] <pochu> is it safe to remove those?
[19:46] <pochu> ok, building
[19:47] <maxb> It loses message flagging and view settings, IIRC
[19:47] <maxb> at the very least
[19:48] <pochu> I don't use flags for bugmail :)
[19:48] <pochu> there's also the possibility to rebuild the index, I guess
[19:48] <pochu> in the folder properties
[19:50] <maxb> safer
[19:59] <asac> pochu: i think its safe ;) ... but better backup your profile
[19:59] <asac> i think for imap it will redownload stuff ... for pop and so on it will recreate the indexes
[20:21] <pochu> oh noes!
[20:21] <pochu> fscking lintian!!
[20:22] <pochu> so, I have a hook to run lintian after the build in pbuilder, and it exits with nonzero when it finds a lintian error
[20:22] <pochu> and that makes pbuilder fail the build and not save the .debs!
[20:22] <asac> pochu: rebuild index i dont know ... compact folder soes something similar
[20:22] <asac> but not everything i think
[20:22] <asac> pochu: bad pbuilder ;)
[20:23] <asac> use a dedicated chroot ;)
[20:24] <pochu> hehe
[21:23] <pochu> asac: \o/
[21:24] <pochu> asac: http://emilio.pozuelo.org/~deb/bz474790_reference_itself_breaks_threading, feel free to apply it to icedove/tb2 ;)
[21:25] <asac> cool ;)
[21:25] <asac> i will wait on upstream decision ...
[21:26] <pochu> fine
[21:26] <pochu> I hope the launchpad folks fix this soon
[21:34] <seb128> crevette: there?
[21:34] <crevette> yep
[21:35] <crevette> playing with my wii
[21:35] <crevette> :)
[21:35] <seb128> what game? ;-)
[21:35] <seb128> crevette: you still want to do the nautilus-sendto changes?
[21:36] <crevette> pperhaps tomorrow morning
[21:36] <crevette> seb128: why?
[21:36] <seb128> crevette: just to know if I should try to find somebody interested in that or if you are
[21:36] <seb128> crevette: no hurry ;-)
[21:37] <crevette> I need to check out the comments you did yesterday
[21:38] <seb128> crevette: basically rename the source to nautilus-sendto-universe, make it build everything and ship only the things which are not in nautilus-sendto in a nautilus-sendto-universe binary
[21:39] <seb128> so having nautilus-sendto and nautilus-sendto-universe installed would be similar to have a normal install
[21:41] <Nafallo> haha!
[21:42] <Nafallo> seb128: are you still discussing that since yesterday? :-D
[21:42] <seb128> Nafallo: not still but again rather ;-)
[21:42] <Nafallo> seb128: thank god :-)
[21:42] <Nafallo> haha
[21:42] <seb128> I was just giving a gently reminder to crevette before running away from IRC and work for the weekend ;-)
[21:43] <Nafallo> seb128: tsss :-)
[21:43] <seb128> anyway enough for today, see you next week everybody
[21:43] <crevette> see you
[21:45] <crevette> okay bon week
[21:45] <seb128> see you later
[21:45] <crevette> end
[21:45] <seb128> to you too ;-)
[22:20] <chrisccoulson> hey crevette - thanks for the advice regarding the ntfs-3g version numbering scheme change yesterday
[22:21] <chrisccoulson> i spoke with the upstream debian maintainer and sorted it out
[22:22] <crevette> chrisccoulson: how did he solved that?
[22:22] <crevette> (hello by the way)
[22:22] <chrisccoulson> he's not incrementing the epoch for the new version when he packages it, because "2009" is greater than "1".
[22:22] <chrisccoulson> it's a good job i asked, because I was going to assume that he would increment it
[22:23] <crevette> ok sounds normal then
[22:25] <chrisccoulson> yeah, it's pretty reasonable. the upstream maintainer of ntfs-3g is quite keen for us to ship the new version now, as we ship a really old version and ubuntu users keep reporting problems upstream that have been fixed several releases ago.
[22:26] <crevette> hey andreasn
[22:26] <andreasn> hi crevette
[22:26] <crevette> sad news I can't change the statusbar shadow, the property is read only in gtk
[22:27] <crevette> it's up to the theme to implement the statusbar looking, I don't understand the rationale for that :/
[22:30] <andreasn> oh
[22:30] <andreasn> not much to do I guess
[22:31] <crevette> yeah, except rewriting a custom statusbar for gtk
[22:31] <andreasn> how does f-spot do it? is it just that it doesn't use a regular statusbar?
[22:31] <crevette> wich is out of my capabilities
[22:32] <crevette> I guess this is not a Gtkstatusbar but a widget derivated from it (my coding fu is near zero, so this is justguess)
[22:32] <andreasn> ok
[22:32] <Amaranth> cp gtkstatusbar.[c-h] ~/myproject ;)
[22:33] <andreasn> hehe
[22:37] <dobey> statusbar doesn't have shadows
[22:40] <crevette>  the border is not a shadow ?
[22:43] <dobey> it sets a shadow type to SHADOW_IN that is drawn by the parent widget type, which is a GtkHBox, from what i can see
[22:50] <dobey> actually looking at the code, i'm not sure /where/ that rectangle with SHADOW_IN gets drawn really
[22:54] <andreasn> dobey, hello, my favorite gnome-icon-theme maintainer
[22:54] <dobey> hi andreasn
[22:54] <andreasn> :)
[22:54] <dobey> what's up?
[22:55] <andreasn> as jimmac said it was ok to relicense his parts of tango-icon-theme (still fixing the metadata stuff btw), would it be ok to use the same spinner icon in gnome-icon-theme as well?
[22:56] <andreasn> mpt bugged me about it again :)
[22:56] <andreasn> and that would fix http://bugzilla.gnome.org/show_bug.cgi?id=558367
[22:57] <dobey> andreasn: if he wants to make it PD, then sure i guess, go for it
[22:57] <andreasn> cool, I'll put it in svn then
[22:57] <dobey> bbiab
[23:29] <pochu> reading launchpad bugmail in threads is just *awesome*