[00:26] <persia> superm1, Just as a reminder, if you're expecting artwork-changing patches, you may find newer debian source formats useful (as you can represent binaries in debian.tar.gz)
[00:27] <superm1> persia, i'm actually tempted to just make it a native package
[00:27] <persia> I've not looked at the package, but if there's insignificant real upstream code (>85% fork), that doesn't seem that bad to me (especially given the package name).
[00:28] <superm1> it's written specifically for mythbuntu, so we're upstream
[00:28] <persia> I don't like native packages for N reasons, but for things where it's already essentially distro-specific...
[00:29] <persia> Yeah.  Note that I'm less happy about themes being native (which is, I believe, the discussion that led you guys to using all non-native packaging (hurrah)) because they can easily be used portably.
[00:29] <superm1> it provides the hooks for the installer, slideshow, casper hooks and stuff like that - i really dont see it being used by another group in it's current form
[00:29] <persia> Potentially dertivatives, but they don't matter in terms of the native/non-native debate.
[00:30] <superm1> right
[02:42] <nenolod> so like
[02:42] <nenolod> what is the deal
[02:43] <persia> with?
[02:43] <nenolod> why do you people find the need to make unsupportable edits to audacious{-plugins}
[02:43] <nenolod> now 2 clause BSD code is now "DFSG incompliant"
[02:43] <nenolod> please rename it if you are going to do this stuff
[02:43] <persia> I don't think there's a blanket reason, and I suspect most of us aren't likely to do that.
[02:44] <nenolod> this happens with every ubuntu dev cycle
[02:44] <persia> I can believe that.  I'm just less sure it's everyone.
[02:44] <nenolod> it's bdrung specifically
[02:45] <persia> bdrung_, Any comments?
[02:45] <nenolod> he needs to just rename it
[02:45] <nenolod> i'm trying to be as nice as i can, but i am pretty much fed up with this at this point
[02:45] <persia> Or work directly with you guys, rather than distro-patching
[02:46] <nenolod> also he seems to not understand the nature of the DFSG
[02:47] <nenolod> asking for a --disable-foo option to disable the allegedly DFSG-incompliant building does not make the package DFSG compliant
[02:47] <persia> I'm not currently having luck finding the change you're talking about from a quick glance at changelogs: would you mind referencing it more explicitly?
[02:47] <nenolod> right now he is shipping vanilla source
[02:47] <nenolod> and then removing the plugin
[02:47] <nenolod> with a patch
[02:47] <nenolod> thus the DFSG incompliant source is being shipped twice
[02:47] <persia> That doesn't achieve DFSG-freeness
[02:47] <nenolod> yes
[02:47] <nenolod> it does not.
[02:47] <persia> which package?
[02:47] <nenolod> audacious-plugins
[02:49] <nenolod> i guess i will have to add an option to disable audacious's branding
[02:49] <nenolod> and then force ubuntu to use it
[02:49] <nenolod> if this is how things will go
[02:49] <persia> Why?
[02:49] <persia> Please don't mistake the actions of one individual for the position of all developers of a distribution.
[02:50] <persia> You were actively working on Ubuntu long enough to know how we do things.  This isn't some "Ubuntu hates nenolod" thing.
[02:53] <wgrant> If the license clauses in the Debian bug are indeed real, it is clearly non-free.
[02:53] <wgrant> But the removal method was insufficient, this is true.
[02:53] <nenolod> the code in question is under 2 clause BSD.
[02:53] <persia> Is src/psf the right place to be looking?  That seems to be largely GPL
[02:53] <wgrant> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594519
[02:54] <nenolod> wgrant: i'm aware
[02:54] <nenolod> wgrant: he is an idiot
[02:54] <persia> wgrant, Thanks for the reference
[02:54] <wgrant> nenolod: Feel free to file a bug, and please obey the CoC.
[02:54] <wgrant> Perhaps the relevance of that license was misunderstood.
[02:54] <persia> nenolod, we like to try to avoid statements that insult specific folk: please instead insult specific ideas.
[02:54] <wgrant> In which case it needs to be clarified, which does not require personal attacks.
[02:55] <nenolod> the code in question comes from highly experimental, which was released into BSD license.
[02:55] <persia> It does seem that src/psf/* is also removed from the source.
[02:55] <nenolod> period.
[02:56] <wgrant> nenolod: Have you told anyone?
[02:56] <nenolod> i'm just going to add technical measures to remove the audacious branding
[02:56] <nenolod> it is easier
[02:56] <persia> Why not sort the license confusion?
[02:56] <nenolod> because this issue is just one of many and many that will happen in the future
[02:56] <persia> If it's not MAME-licensed, then it's not.
[02:56] <nenolod> and i've had enough
[02:56] <wgrant> src/psf indeed does not appear in the orig tarball.
[02:57] <nenolod> regardless, the mame license in this case is ERADICATED by the GPL code ANYWAY
[02:57] <persia> Be nice if there was a README.source or mention in debian/copyright or debian/rules:get-orig-source indicating that.
[02:57] <persia> nenolod, How is it eradicated?
[02:58] <nenolod> regardless, the license was clarified from day one: "It's under the BSD license, mostly, but it uses code from PeOPS, so it's probably GPL."
[02:58] <wgrant> That doesn't sound too clear to me.
[02:58]  * wgrant checks the original source.
[02:58] <nenolod> anyway
[02:58] <nenolod> remove it
[02:58] <nenolod> please for the love of god
[02:59] <nenolod> just remove audacious
[02:59] <persia> Why?
[02:59] <nenolod> because you people make edits to it which are unsupportable
[02:59] <nenolod> so call it something else
[02:59] <nenolod> or remove it
[02:59] <persia> Again, please complain about specific folks.  I don't believe I've ever made such an edit, and I have worked with you for many years to help make audacious *more* supportable.
[03:00] <wgrant> I fail to see how removing a plugin of dubious legality makes it unsupportable.
[03:00] <nenolod> well, please stop bdrung then.
[03:00] <nenolod> wgrant: the audacious developers will not support modified source distributions, period.
[03:00] <wgrant> What does "support" mean?
[03:01] <nenolod> it means, among other things: /kickban $ubuntu-user
[03:01] <wgrant> The latest changelog entry also suggests that it's now an upstream patch that is used to disable the plugin.
[03:01] <nenolod> and advisement to build it from source.
[03:01] <persia> Historically, lots of folks bug #audacious when they have issues with audacious on Ubuntu, and almost always for issues that are fixed upstream.
[03:03] <persia> OK.  I think I understand.  Indeed, the entire psf plugin *MUST* be licensed GPL.
[03:04] <persia> That said, the MAME code needs to be investigated to ensure it was received under a GPL license, and the headers probably need adjustment.
[03:05] <nenolod> protip: it was
[03:06] <nenolod> http://hg.atheme.org/release/audacious-plugins-2.4.x/release/audacious-plugins-2.4.x/rev/6a8df459ccce
[03:06] <nenolod> there is your legal clarification
[03:10] <persia> nenolod, Sure, but do you know how the MAME code was put into it in the first place?
[03:11] <persia> It's clearly GPL now, so there's at least a text-bug in the headers.
[03:11] <wgrant> src/psf/license.txt also says that the files are still MAME.
[03:11] <persia> I believe the fear is that it was inappropriately relicensed.
[03:11] <persia> wgrant, Indeed, but that must be wrong, because of GPL.
[03:11] <wgrant> persia: Where does it say that they are GPL?
[03:12] <persia> wgrant, In the various places nenolod referenced.  Also, they must be GPL to be linked and distributed with GPL.
[03:12] <wgrant> persia: They must be, yes. But that doesn't mean that they are :(
[03:12] <persia> Yes it does.
[03:12] <persia> They are currently GPL.
[03:13] <persia> That doesn't mean that someone didn't violate MAME at some point to make them GPL.
[03:13] <wgrant> True.
[03:13] <nenolod> permission was obtained years ago to use them under normal BSD license as part of highly experimental (which is now dead and was *closed source*)
[03:14] <persia> nenolod, I believe you.  I'm just trying to find a documentation trail that can close 594519
[03:15] <nenolod> there is none.
[03:15] <persia> Ugh!
[03:15] <nenolod> i can ask neill corlett, but that is probably not going to be productive
[03:15] <persia> There's no commit message in a VCS saying they are BSD, or email somewhere, or old repo in the internet archive, or anything?
[03:15] <nenolod> let me put it this way: the MAME people have not complained
[03:15] <nenolod> they are aware of this
[03:15] <nenolod> they have not complained
[03:15] <nenolod> they do not care
[03:15] <persia> That doesn't help my clients if I take a contract to ship Ubuntu on their device, and they want license guarantees, unfortunately.
[03:16] <nenolod> then put audacious unmodified in multiverse and stop bastardizing it
[03:16] <persia> I happen to like audacious, and want to be able to recommend it for such things.
[03:16] <nenolod> or remove the branding
[03:16] <persia> Can7t we just fix it?
[03:16] <nenolod> fixing it requires taking our word for it.  you do not trust us.
[03:16] <nenolod> so please:
[03:16] <nenolod> - remove audacious
[03:16] <nenolod> - change branding
[03:16] <nenolod> - put it in multiverse
[03:16] <nenolod> one of the 3
[03:17] <persia> multiverse won't help if the code is really MAME: that would be a GPL violation, and require removal.
[03:17] <wgrant> Licensing is not a "they do not care" matter.
[03:17] <persia> I don't want to remove it, because I like it.
[03:18] <persia> Changing branding is kinda pointless when we're just talking about some comments in a few source files.
[03:18] <persia> I do trust you about it, but I need something I can show a lawyer, and I know they aren't allowed to just trust folk.
[03:18] <nenolod> there are no comments in the source files
[03:18] <nenolod> saying they are MAME
[03:18] <nenolod> zero
[03:18] <persia> Oh, this might be easier then.
[03:19]  * persia looks harder
[03:19] <nenolod> thusly, they are not declared as MAME.
[03:19] <nenolod> in two of the files
[03:19] <nenolod> there is a BSD license!
[03:20] <persia> Would you mind commiting a change to src/psf/license.txt removing references to MAME licensing?
[03:20] <nenolod> i removed that file
[03:20] <nenolod> it's old
[03:20] <persia> Excellent!
[03:20] <nenolod> psx_hw.c is not even shipped in MAME...
[03:21] <persia> MAME-licensed doesn't necessarily mean code in the MAME project.
[03:21] <nenolod> neither is psx.c
[03:21] <nenolod> yeah i know
[03:21] <nenolod> psx.c is based on MESS, and was *gasp* written by the same guy who made highly experimental
[03:22] <persia> And highly experimental was BSD?
[03:23] <nenolod> highly experimental was proprietary
[03:24] <nenolod> parts of the code was released to us under BSD for use in the plugin
[03:24] <persia> Do you happen to have a copy of that release with the license announcement somewhere?
[03:27] <nenolod> seeing as we have shipped it for years now
[03:27] <nenolod> probably not
[03:28]  * persia wishes licensing were easy
[03:29]  * nenolod wishes that people would stop ruining audacious
[03:31] <persia> Seems to be commit 62cc6d667119 that brought in some of the code.
[03:34] <nenolod> yeah and?
[03:34] <persia> nenolod, Hrm.  Annoyingly, it seems that the (now removed) psf/license.txt was added in the same commit that brought in many of the files in question, and claimed them as MAME at the time.
[03:34] <nenolod> yeah whatever
[03:34] <nenolod> please remove official branding
[03:36] <persia> I'm highly motivated to fix the license problem.  I'm even motivated to try to reduce your perception that Ubuntu is causing you issues rather than an individual.  I'm not motivated to generate a large no-branding patch when there is a simpler licensing adjustment solution available.
[03:37] <nenolod> what solution do you want?
[03:37] <nenolod> you've already shipped this code for years.
[03:37] <persia> I'm hoping to find some way to address the license issue.
[03:37] <nenolod> has canonical gotten sued?
[03:38]  * persia doesn't really care about specific counterparties
[03:38] <nenolod> has any ubuntu user gotten sued?
[03:38] <persia> And I don't know if anyone has been sued or not: that would be invisible to me.
[03:39] <nenolod> PSF playback is a major reason why Ubuntu users use Audacious.
[03:39] <nenolod> removing the plugin will make it appear as if it were a decision made by us.
[03:39] <nenolod> this causes harm to us.
[03:39] <persia> OK.  I'm feeling good.  324f950774cb has no PSF plugin.  62cc6d667119 adds it, the license.txt file, and GPL code linked against it.
[03:40] <nenolod> i would just make audacious pop up a giant box saying Ubuntu has edited it and to leave us alone.
[03:40] <nenolod> wrong.  324f950774cb does have a PSF plugin.
[03:40] <nenolod> sexypsf.
[03:40] <persia> Aha!  Thanks.
[03:40] <nenolod> which is the same code basically
[03:40] <nenolod> and that code is GPL!
[03:40] <nenolod> anyway
[03:41] <nenolod> i would just make audacious pop up a giant box saying Ubuntu has edited it and to leave us alone, but you guys would just patch it out.
[03:41] <nenolod> so that seems futile.
[03:42] <persia> Indeed.  Better to try to sort it.  My goal here is to find something to make 594519 go away, which is a Debian bug, so not even specific to Ubuntu.
[03:43] <nenolod> anyway, SexyPSF is illegal
[03:43] <nenolod> because
[03:43] <persia> The sexypsf code looks very similar, and even has a GPL psx HW C file (although a slightly different implementation).  But it has none of the files claimed as MAME-licensed.
[03:43] <persia> because?
[03:43] <nenolod> PCSX/SexyPSF are based on FPSE.
[03:44] <persia> And FPSE is?
[03:44] <nenolod> FPSE is an Amiga emulator which was released under a MAME-like license.
[03:44] <persia> Ah, right.  Yes.
[03:44] <nenolod> MESS's emulation code is also based on FPSE.
[03:44] <persia> Is that why there is the claim that psx.c might be MAME-licensed?
[03:45] <persia> Or did smf write it on top of MESS from scratch, rather than as part of MESS (in highly experimental)?
[03:46] <nenolod> smf?
[03:46] <persia> smf is the claimed author of psx.c according to the header comment in the file.
[03:46] <nenolod> smf rewrote psx.c for MESS to remove the FPSE code
[03:47] <persia> That explains some of the comments.
[03:47] <nenolod> which comments in particular?
[03:48] <nenolod> Farfetch'd was the author of FPSE, fwiw
[03:49] <persia> Just some of the inline ones that explain why a choice was made in more detail than I often see (which is more common when one is white-box-rewriting, and someone is translating code -> human language -> code)
[03:51] <nenolod> so really, it's just psx.c that is questionable, and since there is no copyright declared on it for anyone...
[03:51] <nenolod> "smf" could be anyone
[03:51] <persia> So, I think we have two ways to address this: 1) dig through the myriad history of all the individual bits of code, 2) accept the word of the committer of 62cc6d667119 that license.txt was a mistake in the first place, and ensure that is documented in a way to close 549519.
[03:51] <nenolod> so it would be thrown out of a court.
[03:51] <persia> Yeah, that's the issue I'm encountering trying to deal with method 1)
[03:52] <persia> Would you be up for being counterparty in case option 2 was ever questioned?
[03:52] <nenolod> psx.c was never shipped in MESS or MAME too
[03:52] <nenolod> sure
[03:52] <nenolod> license.txt refers to a lot of files not even shipped in audacious anyway
[03:53] <persia> Excellent.  let me see if I can find some good boilerplate for GPL-conversion as a suggested patch into src/psf/README that lets us do that.  If there is someone who warrants it as GPL, we ought be OK to close the bug in Debian, and thus get the plugin back in Ubuntu.
[03:53] <nenolod> i don't want to warrant that code as GPL, just 2-clause BSD.
[03:53] <nenolod> the binary is GPL, that code itself is not.
[03:53] <persia> nenolod, And thanks a lot for helping me understand the license mess, although I know you'd rather we could just ship stuff.
[03:54] <persia> Ah, OK.  I may have to create a two-clause BSD warrant text (I've only seen GPL warrants), but I ought be able to get something acceptable (although there's no way I can get review-by-counsel on that soon)
[03:55]  * persia starts hunting, hoping to find pre-reviewed text
[03:56] <nenolod> i will just rewrite psx.c
[03:56] <nenolod> again!
[04:00] <nenolod> persia: fine warrant it as GPL
[04:00] <nenolod> persia: nobody involved in the writing of that code cares
[04:16] <nenolod> hmm.  the psx.c in highly experimental is different
[04:17] <nenolod> and has BSD license text
[04:17] <nenolod> i'll just replace it and hammer it in
[04:17] <persia> Oh, cool.
[04:18] <persia> I'm just filling in file names for the warrant now, but anything you can make not need the warrant reduces the chance of anyone ever exercising it.
[04:23] <persia> The following is not legal advice: I believe that the placement of http://paste.ubuntu.com/500733/ in src/psf/ somewhere is sufficient to cause 62cc6d667119 to demonstrate appropriate licensing, and highly suspect that any later additions or changes to that tree are encoded in the VCS in such a way that further questions can be resolved fairly simply.
[04:34] <nenolod> http://hg.atheme.org/audacious-plugins/audacious-plugins/rev/39017467ba7c
[04:37] <persia> Sorry to get your email wrong.
[04:37] <persia> And it's not about making Ubuntu happy: it's about fixing the Debian bug.  Really, it's not all us.
[04:39] <persia> (and the next two commits are very nice indeed)
[04:46] <nenolod> osd_cpu.h is trivial
[04:46] <nenolod> there's nothing there that can be copyrighted
[04:46] <nenolod> it's just a data structure and some bitshift macros
[04:47] <persia> I just copied the names of the files added in the commit that didn't have clear license identification in the 2-year old commit.
[04:48] <persia> If you don't think it's copyrightable, or don't want to extend a warrant, change it.
[04:48] <persia> I believe that by removing the file quoted in the Debian bug, and doing some of the code cleanup you've been doing, the Debian bug should go away.
[04:49] <persia> And then we should inherit the right code to ship something you want.
[04:54] <nenolod> i think now we can just put public domain notice on psx.[ch]
[04:54] <nenolod> now that the mame framework is *gone*
[04:55] <nenolod> because, effectively without any identifiable copyright holders it is public domain
[04:56] <persia> Unfortunately not.  And in several jurisdictions, there is no public domain.
[04:56] <persia> Safer to claim BSD for it, with untraceable rightsholders.
[04:57] <persia> That said, if you do strip it, and declare it public domain, you're no more or less likely to be sued.
[04:57] <persia> The important bit is really that you're claiming something that is DFSG-compatible, so Debian can feel comfortable, so we don't have to carry a huge diff from Debian to ship your unmodified tarball.
[04:58] <nenolod> hmm
[05:00]  * nenolod puts it under 2 clause BSD license then
[05:00]  * nenolod kills license.txt as it's no longer needed.
[05:01] <nenolod> persia: http://hg.atheme.org/audacious-plugins/audacious-plugins/file/f840da0958a1/src/psf/psx.c seems acceptable
[05:02] <persia> I'd probably replace "code that is contested will be rewritten" with "distributors are amenable to any compatible solution, from relicensing to removal of the code (in which case it will be implemented differently)."
[05:03] <persia> Just in case you get someone from some jurisdiction that must file a motion to resolve anything, but wants an amicable resolution.
[05:03] <persia> I don't see anything obviously wrong with that, but I can't speak for Debian legal, so I can't be sure they would accept it.
[05:04] <nenolod> i don't care
[05:04] <nenolod> i will just add --disable-official-branding
[05:05] <nenolod> then debian can ship audweasel or some nonsense
[05:05] <persia> Let's try with what you have first.
[05:06] <persia> Just reply to 549519 with a notice that you've resolved the licensing issues upstream, and you'd much prefer that the plugin be shipped.
[05:06] <nenolod> i don't care about debian
[05:07] <nenolod> i used to, but then they pulled a tech-ctte
[05:07] <persia> What happened?
[05:07] <nenolod> i stopped paying attention
[05:07] <persia> I suppose we could try to fix Ubuntu-only, but it's a lot more work that way.
[05:08] <nenolod> basically somebody who doesn't know how to write assembler brought lilo back from the grave and demanded debian keep shipping it
[05:08] <nenolod> politics won over QA sanity.
[05:09] <persia> My philosophy with things like that is "You can maintain that, if you want.  I'll keep telling folks not to use it."
[05:09] <nenolod> except that the person in question was not capable of maintaining it
[05:09] <nenolod> his idea of maintenance was applying more broken patches from fedora (which *gasp* dropped lilo a long time ago)
[05:09] <persia> So?  If I don't use it, and nobody I care about uses it, I don't have to care.
[05:09] <persia> We still have lilo in Ubuntu.  No idea if anyone uses it.
[05:10] <nenolod> yeah i basically just said "fuck it" and walked away from that discussion
[05:10] <persia> Ah, seems we still have *your* lilo in Ubuntu, and not this new one you're talking about.
[05:10] <nenolod> the tech-ctte may do whatever it pleases
[05:10] <persia> !ohmy
[05:11] <nenolod> my understanding is that they aren't accepting lilo uploads from *anyone* right now
[05:11] <nenolod> except for NMUs
[05:11] <nenolod> but hey i switched to extlinux
[05:11] <persia> Yeah.  Anyway, back to the current issue, which is soluable.  Would you file a bug against Ubuntu asking for PSF to be enabled as licensing has been resolved upstream, which I can use to leverage the Debian bug?
[05:20] <nenolod> i am just closing that debian bug
[05:20] <nenolod> if that guy reopens it
[05:20] <nenolod> well
[05:20] <nenolod> he does so at his own risk
[05:32] <persia> nenolod, Thanks for chasing the Debian bug directly.
[05:32] <nenolod> if bdrung uploads something removing it...
[05:32] <nenolod> i will be doing more yelling and screaming.
[05:32] <persia> The opposite is preferred :)
[05:33] <persia> bdrung_, Would you mind pulling the (fixed) audacious-plugins upstream source, and restoring PSF?
[05:35] <nenolod> 2.4.1 will be published later.
[05:39] <persia> That makes it even easier
[05:54] <nenolod> cool.  found the troll on OFTC.
[06:54] <micahg> does a package synopsis need a UIF exception?
[06:57] <persia> What is a "package synopsis"?
[06:57] <micahg> persia: short description
[06:57] <micahg> shows in Software Center
[06:59] <persia> I thought Software Center showed the long description.  Anyway, I'd strongly recommend checking with the translation and documentation teams, just in case.  If they don't care about the package, then it's probably fine.  if they do, you will save them loads of pain by coordination.
[06:59] <persia> Probably worth a bug to track the desired change, and collect opinions, etc.
[06:59] <persia> Difference between that and a formal UIFe isn't much, really.
[06:59] <micahg> persia: this started with a bug and since I"m doing an upload I thought I'd fix it
[06:59] <micahg> bug 636014
[07:00] <persia> still, string changes, and *especially* string changes that end up on images or in default documentation (You don't happen to maintain anythign installed by default, right? :)) should be confirmed with folk who may have to do rework to adjust to the changes.
[07:01] <micahg> persia: heh, I know about those (this is a universe package w/out a Task)
[07:02] <persia> They'll likely say "Go ahead" then :)
[07:02] <micahg> persia: is there a channel or list?/
[07:03] <persia> Packages without tasks aren't really procedurally different than packages without tasks, except most folk don't really care because they aren't well tested, well documented, etc.
[07:03] <persia> Both, for both.
[07:04] <persia> #ubuntu-docs, ubuntu-docs@, #ubuntu-translators, ubuntu-translators@ (from memory: please verify, lists.ubuntu.com/archive/list and /cs info #channel are your tools) (/list and lists.ubuntu.com/ are both incomplete, for complex technical reasons)
[10:25] <ari-tczew> bdrung_: ping
[12:07] <onkarshinde> Is there anyone who deals with xvidcore on regular basis?
[12:09] <ari-tczew> bdrung_: could you give the lintian command which you use for REVU?
[12:11] <persia> ari-tczew, I strongly recommend `lintian -iIEv --pedantic *.changes`: not everyone uses it, and not every result from that is necessarily applicable to a given package, but it all merits thought.
[12:12] <ari-tczew> persia: look @ http://revu.ubuntuwire.com/details.py?upid=8645 -> 2nd bdrung's comment
[12:13] <ari-tczew> your command didn't gave his results :(
[12:14] <persia> You ran my command on both source and binary .changes files?
[12:15] <persia> The latest comment looks like output from a binary .changes file.
[12:34] <ari-tczew> persia: how from binary .changes file?
[12:35] <persia> One uses sbuild or pbuilder to generate binary .changes, and one runs lintian against it.
[12:36] <ari-tczew> persia: I use pbuilder
[12:36] <persia> OK.  Use pbuilder.  Generate a binary .changes file (if this isn't obvious, ask someone else who uses pbuilder how to do it)
[12:41] <ari-tczew> persia: I'll leave a message to bdrung_ how he doing a lintian check.
[12:42] <persia> ari-tczew, How do you do lintian checks?
[12:42] <persia> Really, the specific way someone else does them isn't so important.  The important thing is that you do them well.
[12:42] <tumbleweed> doesn't pbuilder create binary .changes by default?
[12:42]  * persia thought so
[12:45] <ari-tczew> persia: in directory where I have a source package: lintian -iIEv --pedantic changes_file <- it's example
[12:45] <ari-tczew> tumbleweed: do you mean ~/pbuilder/ directory?
[12:45] <tumbleweed> do I need to request release team permission to downgrade a library (with a single rdepend which isn't building because the library is too new)?
[12:45] <persia> OK.  Now try that on the place where you have the binary package.
[12:46] <tumbleweed> ari-tczew: I don't use pbuilder-dist
[12:46] <ari-tczew> I use pbuilder-dist
[12:46] <tumbleweed> ari-tczew: you don't need to be in that directory, you just need to point it at the .changes file
[12:46] <persia> tumbleweed, If the library or an rdepend shows up on any of the images, it's best practice.
[12:46] <tumbleweed> persia: it's iulib, the dependancy is ocropus - won't show up on any ISOs
[12:47] <tumbleweed> s/dependancy/rdepend/
[12:47] <persia> tumbleweed, In cases like that, I usually just upload it.  Take care to be very clear in your changelog entry: the release team has to manually approve each upload, and if they haven't given prior approval, they will want not to have to have deep thoughts.  Mind you, don't go overboard: changelog entries need to be interesting to endusers.
[12:48] <tumbleweed> :)
[12:50] <ari-tczew> persia, tumbleweed: http://paste.ubuntu.com/500903/
[12:51] <tumbleweed> ari-tczew: binary .changes = _amd64.changes / _i386.changes
[12:51] <persia> ari-tczew, What architecture do you use?
[12:51] <persia> (_powerpc.changes, _armel.changes work too )
[12:51] <tumbleweed> persia: I doubt he uses PPC / armel :P
[12:51] <persia> Why?  Lots of folk use PPC, and some use armel.
[12:52] <sebner> persia: how do you define lots? Especially compared to 386 and amd64 :P
[12:52]  * sebner waves at persia btw =)
[12:52] <persia> sebner, I know of several members of the development community who only use powerpc, and there are thousands of folks not part of the development community who do so.
[12:53] <persia> That said, I don't know of anyone who *only* uses armel: most folk seem to also have something else.
[12:53] <persia> This may change as the number of armel desktops and laptops increases.
[12:53] <tumbleweed> persia: probably getting rarer though. Not much consumer PPC hardware these days
[12:54] <ari-tczew> persia: i386
[12:54] <persia> tumbleweed, "not much"?  I can't find *any* except the IBM workstations (and I'm not sure those are really "consumer").  Most of the powerpc stuff I used to see has been replaced by MIPS.
[12:54] <tumbleweed> persia: :) I thoght there ware still a fair amount of embedded stuff
[12:54] <persia> ari-tczew, OK.  You want to run `lintian -iIEv --pedantic clementine_0.5.1-0ubuntu1_i386.changes`  pbuilder should give you this .changes file.
[12:55] <ari-tczew> persia: yea, that's work! thanks!
[12:55] <persia> tumbleweed, Mostly high-end "embedded" from what I can tell.  Stuff like routers, switches, telephony interchanges, etc.  Also lots of automotive/industrial control systems.
[12:55] <ari-tczew> btw. why this command won't show warnings on source .changes file?
[12:56] <persia> Because there are diffferent issues with source packages and binary packages.
[12:56] <tumbleweed> ari-tczew: look at the files listed in the .changes file. The source.changes only lists the source package. The binary .changes can list source or not (depending on how it was generated)
[12:56] <persia> There's no way lintian can know in advance what happens when you build a binary.
[12:58] <ari-tczew> anyway, thanks for help. now I can fix lintian alone. thanks again tumbleweed and persia
[12:59] <persia> ari-tczew, Remember, the goal is to strive for perfect packaging, not to make lintian happy.  You can make a package that meets every lintian guideline and is broken.  You can also make a package that disagrees with lintian in several ways that is perfect.
[12:59] <tumbleweed> (in the latter case, putting in some lintian overrides is probably sensible)
[13:00] <persia> Depends on the issue, but probably :)
[13:00] <persia> That said, adding lintian overrides is usually the wrong way to resolve lintian issues.
[13:04] <ari-tczew> conclusion, lintian sometimes is our enemy, like trojan horse :)
[13:04] <tumbleweed> normally not, though
[13:06] <persia> lintian is a set of test cases.  Sometimes one needs to fix the code to comply with the test.  Sometimes one finds the test doesn't actually test what one thinks it tests.
[13:07] <tumbleweed> and sometimes the test is to catch people doing something unusual by mistake, but you aren't doing it by mistake
[13:07] <persia> Especially with -E and --pedantic :)
[13:37] <shadeslayer> hi, id like to move a package from multiverse to universe
[13:37] <shadeslayer> would it be possible?
[13:39] <shadeslayer> the package is kplayer
[13:39] <persia> shadeslayer, Yep.  Just fix the license :)
[13:40]  * persia looks
[13:40] <shadeslayer> persia: its in debian main, and the license is GPL 3
[13:40] <persia> 1:0.7-0.5ubuntu1 is current?
[13:40] <shadeslayer> yes, ive just uploaded 1:0.7-2ubuntu1+ppa1 to my ppa
[13:41] <shadeslayer> persia: https://edge.launchpad.net/~rohangarg/+archive/kde-extra
[13:41] <persia> Did debian/copyright get populated?
[13:41] <shadeslayer> yes
[13:41] <shadeslayer> persia: http://paste.ubuntu.com/500928/
[13:42] <bilalakhtar> hmm
[13:42] <bilalakhtar> persia: does such a change require the intervention of an AA or a MOTU can do it?
[13:42] <persia> shadeslayer, Looks clean to me.  File a bug asking for it to be in universe.  Confirm with the release team.
[13:43] <persia> bilalakhtar, It requires an archive-admin to do it, but they will likely do so on request from any member of ubuntu-dev who can upload the package in question.
[13:43] <shadeslayer> persia: ScottK asked me to fix it, i fixed it, since hes not here, i thought maybe someone here can do it
[13:44] <persia> shadeslayer, I'm hoping that can be you :)
[13:44] <shadeslayer> persia: i mean.. someone who can upload to universe :P
[13:44] <shadeslayer> i didnt know it needed a AA to move it tho
[13:44] <persia> Right.
[13:44] <ari-tczew> what is AA?
[13:44] <persia> So there's two things needing doing: the updated merge and the AA bug.
[13:45] <persia> ari-tczew, archive-admin
[13:45] <persia> shadeslayer, Please file a bug requesting the component change, and one of us can ACK it.
[13:45] <shadeslayer> ok
[13:48] <shadeslayer> persia: ^^ :P
[13:49] <shadeslayer> also bug 648103
[13:49] <persia> There's a fair bundle of differences between 0.7-0.5ubuntu1 and 0.7-2ubuntu1 :(
[13:50] <shadeslayer> persia: all packaging changes really
[13:50] <shadeslayer> none of them new features
[13:50] <persia> heh, all changes are packaging changes in that sense.  You've at least 5 source patches being changed.
[13:51] <shadeslayer> persia: well kubuntu_01_fixdocbook fixes a FTBFS
[13:51] <persia> And there's a fix for Debian bug #565123 in there as well.
[13:51] <shadeslayer> yus
[13:51] <persia> Would you be comfortable with 0.7-2ubuntu1+ppa1 going in as 0.7-2ubuntu1?
[13:52] <shadeslayer> persia: of course
[13:52] <persia> Also, in future, you might want to use something like -2ubuntu0+ppa1 so that folks will be upgraded to -2ubuntu1 when it is released.
[13:52] <persia> shadeslayer, Are you comfortable with me mangling the changelog to sponsor it?
[13:52] <shadeslayer> i had to add +ppa1 because for 0.7-2ubuntu1 i made a mistake in the changelog
[13:52] <shadeslayer> persia: sure
[13:53] <shadeslayer> persia: should i file a bug against the merge? or is not required?
[13:53] <persia> |If you're working in a PPA, use of +ppa is a *good* thing.  I just always recommend folks use ...ubuntu0+ppa... when preparing a merge, so that the main archive version overrides it.
[13:54] <persia> shadeslayer, The bug would only be to request me to upload it: in this case, it makes it harder for me.
[13:54] <persia> Mind you, I usually recommend the sponsor queue, but I have the source here anyway because I was investigating the licensing.
[13:54] <shadeslayer> alright :D
[13:55] <shadeslayer> anyways  i use those PPA's for testing...
[13:56] <persia> I figured,  I strongly recommend you start with ...ubuntu0+ppa... if you're expecting users to use your packages and for them to end up in Ubuntu.
[13:56] <persia> Right now, anyone who has your PPA package installed won't be switched to the one I upload, which may confuse things if they are using pinning.
[13:57] <shadeslayer> right ...
[13:58] <shadeslayer> ill keep that in mind from next time :)
[14:00] <persia> That's when it might be useful :)  Nothing you can do with this one anymore.
[14:00] <bdrung_> nenolod, persia: i am back. i am read the log now.
[14:01] <persia> bdrung_, quick summary: nenolod investigated the offending MAME-licensed files, and has found that they aren't used (and removed them), or has other licensing.  We can restore PSF with a new upstream (which will be released RSN)
[14:01] <persia> s/has/have/
[14:48]  * persia dislikes epochs even more than usual
[14:51] <persia> shadeslayer, Just as a historical note: I believe kplayer was originally in multiverse because it was sync'd from Christian Marillat's repo.
[14:52] <shadeslayer> persia: from debian-multimedia you mean?
[14:52] <persia> Yeah :)
[14:52] <shadeslayer> ah ok :D
[14:53] <persia> Back in the Hardy development cycle, we synced from just about everywhere we could imagine, just to get the latest stuff.  Turned out, we couldn't actually maintain things like that.
[14:53] <bdrung_> nenolod, persia, wgrant: the usf plugin is removed since audacious 2.3-1 (due to  src/usf/x86_fpu.c) and psf is removed since 2.4.0-0ubuntu1. I had to repack the source to not include those two plugins. I removed the usf plugin because of Debian bug #594519. Some of the questions files didn't had a license header and src/psf/license.txt claimed that they were MAME license (which is not DFSG compliant). Thanks to persia for sorting this issue wi
[14:53] <bdrung_> th nenolod.
[14:53] <shadeslayer> yeah happens when you want loads of new stuff :P
[14:59] <bilalakhtar> ubottu supports debian bugs?
[14:59] <persia> bilalakhtar, Lots of bugs.
[14:59] <bilalakhtar> cool
[15:00] <bilalakhtar> thanks to jussi :)
[15:00] <shadeslayer> bilalakhtar: kde ones as well :P
[16:18] <yofel> what do I need to get the branch with the fix for bug 614067 uploaded to maverick? (universe)
[16:18] <yofel> the package needs a rebuild
[16:28] <JontheEchidna> yofel: I can sponsor it
[16:28] <yofel> thx :)
[16:37] <JontheEchidna> yofel: Uploaded, thanks for your contribution :)
[16:38] <yofel> thanks for uploading
[16:39] <JontheEchidna> I don't think I've played the -ng variant of lincity... might have to give it a shot once the rebuild builds
[16:42] <bluefoxicy> Lincity:  Build your very own city once you build your very own binary...
[20:34] <nenolod> bdrung_: we have communicated with the author of psx.c and are awaiting an official statement placing the file under BSD license
[20:34] <nenolod> bdrung_: it is safe to continue redistribution
[20:34] <nenolod> bdrung_: ubuntu shouldn't ship usf due to non-portability anyway
[20:58] <bdrung_> nenolod: while we are at the license files: we don't ship the usf plugin because src/usf/x86_fpu.c (and maybe others) are not DFSG compliant. are there any plans to change that?
[21:16] <bdrung_> nenolod: audacious/src/libaudacious++/plugin.h -> Can you replace "[insert GPL license here later]" with the gpl license?
[21:19] <bdrung_> nenolod: should i wait for the 2.4.1 release to get the psf plugin back?
[21:44] <crimsun> arg
[21:44] <cemc> h
[21:45] <cemc> :)
[21:45] <crimsun> would an archive admin please reject my upload of wireshark_1.2.11-1ubuntu0.1?
[21:45] <crimsun> (or maybe it'll automatically be rejected)
[21:57] <crimsun> ok, the latest /maverick/ upload is good.
[22:16] <nenolod> 15:11:40 <bdrung_>  nenolod: audacious/src/libaudacious++/plugin.h -> Can you replace "[insert GPL license here later]" with the gpl license?
[22:16] <nenolod> LOL
[22:16] <nenolod> that file hasn't even been shipped since 2006
[22:17] <bdrung_> ok, i only checked the source tarball
[22:19] <bdrung_> nenolod: do you have a release schedule for 2.4.1? it would be nice if we could ship 2.4.1 in maverick (including the psf plugin).
[22:20] <nenolod> bdrung_: no because due to us cowtowing to you we messed it up
[22:20] <nenolod> bdrung_: thanks for that
[22:22] <nenolod> bdrung_: general opinion is, at this point, to just toss that code because it's not very good.
[22:22] <nenolod> bdrung_: upse engine is better.