=== ubott2 is now known as ubottu
=== asac_ is now known as asac
[08:24] <asac> rickspencer3: so connman should be there at https://edge.launchpad.net/~network-manager/+archive ... wanna pre-test?
[08:24] <asac> install connman-gnome
[08:26] <rickspencer3> with Add/Remove..., right ;)
[08:26] <rickspencer3> does it replace NM?
[08:28] <asac> rickspencer3: no i didnt do that yet. so you probably have to stop NM to use it
[08:28] <rickspencer3> asac: tx
[08:29] <asac> rickspencer3: i dont think yo uwill find that in add/remove; just run sudo apt-get install connman-gnome
[08:29] <rickspencer3> asac: yeah, I was j/k, as per our conversation last night with Olly ;)
[08:30] <asac> hehe
=== crevette__ is now known as crevette
[08:37] <crevette> hello
[08:37] <crevette> what is the purpose of connman-gnome?
[08:37] <crevette> I guess connman is for Connection Manager ?
[09:02] <asac> crevette: yes. wanna try? its not really production quality, but wired and wireless should work. maybe even bluetooth :)
[09:02] <asac> crevette: intel connection manager that is
[09:02] <crevette> asac, so it does the same job than NM ?
[09:03] <asac> crevette: yes. its ment to be a replacement
[09:03] <crevette> asac, but just for mobile platform or for desktop also ?
[09:05] <asac> crevette: also for desktop
[09:05] <crevette> do you know what is the point of rewriting another connection manager ?
[09:05] <crevette> I give it a try this week end if I remember to do so
[09:06] <asac> not invented here syndrom?
[09:06] <asac> not sure
[09:06] <pochu> crevette: so we can choose ;)
[09:06]  * pochu waves btw
[09:06] <asac> i think marcel - who did this - disagrees with NM maintainer on a few fundamentel things
[09:06] <crevette> asac, ah this is marcel who wrote it
[09:06] <asac> yeah
[09:06] <crevette> that why it uses libgbus
[09:07] <crevette> :)
[09:07] <asac> crevette: it doesnt actually ;)
[09:07] <crevette> libgdbus
[09:07] <asac> it used it ... i packaged it ... and then i found that the build doesnt really pull that in
[09:07] <crevette> :)
[09:07] <asac> not sure why he dropped that. maybe i am just missing something
[09:08] <crevette> I didn't know marcel was worjing for intel
[09:08] <didrocks> morning everyone :)
[09:12] <pochu> hi didrocks :)
[09:13] <didrocks> hey pochu
[09:14] <didrocks> seb128: I think the split for evince is ok. I worked on it yesterday. Just need now to complete the changelog (what I will do this afternoon)
[09:15] <didrocks> seb128: if you have another updates that I can handle during the week-end (even if there is this FOSDEM event), do not hesitate
[09:16] <seb128> didrocks: I think we are mostly uptodate now
[09:17] <didrocks> seb128: oki. So, I will just bzr push this afternoon evince package
[09:18] <rickspencer3> pitti: ping
[09:18] <seb128> didrocks: ok thanks, I might not have time to review it today, do you want quick comments now?
[09:19] <didrocks> seb128: it is on my laptop at home, so, I don'tt have it right now (I go back home at 1PM). But I have some questions:
[09:19] <didrocks> gconf was stored in /usr/share/gconf/ but upstream put it in /etc/gconf (automagically handled?) -> I kept it in /usr/share/gconf/. Is it right?
[09:19] <seb128> right
[09:19] <didrocks> most of packages seems to put the gconf there
[09:19] <seb128> dh_gconf should move it automatically
[09:20] <seb128> etc is a sysadmin directory so we don't store schemas there
[09:20] <didrocks> that's what I read :)
[09:20] <didrocks> Do I have to remove zlib1g-dev lib-dep on evince (don't know if other components, inside evince, needs this) as it is needed by libevview-dev & libevdocument-dev. It's more a theorical question as evince depends on libevview-dev (and libevdocument-dev) which depends on zlib1g-dev
[09:21] <pochu> didrocks: if configure.in requires it, don't drop it
[09:21] <pochu> it's a bad idea to rely on dependencies of your dependencies, as those may change ;)
[09:21] <seb128> didrocks: build-depends or depends?
[09:22] <didrocks> pochu: configure.in requires it for the librairies. But those librairies are built from the same source package.
[09:22] <didrocks> seb128: build-depends
[09:22] <seb128> didrocks: why do you want to change the build-depends? those are for the source the binary split should make no difference
[09:23] <didrocks> seb128: yeah, I just have to duplicate it on libevview-dev depends (what I have done)
[09:24] <didrocks> so that people who will use libevview-dev, can build successfully something with it
[09:24] <didrocks> (only what is in NEEDED section of objdump -p)
[09:25] <seb128> didrocks: you just said you were speaking about build-depends
[09:25] <seb128> you seem to be confused
[09:25] <seb128> build-depends are things which need to be install for evince to build
[09:25] <seb128> depends are things which should be installed with a binary
[09:26] <didrocks> seb128: yes, I didn't have the control file in front of me, and thought of b-d
[09:26] <seb128> look to the requires line in the .pc to know what the library requires
[09:26] <didrocks> it's ok in my mind now :)
[09:26] <pochu> we should invent a ${pkgconfig:Depends} mechanism for -dev packages' depends
[09:26] <didrocks> seb128: is it better than objdump -p the .so
[09:26] <seb128> pochu: I think lool did that a while ago
[09:26] <pochu> oh, did he?
[09:26] <pochu> that would be pretty cool
[09:27] <pochu> lool: hi :)
[09:27] <lool> I think I imaginated doing it :)
[09:27] <seb128> didrocks: objdump is runtime and what ${shlib:Depends} does for you
[09:27] <lool> Some years ago
[09:27] <pochu> heh
[09:27]  * pochu adds that to his 'wish-to-do' list ;)
[09:27] <lool> pochu: I'm happy to review a new dh_foo you would write though
[09:27] <pochu> lool: does it need to be in perl?
[09:27] <seb128> didrocks: there is a difference between what the library uses at runtime and what you need to build using the library
[09:27] <lool> pochu: It would make sense to add it to debhelper, so IMO yes
[09:28] <pochu> lool: so I now have an excuse to learn perl ;)
[09:28] <seb128> lool: I think you did some prof of concept hacked in one pkg-gnome source too no?
[09:28] <pochu> lool: will tell you if I get into it, but no promises :)
[09:28] <lool> seb128: Might have been with *.la, perhaps I did a shell scripts for .pc as well, I'm not sure
[09:28] <seb128> ah right, that was .la
[09:31] <didrocks> seb128: of course, I understood this :) I followed this session (https://wiki.ubuntu.com/MOTU/School/LibraryPackaging), where for the -dev package, we add manually the package that corresponds to "NEEDED section"
[09:31] <didrocks> (around 20:52)
[09:33]  * seb128 looks at this wiki page
[09:33] <seb128> usually I just add what the .pc lists as required
[09:34] <didrocks> (here, the example is fooled as there is only libc6 needed, so we don't add it ;))
[09:35] <seb128> I could be wrong
[09:36] <seb128> but libraries having a .pc usually need only what the .pc requires
[09:36] <seb128> since other packages using the lib are going to use pkg-config and check only for things listed there
[09:36] <seb128> the NEEDED is a runtime thing for the library and those will already be installed thanks to shlib:Depends
[09:37] <didrocks> ok, and we add related package from files listed in .pc file manually as dependency of -dev packages, right?
[09:37] <seb128> yes
[09:37] <didrocks> ok, I think that the list won't be too different from NEEDED section
[09:38] <didrocks> I will check it
[09:39] <didrocks> So, last question but not least: Do you have any idea what can be the cause of /1/ in /usr/lib/evince/1/backends/ in evince-dbg package. It was not present in previous version and was: /usr/lib/debug/usr/lib/evince/backends/?
[09:42] <seb128> didrocks: seems they just versionned their install path so different versions don't conflict
[09:42] <seb128> didrocks: it's not only in the dbg the normal version does the same
[09:42] <didrocks> seb128: ok, so, no warning there. I was just afraid of a side effect of something I did :)
[09:43] <seb128> I don't think so
[09:43] <didrocks> thanks a lot, I will make the final modifications and submit them to you :)
[09:43] <seb128> the non splitted version you uploaded to launchpad some days ago has the same change
[09:43] <seb128> and I don't think any of your packaging changes could do that so I assume that's an upstream thing
[09:44] <didrocks> ok, perfect so. That's probably, as you said, an upstream version method to avoid conflicts
[09:45] <seb128> didrocks: oh you can do the gtkmm update this weekend if you want
[09:45] <didrocks> seb128: thanks a lot. I can now say that I worked on librairies :) (I have just to try now a soname update, etc.)
[09:45] <seb128> you're welcome ;-)
[09:45] <didrocks> ok, I take gtkmm
[11:10] <seb128> didrocks: want to take over bug #316636?
[11:10] <ubottu> Launchpad bug 316636 in pidgin "Please upgrade to pidgin 2.5.4" [Wishlist,Confirmed] https://launchpad.net/bugs/316636
[11:10] <seb128> didrocks: basically it's syncing piding on the current debian version
[12:28] <didrocks> seb128: yeah, I take it
[12:29] <seb128> didrocks: thanks
[12:29] <didrocks> (back home, just for an hour before going to FOSDEM)
[12:29] <seb128> enjoy
[12:30] <didrocks> sure of it ^^
[12:30] <seb128> and say hello to vuntz from me there
[12:30] <didrocks> no problem, I will :)
[12:32] <seb128> cool
[12:36] <pitti> rickspencer3: pong
[12:42] <rickspencer3> asac: connman installed no problems. Thanks.
[12:43] <asac> rickspencer3: thx
[12:43] <rickspencer3> pitti: davidbarth wants to meet with us at 3pm for "go/no go"
[12:44] <pitti> rickspencer3: ack
[12:44] <pitti> TEH DAY OF RECKONING
[12:45] <seb128> rickspencer3: should I be there too?
[12:45] <rickspencer3> seb128: yeah
[12:45] <pitti> plz
[12:45] <seb128> ;-)
[13:04] <rickspencer3> seb128: request is to change the default settings in lcd to "subpixel smoothing (LCDs)
[13:04] <rickspencer3> feasible?
[13:06] <seb128> rickspencer3: you want to speak to Keybuk or doko rather I think, that's a fontconfig configuration thing and Keybuk is the one who made the fonts look the way they do now
[13:06] <rickspencer3> k
[13:06] <Keybuk> rickspencer3: -v?
[13:07] <rickspencer3> sneaker net, be there in a sec]
[13:17] <rickspencer3> seb128: Keybuk says the default is supposed to be subpixel smoothing on an lcd. Perhaps a regression?
[13:26] <seb128> rickspencer3: could be, the config is a fontconfig one which is a platform component
[13:26] <rickspencer3> seb128: *sigh*
[13:26] <rickspencer3> thanks
[13:26] <didrocks> seb128: do you want me to update to the unstable gtkmm version?
[13:28] <bryce__> Keybuk: if you do find reverting the xserver change, of the three patches, 157_check_null_modes.patch would be the first I'd check.
[13:28] <didrocks> (in a nutschell, in 2.14 or in 2.15?)
[13:29] <seb128> didrocks: yes
[13:29] <seb128> 2.15
[13:29] <didrocks> oki
[13:34] <Keybuk> reverting X didn't help
[13:34] <didrocks> seb128: I think that evince is now ok. I pushed it to my branch and tagged it to the new ubuntu version): https://code.edge.launchpad.net/~didrocks/evince/ubuntu
[13:35] <seb128> ok
[13:35] <didrocks> when you will have time, there are some additional information to help you reviewing the package at https://wiki.ubuntu.com/DidierRoche/MOTU/bugsaction
[13:35] <seb128> didrocks: ok
[13:35] <didrocks> time for me to leave. Have a nice weekend!
[13:36] <seb128> didrocks: enjoy
[13:39] <mvo> didrocks: a evince bzr branch is there now? rock!
[15:40] <cody-somerville> seb128, ping
[15:40] <cody-somerville> seb128, Do you push point releases of gnome to -updates?
[15:40] <seb128> depends
[15:40] <cody-somerville> Well, Of course. :)
[15:41] <seb128> depends of the ubuntu version (we try to do it for lts, not especially for non lts) and the changes
[15:41] <cody-somerville> seb128, I'm thinking of pushing a point release of Xfce4 4.4 (4.4.3, a bug fix release) to -updates for 8.10 and was wondering what the gnome team did.
[15:42] <seb128> that's usually a compromise between how interesting the changes are, how many users are requesting those, how much work we put on the sru team, how much the team has to do already, etc
[15:43] <seb128> ie we try to push changes early in the cycle
[15:43] <cody-somerville> Well, the work is already done as we pushed to -backports already
[15:43] <seb128> we don't bother too much about intrepid now, that's not a lts and most users will probably switch to jaunty when it's there
[15:44] <cody-somerville> seb128, My thinking is that some users might stay with intrepid for Xubuntu since Xubuntu ships 4.6 which has some major changes.
[15:44] <seb128> if the upgrades have lot of fixes that would benefit users do it
[15:45] <seb128> that will probably put extra load on the sru team and tester which is deviated from jaunty though
[15:45] <cody-somerville> seb128, Well, I'm on the SRU team and we've already had our Xubuntu QA guys do runs on whats in -backports
[15:45] <cody-somerville> seb128, So sound good to you?
[15:45] <seb128> ok so do it
[15:45] <seb128> yes
[15:46] <cody-somerville> Thanks for the feedback! :) Much appreciated.
[15:46] <cody-somerville> (fyi, Jaunty's desktop for Ubuntu is looking pretty sweet!)
[15:46] <seb128> you're welcome
[15:46] <seb128> thanks ;-)
=== bluesmoke is now known as Amaranth
=== bluesmoke is now known as Amaranth