[00:28] 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] isleshocky77: try #ubuntu-packaging [03:46] if I'm doing a new upstream release, is it worth merging from Debian? [03:46] 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] 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] rhpot1991: is it a free license? [04:02] micahg: http://www.gnu.org/philosophy/apsl.html [04:02] 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] Of course GNU considers GFDL invariant a free license, so I wouldn't take their opinion as counting for much. [05:27] Heh. === freeflyi1g is now known as freeflying [07:02] Yay! rockstar uploaded a package of Tahoe-LAFS 1.7.1 for Ubuntu! [07:02] Anybody want to test it out? [07:06] Hello [07:54] Why did M-o-M has to go down just before FF ? [08:11] good morning [08:20] Who sponsored Tahoe-LAFS v1.7.1 to go into Maverick just now? [08:20] (I want to thank them on the tahoe-lafs mailing list.) [08:24] zooko: https://edge.launchpad.net/ubuntu/+source/tahoe-lafs/1.7.1-0ubuntu1 [08:25] Thanks! [08:25] Thanks, maco [08:26] Good night, folks (UTC-6) [08:42] dholbach: Hello [08:44] hey AnAnt, sabah il cheer [08:49] dholbach: I think you meant: kheer [08:50] AnAnt: that could well be :) [09:59] Rhonda: does your offer for that git session still stand? :) [10:00] I hope so, but I don't have much time to prepare it properly. %-( [10:01] Didn't sleep much this night neither, your young one wasn't working along. [10:01] Rhonda: next week thursday? [10:05] wow, git session. Now that totally rocks :) [10:15] * Rhonda cries [10:19] * X3 throws Rhonda a chocolate tnafish [10:47] it'd also have to ch [10:47] grr, excuse that === yofel_ is now known as yofel === didrocks1 is now known as didrocks [12:46] hi, I would like to seek sponsoring for bug #616025 [12:46] Launchpad bug 616025 in django-configglue "needs packaging" [Undecided,New] https://launchpad.net/bugs/616025 [12:46] anyone iinterested? [12:47] looking [12:51] pindonga: in copyright file, upstream source can be https://launchpad.net/django-configglue [12:51] ok, [12:53] also from upstream LICENSE file, it seems the copyright holder is Canonical Ltd., not Canonical ISD hackers [12:54] pindonga: ^ that is for the Copyright field [12:54] pindonga: the License field machine readable format copyright would be as follows: [12:55] License: LGPL-3 [12:55] the License was like that but lintian complained I wasn't referring to the common licenses [12:55] Copyright: 2010 Canonical Ltd. would be ok? [12:56] followed by the disclaimer [12:56] as for Copyright: 2010, Canonical Ltd. [12:56] and you may even add a URL [12:57] for example. Copyright: 2010, Canonical Ltd. (http://www.canonical.com) [12:57] back to License [12:58] have a look at gst123 copyright file for example [12:58] http://packages.debian.org/changelogs/pool/main/g/gst123/gst123_0.1.2-1/gst123.copyright [12:59] is this tarball a repackage ? [13:00] this would be the first package for ubuntu [13:00] we had some previous packages in our own ppa for custom deployments [13:00] but in those we never bothered to get the package right [13:01] I mean, no upstream tarballs released ? [13:03] not yet, but I can do that if its needed [13:03] I'm not sure about that, but it seems to me that you removed the non-free icons, right ? [13:03] mhhh [13:04] actually I think the disclaimer in the license is wrong [13:04] (I copied this from another project we opensourced) [13:04] this one doesn't have any images or icons [13:04] the disclaimer is in the LICENSE & the LP page [13:04] from LP: Commercial subscription expires 2020-12-09 [13:05] this was an internal project first, and now I changed the license to LGPL3 as we were allowed to opensource [13:05] I don't know why the "internal project" and "commercial subscription" did stick around [13:06] ok, maybe that should be changed upstream [13:06] ok, so, let's recap please. I need to [13:06] a) change the License field [13:06] b) add a Dsiclaimer field [13:06] c) change the Copyright field [13:06] d) change the Upstream-Source field [13:07] e) publish an upstream source tarball [13:07] f) fix the LP project status [13:07] not a Disclaimer field, it is just a paragraph under License field, have a look at the example I gave you pleas [13:07] g) fix the lincese disclaimer [13:07] ah, ok [13:07] I'm not sure if it is required to publish upstream source tarball, but that would be useful for other distros anyways [13:08] as for f) what matters is fixing the LICENSE file in upstream tarball [13:08] but it would be rational to also fix the description in LP page [13:09] oh, you mentioned it in g) already ! [13:09] ok, h) there is a generated patch [13:09] you can avoid that by removing the generated files in clean target [13:10] I dunno how that is done with CDBS [13:10] where do you see the patch? [13:10] debian/patches/debian-changes-0.3-0ubuntu1 [13:10] k [13:10] I'll look into it [13:10] ok [13:16] pindonga: in the control file, you can drop XB-Python-Version field [14:19] AnAnt, I just reuploaded the package, can you please give it another look? === AnAnt_ is now known as AnAnt [14:26] hi AnAnt , in case you didn't see my previous message [14:26] pindonga> AnAnt, I just reuploaded the package, can you please give it another look? [14:26] (I noticed you had a connectivity hickup) [14:26] :) [14:31] 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] pindonga: what commercial support ? [14:32] pindonga: the only issue was with this: [14:32] in the license (in the launchpad page) [14:32] we had 'internal project' [14:32] The image and icon files in django-configglue are copyright Canonical, [14:33] and unlike the source code they are not licensed under the [14:33] LGPLv3. Canonical grants you the right to use them for testing and [14:33] development purposes only, but not to use them in production (commercially or [14:33] non-commercially). [14:33] ok, that I removed [14:33] pindonga: you were talking about the LP page ? [14:33] yeah, don't worry [14:34] ok [14:34] just let me know if there is anything else I need to change on the package [14:34] please [14:36] pindonga: third-party copyright should be noted in debian/copyright [14:36] pindonga: so you'll need a section like [14:36] File: path/to/file [14:36] Copyright: year, holder [14:36] License: whatever [14:38] pindonga: also please run lintian on the changes file, it will give you some good pointers [14:39] I don't understand why the resulting deb file has python (<<2.7) dependency [14:40] pindonga: by the changes file, I mean the one resulting from building the binary package (not just _source.changes) [14:41] or just run lintian on the source & binary packages [14:41] AnAnt, sure, thanks [14:42] AnAnt: python dependancies like that are a result of a python helper [14:44] tumbleweed: he's using python-central, I dunno about it [14:45] I'm used to python-support [14:45] AnAnt: looking at th epackage now [14:45] thanks [14:45] brb [14:45] pindonga: python-support is more widely used :) [14:46] tumbleweed, I started off from another package :) is it important to use python-support instead of python-central? [14:47] 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] yes, I agree [14:47] more people know python-support, but both of them are slated to be replaced by dh_python2 [14:47] :/ [14:47] I'll try to make the next package use python-support [14:48] pindonga: practically speaking for this package, there's nothing really python-central specific [15:08] pindonga: full review on revu [15:17] tumbleweed: does debhelper compat level matter ? [15:18] 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] AnAnt: it doesn't matter, it's just a case of why use an old version... [15:19] tumbleweed: ok [15:21] I don't understand what third-party license is there [15:21] running licensecheck says that every file is copyrighted by Canonical [15:22] 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] and changed the license to LGPL? [15:25] http://launchpadlibrarian.net/53483722/buildlog_ubuntu-maverick-i386.epiphany-browser_2.30.2-1ubuntu5_FAILEDTOBUILD.txt.gz [15:25] Any idea what could cause this? [15:29] LucidFox: yeah, there was some discussion about this in -desktop yesterday [15:34] bdrung: why do sponsorships get the assignee unassigned? [15:39] 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] LucidFox: yeah an upload was done last night to change 1.0 to 1.1 [15:39] LucidFox: https://launchpad.net/ubuntu/maverick/+source/gir-repository/0.6.5-6ubuntu6 [15:40] AnAnt, tumbleweed I just uploaded a new version, can you please re-check? (I hope I got it all this time) [15:55] 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] pindonga: I added more review [15:56] ah, cool thanks [15:56] tumbleweed, a few things [15:57] pindonga: btw, does it work? :) [15:57] 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] 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] 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] 1. so, it shouldn't only say "Copyright: Canonical" [15:59] s/sources/changes/ [16:00] 2. instead of sying "given below" five the common-licenses path, then lintian knows you are doing the rgiht thing [16:00] I could be using a newer lintian... [16:00] I'm on lucid (maybe it's that?) [16:01] :q [16:01] also, lintian doesn't always spot all the problems that a human can :) [16:01] highvoltage: we try to make it, though :) [16:01] tumbleweed, what do you mean by 'the watch file doesn't work?' / how do you test that? [16:02] *nod* [16:02] pindonga: uscan --verbose --report [16:03] 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] pindonga: common-licences comes from debian [16:04] 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] zooko: thank rockstar. he did the packaging. i just sponsored it [16:05] I did. [16:05] He and I have some plans to get packaging of Tahoe-LAFS for Ubuntu more automated. [16:05] ok [16:06] 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] 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] (Unless someone reports a regression, security hole, or major bug.) [16:07] 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] The scheduled release date for 1.8.0 final is "approximately August 15". [16:10] Hm, I don't think I should cut the 1.8.0c2 test cycle short. [16:10] 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] 1. ask to include 1.8.0c2 into Maverick right now [16:11] 2. file a FFE for 1.8.0-final, on Sunday [16:11] 3. forget about it and wait til Maverick+1 [16:11] 4. other? [16:13] whoops gotta get ready for work. will check this IRC window soon... === fta_ is now known as fta [16:46] tumbleweed, what Standards-Version should I use? the one on lucid is 3.8.4 [16:56] tumbleweed, ok, I just pushed another version (please let me know when you looked at it) === fta_ is now known as fta [18:26] lfaraone: ping, I was told to talk with you :) [18:27] 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] 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] lfaraone: thanks! I'll do that right away. [18:29] 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] lfaraone: yes, I have removed quite a few other lintian issues, and did a few bugfixes, and other fixes [18:29] lfaraone: sure, no problem. I'll be online [18:30] lfaraone: no new features [18:30] anyone around that want to finish reviewing #616025? [18:37] 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] fabrice_sp, thanks, what do you mean by 'old value'? [18:38] it's not MOTU anymore [18:39] it's Ubuntu Developers [18:39] Standards-version should be 3.9.1 also for maverick [18:40] also, do you really need a build dependency on python ? [18:40] fabrice_sp, don't know, I think it was mentioned in the packaging guide [18:44] fabrice_sp, when I remove the python build dep, lintian complains (E: missing-python-build-dependency) [18:44] so I think I just leave it in there [18:46] because of distutils. it seems. ok [18:51] fabrice_sp, ok, just pushed a new revision [18:52] ok [19:03] paultag: ah, maco referred you to me. I'll have to talk to her about that :P [19:03] pindonga, the watch file get a newer version from launchpad [19:03] is it normal? [19:03] yes, I don't know why that is [19:04] lfaraone: he needed someone that could make uploads to debian AND ubuntu happen... ergo: you [19:04] ah, actually I think I need to replace the released source with the latest one [19:04] maco: thanks :P [19:06] lfaraone: haha [19:06] maco: by the way, when are you planning on leaving / returning from OLF? [19:06] dunno yet [19:06] * lfaraone has school that week. [19:07] lfaraone: one time deal. My DD / all my DD friends IRL are busy :( [19:07] lfaraone: come on by, it will be great, I'm in Ohio [19:07] lfaraone: this counts for beer debt [19:07] maco: friday after 3:01, monday before 8:19 :P [19:07] paultag: which you cant pay off til he turns 21 in 4 years? [19:07] Oh lawdy [19:07] paultag: right, I'll collect it in 4 years when I'm legal. [19:07] Sure thing. [19:07] lfaraone: or in one year in europe? [19:08] maco: I had my first legal drink @ 16 in Germany [19:08] maco: sure. you going to debconf bosnia? :) [19:08] :) [19:09] maco: did you hear about the ubucon we'll be doing on friday @ olf ? [19:10] maco: akgraner was nice enough to get the ball rolling with that, it should be a blast. [19:10] 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] if you notice it matched 0.3.0.1 and now it matches 0.3.0.3 while looking for 0.3 === fta_ is now known as fta [19:15] lfaraone: any issues you see so far? [19:15] fabrice_sp, if having a watchfile is optional, I'd go with removing it if it causes issues for approving the package [19:15] paultag: I'll let you know. [19:15] lfaraone: thanks :) [19:16] pindonga, I'd really prefer to have a working watch file :-) [19:17] 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] the download url is: http://edge.launchpad.net/django-configglue/trunk/0.3/\+download/django-configglue-0.3.tar.gz [19:17] paultag: is there a reason you're packaging a git snapshot? [19:18] uscan complains about 'Use of uninitialized value $filepattern...' [19:18] 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] lfaraone: it resultes in a much cleaner package imho. Is that wrong? [19:18] paultag: have attempts to get upstream to relese failed? [19:18] lfaraone: yes [19:18] lfaraone: I've tried over the last 4 months to get a .2 release, no luck [19:18] paultag: it's fine. you still have a tonne of patches though :) [19:19] haha, aye. I think the ones left are debian-isms [19:19] or ones upstream refuses [19:19] (well, only two, which is an improvement over the last version) [19:19] lfaraone: :) [19:20] 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] pindonga, this is because you have 2 times (.+) in your watch file [19:21] lfaraone: OK, I'll get that in the git.debian asap. Is it blocking this upload? [19:21] paultag: not per se, but I'll have to guess which repo etc oyu used so I can verify your tarball. [19:22] lfaraone: Ahha. git.fluxbox.org. I'll write the rule and get it in git.debian [19:22] pindonga, if you replace the first one with .*, it works === fta_ is now known as fta [19:25] fabrice_sp, cool, I'll just resubmit the package [19:25] thanks [19:27] 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] fabrice_sp, ok, I just pushed the update [19:33] 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] 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] paultag: if so, which? (I personally find it helpful to do "BASE_VERSION+gitDATE.REF" so there's no ambiguity. [19:33] lfaraone: yeah, I used the date of when I pulled [19:35] paultag: so you would want something like fluxbox-1.1.1+git20100805.0cc08f9, methinks === fta_ is now known as fta [19:35] lfaraone: will that work if the sha sum on the same day for the next revision is "less" then the current revision? [19:35] lfaraone: e.g. a f8 [19:36] paultag: No. But I'd expect you wouldn't be packaging two releases from the same day. [19:36] lfaraone: Very true [19:36] lfaraone: Should I change that, then? [19:37] 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] paultag: very yes. [19:37] paultag: it's important to have zero ambiguity about what version you're working with. [19:37] 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] lfaraone: OK. Let me fix that. [19:38] paultag: sure. I have a spare get-orig-source rule lying around, if you want it. [19:38] lfaraone: I'd love it [19:38] paultag: here's what I use for pianobar: http://bazaar.launchpad.net/~lfaraone/pianobar/debian/annotate/head:/debian/rules#L6 [19:39] which also supports tags, as a matter of fact. [19:39] lfaraone: Ahha, I see what you're doing. [19:40] that's a lot better then what I was writing [19:40] paultag: that code has been adopted, rehashed, converted to different VCSs, so I'm surprised I got it working myself :) [19:41] pindonga, the package is not installable in Maverick, because python-configglue (>= 0.9), but maverick has 02dev-0ubuntu2it's expecting [19:41] 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] python-configglue 0.9 should have been proposed for maverick already [19:42] let me check [19:42] paultag: uh, you do, the debian revision is at the end. [19:42] paultag: "fluxbox_1.1.1+git20100807-1" [19:42] Oh duh, my changelog [19:42] I was looking at my ls [19:43] lfaraone: I'm still just a programmer, sorry for the new-ish questions [19:43] pindonga, maverick still has 02dev [19:43] paultag: no worries. I'm only a packager. I'm still amazed anybody trusts me to upload anywhere, let alone Debian / Ubuntu :) [19:43] :P === fta_ is now known as fta [19:44] lfaraone: you're keeping me in-line :) [19:47] fabrice_sp, ok, I'm told they are updating maverick right now [19:47] I'll ping you back as soon as I have word that it reached maverick [19:47] ok [19:55] lfaraone: I'm trying a build now. I'll put it to mentors if it builds OK [19:56] paultag: mk. [19:59] lfaraone: seriously, thanks so much. You really just saved my day :) [20:02] paultag: I live to serve. [20:06] 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] lfaraone: is it safe to pull the 5 to 7? [20:06] paultag: we have not uploaded it anywhere important, so yes. [20:06] OK [20:06] paultag: where did you get that warning? [20:07] lfaraone: in my dsc build. my pbuild failed, so I'm reviewing what went wrong [20:17] lfaraone: I really hate to bug you again, but I'm getting an error I'm not sure about [20:17] lfaraone: chmod: cannot access `/tmp/buildd/fluxbox-1.1.1+git20100807.0cc08f9/./configure': No such file or directory [20:17] lfaraone: I can paste the pbuilder log if that might help [20:19] paultag: I'm not a pbuilder wiz, but ask and maybe someone here can help. [20:19] Let me run it one more time catching stderr [20:20] Oh, wait [20:20] I think I know why [20:38] lfaraone: I'm having issues. can I email you when it's all set? === fta_ is now known as fta [20:40] paultag: sure. [20:40] lfaraone: thanks, stupid build issues plus a long day of writing stupid code [20:41] lfaraone: thanks so much [20:41] paultag: no sweat. [20:49] what is the status of the sugar packages? Do we keep 0.86 and 0.84 packages or only 0.86? [20:50] it's for bug 616444 [20:50] Launchpad bug 616444 in Ubuntu "Sync sugar-read-activity-0.84 69-4 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/616444 === fta_ is now known as fta [21:14] micahg: because the sponsors assign the bug to themself before beginning sponsoring [21:29] bdrung: k, but why unassign? [21:32] because it's no longer their task to work on [21:33] micahg: ^ and because only one person can be assigned [21:33] morning [21:33] 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] good evening ajmitch [21:34] bdrung: yes, but if one is actually doing the sponsoring, why isn't that considered fixing the bug? [21:35] micahg: hä? i don't get it. [21:35] bug fixing and assigning are two different things [21:36] the person who fixed the bug is the person listed in debian/changelog, generally [21:36] ah, ok [21:36] 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] whether that be the bug fixer or the sponsor [21:37] just a short-term lock, nothing really meant by it afaik [21:38] yeah, it's a spin-lock :) [21:38] * micahg will remember when sponsoring [21:39] someone got time to look at a SRU for lucid? bug 616498 (FTBFS fix) [21:39] Launchpad bug 616498 in gorm.app (Ubuntu) "gorm.app FTBFS in lucid" [High,Fix released] https://launchpad.net/bugs/616498 [21:40] * ajmitch would if his laptop wasn't being useless & thrashing after a resume [21:40] heh [21:40] ajmitch: no! work on U1 in Debian! [21:40] * Laney covers your eyes [21:40] I'll just join the club & blame the fglrx drivers :) [21:40] Laney: that requires the same laptop [21:41] sure does [21:41] since that's my only up-to-date sid install [21:41] you seem eager to have U1 in? [21:42] yeah I'd like it on my work PC [21:42] and from a development POV, to reduce deltas [21:42] Seems a bit odd to see excitement about clients for proprietary web services. [21:42] 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] Tomboy Web could be tasty though [21:43] * Laney will use a decent Free option if one exists [21:43] I saw a suggestion to have a default note in tomboy? [21:43] yeah, some advertising [21:44] I know that in debian you do need to configure note sync manually (typing in a URL) [21:44] 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] 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] bdrung: thanks to gorm.app missing, gnustep-devel is uninstallable in lucid [21:45] bdrung: even though there's no binary package in lucid due to that FTBFS? [21:45] bdrung: I'd say that depends on the likelihood of needing a security update [21:46] s/say/suggest/ [21:46] 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] p.s. I hope it didn't sound like approved of advertising changes or wanted them in Debian/anywhere [21:47] ;) [21:47] s/like/like I/ [21:48] sagemath people still seem upset at us [21:49] I'm assuming it's impossible to remove software from released repos? [21:49] why are they upset? [21:49] jdong: upload an empty package? [21:49] ajmitch: we apparently took a snapshot from sid that was not release quality [21:49] (e.g. badly broken) [21:49] jdong: hello! did you come back from holidays? [21:50] 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] https://launchpad.net/ubuntu/+source/gorm.app/1.2.8-1 looked like there were a binary package. [21:50] and nobody figured this out until after it froze [21:50] I'll have to leave in a while and I want to make sure everything is done so it gets included [21:50] jdong: sagemath isn't in lucid [21:50] jdong: so is it worth updating, or removing? [21:50] micahg: jaunty and karmic, sorry. [21:50] oh [21:50] jdong: could you review one my SRU bug? [21:50] old old releases [21:51] pindonga, I haven't seen anything, but you need 2 acks before upload [21:51] jaunty is almost EOL :) [21:51] ajmitch: I'm asking the maintainer that right now [21:51] ok, anybody else that want to volunteer to review django-configglue ? [21:51] :D [21:51] :-) [21:51] pindonga: url? [21:52] http://revu.ubuntuwire.com/details.py?upid=8519 [21:52]