Re: Handling of removed packages

[Daniel Burrows]

On Thu, May 29, 2008 at 06:17:44PM +0200, Frans Pop <[EMAIL PROTECTED]> was 
heard to say:
> James Vega wrote:
> > As of version 0.4.11, this does happen.  From the NEWS file:
> >   * Command-line updates in aptitude will now list packages that are
> > newly obsolete.  This doesn't work when a source is removed and
> > all its packages become obsolete, for technical reasons.
> 
> Hmm. New Debian release. User uses codenames in sources.list.
> 
> # sed -i "s/etch/lenny/" /etc/apt/sources.list
> # aptitude update
> 
> Does this fit in the exception listed above? I would think yes and in that 
> case the only use case we really care about would not be supported.
> Maybe I'm reading that wrong though or is "source" defined at a higher level 
> than I think it is.

  Here's what happens: aptitude update after editing sources.list will
initialize itself as usual, update the package lists, then re-read them
and looks for packages that weren't obsolete before.

  The problem is that in the initialization procedure, apt will only
read package lists that are mentioned in sources.list.  So as far as
aptitude knows, all the packages that are currently installed from etch
(in your example) were already obsolete before the lists are even
updated, and so they won't show up in the list of new obsolete packages.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the ftp team

[Josip Rodin]

On Fri, May 30, 2008 at 01:08:42AM +0200, Joerg Jaspert wrote:
>  - Britney, *the* central tool of the release team to manage the testing
>distribution, finally lives with the release team[9], where it belongs
>to, and is no longer run by us.

It's very good to see such decentralization. Do share the burden :)

>  - We added some new and long-awaited pseudo packages.

Speaking of which, can you please also do the right thing and give
the Debian pseudo-packages list to the BTS admins, where this really
belongs, so that this too can stop being an issue?

I've documented the full rationale in http://bugs.debian.org/449097
a while ago...

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Generated changes and patch systems

[Neil Williams]

On Thu, 2008-05-29 at 11:56 -0700, Russ Allbery wrote:
> Simon McVittie <[EMAIL PROTECTED]> writes:
> 
> > Here's how gtk-doc *used to* work:
> >
> > * gtk-doc parses source code and writes out skeletal tmpl/*.sgml
> > * svn ci -m 'initial version of gtkdoc templates' tmpl
> > * upstream doc author inserts content into tmpl/*.sgml
> > * svn ci -m 'wrote some docs' tmpl
> > * gtk-doc parses source code (to pick up any new functions) + tmpl/*.sgml,
> >   and merges them
> > * svn ci -m 'yay gtkdoc' tmpl
> > * ...
> >
> > This is, as you've noticed, insane. Sane upstreams now write all the
> > content for the documentation in /** */ comments in the source code, so
> > the tmpl/*.sgml are purely generated and can safely be omitted from
> > source-code control. (I have no opinion on whether your upstream is sane
> > or not - please check.)
> >
> > However, the "no rule to make tmpl/*.sgml" issue still exists, as a
> > relic of the old build process.
> 
> Thank you for the explanation!  This now makes much more sense.

Same here - I'm glad there was an explanation for this behaviour, it was
driving me nuts.
;-)

> Sounds to me like the first thing to try would be to just regenerate all
> of the tmpl/*.sgml files via gtk-doc and delete them in the clean rule and
> see if that works properly for this project.  That's what I'd do, at
> least; that ensures a clean build without putting artifacts in the
> *.diff.gz.

Got a few other things to do first but yes, I will explore that before
uploading the new upstream version. Thanks both.

-- 
Neil Williams <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: Bits from the ftp team

[Thomas Viehmann]

On 2008-05-30 10:32:00.00 Josip Rodin <[EMAIL PROTECTED]> wrote:

>  - We added some new and long-awaited pseudo packages.


Speaking of which, can you please also do the right thing and give  
the Debian pseudo-packages list to the BTS admins,

where this really belongs, so that this too can stop being
an issue?


Pseudo-packages seem to live in the package name space, arguably a  
ftpteam domain.


Kind regards

T.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Handling of removed packages

[Marc 'HE' Brockschmidt]

Wolf Wiegand <[EMAIL PROTECTED]> writes:
> Marc 'HE' Brockschmidt wrote:
>> For some time now, I have been thinking about the problem of packages
>> which are removed from the archive at some point, without an (enforced)
>> transition to a new package name. Users of such packages keep them
>> around, usually never noticing the fact that no security (or other)
>> support is available anymore.
> Maybe it should be mandatory to always have a transition package for
> packages which are being removed from the archives? For example, when
> package X_0.1 is to be removed from the archive, there has to be a
> transition to a package X-obsoleted_0.1 (which is in fact the same as
> X_0.1).

That would force us to keep the packages in the next release.

Marc
-- 
BOFH #81:
Please me, I have to circuit an AC line through my head to get this
database working.


pgpKvWOQkoYgS.pgp
Description: PGP signature

Bug#483656: ITP: libsub-identify-perl -- Retrieve names of code references

[eloy]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyżaniak (eloy)" <[EMAIL PROTECTED]>


* Package name: libsub-identify-perl
  Version : 0.3
  Upstream Author : Rafael Garcia-Suarez (rgarciasuarez at gmail dot com)
* URL : http://search.cpan.org/dist/Sub-Identify/
* License : Dual: Artistic/GPL
  Programming Lang: Perl
  Description : Retrieve names of code references

 Sub::Identify allows you to retrieve the real name of code references. For
 this, it uses perl's introspection mechanism, provided by the B module.
 .
 It provides four functions : sub_name returns the name of the
 subroutine (or __ANON__ if it's an anonymous code reference),
 stash_name returns its package, and sub_fullname returns the
 concatenation of the two.
 .
 The fourth function, get_code_info, returns a list of two elements,
 the package and the subroutine name (in case of you want both and are worried
 by the speed.)
 .
 In case of subroutine aliasing, those functions always return the
 original name.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to pl_PL.UTF-8)
Shell: /bin/sh linked to /bin/bash



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Generated changes and patch systems

[Simon McVittie]

On Thu, 29 May 2008 at 11:56:37 -0700, Russ Allbery wrote:
> Simon McVittie <[EMAIL PROTECTED]> writes:
> > However, the "no rule to make tmpl/*.sgml" issue still exists, as a
> > relic of the old build process.
[...]
> Sounds to me like the first thing to try would be to just regenerate all
> of the tmpl/*.sgml files via gtk-doc and delete them in the clean rule and
> see if that works properly for this project.

Yeah, deleting tmpl/*.sgml during clean would probably be a good start; but
remember to do `touch tmpl/gtkdocs-makefile-sucks.sgml` or something before
running make!

Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483661: ITP: r-cran-amelia -- R package for handling missing data

[Chris Lawrence]

Package: wnpp
Severity: wishlist
Owner: Chris Lawrence <[EMAIL PROTECTED]>

* Package name: r-cran-amelia
  Version : 1.1-29
  Upstream Author : James Honaker, Gary King, Matthew Blackwell
* URL : http://gking.harvard.edu/amelia/
* License : GPLv2 or later
  Programming Lang: R
  Description : R package for handling missing data

Amelia II "multiply imputes" missing data in a single cross-section
(such as a survey), from a time series (like variables collected for
each year in a country), or from a time-series-cross-sectional data
set (such as collected by years for each of several countries). Amelia
II implements our bootstrapping-based algorithm that gives essentially
the same answers as the standard IP or EMis approaches, is usually
considerably faster than existing approaches and can handle many more
variables. Unlike Amelia I and other statistically rigorous imputation
software, it virtually never crashes (but please let us know if you
find to the contrary!). The program also generalizes existing
approaches by allowing for trends in time series across observations
within a cross-sectional unit, as well as priors that allow experts to
incorporate beliefs they have about the values of missing cells in
their data. Amelia II also includes useful diagnostics of the fit of
multiple imputation models. The program works from the R command line
or via a graphical user interface that does not require users to know
R.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25.4 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Handling of removed packages

[Wolf Wiegand]

Hi,

Marc 'HE' Brockschmidt wrote:

> Wolf Wiegand <[EMAIL PROTECTED]> writes:
> > Maybe it should be mandatory to always have a transition package for
> > packages which are being removed from the archives? For example, when
> > package X_0.1 is to be removed from the archive, there has to be a
> > transition to a package X-obsoleted_0.1 (which is in fact the same as
> > X_0.1).
> 
> That would force us to keep the packages in the next release.

True, I hadn't thought about that. Maybe this could be done in point
releases to the stable distribution, and by adding a note to the release
notes for the stable -> new-stable upgrade that all point releases
should be installed prior to upgrading to the new stable release. But I
don't really like this idea as well.


Cheers,

Wolf

-- 
Büroschimpfwort des Tages: Systemapokalyptiker - IT-Mitarbeiter, der gern 
behauptet, das neue System fahre "gegen die Wand" oder treibe die Firma in die 
Pleite. Seine typische Reaktion: "Ich mach' jetzt gleich gar nichts mehr!" 
(Bernd Leibowitz)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483685: ITP: pkcs11-dump -- Dump PKCS#11 token content

[Max Vozeler]

Package: wnpp
Severity: wishlist
Owner: Max Vozeler <[EMAIL PROTECTED]>

* Package name: pkcs11-dump
  Version : 0.2
  Upstream Author : Alon Bar-Lev <[EMAIL PROTECTED]>
* URL : http://alon.barlev.googlepages.com/pkcs11-utilities
* License : BSD-3, BSD-like for PKCS#11 headers
  Programming Lang: C++
  Description : Dump PKCS#11 token content

 pkcs11-dump is a program to query PKCS#11 (cryptoki) provider 
 modules for objects available on a specific crypto device and
 dump them to stdout in a human-readable format.
 . 
 This package is mostly interesting for people familiar with
 PKCS#11 who are developing or analyzing a PKCS#11 module or
 like to get a detailed view of objects on a crypto device.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: libarchive-any-perl -- Perl module to deal with file archives in any format

[Ernesto Hernandez-Novich]

Package: wnpp

* Package name: libarchive-any-perl
  Version: 0.0932
  Upstream Author: Clint Moore <[EMAIL PROTECTED]>
* URL: http://search.cpan.org/dist/Archive-Any/
* License: GPl/Artistic

Description:

The Archive::Any module allows a Perl program to create, manipulate,
read, and write different archive formats (tarballs and Zip files)
through a single API.
-- 
Ernesto Hernández-Novich - Linux 2.6.18 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Handling of removed packages

[Russ Allbery]

Mike Bird <[EMAIL PROTECTED]> writes:

> ssh test-box
>  apt-get update
>  apt-get upgrade
>  tests
> ssh live-server
>  apt-get update
>  ... sometimes gets a slightly different package list

Oh, yes.  That's certainly true.

> The only time we use apt-get is as a convenience when testing different
> package versions.
>
> All packages on live servers and workstations are installed with "dpkg
> -i" to ensure we're using a tested combination.  We could manually copy
> the package lists or "apt-get install foo=x.y.z" but "dpkg -i" is more
> convenient.

Whatever works for you.  :)  We use aptitude for everything in production
and update the package lists nightly as part of our jobs to report which
packages are out of date, and have never had any problems with that.

I'd personally consider your method to be a poor time versus risk
tradeoff, but you may value your time lower and your risk higher than I
do.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Handling of removed packages

[Mike Bird]

On Fri May 30 2008 10:20:51 Russ Allbery wrote:
> Mike Bird <[EMAIL PROTECTED]> writes:
> > All packages on live servers and workstations are installed with "dpkg
> > -i" to ensure we're using a tested combination.  We could manually copy
> > the package lists or "apt-get install foo=x.y.z" but "dpkg -i" is more
> > convenient.
>
> Whatever works for you.  :)  We use aptitude for everything in production
> and update the package lists nightly as part of our jobs to report which
> packages are out of date, and have never had any problems with that.
>
> I'd personally consider your method to be a poor time versus risk
> tradeoff, but you may value your time lower and your risk higher than I
> do.

There's a bunch of scripts which avoid much labor time.
The main downside is the longer elapsed time to roll
out Debian security updates, although we could always
use apt-get if a particular situation warranted.

--Mike Bird


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483717: ITP: pkcs11-data -- Manage PKCS#11 data objects

[Max Vozeler]

Package: wnpp
Severity: wishlist
Owner: Max Vozeler <[EMAIL PROTECTED]>

* Package name: pkcs11-data
  Version : 0.7
  Upstream Author : Alon Bar-Lev <[EMAIL PROTECTED]>
* URL : http://alon.barlev.googlepages.com/pkcs11-utilities
* License : GPL-2
  Programming Lang: C
  Description : Manage PKCS#11 data objects

  pkcs11-dump is a program to manage data objects residing
  on PKCS#11 (Cryptoki) enabled crypto devices.

I will hold off uploading the package for now because 
it is GPL and wants to be linked against libcrypto, but
there is no explicit GPL exception.

(To be precise, it doesn't link to libcrypto itself but
to libpkcs11-helper, which links to libcrypto).

I've contacted the upstream author (and sole copyright 
holder) asking for an exception to be added.

In the meantime, if anyone is interested, the packaging can
be found on git://git.debian.org/~xam/pkcs11-data.git

Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFH: Multiarch capable toolchain as release goal

[Hector Oron]

Hello,

Interesting matter ! Multiarch :-)

I have experienced the same treatment from binutils maintainer, he did
not answer to my mails or bug reports (393841,432772). Tired of this
and as it is an upstream matter i sent a patch upstream and it got
accepted. For my surprise, it is very close to 369064 patch for
genscripts.sh.

ld/ChangeLog
2007-12-24  Hector Oron  <[EMAIL PROTECTED]>
* genscripts.sh (LIB_PATH): Include both {target_alias} and
{TOOL_LIB} in the search paths for multilibbed targets.

See patch at http://sourceware.org/ml/binutils/2007-11/msg00239.html

Goswin et al. is it helpful for binutils multiarch for lenny+1 ?

Regards

-- 
 Héctor Orón


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483719: ITP: python-scikits-openopt -- Python module for numerical optimization

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko <[EMAIL PROTECTED]>


* Package name: python-scikits-openopt
  Version : 0.17
  Upstream Author : Dmitrey Kroshko <[EMAIL PROTECTED]>, Matthieu Brucher 
<[EMAIL PROTECTED]>
* URL : http://scipy.org/scipy/scikits/wiki/OpenOptInstall
* License : BSD-3
  Programming Lang: Python
  Description : Python module for numerical optimization

 Numerical optimization framework developed in Python which provides
 connections to lots of solvers with easy and unified OpenOpt
 syntax. Problems which can be tackled with OpenOpt
  * Linear Problem (LP)
  * Mixed-Integer Linear Problem (MILP)
  * Quadratic Problem (QP)
  * Non-Linear Problem (NLP)
  * Non-Smooth Problem (NSP)
  * Non-Linear Solve Problem (NLSP)
  * Least Squares Problem (LSP)
  * Linear Least Squares Problem (LLSP)
  * Mini-Max Problem (MMP)
  * Global Problem (GLP)
 .
 A variety of solvers is available (e.g. IPOPT, ALGENCAN).

Tentative packaging and package are available from
http://itanix.rutgers.edu/rumba/dists/sid/perspect/binary-all/python/python-scikits-openopt_0.18~svn992-1~pre3_all.deb
http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/python/python-scikits-openopt_0.18~svn992-1~pre3.dsc

feedback is welcome

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (900, 'testing'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483721: ITP: qcontrol -- hardware control for QNAP TS-109 and TS-209

[Frans Pop]

Package: wnpp
Severity: wishlist
Owner: Frans Pop <[EMAIL PROTECTED]>


* Package name: qcontrol
  Version : 0.4.1
  Upstream Author : Byron Bradley <[EMAIL PROTECTED]>
* URL : http://qnap.nas-central.org/index.php/PIC_Control_Software
* License : GPL
  Programming Lang: C
  Description : hardware control for QNAP TS-109 and TS-209

 Allows to send commands to the microcontroller of supported devices,
 for example to change leds or sound a buzzer.
 .
 Depending on the device it can also monitor for example for button
 presses or temperature, with events triggering actions defined in the
 configuration file.
 .
 Supported devices at this time are the QNAP TS-109 and TS-209 but the
 code is extensible so more devices may be added in future releases.

The program is still in alpha state, but usable for simple things such
as controlling status leds or sounding the buzzer. It's not quite
ready to monitor temperature to dynamically control the fan speed.

The QNAP TS-109 and TS-209 are arm(el) NAS devices that should be supported
in Lenny.

The original name was piccontrol, which we deemed too generic (name
implies support for a broader range of devices than it actually does).
The author was so kind as to change the name to qcontrol, where the q is
a reference to QNAP, but which is general enough that it will not be a
problem if support for other devices is added later.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the ftp team

[Josip Rodin]

On Fri, May 30, 2008 at 11:03:15AM +0200, Thomas Viehmann wrote:
> On 2008-05-30 10:32:00.00 Josip Rodin <[EMAIL PROTECTED]> wrote:
> >>  - We added some new and long-awaited pseudo packages.
> 
> >Speaking of which, can you please also do the right thing and give  
> >the Debian pseudo-packages list to the BTS admins,
> >where this really belongs, so that this too can stop being
> >an issue?
> 
> Pseudo-packages seem to live in the package name space, arguably a  
> ftpteam domain.

They live in the same namespace *in the BTS*. They don't live in the same
namespace in dak, the Packages files, or the users' systems (except by way
of reportbug(1), which is an interface to the BTS).

This is really just a historical detail... had the early debbugs developers
introduced a pseudo-header called Pseudo-Package: or Topic: or whatever, to
complement Package:, we never would have called them "pseudo-packages" in
the first place.

Thinking about it, it almost sounds like this overloading of the prefix
pseudo- was done for comedic effect. :)

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the ftp team

[Raphael Hertzog]

On Fri, 30 May 2008, Joerg Jaspert wrote:
> Some time after this mail we will give a few tasks to those who
> volunteer to test their ability and then (maybe) have a few new members
> in our team in the not too distant future.

I would suggest that developing a patch for
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457345 would make a
good start for anyone who wants to become ftpmaster.

It's a change that I'd like to have early in lenny+1 so it's probably a
good idea to start before lenny's release and setup a test repository
before to be able to play with. :)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mouse configuration during installation needs improvement

[Stephen Powell]

Since my initial post I have done some research on the
subject of mouse support in the Linux kernel.  I can
see now why my suggestion was met with such strong
opposition: it goes counter to the direction the
kernel has been going since 2.5.  With such a sweeping
redesign of mouse support since 2.4, I think I need to
do some experimentation to see if gpm still provides
one of the key benefits that it once provided, namely
the ability to resurrect a dead PS/2 mouse after
unplugging and replugging.  On older kernels, I could
issue the following command which nearly always
regained the use of the mouse in a virtual console:

/etc/init.d/gpm restart

And if X was set up to use /dev/gpmdata, this would of
course also resurrect the mouse in X too.  Thomas
Hood, in his web page for Debian GNU Linux on an IBM
Thinkpad 600, specifically recommends this
(http://panopticon.csustan.edu/thood/tp600lnx.htm). 
However, this information appears to have been written
when he was running a 2.4 kernel.

On my system, gpm is currently configured to use the
legacy mouse port /dev/psaux, but it appears from what
I've read that this "device" no longer gives the
direct access to the physical port that it once did. 
I wouldn't be surprised if gpm has thereby lost its
ability to resurrect the mouse.  I'll do some testing
over the weekend and let you know what I find out.



  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the ftp team

[Joerg Jaspert]

On 11401 March 1977, Raphael Hertzog wrote:

>> Some time after this mail we will give a few tasks to those who
>> volunteer to test their ability and then (maybe) have a few new members
>> in our team in the not too distant future.
> I would suggest that developing a patch for
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457345 would make a
> good start for anyone who wants to become ftpmaster.

Oh, would you? I would not. Its not "a good start for anyone who wants
to become ftpmaster"

> It's a change that I'd like to have early in lenny+1 so it's probably a
> good idea to start before lenny's release and setup a test repository
> before to be able to play with. :)

If *you* want to see it, you should do it.

-- 
bye, Joerg
 Sesse: I doubt that many people will switch network


pgpCyv9f41iH1.pgp
Description: PGP signature

Re: Bug#449097: Bits from the ftp team

[Don Armstrong]

On Fri, 30 May 2008, Josip Rodin wrote:
> They live in the same namespace *in the BTS*. They don't live in the
> same namespace in dak, the Packages files, or the users' systems
> (except by way of reportbug(1), which is an interface to the BTS).

We just have to be careful that we never allow a psuedopackage which
will be a package, and vice versa. This requires coordination between
ftpmasters and [EMAIL PROTECTED], but that's presumably fairly trivial.
[That ftpmaster were in charge of pseudopackages is likely for
hysterical raisins.]

But in any event, I think ftpmaster are in violent agreement about
this fact, and it's just a matter of the fiddly bureaucratic bits.


Don Armstrong

-- 
 why the hell does kernel-source-2.6.3 depend on xfree86-common?
 It... Doesn't?
 good point

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]