Bug#738880: apt-get uses globbing but reports regex for selecting packages + documentation issues

2014-02-13 Thread rpr nospam 
Package: apt
Version: 0.9.15
Severity: normal

Dear Maintainer, here is an example which demonstrates this bug:

$ sudo apt-get remove 'libre?f?ice.*'
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libreoffice.org-calc' for regex 'libre?f?ice.*'
Note, selecting 'libreoffice.org-writer' for regex 'libre?f?ice.*'
Package 'libreoffice.org-calc' is not installed, so not removed
Package 'libreoffice.org-writer' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.

$ apt-cache dump | grep -E 'libre?f?ice.*'
$ apt-cache dump | grep -F 'libreoffice.org-calc'
  Depends: libreoffice.org-calc (null)
Package: libreoffice.org-calc

The above commands show that the packages selected by apt-get
(libreoffice.org-calc and libreoffice.org-writer) didn't match
libre?f?ice.* regex.

Obviously, apt-get interprets libre?f?ice.* as a glob pattern. So,
instead of reporting
  Note, selecting 'libreoffice.org-writer' for regex 'libre?f?ice.*'
it should report
  Note, selecting 'libreoffice.org-writer' for glob 'libre?f?ice.*'

I came about this bug after experiencing the issue described on
https://lists.debian.org/debian-user/2014/02/msg00639.html

I'd say that the current apt-get manpage should be expanded and
clarified in regard to matching package names.

The last paragraph of the install command description reads:

  If no package matches the given expression and the expression
  contains one of '.', '?' or '*' then it is assumed to be a POSIX
  regular expression, and it is applied to all package names in the
  database. Any matches are then installed (or removed). Note that
  matching is done by substring so 'lo.*' matches 'how-lo' and
  'lowest'. If this is undesired, anchor the regular expression with
  a '^' or '$' character, or create a more specific regular
  expression.

That explanation has two issues:

(1) It should say that packages may be specified as glob patterns (see
glob(7)).

(2) If no package matches the given expression, it is assumed to be a
POSIX extended regular expression (see regex(7)). It IS NOT required
that the expression contains one of '.', '?' or '*'. Here is an
example:

$ sudo apt-get install '^vlc$'
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'vlc' for regex '^vlc$'
vlc is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.

Please improve the manpage so that it explains the pattern matching
accurately. It would prevent issues with regular expressions that can
be also valid glob expressions.

I've found that bug #475341 also reports on the issues in the apt-get
documentation. E.g. the possibility of appending a package name with a
hyphen (-), a plus sign (+) or an equal sign followed by the version
number is not explained in regard to globbing or regex.

The following examples show that each of these suffixes are stripped
off before matching package names:

$ sudo apt-get -s remove 'inx*+'
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'inxi' for regex 'inx*'
inxi is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.

$ sudo apt-get -s install '^vlc$-'
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'vlc' for regex '^vlc$'
The following packages will be REMOVED:
  browser-plugin-vlc vlc
0 upgraded, 0 newly installed, 2 to remove and 12 not upgraded.
Remv browser-plugin-vlc [2.0.6-2]
Remv vlc [2.1.2-2+b1]

$ sudo apt-get -s install '^vlc$=2.1.2-2+b1'
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'vlc' for regex '^vlc$'
vlc is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.

Please improve the manpage in this regard too.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^kfreebsd-image.*";
APT::NeverAutoRemove:: "^gnumach$";
APT::NeverAutoRemove:: "^gnumach-image.*";
APT::NeverAutoRemove:: "^linux-image-3.11-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3.11-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3.11-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3.11-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-3.11-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-3.12-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3.12-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3.12-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3.12-1-amd64$";

Bug#563382: gnome-control-center should depend on libcanberra-pulse

2013-07-28 Thread rpr nospam 
On Mon, 04 Jan 2010 Josselin Mouette  wrote:
>
> No, GNOME does not depend on pulseaudio, at least not in Debian.
> Introducing the dependency you suggest would make that a hard dependency
> so this is not going to happen.

Currently gnome-core both in stable (wheezy) and in testing (jessie)
depends on pulseaudio and libcanberra-pulse:
http://packages.debian.org/wheezy/gnome-core
http://packages.debian.org/jessie/gnome-core

So, I don't see a reason why gnome-control-center should not depend on
libcanberra-pulse.

Please, add this dependency as there are distributions based on Debian
which install gnome-control-center but not gnome-core which makes the
libcanberra-pulse package missing.

-- rpr.

Bug#656640: fixed in python-cups 1.9.62-1

2013-05-06 Thread rpr nospam 
On 25 Jan 2013 Laurent Bigonville  wrote:
>
> We believe that the bug you reported is fixed in the latest version of
> python-cups, which is due to be installed in the Debian FTP archive.

The following search
http://packages.debian.org/search?keywords=python-cups&searchon=names&suite=all
shows that python-cups 1.9.62-1 is currently available only in the
Debian experimental repository.

Does it mean that there are some problems with this version of python-cups?

-- rpr.

Bug#679877: catppt 0.94.3: Segmentation fault

2012-07-02 Thread rpr nospam 
Package: catdoc
Version: 0.94.3

On Ubuntu 12.04 64-bit I noticed that catppt 0.94.2-2 crashes while processing
https://docs.google.com/open?id=0B2V313X0LzmQeEVBUXVFQzFiWTQ
using the following command:
catppt -d utf-8 OSSEC-Presentation-mw.ppt

(BTW, OSSEC-Presentation-mw.ppt can be opened successfully in
MS PowerPoint 2003 and LibreOffice 3.5.)

I've downloaded the latest catdoc sources (0.94.3) and compiled them
on the same system but the problem is also present in that version.
You can find gdb output in the attachment.

-- rpr.
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/src/catdoc-0.94.3/src/catppt...done.
(gdb) run -d utf-8 "/home/rpr/Downloads/OSSEC HIDS/OSSEC-Presentation-mw.ppt"
Starting program: /usr/local/src/catdoc-0.94.3/src/catppt -d utf-8 
"/home/rpr/Downloads/OSSEC HIDS/OSSEC-Presentation-mw.ppt"

Program received signal SIGSEGV, Segmentation fault.
0x004037d3 in getlong (buffer=0x61a960 "\001", offset=55648)
at numutils.c:22
22  return (long)buffer[offset]|((long)buffer[offset+1]<<8L)
(gdb) backtrace full
#0  0x004037d3 in getlong (buffer=0x61a960 "\001", offset=55648)
at numutils.c:22
No locals.
#1  0x00403af9 in ole_readdir (f=) at ole.c:352
i = 
nLen = 
oleBuf = 
e = 0x61c780
chainMaxLen = 25
chainCurrent = 13912
#2  0x0040474e in ole_init (f=, buffer=, 
bufSize=) at ole.c:245
oleBuf = "\320\317\021\340\241\261\032\341", '\000' , 
">\000\003\000\376\377\t\000\006", '\000' , 
"m\000\000\000_6\000\000\000\000\000\000\000\020\000\000c6\000\000\001\000\000\000\376\377\377\377\000\000\000\000a6\000\000\004\000\000\000\005\000\000\000\006\000\000\000\a\000\000\000\b\000\000\000\t\000\000\000\n\000\000\000\v\000\000\000\f\000\000\000\003\000\000\000\330\004\000\000\331\004\000\000\332\004\000\000\333\004\000\000\334\004\000\000\335\004\000\000\336\004\000\000\337\004\000\000\340\004\000\000\254\t\000\000\255\t\000\000\256\t\000\000\257\t\000\000\260\t\000\000\261\t\000\000\262\t\000\000\263\t\000\000\264\t\000\000\177\016\000\000\200\016\000\000\201\016\000\000\202\016\000\000\203\016\000\000\204\016\000\000\205\016\000\000\206\016\000\000\207\016\000\000\210\016\000\000S\023\000\000T\023\000\000U\023\000\000V"...
tmpBuf = 
newfile = 0x608890
ret = 
i = 
sbdMaxLen = 
sbdCurrent = 
propMaxLen = 5
propCurrent = 4294967294
mblock = 
msat_size = 
tEntry = 
#3  0x0040169d in main (argc=4, argv=) at catppt.c:137
input = 
new_file = 
ole_file = 
filename = 0x7fffe469 "/home/rpr/Downloads/OSSEC 
HIDS/OSSEC-Presentation-mw.ppt"
tmp_charset = 
c = 
tempname = 
(gdb) info registers
rax0x0  0
rbx0x61c780 6408064
rcx0x4000   16384
rdx0x77dd3720   140737351857952
rsi0xd960   55648
rdi0x61a960 6400352
rbp0x3658   0x3658
rsp0x7fffdd88   0x7fffdd88
r8 0x3  3
r9 0x4000   16384
r100x0  0
r110x3  3
r120x19 25
r130x1  1
r140x6d 109
r150x0  0
rip0x4037d3 0x4037d3 
eflags 0x10206  [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0
(gdb) x/16i $pc
=> 0x4037d3 :movzbl 0x1(%rdi,%rsi,1),%eax
   0x4037d8 :movzbl 0x2(%rdi,%rsi,1),%edx
   0x4037dd :   shl$0x8,%rax
   0x4037e1 :   shl$0x10,%rdx
   0x4037e5 :   or %rdx,%rax
   0x4037e8 :   movzbl (%rdi,%rsi,1),%edx
   0x4037ec :   or %rdx,%rax
   0x4037ef :   movzbl 0x3(%rdi,%rsi,1),%edx
   0x4037f4 :   shl$0x18,%rdx
   0x4037f8 :   or %rdx,%rax
   0x4037fb :   retq   
   0x4037fc:nopl   0x0(%rax)
   0x403800 : movslq %esi,%rsi
   0x403803 :   movzbl 0x1(%rdi,%rsi,1),%eax
   0x403808 :   movzbl 0x2(%rdi,%rsi,1),%edx
   0x40380d :  shl$0x8,%rax
(gdb) thread apply all backtrace

Thread 1 (process 27403):
#0  0x004037d3 in getlong (buffer=0x61a960 "\001", offset=55648)
at numutils.c:22
#1  0x00403af9 in ole_readdir (f=) at ole.c:352
#2  0x0040474e in ole_init (f=, buffer=, 
bufSize=) at ole.c:245
#3  0x0040169d in main (argc=4, argv=) at ca