Re: hurd: PIE support
For information, that's the last bit that will allow us to enable pie on hurd-i386, thus fixing libgcrypt20 build, and as a consequence the whole kde set. Samuel
Bug#885012: extrace: FTBFS on non-Linux: linux/connector.h absent
Source: extrace Version: 0.4-1 Severity: important Justification: fails to build from source User: debian-hurd@lists.debian.org Usertags: hurd-i386 Builds of extrace for (non-release) non-Linux architectures (just hurd-i386 so far) have been failing: extrace.c:54:10: fatal error: linux/connector.h: No such file or directory If extrace needs Linux-specific APIs, please formally limit its Architecture field to linux-any so that autobuilders for other architectures don't bother trying to cover it. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#885013: siridb-server: FTBFS on hurd-i386: PATH_MAX undeclared
Source: siridb-server Version: 2.0.25-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-hurd@lists.debian.org Usertags: hurd-i386 The build of siridb-server for hurd-i386 (admittedly not a release architecture) failed: ../src/xpath/xpath.c: In function 'xpath_get_exec_path': ../src/xpath/xpath.c:94:42: error: 'PATH_MAX' undeclared (first use in this function); did you mean 'NAME_MAX'? The Hurd famously has no static PATH_MAX. Best practice is to work dynamically with what you encounter. However, if that's infeasible, you can also look up _PC_PATH_MAX via pathconf or supply a fallback constant (traditionally 4096). Could you please take a look, bearing in mind that there's presumably at least one more reference to PATH_MAX (in whatever calls xpath_get_exec_path)? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Bug#885011: libgio-fam: Remove this package?
[Ccing the non-Linux-kernel lists since this is to do with a package that only their ports get] On Fri, 22 Dec 2017 at 16:02:23 -0500, Jeremy Bicha wrote: > As part of Debian GNOME's svn to git conversion, it makes sense to > evaluate whether we still need deprecated and unmaintained packages in > Debian. One of those is gamin. [1] > > I see that libgio-fam is only built on hurd and kfreebsd. See > https://bugs.debian.org/526219 for some background on that. (Neither > fam nor gamin have been in Ubuntu "main" since at least 12.04. It > appears like fam/gamin was more of a gnome-vfs thing so not needed > since GNOME 3). I think you're misreading #526219, but your conclusion might be valid anyway. The goal is that GFileMonitor detects file changes without polling. On Linux, it does that without external code, because GLib has a built-in GFileMonitor backend that uses inotify. On kFreeBSD at the time of #526219, there was no built-in kqueue backend for GFileMonitor (kqueue is a FreeBSD API that provides the equivalent of Linux inotify, among other things), so FreeBSD users had to either use an external library that does know how to use kqueue (fam/gamin), or resort to periodic polling. However, modern GLib contains something called gio/kqueue/gkqueuefilemonitor.c (and according to build logs, we even build it), which suggests that a kqueue GFileMonitor might now be provided. Hopefully the kFreeBSD porters can advise whether that backend actually works, and if not, send patches upstream to fix it. The reference to gnome-vfs in #526219 was to say that unlike GFileMonitor, the equivalent of GFileMonitor in gnome-vfs didn't know how to use inotify on Linux, which is why fam/gamin used to be desirable on Linux. That is thankfully now a thing of the past, and we only keep libgio-fam for the non-Linux kernels' benefit. I don't know whether Hurd supports a file-change-monitoring API better than periodic polling; according to GLib and gamin build logs, it doesn't seem to have a Linux-compatible inotify or a FreeBSD-compatible kqueue, and I don't see any successful configure checks for anything that looks analogous. I think the options for the GNOME team are: 1. Stop building libgio-fam, and orphan gamin if it has no more GNOME rdeps (it does unfortunately have rdeps outside GNOME, notably lighttpd and libkf5coreaddons5). Hurd no longer gets to multiplex its inefficient polling through the gamin daemon (assuming I'm right in thinking that Hurd has no API for this that our libraries support), so GFileMonitor might become even less efficient on Hurd than it currently is (all processes that monitor files wake up periodically, not just the gamin daemon), but that doesn't seem a huge loss. 2. Keep building libgio-fam, but only on Hurd, and orphan gamin if it has no more GNOME rdeps; warn Hurd porters that if it becomes a maintenance problem, then libgio-fam will be removed altogether (switching to option 1). 3. Keep libgio-fam on both kFreeBSD and Hurd, and maybe orphan gamin, warning both sets of porters that if it becomes a maintenance problem. then libgio-fam will be removed (switching to option 1). This should only be done if kFreeBSD porters tell us that gamin is significantly better than gkqueuefilemonitor.c (but if that's the case, fixing gkqueuefilemonitor.c would be a better solution for the kFreeBSD people than keeping gamin, IMO). Regards, smcv
Bug#885056: gcc-7: Please enable PIE on hurd-i386
Package: gcc-7 Version: 7.2.0-18 Severity: important User: debian-hurd@lists.debian.org Usertag: hurd Hello, We have eventually fixed the issue we had with PIE: gdb support. So could you please enable PIE by default? That should fix the build of gpgme1.0, thus unlocking a lot of packages. Samuel -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcc-7 depends on: ii binutils 2.29.1-12 ii cpp-7 7.2.0-18 ii gcc-7-base7.2.0-18 ii libc6 2.25-3 ii libcc1-0 8-20171102-1 ii libgcc-7-dev 7.2.0-18 ii libgcc1 1:8-20171102-1 ii libgmp10 2:6.1.2+dfsg-1.1 ii libisl15 0.18-1 ii libmpc3 1.0.3-2 ii libmpfr4 3.1.6-1 ii libstdc++68-20171102-1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages gcc-7 recommends: ii libc6-dev 2.25-3 Versions of packages gcc-7 suggests: ii gcc-7-doc 7.2.0-1 pn gcc-7-locales ii gcc-7-multilib7.2.0-18 pn libasan4-dbg pn libatomic1-dbg pn libcilkrts5-dbg pn libgcc1-dbg pn libgomp1-dbg pn libitm1-dbg pn liblsan0-dbg pn libmpx2-dbg pn libquadmath0-dbg pn libtsan0-dbg pn libubsan0-dbg -- no debconf information -- Samuel update-menus: relocation error: update-menus: symbol _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E, version GLIBCPP_3.2 not defined in file libstdc++.so.5 with link time reference quoi que ça peut bien vouloir dire ? N a eu la meme merde c ça que ça veut dire ? wow, c'est bien crypté :) -+- #ens-mim s'entraide -+-
