Re: fortify help
On Thu, Jun 28, 2012 at 10:06:02PM +0200, Salvo Tomaselli wrote: > but i always get: > W: plasma-widget-smooth-tasks: hardening-no-fortify-functions > usr/lib/kde4/plasma_applet_smooth-tasks.so As the extended tag description suggests, refer to http://bugs.debian.org/673112 for the discussion of false positives. -- WBR, wRAR signature.asc Description: Digital signature
Re: Improving our response to "duplicate" packages in Debian
Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : > - Don't immediately start complaining to the submitter of the ITP. Just let > the submitter devote his/her energy to packaging. I don’t think it is worthwile to let people devote their energy to packaging pet applications that will disappear in 2 years time when they find another one. We really need to find better ways to involve new users in core teams, and that means removing from our collective consciousness the idea that you come in Debian to package your new favorite piece of software. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1340954665.3646.280.camel@pi0307572
Re: Improving our response to "duplicate" packages in Debian
[Holger Levsen] > if thats true, I don't want any of my package maintainance jobs. can > you please fire me? You've been around awhile. If that is true, you should know how to RFA or orphan packages and/or retire from the Project. You should know by now that it isn't up to others to "fire" you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629081013.gb...@p12n.org
Re: Improving our response to "duplicate" packages in Debian
On Fri, Jun 29, 2012 at 05:28:45AM +, Bart Martens wrote: > I'm not convinced that the recent additions to the wiki page reflect consensus > in this debate. But I appreciate your attempt to summarize this debate on > that > wiki page. Maybe we should revert the recent changes on that wiki page until > there is a more explicit consensus in this debate. My impression is that > consensus is growing towards what Guus wrote. But this impression may be > colored by the fact that I happen to agree with what Guus wrote. Rather than revert, I'd suggest summarizing the positions where there isn't consensus. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629082237.GB30194@debian
Re: Improving our response to "duplicate" packages in Debian
On Fri, Jun 29, 2012 at 12:55:15AM -0600, Holger Levsen wrote: > On Donnerstag, 28. Juni 2012, Ben Finney wrote: > > It's part of the job of a (prospective) package maintainer to advocate > > for the package. > > what??? I don't see anything unreasonable about being able to articulate the reasons why a package should be part of Debian. I don't mean having to suffer a drawn out argument, but just being able to give the reasons why it's important for the software to be in Debian, what it does, and why it's sufficiently different from what we already have. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629084930.gb9...@codelibre.net
Re: Improving our response to "duplicate" packages in Debian
On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : > > - Don't immediately start complaining to the submitter of the ITP. Just let > > the submitter devote his/her energy to packaging. > > I don’t think it is worthwile to let people devote their energy to > packaging pet applications that will disappear in 2 years time when they > find another one. You or I may not think that but clearly the one who is doing the packaging thinks it is worthwile, and who know how many users there will be for the new package. Nobody knows beforehand if the application will last only a year or be there until the end of time. So we should not blame the new ITP for the already packaged pet applications that have since disappeared. > We really need to find better ways to involve new users in core teams, > and that means removing from our collective consciousness the idea that > you come in Debian to package your new favorite piece of software. I agree we can use more members in core teams, but complaining to a maintainer when he files an ITP is usually not a positive step in that direction. This person will not suddenly think, "hey, you are right, I shouldn't package this software which I thought was very useful, I should join the FTP masters instead!" Already the Debian website mentions lots of things people can do to improve Debian besides packaging, and I am sure they *are* being done. However, if there are core teams that are in desparate need of help, they should make this known somehow. Perhaps there should be a section in the Debian Project News listing teams in need of help, or in general, non-packaging tasks that need to be done. Adding (a link to) a list on http://www.debian.org/intro/help or similar pages might help too. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Improving our response to "duplicate" packages in Debian
On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > We really need to find better ways to involve new users in core teams, > and that means removing from our collective consciousness the idea that > you come in Debian to package your new favorite piece of software. Unfortunately different attitudes, skill sets and other things are required for packaging some software you have chosen for that yourself and for doing work for one of teams. -- WBR, wRAR signature.asc Description: Digital signature
Bug 679504: ITP: lazylpsolverlibs -- libraries that proxy function calls to commercial lp solvers
Package: wnpp Severity: wishlist Owner: Christophe-Marie Duquesne * Package name: lazylpsolverlibs Version : 0.1.44 Upstream Author : Christophe-Marie Duquesne * URL : https://code.google.com/p/lazylpsolverlibs/ * License : EPL Programming Lang: C Description : libraries that proxy function calls to commercial lp solvers Lazylpsolverlibs [1] is a set of libraries designed to make Coin-Osi [2] support commercial solvers without recompilation. Under the hood, it uses dlopen on the commercial libraries. Currently, the package for Coin-Osi (coinor-libosi-dev) cannot be used by people who use commercial solvers. This partly defeats the purpose of using a multi-solver interface. Adding lazylpsolverlibs in Debian and recompiling coinor-libosi-dev against it would solve this problem, thus this ITP. Thanks! [1]: http://code.google.com/p/lazylpsolverlibs/ [2]: https://projects.coin-or.org/Osi -- Christophe-Marie Duquesne -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAHLp1YkjWYmKMeo3zFGvza0iRb07mKxLkY=kfvmxpfzqkt7...@mail.gmail.com
Re: Improving our response to "duplicate" packages in Debian
I would go even 1 step further and seek from a perspective maintainer, especially a non-DD/DM, at least some assurance that it is not a fire-and-forget project for him (e.g. that he is using it extensively and planing to do so for the next X years) and that he is willing to put effort in proper maintenance of the package. ITP -> 1 upload -> X NMUs -> O is not that uncommon. IMHO if there is a strong personal motivation (i.e. active user) to get a package packaged, it might provide additional weight toward "accepting" the package to be part of Debian even if comparable alternatives exist. I wonder if we shouldn't seek extending an /usr/share/pyshared/reportbug/debbugs.py:521:itp_template = textwrap.dedent(u"""\ with some advocation/motivation fields to make our discussion (upon reaching the consensus if such could be reached) any fruitful ? On Fri, 29 Jun 2012, Roger Leigh wrote: > > > It's part of the job of a (prospective) package maintainer to advocate > > > for the package. > > what??? > I don't see anything unreasonable about being able to articulate the > reasons why a package should be part of Debian. I don't mean having > to suffer a drawn out argument, but just being able to give the > reasons why it's important for the software to be in Debian, what > it does, and why it's sufficiently different from what we already > have. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629161849.go5...@onerussian.com
Re: cross-build-essential
Simon McVittie writes: > On 28/06/12 10:17, Goswin von Brederlow wrote: >> Say I want to have the build-essential for i386 installed on amd64. >> I could install build-essential:i386, replacing gcc/g++:amd64 with >> gcc/g++:i386. Wouldn't that give me everything needed to cross-compile >> for i386? > > For evolutions of the same CPU family (i386 vs amd64, powerpc vs > powerpc64) this sort of works, but after you've installed gcc:i386, you > can't compile 64-bit code any more (until you reinstall gcc:amd64). That > means that in practice you use a chroot for 32-bit compilation, and if > you're doing that, it might as well be a purely i386 chroot that doesn't > use multiarch. > > For "real" cross-compiling - amd64 vs armel, say - you don't really want > to be running an armel gcc binary that emits armel machine code (which > is what gcc:armel is) under qemu emulation: it's technically possible, > but your build will be rather slow. What you want is an amd64 gcc binary > that emits armel machine code, which is what gcc-cross-armel:amd64 contains. > > S Obviously. That's why I refined the idea in the next lines. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87395e5bwl.fsf@frosties.localnet
Re: Improving our response to "duplicate" packages in Debian
On Fri, 29 Jun 2012, Josselin Mouette wrote: > I don’t think it is worthwile to let people devote their energy to > packaging pet applications that will disappear in 2 years time when they > find another one. +1 > We really need to find better ways to involve new users in core teams, +1 > and that means removing from our collective consciousness the idea that > you come in Debian to package your new favorite piece of software. -10 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629162040.gp5...@onerussian.com
Bug#679547: ITP: ben -- toolbox for Debian maintainers
Package: wnpp Severity: wishlist Owner: Mehdi Dogguy * Package name: ben Version : 0.6 Upstream Author : Mehdi Dogguy and Stéphane Glondu * URL : http://ben.debian.net/ * License : AGPL-3+ Programming Lang: C, OCaml Description : toolbox for Debian maintainers This is a collection of useful tools that Debian maintainers can use to make their packaging work easier. They all work with regular Debian package list files, and should be useful for Debian derivatives as well. This package ships a single executable, "ben", with the following subcommands: * download: download a set of package list files from a mirror * monitor: monitor the status of a set of packages across several architectures (useful for transitions) * query: query packages using their metadata (similar to grep-dctrl, but uses a dedicated query language) * tracker: frontend to multiple monitors -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629172121.30372.23030.reportbug@potassium
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
Am Freitag, den 29.06.2012, 19:21 +0200 schrieb Mehdi Dogguy: > Package: wnpp > Severity: wishlist > Owner: Mehdi Dogguy > > * Package name: ben > Version : 0.6 > Upstream Author : Mehdi Dogguy and Stéphane Glondu > * URL : http://ben.debian.net/ > * License : AGPL-3+ > Programming Lang: C, OCaml > Description : toolbox for Debian maintainers > > This is a collection of useful tools that Debian maintainers can use > to make their packaging work easier. They all work with regular > Debian package list files, and should be useful for Debian > derivatives as well. This package ships a single executable, "ben", > with the following subcommands: > * download: download a set of package list files from a mirror > * monitor: monitor the status of a set of packages across several > architectures (useful for transitions) > * query: query packages using their metadata (similar to grep-dctrl, > but uses a dedicated query language) > * tracker: frontend to multiple monitors What does ben stand for? Is this just a short name for me? ;) Would it be useful to have ben in devscripts instead of a separate package? -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On 29/06/12 19:36, Benjamin Drung wrote: What does ben stand for? Is this just a short name for me? ;) Very long story¹. :) Would it be useful to have ben in devscripts instead of a separate package? No. I beleive devscripts maintainers will not be happy as it requires OCaml and a few OCaml libs to build. It also builds an OCaml library that it is meant to grow considerably in future. I don't think it is a good idea to put it in devscripts. ¹: This has to do with "Britney". Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fedec83.5000...@dogguy.org
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On Fri, Jun 29, 2012 at 07:36:46PM +0200, Benjamin Drung wrote: > Am Freitag, den 29.06.2012, 19:21 +0200 schrieb Mehdi Dogguy: > > Package: wnpp > > Severity: wishlist > > Owner: Mehdi Dogguy > > > > * Package name: ben > > Version : 0.6 > > Upstream Author : Mehdi Dogguy and Stéphane Glondu > > * URL : http://ben.debian.net/ > > * License : AGPL-3+ > > Programming Lang: C, OCaml > > Description : toolbox for Debian maintainers > > > > This is a collection of useful tools that Debian maintainers can use > > to make their packaging work easier. They all work with regular > > Debian package list files, and should be useful for Debian > > derivatives as well. This package ships a single executable, "ben", > > with the following subcommands: > > * download: download a set of package list files from a mirror > > * monitor: monitor the status of a set of packages across several > > architectures (useful for transitions) > > * query: query packages using their metadata (similar to grep-dctrl, > > but uses a dedicated query language) > > * tracker: frontend to multiple monitors > > What does ben stand for? Is this just a short name for me? ;) It's part of the ongoing project to create ambiguity between the developer and package namespaces. We already have packages for abby, abe, aldo, alex, alice, axel, cecilia, chuck, clementine, clive, dino, ed, elisa, elmer, elvis, emma, eric, florence, grace, gregorio, hal, hannah, hercules, ivy, jack, jade, jed, joe, john, jupp, kasumi, kate, kaya, kiki, kitty, magnus, maki, maria, maude, midge, mona, nana, olive, paco, pasco, pia, pius, rio, ruby, simba, stella, tessa, tina, vagrant, vera, yorick, yoshimi (and no doubt other personal names I don't recognise, not to mention family names) though we are lacking developers to match many of them. Ben (Hutchings). > Would it be useful to have ben in devscripts instead of a separate > package? -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629191839.gb1...@decadent.org.uk
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On 06/29/2012 09:15 PM, Ralf Treinen wrote: > On Fri, Jun 29, 2012 at 07:21:21PM +0200, Mehdi Dogguy wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Mehdi Dogguy >> >> * Package name: ben >> Version : 0.6 >> Upstream Author : Mehdi Dogguy and Stéphane Glondu >> * URL : http://ben.debian.net/ >> * License : AGPL-3+ >> Programming Lang: C, OCaml >> Description : toolbox for Debian maintainers > >> * query: query packages using their metadata (similar to grep-dctrl, >> but uses a dedicated query language) > > Does it subsume the functionality of ara? ara is orphaned since some time, > so this would mean that we could send it into retirement. > (Disclaimer: I never used Ara. I just read its short description from http://ara.alioth.debian.org/). For now, "ben query" is just like "grep-dctrl". Not much, not less. We don't have fancy web interfaces like Ara does. HTH, -- Mehdi Dogguy مهدي الدڤي -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fedff08.8040...@dogguy.org
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On Fri, Jun 29, 2012 at 07:21:21PM +0200, Mehdi Dogguy wrote: > Package: wnpp > Severity: wishlist > Owner: Mehdi Dogguy > > * Package name: ben > Version : 0.6 > Upstream Author : Mehdi Dogguy and Stéphane Glondu > * URL : http://ben.debian.net/ > * License : AGPL-3+ > Programming Lang: C, OCaml > Description : toolbox for Debian maintainers > * query: query packages using their metadata (similar to grep-dctrl, > but uses a dedicated query language) Does it subsume the functionality of ara? ara is orphaned since some time, so this would mean that we could send it into retirement. -Ralf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120629191539.ga19...@free.fr
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
tags 539591 + patch thanks On Thu, Jun 28, 2012 at 02:40:18PM +0100, Roger Leigh wrote: > On Thu, Jun 28, 2012 at 08:02:33AM +0200, Alexander Wirt wrote: > > On Wed, 27 Jun 2012, Roger Leigh wrote: > > > > > On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote: > > > > On 06/27/2012 03:46 PM, Alexander Wirt wrote: > > > > > On Wed, 27 Jun 2012, Paul Wise wrote: > > > > > > > > > >> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote: > > > > >> > > > > >>> Yes. See http://bugs.debian.org/539591 >, > > > > >>> http://bugs.debian.org/573004 > and the source of insserv, > > > > >>> where > > > > >>> a patch to do this was created and included by Kel. The patch has > > > > >>> been available for more than two years. > > > > >> > > > > >> Hmm, no upload in those two years either. Is file-rc still > > > > >> maintained at all? > > > > > It is. But more or less in "no-new-features" mode. > > > > > > > > > > Implementing the insserv stuff is wishlist for me. Even when I now get > > > > > forced into it. > > > > > > I don't think there's any question of "forcing", but encouraging > > > file-rc to retain compatibility with the init scripts being used by the > > > distribution. It looks like the patches are there, they just need > > > testing. If file-rc could have this in place for wheezy, that would > > > be highly desirable, so that we can work on deprecating runlevel > > > sequence numbers in wheezy+1. > > Nope, there is an experimental patch for insserv to print out sequence > > numbers, to get this working I first have to build my own insserv. And the > > whole file-rc part is - beside of some ideas in my mind - missing. > > So the insserv patch is already present, it just needs enabling. So > 10 mins tops to download and rebuild. I never saw a followup in the > bug above--does the output format suit your needs? If it does, please > say so. It could potentially be enabled and uploaded today or tomorrow. The patch works just fine. I retested it this evening. Short example: % insserv -s | egrep '(postgresql|cron|procps|sudo)$' K:02:0 1 6:postgresql K:01:0 1 6:anacron S:02:2 3 4 5:postgresql S:02:2 3 4 5:anacron S:02:2 3 4 5:cron S:01:2 3 4 5:sudo S:13:S:procps > One you have the dependency info, can't you just query that in your > update-rc.d implementation to override the defaults provided to > update-rd.d? Does it require anything more complex than that? The following patch implements this behaviour. While the insserv parsing logic has been tested, it's not been tested for upgrades or whether the whole script works correctly. - it needs a Depends on insserv (>= $version_with_-s) ==> this needs your feedback so it can be uploaded. - the preinst could be simplified to just use update-rc.d "$script" -f defaults if this is sufficient to update the sequence numbers in the configuration. This probably needs running in the postinst TBH. - this just replaces the defaults and user-provided start and stop arguments with those provided by insserv. Other than that, there are no changes to anything else. - You might need to retain support for the old-style logic so that if other scripts call update-rc.d in the gap between unpacking and running the postinst, it won't fail. Just back out the deletions and run those blocks only if insserv didn't run or didn't find any matches, which are a trivial addition to the script. While this patch is just a proof a concept, this should be pretty much all you need. It just needs checking and testing by someone with file-rc expertise. If this could be done in the very near future, then that would be great. Please do provide some feedback on whether "insserv -s" is sufficient for your needs. Thanks, Roger diff -urN file-rc-0.8.12.original/debian/changelog file-rc-0.8.13/debian/changelog --- file-rc-0.8.12.original/debian/changelog2010-04-07 20:30:54.0 +0100 +++ file-rc-0.8.13/debian/changelog 2012-06-29 20:00:01.917474582 +0100 @@ -1,3 +1,10 @@ +file-rc (0.8.13) UNRELEASED; urgency=low + + * Use insserv for runlevel defaults rather than the arguments +provided to update-rc.d. + + -- Roger Leigh Fri, 29 Jun 2012 19:59:06 +0100 + file-rc (0.8.12) unstable; urgency=low * New maintainer (Closes: #539609) diff -urN file-rc-0.8.12.original/debian/preinst file-rc-0.8.13/debian/preinst --- file-rc-0.8.12.original/debian/preinst 2010-04-07 20:30:54.0 +0100 +++ file-rc-0.8.13/debian/preinst 2012-06-29 20:06:18.739474331 +0100 @@ -14,6 +14,8 @@ # for details, see http://www.debian.org/doc/debian-policy/ or # the debian-policy package +# Make sure insserv is in path +PATH=/sbin:$PATH case "$1" in install) @@ -64,6 +66,19 @@ dpkg-divert --package file-rc --remove \ --divert /etc/init.d/rcS.links /etc/init.d/rcS fi + + if [ "$2" != "" ] && dpkg --compare-versions $2 lt 0.8.13 + then + for script in /etc/init.d/*
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On 29/06/12 18:21, Mehdi Dogguy wrote: > Package: wnpp > Severity: wishlist > Owner: Mehdi Dogguy > > * Package name: ben > Version : 0.6 > Upstream Author : Mehdi Dogguy and Stéphane Glondu > * URL : http://ben.debian.net/ > * License : AGPL-3+ > Programming Lang: C, OCaml > Description : toolbox for Debian maintainers > > This is a collection of useful tools that Debian maintainers can use > to make their packaging work easier. They all work with regular > Debian package list files, and should be useful for Debian > derivatives as well. This package ships a single executable, "ben", > with the following subcommands: > * download: download a set of package list files from a mirror > * monitor: monitor the status of a set of packages across several > architectures (useful for transitions) > * query: query packages using their metadata (similar to grep-dctrl, > but uses a dedicated query language) > * tracker: frontend to multiple monitors > > > Yes! Please package this I am in ecstasy =) With respect to names, You could name it something boring like: debian-transition-tracker or something along the lines. I will file loads of wishlist bugs, and maybe even help fixing them! Who knows ;-) -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On Friday 29 June 2012 21:18:39 Ben Hutchings wrote: > On Fri, Jun 29, 2012 at 07:36:46PM +0200, Benjamin Drung wrote: > > Am Freitag, den 29.06.2012, 19:21 +0200 schrieb Mehdi Dogguy: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Mehdi Dogguy > > > > > > * Package name: ben > > > > > > Version : 0.6 > > > Upstream Author : Mehdi Dogguy and Stéphane Glondu > > > > > > * URL : http://ben.debian.net/ > > > * License : AGPL-3+ > > > > > > Programming Lang: C, OCaml > > > Description : toolbox for Debian maintainers > > > > > > This is a collection of useful tools that Debian maintainers can use > > > to make their packaging work easier. They all work with regular > > > Debian package list files, and should be useful for Debian > > > derivatives as well. This package ships a single executable, "ben", > > > > > > with the following subcommands: > > > * download: download a set of package list files from a mirror > > > * monitor: monitor the status of a set of packages across several > > > > > > architectures (useful for transitions) > > > > > > * query: query packages using their metadata (similar to grep-dctrl, > > > > > > but uses a dedicated query language) > > > > > > * tracker: frontend to multiple monitors > > > > What does ben stand for? Is this just a short name for me? ;) > > It's part of the ongoing project to create ambiguity between the > developer and package namespaces. We already have packages for abby, > abe, aldo, alex, alice, axel, cecilia, chuck, clementine, clive, dino, > ed, elisa, elmer, elvis, emma, eric, florence, grace, gregorio, hal, > hannah, hercules, ivy, jack, jade, jed, joe, john, jupp, kasumi, kate, > kaya, kiki, kitty, magnus, maki, maria, maude, midge, mona, nana, > olive, paco, pasco, pia, pius, rio, ruby, simba, stella, tessa, tina, > vagrant, vera, yorick, yoshimi (and no doubt other personal names I > don't recognise, not to mention family names) though we are lacking > developers to match many of them. > > Ben (Hutchings). Fair enough, but I'm also concerned that even more dangerous use-cases exist with so many generic package names... Consider a hypothetical scenario like that: a happy guy gets back at home, sits behind his box and tries to install a handful set of "useful" packages and the wife was carelessly listening to his shouting out various commands from the other room: apt-get install \ hello emma why cheese and wine burn and cook the dog animals instead half an hour later: apt-get install \ wipe the most sane dates contacts and tasks (yes, the packages will happily install, but the pets and business contacts would most likely suffer severe data loss - depending on the wife:) -- pub 4096R/0E4BD0AB -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206300109.09782.danc...@spnet.net
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
Le Fri, Jun 29, 2012 at 07:21:21PM +0200, Mehdi Dogguy a écrit : > > This is a collection of useful tools that Debian maintainers can use > to make their packaging work easier. They all work with regular > Debian package list files, and should be useful for Debian > derivatives as well. This package ships a single executable, "ben", > with the following subcommands: Hi, this looks very interesting, but I worry about future name conflicts with the following scenario: - More than one project is likely to be intested for taking /usr/bin/ben as a program name. - Since Debian's ben is Debian-specific, it will not be noticed by projects aiming at a wider audience. - If such a project comes to existence and becomes popular, we will have another name conflict à la node.js. An alterative scenario is that another project of narrow audience picks ben, which will cause a conflict of lesser importance as it will be solved on the usual first-arrived-first-served basis. But the key point is that if we do not aim at hundred thousands users for a tool, I think that we should avoid three-letter names. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120630010312.ga29...@falafel.plessy.net
Re: Improving our response to "duplicate" packages in Debian
On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : > > - Don't immediately start complaining to the submitter of the ITP. Just let > > the submitter devote his/her energy to packaging. > > I don’t think it is worthwile to let people devote their energy to > packaging pet applications that will disappear in 2 years time when they > find another one. I think this is approaching the problem from the wrong end. Instead of preserving the status quo and asking oracles to predict the future we should have better means of _removing_ software that has proven to be inferior of an equivalent alternative in Debian. The advantage is that we have objective criteria to be able to make an informed decision -- not a guess based on heuristics and opinion. The disadvantage is that it imposes work on other volunteers -- but see below... > We really need to find better ways to involve new users in core teams, > and that means removing from our collective consciousness the idea that > you come in Debian to package your new favorite piece of software. I have to disagree -- and I would even make the bold claim that "packaging your favorite piece of software" is a very common (if not the most common) entry point for _people_ into Debian. One could see the "pet projects" as the price we need to pay to make participation in Debian very attractive (not even talking about the role that "pet projects" play in the context of perceived universality of Debian) . Getting people to participate in Debian, make them become confident and experienced is IMHO a requirement for increasing the chance of anyone joining core teams. If it would work otherwise, we could just post a job-ad on LinkedIn: "Debian security team is looking for skilled developers". Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120630064107.GA20814@meiner
