Re: Work-needing packages report for Oct 22, 2010

Martin Zobel-Helas writes: > Hi, > > On Fri Oct 22, 2010 at 00:25:44 +, w...@debian.org wrote: >> The following is a listing of packages for which help has been requested >> through the WNPP (Work-Needing and Prospective Packages) system in the >> last week. >> >> Total number of orphaned p

Re: Bug#622172: ITP: git-hg -- Script to track mercurial repositories in git

AFAIK Sverre Rabbelier was hoping to bring remote-hg to some conclusion by the end of last year so it could get approached git mainline, but that hasn't happened yet unfortunately :-/ Thus, in the absence of proper remote-hg, I would vote for having fast-export based workaround available meanwhi

RE: alpha and hppa removal from unstable/experimental

Apt-get update on unstable still worked today for the german debian ftp server. If it disappears, I want to have the dump as noted: > > Before we remove the architectures, archives will be taken for anyone > > who wants to take a copy of the dump to use elsewhere. These dumps > > will be made ava

Re: ITP: git-hg -- Script to track mercurial repositories in git

Hi, Andrey Rahmatullin wrote: > On Sun, Apr 10, 2011 at 07:52:52PM +0200, Mike Hommey wrote: >> The right approach for mercurial tracking is IMHO >> https://github.com/SRabbelier/git/tree/remote-hg [...] > If the stuff at your link is a patched git tree instead of a separate > piece of software,

Re: plan to clean up unstable

* Torsten Werner , 2011-04-10, 18:45: http://ftp-master.debian.org/users/twerner/pre-lenny.txt 1. These packages were uploaded recently: altree guile-cairo nyquist How about giving maintainers/autobuilders a little more time? 2. libmowgli is in the middle of a transition, and there are still

Re: plan to clean up unstable

Am -10.01.-28163 20:59, schrieb Steve Langasek: > Only that I had a hard time understanding what you were talking about > removing. :-) Okay, let me rephrase it: i'll keep the newest version of each source package and all older versions that have been uploaded after 2008. Torsten -- To UNSUBSC

Re: plan to clean up unstable

Am -10.01.-28163 20:59, schrieb Svante Signell: > libpcap0.8: #612834 A new version that includes the patch has been uploaded and that means that the old version will be automatically removed from unstable. Torsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subjec

Re: alpha and hppa removal from unstable/experimental

On 10/04/11 20:04, Lars Wirzenius wrote: > I am a mostly dis-interested outsider for both the alpha and hppa > architectures. I write this to be supportive of the ftpmasters. +1 > It seems to me that the alpha porters have had quite a lot of time to > bring the architecture up to the level of qu

Re: plan to clean up unstable

On Sun, 10, Apr, 2011 at 11:50:45AM -0700, Steve Langasek spoke thus.. > I agree, dropping binaries from old source versions so that we can prune the > sources is a good idea. Yeah, that confused me a bit too! Torsten, do you think we should add this to the cruft-report output? Maybe using a two

Criterion of a good computer system; was Re: Back to technical discussion? Yes!

* From: Ben Hutchings * Date: Mon, 4 Apr 2011 15:59:47 +0100 > For most people, a computer is just a tool. You've hit the nail on the head. A personal computer system should be an efficient tool. > ... not all that complexity has to be exposed by default. Yes, needless complexity

Re: alpha and hppa removal from unstable/experimental

On su, 2011-04-10 at 20:06 +0200, Witold Baryluk wrote: > I today say that alpha disappered from unstable buildd. I am a mostly dis-interested outsider for both the alpha and hppa architectures. I write this to be supportive of the ftpmasters. It seems to me that the alpha porters have had quite

Re: plan to clean up unstable

On Sun, Apr 10, 2011 at 06:45:54PM +0200, Torsten Werner wrote: > I plan to remove very old source packages from unstable. The actual > algorithm will be: > from all source packages that have more than 1 versions in unstable: > remove all of them that have version < newest_version and that have b

Re: MBF alert: packages with very long source / .deb filenames

On Sunday 10 April 2011 20:19:42 Toni Mueller wrote: Hi, On Fri, 25.03.2011 at 14:17:06 +, Steve McIntyre wrote: > If we really want to meet the spec, we should be aiming for < 64 > characters, but that affects 98 packages and I'm not *too* bothered > > about it since testing shows no is

Re: [PATCH] dep5.mdwn: Fine tune Copyright header description and examples

Steve, my co-driver, says he has a couple of issues he wants to fix before we are finished with DEP5. He'll write patches and submit them for discussion about next weekend or so. So consider the DEP5 spec unfrozen a bit. (I'd rather patches are written against the version of the spec in the polic

Re: alpha and hppa removal from unstable/experimental

On 04-01 21:55, Mark Hymers wrote: > Hi, > > As mentioned in the recent ftp-team meeting minutes, we're planning to > remove alpha and hppa from unstable. They were removed from testing > before the squeeze release and there's no sign that they will be release > architectures for wheezy. As such

Re: plan to clean up unstable

Am -10.01.-28163 20:59, schrieb Mehdi Dogguy: > can't this limit to 2009 be pushed further? what would be the difference > if we consider 2010, or 2011? (Just want to see the impact). 800 packages would be affected if the date limit would be set to < 2011. I have generated a full list at

Re: Bug#622172: ITP: git-hg -- Script to track mercurial repositories in git

On Sun, Apr 10, 2011 at 07:52:52PM +0200, Mike Hommey wrote: > The right approach for mercurial tracking is IMHO > https://github.com/SRabbelier/git/tree/remote-hg I've asked about the right way to do that at http://lists.debian.org/debian-mentors/2011/04/msg00171.html yesterday and didn't receive

Re: plan to clean up unstable

On Sun, 2011-04-10 at 19:14 +0200, Samuel Thibault wrote: > Torsten Werner, le Sun 10 Apr 2011 18:45:54 +0200, a écrit : > > from all source packages that have more than 1 versions in unstable: > > remove all of them that have version < newest_version and that have been > > uploaded before 2009. >

Re: Bug#622172: ITP: git-hg -- Script to track mercurial repositories in git

On Sun, Apr 10, 2011 at 11:22:24PM +0600, Andrey Rahmatullin wrote: > Package: wnpp > Severity: wishlist > Owner: Andrey Rahmatullin > > * Package name: git-hg > Version : 20110408-1 > Upstream Author : Barak A. Pearlmutter > * URL : https://github.com/barak/git-hg >

Re: MBF alert: packages with very long source / .deb filenames

Hi, On Fri, 25.03.2011 at 14:17:06 +, Steve McIntyre wrote: > If we really want to meet the spec, we should be aiming for < 64 > characters, but that affects 98 packages and I'm not *too* bothered > about it since testing shows no issues thus far. I'm tempted to file: > > * serious bugs on

Re: plan to clean up unstable

On 04/10/2011 06:45 PM, Torsten Werner wrote: I plan to remove very old source packages from unstable. The actual algorithm will be: from all source packages that have more than 1 versions in unstable: remove all of them that have version< newest_version and that have been uploaded before 2009

Bug#622172: ITP: git-hg -- Script to track mercurial repositories in git

Package: wnpp Severity: wishlist Owner: Andrey Rahmatullin * Package name: git-hg Version : 20110408-1 Upstream Author : Barak A. Pearlmutter * URL : https://github.com/barak/git-hg * License : Expat Programming Lang: Bash Description : Script to track

Re: plan to clean up unstable

Torsten Werner, le Sun 10 Apr 2011 18:45:54 +0200, a écrit : > from all source packages that have more than 1 versions in unstable: > remove all of them that have version < newest_version and that have been > uploaded before 2009. > > A full list is available from >

plan to clean up unstable

Hi, I plan to remove very old source packages from unstable. The actual algorithm will be: from all source packages that have more than 1 versions in unstable: remove all of them that have version < newest_version and that have been uploaded before 2009. A full list is available from

Bug#622143: ITP: pvcam-utils -- utilities for using the Photometrics Coolsnap ES camera

Package: wnpp Severity: wishlist Owner: Bas Wijnen * Package name: pvcam-utils Version : 0.1 Upstream Author : Bas Wijnen * URL : None yet, hopefully soon http://alioth.debian.org/. * License : GPL Programming Lang: C++ Description : utilities for usin

Bug#622142: ITP: libpvcam -- library for using Photometrics coolsnap ES camera

Package: wnpp Severity: wishlist Owner: Bas Wijnen * Package name: libpvcam Version : 2.7.0.0 Upstream Author : Unknown, unmaintained. * URL : http://www.photometrics.com/support/downloads/lin_pvcam.php * License : None Programming Lang: Probably C Descript

Re: [PATCH] dep5.mdwn: Fine tune Copyright header description and examples

Jari, thanks for your patch. I am sorry to say I am going to reject it. As of about two days ago, DEP5 is now included in the debian-policy package. There's a couple of details to fix, still (see #609160), but other than that, I consider the spec to be frozen. Unless there are serious bugs in it,

Bug#622137: ITP: pvcam-dkms -- kernel module for Photometrics Coolsnap ES camera

Package: wnpp Severity: wishlist Owner: Bas Wijnen * Package name: pvcam-dkms Version : 4.1.0. Upstream Author : Bas Wijnen * URL : None yet, hopefully soon on http://alioth.debian.org. * License : GPL Programming Lang: C Description : kernel module fo

[PATCH] dep5.mdwn: Fine tune Copyright header description and examples

** CC: DEP5 drivers ** Here is a small patch to update the DEP5's Copyright examples ** See also FSF copyright year use recommendations at http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html In "Files paragraph (Repeatable)" - Drop duplicate word "Copyright"; already included in

Re: Bash-completion with triggers

On Sun, 10 Apr 2011 15:25:09 +0200, David Paleino wrote: > On Sun, 10 Apr 2011 14:55:12 +0200, Josselin Mouette wrote: > > > Le dimanche 10 avril 2011 à 12:54 +0200, David Paleino a écrit : > > > Also, we're currently targetting bash >= 3.2, so we need to take care of > > > backwards compatibili

Re: Bash-completion with triggers

On Sun, 10 Apr 2011 14:55:12 +0200, Josselin Mouette wrote: > Le dimanche 10 avril 2011 à 12:54 +0200, David Paleino a écrit : > > Also, we're currently targetting bash >= 3.2, so we need to take care of > > backwards compatibility. > > For 2.0, we're probably bumping that requirement to >= 4.1,

Bug#622130: RFP: xneur -- xneur[7571]: segfault at 94 ip b745bd50 sp bfa91710 error 4 in libX11.so.6.3.0[b73cf000+119000]

Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Helloy ! I have errors in /var/log/kern.log: Apr 9 23:52:54 gnulinux kernel: [53069.184844] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 1 Apr 9 23:52:54 gnul

Re: Bash-completion with triggers

Le dimanche 10 avril 2011 à 12:54 +0200, David Paleino a écrit : > Also, we're currently targetting bash >= 3.2, so we need to take care of > backwards compatibility. > For 2.0, we're probably bumping that requirement to >= 4.1, so we can use > newer > bash features, which will hopefully make thi

Re: Bash-completion with triggers

On Sun, 10 Apr 2011 12:24:11 +0200, Ansgar Burchardt wrote: > David Paleino writes: > > I've implemented a new revision of bash-completion, which uses > > debtriggers(5) to load only relevant completions, and symlink them when > > something touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin

Re: Bash-completion with triggers

Hi, David Paleino writes: > I've implemented a new revision of bash-completion, which uses debtriggers(5) > to load only relevant completions, and symlink them when something > touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin/, and so on. zsh supports autoloading of functions: the time i

Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]

On Sat, Apr 09, 2011 at 11:42:12PM +0200, Bastian Blank wrote: > On Fri, Apr 08, 2011 at 06:52:41PM +0200, Bastian Blank wrote: > > We have the same problem with awk since ages. We should fix both > > problems together. Therefor I propose the following: > > - An essential or pseudo-essential (depe

Re: Bash-completion with triggers

On Sun, 10 Apr 2011 13:11:57 +0300, Eugene V. Lyubimkin wrote: > On 2011-04-10 11:56, David Paleino wrote: > > Now, with that time spent, I suppose the objections against triggers would > > be fewer and less important. Am I wrong? :) > > I must say I'm a bit uncomfortable with APT-hooks, since the

Re: Bash-completion with triggers

On 2011-04-10 11:56, David Paleino wrote: > I think the time spent was the major objection, so I stripped it down to... > > $ time ./update-bash-completion > bash-completion: updating completion symlinks... done. > > real 0m0.225s > user 0m0.148s > sys 0m0.020s > $ Very good! > Now, with t

Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]

Bastian Blank writes: > On Sun, Apr 10, 2011 at 02:18:49AM +0200, Goswin von Brederlow wrote: >> Here I think we can go one of two ways: >> 2) "bootstrap" scripts are only executed after the owners (Pre-)Depends >> have been unpacked. This would allow base-files to setup the links based >> on ava

Re: Bash-completion with triggers

A quick update... On Thu, 7 Apr 2011 15:16:20 +0200, Raphael Hertzog wrote: > The trigger is going to happen very often (like the man-db one) and > with a 10s impact it's very noticable... I think the time spent was the major objection, so I stripped it down to... $ time ./update-bash-completio

Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]

On Sun, Apr 10, 2011 at 02:18:49AM +0200, Goswin von Brederlow wrote: > - The rules for essential packages must remain fulfilled on upgrades > without this script being executed. The bootstrap script is never > executed if the system was installed from a version predating the > "bootstrap" script i

Re: MBF: Getting rid of unneeded *.la / emptying dependency_libs

Neil Williams wrote: [...] > With the caveats already covered in this thread (excepting kdelibs), are > there objections to a MBF for this outdated Release Goal? We've already > missed this Release Goal once, probably because no bugs were filed > first time around. [...] Hello, I have also tagge