[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #6, sr #110199 (project administration): Hi Inieiev, I'll make one more effort to to comply to your requirements. If you reject the next tarball, I'll publish the project elsewhere, gitlab or github (god forgive) :( ___

Re: git-bisect results on gnumach

On Sat, 2020-04-04 at 11:27 +0200, Samuel Thibault wrote: > Svante Signell, le sam. 04 avril 2020 09:59:26 +0200, a ecrit: > > Just a follow-up: I did cherry-pick > > 572095c645ecc63285d0955fbee2f5d644ad8f88 > > on top of > > 0b3504b6db86c531e8b53b8e9aa9030db6e7235

Re: git-bisect results on gnumach

On Sat, 2020-04-04 at 09:20 +0200, Svante Signell wrote: > On Fri, 2020-04-03 at 23:45 +0200, Samuel Thibault wrote: > > Thanks! I pushed a fix. > > I tried the latest gnumach and something is still not OK: > Loading GNU Mach > Loading the Hurd ... > KVM: entry failed, h

Re: git-bisect results on gnumach

On Fri, 2020-04-03 at 23:45 +0200, Samuel Thibault wrote: > Thanks! I pushed a fix. I tried the latest gnumach and something is still not OK: Loading GNU Mach Loading the Hurd ... KVM: entry failed, hardware error 0x8021 Is bisecting not possible any longer, unless cherry picking the latest

Bug#955700: krb5: FTBFS on hurd-i386

Source: krb5 Version: 1.17-7 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd HI, krb5 currently FTBFS on GNU/Hurd due to a missing MAXHOSTNAMELEN definition. The attached patch fixes the build problem on GNU/Hurd by adding a definition of MAXHOSTNAMELEN to

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #4, sr #110199 (project administration): [comment #3 comment #3:] > > [comment #2 comment #2:] > > Regarding patches in the patches directory, it does not make sense to add copyright notices. > > Why not? I have now added Copyright info to the patches directory, see

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #4, sr #110199 (project administration): [comment #3 comment #3:] > > [comment #2 comment #2:] > > Regarding patches in the patches directory, it does not make sense to add copyright notices. > > Why not? I have now added Copyright info to the patches directory, see

Re: git-bisect results on gnumach

On Fri, 2020-04-03 at 16:11 +0200, Svante Signell wrote: > Hello, > > After having problems to boot the cross-built Hurd from the latest > hurd/gnumach/mig git repos bisecting gnumach with git-bisect the > following bad commit was found (breaking --enable-pae accord

git-bisect results on gnumach

Hello, After having problems to boot the cross-built Hurd from the latest hurd/gnumach/mig git repos bisecting gnumach with git-bisect the following bad commit was found (breaking --enable-pae according to Samuel): 0b3504b6db86c531e8b53b8e9aa9030db6e72357 is the first bad commit commit

Bug#955351: mesa: FTBFS on hurd-i386

Source: mesa Version: 20.0.2-1 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Currently mesa FTBFS on GNU/Hurd due to a new PATH_MAX issue. Version 18.3.6-2 built successfully earlier. The attached patch path_max.diff fixes that problem. Also,

Bug#955351: mesa: FTBFS on hurd-i386

Source: mesa Version: 20.0.2-1 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Currently mesa FTBFS on GNU/Hurd due to a new PATH_MAX issue. Version 18.3.6-2 built successfully earlier. The attached patch path_max.diff fixes that problem. Also,

Re: `guix build hello' now succeeds on the Hurd

Congratulations!! On Fri, 2020-03-06 at 11:15 +0100, Jan Nieuwenhuizen wrote: > Hi Guix! > > The situation on the Hurd starts to look pretty good > > janneke@debian:~/src/guix$ ./pre-inst-env guix build hello --no-offload > /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10 >

Re: Hurd bootstrap breaks guix building binutils-boot0@2.34

Hello, I did build the bootstrap binaries some time ago. They were corrupt. As well as the pre-built ones that were available at http://berlin.guix.gnu.org/guix/bootstrap/i586-gnu/20190508 Down-grading from guile-2.2 to guile-2.0 did not improve the situation. Now I have a project to

[DNG] Help needed:[Fwd: eudev: Methods to detect if running in a container.]

Hello, No replies so far from the devuan-dev list. Maybe with a larger audience I can get some help! Thanks! --- Begin Message --- Hello, I'm trying to solve the problem of detecting if you are within a container, like docker or LXC when running the eudev init script. If true udevd should not

How to undo a merged-user installation?

Hello, I recently installed Debian/bullseye/sid in a VM from a snapshot. After running that image I realized the I got a merged-user installation. As for now I have: bin -> usr/bin lib -> usr/lib lib32 -> usr/lib32 lib64 -> usr/lib64 libx32 -> usr/libx32 sbin -> usr/sbin Is there some way to

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #2, sr #110199 (project administration): Hello, Regarding patches in the patches directory, it does not make sense to add copyright notices. Therefore I have created the README.patches file under patches. It is a lot of work to create a README.patches for every sub-directory.

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #2, sr #110199 (project administration): Hello, Regarding patches in the patches directory, it does not make sense to add copyright notices. Therefore I have created the README.patches file under patches. It is a lot of work to create a README.patches for every sub-directory.

[sr #110199] Cross-building of GNU/Hurd and additional packages

URL: Summary: Cross-building of GNU/Hurd and additional packages Project: Savannah Administration Submitted by: gnu_srs Submitted on: Tue 18 Feb 2020 10:09:24 AM UTC Category:

[sr #110199] Cross-building of GNU/Hurd and additional packages

URL: Summary: Cross-building of GNU/Hurd and additional packages Project: Savannah Administration Submitted by: gnu_srs Submitted on: Tue 18 Feb 2020 10:09:24 AM UTC Category:

Bug#951544: mate-session-manager: FTBFS on non-linux

Source: mate-session-manager Severity: important Version: 1.24.0-1 Tags: patch User: debian-hurd@lists.debian.org Usertags: hurd X-Debbugs-CC: debian-hurd@lists.debian.org Hello, The latest version of mate-session-manager FTBFS on Hurd and kFreeBSD due to a missing build dependency on

Bug#951544: mate-session-manager: FTBFS on non-linux

Source: mate-session-manager Severity: important Version: 1.24.0-1 Tags: patch User: debian-h...@lists.debian.org Usertags: hurd X-Debbugs-CC: debian-h...@lists.debian.org Hello, The latest version of mate-session-manager FTBFS on Hurd and kFreeBSD due to a missing build dependency on

Bug#951541: mate-panel: FTBFS on non-linux

Source: mate-panel Severity: important Version: 1.24.0-1 Tags: patch User: debian-hurd@lists.debian.org Usertags: hurd X-Debbugs-CC: debian-hurd@lists.debian.org Hello, The latest version of mate-panel FTBFS on Hurd and kFreeBSD due to a build dependency of libgtk-layer-shell-dev. That package

Bug#951541: mate-panel: FTBFS on non-linux

Source: mate-panel Severity: important Version: 1.24.0-1 Tags: patch User: debian-h...@lists.debian.org Usertags: hurd X-Debbugs-CC: debian-h...@lists.debian.org Hello, The latest version of mate-panel FTBFS on Hurd and kFreeBSD due to a build dependency of libgtk-layer-shell-dev. That package

Bug#951516: gvfs: gvfs-daemons fails to install on non-linux boxes

Source: gvfs Severity: important Version: 1.42.2-1 Tags: patch User: debian-h...@lists.debian.org Usertags: hurd X-Debbugs-CC: debian-h...@lists.debian.org Hello, The latest version of gvfs fails to install on non-linux boxes due to the dependency on lsof for gvfs-daemons, which is not available

Bug#951516: gvfs: gvfs-daemons fails to install on non-linux boxes

Source: gvfs Severity: important Version: 1.42.2-1 Tags: patch User: debian-hurd@lists.debian.org Usertags: hurd X-Debbugs-CC: debian-hurd@lists.debian.org Hello, The latest version of gvfs fails to install on non-linux boxes due to the dependency on lsof for gvfs-daemons, which is not available

[task #15548] Submission of hurd-cross

Follow-up Comment #4, task #15548 (project administration): Hi again. I have now obtained permission to add my project to "The GNU/Hurd", via emails to bug-hurd. Remains to solve how to add the project git repo to http://git.savannah.gnu.org/cgit/hurd/ Any ideas? As I wrote earlier I have

Re: Adding the hurd-cross package to "The Hurd group"?

there too. I can of course add a link to your work in README.commands as well as add that link to README.md too. Alternately, do you want me to add your name to the files having an origin of your work, like: Copyright (C) 2016 Flavio Cruz, 2019, 2020 Svante Signell Written by Flavio Cruz and Svante

Adding the hurd-cross package to "The Hurd group"?

Hello, I've created the hurd-cross (hurdX) package and submitted it as task #15548, see https://savannah.nongnu.org/task/?15548. I was asked by ine...@gnu.org if I could join "The Hurd group" with it. The project is described in the task, and I also have uploaded a tarball. The tarball is created

[task #15548] Submission of hurd-cross

Follow-up Comment #2, task #15548 (project administration): Yes I have. Where to apply for being part of the Hurd? ___ Reply to this item at: ___

[task #15548] Submission of hurd-cross

URL: Summary: Submission of hurd-cross Project: Savannah Administration Submitted by: gnu_srs Submitted on: Wed 12 Feb 2020 04:14:10 PM UTC Should Start On: Wed 12 Feb 2020 12:00:00 AM UTC

Re: [Proposal] The Formal Methods in GNU Guix Working Group

On Wed, 2020-02-12 at 15:16 +0100, zimoun wrote: > Dear, > > On Wed, 12 Feb 2020 at 13:03, Orians, Jeremiah (DTMB) > wrote: > > > We also have a scheme bootstrappable from nothing written in C > > https://github.com/oriansj/mes-m2 > > https://github.com/oriansj/mescc-tools-seed > > The term

Re: /proc/self/fd support on Hurd

On Tue, 2020-02-11 at 09:03 -0800, Samuel Thibault wrote: > Svante Signell, le mar. 11 févr. 2020 17:59:12 +0100, a ecrit: > > Sorry, that was a Linux system. On hurd: > > ls -l /proc/self/fd/ > > I don't have such a directory on a Hurd system. Yes you are correct. > No

Re: /proc/self/fd support on Hurd

On Tue, 2020-02-11 at 08:46 -0800, Samuel Thibault wrote: > Svante Signell, le mar. 11 févr. 2020 17:42:18 +0100, a ecrit: > > On Tue, 2020-02-11 at 06:16 -0800, Samuel Thibault wrote: > > > Florian Weimer, le mar. 11 févr. 2020 15:06:43 +0100, a ecrit: > > > > >

Re: /proc/self/fd support on Hurd

On Tue, 2020-02-11 at 06:16 -0800, Samuel Thibault wrote: > Florian Weimer, le mar. 11 févr. 2020 15:06:43 +0100, a ecrit: > > > Samuel Thibault, le mar. 11 févr. 2020 05:47:30 -0800, a ecrit: > > > > Florian Weimer, le mar. 11 févr. 2020 14:39:23 +0100, a ecrit: > > > > > Does Hurd support

Re: Debian With Alternate Init Systems

Back on debian-devel. On Mon, 2020-02-10 at 14:22 +, Sam Hartman wrote: >From a private reply to me from Sam: > I hear your frustration at Samuel's message. I want Samuel to apologize on _this_ email list for insulting me. Regarding your opinion about the GR becomes very clear by reading

Re: Debian With Alternate Init Systems

Sam: This reply is addressed to Samuel and another to you follows, then I'll shut up. On Sat, 2020-02-08 at 16:40 +0100, Samuel Thibault wrote: > > Nice, the first thing I'll do is to shut down the Debian/GNU Hurd > > buildd mahler. > Can't you see you are here exactly very precisely here

Re: Debian With Alternate Init Systems

Sam: This reply is addressed to you, and another to Samuel, then I'll shut up. On Sat, 2020-02-08 at 08:27 -0500, Sam Hartman wrote: > I can't speak for anyone else, but yeah I've come to my own conclusions. > I was fairly open about them: > https://hartmans.livejournal.com/99395.html > > For

Re: Debian With Alternate Init Systems

On Sat, 2020-02-08 at 14:51 +0100, Samuel Thibault wrote: > Hello Sam, > > Sam Hartman, le sam. 08 févr. 2020 08:27:24 -0500, a ecrit: > > Svante> Perhaps all [...] ought to leave the project, including > > Svante> those having package not being dependent on systemd. > > > > I am frustrated

Re: Debian With Alternate Init Systems

On Thu, 2020-02-06 at 21:12 +, Sam Hartman wrote: > > > > > > "Svante" == Svante Signell writes: > > Svante> When is > Svante> Debian ever to offer a non-systemd alternative for > Svante> installation? > > I hear y

Re: Heads up: persistent journal has been enabled in systemd

On Thu, 2020-02-06 at 14:14 -0500, Michael Stone wrote: > On Thu, Feb 06, 2020 at 08:09:13PM +0100, Svante Signell wrote: > > > > On a Debian system _not_ running systemd: > > > > > > > > du -sh /var/log > > > > 74M /var/log > >

Re: Heads up: persistent journal has been enabled in systemd

On Thu, 2020-02-06 at 13:41 -0500, Michael Stone wrote: > On Thu, Feb 06, 2020 at 07:22:07PM +0100, Svante Signell wrote: > > On a Debian sytem _not_ running systemd: > > > > du -sh /var/log > > 74M /var/log > > > > And the binary logs from systemd wo

Re: Heads up: persistent journal has been enabled in systemd

On Thu, 2020-02-06 at 16:09 +, Philip Hands wrote: > > > I solved this by removing Systemd from my systems. > > > > > > And now what? > Well, since we're apparently meant to be obsessed about what it is > like to accept every default, then let's assume for a moment that you > are asking about

Re: Heads up: persistent journal has been enabled in systemd

On Thu, 2020-02-06 at 15:08 +0100, Marco d'Itri wrote: > On Feb 06, Svante Signell wrote: > > > There are still a large number of > > Debian users opting away from using systemd (and still use Debian, > > not > > derivatives). And what about non-linux systems

Re: Heads up: persistent journal has been enabled in systemd

On Thu, 2020-02-06 at 07:58 +0100, Vincent Bernat wrote: > ❦ 6 février 2020 09:50 +11, Dmitry Smirnov : > > > > and 2) continuing to use rsyslog isn't an option if the default changes. > > > > No. I just don't want default to change. IMHO rationale for this is weak > > but everybody keeps

Bug#950188: gcc-snapshot: FTBFS on hurd-i386

reassign 950188 gcc-10-10-20200129 thanks! > > The patches have now been committed upstream by Ian. > > > They don't apply to gcc-10 in experimental. Close this issue? > > They might not apply to gcc-10, but they apply fine to 1:20200124-1. > I'm still confused why you have both gcc-10 and

Bug#950188: gcc-snapshot: FTBFS on hurd-i386

reassign 950188 gcc-10-10-20200129 thanks! > > The patches have now been committed upstream by Ian. > > > They don't apply to gcc-10 in experimental. Close this issue? > > They might not apply to gcc-10, but they apply fine to 1:20200124-1. > I'm still confused why you have both gcc-10 and

Re: [DNG] Devuan /etc/os-relase - no VERSION info?

On Sat, 2020-02-01 at 05:55 -0600, hal wrote: > Hi, > I'm in the middle of patching a bunch of systems (Ubuntu, Devuan and > Debian flavors) and noticed Devuan's /etc/os-release file doesn't > contain any VERSION tags. > > This file comes in handy for parsing from shell scripts when >

Bug#950188: gcc-snapshot: FTBFS on hurd-i386

On Thu, 2020-01-30 at 19:46 +0100, Matthias Klose wrote: > On 1/29/20 10:35 PM, Svante Signell wrote: > > Source: gcc-snapshot > > Version: 1:20200124-1 > > Severity: important > > Tags: patch > > User: debian-h...@lists.debian.org > > Usertags: hurd &

Bug#950188: gcc-snapshot: FTBFS on hurd-i386

On Thu, 2020-01-30 at 19:46 +0100, Matthias Klose wrote: > On 1/29/20 10:35 PM, Svante Signell wrote: > > Source: gcc-snapshot > > Version: 1:20200124-1 > > Severity: important > > Tags: patch > > User: debian-h...@lists.debian.org > > Usertags: hurd &

Bug#950188: gcc-snapshot: FTBFS on hurd-i386

Source: gcc-snapshot Version: 1:20200124-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, gcc-snapshot FTBFS on hurd-i386 due to missing patches for gccgo. Attached are the three patches needed for a successful build. This bug has been reported and assigned

Bug#950188: gcc-snapshot: FTBFS on hurd-i386

Source: gcc-snapshot Version: 1:20200124-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, gcc-snapshot FTBFS on hurd-i386 due to missing patches for gccgo. Attached are the three patches needed for a successful build. This bug has been reported and assigned

Bug#947847: please install systemd-sysusers using update-alternatives

On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote: > Simon McVittie wrote: > > I think we have a fairly good picture of the costs that would be > > incurred from using alternatives: > > Plus in the case of opentmpfiles; a pile of security issues: systemd- > tmpfiles addresses a number of

Bug#947847: please install systemd-sysusers using update-alternatives

On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote: > Simon McVittie wrote: > > I think we have a fairly good picture of the costs that would be > > incurred from using alternatives: > > Plus in the case of opentmpfiles; a pile of security issues: systemd- > tmpfiles addresses a number of

Bug#947847: please install systemd-sysusers using update-alternatives

On Wed, 2020-01-29 at 12:24 -0600, Gunnar Wolf wrote: > It's not like having two competing implementations causes much > harm here.we technically _can_ allow any /bin/systemd-* to be > provided by another implementation, that we should (actually, I think > we should clearly _not_). Of course

Bug#947847: please install systemd-sysusers using update-alternatives

On Wed, 2020-01-29 at 12:24 -0600, Gunnar Wolf wrote: > It's not like having two competing implementations causes much > harm here.we technically _can_ allow any /bin/systemd-* to be > provided by another implementation, that we should (actually, I think > we should clearly _not_). Of course

Bug#947847: please install systemd-sysusers using update-alternatives

On Wed, 2020-01-29 at 16:49 +0100, Didier 'OdyX' Raboud wrote: > We'd first have to agree that an alternative is actually _needed_. > And so far, > the only arguments I have read in favour of providing alternatives to > /bin/systemd-sysusers are: > * A) it is shipped in the systemd binary

Bug#947847: [Fwd: Re: Bug#947847: please install systemd-sysusers using update-alternatives]

--- Begin Message --- On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote: > > Strikes me as there is a possible solution, though: have opensysusers > dpkg-divert it and put a shell script in its place that checks which > init system is running, and exec's the right sysusers based on

Bug#947847: [Fwd: Re: Bug#947847: please install systemd-sysusers using update-alternatives]

--- Begin Message --- On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote: > > Strikes me as there is a possible solution, though: have opensysusers > dpkg-divert it and put a shell script in its place that checks which > init system is running, and exec's the right sysusers based on

Re: Bug#947847: please install systemd-sysusers using update-alternatives

On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote: > > Strikes me as there is a possible solution, though: have opensysusers > dpkg-divert it and put a shell script in its place that checks which > init system is running, and exec's the right sysusers based on that. It is as simple

Re: [sr #110175] I'd like to register a new project. Looking at the web pages one finds https://savannah.gnu.org/register/

Hello, answering inline. Skickat från min iPad > 16 jan. 2020 kl. 08:20 skrev Ineiev : > > Update of sr #110175 (project administration): > > Status:None => In Progress > Assigned to:None => ineiev

Bug#905961: unbound: FTBFS on non-linux systems

On Tue, 2020-01-14 at 21:20 +0100, Hilmar Preuße wrote: > Am 12.08.2018 um 14:14 teilte Svante Signell mit: > > Hi Svante, > > > Currently unbound FTBFS on GNU/Hurd and GNU/kFreeBSD-any due to a > > dependency on libsystemd-dev. As is well known that library does no

[sr #110175] I'd like to register a new project. Looking at the web pages one finds https://savannah.gnu.org/register/

Follow-up Comment #1, sr #110175 (project administration): On that page you are recommended to update a tarball together with the project description. However, I'd like to use git, specifically creating a local repository. https://savannah.gnu.org/maintenance/UsingGit/ shows how to use git but

[sr #110175] I'd like to register a new project. Looking at the web pages one finds https://savannah.gnu.org/register/

URL: Summary: I'd like to register a new project. Looking at the web pages one finds https://savannah.gnu.org/register/ Project: Savannah Administration Submitted by: gnu_srs Submitted on:

Re: [DNG] When upgrading to Beowulf please test and report issues with eudev-3.2.9-2 from unstable!

On Fri, 2020-01-10 at 18:15 -0700, 'smee via Dng wrote: > > On Fri, 2020-01-10 at 11:25 +0100, Svante Signell via Dng wrote: > > > > I just installed a fresh ascii install, ran update-initramfs -u and had > no errors (I did see the same last line that's mentioned). So

Re: [DNG] When upgrading to Beowulf please test and report issues with eudev-3.2.9-2 from unstable!

On Thu, 2020-01-09 at 16:17 -0700, 'smee via Dng wrote: > Actually, after apt remove *nonfree (and a reboot for good measure), > update-initramfs -u still comes back with the same exact output > including that last line... I think your problems are with the new (beowulf) image. It is not using

Re: [DNG] When upgrading to Beowulf please test and report issues with eudev-3.2.9-2 from unstable!

On Thu, 2020-01-09 at 14:34 -0700, 'smee via Dng wrote: > Below is the output from apt remove *nonfree. > > On both machines it looks pretty much identical. On both machines, it > mentions the following: > > The following packages were automatically installed and are no longer > required: >

Re: [DNG] When upgrading to Beowulf please test and report issues with eudev-3.2.9-2 from unstable!

On Thu, 2020-01-09 at 13:00 -0700, 'smee via Dng wrote: > apt show showed that firmware-misc-nonfree was not installed manually. > > I tried a apt --fix-broken install firmware-misc-nonfree but that > didn't do anything except mark it as manually installed. > Did you add non-free to your

Re: [DNG] When upgrading to Beowulf please test and report issues with eudev-3.2.9-2 from unstable!

On Thu, 2020-01-09 at 11:31 -0700, 'smee via Dng wrote: > Here is the output from apt when I upgraded. Various repeating messages > about missing firmware. > I haven't rebooted yet, or done anything else really. Slightly worried > I'll lose graphics when I reboot because of the message. ... >

Re: [DNG] When upgrading to Beowulf please test and report issues with eudev-3.2.9-2 from unstable! (PATH error)

On Thu, 2020-01-09 at 12:38 -0300, Gastón via Dng wrote: > On Thu, Jan 09, 2020 at 12:13:10PM +0100, Svante Signell via Dng wrote: > > Hello, ... > > Steps to test: > > You can also use country codes: e.g. http://de.deb.devuan.org... > > /etc/init.d/sources.list >

[DNG] When upgrading to Beowulf please test and report issues with eudev-3.2.9-2 from unstable!

Hello, We are currently working on updating eudev from 3.2.7 to 3.2.9 for Beowulf. Current version in Beowulf/testing is now 3.2.7-6, and the latest 3.2.9-2 version is in Ceres/unstable. In order to find out any remaining bugs, please test and report back any success/problems/bugs with that

[sr #110166] Cannot remove my old account since I'm added to a group:hurd

URL: Summary: Cannot remove my old account since I'm added to a group:hurd Project: Savannah Administration Submitted by: svante Submitted on: Mon 23 Dec 2019 04:57:50 PM UTC

Re: [Bug other/93049] limits.h generated by fixincludes breaks cross-compilation

On Mon, 2019-12-23 at 10:09 +, sch...@linux-m68k.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049 > > --- Comment #1 from Andreas Schwab --- > Make sure you have sysroot properly set up so that the gcc Makefile finds the > system limits.h. Do you mean this:

[sr #110165] Please change my email username from 'svante' to 'gnu_srs'

URL: Summary: Please change my email username from 'svante' to 'gnu_srs' Project: Savannah Administration Submitted by: svante Submitted on: Mon 23 Dec 2019 02:46:44 PM UTC

Bug#946709: Patch for one more successful libgo test: syscall

Hello again, The attached patch libgo_go_syscall_export_unix_test.go.diff fixes one failing test of libgo: syscall. Maybe it could be added to the patch already submitted patch in this bug report. Thanks! --- a/src/libgo/go/syscall/export_unix_test.go 2017-05-10 19:26:09.0 +0200 +++

Bug#946709: Patch for one more successful libgo test: syscall

Hello again, The attached patch libgo_go_syscall_export_unix_test.go.diff fixes one failing test of libgo: syscall. Maybe it could be added to the patch already submitted patch in this bug report. Thanks! --- a/src/libgo/go/syscall/export_unix_test.go 2017-05-10 19:26:09.0 +0200 +++

Bug#946709: gcc-9: Backported upstream gccgo patch for hurd-i386

Package: gcc-9 Version: 9.2.1-1 Severity: important Tags: patch Hello, gccgo patches for GNU/Hurd are now committed upstream for both gcc-9 and gcc-10. As found out by Samuel Thibault the current code in os_hurd.go use a relative time instead of an absolute time, see

Bug#946709: gcc-9: Backported upstream gccgo patch for hurd-i386

Package: gcc-9 Version: 9.2.1-1 Severity: important Tags: patch Hello, gccgo patches for GNU/Hurd are now committed upstream for both gcc-9 and gcc-10. As found out by Samuel Thibault the current code in os_hurd.go use a relative time instead of an absolute time, see

Bug#905963: unbound: The patch in #903963 upstream

FYI: The patch hurd.diff in 903963 is now submitted upstream: https://github.com/NLnetLabs/unbound/issues/131 Thanks!

Bug#905961: 905961: Updated patches for unbound 1.9.4-2

found 905961 1.9.4-2 thanks Hello, Updated patch for debian/rules is attached. The patch for debian/control is added for your convenience. Thanks! --- a/debian/control.orig 2017-07-03 22:30:17.0 +0200 +++ b/debian/control 2017-07-14 11:21:44.0 +0200 @@ -20,7 +20,7 @@

Re: sigaltstack fix & golang

On Wed, 2019-12-11 at 03:14 +0100, Samuel Thibault wrote: > Hello, > > I have tracked & found a bug in the sigaltstack implementation, that > was posing problem to golang. I have uploaded a glibc package version > 2.29-7~0+hurd.1 to unreleased, to be available within a few hours. I > have given

Re: Re: If we're Going to Have Alternate Init Systems, let's being sensible

Changed the subject slightly. Sorry Sam, replying to this list with the previous mail does not work (evolution). Nevertheless being Swedish I don't find any offensive tone in my wording, please tell me where I failed! (As you might no know we are very honest in what we do (and write)), no

Re: Re: If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies

Jonathan, FYI: From a mail From Uoti Urpala: https://lists.debian.org/debian-vote/2019/12/msg00054.html fact: There is in practice no development of new alternative init systems happening, and no clear reason to believe that if it hypothetically did occur, there would be particular problems.

Re: Re: Draft ballot

How can you issue the ballot without consensus. That is over my head.

Re: Re: If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies

Hello, I've purposely kept out of this discussion, hoping that you all can behave in a civil manner. Obviously not. I don't rank you mail defective, there have bee several other on this list. Anyway, this whole GR is about systemd or sysvinit, and everybody pretends they don't know about

Bug#944511: #944511: libgpg-error FTBFS when built with gawk 5.0

retitle 944511 "libgpg-error FTBFS when built with gawk 5.0" severity 944511 serious tags 944511 patch fixed-upstream sid thanks Hello, Since the upgrade of gawk to 5.0+ (current Debian version is 1:5.0.1+dfsg-1) libgpg-error FTBFS due to differences in regex parsing and usage of namespace

Re: Debian GNU/kFreeBSD installer

On Mon, 2019-11-18 at 22:12 +0100, Marek Uher wrote: > > Hello all, > > I am looking for the valid Debian GNU/kFreeBSD installer. It seems > that all links to installer on the page: > >https://wiki.debian.org/Debian_GNU/kFreeBSD > > are broken. Where can I find a valid link to

Re: Kernel / modules version do not match in weekly testing install CD

On Thu, 2019-11-14 at 15:57 +, Steve McIntyre wrote: > On Wed, Nov 13, 2019 at 09:52:18PM +0100, Svante Signell wrote: > > On Wed, 2019-11-13 at 14:58 +, Steve McIntyre wrote: > > > On Sun, Nov 10, 2019 at 10:26:18AM +0100, Julien Bigot wrote: > > > Hi guys, >

Re: Kernel / modules version do not match in weekly testing install CD

On Wed, 2019-11-13 at 14:58 +, Steve McIntyre wrote: > On Sun, Nov 10, 2019 at 10:26:18AM +0100, Julien Bigot wrote: > Hi guys, > > We've had a spate of build failures in debian-installer recently that > have triggered problems like this. I've just pushed a fix now thay > should hopefully

Re: RMS: users request you perhaps program HURD: they fear the path the linux kernel is going.

On Wed, 2019-11-13 at 20:37 +, nipponm...@firemail.cc wrote: > > > Anyway... Hurd needs 64 bit support to take over where Linux has decided > to abdicate. We are happy to review patches. Thanks!

Re: RMS: users request you perhaps program HURD: they fear the path the linux kernel is going.

On Wed, 2019-11-13 at 16:36 +0530, Jean Louis wrote: > > It is time to make fully free FSF endorsed GNU/Hurd > distribution. As you might know, Guix is working on to also support GNU/Hurd. Maybe you can make contributions there (in addition to Debian GNU/Hurd).

Re: RMS: users request you perhaps program HURD: they fear the path the linux kernel is going.

Hello, below are incomplete answers to your questions and some links. Many facts are supplied by Samuel Thibault, the main GNU/Hurd developer. Since he is very busy, he does not want to reply directly due to lack of time to answer any follow-up questions. Thanks! On Tue, 2019-11-12 at 10:44

Re: Kernel / modules version do not match in weekly testing install CD

Hello, Downloading both the latest weekly (20191028) and daily build (2019110) of debian-testing-amd64-netinst.iso the following error message is displayed: "No kernel modules were found. This is probably due to a mismatch between the kernel used by this version of the installer and the version

Re: Coreboot vs Libreboot - GNU: Please use Coreboot without the blobs (compile time option).

To the gnu-system-discuss mailing list admin: Yes, please. Please ban this gameonlinux person from the gnu-system- discuss mailing list. Hen is polluting that list with rubbish, not remotely relevant to the required content of contributions to this list. Thanks! On Fri, 2019-11-08 at 08:07

Re: Integration with systemd

On Fri, 2019-11-01 at 06:47 +, Adam D. Barratt wrote: > On Fri, 2019-11-01 at 00:54 +0100, Svante Signell wrote: > > On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote: > > > On Oct 31, Svante Signell wrote: > > > > > > > Marco, I think your info

Re: Integration with systemd

On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote: > On Oct 31, Svante Signell wrote: > > > When elogind enters testing there would be many more people running > > Debian with sysvinit/elogind. elogind is needed for desktop usage > > when not using systemd as PID

Re: Integration with systemd

On Thu, 2019-10-31 at 15:45 +0100, Marco d'Itri wrote: > > On Oct 31, Simon Richter wrote: > > > > No, and that's not our job. There are a lot of people out there > > building non-systemd systems. > Data says: not really a lot. When elogind enters testing there would be many more people running

Bug#905963: unbound: FTBFS on hurd-i386

On Tue, 2019-10-29 at 13:14 +0100, Samuel Thibault wrote: > Hello, > > Samuel Thibault, le dim. 27 oct. 2019 15:56:51 +0100, a ecrit: > > Svante Signell, le dim. 12 août 2018 14:28:36 +0200, a ecrit: > > > a missing function: compat/getentropy_gnu.c, derived from &g

Re: [PATCH] 1(3) hurd+glibc: Support for file record locking

On Mon, 2019-10-28 at 01:40 +0100, Samuel Thibault wrote: > There was an issue with rlock-tweak.c, revealed by the tdb testsuite: > > Index: hurd-debian/libfshelp/rlock-tweak.c > === > --- hurd-debian.orig/libfshelp/rlock-tweak.c >

Re: [PATCH] 2(3) hurd+glibc: Support for file record locking

On Sun, 2019-10-27 at 21:06 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 12 sept. 2019 10:23:55 +0200, a ecrit: > > @@ -358,6 +357,18 @@ routine file_reparent ( > > skip; /* Was: file_get_children. */ > > skip; /* Was: file_get_source. */ > >

Bug#942558: hurd: should return ENXIO instead of EIEIO in open()

On Fri, 2019-10-18 at 23:37 +0800, Shengjing Zhu wrote: > On Fri, Oct 18, 2019 at 2:38 PM Samuel Thibault > wrote: > > Hello, > > > > Shengjing Zhu, le ven. 18 oct. 2019 13:26:58 +0800, a ecrit: > > > When calling open(fifo_fd, O_WRONLY | O_NONBLOCK) on an fifo > > > file, which has > > > no

<    1   2   3   4   5   6   7   8   9   10   >