[00:40] bye [01:19] superm1_: no [01:19] slangasek, i forget what exactly i messaged as i pinged you before. [01:19] slangasek, it was probably related to that mythtv sru [01:36] superm1_: you asked me if I was still here [01:36] slangasek, ah okay [01:37] slangasek, well i was going to ask you about the sru then when you responded :) === chuck__ is now known as zul [01:37] and if it's about the sru, I'm really probably not here until tomorrow morning when I've had a chance to rest some. :) [01:37] slangasek, sounds good :) [01:37] slangasek, enjoy your evening [02:00] Hobbsee, I need some love. [02:00] Bug 160314 [02:00] Launchpad bug 160314 in xfce4-session "xfce4-session: merge new Debian version" [Undecided,New] https://launchpad.net/bugs/160314 [02:00] somerville32: oh? [02:00] :) [02:03] Hobbsee, Think you can help? :] [02:04] somerville32: nope :) [02:04] Hobbsee, Why not? : *( [02:04] because i'm doing uni stuff, and i'm only on irc to speak to some people [02:04] moogles. [02:32] hey I'm wondering where I can propose something regarding the IRC channel, would the forums be a good place? [02:33] I figured launchpad but then that's mainly for distribution problems I figure [02:33] BlaenkDenum: irc channels are covered by the IRC council [02:33] what is your issue? [02:33] BlaenkDenum, "the"... which channel? [02:34] maybe the most popular, #ubuntu [02:34] Burgundavia: oh haha there's an IRC council, where can I contact them? [02:34] BlaenkDenum: what is your issue? [02:34] Alright, well it's not really an issue I was just wondering if it's something to think about. [02:35] instead of being obtuse, you could tell us what is on your mind [02:35] #ubuntu-irc [02:35] then we can help you a lot better [02:35] Burgundavia: this still isnt the correct place :) [02:35] I will, hold on I'm typing heh [02:35] okay I'll go to #ubuntu-irc [02:35] Hobbsee, #ubuntu-ops you mean? ;) [02:35] BlaenkDenum: use #ubuntu-irc. most of the develpoers are not ops. [02:35] PriceChild: er, yes, that. [02:35] Hobbsee: I have no idea what exactly he is saying yet [02:35] Burgundavia: if ti's regarding the irc channel... [02:36] Hobbsee: and he mentioned LP and the forums, thus I am still confused [02:37] Burgundavia: as places to put his proposals, yeah. [02:37] * Hobbsee waits to see what it is [02:40] Carefully BlaenkDenum, they might eat you alive :P === bddebian2 is now known as bddebian === mpt_ is now known as mpt === elmo_ is now known as elmo === TheMuso_ is now known as TheMuso === shenki__ is now known as shenki === popey_ is now known as popey === blueyed_ is now known as blueyed === tepsipak1i is now known as tepsipakki [12:01] hi guys, does ubiquity copy files from the squashfs image only or the squash+unionfs ? [12:23] viviersf: the squashfs, then a handpicked selection of items from the unionfs [12:23] Mithrandir! [12:24] hello little crazy Australian! [12:24] hiya Mithrandir! [12:25] * Hobbsee is sad little crazy [12:25] Australian [12:25] why are you sad? [12:25] my boss is leaving :( [12:25] * Hobbsee notes that her underlings are *all* sad, and are saying she isnt allowed to go :P [12:26] heh [12:26] * Mithrandir ruffles Hobbsee [12:26] * Hobbsee hugs Mithrandir [12:26] so we probably get a terror person, next [12:27] Mithrandir, there a place one can define things to be copied form unionfs ? [12:30] viviersf: you can set up a hook, sure. /usr/lib/ubiquity/target-config contains a list of hooks [12:31] Mithrandir, heh okay, so i just put a scipt in that copies the stuff [12:31] viviersf: that ought to work, yes. You might want to look at the bits there already to work out how it all fits together. [12:32] Mithrandir, cool thanks [12:32] Mithrandir, was this changed for gutsy ? in feisty it copied form all unionfs ? [12:33] no, it's been the same way since dapper [12:44] Mithrandir, in feisty i used to update packages from the live cd and install with the new versions. In gutsy it seems to revert everything [12:47] morning cjwatson_ [12:47] viviersf: if you got that, I think you would have dreamed it. [12:47] Mithrandir, haha no i didnt. Maby there was a bug :P [12:48] viviersf: somehow, I think we would have noticed. Just copying the unionfs would break a whole lot of things. [12:49] Mithrandir, i dunno it worked. Its weird then === zul_ is now known as zul [13:15] stevenk: how is the battle against libtool going? [13:16] norsetto: I will have my revenge! [13:17] good luck with that. will you succeed? [13:18] Hobbsee: the official score is libbtool 1 - stevenk 0 (see bug 139635 last comment) [13:18] Launchpad bug 139635 in libgpg-error "[cryptsetup] library dependency in /sbin/cryptsetup" [Undecided,In progress] https://launchpad.net/bugs/139635 [13:24] norsetto: pity. [13:56] Hobbsee: Howdy :) [13:57] hiya manchicken! [13:57] How goes it/ [14:00] manchicken: it goes, gnome style :) === simira_ is now known as Simira === \sh is now known as \sh_away [15:00] Heya [16:03] anyone here know what packages I can take off of the alt install cd for kubuntu? I need to make room. [16:04] hya [16:05] hi [16:05] today I've add Hardy reps [16:05] did a few (really few packages) updates [16:05] found a little prob [16:05] SoftwarePropertiesGtk didn't work! should I report it on LP? [16:05] Hi all! [16:06] is Michael Vogt here? [16:09] BUGabundo: you want #ubuntu+1 [16:09] and no, he's not [16:10] thanks Hobbsee [16:16] Was anyone here at the Gobuntu sessions at UDS Boston? [16:18] i was at one of them === keescook_ is now known as keescook === pedro is now known as pedro_ [17:10] FYI: we are going to disable automatic package ACCEPT in launchpad for a few hours === pedro is now known as pedro_ [17:10] oh noes! [17:18] fabbione_: as in, disable build-from-unpublished-source? === chand is now known as chand[aw] [17:20] Mithrandir: not sure.. ask pitti [17:20] Mithrandir: we need to import the partner archive in LP [17:20] ah [17:21] pitti: ^^; are you disabling the publisher completely or just the build-unpublished-source bits? [17:22] Mithrandir: completely, just for safety [17:22] ok [17:23] Mithrandir: b-f-a stays enabled for now === pitti_ is now known as pitti [17:26] carlos: spooky japanese https://translations.edge.launchpad.net/ubuntu/gutsy/+source/kde-guidance/+pots/guidance/nb/+translate [17:31] Riddell: https://bugs.edge.launchpad.net/rosetta/+bug/133315 [17:31] Launchpad bug 133315 in rosetta "at least, four wrong language imports for gutsy" [High,Confirmed] === fabbione_ is now known as fabbione [17:51] pitti: libbsd-resource-perl should be okay to be promoted, it built everywhere [17:51] StevenK: it still needs at least a shallow review for MIR [17:51] pitti: Yeah, okay, but that's you or me doing that? [17:51] pitti: All I was planning on doing was crowbarring yada off of it [17:52] * StevenK beats bloody dexter with the crowbar [17:54] Hi all! === rob1 is now known as rob [18:17] hey, the gutsy-security repo has an invalid signature. Has all morning. Anyone to report it to? [18:23] Joe_CoT: really? [18:23] I just applied security updates 1.5hrs ago [18:23] jdong, yeah. [18:23] W: GPG error: http://security.ubuntu.com gutsy-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key [18:23] * jdong runs a 2nd update [18:24] no error on apt-get update [18:24] really? hmm [18:24] sure you don't have an intercepting proxy or something upstream? [18:24] i'm applying them without problem.. [18:24] Joe_CoT: isn't a problem of your mirror? [18:25] Kmos: it shows sec.ubuntu.com [18:25] Kmos: somehow the traffic is getting corrupted on the way over to him.... [18:25] odd to say the least [18:25] ah yeah =) is direct === nicolai__ is now known as Kopfgeldjaeger [18:48] StevenK: ah, libbsd-r-p package looks so *delightfully* easy now [18:50] StevenK: mainified, thanks [18:50] StevenK: on a related note, gnutls13 FTBFSed again, probably because of the libtool-crackification in libgcrypt11 [18:54] pitti: Thank you for the compliment. :-) [18:55] pitti: I saw the FTBFS, I wanted to ask you about it. Shall I just fix and upload gcrypt11 and then we give back gnutls13 once more with feeling? [19:07] StevenK: weren't there plans to eliminate .la files from the packages several releases back? [19:08] it's an uphill battle [19:09] looks more like a battle that never got out of the planning stage to me really ;) [19:15] It's hard to kill .la files [19:16] Since libtool is a pile of crap [19:16] and some KDE apps need them [19:16] can someone help me. My preseed file is not working. It does not seem to be answering any questions. I pasted it at http://paste.ubuntu-nl.org/43569/. [19:20] tekteen: please don't ask questions and run away before you've given people a chance to answer. kthxbye === pedro__ is now known as pedro_ [19:24] soren: why? [19:24] * slangasek runs away! [19:25] * soren grumbles [19:26] * soren shakes his fist at slangasek [19:40] * popey waves at soren [19:40] o/ === ryu2 is now known as ryu [19:48] mathiaz: http://lists.alioth.debian.org/mailman/listinfo/pkg-samba-maint [19:53] bdmurray: are the Portland Cabal going to go in on Adilson's planning for airport transit? [19:53] Heh heh. Portland Cabal [19:55] FYI: uploads to LP will be processed automatically from now [20:06] slangasek: I've considered it [20:09] keescook: the glib copy is pcre 7.2 [20:10] keescook: the changelog has that [20:10] * glib/gregex.c: define PCRE_ERROR_NULLWSLIMIT if it's not defined by [20:10] PCRE, has PCRE 7.3 removed this definition. (#475474) [20:10] not sure if that's a compatibility breakage or something not exported [20:10] fabbione: hrm, what uploads to LP? [20:11] slangasek: all of them.. we had the publisher in manual for a bit [20:11] it's all good now [20:11] oh [20:13] pitti: Are you busy? [20:13] StevenK: currently typing a mail, but not particularly muc [20:13] h [20:14] pitti: Shall I come find you and we can bitch at each other about gnutls and libtool? [20:15] ugh, does gnutls still have .las? [20:16] slangasek: It's worse than that. All three of us can talk about it if you want [20:16] ok [20:16] So as soon as pitti tells us where he is hiding, both of us can find him. [20:17] StevenK: main room [20:17] Oh, duh [20:17] bdmurray: ok, mail is away [20:17] I'm right behind you [20:17] pitti: ^ [20:18] slangasek: Come find us? [20:18] StevenK: in a meeting [20:21] slangasek: Ahh. pitti and I will discuss it. [20:21] bdmurray: we probably need to get a plan together pretty soon, lest all the vehicles in town get filled up before Saturday? :) [20:22] c [20:22] Gah. [20:22] is it normal that a stat(file, &sb) on a symlink that points to a dir will have S_ISLNK(sb.st_mode) set to FALSE and S_ISDIR set to TRUE? [20:23] fabbione: gah? [20:23] zul: stat(2) [20:23] fabbione: ah.. [20:23] zul: make a symlink pointing to a dir [20:23] stat it [20:23] check what it is via S_IS macros [20:23] it tells me that it is a dir and not a symlink [20:24] might be a bug or a feature.. just need to understand [20:35] fabbione, man fstat [20:36] lamego: that's the same man page as stat.. [20:36] lstat() is identical to stat(), except that if path is a symbolic link, [20:36] then the link itself is stat-ed, not the file that it refers to. [20:36] no it is not [20:36] it has a clear statement regarding how slinks are treated :) [20:36] lamego: read carefully what i said... man stat = man fstat [20:36] lstat() unlike stat() identifies links [20:37] ok perfect [20:37] ok, whatever, it answers to your question :) [20:37] that is not fstat.. i don't need that [20:37] fabbione, stat follows links, as per the developers man page [20:37] violent agreement detected [20:37] lamego: yeps right.. i missed lstat [20:38] liw: no.. he is right for lstat.. we agree on that. [20:38] liw: i don't agree that the man pages are different :) [20:38] you are correct [20:38] :P [20:38] lamego: thanks tho [20:38] :) [20:43] bdmurray: bug 155784 [20:43] Launchpad bug 155784 in qt4-x11 "[gutsy] /usr/lib/libssl.so missing" [Undecided,In progress] https://launchpad.net/bugs/155784 === keir__ is now known as keir [21:17] seb128: new cdbs uploaded, works with libgcrypt11 [21:19] pitti: Hi! Did you received my email? [21:20] pitti: you rock! ;-) [21:21] warp10: no, seems I didn't; which mail you mean? [21:22] pitti: I sent it 5 days ago, November 1st [21:33] pitti: if I ask nicely, would you look at the fix for bug 155498 which is in gutsy-proposed since a month? [21:33] Launchpad bug 155498 in rutilt "rutilt 0.15-0ubuntu5 crashes while applying a profile" [Medium,Confirmed] https://launchpad.net/bugs/155498 [21:33] norsetto: oh, in fact I looked at it yesterday, but there was something about it I didn't like [21:33] norsetto: give me a minute [21:34] pitti: sure [21:38] norsetto: oh, right; it doesn't have approval from motu-sru [21:39] and it has a whole lot of changes in it, which don't look critical [21:39] so I want motu-sru to ack it [21:39] norsetto: also, it doesn't have a changelog which is useful [21:39] even less so for users, so it does not tell anything about the impact and severity [21:39] pitti: ok, for the first point, that was motu-uvf at the time [21:40] oh, eww, I didn't know that [21:40] so that's replaced by motu-uvf team? [21:40] pitti: but its ok, I subscribe motu-sru then [21:41] norsetto: no, please don't [21:41] norsetto: LP says that motu-sru is obsolete [21:41] norsetto: hang on a minute [21:42] norsetto: hm, seems that the MOTU SRU process recently changed to not actually require acks [21:42] norsetto: so, sorry, it's not your fault [21:42] but I don't like this at all [21:42] pitti: I will make it only for that bug if necessary but its a pity to miss the other fixes, they really enhance the package [21:43] norsetto: but every change bears the risk of breaking it for current users [21:43] norsetto: only "severe regressions" or "loss of data" [21:43] pitti: just between you and me, I'm using it since a month [21:44] norsetto: btw, with "I don't like this at all" I didn't refer to your patch, but to the process change of not needing acks from motu-sru any more [21:44] pitti: sure :-) [21:44] the current process basically makes stable-universe fair game for breaking [21:45] The point was more to trust MOTUs to make calls about what to fix. [21:45] well, the current mythtv in gutsy-proposed unapproved is a prime example of how *not* to do an SRU [21:46] Who uploaded it? [21:46] "Rewrite the entire tv backend driver because it's better" [21:46] Oh geez [21:47] and once we go down that route of never ack'ing uploads, I'm also afraid that too much effort will be spent fixing minor things in stables [21:47] which is really better spent on improving the current dev release [21:49] norsetto: ok, I let this through based on the fact that it matches the currnet policy [21:49] but I'll initiate a change to that policy === d33p__ is now known as luisbg_ [21:49] pitti: thanks, I really appreciate it [21:49] norsetto hugs pitti [21:50] * pitti hugs norsetto [21:50] * norsetto hugs stevenk too (he is in a hugging mood, so there) [21:55] seb128: ok, we have fixed prepared for gnutls&friends [21:55] seb128: however, in the long run we need to convince Debian about this concept, or we need to use clean-la.mk by default in cdbs (right now it isn't) [21:55] seb128: I'm actually pondering doing the latter [21:59] pitti: well, clean-la comes from Debian, so there is already people convinced there ;-) [21:59] but right, should be discussed there [21:59] only amongst the gnome team, I guess [21:59] I think Keybuk is not that happy with that and consider .la useful [21:59] what for? [22:00] static building apparently [22:00] so, here's a theory for you ... [22:00] they just cause extra useless dependencies and other trouble [22:00] seb128: the answer to that is to make sure a .pc file is provided when the .la is removed [22:00] if you don't want .la files [22:00] why do you compile with libtool at all? [22:00] but I'm not sure that's true on linux nowadays [22:00] why not just use gcc? [22:00] Keybuk: because upstream build systems do? [22:00] upstream install the .la file [22:00] but TBH I think that dh_shlibdeps does a much better job [22:01] no, libtool installs the .la file [22:01] Keybuk: libtool install those [22:01] that's a side effect [22:01] no, it's the primary effect [22:01] upstream just wants to build their libs [22:01] the side effect is the installation of .so [22:01] and I'm not really concerned about having it working on a 20 year old VAX [22:01] libtool uses and manipulates .la files [22:01] installing the .la file is an implementation detail of a poor implementation [22:01] so don't use the poor implementation [22:01] don't have that choice [22:01] if you're using libtool, you should ship its .la files [22:01] why? [22:01] right, we just hack around it ATM [22:01] if you don't want .la files, don't use libtool [22:01] they're useless if you have a .pc file [22:02] it's easy not to [22:02] Keybuk: that's not true [22:02] what is the issue with not shipping those? [22:02] it breaks static linking [22:02] seb128: none if you provide a .pc file instead [22:02] slangasek: not true [22:02] .pc isn't broken; .la is [22:02] even with .pc files you need .la for static linking [22:02] no, you don't. [22:02] yes, you do [22:02] not if the .pc file isn't broken [22:02] the .pc file doesn't list the list of dependencies for the shared library [22:03] because if it did, you'd be removing those too [22:03] you need that list of dependencies for static linking [22:03] we fixed libtool years ago to ignore that list for dynamic linking [22:03] er, no, you just need a version of pkg-config that supports the --static option [22:03] maybe the current Debian maintainer reverted my patches *shrug* [22:03] Keybuk: except that libtool *still* has to recurse the actual .la files at build time [22:03] Keybuk: static linking tends to break for complex programs with lots of libs anyway [22:03] so when the dependencies of your build-dependencies change, .la shows its true evil [22:03] slangasek: I have no issue with replacing libtool with something else [22:03] . o O { if that breaks static linking, so much the better :-P } [22:03] it's not difficult [22:04] Keybuk: that's not something we want to do at a distro level [22:04] and you told me that aspect of .la behavior couldn't be fixed without a compatibility break [22:04] back in the gnome 1.4 days I tried linking a program using orbit statically; broke horribly [22:04] Chipzz: yet we still ship .a files [22:05] seb128: we overwrite config.guess and config.sub for every package [22:05] adding a third file to that list seems trivial [22:05] the only thing installation of .la files is legitimately needed for on Linux is static linking; there is a way to support static linking via .pc files without the side-effects of .la files. QED [22:05] slangasek: .pc has different problems ;) [22:05] the main one being they can only be installed in one place [22:05] so you can't (easily) parallel install different version [22:06] ...unless that's fixed, I'm not up to date [22:06] Keybuk: how do other distros which don't ship .la do? that's not possible to do static linking on redhat? [22:07] seb128: ever tried static linking gtk? :p [22:07] Keybuk: but that's equally true of .la? /lib/libfoo.la doesn't work [22:07] *boom* [22:07] pitti: yes it does [22:07] assuming you compiled it for /lib [22:07] 23:01 < Keybuk> if you don't want .la files 23:01 < Keybuk> why do you compile with libtool at all? >> Several reasons actually, the prime one being "I didn't decide this as I didn't write the thing" [22:07] one of the usual complaints about libtool is precisely because it *does* support .la files by specific paths [22:07] Chipzz: the upstream maintainer almost certainly didn't decide either [22:07] most people only use libtool because automake demands it for shared libraries [22:07] second one: because it helps on other platforms than linux [22:07] Keybuk: we did, but libtool doesn't find them in /libs; we tried and it failed [22:07] Chipzz: we're Ubuntu *Linux* [22:08] Keybuk: I'm sure upstream cares about us being ubuntu linux ;) [22:08] like I said, upstream probably doesn't care about libtool [22:08] they got it as a side-effect of automake (which makes writing make files easier) [22:08] right [22:08] what upstream actually cares about is building and installing .so [22:09] yeah, and that's easy [22:09] just replace ltmain.sh with something that just calls gcc with the same arguments [22:09] Keybuk: anyway I think there's a difference between libtool being evil and .la files being evil [22:09] Chipzz: .la files are part and parcel about what libtool *does* [22:09] I'm not convinced of the former, but rather of the latter [22:09] Keybuk: libtool works fine without .la files [22:09] not true [22:09] I'm afraid [22:09] it works only for the commonest case [22:09] it's really a bit thick without them [22:10] try rm /usr/lib/*la and build something using libtool; it still builds fine [22:10] which is why I've continually resisted removing them [22:10] I *know* the bugs [22:10] actually [22:10] it doesn't [22:10] usual test [22:10] rm /usr/lib/*.la [22:10] have a package with a convenience library that links to something in /usr/lib [22:10] do you have concrete example of things which doesn't work without those for people who don't know the bugs? [22:10] and an app that links to it [22:10] app will fail to link [22:11] (convenience libraries are arguably bugs in themselves, but people love them) [22:11] what do you call "a convenience library"? [22:11] seb128: info libtool search for "convenience library" [22:11] rm /usr/lib/*.la is the usual way jhbuild users get GNOME to build [22:11] what most people use when they spread code amongst multiple sub-directories in their package [22:12] yeah [22:12] GNOME are particularly well-behaved [22:12] it certainly never affects them [22:12] but it affects a random bunch of other crap [22:12] pitti: err, I owe you an apology for bug 155431 ... can you pls. un-subscribe ubuntu-archive. Sorry :-( [22:12] I honestly can't remember, because I stopped seriously caring about this years ago ;) [22:12] Launchpad bug 155431 in apr "documentation in /usr/share/doc/libapr1-dev missing" [Low,Confirmed] https://launchpad.net/bugs/155431 [22:12] let's fix those then? [22:12] I came to the conclusion that the build chain support was utterly broken [22:12] and nobody had any desire to properly fix it [22:12] so, we could probably fix libgpg-error to ship the shlib in /lib *and* have a working .la file, but autoconf and libtool make this exceptionally hard [22:13] it seems that they actively make it hard to ship libs in /lib [22:13] I fully support replacing ltmain.sh with a very small shell script [22:13] so .la files cease to be a problem at all [22:13] Keybuk: one of the problems of .la files (which I'm sure you're aware of) is it totally defies any attempts of using -Wl,--as-needed [22:13] Keybuk: sounds good to me [22:13] I don't know enough about the build system to have an opinion on that [22:13] Chipzz: patched in Debian years ago [22:13] but if you are comfortable doing a such change [22:14] (when I maintained libtool) [22:14] norsetto: don't worry [22:14] Keybuk: yes, and if upstream doesn't use debians libtool and rolls a tarball you're still screwed [22:14] -- random tangent -- does anyone know how you tell OpenOffice what the individual text boxes on a slide master *mean* ? [22:14] (or you need to run relibtoolize) [22:15] Chipzz: autoreconf [22:15] (which tend to break more often than not) === doko_ is now known as doko [22:16] autoreconf tends to be a chore to run, and it produces big patches which have to be reviewed [22:17] it only produces big patches if the upstream is done wrong [22:17] or with an older/different version than we use [22:18] Chipzz: you can use the same version than upstream, just look to the Makefile.in [22:18] hell [22:18] just running "make" will always use the same version as upstream [22:19] (except where Debian deliberately change the upstream package to prevent all that useful functionality from working -- yay working around perceived problems) [22:19] Keybuk: usually the libtoolize patch have an aclocal and an autoconf call [22:19] anyway what do we argue about now? [22:20] Keybuk: we currently have autoconf2.13; what happens if for example upstream tarball was rolled with autoconf 2.12 ? [22:20] aclocal will just replace a file in m4 [22:20] Chipzz: let's stop there [22:20] like I said [22:20] I don't really care about any of this [22:20] most of us know the issues with the current system [22:20] it's all broken, and made worse by people doing workarounds rather than fixing the system [22:20] do what you want ;) [22:20] but don't complain to me when you break it [22:20] fair enough [22:21] Keybuk: a convenience library referencing the .la files in /usr/lib is precisely a symptom of *why* we shouldn't ship the .la files :) [22:21] seb128: that actually was a genuine question; but whatever ;) [22:21] if they weren't present when the convenience lib was built, the application will also link just fine [22:22] slangasek: no, it won't [22:23] huh? [22:23] if there was no .la file in /usr/lib, the convenience lib's .la will only reference the libraries, not the non-existent .la files [22:23] not true [22:23] but I can't be arsed to argue anymore [22:24] you're claiming that the convenience lib's .la file *will* reference .la files that never existed? :P [22:24] no [22:26] then what? you're saying that you can't have a convenience lib .la without having .la files for all the underlying libs? [22:34] seb128: ping [22:34] are you working on pygoocanvas? i should work with it, so i can take a look for the merge/sync of it. [22:36] gaspa: no, I'm not, you are welcome do to the merging, feel free to ping me if you need sponsoring then [22:42] seb128: ok, thank you ;D [22:43] gaspa: no problem [22:44] seb128: are you generally ok with people merging gnome packages? [22:45] seb128: or are there ones that you need to handle yourself [22:49] LaserJock: https://wiki.ubuntu.com/DesktopTeam/TODO [22:49] LaserJock: feel free to claim any update or merge there [22:50] LaserJock: just put a link to the .dsc or to a bug with the informations === Fujitsu_ is now known as Fujitsu === asac_ is now known as asac