Re: [PATCH rust] Add new target for GNU/Hurd

[Amos Jeffries]

Yay! :-)

Armchair review comments inline..

On 9/07/23 22:05, Damien Zammit wrote:

This is not quite right for library/std, but applies clean to a 2021 tree
of rust on hash 25ea6be13e3 and allows up to the following stage1 build
until libstd breaks on hurd, (with the other patch for rust-libc).



...



diff --git a/compiler/rustc_codegen_llvm/Cargo.toml 
b/compiler/rustc_codegen_llvm/Cargo.toml
index 4999cb3c7ab..39e09a28692 100644
--- a/compiler/rustc_codegen_llvm/Cargo.toml
+++ b/compiler/rustc_codegen_llvm/Cargo.toml
@@ -11,7 +11,7 @@ doctest = false
  [dependencies]
  bitflags = "1.0"
  cstr = "0.2"
-libc = "0.2"
+libc = { path = "../../../rust-libc" }


Would it be possible for stage1 to simulate the library being in its 
normal place instead of patching the paths?





diff --git a/library/std/src/os/hurd/mod.rs b/library/std/src/os/hurd/mod.rs
new file mode 100644
index 000..497a51a1df6
--- /dev/null
+++ b/library/std/src/os/hurd/mod.rs
@@ -0,0 +1,6 @@
+//! OpenBSD-specific definitions
+


 "OpenBSD" ?



+#![stable(feature = "raw_ext", since = "1.1.0")]
+
+pub mod fs;
+pub mod raw;
diff --git a/library/std/src/os/hurd/raw.rs b/library/std/src/os/hurd/raw.rs
new file mode 100644
index 000..475fcdcc4aa
--- /dev/null
+++ b/library/std/src/os/hurd/raw.rs
@@ -0,0 +1,83 @@
+//! NetBSD-specific raw type definitions
+


 "NetBSD" ?



diff --git a/library/std/src/sys/unix/net.rs b/library/std/src/sys/unix/net.rs
index e6b61062d15..2b5f5b917e9 100644
--- a/library/std/src/sys/unix/net.rs
+++ b/library/std/src/sys/unix/net.rs


AFAICS, these should perhapse be in alphabetical order.



@@ -61,6 +61,7 @@ pub fn new_raw(fam: c_int, ty: c_int) -> io::Result {
  target_os = "freebsd",
  target_os = "illumos",
  target_os = "linux",
+target_os = "hurd",
  target_os = "netbsd",
  target_os = "opensbd",
  ))] {
@@ -98,6 +99,7 @@ pub fn new_pair(fam: c_int, ty: c_int) -> io::Result<(Socket, 
Socket)> {
  target_os = "freebsd",
  target_os = "illumos",
  target_os = "linux",
+target_os = "hurd",
  target_os = "netbsd",
  target_os = "opensbd",
  ))] {
@@ -203,6 +205,7 @@ pub fn accept(&self, storage: *mut sockaddr, len: *mut socklen_t) 
-> io::Result<
  target_os = "freebsd",
  target_os = "illumos",
  target_os = "linux",
+target_os = "hurd",
  target_os = "netbsd",
  target_os = "opensbd",
  ))] {
@@ -278,6 +281,7 @@ pub fn recv_from(&self, buf: &mut [u8]) -> io::Result<(usize, 
SocketAddr)> {
  target_os = "emscripten",
  target_os = "freebsd",
  target_os = "linux",
+target_os = "hurd",
  target_os = "netbsd",
  target_os = "openbsd",
  ))]
@@ -309,6 +313,7 @@ pub fn is_write_vectored(&self) -> bool {
  target_os = "emscripten",
  target_os = "freebsd",
  target_os = "linux",
+target_os = "hurd",
  target_os = "netbsd",
  target_os = "openbsd",
  ))]



HTH
Amos

Re: [PATCH] Updated information about the rump kernels, and included a guide on how to use them on the Debian qemu image.

[Amos Jeffries]

On 23/05/2023 5:23 am, Joshua Branson wrote:

Sergey Bugaev writes:


Hi,

On Mon, May 22, 2023 at 6:49 PM jbra...@dismail.de wrote:

+upgrade to the bleeding edge Debian GNU/Hurd:
+
+ $ wget
http://ftp.de.debian.org/debian/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2023.02.01_all.deb
+ # dpkg -i debian-ports-archive-keyring_2023.02.01_all.deb

Is this secure though? You're fetching a package through unprotected
HTTP, then installing it as a trusted keyring.

Probably not.  I actually just copied janneke's recent email.  I have
not executed the above commands.  Is there a more secure way to install
that keyring?


The best way is:
  apt install -t sid debian-ports-archive-keyring

That way leaves security to the apt system.
Details of what to place in /etc/apt/sources/list.d/debian-ports.list to 
get access to the archive may also be useful here.



HTH
Amos

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

[Amos Jeffries]

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 this been discussed anywhere?

It is entirely possible that I made up the plan to drop 32-bit support.
I thought I had seem someone say that was the plan...


Maybe you mistook the talk about one flavour of 64-bit Mach not having 
USER32 support for lack of 32-bit Mach.

The two are not the same 32-bit.


Amos

Re: [RFC PATCH 2/3] hurd: Implement O_TMPFILE

[Amos Jeffries]

On 13/12/2022 12:46 am, Sergey Bugaev wrote:

@@ -90,6 +95,21 @@ __file_name_lookup_at (int fd, int at_flags,
  }
  }
  
+  if ((orig_flags & __O_TMPFILE) == __O_TMPFILE)

+{
+  /* What we have looked up is not the file iteself, but actually


s/iteself/itself.\/


+ the directory to create the file in.  Do that now.  */
+  file_t dir = result;
+
+  err = __dir_mkfile (dir, orig_flags & ~O_TMPFILE, mode, &result);
+  __mach_port_deallocate (__mach_task_self (), dir);
+  if (err)
+{
+  __hurd_fail (err);
+  return MACH_PORT_NULL;
+}
+}
+
return result;
  }
  


HTH
Amos

Re: [PATCH] mig: explicitly use -std=gnu11

[Amos Jeffries]

On 24/11/2022 5:41 am, Flavio Cruz wrote:

On Wed, Nov 23, 2022 at 11:51:36AM +0100, Samuel Thibault wrote:

Flavio Cruz, le mer. 23 nov. 2022 00:10:10 -0500, a ecrit:
Latest GCC will pick up gnu17 by default but gnu11 will be better 
supported with older compilers.


Mmm, but why explicitly requesting gnu11 then? Latest GCC will be fine
with using gnu17, and older GCC will be fine with using whatever it
supports.


I would like to modernize some parts of the mig code (for example, use 
stdbool.h instead of setting up our own boolean type). For this, gnu99 
would be enough but I thought gnu11 would be fine since it has been 
around

for some time.




FWIW, From experience with other code using the -std=*11 options:
This will not just downgrade the specification on latest compilers, but 
at times disable newer code safety checks. Making some types of bugs 
more difficult to detect.


/2c

HTH
AYJ

Re: [PATCH] hurd/translator/httpfs.mdwn: I added a Intro, how to use, and TODO section. hurd/translator/xmlfs.mdwn: I added a How to use and TODO wishlist section.

[Amos Jeffries]

Sorry, not quite. :(

On 10/09/20 11:49 am, Joshua Branson wrote:
> +
> +# settrans -a tmp/ /hurd/httpfs 
> https://www.gnu.org/software/hurd/index.html
> +

"https://"; is not supported sadly. Just "http://"; scheme.


Amos

Re: [PATCH] httpfs: fix HEAD request message

[Amos Jeffries]

On 10/09/20 5:16 am, Samuel Thibault wrote:
> Amos Jeffries, le jeu. 10 sept. 2020 04:16:54 +1200, a ecrit:
>> The HEAD request used to fetch metadata about a file via HTTP
>> contains a trailing 0x20 character which will cause modern HTTP/1.1
>> servers to reject the request.
> 
> Commited, thanks!
> 
> I'm thinking that this should all be using \r\n instead of \n?
> 

In this case it means two line terminators. So "\n\n" or "\r\n\r\n".

Amos

[PATCH] httpfs: fix HEAD request message

[Amos Jeffries]

The HEAD request used to fetch metadata about a file via HTTP
contains a trailing 0x20 character which will cause modern HTTP/1.1
servers to reject the request.

===
RCS file: /sources/hurdextras/httpfs/http.c,v
retrieving revision 1.3
diff --unified -r1.3 http.c
--- http.c  25 Jan 2013 00:50:58 -  1.3
+++ http.c  9 Sep 2020 16:15:02 -
@@ -110,7 +110,7 @@
}

/* Send a HEAD request find header length */
-   sprintf(buffer,"HEAD %s HTTP/1.0 \n\n",node->conn_req);
+   sprintf(buffer,"HEAD %s HTTP/1.0\n\n",node->conn_req);
towrite = strlen (buffer);
written = TEMP_FAILURE_RETRY (write (*fd, buffer, towrite));
if ( written == -1 || written < towrite )

Re: [PATCH] hurd/translator/httpfs.mdwn: I added a Intro, how to use, and TODO section. hurd/translator/xmlfs.mdwn: I added a How to use and TODO wishlist section.

[Amos Jeffries]

With my hat on as an IETF HTTPbis WG member. Here are some editorial
nits in regards to HTTP protocol things being mentioned ...


On 10/09/20 2:29 am, Joshua Branson wrote:
> I copied most of the text from the Hurd extras repos.
> ---
>  hurd/translator/httpfs.mdwn | 68 
>  hurd/translator/xmlfs.mdwn  | 77 +
>  2 files changed, 145 insertions(+)
> 
> diff --git a/hurd/translator/httpfs.mdwn b/hurd/translator/httpfs.mdwn
> index 8b02aa06..97feb291 100644
> --- a/hurd/translator/httpfs.mdwn
> +++ b/hurd/translator/httpfs.mdwn
> @@ -12,6 +12,74 @@ License|/fdl]]."]]"""]]
>  
>  While the httpfs translator works, it is only suitable for very simple use 
> cases: it just provides the actual file contents downloaded from the URL, but 
> no additional status information that are necessary for interactive use. 
> (Progress indication, error codes, HTTP redirects etc.)
>  
> +# Intro
> +INTRODUCTION:
> +
> +Here we describe the structure of the /http filesystem for the Hurd.
> +Under the Hurd, we provide a translator called 'httpfs' which is intended
> +to provide the filesystem structure.
> +
> +The httpfs translator accepts an URL as an argument. The underlying node of 
> the

"URL" can mean a lot of things, including mailto:j...@example.com.
Since this translator is for HTTP protocol specifically this should say
"http:// URL" to avoid other URLs being used (eg https://).

> +
> +# How to Use httpfs
> +
> +# settrans -a tmp/ /hurd/httpfs www.hurd-project.com/
> +

The above does not contain a valid HTTP URL. It is one type of URL the
translator supports, but that form is not valid in modern software.

Luckily the translator does already accept absolute-URI. So this and the
below two references should say:

 settrans -a tmp/ /hurd/httpfs http://www.hurd-project.com/



> + specific file like www.hurd-project.com/httpfs.html >
> +
> +# cd tmp/
> +
> +# ls -l
> +
> +# settrans -a tmp/ /hurd/httpfs www.hurd-project.com/ 
> --proxy=192.168.1.103
> + --port=3126
> +
> +The above command should be used in case if the access to the Internet is
> +through a proxy server, substitute your proxies IP and port no.s
> +
> +# TODO
> +
> +- Teach httpfs to understand HTTP status codes like re-directs, 404 not 
> found,
> +  etc.
> +
> +- Teach httpfs to look for "sitemaps".  Many sites offer a sitemap, and this
> +  would be a nifty way for httpfs to allow grep-ing the entire site's 
> contents.


Some more potential TODOs for todays HTTP environment:

 - https:// support
 - scheme-relative URL support (eg. "//example.com/")
 - query-string and fragment support
 - HTTP/1.1 support
 - HTTP/2 support
 - HTTP/3 support


HTH
Amos

Re: [PATCH] SMP initialization: detection and enumeration OFF TOPIC PRAISE

[Amos Jeffries]

On 12/08/20 12:17 am, Almudena Garcia wrote:
>> You can use b (break) within a git rebase session to stop at some point.
>> That way you can stop before the big change, commit part of it, and use
>> git rebase --continue, and let git discover that part of the big change
>> is already there and drop it from the big change.
> 
> But I have tons of commits. Is there any simple way to only take the
> latest version of each file and generate a set of commits for them?
> 

Is your branch public? I can take some time to go over the history and
make suggestions on cleaning it up if you like.


Amos

Re: [PATCH] SMP initialization: detection and enumeration OFF TOPIC PRAISE

[Amos Jeffries]

On 11/08/20 11:57 pm, Samuel Thibault wrote:
> Almudena Garcia, le mar. 11 août 2020 13:45:19 +0200, a ecrit:
>>> P.S.  You might be interested in using the program git send-email.
>>> Apparently it makes it really easy to send in a patches series.  It's
>>> actually what GNU Guix contributing guidelines recommends.
>> My problem is that, in my internal repository, I do many commits for each
>> change (even for each file). The development is progressive.
>> Then, if I take the commit history to generate my patches, I would generate
>> many spurious patches, making it very difficult to check and apply them.
> 
> Sure, that's a common thing when developping.
> 
>> Even doing a rebase over another branch, the rebase adds the commit history, 
>> so
>> I keep the same problem.
> 
> ? On the contrary, rebase lets you decide what exactly you keep in the
> history and what you squash.
> 

Almundena:

To clarify in case you are not aware. The "rebase -i" operation is what
is being suggested. The -i option enables much more flexibility of
control over the patch sequence and history during rebase.


HTH
Amos

Re: Wiki Edits: a smattering of small changes

[Amos Jeffries]

On 17/12/18 10:56 am, Joshua Branson wrote:
> Amos Jeffries  writes:
> 
>> On 16/12/18 6:17 am, Almudena Garcia wrote:
>>> Can you add a new FAQ about 64 bit support?
>>> Or, if exists, modify It to add this link
>>> https://www.gnu.org/software/hurd/open_issues/64-bit_port.html
>>>
>>
>> The rebootstrap link on that page is outdated and now a 404.
>> The job name should be "rebootstrap_hurd-amd64_gcc8" (not "gcc7").
> 
> Thanks, I'll add this to my wiki changes.
> 
>>
>> After looking at the i386 job failures I have some doubts about what
>> that Jenkins Job is doing for the bootstrap. It seems odd that the
>> "linux-src/" sprinkled liberally with "linux/*.h" includes should be the
>> code trying to be built. I thought there was a Hurd+Mach alternative of
>> it nowdays?
>>
>> Also does the TODO list at the top of the page have any particular order
>> that things need to be implemented to get it done?
> 
> I think so.  Take a look at
> 
> https://www.gnu.org/software/hurd/open_issues/64-bit_port.html
> 
> What is left for initial support (32-on-64) is
> 
> adding 64bit boot support from grub
> implement 32/64 RPC compatibility for RPCs served by kernel.
> 


Thats the page I am looking at. I see two lists for different flavours
of 64-bit. But no indication whether things like MID ABI definition are
blocking binutils which blocks GCC and such.

Making that explicit would help anyone (like myself) with less time to
know whether they are able to dedicate some time yet, or waiting on
something others need to do first.

AYJ

Re: Wiki Edits: a smattering of small changes

[Amos Jeffries]

On 16/12/18 6:17 am, Almudena Garcia wrote:
> Can you add a new FAQ about 64 bit support?
> Or, if exists, modify It to add this link
> https://www.gnu.org/software/hurd/open_issues/64-bit_port.html
> 

The rebootstrap link on that page is outdated and now a 404.
The job name should be "rebootstrap_hurd-amd64_gcc8" (not "gcc7").

After looking at the i386 job failures I have some doubts about what
that Jenkins Job is doing for the bootstrap. It seems odd that the
"linux-src/" sprinkled liberally with "linux/*.h" includes should be the
code trying to be built. I thought there was a Hurd+Mach alternative of
it nowdays?

Also does the TODO list at the top of the page have any particular order
that things need to be implemented to get it done?

AYJ

Re: Hurd Fork: Announcement & Invitation

[Amos Jeffries]

On 21/07/18 09:37, Ranvijay Kumar Vijay wrote:
> Dear All,
> 
> I've created a HURD Bazaar fork,

Er, are you aware that "Bazaar" is already taken by a VCS system? it is
going to be very confusing to have something called a "Bazaar fork" when
it is actually a git fork, not managed by Bazaar.


> because I've seen discussions on the
> net where people didn't want to be a part of Hurd just because it
> requires Copyright assignment to FSF.
> 
> I personally think they are mistaken, but have created this project to
> save time from clearing their misunderstandings.
> 

While your intentions may be pure, this looks more like an attempted
hijack to me.

The result is likely to distract people not already involved with the
copyright disagreement and place their work into an area which cannot be
fed back to the Hurd itself. Due to the explicit copyright intentions of
those people you mention, their work and anything relying on it directly
(as the forked code would) cannot be submitted to the FSF project for
inclusion in Hurd.

So the most likely outcomes will either be a large increase in porting
work placed on the shoulders of the already limited Hurd community, or
moving control of the Hurd brand away from the FSF over to yourself.

AYJ

Re: Enable SMP support

[Amos Jeffries]

On 15/06/18 10:31, Almudena Garcia wrote:
> Yes, I concluded the same a few hours ago. I tried to edit
> kern/cpu_number.h, to add a new definition with many cores, at this form
> 
> int master_cpu; /* 'master' processor - keeps time */
> 
> #if (NCPUS == 1)
>     /* cpu number is always 0 on a single processor system */
> #define cpu_number()    (0)
> 
> #define CPU_L1_SIZE (1 << CPU_L1_SHIFT)
> 
> #else
> #define cpu_number() (NCPUS)
> 

I may be wrong, but that does not seem correct.

The man page for cpu_number() state it to be "an unique CPU
identification number for the CPU that this thread is running on". So it
clearly can change at runtime if there are 2+ CPUs on the machine.

Whereas NCPUS is being used by the precompiler as an integer with fixed
value that can be known at pre-compile time. Implied by the "#if NCPUS >
1" statement which this version of the code omits.


AYJ

Re: Some Hurd related thoughts from someone who has no right to talk

[Amos Jeffries]

On 09/06/18 04:53, Joshua Branson wrote:
> Amos Jeffries writes:
> 
>> On 08/06/18 04:58, Joshua Branson wrote:
>>>
>>> I would actually recommend that you just run the Hurd in qemu.  Most, if
>>> not all, of the main Hurd developers just run the Hurd inside qemu.
>>>
>>> Also a cool idea!  I believe I read somewhere that it possible to have
>>> the Hurd running in qemu, but make the X server run in Linux.  This is
>>> apparently a really stable way to run the Hurd.
>>>
>>> Also, maybe you and I could try to start up a GNU/Hurd hangout session.
>>> Kind of like the Emacs hangouts.
>>>
>>
>> Speaking of that. I tried to follow the instructions at
>> <https://www.gnu.org/software/hurd/hurd/running/qemu.html> yesterday. It
>> seems to be very much in need of updating.
> 
> Are you sure?  Which ones don't work?
> 

The section is talking about qemu, but as a newbie having installed the
qemu package (apt says successfully) the "kvm" command still will not
work.  It needs the qemu-kvm package specifically.

And most of the URLs mentioned are outdated, more updated ones seem to
be listed inside the README.



> I've never had a problem with the first two:
> $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz
> $ tar -xz < debian-hurd.img.tar.gz
> 

"HTTP/1.1 400 Bad Request"

Location:
https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.tar.gz

Samuel seems to only have a Hurd repo in his directory now. Not the
built images.


> I have had problems with the last command:
> 
> $ kvm -m 1G -drive cache=writeback,file=$(echo debian-hurd-*.img)
> 
> mainly that "kvm" is not the command you use.  I've always had to run
>   qemu-system-i386.
> 

The kvm command seemed to work fine once I moved to other documentation
about KVM instead of qemu had me uninstall qemu and install the qemu-kvm
package.


AYJ

Re: Some Hurd related thoughts from someone who has no right to talk

[Amos Jeffries]

On 08/06/18 04:58, Joshua Branson wrote:
> 
> I would actually recommend that you just run the Hurd in qemu.  Most, if
> not all, of the main Hurd developers just run the Hurd inside qemu.
> 
> Also a cool idea!  I believe I read somewhere that it possible to have
> the Hurd running in qemu, but make the X server run in Linux.  This is
> apparently a really stable way to run the Hurd.
> 
> Also, maybe you and I could try to start up a GNU/Hurd hangout session.
> Kind of like the Emacs hangouts.
> 

Speaking of that. I tried to follow the instructions at
 yesterday. It
seems to be very much in need of updating.

Since the section is about use on Debian it should at least mention the
packages (qemu-kvm) that need installing for the kvm command to work
properly. The links are also all stale, though at least there are
working redirectors in place.

AYJ

Re: [PATCH] hurd libpthread: Copyright blurb updates

[Amos Jeffries]

On 02/03/18 03:45, Samuel Thibault wrote:
> Amos Jeffries, on ven. 02 mars 2018 03:37:17 +1300, wrote:
>> Joseph also asked in the other thread for "Contributed by" lines not to
>> be added in new files. There are a few in this code, but the files
>> creation are usually very old - late 1990's early 2000's - so I am not
>> sure if they really qualify as "new".
>>  Should I remove or leave?
> 
> I don't really know, I would say ask the glibc mailing list. For the
> Drepper, Jelinek, and Kylheku contributions, these are basically copies
> from glibc, so I'm not sure whether we are supposed to keep them.

Okay, I will leave for now and see what upstream says for the merger.

Is there anything else I should include or do to get this part of the
updates applied and over with?

AYJ

[PATCH] hurd libpthread: Copyright blurb updates

[Amos Jeffries]

This patch updates the copyright blurbs in libpthread repository to
match upstream glibc requested format.

Specific changes are:

 * use -2018 for copyright dates

 * replace obsolete FSF address with current gnu.org URL reference from
glibc.


Joseph also asked in the other thread for "Contributed by" lines not to
be added in new files. There are a few in this code, but the files
creation are usually very old - late 1990's early 2000's - so I am not
sure if they really qualify as "new".
 Should I remove or leave?

AYJ

Re: [PATCH] hurd: add gscope support

[Amos Jeffries]

On 01/03/18 14:23, Samuel Thibault wrote:
> Joseph Myers, on jeu. 01 mars 2018 01:17:18 +, wrote:
>> Missing spaces before '(' in the calls to atomic_increment, 
> 
> etc.
> 
> Can people _please_ help me with all these? (not only on that patch, but
> on the whole set of patches which we *DO* need to get into upstream,
> otherwise we'll just get pushed out. As a reminder, here is the
> remaining set:
> 
> - the whole libpthread repository

Okay, I am diving in on this one.

Before I go far off the rails some questions:

- the repo to work on is git://git.savannah.gnu.org/hurd/libpthread.git
right?

- where is the upstream repo to diff the savanna master against?
  you said the hurd wiki, but neither of the ones I know of say.



Starting with Joseph Meyers review comment " Use -2018 in
copyright notices."

 - was that copyright only to be updated on files which are touched by
Hurd changes?

  - or a blanket bump to the end-year across all files with a copyright
blurb?

Cheers
AYJ

Re: Glibc port: commit clenup

[Amos Jeffries]

On 20/02/18 11:03, Samuel Thibault wrote:
> Samuel Thibault, on lun. 19 févr. 2018 19:04:57 +0100, wrote:
>> See the branches there, they already exist.
>>
>>> and ask you to commit upstream upstream?
>>
>> If it was a matter of committing, that'd be done already... See what I
>> wrote on 18 Jan 2018:
>>
>> «
>> Most of them don't have changelog, have formatting issues, etc.  That's
>> what needs to be fixed until we can commit them.
>> »
> 
> One thing I hadn't written explictly: the whole hurd libpthread
> repository needs the same formatting checkup before being able to import
> it into upstream glibc.  That's where a lot of help would be very
> welcome :)
> 
> Samuel
> 

By "whole repository" do you mean the history needs rewriting for
changelog automation, or just the working tree HEAD?

I expect to have a bit of time spare in the next month or so.

AYJ

flock() LOCK_UN support on Hurd

[Amos Jeffries]

I am facing a small portability issue on Hurd. Specifically missing 
definition of LOCK_UN for use as flock() parameter when compiling

 <http://bazaar.launchpad.net/~squid/squid/4/view/head:/src/base/File.h>

There seems to be work from 2001/2002 and a GSoC from 2014 making 
patches, but these do not appear to be in the current Hurd build on 
Debian through the expected fcntl.h include.


We need the flock() semantic of reliable atomic locking on files for 
multi-process shared file access between otherwise independent processes.


Am I missing something as simple as an include?
or, are there any alternatives available on Hurd?


Amos Jeffries

Re: [GSoC 2017] IPv6

[Amos Jeffries]

On 07/07/17 03:19, Samuel Thibault wrote:

Hello,

Nice progress :)

Joan Lledó, on dim. 02 juil. 2017 10:29:33 +0200, wrote:

the stack offers the option of
using DAD[2] to check if the address is already in use. This isn't
likely to happen, since the interface identifier is based on the link
address, which should be unique, but I left it enabled just in case.


Yes. It does happen sometimes (particularly with VMs) that there are
duplicates. DAD can also be useful when configuring IPv6 by hand.


Also in the case where there are non-coordinated DHCPv6 servers offering 
potentially overlapping prefix(s).


DHCP collision is a fairly easy attack vector in IP (v4 and v6), so a 
mechanism other than implicitly trusting the DHCP server(s) is useful to 
get out of trouble.


AYJ

Re: Booting/Installing Debian Hurd from DVD not possible

[Amos Jeffries]

On 19/12/2015 6:53 a.m., Samuel Thibault wrote:
> David Renz, on Fri 18 Dec 2015 18:49:11 +0100, wrote:
>> if it really wouldn't be supported by Debian Hurd, then the installation
>> process couldn't even reach that stage, isn't it?
> 
> Yes it would: loading the kernel and initrd is done by grub through the
> help of the BIOS legacy interface.
> 
>> Basically Debian Hurd SHOULD definitely be able to work in a Virtual Box VM,
>> isn't it?
> 
> Yes, in theory yes, but not many people actually test then, let alone
> Hurd developers (they use kvm/qemu), so issues with Virtual Box are most
> often not even known about.

FYI; I recently managed to get Hurd installed on a VirtualBox VM (itself
on Win7 if that matters).

I encountered some major issues doing so:

1) The normal CD .iso just kept crashing, but the netinst .iso managed
to work. I'm not certain if this was due to image differences and/or the
below two issues. There was a week delay between attempts with VM setup
from scratch and .iso freshly downloaded on each.

2) critical for Hurd was having the VirtualBox extensions and settings
identical to those documented for regular Debian Linux installs right
from the point of creating the VM image.
There are some fiddly issues with CPU and ACPI virtualization in VB.
Debian Linux installs but has runtime problems if these are wrong.
Debian Hurd will just crash on initializing the installer, or if it gets
past that the Mach kernel stage.

3) VirtualBox DHCP is a bit wacky. It might fail to allocate IPs
properly (same issue with Linux). I had to skip the installer DHCP step
and configure the /etc/networking/interfaces manually after install
through the VM terminal.

4) Since install was from the netinst .iso #3 above meant that I had to
explicitly de-select everything including "basic system packages" at the
environment selection stage.


... and no kidding about clock issues - 8 hrs to run the installer,
another ~48 hrs to run a dist-upgrade to Sid afterwards. Thats 8x longer
than regular Debian for the same.

Sometime in the next few weeks I will be repeating the install process
yet again. So if anyone is interested in making it easier for newbies to
get started let me know what (if anything) you want recorded from the
process.

HTH
Amos