[00:01] <psusi> what do you mean?
[00:03] <evaluate> psusi, well, I downloaded the files from launchpad (dsc, orig.tar.gz and the diff) and got the same error like in the ftbfs. I think I know where the problem might be, just not sure how to make the changes to the source file that is affected...
[00:03] <psusi> use a text editor?
[00:04] <psusi> or do you mean what is the proper way to package the changes to send upstream?
[00:05] <evaluate> psusi, no. I currently have only those 3 files. Do I need to unpack them, apply the diff, make the needed changes and then repackage with debuild -S ?
[00:06] <psusi> well the old way of doing things was to run apt-get source which would not only download those files, but unpack them for you
[00:06] <psusi> but these days it seems like everyone is using bzr
[00:07] <psusi> if you want to do it the old way, then if you already downloaded the files, run dpkg-source -x to unpack iirc
[00:07] <evaluate> well, it seems like I did it wrong then, I just wget'ed them from launchpad :p
[00:07] <psusi> best to use bzr to checkout these days
[00:08] <psusi> then most packages use quilt to track any changes to the upstream sources you make
[00:17] <evaluate> psusi, would I go through the same steps after downloading from bzr that I would go through if I would do a patch for a debian package for example?
[00:20] <psusi> evaluate, if you checkout the bzr branch, then you get the current source tree and the history with it...  you can then modify it, commit, then push it back to lp and request a merge.  If you download the tarball, you have to unpack it ( and apply the debian diff ) to get the source, modify it, build a new source package, which creates a new debian diff, then use debdiff to generate a diff between the two debian packages, and attach that to a bug report
[00:20] <psusi>  for someone to merge
[00:20] <psusi> in either case, if you make changes to the upstream source, you will need to use quilt to track those changes, assuming the package uses quilt, which most do
[00:20] <psusi> upstream source as opposed to things in the debian/ directory
[00:21] <evaluate> psusi, well, I downloaded the source files using bzr, as you suggested. I wouldn't want to push anything until I know that the problem is solved (and then I'd still probably better mail the maintainer)
[00:21] <achiang> hm. the user chooser at the gdm login window is gone on my lucid machine. anyone know where to start investigating on that?
[00:22] <psusi> evaluate, well then make sure it's using quilt, and then start a new quilt patch and make your changes
[00:23] <psusi> and don't forget to dch -i
[00:23] <evaluate> psusi, ok, thank you!
[00:59] <psusi> if bzr bd fails to find an upstream tarball, how do you recover from this?  I don't even care about building a source package, I just want a binary to test
[01:04] <soren> psusi: Do you have the tarball yourself?
[01:05] <soren> psusi: If so, just put it somewhere where bzr bd looks for it, like ../build-area.
[01:16] <udienz> Hi. i want to ask about merging. nginx have new patch new patch to handle "one_addr" bug. debian and ubuntu doesn't have this patch
[01:16] <udienz> can i proposed merge rather than sync from debian?
[01:17] <udienz> http://nginx.org/pipermail/nginx/2010-December/024235.html
[02:23] <ScottK> tumbleweed: Thanks.
[03:24] <psusi> soren, no, I don't have the original tarball because there isn't one.. it's pulled straight from bzr.. grub2 version 1.99~20101126-1ubuntu3
[03:55] <psusi> hrm... looks like bzr bd --export-upstream should do the trick, but it doesn't seem to do a thing
[04:25] <ebroder> udienz: Around?
[04:25] <udienz> egroder: yup
[04:25] <udienz> ebroder: yup
[04:26] <ebroder> udienz: Hey, looking at your tpb merge again. Do you understand why we're complaining that you have "(LP: #12345)" in the changelog?
[04:27] <udienz> ebroder: no
[04:27] <udienz> i'm not understand
[04:28] <ebroder> udienz: In the first debdiff you attached, you had in the changelog "* Merge from debian unstable (Closes LP: #690927)"
[04:28] <ebroder> My complaint was not with the actual bug number you referenced, but with the way you referenced it
[04:28] <ebroder> Does that make sense?
[04:29] <udienz> ebroder: ah... my mistake.. sorry. i'll make anotehr debdiff again
[04:29] <ebroder> udienz: Don't bother
[04:29] <udienz> *another
[04:29] <ebroder> I can fix it up. I just wanted to make sure you understood the issue
[04:30] <ebroder> udienz: The rest of the diff is much better now
[04:30] <udienz> ebroder: :) thanks
[04:30] <ebroder> udienz: I'm going to do some work on the changelog - you understated what the "remaining changes" are in a few cases - but then I'll sponsor it
[04:31] <ebroder> udienz: For instance, you said that the Ubuntu change in debian/init.d was to initialize LSB information, but if you actually look at the diff, that file is completely new in the Ubuntu version
[04:33] <udienz> ebroder: http://paste.ubuntu.com/545152/ like this?
[04:34] <ebroder> udienz: I think it may be clearer if I demonstrate. Give me a moment to write the changelog as I would have liked to see it
[04:38] <ebroder> udienz: Actually, looking closer, I believe I see more problems than just the changelog
[04:39] <udienz> ebroder: about what?
[04:43] <udienz> ebroder: i will try again to fix it if you want
[04:43] <ebroder> udienz: One moment, please. I need a minute to look at this more closely
[04:43] <udienz> sorry :) i'll wait
[04:45] <ebroder> udienz: It looks like there were several Ubuntu changes that you dropped without explanation
[04:45] <ebroder> udienz: For instance, in 0.6.4-2.3ubuntu3, we added libxinerama-dev and dpatch to the build-dependencies in debian/control, and you dropped that change
[04:46] <ebroder> udienz: You also dropped debian/patches/02_relibtoolize.dpatch
[04:47] <ebroder> udienz: You also dropped the changes to debian/rules which caused the patches in debian/patches to be applied
[04:47] <ebroder> udienz: You also dropped the "#DEBHELPER#" in debian/tpb.postrm and debian/tpb.preinst
[04:47] <ebroder> udienz: And you dropped the environment variable change in debian/tpb.xsession
[04:48] <ebroder> udienz: And you dropped a substantial change to src/cfg.c
[04:49] <ebroder> udienz: Oh wait, forget that last bit. Looks like might it's been incorporated upstream?
[04:49] <ebroder> udienz: But if that was the case, it should be documented in the changelog as well
[04:51] <udienz> ebroder: okay, i will try to fixing it
[04:55] <udienz> ebroder: why we neew #DEBHELPER# in debian/tpb.postrm and debian/tpb.preinst? seems like it commented and will be ignored
[04:55] <udienz> s/neew/need/
[04:56] <ebroder> udienz: "#DEBHELPER#" is a special placeholder. debhelper scripts use that to add code to the maintainer scripts when needed. In this case, dh_installinit adds code to the postrm and preinst
[04:56] <ebroder> udienz: It's not actually a comment
[04:57] <udienz> owh..
[04:57] <udienz> okay
[05:00] <udienz> debroder: btw, i'm not change debian/tpb.preinst,  debian/tpb.preinst only have one "debian/tpb.preinst".
[05:00] <ebroder> udienz: I don't understand
[05:01] <ebroder> udienz: Oh, I see. It already has a #DEBHELPER# placeholder. Yes, that's correct- there should only be one
[05:01] <udienz> debroder: sorry i mean debian/tpb.preinst only have one "#DEBHELPER#".
[06:33] <fabrice_sp> Hi. Reviewing dolphin-emu license, I found some files licensed under the openssl license, wheras the fulle project is under GLP-2. I read about incompatibility between both: how can I avoid it (if any)?
[06:36] <fabrice_sp> the copyright file is there: http://revu.ubuntuwire.com/revu1-incoming/dolphin-emu-1012132339/dolphin-emu-2.0+svn6571/debian/copyright if anyone is willing to have a look
[07:54] <udienz> ebroder: done, ready to review again
[07:59] <ebroder> udienz: Ok, great. I'll look in a moment
[08:00] <ebroder> udienz: Did you re-sub sponsors? I don't have the bug number handy
[08:00] <geser> fabrice_sp: I know that some GPL software has an OpenSSL linking exception to allow linking with openssl, don't know if something like that would help here too (I'd suggest asking #debian-legal)
[08:01] <geser> I meant the debian-legal mailing list
[08:01] <udienz> ebroder: yup
[08:01] <udienz> bug 690927
[08:01] <ubottu> Launchpad bug 690927 in tpb (Ubuntu) "Please merge tpb 0.6.4-6 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/690927
[08:14] <ebroder> udienz: This is an improvement. I still have a few more issues
[08:15] <ebroder> udienz: First, I don't think you need to export DH_COMPAT=3 in the debian/rules file. I'm not sure why that would have ever been there
[08:16] <ebroder> udienz: And for what it's worth, this package doesn't really look like it's been well maintained, so I don't blame you for stumbling with putting it back together correctly
[08:18] <ebroder> You added back some code involving devfs back to debian/tpb.postinst, as well as installing some files debian/rules. We haven't used devfs for longer than I've been paying attention
[08:18] <udienz> ebroder: agree, i spend 2 two days for this package
[08:18] <ebroder> udienz: I think we're getting close
[08:26] <ebroder> udienz: By the way, have you been building and testing this package? Do you have an IBM computer to see if it's working?
[08:27] <udienz> ebroder: yup, i have building this package, but i dob't have IBM Computer
[08:27] <ebroder> udienz: I'm confused because it doesn't look like the patches in debian/patches are getting applied - and they haven't been for a while - so I'm trying to figure out why they're needed
=== hanska is now known as dapal
[08:30] <ebroder> udienz: Yeah. I'm pretty sure the patches in debian/patches were ever used, so I think you can remove debian/patches as well as the quilt stuff in debian/control and debian/rules
[08:32] <udienz> ebrader: hm... wait i will at .deb from pbuilder
[08:32] <udienz> *look at .deb
[08:35] <udienz> ebroder: i got this message from first debuild. i think you right about dpatch "W: tpb source: dpatch-build-dep-but-no-patch-list"
[08:36] <ebroder> udienz: I know I'm right about dpatch not getting used. What I have no clue about is how the package has managed to stay like this for 4.5 years
[08:36] <ebroder> I also have no clue about what those patches were intended to accomplish, or if they were ever necessary in the first place
[08:38] <udienz> ebroder: hm... so i must remove debian/patches and remove line at debian/rules about depatch?
[08:38] <udienz> *dpatch
[08:39] <ebroder> udienz: Yes, as well as removing the change about "patch-stamp" in debian/rules, and removing the build-dep on dpatch in debian/control
[08:52] <fabrice_sp> geser, thanks. Will ask there
[08:53] <udienz> ebroder: done, a patch has been submited
[08:54] <ebroder> udienz: I also asked you to drop the devfs changes
[08:54] <ebroder> in debian/rules and debian/tpb.postinst
[08:54] <ebroder> And also debian/control (the dependency on makedev)
[08:55] <udienz> ebroder: owh i see.. i think i must remove one to avoid duplicating
[08:56] <ebroder> udienz: I'm starting to actually wonder if this package can be synced instead of merged
[08:57] <ebroder> udienz: Because the only real changes left are debian/init.d and debian/tpb.xsession
[08:57] <ebroder> udienz: And if you read the comments on bug #146987, it doesn't sound like the debian/init.d script is doing the right thing
[08:57] <ubottu> Launchpad bug 146987 in tpb (Ubuntu) "tpb init script doesn't launch tpb" [Undecided,Fix released] https://launchpad.net/bugs/146987
[08:57] <ebroder> udienz: But it's hard for me to be sure without a laptop that tpb works on
[08:57] <udienz> ebroder: but referring from bug #368546 debian doesn't have init.d
[08:57] <ubottu> Launchpad bug 368546 in tpb (Ubuntu) "init script doesn't launch tpb at startup" [Undecided,In progress] https://launchpad.net/bugs/368546
[08:58] <ebroder> udienz: Right, Ubuntu added the init script. I think that might have been wrong. Or maybe it used to be right but is wrong now
[09:01] <udienz> ebroder: i have an idea, we can ask bug report to try this package with init script, if everything is okay we can merge
[09:01] <ebroder> udienz: No, you're looking at this backwards. The goal should always be to sync if we can, not merge
[09:02] <ebroder> udienz: One minute, let me pull my thoughts together on this
[09:02] <udienz> ok
[09:04] <ebroder> udienz: Ok, here's what I'm thinking:
[09:04] <ebroder> udienz: We've been working on reducing the number of Ubuntu-specific changes to tpb
[09:04] <ebroder> At this point, we're down to a short list of changes:
[09:05] <ebroder> (1) debian/init.d, which we completely added on our own
[09:05] <ebroder> (2) debian/control, we add libxinerama-dev to the build-depends
[09:05] <ebroder> (3) debian/tpb.xsession, we make "$TPB -d" into "LANG=C $TPB -d"
[09:07] <ebroder> (1) does 2 things at startup. It loads the nvram kernel module, and then runs tpb -d
[09:07] <ebroder> Running tpb -d is definitely a bug - see the comments on #146987 - tpb is supposed to run as part of the user's session, not as a background daemon
[09:07] <ebroder> And you shouldn't have to load a kernel module to detect a piece of hardware. udev should be doing that for us
[09:08] <ebroder> So I don't think the init.d script is doing anything useful. But I can't be sure of that until I find a IBM ThinkPad and make sure that the nvram module gets loaded *without* tpb being installed
[09:08] <ebroder> As for (2), there's no documentation in the changelog of why libxinerama-dev was added to the build dependencies
[09:09] <ebroder> And as for (3), that change was made because "transcoded fonts are currently not available in ubuntu"
[09:09] <ebroder> I don't really know what "transcoded fonts" are, but there's a xfonts-100dpi-transcoded package, which sounds like a transcoded font to me
[09:14] <udienz> ebroder: okay, following list of changes, this packages must be sync instead of merge
[09:14] <ebroder> udienz: That's what I think, but I'm not entirely sure
[09:14] <udienz> one reason (maybe ~10 minute ago) to merge is init script, but you are right
[09:15] <ebroder> udienz: If the nvram kernel module gets loaded automatically *without* tpb installed, then the init script is unnecessary
[09:17] <udienz> ebroder: nvram loaded automatically in my laptop
[09:17] <udienz> $ modinfo nvram, i got information about nvram
[09:18] <ebroder> udienz: modinfo shows information about all modules, not just those that are loaded. You need to run "lsmod" and look for nvram
[09:18] <ebroder> But you said you don't have a IBM ThinkPad, so you might not need the nvram module on your machine
[09:32] <ebroder> udienz: In any case, it's getting late here in California, so I'm goign to go to bed. If you can find out whether the nvram module gets loaded automatically on older IBM ThinkPads, that's all we need to know at this point to figure out if it's a merge or a sync
[09:33] <ebroder> udienz: I'm going to unsubscribe ubuntu-sponsors again for now since this isn't ready for sponsorship yet
[09:33] <udienz> ebroder: okay, Good night.. hope you got night dream. i'll find information about vnram
[09:53] <fabrice_sp> lfaraone, I saw you commented on dolphin-emu RFS (http://lists.debian.org/debian-mentors/2010/12/msg00081.html). This package is also in REVU (http://revu.ubuntuwire.com/p/dolphin-emu): appart from the GPL3+ / GPL2 issue, is there more?
[09:53] <fabrice_sp> hmmm. wrong time for that question. Will try later.
[11:16] <djeenan> hello
[11:24] <fabrice_sp> djeenan, hi
[11:40] <fabrice_sp> exit
[11:40] <fabrice_sp> oops
=== bilalakhtar_ is now known as cdbs
[12:40] <cdbs> bdrung: ping, out of curiosity, what exactly was wrong in my commit?
[12:40] <bdrung> cdbs: look at the diff
[12:41] <cdbs> bdrung: it looks all fine here: http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/832
[12:41] <cdbs> except for the last hunk, which was again not a big problem
[12:41] <bdrung> cdbs: tabs, trailing tabs
[12:42] <bdrung> cdbs: you forgot to document --buildresult in the man page
[12:42] <cdbs> bdrung: isn't that understood in the last section of the manpage?
[12:43] <cdbs> okay, I got what you meant
[12:43]  * cdbs gets to work
[12:46] <cdbs> bdrung: does cowbuilder-dist support --buildresult? or should I mention in the manpage: Pbuilder-dist only
[12:52] <cdbs> done
[13:07] <bdrung> cdbs: dunno
[13:07] <bdrung> cdbs: does pbuilder-dist can be run without sudo?
[13:10] <bdrung> ebroder: work to do: bug #691862 -> 4 bugs against backportpackage
[13:10] <ubottu> Launchpad bug 691862 in ubuntu-dev-tools (Ubuntu) "upload to ppa for multi dists" [Undecided,Invalid] https://launchpad.net/bugs/691862
[13:13] <cdbs> bdrung: yes, it can be run without sudo
[13:13] <cdbs> infact, I run it without sudo always
[13:14] <cdbs> it runs itself as sudo when needed
[13:14] <bdrung> k
=== Quintasan_ is now known as Quintasan
[14:50] <gusnan> I am upstream of a package, and also maintain it in debian - Now I see that the powerpc build fails in Ubuntu - but I get no log or anything - what is the problem? the page where I would expect a build log just says "Failed to build".
[14:51] <evaluate> gusnan, what's the name of the package?
[14:51] <gusnan> evaluate, scitepoj
[14:51] <gusnan> evaluate, sorry, sciteproj
[14:51] <gusnan> https://launchpad.net/ubuntu/+source/sciteproj/0.3.22-1/+build/2099651
[14:55] <ari-tczew> gusnan: ask on #launchpad
[14:58] <gusnan> ari-tczew, thanks
[15:35] <popey> I have what is possibly a silly question. I have configured squid-deb-proxy on a box on my lan, and squid-deb-proxy-client on my desktop, this works fine, i can see the packages being cached on the server.
[15:36] <popey> however when i use pbuilder-dist, it doesn't use the squid-deb proxy, I assume because the pbuilder doesn't know about squid-deb-proxy ?
[15:36] <popey> how can I get pbuilder to use my lovely proxy?
[15:37] <RainCT> popey: you can  pbuilder-foo login --save-after-login   and change sources.list in there
[15:38] <popey> hmm
[15:39] <popey> can i force a package to be inside the pbuilder?
[15:39] <popey> like squid-deb-proxy-client ?
[15:39] <tumbleweed> popey: pbuilder has an --extrapackages option
[15:40] <popey> ah
[15:40]  * popey reads man pages
[15:40] <popey> thanks
[15:40] <tumbleweed> personally, I use E-series hooks to install things I want present (like pkgbinarymangler, in Ubuntu pbuilders)
[16:02] <hakermania> Hey...
[16:28] <lfaraone> fabrice_sp: the issue with dolphin is that it links to NVIDIA's Cg in violation of the GPL, and that there are GPLv2 - GPLv3 licensing incompatibilities.
[16:28] <lfaraone> fabrice_sp: Right now, its (probably) not legal to distribute dolphin in binary form at all. (so multiverse isn't a way out)
[16:28] <gusnan_> I got the suggestion to ask a motu to trigger a retry of my build - Could somebody please take the time? This is the powerpc build of the package sciteproj I am talking about.(I am sorry, I am not familiar with the proper routines regarding this stuff.)
[16:29] <lfaraone> fabrice_sp: the guy in Debian is trying to re-write the parts of dolphin which use cg.
[16:31] <lfaraone> fabrice_sp: replacing wiiuse is trivial, there are libs in debuntu that do the same thing.
[16:31] <BlackZ> gusnan_: done
[16:31] <gusnan_> BlackZ, Thank you!
[17:03] <fabrice_sp> lfaraone, thanks for the answer! About cg, the toolkit has already a dependency in multiverse (ogre-contrib), so that's why I thought this part wouldn't apply to Ubuntu
[17:04] <fabrice_sp> glennricster, did you see my comment about Debian, and the previous comment of lfaraone ?
[17:05] <glennricster> About cg?
[17:06] <glennricster> I have talked to lfaraone before, so I had some idea this was coming.
[17:12] <fabrice_sp> glennricster, and about someone working on the packaging in Debian
[17:12] <hakermania> Emm, may i have an English Question? What is more correct to say? "Ever notice how ugly he seems to be?" or "Ever noticed how ugly he seems to be?"
[17:16] <danohuiginn> hakermania: IMO they're both fine. Think of them as short for "[Did you] ever notice..." and "[Have you] ever noticed..."
[17:16] <hakermania> Oh cool, thx
[17:24] <hakermania> If any reviewer has time, please have a look at http://revu.ubuntuwire.com/p/wallch
[17:24] <hakermania> Thx in advance!
[17:48] <hakermania> Ey, guys, how many MOTUs are there?
[17:49] <Rhonda> launchpad.net/~motu says 153
=== erhesrhsrtb54vyh is now known as Elbrus
=== yofel_ is now known as yofel
[18:49] <Leon_Wallch_Deve> hi... when i go and click about ubuntu it says: You are using Ubuntu 11.04
[18:49] <Leon_Wallch_Deve>                 - the Natty Narwhal - released in April 2011 and supported until October 2012. And the problem is that now i cannot install a deb file because of an error.. How can i fix this?
[18:49] <Leon_Wallch_Deve> i really do not know why it says 11.04
[18:56] <Rhonda> Potential because you have put natty into your /etc/apt/sources.list file.
[18:57] <Rhonda> Downgrade is not supported and pretty troublesome. I suggest either a re-install with maverick or live with having the development release and work around the trouble you have.
[18:57] <Rhonda> Unless you describe your error noone will be able to help you. And actually, #ubuntu might be more suiting for these kind of questions, me thinks. :)
[19:00] <Leon_Wallch_Deve> error: Requires installation of untrusted packages: The action would require the installation of packages from not authenticated sources.
[19:00] <Leon_Wallch_Deve> yes i asked also the #ubuntu and #ubuntu+1
[19:05] <Leon_Wallch_Deve> ok fixed :-D
[20:19] <glennricster> fabrice_sp:  Are you around?
[20:28] <fabrice_sp> glennricster, yes
[20:29] <glennricster> If I am interpreting things correctly, you are saying that if we kill the wiiuse licensing we can get dolphin-emu into Ubuntu regardless of the NVidia Cg issue?
[20:30] <fabrice_sp> this is what I think, yes, but this has to be confirmed, as we already have a package that depends on cg
[20:31] <glennricster> The code that we have licensed under the wiiuse license in dolphin-emu is no longer the upstream wiiuse code.  So it seems justifiable that we could put that code under the dolphin-emu license and rename things.  The upstream wiiuse does not seem to be maintained either.
[20:33] <fabrice_sp> not sure about this one
[20:34] <fabrice_sp> I think you should ask to the copyright owner
[20:35] <glennricster> If you base your code on something that is done in another library you don't have to put the license of the other library on it.  Perhaps state that you borrowed code ideas from that library, but you don't need the license or copyright.  This is done all the time with open source code.
[20:35] <ScottK> glennricster: That is incorrect.
[20:36] <glennricster> Why is that incorrect?
[20:36] <ScottK> It is often done, but done wrongly.
[20:36] <ScottK> If you copy code from another library it's license comes with it.
[20:36] <ScottK> The only way you can change the license is if the copyright holder authorizes it.
[20:37] <glennricster> I am not talking about copying code from another library.  I am talking about using the code snippets or really ideas from another library.
[20:37] <ScottK> (in some cases permission is embedded in the actual license such as saying code is licenses until GPL V2 and later versions, but that's rather the exception)
[20:37] <ebroder> glennricster: "using code snippets" is copying code
[20:38] <ScottK> If you do a complete reimplementation of concepts then it's OK.
[20:38] <glennricster> ScottK:  That is what I am talking about.
[20:38] <ScottK> glennricster: OK.  Then I guess I misunderstood what you meant by "base your code on something".
[20:39] <glennricster> If you look at the wiiuse code that we have, it already pretty much is a reimplemantation of what wiiuse was upstream.  There are just a few things that we would need to change to make it not at all copied code.
[20:40] <ari-tczew> bdrung: could on look on package xmp, whether can I drop changes to disable build audacious?
[20:40] <ari-tczew> package built fine without these changes
[20:41] <fabrice_sp> ScottK, and about cg? dolphin-emu is linked again nvidia-cg-toolkit, but is GPL
[20:41] <fabrice_sp> and according to lfaraone, this is not compatible
[20:41] <ScottK> GPL linking against non-GPL compatible libraries is just plain not distributable.
[20:43] <fabrice_sp> ok. glennricster ^
[20:45] <glennricster> So we will have to implement GLSL to get dolphin-emu in?
[20:46] <bdrung> ari-tczew: ?
[20:56] <ari-tczew> bdrung: I asked you because you are familiar with xmp. doko has added a change to disable build audacious plugin in xmp package.
[20:58] <ari-tczew> bdrung: sorry, I mean you're familiar with audacious
[21:02] <bdrung> ari-tczew: xmp needs to be update to support audacious 2.4
[21:02] <cemc> is it possible to use -jX when building packages with pbuilder to use multiple cores/cpus?
[21:02] <lfaraone> glennricster: plus, they didn't completely reimplement it, I found about half of the code was the same.
[21:03] <bdrung> ari-tczew: enable the audacious plugin and fix the ftbfs ;)
[21:03] <glennricster> lfaraone:  We aren't done reimplementing it.
[21:03] <glennricster> There is more to come.
[21:03] <glennricster> I intend to do it myself.
[21:04] <lfaraone> glennricster: fair enough. there are, by the way, perfectly good existing libraries that are compatible with dolphin's license in Debian already.
[21:04] <lfaraone> glennricster: the owner of the
[21:04] <lfaraone> (and ego ubuntu)
[21:05] <glennricster> We don't need that sort of functionality though.  We really need what we have set up now.  The other libraries (upstream wiiuse included) do not provide the direct access to a wiimote that we need.
[21:05] <lfaraone> glennricster: the owner of the ITP in Debian has been working on switching to GLSL I think, and he said he's replaced wiiuse with a compatible library. you should email him to see if you can work together.
[21:17] <ScottK> cemc: Yes.  Just add -jx onto the end of your pbuilder invocation (IIRC)
[21:17] <ScottK> (or maybe it was before the .dsc)
[21:28] <ari-tczew> bdrung: without disabling package built fine
[21:28] <bdrung> ari-tczew: is it a new upstream version?
[21:29] <ari-tczew> bdrung: yes
[21:29] <bdrung> ari-tczew: great
[21:34] <ari-tczew> bdrung: so, can I drop?
[21:35] <bdrung> ari-tczew: yes, you can drop the disabling = enable audacious plugin