Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Steve Langasek]

On Tue, May 03, 2005 at 03:54:10AM +0200, Adrian Bunk wrote:
> On Fri, Apr 29, 2005 at 09:10:10PM -0700, Steve Langasek wrote:
> > On Fri, Apr 29, 2005 at 10:52:02PM -0500, Adam M. wrote:

> > > >Ideally, we would have agreement to update all of the following packages 
> > > >to
> > > >libmysqlclient12 at the same time:

> > > I would suggest that libmysqlclient14 should be used if possible. MySQL
> > > has changed the way passwords are stored in the database and this
> > > prevents clients from connecting to MySQL databases unless old-passwords
> > > option is enabled (which it is in Debian). libmysqlclient12 clients
> > > cannot connect to MySQL 4.1.x and newer databases unless old password is
> > > explicitly used or enabled.

> > That's not true.  It's only libmysqlclient10 that can't connect using the
> > new protocol.
> >...

> Please check the facts before spreading such misinformation.

Indeed, the facts *were* checked; a libmysqlclient12 can connect to a MySQL
4.1 server on Debian using the default password hash algorithm.

Unfortunately, it turns out this is because the Debian package has changed
the default.

Had I been aware of this three months ago, I almost certainly would have
been trying to get people to switch to libmysqlclient14 instead of
libmysqlclient12. :/

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Adrian Bunk]

On Tue, May 03, 2005 at 12:15:43AM -0700, Steve Langasek wrote:
> On Tue, May 03, 2005 at 03:54:10AM +0200, Adrian Bunk wrote:
> > On Fri, Apr 29, 2005 at 09:10:10PM -0700, Steve Langasek wrote:
> > > On Fri, Apr 29, 2005 at 10:52:02PM -0500, Adam M. wrote:
> 
> > > > >Ideally, we would have agreement to update all of the following 
> > > > >packages to
> > > > >libmysqlclient12 at the same time:
> 
> > > > I would suggest that libmysqlclient14 should be used if possible. MySQL
> > > > has changed the way passwords are stored in the database and this
> > > > prevents clients from connecting to MySQL databases unless old-passwords
> > > > option is enabled (which it is in Debian). libmysqlclient12 clients
> > > > cannot connect to MySQL 4.1.x and newer databases unless old password is
> > > > explicitly used or enabled.
> 
> > > That's not true.  It's only libmysqlclient10 that can't connect using the
> > > new protocol.
> > >...
> 
> > Please check the facts before spreading such misinformation.
> 
> Indeed, the facts *were* checked; a libmysqlclient12 can connect to a MySQL
> 4.1 server on Debian using the default password hash algorithm.
> 
> Unfortunately, it turns out this is because the Debian package has changed
> the default.
> 
> Had I been aware of this three months ago, I almost certainly would have
> been trying to get people to switch to libmysqlclient14 instead of
> libmysqlclient12. :/


What exactly did you check?
Where did libmysqlclient10 fail for you while libmysqlclient12 worked?

To confirm that libmysqlclient10 works fine with MySQL 4.1 servers, I 
recompiled PHP4 with libmysqlclient10 and it worked like a charm (with 
old_passwords in the MySQL server).


> Steve Langasek

cu
Adrian

BTW: The interaction between the two MySQL server packages in
 unstable/sarge at purge time is *ahem* interesting.
 They are really time bombs ready to explode in a few days or 
 years.
 It seems RC bugs are required for both of them...

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Status of PHP5?

[Mark Brown]

On Tue, May 03, 2005 at 04:04:44AM +0200, Adrian Bunk wrote:
> On Mon, Apr 25, 2005 at 07:57:13PM +0200, Joerg Jaspert wrote:

> > And then there is this yada packaging you used.

> Not that I was a friend of yada, but AFAIK it's allowed for a maintainer 
> to use whatever tools he wants for his packaging.

> If this is wrong and I missed a part of Debian policy not allowing yada, 
> RC bugs should be filed against all packages using yada.

The issue wasn't the use of yada per se, it was the use of yada in the
context of something like updating PHP where there are existing packages
and maintainers.  Using one of the more obscure helper packages is a
sign of lack of coordination rather than outright bugginess.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

A way _not_ to handle bugs

[Adrian Bunk]

severity 306015 grave
thanks

Hi Steve,

first of all, if you downgrade a bug only a good hour after I upgraded 
it, it would be nice if you would:
- Cc me
- send a better explanation than "This is not a missing dependency, feh"

I know that downgrading RC bugs makes your RC bugs metric look better, 
but this bug is a good example why only working on improving a metric is 
a bad thing.

In my testing, e.g. php4 from woody together with php4-mysql from sid is 
_not_ a working combination.

Please either explain why "this is not a missing dependency" or promise 
to be a little more careful in the future instead of blindly downgrading 
bugs.

TIA
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[sean finney]

On Tue, May 03, 2005 at 10:22:04AM +0200, Adrian Bunk wrote:
> BTW: The interaction between the two MySQL server packages in
>  unstable/sarge at purge time is *ahem* interesting.
>  They are really time bombs ready to explode in a few days or 
>  years.
>  It seems RC bugs are required for both of them...

if there's a problem, please file a bug about it instead of making
vague remarks like this.

sean

-- 


signature.asc
Description: Digital signature

Re: Status of 'sarge' for the amd64 architecture

[Goswin von Brederlow]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> On Sat, Apr 30, 2005 at 11:50:30AM +0200, Goswin von Brederlow wrote:
>> 1. release team
>> 
>> Another arch to sync. And, as with every arch, there would be some
>> packages that fail just there. There are still a lot of amd64 specific
>> FTBFS bugs (lots of them with patches) that would all become RC. The
>> RC count would double overnight at least for a few weeks. (yeah, it
>> would be back down if this had happened weeks ago)
>
> Besides the fact that I think the RC bug count metric isn't a good 
> metric for measuring the quality (it's a good example for the known fact 
> that in such cases only the metric is improved, but other things that 
> aren't measured by this metric tend to be ignored), FTBFS bugs on 
> architectures a package was never built on are not considered RC.
>
> Are there any FTBFS issues on amd64 in important packages that aren't 
> easily solvable?

Some very few package broke with newer uploads. So those would be
counted as "did build before" by us. Esspecially if the old version is
still in sarge. For the rest you are right, they would still only be
important and not RC.

Then there are the packages with bugs in sarge but not in sid. Again
you can keep them all non RC (except util-linux and syslinux which are
needed for a release) and .

But all of those can easily be fixed by a weekend of aggressive NMUing.


>> 2. security ream
>> 
>> Who knows about amd64? Who is able to debug code to see if security
>> problems also exist there? Who will maintain the amd64 security buildd
>
> What kind of amd64 specific security problems do you expect (except for 
> kernel issues)?

I guess kernel problems. But always expect the unexpected. At a
minimum they need a system meeting their security secrecy
requirements.

>> (since us Non-DDs are not allowed)? Who will get the wanna-build
>> admins to add the amd64 buildd? Seeing as after over 6 month there are
>> still 2 of the old archs without a security buildd for testing this
>> seems to be a realy big problem.
>
> What is the real problem?
>
> Getting hardware?
> Getting money for hardware?
> Finding administratores for the machines?

Beats me.

>> 3. britney
>> 
>> One more arch, 15K more packages to consider. Britney needs more ram,
>> more time, gets slower overall and probably fails more often. More
>> hints needed costing more manual time.
>
> Why are more hints needed?
>
> And if the problem is Britney being resource hungry, adding more RAM to 
> the computer it's running on might be an option?

Might be, might not be. I think the britney algorithm needs
rewriting. There is something seriously wrong with the current
one. Getting killed by out-of-memory after using over 1.2Gb ram
doesn't sound correct.

>> 4. D-I docs and CDs
>> 
>> There are no docs covering amd64 yet as nobody has done any work in
>> that regard. Since amd64 is basicaly just a i386 on steroids adapting
>> those docs should be easy. But it has to be done. There are also some
>> (hopefully minor) quircks left in debian-cd to investigate. Might be
>> caused by the missing docs.
>
> And you have to do this work for your separate amd64 release.
>
>> I do however feel that the need of Debians users to have amd64 over
>> the next 2 years till etch is out far outweights the inconvenience of
>> adding it. That's why the amd64 team, recently with much entusiasm
>> from other parts of the debian foodchain, is doing the inofficial
>> release in parallel with sarge.
>
> Which creates extra work...

At least it will be a test for what the SCC/Vancouver proposal will
mean. LOTS OF PAIN.

>> Sources are the same, cdimages will be on cdimage.d.o, security
>> updates will follow debian closely. All that differs for users is that
>> ftp.debian.org is amd64.debian.net for the main archive and /debian
>> becomes /debian-amd64 for mirros. Maybe at some point someone up there
>> will decide to embrace amd64, move the files over to ftp-master and
>> call it official post datum.
>
> And security fixes will be provided at which location?

amd64.debian.net:/debian/dists/stable-security/ probably.

MfG
Goswin


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

Re: Status of PHP5?

[Adrian Bunk]

On Tue, May 03, 2005 at 11:26:19AM +0100, Mark Brown wrote:
> On Tue, May 03, 2005 at 04:04:44AM +0200, Adrian Bunk wrote:
> > On Mon, Apr 25, 2005 at 07:57:13PM +0200, Joerg Jaspert wrote:
> 
> > > And then there is this yada packaging you used.
> 
> > Not that I was a friend of yada, but AFAIK it's allowed for a maintainer 
> > to use whatever tools he wants for his packaging.
> 
> > If this is wrong and I missed a part of Debian policy not allowing yada, 
> > RC bugs should be filed against all packages using yada.
> 
> The issue wasn't the use of yada per se, it was the use of yada in the
> context of something like updating PHP where there are existing packages
> and maintainers.  Using one of the more obscure helper packages is a
> sign of lack of coordination rather than outright bugginess.

I said at the beginning of my email, that I do think the PHP4 <-> PHP5
maintainer situation is a valid reason for rejecting these packages - 
independent of the kind of packaging.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Sarge release for amd64 - Please help to fix the remaining bugs

[Adrian Bunk]

On Tue, May 03, 2005 at 07:08:50AM -0400, sean finney wrote:
> On Tue, May 03, 2005 at 10:22:04AM +0200, Adrian Bunk wrote:
> > BTW: The interaction between the two MySQL server packages in
> >  unstable/sarge at purge time is *ahem* interesting.
> >  They are really time bombs ready to explode in a few days or 
> >  years.
> >  It seems RC bugs are required for both of them...
> 
> if there's a problem, please file a bug about it instead of making
> vague remarks like this.

I already did this (#307473).

It took a bit of time to properly test it and understand all 
implications of this problem which is why I didn't immediately send the 
bug.

>   sean

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: [Pre-RFA] Intending to drop twenty-some packages

[Martin Michlmayr]

* Dirk Eddelbuettel <[EMAIL PROTECTED]> [2005-05-02 19:50]:
> | maintainer.  Should they be transferred to
> | [EMAIL PROTECTED] too?
> 
> Not necessarily. They all are on their way out:
...
> I will file bug reports against ftp.debian.org for octave-ci and
> octave-matcompat once sarge is out.  Assuming that that will happen :)

OK, noted.

> | Great.  Seems most of the packages have been adopted now.
> 
> Yes. My count got down from low-80s to 67 before three new R packages crept
> in.  70 is still insane given my workload and other stuff so I have to see
> what I'll do about that.  A lot of it is R though ...

Let's include a list of your packages in case someone sees something
they'd like to help out with:

abind -- GNU R abind multi-dimensional array combination function
acepack -- GNU R package for regression transformations
beancounter -- A stock portfolio performance monitoring tool
boot -- GNU R package for bootstrapping functions from Davison and Hinkley
car -- GNU R Companion to Applied Regression by John Fox
cluster -- GNU R package for cluster analysis by Rousseeuw et al
date -- GNU R package for date handling
dbd-odbc -- Perl5 module for an ODBC driver for DBI
design -- GNU R regression modeling strategies tools by Frank Harrell
effects -- GNU R graphical and tabular effects display for glm models
fbasics -- GNU R package for financial engineering -- fBasics
fcalendar -- GNU R package for financial engineering -- fCalendar
fextremes -- GNU R package for financial engineering -- fExtremes
finance-streamer -- Perl5 module with interface to Datek Streamer
finance-yahooquote -- Perl module for retrieving stock quotes from Yahoo! 
Finance
fmultivar -- GNU R package for financial engineering -- fMultivar
foptions -- GNU R package for financial engineering -- fOptions
foreign -- GNU R package to read/write data from other stat. systems
fportfolio -- GNU R package for financial engineering -- fPortfolio
fseries -- GNU R package for financial engineering -- fSeries
ggobi -- Data visualization system for high-dimensional data
gregmisc -- GNU R package with miscellaneous functions by Greg Warnes et al
gretl -- The GNU Regression, Econometric & Time-Series Library -- development 
package
gsl -- GNU Scientific Library (GSL) -- development package
gsl-ref-html -- GNU Scientific Library (GSL) Reference Manual in html
gsl-ref-psdoc -- GNU Scientific Library (GSL) Reference Manual in postscript
gtkdevice -- GNU R Gtk device driver package
hmisc -- GNU R miscellaneous functions by Frank Harrell
its -- GNU R package for handling irregular time series
kernsmooth -- GNU R package for kernel smoothing and density estimation
lattice -- GNU R package for 'Trellis' graphics
linuxtrade -- A real-time stock market tracker and news console
lmtest -- GNU R package for diagnostic checking in linear models
mgcv -- GNU R package for multiple parameter smoothing estimation
multcomp -- GNU R package for multiple comparison procedures
mvtnorm -- GNU R package to compute multivariate Normal and T distributions
nlme -- GNU R package for (non-)linear mixed effects models
octave-ci -- Contributed functions for the GNU Octave language
octave-matcompat -- Empty transition package for octave-forge
octave2.0 -- Static libraries for the GNU Octave language (2.0 branch)
quadprog -- GNU R package for solving quadratic programming problems
quantlib -- Quantitative Finance Library -- example binaries
quantlib-python -- Python bindings for the Quantlib Quantitative Finance library
quantlib-refman -- Quantitative Finance Library -- reference manual
quantlib-refman-html -- Quantitative Finance Library -- reference manual in html
quantlib-ruby -- Ruby bindings for the Quantlib Quantitative Finance library
r-zoo -- GNU R package for totally ordered indexed observations
rcmdr -- GNU R platform-independent basic-statistics GUI
relimp -- GNU R package for inference on relative importance of regressors
repostools -- GNU R set of tools to interface and construct R repositories
rggobi -- GNU R package for the GGobi data visualization system
rgl -- GNU R package for three-dimensional visualisation using OpenGL
rgtk -- GNU R binding for Gtk
rmpi -- GNU R package interfacing MPI libraries for distributed computing
rodbc -- GNU R package for ODBC database access
rpart -- GNU R package for recursive partitioning and regression trees
rpvm -- GNU R package interfacing PVM libraries for distributed computing
rpy -- Python interface to the GNU R language and environment
rquantlib -- GNU R package interfacing the QuantLib finance library
rsprng -- GNU R interface to SPRNG (Scalable Parallel RNGs)
sandwich -- GNU R package for model-robust standard error estimates
sm -- GNU R package for kernel smoothing methods
smtm -- Show Me The Money is a configurable Perl/Tk stock ticker program
snow -- GNU R package for 'simple network of workstations'
sprng -- The SPRNG Scalable Parallel RNG library -- documentation package
strucchange -- GNU R package for structural cha

Re: More DDTP problems

[Daniel Macêdo Batista]

Em 27/4/2005, "Otavio Salvador" <[EMAIL PROTECTED]> escreveu:

>Hello folks,

Hi Otavio!

>
>Like I proposed, I converted all CVS repository to Subversion[1].
>
>1. http://svn.debian.org/wsvn/ddtp/,
>   svn://svn.debian.org/svn/ddtp/
>   svn+ssh://svn.debian.org/svn/ddtp/

I tried access now but the server is not available :(
[...]

>We really need to discuss how we will do the checking. One possible
>approuch could be use a derivation of how the kernel patches are now
>checked. I'll explain my proposal bellow:
>
> In each file we start to check, we add a footer commented (for
> example in C code):
>
> /*
> Checking: otavio; Started in: 2005-04-27
> */
>
> After we finished to check the code and have sure it doesn't have
> malicious code inside, we change it to:
>
> /*
> Sign-Off: otavio; Finished in: 2005-04-27
> */
>
> We should have, at last, two Signs to move the file to trunk. All
> this can be done by scripting (only the checking itself by a human)
> and looks fine to me.
>
> What you all think about it?

I aggree with this metodology. Let's wait the opinion by others.

Thanks by your iniciative!

>
>--
>O T A V I OS A L V A D O R
>-
> E-mail: [EMAIL PROTECTED]  UIN: 5906116
> GNU/Linux User: 239058 GPG ID: 49A5F855
> Home Page: http://www.freedom.ind.br/otavio
>-
>"Microsoft gives you Windows ... Linux gives
> you the whole house."
>
>
>--
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>

Re: Bug#288209: O: audio-cd -- Library to handle CDDB and low-level cd io calls

[Martin Michlmayr]

* Jeroen van Wolffelaar <[EMAIL PROTECTED]> [2005-01-02 14:52]:
> The current maintainer of audio-cd, Bart Warmerdam <[EMAIL PROTECTED]>,
> has orphaned this package.  If you want to be the new maintainer, please

> Description: Library to handle CDDB and low-level cd io calls
>  This module supplies the CDDB functionality and low level calls to CD
>  players.

Is anyone interested in adopting the audio-cd package?  It has been
orphaned for 120 days and has never been part of a stable release, but
I cannot remove it because disc-cover and yaret depend on it.  Is
anyone using this library and would like to maintain it?
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Upcoming removals

[Martin Michlmayr]

I intend to ask for removal of the following packages in the next few
days unless someone is willing to step up as maintainer.  All of these
packages have been orphaned for over 60 days and have never been part
of a stable release; none of them have any reverse (build-)dependencies.


#259581: O: bbconf -- A Blackbox configuration utility
Reported by: Martin Michlmayr <[EMAIL PROTECTED]>; 291 days old.

#263704: O: sced -- A program for creating 3D scenes.
Reported by: Enrique Zanardi <[EMAIL PROTECTED]>; 271 days old.
"ScEd has been unmaintained upstream since June 2000. In the meantime
Blender has become a killer free software app for 3D scene editing and
rendering"

#263874: O: simplecdrx -- SimpleCDR-X is a frontend for CD writing and mastering
Reported by: Benoit Joly <[EMAIL PROTECTED]>; 270 days old.

#279398: O: masqdialer -- daemon for remote control of masqueraded dialup links
Reported by: Martin Michlmayr <[EMAIL PROTECTED]>; 181 days old.

#279593: O: vcr -- v4l video capture program
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 180 days old.

#279505: O: linup -- Client for the Uptimes Project
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 180 days old.

#279816: O: vrel -- Virtual Reality Engine Language parser
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 179 days old.

#282426: O: ic35link -- Synchronization tools for the Siemens IC35 PDA
Reported by: Erich Schubert <[EMAIL PROTECTED]>; 162 days old.

#287985: O: cantus -- Gnome tool to mass-rename/tag mp3 and ogg files
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 123 days old.
obsoleted by cantus3 which is packaged already

#288007: O: strategoxt -- Language transformation tools for programmers
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 122 days old.

#288334: O: imagefs -- Creates a virtual FAT12 file system in a single file.
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 120 days old.

#288209: O: audio-cd -- Library to handle CDDB and low-level cd io calls
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 120 days old.

#289027: O: middleman -- web content caching and filtering proxy server
Reported by: Cedric Delfosse <[EMAIL PROTECTED]>; 116 days old.
"no longer maintained upstream"

#289430: O: libcgi-validate-perl -- Advanced CGI form parser and type validation
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 114 days old.

#292754: O: libcpanplus-perl -- Download and install perl modules from CPAN - 
in a modern way
Reported by: Marc Brockschmidt <[EMAIL PROTECTED]>; 93 days old.
wacky packaging and out of date with upstream

#297429: O: lw-per-installer -- Installer for Lispworks ANSI Common Lisp 
System, Personal Edition
Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.

#297432: O: lw-pro-installer-43 -- Installer for Xanalys Lispworks Common Lisp 
System, version 4.3
Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.

#297441: O: pdp1-lisp -- Early Lisp interpreter for a PDP-1 emulator
Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.

#297425: O: iozone3 -- Filesystem and Disk Benchmarking Tool
Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.

#297443: O: python-aima -- Python code for the an Artificial Intelligence book
Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.

#297426: O: langband -- The langband Common lisp game
Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.

#297427: O: langband-data -- The Langband sound/image/etc files for langband 
engine
Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.

#298151: O: gtk-engines-mac2 -- Mac2 theme for GTK+
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 59 days old.

#298386: O: libmp3hip -- A Python interface to the libmp3hip library
Reported by: Jeroen van Wolffelaar <[EMAIL PROTECTED]>; 57 days old.

-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Bug#288209: O: audio-cd -- Library to handle CDDB and low-level cd io calls

[Jereme Corrado]

Martin Michlmayr wrote:
> Is anyone interested in adopting the audio-cd package?  It has been
> orphaned for 120 days and has never been part of a stable release, but
> I cannot remove it because disc-cover and yaret depend on it.  Is
> anyone using this library and would like to maintain it?

I maintain disc-cover and would be happy to pick up libaudio-cd-perl
if no one objects.

-- 
Jereme Corrado <[EMAIL PROTECTED]>


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

Re: More DDTP problems

[Andreas Tille]

On Tue, 3 May 2005, Daniel [ISO-8859-1] Macêdo Batista wrote:
1. http://svn.debian.org/wsvn/ddtp/,
  svn://svn.debian.org/svn/ddtp/
  svn+ssh://svn.debian.org/svn/ddtp/
I tried access now but the server is not available :(
[...]
... it seems to be the case since about 1 hour. :-(
And even before I did not got any mail about my commits this morning ...
Kind regards
Andreas.
--
http://fam-tille.de

Re: A way _not_ to handle bugs

[Thomas Bushnell BSG]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> severity 306015 grave
> thanks
>
> Hi Steve,
>
> first of all, if you downgrade a bug only a good hour after I upgraded 
> it, it would be nice if you would:
> - Cc me
> - send a better explanation than "This is not a missing dependency, feh"

Looking at the bug log, it seems that you had no business increasing
the severity in the first place.  You didn't report the bug, you
aren't the maintainer, and now you are playing BTS wars.  It's up to
the maintainer and Steve, secondarily it's up to the submitter of the
bug, and it doesn't seem to concern you at all.

This bug does not make the package "unusable or mostly so" because it
has a trivial workaround available.  So it was wrong of you to mark it
grave, unless you are just seeking attention.  It might be "serious",
but the submitter himself thought it was "important".  You didn't give
any reasons for busting in and changing it.  That's wrong.  

Thomas


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

Re: More DDTP problems

[Otavio Salvador]

> "daniel" == Daniel Macêdo Batista <[EMAIL PROTECTED]> writes:

>> 1. http://svn.debian.org/wsvn/ddtp/,
>> svn://svn.debian.org/svn/ddtp/
>> svn+ssh://svn.debian.org/svn/ddtp/

daniel> I tried access now but the server is not available :(
daniel> [...]

I hope it come back soon.

>> What you all think about it?

daniel> I aggree with this metodology. Let's wait the opinion by
daniel> others.

Perfect.

daniel> Thanks by your iniciative!

You're welcome.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: A way _not_ to handle bugs

[Adrian Bunk]

On Tue, May 03, 2005 at 08:30:22AM -0700, Thomas Bushnell BSG wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
> 
> > severity 306015 grave
> > thanks
> >
> > Hi Steve,
> >
> > first of all, if you downgrade a bug only a good hour after I upgraded 
> > it, it would be nice if you would:
> > - Cc me
> > - send a better explanation than "This is not a missing dependency, feh"
> 
> Looking at the bug log, it seems that you had no business increasing
> the severity in the first place.  You didn't report the bug, you
> aren't the maintainer, and now you are playing BTS wars.  It's up to
> the maintainer and Steve, secondarily it's up to the submitter of the
> bug, and it doesn't seem to concern you at all.

You seem to confuse this with bug closing. It's common practice to 
adjust the severity of a bug to a RC one if a RC issue was mistakenly 
reported as non-RC, and neither your Developers Reference nor your 
release team have ever disagreed with this practice.

The alternative would be to send a second bug for the same issue with 
the correct RC severity. If this makes you happy I can do this in the 
future.

> This bug does not make the package "unusable or mostly so" because it
> has a trivial workaround available.  So it was wrong of you to mark it

Once upon a time, Debian was famous for it's working upgrades.
You can workaround many bugs - but why do you emphasize on the fact that 
there was "a trivial workaround available" if the fix for the bug is 
trivial?

> grave, unless you are just seeking attention.  It might be "serious",
> but the submitter himself thought it was "important".  You didn't give
> any reasons for busting in and changing it.  That's wrong.  

grave <-> serious isn't worth a discussion since there's not a big 
difference between them (both are RC)

Even Steve had always agreed that missing dependencies that break 
partial upgrades from woody were RC bugs And even in the email were he 
downgraded this bug he only wrongly stated "This is not a missing 
dependency" - not that missing dependencies weren't RC.

> Thomas

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: A way _not_ to handle bugs

[Richard Atterer]

On Tue, May 03, 2005 at 08:30:22AM -0700, Thomas Bushnell BSG wrote:
> Looking at the bug log, it seems that you had no business increasing
> the severity in the first place.  You didn't report the bug, you
[...]

So now just people who are affected by bugs are allowed to report them? 
And it's also forbidden to go through the list of open bugs and attempt to
alert developers of important issues by raising the severity (if
necessary)?

While I have no opinion regarding the bug being discussed here, I believe
that those few people who take the time to go through open bugs often do
very valuable work, e.g. by identifying "upgrade bugs" which are waiting to
happen the moment we release.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: A way _not_ to handle bugs

[Thomas Bushnell BSG]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> You seem to confuse this with bug closing. It's common practice to 
> adjust the severity of a bug to a RC one if a RC issue was mistakenly 
> reported as non-RC, and neither your Developers Reference nor your 
> release team have ever disagreed with this practice.

If you are also encountering the bug, then this is true, but I would
expect you, being as knowledgeable as you are, to indicate that in the
bug report and add yourself as a submitter.

>> This bug does not make the package "unusable or mostly so" because it
>> has a trivial workaround available.  So it was wrong of you to mark it
>
> Once upon a time, Debian was famous for it's working upgrades.
> You can workaround many bugs - but why do you emphasize on the fact that 
> there was "a trivial workaround available" if the fix for the bug is 
> trivial?

I agree that it's a bug.  You seem to be saying that if it isn't an RC
bug, then it's no bug at all.  I think it is a bug--for exactly the
reasons you state--but that doesn't make it grave.

>> grave, unless you are just seeking attention.  It might be "serious",
>> but the submitter himself thought it was "important".  You didn't give
>> any reasons for busting in and changing it.  That's wrong.  
>
> grave <-> serious isn't worth a discussion since there's not a big 
> difference between them (both are RC)

Oh, I see, in your world there is "RC" and then "nothing".  The point
you are missing is that it is the maintainer and the release manager
who get to decide, not you.

> Even Steve had always agreed that missing dependencies that break 
> partial upgrades from woody were RC bugs And even in the email were he 
> downgraded this bug he only wrongly stated "This is not a missing 
> dependency" - not that missing dependencies weren't RC.

This seems to indicate that he thinks there is a different explanation
for the bug, and that while adding the package in question as a
dependency makes it go away, this is not the correct fix.  But I can
only guess, as can you, which means it would be good to hold off
until he can say rather than play BTS tag.

Thomas


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

Re: A way _not_ to handle bugs

[Thomas Bushnell BSG]

Richard Atterer <[EMAIL PROTECTED]> writes:

> On Tue, May 03, 2005 at 08:30:22AM -0700, Thomas Bushnell BSG wrote:
>> Looking at the bug log, it seems that you had no business increasing
>> the severity in the first place.  You didn't report the bug, you
> [...]
>
> So now just people who are affected by bugs are allowed to report them? 
> And it's also forbidden to go through the list of open bugs and attempt to
> alert developers of important issues by raising the severity (if
> necessary)?

"It seems".  He didn't give any explanation for the increase in
severity, which is why one can only guess at the motives.  That's what
was missing.  The explanation has now been given, though the severity
was incorrectly increased (it should only be "serious" according to
the description).

> While I have no opinion regarding the bug being discussed here, I believe
> that those few people who take the time to go through open bugs often do
> very valuable work, e.g. by identifying "upgrade bugs" which are waiting to
> happen the moment we release.

Oh, I agree completely!  My point is that, having checked the bug and
improved its severity does not entitle one to start playing BTS-tag.

Thomas


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

Bug#307515: ITP: libchart-strip-perl -- Draw strip chart type graphs.

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves <[EMAIL PROTECTED]>

* Package name: libchart-strip-perl
  Version : 1.01
  Upstream Author : Jeff Weisberg <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Chart-Strip/
* License : Artistic
  Description : Draw strip chart type graphs.

The Chart::Strip package plots data values versus time graphs, such as
used for seismographs, EKGs, or network usage reports. It can plot
multiple data sets on one graph. It offers several styles of plots. It
automatically determines the proper ranges and labels for both axes.


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

Re: A way _not_ to handle bugs

[Adam M.]

Adrian Bunk wrote:

>grave <-> serious isn't worth a discussion since there's not a big 
>difference between them (both are RC)
>  
>

You are 100% wrong here. Why do we have bug severities then? Severities
are there to inform the developer and the rest of the Debian world about
the seriousness of the bug. I tend to stay away from packages that have
grave or critical bugs against them before I read the bug report. So,
let me refresh your mind about bug severities,

|critical - |makes unrelated software on the system (or the whole
system) break, or causes serious data loss, or introduces a security
hole on systems where you install the package.

|grave - |makes the package in question unusable or mostly so, or causes
data loss, or introduces a security hole allowing access to the accounts
of users who use the package.

|serious - |is a severe violation of Debian policy
 (roughly, it violates a
"must" or "required" directive), or, in the package maintainer's
opinion, makes the package unsuitable for release.

|important - |a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone.

|normal - |the default value, applicable to most bugs.

|minor - |a problem which doesn't affect the package's usefulness, and
is presumably trivial to fix.

|wishlist - |for any feature request, and also for any bugs that are
very difficult to fix due to major design considerations.

source: http://www.debian.org/Bugs/Developer#severities


Thus, a bug that makes the package break like this falls under the
important category (since an easy work around is available). *But*, the
bug is also a violation of the Debian policy (ie. depends), so it
becomes serious.

Grave bugs are only there if the package doesn't work at all when you
upgraded ALL depends to latest versions.

- Adam



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

Bug#241287: ITP: xmms-musepack -- Musepack plugin for XMMS

[Patryk Cisek]

Package: wnpp
Followup-For: Bug #241287
Owner: Patryk Cisek <[EMAIL PROTECTED]>

I'll make this package.
Currently the newest version of this plugin is 1.1.2 (look at
www.musepack.net).

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-grsec-high-5-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)


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

Re: A way _not_ to handle bugs

[Steve Langasek]

severity 306015 important
quit

On Tue, May 03, 2005 at 12:27:32PM +0200, Adrian Bunk wrote:

> first of all, if you downgrade a bug only a good hour after I upgraded 
> it, it would be nice if you would:
> - Cc me
> - send a better explanation than "This is not a missing dependency, feh"

If you are going to upgrade bugs to RC severity without talking to the
maintainers first, it would be nice if you would be right.

> In my testing, e.g. php4 from woody together with php4-mysql from sid is 
> _not_ a working combination.

$ apt-cache show php4-mysql
Package: php4-mysql
Version: 4:4.3.10-12
Depends: Depends: libc6 (>= 2.3.2.ds1-4), libmysqlclient12, debconf (>= 0.5) | 
debconf-2.0, phpapi-20020918, php4-common (= 4:4.3.10-12)

^^^

php4-mysql does not depend on php4 because the php4 package is *not*
required to be installed in order for php4-mysql to be usable: installing
any of the packages that provide phpapi-20020918 is sufficient to give you
a php4 engine that can be used with php4-mysql.  php4-mysql does not depend
on any particular package providing the interface, because it has no way of
knowing which one the user wants.

The actual bug you're describing, therefore, is that the package
relationships do not prevent you from having multiple PHP engines
co-installed on your system that each provide different extension ABIs.
This is a well-known bug that's irritating but not release-critical, and
fixing it in sarge would not be at all straightforward.

But that isn't even the problem the original submitter was reporting!  The
original submitter reported a problem with "undefined symbol: php_sprintf",
which has *nothing* to do with the php4 package!  IIRC, the last time this
error was reported it was a problem with bad caching from third-party
accelerators, not a PHP bug at all; in *no* event could it be caused by a
partial upgrade from woody.

I knew this as a co-maintainer, and you didn't, and I shouldn't have to
explain all this to you just to avoid having bug severities inflated when I
could be doing something more productive with my time (and you with yours),
like fixing real RC bugs.

> Please either explain why "this is not a missing dependency" or promise 
> to be a little more careful in the future instead of blindly downgrading 
> bugs.

Please be a little more careful in the future instead of blindly upgrading
bugs.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Adobe Software from 70USD(Mac&PC).Microsoft Software from 80USD(PC).

[Alka]

Hi Debian-devel
it's here
www.;6va2rdquaho5pro;.;lackcidfh.com

Just text
Simple End
Me.


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

Adobe Software from 70USD(Mac&PC).Microsoft Software from 80USD(PC).

[Ben_walker]

Hi Debian-devel-announce
it's here
www.;2r6gnr486v213nk;.;ambushlmdbd.com

Just text
Simple End
Me.


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

Re: Should Debian use lsb init-functions?

[Thomas Hood]

I have been looking at the lsb init functions and am beginning to feel
that they are a bad idea.

* Converting to lsb init function requires modifying every initscript in
Debian.

* Every initscript has to read in a file containing a set of function
definitions, some/most of which the initscript does not use.

* The lsb functions don't handle all the kinds of output currently
produced by initscripts.

* Success/failure status has to be signalled using a special function,
whereas this information is (or should be) already available as the exit
status of the initscript.

I think it would be better if we simply made rc capture initscripts'
standard output (and exit status) and formatted it in such a way that
bootup messages were prettier.
-- 
Thomas Hood <[EMAIL PROTECTED]>


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

Urgently need GPL compatible libsnmp5-dev replacement :-(

[Christian Hammers]

Hello

[regarding #306840 and with more info in #243870]

One of my packages, Quagga, is licenced under the GPL but is supposed to
get linked against NetSNMP. That now is problematic, as NetSNMP depends
on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible.

Does anybody know a good and easy to replace GPL-compatible SNMP library
that provides SNMP MUX capatiblities for C applications?

Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package?

bye,

-christian-


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

Bug#305753: general: 38 packages still use 'Origin: debian'

[Dan Jacobson]

S> What information do you have that tells you that the Origin field
S> is obsolete?

No. I'm saying I feel/guess/believe "Origin: debian" is obsolete, not
that "Origin:" is obsolete.  I'm sure "Origin:" still has good uses.


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

Re: Should Debian use lsb init-functions?

[Henrique de Moraes Holschuh]

On Wed, 04 May 2005, Thomas Hood wrote:
> I have been looking at the lsb init functions and am beginning to feel
> that they are a bad idea.

Here's how I thought about doing it when I was mucking around with
invoke-rc.d and the initscripts paper:

1. No shell functions at all.  Trap stdout and stderr, and parse that.
2. Group all output from a single initscript if possible
3. Get a proper standard for the stdout/stderr usage and enforce it.

That is very Debian-centric, but we could actually make it work with LSB
quite easily, since any LSB script will already run those functions anyway,
and we can have them do whatever is needed.

> * Converting to lsb init function requires modifying every initscript in
> Debian.

We will have to do this sooner or later, but lets make damn sure we know how
we want to do it first...

> * Every initscript has to read in a file containing a set of function
> definitions, some/most of which the initscript does not use.

The stdout/stderr parsing method kills this problem.

> * The lsb functions don't handle all the kinds of output currently
> produced by initscripts.

And this one :)

> * Success/failure status has to be signalled using a special function,
> whereas this information is (or should be) already available as the exit
> status of the initscript.

And this one :)

> I think it would be better if we simply made rc capture initscripts'
> standard output (and exit status) and formatted it in such a way that
> bootup messages were prettier.

Exactly!  Anyone up for a lets-design-the-next-debian-initscript BOF on
debconf5?

Here's how I envision it might be done:

[init] - [demultiplexer/parellism control] (pipe A) (pipe B)
   |---­ [rc] (connects to pipe A) -- (initscript 1)
   |   -- (initscript n)
   - [logging/GUI] (connects to pipe B)

A quick read on the (now somewhat outdated) initscript paper at
http://people.debian.org/~hmh/, sections 5.3 and 5.4 will explain what I
would use the demultiplexer/parallelism control daemon for.

All output from the initscripts get to the demultiplexer, tagged as
stdout/stderr and the initscript instace responsible for it.

*AND* this does not change init, at all.

-- 
  "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

Re: Urgently need GPL compatible libsnmp5-dev replacement :-(

[Henrique de Moraes Holschuh]

On Wed, 04 May 2005, Christian Hammers wrote:
> One of my packages, Quagga, is licenced under the GPL but is supposed to
> get linked against NetSNMP. That now is problematic, as NetSNMP depends
> on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible.

A simple extension to Quagga's (*and* NetSNMP if it is GPLed) license
allowing for linking to OpenSSL is probably the easiest way to fix this (and
since that is a documentation change, it would get into sarge).

> Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package?

That would be etch-land.  The most sane way to fix this would be to get
NetSNMP to be able to link to the GNU version of OpenSSL (I don't recall how
it is called).

-- 
  "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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Urgently need GPL compatible libsnmp5-dev replacement :-(

[Christian Hammers]

Hello

On 2005-05-03 Henrique de Moraes Holschuh wrote:
> On Wed, 04 May 2005, Christian Hammers wrote:
> > One of my packages, Quagga, is licenced under the GPL but is supposed to
> > get linked against NetSNMP. That now is problematic, as NetSNMP depends
> > on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible.
> 
> A simple extension to Quagga's (*and* NetSNMP if it is GPLed) license
> allowing for linking to OpenSSL is probably the easiest way to fix this (and
> since that is a documentation change, it would get into sarge).

The extension itself would be easy, more problematic is that it would have
to be signed by all significant contributers to the Quagga source
code and those are many. Not to mention that Quagga was a "frustrated"
fork from Zebra which is no longer part of Debian so there may be problems
when begging for a licence change...

> > Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package?
> 
> That would be etch-land.  The most sane way to fix this would be to get
> NetSNMP to be able to link to the GNU version of OpenSSL (I don't recall how
> it is called).

I could package the whole libsnmp source code into the Quagga file, and
simply compile it with --without-openssl and then link it statically 
or something similar brute force and ugly.

Replacing OpenSSL by GnuTLS is indeed something for etch if the upstream
maintainer from NetSNMP does have ambitions doing this at all as NetSNMP
is BSD licenced and has no need to do so. 

bye,

-christian-
 


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

Orphaning recover and makeztxt

[Gunnar Wolf]

Hi,

I have just orphaned two of my packages, I hope somebody among you
wants to pick them up. They are recover (#307558) and makeztxt
(#307557). 

Recover lets you recover (duh) deleted files in ext2 filesystems. Note
that it is in ext2 and _not_ in ext3 - I once talked with some people
about removing it, but I was persuaded to keep it, as there are many
ext2 users still in some platforms that don't run kernel 2.4/2.6 - I
don't know if now that we are moving to Sarge they will still be
counted in... Possibly it'd be time to remove recover. 

About makeztxt, it is a nice program to convert text files into ztxt
files, apt for reading in a Palm with the (GPLed) Weasel reader. It
has a simple regex engine used to create the TOCs, and works just
fine. The problem is, I no longer own a Palm, so I cannot do much with
it.

Both packages move very slowly (IIRC, two years since their last
release). 

The bugs against WNPP have been filed. Do you want to pick them up? Do
you want recover out of Sarge? Speak up!

Greetings!

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)

[Holger Levsen]

Package: www.debian.org

Hi,

On Tuesday 03 May 2005 21:46, Steve Langasek posted a fine mail about a fine 
change (thanks for both to whom it may apply).

Whohoo! :-)

Regarding testing upgrades from woody, I would like to propose mentioning 
more visible that the suggested upgrade tool is aptitude, not apt-get - fewer 
people than you might think read the fine releasenotes :-) 

This might be related to the fact the they're somewhat hidden, at least 
to ./google "sarge releasenotes" - 
http://www.debian.org/releases/testing/releasenotes isn't helpful atm either.

regards & keep on rockin' ;-)
Holger

> As before, being able to hold to this schedule depends heavily on a
> steadily dropping RC bug count, so if that isn't happening, the timeline
> will have to be tweaked accordingly.

> Note once again that you can stage NEW uploads in experimental to avoid
> disruption in unstable.


pgpxHDe4eT5I4.pgp
Description: PGP signature

Re: transcode

[Jeff Carr]

Marco d'Itri wrote:
On May 01, John Hasler <[EMAIL PROTECTED]> wrote:

Transcode is not in Debian because the codecs are not DFSG-compliant.
Do you mind explaining how you came to this conclusion?
I hope this gets straighted out & resolved. Transcode is excellent 
software and is licensed under the GPL and should be included in Debian. 
No codecs are packaged inside of transcode & it is completely usable 
with OGG/OGM.

Jeff
PS: of interest to the mplayer thread: motion.c allows mpeg-1 & mpeg-2 
support for non-commercial software. AKA: GPL/LGPL'd implementations are 
allowed.

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

Re: [Comandob] Fwd: Release update: editorial changes to the testing propagation scripts

[Kopernix (Joan Puiggali)]

> Hagan sus apuestas: Sarge saldrá en...
Puf, yo no apuesto, que trae mala suerte (es algo infundado socialmente, es 
una autosupersticion, fruto de mis delirios, pero siempre que apuesto algo, 
me pasa algo malo en pocos dias)

eso si, me permito un:
WWWHHAAA


-- 
Joan Puiggali Abanades (a.k.a Kopernix) GPG id B20FB54B
http://www.kopernix.com

Re: Should Debian use lsb init-functions?

[Wouter Verhelst]

On Wed, May 04, 2005 at 12:05:19AM +0200, Thomas Hood wrote:
> I have been looking at the lsb init functions and am beginning to feel
> that they are a bad idea.
> 
> * Converting to lsb init function requires modifying every initscript in
> Debian.

Well, d'oh.

> * Every initscript has to read in a file containing a set of function
> definitions, some/most of which the initscript does not use.

Well, d'oh.

> * The lsb functions don't handle all the kinds of output currently
> produced by initscripts.

That would be a problem, indeed; but I'm sure this isn't an impossible
one to solve.

> * Success/failure status has to be signalled using a special function,
> whereas this information is (or should be) already available as the exit
> status of the initscript.

... and?

> I think it would be better if we simply made rc capture initscripts'
> standard output (and exit status) and formatted it in such a way that
> bootup messages were prettier.

That sounds like an ugly and error-prone hack to me. Not something we
want one of our most important systems to be working with.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Urgently need GPL compatible libsnmp5-dev replacement :-(

[Marco d'Itri]

On May 04, Christian Hammers <[EMAIL PROTECTED]> wrote:

> I could package the whole libsnmp source code into the Quagga file, and
> simply compile it with --without-openssl and then link it statically 
> or something similar brute force and ugly.
Or even better just disable SNMP support, which is not terribly useful
anyway.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Should Debian use lsb init-functions?

[Marco d'Itri]

On May 04, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> > standard output (and exit status) and formatted it in such a way that
> > bootup messages were prettier.
> That sounds like an ugly and error-prone hack to me. Not something we
> want one of our most important systems to be working with.
Agreed. I do not think that enforcing correct formatting for *all*
messages is feasible.
The other issues do not look relevant to me.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Should Debian use lsb init-functions?

[Russ Allbery]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> Here's how I thought about doing it when I was mucking around with
> invoke-rc.d and the initscripts paper:

> 1. No shell functions at all.  Trap stdout and stderr, and parse that.
> 2. Group all output from a single initscript if possible
> 3. Get a proper standard for the stdout/stderr usage and enforce it.

One concern I'd have is that using the LSB functions is (at least
somewhat) lintian-testable, whereas the standard for stdout/stderr usage
would be much more difficult to test in a lintian/linda sort of way.

Making widespread changes happen that are lintian-verifiable seems a lot
easier to do than making changes that aren't.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re:

[adriana price]

New models of phones,
come and look that will be in sales in 2-3 months http://best-pedo.com/a/



Tue, 03 May 2005 23:47:08



agway. adolph   almighty

Orphaning Crossfire

[Jaakko Niemi]

 Hello,

 crossfire-* is available for grabs. Upstream is active and helpful.
 No big issues, just needs some basic work. Any takers?

--j


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

Re: Urgently need GPL compatible libsnmp5-dev replacement :-(

[David Mandelberg]

On Tue, 2005-05-03 at 19:40 -0300, Henrique de Moraes Holschuh wrote:
> GNU version of OpenSSL (I don't recall how
> it is called).

GnuTLS I think.

-- 
The attachment "signature.asc" (if it exists) is a digital signature.
Unless you know what that is, you can completely ignore it. It is mostly
harmless and very small.

Tempt not a desperate man.
-- William Shakespeare, "Romeo and Juliet"



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

Re: transcode

[Matthew Palmer]

On Tue, May 03, 2005 at 04:36:30PM -0700, Jeff Carr wrote:
> PS: of interest to the mplayer thread: motion.c allows mpeg-1 & mpeg-2 
> support for non-commercial software. AKA: GPL/LGPL'd implementations are 
> allowed.

No, GPL/LGPL is not non-commercial.

- Matt


signature.asc
Description: Digital signature

Vancouver, BC: Key signing tomorrow (Wednesday) at lunch

[Shaun Jackman]

There will be a key signing at 12:30 on Wednesday, May 4th at Kirin
Sushi - across the street from the New Westminster SkyTrain station -
31 8th St - (604) 521-1833

See you all there!
Shaun

Re: Urgently need GPL compatible libsnmp5-dev replacement :-(

[Steve Langasek]

On Tue, May 03, 2005 at 07:40:24PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 04 May 2005, Christian Hammers wrote:
> > One of my packages, Quagga, is licenced under the GPL but is supposed to
> > get linked against NetSNMP. That now is problematic, as NetSNMP depends
> > on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible.

> A simple extension to Quagga's (*and* NetSNMP if it is GPLed) license
> allowing for linking to OpenSSL is probably the easiest way to fix this (and
> since that is a documentation change, it would get into sarge).

The license of the GNUTLS OpenSSL shim is GPL, causing possible license
problems in the other direction with GPL-incompatible apps.  It's also not a
very complete compatibility layer.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Upcoming removals

[François-Denis Gonthier]

On May 3, 2005 09:54 am, Martin Michlmayr wrote:

> #297426: O: langband -- The langband Common lisp game
> Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.
>
> #297427: O: langband-data -- The Langband sound/image/etc files for
> langband engine Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days
> old.

Can a non-DD (like me) take over those packages?


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

Re: Upcoming removals

[Adam M.]

François-Denis Gonthier wrote:

>On May 3, 2005 09:54 am, Martin Michlmayr wrote:
>  
>
>>#297426: O: langband -- The langband Common lisp game
>>Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days old.
>>
>>#297427: O: langband-data -- The Langband sound/image/etc files for
>>langband engine Reported by: "Kevin M. Rosenberg" <[EMAIL PROTECTED]>; 63 days
>>old.
>>
>>
>
>Can a non-DD (like me) take over those packages?
>  
>

Yes. You just need a sponsor to upload.

- Adam



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

Re: Should Debian use lsb init-functions?

[Marc Haber]

On Wed, 4 May 2005 01:34:17 +0200, Wouter Verhelst <[EMAIL PROTECTED]>
wrote:
>On Wed, May 04, 2005 at 12:05:19AM +0200, Thomas Hood wrote:
>> I think it would be better if we simply made rc capture initscripts'
>> standard output (and exit status) and formatted it in such a way that
>> bootup messages were prettier.
>
>That sounds like an ugly and error-prone hack to me. Not something we
>want one of our most important systems to be working with.

The fact that there is much more than one init script which writes
additional output in between the policy conformant "Starting foo...
Done.", giving "Starting foo... blurb
blurb
Done." is one of the most annoying facts in Debian, IMO.

Additionally, it is bad that on systems which neither have a serial
console nor a monitor attached init script output is inaccessible.

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

Re: Urgently need GPL compatible libsnmp5-dev replacement :-(

[Theodore Ts'o]

On Tue, May 03, 2005 at 07:06:36PM -0700, Steve Langasek wrote:
> 
> The license of the GNUTLS OpenSSL shim is GPL, causing possible license
> problems in the other direction with GPL-incompatible apps.  It's also not a
> very complete compatibility layer.
> 

So dynamically link against _an_ SSL library, using dlopen(), and this
completely trumps the issue.  The fact that there are multiple
libraries, implementing the OpenSSL interface, means that as long as
the application calls the *interface* it can't be derived from
*either* library, and it escapes the license incompatibility issues.
(Remember, license compatibility can only be an issue if the program
can be shown to be a derived work of a particular library.  If it is
calling an interface which is implemented by more than one library,
then clearly it can't be a derived work, and once it is not a derived
work, copyright law by definition can't apply.)

Example: The libss library searches for the readline, editline, and
libedit libraries via a search path, and dlopen()'s the first one it
can find.  It the calls those interfaces to get readline
functionality.  The Solaris SEAM (Solaris Enterprise Authentication
Mechanism), which is a propietary program which is derived from the
MIT Kerberos V5 sources, also happens to call the libss library, with
which it is dynamically linked.  

Yet now when you run the Kerberos administration CLI program from
SEAM, and install the newer version of libss library so that it
dynamically links with it, and then the libss library could possibly
dlopen the GNU readline library  you can a process containing
propietary Solaris code, BSD licensed libss code, and GPL'ed readline
library, all in the same address space.  But has there been a GPL
violation?  No, since, the only time a derivitive work can
conclusively shown to be created is when the user ran the kadmin
program, and the GPL does not restrict use, only distribution.

Could the kadmin program be considered a derived work of the readline
library?  No, because it was written to call libss *years* ago, long
before libss was modified to potentially call the readline library.
The kadmin program called the libss *interface*, and at the time the
author of the kadmin program had no idea that it might subsequently
end up calling a GPL'ed library indirectly via libss.  And
furthermore, the BSD-licensed libss program does not even directly
link against the readline library, but rather uses dlopen() and
dlsym() to call a particular *interface* which could be satisified
either by a GPL or BSD licensed library.  So how can you say that the
libss program is a derivitive work of either library?

I believe you can use a similar solution to solve the openssl library
problem.  If there is a shim layer, and the application uses a search
path to find a library which it then dlopen()'s, this should
completely trump the license compatibility issue, since in this case
it is clear that it is not a derived work of any one particular
library, but rather it is calling an interface which can be satisified
by multiple libraries, and which library will get used can only be
determined at run-time.

- Ted


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