Re: Some thoughts about problems within Debian

[Anthony Towns]

On Sun, Jan 06, 2002 at 05:55:38PM +0100, Michael Meskes wrote:
> I certainly didn't want to diminish the work you're doing, but I still think
> we have to find better ways to release. potato is too old right now and most
> people I do talk to, tell me they don't care about all these packages, but
> they want newer versions of the packages they use. 

Two responses: first, if they don't want new packages, just newer versions
of the stuff they "use", that'd presumably exclude things like, oh,
say, KDE... So you've got to be a little careful there. Second, most of
the problems are with the newer versions of old packages:

apache: 126707, 126743
apt: 127648, 127942
base-passwd: 123345
exim: 126124
gnuplot: 126014
gpm: 113454
gs-common: 126475
icewm: 123448
imagemagick: 123133
iproute: 118424, 119601, 123224
ld.so: 97071, 102055
libc6: 126441
mc: 123161
mozilla: 128046
pcmcia-cs: 119837
postgresql: 118362, 121088
qmail: 72310
reportbug: 127507
samba: 127444
slapd: 112499, 126898
ssh: 127575
sysutils: 120025
sysvinit: 127635
tetex-bin: 69600
tripwire: 90912, 92510, 94603

...are a sample of pakcages that seem reasonably "standard" to me that
are in the RC bug list. You'll note some of those bug numbers are around
a year old. 

> Yes, I know that if we
> take all those people we probably have 99% of the packages belonging into
> someone's core, but the age is a factor.

No, I don't dispute that looking at core packages is worthwhile: it is;
all I'm saying is that once we actually get to the point where those core
packages are releasable, the rest of the work (getting rid of unreleasable
extra packages) isn't much of a problem. And converesely: if we don't
get all the base/standard bugs fixed, there's nothing anyone can do
to make us release any quciker, unless we're willing to just release a
bunch of junk with known security problems that doesn't upgrade cleanly
and whatever else.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://linux.conf.au/

atlas on HPPA (PA RISC)

[Camm Maguire]

Greetings!  Anyone out there using these machines wanting an atlas
port?  I've run into some very odd compiler problems, and am in need
of an expert to go any further.  Basically, single precision floating
point fails accross the board, double passes all tests.  The compiler
dies with an error if the code tries to tune for too large a cache.
Cross compilation with -march=1.0 fails.

Please cc, as I'm not subscribed to this list.

Take care,

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: CHECK BEFORE YOU RETITLE Re: Processed: Retitling...

[Colin Watson]

On Sun, Jan 06, 2002 at 12:54:26PM -0600, Adam Majer wrote:
> He did change some ITA to O - I have no idea why... IMHO, the 
> difference b/w
> 
>  ITA: gtml
> 
> and
> 
>  ITA: gtml -- An HTML pre-processor
> 
> is trivial.. There should be no reason to do that especially 
> that the package is ITA: for a few days...

Generally speaking, when you're going through the enormous wnpp bug list
and trying to help out by tidying it up, life's too short to work out
the length of time for which a package has been ITAed (it's not
immediately visible).

-- 
Colin Watson  [EMAIL PROTECTED]

RE: Bug#128077: Please mention native source packages in maint-gu ide

[Yves Arrouye]

> A Debian native source package is one which has no .diff.gz, because the
> Debian source code and the upstream source code are the same thing.  This
> means that the source tarball contains a debian/ directory with the
> necessary packaging infrastructure.  This configuration is used for
> packages
> such as dpkg and apt which are developed specifically for Debian.

Thanks for the explanation. Well, ICU is definitely not developed
specifically for Debian, but since I am one of the upstream developers, I
found it convenient to have the debian/ directory in it, not just for me but
for anybody who would want to grab ICU from the CVS and build a .deb for it.


So I guess that as long as the explanation in maint-guide says that a native
Debian package is a package that builds with no modifications, not just a
package developed specifically for Debian, it will be clear for everybody.

YA

postfix/postfix-tls vs. smtpd bug

[martin f krafft]

hi folks,
should i file this bug against both packages, or which one should get
precedence? i feel like postfix will be losing out...

dpkg: error processing /var/cache/apt/archives/smtpd_2.0-4_i386.deb
 trying to overwrite `/usr/share/man/man8/smtpd.8.gz', which is also in
 package postfix-tls

comments?
 
-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
yesterday it worked.
today it is not working.
windoze is like that.


pgpR3POEtYbb1.pgp
Description: PGP signature

Bug#128077: Please mention native source packages in maint-guide

[Matt Zimmerman]

Package: maint-guide
Severity: wishlist

On Sun, Jan 06, 2002 at 02:45:17PM -0800, Yves Arrouye wrote:

> 
> > > if test -d build -a build != source; then rm -f -r build; fi
> > >  dpkg-source -b icu
> > > dpkg-source: warning: source directory `./icu' is not
> > > - `icu-2.0'
> > > dpkg-source: building icu in icu_2.0-1.tar.gz
> > > dpkg-source: building icu in icu_2.0-1.dsc
> > 
> > Why is icu a Debian native package?
> 
> What do you mean by "Debian native"?

A Debian native source package is one which has no .diff.gz, because the
Debian source code and the upstream source code are the same thing.  This
means that the source tarball contains a debian/ directory with the
necessary packaging infrastructure.  This configuration is used for packages
such as dpkg and apt which are developed specifically for Debian.

-- 
 - mdz

Re: Debian.rpm

[Wichert Akkerman]

Previously David B Harris wrote:
> Well, I'm kind of thinking he meant an automated procedure.

So did I. Someone made a rpm package that you could install with
rpm and it would convert a RedHat system into a Debian system. It
only handled the base system and left the rest unchanged, but it
did work.

I suspect you might still find that package with a bit of google
searching.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

hi

[Mr Shadow]

Dear Sir ,
i find your email in someplace ,about tranfering money (fraud money )into 
any overseas account.

i am lebanese and i work with money currency ,and i have many accounts in 
lebanon,if u want to transfer any amout of money (any types of money :fraud 
,money laundering ..) ,and of course i will have my 20% of Commission + 5% 
of the transcation.

if u are interest we can meet or we can talk,also if u have some friends who 
wants to trasfer money ,i am ready.

take care, and keep it secret please and do not give my email to anyone 
,please.

thank you
The man in the shadow .
_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

changed maintainer of ptex-jisfonts

[Atsuhito Kohda]

Hi all,

I don't know where is an appropriate mailing list to announce
this kind of fact but I guess it might be better to announce
somewhere than not to announce at all;

the maintainer of ptex-jisfonts was changed from me to 
OHURA Makoto <[EMAIL PROTECTED]> who has contributed so many 
times to ptex-jisfonts with bug reports.

But he is not Debian developer yet so I sponsor him until he
becomes a developer.

Best regards,   2002.1.7

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Univ. of Tokushima

Re: Debian.rpm

[David B Harris]

On Sat, 5 Jan 2002 01:03:37 +0100
Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> > Well, what you're suggesting isn't really feasible ;)
> 
> Someone actually did this a couple of years ago so it is feasible.

Well, I'm kind of thinking he meant an automated procedure.

To do a "real" upgrade, lots of things need to be done, like figuring
out what's installed, figuring out what *to* install, so on and so
forth.

Considering we have no way to be relatively sure what a package on a Red
Hat system really *is*(since .rpms are downloaded from everywhere, and
rarely have a coherent naming scheme[though luckily our namespace isn't
too crowded yet, so most things are allright])... Anyways, I'm just
being anal :)

I have actually "upgraded" a RH box to a Debian box, while it was
running, but I'd still call it nontrivial, and rather extraordinarily
difficult to automate.

--
 .--=-=-=-=--=---=-=-=.
/David Barclay HarrisAut agere, aut mori.  \
\Clan Barclay  Either action, or death./
 `---==-=-=-=-===-=---=--='


pgpPTsGtFjnbL.pgp
Description: PGP signature

take over preview-latex

[Atsuhito Kohda]

Hi all,

About two months ago, Davide G. M. Salvetti" <[EMAIL PROTECTED]>
anounced ITP of preview-latex (cf. #117060) but after
some communication with him, he kindly permitted me 
to take over preview-latex so I will upload preview-latex
in a few days.

An ITP was already done by him so it might not need to do it
again, but for safety;

It was downloaded from 

Upstream Author: David Kastrup <[EMAIL PROTECTED]>

Copyright:

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

Description: Embed LaTeX environments into the source buffers
 Purpose of the package is to embed LaTeX environments such as display
 math or figures into the source buffers. 
 .
 By mouse-clicking, you can open the original text.  After editing,
 another click will just run the region in question through LaTeX and
 redisplay the new results.

Best regards,   2002.1.7

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Univ. of Tokushima

Re: stat vs stat64 - ugly problem

[Adam Olsen]

On Mon, Jan 07, 2002 at 01:20:45AM +0100, Wichert Akkerman wrote:
> Previously David N. Welton wrote:
> > Right, so how do we fix this?  It is our problem, in that we need to
> > make the software we distribute work together.  But are you also
> > saying that upstream shouldn't be setting that bit in their header
> > file?
> 
> As long as the API (and ABI) never exports things like struct stat and
> offset_t (ie things that are affected by enabling LFS) it should not
> matter if you link things that are compiled with LFS with things that
> are not.
> 
> However that define should never be in a header file, especially
> not one that other applications can use. Doing that should warrant
> a hefty bugreport.

And if they do require the LFS for their interface, then I'd go with:

#ifndef _FILE_OFFSET_BITS
#error _FILE_OFFSET_BITS must be defined for foo
#endif

Which leaves the app to explicitely enabling it, either at the top of
the .c files, or with CFLAGS.

-- 
Adam Olsen, aka Rhamphoryncus

Re: stat vs stat64 - ugly problem

[Wichert Akkerman]

Previously David N. Welton wrote:
> Right, so how do we fix this?  It is our problem, in that we need to
> make the software we distribute work together.  But are you also
> saying that upstream shouldn't be setting that bit in their header
> file?

As long as the API (and ABI) never exports things like struct stat and
offset_t (ie things that are affected by enabling LFS) it should not
matter if you link things that are compiled with LFS with things that
are not.

However that define should never be in a header file, especially
not one that other applications can use. Doing that should warrant
a hefty bugreport.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: stat vs stat64 - ugly problem

[David N. Welton]

Wichert Akkerman <[EMAIL PROTECTED]> writes:

> > The Problem here is, that some header files define the LFS. This
> > should not be done.

> Indeed, doing that is broken behaviour.

Grepping about on my system, I see that mysql does it too, in
my_config.h:

#define _FILE_OFFSET_BITS 64

> > One good Idea would be to include the define in stat.h :)

> No way, that would break lots of things.

Right, so how do we fix this?  It is our problem, in that we need to
make the software we distribute work together.  But are you also
saying that upstream shouldn't be setting that bit in their header
file?

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/

Re: stat vs stat64 - ugly problem

[Wichert Akkerman]

Previously Bernd Eckenfels wrote:
> Yes, Wickert should reread your initial message.

Pleas spell my name correctly.

> The Problem here is, that some header files define the LFS. This
> should not be done.

Indeed, doing that is broken behaviour.

> One good Idea would be to include the define in stat.h :)

No way, that would break lots of things.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: stat vs stat64 - ugly problem

[Philip Blundell]

In message <[EMAIL PROTECTED]>, Wichert Akkerman writes:
>Bogus, if you compile them with the same options then will the the
>same. If you compile one with LFS and one without you can expect
>problems as you have demonstrated. 

Well, yeah, but it seems dubious at best for Apache to be defining
_FILE_OFFSET_BITS in some random header file.  Unless you enforce some
rule that this always has to be the first header included, there is always
going to be the potential for it to cause mysterious lossage.  I think
it would be better all round to put that stuff in CFLAGS instead.

p.

Re: gnumeric and guppi in sid

[Jack Howarth]

   Well, this is on ppc sid. I'll try to find someone else
on ppc sid to check this. Oh I did file a bug report because
guppi hasn't been working for me for quite some time. This
is just the first time it actually showed a support program
was segfaulting.
 Jack

Re: Theory

[Martijn van Oosterhout]

On Sat, Jan 05, 2002 at 07:11:17PM +0100, Robert J?rdens wrote:
> - What do statistics about the CD/FTP ratio say? Are CDs still so
>   important, that we need definite and long-lasting identical
>   images/distros? True: floating release is nothing for CDs. Having 5
>   different versions of a package on each set of CDs is not very
>   productive. [But then again: We might become the first distro that
>   only fits on 5 DVDs. That would make us the "largest distro in size"
>   for ever. ;-]

Statistics? What statistics? CD may not be important in the US where you can
download forever for free but in countries where download costs real $$
(20c/MB) CD's are an extremely important method of distribution.

> - Anonymised () registration of every installed package on systems
>   wich install from the net should not be to difficult (Yes, on a
>   voluntary base; registering its usage is more difficult - and I don't
>   want it for my systems; or simply take it from download statistics).
>   Then we have something like a machine_installation_days variable for
>   the packages. This alone would have huge implications but would give
>   us a rough figure about usage.

Have you looked at the popularity-contest? It gives some idea of what
packages people have installed and which they are actually using.
-- 
Martijn van Oosterhout 
http://svana.org/kleptog/
> Terrorists can only take my life. Only my government can take my freedom.

RE: .dsc not generated during package build?

[Yves Arrouye]

> > Since it was trying to tar up 'icu' (which is a symlink) for whatever
> > reason, it may be that dpkg-source tried to create a tarfile containing
> only
> > that.  dpkg-source just does a "tar cf -", so symlinks would not be
> > followed.  I could see how that might have caused some confusion.
> > I agree that an error should have been reported somewhere during this
> > process if a .dsc was not created, so if you can track down where the
> > problem is, there may be a bug report in it.
> 
> Nope, this is not the case.  I generally have a  symlink pointing to
> -, and it has always worked fine for me.

I tried that and it works.

But have you tried having a  symlink pointing to
/-? That's what I have (icu -> 2.0/icu-2.0) and it
definitely confuses the build. I tried changing:

curd="`pwd`"

to

curd="`/bin/pwd`"

in dpkg-buildpackage but then I get:

if test -d build -a build != source; then rm -f -r build; fi
 dpkg-source -b icu-2.0
dpkg-source: error: cannot stat directory ./icu-2.0: No such file or
directory

Hmmm.
YA

Re: Some thoughts about problems within Debian

[Paul Seelig]

[EMAIL PROTECTED] (Adam Heath) writes:

> On Thu, 3 Jan 2002, Adrian Bunk wrote:
> 
> > One important thing are more frequent releases. We don't have to release
> > as often as other distributions but IMHO it's needed to have a new stable
> > release at about once a year.
[ ...]
> Sure, everyone agrees.  This has been hashed over and over and over.  Talking
> about it doesn't help.  Solve the problem.
> 
But is it solvable at all?  

Hasn't Debian become far too big?  Hasn't Debian's size since long
left the manageability of becoming one of a kind with all those other
distributions out there?  Isn't Debian far too different in it's
functional approach of trying to be just a distribution?

Actually i now firmly believe that Debian's foremost distribution
media has become the net itself and that we should better think about
how to deal with it's constant change process instead of thinking in
terms of a "release".  I think, "testing" has been the right approach
so far.  But maybe i'm hallucinating... ;-)

 Thanks, P. *8^)
-- 
  Paul Seelig <[EMAIL PROTECTED]> --
   African Music Archive - Institute for Ethnology and Africa Studies
   Johannes Gutenberg-University   -  Forum 6  -  55099 Mainz/Germany
 - http://ntama.uni-mainz.de --

Re: CHECK BEFORE YOU RETITLE Re: Processed: Retitling...

[Josip Rodin]

On Sun, Jan 06, 2002 at 12:54:26PM -0600, Adam Majer wrote:
> IMHO, retitling to ITA: without explanation is seen as an attemp 
> to adopt a package..

Retitling ITA to ITA+description should be pretty clear without explanation.

-- 
 2. That which causes joy or happiness.

Re: .dsc not generated during package build?

[Matt Zimmerman]

On Sun, Jan 06, 2002 at 04:49:05PM -0600, Adam Heath wrote:

> On Sun, 6 Jan 2002, Matt Zimmerman wrote:
> 
> > Since it was trying to tar up 'icu' (which is a symlink) for whatever
> > reason, it may be that dpkg-source tried to create a tarfile containing only
> > that.  dpkg-source just does a "tar cf -", so symlinks would not be
> > followed.  I could see how that might have caused some confusion.
> > I agree that an error should have been reported somewhere during this
> > process if a .dsc was not created, so if you can track down where the
> > problem is, there may be a bug report in it.
> 
> Nope, this is not the case.  I generally have a  symlink pointing to
> -, and it has always worked fine for me.

Right, but in your case, dpkg-source is probably being called with the right
name.  What happens if you run dpkg-source -b  (pointing to the
symlink)?  When I try it, I get a broken Debian native source package with
a .tar.gz containing only the symlink:

lrwxrwxrwx mdz/mdz   0 2002-01-06 18:11:28 foo -> vmnet-0.4

I suspect this is what happened to the original poster, whose transcript
showed that, for whatever reason (human or software), dpkg-source -b was run
with the name of the symlink as its argument.

-- 
 - mdz

Re: stat vs stat64 - ugly problem

[Bernd Eckenfels]

On Sun, Jan 06, 2002 at 11:10:13PM +0100, David N. Welton wrote:
> In any case, changing the order of two header files doesn't seem
> offhand like the sort of thing that would go about changing the system
> definitions.  That's poor modularity, in my opinion, because neither
> Apache nor Python, Tcl or anything else but libc6 owns the stuff in
> include/sys/.

Yes, Wickert should reread your initial message. The Problem here is, that
some header files define the LFS. This should not be done. It is not so much
an Issue now that we try to recompile all sources with LFS anyway, but it is
still ugly.

One good Idea would be to include the define in stat.h :)

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: EURO and CENT signs in the console keymaps

[Bernd Eckenfels]

On Sat, Jan 05, 2002 at 01:55:10PM +0100, Josip Rodin wrote:
> Actually, I don't think I've ever seen "AltGr" printed on a key, yet all the
> keyboards in .hr have the right alt doing that.

The Gr stands afaik for "Alternative Graphics". It is found mainly in
Europe if the keyboards does not follow the US Layout closely. Cause the
[]/# Keys are reused for national chars like umlauts.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: packaging spambouncer - cronjob updates in /usr???

[martin f krafft]

also sprach Carlos Laviola <[EMAIL PROTECTED]> [2002.01.06.2034 +0100]:
> > if i package spambouncer so that a configurable cronjob obtains updates
> > on the anti-spam rules and databases from the spambouncer website, then
> > the files can't remain in /usr, right?
> 
> Are you sure you want to do this?  What about all those people who
> filter with spambouncer, but are dial-up users?  You need to either
> have your job run when a PPP link is up, or ask the user if he's on a
> LAN/has direct access to the Internet before doing this.

of course, sorry i excluded that. it'll be a setup similar to snort.

actually, what speaks against:

(1) ask user if cronjob should be installed.
y --> ask for frequency
  install cronjob
(2) in addition, add some smart update script to ip-up.d. with smart i
mean that it would only fetch once a week...

the standard dialup user won't be affected by the cronjob (that fails),
if it doesn't flood them with emails. the only people who should worry
about this are the ones that have pppd set to autodial, or the ones who
use diald or the like. they'll be specifically addressed by debconf and
can disable cronjob...

> > the primary candidate for installation of spambouncer is
> > /usr/share/spambouncer, but /usr/lib/spambouncer might be better. in any
> > case, since /usr should be ro-mountable, these files should really be
> > sitting in /var/lib, right? that would mean that the entire "program"
> > sits in /var. is this acceptable?
> 
> It isn't really a program, just a collection of filters, which are
> non-binary (thus, you'll only need to have a package which is
> Architecture: all).  I'd say that if you rely on a method to update
> your spambouncer definitions that ensures you that /usr is mounted,
> you'd have no problem putting it on /usr/share/spambouncer/ like
> procmail-lib does.

my problem with that is twofold: (a) /usr should be ro-mountable no
matter what, so /usr/share is not an option i feel. the second problem i
have is similar: tripwire, aide and co. - you'd have to explcitly
reconfigure tripwire if you allow periodic changes in /usr.

mh. it looks like there's no way around /var/lib since /usr/local is far
out of bounds.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
there's someone in my head but it's not me.
-- pink floyd, the dark side of the moon, 1972


pgp8A3nVAW1LC.pgp
Description: PGP signature

Re: gnumeric and guppi in sid

[Erich Schubert]

> I am just wondering if guppi has every worked properly in sid.

well, it does right now.
at least for me and on this machine running sid.
i think it was the first time i tried, though ;)
i usually don't need a spreadsheet, and i usually prefer gnuplot...

Greetings,
Erich

P.S. No, Branden, plase ;) Jack isn't an agent of evil again just because
it doesn't work for him, and he doesn't use the bugtracking, nor
debian-user but debian-devel.

Re: packaging spambouncer - cronjob updates in /usr???

[martin f krafft]

also sprach Adam Majer <[EMAIL PROTECTED]> [2002.01.06.2013 +0100]:
> The changing things go in /var/lib/spambouncer or something... If
> there are executables, these should go into /usr/bin or /usr/sbin or
> something.

the entire package consists of procmail recipes, which are changing.
there are no binaries. thus, everything goes into /var/lib/spambouncer.
having the core of the package (save man pages etc.) be in /var is what
made me feel uneasy.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
si vis pacem, para bellum


pgpqzgaPn8Ul8.pgp
Description: PGP signature

Re: .dsc not generated during package build?

[Adam Heath]

On Sun, 6 Jan 2002, Matt Zimmerman wrote:

> Since it was trying to tar up 'icu' (which is a symlink) for whatever
> reason, it may be that dpkg-source tried to create a tarfile containing only
> that.  dpkg-source just does a "tar cf -", so symlinks would not be
> followed.  I could see how that might have caused some confusion.
> I agree that an error should have been reported somewhere during this
> process if a .dsc was not created, so if you can track down where the
> problem is, there may be a bug report in it.

Nope, this is not the case.  I generally have a  symlink pointing to
-, and it has always worked fine for me.

Re: new selftest target in debian/rules, new package state for autobuilder (suspect), debs that selftest on build

[Bernd Eckenfels]

On Sun, Jan 06, 2002 at 01:04:54PM -0500, Maitland Bottoms wrote:
> To that end the VTK package includes regression tests in the build
> process, and a reporting package to accumulate the results.

Just an small experience, beeing the maintainer of libadns from Ian, which
includes some regression tests I had the problem, that libadns itself was
easyly portable, the Regression tests, expecially since they deal with
numerical errno and heap sizes (for memleaks) where not so easy. I had to
make a few adjustments.

On the other hand, I would have loved to export the regression tests, to not
stop the builds on them.

Ah yes, if you look for regression tests, you can also see Ian's framework
in Source: adns.

But... umm.. well.. it does not look very multifunctional and reuseable to
me :)

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

RE: .dsc not generated during package build?

[Yves Arrouye]

> > if test -d build -a build != source; then rm -f -r build; fi
> >  dpkg-source -b icu
> > dpkg-source: warning: source directory `./icu' is not
> > - `icu-2.0'
> > dpkg-source: building icu in icu_2.0-1.tar.gz
> > dpkg-source: building icu in icu_2.0-1.dsc
> 
> Why is icu a Debian native package?

What do you mean by "Debian native"?

> Interesting; it looks like dpkg-buildpackage passed 'icu' to dpkg-source
> as
> the directory name, and dpkg-buildpackage gets the directory name directly
> from running pwd, at least in the current version.  What happens when you
> run /bin/pwd in that directory?  It should definitely show .../icu-2.0,
> not
> .../icu.

Yes. /bin/pwd gives icu-2.0, whilst the zsh pwd gives icu, as expected.

Oh well. I'll see if I can track this down. For now I am happy I can do my
packaging :)

YA

Re: [Evms-devel] EVMS: shared libraries with unversioned sonames

[Matt Zimmerman]

On Sun, Jan 06, 2002 at 10:07:48PM +0100, Tollef Fog Heen wrote:

>   ldconfig  creates the necessary links and cache (for use by the run-
>   time linker, ld.so) to the most recent shared libraries found in the
>   directories   specified   on   the   command   line,   in  the  file
>   /etc/ld.so.conf, and in the trusted directories (/usr/lib and /lib).
> 
> This seems like the tool I want to use.  The man page does not mention
> that it is a Linux-only tool and should not be used it one wants
> cross-platform portability.  Until somebody writes a cross-platform
> utility to do what I want to do, ldconfig _is_ the right tool for the job.
> What does the Hurd use instead of ldconfig?  I presume that they too have
> to create the necessary symlinks somehow?

That would be a question for debian-hurd.  As far as I know, the hurd
doesn't have an ldconfig program, or didn't.

-- 
 - mdz

Re: .dsc not generated during package build?

[Matt Zimmerman]

On Sun, Jan 06, 2002 at 02:04:53PM -0800, Yves Arrouye wrote:

> > > Whilst building my package, I get (from dpkg-dev 1.9.18, debhelper
> > 3.0.51):
> > 
> > What command did you run to do this?  What you probably meant was
> > dpkg-buildpackage.
> 
> I did use dpkg-buildpackage -rfakeroot
> 
> Here's more of the log:
> 
> if test -d build -a build != source; then rm -f -r build; fi
>  dpkg-source -b icu
> dpkg-source: warning: source directory `./icu' is not
> - `icu-2.0'
> dpkg-source: building icu in icu_2.0-1.tar.gz
> dpkg-source: building icu in icu_2.0-1.dsc

Why is icu a Debian native package?

>  debian/rules build
> 
> but the icu_2.0-1.dsc is not created at all.
> 
> If I go to a properly named directory (my mistake; I have a properly named
> icu-2.0 and a symlink icu -> 2.0/icu-2.0 to get there, and usually work from
> the symlink; somehow the scripts see the name icu, not icu-2.0 after I cd'ed
> there w/ zsh) then it works:

Interesting; it looks like dpkg-buildpackage passed 'icu' to dpkg-source as
the directory name, and dpkg-buildpackage gets the directory name directly
from running pwd, at least in the current version.  What happens when you
run /bin/pwd in that directory?  It should definitely show .../icu-2.0, not
.../icu.

> if test -d build -a build != source; then rm -f -r build; fi
>  dpkg-source -b icu-2.0
> dpkg-source: building icu in icu_2.0-1.tar.gz
> 
> So why is dpkg-source just issuing a warning instead of failing if it really
> cannot do anything? Is it looking at $CWD instead of finding out the real
> location (zsh messes up w/ $CWD).

Since it was trying to tar up 'icu' (which is a symlink) for whatever
reason, it may be that dpkg-source tried to create a tarfile containing only
that.  dpkg-source just does a "tar cf -", so symlinks would not be
followed.  I could see how that might have caused some confusion.
I agree that an error should have been reported somewhere during this
process if a .dsc was not created, so if you can track down where the
problem is, there may be a bug report in it.

-- 
 - mdz

Re: Installed postgresql 7.1.3-6 (i386 all source)

[Oliver Elphick]

On Sun, 2002-01-06 at 16:59, Roland Mas wrote:
> Oliver Elphick (2002-01-05 20:53:08 +0100) :
> 
> > Closes: 12166 121666 121699 121712 121944 122167 122871 123349 123950 
> > 124317 125772 126193 126440 127004 127275
> > Changes: 
> >  postgresql (7.1.3-6) unstable; urgency=low
> >  .
> >* postgresql: fix postgresql-dump so that it doesn't crash out
> >  unnecessarily if an unneeded file is missing. (Thanks to Thien-Thi
> >  Nguyen <[EMAIL PROTECTED]>.)
> >* Build dependencies: changed python-dev to python2.1-dev; added 
> > zlibg1-dev.
> >  Closes: #12166, #126193
> ^
> I'm not quite sure this is what you meant there.  Bug #12166 is
> related to fdutils, not postgresql.

Lost a 6 - it's 121666
-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C

 "Thou shalt not avenge, nor bear any grudge against the
  children of thy people, but thou shalt love thy  
  neighbour as thyself. I am the LORD." 
 Leviticus 19:18 


pgpTxb9ZFG4qX.pgp
Description: PGP signature

gnumeric and guppi in sid

[Jack Howarth]

   Has anyone managed to get guppi to work in current sid?
I have yet to have any success. Before today guppi would
silently fail whereas today I get a crash in guppi-gnumeric.
I am trying the following...

1) run gnumeric
2) enter two columns of three rows of numbers (1,2,3 and 2,4,6)
3) select these 6 cells
4) click on graph icon in the gnumeric tool bar

I am just wondering if guppi has every worked properly in
sid.
  Jack

Re: stat vs stat64 - ugly problem

[David N. Welton]

Wichert Akkerman <[EMAIL PROTECTED]> writes:

> Previously David N. Welton wrote:

> > I don't think it's right that two pieces of software can declare
> > the same struct and have them come out different things... there's
> > something wrong.
 
> Bogus, if you compile them with the same options then will the the
> same. If you compile one with LFS and one without you can expect
> problems as you have demonstrated.

Well then that's a problem, because we need to make sure everything in
Debian that could be combined is compiled with the these same things,
otherwise, there is a lot of room for nasty bugs.

In any case, changing the order of two header files doesn't seem
offhand like the sort of thing that would go about changing the system
definitions.  That's poor modularity, in my opinion, because neither
Apache nor Python, Tcl or anything else but libc6 owns the stuff in
include/sys/.

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/

Re: [Evms-devel] EVMS: shared libraries with unversioned sonames

[Tollef Fog Heen]

* Matt Zimmerman 

| If portability is an issue, the software in question should be using libtool
| anyway, which takes care of this for you.  If it will only ever work on
| GNU/Linux, ldconfig -n with an explanatory comment should be sufficient.

Example from where I've used ldconfig -n:

mklibs.py from boot-floppies doesn't generate the needed symlinks.
This took me about a day of working to discover, since I booted up a
system which gave me, well, strange error messages.  Running ldconfig
-n generated all the symlinks I needed, and was a quick and easy was
of doing it.

Why ldconfig?

   ldconfig - determine run-time link bindings
[snip]
  ldconfig  creates the necessary links and cache (for use by the run-
   time linker, ld.so) to the most recent shared libraries found in the
   directories   specified   on   the   command   line,   in  the  file
   /etc/ld.so.conf, and in the trusted directories (/usr/lib and /lib).

This seems like the tool I want to use.  The man page does not mention
that it is a Linux-only tool and should not be used it one wants
cross-platform portability.  Until somebody writes a cross-platform
utility to do what I want to do, ldconfig _is_ the right tool for the
job.  What does the Hurd use instead of ldconfig?  I presume that they
too have to create the necessary symlinks somehow?

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

RE: .dsc not generated during package build?

[Yves Arrouye]

> > Whilst building my package, I get (from dpkg-dev 1.9.18, debhelper
> 3.0.51):
> 
> What command did you run to do this?  What you probably meant was
> dpkg-buildpackage.

I did use dpkg-buildpackage -rfakeroot

Here's more of the log:

if test -d build -a build != source; then rm -f -r build; fi
 dpkg-source -b icu
dpkg-source: warning: source directory `./icu' is not
- `icu-2.0'
dpkg-source: building icu in icu_2.0-1.tar.gz
dpkg-source: building icu in icu_2.0-1.dsc
 debian/rules build

but the icu_2.0-1.dsc is not created at all.

If I go to a properly named directory (my mistake; I have a properly named
icu-2.0 and a symlink icu -> 2.0/icu-2.0 to get there, and usually work from
the symlink; somehow the scripts see the name icu, not icu-2.0 after I cd'ed
there w/ zsh) then it works:

if test -d build -a build != source; then rm -f -r build; fi
 dpkg-source -b icu-2.0
dpkg-source: building icu in icu_2.0-1.tar.gz

So why is dpkg-source just issuing a warning instead of failing if it really
cannot do anything? Is it looking at $CWD instead of finding out the real
location (zsh messes up w/ $CWD).

YA

Re: apt-get reinstall all

[Tollef Fog Heen]

*  (Jacob Elder)

| On Sun, Jan 06, 2002 at 06:05:26PM +0100, Tollef Fog Heen wrote:
|
| > dpkg -l  | awk '/^i/ {print $2}' |xargs apt-get --reinstall install
| > 
| > should work.
| 
| Not unless every package name is <16 characters.

COLUMNS=300 dpkg -l  | awk '/^i/ {print $2}' |xargs apt-get --reinstall install

fixes that.  At least until we have packages with names ~70 chars
long.

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

[¼ºÀα¤°í]1¿ù 2ÀÏ ½Å±Ô ¼ºÀλçÀÌÆ® ¿ÀÇÂÇÕ´Ï´Ù..

[bc°É]

Re: no space left on device: LVM, Gnus --> dpkg, apt-get ?

[Emanuele Aina]

Egon Willighagen <[EMAIL PROTECTED]> sbagliò:
> Actually, i have just read a debian-kde message about the PNG
> problem...
> That seems to be a KDE specific problem.
Yes, it is due to the problem about libpng.
Apt is completely innocent. :-)
--
Au revoir.
Lele...

Re: apt-get reinstall all

[Colin Walters]

On Sun, 2002-01-06 at 12:05, Tollef Fog Heen wrote:

> dpkg -l  | awk '/^i/ {print $2}' |xargs apt-get --reinstall install

dpkg --get-selections | egrep '[[:space:]]install$' | cut -f 1 | xargs apt-get 
install --reinstall

Re: stat vs stat64 - ugly problem

[Wichert Akkerman]

Previously David N. Welton wrote:
> I don't think it's right that two pieces of software can declare the
> same struct and have them come out different things... there's
> something wrong.

Bogus, if you compile them with the same options then will the the
same. If you compile one with LFS and one without you can expect
problems as you have demonstrated. 

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: apt-get reinstall all

[Robin Putters]

> I was just thinking that it would be great to have something in apt-get
> that get 'reinstall' or 'repaire' all packages installed on the system.
> I don't think I am the only one who rm *'s a wrong dir sometimes, ;)
> I think it's now real hard to reinstall every package installed ...
>

You could use 'cruft' to see what files you are missing (it compares the
local file system to the dpkg db), and then you know what packages to
(re)install...

>
> btw: I really like apt & that's why I try to help you make it better, :)
>

Who doesn't like it ? :)

Re: Evolution and GnuPG

[Joe Drew]

On Sun, 2002-01-06 at 06:38, Oliver Elphick wrote:
> I've noticed that Evolution (1.0-4) is very prone to report bad
> signatures.  To start with I thought it was down to use by the sender of
> a particular mailer, but I am beginning to doubt that.

This is a known bug in Evolution: see
http://bugzilla.ximian.com/show_bug.cgi?id=12425 .

Unfortunately it doesn't look hopeful that a fix is forthcoming.

Re: packaging spambouncer - cronjob updates in /usr???

[Carlos Laviola]

On Sun, Jan 06, 2002 at 05:31:28PM +0100, martin f krafft wrote:
> if i package spambouncer so that a configurable cronjob obtains updates
> on the anti-spam rules and databases from the spambouncer website, then
> the files can't remain in /usr, right?

Are you sure you want to do this?  What about all those people who
filter with spambouncer, but are dial-up users?  You need to either
have your job run when a PPP link is up, or ask the user if he's on a
LAN/has direct access to the Internet before doing this.

> the primary candidate for installation of spambouncer is
> /usr/share/spambouncer, but /usr/lib/spambouncer might be better. in any
> case, since /usr should be ro-mountable, these files should really be
> sitting in /var/lib, right? that would mean that the entire "program"
> sits in /var. is this acceptable?

It isn't really a program, just a collection of filters, which are
non-binary (thus, you'll only need to have a package which is
Architecture: all).  I'd say that if you rely on a method to update
your spambouncer definitions that ensures you that /usr is mounted,
you'd have no problem putting it on /usr/share/spambouncer/ like
procmail-lib does.

That's just my opinion, though, and I might be wrong :-)

-- 
 _ _  _| _  _  | _   . _ | _   to hell with icq, use jabber!
(_(_|| |(_)_)  |(_|\/|(_)|(_|  THIS SPACE INTENTIONALLY LEFT BLANK?

Re: CHECK BEFORE YOU RETITLE Re: Processed: Retitling...

[Uwe Hermann]

Hi,

On Sat, Jan 05, 2002 at 07:54:31PM -0600, Adam Majer wrote:
> Hey, buddy!! I ITA those packages a while back - I'll be uploading
> them in the next day!!! PLEASE CHECK THE O LIST 
> __BEFORE__ YOU RETITLE A BUG!

Please calm down. I was not trying to adopt these packages or anything.
I was only adding descriptions to some WNPP bugs where they were missing
and/or renaming the bugs so that they conform to the guidelines listed
at http://www.debian.org/devel/wnpp/...


> > > retitle 126198 O: saml -- Simple Algebraic Math Library
> > Bug#126198: ITA: saml
> > Changed Bug title.

OK, this is my fault, I somehow typo'ed this one, it should have been
renamed to 'ITA: saml -- Simple Algebraic Math Library'.


I guess I'll have to add an "I don't want your #*§$! package!" note to
all of my future cleanup mails...

Uwe.
-- 
Uwe Hermann
[EMAIL PROTECTED]
[EMAIL PROTECTED] | Unmaintained Free Software:
http://www.hermann-uwe.de | http://www.unmaintained-free-software.org

Re: Evolution and GnuPG

[Stephan Dietl]

Hello!

Josselin Mouette <[EMAIL PROTECTED]> schrieb:
> Oliver Elphick a écrit :
> > I've noticed that Evolution (1.0-4) is very prone to report bad
> > signatures.  To start with I thought it was down to use by the sender of
> > a particular mailer, but I am beginning to doubt that.
> [sneep]
> > Do other mail clients give similar results?
> I have noticed the same problem with evolution. It reports a number of 
> GPG signatures as bad, when besides mutt reports them as good. The 
> problem includes all mails written with gnus/oort, but also some others 
> from various mailers (and I couldn't figure out which thing in the 
> headers makes it get wrong).

Same thing happens other way around: If i get an email from a
evolution-user with sylpheed (which i like as much as mutt), it is
reported as BAD, whereas mutt reports it to be fine.

I once saw a two-mails-long thread on evolution-hackers-ML, where it was
basically stated that it is sylpheed`s problem.



Ciao,

Steve
-- 
www.cargal.org
GnuPG-key at www.cargal.org/interact/keys/Publotuskey.asc
"Let do what thou wilt
be the whole of the law!" A.C.


pgptQxuHVXKiY.pgp
Description: PGP signature

Re: apt-get reinstall all

[Matt Zimmerman]

On Sun, Jan 06, 2002 at 12:44:23PM +0100, Michael De Nil wrote:

> I was just thinking that it would be great to have something in apt-get
> that get 'reinstall' or 'repaire' all packages installed on the system.
> I don't think I am the only one who rm *'s a wrong dir sometimes, ;)
> I think it's now real hard to reinstall every package installed ...

It would be nice if apt-get --reinstall dselect-upgrade would do this.

-- 
 - mdz

Re: packaging spambouncer - cronjob updates in /usr???

[Adam Majer]

On Sun, Jan 06, 2002 at 05:31:28PM +0100, martin f krafft wrote:
> if i package spambouncer so that a configurable cronjob obtains updates
> on the anti-spam rules and databases from the spambouncer website, then
> the files can't remain in /usr, right?
> 
> the primary candidate for installation of spambouncer is
> /usr/share/spambouncer, but /usr/lib/spambouncer might be better. in any
> case, since /usr should be ro-mountable, these files should really be
> sitting in /var/lib, right? that would mean that the entire "program"
> sits in /var. is this acceptable?

The changing things go in /var/lib/spambouncer or something... If there 
are executables, these should go into /usr/bin or /usr/sbin or something.

- Adam

Re: [Evms-devel] EVMS: shared libraries with unversioned sonames

[Matt Zimmerman]

On Sun, Jan 06, 2002 at 05:59:55PM +0100, Tollef Fog Heen wrote:

> * Marcus Brinkmann 
> 
> | Sure, evms seems only to be available on GNU/Linux, too.  But just
> because | it happens to work by chance it is no excuse to do the wrong
> thing.  People | might take it as an example and use it in their own
> software, where it | doesn't work (on GNU/Hurd, and other systems).
> 
> Then please propose or write a tool which creates the proper symlinks from
> the sonames of the libraries and get it included in debianutils or some
> other reasonable please.  Until there is a tool which does that, people
> will not stop using ldconfig -n, because it works fine for the platforms
> most people use.

If portability is an issue, the software in question should be using libtool
anyway, which takes care of this for you.  If it will only ever work on
GNU/Linux, ldconfig -n with an explanatory comment should be sufficient.

-- 
 - mdz

Re: .dsc not generated during package build?

[Matt Zimmerman]

On Fri, Jan 04, 2002 at 10:26:11PM -0800, Yves Arrouye wrote:

> Sorry if that has been asked before. I mistakenly deleted quite a bit of
> Debian mail. I did check the archives for the past month though...
> 
> Whilst building my package, I get (from dpkg-dev 1.9.18, debhelper 3.0.51):

What command did you run to do this?  What you probably meant was
dpkg-buildpackage.

-- 
 - mdz

Re: maintainer for cervisia is MIA

[Adam Majer]

Try sending email to QA or something. Maybe they should orphan the package
owned by that maintainer.

- Adam

On Sun, Jan 06, 2002 at 01:34:53AM +0100, Ulrich Eckhardt wrote:
> I mailed the maintainer of the above package on the eleventh of december and 
> haven't got a reply yet. All the bugs of the package are pretty old, a new 
> version of the proggy is also available upstream, current version is > a year 
> old.
> 
> what should I do/can be done?
> Uli

Re: apt-get reinstall all

[Jacob Elder]

On Sun, Jan 06, 2002 at 06:05:26PM +0100, Tollef Fog Heen wrote:
> * Michael De Nil 
> 
> | I was just thinking that it would be great to have something in apt-get
> | that get 'reinstall' or 'repaire' all packages installed on the system.
> | I don't think I am the only one who rm *'s a wrong dir sometimes, ;)
> | I think it's now real hard to reinstall every package installed ...
> 
> dpkg -l  | awk '/^i/ {print $2}' |xargs apt-get --reinstall install
> 
> should work.

Not unless every package name is <16 characters.

-- 
Jacob Elder
http://www.lucidpark.net/

Re: Debian.rpm

[Russell Coker]

On Sat, 5 Jan 2002 00:27, Karl M. Hegbloom wrote:
>  I think you can probably boot to it with a carefully crafted initrd
>  that performs a pivot_root into the debootstrapped chroot.

I believe that pivot_root only works on mounted file systems, so unless your 
chroot environment is at the root directory of a different file system that 
won't work.

Why not use busybox-static to move the directories around?

>  Or, perhaps you could run a UML kernel there?  Has anyone tried that?

That's not as much fun.  We want to totally replace the old system...

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: CHECK BEFORE YOU RETITLE Re: Processed: Retitling...

[Adam Majer]

> Hi Adam,
> 
> it seems you misunderstood what Uwe was doing: He did only add the package
> descriptions to the WNPP bugs, IOW he changed e.g.
>   ITA: gtml
> to
>   ITA: gtml -- An HTML pre-processor
> or
>   O: wmf
> to
>   O: wmf -- Web Mail Folder
> 
> 
> These changes are visible e.g. in the wookly work-needing packages report
> or at the WNPP pages at [1]. Uwe never intended to adopt any of these
> packages.

Hi,

He did change some ITA to O - I have no idea why... IMHO, the 
difference b/w

 ITA: gtml

and

 ITA: gtml -- An HTML pre-processor

is trivial.. There should be no reason to do that especially 
that the package is ITA: for a few days... And generally adding 
a comment to something like:

"Just changing the title to be more readable - not attempting to 
adopt."

would suffice.

IMHO, retitling to ITA: without explanation is seen as an attemp 
to adopt a package..

Thanks,
Adam Majer

Re: Proper way for a i586-pc-linux-gnu (k6-2) to build for the same

[Andrew Hurt]

Junichi Uekawa wrote:
Could you elaborate ?
Uninstalled pentium-builder, and debian/rules build still aborted (could 
not find cc?).

Tried to figure how cc could not be referenced correctly (symlinks 
seemed OK, but would not work when called by debian/rules build).  Long 
story short, I removed everything associated with gcc.

Reinstalled gcc, et. al., and the build completed without any noticeable 
errors (though I could not tell if the k6 made it through to the compiler).

Installed the resulting .debs, and I could not detect a difference.
?
Thanks,
Andrew Hurt

Re: maintainer for cervisia is MIA

[Gustavo Noronha Silva]

On Sun, 6 Jan 2002 01:34:53 +0100
Ulrich Eckhardt <[EMAIL PROTECTED]> wrote:

> Hi all,
> I mailed the maintainer of the above package on the eleventh of december and 
> haven't got a reply yet. All the bugs of the package are pretty old, a new 
> version of the proggy is also available upstream, current version is > a year 
> old.
> 
> what should I do/can be done?
I hope I am not doing something wrong quoting this here:

"- you get some information about the maintainer (you see if he has many
  outstanding bugs, how old the bugs are, you check the last seen
  field on db.debian.org (you need to authenticate to get the info))
- you mail mia-@qa.debian.org
  ([EMAIL PROTECTED] is this case) explaining all what
  you learned. You may announce your intent to NMU in the same mail.
- you cc the maintainer in any case to let him a chance to react
- you forward any answer from the maintainer to
  mia-@q.d.o
- you may also forward the dinstall message saying that the NMU has been
  installed ..." -- Raphael Hertzog <[EMAIL PROTECTED]>

mailing the qa team may help as well

[]s!

-- 
Gustavo Noronha Silva - kov 
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
|  .''`.  | Debian GNU/Linux:  |
| : :'  : + Debian BR...: +
| `. `'`  + Q: "Why did the chicken cross the road?"  +
|   `-| A: "Upstream's decision." -- hmh  |
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+

new selftest target in debian/rules, new package state for autobuilder (suspect), debs that selftest on build

[Maitland Bottoms]

Hi,

In packaging VTK I have come across some tools which address some of
the same things Goswin Brederlow brought up.

It turns out that developing a 3-D scientific data visualization
library is only part of the goals of the Visualization Tool Kit (VTK)
project. The other part is concerned with the metrics of software
quality in large projects.

To that end the VTK package includes regression tests in the build
process, and a reporting package to accumulate the results.

I'd been planning on packaging Dart, but since it is so dependent on
web servers and the specifics of build system clients the way to
package it was not immediately clear to me.

An example Dart ouput:
http://public.kitware.com/vtk/quality/MostRecentResults/

The Dart site:
http://public.kitware.com/Dart/

A chart of the process:
http://public.kitware.com/vtk/quality/vtksqa/vtkSqaProcess.hmtl

So I just thought it would be a good time to point out these tools to
more people in the Debian project, and leave as an exercise for the
reader the integration of the good parts of the Dart tools with the
Debian auto-building infrastructure.

-Maitland

Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

[Steve Greenland]

On 06-Jan-02, 04:55 (CST), Adrian Bunk <[EMAIL PROTECTED]> wrote: 
> 
> You need to do this in a portable way so that it works on every system...

No, the people who want modern code to run on their systems need to
figure out how to support the standard. Why should every piece of
code contain the work-arounds to support broken systems, rather than
expecting the systems to solve their own problems?

> It's the choice of the author of a program whether he wants to support
> older systems or not - 

Exactly. It's not required, and shouldn't even be expected. I'd much
rather an author spent time adding features, or writing docs, or even
relaxing with Quake than waste it supporting the 1993 version of
Piece-o'-Crap OS. But that's my opinion, and if some one feels the need,
then that's up to them.

>I remember that e.g. many GNU programs still support
> pre-ANSI C compilers.

Which is really sad. It makes the code harder to read, and provides
ample opportunity for subtle bugs when the standard code path is
updated, and the non-standard one isn't. The only thing that really
needs to support pre-ansi compilers is gcc (and possibly GNU make).

Anyway, I suppose this is off-topic enough. The original point was that
most people don't even know how to write standard conforming code, much
less adjust for supporting systems that aren't.

Steve

Re: Evolution and GnuPG

[Josselin Mouette]

Oliver Elphick a écrit :
> I've noticed that Evolution (1.0-4) is very prone to report bad
> signatures.  To start with I thought it was down to use by the sender of
> a particular mailer, but I am beginning to doubt that.
[sneep]
> Do other mail clients give similar results?

I have noticed the same problem with evolution. It reports a number of 
GPG signatures as bad, when besides mutt reports them as good. The 
problem includes all mails written with gnus/oort, but also some others 
from various mailers (and I couldn't figure out which thing in the 
headers makes it get wrong).

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'
  `-  Debian GNU/Linux -- The power of freedom


pgpGzUHWXnuf5.pgp
Description: PGP signature

Re: 1 package(s) to rebuild on i386/stable

[Tollef Fog Heen]

*  (Martin Schulze)

| 
http://ftp.debian.org/debian/pool/main/n/nfs-utils/nfs-utils_0.1.9.1-1.potato1.dsc
| 
http://ftp.debian.org/debian/pool/main/n/nfs-utils/nfs-utils_0.1.9.1-1.potato1.tar.gz

Built, test-installed and uploaded.

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: 1 package(s) to rebuild on i386/stable

[Petter Reinholdtsen]

[Martin Schulze]
> For further explanation please check the detailed report at
> .

libc6 is still not mentioned on this list.  Is this on purpose, or did
someone forget to let you know?

There seem to be a security problem with the current potato/woody
glibc.  Check
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=126441> for
details.

Re: maintainer for cervisia is MIA

[Petter Reinholdtsen]

[Ulrich Eckhardt]
> Hi all,
> I mailed the maintainer of the above package on the eleventh of
> december and haven't got a reply yet. All the bugs of the package
> are pretty old, a new version of the proggy is also available
> upstream, current version is > a year
> old.

The same is the situation for pingus.  I tried to email the maintainer
2001-12-23, no reply yet.  No changes in > 260 days.  Last upload was
NMU.  I've tried to email the one doing NMU after a bug squashing
party in April 2001.  Not sure what more I can do.

Re: Bug#126856: kernel-package: kernel-image should deal with flavours just like modules packages

[Manoj Srivastava]

>>"martin" == martin f krafft <[EMAIL PROTECTED]> writes:

 martin> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2002.01.06.1016 
+0100]:
 >> Wrong. Read the documentation on the Flavours before using
 >> it. This is the reason that Flavours are deprecated, incidentally. 

 martin> okay, i did read /usr/share/doc/kernel-package/Flavours.gz, but it
 martin> really just didn't solve my problem.

That does not make it a bug in the package.

 martin> the reason that i am objecting to closing this bug is because
 martin> i have official debian packages here to compile my kernels
 martin> and modules, and what i get out is *broken*. i don't care
 martin> whether flavours are (going to be) deprecated, that feature
 martin> exists with the release of kernel-package that i have, and
 martin> thus i should be able to use it.

Yes. And the feature requires you to patch the
 Makefile. Always has. Just because you failed to read the
 instructions and did not know how the feature worked does not make it
 a package bug.

 martin> i am thus reopening the bug

And I am reclosing it.

 martin> as well as raising its severity, not because i want to "catch
 martin> attention" or anything, but because kernel-package violates
 martin> debian policy!

How so?

 martin> when i compile the kernel as flavour "fishbowl" and the
 martin> kernel-image*.deb package places its modules into
 martin> /lib/modules/2.4.17, while proper modules packages like
 martin> alsa-driver or pcmcia-cs put their modules in
 martin> 2.4.17+fishbowl, then there is a problem. without manual
 martin> interaction, you won't get the new kernel to see the modules
 martin> of the modules package. and that i consider a serious bug!

This is pilot error. Had you modified the Makefile like you
 are required to in order to use the flavours target, this would not
 happen. Next time, read the instructions first.


 martin> so this is pretty much two bugs, the first one has major effects on
 martin> usability, the second violates the policy. i don't think this bug is
 martin> closed yet.

No, this is the user not reading the instructions, and
 creating a mess.

manoj
-- 
 One Bell System - it sometimes works.
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: maintainer for cervisia is MIA

[Gergely Nagy]

> I mailed the maintainer of the above package on the eleventh of december and 
> haven't got a reply yet. All the bugs of the package are pretty old, a new 
> version of the proggy is also available upstream, current version is > a year 
> old.

He is my applicant, and has a new version ready (with a few bugs
waiting to be sorted out). Try mailing him again, he might have missed
your mail.


pgpBVZcxJClkZ.pgp
Description: PGP signature

Re: maintainer for cervisia is MIA

[Josip Rodin]

On Sun, Jan 06, 2002 at 01:34:53AM +0100, Ulrich Eckhardt wrote:
> I mailed the maintainer of the above package on the eleventh of december
> and haven't got a reply yet. All the bugs of the package are pretty old, a
> new version of the proggy is also available upstream, current version is >
> a year old.
> 
> what should I do/can be done?

NMU it.

-- 
 2. That which causes joy or happiness.

Re: EURO and CENT signs in the console keymaps

[Emanuele Aina]

Ari Makela <[EMAIL PROTECTED]> dubitò:
> me neither. I must show my ignorance: I don't know what it
> is.
¥ means "yen", the Japanese currency.
--
Au revoir.
Lele...

Re: EURO and CENT signs in the console keymaps

[Mark Brown]

On Sat, Jan 05, 2002 at 01:55:10PM +0100, Josip Rodin wrote:

> Actually, I don't think I've ever seen "AltGr" printed on a key, yet all the
> keyboards in .hr have the right alt doing that.

It's standard on UK keyboards.

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


pgpgkTR0Q99Rw.pgp
Description: PGP signature

Re: apt-get reinstall all

[Tollef Fog Heen]

* Michael De Nil 

| I was just thinking that it would be great to have something in apt-get
| that get 'reinstall' or 'repaire' all packages installed on the system.
| I don't think I am the only one who rm *'s a wrong dir sometimes, ;)
| I think it's now real hard to reinstall every package installed ...

dpkg -l  | awk '/^i/ {print $2}' |xargs apt-get --reinstall install

should work.

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: stat vs stat64 - ugly problem

[David N. Welton]

Wichert Akkerman <[EMAIL PROTECTED]> writes:

> Previously David N. Welton wrote:

> > I'm not sure exactly what problems this may cause, but I don't
> > like the looks of it...  Interestingly (... or not) enough, that
> > define isn't created when building locally (version 1.3.23-dev)...
 
> It doesn't cause any problems at all, it is by design.

Actually it caused me a great deal of problems - hours spent tracking
down a bug in mod_dtcl, that as far as I can tell, is caused by this
mismatch.

I don't think it's right that two pieces of software can declare the
same struct and have them come out different things... there's
something wrong.  You can convince me that it's Apache, libc, Tcl,
mod_dtcl, or whatever else, but something doesn't seem right to me.

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/

Re: [Evms-devel] EVMS: shared libraries with unversioned sonames

[Tollef Fog Heen]

* Marcus Brinkmann 

| Sure, evms seems only to be available on GNU/Linux, too.  But just because
| it happens to work by chance it is no excuse to do the wrong thing.  People
| might take it as an example and use it in their own software, where it
| doesn't work (on GNU/Hurd, and other systems).

Then please propose or write a tool which creates the proper symlinks
from the sonames of the libraries and get it included in debianutils
or some other reasonable please.  Until there is a tool which does
that, people will not stop using ldconfig -n, because it works fine
for the platforms most people use.

I know that it doesn't make your life easier, but when Hurd is the odd
one out, you will often have to create tools which work on all
platforms.

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: Installed postgresql 7.1.3-6 (i386 all source)

[Roland Mas]

Oliver Elphick (2002-01-05 20:53:08 +0100) :


[...]

> Closes: 12166 121666 121699 121712 121944 122167 122871 123349 123950 124317 
> 125772 126193 126440 127004 127275
> Changes: 
>  postgresql (7.1.3-6) unstable; urgency=low
>  .
>* postgresql: fix postgresql-dump so that it doesn't crash out
>  unnecessarily if an unneeded file is missing. (Thanks to Thien-Thi
>  Nguyen <[EMAIL PROTECTED]>.)
>* Build dependencies: changed python-dev to python2.1-dev; added 
> zlibg1-dev.
>  Closes: #12166, #126193
^
I'm not quite sure this is what you meant there.  Bug #12166 is
related to fdutils, not postgresql.

  Just my tuppence, of course.

Roland.
-- 
Roland Mas

Plus on en fout, plus y'en a du riz.
  -- Proverbe chinois.

Re: Some thoughts about problems within Debian

[Michael Meskes]

On Sun, Jan 06, 2002 at 11:56:38AM +1000, Anthony Towns wrote:
> But like I said, that wouldn't buy as anything: the *hardest* parts are
> getting base and standard working properly, once they're done, it's not overly

Okay, good point.

> Well, in a sense they don't: it's the fact that the core packages aren't
> in a releasable state that's preventing us from releasing.

I thought it wasn't that way, sorry.

> I'm sorry, I just can't see this working, let alone being easier than what
> we're currently doing.

Of course I like a new complete release at least once a year even more. :-)

> "Just" an upgrade problem. You do realise that's an absolutely horrible
> attitude to take? While you (and, evidently, everyone else who knows about
> postgresql) are sitting there saying "Yay! Postgres has no bugs that
> matter", I'm sitting here saying "Great. Postgres has RC bugs. Should
> I remove it from the distribution, or wait, or find someone to buy me a
> ski holiday?" If the bug really is RC (and the severity descriptions are
> fairly clear these days) it has to be fixed. It's that simple. If it's not
> RC, then it shouldn't be marked that way, and it should be fixed anyway.

Sorry, that came out sounding completely different than what I was thinking
when typing. The "just" referred to "no bug in the upstream". Back when I
checked I wanted to pass all release critical bugs in postgresql to the
upstream so they get fixed for everyone. However, the upgrade part seemed to
be Debian specific and besides very difficult for me to reproduce as I have
no machines with an old Postgresql version around anymore. That's what I
meant to say with "just". I do fully agree that the bugs have to be fixed.

Also it seems that Oliver is still working on the package. From your last
mail I got the impression that no one is working on the packages which
certainly is not true. After all there as a new upload two days ago or so. 

I certainly didn't want to diminish the work you're doing, but I still think
we have to find better ways to release. potato is too old right now and most
people I do talk to, tell me they don't care about all these packages, but
they want newer versions of the packages they use. Yes, I know that if we
take all those people we probably have 99% of the packages belonging into
someone's core, but the age is a factor.

We have to find a way to release more often IMO. But I do not know how to
reach that goal. After all my time is serverly limited. At least I do not
have a release critical bug on my packages right now.

Michael

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


pgpJxFLfgv35N.pgp
Description: PGP signature

Re: Evolution and GnuPG

[Robert Kosinski]

Hm, I've already deleted the messages in question, but I know I always get
good signatures from Anthony Towns and Branden Robinson.  I also believe I got
a good signature from that Michael Meskes message as well.  In fact, I don't
think I've seen a bad signature.  This is mutt 1.3.25-1, gnupg 1.0.6-2, and
debian-keyring 2001.09.22.

On Sun, Jan 06, 2002 at 11:38:54AM +, Oliver Elphick wrote:
> I've noticed that Evolution (1.0-4) is very prone to report bad
> signatures.  To start with I thought it was down to use by the sender of
> a particular mailer, but I am beginning to doubt that.
> 
> I checked signatures of 3 signed messages on the debian-devel list that
> I have read this morning.  2 are reported as bad and 1 as good:
> 
> Michael Meskes - Re: Some thoughts about problems within Debian
> <[EMAIL PROTECTED]>
> gpg: armor header: Version: GnuPG v1.0.6 (GNU/Linux)
> gpg: armor header: Comment: Weitere Infos: siehe http://www.gnupg.org
> gpg: Signature made Fri Jan  4 20:15:41 2002 GMT using ELG key ID 2F6DD073
> gpg: using secondary key 2F6DD073 instead of primary key 29F19BD1
> gpg: BAD signature from "Dr. Michael Meskes <[EMAIL PROTECTED]>
> 
> Anthony Towns - Re: Some thoughts about problems within Debian
> <[EMAIL PROTECTED]> 
> gpg: armor header: Version: GnuPG v1.0.6 (GNU/Linux)
> gpg: armor header: Comment: For info see http://www.gnupg.org
> gpg: Signature made Sat Jan  5 00:55:51 2002 GMT using RSA key ID 7172DAED
> gpg: BAD signature from "Anthony Towns <[EMAIL PROTECTED]>"
> 
> Branden Robinson - Re: EURO and CENT signs in the console keymaps:
> <[EMAIL PROTECTED]>
> gpg: armor header: Version: GnuPG v1.0.6 (GNU/Linux)
> gpg: armor header: Comment: For info see http://www.gnupg.org
> gpg: Signature made Fri Jan  4 23:32:17 2002 GMT using DSA key ID 2B46A27C
> gpg: Good signature from "Branden Robinson <[EMAIL PROTECTED]>"
> gpg: aka "Branden Robinson <[EMAIL PROTECTED]>"
> gpg: key 3E1D0C1C: already in trusted key table
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the owner.
> gpg: Fingerprint: 1573 D544 73C3 988F 0096  3E4F EA4C 661F 2B46 A27C
> 
> Do other mail clients give similar results?
> 
> -- 
> 
> Oliver Elphick[EMAIL PROTECTED]
> Isle of Wight  http://www.lfix.co.uk/oliver
> GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
> 
>  "Thou shalt not avenge, nor bear any grudge against the
>   children of thy people, but thou shalt love thy  
>   neighbour as thyself. I am the LORD." 
>  Leviticus 19:18 

Re: Some thoughts about problems within Debian

[Tollef Fog Heen]

* Bas Zoetekouw 

| You wrote:
| 
| > Then you are _very_ wrong.  There are too many and too complicated
| > questions asked for a «normal user», whatever that is.  You have to be
| > interested and/or have somebody help you install Debian, else you will
| > give up halfway.
| 
| Maybe we we should have two modes: a ``user mode'' and a ``administrator
| mode''. Teh administrator mode then should be the current situation,
| whil ein user mode, only simple questions (e.g. "is your system
| connected to a network? yes/no") should be asked.

Maybe so; it will be a lot easier to do that for debian-installer than
trying to whack it into the frozen boot-floppies code. :)

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

packaging spambouncer - cronjob updates in /usr???

[martin f krafft]

if i package spambouncer so that a configurable cronjob obtains updates
on the anti-spam rules and databases from the spambouncer website, then
the files can't remain in /usr, right?

the primary candidate for installation of spambouncer is
/usr/share/spambouncer, but /usr/lib/spambouncer might be better. in any
case, since /usr should be ro-mountable, these files should really be
sitting in /var/lib, right? that would mean that the entire "program"
sits in /var. is this acceptable?

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
all of you that believe in telekinetics, raise my hand!


pgpCbjJvbVfVZ.pgp
Description: PGP signature

Re: apt-get reinstall all

[Bernd Eckenfels]

On Sun, Jan 06, 2002 at 12:44:23PM +0100, Michael De Nil wrote:
> I was just thinking that it would be great to have something in apt-get
> that get 'reinstall' or 'repaire' all packages installed on the system.

You can use "apt-get --reinstall install "

There are a few possibilities to create the list from your system.

Greetings
Bernd

Re: Bug#126856: kernel-package: kernel-image should deal with flavours just like modules packages

[Elie Rosenblum]

On Sun, Jan 06, 2002 at 02:31:48PM +0100, martin f krafft wrote:
> and maybe someone can suggest an alternative to flavours. i have about
> 27 systems for which i have kernel-images, using the flavour to specify
> the machine name. this works beautifully. without the flavour, i would
> not have the possibility to update one machine's kernel and install it
> via apt from my own apt-compatible server. i need to be able to do this.
> scp'ing and dpkg -i are not options, apt-get upgrade must take care of
> this.

I believe you're supposed to use --append-to-version instead. Try:
make-kpkg --append-to-version -whatever clean
make-kpkg --append-to-version -whatever kernel-image modules-image

Without the clean you will have serious problems.

I've used this instead of flavours and it seems to work properly.

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_


pgpHCNX3s6ycN.pgp
Description: PGP signature

Re: apt-get reinstall all

[Erich Schubert]

> I was just thinking that it would be great to have something in apt-get
> that get 'reinstall' or 'repaire' all packages installed on the system.
> I don't think I am the only one who rm *'s a wrong dir sometimes, ;)
> I think it's now real hard to reinstall every package installed ...

well, if you rm'ed /usr/share p.e. just run
apt-get --reinstall install `dpkg -S /usr/share | sed -e 's/,//g' -e 's/:.*$//'`

if you want to reinstall all installed software, i'd try something like
apt-get --reinstall `dpkg --get-selections | grep install | grep -v deinstall | 
cut -d' ' -f1`

Shell scripting is great ;)

Greetings,
Erich

Re: Many .changes not being sent to debian-devel-changes

[Daniel Burrows]

On Sunday 06 January 2002 09:40 am, Robert Bihlmeyer wrote:
> recently, the debian-devel-changes list is missing more .changes
> messages than usual. I first suspected a local config change as the
> culprit, but

  There was a note yesterday on Debian Planet about a resource-exhaustion 
problem on lists.debian.org.  Maybe that has something to do with this?

  Daniel

Re: Still no fam in Woody

[Joerg Wendland]

Petter Reinholdtsen, on 2002-01-05, 22:49, you wrote:
> * fam/hppa unsatisfiable Depends: libstdc++3 (>=
>   1:3.0.3-0pre011215) ['gcc-3.0']
  ^^ see below...

> Why is it still not included in Woody?  Several kde and gnome packages
> depend on this package, and it would be nice if it make it into Woody
> soon.

Why does nearly any KDE package depend on FAM?
 
> I do not understand the unsatisfiable depend error.  The program was
> successfully compiled on hppa.  Is the problem gcc-3.0 >=
> 3.0.3-0pre011214 missing in Woody?  This seem to be a problem on arm
> and m68k, and should not affect hppa, or am I mistaken?

The problem is that FAM does only on hppa depend on libstdc++3 for on
that arch there is no gcc-2.9x. The buildd runs on unstable. The libstdc++3
version there 3.0.3-1 (would fit) but its version in testing is 3.0.2-4.
And since gcc-3 is out of date on other arches this situation will last
on it seems. A solution were to compile FAM against the testing libstdc++3
and reupload but I dunno if such is possible.

Regards, Joerg (maintainer of fam)

-- 
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A  F318 57A3 7FBD 51CF 8417


pgpsGok8Ir1dW.pgp
Description: PGP signature

Re: Many .changes not being sent to debian-devel-changes

[Wichert Akkerman]

Previously Robert Bihlmeyer wrote:
> mozilla_0.9.7-3_i386.changes(non-us)
> openssh_3.0.2p1-2_i386.changes  (non-us)
> rsync_2.5.1-0.1_i386.changes

I did get those three.

> I can dig up more if needed (counting only packages I have installed
> I've found 15 today).

I suspect it's a broken mailsetup somewhere in debian.org, I have
gotten all dinstall mails from friday somewhere on saturday, most
after being delayed for over 24 hours.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: .dsc not generated during package build?

[Wichert Akkerman]

Previously Yves Arrouye wrote:
> any idea about what is happening? Why isn't ../icu_2.0-1.dsc found (when cat
> complains)?

dpkg-source builds the .dsc file.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: no space left on device: LVM, Gnus --> dpkg, apt-get ?

[Joey Hess]

Egon Willighagen wrote:
> That makes me wonder: is it possible that i am imagening things, and that the 
> upgrade went well, even though my HD was full? Did it actually install files 
> then, or did it not overwrite, because of the HD being full, and my files are
> basically not upgraded, but just the version numbers in the index that dpkg 
> uses?

Dpkg has very robust error detection and handling code. If the disk
fills up or it cannot write to a file, it will abort the upgrade, and
roll back to the previously installed version of the package.

It doesn't have support for pausing for more disk space to be made
available, but then all you have to do is run it again..

-- 
see shy jo

Re: Adopting these packages

[Eray Ozkural \(exa\)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Friday 04 January 2002 17:03, Daniel Stone wrote:
> (BCC'ed to [EMAIL PROTECTED]).
>
> I will adopt the KDE packages, while Chris "calc" Cheney will take Qt, and
> will also be the KDE3 maintainer when it comes around to it; by the time
> KDE2.2 is phased out in favour of KDE3, I won't have the time to maintain
> KDE, so it works out nicely.
>
> :) d
>
> Please CC all replies to me; the MX for the domain I get all list mail on
> is down, so I'm reduced to reading lists through the archives. If you
> don't, I reserve the right to have a long, flaming, thread about the fact.
> Oh, and sorry about the line wrapping - LookOut! Express doesn't have it.
> :\

Hi Daniel,

I'm a KDE hacker. I would like to eventually adopt KDE3 packages. Could Chris 
please contact me?

Unfortunately I'm not available until February, but if you have any problems 
I'd try to help.

Thanks,

- -- 
Eray Ozkural (exa) <[EMAIL PROTECTED]>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8NymzfAeuFodNU5wRArY1AJ99z5fT3cSDSg/+ONmtYqj6JnzDIQCdFrQX
ws32zGnOqw/ynCBZwPYvoXQ=
=yKYi
-END PGP SIGNATURE-

Re: Some thoughts about problems within Debian

[Mark Brown]

On Fri, Jan 04, 2002 at 09:15:41PM +0100, Michael Meskes wrote:
> On Fri, Jan 04, 2002 at 11:37:46PM +1000, Anthony Towns wrote:

> > It's already pretty split-up: we have base, we have standard, and we

> That's what I meant to say. The only think we don't have is the release of
> base/standard without extra etc.

That's one of the things testing was supposed to facilitiate.  With
testing we hopefully keep around a stack of releasable versions of
these packages.  It doesn't quite work that way of course, but it ought
to help a great deal.

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


pgpdQ8R3iUHXc.pgp
Description: PGP signature

Bug#127909: glibc: cross compile support

[YAEGASHI Takeshi]

Package: glibc
Version: 2.2.4-7
Tags: patch

Hi,

It seems glibc source package is aware of cross compile, but I feel
current version is not very useful.  I'm using dpkg-cross and applying
following patch to glibc.

  * makerules.dpatch: Disable check for make -e.  It checks $(PATH),
but $(PATH) is overriden by dpkg-buildpackage of dpkg-cross via
MAKEFLAGS, so the check always fails.

  * linux.mk: cross compile support.
- Checking building host's kernel-headers packages is useless.
- LINUX_SOURCE variable must be set for later use.

My target architecture is mainly SuperH, but I want to hear about
other architecture's circumstances.


diff -ruN glibc-2.2.4/debian/patches/0list glibc-2.2.4-new/debian/patches/0list
--- glibc-2.2.4/debian/patches/0listSat Jan  5 20:32:22 2002
+++ glibc-2.2.4-new/debian/patches/0listSat Jan  5 20:02:09 2002
@@ -19,3 +19,4 @@
 glibc22-locales
 sparc64-fixups
 glibc22-getdents-fix
+makerules
diff -ruN glibc-2.2.4/debian/patches/makerules.dpatch 
glibc-2.2.4-new/debian/patches/makerules.dpatch
--- glibc-2.2.4/debian/patches/makerules.dpatch Thu Jan  1 09:00:00 1970
+++ glibc-2.2.4-new/debian/patches/makerules.dpatch Sat Jan  5 20:01:15 2002
@@ -0,0 +1,35 @@
+#! /bin/sh -e
+
+# All lines beginning with `# DP:' are a description of the patch.
+# DP: Prevent -e option checking.
+
+if [ $# -ne 2 ]; then
+echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+exit 1
+fi
+case "$1" in
+-patch) patch -d "$2" -f --no-backup-if-mismatch -p1 < $0;;
+-unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p1 < $0;;
+*)
+   echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+   exit 1
+esac
+exit 0
+
+# append the patch here and adjust the -p? flag in the patch calls.
+--- glibc-2.2.4/Makerules.orig Mon Dec 10 23:49:08 2001
 glibc-2.2.4/Makerules  Mon Dec 10 23:49:22 2001
+@@ -44,13 +44,6 @@
+ sources :=
+ endif
+ 
+-oPATH := $(PATH)
+-PATH := this definition should take precedence over $(oPATH)
+-ifeq ($(PATH),$(oPATH))
+-You must not use the -e flag when building the GNU C library.
+-else
+-PATH := $(oPATH)
+-endif
+ 
+ ifndef +included-Makeconfig
+ include $(..)Makeconfig
diff -ruN glibc-2.2.4/debian/sysdeps/linux.mk 
glibc-2.2.4-new/debian/sysdeps/linux.mk
--- glibc-2.2.4/debian/sysdeps/linux.mk Sat Jan  5 20:32:22 2002
+++ glibc-2.2.4-new/debian/sysdeps/linux.mk Sat Jan  5 21:56:12 2002
@@ -48,8 +48,18 @@
   endif
   with_headers := --with-headers=$(LINUX_SOURCE)/include
 else
-  # Cross compiles can just use sys-include
-  with_headers :=
+  ifndef LINUX_SOURCE
+# Building host's kernel-headers package must not be used for cross 
compile.
+# Give a probable default instead.
+# But this may cause unnessesary headers get mixed into libc-dev package.
+LINUX_SOURCE := /usr/$(DEB_HOST_GNU_TYPE)
+num_headers := 1
+  else
+# Get it from the environment
+LINUX_SOURCE := $(strip $(shell echo ${LINUX_SOURCE}))
+num_headers := 1
+  endif
+  with_headers := --with-headers=$(LINUX_SOURCE)/include
 endif
 
 # Minimum Kernel supported


-- 
YAEGASHI Takeshi <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

1 package(s) to rebuild on i386/stable

[Martin Schulze]

These packages have to be rebuilt for stable on i386 in order to let
the packages go into 2.2r5.

Please find URLs to source packages attached below for convenience.
When uploading, please take care of the distribution, which should
contain 'stable' and nothing else.

For further explanation please check the detailed report at
.

http://ftp.debian.org/debian/pool/main/n/nfs-utils/nfs-utils_0.1.9.1-1.potato1.dsc
http://ftp.debian.org/debian/pool/main/n/nfs-utils/nfs-utils_0.1.9.1-1.potato1.tar.gz

Thank you for your contribution,

Joey

-- 
This mail was generated automatically.

maintainer for cervisia is MIA

[Ulrich Eckhardt]

Hi all,
I mailed the maintainer of the above package on the eleventh of december and 
haven't got a reply yet. All the bugs of the package are pretty old, a new 
version of the proggy is also available upstream, current version is > a year 
old.

what should I do/can be done?
Uli

new selftest target in debian/rules, new package state for autobuilder (suspect), debs that selftest on build

[Goswin Brederlow]

Hi,

I'm trying to build gcc-3.0 manually because the autobuilder on m68k
just timeout on it. So all this takes gcc-3.0 as example, nothing
personal. This is more about improving the autobuilders.

Doing a test compile on i386 (way faster to check build-depends and
general errors there) I noticed that the selftests of gcc had
unexpected failures.

But since that happens all the time the results of the selftests are
just ignored and the build succeeds. The reason being that otherwise
there would never be a successfull build, esspecialy for the MHz
challenged archs.


But neigther failing nor succeeding seems to be right here.
My suggestion would be to have a target "selftests" in
debian/rules. During build that should be called to carry out the
selftests (if any).

Now two things can happen:

- The selftests work fine. The package completes its build and gets
uploaded to unstable. (the build succeeds).

- The selftests fail. The package gets flaged as suspect because of
selftest failures and uploaded to experimental or selftest-failures or
so. Then someone can take a look at the debs and check what caused the
selftest failures. If its nothing serious (like outdated testcases)
the package can still be released. If its something serious, he can
patch it and upload a new version.



Why not just fail the build when the selftest fails?

Many packages build multiple debs. Many take very long to build,
esspecially those with selftests. A selftest failure in for example
the libjava portion of gcc should not hold back all other gcc
packages. The debs should still be build and then the maintainer can
move everything but libjava.deb to incoming.


Comments, ideas, flames?
Goswin

Re: stat vs stat64 - ugly problem

[Wichert Akkerman]

Previously David N. Welton wrote:
> I'm not sure exactly what problems this may cause, but I don't like
> the looks of it...  Interestingly (... or not) enough, that define
> isn't created when building locally (version 1.3.23-dev)...

It doesn't cause any problems at all, it is by design.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: VIM features

[Wichert Akkerman]

Previously Paul Mackinney wrote:
> What would be helpful is a README.Debian file in /usr/doc/vim that
> alerts the user to the existence of /etc/vim/vimrc and its nice set of
> potential customizations.  I had overlooked the vim stuff in /etc, but I 
> have learned to check the /usr/doc directory.

Feel free to write one :)

Wichet.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Still no fam in Woody

[Adrian Bunk]

On Sat, 5 Jan 2002, Petter Reinholdtsen wrote:

> The current excuse for 'fam' in
> http://ftp-master.debian.org/testing/update_excuses.html.gz> is
>
>   - fam (- to 2.6.6.1-4)
> * Maintainer: Joerg Wendland
> * 16 days old (needed 10 days)
> * fam/hppa unsatisfiable Depends: libstdc++3 (>=
>   1:3.0.3-0pre011215) ['gcc-3.0']
> * Valid candidate
> * Depends: fam gcc-3.0
>
> Why is it still not included in Woody?  Several kde and gnome packages
> depend on this package, and it would be nice if it make it into Woody
> soon.
>
> I do not understand the unsatisfiable depend error.  The program was
> successfully compiled on hppa.  Is the problem gcc-3.0 >=
> 3.0.3-0pre011214 missing in Woody?  This seem to be a problem on arm
> and m68k, and should not affect hppa, or am I mistaken?

short answer:
fam won't go into woody as long as the build errors of gcc-3.0 on arm and
m68k aren't fixed.

long answer:
fam was compiled with a recent libstdc++3-dev on hppa so you got a
dependency on libstdc++3 (>= 1:3.0.3-0pre011215). This dependency can't be
fulfilled inside woody at the moment. The way testing works is that fam
won't get into woody until a recent enough libstdc++3 is in testing. It
doesn't matter whether the problems that keep the new libstdc++3 from
entering testing are build problems on other architectures, RC bugs in any
package built from the gcc-3.0 source package or dependency problems that
arise when the binary packages from gcc-3.0 enter testing.


cu
Adrian

Debian at FOSDEM 2002

[Martin Schulze]

Moin!

We have also been invited by FOSDEM to attend this year's Free and
Open Source Developers Meeting taking place on February 16th and 17th
in Bruxelles.  There are a lot of seminar rooms which can be used by
all participating projects and developers.  If there are people from
Debian who would like to give a talk or listen to Debian talks, these
rooms can be used.

We are currently not participating because there are too few people
attending FOSDEM.  Currently my list of people contains five Debian
people going there.  Out of these Eric Van Buggenhaut offered to give
a talk about Debian packaging.

People who are interested should drop a mail to
debian-events-eu@lists.debian.org

Koordination und Informationen:

  

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.

Bug#128013: ITP: debpartial -- Debian Packages/Sources file partition tool

[Masato Taruishi]

Package: wnpp
Version: N/A; reported 2002-01-06
Severity: wishlist

* Package name: debpartial
  Version : 0+20020106.1
  Author  : Masato Taruishi <[EMAIL PROTECTED]>
* License : GPL
  Description : Debian Packages/Sources file partition tool

debpartial is a program to separate Packages and Sources files by
size of packages and sources. We can create debian partial mirror
, distribution, and so on using debpartial.

This program is similar with list2cds of debian-cd, but for more
general purpose.

~$ dpkg -I debpartial_0+20020106.1_all.deb
 new debian package, version 2.0.
 size 10620 bytes: control archive= 982 bytes.
 574 bytes,16 lines  control  
 489 bytes, 7 lines  md5sums  
 269 bytes, 9 lines   *  postinst #!/bin/sh
 202 bytes, 7 lines   *  prerm#!/bin/sh
 Package: debpartial
 Version: 0+20020106.1
 Section: misc
 Priority: extra
 Architecture: all
 Depends: ruby, libzlib-ruby
 Installed-Size: 96
 Maintainer: Masato Taruishi <[EMAIL PROTECTED]>
 Description: Debian Packages/Sources file partition tool
  debpartial is a program to separate Packages.gz and Sources.gz
  files by size of packages and sources. It can be used in the
  case of:
  .
   * creating 1 DVD/CD Debian (including binaries and sources in the storage)
   * separating the debian archive into several harddisks.
   * mirroring packages only you want (using debmirror etc).

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux gnu 2.4.16-686 #1 Wed Nov 28 09:27:17 EST 2001 i686
Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP

Re: An alarming trend (no it's not flaimbait.)

[Goswin Brederlow]

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

> On Thu, 03 Jan 2002, Craig Dickson wrote:
> > Karl M. Hegbloom wrote:
> > >  If a package has gotten very stale, and nobody has taken up
> > >  maintainence, isn't that a pretty good indication that nobody is
> > >  using it anyhow?
> > 
> > Is it? Is the average Debian user both able and willing to be a
> 
> Obviously not. It is a pretty good indication that no developer is using it
> anymore, but just that.

1. Debian Developer are a good sample of the Debian users. Only a
selected group, but it still gives some indication.

2. popularity-contest should also give you a hint.

3. If a package has a bug and is not maintained that can be
noticed. If the bug is release critical, it drops out of stable. Watch
out for those. Clean up those buggy, stale debs first.

4. Check for packages that are outdated compared to upstream
source. Contact upstream if they know someone to maintain it.

But what about stale, unused, bugfree debs that are just perfect
(Yeah, show me one). No newer upsteam and no other indication of
staleness?  First of all its maintainer should know. Would you
maintain a package you don't use? The package should be orphaned when
its not maintained and then go the way of all orphans: get adopted or
grow up and earn your own money. :)

The only way to see if a probably unused package is realy unused is to
remove it and wait for someone to scream. Do you want to listen to all
those screams? Removing a package should be well though about.

MfG
Goswin

PS: I'm all for cleaning up old cruft. Just remember that someones cruft might 
be someone elses dearest.
PPS: NEVER REMVOE MOONBUGGY

Re: Bug#126856: kernel-package: kernel-image should deal with flavours just like modules packages

[martin f krafft]

reopen 126856
severity 126856 serious
thanks

[cc'ing to debian-devel for comments.]
[please refer to bug 126856 for background info.]

also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2002.01.06.1016 +0100]:
>   Wrong. Read the documentation on the Flavours before using
>  it. This is the reason that Flavours are deprecated, incidentally. 

okay, i did read /usr/share/doc/kernel-package/Flavours.gz, but it
really just didn't solve my problem.

the reason that i am objecting to closing this bug is because i have
official debian packages here to compile my kernels and modules, and
what i get out is *broken*. i don't care whether flavours are (going to
be) deprecated, that feature exists with the release of kernel-package
that i have, and thus i should be able to use it. i am thus reopening
the bug as well as raising its severity, not because i want to "catch
attention" or anything, but because kernel-package violates debian
policy!

when i compile the kernel as flavour "fishbowl" and the
kernel-image*.deb package places its modules into /lib/modules/2.4.17,
while proper modules packages like alsa-driver or pcmcia-cs put their
modules in 2.4.17+fishbowl, then there is a problem. without manual
interaction, you won't get the new kernel to see the modules of the
modules package. and that i consider a serious bug!

moreover, the packages compiled with kernel-package actually end up
leaving files on a system that are not registered as belonging to any
packages. these are orphan files, and even though i can't find the
section of the policy manual that addresses this, it seems fairly
obvious that this shouldn't happen. consider a custom kernel
kernel-image-2.4.17+fishbowl and a corresponding package
pcmcia-modules-2.4.17+fishbowl. when the pcmcia package is updated and
apt-get installs the new version on the machine, it not only doesn't
place the modules under /lib/modules/2.4.17 where the kernel modules
reside, it creates a directory for the format
/lib/modules/2.4.17+fishbowl_[0-9]{4}. for instance, this is after
updating the kernel and pcmcia-modules package a couple of times:

fishbowl:~> ls -1 /lib/modules
2.2.20-compact_2169
2.4.17
2.4.17+fishbowl_1344
2.4.17+fishbowl_2634
2.4.17+fishbowl_5736
2.4.17+fishbowl_7652

*but*:

fishbowl:~> dpkg -S /lib/modules/*
kernel-image-2.4.17+fishbowl: /lib/modules/2.4.17

fishbowl:~> dpkg -l | grep "kernel-image\|pcmcia-modules"
ii  kernel-image-2 20020104.1146  Linux kernel binary image 2.4.17+fis
ii  kernel-image-2 20010822.0048  Linux kernel binary image 2.4.5+fish
ii  pcmcia-modules 3.1.29-4+20020 PCMCIA Modules for Linux 2.4.17+fish

first of al, 2.2.20-compact wasn't even compiled by me, but it still
left a directory in /lib/modules that wasn't removed when i purged (!)
kernel-image-2.2.20-compact.

then, not even the installed pcmcia-modules package knows about
2.4.17+fishbowl_7652 in /lib/modules, which it left there. the three
predecessor versions of pcmcia-modules had the same problem and left
orphan files.

so this is pretty much two bugs, the first one has major effects on
usability, the second violates the policy. i don't think this bug is
closed yet.

any comments welcome. thanks.

and maybe someone can suggest an alternative to flavours. i have about
27 systems for which i have kernel-images, using the flavour to specify
the machine name. this works beautifully. without the flavour, i would
not have the possibility to update one machine's kernel and install it
via apt from my own apt-compatible server. i need to be able to do this.
scp'ing and dpkg -i are not options, apt-get upgrade must take care of
this.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
"if beethoven's seventh symphony
 is not by some means abridged,
 it will soon fall into disuse."
 -- philip hale, boston music critic, 1837


pgpcujWbndaMh.pgp
Description: PGP signature

Many .changes not being sent to debian-devel-changes

[Robert Bihlmeyer]

[please CC me on replies]

Hi,

recently, the debian-devel-changes list is missing more .changes
messages than usual. I first suspected a local config change as the
culprit, but

http://lists.debian.org/debian-devel-changes/2002/debian-devel-changes-200201/maillist.html>

doesn't list what I missed, either. A few examples of stuff that did
not show up (I'm using the names under incoming.debian.org/DONE/ in
following):

alien_7.31_i386.changes
fortune-mod_9708-24_i386.changes
guppi_0.40.2-7_i386.changes
mozilla_0.9.7-3_i386.changes(non-us)
openssh_3.0.2p1-2_i386.changes  (non-us)
rsync_2.5.1-0.1_i386.changes

I can dig up more if needed (counting only packages I have installed
I've found 15 today).

Does anyone know what the problem is? The list still gets /some/
changes, and I can't see any pattern in what ends up there and what
doesn't.

This is somewhat inconvenient for me because I use the .changes files
to link packges to a trusted maintainer key (i.e. as external package
signatures).

-- 
Robbe


signature.ng
Description: PGP signature

Re: CHECK BEFORE YOU RETITLE Re: Processed: Retitling...

[Adrian Bunk]

On Sat, 5 Jan 2002, Adam Majer wrote:

> Hey, buddy!! I ITA those packages a while back - I'll be uploading them in 
> the next day!!! PLEASE CHECK THE O LIST
> __BEFORE__ YOU RETITLE A BUG!

Hi Adam,

it seems you misunderstood what Uwe was doing: He did only add the package
descriptions to the WNPP bugs, IOW he changed e.g.
  ITA: gtml
to
  ITA: gtml -- An HTML pre-processor
or
  O: wmf
to
  O: wmf -- Web Mail Folder


These changes are visible e.g. in the wookly work-needing packages report
or at the WNPP pages at [1]. Uwe never intended to adopt any of these
packages.


> - Adam

cu
Adrian

[1] http://www.debian.org/devel/wnpp/

Re: NFS Servers, deadlocks and symlinks

[Bas Zoetekouw]

Hi elf!

You wrote:

> I'll start with the question(s) for the impatient.  Is anyone
> experiencing deadlocks between nfs-kernel-server and ext3?  How about

No, not at all. Using 2.4.17 on potato+bunk. 

> Starting back on the original project, the Etherboot finally succeeded
> The next discovery was that the newly network-booted machine was
> experiencing NFS errors complaining about too many symlinks.  It's
> root filesystem is mounted from server:/tftpboot/seashore which is a
> symlink to /a/dev/sde1/seashore.  I wouldn't expect this to be a
> problem.  Should I?

No, this shouldn't be a problem. I use the same here
(server:/tftpboot/www.xxx.yyy.zzz symlinked to
/export/netboot/machinename). That works quite well.


-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+