Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

2023-12-13 Thread Michael Gold
On Sun, Nov 26, 2023 at 09:01:12 +, Mate Kukri wrote: > The mechanism used to load the kernel has changed from GRUB 2.06 to > GRUB 2.12, it is possible that there are unfortunate bugs in either in > GRUB and/or your firmware that is stopping the new mechanism from > loading the kernel. Just

Bug#992383: debianutils: which is noisy and doesn't suggest a different option

2021-08-19 Thread Michael Gold
On Wed, Aug 18, 2021 at 12:53:53 -0400, Jason Riedy wrote: > I've been using which for decades, including on SunOS and AIX. When I know > it's a script, less `which foobar` is quick and easy. Adding this to ~/.bashrc or similar might help: which () { bash -c 'command -v "$@"' which "$@"; } It

Bug#992383: debianutils: which is noisy and doesn't suggest a different option

2021-08-19 Thread Michael Gold
On Wed, Aug 18, 2021 at 13:28:14 +0900, Norbert Preining wrote: ... > but being noisy about it on any invocation, **without** providing > an alternative is a no go ... > Please use NEWS, or whatever other channels, and above all, **provide > information on a replacement!** I checked 'man which'

Bug#796931: gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file

2015-08-30 Thread Michael Gold
On Mon, Aug 31, 2015 at 00:22:06 +0200, Thorsten Glaser wrote: On Sat, 29 Aug 2015, Michael Gold wrote: This seems to work for gpg1 and gpg2: : ${GPG_AGENT_INFO=${GNUPGHOME-$HOME/.gnupg}/S.gpg-agent:0:1} export GPG_AGENT_INFO I assume this needs to be written after the eval? I

Bug#796931: gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file

2015-08-29 Thread Michael Gold
On Tue, 25 Aug 2015, Thorsten Glaser wrote: particular sharing now becomes impossible). It’s actually worse: when using startx or no X environment at all, I can no longer use gpg-agent: tglase@tglase-nb:~ $ eval $(gpg-agent --daemon --sh) tglase@tglase-nb:~ $ gpg --clearsign x ...

Bug#751585: systemd: opens emergency shell after prompting for unnecessary dm-crypt passwords

2014-06-14 Thread Michael Gold
Package: systemd Version: 204-10 Severity: critical After installing systemd today and rebooting, I saw a few lines (not errors) about systemd-fsck on xfs filesystems, and then I was prompted for dm-crypt passwords for 4 disks that are not necessary to boot the system. I pressed enter to bypass

Bug#751589: sysvinit-core: /sbin/init missing after switching from systemd to sysvinit

2014-06-14 Thread Michael Gold
Package: sysvinit-core Version: 2.88dsf-53.2 Severity: critical After a failed switch to systemd today (Debian bug #751585), I tried to switch back to sysvinit but found /sbin/init missing after a reboot, which of course prevented the system from booting. /sbin was available in the emergency

Bug#751589: [Pkg-sysvinit-devel] Bug#751589: sysvinit-core: /sbin/init missing after switching from systemd to sysvinit

2014-06-14 Thread Michael Gold
On Sat, Jun 14, 2014 at 16:47:45 +0200, Petter Reinholdtsen wrote: [Michael Gold] /sbin was available in the emergency shell and contained some files, but 'init' wasn't there. 'dpkg -L sysvinit-core' ended at the line '/sbin' (i.e., it was missing /sbin/shutdown, /sbin/init, etc.). I

Bug#751589: sysvinit-core: /sbin/init missing after switching from systemd to sysvinit

2014-06-14 Thread Michael Gold
On Sat, Jun 14, 2014 at 17:34:21 +0200, Michael Biebl wrote: That said, I can not reproduce the sequence of events which make /sbin/init dissappear. I've installed systemd-sysv in a VM, then ran apt-get install sysvinit-core and /sbin/init was available afterwards. So something else must

Bug#751589: sysvinit-core: /sbin/init missing after switching from systemd to sysvinit

2014-06-14 Thread Michael Gold
On Sat, Jun 14, 2014 at 18:31:25 +0200, Michael Biebl wrote: Did you try apt-get remove systemd? According to apt-history that was the first command I ran after installing it. You can't remove the systemd package while systemd is still the active init. How did you force the removal? I

Bug#718191: moreutils: vidir loses changes on error

2013-07-28 Thread Michael Gold
Package: moreutils Version: 0.49 Severity: grave vidir will abort, discarding the edited name list, on a parsing error: michael@terra:~/x$ mkdir vidir-test michael@terra:~/x$ cd vidir-test/ michael@terra:~/x/vidir-test$ ls michael@terra:~/x/vidir-test$ touch a b c d e

Bug#718191: moreutils: vidir loses changes on error

2013-07-28 Thread Michael Gold
severity 718191 normal thanks On Sun, Jul 28, 2013 at 18:40:25 -0400, Joey Hess wrote: Grave severity means that this is so important that it would be better to remove moreutils entirely than leave it as-is. Sorry, I wasn't aware of that; the documentation[1] states that data loss alone is

Bug#536683: Info received (bash execution trace)

2009-09-15 Thread Michael Gold
On Mon, Sep 14, 2009 at 18:28:27 -0300, Rogério Brito wrote: OK, now that I just sent the workaround in the earlier message, I dug in a little further. The problem seems to be related to the embedded awk script in the configure script of the package. In its stock version, when fed with my

Bug#540571: Backtrace

2009-08-22 Thread Michael Gold
On Fri, Aug 21, 2009 at 10:35:51 +0300, Peter Pentchev wrote: I've fixed it in my Subversion repository, and I'll release hexer-0.1.5 (adopting the upstream) soon. In the meantime, could you try dropping the attached file into debian/patches/ and adding it to series to see if it helps? I no

Bug#540571: Backtrace

2009-08-09 Thread Michael Gold
Here's the gdb output after rebuilding it with debug symbols: Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:48 48 ../sysdeps/x86_64/strlen.S: No such file or directory. ~ in ../sysdeps/x86_64/strlen.S Current language: auto; currently asm

Bug#540571: crashes when ':' typed

2009-08-08 Thread Michael Gold
Package: hexer Version: 0.1.4c-3 Severity: grave hexer segfaults whenever a colon is typed; this makes the package unusable since many important commands are prefixed with a colon. Older versions worked fine on the same system. - Michael -- System Information: Debian Release: squeeze/sid APT