Bug#1078597: libradare2-5.0.0t64: symbolic links to unversioned *.so files missing
On 13.08.24 14:59, Gürkan Myczko wrote: [...] can you tell me which version of iaito you are using? And how it was installed? I used the `iaito` debian packages from the upstream github repos release section: https://github.com/radareorg/iaito/releases/download/5.9.4/iaito_5.9.4_amd64.deb and https://github.com/radareorg/iaito/releases/download/5.9.2/iaito_5.9.2_amd64.deb I don't think it's missing any symbolic link or anything. And I don't think this bug is a bug in radare2. well -- if you install the 5.9.2 release of libradare2-5.0.0t64 you will find libs and unversioned link locations: ``` ls -lh /usr/lib/x86_64-linux-gnu/libr_core.so* lrwxrwxrwx 1 root root 18 Mai 23 08:46 /usr/lib/x86_64-linux-gnu/libr_core.so -> libr_core.so.5.9.2 -rw-r--r-- 1 root root 2,8M Mai 23 08:46 /usr/lib/x86_64-linux-gnu/libr_core.so.5.9.2 ``` but if you install the 5.9.4 release of your package, you will only get: `` ❯ ls -lh /usr/lib/x86_64-linux-gnu/libr_core.so* -rw-r--r-- 1 root root 2,9M Aug 10 21:36 /usr/lib/x86_64-linux-gnu/libr_core.so.5.9.4 ``` this will cause an error in `iaito`: ``` ❯ iaito iaito: error while loading shared libraries: libr_core.so: cannot open shared object file: No such file or directory ``` I would guess that it is due a missing `ldconfigure` call in the installation script... Would you mind trying this version? If it's not 5.9.4: http://bananas.debian.net/debian/iaito/ I couldn't test this package on my machine, because it's only build for the arm architecture.
Bug#1078597: libradare2-5.0.0t64: symbolic links to unversioned *.so files missing
Package: libradare2-5.0.0t64 Version: 5.9.4+dfsg-1 Severity: important Dear Maintainer, The version 5.9.4 of the radare2 libs is missing the symbolic links to the unversioned *.so location. This effects the GUI tool `iaito`, which will not start anymore because it doesn't find the requred libs. Release 5.9.2 did work resp. installs the libs as expected. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libradare2-5.0.0t64 depends on: ii libc6 2.39-6 ii libcapstone4 4.0.2-5.1 ii liblz4-1 1.9.4-3 ii libmagic1t64 1:5.45-3 ii libradare2-common 5.9.4+dfsg-1 ii libxxhash0 0.8.2-2+b1 ii libzip4t64 1.7.3-1.1+b1 ii zlib1g 1:1.3.dfsg+really1.3.1-1 libradare2-5.0.0t64 recommends no packages. libradare2-5.0.0t64 suggests no packages. -- no debconf information
Bug#1078055: refind: ext4 driver in outdated debian version of refind (3.12) doesn't work
Package: refind Version: 0.13.2-1+b1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? The present refind package is outdated even in sid and testing. The actual upstream allready fixied this issue. * What exactly did you do (or not do) that was effective (or ineffective)? I was trying to install refind, but could not see the installed kernels in the chooser. The reason wasn't even reported in refinds logfile. Another user in an internet forum pointed me to the refinds upstream Changelog, where yoz can read at realease 0.14.0 (3/4/2023): "The ext4fs driver now ignores the metadata_csum_seed flag, which is being set by default in e2fsprogs version 1.47.0 and later. Not ignoring the flag caused the driver to fail to read such filesystems. Thanks to Martin Whitaker for the relevant patch." * What was the outcome of this action? I installed the uptream release and everything worked! -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages refind depends on: ii debconf [debconf-2.0] 1.5.87 ii efibootmgr 18-2 ii gdisk 1.0.10-2 ii mokutil0.6.0-2+b1 ii openssl3.2.2-1 Versions of packages refind recommends: ii python3 3.12.4-1 ii sbsigntool 0.9.4-3.1+b1 refind suggests no packages. -- Configuration Files: /etc/refind.d/keys/README.txt [Errno 13] Permission denied: '/etc/refind.d/keys/README.txt' /etc/refind.d/keys/SLES-UEFI-CA-Certificate.cer [Errno 13] Permission denied: '/etc/refind.d/keys/SLES-UEFI-CA-Certificate.cer' /etc/refind.d/keys/SLES-UEFI-CA-Certificate.crt [Errno 13] Permission denied: '/etc/refind.d/keys/SLES-UEFI-CA-Certificate.crt' /etc/refind.d/keys/altlinux.cer [Errno 13] Permission denied: '/etc/refind.d/keys/altlinux.cer' /etc/refind.d/keys/canonical-uefi-ca.cer [Errno 13] Permission denied: '/etc/refind.d/keys/canonical-uefi-ca.cer' /etc/refind.d/keys/canonical-uefi-ca.crt [Errno 13] Permission denied: '/etc/refind.d/keys/canonical-uefi-ca.crt' /etc/refind.d/keys/centossecureboot201.cer [Errno 13] Permission denied: '/etc/refind.d/keys/centossecureboot201.cer' /etc/refind.d/keys/centossecureboot201.crt [Errno 13] Permission denied: '/etc/refind.d/keys/centossecureboot201.crt' /etc/refind.d/keys/centossecurebootca2.cer [Errno 13] Permission denied: '/etc/refind.d/keys/centossecurebootca2.cer' /etc/refind.d/keys/centossecurebootca2.crt [Errno 13] Permission denied: '/etc/refind.d/keys/centossecurebootca2.crt' /etc/refind.d/keys/debian.cer [Errno 13] Permission denied: '/etc/refind.d/keys/debian.cer' /etc/refind.d/keys/fedora-ca.cer [Errno 13] Permission denied: '/etc/refind.d/keys/fedora-ca.cer' /etc/refind.d/keys/fedora-ca.crt [Errno 13] Permission denied: '/etc/refind.d/keys/fedora-ca.crt' /etc/refind.d/keys/microsoft-kekca-public.cer [Errno 13] Permission denied: '/etc/refind.d/keys/microsoft-kekca-public.cer' /etc/refind.d/keys/microsoft-pca-public.cer [Errno 13] Permission denied: '/etc/refind.d/keys/microsoft-pca-public.cer' /etc/refind.d/keys/microsoft-uefica-public.cer [Errno 13] Permission denied: '/etc/refind.d/keys/microsoft-uefica-public.cer' /etc/refind.d/keys/microsoft-uefica-public.crt [Errno 13] Permission denied: '/etc/refind.d/keys/microsoft-uefica-public.crt' /etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.cer [Errno 13] Permission denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.cer' /etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.crt [Errno 13] Permission denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.crt' /etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.cer [Errno 13] Permission denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.cer' /etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.crt [Errno 13] Permission denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.crt' /etc/refind.d/keys/refind.cer [Errno 13] Permission denied: '/etc/refind.d/keys/refind.cer' /etc/refind.d/keys/refind.crt [Errno 13] Permission denied: '/etc/refind.d/keys/refind.crt' -- debconf information: * refind/install_to_esp: true
Bug#1009754: missing go.d.plugin and epbf support in debian packaging of netdata
Package: netdata Version: 1.34.1-1 dear Daniel Baumann! first of all i really have to thank you for your extraordinary quick netdata debian package maintenance work. nevertheless i still have to report some disappointment about important missing parts in this packages. the go.d.plugin, which in the meanwhile has to be seen as the most important plugin kind of netdata, is still absent in your packages of this new release. another more recent feature, eBPF support, is also not enabled. please add this very important and useful components to your package! it would realize a much more complete and satisfying debian alternative to the upstream binary installer. thanks!
Bug#975922: rtklib: please update to a more recent upstream version
On 02.12.20 09:04, Gürkan Myczko wrote: I think I did some time ago (well a new co maintainer acutally did, i just fixed minor formatting in his changes and some lintian clean ups): http://sid.ethz.ch/debian/rtklib/ thanks for this efforts! Unfortunately I lost my post-dsc-in-irc sponsor half a year ago. If you know someone with @debian.org I'd get the package in shape for review+sponsoring happily. I'll queue it up for the mentors.d.n page for now. unfortunately i do not have any knowledge or contacts in privileged debian circles resp. this kind of bureaucracy, but i hope, your contribution will finally find its way in the official repos. rtklib is indeed a very specialized software, which perhaps isn't of much interest to the broad mass of debian users. nevertheless it seems very useful to have a working package available instead of fighting all those rather unpleasant peculiarities, which appear on compiling this software, on every installation attempt again. so: thanks again for your work and good luck on contributing! martin
Bug#975922: rtklib: please update to a more recent upstream version
Package: rtklib Version: 2.4.3+dfsg1-2.1 Severity: important Dear Maintainer, please update the rtklib package! although the rtklib-packes in the debian repository are based on the upstream development branch (2.4.3) of this application, it's in fact still based on a utterly outdated patch level (b8 dating back to january 2016!!! -- instead of the much more common b33 from august 2019). that's very irritating for practical use, because many obvious bugs got already fixed in this more recent patch-level-releases (eg. support for newer Gallileo satellites, etc.) thanks! martin
Bug#865069: [Pkg-raspi-maintainers] Bug#865069: uncompress kernel images
On 2017-10-07 09:16, Michael Stapelberg wrote: i finally didn't use extract-vmlinux from the kernel scripts, because it doesn't work for arm kernels (see: https://patchwork.kernel.org/patch/8120831/), but the 7zip solution also doesn't without flaws. Can you clarify what that means? What are the flaws? Is this ready to merge or not? the actual kernel source decompression script has some nasty compression format detection/handling flows concerning the ARM/ARM64 architecture. it's a well known problem since a long time, but never got fixed AFAIK. and in case of our raspi3 boards it's a really essential problem, because the usual debian kernel compilation tools by default generate compressed images and the raspi3 firmware will not boot from them! Could you lower the Depends on 7zip-full to a Recommends in the interest of reducing the size of the Raspberry Pi images please? The code would need to be changed in such a way that it works both with 7zip present and not present. well -- in fact we could reduce the requirements to a few lines in the README file, explaining, how to compile a uncompressed customized kernel image for raspi3s on debian systems. but if we want to support a more user friendly and tolerant way to bypass this kind of issues in a fully automatic manner and prevent critical faults as much as possible, 7zip-full is a quite simple and efficient solution resp. a very well maintained and versatile package, because we would otherwise need a lot more precautions to handle all the possible different kernel image compression variants in a proper way. but if you see a better solution, please simply ignore my suggestion. it was just my personal answer to the fact, that it took me quite while to find out, why my rasp3s didn't boot with self compiled debian kernels... martin
Bug#865069: [Pkg-raspi-maintainers] Bug#865069: uncompress kernel images
On 2017-06-19 11:39, Michael Stapelberg wrote: Could you supply a tested patch which accomplishes this please? I only use the Debian kernel images. Thanks. you can find a workaround for this issue at: https://gitlab.com/mash_graz/raspi3-firmware/commit/c91645aea40c545d3c4a1cdab5fa8899abc8ceb7 i finally didn't use extract-vmlinux from the kernel scripts, because it doesn't work for arm kernels (see: https://patchwork.kernel.org/patch/8120831/), but the 7zip solution also doesn't without flaws. there is also another fix in this branch, to update /boot/firmware on kernel remove. https://gitlab.com/mash_graz/raspi3-firmware/commit/c206b21e56390d9eed4ef6ddf13621d743c81c91
Bug#865069: [Pkg-raspi-maintainers] Bug#865069: uncompress kernel images
On 2017-06-19 11:39, Michael Stapelberg wrote: Could you supply a tested patch which accomplishes this please? I only use the Debian kernel images. Thanks. yes -- i'll try to find a solution for this issue asap. i'll send you a patch.
Bug#865069: uncompress kernel images
Package: raspi3-firmware Version: 1.20170317-4 the raspi3-firmware kernel postinstall hook should take care of uncompressing kernel moved to /boot/firmware. raspberry firmware can only handle uncompressed images (otherwise the board will hang and only show the rainbow screen). debians official arm64 kernel packages utilize uncompressed kernel images, but cross compiled custom kernels (e.g. by using 'make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- deb-pkg') will pack compressed ones in the linux-image*_arm64.debs by default. 'scripts/extract-vmlinux', provided by the linux kernel source code, could be used to decompress all kinds of kernel images.
Bug#845526: [PATCH] Allow users to specify the boot directory path
the suggested vmdebootstrap patch by Michael doesn't set the customized
boot mount point in /etc/fstab of the generated images.
i also think, the '--bootdirfmt' and its unusual "%s..." syntax doesn't
look very handy. therefore i used a simple '--bootdir' option in my fix.
working patch attached.
diff --git a/bin/vmdebootstrap b/bin/vmdebootstrap
index d9a697d..e4e7e60 100755
--- a/bin/vmdebootstrap
+++ b/bin/vmdebootstrap
@@ -78,6 +78,7 @@ class VmDebootstrap(cliapp.Application): # pylint: disable=too-many-public-meth
self.settings.string(['bootflag'], 'specify flag to set for /boot/', default='')
self.settings.bytesize(['bootoffset'], 'Space to leave at start of the '
'image for bootloader', default='0')
+self.settings.string(['bootdir'], 'Mount point of /boot partition', default='/boot/')
self.settings.boolean(['use-uefi'], 'Setup image for UEFI boot', default=False)
self.settings.bytesize(['esp-size'], 'Size of EFI System Partition - '
'requires use-uefi', default='5mib')
@@ -248,9 +249,9 @@ class VmDebootstrap(cliapp.Application): # pylint: disable=too-many-public-meth
elif bootdev:
boottype = self.settings['boottype']
filesystem.mkfs(bootdev, fstype=boottype)
-self.bootdir = '%s/%s' % (rootdir, 'boot/')
+self.bootdir = '%s/%s' % (rootdir, self.settings['bootdir'])
filesystem.devices['bootdir'] = self.bootdir
-os.mkdir(self.bootdir)
+os.makedirs(self.bootdir)
self.mount(bootdev, self.bootdir)
# set user-specified flags, e.g. lba
diff --git a/doc/overview.rst b/doc/overview.rst
index 43693f2..da0f236 100644
--- a/doc/overview.rst
+++ b/doc/overview.rst
@@ -107,6 +107,8 @@ Options
--boottype=FSTYPE Filesystem to use for the /boot partition. (default ext2)
--bootflag=FLAG Flag to set on the first partition. (default none)
--bootoffset=SIZE Space to leave at start of the image for bootloader
+ --bootdir=PATHMount point of /boot partition.
+ Default is ``/boot/``.
--roottype=FSTYPE Filesystem to use for the / (root) partition. (default ext4)
--part-type=PART-TYPE
Partition type to use for this image. (default msdos)
diff --git a/vmdebootstrap/filesystem.py b/vmdebootstrap/filesystem.py
index b911c05..d9241c9 100644
--- a/vmdebootstrap/filesystem.py
+++ b/vmdebootstrap/filesystem.py
@@ -171,8 +171,8 @@ class Filesystem(Base):
fstab.write('%s / %s %s 0 1\n' %
(rootdevstr, roottype, self.get_mount_flags(roottype)))
if bootdevstr:
-fstab.write('%s /boot %s %s 0 2\n' %
-(bootdevstr, boottype, self.get_mount_flags(boottype)))
+fstab.write('%s %s %s %s 0 2\n' %
+(bootdevstr, self.settings['bootdir'], boottype, self.get_mount_flags(boottype)))
if self.settings['swap'] > 0:
fstab.write("/dev/sda3 swap swap defaults 0 0\n")
elif self.settings['swap'] > 0:
Bug#864945: wrong sort order in kernel postinst hook
Package: raspi3-firmware Version: 1.20170317-4 the sort commands utilized for searching the most actual kernel in /etc/kernel/postinst.d/raspi3-firmware are not using option --version-sort. this doesn't work for updates e.g. from 4.9 to 4.12. a patch to fix this issue is included. diff --git a/debian/kernel/postinst.d/raspi3-firmware b/debian/kernel/postinst.d/raspi3-firmware index ca4d158..38cc69d 100755 --- a/debian/kernel/postinst.d/raspi3-firmware +++ b/debian/kernel/postinst.d/raspi3-firmware @@ -22,13 +22,13 @@ if ! ischroot; then fi fi -latest_kernel=$(ls -1 /boot/vmlinuz-* | grep -v '\.dpkg-bak$' | sort -r | head -1) +latest_kernel=$(ls -1 /boot/vmlinuz-* | grep -v '\.dpkg-bak$' | sort -V -r | head -1) if [ -z "$latest_kernel" ]; then echo "raspi3-firmware: no kernel found in /boot/vmlinuz-*, cannot populate /boot/firmware" exit 0 fi -latest_initrd=$(ls -1 /boot/initrd.img-* | grep -v '\.dpkg-bak$' | sort -r | head -1) +latest_initrd=$(ls -1 /boot/initrd.img-* | grep -v '\.dpkg-bak$' | sort -V -r | head -1) if [ -z "$latest_initrd" ]; then echo "raspi3-firmware: no initrd found in /boot/initrd.img-*, cannot populate /boot/firmware" exit 0
Bug#775490: ITP natron -- Natron is an open-source, crossplatform, nodal compositing software
it would be really helpful, if could have access to natron in a more debian like style at last. although it's a GPL licensed project, binaries from https://natron.fr/download/ are only available after registration and the .deb creation mechanism used for their packages doesn't look very transparent and easy to reproduce by ordinary users. see: https://forum.natron.fr/t/how-to-build-deb-packages-of-natron/1345/1 https://github.com/MrKepzie/Natron/issues/385 https://forum.natron.fr/t/no-binary-download-without-account/808 i think, IOhannes has much more experiences maintaining packages, but otherwise i'm always willing to help. martin
Bug#787033: [calligra] New release 2.9.4 available upstream
On 2015-10-19 04:18, Dmitry Smirnov wrote: I understand your frustration but situation is more complex than it seems. thanks for your kind reply. :) don't worry, i'll wait as long as it takes... good luck!
Bug#787033: [calligra] New release 2.9.4 available upstream
On Thu, 28 May 2015 17:37:09 +0200 Adrien Grellier wrote: I just started the packaging this week. Sorry for the delay it's now have a year later... krita can not be used/installed anymore on typical debian testing machines because of unresolved dependency problems. no necessary update happened for quite a while! :( it would be really nice, if this issue could be solved sooner or later...
Bug#801426: ociolutimage and ocioconvert are missing in opencolorio-tools
Package: opencolorio-tools Version: 1.0.9~dfsg0-4 there are manual page for ociolutimage and ocioconvert in the package opencolorio-tools but the commands are not included. ociolutimage is used/needed by the selfcheck of ACES 1.0.1 config python scripts.
Bug#801355: python module missing
Package: openimageio Version: 1.5.19~dfsg0-1 there is no python package for openimageio available for debian and it's not easy to build without compiling the whole package... (see: http://openimageio.org/wiki/index.php?title=Python_bindings) the python module is necessary to rebuild/update ACES 1.0.1 opencolorio configs etc.
Bug#754388: dcraw 9.22
Package: dcraw Version: 9.21-0.2 there is a new upstream version (9.22) of dcraw available. it would be very helpful to get support for new cameras (eg. lumix GH4). thanks! martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713974: not solved in darktable:1.4-1
this problem still exists in darktable:amd64/testing 1.4-1 ls -lh Bilder/xyz/darktable_gallery/js -rw-r--r-- 1 mash mash0 Jän 8 19:28 builder.js -rw-r--r-- 1 mash mash0 Jän 8 19:28 effects.js -rw-r--r-- 1 mash mash0 Jän 8 19:28 lightbox.js -rw-r--r-- 1 mash mash0 Jän 8 19:28 lightbox-web.js -rw-r--r-- 1 mash mash 177K Jän 8 19:28 prototype.js -rw-r--r-- 1 mash mash 2,9K Jän 8 19:28 scriptaculous.js -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593652: grub-common: grub-probe still segfaults with 1.98+20100804-6
Am 2010-11-01 23:11, schrieb Robert Millan: I backported the patch, please can you test this? i had some simple compilation errors: ../../disk/mdraid_linux.c:257: error: request for member ‘this_disk’ in something not a structure or union fixed it: --- disk/mdraid_linux.c-old 2010-11-02 02:10:23.0 +0100 +++ disk/mdraid_linux.c 2010-11-02 02:13:51.0 +0100 @@ -255,5 +255,5 @@ return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "unsupported RAID level: %d", sb->level); - if (sb.this_disk.number == 0x || sb.this_disk.number == 0xfffe) + if (sb->this_disk.number == 0x || sb->this_disk.number == 0xfffe) return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "spares aren't implemented"); the resulting binaries seem to work fine: r...@sow:~# for array in /boot / /mnt; do echo -e "\n testing: $array"; for target in fs drive device abstraction; do /usr/sbin/grub-probe -t $target $array; done ; done testing: /boot ext2 (md/boot) /dev/md127 raid mdraid testing: / ext2 (md/root) /dev/md125 raid mdraid testing: /mnt ext2 (md0) /dev/md0 raid mdraid thanks for this effort! martin --- disk/mdraid_linux.c-old 2010-11-02 02:10:23.0 +0100 +++ disk/mdraid_linux.c 2010-11-02 02:13:51.0 +0100 @@ -255,5 +255,5 @@ return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "unsupported RAID level: %d", sb->level); - if (sb.this_disk.number == 0x || sb.this_disk.number == 0xfffe) + if (sb->this_disk.number == 0x || sb->this_disk.number == 0xfffe) return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "spares aren't implemented");
Bug#593652: grub-common: grub-probe still segfaults with 1.98+20100804-6
Am 2010-10-31 13:56, schrieb Robert Millan: So you want me to cherry-pick this non-trivial patch but nobody has tested it with mdraid 0.9, which I presume is the most widely deployed version? just for testing purposes i set up a 0.9 array on my machine: r...@sow:~# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb4[2](S) sdb3[3](S) sdb2[1] sdb1[0] 10490304 blocks [2/2] [UU] [>] resync = 3.6% (383104/10490304) finish=15.8min speed=10641K/sec md125 : active raid1 sda3[0] sdc3[2] sdd3[3](S) 64324188 blocks super 1.0 [2/2] [UU] md126 : active raid1 sda2[0] sdc2[2] sdd2[3](S) 6297468 blocks super 1.0 [2/2] [UU] md127 : active raid1 sda1[0] sdc1[2] sdd1[3](S) 1060244 blocks super 1.0 [2/2] [UU] grub-probe seems to work fine on this device: r...@sow:~# mount /dev/md0 /mnt r...@sow:~# /tmp/grub-probe /mnt/ ext2 r...@sow:~# /tmp/grub-probe -t device /mnt /dev/md0 i coudn't figure out any way to let it crash like the actual debian binaries... Or otherwise, someone confirm me it's been tested with 0.9, and I'll add the patch myself. btw. -- i did all this tests using patched versions from upstream. it's perhaps not so trival to backport everything to 1.98+20100804 faultlessly. if you need any further testing i'll do my best... but in general i would like to see the upstream development and their fixes as the most responsible source of improvement. martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593652: grub-common: grub-probe still segfaults with 1.98+20100804-6
Am 2010-10-30 22:00, schrieb Vincent Danjean: On 28/10/2010 15:44, Robert Millan wrote: Have you tested this with the version in Debian? Is it known to work with 1.x and not cause regression with 0.9? it works fine in my (version 1.0) setup but it couldn't test it in all the the other possible configurations... Please let me know, I'll try to get it in squeeze when this is confirmed. I'm sure that the current grub2 in Debian is a regression in comparison with some previous versions. Robert, I really think that a patch for this bug should be included in squeeze.A raid setup with spare disks was > working before. Since a few versions of grub2, it is broken. There is > a patch that seems to fix this bug and the patch comes from upstream. > You should apply it to the grub2 package and upload it to unstable. i think, robert was just asking for some confirmation an practical testing in the context of affected machines. but you right -- we should use the given solution simply as one step forward to make grub-probe work again. martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593652: grub-common: grub-probe still segfaults with 1.98+20100804-6
Am 2010-10-26 00:16, schrieb Robert Millan: Has this patch been sent upstream? Was it reviewed there? there is now a much more complete patch by vladimir serbinenko for upstream available. beside some minor cleanup (change 'index' from signed to unsigned) and refactoring (folding some fields to the structure 'grub_raid_member') it respects the differences between dmraid format 0.9 and 1.x (the later becomes the default in debian squeeze) and all the related memory management. (see: http://lists.gnu.org/archive/html/grub-devel/2010-10/msg00044.html ) please include this changes in the debian packages. otherwise it will be nearly impossible to update or finish an installation using spare disks. martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593652: grub-common: grub-probe still segfaults with 1.98+20100804-6
Am 2010-10-26 00:16, schrieb Robert Millan: I'm afraid I'm not familiar enough with this part of the code to ACK this kind of patch during freeze. Has this patch been sent upstream? Was it reviewed there? If it hasn't, please do. If it's committed or at least ACKed in upstream, I see no problem with adding it. the upstream developers are informed about this problem, even though they didn't accept this bug fix. (http://lists.gnu.org/archive/html/grub-devel/2010-09/msg00259.html) in a quick response to my reminder concerning this outstanding problem vladimir serbinenko wrote today on the grub-devel list that he will seek for a better solution very soon. (http://lists.gnu.org/archive/html/grub-devel/2010-10/msg00043.html) martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572865: not gthumb really
this probleme seems to be related to the missing /lib/udev/rules.d/40-libgphoto2-2.rules file in debian. as a workaround you can copy this file from ubuntu. see also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564540 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531978 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593652: grub-common: grub-probe segfault (revised patch)
here is a revised patch.
it takes care, that spare (index == 0x) or faulty (index == 0xfffe)
drives don't increment array->nr_devs. otherwise the function
grub_is_array_readable would return wrong results.
sorry, i didn't recognize that in my first attempt.
=== modified file 'grub-core/disk/raid.c'
--- grub-core/disk/raid.c 2010-09-13 21:59:22 +
+++ grub-core/disk/raid.c 2010-09-25 22:20:29 +
@@ -501,7 +501,8 @@
grub_dprintf ("raid", "array->nr_devs > array->total_devs (%d)?!?",
array->total_devs);
-if (array->device[new_array->index] != NULL)
+if ((new_array->index < GRUB_RAID_MAX_DEVICES) &&
+ (array->device[new_array->index] != NULL))
/* We found multiple devices with the same number. Again,
this shouldn't happen. */
grub_dprintf ("raid", "Found two disks with the number %d?!?",
@@ -609,9 +610,14 @@
}
/* Add the device to the array. */
- array->device[new_array->index] = disk;
- array->start_sector[new_array->index] = start_sector;
- array->nr_devs++;
+
+ /* ignore spare/faulty disks and more then GRUB_RAID_MAX_DEVICES */
+ if (new_array->index < GRUB_RAID_MAX_DEVICES)
+{
+ array->device[new_array->index] = disk;
+ array->start_sector[new_array->index] = start_sector;
+ array->nr_devs++;
+}
return 0;
}
Bug#593652: grub-common: grub-probe segfault (revisited patch)
here is a revisted patch.
it takes care, that spare (index == 0x) or faulty (index == 0xfffe)
drives don't increment array->nr_devs. otherwise the function
grub_is_array_readable would return wrong results.
sorry, i didn't recognize that in my first attempt.
=== modified file 'grub-core/disk/raid.c'
--- grub-core/disk/raid.c 2010-09-13 21:59:22 +
+++ grub-core/disk/raid.c 2010-09-25 22:20:29 +
@@ -501,7 +501,8 @@
grub_dprintf ("raid", "array->nr_devs > array->total_devs (%d)?!?",
array->total_devs);
-if (array->device[new_array->index] != NULL)
+if ((new_array->index < GRUB_RAID_MAX_DEVICES) &&
+ (array->device[new_array->index] != NULL))
/* We found multiple devices with the same number. Again,
this shouldn't happen. */
grub_dprintf ("raid", "Found two disks with the number %d?!?",
@@ -609,9 +610,14 @@
}
/* Add the device to the array. */
- array->device[new_array->index] = disk;
- array->start_sector[new_array->index] = start_sector;
- array->nr_devs++;
+
+ /* ignore spare/faulty disks and more then GRUB_RAID_MAX_DEVICES */
+ if (new_array->index < GRUB_RAID_MAX_DEVICES)
+{
+ array->device[new_array->index] = disk;
+ array->start_sector[new_array->index] = start_sector;
+ array->nr_devs++;
+}
return 0;
}
Bug#593652: grub-common: grub-probe segfault
just a few additional remarks about this bug fix in my last post: spare disks within a raid array don't show a useful 'index' number. they may have values like 65535 in their index field. whiteout this fix it's nearly impossible to install grub on any machine with software raid and spare disks under debian squezze or unstable. every call of grub-probe will segfault. this belongs to "grub-pc" and "grub-legacy". both of them share the package grub-common and this grave bug. :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593652: grub-common: grub-probe segfault
grub2 upstream needs some fixes to accept spare disks in raid arrays.
the attached modifications in 'grub-core/drive/raid.c' stopped the
segmentation faults on my machine.
=== modified file 'grub-core/disk/raid.c'
--- grub-core/disk/raid.c 2010-09-13 21:59:22 +
+++ grub-core/disk/raid.c 2010-09-25 05:59:45 +
@@ -501,7 +501,8 @@
grub_dprintf ("raid", "array->nr_devs > array->total_devs (%d)?!?",
array->total_devs);
-if (array->device[new_array->index] != NULL)
+if ((new_array->index < GRUB_RAID_MAX_DEVICES) &&
+ (array->device[new_array->index] != NULL))
/* We found multiple devices with the same number. Again,
this shouldn't happen. */
grub_dprintf ("raid", "Found two disks with the number %d?!?",
@@ -609,8 +610,13 @@
}
/* Add the device to the array. */
- array->device[new_array->index] = disk;
- array->start_sector[new_array->index] = start_sector;
+
+ /* ignore spare disks and more then GRUB_RAID_MAX_DEVICES */
+ if (new_array->index < GRUB_RAID_MAX_DEVICES)
+{
+ array->device[new_array->index] = disk;
+ array->start_sector[new_array->index] = start_sector;
+}
array->nr_devs++;
return 0;
Bug#572865: same problem...
version 2.11 doesn't import photos from my camera too. i have to use the 2.11 package from lenny and set it on hold. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#310595: libpam-passwdqc: incorrect/misleading documentation
Package: libpam-passwdqc Version: 0.7.5-1 Severity: normal the documentation for parameter N2 in the list of minum allowed password lengths asserts: "N2 is used for passphrases. A passphrase must consist of sufficient words (see the "passphrase" option below)." ^ that's misleading or wrong! well -- the min. number of WORDS within a passphrase is only defined by the 'passphrase' argument described a few lines later... but N2 at the scope of this paragraph belongs to the min. length in LETTERS of such a passphrase and nothing else! please correct: /usr/share/doc/libpam-passwdqc/README.gz /usr/share/man/man8/pam_passwdqc.8.gz and btw.: IMHO it would be a very usefull to include a simple example how to stack passwdqc.so and pam_unix.so within /etc/pam.d/common-passwd in this documentation, too. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.12-rc4clean-serial-mod Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libpam-passwdqc depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libpam0g0.76-22 Pluggable Authentication Modules l -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
