Bug#373611: Bug#373242: nslint: FTBFS: bashisms in debian/rules

[Gerrit Pape]

On Wed, Jun 14, 2006 at 06:53:31PM +0200, Sven Mueller wrote:
> Yes, but it barfs for a completely different reason than I would have
> expected. I could implement a small shell function which does those
> tests in the way /usr/bin/test would do them, but I suppose just calling
>  /usr/bin/test explicitly is easier, so I will stick with that for now.

I personally would have changed it to

 ! test -r /usr/share/misc/config.guess ||
  test config.guess -nt /usr/share/misc/config.guess ||
   cp /usr/share/misc/config.guess config.guess

Regards, Gerrit.


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

Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play

[Steinar H. Gunderson]

On Thu, Jun 08, 2006 at 02:06:01PM -0700, David Schleef wrote:
> GCC is really dumb in this area, since it often assumes things about
> stack alignment that just aren't true.  GCC doesn't even always follow
> the rules it assumes.
> 
> In general, liboil has been able to avoid these situations on other
> architectures, so I'll just fix the code here.

Is there any progress on this? This bug is currently (indirectly) what's
holding up removal of xorg-x11 from unstable, so I guess fixing it soonish
would be a good idea, if at all possible. :-) 

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Bug#373701: maradns: Microsoft doesn't follow DNS standards

[Kai Hendry]

Package: maradns
Version: 1.2.07.5-1
Severity: minor

Just for the record, maradns has had difficulty with Microsoft DNS
records due to Microsoft not following DNS standards:

http://marc.10east.com/?l=maradns-list&m=115025922705423&w=2

A development release has been made:
http://marc.10east.com/?l=maradns-list&m=115028228119584&w=2

It will be packaged when its proved stable.

-- 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.16-2-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages maradns depends on:
ii  adduser   3.87   Add and remove users and groups
ii  libc6 2.3.6-15   GNU C Library: Shared libraries

maradns recommends no packages.

-- no debconf information


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

Bug#372498: News about this bug? (ksynaptics: incompatible with xfree86-driver-synaptics 0.14.5-1)

[Christian Perrier]

Actually, after the various mail exchanges about this topic, I'd like
to thank Arnaud for all the good work on the *synaptics things.

I happen to have been partly the one reviving this because I worried
bout the #372498 bug which hit me hard and I'm glad that things are
currently setting up to solve all this.

I'm here "only" a user and certainly can't be of any help. But this is
actually the occasion to thank everybody involved in all this because
all these synaptics things have been, up to now, something that has
been pretty much transparent to me: it just used to work, that's
all..:-)

One last contribution I'd like to add is suggesting to add the
relevant packages to the "laptop" task in tasksel. Given that
synaptics and related touchpads are very common on laptops these days,
it seems pretty much relevant, imho.

xfree86-driver-synaptics is already listed there (should be replaced
by xserver-xorg-input-synaptics, I guess) but I think that both ksynaptics and
gsynaptics should also (given that the "desktop" tasks installs both
KDE and Gnome).

This is just a matter of sending a wishlist BR to tasksel, indeed.



signature.asc
Description: Digital signature

Bug#373700: posixtestsuite: Building the package as root on amd64 changes the system clock permanently

[Andreas Jochens]

Package: posixtestsuite
Version: 1.5.1-1
Severity: grave


Hello,


I created a clean amd64/unstable chroot environment and tried to build
the 'posixtestsuite' package inside the chroot as the root user with
'dpkg-buildpackage'. 


The build completed, but at the end of the build
the system clock had been changed to 2002-11-12 19:25:26.


I can reproduce this behaviour, i.e. every time I build the package on
amd64 the system clock is changed permanently during the build. 
The offsets are different in each case (ranging from a few days 
to a few years).


Regards
Andreas Jochens


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

Bug#373613: mozilla-firefox: missing extensions file produces unhelpful error messages

[Mike Hommey]

On Thu, Jun 15, 2006 at 08:00:26AM +1000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 
wrote:
> This seems pretty relevant.
> I am fairly sure no-one would have intentionally removed the file, this
> is why I am wondering if plugin/extension installation could cause the
> problem. I have tried out various extensions (eg for CSS editing) and
> mostly deleted them again. Installation of these usually requires running
> the browser as root.

Please don't install extensions as root. It's the best way to break
things. Though the extension manager is supposed to have been fixed by
our patches for this case, it is likely you're hitting some bug there.
Please try to install these extensions as a normal user, or find a
debian package for the extension.

Mike


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

Bug#373702: O: sawfish -- a window manager for X11

[Christian Marillat]

Package: wnpp
Severity: normal

I don't intent to spend my time with non-existent bug report like 368546.

The package description is:
 Sawfish is an extensible window manager using an Emacs Lisp-like scripting
 language--all window decorations are configurable, the basic idea is to
 have as much user-interface policy as possible controlled through the Lisp
 language. This is no layer on top of twm, but a wholly new architecture.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (900, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.17
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Bug#368546: bug 368546: Could this be caused by hardware overheating?

[Christian Marillat]

Graham <[EMAIL PROTECTED]> writes:

> Hi Christian,

Hi,

> I sometimes check the RC bug list, and this bug somewhat intrigued me.
>
> http://bugs.debian.org/368546
>
> I once saw symptoms somewhat like this on a laptop: the system was
> extremely slow, even with nothing running, and the load average was
> very high. It was running KDE.
>
> I believe it was a thermal issue: many current CPUs can throttle to
> very low speeds when they detect a severe overheat condition. In my
> case, blowing 3 years of dust out of the heatsinks seemed to solve the
> problem.
>
> So, I would suggest checking lm-sensors, and/or "acpi -V", both when
> the system is running properly, and when it is abnormally slow.
>
> Obviously I can't be sure whether this is a hardware or software
> problem, but checking the hardware is relatively easy to do, so it
> might be worthwhile.

Thanks for the comment, but you should send that to the BTS 5See the Cc:)

Christian


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

Bug#373699: debian-installer: installation will not complete

[Nizamov Shawkat]

Package: debian-installer
Severity: grave
Justification: renders package unusable

I tried to install Etch using last cd from 12.06.2006
Note thah I do not have access to online mirror on that PC and use "expert" mode
Installation silently fails after step "Choose and install software" - it will 
just go to the next step in menu (AFAIR it is "check cd-rom integrity")
After manually trying following steps in installation menu "Abort installation" 
comes at last. After rebooting I have bootable system but is is completely 
weird- 
for example, users that I have created have gone (no entry's in /etc/passwd), 
/etc/shadow is non-existent so only root with empty password is allowed and so 
on 

I tried this several times (at first I thought that was because of failing 
installation of console-cyrillic because of not available mirror) and even 
with all default values (excluding disk partiotioning) instalation just 
silently 
fails at the end, leaving installed system weird


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

Bug#373698: perlrun doesn't mention -CSD scoping

[Joey Hess]

Package: perl-doc
Version: 5.8.8-6
Severity: normal

perlrun doesn't mention that -CSD is scoped so it only affects the main
program file or -e line and not any modules or other files. But it seems
that it is:

[EMAIL PROTECTED]:~/src/ikiwiki>cat foo.pl 
#!/usr/bin/perl -CSD

sub readfile ($) {
my $file=shift;

local $/=undef;
open (IN, $file) || error("failed to read $file: $!");
my $ret=;
close IN;
return $ret;
}

use Encode;
print "utf: ".Encode::is_utf8(readfile("/etc/passwd"))."\n";

1
[EMAIL PROTECTED]:~/src/ikiwiki>./foo.pl
utf: 1
[EMAIL PROTECTED]:~/src/ikiwiki>perl -CSD -e 'do "foo.pl"'
utf: 

This is highly suprising when factoring previously utf-clean code out into
modules where it promptly breaks. :-( Needs a big warning IMHO.

-- 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.6.16-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages perl-doc depends on:
ii  perl  5.8.8-6Larry Wall's Practical Extraction 

perl-doc recommends no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#362282: alsa-base: No sound with Intel 82801G ICH7 (HDA) (solved)

[Miguel Filho]

I got a brand new Dell Latitude 120L, I installed debian testing and
dist-upgrade to unstable. Using default kernel 2.6.16 and sound was
not working. I'm a little newbie but this is what I did.

Using unstable and stock kernel package.

My sound card:

00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) High Definition Audio Controller (rev 03)

Looking at alsa bug track, varius sound problems with this type of
chip have been reported, and the latest version should fix.

Following varius instructions, `cat /proc/asound/version` showed to me
my alsa drivers was version 1.0.11rc2, that does not contain the fixes
needed.

So, I downloaded alsa-source package: aptitude install alsa-source

It downloads a /usr/src/alsa-driver.tar.bz2, that I think is the
1.0.11 final release.

After unziping, I entered in the modules/alsa-driver directory,
executed debian/rules binary_modules, and the package
alsa-modules-2.6.16-2-686_1.0.11-2_i386.deb was created.

It was not instalaled on the first try, because i have gcc 4.1, and it
is the default now, while the kernel is compiled with 4.0, so I
installed gcc 4.0 and changed de link gcc in /usr/bin go gcc-4.0, I
rellay don't know a elegant way to do this. Kernel headers for my
kernel were installed to.

After this, fire up alsaconf and my sound is working!

Now i got the alsa drivers 1.0.11 final loaded, I think that this was
the problem, the module that came with kernel package was causing the
trouble.

cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.11.
Compiled on Jun 15 2006 for kernel 2.6.16-2-686.


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

Bug#116500: Making Automake 1.9 the default in Ubuntu

[Eric Dorland]

* Scott James Remnant ([EMAIL PROTECTED]) wrote:
> On Mon, 2006-06-12 at 19:44 -0400, Eric Dorland wrote:
> 
> > * Scott James Remnant ([EMAIL PROTECTED]) wrote:
> > > I notice that with a recent change to automake-1.9 you have adjusted the
> > > priorities so that 1.9 is the default, instead of 1.4.  However this
> > > still does not solve many of the problems people have had in Ubuntu, so
> > > we've proposed a specification to transition the archive to the newest
> > > Automake and drop 1.4.
> > > 
> > >   https://wiki.ubuntu.com/AutomakeTransition
> > 
> > > As the Debian maintainer, we'd really appreciate your opinion on this;
> > > especially as there are several options listed which we have yet to
> > > choose between.
> > 
> > Looking at the wiki page, you have some good ideas there. From
> > Debian's perspective I think option 3 is a non-starter. Even if we
> > banish all automake 1.4 using packages from the distro there will
> > still be old code out there that will want it. But it is fairly
> > deprecated garbage at this point, so its use should be discouraged.
> > 
> I agree that Option #3 is probably not desirable, it was put there for
> completeness.
> 
> > Here's what I believe would make the most sense:
> > 
> Have added this to the wiki as Option 2b.
> 
> > For this to happen in Debian anything depending on automake would need
> > to be fixed. As of yesterday, 79 packages are still build depending on
> > "automake" by my reckoning. Most of these are likely trivial to
> > fix.
> > 
> This is certainly somewhere Ubuntu can help; we've had good results in
> the past by trialling migrations before Debian and providing them all
> the patches they need.
> 
> All of the 79 packages would receive patches which have already been
> shipped in a released distribution, which makes it somewhat easier for
> people to apply them.

I don't think Ubuntu should get all the fun :) I'm going to propose
this mass bug filing and transition to the release team. Obviously I
can't promise the release team will approve, but I'll get bugs filed
and start working on patches for these issues. 

I'll propose the other changes I outlined and point out the Ubuntu
proposals as well, and see what the general developer opinion of them
is. 
 
> It also makes it easier for you to change things in Debian because you
> can say "all packages are changed or have patches in the BTS" and then
> it's their fault if they brake.


-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6



signature.asc
Description: Digital signature

Bug#373697: clisp_1:2.38-5 (ia64/unstable): FTBFS: [interpreted.mem] Aborted

[Steve Langasek]

Package: clisp
Version: 1:2.38-5
Severity: serious

Hi Peter,

The latest clisp package is failing to build on arm, ia64, and sparc, each
with a different error.  Of these, arm and ia64 are currently
release-critical architectures, which means the failures are preventing the
fix for 346164 from propagating to testing.

The failure on ia64 is:

[...]
echo '(setq *clhs-root-default* "http://www.lisp.org/HyperSpec/";)' >> 
config.lisp
./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -Emisc 1:1 -norc -m 
1400KW -x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) 
(ext::exit t)"
make[1]: *** [interpreted.mem] Aborted
[...]

A full build log can be found at
.

The arm failure looks like it may have been a temporarily broken header file
on arm, or it may be a bad #define in clisp.

The sparc one is completely different from the other two; it's not currently
a release-critical issue, but should be treated with a high priority since
sparc may be re-added as a release candidate soon.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#373696: vim: Default $VIMRUNTIME set incorrectly

[Adam Collins]

Package: vim
Version: 1:7.0-017+6
Severity: important

Vim reports the following when run:

  Error detected while processing /home/adam/.vimrc:
  line   15:
  E484: Can't open file /usr/local/share/vim/syntax/syntax.vim
  Press ENTER or type command to continue

Backspace key doesn't work, and numerous other small problems.
Possibly due to incorrect default runtime directory.
Output of ":version" :

  
   system vimrc file: "$VIM/vimrc"
 user vimrc file: "$HOME/.vimrc"
  user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"
  

The last line indicates the culprit.
Workaround is to add this to your shell config file (~/.bashrc):

  export VIMRUNTIME=/usr/share/vim/vim70

and restart your shell or X session.

-- 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.16-2-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages vim depends on:
ii  libc62.3.6-15GNU C Library: Shared libraries
ii  libgpmg1 1.19.6-22   General Purpose Mouse - shared lib
ii  libncurses5  5.5-2   Shared libraries for terminal hand
ii  vim-common   1:7.0-017+6 Vi IMproved - Common files
ii  vim-runtime  1:7.0-017+6 Vi IMproved - Runtime files

vim recommends no packages.

-- no debconf information


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

Bug#373695: sound-juicer: missing Depend: on gstreamer0.10-gnomevfs

[Alec Berryman]

Package: sound-juicer
Version: 2.14.4-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I installed sound-juicer without having many other GNOME packages on my
system.  When I started it up, I received the following error message
before the program quit without having displayed the main window:

  Could not start Sound Juicer

  Reason: The plugin necessary for file access was not found.  Please
  consult the documentation for assistance.

When I install gstreamer0.10-gnomevfs, the problem goes away.  I am
able to start sound-juicer and rip CDs as expected.


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

Versions of packages sound-juicer depends on:
ii  gconf2 2.14.0-1  GNOME configuration database syste
ii  gstreamer0.10-plugins-base 0.10.8-1  GStreamer plugins from the "base" 
ii  gstreamer0.10-plugins-good 0.10.3-2  GStreamer plugins from the "good" 
ii  libart-2.0-2   2.3.17-1  Library of functions for 2D graphi
ii  libatk1.0-01.11.4-2  The ATK accessibility toolkit
ii  libbonobo2-0   2.14.0-1  Bonobo CORBA interfaces library
ii  libbonoboui2-0 2.14.0-2  The Bonobo UI library
ii  libc6  2.3.6-15  GNU C Library: Shared libraries
ii  libcairo2  1.0.4-2   The Cairo 2D vector graphics libra
ii  libfontconfig1 2.3.2-7   generic font configuration library
ii  libgcc11:4.1.1-4 GCC support library
ii  libgconf2-42.14.0-1  GNOME configuration database syste
ii  libglade2-01:2.5.1-2 library to load .glade files at ru
ii  libglib2.0-0   2.10.3-1  The GLib library of C routines
ii  libgnome-keyring0  0.4.9-1   GNOME keyring services library
ii  libgnome-media02.14.2-1  runtime libraries for the GNOME me
ii  libgnome2-02.14.1-2  The GNOME 2 library - runtime file
ii  libgnomecanvas2-0  2.14.0-2  A powerful object-oriented display
ii  libgnomeui-0   2.14.1-1  The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0 2.14.2-1  GNOME virtual file-system (runtime
ii  libgstreamer0.10-0 0.10.8-2  Core GStreamer libraries and eleme
ii  libgtk2.0-02.8.18-1  The GTK+ graphical user interface 
ii  libice61:1.0.0-3 X11 Inter-Client Exchange library
ii  libmusicbrainz4c2a 2.1.2-5   Second generation incarnation of t
ii  libnautilus-burn3  2.14.1-1  Nautilus Burn Library - runtime ve
ii  liborbit2  1:2.14.0-1.1  libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0  1.12.3-1  Layout and rendering of internatio
ii  libpopt0   1.10-2lib for parsing cmdline parameters
ii  libsm6 1:1.0.0-4 X11 Session Management library
ii  libstdc++6 4.1.1-4   The GNU Standard C++ Library v3
ii  libx11-6   2:1.0.0-6 X11 client-side library
ii  libxcursor11.1.5.2-5 X cursor management library
ii  libxext6   1:1.0.0-4 X11 miscellaneous extension librar
ii  libxfixes3 1:3.0.1.2-4   X11 miscellaneous 'fixes' extensio
ii  libxi6 1:1.0.0-5 X11 Input extension library
ii  libxinerama1   1:1.0.1-4 X11 Xinerama extension library
ii  libxml22.6.26.dfsg-1 GNOME XML library
ii  libxrandr2 2:1.1.0.2-4   X11 RandR extension library
ii  libxrender11:0.9.0.2-4   X Rendering Extension client libra
ii  zlib1g 1:1.2.3-11compression library - runtime

Versions of packages sound-juicer recommends:
ii  eject 2.1.4-2ejects CDs and operates CD-Changer

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEkOnLAud/2YgchcQRAo67AKDBJLryvxqJeHNcimJo/x2yfzTg+wCfSIAm
/d92sm5Bkdu7quPc7dgnM/E=
=zANa
-END PGP SIGNATURE-


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

Bug#370807: libpam-p11 spews odd error message about /var/run/pcscd.pub during authentication attempts

[Daniel Kahn Gillmor]

On June 15, [EMAIL PROTECTED] said:

 > Interesting. Can you try installing pcscd and see if it changes the
 > behavior at all.

Yep.  installing pcscd makes the error message go away.  And removing
it makes the message come back.  However, libpam-p11 appears to work
properly for me without the daemon, and i guess i'd rather have a bit
of noise during PAM sessions, rather than run a superfluouse daemon as
root.  But neither would be best, of course.

Should i be running pcscd?  Am i using an unsupported configuration?
Should libpam-p11 actually depend on pcscd?  i still don't understand
the architecture well enough to know just what pcscd is supposed to
do, and what features i'm missing by not running it.

Thanks for looking into this, Eric.

--dkg


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

Bug#373085: 'apt-get build-dep twinkle' cannot be satisfied on Sid

[Mark Purcell]

On Thursday 15 June 2006 12:41, Andrew McMillan wrote:
> The instructions on this bug don't seem to allow building twinkle on
> unstable either, at least at present:

Andrew,

Thanks for your details.

We do have a bit of a chain dependency going on between; libcommoncpp2, 
libccrtp and twinkle.

Unfortunately each package need to be updated/ rebuilt in turn.

As it turns out, libcommoncpp2 underwent a soname change so took some time in 
NEW processing. I could of rebuilt libccrtp and twinkle at that time.

However libccrtp also underwent a soname change so that is also taking some 
time in NEW processing, it's been waiting there for the last 6 days. 
http://ftp-master.debian.org/new.html

Once libccrtp is in the archive, then I can request a binary only NMU (or you 
can rebuild yourself) for twinkle, which will clear up the backlog.

So at present if you want the package, you need to manually build and install 
the package for libccrtp & then manually build and install the package for 
twinkle..

Alternatively, as this is taking a while, I have placed the libccrtp & twinkle 
rebuild .debs at http://people.debian.org/~msp

Mark


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

Bug#373679: vim_7.0-017+6: vim-ruby and vim-full are badly ./configured

[James Vega]

reassign 373679 libruby1.8 1.8.4-4
retitle rbconfig returns invalid LDFLAGS
thanks

On Thu, Jun 15, 2006 at 02:18:53AM +0200, Adeodato Simó wrote:
> Hey guys.
> 
> Seems like something has gone astray in the vim-ruby and vim-full part
> of the build, since ./configure is invoked once, with all the correct
> arguments, but then, it's called again when starting the build, like
> this:

Taking a look at the config.log, this appears to be a bug in libruby1.8.
The initial configure fails because of some bogus LDFLAGS returned from
rbconfig:

  > ruby -r rbconfig -e 'print Config::CONFIG["LDFLAGS"]'
   -rdynamic -Wl\,-export-dynamic

Error from config.log:

  configure:4900: gcc -o conftest -O2 -g -Wall   -rdynamic -Wl\,-export-dynamic 
 -L/usr/local/lib con ftest.c -lsocket   >&5
  cc1: error: unrecognized command line option "-Wl\,-export-dynamic"

This was working with libruby1.8 1.8.4-2.  I'm not sure if the breakage
occurred in 1.8.4-3 or -4, but I could probably test this tomorrow and
report back.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Bug#373203: ikiwiki: utf8 not handled in image titles

[Joey Hess]

Pablo Barbachano wrote:
> Hi, I have a wiki page like this (simplified for the report):
> 
> cat >fo.mdwn < ![o](../images/o.jpg "ó")
> EOF
> 
> It is valid utf8. When it is converted to html, the 'ó' gets converted to
> ó
> 
> I don't know if it is bug in markdown or ikiwiki.

You can work around this bug by turning off the htmlscrubber module,
either by passing --disable-module htmlscrubber or by removing it from
your ikiwiki setup file.

And what it seems to be doing is not treating the input as utf-8 and encoding
each of the two bytes of the dual-width utf-8 character separately. Let's see:

[EMAIL PROTECTED]:~/src/ikiwiki/doc>markdown < foo.mdwn 

ó
[EMAIL PROTECTED]:~/src/ikiwiki/doc>markdown < foo.mdwn | perl -e 'use 
HTML::Scrubber; my $s=HTML::Scrubber->new(allow => [qw{img}], default => 
[undef, { alt => 1, src => 1, title => 1 }]); while (<>) { print $s->scrub($_) 
}'

ó
[EMAIL PROTECTED]:~/src/ikiwiki/doc>markdown < foo.mdwn | perl -e 'use Encode; 
use HTML::Scrubber; my $s=HTML::Scrubber->new(allow => [qw{img}], default => 
[undef, { alt => 1, src => 1, title => 1 }]); while (<>) { print 
$s->scrub(Encode::decode_utf8($_)) }'  

���
Not sure what happened to the "ó" there, but on the right track..
[EMAIL PROTECTED]:~/src/ikiwiki/doc>markdown < foo.mdwn | perl -CSD -e 'use 
HTML::Scrubber; my $s=HTML::Scrubber->new(allow => [qw{img}], default => 
[undef, { alt => 1, src => 1, title => 1 }]); while (<>) { print $s->scrub($_) 
}' 

ó

So running perl with -CSD, as ikiwiki does, should make it work. But it
doesn't in ikiwiki, so I guess that what we get back from markdown in
ikiwiki is not being treated as utf8 internally before the sanitize hook
is called. I don't understand why though. This was changed in Recai's
big utf-8 patch in ikiwiki 1.5; if I back that patch out things work ok.

Or I could just do this:

Index: IkiWiki/Render.pm
===
--- IkiWiki/Render.pm   (revision 795)
+++ IkiWiki/Render.pm   (working copy)
@@ -39,9 +39,12 @@
}
 
if (exists $hooks{sanitize}) {
+   require Encode;
+   $content=Encode::decode_utf8($content);
foreach my $id (keys %{$hooks{sanitize}}) {
$content=$hooks{sanitize}{$id}{call}->($content);
}
+   $content=Encode::encode_utf8($content);
}

return $content;

This patch fixes the problem, but I don't understand why we have to
re-encode the string to utf-8 on the way out. ikiwiki should just be
using decoded utf-8 internally throughout and perl automatically 
converting to utf-8 on output. 

Beginning to think that Recai's patch wasn't the right approach. With my
patch above, if displaying a preview page, ikiwiki will now:

- Read it in from CGI as, apparently, raw utf-8
- decode_utf8 so it's in perl's internal representation
- htmlize it via markdown, which will include running decode_utf8
  again on the markdown output as above, and then encode_utf8 so it's
  back to raw utf-8
- decode_utf8 once again in the preview code
- finally turn it back into raw utf-8 again and emit it to the
  browser

Yugh. This is becoming far too ugly to live. Maybe Recai can help figure
this out..

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#247134: debconf: affects backups

[gambarimasu+reportbug]

Package: debconf
Version: 1.5.1
Followup-For: Bug #247134


i see that the bug is 2 years old, that there was a previous bug, and
that the changelog implies that it used to be in /usr/lib/.  not sure
why, since it seems to violate the fhs to me.  perhaps debian is not
supposed to agree with the fhs?  or perhaps the i/o is not considered
significant.

just wanted to say that many users will exclude /var/cache from
backups.

-- System Information:
Debian Release: testing/unstable
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16myver
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages debconf depends on:
ii  debconf-i18n  1.5.1  full internationalization support 
ii  perl-base 5.8.8-4The Pathologically Eclectic Rubbis

Versions of packages debconf recommends:
ii  apt-utils 0.6.44.1   APT utility programs

-- debconf information:
  debconf-apt-progress/title:
  debconf-apt-progress/info:
* debconf/priority: low
  debconf-apt-progress/preparing:
* debconf/frontend: Dialog


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

Bug#370807: libpam-p11 spews odd error message about /var/run/pcscd.pub during authentication attempts

[Eric Dorland]

* Daniel Kahn Gillmor ([EMAIL PROTECTED]) wrote:
> Package: libpam-p11
> Version: 0.1.2-2
> Severity: minor
> 
> 
> i'm using libpam-p11 with the openct framework.  when i try to log in
> at the console (via login), i get an odd error message (the line after
> the login: prompt shows up in red):
> 
> 
> 
> Debian GNU/Linux testing/unstable squeak tty1
> 
> squeak login: dkg
> winscard_clnt.c:320:SCardEstablishContextTH() Cannot open public shared file: 
> /var/run/pcscd.pub
> Password for token OpenSC Card (dkg):
> Last login: Tue Jun  6 16:30:50 2006 on tty1
> Linux squeak 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686
> 
> The programs included with the Debian GNU/Linux system are free software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
> 
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> No mail.
> [0 [EMAIL PROTECTED] ~]$ 

Interesting. Can you try installing pcscd and see if it changes the
behavior at all.  
 
> Note that logging in works properly, without any trouble.
> 
> /etc/pam.d/common-auth contains only the line:
> 
>  auth required pam_p11_opensc.so /usr/lib/opensc-pkcs11.so
> 
> and /etc/pam.d/login is untouched from the default.
> 
> the error message about /var/run/pcscd.pub also shows up in my
> screensaver.
> 
> i have no need for pcscd to my knowledge, so i'm not sure why the
> system should be complaining about it.
> 
> Some other info that might be useful/relevant:
> 
> 
> [0 [EMAIL PROTECTED] tmp]$ dpkg -l openct libpam-p11 pcscd
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
> uppercase=bad)
> ||/ Name   VersionDescription
> +++-==-==-
> ii  libpam-p11 0.1.2-2PAM module for using PKCS#11 smart cards
> ii  openct 0.6.6-2middleware framework for smart card terminal
> un  pcscd   (no description available)
> [0 [EMAIL PROTECTED] tmp]$ ls -la /var/run
> total 64
> drwxr-xr-x  4 root root  4096 2006-06-06 14:09 .
> drwxr-xr-x 16 root root  4096 2006-06-05 14:40 ..
> srw-rw-rw-  1 root root 0 2006-06-05 09:30 acpid.socket
> -rw-r--r--  1 root root 5 2006-06-05 09:30 crond.pid
> --  1 root root 0 2006-06-05 09:30 crond.reboot
> -rw-r--r--  1 root root  3014 2006-06-06 16:02 dhclient.3com.leases
> -rw-r--r--  1 root root 6 2006-06-06 13:25 dhclient.3com.pid
> -rw-r--r--  1 root root 5 2006-06-05 09:30 gdm.pid
> -rw---  1 root root 5 2006-06-05 09:30 gpm.pid
> -rw-r--r--  1 root root 5 2006-06-05 09:30 klogd.pid
> -rw-r--r--  1 root root 0 2006-06-05 09:30 laptop-mode-enabled
> -rw-r--r--  1 root root 1 2006-06-05 09:30 
> laptop-mode-start-stop-undo-actions
> -rw-r--r--  1 root root 6 2006-06-05 09:30 laptop-mode-state
> -rw-r--r--  1 root root   348 2006-06-05 09:30 motd
> drwxr-x---  2 root scard 4096 2006-06-06 16:30 openct
> drwxrwxr-x  3 root utmp  4096 2006-06-04 19:11 screen
> -rw-r--r--  1 root root 5 2006-06-05 09:30 syslogd.pid
> -rw-rw-r--  1 root utmp  4608 2006-06-06 16:32 utmp
> [0 [EMAIL PROTECTED] tmp]$ 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6



signature.asc
Description: Digital signature

Bug#373694: suggest adding the "AR PL ShanHeiSun Uni" font in config

[Wei Mingzhi]

Package: fontconfig-config
Version: 2.3.2-7

Hello,

I would suggest adding the "AR PL ShanHeiSun Uni" font to the font list of the 
 and  in fonts.conf. The font is in the Debian 
package "ttf-arphic-uming". This font works for both Simplified Chinese and 
Traditional Chinese, and looks _much_ better than the default ones in the 
current config file.

Patch against the current source is attached.

Regards,
Wei Mingzhi

diff -ur fontconfig-2.3.2.orig/fonts.conf.in fontconfig-2.3.2/fonts.conf.in
--- fontconfig-2.3.2.orig/fonts.conf.in	2006-06-15 12:22:23.0 +0800
+++ fontconfig-2.3.2/fonts.conf.in	2006-06-15 12:24:28.0 +0800
@@ -78,6 +78,7 @@
 		Times
 		Nimbus Roman No9 L
 		Luxi Serif
+		AR PL ShanHeiSun Uni
 		Kochi Mincho
 		AR PL SungtiL GB
 		AR PL Mingti2L Big5
@@ -97,6 +98,7 @@
 		Albany AMT
 		Nimbus Sans L
 		Luxi Sans
+		AR PL ShanHeiSun Uni
 		Kochi Gothic
 		AR PL KaitiM GB
 		AR PL KaitiM Big5
@@ -117,6 +119,7 @@
 		Luxi Mono
 		Cumberland AMT
 		Nimbus Mono L
+		AR PL ShanHeiSun Uni
 		NSimSun
 		FreeMono
 		monospace
@@ -265,6 +268,7 @@
 			Nimbus Roman No9 L
 			Times
 			Frank Ruehl
+			AR PL ShanHeiSun Uni
 			Kochi Mincho
 			AR PL SungtiL GB
 			AR PL Mingti2L Big5
@@ -284,6 +288,7 @@
 			Nimbus Sans L
 			Helvetica
 			Nachlieli
+			AR PL ShanHeiSun Uni
 			Kochi Gothic
 			AR PL KaitiM GB
 			AR PL KaitiM Big5
@@ -304,6 +309,7 @@
 			Nimbus Mono L
 			Courier
 			Miriam Mono
+			AR PL ShanHeiSun Uni
 			Kochi Gothic
 			AR PL KaitiM GB
 			Baekmuk Dotum


pgpVtc5LXCB0B.pgp
Description: PGP signature

Bug#291120: Battery plugin bug

[Daniel Burrows]

  Unfortunately, I don't have xfce installed any more, so I can't
really check whether this is fixed.  It might be easiest to just
go ahead and close the bug report.

  Daniel


signature.asc
Description: Digital signature

Bug#373693: xjig_2.4-11: FTBFS: expects binaries to be installed to /usr/X11R6

[Steve Langasek]

Package: xjig
Version: 2.4-9
Severity: serious

Hi Dave,

The xjig package fails to build against x11r7 because the build rules expect
to find xjig installed to /usr/X11R6/bin:

[...]
install -c   xjig /home/devel/release/xjig-2.4/debian/tmp/usr/bin/xjig
[...]
install -s debian/tmp/usr/X11R6/bin/xjig debian/tmp/usr/games/.
install: cannot stat `debian/tmp/usr/X11R6/bin/xjig': No such file or directory
make: *** [binary-arch] Error 1
[...]

A full build log can be found at
.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#372253: hylafax-server: init.d script may have some timing issues

[Ross Boylan]

I just ran into another problem that may be related to this same
underlying cause.I edited /etc/hylafax/hfaxd.conf to increase the
IdleTimeout and then did /etc/init.d/hylafax force-reload.  I verified
after this that /var/spool/hylafax/etc/hfaxd.conf had been updated.

However, when I attempted to submit a job, I got a timeout after the
old, default (900) interval.  I manually stopped, paused, and started
the server and tried again.  This time it worked.

Among the possibilities
1) hylafax restarted before hfaxd.conf was updated
2) hylafax never restarted/reloaded at all
3) I've misunderstood force-reload; the behavior is to be expected
4) something else

1 or 2 are probably part of this same problem.  3 is a non-bug.  4 is
likely a separate bug.

Ross


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

Bug#373692: gnome-control-center: Switching keyboard to Japanese loses tilde key

[Robert Marlow]

Package: gnome-control-center
Version: 1:2.14.2-1
Severity: normal
Tags: l10n

If a japanese keyboard layout is added along with a typical US
keyboard layout, switching to japanese and then back again causes the
tilde key to no longer work in the US keyboard layout. both ` and
shift+` cause only ` to be printed.



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

Versions of packages gnome-control-center depends on:
ii  capplets-data  1:2.14.2-1configuration applets for GNOME 2 
ii  desktop-file-utils 0.10-1Utilities for .desktop files
ii  gnome-desktop-data 2.14.2-1  Common files for GNOME 2 desktop a
ii  gnome-icon-theme   2.14.2-1  GNOME Desktop icon theme
ii  gnome-menus2.14.0-2  an implementation of the freedeskt
ii  libart-2.0-2   2.3.17-1  Library of functions for 2D graphi
ii  libatk1.0-01.11.4-2  The ATK accessibility toolkit
ii  libaudiofile0  0.2.6-6   Open-source version of SGI's audio
ii  libavahi-client3   0.6.10-1  Avahi client library
ii  libavahi-common3   0.6.10-1  Avahi common library
ii  libavahi-glib1 0.6.10-1  Avahi glib integration library
ii  libbonobo2-0   2.14.0-1  Bonobo CORBA interfaces library
ii  libbonoboui2-0 2.14.0-2  The Bonobo UI library
ii  libc6  2.3.6-13  GNU C Library: Shared libraries
ii  libcairo2  1.0.4-2   The Cairo 2D vector graphics libra
ii  libdbus-1-20.61-6simple interprocess messaging syst
ii  libebook1.2-5  1.6.1-3   Client library for evolution addre
ii  libesd-alsa0 [libesd0] 0.2.36-3  Enlightened Sound Daemon (ALSA) - 
ii  libfontconfig1 2.3.2-5.1 generic font configuration library
ii  libfreetype6   2.2.1-2   FreeType 2 font engine, shared lib
ii  libgconf2-42.14.0-1  GNOME configuration database syste
ii  libgcrypt111.2.2-1   LGPL Crypto library - runtime libr
ii  libglade2-01:2.5.1-2 library to load .glade files at ru
ii  libglib2.0-0   2.10.2-1  The GLib library of C routines
ii  libgnome-desktop-2 2.14.2-1  Utility library for loading .deskt
ii  libgnome-keyring0  0.4.9-1   GNOME keyring services library
ii  libgnome-menu2 2.14.0-2  an implementation of the freedeskt
ii  libgnome-window-settings1  1:2.14.2-1Utility library for getting window
ii  libgnome2-02.14.1-2  The GNOME 2 library - runtime file
ii  libgnomecanvas2-0  2.14.0-2  A powerful object-oriented display
ii  libgnomeui-0   2.14.1-1  The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0 2.14.2-1  GNOME virtual file-system (runtime
ii  libgnutls131.3.5-1.1 the GNU TLS library - runtime libr
ii  libgpg-error0  1.2-1 library for common error values an
ii  libgstreamer-plugins-base0 0.10.7-2  GStreamer libraries from the "base
ii  libgstreamer0.10-0 0.10.6-2  Core GStreamer libraries and eleme
ii  libgtk2.0-02.8.18-1  The GTK+ graphical user interface 
ii  libice61:1.0.0-3 X11 Inter-Client Exchange library
ii  libjpeg62  6b-13 The Independent JPEG Group's JPEG 
ii  libmetacity0   1:2.14.5-1library of lightweight GTK2 based 
ii  libnautilus-extension1 2.14.1-4  libraries for nautilus components 
ii  liborbit2  1:2.14.0-1libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0  1.12.3-1  Layout and rendering of internatio
ii  libpng12-0 1.2.8rel-5.1  PNG library - runtime
ii  libpopt0   1.10-2lib for parsing cmdline parameters
ii  libsm6 1:1.0.0-4 X11 Session Management library
ii  libstartup-notification0   0.8-1 library for program launch feedbac
ii  libtasn1-2 1:0.2.17-2Manage ASN.1 structures (runtime)
ii  libx11-6   2:1.0.0-6 X11 client-side library
ii  libxcursor11.1.5.2-5 X cursor management library
ii  libxext6   1:1.0.0-4 X11 miscellaneous extension librar
ii  libxfixes3 1:3.0.1.2-4   X11 miscellaneous 'fixes' extensio
ii  libxft22.1.8.2-8 FreeType-based font drawing librar
ii  libxi6 1:1.0.0-5 X11 Input extension library
ii  libxinerama1   1:1.0.1-4 X11 Xinerama extension library
ii  libxklavier10  2.2-3 X Keyboard Extension high-level AP
ii  libxml2   

Bug#364621: aptitude: [INTL:ja] Aptitude Japanese translation update

[Daniel Burrows]

On Wed, Jun 14, 2006 at 03:17:35PM +0200, Christian Perrier <[EMAIL PROTECTED]> 
was heard to say:
> Quoting Kobayashi Noritada ([EMAIL PROTECTED]):
> > > > Everything has been comimted in my copy and 5 patches have been sent
> > > > to Daniel Burrows for his darcs copy.
> > 
> > Thank you very much for processing my patch, but no change for ja has been
> > seen in the repository, although there have been many changes for other
> > languages.  I've been waiting for my patch approved to get in the 
> > repository.
> 
> Well, so am I...
> 
> 
> The patch has been commited in my copy and sent to Daniel.
> 
> What's needed actually is Daniel to update his public copy with that
> patch and a few others.
> 
> Actually, I'm a bit worrying about the low activity on aptitude. I
> guess that Daniel Burrows is certainly busy with real life and I hope
> that nothing more grave is behind the current silence. I've seen many
> other issues reported to the BTS without much action.
> 
> aptitude being a key package in Debian and we are quite close to the
> release time (and freeze time), so I indeed really would like to get
> news from Daniel now.

  Is that <[EMAIL PROTECTED]>?  It
looks like it didn't apply cleanly and I didn't have time to investigate
why.

  I'm finally partly moved into my new apartment, I've gotten settled
into my new job, and I have an internet connection again, so I can
slowly start to pick up work on aptitude.  (I almost just orphaned it,
but doing useful work ... as opposed to what I have to do to pay the
rent ... is so much fun that I couldn't make myself do it; my standing
request for a comaintainer is still open, though)

  Daniel


signature.asc
Description: Digital signature

Bug#373689: dokuwiki: CVE-2006-2945: remote authenticated users read unauthorized files

[Alec Berryman]

Package: dokuwiki
Severity: important
Tags: security patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2006-2945: "Unspecified vulnerability the user profile change
functionality in DokuWiki, when Access Control Lists are enabled, allows
remote authenticated users to read unauthorized files via unknown attack
vectors."

More details are available on the DokuWiki bug system [1], including a
one-line fix.  I have verified that this fix is not present in
0.0.20060309-3.

Please mention the CVE in your changelog.

Thanks,

Alec

[1] http://bugs.splitbrain.org/?do=details&id=825

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEkNEBAud/2YgchcQRAnxWAKCbbCMhR8p91kFbZhJ9awbKF2eBdwCfVCoq
723oLwRvqL6qt4tvd43lYgg=
=WGK/
-END PGP SIGNATURE-


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

Bug#371049: network-manager: does not set wireless key correctly

[Brice Goglin]

It looks like the problem is related to the ipw2200 driver. I was
previously using driver release 1.1.2 (and I think I have tried 1.1.1
without success too).

1.1.3 got released recently and it makes both my WEP and WPA work fine
so far (and network-manager thus becomes wonderful). I am going to run
more tests in the next days and I will close this bug if no problem appears.

Brice



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

Bug#373691: 3 more packages x11-common needs to conflict with

[Ross Boylan]

Package: x11-common
Version: 1:7.0.20
Severity: normal

Severity note: this problem blocks the upgrade of X11 and any other
packages that happen to be upgrade targets at the same time.  It may
leave the user without a functioning X.  So it may warrant higher
severity.  On the other hand, the packages that caused the trouble are
likely not too common, and there is a work-around.

I'm reporting this as suggested in http://wiki.debian.org/Xorg69To7.

The following packages own stuff in /usr/X11/bin/, and thus make the
upgrade impossible.  The work-around is to purge them with dpkg -P.
apt-get remove does not work; it gags on the weird state of things in
the middle of the X transition.

x11-common needs to conflict with
cbb
guitar
xext

Once I dpkg -P'd these packages I was able to complete the upgrade
with
apt-get -f install
apt-get dist-upgrade

I had initiated the upgrade with
apt-get dist-upgrade


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

Versions of packages x11-common depends on:
ii  debconf [debconf-2.0] 1.5.1  Debian configuration management sy
ii  debianutils   2.16.1 Miscellaneous utilities specific t
ii  lsb-base  3.1-10 Linux Standard Base 3.1 init scrip

x11-common recommends no packages.

-- debconf information excluded


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

Bug#373690: nvidia-kernel-source: m-a a-b fails near os-interface.o (transcript included)

[Scott Edwards]

Package: nvidia-kernel-source
Version: 1.0.7174-3
Severity: important
Justification: fails to build from source

A kernel config can be provided upon request.  I hope the transcript
isn't too long... Transcript of m-a -i a-b nvidia-kernel as follows:

/usr/bin/make  -f debian/rules clean
make[1]: Entering directory `/usr/src/modules/nvidia-kernel'
# select which makefile to use.
rm -f /usr/src/modules/nvidia-kernel/nv/Makefile || true
if [ 6 = 6  ]; then \
 cd /usr/src/modules/nvidia-kernel/nv ; \
 ln -s Makefile.kbuild Makefile ; \
 cd .. ; \
 if [ 0  = 1 ] ; then \
dpatch apply 04_minion ; \
 fi ; \
 if [ 0 = 1 ]; then \
dpatch apply 01_sysfs ; \
dpatch status 01_sysfs >patch-stamp ; \
dpatch apply 02_pcialias ; \
dpatch status 02_pcialias >>patch-stamp ; \
 fi ; \
fi
if [  6 = 4  ]; then \
 cd /usr/src/modules/nvidia-kernel/nv ; \
 ln -s Makefile.nvidia Makefile ; \
 cd .. ; \
fi
if [ -e patch-stamp ]; then \
   dpatch deapply-all ; \
   rm -rf patch-stamp debian/patched ; \
fi   
if [ -f /usr/src/modules/nvidia-kernel/debian/control.template ]; then \
cp  /usr/src/modules/nvidia-kernel/debian/control.template 
/usr/src/modules/nvidia-kernel/debian/control; \
fi
dh_testroot
rm -f build-stamp configure-stamp
/usr/bin/make clean SYSSRC=/usr/src/linux -C /usr/src/modules/nvidia-kernel/nv 
-f Makefile 
make[2]: Entering directory `/usr/src/modules/nvidia-kernel/nv'
rm -f -f nv.o nv-vm.o os-agp.o os-interface.o os-registry.o nv.o nv-vm.o 
os-agp.o os-interface.o os-registry.o nvidia.mod.o
rm -f -f build-in.o nv-linux.o *.d .*.{cmd,flags}
rm -f -f nvidia.{o,ko,mod.{o,c}} nv_compiler.h *~
rm -f -rf .tmp_versions
make[2]: Leaving directory `/usr/src/modules/nvidia-kernel/nv'
rm -f /usr/src/modules/nvidia-kernel/nv/Makefile || true;   
rm /usr/src/modules/nvidia-kernel/nv/gcc-check
rm /usr/src/modules/nvidia-kernel/nv/cc-sanity-check
dh_clean
rm /usr/src/modules/nvidia-kernel/debian/control
rm /usr/src/modules/nvidia-kernel/debian/dirs
rm /usr/src/modules/nvidia-kernel/debian/override
make[1]: Leaving directory `/usr/src/modules/nvidia-kernel'
echo "ROOT_CMD = "
ROOT_CMD = 
/usr/bin/make  -f debian/rules binary_modules
make[1]: Entering directory `/usr/src/modules/nvidia-kernel'
# select which makefile to use.
rm -f /usr/src/modules/nvidia-kernel/nv/Makefile || true
if [ 6 = 6  ]; then \
 cd /usr/src/modules/nvidia-kernel/nv ; \
 ln -s Makefile.kbuild Makefile ; \
 cd .. ; \
 if [ 0  = 1 ] ; then \
dpatch apply 04_minion ; \
 fi ; \
 if [ 0 = 1 ]; then \
dpatch apply 01_sysfs ; \
dpatch status 01_sysfs >patch-stamp ; \
dpatch apply 02_pcialias ; \
dpatch status 02_pcialias >>patch-stamp ; \
 fi ; \
fi
if [  6 = 4  ]; then \
 cd /usr/src/modules/nvidia-kernel/nv ; \
 ln -s Makefile.nvidia Makefile ; \
 cd .. ; \
fi
#nothing here anymore
touch configure-stamp
if [ -f /usr/src/modules/nvidia-kernel/debian/control.template ]; then \
cp  /usr/src/modules/nvidia-kernel/debian/control.template 
/usr/src/modules/nvidia-kernel/debian/control; \
fi
dh_testdir
dh_testroot
PATCHLEVEL = 6 
Kernel compiler version : 3.3.6
Detected compiler version : 3.3.6
Using compiler gcc-3.3 version 3.3.6
touch /usr/src/modules/nvidia-kernel/nv/gcc-check
touch /usr/src/modules/nvidia-kernel/nv/cc-sanity-check
## Main Make ##
IGNORE_CC_MISMATCH=1 CC="gcc-3.3"  /usr/bin/make -C 
/usr/src/modules/nvidia-kernel/nv -f Makefile SYSSRC=/usr/src/linux   
KBUILD_PARAMS="-C /usr/src/linux SUBDIRS=/usr/src/modules/nvidia-kernel/nv" 
module;
make[2]: Entering directory `/usr/src/modules/nvidia-kernel/nv'

NVIDIA: calling KBUILD...
make CC=gcc-3.3 -C /usr/src/linux SUBDIRS=/usr/src/modules/nvidia-kernel/nv 
modules
make[3]: Entering directory `/usr/local/src/linux-2.6.16.20'
echo \#define NV_COMPILER \"`gcc-3.3 -v 2>&1 | tail -n 1`\" > 
/usr/src/modules/nvidia-kernel/nv/nv_compiler.h
  CC [M]  /usr/src/modules/nvidia-kernel/nv/nv.o
In file included from include/linux/list.h:7,
 from include/linux/wait.h:23,
 from include/asm/semaphore.h:41,
 from include/linux/sched.h:20,
 from include/linux/module.h:10,
 from /usr/src/modules/nvidia-kernel/nv/nv-linux.h:46,
 from /usr/src/modules/nvidia-kernel/nv/nv.c:14:
include/linux/prefetch.h: In function `prefetch_range':
include/linux/prefetch.h:62: warning: pointer of type `void *' used in 
arithmetic
In file included from include/linux/dmapool.h:14,
 from include/linux/pci.h:522,
 from /usr/src/modules/nvidia-kernel/nv/nv-linux.h:69,
 from /usr/src/modules/nvidia-kernel/nv/nv.c:14:
include/asm/io.h: In function `check_signature':
include/asm/io.h:258: warning: wrong type argument to increment
In file included from /usr/src/modules/nvidia-kernel/nv/nv.c:14:
/usr/src/modules/nvi

Bug#116599: getting to know you

[Beulah]

Hire,
i am here sitting in thae interne!t caffe. Found your email and!
decided to write. I might be coming to your place ian 14 days, 
so I decided to e!mail you. May be we can meet? I am 25 y.o.
gairl. I have a picture if you want. No need to reply here as 
this is not my email. Write me at [EMAIL PROTECTED]




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

Bug#373680: vim-common: vimrc.tiny sources debian.vim instead of 'set compatible'

[James Vega]

On Thu, Jun 15, 2006 at 02:23:35AM +0200, Adeodato Simó wrote:
> Hey,
> 
> Seems like vimrc.tiny.diff works and vim-tiny only reads that configuration
> file when invoked like `vi`. However, the file itself contains 
> 
>   runtime! debian.vim
> 
> instead of the expected
> 
>   set compatible

Thanks for the notice.  Fixed in svn and will be uploaded when the other
bug you reported is fixed. :)

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Bug#328318: pciutils: why not centralize pci.ids?

[Matt Taggart]

Cristian Ionescu-Idbohrn writes...

> The other thing needed would be some sort of cron job to periodically
> synch with:
>
>   http://pciids.sourceforge.net/pci.ids

Have you tried /usr/bin/update-pciids from the pciutils packages? :)
You could setup a cronjob to run that.

> That would help enhance hw-detection on new hw.

I don't know how much hw-detection is done with pci.ids, it's mostly so that 
humans can have reasonable strings to look at. The drivers in the Linux kernel 
all have their own lists of PCI ids that they support. I don't know what 
kudzu/etc do, but I didn't think their ability to support hardware was based 
on how up to date their pci.ids was.

Anyway we'll try to keep it as up to date as possible. After a stable release 
happens I suppose we could update via a stable update if needed, but we'd need 
to have a good reason.

-- 
Matt Taggart
[EMAIL PROTECTED]




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

Bug#373085: 'apt-get build-dep twinkle' cannot be satisfied on Sid

[Andrew McMillan]

Hi,

The instructions on this bug don't seem to allow building twinkle on
unstable either, at least at present:

[EMAIL PROTECTED]:/usr/src/twinkle$ apt-get build-dep twinkle
Reading package lists... Done
Building dependency tree... Done
E: Build-dependencies for twinkle could not be satisfied.

Regarding the install dependencies, it appears that the problem is with
the dependency on libccrtp-dev, which depends in turn on
libccrtp1-1.3-0, which in turn depends on libcommoncpp2-1.3-2, which is
no longer in unstable, having been replaced by libcommoncpp2-1.4-0...

  libccrtp-dev: Depends: libccrtp1-1.3-0 (= 1.3.7-1+b1) but it is not going to 
be installed

  libccrtp1-1.3-0: Depends: libcommoncpp2-1.3-2 but it is not installable

[EMAIL PROTECTED]:/usr/src/twinkle$ apt-cache search libcommoncpp
libcommoncpp2-1.4-0 - A GNU package for creating portable C++ programs
libcommoncpp2-dev - Header files and static libraries for Common C++ "2"
libcommoncpp2-doc - Documentation files for Common C++ "2"

Of course if twinkle (and libccrtp1) would actually build against
libcommoncpp2 version 1.4 then twinkle itself would be installable
again:

The following packages have unmet dependencies:
  twinkle: Depends: libccrtp1-1.3-0 but it is not going to be installed
   Depends: libcommoncpp2-1.3-2 but it is not installable

Thanks,
Andrew McMillan.

-
Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201  MOB: +64(272)DEBIAN  OFFICE: +64(4)499-2267
  Never commit yourself!  Let someone else commit you.
-



signature.asc
Description: This is a digitally signed message part

Bug#322718: gftp: segfaults when modifying bookmarks

[Matthieu Crapet]

Package: gftp
Version: 2.0.18-13
Followup-For: Bug #322718

Greetings,

The bug occurs when you have an option in a site entry (.gftp/bookmarks),
for example "passive_transfer" or "preserve_time".
And then, you edit your bookmarks and add a new option to the site.
A hash table already containing "modified params" is wrong after a realloc
(see config_file.c, gftp_set_bookmark_option).

See attached patch.

Matthieu Crapet


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.19-matt
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages gftp depends on:
ii  gftp-gtk  2.0.18-13  X/GTK+ FTP client
ii  gftp-text 2.0.18-13  colored FTP client using GLib

gftp recommends no packages.

-- no debconf information
--- config_file.c.orig	2006-06-15 04:13:30.0 +0200
+++ config_file.c	2006-06-15 03:56:37.0 +0200
@@ -1420,6 +1420,8 @@
 _gftp_set_option_value (tmpconfigvar, value);
   else
 {
+  int i;
+
   if (gftp_global_options_htable == NULL ||
   (tmpconfigvar = g_hash_table_lookup (gftp_global_options_htable,
key)) == NULL)
@@ -1437,15 +1439,22 @@
   ret = gftp_option_types[tmpconfigvar->otype].compare_function (&newconfigvar, tmpconfigvar);
   if (ret == 0)
 return;
-  
+
   if (bm->local_options_hash == NULL)
 bm->local_options_hash = g_hash_table_new (string_hash_function,
string_hash_compare);
 
   bm->num_local_options_vars++;
-  bm->local_options_vars = g_realloc (bm->local_options_vars, 
+  bm->local_options_vars = g_realloc (bm->local_options_vars,
   sizeof (gftp_config_vars) * bm->num_local_options_vars);
 
+  /* We must rebuild the bm->local_options_hash because pointers are relocated
+ (remember that g_hash_table do not keep their own copies of either keys or values) */
+  for (i = 0; i < bm->num_local_options_vars - 1; i++) {
+g_hash_table_replace (bm->local_options_hash, bm->local_options_vars[i].key,
+&bm->local_options_vars[i]);
+  }
+
   memcpy (&bm->local_options_vars[bm->num_local_options_vars - 1], tmpconfigvar, sizeof (*tmpconfigvar));
   _gftp_set_option_value (&bm->local_options_vars[bm->num_local_options_vars - 1], value);
 

Bug#351716: backupninja: recommends instead of suggests for programs needed by helpers

[Micah Anderson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthieu Helleboid wrote:
> Package: backupninja
> Severity: minor
> 
> Hello,
> 
> I think that it would be better to use recommends instead of suggests for
> programs needed by helpers.
> 
> Firstly because when you use aptitude, you can install or uninstall 
> recommended programs automatically with the main program.

Yes, but not everyone wants to install rdiff-backup, duplicity, hwinfo,
mkisofs, cdrecord, dvd+rw-tools... because not everyone uses those handlers.

> Secondly because backupninja is useless without its "dependencies", so
> IMHO, it should be more than a suggestion.

Yes, but installing more things than a person needs is not usually how
debian works.

> Backupninja is really a "simple" but very good software.
> Thanks !

Thank you! :)

micah
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEkMsi9n4qXRzy1ioRAiGXAJ0dvqPt1v356T4QF9eer7SNUiizyACdGFSp
I1TYk088OXRAsgAb9qfPUlQ=
=S1iy
-END PGP SIGNATURE-


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

Bug#372795: missleading version info

[Daniel Burrows]

  As I understand it, this is a feature request that "aptitude show"
should display the currently installed version by default?

  Daniel


signature.asc
Description: Digital signature

Bug#373688: Acknowledgement (xserver-xorg: DRI output is shifted to the left)

[Marc Horowitz]

One more detail: everything worked fine when I was running xorg 6.9.
The problem started after the upgrade.

Marc


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

Bug#371196: grub problems with memtest86+, patch

[Matt Taggart]

Hi,

I am also seeing the problem reported in #371196 with update-grub not working 
if memtest86 is true. The submitter is right in that a couple calls to 
write_kernel_entry are missing a parameter. It looks like when the "lockold" 
functionality was introduced not all of them got updated. I'm assuming that 
the memtest86 and  kfreebsd cases don't need the lock functionality? Here's a 
patch based on that. If they do need the lock functionality then you'll need 
additional stuff to check $lockold and the counter stuff, like the main 
kernels do.

-- 
Matt Taggart
[EMAIL PROTECTED]

--- /sbin/update-grub~  2006-06-05 08:25:31.0 -0700
+++ /sbin/update-grub   2006-06-14 19:02:30.0 -0700
@@ -884,7 +884,7 @@
 else
   kernel=/boot/loader
 fi
-write_kernel_entry "" "" "" "$grub_root_device" "$kernel" "" "" "" "true"
+write_kernel_entry "" "" "" "$grub_root_device" "$kernel" "" "" "" "true" 
""
   ;;
 esac
 
@@ -967,7 +967,7 @@
echo "Found kernel: $kernel" >&2
 
write_kernel_entry "$kernelVersion" "" "" 
"$grub_root_device" \
-   "$kernel" "$currentOpt" "" "$initrd" "false"
+   "$kernel" "$currentOpt" "" "$initrd" "false" ""
fi
done
 fi

Bug#306537: Debugging info

[Jim Wiggs]

   OK, installed the firefox-dbg package, then ran the code in what I
thought was debug mode, got the browser to freeze, and got this for
the effort:

sh-3.1$ /usr/lib/firefox/firefox -debug
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run http://www.overstock.com
Starting program: /usr/lib/firefox/firefox-bin http://www.overstock.com
[Thread debugging using libthread_db enabled]
[New Thread -1221765440 (LWP 5986)]
[New Thread -1223636048 (LWP 5989)]
[New Thread -1232663632 (LWP 5990)]
[New Thread -1245008976 (LWP 5991)]
[New Thread -1253995600 (LWP 5992)]
[New Thread -1262666832 (LWP 5993)]
[New Thread -1271059536 (LWP 5994)]
[Thread -1262666832 (LWP 5993) exited]
[New Thread -1262666832 (LWP 5995)]
[Thread -1271059536 (LWP 5994) exited]
[Thread -1262666832 (LWP 5995) exited]
[Thread -1245008976 (LWP 5991) exited]
[Thread -1253995600 (LWP 5992) exited]
[New Thread -1253995600 (LWP 5996)]
[New Thread -1245008976 (LWP 5997)]
[New Thread -1262666832 (LWP 5998)]
[New Thread -1271059536 (LWP 5999)]
[Thread -1271059536 (LWP 5999) exited]
[Thread -1262666832 (LWP 5998) exited]
[New Thread -1262666832 (LWP 6000)]
[New Thread -1271059536 (LWP 6001)]
[Thread -1271059536 (LWP 6001) exited]
[Thread -1245008976 (LWP 5997) exited]
thread_db_get_info: cannot get thread info: generic error
(gdb) Quit
(gdb) quit
The program is running.  Exit anyway? (y or n) y

   This sure doesn't look like it's reading any of the debugging symbols
that are supposedly provided by firefox-dbg -- generic error is about as
useful as a diet crouton.  What am I doing wrong?  I can't find any sort
of documentation that came with firefox-dbg to indicate how to start up
firefox to take advantage of it.

thanks,
Jim

Bug#373687: overkill: CVE-2006-2971: remote denial of service (daemon crash)

[Alec Berryman]

Package: overkill
Severity: important
Tags: security

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2006-2971: "Integer overflow in the recv_packet function in 0verkill
0.16 allows remote attackers to cause a denial of service (daemon crash)
via a UDP packet with fewer than 12 bytes, which results in a long
length value to the crc32 function."

There is a sample exploit [1] available.  Sarge and Woody may be affected.

Please mention the CVE in your changelog.

Thanks,

Alec

[1] http://www.securityfocus.com/archive/1/archive/1/436659/100/0/threaded

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD4DBQFEkL2hAud/2YgchcQRAomxAJjMfv7iEjb3Laci2o9bvwCjFQHbAKCkDpt3
pevbgxW//O2iq39xLliVEg==
=JvUJ
-END PGP SIGNATURE-


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

Bug#306537: Frequent Crashes

[Jim Wiggs]

On 6/14/06, Wayne Mery <[EMAIL PROTECTED]> wrote:
On 6/13/2006 2:27 PM, Jim Wiggs wrote:> Folks,>>   I am posting hoping for some feedback WRT stability> of the current Firefox/Mozilla codebase.  We are running> a web-based application on two workstations using either
> Mozilla or Firefox and experiencing repeated crashes.> We see anywhere from 3 to 10 crashes a day.  The app is> not doing a lot of _javascript_; several of the displays> do self-updates from once a second to about 30 seconds.
> The self-updating displays are either simple HTML table> displays or displays that contain a single dynamically> generated GIF or PNG image (a chart).  After lining up> about 10-15 of these windows, the system will run for a
> while, then crash completely, requiring the entire multi-> window workspace to be set up again.  What we're trying> to determine is whether there are known stability issues> in the current codebase that are being worked on, or the
> developer base is unaware of these problems.there are (always) PLENTY of issues.can you supply a URL that someone with windows can run?  Or, run the applicationon WINDOWS so we can get a talkback crash report?
[Chopped out workstations description to prevent duplication in bug tracker] 
--ThanksWayne_Wayne S. Mery   | Systems Programmer   Lehigh University 610-758-3983 | 
http://www.lehigh.edu/~wsm0  Bethlehem, PA Save a Life - Sign an Organ Donor card http://www.transweb.orgfor more information


 Hi Wayne,



   Thanks for the reply on this, unfortunately I have literally

*no* boxes here running Windows right now.  All of theseworkstations are running Linux, with identical Debian Etchinstalls.  We're running firefox under a debugger on one ofthe boxes now and going to a site (
overstock.com) whichpretty reliably generates freezes if you navigate around onit for more than a few minutes.  I'll be posting a stacktrace once we get a crash.



best,

Jim 

Bug#373685: CVE-2006-1513: Multiple buffer overflows in abc2ps before 1.3.3 allow for execute arbitrary code

[Micah Anderson]

Package: abc2ps
Severity: important

Hi

CVE-2006-1513 reads:

Multiple buffer overflows in abc2ps allow user-complicit
attackers to execute arbitrary code via crafted ABC music files.

The patches applied for the sarge security update (DSA 1041-1)
need to be applied to the sid version of this package

Micah

-- 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.6.16-1-vserver-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#373674: sudo-ldap: Lack of ordering contraints / sensible override options

[Bdale Garbee]

severity 373674 wishlist
forwarded 373674 [EMAIL PROTECTED]
thanks

On Thu, 2006-06-15 at 00:50 +0100, Paul LeoNerd Evans wrote:

> I propose two methods that may solve this:

Thanks for the idea.  I've forwarded this to Todd Miller, the upstream
author of sudo, for his consideration.

Bdale



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

Bug#373145: Third time is the charm, but some issues remain

[Graham]

I did a bit more reading, and learned that md does store a signature
on the drive, so I tried blanking the MBRs on both drives. For some
reason, this didn't work -- but blanking the drives completely did
resolve the problem. The md arrays are now detected and mounted
properly, and the system boots and runs.

There must have been some latent md array configuration on those
drives. I wish that the installer/partitioner could have noticed this.
In particular, when it prompts me to create a partition table on a
drive that doesn't seem to have one, could it check for any
drive-level md signatures and remove them?

I should also mention that during installation, I got a couple of "The
device is already open" error messages, after configuring software
RAID, while starting the partitioner the second time. I'll attach a
gzipped copy of /var/log/installer/syslog

The grub configuration is still wrong, as noted yesterday: I have to
change "root (hd0,0)" to "root (hd0,1)". I would guess that the grub
package is to blame for this?

Let me know if you need any further info here, or if you want me to do
another test.

-- graham


syslog.gz
Description: GNU Zip compressed data

Bug#372179: bug is now a documentation problem

[Ben Pfaff]

reassign 372179 autoconf-doc
thanks

Tollef Fog Heen <[EMAIL PROTECTED]> described this bug as follows:

It seems like the CVS snapshot of autoconf currently in unstable
overwrites $@ (it does a set x $ac_cv_target among other things).
This causes problems for apr-util since it needs to recover the
command line arguments through the APR_PARSE_ARGUMENTS macro.

Later, I summarized my preferred fix as follows:

In the long term, I suspect that the Autoconf macros in the
apr-util package should be fixed, and that autoconf-doc should
document that $@ may be changed by some macros.

Then Paul Eggert <[EMAIL PROTECTED]> installed such a patch into
the Autoconf CVS for the documentation, adding the following
paragraphs:

If your @command{configure} script does its own option processing, it
should inspect @samp{$@@} or @samp{$*} immediately after calling
@code{AC_INIT}, because other Autoconf macros liberally use the
@command{set} command to process strings, and this has the side effect
of updating @samp{$@@} and @samp{$*}.  However, we suggest that you use
standard macros like @code{AC_ARG_ENABLE} instead of attempting to
implement your own option processing.  @xref{Site Configuration}.

...

Autocoonf macros often use the @command{set} command to update
@samp{$@@}, so if you are writing shell code intended for
@command{configure} you should not assume that the value of @samp{$@@}
persists for any length of time.

So I am reassigning this bug to autoconf-doc, in hopes that it
can soon be refreshed from Autoconf CVS.
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org


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

Bug#373684: cruft: error message when doc-base not installed

[Kevin Ryde]

Package: cruft
Version: 0.9.6-0.14
Severity: normal

If the doc-base package is not installed cruft prints an error

find: /var/lib/doc-base: No such file or directory


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.15-1-486
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)

Versions of packages cruft depends on:
ii  file  4.17-1 Determines file type using "magic"
ii  libc6 2.3.6-7GNU C Library: Shared libraries

cruft recommends no packages.

-- no debconf information


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

Bug#369824: dep on libpcre3 should mean no zsh in /bin

[Clint Adams]

> Since zsh-beta depends on libpcre3, which is in /usr/lib, please do
> not satisfy/distribute /bin/zsh with the package.
> 
> Alternatively, please use dynamic loading or libpcre3 and fail
> gracefully when it's not present; zsh non-beta seems to do that.

The quick fixes to this are to either move pcre to /lib or disable the
pcre module in zsh-beta.


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

Bug#364234: PATCH pkg-dev-el: [debian-readme.el] Incorrect prefix readme-debian => debian-readme

[Peter S Galbraith]

Junichi Uekawa <[EMAIL PROTECTED]> wrote:

> > > > I was letting Junichi take care of all issues relative to this file,
> > > > since he is the author and has CVS access.  I'll let him answer, but I
> > > > think your suggestion is a good idea.
> > > > 
> > > > There's also this one to look at:
> > > > 
> > > >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364234
> > > 
> > > Humph, thanks.
> > > 
> > > considering
> > >   http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html
> > > 
> > > and considering xemacs help for format-time-string claims:
> > >   The number of options reflects the `strftime' function.
> > > 
> > > that's a bug on xemacs...
> > 
> > :-) 
> > 
> > Might still take a long time to get fixed if you choose to not work
> > around it.  Up to you.  Please reassign the bug to xemacs if you decide
> > to go that route.
> 
> I've discovered the mew hackers have done a better job (without fork).
> 
> (defsubst mew-time-tmzn-int ()
>   (let ((tz (car (current-time-zone
> (if (< tz 0)
>   (format "-%02d%02d" (/ (- tz) 3600) (/ (% (- tz) 3600) 60))
>   (format "+%02d%02d" (/ tz 3600) (/ (% tz 3600) 60)
> 
> (defsubst mew-time-ctz-to-rfc (time)
>   (let ((system-time-locale "C")
>   (tmzn-int (mew-time-tmzn-int)))
> ;; XEmacs doesn't have %z
> (format (format-time-string "%a, %d %b %Y %T %%s (%Z)" time) tmzn-int)))
> 
> I'm inclined to use this instead.

Go for it!

-- 
Peter


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

Bug#355752: python-logilab-common: upgrade in Sid fails because of the same error

[Daniel Leidert]

Package: python-logilab-common
Version: 0.16.1-2
Followup-For: Bug #355752

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The same hit me today during my system's upgrade procedure. I got:

Richte python-central ein (0.4.15) ...
Richte python2.3 ein (2.3.5-14) ...
pycentral: pycentral rtinstall: package python-logilab-common: already
  exists: /usr/lib/python2.3/site-packages/logilab/__init__.py
pycentral rtinstall: package python-logilab-common: already
  exists: /usr/lib/python2.3/site-packages/logilab/__init__.py
dpkg: Fehler beim Bearbeiten von python2.3 (--configure):
 Unterprozess post-installation script gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von python2.3-dev:

Then I looked into the directory and found:

ls -lA /usr/lib/python2.3/site-packages/logilab/
insgesamt 8
- -rw-r--r-- 1 root root   0 2006-03-03 01:45 __init__.py
- -rw-r--r-- 1 root root 132 2006-03-04 02:30 __init__.pyc
- -rw-r--r-- 1 root root 132 2006-03-08 03:12 __init__.pyo

After removing those files, installation process worked. I did not
upgrade from Sarge. It was a normal upgrade in Sid.

Daniel Leidert


- -- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.08060320
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages python-logilab-common depends on:
ii  python-central0.4.15 register and build utility for Pyt
ii  python-xml0.8.4-4XML tools for Python [dummy packag

python-logilab-common recommends no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEkK9Sdg0kG0+YFBERAnUlAJ9zVoG0HY3ogA7iqYsO1bHYYzCa0gCfdumx
+5v0KXkD/SrPTc4NRcXzuKw=
=JOVo
-END PGP SIGNATURE-


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

Bug#373683: python-imaging fails to configure

[Michael Neuffer]

Package: python-imaging
Version: 1.1.5-8
Severity: grave

Setting up python-imaging (1.1.5-8) ...
Traceback (most recent call last):
  File "/usr/bin/pycentral", line 1314, in ?
main()
  File "/usr/bin/pycentral", line 1308, in main
rv = action.run(global_options)
  File "/usr/bin/pycentral", line 858, in run
pkg.read_version_info()
  File "/usr/bin/pycentral", line 551, in read_version_info
raise PyCentralError, "package has no field Python-Version"
__main__.PyCentralError: package has no field Python-Version
dpkg: error processing python-imaging (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of python-imaging-tk:
 python-imaging-tk depends on python-imaging (= 1.1.5-8); however:
  Package python-imaging is not configured yet.
dpkg: error processing python-imaging-tk (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python-imaging
 python-imaging-tk



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

Versions of packages python-imaging depends on:
ii  mime-support  3.36-1 MIME files 'mime.types' & 'mailcap
ii  python-central0.4.15 register and build utility for Pyt

python-imaging recommends no packages.

-- no debconf information


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

Bug#373581: latest libfreetype6 update

[Steve Langasek]

Hi Christian,

On Wed, Jun 14, 2006 at 10:27:51AM +0200, Christian Varga wrote:

> I would like to report some strange behaviour of applications after
> installing the latest libfreetype6 package. The software is not in the
> Debian stable tree, so I don't know if this info is of relevance for
> you.

> System: Debian Sarge 3.1

> After installing libfreetype6 version 2.1.7-2.5 following software
> seized to work:

> * spumux - using the marillat sources

> spumux crashes with SIGFPE when executed with any file.

> * OpenOffice Calc 2.0.2 - german debs from openoffice.org

> When entering text into cell A3 (i.e. "Frequenz [Hz]") and try to save
> the document calc crashes. If executed from the command line it says
> SIGFPE.

It seems likely that this is bug #373581, which I'll be looking into in the
next couple of days.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#372773: [powerpc][newwolrd][g-i] cdebconf-gtk interface crash (daily image)

[Eddy Petrişor]

On 6/14/06, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote:

Eddy Petrişor wrote:
> On 6/14/06, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote:
>
>> Eddy Petrişor wrote:
>> > On 6/14/06, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote:
>> >
>> >> Eddy Petrişor wrote:
>> >> > Hello all,
>> >> >
>> >> > I have reported this issue for about a week and I don't know yet
>> if is
>> >> > related to #372773, but the G-I interface (powerpc daily image)
>> >> > crashes and I haven't seen anybody interested in fixing this issue.
>> >> >
>> >> > Can somebody confirm/infirm this?
>> >> >
>> >> > Tests have been ran on a PowerBook5,2.
>> >> >
>> >> > I have added this info on the /GUI wiki page.
>> >>
>> >> as you don't provide many details , i can only suggest to boot in
>> NEWT,
>> >> add "disable-module=linux_input" to /etc/directfbrc and then try going
>> >> graphical.
>> >> If the crash still persists, try adding also "no-hardware" to
>> directfbrc
>> >> (it may be bug #342053)
>> >
>> >
>> > I have started the G-I previousely on this hardware (remember the
>> > missing cyrillic fonts issue), but I think the issue I am hitting is
>> > #372773.
>> >
>> > I knew about the input issue yesteday, but I didn't knew the exact
>> > needed changes that were needed. As my i-net connection was not
>> > working, I wasn't able to test with this modification as I didn't knew
>> > the needed modification.
>> >
>> > Today I wrote this and will try again this evening.
>> >
>>
>> ok, let me know if it works
>
>
> Is it enough for me to add the line "disable-module=linux_input" in
> /etc/directfb in the D-I environment and restart the debconf interface
> (via GTK) or do i need a rebuilt rootskel-gtk udeb?

adding line(s) is enough: directfbrc is parsed everytime a DFB-based
application, like the graphical frontend, is started


The fix given in #372773 is working for me, too. This seems weird, the
G-I daily worked fine for me around the 18th of May. Is this due to
directfb 0.9.24?

I tried with the known trick:
- boot with "install DEBIAN_FRONTEND=newt"
- switch to VT2, "export DEBIAN_FRONTEND=gtk"
- run "debian-installer" (now after adding the line
"disable-module=linux_input" in /etc/directfbrc)

--
Regards,
EddyP
=
"Imagination is more important than knowledge" A.Einstein

Bug#373682: python-imaging: missing Python-version field causes postinst to die

[Paul Brossier]

Package: python-imaging
Version: 1.1.5-8
Severity: important

Do you want to continue [Y/n]?
Setting up python-imaging (1.1.5-8) ...
Traceback (most recent call last):
  File "/usr/bin/pycentral", line 1314, in ?
main()
  File "/usr/bin/pycentral", line 1308, in main
rv = action.run(global_options)
  File "/usr/bin/pycentral", line 858, in run
pkg.read_version_info()
  File "/usr/bin/pycentral", line 551, in read_version_info
raise PyCentralError, "package has no field Python-Version"
__main__.PyCentralError: package has no field Python-Version
dpkg: error processing python-imaging (--configure):
 subprocess post-installation script returned error exit status 1

i guess debian/control is missing a field XB-Python-Version

cheers, piem


-- 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.16-2-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages python-imaging depends on:
ii  mime-support  3.36-1 MIME files 'mime.types' & 'mailcap
ii  python-central0.4.15 register and build utility for Pyt

python-imaging recommends no packages.

-- no debconf information


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

Bug#373681: xserver-xorg: Fast scrolling mouse wheel sometimes reports wrong button numbers

[Paul LeoNerd Evans]

Package: xserver-xorg
Version: 1:7.0.20
Severity: normal

If you roll the mouse wheel slowly it works "as expected"; i.e. reports
buttons 4 and 5. But if you roll it very quickly, sometimes an event of
button 6 or 7 appears as well. E.g; the following from xev:

  ButtonPress event, serial 27, synthetic NO, window 0x81,
  root 0x4d, subw 0x0, time 2707326669, (77,150), root:(656,363),
  state 0x10, button 4, same_screen YES

  ButtonRelease event, serial 27, synthetic NO, window 0x81,
  root 0x4d, subw 0x0, time 2707326669, (77,150), root:(656,363),
  state 0x810, button 4, same_screen YES

  ButtonPress event, serial 27, synthetic NO, window 0x81,
  root 0x4d, subw 0x0, time 2707326682, (77,150), root:(656,363),
  state 0x10, button 4, same_screen YES

  ButtonRelease event, serial 27, synthetic NO, window 0x81,
  root 0x4d, subw 0x0, time 2707326682, (77,150), root:(656,363),
  state 0x810, button 4, same_screen YES

  ButtonPress event, serial 27, synthetic NO, window 0x81,
  root 0x4d, subw 0x0, time 2707326694, (77,150), root:(656,363),
  state 0x10, button 6, same_screen YES

  ButtonRelease event, serial 27, synthetic NO, window 0x81,
  root 0x4d, subw 0x0, time 2707326694, (77,150), root:(656,363),
  state 0x10, button 6, same_screen YES

In case it's of relevance, the mouse is a Logitech MX900 Bluetooth
mouse, connected via the Bluetooth HID stack. However, I've also
observed the same behaviour when using a MX310, directly over USB. I
don't have a PS/2 wheel mouse, so I can't check whether it is a USB-only
problem.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-mh2.nim
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages xserver-xorg depends on:
ii  debconf   1.5.1  Debian configuration management sy
ii  x11-common1:7.0.20   X Window System (X.Org) infrastruc
ii  xbase-clients 1:7.0.1-2  miscellaneous X clients
ii  xkb-data  0.8-5  X Keyboard Extension (XKB) configu
ii  xserver-xorg-core 1:1.0.2-8  X.Org X server -- core server
ii  xserver-xorg-input-al 1:7.0.20   the X.Org X server -- input driver
ii  xserver-xorg-input-ev 1:1.0.0.5-2X.Org X server -- evdev input driv
ii  xserver-xorg-input-kb 1:1.0.1.3-2X.Org X server -- keyboard input d
ii  xserver-xorg-input-mo 1:1.0.4-3  X.Org X server -- mouse input driv
ii  xserver-xorg-video-al 1:7.0.20   the X.Org X server -- output drive
ii  xserver-xorg-video-ap 1:1.0.1.5-2X.Org X server -- APM display driv
ii  xserver-xorg-video-ar 1:0.5.0.5-2X.Org X server -- ark display driv
ii  xserver-xorg-video-at 1:6.5.8.0-1X.Org X server -- ATI display driv
ii  xserver-xorg-video-ch 1:1.0.1.3-3X.Org X server -- Chips display dr
ii  xserver-xorg-video-ci 1:1.0.0.5-2X.Org X server -- Cirrus display d
ii  xserver-xorg-video-cy 1:1.0.0.5-2X.Org X server -- Cyrix display dr
ii  xserver-xorg-video-du 1:0.1.0.5-2X.Org X server -- dummy display dr
ii  xserver-xorg-video-fb 1:0.1.0.5-2X.Org X server -- fbdev display dr
ii  xserver-xorg-video-gl 1:1.0.1.3-3X.Org X server -- Glint display dr
ii  xserver-xorg-video-i1 1:1.1.0.5-2X.Org X server -- i128 display dri
ii  xserver-xorg-video-i7 1:1.0.0.5-2X.Org X server -- i740 display dri
ii  xserver-xorg-video-i8 1:1.5.1.0-2X.Org X server -- Intel i8xx, i9xx
ii  xserver-xorg-video-im 1:1.0.0.5-2X.Org X server -- IMSTT display dr
ii  xserver-xorg-video-mg 1:1.2.1.3.dfsg.1-2 X.Org X server -- MGA display driv
ii  xserver-xorg-video-ne 1:1.0.0.5-2X.Org X server -- Neomagic display
ii  xserver-xorg-video-ne 1:0.1.4.1-3X.Org X server -- Newport display 
ii  xserver-xorg-video-ns 1:2.7.6.5-2X.Org X server -- NSC display driv
ii  xserver-xorg-video-nv 1:1.0.1.5-2X.Org X server -- NV display drive
ii  xserver-xorg-video-re 1:4.0.1.3.dfsg.1-2 X.Org X server -- Rendition displa
ii  xserver-xorg-video-s3 1:1.8.6.5-2X.Org X server -- S3 ViRGE display
ii  xserver-xorg-video-sa 1:2.0.2.3-4X.Org X server -- Savage display d
ii  xserver-xorg-video-si 1:1.3.1.5-3X.Org X server -- SiliconMotion di
ii  xserver-xorg-video-si 1:0.8.1.3-2X.Org X server -- SiS display driv
ii  xserver-xorg-video-si 1:0.7.1.3-2X.Org X server -- SiS USB display 
ii  xserver-xorg-video-td 1:1.1.1.3-3X.Org X server -- tdfx display dri
ii  xserver-xorg-video-tg 1:1.0.0.5-3X.Org X server -- TGA display driv
ii  xserver-xorg-video-tr 1:1.0.1.2-2X.Org X server -- Trident display 
ii  xserver-xorg-video-ts 1:1.0.0.5-2X.Org X server -- Tseng display dr
ii  xserver-xorg-video

Bug#297572: qemu -L will loop forever if it find symlink to directory.

[Michael Gilbert]

tag 297572 confimed

hi bill,

thanks for the info.  looks like this problem does indeed exist.

the question is: is it really a bug?  the software seems to execute
just fine (although after a slight delay until the kernel spits back
ELOOP).  is this normal/reasonable behavior, or should the devs go
through the effort to manually detect this situation?  seems
unnecessary since its already handled.

mike


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

Bug#373666: autogen: FTBFS: bashisms in build commands

[Bruce Korb]

Hi Julien,

Julien Danjou wrote:


Package: autogen
Version: 1:5.8.3-2
Severity: important

Hello,

There was a problem while autobuilding your package:


make[3]: Entering directory `/build/buildd/autogen-5.8.3/xml2ag'
top_builddir=.. top_srcdir=.. PATH=`cd ../columns;pwd`:$PATH ; export 
top_builddir top_srcdir PATH ; /build/buildd/autogen-5.8.3/agen5/autogen 
-L../autoopts --definition=./xmlopts.def
Closing server:  Broken pipe signal (13) received

Last command issued:
cd /build/buildd/autogen-5.8.3/xml2ag

   if test -z "$top_srcdir" || test ! -d "$top_srcdir"; then
   echo "NOTICE:  Setting top_srcdir to .." >&2
   top_srcdir=..
   fi
   if test ! -f $top_srcdir/VERSION ; then
   echo "error $top_srcdir/VERSION file missing" >&2
   kill -TERM $AG_pid
   fi
   f="`egrep '^AG_'  $top_srcdir/VERSION`"
   eval "$f" > /dev/null
   echo $AG_VERSION 


echo
echo ShElL-OuTpUt-HaS-bEeN-cOmPlEtEd - 2
Closing server:  Broken pipe signal (13) received
   


[...]


FSM Error:  in state 6 (need_value), event 8 (;) is invalid
invalid transition:  in /build/buildd/autogen-5.8.3/agen5/opts.def on line 65
token in error:  `;'

	[[...]] 


#ifndef XML2AG
include = <<-  _END_INCLUDE
#include "autogen.

Likely causes:  a mismatched quote, a value that needs quoting,
or a missing semi-colon


Test fails with dash as /bin/sh
Please fix this or build-depends on bash

I must be blinded by staring at this too long.  What is it about this 
script fragment

that is Bourne-incompatible?  Looks pretty vanilla to these tired eyes...

Thanks - Bruce


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

Bug#373680: vim-common: vimrc.tiny sources debian.vim instead of 'set compatible'

[Adeodato Simó]

Package: vim-common
Version: 1:7.0-017+6
Severity: important

Hey,

Seems like vimrc.tiny.diff works and vim-tiny only reads that configuration
file when invoked like `vi`. However, the file itself contains 

  runtime! debian.vim

instead of the expected

  set compatible

or, perhaps

  runtime! debian.vim
  set compatible

Thanks,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Leonard Cohen - Light as the breeze



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

Bug#362095: grub problems with cciss/ida

[Matt Taggart]

Hi,

I just noticed that #362095 and #368030 appear to be the same bug. I am seeing 
the same problem on my dl360g1 machine that has a SMART/2 controller (IDA, 
cpqarray driver). I noticed that the update-grub function "convert_kernel26" 
is the thing that munges the path to the /dev/ida!c0d0p1 thing. I mentioned it 
to otavio on irc and he said that it was needed to fix a problem in the 2.6.14 
timeframe, but that it's fixed in newer kernels. He's going to find a way to 
remove it soon.

-- 
Matt Taggart
[EMAIL PROTECTED]




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

Bug#373225: Please add ARM kernels and tools

[Steve McIntyre]

tags 373225 +pending
thanks

On Tue, Jun 13, 2006 at 07:07:10PM +0200, Martin Michlmayr wrote:
>Package: debian-cd
>
>* Joey Hess <[EMAIL PROTECTED]> [2006-06-12 17:25]:
>> Based on my recent update to the kerntabl, the following seems to need
>> to be done on a per-arch basis:
>> 
>> arm: update udebs and build/config from 2.6.16-1 to 2.6.16-2
>>  make sure that the CDs include 2.6 kernels for subarches that use 2.6
>>  currently the CDs include it for footbridge and s3c2410 only
>
>Can you please make sure the following 2.6 kernels are on the ARM CDs:
> footbridge
> ixp4xx
> nslu2
> rpc
> s3c2410
>
>In terms of utilities, it would be helpful to have the following on
>ARM CDs:
> nwutil
> slugimage
> nslu2-utils

Added into svn; the next daily arm build should have these changes for you.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews



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

Bug#364234: PATCH pkg-dev-el: [debian-readme.el] Incorrect prefix readme-debian => debian-readme

[Junichi Uekawa]

> > > I was letting Junichi take care of all issues relative to this file,
> > > since he is the author and has CVS access.  I'll let him answer, but I
> > > think your suggestion is a good idea.
> > > 
> > > There's also this one to look at:
> > > 
> > >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364234
> > 
> > Humph, thanks.
> > 
> > considering
> > http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html
> > 
> > and considering xemacs help for format-time-string claims:
> > The number of options reflects the `strftime' function.
> > 
> > that's a bug on xemacs...
> 
> :-) 
> 
> Might still take a long time to get fixed if you choose to not work
> around it.  Up to you.  Please reassign the bug to xemacs if you decide
> to go that route.

I've discovered the mew hackers have done a better job (without fork).

(defsubst mew-time-tmzn-int ()
  (let ((tz (car (current-time-zone
(if (< tz 0)
(format "-%02d%02d" (/ (- tz) 3600) (/ (% (- tz) 3600) 60))
  (format "+%02d%02d" (/ tz 3600) (/ (% tz 3600) 60)

(defsubst mew-time-ctz-to-rfc (time)
  (let ((system-time-locale "C")
(tmzn-int (mew-time-tmzn-int)))
;; XEmacs doesn't have %z
(format (format-time-string "%a, %d %b %Y %T %%s (%Z)" time) tmzn-int)))

I'm inclined to use this instead.

regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Bug#373678: python-distutils.mk DEB_PYTHON_INSTALL_ARGS variable should be DEB_PYTHON_INSTALL_ARGS_ALL

[Sergio Talens-Oliag]

Package: cdbs
Version: 0.4.41
Severity: normal
Tags: patch

CDBS should be using the options '--no-compile -O0' when calling setup.py at
install time to avoid compiling .py files, but the variable that sets that
value (DEB_PYTHON_INSTALL_ARGS_ALL), is not used (the name on the rules is
'DEB_PYTHON_INSTALL_ARGS', without the _ALL suffix).

I'm attaching a patch against 'python-distutils.mk' that renames the variable.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (100, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-vserver-powerpc
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)

cdbs depends on no packages.

Versions of packages cdbs recommends:
ii  autotools-dev 20060223.1 Update infrastructure for config.{
ii  debhelper 5.0.37.1   helper programs for debian/rules

-- no debconf information

-- 
Sergio Talens-Oliag <[EMAIL PROTECTED]>   
Key fingerprint = 29DF 544F  1BD9 548C  8F15 86EF  6770 052B  B8C1 FA69
--- python-distutils.mk.orig2006-06-14 19:53:33.0 +0200
+++ python-distutils.mk 2006-06-15 02:06:50.171215082 +0200
@@ -189,23 +189,23 @@
 else
 common-install-arch common-install-indep:: $(addprefix python-install-so-, 
$(cdbs_python_build_versions)) python-install-py
 python-install-so-%:
-   cd $(DEB_SRCDIR) && python$* $(DEB_PYTHON_SETUP_CMD) install 
--root=$(DEB_DESTDIR) $(DEB_PYTHON_INSTALL_ARGS)
+   cd $(DEB_SRCDIR) && python$* $(DEB_PYTHON_SETUP_CMD) install 
--root=$(DEB_DESTDIR) $(DEB_PYTHON_INSTALL_ARGS_ALL)
find $(DEB_DESTDIR)/usr/lib/python$* -type f -a ! -name "*.so" -exec rm 
{} \;
find $(DEB_DESTDIR)/usr/lib/python$* -depth -type d -a -empty -exec 
rmdir {} \;
 endif # archall detection
 python-install-py:
-   cd $(DEB_SRCDIR) && python $(DEB_PYTHON_SETUP_CMD) install 
--root=$(DEB_DESTDIR) $(DEB_PYTHON_INSTALL_ARGS) --install-lib 
$(cdbs_python_support_path)
+   cd $(DEB_SRCDIR) && python $(DEB_PYTHON_SETUP_CMD) install 
--root=$(DEB_DESTDIR) $(DEB_PYTHON_INSTALL_ARGS_ALL) --install-lib 
$(cdbs_python_support_path)
find $(DEB_DESTDIR)/$(cdbs_python_support_path) -type f -a -name "*.so" 
-exec rm {} \;
find $(DEB_DESTDIR)/$(cdbs_python_support_path) -depth -type d -a 
-empty -exec rmdir {} \;
 else
 ifeq (all, $(cdbs_python_module_arch))
 common-install-arch common-install-indep:: python-install-py
 python-install-py:
-   cd $(DEB_SRCDIR) && python $(DEB_PYTHON_SETUP_CMD) install 
--root=$(DEB_DESTDIR) $(DEB_PYTHON_INSTALL_ARGS)
+   cd $(DEB_SRCDIR) && python $(DEB_PYTHON_SETUP_CMD) install 
--root=$(DEB_DESTDIR) $(DEB_PYTHON_INSTALL_ARGS_ALL)
 else
 common-install-arch common-install-indep:: $(addprefix python-install-, 
$(cdbs_python_build_versions))
 python-install-%:
-   cd $(DEB_SRCDIR) && python$* $(DEB_PYTHON_SETUP_CMD) install 
--root=$(DEB_DESTDIR) $(DEB_PYTHON_INSTALL_ARGS)
+   cd $(DEB_SRCDIR) && python$* $(DEB_PYTHON_SETUP_CMD) install 
--root=$(DEB_DESTDIR) $(DEB_PYTHON_INSTALL_ARGS_ALL)
 endif # archall detection
 endif # install selection
 


signature.asc
Description: Digital signature

Bug#373679: vim_7.0-017+6: vim-ruby and vim-full are badly ./configured

[Adeodato Simó]

Package: vim
Version: 1:7.0-017+6
Severity: serious

Hey guys.

Seems like something has gone astray in the vim-ruby and vim-full part
of the build, since ./configure is invoked once, with all the correct
arguments, but then, it's called again when starting the build, like
this:

 *** DEBIAN *** BUILDING VARIANT vim-ruby
 if [ "vim-ruby" = "vim-tiny" ]; then \
   patch -Np0 < debian/tiny/vimrc.tiny.diff; \
 fi
 /usr/bin/make -C vim70 CFLAGS="-O2 -g -Wall"
 make[1]: Entering directory `/build/buildd/vim-7.0/vim70'
 Starting make in the src directory.
 If there are problems, cd to the src directory and run make there
 cd src && /usr/bin/make first
 make[2]: Entering directory `/build/buildd/vim-7.0/vim70/src'
 rm -f auto/config.status auto/config.cache config.log auto/config.log
 rm -f auto/config.h auto/link.log auto/link.sed auto/config.mk
 touch auto/config.h
 cp config.mk.dist auto/config.mk
 GUI_INC_LOC="" GUI_LIB_LOC="" \
 CC="" CPPFLAGS="" CFLAGS="-O2 -g -Wall" \
 LDFLAGS=""  srcdir="." \
 ./configure\
\
\
\
\
\
 \

Which results in both being "Normal version with GTK2 GUI". Severity set
to RC since vim-ruby configured with '-ruby' should not get into
testing (and same for -full).

Thanks,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Leonard Cohen - Be for real



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

Bug#373674: sudo-ldap: Lack of ordering contraints / sensible override options

[Paul LeoNerd Evans]

Package: sudo-ldap
Version: 1.6.8p12-4
Severity: normal

Suppose the following normal /etc/sudoers entries

  user  ALL=(ALL) NOPASSWD: /usr/bin/apt-get
  user  ALL=(ALL) ALL

This lets "user" run apt-get commands without entering a password, or
any other command with it. The ordering in the file ensures that the
specific rule for apt-get is hit before the general "ALL" rule. But now
consider the following entries in LDAP:

  dn: cn=user,ou=SUDOers,dc=example,dc=com
  objectClass: top
  objectClass: sudoRole
  cn: user
  sudoUser: user
  sudoHost: ALL
  sudoCommand: ALL

  dn: cn=user_noauth,ou=SUDOers,dc=example,dc=com
  objectClass: top
  objectClass: sudoRole
  cn: user_noauth
  sudoUser: user
  sudoHost: ALL
  sudoCommand: /usr/bin/apt-get
  sudoOption: !authenticate

Because LDAP search results are not ordered, either or other of these
results could be returned first. The upshot here is that when running an
"apt-get" command, half the times a password is required, and half not.
This makes it unpredictable, and unusable for automated scripted tasks,
which may rely on "sudo" being able to run non-interactively.

I propose two methods that may solve this:

  1. Store a "sudoPriority" or similar attribute, and sort the replies
 into order, thus allowing full ordering as would be achievable in
 the config file.

  2. Apply some logic to the "strength" of the match, allowing more
 specific rules to override more general ones. Any specific command
 would override "ALL", any specific user would override "ALL",
 longer commands override shorter ones, etc... This might be more
 confusing though, as the exact order between

user ALL=(ALL) ALL
 
 and
 
ALL ALL=(ALL) /bin/some/command

 is not obvious - either could be correct.

I suspect the first solution would be easier for users and
administrators to understand. Also, it directly maps to the config file
layout, allowing easy migration from a config file. And it allows
expression of any rules that can be expressed in a config file, whereas
the overriding order solution would not.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-mh2.nim
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages sudo-ldap depends on:
ii  libc6 2.3.6-13   GNU C Library: Shared libraries
ii  libldap2  2.1.30-13  OpenLDAP libraries
ii  libpam-modules0.79-3.1   Pluggable Authentication Modules f
ii  libpam0g  0.79-3.1   Pluggable Authentication Modules l

sudo-ldap recommends no packages.

-- no debconf information


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

Bug#373675: python-imaging: Missing Python-Version

[Gordon Haverland]

Package: python-imaging
Version: 1.1.5-8
Severity: normal

Setting up python-imaging (1.1.5-8) ...
Traceback (most recent call last):
  File "/usr/bin/pycentral", line 1314, in ?
main()
  File "/usr/bin/pycentral", line 1308, in main
rv = action.run(global_options)
  File "/usr/bin/pycentral", line 858, in run
pkg.read_version_info()
  File "/usr/bin/pycentral", line 551, in
read_version_info
raise PyCentralError, "package has no field
Python-Version"
__main__.PyCentralError: package has no field
Python-Version


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

Versions of packages python-imaging depends on:
ii  mime-support  3.36-1 MIME files 'mime.types' & 'mailcap
ii  python-central0.4.15 register and build utility for Pyt

python-imaging recommends no packages.

-- no debconf information


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

Bug#373676: python-imaging: Error in configure: __main__.PyCentralError: package has no field Python-Version

[Sven Hartge]

Package: python-imaging
Version: 1.1.5-8
Severity: grave
Justification: renders package unusable

During setup of python-imaging the following happens:

Setting up python-imaging (1.1.5-8) ...
Traceback (most recent call last):
  File "/usr/bin/pycentral", line 1314, in ?
main()
  File "/usr/bin/pycentral", line 1308, in main
rv = action.run(global_options)
  File "/usr/bin/pycentral", line 858, in run
pkg.read_version_info()
  File "/usr/bin/pycentral", line 551, in read_version_info
raise PyCentralError, "package has no field Python-Version"
__main__.PyCentralError: package has no field Python-Version
dpkg: error processing python-imaging (--configure):
 subprocess post-installation script returned error exit status 1


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-beyond4-272
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages python-imaging depends on:
ii  mime-support  3.36-1 MIME files 'mime.types' & 'mailcap
ii  python-central0.4.15 register and build utility for Pyt

python-imaging recommends no packages.

-- no debconf information


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

Bug#373677: python2.3.postinst: "pycentral rtinstall" improperly conditionalized

[Aaron M. Ucko]

Package: python2.3
Version: 2.3.5-14
Severity: important

The logic intended to avoid running "pycentral rtinstall python2.3" more
than once is broken, as [ -n "$2" ] tests whether $2 is NON-empty, and dpkg
--compare-versions considers the empty string to be less than any actual
version anyway.

This wouldn't be a big deal if pycentral were more robust; as it is, though,
I had to remove /usr/lib/python2.3/site-packages/logilab/__init__.py* a
couple of times, and also temporarily downgrade gvrng, which pycentral
should have been ignoring anyway.

-- 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.16.9
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages python2.3 depends on:
ii  libbz2-1.01.0.3-2high-quality block-sorting file co
ii  libc6 2.3.6-15   GNU C Library: Shared libraries
ii  libdb4.3  4.3.29-5   Berkeley v4.3 Database Libraries [
ii  libncurses5   5.5-2  Shared libraries for terminal hand
ii  libreadline5  5.1-7  GNU readline and history libraries
ii  libssl0.9.8   0.9.8b-2   SSL shared libraries
ii  python-central0.4.15 register and build utility for Pyt
ii  zlib1g1:1.2.3-11 compression library - runtime

Versions of packages python2.3 recommends:
ii  python2.3-cjkcodecs   1.1.1-1.2  Python Unicode Codecs Collection f
ii  python2.3-iconvcodec  1.1.2-2.2  Python universal Unicode codec, us

-- no debconf information


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

Bug#372841: twisted-quotes: Typo in delimiter

[Matthias Klose]

tags 372841 + stable
tags 372841 + wontfix
thanks

twisted-quotes was removed from testing/unstable.

Drake Wilson writes:
> Package: twisted-quotes
> Version: 1.3.0-2
> Severity: normal
> 
> On line 4274 of /usr/share/games/fortunes/twisted-quotes, there is
> '%a' where it seems there should be only '%', thus confusing the
> fortune program into thinking the fortune above that and the fortune
> below that are part of the same entry when they seem not to be.


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

Bug#373118: d-i: BRLTTY is not installed

[Samuel Thibault]

Samuel Thibault, le Thu 15 Jun 2006 00:42:59 +0200, a écrit :
> Joey Hess, le Wed 14 Jun 2006 12:06:03 -0400, a écrit :
> > > at the syslinux prompt: brltty correctly gets started during
> > > installation, but the prebaseconfig script didn't get started (or failed
> > > somehow maybe), and as a result brltty didn't get installed.
> > 
> > I don't suppose you have a log file?
> 
> I didn't have the time to do it. I took some: the script isn't ever
> called: I put 
> echo ok >> /target/var/tmp/brltty
> at the very beginning of the prebaseconfig script, and it didn't show up
> on the installed system.

And /var/log/installer/syslog only shows

Jun 14 23:23:52 user-setup: Adding user `foo' to group `plugdev'...
Jun 14 23:23:52 user-setup: Done.
Jun 14 23:23:52 finish-install: info: Running 
/usr/lib/finish-install.d/07preseed
Jun 14 23:23:53 finish-install: info: Running 
/usr/lib/finish-install.d/10bind-mount
Jun 14 23:23:53 finish-install: info: Running 
/usr/lib/finish-install.d/10clock-setup
Jun 14 23:23:53 finish-install: info: Running 
/usr/lib/finish-install.d/20final-message
Jun 14 23:23:55 finish-install: info: Running 
/usr/lib/finish-install.d/30hw-detect
Jun 14 23:23:55 finish-install: info: Running 
/usr/lib/finish-install.d/50config-target-network
Jun 14 23:23:55 finish-install: info: Running /usr/lib/finish-install.d/65mdcfg
Jun 14 23:23:55 finish-install: info: Running 
/usr/lib/finish-install.d/70kbd-chooser
Jun 14 23:23:57 finish-install: info: Running 
/usr/lib/finish-install.d/90base-installer
Jun 14 23:23:57 finish-install: info: Running /usr/lib/finish-install.d/90cdrom
Jun 14 23:23:58 finish-install: info: Running 
/usr/lib/finish-install.d/90console
Jun 14 23:23:58 finish-install: info: Running 
/usr/lib/finish-install.d/94save-logs
Jun 14 23:23:58 finish-install: /usr/lib/finish-install.d/94save-logs: 
/usr/lib/finish-install.d/94save-logs: 8: db_x_save: not found

Samuel


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

Bug#373118: d-i: BRLTTY is not installed

[Joey Hess]

Samuel Thibault wrote:
> I didn't have the time to do it. I took some: the script isn't ever
> called: I put 
> echo ok >> /target/var/tmp/brltty
> at the very beginning of the prebaseconfig script, and it didn't show up
> on the installed system.
> 
> When are prebaseconfig scripts supposed to be called? Before or after
> finish-install?

It doesn't matter which directory they are in; they're run at the same
time.

BTW, it turns out this is broken if d-i is using the busybox in beta2,
but daily builds are using a newer version of busybox.

-- 
see shy jo

Bug#358542: knoda gcc-4.1 FTBFS

[Mike Schacht]

Marc 'HE' Brockschmidt wrote:

Heya,

You said you have prepared packages of the new upstream release fixing
this issue, but that your sponsor needs to check and upload
them. Nothing has happened since then, do you need another sponsor?
  
I was told that since the associated version of hk-classes has not yet 
made it into unstable there is no point in uploading knoda. I just 
checked now and see that hk-classes-0.8.1a is still stuck in NEW. I 
don't know what is holding it up or what can be done about it.


--
Mike Schacht
[EMAIL PROTECTED]



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

Bug#373660: acpi-support: acpi_fakekey doesn't work

[Martin Michlmayr]

* Angus Lees <[EMAIL PROTECTED]> [2006-06-14 22:13]:
> Package: acpi-support
> Version: 0.80-1

I don't see such a package in Debian.  What does
   dpkg -p acpi-support | grep Maintainer
say?
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Bug#372825: gnomebaker: Please rebuild with gstreamer 0.10 instead of 0.8

[Goedson Teixeira Paixao]

Em Seg, 2006-06-12 às 01:38 +0200, Jerome Warnier escreveu:
> Package: gnomebaker
> Version: 0.5.1-2
> Severity: wishlist
> 
> Gstreamer 0.10 is going soon to be the only Gstreamer version in Sid,
> and probably in Etch. Subsequently, gnomebaker would be the only package
> left depending on version 0.8.
> Please rebuild GnomeBaker using 0.10 when you can.

The next upstream release, which is due to be out soon, is already
ported to gstreamer 0.10. So I expect to have a package built against
0.10 in the archives very soon.

-- 
Goedson Teixeira Paixaohttp://mundolivre.wordpress.com/
Jabber ID: [EMAIL PROTECTED]http://www.jabber.org/

Bug#274738: Finally a fix for this mess

[Thiemo Seufer]

retitle 274738 [mips, mipsel] Fix dynamic function call stub for big binaries
tags 274738 +patch
thanks

The root of this problem was the stub created for lazily resolved
function references. It uses currently a signed 16 bit immediate
for the symbol index, which wraps to negative values for more than
2^15 symbols, which caused ld.so to load garbage as function pointer.

The appended patch fixes this, and supersedes the current mips-specific
xgot workaround (120_mips_xgot_multigot_workaround.dpatch). This patch
already went in upstream.

Applying this patch is a preliminary to make ghc and gcj work reliably
for mips/mipsel. Applying this patch will also cause all current xgot
users to fail, until the xgot option is removed for them. Those were
some weeks ago:

asterisk-oh323_0.7.3-2
asterisk_1:1.2.4.dfsg-6
enigmail_2:0.93-1
gnugk_2:2.2.3-2-2
inkscape_0.43-4
mozilla-thunderbird_1.0.7-3
mozilla_2:1.7.12-1.1
nvu_1.0final-1
ohphone_1:1.4.5+20060204-1
openam_1.1.18+20050304-2
openh323_1.18.0-1
openmcu_2.1.1-2
pstngw_1.3.1-6
python-qt3_3.15-4
qt-x11-free_3:3.3.6-1
t38modem_0.8.0+20050304-2
thunderbird_1.5-4
vegastrike_0.4.3-4
xulrunner_1.8.0.1-5

plus firefox, for which I did a test build without xgot to verify the
patch. I plan to do patches for them in the next days.


Thiemo


#! /bin/sh -e
## 122_mips_dynsymstub.dpatch
##
## DP: Description: 
## DP: Author: Dave Daney <[EMAIL PROTECTED]>, Richard Sandiford <[EMAIL 
PROTECTED]>, Thiemo Seufer <[EMAIL PROTECTED]>
## DP: Upstream status: In trunk and 2.17 branch.
## DP: Date: 2006-06-12

if [ $# -lt 1 ]; then
echo "`basename $0`: script expects -patch|-unpatch as argument" >&2
exit 1
fi

[ -f debian/patches/00patch-opts ] && . debian/patches/00patch-opts
patch_opts="${patch_opts:--f --no-backup-if-mismatch} ${2:+-d $2}"

case "$1" in
-patch) patch -p0 ${patch_opts} < $0;;
-unpatch) patch -R -p0 ${patch_opts} < $0;;
*)
echo "`basename $0`: script expects -patch|-unpatch as argument" >&2
exit 1;;
esac

exit 0

@DPATCH@
Index: bfd/elfxx-mips.c
===
RCS file: /cvs/src/src/bfd/elfxx-mips.c,v
retrieving revision 1.169
retrieving revision 1.172
diff -u -p -r1.169 -r1.172
--- bfd/elfxx-mips.c22 May 2006 15:06:22 -  1.169
+++ bfd/elfxx-mips.c11 Jun 2006 08:33:26 -  1.172
@@ -335,6 +335,8 @@ struct mips_elf_link_hash_table
   bfd_vma plt_header_size;
   /* The size of a PLT entry in bytes (VxWorks only).  */
   bfd_vma plt_entry_size;
+  /* The size of a function stub entry in bytes.  */
+  bfd_vma function_stub_size;
 };
 
 #define TLS_RELOC_P(r_type) \
@@ -623,20 +625,25 @@ static bfd *reldyn_sorting_bfd;
 #define MIPS_ELF_GOT_MAX_SIZE(INFO) (ELF_MIPS_GP_OFFSET (INFO) + 0x7fff)
 
 /* Instructions which appear in a stub.  */
-#define STUB_LW(abfd)  \
-  ((ABI_64_P (abfd)\
-? 0xdf998010   /* ld t9,0x8010(gp) */  \
-: 0x8f998010))  /* lw t9,0x8010(gp) */
-#define STUB_MOVE(abfd) \
-   ((ABI_64_P (abfd)   \
- ? 0x03e0782d  /* daddu t7,ra */   \
- : 0x03e07821))/* addu t7,ra */
-#define STUB_JALR 0x0320f809   /* jalr t9,ra */
-#define STUB_LI16(abfd) \
-  ((ABI_64_P (abfd)\
-   ? 0x6418/* daddiu t8,zero,0 */  \
-   : 0x2418))  /* addiu t8,zero,0 */
-#define MIPS_FUNCTION_STUB_SIZE (16)
+#define STUB_LW(abfd)  \
+  ((ABI_64_P (abfd)\
+? 0xdf998010   /* ld t9,0x8010(gp) */  \
+: 0x8f998010)) /* lw t9,0x8010(gp) */
+#define STUB_MOVE(abfd)
\
+   ((ABI_64_P (abfd)   \
+ ? 0x03e0782d  /* daddu t7,ra */   \
+ : 0x03e07821))/* addu t7,ra */
+#define STUB_LUI(VAL) (0x3c18 + (VAL)) /* lui t8,VAL */
+#define STUB_JALR 0x0320f809   /* jalr t9,ra */
+#define STUB_ORI(VAL) (0x3718 + (VAL)) /* ori t8,t8,VAL */
+#define STUB_LI16U(VAL) (0x3418 + (VAL))   /* ori t8,zero,VAL unsigned */
+#define STUB_LI16S(abfd, VAL)  \
+   ((ABI_64_P (abfd)   \
+? (0x6418 + (VAL)) /* daddiu t8,zero,VAL sign extended */  \
+: (0x2418 + (VAL   /* addiu t8,zero,VAL sign extended */
+
+#define MIPS_FUNCTION_STUB_NORMAL_SIZE 16
+#define MIPS_FUNCTION_STUB_BIG_SIZE 20
 
 /* The name of the dynamic interpreter.  This is put in the .interp
  

Bug#373664: bts: don't hardcode sendmail -t option

[Bastian Kleineidam]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julian Gilbey schrieb:
> Good bug report, thanks!  I don't actually know instantly how to fix
> it: -t is such a standard option.  There are other mailers which would
> expect the -t option as well, and I don't want to assume that only
> /usr/sbin/sendmail needs the -t option.
I think you have several options here, with varying tradeoffs.

- - Break backwards compatibility. Don't append the -t option to
$sendmailcmd anymore, instead make the default $sendmailcmd
"/usr/sbin/sendmail -t". Expect users to adjust their config if they use
non-sendmail mailers that need a -t option.

- - Try to be backward compatible. Would require to recognize those
mailers that do need the -t option, and append it automatically. Don't
know how hard it is to get a complete mailer list that need the -t
option, sendmail is the only one I can think of.

- - Don't change the current behaviour, and document the hard-coded -t
option in the man page. Users like me using qmail-inject then could use
a shell-wrapper that just ignores any -t option, and passes all the
other ones to qmail-inject.


Regards,
  Bastian
- --
  ,''`.  Bastian Kleineidam
 : :' :GnuPG Schlüssel
 `. `'gpg --keyserver wwwkeys.pgp.net --recv-keys 32EC6F3E
   `-

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkJyyeBwlBDLsbz4RAmpQAJ9TYWtiFxBgNH7nL1k5V2/xZ92AnACfQrp9
Rg87Thlojt5bgoqjPRrMT3A=
=hXuN
-END PGP SIGNATURE-

Bug#373663: [Pkg-xfce-devel] Bug#373663: keys have become toggles

[Simon Huggins]

On Wed, Jun 14, 2006 at 03:21:31PM -0600, Troy Heber wrote:
> BTW: I also had the horrible upgrade experience outlined in #315662, I
> really hope that some of this can be resolved for etch, even if
> upstream is not providing any path. It's not very friendly to loose
> most of your desktop settings.

Feel free to submit a magical program which can migrate all settings
ever from 4.0.x to 4.4 or from 4.2 to 4.4 via any intermediate versions.

Good luck.

Looking forward to your patch,

Simon.

-- 
oOoOo   "Abandon shop! Abandon shop! This is not a daffodil!" -oOoOo
 oOoOo   HollyoOoOo
  oOoOo  oOoOo
  htag.pl 0.0.22 ::: http://www.earth.li/~huggie/


signature.asc
Description: Digital signature

Bug#373271: dch --urgency high doesn't seem to work

[Julian Gilbey]

On Wed, Jun 14, 2006 at 10:49:24AM +1000, Mark Purcell wrote:
> Package: devscripts
> Version: 2.9.20
> Severity: normal
> File: /usr/bin/debchange
> 
> WHen using dch --urgency high it doesn't seem to perform as expected, ie the
> urgency in the change log remains low.

Was this for a NEW changelog entry or for an existing one?  The
behaviour of --urgency is documented as only affecting a new entry.
On second thoughts, it would probably make sense for an explicit
--urgency option to affect the current changelog entry, new or
existing.

   Julian


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

Bug#370186: HAL keeps CD drive spinning constantly

[Sjoerd Simons]

On Tue, Jun 13, 2006 at 03:42:17PM -0700, Steve Langasek wrote:
> On Tue, Jun 13, 2006 at 11:23:02PM +0200, Sjoerd Simons wrote:
> > On Mon, Jun 05, 2006 at 12:29:55PM -0400, Daniel Schepler wrote:
> > > I can confirm that this happens on my laptop as well; when a CD is in the
> > > drive, I can hear the drive spinning all the time, although at a lower
> > > speed than when the disc is being read.  After I stop hald manually, the
> > > drive spins down after about a minute.
> 
> > What hal does is poll the cddrive for status every two seconds.. This
> > shouldn't spin up the drive though.. Could you try to kill/stop the
> > /usr/lib/hal/hald-addon-storage processes that hal spawns (These poll your
> > drive) and check if that solves it ?
> 
> FWIW, hald-addon-storage is totally fucked on my machine as well, and
> regularly goes into a disk-wait state whenever I try to suspend to ram,
> so I kill it off by hand whenever I reboot.

Well, the addon does three different ioctl's: CDROM_DRIVE_STATUS,
CDROM_MEDIA_CHANGED and SG_IO. The last two are only done when there is a cd in
the drive.. 

That it goes in disk-wait is not that strange. But the fact that it fucks up
your suspend to ram is a kernel bug imho. 

  Sjoerd
-- 
Just remember, wherever you go, there you are.
-- Buckaroo Bonzai


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

Bug#366759: version without renaming Egg directory

[Chad Walstrom]

The patch is broken.  I'm betting you haven't tried building this yet.
;-)  The real fix would alter SetupTools.py.

Again, hold your horses.  I'll take a look at it this weekend.
-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */



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

Bug#361377: xfingerd: missing dependency on inetd?

[Stephen Gran]

This one time, at band camp, Lars Wirzenius said:
> ke, 2006-06-14 kello 16:54 +0200, KELEMEN Peter kirjoitti:
> > * Lars Wirzenius ([EMAIL PROTECTED]) [20060408 13:22]:
> > 
> > > [...] c) what happens if xinetd or some other inetd
> > > implementation is installed instead of inetd?
> > 
> > Dunno.  Is there a generic framework for handling inetd/xinetd?
> 
> I don't know, but if there isn't, there seems to be a need for that.
> Could you bring it up on debian-devel?

There is update-inetd.  It does not work for xinetd.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#373672: libjpeg-mmx: CVE-2006-3005: memory exhaustion

[Alec Berryman]

Package: libjpeg-mmx
Severity: important
Tags: security patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2006-3005: "The JPEG library in media-libs/jpeg before 6b-r7 on
Gentoo Linux is built without the -maxmem feature, which could allow
context-dependent attackers to cause a denial of service (memory
exhaustion) via a crafted JPEG file that exceeds the intended memory
limits."

Although the CVE is Gentoo-specific, Debian's libjpeg-mmx is not built
with --maxmem enabled, making it vulnerable.  I have attached a trivial
patch to enable --maxmem to the same limit used in libjpeg62.  The
Gentoo bug report mentioned in the CVE [1] contains a more elaborate
patch [2] that limits the maximum amount of allocatable memory to 95% of
physical memory.  I believe the second patch is the better solution -
libjpeg62 sets maxmem to 1024MB, and that doesn't help much when mem +
swap is less than 1024 (the sample exploit image attached to the Gentoo
bug starts my computer thrashing).

Neither the Woody nor the Sarge version build with --maxmem and are
vulnerable.

Please mention the CVE in your changelog.

Thanks,

Alec

[1] http://bugs.gentoo.org/show_bug.cgi?id=130889
[2] http://bugs.gentoo.org/attachment.cgi?id=88029&action=view

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEkJN3Aud/2YgchcQRAv7UAKCL3GLZjODa6PbqNNlJe6Wdq0XMxQCfb3j7
Ykn3VKh6AClF8pIAaSBn8/Q=
=Dx7A
-END PGP SIGNATURE-
--- debian/rules2006-06-14 17:04:51.387093389 -0500
+++ debian/rules.new2006-06-14 17:04:46.338577763 -0500
@@ -5,7 +5,7 @@
 configure: configure-stamp
 configure-stamp:
dh_testdir
-   ./configure --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info
+   ./configure --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info --enable-maxmem=1024
 
touch configure-stamp
 

Bug#373118: d-i: BRLTTY is not installed

[Samuel Thibault]

Hi,

Joey Hess, le Wed 14 Jun 2006 12:06:03 -0400, a écrit :
> > at the syslinux prompt: brltty correctly gets started during
> > installation, but the prebaseconfig script didn't get started (or failed
> > somehow maybe), and as a result brltty didn't get installed.
> 
> I don't suppose you have a log file?

I didn't have the time to do it. I took some: the script isn't ever
called: I put 
echo ok >> /target/var/tmp/brltty
at the very beginning of the prebaseconfig script, and it didn't show up
on the installed system.

When are prebaseconfig scripts supposed to be called? Before or after
finish-install?

Samuel


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

Bug#373664: bts: don't hardcode sendmail -t option

[Julian Gilbey]

On Wed, Jun 14, 2006 at 11:23:28PM +0200, Bastian Kleineidam wrote:
> Package: devscripts
> Version: 2.9.20
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> I want to use this config entry in ~/.devscripts:
> BTS_SENDMAIL_COMMAND='/usr/sbin/qmail-inject [EMAIL PROTECTED]'
> 
> But since bts hardcodes the "-t" option, qmail-inject fails to send
> mail.
> I made patch that only adds "-t" to $sendmailcmd if it starts with
> the default /usr/sbin/sendmail. This should be backwards compatible,
> and allows me to use qmail-inject as mailer.

Good bug report, thanks!  I don't actually know instantly how to fix
it: -t is such a standard option.  There are other mailers which would
expect the -t option as well, and I don't want to assume that only
/usr/sbin/sendmail needs the -t option.

Stuck,

   Julian


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

Bug#370186: HAL keeps CD drive spinning constantly

[Sjoerd Simons]

On Tue, Jun 13, 2006 at 09:05:38PM -0400, Daniel Schepler wrote:
> On Tuesday 13 June 2006 17:23 pm, you wrote:
> > On Mon, Jun 05, 2006 at 12:29:55PM -0400, Daniel Schepler wrote:
> > > I can confirm that this happens on my laptop as well; when a CD is in the
> > > drive, I can hear the drive spinning all the time, although at a lower
> > > speed than when the disc is being read.  After I stop hald manually, the
> > > drive spins down after about a minute.
> >
> > What hal does is poll the cddrive for status every two seconds.. This
> > shouldn't spin up the drive though.. Could you try to kill/stop the
> > /usr/lib/hal/hald-addon-storage processes that hal spawns (These poll your
> > drive) and check if that solves it ?
> 
> Yes, that solves it.

Ok, well in the ioctl's/commands that the addon uses shouldn't spin up the
drive.. But well, hardware can do odd things :) 

It would be interested to know what actually triggers the spin of the
drive.. I've attached a little test program which does two of the three things
the addon usually does. To compile just run gcc test.c -o test..  After that
run it as root and pass the device name of your cd drive it 
(e.g. ./test /dev/hdc).. Please let me know when the drive spins up (if at all) 

Furthermore can you send me the output of running lshal on your system (while
hal is running ofcourse :).

  Sjoerd
-- 
Loneliness is a terrible price to pay for independence.


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

Bug#321102: Further plans for possible data-loss bug in kmail

[Pierre HABOUZIT]

On Tue, Jun 13, 2006 at 12:09:17AM +0200, Marc 'HE' Brockschmidt wrote:
> Heya,
> 
> 321102 has been open for a long time now, but etch is relatively near
> now (especially for a big and therefore slow-moving package like
> kdepim). In the last few mails in the buglog disabling the dimap support
> leading to this problem was proposed, but there hasn't been any reaction
> to this in the last month. Could you please give a short overview and
> tell us what you're planning to do about this?

  http://bugs.kde.org/show_bug.cgi?id=104956#c52 explains all the horror
of the situation.

  Ping daniel ? etch is close, and we *really* need to do something
here. I've looked at the source, disabling dimap seems quite ...
difficult to do, and upstream is clearly unwilling to fix it before KDE
4 wich will be too late.

  so fixing it (with a patch presumably) won't be easy and will need
testing. we should work on it. I lack the essential qualities to write
that patch sadly, and I've not found any on the web.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


signature.asc
Description: Digital signature

Bug#373669: aclocal grabs unneeded/unwanted macros

[Bill Allombert]

Package: automake1.7
Version: 1.7.9-7
Severity: normal
File: /usr/bin/aclocal-1.7

Hello Eric,

when running aclocal (1.7 but also with 1.4), it grabs macros that
does not seems wanted and have problematic side-effect.

Let configure.in be just
AC_INIT(test.c)
AM_INIT_AUTOMAKE(test,0)
or even the empty file.

now run aclocal,
you get a different aclocal.m4 whether you have gettext installed or not.

In particular, if you have gettext installed, it will get a AC_PREREQ([2.54])
which will break if you are using an older version of autoconf,
while everything would work fine if gettext was not installed.

So i have some questions:

1) why aclocal is adding macros to aclocal.m4 even if configure.in is empty ?

2) can I disable the use of third-party .m4 file (i.e. only use the one
shipped with automake) ?

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#373662: ircd-irc2: Erroneous pointer in /etc/ircd/ircd.conf

[Kurt Roeckx]

On Wed, Jun 14, 2006 at 11:20:25PM +0200, Christoph Biedl wrote:
> Package: ircd-irc2
> Version: 2.11.1p1+dfsg-1
> Severity: minor
> 
> I read in /etc/ircd/ircd.conf :
> 
> # This is ircd's config-file. Look at /usr/share/doc/ircd-irc2/example.conf 
> # and /usr/share/doc/ircd-irc2/example.conf for more detailled information
> # and instructions
> 
> Well,
> - one "/usr/share/doc/ircd-irc2/example.conf" should be enough :-)
> - this file is missing, to comment should probably refer to
>   /usr/share/doc/ircd-irc2/ircd.conf.example.gz

Right, one should be
/usr/share/doc/ircd-irc2/ircd.conf.example.gz, the other should
be /usr/share/doc/ircd-irc2/INSTALL.*.


Kurt



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

Bug#373667: zope-zms: CVE-2006-2997: cross-site scripting

[Alec Berryman]

Package: zope-zms
Severity: normal
Tags: security

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2006-2997: "Cross-site scripting (XSS) vulnerability in ZMS 2.9 and
earlier, when register_globals is enabled, allows remote attackers to
inject arbitrary web script or HTML via the raw parameter in the search
field."

Note that 'register_globals' must be set 'on' for this to be a
vulnerability.

The original BugTraq posting [1] does not include a patch, and no new
upstream version has been released.

This appears to affect sarge.

Please mention the CVE in the changelog.

Thanks,

Alec

[1] http://www.securityfocus.com/archive/1/archive/1/436703/100/0/threaded

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEkIeSAud/2YgchcQRAlDMAJwLO6ZYpLPdeziVuQIA0/O7fafwwgCgviks
2xdf6GpjmpXjIuQv4FqdZbQ=
=KEae
-END PGP SIGNATURE-


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

Bug#358542: knoda gcc-4.1 FTBFS

[Marc 'HE' Brockschmidt]

Heya,

You said you have prepared packages of the new upstream release fixing
this issue, but that your sponsor needs to check and upload
them. Nothing has happened since then, do you need another sponsor?

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
250: Reine Programmiersprache
   Zu nichts außer für Spielzeuganwendungen verwendbar. Ausnahme:
   Assembler. (Holger Schauer)

Bug#373613: mozilla-firefox: missing extensions file produces unhelpful error messages

[Vincent . McIntyre]

On Wed, 14 Jun 2006, Justin Pryzby wrote:

> >   # id
> >   uid=0(root) gid=0(root) groups=0(root),1003(lpadmin)
> >   # /bin/rm -rf .mozilla
> >   # firefox
> >
> > Now I get three copies of the warnings, not just one. Hm.
> As root and the user both?

I see the same thing for both users if
 a) the Extensions.rdf is missing and
 b) the .mozilla directory is missing for the user I am running as.
If only a) is true, I see one message, in both cases.


> > Things I tried:
> >
> >   # /bin/rm -rf .mozilla
> /root/.mozilla or /home/~vmi/.mozilla?

/root/.mozilla


> >   # dpkg -L mozilla-firefox | grep -i extens |xargs ls -l
> >   I could find no files or directories that were not owned by root
> >   or were not writeable by root.
> Actually, permissions checks should be bypassed for the root user
> anyway.  access() is a special case, and uses the ruid not the euid.
> This doesn't seem to be relevant here.
>
> >   The only funny I noticed was that:
> >/etc/mozilla-firefox/profile/extensions/Extensions.rdf
> How did you notice that?

>From the output of the command string above; dpkg -L said the file
should be there but ls -l was unable to find it.


> > So the actual problem is that somehow this extensions file got deleted.
> > It would have been helpful for Firefox to report that, instead of the
> > gibberish it gave me. Hopefully later releases from upstream have attended
> > to this.
> Indeed; it probably does
>
>   FILE *fp;
>   if (NULL==(fp=fopen(fn, s)))
>   error_msg()
>
> But since the error indicates that the file is missing, it is wrong;
> either the message should be generalized, or the check should confirm
> that errno==ENOENT before displaying that message, and use a different
> message otherwise.

I agree.

> > That leaves why the file was missing in the first place.
> > Perhaps that is something that the package postinst or postrm scripts
> > could do, on a bad day? Or an incomplete purge after an
> >  apt-get remove mozilla-firefox?
> This might be the case, see below.
>
> > It may be worth checking the package pre- & post- scripts to see if
> > this is something that could possibly happen.
> FYI these are stored in /var/lib/dpkg/info/mozilla-firefox.p*

ah, thanks.

> > Perhaps also it is something to do with the plugin set I have;
> >  libmozsvgdec.so, libjavaplugin_oji.so, libflashplayer.so
> Would you try disabling those extensions by running mozilla-firefox
> -safe-mode and see if that changes anything?

My thought was that installing these may have nuked the Extensions.rdf
file. -safe-mode didn't seem to have much effect.
  # pwd
  /root
  # mv .mozilla nomozilla
  # mv /etc/mozilla-firefox/profile/extensions/Extensions.rdf /tmp
  # firefox -safe-mode
This sequence gives me the three error messages.

> /var/lib/mozilla-firefox/extensions/Extensions.rdf is a link to
> /usr/lib/mozilla-firefox/extensions/Extensions.rdf.
>
> /var/lib/mozilla-firefox/extensions/Extensions.rdf and
> /usr/lib/mozilla-firefox/defaults/profile/extensions/Extensions.rdf
> are removed on prerm remove.
>
> The postinst and postrm all call
> update-mozilla-firefox-chrome, which does:
>
> cat < ${LIBDIR}/extensions/Extensions.rdf
> [...]
> mv ${LIBDIR}/extensions/Extensions.rdf ${VARDIR}/extensions/
> ln -fs ${VARDIR}/extensions/Extensions.rdf ${LIBDIR}/extensions/
>
> So reconfiguring *should* have fixed it.  If prerm remove fails, this
> could have been deleted, but, if postinst returned successfully, they
> should have been recreated.  Can you check what package state
> mozilla-firefox is in?  dpkg -l mozilla-firefox

ii  mozilla-firefox   1.0.4-2sarge7 lightweight web browser based on Mozilla


> I see the following changelog entry:
> |  * debian/update-mozilla-firefox-chrome: Re-initialize Extensions.rdf
> |inside the script instead of relying on mozilla-firefox's default
> |behaviour, which just fails when defaults/profile/extensions/ \
> |Extensions.rdf doesn't exist (and it seems some people like to remove
> |files in /etc). (Closes: #294175)

This seems pretty relevant.
I am fairly sure no-one would have intentionally removed the file, this
is why I am wondering if plugin/extension installation could cause the
problem. I have tried out various extensions (eg for CSS editing) and
mostly deleted them again. Installation of these usually requires running
the browser as root.

Thanks for the fast response, hope this helps
Vince


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

Bug#362966: more occurences of nscd assert() failure

[Colm MacCarthaigh]

We appear to have also been hit by this bug Firstly, the bug is
seemingly only triggered by GETPWBYNAME cached entities whose cached key
(ie what the process tried to getpwnam()) does not match pw->pw_name.

Looking at pwdcache.c shows that for records of this type, cache_addpw
creates a copy of the key for use with cache_add(), however cache_add()
itself (in cache.c) uses pointer arithmatic which makes assumptions
about the "key" argument and table->data coming from the same memory
allocation which I'm not certain are valid. 

The code is pretty poorly commented and arcane. But I'll try to pick
more up when I get time.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]


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

Bug#373670: libdbi-ruby1.8: libdbd-pg-ruby missing ri documentation

[Tom Allison]

Package: libdbi-ruby1.8
Version: 0.0.23-3
Severity: normal

unable to find any documentation for 'ri'

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

Versions of packages libdbi-ruby1.8 depends on:
ii  libruby1.81.8.4-2Libraries necessary to run Ruby 1.

libdbi-ruby1.8 recommends no packages.

-- no debconf information


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

Bug#373663: [Pkg-xfce-devel] Bug#373663: keys have become toggles

[Yves-Alexis Perez]

On Wed, 2006-06-14 at 15:21 -0600, Troy Heber wrote:
> Package: xfce4
> Version: 4.3.90.1-2
> Severity: normal
> 
> I just upgraded to 4.3.90.1 (Xfce 4.4 BETA1) and noticed that some of
> my keyboard shortcuts have become toggles. I have the following
> "Window shortcuts":
> 
> "Workspace 1"  "Alt+F1"
> "Workspace 2"  "Alt+F2"
> ...
> 
> In previous versions, pressing Alt+F1 would take me from any workspace
> to "Workspace 1" even if I was already on "Workspace 1". However, the
> behavior has now changed to toggle between "Workspace 1" and the
> previously visited workspace. Yuck, when I bind a key to take me to
> "Workspace 1", I expect it to do just that.

It was an hidden option (not activated by default) under Xfce 4.2. Now
in 4.4 it can be changed by using the "Workspace" tab in "Window Manager
Tweaks" in the Xfce Settings Manager.
> 
> I believe this behavior is a bug. However, if you think it should be
> wishlist feel free to adjust the severity.

It's not a bug, it's a feature (tm) !


-- 
Yves-Alexis Perez



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

Bug#370186: HAL keeps CD drive spinning constantly

[Sjoerd Simons]

On Thu, Jun 15, 2006 at 12:15:06AM +0200, Sjoerd Simons wrote:
> On Tue, Jun 13, 2006 at 09:05:38PM -0400, Daniel Schepler wrote:
> > On Tuesday 13 June 2006 17:23 pm, you wrote:
> > > On Mon, Jun 05, 2006 at 12:29:55PM -0400, Daniel Schepler wrote:
> > > > I can confirm that this happens on my laptop as well; when a CD is in 
> > > > the
> > > > drive, I can hear the drive spinning all the time, although at a lower
> > > > speed than when the disc is being read.  After I stop hald manually, the
> > > > drive spins down after about a minute.
> > >
> > > What hal does is poll the cddrive for status every two seconds.. This
> > > shouldn't spin up the drive though.. Could you try to kill/stop the
> > > /usr/lib/hal/hald-addon-storage processes that hal spawns (These poll your
> > > drive) and check if that solves it ?
> > 
> > Yes, that solves it.
> 
> Ok, well in the ioctl's/commands that the addon uses shouldn't spin up the
> drive.. But well, hardware can do odd things :) 
> 
> It would be interested to know what actually triggers the spin of the
> drive.. I've attached a little test program which does two of the three things
> the addon usually does. To compile just run gcc test.c -o test..  After that
> run it as root and pass the device name of your cd drive it 
> (e.g. ./test /dev/hdc).. Please let me know when the drive spins up (if at 
> all) 

And ofcourse i forgot the attachment.. Should be there this time :)

  Sjoerd
-- 
Time is nature's way of making sure that everything doesn't happen at once.

Space is nature's way of making sure that everything doesn't happen to you.
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 

int
main(int argc, char **argv) {
  unsigned int drive;
  int fd;

  fd = open(argv[1], O_RDONLY | O_NONBLOCK | O_EXCL);
  if (fd < 0 && errno == EBUSY) {
fd = open(argv[1], O_RDONLY | O_NONBLOCK);
  }
  assert(fd >= 0);

  printf("Doing CDROM_DRIVE_STATUS\n");
  drive = ioctl (fd, CDROM_DRIVE_STATUS, CDSL_CURRENT);

  printf("Got: %x\n", drive);
  sleep(5);
  printf("Doing CDROM_MEDIA_CHANGEDs\n");
  ioctl (fd, CDROM_MEDIA_CHANGED, CDSL_CURRENT);
  ioctl (fd, CDROM_MEDIA_CHANGED, CDSL_CURRENT);

  return 0;
}

Bug#370106: crashes with xterm: symbol lookup error: xterm: undefined symbol: _XA_UTF8_STRING

[Hynek Med]

Problem solved. I had stale libXmu in /usr/X11R6/lib, not owned by any package. 
After removing it (and other stale libs there) I got a running Xterm with this 
messaege (even in LC_ALL=C):

Warning: locale not supported by Xlib, locale set to C
Warning: X locale modifiers not supported, using default
Failed to open input method

Which was fixed by forced dpkg --remove and apt-get install libx11-6.

Hynek


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

Bug#373668: linitan: [source-contains-CVS-dir] enhance lintian-info description

[Jari Aalto]

Package: lintian
Version: 1.23.21
Severity: wishlist

lintian-info for source-contains-CVS-dir reads

N:
N:   Package contains a CVS directory. It was most likely included by
N:   accident, since transient CVS data usually doesn't belong in packages.
N:   Export from CVS rather than use a checkout.

The problem is not necessarily due to directly packaging from CVS, but
that the upstream tarball contains CVS directories in it.

Please enhance the message by referring to also check
variable debhelper::DH_ALWAYS_EXCLUDE in those cases

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)

Versions of packages lintian depends on:
ii  binutils 2.16.1cvs20060413-1 The GNU assembler, linker and bina
ii  diffstat 1.41-1  produces graph of changes introduc
ii  dpkg-dev 1.13.21 package building tools for Debian
ii  file 4.17-1  Determines file type using "magic"
ii  gettext  0.14.5-4GNU Internationalization utilities
ii  intltool-debian  0.34.2+20060512 Help i18n of RFC822 compliant conf
ii  libparse-debianchang 1.0-1   parse Debian changelogs and output
ii  man-db   2.4.3-3 The on-line manual pager
ii  perl [libdigest-md5- 5.8.8-6 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information


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

Bug#373663: [Pkg-xfce-devel] Bug#373663: keys have become toggles

[Jonathan Black]

On Wed, 14 Jun 2006, Troy Heber wrote:

In previous versions, pressing Alt+F1 would take me from any workspace
to "Workspace 1" even if I was already on "Workspace 1". However, the
behavior has now changed to toggle between "Workspace 1" and the
previously visited workspace. Yuck, when I bind a key to take me to
"Workspace 1", I expect it to do just that.


I actually found this to be a welcome new feature, providing a way to 
easily toggle between two workspaces without having to use two different 
key combinations or even necessarily remember which one you started 
from. Creative use, I thought, of a keybinding which would otherwise do 
nothing much useful at the time, simply taking you to where you already 
are.


However, I see your point, that you might actually want to get to 
Workspace N regardless of whether or not you are already there. And I 
believe you're in luck: the new behaviour can be turned off, in Settings 
-> Window Manager Tweaks -> "Remember and recall previous workspace when 
switching via keyboard shortcuts".


--
jonathaN


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

Bug#373387: python transition

[Peter Samuelson]

unblock 373387 by 373628
thanks

(This block was a false positive.  While we use cdbs a little, we don't
actually use it for anything python-related.)

First, it's not clear to me what advantages anyone would get from
"fixing" the subversion packaging to comply with current python policy.
I do not see what is broken about our current package.  It doesn't
hard-code python 2.3 anywhere, so it's binNMUable.  (Well, other than
the "Provides: python2.3-subversion", which can probably go away now.
It's left over from renaming the package from that.)

It's even less clear what point there is in supporting multiple
simultaneous python versions, except to avoid the need for a binNMU
once every 3 years.  python-subversion has very few users.  Building
the module code twice, and making the package hard to backport to
stable, is enough of a pain to make it reasonable to ask what benefit
these users will get in return.


signature.asc
Description: Digital signature

Bug#373665: aspectc++: FTBFS: bashisms in tests

[Julien Danjou]

Package: aspectc++
Version: 0.99+1.0pre3-2
Severity: important

Hello,

There was a problem while autobuilding your package:

> Automatic build of aspectc++_0.99+1.0pre3-2 on avidan by sbuild/i386 0.46
> Build started at 20060614-2320
> **
...
> ---
> Making AspectC++ for TARGET=linux-release
>   AC++ =
>   Compiler = g++ -O2 -Wall -pipe -fno-rtti -fno-exceptions -DNDEBUG  
> -I../Puma/include
>   Linker   = g++ -O2 -Wall -pipe -fno-rtti -fno-exceptions -DNDEBUG  
> -I../Puma/include  -Wl,-Bstatic -L../Puma/lib/linux-release -lPuma 
> -Wl,-Bdynamic
> ---
> export: 16: ./test_02: bad variable name
> make[1]: *** [test] Error 2
> make[1]: Leaving directory `/build/buildd/aspectc++-0.99+1.0pre3/Ag++'
> make: *** [test-builds] Error 2
> ******
> Build finished at 20060614-2345
> FAILED [dpkg-buildpackage died]
> --

Test fails with a posix compliant shell like dash.
Please fix this or build-depends on bash and change the #!

-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


signature.asc
Description: Digital signature