Possibly hijacking netcdf
Hi folks after at least other 2 messages sent without answer in the past year and half and the latest below (with the same result at this moment), I'm going to hijack the netcdf package in order to move forward with version 4. If someone had objections about, please talk now or never :) - Forwarded message from "Francesco P. Lovergine" - Date: Mon, 7 Sep 2009 15:33:51 +0200 From: "Francesco P. Lovergine" To: Warren Turkal Cc: fran...@debian.org Subject: Netcdf status User-Agent: Mutt/1.5.20 (2009-06-14) Warren are you still motivated in maintaining netcdf in Debian? Your last update is quite dated and is has been already NMUed a couple of times. If not, we at DebianGis could properly migrate to current version 4 the current version and taking care of migration for squeeze. -- Francesco P. Lovergine - End forwarded message - -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possibly hijacking netcdf
I told someone to go ahead feel free to take it over. I don't remember who. I clearly don't have the time to do a proper job of this. I don't even use netcdf anymore, so I don't really have much motivation to package it. I did start packing the newest version, but I didn't make any real progress. I had a good reason until the dependencies for netcdf 4 were in debian. The responsible thing for me to do at this point is give the package up to another interested party, so please feel free to take it over. Warren Turkal Linux Enthusiast and Libre Software Advocate On Sep 21, 2009 12:47 AM, "Francesco P. Lovergine" wrote: Hi folks after at least other 2 messages sent without answer in the past year and half and the latest below (with the same result at this moment), I'm going to hijack the netcdf package in order to move forward with version 4. If someone had objections about, please talk now or never :) - Forwarded message from "Francesco P. Lovergine" - Date: Mon, 7 Sep 2009 15:33:51 +0200 From: "Francesco P. Lovergine" To: Warren Turkal Cc: fran...@debian.org Subject: Netcdf status User-Agent: Mutt/1.5.20 (2009-06-14) Warren are you still motivated in maintaining netcdf in Debian? Your last update is quite dated and is has been already NMUed a couple of times. If not, we at DebianGis could properly migrate to current version 4 the current version and taking care of migration for squeeze. -- Francesco P. Lovergine - End forwarded message - -- Francesco P. Lovergine
Re: Seeking advice on packaging of pion-net
On Sun, Sep 20, 2009 at 10:17:43PM -0400, Roberto C. Sánchez wrote: > Source: pion-net > Binary: libpion-net-dev, libpion-net-2.1.8, libpion-common-2.1.8, > libpion-net-2.1.8-dbg, libpion-common-2.1.8-dbg, libpion-net-doc > > The problem, as I see it, with this arrangement is, that when a new > upstream released, like 2.1.9, then four of the package names will > change, resulting in the need for the new upstream to pass NEW > processing. > I don't currently plan to package and reverse dependencies. In that case, another option might be not to package the libraries at all for now (or maybe just a static library as unversioned -dev package), and only start doing so if somebody requests it. Did you try to discuss the library versioning scheme with upstream? Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
On Mon, 21 Sep 2009 07:52:48 +0200, Luk Claes wrote: >The time complaining in this thread could probably better spent by >talking to ftpmas...@d.o and implementing a solution btw. Why do I need to actively talk to ftpmaster when it's them wanting to implement changes to a setup which has been implemented in close cooperation with their precedessors and which has been working for years? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possibly hijacking netcdf
On Mon, Sep 21, 2009 at 12:54:50AM -0700, Warren Turkal wrote: > I told someone to go ahead feel free to take it over. I don't remember who. /me probably :) > I clearly don't have the time to do a proper job of this. I don't even use > netcdf anymore, so I don't really have much motivation to package it. > > I did start packing the newest version, but I didn't make any real progress. > I had a good reason until the dependencies for netcdf 4 were in debian. > > The responsible thing for me to do at this point is give the package up to > another interested party, so please feel free to take it over. > > Warren Turkal > Linux Enthusiast and Libre Software Advocate > Thanks for all the paste work Warren, I'm going ahead with adoption. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Changes in the maintenance of the Developers Reference
On Mon, Sep 21, 2009 at 09:56:37AM +0200, Lucas Nussbaum wrote: > Hi, > > Following a discussion on debian-de...@l.d.o[1], the way the Developers > Reference[2] is maintained has been changed, with the aim to make it > more public and easier for people to contribute. > > Changes to developers-reference are now discussed on debian-pol...@l.d.o > (also used for debian-policy). Don't hesitate to jump in and contribute > to the discussions. Debian Policy has a more formal process than developers-reference and I am concerned that mixing both discussions on the same channel would cause confusion. debian-de...@l.d.o could be a better channel for the developers-reference discussions, though with the downside of yet more outside traffic than debian-policy. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547659: ITP: rephrase -- Specialized passphrase recovery tool for GnuPG
Package: wnpp Severity: wishlist Owner: Tiago Bortoletto Vaz * Package name: rephrase Version : 0.1 Upstream Author : Phil Lanch * URL : http://www.roguedaemon.net/rephrase/ * License : GPL Programming Lang: C Description : Specialized passphrase recovery tool for GnuPG If you can nearly remember your GnuPG passphrase - but not quite - then Rephrase may be able to help. Tell Rephrase the parts of the passphrase you know, and any number of alternatives for the parts you're not sure about; and Rephrase will try all the alternatives, in all possible combinations, and tell you which combination (if any) gives you the correct passphrase. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
* Henrique de Moraes Holschuh: > On Sun, 20 Sep 2009, Marc Haber wrote: >> As long as you do not expect me to manually sign every single upload, > Why not? ClamAV, like about every other antivirus scanner, is used to fight rapidly moving targets. It relies on current -data files to provide any kind of useful service to its users. "Malware vs. Anti-Malware: (How) Can We Still Survive?"[1] may give you a bit of an idea how fast the targets are moving. I have written and maintained scripts that download signature file updates for several commercial antivirus scanners and built packages for them -- which is pretty much the same thing that clamav-getfiles does. 10 updates to the signature files per day are not uncommon in the proprietary space and I'd be very surprised if things were any different for ClamAV. If it's really necessary to generate the signature with manual intervention, we are going to need a 24/7 commitment by a group of people to a response time of a few hours or less for every update. > It is a package, it has root access anywhere it is being installed or > removed. Even if you abuse the DM machinery to have a key restricted > to only upload clamav-data, it would still be risky. There are only a few places from where malicious code could be executed on behalf of the package creator: The maintainer scripts (preinst, postinst, prerm, postrm, config) and any executables that may be part of the package. The maintainer scripts can be checked and stay constant across new version, and the list of files shipped in the clamav-data package is fixed. This stuff can easily be checked automatically between upload and accepting the package into the archive. I know that whenever I claim that something should be easy, people tend to answer "show me the code", so there: If whoever in charge states that my idea is acceptable, I'll be happy to implement limited checking of pacakge contents in the archive software. -Hilko [1] http://av-test.org/down/papers/2008-02_vb_comment.pdf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
deepti seo has invited you to join Gusto!
deepti seo has invited you to join Gusto, a free community of travel enthusiasts. hey friends cm here and share yout travel tips. Follow the link below to activate your Gusto! account: http://www.gusto.com/my_gusto/activate_account?token=taez5 If you are unable to follow the link above directly from your email, simply copy the entire link into your favorite browser to activate your Gusto account. About gusto! Gusto is a free travel community. Members of Gusto have access to all the free Gusto travel tools, along with the ability to: * Book travel reservations * Customize travel deals * Read and write reviews * View and store photos * Create and read blogs * Explore and save destination information from around the Web using the Gusto Grabber JOIN deepti seo and the Gusto travel community today! http://www.gusto.com/my_gusto/activate_account?token=taez5 Travel with Gusto! The Gusto Team -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Seeking advice on packaging of pion-net
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Banck wrote: > > Did you try to discuss the library versioning scheme with upstream? pion-net is built on boost's asio. I'd be very suprised if they even _can_ offer a stable ABI with no symbol pollution from asio etc. :) - -Rob -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq3c8kACgkQ42zgmrPGrq5gDwCgm9vf9LbEpd1Peh+/G8Nd73Kd ng0Ani0Y31sZoipdBPehaf1R7PWfCzEh =exJ7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547667: ITP: nasty -- Helps you to recover the passphrase of your GPG key
Package: wnpp Severity: wishlist Owner: Tiago Bortoletto Vaz * Package name: nasty Version : 0.6 Upstream Author : Folkert van Heusden * URL : http://www.vanheusden.com/nasty/ * License : GPL Programming Lang: C Description : Helps you to recover the passphrase of your GPG key Nasty is a program that helps you to recover the passphrase of your PGP or GPG-key in case you forget or lost it. The following features will make things easier: - set minimum/maximun length of passphrase - incremental mode, random mode or reading a file for guessing - charset filter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please help with checking the boot and shutdown script ordering
As was announced earlier, Squeeze will be using dependency based boot sequencing to order the init.d scripts. The current dependencies are fairly good, but work is still needed to weed out the last bugs in the ordering. Automatic systems are in place to detect the most grave problems and inconsistencies, but to detect missing or incorrect dependencies, someone that know each script and package need to be involved. This is where you come in. :) The current effort is coordinated on IRC (#pkg-sysvinit on irc.debian.org) and the mailing list initscripts-ng-de...@lists.alioth.debian.org. The wiki page http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot > link to related resources. One new resource is an archive wide check of the consistency of dependencies available from http://lintian.debian.org/~pere/>. In the log file available from there, one can currently see how all scripts in the archive will be ordered in each rc?.d/ directory, and also see bugs and inconsistencies detected. Examples of such are scripts depending on non-existing services, scripts starting in rcS.d/ depending on $syslog which is started in rc2.d/, etc. Another new resource is piuparts, which will detect packages with inconsistency between the package dependency and the init.d script dependency - like a script requiring $portmap while the package do not depend on portmap. Please help find and fix errors in the init.d script ordering. The majority of packages are fairly correct, and I have tested the packages installed by tasksel to verify that the common setup is correct, but some lesser used packages might have incorrect order and only manual review can discover this. For sequential booting, the dependencies only need to be fairly correct to get a useful order, but for concurrent booting the dependencies need to be complete to avoid surprises. If you want to help out and wonder what to look for in the headers or in the log files generated by the automatic checking systems, please ask on IRC. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547686: ITP: libconvert-color-perl -- Color space conversions and named lookups
Package: wnpp Severity: wishlist Owner: Maximilian Gass * Package name: libconvert-color-perl Version : 0.05 Upstream Author : Paul Evans * URL : http://search.cpan.org/dist/Convert-Color/ * License : Artistic | GPL-1+ (Perl) Programming Lang: Perl Description : Color space conversions and named lookups This module provides conversions between commonly used ways to express colors. It provides conversions between color spaces such as RGB and HSV, and it provides ways to look up colors by a name. I am packaging this as a dependency for dizzy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
On 2009-09-21, Hilko Bengen wrote: > I have written and maintained scripts that download signature file > updates for several commercial antivirus scanners and built packages for > them -- which is pretty much the same thing that clamav-getfiles does. > 10 updates to the signature files per day are not uncommon in the > proprietary space and I'd be very surprised if things were any different > for ClamAV. Well, there was also the problem that when asked what problem it tries to solve nobody came up with something sane. If boxes have no internet access freshclam could ask through a proxy, or similar. So I guess the usecase is really that you shut off your machines from the internet, only able to access internal hosts and the packaging mirror to fetch the signatures from? How is that different from just setting up a signature mirror on an internal host? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
On Mon, 21 Sep 2009, Marc Haber wrote: > And people know that the package is built automatically. All users I > know especially opted in to using the package instead of freshclam for > some-or-other reason. WHERE is that information published? I don't see it in the package description, and I don't see it in volatile.d.o either. It is not even in the for-developers page. Was it somehow lost or misplaced in the web pages? Or is it just inside the package, or in a blog somewhere, or in a mailing-list post somewhere? Those would not give that information anywhere near the necessary exposal to people who are considering installing the package for the first time. > > If someone has network access to fetch > >clamav-data, he also has network access to fetch the signatures, so he could > >run the "create-clamav-data" utility instead... > > This assumption is wrong. I am honestly curious about this one. Look, I don't have anything against gatekeeper procedures being put in place to keep the current way clamav-data is built, although I *still* don't understand why clamav-data is necessary, and therefore I don't understand either why it would warrant so much effort and complexity [to do it right]. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
On Mon, Sep 21, 2009 at 11:49 AM, Henrique de Moraes Holschuh wrote: > On Mon, 21 Sep 2009, Marc Haber wrote: >> And people know that the package is built automatically. All users I >> know especially opted in to using the package instead of freshclam for >> some-or-other reason. > > WHERE is that information published? > > I don't see it in the package description, and I don't see it in > volatile.d.o either. It is not even in the for-developers page. >From the description of the volatile package: This package contains data files for clamav and was automatically generated by clamav-getfiles from the identically named package. ... Please note that this package was built automatically without human supervision and was only automatically checked before upload. Use at your own risk. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
On Mon, 21 Sep 2009, James Vega wrote: > On Mon, Sep 21, 2009 at 11:49 AM, Henrique de Moraes Holschuh > wrote: > > On Mon, 21 Sep 2009, Marc Haber wrote: > >> And people know that the package is built automatically. All users I > >> know especially opted in to using the package instead of freshclam for > >> some-or-other reason. > > > > WHERE is that information published? > > > > I don't see it in the package description, and I don't see it in > > volatile.d.o either. It is not even in the for-developers page. > > >From the description of the volatile package: > > This package contains data files for clamav and was automatically > generated by clamav-getfiles from the identically named package. > ... > Please note that this package was built automatically without human > supervision and was only automatically checked before upload. Use at > your own risk. Thank you. I misused apt-cache and got the package description from a box that didn't have volatile.d.o in the sources list. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please help with checking the boot and shutdown script ordering
Hi! Petter Reinholdtsen schrieb: > Another new resource is piuparts, which will detect packages with > inconsistency between the package dependency and the init.d script > dependency - like a script requiring $portmap while the package do not > depend on portmap. Couldn't that be added as a check to lintian? Best Regards, Alexander signature.asc Description: OpenPGP digital signature
Re: Of the use of native packages for programs not specific to Debian.
"Giacomo A. Catenazzi" writes: > Wouter Verhelst wrote: >> On Thu, Sep 17, 2009 at 07:46:08AM +0200, Giacomo A. Catenazzi wrote: >>> On native package the debian/changelog is also used for upstream >>> changelog: upstreams tend to package their packages as native. >> [...] >>> Thus non debian specific package, which are also native, >>> should (must on GPL licensed packages) have a separate >>> "upstream" changelog. >> >> That doesn't follow. You're assuming it's going to be impossible to keep >> the original debian/changelog file, and/or that the only way to package >> something that an upstream has packaged as native is to package it as >> non-native. > > hmm. Do you think we should pack an external package as native, if > upstream (or "upstream distribution") packages it as native? If you can join the upstream team and do releases directly as the upstream you then are then why not? > I think this is not intended by our polict, but OTOH it is the easier > way: we should only take care about version conflicts (automatically > adding a suffix could not be enough on few seldom cases). > > But if we pack as non-native (as it should be: we are not upstream), > more problems arises: > we cannot patch anymore debian directory: on 3.0 source format > the original debian dir will disappear, thus removing the > debian/changelog (which is required by GPL for upstream changes). How does that work at all for upstream itself? From what you describe unpacking the upstream released source with dpkg-source -x would end up without debian dir at all. > It is not impossible to solve this problem: we can manually copy the > original changelog to our diff/patches. > > So the question is: > > Is it really worth to use "native package for programs not > specific to Debian" ? Is it worth it use non-native when you are upstream and maintainer? I think that is the more important question. For packages where upstream != maintainer you should imho not use native format. If upstream releases debian packages (has a debian dir) and the maintainer also releases debian packages then there will be problems. That can only be avoided by close cooperation. Become co-upstreams / co-maintainers and only release one version. > I still think it is not nice for downstream. It is not nice either way. Worse for downstream of downstream. >> If I'm an upstream and a Debian maintainer for a particular package, and >> a downstream distribution wants to modify my package, then I think it's >> fairly reasonable for them to just modify the package, without having to >> repackage it entirely. > > This is the problem with sources 3.0, on non-native packages: we cannot > modify the package, we must repack discarding all original files in debian/ Why? Only problem I see is that you need to duplicate the files from debian/ if you change from native to non-native. The solution is to get upstream to fix their debian dir so you do not have to modify the package under normal circumstances. And in an emergency you modify it as native package. >> People fork software *all the time*. This is no different. > > Yes, but it is not our job to fork packages (freely interpreted from devref > 3.5). > > ciao > cate MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547711: ITP: libpoe-test-loops-perl -- Perl test suite for POE event loops
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libpoe-test-loops-perl Version : 1.022 Upstream Author : Rocco Caputo * URL : http://search.cpan.org/dist/POE-Test-Loops/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Perl test suite for POE event loops POE::Test::Loops is a Perl helper module that provides a framework for testing the functionality of POE event loops. It contains a single function that sets up all the loop tests for one or more POE::Loop subclasses. It is most useful during development and building of POE event loops. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547720: ITP: dizzy -- graphics demo that makes you dizzy using rotating textures
Package: wnpp Severity: wishlist Owner: Maximilian Gass * Package name: dizzy Version : 0.1.1 Upstream Author : Lars Stoltenow http://penma.de/code/dizzy * License : Artistic | GPL-1+ (Perl) Programming Lang: Perl Description : graphics demo that makes you dizzy using rotating textures dizzy is a graphics demo that rotates planes of patterns on a colored background to make you dizzy. Textures can be cross-faded and there is a mode that automatically changes textures, allowing Dizzy to be run as a screensaver. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please help with checking the boot and shutdown script ordering
[Alexander Reichle-Schmehl] > Couldn't that be added as a check to lintian? Sure, for this particular problem, which at most affect 14 scripts. For the general case, it is not possible for lintian to know which package a given init.d script dependency belong to. Quite a lot of lintian checks are already written, thanks to Raphael, and we should create more as we come up with tests that can be done per package. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Faster boot by running init.d scripts in parallel
On Sun, Sep 20, 2009 at 13:52:59 -0700, lkcl wrote: [...] > some years back, richard lightman wrote depinit. it's a complete > replacement for sysvinit, and it's a parallel initialisation system. > > unlike sysvinit, it caught _all_ signals on applications. > > i installed it several times, and it showed that startup time could be > reduced from 2 minutes (800mhz PIII) to 25 seconds, and it showed that > shutdown time can be reduced from 1-2 minutes to under 4 seconds. > > the reason for the fast shutdown time is that a) shutting down services > typically takes a lot less time than starting them b) depinit would send > increasingly drastic signals to kill a service. > > other nice features include: [...] > * script / service chaining (applying the unix pipe philosophy, even to > services). one "service" can output its stdout and/or stderr to _another_ > service. richard utilised this e.g. on sshd and other services requiring > authentication. by chaining the output from sshd into another script, he > could monitor attacks against a server _live_ rather than "ohh let's run a > cron job every minute and watch the sshd logs or something oh whoops, too > late". so, the monitoring script could observe three login failures and > *instantly* add a firewall rule. > > * automatic re-spawning of services AND termination of dependent services if > re-spawning fails. this is a really important security feature. if the > firewall doesn't come up, or any other particularly critical service (such > as heartbeat monitoring service), do you REALLY want the dependent services > to come up? automatic re-spawning basically does away with the [stupid] > mysql monitoring script, which cannot do a proper job anyway, simply because > the required signals cannot be properly caught [remember: depinit catches > EVERYTHING]. Maybe you are interested in the runit init system, as depinit sounds similar. It doesn't directly support dependencies, but it runs a service through a pipe and not as a daemon in the background, so that supervision and direct submission of signals is possible. Regards, Tino -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Changes in the maintenance of the Developers Reference
Bill Allombert wrote: > debian-de...@l.d.o could be a better channel for the developers-reference > discussions, though with the downside of yet more outside traffic than > debian-policy. Not really - d-devel is a way too messy list for a useful discussion. Not sure if there is a better list to use for that. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Automatic ITP closing.
Dear David, In 2005 you started an effort to close old WNPP bugs that do not get resolved: http://lists.debian.org/msgid-search/1127503245.4308.5.ca...@cerdita Apparently, this was stopped in 2008. Can you confirm that it is intentional or did it just get unnoticed by everybody? The reason I ask is that I am editing a documentation that mentions the automatic WNPP closings, and I wonder if I should delete this part or not. (CC to -devel as it may be of general interest.) Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic ITP closing.
Charles Plessy wrote: > Dear David, > > In 2005 you started an effort to close old WNPP bugs that do not get resolved: > http://lists.debian.org/msgid-search/1127503245.4308.5.ca...@cerdita > > Apparently, this was stopped in 2008. Can you confirm that it is intentional > or > did it just get unnoticed by everybody? The reason I ask is that I am editing > a > documentation that mentions the automatic WNPP closings, and I wonder if I > should delete this part or not. > > (CC to -devel as it may be of general interest.) > > Have a nice day, > Hi I contacted David in relation to this after I took ownership of #264774 (which is about this very problem) and David replied: > It's available on my home directory on master. Sadly I forgot all about this bug after I joined the java team. I do not have access to master, so I have not been able to see this script. David did not say anything about why the script was not still active when he replied. ~Niels PS: I had more luck contacting David using da...@axiombox.com rather than the debian mail. signature.asc Description: OpenPGP digital signature
Re: Automatic ITP closing.
On Tue, Sep 22, 2009 at 06:34, Charles Plessy wrote: > Dear David, > > In 2005 you started an effort to close old WNPP bugs that do not get resolved: > http://lists.debian.org/msgid-search/1127503245.4308.5.ca...@cerdita > > Apparently, this was stopped in 2008. Can you confirm that it is intentional > or > did it just get unnoticed by everybody? The reason I ask is that I am editing > a > documentation that mentions the automatic WNPP closings, and I wonder if I > should delete this part or not. I'm personally happy that this script stops: ITP without work should be retitled to RFP (since this way we don't loose the history of the bugs if someone will step in) instead of closing it. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
