[00:28] <isleshocky77>  I've been looking through the packaging documentation for a while now and still I'm running in circles. Could someone set me straight. I took the source of pidgin-libnotify and modified one file. Now I want to get a build in my personal launchpad ppa for x32 and amd64
[00:38] <micahg> isleshocky77: try #ubuntu-packaging
[03:46] <micahg> if I'm doing a new upstream release, is it worth merging from Debian?
[03:46] <micahg> sorry I should be clearer, the new debian release only was for 1 of the ubuntu revisions (i.e. we don't add anything, diff slighlty smaller)
[04:00] <rhpot1991> got a question on licensing, is it possible to get a non gpl compatible open source product into one of the ubuntu repositories?  the license in question is apple public software license.
[04:02] <micahg> rhpot1991: is it a free license?
[04:02] <rhpot1991> micahg: http://www.gnu.org/philosophy/apsl.html
[04:02] <RAOF> rhpot1991: If it's DFSG free, there's no problem (unless, of course, it does something stupid, like link against GPL libraries or somesuch).
[05:19] <ScottK> Of course GNU considers GFDL invariant a free license, so I wouldn't take their opinion as counting for much.
[05:27] <RAOF> Heh.
[07:02] <zooko> Yay! rockstar uploaded a package of Tahoe-LAFS 1.7.1 for Ubuntu!
[07:02] <zooko> Anybody want to test it out?
[07:06] <AnAnt> Hello
[07:54] <bilalakhtar> Why did M-o-M has to go down just before FF ?
[08:11] <dholbach> good morning
[08:20] <zooko> Who sponsored Tahoe-LAFS v1.7.1 to go into Maverick just now?
[08:20] <zooko> (I want to thank them on the tahoe-lafs mailing list.)
[08:24] <dholbach> zooko: https://edge.launchpad.net/ubuntu/+source/tahoe-lafs/1.7.1-0ubuntu1
[08:25] <zooko> Thanks!
[08:25] <zooko> Thanks, maco
[08:26] <zooko> Good night, folks (UTC-6)
[08:42] <AnAnt> dholbach: Hello
[08:44] <dholbach> hey AnAnt, sabah il cheer
[08:49] <AnAnt> dholbach: I think you meant: kheer
[08:50] <dholbach> AnAnt: that could well be :)
[09:59] <dholbach> Rhonda: does your offer for that git session still stand? :)
[10:00] <Rhonda> I hope so, but I don't have much time to prepare it properly.  %-(
[10:01] <Rhonda> Didn't sleep much this night neither, your young one wasn't working along.
[10:01] <dholbach> Rhonda: next week thursday?
[10:05] <nigelb> wow, git session.  Now that totally rocks :)
[10:15]  * Rhonda cries
[10:19]  * X3 throws Rhonda a chocolate tnafish
[10:47] <tumbleweed> it'd also have to ch
[10:47] <tumbleweed> grr, excuse that
[12:46] <pindonga> hi, I would like to seek sponsoring for bug #616025
[12:46] <pindonga> anyone iinterested?
[12:47] <AnAnt> looking
[12:51] <AnAnt> pindonga: in copyright file, upstream source can be https://launchpad.net/django-configglue
[12:51] <pindonga> ok,
[12:53] <AnAnt> also from upstream LICENSE file, it seems the copyright holder is Canonical Ltd., not Canonical ISD hackers
[12:54] <AnAnt> pindonga: ^ that is for the Copyright field
[12:54] <AnAnt> pindonga: the License field machine readable format copyright would be as follows:
[12:55] <AnAnt> License: LGPL-3
[12:55] <pindonga> the License was like that but lintian complained I wasn't referring to the common licenses
[12:55] <pindonga> Copyright: 2010 Canonical Ltd. would be ok?
[12:56] <AnAnt> followed by the disclaimer
[12:56] <AnAnt> as for Copyright: 2010, Canonical Ltd.
[12:56] <AnAnt> and you may even add a URL
[12:57] <AnAnt> for example. Copyright: 2010, Canonical Ltd. (http://www.canonical.com)
[12:57] <AnAnt> back to License
[12:58] <AnAnt> have a look at gst123 copyright file for example
[12:58] <AnAnt> http://packages.debian.org/changelogs/pool/main/g/gst123/gst123_0.1.2-1/gst123.copyright
[12:59] <AnAnt> is this tarball a repackage ?
[13:00] <pindonga> this would be the first package for ubuntu
[13:00] <pindonga> we had some previous packages in our own ppa for custom deployments
[13:00] <pindonga> but in those we never bothered to get the package right
[13:01] <AnAnt> I mean, no upstream tarballs released ?
[13:03] <pindonga> not yet, but I can do that if its needed
[13:03] <AnAnt> I'm not sure about that, but it seems to me that you removed the non-free icons, right ?
[13:03] <pindonga> mhhh
[13:04] <pindonga> actually I think the disclaimer in the license is wrong
[13:04] <pindonga> (I copied this from another project we opensourced)
[13:04] <pindonga> this  one doesn't have any images or icons
[13:04] <AnAnt> the disclaimer is in the LICENSE & the LP page
[13:04] <AnAnt> from LP:    Commercial subscription expires 2020-12-09
[13:05] <pindonga> this was an internal project first, and now I changed the license to LGPL3 as we were allowed to opensource
[13:05] <pindonga> I don't know why the "internal project" and "commercial subscription" did stick around
[13:06] <AnAnt> ok, maybe that should be changed upstream
[13:06] <pindonga> ok, so, let's recap please. I need to
[13:06] <pindonga> a) change the License field
[13:06] <pindonga> b) add a Dsiclaimer field
[13:06] <pindonga> c) change the Copyright field
[13:06] <pindonga> d) change the Upstream-Source field
[13:07] <pindonga> e) publish an upstream source tarball
[13:07] <pindonga> f) fix the LP project status
[13:07] <AnAnt> not a Disclaimer field, it is just a paragraph under License field, have a look at the example I gave you pleas
[13:07] <pindonga> g) fix the lincese disclaimer
[13:07] <pindonga> ah, ok
[13:07] <AnAnt> I'm not sure if it is required to publish upstream source tarball, but that would be useful for other distros anyways
[13:08] <AnAnt> as for f) what matters is fixing the LICENSE file in upstream tarball
[13:08] <AnAnt> but it would be rational to also fix the description in LP page
[13:09] <AnAnt> oh, you mentioned it in g) already !
[13:09] <AnAnt> ok, h) there is a generated patch
[13:09] <AnAnt> you can avoid that by removing the generated files in  clean target
[13:10] <AnAnt> I dunno how that is done with CDBS
[13:10] <pindonga> where do you see the patch?
[13:10] <AnAnt> debian/patches/debian-changes-0.3-0ubuntu1
[13:10] <pindonga> k
[13:10] <pindonga> I'll look into it
[13:10] <AnAnt> ok
[13:16] <AnAnt> pindonga: in the control file, you can drop XB-Python-Version field
[14:19] <pindonga> AnAnt, I just reuploaded the package, can you please give it another look?
[14:26] <pindonga> hi AnAnt , in case you didn't see my previous message
[14:26] <pindonga> pindonga> AnAnt, I just reuploaded the package, can you please give it another look?
[14:26] <pindonga> (I noticed you had a connectivity hickup)
[14:26] <pindonga> :)
[14:31] <pindonga> AnAnt, regarding the 'commercial support' thing, bac told me it's not so easy to remove... if this is still an issue for packaging, please contact him
[14:32] <AnAnt> pindonga: what commercial support ?
[14:32] <AnAnt> pindonga: the only issue was with this:
[14:32] <pindonga> in the license (in the launchpad page)
[14:32] <pindonga> we had 'internal project'
[14:32] <AnAnt> The image and icon files in django-configglue are copyright Canonical,
[14:33] <AnAnt> and unlike the source code they are not licensed under the
[14:33] <AnAnt> LGPLv3.  Canonical grants you the right to use them for testing and
[14:33] <AnAnt> development purposes only, but not to use them in production (commercially or
[14:33] <AnAnt> non-commercially).
[14:33] <pindonga> ok, that I removed
[14:33] <AnAnt> pindonga: you were talking about the LP page ?
[14:33] <pindonga> yeah, don't worry
[14:34] <AnAnt> ok
[14:34] <pindonga> just let me know if there is anything else I need to change on the package
[14:34] <pindonga> please
[14:36] <AnAnt> pindonga: third-party copyright should be noted in debian/copyright
[14:36] <AnAnt> pindonga: so you'll need a section like
[14:36] <AnAnt> File: path/to/file
[14:36] <AnAnt> Copyright: year, holder
[14:36] <AnAnt> License: whatever
[14:38] <AnAnt> pindonga: also please run lintian on the changes file, it will give you some good pointers
[14:39] <AnAnt> I don't understand why the resulting deb file has python (<<2.7) dependency
[14:40] <AnAnt> pindonga: by the changes file, I mean the one resulting from building the binary package (not just _source.changes)
[14:41] <AnAnt> or just run lintian on the source & binary packages
[14:41] <pindonga> AnAnt, sure, thanks
[14:42] <tumbleweed> AnAnt: python dependancies like that are a result of a python helper
[14:44] <AnAnt> tumbleweed: he's using python-central, I dunno about it
[14:45] <AnAnt> I'm used to python-support
[14:45] <tumbleweed> AnAnt: looking at th epackage now
[14:45] <AnAnt> thanks
[14:45] <AnAnt> brb
[14:45] <tumbleweed> pindonga: python-support is more widely used :)
[14:46] <pindonga> tumbleweed, I started off from another package :) is it important to use python-support instead of python-central?
[14:47] <tumbleweed> pindonga: it helps if you actually learn what you are doing rather than just modifying something else (but one has to start somewhere)
[14:47] <pindonga> yes, I agree
[14:47] <tumbleweed> more people know python-support, but both of them are slated to be replaced by dh_python2
[14:47] <pindonga> :/
[14:47] <pindonga> I'll try to make the next package use python-support
[14:48] <tumbleweed> pindonga: practically speaking for this package, there's nothing really python-central specific
[15:08] <tumbleweed> pindonga: full review on revu
[15:17] <AnAnt> tumbleweed: does debhelper compat level matter ?
[15:18] <tumbleweed> AnAnt: I don't know what caused python-central to misbehave either, I don't know it as well as -support or dh_python2
[15:19] <tumbleweed> AnAnt: it doesn't matter, it's just a case of why use an old version...
[15:19] <AnAnt> tumbleweed: ok
[15:21] <AnAnt> I don't understand what third-party license is there
[15:21] <AnAnt> running licensecheck says that every file is copyrighted by Canonical
[15:22] <pindonga> AnAnt, its because we copied over some code from django and adapted it, so we need to say it came from django source base
[15:22] <AnAnt> and changed the license to LGPL?
[15:25] <LucidFox> http://launchpadlibrarian.net/53483722/buildlog_ubuntu-maverick-i386.epiphany-browser_2.30.2-1ubuntu5_FAILEDTOBUILD.txt.gz
[15:25] <LucidFox> Any idea what could cause this?
[15:29] <micahg> LucidFox: yeah, there was some discussion about this in -desktop yesterday
[15:34] <micahg> bdrung: why do sponsorships get the assignee unassigned?
[15:39] <LucidFox> micahg> From the looks of it, WebKit-1.0.gir depends on JSCore version 1.0, while JSCore-1.0.gir claims 1.1
[15:39] <micahg> LucidFox: yeah an upload was done last night to change 1.0 to 1.1
[15:39] <micahg> LucidFox: https://launchpad.net/ubuntu/maverick/+source/gir-repository/0.6.5-6ubuntu6
[15:40] <pindonga> AnAnt, tumbleweed I just uploaded a new version, can you please re-check? (I hope I got it all this time)
[15:55] <pindonga> tumbleweed, shall I  look for someone else to finish the review (I don't want to bother you too much, but I would really like to make the maverick deadline)
[15:56] <tumbleweed> pindonga: I added more review
[15:56] <pindonga> ah, cool thanks
[15:56] <pindonga> tumbleweed, a few things
[15:57] <tumbleweed> pindonga: btw, does it work? :)
[15:57] <pindonga> 1. the thing with third-party: we copied some code over from django and modified it... the idea is to cope with django's license, mentioning that we used and modified original django code
[15:58] <pindonga> 2. re License: when  I run the lintian locally, it complains if I just use LGPL-3 saying I'm not referencing the common-licenses location
[15:59] <pindonga> how can I spot all those errors you found? running lintian locally gave no errors at all (I checked against the built package, the sources file and the dsc file)
[15:59] <tumbleweed> 1. so, it shouldn't only say "Copyright: Canonical"
[15:59] <pindonga> s/sources/changes/
[16:00] <tumbleweed> 2. instead of sying "given below" five the common-licenses path, then lintian knows you are doing the rgiht thing
[16:00] <tumbleweed> I could be using a newer lintian...
[16:00] <pindonga> I'm on lucid (maybe it's that?)
[16:01] <pindonga> :q
[16:01] <highvoltage> also, lintian doesn't always spot all the problems that a human can :)
[16:01] <tumbleweed> highvoltage: we try to make it, though :)
[16:01] <pindonga> tumbleweed, what do you mean by 'the watch file doesn't work?' / how do you test that?
[16:02] <highvoltage> *nod*
[16:02] <tumbleweed> pindonga: uscan --verbose --report
[16:03] <pindonga> ok, regarding the License: shouldn't it say the same thing as the LICENSE file? in that case, should I remove the LGPL code from it and point to the common-licenses file? if so, what happens on non-ubuntu distributions?
[16:03] <tumbleweed> pindonga: common-licences comes from debian
[16:04] <tumbleweed> it should say the same thing as LICENSE, yes, except that you can factor out the licence body, as found in common-licenses (look at other packages' copyright files)
[16:04] <maco> zooko: thank rockstar. he did the packaging. i just sponsored it
[16:05] <zooko> I did.
[16:05] <zooko> He and I have some plans to get packaging of Tahoe-LAFS for Ubuntu more automated.
[16:05] <maco> ok
[16:06] <zooko> So, that was Tahoe-LAFS v1.7.1. It has the major new improvement that it can be configured to act as an SFTP server, which means you can then point Nautilus at it and browse your decentralized filesystem graphically.
[16:07] <zooko> Now, Tahoe-LAFS v1.8.0 is in release-candidate mode. In all likelihood the current release--1.8.0c2--is going to be identical to the final 1.8.0 release.
[16:07] <zooko> (Unless someone reports a regression, security hole, or major bug.)
[16:07] <zooko> I'm toying with the notion of going ahead and announcing 1.8.0-final a few days early in the attempt to get 1.8.0 into Maverick.
[16:07] <zooko> The scheduled release date for 1.8.0 final is "approximately August 15".
[16:10] <zooko> Hm, I don't think I should cut the 1.8.0c2 test cycle short.
[16:10] <zooko> So, suppose I want to get 1.8.0-final included in Maverick, but it won't be released until the 15th (Sunday), then should I:
[16:11] <zooko> 1. ask to include 1.8.0c2 into Maverick right now
[16:11] <zooko> 2. file a FFE for 1.8.0-final, on Sunday
[16:11] <zooko> 3. forget about it and wait til Maverick+1
[16:11] <zooko> 4. other?
[16:13] <zooko> whoops gotta get ready for work. will check this IRC window soon...
[16:46] <pindonga> tumbleweed, what Standards-Version should I use? the one on lucid is 3.8.4
[16:56] <pindonga> tumbleweed, ok, I just pushed another version (please let me know when you looked at it)
[18:26] <paultag> lfaraone: ping, I was told to talk with you :)
[18:27] <paultag> lfaraone: I'm up in Debian, I work on the Fluxbox package ( only active maintainer right now ), and my DD is out ( his dad just died ). I'd love to get my new version uploaded in Debian in time to sync for Ubuntu. Is there any chance you could sponsor the upload / review the package. Currently there are 4 lintaian issues on the .deb because of upstream doc issues. I'm working on helping them resolve them
[18:29] <lfaraone> paultag: I'll be happy to take a look at it. Upload it to mentors and mail me the resulting email to myircnick at debian dot org
[18:29] <paultag> lfaraone: thanks! I'll do that right away.
[18:29] <lfaraone> paultag: these issues were present in the previous version, right?
[18:29]  * lfaraone will get to it in about 30 minutes, I was just walking out to lunch
[18:29] <paultag> lfaraone: yes, I have removed quite a few other lintian issues, and did a few bugfixes, and other fixes
[18:29] <paultag> lfaraone: sure, no problem. I'll be online
[18:30] <paultag> lfaraone: no new features
[18:30] <pindonga> anyone around that want to finish reviewing #616025?
[18:37] <fabrice_sp> pindonga, you have a generated patch in debian/patches: either make a clean patch or change it upstream. Maintainer field has the old value
[18:38] <pindonga> fabrice_sp, thanks, what do you mean by 'old value'?
[18:38] <fabrice_sp> it's not MOTU anymore
[18:39] <fabrice_sp> it's Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[18:39] <fabrice_sp> Standards-version should be 3.9.1 also for maverick
[18:40] <fabrice_sp> also, do you really need a build dependency on python ?
[18:40] <pindonga> fabrice_sp, don't know, I think it was mentioned in the packaging guide
[18:44] <pindonga> fabrice_sp, when I remove the python build dep, lintian complains (E: missing-python-build-dependency)
[18:44] <pindonga> so I think I just leave it in there
[18:46] <fabrice_sp> because of distutils. it seems. ok
[18:51] <pindonga> fabrice_sp, ok, just pushed a new revision
[18:52] <fabrice_sp> ok
[19:03] <lfaraone> paultag: ah, maco referred you to me. I'll have to talk to her about that :P
[19:03] <fabrice_sp> pindonga, the watch file get a newer version from launchpad
[19:03] <fabrice_sp> is it normal?
[19:03] <pindonga> yes, I don't know why that is
[19:04] <maco> lfaraone: he needed someone that could make uploads to debian AND ubuntu happen... ergo: you
[19:04] <pindonga> ah, actually I think I need to replace the released source with the latest one
[19:04] <lfaraone> maco: thanks :P
[19:06] <paultag> lfaraone: haha
[19:06] <lfaraone> maco: by the way, when are you planning on leaving / returning from OLF?
[19:06] <maco> dunno yet
[19:06]  * lfaraone has school that week.
[19:07] <paultag> lfaraone: one time deal. My DD / all my DD friends IRL are busy :(
[19:07] <paultag> lfaraone: come on by, it will be great, I'm in Ohio
[19:07] <paultag> lfaraone: this counts for beer debt
[19:07] <lfaraone> maco: friday after 3:01, monday before 8:19 :P
[19:07] <maco> paultag: which you cant pay off til he turns 21 in 4 years?
[19:07] <paultag> Oh lawdy
[19:07] <lfaraone> paultag: right, I'll collect it in 4 years when I'm legal.
[19:07] <paultag> Sure thing.
[19:07] <maco> lfaraone: or in one year in europe?
[19:08] <paultag> maco: I had my first legal drink @ 16 in Germany
[19:08] <lfaraone> maco: sure. you going to debconf bosnia? :)
[19:08] <paultag> :)
[19:09] <paultag> maco: did you hear about the ubucon we'll be doing on friday @ olf ?
[19:10] <paultag> maco: akgraner was nice enough to get the ball rolling with that, it should be a blast.
[19:10] <pindonga> fabrice_sp, I think it finds a newer version beause lp doesn't really delete the old files? (even though I deleted them via the web interface?)
[19:11] <pindonga> if you notice it matched 0.3.0.1  and now it matches 0.3.0.3 while looking for 0.3
[19:15] <paultag> lfaraone: any issues you see so far?
[19:15] <pindonga> fabrice_sp, if having a watchfile is optional, I'd go with removing it if it causes issues for approving the package
[19:15] <lfaraone> paultag: I'll let you know.
[19:15] <paultag> lfaraone: thanks :)
[19:16] <fabrice_sp> pindonga, I'd really prefer to have a working watch file :-)
[19:17] <pindonga> do you know how I can change it so that it takes the version in the url file? I tried that but it complains
[19:17] <pindonga> the download url is: http://edge.launchpad.net/django-configglue/trunk/0.3/\+download/django-configglue-0.3.tar.gz
[19:17] <lfaraone> paultag: is there a reason you're packaging a git snapshot?
[19:18] <pindonga> uscan complains about 'Use of uninitialized value $filepattern...'
[19:18] <paultag> lfaraone: yes, the 1.1.1 release is over 2 years old now, and there are a lot of debian patches I got merged into git mainline
[19:18] <paultag> lfaraone: it resultes in a much cleaner package imho. Is that wrong?
[19:18] <lfaraone> paultag: have attempts to get upstream to relese failed?
[19:18] <paultag> lfaraone: yes
[19:18] <paultag> lfaraone: I've tried over the last 4 months to get a .2 release, no luck
[19:18] <lfaraone> paultag: it's fine. you still have a tonne of patches though :)
[19:19] <paultag> haha, aye. I think the ones left are debian-isms
[19:19] <paultag> or ones upstream refuses
[19:19] <lfaraone> (well, only two, which is an improvement over the last version)
[19:19] <paultag> lfaraone: :)
[19:20] <lfaraone> paultag: if you're packaging git snapshots, you *should* write a get-orig-source rule to automate the process so that other people can reproduce your steps.
[19:21] <fabrice_sp> pindonga, this is because you have 2 times (.+) in your watch file
[19:21] <paultag> lfaraone: OK, I'll get that in the git.debian asap. Is it blocking this upload?
[19:21] <lfaraone> paultag: not per se, but I'll have to guess which repo etc oyu used so I can verify your tarball.
[19:22] <paultag> lfaraone: Ahha. git.fluxbox.org. I'll write the rule and get it in git.debian
[19:22] <fabrice_sp> pindonga, if you replace the first one with .*, it works
[19:25] <pindonga> fabrice_sp, cool, I'll just resubmit the package
[19:25] <pindonga> thanks
[19:27] <lfaraone> hmmm. how does one diff two *debian.tar.gzs.... debdiff tells me all the changes that were made, period, when I just want the changes that have been made in debian.
[19:32] <pindonga> fabrice_sp, ok, I just pushed the update
[19:33] <lfaraone> paultag: there's no commit on 2010-08-07 according to http://git.fluxbox.org/?p=fluxbox.git;a=shortlog;h=HEAD , did you mean the 2010-08-05 commit?
[19:33] <paultag> lfaraone: doh! yes, I forgot, I was playing in my PPA and had to get rid of the old revisions. That was just the date when I pulled the git tree down
[19:33] <lfaraone> paultag: if so, which? (I personally find it helpful to do "BASE_VERSION+gitDATE.REF" so there's no ambiguity.
[19:33] <paultag> lfaraone: yeah, I used the date of when I pulled
[19:35] <lfaraone> paultag: so you would want something like fluxbox-1.1.1+git20100805.0cc08f9, methinks
[19:35] <paultag> lfaraone: will that work if the sha sum on the same day for the next revision is "less" then the current revision?
[19:35] <paultag> lfaraone: e.g. a f8
[19:36] <lfaraone> paultag: No. But I'd expect you wouldn't be packaging two releases from the same day.
[19:36] <paultag> lfaraone: Very true
[19:36] <paultag> lfaraone: Should I change that, then?
[19:37] <lfaraone> paultag: if you are planning on that, feel free to do fluxbox-1.1.1+git20100805.0.0cc08f9, and incr the middle .0. :)
[19:37] <lfaraone> paultag: very yes.
[19:37] <lfaraone> paultag: it's important to have zero ambiguity about what version you're working with.
[19:37] <paultag> lfaraone: should I also include get-orig-source? I was just working on it, but I think it's broken. Could I exclude that for this revision?
[19:38] <paultag> lfaraone: OK. Let me fix that.
[19:38] <lfaraone> paultag: sure. I have a spare get-orig-source rule lying around, if you want it.
[19:38] <paultag> lfaraone: I'd love it
[19:38] <lfaraone> paultag: here's what I use for pianobar: http://bazaar.launchpad.net/~lfaraone/pianobar/debian/annotate/head:/debian/rules#L6
[19:39] <lfaraone> which also supports tags, as a matter of fact.
[19:39] <paultag> lfaraone: Ahha, I see what you're doing.
[19:40] <paultag> that's a lot better then what I was writing
[19:40] <lfaraone> paultag: that code has been adopted, rehashed, converted to different VCSs, so I'm surprised I got it working myself :)
[19:41] <fabrice_sp> pindonga, the package is not installable in Maverick, because python-configglue (>= 0.9), but maverick has 02dev-0ubuntu2it's expecting
[19:41] <paultag> lfaraone: I just noticed I don't have a debian revision on the package. Would it do me good to have it as 1.1.1-1+git... ?
[19:41] <pindonga> python-configglue 0.9 should have been proposed for maverick already
[19:42] <pindonga> let me check
[19:42] <lfaraone> paultag: uh, you do, the debian revision is at the end.
[19:42] <lfaraone> paultag: "fluxbox_1.1.1+git20100807-1"
[19:42] <paultag> Oh duh, my changelog
[19:42] <paultag> I was looking at my ls
[19:43] <paultag> lfaraone: I'm still just a programmer, sorry for the new-ish questions
[19:43] <fabrice_sp> pindonga, maverick still has 02dev
[19:43] <lfaraone> paultag: no worries. I'm only a packager. I'm still amazed anybody trusts me to upload anywhere, let alone Debian / Ubuntu :)
[19:43] <paultag> :P
[19:44] <paultag> lfaraone: you're keeping me in-line :)
[19:47] <pindonga> fabrice_sp, ok, I'm told they are updating maverick right now
[19:47] <pindonga> I'll ping you back as soon as I have word that it reached maverick
[19:47] <fabrice_sp> ok
[19:55] <paultag> lfaraone: I'm trying a build now. I'll put it to mentors if it builds OK
[19:56] <lfaraone> paultag: mk.
[19:59] <paultag> lfaraone: seriously, thanks so much. You really just saved my day :)
[20:02] <lfaraone> paultag: I live to serve.
[20:06] <paultag> lfaraone: warning: the current version (1.1.1+git20100805.0cc08f9-2) is smaller than the previous one (1.1.1+git20100807-1) <-- this was giving me flack
[20:06] <paultag> lfaraone: is it safe to pull the 5 to 7?
[20:06] <lfaraone> paultag: we have not uploaded it anywhere important, so yes.
[20:06] <paultag> OK
[20:06] <lfaraone> paultag: where did you get that warning?
[20:07] <paultag> lfaraone: in my dsc build. my pbuild failed, so I'm reviewing what went wrong
[20:17] <paultag> lfaraone: I really hate to bug you again, but I'm getting an error I'm not sure about
[20:17] <paultag> lfaraone: chmod: cannot access `/tmp/buildd/fluxbox-1.1.1+git20100807.0cc08f9/./configure': No such file or directory
[20:17] <paultag> lfaraone: I can paste the pbuilder log if that might help
[20:19] <lfaraone> paultag: I'm not a pbuilder wiz, but ask and maybe someone here can help.
[20:19] <paultag> Let me run it one more time catching stderr
[20:20] <paultag> Oh, wait
[20:20] <paultag> I think I know why
[20:38] <paultag> lfaraone: I'm having issues. can I email you when it's all set?
[20:40] <lfaraone> paultag: sure.
[20:40] <paultag> lfaraone: thanks, stupid build issues plus a long day of writing stupid code
[20:41] <paultag> lfaraone: thanks so much
[20:41] <lfaraone> paultag: no sweat.
[20:49] <fabrice_sp> what is the status of the sugar packages? Do we keep 0.86 and 0.84 packages or only 0.86?
[20:50] <fabrice_sp> it's for bug 616444
[21:14] <bdrung> micahg: because the sponsors assign the bug to themself before beginning sponsoring
[21:29] <micahg> bdrung: k, but why unassign?
[21:32] <Laney> because it's no longer their task to work on
[21:33] <bdrung> micahg: ^ and because only one person can be assigned
[21:33] <ajmitch> morning
[21:33] <bdrung> micahg: and noone assigned means that it's ready for sponsoring. if someone is assigned it means that he/she is working on it
[21:33] <bdrung> good evening ajmitch
[21:34] <micahg> bdrung: yes, but if one is actually doing the sponsoring, why isn't that considered fixing the bug?
[21:35] <bdrung> micahg: hä? i don't get it.
[21:35] <bdrung> bug fixing and assigning are two different things
[21:36] <ajmitch> the person who fixed the bug is the person listed in debian/changelog, generally
[21:36] <micahg> ah, ok
[21:36] <ajmitch> having someone assigned is a way of saying that this bug is being looked at by a particular person, don't touch it
[21:37] <ajmitch> whether that be the bug fixer or the sponsor
[21:37] <ajmitch> just a short-term lock, nothing really meant by it afaik
[21:38] <bdrung> yeah, it's a spin-lock :)
[21:38]  * micahg will remember when sponsoring
[21:39] <yofel> someone got time to look at a SRU for lucid? bug 616498   (FTBFS fix)
[21:40]  * ajmitch would if his laptop wasn't being useless & thrashing after a resume
[21:40] <yofel> heh
[21:40] <Laney> ajmitch: no! work on U1 in Debian!
[21:40]  * Laney covers your eyes
[21:40] <ajmitch> I'll just join the club & blame the fglrx drivers :)
[21:40] <ajmitch> Laney: that requires the same laptop
[21:41] <Laney> sure does
[21:41] <ajmitch> since that's my only up-to-date sid install
[21:41] <ajmitch> you seem eager to have U1 in?
[21:42] <Laney> yeah I'd like it on my work PC
[21:42] <Laney> and from a development POV, to reduce deltas
[21:42] <ScottK> Seems a bit odd to see excitement about clients for proprietary web services.
[21:42] <Laney> I'm quite relaxed about those really
[21:42]  * Laney visits twitter.com
[21:43]  * ajmitch uses the notes syncing more than the file sync, and that's pretty much just couchdb replication
[21:43] <Laney> Tomboy Web could be tasty though
[21:43]  * Laney will use a decent Free option if one exists
[21:43] <ajmitch> I saw a suggestion to have a default note in tomboy?
[21:43] <Laney> yeah, some advertising
[21:44] <ajmitch> I know that in debian you do need to configure note sync manually (typing in a URL)
[21:44] <bdrung> yofel: i don't think that's worth a sru. there must a more important reason than "fixes TFBFS"
[21:44]  * ScottK considers adding adverts to a bunch of packages.
[21:45] <ScottK> bdrung: I don't agree with that.  Fixing FTBFS is a good reason for an SRU.  Particularly in an LTS it improves the supportability of the archive.
[21:45] <yofel> bdrung: thanks to gorm.app missing, gnustep-devel is uninstallable in lucid
[21:45] <ajmitch> bdrung: even though there's no binary package in lucid due to that FTBFS?
[21:45] <micahg> bdrung: I'd say that depends on the likelihood of needing a security update
[21:46] <micahg> s/say/suggest/
[21:46] <ScottK> In fact, when we did the removal of unbuildable binaries in Lucid, we explicitly said they were eligible to be restored as an SRU if the FTBFS was fixed.
[21:47]  * Laney has fixed at least one like that
[21:47] <Laney> p.s. I hope it didn't sound like approved of advertising changes or wanted them in Debian/anywhere
[21:47] <Laney> ;)
[21:47] <Laney> s/like/like I/
[21:48] <jdong> sagemath people still seem upset at us
[21:49] <jdong> I'm assuming it's impossible to remove software from released repos?
[21:49] <ajmitch> why are they upset?
[21:49] <micahg> jdong: upload an empty package?
[21:49] <jdong> ajmitch: we apparently took a snapshot from sid that was not release quality
[21:49] <jdong> (e.g. badly broken)
[21:49] <ari-tczew> jdong: hello! did you come back from holidays?
[21:50] <pindonga> fabrice_sp, a quick question, assuming configglue 0.9 gets into maverick in the next 30min, would the django-configglue package need anything else done to it?
[21:50] <bdrung> https://launchpad.net/ubuntu/+source/gorm.app/1.2.8-1 looked like there were a binary package.
[21:50] <jdong> and nobody figured this out until after it froze
[21:50] <pindonga> I'll have to leave in a while and I want to make sure everything is done so it gets included
[21:50] <micahg> jdong: sagemath isn't in lucid
[21:50] <ajmitch> jdong: so is it worth updating, or removing?
[21:50] <jdong> micahg: jaunty and karmic, sorry.
[21:50] <micahg> oh
[21:50] <ari-tczew> jdong: could you review one my SRU bug?
[21:50] <ajmitch> old old releases
[21:51] <fabrice_sp> pindonga, I haven't seen anything, but you need 2 acks before upload
[21:51] <micahg> jaunty is almost EOL :)
[21:51] <jdong> ajmitch: I'm asking the maintainer that right now
[21:51] <pindonga> ok, anybody else that want to volunteer to review django-configglue ?
[21:51] <pindonga> :D
[21:51] <fabrice_sp> :-)
[21:51] <ajmitch> pindonga: url?
[21:52] <pindonga> http://revu.ubuntuwire.com/details.py?upid=8519
[21:52] <pindonga> ajmitch, do you want the bug url?
[21:52]  * ajmitch knows python-configglue, so django-configglue should go with it :)
[21:52] <ajmitch> sure
[21:52] <pindonga> ajmitch, https://bugs.launchpad.net/bugs/616025
[21:52] <yofel> bdrung: there was the binary package from karmic that was copied over, but it was removed after the rebuld test showed that it fails to build
[21:53] <jdong> ari-tczew: is it uploaded to -proposed yet?
[21:53] <pindonga> ajmitch, yes, python-configglue is being updated for maverick as we speak
[21:53] <bdrung> yofel: ok. i might look after processing the sync requests
[21:53] <ajmitch> pindonga: yeah I was talking to chipaca about it last night, I've uploaded the previous version to debian
[21:53] <pindonga> django-configglue uses latest python-configglue
[21:53] <pindonga> ajmitch, cool,
[21:53] <ari-tczew> jdong: no, it's require review by SRU team first, right?
[21:53] <yofel> bdrung: thanks :)
[21:54] <ajmitch> ari-tczew: it's been recently clarified that they find it easier to review an uploaded package
[21:54] <ajmitch> the policy was never very clear on the order of things
[21:55] <ari-tczew> ajmitch: interested in uploading to -proposed?
[21:55] <ari-tczew> :>
[21:55] <jdong> ari-tczew: right, as ajmitch said, I anounced a bit ago on -devel that after the SRU teams merged, it's now preferable to upload into the queue first, then review
[21:56] <ajmitch> ari-tczew: possibly, if someone else doesn't jump on it first :)
[21:56] <ari-tczew> ajmitch: you don't think which it's a simple!
[21:57] <ari-tczew> bug 464175
[21:57] <ajmitch> ari-tczew: sorry?
[21:58] <ari-tczew> ajmitch: ehkm, it's very simple SRU :) sorry for lack english
[21:58] <ajmitch> np :)
[21:59]  * ajmitch was about to ask where the debdiff was, until I saw the branches
[21:59] <Quintasan> Anyone knows if persia is on holidays or something?
[22:00]  * ari-tczew is looking also for persia
[22:00] <ajmitch> anyone else, feel free to grab that sru as well for sponsoring :)
[22:01] <bdrung> ajmitch: ping me once i have updated vlc and sponsored the sync requests. :)
[22:14] <pindonga> fabrice_sp, ajmitch , in case I don't get news word from Chipaca in the next 15 minutes, I will tell him to let you know when configglue reached maverick, so you can finish the review on django-configglue, ok?
[22:14] <ajmitch> pindonga: ok
[22:14] <pindonga> in case everything is ok, is there anything else on my side I should do?
[22:15] <ajmitch> at this point now
[22:15] <ajmitch> s/now/no/
[22:15] <fabrice_sp> pindonga, it's bed time for me. Sorry I'll check tomorrow morning
[22:15]  * ajmitch just needs to get time to sit down & look over it properly :)
[22:15] <ajmitch> it's only 9AM here, so I have a little bit of time
[22:15]  * fabrice_sp just needs to sleep :-)
[22:15] <pindonga> fabrice_sp, isn't today the deadline for maverick?
[22:16] <pindonga> if we still have time, I don't mind waiting a few days
[22:16] <pindonga> ok, Chipaca just told me configglue should be in maverick now
[22:16] <pindonga> just in time :)
[22:16] <fabrice_sp> If I remember correctly other cycles, freeze will happen tomorro morning
[22:16] <ajmitch> ok, I'll grab it (I need to stick 0.9 in debian anyway)
[22:17] <ajmitch> pindonga: is there any easy way to test django-configglue? :)
[22:17] <pindonga> ajmitch, once installed not really, as we are not including the test project in the deb file
[22:17] <pindonga> but if you grab the branch (or the source tar file)
[22:17] <ajmitch> is the test project public?
[22:17] <pindonga> yes
[22:18] <ajmitch> ok, that's good
[22:18] <pindonga> in the source tar file you should have the test project and a readme file on how to run the tests
[22:18] <ajmitch> just fetching now
[22:18] <fabrice_sp> pindonga, otherwise, you can find another sponsor. I really have to go now. Sorry
[22:18] <pindonga> fabrice_sp, ok, np. thanks
[22:18] <fabrice_sp> bye
[22:23] <ajmitch> pindonga: OK, I'll try & get this checked over in the next couple of hours - I've got a little bit of other stuff i need to do this morning as well :)
[22:23] <pindonga> ajmitch, I appreciate it
[22:24] <pindonga> do you think there is still time for it to get into maverick (assuming everything is ok)?
[22:25] <ajmitch> should be
[22:25] <pindonga> if you think there is a risk of it not getting included because another reviewer is required, would you mind requesting someone to look at it in addition to you?
[22:25] <ajmitch> otherwise freeze exceptions will be granted fairly readily if there's a good reason
[22:26] <pindonga> as I have to leave now, and won't be back for a couple of hours
[22:26] <pindonga> ajmitch, ok, thanks a lot
[22:26] <pindonga> I'll talk to you when I get back, or tomorrow
[22:26] <ajmitch> ok
[22:31]  * ajmitch really needs to get that dpkg backport tested & installed soon :)
[22:33] <jdong> there are days where I feel like my official job title is "coaster maker"
[22:33] <jdong> I hate optical drives
[22:34]  * micahg had that job for a while :)
[22:37]  * ajmitch wishes he could upgrade X
[22:37]  * Laney did earlier
[22:37] <shane2peru> I'm trying to help package a python app, It is all in the directory, and I created the deb with this: sudo dpkg-deb -b directory name.deb and it worked well, however the dev wants to be able to put files in the /home/$USER/app directory, how is this done?
[22:37]  * Laney dare not reboot
[22:37] <ajmitch> Laney: virtualbox-ose is holding me back
[22:38] <ajmitch> shane2peru: packages should never put files into home directories on installation
[22:39] <ajmitch> the app can place files there when run, but packages cannot
[22:39] <shane2peru> ajmitch, ok, this is a Bible application, with the ability to install other Bibles, or user material, like Sword does with .sword in the user directory, what is the proper way to do this?
[22:39] <ajmitch> the app should have a shared directory & per-user data directories
[22:39] <ajmitch> iirc sword would store bibles in /usr/share/sword or similar
[22:40] <shane2peru> ajmitch, so it would be better if the Bibles, and or user data were in /usr/share/bibleanalyzer then
[22:41] <shane2peru> it is a Bible app that is written in Python on windows, and is ported to Linux (specifically Ubuntu) but the dev is  in need of some help from a Linux guy, that is where I come in
[22:41] <ajmitch> yes, it would be better
[22:42] <ajmitch> also, you should never need to be using dpkg-deb to put together a binary package :)
[22:42] <bdrung> RainCT: ping
[22:42] <shane2peru> it is really odd to me, because there is no compiling necessary, I'm compiled apps, and that seems less odd to me then building a deb from a folder
[22:42] <RainCT> hi bdrung
[22:43] <shane2peru> ajmitch, ok, obviously I'm spilling out all my complete ignorance of this, what is the proper way to build a deb for a python app, and distribute it?
[22:43] <ajmitch> you need to make a source package which has the standard files (control, changelog, rules, etc) in a debian/ directory
[22:43] <ajmitch> the packaging guide has some good examples
[22:43] <ajmitch> if I can recall the URL :)
[22:44] <ajmitch> https://wiki.ubuntu.com/PackagingGuide/Complete
[22:44] <shane2peru> the dev didn't have a 64bit deb, so I started tinkering around, edited his control file to get the deb so that it would install on 64bit, because it is python, with no compiling, I don't know if it need to be architecture specific
[22:44] <Laney> it's best to get the *source* package and modify that
[22:45] <ajmitch> python packages like that should be created as architecture: all
[22:45] <RainCT> bdrung: what's up?
[22:45]  * bdrung shouldn't do too many thinks in parallel...
[22:45] <paultag> lfaraone: I have my stuff working. Should I email you again ( this is more of a ping then anything else ;) )
[22:46] <bdrung> RainCT: suspicious-source  license.
[22:46] <shane2peru> well, I don't know how he built his deb, but I extracted it and it was folders with the control files etc, I edited it to read all, and re-built the deb, which installed with no complaints on my 64bit setup
[22:46] <shane2peru> I also installed it on a 32bit setup, and it didn't complain
[22:46] <ajmitch> you extracted the binary package, no doubt
[22:47] <shane2peru> ajmitch, thanks for the link, I will read that, as I want to learn this to help him get his app out to Ubuntu,
[22:47] <bdrung> RainCT: do you allow relicensing the man page for it under the isc license?
[22:47] <shane2peru> right, I just right clicked the deb, and extracted, never done that before, apparently cli is ar or something of that, I'm not familiar with that.
[22:48] <paultag>  shane2peru ar x file.deb
[22:48] <RainCT> bdrung: Ah. Sure.
[22:48] <paultag> shane2peru: it's the old unix archive tool, and it was common at the time :)
[22:48] <shane2peru> paultag, right, I read that somewhere online.
[22:48] <paultag> shane2peru: in my younger years, I tried building a deb that way
[22:49] <paultag> it's hard
[22:49] <shane2peru> paultag, oh, with ar you mean, yeah, I could imagine.
[22:50] <shane2peru> one last question, with python type apps, you don't have to make configure and compile, is that correct?
[22:50] <shane2peru> actually it is wxpython
[22:50] <bdrung> RainCT: thanks. current change: http://pastebin.com/enCnWpbL the AUTHORS section is a little bit rough.
[22:50] <ajmitch> shane2peru: correct, they often have setup.py though
[22:50] <paultag> shane2peru: https://wiki.ubuntu.com/PackagingGuide/Complete
[22:50] <paultag> Oh shoot!
[22:51] <shane2peru> ajmitch, that is so odd for me, so then building a deb from the folders is the proper way to do that with python apps then?
[22:51] <paultag> That was going to be the python one
[22:51] <bdrung> RainCT: i failed to not mention my name twice
[22:51] <shane2peru> paultag, ohh, if there is a python specific link, I would love that!  Because seems as though they are not the same.
[22:51] <paultag> shane2peru: yeah, let me find it, I just lost it
[22:52] <ajmitch> shane2peru: you use tools like 'debuild' to build it from a source package, not using dpkg-deb
[22:52] <RainCT> bdrung: Heh.  «\fBsuspicious\-source\fP have been written by» -> «has been».  You may just remove my name from the manpage if you want.
[22:52] <paultag> shane2peru: https://wiki.ubuntu.com/PackagingGuide/Python
[22:52] <shane2peru> ajmitch, ok, thanks!!!  I will do some research on debuild later, I only ever used checkinstall before, and I don't think I can use that with a folder
[22:52] <shane2peru> paultag, thanks!!!
[22:53] <paultag> Sure, that guide is pretty complete
[22:53] <shane2peru> wonderfull!  Thanks guys, I'm sure I'll be back
[22:53] <bdrung> RainCT: is that really ok for you?
[22:53] <neeraj> I have requested sync of some packages which now I have found that will not work in maverick.
[22:54] <bdrung> neeraj: fix them ;)
[22:54] <neeraj> what will be the proper procedure for closing the bug
[22:54] <neeraj> bdrung, we have upgraded versions of those packages which will work :)
[22:55] <RainCT> bdrung: Yeah. What's left there, 5 lines? I can live with not getting mentioned for that ;)
[22:55] <bdrung> neeraj: are the not working version already synced?
[22:55] <neeraj> no, i filed a request today only
[22:55] <bdrung> RainCT: ~8 lines ;)
[22:56] <bdrung> neeraj: mark them as invalid and give a short reason for marking them invalid
[22:56] <bdrung> neeraj: which one are they? i am currently processing sync requests
[22:56] <neeraj> bdrung, Ok.  thanks :)
[22:57] <bdrung> neeraj: i just uploaded sugar-write-activity-0.86_70-1
[22:58] <neeraj> sugar-chat-activity-0.84
[22:58] <neeraj> bdrung,  LP Bug#616462
[22:59] <bdrung> neeraj: all other sync request of you are unaffected?
[23:00] <neeraj> bdrung, no. LP#616444 and Bug #616465 too.
[23:00] <neeraj> bdrung, rest are working properly to my best knowledge.
[23:25] <RainCT> bdrung: Oh, I've just seen you 'stole' my merge. Thanks :)              (manpages-de)
[23:25] <directhex> DktrKranz, is there any planned slowdown in debian NEW alongside the freeze?
[23:25] <ajmitch> apart from ftpmasters recovering from debconf? :)
[23:25] <bdrung> RainCT: :)
[23:26] <directhex> ajmitch, i don't know how many of them were at debconf. i make no assumptions of slacking, i merely ask if there's a plan to do other things in the short term
[23:26] <bdrung> RainCT: can i exchange it for vim?
[23:37] <norax> Hi
[23:39] <norax> If there is someone over there, just a question: Someone told me that when you submit a patch to launchpad you should subscribe to Ubuntu-Universe-Sponsors. Now it seems that this group is depreciated. Any alternative?
[23:39] <ScottK> norax: ubuntu-sponsors
[23:39] <norax> thank ScottK
[23:41] <micahg> hmm...I thought patches go through reviews and debdiffs go through sponsors
[23:42] <norax> well, I have submit a debdiff, but what is the difference?
[23:43] <micahg> norax: yeah, sponsors then, patches that are suggestions for fixing usually go through reviews that will attempt to upstream and make sure it works
[23:43] <micahg> debdiffs as tested fixes go through sponsors AFAIK
[23:50] <norax> hmmm, don't know. When I submit a patch, I create a debdiff and test it in my computer. I do not create a patch so other people can test and later create a debdiff to submit. I mean maybe I should subscribe just to reviews, and wait that it is tested from other people and later subscribe sponsors.