Re: Porting with Guix

Hello, Regarding this topic, performing more tests: * Running with the sudo command 'Screen' works. I think that a user must be set for 'Screen' to run correctly as the Debian project does. buzz@Hurd:~$ sudo /home/buzz/.guix-profile/bin/screen ~/Guix-on-Hurd/pre-inst-env guix-daemon --build

Re: Porting with Guix

ren...@openmailbox.org skribis: > make[3]: Entering directory '/home/buzz/gits/D/bdwgc' > PASS: cordtest > hurd: Can't add reference on Mach thread FWIW this comes from the Hurd signal handling code in glibc: err = __mach_port_mod_refs (__mach_task_self (), thread,

Re: Porting with Guix

Hello, Annotated, Thanks On 2016-12-31 23:54, Olaf Buddenhagen wrote: On a side note, to do this correctly, you need to use `gdb --args ...`

Re: Porting with Guix

Hi, On Tue, Dec 27, 2016 at 06:54:30PM -0600, ren...@openmailbox.org wrote: > $ gdb screen /home/buzz/.guix-profile/bin/bash > "/home/buzz/.guix-profile/bin/bash" is not a core dump: File format not > recognized On a side note, to do this correctly, you need to use `gdb --args ...` -antrik-

Re: Porting with Guix

Hello everyone, Continuing my last email the deadlock in "gctest" originates from file phtread_support.c:2007 #ifndef NO_PTHREAD_TRYLOCK if (1 == GC_nprocs || GC_collecting) { pthread_mutex_lock(&GC_allocate_ml) } else { GC_generic_lock(&GC_allocate_ml); } When it tries

Re: Porting with Guix

Hello everyone, On 01/05/17 02:23, ren...@openmailbox.org wrote: > gnu/store/1h7p18gpn84kdww5i542k93arw4hhgs8-libgc-7.6.0/lib > make[2]: Leaving directory > '/tmp/guix-build-libgc-7.6.0.drv-0/gc-7.6.0' > make check-TESTS > make[2]: Entering directory > '/tmp/guix-build-libgc-7

Re: Porting with Guix

Ricardo Wurmus skribis: > ren...@openmailbox.org writes: > >> Now there are two errors related to the 'Check' phase of libgc and >> guile: >> In libgc shows: > > […] > >> building of >> `/gnu/store/y3icscjhkk7pa7dg21xqy46riysi36rn-libgc-7.6.0.drv' timed >> out after 3600 seconds of

Re: Porting with Guix

ren...@openmailbox.org writes: > Now there are two errors related to the 'Check' phase of libgc and > guile: > In libgc shows: […] > building of > `/gnu/store/y3icscjhkk7pa7dg21xqy46riysi36rn-libgc-7.6.0.drv' timed > out after 3600 seconds of silence You can increase the timeout:

Re: Porting with Guix

ren...@openmailbox.org, on Wed 04 Jan 2017 18:23:08 -0600, wrote: > PASS: cordtest > building of > `/gnu/store/y3icscjhkk7pa7dg21xqy46riysi36rn-libgc-7.6.0.drv' timed out after > 3600 seconds of silence Ah. Just for information, the libgc testsuite passes fine on Debian GNU/Hurd. Samu

Re: Porting with Guix

Hello Rennes, Please pull the latest changes from my github repo, try again and report back. Manolis

Re: Porting with Guix

Hello Rennes, your previous error is becase Guix uses 4.9 as default which doesn't support non-static initializers. I am currently rebuilding the bootstrap-binaries so you can try again with gcc-5. This error is probably because you are missing guile-2.0-dev. Manolis On 12/30/16 22:40, ren...@op

Re: Porting with Guix

Hi, On 2016-12-30 12:19, ren...@openmailbox.org wrote: Hi Manolis, I updated Debian GNU/Hurd to 0.9(GNU Hurd 0.9 GNU-Mach 1.8-486/Hurd-0.9 i686-AT386 GNU). Later, I run: $ ./bootstrap + exec autoreconf -vfi autoreconf: Entering directory `.' autoreconf: running: autopoint --force autoreconf: ru

Re: Porting with Guix

Hi Manolis, I updated Debian GNU/Hurd to 0.9(GNU Hurd 0.9 GNU-Mach 1.8-486/Hurd-0.9 i686-AT386 GNU). Later, I run: $ ./bootstrap + exec autoreconf -vfi autoreconf: Entering directory `.' autoreconf: running: autopoint --force autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac:

Re: Porting with Guix

Hello, Can you rerun guix build command with -K and check the version of gcc being used in the file "/tmp/guix-build-.../environment-variables"? Related to gcc, i see: export CPATH="/gnu/store/vz5xa345sgsq1c7gb5biaqb8zmyf7934-glibc-bootstrap-0/include:/gnu/store/fc2nz3zkac3w2ic5cyganj0rjqah

Re: Porting with Guix

Hello Rennes On 12/28/16 23:22, ren...@openmailbox.org wrote: a345sgsq1c7gb5biaqb8zmyf7934-glibc-bootstrap-0/include/pthread/pthread.h:757:27: > error: initializer element is not constant > #define PTHREAD_ONCE_INIT __PTHREAD_ONCE_INIT >^ > glthread/lock.c:454:42: note

Re: Porting with Guix

This likely means that Guix was configured in an environment where Guile-SSH was available (so offloading support was enabled), but at runtime Guile-SSH cannot be found. You could try adding “--no-build-hook”. Hi, Now, start downloading and built with: "guix build hello --no-substitutes --no

Re: Porting with Guix

ren...@openmailbox.org writes: > After successfully compiling with the new branch. > > I run 'guix build hello --no-substitutes', and shows: > > The following derivations will be built: > /gnu/store/7i1nbypavdly0n0858bq9ngrhj8s5i6i-hello-2.10.drv > > ... > > /gnu/store/zsgpdqglj2i7i3kz777

Re: Porting with Guix

I have rebooted, I currently have the Hurd version: GNU Hurd 0.8 GNU-Mach 1.7+git20160607-486/Hurd-0.8 i686-AT386 GNU On 2016-12-28 13:19, Manolis Ragkousis wrote: Hello Rennes, Did you update your daemon and restart it?

Re: Porting with Guix

Hello Rennes, Did you update your daemon and restart it? Manolis On 12/28/16 21:16, ren...@openmailbox.org wrote: > Hi Manolis, > > After successfully compiling with the new branch. > > I run 'guix build hello --no-substitutes', and shows: > > The following derivations will be built: >/gn

Re: Porting with Guix

Hi Manolis, After successfully compiling with the new branch. I run 'guix build hello --no-substitutes', and shows: The following derivations will be built: /gnu/store/7i1nbypavdly0n0858bq9ngrhj8s5i6i-hello-2.10.drv ... /gnu/store/zsgpdqglj2i7i3kz777lv8kbvc9hk57h-bash-4.4.5.drv killing

Re: Porting with Guix

Sorry I forgot this. > Are there additional changes needed compared to Guix 0.12.0? Do you > happen to have a write-up on how to get started with the Hurd and Guix? Well I need to clear my daemon work and merge with guix proper. I haven't and I need to do that.

Re: Porting with Guix

Hey Ricardo, :-D I don't think we have i586 binaries in Guix proper yet. We need to first build them with hydra. Manolis On 12/28/16 20:15, Ricardo Wurmus wrote: > > Hi Manolis, > >> Now on the problem, I suppose you are using the Guix version from my >> github repo? The wip-hurd branch is an

Re: Porting with Guix

Hi Manolis, > Now on the problem, I suppose you are using the Guix version from my > github repo? The wip-hurd branch is an older version which is probably > why you have those issues. I created a new branch in my github repo > called wip-hurd-native for you to clone. I cherry picked my latest >

Re: Porting with Guix

Hello Rennes, First of all thank you for helping with this! Now on the problem, I suppose you are using the Guix version from my github repo? The wip-hurd branch is an older version which is probably why you have those issues. I created a new branch in my github repo called wip-hurd-native for yo

Re: Porting Mach syscall/ipc to Linux

Hi, On Fri, Jan 15, 2016 at 09:52:54AM +0100, Luca Dariz wrote: > has anyone already tried to port or implement the Mach syscalls and ipc > to Linux? Someone on IRC mentioned a project recent-ish that apparently works on implementing some Mach interfaces in Linux, to allow running certain system

Re: Porting Mach syscall/ipc to Linux

Luca Dariz, on Fri 15 Jan 2016 09:52:54 +0100, wrote: > has anyone already tried to port or implement the Mach syscalls and ipc > to Linux? Not that I know of. > I am wondering if there are any fundamental limitations due to different > architectural decisions and so on, I was thinking about buil

Re: Porting LLVM, clang et al. to GNU/Hurd

Hi! On Thu, 10 Jan 2013 12:36:38 +0100, I wrote: > At night, when having my GNU Hurd maintainer hat on, I'm currently > working on porting LLVM, clang et al. to x86-class systems using the GNU > Hurd as their kernel, . I have now posted most of my patches for re

Re: Porting Debian Packages

On Tue, 2012-01-24 at 15:33 +0100, Tanguy LE CARROUR wrote: > Is this the right place to check for next time? (instead of asking > stupid questions ^_^') > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257087 You should check: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lis

Re: Porting Debian Packages

2012/1/24 Samuel Thibault > Tanguy LE CARROUR, le Tue 24 Jan 2012 13:16:36 +0100, a écrit : > > I checked version 0.3.22. Here is part of the debian/changelog > > > > auto-apt (0.3.22) unstable; urgency=low > > [...] > > * debian/patches > > - (Number 10): Fix FTBFS(hurd-i386): PATH_MAX u

Re: Porting Debian Packages

Tanguy LE CARROUR, le Tue 24 Jan 2012 13:16:36 +0100, a écrit : > I checked version 0.3.22. Here is part of the debian/changelog > > auto-apt (0.3.22) unstable; urgency=low >   [...] >   * debian/patches >     - (Number 10): Fix FTBFS(hurd-i386): PATH_MAX undeclared >       (Closes: #257087). >  

Re: Porting Debian Packages

2012/1/24 Samuel Thibault > Tanguy LE CARROUR, le Tue 24 Jan 2012 11:07:24 +0100, a écrit : > > 1) How comes the Hurd patch (part of the last debian/changelog entry) > doesn't > > fix this one, leaving a FTBFS package?! > > Most probably because this one is new. > Oh... Maybe you can clarify some

Re: Porting Debian Packages

Tanguy LE CARROUR, le Tue 24 Jan 2012 11:07:24 +0100, a écrit : > 1) How comes the Hurd patch (part of the last debian/changelog entry) doesn't > fix this one, leaving a FTBFS package?! Most probably because this one is new. > 2) When is is acceptable to solve a PATH_MAX problem like it was done

Re: Porting Debian Packages

Hi guys! Some more question on "Porting Package", but this time with a specific example... I picked "auto-apt" (0.3.22) and even if some Hurd patch had been applied the code still failed to compile because of one undeclared PATH_MAX. 1) How comes the Hurd patch (part of the last debian/changelog

Re: Porting Debian Packages

Hi! 2012/1/18 Anatoly A. Kazantsev > Also, it's possible to use sshfs. It allows to edit files on VM directly > with a preffered editor :-) I'll stick to: try everything on Linux and when it works scp/ssh to Hurd-qemu to try it! For now I've selected a bunch of "useless" packages from the bott

Re: Porting Debian Packages

On Tue, 17 Jan 2012 22:22:28 +0100 Svante Signell wrote: > On Tue, 2012-01-17 at 21:30 +0100, Samuel Thibault wrote: > > Tanguy LE CARROUR, le Tue 17 Jan 2012 21:20:24 +0100, a écrit : > > > Le mardi 17 janvier 2012, Svante Signell a > > > écrit : > > > > On Tue, 2012-01-17 at 17:03 +0100, Tang

Re: Porting Debian Packages

Hi Tanguy :) In-Reply-To: Quoting Tanguy LE CARROUR (2012-01-18 10:19:14) >For sure, once it builds on Linux I have to try it on Hurd. >But the build process take longer in my qemu. And I'm used to use pbuild which >is also a bit of an overhead. > >[...] > >I do the same but all network related

Re: Porting Debian Packages

On Wed, 2012-01-18 at 10:29 +0100, Samuel Thibault wrote: > Samuel Thibault, le Wed 18 Jan 2012 10:27:10 +0100, a écrit : > > Tanguy LE CARROUR, le Wed 18 Jan 2012 10:19:14 +0100, a écrit : > > Also check the bug tracker and > > http://wiki.debian.org/Debian_GNU/Hurd > > for possibly existing pat

Re: Porting Debian Packages

Samuel Thibault, le Wed 18 Jan 2012 10:27:10 +0100, a écrit : > Tanguy LE CARROUR, le Wed 18 Jan 2012 10:19:14 +0100, a écrit : > > Oh, one last question: According to the timestamp this list [1] seems up to > > date, should it be the one to choose packages to fix from?  > > > > [1] http://people.

Re: Porting Debian Packages

Tanguy LE CARROUR, le Wed 18 Jan 2012 10:19:14 +0100, a écrit : > Oh, one last question: According to the timestamp this list [1] seems up to > date, should it be the one to choose packages to fix from?  > > [1] http://people.debian.org/~sthibault/graph-total-top.txt Yes. Note that the topmost pa

Re: Porting Debian Packages

Hi! 2012/1/17 Samuel Thibault > > But, as fixing problems such as PATH_MAX is not Hurd specific, one could > also > > fix it on a Linux system. > > PATH_MAX issues can be worked on on Linux, yes. But a test is needed on > Hurd afterwards, in case some other, non-PATH_MAX issues remain. > For sur

Re: Porting Debian Packages

On Tue, 2012-01-17 at 21:30 +0100, Samuel Thibault wrote: > Tanguy LE CARROUR, le Tue 17 Jan 2012 21:20:24 +0100, a écrit : > > Le mardi 17 janvier 2012, Svante Signell a écrit > > : > > > On Tue, 2012-01-17 at 17:03 +0100, Tanguy LE CARROUR wrote: > > >> Can I fix Hurd package build errors (simp

Re: Porting Debian Packages

Tanguy LE CARROUR, le Tue 17 Jan 2012 21:20:24 +0100, a écrit : > Le mardi 17 janvier 2012, Svante Signell a écrit : > > On Tue, 2012-01-17 at 17:03 +0100, Tanguy LE CARROUR wrote: > >> Can I fix Hurd package build errors (simple ones like PATH_MAX) on a > >> Linux system? > > The best way to port

Re: Porting Debian Packages

Hi, Le mardi 17 janvier 2012, Svante Signell a écrit : > On Tue, 2012-01-17 at 17:03 +0100, Tanguy LE CARROUR wrote: >> Can I fix Hurd package build errors (simple ones like PATH_MAX) on a >> Linux system? > The best way to port packages using Linux is to install a Hurd image in > a VM, like kvm

Re: Porting Debian Packages

On Tue, 2012-01-17 at 17:03 +0100, Tanguy LE CARROUR wrote: > Hi, > > > I have a small (stupid) question regarding "Porting Debian Packages". > I already know the answer but I have to ask anyway before I start > working on something... > > > Can I fix Hurd package build errors (simple ones like

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

On Fri, 2011-11-04 at 00:55 +0100, Guillem Jover wrote: > Hi! ... > > + *-gnu*) > > +AC_DEFINE(PLATFORM_GNU, 1, [Define if you are compiling for *GNU]) > > +;; ... > If you add this, no platform specific code is being used, so it should > not build as it stops using the fallback unknown pl

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

Hi! On Tue, 2011-11-01 at 23:25:13 +0100, Svante Signell wrote: > On Tue, 2011-11-01 at 22:30 +0100, Guillem Jover wrote: > > and then use HAVE_GETDTABLESIZE. Also if there's no limit (-1) it's a > > bit harsh to exit(1). I'd code this for example like: > > I did not realize that -1 meant unlimit

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

On Tue, 2011-11-01 at 22:30 +0100, Guillem Jover wrote: > On Tue, 2011-11-01 at 15:57:53 +0100, Svante Signell wrote: .. > __USE_BSD is an internal macro used by glibc and should not be relied > on. Add a check to configure.ac instead, something like this: > > AC_CHECK_FUNCS([getdtablesize]) Ok,

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

On Tue, 2011-11-01 at 15:57:53 +0100, Svante Signell wrote: > Updated code snippet below, OK? > > void bg(void) > { > int i, fdmax; [...] > /* Close probably all file descriptors */ > #ifdef __USE_BSD > if ((fdmax = getdtablesize()) == -1) exit(1); > #else > if ((fd

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

On Tue, 2011-11-01 at 13:34 +0100, Guillem Jover wrote: > On Tue, 2011-11-01 at 11:49:48 +0100, Svante Signell wrote: > > In package uptimed-0.3.16 the following function is defined: > > void bg(void) Updated code snippet below, OK? void bg(void) { int i, fdmax; /* Simple fork to

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

Hi, On Tue, Nov 01, 2011 at 11:49:48AM +0100, Svante Signell wrote: > In package uptimed-0.3.16 the following function is defined: BTW, I had a look at uptimed before, and the main problem I faced (IIRC), was making it crash safe. uptimed is writing the current uptime into a file, and even on GN

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

On Tue, 2011-11-01 at 11:49:48 +0100, Svante Signell wrote: > In package uptimed-0.3.16 the following function is defined: > void bg(void) > { [...] > /* Close probably all file descriptors */ > for (i = 0; i close(i); [...] > } > Two questions arrives after discuss

Re: porting the clustered paging-in from OSF Mach to GNU Mach

Hi, On Fri, Jun 04, 2010 at 07:26:58PM +0300, Karim Allah Ahmed wrote: > ChangeLog [key modifications]: > > -ported the clustered paging-in code from OSF Mach's > [mach_kernel]/vm/vm_fault_page.c > -added "behavior" attribute for the "vm_map" entries > -added "cluster_size" attribute for the mem

Re: Porting highlights for the Month of the Hurd 2009-12

Hi, Arne Babenhauserheide wrote: > Is there a port among the highlights you'd like to showcase? Many GNOME packages have been ported, resulting in the gnome-core metapackage being installable again. I haven't tested them yet though as I can't start X :) Cheers, Emilio

Re: porting.

"Lucas Mendes" <[EMAIL PROTECTED]> writes: > Hi there! > I am reading Hurd Kernel and thinking about to port this for my mac68k; > how can I officialize my porting? :-) > Thanks for read me. Some people worked on a m68k port of Mach once, although that work was not finished. IIRC that was for th

Re: porting kerberos

> #ifndef NCARGS > /* Linux doesn't seem to have it. */ > #define NCARGS 1024 > #endif > > char cmdbuf[NCARGS+1] > > We define NCARGS to INTMAX for compatibility with BSD programs > (in ). If this is how BSD programs use that value, > we should probably define it to a lower value ;) or not defi

Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)

Roland, > > need to reply like this. Basically, you suggest nothing less than to shut > > up and do our own non-approved stuff without asking for feedback from the > > list. This is asking for a split in development :-((( Sad perspectives..., > > but splits are necessary sometimes. > I didn't say

Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)

On Sun, Oct 29, 2000 at 03:49:01PM -0500, Roland McGrath wrote: > > Is it _absolutely_ necessary to use glibc with the Hurd? > > Why on earth would one want not to? The Hurd developers have no interest > whatsoever in using anything but the GNU C library for the GNU system. think about embedded

Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)

On Sun, Oct 29, 2000 at 06:57:41PM -0500, Roland McGrath wrote: > Perhaps there should just be another mailing for wild speculations about > random development ideas tangentially related to the Hurd development > effort. Then I would read that one when I was in that kind of mood. These > lists r

Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)

Perhaps there should just be another mailing for wild speculations about random development ideas tangentially related to the Hurd development effort. Then I would read that one when I was in that kind of mood. These lists really exist for concrete discussion of real problems with the existing c

Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)

> if you would let us participate to your concepts of current and future > development, such discussions would be more effective. We can't guess > what you're planning to do on short or middle term if you don't post > your ideas somewhere :(. There is no secret plan. Marcus has laid out numerous

Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)

Roland, > Look, whatever you want to hack on is fine with me. If you contribute > changes to Hurd and/or glibc that are clean and do not have negative > consequences for the ways we are using the code now, then we will probably > accept your changes. But the development priorities of the Hurd p

Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)

Look, whatever you want to hack on is fine with me. If you contribute changes to Hurd and/or glibc that are clean and do not have negative consequences for the ways we are using the code now, then we will probably accept your changes. But the development priorities of the Hurd project per se are

Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)

> The Hurd is IMHO more than just a simple kernel replacement of a glibc- > based system. Due to its flexibility, other applications like host-os > subhurds are possible too. Just because it's 'oolitically correct' to > stick to glibc doesn't mean that we _must_! Other GNU programs are not > depen

Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)

> Anything that can be done to make the HURD available on more > processor architectures would be a good thing. But my impression is > that the work the needs to be done is to port the HURD to OSKit Mach > and to port OSKit Mach to other architectures. Then you would still be stuck with Mach which

Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)

> > Is it _absolutely_ necessary to use glibc with the Hurd? > Why on earth would one want not to? The Hurd developers have no interest > whatsoever in using anything but the GNU C library for the GNU system. The Hurd is IMHO more than just a simple kernel replacement of a glibc- based system. Du

Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)

> Is it _absolutely_ necessary to use glibc with the Hurd? Why on earth would one want not to? The Hurd developers have no interest whatsoever in using anything but the GNU C library for the GNU system. ___ Bug-hurd mailing list [EMAIL PROTECTED] http

Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)

>>> Farid Hajji <[EMAIL PROTECTED]> 29-Oct-00 5:34:40 PM >>> >P.S.: I don't have anything against glibc. Dropping glibc >dependency from the Hurd is purely an architectural issue >that would help support the notion of "host OS running sub-hurd" >as well as to help isolate the current Mach depe