Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Svante Signell writes: > On Sat, 2023-05-13 at 19:01 +, jbra...@dismail.de wrote: >> May 13, 2023 1:46 PM, "Sergey Bugaev" wrote: >> >> > On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de  >> > wrote: >> > >> > > +Hurd developers are adding 64-bit support, and they plan to drop the >> > >

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On Sat, 2023-05-13 at 19:01 +, jbra...@dismail.de wrote: > May 13, 2023 1:46 PM, "Sergey Bugaev" wrote: > > > On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de  > > wrote: > > > > > +Hurd developers are adding 64-bit support, and they plan to drop the > > > +32-bit support, once the 64-bit

Re: [PATCH] * faq/64-bit.mdwn: added up to date 64-bit porting info * open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Joshua Branson, le mer. 17 mai 2023 15:41:01 -0400, a ecrit: > Samuel Thibault writes: > > I have restored some pieces which are not outdated (we still do have > > 32-on-64 > > plans, and running 32bit on 64bit hardware is still something people > > have to understand possible). > > That is tota

Re: [PATCH] * faq/64-bit.mdwn: added up to date 64-bit porting info * open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Samuel Thibault writes: > Hello, > > I have restored some pieces which are not outdated (we still do have 32-on-64 > plans, and running 32bit on 64bit hardware is still something people > have to understand possible). That is totally fine with me. May I ask why we might pursue supporting 32-on-

Re: [PATCH] * faq/64-bit.mdwn: added up to date 64-bit porting info * open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Hello, I have restored some pieces which are not outdated (we still do have 32-on-64 plans, and running 32bit on 64bit hardware is still something people have to understand possible). Thanks, Samuel jbra...@dismail.de, le mer. 17 mai 2023 09:53:01 -0400, a ecrit: > --- > faq/64-bit.mdwn

[PATCH] * faq/64-bit.mdwn: added up to date 64-bit porting info * open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

--- faq/64-bit.mdwn | 15 --- open_issues/64-bit_port.mdwn | 6 +- 2 files changed, 9 insertions(+), 12 deletions(-) diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn index 2e1278cb..9c8ecc9c 100644 --- a/faq/64-bit.mdwn +++ b/faq/64-bit.mdwn @@ -13,11 +13,12 @@ License

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Sergey Bugaev, le lun. 15 mai 2023 20:51:54 +0300, a ecrit: > store (= rumpdisk, not ramdisk) and nano? :) FI nano is now available as debian-amd64 package since a few days :) Samuel

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On May 15, 2023 7:51:54 PM GMT+02:00, Sergey Bugaev wrote: >On Mon, May 15, 2023 at 7:28 PM Guy-Fleury Iteriteka > wrote: >> Yes, i know that. I fallow you on mastodon. > >Then you get to see all the shitposts :D > All posts yes :) >> Also as you are good in writing you can documents how you creat

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On Mon, May 15, 2023 at 7:28 PM Guy-Fleury Iteriteka wrote: > Yes, i know that. I fallow you on mastodon. Then you get to see all the shitposts :D > Also as you are good in writing you can documents how you created and launch > it but when you finished your great work Ah, :blush: thank you fo

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On May 15, 2023 6:45:40 PM GMT+02:00, Samuel Thibault wrote: >Guy-Fleury Iteriteka, le lun. 15 mai 2023 18:28:36 +0200, a ecrit: >> It should be interesting to use flavio's script. > >I don't think Flavio aims to bootstrap various libraries and whatnot :) > I meant to test just the hurd core woul

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Sergey Bugaev writes: > On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka > wrote: >> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" >> wrote: >> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian >> Are sure a debian hurd boot?? > > I'm rather sure some patches

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Sergey Bugaev, le sam. 13 mai 2023 20:45:35 +0300, a ecrit: > On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de wrote: > > +Hurd developers are adding 64-bit support, and they plan to drop the > > +32-bit support, once the 64-bit support is deemed stable. > > Is this really the plan? :( No, but

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Guy-Fleury Iteriteka, le lun. 15 mai 2023 18:28:36 +0200, a ecrit: > It should be interesting to use flavio's script. I don't think Flavio aims to bootstrap various libraries and whatnot :) Samuel

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On May 15, 2023 5:58:12 PM GMT+02:00, Sergey Bugaev wrote: >On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka > wrote: >> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" >> wrote: >> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian >> Are sure a debian hurd boot?

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka wrote: > On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" > wrote: > >+As of May 2023, the Hurd developers have a bootable 64-bit Debian > Are sure a debian hurd boot?? I'm rather sure some patches required to get anything serious (

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

Guy-Fleury Iteriteka writes: > On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" > wrote: >>--- >>I explained that the Hurd has initial 64-bit support, but I >>did not mention if the project plans to drop 32-bit >>support. Joshua >> >> faq/64-bit.mdwn | 10 +++--- >> o

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" wrote: >--- >I explained that the Hurd has initial 64-bit support, but I >did not mention if the project plans to drop 32-bit >support. Joshua > > faq/64-bit.mdwn | 10 +++--- > open_issues/64-bit_port.mdwn | 6 +- >

[PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

--- I explained that the Hurd has initial 64-bit support, but I did not mention if the project plans to drop 32-bit support. Joshua faq/64-bit.mdwn | 10 +++--- open_issues/64-bit_port.mdwn | 6 +- 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/faq/64-bit.

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On 14/05/2023 7:01 am, jbranso wrote: May 13, 2023 1:46 PM, "Sergey Bugaev" wrote: On Sat, May 13, 2023 at 7:38 PM jbranso wrote: +Hurd developers are adding 64-bit support, and they plan to drop the +32-bit support, once the 64-bit support is deemed stable. Is this really the plan? :( Has

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

May 13, 2023 1:46 PM, "Sergey Bugaev" wrote: > On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de wrote: > >> +Hurd developers are adding 64-bit support, and they plan to drop the >> +32-bit support, once the 64-bit support is deemed stable. > > Is this really the plan? :( > > Has this been d

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de wrote: > +Hurd developers are adding 64-bit support, and they plan to drop the > +32-bit support, once the 64-bit support is deemed stable. Is this really the plan? :( Has this been discussed anywhere? I understand that supporting multiple arch

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On May 13, 2023 6:38:15 PM GMT+02:00, "jbra...@dismail.de" wrote: >--- > faq/64-bit.mdwn | 11 --- > open_issues/64-bit_port.mdwn | 6 +- > 2 files changed, 5 insertions(+), 12 deletions(-) > >diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn >index 2e1278cb..36afbbc3 100644

[PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

--- faq/64-bit.mdwn | 11 --- open_issues/64-bit_port.mdwn | 6 +- 2 files changed, 5 insertions(+), 12 deletions(-) diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn index 2e1278cb..36afbbc3 100644 --- a/faq/64-bit.mdwn +++ b/faq/64-bit.mdwn @@ -13,11 +13,8 @@ License|/fdl

Re: [GSOC ‘23] Interested in working on Porting Rust to GNU/Hurd

Thanks, I will do that. On Thu, Mar 30, 2023 at 4:24 PM wrote: > March 30, 2023 11:01 AM, "Raj Sahu" wrote: > > > Thanks for the links Joshua. I saw the more descriptive problem > statement and goals for the Rust > > porting task and would like to take it up

Re: [GSOC ‘23] Interested in working on Porting Rust to GNU/Hurd

March 30, 2023 11:01 AM, "Raj Sahu" wrote: > Thanks for the links Joshua. I saw the more descriptive problem statement and > goals for the Rust > porting task and would like to take it up for my GSOC application. Would you > suggest me to go with > the bonding exerci

Re: [GSOC ‘23] Interested in working on Porting Rust to GNU/Hurd

Thanks for the links Joshua. I saw the more descriptive problem statement and goals for the Rust porting task and would like to take it up for my GSOC application. Would you suggest me to go with the bonding exercise or shall I work on the proposal right away? Thanks Raj On Thu, 30 Mar 2023 at 10

Re: [GSOC ‘23] Interested in working on Porting Rust to GNU/Hurd

March 30, 2023 1:18 PM, "Raj Sahu" wrote: > Hello > I was going through the list of proposed ideas within GNU for the GSOC'23 and > I wanted to get in > touch with you to discuss more about it. > > I am currently a Master's student at Virginia Tech working towards a thesis > on eBPF which incl

Re: [gnu-soc] GNU Hurd : Rust Porting Project

Hii !! I am starting my draft proposal for the GNU/Hurd Rust port. So, Once I have my first draft ready then can I share it here itself or this could be mailed personally ? On Sun, Feb 26, 2023 at 8:22 PM Samuel Thibault wrote: > Harshil Jani, le dim. 26 févr. 2023 19:26:18 +0530, a ecrit: > > S

Re: GSoC'2023: Porting Rust to GNU/Hurd: GNU

Hello, Madhu patel, le sam. 11 mars 2023 17:56:47 +0530, a ecrit: > can you please tell me the number of applicants for this project? We won't know that until the application frontend closes. Samuel

Re: GSoC'2023: Porting Rust to GNU/Hurd: GNU

hi Samuel. I have completed the tasks you mentioned. can you please tell me the number of applicants for this project? and what are my chances of getting selected? Thanks! On Fri, Mar 10, 2023 at 5:29 AM Samuel Thibault wrote: > Hello, > > Madhu patel, le jeu. 09 mars 2023 13:01:51 +0530, a ec

Re: GSoC'2023: Porting Rust to GNU/Hurd: GNU

Hello, Madhu patel, le jeu. 09 mars 2023 13:01:51 +0530, a ecrit: > I have gone through the page, and I meet some requirements as mentioned. I > have > good knowledge of C and am currently in the process of learning Rust. At the > moment, I am working on [1][1]. Can you recommend any other skills

Re: GSoC'2023: Porting Rust to GNU/Hurd: GNU

Hi, I have gone through the page, and I meet some requirements as mentioned. I have good knowledge of C and am currently in the process of learning Rust. At the moment, I am working on [1] . Can you recommend any other skills

Re: GSoC'2023: Porting Rust to GNU/Hurd: GNU

Hello, Madhu patel, le jeu. 09 mars 2023 01:44:50 +0530, a ecrit: > Please suggest a few initial tasks I can work on during the application period > and attach them to my application. We have posted information on https://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/rust/ Samuel

GSoC'2023: Porting Rust to GNU/Hurd: GNU

Hi, I'm interested in working on the project `Porting Rust to GNU/Hurd` in the GNU organization through GSoC'2023. I am Madhu Patel, a fourth-year B.Tech. student in Computer Science at IGDTUW, with a CGPA of 8.7/10. I have previously interned at Adobe India, Rabvik Innovations, and FM

Re: [gnu-soc] GNU Hurd : Rust Porting Project

Harshil Jani, le dim. 26 févr. 2023 19:26:18 +0530, a ecrit: > So, I am planning to get GNU/Hurd on VM if all goes well. One more > thing which I wanted to ask was about the C headers ? Would the bindgen tool > take care of the headers during the port or we have to do it manually? The C headers ar

Re: GNU Hurd : Rust Porting Project

Hey ! Thanks for this patch. I recently saw back on the site about the bonding exercise. So, I am planning to get GNU/Hurd on VM if all goes well. One more thing which I wanted to ask was about the C headers ? Would the bindgen tool take care of the headers during the port or we have to do it manua

Re: GNU Hurd : Rust Porting Project

Hello, Thanks for your interest on this project :D Harshil Jani, le ven. 24 févr. 2023 00:25:32 +0530, a ecrit: > 1. What is the project size? I am curious if it falls under the category of > 350 > Large or 175 Medium. I'm not sure. I'd say it significantly depends on the existing knowledge of

GNU Hurd : Rust Porting Project

Hi, My name is Harshil Jani, and I am interested in the GNU Hurd project listed on the Ideas page. Specifically, I am intrigued by the port to Rust aspect of the project. As a newcomer to the Rust programming language, I have been actively contributing to Rust-Bitcoin to hone my skills. I believe

Porting Valgrind to GNU/Hurd: Re: Need help with assembly code

On Tue, 2021-11-30 at 22:22 +, jbra...@dismail.de wrote: > November 29, 2021 12:41 PM, "Svante Signell" > wrote: > > > Hello, > > > > I've been working lately with on how to port valgrind to GNU/Hurd, > > and found out that this is not a trivial task. Seems like one have > > to make a suitab

Fwd: GSoC 2017: Porting LwIP to the Hurd

Hello Thomas, Great news, now I have another reference for doing this. I've been taking a look and have seen they are using LwIP as a library. In my prototype, LwIP is not even a static library, its sources are compiled along with the translator to create a single binary, like pfinet with the Lin

Re: GSoC 2017: Porting LwIP to the Hurd

Hi! On Fri, 17 Mar 2017 08:31:37 +0100, Joan Lledó wrote: > My name is Joan Lledó, I'm in the last year of my degree in CS at the > Open University of Catalonia[1]. I'm interested in OS programming and, > for now, I have only read theory and have made university exercises in > ths field. That's w

Re: GSoC 2017: Porting LwIP to the Hurd

Hello, Welcome on board ! That's a very promising project proposal :D Joan Lledó, on ven. 17 mars 2017 08:31:37 +0100, wrote: > I think it's a feasible GSoC project to implement the same > functionality that pfinet ofers now, but I'd like to know your > opinion. Perhaps not everything, but prob

GSoC 2017: Porting LwIP to the Hurd

Hello, My name is Joan Lledó, I'm in the last year of my degree in CS at the Open University of Catalonia[1]. I'm interested in OS programming and, for now, I have only read theory and have made university exercises in ths field. That's why I see GSoC as a good chance to work in a real project and

Re: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns

issue with the > runtime that occurs, are there any potentials notes on it so far? Is > Ian Lance Taylor still active on the project as well? >   > From: Svante Signell > Sent: Saturday, March 4, 2017 6:52 PM > To: Samuel Thibault; Louis Jenkins > Cc: bug-hurd@gnu.org; summer-o

RE: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns

: bug-hurd@gnu.org<mailto:bug-hurd@gnu.org>; summer-of-c...@gnu.org<mailto:summer-of-c...@gnu.org> Subject: Re: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns On Sun, 2017-03-05 at 00:44 +0100, Samuel Thibault wrote: > Louis Jenkins, on sam. 04 mars 2017 23:16:30 +,

RE: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns

c...@gnu.org<mailto:summer-of-c...@gnu.org>; bug-hurd@gnu.org<mailto:bug-hurd@gnu.org> Subject: Re: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns Hello, Louis Jenkins, on sam. 04 mars 2017 22:38:06 +, wrote: > As for Svante Signell, I was googling his name a

Re: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns

On Sun, 2017-03-05 at 00:44 +0100, Samuel Thibault wrote: > Louis Jenkins, on sam. 04 mars 2017 23:16:30 +, wrote: > > One more thing: I see it is now CC’d, but would he be able to see > > the previous > > messages, or should I ask directly there? > > Google for "bug-hurd", and you'll find the

Re: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns

Louis Jenkins, on sam. 04 mars 2017 23:16:30 +, wrote: > One more thing: I see it is now CC’d, but would he be able to see the previous > messages, or should I ask directly there? Google for "bug-hurd", and you'll find the mailing list archives. Samuel

Re: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns

Hello, Louis Jenkins, on sam. 04 mars 2017 22:38:06 +, wrote: > As for Svante Signell, I was googling his name a bit and the most relevant I > could find was for [1]svante.sign...@gmail.com would that be his appropriate > email address, or is there a way to search or communicate through the ma

Re: [GSoC 2017] Porting Google Go (GCC: gccgo) - Questions and Concerns

Louis Jenkins, on ven. 03 mars 2017 20:20:20 +, wrote: > However, again, before I delve further I would like to know first if it is > still active, or can potentially be restarted. So, assuming that this is about porting Go to the GNU/Hurd system, you need to be aware that some work ha

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

Porting with Guix

Hi, I'm helping to port some applications to Hurd, with Guix package manager. I am using Debian GNU/Hurd to perform my tests. I have the following error when running the Screen application, and tried to debug as follows: $ screen /home/buzz/.guix-profile/bin/bash [screen is terminating] $ gd

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

Hello Manolis, Manolis Ragkousis skribis: > On Hurd though, because of the lack of mount(), the above could not > work. But with the help of my libhurdutil library, which I wrote at the > beginning of this project, I created 2 wrappers inside > nix/libutil/call.(hh.cc) for mount() and umount2(),

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

Manolis Ragkousis, on Sat 20 Aug 2016 21:31:43 +0300, wrote: > On 08/20/16 20:47, Samuel Thibault wrote: > > Ok, but the Linux part uses glibc 2.22, and you'd rather use it, right? > > Of course :-) Ok, I have pushed it, along the debian glibc 2.22 fixup patches, it seems to be working fine with

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

On 08/20/16 20:47, Samuel Thibault wrote: > Ok, but the Linux part uses glibc 2.22, and you'd rather use it, right? Of course :-)

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

Manolis Ragkousis, on Sat 20 Aug 2016 20:42:25 +0300, wrote: > Actually the Hurd part of Guix uses 2.19 as it is in > ftp://alpha.gnu.org/gnu/hurd/ > > The glibc tarballs use 2.19 as their version, which is the one I am > using as the version in our glibc/hurd recipe. Ok, but the Linux part uses

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

Hey Samuel, Actually the Hurd part of Guix uses 2.19 as it is in ftp://alpha.gnu.org/gnu/hurd/ The glibc tarballs use 2.19 as their version, which is the one I am using as the version in our glibc/hurd recipe. Check (gnu packages base) glibc/hurd. Manolis On 08/20/16 19:24, Samuel Thibault wro

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

Hello, Which glibc version is guix based on? It's very high time we upgrade our glibc repository, because we see people contribute patch against it and it makes use rebase the work in downstreams. I'd thus say we should make our glibc repository based on the minimum version used by the supported

[GSoC] Porting GuixSD to GNU/Hurd Update

Hello Guix, Hello Hurd, As GSoC is coming to an end I think it's time to sum up my work till now, report issues I had and then talk about what our next steps are. First I would like to mention what were the two main objectives of the project and also what was the status of the port when the proje

Re: open-isns porting question: sudden SIGLOST

On 07/27/2016 07:25 PM, Svante Signell wrote: > (Adding bug-hurd to the Cc: list, not all developers follows the > debian-hurd list) > > On Wed, 2016-07-27 at 18:15 +0200, Christian Seiler wrote: >> Oh, I should mention that every time you run isnsadm the server >> (isnsd) crashes with SIGLOST, so

Re: open-isns porting question: sudden SIGLOST

On 07/28/2016 12:45 AM, Svante Signell wrote: > On Wed, 2016-07-27 at 23:38 +0200, Christian Seiler wrote: >> On 07/27/2016 07:25 PM, Svante Signell wrote: >>> >> (FTR: , code is more or less >> identical to the code in open-isns when it comes to sendmsg and >> re

Re: open-isns porting question: sudden SIGLOST

On Wed, 2016-07-27 at 23:38 +0200, Christian Seiler wrote: > On 07/27/2016 07:25 PM, Svante Signell wrote: > >  > (FTR: , code is more or less > identical to the code in open-isns when it comes to sendmsg and > recvmsg, but it works...) Does the open-isns code use

Re: open-isns porting question: sudden SIGLOST

(Adding bug-hurd to the Cc: list, not all developers follows the debian-hurd list) On Wed, 2016-07-27 at 18:15 +0200, Christian Seiler wrote: > Oh, I should mention that every time you run isnsadm the server > (isnsd) crashes with SIGLOST, so you need to restart it between > tries. > > Or you can

Re: [GSoC] Porting GuixSD to GNU/Hurd Update 1

Hi Manolis! Manolis Ragkousis skribis: > We already knew that the guix-daemon was not working properly on the > Hurd. I looked more into it and I found that if you do a build with > Guix and it fails, and then you retry again, the next one will create a > new build directory in /tmp/ as it shou

[GSoC] Porting GuixSD to GNU/Hurd Update 1

Hello everyone, One week passed since the beginning of the coding phase of GSoC, so I think it's time to give you an update on my progress. In the previous weeks I tried to get me prepared as much as possible and get a better idea of what needs to be done. I concentrated on getting familiar with

Re: [GSoC] Porting GuixSD to GNU Hurd draft

parts. I think I would rather let you focus on the GuixSD stuff as you > >>> wrote, but I’d like to hear what the Hurd folks think. > >> > >> I consider isolation more important. > > > > OK. > > Isolation first it is then. > > > So, Manolis

Re: [GSoC] Porting GuixSD to GNU Hurd draft

d like to hear what the Hurd folks think. >> >> I consider isolation more important. > > OK. Isolation first it is then. > So, Manolis, what about reframing the agenda such that porting > guix-daemon to GNU/Hurd comes first (I’d consider it roughly half of the > progra

Re: [GSoC] Porting GuixSD to GNU Hurd draft

working GuixSD system image with Hurd as the kernel. > > Hurd is not a kernel. I think we use “kernel” to mean “the thing(s) that libc talks to.” >> The main question is whether you should implement build isolation in >> guix-daemon, in which case that would leave little time for

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Quoting Manolis Ragkousis (2016-03-24 13:36:04) > > Hmmm, so one still needs a filesystem, right? That's going to be a > > bit tricky too, since whatever tool you use for that purpose, it > > surely does not support creating hurdish passive translator records. > > Without passive translator record

Re: [GSoC] Porting GuixSD to GNU Hurd draft

On 03/24/16 13:38, Justus Winter wrote: > Otoh if we could properly build packages, we could provide the > substitutes, so people could try Guix on the Hurd without going > through the 12h+ bootstrap procedure. Here the problem is not isolation but the fact that we don't have a substitutes server.

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Quoting Manolis Ragkousis (2016-03-24 12:18:25) > >>> The project consists of four main stages > >>> > >>> 1. Modify Guix so it will be able to create and mount the file-system > >>> needed to boot into a system with Hurd at its core. > >>> 2. Modify Guix so it can produce a working image, while

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hello Justus, Hello Ludo On 03/23/16 18:55, Justus Winter wrote: > Quoting Ludovic Courtès (2016-03-23 14:40:38) >>> 2. The Project >>> >>> The project consists of four main stages >>> >>> 1. Modify Guix so it will be able to create and mount the file-system >>> needed to boot into a system with

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hi, Quoting Ludovic Courtès (2016-03-23 14:40:38) > > 2. The Project > > > > The project consists of four main stages > > > > 1. Modify Guix so it will be able to create and mount the file-system > > needed to boot into a system with Hurd at its core. > > 2. Modify Guix so it can produce a worki

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hello! Manolis Ragkousis skribis: > Although I have uploaded and shared my draft to the GSoC website, I am > also resending it to the lists as per Ludovic's instruction. Yeah, the GSoC website makes it possible to provide a link to a text file, so let’s do that instead of using their SaaSS. >

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hello, Manolis Ragkousis, on Mon 21 Mar 2016 14:09:36 +0200, wrote: > Although I have uploaded and shared my draft to the GSoC website, I am > also resending it to the lists as per Ludovic's instruction. Looks very promising :) Samuel

[GSoC] Porting GuixSD to GNU Hurd draft

google.com/document/d/1NEEz_PHM2YZTm8okd2BgPRSc4c89I1fGnwbyeeEUrhw/edit?usp=sharing This is the time to share your ideas/corrections :-) Manolis Porting GuixSD to GNU/Hurd Manolis Ragkousis manolis...@gmail.com March 17, 2016 1. Summary In this project, we would like to port the Guix Software Distr

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

  1   2   3   >