Bug#1012789: Can you check if Img works at all?
Thanks for tryting LinuxCNC on aarch64. I don't know of anyone presently using such a configuration. As far as the "undefined symbol" message: Please check whether in "wish", it works to "package require Img" or whether the same error occurs. If it's the same error then may point to a general problem between libtk-img and libtiff. As far as the "LIBGL: Error while gathering supported extension (eglInitialize: EGL_BAD_DISPLAY), default to none" message: Most UIs for LinuxCNC require working OpenGL. You can try a different UI such as tklinuxcnc, it doesn't use OpenGL and probably also doesn't use Img. However, it's much less friendly (IMO) Jeff
Bug#867282: live-wrapper: Lacks dependency on squashfs-tools
Package: live-wrapper Version: 0.6+nmu1 Severity: serious Justification: Policy 3.5 Dear Maintainer, Hi. after installing live-wrapper with --no-install-recommends, it does not function properly, eventually issuing an error that /tmp/.../live can not be found. I believe that this is because it does not depend on squashfs-tools to provide the "mksquashfs" program. This dependency bug is often not visible, because "mksquashfs" is a recommends, but not a depends, of vmdebootstrap. Specifically, I created a new stretch schroot, then inside it I ran 'apt install live-wrapper --no-install-recommends', and then 'lwr'. The eventual failure looked something like this: File "/usr/lib/python2.7/dist-packages/lwr/vm.py", line 66, in detect_kernels filenames = os.listdir(os.path.join(cdroot, "live")) OSError: [Errno 2] No such file or directory: '/tmp/tmpZDO8j6/live' Thanks for your attention to this matter, Jeff -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-rt-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages live-wrapper depends on: ii debian-archive-keyring 2017.5 ii isolinux3:6.03+dfsg-14.1 ii python 2.7.13-2 ii python-apt 1.4.0~beta3 ii python-cliapp 1.20160724-2 ii python-distro-info 0.14 ii python-pycurl 7.43.0-2 ii python-requests 2.12.4-1 ii vmdebootstrap 1.7-1 ii xorriso 1.4.6-1+b1 live-wrapper recommends no packages. Versions of packages live-wrapper suggests: pn cmdtest -- no debconf information
Bug#750870: Proposed OpenSSL linking exception
In the thread ITP: libressl, the OpenSSL linking exception was discussed. This is of great interest to people who would think that LibreSSL may be a long-term viable fork of OpenSSL, because many statements of the OpenSSL exception do not explicitly to permit linking with modified and/or renamed versions of OpenSSL. It would be better if their wording did explicitly permit this. However, as Joey Hess noted, in practice Debian already treats any OpenSSL linking exception as allowing linking of Debian's modified version of OpenSSL. [summarizing https://lists.debian.org/debian-devel/2014/07/msg00564.html] In any case, your upstream might consider this exception, which can be found in at least wget and GnuPG: | In addition, as a special exception, copyright holder gives permission to | link the code of project with the OpenSSL project's OpenSSL library (or | with modified versions of it that use the same license as the OpenSSL | library), and distribute the linked executables. You must obey the GNU General | Public License in all respects for all of the code used other than OpenSSL. | If you modify this file, you may extend this exception to your version of the | file, but you are not obligated to do so. If you do not wish to do so, delete | this exception statement from your version. [from http://mid.gmane.org/20140722013130.GA14673%40gauss.olasd.eu] Jeff -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628383: [kfreebsd-*] test failure: test-secmem
Apparently freebsd kernels 9.2 and later have security.bsd.unprivileged_mlock, which appears to default to permitted. http://www.freebsd.org/cgi/man.cgi?query=mlocksektion=2manpath=FreeBSD+9.2-RELEASE http://marc.info/?l=freebsd-archm=134617193210756 Is this test failure happening with kernel 9.2? I can't see that in the buildd logs. I only have a 9.0 kernel to test on... Jeff -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707733: pygobject: FTBFS on kfreebsd
Another bug that may be similar: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671785 In that bug I remark that a problem with pthread_mutex_unlock can be observed on linux with valgrind --tool=helgrind. I haven't tried to determine whether it's a similar problem here, but it might be worth valgrinding it on Linux. (unfortunately I can't do this at the moment; if I get a chance I'll report the results here) Jeff signature.asc Description: Digital signature
Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation
On Sun, Mar 03, 2013 at 12:20:57PM +, Steven Chamberlain wrote:
#5 0x000800d21f2c in *__GI___libc_free (mem=optimized out) at
malloc.c:3736
ar_ptr = 0x800ff3240
p = optimized out
#6 0x000800844a79 in gvFreeContext () from /usr/lib/libgvc.so.5
No symbol table info available.
#7 0x00400fd8 in ?? ()
No symbol table info available.
#8 0x00080389bf04 in __pthread_sighandler
As many of you are probably aware, it's not permitted in POSIX to call free()
in signal handler context without some additional guarantees about what the
interrupted function may be.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
(search for async-signal-safe)
It looks like this is what will happen when sending ctrl-c, though.
That's why a hang can be provoked in this way.
static void intr(int s)
{
/* if interrupted we try to produce a partial rendering before exiting */
if (G)
gvRenderJobs(Gvc, G);
/* Note that we don't call gvFinalize() so that we don't start event-driven
* devices like -Tgtk or -Txlib */
exit (gvFreeContext(Gvc));
}
... and in main():
signal(SIGINT, intr);
for that matter, whatever gvRenderJobs is intended to do is likely hard
to guarantee to be only doing async-signal-safe things (let alone things that
are data-structure safe). Indeed, I got a sigsegv when sending SIGINT exactly
when the first free inside gvLayoutJobs is holding the lock:
Breakpoint 3, 0x000800843b50 in gvLayoutJobs () from /usr/lib/libgvc.so.5
(gdb) ena 2
(gdb) c
Continuing.
Breakpoint 2, *__GI___libc_free (mem=0x61d940) at malloc.c:3736
3736in malloc.c
(gdb) signal 2
Continuing with signal SIGINT.
Program received signal SIGSEGV, Segmentation fault.
0x000800867778 in ?? () from /usr/lib/libgvc.so.5
(gdb) where
#0 0x000800867778 in ?? () from /usr/lib/libgvc.so.5
#1 0x000800870811 in ?? () from /usr/lib/libgvc.so.5
#2 0x000800873efd in emit_graph () from /usr/lib/libgvc.so.5
#3 0x000800875c9a in gvRenderJobs () from /usr/lib/libgvc.so.5
#4 0x00400fcc in ?? ()
#5 0x00080389bf04 in __pthread_sighandler (signo=6550134, _code=0,
_sg=0x80063f276, ctx=0xa) at sighandler.c:39
#6 0x7083 in ?? ()
#7 0x00080389be60 in ?? () at internals.h:545
from /lib/x86_64-kfreebsd-gnu/libpthread.so.0
#8 0x in ?? ()
possibly getting the segv is more common than the hang? I haven't managed to
get the hang once using this break-and-signal-in-gdb methodology (amd64
kfreebsd sid/wheezy).
Jeff
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698102: eglibc: initgroups changes egid on kfreebsd
Michael, For now it sounds like there's no consensus that this is a bug in initgroups(3) in eglibc or setgroups(2) in kfreebsd. If you're aware of this leading to a bug in a specific Debian package (particularly if it is a bug with a security impact), please file a bug against that package. Jeff -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698102: eglibc: initgroups changes egid on kfreebsd
I've reworked the test program as follows:
#include stdio.h
#include stdlib.h
#include unistd.h
#define NGROUPS 32
void call() {
gid_t groups[NGROUPS];
int ngroups = getgroups(NGROUPS, groups), i;
printf(gid = %d egid = %d groups =, (int) getgid(), (int)
getegid());
for(i =0; i ngroups; i++) printf( %d, (int) groups[i]);
printf(\n);
}
int main(void) {
gid_t groups[] = {1, 2};
call();
setgroups(2, groups);
call();
setgid(groups[0]);
call();
setuid(groups[0]);
call();
}
now the dependence on glibc initgroups() is removed.
On FreeBSD and kFreeBSD, the first group passed to setgroups becomes the
effective group ID. On Linux, it does not:
kfreebsd# gcc test.c ./a.out
gid = 0 egid = 0 groups = 0
gid = 0 egid = 1 groups = 1 2
gid = 1 egid = 1 groups = 1 2
gid = 1 egid = 1 groups = 1 2
freebsd9chroot# gcc test.c ./a.out
gid = 0 egid = 0 groups = 0
gid = 0 egid = 1 groups = 1 2
gid = 1 egid = 1 groups = 1 2
gid = 1 egid = 1 groups = 1 2
linux# gcc test.c sudo ./a.out
gid = 0 egid = 0 groups = 0
gid = 0 egid = 0 groups = 1 2
gid = 1 egid = 1 groups = 1 2
gid = 1 egid = 1 groups = 1 2
The original program in freebsd9chroot (modified to use a different
username):
# ./a.out
pw_name=jepler
pw_uid=1001
pw_gid=1001
uid=0(root) gid=0(wheel) groups=0(wheel)
uid=0(root) gid=0(wheel) egid=1001(jepler) groups=1001(jepler),5(operator)
uid=0(root) gid=0(wheel) egid=1001(jepler) groups=1001(jepler),5(operator)
uid=1001(jepler) gid=1001(jepler) groups=1001(jepler),5(operator)
Unfortuantely, POSIX declined to specify setgroups() and initgroups() is
not in any standard, so it's hard to say which behavior is right and
which is wrong. It seems possible to argue any of the following:
1. The bug is in kFreeBSD's implementation of setgroups(), which must
be fixed so that eglibc's initgroups() implementation works as
expected.
2. The bug is in eglibc's implementation of initgroups(), which must be
fixed so that it works properly with kFreeBSD's setgroups().
3. Since both behaviors of setgroups() and initgroups() are seen in
the wild, programs that depend on the linux kernel behavior are
broken and should be fixed as they become known.
Personally I'm leaning towards 3 here, since these are buggy not only on
debian/kFreeBSD but on real FreeBSD as well.
Jeff
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685625: libgeom: may cause segfault of grub-probe
If it's a question of minimal impact to fix the specific crash that
grub-probe encounters, then there are two more minimal ways to fix this
specific problem that come to mind:
replace reallocf with realloc---but in the unlikely case that realloc
fails, it doesn't deallocate the argument (this is the point of
reallocf)
explicitly declare reallocf instead of using the bsd/ header:
void *reallocf(void *, size_t)
however, I don't think either of these is better than the approach I
originally proposed, to add a #include directive that matches the one in
the reallocf manpage that debian ships.
(dropping the -Werror= flag addition would of course make it a bit more
minimal; it might avoid an FTBFS in the future, but if it's an FTBFS
that would point right at another crashing bug, well, it might be a
bonus rather than a detriment to FTBFS)
Being unfamiliar with the culture and practices of Debian, I can't speak
to whether a more invasive ('overlay') approach is appropriate or not in
light of the present freeze, but it seems that Guillem Jover has
concerns about doing that at this moment.
The machine where I originally encountered the trouble isn't yet in
production, so if there's an alternate fix proposed soon I'll be happy
to test it out. On the other hand, I think the presence or absence of
the implicit declaration warning is enough to indicate whether the bug
is present under any given fix...
Jeff
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685625: implicit declaration of function ‘reallocf’
[snipped astute observations about the size of the xml data being important] On Fri, Dec 21, 2012 at 10:02:45PM +, Steven Chamberlain wrote: And I'm worried about some of the other packages mentioned, where the error shows on kfreebsd-* or maybe hurd-*, but not on other arches. Should they really all be doing this: ++#include bsd/stdlib.h Or should we be trying to fix this elsewhere, in GNU/kFreeBSD headers maybe? I don't know the right fix. I chose to #include bsd/stdlib.h because the manpage (on debian-kFreeBSD) lists that as the proper header: debian-kFreeBSD$ man reallocf MALLOC(3)BSD Library Functions ManualMALLOC(3) NAME reallocf — general purpose memory allocation functions LIBRARY Utility functions from BSD systems (libbsd, -lbsd) SYNOPSIS #include bsd/stdlib.h void * reallocf(void *ptr, size_t size); I notice now that the guidance in the FreeBSD project's manpage is to simply include stdlib.h for the declaration of reallocf: http://www.freebsd.org/cgi/man.cgi?query=reallocf Unless you were going to put reallocf in eglibc I don't think you want it in stdlib.h, since on debian-kFreeBSD use of reallocf will result in a link error without -lbsd. You can't simply make the bsd header be included via #include stdlib.h, as -I/usr/include/bsd on the gcc commandline leads to a recursive inclusion error. Jeff -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
