Bug#861027: gprolog bug still there despite easy fixes
Hello Tony,
tony mancill (Sunday 2019-03-10):
> I had a try at this. I pulled the latest upstream release 1.4.5 from
> gprolog.org [1], which is dated February of 2019 and it exhibits the
> same problem reported in this bug report.
Are you sure? The official 1.4.5 works for me when compiled from
source and installed into a directory that is in my PATH. Remember
that the toplevel gprolog invokes various binaries, e.g. pl2wam;
are you sure you didn't have the buggy pl2wam in your PATH? It has
bitten me before while testing.
> Also problematic is that the sources for version 1.4.5 found on
> gprolog.org differ substantially from the 1.4.5 sources found in Debian.
As far as I understand it, that's because Debian's "1.4.5" isn't the
release, it's development code pulled from gprolog's git repository
a couple of years ago, sometime after 1.4.4 was released.
Best regards,
Cedric Ware.
Bug#861027: gprolog bug still there despite easy fixes
Hello, I don't think anything changed with this bug, which still prevents gprolog's inclusion in any stable release, and affects Ubuntu as well. I believe just pulling the latest upstream source would fix it. Alternatively, if downgrading to the stable gprolog-1.4.4 is an option, the attached patch lets it compile with gcc 6. Tested on Debian 9.4. Thanks in advance, Cedric Ware. diff -ru gprolog-1.4.4.orig/src/Ma2Asm/x86_64_any.c gprolog-1.4.4/src/Ma2Asm/x86_64_any.c --- gprolog-1.4.4.orig/src/Ma2Asm/x86_64_any.c 2013-04-22 13:52:16.0 +0200 +++ gprolog-1.4.4/src/Ma2Asm/x86_64_any.c 2018-05-10 16:31:10.534235899 +0200 @@ -204,8 +204,8 @@ strcpy(asm_reg_cp, Off_Reg_Bank(MAP_OFFSET_CP)); #endif -#ifdef M_x86_64_darwin - pic_code = 1; /* NB: on darwin everything is PIC code */ +#if defined(M_x86_64_darwin) || defined(M_x86_64_bsd) || defined(M_x86_64_linux) + pic_code = 1; /* NB: on darwin and BSD everything is PIC code, last gcc 6 needs this for linux */ #elif defined(_WIN32) pic_code = 0; /* NB: on MinGW nothing is needed for PIC code */ #endif
Bug#775234: /sbin/e2fsck: systemd boot will hang if e2fsck-based logging is enabled
Hello,
Theodore Ts'o (Monday 2015-01-12):
Arguably this is as mucha bug in systemd-fsck since it could have been
waiting for fsck to terminate instead of waiting for an EOF from the
progress_fd pipe, but I agree that it would be better if e2fsck were
to close the progress_fd.
Thank you. Indeed, I wasn't sure where to file this bug; I chose e2fsck
because it had suffered from a similar one, and it seemed easier to fix
as you did than to replace systemd-fsck's while(!feof) { fscanf } loop
with something much more complicated...
OTOH, thinking about it, other filesystems' fsck utilities might be
affected too, not just e2fsck.
Do you think this bug should be reassigned to systemd? Or that other fsck
maintainers should be made aware of the issue?
This isn't an RC bug by any means (I don't think it even rates
important) since very few people are using the e2fsck.conf logging
capabilities --- most debian users pre-systemd have been been using
/var/log/fsck/*, and systemd will do its own journalctl thing.
I'm not as well-versed as I'd like in the various logging mechanisms, but
given that /var/log/fsck isn't mounted RW at this stage of the boot,
doesn't logging there require e2fsck.conf logging?
Besides, even though few people may be using e2fsck.conf, they may be in for
a nasty surprise when upgrading to Jessie, or systemd users if they try
tinkering with e2fsck.conf; don't you think users should be warned somehow?
Perhaps the postinst script in the Debian package could check for it?
(And this doesn't cover other distributions or filesystems, of course.
Maybe it is really systemd's problem...)
Anyway, thanks for your time, and for the patch.
Best regards,
Cedric Ware.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775234: /sbin/e2fsck: systemd boot will hang if e2fsck-based logging is enabled
Theodore Ts'o (Tuesday 2015-01-13): My understanding is that the release team is trying very hard to get Jessie out the door, and so I don't want to try to push things, especially since most debian users probably won't have discovered this particular e2fsck.conf feature. I understand. At least, future versions of e2fsck will have the fix. Well, the -C option is to date only honored by e2fsck. In fact /sbin/fsck will only pass the -C option to fsck.ext[234]. Ah, I hadn't noticed. systemd-fsck does pass the -C option to /sbin/fsck, for all filesystem types, as long as fsck.fstype exists in the PATH (and isn't a symlink to /bin/true or the like). So, if other fsck programs detach a child process, they won't even be able to close the pipe's fd and will have the problem. Do you know of any such? If I have time I'll have take a look at the systemd-fsck sources, but that's neither here nor there. I have looked; if you think someone may be actually interested in a patch, I could probably write it while the memory's fresh. It's not that hard, just somewhat tedious, as you couldn't use fscanf reliably on the pipe itself; you'd need a poll() loop that relays the pipe to a memory stream or something like that. Do you think it would be worth it? For that matter, I wasn't aware that anyone other than Ubuntu's graphical boot is using it --- I have no idea why systemd-fsck would care about the progress bar information, and how or why it might be using it in the first place. It writes a completion percentage to the console. As for why it doesn't just use -C0, I don't know. All the best, Cedric. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775234: /sbin/e2fsck: systemd boot will hang if e2fsck-based logging is enabled
Package: e2fsprogs
Version: 1.42.12-1
Severity: important
File: /sbin/e2fsck
Tags: upstream
Greetings,
While migrating to Jessie (debootstrap + pick-and-choose from old Wheezy's
/etc), I stumbled on the boot process freezing between mounting / and the
other filesystems.
I eventually traced it to the systemd-fsck-root service hanging if
/etc/e2fsck.conf specifies logging to a yet-unmounted directory. I think
it is an fd leak similar to bug #682592:
* systemd-fsck forks fsck with argument -Cn, with fd n being one end
of a pipe which systemd uses to read progress information.
* systemd-fsck attempts to read from pipe until EOF (systemd source file
src/fsck/fsck.c, function process_progress).
* fsck forks e2fsck (actually fsck.ext4), which needs fd n.
* e2fsck forks/detaches a child to wait until directory mounted/writable,
without closing fd n.
* e2fsck and fsck terminate, e2fsck child waits for boot to complete,
systemd-fsck waits for pipe to be closed, deadlock.
Workaround: disable e2fsck logging.
strace logs attached, obtained by copying
/lib/systemd/system/systemd-fsck-root.service to /etc/systemd/system/
and replacing ExecStart=/lib/systemd/systemd-fsck with
ExecStart=strace -ff -o /run/logfile /lib/systemd/systemd-fsck, then
using systemd's debug shell on tty9 to copy /run/logfile.* elsewhere
and kill -1'ing waiting e2fsck processes to complete the boot.
I put the severity as important because it can unexpectedly leave the
system unbootable (not even in single-user mode).
Thanks in advance,
Cedric Ware.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages e2fsprogs depends on:
ii e2fslibs1.42.12-1
ii libblkid1 2.25.2-4
ii libc6 2.19-13
ii libcomerr2 1.42.12-1
ii libss2 1.42.12-1
ii libuuid12.25.2-4
ii util-linux 2.25.2-4
e2fsprogs recommends no packages.
Versions of packages e2fsprogs suggests:
pn e2fsck-static none
pn gpart none
ii parted 3.2-6
-- no debconf information
execve(/lib/systemd/systemd-fsck, [/lib/systemd/systemd-fsck], [/* 1 var
*/]) = 0
brk(0) = 0x7f991e592000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f991dd4b000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=94739, ...}) = 0
mmap(NULL, 94739, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f991dd33000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/x86_64-linux-gnu/libpthread.so.0, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\20o\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=137440, ...}) = 0
mmap(NULL, 2213008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f991d91
mprotect(0x7f991d928000, 2093056, PROT_NONE) = 0
mmap(0x7f991db27000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f991db27000
mmap(0x7f991db29000, 13456, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f991db29000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0P\34\2\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1729984, ...}) = 0
mmap(NULL, 3836448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f991d567000
mprotect(0x7f991d706000, 2097152, PROT_NONE) = 0
mmap(0x7f991d906000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19f000) = 0x7f991d906000
mmap(0x7f991d90c000, 14880, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f991d90c000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f991dd32000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f991dd3
arch_prctl(ARCH_SET_FS, 0x7f991dd30780) = 0
mprotect(0x7f991d906000, 16384, PROT_READ) = 0
mprotect(0x7f991db27000, 4096, PROT_READ) = 0
mprotect(0x7f991df8a000, 12288, PROT_READ) = 0
mprotect(0x7f991dd4d000, 4096, PROT_READ) = 0
munmap(0x7f991dd33000, 94739) = 0
set_tid_address(0x7f991dd30a50) = 253
set_robust_list(0x7f991dd30a60, 24) = 0
rt_sigaction(SIGRTMIN, {0x7f991d9169f0, [], SA_RESTORER|SA_SIGINFO
Bug#427553: diploma: please support TeXLive
Package: diploma Version: 1.2.6 Hello, The diploma package depends on tetex-extra, which makes it incompatible with TeXLive. Yet it seems to compile well with TeXLive. If I'm not mistaken, it requires only the latex executable and graphicx.sty, which are included in texlive-base-bin and texlive-latex-base respectively. Therefore, I believe that diploma should depend on (tetex-extra OR texlive-latex-base) AND (tetex-bin OR texlive-base-bin), not just tetex-extra. Thank you, Cedric Ware. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326188: gnupg should not access keyring for symmetric encryption
Package: gnupg Version: 1.4.1-1 Hello, When using gpg for symmetric encryption/decryption, the key is deduced from a passphrase; it has no need to access pubring and secring. If, in addition, the options --no-options --no-random-seed-file are used, there is no need at all to access $HOME/.gnupg. Yet gpg does. For encryption, one can add --no-default-keyring --keyring /dev/null but this is a workaround. (It relates to bug 200183.) For decryption, I have not found any way to prevent gpg from trying to access the secring. With --lock-never --homedir /nowhere, it will neither read nor create anything sensitive, but it will report errors. This may be related to bug 67564, except that the justification given (that secring is needed to know how trusted the key is) does not apply. This is a problem for automated system administration scripts which need to use gpg for encryption, depending on whether the user they run as has a home directory. One can work around it by creating temporary directories each time gpg is run, but IMNSHO it would be better if it did not attempt to access files unnecessarily in the first place... Thank you, Cedric Ware. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
