[00:02] <Laney> motu-release folks: How do you determine whether a library has new features?
[00:03] <Laney> http://gitorious.org/projects/git-python/repos/mainline/blobs/master/CHANGES <- we currently have 0.14.1
[00:05] <ScottK> Laney: It's got features.
[00:05] <Laney> ScottK: That's what I thought
[00:05] <Laney> thanks
[00:05] <ScottK> Does it have rdepends?
[00:06] <Laney> dunno, just looking at the u-u-s queue
[00:06] <Laney> no
[00:06] <ScottK> Might be worth doing.  Dunno.  It looked like mostly fixing.
[00:07] <Laney> andersk: ^^ (about bug 337460)
[00:12] <Laney> jpds: apologies for not uploading u-d-t myself
[00:12] <Laney> :(
[00:20]  * Laney is using bzr builddeb for the first time
[00:21] <james_w> \o/
[00:22]  * porthose thinks bzr builddeb rocks 
[00:22]  * directhex wonders what's wrong with good ol' cvs
[00:24] <Laney> wait
[00:24] <Laney> guh, it didn't work
[00:27] <james_w> what went wrong?
[00:28] <Laney> I guess the branch is borked somehow
[00:28] <slangasek> directhex: there are copious blogs and case studies on the Internet that answer that question; perhaps you'd like to troll the author of one of those, instead of trolling here :P
[00:28] <Laney> http://dpaste.com/19307/
[00:29] <Laney> maybe it's not set up for builddebbing or something
[00:29] <Laney> looks like it checked out the wrong version
[00:29]  * Laney fails
[00:29]  * Laney should read docs before trying things
[00:34] <Laney> hah
[00:34] <Laney> broken get-orig-source and watchfile
[00:35] <Laney> nice(!)
[00:41] <Laney> much better
[01:53] <leonel> scottK what means the  X in the packages in the tables in  https://wiki.ubuntu.com/MOTU/Clamav
[01:53] <ScottK> leonel: It means they don't exist in that release.
[01:53] <leonel> scottK Ok ..
[02:35] <ripps> Does anybody know why automake would freeze and consume large amounts of ram in a build environment, but not in normal desktop environment?
[03:58] <fabrice_sp> Hi. bug Bug #277926 still happens in Jaunty, and is fixed in debian Unstable's version. Is it better to apply the fix to actual jaunty's version or request a sync for synfigstudio? (as we are in Beta Freeze)
[04:02] <dtchen> fabrice_sp: the fix linked from comment 20 would be the way to go
[04:03] <dtchen> fabrice_sp: i.e., apply it to jaunty's existing source package
[04:04] <fabrice_sp> dtchen, ok. That's what I thought. This way, I can fill a SRU for intrepid after. By the way, this package FTBFS (Bug #336583). Should I update the debdiff in that bug report to add this patch?
[04:05] <ScottK> fabrice_sp: Yes.  Combine the changes into one debdiff.
[04:06] <fabrice_sp> will do. Thanks!
[05:58] <dholbach> good morning
[06:02] <fabrice_sp> Hey dholbach
[06:02] <fabrice_sp> how are you this morning ;-)
[06:02] <dholbach> hi fabrice_sp - very good, thanks
[06:02] <dholbach> how 'bout you?
[06:03] <fabrice_sp> good too :-)
[06:04] <fabrice_sp> could you please have a quick look at bug #348160?  Someone else put a debdiff, and we 'disagree' on using quilt or not ;-)
[06:04] <fabrice_sp> just to be sure I'm not totally wrong
[06:05] <iulian> Heya dholbach, fabrice_sp.
[06:05] <fabrice_sp> Hey iulian ! :-)
[06:05] <dholbach> hiya iulian
[06:06] <dholbach> fabrice_sp: autotrace clearly just patches the source directly
[06:07] <fabrice_sp> dholbach, that's exactly what I saw :-) I'll wait his answer then. Thanks ;-)
[06:07]  * fabrice_sp hugs dholbach 
[06:08] <dholbach> fabrice_sp: I generally feel that if you're not maintaining the package yourself, it's not worth adding a patch system
[06:09] <fabrice_sp> dholbach, ohh. ok. Anyway, I'll also ask him to report the fix to debian, so that next time, we can just sync
[06:09] <dholbach> sounds good
[06:09]  * dholbach hugs fabrice_sp back
[06:10] <fabrice_sp> :-)
[06:54] <didrocks> good morning o/
[06:59] <a|wen> morning didrocks
[07:05] <didrocks> hey a|wen
[07:22] <DanMcGoo> hi
[07:23] <RAOF> Someone's quite likely to want to help you here :)
[07:26] <RAOF> You need some packaging help?  What with, and have you already read the packaging guide?
[07:26] <DanMcGoo> Actually I am trying to build my first debian package
[07:27] <DanMcGoo> I am quite advanced and I almost finished it
[07:27] <DanMcGoo> but I have one problem
[07:27] <DanMcGoo> /usr/bin/install -c -D -m 755 .libs/libOpenDRIMCommon.so /home/guillaume/DEB/test/libopendrim-common-1.0.3/debian/tmp/usr/lib/
[07:28] <DanMcGoo> this line make one error because the usr/lib directory does not exist under debian/tmp
[07:29] <RAOF> Have you written that?  What is trying to execute that?
[07:30] <DanMcGoo> actually it is trying to execute it
[07:32] <ttx> DanMcGoo: it's your "make install" that executes that ?
[07:32] <DanMcGoo> yes
[07:32] <DanMcGoo> actually the install section have been entierly rewritten by my predecessor
[07:32] <ttx> DanMcGoo: then it means make install doesn't create directories on targetdir if they are missing
[07:32] <RAOF> So, you'll need to fix the makefile.
[07:32] <DanMcGoo> yes correct
[07:33] <ttx> you can workaround that by adding usr/lib in a "debian/dirs" file
[07:33] <DanMcGoo> so i should do an "install -d DIRECTORY" right ?
[07:33] <DanMcGoo> really ?
[07:33] <DanMcGoo> it will create it automatically ?
[07:33] <ttx> well, it depends on what your rules file looks like
[07:33] <ttx> if its CDBS it will
[07:34] <DanMcGoo> autogenerated by dh_make
[07:34] <ttx> if its debhelper then you'll need dh_installdirs in there (should be there)
[07:34] <DanMcGoo> it's there
[07:35] <ttx> so the dirs trick should do it. Though you should rather fix your makefile, since you control both sides :)
[07:35] <ttx> DanMcGoo: otherwise it will fail on anyone deploying in something else than /
[07:36] <DanMcGoo> but I read this from the Ubuntu Packaging guide: "You only need to use dh_installdirs if your package needs to ship empty nonstandard directories"
[07:36] <ttx> yes, that's why it's a workaround. Proper fix is to patch the makefile
[07:37] <DanMcGoo> ok I c
[07:37] <DanMcGoo> thanks for the help ^^
[07:37] <ttx> np
[07:39] <DanMcGoo> so actually I have another question
[07:39] <DanMcGoo> I added install -d /usr/lib
[07:39] <DanMcGoo> what will happen if I do a ./configure --prefix=/usr ?
[07:39] <DanMcGoo> it will create a /usr/usr/lib directory ?
[07:45] <ttx> DanMcGoo: it obviously depends on what your configure/makefile make of it... but I thnink the make install DESTDIR will be overridden correctly
[08:21] <gnunezr> Hello... Any MOTU around for a (I hope) quick question :)?
[08:23] <ttx> gnunezr: just ask and you may be answered.
[08:23] <gnunezr> Ok... I have a debdiff for a bug in launchpad, but I'm not sure how to proceed...
[08:24] <gnunezr> Not even sure if this is the right place for such a question
[08:24] <gaspa> gnunezr: did you already upload the debdiff on LP?
[08:24] <gnunezr> Uh... Nope
[08:24] <ttx> gnunezr: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue might help
[08:25] <gaspa> ttx: embarassed? :D
[08:25] <ttx> uh.
[08:25] <gaspa> ttx: am I so scary?
[08:25] <ttx> I knew it might help, but so quick, I'm impressed.
[08:26] <gonzalo_> oops... sorry ttx... xchat just died on me
[08:32] <Toadstool> good morning
[08:35] <gonzalo_> ttx, gaspa: Uh... I don't see the bug listed in the Sponsors Queue. The bug in question is LP #107668, in the 'gnome-mount' package.
[08:37] <gaspa> gnunezr: so, when you think you tested enough your patch, (1) attach it to the bug report,(2) set it as confirmed, and (3) subscribe ubuntu-{main,universe}-sponsors to the bug.
[08:37] <ttx> gnunezr: there is already a developer assigned to it
[08:38] <gaspa> uh, right
[08:38] <gaspa> gnunezr: talk with pitti, then. :P
[08:39] <gnunezr> ttx, gaspa: Ok... So, I just add a comment in the bug report addressed to him?
[08:39] <ttx> gnunezr: sounds good.
[08:40] <gnunezr> ttx: Ok, cool... Thanks both ttx and gaspa :) G'nite/G'day (depending on where in the world are you ;) )
[08:41] <gaspa> ...and in which part of the day we use to sleep...
[08:42] <gnunezr> lol... Indeed!
[08:43] <gnunezr> thanks! l8r
[09:02] <binarymutant> dholbach, did you mean the copyright was wrong?
[09:03] <dholbach> binarymutant: no, you said that the last patch was "reversed"
[09:04] <dholbach> binarymutant: I don't think that's true
[09:04] <binarymutant> dholbach, the first one I had posted was
[09:04] <dholbach> binarymutant: the copyright stuff the new patch wants to change for example is in the patch already
[09:06] <dholbach> binarymutant: http://paste.ubuntu.com/138086/
[09:06] <dholbach> whatever the new patch is supposed to do, it fails to apply
[09:06] <dholbach> and the old patch applied cleanly (and I did not have to use "-R")
[09:09] <binarymutant> dholbach, this bug needs to be closed, this debdiff was already applied from bug #347346 and I think thats why its reversed
[09:11] <dholbach> binarymutant: ok, just close it then :)
[09:12] <binarymutant> sorry about that, how do I close it? change status to fix released?
[09:13] <dholbach> or invalid, yep
[09:13] <dholbach> no worries
[09:13] <binarymutant> ty ty
[10:16] <a|wen> what is the procedure for security-updates in universe?
[10:18] <a|wen> as a MOTU do i still subscribe motu-swat / ubuntu-security? and what status should i use (can't seem to find that info)
[10:20] <siretart`> kees: -^^
[10:51] <a|wen> i've gone with triaged now and subscribed motu-swat ... please let me know, if i can/should do someting more myself
[12:10] <dholbach> who of you would like to give a 15 minute demo of something to do with packaging some time in the next month? something like "updating a gnome package" or "what dh_install --list-missing can do for you" or "not going nuts with quilt"
[12:10] <dholbach> it's for the packaging training sessions we're planning
[12:24] <maxb> not going nuts?
[12:25] <dholbach> maxb: or "avoiding pain with quilt" or something - whatever :)
[12:25] <maxb> ah, right :-)
[13:11] <a|wen> mdeslaur: ping
[13:15] <ScottK> a|wen: There's a wiki page (don't recall exactly which) that tells you what to do with bug status and such to make sure they pick it up.
[13:16] <mdeslaur> a|wen: yes
[13:17] <a|wen> mdeslaur: also about the patch tagging; when they are applied inline, should the ubuntu-applied-patches be inside or outside the debian dir?
[13:18] <mdeslaur> a|wen: when they are applied inline, just include the urls and bugs in the changelog as you've been doing
[13:19] <mdeslaur> a|wen: I've never done the "ubuntu-applied-patches" directory
[13:19] <mdeslaur> of course, if there is one already, than put your patches in it
[13:21] <a|wen> mdeslaur: so generally making a specific link to the patch if that is possible ... i'm working on the fix for the last two squirrelmail CVE's as you mentioned
[13:22] <mdeslaur> a|wen: yeah...if we discover a bug in a patch, it'll be easier to figure out where we got it from. It's also easier to review if there's a link.
[13:22] <mdeslaur> a|wen: cool!
[13:23] <a|wen> mdeslaur: makes sense ... this time around it is upstream svn revisions, so they should be easy to locate
[13:26] <a|wen> ScottK: i've found the wiki page about it ... but it doesn't mention anything about statuses
[13:26] <mdeslaur> a|wen: did you see my comment about the odd line in the hardy mediawiki debdiff?
[13:26] <ScottK> a|wen: I think they have to be In Progress to show up on their filter, but mdeslaur would know better.
[13:27] <mdeslaur> yes, our script pulls bugs that have "In Progress" and a patch attached
[13:27] <mdeslaur> you also need to check "This attachment is a patch" when you attach a debdiff
[13:27] <ScottK> a|wen: If you've got a wiki page that doesn't say that, please edit.
[13:27] <a|wen> mdeslaur: ahh, thanks! that was the info i needed
[13:27] <mdeslaur> https://wiki.ubuntu.com/SecurityUpdateProcedures
[13:28] <mdeslaur> step 7 of "Preparing an update"
[13:29] <a|wen> got it... some other places were referencing the standard sponsorship procedures, and that is somewhat different
[13:31] <a|wen> mdeslaur: just looked at your comment to the patch... it should be good enough
[13:31] <mdeslaur> a|wen: ok, I'll push it out as-is then
[13:32] <mdeslaur> thanks for looking :)
[13:32] <a|wen> mdeslaur: i need to add to the end of the file, but as it doesn't have a newline the diff needs to contain a removal of the last line and a re-insert
[13:32] <a|wen> agreed, it does make things look kind of strange :)
[13:33] <mdeslaur> oh! that line is diff-generated?
[13:34] <mdeslaur> Curiously, I've never seen that before :)
[13:34] <a|wen> mdeslaur: exactly, the "\no newline" is diff-generated
[13:35]  * mdeslaur learns something new today :)
[13:35]  * a|wen did that as well :)
[14:45] <a|wen> mdeslaur: do you want to include the two other security fixes in the squirrelmail dapper ... or is it so far in the process, that is should wait till it is done and then make a new update?
[16:21] <directhex> motu-release, i choose you!
[17:13] <Turl> hi, can you guide me on patching with cdbs?
[17:17] <jpds> Turl: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#CDBS%20with%20Simple%20Patchsys
[17:17] <Turl> thanks jpds
[17:18] <jpds> Turl: Life is a lot easier with simple-patchsys.
[17:53] <Turl> I'm having a problem with sbuild
[17:53] <Turl> it doesn't build my package because it says 'amd64' is not in 'all'. but all means all!
[17:54] <slytherin> need some help from licensing experts. the luatex package does not contain a 'COPYING' file. Instead COPYING is a symlink and the target does not exist. What should I do about it?
[17:55] <slytherin> Turl: can you paste your debian/control file in pastebin?
[17:56] <Turl> slytherin: it's untouched from the original package in the repos, http://paste.pocoo.org/show/109742/
[17:57] <slytherin> Turl: looks fine to me. it's weird that you are getting that error.
[17:57] <slytherin> Turl: I am not much familiar with sbuild, so can't help much. :-(
[17:57] <Turl> slytherin: postr_0.12.3-1ubuntu2.dsc: amd64 not in arch list: all -- skipping
[17:57] <Turl> np
[17:57] <Turl> I'll see if PPAs build it
[17:58] <slytherin> Turl: have you tried with pbuilder?
[17:58] <Turl> nope slytherin
[17:58] <sistpoty|work> slytherin: as luatex is (mainly) GPL, repack the orig.tar.gz and add a copy of the GPL (and inform upstream, seems to have been a mistake)
[17:59] <slytherin> sistpoty|work: that looks like a lot of work to me as of now. I was just trying to rebuild it against latest libpoppler.
[18:00] <sistpoty|work> slytherin: then you shouldn't have asked what you should do about it :P
[18:01] <slytherin> sistpoty|work: I was expecting something like "file a bug in debian". :-D
[18:03] <slytherin> sistpoty|work: by the way, the debian/copyright is a bit complicated. So it doesn't look like it is mostly GPL.
[18:07] <Turl> any motu in here?
[18:09] <slytherin> Turl: quite a few
[18:10] <sistpoty|work> slytherin: but the missing link seems to be the GPL, as (from a quick glimpse) only the GPL is missing in the tarball
[18:11] <sistpoty|work> slytherin: e.g. LGPL is in some subdirectory
[18:11] <slytherin> sistpoty|work: I will take a look after I finish working on other packages.
[19:18] <ScottK> The joys of upgrading.
[19:18] <ScottK> I upgraded my test server to Jaunty today and mail didn't work.
[19:18] <ScottK> It turns out that a Python module update I did a month ago I forgot to upload.
[19:21] <hyperair> lol
[19:23] <ScottK> Fortunately it didn't take me long to find an archive admin to accept it.
[19:24] <hyperair> how nice
[19:25] <ScottK> Normally one doesn't approve their own uploads, but since Universe stuff isn't be scrutinized, just waved through it was easy.
[19:27] <directhex> oh. erm... looks like the security team need to work on sun-java
[19:27] <hyperair> what's wrong with it?
[19:27] <kees> debdiffs welcome.  :)
[19:28] <directhex> http://sunsolve.sun.com/search/document.do?assetkey=1-66-254571-1
[19:28] <directhex> Buffer Overflow Vulnerabilities in the Java Runtime Environment (JRE) with Processing Image Files and Fonts may Allow Privileges to be Escalated
[19:28] <slytherin> hggdh: do you plan to package Anjal for intrepid as well?
[19:28] <directhex> just got a critical mail from the university security team about it
[19:28] <kees> directhex: switch to openjdk-6 instead?
[19:28] <kees> https://launchpad.net/ubuntu/+source/openjdk-6
[19:29] <directhex> kees, well, yes, but the packages in the archive as-is are vulnerable
[19:29] <kees> not openjdk-6.
[19:29] <directhex> kees, true
[19:29] <kees> (but yeah, sun-java needs an update)
[19:29] <directhex> poor doko
[19:30] <jdstrand> sun-java is multiverse, community supplied debdiffs are most welcome
[19:30] <hggdh> slytherin, I am not sure yet
[19:30] <directhex> i'm not a java packager, and it doesn't affect me. i was just mentioning it. let me check if there's an open bug
[19:30] <slytherin> jdstrand: how is anyone supposed to provide debdiff for binary only packages?
[19:31] <hggdh> slytherin, srag and I are considering it, but we will need to rebase the Evo/EDS patches to Evo/EDS 2.24
[19:31] <directhex> nope. i'll file a bug. it's a start
[19:31] <slytherin> hggdh: Ok. May be I can provide packages in my PPA.
[19:32] <hggdh> slytherin, or, perhaps, we could ask for an "anjal" PPA -- it would make things easier, all in one place
[19:33]  * hggdh is not sure how to proceed on having a team PPA
[19:33] <jdstrand> slytherin: one needs a relationship with sun IIRC. it's their licensing that keeps it from being officially supported, which is why kees recommended openjdk
[19:33] <slytherin> hggdh: or since it is targeted at small screens, ask mobile-team to provide the packages in their PPA.
[19:33] <hggdh> slytherin, indeed
[19:34] <directhex> okay, Bug #349135 filed
[19:34] <directhex> relevant people can determine which releases need fixing
[19:34] <kees> directhex: please "public" it :)
[19:34] <slytherin> jdstrand: I know. My question was reply to your quote "community supplied debdifs are welcome". It is not possible to patch sun-java packages.
[19:34] <jdstrand> if a community member were so inclined to provide updated packages (version bump and all), they could be uploaded and reviewed
[19:35] <jdstrand> slytherin: s/debdiffs/updated packages/
[19:35] <slytherin> directhex: only java 6 packages are affected.
[19:35] <slytherin> :-)
[19:35] <slytherin> no, wait. I misread. even java5 is affected.
[19:35] <directhex> yeah
[19:36] <directhex> slytherin, i should re-file against sun-java5
[19:36] <directhex> there
[19:36] <slytherin> directhex: yup, a separate bug is better.
[19:38] <directhex> oh, is it? bugger :(
[19:38] <directhex> i made the bug multi-package
[19:39] <slytherin> directhex: I was talking from tracking point of view. And also java5 is affected by only one issue. java6 is affected by both.
[19:40] <directhex> bah, i suck
[20:04] <slytherin> can anyone please confirm bug 349146?
[20:07] <hggdh> slytherin, I am sending an email to the mobile team asking about using their PPA
[20:08] <slytherin> hggdh: you will have to be team member
[20:08] <hggdh> slytherin, yes, I understand that. I hope, at least, you are... but I am asking anyway. At least I tried ;-)
[20:09] <hggdh> I personally doubt I would be accepted, since I have no track record on mobile thingies
[20:10] <slytherin> hggdh: i am not a team member
[20:12] <slytherin> hggdh: you can try asking in #ubuntu-mobile
[20:12] <hggdh> slytherin, heh. This may make it a bit more difficult
[20:12] <hggdh> and yes, good idea. Getting there now
[20:15] <c_korn> slytherin: the icon for logout is different than the one for shutdown
[20:15] <slytherin> c_korn: are you using human icon theme?
[20:16] <c_korn> slytherin: yes, but I use an updated fusa
[20:16] <c_korn> slytherin: https://launchpad.net/~getdeb.packages/+archive/ppa
[20:17] <c_korn> this one is proposed for jaunty
[20:17] <slytherin> c_korn: it is not just fusa, if you remove it from panel, the logout option in the system menu also has icon that looks like shutdown.
[20:18] <c_korn> slytherin: http://www.ubuntu-pics.de/bild/11599/screenshot_001_pyR6I0.png
[20:18] <c_korn> shutdown has a different icon
[20:18] <c_korn> but it is still confusing, you are right
[20:19] <slytherin> that is why I said the icon is 'similar' to shutdown icon. :-)
[20:19] <c_korn> slytherin: is this a human-icon-theme bug or fusa bug?
[20:20] <slytherin> c_korn: human-icon-theme. because the icon itself is wrong in the theme. so if a user is not using fusa, he will have problem even in system menu.
[20:20] <c_korn> ok
[20:22] <c_korn> slytherin: confirmed
[20:22] <slytherin> c_korn: thanks
[20:51] <datag> in a few days i'm releasing a Qt4 based game. altough i'm trying to provide a linux-generic package (including libs) i would like to provide an ubuntu package as well. i'm uncertain if i should build a package on my own or if a package maintainer could have a look at it. some advice?
[20:54] <directhex> datag, you'd need to get enough interest out of a packager if you expect them to do the work for you
[20:55] <datag> directhex: i guessed that :) which is the right way to do this? ask here in irc or should i create kinda ticket (tracker) for package-request?
[20:58] <slytherin> datag: at this point a new package will not enter ubuntu. So it will be hard to convince people here to work on the package. You can try building the package on your own and add it to your PPA if you have launchpad account.
[20:59] <slytherin> datag: what would be even better is package it for Debian and get someone sponsor it. Ubuntu syncs all the packages in Debian at the start of new development cycle.
[21:00] <datag> slytherin: ah, thank you for that advice. i think i'll first try to build a deb package on my own and provide it to a debian maintainer
[21:03] <datag> another thing, might be a bit offtopic: building generic binary packages is a hell. i've tried to use ubuntu as a base copying shared libs into my archive. i guess this isn't a good idea? ;)  (a better method might be to build stripped dependencies (libs) on my own and provide these)
[21:08] <slytherin> datag: what do you mean by generic binary package?
[21:09] <datag> slytherin: a package which does not depend on a specific distribution by providing most needed shared libs (sdl, qt4) and running the app with LD_LIBRARY_PATH=my_libs
[21:10] <slytherin> datag: then why not provide a statically compiled binary?
[21:11] <datag> slytherin: yep, that's another way i'm currently thinking of... maybe this would be the best solution.
[21:17] <datag> slytherin: thank you so far. hope i get my Cmake-hell working with static linking qt4 and sdl.. oh, he is gone
[21:27] <directhex> be very careful about licensing when using static compilation tho
[21:28] <datag> directhex: my app is open source (GPLv3) and libSDL and Qt4 do not have any restrictions for this case AFAIK
[21:28] <datag> i hope so
[21:28] <maco> qt4 which version?
[21:28] <datag> 4.5
[21:29] <datag> was there a change in policy recently?
[21:29] <maco> 4.5 is LGPL
[21:29] <maco> up to 4.4 was GPL or commercial only
[21:30] <datag> maco: anyhow, if i provide the sources it doesn't really matter, doesn't it?
[21:30] <maco> dont think so
[21:30] <maco> no idea on libsdl's licensing
[21:30] <directhex> if sdl is 2-only, you have an issue
[21:30] <maco> exactly
[21:31] <datag> oh dear
[21:31] <directhex> 2-only is not compatible with 3+
[21:31] <directhex> 2+ is
[21:32] <datag> SDL is distributed under GNU LGPL version 2
[21:33] <datag> so my option of statically linking is gone :/
[21:34] <directhex> LGPL2 or 2.1?
[21:34] <directhex> and 2 or 2+?
[21:35] <directhex> "The Simple DirectMedia Layer library is currently available under the GNU Lesser General Public License (LGPL)  version 2.1 or newer. "
[21:35] <directhex> that's okay then
[21:36] <datag> directhex: god bless :) thanks
[21:36] <directhex> you have the option when using l2.1+ to license the whole thing as 2+
[21:37] <directhex> http://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix is a reasonable matrix
[21:38] <datag> good resource
[22:05] <RainCT> btw, I'll be away next week (going to Italy :))
[22:09] <directhex> but italy's full of italians :'(
[22:09] <directhex> oh, hi hanska!
[22:16] <RainCT> directhex: yeah...
[22:17] <RainCT> people like norsetto :/
[22:17] <RainCT> bah, he isn't online :P
[22:17] <directhex> i know :(
[22:20] <dtchen> directhex: rsync instead of scp
[22:20] <directhex> dtchen, ECHAN
[22:21] <dtchen> directhex: intentionally ECHAN. it's not Ubuntu development-related.
[22:21] <dtchen> as in: my recommendation is not Ubuntu development-related.
[22:22] <directhex> bug confirmed, btw
[22:25] <directhex> damn, i'm unoriginal. already filed as Bug #218741
[22:31] <ripps> Can someone lead me to some resources on how to make virtual packages.
[22:33] <dtchen> meaning equivs or real virtuals?
[22:34] <ripps> dtchen: Not sure, I'm trying to create a package that will pull in a bunch of plugins automatically.
[22:35] <azeem> ripps: that's not virtual
[22:35] <azeem> that's meta
[22:35] <cjwatson> ripps: your problem may be that you're searching for a term that means something else in our world. The term we use for what you want is "metapackages"
[22:35] <ripps> azeem, cjwatson: thanks, that might be my problem
[22:36] <azeem> ripps: usually, you would just add that binary package to debian/control of the source package building all thos plugins
[22:37] <ripps> azeem: I have a package that builds ~20 seperate packages. I like it like this, but I also want a metapackage to pull them all in simultaneously
[22:38] <azeem> see my above line then
[22:44] <ripps> azeem: Do I have to manually add all the binary packages to it's Depends line, or can I just leave it blank?
[22:54] <azeem> ripps: if you want a package which depends on those plugins (i.e. a meta-package), you will have to add those plugins, yes
[22:54] <azeem> ...to the Depends