[04:26] <porthose> a little OT but worth mentioning http://ourfriendsinjapan.com/index.php
[04:51] <wejaeger> Hey, anyone up for reviewing http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn and http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn-daemon
[05:06] <ScottK> wejaeger: You know it's after feature freeze and we aren't, except with very limited exceptions accepting new packages right now?
[05:18] <wejaeger> ScottK: I did not know that, so I better try to get the package into the next ubuntu version ?
[05:18] <ScottK> wejaeger: Yes.  Even better to try and get it into Debian and it will automatically be in the next Ubuntu version.
[05:19] <ScottK> mentors.debian.net is much like REVU for Ubuntu.
[06:12] <micahg> ScottK, does phatch need a release ACK?
[11:06] <nivan> !seen jelmer
[11:08] <directhex> who are you, mortal, who seeks the mighty jelmer?
[11:19] <nivan> hi directhex, I'm looking for some guidance on submitting a change to lp:gnome-session. I understand it's just a mirror of the upstream git repository. Where should I submit my changes?
[11:20] <directhex> nivan, gnome-session seems heavily ubuntu'd in ubuntu, so launchpad is probably the right place.
[11:22] <nivan> jelmer told me to send it to the 'packaging branch'. I don't know what the packaging branch is.
[11:22] <tumbleweed> nivan: lp:ubuntu/gnome-session. wiki.ubuntu.com/UDD
[11:24] <directhex> lp:ubuntu/gnome-session
[11:30] <nivan> thanks guys
[11:41] <geser> nivan: ask the guys in #ubuntu-desktop how they prefer it as they also have their own branches
[11:41] <geser> lp:~ubuntu-desktop/gnome-session/ubuntu
[11:42] <geser> and https://wiki.ubuntu.com/DesktopTeam/Bzr on how to use those branches
[11:46] <nivan> geser: thanks, will give that a try
[11:59] <matttbe> Hello,
[11:59] <matttbe> I want to update Cairo-Dock version in Ubuntu Natty. I've proposed a branch for merging and I've opened a new bug report: https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/723994 before the FF but this version is still not available on Ubuntu Natty...
[11:59] <matttbe> What can I do?
[12:00] <matttbe> A member of Ubuntu-Sponsoring team said to me:  "the merges proposed still have the issue of missing the pristine tarball, which you could get anyone in #ubuntu-motu to help you get fixed." but I don't understand why there is an issue because when I launch "uscan --verbose" command, I see the new tarball!
[12:01] <matttbe> I've also tagged the upstream branch (lp:cairo-dock-core and lp:cairo-dock-plug-ins) and added two new series:  lp:cairo-dock-core/2.3 and lp:cairo-dock-plug-ins/2.3 
[12:02] <matttbe> I've tried this command: bzr merge-upstream --version 2.3.0~0rc1 lp:cairo-dock-core -r tag:2.3.0~0rc1 --distribution=natty
[12:02] <matttbe> but it didn't work :-/
[12:10] <tumbleweed> matttbe: you need to provide the tarball
[12:10] <tumbleweed> uscan --download-current-version --rename --destdir .. <- that normally does the trick
[12:22] <ScottK> micahg: It's just a bug fix, AFAIK.
[12:38] <matttbe> tumbleweed: thank you and sorry for the delay, I had an annoying paper jam with an old printer...
[12:40] <matttbe> tumbleweed: when I launch this command, this is what I have: uscan warning: In debian/watch no matching hrefs for version 2.3.0~0rc1 in watch line
[12:42] <matttbe> but this is what I have with uscan --verbose: -- Found the following matching hrefs:
[12:42] <matttbe>      http://launchpad.net/cairo-dock-core/2.3/2.3.0-0rc1/+download/cairo-dock-2.3.0~0rc1.tar.gz
[12:42] <matttbe> (...) Newest version on remote site is 2.3.0.~0rc1, local version is 2.3.0~0rc1
[12:42] <matttbe> is it because there is a ~ in the versionning?
[12:43] <Rhonda> What's the watchfile?
[12:43] <matttbe> version=3
[12:43] <matttbe> https://launchpad.net/cairo-dock-core/+download .*/cairo-dock-([\d\.\-]+)(~.*)?.tar.gz
[12:44] <Rhonda> That's all, no opts with any mangle thing?
[12:44] <matttbe> no :-/
[12:46] <Rhonda> So shall the ~0rc1 be part of the version, actually?
[12:46] <Rhonda> Try .*/cairo-dock-([\d\.\-]+(~.*)?).tar.gz instead
[12:46] <Rhonda> i.e. taking the (~.*)? into the other bracked instead of having it after it
[12:47] <Rhonda> Potential that also should be a (?:~.*)? so that it isn't put into a variable.
[12:50] <matttbe> this is what I have with .*/cairo-dock-([\d\.\-]+(~.*)?).tar.gz: Newest version on remote site is 2.3.0~0rc1.~0rc1
[12:52] <Rhonda> (?:~.*)?
[12:54] <matttbe> Rhonda: should be better :) => Newest version on remote site is 2.3.0~0rc1, local version is 2.3.0~0rc1
[12:54] <matttbe>  => Package is up to date
[12:55] <matttbe> Rhonda: thank you :)
[21:16] <fabrice_sp> slangasek, Hi. After your update of the expat package, gnome-commander FTBFS (see https://launchpad.net/ubuntu/+source/gnome-commander/1.2.8.10-3build1/+buildjob/2327761/+files/buildlog_ubuntu-natty-i386.gnome-commander_1.2.8.10-3build1_FAILEDTOBUILD.txt.gz ). It seems to be linked to the multiarch change you did. What should I change to the gnome-commander package to make it buildable?
[21:17] <slangasek> fabrice_sp: hi, thanks for the ping - let me have a look at the log
[21:18] <slangasek> fabrice_sp: some package that gnome-commander build-depends on which ships a .la file includes a wrong reference to libexpat.la; that package (which I'm looking up now) needs rebuilt, but it should also do something like the clean-la.mk target from gnome-pkg-tools
[21:18] <fabrice_sp> slangasek, oh, I missed that
[21:30] <slangasek> fabrice_sp: it appears to be /usr/lib/libexiv2.la that's to blame
[21:31] <slangasek> so exiv2 needs at minimum a rebuild, and ideally a fix to clear out its dependency_libs field in that .la file
[21:36] <fabrice_sp> slangasek, thanks for looking. At it's in main, I'll open a bug report with that. Thanks!
[21:36] <fabrice_sp> s/at/as
[21:36] <slangasek> fabrice_sp: I'd be happy to review a patch that add support for the .la file cleanup, if you want to prepare one
[21:36] <slangasek> otherwise I can trigger a no-change rebuild now-ish
[21:37] <slangasek> (currently I have my hands full figuring out why gcj doesn't actually work now)
[21:38] <fabrice_sp> slangasek, I'll have a look at the patch for .la cleanup (no hurry for the rebuild of exiv2, now that the origin of the FTBFS is clear)
[23:16] <slangasek> fabrice_sp: I'm out of the woods now with gcj and ldconfig; I don't see a bug yet regarding exiv2, should I have a look at this?