encode
>the mode data in base-256 (dpkg suppports that just fine, but it's
>still unexpected, and seems incorrect to me). None of the other tar
>formats show this behavior.
> * None of the other dpkg tests fail except for this one.
> * dpkg is now being built w/o fak
still unexpected, and seems incorrect to me). None of the other tar
formats show this behavior.
* None of the other dpkg tests fail except for this one.
* dpkg is now being built w/o fakeroot due to the R³ field set to no.
* Building the source with fakeroot again makes GNU tar with -Holdgnu
Hi :)
Guillem Jover writes:
> I finally got the chance to take a look at the dpkg FTBFS on Hurd (after
> recovering my VM! :), and it appears as if it was a fakeroot problem?
It is a bug in our fakeroot, it breaks O_NOFOLLOW:
teythoon@hurdbox ~ % cat onofollow.c
#include
#include
#i
Hi!
I finally got the chance to take a look at the dpkg FTBFS on Hurd (after
recovering my VM! :), and it appears as if it was a fakeroot problem?
Building dpkg w/o fakeroot works fine. And running the specific test w/
and w/o fakeroot shows the problem:
,---
$ apt-get source dpkg
$ cd
Hello,
Axel Beckert, le Fri 28 Aug 2015 20:58:27 +0200, a écrit :
> JFYI: zsh upstream suspects fakeroot as reason for the endless loops
> during zsh's configure run on Debian GNU/Hurd.
I've found why. This basically boils down to opening a fifo with O_RDWR
which was getting stu
Hello,
I have noticed a few more fakeroot issues probably worth looking at:
https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=hurd-i386&ver=20150817-1&stamp=1439929709
Error: can't open /tmp/cc7P65hz.s for reading: Permission denied
https://buildd.debian.org/sta
Axel Beckert, le Fri 28 Aug 2015 21:55:18 +0200, a écrit :
> Samuel Thibault wrote:
> > Samuel Thibault, le Fri 28 Aug 2015 21:10:41 +0200, a écrit :
> > > Axel Beckert, le Fri 28 Aug 2015 20:58:27 +0200, a écrit :
> > > > JFYI: zsh upstream suspects fakeroot a
Hi Samuel,
thanks for investigating.
Samuel Thibault wrote:
> Samuel Thibault, le Fri 28 Aug 2015 21:10:41 +0200, a écrit :
> > Axel Beckert, le Fri 28 Aug 2015 20:58:27 +0200, a écrit :
> > > JFYI: zsh upstream suspects fakeroot as reason for the endless loops
> > >
Samuel Thibault, le Fri 28 Aug 2015 21:10:41 +0200, a écrit :
> Axel Beckert, le Fri 28 Aug 2015 20:58:27 +0200, a écrit :
> > JFYI: zsh upstream suspects fakeroot as reason for the endless loops
> > during zsh's configure run on Debian GNU/Hurd.
>
> I'll try to
Axel Beckert, le Fri 28 Aug 2015 20:58:27 +0200, a écrit :
> JFYI: zsh upstream suspects fakeroot as reason for the endless loops
> during zsh's configure run on Debian GNU/Hurd.
I'll try to build with fakeroot-tcp to see what happens.
We'd have to investigate what is happening then.
Samuel
Hi,
JFYI: zsh upstream suspects fakeroot as reason for the endless loops
during zsh's configure run on Debian GNU/Hurd.
- Forwarded message from Bart Schaefer -
Date: Fri, 28 Aug 2015 10:44:22 -0700
From: Bart Schaefer
To: Axel Beckert , zsh-work...@zsh.org
Subject: Re: zsh 5.0.8.
Hello :)
Quoting Svante Signell (2015-02-03 12:42:32)
> > In your particular case, did you check whether the error is right,
> > i.e. it tried to do something to the file on the ext2fs that the user
> > is not allowed to do ?
>
> Well, the printouts from libdiskfs shows a uid and gid of 1000, i.e
are.
> > libnetfs is built into fakeroot itself, but not libdiskfs, which is
> > built into ext2fs.static. libdiskfs functions does not seem to be faked.
>
> That's not so surprising. fakeroot does not fake all functions, any
> message it does not understand is pas
Hello :)
Quoting Svante Signell (2015-02-02 12:26:06)
> Confusing thing is: Printouts in
> libnetfs/dir-lookup.c:netfs_S_dir_lookup() are not triggered, but
> libdiskfs/dir-lookup.c:diskfs_S_dir_lookup are.
> libnetfs is built into fakeroot itself, but not libdiskfs, which is
On Sat, 2014-12-20 at 15:29 +0100, Svante Signell wrote:
> Hi,
>
> Building gnat-4.9 fails currently with EACCES errors when building some
> of the .debs, specifically libgnatvsn4.9-dev, libgnatprj4.9-dev. The
> failing commands are dh_movefiles and dh_md5sums,
...
> Invoking
that the processing is via pipes, see below for dh_md5sums.
(the failures are also somewhat random, sometimes the build of the .deb
succeeds, sometimes not. A race condition/something not properly
initialized?)
Invoking .../fakeroot-hurd sh -c 'command' results in different code
paths. Ho
Svante Signell, le Wed 12 Nov 2014 00:16:37 +0100, a écrit :
> On Wed, 2014-11-12 at 00:07 +0100, Samuel Thibault wrote:
> > Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit :
> > > Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite),
> > >
On Wed, 2014-11-12 at 00:07 +0100, Samuel Thibault wrote:
> Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit :
> > Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite),
> > but the latest version does not: glibc-2.19-14~0:
>
> But what "previo
Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit :
> Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite),
> but the latest version does not: glibc-2.19-14~0:
But what "previously" is exactly? Did you try to downgrade the libc or
hurd installed on your b
Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit :
> dh_install -plocales-all
> cp: cannot create symbolic link
> ‘debian/locales-all//usr/lib/locale/es_PA/LC_NUMERIC’: Device or
> resource busy
>
> What to do?
Well, investigate? This EBUSY error must be coming from somewhere.
Samuel
Hi,
Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite),
but the latest version does not: glibc-2.19-14~0:
dh_install -plocales-all
cp: cannot create symbolic link
‘debian/locales-all//usr/lib/locale/es_PA/LC_NUMERIC’: Device or
resource busy
dh_install: cp -a ./build-tree
On Thu, Jul 3, 2014 at 10:11 AM, Samuel Thibault wrote:
> Gabriele Giacone, le Thu 03 Jul 2014 01:55:35 +0200, a écrit :
>> I reproduced aghermann FTBFS and fixed it by switching fakeroot from
>> -tcp to -hurd.
>
> Ok, thanks. We'd however need to investigate these cras
Hello,
Gabriele Giacone, le Thu 03 Jul 2014 01:55:35 +0200, a écrit :
> I reproduced aghermann FTBFS and fixed it by switching fakeroot from
> -tcp to -hurd.
Ok, thanks. We'd however need to investigate these crashes, though.
> mbanck made me notice it could be useful making build
Hello,
I reproduced aghermann FTBFS and fixed it by switching fakeroot from
-tcp (I guess the active one on ironforge, at least active 6 days ago
when aghermann FTBFS'ed) to -hurd.
mbanck made me notice it could be useful making buildlogs say which
fakeroot buildd/manual builds used. Att
Quoting Samuel Thibault (2013-11-19 09:30:22)
> Justus Winter, le Mon 18 Nov 2013 18:54:45 +0100, a écrit :
> > Quoting Samuel Thibault (2013-11-18 17:15:05)
> > > So with this patch, does building packages inside the hurdish fakeroot
> > > now works?
> >
>
Justus Winter, le Mon 18 Nov 2013 18:54:45 +0100, a écrit :
> Quoting Samuel Thibault (2013-11-18 17:15:05)
> > So with this patch, does building packages inside the hurdish fakeroot
> > now works?
>
> No :/ something funny happens with some path during make
> install.
ntity ports are still compared. This cannot succeed if
> > > > fakeroot or chroot is used,
> > >
> > > Aah, that's why.
> > >
> > > So with this patch, does building packages inside the hurdish fakeroot
> > > now works?
> >
> &
Justus Winter, le Mon 18 Nov 2013 18:54:45 +0100, a écrit :
> Quoting Samuel Thibault (2013-11-18 17:15:05)
> > Justus Winter, le Mon 18 Nov 2013 16:49:57 +0100, a écrit :
> > > However, the identity ports are still compared. This cannot succeed if
> > > fakeroot or c
Quoting Samuel Thibault (2013-11-18 17:15:05)
> Justus Winter, le Mon 18 Nov 2013 16:49:57 +0100, a écrit :
> > However, the identity ports are still compared. This cannot succeed if
> > fakeroot or chroot is used,
>
> Aah, that's why.
>
> So with this patch, d
Justus Winter, le Mon 18 Nov 2013 16:49:57 +0100, a écrit :
> However, the identity ports are still compared. This cannot succeed if
> fakeroot or chroot is used,
Aah, that's why.
So with this patch, does building packages inside the hurdish fakeroot
now works?
Samuel
--
To
the script file and no attempt at
locating the script file is done. However, the identity ports are
still compared. This cannot succeed if fakeroot or chroot is used,
because the process doing the exec and thus the initial file lookup is
running in the chrooted environment, while the exec server is
Source: fakeroot
Version: 1.18.2-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
Hello,
fakeroot FTBFS on GNU/Hurd during tests of the faked-sysv script and
faked-sysv binary. Since SysV IPC is not yet supported, there is not
much idea to perform the tests for
On Sun, Sep 11, 2011 at 02:30:29PM +0200, Thomas Schwinge wrote:
> + while (1) {
> +if (connect(comm_sd, get_addr(), sizeof (struct sockaddr_in)) < 0) {
> + if (errno != EINTR)
> +fail("connect");
> +} else
> + break;
> + }
I'm concerned about the possibility for an inf
Package: fakeroot
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org
thanks
Debian GNU/Hurd folks: why do I have to specify Hurd
User/Usertags/X-Debbugs-CC, all three? Can't this be made simpler?
(This is from
<http://www.gnu.org/
Hi!
On Sun, 11 Sep 2011 11:55:21 +0200, Thomas Schwinge
wrote:
> Debian fakeroot 1.15.1-1 (fakeroot-tcp) has problems with EINTR or
> something?
>
> [...]
> ./scripts/mkinstalldirs
> /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include
Hi!
Debian fakeroot 1.15.1-1 (fakeroot-tcp) has problems with EINTR or
something?
[...]
./scripts/mkinstalldirs
/media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include
libfakeroot: connect: Interrupted system call
/usr/bin/install -c -m 644 include
Package: fakeroot
Version: 1.12.2
Severity: important
Hello,
We're getting FTBFSs on hurd-i386 because of /usr/bin/diff getting
644 instead of 755. This is apparently due to a race in fakeroot-tcp
triggered by install -s, which does the following:
- copy the target file, which is now 600
-
Your message dated Fri, 17 Jun 2005 01:27:53 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Split fakeroot into a separate package.
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case
Hello,
I just uploaded fakeroot_1.2.5_hurd-i386.deb. The hurd package no
longer conflicts with it, so you can install it safely.
However, note that fakeroot itself won't work as we (for now) don't have
sysv ipc, you need to call `fakeroot-tcp' which appears to work fine.
In t
l Banck <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Disable Hurd's fakeroot and remove fakeroot conflict
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040523i
Sender: Michael B
How about someone actually look at the bug?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, Feb 03, 2005 at 06:10:54PM -0800, Roland McGrath wrote:
> It would be better to debug the Hurd's fakeroot stuff, since it is a
> much better way to implement that than the weird kludges used on Linux.
Sure, but fakeroot is the standard way of building Debian packages, so
It would be better to debug the Hurd's fakeroot stuff, since it is a much
better way to implement that than the weird kludges used on Linux.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: hurd
Severity: normal
fakeroot-tcp from the fakeroot package appears to work fine, while the
one in the hurd package is broken (see #11509 at sv.gnu.org). So, we
should not ship fakeroot in the hurd package and remove the Conflicts:
fakeroot.
Michael
--
Michael Banck
Debian Developer
On Fri, May 03, 2002 at 07:58:16PM +0200, Niels Möller wrote:
> Ah, the fake master device port is already there. That's excellent. Is
> it the boot process in the parent that responds to the child's device
> requests, or some other component?
Yep. It's right there in hurd/boot/boot.c, for exampl
--- Jeff Bailey <[EMAIL PROTECTED]> wrote:
> On Fri, May 03, 2002 at 01:55:50PM +0200, Alfred M. Szmidt wrote:
>
> > > Well, IMHO a good solution is to hack ext2fs to allow that. Maybe
> > > with a special option and starting it dinamicaly with a "fakeroot&q
> I hope there's no hard reason for that. It ought to be possible to set
> up some bridging (similar to what vmware does between host and guest os).
>
> But sure, that's a project for the future. Having the parent hurd
> provide a "fake" device port for the subhurd to use, not giving it
> direct ac
> One problem in the context of Debian packaging is that some files want to be
> owned by other user and/or groups than root, for example news/news, or
> things like that.
So? The uid-mapping would apply to isowner/rootness tests as well,
so you could chown.
--
To UNSUBSCRIBE, email to [EMAIL
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> No, of course not. The main reason is that two Hurds (we don't call
> them subhurds anywmore, they are more peer than parent/child, you might
> call them neighbourhurd) are too isolated :) they are really two
> distinct Hurd systems running in paral
On Fri, May 03, 2002 at 04:55:59PM +0200, Niels M?ller wrote:
> > 1) Subhurds suck for connecting to a network
>
> I hope there's no hard reason for that. It ought to be possible to set
> up some bridging (similar to what vmware does between host and guest
> os).
No, of course not. The main reas
ng he asks for". That would work.
> $ settrans -ca my-pkg /hurd/tmpfs --map-uid=`whoami`:root
The whoami invocation seems a little ugly. There should probably be
some other way to refer to the uid that owns the underlying node, or
something like that.
> Note also, this all is only
stgresql and gimp).
> So, following the described behavior of fakeroot, I whipped up a translator
> to do approximately the same thing. I've checked the new file
> trans/fakeroot.c into hurd cvs with code that I have compiled but not
> tested at all.
I gave it a quick test. netfs_node_n
Jeff Bailey <[EMAIL PROTECTED]> writes:
> 1) Subhurds suck for connecting to a network
I hope there's no hard reason for that. It ought to be possible to set
up some bridging (similar to what vmware does between host and guest
os).
But sure, that's a project for the future. Having the parent hur
On Fri, May 03, 2002 at 07:37:43AM -0700, Jeff Bailey wrote:
> On Fri, May 03, 2002 at 10:34:20AM -0400, Marcus Brinkmann wrote:
>
> > > 1) Subhurds suck for connecting to a network
>
> > A firmlink for servers/socket/2 works fine, though.
>
> I've done that for chroot jails - How do you do that
On Fri, May 03, 2002 at 10:34:20AM -0400, Marcus Brinkmann wrote:
> > 1) Subhurds suck for connecting to a network
> A firmlink for servers/socket/2 works fine, though.
I've done that for chroot jails - How do you do that across a subhurd?
--
One of the great things about books is sometimes
On Fri, May 03, 2002 at 06:43:29AM -0700, Jeff Bailey wrote:
> 1) Subhurds suck for connecting to a network
A firmlink for servers/socket/2 works fine, though.
Thanks,
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Fri, May 03, 2002 at 01:55:50PM +0200, Alfred M. Szmidt wrote:
> > Well, IMHO a good solution is to hack ext2fs to allow that. Maybe
> > with a special option and starting it dinamicaly with a "fakeroot"
> > script. I need to think about this.
> What is wron
> What will it take to port fakeroot to the Hurd?
I had never bothered to understand what fakeroot really did before now.
Having looked at it tonight, I wish I had done something about it earlier.
There are several answers, each one superceding the last. I'll give you
them all in or
Hi,
I am moving this thread to the bug-hurd list. Please only reply to
that.
On Fri, May 03, 2002 at 06:46:02AM +0200, Robert Millan wrote:
> I was thinking of a hurdish alternative to fakeroot. What we need is
> just a way of chown files to any user without having root proviledges.
We
On Fri, May 03, 2002 at 08:05:59AM -0400, Ryan M. Golbeck wrote:
> Robert Millan <[EMAIL PROTECTED]> writes:
>
> > I was thinking of a hurdish alternative to fakeroot. What we need is
> > just a way of chown files to any user without having root proviledges.
>
> I d
On Fri, May 03, 2002 at 01:55:50PM +0200, Alfred M. Szmidt wrote:
>
> > I was thinking of a hurdish alternative to fakeroot. What we need is
> > just a way of chown files to any user without having root
> > proviledges.
>
> > Well, IMHO a good solution is to ha
Robert Millan <[EMAIL PROTECTED]> writes:
> I was thinking of a hurdish alternative to fakeroot. What we need is
> just a way of chown files to any user without having root proviledges.
I don't think being able to chown files to any user is a good idea.
Think about filling
* Robert Millan writes:
> On Thu, May 02, 2002 at 10:52:01PM -0700, Grant Bowman wrote:
>> What will it take to port fakeroot to the Hurd? (he asks nievely)
>>
>> When I tried to compile it it failed while testing itself with an
>> error about unimplemented message fu
On Thu, May 02, 2002 at 10:52:01PM -0700, Grant Bowman wrote:
> What will it take to port fakeroot to the Hurd?
> (he asks nievely)
>
> When I tried to compile it it failed while testing itself with an error
> about unimplemented message function. I can duplicate it if necessary.
What will it take to port fakeroot to the Hurd?
(he asks nievely)
When I tried to compile it it failed while testing itself with an error
about unimplemented message function. I can duplicate it if necessary.
Thanks,
--
-- Grant Bowman<[EMAIL PROTEC
>
> Has anyone managed to compile fakeroot? I've tried to build it
> (somewhat successfully) but it seems the HURD[1] doesn't implement
> semget (and friends). So while the build succeeds, fakeroot will not
> run, which puts package-building under the HURD at some
Has anyone managed to compile fakeroot? I've tried to build it
(somewhat successfully) but it seems the HURD[1] doesn't implement
semget (and friends). So while the build succeeds, fakeroot will not
run, which puts package-building under the HURD at something of a
disadvantage.
jason
67 matches
Mail list logo
