Hamish Moffatt | 1 Nov 01:20
Picon
Favicon

Re: Orphaned packages with quite some users

On Thu, Nov 01, 2007 at 12:45:29AM +0100, Frank S. Thomas wrote:
> Hi,
> 
> On Wednesday 31 October 2007, Luk Claes wrote:
> > Below you'll find a list of longtime orphaned packages with quite some
> > users. It would be great if people could adopt packages that are still
> > usefull and give alternatives and/or migration plans for packages that
> > are rather obsolete or not really usefull anymore.
> 
> People who are interested in adopting orphaned packages might want to run 
> something like the script below to see the list of orphaned packges that are 
> installed on their system sorted by the packages' popcon scores. This may 
> help with deciding which package to adopt.

Or use wnpp-alert from devscripts.

Hamish
--

-- 
Hamish Moffatt VK3SB <hamish <at> debian.org> <hamish <at> cloud.net.au>

Josselin Mouette | 1 Nov 02:08
Picon
Favicon

Re: Bug#438665: Orphaned packages with quite some users

Le mercredi 31 octobre 2007 à 18:05 -0400, Joey Hess a écrit :
> d-i can't afford to install recommends by default (best way to change
> that is to make all uses of recommends sane to be installed by default).
> 
> So the laptop task would need to track and list the recommends. Doing
> something smarter like only installing given recommends on laptop
> hardware that can use them would also be an option.

You may be interested to learn that we plan to downgrade a number of
dependencies of the gnome metapackages to Recommends.

If this means tracking them later on to be sure that everything needed
is installed, maybe we need a way to improve the coordination between
tasksel and the gnome uploads.

--

-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
Joey Hess | 1 Nov 03:46
Picon
Favicon
Gravatar

Re: Bug#438665: Orphaned packages with quite some users

Josselin Mouette wrote:
> You may be interested to learn that we plan to downgrade a number of
> dependencies of the gnome metapackages to Recommends.
> 
> If this means tracking them later on to be sure that everything needed
> is installed, maybe we need a way to improve the coordination between
> tasksel and the gnome uploads.

tasksel doesn't use the gnome-desktop metapackage, if
gnome-desktop-environment drops things to recommends I'd have to track
that.

--

-- 
see shy jo
Bart Samwel | 1 Nov 03:54

Re: Bug#438665: Orphaned packages with quite some users

Luk Claes wrote:
> Bart Samwel wrote:
>> 3. Regarding the toshset package: I have a working Toshiba Tecra 8200,
>> one of the models covered by toshset. I may be biased, but as far as I'm
>> concerned the stuff is still useful. :-)
> 
> Please do adopt the toshutils and toshset packages so people don't need
> to reiterate the same discussion over and over again as you say
> yourself. Thanks already for taking care.

Hmmm. I'd require a sponsor for that, as I'm not a DD. Raphael, would 
you mind sponsoring?

Cheers,
Bart

Bart Samwel | 1 Nov 06:19

Re: Bug#438665: Orphaned packages with quite some users

Joey Hess wrote:
> Raphael Hertzog wrote:
>> The problem is not so much on manually installed package but on initial
>> installation. I'm not sure what would get installed via the laptop task if
>> we made that a Recommends...
> 
> d-i can't afford to install recommends by default (best way to change
> that is to make all uses of recommends sane to be installed by default).
> 
> So the laptop task would need to track and list the recommends. Doing
> something smarter like only installing given recommends on laptop
> hardware that can use them would also be an option.

I wouldn't mind having the packages installed in the laptop task if that 
fixes it. However, the laptop task currently uses the task-fields 
method, which AFAICT means that the dependent packages should list 
themselves as being part of the laptop task, something that will take 
quite some effort if we want to do it. That would also be a dependency 
inversion, with the dependencies basically saying "I'm a dependency of 
acpi-support (and I express this by being in the laptop task)". 
Unfortunately, AFAICT switching away from the task-fields method means 
explicitly listing *all* of the packages in the laptop task, which is 
not something we'd want to do either. Is a hybrid task-field/list method 
possible in tasksel?

Cheers,
Bart

Francois Marier | 1 Nov 06:20
Picon
Favicon
Gravatar

Bug#448805: ITP: flatzebra -- Generic Game Engine library

Package: wnpp
Severity: wishlist
Owner: Francois Marier <francois <at> debian.org>

* Package name    : flatzebra
  Version         : 0.1.1
  Upstream Author : Pierre Sarrazin <sarrazip <at> sarrazip.com>
* URL             : http://perso.b2b2c.ca/sarrazip/dev/burgerspace.html
* License         : GPL
  Programming Lang: C++
  Description     : Generic Game Engine library

flatzebra is a simple generic C++ game engine library supporting 2D
double-buffering.

It is required for the new version of the burgerspace package and it
replaces the gengameng library from the same author.

Once it's in Debian, it would allow for the packaging of these other
games:

- batrachians (http://perso.b2b2c.ca/sarrazip/dev/batrachians.html)
- cosmosmash (http://perso.b2b2c.ca/sarrazip/dev/cosmosmash.html)
- afternoonstalker (http://perso.b2b2c.ca/sarrazip/dev/afternoonstalker.html)

Michael Biebl | 1 Nov 06:38
Picon
Favicon

Re: Bug#438665: Orphaned packages with quite some users

Bart Samwel schrieb:
> Joey Hess wrote:
>> Raphael Hertzog wrote:
>>> The problem is not so much on manually installed package but on initial
>>> installation. I'm not sure what would get installed via the laptop
>>> task if
>>> we made that a Recommends...
>>
>> d-i can't afford to install recommends by default (best way to change
>> that is to make all uses of recommends sane to be installed by default).
>>
>> So the laptop task would need to track and list the recommends. Doing
>> something smarter like only installing given recommends on laptop
>> hardware that can use them would also be an option.
> 
> I wouldn't mind having the packages installed in the laptop task if that
> fixes it. However, the laptop task currently uses the task-fields

Given that acpi-support is going to be deprecated in favor of
pm-utils/hal [1] I'd rather see acpi-support removed from the
laptop-task completely.

@joeyh: do you prefer a bug against tasksel to track this issue?

Cheers,
Michael

[1] https://wiki.ubuntu.com/PMUtilsSpec
--

-- 
Why is it that all of the instruments seeking intelligent life in the
(Continue reading)

Robert Edmonds | 1 Nov 07:38
Picon
Favicon

Bug#448810: ITP: fcapture -- network flow capture utility

Package: wnpp
Owner: "Robert S. Edmonds" <edmonds <at> debian.org>
Severity: wishlist

* Package name    : fcapture
  Version         : 0.0.1
  Upstream Author : me
* URL             : http://people.debian.org/~edmonds/fcapture/
* License         : MIT/X11
  Programming Lang: C
  Description     : network flow capture utility

 fcapture is a utility to capture and dump IPv4 TCP/UDP flow information
 from a network interface or pcap save file.  The accompanying fcapdump
 utility converts these flow capture dump files into human readable output.
 .
 fcapture can monitor high speed links and is more frugal in terms of disk
 space and CPU usage than similar programs like argus which use more
 detailed flow log formats.

--

-- 
Robert Edmonds
edmonds <at> debian.org
Joey Hess | 1 Nov 07:48
Picon
Favicon
Gravatar

Re: Bug#438665: Orphaned packages with quite some users

Bart Samwel wrote:
> I wouldn't mind having the packages installed in the laptop task if that 
> fixes it. However, the laptop task currently uses the task-fields method, 
> which AFAICT means that the dependent packages should list themselves as 
> being part of the laptop task, something that will take quite some effort 
> if we want to do it.

No, Task fields are added via overrides taken from tasksel.

--

-- 
see shy jo
Christian Perrier | 1 Nov 08:47
Picon
Favicon
Gravatar

Re: XS-Vcs-*, XS-X-Vcs-* and friends

Quoting Romain Francoise (rfrancoise <at> debian.org):
> Willi Mann <willi <at> wm1.at> writes:
> 
> > Why did you not search for XS-Vcs in general?
> 
> Because packages using XS-Vcs-Browse are easy to catch, you can just
> look at the Sources file and filter on 'Vcs-Browse'.  Since the
> other XS-Vcs-* fields get normalized to legit values, catching them
> requires unpacking all the source packages.
> 
> BUT! you may be interested in the following packages, which use
> XS-X-Vcs-* headers and are also easy to catch:

So, these should now use Vsc-*: fields ?

For shadow, we have now:

XS-X-Vcs-Svn: svn://svn.debian.org/svn/pkg-shadow/trunk

So, we should use:

Vcs-Svn: svn://svn.debian.org/svn/pkg-shadow/trunk

(Or "Vcs-svn"?)

(we also should correct the URL as we recently integrated upstream in
our SVN repository and therefore changed the SVN layout, but that's
another story)

(Continue reading)


Gmane