Bug#298177: dvi2ps: FTBFS (amd64/gcc-4.0):

[OHURA Makoto]

tags 298177 pending
thanks

  Hi.

From: Roger Leigh <[EMAIL PROTECTED]>
Subject: Bug#298177: dvi2ps: FTBFS (amd64/gcc-4.0):
Date: Wed, 20 Jul 2005 21:30:03 +0100

> I have re-done the patch for GCC-4.0.  Unless there are any
> objections, or you intend to upload a fix yourself, I intend to upload
> this shortly.

  New package has already been prepared, but ftp-master is down
now.  I'll upload as soon as ftp-master will be up.

  Thanks.


  OHURA Makoto: [EMAIL PROTECTED](Debian Project)
[EMAIL PROTECTED](LILO/Netfort)
  GnuPG public key: http://www.netfort.gr.jp/~ohura/gpg.asc.txt
fingerprint: 54F6 D1B1 2EE1 81CD 65E3  A1D3 EEA2 EFA2 77DC E083
  http://www.netfort.gr.jp/~ohura/


pgpfE1UxsbDAZ.pgp
Description: PGP signature

Bug#319993: regina-normal: FTBFS with gcc-3.4/gcc-4.0: various

[Karl Chen]

Package: regina-normal
Severity: normal
Tags: patch


'regina-normal' fails to build from source using gcc-3.4/gcc-4.0.

The following patch allows regina-normal to build under gcc-3.4.


--- engine/engine/maths/nmatrix.h.orig  2005-07-25 02:54:45.0 -0700
+++ engine/engine/maths/nmatrix.h   2005-07-25 15:04:43.0 -0700
@@ -284,8 +284,8 @@
  */
 void makeIdentity() {
 initialise(zero);
-for (unsigned long i = 0; i < nRows && i < nCols; i++)
-data[i][i] = one;
+for (unsigned long i = 0; i < this->nRows && i < this->nCols; i++)
+this->data[i][i] = one;
 }
 
 /**
@@ -298,8 +298,8 @@
  * @param dest the row that will be added to.
  */
 void addRow(unsigned long source, unsigned long dest) {
-for (unsigned long i = 0; i < nCols; i++)
-data[dest][i] += data[source][i];
+for (unsigned long i = 0; i < this->nCols; i++)
+this->data[dest][i] += this->data[source][i];
 }
 /**
  * Adds the given number of copies of the given source row to
@@ -318,8 +318,8 @@
  */
 void addRow(unsigned long source, unsigned long dest,
 T copies) {
-for (unsigned long i = 0; i < nCols; i++)
-data[dest][i] += copies * data[source][i];
+for (unsigned long i = 0; i < this->nCols; i++)
+this->data[dest][i] += copies * this->data[source][i];
 }
 /**
  * Adds the given source column to the given destination column.
@@ -331,8 +331,8 @@
  * @param dest the column that will be added to.
  */
 void addCol(unsigned long source, unsigned long dest) {
-for (unsigned long i = 0; i < nRows; i++)
-data[i][dest] += data[i][source];
+for (unsigned long i = 0; i < this->nRows; i++)
+this->data[i][dest] += this->data[i][source];
 }
 /**
  * Adds the given number of copies of the given source column to
@@ -351,8 +351,8 @@
  */
 void addCol(unsigned long source, unsigned long dest,
 T copies) {
-for (unsigned long i = 0; i < nRows; i++)
-data[i][dest] += copies * data[i][source];
+for (unsigned long i = 0; i < this->nRows; i++)
+this->data[i][dest] += copies * this->data[i][source];
 }
 /**
  * Multiplies the given row by the given factor.
@@ -366,8 +366,8 @@
  * @param factor the factor by which to multiply the given row.
  */
 void multRow(unsigned long row, T factor) {
-for (unsigned long i = 0; i < nCols; i++)
-data[row][i] *= factor;
+for (unsigned long i = 0; i < this->nCols; i++)
+this->data[row][i] *= factor;
 }
 /**
  * Multiplies the given column by the given factor.
@@ -381,8 +381,8 @@
  * @param factor the factor by which to multiply the given column.
  */
 void multCol(unsigned long column, T factor) {
-for (unsigned long i = 0; i < nRows; i++)
-data[i][column] *= factor;
+for (unsigned long i = 0; i < this->nRows; i++)
+this->data[i][column] *= factor;
 }
 
 /**
@@ -399,14 +399,14 @@
  * this * other.
  */
 NMatrixRing* operator * (const NMatrixRing& other) const {
-NMatrixRing* ans = new NMatrixRing(nRows, other.nCols);
+NMatrixRing* ans = new NMatrixRing(this->nRows, other.nCols);
 unsigned long row, col, k;
-for (row = 0; row < nRows; row++)
+for (row = 0; row < this->nRows; row++)
 for (col = 0; col < other.nCols; col++) {
 ans->data[row][col] = zero;
-for (k = 0; k < nCols; k++)
+for (k = 0; k < this->nCols; k++)
 ans->data[row][col] +=
-(data[row][k] * other.data[k][col]);
+(this->data[row][k] * other.data[k][col]);
 }
 return ans;
 }

--- engine/engine/maths/nvector.h.orig  2005-07-25 15:48:06.0 -0700
+++ engine/engine/maths/nvector.h   2005-07-25 15:48:34.0 -0700
@@ -39,6 +39,11 @@
 
 namespace regina {
 
+template  class NVector;
+
+template  std::ostream& operator << (std::ostream& out,
+  const NVector& vector);   
 
+
 /**
  * \weakgroup maths
  * @{

--- engine/engine/maths/nvectordense.h.orig 2005-07-25 15:49:11.0 
-0700
+++ engine/engine/maths/nvectordense.h  2005-07-25 15:50:00.0 -0700
@@ -139,7 +139,7 @@
 elements[i] -= other[i];
 }
 virtual void operator *= (const T& factor) {
- 

Bug#318413: xlibs: Backslash Key is broken on Japanese Keyboards

[Horms]

On Wed, Jul 20, 2005 at 11:46:51PM +0200, Denis Barbier wrote:
> On Wed, Jul 20, 2005 at 10:35:22PM +0200, Horms wrote:
> > On Wed, Jul 20, 2005 at 10:07:06PM +0200, Denis Barbier wrote:
> > > On Wed, Jul 20, 2005 at 01:18:26AM +0200, Horms wrote:
> > > [...]
> > > > > > ii  libx11-6 4.3.0.dfsg.1-14 X Window System 
> > > > > > protocol client li
> > > > > 
> > > > > There is some mismatch here, your libx11-6 package should have the 
> > > > > same
> > > > > version number as other X packages.
> > > > 
> > > > Good point, I think that was as a result of me desparately
> > > > reinstalling old versions in order to debug the problem.
> > > > Surprosingly said system seems to work.
> > > 
> > > I am confused, do you mean that this bug can be closed?
> > 
> > Now I am confused. What would you like me to test?
> 
> I would like to know if your Japanese keyboard is broken when all X
> packages have been upgraded from XFree86 to X.Org, and if my patch
> against /etc/X11/xkb/symbols/pc/jp has some good effect.

I am pretty sure it doesn't work on my laptop without the modifucation I posted
earlier. And I am pretty sure the japanese keys (e.g. Muhenkan) don't
work on my IBM spacesaver keyboard even with your patch and mine.
I will double check this and get back to you.

-- 
Horms


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

Bug#319022: Testing requirements stalled

[Philipp Kern]

On Mon, 2005-07-25 at 18:20 -0700, Shaun Jackman wrote:
> It's been saying that "ncurses is only 3 days old" for the past four
> days. Any idea what's up?

Well, ftp-master is down, so the testing scripts (aka britney) do not
run.

Kind regards,
Philipp Kern


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

Bug#319839: INTL:vi Vietnamese translation for sugarplum

[sean finney]

tags 319839 pending
thanks

On Mon, Jul 25, 2005 at 03:34:27PM +0930, Clytie Siddall wrote:
> Please find attached the Vietnamese translation for debconf template:  
> sugarplum

thanks, will be included in next upload.

sean

-- 


signature.asc
Description: Digital signature

Bug#319856: newvserver script needs /etc/vservers/util-vserver-vars

[Ola Lundqvist]

Hello

On Mon, Jul 25, 2005 at 03:55:07PM +0800, Andrew Lee wrote:
> Package: util-vserver
> Version: 0.30.204-5sarge2
> Severity: important
> 
> Hi Ola,
> 
> I found the old sarge has /etc/vservers/util-vserver-vars
> And the new one(fresh installed sarge) does not.
> 
> It cause the newvserver script failed on build new vserver, because has 
> no /etc/vservers/util-vserver-vars.
> 
> For solve this problem, just simply copy
> /usr/lib/util-vserver/util-vserver-vars to /etc/vservers/

I actually do not think this is a problem. The util-vserver-vars file
exist in /usr/lib/util-vserver (as far as i remember) and it
can be used for building.

To determine the exact cause of this error. I need more information,
i.e. error output and probably some help with debugging.

It can be that you have a symlink that point to wrong location
maybe.

Did you a fresh install of util-vserver, or was it an upgrade from
older version in sarge before it entered testing.

> I will suggest to mention this in NEW or README.Debian or add it to
> postinst.

Well sarge has become stable and such updates will not be allowed for
the package, unfortunatly.

> Thank you for your wonderfull integration of vserver packages in Debian.

You are welcome.

Regards,

// Ola

> -- System Information:
> Debian Release: 3.1
> Architecture: i386 (i686)
> Kernel: Linux 2.4.27-10vserver
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> 
> Versions of packages util-vserver depends on:
> pn  iproute  Not found.
> ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries 
> an
> ii  libgcc1 1:3.4.3-13   GCC support library
> ii  libstdc++5  1:3.3.5-13   The GNU Standard C++ Library v3
> ii  net-tools   1.60-10  The NET-3 networking toolkit
> 
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED] 654 65 KARLSTAD  |
|  +46 (0)54-10 14 30  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---


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

Bug#319992: resolv.conf empty at boot time

[Dustin]

Package: resolvconf
Version: 1.28

Recently I rebooted this machine and discovered that name resolution no
longer is configured properly by the initscripts.  The OS is an up-to-date
Debian Sarge.  I don't know whether I broke it or there was some
incompatibility after an update because the machine is kept up to date but
rarely rebooted.

For debugging I have commented out the LAN NIC eth1 in
/etc/network/interfaces to try to isolate what is happening, so eth0 is
the only network interface.  This card is connected to my cable modem and
is configured with my fixed IP address (no DHCP).  The relevant lines from
/etc/network/interfaces are

---
# The primary network interface
auto eth0
iface eth0 inet static
address 72.25.87.157
netmask 255.255.255.0
network 72.25.87.0
broadcast 72.25.87.255
gateway 72.25.87.1
# dns-* options are implemented by the resolvconf package, if 
installed
dns-nameservers 66.51.206.100 66.51.205.100
dns-search laurences.net
---

/etc/resolv.conf is the correct symlink according to the man page:

poly:/etc# ls -l /etc/resolv.conf
lrwxrwxrwx  1 root root 31 Jun 30 00:18 /etc/resolv.conf -> 
/etc/resolvconf/run/resolv.conf

After a clean boot the /etc/resolvconf/run/interface/ directory is empty:

poly:/etc# ls -a /etc/resolvconf/run/interface/
.  ..

and /etc/resolv.conf is empty but for header comments:

---
poly:/etc# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
---

even though /etc/network/interfaces has the lines listed above. eth0
itself is up though: I can ping machines listed in /etc/hosts, such as the 
ISP's gateway and nameservers,

poly:/etc# ping nameserver1
PING nameserver1 (66.51.206.100) 56(84) bytes of data.
64 bytes from nameserver1 (66.51.206.100): icmp_seq=1 ttl=252 time=8.93 ms
64 bytes from nameserver1 (66.51.206.100): icmp_seq=2 ttl=252 time=8.01 ms

--- nameserver1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 8.018/8.477/8.937/0.468 ms

and do a DNS lookup if I specify the nameserver
explicitly,

poly:/etc# nslookup www.google.com. nameserver1
Server: nameserver1
Address:66.51.206.100#53

Non-authoritative answer:
www.google.com  canonical name = www.l.google.com.
Name:   www.l.google.com
Address: 66.102.7.147
Name:   www.l.google.com
Address: 66.102.7.99
Name:   www.l.google.com
Address: 66.102.7.104

so I think the problem is just the empty resolv.conf.

Re-running resolvconf doesn't fix it:

poly:/etc# /etc/init.d/resolvconf reload
poly:/etc# nslookup www.google.com.
;; connection timed out; no servers could be reached

However, doing an ifdown/ifup on eth0 does the trick:

poly:/etc# ifdown eth0 ; ifup eth0
poly:/etc# nslookup www.google.com.
Server: 66.51.206.100
Address:66.51.206.100#53

Non-authoritative answer:
www.google.com  canonical name = www.l.google.com.
Name:   www.l.google.com
Address: 66.102.7.99
Name:   www.l.google.com
Address: 66.102.7.104
Name:   www.l.google.com
Address: 66.102.7.147

poly:/etc# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 66.51.206.100
nameserver 66.51.205.100
search laurences.net

Essentially, everything works as expected except at boot time.

I also fiddled with running bind locally as a caching nameserver; starting
and stopping it after boot adds and removes the loopback address to
resolv.conf, but it isn't there right after a reboot (though name 
resolution works because the resolver apparently checks the local host if 
there are no resolv.conf entries:

poly:/etc# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
poly:/etc# ifdown eth0 ; ifup eth0
poly:/etc# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 66.51.206.100
nameserver 66.51.205.100
search laurences.net
poly:/etc# /etc/init.d/bind9 restart
Stopping domain name service: named.
Starting domain name service: named.
poly:/etc# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
nameserver 66.51.206.100
nameserver 66.51.205.100
search laurences.net
poly:/etc#

Dustin




-- 
To UNSUBSCRI

Bug#318062: mozilla-browser: version 1.7.9 fixes security bugs

[Takuo KITAME]

2005-07-23 (土) の 16:30 +0200 に Andreas Metzler さんは書きました:
> On 2005-07-20 Takuo KITAME <[EMAIL PROTECTED]> wrote:
> > 2005-07-13 (水) の 09:25 +0200 に Florian Weimer さんは書きました:
> [...] 
> >> Mozilla 1.7.9 fixes several security bugs, one of them rated critical.
> >> Unfortunately, details for this bug are embargoed until at least July
> >> 20, 2005. 8-(
> 
> > 1.7.9 is still not released yet.
> > pending.
> 
> 1.7.10 has been released the day before yesterday (July 21st).
> 
>  cu andreas


still pending due to build problem. (#316106: FTBFS with freetype
2.1.10)
-- 
Takuo KITAME



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

Bug#319841: surfraw

[Clytie Siddall]

On 25/07/2005, at 5:12 PM, Moritz Muehlenhoff wrote:


I'm sorry, but the debconf stuff has already been removed in CVS. It
was only used for Sarge -> Woody transitions, where the surfraw  
scripts

have changed their locations. We should really upload the current CVS
into sid, so that further wasted translator work is prevented. Thomas
or Christian, could you have a look at current CVS and upload it,  
if it's

appropriate (changes to current sid are minimal)?


Please remove it from the debconf list. There are quite enough files  
needing translation without working on ones that won't be used. :(


from Clytie (vi-VN, Vietnamese free-software translation team / nhóm  
Việt hóa phần mềm tự do)

http://groups-beta.google.com/group/vi-VN

Bug#317048: libetpan: new version available (0.37)

[Nikita V. Youshchenko]

> > > Any chance of getting 0.38, even just an unofficial version on your
> > > site? Or is it still 0.38-pre, and you don't want to package it
> > > until its stable?
> >
> > It is already not pre, and it is already packaged, and request to my
> > sponsor to upload it is already sent.
> >
> > For now, please look at http://zigzag.lvk.cs.msu.su/~nikita/libetpan/
>
> Thanks a lot. I was patiently waiting for 0.37 to build sylpheed, guess
> I'll just have to wait a little longer. Is there a .deb somewhere? I

I've put binary debs for i386/sid to the above URL.


pgpzyzBPiZCDz.pgp
Description: PGP signature

Bug#319788: installation-reports: [sparc][netinst] attempt to access beyond end of device

[Elie De Brauwer]

> Could you also check the new builds? Booting into Debian-installer is
> good enough (that is beyond the ramdisk size issue ) and quit.
> It wouldn't hurt your fresh installed system
> and it is good to known that is works again out of the box.
> 


At this point I don't have a freshly installed system yet, so this evening (or
tomorrow depends when I have some time) I'll look into the fresh images (and
probably file a bug about the fscked up terminal).


greetings
Elie De Brauwer

-- 
<>
 Homepage:
 www.de-brauwer.be
<>


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

Bug#319988: Mozilla always closes when close dialog appears, regardless of selection

[Benjamin]

Package: mozilla-browser
Version: 2:1.7.8-1

When the close button on the titlebar is clicked and multiple tabs are
open, a dialog box appears to confirm whether the browser should be
closed. However, regardless of the choice made in this dialog box, the
browser will close anyway. This does not occur when using the Ctrl-Q
keyboard shortcut or the Quit command on the File menu.

I'm currently using KDE 3.4.1 from Alioth, but this problem was also
present in the KDE version included in Sarge.

--Benjamin


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

Bug#319905: FTBFS on GNU/kFreeBSD

[Ola Lundqvist]

Could not upload today. Will be some other day.

Regards,

// Ola

On Mon, Jul 25, 2005 at 05:24:06PM +0200, Aurelien Jarno wrote:
> Package: primaxscan
> Severity: important
> 
> Hello,
> 
> primaxscan currently fails to build on GNU/kFreeBSD due to the
> following reasons:
> - kfreebsd-i386 is not in the arch list
> - outdated config.guess and config.sub
> - use of asm/io.h instead of sys/io.h
> 
> Please find attached a patch to fix that. Could you please include it
> in your next upload?
> 
> Thanks in advance,
> Aurelien
> 
> -- System Information:
> Debian Release: testing/unstable
> Architecture: kfreebsd-i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: GNU/kFreeBSD 5.3-17
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

> diff -u primaxscan-0.93beta3/debian/rules primaxscan-0.93beta3/debian/rules
> --- primaxscan-0.93beta3/debian/rules
> +++ primaxscan-0.93beta3/debian/rules
> @@ -14,6 +14,7 @@
>  configure-stamp:
>   dh_testdir
>   # Add here commands to configure the package.
> + cp -f /usr/share/misc/config.{guess,sub} $(CURDIR)
>   ./configure --prefix=/usr --mandir=\$${prefix}/share/man 
> --infodir=\$${prefix}/share/info
>  
>   touch configure-stamp
> @@ -36,6 +37,7 @@
>   dh_testdir
>   dh_testroot
>   rm -f build-stamp configure-stamp
> + rm -f config.{guess,sub}
>  
>   # Add here commands to clean up after the build process.
>   -$(MAKE) distclean
> diff -u primaxscan-0.93beta3/debian/control 
> primaxscan-0.93beta3/debian/control
> --- primaxscan-0.93beta3/debian/control
> +++ primaxscan-0.93beta3/debian/control
> @@ -2,11 +2,11 @@
>  Section: misc
>  Priority: extra
>  Maintainer: Ola Lundqvist <[EMAIL PROTECTED]>
> -Build-Depends: debhelper (>> 3.0.0), perl, libtiff4-dev, zlib1g-dev (>= 
> 1:1.1.3)
> +Build-Depends: debhelper (>> 3.0.0), perl, libtiff4-dev, zlib1g-dev (>= 
> 1:1.1.3), autotools-dev
>  Standards-Version: 3.6.1
>  
>  Package: primaxscan
> -Architecture: i386 amd64
> +Architecture: i386 kfreebsd-i386 amd64
>  Depends: ${shlibs:Depends}
>  Description: Primax Colorado Direct scanner software
>   This is a stand-alone driver program for the Primax Colorado Direct
> only in patch2:
> unchanged:
> --- primaxscan-0.93beta3.orig/lp.c
> +++ primaxscan-0.93beta3/lp.c
> @@ -25,7 +25,7 @@
>  
>  
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> only in patch2:
> unchanged:
> --- primaxscan-0.93beta3.orig/primax_scan.c
> +++ primaxscan-0.93beta3/primax_scan.c
> @@ -22,7 +22,7 @@
> Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  
>  */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 


-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED] 654 65 KARLSTAD  |
|  +46 (0)54-10 14 30  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---


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

Bug#100925: resproduce

[David Coe]

Joey Hess <[EMAIL PROTECTED]> writes:

> FYI, I can still reproduce this bug, four years after I filed it.
>
> -- 
> see shy jo

Yeah, I have an update from upstream on April 15 (2005):

#100925: spins if ctrl-z'd
Just fixed it.  The fix isn't perfect because you have to type
control-L to refresh the screen after resuming, (that's much
harder to fix) but at least control-Z now works.

I haven't had time to test the fix yet.


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

Bug#181509: we make it simple and F-R-E-E

[Houston H. Kerry , III]

Hello, [EMAIL PROTECTED]

We tried to contact you earlier about financinq your home at a better a.p.r
We would like to let you know that we have gone ahead and started the 
pre-app-roval process.

Here are the results:

Amount: $217,000 - $898,800
a p r: 3.29 - 6.48

for more information visit.
place in your window
www.thefunding.net/quote.ihtml?affiliateid=5&campid=18


Thank you.
Houston H. Kerry , III


..
to quit...visit...
atwebpage


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

Bug#201409: approval pending

[Lewis]

Hey,

We tried to contact you earlier about f*inanc*ing your home at a lower a.p.r
I would like to let you know that we have gone ahead and started the 
p-re-app-roval process.

Here are the results:

Amount: $238,000 - $880,700
a[p]r: 3.63 - 6.20

for more info please visit.
place into your window
www.thefunding.net/quote.ihtml?affiliateid=5&campid=18


Thank you.
Lewis


..
to quit...visit...
atwebpage


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

Bug#223877: we are waiting for a answer

[Mayer]

Hello,

We tried to contact you earlier about f*inanc*ing your home at a lovver a p r
I would like to let you know that we have gone ahead and started the 
preappr0val process.

Here are the results:

Amount: $281,400 - $825,400
a[p]r: 3.64 - 6.15

to continue visit..
just put into your window
www.thefunding.net/quote.ihtml?affiliateid=5&campid=18


Kind Regards,
Mayer


..
to quit...visit...
atwebpage


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

Bug#319989: piuparts: malformed sources.list

[Kai Hendry]

Package: piuparts
Version: 0.7-1
Severity: normal


This is my sources.list :

deb http://ftp.au.debian.org/pub/linux/debian/ unstable main contrib non-free
deb-src http://ftp.au.debian.org/pub/linux/debian/ unstable main contrib 
non-free

deb ftp://ftp.nerim.net/debian-marillat/ sid main
deb-src ftp://ftp.nerim.net/debian-marillat/ sid main

deb http://hendry.iki.fi/debian/ unstable/
deb-src http://hendry.iki.fi/debian/ unstable/



This is the one that is generated for piuparts in the tempdir:

frodo$ cat etc/apt/sources.list
deb http://ftp.au.debian.org/pub/linux/debian/ sarge main contrib non-free
deb ftp://ftp.nerim.net/debian-marillat/ sarge main
deb http://hendry.iki.fi/debian/ sarge

Since it's a private repo, it need the trailing slash. 
More info: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317384




frodo$ sudo piuparts -v -d sarge maradns_1.0.30-1_i386.deb
0min0.0s ---
0min0.0s piuparts version 0.7 starting up.
0min0.0s Command line arguments: /usr/sbin/piuparts -v -d sarge 
maradns_1.0.30-1_i386.deb
0min0.0s DEBUG: Starting command: dpkg --info maradns_1.0.30-1_i386.deb
0min0.1s DEBUG: Command ok: 'dpkg --info maradns_1.0.30-1_i386.deb'
0min0.1s DEBUG: Created temporary directory ./tmpzFW0X0
0min0.1s DEBUG: Setting up minimal chroot for sarge at ./tmpzFW0X0.
0min0.1s DEBUG: Starting command: debootstrap sarge './tmpzFW0X0' 
'http://ftp.au.debian.org/pub/linux/debian/'
7min40.4s DEBUG: Command ok: "debootstrap sarge './tmpzFW0X0' 
'http://ftp.au.debian.org/pub/linux/debian/'"
7min40.4s DEBUG: Starting command: chroot ./tmpzFW0X0 apt-get update
7min40.5s ERROR: Command failed (status=25600): 'chroot ./tmpzFW0X0 apt-get 
update'
  E: Malformed line 3 in source list /etc/apt/sources.list (dist parse)


I don't care for my private repo while testing a package, so the first line of
the generated sources.list would have been fine.

Best wishes Lars, you're doing some really great Debian work.

-- 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.12-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)

Versions of packages piuparts depends on:
ii  apt   0.6.38 Advanced front-end for dpkg
ii  debootstrap   0.3.1.4Bootstrap a basic Debian system
ii  python2.3.5-3An interactive high-level object-o

piuparts recommends no packages.

-- no debconf information


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

Bug#319990: piuparts: man page example fails

[Kai Hendry]

Package: piuparts
Version: 0.7-1
Severity: minor

This could be a problem with debootstrap. :)

Anyway, scripts for stable, testing and unstable don't exist:

frodo$ dpkg -L debootstrap | grep scripts
/usr/lib/debootstrap/scripts
/usr/lib/debootstrap/scripts/potato
/usr/lib/debootstrap/scripts/woody
/usr/lib/debootstrap/scripts/woody.buildd
/usr/lib/debootstrap/scripts/sarge
/usr/lib/debootstrap/scripts/sarge.buildd
/usr/lib/debootstrap/scripts/sarge.fakechroot
/usr/lib/debootstrap/scripts/etch
/usr/lib/debootstrap/scripts/sid
/usr/lib/debootstrap/scripts/warty
/usr/lib/debootstrap/scripts/warty.buildd
/usr/lib/debootstrap/scripts/hoary
/usr/lib/debootstrap/scripts/hoary.buildd

So the example in the man page:

piuparts -a -d stable -d testing -d unstable foo

Fails

-- 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.12-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)

Versions of packages piuparts depends on:
ii  apt   0.6.38 Advanced front-end for dpkg
ii  debootstrap   0.3.1.4Bootstrap a basic Debian system
ii  python2.3.5-3An interactive high-level object-o

piuparts recommends no packages.

-- no debconf information


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

Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable

[Matt Kraai]

On Mon, Jul 25, 2005 at 04:40:03PM -0700, Bruce Korb wrote:
> I have an image up on Source Forge:
> 
>   http://autogen.sf.net/data/autogen-5.7.2-semifinal.tar.gz
> 
> If it makes you-all happy, then I will release exactly  that image.

I have two minor nits:

1. After it calls canonicalize_file_name, shouldn't optionMakePath
check that the length of the result is less than bufSize instead of
less than MAXPATHLEN?

2. Since realpath expects a buffer of size PATH_MAX, if PATH_MAX isn't
defined, shouldn't realpath not be used at all?

-- 
Matt


signature.asc
Description: Digital signature

Bug#155806: tried the pente sound patch

[Joey Hess]

FYI, André if you send mail to [EMAIL PROTECTED] I, as the bug
repost submitter, don't see it. CCing the submitter is a good way to
avoid 3 year turnaround times on your questions. ;-)
Anyway, you don't even maintain this anymore so sorry to bother you.

Anyway, I tried the patch, configure finds the header and it builds but
I hear that the author described as "farts" too.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#314435: libc6-dev: struct timespec and nanosleep() not available with -std=c99

[GOTO Masanori]

At Mon, 25 Jul 2005 15:23:12 +0200,
Baurzhan Ismagulov wrote:
> > How do you think that this bug report should be reassigned to
> > manpages-dev, or simple close?
> 
> I've already reassigned it to manpages-dev, and it is already
> fixed-upstream thanks to Michael.

Baurzhan and Michael, thanks for your quick reply and works :)

Regards,
-- gotom


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

Bug#319947: Current RADEON driver in xserver-xorg is ancient.

[Daniel Stone]

On Tue, Jul 26, 2005 at 12:42:29AM +0300, Samuli Suominen wrote:
> Current RADEON driver in X.Org 6.8.2 doesn't support Non-Rectangular MergedFB
> Desktops, or AGPMode 8x, not to mention r300 drivers from DRI CVS. X.Org CVS
> Snapshots, like 6.8.99.15 does. Maybe RADEON driver should be backported
> from HEAD to current Debian X.Org ? Would be lovely to use Debian again,
> with Fast, Accellerated, Open Source Dualhead.

X.Org HEAD does not have the r300 DRI drivers, however.

I think taking Radeon from HEAD is generally sane.


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

Bug#229841: vim-gnome: :vsp removes bottom lines of a maximised window

[Paul Brossier]

I was about to report the bug described in the title: when starting vim,
if i maximise the window and split in two buffers vertically, the space
for about 4 text lines at the bottom of the window is left blank.

if i switch the window to a smaller size and back, the lines are back.

now i also noticed a variant of 229841, where in fullscreen mode (not
maximised, fullscreen), the command line is drawn a little to low,
enough to make a 'p' and an 'n' look the same. 

guess both of these are related to the way gvim calculates where to put
the bottom line. let me know if you want screen shots or so.

cheers, piem


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

Bug#319979: proc_usb_info.txt.gz: added blank lines to reflect current format

[Horms]

Hi Dan,

Thanks for your patch. I'm not sure that documentation patches
are appropriate for 2.6.8 which is really just in maintenence mode.
Actually, I'm not sure if anything other than security
fixes will ever make it into the 2.6.8 for sarge. 

Do you know which upstream version this was included in?
If it is in 2.6.12 then it is already in unstable.

-- 
Horms


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

Bug#12254: hmm

[Joey Hess]

This bug has been open for 7 going on 8 years without a reply.

I imagine it's hard to reproduce since it relys on a network read
failing, but looking at the code, it can't be that hard to fix. The
program forks off a send process and then waits receiving the data. The
problem happens when one of these reads fails:

if ((cnt = read(sock, buf, bytes_left)) == -1)  {
  perror("receive:");
  exit(2);
}

All the parent process needs to do in this situation is signal the child to
exit. Or even just wait() on it before exiting.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#313063: dpkg-reconfigure locales generated /etc/envrironment with ru_EE locale :)

[GOTO Masanori]

At Sun, 24 Jul 2005 15:08:31 +0300,
Anton wrote:
> You may close the bug. I edited /etc/environment by hand long time
> ago. And all worked out. Concerning russian in Estonia, I'd say that
> there are about 20-33% russian speaking people in Estonia, Latvia. But
> you may forget about it and close the bug.

In Estonia, are there people who cannot speak Estonian but Russian?
If someone needs ru_EE, it's nice to support it officially, IMHO.

Regards,
-- gotom


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

Bug#137311: FWIW

[Joey Hess]

FWIW, this bug remains and is probably #3 on my list of reasons to hate
aptitude.

Thanks for aptitude BTW! ;-)

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#319986: powerpc: kernel-image-2.6.12-sven64 does not boot dual CPU PowerMac7,3

[Shyamal Prasad]

Package: kernel
Severity: important

"Sven" == Sven Luther <[EMAIL PROTECTED]> writes
 [http://lists.debian.org/debian-powerpc/2005/07/msg00304.html]: 

Sven> Oh, darn, thsis means something is broken. or something
Sven> else,, please can you comment on a real bugreporty
Sven> (reportbug kernel should do).

The 2.6.12-sven64_1_powerpc.deb that was tested can be found at
http://people.debian.org/~luther/ppc64/kernel-image-2.6.12-sven64_1_powerpc.deb

  [The text below was originally posted to debian-powerpc
http://lists.debian.org/debian-powerpc/2005/07/msg00273.html ]

This kernel fails to boot a dual 970FX G5 (PowerMac7,3). I'm not sure what
the relevant parts you need are, but after the initial start it
switches to a reverse video terminal mode, runs for a bit and prints
about a screenful of data ending with


time_init: decrementer frequency 33.33 Mhz
smp_core99_probe
smp_core99_kick_cpu
smp_core99_kick_cpu done
smp_core99_setup_cup 0 done

2.6.12-sven64


which I copied by hand. If you need some other input from earlier let
me know what you are looking for (its a pain to copy it all by
hand). Here is the cpuinfo for this machine running 2.6.8-power4-smp

~$ cat /proc/cpuinfo 
processor   : 0
cpu : PPC970FX
clock   : 2000MHz
revision: 3.0 (pvr 003c 0300)
bogomips: 1331.20

processor   : 1
cpu : PPC970FX
clock   : 2000MHz
revision: 3.0 (pvr 003c 0300)
bogomips: 1331.20

total bogomips  : 2662.40
machine : PowerMac7,3
motherboard : PowerMac7,3 MacRISC4 Power Macintosh 
detected as : 336 (PowerMac G5)
pmac flags  : 
L2 cache: 512K unified
memory  : 0MB
pmac-generation : NewWorld

Sorry for the sketchy info - my job has kept me off my G5 Linux box
for the last few months and I've lost touch with the little idea I had
about what is useful :-(

Cheers!
Shyamal


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

Bug#317853: clamav: source package gmp has been split

[Stephen Gran]

This one time, at band camp, Ray Kohler said:
> Details of the dependency change: libgmp3 has been split into libgmp3c2
> (C API) and libgmpxx3 (C++ portion). Dependencies need to point to the
> appropriate one (or both, if really needed).

This is handled automagically for me by the dh_shlibdeps call in
debian/rules.  I have checked, and it does the right thing.  When uploads
are possible again, this will be fixed.

thanks for reporting,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#319987: Segmentation fault in python: vte.Terminal.set_colors

[Ethan Glasser-Camp]

Package: python-vte
Version: 0.11.13-2

Attached is an example script that should set colors on a VTE Terminal widget to
be all white. It segfaults when run with the python-vte package.

I tracked the problem down to the python/vte.c file, in
_wrap_vte_terminal_set_colors(), line 472 or so:

if (PySequence_Check(py_palette)) {
palette_size = PySequence_Length(py_palette);
palette = g_malloc(sizeof(GdkColor) * palette_size);
for (i = 0; i < palette_size; i++) {
item = PySequence_GetItem(py_palette, i); /* INCREFs */
if (!pyg_boxed_check(item, GDK_TYPE_COLOR)) {
g_free(palette);
PyErr_SetString(PyExc_TypeError, "palette should be a list of 
GdkColors");
return NULL;
}
/*   Good here  */
palette[i] = *((GdkColor*)pyg_boxed_get(py_palette, GdkColor));
/*  Never get here -- ^ segfaults!!   */
printf("about to dec\n");
Py_DECREF(item);
printf("decremented successfully\n");
}
}

I think py_palette in this line should be changed to item. I haven't done any
strenuous testing, but this appears to make the program not seg fault.

Ethan
import gtk
import vte

w = gtk.Window()
v = vte.Terminal()
w.add(v)
v.show()
w.show()
black = gtk.gdk.Color(0, 0, 0)
white = gtk.gdk.Color(255, 255, 255)
palette = [gtk.gdk.Color(255,255,255) for x in range(8)]
v.set_colors(black, white, palette)
gtk.main()

Bug#100925: resproduce

[Joey Hess]

FYI, I can still reproduce this bug, four years after I filed it.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#129771: no, really, fix it

[Joey Hess]

In the meantime, NEWS.Debian has become available. It's the correct fix,
please use it.

Also, the existance of bugs like this tagged "wontfix" are one of the
reasons debconf will eventually drop its note facility completely. :-P

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#319985: libsnack2-doc: Please don't distribute file /usr/share/doc/libsnack2/examples/tcl/tclkit-linux-x86

[Karl Chen]

Package: libsnack2-doc
Severity: normal


The file /usr/share/doc/libsnack2/examples/tcl/tclkit-linux-x86
looks to be a tclkit binary be precompiled by upstream.

The file is large and binary-only.  Instead, please depend:
tcl8.4 if necessary.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-quack+roar.cs.berkeley.edu
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Bug#319984: xserver-xorg: Aiptek driver doesn't throw proximity out events

[Andrea Briganti]

Package: xserver-xorg
Version: 6.8.2.dfsg.1-4
Severity: normal

The aiptek input driver is affected by a known bug that is capable to
freeze gtk applications.

Some gtk applications, as gimp, thinks the tablet is still in use and
doesn't give back control to mouse.

I suggest you to look at this link:

http://sourceforge.net/tracker/index.php?func=detail&aid=1117415&group_id=75377&atid=543737

The cvs release of this driver probably isn't affected by this bug and
it also fix xserver's crashes which occurs when the user switch to a virtual
terminal.

Please consider to test it in the next release.

Greetings.

-- Package-specific info:
Contents of /var/lib/xfree86/X.roster:
xserver-xfree86
xserver-xorg

/etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum.

X server symlink status:
lrwxrwxrwx  1 root root 17 2005-07-21 15:06 /etc/X11/X -> /usr/bin/X11/Xorg
-rwxr-xr-x  1 root root 1835416 2005-07-20 19:49 /usr/bin/X11/Xorg

Contents of /var/lib/xfree86/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:
:01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 
5200] (rev a1)

/etc/X11/xorg.conf does not match checksum in /var/lib/xfree86/xorg.conf.md5sum.

Xorg X server configuration file status:
-rw-r--r--  1 root root 4670 2005-07-26 04:43 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# XFree86 4.0 configuration generated by Xconfigurator

Section "ServerLayout"
Identifier "XFree86 Configured"
Screen  0  "Screen0" 0 0
InputDevice"Mouse0" "CorePointer"
InputDevice"Keyboard0" "CoreKeyboard"

# the following are entries for the tablet
#InputDevice "pen" 
#InputDevice "cursor"  "AlwaysCore"
#InputDevice "eraser"  "AlwaysCore"

EndSection

# By default, Red Hat Linux 6.0 and later use xfs

Section "Files"
FontPath"/usr/local/fonts/TrueType"
FontPath"/usr/X11R6/lib/X11/fonts/TrueType"
FontPath"/usr/X11R6/lib/X11/fonts/misc:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/100dpi:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/75dpi:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/Type1"
FontPath"/usr/X11R6/lib/X11/fonts/Speedo"
FontPath"/usr/X11R6/lib/X11/fonts/misc"
FontPath"/usr/X11R6/lib/X11/fonts/100dpi"
FontPath"/usr/X11R6/lib/X11/fonts/75dpi"
FontPath"unix/:7100"
EndSection

# Module loading section

Section "Module"
Load  "dbe" # Double-buffering
Load  "GLcore"  # OpenGL support NVIDIA OFF
Load"ddc"
Load  "dri" # Direct rendering infrastructure NVIDIA OFF
Load  "glx" # OpenGL X protocol interface NVIDIA ON
Load  "extmod"  # Misc. required extensions
Load  "v4l" # Video4Linux
Load"int10"
# Load  "pex5"  # PHIGS for X 3D environment (obsolete)
# Load  "record"# X event recorder
# Load  "xie"   # X Image Extension (obsolete)
# You only need the following two modules if you do not use xfs.
Load  "freetype" # TrueType font handler
Load  "type1"   # Adobe Type 1 font handler
EndSection

Section "InputDevice"
Identifier  "Keyboard0"
Driver  "keyboard"
Option  "XkbModel" "pc105"
Option  "XkbLayout" "it"
Option  "XkbRules"  "xorg"
EndSection

Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Device" "/dev/input/mouse1"
Option  "Protocol" "IMPS/2"
Option  "Emulate3Buttons" "off"
Option  "ZAxisMapping" "4 5"
Option  "SendCoreEvents" "true"

EndSection

Section "InputDevice"
Identifier  "pen"
Driver  "aiptek"
Option  "Device""/dev/input/aiptek"
Option  "Type"  "stylus"
Option  "Mode"  "absolute"
Option  "Cursor""stylus"
Option  "PressCurve" "10,25,95,100"
Option  "zMin" "0"
Option  "zMax" "512"
Option  "ZThreshold" "0"
Option  "USB"   "on"
Option  "KeepShape" "on"
Option  "debuglevel""1"
EndSection

Section "InputDevice"
Identifier  "cursor"
Driver  "aiptek"
Option  "Device""/dev/input/aiptek"
Option  "Type"  "cursor"
Option  "Mode"  "absolute"
Option  "Cursor""puck"
Option  "PressCurve" "10,25,95,100"
Option  "KeepShape" "on"
Option  "zMin" "0"
Option  "zMax" "512"
Option  "ZThreshold"  "0"
Option  "USB"   "on"
Option  "debuglevel""1"
EndSection

Section "InputDevice"
Identifier  "eraser"
Driver  "aiptek"
Option  "Device""/dev/input/aiptek"
Option  "Type"  "eraser"
Option  

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2005 at 05:52:54PM -0700, Steve Langasek wrote:
> On Tue, Jul 26, 2005 at 12:45:48AM +0100, Luke Kenneth Casson Leighton wrote:
> > On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote:
> 
> >  for this P120 (whatever) i have *shudder* had to use a
> >  2.2.10-compact-pci kernel.
> 
> >  there exists a kernel-image-2.4.18-bf2.4 (which i might try at some
> >  point).
> 
> Uh, 2.4.18-bf2.4 was built solely for use with the woody installer, and is
> only available in oldstable.  If you're considering using it as the kernel
> on a newly-installed system, 

 only as a drastic desperation measure, as you can see it is a step up
 from what the machine is _presently_ running...



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

Bug#319981: dia: antialiased hex grid drawn incorrectly

[Michael Deegan]

Package: dia
Version: 0.94.0-7
Severity: normal

Steps to reproduce:
- Start dia
- Turn off dynamic grid and turn on hex grid. Hex grid drawn correctly.
- Turn on antialiasing. Hex grid drawn incorrectly.

See attached screenshot.

Both vanilla dia and dia-gnome exhibit this effect.

I also couldn't help but notice that the 'Hex grid size' value has
absolutely no effect on the size of the hex grid.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (99, 'testing'), (98, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.11
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)

Versions of packages dia depends on:
ii  dia-common 0.94.0-7  Diagram editor (common files)
ii  dia-libs   0.94.0-7  Diagram editor (library files)
ii  libart-2.0-2   2.3.17-1  Library of functions for 2D graphi
ii  libatk1.0-01.8.0-4   The ATK accessibility toolkit
ii  libc6  2.3.2.ds1-22  GNU C Library: Shared libraries an
ii  libfreetype6   2.1.7-2.4 FreeType 2 font engine, shared lib
ii  libglib2.0-0   2.6.4-1   The GLib library of C routines
ii  libgtk2.0-02.6.4-3   The GTK+ graphical user interface 
ii  libpango1.0-0  1.8.1-1   Layout and rendering of internatio
ii  libpng12-0 1.2.8rel-1PNG library - runtime
ii  libpopt0   1.7-5 lib for parsing cmdline parameters
ii  libxml22.6.16-7  GNOME XML library
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information

-- 
__ 
Michael Deegan, Unix Server Administrator, Murdoch University. Ph +61893606967


dia-grid-hex-antialiased.png
Description: PNG image

Bug#319978: getty.8.gz: corners say AGETTY

[Dan Jacobson]

Package: util-linux
Version: 2.12p-4
Severity: minor
File: /usr/share/man/man8/getty.8.gz

Corners of page say AGETTY, but NAME is getty.
Bad when binding into a printed manual.


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

Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable

[Matt Kraai]

On Mon, Jul 25, 2005 at 12:19:00PM -0700, Bruce Korb wrote:
> Anyway, I'll replace "PATH_MAX" with 
> "MAXPATHLEN"
> and now define it thus:
> 
> #ifndef MAXPATHLEN
> #  ifdef PATH_MAX
> #define MAXPATHLEN   PATH_MAX
> #  else
> #define MAXPATHLEN   4096
> #  endif
> #else
> #  if defined(PATH_MAX) && (PATH_MAX > MAXPATHLEN)
> # undef  MAXPATHLEN
> # define MAXPATHLEN  PATH_MAX
> #  endif
> #endif
> 
> Ugly stuff
> 
> Thank you.  Regards, Bruce

Thanks for the quick reply, Bruce.  I'll apply Michael's minimal fix
for now and undo it once the next version is released.

-- 
Matt


signature.asc
Description: Digital signature

Bug#319977: deb.5.gz: vague reference to manual locations

[Dan Jacobson]

Package: dpkg-dev
Version: 1.10.28
Severity: wishlist
File: /usr/share/man/man5/deb.5.gz

I wish they wouldn't just say

   Please see the Debian Packaging Manual, section 2.2 for details
   of these files.
and
   SEE ALSO
   deb-old(5), dpkg-deb(1), deb-control(5), Debian Packaging Manual.

As the new user will have a hard time looking for the Debian Packaging
Manual:

$ dlocate Packaging
$ dlocate ackaging
$ ls /usr/share/debian-reference/
$ /usr/share/doc/
$ debian-reference
$ dhelp
$ lynx -dump file:///usr/share/doc/HTML/debian/index.html|grep -i packaging
  do an NMU, guidelines for porters, available packaging tools,
  This document describes the packaging of Python within the
So it must be who knows where.
$ wwwoffle -o 
http://debian.linux.org.tw/debian/dists/sid/Contents-i386.gz|zgrep -i packaging
No help.


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

Bug#319922:

[Dan Cunningham]

Thanks, that did it.  Not being a php expert, I'm not sure what that  
mod is, much less how it got installed but after many hours of  
googling I didn't even come close to finding that answer.  Thanks for  
your time.


D-


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

Bug#319979: proc_usb_info.txt.gz: added blank lines to reflect current format

[Dan Jacobson]

Package: kernel-doc-2.6.8
Version: 2.6.8-10
Severity: minor
File: /usr/share/doc/kernel-doc-2.6.8/Documentation/usb/proc_usb_info.txt.gz
Tags: upstream patch

Please forward to upstream maintainer.
Added blank lines to reflect current format.
Nobody can read that jumble without them.
Removed trailing whitespace.

*** proc_usb_info.txt.orig  2005-07-26 07:16:28.0 +0800
--- proc_usb_info.txt   2005-07-26 07:18:37.211825605 +0800
***
*** 22,24 
  You can then issue `cat /proc/bus/usb/devices` to extract
! USB device information, and user mode drivers can use usbfs 
  to interact with USB devices.
--- 22,24 
  You can then issue `cat /proc/bus/usb/devices` to extract
! USB device information, and user mode drivers can use usbfs
  to interact with USB devices.
***
*** 34,36 
  For more information on mounting the usbfs file system, see the
! "USB Device Filesystem" section of the USB Guide. The latest copy 
  of the USB Guide can be found at http://www.linux-usb.org/
--- 34,36 
  For more information on mounting the usbfs file system, see the
! "USB Device Filesystem" section of the USB Guide. The latest copy
  of the USB Guide can be found at http://www.linux-usb.org/
***
*** 135,137 
  is not used for transfers (such as for short packets).
! 
  The percentage is how much of the "reserved" bandwidth is scheduled by
--- 135,137 
  is not used for transfers (such as for short packets).
! 
  The percentage is how much of the "reserved" bandwidth is scheduled by
***
*** 199,201 
  |__Config info tag
! 
  USB devices may have multiple configurations, each of which act
--- 199,201 
  |__Config info tag
! 
  USB devices may have multiple configurations, each of which act
***
*** 230,232 
  of bus bandwidth, drivers must select a non-default altsetting.
! 
  Only one setting for an interface may be active at a time, and
--- 230,232 
  of bus bandwidth, drivers must select a non-default altsetting.
! 
  Only one setting for an interface may be active at a time, and
***
*** 299,300 
--- 299,301 
  E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
+ 
  T:  Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 4
***
*** 305,306 
--- 306,308 
  E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=255ms
+ 
  T:  Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=1.5 MxCh= 0
***
*** 311,312 
--- 313,315 
  E:  Ad=81(I) Atr=03(Int.) MxPS=   3 Ivl= 10ms
+ 
  T:  Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=  4 Spd=12  MxCh= 0


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

Bug#319973: FTBFS: Unable to find libpq-fe.h

[Matt Kraai]

Package: courier
Version: 0.47-4
Severity: serious
Tags: patch

courier fails to build because it cannot find libpq-fe.h, which has
moved from /usr/include/postgresql to /usr/include/postgresql/8.0:

> Compiling authpgsql.c
> In file included from authpgsql.c:19:
> authpgsql.h:8:22: error: libpq-fe.h: No such file or directory

The attached patch makes it look in the new location, which fixes the
problem.

-- 
Matt
diff -u courier-0.47/debian/rules courier-0.47/debian/rules
--- courier-0.47/debian/rules
+++ courier-0.47/debian/rules
@@ -49,7 +49,7 @@
--with-mysql-includes=/usr/include/mysql \
--with-mysql-libs=/usr/lib \
--with-authpgsql \
-   --with-pgsql-includes=/usr/include/postgresql \
+   --with-pgsql-includes=/usr/include/postgresql/8.0 \
--with-pgsql-libs=/usr/lib \
--without-authshadow \
--without-authvchkpw \


signature.asc
Description: Digital signature

Bug#319974: FTBFS: Needs to be compiled with -falign-functions=4

[Matt Kraai]

Package: clisp
Version: 2.33.2-10
Severity: serious

clisp fails to build because it is not compiled with
'-falign-functions=4':

> ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m 750KW -x 
> "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit))"
> C_CODE_ALIGNMENT is wrong. &EVAL-WHEN = 0x806673e.
> Add -falign-functions=4 to CFLAGS in the Makefile.

-- 
Matt


signature.asc
Description: Digital signature

Bug#319975: FTBFS: Undefined references to pthread functions

[Matt Kraai]

Package: ccs
Version: 0.trunk20050206-1
Severity: serious
Tags: patch

ccs fails to build because there are undefined references when it
tries to link ccs_tool:

> gcc -Wall -I. -I../config -I../include -I../lib -Wall -O2 
> -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE `xml2-config --cflags` 
> -DCCS_RELEASE_NAME=\"DEVEL.1121908234\" -I. -I../config -I../include -I../lib 
> -o ccs_tool ccs_tool.c update.c upgrade.c old_parser.c -L../lib `xml2-config 
> --libs` -L//usr/lib -lccs -lmagma -lmagmamsg -ldl
> update.c: In function 'get_doc_version':
> update.c:44: warning: pointer targets in passing argument 1 of 
> 'xmlXPathEvalExpression' differ in signedness
> update.c:58: warning: pointer targets in passing argument 1 of 'strlen' 
> differ in signedness
> update.c:63: warning: pointer targets in passing argument 1 of 'strlen' 
> differ in signedness
> update.c:70: warning: pointer targets in passing argument 1 of 'atoi' differ 
> in signedness
> update.c: In function 'update':
> update.c:153: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
> upgrade.c: In function 'upgrade_device_archive':
> upgrade.c:190: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
> /usr/lib/libmagma.a(global.o): In function `clu_connect':
> : undefined reference to `pthread_rwlock_wrlock'
...
> /usr/lib/libmagma.a(global.o): In function `clu_local_nodeid':
> : undefined reference to `pthread_rwlock_unlock'
> collect2: ld returned 1 exit status

The attached patch adds -lpthread to the link command, which fixes
this problem.

-- 
Matt
only in patch2:
unchanged:
--- ccs-0.trunk20050206.orig/ccs_tool/Makefile
+++ ccs-0.trunk20050206/ccs_tool/Makefile
@@ -25,7 +25,7 @@
 endif
 
 LDFLAGS+= -L${ccs_libdir} `xml2-config --libs` -L${libdir}
-LOADLIBES+= -lccs -lmagma -lmagmamsg -ldl
+LOADLIBES+= -lccs -lmagma -lmagmamsg -ldl -lpthread
 
 all: ccs_tool
 


signature.asc
Description: Digital signature

Bug#319976: FTBFS: Cannot move HTML documentation

[Matt Kraai]

Package: calc
Version: 2.02f-23
Severity: serious
Tags: patch

calc fails to build because it cannot move its HTML documentation,
which recent versions of texi2html place in a subdirectory:

> test -f stamp-build-calc || texi2html -doctype html2 -expandinfo -menu \
>  -split=chapter -Verbose  calc.texinfo;
> # Expanded: verbatim ifnotxml documentdescription ifnotplaintext html ifinfo 
> ifnotdocbook titlepage ifset menu copying ifnottex ifclear ifhtml 
> # created directory calc
> # putting result files into directory calc/
> # reading from calc.texinfo
> # using 'en' as document language
> # end of pass texi
> # end of pass structure
> ** `Interactive Tutorial' doesn't appear in menus
> ** `Top' is up for `Interactive Tutorial', but has no menu entry for this node
> # Writing elements:
> # Writing to calc/calc.html .** Unknown command [EMAIL PROTECTED]' (left as 
> is) (l. 245)
> [Top]
> # Writing to calc/calc_1.html ..
...
> # Writing to calc/calc_43.html .
> # writing Toc in calc/calc_toc.html
> # writing Overview in calc/calc_ovr.html
> # writing About in calc/calc_abt.html
> # that's all folks
> test -f stamp-build-calc || mv -f *.html debian/html
> mv: cannot stat `*.html': No such file or directory

The attached patch fixes this problem.

-- 
Matt
diff -u calc-2.02f/debian/local.mk calc-2.02f/debian/local.mk
--- calc-2.02f/debian/local.mk
+++ calc-2.02f/debian/local.mk
@@ -24,7 +24,7 @@
 
 CLEAN/calc::
test ! -d $(TMPTOP) || rm -rf $(TMPTOP)
-   rm -f $(package)*.html
+   rm -fr $(package)
rm -f $(package)*.info $(package)*.info-?? $(package)*.info-?
 
 build/calc:
@@ -37,7 +37,7 @@
test -f stamp-build-calc || $(MAKE) info
test -f stamp-build-calc || texi2html -doctype html2 -expandinfo -menu \
   -split=chapter -Verbose  $(package).texinfo;
-   test -f stamp-build-calc || mv -f *.html debian/html
+   test -f stamp-build-calc || mv -f $(package)/*.html debian/html
touch stamp-build-calc
 
 


signature.asc
Description: Digital signature

Bug#319022: Testing requirements stalled

[Shaun Jackman]

The testing requirements for libnjb-dev [1] says that it is...
trying to update libnjb from 2.1-1 to 2.1-2 (candidate is 14 days old) 
libnjb is waiting for ncurses 
ncurses is only 3 days old. It must be 5 days old to go in. 
ncurses is not yet built on m68k: 5.4-8 vs 5.4-9 (missing 7 binaries:

It's been saying that "ncurses is only 3 days old" for the past four
days. Any idea what's up?

Thanks,
Shaun

[1] http://bjorn.haxx.se/debian/testing.pl?package=libnjb-dev

Bug#319971: FTBFS: Doesn't build gnome-typing-monitor

[Matt Kraai]

Package: control-center
Version: 2.10.1-4
Severity: serious

control-center fails to build because it can't install
gnome-typing-monitor:

> dh_install -pgnome-control-center  
> cp: cannot stat `./debian/tmp/usr/bin/gnome-typing-monitor': No such file or 
> directory
> dh_install: command returned error code 256

gnome-typing-monitor isn't built because configure cannot find
XScreenSaverQueryInfo.  Adding a build-dependency on libxss-dev fixes
this problem.

-- 
Matt


signature.asc
Description: Digital signature

Bug#319972: FTBFS: Ambiguous calls to findHash

[Matt Kraai]

Package: criticalmass
Version: 0.9.11-1
Severity: serious

criticalmass fails to build because it contains ambiguous calls of
findHash:

> g++ -DHAVE_CONFIG_H -I. -I. -I.. -W -Wall -fno-exceptions -O2 
> -I/usr/include/SDL -D_REENTRANT -I/usr/X11R6/include -c -o ResourceManager.o 
> ResourceManager.cpp
> ResourceManager.cpp: In member function 'int 
> ResourceManager::getResourceSize(const std::string&)':
> ResourceManager.cpp:199: error: call of overloaded 'findHash(const 
> std::basic_string, std::allocator >&, 
> __gnu_cxx::hash_map std::string>, std::equal_to, 
> std::allocator >&)' is ambiguous
> ./FindHash.hpp:21: note: candidates are: _ValT* findHash(_KeyT&, 
> __gnu_cxx::hash_map<_KeyT, _ValT*, __gnu_cxx::hash<_Key>, 
> std::equal_to<_Key>, std::allocator<_ValT*> >&) [with _KeyT = const 
> std::basic_string, std::allocator >, _ValT 
> = DirectoryEntry]
> ./FindHash.hpp:39: note: _ValT* findHash(const _KeyT&, 
> __gnu_cxx::hash_map, 
> std::equal_to, std::allocator<_ValT*> >&) [with _KeyT = 
> std::basic_string, std::allocator >, _ValT 
> = DirectoryEntry]
> ResourceManager.cpp: In member function 'bool 
> ResourceManager::selectResource(const std::string&)':
> ResourceManager.cpp:246: error: call of overloaded 'findHash(const 
> std::basic_string, std::allocator >&, 
> __gnu_cxx::hash_map std::string>, std::equal_to, 
> std::allocator >&)' is ambiguous
> ./FindHash.hpp:21: note: candidates are: _ValT* findHash(_KeyT&, 
> __gnu_cxx::hash_map<_KeyT, _ValT*, __gnu_cxx::hash<_Key>, 
> std::equal_to<_Key>, std::allocator<_ValT*> >&) [with _KeyT = const 
> std::basic_string, std::allocator >, _ValT 
> = DirectoryEntry]
> ./FindHash.hpp:39: note: _ValT* findHash(const _KeyT&, 
> __gnu_cxx::hash_map, 
> std::equal_to, std::allocator<_ValT*> >&) [with _KeyT = 
> std::basic_string, std::allocator >, _ValT 
> = DirectoryEntry]

-- 
Matt


signature.asc
Description: Digital signature

Bug#319969: FTBFS: Invalid storage classes and labels at the end of compound statements

[Matt Kraai]

Package: chdrv
Version: 1.0.13p-2
Severity: serious
Tags: patch

chdrv fails to build because it uses an invalid storage class for the
declaration of cursor and because it contains labels at the end of
compound statements (not shown below):

> gcc -c -DCHSYS=\"/usr/share/chdrv/\" -DCHBIN=\"/usr/bin/\" 
> -DCHETC=\"/etc/chdrv/\"  -DUSE_BY_CHDAM -O2 -DDISABLE_CACHE 
> -DDISABLE_FUNCTION_KEY -DUSE_ELF chinese.c
> chinese.c: In function '_ch_swap_console':
> chinese.c:128: error: invalid storage class for function 'cursor'
> chinese.c:150: warning: pointer targets in assignment differ in signedness
> chinese.c:151: warning: pointer targets in assignment differ in signedness
> chinese.c: In function 'ch_change_console':
> chinese.c:168: error: invalid storage class for function 'cursor'
> chinese.c:178: warning: pointer targets in assignment differ in signedness
> chinese.c:179: warning: pointer targets in assignment differ in signedness
> chinese.c: In function 'demo_output':
> chinese.c:298: warning: pointer targets in passing argument 1 of 
> 'ch_system_showstr' differ in signedness
> chinese.c:299: warning: pointer targets in passing argument 1 of 
> 'ch_system_showstr' differ in signedness
> chinese.c: In function 'ch_drawsystem':
> chinese.c:325: warning: pointer targets in passing argument 1 of 
> 'ch_system_showstr' differ in signedness
> chinese.c:331: warning: pointer targets in passing argument 1 of 
> 'ch_system_showstr' differ in signedness
> chinese.c: In function 'ch_setwsize':
> chinese.c:1311: warning: pointer targets in assignment differ in signedness
> chinese.c:1312: warning: pointer targets in assignment differ in signedness
> chinese.c:1314: warning: pointer targets in assignment differ in signedness
> chinese.c:1320: warning: pointer targets in assignment differ in signedness
> chinese.c:1321: warning: pointer targets in assignment differ in signedness
> chinese.c: In function 'ch_screen_saver':
> chinese.c:1377: warning: pointer targets in passing argument 3 of 
> 'ch_drawstring' differ in signedness

The attached patch fixes these problems.

-- 
Matt
diff -u chdrv-1.0.13p/chdrv.c chdrv-1.0.13p/chdrv.c
--- chdrv-1.0.13p/chdrv.c
+++ chdrv-1.0.13p/chdrv.c
@@ -550,7 +550,6 @@
  }
   }
   }
- end_loop:
 }
 
 
only in patch2:
unchanged:
--- chdrv-1.0.13p.orig/chinese.c
+++ chdrv-1.0.13p/chinese.c
@@ -125,7 +125,6 @@
 void _ch_swap_console(int newconsole)
 {
   int i,j;
-  static void cursor();
   static VSC *swapscr = NULL;
 
   
@@ -165,7 +164,6 @@
 void ch_change_console(int newconsole)
 {
   int i,j,lastmode;
-  static void cursor();
 
   if (newconsole < 0 || newconsole >= CONS_NUM)
 return;
only in patch2:
unchanged:
--- chdrv-1.0.13p.orig/output.c
+++ chdrv-1.0.13p/output.c
@@ -207,6 +207,7 @@
   break;
 case '=':
   /*dump_screen();*/
+  break;
 }
   termstate->state = NORMAL;
   termstate->esc_state = NORMAL;


signature.asc
Description: Digital signature

Bug#319968: mtr-tiny: TTL of 30 is insufficient for some routes

[Konstantin Seiler]

Package: mtr-tiny
Version: 0.67-1
Severity: normal

mtr uses a maxTTL of 30 hops. However, today there are longer routes on the
net.

Today linux's default ttl is 64. Mtr should support this by either setting
maxTTL to a higher value (in mtr.c) or by offering a commandline option to
manually raise this value. (like traceroute does)

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.9kms4
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages mtr-tiny depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libncurses5 5.4-4Shared libraries for terminal hand

-- no debconf information


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

Bug#169584: defrag: patch for powerpc

[Ray Kohler]

Package: defrag
Version: 0.73pjm1
Followup-For: Bug #169584

I got this package to compile on powerpc. I don't think it's actually
usable yet, though - it fails every test in the testsuite with "bad
superblock" on trying to mount the "after" image. Hopefully, it's still
helpful.

--- buffers.c.orig  2005-07-25 20:42:45.0 -0400
+++ buffers.c   2005-07-25 20:42:45.0 -0400
@@ -427,7 +427,7 @@
/* Don't bother reading here if we are in readonly mode; there
   will be no need to write it back at any time. */
if (!readonly)
-   read_current_block (source, b->data);
+   read_current_block (source, (char*)b->data);
d2n(source) = 0;
n2d(b->dest_zone) = 0;
b->full = 1;
@@ -442,7 +442,7 @@
(unsigned long) b->dest_zone, 
(unsigned long) dest);
assert (b->in_use & b->full);
-   write_current_block (dest, b->data);
+   write_current_block (dest, (char*)b->data);
assert (!n2d(b->dest_zone));
assert (!d2n(dest));
d2n(dest) = b->dest_zone;

--- defrag.c.orig   2005-07-25 20:42:45.0 -0400
+++ defrag.c2005-07-25 20:42:45.0 -0400
@@ -712,7 +712,7 @@
 #ifndef NODEBUG
"d"
 #endif
-   )) != EOF)
+   )) != (char)-1)
switch (c)
{
case 'b':

--- e2dump.c.orig   2005-07-25 20:42:45.0 -0400
+++ e2dump.c2005-07-25 20:42:45.0 -0400
@@ -79,9 +79,9 @@
 static inline unsigned long bit_is_set(const void * addr, int nr)
 {
 # if powerpc
-   return 1UL & (((const int *) addr)[nr >> 5] >> (nr & 31)));
+   return 1UL & (((const int *) addr)[nr >> 5] >> (nr & 31));
 # else
-   return 1UL & (((const unsigned char *) addr)[nr >> 3] >> (nr & 7)));
+   return 1UL & (((const unsigned char *) addr)[nr >> 3] >> (nr & 7));
 # endif
 }
 #endif

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-powerpc
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Bug#319967: kernel-patch-xen: make-kpkg with --added_patches doesn't work

[Kai Hendry]

Package: kernel-patch-xen
Version: 2.0.6-1
Severity: normal

$ cp /boot/config-2.6.12-1-686 .config

frodo$ sudo make-kpkg kernel-image --added_patches xen --arch xen
Please ignore the warning about overriding and ignoring targets above.
These are harmless. They are only invoked in a part of the process
that tries to snarf variable values for the conf.vars file.
Makefile:530: /usr/src/linux-source-2.6.12/arch/xen/Makefile: No such file or 
directory
make[1]: *** No rule to make target 
`/usr/src/linux-source-2.6.12/arch/xen/Makefile'.  Stop.
make: *** [conf.vars] Error 2
frodo$ 

Shouldn't that work?

-- 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.12-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)

Versions of packages kernel-patch-xen depends on:
ii  bash  3.0-15 The GNU Bourne Again SHell
ii  grep-dctrl2.6.7  Grep Debian package information
ii  patch 2.5.9-2Apply a diff file to an original

kernel-patch-xen recommends no packages.

-- no debconf information


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

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM

[Jurij Smakov]

Hi,

On Mon, 25 Jul 2005, Luke Kenneth Casson Leighton wrote:


hi jurij,

i invite you to think ahead to when the 2.4 kernel is no longer
maintained.

i invite you to consider where debian will stand at that time with
respect to older hardware.

should debian be possible to install on older hardware in two,
three years time, or should people who are not as fortunate and
as computer literate as yourself, myself and mr horms, either
throw the machine away or utilise an alternative distribution?


I am sure that if you would post a message containing the above
three paragraphs to the debian-kernel mailing list, you could have
started a nice and constructive discussion.

To answer your questions, Debian is dropping support for older hardware 
all the time. The pure 386 processors are no longer supported. Woody was 
the last release to support sun4c, older Sun machines, and it looks like 
support for all 32-bit sparc hardware might be dropped for etch. And there 
is a chance that for architectures for which 2.6 works well, 2.4 kernel 
will not be included in it.


In the end of the day, it all comes to the question of whether it is worth 
to jeopardize the interests of majority of the users in favour of a tiny 
fraction. Old and low-memory hardware definitely can be supported, however 
that requires interested, skilled and dedicated people to work on it. 
Given that most members of the kernel team currently have their hands 
full, there is not much chance that anyone will be willing to do that. 
Also, considering how laughably small the price of 16- or 32-megabyte 
memory stick is these days, I see the demands for support of such 
extremely-low-memory machines pretty egocentric.



regarding the tone of my second report: you are entitled to
dismiss it, just as mr horms is equally entitled to dismiss
my first report.

dismissal and blatant disregard of reports, however, does not solve
problems.

_instant_ dismissal, especially dismissals that contain
assumptions that clearly indicate a lack of thought and
foresight, are guaranteed to drive me absolutely fucking nuts.


This is the quote from your original bug report (#319823):

| From: Luke Kenneth Casson Leighton <[EMAIL PROTECTED]>
| To: Debian Bug Tracking System <[EMAIL PROTECTED]>
| Subject: kernel-image-2.6-686: 2.6 debian kernels do not install on m/cs with 
<= 48mb RAM!!!
| Date: Mon, 25 Jul 2005 02:30:41 +0100
|
| Package: kernel-image-2.6-686
| Version: 2.6.5-2
   ^^^
Feel free to verify in the BTS that it is accurate. This clearly indicates 
that the kernel-image version you are filing report against is 2.6.5-2, 
which is older than the version in Sarge (2.6.8). So Horms was absolutely 
correctly telling you that 2.6.5 is not supported anymore. Yes, the 
explanation accompanying the closing was somewhat terse, but from my point 
of view your reaction to it was rude and unacceptable. And you have 
repeated the obviously incorrect version number in your second report too.


Best regards,

Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/   KeyID: C99E03CC


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

Bug#319959: (no subject)

[Bob Tanner]

I believe this is the correct regex you want?

if ($section =~ m/$check_section[\/.+]*/) {

-- 
Bob Tanner <[EMAIL PROTECTED]>  | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


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

Bug#319959: Little debug work

[Bob Tanner]

sub Strip_Subsection {
use DebPool::Config qw(:vars);

my($section) = @_;

if (!defined($section)) {
printf("section is not defined!\n");
return 'main';
}

my($check_section);
foreach $check_section (@{$Options{'sections'}}) {
printf("Strip_Subsection section='%s'\n", $section);
printf("Strip_Subsection check_section='%s'\n", $check_section);
if ($section =~ m/$check_section\/.+/) {
return $check_section;
}
}

return 'main';
}

Changed Strip_Subsection to the above and add a printf to PoolDir to see what 
Strip_Subsection returns.

Running this code against a package the has a 'Section: contrib' here is the 
debug output.

Strip_Subsection section='contrib'
Strip_Subsection check_section='custom'
Strip_Subsection section='contrib'
Strip_Subsection check_section='contrib'
PoolDir section=main

Note, section and check_section match, but  main is still returned.

Running this code against a package the has a 'Section: contrib/otherosfs' 
here is the debug output.

Strip_Subsection section='contrib/otherosfs'
Strip_Subsection check_section='custom'
Strip_Subsection section='contrib/otherosfs'
Strip_Subsection check_section='contrib'
PoolDir section=contrib

I think the problem is the match code

if ($section =~ m/$check_section\/.+/) {

That regex looks like it is requiring a / followed by 1 or more of anything, I 
believe the / should be option?

-- 
Bob Tanner <[EMAIL PROTECTED]>  | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


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

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM

[Steve Langasek]

On Tue, Jul 26, 2005 at 12:45:48AM +0100, Luke Kenneth Casson Leighton wrote:
> On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote:

>  for this P120 (whatever) i have *shudder* had to use a
>  2.2.10-compact-pci kernel.

>  there exists a kernel-image-2.4.18-bf2.4 (which i might try at some
>  point).

Uh, 2.4.18-bf2.4 was built solely for use with the woody installer, and is
only available in oldstable.  If you're considering using it as the kernel
on a newly-installed system, then it would seem support isn't of vital
importance to you after all.

>  ... would it not make an inordinate amount of sense to have a
>  kernel-image-2.6.N-bf2.6?

That wouldn't really be the right name for the flavor ("bf" refers to "boot
floppies", the old Debian installer), but I suppose a compact flavor that
statically enables a number of modules common to older hardware would be
feasible.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2005 at 05:06:49PM -0700, Steve Langasek wrote:

> Incidentally, I have no idea why this bug was filed against
> kernel-image-2.6-686; 

 ... because i believed it to be a... wossisname... dummy package
 (2.6.N ... 2.6.NN)

 oops.



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

Bug#319966: libboost-dev: 1.33 breaks linking with libboost-program-options

[Benjamin Redelings I]

Package: libboost-dev
Version: 1.32.0+1.33.0-cvs20050720-3
Severity: normal

Hello,
Unlike with boost 1.32, my program gets several "undefined 
reference" errors while linking.  For example, 

bali-phy.o: In function `parse_cmd_line(int, char**)':
bali-phy.C:(.text+0x3f21): undefined reference to 
`boost::program_options::options_description::options_description(std::basic_string, std::allocator > const&)'
bali-phy.C:(.text+0x4ae4): undefined reference to 
`boost::program_options::common_command_line_parser::run() const'

If this is due to a change in the program_options library, perhaps you 
could provide a note that old program continue to compile, but just 
won't link.

Also, libboost-doc doesn't contain update documentation for using 
libboost-program-options.  It's HTML doc files are just redirects to the 
current (1.32) boost manual pages on the web.  Boost should probably 
include actual documentation once 1.33 is released, if not before :P

-BenRI

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

Versions of packages libboost-dev depends on:
ii  libstdc++5-3.3-dev [libstdc++ 1:3.3.6-7  The GNU Standard C++ Library v3 (d
ii  libstdc++6-4.0-dev [libstdc++ 4.0.1-2The GNU Standard C++ Library v3 (d
ii  libstdc++6-dev [libstdc++-dev 3.4.4-5The GNU Standard C++ Library v3 (d

libboost-dev recommends no packages.

-- no debconf information


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

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM

[Steve Langasek]

On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote:
> Luke Kenneth Casson Leighton writes...

> > i invite you to think ahead to when the 2.4 kernel is no longer
> > maintained.

> > i invite you to consider where debian will stand at that time with
> > respect to older hardware.

> > should debian be possible to install on older hardware in two,
> > three years time, or should people who are not as fortunate and
> > as computer literate as yourself, myself and mr horms, either
> > throw the machine away or utilise an alternative distribution?

> The subject of the minimum system requirements for Debian is probably 
> something the Debian Release team should be tracking if they're not already. 
> I 
> don't know if sarge had minimum system requirements, I didn't find any in a 
> brief scan of the release notes.

I believe Joey Hess is the person who has the best handle on what the actual
minimum requirements are for installing sarge.  Joey, do you have anything
we could add to the sarge release notes for this, if it's not already in
there?

> Can a goal be added to the release goals for etch? Obviously supporting 32mb 
> would be nice since a lot of appliance type systems only have that, but 64mb 
> might be a more reasonable goal. In addition to "minimum" requirements, 
> "recommended" requirements might be a good idea too.

I think 48MB should still be a reasonable goal even with 2.6 kernels,
shouldn't it?  Whether 32 or 48 is the minimum for etch probably depends on
whether we insist on shipping etch as 2.6-only.

On Mon, Jul 25, 2005 at 04:17:10PM -0700, Matt Taggart wrote:
> Luke Kenneth Casson Leighton writes...

> >  my bug report invites you to consider the impact that such
> >  a policy decision "roll your own or install 2.4 on anything
> >  with <= 48mb of ram", made by mr horms, will have on the
> >  debian project.

> In reality, not much. But the nice thing about Debian is that it's built to 
> be 
> able to support the needs of minority groups, so there could be a solution 
> for 
> this group if there are people motivated to work on and maintain it. It's not 
> clear that there are though :(

Curiously, this bug report seems to be about the memory requirements of 2.6
ramdisks.  AIUI, it's still the hope that we'll have switched from
initrd-tools to an initramfs solution for etch, which should have the effect
of dropping the memory requirements significantly.

But I don't think it's the responsibility of the kernel maintainers to hold
back the hands of time where hardware obsoletion in concerned.  If 48MB is
the minimum that 2.6 will support, then someone who cares about machines
with less RAM than that needs to do the work to lower that bar.

Incidentally, I have no idea why this bug was filed against
kernel-image-2.6-686; that package does not contain *any* ramdisks, so
either Luke is complaining about the ramdisk used by d-i to boot 2.6, or the
ramdisk generated by initrd-tools, yes?  I can't tell which one, because his
bug report is uselessly vague and rant-oriented; otherwise, I'd reassign the
bug to the appropriate package.

> There is an organization in Portland, OR, USA called FreeGeek ( 
> http://freegeek.org ) that recycles computer equipment and turns it into as 
> many working computers as possible (running Debian) and donates them to 
> various groups around the world. They maintain a specification of the minimum 
> requirements for the systems they build. Currently this is,

> http://freegeek.org/freekbox.php
> * Pentium III 500 - 566mhz
> * 128MB RAM
> * 9 - 10 GB hard drive
> * 14x - 24x CD ROM drive
> * Floppy disk drive
> * 17 inch color monitor
> * 56k Modem
> * 10/100 Network card
> * Keyboard
> * Mouse
> * Speakers

> IMO, at any given time this spec is a good indication of what the minimal 
> system is to even attempt to run Debian on, anything less would be painful.

> If the debian-release team decides to come up with minimum system 
> requirements 
> for etch, I think a good place to aim for i386 would be slightly less than 
> whereever the freekbox spec is at the time.

Oh, well, I still have an AMD K6-450 with 128MB running sarge as my primary
mailserver.  It creaks under spamassassin's load from time to time, but it's
not painful enough for me to deal with trying to swap the hardware out
remotely.  Maybe this box will still be useful through the etch timeframe.
:)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#319965: libboost-date-time1.33.0: bad shlibs file

[Aaron M. Ucko]

Package: libboost-date-time1.33.0
Version: 1.32.0+1.33.0-cvs20050720-3
Severity: serious
Justification: Policy 8.6.3

libboost-date-time1.33.0 (like the other libboost*1.33.0 packages)
specifies a versioned dependency of 

libboost-date-time1.33.0 (<< 1.32.0+1.33.0-cvs20050721)

in its shlibs file.  This doesn't actually work the way you'd like it
to, because dpkg parses that as upstream version 1.32.0+1.33.0, Debian
revision cvs20050721, and consequently *less* than any Debian revision
of upstream version 1.32.0+1.33.0-cvs20050720.  Adding a -0 to the
upper bound will remedy that.

In the future, using a second + before cvs should avoid this failure
mode; however, that will not work now without introducing an epoch,
because dpkg considers foo+bar-baz to come before foo-bar-baz.  (You
can verify this with dpkg --compare-versions.)

Packages such as monotone that got built against the broken
libboost*1.33.0 packages will need rebuilding against fixed versions.

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

Versions of packages libboost-date-time1.33.0 depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:4.0.1-2GCC support library
ii  libstdc++6  4.0.1-2  The GNU Standard C++ Library v3

libboost-date-time1.33.0 recommends no packages.

-- no debconf information


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

Bug#319823: Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2005 at 12:03:48PM -0700, Matt Taggart wrote:
> Luke,
> 
> Sorry for the previous terse replies to your bug reports #319878 and #319823. 
> The debian-kernel team gets a lot of email/bugs and sometimes is quick to 
> response/close bugs without a lot of explanation.

 *sigh* yeh i know.  used to do that for samba mailing lists if i got
 too many in a day...

> I think what horms was trying to say was that your bug report listed 2.6.5 as 
> the kernel version you were reporting against and that Debian no longer 
> supports that kernel. Your second bug report seems to indicate that you've 
> tried 2.6.5-12 so that answers that question.

 no, i don't believe i've ever installed 2.6.5 - i do not know where
 that version number comes from.

 i raised the bug against the 2.6-686 package _not_ a specific version
 of the 2.6 kernel.


> The debian-kernel team could use your help in tracking down the problem. Have 
> you google'd to see if others are having the problem and have found a 
> solution 
> (maybe another distro has solved this?)? Can you try, as horms suggested, to 
> fix it yourself and then let the debian-kernel team know how to fix it so 
> they 
> can try, if possible, to integrate the fix in the generic kernels?

 will give that some thought.




> I agree with your comment about 2.6 requiring a lot of memory, I guess this 
> is 
> the price we pay for supporting more hardware. Maybe there's a solution that 
> would allow for modular ramdisks or something so that you wouldn't need so 
> much memory if you didn't need all the drivers? Or maybe a special low-mem 
> kernel maintained by the people who needed it?
> 
> I think at some point the only way of supporting such hardware will be to 
> stay 
> on old releases. You might already have trouble running 
> dselect/apt-get/aptitude on a box with 48mb.

 apt-get runs fine (but phil hands runs apt-get on a really
 badly designed P90 machine and it takes forrreeer
 like twenty minutes to run apt-get update! )
 
 i've never used dselect or aptitude so i couldn't tell you there.




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

Bug#163653: new CAN number CAN-2005-2356

[Joey Hess]

The previous CAN number for this hole, CAN-2005-2355, was accidentially
used in some Red Hat advisory and to avoid confusion, Mitre has assigned
a new CAN number, CAN-2005-2356. Please use the new one in any changelog
entries.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#316454: fetchmail: Puts localhost into Received header instead of hostname

[Matthias Andree]

Please try adding a line like this to your .fetchmailrc and let me know
if it helps (yes it will report errors for obvious reasons - note that
"skip" doesn't work):

poll dummy.invalid with proto ETRN no dns

-- 
Matthias Andree


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

Bug#319964: No way to find the archive of a source package

[Daniel Burrows]

Package: libapt-pkg-dev
Version: 0.6.38
Severity: wishlist

  I'd like to allow archive specifiers to be attached to commands that take a 
source package name (like "aptitude changelog").  However, the information 
that I can get through the public interface of apt-pkg doesn't seem to be 
sufficient to find out which archive a particular source package belongs to.  
As far as I can tell, the archive information is stored in the Dist field of 
metaIndex; while you can reach an IndexFile from a pkgSrcRecords::Parser 
object, there's no route that I can find to get your hands on either the Dist 
or the corresponding metaIndex.

  The most obvious way of addressing this that I can see is to add a link from 
the IndexFile objects to their corresponding metaIndex, and perhaps to add an 
Archive() convenience routine to look up the archive of a Parser.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|  swapon /dev/ram  |
\- Does your computer have Super Cow Powers? --- http://www.debian.org -/


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

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote:
 
> It would probably be a good idea to record what ought to work in any given 
> release and maybe have an ongoing idea what it should be. The answer might be 
> architecture specific? ISTR either the d-i team or apt/dpkg/aptitude trying 
> to 
> get sarge systems with 32mb working towards the end of the release.

 if you really want to try that out, without messing with
 older hardware, try usin XEN.

 you will find that XEN guest domains fail to boot in 32mb on
 a 2.6 kernel.

 but at least it can be attempted - easily.


 *another thinks*...

 for this P120 (whatever) i have *shudder* had to use a
 2.2.10-compact-pci kernel.

 there exists a kernel-image-2.4.18-bf2.4 (which i might try at some
 point).

 ... would it not make an inordinate amount of sense to have a
 kernel-image-2.6.N-bf2.6?

 l.



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

Bug#319922: GDB dump

[Steve Langasek]

On Mon, Jul 25, 2005 at 02:08:40PM -0600, Dan Cunningham wrote:
> Running apache2 through gdb gives me this upon login...

And what does this backtrace look like if you *aren't* using php4-apd?

-- 
Steve Langasek
postmodern programmer

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1213844832 (LWP 11819)]
> 0xb7bcd563 in strlen () from /lib/tls/i686/cmov/libc.so.6
> (gdb) bt
> #0  0xb7bcd563 in strlen () from /lib/tls/i686/cmov/libc.so.6
> #1  0xb78a5205 in _estrdup () from /usr/lib/apache2/modules/libphp4.so
> #2  0xb7453f5b in mkCallStackEntry () from /usr/lib/php4/20020429/apd.so
> #3  0xb745440c in apd_get_active_function_name ()
>from /usr/lib/php4/20020429/apd.so
> #4  0xb7454eb2 in apd_execute_internal () from /usr/lib/php4/20020429/apd.so
> #5  0xb78accf8 in call_user_function_ex ()
>from /usr/lib/apache2/modules/libphp4.so
> #6  0xb78979c4 in php_end_ob_buffer () from
> /usr/lib/apache2/modules/libphp4.so
> #7  0xb7897b4e in php_end_ob_buffers ()
>from /usr/lib/apache2/modules/libphp4.so
> #8  0xb7885368 in php_request_shutdown ()
>from /usr/lib/apache2/modules/libphp4.so
> #9  0xb78c9c90 in execute () from /usr/lib/apache2/modules/libphp4.so
> #10 0xb78c9f6a in execute () from /usr/lib/apache2/modules/libphp4.so
> #11 0x080783a5 in ap_run_handler ()
> #12 0x080789b0 in ap_invoke_handler ()
> #13 0x08069c9a in ap_process_request ()
> #14 0x0806512d in _start ()
> #15 0x082b92a0 in ?? ()
> #16 0x0004 in ?? ()
> #17 0x082b92a0 in ?? ()
> #18 0x0808373c in ap_run_pre_connection ()
> #19 0x080835f5 in ap_run_process_connection ()
> #20 0x080769a4 in ap_graceful_stop_signalled ()
> #21 0x08076bbb in ap_graceful_stop_signalled ()
> #22 0x08076c18 in ap_graceful_stop_signalled ()
> #23 0x0807748a in ap_mpm_run ()
> #24 0x0807dabd in main ()


signature.asc
Description: Digital signature

Bug#319730: .deskop file misplaced

[Matt Zimmerman]

On Sun, Jul 24, 2005 at 12:25:52PM -0700, Thomas Bushnell BSG wrote:
> Magnus Therning <[EMAIL PROTECTED]> writes:
> 
> > Subject: gnucash-common: .desktop file misplaced
> > Package: gnucash-common
> > Version: 1.8.9-4ubuntu2
> > Severity: normal
> >
> > *** Please type your report below this line ***
> >
> > The .desktop file should be placed in /usr/share/applications to follow
> > the freedesktop.org specification.
> 
> I'm sorry, can you confirm whether this problem is in the  Debian
> package?  You have reported this against a package I don't maintain.
> 
> Also, can you be specific about exactly which file you are speaking
> of?

He's talking about /usr/share/gnome/apps/Applications/gnucash.desktop.

Yes, this should have been reported to Ubuntu instead.

Yes, reportbug in Ubuntu does this by default.

-- 
 - mdz


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

Bug#319721: vobcopy: error when filenames end with ";?"

[Robos]

On Sun, 24.07.05, Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> Package: vobcopy
> Version: 0.5.14-2
> 
> Some DVDs have filenames ending with a semicolon and a question mark
> (";?"). vobcopy does not deal with them correctly. Attached is a patch
> containing the changes I did to make them work with at least one of the
> disks I have (the only one I've tested so far, however, but it works at
> least).
> 

> diff -ru vobcopy-0.5.14/vobcopy.c vobcopy-0.5.14.fixed/vobcopy.c
> --- vobcopy-0.5.14/vobcopy.c  2004-11-22 21:12:46.0 +0200
> +++ vobcopy-0.5.14.fixed/vobcopy.c2005-07-24 13:04:53.0 +0300
> @@ -1112,6 +1112,14 @@
>{
>off_t culm_single_vob_size = 0;
>int a, subvob; 
> +  int len, offset;
> +  
> +  len = strlen(input_file);
> +  if (len > 2 && strcmp(input_file + len - 2, ";?") == 0)
> + offset = len - 7;
> +else
> +offset = len - 5;
> +  
>  //printf( "debug: title = %d \n", title_nr );
>
>subvob = ( directory->d_name[7] - 48 );
> @@ -1119,7 +1127,7 @@
>
>for( a = 1; a < subvob; a++ )
>  {
> -   input_file[ strlen( input_file ) - 5 ] = ( a + 48 
> );
> +   input_file[ offset ] = ( a + 48 );
> if( stat( input_file, &buf ) < 0 )
>   {
>  fprintf( stderr, "Can't stat() %s.\n", 
> input_file );

There is already some code in vobcopy to deal with ";?" but obviously not
enough :) I take a look at your patch and merge it with my modifications
also already in that direction. Thanks a lot for your help and input.
Cheers
Robos
-- 
Robos - 
gpg --recv-keys --keyserver blackhole.pca.dfn.de 6EEADA09
It's GNU/Linux dammit! F U M $ !


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

Bug#319963: CXX ABI change needs renaming of package libofx1 to libofx1c2

[Micha Lenk]

Package: libofx1
Version: 1:0.7.0-7
Severity: important
Tags: patch

I would appreciate an upload of package libofx1c2 because I need a
package of libOFX which has passed the CXX ABI change.

A patch is already available from Ubuntu at
http://people.ubuntu.com/~scott/patches/libofx/

-- 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.8-2-686
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]

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 deb ian kernels do not install on m/cs with <= 48mb RAM

[Matt Taggart]

debian-release cc'd due to minimum system requirement stuff mentioned in a 
previous message...

Luke Kenneth Casson Leighton writes...

>  my bug report invites you to consider the impact that such
>  a policy decision "roll your own or install 2.4 on anything
>  with <= 48mb of ram", made by mr horms, will have on the
>  debian project.

In reality, not much. But the nice thing about Debian is that it's built to be 
able to support the needs of minority groups, so there could be a solution for 
this group if there are people motivated to work on and maintain it. It's not 
clear that there are though :(

>  when the 2.4 kernel is no longer maintained / supported
>  by debian, in oh [wild guess] 2-3 years time, anyone not
>  sufficiently technically competent who is using debian on
>  such older hardware is left completely shafted.

Yes, but Debian supported those users far longer than any other major 
distribution, they abandoned older hardware a long time ago. Just as Debian no 
longer supports 386/25 systems with 8mb RAM, there will come a day when it no 
longer makes sense to support pentium-90s with 48mb RAM. (I would argue we've 
passed it already...)

If users want to continue to keep this old hardware limping along, I don't 
think it's unreasonable that they have the competency to do it themselves 
instead of being a burden on the developers and majority of the user base. 
Users who can't can upgrade their hardware, Debian's minimum config will 
always be a system that is nearly free to obtain in most countries around the 
world.

There is an organization in Portland, OR, USA called FreeGeek ( 
http://freegeek.org ) that recycles computer equipment and turns it into as 
many working computers as possible (running Debian) and donates them to 
various groups around the world. They maintain a specification of the minimum 
requirements for the systems they build. Currently this is,

http://freegeek.org/freekbox.php
* Pentium III 500 - 566mhz
* 128MB RAM
* 9 - 10 GB hard drive
* 14x - 24x CD ROM drive
* Floppy disk drive
* 17 inch color monitor
* 56k Modem
* 10/100 Network card
* Keyboard
* Mouse
* Speakers

IMO, at any given time this spec is a good indication of what the minimal 
system is to even attempt to run Debian on, anything less would be painful.

If the debian-release team decides to come up with minimum system requirements 
for etch, I think a good place to aim for i386 would be slightly less than 
whereever the freekbox spec is at the time.

-- 
Matt Taggart
[EMAIL PROTECTED]




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

Bug#319962: powernowd: README should mention acpi-cpufreq

[Kai Hendry]

Package: powernowd
Version: 0.96-2
Severity: normal

Wasted a few hours discovering that I need acpi-cpufreq in my
/etc/modules to make powernowd. Here is a complete list for my Thinkpad
T30:

# /etc/modules: kernel modules to load at boot time.
#
# This file should contain the names of kernel modules that are
# to be loaded at boot time, one per line.  Comments begin with
# a "#", and everything on the line after them are ignored.

ide-cd
ide-detect
ide-disk
psmouse
battery
ac
thermal
processor
acpi-cpufreq
cpufreq-userspace

-- 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.12-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)

Versions of packages powernowd depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an

powernowd recommends no packages.

-- no debconf information


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

Bug#319961: nagat: Requires php with register_globals

[Mozai]

Package: nagat
Version: 1.0a2-6
Severity: minor


"register_globals is off. This means you have PHP 4.2 or higher. Nagat
was initially made with 4.0.6 and will in the future make sure that your good 
choice will be respected.  For now, set it to 'on' or just sit tight and hope 
it will be fixed in next release of Nagat ;)."

register_globals in PHP considered harmful.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1)

Versions of packages nagat depends on:
ii  apache2-mpm-prefork 2.0.54-4 traditional model for Apache2
ii  debconf 1.4.52   Debian configuration management sy
ii  nagios-text [nagios 2:1.3-cvs.20050402-4 A host/service/network monitoring 
ii  php44:4.3.10-15  server-side, HTML-embedded scripti
ii  php4-cgi4:4.3.10-15  server-side, HTML-embedded scripti
ii  php4-gd 4:4.3.10-15  GD module for php4
ii  php4-mysql  4:4.3.10-15  MySQL module for php4
ii  php4-pgsql  3:4.3.10-5   PostgreSQL module for php4
ii  wwwconfig-common0.0.43   Debian web auto configuration

nagat recommends no packages.


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

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 deb ian kernels do not install on m/cs with <= 48mb RAM

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2005 at 04:17:10PM -0700, Matt Taggart wrote:
> debian-release cc'd due to minimum system requirement stuff mentioned in a 
> previous message...
> 
> Luke Kenneth Casson Leighton writes...
> 
> >  my bug report invites you to consider the impact that such
> >  a policy decision "roll your own or install 2.4 on anything
> >  with <= 48mb of ram", made by mr horms, will have on the
> >  debian project.
> 
> In reality, not much. But the nice thing about Debian is that it's built to 
> be 
> able to support the needs of minority groups, so there could be a solution 
> for 
> this group if there are people motivated to work on and maintain it. It's not 
> clear that there are though :(
 
 yeh, *sigh*.

> >  when the 2.4 kernel is no longer maintained / supported
> >  by debian, in oh [wild guess] 2-3 years time, anyone not
> >  sufficiently technically competent who is using debian on
> >  such older hardware is left completely shafted.
> 
> Yes, but Debian supported those users far longer than any other major 
> distribution, they abandoned older hardware a long time ago. Just as Debian 
> no 
> longer supports 386/25 systems with 8mb RAM, there will come a day when it no 
> longer makes sense to support pentium-90s with 48mb RAM. (I would argue we've 
> passed it already...)

 :)
 
 makes a perfectly good email, squid proxy and web server, dammit

 dude, i've even given machines with this kind of spec to kids!!

 embarrassingly, because the machine hadn't been used for 10 years,
 it blew up within 24 hours.

 ... unlike my email/squid/web server which has been in constant use,
 recently acquired, and therefore is still going, and i honestly believe
 that it won't need replacing until the solder whiskers grow and fries
 it some time in the next five years.


> If users want to continue to keep this old hardware limping along, I don't 
> think it's unreasonable that they have the competency to do it themselves 
> instead of being a burden on the developers and majority of the user base. 
> Users who can't can upgrade their hardware, Debian's minimum config will 
> always be a system that is nearly free to obtain in most countries around the 
> world.
> 
> There is an organization in Portland, OR, USA called FreeGeek ( 
> http://freegeek.org ) that recycles computer equipment and turns it into as 
> many working computers as possible (running Debian) and donates them to 
> various groups around the world. They maintain a specification of the minimum 
> requirements for the systems they build. Currently this is,
> 
> http://freegeek.org/freekbox.php
> * Pentium III 500 - 566mhz
> * 128MB RAM
> * 9 - 10 GB hard drive
> * 14x - 24x CD ROM drive
> * Floppy disk drive
> * 17 inch color monitor
> * 56k Modem
> * 10/100 Network card
> * Keyboard
> * Mouse
> * Speakers

 ah.  this is the kind of spec that i would consider _perfect_
 for "reasonable" desktop computer use - as long as you don't
 then try to put gnome or kde 3.4 on it (it's _just_ useable
 with kde 3.3).

 heck - i only just helped replace some pentium III 800s with
 128mb ram last month, and due to new staff have had to bring
 some of those machines back into service!

 
 <= 64mb ram and <= pentium 200 is only truly sane for use as servers.

 
 in conclusion, matt, much against my frugal and nostalgic
 ethos, i believe that you are right: your comments make a lot
 of sense [that pentium-I machines are now basically _really_
 out there, and so can go hang but if you can get it to work,
 great, and good luck].

 i wish that mr horm's message had contained even the _briefest_
 reference to something like this.
 
 l.



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

Bug#319922: GDB dump

[Adam Conrad]

Dan Cunningham wrote:
> Running apache2 through gdb gives me this upon login...
> 
> #2  0xb7453f5b in mkCallStackEntry () from /usr/lib/php4/20020429/apd.so

And what happens if you disable apd?  Even if it still segfaults, THAT
backtrace would be far more useful.

... Adam


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

Bug#317034: [EMAIL PROTECTED]: Bug#317034: add --bind commandline/configuration option]

[Brian Almeida]

- Forwarded message from Filippo Giunchedi <[EMAIL PROTECTED]> -

>From bma  Tue Jul  5 14:50:45 2005
Subject: Bug#317034: add --bind commandline/configuration option
Reply-To: Filippo Giunchedi <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
X-Debian-PR-Message: report 317034
X-Debian-PR-Package: gkrellmd
X-Debian-PR-Keywords: 
Date: Tue, 5 Jul 2005 20:27:38 +0200
From: Filippo Giunchedi <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
X-Editor: VIM - Vi IMproved 6.3
Organization: NoName Inc.
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2005_01_02

Package: gkrellmd
Severity: wishlist

Hi,
it would be nice to have the possibility to bind gkrellmd only on some ip
address and not 0.0.0.0 by default.

If time permits I'll try to post a patch although I'm not very familiar with
gkrellm's code.

thanks,
filippo



- End forwarded message -


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

Bug#312267: t1lib-old no longer exists

[Steve Langasek]

On Mon, Jul 25, 2005 at 03:34:29PM +0200, Artur R. Czechowski wrote:
> On Mon, Jul 25, 2005 at 04:45:44AM -0700, Steve Langasek wrote:
> > On Mon, Jul 25, 2005 at 12:08:55PM +0200, Artur R. Czechowski wrote:
> > > On Sun, Jul 24, 2005 at 03:33:22PM -0700, Debian Bug Tracking System 
> > > wrote:
> > > > Version: 1.3.1-9
> > > > t1lib-old is now removed from unstable.
> > > It does not assure that package will be removed from etch too[1].
> > > Have you an agreement with etch Release Manager about this bug. If not, I 
> > > am
> > > going to reopen it.
> > > [1] There is still a package depending on t1lib-old in etch.
> > Yes, I have personally NMUed that last package, and it should reach testing
> > soon after ftp-master.debian.org is back on-line, at which point t1lib-old
> > will be removed.  So, at least I don't *disagree* that the bug can be
> > closed. :)
> Enough for me :)

> > OTOH, it seems incorrect to list 1.3.1-9 as the version that this bug was
> > fixed in since 1.3.1-9 is the version still awaiting removal.  That seems
> > like a minor point to me, though.
> Is there a better way to do it with new version tracking subsystem in BTS?

You may want to ask the BTS admins.  My instinct is that the bug should be
left "open", and the BTS should automatically treat it as closed after a
period of time because of the package's removal, but I don't think it works
like this yet.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable

[Bruce Korb]

Hi Guys,

I have an image up on Source Forge:

  http://autogen.sf.net/data/autogen-5.7.2-semifinal.tar.gz

If it makes you-all happy, then I will release exactly  that image.

Regards, Bruce


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

Bug#319222: ghc6: Depends on non-existing package

[Steve Langasek]

On Mon, Jul 25, 2005 at 08:36:07PM +0200, Kurt Roeckx wrote:
> Marco Tulio Gontijo e Silva <[EMAIL PROTECTED]> wrote:
> > It depends on package libgmp3 which is not on the sid tree.

> That's because it was renamed to libgmp3c2 because of the C++ ABI
> transition.

> ghc6 probably just requires a rebuild, but I'm not sure wether
> the rest of the pacakges it depends on are ready.

Yes, libgmp is the only C++ lib that ghc6 depends on.  I had already talked
to the maintainer about doing a rebuild NMU for this (he isn't planning to
work on these packages until the new upstream version comes out), but if
someone beats me to it, that's fine too.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#319960: Please change the os name from KFreeBSD to kFreeBSD

[Aurelien Jarno]

Package: coreutils
Version: 5.2.1-2
Severity: minor
Tags: patch

Hi,

Sorry to bother you with so minor things, but currently uname returns
GNU/KFreeBSD instead of GNU/kFreeBSD (the k should be lower-case) as 
the system name. 

Please find attached a patch to fix that. It would be nice if you could
include it in the next upload. Also could you please forward it to
upstream?

Thanks for your cooperation,
Aurelien


-- System Information:
Debian Release: testing/unstable
Architecture: kfreebsd-i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: GNU/kFreeBSD 5.3-17
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages coreutils depends on:
ii  libc0.12.3-1+kbsd.10 GNU C Library: Shared libraries an

coreutils recommends no packages.

-- no debconf information
--- coreutils-5.2.1.orig/debian/patches/22_kbsd_name.diff
+++ coreutils-5.2.1/debian/patches/22_kbsd_name.diff
@@ -0,0 +1,28 @@
+diff -Nur coreutils-5.2.1.orig/configure coreutils-5.2.1/configure
+--- coreutils-5.2.1.orig/configure 2004-03-11 09:58:11.0 +0100
 coreutils-5.2.1/configure  2005-07-26 00:42:37.0 +0200
+@@ -8333,8 +8333,8 @@
+nonstopux*)os='NonStop-UX';;
+netbsd*-gnu*)  os='GNU/NetBSD';; # NetBSD kernel+libc, GNU userland
+netbsd*)   os='NetBSD';;
+-   knetbsd*-gnu)  os='GNU/KNetBSD';; # NetBSD kernel, GNU libc+userland
+-   kfreebsd*-gnu) os='GNU/KFreeBSD';; # FreeBSD kernel, GNU libc+userland
++   knetbsd*-gnu)  os='GNU/kNetBSD';; # NetBSD kernel, GNU libc+userland
++   kfreebsd*-gnu) os='GNU/kFreeBSD';; # FreeBSD kernel, GNU libc+userland
+msdosdjgpp*)   os='DJGPP';;
+mpeix*)os='MPE/iX';;
+mint*) os='MiNT';;
+diff -Nur coreutils-5.2.1.orig/m4/host-os.m4 coreutils-5.2.1/m4/host-os.m4
+--- coreutils-5.2.1.orig/m4/host-os.m4 2003-11-03 16:37:44.0 +0100
 coreutils-5.2.1/m4/host-os.m4  2005-07-26 00:42:27.0 +0200
+@@ -32,8 +32,8 @@
+nonstopux*)os='NonStop-UX';;
+netbsd*-gnu*)  os='GNU/NetBSD';; # NetBSD kernel+libc, GNU userland
+netbsd*)   os='NetBSD';;
+-   knetbsd*-gnu)  os='GNU/KNetBSD';; # NetBSD kernel, GNU libc+userland
+-   kfreebsd*-gnu) os='GNU/KFreeBSD';; # FreeBSD kernel, GNU libc+userland
++   knetbsd*-gnu)  os='GNU/kNetBSD';; # NetBSD kernel, GNU libc+userland
++   kfreebsd*-gnu) os='GNU/kFreeBSD';; # FreeBSD kernel, GNU libc+userland
+msdosdjgpp*)   os='DJGPP';;
+mpeix*)os='MPE/iX';;
+mint*) os='MiNT';;

Bug#319956: Broken link to http://www.windowsrefund.net/ on http://www.us.debian.org/releases/stable/i386/ch02s04.html.en

[Frank Lichtenheld]

Package: debian-installer-manual

Thanks for the report, forwarding it to the BTS entry of the install manual.

On Mon, Jul 25, 2005 at 08:56:31PM +0200, Tobias Nyström wrote:
> On page: 
> 
> http://www.us.debian.org/releases/stable/i386/ch02s04.html.en
> 
> there's a link to:
> 
> http://www.windowsrefund.net/
> 
> Which (sadly) does not exist anymore.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM

[Matt Taggart]

Luke Kenneth Casson Leighton writes...

> i invite you to think ahead to when the 2.4 kernel is no longer
> maintained.
> 
> i invite you to consider where debian will stand at that time with
> respect to older hardware.
> 
> should debian be possible to install on older hardware in two,
> three years time, or should people who are not as fortunate and
> as computer literate as yourself, myself and mr horms, either
> throw the machine away or utilise an alternative distribution?

The subject of the minimum system requirements for Debian is probably 
something the Debian Release team should be tracking if they're not already. I 
don't know if sarge had minimum system requirements, I didn't find any in a 
brief scan of the release notes.

It would probably be a good idea to record what ought to work in any given 
release and maybe have an ongoing idea what it should be. The answer might be 
architecture specific? ISTR either the d-i team or apt/dpkg/aptitude trying to 
get sarge systems with 32mb working towards the end of the release.

Can a goal be added to the release goals for etch? Obviously supporting 32mb 
would be nice since a lot of appliance type systems only have that, but 64mb 
might be a more reasonable goal. In addition to "minimum" requirements, 
"recommended" requirements might be a good idea too.

-- 
Matt Taggart
[EMAIL PROTECTED]




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

Bug#317853: clamav: source package gmp has been split

[Ray Kohler]

Package: clamav
Version: 0.86.1-2
Followup-For: Bug #317853

Details of the dependency change: libgmp3 has been split into libgmp3c2
(C API) and libgmpxx3 (C++ portion). Dependencies need to point to the
appropriate one (or both, if really needed).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-powerpc
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Bug#319952: locales not take into account when output is redirected

[Colin Watson]

On Tue, Jul 26, 2005 at 12:09:04AM +0200, Bas Zoetekouw wrote:
> Package: man-db
> Version: 2.4.3-1
> Severity: normal
> 
> It looks like man outputs only ASCII7 text if the output is redirected
> to a file or a pipe.  This even happens if the locale is explicitly
> specified on the command line.
> 
> For example, set your locale to de_DE.UTF-8, and compare the outputs
> of "man chsh", "man chsh|less" and "man -L de_DE.UTF-8|less".  The
> first one outputs nice utf8 German umlaut chars, but these chars are
> simply dropped in the latter two cases.
> 
> This breaks programs such as pinfo, which uses man as a backend for
> displaying man pages.
> 
> I would suggest that man just looks at the current locale (or adding a
> command line param that forces such behaviour).  Anyone who
> wants a clean ASCII7 text can simply set the correct locale, or
> specify -7 on the command line.

Actually, all locale support is still present. The problem is that man
pages being output to a file or a pipe are now filtered through 'col
-b', the intent of which was simply:

o When stdout is not a terminal, man pages will be formatted in
  plain text without the use of backspace or ANSI formatting
  characters.

Unfortunately, and unintentionally, this clobbers characters that aren't
printable ASCII. Bah. 'col -b -p -x' is much better, but exhibits some
minor corruption ("ÜBERSICHT" at the start of a line has some garbage
before it, probably because col can't handle the overstruck "Ü").

Changing the arguments to col seems to be obviously the right thing to
do, but beyond that I'm not sure what to do about this. I could reassign
to bsdmainutils in the hope that col can be changed to deal with UTF-8
in UTF-8 locales, or I could just disable the col command in the
pipeline for multibyte locales. The latter would be a shame given that
it means everyone has to go back to putting explicit 'col -b' in
makefiles and things again, and the breakage pending a col fix is
confined to just a few places ...

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Bug#319788: installation-reports: [sparc][netinst] attempt to access beyond end of device

[Joey Hess]

Geert Stappers wrote:
> Could you also check the new builds? Booting into Debian-installer is
> good enough (that is beyond the ramdisk size issue ) and quit.
> It wouldn't hurt your fresh installed system
> and it is good to known that is works again out of the box.

I expect my system "zebra" that was experiencing this before will try it
again in its next test run tomorrow. You can find the daily install logs
here: http://people.debian.org/~joeyh/d-i/test-logs.html

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#319959: debpool: [INSTALL/FATAL] Couldn't install package when changing pool location

[Bob Tanner]

Package: debpool
Version: 0.2.2
Severity: important


Change the archive_dir and uncommenting the pools_dir doesn't seem to
pick up the sections attribute

Config.pm
$Options{'archive_dir'} = '/var/ftp/linux/real-time-debpool';
$Options{'pool_dir'} = "$Options{'archive_dir'}/pool";
$Options{'sections'} = [ 'custom' ];
$Options{'archs'} = [ 'i386', 'powerpc', 'alpha', 'sparc' ];


2005-07-25 17:44:12 [GENERAL/DEBUG] Starting processing run
2005-07-25 17:44:12 [GENERAL/INFO] Processing changefile 
'showeq_5.0.0.25-1_i386.changes'
2005-07-25 17:44:13 [INSTALL/FATAL] Couldn't install package 'showeq': Failed 
to mkdir '/var/ftp/linux/real-time-debpool/pool/main/s/showeq': No such file or 
directory

This should be installed in
/var/ftp/linux/real-time-debpool/pool/custom/s/showeq

The weird part is that a 'sudo su - debpool /usr/bin/debpool' creates
the right directories.




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

Versions of packages debpool depends on:
ii  perl  5.8.7-4Larry Wall's Practical Extraction 

Versions of packages debpool recommends:
hi  gnupg 1.4.0-3GNU privacy guard - a free PGP rep
pn  libdigest-sha1-perl(no description available)
pn  libproc-daemon-perl(no description available)
ii  perl [libdigest-md5-perl] 5.8.7-4Larry Wall's Practical Extraction 

-- no debconf information


pool-tree.gz
Description: Binary data

Bug#319878: kernel-image-2.6-686: the entire range of 2.6 deb ian kernels do not install on m/cs with <= 48mb RAM

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2005 at 11:56:21AM -0300, Humberto Massa Guimar?es wrote:
> ** Luke Kenneth Casson Leighton ::
> 
> > telling people to "roll their own" kernel (mr horms) isn't an
> > acceptable option, either.  i may be able to do that (mr horms)
> > but other people won't be able to.
> > 
> > you going (mr horms) to tell me and people like me that i
> > should throw away perfectly good hardware
> 
> This was less than polite.
 
  so is out-of-hand dismissal of bug reports that clearly indicate a
  lack of thought and foresight, and such dismissal causes me to pretty
  much see red.

  
> > possible solutions:
> > 
> > * fix the bloody 2.6 kernel so it doesn't use so much damn memory.
> > 
> > * fix the debian-specific, debian-created and debian-responsible
> >   initrd ramdisk so it doesn't require so much damn memory.
> > 
> > * provide an alternate "compact" ramdisk if fixing the "default"
> >   ramdisk isn't a viable option.
> 
> Remember Debian is a volunteer-driven organization. Implement the features 
> you need yourself and then ask (politely) for the inclusion of your 
> contribution. Or, you can ask (more politely still) for someone more 
> knowledgeable than you (like Horms) to implement one of your suggestions. But 
> what you should NOT do is to demand features like your e-mail seemed to.
 
 if you read it carefully, you will note that the wording
 doesn't make any demands.  it _does_ however hint at some socially
 uncomfortable responsibilities.

 my bug report invites you to consider the impact that such
 a policy decision "roll your own or install 2.4 on anything
 with <= 48mb of ram", made by mr horms, will have on the
 debian project.

 when the 2.4 kernel is no longer maintained / supported
 by debian, in oh [wild guess] 2-3 years time, anyone not
 sufficiently technically competent who is using debian on
 such older hardware is left completely shafted.

 the machine which i cannot put a standard debian 2.6 kernel
 on is somewhere around a P90 or P150 i forget which and don't
 care which.

 anyone who is still installing debian linux on this kind of
 hardware is going to be either extremely technically competent
 or is going to be extremely poor or both.

 as a technically aware expert like yourselves, i am perfectly
 capable of "rolling my own" or "installing 2.4".

 other people less fortunate than you, myself or mr horms, can do no
 such thing.

 such people RELY on us to get these things right.

 _that's_ what makes me so ing angry and that's why i re-raised the
 bug report.

 l.

 p.s. 2.4 kernels don't support udev or hotplug.  what happens
 in two-three years time when packages start to critically
 depend on udev and hotplug?



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

Bug#319882: buddy(GNU/k*BSD): FTBFS: out of date config.sub/config.guess

[Aurelien Jarno]

Jens Peter Secher a écrit :

Hi,

Hi!


Sorry about the FTBFS, I'm sending you the new diff in a separate email.
If it is not too much trouble, could you confirm that this new version
will compile on GNU/k*BSD?


Thanks a lot for your reactivity. I confirm that this version works on 
GNU/k*BSD. BTW we are currently setting up a developer accesssible 
machine that will run GNU/kFreeBSD, so that would be easier for the 
Debian developers to do such checks.


Thanks,
Aurelien

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Bug#319957: debmirror: Should not say 'All done' until really all is done

[Frans Pop]

Package: debmirror
Version: 20050118
Severity: minor

Debmirror reports "All done" but then continues to clean up which on my
slow system takes quite a while. IMHO this is confusing.

It would be nice if some indication were given what it's doing at that
late stage and only say "All done" right before it exits.

Cheers,

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages debmirror depends on:
ii  bzip2 1.0.2-1A high-quality block-sorting file 
ii  libcompress-zlib-perl 1.33-3 Perl module for creation and manip
ii  liblockfile-simple-perl   0.2.5-4Simple advisory file locking
ii  libwww-perl   5.803-3WWW client/server library for Perl
ii  perl [libdigest-md5-perl] 5.8.4-5Larry Wall's Practical Extraction 
ii  perl-modules [libnet-perl]5.8.4-5Core Perl modules
ii  rsync 2.6.3-2fast remote file copy program (lik

-- no debconf information


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

Bug#262128: pinfo utf8 bug

[Bas Zoetekouw]

Hi Eduard!

Are you still able to reproduce bug #262128?  The man pages look fine
here.

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


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

Bug#319958: inkscape: fails to install (wrong dependencies)

[Cyril Brulebois]

Package: inkscape
Version: 0.41-5
Severity: grave
Tags: patch
Justification: renders package unusable

Hi!

When trying to install inkscape, it doesn't success due to dependency
problems:

  inkscape: Dépend: libgc1 mais il n'est pas installable
Dépend: libglibmm-2.4-1 (>= 2.6.1) mais ne sera pas installé
Dépend: libgtkmm-2.4-1 (>= 2.6.0) mais ne sera pas installé
Dépend: libsigc++-2.0-0 (>= 2.0.2) mais il n'est pas installable
E: Paquets défectueux

Rebuilding it 'as is' should be sufficient to refresh the dependencies (via
the ${shlibs:Depends} variable). I joined the diff between the official
dependencies and mine.

HTH

Best regards,

-- 
Cyril Brulebois



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (300, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10-1-386
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
 Depends
-libatk1.0-0 (>= 1.7.2)
+libatk1.0-0 (>= 1.9.0)
 libc6 (>= 2.3.2.ds1-21)
 libfontconfig1 (>= 2.3.0)
 libfreetype6 (>= 2.1.5-1)
-libgc1
-libgcc1 (>= 1:3.4.1-3)
+libgc1c2
+libgcc1 (>= 1:4.0.0-9)
 libglib2.0-0 (>= 2.6.0)
-libglibmm-2.4-1 (>= 2.6.1)
+libglibmm-2.4-1c2 (>= 2.6.1)
 libgtk2.0-0 (>= 2.6.0)
-libgtkmm-2.4-1 (>= 2.6.0)
+libgtkmm-2.4-1c2 (>= 1:2.6.0)
+libgtkspell0 (>= 2.0.2)
 libpango1.0-0 (>= 1.8.1)
 libpng12-0 (>= 1.2.8rel)
 libpopt0 (>= 1.7)
-libsigc++-2.0-0 (>= 2.0.2)
-libstdc++5 (>= 1:3.3.4-1)
+libsigc++-2.0-0c2 (>= 2.0.2)
+libstdc++6 (>= 4.0.1)
 libx11-6 | xlibs (>> 4.1.0)
 libxft2 (>> 2.1.1)
-libxml2 (>= 2.6.16)
-libxrender1
-libxslt1.1 (>= 1.1.12)
+libxml2 (>= 2.6.20)
+libxrender1 (>> 1:0.9.0-1)
+libxslt1.1 (>= 1.1.14)
 zlib1g (>= 1:1.2.1)

Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable

[Bruce Korb]

Hi Michael,

On Monday 25 July 2005 03:08 pm, Michael Banck wrote:

> The GNU C library manual (as in, libc.info.gz) suggests using
> canonicalize_file_name in chapter 14.5, "Symbolic Links":
> 
> Function: char * canonicalize_file_name (const char *NAME)
> 
>  The `canonicalize_file_name' function returns the absolute name of
>  the file named by NAME which contains no `.', `..' components nor
>  any repeated path separators (`/') or symlinks.  The result is
>  passed back as the return value of the function in a block of
>  memory allocated with `malloc'.  If the result is not used anymore
>  the memory should be freed with a call to `free'.

> I don't much about this though, so maybe this is bad advise.

Excellent advice.  You just need  to know about such functions.
The person who went to the trouble to say, "Never  use this function."
should also go to the trouble to add, "See Also: canonicalize_file_name"
Oh, well.  Thank you.  Since I am still futzing with the 5.7.2 release,
this will be very quickly added in.

Regards, Bruce


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

Bug#319938: Error on debian-control-with-duplicate-fields

[Frank Lichtenheld]

merge #319370 #319938
thanks

On Mon, Jul 25, 2005 at 10:45:10PM +0200, Michael Biebl wrote:
> I'm the maintainer of lksctp-tools. The debian/control file has amongst
> others two binary packages named lksctp-tools and lksctp-tools-doc. Running
> lintian gives me the following error messages:
[...]
> Obviously lintian believes that lksctp-tools and lksctp-tools-doc are
> the same binary package. Maybe it gets confused by the hyphen. Older
> versions of lintian didn't show this behaviour.

Known problem. Already fixed in SVN, waiting for ftp-master to come
back...

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Bug#319954: FTBFS on GNU/kFreeBSD

[Aurelien Jarno]

Package: sdlgfx
Severity: important
Tags: patch

Hello,

sdlgfx currently fails to build from sources on GNU/kFreeBSD. This is
due to the following reasons:
- config.{guess.sub} outdated
- libtool outdated

Please find attached a patch to fix that. I have patched libtool
manually, but you may prefer to update it with libtoolize. It's your 
choice!

Note that I also have changed DEB_HOST_ARCH into DEB_HOST_ARCH_CPU to
detect the i386 CPU instead of the debian i386 architecture.

Would it be possible to include this patch in the next upload of sdlgfx?

Thanks for your cooperation,
Aurelien


-- System Information:
Debian Release: testing/unstable
Architecture: kfreebsd-i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: GNU/kFreeBSD 5.3-17
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
diff -u sdlgfx-2.0.9/debian/rules sdlgfx-2.0.9/debian/rules
--- sdlgfx-2.0.9/debian/rules
+++ sdlgfx-2.0.9/debian/rules
@@ -6,12 +6,13 @@
 build-stamp:
dh_testdir
 
+   cp -f /usr/share/misc/config.{guess,sub} .
touch configure.in
touch aclocal.m4
touch configure
touch `find -name Makefile.in`
 
-ifeq ($(DEB_BUILD_ARCH),i386)
+ifeq ($(DEB_HOST_ARCH_CPU),i386)
./configure $(confflags) --prefix=/usr --enable-mmx
 else
./configure $(confflags) --prefix=/usr --disable-mmx
@@ -25,6 +26,7 @@
dh_testdir
dh_testroot
rm -f build-stamp
+   rm -f config.{guess,sub}
 
-$(MAKE) distclean
 
diff -u sdlgfx-2.0.9/debian/control sdlgfx-2.0.9/debian/control
--- sdlgfx-2.0.9/debian/control
+++ sdlgfx-2.0.9/debian/control
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Sam Hocevar (Debian packages) <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4.0), libsdl1.2-dev (>= 1.2.5-8)
+Build-Depends: debhelper (>= 4.0), libsdl1.2-dev (>= 1.2.5-8), autotools-dev
 Standards-Version: 3.6.1.1
 
 Package: libsdl-gfx1.2
only in patch2:
unchanged:
--- sdlgfx-2.0.9.orig/ltconfig
+++ sdlgfx-2.0.9/ltconfig
@@ -1361,7 +1361,7 @@
 ;;
 
   # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
-  freebsd*)
+  freebsd* | kfreebsd*-gnu)
 archive_cmds='$CC -shared -o $lib $libobjs $deplibs $linkopts'
 hardcode_libdir_flag_spec='-R$libdir'
 hardcode_direct=yes
@@ -1892,7 +1892,20 @@
 freebsd1*)
   dynamic_linker=no
   ;;
-
+
+kfreebsd*-gnu)
+  version_type=linux
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}.so$versuffix 
${libname}${release}.so$major $libname.so'
+  soname_spec='${libname}${release}.so$major'
+  finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
+  shlibpath_var=LD_LIBRARY_PATH
+  shlibpath_overrides_runpath=no
+  deplibs_check_method=pass_all
+  dynamic_linker='GNU ld.so'
+  ;;
+ 
 freebsd*)
   objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
   version_type=freebsd-$objformat

Bug#247484: d-i and ntpdate

[Frans Pop]

On Monday 25 July 2005 21:22, Joey Hess wrote:
> I welcome thoughts of suggestions on this matter..

Running ntpdate once during install should also be optional. Lots of 
people install Debian as a second OS and would not like d-i to mess with 
their hardware clock.

Running ntpdate also assumes quite a lot about network connectivity: is 
the port open; should a general ntp server be used or a local one (maybe 
DHCP can help there?).

Installing some kind of ntp service should be optional.
Also, personally I prefer chrony over ntp/ntpdate.

What about laptops that may not have networking at boot? You can setup ntp 
software to deal with that (chrony has a nice mechanism), but that would 
need to be done.

You are right there can be issues with ntp software: it often assumes a 
working RTC. At least for Sparc there is an issue with the RTC [1]. IIRC 
ntp was also affected.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301592


pgp8oMYX9qym9.pgp
Description: PGP signature

Bug#319955: FTBFS on GNU/kFreeBSD

[Aurelien Jarno]

Package: sdlperl
Severity: important
Tags: patch

Hi,

sdlperl currently fails to build on GNU/kFreeBSD. Please find below a
very simple patch to support it:

--- sdlperl-1.20.3.orig/Makefile.PL
+++ sdlperl-1.20.3/Makefile.PL
@@ -8,6 +8,7 @@
linux   => "Makefile.linux",
win32   => "Makefile.win32",
freebsd => "Makefile.freebsd",
+   gnukfreebsd => "Makefile.linux",
 );
 
 #

Actually Makefile.linux should be renamed into Makefile.glibc as it has
nothing specific to linux, it is rather specific to the glibc.

Could you please include this patch in the next upload?

Thanks for your cooperation,
Aurelien


-- System Information:
Debian Release: testing/unstable
Architecture: kfreebsd-i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: GNU/kFreeBSD 5.3-17
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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

Bug#267330: BTS spam

[Matt Taggart]

Justin Pryzby writes...

> You submitted this bug sometime last year, requesting that
> bugs.debian.org advertize the address to which spam should be
> reported.  I just noticed that bugs now have a link to a CGI which
> flags it as containing spam.
> 
> Does this satisfy your request?

Yeah I just noticed that today as well, maybe it got added along with all the 
other stuff at debconf?

It still might be useful to have the address listed somewhere for people who 
might want to report by email (assuming that will still be supported), but the 
cgi thing is more practical for me.

So guess leave it the bug open unless that email address isn't a preferred way 
to report spam. It should be easy to add. The only reason I can think of not 
to add it is that it would get spammed.

-- 
Matt Taggart
[EMAIL PROTECTED]




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

Bug#319950: Fixes for Flac support

[Michael Banck]

On Mon, Jul 25, 2005 at 11:53:18PM +0200, Robert Millan wrote:
> Package: jack
> Version: 3.1.1-3
> Severity: normal
> Tags: patch
> 
> This patch includes fixes for Flac support.  Basicaly:
> 
>   - Use only a command for best performance, and mark it as such by naming it
> "cmd" instead of "vbr-cmd".

Is flac incapable of doing VBR?

>   - Remove the "otf" command which includes invalid flags (probably was added
> for an old version of flac).

I asked the flac maintainer:

 azeem: if jack is using raw audio, you need all those flags.  if
not, you don't
 azeem: they have nothing to do with the compression; they're
setting the attributes of the raw stream
 azeem: if it's encoding a wav file, it gets that information from
the header instead

So this sounds consistent with on-the-fly to me, are you sure the
options are bad?


cheers,

Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Bug#319951: ttf-farsiweb: defoma errors on install

[pmaydell]

Package: ttf-farsiweb
Version: 0.4-1

Extract from apt-get log (edited to remove references to
irrelevant packages; full log available if required):

Setting up ttf-farsiweb (0.4-1) ...
Debian::Defoma::Id::defoma_id_register at line 60 in 
/var/lib/defoma/scripts/vflib2.defoma: (Nazli Bold, 
/usr/share/fonts/truetype/ttf-farsiweb/nazlib.ttf, 20): Illegal argument.
Regenerating /etc/vfontcap... done

I suspect that this is because defoma doesn't like fonts with
spaces in the name (but the defoma docs don't say explicitly that
that's wrong, and I'm no defoma expert, I just looked at the source
to see what causes that error message to be produced.)

The system is a stock 'sarge' and this was a first-time install of 
the package. This is architecture: alpha, but I don't think that
is likely to matter.

-- PMM


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

Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable

[Michael Banck]

On Mon, Jul 25, 2005 at 12:19:00PM -0700, Bruce Korb wrote:
> Hmm.  Interesting problem.   The "realpath(3C)" documentation
> specifically references PATH_MAX:
> 
> > NAME
> >realpath - return the canonicalized absolute pathname
> > 
> > SYNOPSIS
> >#include 
> >#include 
> >char *realpath(const char *path, char *resolved_path);
> > [...]
> > ERRORS
> > [...]
> >ENAMETOOLONG
> >   A component of a path name exceeded NAME_MAX
> >   characters,  or  an entire path name exceeded PATH_MAX
> >   characters.
> 
> and the code in question is only compiled in if "realpath" is known
> to be in the library.  And, yes, I know about the extended GNU doc:
> 
> > BUGS
> >Never  use this function. It is broken by design since it is
> >impossible to determine a suitable size for the output
> >buffer.  According to POSIX a  buffer of size PATH_MAX
> >suffices, but PATH_MAX need not be a defined constant, and
> >may have to be obtained  using  pathconf().   And  asking
> >pathconf() does not really help, since on the one hand POSIX
> >warns that the result of pathconf() may be huge and
> >unsuitable for mallocing  mem- ory.  And  on  the  other hand
> >pathconf() may return -1 to signify that
> >PATH_MAX is not bounded.
> 
> but since no viable alternative is suggested, it leaves one in a difficult
> spot.  

The GNU C library manual (as in, libc.info.gz) suggests using
canonicalize_file_name in chapter 14.5, "Symbolic Links":

Function: char * canonicalize_file_name (const char *NAME)

 The `canonicalize_file_name' function returns the absolute name of
 the file named by NAME which contains no `.', `..' components nor
 any repeated path separators (`/') or symlinks.  The result is
 passed back as the return value of the function in a block of
 memory allocated with `malloc'.  If the result is not used anymore
 the memory should be freed with a call to `free'.

 In any of the path components except the last one is missing the
 function returns a NULL pointer.  This is also what is returned if
 the length of the path reaches or exceeds `PATH_MAX' characters.
 In any case `errno' is set accordingly.

`ENAMETOOLONG'
  The resulting path is too long.  This error only occurs on
  systems which have a limit on the file name length.

`EACCES'
  At least one of the path components is not readable.

`ENOENT'
  The input file name is empty.

`ENOENT'
  At least one of the path components does not exist.

`ELOOP'
  More than `MAXSYMLINKS' many symlinks have been followed.

 This function is a GNU extension and is declared in `stdlib.h'.

So you could perhaps use this function if available (i.e. on GNU/Linux
and GNU/Hurd), and realpath() otherwise.  I don't much about this
though, so maybe this is bad advise.


cheers,

Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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