Bug#821900: apt: changelog lookup in incorrect location, hence fails to find it
Package: apt Version: 1.0.9.8.3 Severity: normal Dear Maintainer, * What led up to the situation? # apt-get upgrade It listed the new packages in the usual fashion, including openssh-server, which in particular suggests to me that I should look at the changelog. * What exactly did you do (or not do) that was effective (or ineffective)? $ apt-get changelog openssh-server * What was the outcome of this action? $ apt-get changelog openssh-server Err Changelog for openssh-server (http://packages.debian.org/changelogs/pool/updates/main/o/openssh/openssh_6.7p1-5+deb8u2/changelog) 404 Not Found [IP: 5.153.231.3 80] Err Changelog for openssh-server (http://security.debian.org/pool/updates/main/o/openssh/openssh_6.7p1-5+deb8u2.changelog) 404 Not Found [IP: 195.20.242.89 80] E: changelog download failed * What outcome did you expect instead? To see the changelog. I noticed that the changelog file for openssh_6.7p1-5+deb8u1 (note: u1) on the web is both at a "redirected" site and under a different path, so maybe some of apt or a changelog placement script is uninformed about where the other would write or where the other should look in this case? I notice that "changelog not found" is not a new problem either, but maybe the site redirection is, or the inclusion of security host's paths in this scheme? apt(8) is a core tool and in this state suggests to the administrator to bye a pig in a poke even when he or she should install security updates such as openssh. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-headers-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-modules-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-tools-3\.2\.0-4-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Never-MarkAuto-Sections:: "oldlibs"; APT::Never-MarkAuto-Sections:: "restricted/oldlibs"; APT::Never-MarkAuto-Sections:: "universe/oldlibs"; APT::Never-MarkAuto-Sections:: "multiverse/oldlibs"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "1"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "2"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-9n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "3";
Bug#737225: gnat: decimal type's 'Round does not round, effectively truncates
Package: gnat Version: 4.6 Severity: normal Tags: patch Dear Maintainer, The program attached to this report reflects a finding in c.l.ada, Jan 2014, How to round to the nearest fixed-point value, Message-ID: slrnldvtim.1lme.lithium...@sigil.instinctive.eu which has been classified as a compiler bug. The program should run as is, with no output. Instead, it raises Program_Error because the value of 0.999, rounded to 3 digits, is not 1.00, but 0.99. procedure Round_Decimal is -- OJBECTIVE: --Check that 'Round of a decimal fixed point type does round --away from zero if the operand is of a decimal fixed point --type with a smaller delta. type Milli is delta 0.001 digits 9; type Centi is delta 0.01 digits 9; function Rounded (Value : Milli) return Centi; -- Value, rounded using Centi'Round function Rounded (Value : Milli) return Centi is begin return Centi'Round (Value); end Rounded; begin -- Operands used directly: if not (Milli'Round (0.999) = Milli'(0.999) and Centi'Round (0.999) = Centi'(1.0) and Centi'Round (Milli'(0.999)) = Centi'(1.0)) then raise Program_Error; end if; -- This is expected to fail, currently, but shouldn't: if Rounded (Milli'(0.999)) /= Centi'(1.0) then raise Program_Error; end if; end Round_Decimal; -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnat depends on: ii gnat-4.6 4.6.3-8 Versions of packages gnat recommends: pn ada-reference-manual none pn gnat-gps none gnat 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#471609: libaunit-dev: possible impact of gnatgcc in debian/rules
Package: libaunit-dev Version: 1.03-2 Followup-For: Bug #471609 (Using gnat-4.3.) While forcing a dpkg-buildpackage -b of libaunit-1.03-2 I stumbled on /usr/bin/gnatgcc, which is not installed with gnat-4.3 (as ^gnat$ not installed). However, gnatgcc is used verbatim as a command in the rules file of libaunit-1.03, for making a shared library. As a workaround: if the link gnatgcc - /usr/bin/gcc-4.3 is present, aunit can be built. Still, installation isn't possible (presumably because of the conflicting dependences). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libaunit-dev depends on: pn gnat-4.1 none (no description available) pn libaunit1.03 none (no description available) libaunit-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480532: libaunit-dev: instructions in aunit.gpr not using the right syntax
Package: libaunit-dev Version: 1.03-2 Severity: minor Tags: patch File /usr/share/ada/adainclude/aunit.gpr (which is debian/aunit.gpr) has this Linker options line: -- -- for Default_Switches (Ada) use (AUnit.Ada_Switches ...) This is using '', but should be using ','. (With '', options will in fact be concatenated. They need to be passed as different arguments here, and messages are somewhat confusing if not.) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libaunit-dev depends on: pn gnat-4.1 none (no description available) pn libaunit1.03 none (no description available) libaunit-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320087: fixed in ipsec-tools 1:0.6.4-1
Lionel points to the use of insmod where modprobe should be used in racoon's setup. Ganesan reports their belief in a fix of this in ipsec-tools 1:0.6.4-1 However, /usr/sbin/racoon-tool, which is the origin of thi bug, is not listed as part of ipsec-tools, AFAICS. Indeed, racoon-tools still calls /sbin/insmod explicitly (near line 2400). So how does ipsec-tools fix a bug in a different package (racoon)? Or am I missing something? -- Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320087: fixed in ipsec-tools 1:0.6.4-1
On Wed, 2006-12-06 at 19:21 +0530, Ganesan Rajagopal wrote: Georg Bauhaus wrote: ... Indeed, racoon-tools still calls /sbin/insmod explicitly (near line 2400). So how does ipsec-tools fix a bug in a different package (racoon)? Or am I missing something? ipsec-tools is the source package. racoon and ipsec-tools are binary packages from the same source. What version of racoon-tools do you have installed? My version (0.6.6-3) does not have the insmod statement. Wrong version here, I should have made sure that I am looking at a Debian window :-/. Sorry. (If anyone is interested, at the time of this email Ubuntu 6.06 has it wrong, Debian has it right.) Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311360: gnupg: introduces unnecessary dependence on USB dev support (i.e. not sug./rec.)
Package: gnupg Version: 1.2.5-3 Severity: normal after an update today dselect reports that gnupg depends on libusb-0.1-4. Possibly indirectly: Depends: libbz2-1.0, libc6 (= 2.3.2.ds1-4), libldap2 (= 2.1.17-1), zlib1g (= 1:1.2.1), makedev (= 2.3.1-13) | devfsd | hurd Nothing against USB support in cryptograhpic software of course, but GnuPG shouldn't require USB device support to be present. Offering the support by way of suggesting it seems way enough. (We have a number of production machines where USB device support is turned off for good reasons. The latest dependence would force us to reintroduce USB and set up appropriate procedures with far reaching consequences, for no good.) regards, Georg # apt-cache depends gnupg gnupg Depends: libbz2-1.0 Depends: libc6 Depends: libldap2 Depends: libreadline5 Depends: libusb-0.1-4 Depends: zlib1g |Depends: makedev |Depends: devfsd Depends: hurd Suggests: gnupg-doc Suggests: xloadimage Conflicts: gpg-rsa Conflicts: gpg-rsaref Conflicts: suidmanager Conflicts: gpg-idea Replaces: gpg-rsa gnupg Replaces: gpg-rsaref gnupg -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.18 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages gnupg depends on: ii libbz2-1.0 1.0.2-6 high-quality block-sorting file co ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libldap22.1.30-8 OpenLDAP libraries ii makedev 2.3.1-77 creates device files in /dev ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311360: gnupg: introduces unnecessary dependence on USB dev support (i.e. not sug./rec.)
Peter Palfrader wrote: Georg Bauhaus schrieb am Dienstag, dem 31. Mai 2005: after an update today dselect reports that gnupg depends on libusb-0.1-4. Possibly indirectly: Depends: libbz2-1.0, libc6 (= 2.3.2.ds1-4), libldap2 (= 2.1.17-1), zlib1g (= 1:1.2.1), makedev (= 2.3.1-13) | devfsd | hurd Have you verified that this is actually the case? Just because GnuPG depends and is linked against libusb doesn't mean that it requires USB support to be present on the system or in the kernel. Sorry, I should have been more precise: (1) GnuPG Depends: on libusb as in dselect, and apt, (2) /usr/bin/gpg requires lubusb-0.1.so.4 to run, see below. So I guess that in a Debian system, by default no GnuPG tool cannot be had without that library linked to all GnuPG programs? (Out of couriosity, does one need the tool /usr/bin/gpg for secured USB device handling?) Trying standard installation (dselect won't install even when overriding with Q): # dpkg -i gnupg_1.4.1-1_i386.deb (Reading database ... 129928 files and directories currently installed.) Unpacking gnupg (from gnupg_1.4.1-1_i386.deb) ... dpkg: dependency problems prevent configuration of gnupg: gnupg depends on libusb-0.1-4 (= 2:0.1.10a); however: Package libusb-0.1-4 is not installed. dpkg: error processing gnupg (--install): dependency problems - leaving unconfigured Errors were encountered while processing: gnupg Now use force: strudel:/tmp# dpkg --force-depends -i gnupg_1.4.1-1_i386.deb (Reading database ... 129997 files and directories currently installed.) Preparing to replace gnupg 1.4.1-1 (using gnupg_1.4.1-1_i386.deb) ... Unpacking replacement gnupg ... dpkg: gnupg: dependency problems, but configuring anyway as you request: gnupg depends on libusb-0.1-4 (= 2:0.1.10a); however: Package libusb-0.1-4 is not installed. Setting up gnupg (1.4.1-1) ... Try it: strudel:/tmp# gpg --version gpg: error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory strudel:/tmp# To verify: # ldd /usr/bin/gpg libz.so.1 = /usr/lib/libz.so.1 (0x40025000) libbz2.so.1.0 = /usr/lib/libbz2.so.1.0 (0x40037000) libreadline.so.5 = /lib/libreadline.so.5 (0x40046000) libdl.so.2 = /lib/libdl.so.2 (0x40074000) libusb-0.1.so.4 = not found libc.so.6 = /lib/libc.so.6 (0x40077000) libncurses.so.5 = /lib/libncurses.so.5 (0x401aa000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311360: gnupg: introduces unnecessary dependence on USB dev support (i.e. not sug./rec.)
Peter Palfrader wrote: Georg Bauhaus schrieb am Dienstag, dem 31. Mai 2005: Peter Palfrader wrote: Georg Bauhaus schrieb am Dienstag, dem 31. Mai 2005: after an update today dselect reports that gnupg depends on libusb-0.1-4. Possibly indirectly: Depends: libbz2-1.0, libc6 (= 2.3.2.ds1-4), libldap2 (= 2.1.17-1), zlib1g (= 1:1.2.1), makedev (= 2.3.1-13) | devfsd | hurd Have you verified that this is actually the case? Just because GnuPG depends and is linked against libusb doesn't mean that it requires USB support to be present on the system or in the kernel. Sorry, I should have been more precise: (1) GnuPG Depends: on libusb as in dselect, and apt, (2) /usr/bin/gpg requires lubusb-0.1.so.4 to run, see below. Yes, but why is this a problem? The package is there, just install it and you're done. just install it and you're done becomes a problem (I big one) if you care about a consistent, and manageable set of archives in an operating system installation. Every part requires time and thus money, every recursive closure of an additional dependence introduces more and more SysOp work (than needed). If there is a really convincing argument that a tool like /usr/bin/gpg invented for signing and encrypting files must be aware of the USB, I'll shut up immediately. (Not saying that encrypted communication of some sort over USBs makes no sense!). (I know I can compile the thing myself, tweaking debian/control.) Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311360: gnupg: introduces unnecessary dependence on USB dev support (i.e. not sug./rec.)
Peter Palfrader wrote: Georg Bauhaus schrieb am Dienstag, dem 31. Mai 2005: Yes, but why is this a problem? The package is there, just install it and you're done. I see that since v1.3.90 GnuPG is by default used as a card reader thing. So the USB requirement for traditional use doesn't seem to be a Debian issue. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
