[gentoo-dev] Licenses
I'm trying to add app-admin/supervisor (http://supervisord.org/) to the tree, but its licensing situation kind of sucks. The file talks about 4 different licenses. 1: the Repoze license (which I added to the tree in anticipation of this ebuild) 2: a copy of the regular BSD license, should be straightforward 4: the ZPL, which we also have The third is this: Medusa was once distributed under a 'free for non-commercial use' license, but in May of 2000 Sam Rushing changed the license to be identical to the standard Python license at the time. The standard Python license has always applied to the core components of Medusa, this change just frees up the rest of the system, including the http server, ftp server, utilities, etc. Medusa is therefore under the following license: == Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Sam Rushing not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. SAM RUSHING DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL SAM RUSHING BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. == The bit between === and === is the PERMISSIONS AND DISCLAIMER STATEMENT from the CNRI license (which I think is the standard Python license 10 years ago), but the CNRI license explicitly names the CWI and Stichting Mathematisch Centrum (i.e. doesn't talk about Organization or Owner like some of the other licenses). Any clues on what to do with this would be greatly appreciated. Cheers, Dirkjan
Re: [gentoo-dev] Low hanging bug fruit patterns
On Tue, 9 Mar 2010 00:17:18 +0100 Jeroen Roovers j...@gentoo.org wrote: On Mon, 08 Mar 2010 14:13:30 +0100 Róbert Čerňanský hslis...@zoznam.sk wrote: - Minor version bumps (After examination what upstream changed and after confirmation with mantainer, if any.) The stuff you put in brackets is exactly the sort of stuff that tends to make version bumps hard to fix. You would first have to determine what major/minor means, on a per package-version basis, so these aren't really as trivial to fix as (non) package maintainer as a minor version change might suggest. Yes, one needs to be carefull when doing even minor version bump. And after examination of changes one can decide to do the bump or leave it because it looks too risky. I'm sure there are upstream releases that contains only bug fixes and it can be relatively easy determined by looking into NEWS, Changelog or similar files. After all, the examination should not exceed 1 day of effort (Sebastian wrote that it should not take days to fix). So if we say that 1 day is still less than days then I think it is plenty of time to examine upstream changes. But maybe 1 day is too much for low hanging fruits so let's say 2 hours is acceptable. In that time it should be possible to fully examine changes. Which means read the changelogs, do some internet search (upstream and other distros bugzillas) and even take a peek to the source code. Also, any version bump is a splendid occasion on which to revise the ebuild (introduce missing features, check for novel QA issues, move up an EAPI to cut out a few build phases, review COPYING to make sure the LICENSE variable is still OK, figure out that one slight syntax change might serve to fix a compilation error with a newer-toolchain-than-you-use). It still can be done at another time after bump; which is maybe even better because it could be easily distinguished whether potencial new bugs were caused by the bump or by ebuild enhancement changes. Also I think that the overall quality of a package is increased if it is just bumped to the new minor/bugfix upstream release and ebuild stays at the same quality level as before. Compared to staying at the older upstream version and also with the same ebuild because nobody has time to do bump with ebuild enhacement. So I generally don't regard a version bump as a low hanging fruit, as you might end up painfully ignoring the wasps' nest hanging directly beside it. Cenrtailny not in general. So let's say it is low hanging fruit at which you have to stare for a while and look at it from all sides before you pick it up. ;-) Robert -- Robert Cernansky E-mail: hslis...@zoznam.sk Jabber: h...@jabber.sk
[gentoo-dev] Lastrite: net-voip/wengophone-bin
# Mounir Lamouri volk...@gentoo.org (09 Mar 2010) # net-voip/wengophone-bin has been superseeded by net-im/qutecom # and suffers of QA issues, see bug 251575 # Masked for removal in 30 days net-voip/wengophone-bin
[gentoo-dev] Re: Low hanging bug fruit patterns
Jeroen Roovers posted on Tue, 09 Mar 2010 00:17:18 +0100 as excerpted: I generally don't regard a version bump as a low hanging fruit, as you might end up painfully ignoring the wasps' nest hanging directly beside it. FWIW, that's definitely sig/fortune material! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] The feature patch mess in the webalizer ebuild (and how to deal with it)
Hello! Intro = The latest version of webalizer is 2.01 while upstream is at 2.21 by now. The reason it's not been bumped in Gentoo is the two use flags geoip and xtended. The former alone pulls in a feature patch called geolizer, while the latter pulls a feature patch called webalizer xtended, either with or without geoip support. Problem === Both of these patches have not been updated for quite some time. To bump webalizer we would either need fresh version of both patches or drop what's out of date which breaks the use flags. geoip support is included in webalizer itself by now. Still, geoalizer added a bit more than that: human-readable byte units might still be missing. With weblizer xtended if may be similar, at least that's my guess. The real problem is that we have an ebuild depending on feature patches. Even if we had updated patches by now it were a question of time only until the symptoms return. Solution 1) Add two new packages to the tree: - app-admin/geolizer (/usr/bin/geolizer) - app-admin/webalizer-xtended (/usr/bin/webalizer-xtended) 2) Bump webalizer to 2.21 while - no longer applying either feature patch - removing use flag xtended - keeping now hollow use flag geoip to reduce breakage 3) Close related bug 231859 https://bugs.gentoo.org/show_bug.cgi?id=231859 I volunteer to do that. Any objections or suggestions? Side note = If anyone feels like playing around with merging changes from webalizer into geolizer (and maybe geolizer-based webalizer xtended) he is welcome to do that on top a dedicated Git repository for it: http://git.goodpoint.de/?p=webalizer.git;a=summary Contact me if that sounds like a job for you. Geolizer upstream is more likely to migrate anytime soon, so checking back with Stanislaw Pusep again before would be good. Sebastian
[gentoo-dev] webapp-config needs a new maintainer
Hello! There are quite a few bugs open for it plus the latest version (1.50.18) is not even in Gentoo but on SourceForge only. Its upstream Gunnar left Gentoo due to lack of time recently. As I got project admin rights for layman from Gunnar before I know that a similar thing should be theoretical possible for you and webapp-config, too. So your first task would be a proper bump and a maybe few bug fixes after: http://sourceforge.net/projects/webapp-config/files/ https://bugs.gentoo.org/buglist.cgi?quicksearch=webapp-config I know there's people using this tool. If you use it this is your chance to ensure it keeps in good shape. Being proxied or mentored initially should also work in case you want that. Thanks, Sebastian
[gentoo-dev] How about a monthly bumpday?
Hello! We have about 500 bump request open at the moment: https://bugs.gentoo.org/buglist.cgi?quicksearch=bump I assume that quite a few of them would be no big deal to their maintainers in Gentoo. Bugday is occupying the first Saturday of the month: how about bumpday on the third Saturday of the month? First bumpday could be March 20th, 10 days from now. What do you think? Sebastian
Re: [gentoo-dev] How about a monthly bumpday?
On 09/03/10 22:08, Sebastian Pipping wrote: Hello! We have about 500 bump request open at the moment: https://bugs.gentoo.org/buglist.cgi?quicksearch=bump I assume that quite a few of them would be no big deal to their maintainers in Gentoo. Bugday is occupying the first Saturday of the month: how about bumpday on the third Saturday of the month? First bumpday could be March 20th, 10 days from now. What do you think? Sebastian Not sure that my opinion matters all that much as I'm not currently doing ebuild work, but I think this idea could really help out the status of the tree. Attached to it could be a stabilisation day as well. --Nathan Zachary
Re: [gentoo-dev] How about a monthly bumpday?
On Tue, 09 Mar 2010 22:32:22 -0600 Nathan Zachary nathanzach...@gentoo.org wrote: On 09/03/10 22:08, Sebastian Pipping wrote: Hello! We have about 500 bump request open at the moment: https://bugs.gentoo.org/buglist.cgi?quicksearch=bump I assume that quite a few of them would be no big deal to their maintainers in Gentoo. Bugday is occupying the first Saturday of the month: how about bumpday on the third Saturday of the month? First bumpday could be March 20th, 10 days from now. What do you think? Sebastian Not sure that my opinion matters all that much as I'm not currently doing ebuild work, but I think this idea could really help out the status of the tree. Attached to it could be a stabilisation day as well. --Nathan Zachary The ones that I'm CCed on, either as proxy maintainer or because I have some other interest, I prolly would mind. They're not simple revbumps, but they have dependency changes and/or other complicated changes, which is the only reason why they're still open. My bugs can't be solved with a simple rename-and-commit. I'm prolly not the only one who feels this way, so you really need to pick your bugs carefully! Otherwise we'll end up with another screwed-up mess like the one we just went through with patrick. Bumpdays are otherwise a good idea, though I'm not sure why we need a separate day for that in addition to our standard bugdays. signature.asc Description: PGP signature
Re: [gentoo-dev] How about a monthly bumpday?
On 03/10/10 06:00, Joshua Saddler wrote: I'm prolly not the only one who feels this way, so you really need to pick your bugs carefully! Agreed, yes. Bumpdays are otherwise a good idea, though I'm not sure why we need a separate day for that in addition to our standard bugdays. While bugday is also meant to activate developers it's primarily focused on users fixing bugs, making them able to do that and doing proxy commits. I guess a developer doing the bump himself is much faster than waiting for and working with a user on that. It would help to teach users but it would work against the goal of getting all the bump requests closed. Also, another day means one more day a month with people working on Gentoo theoretically. Sebastian
Re: [gentoo-dev] webapp-config needs a new maintainer
Hi, On 2010-03-10 11:30, Sebastian Pipping wrote: There are quite a few bugs open for it plus the latest version (1.50.18) is not even in Gentoo but on SourceForge only. Its upstream Gunnar left Gentoo due to lack of time recently. As I got project admin rights for layman from Gunnar before I know that a similar thing should be theoretical possible for you and webapp-config, too. So your first task would be a proper bump and a maybe few bug fixes after: http://sourceforge.net/projects/webapp-config/files/ https://bugs.gentoo.org/buglist.cgi?quicksearch=webapp-config I know there's people using this tool. If you use it this is your chance to ensure it keeps in good shape. Being proxied or mentored initially should also work in case you want that. I'm using webapp-config on multiple servers, and I think it's an important part of Gentoo, as it provides a sane way to keep track of web applications. I see a problem though: the ebuilds of popular webapps like MediaWiki or Wordpress seem to be in bad shape / unmaintained, which in term makes this tool much less useful. Maybe that is caused by the fact, that webapp-config has bugs? Chicken/Egg problem? So, I wish there could be more people taking care of timely version bumps etc. for webapps, since it is essential that webapps are always kept up-to-date, most of them being written in PHP, buggy, exposed to the net and all. Anyway, I can imagine working on webapp-config, and becoming a Gentoo package maintainer. My time is a little limited though (day job + part time job + family), so don't expect too much. If there is someone with more time on his/her hands, please go for it. Patrick. -- Key ID: 0x86E346D4http://patrick-nagel.net/key.asc Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] webapp-config needs a new maintainer
Hi! On Wed, Mar 10, 2010 at 4:30 AM, Sebastian Pipping sp...@gentoo.org wrote: There are quite a few bugs open for it plus the latest version (1.50.18) is not even in Gentoo but on SourceForge only. The release on sourceforge is not compatible with the current implementation in Gentoo AFAIK. So your first task would be a proper bump and a maybe few bug fixes after: webapp-config is in a horrible shape and also has several design flaws. i wouldn't touch it. that's why i already added an idea to the GSoC list for a complete w-c rewrite. i talked to gunnar in 2008 or 2009 at chemnitz linux days, and we agreed that w-c needs a rewrite. but none of us had/has time to do it. hopefully gsoc can change this situation. Greetings, Bene
Re: [gentoo-dev] The feature patch mess in the webalizer ebuild (and how to deal with it)
On Wed, Mar 10, 2010 at 3:43 AM, Sebastian Pipping sp...@gentoo.org wrote: Solution 1) Add two new packages to the tree: - app-admin/geolizer (/usr/bin/geolizer) - app-admin/webalizer-xtended (/usr/bin/webalizer-xtended) 2) Bump webalizer to 2.21 while - no longer applying either feature patch - removing use flag xtended - keeping now hollow use flag geoip to reduce breakage 3) Close related bug 231859 https://bugs.gentoo.org/show_bug.cgi?id=231859 +1. please do it. and please help out the web-apps herd in the future if you have the time. the herd really needs some love ;-)
