Re: audiofile: FTBFS on hurd-i386 (for review)
On 2014-06-02 23:55, Svante Signell wrote: Source: audiofile Version: 0.3.6-2 Severity: important Tags: patch User: debian-hurd@lists.debian.org Usertags: hurd Hi, Currently audiofile fails to build from source due to usage of PATH_MAX, which is not defined on GNU/Hurd. The attached patch solve this problem by dynamically allocating space for the string 'path' in function createTemporaryFile() of test/TestUtilities.cpp and freeing it in the calling functions when not needed any longer. All 36 tests needed for the build pass. Already fixed upstream for more than one year: https://github.com/mpruett/audiofile/commit/34c261034f1193a783196618f0052112e00fbcfe Upstream has just not released a new version since then. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f0156b013621afba1fd40e509d7c6...@pino.toscano.name
audiofile: FTBFS on hurd-i386 (for review)
Source: audiofile
Version: 0.3.6-2
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
Hi,
Currently audiofile fails to build from source due to usage of
PATH_MAX, which is not defined on GNU/Hurd. The attached patch solve
this problem by dynamically allocating space for the string 'path' in
function createTemporaryFile() of test/TestUtilities.cpp and freeing it
in the calling functions when not needed any longer. All 36 tests needed
for the build pass.
Thanks!
Index: audiofile-0.3.6/test/TestUtilities.h
===
--- audiofile-0.3.6.orig/test/TestUtilities.h
+++ audiofile-0.3.6/test/TestUtilities.h
@@ -53,7 +53,7 @@ extern "C" {
#include
-bool createTemporaryFile(const char *prefix, char *path);
+bool createTemporaryFile(const char *prefix, char **path);
#ifdef __cplusplus
}
Index: audiofile-0.3.6/test/TestUtilities.cpp
===
--- audiofile-0.3.6.orig/test/TestUtilities.cpp
+++ audiofile-0.3.6/test/TestUtilities.cpp
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
bool createTemporaryFile(const std::string &prefix, std::string *path)
{
@@ -35,10 +36,14 @@ bool createTemporaryFile(const std::stri
return true;
}
-bool createTemporaryFile(const char *prefix, char *path)
+bool createTemporaryFile(const char *prefix, char **path)
{
- snprintf(path, PATH_MAX, "/tmp/%s-XX", prefix);
- int fd = ::mkstemp(path);
+ int len = 5 + strlen(prefix) + 7 + 1;
+ *path = (char*)malloc(len);
+ if (*path == NULL)
+ return false;
+ snprintf(*path, len, "/tmp/%s-XX", prefix);
+ int fd = ::mkstemp(*path);
if (fd < 0)
return false;
::close(fd);
Index: audiofile-0.3.6/test/floatto24.c
===
--- audiofile-0.3.6.orig/test/floatto24.c
+++ audiofile-0.3.6/test/floatto24.c
@@ -86,8 +86,9 @@ int main (int argc, char **argv)
afInitChannels(setup, AF_DEFAULT_TRACK, 1);
afInitSampleFormat(setup, AF_DEFAULT_TRACK, AF_SAMPFMT_FLOAT, 32);
- char testFileName[PATH_MAX];
- if (!createTemporaryFile("floatto24", testFileName))
+ /* testFilename is malloced in createTemporaryFile() */
+ char *testFileName = NULL;
+ if (!createTemporaryFile("floatto24", &testFileName))
{
fprintf(stderr, "Could not create temporary file.\n");
exit(EXIT_FAILURE);
@@ -182,6 +183,7 @@ int main (int argc, char **argv)
}
unlink(testFileName);
+ free(testFileName);
exit(EXIT_SUCCESS);
}
Index: audiofile-0.3.6/test/sixteen-to-eight.c
===
--- audiofile-0.3.6.orig/test/sixteen-to-eight.c
+++ audiofile-0.3.6/test/sixteen-to-eight.c
@@ -57,8 +57,9 @@ int main (int argc, char **argv)
afInitSampleFormat(setup, AF_DEFAULT_TRACK, AF_SAMPFMT_UNSIGNED, 8);
afInitChannels(setup, AF_DEFAULT_TRACK, 1);
- char testFileName[PATH_MAX];
- if (!createTemporaryFile("sixteen-to-eight", testFileName))
+ /* testFilename is malloced in createTemporaryFile() */
+ char *testFileName = NULL;
+ if (!createTemporaryFile("sixteen-to-eight", &testFileName))
{
fprintf(stderr, "Could not create temporary file.\n");
exit(EXIT_FAILURE);
@@ -113,6 +114,7 @@ int main (int argc, char **argv)
afCloseFile(file);
unlink(testFileName);
+ free(testFileName);
exit(EXIT_SUCCESS);
}
Index: audiofile-0.3.6/test/testchannelmatrix.c
===
--- audiofile-0.3.6.orig/test/testchannelmatrix.c
+++ audiofile-0.3.6/test/testchannelmatrix.c
@@ -39,7 +39,8 @@
#include "TestUtilities.h"
-static char sTestFileName[PATH_MAX];
+/* sTestFilename is malloced in createTemporaryFile() */
+static char *sTestFileName = NULL;
const short samples[] = {300, -300, 515, -515, 2315, -2315, 9154, -9154};
#define SAMPLE_COUNT (sizeof (samples) / sizeof (short))
@@ -48,6 +49,7 @@ const short samples[] = {300, -300, 515,
void cleanup (void)
{
unlink(sTestFileName);
+ free(sTestFileName);
}
void ensure (int condition, const char *message)
@@ -76,7 +78,7 @@ int main (void)
afInitFileFormat(setup, AF_FILE_AIFFC);
/* Write stereo data to test file. */
- ensure(createTemporaryFile("testchannelmatrix", sTestFileName),
+ ensure(createTemporaryFile("testchannelmatrix", &sTestFileName),
"could not create temporary file");
file = afOpenFile(sTestFileName, "w", setup);
ensure(file != AF_NULL_FILEHANDLE, "could not open file for writing");
Index: audiofile-0.3.6/test/testdouble.c
===
--- audiofile-0.3.6.orig/test/testdouble.c
+++ audiofile-0.3.6/test/testdouble.c
@@ -38,7 +38,8 @@
#include "TestUtilities.h"
-static char sTestFileName[PATH_MAX];
+/* sTestFilename is malloced in createTemporaryFile() */
+static char *sTestFileName = NULL;
const double samples[] =
{1.0, 0.6, -0.3, 0.95, 0.2, -0.6, 0.9, 0.4, -0.22, 0.125, 0.1, -0.4
Re: please remove kfreebsd-any from Architecture
Hi Emilio, On 02/06/14 19:13, Emilio Pozuelo Monfort wrote: > May I ask what was broken on gdm3 and gnome-shell to have caused all these > removals? Note that there are efforts upstream to port GNOME to BSD. Was > there a > bug or bugs in gnome-shell and/or gdm3 that led to this? Sometime during the flamewar it was claimed that they wouldn't function properly without systemd for the jessie release. I'm aware of heroic efforts by the BSDs and some GNOME developers[0] to try to keep it working - I don't this work has caught up with 3.12 yet. The 3.13.2 release notes[1] announced that a 'temporary' dependency on systemd had been introduced. [0]: http://undeadly.org/cgi?action=article&sid=20140219085851 [1]: https://mail.gnome.org/archives/gnome-announce-list/2014-May/msg00034.html But there are recent statements from Debian GNOME maintainers that they wouldn't support such a configuration either way: On Mon, 12 May 2014 11:54:43 +0200, Josselin Mouette wrote: > As far as GDM is concerned, any bug reported with systemd-shim installed > will be ignored. The bug script should probably be updated to that > effect, BTW. https://lists.debian.org/debian-devel/2014/05/msg00477.html Also related, I suspect there was pressure being exerted on the release team to try to disqualify kfreebsd as a release arch entirely. Agreeing to drop GNOME was something of a compromise I think. We still see conflicts with some GNOME maintainers even over trivial issues, making it difficult to collaborate: http://lists.debian.org/20140531155148.ga26...@fatal.se (rude answer, which still didn't address key questions asked) http://lists.debian.org/20140602121342.ga13...@fatal.se (dismissed my concerns over gnoem-terminal Build-Depends: gnome-shell [requiring whole GNOME desktop to build it] with "random ramblings removed") So I think there are mostly human rather than technical reasons. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538cc7ea.20...@pyro.eu.org
Re: please remove kfreebsd-any from Architecture
On 02/06/14 19:56, Steven Chamberlain wrote: > Hi Robert, > > On 02/06/14 14:36, Adam D. Barratt wrote: >> There's also gnome-session. gnome-core depends on gnome-session, which >> in turn depends on gnome-shell. > > We'll need to make gnome-session Architecture: linux-any and remove it. > > And I wonder if we could adjust gnome-core's dependency from: > gnome-session (>= 3.4), > > to: > gnome-session (>= 3.4) [linux-any], > gnome-session-bin (>= 3.4) [!linux-any], > > That keeps it installable as a metapackage of "the remaining core bits > of GNOME not needing systemd" which could be useful information. The > alternative is to make it linux-any and remove it. > > I think these are the last bits of the dependency chain, > (gnome-shell + gdm3 < gnome-core < gnome-session), except for some > arch:all packages which don't matter for testing migration. May I ask what was broken on gdm3 and gnome-shell to have caused all these removals? Note that there are efforts upstream to port GNOME to BSD. Was there a bug or bugs in gnome-shell and/or gdm3 that led to this? Sincerely, Emilio -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538cbebd.1040...@debian.org
Re: please remove kfreebsd-any from Architecture
Hi Robert, On 02/06/14 14:36, Adam D. Barratt wrote: > There's also gnome-session. gnome-core depends on gnome-session, which > in turn depends on gnome-shell. We'll need to make gnome-session Architecture: linux-any and remove it. And I wonder if we could adjust gnome-core's dependency from: gnome-session (>= 3.4), to: gnome-session (>= 3.4) [linux-any], gnome-session-bin (>= 3.4) [!linux-any], That keeps it installable as a metapackage of "the remaining core bits of GNOME not needing systemd" which could be useful information. The alternative is to make it linux-any and remove it. I think these are the last bits of the dependency chain, (gnome-shell + gdm3 < gnome-core < gnome-session), except for some arch:all packages which don't matter for testing migration. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538cbab4.1040...@pyro.eu.org
Re: Bug#749685: morse-simulator: FTBFS on Kfreebsd - Blocking python3.4 as default python3
Am 01.06.2014 18:28, schrieb Emilio Pozuelo Monfort:
> On 01/06/14 12:13, Sebastian Ramacher wrote:
>> On 2014-05-29 00:55:09, Scott Kitterman wrote:
>>> Source: morse-simulator
>>> Version: 1.2-2
>>> Severity: serious
>>> Justification: fails to build from source (but built successfully in the
>>> past)
>>>
>>> FTBFS on both Kfreebsd i386 and amd64. The end of the build log looks like:
>>>
>>> reading sources... [ 12%] media
>>> reading sources... [ 12%] morse
>>> reading sources... [ 13%] multinode
>>> reading sources... [ 13%] pymorse
>>> [error] install python-concurrent.futures
>>> make[3]: *** [CMakeFiles/doc] Error 1
>>> CMakeFiles/doc.dir/build.make:52: recipe for target 'CMakeFiles/doc' failed
>>> make[3]: Leaving directory '/«PKGBUILDDIR»/obj-i486-kfreebsd-gnu'
>>> CMakeFiles/Makefile2:967: recipe for target 'CMakeFiles/doc.dir/all' failed
>>> make[2]: *** [CMakeFiles/doc.dir/all] Error 2
>>> make[2]: Leaving directory '/«PKGBUILDDIR»/obj-i486-kfreebsd-gnu'
>>> make[1]: *** [all] Error 2
>>> Makefile:126: recipe for target 'all' failed
>>> make[1]: Leaving directory '/«PKGBUILDDIR»/obj-i486-kfreebsd-gnu'
>>> dh_auto_build: make -j1 returned exit code 2
>>> make: *** [build-arch] Error 2
>>> debian/rules:8: recipe for target 'build-arch' failed
>>> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
>>>
>>> While this is not new (it's three months old), it's now blocking getting
>>> packages rebuilt for python3.4 as default python3 (See #746709).
>>
>> The issue here is that importing concurrent.futures fails.
>> morse-simulator tries to import ThreadPoolExectur and Future from
>> concurrent.futures. On falla, this fails with
>>
>> % python3 -c "from concurrent.futures import ThreadPoolExecutor, Future"
>> Traceback (most recent call last):
>> File "", line 1, in
>> File "/usr/lib/python3.4/concurrent/futures/__init__.py", line 17, in
>>
>> from concurrent.futures.process import ProcessPoolExecutor
>> File "/usr/lib/python3.4/concurrent/futures/process.py", line 55, in
>>
>> from multiprocessing.connection import wait
>> File "/usr/lib/python3.4/multiprocessing/connection.py", line 21, in
>>
>> import _multiprocessing
>> ImportError: No module named '_multiprocessing'
>>
>> Adding python-concurrent.futures to Build-Depends didn't help because
>> it is the backport of concurrent.futures for Python 2. Python >= 3.2 (I
>> think, or maybe >= 3.3) provides concurrent.futures in the standard lib.
>>
>> This looks like a python3.4 bug to me, but someone with more knowledge
>> of concurrent.futures needs to decide that.
>
> I think the problem (or at least one of them) is this:
>
> (sid_kfreebsd-amd64-dchroot)pochu@falla:~$ dpkg -L libpython3.3-stdlib | grep
> multiprocessing.cpython
> /usr/lib/python3.3/lib-dynload/_multiprocessing.cpython-33m-x86_64-kfreebsd-gnu.so
> (sid_kfreebsd-amd64-dchroot)pochu@falla:~$ dpkg -L libpython3.4-stdlib | grep
> multiprocessing.cpython
> (sid_kfreebsd-amd64-dchroot)pochu@falla:~$
>
> That's why importing _multiprocessing fails with python3.4.
>
> That is not shipped because of this: (from
> https://buildd.debian.org/status/fetch.php?pkg=python3.4&arch=kfreebsd-amd64&ver=3.4.1-1&stamp=1400800890
> )
>
> *** WARNING: renaming "_multiprocessing" since importing it failed:
> build/lib.gnukfreebsd-9.0-2-amd64-x86_64-3.4/_multiprocessing.cpython-34m.so:
> undefined symbol: _PyMp_sem_unlink
> [...]
> find debian/tmp/usr/lib/python3.4 -name '*_failed*.so'
> debian/tmp/usr/lib/python3.4/lib-dynload/_multiprocessing.cpython-34m_failed.so
>
>
> _PyMp_sem_unlink is defined in semaphore.c. setup.py has:
>
> if host_platform == 'win32':
> multiprocessing_srcs = [ '_multiprocessing/multiprocessing.c',
> '_multiprocessing/semaphore.c',
>]
>
> else:
> multiprocessing_srcs = [ '_multiprocessing/multiprocessing.c',
>]
> if (sysconfig.get_config_var('HAVE_SEM_OPEN') and not
> sysconfig.get_config_var('POSIX_SEMAPHORES_NOT_ENABLED')):
> multiprocessing_srcs.append('_multiprocessing/semaphore.c')
>
> But the kfreebsd-amd64 build log has:
>
> /* Define to 1 if you have the `sem_open' function. */
> #define HAVE_SEM_OPEN 1
> [...]
> /* Define if POSIX semaphores aren't enabled on your system */
> #define POSIX_SEMAPHORES_NOT_ENABLED 1
>
> Thus semaphore.c is not built (as can be verified by looking for "semaphore.c"
> in the log), and we get that undefined symbol.
>
> (The same thing happens on hurd).
>
> I'm not sure if the file should be built on kfreebsd/hurd, or if it shouldn't
> but there should be some fallback code in python3.4. Adding the python
> maintainer, and the bsd and hurd porters to Cc.
checking on falla, the failing autoconf test is
#include
#include
#include
#include
#include
int main(void) {
sem_t *a = sem_open
Error with running the image
I run into a critical error whenever I try to run the pre-installed image using the method described in the README[1]. Grub runs just fine but when it tries to load hurd I run into an error equal to the one described by Neil McGovern when running the installer from virtualbox[2]. This is my second attempt at this problem, previously I tried both the CD and the pre-installed image with the same result. I've also tried running with qemu but the hurd system was extremely unstable and crashed often. My processor does not seem to support kvm. [1] - http://ftp.debian-ports.org/debian-cd/hurd-i386/current/README.txt [2] - https://lists.debian.org/debian-hurd/2013/05/msg00049.html -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538c852f.2040...@gmail.com
Re: please remove kfreebsd-any from Architecture
On Sat, 2014-05-31 at 00:42 +0200, Emilio Pozuelo Monfort wrote: > On 30/05/14 17:57, Steven Chamberlain wrote: > > On 16:01, Emilio Pozuelo Monfort wrote: > >> Just a reminder: there are still various things depending on the removed > >> packages, preventing things from migrating to testing. > > > > Do you agree it's just the two metapackages from src:meta-gnome3 that > > need changes, or is there anything else? > > > > http://lists.debian.org/53863f46.2050...@pyro.eu.org > > There's that and also #749888. I don't know if there are other things, I > haven't > looked in detail. There's also gnome-session. gnome-core depends on gnome-session, which in turn depends on gnome-shell. Regards, Adam -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401716207.4230.16.ca...@jacala.jungle.funky-badger.org
Re: gnome-terminal: FTBFS on kfreebsd & hurd archs
Andreas, Seems I need to rephrase. The kfreebsd-specific problem has been addressed. Any other problem with gnome-terminal, I don't have patience/motivation to pursue right now, due in part to: Point 1: On 02/06/14 13:13, Andreas Henriksson wrote: > On Sun, Jun 01, 2014 at 12:50:06PM +0100, Steven Chamberlain wrote: > [... random ramblings removed ...] Point 2: >> I'm assuming gnome-terminal will still run okay, or otherwise some >> Linux user can follow up on this. > [...] > > Please stop making assuptions. Point 3: > Andreas "some Linux user" Henriksson -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538c7881.1050...@pyro.eu.org
Re: gnome-terminal: FTBFS on kfreebsd & hurd archs
On Sun, Jun 01, 2014 at 12:50:06PM +0100, Steven Chamberlain wrote: [... random ramblings removed ...] > I'm assuming gnome-terminal will still run okay, or otherwise some > Linux user can follow up on this. [...] Please stop making assuptions. Instead, again, please take 2 seconds to try to look things up! If you bothered to look at (atleast the top item on): http://bugs.debian.org/gnome-terminal You'd find that the default configuration is unusable under non-GNOME (and thus now for all hurd and kfreebsd users). #683744 gnome-terminal: black-on-black text with "Use colors from system theme" under non-GNOME Patches welcome, especially from non-GNOME users! Regards, Andreas "some Linux user" Henriksson -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602121342.ga13...@fatal.se
Re: Some issues on fresh installed Debian-Hurd
Am 02.06.2014 um 12:22 schrieb Justus Winter <4win...@informatik.uni-hamburg.de>: > Quoting Jens Rehsack (2014-06-02 11:46:10) >> Am 02.06.2014 um 11:21 schrieb Justus Winter >> <4win...@informatik.uni-hamburg.de>: >> >> [...] >> Ok - what I was talking about (and I'm sure the installer named it kernel or >> with a similar term) was >> >> gnumach-image-1.3.99-486 vs. gnumach-image-1.4-486 > > Fair enough. Gnumach is our kernel allright. I wonder why 1.3.99 is > still available. Samuel? > > `> [...] >>> >>> No it's not. Apparently, 'c' is a valid identifier. If you have no >>> getty for the console, please add it. ttyX is used when the Hurd >>> console is running, 'console' refers to the mach console. >> >> Added and there is a login :) > > Good. That means (most likely), that your hurd console isn't running. Didn't got installed ... Now it's running ;) >> From original mail now only the nfs issue remains. > > Our nfs client is likely just crappy. > >> Playing around I see differences between >> >> $ mount # no output, returns immediately >> # mount >> typed:device:hd0s1 on / type ext2fs (rw,no-inherit-dir-group) >> # cat /proc/mounts >> /dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0 >> none /run /hurd/tmpfs >> writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=102148K 0 0 >> none /run/lock /hurd/tmpfs >> writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=5M 0 0 >> none /run/shm /hurd/tmpfs >> writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=613980K 0 0 >> waldorf:/data/pkgsrc /data/pkgsrc /hurd/nfs >> hard,read-size=8192,write-size=8192,stat-timeout=3,cache-timeout=3,init-transmit-timeout=1,max-transmit-timeout=30,name-cache-timeout=3,name-cache-neg-timeout=3 >> 0 0 >> >> Is there any reason for it? > > Hurd's mount simply does not work like Linux' mount. Our mount > doesn't parse /proc/mounts. It should do so, if only to avoid this > reoccurring confusion. > >> BTW: why I initially assumed the is a problem with the way mounting /proc: >> >> # top >> Error, do this: mount -t proc proc /proc > > At this point, did you verify that /proc is mounted at all? > > But indeed: > > $ mount -t proc proc ./foo > procfs: Too many arguments > Try `procfs --help' or `procfs --usage' for more information. > mount: cannot start translator /hurd/procfs: Translator died Finally there is something - even if I don't know what: # ls -l /proc | wc -l 75 # cat /proc/1/cmdline init [2] So it seems to me something what feels like a procfs is there - but what ;) But /proc/mounts doesn't show itself (what else could be missing?) Cheers -- Jens Rehsack rehs...@gmail.com -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/37cfdd1f-585f-44c3-bed7-e202a0680...@gmail.com
Re: Some issues on fresh installed Debian-Hurd
Quoting Jens Rehsack (2014-06-02 12:28:16)
> But /proc/mounts doesn't show itself (what else could be missing?)
True. At first, we included all kinds of translators in /proc/mounts.
However, that caused severe trouble as e.g. the Debian init scripts
would umount (i.e. terminate) vital system servers on shutdown.
Therefore, we now only include real filesystems in /proc/mount. We
could show procfs there I guess, it would just have to implement the
file_get_source rpc:
teythoon@darnassus:~$ /hurd/mtab /proc
/hurd/mtab: /proc: Operation not supported
teythoon@darnassus:~$ rpctrace /hurd/mtab /proc
[...]
113<--145(pid9632)->dir_lookup ("proc" 0 420) = 0 1 ""162<--163(pid9632)
162<--163(pid9632)->dir_readdir (0 1 0) = 0x4009 (Bad file descriptor)
162<--163(pid9632)->file_get_fs_options () = 0 "/hurd/procfs"
task134(pid9632)->vm_allocate (0 43 1) = 0 204800
162<--163(pid9632)->file_get_source () = 0x402d (Operation not supported)
[...]
Justus
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140602103718.10651.20...@thinkbox.jade-hamburg.de
Re: please remove kfreebsd-any from Architecture
Hi Emilio, I'm confused why source packages gdm3 and gnome-shell didn't migrate at the same time as meta-gnome3. I can only see that they wait for each other; is there something else blocking this? Is some additional hint needed to allow removals? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538c50f9@pyro.eu.org
Re: Some issues on fresh installed Debian-Hurd
Quoting Jens Rehsack (2014-06-02 11:46:10) > Am 02.06.2014 um 11:21 schrieb Justus Winter > <4win...@informatik.uni-hamburg.de>: > > > Quoting Jens Rehsack (2014-06-02 10:58:17) > >> Am 02.06.2014 um 10:47 schrieb Justus Winter > >> <4win...@informatik.uni-hamburg.de>: > >> > >>> Hi :) > >>> > >>> Quoting Jens Rehsack (2014-06-02 08:28:50) > >>> > Beside the kernel choice the installation went smoothly (a problem > Debian-Hurd shares with Debian-kFreeBSD ^^). > >>> > >>> I don't follow. > >> > >> I most likely pebcak :) > >> Generally it's (for me) poorly documented which kernel is meant by hurd-1 > >> vs. hurd-1.3.nnn > >> I got it later by doing apt-cache search (but initial boot was with > >> 1.3.nnn) > > > > I still don't follow. Hurd is not a kernel. There is no package hurd-1 or > > hurd-1.3.nnn. > > Ok - what I was talking about (and I'm sure the installer named it kernel or > with a similar term) was > > gnumach-image-1.3.99-486 vs. gnumach-image-1.4-486 Fair enough. Gnumach is our kernel allright. I wonder why 1.3.99 is still available. Samuel? `> > >> Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is > >> favored over kernel (and which version is kernel - 8+patches, 9, ???) > >> Enlightening comes later by trying it out ... > >> > >> But beside that - Hurd installation was impressive sane for "experimental" > >> why kFreeBSD crashs because it always installs 9'er kernel (regardless the > >> choice I make at installer - but maybe PEBCAK, let's do Hurd first). > >> > I had to modify line 117 in /etc/hurd/rc: "settrans -c /proc > /hurd/procfs --compatible" -> "settrans -c /proc /hurd/procfs", > otherwise the /proc file > system didn't came up. > > That reduces the noise during boot dramatically (cannot stat /proc > or something like that). > >>> > >>> Which is very strange, as we switched to sysv-rc and don't use > >>> /etc/hurd/rc no more. Could you please double check that > >>> (e.g. update-alternatives --display runsystem should say > >>> /etc/hurd/runsystem.sysv). > >> > >> # update-alternatives --display runsystem > >> runsystem - auto mode > >> link currently points to /etc/hurd/runsystem.sysv > >> /etc/hurd/runsystem.gnu - priority 5 > >> slave halt: /sbin/halt-hurd > >> slave reboot: /sbin/reboot-hurd > >> /etc/hurd/runsystem.sysv - priority 10 > >> slave halt: /sbin/halt-sysv > >> slave reboot: /sbin/reboot-sysv > >> Current 'best' version is '/etc/hurd/runsystem.sysv'. > >> > >> I cannot say why no proc was mounted before I removed --compatible when > >> /etc/hurd/rc isn't used. > >> But it works (proved by visual examination ^^) > > > > Also, --compatible is a valid argument and it is recommended to use > > that for compatibility with Linux' /proc. There is no reason to > > believe it should cause any trouble. > > I cannot tell why it caused trouble - but now after I uninstalled > gnumach-image-1.3.99-486 the issue disappears. > > >> Maybe we should first check why /etc/hurd/rc is involved in boot-process? > > > > Yes. Add exit 0 at the top. It is not used. > > Done without harming anything - seems to have a relation to > gnumach-image-1.3.99-486 > > But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl > vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can > access remotely. I'm quite unsure if it has to do with procfs or > another issue (nothing suspicious in log or on screen) - but I'd > like to mention it. > >>> > >>> Check that the hurd console is running. Also, check that you have an > >>> entry like > >>> > >>> c:23:respawn:/sbin/getty 38400 console > >>> > >>> in your /etc/inittab to get a getty on the mach console (of course > >>> inittab is only used if you use sysvinit). > >> > >> I have some lines looking similar (was 'c' a placeholder for [1-9]?) > >> > >> 1:2345:respawn:/sbin/getty 38400 tty1 > >> 2:23:respawn:/sbin/getty 38400 tty2 > >> 3:23:respawn:/sbin/getty 38400 tty3 > > > > No it's not. Apparently, 'c' is a valid identifier. If you have no > > getty for the console, please add it. ttyX is used when the Hurd > > console is running, 'console' refers to the mach console. > > Added and there is a login :) Good. That means (most likely), that your hurd console isn't running. > From original mail now only the nfs issue remains. Our nfs client is likely just crappy. > Playing around I see differences between > > $ mount # no output, returns immediately > # mount > typed:device:hd0s1 on / type ext2fs (rw,no-inherit-dir-group) > # cat /proc/mounts > /dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0 > none /run /hurd/tmpfs > writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=102148K 0 0 > none /run/lock /hurd/tmpfs > writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=5M 0 0 > none /run/shm /hurd/tmpfs > writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=6139
Re: Some issues on fresh installed Debian-Hurd
Am 02.06.2014 um 11:21 schrieb Justus Winter <4win...@informatik.uni-hamburg.de>: > Quoting Jens Rehsack (2014-06-02 10:58:17) >> Am 02.06.2014 um 10:47 schrieb Justus Winter >> <4win...@informatik.uni-hamburg.de>: >> >>> Hi :) >>> >>> Quoting Jens Rehsack (2014-06-02 08:28:50) >>> Beside the kernel choice the installation went smoothly (a problem Debian-Hurd shares with Debian-kFreeBSD ^^). >>> >>> I don't follow. >> >> I most likely pebcak :) >> Generally it's (for me) poorly documented which kernel is meant by hurd-1 >> vs. hurd-1.3.nnn >> I got it later by doing apt-cache search (but initial boot was with 1.3.nnn) > > I still don't follow. Hurd is not a kernel. There is no package hurd-1 or > hurd-1.3.nnn. Ok - what I was talking about (and I'm sure the installer named it kernel or with a similar term) was gnumach-image-1.3.99-486 vs. gnumach-image-1.4-486 >> Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is >> favored over kernel (and which version is kernel - 8+patches, 9, ???) >> Enlightening comes later by trying it out ... >> >> But beside that - Hurd installation was impressive sane for "experimental" >> why kFreeBSD crashs because it always installs 9'er kernel (regardless the >> choice I make at installer - but maybe PEBCAK, let's do Hurd first). >> I had to modify line 117 in /etc/hurd/rc: "settrans -c /proc /hurd/procfs --compatible" -> "settrans -c /proc /hurd/procfs", otherwise the /proc file > system didn't came up. That reduces the noise during boot dramatically (cannot stat /proc or something like that). >>> >>> Which is very strange, as we switched to sysv-rc and don't use >>> /etc/hurd/rc no more. Could you please double check that >>> (e.g. update-alternatives --display runsystem should say >>> /etc/hurd/runsystem.sysv). >> >> # update-alternatives --display runsystem >> runsystem - auto mode >> link currently points to /etc/hurd/runsystem.sysv >> /etc/hurd/runsystem.gnu - priority 5 >> slave halt: /sbin/halt-hurd >> slave reboot: /sbin/reboot-hurd >> /etc/hurd/runsystem.sysv - priority 10 >> slave halt: /sbin/halt-sysv >> slave reboot: /sbin/reboot-sysv >> Current 'best' version is '/etc/hurd/runsystem.sysv'. >> >> I cannot say why no proc was mounted before I removed --compatible when >> /etc/hurd/rc isn't used. >> But it works (proved by visual examination ^^) > > Also, --compatible is a valid argument and it is recommended to use > that for compatibility with Linux' /proc. There is no reason to > believe it should cause any trouble. I cannot tell why it caused trouble - but now after I uninstalled gnumach-image-1.3.99-486 the issue disappears. >> Maybe we should first check why /etc/hurd/rc is involved in boot-process? > > Yes. Add exit 0 at the top. It is not used. Done without harming anything - seems to have a relation to gnumach-image-1.3.99-486 But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can access remotely. I'm quite unsure if it has to do with procfs or another issue (nothing suspicious in log or on screen) - but I'd like to mention it. >>> >>> Check that the hurd console is running. Also, check that you have an >>> entry like >>> >>> c:23:respawn:/sbin/getty 38400 console >>> >>> in your /etc/inittab to get a getty on the mach console (of course >>> inittab is only used if you use sysvinit). >> >> I have some lines looking similar (was 'c' a placeholder for [1-9]?) >> >> 1:2345:respawn:/sbin/getty 38400 tty1 >> 2:23:respawn:/sbin/getty 38400 tty2 >> 3:23:respawn:/sbin/getty 38400 tty3 > > No it's not. Apparently, 'c' is a valid identifier. If you have no > getty for the console, please add it. ttyX is used when the Hurd > console is running, 'console' refers to the mach console. Added and there is a login :) From original mail now only the nfs issue remains. Playing around I see differences between $ mount # no output, returns immediately # mount typed:device:hd0s1 on / type ext2fs (rw,no-inherit-dir-group) # cat /proc/mounts /dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0 none /run /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=102148K 0 0 none /run/lock /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=5M 0 0 none /run/shm /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=613980K 0 0 waldorf:/data/pkgsrc /data/pkgsrc /hurd/nfs hard,read-size=8192,write-size=8192,stat-timeout=3,cache-timeout=3,init-transmit-timeout=1,max-transmit-timeout=30,name-cache-timeout=3,name-cache-neg-timeout=3 0 0 Is there any reason for it? BTW: why I initially assumed the is a problem with the way mounting /proc: # top Error, do this: mount -t proc proc /proc Cheers -- Jens Rehsack rehs...@gmail.com -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a
Re: Some issues on fresh installed Debian-Hurd
Quoting Jens Rehsack (2014-06-02 10:58:17) > Am 02.06.2014 um 10:47 schrieb Justus Winter > <4win...@informatik.uni-hamburg.de>: > > > Hi :) > > > > Quoting Jens Rehsack (2014-06-02 08:28:50) > > > >> Beside the kernel choice the installation went smoothly (a problem > >> Debian-Hurd shares with Debian-kFreeBSD ^^). > > > > I don't follow. > > I most likely pebcak :) > Generally it's (for me) poorly documented which kernel is meant by hurd-1 vs. > hurd-1.3.nnn > I got it later by doing apt-cache search (but initial boot was with 1.3.nnn) I still don't follow. Hurd is not a kernel. There is no package hurd-1 or hurd-1.3.nnn. > > Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is favored > over kernel (and which version is kernel - 8+patches, 9, ???) > Enlightening comes later by trying it out ... > > But beside that - Hurd installation was impressive sane for "experimental" > why kFreeBSD crashs because it always installs 9'er kernel (regardless the > choice I make at installer - but maybe PEBCAK, let's do Hurd first). > > >> I had to modify line 117 in /etc/hurd/rc: "settrans -c /proc > >> /hurd/procfs --compatible" -> "settrans -c /proc /hurd/procfs", > >> otherwise the /proc file > system didn't came up. > >> > >> That reduces the noise during boot dramatically (cannot stat /proc > >> or something like that). > > > > Which is very strange, as we switched to sysv-rc and don't use > > /etc/hurd/rc no more. Could you please double check that > > (e.g. update-alternatives --display runsystem should say > > /etc/hurd/runsystem.sysv). > > # update-alternatives --display runsystem > runsystem - auto mode > link currently points to /etc/hurd/runsystem.sysv > /etc/hurd/runsystem.gnu - priority 5 > slave halt: /sbin/halt-hurd > slave reboot: /sbin/reboot-hurd > /etc/hurd/runsystem.sysv - priority 10 > slave halt: /sbin/halt-sysv > slave reboot: /sbin/reboot-sysv > Current 'best' version is '/etc/hurd/runsystem.sysv'. > > I cannot say why no proc was mounted before I removed --compatible when > /etc/hurd/rc isn't used. > But it works (proved by visual examination ^^) Also, --compatible is a valid argument and it is recommended to use that for compatibility with Linux' /proc. There is no reason to believe it should cause any trouble. > > Maybe we should first check why /etc/hurd/rc is involved in boot-process? Yes. Add exit 0 at the top. It is not used. > > >> But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl > >> vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can > >> access remotely. I'm quite unsure if it has to do with procfs or > >> another issue (nothing suspicious in log or on screen) - but I'd > >> like to mention it. > > > > Check that the hurd console is running. Also, check that you have an > > entry like > > > > c:23:respawn:/sbin/getty 38400 console > > > > in your /etc/inittab to get a getty on the mach console (of course > > inittab is only used if you use sysvinit). > > I have some lines looking similar (was 'c' a placeholder for [1-9]?) > > 1:2345:respawn:/sbin/getty 38400 tty1 > 2:23:respawn:/sbin/getty 38400 tty2 > 3:23:respawn:/sbin/getty 38400 tty3 No it's not. Apparently, 'c' is a valid identifier. If you have no getty for the console, please add it. ttyX is used when the Hurd console is running, 'console' refers to the mach console. Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602092118.10651.4...@thinkbox.jade-hamburg.de
Re: Some issues on fresh installed Debian-Hurd
Am 02.06.2014 um 10:47 schrieb Justus Winter <4win...@informatik.uni-hamburg.de>: > Hi :) > > Quoting Jens Rehsack (2014-06-02 08:28:50) > >> Beside the kernel choice the installation went smoothly (a problem >> Debian-Hurd shares with Debian-kFreeBSD ^^). > > I don't follow. I most likely pebcak :) Generally it's (for me) poorly documented which kernel is meant by hurd-1 vs. hurd-1.3.nnn I got it later by doing apt-cache search (but initial boot was with 1.3.nnn) Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is favored over kernel (and which version is kernel - 8+patches, 9, ???) Enlightening comes later by trying it out ... But beside that - Hurd installation was impressive sane for "experimental" why kFreeBSD crashs because it always installs 9'er kernel (regardless the choice I make at installer - but maybe PEBCAK, let's do Hurd first). >> I had to modify line 117 in /etc/hurd/rc: "settrans -c /proc >> /hurd/procfs --compatible" -> "settrans -c /proc /hurd/procfs", >> otherwise the /proc file > system didn't came up. >> >> That reduces the noise during boot dramatically (cannot stat /proc >> or something like that). > > Which is very strange, as we switched to sysv-rc and don't use > /etc/hurd/rc no more. Could you please double check that > (e.g. update-alternatives --display runsystem should say > /etc/hurd/runsystem.sysv). # update-alternatives --display runsystem runsystem - auto mode link currently points to /etc/hurd/runsystem.sysv /etc/hurd/runsystem.gnu - priority 5 slave halt: /sbin/halt-hurd slave reboot: /sbin/reboot-hurd /etc/hurd/runsystem.sysv - priority 10 slave halt: /sbin/halt-sysv slave reboot: /sbin/reboot-sysv Current 'best' version is '/etc/hurd/runsystem.sysv'. I cannot say why no proc was mounted before I removed --compatible when /etc/hurd/rc isn't used. But it works (proved by visual examination ^^) Maybe we should first check why /etc/hurd/rc is involved in boot-process? >> But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl >> vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can >> access remotely. I'm quite unsure if it has to do with procfs or >> another issue (nothing suspicious in log or on screen) - but I'd >> like to mention it. > > Check that the hurd console is running. Also, check that you have an > entry like > > c:23:respawn:/sbin/getty 38400 console > > in your /etc/inittab to get a getty on the mach console (of course > inittab is only used if you use sysvinit). I have some lines looking similar (was 'c' a placeholder for [1-9]?) 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 Cheers -- Jens Rehsack rehs...@gmail.com -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/75f9eaa1-38ed-46b6-b499-7880a5bf1...@gmail.com
Re: Hello
Hi :) Quoting Marcelo Lacerda (2014-06-01 21:02:12) > I joined this mailing list to help with the development of debian/hurd. > > > I can patch, help with debbuging and bug triaging. Cool! Start by installing Debian/Hurd, and familiarize yourself with the system. Remember, the Hurd is not Linux (it would be boring otherwise). Start to hang out at #hurd. Then, have a look at https://www.gnu.org/software/hurd/contributing.html, especially the small hacks list. Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602085154.10651.10...@thinkbox.jade-hamburg.de
Re: Some issues on fresh installed Debian-Hurd
Hi :) Quoting Jens Rehsack (2014-06-02 08:28:50) > Beside the kernel choice the installation went smoothly (a problem > Debian-Hurd shares with Debian-kFreeBSD ^^). I don't follow. > I had to modify line 117 in /etc/hurd/rc: "settrans -c /proc > /hurd/procfs --compatible" -> "settrans -c /proc /hurd/procfs", > otherwise the /proc file > system didn't came up. > > That reduces the noise during boot dramatically (cannot stat /proc > or something like that). Which is very strange, as we switched to sysv-rc and don't use /etc/hurd/rc no more. Could you please double check that (e.g. update-alternatives --display runsystem should say /etc/hurd/runsystem.sysv). > But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl > vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can > access remotely. I'm quite unsure if it has to do with procfs or > another issue (nothing suspicious in log or on screen) - but I'd > like to mention it. Check that the hurd console is running. Also, check that you have an entry like c:23:respawn:/sbin/getty 38400 console in your /etc/inittab to get a getty on the mach console (of course inittab is only used if you use sysvinit). Cheers, Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602084703.10651.90...@thinkbox.jade-hamburg.de
