Bug#885243: libgaminggear: FTBFS on non-Linux: Neither uhid nor uinput was found
Source: libgaminggear Version: 0.15.1-2 Severity: important Justification: fails to build from source User: debian-hurd@lists.debian.org Usertags: hurd-i386 Builds of libgaminggear for (non-release) non-Linux architectures (hurd-i386 so far, presumably also kfreebsd-*) have been failing: CMake Error at CMakeLists.txt:39 (MESSAGE): Neither uhid nor uinput was found If support for these Linux APIs is essential, please formally restrict the package's architecture to linux-any accordingly, so that other architectures' autobuilders 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#885246: peewee: FTBFS on hurd-i386: sqlite3.OperationalError: database is locked
Source: peewee Version: 2.10.2+dfsg-2 Severity: important Tags: upstream Justification: fails to build from source User: debian-hurd@lists.debian.org Usertags: hurd-i386 The build of peewee for hurd-i386 (admittedly not a release architecture) failed with test suite errors boiling down to sqlite3.OperationalError: database is locked as detailed at https://buildd.debian.org/status/fetch.php?pkg=peewee&arch=hurd-i386&ver=2.10.2%2Bdfsg-2&stamp=1513960535&raw=0. Could you please take a look? 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#885248: syslog-ng: FTBFS on hurd-i386: typos in get_path_max
Source: syslog-ng
Version: 3.13.2-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
Builds of syslog-ng for hurd-i386 (admittedly not a release
architecture) have been failing lately:
/<>/debian/build-tree/../../modules/affile/directory-monitor.c:
In function 'get_path_max':
/<>/debian/build-tree/../../modules/affile/directory-monitor.c:87:11:
error: 'pathmax' undeclared (first use in this function); did you mean
'path_max'?
pathmax++;
^~~
path_max
/<>/debian/build-tree/../../modules/affile/directory-monitor.c:87:11:
note: each undeclared identifier is reported only once for each function it
appears in
/<>/debian/build-tree/../../modules/affile/directory-monitor.c:126:1:
error: invalid storage class for function '_get_real_path'
[...]
It's great that directory-monitor.c already attempts to accommodate
systems like the Hurd with no fixed PATH_MAX, but there are a couple
of typos in the relevant code. Please try removing the unbalanced
(and unneeded) { on line 65 and fixing the spelling of path_max on
line 87.
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#885249: yoshimi: FTBFS on hurd-i386: PATH_MAX undeclared
Source: yoshimi Version: 1.5.6-2 Severity: important Tags: upstream Justification: fails to build from source User: debian-hurd@lists.debian.org Usertags: hurd-i386 Builds of yoshimi for hurd-i386 (admittedly not a release architecture) have been failing: /<>/src/Misc/MiscFuncs.cpp: In member function 'std::__cxx11::string MiscFuncs::localPath(std::__cxx11::string)': /<>/src/Misc/MiscFuncs.cpp:343:29: error: 'PATH_MAX' was not declared in this scope The Hurd notoriously has no static PATH_MAX. Best practice is to accommodate whatever you actually encounter (with the help of, e.g., the GNU libc extension get_current_dir_name); alternatively, you can look up _PC_PATH_MAX via pathconf or supply a fallback constant (traditionally 4096). Could you please take a look? 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
