Bug#323737: FTBFS: Too few template-parameter lists

[Kevin Glynn]

Steve Langasek writes:


 > 
 > The source updates look fine to me, but:
 > 
 >   * Use absolute paths when making links to doc directories, this stops
 > problems for people with symlinked /usr/share/doc (i.e., me!).
 > 
 > contradicts Debian Policy 10.5.  I don't think personal preference in
 > configuring symlinks on one's system is a very compelling reason to
 > contradict policy here.
 > 

Thanks for the reference,  I have also noticed this from Section 12.3
of the Debian Policy:

   Packages must not require the existence of any files in
   /usr/share/doc/ in order to function [73]. Any files that are
   referenced by programs but are also useful as stand alone
   documentation should be installed under /usr/share/package/ with
   symbolic links from /usr/share/doc/package.

It seems to me that the result of these two policies is that Debian
doesn't support a system like mine that has a symbolic link from
/usr/share/doc to another directory.

That's fine by me, I now have enough space to move it back again, but
I imagine it is quite a common situation.

Unless you have an alternative suggestion I propose to just back out
the change that turned the relative link into an absolute one.

thanks for your time.
Kevin


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

Bug#323737: FTBFS: Too few template-parameter lists

[Kevin Glynn]

Steve Langasek writes:

 > > It seems to me that the result of these two policies is that Debian
 > > doesn't support a system like mine that has a symbolic link from
 > > /usr/share/doc to another directory.
 > 
 > > That's fine by me, I now have enough space to move it back again, but
 > > I imagine it is quite a common situation.
 > 
 > FWIW, in 2.4 and 2.6 Linux kernels you also have the option to use mount
 > --bind, and in 2.6 kernels there's also mount --move, to let you distribute
 > your disk usage in a way that's more transparent to userspace.
 > 
 > > Unless you have an alternative suggestion I propose to just back out
 > > the change that turned the relative link into an absolute one.
 > 
 > Yes, that's definitely my preference.  If you can provide an updated source
 > package with this change, I'd be happy to sponsor the upload.
 > 

I realised I could use 'mount -bind' instead of a symbolic link
yesterday and now it all works fine with the relative links.  My
regular sponsor has uploaded a new fixed package and so this bug
should be fixed real soon now. 

Thanks for the offer and the help,

Kevin
  


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

Bug#325812: unison-gtk: looks for .unison-2.13.16-gtk instead of .unison for profiles

[Kevin Glynn]

Package: unison-gtk
Version: 2.13.16-1
Severity: normal

- Unison is looking in .unison-2.13.16-gtk instead of .unison for user
  profiles.

- Also, if I run unison-gtk, sync a profile and then press the quit
  button I get 'Killed by signal 1.' printed in the terminal, i.e. 

@quaver:~ 4Q> unison-gtk
Killed by signal 1.
@quaver:~ 4Q>



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

Versions of packages unison-gtk depends on:
ii  libatk1.0-0   1.10.1-2   The ATK accessibility toolkit
ii  libc6 2.3.5-6GNU C Library: Shared libraries an
ii  libglib2.0-0  2.8.0-1The GLib library of C routines
ii  libgtk2.0-0   2.6.9-1The GTK+ graphical user interface 
ii  libpango1.0-0 1.8.2-1Layout and rendering of internatio
ii  unison2.13.16-1  A file-synchronization tool for Un
ii  unison2.9.1 [unison]  2.9.1-3A file-synchronization tool for Un

Versions of packages unison-gtk recommends:
ii  ssh-askpass  1:1.2.4.1-3 under X, asks user for a passphras
ii  ssh-askpass-gnome [ssh-askpa 1:4.1p1-6   under X, asks user for a passphras

-- no debconf information


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

Bug#328356: Processed: severity of 328356 is grave

[Kevin Glynn]

New package is ready, waiting for response from my sponsor.  If
someone wants to step in and sponsor the upload, please contact me.

cheers
k


Debian Bug Tracking System writes:
 > Processing commands for [EMAIL PROTECTED]:
 > 
 > > # Automatically generated email from bts, devscripts version 2.9.7
 > > severity 328356 grave
 > Bug#328356: mozart-gtk: please rebuild against latest libpng
 > Severity set to `grave'.
 > 
 > >
 > End of message, stopping processing here.
 > 
 > Please contact me if you need assistance.
 > 
 > Debian bug tracking system administrator
 > (administrator, Debian Bugs database)
 > 


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

Bug#328356: mozart-gtk: please rebuild against latest libpng

[Kevin Glynn]

[EMAIL PROTECTED] writes:
 > Package: mozart-gtk
 > Version: 20040429-4
 > 
 > This is an automatically generated report. The mozart-gtk package depends
 > on libpng2, libpng10-0 or libpng3. It should be rebuilt against the latest 
 > libpng 1.2 packages, so that libpng 1.0 can safely be removed from the 
 > archive.
 > 
 > To achieve that, please install libpng12-dev, and make your package 
 > simply build-depend on:
 >  * libpng-dev for a binary package,
 >  * libpng12-dev for a library package.
 > (The former is a virtual package provided by the latter.)
 > 
 > Please don't forget that as soon as libpng 1.0 is removed from the 
 > archive (which is due soon), packages using libpng10-0 or libpng2 will
 > be uninstallable.
 > 


Thanks for the report.  I am waiting for a new imlib1-dev package that
doesn't require libpng10-dev and libpng2-dev, and conflict with
libpng12-dev.

cheers
k

Bug#323737: FTBFS: Too few template-parameter lists

[Kevin Glynn]

Matt Kraai writes:
 > Package: mozart
 > Version: 1.3.1.20040616-8
 > Severity: serious
 > 
 > mozart fails to build because of two "too few
 > template-parameter-lists" errors:
 > 
 > > c++ -DHAVE_CONFIG_H -I. 
 > > -I/tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator  
 > > -DSITE_PROPERTY -fno-exceptions  -fno-implicit-templates -O3 -pipe 
 > > -fno-strict-aliasing -march=pentium -fomit-frame-pointer -c -o 
 > > var_base.o 
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/var_base.cc
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/fset.hh:46: 
 > > error: expected ',' or '...' before '&' token
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/fset.hh:46: 
 > > error: ISO C++ forbids declaration of 'FSetConstraint' with no type
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/fset.hh:52: 
 > > error: expected ',' or '...' before '&' token
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/fset.hh:52: 
 > > error: ISO C++ forbids declaration of 'FSetConstraint' with no type
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/mozart_cpi.hh:1217:
 > >  error: 'OZ_Boolean OZ_CtVar::tell()' is private
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/var_ct.hh:41: 
 > > error: within this context
 > 
 > These errors have been fixed upstream, but I don't have access to CVS
 > so I can't extract the patch.
 > 

Thanks for the report.  I have had packages ready for some time,
however my sponsor is not responding for the moment.  I have asked for
a sponsor on debian-mentors but have not had any response yet.

If you would be willing to sponsor the upload ..

cheers
k


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

Bug#323737: FTBFS: Too few template-parameter lists

[Kevin Glynn]

Steve Langasek writes:
 > On Fri, Aug 19, 2005 at 08:03:38AM +0200, Kevin Glynn wrote:
 > > Matt Kraai writes:
 > >  > Package: mozart
 > >  > Version: 1.3.1.20040616-8
 > >  > Severity: serious
 > >  > 
 > >  > mozart fails to build because of two "too few
 > >  > template-parameter-lists" errors:
 > >  > 
 > >  > > c++ -DHAVE_CONFIG_H -I. 
 > > -I/tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator  
 > > -DSITE_PROPERTY -fno-exceptions  -fno-implicit-templates -O3 -pipe 
 > > -fno-strict-aliasing -march=pentium -fomit-frame-pointer -c -o 
 > > var_base.o 
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/var_base.cc
 > >  > > 
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/fset.hh:46: 
 > > error: expected ',' or '...' before '&' token
 > >  > > 
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/fset.hh:46: 
 > > error: ISO C++ forbids declaration of 'FSetConstraint' with no type
 > >  > > 
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/fset.hh:52: 
 > > error: expected ',' or '...' before '&' token
 > >  > > 
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/fset.hh:52: 
 > > error: ISO C++ forbids declaration of 'FSetConstraint' with no type
 > >  > > 
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/mozart_cpi.hh:1217:
 > >  error: 'OZ_Boolean OZ_CtVar::tell()' is private
 > >  > > 
 > > /tmp/buildd/mozart-1.3.1.20040616/mozart/platform/emulator/var_ct.hh:41: 
 > > error: within this context
 > 
 > >  > These errors have been fixed upstream, but I don't have access to CVS
 > >  > so I can't extract the patch.
 > 
 > > Thanks for the report.  I have had packages ready for some time,
 > > however my sponsor is not responding for the moment.  I have asked for
 > > a sponsor on debian-mentors but have not had any response yet.
 > 
 > > If you would be willing to sponsor the upload ..
 > 
 > Where can your packages be found for sponsoring?
 > 

Please find it at:

   http://www.info.ucl.ac.be/~glynn/mozart_1.3.1.20040616-9.dsc
   http://www.info.ucl.ac.be/~glynn/mozart_1.3.1.20040616-9.diff.gz
   http://www.info.ucl.ac.be/~glynn/mozart_1.3.1.20040616.orig.tar.gz

Thanks for your help.

Kevin


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

Bug#318611: mozart: Annoying behaviour of Emacs mode

[Kevin Glynn]

Björn Lindström writes:
 > 
 > The Emacs mode that accompanies the mozart package has a couple of 
 > misfeatures.
 > 
 > a) It changes the mode line globally. This is alright when Emacs is called 
 > as 'oz',
 >I suppose, but _not_ when just loading a .oz file in a regular Emacs 
 > session.
 > 
 > b) Most bindings in oz-mode have a prefix of C-. , which often can't be 
 > produced in
 >text mode. For instance, it doesn't work in xterm on my machine. This 
 > should be
 >changed to the more common C-c. (C-. can of course be left in for those 
 > that have
 >gotten used to it.)
 > 

Hi Björn,

Thanks for your comments. I am no emacs hacker, but ...

a)  I don't understand this.  The mode-line is changed when we enter
oz-mode.  As far as I can see it is only in effect when we are
editing buffers in oz-mode.

For example, I like it that I can start an ordinary emacs, open a
.oz file, automatically get font-lock and the Oz menu, even feed
the buffer (and the mozart emulator is automatically started).

Perhaps you can give me a step-by-step account that shows what you
dislike. 

b)  I definitely agree!  I get bitten by this a lot.  I will look into
this.

k

Bug#318611: mozart: Annoying behaviour of Emacs mode

[Kevin Glynn]

Björn Lindström writes:
 > b) Most bindings in oz-mode have a prefix of C-. , which often can't be 
 > produced in
 >text mode. For instance, it doesn't work in xterm on my machine. This 
 > should be
 >changed to the more common C-c. (C-. can of course be left in for those 
 > that have
 >gotten used to it.)

Actually, having had a quick look, I see that this is already done!
C-c . C-b  feeds the buffer, for example.

k

Bug#289470: totem crash

[Kevin Glynn]

Package: totem
Version: 0.100-1
Followup-For: Bug #289470


totem crashes on startup for me too, I am not running any experimental 
packages.  Here is the backtrace from gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223911872 (LWP 1439)]
0xb71bcfd3 in strlen () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb71bcfd3 in strlen () from /lib/tls/libc.so.6
#1  0xb7447d47 in giop_send_buffer_append_string () from
/usr/lib/libORBit-2.so.0
#2  0xb74550d0 in ORBit_marshal_value () from /usr/lib/libORBit-2.so.0
#3  0xb7455073 in ORBit_marshal_value () from /usr/lib/libORBit-2.so.0
#4  0xb744c3c8 in ORBit_small_freekids () from /usr/lib/libORBit-2.so.0
#5  0xb744c95b in ORBit_small_invoke_stub () from
/usr/lib/libORBit-2.so.0
#6  0xb744c840 in ORBit_small_invoke_stub_n () from
/usr/lib/libORBit-2.so.0
#7  0xb74607c2 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#8  0xb74a160a in ConfigDatabase_set () from /usr/lib/libgconf-2.so.4
#9  0xb749838e in gconf_engine_set () from /usr/lib/libgconf-2.so.4
#10 0xb749a964 in gconf_engine_get_pair () from /usr/lib/libgconf-2.so.4
#11 0xb749d55a in gconf_client_set_string () from
/usr/lib/libgconf-2.so.4
#12 0x0806 in totem_remote_new ()
#13 0xb740d973 in g_cclosure_marshal_VOID__STRING () from
/usr/lib/libgobject-2.0.so.0
#14 0xb73fb686 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#15 0xb740cd1f in g_signal_emit_by_name () from
/usr/lib/libgobject-2.0.so.0
#16 0xb740bdec in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#17 0xb740c076 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#18 0xb79be84c in bacon_cd_selection_get_type () from
/usr/lib/libnautilus-burn.so.0
#19 0xb740d1f6 in g_cclosure_marshal_VOID__VOID () from
/usr/lib/libgobject-2.0.so.0
#20 0xb73fb686 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#21 0xb740cd1f in g_signal_emit_by_name () from
/usr/lib/libgobject-2.0.so.0
#22 0xb740bdec in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#23 0xb740c166 in g_signal_emit_by_name () from
/usr/lib/libgobject-2.0.so.0
#24 0xb7730721 in gtk_combo_box_set_active () from
/usr/lib/libgtk-x11-2.0.so.0
#25 0xb77305e7 in gtk_combo_box_set_active () from
/usr/lib/libgtk-x11-2.0.so.0
#26 0xb79bf756 in bacon_cd_selection_set_device () from
/usr/lib/libnautilus-burn.so.0
#27 0x0806e97b in totem_setup_preferences ()
#28 0x0806ce52 in main ()

and here is the output of gconftool-2 -R /apps/totem:

quaver:~ 4Q> gconftool-2 -R /apps/totem
 brightness = 32767
 window_h = 540
 playlist_x = 280
 playlist_y = 173
 auto_resize = false
 repeat = false
 shuffle = false
 volume = -1
 visual = goom
 saturation = 32767
 audio_output_type = 0
 show_vfx = true
 window_w = 966
 contrast = 32767
 deinterlace = false
 hue = 32767
 debug = false
 mediadev = /dev/scd0
 window_on_top = false
@quaver:~ 4Q> 

I don't have /dev/scd0 (probably I would have it if I connected my usb
cdrom)

Hope this helps,

Kevin


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1+1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages totem depends on:
ii  totem-xine0.100-1A simple media player for the Gnom

-- no debconf information


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

Bug#370720: virtual-package-depends-without-real-package-depends is bodus

[Kevin Glynn]

Russ Allbery writes:
 > martin f krafft <[EMAIL PROTECTED]> writes:
 > 
 > > Package: lintian
 > > Version: 1.23.21
 > > Severity: normal
 > 
 > > W: mdadm: virtual-package-depends-without-real-package-depends recommends: 
 > > mail-transport-agent
 > > N:
 > > N:   The package declares a depends on a virtual package without listing a
 > > N:   real package as an alternative first.
 > > N:   
 > > N:   A real package should be listed in the first part of the | dependency
 > > N:   in order for the package to be installable by package management
 > > N:   programs that can't or won't guess which alternative to select by
 > > N:   default. In particular, it helps build daemons rebuild the package
 > > N:   without manual overrides.
 > > N:   
 > > N:   Refer to Policy Manual, section 7.4 for details.
 > 
 > > This makes no sense. Build daemons are only concerned about
 > > build-depends, and there isn't one package management programme in
 > > Debian that can't pick an alternative.
 > 
 > > Please at least don't show this warning for recommends/suggests.
 > 
 > If package A Build-Depends on package B which in turn then Depends on
 > virtual package C, I can see two possibilities:  either the package system
 > will want to prompt someone for what package to install, which won't work
 > because it's non-interactive, or the installed package to satisfy the
 > dependency on virtual package C will be chosen essentially at random.  The
 > latter leaves open the possibility that a different choice will be made
 > next time, meaning that we no longer have a consistent and reproducible
 > build environment.  That strikes me as bad, although I'm not sure it's bad
 > enough to warrant the lintian warning.  I'd at least want to see some more
 > discussion of that first.
 > 

Since you ask for discussion :-).  

I just got this lintian warning (I replaced emacs21 | xemacs21 by
emacsen in my depends field) and I have a little complaint as
well. Policy Manual, section 7.4 does not say that a real package must
be included in the dependency.  It just says "The effect is as if the
package(s) which provide a particular virtual package name had been
listed by name everywhere the virtual package name appears".

I understand the usefulness of this requirement but then shouldn't the
Policy Manual be updated to say this?

thanks
k






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

Bug#374738: developers-reference: [5.8.4] Only most recent section of changelog is considered

[Kevin Glynn]

Package: developers-reference
Severity: normal


Section 5.8.4 should make it clear that only the most recent section of the 
changelog
is significant for closing bugs. So, if one uploads version -11, followed by 
-13 bugs closed
in the -12 section will not be picked up by daks and closed automatically.

I suppose this is the scenario addressed by the line "To close any remaining 
bugs that were 
fixed by your upload, email the .changes file to [EMAIL PROTECTED], where XXX 
is your 
bug number.", but I think this requires a bit more explanation.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-amd64-k8-smp
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#374738: developers-reference: [5.8.4] Only most recent section of changelog is considered

[Kevin Glynn]

Frank Lichtenheld writes:
 > On Tue, Jun 20, 2006 at 08:48:08PM -0500, Kevin Glynn wrote:
 > > Package: developers-reference
 > > Severity: normal
 > > 
 > > 
 > > Section 5.8.4 should make it clear that only the most recent section of 
 > > the changelog
 > > is significant for closing bugs. So, if one uploads version -11, followed 
 > > by -13 bugs closed
 > > in the -12 section will not be picked up by daks and closed automatically.
 > 
 > No, really it should it make clear that the archive software doesn't
 > care about Debian changelog at all and just uses the "Closes:" field
 > of the .changes file of the upload...
 > 
 > It should probably then explain how to influence the content of this
 > field when building packages.
 > 

Yes, this is the information I was missing.

cheers
k


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

Bug#374738: developers-reference: [5.8.4] Only most recent section of changelog is considered

[Kevin Glynn]

Justin Pryzby writes:
 > On Tue, Jun 20, 2006 at 08:48:08PM -0500, Kevin Glynn wrote:
 > > Package: developers-reference
 > > Severity: normal
 > > 
 > > Section 5.8.4 should make it clear that only the most recent section
 > > of the changelog is significant for closing bugs. So, if one uploads
 > > version -11, followed by -13 bugs closed in the -12 section will not
 > > be picked up by daks and closed automatically.
 > This is controllable to various options to the dpkg-dev tools, eg.
 > dpkg-buildpackage -v, which presumably just passes it on to
 > dpkg-parsechangelog.
 > 

It would be nice if this section explained that it was controllable at
upload time.

 > > I suppose this is the scenario addressed by the line "To close any
 > > remaining bugs that were fixed by your upload, email the .changes
 > > file to [EMAIL PROTECTED], where XXX is your bug number.",
 > > but I think this requires a bit more explanation.
 > Of course using the changelog is commonly preferred, for conformity;
 > this suggestion is just for the case that a previosly-reported problem
 > turns out to have been fixed which wasn't known to be so at thet time
 > of upload, especially for a package with many bugs, or for a new
 > upstream release.
 > 

Aaah, I think I see.  The .changes file doesn't have to explicitly say
that it closes that bug. It is closed because you have mailed
-done.  The advantage of mailing the .changes is that it will nail
the version where the bug was fixed, (and maybe give a hint why it was
fixed).

Thanks for the explanation.  I was a bit dense.  In my case I fixed
the bug by mailing the missing .changes which did close the bugs (that
was on my local disk, that had not been uploaded) to xxx-done.

cheers
k





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

Bug#358449: RC now

[Kevin Glynn]

Martin Michlmayr writes:
 > severity 358449 serious
 > thanks
 > 
 > This bug is RC now since GCC 4.1 will become the default compiler today.
 > 


No problem, I tried to make a release before I left Monday morning to
close this bug but ran out of time.  It will be closed soon (sponsor
willing!) 

regards
k


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

Bug#372152: g++-4.1: PR27935 appears to be unresolved (operator delete(void*, size_t) issue)

[Kevin Glynn]

This bug doesn't appear on amd64,  but does appear in my i386 chroot.

cheers
k



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

Bug#410492: emacs-snapshot: Fails during compilation of add-on packages

[Kevin Glynn]

 >  > With the latest emacs-snapshot, it looks like the process goes
 >  > into an infinite loop.
 >  
 >  No, it's not an infinite loop; the compilation just takes a very,
 >  very long time.  This is because the byte-compiler in Emacs 22 now
 >  tries to print recursive structures using special reader constructs,
 >  and there is a noticeable complexity effect when compiling very
 >  large files...
 >  
 >  This patch fixes the problem, it simply disables this feature.
 >  
 >  --- vm-7.19.orig/vm-byteopts.el
 >  +++ vm-7.19/vm-byteopts.el
 >  @@ -16,6 +16,7 @@
 >   ;; different v19 Emacses.
 >   (setq byte-compile-dynamic nil)
 >   (setq byte-compile-dynamic-docstrings nil)
 >  +(setq byte-compile-disable-print-circle t)
 >   ;; avoid v20 features because users are going
 >   ;; to try to share elc files no matter what we tell them.
 >   (setq byte-compile-emacs19-compatibility t)
 >  

Hi Romain,

This also affects the mozart package ( but we don't have a convenient
byteopts.el hack yet :-( ).  Since you haven't yet closed this bug I
wanted to ask whether this new behaviour is going to remain (and I
should work round it in mozart).

thanks for your help,

Kevin





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

Bug#400355: mozart-gtk: FTBFS: arch is unknown ?

[Kevin Glynn]

One other thing.  there should be a directory in

   /usr/lib/mozart/platform

can you tell me its name on nasya?

Thanks
k



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

Bug#400355: mozart-gtk: FTBFS: arch is unknown ?

[Kevin Glynn]

Hi Julien,

Can you send me the output of this command when run on this machine
(nasya):

   echo "`uname -m` `uname -s` `uname -r`"

Do you know if there is anything different about this machine compared
to the other autobuilders.  If you have access it would be helpful if
you could also run the above command on spontini as well.

Thanks for the report,

Kevin




Julien Danjou writes:
 > Package: mozart-gtk
 > Version: 20060615-2
 > Severity: serious
 > 
 > Hello,
 > 
 > There was a problem while autobuilding your package:
 > 
 > > Automatic build of mozart-gtk_20060615-2 on nasya by sbuild/sparc 0.50
 > > Build started at 20061125-1533
 > > **
 > ...
 > >  debian/rules build
 > > dh_testdir
 > > test -r /usr/share/misc/config.sub && \
 > >  cp -f /usr/share/misc/config.sub 
 > > /build/buildd/mozart-gtk-20060615/mozart-gtk-1.1/config.sub
 > > make: [source-stamp] Error 1 (ignored)
 > > test -r /usr/share/misc/config.guess && \
 > >  cp -f /usr/share/misc/config.guess 
 > > /build/buildd/mozart-gtk-20060615/mozart-gtk-1.1/config.guess
 > > make: [source-stamp] Error 1 (ignored)
 > > chmod u=rwx,g=rx,o=rx 
 > > /build/buildd/mozart-gtk-20060615/mozart-gtk-1.1/configure
 > > echo > source-stamp
 > > dh_testdir
 > > mkdir /build/buildd/mozart-gtk-20060615/BUILD || true
 > > cd /build/buildd/mozart-gtk-20060615/BUILD && 
 > > /build/buildd/mozart-gtk-20060615/mozart-gtk-1.1/configure \
 > >--host=sparc-linux-gnu \
 > >--build=sparc-linux-gnu \
 > >--with-gtk-canvas-dir=/usr
 > > creating cache ./config.cache
 > > checking host system type... sparc-unknown-linux-gnu
 > > checking for oztool... /usr/bin/oztool
 > > checking for ozdoc... /usr/bin/ozdoc
 > > sh: /usr/lib/mozart/platform/unknown-unknown/oztool.sh: No such file or 
 > > directory
 > > checking for gmake... no
 > > checking for make... make
 > > checking whether make sets ${MAKE}... yes
 > > checking for a BSD compatible install... /usr/bin/install -c
 > > checking for mkinstalldirs... 
 > > /build/buildd/mozart-gtk-20060615/mozart-gtk-1.1/mkinstalldirs
 > > checking for c++... c++
 > > checking whether the C++ compiler (c++ -O ) works... yes
 > > checking whether the C++ compiler (c++ -O ) is a cross-compiler... no
 > > checking whether we are using GNU C++... yes
 > > checking whether c++ accepts -g... yes
 > > checking c++ version is at least 2.7... yes (4.1.2)
 > > checking how to run the C++ preprocessor... c++ -E
 > > checking for ozc... /usr/bin/ozc
 > > checking for ozl... /usr/bin/ozl
 > > checking for ozengine... /usr/bin/ozengine
 > > checking for flex... flex
 > > checking for yywrap in -lfl... yes
 > > checking flex version is at least 2.5.3... yes (2.5.4)
 > > checking for bison... bison -y
 > > checking bison -y version is at least 1.25... yes (2.3)
 > > checking for cpp... /usr/bin/cpp
 > > checking for tricky preprocessor options... 
 > > checking for -s option to oztool ld... no
 > > checking for gtk-config... /usr/bin/gtk-config
 > > checking gtk c flags... -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
 > > -I/usr/lib/glib/include
 > > checking for options to filter from gtk c flags... keeping: 
 > > -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
 > > checking gtk lib flags... -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk 
 > > -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
 > > checking for imlib-config... /usr/bin/imlib-config
 > > checking imlib c flags... -I/usr/X11R6/include
 > > checking for options to filter from imlib c flags... keeping: 
 > > -I/usr/X11R6/include
 > > checking imlib lib flags... -L/usr/lib -lImlib -ljpeg -ltiff -lungif -lpng 
 > > -lz -lm -lXext -L/usr/X11R6/lib -lSM -lICE -lXext -lX11
 > > checking for libart-config... /usr/bin/libart-config
 > > checking libart c flags... -I/usr/include/gnome-1.0
 > > checking for options to filter from libart c flags... keeping: 
 > > -I/usr/include/gnome-1.0
 > > checking libart lib flags... -L/usr/lib -lart_lgpl -lm
 > > checking for GTK+ version... 1.2.10
 > > checking for --with-gtk-canvas-dir... canvas directory = /usr
 > > updating cache ./config.cache
 > > creating ./config.status
 > > creating Makefile
 > > dh_testdir
 > > /usr/bin/make -C /build/buildd/mozart-gtk-20060615/BUILD
 > > make[1]: Entering directory `/build/buildd/mozart-gtk-20060615/BUILD'
 > > cpp -I/usr/X11R6/include -I/usr/include/gnome-1.0 -I/usr/include/gtk-1.2 
 > > -I/usr/include/glib-1.2 -I/usr/lib/glib/include  -D__IEEE_LITTLE_ENDIAN 
 > > -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include 
 > > -I/usr/include -I/usr/include/gnome-1.0 -I/usr/X11R6/include 
 > > /build/buildd/mozart-gtk-20060615/mozart-gtk-1.1/gtkdefs.c > gtkraw.c
 > > flex -olex.yy.cc /build/buildd/mozart-gtk-20060615/mozart-gtk-1.1/c.flex
 > > bison -y -d /build/buildd/mozart-gtk-20060615/mozart-gtk-1.1/c.bison
 > > conflicts: 1 shift/reduce
 > > cp y.tab.

Bug#400355: mozart-gtk: FTBFS: arch is unknown ?

[Kevin Glynn]

reassign 400355 mozart
thanks

Julien Danjou writes:
 > At 1164838229 time_t, Kevin Glynn wrote:
 > > Can you send me the output of this command when run on this machine
 > > (nasya):
 > > 
 > >echo "`uname -m` `uname -s` `uname -r`"
 > 
 > sparc64 Linux 2.6.18-1-sparc64
 > 
 > Unfortunately, spontini is still locked down.
 > 
 > > Do you know if there is anything different about this machine compared
 > > to the other autobuilders.  If you have access it would be helpful if
 > > you could also run the above command on spontini as well.
 > 
 > As far as I can tell there is nothing different :)
 > 

Well, nasya is identifying itself as a sparc64 and I guess spontini is
just using sparc.

Mozart won't run on 64 bit architectures.  However, from reading 

   http://www.debian.org/ports/sparc/

It looks like everything is actually built and run in 32 bit mode.   

I am a bit surprised that mozart built on sparc64,  did you build it
yourself (if so, would you mind sending me the logs for my
interest), or did you install the sparc binary?


I can enable mozart for sparc64 but before doing that I would like to
know that the test suite runs OK.

Please build mozart, then cd to 

cd /mozart-1.3.2.20060615+dfsg/BUILD/share/test

make boot-all
make boot-check

If that prints a big PASSED at the end then I will make the change, if
not please send me the log.

Thanks a lot for your help.

k
 
 


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

Bug#400355: mozart-gtk: FTBFS: arch is unknown ?

[Kevin Glynn]

That explains my confusion.  It may well be that mozart can run on
sparc64 but it needs testing.  Would it be possible for me to have an
account?  I am not a DD, I am currently in the application process.

Otherwise I will need your help to modify the mozart sources to see if
it will build.

It is unfortunate that different machines in the same Debian
architecture report that they have different underlying architectures


cheers
k

On 12/1/06, Julien Danjou <[EMAIL PROTECTED]> wrote:

At 1164895512 time_t, Kevin Glynn wrote:
> I am a bit surprised that mozart built on sparc64,  did you build it
> yourself (if so, would you mind sending me the logs for my
> interest), or did you install the sparc binary?

I installed the sparc binary via apt-get.
However I just tried to build mozart and it FTBFS:
OZTOOL_CC="gcc" /bin/sh
/home/jd/mozart-1.3.2.20060615+dfsg/BUILD/platform/emulator/oztool.sh cc
-O  -I/home/jd/mozart-1.3.2.20060615+dfsg/mozart/platform/emulator  -c
/home/jd/mozart-1.3.2.20060615+dfsg/mozart/platform/tools/gump/ozbison/version.c
-o version.o
OZTOOL_CC="gcc" /bin/sh
/home/jd/mozart-1.3.2.20060615+dfsg/BUILD/platform/emulator/oztool.sh cc
-O  -I/home/jd/mozart-1.3.2.20060615+dfsg/mozart/platform/emulator  -c
/home/jd/mozart-1.3.2.20060615+dfsg/mozart/platform/tools/gump/ozbison/alloca.c
-o alloca.o
OZTOOL_LD="gcc" /bin/sh
/home/jd/mozart-1.3.2.20060615+dfsg/BUILD/platform/emulator/oztool.sh ld
-o Bison.so-unknown-unknown LR0.o allocate.o closure.o conflicts.o
derives.o gram.o lalr.o main.o nullable.o output.o print.o reader.o
reduce.o symtab.o warshall.o version.o alloca.o
ld: warning: cannot find entry symbol _start; defaulting to
00010094
LR0.o: In function `augment_automaton':
LR0.c:(.text+0x620): undefined reference to `free'
LR0.c:(.text+0x74c): undefined reference to `free'
LR0.o: In function `free_storage':
LR0.c:(.text+0x8a8): undefined reference to `free'
LR0.c:(.text+0x8c4): undefined reference to `free'
LR0.c:(.text+0x8e0): undefined reference to `free'
[...]
symtab.o: In function `copys':
symtab.c:(.text+0x12c): undefined reference to `strlen'
symtab.c:(.text+0x13c): undefined reference to `strcpy'
symtab.o: In function `getsym':
symtab.c:(.text+0x188): undefined reference to `strcmp'
make[6]: *** [Bison.so-unknown-unknown] Error 1
make[6]: Leaving directory
`/home/jd/mozart-1.3.2.20060615+dfsg/BUILD/platform/tools/gump/ozbison'

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






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

Bug#400355: mozart-gtk: FTBFS: arch is unknown ?

[Kevin Glynn]

Steve Langasek writes:
 > On Fri, Dec 01, 2006 at 09:15:49AM -0600, Kevin Glynn wrote:
 > > That explains my confusion.  It may well be that mozart can run on
 > > sparc64 but it needs testing.
 > 
 > No, "sparc64" has nothing to do with this.  The value returned by uname
 > *should* have nothing to do with this.  Almost all sparc systems in use
 > today are 64-bit processors, but the Debian userspace port is a *32-bit*
 > system; and building code with gcc without specific flags gets you 32-bit
 > binaries, not 64-bit binaries.
 > 
 > If something in mozart is looking at the uname and deciding to enable some
 > kind of 64-bit functionality, that's a bug in mozart.  With very few
 > exceptions, the target that Debian packages need to be building for on sparc
 > is sparc-linux, *not* sparc64-linux; and your package is not one of those
 > exceptions, because it doesn't have any of the necessary 64-bit
 > build-dependencies...
 > 

Mozart (upstream) is very anal about these things.  If it meets a
strange architecture it just refuses to play.  We need to show it works
then enable support.  It would be nice if mozart just checked the
functionality of the platform it is building on but it doesn't.

Also, mozart is not enabling any 64-bit functionality.  Sadly it runs
away and hides in a corner if it even hears a rumour that the
platform is 64 but .

 > > It is unfortunate that different machines in the same Debian
 > > architecture report that they have different underlying architectures
 > > 
 > 
 > You should be ignoring the output of uname altogether.  I don't know if
 > uname is actually confusing mozart's build, but it does seem to be confusing
 > its maintainer. ;)
 > 

As I said in my response to the previous message I am not sure that we
are ignoring the passed in architecture string during configure, but
we will still break when we run certain scripts which rely on uname to
find their buddies.

Yours helplessly,

k




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

Bug#400355: mozart-gtk: FTBFS: arch is unknown ?

[Kevin Glynn]

Steve Langasek writes:
 > Side note -- sparc does have a "sparc32" util that can be used to change the
 > kernel personality that a process is running under (i.e., it changes the
 > output of uname among other things...), and I believe the official buildds
 > run all builds under sparc32 to avoid precisely these issues.  Julien, can
 > you confirm whether mozart/mozart-gtk build for you under sparc32?
 > 
 > It's still a bug in these packages if they're looking at the value of uname
 > instead of the architecture string from configure (in this case, one that's
 > been passed *explicitly* on the commandline!), but there's no reason it
 > should need to be RC if sparc32 works around it.

Mozart is a platform specific emulator and platform agnostic byte
codes all living in the same place.  Upstream supports many platforms
sharing a common installation (in shared filespace) by dynamically
finding the right emulator by calling uname 

For debian we do things different.  I can modify our package to map
sparc64 to sparc-linux and all will work (if sparc64 really is 32
bit), but I don't think this is a change I could feed to upstream.

I don't think running the build under sparc32 is a solution because it
means the users will have to also invoke mozart/oz under sparc32.

cheers
k


 


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

Bug#401324: mysql-server-5.0: Upgrade fails badly (hangs)

[Kevin Glynn]

Package: mysql-server-5.0
Version: 5.0.27-1
Severity: serious


Hangs duing upgrade:


   The following packages have been kept back:
 emacs-snapshot-common mozilla mozilla-browser mozilla-mailnews mozilla-psm
   The following packages will be upgraded:
 mysql-server-5.0
   1 packages upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
   Need to get 0B/25.7MB of archives. After unpacking 32.8kB will be used.
   Do you want to continue? [Y/n/?]
   Reading package fields... Done
   Reading package status... Done
   Retrieving bug reports... Done
   Parsing Found/Fixed information... Done
   Reading changelogs... Done
   Preconfiguring packages ...
   Selecting previously deselected package mysql-server-5.0.
   (Reading database ... 237922 files and directories currently installed.)
   Preparing to replace mysql-server-5.0 5.0.27-1 (using 
.../mysql-server-5.0_5.0.27-2_amd64.deb) ...
   Stopping MySQL database server: mysqld.
   /etc/lsb-base-logging.sh: line 42: RUNLEVEL: unbound variable
   invoke-rc.d: initscript mysql, action "stop" failed.
   dpkg: warning - old pre-removal script returned error exit status 1
   dpkg - trying script from the new package instead ...
   Stopping MySQL database server: mysqld.
   /etc/lsb-base-logging.sh: line 42: RUNLEVEL: unbound variable
   invoke-rc.d: initscript mysql, action "stop" failed.
   dpkg: error processing 
/var/cache/apt/archives/mysql-server-5.0_5.0.27-2_amd64.deb (--unpack):
subprocess new pre-removal script returned error exit status 1
   Stopping MySQL database server: mysqld.
   /etc/lsb-base-logging.sh: line 42: RUNLEVEL: unbound variable
   invoke-rc.d: initscript mysql, action "stop" failed.
   Starting MySQL database server: mysqld.
   /etc/lsb-base-logging.sh: line 42: RUNLEVEL: unbound variable
   invoke-rc.d: initscript mysql, action "start" failed.

If I press ^C, I get:

   dpkg: error while cleaning up:
subprocess post-installation script killed by signal (Interrupt)
   Errors were encountered while processing:
/var/cache/apt/archives/mysql-server-5.0_5.0.27-2_amd64.deb
   E: Sub-process /usr/bin/dpkg returned an error code (1)
   A package failed to install.  Trying to recover:
   dpkg: error processing mysql-server-5.0 (--configure):
Package is in a very bad inconsistent state - you should
reinstall it before attempting configuration.
   Errors were encountered while processing:
mysql-server-5.0

I can't remove the package because I get the same error.

If I try to stop mysql:

   @twiglet:mozart 4Q> sudo /etc/init.d/mysql stop
   Stopping MySQL database server: mysqld.
   /etc/lsb-base-logging.sh: line 42: RUNLEVEL: unbound variable

k



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

Versions of packages mysql-server-5.0 depends on:
ii  adduser 3.100Add and remove users and groups
ii  debconf [debconf-2.0]   1.5.9Debian configuration management sy
ii  libc6   2.3.6.ds1-8  GNU C Library: Shared libraries
ii  libdbi-perl 1.53-1   Perl5 database interface by Tim Bu
ii  libgcc1 1:4.1.1-20   GCC support library
ii  libmysqlclient15off 5.0.27-2 mysql database client library
ii  libncurses5 5.5-5Shared libraries for terminal hand
ii  libreadline55.2-1GNU readline and history libraries
ii  libstdc++6  4.1.1-20 The GNU Standard C++ Library v3
ii  libwrap07.6.dbs-11   Wietse Venema's TCP wrappers libra
ii  lsb-base3.1-22   Linux Standard Base 3.1 init scrip
ii  mysql-client-5.05.0.27-2 mysql database client binaries
ii  mysql-common5.0.27-2 mysql database common files (e.g. 
ii  passwd  1:4.0.18.1-5 change and administer password and
ii  perl5.8.8-6.1Larry Wall's Practical Extraction 
ii  psmisc  22.3-1   Utilities that use the proc filesy
ii  zlib1g  1:1.2.3-13   compression library - runtime

Versions of packages mysql-server-5.0 recommends:
ii  mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent

-- debconf information:
  mysql-server-5.0/really_downgrade: false
  mysql-server-5.0/start_on_boot: true
  mysql-server-5.0/nis_warning:
  mysql-server-5.0/postrm_remove_databases: false
  mysql-server-5.0/no_upgrade_with_isam_tables:
* mysql-server-5.0/mysql_install_db_notes:
  mysql-server-5.0/need_sarge_compat: false
  mysql-server/error_setting_password:
  mysql-server-5.0/mysql_update_hints1:
  mysql-server-5.0/need_sarge_compat_done: true


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

Bug#400355: mozart-gtk: FTBFS: arch is unknown ?

[Kevin Glynn]

tags 400355 pending
thanks

I will submit a new version of mozart to my sponsor that will treat
sparc64 as sparc, and set urgency=medium.

k






Julien Danjou writes:
 > At 1165019355 time_t, Steve Langasek wrote:
 > > Side note -- sparc does have a "sparc32" util that can be used to change 
 > > the
 > > kernel personality that a process is running under (i.e., it changes the
 > > output of uname among other things...), and I believe the official buildds
 > > run all builds under sparc32 to avoid precisely these issues.  Julien, can
 > > you confirm whether mozart/mozart-gtk build for you under sparc32?
 > 
 > Yes, they both build fine under sparc32.
 > 
 > Cheers,
 > -- 
 > Julien Danjou
 > .''`.  Debian Developer
 > : :' : http://julien.danjou.info
 > `. `'  http://people.debian.org/~acid
 >   `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


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

Bug#401627: mozart: FTBFS on kfreebsd-i386

[Kevin Glynn]

Please check that the mozart test suite runs successfully.  To do
this then, after the package has built:

  cd mozart-1.3.2.20060615+dfsg/BUILD/share/test
  make boot-all
  make boot-check

and send me the output.

If I am happy with that then I will enable this architecture and
upload a new package.  I can also make the change to upstream.

cheers
k




Petr Salinger writes:
 > Package: mozart
 > Severity: important
 > Version: 1.3.2.20060615+dfsg-1
 > Tags: patch
 > 
 > 
 > Hi,
 > 
 > the current version fails to build on GNU/kFreeBSD.
 > 
 > It needs just to add recognition into ozplatform,
 > see bellow. Please also do not forget to add kfreebsd-i386
 > into Architecture line in debian/control.
 > 
 > It would also be nice if you can ask upstream
 > to include this change.
 > 
 > Thanks in advance
 > 
 >  Petr
 > 
 > 
 > --- mozart/share/bin/ozplatform
 > +++ mozart/share/bin/ozplatform
 > @@ -13,6 +13,8 @@
 >   #-
 >   # tentative new platforms pending confirmation
 >   #-
 > +i[4567]86\ GNU/kFreeBSD\ *) OZARCH=linux-i486
 > +;;
 >   mips\ Linux\ *)OZARCH=linux-mips
 >   ;;
 >   s390\ Linux\ *)OZARCH=linux-s390
 > 
 > 


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

Bug#411956: emacs-snapshot: Aborts during byte-compilation

[Kevin Glynn]

Romain Francoise writes:
 > Kevin Glynn <[EMAIL PROTECTED]> writes:
 > 
 > > @twiglet:code 4Q> emacs-snapshot -q -no-site-file -batch -f 
 > > batch-byte-compile Fontifier.el
 > >>>Error occurred processing Fontifier.el: Symbol's value as variable is 
 > >>>void ((t))
 > > (1)
 > 
 > After investigation, this might be a different issue.
 > Did the file compile before?
 > 

I'm sure that it compiled Ok "a few months ago" with emacs-snapshot.
Sorry, I don't know exactly when it broke I hadn't tried to build for
a while.  I will look at snapshot.debian.net and see if I can wind
back emacs-snapshot to find the place it broke if that would be
helpful. 

thanks
k


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

Bug#397381: diff for (Proposed) 2.0.8.2 NMU

[Kevin Glynn]

Package: apt-file
Version: 2.0.8.1
Severity: normal
Tags: patch

Hi,

Attached is the diff for my (proposed) apt-file 2.0.8.2 NMU. It is
a cut down version of the previous patch for #382312, that is limited
to closing #382312 (and updating the Version String).

Since I am not a DD I can't upload this NMU myself.  If I don't hear from 
you soon I will try and find a DD who is willing to sponsor this upload.

Note, that I have made this NMU version 2.0.8.2, following the precedent set
by the previous NMU.

regards
Kevin

diff -Nru /tmp/QNYq976uyZ/apt-file-2.0.8.1/apt-file 
/tmp/wdoamkvcx0/apt-file-2.0.8.2/apt-file
--- /tmp/QNYq976uyZ/apt-file-2.0.8.1/apt-file   2006-10-27 13:32:44.0 
-0500
+++ /tmp/wdoamkvcx0/apt-file-2.0.8.2/apt-file   2006-11-06 16:36:53.0 
-0600
@@ -28,7 +28,7 @@
 use Data::Dumper;
 use File::Basename;
 use AptPkg::Config '$_config';
-use constant VERSION => "2.0.7";
+use constant VERSION => "2.0.8.2";
 
 
 my $Conf;
@@ -206,6 +206,32 @@
 }
 }
 
+sub print_winners ($$) {
+my ($db, $matchfname) = @_;
+my $filtered_db;
+
+# $db is a hash from package name to array of file names.  It is
+# a superset of the matching cases, so first we filter this by the 
+# real pattern.
+foreach my $key (keys %$db) {
+if ($matchfname || ($key =~ /$Conf->{pattern}/)) {
+$filtered_db->{$key} = $db->{$key};
+}
+}
+
+# Now print the winners
+if (!defined $Conf->{package_only}) {
+   foreach my $key (sort keys %$filtered_db) {
+   foreach (sort @{$filtered_db->{$key}}) {
+   print "$key: $_\n";
+   }
+   }
+} else {
+   print map {"$_\n"} (sort keys %$filtered_db);
+}
+exit 0;
+}
+
 sub do_grep($$) {
 my ($data, $pattern) = @_;
 my $ret;
@@ -231,17 +257,7 @@
close ZCAT;
debug_line "\n";
 }
-$ret = reverse_hash($ret);
-if (!defined $Conf->{package_only}) {
-   foreach my $key (sort keys %$ret) {
-   foreach (sort @{unique $ret->{$key}}) {
-   print "$key: $_\n";
-   }
-   }
-} else {
-   print map {"$_\n"} (sort keys %$ret);
-}
-exit 0;
+return reverse_hash($ret);
 }
 
 sub grep_file($) {
@@ -253,21 +269,24 @@
")" : '[^\s]*)',
'\s+(\S+)\s*$',
);
-do_grep $data, $pattern;
+my $ret = do_grep $data, $pattern;
+print_winners $ret, 1; 
 }
 
 sub grep_package($) {
 my $data = shift;
+# File name may contain spaces, so match template is 
+# ($fname, $pkgs) = (line =~ '^\s*(.*?)\s+(\S+)\s*$')
 my $pattern = join "", (
-   '^(\S+)\s+',
+   '^\s*(.*?)\s+',
'(\S*/',
$Conf->{pattern},
defined $Conf->{fixed_strings} ?
-   "" : ".*",
-   ")",
-   '$',
+   '(,\S*|)' : '\S*',
+   ')\s*$',
);
-do_grep $data, $pattern;
+my $ret = do_grep $data, $pattern;
+print_winners $ret, 0;
 }
 
 sub purge_cache($) {
diff -Nru /tmp/QNYq976uyZ/apt-file-2.0.8.1/debian/changelog 
/tmp/wdoamkvcx0/apt-file-2.0.8.2/debian/changelog
--- /tmp/QNYq976uyZ/apt-file-2.0.8.1/debian/changelog   2006-10-27 
13:38:03.0 -0500
+++ /tmp/wdoamkvcx0/apt-file-2.0.8.2/debian/changelog   2006-11-06 
16:53:59.0 -0600
@@ -1,3 +1,20 @@
+apt-file (2.0.8.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * The Contents.gz files map a file to the list of packages that
+contain it. do_grep grabs all these packages, this fix
+post-processes its result so that we only print out the packages
+that do match the given pattern.  Also, take account that a file
+name may have spaces and avoid false positives by tightening the
+grep pattern.  NOTE: this is a minimal NMU patch to close
+important bug #382312 (it also closes two similar bugs). 
+There is a more complete patch available in the bts for
+#382312 that I think would make apt-file much more useful and
+closes other bugs. (Closes: #382312, #376607, #358821)
+  * Updated Version String to 2.0.8.2 (Closes: #376458)
+
+ -- Kevin Glynn <[EMAIL PROTECTED]>  Mon,  6 Nov 2006 15:47:57 -0600
+
 apt-file (2.0.8.1) unstable; urgency=low
 
   * Non-maintainer upload by Gunnar Wolf

Bug#382312: Processed: reopening 382312, retitle 382312 to apt-file: please apply more complete patch to fix output ...

[Kevin Glynn]

Justin,

It is not clear to me what the intent of this reopening/retitling is. 

Do you mean that the fuller patch attached to this report should be
applied? If so, then I would like to see that too.  I am planning to
rewrite the patch against 2.0.8.2 and add it to the remaining open
bugs. However, it was a struggle to find someone to NMU 2.0.8.2 which
was limited to closing the severity important report.  I was thinking
that I could push it again post-etch.

Or is there still an aspect of this report that is still open to do
with fixing apt-file's output? I can't see what that would be.


cheers
k



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

Bug#358449: FTBFS with G++ 4.1: extra qualification & co

[Kevin Glynn]

Martin Michlmayr writes:
 > * Kevin Glynn <[EMAIL PROTECTED]> [2006-03-25 17:58]:
 > > A patch for gcc 4.1 is available from upstream and I will apply it
 > > when I make the next release.  Upstream is planning a 1.3.2 release
 > > which I will wait for.
 > 
 > What's the status of this?  It would be ni to get this into unstable
 > in the next 2 weeks.


Why?  As far as I know the new release is still 'in preparation', but
I don't know when it will happen.  I can make a new release of Debian
that will be 'nearly' 1.3.2 if there is a good reason.

   
cheers
k




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

Bug#349703: Bug #349703: gnome-terminal: display screwed when searching command history in secondary tab

[Kevin Glynn]

Vincent Ho writes:
 > Version: 2.14.2-1
 > 
 > On Thu, Jul 06, 2006 at 01:45:34AM +0200, Daniel Rodriguez Garcia wrote:
 > 
 > > The problem seems to be solved in current version (debian testing / etch)
 > 
 > Thanks, I'm marking the bug as fixed in 2.14.2-1 then.
 > 
 > 
 >   Vince
 > 
 > -- 
 >   Vincent Ho
 > 
 > "If we hit that bullseye, the rest of the dominos will fall like a house
 > of cards. Checkmate."


Sorry, I was on vacation last week.  I cannot reproduce this bug any
more with current Debian Unstable.  Thanks for following up and
closing this.

cheers
k


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

Bug#381452: emacs21: FTBFS on mips, mipsel

[Kevin Glynn]

Package: emacs21
Version: 21.4a-6
Severity: normal

Logs at:

   http://buildd.debian.org/build.php?arch=mips&pkg=emacs21&ver=21.4a-6

and

   http://buildd.debian.org/build.php?arch=mipsel&pkg=emacs21&ver=21.4a-6

This is stopping mozart, and presumably many other packages progressing to 
etch. Apologies
if this has already been reported, but I can't find anything appropriate.

k


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

Versions of packages emacs21 depends on:
ii  emacs21-bin-common  21.4a-6  The GNU Emacs editor's shared, arc
ii  libc6   2.3.6-18 GNU C Library: Shared libraries
ii  libice6 1:1.0.0-3X11 Inter-Client Exchange library
ii  libjpeg62   6b-13The Independent JPEG Group's JPEG 
ii  libncurses5 5.5-2Shared libraries for terminal hand
ii  libpng12-0  1.2.8rel-5.2 PNG library - runtime
ii  libsm6  1:1.0.0-4X11 Session Management library
ii  libtiff43.8.2-6  Tag Image File Format (TIFF) libra
ii  libungif4g  4.1.4-2  shared library for GIF images (run
ii  libx11-62:1.0.0-7X11 client-side library
ii  libxext61:1.0.0-4X11 miscellaneous extension librar
ii  libxmu6 1:1.0.1-3X11 miscellaneous utility library
ii  libxpm4 1:3.5.4.2-3  X11 pixmap library
ii  libxt6  1:1.0.0-5X11 toolkit intrinsics library
ii  xaw3dg  1.5+E-14 Xaw3d widget set
ii  zlib1g  1:1.2.3-13   compression library - runtime

emacs21 recommends no packages.

-- no debconf information


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

Bug#390127: mozart_1.3.2.20060615-1: FTBFS with -rsudo

[Kevin Glynn]

Steve Langasek writes:
 > Package: mozart
 > Version: 1.3.2.20060615-1
 > Severity: serious
 > 
 > emacs21 is now fixed finally on mips and mipsel, but mozart still fails to
 > build because it uses the $(PWD) variable in its debian/rules and this
 > variable is not preserved by sudo:
 > 

Thanks for the report.  I had noticed this too and I have sent an
update of the package that fixes this problem to my sponsor.
Hopefully, it will be uploaded soon.

regards
Kevin


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

Bug#382865: complains about missing .hpodder/curlrc file

[Kevin Glynn]

Package: hpodder
Version: 0.5.3
Severity: minor


Since a recent upgrade hpodder has started complaining about not being able to 
read my (non-existant) curlrc file:

   @twiglet:~ 4Q> hpodder
   11 podcast(s) to consider

* Podcast 1: http://soundofhistory.complete.org/files_soh/podcast.xml
   Warning: error trying read config from the '/home/keving/.hpodder/curlrc' 
file
    
100.0%
  0 new episodes

etc.

cheers
k



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

Versions of packages hpodder depends on:
ii  curl  7.15.5-1   Get a file from an HTTP, HTTPS, FT
ii  id3v2 0.1.11-3   A command line id3v2 tag editor
ii  libc6 2.3.6-19   GNU C Library: Shared libraries
ii  libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library
ii  libsqlite3-0  3.3.5-0.2+b1   SQLite 3 shared library

hpodder recommends no packages.

-- no debconf information


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

Bug#393399: Source package contains non-free IETF RFC/I-D's

[Kevin Glynn]

tags 393399 pending
thanks

I shall replace the included rfc with a README file that tells the
reader where they can find the text for themselves [either in non-free
package doc-rfc-2000-2999 or download via
http://www.ietf.org/rfc/rfc2229.txt]. 

cheers
k
 


Simon Josefsson writes:
 > Package: mozart
 > Version: 1.3.2.20060615-2
 > Severity: serious
 > 
 > Hi!
 > 
 > This bug has been filed on multiple packages, and general discussions
 > are kindly requested to take place on debian-legal or debian-devel in
 > the thread with Subject: "Non-free IETF RFC/I-Ds in source packages".
 > 
 > It seems this source package contains the following files from the
 > IETF under non-free license terms:
 > 
 > mozart-1.3.2.20060615/mozart/share/demo/DictClient/rfc2229.txt 
 > 
 > The license on RFC/I-Ds is not DFSG-free, see:
 >  * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199810
 >  * http://release.debian.org/removing-non-free-documentation
 >  * http://wiki.debian.org/NonFreeIETFDocuments
 > 
 > The etch release policy says binary and source packages must each be free:
 >  * http://release.debian.org/etch_rc_policy.txt
 > 
 > The severity is serious, because this violates the Debian policy:
 >  * http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg
 > 
 > There are (at least) three ways to fix this problem.  In order of
 > preference:
 > 
 > 1. Ask the author of the RFC to re-license the RFC under a free
 >license.  A template for this e-mail request can be found at
 >http://wiki.debian.org/NonFreeIETFDocuments
 > 
 > 2. Remove the non-free material from the source, e.g., by re-packaging
 >the upstream archive and adding a 'dfsg' version name to it.
 > 
 > 3. Move the package to non-free.
 > 
 > I went over many packages looking for names of likely non-free files,
 > and there may be false positives.  If this is the case for your
 > package, I'm sorry for the noise.  I'll modify the scripts to take
 > into account false positives when I learn of them, and publish the
 > list of exceptions under "Known exceptions" at
 > .
 > 
 > Thanks,
 > Simon
 > 


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

Bug#393758: man page for ipod

[Kevin Glynn]

Package: ipod
Tags: patch

Please find attached a proposed man page for the ipod executable. 

I discovered that the usage information for ipod (from 'ipod --help')
is incorrect.  It would be helpful if you could sync that from the
attached manpage.

regards
Kevin 




ipod.1
Description: Binary data

Bug#392077: Processed: joe: execmd with empty command results in SEGV

[Kevin Glynn]

Josip Rodin writes:
 > On Tue, Oct 17, 2006 at 02:34:27PM -0700, Debian Bug Tracking System wrote:
 > > Processing commands for [EMAIL PROTECTED]:
 > > 
 > > > tags 392077 + patch
 > > Bug#392077: joe: execmd with empty command results in SEGV
 > > There were no tags set.
 > > Bug#392304: joe: yet another segfault: alt/x enter segfault(loss of data)
 > > Tags added: patch
 > 
 > On Tue, Oct 17, 2006 at 16:25:52 -0500, Kevin Glynn wrote:
 > > The attached patch to joe 3.5-1 just treats a blank command string
 > > (i.e. empty or all whitespace) as an unknown command.
 > 
 > Kevin, please Cc: the bug address when adding stuff, otherwise your mail is
 > relegated to a footnote in the bug log.
 > 

Sorry, first time I tried to add a patch.

 > I wonder, however, why this isn't handled by those bits:
 > 
 >  /* Do we have a command? */
 > [...]
 > if (!cmd) {
 > *sta = -1;
 > return NULL;
 > 

I believe we skip over this last statement because we are already at
the end of the buffer. The for loop finishes immediately and y still
equals x:

/* Do we have a command? */
else {
for (y = x; buf[y] && buf[y]!='#' && buf[y] != '!' &&
buf[y] != '~' && buf[y] !='-' && buf[y] != ',' &&
buf[y] != ' ' && buf[y] != '\t' &&
buf[y] != '\n' && buf[x] != '\r'; ++y) ;

if (y != x) {

[...]
 if (!cmd) {
 *sta = -1;
 return NULL;
 


regards
Kevin



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

Bug#394373: linux-headers-2.6.18-1-amd64: Missing /lib/modules/2.6.18-1-amd64/build link

[Kevin Glynn]

Package: linux-headers-2.6.18-1-amd64
Version: 2.6.18-2
Severity: normal


/lib/modules/2.6.18-1-amd64/build is shipped as an empty directory in
linux-headers-2.6.18-1-amd64. It should be a symbolic link to 
/usr/src/linux-headers-2.6.18-1-amd64/ (I needed that to build ivtv 0.8.0 
from source)

Apologies if this is a dupe, I did search the bug list for linux-2.6 
a number of ways ...

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

Versions of packages linux-headers-2.6.18-1-amd64 depends on:
ii  gcc-4.1   4.1.1-16   The GNU C compiler
ii  linux-headers-2.6.18-12.6.18-2   Common header files for Linux 2.6.
ii  linux-kbuild-2.6.18   2.6.18-1   Kbuild infrastructure for Linux 2.

linux-headers-2.6.18-1-amd64 recommends no packages.

-- no debconf information


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

Bug#358896: FTBFS on AMD64: cast loses precision

[Kevin Glynn]

Mozart cannot be built on 64 bit systems. There is an open upstream
bug for this and already a debian wislist bug (#119583).  I don't
think this will be fixed any time soon, so I suggest you respect the
Architecture line in the control file 

regards and thanks for your report,

k


Martin Michlmayr writes:
 > Package: mozart
 > Version: 1.3.1.20040616-11
 > Severity: important
 > 
 > Your package fails to build on AMD64 (and probably Alpha) with:
 > error: cast from 'char*' to 'unsigned int' loses precision
 > 
 > 
 > > Automatic build of mozart_1.3.1.20040616-11 on em64t by sbuild/amd64 1.106
 > ...
 > > c++ -DHAVE_CONFIG_H -I. 
 > > -I/build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator  
 > > -DSITE_PROPERTY -fno-exceptions  -fno-implicit-templates  -c -o 
 > > stack.o /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/stack.cc
 > > /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/mozart.h: In 
 > > member function 'void OZ_Container::cacMark(OZ_Container*)':
 > > /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/mozart.h:731: 
 > > error: cast from 'OZ_Container*' to 'unsigned int' loses precision
 > > /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/mozart_cpi.hh: 
 > > In member function 'OZ_CPIVar::operator OZ_Term() const':
 > > /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/mozart_cpi.hh:881:
 > >  error: cast from 'OZ_Term*' to 'OZ_Term' loses precision
 > > /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/mem.hh: In 
 > > function 'void* oz_heapDoubleMalloc(size_t)':
 > > /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/mem.hh:329: 
 > > error: cast from 'char*' to 'unsigned int' loses precision
 > > /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/mem.hh: In 
 > > function 'void oz_freeListDisposeUnsafe(void*, size_t)':
 > > /build/tbm/mozart-1.3.1.20040616/mozart/platform/emulator/mem.hh:348: 
 > > error: cast from 'char*' to 'unsigned int' loses precision
 > > make[3]: *** [stack.o] Error 1
 > 
 > 
 > -- 
 > Martin Michlmayr
 > http://www.cyrius.com/
 > 


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

Bug#358449: FTBFS with G++ 4.1: extra qualification & co

[Kevin Glynn]

A patch for gcc 4.1 is available from upstream and I will apply it
when I make the next release.  Upstream is planning a 1.3.2 release
which I will wait for.

thanks
k


Martin Michlmayr writes:
 > tags 358449 - patch
 > thanks
 > 
 > * Martin Michlmayr <[EMAIL PROTECTED]> [2006-03-22 19:46]:
 > > A patch is attached.
 > 
 > A partial patch...
 > -- 
 > Martin Michlmayr
 > http://www.cyrius.com/
 > 


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

Bug#358896: FTBFS on AMD64: cast loses precision

[Kevin Glynn]

severity wishlist
merge 119583
thanks
k


Martin Michlmayr writes:
 > * Kevin Glynn <[EMAIL PROTECTED]> [2006-03-25 18:00]:
 > > Mozart cannot be built on 64 bit systems. There is an open upstream
 > > bug for this and already a debian wislist bug (#119583).  I don't
 > > think this will be fixed any time soon, so I suggest you respect the
 > > Architecture line in the control file 
 > 
 > Sorry, I did check the BTS for existing bugs, but I didnt look at
 > wishlist bugs.  Please feel free to downgrade and merge.
 > -- 
 > Martin Michlmayr
 > http://www.cyrius.com/
 > 


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

Bug#358896: (no subject)

[Kevin Glynn]

severity 358896 wishlist
merge 358896 119583
thanks

Hopefully I got the syntax right this time!

k



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

Bug#317590: apt-spy: Please include improved error checks in argument parsing code

[Kevin Glynn]

Isn't this bug filed against the wrong package? It is a patch against
apt-spy not apt-file.

regards
Kevin
  


Justin Pryzby writes:
 > Package: apt-file
 > Severity: wishlist
 > Tags: patch
 > 
 > Please include improved error checks in argument parsing code.  Patch
 > is attached which will error on arguments such as "-n 10FOOBAR".
 > 
 > Also fixed is a spelling error and a grammar error.
 > 
 > This patch would probably conflict with:
 > apt-spy.inline-initializations, but I've included the necessary
 > renaming of the variable BESTNUMBER here.
 > 
 > Justin
 > diff -ur apt-spy-3.1/main.c apt-spy-3.1.jp6/main.c
 > --- apt-spy-3.1/main.c   2005-07-08 20:48:09.0 -0400
 > +++ apt-spy-3.1.jp6/main.c   2005-07-09 14:28:52.0 -0400
 > @@ -71,6 +71,7 @@
 >  /* Parse options... */
 >  while((c = getopt(argc, argv, "a:c:d:e:f:i:m:o:p:s:t:u:w:n:vh")) != -1)
 >  switch(c) {
 > +char *end;
 >  /* Area to benchmark */
 >  case 'a':
 >  area = optarg;
 > @@ -85,7 +86,13 @@
 >  break;
 >  /* Number of servers to benchmark */
 >  case 'e':
 > -test_number = atoi(optarg);
 > +test_number = strtol(optarg, &end, 10);
 > +if (!*optarg || end!=optarg+strlen(optarg)) {
 > +fprintf(stderr, "Error parsing number"
 > +" of servers to be"
 > +" benchmarked\n");
 > +exit(1);
 > +}
 >  break;
 >  /* File, relative to Debian base, to grab from server. */
 >  case 'f':
 > @@ -111,9 +118,15 @@
 >  case 's':
 >  country_list = optarg;
 >  break;
 > -/* Time to bencmark each server for. */
 > +/* Time for which to benchmark each server. */
 >  case 't':
 > -timeout = atoi(optarg);
 > +timeout = strtol(optarg, &end, 10);
 > +if (!*optarg || end!=optarg+strlen(optarg)) {
 > +fprintf(stderr, "Error parsing server"
 > +" benchmark time"
 > +" interval\n");
 > +exit(1);
 > +}
 >  break;
 >  /* The URL we should update ourselves from */   
 > 
 >  case 'u':
 > @@ -126,7 +139,13 @@
 >  break;
 >  /* Number of servers to write in "top" server list */
 >  case 'n':
 > -BESTNUMBER = atoi(optarg);
 > +bestnumber = strtol(optarg, &end, 10);
 > +if (!*optarg || end!=optarg+strlen(optarg)) {
 > +fprintf(stderr, "Error parsing number"
 > +" of best servers to"
 > +" write\n");
 > +exit(1);
 > +}
 >  break;
 >  case 'v':
 >  version();


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

Bug#382312: "apt-file -F list" does not list all files

[Kevin Glynn]

tags 382312 patch
thanks

Hi Sebastien,

I started looking at a fix for bug 382312. however many of the
outstanding bug reports on apt-file are related and I ended up with a
patch against version 2.0.8 that I think addresses all the open bugs
to do with broken matching against file names and package names.

I provide detailed notes about the changes below, sorry that it is so
long but I tried to be thorough. 

As part of my application to be a DD I have to do an NMU for a package
to fix a severity important bug. I would be grateful if, after we have
discussed these patches and come to an agreement, you would let me do
an NMU.  Perhaps I could just do a minimal NMU that fixes the severity
important bug 382312.

Thanks for writing a great tool.  I think with these fixes it will
behave a lot closer to how users would want / expect it to.

cheers
Kevin


Change to filtering.

  We filter in two stages, first we do a rough filter against each
  line in the Contents file.  For this, we simplify the provided
  pattern to be sure to get a superset of the matching lines (more
  detail in the comments below).

  We have a separate routine to print the matches (print_winners).
  This first filters the package name or file name against the real
  pattern, as provided, and prints the winners.

  Assuming that the rough filter only matches a small proportion of
  the input files then this allows us to get accurate results
  efficiently.

-F, --fixed

  This is equivalent to searching for names that *end* with the
  given input string. This isn't what the man page but it is close to
  what is done at the moment.

Filenames

  We add back a leading '/' to file names.  Therefore the pattern is
  matching the file as it would appear in the installed system (I
  think that is what the user would expect, but it is not compatible
  with what is done at the moment.

  So:

 @twiglet:apt-file-2.0.8 4Q> ./apt-file search -x ^bin/ls$
 @twiglet:apt-file-2.0.8 4Q> ./apt-file search -x ^/bin/ls$
 coreutils: /bin/ls
 @twiglet:apt-file-2.0.8 4Q>


Misc changes.

  In do_grep 

 - I changed $pack to $pkgs (because it is one or more package
  names).
 - I changed $file to $fname so that it doesn't clash with $file
  used to refer to Contents files.
 - I swap $file and $pkgs when matching entries (because they were
  the wrong way round and that is confusing).

  We save a small amount of time by adding the o modifier to the grep: 

next if ! (($fname, $pkgs) = /$regexp/o);

  which pre-calculates $regexp once.

Fixed Bugs:

#293942: apt-file: Fails to trim header of Contents.gz

   When processing a Contents file we ignore all lines until we see a
   line that matches /FILE\s+LOCATION/. 

   Is the format of Contents files defined somwehere? Can we rely on
   this?
 
#259416: apt-file: weird usage - unclear manpage

  apt-file search -x bin/ls$

   For regex searches we remove any leading ^ and trailing $ when doing
   the rough search. We filter results with the real pattern.  

   @twiglet:apt-file-2.0.8 4Q> ./apt-file search -x bin/ls$
   coreutils: /bin/ls
   systemimager-boot-i386-standard: 
/usr/share/systemimager/boot/i386/standard/initrd_template/bin/ls
   systemimager-boot-ia64-standard: 
/usr/share/systemimager/boot/ia64/standard/initrd_template/bin/ls


  apt-file list postfix

   The final filter in print_winners ensures only contents of packages
   matching postfix are printed.

   @twiglet:apt-file-2.0.8 4Q> ./apt-file list -p postfix
   postfix
   postfix-cdb
   postfix-dev
   postfix-doc
   postfix-gld
   postfix-ldap
   postfix-mysql
   postfix-pcre
   postfix-pgsql
   postfix-policyd
   postfix-smtpguard
   @twiglet:apt-file-2.0.8 4Q>

  apt-file -F postfix

   This now only prints contents of packages that end in 'postfix'

#382312: "apt-file -F list" does not list all files

   When searching for packages with -F flag set.  We insist that
either matches the end of the package list or is followed
   by a ','

   @twiglet:apt-file-2.0.8 4Q> ./apt-file list cyrus-clients-2.2 | wc -l
   19
   @twiglet:apt-file-2.0.8 4Q> ./apt-file list -F cyrus-clients-2.2 | wc -l
   19

#376607: apt-file seems ignorant of some files

   We don't ignore files appearing in multiple packages and we accept
   leading / on file names. 

   @twiglet:apt-file-2.0.8 4Q> ./apt-file search 
/usr/share/perl5/Mail/SpamAssassin/Plugin/Razor2.pm
   spamassassin: /usr/share/perl5/Mail/SpamAssassin/Plugin/Razor2.pm
   @twiglet:apt-file-2.0.8 4Q> ./apt-file search -x 
/usr/share/perl5/Mail/SpamAssassin/Plugin/Razor2.pm
   spamassassin: /usr/share/perl5/Mail/SpamAssassin/Plugin/Razor2.pm
   @twiglet:apt-file-2.0.8 4Q>
   
   './apt-file list spamassassin' gives the same number files as 
   'dpkg -L spamassassin' 

#358821: apt-file: wrong result for apt-file list libsl0-heimdal

   @twiglet:apt-file-2.0.8 4Q> ./apt-file list libsl0-heimdal
   libsl0-heimdal: /usr/lib/libsl.so.0
   libsl0-heimdal: /usr/lib/libsl.so.0.1.