Re: GSoC ideas

[Christopher Allan Webber]

Manolis Ragkousis writes:

> Hello everyone,
>
> As I am still a student I would like to suggest continuing the project
> of porting Guix to GNU/Hurd in this GSoC as well, with the objective of
> having a working GuixSD/Hurd by the end of the summer.
>
> After discussions with Justus and Samuel in FOSDEM about the Guix-Hurd
> port I am starting to have a good idea on what is left to be done and
> the solution needed for the problems we have.
>
> So here's a preliminary timeline as well as a list of things to be done:
>
> 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
> isolation, so I should change the daemon to use this capability.
> 3) Instead of using the Linux syscall guile wrappers, I should modify
> Guix to use a more Hurdish way (i.e settrans) so later on we can handle
> translators and bootstrap a GNU/Hurd system.
> 4) Better understand how GuixSD startup works.
>
> May-August:
> 1) Implement the mechanisms for creating and mounting the initial
> filesystem and starting the system.
> 2) Implement the mechanisms to handle the Hurd servers in /hurd. I
> remember I was told that there may be an issue when the servers are not
> actually there (i.e all the binaries are in the /gnu/store). Would love
> if somebody could tell us more on that.
> 3) Isolate Linuxisms around Guix.
> 4) David Michael has made an excelent work on getting Shepherd working
> with Hurd so I don't think we will have any serious issues with the init
> daemon.
> 5) Others that will come up.. In the following weeks I will work closely
> with the Hurd guys to make sure we get a better understanding of
> everything and a detailed timeline.
>
> End of GSoC:
> Have a working GuixSD with Hurd as the kernel.
>
> Currently Justus (and others soon :-)) are testing Guix on their
> machines. We have some issues but we are working on them.
>
> Please feel free to add/correct anything from the above. Your
> comment/opinion may help to get things up and running faster :-)
>
> Finally I want to say that I will continue my work on this, regardless
> of GSoC or not, but I would like it if it was. :-)
>
> Thank you,
> Manolis

I can't speak for everyone else but it feels like this would be a great
project for you to contininue.  The guile-emacs project ran for a few
years, so I don't see any blocker on continuing, right?

[bug #15327] Hurd console missing login prompt when using ncurses driver over ssh

[Justus Winter]

Update of bug #15327 (project hurd):

  Status:None => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

I cannot reproduce it.  Works fine for me with xterm, rxvt, gnome-terminal,
and terminology.  The former two start out with a light background, the later
two with an dark background.  When the console is started, each terminal
switches to a dark background, and the result looks reasonable in each case.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [PATCH] Use libihash to store directory entries in ftpfs.

[Justus Winter]

Quoting Flavio Cruz (2016-02-07 21:53:53)
> * ftpfs/ftpfs.h: Add dir_locp for each directory entry and replace the table 
> with a libihash table.
> * ftpfs/dir.c: Modify the code to use libihash. Remove several functions such 
> as rehash and insert.

Your changelog entries are very long, please do reflow them to a
reasonable length.  I don't know what the reasonable length is, but I
always reflow them using meta-q in emacs.

> ---
> -
> 
> +
> [...]
> -
> 
> +
> [...]
> -
> 
> +
> [...]
> -
> 
> +
> [...]
> -
> 
> +
> [...]
> -
> 
> +
> [...]
> -
> 
> +
> [...]
> -
> 
> +

Your patch removes quite a lot of the form feed characters, is that on
purpose or an accident?  Fwiw, the coding conventions encourage their
use to break the source into logical segments.

Justus

[bug #26476] rpctrace cannot trace messages sent to the host port

[Justus Winter]

Update of bug #26476 (project hurd):

  Status:None => Confirmed  
 Summary: rpctrace cannot handle host_processor_sets() =>
rpctrace cannot trace messages sent to the host port

___

Additional Item Attachment:

File name: rpctrace-test.cSize:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: GSoC ideas

[Manolis Ragkousis]

Hello everyone,

As I am still a student I would like to suggest continuing the project
of porting Guix to GNU/Hurd in this GSoC as well, with the objective of
having a working GuixSD/Hurd by the end of the summer.

After discussions with Justus and Samuel in FOSDEM about the Guix-Hurd
port I am starting to have a good idea on what is left to be done and
the solution needed for the problems we have.

So here's a preliminary timeline as well as a list of things to be done:

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
isolation, so I should change the daemon to use this capability.
3) Instead of using the Linux syscall guile wrappers, I should modify
Guix to use a more Hurdish way (i.e settrans) so later on we can handle
translators and bootstrap a GNU/Hurd system.
4) Better understand how GuixSD startup works.

May-August:
1) Implement the mechanisms for creating and mounting the initial
filesystem and starting the system.
2) Implement the mechanisms to handle the Hurd servers in /hurd. I
remember I was told that there may be an issue when the servers are not
actually there (i.e all the binaries are in the /gnu/store). Would love
if somebody could tell us more on that.
3) Isolate Linuxisms around Guix.
4) David Michael has made an excelent work on getting Shepherd working
with Hurd so I don't think we will have any serious issues with the init
daemon.
5) Others that will come up.. In the following weeks I will work closely
with the Hurd guys to make sure we get a better understanding of
everything and a detailed timeline.

End of GSoC:
Have a working GuixSD with Hurd as the kernel.

Currently Justus (and others soon :-)) are testing Guix on their
machines. We have some issues but we are working on them.

Please feel free to add/correct anything from the above. Your
comment/opinion may help to get things up and running faster :-)

Finally I want to say that I will continue my work on this, regardless
of GSoC or not, but I would like it if it was. :-)

Thank you,
Manolis

[bug #17119] user space (fftw application) crashing the system

[Justus Winter]

Update of bug #17119 (project hurd):

  Status:None => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

I just ran the fftw test suite a hundred times, without any ill-effect.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #19765] ext2fs: different behavior of an active translator and a translator started from a passive translator setting

[Justus Winter]

Update of bug #19765 (project hurd):

  Status:None => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

teythoon@hurdbox /var/tmp % uname -a
GNU hurdbox 0.7 GNU-Mach 1.6-686-dbg/Hurd-0.7 i686-AT386 GNU
teythoon@hurdbox /var/tmp % dd of=trash.img bs=1M count=0 seek=50 
0+0 records in
0+0 records out
0 bytes copied, 0 s, Infinity B/s
teythoon@hurdbox /var/tmp % /sbin/mkfs.ext2 -F -b 4096 trash.img 
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 12800 4k blocks and 12800 inodes

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

teythoon@hurdbox /var/tmp % settrans -cp trash /hurd/ext2fs `pwd`/trash.img 
teythoon@hurdbox /var/tmp % cd trash
teythoon@hurdbox /var/tmp/trash % ls
lost+found/


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #15321] pflocal memory leak ?

[Justus Winter]

Update of bug #15321 (project hurd):

  Status:   Need Info => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

I've never seen such a problem either, and I recently piped 8 tb through
pflocal without seeing any sign of any kind of leak.  I'd say it is not
reproducible anymore.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #15299] ranlib causes kernel panics

[Justus Winter]

Update of bug #15299 (project hurd):

  Status:   Confirmed => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

This bug report is 15 years old, the allocator in question is gone, and we're
in the middle of revamping the allocator once again.  The report is no longer
relevant.  Feel free to reopen if you disagree.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: GSoC ideas

[Andreas Enge]

On Thu, Feb 11, 2016 at 01:46:30PM +0200, Manolis Ragkousis wrote:
> As I am still a student I would like to suggest continuing the project
> of porting Guix to GNU/Hurd in this GSoC as well, with the objective of
> having a working GuixSD/Hurd by the end of the summer.

Sounds great, I hope it will go through!

Andreas