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 PROTECTED]
--
On Thu, May 02, 2002 at 09:01:12PM -0400, Marcus Brinkmann wrote:
No. See
http://lists.debian.org/debian-dpkg/2002/debian-dpkg-200204/msg00094.html
I think this problem needs to be fixed in the root, having a usr - .
simlink on the DESTDIR of every debian package when it's being built
on
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.
I was thinking of a
Hello,
Does anyone disagree with this?
# Install on / instead of /usr when on GNU
DEB_BUILD_GNU_SYSTEM ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_SYSTEM)
ifeq (hurd, $(DEB_BUILD_GNU_SYSTEM))
prefix=/
else
prefix=/usr
endif
We could put it in debian/rules of all debian packages,
* 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 function. I can duplicate it if
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 up someone's disk quota.
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 hack ext2fs to allow that. Maybe
with a
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 don't think being able to chown files to
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.
Well, we do
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 order, not
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 wrong with a sub-hurd?
1) Subhurds suck for
On Fri, May 03, 2002 at 08:53:29AM +0200, Robert Millan wrote:
Does anyone disagree with this?
Yes, I do.
It might not be a definitive solution but it's something we need
to do sooner or later anyway. What do you think?
We are certainly not putting an indefinitive solution into all packages,
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 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 across a
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 hurd
On Fri, May 03, 2002 at 09:13:57AM -0400, Roland McGrath wrote:
The unimplemented functions are the sysvipc interfaces (msgsnd/msgrcv et
al). They're not implemented. They would not be real hard to implement
and I won't get into to how to implement them, but there is almost never
any
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 reason is
On Fri, May 03, 2002 at 09:21:43AM -0700, Grant Bowman wrote:
* Robert Millan [EMAIL PROTECTED] [020503 08:37]:
On Thu, May 02, 2002 at 09:01:12PM -0400, Marcus Brinkmann wrote:
No. See
http://lists.debian.org/debian-dpkg/2002/debian-dpkg-200204/msg00094.html
I think this problem
On Fri, May 03, 2002 at 08:53:29AM +0200, Robert Millan wrote:
ifeq (hurd, $(DEB_BUILD_GNU_SYSTEM))
prefix=/
else
prefix=/usr
endif
We could put it in debian/rules of all debian packages, starting
with the dh-make templates
This is completely irreal.
--
Jordi Mallach Pérez ||
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 parallel,
On Fri, May 03, 2002 at 12:51:12PM -0400, Marcus Brinkmann wrote:
There is no logic in putting symlinks into all packages.
The whole purpose of having the usr symlink is for packages that install
into /usr. If we were going to change packages, they should not install
into /usr in the first
Marcus,
Relax, I'm agreeing with you. You must have too much time on your hands
like I do at the moment. Please trust in the process, go write some
code and let other people work out their own issues.
--
-- Grant Bowman[EMAIL PROTECTED]
--
To UNSUBSCRIBE,
On Fri, May 03, 2002 at 11:06:10AM -0700, Grant Bowman wrote:
Marcus,
Relax, I'm agreeing with you. You must have too much time on your hands
like I do at the moment.
Actually not, that's why I didn't read Robert's mail carefully enough.
Please trust in the process, go write some
code
* Marcus Brinkmann [EMAIL PROTECTED] [020503 11:14]:
Yeah, uh, like a patch for dpkg-shlibdeps, which I will send to the
BTS now.
Excellent news, thanks very much for doing this important work!
Cheers,
--
-- Grant Bowman[EMAIL PROTECTED]
--
To UNSUBSCRIBE,
On Fri, May 03, 2002 at 11:29:07AM -0700, Grant Bowman wrote:
* Marcus Brinkmann [EMAIL PROTECTED] [020503 11:14]:
Yeah, uh, like a patch for dpkg-shlibdeps, which I will send to the
BTS now.
Excellent news, thanks very much for doing this important work!
It's at
Hi,
I am python illiterate. Can someone who isn't please pick this up?
Thanks,
Marcus
On Fri, May 03, 2002 at 08:50:44PM +0200, Wichert Akkerman wrote:
Please provide a patch for the python version in dpkg-dev CVS instead,
I already told you that dpkg will switch to that.
Wichert.
--
I'm missing something, when will the switch take place upstream?
I see the old version here:
cvs -d :pserver:[EMAIL PROTECTED]:/cvs/dpkg co dpkg
and the python version here:
cvs -d :pserver:[EMAIL PROTECTED]:/cvs/dpkg co dpkg-dev
Cheers,
--
-- Grant Bowman
Last I checked the dpkg-dev CVS worked correctly without changes.
However, I asked in #debian-devel in December or so when we would be
considering switching and got laughter in response.
Will you be switching to the python version soon? We can work around
this bug on the buildd and the people
Previously Jeff Bailey wrote:
Last I checked the dpkg-dev CVS worked correctly without changes.
However, I asked in #debian-devel in December or so when we would be
considering switching and got laughter in response.
Heh, laughter. Not the best reaction.
Will you be switching to the python
On Fri, May 03, 2002 at 09:52:39PM +0200, Wichert Akkerman wrote:
Previously Jeff Bailey wrote:
Last I checked the dpkg-dev CVS worked correctly without changes.
However, I asked in #debian-devel in December or so when we would be
considering switching and got laughter in response.
Heh,
hi i need help i cant get my at button to vome up
so i cant access chat rooms can u help me please ?
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
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 access to
--- 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
script. I need to think about this.
What is
Previously Marcus Brinkmann wrote:
This sounds like my patch would still be useful, for 1.10.
1.10 is basically frozen, I can't promise I will include it in
there. Maybe in 1.10.1.
Wichert.
--
_
/[EMAIL PROTECTED] This
I've just posted a followup patch to the gcc-3.0 packaging bug that
generates an incorrect dependancy on libc0.3. I've fixed the package
on alpha.
I'm trying to avoid hackery like having a fake libc6-dev package. It
shouldn't be needed and packages with bad dependancies are broken. If
you're
36 matches
Mail list logo
