Re: VIM features

[Paul Mackinney]

Wichert Akkerman declaimed:
> Previously Caleb Shay wrote:
> > I second this.  For example, at the bottom of /etc/vim/vimrc there are
> > several lines commented out "as they cause vim to behave a lot different
> > from regular vi".  However, as was pointed out below, vim is NOT the
> > default vi when you install, so why not enable some more of it's better
> > features.
> 
> Because I'm not willing to for several reasons:
> 
> 1. every time I enable a feature that makes vim a bit more unlike vi
>I get multiple bugreports
> 2. vim is very well documented, if people want to try any of its
>features they can trivially enable them themselves
> 3. which features you want enabled is a very personal choice, one that I
>am not willing to make for users. So I'll always pick the choice
>that makes vim more like stock vi. This keeps things consistent
>and prevents endless debates.

I don't at all mind having a vimrc file with lines commented out that
the user can enable. Note that this is the strategy for bash.

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.

-- 
Paul Mackinney   |   Another look at Sept 11
[EMAIL PROTECTED]   |   http://www.copvcia.com/

Re: Debian.rpm

[Tollef Fog Heen]

* Wichert Akkerman 

| Previously David B Harris wrote:
| > Well, what you're suggesting isn't really feasible ;)
| 
| Someone actually did this a couple of years ago so it is feasible.

Run-time upgrading from RH to Debian is very much feasible and very,
very cool.  No reboot required, even.

It was a bit scary doing it to my home system which will only boot
from the hard drive, no floppy, and won't boot from the cdrom,
though. :)

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

Re: Debian.rpm

[David Graham]

Debian.rpm would be very cool. And very portable!

system:~# alien --to-deb Debian.rpm ; dpkg --install Debian.deb

:)

David Graham
[EMAIL PROTECTED]

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

[Egon Willighagen]

On Sunday 6 January 2002 08:51, Egon Willighagen wrote:
> On Saturday 5 January 2002 00:24, Karl M. Hegbloom wrote:
> >  Wow, now that's really cool.  What I'm wondering is, can "apt-get",
> >  "dpkg", and friends recover this easily from a device overflow?  Was
> >  that thought of during their design and implementation?  If it needs
> >  a little more space in "/var" or "/usr", can it notice that before
> >  filling the block device, and prompt me about it, so I can make some
> >  room somehow?  (either by removing files, dpkg --purging something,
> >  or using the LVM tools to extend the logical volume and then the
> >  filesystem utility to grow the filesystem.)
>
> That is funny. I had just this problem yesterday... I "apt-get upgrade"-ed
> and my HD was full... and now my system is in dubious state...
> Missing KDE icons. Or actually, i think this is caused by a versioning
> problem that is caused by the upgrade:
>
> libpng warning: Application was compiled with png.h from libpng-1.0.12
> libpng warning: Application  is  running with png.c from libpng-1.2.1
> libpng error: Incompatible libpng version in application and library
>
> I guess packages are only partly upgraded. Some files are, others are
> not... I can only fear what other incompatibilities are caused by the
> upgrade.

Actually, i have just read a debian-kde message about the PNG problem... That 
seems to be a KDE specific problem.

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?

Egon

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

[Egon Willighagen]

On Saturday 5 January 2002 00:24, Karl M. Hegbloom wrote:
>  Wow, now that's really cool.  What I'm wondering is, can "apt-get",
>  "dpkg", and friends recover this easily from a device overflow?  Was
>  that thought of during their design and implementation?  If it needs
>  a little more space in "/var" or "/usr", can it notice that before
>  filling the block device, and prompt me about it, so I can make some
>  room somehow?  (either by removing files, dpkg --purging something,
>  or using the LVM tools to extend the logical volume and then the
>  filesystem utility to grow the filesystem.)

That is funny. I had just this problem yesterday... I "apt-get upgrade"-ed
and my HD was full... and now my system is in dubious state... 
Missing KDE icons. Or actually, i think this is caused by a versioning 
problem that is caused by the upgrade:

libpng warning: Application was compiled with png.h from libpng-1.0.12
libpng warning: Application  is  running with png.c from libpng-1.2.1
libpng error: Incompatible libpng version in application and library

I guess packages are only partly upgraded. Some files are, others are not...
I can only fear what other incompatibilities are caused by the upgrade.

Now, I am facing the following problem (after making more space):

- how can i determine which packages were updated yesterday?
- how can i (semi)-automatically reinstall these packages?

In the mean time i filed a bug (#127942) against apt for loss of non-critical 
data. It can be argued wether it is loss or not, but anyway, my systems 
expects files that are not installed, and thus are missing IMHO...

Egon

NFS Servers, deadlocks and symlinks

[elf]

I'll start with the question(s) for the impatient.  Is anyone
experiencing deadlocks between nfs-kernel-server and ext3?  How about
symlink errors using nfs-user-server?  There is nothing in the debian
bugs database about either of these problems.  Nor is there anything
about the ext3 deadlock in google.

Background.

I've been using the kernel server for nearly a year to provice NFS to
an NCD xterm.  It worked fine.  This afternoon, while experimenting
with Etherboot and it's need for an NFS server, a reiserfs partition I
was using refused to

  mv bin ..

where bin was a directory.  The machine deadlocked, forcing me to
reboot and wait 45 minutes while the raid fsck'd.  After the second go
at this, I decided it was time to enable journaling on the ext2
partitions.  The discovery was that when I enabled ext3 on the
partition that the NCD was NFS mounting to, the NFS mount would
deadlock the machine.  Switching to the nfs-user-server eliminated the
deadlock.  (A toast to apt-get.)

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?

Re: dpkg-cross maintenance status

[Steve Langasek]

On Sat, Jan 05, 2002 at 09:44:16AM +0900, YAEGASHI Takeshi wrote:

> At Thu, 03 Jan 2002 21:07:33 -0700,
> Matt Taggart wrote:

> > > Is there anyone who utilize dpkg-cross?

> > I used it for bootstrapping Debian on hppa, it's *very* useful. I didn't 
> > need 
> > to make too many changes. I still need to submit a patch for hppa support. 
> > At 
> > the time I was too distracted by having a native toolchain to spend time on 
> > dpkg-cross patches :)

> > The things I changed for hppa are available at,
> > http://cvs.parisc-linux.org/build-tools/dpkg-cross/

> That's right, I know its usefulness as well as you.  I worked with
> dpkg-cross for binary-sh bootstrapping last spring. That effort
> resulted in the Dreamcast Linux Distribution later.

> We must have accumulated numerous improvements and much know-how on
> dpkg-cross through such a rare experience as bootstrapping Debian for
> the brand-new architecture.

> I simply feel it regrettable to leave them being lost.  We should
> share them.

If there is renewed interest in improving dpkg-cross, there are a few 
issues yet with building multi-binary packages that include libraries 
that I'd be happy to help work out.

Cheers,
Steve Langasek
postmodern programmer


pgpJQ1dJAY9Lv.pgp
Description: PGP signature

Re: dpkg-cross maintenance status

[David Schleef]

On Sat, Jan 05, 2002 at 09:44:16AM +0900, YAEGASHI Takeshi wrote:
> 
> Yes, for embedded platforms with limited resources cross compling is
> quite important, especially when you want to build a large set of
> software such as Debian distrubution.
> 
> But as you know we currently have much troubule with cross building
> Debian packages, even though most of the problem can be easily solved
> with a few changes.
> 
> I often feel that most source packages might have a bit more cross
> compile awareness.  Of course I should report that to the BTS to the
> extent not annoying maintainers.

I've been fixing packages when I notice problems, and sending the
patches to the maintainer.  Most maintainers understand the
usefulness of cross-compiling.  Perhaps some day, we might have
cross-compiling as part of Debian policy (or at least a tag for
cross-compiliability), but I certainly wouldn't advocate that now,
as it would cause too much turmoil.

However, I'm almost to the point of getting a cross autobuilder set
up, so one of the results of that will at least be a list of packages
that cross compile.



dave...

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

[Adam Majer]

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!

- Adam


On Fri, Jan 04, 2002 at 03:03:14PM -0600, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
> 
> > retitle 123477 ITA: gtml -- An HTML pre-processor
> Bug#123477: ITA: gtml
> Changed Bug title.
> 
> > retitle 123480 ITA: yiff -- A network based and multi client connection 
> > system
> Bug#123480: ITA: Yiff
> Changed Bug title.
> 
> > retitle 123491 ITA: libhoard -- Fast memory allocation library
> Bug#123491: ITA: libhoard
> Changed Bug title.
> 
> > retitle 123508 ITA: xshipwars -- Dynamic space-oriented gaming system
> Bug#123508: ITA: xshipwars: Dynamic space-oriented gamming system
> Changed Bug title.
> 
> > retitle 123509 ITA: xshipwars-images-st -- Image Collection for XShipWars
> Bug#123509: ITA: xshipwars-images-st: Image Collection for XShipWars
> Changed Bug title.
> 
> > retitle 125886 ITA: xshipwars-sounds-st -- Sound Collection for XShipWars
> Bug#125886: ITA: xshipwars-sounds-st
> Changed Bug title.
> 
> > retitle 126198 O: saml -- Simple Algebraic Math Library
> Bug#126198: ITA: saml
> Changed Bug title.
> 

> Please contact me if you need assistance.
> 
> Debian bug tracking system administrator
> (administrator, Debian Bugs database)

Re: Some thoughts about problems within Debian

[Anthony Towns]

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:
> > > I agree completely. With our current testing setup this shouldn't be too
> > > difficult to do. 
> > 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.

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
difficult to get the rest working: packages with bugs (and things that depend
on them) can just be dropped. Dropping glibc, base-passwd, and postgresql,
otoh, would all cause complaints, I think.

> > You can solve this by *completely ignoring* the extra set of packages
> > (ie not distributing them at all), but you can't divide them up and get
> > rid of the complexity, particularly.
> Once again I agree. And I do not think ignoring extra makes sense at all.
> It's just that an extra package should not prevent us from a new "core"
> release.

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.

And in another sense, they absolutely have to: you can't just update
python and ignore the fact that that makes (eg) postgresql uninstallable
and useless, and release the new python and expect people to just
uninstall postgres and sing happy songs. For "postgresql" read any `extra'
package that people use.

> How about a new "core" consisting of base/standard every 6 months
> and a new full release every year. The full release could then be based on
> the next to last "core" release.

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

> > > Use Debian GNU/Linux! Use PostgreSQL!
> > For example, postgresql has a bunch of serious and grave bugs that've
> > been open for over a month, that, afaict, no one's doing anything about,
> That's new to me. Yes, I've been too busy to follow thinks closely enough,
> but the last time I checked therer was just one about an upgrade problem.

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

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/


pgpcIQbDcSaVi.pgp
Description: PGP signature

re vlc

[Jack Howarth]

Branden,
Nevermind. I just heard back from Samuel Hocevar and he is aware 
of the problem and will fix it in the next build. I got thrown for
a loop because there was a crashing bug not fixed in vlc until 0.2.92-7
(which isn't in sid ppc yet) and local builds were failing (because
of xlibs-pics being installed). These two unrelated problems confused
the situation for me.
   Jack

vlc, sdl and xlibs-pic conflict

[Jack Howarth]

Branden,
   I guess I'm just a tad thick here but I don't understand 
the rational for the following conflict. My debian ppc sid
machine is current for all the packages in sid and has xlibs-pic
installed as well. I discovered that when I tried to do...

apt-get -b source vlc

for the latest vlc-0.2.92-7 package to build locally that I got
a failure in the link. The problem disappears when I deinstall
xlibs-pic and then try rebuilding vlc again. The difference seems
to be that when xlibs-pic is installed I get a build with...

gcc -fPIC -o ../sdl.so sdl.o vout_sdl.o aout_sdl.o -shared -L/usr/lib
-lSDL -lpthread -L/usr/X11R6/lib -lXxf86dga_pic -lXxf86vm_pic -lXv_pic

which causes a link failure on vlc later on with unresolved symbols
from those static pic libs whereas when xlibs-pic is deinstalled I get...

gcc -fPIC -o ../sdl.so sdl.o vout_sdl.o aout_sdl.o -shared -L/usr/lib
-lSDL -lpthread -L/usr/X11R6/lib 

and I get no link failures on vlc. I assume this is a flaw in vlc where
the static pic libs are being incorrectly linked into a shared lib
instead of the final program itself. I have passed this info onto the
vlc maintainer but since you did the sdl NMU and I assume this link
command is created using sdl-config, I thought you should be in the loop.
Perhaps xlibs-pic should be installed on all the build machines when
programs that link to libsdl1.2 are built so we can tickle this bug
and identity all the programs that need to be fixed. Call me silly but
it seems to me a program shouldn't have a build failure just because
xlibs-pic is installed.
  Jack
ps No more postings to announcements please (grin).

Re: Some thoughts about problems within Debian

[Adam Majer]

On Sat, Jan 05, 2002 at 04:43:10PM +0100, Tollef Fog Heen wrote:
> * Adam Majer 
> | clear.. For even a novice admin that is... After all, isn't admins
> | or admin-wanna-bees what are installing a new system anyway? IMHO, I
> | don't think that there is anything too cryptic being asked for
> | desktop installation...
> 
> 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.

Well, the defaults are usually the correct choice anyway.. Some questions for 
setting up X might be a bit criptic but 
that is X and it would be very difficult to get them more "user friendly".

- Adam

Re: VIM features

[Steve Greenland]

On 01-Jan-02, 18:06 (CST), Steve Greenland <[EMAIL PROTECTED]> wrote: 
> Also, vim is higher precedence than nvi.

Ack. That's no longer true. Sorry.

Steve

Any archive of pre-slink nonus sources?

[Jesus M.]

Hi,

I've been looking at ftp://archive.debian.org, ftp://nonus.debian.org
and other sites and I have not found nonus source packages for Debian
distributions older than slink (hamm, bo, etc.) (In fact, I have found
no packages at all).

Any idea about where can I find them?

Saludos,

Jesus.

-- 
Jesus M. Gonzalez Barahona| Grupo de Sistemas y
Comunicaciones
[EMAIL PROTECTED] / [EMAIL PROTECTED] | ESCET, Universidad Rey Juan
Carlos 
tel: +34 91 664 74 67 | c/ Tulipan s/n
fax: +34 91 664 74 90 | 28933 Mostoles, Spain


pgpXpQecbgRyI.pgp
Description: PGP signature

Re: X autoconf

[Petter Reinholdtsen]

[Sergio Rua]
>   I've a python script to autoconfigure X. It tries to configure
>   your X server using FrameBuffer. If it's not available, using
>   "XFree -configure" option detect and configure your X.

This sounds like a very good idea.  How do you pass the configuration
information on to the official config script?

>   It needs 2 external C programs: 
>   
>   myfbset:show framebuffer geometry
>   mousedetect:detect your mouse

Is mousedetect the same as mdetect?

>   Mouse detection don't work perfectly because it's very difficult
>   to distinguish USB from PS2. It needs to be rewrited. This program 
>   uses libdetect. I test with libkudzu of redhat and libdiscover
>   with the same results.
> 
>   This script was developed by me to a spanish linux distribution
>   called Esware (www.esware.com) where I work. GPL, of course.
> 
> 
>   You can download it from: http://people.debian.org/~srua/Xconfig

Thanks.  I'll have a look at this for use in Norway as well. :-)

Still no fam in Woody

[Petter Reinholdtsen]

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?

stat vs stat64 - ugly problem

[David N. Welton]

FILE 1

#include "httpd.h"
#include 

int main() {
struct stat foo;
printf("size of stat __pad1 is %d\n", sizeof(foo.__pad1));
}

FILE 2

#include 
#include "httpd.h"

int main() {
struct stat foo;
printf("size of stat __pad1 is %d\n", sizeof(foo.__pad1));
}

These produce different code, because of #define _FILE_OFFSET_BITS 64
in /usr/include/apache-1.3/ap_config_auto.h.

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)...

Hrm...
-- 
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: Theory

[Robert Jördens]

Hello!

On Sam, 05 Jan 2002, Robert Jördens produced 5,8K chars torturing the keyboard:

> And: Did I reinvent the wheel?

I guess, I did.

It was:
30 Aug 2000 - 31 Aug 2000 (10 posts): 
Crazy idea: removing version numbers from debian

But then: Lets bring it up again. My idea is much more far reaching ;-]


- Can't we have the one without losing the other? I mean having those
  floating releases and on top of that officially announced and promoted
  releases (may be even every 6 months or oriented on different release
  goals). Times or goals as distros is so much similar to
  stable,unstable,testing on top of package pools. 

- 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. ;-]

- What if the need for stability increases on a system (the
  stability-value of the system increases or the stability of a packges
  version decreases because a bug is found): Is a downgrade in version
  and upgrade in stability of a package a big deal?  Is this a problem?
  Or isn't this rather something we _have_ to support better anyway,
  because it happens too in real life if you build/install from source
  and maybe discover a bug and then downgrade?

- Support: Should not become more complicated because we are already
  supporting different versions of a package and different "clusters" of
  interdependent packages at the same time with stable/frozen/testing.
  The BTS is prepared. The archive is prepared.

- "Synchronizing the dependency graph globally": Isn't that already done
  with correct and versioned dependencies and the stability-value.

- I believe that we really need the stability-value anyway. Although
  this will be really tough, a clear mathematical definition of
  stability is needed everywhere. At the moment we have a pretty sloppy
  and fuzzy one: Personal opinion of archive maintainers (time of
  upload, no new features but bugfixes), number of bugs and time for
  testing.

- I don't know the process to well yet. But AFAICS the following things
  would have to be done:

   + Add the "Stability:" field to Packages.gz (for the pool). This is
   the only place it belongs. We don't want to poke into the binaries
   every time a bug is discovered.

   + Discuss, write and set up the rating system.

   + Remove that distribution field in debian/changelog and .changes
   Isn't its role fainting with package pools anyway?

   + Make apt/dpkg aware of the field, its implications and write a
   frontend to the desired stability-value.

   + Reorganise the archive. Set up distros as symlink-collections to
   depending on stability and time.

   + Reorganise the upload process.


And yet again some thoughts about the rating system:

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

- Maintainers must be "honest" about added features and fixed bugs. Add
  something analogous to "Closes: Bug" ("Opens: Feature" ?) to the
  changelog. "Severity" of added features? Inverse BTS (FTS)? Funny
  idea.

- We would have to take initial Stability values from the distro a
  version is in. 

- The rating of stability is a problem. ;-]

Robert. 

-- 
Cult of Aloneness:
The need for autonomy at all costs, usually at the expense of
long-term relationships.  Often brought about by overly high
expectations of others.
-- Douglas Coupland, "Generation X: Tales for an Accelerated
   Culture"


pgpbYWWX3gUZ1.pgp
Description: PGP signature

.dsc not generated during package build?

[Yves Arrouye]

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):

dh_builddeb
dpkg-deb: building package `libicu-dev' in `../libicu-dev_2.0-1_i386.deb'.
dpkg-deb: building package `icu-doc' in `../icu-doc_2.0-1_all.deb'.
dpkg-deb: building package `libicu20' in `../libicu20_2.0-1_i386.deb'.
dpkg-deb: building package `icu' in `../icu_2.0-1_i386.deb'.
dpkg-deb: building package `icu-locales' in `../icu-locales_2.0-1_i386.deb'.
dpkg-deb: building package `icu-data' in `../icu-data_2.0-1_all.deb'.
dpkg-deb: building package `icu-i18ndata' in
`../icu-i18ndata_2.0-1_all.deb'.
 signfile icu_2.0-1.dsc
cat: ../icu_2.0-1.dsc: No such file or directory

You need a passphrase to unlock the secret key for
user: "Yves Arrouye <[EMAIL PROTECTED]>"
1024-bit DSA key, ID 63D2C165, created 1999-09-26

  
 dpkg-genchanges
dpkg-genchanges: error: syntax error in source control file ../icu_2.0-1.dsc
at line 92: empty file
gabier% wc -l ../icu_2.0-1.dsc
32
gabier%

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

Thanks,
YA
--
My opinions do not necessarily reflect my company's.
The opposite is also true.

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

[Marcus Brinkmann]

On Wed, Jan 02, 2002 at 11:55:52PM +0100, Tollef Fog Heen wrote:
> * Wichert Akkerman 
> 
> | Previously Kevin Corry wrote:
> | > Could the "ldconfig" call be added to the top-level Makefile "install"
> | > target?
> | 
> | No, since you might not be installing on a real system but a temporary
> | location to build a package or for some other reason. Also if you
> | are not running as root but with fakeroot ldconfig will fail.
> 
> In which case «ldconfig -n $libdir» should work just fine.

But ldconfig is something only available on GNU/Linux system, and clearly
the wrong tool for the job.

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).

I have never understood why some people want to use ldconfig -n in package
builds.  ldconfig is a tool that enhances the systems run time loader on
GNU/Linux, not the compilers linker.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

Theory

[Robert Jördens]

Hello!

I'm a little reluctant about speaking with this to this huge
blood-hungry crowd, since this is my first post and I'm starting right
out with something that will be either seen as totally stupid or totally
awesome. In short: this will polarize.

Debian-devel and linux-kernel are both heavily arguing about release
policy at the moment. Arguing in a way they have never been arguing
before. More brutal, more agressive.

I believe that in both cases it's the same problem. The tradeoff between
stability and features. It's hard to tell what is stable and what is not
supposed to be used on production systems yet. This is a problem that
will never be solved. But if you think about it and aknowledge that
tradeoff you might want to use it as a key policy for releases. And:
Isn't "release" actually something stupid: Why do we have to release it?
Who is holding what, so that we have to free and release it?

So why not abandoning releases (distributions in the debian sense) at
all? Can't we have many (infinitely many) distributions at the same
time? 


Meaning: 

- Lets give each package a new field describing it's stability.  A field
  that - lets say - ranges from 0 to 10 (float?). I think we will find a
  way to calculate that stability (testing has made the first steps
  towards such an algorithm. I'm sure that this algorithm can be
  extended, see below).

- Then let every maintainer upload and maintain as many different
  versions of his package as he desires. I guess that about five would
  be enough for the most packages.

- package-pools is a huge step forward towards abandoning the
  distribution idea. Distributions are now simply masks on top of the
  pool. What they masquerade is determined by such words as "freeze",
  "rc-bugs", "in testing".

- Then simply ask the admin what stability he desires: 0-10

- The dependency system will pretty much do the rest. It can solve all
  the problems like: "a" (available with stabilities of 1,3,5 and
  versions of 1.0.0-1, 0.2.1-1, 0.1.0-2) depends
  on "b" (s=1,4,10 | v=2.0.0-1,1.0.0-3,0.0.2-1) with version of "b" >=
  (2.0.0-1,2.0.0-1,1.0.0-3) [for the respective versions of "a"].
  Now the admin wants stability of at least 3. He wants "a": a_0.2.1-1
  could be installed but depends on "b" >= 2.0.0-1 which has a stability
  of 1. So a_0.1.0-2 and b_1.0.0-3 will be installed. Both fullfill the
  stability ceteria and their dependencies.


Some conclusions:

- This system doesn't introduce more problems. Like the current policy,
  a package that is stable enough for itself wont make it onto the
  system if its version depends on a package which is not available in
  the desired stability.

- Only one thing will go away: The cyclic wave of buzzing, fixing
  rc-bugs and complaining about them. We would have to make sure that
  there is still some motivation to fix bugs apart from the fact that
  there is an upcoming or running freeze!

- Admins would be happy. They could have their own distribution with a
  stability and featuredness they want. No painful decision between
  testing and stable. Wouldn't you be happy if you could take a few
  packages from unstable because of added features and keep the rest 
  from stable because of stability?

- "Incremental (beta/alpha)-testing" would be possible. Isn't it pretty
  much impossible to have a system running "unstable" at the moment.

- In the transition phase (and afterwards too) there would still be
  (cosmetic) distributions, lets say stable (s>=7), testing (s>=5),
  unstable (s>=2) and experimental (s>=0). frozen would disappear.

- We would have to enforce the exactness of dependencies. Has to be done
  anyway.

- There wouldn't be such a big deal with delayed releases and
  forever-taking freezes. They simply dont't exist or happen every
  second depending on the way you look at it.

- Noone would ask for a "strict 6-month-release-cycle". ;-]

Some thoughts about the stability algorithm:

- Added features reduce stability
- Open Bugs reduce stability
- Time in the various lower stabilities without new bugs increases
  stability
- Karma of Maintainer increases stability (??)
- What about a voting/rating system for each package where systems, the
  package is installed on, vote for it's stability?

[Yes I know: Define "added features", "increases", "decreases"! This is
the tricky part ;-]


Random thoughts:

- This approach doesn't make much sense for linux-kernel. There is no
  simple way of maintaining the kernel in "parts". But for Debian there
  is. We have dependencies as the only (and natural) relationship
  between the parts.  And the package-pool itself is so much simpler to
  maintain in parts than the entire mess about patches sent around with
  the kernel.

- This is somewhat similar to the moderation idea behind slashdot.

- ... and simply an extension of the testing-idea.

- Space considerations.

- I don't think this is to complex and non-intuitive. Isn't this the
  process, every admin is going th

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

[Martin Michlmayr]

* Adam Majer <[EMAIL PROTECTED]> [20020105 19:54]:
> 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!

Can you calm down and wrap your lines properly?

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: EURO and CENT signs in the console keymaps

[Josip Rodin]

On Fri, Jan 04, 2002 at 09:29:34PM +0200, Juha Jäykkä wrote:
> > But is doesn't have an AltGr key...
> 
>   I would say, AltGr is which ever key functions as Mode_switch. AltGr
> just something printed on the key functioning as Mode_switch on some
> keyboards. For example, I have CapsLock functioning as Mode_switch as
> well.

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.

-- 
 2. That which causes joy or happiness.

Re: EURO and CENT signs in the console keymaps

[Herbert Xu]

Branden Robinson <[EMAIL PROTECTED]> wrote:

> On Fri, Jan 04, 2002 at 07:54:16PM +1100, Herbert Xu wrote:
>> You can now get POSIX online for free...

> URL?

Subscribe at

http://www.opengroup.org/austin/
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Adrian Bunk]

On Fri, 4 Jan 2002, Steve Greenland wrote:

> > If every system had up-to-date, standards-conforming
> > ctype.h support, we wouldn't have to worry much at all.
> > But even these days, pretty many systems with buggy macros
> > are still in use.
>
> Then fix those systems. Pull the necessary stuff out of glibc and use
> it rather than the system headers/libc.

You need to do this in a portable way so that it works on every system...

> > FYI, as far as I know, the most portable way to use
> > the ctype macros is to define wrapper macros
> > (e.g., like those below, from fileutils/src/sys2.h)
> > and then use only the wrappers (upper-case names) from your code.
>
> 
> What an abomination. I spent way too much of my youth doing crap like
> this. I'm tired of it. The standard has been in place for 12 fscking
> years. If the vendors aren't going to support it, then those systems
> are dead. I've better things to do with my time than make ugly code to
> support systems that haven't been upgraded for over a decade.
> 

It's the choice of the author of a program whether he wants to support
older systems or not - and if he wants to support older systems (and many
older systems are still running) or systems that don't confirm to a
standard he won't accept patches that limit the number of systems his
program runs on. I remember that e.g. many GNU programs still support
pre-ANSI C compilers.

> Steve

cu
Adrian

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

[Adrian Bunk]

On Sun, 6 Jan 2002, 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?

Do you mean with "my HD was full" that "df" says that it's used 100% ?
If yes then your HD isn't physically full, usually 5% of the blocks in a
partition are reserved - this means they aren't counted when "df"
estimates how many space is free on the device and only root can write to
the device if not more than the number of reserved blocks are free. Since
you did run dpkg as root you can write additional files to the partition
even though the partition is full.

> Egon

cu
Adrian

Re: NFS Servers, deadlocks and symlinks

[Hamish Moffatt]

On Sat, Jan 05, 2002 at 11:19:30PM -0800, [EMAIL PROTECTED] wrote:
> I'll start with the question(s) for the impatient.  Is anyone
> experiencing deadlocks between nfs-kernel-server and ext3?  How about
> symlink errors using nfs-user-server?  There is nothing in the debian
> bugs database about either of these problems.  Nor is there anything
> about the ext3 deadlock in google.

This seems like a great question for debian-user, but not debian-devel.

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

Can you symlink /tftpboot to /a/dev/sde1 instead? I have that
configuration working fine here (booting a linux PC with etherboot,
on ext2, with the user-space NFS server).


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Evolution and GnuPG

[Oliver Elphick]

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 


pgpaRtJ8JMNP1.pgp
Description: PGP signature

apt-get reinstall all

[Michael De Nil]

Hi

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

Greetz
Michael


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

---
Michael De Nil -- [EMAIL PROTECTED]
   Linux LiSa 2.4.17 #6 SMP Sun Jan 6 11:55:25 CET 2002 i686
 12:40:01 up 32 min,  4 users,  load average: 0.70, 0.61, 0.35
---

Re: Some thoughts about problems within Debian

[Bas Zoetekouw]

Hi Tollef!

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.

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

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

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/

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

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

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

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.

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

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

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

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

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.

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

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

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: 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: .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: 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: 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

[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: 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: 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

[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

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: 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.

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

[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: 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: 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: 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: 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: 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: 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: 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: 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

[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: 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: 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: 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: 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

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: 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  |
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+

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: 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: 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: 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: 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: .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: [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: 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: 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: 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: 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: 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: 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: 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: 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

[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: 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...

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

[bc°É]

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.

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: [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: 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/

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

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