$BL$>5G'9-9p"(?M:`%S%8%M%9$N3+@_(B$B$r$*9M$($G$"$l$P!"(B

[$B@D0f!!9aN$(B]

$BpJs<<[EMAIL PROTECTED](B
$B#T(B/045-474-5237$B!!#F(B/045-475-0764
(B[EMAIL PROTECTED]
(Bhttp://www.yap.co.jp
(B
(B
(B
(B[EMAIL PROTECTED](B
$B2#IM%"%I!&%W%m%b!<%7%g%s6(F1AH9g!J([EMAIL PROTECTED](B
(B
$B?75,;v6H;2F~$r$*9M$($N4k6HMM$X!Z?M:`%S%8%M%9$N5/6H!A1?1D![(B
$B$rA4LLE*$K$*e#1#7#0#0K|1_(B
$B!|;0=E8)#57n#1#7!"#1#8F|(B $B8&=$$K$F5/6H!?Gd>e#3#6#0#0K|1_(B
$B!|@E2,8)#47n#2#6!"#2#7F|(B $B8&=$$K$F5/6H!?Gd>e#1#0#0#0K|1_(B
$B!|[EMAIL 
(BPROTECTED]@n8)!!#2#0#0#1G/#67n!!8&=$$K$F5/6H!?Gd>e#42/#3#0#0#0K|1_(B
$B!|0q>k8)#2#0#0#1G/#27n(B $B!!8&=$$K$F5/6H!?Gd>e#12/#5#0#0#0K|1_(B
$B"(C4Ev$G!"[EMAIL PROTECTED](B
$B"(%<%m$+$i$N5/6H$G$9!#(B
(B
(B[EMAIL PROTECTED]"(B
$B"!(BYAP$B$+$i$N;E;v>R2p@)EY!JA49q(B1000/$B7n!K(B
$B"!K,Ld$J$-%m%C%/%$%s1D6H(B
$B"!6%9g$7$J$$?M:`%S%8%M%9Z:[EMAIL PROTECTED]\:Y;qNA$rL5NA$G$*Aw$j?=$7>e$2$^$9!#(B
$B0J2e!"K\%a!<%k$r$4JV?.2<$5$$!#!J$*EEOC$G$b7k9=$G$9!K(B
(B
$B-!2q(B
$B-"$4C4EvpJs<<[EMAIL PROTECTED](B
$B#T(B/045-474-5237$B!!#F(B/045-475-0764
(B[EMAIL PROTECTED]
(Bhttp://www.yap.co.jp
(B--
$B2w?J7b%+%s%Q%K!<$r:n$k%3%s%5%k%F%#%s%0%U%!!<%`(B  $B#Y(B $B#A(B $B#P(B
$B!V%m%C%/[EMAIL PROTECTED],!JK,Ld$r$7$J$$1D6H!&AH?%%N%&%O%&!K!W8x3+Cf!*!*(B
(B--

Re: task-spanish exists: expansion proposal (was Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish))

[Manoj Srivastava]

>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
 >> 
 >> From the changelog of Debian policy package:
 >> 
 >> debian-policy (3.5.7.0) unstable; urgency=low
 >> 
 >> [...]
 >> * we no longer have task packages, instead, we define tasks using a
 >> special field in the control file (and these should be added only
 >> after discussion on the mailing lists)closes: Bug#97755 
 >> [...]
 >> 
 >> -- Manoj Srivastava <[EMAIL PROTECTED]>  Sat, 31 Aug 2002 02:18:02 -0500

 Joey> This is a seemingly ill-informed changelog entry, and not Policy, FWIW.
 Joey> See my posting on -policy.


Ill-informed? How about poorly documented task proposals
 which did not reflect reality? the changelog entry was taken straignt
 out of the task porposal as presented to the policy group; and since
 there has been no mention in the last few months in debian-devel, is
 it surprising that I assumed that the proposers of tasksel knew what
 they were talking about the proposal.

manoj
-- 
 A year spent in artificial intelligence is enough to make one believe
 in God.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: RFC: A regression test framework for Debian packages?

[Scott Henson]

On Mon, 2002-09-02 at 06:19, Jamie Wilkinson wrote:
> This one time, at band camp, Jérôme Marant wrote:
> >  In a chrooted environment, we can install deboostrap and
> >  package dependencies through APT.
> 
> About 6 months ago I started writing some code in expect to do just this, to
> test my quake2-data installer package.  I was able to install the package
> into an UML machine, answer the debconf questions, and check the location of
> the installed files (being an installer package, not all files installed by
> the package are in the deb).
> 
> I haven't touched this code for a long time, but I've been meaning to clean
> it up and start doing regression testing on parts of the archive.  I envisage
> being able to run it once a week on the entire archive, testing the
> ability of every pacakge to cleanly upgrade from woody to sarge, and back
> again.

I hate to break in as a normal user, but it seems to me that all these
scripts such as this one, linda and litian are all having to be run over
the entire archive.  Cant these scripts be made to be archive aware so
only updated packages are check and possibly packages that depend on
them.  Wouldn't this save all kinds of CPU time? Just a quick thought.

-- 

Re: Dependencies on -dev packages

[Stephen Zander]

> "Andrew" == Andrew Suffield <[EMAIL PROTECTED]> writes:
Andrew> Recommends and Suggests are not considered when installing
Andrew> build-dependencies.

And packages aren't supposed to be built staticly either.  Packages
that do build staticly could explicitly Build-Depend on whatever they
require.

Regardless, I've had my question (partially) answered; unless Debian
generally moves to versioned symbols, more conversation is moot.

-- 
Stephen

"And what do we burn apart from witches?"... "More witches!"

Re: Dumb little utilities

[Joey Hess]

Clint Adams wrote:
> alias ren='noglob zmv -W'
> ren *.c *.x

Ok, I love zsh and all, but: RUN AWAY!!

> I find the last preferable to the more cumbersome syntaxes of rename and
> mmv.

rename 's/\.c$/.x/' cumbersome?

-- 
see shy jo, suffering 4dos flashbacks (see my .zshrc)


pgpl43ZOy1ZMN.pgp
Description: PGP signature

Re: task-spanish exists: expansion proposal (was Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish))

[Joey Hess]

Rene Engelhard wrote:
> Hmm. According to the latest policy the Task: method should be used
> which I think is not the best thing...
> 
> From the changelog of Debian policy package:
> 
> debian-policy (3.5.7.0) unstable; urgency=low
> 
> [...]
>  * we no longer have task packages, instead, we define tasks using a
> special field in the control file (and these should be added only
> after discussion on the mailing lists)closes: 
> Bug#97755 
> [...]
> 
>  -- Manoj Srivastava <[EMAIL PROTECTED]>  Sat, 31 Aug 2002 02:18:02 -0500

This is a seemingly ill-informed changelog entry, and not Policy, FWIW.
See my posting on -policy.

-- 
see shy jo


pgpOex6CvsvRA.pgp
Description: PGP signature

Re: Dependencies on -dev packages

[Henrique de Moraes Holschuh]

On Tue, 03 Sep 2002, Stephen Zander wrote:
> I wrote a longer response to this but then thought about what you
> wrote a bit more and deleted it.
> 
> > "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> Henrique> The lack of symbol versioning, about 90% of the time.
> 
> Then why not mandate symbol versioning instead; that would be a much
> lighter-weight solution IMHO.

I would *love* to have Debian mandate symbol versioning.  But it is
extremely unforgiving of soname fuckups (one usually uses the soname as the
versioning, unless one knows much better AND one is upstream), so it is not
as easy to get people to adopt it as I'd like.

-- 
  "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: Deleting /var/cache/*

[Martijn van Oosterhout]

On Tue, Sep 03, 2002 at 10:34:23PM -0400, Duncan Findlay wrote:
> I deleted /var/cache/* today to free up some space on my /var
> partition. However, instead of applications re-creating the files as I
> expected, I recieved a bunch of error messages.

> apt/apt-get refused to do anything until I manually created the
> directory /var/cache/apt/archives/partial


[snip]

> Sure, these errors are relatively simple to fix, but I am wondering if
> they are bugs. So before I file them as such, I'd like to know is it a
> requirement of using /var/cache that directories and files be
> automatically re-created?
> 
> According to FHS 5.2:
> 
> Files located under /var/cache may be expired in an application
> specific manner, by the system administrator, or both. The application
> should always be able to recover from manual deletion of these files
> (generally because of a disk space shortage). No other requirements
> are made on the data format of the cache directories.

I think the key word is "files". As you say it doesn't talk about about
directories, for good reason since it's an awful lot of work. you'd have to
replace:

  Look for cache file
  If not, go the long way

with:

  Look for cache file
  If not, check for parent directory
If not there, try to create it
  If fails, check for parent directory
etc...

Ofcourse, it could just do system("mkdir -p /var/cache/whatever/dir/it/is")
everytime it wants to open a file but that would be inefficient.

> True, the FHS does not specifically say that directories have to be
> recreated, but I would consider it a bug if they aren't. Anyone agree?

Maybe in a maintainence script somewhere. IIRC squid needs to create a whole
bunch of directories for it's cache before it will start up. It does this
when you install it.

So no, I don't agree.
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.

Re: Deleting /var/cache/*

[Joey Hess]

Duncan Findlay wrote:
> True, the FHS does not specifically say that directories have to be
> recreated, but I would consider it a bug if they aren't. Anyone agree?

I think it would be at best a feature request, but I would like to see
that feature implemented, nontheless..

-- 
see shy jo


pgpDTD2iTFemQ.pgp
Description: PGP signature

Deleting /var/cache/*

[Duncan Findlay]

I deleted /var/cache/* today to free up some space on my /var
partition. However, instead of applications re-creating the files as I
expected, I recieved a bunch of error messages.

apt/apt-get refused to do anything until I manually created the
directory /var/cache/apt/archives/partial

I also got a few messages from cron.daily:
/etc/cron.daily/dwww:
mkdir: cannot create directory `/var/cache/dwww/dwww-build.1008': No
such file or directory
run-parts: /etc/cron.daily/dwww exited with return code 1
/etc/cron.daily/man-db:
fopen: No such file or directory
mandb: can't create index cache /var/cache/man/1075: No such file or
directory
mandb: can't chmod /var/cache/man/index.bt: No such file or directory
mandb: warning: can't update index cache /var/cache/man/index.bt: No
such file or directory
fopen: No such file or directory
mandb: can't create index cache /var/cache/man/oldlocal/1075: No such
file or directory
mandb: can't chmod /var/cache/man/oldlocal/index.bt: No such file or
directory
mandb: warning: can't update index cache
/var/cache/man/oldlocal/index.bt: No such file or directory
fopen: No such file or directory
mandb: can't create index cache /var/cache/man/X11R6/1075: No such
file or directory
mandb: can't chmod /var/cache/man/X11R6/index.bt: No such file or
directory
mandb: warning: can't update index cache
/var/cache/man/X11R6/index.bt: No such file or directory

Sure, these errors are relatively simple to fix, but I am wondering if
they are bugs. So before I file them as such, I'd like to know is it a
requirement of using /var/cache that directories and files be
automatically re-created?

According to FHS 5.2:

Files located under /var/cache may be expired in an application
specific manner, by the system administrator, or both. The application
should always be able to recover from manual deletion of these files
(generally because of a disk space shortage). No other requirements
are made on the data format of the cache directories.


True, the FHS does not specifically say that directories have to be
recreated, but I would consider it a bug if they aren't. Anyone agree?

-- 
Duncan Findlay

Re: foomatic unmaintained?

[Chris Lawrence]

On Sep 03, Rainer Dorsch wrote:
> some weeks ago I was installing an HP OfficeJet and on the hpoj mailing list 
> somebody was pointing out that I need the latest version of foomatic to get 
> good results.but it seems that the Debian foomatic-{bin,db} packages in 
> sid are outdated. I contacted the maintainer,  Manfred Wassmann, but so far 
> no response.
> 
> This could mean that the maintainer is simply to busy to respond and invests 
> his time better in maintaining the package than answering stupid email or 
> more likely that the package is unmaintained
> 
> In this case, maybe somebody familar with foomatic may want to take it...to 
> help to prepare Debian for the desktop for the masses.

I contacted the maintainer a few days ago about the package, and have
not received any response either.  I have prepared an NMU of the
current foomatic release; it's currently in DELAYED/?-days (I think ?
is 4 at the moment).


Chris
-- 
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/

Re: Dependencies on -dev packages

[Stephen Zander]

I wrote a longer response to this but then thought about what you
wrote a bit more and deleted it.

> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
Henrique> The lack of symbol versioning, about 90% of the time.

Then why not mandate symbol versioning instead; that would be a much
lighter-weight solution IMHO.

-- 
Stephen

You will be a large breasted porno star in your next life
- Chinese Fortune Cookie

Re: Dependencies on -dev packages

[Henrique de Moraes Holschuh]

On Tue, 03 Sep 2002, Goswin Brederlow wrote:
> Stephen Zander <[EMAIL PROTECTED]> writes:
> > What is the thinking behind always requiring libfoo-dev to depend on
> > libbar-dev when libfoo depends on libbar?  I understand the need when

The lack of symbol versioning, about 90% of the time.

> > but if libfoo opaquely wraps libbar, why have libfoo-dev depend on
> > libbar-dev?

It only opaquely wraps libbar if it is compiled statically.

-- 
  "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: bugs.debian.org: ChangeLog closes handling should be changed

[Goswin Brederlow]

Gerfried Fuchs <[EMAIL PROTECTED]> writes:

> * Brian May <[EMAIL PROTECTED]> [2002-08-29 09:50]:
> > On Tue, Aug 27, 2002 at 08:48:31AM +0200, Gerfried Fuchs wrote:
> >>  What we need is a change here: Bugs should just be closed in unstable.
> >> How to do this?  They should be rather be tagged  than be closed
> >> by an upload to unstable.  Not unconditionally, of course.  The version
>^^^
> >> of the bugreport should be compared with the version currently in
>   ^^
> >> testing.  Some sort of algorithm not too complex but able to handle most
>
> >> of the cases shouldn't be too hard to do (yes, I volunteer to help
> >> there).
> > 
> > Then bugs will me marked as sarge, even though they might be bugs
> > specific to unstable.
> 
>  Just to make sure you didn't miss that I thought of that problem
> already, thanks.  Or do you think of that the bugs are there because of
> other packages in unstable?  Well, then the bug might be filed against
> the wrong package.  Which would leave us with a problem -- the version
> is rather meta information in the bugreport and not real useful data, is
> it?  So currently there is no need to change the version field if a bug
> gets reassigned to a different package... *hmmm*  Difficult issue, but
> still no issue that shouldn't be raised/thought about.

What about the folowing mechanism:

- The dist of the reportie(s) is checked. If its not in the bugreport
  guess stable.

- When a "closes" is seen in the changelog the version of the
  uploaded package is noted.

- Reporties using unstable get the normal mail as it is now.

- Reporties with testing get a mail that a bugfix is uploaded to
  unstable and they might want to try that out. Once the package closing
  the bug (or any later version) moves to testing they get a mail
  seaying that the bug is fixed in testing.

- same for stable but 3 mails. A "is in unstable", a "is in testing"
  and a "is closed" mail.

- The BTS tags bugs as [closed unstable], [closed testing] or
  [closed] respectivly. The script moving things to testing and stable
  tells the BTS about the version it moves and the BTS changes the tags
  according to a version compare.

- Bugs with tag [sid] could get closed immediatly with a upload to
  sid. The [sid] or [sarge] tags could be adjusted by the BTS when a
  new version is moved. If bar is moved from sid to sarge all [sid]
  tags become [sid][sarge]. A [closed unstable] would replace the
  [sid] tag but leave the [sarge] tag.


MfG
Goswin

Re: Improper NMU (Re: NMU for libquota-perl)

[Josip Rodin]

On Tue, Sep 03, 2002 at 11:13:07PM +0100, Andrew Suffield wrote:
> On Tue, Sep 03, 2002 at 02:19:03PM +0200, Josip Rodin wrote:
> > A NMU is a waste of effort if the same thing can be done by the maintainer
> > after just one quick email message -- primarily a waste of effort for the
> > NMUer who has to go in and figure out how to fix the package, not the
> > maintainer. If we can save others that time by doing what we're simply
> > supposed to do, well, I see no reason not to do that.
> 
> This argument is bogus. Updating a Build-Depends and rebuilding the
> package is trivial (not least because the system is designed to make
> it trivial).

It still requires effort by the non-maintainer to get the sources, fiddle
with it a little bit, recompile, and upload. Two minutes, sure, but two
minutes that could have been spent fixing #155939. ;)

> Also, in general, it's hard to create a suitable patch and send it to
> the BTS, and trivial to apply the patch and build the package.

Just letting the maintainer know about the problem is enough, at least in
some cases, no need to go out of your way and prepare a ready-made fix.

> And lastly, am I the only one who finds complaining about *other
> people* wasting effort to be insane in a volunteer-based organisation?
> There's a difference between advice, and telling people what to spend
> their time on.

Every time someone NMUs someone else's package just like that, the
(supposed-to-be) maintainer's desire to maintain the package drops by a
little bit. They get discouraged by the fact nobody's asking them anything
about stuff that supposed to be theirs, so they get a feeling nobody needs
them. Joey has ranted about this before :) and I must say I can see why
someone could feel this way.

Perhaps in the case of a simple recompile, there's no reason to worry about.
But if we use this to start not requiring any communication with a
maintainer prior to NMUs, the situation might evolve into a state where it
really is a problem.

I think that recompile-NMUs should be done like the xmms 1.2.7-1.1 one was
done. That one had a decent amount of advance notice to the maintainer, and
was still done fast enough to prevent more than five or six duplicate bugs
from being filed.

I'm willing to bet that the NMUer wasn't unhappy with how things turned out
in that case. I can vouch that the maintainer was happy, too. ;)

IMHO, YMMV.

-- 
 2. That which causes joy or happiness.

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Craig Sanders]

i'm not 100% certain that it's related but for the last week or so, i've
been unable to run apt-get update on any of my home machines.  what i
get is:

[EMAIL PROTECTED] [09:01:52] ~# apt-get update
Get:1 http://siva.taz.net.au unstable/main Packages [2097kB]
Get:2 http://siva.taz.net.au unstable/main Release [34.1kB]
Get:3 http://siva.taz.net.au unstable/contrib Packages [63.7kB]
Get:4 http://siva.taz.net.au unstable/contrib Release [85B]
Get:5 http://siva.taz.net.au unstable/non-free Packages [73.4kB]
Get:6 http://siva.taz.net.au unstable/non-free Release [86B]
Get:7 http://siva.taz.net.au unstable/non-US/main Packages [35.5kB]
Get:8 http://siva.taz.net.au unstable/non-US/main Release [89B]
Get:9 http://siva.taz.net.au unstable/non-US/contrib Packages [926B]
Get:10 http://siva.taz.net.au unstable/non-US/contrib Release [92B]
Get:11 http://siva.taz.net.au unstable/non-US/non-free Packages [3042B]
Get:12 http://siva.taz.net.au unstable/non-US/non-free Release [93B]
Get:13 http://siva.taz.net.au unstable/main Packages [2063B]
Ign http://siva.taz.net.au unstable/main Release
Get:14 http://siva.taz.net.au unstable/contrib Packages [3488B]
Ign http://siva.taz.net.au unstable/contrib Release
Get:15 http://marillat.free.fr unstable/main Packages [8464B]
Get:16 http://marillat.free.fr unstable/main Release [112B]
Fetched 2322kB in 5s (437kB/s)
Reading Package Lists... Error!
E: Unable to parse package file 
/var/lib/apt/lists/siva.taz.net.au_debian_dists_unstable_main_binary-i386_Release
 (1)
E: Problem opening 
/var/lib/apt/lists/siva.taz.net.au_debian_dists_unstable_contrib_binary-i386_Packages
E: The package lists or status file could not be parsed or opened.


siva.taz.net.au contains a mirror of unstable binary-i386 only.  it is
updated nightly using the debmirror script from another mirror
falls.vicnet.net.au which contains stable & unstable binary-i386.  the
falls mirror is updated nightly using debmirror from ftp.au.debian.org

siva is my home mirror, and falls is my mirror at work.

interestingly, my machines at work (which have lines referring to falls in
their sources.list) have no problem.  similarly, when i point my home machines
at falls, apt-get update works OK. which makes me suspect that there's
something weird about unstable which debmirror or apt can't cope with.

so, is this a bug with apt-get, debmirror, or the archive?  or with the
command-line options i use to run debmirror.

i call debmirror like so:

HOST="falls.vicnet.net.au"
ARGS="--debug --progress --nosource --dist=unstable --arch=i386 --getcontents"

savelog /var/log/debmirror.log

debmirror /home/ftp/debian $ARGS --host $HOST >/var/log/debmirror.log 2>&1

debmirror /home/ftp/debian-non-US $ARGS --host $HOST -r /debian-non-US -s 
non-US/main,non-US/contrib,non-US/non-free >>/var/log/debmirror.log 2>&1



software versions installed are:

ii  apt0.5.4  Advanced front-end for dpkg
ii  debmirror  20020427-1 Debian partial mirror script, with ftp and p
ii  dpkg   1.10.5 Package maintenance system for Debian
ii  dselect1.10.5 a user tool to manage Debian packages


btw, both the files that apt-get complains about exist and contain what
looks like valid data.


On Tue, Sep 03, 2002 at 01:03:00PM +1000, Anthony Towns wrote:
> On Tue, Sep 03, 2002 at 11:47:26AM +1000, Brian May wrote:
> > The release file at:
> > http://snoopy.apana.org.au:8081/debian/dists/unstable/main/binary-i386/Release
> 
> Wrong Release file. You want debian/dists/unstable/Release.
> 
> > contains:
> 
> 5fae015d924f72c2568bbc55cd1ee8877822376 main/binary-i386/Packages
> 43d6da7b3da37f40c6861dcef2949d3d2096801 main/binary-i386/Packages.gz
> 3816502b7b94745a0fdf6b8fc252caa61611051 main/binary-i386/Packages.bz2

my debian/dists/unstable/Release file contains 

Origin: Debian
Label: Debian
Suite: unstable
Codename: sid
Date: Mon, 02 Sep 2002 19:41:31 UTC
Architectures: alpha arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 
sh sparc
Components: main contrib non-free
Description: Debian Unstable - Not Released
MD5Sum:
 cd0d4040bad58f81bdc86cff13f39fe7  7387581 main/binary-alpha/Packages
 4a97463402fd3a88b1cd41fd01ba23d2  1989746 main/binary-alpha/Packages.gz
 3c51fa93a24946e0b34689e4872ebe08  1522306 
main/binary-alpha/Packages.bz2
 3af8fbafe3e4538520989de964289712   83 main/binary-alpha/Release
 ef9692928e79c6d4d7854d39d3232146  7296460 main/binary-arm/Packages
 0919eb088b48f6ec67ad01fc7aa0c909  1976268 main/binary-arm/Packages.gz
 ff6feaeb1002fdf04911cdaac164e5f1  1511137 main/binary-arm/Packages.bz2
 9fc7715e97078b34314e617f50209d2e   81 main/binary-arm/Release
 d0709e1d86866c7c818cc5656c8b87cf  7121087 main/binary-hppa/Packages
 e642f1758ca4a25bf2c8127e8efa0aae  1926528 main/binary-hppa/Packages.gz
 3cd030109910e7f8fde3ba36cd3147ab  1473196 main/binary-hppa/Packages.bz2
 1ab866241b09154589453958

Re: Improper NMU (Re: NMU for libquota-perl)

[Stephen Depooter]

On Tue, 2002-09-03 at 18:13, Andrew Suffield wrote:
> 
> And lastly, am I the only one who finds complaining about *other
> people* wasting effort to be insane in a volunteer-based organisation?
> There's a difference between advice, and telling people what to spend
> their time on.

Am I the only one who feels that more time has been wasted in this
thread than by anyone doing a simple NMU, whether they followed policy
or not :)

-- 
Stephen Depooter
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>

Re: Dependencies on -dev packages

[Andrew Suffield]

On Tue, Sep 03, 2002 at 01:57:33PM -0700, Stephen Zander wrote:
> > "Ray" == J H M Dassen  writes:
> Ray> How opaque is that opaque when considering the case of
> Ray> linking against a library statically?
> 
> That need might reasonably be met with a Recommends: or Suggests:

Recommends and Suggests are not considered when installing
build-dependencies.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpux4IfEZvF6.pgp
Description: PGP signature

Re: task-spanish exists: expansion proposal (was Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish))

[Rene Engelhard]

Hi Joey,

Joey Hess wrote:
> Javier Fernández-Sanguino Peña wrote:
> > Thanks. Then is everyone ok if I include (or submit bug against the 
> > packages that
> > don't) Task: spanish to the control files for
> 
> No, that's not how it works. File a bug against tasksel if you are not
> seeing the spanish task, which it already has.

Hmm. According to the latest policy the Task: method should be used
which I think is not the best thing...

From the changelog of Debian policy package:

debian-policy (3.5.7.0) unstable; urgency=low

[...]
 * we no longer have task packages, instead, we define tasks using a
special field in the control file (and these should be added only
after discussion on the mailing lists)closes: Bug#97755 
[...]

 -- Manoj Srivastava <[EMAIL PROTECTED]>  Sat, 31 Aug 2002 02:18:02 -0500

Regards,

Rene
-- 
  .''`. Rene Engelhard -- Debian GNU/Linux Developer 
 : :' : http://www.debian.org | http://people.debian.org/~rene/ 
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


pgpGpStJ5XTWv.pgp
Description: PGP signature

Bug#159522: ITP: gjay -- an automatic and learning DJ for xmms

[martin f krafft]

Package: wnpp
Version: N/A; reported 2002-09-03
Severity: wishlist

* Package name: gjay
  Version : 0.1
  Upstream Author : Chuck Groom <[EMAIL PROTECTED]>
* URL : http://gjay.sourceforge.net
* License : GPL
  Description : an automatic and learning DJ for xmms

>From the webpage:
  GJay (Gtk+ DJ) generates playlists across a collection of music
  (mp3, ogg, wav) such that each song sounds good following the
  previous song. Matches are based on both automatically analyzed song
  characteristics (BPM, frequency) as well as user-assigned
  categorizations (song 'color' and rating). It is ideal for DJs
  planning a set list or home users who want a non-random way to
  wander large collections.

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux fishbowl 2.4.18+machine #1 Sun Mar 24 02:15:23 CET 2002 i686
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=de_DE.ISO-8859-15

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
 
"frank harris has been received
 in all the great houses -- once!"
-- oscar wilde

Bug#159523: ITP: rrdcollect -- RRDcollect - Round-Robin Database Collecting Daemon

[qnex]

Package: wnpp
Version: N/A; reported 2002-09-04
Severity: wishlist

* Package name: rrdcollect
  Version : 0.2
  Upstream Author : Dawid Kuroczko <[EMAIL PROTECTED]>
* URL : http://rrdcollect.sourceforge.net/
* License : GPL
  Description : RRDcollect - Round-Robin Database Collecting Daemon

 RRDcollect is a daemon which polls ceratin files in /proc/
 directory, gathering data and storing it inside RRDtool's
 database files.  Being written in C should be both fast
 and resources-friendly.  Supports both scanf(3)-style
 pattern matches and perl compatible regular expressions.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux atlantis.ssw.krakow.pl 2.4.19-qnex #9 SMP Sun Aug 25 01:56:36 
CEST 2002 i686
Locale: LANG=C, LC_CTYPE=pl_PL (ignored: LC_ALL set)

-- no debconf information

Re: Improper NMU (Re: NMU for libquota-perl)

[Andrew Suffield]

On Tue, Sep 03, 2002 at 02:19:03PM +0200, Josip Rodin wrote:
> A NMU is a waste of effort if the same thing can be done by the maintainer
> after just one quick email message -- primarily a waste of effort for the
> NMUer who has to go in and figure out how to fix the package, not the
> maintainer. If we can save others that time by doing what we're simply
> supposed to do, well, I see no reason not to do that.

This argument is bogus. Updating a Build-Depends and rebuilding the
package is trivial (not least because the system is designed to make
it trivial).

Also, in general, it's hard to create a suitable patch and send it to
the BTS, and trivial to apply the patch and build the package.

And lastly, am I the only one who finds complaining about *other
people* wasting effort to be insane in a volunteer-based organisation?
There's a difference between advice, and telling people what to spend
their time on.

There may be valid reasons for not making NMUs in these circumstances,
but this is not one of them.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpVjsRqP0jxy.pgp
Description: PGP signature

Re: Dumb little utilities

[Clint Adams]

And if you use zsh, you don't need to bother with mmv or rename, since
there's zmv.

> > Anyway, it's similar to the 'rename' command that someone else mentioned.
> > It renames multiple files like converting all the files in a directory
> > from upper to lower case
> 
>   mmv \* \#l1

zmv '(*)' '${(L)1}' 

> > or changing the extension of the *.c files to *.x.
> 
>   mmv \*.c \#1.x

zmv '(*).c' '$1.x'

or

zmv -W '*.c' '*.x'

or

alias ren='noglob zmv -W'
ren *.c *.x


I find the last preferable to the more cumbersome syntaxes of rename and
mmv.

Re: Dumb little utilities

[Malcolm Parsons]

On Tue, Sep 03, 2002 at 01:07:28PM -0600, J. Scott Edwards wrote:
> 
> On Wed, 28 Aug 2002 Marcelo E. Magallon wrote:
> 
> >
> > >> Ola Lundqvist <[EMAIL PROTECTED]> writes:
> >
> >  > > tab and untab (I just discovered that this can be done with pr).
> >  > If it can be done with something else it might not be too necessary. It
> >  > is your choice though.
> >
> >  JFYI, it can also be done with expand.
> >
> 
> One down.  Is there a program to do the reverse and convert the spaces to
> tabs?

unexpand.

Re: Dependencies on -dev packages

[Stephen Zander]

> "Ray" == J H M Dassen  writes:
Ray> How opaque is that opaque when considering the case of
Ray> linking against a library statically?

That need might reasonably be met with a Recommends: or Suggests:

-- 
Stephen

To Republicans, limited government means not assisting people they
would sooner see shoveled into mass graves. -- Kenneth R. Kahn

Re: Dependencies on -dev packages

[Goswin Brederlow]

Stephen Zander <[EMAIL PROTECTED]> writes:

> What is the thinking behind always requiring libfoo-dev to depend on
> libbar-dev when libfoo depends on libbar?  I understand the need when
> /usr/include/foo.h contains
> 
>   #include 
> 
> but if libfoo opaquely wraps libbar, why have libfoo-dev depend on
> libbar-dev?

Do you have a case where theres no #include ? Then you would
just build-depend on libbar-dev.

If it works 100% without there is no need to depend.

MfG
Goswin

Re: Dumb little utilities

[Goswin Brederlow]

"J. Scott Edwards" <[EMAIL PROTECTED]> writes:

> On Wed Aug 28 11:37:29 2002 Allan Wind wrote:
> > On 2002-08-27 21:59:28, J. Scott Edwards wrote:
> > > file slicer (that can slice up a file into different size chunks).
> >
> > dd?
> 
> Yea, that would do it, slightly more cumbersome to use.

split ?

MfG
Goswin

Re: Improper NMU (Re: NMU for libquota-perl)

[Goswin Brederlow]

Martin Wheeler <[EMAIL PROTECTED]> writes:

> On Mon, 2 Sep 2002, Sebastian Rittau wrote:
> 
> >  If you're not able to maintain
> > your packages properly and in a timely manner, and your holding up a
> > major part of the distribution, it's your fault.
> 
> I'm interested in this.
> Individuals differ greatly in their working methods.
> So what is considered: "in a timely manner"?  (Seriously.)
> 
> I have dropped out of several co-operative projects in the past simply
> because I'm a relatively "slow" worker -- i.e. I don't tend to give three
> or four fast responses to collective development _in the same day_.
> I find that sort of speed of progression highly de-motivating.
> Am I alone in this?  (I might take up to a week to respond to any
> particular event -- this is normal for _me_.)
> 
> I'm curious as to what the expectations of other debian-developers are --
> for example, does not being online 24/7 -- or even once a day --
> effectively create a barrier to participation in collective development
> projects in debian?  (Theory would say: No.  But what does _practical_
> experience dictate?)

That completly depends on the problem at hand. For example if the
group is fixing a security bug responding a week later probably
doesn't help and you would be left out.

If you discuss where to go next, what parts to improve or how to
extend the interface of a library or such, discussing it for a month
might be normal and needed to get a proper consensus. 

> So I guess my question really is: what is "timely"; and what is
> "untimely"?
> Where is it defined?  By whom?  Does it make sense?

Its a case to case basis, so it full of errors, opinions and
flamewars.

MfG
Goswin

Re: Dependencies on -dev packages

[J.H.M. Dassen (Ray)]

On Tue, Sep 03, 2002 at 11:58:10 -0700, Stephen Zander wrote:
> but if libfoo opaquely wraps libbar, why have libfoo-dev depend on
> libbar-dev?

How opaque is that opaque when considering the case of linking against a
library statically?

Ray
-- 
"The problem with the global village is all the global village idiots."
Paul Ginsparg

Re: Dumb little utilities

[J. Scott Edwards]

On Tue, 3 Sep 2002, I wrote:

>
> On Wed, 28 Aug 2002 Romain Lerallut wrote:
> >
> > Thus spake J. Scott Edwards on Tue, Aug 27, 2002 at 09:59:28PM -0600:
> > > file renamer (that can change case).
> >
> > Just asking: anything that mmv can't do ?
> >
>
> (I guess that you meant 'mv'?)
>


I feel appropriately stupid now.  I checked on my machine and there was no
mmv so I thought perhaps it was just a typo.  But I just installed 'mmv'
and you're right it sounds similar all right.  I haven't quite figured mmv
out yet so I can't say if it's the same thing or not.

Sorry,
  -Scott

Re: Some proposals about the Email-subsystem, was Re: RFC: OpenLDAP and TLS/SSL

[Jorge . Lehner]

Hello!

On Mon, Sep 02, 2002 at 01:52:13PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Sun, Aug 25, 2002 at 02:56:46PM +1000, Martijn van Oosterhout wrote:
...
> > What I'm saying is that to must have a mail-server install, even if it is
> > just ssmtp or something like that.
> 
>   Yes, however the mail server should not be running as a daemon nor
> listening for incoming port 25 connections.
...

I checked out ssmtp and it is not what we would eventually want.  It
does not deliver _any_ mail locally.

Indeed procmail cannot deliver local mail, and I though about writing
some script which acomplishes the simple task of distinguishing
between local and remote recipients and pipe the local ones a copy via
the default delivery method, while putting the remote ones into a kind
of outgoing queue.  However has it done or is faster than I, go ahead.

Javier states it clearly, it is not necessary to have a daemon running
for this.


Best Regards,

 Jorge-León

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Jorge . Lehner]

Hello!


On Sat, Aug 31, 2002 at 05:16:15AM -0400, Colin Walters wrote:
> On Fri, 2002-08-30 at 23:05, Goswin Brederlow wrote:
> 
> > That will also break rsyncing them, which saves a lot.
> 
> Let's just keep pestering gzip upstream to include the rsyncable patch.
...

I want to second this, as the low-bandwidth, low-featured computer
branded one.

This would allow to retrieve package diff's (with jigdo, rsync or
whatever), instead of re-downloading the everyday bigger .deb's,
just because three lines were added to the README file.

Another issue is, that at my observation bzip2 is muuuch slower on
computers with little (available) memory, so spared download time
reverts to wasted decompression time.  It should not be a problem to
have plain-text Package files as well as .gz and .bz2 on a mirror, so
the downloading user can select between download speed and processing
speed at will.

Regards,

Jorge-León

Re: RFC: A regression test framework for Debian packages?

[Jérôme Marant]

Anthony Towns  writes:


> Build time is important too: that's the only time you can attempt fine
> grained testing of modules rather than executables, and it lets you catch
> problems before you upload too. eg, after some irritating bugs that happened
> to only show up on one or two architectures, I added some regression tests
> to ifupdown, which basically:
...
> These all seem pretty hard to actually do. Useful, but hard. Something
> that might also be useful, and isn't that hard could be letting you
> check that particular files actually end up in the .deb you're creating,
> with particular ownerships and permissions.

Very nice piece of information. Thank you.

Cheers,

-- 
Jérôme Marant

http://marant.org

Re: foomatic unmaintained?

[Samuli Suonpaa]

Rainer Dorsch <[EMAIL PROTECTED]> writes:
> Hello,
>
> some weeks ago I was installing an HP OfficeJet and on the hpoj
> mailing list somebody was pointing out that I need the latest
> version of foomatic to get good results.but it seems that the
> Debian foomatic-{bin,db} packages in sid are outdated. I contacted
> the maintainer, Manfred Wassmann, but so far no response.

What exactly is the problem with foomatic you are having? I've used
first Woody's and later Sarge's foomatic and hpoj with my OfficeJet
G55 for a long time and they've always seemed to perform just fine.

Suonpää...

Re: Dumb little utilities

[Colin Watson]

On Tue, Sep 03, 2002 at 01:02:20PM -0600, J. Scott Edwards wrote:
> On Wed, 28 Aug 2002 Romain Lerallut wrote:
> > Thus spake J. Scott Edwards on Tue, Aug 27, 2002 at 09:59:28PM -0600:
> > > file renamer (that can change case).
> >
> > Just asking: anything that mmv can't do ?
> 
> (I guess that you meant 'mv'?)

There really is something called 'mmv'. Check the package by the same
name.

For example:

> Anyway, it's similar to the 'rename' command that someone else mentioned.
> It renames multiple files like converting all the files in a directory
> from upper to lower case

  mmv \* \#l1

> or changing the extension of the *.c files to *.x.

  mmv \*.c \#1.x

The ';' character on the left-hand side can be used to recurse through
subdirectories.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Improper NMU (Re: NMU for libquota-perl)

[Colin Watson]

On Tue, Sep 03, 2002 at 03:03:34PM -0400, Stephen Frost wrote:
> Additionally I'm of half a mind to suggest that the maintainer have the
> ability to remove the files from the DELAYED system; their timing may be
> off, the person who put them there may be unavailable, etc.

I agree. Actually I was slightly surprised to discover it isn't possible
to do that at the moment.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Dumb little utilities

[J. Scott Edwards]

On Wed, 28 Aug 2002 Marcelo E. Magallon wrote:

>
> >> Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
>  > > tab and untab (I just discovered that this can be done with pr).
>  > If it can be done with something else it might not be too necessary. It
>  > is your choice though.
>
>  JFYI, it can also be done with expand.
>

One down.  Is there a program to do the reverse and convert the spaces to
tabs?

-Scott

Re: Dumb little utilities

[J. Scott Edwards]

On Wed, 28 Aug 2002 Romain Lerallut wrote:
>
> Thus spake J. Scott Edwards on Tue, Aug 27, 2002 at 09:59:28PM -0600:
> > file renamer (that can change case).
>
> Just asking: anything that mmv can't do ?
>

(I guess that you meant 'mv'?)

Anyway, it's similar to the 'rename' command that someone else mentioned.
It renames multiple files like converting all the files in a directory
from upper to lower case or changing the extension of the *.c files to
*.x.

-Scott

Re: Improper NMU (Re: NMU for libquota-perl)

[Stephen Frost]

* Raphael Hertzog ([EMAIL PROTECTED]) wrote:
> Le Tue, Sep 03, 2002 at 01:01:33PM -0500, The Doctor What écrivait:
> > * Elie Rosenblum ([EMAIL PROTECTED]) [020902 11:43]:
> > > DELAYED is fine. Not submitting a bug is not fine.
> > 
> > Can DELAYED be set up to email the maintainer with the changelog?
> > 
> > Would that help the "unexpected" NMU from ambushing the maintainer?
> 
> The NMUer sends a mail (the patch) at the same time he uploads to
> DELAYED. So there's no point in doing anything automatic with DELAYED...

The NMUer is supposted to, yes.  Unfortunately it doesn't always work
that way and as such I think it'd still be nice to get a notice from the
system that there is a package you maintain uploaded by someone else in
the DELAYED queue.

Additionally I'm of half a mind to suggest that the maintainer have the
ability to remove the files from the DELAYED system; their timing may be
off, the person who put them there may be unavailable, etc.  Though
according the guidelines one isn't supposted to NMU if the maintainer is
active so (assuming people follow the guidelines) this ability might not
get used much.

Stephen


pgpsaBTorViFZ.pgp
Description: PGP signature

Re: old ITP's

[Roland Bauerschmidt]

Noah Meyerhans wrote:
> program called xplot.  Consider using the alternatives system for that.
> You'll need to coordinate with the maintainer of the other xplot package
> for that to work.

That sounds ugly though - having an alternative for something that does
entirely different stuff. Isn't it possible to rather rename the "new"
version of xplot to, say, xtcpplot or something?

-- 
Roland Bauerschmidt

Re: Improper NMU (Re: NMU for libquota-perl)

[Eduard Bloch]

#include 
* Peter Mathiasson [Tue, Sep 03 2002, 06:44:54PM]:
> On Tue, Sep 03, 2002 at 02:19:03PM +0200, Josip Rodin wrote:
> > NMUer time is better spent on really unmaintained packages.
> 
> Amen.

Dito. Unused and maintained package are not bad, they will be excluded
if they have RC bugs. But frequently used packages with MIA maintainers
are worse, especially when nobody dares to make the NMU.

Even worse are the "mine, all mine" maintainers that want to be the
official maintainer of some prominent package, allowing noone to touch
the stuff, even if sHe has no time or no motivation to improve the
package or even fix the bugs.

Come on people, it is unstable and the transitions are announced. If the
particular maintainer does not follow the development, other should be
allowed to "help" him. If the package is really needed by some people,
and became uninstallable in unstable, that is a state of no-go and
should be fixed by NMUs, if neccessary. Of course, some quality tests
are better made by the maintainer, but obvious changes should not stop
the development. If really bad things happens just because of the
recompilation, than the package is faulty anyways.

Gruss/Regards,
Eduard.
-- 
Space Cadet wrote:
> wird jetzt aus meinem 100%-WindowsNTkompatiblen, 100%-absturzsicheren
> Microsoft Outlook Express 5.0 (ist übrigens auch Freeware) entfernt.
So ein Glück aber auch. Spart den Eintrag im Killfile.
   (Jörg Fischer in dcoulh)

Dependencies on -dev packages

[Stephen Zander]

What is the thinking behind always requiring libfoo-dev to depend on
libbar-dev when libfoo depends on libbar?  I understand the need when
/usr/include/foo.h contains

  #include 

but if libfoo opaquely wraps libbar, why have libfoo-dev depend on
libbar-dev?

-- 
Stephen

"Farcical aquatic ceremonies are no basis for a system of government!"

Re: old ITP's

[Noah Meyerhans]

On Mon, Sep 02, 2002 at 07:06:23PM -0700, Vikram wrote:
> 
> If you are too busy for this I still offer to look into packaging tcptrace
> with xplot.

If you want to go ahead and package xplot, please do.  You'll need to
handle the fact that we've already got an xplot package that installs a
program called xplot.  Consider using the alternatives system for that.
You'll need to coordinate with the maintainer of the other xplot package
for that to work.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgpZrwUcqF3mH.pgp
Description: PGP signature

Re: Improper NMU (Re: NMU for libquota-perl)

[Raphael Hertzog]

Le Tue, Sep 03, 2002 at 01:01:33PM -0500, The Doctor What écrivait:
> * Elie Rosenblum ([EMAIL PROTECTED]) [020902 11:43]:
> > DELAYED is fine. Not submitting a bug is not fine.
> 
> Can DELAYED be set up to email the maintainer with the changelog?
> 
> Would that help the "unexpected" NMU from ambushing the maintainer?

The NMUer sends a mail (the patch) at the same time he uploads to
DELAYED. So there's no point in doing anything automatic with DELAYED...

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: NMU for bayonne

[Raphael Hertzog]

Le Tue, Sep 03, 2002 at 08:12:58PM +1000, Mark Purcell écrivait:
> Bas,

Mark,

why do you need to complain about that in -devel ?

> It is actually courtesy to file a bug/ contact the maintainer prior to 
> uploading a NMU (even to DELAYED/3-day). Have a look at Bug #159174 which I 
> received two hours after your NMU notification.

Please subscribe to debian-devel-announce and you'd have heard of the
perl migration before ...

BTW, the patch that bas sent to you was correct, and the one that you did
was not...

> > 0.9.0-2) , libccscript-dev (>= 2.0.2-2), libperl-dev (>= 5.8), zlib1g-dev,

You have to build-depends on libperl-dev (>= 5.8) to be sure that your
package will get recompiled with perl 5.8 and not again with perl 5.6
...

Your upload doesn't have the good build dependency. If you simply
applied the patch the NMUer sent you, you would have no troubles
at all. :-)

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: Dumb little utilities

[J. Scott Edwards]

On Wed Aug 28 11:37:29 2002 Allan Wind wrote:

>
> On 2002-08-27 21:59:28, J. Scott Edwards wrote:
> > tab and untab (I just discovered that this can be done with pr).
>
> tr

I'm not the brightest bulb in the box, so perhaps it's just me, but tr
seems kind of a complicated way to do this.  I don't even see how to use
it for that.  If I wanted to change all of the files that I have that
are tabbed for 8 stops and change them to 3, to me it seems easier to just
do:

untab -t 8 *.e
tab -t 3 *.e


> > file renamer (that can change case).
>
> rename

Yup that would do it (it would be nicer if it could do the directories
recursively).

> > file slicer (that can slice up a file into different size chunks).
>
> dd?

Yea, that would do it, slightly more cumbersome to use.


> > convert wave <--> raw audio files
>
> sox
>


I will take a look at that.

Thanks
  -Scott

Re: Improper NMU (Re: NMU for libquota-perl)

[The Doctor What]

* Elie Rosenblum ([EMAIL PROTECTED]) [020902 11:43]:
> DELAYED is fine. Not submitting a bug is not fine.

Can DELAYED be set up to email the maintainer with the changelog?

Would that help the "unexpected" NMU from ambushing the maintainer?

Ciao!

-- 
When the only tool you have is a hammer, you tend to treat everything as if
it were a nail.
 -- Abraham Maslow

The Doctor What: Un-Humble   http://docwhat.gerf.org/
[EMAIL PROTECTED]   KF6VNC


pgp6CY8dl5wiH.pgp
Description: PGP signature

Re: Improper NMU (Re: NMU for libquota-perl)

[Raphael Hertzog]

Le Tue, Sep 03, 2002 at 12:52:52PM +0200, Josip Rodin écrivait:
> I agree, filing bugs and direct mails are much better than -devel-announce
> posts, much less likely for one to skip by accident IMHO.

Can we file bugs to ask that a package needs to be recompiled and uploaded
in a staging area ?

That would have been the best, informing all the maintainers as soon as
possible...

The bugs would have been wishlist initially. Once the maintainer
uploaded a fixed package to the staging area, he tags it pending
(it will be closed when the upload reaches unstable).

Once the packages from the staging area are moved in unstable, the
non-pending bugs (for non-updated packages) are changed to severity
serious (or grave or whatever).

At the time of the BSP, nobody could complain of not beeing
informed...

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Bug#159496: ITP: libsdl-console -- Console for SDL application

[Julien Danjou]

Package: wnpp
Version: N/A; reported 2002-09-03
Severity: wishlist

* Package name: libsdl-console
  Version : 1.1
  Upstream Author : Boris Lesner <[EMAIL PROTECTED]>
Garrett Banuk <[EMAIL PROTECTED]> 
* URL : http://sdlconsole.tuxfamily.org
* License : GPL
  Description : Console for SDL application


This is a console that can be added to any SDL application. It is similar to 
Quake and other game consoles but with lots of added features. A console is 
meant to be a very simple way of interacting with a program and executing 
commands. Commands are linked to the console with callback functions so that 
when a command is typed in, a specific function is executed automatically. 

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux abydos 2.4.19 #1 dim sep 1 22:42:08 CEST 2002 i686
Locale: LANG=fr_FR, LC_CTYPE=fr_FR

-- 
Julien Danjou

(°>  - http://hno3.org <[EMAIL PROTECTED]> -
//\  - http://tuxfamily.org   <[EMAIL PROTECTED]> -
V_/_ GPG: 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


pgp5n8fFNouXJ.pgp
Description: PGP signature

Re: Kernel problem

[Michael Meskes]

On Tue, Sep 03, 2002 at 08:11:41PM +1000, Herbert Xu wrote:
> Which 2.4.19 kernel package did you install and what is the exact
> error message?

The "error" message is:

BIOS data check successful

Interestingly the very same message is printed my my manually installed
2.4.18 kernel, but not by the 2.4.18 debian package. The kernel from
this package stops working even before the message is printed.

BTW I just noticed that there is a break between the dots when loading
the Debian kernel. It does print quite some dots followed by a few
blanks and one final dot. Maybe that's normal and I never noticed since
you rarely see these dots. :-)

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: Improper NMU (Re: NMU for libquota-perl)

[Peter Mathiasson]

On Tue, Sep 03, 2002 at 02:19:03PM +0200, Josip Rodin wrote:
> NMUer time is better spent on really unmaintained packages.

Amen.

-- 
Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu
GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228


pgpydQfe90SCO.pgp
Description: PGP signature

foomatic unmaintained?

[Rainer Dorsch]

Hello,

some weeks ago I was installing an HP OfficeJet and on the hpoj mailing list 
somebody was pointing out that I need the latest version of foomatic to get 
good results.but it seems that the Debian foomatic-{bin,db} packages in 
sid are outdated. I contacted the maintainer,  Manfred Wassmann, but so far 
no response.

This could mean that the maintainer is simply to busy to respond and invests 
his time better in maintaining the package than answering stupid email or 
more likely that the package is unmaintained

In this case, maybe somebody familar with foomatic may want to take it...to 
help to prepare Debian for the desktop for the masses.

Thanks.
Rainer 

Re: lilo-22.3.2-3 trashed my SCSI disk

[Russell Coker]

On Tue, 3 Sep 2002 08:44, Svante Signell wrote:
> After upgrade of lilo in unstable my whole SCSI disk got trashed. It
> could only be recovered with the use of the IBM drive fitness test
> tool, and a complete erase disk was necessary :-( What happened?

If you need to run an IBM diagnostics program to get your disk working then 
it's a hardware issue and nothing to do with LILO.

LILO like all Linux programs does not get to talk to the hardware directly and 
only gets to write data to the block device (/dev/sda or /dev/sda1).  If 
writing to such a device can require special IBM utilities to recover then 
it's a hardware or device driver issue (but most likely hardware).

> A reinstall of Woody showed that it can only boot from the MBR
> partition, not the root partition, i.e.
>
> boot=/dev/sda, works!
> boot=/dev/sda1, does not work!

Strange, /dev/hda1 in the form of /dev/md1 works for me.

> What has changed for newer versions of lilo?  I have been running
> Debian stable/testing/unstable for several years now without any
> problems before.

22.3 was one of the biggest changes to LILO in recent times that did have 
potential to cause breakage.  The versions after that were minor changes.

> Note also that I have a dual disk system, SCSI and IDE, therefore the
> disk=, bios= statements in lilo.conf. The disk partitioning tools, such as
> cfdisk requires both the SCSI disk and the IDE disk to have at least
> one partition with the boot flag set. Is this really necessary?

No.  You don't really need any boot flags to be set.

> Does the install=menu stuff have anything to do with the crash?

No.  It's the default action anyway...

> Maybe grub is better with respect to error recovery?

If your hardware fails to badly that Linux programs can't fix it then grub vs 
LILO is not an issue.


Russell Coker


PS  Let's move this to debian-user.

Re: Stacked Debconf

[Joey Hess]

Henning Glawe wrote:
> the manpage of debconf.conf says it uses the topmost writable database
> in a stack for saving users choices. But debconf complains if the 
> topmost database in a stack isn't writable. 

This will be fixed in a future release.

-- 
see shy jo


pgpIV3RmBj44W.pgp
Description: PGP signature

Re: Where are tasks now and how are they handled?

[Erich Schubert]

>   Then the policy document is wrong? Shouldn't it be bugged?

I guess the policy document describes how this is to be done _now_.
(That is after woody ;)
Whereas the override file was they way this was handled for woody.

Maybe ask on debian-policy on this issue?

Greetings,
Erich

-- 
erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C
A polar bear is a rectangular bear after a coordinate transform.
Ein Freund ist ein Geschenk, das man sich selbst macht.
   Humor sollte immmer dabeisein, auch bei Problemen.

Re: task-spanish exists: expansion proposal (was Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish))

[Joey Hess]

Javier Fernández-Sanguino Peña wrote:
> Thanks. Then is everyone ok if I include (or submit bug against the packages 
> that
> don't) Task: spanish to the control files for

No, that's not how it works. File a bug against tasksel if you are not
seeing the spanish task, which it already has.

Try running 'dselect update' first though.

-- 
see shy jo


pgpLEgQFSU5RR.pgp
Description: PGP signature

Re: [PHP] Placement of PHP programs?

[alex]

On Mon, Sep 02, 2002 at 05:30:13PM -0700, Ian Zimmerman wrote:
> Well, I have always held (right or wrong) pretty much the opposite
> view to yours: /var/www _is_ for Debian content, and local content
> belongs in /usr/local.  (thats why you don't see all that much in my
> /var/www :-] )

IMO this is wrong, too. Local variable content should go to /var/local.

Alex

-- 
Janusz A. Urbanowicz, stomil at jabber.org, PGP 0x21939169

ÃÀÖÝÏßÔ˼Û

[ºãÈÙ¹ú¼Ê»õÔËÓÐÏÞ¹«Ë¾]

您好

本邮件属善意邮件,打扰之处,敬请见谅!!

如果得到您的支持，我们一定保证您的舱位，以方便您的贸易操作


上海至  九月一日执行
***
目的港  20' 40' 40HQ船东  船期  
 
*** 
北美洲(ALL IN)  

BALTIMORE   210027503200MSC 周三
CHARLESTON  210027503200MSC 周三
250032503650COSCO   周二
HOUSTON 210027503200MSC 周三
JACKSONVILLE*   210027503200MSC 周三
LONGBEACH   135018002000MARUBA  周二

155021002400COSCO   周三
LOS  AGELES 135018002000MARUBA  周二

155021002400COSCO   周三
MONTREAL230030003350CLAN.S.A周二
NEW  ORLEANS210027503200MSC 周三
NEW  YORK   210027503200MSC 周三
250032503650COSCO   周二
NORFOLK 210027503200MSC 周三
250032503650COSCO   周二
OAKLAND 135018002000MARUBA  周二

155021002400COSCO   周三
SAVANNAH210027503200MSC 周三
SEATTLE 155021002400COSCO   周三
TORONTO 230030003350CLAN.S.A周二
VANCOUVER   165021502400CLAN.S.A周二



中美洲(ALL IN)   
BALBOA  190030003200CSAV

COLON   190030003200CSAV
CRITOBAL190030003200CSAV
KINGSTON270039004000ZIM 周四
MANZANILLO（墨西哥）120024002500CLAN.S.A周二
MANZANILLO（巴拿马）190030003200CSAV
MEXICO CIYT 195033003400建恒周六
PANAMA CITY 230030503150LYKES   周二

南美洲(ALL IN)   
ASUNCION195039004000建恒周六
BUENAVENTURA140028002900CLAN.S.A周二
BUENS  AIRES125025002600北欧亚  周四
CALLAO  145028002900长荣周二.四
GUANTA  250035003800ZIM 周四
GUAYAQUIL   145028002900长荣周二.四
IQUIQUE 145028002900长荣周二.四
ITAJAI  135025502650BEN-LINE周一四
140028002900建恒周六
LA  GUAIRA  250035003800ZIM 周四
MONTEVIDEO  125025002600北欧亚  周四
PARANAGUA   110022002300百威周三
120024002500建恒周六
PUERTO  CABELLO 250035003800ZIM 周四
RIO  DE  JANEIRO125025002600北欧亚  周四
RIO  GRANDE 125025002600北欧亚  周四
135027002800建恒周六
SAN  ANTONIO145028002900长荣周二.四
SANTOS  125025002600北欧亚  周四
VALPARAISO  145028002900长荣周二.四

注:同时承接美国内陆点/特种箱/长江沿线的货物
   到付货/门道门/中转/进口反定舱(运价特优)


以上运价是不完全运价,如果阁下要查询其他点价格,
欢迎来电垂询:

世聚物流上海代表处
恒荣国际货运有限公司
电话:021-65861818(80线)
分机:266/264
传真:021-65869003/65869001
手机:0-13166217040
邮箱:[EMAIL PROTECTED]
联系人：郭 先生
 

谢谢



邮件内容与以下文字无关=

优联网络 http://www.chinamysql.com  专业提供各类虚拟主机，不满意可获退款。

强势套餐：100M主机送顶级域名，送10个10M企业油箱，加送20个二级域名，仅需318元/年！


三龙证券投资 http://3long.sayba.com 
为您提供专业理财服务。现在购买只需588元，赠送价值超过1800元的礼品！

说吧网上商城 http://shop.sayba.com 
全是厂商直销的新品或折上折的商品，是您网络购物的好去处！


使用极星邮件群发，无须通过邮件服务器，直达对方邮箱，速度绝对一流！

软件下载网址：http://www.lovexin.com，更多的超酷软件等你来下载哦！;

Re: pbuilder sid chroot libpcap0

[Stefano Zacchiroli]

On Tue, Sep 03, 2002 at 03:25:16PM +0200, Stefano Zacchiroli wrote:
> Anyway, do you know when a fixed version of pbuilder will be available?

Never mind: I've just tried a "pbuilder create --distribution sid" and
it worked fine.

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
[EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney


pgprrertaIdX5.pgp
Description: PGP signature

Re: pbuilder sid chroot libpcap0

[Stefano Zacchiroli]

On Tue, Sep 03, 2002 at 09:55:06PM +0900, Junichi Uekawa wrote:
> You may upgrade your chroot from woody.
> 
> pbuilder create --distribution woody
> pbuilder update --distribution sid

Tnx for the hint.

Anyway, do you know when a fixed version of pbuilder will be available?
I have to use pbuilder on a machine where is available only a mirrored
sid repository.

TIA,
Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
[EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney


pgp4Nt4fbt5KP.pgp
Description: PGP signature

Re: Is it me, pbuilder, dpkg or something else?

[Junichi Uekawa]

On Tue, 3 Sep 2002 12:30:43 +0300
[EMAIL PROTECTED] wrote:
> Extracting source
> unable to get login information for username "shaul" at
> /usr/lib/dpkg/controllib.pl line 56.
> Compilation failed in require at /usr/bin/dpkg-source line 22.
> pbuilder: Failed extracting the source
>  -> unmounting /proc filesystem
>  -> unmounting /dev/pts filesystem
>  -> cleaning the build env 
> [EMAIL PROTECTED]:/tmp# exit
> exit
> 
This error is being emit inside the chroot, which 

> 
> [EMAIL PROTECTED]:/tmp$ getent passwd shaul
> shaul:x:1000:1000:Shaul Karl,,,:/home/shaul:/bin/bash
> [EMAIL PROTECTED]:/tmp$ 

should be untrue.

There is probably something else in your setup that is broken.


regards,
junichi

-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: pbuilder sid chroot libpcap0

[Junichi Uekawa]

On Tue, 3 Sep 2002 12:40:02 +1000
Brian May <[EMAIL PROTECTED]> wrote:
 
> I can't install the latest version of debootstrap (in case this
> is going to help), the whole idea of using pbuilder was so I don't
> have to upgrade libc6 to unstable on my host system.

You may upgrade your chroot from woody.

pbuilder create --distribution woody
pbuilder update --distribution sid





regards,
junichi


-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: Improper NMU (Re: NMU for libquota-perl)

[Josip Rodin]

On Tue, Sep 03, 2002 at 01:58:57PM +0200, Peter Mathiasson wrote:
> What I'm trying to say is, does it really matter? Why not just make a
> maintainer upload when you have time, be it before or after the NMU
> enters the pool.
> For you the NMU seems like a waste of time, but it was not a waste of
> _your_ time, nor of the current maintainers (except for looking at a
> diff which changed nothing but the build-depends field from what I can
> tell, w/o looking at neither the package nor the NMU).

I think someone can be a "current" maintainer even if they haven't uploaded
stuff instantly after a -d-a post.

A NMU is a waste of effort if the same thing can be done by the maintainer
after just one quick email message -- primarily a waste of effort for the
NMUer who has to go in and figure out how to fix the package, not the
maintainer. If we can save others that time by doing what we're simply
supposed to do, well, I see no reason not to do that.

NMUer time is better spent on really unmaintained packages.

-- 
 2. That which causes joy or happiness.

Re: Improper NMU (Re: NMU for libquota-perl)

[Peter Mathiasson]

On Tue, Sep 03, 2002 at 01:49:14PM +0200, Josip Rodin wrote:
> How about we start from the simple issue of notifying maintainers and making
> sure they are _aware_ of the exact problems? People can be reasonably alert
> for fixing their packages without knowing what's that's going on in the
> bigger scheme of things.

One can argue about that being done through the d-d-a post.
IMO it's just no big deal, nothing to get upset about ...

> > Why get so upset about a, what I can tell from this discussion, working
> > NMU.
> 
> Nobody's upset.

... and I'm glad you're not :)

> > Though, a BTS entry would have been good, it wouldn't have made the
> > maintainer aware of the problem earlier (unless the NMU was delayed
> > until the maintainer had a time to fix it himself, of course).
> 
> The whole point of mailing beforehand is to leave it up to the maintainer to
> fix the bugs in their packages instead of wasting effort on doing NMUs.

What I'm trying to say is, does it really matter? Why not just make a
maintainer upload when you have time, be it before or after the NMU
enters the pool.
For you the NMU seems like a waste of time, but it was not a waste of
_your_ time, nor of the current maintainers (except for looking at a
diff which changed nothing but the build-depends field from what I can
tell, w/o looking at neither the package nor the NMU).

-- 
Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu
GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228


pgpCs2nj5g1TZ.pgp
Description: PGP signature

Re: Improper NMU (Re: NMU for libquota-perl)

[Mark Brown]

On Tue, Sep 03, 2002 at 01:25:34PM +0200, Peter Mathiasson wrote:

> And by the use of DELAYED it does not even need to be installed in the
> pool before you react. Why get so upset about a, what I can tell from
> this discussion, working NMU.

Having been in this position in the past I have to say that there's a
big difference between "Ah, the NMU I was expecting has appeared" and
"WTF?  An NMU?  Where did that come from?".

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

Re: Improper NMU (Re: NMU for libquota-perl)

[Josip Rodin]

On Tue, Sep 03, 2002 at 01:25:34PM +0200, Peter Mathiasson wrote:
> Therefore the NMU. When you have finally understood the problem and
> solved it, either through incorporating the NMU or in your own way, you
> (the maintainer) can upload a new version.

How about we start from the simple issue of notifying maintainers and making
sure they are _aware_ of the exact problems? People can be reasonably alert
for fixing their packages without knowing what's that's going on in the
bigger scheme of things.

> Why get so upset about a, what I can tell from this discussion, working
> NMU.

Nobody's upset.

> Though, a BTS entry would have been good, it wouldn't have made the
> maintainer aware of the problem earlier (unless the NMU was delayed
> until the maintainer had a time to fix it himself, of course).

The whole point of mailing beforehand is to leave it up to the maintainer to
fix the bugs in their packages instead of wasting effort on doing NMUs.

-- 
 2. That which causes joy or happiness.

Re: Improper NMU (Re: NMU for libquota-perl)

[Michael Banck]

On Tue, Sep 03, 2002 at 12:15:10PM +0100, Mark Brown wrote:
> > That depends on your mail-setup. IMHO it's reasonable to expect from DDs
> > to follow -devel-announce without accidently overlooking a post there or
> > two.
> 
> Seeing the mail is one thing.  Fully understanding it and grasping that
> it affects one of your packages and needs to be acted on right now is
> quite another, particularly since in the past this sort of thing has
> always involved filing bug reports.

OK, I get your point. That's right of course.

Michael

-- 
"alles hat Bugs außer TeX"
-- Lars Marowsky-Bree

ZINF [was: Re: ardour]

[Andreas Rottmann]

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

> On Sat, 31 Aug 2002, Robert Jordens wrote:
> > Users complained they were not able to compile ardour because of these
> > libraries and C++'s ABI instability.
> > So Paul Davis (upstream) decided to include all C++ libraries except
> > libstdc++ (I don't understand that exception) in the CVS tree. Namely
> 
ZINF does that, too. (zlib, libvorbis, unzip, gdbm, from a quick guess
at the sources). I guess I should bug upstream to at least have
configure options to have these linked from the system.

Andy
-- 
Andreas Rottmann | [EMAIL PROTECTED]| [EMAIL PROTECTED] | 
[EMAIL PROTECTED]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Re: Improper NMU (Re: NMU for libquota-perl)

[Peter Mathiasson]

On Tue, Sep 03, 2002 at 12:15:10PM +0100, Mark Brown wrote:
> > That depends on your mail-setup. IMHO it's reasonable to expect from DDs
> > to follow -devel-announce without accidently overlooking a post there or
> > two.
> 
> Seeing the mail is one thing.  Fully understanding it and grasping that
> it affects one of your packages and needs to be acted on right now is
> quite another, particularly since in the past this sort of thing has
> always involved filing bug reports.

Therefore the NMU. When you have finally understood the problem and
solved it, either through incorporating the NMU or in your own way, you
(the maintainer) can upload a new version.

And by the use of DELAYED it does not even need to be installed in the
pool before you react. Why get so upset about a, what I can tell from
this discussion, working NMU.

Though, a BTS entry would have been good, it wouldn't have made the
maintainer aware of the problem earlier (unless the NMU was delayed
until the maintainer had a time to fix it himself, of course).

-- 
Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu
GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228


pgpdwXIxIEAmM.pgp
Description: PGP signature

Re: Kernel problem

[Michael Meskes]

On Tue, Sep 03, 2002 at 08:11:41PM +1000, Herbert Xu wrote:
> Which 2.4.19 kernel package did you install and what is the exact
> error message?

2.4.19-k7.

As for the BIOS message, I will look it up when I get to the machine the
next time. It may take a day or two though. Anyway, that message did not
appear on 2.4.18-k7.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: Improper NMU (Re: NMU for libquota-perl)

[Mark Brown]

On Tue, Sep 03, 2002 at 12:57:10PM +0200, Michael Banck wrote:

> That depends on your mail-setup. IMHO it's reasonable to expect from DDs
> to follow -devel-announce without accidently overlooking a post there or
> two.

Seeing the mail is one thing.  Fully understanding it and grasping that
it affects one of your packages and needs to be acted on right now is
quite another, particularly since in the past this sort of thing has
always involved filing bug reports.

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

Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish)

[Philip Charles]

On Tue, 3 Sep 2002, Javier Fernández-Sanguino Peña wrote:

> On Tue, Sep 03, 2002 at 10:43:25AM +1200, Philip Charles wrote:
> > > |
> > > | Excerpt from the changelog:
> > > |   * we no longer have task packages, instead, we define tasks using a
> > > | special field in the control file (and these should be added only
> > > | after discussion on the mailing lists) closes: 
> > > Bug#97755
> > >
> > > uhm, they should _not_ be added to the control file.  They should be
> > > added by the override files plucked from base-config's CVS.  Skim the
> > > archives on -boot for information.
> > >   `. 
> > > `'
> > The info for the Tasks is in debian/indices/override.woody.extra.main.gz
> > if you want to have a look.  debian-cd then adds this info to the Packages
> > file.
>
>   Then the policy document is wrong? Shouldn't it be bugged?
>
>   Javi

Not very clear, I must admit.  I modify this particular override file if I
want to add packages to a task for custom CDs.  A new task could be
created the same way, but I am not certain if this canonical.

Phil.

--
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420
 [EMAIL PROTECTED] - preferred.  [EMAIL PROTECTED]
 I sell GNU/Linux & GNU/Hurd CDs.   See http://www.copyleft.co.nz

Re: Improper NMU (Re: NMU for libquota-perl)

[Josip Rodin]

On Tue, Sep 03, 2002 at 12:57:10PM +0200, Michael Banck wrote:
> > I agree, filing bugs and direct mails are much better than -devel-announce
> > posts, much less likely for one to skip by accident IMHO.
> 
> That depends on your mail-setup. IMHO it's reasonable to expect from DDs
> to follow -devel-announce without accidently overlooking a post there or
> two.

I follow it, and I saw that post, but I have forty packages, and I'm not
sure offhand if any of them have Perl dependencies strict enough to warrant
changes for Perl 5.8. At that particular time, I didn't really read all of
it because I was busy with other things. But I can assure you that I would
have cast other things aside to look closely at this if the post said "Your
package  is ".

Writing a direct mail is socially less error-prone, and technically
absolutely trivial, so I see no reason not to do it.

-- 
 2. That which causes joy or happiness.

Re: Improper NMU (Re: NMU for libquota-perl)

[Michael Banck]

On Tue, Sep 03, 2002 at 12:52:52PM +0200, Josip Rodin wrote:
> I agree, filing bugs and direct mails are much better than -devel-announce
> posts, much less likely for one to skip by accident IMHO.

That depends on your mail-setup. IMHO it's reasonable to expect from DDs
to follow -devel-announce without accidently overlooking a post there or
two.

Michael

-- 
"In a world of NDA-bound business agreements, Debian is an open book. In
a world of mission statements, Debian has a social contract."
--Evan Leibovitch, ZDNet

Re: Improper NMU (Re: NMU for libquota-perl)

[Josip Rodin]

On Mon, Sep 02, 2002 at 12:43:04PM -0400, Elie Rosenblum wrote:
> > The strict minimum is :
> > - create a patch for the NMU
> > - make the patch available to the maintainer (via direct mail or bts)
> 
> DELAYED is fine. Not submitting a bug is not fine.
> 
> I think he would have been within the guidelines by something as
> incredibly simple as a BTS entry. How fucking hard is that?

I agree, filing bugs and direct mails are much better than -devel-announce
posts, much less likely for one to skip by accident IMHO.

I've committed a patch for the appropriate section of the  developers'
reference to elaborate on this.

-- 
 2. That which causes joy or happiness.

Re: NMU for bayonne

[Mark Purcell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bas,

It is actually courtesy to file a bug/ contact the maintainer prior to 
uploading a NMU (even to DELAYED/3-day). Have a look at Bug #159174 which I 
received two hours after your NMU notification.

Mark

On Mon, 2 Sep 2002 01:36, you wrote:
> Hi!
>
> I just uploaded an NMU for bayonne to DELAYED/3-day.  It's a simple
> rebuild for perl 5.8.  The changes are:
>
>
> diff -Naur bayonne-0.9+1.0pre1.old/debian/changelog
> bayonne-0.9+1.0pre1/debian/changelog ---
> bayonne-0.9+1.0pre1.old/debian/changelog  2002-07-27 08:45:50.0
> + +++ bayonne-0.9+1.0pre1/debian/changelog2002-09-01
> 15:32:25.0 + @@ -1,3 +1,10 @@
> +bayonne (0.9+1.0pre1-1.2) unstable; urgency=low
> +
> +  * Non-maintainer upload (BSP)
> +  * Fixed build-depends for perl 5.8 and rebuilt against libperl 5.8
> +
> + -- Bas Zoetekouw <[EMAIL PROTECTED]>  Sun,  1 Sep 2002 15:31:47 +
> +
>  bayonne (0.9+1.0pre1-1) unstable; urgency=low
>
>* New upstream release
> diff -Naur bayonne-0.9+1.0pre1.old/debian/control
> bayonne-0.9+1.0pre1/debian/control ---
> bayonne-0.9+1.0pre1.old/debian/control2002-06-28 16:45:05.0 
> +
> +++ bayonne-0.9+1.0pre1/debian/control2002-09-01 15:31:45.0 
> +
> @@ -2,7 +2,7 @@
>  Section: comm
>  Priority: optional
>  Maintainer: Mark Purcell <[EMAIL PROTECTED]>
> -Build-Depends: debhelper (>> 3.0.0), libcommoncpp2-dev, libccaudio-dev (>=
> 0.9.0-3) , libccrtp-dev (>= 0.9.0-2) , libccscript-dev (>= 2.0.2-2),
> libperl-dev, zlib1g-dev, libxml2-dev, libperl5.6, tcl8.2-dev, libcapi20,
> libhoard, libfox0.99-dev, libopenh323-dev +Build-Depends: debhelper (>>
> 3.0.0), libcommoncpp2-dev, libccaudio-dev (>= 0.9.0-3) , libccrtp-dev (>=
> 0.9.0-2) , libccscript-dev (>= 2.0.2-2), libperl-dev (>= 5.8), zlib1g-dev,
> libxml2-dev, tcl8.2-dev, libcapi20, libhoard, libfox0.99-dev,
> libopenh323-dev Standards-Version: 3.5.2
>
>  Package: bayonne
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9dIsuoCzanz0IthIRArVXAJ9ey0zOTvbKCWFPIqRz8AULw9RiuwCggo5t
+WqDk/5EI9seCtl5tavjdv4=
=kyxf
-END PGP SIGNATURE-

Re: Kernel problem

[Herbert Xu]

Michael Meskes <[EMAIL PROTECTED]> wrote:
 
> makes it boot but later I get a lost interrupt on hda. Now I installed
> 2.4.19 and do get that message about bios checksum or so. But after that
> it stands still again. 

Which 2.4.19 kernel package did you install and what is the exact
error message?
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Stacked Debconf

[Henning Glawe]

Moin,
the manpage of debconf.conf says it uses the topmost writable database
in a stack for saving users choices. But debconf complains if the 
topmost database in a stack isn't writable. 

-- 
c u
henning

Is it me, pbuilder, dpkg or something else?

[shaulka]

script started on Tue Sep  3 12:00:00 2002
[EMAIL PROTECTED]:/tmp# pbuilder build --distribution woody --basetgz \
> /var/cache/pbuilder/woody/base.tgz \
> ~shaul/devel/debian/libv/libv1.25/libv1.25_1.25-3.dsc
W: /root/.pbuilderrc does not exist
pbuilder-buildpackage/i386 $Id: pbuilder-buildpackage,v 1.84 2002/05/13
 16:25:35 dancer Exp $

Current time: Tue Sep  3 12:00:24 IDT 2002
pbuilder-time-stamp: 1031043624
Building the build Environment
 -> extracting base.tgz
 -> mounting /proc filesystem
 -> mounting /dev/pts filesystem
 -> copying/creating local configuration
 -> Installing apt-lines
Copying source file
-> copying
  [/home/shaul/devel/debian/libv/libv1.25/libv1.25_1.25-3.dsc]
-> copying
  [/home/shaul/devel/debian/libv/libv1.25/libv1.25_1.25.orig.tar.gz]
-> copying
  [/home/shaul/devel/debian/libv/libv1.25/libv1.25_1.25-3.diff.gz]
Extracting source
unable to get login information for username "shaul" at
/usr/lib/dpkg/controllib.pl line 56.
Compilation failed in require at /usr/bin/dpkg-source line 22.
pbuilder: Failed extracting the source
 -> unmounting /proc filesystem
 -> unmounting /dev/pts filesystem
 -> cleaning the build env 
[EMAIL PROTECTED]:/tmp# exit
exit

Script done on Tue Sep  3 12:08:46 2002

[EMAIL PROTECTED]:/tmp$ tail /etc/pbuilderrc 
#default is to build everything. Passed on to dpkg-buildpackage
#DEBBUILDOPTS="-b"
DEBBUILDOPTS=""

#APT configuration files directory
APTCONFDIR=""

# the username and ID used by pbuilder, inside chroot. Needs fakeroot,
# really
BUILDUSERID=1234
#BUILDUSERNAME=pbuilder
[EMAIL PROTECTED]:/tmp$ 

[EMAIL PROTECTED]:/tmp$ getent passwd shaul
shaul:x:1000:1000:Shaul Karl,,,:/home/shaul:/bin/bash
[EMAIL PROTECTED]:/tmp$ 

-- 

Shaul Karl, [EMAIL PROTECTED] e t

Re: RFC: A regression test framework for Debian packages?

[David Schmitt]

On Mon, Sep 02, 2002 at 10:07:59AM -0700, Ian Zimmerman wrote:
> >> kronstadt:~# dpkg --status debian-test
> >> Package: debian-test
> 
> Wasn't this at least a start?  Shouldn't we build on it instead of
> starting from scratch?

Using this framework could ease many of the problems testing
packages/package upgrades 'offline' because it can test them in a
'production environment' on users machines.

This would act as a early-warning-system in sid _and_ as a method to
regularily check services and other stuff on stable production machines.




There is a version of debian-test fixing all outstanding bugreports at
http://www.edv-bus.at/~david/debian-test/




Regards, David

-- 
Afrika kommt nach Europa. Das ist der Kontinentaldrift. Da kann man auch
mit einem neuen Asylgesetz nichts dagegen machen. Das sollte mal wer
denen von der FPÖ erklären!
-- Dieter Nuhr (www.nuhr.de) in der Wiener Remise, 2002-08-02


pgp7Py2OCTxXc.pgp
Description: PGP signature

Re: install-info and LSB

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 11:57:03PM +0200, Josip Rodin wrote:
> 
> > The dpkg-iasearch package used to contain a program called dpkg-query.
> > When the dpkg maintainers added a program with the same name, the
> > dpkg-iasearch maintainer renamed his file, without worrying about
> > 'seniority'. I think he did well to do so, don't you?
> > 
> > Debian would do well to rename its install-info for the same reasons.
> 
> "dpkg-query" was obviously very much inside the dpkg namespace. On the other
> hand, dpkg's install-info is both not really in texinfo namespace because it
(...)

As for this issue, even if I did get into dpkg namespace many
other packages (such as dpkg-awk, dpkg-www, dpkg-ruby or devscripts) have
interfered in that namespace.
Without there being a policy on *who* or *how* program namespaces
should be handled I fixed the bug, but you understand I could have *not*
fixed it and reassigned it to 'dpkg'!
I wonder if new packages/packages updates could be automatically
checked for conflicts of this kind. It would have taken the dpkg
maintainers an 'apt-file search dpkg-search' to foresee the bug *before*
it happened (and contact me through other non-bug-report methods).

Regards

Javi

Re: Bug#159392: ITP: tetrinetx -- GNU Tetrinet server

[Helios de Creisquer]

On Tue, Sep 03, 2002 at 02:49:04AM +0200, Helios de Creisquer wrote:
> Package: wnpp
[...]
> * Package name: tetrinetx
[...]

I CC-ed [EMAIL PROTECTED], closing the RFP, I though it was
the right thing to do, but apparently I was misleading...

Thx to Daniel Burrows for reporting it, and sorry for this :)

[EMAIL PROTECTED] report:

> reopen 155493
Bug#155493: RFP: tetrinetx -- the GNU TetriNET server
Bug reopened, originator not changed.

> merge 155493 159392
Bug#155493: RFP: tetrinetx -- the GNU TetriNET server
Bug#159392: ITP: tetrinetx -- GNU Tetrinet server
Merged 155493 159392.

Cheers,
-- 
   Helios de Creisquer  <[EMAIL PROTECTED]>
http://www.tuxfamily.org/<[EMAIL PROTECTED]>
http://www.vhffs.org/  +33 (0)6 70 71 20 29  <[EMAIL PROTECTED]>
http://www.gnu.org/<[EMAIL PROTECTED]>
GPG(1024D/96EB1C44): FB11 8B80 4D86 D9C2 DE0C 11D7 2FA8 A5CC 96EB 1C44


pgpLqXigJVNZc.pgp
Description: PGP signature

Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish)

[Javier Fernández-Sanguino Peña]

On Tue, Sep 03, 2002 at 10:43:25AM +1200, Philip Charles wrote:
> > |
> > | Excerpt from the changelog:
> > |   * we no longer have task packages, instead, we define tasks using a
> > | special field in the control file (and these should be added only
> > | after discussion on the mailing lists) closes: 
> > Bug#97755
> >
> > uhm, they should _not_ be added to the control file.  They should be
> > added by the override files plucked from base-config's CVS.  Skim the
> > archives on -boot for information.
> >   `. `'
> The info for the Tasks is in debian/indices/override.woody.extra.main.gz
> if you want to have a look.  debian-cd then adds this info to the Packages
> file.

Then the policy document is wrong? Shouldn't it be bugged?

Javi

Re: bugs.debian.org: ChangeLog closes handling should be changed

[Gerfried Fuchs]

* Brian May <[EMAIL PROTECTED]> [2002-08-29 09:50]:
> On Tue, Aug 27, 2002 at 08:48:31AM +0200, Gerfried Fuchs wrote:
>>  What we need is a change here: Bugs should just be closed in unstable.
>> How to do this?  They should be rather be tagged  than be closed
>> by an upload to unstable.  Not unconditionally, of course.  The version
   ^^^
>> of the bugreport should be compared with the version currently in
  ^^
>> testing.  Some sort of algorithm not too complex but able to handle most
   
>> of the cases shouldn't be too hard to do (yes, I volunteer to help
>> there).
> 
> Then bugs will me marked as sarge, even though they might be bugs
> specific to unstable.

 Just to make sure you didn't miss that I thought of that problem
already, thanks.  Or do you think of that the bugs are there because of
other packages in unstable?  Well, then the bug might be filed against
the wrong package.  Which would leave us with a problem -- the version
is rather meta information in the bugreport and not real useful data, is
it?  So currently there is no need to change the version field if a bug
gets reassigned to a different package... *hmmm*  Difficult issue, but
still no issue that shouldn't be raised/thought about.

> It would be much better to remove the sid tag when it gets uploaded
> to unstable, turn off the sarge tag when it goes into testing, and
> turn of the woody tag if it is lucky enough to get into stable.

 ... and if the final tag gets removed it should be closed.  Another
approach which seems to work quite well and might even live happily with
the current situation: Bugs with no tags simply get closed for they are
not tagged for a specific distribution.  Sounds good to me.

> (of course this assumes that the tags were already set, preferably when
> the bug is first reported)

 Of course.  And of course the whole BTS depends on reasonable users,
not on spam bots closing bugs just out of curiosity ;)   So I don't
think that's a real problem.  Maintainer that care for a good history of
the bugreports against their package should do that anyway.  Others who
simply don't care shouldn't be bothered if we take the second approach
because they won't usually tag their bugreports anway.

> PS. Please look at http://www.debian.org/Bugs/Reporting, and search
> for "X-Debbugs-CC".

 P.S.: Please look at the BTS archives for this mail, I did set
X-Debbugs-CC, just with the wrong value.  Mea culpa.

 So long!
Alfie
-- 
 I have  a little problem with a bug-report I received... *scratch*
 Alfie: I send those to /dev/null
  -- #debian-devel


pgpTQiEagD5Ux.pgp
Description: PGP signature

lilo-22.3.2-3 trashed my SCSI disk

[Svante Signell]

Hello,

After upgrade of lilo in unstable my whole SCSI disk got trashed. It
could only be recovered with the use of the IBM drive fitness test
tool, and a complete erase disk was necessary :-( What happened?

A reinstall of Woody showed that it can only boot from the MBR
partition, not the root partition, i.e.

boot=/dev/sda, works!
boot=/dev/sda1, does not work!

What has changed for newer versions of lilo?  I have been running
Debian stable/testing/unstable for several years now without any
problems before. 

Note also that I have a dual disk system, SCSI and IDE, therefore the
disk=, bios= statements in lilo.conf. The disk partitioning tools, such as
cfdisk requires both the SCSI disk and the IDE disk to have at least
one partition with the boot flag set. Is this really necessary?

Does the install=menu stuff have anything to do with the crash?

Maybe grub is better with respect to error recovery?

Still a Debian fan,
Svante

==
Partial session follows:

Setting up lilo (22.3.2-3) ...
Old /boot/boot.b symlink discovered, put the line "install=menu" in
/etc/lilo.conf instead.
Removing sym link
Press ENTER to continue

Running /usr/sbin/liloconfig

LILO, the LInux LOader, sets up your system to boot Linux directly
from your hard disk, without the need for a boot floppy.

You already have a LILO configuration in the file /etc/lilo.conf

Checking your /etc/lilo.conf for incompatible options...

Install a boot block using your current LILO configuration? [Yes] 

   ==
WARNING: Even if lilo runs successfully, see /usr/share/doc/lilo/INCOMPAT.gz
 for changes in the usage of the /etc/lilo.conf file.
 If needed: edit /etc/lilo.conf and rerun '/sbin/lilo -v'

Running lilo...
LILO version 22.3.2, Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2002 John Coffman
Released 11-Jul-2002 and compiled at 11:04:56 on Aug 31 2002.

Reading boot sector from /dev/sda1
Using MENU secondary loader
Calling map_insert_data

Boot image: /boot/vmlinuz-2.4.17
Added 2417smp1 *
...
/boot/boot.0801 exists - no backup copy made.
Writing boot sector.
===

Editing /etc/lilo.conf:
boot=/dev/sda1
root=/dev/sda1
lba32
#compact

#My changes below...
install=menu
#install=/boot/boot.b

delay=20
map=/boot/map
read-only
disk=/dev/sda
  bios = 0x80
disk=/dev/hda
  bios = 0x81
prompt
default=2417smp1
timeout=50
#image=/vmlinuz
image=/boot/vmlinuz-2.4.17
  label=2417smp1
  read-only
=

lilo -v:
LILO version 22.3.2, Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2002 John Coffman
Released 11-Jul-2002 and compiled at 11:04:56 on Aug 31 2002.

Reading boot sector from /dev/sda1
Using MENU secondary loader
Calling map_insert_data

Boot image: /boot/vmlinuz-2.4.17
Added 2417smp1 *

/boot/boot.0801 exists - no backup copy made.
Writing boot sector.

=
reboot:
...

Kernel problem

[Michael Meskes]

Hi,

I've been using self compiled kernels throughout the years and up to
2.4.18 never experienced a problem. But Now I tried switching to the
debian kernel and cannot do that at all. When using 2.4.18 the first try
ends before "Uncompressing ..." is written on the screen. A reset then
makes it boot but later I get a lost interrupt on hda. Now I installed
2.4.19 and do get that message about bios checksum or so. But after that
it stands still again. 

I do attach my own config file.

Any idea why this happens? I can live with a self compiled kernel. After
all it's my private machine, but I'd like to know what's going on and of
course I'd like to move away from anything I have to do manually. :-)

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_APIC=y
# CONFIG_X86_UP_IOAPIC is not set
CONFIG_X86_LOCAL_APIC=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
# CONFIG_HOTPLUG_PCI is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_PM is not set
# CONFIG_ACPI is not set
# CONFIG_APM is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
CONFIG_PARPORT_OTHER=y
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=m

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
# CONFIG_SYN_COOKIES is not set

#
#   IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
CONFIG_IP_NF_COMPAT_IPCHAINS=y
CONFIG_IP_NF_NAT_NEEDED=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set

#
#  
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is n

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Chris Halls]

On Sat, Aug 31, 2002 at 01:38:52PM +0200, Peter Palfrader wrote:
> Still, the Packages files should only be removed after no software in
> our stable distribution depends on it. If you remove the Packages file
> from unstable now you will break apt-proxy (and perhaps other tools
> too).

Well, apt-proxy won't actually break - it will just be less efficient when
configured to fetch control files using rsync because it will have to use
the .gz file and fetch the whole thing.  http and ftp backends will be
unchanged because apt-proxy is already fetching Packages.gz.

Chris
(apt-proxy maintainer)


pgpKnsy4V3TLo.pgp
Description: PGP signature

Re: The harden-*flaws packages.

[Ola Lundqvist]

On Mon, Sep 02, 2002 at 06:28:44PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Sep 02, 2002 at 05:13:51PM +0200, Ola Lundqvist wrote:
> > 
> > Now we just have to solve the upload-to-security problem, or simply
> > write some other check that scans the security.d.o web pages and
> > make clever things of it. Maybe using tiger, maybe some other things. But
> > because tiger can do similar things that might be useful.
> > 
> It's in my todo list. Now DSAs are much more easy to parse. Some older DSAs
Nice (that it is on your todo list).

> (pre-1999) might need special parsing however. Also, DSAs could be improved 
> to add

The really old ones is probably not valid because this kind of check will
be added to a release where such packages simply can not be hold back.

> an 'affected versions' tag (currently only the package name is provider, you 
> can
> infer the affected versions by looking the versions which *fix* the 
> vulnerability).

Most the time it is not that easy to know each and every version that is
affected so infering is probably the way to go. Do you want help with this
and do you have anything for a starter?

Regards,

// Ola

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

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---