[01:45] <persia> kirkland: Please provide content when pinging me, so that if I'm not watching the bytestream, I can provide a useful response when I review backscroll.
[01:46] <kirkland> persia: my bad
[01:46] <persia> kirkland: No problem, but you pinged me, so surely you seek me for something, yes?
[03:20] <Elbrus> james_w: what do you think is my best approach regarding bug 275688
[05:54] <fabrice_sp> Morning. I'm fixing a bug with a package that uses cmake to generate Makefile, but it left a lot of temporary files behind, and diff file is 11 Mb! Is there a way to automatically clean the cmake temporary files or I have to put a dh_clean for all the files?
[06:00] <porthose> nxvl:  ping
[06:00] <nxvl> porthose: pong
[06:00] <porthose> nxvl: if you have a min would you look at Bug #275790 for me please
[06:00]  * nxvl checks
[06:01] <porthose> there is a debdiff attached
[06:10] <dholbach> good morning
[06:14] <nxvl> good morning!
[06:14] <dholbach> hiya nxvl
[06:20] <iulian> Good morning.
[06:20] <dholbach> hi iulian
[06:20] <iulian> Hello Daniel!
[06:37] <geser> good morning dholbach
[06:38] <dholbach> hiya geser
[06:43] <nxvl> porthose: uploading
[06:44] <porthose> nxvl:  Thanks :)
[06:52] <slytherin> should I file a bug for this? type-handling any linux-gnu generates a list which contains i686 and lintian throws error invalid-arch-string-in-source-relation i686
[08:16] <stefanlsd> Hi guys - does anyone have any suggestion as to why this builds on x86 but fails on power? - http://launchpadlibrarian.net/18056358/buildlog_ubuntu-intrepid-powerpc.wordnet_1%3A3.0-11ubuntu0.1_FAILEDTOBUILD.txt.gz
[08:19] <TheMuso> stefanlsd: Ah. The package needs to have its autoconf files, i.e configure, Makefile.in, lt-main etc regenerated.
[08:20] <TheMuso> But why it succeeds on x86 but fails on PowerPC is unusual.
[08:20] <TheMuso> stefanlsd: When I'm back on a bit later, I'll build locally on PowerPC and see what happens for me.
[08:21] <stefanlsd> TheMuso: thanks. i'd appreciate that.   btw, how would i regenerate those files?
[08:26] <stefanlsd> bbiab
[08:27] <TheMuso> ~/c~
[08:59] <didrocks> morning ^^
[09:11] <huats> morning everyone
[09:12] <k0p> g'morning
[09:12] <k0p> james_w, are you there?
[09:13] <k0p> you have commented my patch yesterday. I have several questions to do about flawed of patch
[09:14] <james_w> hey k0p
[09:14] <k0p> james_w, well
[09:15] <k0p> I'm reading your comment
[09:15] <k0p> And about the descriptions of changelog. . yeah.. I shoud me more clearly
[09:16] <k0p> did you want links to reported of bugs, out of LP?
[09:23] <james_w> k0p: I'd prefer links of bugs reported upstream, with the patches, or links to the changes in their version control.
[09:25] <k0p> james_w, something like that: http://trac.umitproject.org/changeset/3628
[09:26] <k0p> http://paste.ubuntu.com/52397/
[09:26] <k0p> changelog looks nice now?
[09:26] <james_w> k0p: yes, that would be fine. Linking to that doesn't get you the extra explanation of a bug report, but it shows that upstream already has the fix, which makes it more reliable, and means that we won't have to carry the patch forever.
[09:27] <james_w> k0p: yeah, do you have the same for the other patches?
[09:27] <k0p> links for revision?
[09:28] <k0p> I didn't have link for the revision for gksu2 issue
[09:32] <k0p> now I have to go
[09:33] <k0p> i'll post a new patch tonight
[09:33] <k0p> but some things you want to change isn't possible.
[09:38] <directhex> what time is ncommander usually about?
[09:39] <james_w> directhex: in a couple of hours
[09:39] <james_w> maybe more actually
[11:00] <HereBePython> slytherin: ping
[11:05] <directhex> he was a bit impatient
[11:06] <norsetto> directhex: pay per time connection ...
[11:30]  * wgrant snorts at #-devel
[11:30] <gaspa> james_w: sent another mail to other addresses....
[11:31] <james_w> gaspa: great, thanks
[11:31] <gaspa> james_w: but i think it'd be better to have it now, since we're near to the release.
[11:31]  * norsetto goes cooking
[11:33] <james_w> gaspa: yeah, I'd like to give it a few days to give them chance to respond
[11:33] <james_w> gaspa: having seb on board is good though. Is he going to upload a fix to Debian?
[11:34] <gaspa> james_w: it seems to
[11:35] <gaspa> we could wait a little for him too, and see what happen ;)
[11:35] <directhex> ?
[11:56] <gaspa> james_w: at a first glance seems only package aptfs is affected by the same issue. ( looked at rdeps of python-fuse )
[11:56] <james_w> nice work
[11:56] <james_w> does that need the same patch then?
[11:56] <gaspa> don't know...
[11:56] <gaspa> never used that fs.
[11:59] <directhex> hm. i wonder whether f-spot's hang-on-exit bug is valid for a SRU
[12:15] <persia> directhex: Does that hang impact logout or next-start?
[12:16] <directhex> persia, nah, just breaks the default photo management app for a seemingly random subset of users
[12:17] <directhex> so far i have three leads i'm following up on to fix it
[12:17] <persia> directhex: Define "break".
[12:17] <persia> That sounds like a problem with next-start of F-spot.
[12:17] <directhex> persia, force quit required on program exit, every time, for affected users
[12:18] <persia> Oh, so it's a very visible and annoying hang.  Yeah, that's usually OK for SRU (but not *always*).  It's worth asking someone from ubuntu-sru on -devel
[12:19] <directhex> persia, i'm waiting for some user feedback to help with my leads. since i'm unaffected, i can't debug it
[12:19] <persia> directhex: Hrm.  Missing dependency of some sort maybe, or missing conflict?
[12:20] <persia> (well, "missing conflict" is best solved by not breaking when both are installed, rather than adding a conflict)
[12:20] <directhex> persia, it's something specific to the user's environment. the reports seem to indicate that any affected users don't exhibit the same problems if they create a new user account on the same machine
[12:20] <directhex> something is "poisoning" their user accounts
[12:21] <directhex> oh, and i'm seeing vague evidence of a thread i don't expect to see, as well
[12:21] <directhex> again, it's all a bit man-in-middle right now
[12:23] <directhex> so lead #1: what point is reached in f-spot when it deadlocks?
[12:23] <directhex> lead #2: which file in ~ is causing f-spot to deadlock there?
[12:24] <directhex> lead #3: why does f-spot use an ass-backwards way to quit itself, and is the bug caused by some of its dependencies not expecting such monumentally stupid code?
[12:41] <slytherin> directhex: Is it reported on hardy? I think I have seen that but perhaps was later fixed.
[12:41] <slytherin> no hardy and f-spot combination now so can't confirm
[12:41] <directhex> slytherin, it's definitely reported against hardy, and apparently still affects intrepid.
[12:42] <directhex> slytherin, the problem is the lack of reproducibility for me - impossible to try test cases really
[12:43] <directhex> i might have a patch for gtk-sharp2 which might help, but i want to verify where f-spot is hanging before prepping a dpatch
[13:04] <huats_> norsetto: !
[13:04] <huats_> how are you ?
[13:04] <norsetto> huats_: !!
[13:04] <huats_> it has been a long time ....
[13:05] <norsetto> huats: surviving, and you?
[13:06] <huats_> kind of :)
[13:07] <huats_> i try to do my best
[13:07] <huats_> but a big big lack of time...
[13:07] <huats_> :(
[13:07] <norsetto> huats: oh yeah, there are only 24 hrs in a day, or so they say
[13:09] <huats_> that is what I heard too
[13:09] <huats_> it is a shame :)
[13:10] <persia> Nah.  There's at least 49 hours in a day.  Sometimes 49.5 hours.  The issue is that if you actually follow the sun, you don't get that many days in a week.
[13:11] <huats_> :)
[13:11] <huats_> persia: that is a way to see it indeed :)
[13:12] <persia> huats_: timezones are key.
[13:13] <norsetto> on the right polar orbit you can beat time (at least, the local one).
[13:30] <norsetto> james_w: are you going to ask for a third exception for package kit?
[13:43] <nhandler> Quick question. I'm trying to triage a bug. What compiz first enabled by default in hardy or gutsy?
[13:45] <persia> nhandler: I believe gutsy had it by default for some chipsets, but I don't know if they were the majority.
[13:48] <didrocks> dholbach: thx for the upload :)
[13:49] <dholbach> de rien :)
[13:49] <didrocks> dholbach: sorry. I really have to improve my german, I lost a lot in six year of inactivity ;)
[13:50] <dholbach> ask seb128 about my french :)
[13:52] <didrocks> sure, I will ^^ (this will free me of guilt :))
[13:54] <norsetto> dholbach: mon ami!
[13:55] <dholbach> hiya norsetto! :)
[13:55] <dholbach> comment ça-va? :)
[13:55] <norsetto> dholbach: pas tres bien :-(
[13:56]  * dholbach hugs norsetto
[13:59] <james_w> norsetto: yeah, should be the last
[14:00] <norsetto> james_w: at this rate? hmmmm
[14:01] <norsetto> james_w: seriously, why don't you ask for a standing exception?
[14:02] <james_w> we could have done, I wasn't expecting as many point releases
[14:09]  * huats__ hugs norsetto 
[14:09] <huats__> :)
[14:09] <norsetto> huats: ha! That qualifies for an hug attack!
[14:10] <huats__> exactly :)
[14:10]  * norsetto answers back with a surprise hug attack from the back et toc!
[14:10] <huats__> :)
[14:11] <Laibsch> calc: Do you think it would be possible to recompile OOo3 for hardy?
[14:11] <Laibsch> I tried but failed with libcups2-dev
[14:12] <directhex> libcupsys2-dev
[14:12] <Laibsch> which needs to be recompiled first
[14:12] <directhex> package name has changed. try libcupsys2-dev for hardy
[14:13] <StevenK> It was never libcups*-dev
[14:13] <Laibsch> StevenK: In the package provided by calc, it was
[14:13] <Laibsch> https://launchpad.net/~openoffice-pkgs/+archive
[14:14] <Laibsch> Thanks, directhex
[14:14] <Laibsch> StevenK: http://packages.ubuntu.com/intrepid/libcups2-dev
[14:15] <Laibsch> looks like you are mistaken
[14:15] <directhex> mono (1.9.1+dfsg-3ubuntu2~dhx1) hardy; urgency=low
[14:15] <directhex>   * badgerport to Hardy.
[14:15] <directhex>     - libcups2-dev my arse. Back to libcupsys2-dev.
[14:15] <directhex>  -- Jo Shields <directhex@apebox.org>  Fri, 22 Aug 2008 09:35:18 +0100
[14:22] <norsetto> james_w: re. gforth, it has no r(b)depends, it shouldn't require any rebuild/transition
[14:22] <Laibsch> calc: I have made that build-time dependency libcupsys2-dev|libcups2-dev now and trying recompilation for hardy now.  Maybe you want to do the same?
[14:23] <james_w> norsetto: ah, should have spotted that thanks. I'd still like to know if there are any compatibility worries.
[14:23] <norsetto> james_w: the only point is if enabling the C interface will not change anything else
[14:23] <norsetto> james_w: perhaps its worth asking upstream
[14:24] <james_w> yeah
[14:24] <norsetto> james_w: but it doesn't look as if you need an exception (IMO)
[14:25] <james_w> no, I didn't think it did, but I was assuming that motu-release might like to be aware of it, and help to pick the best solution
[14:35] <norsetto> james_w: hehe, just opened planet and got you looking smirkly at me
[14:36] <james_w> :-)
[14:36] <norsetto> james_w: where are you in Bristol?
[14:37] <james_w> norsetto: behind the University, on St. Michaels Hill. You know the city?
[14:38] <norsetto> james_w: oh yeah, thats a nice zone, one of those I prefer
[14:39] <huats__> james_w: you'll figure out that norsetto knows every city....
[14:40] <huats__> he knows my place too :)
[14:40] <slytherin> does anyone know what is rpm equivalent of dpkg --info?
[14:40] <norsetto> huats__: its not my fault if you guys live in cities I often visited for my work ...
[14:42] <norsetto> huats__: I must have spent half of my life in Bristol and Toulouse (and a fair chunk in Bremen)
[14:42] <huats__> :)
[14:43] <directhex> usage figures for my third party repo are getting pretty high
[14:52] <norsetto> james_w: we used to have a pint on the waterfront and then climb Park Street to have food, sometime as farther as Clifton
[14:53] <james_w> nice
[14:53] <directhex> i could go for a pint right now
[14:54] <norsetto> directhex: cheers
[14:55] <bddebian> Heya gang
[14:56] <azeem> hi Barry
[14:56] <norsetto> huats__: all I remember of these towns are the restaurants ;-)
[14:56] <bddebian> Hi Michael
[14:56]  * norsetto bows to super master bddebian
[14:57] <huats__> :)
[14:57] <bddebian> pfft, Hi norsetto
[14:58] <huats__> I am sure you remember restaurant AND girls :)
[14:58] <huats__> norsetto ;)
[14:59] <norsetto> huats__: well,they certainly remembers me ... some of them still have nightmares
[15:00] <directhex> haven't been to bristol for years
[15:00] <norsetto> directhex: are you in England?
[15:01] <directhex> bien sur!
[15:01] <norsetto> directhex: well, I won't ask you where otherwise huats will complain
[15:01] <RainCT> wow, bluetooth has really improved since I last tried it :)  </random_comment>
[15:02] <directhex> RainCT, i hear some loser even wrote a driver for the sony bluetooth ps3 remote, in python of all things
[15:02] <directhex> norsetto, use the hostmask, man!
[15:03]  * norsetto wears the hostmask, pretending to know what it is
[15:04] <RainCT> norsetto: heh. «norsetto [n=Cesare@79.9.219.141] []» that's not the hostmask ;)
[15:06] <RainCT> directhex: I guess I'm a loser too if I'm trying to get my phone to work over the USB connection? :)
[15:06] <directhex> of course!
[15:07]  * norsetto thinks that the only thing that python seems to be good at is producing tracebacks
[15:07] <directhex> norsetto, i agree wholeheartedly. people should be using c# instead!
[15:07] <norsetto> directhex: pfff, real men do it with perl
[15:08]  * directhex has written gui apps with perl, now...... doesn't.
[15:08] <nhandler> directhex: With GTK?
[15:08] <RainCT> uhm.. you (ie, someone) said that the REVU Coordinator has a stab, right?  /me looks evil at norsetto  :D
[15:08] <directhex> nhandler, aye
[15:08] <norsetto> RainCT: no idea what a stab is, is it edible?
[15:09] <nhandler> directhex: I tried using GTK for an image steganography application I made in perl. Lets just say that I do not do GUI applications in perl anymore.
[15:09] <RainCT> norsetto: it's me not knowing English :P
[15:10] <norsetto> RainCT: stab is actually an english word (cf. stabbing someone to death)
[15:10] <RainCT> s/stab/stick
[15:10] <directhex> nhandler, i wrote a launcher for a doom engine in gtk-perl, and also wrote an ldap systems management tool in perl
[15:11] <RainCT> norsetto: right, but it's the action; I thought that it also is an object :P
[15:11] <norsetto> RainCT: I guess one would use a stab to stab and a stick to, well, to stick
[15:11] <directhex> nhandler, the latter exists only as a tarball in some long lost directory, having been replaced by a c# version so much better (and easier to code) it defies belief
[15:11] <nhandler> directhex: I have no issue with perl itself (I actually prefer it over most languages). I just hate doing GUI applications in it. My current perl project is an IRC bot for the Beginners Team
[15:11] <directhex> sticks are for poking. knives for stabbing. it's all very zen.
[15:12] <directhex> nhandler, http://packages.ubuntu.com/intrepid/libsmartirc4net0.4-cil ;)
[15:12] <RainCT> norsetto: the dictionary says that stab is "the act of stabbing"/"a wound..."/"an attempt"/"a painful sensation", but perhaps I'm unable to read the dictionary, too ^^
[15:14] <RainCT> directhex: back to bluetooth: the nautilus plugin still sucks, though :P
[15:14] <RainCT> (it only has browsing implemented)
[15:14] <directhex> RainCT, aye
[15:14] <directhex> RainCT, konq is better with it
[15:14] <RainCT> why can't they use a common backend for everything then? -.-
[15:15] <persia> RainCT: which bluetooth?
[15:15] <RainCT> persia: EMENOTUNDERSTAND :$
[15:16] <RainCT> I'm using a dongle, if that's what you mean
[15:16] <persia> RainCT: Well, I've been testing superm1's updates to bluetooth, and I was wondering which part was particularly painful for you, and which version of which bluetooth tools you were using when you experienced the pain.
[15:17] <RainCT> (is en.wikipedia.org dead? o_O)
[15:17] <superm1> persia, i'm going  to be making a few changes to the packages yet that might break the upgrade from ppaX to ppaY.  i'm going to avoid doing too many more NEW packages until debian has decided that they will
[15:17] <superm1> persia, just so that we dont put ourselves into an uncomfortable situation
[15:18] <RainCT> persia: Ah, it's not really painful, just suboptimal. I can send files to the phone using the applet, but the nautilus plugin only supports browsing; tried that with the bluez-utils versions from Hardy and Intrepid.
[15:18] <persia> superm1: Sounds good to me.  I'm just running live sessions anyway.  Ping me when you want a round of tests: I've three environments working now.
[15:18] <superm1> persia, okay great.
[15:19] <persia> RainCT: The context-menu sendto isn't working for you?
[15:19] <superm1> persia, other update regarding this, there's a bunch of stuff that needs to be rebuilt for the library transition.  some of it is faililng to build from missing symbols (assumingly not present in the SONAME bump).  that will all be on a separate bug though
[15:20] <RainCT> (btw, if someone here has a samsung sgh-vz60, please ping me)
[15:20] <persia> superm1: Hrm.  Are you throwing it all in the PPA?  I don't mind downloading a bunch of stuff, or even uploading some, but expect my test results will more accurately reflect the target environment with a more complete install.
[15:21] <RainCT> persia: I don't have such a menu - /me is trying to drag into an obex://... location in Nautilus (opened by clicking "Browse..." in bluetooth-applet)
[15:21] <superm1> persia, Well StevenK is doing some test wrg to rebuilds.  StevenK do you want  to put the ones that you've got functional into the bluetooth PPA so that we'll have as close to what will reflected in the archive there?
[15:22] <persia> Oh.  I hadn't tried that.  I'll include it as a test in my next round, unless you want to try ~bluetooth/+archive
[15:23] <slytherin> RainCT: the menu is available for the bluetooth applet in panel.
[15:23] <StevenK> superm1: That requires munging their versions to include ~ppa1, doesn't it? :-(
[15:23] <RainCT> persia: I can have a try if they work in Hardy (yeah, I'm still using it.. I may do a clean Intrepid install once beta is out, though)
[15:23] <superm1> StevenK, well if you *know* that there won't be any more improvements to the package, you can upload them as they stand
[15:23] <superm1> eg if they were no source rebuilds
[15:23] <superm1> or a very small diff
[15:23] <persia> StevenK: Ideally, although not strictly required: it depends if you want to support upgrades.
[15:24] <RainCT> slytherin: Ah, OK. Yes, that's the one which works. I thought persia was talking about a "Send to.." option in Nautilus or something
[15:24] <persia> RainCT: No, they won't work in hardy.
[15:25] <RainCT> Something more: I've just tried sending from the phone to the PC and that doesn't work.
[15:25] <persia> RainCT: Yes I was.  For me, nautilus send to supports BT.
[15:25] <slytherin> RainCT: there is an option in nautilus also and it should work. Although I haven't tested recently in hardy as well as intrepid. I plan do to some test with new stack in a day or two
[15:25] <persia> RainCT: Did you check the "Receive files from remote devices" box?
[15:28] <RainCT> persia: yes, it's checked
[15:28] <persia> Odd.  Do you have a Symbian handset?
[15:28] <RainCT> persia: and I haven't nautilus-sendto; installing it now..
[15:29] <RainCT> persia: nope, it's a samsung phone
[15:29] <RainCT> (or rather not, it wants to install evolution)
[15:31] <Oobalicious> Question: currently, all parts of VTK in the Ubuntu repos are v5.0.3. I've managed to get 5.2.0 packaged up, but not all of it - specifically, I know nothing about Qt, Tcl and Tk, so I don't want to try getting those to work. Would the maintainers accept updates for some packages if it means leaving others behind? I think they should still work, but I wouldn't know.
[15:32] <norsetto> RainCT: hmmm, the suggests to sylpheed-claws in nautilus-sendto seems quite obsolete
[15:36] <james_w> Oobalicious: if what is in the archive currently works and is consistent, then I think we would prefer that over a mixed bag
[15:36] <james_w> Oobalicious: unless it doesn't matter that the versions are mixed
[15:36] <Oobalicious> Oobalicious, OK, that's understandable - I'm packaging up 5.2 because the research group I'm working for needs the extra features for a couple of things.
[15:37] <Oobalicious> Now why did I just mention my own name in that?
[15:37] <Oobalicious> Ah, well.
[15:37] <james_w> :-)
[15:38] <Oobalicious> OK, I'm not sure I would be able to figure out whether a mixed bag would work - like I said, I have no experience with Tcl, Tk or Qt, so I couldn't update those packages without feeling uneasy.
[15:38] <Oobalicious> I mean, I have the files - it would just be a matter of downloading the old package, replacing the old files with the new ones and packaging it up again - but I'd like someone to test it.
[15:38] <Oobalicious> Perhaps if I packaged everything up and sent it to the VTK mailing list for testing.
[15:41] <RainCT> Oobalicious: [Disclaimer: I don't know the package about which you ask] Intrepid is in Feature Freeze since a while already (the latest beta is about to be released), so it will be difficult to get anything new into Ubuntu before Intrepid has been released.
[15:42] <RainCT> Oobalicious: Your work may be useful once the development cycle for Jauny starts, though :).
[15:42] <superm1> StevenK, persia okay but 276343 will help track the transition
[15:42] <superm1> bug 276343 that is
[15:42] <Oobalicious> Should still be worth contributing if I can, though - we'll be adding the package to our own repository, so it's not an issue for us, but it'd be nice if it was in the central repos.
[15:42] <superm1> StevenK, would it be easyish to publish those failed build logs anywhere for you?
[15:43] <Oobalicious> RainCT, I'm only here 'til Friday - after that, I start university up again and I won't have time to do stuff like this... perhaps I should send it to the VTK people and they can do what they like with it.
[15:43] <StevenK> superm1: Easier than uploading a bunch to the PPA with different version numbers :-)
[15:45] <RainCT> Oobalicious: Sure. There is no dedicated maintainer for VTK in Ubuntu, but you can contact the Debian Maintainer of the package (at bottoms@debian.org, sending a copy to bugs.debian.org).
[15:46] <Oobalicious> OK, will do.
[15:46] <superm1> persia, any idea what this "gnome-bluetooth" package is?
[15:47] <superm1> i'm assuming it was something from back before bluez-gnome existed
[15:47] <directhex> yes
[15:47] <directhex> ii  gnome-bluetooth                       0.11.0-0ubuntu1                       GNOME Bluetooth tools.
[15:47] <persia> superm1: It's an old phone-discovery wizard by Edd Dumbhil
[15:47] <superm1> should we just request it be removed from the archive then?
[15:47] <persia> Dumbill*
[15:47] <directhex> the main highlight is /usr/bin/gnome-obex-server
[15:48] <StevenK> superm1: http://people.ubuntu.com/~stevenk/bluez/
[15:48] <directhex> which is a tray icon app which lets you send files to pc from phone
[15:48] <directhex> s/main/only/
[15:48] <persia> Bastien Nocera is the titular maintainer, and it's related to the backend of gnome-phone-manager, but I've not used in it ages, as none of my phones are ever supported.
[15:48] <superm1> directhex, that's the same purpose as as obex-data-server then
[15:49] <superm1> just i think if some of these packages dont rebuild after the transition, it wouldn't make sense to have them available
[15:49] <directhex> yes
[15:50] <persia> superm1: Dropping gnome-bluetooth would be better than keeping it.
[15:50] <superm1> persia, okay i'm going to file a bug for that and mark it won't fix on our transition bug
[15:50] <superm1> keep an eye out for any of those that the same thing makes sense
[15:51] <persia> superm1: Sounds good.  I've just confirmed that gnome-phone-manager doesn't rely on it anymore.
[15:58] <StevenK> superm1: Bug 276343 description edited
[16:00] <superm1> StevenK, thanks.  the build failures at http://people.ubuntu.com/~stevenk/bluez/bluetooth-alsa_0.5cvs20080115-1build1_20080930-1851 looks quite peculiar
[16:01] <superm1> i'm not sure that's a related failure
[16:01] <StevenK> superm1: pilot-link uploaded
[16:02] <StevenK> superm1: I doubt it's related, I suspect it's due to the libtool transistion
[16:03] <superm1> StevenK, that's going on "right now" during a freeze?
[16:03] <StevenK> superm1: No, it's been on-going for ages and ages
[16:04] <superm1> StevenK, then there a pretty basic fix for how to adjust for it then?
[16:05] <StevenK> superm1: First step is to re-libtoolize
[16:06]  * RainCT just send his 3th mail to Samsung's support.. let's see if someone finally tells me what protocol the damn phone uses for data transmission over USB :P
[16:14] <StevenK> superm1: Right, bluetooth-alsa fixed
[16:14] <superm1> StevenK, ok cool.  i've updated the status for most of the tasks that are fixed now
[16:14] <StevenK> % debdiff bluetooth-alsa_0.5cvs20080115-1{,ubuntu1}.dsc | diffstat | tail -n 1
[16:14] <StevenK>  4 files changed, 7083 insertions(+), 5622 deletions(-)
[16:15] <jdong> sounds like fun :)
[16:15] <jdong> I hope most of that is cruft?
[16:15] <StevenK>  ltmain.sh                                      |12694 +++++++++++++------------
[16:15] <jdong> yup
[16:15] <superm1> StevenK, hum you have libpam-blue and libwiimote on both lists.  which one should they be on?
[16:16] <StevenK> superm1: Which both?
[16:17] <superm1> the FTBFS and the minor changes lists
[16:17] <StevenK> Mmm
[16:17] <StevenK> Checking
[16:18] <StevenK> superm1: Fixed
[16:20] <StevenK> Right, libpam-blue is the only real failure that isn't hci releated
[16:20] <StevenK> *related
[16:20] <superm1> okay so it shouldn't be on the pass list
[16:21] <jdong> siretart: is there a reason we don't build with rtsp streaming support for VLC?
[16:22] <jdong> (i.e. bug 275980)
[16:22] <siretart> jdong: I've pinged xtophe in #videolan about this, still waiting for a response. you might want to ping him yourself, maybe I've just overlooked his response
[16:22] <siretart> jdong: short: I have no idea :)
[16:23] <jdong> siretart: sounds good! :D
[16:30] <StevenK> superm1: I need to sleep. I'll sort out the unknowns and libpam-blue when I re-surface
[16:31] <directhex> libpam-blue?
[16:31] <directhex> bluetooth proximity pamming?
[16:32] <directhex> that is awesome and epic
[16:33] <jdong> directhex: makes for good denial-of-service attacks though :)
[16:33] <jdong> directhex: I wonder if I remove the magnetron from my microwave how many screens I can lock :)
[16:34] <directhex> jdong, mark it as sufficient in the pam config, surely?
[16:34] <directhex> jdong, i.e. it's enough, but fall back to unix2?
[16:34] <jdong> directhex: I wa thinking of the bluetooth screen locking applet
[16:34] <jdong> directhex: blueproxy or something like that
[16:35] <jdong> it locks your screen as your BT device goes out of range
[16:35] <StevenK> I'm no longer paired to <device> *lock* ?
[16:35] <jdong> yeah
[16:35] <jdong> StevenK: rather, even weak signal
[16:35] <directhex> jdong, ctrl-alt-f1, killall blueproxy
[16:35] <directhex> ;)
[16:35] <jdong> lol
[16:35] <directhex> or whatever
[16:35] <StevenK> directhex: At a login prompt?
[16:35] <directhex> StevenK, all the cool kids have init set to spawn a root term on console 1!
[16:36] <StevenK> If they do, they don't be deserve to be cool
[16:36] <directhex> StevenK, and like i said, use sufficient in the pam config so an empty password works with bluetooth, or a real password with no bluetooth
[16:36] <norsetto> RAOF: ping
[16:36] <StevenK> norsetto: It's 1:36am local, RAOF is sleeping, probably
[16:37] <directhex> why do i need 8 gig of dvd isos in order to get access to basic packages with sles? why do they hate online repos so much? silly novell
[16:37] <jdong> directhex: I used the USB PAM thing before so I guess I shouldn't speak about security :)
[16:37] <norsetto> StevenK: ah, I though he was in Austria
[16:37] <StevenK> No, the Austr*
[16:37] <jdong> directhex: isn't it because they don't want non-licensed users to get access to the medium?
[16:37] <StevenK> the other
[16:37] <norsetto> StevenK: yes :-)
[16:37] <directhex> jdong, so hide them behind the same https servers they use for security updates. being a sles admin sucks
[16:38] <directhex> SLE-10-SP2-SDK-DVD-ia64-GM-DVD2.iso           100% 4478MB  29.9MB/s   02:30
[16:38] <jdong> you poor thing
[16:38] <directhex> all this for imagemagick
[16:38] <StevenK> Two reasons to hate that. First, SLES. Second, ia64
[16:38] <directhex> ia64 isn't hate. it's love!
[16:39] <StevenK> It's hate
[16:39] <directhex> jms@orac:~> grep -c IA-64 /proc/cpuinfo
[16:39] <directhex> 256
[16:39] <directhex> it's love, in large quantities
[16:39] <superm1> StevenK, i'll take a look today too at what i can for making some patches to work around the API change
[16:39] <StevenK> superm1: \o/
[16:39] <StevenK> superm1: Both of us should be able to nail down the 34 packages :-)
[16:40] <superm1> StevenK, yeah, and afaik, this is the last gating factor on the bluez 4.x transition
[16:40] <superm1> StevenK, so should be good :)
[16:51] <RainCT> slomo: Hey, I had forgotten about it... Can you please upload gbrainy 1.00 to experimental?
[16:59] <RainCT> http://rainct.homelinux.net/gbrainy/1.00-1/gbrainy_1.00-0ubuntu1.dsc
[17:04] <Laibsch> Any kind soul here to help me compile libsaxonb on hardy? -> bug 276391
[17:05] <Laibsch> Is there a tool to check if a package has unsatisfiable (not just unsatisfied) build time dependencies?
[17:08] <geser> Laibsch: what's the difference?
[17:09] <Laibsch> unsatisfiable = package not available in feeds
[17:09] <Laibsch> unsatisfied = package not installed
[17:09] <persia> Laibsch: Try apt-get --simulate build-dep foo
[17:10] <Laibsch> persia: How about for a package that is not (yet) in the feeds, like OOo3, for example
[17:10] <Laibsch> ?
[17:10] <persia> You can probably hack something with a customised apt.conf and pbuilder-satisfydepends.
[17:11] <Laibsch> OK
[17:11] <Laibsch> Don't feel like hacking too much
[17:11] <Laibsch> It'll be just trial and error, then ;-)
[17:11] <geser> Laibsch: re saxonb: try installing java-gcj-compat-dev before calling debuild -S (you need often a subset of the build-dependencies for building the source package)
[17:12] <Laibsch> OK, will do
[17:12] <Laibsch> Is that still a bug?  I mean only want to create orig.tar.gz, diff and dsc
[17:14] <geser> Laibsch: it's not a bug, you need the packages installed which are called in the clean target (here apparently java is needed)
[17:20] <persia> Yeah, Java is annoying about the number of things that need to be installed to build source.
[17:21] <sebner> persia: don't force me to use ohmygod! :P
[17:22] <persia> sebner: ?
[17:22] <sebner> persia: J-word is evil :P
[17:22] <sebner> aloha emgent
[17:23] <geser> persia: in such cases I use dpkg-source -b and dpkg-genchanges when sponsoring a ready debdiff
[17:23] <sebner> geser: \o
[17:24] <persia> geser: Ah.  I actually test, as I've been hit N times with incorrect balance of Build-Depends: and Build-Depends-Indep: on the buildds.
[17:24] <emgent> aloha people
[17:24] <persia> sebner: No language is inherently evil.
[17:25] <geser> persia: I do that too (test build with pbuilder) but I need a new source package first
[17:25] <ScottK-laptop> persia: Not inherently, but some seem to have evil thrust upon them.
[17:25] <Ooble> Question: if a language is predominantly used for evil purposes, does that make it evil?
[17:25] <geser> and I'm to lazy to install java just to be able to call debuild -S
[17:25] <Ooble> I'm not entirely sure why I'm prefixing all my questions with "Question:" today.
[17:26] <sebner> ScottK-laptop: +1
[17:26] <persia> geser: I have a special "Build Java packages from source chroot".
[17:26] <persia> ScottK: Indeed.
[17:26] <geser> Ooble: as long as we don't need to prefix answers with "Answer:" everything is good :)
[17:27] <Ooble> It would be amusing, but I guess it's not necessary.
[17:28] <Laibsch> Well, I installed another 100MB of software and apparently that still is not enough.  The error now is "You must specify a valid ANT_HOME directory!"
[17:28] <geser> Laibsch: have you ant installed?
[17:28] <Laibsch> I should have thought of the dpkg-source, dpkg-genchanges route before
[17:29] <Laibsch> geser: I just want this package built, so I can go on building OOo3
[17:29] <geser> Laibsch: do you want to build it locally or in a pbuilder?
[17:30] <Laibsch> Well, I dget the stuff on my local box, change the changelog, sign things and then upload to PPA
[17:30] <Laibsch> So, eventuall, it will be pbuilder
[17:30] <Laibsch> y
[17:30] <Laibsch> All that Java cruft is going away from my computer again.
[17:31] <Laibsch> Let's hope dpkg-source, dpkg-genchanges doesn't run into trouble
[17:37] <geser> Laibsch: don't try to run debuild -S and if that fails dpkg-source -b as that might get some cruft into the .diff.gz
[17:40] <Ooble> Does MOTU actually stand for Masters of the Universe or is that my overimaginative brain going haywire again?
[17:41] <cody-somerville> It actually stands for Masters of the Universe.
[17:41] <nxvl> on that's because the repo we care about it's called universe
[17:41] <nxvl> and we master it
[17:41] <nxvl> \o/
[17:42] <nxvl> and i'm quite sure about a geeky story involving he-man
[17:42] <Laibsch> Ooble: In case you take offense at my question, my apologies.  But the way I understand it, this channel is also the ubuntu equivalent of #debian-mentors
[17:42] <Laibsch> questions
[17:43] <nxvl> Laibsch: ye sit is
[17:43] <Ooble> Laibsch, no, 'twas an honest question and a poor attempt at humour.
[17:44] <Ooble> I can stop that if you like.
[17:44]  * nxvl is lost
[17:46] <nxvl> We should do the "Question:" "Answer:" day i found it amusing too
[17:48] <Laibsch> Ooble: Don't worry.  I was just worried about a possible misunderstanding.
[17:51] <Ooble> Gotcha Laibsch - no worries.
[17:51] <Ooble> I'm new here.
[17:52] <iulian> Hi
[17:55] <persia> We used to have Q&A sessions every Friday at 13:00 UTC.  If people are interested, it's likely possible to reoccupy classroom and bring them back.
[17:56] <persia> The criticism was that they discouraged people from just asking questions here.
[17:56] <slytherin> superm1: ping
[17:56] <superm1> hi slytherin
[17:57] <slytherin> superm1: I was about to install the bluez packages form PPA. I have two questions. Where is bluez-audio package? Is it replaced with bluez-alsa? Why don't we have bluez-utils package anymore.
[17:58] <superm1> slytherin, can you hold off a little bit?
[17:58] <superm1> slytherin, what i'm doing right this moment is moving it back to the old package names
[17:59] <slytherin> superm1: sure.
[17:59] <superm1> the upgrade from the current ppa version to the one i'm doing won't be clean - but the intrepid version to this ppa version will be OK
[17:59] <superm1> slytherin, for that exact reason, don't want to introduce NEW packages that debian hasn't necessarily ack'ed
[17:59] <superm1> it will make for a really ugly upgrade scenario in jaunty if we do
[17:59] <slytherin> I understand that.
[18:00] <slytherin> superm1: I also think the input, serial, network packages should be dropped.
[18:00] <slytherin> as debian has not split packages like that.
[18:00] <superm1> slytherin, yeah that's what i'm doing
[18:03] <slytherin> superm1: one last comment. You have a dependency problem. bluez-gnome depends bluetooth which intern Recommends bluez-alsa, -cups, and -gstreamer. This I think is necessary. Let me know if you need any help fixing the packages.
[18:03] <superm1> slytherin, why is that a problem?
[18:03] <norsetto> persia: I thought those sessions were pretty good, especially for people to break the ice
[18:05] <slytherin> superm1: doesn't seem to be a problem. I first thought bluetooth was in universe.
[18:05] <superm1> slytherin, something you can help with, can you find bugs that are resolved by these uploads?
[18:05] <superm1> and put them into the changelog in bzr?
[18:06] <slytherin> superm1: he he, I stay away form bzr. :-P But I can find bugs fixed by looking at the test reports done till now.
[18:06] <superm1> slytherin, well even a pastebin'ed changelog entry is fine
[18:06] <superm1> i'll put it in bzr if you dont like bzr
[18:06] <slytherin> will do. give me some time.
[18:06] <superm1> but it'd be good to close off a lot of the reports that should be fixed here
[18:06] <superm1> i'm sure there are plenty
[18:07] <persia> norsetto: Yeah, there were positive aspects too.  I'm not sure if they are an overall good or not, but they are currently unstaffed.
[18:07] <norsetto> persia: yes, that's too much work
[18:09] <persia> norsetto: Well, it's an hour a week, for two or three people.  Needs a coordinator, and some volunteers.  We could probably get some sessions going for next cycle with a little planning now, and a call for volunteers for midday Friday.
[18:09] <persia> Might even work better with a rotating time or something.
[18:10] <norsetto> persia: I won't have any problem to do the odd one
[18:11] <persia> norsetto: Excellent.  Do you think you have time to round up some people to do the bulk of them?
[18:11] <norsetto> persia: I would think james_w should do that as part of the school
[18:12] <persia> james_w: Does that make sense to you?  Would you have time to organise such a thing?
[18:12] <persia> nxvl: You've previously expressed interest in school and coordination: want to be the MOTU Q&A guy?
[18:12]  * nxvl prepares to run scared will reads the scroll
[18:13] <nxvl> s/will/while
[18:14] <nxvl> ok, i'm lost
[18:14] <nxvl> oh
[18:14] <nxvl> Q&A sessions
[18:14] <nxvl> persia: of course
[18:14]  * nxvl sits back again
[18:15] <nxvl> and i'm sure i can find some volunteers in the way
[18:16] <persia> nxvl: Excellent.  Please coordinate with dholbach to discover history, james_w about scheduling with MOTU/School, pleia2 about reserving #ubuntu-classroom for the sessions, and send out a mail asking for two or three MOTU to staff each Q&A session during the jaunty cycle.  You probably need a couple wiki pages for coordination.
[18:17] <nxvl> oh god i hate kelly bundy
[18:17] <nxvl> persia: ok, will do, i have long talks with dholbach really often
[18:17] <nxvl> and with james too
[18:18] <nxvl> my brain is in a full fifo buffer state
[18:18] <nxvl> needs to flush stuff before letting more things in
[18:18] <nxvl> -> kelly bundy syndrome
[18:18] <persia> nxvl: Cool.  Note that there was some controversy that caused the sessions to end.  I don't remember exactly why.  You probably want to start the discussion early to hear various opinions before you get going too much.
[18:18] <slytherin> superm1: There are loads of bugs and it hard to see which are fixed without testing packages. Also as of now with current versions in intrepid nothing is working in bluetooth.
[18:18] <james_w> nxvl: I'd like to help with that, lets chat at UDS
[18:18] <slytherin> I mean on my machine
[18:19] <nxvl> james_w: why to wait? let's chat now and extend it at UDS :D
[18:19] <persia> slytherin: Not even obex comms?  I know I tested that against the current stack in intrepid.
[18:19] <superm1> slytherin, okay well i've almost got things together.  i'm just doing a test right now to make sure the upgrade goes right from stock intrepid before i push to the ppa again
[18:19] <james_w> nxvl: sure. Well, not now, but we can chat this week for sure
[18:19] <nxvl> persia: ok, i will talk with daniel tonight as usual to see what happens there
[18:19] <nxvl> james_w: yeah, that's what i mean, i'm quite busy too
[18:20] <slytherin> persia: only phone to PC works. I am wondering if this is a hardware issue.
[18:22] <persia> slytherin: Odd.  Can your phone receive from other sources?
[18:22] <slytherin> persia: yes, I did phone to phone transfer sometime back.
[18:22] <DBO> so if I know of a fix for a suspend bug for new thinkpads, but it requires updating some core libs, is it worth trying to get it into intrepid?
[18:23] <persia> DBO: Which libraries?
[18:23] <DBO> libdrm2 and xserver-xorg-video-intel
[18:23] <DBO> without the fixes, the new Thinkpad T500 series will not suspend properly when Acceleration is enabled
[18:24] <slytherin> DBO: is it possible to create a patch doe this libraries. Something cherry picked form respective upstream svn
[18:24] <DBO> for intel, likely?
[18:24] <DBO> for libdrm, not very likely
[18:24] <DBO> i mean I couldn't do libdrms patch at least
[18:25] <DBO> the intel one is a single commit that fixed it, but it depends on a more recent libdrm to do vt switching
[18:25] <slytherin> oh
[18:26] <persia> DBO: Does the libdrm change cause an ABI change?
[18:26] <DBO> no
[18:26] <persia> There's a (low) chance.  Submit the patches in a bug.
[18:26] <DBO> I was running a more up to date libdrm for some time without changing anything else on my system while debugging
[18:27] <DBO> to be fair, I dont know if a patch is whats needed, it really needs to git libdrm
[18:27] <persia> Erm.  What do you mean by "more up to date drm"?
[18:27] <DBO> git head
[18:27] <DBO> is it possible to maybe make a package for libdrm-git and place it in universe
[18:27] <persia> Yes, that's ABI incompatible with what is currently in intrepid.
[18:27] <DBO> for users like me who need it?
[18:28] <persia> There's one in the nouveau-snapshot PPA.
[18:28] <DBO> yeah it has to be more recent than that one actually
[18:28] <DBO> within the last 7 days
[18:28] <persia> That gets updated weekly.  It ought be fixed soon.
[18:29] <DBO> okay, but that doesn't create the matching intel xorg driver thats needed for users
[18:29] <DBO> both are needed to fix the bug
[18:31] <slytherin> DBO: Does the intel drive fix has any fallback mechanism? i.e. what is latest libdrm is not available, will it crash?
[18:31] <DBO> it does not crash
[18:31] <DBO> but it will fail to VT switch on some intel cards
[18:32] <DBO> so it has regressions without libdrm-git
[18:34] <slytherin> DBO: regressions as compared to current functionality?
[18:34] <DBO> yes
[18:34] <superm1> slytherin, okay i've uploaded the new version to the PPA
[18:35] <superm1> so as soon as it publishes you can carry onward with testing
[18:35] <DBO> if you just update the intel driver, and not libdrm, you get serious regressions
[18:35] <DBO> if you update both, you get no regressions
[18:35] <DBO> if you just update libdrm, you get no regressions, but you gain nothing
[18:35] <superm1> slytherin, one thing i know is fixed, but forget the bug number is that the dfutool is now included
[18:35] <superm1> i think there was a bug report on that at some point
[18:36] <slytherin> superm1: Ok. I can test data transfer and input with my phone. Let's just hope my dongle is not faulty.
[18:39] <superm1> slytherin, the version number is bluez-4.9-0ubuntu1~ppa3, make sure you are offered that before you install fromthe PPA
[18:39] <superm1> the ppa2 version will make the ugly upgrade
[18:39] <slytherin> superm1: yes. I am checking changelog. I don't understand this comment - It was generated by merging the contents of bluez-utils and bluez-libs       and updating content.
[18:39] <superm1> slytherin, literally there are no longer bluez-libs and bluez-utils source packages
[18:40] <superm1> slytherin, just one big "bluez" source package now
[18:40] <slytherin> superm1: yes but then the change was done upstream right? Your comment sounds like we merged the source packages.
[18:45] <superm1> slytherin, oh the debian/ directory was merged between the two
[18:45] <superm1> that's what i was meaning
[19:37] <slytherin> superm1: bluez-utils is trying to overwrite /usr/lib/bluetooth/plugins/audio.so
[19:38] <persia> slytherin: Without Replaces: ?
[19:38] <slytherin> persia: Yes, upgrade fails form intrepid
[19:38] <slytherin> I wan't using any previous PPA versions.
[19:38] <persia> Bother.  I was about to pull those.  Can you fix and push, or do you not have upload to that PPA?
[19:38] <slytherin> Either bluez-utils should not contain the file or it should add replaces
[19:39] <slytherin> persia: I can. Let me get source package
[19:39] <slytherin> persia: which approach should I follow? remove the .so file from bluez-utils right?
[19:40] <persia> slytherin: Which package owns it now?  Is that package name in the new set?  Does the package in the new set provide that file?
[19:41] <slytherin> persia: In intrepid the file is owned by bluez-audio
[19:42] <slytherin> new set has bluez-audio. let me check it's contents
[19:43] <persia> slytherin: And is it in the new bluez-audio?  (aptitude download + dpkg --contents may help here)
[19:43] <slytherin> persia: No it is not. So the file needs shifting from one package to another.
[19:46] <persia> slytherin: Well, that needs a bit of investigation.  If the file *should* switch, then you need versioned conflicts & replaces.  If the file *shouldn't* switch, then you need to fiddle the package split.
[19:47] <slytherin> persia: I understand what you mean. Only audio.so should got to bluez-audio. Rest should remain in bluez-utils.
[19:48] <persia> slytherin: Maybe.  As you've seen over the last month, I've never really had time to look at this, aside from doing some tests to see if any given candidate solution works yet.
[19:49] <slytherin> persia: I will look into this and add versioned replaces
[19:49] <superm1> slytherin, ah i didn't run into that because i used dpkg -i
[19:49] <superm1> slytherin, i'll push a fix in a minute
[19:49] <persia> slytherin: If audio.so doesn't need to move between packages, you don't need versioned replaces, you just need to change where the file is installed.  It really depends what depends on what.
[19:49] <slytherin> superm1: I am working on it already
[19:50] <persia> (at a library level, not at a package level)
[19:50] <superm1> persia, what's your take on what marcel is staying?
[19:50] <slytherin> persia: right. The file went to bluez-utils by mistake because of the *.so expression.
[19:50] <superm1> about choosing to adopt the names upstream chooses
[19:51] <superm1> i'd really like to do that, but slangasek brought up the good point yesterday about what's going to happen at jaunty if debian doesn't agree with the naming
[19:52] <slangasek> I think the Debian package split is wrong, and I remember much squinting when it was done
[19:52] <slangasek> but I'm concerned about the divergence from Debian, yes
[19:53] <persia> superm1: The pkg-bluetooth folk seem nice enough.  Probably best to chat with them.  I don't really like /etc/init.d/bluetoothd either.
[19:53] <persia> (and yes, they don't want to talk much until squeeze)
[19:53] <superm1> persia, i've tried to ping godog about it
[19:53] <superm1> but he hasn't responded at all
[19:54] <superm1> persia, that was mostly a hack to workaround an issue where bluez-utils couldn't purge.  it's reverted anyway now though since we're back at the same names as prior
[19:55] <slytherin> superm1: I remember Marcel complaining even when the bluez-audio package was created.
[19:55]  * persia looks at the bugs and ML archives again to get some current context
[19:55] <superm1> well I say lets go out the door with intrepid with the the same names as debian, and have the discussion started on the pkg-bluetooth team's mailing list then
[19:56] <slytherin> superm1: here is debdiff. I haven't actually built it. I didn't add any changelog entry just bumped the version. http://paste.ubuntu.com/52562/
[19:56] <superm1> and if they dont agree, we start divergence in Jaunty so as to prevent any other unnecessary issues now
[19:56] <superm1> gives us more time to work out any side effects of it
[19:57] <superm1> slytherin, that's not correct
[19:57] <superm1> the audio.so should be in bluez-utils
[19:57] <superm1> not bluez-audio
[19:57] <superm1> bluez-audio is just for alsa and gstreamer, not the :audio service"
[19:57] <slytherin> superm1: but currently it is in bluez-audio i.e. the version available in intrepid
[19:57] <superm1> slytherin, then a conflicts/replaces is what's actually needed
[19:58] <slytherin> superm1: your call.
[19:58] <superm1> okay i'll put the conflicts/replaces in then
[19:58] <persia> Remember to version them so we don't get hit because of the continued names.
[19:59] <superm1> yeah i'm planning on just doing bluez-audio (<= 4.9)
[19:59] <persia> Looking at Marcel's comment, and based on godog not responding, I'm tempted to not worry so much about the Debian naming.
[19:59] <persia> There's enough different between 3.x and 4.x that a different split might make sense, and when squeeze opens would be a good time to introduce such a thing.
[20:00] <persia> The only issue is that if we diverge significantly, it's a lot more work to cherrypick from Debian, and we lose orig.tar.gz mapping.
[20:00] <slytherin> superm1: by the way what is the use of audio service seperately from gstreamer?
[20:00] <persia> slytherin: ALSA.
[20:00] <slytherin> ahh forgot that part. :-(
[20:02] <slytherin> superm1: persia: in that case shouldn't /usr/lib/alsa-lib/libasound_module_ctl_bluetooth.so and /usr/lib/alsa-lib/libasound_module_pcm_bluetooth.so go into bluez-utils?
[20:03] <superm1> well the ALSA support isn't the same thing as the audio service still
[20:03] <superm1> the audio service just is what tells the devices that pair that you are capable of audio functionality
[20:03] <persia> That said, we've done a lot more original patches and cherrypicks from Fedora with bluetooth, and the bluez stack doesn't seem to have been in sync since hoary.
[20:04] <superm1> so in a sense we've been divergent from debian for some time already
[20:04] <slytherin> superm1: back to my question then. What is use of audio service without alsa or gstreamer support?
[20:06] <persia> superm1: Right.  We've been divergent from Debian (typically higher upstream, and always additional patches) since at least 2004.
[20:07] <superm1> persia, by that argument i would much prefer to get on the side of upstream
[20:07] <persia> For hoary, I don't think the sync/merge workflow was as institutionalised, so there may be lost diversions from warty that I don't see.
[20:07] <superm1> persia, additionally, upstream will be hammering the debian maintainer to get this scheme in addition to us
[20:07] <superm1> slytherin, it's not particularly useful, but then you are able to still pair with devices that advertise audio services
[20:08] <persia> Well, we might be able to help work nicely with pkg-bluetooth in order to get back out of divergence.  I think sync remains the goal, but I'm not sure the path is to follow the current Debian packaging.
[20:08] <slytherin> superm1: think form user's point of view. what is use of pairing if you can't even test playing wave file unless you install bluez-audio. It is a different thing that it will be pulled due to 'Recommends' but that is a different topic.
[20:09] <slytherin> persia: +1
[20:09] <superm1> slytherin, well the split is how upstream wants to see it split (main package/alsa package/gstreamer package)
[20:10] <superm1> and how they're adopting it in OpenSuSE and Fedora
[20:10] <superm1> okay so i'll revert the commits that brought us to old naming scheme then, and add in a  transitional bluez-utils package instead
[20:10] <persia> slytherin: At issue is that you can install either of -gstreamer or -alsa to support -audio.  Doesn't matter.  Further, if someone wanted to add -jack or -pulse or whatnot, they could.
[20:11] <slytherin> persia: yes but that is if we decide to go upstream and FC/Suse way rigtht now.
[20:11] <superm1> slytherin, whilest I revert doing this would you be able to try to investigate some of the other FTBFS libraries?
[20:11] <slytherin> superm1: sure.
[20:11] <superm1> that needed rebuilding after switching to bluez 4.x
[20:11] <superm1> do you know the bug number slytherin ?
[20:11] <slytherin> superm1: Yes I have it.
[20:11] <superm1> slytherin, okay great thanks
[20:12] <superm1> particularly the onces that have the link error, if you solve one, likely that will solve about 8 of them
[20:12] <superm1> with the missing symobl
[20:12] <superm1> symbol even
[20:12] <slytherin> superm1: first let me tell you that I am awake for an hour more. It;s already past midnight :-)
[20:12] <superm1> hehe :)
[20:12]  * persia searches in vain for NCommander for fixing libtool FTBFS quick-like.
[20:13] <fabrice_sp> Siretart: I attached a debdiff to bug #264790, with the correction. Can you validate please?
[20:13] <slytherin> I liked Marcel's comment on the bug. :-)
[20:23] <slytherin> superm1: hci_read_remote_name seems to be replacement for hci_remote_name. Let me know when your packages are ready so I can try compiling the ones that FTBFS.
[20:24] <superm1> slytherin, just use the stuff on the PPA right now
[20:24] <slytherin> superm1: Ok.
[20:24] <superm1> its just libbluetooth-dev and libbluetooth3 that do it
[20:24]  * slytherin updates pbuilder.
[20:24] <superm1> i have to add in some magic that will transition the init script
[20:31] <siretart> fabrice_sp: the patch in kdenlive/effect.h needs more explanation
[20:32] <fabrice_sp> siretart: ok. I'll update the changelog
[20:35] <fabrice_sp> Would that description be ok: - kdenlive/effect.h: change name of the second id variable in Effect constructor
[20:35] <siretart> ah i see. why is upstream doing such stupid thing here?
[20:36] <siretart> may I suggest to just remove the identifier name?
[20:41] <fabrice_sp> siretart: having a look at the constructor code, it appear that the second 'id' is named group, so I should change it also in effect.h
[20:41] <siretart> ah dropping does not work because of the default initializer. hm
[20:41] <fabrice_sp> exactly
[20:42] <fabrice_sp> effect.h should have constructor  defined like this: Effect(const EffectDesc & desc, const QString & id, const QString & group)
[20:42] <fabrice_sp> changing the patch
[20:43] <siretart> okay, thanks for working on it. i'll upload it!
[20:49] <fabrice_sp> siretart: great! Give me 5 minutes, and I'll upload the debdiff with changed comment, and updated patch (running pbuilder now)
[20:50] <siretart> thnx!
[20:50] <superm1> slytherin, okay do you know which one of those was not from the hci_remote_name bug?
[20:51] <superm1> i just uploaded bluez ~ppa4 that takes care of the naming, so i'll look at one of these FTBFS
[20:51] <slytherin> superm1: I have only looked into 2, freej and libbtctl
[20:51] <superm1> slytherin, okay
[20:51] <superm1> any luck with the function name change?
[20:52] <slytherin> superm1: Trying. My connection is slow and pbuilder update taking time.
[20:52] <superm1> slytherin, okay.
[20:53] <superm1> libpamblue looks interesting
[20:53] <superm1> i'll take that one
[20:54] <slytherin> superm1: of all the packages listed at http://people.ubuntu.com/~stevenk/bluez/ libpam-blue and bluetooth-alsa have same error. Rest all are due to hci_remote_name
[20:54] <superm1> slytherin, okay libpam-blue is probably just a relibtoolize then
[20:54] <slytherin> superm1: yes, that is what I was going to say.
[20:55] <superm1> bluetooth-alsa is taken care of.  StevenK got that one before
[20:56] <slytherin> cool
[20:56] <fabrice_sp> siretart: build ok, and debdiff uploaded. All yours :-)
[20:57] <slytherin> superm1: so if this function name works then only evolution, gnome-phone-manager, multisync and slypheed is remaining.
[20:59] <superm1> slytherin, i think evolution will "just" work too given pilot-link was resolved
[20:59] <superm1> i'll double check
[21:00] <siretart> fabrice_sp: excellent >)
[21:01] <slytherin> superm1: libbtctl has no patch system. is it ok to patch the source directly?
[21:01] <slangasek> superm1: errr, what do you mean by "haven't been in sync since about hoary"?  We've certainly been /merging/ with them, I don't see why not being in sync is an argument in support of greater divergence
[21:01] <superm1> persia, ^
[21:02] <fabrice_sp> siretart: thanks ;-) It was an easy one, even if that cmake stuff drove me crazy (did you had a look to the debian diff file?!)
[21:03] <persia> slangasek: We've done some merges of some of the packages.  For others, we've not had the same upstream version at any point recently.
[21:04] <persia> slangasek: For an especially extreme example of not having the same upstream, take a look at the bluez-gnome changelog, and compare to the debian changelog.
[21:04] <slangasek> well, that one yes
[21:06] <persia> bluez-utils isn't that much better.
[21:07] <siretart> fabrice_sp: yeah, I didn't really get cmake yet either...
[21:07] <persia> Mind you, I'll all for being in sync, I'm just not seeing a lot of historical evidence, and if the debian packaging split has already raised eyebrows, and upstream has such strong language against it, I'd think the right path forward would be to discuss with pkg-bluetooth, rather than to try to follow Debian just because it's Debian.
[21:07] <persia> I'd not hold this opinion were we a little more in sync.
[21:08] <slytherin> superm1: ppa4 failed to build on i386 :-)
[21:08] <siretart> fabrice_sp: do you track kdenlive upstream? do you know if upstream meanwile compiles with gcc-4.3?
[21:08] <RainCT> btw, is the bluez stuff C/C++/Python/something_else?
[21:08] <superm1> wha? i just built it locally.
[21:08] <superm1> i'll look
[21:08] <slytherin> RainCT: C
[21:09]  * RainCT runs away from it :P
[21:09] <slytherin> superm1: couldn't find library libbluetooth.so.3 needed by debian/bluez-utils/usr/bin/rfcomm (its RPATH is '').
[21:09] <NCommander> persia, a lot of debian maintainers dislike that we use their packages, and the concept of them being the upstream of Ubuntu
[21:09] <RainCT> (at least for the next years ^^)
[21:09] <slytherin> superm1: surprisingly it built on amd64 and lpia
[21:10] <slytherin> NCommander: by upstream persia means bluez.org.
[21:10] <NCommander> slytherin, isn't it a pain when that happens :-)
[21:10] <slytherin> :-)
[21:11]  * NCommander is working on the release critical Xubuntu bugs
[21:11] <persia> NCommander: Close involvement, and effort towards sync typically reduces that feeling.
[21:11] <fabrice_sp> siretart: to be honest: no, as I saw as last stable version the same as we have in Ubuntu
[21:11] <slytherin> superm1: libbtctl done. should I upload to PPA or wait for you to fix your packages first?
[21:11] <k0p> james_w, there?
[21:11] <james_w> hey k0p
[21:12] <k0p> hi. Good night
[21:12] <k0p> or something like that
[21:12] <k0p> :)
[21:12] <k0p> james_w, about try: except of gksu2...
[21:12] <k0p> I didn't catch ImportError.
[21:13] <james_w> heh, I *just* saw this on planet.python.org: http://bluesock.org/~willg/blog
[21:13] <siretart> fabrice_sp: okay.
[21:13] <superm1> slytherin, put the debdiff on the bug, dont worry about the PPA for now
[21:13] <superm1> slytherin, and go ahead and update it to "Fix Committed" on the bug
[21:14] <james_w> k0p: what problem is it that you are trying to prevent with the try: except: ?
[21:14] <k0p> james_w, may be. But I didn't know how solve using other way
[21:14] <slytherin> superm1: Ok.
[21:15] <superm1> slytherin, hopefully the same patch is applicable directly to these other packages too :)
[21:15] <superm1> or same type of patch at least
[21:15] <slytherin> superm1: Let me try building others.
[21:15] <k0p> james_w, http://paste.ubuntu.com/52574/
[21:16] <james_w> k0p: ok, and what problems does that cause? When the user cancels it aborts the program?
[21:16] <slytherin> superm1: patching a source file directly is fine right?
[21:16] <slytherin> when there is no patch system
[21:17] <superm1> slytherin, it's much better to add a patch system in
[21:17] <superm1> so that you can track it
[21:17] <persia> Hrm!  Which package.
[21:17] <k0p> james_w, Umit have a system to catch all tracebacks.. so it will send a Crash Report. It didn't make sense.
[21:17] <superm1> and then the patch can be more easily picked out and sent upstream
[21:17] <slytherin> persia: libbtctl
[21:18]  * persia usually doesn't like the introduction of a patch system as it can complicate coordination with Debian if there is a reason for no patch system, and looks at the pacakge
[21:18] <james_w> k0p: fair enough. You should "except GError, e: print e" in my opinion
[21:18] <k0p> may be my python instructions are killing rain florest.. but sorry. I didn't find a better solution
[21:18] <k0p> james_w, I already tried.
[21:18] <slytherin> superm1: ok, another question. should I change any 'Depends' of the type libbluetooth2-dev to libbluetooth3-dev or simply libbluetooth-dev?
[21:18] <superm1> slytherin, i say libbluetooth-dev
[21:18] <superm1> it will make things easier in the future
[21:18] <slytherin> ok, I did same
[21:19] <slangasek> ... the -dev package name is changing as part of this update?
[21:19]  * slangasek becomes increasingly unenthusiastic
[21:19] <slytherin> I was wrong, there is a patch system.
[21:20] <persia> slytherin: My copy of the libbtctl source uses CDBS simple-patchsys  Are you sure yours doesn't?
[21:20] <slytherin> persia: ^^
[21:20] <persia> slytherin: OK.  Cool.
[21:21] <superm1> slangasek, the dev package name is the same, but the old one had a provides "libbluetooth2-dev"
[21:21] <persia> slangasek: It needn't, except that there is a soname bump, and so libbluetooth2-dev isn't quite correct for libbluetooth3.
[21:21] <superm1> slangasek, so some people decided to depend on libbluetooth2-dev instead
[21:21] <slangasek> superm1: does the new one not provide the same API?
[21:21] <james_w> k0p: ok, it doesn't have to stop the patch from going in, I just wanted to point it out in the review, as it's generally not a good idea to have a bare except clause
[21:21] <superm1> slangasek, a lot of the API is still compatible, but it's not identical
[21:21] <slangasek> persia: libbluetooth2-dev isn't correct for libbluetooth2 either, the dev package name should always reflect API not ABI
[21:21] <k0p> james_w, found a better solution now. :D
[21:22] <james_w> k0p: great!
[21:22] <slangasek> superm1: <mumble>
[21:22] <k0p> gobject.GError :D
[21:22] <k0p> btw I need to import gobject too.
[21:22] <slytherin> slangasek: as of now we have found only one API change.
[21:22] <k0p> thanks. :)
[21:22] <superm1> slangasek, hence why there's a few packages that are hitting these FTBFS and needing some changes
[21:22] <slangasek> right
[21:22] <k0p> james_w, before upload to LP a new patch, can you take a look?
[21:22] <james_w> sure
[21:22] <superm1> of the 35 or so, its only been about 10
[21:23] <persia> slangasek: Hrm.  I thought the practice was to either keep versioned -dev to match the library version (e.g. wx*) or only use -dev and expect clients to move to the new A?I
[21:23] <nxvl> james_w: did you got my mail?
[21:23] <nxvl> persia: did you?
[21:23] <james_w> nxvl: sure did
[21:23] <nxvl> \o/
[21:24] <slangasek> persia: that's the practice, yes; the people who propagated the first of those practices were Wrong :-P
[21:25] <slangasek> the latter practice is usually an ok approximation of "change the -dev package name when the API changes"
[21:25] <slangasek> the former results in -dev package name changes or no reason, leading to more fiddling with sources for rebuilds than is necessary
[21:27] <persia> slangasek: I think I wasn't clear.  I generally see "libfoo-dev" persist over API changes.  I only rarely see "libfooN-dev", and in those cases, it often seems to depend on libfooN, where I beleive N to track ABI, rather than API.  I have no memory of seeing libfooX-dev depending on libfooY-dev.
[21:27] <persia> s/libfooY-dev/libfooY/
[21:28] <slangasek> sure
[21:28] <slangasek> what I'm saying is that everyone who does libfooN-dev is Doing It Wrong
[21:28] <persia> I agree the former doesn't make sense, but I'm not seeing the "change the -dev package name when the API changes" behaviour.
[21:28] <slangasek> I think there've been a few
[21:28] <persia> Even for things where we carry multiple versions of a library, like wx?
[21:29] <geser> persia: easy example: curl: libcurl4-gnutls-dev depends on libcurl3-gnutls, but I believe curl is special
[21:30] <persia> geser: That's because of a very special case of a useless soname bump at an inconvenient time, and it was determined to be easier to make a mess than to rebuild everything.
[21:30] <slangasek> persia: the APIs are also different between the multiple versions of wx, that's a major factor in why we have several of them :)
[21:32] <persia> Yes, *very* different.  But the practice of having different source packages for API bumps seems limited to a few specific libraries with *lots* of reverse dependencies, like db, or wx, or gtk.  Do you think it ought be more common?
[21:32] <slangasek> oh, I'm not generally arguing for proliferation of source packages
[21:33] <slangasek> only saying that the time to change a -dev package name is IFF the API changes
[21:33] <slangasek> and that we should err on the side of less frequent package name changes if we're not sure whether there's an API change, or whether it matters to packages
[21:34] <persia> OK.  In this case I think we're correcting the previous proliferation of binary -dev names, at a time when there is a minor API change.
[21:34] <slangasek> db is a special case where the API hasn't changed, the ABI has, and we've kept lots of them around because the on-disk format is what's changed
[21:34] <slangasek> persia: yes
[21:38] <slytherin> superm1: libwiimote done. what version should I in changelog? I used ~ppa1 for libbtctl.
[21:40] <superm1> slytherin, if its going to the PPA, put the ppa in it
[21:40] <superm1> is it a dependency for other stuff?
[21:40] <superm1> like cwiid or anything?
[21:40] <superm1> if not, then i say don't worry about dropping it in the ppa
[21:40] <slytherin> let me check.
[21:40] <superm1> slytherin, okay i got evolution taken care of
[21:41] <persia> How are we testing the rebuilds if they aren't going in the PPA?
[21:42] <slytherin> persia: we are talking about rebuilds of the packages that depend on libbluetooth
[21:42] <persia> slytherin: Yes.  How are we testing them against BlueZ 4.x?
[21:43] <slytherin> persia: I don't know. I was trying to fix the builds.
[21:43] <persia> Given that we're currently in the process of missing the beta window, I think aggressive testing is in order.  I've a box ready to test, but was waiting for a transition set.
[21:43] <persia> superm1: What's your thought on testing?
[21:43] <slytherin> persia: so you want all the packages in ppa?
[21:44] <persia> Not necessarily.  I'm happy to test, but if there's another plan, there's other things I can do.
[21:44] <superm1> persia, i think once we have all of the debdiffs ready, we should setup the PPA to host "everything"
[21:44] <superm1> persia, and we'll have an archive admin do a copy from it once we've tested everything
[21:44] <superm1> eg do a test install and remove
[21:45] <slytherin> superm1: then why not add packages right now?
[21:45] <superm1> slytherin, in case there's churn
[21:45] <superm1> the version numbers need to reflect what will go in the archive then
[21:45] <persia> Hrm.  I'm not sure I like that, as 1) I don't like pocket copies from PPAs, and 2) setting archive versions means no tweaking if something is broken.
[21:45] <superm1> persia, how do you propose we test everything then?
[21:46] <persia> Push to a PPA with ~ppa versioning.  Install.  Test.  If all is good, un~ppa and upload.
[21:46] <persia> That allows for interim version bumps.
[21:46] <slytherin> I agree with persia. We should have all relevant packages in PPA. So anyone who is willing to test can use it.
[21:46] <persia> The other alternative is to ask testers to build locally & test.
[21:47] <superm1> well StevenK is the one that has to push a lot of things to the PPA then
[21:47] <superm1> he's done test builds for most of the rebuild bug
[21:47]  * persia thinks it's around sunrise there.
[21:48] <slytherin> I will upload what I have fixed to PPA. Ican't stay up more than 15 minutes now.
[21:49] <persia> superm1: Hrm.  If the list is large, and you want to just shove everything, that also works for me, but I don't see much benefit of PPA vs. archive except with ~ppa.  I suppose we get an additional bit of time to test, but we can't fix any issues (or we have to fiddle with -V if we do and reupload)
[21:50] <superm1> persia, well yeah the list is rather large - 35 packages in addition to the ones already being tracked on the first bug
[21:50] <superm1> persia, that's why i thought it made sense to ask for a pocket copy on it to avoid doing that many uploads twice
[21:51] <persia> superm1: I guess.  What's the win?  Just testing time because of beta?
[21:51] <superm1> persia, that and we have more granular control of the order they're built
[21:51] <superm1> some of these have indirect dependencies that cause the failures
[21:51] <superm1> so you can't explicitly say you need pilot-link x.y.z
[21:51] <superm1> b
[21:53] <persia> But we still need to restage the build order carefully when pulling out of the PPA, for the rest of the architectures.
[21:53] <superm1> ah that's right.
[21:54] <slytherin> superm1: by the way, have you already edited file debian/libbluetooth3.shlibs to reflect proper version?
[21:55] <superm1> slytherin, yeah some days ago i did
[21:55] <slytherin> superm1: it should say >=3.14, should it? should be something like >= 4.9
[21:56] <superm1> slytherin, ah yeah i had only updated part of it
[21:56] <superm1> good catch
[21:57] <slytherin> superm1: persia: So what is final decision? ppa or not ppa?
[21:58] <jono> Hobbsee, ping
[21:58]  * persia defers to superm1
[21:58] <persia> jono: It's early there yet.
[21:58] <jono> anyone know the contact details of the IRC Council?
[21:59] <superm1> slytherin, for the ones that required the bigger changes, writing a patch etc, lets put them on the PPA
[21:59] <persia> jono: Most of them are often in #ubuntu-ops : I don't know the ML address offhand.
[21:59] <Nafallo> jono: #ubuntu-irc
[21:59] <superm1> slytherin, if it was a no change rebuild, or libbluetooth2-dev-> libbluetooth-dev, lets not
[22:00] <slytherin> superm1: Ok. I will upload both libbtctl and libwiimote in morning. I hope you will have changed shlibs by then.
[22:00] <superm1> yeah i'll have that fixed momentarily
[22:00] <slytherin> oh, then I will wait 5-10 minutes. I have packages ready.
[22:01] <slytherin> superm1: persia: is this correct dput.cf for ppa - http://paste.ubuntu.com/52594/
[22:02] <superm1> slytherin, yeah that looks right
[22:02] <superm1> i've uploaded the newer one
[22:02] <slytherin> ok
[22:22] <k0p> james_w, can you review it: http://www.kop-labs.com/umit/patch/higwidgets_issue-new.patch?
[22:25] <james_w> k0p: your root.patch is a bit funny now, it deletes a lot of lines, which are then added back as a direct patch to the source at the end
[22:25] <superm1> slytherin, can you make sure that you attach your libwiimote patch to the bug too before you go to bed?
[22:26] <slytherin> superm1: I am uploading bothe the packages to PPA and I will also attach patch.
[22:26] <superm1> slytherin, okay very good thanks.
[22:26] <jsomers> I was attempting to package an application but pbuilder is giving me an error. It seems the application makefile is trying to install it in /usr/local/bin and it throws a permission denied error
[22:27] <jsomers> how can I bypass that without modifying the original makefile?
[22:27] <k0p> james_w, added ?
[22:27] <k0p> james_w, is it wrong?
[22:27] <james_w> k0p: +        root = gtk.Button('Run as Root') etc. in the last hunk of the diff
[22:28] <james_w> I don't know if it looks wrong, but it certainly looks weird, and is different to the last version
[22:28] <k0p> james_w, hmm
[22:29] <k0p> james_w, I don't know.
[22:29] <k0p> It's diff mistakes
[22:29] <k0p> I didn't add nothing more.
[22:30] <k0p> i'm downloading dsc files
[22:30] <james_w> yeah, I think it was just a mistake as you changed the patch
[22:30] <k0p> and try apply patch
[22:31] <k0p> :(
[22:31] <k0p> yeah
[22:31] <k0p> fsck!
[22:34] <directhex> did NCommander materialize? ah, yes, it seems so
[22:34]  * NCommander runs to the Peagus to escape into time
[22:35] <slytherin> jsomers: you need to give --prefix option to ./configure in your debian/rules file.
[22:36] <superm1> slytherin, did you do libbtctl too, or was that StevenK ?
[22:37] <superm1> oh there it is
[22:37] <slytherin> superm1: done with both. going now. see you tomorrow.
[22:37] <superm1> nvm
[22:37] <NCommander> directhex, what do you need from me
[22:37] <superm1> i was just confused :)
[22:37] <superm1> see you slytherin
[22:37] <directhex> NCommander, we were talking about ppc yesterday
[22:37] <slytherin> superm1: I think you can evaluate gnome-phone-manager once libbtctl is done
[22:37] <NCommander> Still need access to my PPC box?
[22:37] <superm1> slytherin, yeah that's what i was just bout to do
[22:39] <persia> superm1: Were there still libtool issues outstanding, or did those all get sorted?
[22:39] <superm1> persia, one left
[22:39] <superm1> you want it?
[22:40] <superm1> libpam-blue
[22:40] <persia> NCommander: Do you have time to chase an outstanding libtool FTBFS?
[22:40] <NCommander> persia, sure
[22:40] <NCommander> (assuming the FTBFS occcurs on i386, amd64, powerpc, lpia, or hppa)
[22:40] <NCommander> (or sparc)
[22:41] <superm1> NCommander, it's libpam-blue.
[22:41] <superm1> NCommander, related to bug 276343
[22:41]  * slytherin dreams of the day when bluetooth team will have upload rights to all blue packages. :-D
[22:41] <superm1> so when you sort out the libtool transition, if you could see that it builds against the PPA in question too, that'd be awesome
[22:41] <superm1> we're collecting all the debdiffs on that bug then too
[22:42] <jsomers> slytherin: how do I do that and will it even work if the Makefile of the application has the path "/usr/local/bin" explicitly stated in a "cp" statement?
[22:43] <slytherin> jsomers: What package is this? Do you have only Makefile? Is it not autogenerated using configure script?
[22:43] <NCommander> Is there a build log handy?
[22:43] <NCommander> ^- persia
[22:44] <superm1> NCommander, yeah there is
[22:44] <k0p> james_w, refresh please
[22:44] <jsomers> slytherin: nope, just 1 Makefile that does the trick
[22:44] <superm1> NCommander, http://people.ubuntu.com/~stevenk/bluez/libpam-blue_0.9.0-2ubuntu1_20080930-2312
[22:44] <slytherin> jsomers: then you have to patch it
[22:44] <NCommander> ewwwwwwwwwwww
[22:44] <directhex> NCommander, i'd still like access to *a* ppc box, yeah. or you could mail me a UK iBook power brick, that'd work too ;)
[22:44] <jsomers> bummer
[22:45] <NCommander> directhex, I have the part that breaks, you'll need the prongs adapter
[22:45] <james_w> k0p: that's better.
[22:46] <slytherin> superm1: I will test upgrade same time tomorrow. One thing occurred to me just now. Do you have appropriate Replaces added in bluez-alsa and bluez-gstreamer for bluez-audio?
[22:46] <k0p> james_w, sorry my mistake :)
[22:46] <james_w> k0p: no worries
[22:46] <k0p> I was very confuse with patchs :)
[22:46] <slytherin> directhex: you too lost the power adapter for ibook?
[22:46] <superm1> slytherin, yes
[22:46] <directhex> slytherin, seems like a common problem. yet we always moan about dell design sucking, never apple ;)
[22:46] <james_w> k0p: I only have two concerns left, firstly that the patches are sent upstream, and secondly that the changelog be a bit more clear about the purposes of the change.
[22:46] <superm1> slytherin, both bluez-alsa and bluez-gstreamer have conflicts/replaces for bluez-audio
[22:46] <james_w> k0p: any links you can add to it would help a lot
[22:47] <slytherin> superm1: Ok.
[22:47] <superm1> slytherin, hopefully the packaging there should be very close to what we're planning to go in intrepid now
[22:47] <k0p> james_w, second I understand. I didn't understand first.
[22:47] <k0p> upstream?
[22:48] <directhex> NCommander, well that's a standard plug anyway. coo, a 400mhz buildd. sexy o_o
[22:48] <directhex> suddenly i feel for the arm developers
[22:48] <slytherin> directhex: It was my first time with Apple and the adapter died soon. I got the ibook form my brother after he used it for almost 3 years. I am now getitng a custom adapter made since it is way cheaper than buying from Apple.
[22:48] <james_w> k0p: the authors of the software
[22:49] <k0p> james_w, the patches was fixed in svn of software.
[22:49] <directhex> slytherin, still lot of money though as far as i can tell.
[22:49] <james_w> k0p: http://trac.umitproject.org/ <- these people
[22:49] <k0p> james_w, yeah I know.
[22:49] <slytherin> directhex: not more than 1/3 of the price of original
[22:49] <james_w> k0p: great, links to the revisions in trac where they were fixed and/or the bug reports about the problems would probably suffice then
[22:50]  * slytherin hits bed without any further delay.
[22:50] <k0p> james_w, changelog?
[22:50] <james_w> k0p: sorry?
[22:50] <persia> james_w: In the changelog?
[22:51] <directhex> the battery's gone too
[22:51] <k0p> james_w, yeah, it's the question. thanks persia :)
[22:51]  * persia usually thinks that just linking the bug to the upstream bug, or adding a link in the bug commentary is sufficient.
[22:51] <k0p> hehe
[22:52] <persia> As a user, I want to know what changed,  I'm not usually as concerned about the link to upstream, but I like having a bug number in case I want to investigate.
[22:52] <james_w> k0p: ah, yeah, sorry, in the changelog please
[22:52] <persia> As a developer, when merging, I want to read the bugs anyway when merging, just to make sure I understand.
[22:52] <persia> james_w: Why?
[22:52] <persia> (not that I want to block such excellent sponsoring, just curious)
[22:52] <james_w> persia: sorry, I think I might be missing something
[22:53] <james_w> you want to know why I'd like pointers to the upstream commits/bugs in the changelog?
[22:53] <persia> james_w: Yes.  As a user, I don't typically want to read that.  As a developer, the changelogs are largely insufficient anyway, and I need to review the bugs closed by deviation from Debian.
[22:55] <james_w> persia: 3 reasons, but they don't all require it to be in the changelog. Firstly, so that I understand what I am sponsoring, as I don't fully yet. Secondly as it's trivial to see that the changes have been upstreamed. Thirdly, to save others interested in the changes from having to dig up the links themselves.
[22:56] <james_w> it doesn't really help users, but when we have the links we can write up good changelog entries to accompany them.
[22:56] <persia> james_w: I agree with *all* of those reasons, I just usually expect that to be in the bug, and for the second option, expect a link to the related upstream bug.  I don't like it in the changelog because of the audience of the changelog: it's stuff installed on *every* user system, so every extra byte takes CD space, and takes HD space.
[22:57] <k0p> james_w, is it needed bug report too?
[22:57] <persia> A short overview of significant changes with pointers to the LP bugs for interested parties seems much more appropriate.
[22:57] <james_w> persia: fair enough, and that works nicely too. I'm happy as long as they are somewhere.
[22:58] <james_w> k0p: if you have them to hand please, but it's not that important
[22:58] <k0p> I didn't have
[22:58] <k0p> :(
[22:58] <james_w> that's ok
[22:58] <k0p> but I have svn fix
[22:58] <persia> james_w: Yeah.  *Somewhere* is critical, and you're perfectly right to question their absence :)
[22:59] <james_w> persia: there was some discussion recently about sponsors requiring links to either Debian or upstream for all changes in the changelog where applicable, and I don't think anyone bought up that issue, so I hadn't considered it.
[23:00] <james_w> persia: I know for some things that I have done I have cheered every time I have found the links directly in the changelog, and cheered a little every time they were in the referenced LP bugs, so I like to encourage it for my benefit.
[23:00] <persia> Yeah, well.  The desktop team decided to copy all of upstream NEWS in every changelog entry, and add the name of *every* file touched.  They then removed the upstream changelogs to save space.  Everyone has different opinions.
[23:01] <persia> james_w: Oh, certainly.  Having to track down from where something came can be exceedingly frustrating.
[23:01] <james_w> agreed
[23:02] <james_w> I like the idea of sponsors writing changelog entries though
[23:02] <k0p> james_w, http://paste.ubuntu.com/52617/ better?
[23:03] <james_w> k0p: yes, thank you. Do you have a link for the root.patch as well?
[23:04] <k0p> james_w, root.patch it's a business of ubuntu package only
[23:05] <k0p> Umit can't use gksu2 because they are in Windows and Mac OS
[23:05] <james_w> k0p: ah, ok
[23:06] <james_w> k0p: the same for setup.patch?
[23:06] <k0p>  http://trac.umitproject.org/changeset/3742
[23:07] <k0p> james_w, it appears in changelog
[23:07] <k0p> did you want a line for file?
[23:07] <james_w> k0p: ah, ok, sorry, I just mis-read the entry
[23:07] <james_w> k0p: no, that's fine, I think we might be good to go
[23:08] <k0p> james_w, give a minutes to upload ok?
[23:08] <james_w> k0p: could you put the latest version of your debdiff on the launchpad bug please, and I'll do a final review.
[23:08] <k0p> ok
[23:08] <james_w> I'll be uploading tomorrow though, sorry.
[23:08] <james_w> unless someone else wants to jump in
[23:12] <k0p> james_w, done
[23:12] <k0p> can you check now ?
[23:12] <k0p> it it need subscrive again ubuntu-sponsors?
[23:13] <persia> k0p: You generally only need to subscribe once to get a sponsor, especially for an interactive discussion.  If it doesn't get hit soon, then it may be worth resubscribing.  Personally, without any context whatsover, I'd be very surprised if it wasn't uploaded soon, at least within the next 12 hours.
[23:14] <k0p> persia, ok :)
[23:15] <k0p> persia, but in Subscrivers of my LP bug ubuntu-sponsors didn't appear now. So I'll wait next 12 hours or wait by james_w :)
[23:15] <superm1> persia, StevenK okay that's the last of the library transition tasks (other than libpam-blue with NCommander is handling).
[23:16] <persia> superm1: OK.  Shall I pull the suite, and try to activate bluetooth in each affected app, and report success/failure?
[23:16] <persia> Or are we waiting on something else first?
[23:16]  * persia only wants to test 40 packages once or twice
[23:16] <superm1> persia, well not everything is on the PPA for this task, that will have to wait for StevenK to push his stuff
[23:17] <k0p> james_w, so is it ok? :)
[23:17] <persia> OK.  I'll catch him in a couple hours, and test thereafter.  Thanks for preparing this.
[23:17] <superm1> persia, if you can test the basic things one last time in your live session - (bluez/bluez-gnome), everything should be ready with those now including final package names and transitions
[23:17] <persia> Sure.  I'll pull and test those now.  I can't do much with bluez-cups though.
[23:17] <superm1> persia, hopefully we'll go out the door with a working bluetooth for once because of all this :)
[23:18] <persia> We had a pretty good bluetooth in gutsy, but yeah :)
[23:29] <james_w> k0p: sorry, just stepped out
[23:30] <james_w> k0p: looks good to me. I may tweak your changelog entry before uploading if that's ok. I'll show the final diff that I end up with if I do.
[23:30] <james_w> k0p: thanks for working on it
[23:31] <k0p> james_w, ok :)
[23:32] <k0p> thanks for the help too. :)
[23:32] <james_w> k0p: as I said it will be tomorrow. I'm working on something at the moment, and then I need to chat to someone in a timezone that is inconvenient for me.
[23:32] <james_w> k0p: no problem
[23:33] <k0p> ok no problem ;)
[23:37] <k0p> well cya people