=== jono_ is now known as jono
=== ubott2 is now known as ubottu
=== julezz is now known as julez
=== jtechidna is now known as JontheEchidna
=== nenolod_ is now known as nenolod
[04:41] <imbrandon> ok so its quiet and i got a question/problem, bash script that i run, it then runs a ssh session and does a ton of stuff on the other comp and *should* never disconnect ( its forever tail on a file and a few other pipes ) and it works good unless the network hickups and ssh hangs, is there an easy way for me to run a loop in the bash script and tell if the ssh session has hun and restart it ?
[04:49] <ScottK> Run it in a screen session would probably be easier.
[04:49] <imbrandon> hum
[04:49] <imbrandon> how would that help ? ssh would still die if net hiccuped
[04:50] <ScottK> Yes, but the script would keep going in the screen session and you could reconnect to it.
[04:51] <imbrandon> whats the ssh is doing is going to my remote irssi box and parseing / tailing the notifi hilights i get from irssi and then using the local notify-send on my laptop to get gui notifications
[04:51] <imbrandon> so i dont think screen would help
[04:51] <ScottK> I see.
[04:52] <superm1> use an irc bouncer instead and run irssi on the local box connecting to the IRC bouncer
[04:52] <superm1> like bip or zsh
[04:52] <superm1> or a client that natively supports notifications like xchat
[04:52] <imbrandon> meh, i do that, i have irssi proxy loaded and tried bip but backscroll and a ton of other stuff sucks on it
[04:53] <imbrandon> and xchat would be sooo slow running on the xserver across the internet and still die when my x session dies iirc
[04:53] <superm1> xchat + bip i mean
[04:53] <superm1> xchat locally, connect to a remote bip box
[04:53] <superm1> and it will just replay what you missed
[04:54] <imbrandon> xchat + bip == shitty backscroll
[04:54] <imbrandon> ever actualy used it ? i tried for a week once aboutr a year ago
[04:54] <imbrandon> lol
[04:54] <superm1> just set your buffer large enough and you can scroll back
[04:54] <superm1> i have been using it for about 1.5 years
[04:54] <superm1> it's what i'm using right now)
[04:55] <imbrandon> yea i did for a while, i just couldent handle that and the lag of connecting when its loading 50+ channels on a few networks and should never be off and i can use a cli client
[04:56] <superm1> well you are on too many networks and channels then clearly ;)
[04:56] <imbrandon> wht i have works great cept for the ssh hang laptop use iisue ;)
[04:56] <imbrandon> superm1: maybe, but i do actualy use most of them regularly
[04:56] <imbrandon> ;)
[04:57] <nigelb> imbrandon: use seprate bips :D
[04:57] <imbrandon> but yea lots of channels + loading backscroll of i think 1000 lines was max ( not much for some rooms ) was bad bad jojo
[04:57] <superm1> i have my scrollback set to 5000 per channel
[04:57] <imbrandon> nigelb: how would that help ?
[04:58] <superm1> as long as i dont disappear for too long that works well for me
[04:58] <nigelb> imbrandon: well at least you can selectively connect to networks
[04:58] <imbrandon> i tend to be away from some chans for about 24 hours, but not much more before i read em
[04:59] <imbrandon> nigelb: ahhh that would not help then, i would just be a regression from now when i can do it fine
[04:59] <imbrandon> really the main issue is getting the ssh restarted when it hangs due to network being unavailable for a short time, everything else is perfect
[05:00] <imbrandon> for me at leaste
[05:00] <superm1> autossh is what you need then
[05:00] <imbrandon> rockin, thats what i needed /me googles a bit
[05:00] <imbrandon> ty ty
[05:01] <imbrandon> btw man how goes thing havent been on at the same time as you in a while
[05:01] <superm1> v. busy, not enough time lately to dedicate to ubuntu community type stuff
[05:02] <imbrandon> i hear ya, sometimes things get hetic
[05:04] <RAOF> There's always something like smuxi, although that also suffers somewhat from inefficient backscroll.
[05:15] <ScottK> imbrandon: You could also go gui and use quassel.  Put the client on your laptop and the core on your server.  It does an initial backsroll fetch on connect, but you can get as much more as you want if it's not enough.
[05:25]  * micahg thinks quassel might be worth looking into
[05:26] <micahg> ScottK: it doesn't do any other protocols, does it?
[05:27] <ScottK> micahg: No.  The client/core protocol for quassel speaks in native Qt objects, so it'd be non-trivial.
[05:27] <imbrandon> ScottK: hum, dident know you could split quassel
[05:27] <micahg> ScottK: k
[05:27] <RAOF> Smuxi has the same sort of architecture; it does IRC and twitter at the moment, I think.
[05:28] <ScottK> micahg: We do provide packages for the full KDE client and also a Qt only version for people who don't want all of KDE.
[05:28] <imbrandon> i'm only worried about irc, i have pidgin for everything else
[05:28] <micahg> ScottK: I like pidgin because I can do IRC, xmpp, AIM, and identi.ca all in one client
[05:28] <ScottK> imbrandon: The split client/core is actually the "normal" use case for Quassel.  The monolithic client we use in Kubuntu is actually very secondary to upstream.
[05:29] <ScottK> micahg: I've yet to use a multi-protocol client like that that did IRC well enough for me.
[05:29] <imbrandon> nice, i'll look into that right now. i'm not oposed to a gui client, i just dont like missing all the stuff i'm used to when i switch to one
[05:30] <micahg> ScottK: works pretty well for me, I just wish I had a way to be online all the time with that client :)
[05:30] <imbrandon> *sometimes* i even use the irssi proxy and connect xchat but not much
[05:30]  * micahg will file a feature request for a relay \o/
=== ApOgEE__ is now known as ApOgEE
=== yofel_ is now known as yofel
[07:24] <dholbach> good morning
[08:51] <ApOgEE> good morning dholbach
[09:06] <dholbach> hi ApOgEE
[09:43] <huats> morning
[09:49] <ApOgEE> morning huats
[09:51] <huats> mornig ApOgEE
[09:54] <BlackZ> tumbleweed: if you want you can ACK the sync
=== Amto_res`OFF is now known as Amto_res
[10:05] <tamrat> There is a needs-packaging bug for a package which is now part of debian. Should I file a seperate 'sync from debian' bug, or should I update the current bug report
[10:05] <tamrat> https://bugs.launchpad.net/ubuntu/+bug/95667
[10:05] <ubottu> Launchpad bug 95667 in Ubuntu "[needs-packaging] SAGA GIS" [Wishlist,Fix committed]
[10:06] <BlackZ> tumbleweed: it should go as "Triaged", marking so
[10:09] <geser> tamrat: please update that bug. that way we don't have a stale bug left because someone forgot to close it after the sync
=== ApOgEE is now known as ApOgEE_away
=== ApOgEE_away is now known as ApOgEE
[10:18] <tumbleweed> BlackZ: not according to https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue#Sync request bugs
[10:19] <BlackZ> geser: the status "Triaged" in a sync request is invalid? (if it has been ACKed by a MOTU)
[10:20] <geser> BlackZ: I don't know if the archive admins care about the bug status but we usually set it to Confirmed
[10:20] <BlackZ> I've seen few bugs with this status after the ACK
[10:21] <BlackZ> tumbleweed: OK, I've set "Confirmed" newly
[10:21] <tumbleweed> BlackZ: :)
[10:25] <BlackZ> tumbleweed: if a package works fine without the versioned dependence can we drop it?
[10:25] <tumbleweed> BlackZ: need more information
[10:26] <BlackZ> tumbleweed: bug #598184 -- I'm testing it right now
[10:26] <ubottu> Launchpad bug 598184 in cynthiune.app (Ubuntu) "Please merge cynthiune.app 0.9.5-10 (universe) from debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/598184
[10:29] <tumbleweed> BlackZ: sorry, I don't know anything about libmpcdec-dev
[10:30] <tumbleweed> but why don't we have a recent version in ubuntu?
[10:36] <tumbleweed> BlackZ: ok, so we use a different source package to provide libmpcdec-dev to debian (LP: #540019). update build-deps appropriatly and see if it works
[10:39] <BlackZ> tumbleweed: what do you mean? dropping the versioned dependence or set the versioned dependence which is in ubuntu?
[10:41] <tumbleweed> err, drop I guess
[10:55] <BlackZ> tumbleweed: seems it FTBFS: http://launchpadlibrarian.net/50892644/buildlog_ubuntu-maverick-i386.cynthiune.app_0.9.5-10ubuntu1_FAILEDTOBUILD.txt.gz
[10:55] <BlackZ> I don't think this is related to the dependence
[10:56] <tumbleweed> BlackZ: that looks very much related to dependancies: mpc/reader.h: No such file or directory
[10:57] <BlackZ> ah yes
[10:58] <BlackZ> hmm, seems we need the newest version of libmpcdec
[11:12] <rsajdok> hi, where can i read about how to make update package eclipse to the newest version (wiki page) "helios" ? who is responsible for this package, developer ubuntu or developer debian?
[11:15] <tamrat> rsajdok: eclipse is a complicated package - updating yourself is most likely difficult, and the packagers of that package will know there is a new version - no need to ask them for an update
[11:23] <rsajdok> tamrat: My intention is not hurry up packagers. I want to learn how to do it. i am looking for any wikis pages or documentations about it.
[11:26] <BlackZ> tumbleweed: I fixed bug #595180 please check it
[11:26] <ubottu> Launchpad bug 595180 in ircd-hybrid (Ubuntu) "Please merge ircd-hybrid 1:7.2.2.dfsg.2-6.1 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/595180
=== Quintasan_ is now known as Quintasan
[11:28] <tamrat> rsajdok: https://wiki.ubuntu.com/PackagingGuide/Complete But believe me - try packaging some smaller things first
[11:37] <rsajdok> tamrat: ok, thanks
[11:46] <soren> persia: What do you have against pandora-build?
[13:00] <dholbach> BlackZ: the comment about the patch file name was more general :)
[13:01] <BlackZ> dholbach: yes, I know, in the next I will do as you said :)
[13:02] <dholbach> BlackZ: thanks :)
[13:03] <BlackZ> dholbach: package-version.debdiff would be correct? e.g foobar_0.1-1ubuntu1.debdiff
[13:03] <dholbach> whatever - and if it's just package.debdiff
[13:06] <BlackZ> dholbach: thanks for your hint :) I will do so
[13:36] <dholbach> who could imagine giving a session about merging, UDD, avoiding common packaging mistakes, finding good stuff to work on at Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has a few open slots
[13:52] <warp10> ehy dholbach, gaspa suggests a "working with Debian" session for UDW. What's your opinion about it?
[13:52] <dholbach> warp10: Laney is giving one of those
[13:52] <warp10> D'OH!
[13:52] <dholbach> warp10: you could work together with him
[13:52] <dholbach> or do a double session
[13:52] <dholbach> or a second one
[13:52] <warp10> gaspa: --^
[13:53] <dholbach> you're all a great team
[13:54] <warp10> dholbach: yeah, that could be an idea. gaspa, maybe we want to check the session program with Laney and see if we should double it, co-work or move to a whole differen thing, do you agree?
[13:55] <gaspa> ok, good!
[13:55] <dholbach> I mean there's LOADS of topics that interest new developers and contributors
[13:55] <dholbach> merging, UDD, avoiding common packaging mistakes, finding good stuff to work on, the release schedule, etc
[13:55] <dholbach> there's really loads
[13:56] <dholbach> a development q&a could be nice too
[14:22] <gaspa> dholbach: we'd take the last slot of wednesday, can I modify the page?
[14:24] <dholbach> gaspa: sure
[14:24] <gaspa> nop
[14:24] <gaspa> taken :)
[14:30] <gaspa> dholbach: ehm, signed up for Friday... Wed was already taken.
[14:30]  * dholbach hugs gaspa
[14:30] <dholbach> gaspa: awesome
[14:30] <dholbach> gaspa: BlackZ has an interest to work together with you guys
[14:30] <dholbach> hey stefanlsd
[14:30] <dholbach> ah, he's on there already
[14:30] <dholbach> awesome
[14:30] <gaspa> ;)
[14:30] <dholbach> Italian mafia back in business
[14:30] <gaspa> LOL
[14:30] <dholbach> :-)
[14:31] <gaspa> need a pizza, then
[14:31] <dholbach> I love you guys - ROCK ON
[14:31] <warp10> dholbach: LOL
[14:32]  * warp10 hugs dholbach 
[14:32]  * dholbach hugs warp10 back :)
[14:32] <warp10> Uhmm... maybe I should rather kiss hands...
[14:33] <dholbach> warp10: you probably know more about that than I do ;-)
[14:33] <warp10> dholbach: yeah, think so! :D
[14:33] <warp10> gaspa: could you arrange the play Godfather theme in background during our session?
[14:33] <gaspa> ...sometimes I feel we're not joking about it...
[14:34] <warp10> ROTFL
[14:35] <gaspa> warp10: can we use A4 to present our session? :D
[14:35] <warp10> gaspa: rocking idea! :D
[14:54] <barry> hello folks!  is anybody up for reviewing two new packages uploaded to revu?  they are fairly simple python packages that have been available on pypi for a while, but now i've packaged them for ubuntu (i'm upstream on them too)
[14:55] <ScottK> barry: Usually we suggest people go to DPMT/PAPT in Debian for that.
[14:56] <barry> ScottK: yes, i'm going to do that, but i really wanted to go through the ubuntu process as documented in the ubuntu wiki.  or will that make it more difficult to sync once the packages are in debian?
[14:58] <ScottK> As long as the md5sum of the tarball is the same, it won't make things more difficult.
[14:59] <ScottK> Unfortunately, due to a shortage of sponsors that actual process seems to be upload to REVU, wait for something to happen, and then eventually go to Debian because only about 10% of the packages uploaded to REVU ever get a serious look.
[14:59] <barry> ScottK: ouch
[15:00] <ScottK> barry: A lot of MOTU get distracted by stuff like the Ubuntu Python maintainer uploading 2.6 to the distro the day before feature freeze and declaring his work done after Main is transitioned.
[15:02] <barry> ScottK: heh.  still, we should give new ubuntu developers reasonable, working guidelines on the ubuntu wiki.  if revu is not a reasonable path to success, then let's change the wiki guidelines
[15:03] <ScottK> barry: There really isn't one.  The best guideline is that if you have an interest in maintaining a specific package, you should maintain it in Debian and sync it into Ubuntu.  If the package is of interest to a development team, upload to REVU and ask someone on the team to review it (we do this in Kubuntu a lot).
[15:03] <ScottK> If you just want to do a fire and forget upload, then we probably don't want the package.
[15:04] <barry> ScottK: that's already a better recommendation than what's currently on wiki.ubuntu.com/MOTU/Packages/REVU
[15:04] <ScottK> barry: OK.  It's a wiki.  Go for it.
[15:04] <barry> ScottK: which is where you land if you follow the twisty path for getting a new package into Ubuntu
[15:04] <ScottK> Right.
[15:04] <barry> ScottK: that's exactly why i'm here! :)
[15:04] <barry> ScottK: thanks
[15:05] <ScottK> Obviously though if you got that far, we didn't make it twisty and turny enough.
[15:06] <barry> ScottK: oh, you tried, and almost won.  when i got to the page about vuvuzelas, i realized i had to backtrack
[15:06] <ScottK> Heh.
[15:09] <barry> ScottK: what's the best debian page we should point people to who want to start the process of getting new packages into debian?
[15:09] <ScottK> barry: Probably point them at mentors.debian.net, but mention that there are many teams in Debian and if your package fits a team, you should contact them.
[15:10] <barry> +1, thanks
[15:11] <ScottK> barry: You can use https://wiki.ubuntu.com/Debian/PythonModulesTeam for an example of how to interact with a Debian team.
[15:11] <barry> ScottK: perfect thanks.  i'll let you know when i've updated the wiki page
[15:12] <ScottK> Excellent.  Once you've done that, you can go to DPMT in good conscience that you are in deed following the Ubuntu process.
[15:13] <barry> ScottK: yep.  just trying to make the path a little smoother for the next rider
[15:14] <ScottK> Great.
[15:30] <barry> ScottK: https://wiki.ubuntu.com/MOTU/Packages/REVU
[15:31] <ScottK> barry: Looks good to me.
[15:31] <barry> thanks for the feedback
=== virtuald_ is now known as virtuald
[16:39]  * hyperair wonders where Ubuntu will go after going through Zippy Zebra
[16:41] <Pici> We never did have an AA release..
[16:42] <hyperair> hmm so we loop back to AA eh
[16:42] <hyperair> then all these x.y.z~zippy1 versions will break.
[16:42] <hyperair> because x.y.z~angry1 is definitely not going to supersede x.y.z~zippy1
[16:42]  * hyperair votes Angry Apple for AA
[16:43] <hyperair> oh wait, apple's not an animal..
[16:44] <Pici> Oh, then thats not good.
[16:44] <Quintasan> hello
[16:44] <hyperair> Angry Ape.
[16:44] <hyperair> well hello there
[16:44] <Quintasan> hyperair: Angry Apple is good
[16:44] <Quintasan> hyperair: by the time we hit AA Apple is really going to be angry because we will take over their market share
[16:44] <Quintasan> :P
[16:45] <hyperair> =D
[16:45] <hyperair> that sounds really appropriate.
[16:45] <Quintasan> I would do and exception for PP  == PA  == Problem, Apple?
[16:45] <Quintasan> s/and/an
[16:45] <hyperair> heheh =p
[17:10]  * ScottK votes for aardvark since it'll be the second time through the alphabet.
[17:14] <paissad> hi all, where can i have the available|possible results of dpkg-architecture -qDEB_HOST_ARCH
[17:15] <paissad> thanks in advance for helping
[17:16] <carstenh> dpkg-architecture -L
[17:17] <carstenh> though I don't think architectures like darwin-m68k will ever exist in debian or ubuntu
[17:17] <paissad> :)
[17:19] <geser> hyperair: Crispy Calamari for CC :)
[17:20] <hyperair> geser: nice =p
[17:20] <hyperair> geser: Duck Dumpling for DD
[17:20] <hyperair> ;-0
=== yofel_ is now known as yofel
[17:25] <ScottK> carstenh: There are archs in there that will never exist in Debian either.
[17:57] <geser> kees: I'm right that that adding -nostdlib (or -Wno-stack-protector) to CFLAGS is the right fix for http://launchpadlibrarian.net/50893909/buildlog_ubuntu-maverick-i386.lustre_1.8.3-2ubuntu1~ppa0_FAILEDTOBUILD.txt.gz?
[17:59] <kees> geser: yes, it looks like the final link includes the -nostdlib, but that means the other .o files need to be built with that too.
[18:00] <geser> kees: do I need to add the package somewhere to https://wiki.ubuntu.com/CompilerFlags? I didn't spot an obvious place
[18:01] <kees> geser: no, since it won't be an "exception".  the intended way to build that package is with -nostdlib, so it's just a simple (fixable) bug in the compile.
[18:01] <kees> geser: only if no correct solution for a problem can be found should it show up on CompilerFlags (like, say, bacula)
[18:02] <geser> ok
[18:03] <geser> kees: do you have an idea why the same linking on amd64 succeeds? http://launchpadlibrarian.net/50893899/buildlog_ubuntu-maverick-amd64.lustre_1.8.3-2ubuntu1~ppa0_FULLYBUILT.txt.gz (search for "static lib lustre" to find the same place where it failed on i386)
[18:03] <geser> I assumed that it would fail on amd64 too because of the -nostdlib at the linking stage
[18:05] <tumbleweed> BlackZ: so for hp-ppd. want to mark the bug invalid and put a note on merges sayng "sync when Debian version is sane again"?
[18:05] <kees> geser: I think amd64 isn't as strict in some situations.  I don't really know the root cause, though.
[18:06] <BlackZ> tumbleweed: go ahead, thanks
[18:06] <geser> kees: ok, thanks anyways
[18:07] <kees> np
=== Amto_res is now known as Amto`Off
[20:06] <fabrice_sp> about bug 596891, I was going to answer to Bhavani that as Angel as done all the work, I'd rather sponsor a debdiff from Angel. What do you think about that answer?
[20:06] <ubottu> Launchpad bug 596891 in ldaptor (Ubuntu) "Please merge ldaptor 0.0.43+debian1-3 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/596891
[20:06] <fabrice_sp> (all the work is report to Debian, and get half of the diff fixed there)
=== jtechidna is now known as JontheEchidna
[20:23] <shishire> where can I find the configure line for a prebuilt package? I need to rebuild php5, with some custom options, but I want to retain the rest of the configure line as is, to make it as compatible as possible.
[20:26] <fabrice_sp> shishire, in debian/rules, except if php5 is special
[20:27] <shishire> fabrice_sp, debian/rules inside the prebuilt package?
[20:27] <fabrice_sp> shishire, inside the source package
[20:28] <shishire> oh, even better :D
[20:28] <shishire> ty
[20:28] <fabrice_sp> yw ;-)
[20:28] <shishire> awesome!  now I can just add the extension support I need, and good to go :D
[20:31] <fabrice_sp> shishire, and you can build it with debuild -b
[20:31] <fabrice_sp> it will use your 'patched' debian/rules file to generate the debs
[20:31] <shishire> :D it keeps getting better and better :D
[20:33] <BlackZ> fabrice_sp: seems the new version of cmus has some problems
[20:34] <fabrice_sp> BlackZ, what kind of problems?
[20:35] <BlackZ> fabrice_sp: it FTBFS, as you said in bug #596323
[20:35] <ubottu> Launchpad bug 596323 in cmus (Ubuntu) "Please merge cmus 2.2.0-4.1 (universe) from debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/596323
[20:35] <BlackZ> seems the debian version fails too
[20:36] <fabrice_sp> BlackZ, if it FTBFS in sid, please report the bug in Debian
[20:36] <BlackZ> fabrice_sp: checking, however I fixed ekiga
[20:36] <fabrice_sp> I saw: I'm just cleaning my local copy to reapply your debdiff
[20:36] <fabrice_sp> ;-)
[20:37] <fabrice_sp> BlackZ, seems to be some libmpc update
[20:37] <BlackZ> fabrice_sp: exactly
[20:38] <fabrice_sp> Ubuntu has the same version as Debian?
[20:38] <fabrice_sp> !info libmpc maverick
[20:38] <ubottu> Package libmpc does not exist in maverick
[20:38] <fabrice_sp> oops
[20:38] <fabrice_sp> :-)
[20:38] <BlackZ> hm, seems not
[20:39] <BlackZ> I see just an upload in karmic
[20:39] <fabrice_sp> !info libmpc-dev maverick
[20:39] <ubottu> libmpc-dev (source: mpclib): multiple precision complex floating-point library development package. In component main, is extra. Version 0.8.2-1 (maverick), package size 42 kB, installed size 208 kB
[20:39] <fabrice_sp> !info libmpc-dev sid
[20:39] <ubottu> 'sid' is not a valid distribution: hardy, hardy-backports, hardy-proposed, jaunty, jaunty-backports, jaunty-proposed, karmic, karmic-backports, karmic-proposed, kubuntu-backports, kubuntu-experimental, kubuntu-updates, lucid, lucid-backports, lucid-proposed, maverick, maverick-backports, maverick-proposed, medibuntu, partner, stable, testing, unstable
[20:39] <fabrice_sp> !info libmpc-dev unstable
[20:39] <ubottu> libmpc-dev (source: mpclib): multiple precision complex floating-point library development package. In component main, is extra. Version 0.8.2-1 (unstable), package size 42 kB, installed size 208 kB
[20:39] <BlackZ> oh yes
[20:39] <fabrice_sp> the same, so it should FTBFS
[20:39] <BlackZ> it's the same
[20:39] <BlackZ> I was looking for the wrong package :p
[20:39] <fabrice_sp> good candidate for submittodebian or reportbug :-)
[20:40] <fabrice_sp> so did I :-)
[20:44] <fabrice_sp> BlackZ, about ekiga, I'll update the Vcs-Bzr url, as it's referencing lucid
[20:44] <BlackZ> fabrice_sp: yes, please do
[20:44] <BlackZ> I didn't found that in the debian/changelog BTW
[20:44] <fabrice_sp> it's not worth a new debdiff.
[20:45] <BlackZ> "- debian/control: Clarify Vcs-*;"
[20:45] <BlackZ> found
[20:45] <fabrice_sp> it's a bit hidden: "debian/control: Clarify Vcs-*;"
[20:45] <fabrice_sp> yes
[20:45] <fabrice_sp> I'm too slow :-)
[20:45] <BlackZ> heh
[20:45] <fabrice_sp> do you know the patches.ubuntu.com site?
[20:45] <fabrice_sp> like http://patches.ubuntu.com/by-release/ubuntu/e/ekiga/
[20:46] <BlackZ> yes
[20:46] <fabrice_sp> ok
[20:46] <BlackZ> I heard it
[20:47] <fabrice_sp> this is how I check the merges ;-) Comparing the old diff wit hthe new one
[20:48] <BlackZ> tumbleweed: I can't find lintian errors in ircd-hybrid, please see http://pastebin.ubuntu.com/455148/
[20:48] <BlackZ> just warnings
[21:02] <fabrice_sp> BlackZ, ekiga FTBFS: "Requested 'ptlib >= 2.6.7' but version of ptlib is 2.6.5"
[21:02] <tumbleweed> BlackZ: binary, not source
[21:07] <BlackZ> fabrice_sp: maybe we can drop the versioned dependence? (however that needs testing)
[21:07] <BlackZ> or merge/sync ptlib directly
[21:07] <BlackZ> tumbleweed: are you able to build it?
[21:08] <fabrice_sp> better merge ptlib: the check is done in configure
[21:08] <fabrice_sp> so upstream is willing to have that version
[21:09] <fabrice_sp> s/willing/requesting/
[21:10] <BlackZ> fabrice_sp: well, I'm on it
[21:10] <fabrice_sp> good :-)
[21:10] <tumbleweed> BlackZ: yes
[21:11] <tumbleweed> BlackZ: surely you tested building it? :)
[21:12] <BlackZ> tumbleweed: strange, http://launchpadlibrarian.net/50893846/buildlog_ubuntu-maverick-i386.ircd-hybrid_1%3A7.2.2.dfsg.2-6.1ubuntu1_FULLYBUILT.txt.gz
[21:12] <BlackZ> I'm able to build it
[21:12] <BlackZ> (is it a your problem or is it my fault?)
[21:12] <BlackZ> maybe I dropped something in the package, but I don't think so
[21:13] <tumbleweed> BlackZ: it builds, but it doesn't completly fix the problem that the ubuntu delta is there for (thus the lintian error) - you forgot to patch "dirs"
[21:14] <tumbleweed> BlackZ: and there's also another lintian error, that should be fixed and forwarded to debian and probably patched
[21:14] <tumbleweed> s/and probably patched//
[21:14] <BlackZ> tumbleweed: well, is it the one in the bug report?
[21:15] <tumbleweed> BlackZ: dir-or-file-in-var-run is one of the things the delta is supposed to fix
[21:16] <tumbleweed> BlackZ: init.d-script-missing-dependency-on-remote_fs is the other one
[21:16] <BlackZ> tumbleweed: I was sure to merged that
[21:16] <BlackZ> and hmm I re-merged
[21:17] <tumbleweed> BlackZ: also, for neatness (and it matters in some languages like python) use same identation type when you modify files (tabs vs spaces)
[21:19] <fabrice_sp> tumbleweed, will you ake care of bug 598584 ?
[21:19] <ubottu> Launchpad bug 598584 in Ubuntu "Sync re2 0+hg23+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/598584
[21:19] <tumbleweed> fabrice_sp: heh, sure
[21:19] <arand> lachouffe: I think pavucontrol can do that..
[21:20] <tumbleweed> fabrice_sp: btw, I'm hoping upstream releases that and commits to SONAMES before squeze goes into freeze
[21:20] <tumbleweed> fabrice_sp: otherwise I'm going to remove it from testing
[21:21] <tumbleweed> fabrice_sp: but I guess Ubuntu doesn't care as much :)
[21:21] <fabrice_sp> tumbleweed, not sure about that ;-)
[21:22] <fabrice_sp> but as we sync from unstable, you're probably right
[21:23] <tumbleweed> hah
[21:32] <BlackZ> fabrice_sp: I'm doing the merge but I'm not sure 100 % about the changes, maybe you could look at it
[21:33] <fabrice_sp> BlackZ, you mean ptlib?
[21:33] <BlackZ> fabrice_sp: yes
[21:34] <fabrice_sp> what changes do you have problem with?
[21:36] <BlackZ> fabrice_sp: "+ debian/control: Build-depend on libdc1394-22-dev; add conflicts and replaces for libpt2.6.1-dev and -plugins-dc." for the second change: there's no longer the libpt2.6.5-plugins transition
[21:37] <BlackZ> where the "-plugins-dc" were added
[21:37] <fabrice_sp> libpt-1.11.2-dev is still there, it seems
[21:38] <BlackZ> yes, it's
[21:38] <fabrice_sp> so you should keep the conflict/replace stuff for this one
[21:39] <fabrice_sp> libpt2.6.1-doc is only in jaunty, so can be dropped
[21:40] <BlackZ> there's just "libpt-doc"
[21:40] <fabrice_sp> and no libpt2.6.3, it seems ,so it can be dropped too
[21:41] <BlackZ> fabrice_sp: in which version are you looking?
[21:42] <fabrice_sp> all (using u.p.c)
[21:44] <BlackZ> fabrice_sp: BTW I will file the merge, maybe you can give some recommendations there :)
[21:44] <BlackZ> (if it's necessary)
[21:49] <fabrice_sp> I'll check tomorrow (time to go to bed :-) ). Bye
[21:50] <BlackZ> good night, fabrice_sp