Bug#1005047: pipewire daemon starting even in non-graphical sessions
Package: pipewire Version: 0.3.44-1 Severity: minor (I am running pipewire from Bookworm re-compiled for Bullseye, but I am confident that the problem occurs in plain Bookworm, too.) Is it intentional that the systemd user services for pipewire and pipewire-pulse (and the related socket services) are WantedBy default.target? This causes them to be started even for users logged in via SSH. I would expect WantedBy graphical-session.target instead. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pipewire depends on: ii init-system-helpers 1.60 ii libpipewire-0.3-modules 0.3.44-1~ucw11+1 ii pipewire-bin 0.3.44-1~ucw11+1 pipewire recommends no packages. pipewire suggests no packages. -- no debconf information
Bug#1002830: mailman3: Wrong error message when permissions are wrong
Package: mailman3 Version: 3.3.3-1 Severity: minor Hello! I was receiving mysterious messages from the out runner: Cannot connect to SMTP server 127.0.0.1 on port 25 even though the SMTP server was running fine. It turned out that the cause of the failure is wrong permissions on the template file: /var/lib/mailman3/templates/lists/test-l.example.org/en/list:member:regular:footer.txt Could somebody please fix the misleading message? -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages mailman3 depends on: ii dbconfig-pgsql 2.0.19 ii debconf [debconf-2.0]1.5.77 ii init-system-helpers 1.60 ii logrotate3.18.0-2 ii lsb-base 11.1.0 ii python3 3.9.2-3 ii python3-aiosmtpd 1.2.2-1 ii python3-alembic 1.4.3-1 ii python3-authheaders 0.13.1-1 ii python3-authres 1.2.0-2 ii python3-click7.1.2-1 ii python3-dateutil 2.8.1-6 ii python3-dnspython2.0.0-1 ii python3-falcon 2.0.0-2+b1 ii python3-flufl.bounce 3.0.1-1 ii python3-flufl.i18n 3.0.1-1 ii python3-flufl.lock 5.0.1-1 ii python3-gunicorn 20.1.0-1 ii python3-importlib-resources 5.1.0-1 ii python3-lazr.config 2.2.3-1 ii python3-passlib 1.7.4-1 ii python3-psycopg2 2.8.6-2 ii python3-public 0.5-1.1 ii python3-requests 2.25.1+dfsg-2 ii python3-sqlalchemy 1.3.22+ds1-1 ii python3-zope.component 4.3.0-3 ii python3-zope.configuration 4.4.0-1 ii python3-zope.event 4.4-3 ii python3-zope.interface 5.2.0-1 ii ucf 3.0043 Versions of packages mailman3 recommends: ii postfix [mail-transport-agent] 3.5.6-1+b1 Versions of packages mailman3 suggests: ii elinks [www-browser]0.13.2-1+b1 ii links2 [www-browser]2.21-1+b1 ii lynx [www-browser] 2.9.0dev.6-3~deb11u1 ii mailman3-doc3.3.3-1 ii mariadb-server-10.5 [virtual-mysql-server] 1:10.5.12-0+deb11u1 ii w3m [www-browser] 0.5.3+git20210102-6 -- debconf information: mailman3/install-error: abort mailman3/pgsql/authmethod-admin: ident mailman3/db/app-user: mailman3@localhost mailman3/remote/port: mailman3/pgsql/method: TCP/IP mailman3/db/dbname: mailman3 mailman3/upgrade-backup: true mailman3/missing-db-package-error: abort * mailman3/remote/host: localhost mailman3/pgsql/authmethod-user: password mailman3/internal/reconfiguring: false mailman3/pgsql/no-empty-passwords: mailman3/remote/newhost: localhost mailman3/mysql/method: Unix socket mailman3/pgsql/changeconf: false * mailman3/dbconfig-install: true mailman3/pgsql/admin-user: postgres mailman3/dbconfig-reinstall: false mailman3/upgrade-error: abort mailman3/dbconfig-remove: true mailman3/purge: false mailman3/pgsql/manualconf: mailman3/mysql/authplugin: default * mailman3/database-type: pgsql mailman3/remove-error: abort mailman3/db/basepath: /var/lib/mailman3/data mailman3/init_service_failed: mailman3/mysql/admin-user: mailman3/dbconfig-upgrade: true mailman3/config_hyperkitty: mailman3/passwords-do-not-match: mailman3/internal/skip-preseed: false
Bug#989938: mupdf: Wrapper script interferes with SIGHUP
Package: mupdf Version: 1.14.0+ds1-4+deb10u2 Severity: normal The man page of mupdf documents that we can send SIGHUP to mupdf to make it reload the file. However, this is broken by the wrapper script provided by Debian: when the script receives a SIGHUP, it terminates instead of forwarding the SIGHUP to the mupdf binary. -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mupdf depends on: ii libc62.28-10 ii libfreetype6 2.9.1-3+deb10u2 ii libharfbuzz0b2.3.1-1 ii libjbig2dec0 0.16-1 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii libopenjp2-7 2.3.0-2+deb10u2 ii libx11-6 2:1.6.7-1+deb10u2 ii libxext6 2:1.3.3-1+b2 ii zlib1g 1:1.2.11.dfsg-1 mupdf recommends no packages. Versions of packages mupdf suggests: ii mupdf-tools 1.14.0+ds1-4+deb10u2 -- no debconf information
Bug#977815: texlive-binaries: man pdftex is missing -synctex option
Package: texlive-binaries Version: 2018.20181218.49446-1 Severity: minor Hello! I noticed that the pdftex man page is missing the "-synctex" option, even though this option is described in "pdftex --help". -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-binaries depends on: ii dpkg 1.19.7 ii install-info 6.5.0.dfsg.1-4+b1 ii libbrotli11.0.7-2+deb10u1 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3+deb10u2 ii libgcc1 1:8.3.0-6 ii libgmp10 2:6.1.2+dfsg-4 ii libgraphite2-31.3.13-7 ii libgs99.27~dfsg-2+deb10u4 ii libharfbuzz-icu0 2.3.1-1 ii libharfbuzz0b 2.3.1-1 ii libice6 2:1.0.9-2 ii libicu63 63.1-6+deb10u1 ii libkpathsea6 2018.20181218.49446-1 ii libmpfr6 4.0.2-1 ii libpaper1 1.1.28 ii libpixman-1-0 0.36.0-1 ii libpng16-16 1.6.36-6 ii libpotrace0 1.15-1 ii libptexenc1 2018.20181218.49446-1 ii libsm62:1.2.3-1 ii libstdc++68.3.0-6 ii libsynctex2 2018.20181218.49446-1 ii libteckit02.5.8+ds2-5 ii libtexlua52 2018.20181218.49446-1 ii libtexlua53 2018.20181218.49446-1 ii libtexluajit2 2018.20181218.49446-1 ii libwoff1 1.0.2-1 ii libx11-6 2:1.6.7-1+deb10u1 ii libxaw7 2:1.0.13-1+b2 ii libxext6 2:1.3.3-1+b2 ii libxi62:1.7.9-1 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii libxt61:1.1.5-1+b3 ii libxxhash00.6.5-2 ii libzzip-0-13 0.13.62-3.2 ii perl 5.28.1-6+deb10u1 ii t1utils 1.41-3 ii tex-common6.11 ii zlib1g1:1.2.11.dfsg-1 Versions of packages texlive-binaries recommends: ii texlive-base 2018.20190227-2 texlive-binaries suggests no packages. -- debconf-show failed
Bug#960916: cups-daemon: cuspd fails to detect local host name
Package: cups-daemon Version: 2.2.10-6+deb10u3 Severity: normal Apparantly, there is something fishy in cups around server host names. I found several issues: (1) When the client is configured to connect to the server using a host name unknown to the server (the name is sent in the "Host:" header), the server responds with status code 400 (Bad Request). By the HTTP standard, this is the correct response if the Host header is missing, present multiple times, or malformed. But I seriously doubt that 400 applies when the Host header matches no host name of the server. (2) If lpstat (and probably other clients, too) receives the status code 400, it gives a misleading error message "Error - add '/version=1.1' to server name". Adding that does not help the above issue and the message is given even if the version string is already present. ... let's move on to why the server's opinion on its own host name is wrong: (3) cupsd uses gethostname() to get the host name. By Debian Reference, section 3.2.1 (https://www.debian.org/doc/manuals/debian-reference/ch03.en.html#_the_hostname), this should be only the system hostname, not a FQDN. Still, cupsd boldly compares this to the value in the Host header, which usually is a FQDN. (4) cupsd is willing to use gethostbyname() to obtain additional host aliases from /etc/hosts, but only if the HostNameLookups switch is on. This does not match the documentation (both the man page and https://www.cups.org/doc/man-cupsd.conf.html), which explicitly tells that HostNameLookups affects only reverse lookups of connecting clients. (5) cupsd also matches the Host header against the list of network interfaces (function valid_host() in scheduler/client.c) in the NetIFList. However, the function cupsdNetIFUpdate (scheduler/network.c) which populates this list seems to be never called, at least in the default configuration. Also, local IP addresses of interfaces are resolved to host names only if HostNameLookups is turned on. (6) HostNameLookups is not turned on in default configuration, so cupsd knows only the unqualified hostname. (Still, it's probably a good idea to have it turned off since resolving all client IPs slows the server down. It is really unfortunate that HostNameLookups controls two unrelated things.) All this put together, cupsd in Debian Buster works with non-local clients only if they refer to the server by its unqualified hostname. If they want to use the FQDN, cupsd configuration must include either HostNameLookups or explicit ServerName/ServerAlias with the FQDN. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-daemon depends on: ii adduser 3.118 ii bc1.07.1-2+b1 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libc6 2.28-10 ii libcups2 2.2.10-6+deb10u3 ii libdbus-1-3 1.12.16-1 ii libgssapi-krb5-2 1.17-3 ii libpam0g 1.3.1-5 ii libpaper1 1.1.28 ii libsystemd0 241-7~deb10u4 ii lsb-base 10.2019051400 ii procps2:3.3.15-2 ii ssl-cert 1.0.39 Versions of packages cups-daemon recommends: ii avahi-daemon 0.7-4+b1 ii colord1.4.3-4 ii cups-browsed 1.21.6-5 Versions of packages cups-daemon suggests: ii cups 2.2.10-6+deb10u3 ii cups-bsd 2.2.10-6+deb10u3 ii cups-client 2.2.10-6+deb10u3 ii cups-common 2.2.10-6+deb10u3 ii cups-filters [foomatic-filters] 1.21.6-5 pn cups-pdf ii cups-ppdc2.2.10-6+deb10u3 ii cups-server-common 2.2.10-6+deb10u3 ii foomatic-db 20181217-2 ii ghostscript 9.27~dfsg-2+deb10u3 pn hplip ii poppler-utils0.71.0-5 pn printer-driver-gutenprint pn printer-driver-hpcups ii smbclient2:4.9.5+dfsg-5+deb10u1 ii udev 241-7~deb10u4 -- no debconf information
Bug#958060: mdadm segfaults when run from cron.daily
Package: mdadm
Version: 4.1-1
Severity: normal
Tags: patch upstream
Dear maintainers,
when mdadm is run from /etc/cron.daily/mdadm on one of my machines, it
deterministically segfaults.
The cron job runs:
mdadm --monitor --scan --oneshot
Surprisingly, when I run the same command from a normal root shell, it
finishes correctly. Strace reveals that the difference is that in the first
case, it is run with cwd set to "/", while in the second case cwd is "/root".
And in "/", I have a directory "big", which is also the name of one of my
arrays :) But why is mdadm looking this up in the current directory?
The culprit is the following piece of code in Monitor.c in function Monitor():
if (mdlist->devname[0] == '/')
st->devname = xstrdup(mdlist->devname);
else {
st->devname = xmalloc(8+strlen(mdlist->devname)+1);
strcpy(strcpy(st->devname, "/dev/md/"),
mdlist->devname);
}
In my case, the first character of mdlist->devname[0] is not '/', so the
else branch is executed ... which copies "/dev/md" to st->devname and happily
overwrites it with mdlist->devname in a moment. Apparently, the outer strcpy
was meant to be a strcat. (This is fixed by the attached patch.)
However, this solves only one part of the puzzle. Even if mdadm accesses the
wrong name, it should not be a reason for a crash. It crashes on a NULL pointer
dereference in Monitor.c, function check_array():
fd = open(dev, O_RDONLY);
if (fd < 0)
goto disappeared;
if (st->devnm[0] == 0)
strcpy(st->devnm, fd2devnm(fd));
Here, open() succeeds on "big", so we call fd2devnm(fd) in lib.c:
char *fd2devnm(int fd)
{
struct stat stb;
if (fstat(fd, ) == 0)
return stat2devnm();
return NULL;
}
Of course fstat succeeds, so we go here:
char *stat2devnm(struct stat *st)
{
if ((S_IFMT & st->st_mode) != S_IFBLK)
return NULL;
return devid2devnm(st->st_rdev);
}
However "fd" refers to a directory, not to a block device, so we return NULL
to strcpy(). This is a separate bug which would also deserves fixing (at least
by a printing an error message instead of crash), even it is unlikely to be
triggered when the first bug is fixed. (However, it can be triggered for example
by running the command while another instance of mdadm is stopping the array.)
-- Package-specific info:
I believe that the details of arrays are not relevant.
-- System Information:
Debian Release: 10.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages mdadm depends on:
ii debconf [debconf-2.0] 1.5.71
ii libc6 2.28-10
ii lsb-base 10.2019051400
ii udev 241-7~deb10u3
Versions of packages mdadm recommends:
ii kmod26-1
ii postfix [mail-transport-agent] 3.4.8-0+10debu1
Versions of packages mdadm suggests:
pn dracut-core
-- debconf information:
mdadm/start_daemon: true
mdadm/initrdstart_notinconf: false
mdadm/initrdstart_msg_errconf:
mdadm/initrdstart_msg_intro:
mdadm/initrdstart_msg_errmd:
mdadm/mail_to: root
* mdadm/initrdstart: all
mdadm/initrdstart_msg_errexist:
mdadm/autostart: true
mdadm/autocheck: true
mdadm/initrdstart_msg_errblock:
diff -ruN mdadm-4.1.orig/Monitor.c mdadm-4.1/Monitor.c
--- mdadm-4.1.orig/Monitor.c2018-10-01 20:26:06.0 +0200
+++ mdadm-4.1/Monitor.c 2020-04-18 00:08:26.342858997 +0200
@@ -176,7 +176,7 @@
st->devname = xstrdup(mdlist->devname);
else {
st->devname =
xmalloc(8+strlen(mdlist->devname)+1);
- strcpy(strcpy(st->devname, "/dev/md/"),
+ strcat(strcpy(st->devname, "/dev/md/"),
mdlist->devname);
}
st->next = statelist;
Bug#950921: monitoring-plugins-basic: check_by_ssh does not kill ssh on timeout
Package: monitoring-plugins-basic Version: 2.2-6 Severity: normal When check_by_ssh times out, the ssh process still keeps running. This is already fixed in upstream commit 7cafb0e84550035fe671662c293122be975065ca. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages monitoring-plugins-basic depends on: ii iputils-ping 3:20180629-2 ii libc6 2.28-10 ii libssl1.1 1.1.1d-0+deb10u2 ii monitoring-plugins-common 2.2-6 ii procps 2:3.3.15-2 ii ucf3.0038+nmu1 Versions of packages monitoring-plugins-basic recommends: ii libcap2-bin 1:2.25-2 Versions of packages monitoring-plugins-basic suggests: pn icinga | icinga2 -- no debconf information
Bug#949315: cups-filters: driverless generates wrong InputSlots
Package: cups-filters Version: 1.21.6-5 Severity: important When I use "driverless" to generate a PPD for my Xerox B215 printer, I get definition of InputSlot which does not work. In particular, the printer reports that it supports media source "tray-1". This is translated to "Tray-1" by driverless, so the PPD contains: *InputSlot Tray-1/Tray 1: "" When I submit a print job, CUPS's IPP backend translates this to IPP media source "tray--1", which is later rejected by the printer (the printer replies by a malformed IPP message, but that's another story). The problem lies in the mismatch between name mangling rules in cups-filters-1.21.6/cupsfilters/ppdgenerator.c (the pwg_ppdize_name function) and cups-2.2.10/cups/ppd-cache.c (the pwg_unppdize_name function). It is hard to tell which one is wrong as the name mangling rules seem arbitrary. However, at least one of them needs fixing. I checked cups-filters 1.26.2 and CUPS 2.3.1 and the name mangling functions stay the same, so the problem is probably still present. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-filters depends on: ii bc 1.07.1-2+b1 ii cups-filters-core-drivers 1.21.6-5 ii ghostscript9.27~dfsg-2+deb10u3 ii libc6 2.28-10 ii libcups2 2.2.10-6+deb10u1 ii libcupsfilters11.21.6-5 ii libcupsimage2 2.2.10-6+deb10u1 ii libfontconfig1 2.13.1-2 ii libfontembed1 1.21.6-5 ii libgcc11:8.3.0-6 ii libqpdf21 8.4.0-2 ii libstdc++6 8.3.0-6 ii poppler-utils 0.71.0-5 Versions of packages cups-filters recommends: ii colord 1.4.3-4 ii liblouisutdml-bin 2.7.0-5+b1 Versions of packages cups-filters suggests: ii antiword 0.37-14 pn docx2txt ii foomatic-db 20181217-2 ii imagemagick 8:6.9.10.23+dfsg-2.1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1 -- Configuration Files: /etc/modules-load.d/cups-filters.conf changed [not included] -- no debconf information
Bug#915632: gitweb: local configuration not found
Package: git Version: 1:2.19.2-1~bpo9+1 Severity: normal Hello, world!\n After upgrade to Stretch, gitweb no longer finds the configuration file "gitweb_config.perl" in the current directory. However, "man gitweb" still mentions this as one of the possible locations of the config file (and indeed a useful one when using multiple instances of gitweb). It was probably broken by Perl dropping "." from the default search path for security reasons. I tried git-2.19.2 from stretch-backports with the same result. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git depends on: ii dpkg 1.18.25 ii git-man 1:2.19.2-1~bpo9+1 ii libc62.24-11+deb9u3 ii libcurl3-gnutls 7.52.1-5+deb9u8 ii liberror-perl0.17024-1 ii libexpat12.2.0-2+deb9u1 ii libpcre2-8-0 10.22-3 ii perl 5.24.1-3+deb9u5 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages git recommends: ii less 481-2.1 ii openssh-client [ssh-client] 1:7.4p1-10+deb9u4 ii patch2.7.5-1+deb9u1 Versions of packages git suggests: ii gettext-base 0.19.8.1-2 pn git-cvs pn git-daemon-run | git-daemon-sysvinit pn git-doc pn git-el pn git-email pn git-gui pn git-mediawiki pn git-svn ii gitk 1:2.19.2-1~bpo9+1 pn gitweb -- no debconf information
Bug#893966: pciutils: Consider removing pcimodules
Package: pciutils Version: 1:3.5.2-1 Severity: minor Debian pciutils package includes the pcimodules program, which was never a part of the upstream package and which was obsoleted years ago by both udev and 'lspci -k'. I think the time has come to remove it. -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pciutils depends on: ii libc6 2.24-11+deb9u1 ii libkmod2 23-2 ii libpci3 1:3.5.2-1 pciutils recommends no packages. Versions of packages pciutils suggests: ii bzip2 1.0.6-8.1 ii curl 7.52.1-5+deb9u4 ii lynx-cur 2.8.9dev11-1 ii wget 1.18-5+deb9u1 -- no debconf information
Bug#893965: pciutils: Obsolete Homepage in debian/control
Package: pciutils Version: 1:3.5.2-1 Severity: minor The Homepage field in debian/control lists a long obsolete homepage. Please update it to http://mj.ucw.cz/sw/pciutils/, where the old page redirects anyway. -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pciutils depends on: ii libc6 2.24-11+deb9u1 ii libkmod2 23-2 ii libpci3 1:3.5.2-1 pciutils recommends no packages. Versions of packages pciutils suggests: ii bzip2 1.0.6-8.1 ii curl 7.52.1-5+deb9u4 ii lynx-cur 2.8.9dev11-1 ii wget 1.18-5+deb9u1 -- no debconf information
Bug#887424: texlive-plain-extra: autopict.sty is broken
> This is surprising, because the file wasn't changed since 2009 and > Jessie was released in 2015 ... texlive-plain-extra 2014.20141024-1 from Jessie contains a version with timestamp from 2009. texlive-plain-extra 2016.20170123-5 from Stretch contains a version dated 2016, which is broken.
Bug#887424: texlive-plain-extra: autopict.sty is broken
Sorry for the confusion. It is broken in Stretch, the version in Jessie works. I will produce a minimal example for Asymptote soon.
Bug#887424: texlive-plain-extra: autopict.sty is broken
Package: texlive-plain-extra Version: 2016.20170123-5 Severity: normal Hello! The package graphics-pln is broken in Debian Jessie. The cuplrit is that the autopict.sty file (generated from ltpictur.dtx during package build) contains only comments and \endinput and lacks the definitions of essential macros like \pictur@. As Asymptote depends on graphics-pln when using plain TeX, some Asymptote pictures cannot be compiled any longer. Replacing autopict.sty with the version present in Jessie solves the problem. This package was replaced by texlive-plain-generic in unstable, but the file is broken there, too. -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files -rw-r--r-- 1 mj users 1273 Apr 13 2007 /home/mj/texmf/ls-R -rw-r--r-- 1 root root 3475 Jan 13 22:24 /var/lib/texmf/ls-R -rw-rw-r-- 1 root staff 80 Jan 3 2016 /usr/local/share/texmf/ls-R lrwxrwxrwx 1 root root 29 Jan 17 2017 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Mar 4 2017 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Mar 4 2017 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 838 Jan 13 21:52 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Mar 4 2017 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN lrwxrwxrwx 1 root root 32 Mar 4 2017 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 3287 Jan 13 21:56 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Jun 18 2012 mktex.cnf -rw-r--r-- 1 root root 838 Jan 13 21:52 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf 1df66bc319cec731e202eaf39f5d85e1 /etc/texmf/texmf.d/96JadeTeX.cnf -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-plain-extra depends on: ii tex-common6.06 ii texlive-base 2016.20170123-5 texlive-plain-extra recommends no packages. texlive-plain-extra suggests no packages. Versions of packages tex-common depends on: ii dpkg 1.18.24 ii ucf 3.0036 Versions of packages tex-common suggests: ii debhelper 10.2.5 Versions of packages texlive-plain-extra is related to: ii tex-common6.06 ii texlive-binaries 2016.20160513.41080.dfsg-2 -- debconf information: tex-common/check_texmf_missing: tex-common/check_texmf_wrong:
Bug#850681: netpbm: anytopnm returns wrong exit code
Package: netpbm Version: 2:10.0-15.2 Severity: normal When anytopnm delegates its work to a conversion program (*topnm) and this program fails, anytopnm still returns success. This confuses other programs, for example asciiview (from the aview package). -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.39-kam (SMP w/16 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages netpbm depends on: ii libc62.19-18+deb8u6 ii libjpeg62-turbo 1:1.3.1-12 ii libnetpbm10 2:10.0-15.2 ii libpng12-0 1.2.50-2+deb8u2 ii libtiff5 4.0.3-12.3+deb8u1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages netpbm recommends: ii ghostscript 9.06~dfsg-2+deb8u4 netpbm suggests no packages. -- no debconf information
Bug#850680: netpbm: anytopnm fails on JPEGs with Exif data
Package: netpbm Version: 2:10.0-15.2 Severity: normal When I run anytopnm on a JPEG image with Exif data, it fails with: > /tmp/anytopnm.wWyz74jE6o/atn.stdin: Not a TIFF or MDI file, bad magic number > 1 (0xd8ff). > tifftopnm: error opening TIFF file /tmp/anytopnm.wWyz74jE6o/atn.stdin The cause is that anytopnm runs "file" first to determine the type of the image, which results in: > JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=7, > orientation=upper-left, xresolution=98, yresolution=106, resolutionunit=2, > software=Adobe Photoshop CS5 Windows, datetime=2011:08:06 22:42:46], baseline, > precision 8, 900x656, frames 3 Then it uses a huge "case" to match known patterns on this string, which catches "TIFF" before "JPEG". So it runs tifftopnm, which gives up. Running jpegtopnm instead would work. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.39-kam (SMP w/16 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages netpbm depends on: ii libc62.19-18+deb8u6 ii libjpeg62-turbo 1:1.3.1-12 ii libnetpbm10 2:10.0-15.2 ii libpng12-0 1.2.50-2+deb8u2 ii libtiff5 4.0.3-12.3+deb8u1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages netpbm recommends: ii ghostscript 9.06~dfsg-2+deb8u4 netpbm suggests no packages. -- no debconf information
Bug#829203: libpaper1: Wrong size of C4 paper
Package: libpaper1 Version: 1.1.24+nmu4 Severity: normal Hello! I noticed that the dimensions of the C4 paper are reported by 'paperconf -whm c4' as '229 mm 354 mm', but the correct values are '229 mm 324 mm'. The other ISO Cn formats are correct. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-kam (SMP w/8 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages libpaper1 depends on: ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.27 ii libc6 2.19-18+deb8u4 ii multiarch-support 2.19-18+deb8u4 ii ucf3.0030 Versions of packages libpaper1 recommends: ii libpaper-utils 1.1.24+nmu4 libpaper1 suggests no packages. -- debconf information: libpaper/defaultpaper: a4
Bug#819314: procps: [sysctl] Missing dependency when used with systemd
Hello! > Are you sure? > networking.service has > > After=local-fs.target network-pre.target apparmor.service > > systemd-sysctl.service > > This makes sure that networking.service, which deals with type auto > interfaces, is started after systemd-sysctl.service. On my system (Wheezy recently upgraded to Jessie): | ● networking.service - LSB: Raise network interfaces. |Loaded: loaded (/etc/init.d/networking) | Drop-In: /run/systemd/generator/networking.service.d |└─50-insserv.conf-$network.conf | /lib/systemd/system/networking.service.d |└─network-pre.conf |Active: active (exited) since Sun 2016-03-20 21:56:51 CET; 1 weeks 3 days ago /run/systemd/generator/networking.service.d/50-insserv.conf-$network.conf contains only: | # Automatically generated by systemd-insserv-generator | | [Unit] | Wants=network.target | Before=network.target /lib/systemd/system/networking.service.d/network-pre.conf contains only: | [Unit] | After=network-pre.target No trace of systemd-sysctl.service anywhere. > And for hotplugged devices > > /lib/udev/rules.d/99-systemd.rules contains > > 99-systemd.rules:# Apply sysctl variables to network devices (and only to > > those) as they appear. > > 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", > > RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name > > --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name > > --prefix=/net/ipv6/neigh/$name" This works for per-interface options, but not for /net/ipv6/conf/default. (However, I probably should abandon using conf/default anyway, since some kernel modules are loaded before sysctl is set.) Martin
Bug#805445: More data points
Hello! I think I have a couple of data points more for this bug. First of all, disabling ipv6.conf.(all|default).accept_ra in /etc/sysctl.conf does not work reliably for three reasons: (1) With systemd, there is no dependency between sysctl and networking, so there is a race condition. I just reported it as bug for procps (sorry, no bug number yet). (2) conf.all.accept_ra seems to be ignored by the kernel (actually, conf.all works only with a couple of options like forwarding). (3) conf.default.accept_ra does not help if the interface already exists when systemd-sysctl.service runs. Second, if /etc/network/interfaces specifies both IPv6 and IPv6 addresses, the interface is already up when ifup sets conf.$IFACE.accept_ra=0. Hence there is a small time window when the RA can be accepted. Yes, our router is sometimes fast enough to hit it ;) I wonder what is the right solution... I see these possibilities: (a) We could make ifup set accept_ra before it tries to up the interface for the first time. (b) ifup could explicitly flush routes with proto=ra before setting up the default route. (c) The kernel could drop such routes when accept_ra is turned off. Martin
Bug#819314: procps: [sysctl] Missing dependency when used with systemd
Package: procps Version: 2:3.3.9-9 Severity: normal With sysvinit, the init script for procps ensures that sysctl's are set before networking is started (via X-Start-Before: $network). When run with systemd, procps.service does not have such dependency. Since system startup is highly parallel, there is a race condition: sometimes network interfaces are initialized before net.ipv6.conf.default.* is set. If the new behavior is considered better for some reason, at least the difference should be clearly documented. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.16-kam (SMP w/8 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages procps depends on: ii initscripts 2.88dsf-59 ii libc6 2.19-18+deb8u3 ii libncurses5 5.9+20140913-1+b1 ii libncursesw5 5.9+20140913-1+b1 ii libprocps32:3.3.9-9 ii libtinfo5 5.9+20140913-1+b1 ii lsb-base 4.1+Debian13+nmu1 Versions of packages procps recommends: ii psmisc 22.21-2 procps suggests no packages. -- no debconf information
Bug#778997: pciutils: lspci -nn freezes
Hello! I suspect a kernel bug since the reboot froze (I had to press the power button) and lspci -nn is now working. I suspect either a kernel bug or a hardware bug. Reading the first 64 bytes of configuration space (which is what lspci does and the strace confirms that) should not lock up the process. If I understand correctly, it froze for: 0f:00.0 VGA compatible controller [0300]: NVIDIA Corporation G98 [Quadro NVS 295] [10de:06fd] (rev a1) Yes. Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721088: initramfs-tools: nfsroot with pxelinux fails on systems with multiple NICs
Package: initramfs-tools Version: 0.109.1 Severity: normal When I try to use Debian initramfs to mount root over NFS on a machine with multiple NICs, it never succeeds, because the initramfs configures all NICs with the same IP address. In more detail, the following happens: o I have configured pxelinux to boot Linux kernel and set ipappend 3, so that pxelinux appends ip= and BOOTIF= to kernel options. The former contains the IP address and netmask (but no information on the interface, which is logical, because it has no idea how will the kernel name the interface). The latter contains the MAC address of the boot interface. o configure_networking() in scripts/functions inside the initramfs correctly detects that BOOTIF was passed and sets the DEVICE variable to the name of the right network device. o Later, configure_networking() detects that the ip parameter contains something complex (different from trivial things like any, off, dhcp, ...) and runs ipconfig on all interfaces. o Therefore, the DEVICE variable calculated from BOOTIF is not used at all. A simple work-around exists: let pxelinux pass only the BOOTIF parameter (ipappend 2) and add ip=dhcp manually, in which case configure_networking() behaves correctly and runs ipconfig only on the matching interface. However, (1) this is unnecessarily slow (DHCP is run twice, once in PXE and then in the initramfs), (2) one should not need such tricks to get a working nfsroot. I propose the following fix: In the complex ip parameter case (around line 393 in my version of the scripts/functions file), the DEVICE variable should be checked and if it already set, ipconfig should be run only on the selected device. Also, the NEW_DEVICE logic below that call to ipconfig is likely wrong for the same reason. I think it should be moved to the same place where the BOOTIF check resides. If you wish, I can provide a patch. -- Package-specific info: -- initramfs sizes -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.9.2-kam root=UUID=9a1f02a6-70f0-4958-821a-b603696c6d2d ro -- /proc/filesystems ext3 ext2 ext4 vfat msdos iso9660 romfs udf -- lsmod Module Size Used by usblp 9474 0 tun15607 2 deflate 1775 0 zlib_deflate 17451 1 deflate ctr 3415 0 twofish_generic 6017 0 twofish_x86_64_3way18587 0 twofish_x86_64 5221 1 twofish_x86_64_3way twofish_common 12753 3 twofish_generic,twofish_x86_64_3way,twofish_x86_64 camellia_generic 18041 0 camellia_x86_6443873 0 serpent_sse2_x86_6444621 0 serpent_generic18028 1 serpent_sse2_x86_64 xts 2687 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way lrw 3069 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way gf128mul5138 2 lrw,xts glue_helper 3105 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way blowfish_generic3032 0 blowfish_x86_6413244 0 blowfish_common 6159 2 blowfish_generic,blowfish_x86_64 cast5_generic 10293 0 cast_common 4849 1 cast5_generic ablk_helper 1556 1 serpent_sse2_x86_64 cryptd 6479 1 ablk_helper xcbc2269 0 rmd160 7160 0 sha512_generic 4553 0 sha256_generic 9509 0 sha1_generic1822 0 crypto_null 2468 0 af_key 22195 0 xfrm_algo 4208 1 af_key ip6t_REJECT 2428 3 xt_nat 1777 6 ipt_REJECT 2009 2 xt_LOG 9702 5 xt_limit1678 7 xt_state1151 3 xt_multiport1566 2 xt_DSCP 2003 2 xt_owner1107 3 xt_mark 1133 8 xt_connmark 1653 2 ip6table_filter 1284 1 ip6_tables 13824 1 ip6table_filter iptable_mangle 1424 1 iptable_nat 2382 1 nf_conntrack_ipv4 6526 6 nf_defrag_ipv4 1259 1 nf_conntrack_ipv4 nf_nat_ipv4 2992 1 iptable_nat nf_nat 11007 3 nf_nat_ipv4,xt_nat,iptable_nat nf_conntrack 50975 6 nf_nat,xt_state,nf_nat_ipv4,xt_connmark,iptable_nat,nf_conntrack_ipv4 iptable_filter 1312 1 ip_tables 13378 3 iptable_filter,iptable_mangle,iptable_nat x_tables 13511 16 ip6table_filter,xt_DSCP,xt_mark,ip_tables,xt_limit,xt_owner,xt_state,xt_LOG,xt_nat,xt_multiport,iptable_filter,xt_connmark,ipt_REJECT,iptable_mangle,ip6_tables,ip6t_REJECT acpi_cpufreq6294 1 mperf 1107 1 acpi_cpufreq snd_hda_codec_hdmi 24489 1 kvm_amd43896 0 snd_hda_codec_realtek26712 1 kvm
Bug#691247: mime-support: Useless permission checks in see
Package: mime-support Version: 3.52-1 Severity: normal When I run `see' on a file, I get `Error: no read permission for file XXX', although the file is perfectly readable. This happens for example when the file in question is located in a directory mounted by sshfs. Permissions reported by stat(2) on such files usually follow the remote server, which does not necessarily make any sense when interpreted locally. But this is exactly what `see' does: it stats the filesystem permissions and and dies when it guesses that the file looks unreadable. This can fail under lots of circumstances: not only sshfs, but also permissions granted by an ACL. I recommended removing the check altogether or at least replacing it by trying to open the file. -- System Information: Debian Release: wheezy/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.2-kamdesktop (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash mime-support depends on no packages. Versions of packages mime-support recommends: ii file 5.11-2 mime-support suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676378: foomatic-db-engine: foomatic-getpjloptions refers to non-existent /usr/bin/nc
Package: foomatic-db-engine Version: 4.0.4-3 Severity: minor The foomatic-getpjloptions does not work, since it tries to run /usr/bin/nc, which nc resides in /bin/nc. Also, all nc's error messages are redirected to /dev/null, so the user does not get notified when it's impossible to run nc or for example if the host does not exist. -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.2-kamdesktop (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages foomatic-db-engine depends on: ii bash 4.1-3 The GNU Bourne Again SHell ii curl 7.21.0-2.1+squeeze2 Get a file from an HTTP, HTTPS or ii foomatic-db20100630-1OpenPrinting printer support - dat ii foomatic-filters 4.0.5-6+squeeze2 OpenPrinting printer support - fil ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libxml22.7.8.dfsg-2+squeeze4 GNOME XML library ii perl 5.10.1-17squeeze3 Larry Wall's Practical Extraction ii wget 1.12-2.1 retrieves files from the web Versions of packages foomatic-db-engine recommends: ii cups1.4.4-7+squeeze1 Common UNIX Printing System(tm) - ii cups-client 1.4.4-7+squeeze1 Common UNIX Printing System(tm) - ii netcat 1.10-38 TCP/IP swiss army knife -- transit ii netcat-traditional [net 1.10-38 TCP/IP swiss army knife Versions of packages foomatic-db-engine suggests: pn foomatic-db-gutenprintnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609934: inetutils-telnetd: telnetd manpage lists bogus options
Package: inetutils-telnetd Version: 2:1.6-3.1+squeeze1 Severity: normal The telnetd manpage lists options, which do not exist in the current telnetd (e.g., -u). On the other hand, it misses several interesting options, which exist (e.g., --exec-login). -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: i386 (x86_64) Kernel: Linux 3.1.6-kamdesktop (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages inetutils-telnetd depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libshishi01.0.0-1Library for the Shishi Kerberos v5 ii netbase 4.45 Basic TCP/IP networking system ii openbsd-inetd [inet-super 0.20080125-6 The OpenBSD Internet Superserver ii rsyslog [system-log-daemo 4.6.4-2enhanced multi-threaded syslogd inetutils-telnetd recommends no packages. inetutils-telnetd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645948: stun: Init script dies when run repeatedly
Package: stun Version: 0.96.dfsg-5 Severity: normal When I run /etc/init.d/stun stop and the daemon is already stopped, the init script dies in the middle of a message, because start-stop-daemon returns non-zero exit code. This happens for example when I try to upgrade the package and the daemon is already stopped. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages stun depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libstdc++64.4.5-8The GNU Standard C++ Library v3 stun recommends no packages. stun suggests no packages. -- Configuration Files: /etc/default/stun changed: START_DAEMON=true DAEMON_OPTS= PRIMARY_IP=46.255.230.98 SECONDARY_IP=46.255.230.99 PRIMARY_PORT=3478 SECONDARY_PORT=3479 DAEMON_USER=nobody -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645671: stund eating lots of CPU
Package: stun Version: 0.96.dfsg-5 Severity: normal When stund runs, it consumes a lot of CPU time, even though it receives no packets. A brief look at the source (stun.cxx, stunServerProcess) reveals that select() is called with a timeout of 1ms. Since the only purpose of the timeout is checking whether an entry in the relay table has expired, the timeout can be increased to 1s with no harm. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages stun depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libstdc++64.4.5-8The GNU Standard C++ Library v3 stun recommends no packages. stun suggests no packages. -- Configuration Files: /etc/default/stun changed: START_DAEMON=true DAEMON_OPTS= PRIMARY_IP=46.255.230.98 SECONDARY_IP=46.255.230.99 PRIMARY_PORT=3478 SECONDARY_PORT=3479 DAEMON_USER=nobody -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608431: xaos: Extension in desktop file
Package: xaos Version: 3.5+ds1-1 Severity: minor When I run an application using desktop files (e.g., geeqie), I get the following warning message: Desktop file '/usr/share/applications/xaos.desktop' should not include extension in Icon key: 'xaos.png' Also, the `desktop-file-validate' utility warns about this problem (and one more). Could you please fix it? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.36.1-kamdesktop (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/bash Versions of packages xaos depends on: ii dpkg1.15.8.5 Debian package management system ii install-info4.13a.dfsg.1-6 Manage installed documentation in ii libaa1 1.4p5-38 ascii art library ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libgsl0ldbl 1.14+dfsg-1 GNU Scientific Library (GSL) -- li ii libpng12-0 1.2.44-1 PNG library - runtime ii libx11-62:1.3.3-4X11 client-side library ii libxext62:1.1.2-1X11 miscellaneous extension librar ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime xaos recommends no packages. xaos suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608432: fontforge: Extension in desktop file
Package: fontforge Version: 0.0.20100501-4 Severity: minor When I run an application using desktop files (e.g., geeqie), I get the following warning message: Desktop file '/usr/share/applications/fontforge.desktop' should not include extension in Icon key: 'ffanvil32.xpm' Also, the `desktop-file-validate' utility warns about this problem (and one more). Could you please fix it? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.36.1-kamdesktop (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/bash Versions of packages fontforge depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfontforge1 0.0.20100501-4 font editor - runtime library ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib ii libgdraw4 0.0.20100501-4 font editor - runtime graphics and ii libgif4 4.1.6-9 library for GIF images (library) ii libglib2.0-02.24.2-1 The GLib library of C routines ii libice6 2:1.0.6-2X11 Inter-Client Exchange library ii libjpeg62 6b1-1The Independent JPEG Group's JPEG ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii libpng12-0 1.2.44-1 PNG library - runtime ii libpython2.62.6.6-8+b1 Shared Python runtime library (ver ii libsm6 2:1.1.1-1X11 Session Management library ii libspiro0 20071029-2 a library for curve design ii libtiff43.9.4-5 Tag Image File Format (TIFF) libra ii libuninameslist00.0.20091231-1 a library of Unicode annotation da ii libx11-62:1.3.3-4X11 client-side library ii libxft2 2.1.14-2 FreeType-based font drawing librar ii libxml2 2.7.8.dfsg-2 GNOME XML library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime fontforge recommends no packages. Versions of packages fontforge suggests: ii autotrace 0.31.1-15+b1 bitmap to vector graphics converte ii fontforge-doc 0.0.20100429-1 Documentation for FontForge pn fontforge-extras none (no description available) ii potrace 1.8-4 utility to transform bitmaps into pn python-fontforge none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608433: gtkam: Extension in desktop file
Package: gtkam Version: 0.1.17-1 Severity: minor When I run an application using desktop files (e.g., geeqie), I get the following warning message: Desktop file '/usr/share/applications/gtkam.desktop' should not include extension in Icon key: 'gtkam-camera.png' Also, the `desktop-file-validate' utility warns about this problem. Could you please fix it? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.36.1-kamdesktop (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/bash Versions of packages gtkam depends on: ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libexif-gtk50.3.5-4 Library providing GTK+ widgets to ii libexif12 0.6.19-1 library to parse EXIF files ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgphoto2-22.4.6-3 gphoto2 digital camera library ii libgphoto2-port02.4.6-3 gphoto2 digital camera port librar ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii libusb-0.1-42:0.1.12-16 userspace USB programming library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime gtkam recommends no packages. gtkam suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601864: openssh-server: Environment variable defaults in PAM act as overrides
Package: openssh-server Version: 1:5.1p1-5 Severity: normal When I configure PAM (in /etc/security/pam_env.conf) to supply a default value for an environment variable that can be passed through a SSH connection, the default always overrides the client's value. Test case: Clear /etc/default/locale Append to /etc/security/pam_env.conf: LC_CTYPE DEFAULT=cs_CZ Check that LC_* is listed in AcceptEnv in /etc/ssh/sshd_config Connect to the server from a client which has LC_CTYPE=cs_CZ.UTF8 set. I expect that the shell on the server will have the client's LC_CTYPE, but I got cs_CZ instead. SSH passes the environment variable correctly (when I comment out the line in pam_env.conf, LC_CTYPE is correct). I suspect that the problem lies in interaction between sshd's environment and PAM's environment. It is likely that sshd does not pass the connection's environment to PAM env, so pam_env does not see the value supplied by the client and sets it to the default, but SSH then blindly overwrites the connection's environment by the PAM's values. [I haven't checked that in the source, though.] -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.33 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/bash Versions of packages openssh-server depends on: ii adduser 3.110add and remove users and groups ii debconf [debcon 1.5.24 Debian configuration management sy ii dpkg1.14.29+b1 Debian package management system ii libc6 2.7-18lenny4 GNU C Library: Shared libraries ii libcomerr2 1.41.3-1 common error description library ii libkrb531.6.dfsg.4~beta1-5lenny4 MIT Kerberos runtime libraries ii libpam-modules 1.0.1-5+lenny1 Pluggable Authentication Modules f ii libpam-runtime 1.0.1-5+lenny1 Runtime support for the PAM librar ii libpam0g1.0.1-5+lenny1 Pluggable Authentication Modules l ii libselinux1 2.0.65-5 SELinux shared libraries ii libssl0.9.8 0.9.8g-15+lenny8 SSL shared libraries ii libwrap07.6.q-16 Wietse Venema's TCP wrappers libra ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip ii openssh-blackli 0.4.1list of default blacklisted OpenSS ii openssh-client 1:5.1p1-5secure shell client, an rlogin/rsh ii procps 1:3.2.7-11 /proc file system utilities ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime Versions of packages openssh-server recommends: pn openssh-blacklist-extra none (no description available) ii xauth 1:1.0.3-2 X authentication utility Versions of packages openssh-server suggests: pn molly-guard none (no description available) pn rssh none (no description available) ii ssh-askpass 1:1.2.4.1-7 under X, asks user for a passphras -- debconf information: ssh/vulnerable_host_keys: ssh/new_config: true * ssh/use_old_init_script: true ssh/encrypted_host_key_but_no_keygen: * ssh/disable_cr_auth: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585719: gphoto2 does not respect umask
Package: gphoto2 Version: 2.4.0-1 Severity: normal Hello! When I use `gphoto2 --get-all-files' in Lenny, all downloaded files have permissions 600, even though my umask is 022. Previous versions of gphoto2 did respect the umask properly. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.33 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/bash Versions of packages gphoto2 depends on: ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libcdk5 5.0.20060507-1 C-based curses widget library ii libexif12 0.6.16-2.1 library to parse EXIF files ii libgphoto2-2 2.4.1-3gphoto2 digital camera library ii libgphoto2-port0 2.4.1-3gphoto2 digital camera port librar ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii libpopt0 1.14-4 lib for parsing cmdline parameters ii libreadline5 5.2-3.1GNU readline and history libraries ii libusb-0.1-4 2:0.1.12-13userspace USB programming library gphoto2 recommends no packages. Versions of packages gphoto2 suggests: pn gthumbnone (no description available) ii gtkam 0.1.12-2.4 GTK+ application for digital still -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565662: krb5-admin-server: kadmind documentation lies about multiple realms
Package: krb5-admin-server Version: 1.6.dfsg.4~beta1-5lenny2 Severity: normal The kadmind(8) man page explicitly says that multiple realms are supported by a single kadmind: -r realm specifies the default realm that kadmind will serve; if it is not specified, the default realm of the host is used. kadmind will answer requests for any realm that exists in the local KDC database and for which the appropriate principals are in its keytab. However, the reality seems to be that the current kadmind no longer supports multiple realms and multiple instances of the daemon have to be used instead. In combination with poor error reporting in the whole Kerberos suite, this is a deadly trap :) Please fix the documentation to say that an instance of kadmind per realm is needed. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/bash Versions of packages krb5-admin-server depends on: ii debconf [debcon 1.5.24 Debian configuration management sy ii krb5-kdc1.6.dfsg.4~beta1-5lenny2 MIT Kerberos key server (KDC) ii libc6 2.7-18 GNU C Library: Shared libraries ii libcomerr2 1.41.3-1 common error description library ii libkadm55 1.6.dfsg.4~beta1-5lenny2 MIT Kerberos administration runtim ii libkeyutils11.2-9Linux Key Management Utilities (li ii libkrb531.6.dfsg.4~beta1-5lenny2 MIT Kerberos runtime libraries ii libss2 1.41.3-1 command-line interface parsing lib ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip krb5-admin-server recommends no packages. krb5-admin-server suggests no packages. -- debconf information: krb5-admin-server/kadmind: true * krb5-admin-server/newrealm: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563856: cvs shocks users by emergency-level syslog messages
Package: cvs Version: 1:1.12.13-12 Severity: important When CVS detects an error while printing an error message, it reports this situation to syslog with level LOG_EMERG, so the (rather useless) message gets broadcasted to all logged-in users. The culprit lies in the error() function in src/error.c: | #if HAVE_SYSLOG_H | /* Syslog the problem since recursion probably means that we encountered an | * error while attempting to send the last error message to the client. | */ | | syslog (LOG_DAEMON | LOG_EMERG, | error (%d, %d) called recursively. Original message was:, | last_status, last_errnum); | syslog (LOG_DAEMON | LOG_EMERG, %s, last_message); | | | syslog (LOG_DAEMON | LOG_EMERG, | error (%d, %d) called recursively. Second message was:, | status, errnum); | syslog (LOG_DAEMON | LOG_EMERG, %s, buf2); | | syslog (LOG_DAEMON | LOG_EMERG, Aborting.); | #endif /* HAVE_SYSLOG_H */ I think that it would be better to disable this piece of code completely. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/bash Versions of packages cvs depends on: ii debconf [debconf-2.0] 1.5.24Debian configuration management sy ii libc6 2.7-18GNU C Library: Shared libraries ii libpam-runtime 1.0.1-5+lenny1Runtime support for the PAM librar ii libpam0g 1.0.1-5+lenny1Pluggable Authentication Modules l ii update-inetd 4.31 inetd configuration file updater ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages cvs recommends: ii emacs [info-browser] 22.2+2-5The GNU Emacs editor (metapackage) ii emacs22 [info-browse 22.2+2-5The GNU Emacs editor ii info [info-browser] 4.11.dfsg.1-4 Standalone GNU Info documentation ii jed [info-browser] 1:0.99.18+dfsg.1-11 editor for programmers (textmode v ii netbase 4.34Basic TCP/IP networking system ii pinfo [info-browser] 0.6.9-3 An alternative info-file viewer cvs suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518750: pommed: cannot mmap memory for GMA950/GMA965
This bug is not present in version 3.0.3 (Lenny), it's in 3.1.2 as explained above by Julien. This is not a bug in libpci, but rather a deficiency in its documentation leading to improper usage in certain applications. The pci_dev-base_addr[] array was always intended to contain the BAR values including the flags in lower bits and it behaved that way for a long time, except for the sysfs back-end which was setting them improperly. This bug was however fixed in pciutils-3.1.0 (commit 6d143c3283855c474445a3cf27c65280ed7ab1b7), exposing the problem in applications to a much larger audience. I have added a note to the declaration in lib/pci.h explaining the proper semantics. Have a nice fortnight -- Martin `MJ' Mares m...@ucw.cz http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Never send to know for whom the bell tolls: it tolls for thee. -- John Donne -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521176: pommed: fails to start, complains of version `LIBPCI_3.1' not found
Hello! SONAME in libpci.so.3.1.2 should be set to libpci.so.3.1 (not libpci.so.3). objdump -p libpci.so.3.1.2 | grep SONAME SONAME libpci.so.3 The SONAME is perfectly correct, the library is designed to be forward compatible by using versioned symbols in the same way as glibc. Applications linked with an older release of libpci should still work with a new release. You however need to provide the correct shlibs file, so that applications linked with the new release will depend on it. They should depend on the most recent version which changed any of the versioned symbols, but in practice I increment the second component of the version number upon any such changes, so a good rule of thumb is to depend on libpci3 = 3.1 for the 3.1.x series. Have a nice fortnight -- Martin `MJ' Mares m...@ucw.cz http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth This message is transmitted on 100% recycled electrons. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517985: FTBFS pciutils 1:3.1.2-1 Fix asm/byteorder.h to define one endianness
Hello, pciutils 3.1.2 fails to compile on mipsel. could you please send me the version of asm/byteorder.h it fails with? Have a nice fortnight -- Martin `MJ' Mares m...@ucw.cz http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth War doesn't determine who's right. It determines who's left. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490295: pciutils: lspci immediately freezes my alpha
Hello! I believe it worked with either etch (1:2.2.4~pre4-1) or even sarge (1:2.1.11-15). Sorry, but I am not sure. Will it help if I foreport one of those to current sid and try again? It probably does not depend on the version of pciutils at all, but it would help if you could try the kernel from Etch. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490295: pciutils: lspci immediately freezes my alpha
Hello! This problem is very likely caused by some PCI device hanging whenever lspci attempts to read its configuration. This can happen due to a bug in either the kernel or the hardware itself. Let us try to find which device it is. First of all, could you please send us the output of `ls -lR /sys', so that we can make sure that there are no devices with strange addresses detected by the kernel? Also, do you know of any version of lspci or the kernel with which the machine does not hang? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496655: State of pci.ids
I think that changing the format of the file (with other suffix) would also be helpful, i.e. instead of using tab-indent I would explicitly writing vendor id (ev. other implicit ids) in every line. In this manner it is easier to grep for hardware, and also to merge files from different sources (cat | sort -u), without requiring external libraries or complex scripts. First, I do not believe it would help anything -- the file would be less readable, larger and harder to edit. This is not a fair price for simplifying a couple of scripts. Second, merging of pci.ids does not help with the updating problem I have described. Do you see any way how it could? Third, while grepping for ID's is appealing, it is nowhere as simple as it looks -- for example, the subsystems can be present either as sub-items of the devices, or as stand-alone entries. [Note: other files *try* to use the same format, e.g. usb.ids, zorro.ids and eisa.ids (in kernel sourcers). But usb.ids has frequently spaces instead of tabs.] I hope this will get much better soon as a common administration system for all the ID files is almost finished. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth There really exists a Microsoft product that doesn't suck -- unfortunately, it's a vacuum cleaner. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496655: State of pci.ids
Hello! Readable: I don't find that actual version is readable, in particular with biggest vendor (i.e. I need a lot of scroll to see if I'm in the right section). This is however not solved by repeating the vendor ID at every line, because people usually do not remember the vendor by the ID ;-) It was a side note: if you need to change it (because of split, etc.) I propose to change also the format. Merging different sources is not so simple (but also not so complex). I would move the logic from code (and runtime) to data. The problem is that your proposal solves only a fraction of the whole problem and quite likely the least important one. For example, if you use `cat | sort -su' to merge ID files, you get the comments completely wrong and you are not able to handle deletions. The tools we use for the maintenance of the ID database work with a similar format internally, but with several tab-separated fields on each line (name, comment, approval state etc.), which is useful in scripts, but awful as a distribution format (fixed order of fields etc.). So I would rather like to keep the current distribution format and let the people use the tools to convert it to whatever they wish. Could you elaborate this? grep '^ ' grep '^ ' would give the subsystem in two simple lines. Yes, except that it depends on the version of the ID file. Three years ago, the stand-alone subsystems did not exist, so people would assume that the second line is sufficient. Suddenly, it no longer is. Extensibility is important, therefore I believe that it is better to use the lookup algorithm from libpci as a black box. But I don't find any of such kind of detection in kernel (e.g. no checking of subsystem ids without a fix vendor/device ids). Many motherboard manufacturers tend to stick a common subsystem ID on all devices on the board. It rarely makes a functional differences, so the drivers usually do not match such ID's (even if the PCI core in the kernel supports such matches), but lspci should tell that the ID belongs to a motherboard and it is somewhat boring to repeat it all over for all devices. ok. This would be nice! So maybe we could have a common tools that handle, grep, merge different ids files. Yes, we definitely want to release such a toolbox. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth This message is transmitted on 100% recycled electrons. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496655: State of pci.ids
Hello and thanks for the prompt response! Martin, what is the pros of having this striped data available? In many cases, the subsystem ID is needed to reliably identify a PCI card as the manufacturers are used to make multiple cards with the same chip, but wired differently. Dropping this information in the udeb is if course a good way of saving space, but the full package should contain everything. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Homo homini lupus, frater fratri lupior, bohemus bohemo lupissimus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496655: State of pci.ids
Hello! My point is that pci.ids has been stripped in both the udeb and the normal binary packages for a number of debian versions of pciutils. Yes, but only in testing. The Etch version is complete. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth All that is necessary for the triumph of evil is that good men do nothing. -- E. Burke -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497861: pciutils: Typo in pci.ids
Hello! Please consider applying Antony's patch. Applied, changes approved. (In the future, you can send patches to a mail robot at [EMAIL PROTECTED], they are automatically analysed and queued for approval in the same way as all submissions through the web interface at http://pci-ids.ucw.cz/ do.) It would be very nice if you could let me know when can I download a new pci.ids to include it in the debian pciutils package. Sure, a snapshot is regenerated every night, see the links at http://pci-ids.ucw.cz/ Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth If a train station is where the train stops, what is a work station? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496655: State of pci.ids
Dropping this information in the udeb is if course a good way of saving space, but the full package should contain everything. In the future (after Lenny), I would like to solve one more problem: with the current rate of development of new hardware, the pci.ids file is getting out of date very quickly and there is no way how to update it nicely. The problem is somewhat mitigated by the network lookup feature present since pciutils 3.0.0, but not all users are connected to the network all the time (and not all programs linked with libpci know how to enable the lookups), so it still makes sense to update the pci.ids file. Of course, we have the update-pciids script, but does its job in a dirty way as it rewrites the pci.ids file coming from the pciutils package, so the file system is no longer consistent with the packages (and debsums fail and so on). We might make libpci look for the file at several places and keep the updated copy somewhere in /var/, but it would make updates of the package painful: which version is the more up-to-date? The one in /usr/share, or the one in /var? So it does not help either. I suggest that we should split off the pci.ids file to a separate arch-independent package with a date-based version number, so that the users can mix pci.ids from several sources and still get consistent upgrades: o the base version present in the distribution; o potential updates from debian-volatile (once in a month?); o daily snapshots from the PCI ID database (I can easily make the snapshot machinery produce Debian packages as well). What do you think of this approach? Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth The road to hell is paved with melting snowballs. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496655: State of pci.ids
volatile is up to the volatile maintainers, though updating it on volatile won't make it usefull for installing new systems... The ability to update the pci.ids from -volatile was meant as a small icing at the top of the cake -- I see the real benefit in the possibility of fetching a package with the new ID file from the PCI ID repository while keeping consistent upgrades. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496655: Broken pci.ids
Package: pciutils Version: 3.0.0-4 Severity: important The pci.ids file provided by the Debian patch is seriously broken. It contains no subsystem entries, no programming interface entries and no comments including the top comment with version and copyright information. As the upstream maintainer, I strongly believe that this problem should be fixed for Lenny, because it makes the output of lspci too broken for normal use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473222: evince: Fails to open files with colons in their name
Package: evince Version: 0.4.0-5 Severity: normal When evince is run from the shell with a file name given as an argument and the file name contains a colon, an error message box with Unable to open document // Unsupported operation appears. When I try to open the same file from the GUI, it works properly. My guess is that evince (or Gnome VFS) tries to use the file name as a URL and it immediately fails, because it does not recognize the URL scheme. This is broken, it should check if the file exists first and fall back to the URL heuristics only if it doesn't. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Versions of packages evince depends on: ii gconf2 2.16.1-1 GNOME configuration database syste ii gs 8.54.dfsg.1-5etch1 Transitional package ii gs-esp [gs] 8.15.3.dfsg.1-1etch1 The Ghostscript PostScript interpr ii gs-gpl [gs] 8.54.dfsg.1-5etch1 The GPL Ghostscript PostScript int ii libart-2.0-22.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.12.4-3 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6 Open-source version of SGI's audio ii libavahi-client30.6.16-3etch1Avahi client library ii libavahi-common30.6.16-3etch1Avahi common library ii libavahi-glib1 0.6.16-3etch1Avahi glib integration library ii libbonobo2-02.14.0-3 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-5 The Bonobo UI library ii libc6 2.3.6.ds1-13etch5GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libdbus-1-3 1.0.2-1 simple interprocess messaging syst ii libdjvulibre15 3.5.17-3 Runtime support for the DjVu image ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.2.1-5+etch2FreeType 2 font engine, shared lib ii libgconf2-4 2.16.1-1 GNOME configuration database syste ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime libr ii libglade2-0 1:2.6.0-4library to load .glade files at ru ii libglib2.0-02.12.4-2 The GLib library of C routines ii libgnome-keyring0 0.6.0-3 GNOME keyring services library ii libgnome2-0 2.16.0-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeprint2.2-0 2.12.1-7 The GNOME 2.2 print architecture - ii libgnomeprintui2.2- 2.12.1-4 GNOME 2.2 print architecture User ii libgnomeui-02.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.14.2-7 GNOME virtual file-system (runtime ii libgnutls13 1.4.4-3 the GNU TLS library - runtime libr ii libgpg-error0 1.4-1library for common error values an ii libgtk2.0-0 2.8.20-7 The GTK+ graphical user interface ii libice6 1:1.0.1-2X11 Inter-Client Exchange library ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libkpathsea43.0-30 path search library for teTeX (run ii libnautilus-extensi 2.14.3-11+b1 libraries for nautilus components ii liborbit2 1:2.14.3-0.2 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-1 PNG library - runtime ii libpoppler0c2 0.4.5-5.1etch2 PDF rendering library ii libpoppler0c2-glib 0.4.5-5.1etch2 PDF rendering library (GLib-based ii libpopt01.10-3 lib for parsing cmdline parameters ii libsm6 1:1.0.1-3X11 Session Management library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libtasn1-3 0.3.6-2 Manage ASN.1 structures (runtime) ii libtiff43.8.2-7 Tag Image File Format (TIFF) libra ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-5X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4X11 Input extension library ii libxinerama11:1.0.1-4.1 X11 Xinerama extension library ii libxml2 2.6.27.dfsg-2
Bug#465277: zlib1g: gzopen() fails on empty files
Package: zlib1g
Version: 1:1.2.3-13
Severity: normal
Tags: patch
When gzopen() is called on an empty file, gzgets() reports end of file
properly, but gzerror() returns the Z_BUF_ERROR. I think that the Debian
patch fixing problems with empty files solves the problem only partially
and that it is necessary to set the transparent mode to 1 in this case.
Patch follows:
--- zlib-1.2.3/gzio.c.mj2008-02-11 16:53:33.0 +0100
+++ zlib-1.2.3/gzio.c 2008-02-11 16:54:15.0 +0100
@@ -306,7 +306,7 @@
s-stream.avail_in += len;
s-stream.next_in = s-inbuf;
if (s-stream.avail_in 2) {
-s-transparent = s-stream.avail_in;
+s-transparent = 1;
return;
}
}
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.23.9
Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2)
Versions of packages zlib1g depends on:
ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries
zlib1g recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459298: ulogd: Silent failure to start
Package: ulogd Version: 1.23-8 Severity: normal When the ipt_ULOG module is not available in the current kernel, the ulogd startup script fails silently without even printing a newline (start-stop-daemon returns with exit code 1, aborting the script, but it has stdout and stderr redirected to /dev/null). This makes troubleshooting unnecessarily painful. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Versions of packages ulogd depends on: ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libc6 2.3.6.ds1-13etch4 GNU C Library: Shared libraries ulogd recommends no packages. -- debconf information: ulogd/config_syntax_changed: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459304: ulogd: Development package wanted
Package: ulogd Version: 1.23-8 Severity: wishlist It would be nice to have a package containing the header files needed for compiling custom plugins. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Versions of packages ulogd depends on: ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libc6 2.3.6.ds1-13etch4 GNU C Library: Shared libraries ulogd recommends no packages. -- debconf information: ulogd/config_syntax_changed: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458201: gzip: zless does not work on non-regular files
Package: gzip Version: 1.3.5-15 Severity: normal As already noted in Bug #407278, zless does not work on pipes when called without arguments. However, this is not the whole story: zless actually does not work on anything except regular files: zless - -- fails to decompress zless /dev/stdin-- not a regular file, use -f (OK) zless -f /dev/stdin -- fails to decompress zless -f /tmp/named-fifo -- fails to decompress This is rather annoying and also incompatible with other Linux distributions, including previous releases of Debian (zless on pipes used to work in Woody), so I believe that it really should be fixed. I agree with the maintainer reasoning in #407278 that zless should be as close in its usage to zless as possible, but it should not be at the expense of breaking special cases. A proper fix is probably to teach less to call LESSOPEN even for non-regular files (maybe only when given a special option). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Versions of packages gzip depends on: ii debianutils2.17 Miscellaneous utilities specific t ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries gzip recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458012: cpufreqd: Automatic loading of modules stops on the first error
Package: cpufreqd Version: 2.2.1-2 Severity: normal When /etc/init.d/cpufreqd tries to load governor modules, it runs modprobe once with the list of all modules it wants. Unfortunately, modprobe stops on the first module it's unable to load, which causes it to fail silently when some of the modules are compiled in the kernel. This is annoying especially on recent 2.6 kernels which don't allow the performance governor to be compiled as a module. Calling modprobe separately for each module solves the problem. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2) Versions of packages cpufreqd depends on: ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libcpufreq0002-2 shared library to deal with the cp ii libsensors31:2.10.1-3library to read temperature/voltag ii libsysfs2 2.1.0-1 interface library to sysfs ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip Versions of packages cpufreqd recommends: ii acpid 1.0.4-5Utilities for using ACPI power man -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453663: ntp-doc: Description of flash codes does not match reality
Package: ntp-doc Version: 1:4.2.2.p4+dfsg-2 Severity: minor The flash codes documented in ntpq manual do not match reality. For example, TEST11 means `root distance exceeded', not any sort of autokey problem. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-kamsmp Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431113: libnet-ssleay-perl: ssl_write_all loops forever if connection broken
Package: libnet-ssleay-perl
Version: 1.30-1
Severity: normal
Tags: patch
When the underlying TCP connection gets broken and the SIGPIPE signal is
blocked, the ssl_write_all method loops forever instead of reporting the
error properly.
Below is my attempt to fix the problem.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20-kamsmp
Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2)
Versions of packages libnet-ssleay-perl depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libssl0.9.8 0.9.8c-4 SSL shared libraries
ii perl5.8.8-7 Larry Wall's Practical Extraction
ii perl-base [perlapi-5.8.7] 5.8.8-7 The Pathologically Eclectic Rubbis
libnet-ssleay-perl recommends no packages.
-- no debconf information
--- /usr/lib/perl5/Net/SSLeay.pm.mj 2007-06-29 22:12:18.0 +0200
+++ /usr/lib/perl5/Net/SSLeay.pm2007-06-29 22:17:37.0 +0200
@@ -1659,9 +1659,10 @@
}
$vm = $trace2 $linux_debug ?
(split ' ', `cat /proc/$$/stat`)[22] : 'vm_unknown';
warn written so far $wrote:$written bytes (VM=$vm)\n if $trace2;
$errs .= print_errs('SSL_write');
+ $errs .= SSL_write $$: 1 - $!\n if $wrote 0 !$errs;
return (wantarray ? (undef, $errs) : undef) if $errs;
}
return wantarray ? ($written, $errs) : $written;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427772: [patch] detach from controlling tty in non-debug mode
Hi! bird needs something like this because in case it daemonizes it still keeps the fds open of the controlling tty which is bad in case you'd like to log out which then will hang. This is definitely worth fixing, but I think that closing all possible fd's is an overkill, especially as getdtablesize() can return an arbitrarily high number if the ulimit on the number of fd's is unset. Here is the patch I applied. diff -u -p -r1.56 main.c --- sysdep/unix/main.c 6 Jun 2004 17:05:25 - 1.56 +++ sysdep/unix/main.c 20 Jun 2007 07:32:04 - @@ -435,6 +435,11 @@ main(int argc, char **argv) if (pid) return 0; setsid(); + close(0); + if (open(/dev/null, O_RDWR) 0) + die(Cannot open /dev/null: %m); + dup2(0, 1); + dup2(0, 2); } signal_init(); Thanks for your bug report -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A: No. Q: Should I include quotations after my reply? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411314: compressed pci.ids issues
Hi Matt! (I will take a look at the other ones soon, now just quickly...) 2.) The file at http://pciids.sourceforge.net/v2.2/pci.ids.gz; is not gzipped. Likewise http://pciids.sourceforge.net/v2.2/pci.ids.bz2; is not bzip2'd (although that's not an issue yet since we don't have bz2 support). Could this be curl/wget or the sf.net web server automatically decompressing? `wget http://pciids.sourceforge.net/v2.2/pci.ids.gz' works for me on my Debian Sarge. The same with curl and also on Etch. Could you please check which utility is used for downloading on your system? Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Purchasing Windows is an Unrecoverable Application Error. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411314: compressed pci.ids issues
Hi! Hmm, I must have been on crack. I thought I tested with wget last night. I know that they were appearing uncompressed with firefox, but that must just be firefox doing that. Sorry for the false alarm. Yes, Firefox does that. #1 and #3 from my email are still valid I think. I will take a look. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth How I need a drink, alcoholic in nature, after the tough chapters involving quantum mechanics! = \pi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393023: PAGE_SIZE export
Hello! I disagree with the assertion that programs which rely on PAGE_SIZE are broken -- if they are architecture specific, they are perfectly correct to assume that PAGE_SIZE is a compile-time constant and there is just no valid reason for trying to hide PAGE_SIZE from them. PAGE_SIZE has been a part of glibc API since ages (on architectures where it's a constant) and I don't think that Debian should be the one who takes decisions on what's in the API and what isn't, leaving us with packages which build (on the given architecture) with every libc except for the Debian one. Also, you have not hidden PAGE_SIZE, but replaced it by a non-constant expression. This breaks programs which assume that if PAGE_SIZE exists, it's a constant. So far, this was true on all architectures and although it hasn't been codified anywhere, so technically you are not breaking any standard, it was a common behavior and there are programs that rely on that, so I don't think it should be changed without a really strong reason. Please revert this patch and leave the decision to upstream maintainers. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393023: PAGE_SIZE export
This bug is assigned to bogl. I assume from your message you meant to reach the linux-kernel-headers maintainers - try debian-glibc instead. Sorry, got a bit confused, I will resend it. Also upstream kernels do not export PAGE_SIZE for various architectures. For instance ia64. Agreed, but Debian should not hide PAGE_SIZE on architectures where the kernel (or libc) exports it. Have a nice day Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404710: vim-common: example macros are distributed with useless info files
Package: vim-common Version: 1:6.3-071+1sarge1 Severity: wishlist The /usr/share/vim/vim63/macros/ directory contains several *.info files with AmigaOS icons, which are completely useless on Debian, so it probably doesn't make any sense to distribute them. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.17.11 Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Versions of packages vim-common depends on: ii vim1:6.3-071+1sarge1 Vi IMproved - enhanced vi editor -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379407: [Pkg-pciutils-discuss] Bug#379407: I/O access on GNU/Hurd
If you apply the attached pciutils-warning.patch, it compiles and then even works. :-) Eh, that was silly :) Thanks! Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379407: [Pkg-pciutils-discuss] Bug#379407: I/O access on GNU/Hurd
Hello! The attached patch is needed to make the pciutils package usable on GNU/Hurd systems with the current Debian gnumach kernel packages. I've merged the patch and cleaned it up considerably. Could you please test that it still works? (It's in the public GIT tree and also in the 2.2.4-pre3 release.) Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Wanted: Schroedinger Cat. Dead or Alive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380032: [Pkg-pciutils-discuss] Bug#380032: FTBFS on hurd-i386: Unconditional use of MAXPATHLEN
As briefly explained on the hurd-devel-debian page[1], unconditional use of PATH_MAX is a POSIX incompatibility. Err, is there any sense in trying to compile pcimodules on the Hurd? It's a program specific to Linux (and it isn't a part of the official pciutils at all, anyway). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379407: [Pkg-pciutils-discuss] Bug#379407: I/O access on GNU/Hurd
Hello! I've tried that but the build fails (I attached the log). I also try to move the #define before other preprocessor directives but that's not better. I've also try to add the #define within the test case in lib/i386-ports.c, but that's not sufficient either. So I guess that a flag could be a better solution than patching many other files. I think that the correct way is to add the #define to internal.h and move #include internal.h in i386-ports.c before the other includes. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth One single semicolon. A perfect drop of perliness. The rest is padding. -- S. Manandhar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335665: kudzu patch to not use PCI_FILL_CLASS
Hello!
Aha. That makes sense; I suspect most PCI devices don't allow the OS to
write that field ;-) I didn't like the 'read it byte-by-byte' part of
the patch, so I changed it to pci_get_word().
Martin, now that we have a reason, what do you think to this patch?
Applied :)
(Available in the GIT repository and also as a -pre2.)
--- pciutils-2.2.1/lib/generic.c.devicetype 2004-08-13 16:15:23.0
-0400
+++ pciutils-2.2.1/lib/generic.c 2005-12-13 17:02:12.0 -0500
@@ -46,7 +46,8 @@
d-func = t-func;
d-vendor_id = vd 0x;
d-device_id = vd 16U;
- d-known_fields = PCI_FILL_IDENT;
+ d-device_class = pci_read_word(t, PCI_CLASS_DEVICE);
+ d-known_fields = PCI_FILL_IDENT | PCI_FILL_CLASS;
Except for this bit -- why should we read it if nobody requested?
--- pciutils-2.2.1/lib/example.c.devicetype 2000-03-09 03:38:33.0
-0500
+++ pciutils-2.2.1/lib/example.c 2005-12-13 17:02:12.0 -0500
@@ -21,7 +21,7 @@
pci_scan_bus(pacc);/* We want to get the list of devices */
for(dev=pacc-devices; dev; dev=dev-next) /* Iterate over all devices */
{
- pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_BASES); /* Fill in
header info we need */
+ pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_BASES | PCI_FILL_CLASS);
/* Fill in header info we need */
c = pci_read_word(dev, PCI_CLASS_DEVICE); /* Read config register
directly */
This doesn't make much sense, I've tried to come with a better example.
Have a nice fortnight
--
Martin `MJ' Mares [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
IBM = Inside Black Magic
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335665: Rationale?
Hello! I am not against this patch, but so far I don't understand the rationale for it. Is there any case where the kernel reports a different class number than the one reported by the device? And if so, it's important for any userland programs? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304576: Fixed upstream
This bug is fixed in pciutils-2.2.1. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347872: Fixed upstream
Fixed in pciutils-2.2.1. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347877: Changing output format
Hello! I would very much appreciate any changes to lspci output format to be discussed in the linux-pci mailing list first. While I admit there were some mistakes in the original format (which I've hopefully fixed in 2.2.0 with minimal incompatibilities), changing the format in just a single distribution is pretty silly. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329067: iproute: Missing src in help
Package: iproute Version: 20041019-3 Severity: minor The src option for ip route add is mentioned in the detailed list of options in the man page, but not in the man page's introduction nor in ip route help. -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.5-kam Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages iproute depends on: ii libatm1 2.4.1-17 shared library for ATM (Asynchrono ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an iproute recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309484: cdrecord: README.DVD.Debian inaccurate
Package: cdrecord Version: 4:2.01+01a01-2 Severity: minor /usr/share/doc/cdrecord/README.DVD.Debian mentions that there is no DVD recording support in this package, but contrary to this, the package seems to be distributed with the DVD recording patch applied. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages cdrecord depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii makedev 2.3.1-77 creates device files in /dev -- debconf information: * cdrecord/SUID_bit: false cdrecord/MAKEDEVNEW: true cdrecord/do_it_yourself: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
