Bug#195948: URL for workaround list

[Mark Nipper]

Package: wnpp
Followup-For: Bug #195948
Owner: Mark Nipper <[EMAIL PROTECTED]>

Just in case someone gets to the end here like I did and
is wondering where the workaround list is, the URL is:
---
http://workaround.org/pipermail/dspam-debian/

Hopefully that is okay to give out.  Wasn't too tough to find
but I thought I'd save others the trouble.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#291562: i wish to package openev for debian

[alex bodnaru]

Package: wnpp
Followup-For: Bug #291562
Owner: alex bodnaru <[EMAIL PROTECTED]>

in the process of debianizing postgis,
i wish to package openev for debian.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-686-smp-skas3-v7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: gcc 4.1 with stack smashing protection in etch?

[Andrew M.A. Cater]

On Wed, Oct 19, 2005 at 11:45:21PM +0200, Michael Meyer wrote:
> Hi,
> now that Steve Langasek has published July 30th as the
> toolchain freeze, do you already know if you will
> include   gcc 4.1 instead of 4.0 as the standard gcc
> in etch? If yes, etch could profit from the
> ProPolice-like stack smashing protection in gcc 4.1.
Let's see it first :)  There is currently a transition 
going on to get GCC 4.0x as the default compiler
across all architectures that Debian supports. That
takes a long time :( 4.1 is currently in stage 3 - if
I'm reading the GCC site properly - which means it will be
out round about December??

Chances are good for it to be in for July/August then for
Etch freeze. As ever, wait and see :)

> If it will be 4.1, will every debian package
> automatically be compiled with the SSP in etch? Or is
> a certain compile-flag needed to be activated, which
> won't be the default in etch?

Let's see what SSP breaks in terms of old code _first_ :)

> It seems that Redhat will release RHEL 5 in the end of
> 2006 with a gcc 4.1 compiler. 

Ignore Red Hat - they released 2.96, remember, and GCC that
couldn't compile a kernel.  In Red Hat Enterprise Linux 4 they released
with 3.4.x _and_ a pre-release alpha quality snapshot from December 12
2004 for 4.x - fully three months before 4.x was released.

If you want cutting edge compilers that just don't work, use Red Hat
IMHO.

Andy
> cheers, 
> mike.
> 
> 
>   
> 
>   
>   
> ___ 
> Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: 
> http://mail.yahoo.de
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


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

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 07, 2005 at 11:18:57AM -0700, Russ Allbery wrote:

>  * Obtain the system host name with gethostname().
>  * Look up an IP address for that host with gethostbyname().

The bug is here. This is completely wrong but sadly very common
practice. It is common because it is portable and works with some simple
configurations (namely, single-homed machines with static IP address).

>  * Look up the names associated with that address with gethostbyaddr().
>  * Walk the alias list of the result and find the first name containing
>a period.

The proper fix would be to enumerate all IP addresses of all network
interfaces and select one that has an appropriate name. Unfortunately
this is non-trivial and highly OS-dependent, although the libdumbnet1
package provides a platform-independent API for this (among other
things).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 07, 2005 at 04:15:18PM +0200, Christoph Haas wrote:

> MySQL definitely chokes on localhost.localdomain. And although MySQL will
> adopt to distributions using "localhost.localdomain" instead of "localhost"
> doesn't mean it's correct. MySQL by default expects "localhost" as the
> hostname assigned to the loopback interface.

No, MySQL is happy to use whatever name the loopback interface has; it
is the MySQL _documentation_ that stresses the "localhost" string
without mentioning that it depends on the naming service configuration.

So the bug is that the documentation does not describe what the code
really does; you have to fix one or the other. Upstream went with
modifying the code rather than the documentation, and I agree with them.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 13, 2005 at 12:35:11PM -0700, Jeff Stevens wrote:

> 1 -- When configuring DNS, 127.0.0.1 must resolve to localhost and vice
> versa [1].

No, the RFC does not say "must", it only says "should" (and it is not
even a "SHOULD").

And regardless if localhost.localdomain is removed from /etc/hosts or
not, finding & fixing applications that choke on it is a good thing.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: localhost.localdomain

[Olaf van der Spek]

On 10/20/05, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> The proper fix would be to enumerate all IP addresses of all network
> interfaces and select one that has an appropriate name. Unfortunately
> this is non-trivial and highly OS-dependent, although the libdumbnet1
> package provides a platform-independent API for this (among other
> things).

Wouldn't the proper fix be to not use source address based authentication?

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 20, 2005 at 04:16:40PM +0200, Olaf van der Spek wrote:

> Wouldn't the proper fix be to not use source address based authentication?

This is not authentication. INN just need a string to uniquely identify
a host. Using a FQDN is OK, it's just the way of obtaining that FQDN
that is problematic.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: localhost.localdomain

[Olaf van der Spek]

On 10/20/05, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 20, 2005 at 04:16:40PM +0200, Olaf van der Spek wrote:
>
> > Wouldn't the proper fix be to not use source address based authentication?
>
> This is not authentication. INN just need a string to uniquely identify
> a host. Using a FQDN is OK, it's just the way of obtaining that FQDN
> that is problematic.

Ah, I was thinking about the MySQL case.

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 14, 2005 at 03:25:53AM -0500, Peter Samuelson wrote:

> Well, that's not quite true.  As someone else pointed out earlier, AIX
> lists "loopback localhost".

On a fresh OpenBSD 3.7 install:

::1 localhost.home localhost
127.0.0.1 localhost.home localhost

("home" is the domain used on my vmware intranet). So "localhost" is not
the first alias here either.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: localhost.localdomain

[Christoph Haas]

On Thursday 20 October 2005 16:01, Gabor Gombas wrote:
> On Fri, Oct 07, 2005 at 04:15:18PM +0200, Christoph Haas wrote:
> > MySQL definitely chokes on localhost.localdomain. And although MySQL
> > will adopt to distributions using "localhost.localdomain" instead of
> > "localhost" doesn't mean it's correct. MySQL by default expects
> > "localhost" as the hostname assigned to the loopback interface.
>
> No, MySQL is happy to use whatever name the loopback interface has; it
> is the MySQL _documentation_ that stresses the "localhost" string
> without mentioning that it depends on the naming service configuration.

Thanks for the clarification. Since I didn't feel like reading the source
code of MySQL I relied on its documentation. And it was a bit confusing
(not only to me). So MySQL is happy with whatever name is bound to the
lo interface. Good to know.

Regards
 Christoph


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

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Do den 20. Okt 2005 um 16:01 schrieb Gabor Gombas:
> No, MySQL is happy to use whatever name the loopback interface has; it
> is the MySQL _documentation_ that stresses the "localhost" string
> without mentioning that it depends on the naming service configuration.

Thats not completely true. MySQL use the name "localhost" to select a
other connection methode (socket). If you use the ip or
localhost.localdomain it tries to connect bei network which is much
slower.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ1exOJ+OKpjRpO3lAQJH0wf/UTwNaQcI/4mhcLj4o/ZhgfJNXFSUyroM
Ok/mkrwpww/4LPjD4ZnsgmZVi/MWScfO4eFNm29Tc+K5aHrbvxqqEpIFXXDuLiHb
IvZZXxyRAkO5RD/M0Jjo9oxmLl7GpQy4yIQn3KCSSLu6b4TtoOv9ZZt0Mh67x60W
MujnKp90NJEDsHGfAFYvBSpzewYevEH6nCG543YfKq66FwniAKQAyCPelWbWgwx3
aCf71In8PxIrZoZw5K6PGG8vgEH/gBnwJoxGZdqHgufyUx34O9QY0SakTdUc/A+g
xfnUR1FLj1w+HE9Pe2oADBwlqNDN6kF0octUnGPQlkeu6trrDMm7AA==
=vGLk
-END PGP SIGNATURE-


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

Re: NMU policies for etch

[wieseltux23]

Henrique de Moraes Holschuh wrote:

>On Wed, 19 Oct 2005, Steve Langasek wrote:
>  
>
>>On Tue, Oct 18, 2005 at 10:28:55AM +0200, Frank Küster wrote:
>>
>>
>>>Steve Langasek <[EMAIL PROTECTED]> wrote:
>>>  
>>>
- don't NMU for feature requests (i.e., wishlist bugs) without the
  maintainer's prior approval


>>>Shouldn't NMU's without the maintainers approval be restricted to RC and
>>>maybe important bugs?
>>>  
>>>
>>Isn't that my question? :)
>>
>>
>
>Well, IMHO only if we want to increase the hostile takeovers. What could be
>easily solved with a few NMUs will get much uglier.
>
>Note that I am all for going postal over anyone that breaks an essential
>package or does something equally stupid in an NMU.
>
>There is one thing that should be mandatory on all NMUs, though. It must be
>built inside a *CLEAN* pbuilder chroot for whichever distro the NMU is going
>to be uploaded to.  low-disk-IO autobuilder-style chroots where packages are
>installed and removed and sometimes leave breakage behind do NOT count.
>
>  
>
TRY IT!! https://www.scientificlinux.org/


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

ITP: zim -- a desktop wiki

[Emfox Zhou]

Package: wnpp
Severity: wishlist

Package name: Zim
Version:0.0.5
Homepage:   http://zoidberg.student.utwente.nl/zim/
License:Perl License
Description:  a desktop wiki

Zim is a WYSIWYG text editor written in Gtk2-Perl. It aims at bringing
the concept of a wiki to your desktop. For example every page is saved
as a text file with wiki markup. Pages can contain links to other
pages, and are saved automatically. Creating a new page is as easy as
linking to a non-existing page. This tool is intended to keep track of
TODO lists or serve as a personal scratch book.

--
GnuPG Public Key: 0xF7142EC2

Re: ITP: zim -- a desktop wiki

[Frans Pop]

On Thursday 20 October 2005 17:35, Emfox Zhou wrote:
> Package name: Zim

Hmm. That takes me back to my university days where Zim was one of the 
earlier relational DBMSs with its own 4GL development environment...


pgpz43U3YpkiD.pgp
Description: PGP signature

Bug#334907: ITP: php-htscanner -- htaccess file parser for PHP in CGI mode

[Piotr Roszatycki]

Package: wnpp
Severity: wishlist
Owner: Piotr Roszatycki <[EMAIL PROTECTED]>

* Package name: php-htscanner
  Version : 0.1
* URL : http://files.zoeloelip.be/
* License : PHP License 3.0
  Description : htaccess file parser for PHP in CGI mode

When using a CGI version of php (plain old CGI or FastCGI), Apache can't pass
any PHP settings from htaccess files it parses.  This can be solved by giving 
each user it's own php.ini file, but the htscanner might be an alternative
solution.  This extension parses these configuration files (in most cases
..htaccess) and changes the settings.  It will search all directories for a
configuration file from the docroot until the directory where the request
scripts is found.


The source is licensed under PHP License, but I hope the upstream author could
release it under fixed license.


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

Re: Bits from the release team: the plans for etch

[Manoj Srivastava]

On Fri, 14 Oct 2005 00:02:17 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> Pet release goals
> ~

> There are a number of other systematic improvements on the drawing
> board for etch which we consider worthwhile even if we don't
> consider them blockers.  We would like as many of these goals as
> possible to be met for etch, but by definition they are not
> release-critical.  There is a chance that some of these goals may
> become release blockers for etch+1, though.

> The "pet release goals" that we are aware of are:

> - comprehensive SELinux support by building everything with
>   libselinux

> Please consider helping us meet these goals, not only in your own
> packages, but also in others' through patches and NMUs.

At this point, most of the major packages that have to be
 modified to enable a bare SELinux Debian system are in place, with
 coreutils being the last holdout.

Gregory T. Norris has created a set of patches for coreutils,
 and the resultant packages, which can be found at 
  "deb http://people.debian.org/~srivasta/ packages/"
 have been use on all my machines, including my production mail
 server, for about 6 months now. The corresponding bugs on coreutils
 are  Bug #312426 and  Bug #193328.
  http://www.golden-gryphon.com/software/security/selinux.xhtml
 id the page which I have been using to track the state of selinux in
 Sid, any changes to that are gratefully accepted.

Next, we need to focus on the security policy packages. The
 strict policy is pretty limited, and would need extension for the
 plethora of packages we have in Debian, and running a selinux box in
 permissive mode, and gradually attacking the number of AVC denials
 and making policy for the aditional packages is something that shall
 take time (but then, this is not a debian specific problem).

Also, the current means of handling changed or new policy
 packages is kinda horrid, and really should be replaced by a batch
 UCF like handling (asking ucf like questions for each file would be
 equally odious). I quite like the way apache module handling is one,
 one giant question with check boxes for individual modules.


Unfortunately, I have not had time recently to work on the new
 policy package (my new new root_fs  refuses to boot with strange libc
 errors, even in non-SELinux mode, which I have yet to track down).
 When my current situation improves, I hope to be able to help with
 the packaging of the policy package.

manoj
-- 
Each person has the right to take the subway.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Debian Installer team monthly meeting minutes (20051019 meeting)

[Christian Perrier]

(reply-to: debian-boot)

The minutes of the October D-I (Debian Installer) team IRC meeting
are now available from the Debian Installer Meetings wiki page:

http://wiki.debian.org/DebianInstallerMeetings

Minutes:
http://people.debian.org/~bubulle/d-i/irc-meeting-20051019/minutes

Log:
http://people.debian.org/~bubulle/d-i/irc-meeting-20051019/log

The next D-I meeting will be held on Saturday November 19th 16:00 UTC
on the #debian-boot channel on freenode.



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

Re: buzz/rex binaries/install media?

[Adrian von Bidder]

On Tuesday 18 October 2005 19.40, Matej Vela wrote:

> See 
> for buzz disks.

Thanks.

Now, does anybody know if buzz/Linux 2.0.0's 'ne' driver didn't support 
realtek PCI network cards, or if it's a qemu problem?  (I suspect the 
latter, as the ne2k-pci of 2.0.38 also doesn't work.)

Ok, this is getting OT - I'll shut up now on this topic.

cheers
-- vbi

-- 
featured link: http://fortytwo.ch/smtp


pgpCu6ykF5xxm.pgp
Description: PGP signature

Dependencies of -dev packages

[Gabor Gombas]

Hi,

(Parts of this topic has been discussed before, but the issues were not
solved, so let's try again).

Today I wanted to install libcurl-openssl-dev, because I wanted to build
an application locally that can utilize libcurl (and for the curious, I
choose libcurl-openssl-dev because the application already uses OpenSSL
natively and I felt no reason to link both OpenSSL and gnutls into the
same binary). The problem with this was that libcurl-openssl-dev wanted
to remove heimdal-dev which I also use for developing an other
application in favour of libkrb5-dev. So we have 2 problems that are
somewhat connected:

1. libcurl-openssl-dev Depends: on libkrb5-dev
2. libkrb5-dev Conflicts: with heimdal-dev

(the exact packages do not matter, they are just used to demonstrate the
situation)

libcurl-openssl-dev Depends: on libkrb5-dev
===

This issue was already discussed, last time due to link failures caused
by missing libtool .la files. But the thing is, .la files only show the
symptom, not the real problem.

The real problem is that -dev packages should contain everything needed
for both shared _and_ static linking, but the dependency information is
_different_ for static and shared linking. Therefore, the Depends: line
in the control file cannot describe both properly.

Things needed for shared linking:
- if an installed header #includes a header from an other -dev package,
  then a Depends: on that package

Note: we do _not_ need to depend on any packages that are used
internally but are not exposed in the public headers.

Things needed for static linking:
- if an installed header #includes a header from an other -dev package,
  then a Depends: on that package
- if the .a library references a symbol from an other package, then a
  Depends: on that package

This means that static dependencies are a superset of shared
dependencies. So, if the Depends: line in the control file wants to
cover static linking, then a lot of other packages that are not
neccessary for shared-only linking will be pulled in, and people have
already complained about that.

On the other hand, if the Depends: line in the control file covers only
shared linking, then people wanting to link statically need to know a
lot about how the Debian package was built to be able to install the
dependencies. For example, in the libcurl case, they'd need to know not
only that they need Kerberos development libraries, but also they should
know which one, since they are not ABI-compatible.

The proper solution were to move the headers and static libraries to
separate packages: the Depends: line of the header-package would follow
the requirements of dynamic linking, and the Depends: line of the static
library package would follow the requirements of static linking. This
would also solve the "missing libtool .la file" problem if all .la files
were included in the static library packages.

The downside is obvious: double the number of -dev packages. So I
propose a different solution, which is not perfect, but is better than
the current situation:

- -dev packages should only Depend: on other -dev packages neccessary
  for shared linking
- -dev packages should Recommend: any other -dev packages that are
  neccessary for static linking
- Make pkg-config mandatory. pkg-config can already handle the case that
  different libraries are needed for static and shared linking.
  pkg-config also helps the second problem (conflicting -dev packages),
  see below

How this would work:

- The Depends: line ensures that shared linking is always possible
- Due to the Recommends:, people tight on space do not have to install
  a horde of other -dev packages if they do not want static linking, but
  people wanting to link statically can still get the right dependencies
  easily
- pkg-config's .pc file properly documents what other libraries are
  needed for static linking, even if the same API (but not the same ABI)
  is provided by multiple packages

What is not solved here is the "missing libtool .la file" problem. But
pkg-config's .pc files can provide the almost the same functionality as
the .la files, so most .la files could simply be removed (there are a
small number of applications that parse .la files run-time though).

Sort test on my current desktop:
$ dpkg -l | grep -- "-dev " | wc -l
176
$ pkg-config --list-all | wc -l
115

So making pkg-config mandatory in the not-too-distant future (etch + 1?)
does not look unreasonable.

libkrb5-dev Conflicts: heimdal-dev
==

The problem here is that this "Conflicts:" assumes that the system has
just one user, which is simply not true. It is perfectly valid that on
the same system user A wants to use MIT Kerberos for his own application
while user B wants Heimdal. Or, better example, user A wants to use
libcurl3-gnutls-dev due to licensing reasons while user B wants to use
libcurl3-openssl-dev because he is already relying on OpenSSL.

pkg-config comes h

There are buildlogs for amd64 packages?

[Erik Schanze]

Hi,

there can I find the build log for dvgrab_1.7-1 on amd64?

http://buildd.debian.org/ doesn't list amd64 at all and
http://amd64.ftbfs.de/ has only 1.8-1 and higher.

Because amd64 is listed on http://packages.debian.org/
build logs should also be (easyly) available for packages of this 
architecture.


Regards,
Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
  * Linux-Info-Tag in Dresden, am 29. Oktober 2005  *
 Info: http://www.linux-info-tag.de *


pgp7rxhBfXUBN.pgp
Description: PGP signature

Debian

[Christopher Lemire]

What is different about debian 3.1r0 and r1 r2 through r6? I do not know whether to get r0 or something else because I do not know the difference. What is the difference between those and Debian Sarge?

Re: buzz/rex binaries/install media?

[Andrew M.A. Cater]

On Thu, Oct 20, 2005 at 08:41:07PM +0200, Adrian von Bidder wrote:
> On Tuesday 18 October 2005 19.40, Matej Vela wrote:
> 
> > See 
> > for buzz disks.
> 
> Thanks.
> 
> Now, does anybody know if buzz/Linux 2.0.0's 'ne' driver didn't support 
> realtek PCI network cards, or if it's a qemu problem?  (I suspect the 
> latter, as the ne2k-pci of 2.0.38 also doesn't work.)
> 
I'd be fairly surprised if _anything_ that old supported any but
experimental PCI cards: I'm not even sure that Realtek were around then
:) I have had problems installing RH 7.0 on qemu because various kernel 
stuff just died horribly - 7.3 and later was fine.

I've got a couple of my oldest machines I could try this on:
alternatively, I've threatened to bring along a 486 running Debian 1.3
to a Linux Expo and raffle it off as a consolation prize :)

> Ok, this is getting OT - I'll shut up now on this topic.
> 
> cheers
> -- vbi
> 
QEMU is software which really rocks - good luck :)

Andy

> -- 
> featured link: http://fortytwo.ch/smtp



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

Bug#334927: ITP: hoichess -- xboard compatible chess engine to play chess with

[Oliver Korff]

Package: wnpp
Severity: wishlist
Owner: Oliver Korff <[EMAIL PROTECTED]>

I will have a package ready for hoichess in a few days

* Package name: hoichess
  Version : 0.3.4
  Upstream Author : Holger Ruckdeschel <[EMAIL PROTECTED]>
* URL : http://www.hoicher.de/hoichess/
* License : GPL
  Description : xboard compatible chess engine to play chess with

Description: xboard compatible chess engine to play chess with
 chess engine compatible with xboard, but may also be used stand-alone,
 via terminal.
 HoiChess is still under development, but already plays a legal game of
 chess, always winning against his author :-) and packager too.
 .
 See http://www.hoicher.de/hoichess for more information.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: a few tips on proper use of version tracking in the Debian BTS

[Pierre THIERRY]

Scribit Stefano Zacchiroli dies 19/10/2005 hora 11:06:
> 1) once a bug as been closed - erroneously I would say - mailing
> [EMAIL PROTECTED] without the "Version:" pseudo header, is
> there a way to push the version information to the bts?

It seems. I did it for #297927: after sending a 'close 297927' to
[EMAIL PROTECTED], the BTS informed me that it was deprecated. I sent
another mail to [EMAIL PROTECTED] with 'Version: 0.9.23-1', and it is
now in the BTS as ``Fixed in version 0.9.23-1''.

Precisely,
Nowhere man
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: buzz/rex binaries/install media?

[Simon Richter]

Hi,

Adrian von Bidder schrieb:

> Now, does anybody know if buzz/Linux 2.0.0's 'ne' driver didn't support 
> realtek PCI network cards, or if it's a qemu problem?  (I suspect the 
> latter, as the ne2k-pci of 2.0.38 also doesn't work.)

No, the "ne" driver only handles ISA NE1000 and NE2000 cards. The
ne2k-pci does, but needs to be taught the PCI IDs possibly, and it only
works with the RTL8019 and RTL8029.

   Simon


signature.asc
Description: OpenPGP digital signature

Re: Dependencies of -dev packages

[Darren Salt]

I demand that Gabor Gombas may or may not have written...

[snip]
> So I propose a different solution, which is not perfect, but is better than
> the current situation:

> - -dev packages should only Depend: on other -dev packages neccessary
>   for shared linking
> - -dev packages should Recommend: any other -dev packages that are
>   neccessary for static linking
> - Make pkg-config mandatory. pkg-config can already handle the case that
>   different libraries are needed for static and shared linking.

I can see potential problems with that last part regarding upstream
developers whose software happens to depend on packages for which pkg-config
support remains Debian-specific because upstream doesn't accept the patch.
It's possible that the Debian-specific nature of this support may simply not
be noticed until bug reports start coming in from users of other
distributions...

[snip]
-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Retrocomputing: a PC card in a Risc PC

Would it help if I got out and pushed?


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

Re: localhost.localdomain

[Miles Bader]

Gabor Gombas <[EMAIL PROTECTED]> writes:
> On a fresh OpenBSD 3.7 install:
>
> ::1 localhost.home localhost
> 127.0.0.1 localhost.home localhost

Heh, I'm just surprised it's not:

   127.0.0.1 OpenLocalHOST localhost

-miles
-- 
Quidquid latine dictum sit, altum viditur.


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

Re: buzz/rex binaries/install media?

[Peter Samuelson]

  [vbi]
> > Now, does anybody know if buzz/Linux 2.0.0's 'ne' driver didn't
> > support realtek PCI network cards, or if it's a qemu problem?  (I
> > suspect the latter, as the ne2k-pci of 2.0.38 also doesn't work.)

[Simon Richter]
> No, the "ne" driver only handles ISA NE1000 and NE2000 cards. The
> ne2k-pci does, but needs to be taught the PCI IDs possibly, and it
> only works with the RTL8019 and RTL8029.

There was definitely a period of time when 'ne' was the correct driver
for PCI NE2000 clones.  I think Linux 2.0.0 was during that time
period, but am not sure.  Eventually (Linux 2.1?) ne2k-pci was split
off from ne.c, and the latter dropped PCI support.


signature.asc
Description: Digital signature

pbuilder help (bug 334877)

[Thomas Bushnell BSG]

I'm trying to solve bug 304932/334877.  

I can reproduce the build failure using pbuilder, but not when I build
on my own system directly.

I would like to do the pbuilder build and then examine the failing
filesystem, but pbuilder always deletes the build directory, and the
manual gives no clear indication of how to prevent this.  --debug says
that it only avoids cleanup in update and create.

--save-after-login and --save-after-exec only work for those
  particular commands.

Thomas


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

Re: pbuilder help (bug 334877)

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>
>I'm trying to solve bug 304932/334877.  
>
>I can reproduce the build failure using pbuilder, but not when I build
>on my own system directly.
>
>I would like to do the pbuilder build and then examine the failing
>filesystem, but pbuilder always deletes the build directory, and the
>manual gives no clear indication of how to prevent this.  --debug says
>that it only avoids cleanup in update and create.

Use:

pbuilder login
sed -i~ -e 's/#//g' /etc/apt/sources.list
cd /tmp/build
apt-get build-dep $package
apt-get source $package
cd $package-ver
dpkg-buildpackage -us -uc

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Re: Bits from the release team: the plans for etch

[Christian Perrier]

(CC in case you don't follow -devel that closely given your current
situation, Manoj. Please accept my apologies in advance if you do...)


> At this point, most of the major packages that have to be
>  modified to enable a bare SELinux Debian system are in place, with
>  coreutils being the last holdout.


Myself and other shadow package maintainers were wondering whether we
have to compile shadow utilities (login, su, passwd...) with SELinux
support.

One of my co-maintainers said me we shouldn't because libselinux1 is
not in the base system...which seems untrue..:-) (or I misunderstood
him which is also likely)

So, I guess we could, indeed...anyway I bet you'll ask us to do so at
some moment, won't you?





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

Work-needing packages report for Oct 21, 2005

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 205 (new: 5)
Total number of packages offered up for adoption: 86 (new: 1)
Total number of packages requested help for: 21 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   dcgui (#334492), orphaned 2 days ago
 Description: Direct Connect Graphical client (GTK+) (peer-based
 file-sharing)

   dctc (#334488), orphaned 2 days ago
 Description: Direct Connect Text Client
 Reverse Depends: rccp dcgui

   goldedplus (#334743), orphaned yesterday
 Description: Offline mail reader for Fidonet and Usenet

   juke (#334375), orphaned 3 days ago
 Description: A curses-based jukebox program

   jwhois (#334543), orphaned 2 days ago
 Description: Improved Caching Whois client

200 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   minit (#334178), offered 5 days ago
 Description: Small but powerful init system

85 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 119 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross ltsp-server dfsbuild aboot

   athcool (#278442), requested 359 days ago
 Description: Enable powersaving mode for Athlon/Duron processors

   debtags (#321654), requested 75 days ago
 Description: Enables support for package tags
 Reverse Depends: debtags-edit

   dselect (#282283), requested 334 days ago
 Description: a user tool to manage Debian packages

   fetchmail (#331642), requested 16 days ago
 Description: SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
 Reverse Depends: fetchmail-ssl fetchmailconf webmin-fetchmail

   grub (#248397), requested 528 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: webmin-grub grubconf replicator dfsbuild
 grub-splashimages

   gtkpod (#319711), requested 88 days ago
 Description: manage songs and playlists on an Apple iPod

   gutenbrowser (#331203), requested 18 days ago
 Description: Project Gutenberg Etext reader

   lib (#329966), requested 26 days ago
 Description: Perl interfaces to the Gtk and Gnome libraries

   lsdvd (#316922), requested 108 days ago
 Description: read the contents of a DVD

   mwavem (#313369), requested 129 days ago (non-free)
 Description: Mwave/ACP modem support software

   openssl (#332498), requested 14 days ago
 Description: Secure Socket Layer (SSL) binary and related
 cryptographic tools
 Reverse Depends: apcupsd dovecot-common apcupsd-cgi
 openssh-server-udeb stone spamc libsword5 libopensc-openssl
 libecpg-compat2 apache-ssl pound tn5250 webmin courier-ssl
 libtorrent5 fireflier-client-kde bzflag-server wpasupplicant
 fwbuilder-linux fwbuilder-bsd tcpdump dsniff libcrypt-ssleay-perl
 sqlrelay-postgresql liblasso3 ultrapossum-tls ssmtp libwebauth-perl
 sqlrelay-freetds php4-dev sqlrelay-sqlite cacti-cactid
 libmusclepkcs11 libapache2-mod-php5 subversion libapache-mod-php4
 php4-cgi mzscheme libpq3 fireflier-client-qt libneon23-dev
 python2.4-sqlrelay lwresd tor sip-tester drivel newpki-server davfs2
 openssh-client-udeb postgresql-contrib-7.4 nessusd heartbeat-2
 php5-cli nagios-nrpe-server libecpg-dev ntp-refclock asmail
 uw-mailutils libopenh323-dev libomniorb4-dev postfix libpt-dev
 libfwbuilder6c2 libapache2-webkdc libneon24-dev ardour-gtk-i686 pyca
 openvpn ftpd-ssl stunnel4 fireflier-server siege
 libmultisync-plugin-syncml libscam1 libpq4 ejabberd libyaz
 pantomime-dev medussa libzorpll-dev usermin libpam-mount
 python2.3-sqlrelay nagios-plugins mozilla-opensc aria kdelibs4-dev
 stunnel libkeynote0 sslwrap postgresql-7.4 libwebauth1 tellico
 webauth-utils ntp-simple ca-certificates elfsign diatheke
 libopensc1-dev dovecot-pop3d libgadu-dev libsnmp9-dev httping isync
 nmap dovecot-imapd esmtp ntop libpam-musclecard libc-client-dev
 libace5.4.7 libaws-dev libdar3 ipopd gambas-gb-net-curl libopensc1
 epic4 telnet-ssl schoolbell apache2-threaded-dev apache2-prefork-dev
 partimage-server libxmlsec1-dev icecast2 php4-lasso ssl-cert
 php5-curl php4-curl cogito lprng kphone ftp-ssl
 libgnustep-base1.10-dev mixmaster php4-sqlrelay openssl opensc curl
 dnsutils libapache-mod-php5 encfs libo