=== ivoks is now known as ivoks-afk
[02:53]  * highvoltage sees ScottK is in e-mail mode :)
[07:11] <\sh> moins
[07:13] <ajmitch> hi \sh
[07:15] <\sh> hey ajmitch
[07:53] <micahg> I'm wondering if debian/copyright says the upstream software is under GPL2, do I need to add a GPL 2 header to a shell wrapper I have in the package?>
[07:56] <RAOF> Is your shell wrapper copyrightable?
[07:57] <micahg> RAOF: only sets library path and runs exec, idk what is copywritable
[07:57] <RAOF> I don't think you need to worry; there's no sense in which your shell wrapper is going to be a derived work of the thing it's running.
[07:57] <micahg> er, copyrightable
[07:57] <RAOF> A simple rule of thumb: if the GPL header would be ~50% of the size of the file, it's probably not copyrightable :)
[07:58] <micahg> RAOF: yeah, it's 7 lines including description and spaces
[07:58] <\sh> a copyright header doesn't have anything to do with the GPL license header
[07:58] <RAOF> The GPL header is an example of a copyright header.
[07:59] <\sh> no it's not
[07:59] <persia> copyright assignment != license arrangements
[07:59] <RAOF> Yeah, fair enough.
[08:00] <\sh> it includes a copyright statement, yes, but the majority of the text is a license explanation
[08:00] <micahg> ok, let's get broader, do I need copyright assignment and or licensing in the shell script?
[08:00] <persia> micahg, You need copyright if you claim copyright.  You don't if you think it's trivial enough to be part of the greater work.
[08:01] <\sh> micahg: that depends on you, if you want that or not...copyright I would set (if it's important to you) the license things..I wonder if GPL + Public Domain is compatible
[08:02] <persia> \sh, They are compatible (result is GPL) anywhere "Public Domain" has meaning.  Lots of jurisdictions don't accept the concept of "Public Domain".
[08:02] <micahg> Who should it be copyrighted to
[08:02] <RAOF> You.
[08:03] <RAOF> Well, you wrote it, you have copyright.  You could assign your copyright to whomever you desire, I guess.
[08:04] <persia> micahg, I strongly recommend not assigning copyright to a fictional figure.  If you don't choose to hold it yourself, please assign to some corporeal or statutory person.
[08:05] <micahg> persia: k, well, I guess I could assign to myself, but I don't think I can add it in, since I"m doing a security update for a package and IIRC, it's best to just do the security update w/out any other changes?
[08:06] <persia> micahg, Unless the security update consists of adding the wrapper... :)
[08:06] <micahg> persia: actually, it's updating it
[08:06] <persia> Is it updating it in a way that is sufficiently non-trivial that you want to worry about it?  If so, add the copyright also.  If not, don't.
[08:08] <micahg> well, it's a simple change...
[08:08] <persia> Also, copyright only applies to expression, not to the ideas expressed, so by claiming copyright (and licensing), you're only saying under what conditions your code can be copied verbatim: rewrites are always permitted (ignoring software patents as out-of-scope for this discussion)
[08:08] <micahg> persia: I don't personally care if it's reused, I just don't want people worrying if they can use it as free software
[08:09] <persia> Would you be willing to assign copyright for the modified code to the current copyright holders?  Are you comfortable with the current licensing?  If the answer to both is "Yes" then don't do anything to add headers.
[08:09] <micahg> yes, I guess, if upstream felt they wanted to ship it, I'd have no issue
[08:10] <\sh> persia: right
[08:11] <persia> Then don't bother worrying about it.  This has a very slight chance of causing confusion in places like "France" where there is the concept of "natural right" limiting copyright assignment in certain ways, but in practice, nobody cares.
[08:11] <persia> s/"//g
[08:11] <micahg> persia: k, thanks
=== hannesw__ is now known as hannesw
=== hrw|gone is now known as hrw
[08:36] <micahg> persia: if I modify someone else's shell wrapper, what do I need to add to it if anything?
[08:36] <persia> micahg, If you are willing to assign copyright for the modifications to them, and accept their licensing for your work, nothing.
[08:37] <micahg> persia: k, yep, again, no big deal for me
[08:37] <persia> If you aren't willing to so assign copyright, you need to list yourself as a copyright holder for the result (likely along with other folk).
[08:37] <persia> If you aren't willing to distribute under that license, you can change the license, assuming the current license allows this, or not distribute the result.
[08:43] <dholbach> good morning
[08:43] <ajmitch> morning dholbach & welcome back
[08:43] <dholbach> thanks ajmitch
[10:04] <dholbach> persia, can you readd ubuntu-universe-sponsors to ubuntu-sponsors and remove the expiry?
[10:05] <persia> My plan is to remove the group entirely tomorrow.  Is there a reason I shouldn't?
[10:05] <dholbach> persia, can we remove it?
[10:05] <dholbach> please do if you can :)
[10:06] <persia> I was just waiting for the end of September.  It doesn't have any members anymore, I think.  And it oughtn't have any bugs (I'll do a final push if I find any before removing the team).
[10:07] <persia> Welcome back, by the way.  Also, I fell out of -sponsors, and got readded: would you mind making me an admin again?
[10:07] <dholbach> persia, perfect, thanks
[10:07] <dholbach> persia, done
[10:08] <persia> Thanks.
[12:32]  * RainCT is confused by the security updates info on the wiki
[12:32] <RainCT> What do I have to do to get a fixed package into -security?
[12:34] <nigelb> RainCT: I can't find much documentation, https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
[12:34] <nigelb> Asking in #ubuntu-hardened might be a good idea.
[12:39] <RainCT> Thanks nigelb
[12:40]  * RainCT wonders why they make it so complicated. It's tempting to just ignore the problem in Ubuntu.
[13:00]  * RainCT files a bug with a debdiff, subscribes ubuntu-security-sponsors and waits to see if something happens.   (Sorry for the previous comment btw, that was a too-many-confusing-wiki-pages-frustration :P).
[13:06] <nigelb> RainCT: that is something that needs fixing then
[13:07] <nigelb> i.e. the information not being up-to-date
[13:18] <RainCT> nigelb: Yup. Although it's not about it being up-to-date, it's that as an existing developer I can't find any straightforward information on what to do.
[13:19] <nigelb> RainCT: I know how that goes.
=== icf7 is now known as phihag
[13:59] <ScottK> oojah: Use python-foo where foo is whatever you import in Python (i.e. import foo) for the binary package name.  The source pacakge name can be whatever you think best.
[14:02] <jdstrand> RainCT, nigelb: we have strived to make the process for submitting security updates as close to regular updates as possible. https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures is the proper page, which is linked off of https://wiki.ubuntu.com/SponsorshipProcess
[14:04] <jdstrand> but if there is ever any question, feel free to ask in #ubuntu-security (aka #ubuntu-hardened)
[14:04] <RainCT> jdstrand: Hey :). I've seen that page but it doesn't say anything about how to submit the fix, other than a link to the SponsorshipProcess page which in the first line says it's for "prospective developers".
[14:05] <jdstrand> RainCT: which page, UpdateProcedures?
[14:06] <RainCT> jdstrand: SecurityTeam/UpdatePreparation#Submission which is linked to from UpdateProcedures
[14:06] <jdstrand> hmm, yes I see what you mean
[14:06] <jdstrand> I think SponsorshipProcess needs to be generalized
[14:07] <jdstrand> may be we should link directly to SecurityTeam/SponsorsQueue
[14:07] <jdstrand> s/may be/maybe/
[14:08] <RainCT> jdstrand: Ah, that page is much better.    /me goes to change the status of the bug he filled to Confirmed
[14:09] <jdstrand> the intent was to read the first and get to the second
[14:09] <jdstrand> but I'll just go to the second and recommend reading the first, since that seems to be more straightforward
[14:13] <jdstrand> RainCT: would you mind reading https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Submission and letting me know if that should work better?
[14:14] <persia> jdstrand, Should it recommend writing a Details section anyway, or are UUSNs no longer sent?
[14:15] <jdstrand> persia: we've sent only 1 or 2 UUSNs. while planned, our tools don't support it yet
[14:15] <jdstrand> persia: ie, that is still accurate
[14:15] <persia> Oh.  I thought wgrant fixed that a couple years ago.  My mistake.
[14:16] <jdstrand> I have a split infinitive
[14:16]  * jdstrand fixes
[14:19] <wgrant> I think the only UUSN was for ClamAV.
[14:20] <ScottK> Yes, and IIRC it hurt to squeeze it out of the current system/tools.
=== ApOgEE__ is now known as ApOgEE
[14:21] <jdstrand> it did
[14:22] <jdstrand> in fact, I jacked something up and had to come up with the procedure in https://wiki.ubuntu.com/SecurityTeam/UpdatePublication#Removing%20a%20Published%20USN to fix stuff :)
[14:23] <jdstrand> it was exciting for a few minutes though ;)
[14:25] <persia> stefanlsd, Any nifty cool ideas on how we can have UUSNs?  Any time for it?
[14:26] <jdstrand> https://blueprints.launchpad.net/ubuntu/+spec/security-m-community-usns is the bp
[14:30] <stefanlsd> persia: jdstrand: heys! my initial feeling is that USN's and UUSN's should work with the same process
[14:30] <RainCT> jdstrand: Yup, it looks better now. Thanks.
[14:31] <persia> stefanlsd, That meshes well with my feeling that we shouldn't have a "universe" component :)
[14:31] <jdstrand> hey stefanlsd! it's been a while :)
[14:31] <jdstrand> RainCT: thanks
[14:32] <jdstrand> the main thing is there are issues with usn-tool that need to be addressed
[14:32] <stefanlsd> jdstrand: yeah. been a terrible cycle (for me anyways)
[14:32] <jdstrand> that tool is used by landscape (and possibly other) consumers
[14:32] <jdstrand> stefanlsd: very busy here too
[14:35] <stefanlsd> jdstrand: is the plan to fix those tools, or do something else with uusn's (new name? uc|usn (community or unseeded?))?  might be nice to auto publish (or go to approve queue) for security bugs with cve's marked fixed released
[14:36] <stefanlsd> jdstrand: not sure if im wrong, but is generating USN's currently a time consuming process?
[14:37] <jdstrand> stefanlsd: the only part about generating a USN that is horribly time consuming is drafting the USN text
[14:37] <ScottK> lfaraone: Would you please look at the sugar* packages on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi and propose update/removal as needed?
[14:37] <jdstrand> stefanlsd: we figured we could pull that from the changelog for a community usn
[14:37] <stefanlsd> jdstrand: yeah, was thinking similair (and maybe the CVE report text)
[14:37]  * jdstrand nods
[14:38] <jdstrand> it's been deferred to natty for now
[14:38] <jdstrand> hopefully I'll be able to get to it. it is something we've wanted for a while
[14:40] <stefanlsd> jdstrand: ok, cool. hopefully i'll be able to help with that
[14:40] <jdstrand> nice
[14:45] <persia> stefanlsd, Please avoid "community".  There's plenty of unseeded stuff supported by folks who consider it their job and plenty of seeded stuff supported by folks who don't.
[14:46] <persia> (and both types of folks are part of our community)
[14:49] <highvoltage> persia: surely people who are paid to maintain stuff or companies who contribute can be considered part of the ubuntu community?
[14:50] <highvoltage> persia: I'm not sure I agree with some people who associate community strictly with hippies :)
[14:51] <stefanlsd> persia: kk. guess people are just going to need education what 'unseeded' is
[14:53] <ScottK> stefanlsd: The problem is that we are all (paid or not) part of the community.  So community maintained means precisely nothing.
[15:01] <persia> highvoltage, Neither I, but I also object to anyone who suggests that "unseeded" implies "community" and "seeded" doesn't somehow.
[15:02] <persia> stefanlsd, "unseeded" merely means not in any seeds.  Has no relation to "main" vs. "universe" or any other dichotomy of which I am aware.
[15:06] <highvoltage> persia: ah, agreed
[15:12] <stefanlsd> agreed!
[15:14] <persia> \o/ consensus!
[15:14] <ScottK> Would someone please have a look at xvidcap.  It's currently FTBFS and needs a rebuild for NBS.  From looking at debian/changelog, it looks like there is an update on Debian Multimedia that might fix it, so it probably needs a manual merge.  http://www.debian-multimedia.org/pool/main/x/xvidcap/xvidcap_1.1.7-0.5.dsc
[15:15] <lfaraone> ScottK: will do, it probably just needs some dep fixes.
[15:15] <ScottK> lfaraone: Thanks.
[15:15] <ScottK> (note: that was for an earlier request, xvidcap is still up for grabs)
[15:22] <tumbleweed> I looked at xvidcap it a while back and it wasn't just a trivial merge, enjoy :)
[15:25] <\sh> ScottK: who will do syncs when we request some?
[15:26] <ScottK> \sh: Standard archive admin work. We have time for Universe stuff.
[15:28] <ScottK> YokoZar: Somehow we got two copies of gnome-exe-thumbnailer in queue, so don't be excited when you get a reject.  It's just for the duplicate.
[15:28] <YokoZar> ScottK: did you also get a lucid-proposed one?
[15:28]  * ScottK looks
[15:28] <YokoZar> ScottK: maybe I uploaded the same .changes twice
[15:29] <ScottK> YokoZar: I don't see one there.
[15:29] <YokoZar> ok that's what happened then
[16:26] <oojah> ScottK: Great, thanks.
[16:26] <ScottK> oojah: You should consult Debian Python policy on this as we follow it.
[16:30] <ari-tczew> ScottK: do you work on ubuntu-release bugs?
[16:30] <ScottK> ari-tczew: When I have time and expertise, yes.
[16:34] <oojah> ScottK: Sure thing.
[16:51] <SpamapS> micahg: ping.. whats the status of mongodb and bug 557024 ?
[16:51] <ubottu> Launchpad bug 557024 in mongodb (Ubuntu) "mongo / mongod as packaged can't load libmozjs.so" [High,Confirmed] https://launchpad.net/bugs/557024
[16:52] <micahg> SpamapS: is that updated with the changes that resulted in a successful build in your PPA?
[16:52] <SpamapS> micahg: it should be.. let me verify that
[16:53] <micahg> SpamapS: can I PM You?
[16:54] <SpamapS> micahg: please do
=== RoAkSoAx is now known as andreserl
=== andreserl is now known as RoAkSoAx
[17:04] <SpamapS> ScottK: I'm not finding a standard procedure to file for package removal. Is it somewhere in the wiki, or more informal?
[17:05] <ScottK> It's in the wiki somewhere.  It's file a bug asking for source and binary removal (list the binaries), state the package has no rdepends (this needs to be true), get a developer to approve it and then they will subscribe ubuntu-archive.
[17:09] <SpamapS> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing Packages
[17:09] <SpamapS> found it
[17:13] <ari-tczew> is there any wrong? I have in debian/rules: -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/clementine/usr \
=== JanC_ is now known as JanC
[17:21] <persia> ari-tczew, Depending on various other factors, you might have wanted ${CURDIR}/debian/tmp/usr/ or similar.
=== hrw is now known as hrw|gone
[17:36] <tumbleweed> ari-tczew: generally you want INSTALL_PREFIX=$(CURDIR)/debian/clementine PREFIX=/usr
[17:37] <tumbleweed> i.e. you want the program to look for data in /usr/... but you are instalning into a temporary root directory to generate the deb
[17:38] <persia> CMAKE is odd though
=== ivoks-afk is now known as ivoks
[18:58] <fabrice_sp> Hi! Are archive admin still processing sync requests for Universe? I have 3 of them waiting, but I was wondering if I shouldn't use the ack-sync script
[18:59] <ScottK> fabrice_sp: Still being processed.  A bunch were done just yesterday.
[18:59] <fabrice_sp> ok. good to know. Thanks!
[19:46] <ScottK> fta: I'm finding that in KDE, setting Chromium to default browser no longer works (With rekonq, firefox, and chromium installed the system things it's firefox).  Do you have any suggestions on how I might troubleshoot this (It's find on Lucid).
[19:47] <fta> ScottK, which build? maverick or one of the 4 ppas?
[19:48] <ScottK> fta: Maverick.
[19:48] <ScottK> It's been problematic on Maverick for some time, I just didn't focus on it before now.
[19:48] <fta> ScottK, i made 1 change in the last upload last week. the desktop file now has a full path
[19:49] <ScottK> That wouldn't be it.
[19:49] <ScottK> It does back further than that and it's still there as of today..
[19:49] <fta> it was supposed to help with chromium reporting it's not default, but it didn't work
[19:49] <ScottK> I see.
[19:50] <fta> in trunk, upstream landed a change for kde.. hold on
[19:50] <fta> http://crbug.com/18106
[19:51] <fta> i have that in the daily builds and in the -dev channel
[19:51] <ScottK> fta: That looks like it.
[19:52] <ScottK> Odd it works in Lucid then.
[19:52] <fta> in gnome, none of this ever worked. and i have no clue why
[19:53] <ScottK> Any chance we could have that in Maverick?
[19:54] <fta> i have to check if it's just about shipping a fixed xdg-mime or if it involves back porting more patches
[19:55] <ScottK> Cool.  Thanks.
=== rgreening_ is now known as rgreening
=== sebner__ is now known as sebner
[21:59] <tyarusso> Is there a way to see what the delta is (if any) between an Ubuntu package and the Debian one easily?
[22:00] <tumbleweed> tyarusso: ubuntudiff.debian.net
[22:03] <ari-tczew> nice page! tumbleweed, is it included on wiki.ubuntu.com any page?
[22:03] <highvoltage> tumbleweed: cool! is that new?
[22:03] <ari-tczew> if not, I suggest to include to page about merging
[22:06] <lfaraone> RAOF: re tmpfs, is there a configuration option to have sbuild use it with aufs?
[22:06] <tumbleweed> ari-tczew: no idea. Hmm, it seems abit broken atm
[22:07] <tumbleweed> ari-tczew, highvoltage: there's also patches.ubuntu.com of course
[22:08] <ajmitch> or pull-lp-source, pull-debian-source, debdiff
[22:09] <ajmitch> or just grab the bzr branches, pray that they're up to date & bzr diff, which I find useful at times :)
[22:09] <ari-tczew> or grab-udd-merge ?
[22:09] <ajmitch> do you think we have too many ways to do something? :)
[22:10] <ari-tczew> ajmitch: I think that merging bzr branches is not sense.
[22:10] <tumbleweed> ari-tczew: yip
[22:12] <ajmitch> & doesn't grab-udd-merge use those same bzr branches?
[22:12] <ari-tczew> ajmitch: tumbleweed is a father of grab-udd-merge
[22:12] <tumbleweed> ajmitch: yes, it's just a wrapper around that (that also generates debdiffs)
[22:12] <ajmitch> ari-tczew: yes I know
[22:13] <tumbleweed> tyarusso asked for "easily" but yes, when one is looking at diffs it's usually because you are about to do something so you'll pull both source pkgs / branches and debdiff
[22:14] <ari-tczew> after merging bzr you need to upload package to revu. it's not sense
[22:14] <ajmitch> why would you do that?
[22:15]  * ajmitch doesn't really like using revu for new upstream versions of packages
[22:15] <ari-tczew> ajmitch: sorry, I mean dput
[22:15] <ari-tczew> also 4 words phrase
[22:16] <ajmitch> right, so you don't like the double up of having to push the branch changes & then dput as well?
[22:17] <ari-tczew> ajmitch: yes. bazaar should build package automatically after push
[22:17] <ajmitch> that will come in time, but there's a bit of work to get to that point
[22:18] <ajmitch> since we expect all packages to have a signed .changes file, and the source package would need to be created on the server from the branch
[22:18]  * ajmitch doesn't know the current status of it, but it's getting there
[22:19] <tyarusso> tumbleweed: very cool.
[22:37] <fta> ScottK, did you file a bug for the default browser thingy? (so i can close it in my d/changelog)
[22:37] <ScottK> fta: I did not.
[22:38] <ScottK> I kept hoping it would go away on it's own.
[22:49] <fta> ScottK, ok, backported the patch. it's going 1st to the ucd-stable ppa (same version as maverick). could you please test that one (once it's built) so i can update maverick if it's fine?
[22:49] <ScottK> fta: I should be able to.  Thanks.
[22:51] <fta> ScottK, great. (https://edge.launchpad.net/~chromium-daily/+archive/stable) most probably in an hour or two
=== yofel_ is now known as yofel
[23:44] <micahg> if someone requests an update is it bad form to use requestsync and dupe the original request?
[23:48] <persia> I usually just edit the bug, so they stay as submitter.
[23:50] <micahg> persia: k