On Wed, May 29, 2024 at 5:09 AM Samuel Thibault wrote:
>
> It was becoming more and more a concern (gstreamer build-depends on
> rustc nowadays). At last, the rustc compiler becomes available :D
>
> Thanks to Vedant's GSoC work last summer, and then waiting for Debian to
> catch with upstream rele
Samuel Thibault, le mer. 29 mai 2024 11:09:28 +0200, a ecrit:
> (will become available in the unreleased archive within 6h)
It's available. The buildds have started building the hundreds of
packages that were waiting.
Samuel
On 29/05/24 21:09, Samuel Thibault wrote:
Hello,
It was becoming more and more a concern (gstreamer build-depends on
rustc nowadays). At last, the rustc compiler becomes available :D
Thanks to Vedant's GSoC work last summer, and then waiting for Debian to
catch with upstream releases, eventuall
Hello,
It was becoming more and more a concern (gstreamer build-depends on
rustc nowadays). At last, the rustc compiler becomes available :D
Thanks to Vedant's GSoC work last summer, and then waiting for Debian to
catch with upstream releases, eventually we have rustc!
(will become available in
Control: reopen -1
Hi,
looks like this didn't work:
> https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia&arch=powerpc&ver=6.4.2-11&stamp=1705003199&raw=0
Reopening the bug therefore.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :'
Hello,
Mattias Ellert, le lun. 29 janv. 2024 08:53:44 +0100, a ecrit:
> The build of davix 0.8.5-1+b1 failed on hurd-i386 due to bug 1061610,
> which is a bug in debhelper 13.12. Could you retry the build with
> debhelper 13.13?
>
> https://buildd.debian.org/status/package.php?p=d
Hi!
The build of davix 0.8.5-1+b1 failed on hurd-i386 due to bug 1061610,
which is a bug in debhelper 13.12. Could you retry the build with
debhelper 13.13?
https://buildd.debian.org/status/package.php?p=davix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061610
Mattias
Aurelien Jarno, le sam. 20 mai 2023 12:43:12 +0200, a ecrit:
> On 2023-05-19 22:16, Samuel Thibault wrote:
> > could you remove version 4.4.2-P1-1+b1 from sid?
>
> That should be done now, and should be visible after the next mirror
> push.
Thanks!
Samuel
Hi,
On 2023-05-19 22:16, Samuel Thibault wrote:
> Hello,
>
> iscp-dhcp-client currently doesn't build in sid so we have a patched
> 4.4.3-P1-1.1+hurd.1 version in unreleased. But debootstrap has troubles
> installing that version instead of the old 4.4.2-P1-1+b1 version tha
Hello,
iscp-dhcp-client currently doesn't build in sid so we have a patched
4.4.3-P1-1.1+hurd.1 version in unreleased. But debootstrap has troubles
installing that version instead of the old 4.4.2-P1-1+b1 version that is
still present in sid, it picks whatever comes first, which is th
idn't help.
>
> Ok, now I see the issue, it's indeed on basically all boxes except mine
> because I tinkered with /dev/random.
I have uploaded hurd version 1:0.9.git20220301-2 which sort things out.
If you have a system which is hosed, you can easily make it boot again
with
rm
Samuel Thibault, le mar. 31 mai 2022 11:53:27 +0200, a ecrit:
> Mattias Ellert, le mar. 31 mai 2022 11:17:00 +0200, a ecrit:
> > https://buildd.debian.org/status/logs.php?pkg=globus-gass-copy&arch=hurd-i386
> >
> > I can not reproduce the failure on exodar. I tried 10 times, all
> > successful.
>
Mattias Ellert, le mar. 31 mai 2022 11:17:00 +0200, a ecrit:
> https://buildd.debian.org/status/logs.php?pkg=globus-gass-copy&arch=hurd-i386
>
> I can not reproduce the failure on exodar. I tried 10 times, all
> successful.
Ah, Computer bought the farm, I wonder what happened on the box.
> Can t
Hi!
The build of globus-gass-copy/10.12-1 failed on GNU/Hurd:
https://buildd.debian.org/status/logs.php?pkg=globus-gass-copy&arch=hurd-i386
I can not reproduce the failure on exodar. I tried 10 times, all
successful.
Can the build be tried again?
Mattias
signature.asc
Descrip
On 3/11/21 05:31, Sergey Bugaev wrote:
Short description
=
libports accepts fake notification messages from any client on any port, which
can lead to port use-after-free, which can be exploited for local privilege
escalation to get full root access to the system.
This has been
ht
carried in a message gets received as MACH_PORT_DEAD (-1), which would be rather
useless to the receiver.
To prevent potential races between processing the notification and the now-dead
name getting deallocated and reused for another right, the dead-name
notification "carries" an extra
Hello,
Niko Tyni, le jeu. 18 juin 2020 07:34:03 +0100, a ecrit:
> perl_5.32.0~rc1-1 in experimental failed to build on hurd with a
> test failure:
>
> dist/IO/t/cachepropagate-unix .. # Failed
> test 'protocol defined'
> # at
Hi hurd porters,
perl_5.32.0~rc1-1 in experimental failed to build on hurd with a
test failure:
dist/IO/t/cachepropagate-unix .. # Failed
test 'protocol defined'
# at t/cachepropagate-unix.t line 54.
# Failed test 'protocol defi
Samuel Thibault, le lun. 08 oct. 2018 00:02:03 +0200, a ecrit:
> Chris Lamb, le dim. 07 oct. 2018 22:40:08 +0100, a ecrit:
> >
> > https://github.com/tavianator/bfs/commit/85caf29cfd2f40ef10ed76d425bb89a5f8f45a1a
> >
> > .. but that was in 1.2.2-2.
> >
> > debian-hurd@, any input here? Any reas
Hello,
Chris Lamb, le dim. 07 oct. 2018 22:40:08 +0100, a ecrit:
>
> https://github.com/tavianator/bfs/commit/85caf29cfd2f40ef10ed76d425bb89a5f8f45a1a
>
> .. but that was in 1.2.2-2.
>
> debian-hurd@, any input here? Any reason why /proc/mounts might not
> exist, or...?
I have seen /proc not
ich is presumably an error opening /proc/mounts (bfs tries /etc/mtab
> first and falls back to /proc/mounts).
>
> It worked fine for 1.2.3:
> https://buildd.debian.org/status/fetch.php?pkg=bfs&arch=hurd-i386&ver=1.2.3-1&stamp=1532143385&raw=0
That's very odd.
---
debian/patches/port | 60 -
1 file changed, 23 insertions(+), 37 deletions(-)
diff --git a/debian/patches/port b/debian/patches/port
index 1a3a71f..92fffb3 100644
--- a/debian/patches/port
+++ b/debian/patches/port
@@ -1,8 +1,6 @@
-Index
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 06 Mar 2018 08:35:38 +
Source: hurd
Binary: hurd-libs0.3 hurd hurd-prof hurd-dev hurd-doc hurd-libs0.3-udeb
hurd-udeb
Architecture: source hurd-i386 all
Version: 1:0.9.git20180305-1
Distribution: unstable
Urgency: medium
Package: faketime
Version: 0.9.7-2
Severity: normal
User: debian-hurd@lists.debian.org
Usertags: hurd-i386
Control: affects -1 src:mbedtls
The faketime executable fails on hurd-i386 (admittedly not a release
architecture) with the error
sem_open: Operation not supported
as seen in [1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 22 Feb 2018 20:58:25 +
Source: hurd
Binary: hurd-libs0.3 hurd hurd-prof hurd-dev hurd-doc hurd-libs0.3-udeb
hurd-udeb
Architecture: source hurd-i386 all
Version: 1:0.9.git20180222-1
Distribution: unstable
Urgency: medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 18 Feb 2018 18:06:32 +
Source: gnumach
Binary: gnumach-image-1-486 gnumach-image-1-xen-486 gnumach-image-1.8-486
gnumach-image-1.8-xen-486 kernel-image-1.8-486-di kernel-image-1.8-xen-486-di
gnumach-image-1.8-486-dbg
o: Nobody (None)
Summary: Partial patch for kbuild 1:0.1.98svn2318-1
Category: linuxism
Group: submitted
Resolution: None
Initial Comment:
Hi,
Attached is the start of a patch for kbuild. Unfortunately it has several
PATH_MAX issues that I just #ifdef'd for now. But even larger is that it
Signed-off-by: James Clarke
---
util-linux/blkdiscard.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/util-linux/blkdiscard.c b/util-linux/blkdiscard.c
index 5863f0aab..e4902e5b5 100644
--- a/util-linux/blkdiscard.c
+++ b/util-linux/blkdiscard.c
@@ -8,6 +8,7 @@
//config:config BLKDISCARD
Email_ouvidoria_saida
Mails_opção4B-1
no objections from me.
KiBi.
> Emilio
>
> >
> > diff -Nru bind9-9.10.3.dfsg.P4/debian/changelog
> > bind9-9.10.3.dfsg.P4/debian/changelog
> > --- bind9-9.10.3.dfsg.P4/debian/changelog 2017-02-19 23:39:32.0
> > +0100
> > +++ bind9-9.10.3.dfs
ibc.h has:
>>
>> OREAD = 0,
>> OWRITE = 1,
>> ORDWR = 2,
>> OCEXEC = 4,
>>
>> but it looks like nothing #includes that file, so perhaps that
>> doesn't have to be patched. Have you tested sam on the Hurd?
>>
>
sam/_libc.h has:
OREAD = 0,
OWRITE = 1,
ORDWR = 2,
OCEXEC = 4,
but it looks like nothing #includes that file, so perhaps that
doesn't have to be patched. Have you tested sam on the Hurd?
If these flags are sent in the Topen and Tcreate requests of t
Package: 9base
Severity: important
Version: 1:6-7
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org
The package fails to build on hurd-i386 because of incorrect values
supplied to fopen() and missing (__GNU__)-defines.
Failing build log
---
debian/rules | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/rules b/debian/rules
index 63a5932..81e9ad9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,8 +5,8 @@
%:
dh $@
-ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
-ifneq (,$(findstring
Ah, thank you, I did not realise such a variable existed; guess I should have
checked!
James
> On 24 Sep 2015, at 14:37, Guillem Jover wrote:
>
> Hi!
>
> On Wed, 2015-09-23 at 19:04:03 +0100, James Clarke wrote:
>> --- a/debian/rules
>> +++ b/debian/rules
>> @@ -6,7 +6,7 @@
>> dh $@
>>
Hi!
On Wed, 2015-09-23 at 19:04:03 +0100, James Clarke wrote:
> --- a/debian/rules
> +++ b/debian/rules
> @@ -6,7 +6,7 @@
> dh $@
>
> ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
> -ifneq (,$(findstring :$(ARCH):,:i386:amd64:))
> +ifneq (,$(filter i386 amd64 %-i386 %-amd64,$(ARCH)))
>
X-Debbugs-CC: debian-hurd@lists.debian.org
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 63a5932..d71c544 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@
dh $@
ARCH=$(shell dpkg-architecture
X-Debbugs-CC: debian-hurd@lists.debian.org
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 63a5932..d71c544 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@
dh $@
ARCH=$(shell dpkg-architecture
27;'
Unable to make a source version for version '0.6-4'
No longer marked as found in versions 0.6-4.
> found 785134 1:0.6-4
Bug #785134 {Done: Samuel Thibault } [hurd] Directory
permissions not enforced when renaming a directory
Marked as found in versions hurd/1:0.6-4.
> thanks
St
Svante Signell, le Thu 08 Jan 2015 12:28:24 +0100, a écrit :
> hurd: add new RPC: file_record_lock
It seems good.
> hurd/ChangeLog
> 2014-08-21 Svante Signell
>
> * fs.defs: Added description.
> * hurd_types.defs: Make struct flock_t seven integers long since
> l_start and
hurd: add new RPC: file_record_lock
hurd/ChangeLog
2014-08-21 Svante Signell
* fs.defs: Added description.
* hurd_types.defs: Make struct flock_t seven integers long since
l_start and l_len are 64bit.
* hurd_types.h: typedef flock_t as flock64.
2001-04-10 Neal H Walfield
* fs.defs: N
was changed, I don't think d-i
uses any part of that, and needs only unrelated library functions
for ISC dhcpd.
Still, with the updated libs d-i still completed successfully
(a netboot install involving DNS resolution and using DHCP).
This test-run was more than 24 hours after 1:9.9.5.dfsg-
Hi,
On Sat, Dec 20, 2014 at 11:07:37PM +0100, Cyril Brulebois wrote:
> > unblock bind9/1:9.9.5.dfsg-7
>
> bind9 is only related to d-i on non-linux architectures (through netcfg
> → isc-dhcp → bind9), so no objection from me.
Added unblock and unblock-udeb.
Cheers,
Ivo
--
Control: tag -1 confirmed
Jonathan Wiltshire (2014-12-19):
> Package: release.debian.org
> Severity: normal
> Tags: d-i
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock package bind9
>
> Fix for RC bug #772610, for some reason
On Tue, Apr 8, 2014 at 1:31 AM, Samuel Thibault wrote:
> Yes, this seems good.
Applied. Thanks for reviewing.
--
G..e
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Ar
Hello,
Yes, this seems good.
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140407233149.ga18...@type.youpi.perso.aquilenet.fr
e34f63..a828037 100755
--- a/debian/sysvinit-core.config
+++ b/debian/sysvinit-core.config
@@ -22,7 +22,8 @@ case "$1" in
| md5sum --status --check -; then
# The file is unmodified, update it silently.
:
- elif fgrep -q
That's better indeed, thanks!
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140225065055.gk6...@type.globalsuite.net
Rémi Denis-Courmont, le Wed 19 Feb 2014 14:17:01 +0100, a écrit :
> > From looking at the build error, it seems the actual error is that
> > vlc_clock_id is not defined, i.e. the actual issue comes from the
> > fact that the #if at the top of the file don't match the #if in the
> > source code.
>
Hello,
> Gabriele Giacone, le Tue 18 Feb 2014 00:54:12 +0100, a écrit :
> > diff --git a/src/posix/thread.c b/src/posix/thread.c
> > index 07fa71e..d49e94c 100644
> > --- a/src/posix/thread.c
> > +++ b/src/posix/thread.c
> > @@ -300,7 +300,7 @@ void vlc_cond_init (vlc_cond_t *p_condvar)
> >
>
Gabriele Giacone, le Tue 18 Feb 2014 00:54:12 +0100, a écrit :
> diff --git a/src/posix/thread.c b/src/posix/thread.c
> index 07fa71e..d49e94c 100644
> --- a/src/posix/thread.c
> +++ b/src/posix/thread.c
> @@ -300,7 +300,7 @@ void vlc_cond_init (vlc_cond_t *p_condvar)
>
> if (unlikely(pthrea
---
src/posix/thread.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/posix/thread.c b/src/posix/thread.c
index 07fa71e..d49e94c 100644
--- a/src/posix/thread.c
+++ b/src/posix/thread.c
@@ -300,7 +300,7 @@ void vlc_cond_init (vlc_cond_t *p_condvar)
if
hurd_0.5.git20140203-1.dsc: Source field does not match Source field in changes
===
Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.
--
To UNSUBSCRIBE, email to debian-hurd
hurd_0.5.git20140203-1+b1_hurd-i386.changes uploaded successfully to localhost
along with the files:
hurd_0.5.git20140203-1.dsc
hurd_0.5.git20140203-1.debian.tar.bz2
hurd-libs0.3_0.5.git20140203-1+b1_hurd-i386.deb
hurd_0.5.git20140203-1+b1_hurd-i386.deb
hurd-dev_0.5.git20140203-1+b1_hurd
Svante Signell, le Wed 16 Oct 2013 11:26:29 +0200, a écrit :
> > All of them. Everything that is provided in cmsgcred is supposed to have
> > been checked by the operating system as being correct.
>
> How to handle case where not all ancillary data is sent, e.g. groups
> missing?
Well, you can st
On Wed, 2013-10-16 at 10:46 +0200, Samuel Thibault wrote:
> Svante Signell, le Wed 16 Oct 2013 09:50:27 +0200, a écrit :
>
> Also, you need to check that it works when the sender and the receiver
> don't have the same uid/gid/etc., e.g. root sending to a normal user
> (which is one of the most us
Svante Signell, le Wed 16 Oct 2013 09:50:27 +0200, a écrit :
>
> On Wed, 2013-10-16 at 09:24 +0200, Samuel Thibault wrote:
> > Svante Signell, le Wed 16 Oct 2013 07:44:11 +0200, a écrit :
> > > What about being paranoid, and do the check on both the transmit _and_
> > > receive side?
> >
> > Ther
On Wed, 2013-10-16 at 09:24 +0200, Samuel Thibault wrote:
> Svante Signell, le Wed 16 Oct 2013 07:44:11 +0200, a écrit :
> > What about being paranoid, and do the check on both the transmit _and_
> > receive side?
>
> There is no need for a check on the transmit side: the sender does know
> for s
Svante Signell, le Wed 16 Oct 2013 07:35:51 +0200, a écrit :
> OK, I'll move the check to recvmsg.c then. No problem:) We can also do a
> full re-authentication at the receive end, should that be added too?
I don't remember what that means, but you might need that.
In any case, you should really
Svante Signell, le Wed 16 Oct 2013 07:44:11 +0200, a écrit :
> What about being paranoid, and do the check on both the transmit _and_
> receive side?
There is no need for a check on the transmit side: the sender does know
for sure what he is.
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ
On Wed, 2013-10-16 at 07:35 +0200, Svante Signell wrote:
> On Wed, 2013-10-16 at 00:49 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Wed 16 Oct 2013 00:48:35 +0200, a écrit :
> > > Because the receiver does not trust the sender.
> >
> > And that is the *whole* point of SCM_CREDS. Otherwise
On Wed, 2013-10-16 at 00:49 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Wed 16 Oct 2013 00:48:35 +0200, a écrit :
> > Because the receiver does not trust the sender.
>
> And that is the *whole* point of SCM_CREDS. Otherwise the sender could
> simply write a mere struct, without having to g
Samuel Thibault, le Wed 16 Oct 2013 00:48:35 +0200, a écrit :
> Because the receiver does not trust the sender.
And that is the *whole* point of SCM_CREDS. Otherwise the sender could
simply write a mere struct, without having to go through SCM_*.
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-
Svante Signell, le Wed 16 Oct 2013 00:46:54 +0200, a écrit :
> On Wed, 2013-10-16 at 00:42 +0200, Samuel Thibault wrote:
> > Svante Signell, le Wed 16 Oct 2013 00:40:18 +0200, a écrit :
> > > On Wed, 2013-10-16 at 00:28 +0200, Samuel Thibault wrote:
> > > > Svante Signell, le Tue 15 Oct 2013 10:33:
On Wed, 2013-10-16 at 00:42 +0200, Samuel Thibault wrote:
> Svante Signell, le Wed 16 Oct 2013 00:40:18 +0200, a écrit :
> > On Wed, 2013-10-16 at 00:28 +0200, Samuel Thibault wrote:
> > > Svante Signell, le Tue 15 Oct 2013 10:33:12 +0200, a écrit :
> > > > + pids = __getpid();
> > > > +
Svante Signell, le Wed 16 Oct 2013 00:40:18 +0200, a écrit :
> On Wed, 2013-10-16 at 00:28 +0200, Samuel Thibault wrote:
> > Svante Signell, le Tue 15 Oct 2013 10:33:12 +0200, a écrit :
> > > + pids = __getpid();
> > > + euids = __geteuid();
> > > + auids = __getuid();
> > > + egids = __get
On Wed, 2013-10-16 at 00:28 +0200, Samuel Thibault wrote:
> Svante Signell, le Tue 15 Oct 2013 10:33:12 +0200, a écrit :
> > + pids = __getpid();
> > + euids = __geteuid();
> > + auids = __getuid();
> > + egids = __getegid();
> > + agids = __getgid();
>
> Err, which part of the
Svante Signell, le Tue 15 Oct 2013 10:33:12 +0200, a écrit :
> + pids = __getpid();
> + euids = __geteuid();
> + auids = __getuid();
> + egids = __getegid();
> + agids = __getgid();
Err, which part of the protocol which check that these are actually the
proper value?
Hi,
Patch 1(2) on SCM_CREDS support for GNU/Hurd.
Time to publish the SCM_CREDS proposal to the list. From the patch there
are some FIXMEs that need to be resolved for a final patch to be
created. I've been running two kvm-images with eglibc built with this
patch for a few weeks now, and ha
All applied, thanks!
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131013160026.go14...@type.youpi.perso.aquilenet.fr
Remove the pid file if the console client exits either cleanly using
console_exit or because of an error during daemonization.
* console-client/console.c (console_exit): Remove the pid file.
(daemon_error): Likewise.
---
console-client/console.c |5 +
1 file changed, 5 insertions
All three applied, thanks.
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131008204035.gj5...@type.youpi.perso.aquilenet.fr
dropped before, this operation fails
with EPERM.
This commit also broke mkfifo(3), possibly for similar or related
reasons.
* tmpfs/tmpfs.c (main): Do not drop all privileges.
---
tmpfs/tmpfs.c |6 --
1 file changed, 6 deletions(-)
diff --git a/tmpfs/tmpfs.c b/tmpfs/tmpfs.c
index 1872a7d
* hurd/process.defs (proc_set_init_task): New procedure.
* hurd/process_reply.defs (proc_set_init_task): Likewise.
* hurd/process_request.defs (proc_set_init_task): Likewise.
* include/pids.h: Add HURD_PID_INIT as 1, adjust others accordingly.
* init/init.c (start_child): Register the child task
runsystem.sh checks whether /servers/socket/1 exists and creates it
using settrans -c if it does not. But at this point in the boot the
root filesystem is normally not writable. This patch fixes this.
* daemons/runsystem.sh: Make sure / is writable before attempting to
set up pflocal
port_set);
+ if (err)
+return err; /* XXX */
+
+ err = n->notify_func (r->port,
+reply_port,
+r->data,
+common_data);
+ if (err == MACH_SEND_INVALID_DEST)
+{
+ hurd_ihash_key_t key = (hurd_ihas
Using PID 0 causes various problems. This makes genpid skip PID 0.
* proc/mgt.c (genpid): Start PIDs at 1.
---
proc/mgt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/proc/mgt.c b/proc/mgt.c
index c093b8f..d7ad296 100644
--- a/proc/mgt.c
+++ b/proc/mgt.c
@@ -862,7
Uh, indeed, it even seems syntaxically incorrect :)
Applied, thanks,
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20130915210208.gf5...@type.youpi.perso.aqu
* proc/exc-reply.defs: Delete file.
---
proc/exc-reply.defs | 36
1 file changed, 36 deletions(-)
delete mode 100644 proc/exc-reply.defs
diff --git a/proc/exc-reply.defs b/proc/exc-reply.defs
deleted file mode 100644
index 8a04723..000
--- a/proc/exc
: Add field parent_task.
* kern/task.c (task_create): Keep a reference to the parent task.
(task_deallocate): Dereference the parent task.
---
kern/task.c |3 +++
kern/task.h |1 +
2 files changed, 4 insertions(+)
diff --git a/kern/task.c b/kern/task.c
index 114dd31..0c0be99 100644
--- a
ce any useful results,
not quite sure why). Turns out it was only because my /hurd/init
contained the proc_set_init_task patches while the /hurd/proc I built
on top of hurd upstream did not :/ and this was even though I wrote
those patches.
So I'd like to restate these questions:
1. Who is &q
-rele.c |1 +
5 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/libdiskfs/dir-lookup.c b/libdiskfs/dir-lookup.c
index 923be03..15a9b0c 100644
--- a/libdiskfs/dir-lookup.c
+++ b/libdiskfs/dir-lookup.c
@@ -1,6 +1,6 @@
/* libdiskfs implementation of fs.defs:dir_lookup
Copyright (C
> Right. The feature is however still somehow interesting, so I prefered
> to just disable the support by default, so users can easily build their
> own exec server and set it up for themselves if they wish.
Doing this in the exec server was always just a cheap hack because we
didn't have a transl
On Thu, Aug 29, 2013 at 12:52:39PM +0200, Samuel Thibault wrote:
> Justus Winter, le Thu 29 Aug 2013 12:41:47 +0200, a écrit :
> > But couldn't the same be achieved by installing an unzipping storeio
> > translator on the zipped executable? It is more explicit, but I'd
> > argue that this is a good
Justus Winter, le Thu 29 Aug 2013 13:06:03 +0200, a écrit :
> Umm, I just tested this, and it doesn't work :/ I guess b/c storeio
> claims that it is a character device:
> % ls -l /tmp/hello.unzipped
> crwxr-xr-x 1 teythoon teythoon 0, 0 Aug 29 13:01 /tmp/hello.unzipped
Chara
actorization :)
>
> What do people think about it? That can mean, with nsmux, to exec, say,
> foo.gz,,gunzip for instance, instead of guessing.
Umm, I just tested this, and it doesn't work :/ I guess b/c storeio
claims that it is a character device:
% ls -l /tmp/hello.unzipped
crw
Justus Winter, le Thu 29 Aug 2013 12:41:47 +0200, a écrit :
> > At least to show flexibility of the exec server. The difference between
> > the BFD code and the gzip/bzip2 code is that the latter makes the whole
> > exec code complex, while the gzip/bzip2 support only has a couple of
> > hooks, so
Quoting Samuel Thibault (2013-08-29 12:32:50)
> Justus Winter, le Thu 29 Aug 2013 12:16:11 +0200, a écrit :
> > The patches were also ment to address the complexity^Wsheer size of
> > the code. That is why I wanted to remove them, #ifdef'ing it out has a
> > cost, not a runtime one but for anyone h
Justus Winter, le Thu 29 Aug 2013 12:16:11 +0200, a écrit :
> The patches were also ment to address the complexity^Wsheer size of
> the code. That is why I wanted to remove them, #ifdef'ing it out has a
> cost, not a runtime one but for anyone hacking on /hurd/exec.
Yes, the BFD code was making th
Quoting Samuel Thibault (2013-08-28 23:56:10)
> Hello,
>
> Justus Winter, le Thu 15 Aug 2013 18:41:50 +0200, a écrit :
> > Remove support for transparently unbzip2ing executables from the exec
> > server. The code in question makes the exec server unnecessarily
> > complex and since the exec serve
Quoting Samuel Thibault (2013-08-29 01:48:10)
> I think we should keep this in the Debian package, the upstream GNU
> system will a priori still use /hurd/init as reaper.
Well, it is not my place to question this and maintaining the patches
is your burden, but I was hoping to remove the process re
I think we should keep this in the Debian package, the upstream GNU
system will a priori still use /hurd/init as reaper.
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.d
Hello,
Justus Winter, le Thu 15 Aug 2013 18:41:50 +0200, a écrit :
> Remove support for transparently unbzip2ing executables from the exec
> server. The code in question makes the exec server unnecessarily
> complex and since the exec server is an essential process, crashing it
> makes /hurd/init
# that should be the right syntax
tags 720941 patch
user 720941 debian-hurd@lists.debian.org
usertags 720941 hurd
thanks
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.
>>>>> Justus Winter <4win...@informatik.uni-hamburg.de> writes:
>>>>> Quoting Ivan Shmakov (2013-08-25 17:55:39)
[…]
>> /bin/fakeauth /bin/sh \
>> -c 'cd "$1" || exit ; shift ; exec "$@"' \
>>
ettrans --chroot \
/bin/fakeauth /bin/sh \
-c 'cd "$1" || exit ; shift ; exec "$@"' \
dummy.sh "$(pwd)" "$@" \
-- / /hurd/fakeroot
(Also to note is that `pwd` may generally contain whitespace
charac
a single string of
> the command passed, just for the /bin/sh to parse it later?
> Like (untested):
>
> exec /bin/settrans --chroot \
> /bin/fakeauth /bin/sh \
> -c 'cd "$1" || exit ; shift ; exec "$@"' \
Yes, obviously s
Both applied, thanks!
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130825132859.gf13...@type.colubris.lan
; '-c' 'echo $0'
/bin/sh
% fakeroot-hurd '/bin/sh' '-c' 'echo $0'
% fakeroot-hurd-fixed '/bin/sh' '-c' 'echo $0'
/bin/sh
* utils/fakeroot.sh: Escape arguments handed to /bin/sh so that they
are not evaluated pr
arser.y
index ade56be..a916cb3 100644
--- a/parser.y
+++ b/parser.y
@@ -172,7 +172,7 @@ Statement : Subsystem sySemi
| TypeDecl sySemi
| RoutineDecl sySemi
{
-register statement_t *st = stAlloc();
+statement_t *st = s
1 - 100 of 364 matches
Mail list logo
