Bug#1043017: Take patch from upstream to fix 'Fix crash when printing download rate'
Package: wget Version: 1.21-1+deb11u1 Actually all versions of wget 1.xxx on all (supported) versions of Debian. Wget can segfault, caused by passing undefined memory to printf. It's been fixed upstream. https://git.savannah.gnu.org/git/wget.git Commit 04ab35666997fbb3cd5d72497415fb3dfd62dcc5 https://lists.gnu.org/archive/html/bug-wget/2023-08/msg1.html Patch attached. 0001-Fix-crash-when-printing-download-rate.patch Description: application/mbox
Bug#995567: Can't handle cross-signed Let's Encrypt CA
Package: lftp Version: 4.7.4-1 Severity: important Tags: upstream LFTP implements a certificate verification that can't handle cross-singing when the cross-sign CA expires. The result is that you can't use lftp to access ftp servers that use Let's Encrypt certificates, with the recent expiration of DST root CA X3. All Debian versions are affected (don't mind my oldoldstable version). Fix is not ready, but is pending. It needs back-porting (in supported Debian versions). https://github.com/lavv17/lftp/issues/641 -- System Information: Debian Release: 9.13 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: i386 (i686) Kernel: Linux 4.9.0-16-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages lftp depends on: ii libc6 2.24-11+deb9u4 ii libgcc1 1:6.3.0-18+deb9u1 ii libgnutls30 3.5.8-5+deb9u6 ii libidn11 1.33-1+deb9u1 ii libreadline7 7.0-3 ii libstdc++66.3.0-18+deb9u1 ii libtinfo5 6.0+20161126-1+deb9u2 ii netbase 5.4 ii zlib1g1:1.2.8.dfsg-5 Versions of packages lftp recommends: ii openssh-client [ssh-client] 1:7.4p1-10+deb9u7 lftp suggests no packages. -- debconf information:
Bug#929129: closed by Hans van Kranenburg (Bug#929129: fixed in xen 4.11.1+92-g6c33308a8d-1)
This is an update to the unstable release. What is one running Debian stable (9), with Xen Hypervisor 4.8, to do?
Bug#929129: [Pkg-xen-devel] Bug#929129: Xen Hypervisor security update for Intel MDS - XSA 297
On Sat, 18 May 2019 at 12:18, Hans van Kranenburg wrote: > Hi, > > On 5/17/19 5:21 PM, Wiebe Cazemier wrote: > > Package: xen-hypervisor-4.8-amd64 > > Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11 > > > > All Xen Hypervisor packages also need patches against the Intel MDS bug, > > same as https://www.debian.org/security/2019/dsa-. > > > > http://xenbits.xen.org/xsa/advisory-297.html > > Yes, they do. > > For Xen 4.8 and 4.11, we're currently waiting for the related changes in > the upstream code branches to complete the regular test process at Xen > (compile, run on all different hardware etc). > > Only at the moment that the advisary is published, the patches are > committed to the public development branches. After that, the tests do > more rigorous regression testing than the developer writing them could > do. We tend to wait for this to succeed. E.g. as part of the packaging > team, I can test that the result boots on amd64, but I have no idea > myself if it also runs on arm etc. > > If you're desperately in need for an intermediate version, and you're > able to build debian packages yourself, then I can point you at > something that I'm running myself now. > > Regards, > Hans > No rush in that sense. The bugreport was precipitated by the lack of any mention of Xen in Ubuntu's en Debian's security announcements, while Qemu and libvirt were.
Bug#929129: Xen Hypervisor security update for Intel MDS - XSA 297
Package: xen-hypervisor-4.8-amd64 Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11 All Xen Hypervisor packages also need patches against the Intel MDS bug, same as https://www.debian.org/security/2019/dsa-. http://xenbits.xen.org/xsa/advisory-297.html
Bug#905832: svn2git: Possible error in code handling keyboard events
I have the same issue. Version 2.4.0-1 in Ubuntu 18.04. A work-around is to log in successfully with the 'git svn' command (which is run by svn2git in the background) on the server, and make it remember.
Bug#903821:
Hi, Yesterday, it was already due to be installed on FTP. When is that? Because of the delay, I caused our Xen server to get stuck into a kernel panic reboot loop after upgrading and rebooting Jul 19 23:00 UTC. It was actually during an upgrade from Debian 8 to 9 and I had no older 4.9 kernel, so I'm now running one of the old 3.16 kernels. A fast release would be much appreciated.
Bug#832995: Same in Ubuntu 16.04
Same problem in Ubuntu 16.04. Ubuntu 16.04 AMD64 Rsyslog 8.16.0-1ubuntu3
Bug#770135: Reproduced in Ubuntu 16.04
Should it be relevant, this keeps hapenning on Ubuntu 16.04. Systemd and libpam-systemd version 229-4ubuntu10.
Bug#702046: Update to 4.0.1-5.7 breaks pygrub here too
Just dropping a line; xen-utils-4.0 4.0.1-5.7 breaks here too. Luckily, I hadn't upgraded my main xen hosts yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702046: xen-utils-4.0: Update to 4.0.1-5.7 breaks pygrub, none of my VMs boot
Package: xen-utils-4.0 Version: 4.0.1-5.7 Severity: normal Just dropping the note that my xen hosts suffer from this bug (#702046) -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xen-utils-4.0 depends on: ii e2fslibs1.41.12-4stable1 ext2/ext3/ext4 file system librari ii iproute 20100519-3 networking and traffic control too ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libxenstore3.0 4.0.1-5.7Xenstore communications library fo ii python-support 1.0.10 automated rebuilding support for P ii python2.5 2.5.5-11 An interactive high-level object-o ii udev164-3/dev/ and hotplug management daemo ii xen-utils-common4.0.0-1 XEN administrative tools - common ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages xen-utils-4.0 recommends: ii bridge-utils 1.4-5 Utilities for configuring the Linu ii xen-hypervisor-4.0-amd64 [xen 4.0.1-5.7 The Xen Hypervisor on AMD64 Versions of packages xen-utils-4.0 suggests: pn xen-docs-4.0 (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#696415: nagios3: Nagios sends notifications when notifications are disabled with the webgui.
Package: nagios3 Version: 3.2.1-2 Severity: normal Tags: upstream When you have external commands enabled and you set a host to 'Disable notifications for this host', you still get notifications about its services. Expected behavior is that you wouldn't. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (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/bash Versions of packages nagios3 depends on: ii nagios3-cgi 3.2.1-2cgi files for nagios3 ii nagios3-core 3.2.1-2A host/service/network monitoring nagios3 recommends no packages. Versions of packages nagios3 suggests: pn nagios-nrpe-plugin (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#476545: Progress
Is there any progress here? It's 4 years later and we have dependency boot sequencing now. My problem is that drbd is started after xendomains, but drbd needs to be active for starting Xen domains (in my case). I added xendomains to the following parameters in /etc/init.d/drbd: # X-Start-Before: heartbeat corosync xendomains # X-Stop-After: heartbeat corosync xendomains Then it works.
Bug#640500: [Pkg-xen-devel] Bug#640500: Acknowledgement (xen-hypervisor-4.0-amd64: xend invokes oomkiller and reboots machine when creating DomU's)
Op 05-09-11 19:04, Thomas Goirand schreef: On 09/05/2011 07:33 PM, Wiebe Cazemier wrote: Severity is set to normal, but I set it to grave or serious in the bug report tool. This bug is more severe than 'normal', in any case. Not discussing the bug itself, but just FYI... Please read about the severity when reporting. "serious" is mostly reserved for the Debian policy violation: serious: is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should not do so.) In your case, it might deserves a severity "important" if you think that "normal" doesn't fit: important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. vs normal: a bug that does not undermine the usability of the whole package; for example, a problem with a particular option or menu item. The Xen hypervisor, in this case, is not "completely unusable to everyone", so severity "important" might be the highest severity. The other 2 higher seriousness would be: 1 critical: makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. or 2 grave: makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. and none are your case, IMO. Please pay attention to the definitions of seriousness next time you do a bug report. Thomas Goirand (zigo) Thanks for pointing it out. I'll be more watchful and careful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#640500: [Pkg-xen-devel] Bug#640500: xen-hypervisor-4.0-amd64: xend invokes oomkiller and reboots machine when creating DomU's
Op 05-09-11 18:54, Thomas Goirand schreef: On 09/05/2011 06:48 PM, Wiebe Cazemier wrote: Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-2 Severity: normal Tags: upstream When creating Xen DomU's, at some point xend invokes the oom-killer and the entire machine restarts: Sep 5 12:04:59 arbiter kernel: [259697.101212] __ratelimit: 136 callbacks suppressed Sep 5 12:04:59 arbiter kernel: [259697.101218] xend invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0 Sep 5 12:04:59 arbiter kernel: [259697.101225] xend cpuset=/ mems_allowed=0 Sep 5 12:04:59 arbiter kernel: [259697.101230] Pid: 1841, comm: xend Not tainted 2.6.32-5-xen-amd64 #1 Sep 5 12:06:23 arbiter kernel: imklog 4.6.4, log source = /proc/kmsg started. Sep 5 12:06:23 arbiter rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="1409" x-info="http://www.rsyslog.com";] (re)start Sep 5 12:06:23 arbiter kernel: [0.00] Initializing cgroup subsys cpuset xm info says the machine has 10231 MB of RAM. These are the VMs that normally run: Name ID Mem VCPUs State Time(s) Domain-0 0 2177 1 r- 127.1 one 1 1536 2 r- 192.4 two 2 512 1 -b 2.7 three3 1024 1 -b 188.6 four 4 512 1 -b 12.7 five 5 2048 2 -b 151.7 six 6 1024 2 r- 64.9 seven7 1024 2 -b 65.9 eight8 1024 2 -b 100.7 Funny domU names! :) Well, I actually obfuscated the names. Personally, I don't mind revealing such things, but I don't know what 'the company' would say... That means 8704 MB of memory is used. Over the last couple of days, I've experienced that when creating two VM's with 512 MB RAM, the oom-killer is invoked. This should not happen because Dom0 can shrink and because the machine should not restart when it is out of memory. This is a production Xen host, which is becomming a liability, because it's so unpredictable. Current Dom0 kernel: Linux arbiter 2.6.32-5-xen-amd64 Hi, I wouldn't recommend to just let your dom0 shrink. Set it directly to a much lower memory footprint, something like 512 MB of RAM, so that the Linux kernel sees directly that it doesn't have so much memory to deal with, and it will not allocate too big buffers and so on. Here's how to do this with the Squeeze grub: echo " # Start dom0 with less RAM GRUB_CMDLINE_XEN_DEFAULT=\"dom0_mem=512M\" ">>/etc/default/grub Then either run update-grub2 or dpkg-reconfigure grub-pc (and of course reboot...). If you do that, I'm sure your troubles will go away. You shouldn't be running big software in the dom0 anyway. I always done that because of habits from running older Xen (since 2.0.7), and because I've seen issues with the dom0 ballooning out. To me, ballooning the memory of dom0 is more a desktop feature than for a server. I believe this bug should be closed, because that's not really an issue with Xen (but more with the way the Linux dom0 kernel works). I'll let Bastian decide though. Thomas Goirand (zigo) I agree that the dom0 shouldn't do heavy work and it doesn't. I will try your suggestion; I had already looked for an option to set the max dom0 memory, but couldn't find it (only a minimum one). I didn't think about kernel params. I wonder though, if creating VM's when memory runs out even with a small dom0 will the still trigger the OOM killer. A nice warning about being out of memory would be nicer... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#640500: Acknowledgement (xen-hypervisor-4.0-amd64: xend invokes oomkiller and reboots machine when creating DomU's)
Severity is set to normal, but I set it to grave or serious in the bug report tool. This bug is more severe than 'normal', in any case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#640500: xen-hypervisor-4.0-amd64: xend invokes oomkiller and reboots machine when creating DomU's
Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-2 Severity: normal Tags: upstream When creating Xen DomU's, at some point xend invokes the oom-killer and the entire machine restarts: Sep 5 12:04:59 arbiter kernel: [259697.101212] __ratelimit: 136 callbacks suppressed Sep 5 12:04:59 arbiter kernel: [259697.101218] xend invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0 Sep 5 12:04:59 arbiter kernel: [259697.101225] xend cpuset=/ mems_allowed=0 Sep 5 12:04:59 arbiter kernel: [259697.101230] Pid: 1841, comm: xend Not tainted 2.6.32-5-xen-amd64 #1 Sep 5 12:06:23 arbiter kernel: imklog 4.6.4, log source = /proc/kmsg started. Sep 5 12:06:23 arbiter rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="1409" x-info="http://www.rsyslog.com";] (re)start Sep 5 12:06:23 arbiter kernel: [0.00] Initializing cgroup subsys cpuset xm info says the machine has 10231 MB of RAM. These are the VMs that normally run: Name ID Mem VCPUs State Time(s) Domain-0 0 2177 1 r- 127.1 one 1 1536 2 r- 192.4 two 2 512 1 -b 2.7 three3 1024 1 -b 188.6 four 4 512 1 -b 12.7 five 5 2048 2 -b 151.7 six 6 1024 2 r- 64.9 seven7 1024 2 -b 65.9 eight8 1024 2 -b 100.7 That means 8704 MB of memory is used. Over the last couple of days, I've experienced that when creating two VM's with 512 MB RAM, the oom-killer is invoked. This should not happen because Dom0 can shrink and because the machine should not restart when it is out of memory. This is a production Xen host, which is becomming a liability, because it's so unpredictable. Current Dom0 kernel: Linux arbiter 2.6.32-5-xen-amd64 -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (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 xen-hypervisor-4.0-amd64 depends on no packages. Versions of packages xen-hypervisor-4.0-amd64 recommends: ii xen-utils-4.0 4.0.1-2XEN administrative tools Versions of packages xen-hypervisor-4.0-amd64 suggests: pn xen-docs-4.0 (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#640099: Acknowledgement (xen-tools: xen-create-image doesn't include xen-blkfront module in initramfs, so doesn't boot.)
As addendum; I reported a bug about it at Ubuntu's Launchpad: https://bugs.launchpad.net/ubuntu/+bug/839492 Because the previous Ubuntu releases did find the /dev/xvda device, something changed at their end. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#640099: xen-tools: xen-create-image doesn't include xen-blkfront module in initramfs, so doesn't boot.
Package: xen-tools Version: 4.2-1 Severity: important Tags: upstream Subject says it all. It falls back to initramfs prompt. I do "modprobe xen-blkfront" and then "exit" and then it boots. Then I do "echo "xen-blkfront" >> /etc/initramfs-tools/modules" and "update-initramfs -u" to make it permanent. This not only fails when upgrading your DomU to Natty (which this tool can't help), but also when creating a new Natty. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (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 xen-tools depends on: ii debootstrap1.0.26+squeeze1 Bootstrap a basic Debian system ii libconfig-inifiles-per 2.52-1Read .ini-style configuration file ii libfile-slurp-perl .13-1 single call read & write file rout ii libtext-template-perl 1.45-1Text::Template perl module ii perl-modules 5.10.1-17squeeze2 Core Perl modules Versions of packages xen-tools recommends: ii libexpect-perl1.20-2 Expect.pm - Perl Expect interface ii rinse 1.7-1 RPM installation environment ii xen-hypervisor-4.0-amd64 [xen 4.0.1-2The Xen Hypervisor on AMD64 pn xen-shell (no description available) Versions of packages xen-tools suggests: pn btrfs-tools(no description available) pn cfengine2 (no description available) pn evms-cli (no description available) pn reiserfsprogs (no description available) ii xen-utils-4.0 [xen-utils] 4.0.1-2XEN administrative tools pn xfsprogs (no description available) -- Configuration Files: /etc/xen-tools/xen-tools.conf changed: lvm = universe install-method = debootstrap size = 50Gb # Disk image size. memory = 512Mb# Memory size swap = 4GB# Swap size fs = ext3 # use the EXT3 filesystem for the disk image. dist = `xt-guess-suite-and-mirror --suite` # Default distribution to install. gateway= 89.188.17.1 netmask= 255.255.255.0 passwd = 1 kernel = /boot/vmlinuz-`uname -r` initrd = /boot/initrd.img-`uname -r` mirror = `xt-guess-suite-and-mirror --mirror` mirror_maverick = http://nl.archive.ubuntu.com/ubuntu/ mirror_natty = http://nl.archive.ubuntu.com/ubuntu/ ext3_options = defaults ext2_options = defaults xfs_options = defaults reiserfs_options = defaults btrfs_options= defaults disk_device = xvda #default (not default?) pygrub=1 scsi=1 -- 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#621499: xen-tools: disk_device is checked to match tty* or hvc* pattern.
Package: xen-tools Version: 4.2-1 Severity: normal Tags: patch 1556,1557c1556,1557 < check => qr/^(?:\/dev\/)?(?:tty|hvc)[0-9]+$/, < message => "must be a disk device (tty*, hvc*).\n", --- > check => qr/^(?:\/dev\/)?(?:xvda|sda|hda)$/, > message => "must be a disk device (sda, xvda, hda).\n", -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (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 xen-tools depends on: ii debootstrap 1.0.26+squeeze1 Bootstrap a basic Debian system ii libconfig-inifiles-perl 2.52-1 Read .ini-style configuration file ii libfile-slurp-perl .13-1 single call read & write file rout ii libtext-template-perl1.45-1 Text::Template perl module ii perl-modules 5.10.1-17 Core Perl modules Versions of packages xen-tools recommends: ii libexpect-perl1.20-2 Expect.pm - Perl Expect interface ii rinse 1.7-1 RPM installation environment ii xen-hypervisor-4.0-amd64 [xen 4.0.1-2The Xen Hypervisor on AMD64 pn xen-shell (no description available) Versions of packages xen-tools suggests: pn btrfs-tools(no description available) pn cfengine2 (no description available) pn evms-cli (no description available) pn reiserfsprogs (no description available) ii xen-utils-4.0 [xen-utils] 4.0.1-2XEN administrative tools pn xfsprogs (no description available) -- Configuration Files: /etc/xen-tools/xen-tools.conf changed [not included] -- 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#433668: rdiff-backup has random "assertionerror"s crashes
Package: rdiff-backup Version: 1.1.9-2 Rdiff-backup 1.1.9 (which I got after upgrading the stable 1.0.5 version) suffers from random crashes, giving "AssertionError" at the end of a stacktrace. I have the problem, and I have found several other cases. However, I realize that this is not a debian problem. My actual confusion is about the development version of rdiff-backup being the only version available, even in the stable branch? The changelog says: "now using development-releases as they are stable enough", but how can that decision be made when the developer of the program labels it as "development/unstable" (literal quote). There is very little development going on in rdiff-backup, and I would really expect to see the latest stable version available in Debian, because to be blunt, I don't want the developers weekend's experiments on my production server. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425824: (no subject)
Severity: grave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425824: Dar 2.3.3 contains major bugfix and should be available
Package: dar Version: 2.3.3 Severity: |grave| Dar version 2.3.3 should be available because it contains a major bugfix. From the dar mailinglist: === See at the bottom of this email the list of all change and let me first warn you about an important bug found three days ago (all older version of dar are affected): If you were using dar to backup in one time several mounted filesystems, if hard links were present on one of theses filesystems (most Unix users should assume yes, while windows users should not be concerned) and if you were using filtering (-X, -I, -P, -g, -[, -] option) that lead to exclude some hard linked files, it is strongly recommended to consider the case where the bug #1667400 expressed (for details refer to Sourceforge): In brief, some files may have been considered as a hard link to an inode of same number but located on another filesystem, leading to your data not being backed up properly. Dar's test (-t) option cannot report any problem as the resulting archive stayed well generated while Dar's diff (-d) option of older releases suffered from the same bug (same code used to read a filesystem). In consequence, as more as you have hard links as more it is recommended to recycle your backup quickly (at least make a full backup should be OK). If however the filesystem under backup does not change often, you can use Dar's diff option (-d) of release 2.3.3 to check for the occurrence of this bug, be aware that it may report differences due to real changes in the filesystem as well as improperly saved hard linked data due to this bug. === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417700: Dosbox upstream version 0.70 packaging request
Package: dosbox Version: 0.70 Dosbox 0.70 has been released upstream; packaging is requested. It can be downloaded at: http://dosbox.sourceforge.net/download.php?main=1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
