RFS: ampache (updated package)
Dear mentors, I am looking for a sponsor for the new version 3.5.1-2 of my package ampache. As explained in http://lists.debian.org/debian-devel/2009/10/msg00297.html the mentioned file have been patched to use mysql_real_escape_string(). This corrects a possible SQL injection vulnerability. It builds these binary packages: ampache- web-based audio file management system The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/ampache - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.5.1-2.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman signature.asc Description: This is a digitally signed message part
Re: RFS: ampache (updated package)
On Tue, Oct 20, 2009 at 12:35:55AM -0500, Charlie Smotherman wrote: Dear mentors, I am looking for a sponsor for the new version 3.5.1-2 of my package ampache. As explained in http://lists.debian.org/debian-devel/2009/10/msg00297.html the mentioned file have been patched to use mysql_real_escape_string(). This corrects a possible SQL injection vulnerability. It builds these binary packages: ampache- web-based audio file management system The package appears to be lintian clean. Uploaded. Thanks! In future check your packages with 'lintian -IE --pedantic *.changes' to catch minor issues. But the package looks good! :) Hauke signature.asc Description: Digital signature
Re: RFS: ampache (updated package)
On Tue, Oct 20, 2009 at 3:56 PM, Jan Hauke Rahm j...@debian.org wrote: In future check your packages with 'lintian -IE --pedantic *.changes' to catch minor issues. But the package looks good! :) Personally, I use this as it catches more things and gives more detail: lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: stx-btree
Quoting Ury Stankevich ury...@gmail.com: Dear mentors, Hi, I am looking for a sponsor for my package stx-btree. Package name: stx-btree Version : 0.8.3-2 Upstream Author : Timo Bingmann (Mail: tb a-with-circle idlebox dot net) URL : http://idlebox.net/2007/stx-btree/ License : LGPL 2.1 Section : libdevel It builds these binary packages: stx-btree-dev - b+tree implementation in c++ The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/stx-btree - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/stx-btree/stx-btree_0.8.3-2.dsc I would be glad if someone uploaded this package for me. Not a complete review, but just a list of flaws immediately hurting my eyes ;-): * your clean target does not work when Makefile is not present (dpkg-buildpackage starts with cleaning up first) * the binary package should be architecture: all, since no arch-dependent code is produced during build phase (pure templates, header-based, right?) * perhaps splitting a separate binary package (-doc) for documentation would be nice, since its size is somehow large enough to justify its creation. For reference you could have a look at libtut source package which is in Debian proper, yours is in the same boat. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ampache (updated package)
On Tue, Oct 20, 2009 at 04:07:27PM +0800, Paul Wise wrote: On Tue, Oct 20, 2009 at 3:56 PM, Jan Hauke Rahm j...@debian.org wrote: In future check your packages with 'lintian -IE --pedantic *.changes' to catch minor issues. But the package looks good! :) Personally, I use this as it catches more things and gives more detail: lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color Oh, didn't notice lintian knows color, yet. :) Thanks for the hint! Hauke signature.asc Description: Digital signature
Re: RFS: stda
On Mon, 19 Oct 2009, Jan Hauke Rahm wrote: [..] Good job! Uploaded. Keep me posted on updates if you want to; otherwise everyone else on this list will be pleased to help out, I guess. :) Hauke Thanks a lot for the sponsoring and for your support. Dimitar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Convenience copies in upstream code: dependencies, removal, copyright, and other issues
Howdy all, I recall this discussion occurring a few times, but I'm not sure of the recommended best practice. We can all agree that “convenience copies” of third-party library code are to be avoided, and to work with upstream to remove them where feasible. What I'm not clear on are the details of dealing with it in the interim: * Declare dependencies on the version of the library in Debian, even though that version may be later than the convenience copy currently in the original source? * Remove the convenience copy from the original source archive, or merely from the binary package? * Document the convenience copy in the dependent package's ‘copyright’, even if it doesn't appear in the binary package? -- \ “The most common of all follies is to believe passionately in | `\the palpably not true. It is the chief occupation of mankind.” | _o__)—Henry L. Mencken | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues
Ben Finney wrote: * Declare dependencies on the version of the library in Debian, even though that version may be later than the convenience copy currently in the original source? Section 4.1.3 of Debian policy says If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. That seems to be a yes, or a yes + update the library, at least as a best practice. * Remove the convenience copy from the original source archive, or merely from the binary package? IMHO, it depends. If the code is dfsg free and not too big, don't bother to repack. * Document the convenience copy in the dependent package's ‘copyright’, even if it doesn't appear in the binary package? I thought everything in the source package should be documented in debian/copyright? At least, this seems to be what the ftp-masters expect, based on some recent email exchanges I have read. Sorry no references, but maybe check the pkg-perl or debian-science archives. d -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: redis (updated package)
Dear mentors, I am looking for a sponsor for the new version 1:1.01-1~bpo50+1 of my package redis. It builds these binary packages: erlang-redis - Persistent key-value database with network interface (Erlang clie libphp-redis - Persistent key-value database with network interface (PHP client libredis-perl - Persistent key-value database with network interface (Perl client python-redis - Persistent key-value database with network interface (Python clie redis-doc - Persistent key-value database with network interface (Documentati redis-server - Persistent key-value database with network interface The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/redis - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/redis/redis_1.01-1~bpo50+1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Rodolphe Quiédeville - Artisan Logiciel Libre http://rodolphe.quiedeville.org/ Travaillons Libre - http://fr.lolix.org/ signature.asc Description: OpenPGP digital signature
Re: RFS: ampache (updated package)
On Tue, 2009-10-20 at 09:56 +0200, Jan Hauke Rahm wrote: On Tue, Oct 20, 2009 at 12:35:55AM -0500, Charlie Smotherman wrote: Dear mentors, I am looking for a sponsor for the new version 3.5.1-2 of my package ampache. As explained in http://lists.debian.org/debian-devel/2009/10/msg00297.html the mentioned file have been patched to use mysql_real_escape_string(). This corrects a possible SQL injection vulnerability. It builds these binary packages: ampache- web-based audio file management system The package appears to be lintian clean. Uploaded. Thanks! In future check your packages with 'lintian -IE --pedantic *.changes' to catch minor issues. But the package looks good! :) Hauke Thank you for the upload, and the lintian hint :) Charlie signature.asc Description: This is a digitally signed message part
Re: RFS: ampache (updated package)
On Tue, Oct 20 2009, Paul Wise wrote: On Tue, Oct 20, 2009 at 3:56 PM, Jan Hauke Rahm j...@debian.org wrote: In future check your packages with 'lintian -IE --pedantic *.changes' to catch minor issues. But the package looks good! :) Personally, I use this as it catches more things and gives more detail: lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color I find that experimental and pedantic add far too much irrelevant chatter, and that it tends to mask the problems one should actually fix. manoj -- Deprive a mirror of its silver and even the Czar won't see his face. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues
On Tue, 2009-10-20 at 20:48 +1100, Ben Finney wrote: Howdy all, I recall this discussion occurring a few times, but I'm not sure of the recommended best practice. We can all agree that “convenience copies” of third-party library code are to be avoided, and to work with upstream to remove them where feasible. What I'm not clear on are the details of dealing with it in the interim: * Declare dependencies on the version of the library in Debian, even though that version may be later than the convenience copy currently in the original source? Yes, and possibly patch your program to work with the new version. Note that it is a policy 'should', so if that is too hard eventually you could link with the convenience copy while upstream works at it, provided you notify the security team of the fact (and possibly leaving your package out of testing). * Remove the convenience copy from the original source archive, or merely from the binary package? I would say merely from the binary package but... * Document the convenience copy in the dependent package's ‘copyright’, even if it doesn't appear in the binary package? ftpmasters seem to be requiring everything in the source to be documented in debian/copyright (really annoying, I know). If the library copied is large enough, it might be easier to repack instead of documenting it. Specially if it is not the same version as the package in Debian. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: sandboxgamemaker
Dear mentors, I am looking for a sponsor for my package sandboxgamemaker. * Package name: sandboxgamemaker Version : 2.4-1 Upstream Author : Platinum Arts, LLC * URL : http://sandboxgamemaker.com/ * License : Custom, open-source, I have written permission to package, non-free since author is concerned about it being used to make commercial games and thus puts some extra requirements in the license. Some of the user-generated content that is included with the package also has non-commercial clauses. Section : non-free/games This is developed as educational software for children. Users can develop their own high-quality 3D RPG, FPS, or film their own movie using their created world and models from inside the game. It also allows co-operative editing by running a editing server on your machine that allows other clients on the network (or internet) to connect to you so you can create games with your friends. This package includes the binaries for the client, server, and several user generated-content packages and tutorials. The authors have received some good press from teaching conferences and publications and are working to get sadnbox used in more classrooms and educational programs. They really would like to see this in Debian and it's derivatives. See their you-tube channel: http://www.youtube.com/PlatinumArtsKids , lots of demos and some interviews with the authors. It builds these binary packages: sandboxgamemaker - Standalone 3D Game Maker and 3D Game Design program The package appears to be lintian clean. The upload would fix these bugs: 551000 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/non-free/s/sandboxgamemaker - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/non-free/s/sandboxgamemaker/sandboxgamemaker_2.4-1.dsc - The debian/ packaging is in VCS at: https://launchpad.net/sandboxgamemaker-debian I would be glad if someone uploaded this package for me. Kind regards Scott Howard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ampache (updated package)
On Tue, Oct 20 2009, Paul Wise wrote: On Tue, Oct 20, 2009 at 3:56 PM, Jan Hauke Rahm j...@debian.org wrote: In future check your packages with 'lintian -IE --pedantic *.changes' to catch minor issues. But the package looks good! :) Personally, I use this as it catches more things and gives more detail: lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color I find that experimental and pedantic add far too much irrelevant chatter, and that it tends to mask the problems one should actually fix. Then split'em up and use on demand. For instance, use one shell alias for 'must fix these', when done use another one for 'pedantic' mode, if you like to, which should be enough to demask lintian reports. I think that experimenting with experimental/pedantic and eventually report results to BTS could help lintian developers to evaluate some information in advance about future infiltration and impact of these experimental checks, how useful, robust, or eventually boring they are, so they tweak the development heading according to the 'wind conditions'. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues
On Tue, 20 Oct 2009, Felipe Sateler wrote: ftpmasters seem to be requiring everything in the source to be documented in debian/copyright (really annoying, I know). This is because we don't only distribute the binaries; we also distribute the source. ftpmaster has to check all of this out anyway, and it makes it much easier on them if you've documented it properly. Don Armstrong -- If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ampache (updated package)
On Tue, Oct 20 2009, George Danchev wrote: On Tue, Oct 20 2009, Paul Wise wrote: On Tue, Oct 20, 2009 at 3:56 PM, Jan Hauke Rahm j...@debian.org wrote: In future check your packages with 'lintian -IE --pedantic *.changes' to catch minor issues. But the package looks good! :) Personally, I use this as it catches more things and gives more detail: lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color I find that experimental and pedantic add far too much irrelevant chatter, and that it tends to mask the problems one should actually fix. Then split'em up and use on demand. For instance, use one shell alias for 'must fix these', when done use another one for 'pedantic' mode, if you like to, which should be enough to demask lintian reports. I think that experimenting with experimental/pedantic and eventually report results to BTS could help lintian developers to evaluate some information in advance about future infiltration and impact of these experimental checks, how useful, robust, or eventually boring they are, so they tweak the development heading according to the 'wind conditions'. If you want to help improve lintian, sure. If you have the experience and the patience, that is great. But suggesting it to a bunch of novices trying to learn how to create packages might notbe the best advice -- the experimental stuff is not something that is necessarily things that ought to be fixed in the first place, and the -I stuff is debatable. If you are learning how to package stuff, concentrate on things you _do_ need to fix. Move on to helping fix lintian once you are comfortable with packaging, and have developed some judgment about where lintian ought to be heading. manoj -- The more control, the more that requires control. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ampache (updated package)
On Tue, Oct 20, 2009 at 02:28:09PM -0500, Manoj Srivastava wrote: On Tue, Oct 20 2009, George Danchev wrote: On Tue, Oct 20 2009, Paul Wise wrote: On Tue, Oct 20, 2009 at 3:56 PM, Jan Hauke Rahm j...@debian.org wrote: In future check your packages with 'lintian -IE --pedantic *.changes' to catch minor issues. But the package looks good! :) Personally, I use this as it catches more things and gives more detail: lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color I find that experimental and pedantic add far too much irrelevant chatter, and that it tends to mask the problems one should actually fix. Then split'em up and use on demand. For instance, use one shell alias for 'must fix these', when done use another one for 'pedantic' mode, if you like to, which should be enough to demask lintian reports. I think that experimenting with experimental/pedantic and eventually report results to BTS could help lintian developers to evaluate some information in advance about future infiltration and impact of these experimental checks, how useful, robust, or eventually boring they are, so they tweak the development heading according to the 'wind conditions'. If you want to help improve lintian, sure. If you have the experience and the patience, that is great. But suggesting it to a bunch of novices trying to learn how to create packages might notbe the best advice -- the experimental stuff is not something that is necessarily things that ought to be fixed in the first place, and the -I stuff is debatable. If you are learning how to package stuff, concentrate on things you _do_ need to fix. Move on to helping fix lintian once you are comfortable with packaging, and have developed some judgment about where lintian ought to be heading. As much as In understand your issue here, note that I suggested the experimental and pedantic test for a last check. I expect that a package is working (i.e. no FTBFS, installable, removable etc.) even before lintian is used at all. As a last stepbefore uploading a package I find -I -E --pedantic very appropriate. You catch common typos in descriptions, catch some should guidelines from policy etc. It's not like you have to fix it but if you can, all the better... Hauke signature.asc Description: Digital signature
RFS: tokyocabinet-ruby (try 2)
Dear mentors, I am looking for a sponsor for my package tokyocabinet-ruby. This is a second attempt lintian warning free. * Package name: tokyocabinet-ruby Version : 1.21-1 Upstream Author : Mikio Hirabayashi mi...@users.sourceforge.net * URL : http://1978th.net/tokyocabinet/ * License : GNU Lesser General Public Licence Section : libs It builds these binary packages: libtokyocabinet-ruby-doc - Ruby Binding of Tokyo Cabinet Database libtokyocabinet-ruby1.8 - Ruby Binding of Tokyo Cabinet Database libtokyocabinet-ruby1.9 - Ruby Binding of Tokyo Cabinet Database The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tokyocabinet-ruby - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tokyocabinet-ruby/tokyocabinet-ruby_1.21-1.dsc I would be glad if someone uploaded this package for me. Kind regards spk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: sandboxgamemaker
Scott Howard showard...@gmail.com writes: * License : Custom, open-source, I have written permission to package, non-free since author is concerned about it being used to make commercial games and thus puts some extra requirements in the license. Some of the user-generated content that is included with the package also has non-commercial clauses. This is incoherent. If the license terms restrict commercial redistribution, then the work is not open source (nor is it DFSG-free). Also, if *you* have written permission from the copyright holder to redistribute, be aware that this is effectively part of your license terms and needs to be documented verbatim in the package ‘copyright’. You'll also need to check whether it passes DFSG §8. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but if we give peas a chance, won't the lima beans feel | _o__)left out?” —_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: sandboxgamemaker
Ben, thank you for your comments: * License : Custom, open-source, I have written permission to package, non-free since author is concerned about it being used to make commercial games and thus puts some extra requirements in the license. Some of the user-generated content that is included with the package also has non-commercial clauses.Benn, Thank you for your comments: This is incoherent. If the license terms restrict commercial redistribution, then the work is not open source (nor is it DFSG-free). I'm sorry I was not precise with my language. My previous experience is with GNOME, so I'm still learning the importance of being precise, and which words to use. The legal issues have been discussed on the debian-legal mailing list: http://lists.debian.org/debian-legal/2009/10/msg00015.html The license does not explicitly bar commercial use nor restricts any endeavour, it just is a non-standard license. That is why I believe it should be non-free, since it isn't clear if they intend this to be DFSG-free nor have they explicitly said it in their license. I hope that inclusion in the non-free repository would let them see the benefits of adopting a more standard license that fits their needs to eventually get this into main in later releases. Also, if *you* have written permission from the copyright holder to redistribute, be aware that this is effectively part of your license terms and needs to be documented verbatim in the package ‘copyright’. You'll also need to check whether it passes DFSG §8. Thanks for the feedback, I will add the email correspondence to the debian/copyright. To quote their email in response to my asking for permission to package and distribute their software with Debian and to be available as an open source project, they responded, You have my permission, blessing and support. (There is more too it, which I will include in the copyright file). In fact, part of the reason they want it in Debian is so that it would be redistributed into Edubuntu with the same rights. Regards, Scott -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues
On Tue, 2009-10-20 at 12:05 -0700, Don Armstrong wrote: On Tue, 20 Oct 2009, Felipe Sateler wrote: ftpmasters seem to be requiring everything in the source to be documented in debian/copyright (really annoying, I know). This is because we don't only distribute the binaries; we also distribute the source. But the upstream source already has them (in the source files themselves or other files). The copyright file is for installation in the binary packages (as per my reading of policy 12.5). ftpmaster has to check all of this out anyway, and it makes it much easier on them if you've documented it properly. I don't see how including that info saves work for them since they check it anyways. It's probably only confusing if different than what is in the source. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ampache (updated package)
Hi Manoj, Manoj Srivastava wrote: [...] I find that experimental and pedantic add far too much irrelevant chatter, and that it tends to mask the problems one should actually fix. Could you please elaborate a bit more? I'd like to know how I can improve lintian so that it is more useful for others. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues
On Tue, Oct 20, 2009 at 5:48 AM, Ben Finney ben+deb...@benfinney.id.au wrote: * Remove the convenience copy from the original source archive, or merely from the binary package? Related question: Since the source package consists of orig.tar.gz and a .diff, how would one remove the convenience copy from the original source? The policy seems to speak only to *use* of the convenience copy, not exclusion. Removing it would seem to leave the original copy in the tarball, and a *second* copy (with a bunch of - in front) in the diff. This is for a case where the package will function without the convenience copy (it's optional functionality), and the convenience copy code is patent-encumbered (not truly Free, and thus better not to distribute at all) while the rest of the package is Free. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues
Le 21 oct. 09 à 11:03, Jonathan Niehof a écrit : On Tue, Oct 20, 2009 at 5:48 AM, Ben Finney ben+deb...@benfinney.id.au wrote: * Remove the convenience copy from the original source archive, or merely from the binary package? Related question: Since the source package consists of orig.tar.gz and a .diff, how would one remove the convenience copy from the original source? You would need to repack: unpack the tar.gz, remove the copy, re-tar. The policy seems to speak only to *use* of the convenience copy, not exclusion. That's why removing from the source is not necessary in the general case. It is advisable if the code is very large to avoid cluttering the archive with unused stuff, and necessary if the code is not free of poses other legal problems. [...] This is for a case where the package will function without the convenience copy (it's optional functionality), and the convenience copy code is patent-encumbered (not truly Free, and thus better not to distribute at all) while the rest of the package is Free. Then I would repack, although I know there are packages in the archive which include patent-encumbered code which is simply disabled in the binary. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
request for review: lbzip2-0.16rc1-1
Dear Mentors, I released a new upstream version of lbzip2. It is a beta (or release candidate). I refreshed the Debian package under [0], built in a sid pbuilder; lintian produced no warnings. lbzip2 (0.16rc1-1) unstable; urgency=low . * New upstream release (candidate): - (Mostly) bzip2-compatible command-line, e.g. settable compression block size, file operands etc. However, lbzip2 never deletes or overwrites files it didn't create. - Merged eglibc getconf bug workaround (patches/eglibc-getconf) from 0.15-2. * Changed the bzip2 filter program substring in the short description to bzip2 utility. * Adapted patches/man-inst-paths to new upstream manual page. I kindly request you to review it and upload it if appropriate. I'd be grateful if valiant squeeze users would be able and willing to test the RC, perhaps even as a bzip2 substitute. Thank you very much, lacos (deb-0_16rc1-1-try-01) [0] http://mentors.debian.net/debian/pool/main/l/lbzip2/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
