Re: accept(2) returning a O_NONBLOCK socket

Hello, So I think my last attempt was misguided; attached is a simpler reproducer that exhibits the problem following these steps: 1. create a socket, bind it, and mark it as O_NONBLOCK; 2. select on that socket to wait for an incoming connection; 3. clear its O_NONBLOCK flag; 4. call acc

Re: accept(2) returning a O_NONBLOCK socket

Hi, yelni...@tutamail.com writes: > After spending a bit of time investigating I am a bit lost. I haven't > found anything that is for me obviously wrong, but have not yet fully > understood how things fit together. > > The only thing I have so far is that the flags of the wrong socket are > the

Re: streamio returning ED_WOULD_BLOCK

Samuel Thibault writes: > dev_read starts with if (err) return err;. Various functions do not > define their own err variable. I don't know the original reason for > this, but this looks fishy to me, and local variables should probably > always be used, patch welcome. I wondered about that: acce

Re: streamio returning ED_WOULD_BLOCK

Hey, Samuel Thibault writes: > Ludovic Courtès, le dim. 20 avril 2025 17:40:02 +0200, a ecrit: >> What happens here is that reading from /dev/klog (opened with >> O_NONBLOCK) returns ED_WOULD_BLOCK. However Guile and its concurrency >> framework (Fibers) don’t know about

streamio returning ED_WOULD_BLOCK

Hello, While running the Shepherd on the Hurd, I stumbled upon this: --8<---cut here---start->8--- System lacks support for 'signalfd'; using fallback mechanism. shepherd[1]: GNU Shepherd 1.0.4 (Guile 3.0.9, i586-pc-gnu) shepherd[1]: Starting service root... sh

Re: [RFC PATCH 0/2] On ldconfig and ld.so.cache

Hi, Sergey Bugaev skribis: > On Fri, May 19, 2023 at 2:52 PM Carlos O'Donell wrote: >> Removing configuration options and making it simple to configure and use >> glibc is great >> goal. I think that ldconfig should always be enabled and I don't see a >> downside to making >> `use_ldconfig=ye

Pushing a MiG release tarball?

Hello! Version 2.35 of glibc expects ‘const’-qualified parameters in MiG-generated stubs. Unfortunately, that feature is not is MiG 1.8, the latest release. Would you consider tagging a new release and uploading a tarball to ftp.gnu.org? The reason I’m asking is that Guix will need such a tarba

Re: Apparent deadlock in processes interacting with /hurd/fifo

Hi, Samuel Thibault skribis: > Ludovic Courtès, le ven. 25 nov. 2022 12:35:58 +0100, a ecrit: >> Let’s assume you do this: >> >> mkfifo fifo >> rpctrace cat fifo >> >> I think there’s at least one bug here: ‘dir_lookup’ should complete >>

Re: coreutils-8.32 test failure on i586-gnu

Hi, Samuel Thibault skribis: > It seems that replying on the web interface didn't work, so replying > again here by mail. Weird. > Ludovic Courtès, le mer. 26 oct. 2022 19:20:07 +0200, a ecrit: >> ludo@childhurd ~$ mkfifo fifo >> ludo@childhurd ~$ ls -l fifo >&g

Re: Apparent deadlock in processes interacting with /hurd/fifo

Ludovic Courtès skribis: > I think there’s at least one bug here: ‘dir_lookup’ should complete > immediately; it’s ‘io_read’ that should block. This issue also breaks a Coreutils test: https://issues.guix.gnu.org/58803 Ludo’.

Apparent deadlock in processes interacting with /hurd/fifo

Hello, Let’s assume you do this: mkfifo fifo rpctrace cat fifo In another terminal, you find the PID of ‘cat’ and run “kill PID”, twice. The second ‘kill’ command hangs. The ‘cat’ process, which was initially stuck in dir_lookup("fifo"), eventually fails to service the second kill request

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi, Ludovic Courtès skribis: > Of course, the thing boots just fine on that machine when using > ‘exec.static’. It’s frustrating I did not get to the bottom of it, but time passes, so I pushed this workaround in Guix commit 3fb3bd3da530a5f82a169b1fa451474f9d90c3b6. Ludo’.

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi, Ludovic Courtès skribis: > … so ‘exec_load’ is doing its job, it seems. Turns out that may not be the case. Here’s a *bad* mapping on the second ‘task_resume’ breakpoint (when ‘exec’ is about to start): --8<---cut here---start->8--- db&

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Ludovic Courtès skribis: > Through a dichotomy I tried to see how far it goes. The info I have so > far is that ld.so errors out from elf/rtld.c:563 (line 565 is not > reached): > > 558: if (bootstrap_map.l_addr || ! > bootstrap_map.l_info[VALIDX(DT_GNU_PRELINKED)])

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi! Ludovic Courtès skribis: > $ addr2line -e > /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1 > 0x1000 0x11627 0x11bb > ??:0 > /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/glibc-2.33/elf/dl-misc.c:333 > :? > > > That’s

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi Samuel, Samuel Thibault skribis: > About the backtrace: > >> user space < > 0x1000(bf24,0,0,1160b,0) > 0x11627(bf9c,0,0,0,2) > 0x11bb() > > That is quite surprising actually: in my ld.so there is nothing useful > at 0x1000. Perhaps you can check what 0x11627 is all about? Sur

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi! Samuel Thibault skribis: > Ludovic Courtès, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit: [...] >> Of course, the thing boots just fine on that machine when using >> ‘exec.static’. > > Uh. At least you have a workaround :) Yup. :-) >> So the issue migh

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Samuel Thibault skribis: > Ludovic Courtès, le jeu. 06 oct. 2022 15:14:13 +0200, a ecrit: >> such that it would stop on each trap, hopefully allowing me to see why >> exec is not starting. > > Also, better use exec.static to have static addresses. Thanks for the hint.

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi! As suggested by Samuel on IRC, I did that early on in kdb: debug traps /on such that it would stop on each trap, hopefully allowing me to see why exec is not starting. --8<---cut here---start->8--- module 0: ext2fs --multiboot-command-line=${kernel-comm

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hello! On AMD EPYC processors, as found on the build nodes of ci.guix.gnu.org, childhurd VMs fail to boot when running with ‘qemu-system-i386 -enable-kvm’ (the kvm-amd Linux kernel module is used), with the Hurd startup process hanging before /hurd/exec has been started: --8<---cut he

Re: [VULN 0/4] Hurd vulnerability details

Hi Samuel, Sergey, & all, Samuel Thibault skribis: > Ludovic Courtès, le mar. 09 nov. 2021 18:19:03 +0100, a ecrit: >> Am I right that the fixes have not been applied yet in the upstream >> repository? > > That's right. That's still waiting for the copyright a

Re: [VULN 0/4] Hurd vulnerability details

Hello, Samuel Thibault skribis: > Thanks a lot for this writing! That'll surely be an interesting read for > whoever wants to look a bit at the details of how the Hurd works. And of > course thanks for finding and fixing the vulnerabilities :) Seconded. It’s interesting both from a security pe

Re: Kernel crash with rtl8139 while restarting pfinet

Hi, Samuel Thibault skribis: > Ludovic Courtès, le dim. 24 oct. 2021 15:47:36 +0200, a ecrit: >> $ addr2line -e >> /gnu/store/acl9ffg0pjcj1hvzf8f5pz98xm0cqpps-gnumach-1.8-1.097f9cf/boot/gnumach >> 0xc10b1f5d 0xc105c6da 0xc1046209 0xc1040d25 0xc104a7a5 0xc1022252 >

Kernel crash with rtl8139 while restarting pfinet

Hello! I stumbled upon a crash while running GNU/Hurd in QEMU with rtl8139 emulation along these lines: qemu-system-i386 -enable-kvm -m 1024 -hda /gnu/store/mkvai2a97w702yhayv66y62kd7r2j1ps-disk-image \ -snapshot "--device" "rtl8139,netdev=net0" --netdev user,id=net0 The crash is pretty r

Re: Hurd Security vulnerabilities, please upgrade!

Hi Samuel, Samuel Thibault skribis: > Ricardo Wurmus, le mar. 10 août 2021 17:52:34 +0200, a ecrit: >> I’m a little unclear on what this means for distributions like Guix. Should >> we just update to the latest version from git? Are there specific commits >> we should use if it’s not just the

Re: Broken stack traces on crashed programs

Hi, Samuel Thibault skribis: > Ludovic Courtès, le mar. 17 nov. 2020 14:55:32 +0100, a ecrit: >> Samuel Thibault skribis: >> >> > Ludovic Courtès, le mar. 17 nov. 2020 10:57:43 +0100, a ecrit: >> >> I’ve noticed that I’d always get “broken” stack traces

Re: Broken stack traces on crashed programs

Hi! Samuel Thibault skribis: > Ludovic Courtès, le mar. 17 nov. 2020 10:57:43 +0100, a ecrit: >> I’ve noticed that I’d always get “broken” stack traces in GDB when (1) >> attaching to a program suspended by /servers/crash-suspend, (2) >> examining a core dump, or (3) spaw

Broken stack traces on crashed programs

Hello! I’ve noticed that I’d always get “broken” stack traces in GDB when (1) attaching to a program suspended by /servers/crash-suspend, (2) examining a core dump, or (3) spawning a program in GDB and examining it after it’s received an unhandled signal like SIGILL. At best I can see the backtra

Re: [PATCH] hurd: '_hurd_raise_signal' checks signal number is valid

Andreas Schwab skribis: > https://sourceware.org/git/?p=glibc.git;a=commit;h=785ec62dbd Thanks, I guess I was looking at a stale checkout, apologies! Ludo’.

[PATCH] hurd: '_hurd_raise_signal' checks signal number is valid

Previously, 'pthread_kill (pthread_self (), -1)' would wrongfully succeed: https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00152.html Reported-by: Jan Nieuwenhuizen --- hurd/hurd-raise.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hurd/hurd-raise.c b/hurd/hurd-raise.c inde

Re: raise(-1) succeeds for programs linked against libpthread

Samuel Thibault skribis: > Ludovic Courtès, le mar. 13 oct. 2020 15:41:37 +0200, a ecrit: >> ‘pthread_kill’ passes the signal number to ‘_hurd_raise_signal’, which >> assumes it is valid: > [...] >> I suppose that before calling ‘sigaddset’, it should check whether S

raise(-1) succeeds for programs linked against libpthread

Hi! (Cc: bug-hurd.) Jan Nieuwenhuizen skribis: >>> #include >>> >>> int >>> main (void) >>> { >>> if (!raise (-1)) >>> return 1; >>> >>> return 0; >>> } >> >> I don’t know if it’s relevant here, but you should always use ‘-pthread’ >> both at compile time and link time: >> >> gcc

Re: exec hang at boot.

Hi Almudena, Almudena Garcia skribis: > In Qemu, the boot looks fine, and the exec problems seem to have > disappeared. I tested It using gnumach in SMP mode (--enable-cpus=2). The new “childhurd” feature in Guix makes it easy (and safe) to test the kernel in QEMU. What would you suggest for u

Re: [BLOG] A "Hello World" VM running the Hurd!

Hi Samuel, Samuel Thibault skribis: > Jan Nieuwenhuizen, le mer. 08 avril 2020 22:02:25 +0200, a ecrit: >> Using Guix we have cross-built a VM image for the Hurd. Read more... >> >> >> https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-hurd/ > > It would be nice to h

Re: readlink("/proc/self/exe") with glibc 2.28 is broken?

Samuel Thibault skribis: > Samuel Thibault, le dim. 16 déc. 2018 16:53:08 +0100, a ecrit: >> Ludovic Courtès, le dim. 16 déc. 2018 16:44:54 +0100, a ecrit: >> > What is the glibc test you were referring to? >> >> make check > > I have now committed it. Awesome, thank you! Ludo’.

Re: readlink("/proc/self/exe") with glibc 2.28 is broken?

Hi Samuel, Samuel Thibault skribis: > Ludovic Courtès, le sam. 15 déc. 2018 23:10:39 +0100, a ecrit: >> Any particular reason why this patch hasn’t made it upstream? > > Most probably the answer is "nobody took the time to polish the patch > and run the glibc test with it

Re: readlink("/proc/self/exe") with glibc 2.28 is broken?

Ludovic Courtès skribis: > 137<--176(pid8674)->dir_lookup ("proc/self/exe" 65 0) = 0 1 "self/exe" > 191<--190(pid8674) > 191<--190(pid8674)->dir_lookup ("self/exe" 65 0) = 0 3 "pid/exe" (null) Looking more closely, I fou

readlink("/proc/self/exe") with glibc 2.28 is broken?

Hello hacker herd! The attached C code reads /proc/self/exe. I tested it on darnassus in two contexts: 1. Natively compiled with the Debian toolchain available on darnassus; 2. Cross-built with the GNU toolchain (which includes stock glibc 2.28) found in Guix, statically-linked. #1 wo

Re: Meta Learning the Hurd Stuff

Hi Joshua, Joshua Branson skribis: > So yesterday, I decided to write a GNU/Hurd translator in gnu guile. I think this is a worthy goal (Guile bindings would be lovely!), but maybe not the easiest way to get started since there are currently no Guile bindings to write Hurd translators. For a s

Re: Fwd: The GNU C Library version 2.28 is now available

Hello! Richard Braun skribis: > On Wed, Aug 01, 2018 at 09:53:59AM +0200, Samuel Thibault wrote: >> NEWS for version 2.28 >> = >> >> [...] >> >> * Building and running on GNU/Hurd systems now works without out-of-tree >> patches. > > I didn't think it would actually happe

Re: About GCC-5.5.0

Hello Rene, Rene skribis: > configure:6227: checking whether i586-pc-gnu-gcc implicitly enables > -fstack-protector > configure:6244: i586-pc-gnu-gcc -c -g -O2 conftest.c >&5 > configure:6244: $? = 0 > libc_undefs='' > configure:6263: error: unexpected symbols in test: This comes from this c

Re: Add a new exec_exec_file_name RPC

Hello! Samuel Thibault skribis: > For non-Debian distributions, you may want > to pick up the hurd exec_filename_ patches from > https://anonscm.debian.org/git/pkg-hurd/hurd.git/tree/debian/patches > and the local-exec_filename.diff patch from > https://anonscm.debian.org/cgit/pkg-glibc/glibc.gi

Re: boot the Hurd with Guix

Hi rennes, rennes skribis: > 1) Manually run : > > '/gnu/store/6fgz3s8fjva40hsdvs2hs0f5p4bw12jc-guile-static-stripped-2.2.2/bin/guile > > --version' > > Output: > > guile: warning: failed to install locale > .. > Uncaught exception: > Throw to key misc-error with args ("primitive-l

Re: boot the Hurd with Guix

Hi rennes, ren...@openmailbox.org skribis: > This is the demo generated with Guix: > > https://github.com/methalo/boot-hurd > > The binary files were generated in Debian/Hurd and placed in an 'img' file. > > The command used to generate the binaries is: > > './pre-inst-env guix system init ~/ligh

Re: boot the Hurd with Guix

Hi Samuel, :-) Samuel Thibault skribis: > Ludovic Courtès, on lun. 13 nov. 2017 11:42:01 +0100, wrote: >> PS: guix-daemon no longer depends on ‘lsof’, but it still depends on /proc. > > Does our procfs have everything it needs already? It needs /proc/PID/{exe,cwd,fd,maps,envi

Re: boot the Hurd with Guix

Hi rennes, (Something went wrong with your message headers.) ren...@openmailbox.org skribis: >>> Finally I was able to start the Hurd with the binaries generated with the >>> guix package manager. >> >> Woohoo! Does that mean you were able to run packages cross-compiled >> with Guix, or packa

Re: boot the Hurd with Guix

Hi rennes! ren...@openmailbox.org skribis: > Finally I was able to start the Hurd with the binaries generated with the > guix package manager. Woohoo! Does that mean you were able to run packages cross-compiled with Guix, or packages built natively with Guix? > At the moment the image of Hurd

Re: Documentation severely outdate on gnu.org

Samuel Thibault skribis: > Ludovic Courtès, on dim. 05 nov. 2017 18:37:06 +0100, wrote: >> Samuel Thibault skribis: >> > People find >> > https://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#dir >> > as documentation for the Hurd, which is just an

Re: Documentation severely outdate on gnu.org

Hi, Samuel Thibault skribis: > People find > https://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#dir > as documentation for the Hurd, which is just antique. Does anybody know > how to update this? See the bits about “Webpages repository” at

Re: guile 2.0.14 assertion failure

Howdy! Samuel Thibault skribis: > Manolis Ragkousis, on mar. 14 mars 2017 20:22:44 +0200, wrote: >> "scheme@(repl-server)> While reading expression:\nERROR: In procedure >> fport_fill_input: Resource temporarily >> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In >> proced

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

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: rpctrace man page

Hello! Thanks for taking care of the manual! Just a very very partial review… "Brent W. Baccala" skribis: > +@node rpctrace > +@section rpctrace The convention would be to call this section “Invoking rpctrace”, so: @node Invoking rpctrace @section Invoking @command{rpctrace} > +@example

Re: Time for another round of releases

Samuel Thibault skribis: > Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote: >> > Yes, but our current glibc tree is based on glibc 2.22, as guix needs >> > it. >> >> FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently >> i

Re: Time for another round of releases

Hi, Samuel Thibault skribis: > Svante Signell, on Tue 04 Oct 2016 12:27:12 +0200, wrote: >> On Sun, 2016-10-02 at 18:54 +0200, Justus Winter wrote: >> > it is October, therefore, it is time for a new set of releases :) >> > >> > I'll be going over the changes and update the NEWS files as usual,

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: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros

Thomas Schwinge skribis: > The next thought then occurred to me: why not use a programming language > that allows for defining additional types, powerful enough to model the > desired semantics? For example, if we'd compile the Hurd with a C++ > compiler (which, hopefully, will just work -- most

Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros

Samuel Thibault skribis: > Ludovic Courtès, on Sun 05 Jun 2016 21:53:35 +0200, wrote: >> Justus Winter skribis: >> > +#define Mach_port_check(NAME) \ >> > + void _Mach_port_check_##NAME(char *_unus

Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros

Justus Winter skribis: > +#define Mach_port_check(NAME) \ > + void _Mach_port_check_##NAME(char *_unused[] __attribute__ ((unused))) \ > + { \ > + if (MACH_PORT_VALID (NAME))

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

Re: A malware? and GPL infrigment?

Samuel Thibault skribis: > I have however been approached by clamav maintainers, who told me > that one such malware got ported to GNU/Hurd! They apparently "just" > rebuilt the malware using a GNU/Hurd cross tolchain (why not running > the qemu image?! Beats me). They however had to patch the so

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hi Justus, Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > 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

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 ideas

Manolis Ragkousis skribis: > On 03/02/16 23:31, Ludovic Courtès wrote: [...] >> Other options include calling out to the ‘settrans’ command (inelegant >> IMO), writing Guile bindings for some of the Hurd libraries, and/or some >> sort of a MiG in Scheme (neat but take

Re: Coppyright assignment

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Quoting Ludovic Courtès (2016-03-04 13:49:09) >> Justus Winter <4win...@informatik.uni-hamburg.de> skribis: >> >> > I have learned that not all GNU projects require this. For example, >> &

Re: Coppyright assignment

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > I have learned that not all GNU projects require this. For example, > GnuPG uses DCO [0], and Guix doesn't even seem to require that. > > Maybe we can change this policy for Hurd, GNU Mach, and MIG too? I general, we “cannot” (i.e., ar

Re: GSoC ideas

Samuel Thibault skribis: > Ludovic Courtès, on Wed 02 Mar 2016 11:09:28 +0100, wrote: >> Manolis Ragkousis skribis: >> > 1) Merge wip-hurd branch. >> > 2) Make the daemon handle chroot builds on the Hurd. >> > Note here that on the Hurd, one does not need

Re: GSoC ideas

Hi! I realize I hadn’t responded to Manolis. Another +1 from me! Some random comments: Manolis Ragkousis skribis: > Before May: > > 1) Merge wip-hurd branch. > 2) Make the daemon handle chroot builds on the Hurd. > Note here that on the Hurd, one does not need to be root to achieve > isolatio

Re: active translators stdout/stderr

Richard Braun skribis: > On Sun, Feb 14, 2016 at 10:09:37PM +0100, Samuel Thibault wrote: >> Hello, >> >> We have various issues with the active translators' stdout/stderr: >> >> - When mounting /proc from /etc/init.d/rc, stdout/stderr is closed, and >> thus as soon as e.g. mtab reports a war

Re: Rolling new releases

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > as agreed earlier, we're trying to produce two releases a year. We > released GNU Mach 1.5, GNU MIG 1.5, and GNU Hurd 0.6 in April, hence > it is time for our next release :) Don’t forget libc! :-) Ludo’.

Re: [GSoC update] Porting Guix to GNU/Hurd

Hi! Manolis Ragkousis skribis: > 1) Guix can successfully cross-build any package for the Hurd and produce > the bootstrap-tarballs to build packages with Guix natively on such a system. > > 2) Guix can build the native final toolchain. > > 3) Guix can build packages natively using the final too

Re: Problem with natively built binaries on Hurd from Guix

Hi Manolis, I just remembered how I addressed it when I cross-built the Hurd with Nix: Given that libc.so is an ld script on GNU/Hurd, simply add libhurduser.so and libmachuser.so in there, next to libc.so.0.3 (see

Re: Question with moving mount/umount logic in glibc

Roland McGrath skribis: > Frankly I think it would be better to keep these single-caller interfaces > out of libc proper. It's not really ideal that they are there for Linux > either, but syscall stubs are less of an issue than real code. While not ideal, I think it would greatly simplify porti

Re: Question with moving mount/umount logic in glibc

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Sounds awesome. One thing to be aware of (iirc) is that the > mount/umount code depends on the fstab parser. I'm not sure whether > it is needed for the mount/umount(2) interface, or just for the > command line frontend. I bet the for

Re: [GSoC] Guix + Hurd continuation

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Quoting Ludovic Courtès (2015-07-02 11:33:29) >> I think it would work anyway, but would end up starting one instance of >> /hurd/symlink for each symlink, which is suboptimal. > > No, /hurd/symlink doe

Re: [GSoC] Guix + Hurd continuation

l...@gnu.org (Ludovic Courtès) skribis: > 2. When building natively, surely you’ll find out that some packages > do not build (PATH_MAX!), and that there are assumptions in > hurd.scm and base.scm, such as the fact that GNU/Hurd is a > cross-compilation target and

[GSoC] Guix + Hurd continuation

Hello! Now that Manolis managed to produce the bootstrap binaries (yay!), we must plan for what’s next. I think the first thing will be to try and start building things natively, as noted in . That implies a few things: 0. Run G

Re: glibc build log (TLS-related issue)

Manolis Ragkousis skribis: > On 24 June 2015 at 12:17, Thomas Schwinge wrote: >>> and the same command with the tarballs sources end up with >>> >>> http://paste.lisp.org/display/150437 >> >> That looks like , >>

Re: GSoC: Porting Guix to Hurd week 3+4 report.

Thomas Schwinge skribis: > On Thu, 04 Jun 2015 22:48:48 +0200, l...@gnu.org (Ludovic > =?utf-8?Q?Court=C3=A8s?=) wrote: >> Manolis Ragkousis skribis: [...] >> autoreconf && ./configure --localstatedir=/var \ >> --with-libgcrypt-prefix=/gnu/store/... && make > > (Not relevant right now,

Re: GSoC: Porting Guix to Hurd week 3+4 report.

Manolis Ragkousis skribis: > Hey Thomas, thank you for looking into this. > > On 2 June 2015 at 18:55, Thomas Schwinge wrote: >> Shame on me, but I've never actively used/built Guix before. I do know >> about , and that there must be >> a Guix manual e

Re: GSoC: Porting Guix to Hurd week 3+4 report.

Hi Manolis, Thanks for the report! Manolis Ragkousis skribis: > 3) Found a circular dependency between glibc-hurd-headers and > hurd-minimal. Resolved it > and sent a patch to the list. (Ludovic please give it a look :-)) Will do shortly, sorry for the delay! > 4) tarball-package in make-boot

Re: GSoC: Porting Guix to Hurd week 2 report

Hello, Thanks for the update, it all seems to be on track! Hopefully the availability of the glibc-hurd tarball allow the code to be simplified, and the Hurd-specific parts of the glibc recipes to be reduced. > I was thinking about following Mark's suggestion of having a generic > glibc package

Re: glibc-2.19-hurd+libpthread-20150515

Thomas Schwinge skribis: > Snapshot uploaded: , and corresponding > Git tags glibc-2.19-hurd+libpthread-20150515 pushed to the Savannah glibc > and libpthread repositories. Wonderful! Manolis should feel relieved now. ;-) I thought this was 2.21, but 2.19 shoul

Re: GSoC: Porting Guix to Hurd week 1 report

Hello Manolis, Thanks for the detailed report! So I gather that something like: guix build --target=i686-pc-gnu coreutils sed tar works as expected on wip-hurd, right? Did you try running the resulting binaries on GNU/Hurd? ISTR there were problems in the past. Ludo’.

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

Samuel Thibault skribis: > Ludovic Courtès, le Thu 07 May 2015 14:42:10 +0200, a écrit : >> It would be nice to tag commits that correspond to glibc X.Y plus >> Hurd-specific patches. > > I'm not sure what exactly you mean. What I have done is tagging the > com

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

Samuel Thibault skribis: > Ludovic Courtès, le Wed 29 Apr 2015 21:40:13 +0200, a écrit : >> The last missing bit upstream is a libc-for-hurd tarball. > > I have prepared a master-glibc branch in the libpthread repo. Excellent! > $ git clone git.savannah.gnu.org:/srv/git/hurd

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

Andreas Enge skribis: > On Thu, Apr 30, 2015 at 12:01:44AM +0300, Manolis Ragkousis wrote: >> I just wanted to add that I will keep a repo at github which I will upload >> any >> (serious) local changes before I send them as patches so anyone can keep >> an eye on the current status of my work.

GSoC: Manolis to work on Guix port to GNU/Hurd

Hello! I’m pleased to announce that Manolis Ragkousis will (at last!) be working on the Guix port to GNU/Hurd as part of Google’s Summer of Code as described at . Manolis will be mentored by Samuel Thibault and myself. Manolis ac

Re: Release process & rolling new releases

Woohoo! Congratulations to everyone involved! :-) Ludo’.

Re: Hurd development

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Quoting Samuel Thibault (2015-01-16 12:08:07) >> Justus Winter, le Fri 16 Jan 2015 12:01:26 +0100, a écrit : [...] >> Also, don't you have commit access to the debian packaging? I guess >> that's one of the things we must fix. > > No

Re: Reinventing the Hurd server bootstrap

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Quoting Ludovic Courtès (2014-12-27 22:22:34) >> Did you consider using a statically-linked Guile? This is what we do in >> the Linux initrd for Guix, and it’s wonderful. :-) >> >> If you take tha

Re: Reinventing the Hurd server bootstrap

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Wait, that sounds like serverboot, doesn't it ? > > It does. I think it was a mistake to abandon it in the first place. > Evidence for that: 1. We now have two copies of the bootscript > parser, once in the kernel, once in boot. 2. W

Re: [PATCH hurd] libpager: use a fixed number of threads

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Quoting Samuel Thibault (2014-11-02 13:52:16) >> AIUI, this does work because you had previously separated disk and file >> pagers? > > Yes. > >> > + /* What follows is basically the second part of >> > + mach_msg_server_timeou

Re: Hurd server introspection and tracing

Hi, Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > * I use Machs `Inherited Ports' mechanism to install a receive right > at a well-known location to serve introspection requests. This is > by choice orthogonal to the usual mechanism used in the Hurd, as I > want it to be as

Re: Release process & rolling new releases

Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > I understand you took care of the release process last time. Is this > process documented somewhere? I think that we should make another > round of releases. In fact, we should make one or two releases each > year. At the very least

nscd fails to build

Hello! Manolis reported that nscd fails to build with Savannah’s libc, and with libpthread used as an add-on: --8<---cut here---start->8--- i686-pc-gnu-gcc getpwnam_r.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fro

Re: [PATCH] nscd: Remove unused typedef and variable.

Ondřej Bílka skribis: > On Sun, Jun 22, 2014 at 11:55:43AM +0200, Ludovic Courtès wrote: >> The attached patch removed the unused ‘thread_info_t’ typedef and the >> ‘thread_info’ variable from nscd.c. The former conflicts with a GNU Mach >> typedef, and the latter conf

[PATCH] nscd: Remove unused typedef and variable.

ted on x86_64-linux-gnu. Thanks, Ludo’. 2014-06-22 Ludovic Courtès * nscd/nscd.c (thread_info_t): Remove typedef. (thread_info): Remove variable. diff --git a/nscd/nscd.c b/nscd/nscd.c index 5680378..d4faa29 100644 --- a/nscd/nscd.c +++ b/nscd/nscd.c @@ -56,20 +56,6 @@ #

Re: Conflicting ‘thread_info_t’ declaration between nscd and Mach

Pino Toscano skribis: > On Saturday 21 June 2014 23:29:43 Ludovic Courtès wrote: >> Roland McGrath skribis: >> > Send a patch upstream to libc to avoid using the *_t name space for >> > non-public type names like the one in nscd. We'll take it. >> >&g

Re: Conflicting ‘thread_info_t’ declaration between nscd and Mach

Roland McGrath skribis: > Send a patch upstream to libc to avoid using the *_t name space for > non-public type names like the one in nscd. We'll take it. Great, will do. Manolis: could you confirm that the attached patch allows you to build libc for the Hurd with nscd support? diff --git a/n

  1   2   3   4   >