[12:16] <TheMuso> jbHey folks.
[12:16] <TheMuso> ugh
[12:16] <TheMuso> hey folks
[12:16] <persia> Hey TheMuso.
[12:17] <persia> TheMuso: Could I convince you to change the license on the packaging for the ubuntustudio-* stuff?  The packages look great, but I'm concerned about GPL vs. CC-BY-SA.  Is this a copy of GPL packaging, or is it yours?
[12:19] <TheMuso> persia: Its not my call. I am a member of the team, and have been asked to state the deal with the licensing on their behalf. I am noexpert, so take it up with them please. If anything, I am with you on this one.
[12:20] <persia> TheMuso: I ask you because you hold copyright on the packaging for the last two packages a reviewed :)
[12:20] <TheMuso> Well I'd have to have another look. Which ones are they?
[12:20] <TheMuso> c
[12:20] <TheMuso> ugh
[12:20] <TheMuso> But I didn't choose the license.
[12:20] <TheMuso> Its just because I did packaging work on them.
[12:20] <TheMuso> No actual artistic work.
[12:21] <persia> TheMuso: Right.  It's only the packaging license that bothers me.  I'll get you a list in a moment.
[12:23] <persia> TheMuso: My apologies.  Apparently it's only one for you: ubuntustudio-screensaver (http://revu.tauware.de/details.py?upid=5764).
[12:23] <TheMuso> Well I haven't even really looked that one over, but I did have a hand in the packaging.
[12:24] <persia> TheMuso: It looks great to me except for " The Debian packaging is (C) 2007, Luke Yelavich and is licensed under the GPL, see above." on CC-BY-SA content.
[12:25] <TheMuso> So what should it be?
[12:26] <ajmitch> hey TheMuso 
[12:26] <TheMuso> Hey ajmitch.
[12:26] <persia> TheMuso: Almost anything else.  I'd recommend CC-BY-SA for maximum compatibility, but PubDom, X11, or BSD would all also be compatible.
[12:26] <TheMuso> ok
[12:26] <TheMuso> gah I hate licenses.
[12:26] <TheMuso> Always does my head in.
[12:27] <persia> TheMuso: Thanks :)
[12:29] <TheMuso> persia: So I can get a better understanding, how is GPL and the CC-BY-SA incompatible?
[12:31] <persia> TheMuso: It has something to do with the attribution.  See http://www.fsf.org/licensing/licenses and http://people.debian.org/~evan/ccsummary.html for opinions by people who actually understand licensing (I just search the web, and have a set of rules of thumb).
[12:31] <TheMuso> Right.
[12:31] <TheMuso> Well how then do the ubuntustudio guys think that the other artwork packages have similar compatible licenses?
[12:32] <persia> TheMuso: They followed the example of ubuntu-artwork :(
[12:32] <TheMuso> Right.
[12:32] <TheMuso> SO how does ubuntu-artwork get in?
[12:33] <persia> TheMuso: More generally, _MMA_ and I agreed yesterday that the licensing should probably be fixed, rather than propagate the bug.
[12:33] <persia> TheMuso: I'm not sure - it looks like a bug to me.
[12:34] <TheMuso> Right.
[12:34] <TheMuso> So its just the debian packaging thats conflicting with GPL correct?
[12:35] <persia> TheMuso: Rather the debian packaging is GPL, so the combined work of the binary package cannot be distributed for upstream CC-BY-SA.
[12:35] <TheMuso> Right
[12:35] <TheMuso> Yet Toby Smithe hasn't been around alot.
[12:36] <persia> TheMuso: I think that's easiest, as otherwise we need to document your approval of changing the license somehow.
[12:36] <TheMuso> persia: Whats easiest?
[12:37] <persia> ***TheMuso ponders whether he should just completely fix up screensaver, and re-upload to REVU.
[12:37] <_MMA_> persia: Wait. So you mean to say we need to change the license on the contents and not the package?
[12:37] <TheMuso> ah
[12:37] <persia> _MMA_: either works, but changing the packaging license is likely easier.
[12:38] <_MMA_> Yes. We cant change the contents.
[12:38] <_MMA_> TheMuso: The screensaver should just be whatever the Ubuntu one is right?
[12:38] <TheMuso> _MMA_: I don't know.
[12:39] <_MMA_> ok
[12:39] <TheMuso> I am no license expert.
[12:39] <_MMA_> Well I was saying we just copy that one.
[12:39] <_MMA_> I thought thats what we did anyway.
[12:40] <persia> _MMA_: As far as I know, that is what you did.  I'm just picky about licenses (having had too many archive-admin rejects from things I advocated).
[12:41] <minghua> I only read the IRC discussion and didn't check the packages, but I am going to jump in anyway:
[12:42] <minghua> I believe the Ubuntu stance is that cc-by-sa is okay to enter archive
[12:42] <minghua> but I agree with persia that cc-by-sa package with packaging licensed to GPL is definitely a no-go
[12:42] <persia> minghua: Absolutely.  There's no problem with CC-BY-SA, just mixing with GPL is not OK.
[12:43] <_MMA_> persia: I see. We'll probably uncover another bug. ;)
[12:43] <_MMA_> (darn router)
[12:44] <minghua> persia: BTW I just commented a REVU package to use the same license as upstream for packaging :-)
[12:44] <persia> minghua: That's my general recommendation, although I don't have any objections to compatible licenses (e.g. CC-BY-SA content with BSD packaging).
[12:45] <TheMuso> and notes he doesn't have a lot of time before he has to go.
[12:46] <minghua> persia: my case was LGPL upstream and GPL packaging.  I think it's ok, but I would prefer simple situations.
[12:46] <persia> TheMuso: May as well go CC-BY-SA: it's the easiest choice, and makes debian/copyright nice and short.
[12:46] <TheMuso> persia: ubuntustudio-default-settings is a bit of a hack, and I wish that wasn't uploaded, as I would rather do that myself.
[12:46] <minghua> It's not like you're going to lose anything by changing you packaging from GPL to LGPL
[12:46] <persia> minghua: Yeah.  That falls under "recommendation" rather than "advocation block" for me.
[12:46] <TheMuso> I need to fix a few things in it that are against sanity.
[12:46] <persia> TheMuso: Archive it and do it differently :)
[12:47] <minghua> persia: Definitely.  I put it to "things should be fixed" section.
[12:47] <TheMuso> persia: Yep ok.
[12:47] <TheMuso> Just don't have time today and won't be able to for the next week.
[12:47] <persia> TheMuso: Maybe leave a comment then.  Toby might be around, and can have a go.
[12:47] <TheMuso> who uploaded it?
[12:48] <TheMuso> I don't remember doing so.
[12:48] <persia> TheMuso: Toby
[12:48] <TheMuso> ah
[12:48] <TheMuso> thought so
[12:50] <persia> TheMuso: On the other hand, that one doesn't have any licensing issues :)
[12:50] <TheMuso> persia: I know, as I created it from the ground up.
[12:54] <TheMuso> anyway, time to go start getting ready.
[12:54] <persia> TheMuso: have a good trip.
[12:55] <TheMuso> persia: Thanks.
[01:57] <peanutb> Is it bad if i uploaded a Multiverse package change to REVU?
[01:59] <persia> peanutb: Probably not.  Is it a new upstream version?
[01:59] <peanutb> upstream?
[01:59] <peanutb> I just made a small change to include the logo for acidrip.
[01:59] <persia> peanutb: To ask differently, is the change an upgrade, or just a patch?
[02:00] <peanutb> persia, just a patch
[02:01] <persia> peanutb: REVU isn't really the right place for patches.  You'll get a faster response by attaching a debdiff to the bug.  See https://wiki.ubuntu.com/MOTU/Contributing for some instructions (under "Preparing New Revisions").
[02:02] <persia> peanutb: Also, which package?  I'd like to archive the REVU upload.
[02:03] <peanutb> ok. I didnt really read that. The debdiff is on the bug. Its called acidrip
[02:04] <peanutb> Thanks for helping a stupid person such as me with this.
[02:05] <persia> peanutb: No problem :)  I'm archiving the REVU upload now.  Please request sponsorship with ubuntu-universe-sponsors for this.
[02:05] <peanutb> ok thanks again
[02:11] <DktrKranz> we prepared a spec to provide some php5 packages which are no longer included in php5 package in main: https://blueprints.launchpad.net/ubuntu/+spec/php5-universe
[02:11] <DktrKranz> we would like to propose this brand new package before feature freeze
[02:12] <minghua> the mail sent to -devel-discuss about checksums is interesting
[02:12] <DktrKranz> is it worth presenting it to some MOTU Meeting?
[02:13] <persia> I don't think you need to present it at a meeting.  The spec looks straightforward (not that I know much about PHP5 packaging).  I suspect you just need REVU and uploading.
[02:14] <DktrKranz> it's on REVU ready for review
[02:14] <DktrKranz> but last word should be pitti's
[02:15] <DktrKranz> anyway, we will be happy to start fixing packaging mistakes
[02:15] <minghua> DktrKranz: so the "we have a separate php-interbase source" in php5 changelog is wrong?
[02:15] <DktrKranz> minghua, yes
[02:16] <DktrKranz> (as of today)
[02:16] <DktrKranz> we had in feisty
[02:16] <DktrKranz> but it is no longer the case
[02:16] <DktrKranz> see package-removals.
[02:16] <minghua> DktrKranz: why is it dropped?
[02:17] <DktrKranz> http://people.ubuntu.com/~ubuntu-archive/removals.txt
[02:17] <DktrKranz> obsolete source package
[02:17] <DktrKranz> it was uploaded but never kept synced with php5
[02:18] <DktrKranz> so it was dropped
[02:18] <DktrKranz> in gutsy
[02:18] <minghua> I see
[02:18] <DktrKranz> php5-interbase was never uploaded IIRC
[02:18] <DktrKranz> php5-imap and php5-mcrypt did
[02:19] <minghua> php5-interbase is in the removal list, so it should have been uploaded at least some time
[02:19] <DktrKranz> probably yes, I don't remember correctly
[02:20] <DktrKranz> they never reached gutsy, though
[02:20] <DktrKranz> and there are several packages requiring them
[02:21] <DktrKranz> so we should take it into consideration
[02:21] <DktrKranz> (or at least I think so)
[02:22] <minghua> DktrKranz: is the merging strategy agreed on?
[02:22] <minghua> regardless the situation, I don't see much point discuss this in a MOTU meeting
[02:22] <minghua> if the php5 main maintainer (I assume pitti) approves, and there are enough manpower to keep it in sync with Debian php5 source, I don't see any controversy
[02:22] <DktrKranz> the major point is: how can we manage sync with php5 in main?
[02:23] <persia> DktrKranz: I don't think a little skew is an issue.  if you have a dedicated team, and someone uploads new versions within a couple days, it should be OK.
[02:23] <DktrKranz> we can arrange it
[02:24] <DktrKranz> it's not a problem
[02:24] <DktrKranz> there are only few files to look at
[02:24] <minghua> yeah, as long as there is a promise to keep things in sync for each alpha/beta release, I would say it's okay
[02:24] <minghua> temporary version mismatch always happen
[02:25] <DktrKranz> we need to coordinate with php5 maintainers in order to avoid a double php5-* if some universe depends will be dropped or promoted
[02:26] <minghua> DktrKranz: it would be nice if you can clarify the status of the php5-{interbase,imap,mcrypt} packages in gutsy on the spec, though
[02:26] <DktrKranz> minghua, could you explain that?
[02:27] <minghua> DktrKranz: The question I asked about php5-interbase earlier.  I should be able to find answers on the spec IMO.
[02:28] <siti> Hi, are there any tools (I am thinking of making one) that integrates a sane distributed source code management (git etc) with the debian packaging.  I ask this because my experience of creating debian packages is truly awful, especially modifying patches.
[02:28] <DktrKranz> I'm going to add that ASAP
[02:29] <persia> siti: You might be interested in svn-buildpackage and bzr-buildpackage
[02:29] <siti> persia: cheers
[02:29] <minghua> there is gtk-buildpackage IIRC
[02:29] <minghua> git-buildpackage*
[02:30] <siti> ok
[02:30] <persia> Wow.  apt-cache search buildpackage shows support for quite a few VCSs.
[02:30] <siti> minghua: yes, but it's not in ubuntu :(
[02:31] <minghua> siti: even not in gutsy?
[02:31] <siti> I will have a play on the bzr one and see if it's similar to what I was thinking :)
[02:31] <siti> I will have a look on gutsy, one sec
[02:31] <persia> siti: It's new in gutsy.
[02:31] <siti> ok
[02:31] <minghua> although I doubt those *-buildpackage things are exactly intended for the usage siti described
[02:32] <minghua> (I have only looked at svn-buildpackage, though)
[02:32] <siti> minghua: yeah you're right, these just build from git/bzr/* source code
[02:33] <persia> siti: I may have misunderstood then.  What are you seeking to do?
[02:33] <DktrKranz> well, if you could have a look at http://revu.tauware.de/details.py?upid=5701 for a first review, we can begin fixing package
[02:33] <siti> what I am after is something that manages the debian/* the source code, automatic cleaning (no stupid writing rules), maintaining patches to the source code, allowing for bumping with good merging/conflict resolution
[02:33] <siti> sorry I haven't expalined it to well, but do you see what I mean?
[02:34] <siti> have you guys played with dpatch-edit-patch and wanted to kill it?
[02:35] <minghua> siti: and you want to keep track of the git repo of upstream, right?
[02:35] <AndyP> i've found dpatch-edit-patch quite handy
[02:35] <persia> siti: Ah.  *-buildpackage allows VCS of debian/, CDBS automates a lot of the rule-writing, I actually like dpatch for maintaining patches, although some people report quilt to be better, and you might want to look at DaD for automated merging (although there are still bugs).
[02:36] <siti> well, optionally would be nice, if the package does not use git then the tool could grab a new version manually
[02:36] <minghua> I've heard quilt is better, too.
[02:37] <AndyP> quilt is nice too, after you get your head around the stack idea ;)
[02:37] <siti> well just a simple flaw in debian-edit-patch is: I am creating a patch, I edit some of source code, and I want to test it, if I try and test it the patch is screwed
[02:37] <minghua> how so?
[02:37] <persia> siti: Generally, packaging is encouraged of upstream releases (uscan helps automate this), but see https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball for an example get-orig-source: rule that can help automate grabbing new VCS snapshots.
[02:37] <siti> because by me building I made some generated files
[02:38] <minghua> you are using dpatch wrong
[02:38] <siti> how am I mean to use it then?
[02:38] <minghua> generate a patch, then run "debian/rules patch", then test
[02:39] <minghua> don't test/build/whatever in the dpatch generated temporary tree
[02:39] <siti> what about all the **** packages that die after a second build?
[02:39] <persia> Generally, I generate a patch, build a source package, and test build the source package.
[02:39] <persia> siti: Those are bugs.
[02:40] <minghua> which packages die after a second build?
[02:40] <minghua> file bugs and they'll be fixed
[02:40] <siti> lol
[02:40] <minghua> (most likely there is already a bug filed in Debian)
[02:40] <siti> why is there no automated testing of the double build problem?
[02:41] <persia> siti: No, really.  There's a couple people trying to fix that for every Debian package, and if you find any new packages with the problem, it would be a great help to make sure they are reported.
[02:41] <minghua> there is, currently, in Debian
[02:41] <minghua> that's why I asked which packages those are
[02:41] <siti> well we could make those people obsolete and free to work on decent things ;)
[02:41] <siti> xkeyboard-config for one
[02:41] <siti> iirc gksu/libgksu
[02:42] <minghua> I don't see Debian bugs on either gksu or libgksu
[02:43] <minghua> xkeyboard-config is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424112
[02:44] <ubotu> Debian bug 424112 in xkeyboard-config "xkeyboard-config: FTBFS if built twice in a row" [Important,Open]  
[02:44] <siti> seriously, if I get my idea in action, I think maintaining debian packages will be twice as easy ;)
[02:45] <siti> problem is no one would move to it knowing the slow debian devs ;)
[02:46] <minghua> siti: I don't know what you idea is, and I honestly don't see how your VCS based build system question is related to the "fails to build twice in a row" bugs
[02:46] <siti> you could automate cleaning by using a VCS
[02:47] <persia> siti: What if you have local changes that you haven't yet published, and want to test?
[02:47] <siti> that's where a DVCS shines :D
[02:47] <minghua> then instead of publishing source packages, you need to publish a VCS repo
[02:48] <minghua> not necessarily a bad idea, but I don't see it happening soon
[02:48] <siti> well it's a bit different for a DVCS, and an export function to the old format would be good, although the generated patches might be strange
[02:48] <AndyP> i'm pretty sure i've heard this idea before, not that i understand it fully, but i can't remember where from
[02:49] <siti> AndyP: maybe in your head, because it's such a good idea ;)
[02:49] <minghua> If the implementation is there, I think many people will be interested.
[02:50] <siti> yeah, hopefully it's not to hard to make
[02:50] <siti> and one cool advantage is upstream can just cherry pick :)
[02:50] <minghua> I want to point out though, such an system can never be enforced, at least not in Debian
[02:51] <minghua> especially considering there are so many VCS floating around
[02:51] <siti> those rebels :p
[02:52] <minghua> siti: FYI there are quite a few DDs in this channel.
[02:52] <siti> yeah, I am just joking with them
[02:52] <minghua> (and I am a Debian package maintainer, not DD though)
[02:52] <siti> persia: thanks
[02:54] <pleia2> actually I think a lot of us in here are debian package maintainers
[02:55] <DktrKranz> minghua, I edited a bit the spec
[02:56] <AndyP> persia: bah, you beat me to it :)
[02:57] <minghua> DktrKranz: That clarified all my questions, thanks.
[02:57] <DktrKranz> thanks to you :)
[02:58] <siti> minghua: have you used a DVCS?
[02:58] <minghua> siti: not really.
[02:59] <siti> the current package model reminds me of projects that email each other the source code ;)
[02:59] <siti> ie: it's very difficult :p
[02:59] <minghua> I have bzr installed and did a branch once.  I use svk regularly.  But mainly my experience is on svn.
[02:59] <siti> ok
[02:59] <AndyP> i'd like to try the idea just to see what it's like, but i have my reservations
[02:59] <minghua> siti: well, the current model predates most DVCS, so you can't really blame that
[03:00] <siti> yeah I wasn't blaming them, just saying new stuff is out that's better ;)
[03:00] <minghua> the current model perhaps even predates widespread use of email now that I think about it
[03:00] <persia> siti: It's somewhat like emailing patches, but there shouldn't be that many pending changes to a package (if it's broken, fix it).  Most of the interesting effects you get with DVCS are more interesting for the upstream code.
[03:00] <minghua> siti: that's why I am saying if implementation is there, people will be interested
[03:00] <persia> minghua: No.  Debian is post emailed patches.
[03:02] <minghua> persia: I said "widespread" :-P
[03:03] <minghua> although I admit source packages is not a thing end-user should worry about, so widespread email usage is probably irrelevant
[03:03] <siti> but the end user is a developer in a lot of cases
[03:03] <siti> ;)
[03:05] <minghua> not really. especially for ubuntu
[03:05] <AndyP> devs are the vocal minority
[03:05] <siti> :D
[03:05] <minghua> a lot of ubuntu users even consider "rebuild a source package" an impossible task, and prefer to download binary packages from untrusted internet sites
[03:06] <minghua> which is really something I frown upon
[03:07] <AndyP> $graphical_apt_frontend doesn't support it, perhaps
[03:07] <minghua> persia: perhaps because the default installation doesn't have a deb-src line in sources.list? :-)
[03:07] <persia> AndyP: Yep.  That's probably it.  Hmm.  That'd be an interesting feature.
[03:07] <AndyP> :)
[03:08] <persia> minghua: I think that's a side effect of AndyP's note - my memory is that default Debian did include deb-src (although I last installed Debian afresh for potato, so I could very well be wrong).
[03:08] <minghua> persia: They don't for sarge and etch, I'm sure.
[03:09] <minghua> There is a commented off line, though.
[03:09] <persia> minghua: Makes sense.
[03:10] <minghua> also, apt-get --build install is not particularly a small task if you don't have build-essential and various -dev package installed
[03:11] <persia> minghua: True.  Also, the dependencies can interfere with the current system if it's not done in a chroot.
[03:11] <minghua> persia: I am curious.  Any examples?
[03:11] <persia> minghua: Still, it's better than apt-get.org :)
[03:12] <persia> minghua: "interfere" was perhaps too strong a word.  Rather, install extra unwanted software, perhaps generating extra menu items that are confusing.
[03:13] <minghua> well, considering even automatix is praised a lot somewhere else, I'll refrain from complaining about apt-get.org, and just accept that I don't understand the users
[03:13] <minghua> persia: yeah, extra menu items is annoying
[03:13] <minghua> that's probably my main reason for not installing KDE
[03:14] <minghua> (and less download for upgrade, I think)
[03:14] <persia> More specifically, `dpkg --get-selections > my.selections && apt-get build-dep foo && apt-get --build install foo && sed /foo/d < my.selections | dpkg --set-selections` isn't guaranteed not to leave a footprint.
[03:17] <minghua> I think dpkg --set-selctions doesn't do the actual removal of the packages?
[03:18] <minghua> anyway, that line is too hard for me to digest
[03:19] <persia> minghua: No, you're right.  One needs to follow up with something to actually process the removals.
[03:20] <minghua> persia: and why did you removed foo from my.selections?
[03:21] <persia> minghua: The whole point was to install foo.  Thinking about it, I probably wanted to add foo, rather than deleting it.
[03:21] <minghua> :-)
[03:22] <minghua> and you probably want to consider reinstalling foo as well
[03:22] <persia> minghua: Why?  Unless I put it in a repo, won't I not get the local copy?
[03:23] <persia> Alternately, skip the install: have apt do only the build, and use gdebi for the install.
[03:24] <minghua> no, I mean if I already have foo installed, but it's broken (say, obsolete dependency) and can be fixed by a rebuild
[03:24] <persia> minghua: Right.  So, I rebuilt it locally, and installed the local copy.  Why reinstall?
[03:25] <persia> Or do you mean apt-get --build --reinstall install foo?
[03:25] <minghua> but your old and new "dpkg --get-selections" list will both include foo
[03:25] <minghua> and you don't want to have two "foo" lines there
[03:26] <minghua> that's all I meant by "you probably want to consider..."
[03:26] <persia> minghua: Ah.  In that case, since the version didn't change (no changelog update), it won't cause any issues to just leave my.selections alone.  I was thinking of the case where foo was uninstallable for some reason, and the user really wanted it.
[03:26] <minghua> persia: I don't really know what "apt-get --build install" do, though
[03:27] <persia> minghua: It downloads the source, calls dpkg-buildpackage, and installs the result.
[03:27] <minghua> yes, yes.  I am just pointing out another user case for rebuilding a pristine source package
[03:28] <persia> Right.  Now, if only there weren't so many drawbacks regarding implications to the rest of the system of having all the build-deps installed, I'd think we were close to a spec for a graphical rebuild tool :)
[03:28] <minghua> persia: in that case, you also want to add "apt-get install build-essential" in your long line :-P
[03:29] <persia> minghua: Doesn't apt-get build-dep foo do that as well?  Hmmm....
[03:29] <minghua> I don't think so
[03:30] <minghua> persia: in any case, such a tool as we just discussed will be of limited use, as most end-users want an updated/changed source package to build anyway
[03:31] <persia> minghua: Yeah.  There's lots of reasons why such a tool is only for limited use.  Aside from updates, and system consistency, one needs to consider the support headaches of that many custom builds.
[03:31] <minghua> I was looking at www.getdeb.net and was surprised that such effort will attract so many users and developers
[03:32] <minghua> yeah, if we have such a tool, it really should change the package version number
[03:33] <persia> Copyright Canonical?  Interesting.  While www.apt-get.org seemed a reasonable response to the opacity of Debian processes (especially during the long DAM freeze), I would think that Ubuntu's processes were open enough that it wouldn't be necessary.
[03:34] <persia> (it = getdeb)
[03:35] <minghua> well, that's why I say I was surprised
[03:36] <minghua> It seems to me that site is just a pretty site that publish all REVU uploads
[03:36] <Flannel> eh?  getdeb isn't copyright canonical
[03:36] <persia> Flannel: Yes it is (in part).  See the bottom of the front page.
[03:36] <minghua> and my cynical side thinks it probably is
[03:36] <Flannel> persia: no.  Read the line again.
[03:37] <Flannel>  2007 Joo Pinto - GetDeb - www.getdeb.net
[03:37] <Flannel>  2007 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.
[03:37] <persia> Flannel: If there's no Canonical input, " 2007 Canonical Ltd. " either represents an assignment or a misattribution.
[03:38] <Hobbsee> well, the trademarks are ubuntu's i suspect
[03:38] <Flannel> persia: I believe that's a "Ubuntu and Canonical are C Canonical"
[03:38] <persia> 
[03:38] <AndyP> it's certainly ambiguous
[03:38] <Flannel> Right.  But he's not up on the legalities, apparently.
[03:38] <Flannel> http://www.whois.net/whois_new.cgi?d=getdeb&tld=net
[03:39] <minghua> maybe they took some website design?
[03:39] <persia> Flannel: Ah.  That's not quite accurate.  I suspect "Ubuntu and Canonical are trademarks of Canonical Ltd." would mean that.
[03:39] <Flannel> it's certainly not owned by C
[03:53] <gouki> getdeb.net is owned by a guy on my LoCo Team
[03:54] <persia> gouki: Ah.  You might mention the copyright attribution then.  It may not be correct (although this does not represent legal advice).
[03:54] <gouki> persia: yeah, sure thing. I'll talk to him ASAP!
[04:53] <persia> Sorry for the delay.  Any comments on https://wiki.ubuntu.com/MOTU/Meetings/2007-06-30 before I officially publish?
[05:04] <persia> It might just be a persistent client.
[05:04] <ajmitch> well there were several people that dropped offline with excess flood
[05:05] <persia> Right.  But only one seems to be continually bouncing.
[05:05] <ajmitch> yep
[05:06] <persia> So, in the absence of criticism, I'm publishing the minutes.
[05:28] <Burgundavia> can I interest any MOTU is writing up a short bit on the MOTU meeting for the UWN?
[05:30] <persia> Burgundavia: Can you give me an example of a previous writeup?
[05:30] <Burgundavia> this would be the first
[05:30] <persia> Burgundavia: OK.  What size?  What tone?  (I'm happy to draft something, but I don't know what I'd be writing).
[05:31] <Burgundavia> the key bits would be mention where you need help, what the community can do
[05:32] <persia> Burgundavia: OK.  So, for the recent meeting, a short paragraph covering decisions and a highlight of the upcoming events (as listed in Daniel's mail)?
[05:32] <Burgundavia> basically, yep
[05:39] <persia> Burgundavia: Something like http://paste.ubuntu-nl.org/27901/ ?
[05:40] <persia> (with line breaks) :)
[05:41] <Burgundavia> persia: looks good, but I would add bits about how people can help you
[05:41] <Burgundavia> remember, this is part of an outreach tool
[05:41] <persia> Hmm...  I'm not so strong with community outreach.  Anyone else?
[05:42] <Burgundavia> You could say: The MOTU team is looking for help with BLAH, BLAH AND BLAH. A great way to get involved is at the upcoming Hug Day at ....
[05:43] <persia> Burgundavia: At issue is more that I don't have good replacements for BLAH, BLAH, and BLAH, aside from bug triage and bug patches.
[05:44] <Burgundavia> what about the clamav stuff?
[05:44] <persia> Burgundavia: It certainly needs resources, but those working on it need a repository to which to upload.  Depending on how PPA works, it might not be so bad (this is under investigation).
[05:45] <Burgundavia> ok
[05:47] <persia> Burgundavia: I think the key bits are really the HUG Day and the Q&A sessions - most REVU users will be happy to have a REVU day, but more submissions to REVU doesn't necessarily help.
[05:48] <Burgundavia> cool, ok
[05:56] <minghua> REVU apparently doesn't need outreach
[05:57] <minghua> outreach only makes the queue longer, I suppose :-)
[05:58] <minghua> Burgundavia: do you think the ordinary reader of UWN knows what MOTU is?
[05:58] <Burgundavia> absolutely
[05:59] <persia> minghua: Depends on how you look at it.  The existence of getdeb makes me think REVU needs outreach, but I don't think we're currently staffed to handle increased volume.
[06:00] <minghua> persia: True.  But I am also thinking that getdeb may have its place
[06:00] <minghua> I am not very optimistic about the package qualities on getdeb
[06:01] <persia> minghua: Really?  Wouldn't backports + more REVU be a cleaner solution?  That way the packages should be better quality, and users should be happier.
[06:01] <minghua> persia: the key is _more_ REVU
[06:01] <Burgundavia> there are some things that cannot go int eh archives
[06:01] <minghua> so far I don't see a clear solution to get more reviewing power
[06:01] <Burgundavia> getdeb has some questionably legal stuff
[06:01] <minghua> s/power/manpower/
[06:02] <persia> Burgundavia: Some, but a lot of it is legal (or could be with a couple emails), but just shiny.
[06:02] <minghua> yeah, the top downloads seem most in the "released yesterday" category
[06:02] <Burgundavia> it looks like getdeb sucks a lot of people away
[06:03] <persia> minghua: The recent revised MOTU process should get more people, and I'm hoping REVU2 will provide better workflow.  I believe part of the problem with REVU is that it's hard to know what you've already done.
[06:04] <minghua> persia: maybe, I always think that REVU, or on a tangent topic, Debian, is not very good at attracting people to join and help is the high technical standard
[06:05] <minghua> persia: that of course is from my limited, and most likely not typical, experience
[06:06] <minghua> I've seem quite a few cases that people simply consider "reviewing all the license headers in source" and "run lintian/linda and fix the errors and warnings" an annoyance
[06:06] <persia> minghua: Regarding Debian, I think part of that is that the process is fairly opaque - it's really hard to know how to get involved.  Regarding REVU, I think that a better workflow with faster responses would help: most of the contributors I've seen have been happy with the comments, so long as they come with a bit of explanation.
[06:06] <minghua> s/seem/seen/
[06:07] <persia> minghua: Yep.  There's lots of that.  Perhaps a more collaborative REVU - people propose packages, and others work on them until it's good.
[06:07] <minghua> persia: as I said, perhaps different experience
[06:08] <minghua> I don't know.  I also feel the real problem is that for a certain package, the people who are really interested in it and capable of packaging is relatively few
[06:08] <minghua> input method packages are a very good example
[06:08] <minghua> which is most of my experience coming from
[06:09] <persia> minghua: Really?  With the exception of system infrastructure (like IMEs), I suspect that most packages could be intially constructed by a motivated user with a bit of knowledge, and made good with the help of someone more familiar with debian packaging.
[06:10] <minghua> take the package I reviewed today as example, it's a science related package.  It has sit in REVU for quite a while, went though a few review cycles, but still plenty of lintian warnings.
[06:10] <persia> For infrastructural things - it's rather different: there's too many things that can go wrong (like my intention to write a quick patch to make scim & anthy work for french locales :))
[06:11] <minghua> persia: Science related stuff is another example.  Maybe I am always interested in the "minority market" packages. :-)
[06:11] <persia> Were the lintian errors mentioned in previous reviews?
[06:11] <Burgundavia> most of the stuff packaged is the latest crack or games
[06:11] <minghua> no, it FTBFS in the first review
[06:11] <persia> Burgundavia: Games are good, crack needs review.
[06:12] <persia> minghua: For Science packages, is there anything special that can go wrong easily?  I would think the only domain-specific issue would be non-free data.
[06:13] <minghua> persia: oh, for science stuff, the sticky point is that many upstreams are not very competent programmers themselves
[06:13] <persia> Ah.  So there ends up being a lot of work just to get the build system working, 64-bit clean, etc.?
[06:14] <minghua> so you are more likely to see hand-made makefiles, not aware of the 64bit issue, don't know how to properly build a shared library, those kind of stuff
[06:15] <persia> Right.  Frustrating that, and not something easily addressed by MOTU (even with infinite MOTUs working on packages).
[06:15] <StevenK> ScottK: The licensecheck bug is due to Feisty, and doesn't affect Gutsy.
[06:17] <minghua> persia: Yeah.  I am just saying: I am willing to do REVU review work, and I think I am competent enough on packaging, but there is simply no package that I'm interested.
[06:17] <persia> minghua: Ah.  I've only reviewed one package so far in which I'm actually interested.  For me, it's just part of the responsibilities of being listed as a reviewer.
[06:17] <minghua> And when I find one, sometimes the packaging work is poor, and frustrates me.
[06:18] <minghua> persia: That's why I am not in motu-reviewers team. :-P
[06:18] <minghua> I have been feeling I don't really need to be an MOTU for quite some time.
[06:20] <minghua> I haven't reviewed or sponsored packages since probably mid-feisty, most of my universe packages are direct sync from Debian, and I have good relationship with many MOTUs that I can easily ask for a sponsor upload.
[07:01] <jmg> hey all
[07:01] <nixternal> way to loud in here
[07:01] <nixternal> howdy jmg 
[07:07] <jmg> whoa, source for restricted modules is massive
[09:03] <jmg> where is the debian/rules file for linux-source-2.6.22?
[09:07] <man-di_> jmg: apt-get source linux-source-2.6.22
[09:35] <ajmitch> sigh
[09:35] <ajmitch> seems like the sound problems I was having was directly due to rhythmbox
[09:44] <DarkMageZ> ajmitch, extra sound distortion?
[09:44] <ScottK> StevenK: Thanks for the debuild fix and working through the checklicense question.
[09:49] <ajmitch> DarkMageZ: yes
[09:49] <ajmitch> and it was irritating
[09:49] <jmg> ugh
[09:50] <ajmitch> I was playing around with the main volume controls, didn't think to look for the little volume icon in rb
[09:50] <jmg> wait
[09:50] <ajmitch> far too many volume controls 
[09:50] <jmg> fsck
[09:50] <highvoltage> hey ajmitch, how are you?
[09:50] <jmg> far too much work to get gutsy kernel on this box, but i really need it :/
[09:50] <persia> ajmitch: Remember, this allows you to degrade your sound as much as you want :)  If you only had one control, you'd be stuck with the maximum available bitrates.
[09:52] <ajmitch> hey highvoltage 
[09:52] <ajmitch> persia: yeah, helpful
[09:53] <ajmitch> so tempting to just order a new monitor
[09:57] <Hobbsee> hey all
[10:00] <ajmitch> Hobbsee: what's up?
[10:00] <jmg> O bug #117282, thou all destroying yet unconquering whale, from hells heart i stab at thee.
[10:00] <ubotu> Launchpad bug 117282 in linux-source-2.6.20 "2gb SD card not usable" [Undecided,New]  https://launchpad.net/bugs/117282
[10:00] <Hobbsee> ajmitch: w.r.t?
[10:00] <ajmitch> Hobbsee: life, the universe & everything
[10:01] <jmg> I cant even dd the fucking card under Feisty
[10:01] <Hobbsee> ajmitch: well,  i survived work
[10:01] <jmg> er 
[10:01] <Hobbsee> just
[10:01] <jmg> fscking
[10:01] <ajmitch> Hobbsee: yay!
[10:01] <Hobbsee> ajmitch: yeah.  le sigh
[10:01] <jmg> using ubuntu is breaking my social life
[10:01] <ajmitch> hard day at work?
[10:03] <Hobbsee> ajmitch: rosters were stuffed, as usual.  but i particularly like the fact that *2* customers were bitching, at once, on different issues, while i was serving other customers entirely.
[10:03] <ajmitch> that sounds like fun
[10:03] <Hobbsee> oh yes
[10:03] <ajmitch> I'm lucky that I rarely have to deal directly with clients
[10:03] <Hobbsee> including continuing to bitch, after they'd gotten their refunds/changes/whatever else they wanted.
[10:04] <ajmitch> a good exercise in patience
[10:04] <Hobbsee> nah, a good exercise in keeping control of 10 things at once, and not letting the bitching customers get to you, nor get their way faster.
[10:06] <ajmitch> ah, looks like gutsy-changes may be fixed to honour Changed-By again
[10:07] <Hobbsee> yay!
[10:07] <RainCT> Morning
[10:08] <Hobbsee> hiyua
[10:08] <RainCT> persia: what's on?
[10:09] <persia> RainCT: ajmitch reports improvements to gutsy-changes to give appropriate credit for patches.
[10:09] <RainCT> nice :). how will that work?
[10:10] <persia> RainCT: It will use the name and email from Changed-By: as the From: address, rather than the name & email associated with the signature.
[10:15] <ajmitch> it was only broken for a few days
[10:16] <ajmitch> and I think it was using the Maintainer address, not the signature
[10:18] <RainCT> and where will that be shown?
[10:18] <persia> ajmitch: As usual, you're completely correct.
[10:18] <persia> RainCT: https://lists.ubuntu.com/archives/gutsy-changes/
[10:18] <ajmitch> 'as usual'?
[10:18] <ajmitch> you're on crack
[10:19] <jmg> grrrrr
[10:19] <persia> At least in my experience.  Maybe you're only right when you correct my mistakes: I don't pay as much attention other times :)
[10:19] <RainCT> I mean in what package
[10:20] <jmg> wtf
[10:54] <RainCT> bdmurray: ping
[11:21] <DarkMageZ> ajmitch, probably http://bugzilla.gnome.org/show_bug.cgi?id=436192
[11:25] <ajmitch> yeah, I knew it was related to the gain stuff
[11:25] <RainCT> if in a Debian package there's a not needed file (in /, not debian/) but it anways doesn't get installed (that file), should it be deleted on the next debdiff?
[11:26] <ajmitch> RainCT: I don't think it needs to be deleted
[11:26] <ajmitch> there are plenty of files that don't get used (eg win32 build files) that you wouldn't delete
[11:28] <persia> RainCT: No.  The upstream tarball should be left alone as much as possible.
[11:28] <RainCT> ok, that's what I tought too :)
[11:28] <RainCT> thanks
[11:29] <persia> RainCT: There is a semi-exception for native packages, where the file is no longer required due to other changes, but these should ideally be handled in Debian.
[11:35] <RainCT> (can someone check my comment on bug 108742?)
[11:35] <ubotu> Launchpad bug 108742 in acidrip "no icon in kde menu" [Wishlist,In progress]  https://launchpad.net/bugs/108742
[11:42] <cbx33> I forget do I debuild -sa or -S?
[11:43] <cbx33> or which
[11:43] <cbx33> grrr
[11:43] <persia> cbx33: It is a new upstream, or just a new revision?  If the former, you want -sa.  if the latter, you don't.
[11:43] <cbx33> ok
[11:43] <cbx33> thanks
[11:48] <persia> RainCT: Looks good.  A couple notes: dh_installdirs can take multiple arguments, which is sometimes cleaner.  Ideally there should be a blank line between each rule in debian/rules.  Deletions cannot be processed by the diff.gz, so the deletion of ./1 is probably OK (this may have been an error from a previous packaging).  I'm also confused by your comment on Maintainer.
[11:49] <RainCT> persia: about dh_installdirs, the previous maintainers were putting one at each line, that's why I've said to do the same
[11:50] <persia> RainCT: Ah.  Yes.  The rule that one attempts to mirror existing packaging as much as possible overrides the rule that one should strive for a short and easy to read debian/rules.
[11:52] <RainCT> and about maintainer, in his second debdiff he changed Debian's to XSBC-O-M but did not put the Maintainer: {motu list}
[11:52] <cbx33> dh_pysupport: debian/vcsfrenzy/usr/lib/python-support/vcsfrenzy doesn't contain modules for any supported python version
[11:52] <cbx33> what the heck does that mean?
[11:52] <cbx33> I just have some simple py files in there
[11:53] <RainCT> persia: but in his first debdiff he put MOTU as Maintainer, so that's why I say that was ok
[11:53] <persia> RainCT: Right.  That just wasn't clear to me from your comment.
[11:54] <persia> (perhaps it will be clear to Paul, so no worries)
[11:54] <cbx33> anyone got a secto help out with this python marlarky?
[11:54] <RainCT> persia: what do you mean with the about the deletion of "./1"? that it won't be deleted anyways?
[11:55] <persia> RainCT: Hmm.  Let me look at the package in some detail (reviewing mentoring of patching is too far removed for real understanding).
[11:55] <cbx33> http://codebrowse.launchpad.net/~petesavage/vcs-frenzy/trunk/files/petesavage%40ubuntu.com-20070630095338-6p7c56m6x2gmlb5y
[11:55] <cbx33> gives me the above error
[11:55] <cbx33> what am I doing wrong :S
[11:59] <persia> RainCT: ./1 was in diff.gz as a new file, and appears to be cruft from the original packaging.  Removing it is safe (it's likely the result of using 2&>1 rather than 2>&1).  On the other hand, it doesn't break anything, so removing it without changelog, and without notifying the original maintainer is not the best idea (although it's perhaps worth checking to see if this is an Ubuntu-only addition, in which case deletion is best).
[12:00] <RainCT> persia: ok. thanks
[12:00] <persia> RainCT: So, to restate: removing files provided in orig.tar.gz should be avoided, unless required.  Adding files in diff.gz outside debian/ should be avoided.  Fixing the latter is OK, but if the problem exists outside Ubuntu, it's better to get the fix outside Ubuntu rather than patching.
[02:59] <jussi01> persia: !
[02:59] <jussi01> :)
[03:00] <persia> Hello jussi01
[03:33] <bdmurray> RainCT: pong
[05:50] <jhansonxi> Any Ubuntu Wine team members here or are they not part of MOTU?
[05:57] <RainCT> bdmurray: ping? :)
[05:57] <jhansonxi> pong
[05:57] <bdmurray> RainCT: I'm headed out the door. What is up?
[05:58] <jhansonxi> Are any Wine team members in this channel?
[05:58] <jhansonxi> or is Wine not part of MOTU?
[05:58] <superm1> jhansonxi, i believe the maintainer for wine is running up against the council to become part of MOTU
[05:58] <superm1> i'm not sure of the handle they use though
[05:58] <superm1> its saturday though, you might not find them in here today either way
[05:59] <RainCT> bdmurray: just wanted to know if you have you assigned bug 118655 to you for some reason?
[05:59] <ubotu> Launchpad bug 118655 in acidrip "control file for acidrip has wrong homepage for project" [Low,Triaged]  https://launchpad.net/bugs/118655
[06:00] <bdmurray> RainCT: Not particularly.
[06:01] <bdmurray> RainCT: Feel free to take it.
[06:02] <RainCT> bdmurray: ok. (I ask because there is a patch for bug 108742 in progress and I'd like to add the fix for this to it)
[06:02] <ubotu> Launchpad bug 108742 in acidrip "no icon in kde menu" [Wishlist,In progress]  https://launchpad.net/bugs/108742
[06:03] <bdmurray> RainCT: cool, that'd be great. have you seen 118992?
[06:04] <bdmurray> bug 118992
[06:04] <ubotu> Launchpad bug 118992 in acidrip "[gutsy]  acidrip crashed with SIGSEGV" [High,Confirmed]  https://launchpad.net/bugs/118992
[06:04] <bdmurray> RainCT: It broke for a while and then magically fixed itself.
[06:07] <RainCT> bdmurray: no, I've just looked at the easy ones
[06:07] <bdmurray> RainCT: heh, well it seems to be working now but I am worried about it getting broken again the author hasn't worked on it in quite a while afaict.
[06:09] <bdmurray> RainCT: anyway gotta run thanks for catching / finding that bug
[06:10] <RainCT> bdmurray: ok, good day
[06:11] <RainCT> (s/day/afternoon :p)
[06:30] <siretart> anyone able to upload to ubuntu around and can test something for me?
[06:34] <ScottK> Upload to universe ...
[06:34] <ScottK> siretart: Is that sufficient?
[06:34] <siretart> sure
[06:34] <siretart> I'm trying to upload g-wrap, but I don't get any response
[06:35] <siretart> as in ANY response
[06:35] <ScottK> OK.  Want me to try to upload it?
[06:35] <siretart> I've done other uploads in the mean time, which did get accepted
[06:35] <siretart> yes, that would be very kind
[06:35] <siretart> ScottK: http://paste.debian.net/31714
[06:36] <siretart> that's the debdiff I wanted to upload
[06:36] <ScottK> OK.  I'm just getting my brain fired up here, so it'll be a few minutes.
[06:36] <hugelmopf> is the sync request process (https://wiki.ubuntu.com/SyncRequestProcess) also applyable for packages which are completely new in debian unstable (and not in ubuntu yet), or only for ones which have a newer version then the existing one?
[06:37] <ScottK> hugelmopf: New packages too, but you need to say that in the sync request AFAIK.
[06:37] <siretart> ScottK: if you prefer the debdiff per mail, I can do that
[06:37] <hugelmopf> ScottK: ok, thanks. which package do i file the bug against?
[06:38] <ScottK> Ubuntu
[06:38] <ScottK> No package
[06:38] <ScottK> siretart: No problem.
[06:38] <siretart> thanks!
[06:38] <hugelmopf> ScottK: thanks!
[06:46] <ScottK> siretart: AFAICT you didn't do the maintainer mangling in debian/control ...
[06:47] <siretart> ScottK: ah?
[06:47] <ScottK> siretart: Should I change that?
[06:47] <siretart> ScottK: yes please
[06:47] <siretart> I still wonder if that's a reason to ignore uploads, though...
[06:48] <ScottK> siretart: Just noticed you diffed the previous Ubuntu version and not the Debian version.  Sorry.
[06:48] <siretart> ah, yes
[06:53] <ScottK> siretart: Uplaoded
[06:54] <siretart> ScottK: and accepted?
[06:54] <ScottK> siretart: I didn't get the accepted mail yet, but it said "Successfully uploaded packages."
[06:55] <siretart> ScottK: same here
[06:55] <ScottK> Ah.
[06:55] <ScottK> I guess we wait and see then.
[07:07] <siretart> StevenK: still nothing, no?
[07:07] <siretart> ScottK:  still nothing, no?
[07:07] <siretart> StevenK: never mind
[07:08] <ScottK> siretart: Still nothing.
[07:09] <siretart> gnarf. need to bug #launchpad, then..
[07:11] <ScottK> siretart: Yes.  It looks like doko uploaded a new gcc about 5 minutes after I uploaded yours and it's showing up/building.
[07:12] <siretart> :/
[07:50] <bur[n] er> can I get help on packaging a simple pygtk app into a .deb here?
[07:50] <ScottK> bur[n] er: You are in the right place.
[07:50] <ScottK> Not very many people seem to around today though.
[07:51] <bur[n] er> well bummer on that last point
[07:51] <bur[n] er> ScottK: you familiar with packaging?  is it fairly complex?
[07:51] <bur[n] er> I have this project http://code.google.com/p/gitso/
[07:51] <ScottK> Yes and sometimes.
[07:51] <jussi01> lol...
[07:51] <jussi01> sometimes...
[07:52] <bur[n] er> it consists of one .py file that could just be moved somewhere like /usr/bin and i still need to make a .desktop file
[07:52] <bur[n] er> and it needs to depend on two apps in universe
[07:52] <jussi01> bur[n] er: ScottK is one of the MOTU's, ie. MASTERS of the universe... 
[07:52] <jussi01> :)
[07:52] <ScottK> bur[n] er: The first thing I would do for your app is look into Python distutils and make a good setup.py.
[07:53] <ScottK> Once you have that, doing the Debian packaging is easy.
[07:54] <bur[n] er> so setup.py should do everything like moving stuff to /usr/bin, copy the .desktop somewhere, etc?
[07:55] <ScottK> bur[n] er: Yes.  You will also want stuff like a changelog, COPYING file, man page, and stuff.
[07:55] <bur[n] er> i have a changelog
[07:55] <ScottK> Which Ubuntu release are you running?
[07:55] <bur[n] er> uhh... gutsy right now
[07:55] <bur[n] er> but this app works on dapper on up
[07:56] <ScottK> bur[n] er: OK.
[07:57] <bur[n] er> is a man page just a text file?  wow, this seems like it has to be way more complex before I can make a .deb
[07:57] <ScottK> What I'd suggest doing is downloading the source package for pypolicyd-spf (as in apt-get source pypolicyd-spf) and have a look at that.
[07:57] <ScottK> It's slightly more complex than your package, but it has all the stuff (except the .desktop bits) that you'll need to deal with.
[07:57] <bur[n] er> or I can just tell people to download my tarball and extracy the .py to run it ;)
[07:58] <ScottK> bur[n] er: Yes, you can, but wouldn't it be better to get into the official repositories?
[07:58] <bur[n] er> at least until another day
[07:58] <bur[n] er> no it would, but I was thinking I could bang this out in 20 minutes ;)
[07:58] <bur[n] er> I'm off to a concert at Red Rocks... thanks for the help though
[07:58] <ScottK> bur[n] er: Additionally it's better to work within the packaging system (i.e. your own .deb is better than just using distutils).
[07:58] <ScottK> bur[n] er: If you had done this a few times, you probably could.  The first time will take longer.
[07:59] <bur[n] er> yeah, I'll be back sometime soon though
[07:59] <ScottK> bur[n] er: If your package will work on Dapper +, you can get it into the Gutsy repostitories and then request a backport.
[07:59] <ScottK> !REVU| bur[n] er
[07:59] <ubotu> bur[n] er: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[07:59] <bur[n] er> I'm not worried about that so much.  Even a .deb that people could double-click would be all I'm after
[07:59] <ScottK> You'll want to into that.
[08:00] <ScottK> You'll want to look into that to get into the repos.
[08:00] <bur[n] er> exaile and pidgin are successful and they're not in the repos 
[08:00] <bur[n] er> thanks again
[08:00] <ScottK> bur[n] er: Once you have a proper package made up, getting it into the repos is actually quite easy.
[08:00] <ScottK> exaile is in the repos.
[08:00] <bur[n] er> oh
[08:00] <ScottK> pigdin is in the repos for Gutsy.
[08:01] <ScottK> And pigdin is just gaim which is in the repos.
[08:01] <bur[n] er> ok, bad examples.  In any event, I'll be back!
[08:01] <ScottK> OK.
[08:02] <ScottK> bur[n] er: In fact, a new exaile was just uploaded today.  I'm waiting for it to build and then I'm going to try and round up people to check and see which bugs are fixed.  Do you use exaile?
[08:03] <ScottK> Good $TIME_OF_DAY calc.
[08:03] <jussi01> ScottK: do you know of any qt native browsers other than knoq?
[08:03] <jussi01> konq even?
[08:06] <ScottK> Nope.
[08:06] <ScottK> investigated...
[08:07] <jussi01> I just removed konq, an now I want to replace firefox with something native...
[08:09] <jussi01> I dont, its slow and annoying...
[09:07] <tsmithe> persia has me in a twist re compatibility between gpl2 and cc-sa
[09:07] <tsmithe> surely if the packaging is gpl2, and the package is cc-sa, then that is ok?
[09:07] <tsmithe> (as the packaging and package do not necessarily link together)
[09:08] <ScottK> tsmithe: Why not just make the packaging cc-sa?
[09:08] <ScottK> That way there's no confusion.
[09:08] <tsmithe> ScottK, yes, that was my idea. but in the case i cannot contact the original packager, am i allowed to adopt and change the licence?
[09:09] <ScottK> Ah.
[09:09] <tsmithe> heh
[09:09] <ScottK> No.  All you can do is license your mods to the package differently.
[09:09] <tsmithe> thought so :)
[09:09] <tsmithe> so that leaves me back with the original question
[09:10] <ScottK> Right.
[09:10] <ScottK> What happened to the original packager?
[09:11] <tsmithe> he's not been around for a while due to personal issues, and so i've (temporarily) adopted the package[s]  for ubuntustudio so that we can get a move on :)
[09:11] <tsmithe> i guess i could give it a shot and try and get his permission for a licence change
[09:12] <ScottK> Who is it?
[09:13] <tsmithe> "Janne Jokitalo (AstralJava) <janne.jokitalo@dnainternet.net>"
[09:15] <ScottK> Ah.
[09:15] <ScottK> The simplest solution would be to ask and get permission.
[09:15] <ScottK> Be sure to note that in debian/changelog.
[09:16] <tsmithe> yes
[09:16] <tsmithe> i've just sent off an email
[09:16] <tsmithe> i'm doing similarly for ubuntustudio-sounds' contents licence
[09:17] <ScottK> Sounds good.
[10:34] <jekil> i have a trouble with cdbs, any hint? http://rafb.net/p/WsTVCK82.html please
[10:45] <geser> jekil: 404 Not Found
[10:47] <jekil> geser: sorry http://rafb.net/p/Lot1i329.html
[10:53] <geser> jekil: it's a python software. See how other python packages use cdbs
[10:54] <geser> it looks like it uses python distutils for setup and cdbs has a class for it
[10:54] <ScottK> In that case it should be dead simple.
[10:54] <jekil> geser: i use it
[10:54] <jussi01> jekil: heres some useful docs if you dont have them already: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
[10:54] <ScottK> jekil: Paste your debian/rules file.
[10:55] <geser> then I wonder why it looks for configure
[10:56] <jekil> http://rafb.net/p/7NxyIj32.html my rules
[10:56] <jekil> jussi01: i know it
[10:56] <jekil> i can imagine why this search for configure
[10:56] <jekil> s/can/cant/
[10:59] <geser> does it also happen if you comment out the kde class?
[10:59] <jekil> geser: yes
[11:03] <ScottK> jekil: Not sure if if would make any difference, but you have DEB_PYTHON_SYSTEM 		:= pysupport, on my packages that work, I have DEB_PYTHON_SYSTEM=pysupport with no spaces.
[11:03] <ScottK> jekil: I'd also suggest looking at the setup.py for the program to make sure it's not doing something odd.
[11:04] <jekil> ScottK: thanks. now i check
[11:21] <jekil> ScottK: same error :( setup.py is clean
[11:22] <jekil> i think the error is raised from cdbs
[11:23] <RainCT> a little off-topic question if you allow me. if I'm doing a Python application, and want to provide a script to install, uninstall and purge, what is better? create a custom script or can/should that be done with a makefile?
[11:40] <Kmos> RainCT: makefile i think
[11:41] <Kmos> do the autoclean stuff
[11:41] <Kmos> :)