Re: usr/libexec/console-run: /dev/console: Read-only file system

and '#Start the > >> default pager'. > >> As I understand I have to launch 'shell' before it, and run > >> '/usr/lib/hurd/setup-translators'. > >> (...) > > You can do that, but you can also simply pass init=/bin/sh on the >

Re: usr/libexec/console-run: /dev/console: Read-only file system

2023-06-25 17:10 GMT+02:00, Samuel Thibault : > Marcin Laszewski, le sam. 24 juin 2023 22:03:45 +0200, a ecrit: >> (...) >> The 'pipe' error occures between '# Check boot flags' and '#Start the >> default pager'. >> As I understand I ha

Re: usr/libexec/console-run: /dev/console: Read-only file system

> As I understand I have to launch 'shell' before it, and run > '/usr/lib/hurd/setup-translators'. > > Am I right? You can do that, but you can also simply pass init=/bin/sh on the gnumach kernel command line, that'll get evaluated just above that. Samuel

Re: usr/libexec/console-run: /dev/console: Read-only file system

Thank you. I've added 'set -v -x' to /etc/hurd/runsystem.sysv and I see executed commands. The 'pipe' error occures between '# Check boot flags' and '#Start the default pager'. As I understand I have to launch 'shell' before it, and run 

Re: usr/libexec/console-run: /dev/console: Read-only file system

Marcin Laszewski, le lun. 12 juin 2023 21:48:13 +0200, a ecrit: > 2023-06-12 12:35 GMT+02:00, Samuel Thibault : > > You are still getting the > > > > settrans: /servers/socket/1: Operation not supported. > > > > error? > > No. This one: > > /usr/

Re: usr/libexec/console-run: /dev/console: Read-only file system

2023-06-12 12:35 GMT+02:00, Samuel Thibault : > You are still getting the > > settrans: /servers/socket/1: Operation not supported. > > error? No. This one: /usr/libexec/runsystem: Pipe call failed.

Re: usr/libexec/console-run: /dev/console: Read-only file system

Marcin Laszewski, le lun. 12 juin 2023 12:19:34 +0200, a ecrit: > 2023-06-10 17:12 GMT+02:00, Samuel Thibault : > > (...) > > I hadn't checked because I assumed "-L hurd" was about it: you *need* > > -o hurd > > I've created EXT2 filesystem: > > # mkfs.ext2 -o hurd -I 128 -L hurd /dev/hd2s3 > >

Re: usr/libexec/console-run: /dev/console: Read-only file system

2023-06-10 17:12 GMT+02:00, Samuel Thibault : > (...) > I hadn't checked because I assumed "-L hurd" was about it: you *need* > -o hurd I've created EXT2 filesystem: # mkfs.ext2 -o hurd -I 128 -L hurd /dev/hd2s3 Nothing has changed. Here is output of 'tune2fs /dev/hd2s3'. I see 'Filesystem OS t

Re: usr/libexec/console-run: /dev/console: Read-only file system

Marcin Laszewski, le mar. 06 juin 2023 11:59:23 +0200, a ecrit: > 1. I have created ext2 filesystem: mkfs.ext2 -I 128 -L hurd /dev/hd2s3 I hadn't checked because I assumed "-L hurd" was about it: you *need* -o hurd otherwise translators won't be recordable in it. Samuel

Re: usr/libexec/console-run: /dev/console: Read-only file system

I am able to run console. $ fsysopts / --update --writeable # OK $ settrabs -c /servers/socket/1 /hurd/pflocal # Error: settrans: /servers/socket/1: Operation not supported. I see this error when I run /usr/lib/hurd/setup-translators How can I setup translators?

Re: usr/libexec/console-run: /dev/console: Read-only file system

Marcin Laszewski, le mar. 06 juin 2023 13:44:05 +0200, a ecrit: > 2023-06-06 13:39 GMT+02:00, Samuel Thibault : > > Yes, pipes can't work until you have the pflocal translator set on > > /servers/socket/1 > > How can I launch it under chroot ? As I said, use /usr/lib/hu

Re: usr/libexec/console-run: /dev/console: Read-only file system

Marcin Laszewski, le mar. 06 juin 2023 13:42:58 +0200, a ecrit: > 2023-06-06 13:06 GMT+02:00, Samuel Thibault : > > Marcin Laszewski, le mar. 06 juin 2023 12:56:43 +0200, a ecrit: > >> 2023-06-06 12:29 GMT+02:00, Samuel Thibault : > > (...) , but don't you also get a shell prompt? > > I've found

Re: usr/libexec/console-run: /dev/console: Read-only file system

2023-06-06 13:39 GMT+02:00, Samuel Thibault : > Yes, pipes can't work until you have the pflocal translator set on > /servers/socket/1 How can I launch it under chroot ?

Re: usr/libexec/console-run: /dev/console: Read-only file system

2023-06-06 13:06 GMT+02:00, Samuel Thibault : > Marcin Laszewski, le mar. 06 juin 2023 12:56:43 +0200, a ecrit: >> 2023-06-06 12:29 GMT+02:00, Samuel Thibault : > (...) , but don't you also get a shell prompt? I've found 'root=' in 'kern/bootstrap.c', but there is no 'init='. It seems that 'root=

Re: usr/libexec/console-run: /dev/console: Read-only file system

Marcin Laszewski, le mar. 06 juin 2023 13:35:38 +0200, a ecrit: > Unfortunately it doesn't work. Then you can try to run by hand /usr/lib/hurd/setup-translators > It seems, that dpkg doesn't work in

Re: usr/libexec/console-run: /dev/console: Read-only file system

re hurd > > That's an option, yes. Unfortunately it doesn't work. # chroot /mnt/hurd # dpkg-reconfigure hurd [?2004l Use of uninitialized value $Debconf::Encoding::charmap in scalar chomp at /usr/share/perl5/Debconf/Encoding.pm line 17. Use of uninitialized value

Re: usr/libexec/console-run: /dev/console: Read-only file system

Marcin Laszewski, le mar. 06 juin 2023 12:56:43 +0200, a ecrit: > 2023-06-06 12:29 GMT+02:00, Samuel Thibault : > > That's not enough, tar doesn't know about translators, so all /dev and > > /servers entries are not properly set. You can probably fix this by > > passing init=/bin/sh to gnumach, and

Re: usr/libexec/console-run: /dev/console: Read-only file system

2023-06-06 12:29 GMT+02:00, Samuel Thibault : > That's not enough, tar doesn't know about translators, so all /dev and > /servers entries are not properly set. You can probably fix this by > passing init=/bin/sh to gnumach, and there use ... GRUB ...

Re: usr/libexec/console-run: /dev/console: Read-only file system

Hello, Marcin Laszewski, le mar. 06 juin 2023 11:59:23 +0200, a ecrit: > 2. I have mounted my "new" rootfs as /mnt/hurd > 3. I have copied my files to it: tar cvf - -C / . | tar xvf - -C /mnt/hurd That's not enough, tar doesn't know about translators, so all /dev and /servers entries are not prop

usr/libexec/console-run: /dev/console: Read-only file system

servr bootstrap: ext2fs[device:hd2s3] exec startup proc auth. /usr/libexec/console-run: /dev/console: Read-only file system /usr/libexec/runsystem: 118: Pipe call failed . Wh

[debian-hurd-Bugs][312550] *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 ***

one) Summary: *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 *** Category: None Group: None Resolution: None Initial Comment: a few perl applications, perldoc notably, crash with *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 ***

Re: Bug#810301: merged /usr support for debootstrap

, what should we have here for your archs? For those wondering (and AFAICT) it seems the only issue here is how to handle multilib, since multiarch is “hidden” below usr/lib (in usr/lib/ subdirectories). > > + amd64) link_dir="lib32 lib64 libx32" ;; > > +

Bug#723357: marked as done (hurd-libfuse link with -L/usr/lib)

Your message dated Tue, 17 Sep 2013 13:11:45 +0200 with message-id <2013091745.gk5...@type.bordeaux.inria.fr> and subject line Re: Bug#723357: hurd-libfuse link with -L/usr/lib has caused the Debian Bug report #723357, regarding hurd-libfuse link with -L/usr/lib to be marked as done.

Bug#723357: hurd-libfuse link with -L/usr/lib

Package: hurd-libfuse Version: 0.0.20130220-1 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is

Re: Bug#557771: *** stack smashing detected ***: /usr/bin/perl terminated

Hi! First, thanks for handling this old issue! On Tue, 20 Mar 2012 22:58:37 +, Dominic Hargreaves wrote: > On Mon, Dec 28, 2009 at 12:43:43AM +0100, Thomas Schwinge wrote: > > $ perl -e 'use Image::Magick;' > > *** stack smashing detected ***: perl terminated > > Aborted > > I

Re: Bug#557771: *** stack smashing detected ***: /usr/bin/perl terminated

5.dfsg1-2 (which I think was the > latest version built for GNU/Hurd?) in the current Perl environment. > > > > > Please note that the perl test suite doesn't pass on hurd yet AFAIK, so > > > it's possible this is just a consequence of unimplemented or u

Re: Bug#639517: Riddling absence of /usr/lib/libattr.la

On 08/29/2011 11:01 AM, Samuel Thibault wrote: > Thomas Schmitt, le Sat 27 Aug 2011 21:54:31 +0200, a écrit : >> This idea must come from libacl-dev. >> And really in >> /lib/libacl.la >> i read >> dependency_libs=' /usr/lib/libattr.la' > &g

Re: Bug#639517: Riddling absence of /usr/lib/libattr.la

>> /lib/libacl.la > >>i read > >> dependency_libs=' /usr/lib/libattr.la' > > > >Yes, that's the problem: it should rather be a -lattr, because > >libattr.la is not shipped any more. That would be fixed by a newer build > >of the acl pac

Re: Bug#639517: Riddling absence of /usr/lib/libattr.la

On Mon, Aug 29, 2011 at 11:01:12AM +0200, Samuel Thibault wrote: >Thomas Schmitt, le Sat 27 Aug 2011 21:54:31 +0200, a écrit : >>This idea must come from libacl-dev. >>And really in >> /lib/libacl.la >>i read >> dependency_libs=' /usr/lib/libattr.la' &

Re: Riddling absence of /usr/lib/libattr.la

Thomas Schmitt, le Sat 27 Aug 2011 21:54:31 +0200, a écrit : > This idea must come from libacl-dev. > And really in > /lib/libacl.la > i read > dependency_libs=' /usr/lib/libattr.la' Yes, that's the problem: it should rather be a -lattr, because libattr.la is no

Re: Riddling absence of /usr/lib/libattr.la

do wonder, how my generated Makefile comes to the idea to expect libattr.la if it is removed from the system. None of my files mentions libattr. This idea must come from libacl-dev. And really in /lib/libacl.la i read dependency_libs=' /usr/lib/libattr.la' Following the prescriptions in L

Re: Bug#639517: Riddling absence of /usr/lib/libattr.la

Sorry thanks for your patch... as the release goal says if you can make a case for using it then we should ship (and use your pat h, thanks a lot for taking the effort). I'll let nathans comment what he thinks, Cheers On Aug 27, 2011 4:00 PM, "harish badrinath" wrote: > On Sun, Aug 28, 2011 at 1

Re: Riddling absence of /usr/lib/libattr.la

On Sun, Aug 28, 2011 at 12:21 AM, Niv Sardi wrote: > http://wiki.debian.org/ReleaseGoals/LAFileRemoval > > IIRC, It's a release goal. Well that was embarrassing :). I will close the bug. Sorry, Harish > On Aug 27, 2011 3:42 PM, "Harish Badrinath" > wrote: >> Package: libattr1-dev >> Version:

Re: Riddling absence of /usr/lib/libattr.la

Hello, dpkg -S libattr* | grep la is returning empty for me too. Package: libattr1 Source: attr Version: 1:2.4.46-3 Architecture: hurd-i386 I have posted a bug report,http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639517 CREDIT clarification: If there is response from the debian maintainer,

Re: Riddling absence of /usr/lib/libattr.la

Hello, dpkg -S libattr* | grep la is returning empty for me too. Package: libattr1 Source: attr Version: 1:2.4.46-3 Architecture: hurd-i386 I have posted a bug report,http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639517 CREDIT clarification: If there is response from the debian maintainer,

Riddling absence of /usr/lib/libattr.la

/usr/lib/libattr.la if libacl-dev is installed. I solved this by copying /usr/lib/libattr.la from the hosting system to Hurd, where i had to change its content from libdir='/usr/lib' to libdir='/lib/i386-gnu' But libisofs-1.1.4 builds fine on buildd ("bach") for hur

[debian-hurd-Bugs][312550] *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 ***

y: *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 *** Category: None Group: None Resolution: None Initial Comment: a few perl applications, perldoc notably, crash with *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 *** This is in p

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

Svante Signell, le Mon 07 Feb 2011 12:49:35 +0100, a écrit : > On Mon, 2011-02-07 at 12:26 +0100, Samuel Thibault wrote: > > Svante Signell, le Mon 07 Feb 2011 07:01:40 +0100, a écrit : > > > For people who don't have access to buildd, I have a cronjob which puts > > it on http://people.debian.org

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

On Mon, 2011-02-07 at 12:26 +0100, Samuel Thibault wrote: > Svante Signell, le Mon 07 Feb 2011 07:01:40 +0100, a écrit : > For people who don't have access to buildd, I have a cronjob which puts > it on http://people.debian.org/~sthibault/failed_packages.txt everyday. Thanks! Maybe the file shoul

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

Svante Signell, le Mon 07 Feb 2011 07:01:40 +0100, a écrit : > Is there some way to find out how many and which packages are affected > by a certain feature, like in the mail from Michael Banck in 2007: > > http://lists.gnu.org/archive/html/bug-hurd/2007-07/msg1.html ssh buildd.debian.org wan

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

On Mon, 2011-02-07 at 04:10 +0100, Samuel Thibault wrote: > Hello, > > I've commited the upstream-submitted fix to eglibc. Thanks! Is there some way to find out how many and which packages are affected by a certain feature, like in the mail from Michael Banck in 2007: http://lists.gnu.org/archi

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

Hello, I've commited the upstream-submitted fix to eglibc. 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/20110207031024.gl4...@const.famille.thibault.fr

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

Svante Signell, le Mon 31 Jan 2011 13:58:29 +0100, a écrit : > On Sun, 2011-01-30 at 15:19 +0100, Samuel Thibault wrote: > > I've completed Aurelien's any/submitted-sched_h.diff patch in my tree, I'll > > commit it after the squeeze release. > > Looks like there is a patch from 2009 in addition to

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

On Sun, 2011-01-30 at 15:19 +0100, Samuel Thibault wrote: > I've completed Aurelien's any/submitted-sched_h.diff patch in my tree, I'll > commit it after the squeeze release. Looks like there is a patch from 2009 in addition to the one from 2007: http://lists.debian.org/debian-glibc/2007/12/msg00

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

I've completed Aurelien's any/submitted-sched_h.diff patch in my tree, I'll commit it after the squeeze release. 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

Re: Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

Svante Signell, le Sun 30 Jan 2011 10:44:02 +0100, a écrit : > Looks like the GNU/Hurd header file /usr/include/bits/sched.h is > outdated compared to the GNU/Linux version. Attached is a diff between > the two files. The missing definitions of __CPU_ZERO_S and __CPU_SET_S > is affecti

Outdated header file /usr/include/bits/sched.h for GNU/Hurd!?

severity 527589 important Package: libc0.3-dev Tags: patch Version: 2.11.2-10 Looks like the GNU/Hurd header file /usr/include/bits/sched.h is outdated compared to the GNU/Linux version. Attached is a diff between the two files. The missing definitions of __CPU_ZERO_S and __CPU_SET_S is affecting

[debian-hurd-Bugs][312550] *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 ***

y: *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 *** Category: None Group: None Resolution: None Initial Comment: a few perl applications, perldoc notably, crash with *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 *** This is in p

[debian-hurd-Bugs][312550] *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 ***

y: *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 *** Category: None Group: None Resolution: None Initial Comment: a few perl applications, perldoc notably, crash with *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 *** This is in p

Bug#557418: marked as done (crosshurd: The usr->. symlink is deprecated)

Your message dated Sun, 14 Mar 2010 22:12:16 +0100 with message-id <20100314211216.ga13...@const.famille.thibault.fr> and subject line Re: The usr->. symlink is deprecated has caused the Debian Bug report #557418, regarding crosshurd: The usr->. symlink is deprecated to be marked as

Re: Bug#557771: *** stack smashing detected ***: /usr/bin/perl terminated

d yet AFAIK, so > > it's possible this is just a consequence of unimplemented or unfinished > > functionality. Reproducing the bug on another port would eliminate that. Trying to run the perlmagick demos: $ rsync -a /usr/share/doc/perlmagick/examples/demo/ perlmagick-demos/

Re: Bug#557771: *** stack smashing detected ***: /usr/bin/perl terminated

Hi, Alle domenica 27 dicembre 2009, Thomas Schwinge ha scritto: > On Fri, Dec 25, 2009 at 03:26:05PM +0200, Niko Tyni wrote: > > Looks rather like a problem with the Storable module, but it's hard to > > say more without a test case. > > That's what I thought, too, but I now bisected this down to

Re: Bug#557771: *** stack smashing detected ***: /usr/bin/perl terminated

Hello! On Fri, Dec 25, 2009 at 03:26:05PM +0200, Niko Tyni wrote: > Looks rather like a problem with the Storable module, but it's hard to say > more without a test case. That's what I thought, too, but I now bisected this down to perlmagick being installed vs. not being installed. Involving Pin

Bug#557418: crosshurd: The usr->. symlink is deprecated

Package: crosshurd Version: 1.7.36 Severity: normal Hello, The usr->. symlink has been posing too many issues with shlibdeps & such so we ended up deciding that we don't want to support it any more. crosshurd should thus not even propose it. Samuel -- System Information: De

Re: The /usr > . sysmlink

മഹേഷ് മുകുന്ദന് | Mahesh M, le Tue 22 Sep 2009 11:35:39 -0100, a écrit : > What is the status of grub in hurd? Hasn't changed. > Can anybody please fix it if it has not yet been. It's in TODO lists since a long time, yes. > I think i was told that only little more has to be done. But the littl

Re: The /usr > . sysmlink

:00:25 +1200, a écrit : >> Is the /usr > . symlink still the standard on Debian GNU/Hurd systems? > > Nope, it poses too many issues that we can't necessarily fix. > > Samuel > > > -- > To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org > with

Re: The /usr > . sysmlink

On Tue, 22 Sep 2009, Samuel Thibault wrote: > Philip Charles, le Tue 22 Sep 2009 18:00:25 +1200, a écrit : > > Is the /usr > . symlink still the standard on Debian GNU/Hurd > > systems? > > Nope, it poses too many issues that we can't necessarily fix. > > Sam

Re: The /usr > . sysmlink

Philip Charles, le Tue 22 Sep 2009 18:00:25 +1200, a écrit : > Is the /usr > . symlink still the standard on Debian GNU/Hurd systems? Nope, it poses too many issues that we can't necessarily fix. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a

The /usr > . sysmlink

Is the /usr > . symlink still the standard on Debian GNU/Hurd systems? Thanks. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453 phil...@copyleft.co.nz - personal.i...@copyleft.co

/usr -> . symlink

Just another reason for _not_ creating a /usr -> . symlink on debian systems: the pciutils package creates both /usr/bin/lspci and /bin/lspci that points to /usr/bin/lspci, and unfortunately the symlink gets created after the real program... Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTEC

/usr->. symlink (was: K15 mini iso)

Hi, On Wed, Nov 21, 2007 at 05:44:43PM +0100, Michael Banck wrote: > The true GNU snapshots will have a /usr->. symlink (or no /usr at > all). Actually neither is right I think. AIUI the idea is to have /usr unioned into / , so the files can be put in separate locations, but are al

[debian-hurd-Patches][303058] #349418: libapr0-dev: /usr/include/apr-0/apr.h #errors

Patches item #303058, was opened at 15/02/2006 19:32 >Status: Closed Priority: 3 Submitted By: Samuel Thibault (sthibaul-guest) Assigned to: Nobody (None) Summary: #349418: libapr0-dev: /usr/include/apr-0/apr.h #errors Category: None Group: None >Resolution: Fixed Initial Comment:

Bug#365828: marked as done (gnumach: Should install msgids into /usr/share/msgids)

Your message dated Tue, 6 Mar 2007 22:13:49 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#365828: gnumach: Should install msgids into /usr/share/msgids has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt wi

Re: Debian GNU/Hurd and ``/usr -> .''

On Wed, Dec 06, 2006 at 07:43:01PM +0100, Thomas Schwinge wrote: > Having a symbolic link for `/usr' that points to `.' has again and again > proven to be not really suitable for the Debian GNU/Hurd operating system > -- simply for the reason that this isn't what Debian GNU

Re: Debian GNU/Hurd and ``/usr -> .''

Thomas Schwinge wrote: Hello! Having a symbolic link for `/usr' that points to `.' has again and again proven to be not really suitable for the Debian GNU/Hurd operating system -- simply for the reason that this isn't what Debian GNU/Linux is doing, which is where 99,9 % of all

Debian GNU/Hurd and ``/usr -> .''

Hello! Having a symbolic link for `/usr' that points to `.' has again and again proven to be not really suitable for the Debian GNU/Hurd operating system -- simply for the reason that this isn't what Debian GNU/Linux is doing, which is where 99,9 % of all Debian packages are main

[ debian-hurd-Patches-303058 ] #349418: libapr0-dev: /usr/include/apr-0/apr.h #errors

st) Assigned to: Nobody (None) Summary: #349418: libapr0-dev: /usr/include/apr-0/apr.h #errors Initial Comment: Breaks subversion & such that use apr -- Comment By: Samuel Thibault (sthibaul-guest) Date: 06/10/2006 23:53

[ debian-hurd-Patches-303058 ] #349418: libapr0-dev: /usr/include/apr-0/apr.h #errors

st) Assigned to: Nobody (None) Summary: #349418: libapr0-dev: /usr/include/apr-0/apr.h #errors Initial Comment: Breaks subversion & such that use apr -- >Comment By: Samuel Thibault (sthibaul-guest) Date: 06/10/2006 23

[ debian-hurd-Patches-303058 ] #349418: libapr0-dev: /usr/include/apr-0/apr.h #errors

ul-guest) Assigned to: Nobody (None) Summary: #349418: libapr0-dev: /usr/include/apr-0/apr.h #errors Initial Comment: Breaks subversion & such that use apr -- You can respond by visiting: http://alioth.debian.org/tracker/?f

Bug#365828: gnumach: Should install msgids into /usr/share/msgids

On Wed, May 03, 2006 at 10:07:14AM +0200, Michael Banck wrote: > the gnumach package should install the msgids files in /usr/share/msgids This is already being worked on, see http://savannah.gnu.org/task/?func=detailitem&item_id=1017>. > (where the hurd package will put them star

Bug#365828: gnumach: Should install msgids into /usr/share/msgids

Package: gnumach Version: 1:20060408.dfsg.1-1 Severity: wishlist Hi, the gnumach package should install the msgids files in /usr/share/msgids (where the hurd package will put them starting from the next upload as well), unless there are reservations about the directory naming etc. cheers

Bug#320121: marked as done (/usr/include/semaphore.h's use of the 'restrict' keyword)

for <[EMAIL PROTECTED]>; Wed, 27 Jul 2005 07:55:18 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> Date: Wed, 27 Jul 2005 08:01:52 +0200 From: Julien PUYDT <[EMAIL PROTECTED]> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: fr, en MIME-Version: 1.0 To: [EMAIL

Bug#320121: /usr/include/semaphore.h's use of the 'restrict' keyword

Package: hurd-dev Version: 20050513-3 Hi, I tried to compile some app on GNU/Hurd, but had a problem with semaphore.h's use of 'restrict' keyword: it is a C99 keyword, and hence makes gcc (Debian 1:3.3.6-4) a little unhappy. I was said on #hurdfr to replace restrict with __restrict, to see if

Re: /usr -> .

> What about a firmlink? That would solve all problems. What is a firmlink? /hurd/firmlink --help, [hurd]/trans/firmlink.c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /usr -> .

Michael D. Adams wrote: On 7/22/05, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote: What about a firmlink? That would solve all problems. What is a firmlink? See . HTH, -- Manuel Menal -- To UNSUBSCRIBE, email to [EMAIL PROTE

Re: /usr -> .

On 7/22/05, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote: > What about a firmlink? That would solve all problems. What is a firmlink? Back to lurking, Michael D. Adams [EMAIL PROTECTED]

Re: /usr -> .

So the problem remains : if you put /bin first in your PATH, you'll have configure discover 'gzip' in /bin (which is the right thing) and 'pager' in /bin (which is the wrong thing), and if you put /usr/bin first you'll have the same problem the o

Re: /usr -> .

> What about a firmlink? That would solve all problems. Would it ? Yes. You don't get the funky side-effects of symlinks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /usr -> .

x27;gzip' in /bin (which is the right thing) and 'pager' in /bin (which is the wrong thing), and if you put /usr/bin first you'll have the same problem the other way around. Thanks, -- Manuel Menal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /usr -> .

What about a firmlink? That would solve all problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /usr -> .

Alfred M. Szmidt wrote: What about a firmlink? That would solve all problems. Would it ? I don't see how it would solve, e.g., the problem we had with man-db. Using a firmlink instead of a symlink might be a good idea anyway, though. Cheers, -- Manuel Menal -- To UNSUBSCRIBE, email to [EMA

Re: /usr -> .

On Thu, Jul 14, 2005 at 04:18:51PM +0200, Manuel Menal wrote: > Thomas Schwinge wrote: > >I strongly suggest to remove the '/usr -> .' symlink from the Debian > >GNU/Hurd system. Having this symlink (and having no /usr anymore, > >eventually) is suited for

Re: /usr -> .

Hiran Watson wrote: This is probably a dumb question, but currently where is /usr a symlink to? AFAIK, on my Debian GNU/Linux system, /usr is its own dir, and not a symlink. As Thomas pointed out earlier, it's specific to the GNU system, and that's where Debian GNU/Hurd took it

Re: /usr -> .

This is probably a dumb question, but currently where is /usr a symlink to? AFAIK, on my Debian GNU/Linux system, /usr is its own dir, and not a symlink. Also, with my limited knowledge, would a hard link work instead of a soft one (symlink)? Thanks for the info. God bless Hiran On 7/14/05

Re: /usr -> .

Thomas Schwinge wrote: [ Moved to the Debian GNU/Hurd mailing list. ] [snip] AFAIK this is not the first time for something like this to happen. It sure isn't. I strongly suggest to remove the '/usr -> .' symlink from the Debian GNU/Hurd system. Having this symlink (

/usr -> . (was: [ debian-hurd-Bugs-301806 ] man-db package broken with a separate /usr)

[ Moved to the Debian GNU/Hurd mailing list. ] > Summary: man-db package broken with a separate /usr > The hurd-i386 man-db package is broken when you have a separate > /usr directory, which is the default for Debian GNU/Hurd. Here is why : > [...] > The man-db package must

[ debian-hurd-Bugs-301806 ] man-db package broken with a separate /usr

gned to: Nobody (None) Summary: man-db package broken with a separate /usr Initial Comment: The hurd-i386 man-db package is broken when you have a separate /usr directory, which is the default for Debian GNU/Hurd. Here is why : [EMAIL PROTECTED]:~$ strings -a /usr/bin/man|grep gzip /usr/bin/gz

Re: [ debian-hurd-Bugs-301806 ] man-db package broken with a separate /usr

Michael Banck wrote: On Mon, Jun 20, 2005 at 12:37:57PM +, [EMAIL PROTECTED] wrote: [snip] I've built man-db_2.4.2-22 now, having a real /usr, so this bug should be gone by the time I get around uploading the package (so, tomorrow's dinstall run probably). It seems building

Re: [ debian-hurd-Bugs-301806 ] man-db package broken with a separate /usr

On Mon, Jun 20, 2005 at 12:37:57PM +, [EMAIL PROTECTED] wrote: > Summary: man-db package broken with a separate /usr > > Initial Comment: > The hurd-i386 man-db package is broken when you have a separate > /usr directory, which is the default for Debian GNU/Hurd. Here is wh

[ debian-hurd-Bugs-301806 ] man-db package broken with a separate /usr

d to: Nobody (None) Summary: man-db package broken with a separate /usr Initial Comment: The hurd-i386 man-db package is broken when you have a separate /usr directory, which is the default for Debian GNU/Hurd. Here is why : [EMAIL PROTECTED]:~$ strings -a /usr/bin/man|grep gzip /usr/bin/gzip -c7 /

Re: dpkg-shlibdeps, ldd and /usr -> .

On Thu, Oct 10, 2002 at 12:25:29PM +1000, Glenn McGrath wrote: > I think the one great strength rpm's have over deb's is that they > appear to have all there packaging stuff in one library, whereas we > have bits and pieces scattered everywhere in all sorts of languages. I would have trouble desc

Re: dpkg-shlibdeps, ldd and /usr -> .

On Wed, 9 Oct 2002 18:37:20 -0700 Jeff Bailey <[EMAIL PROTECTED]> wrote: > I don't suppose doogie mentioned whether this feature was coming > before or after the upcoming iceage, did he? =) > No, i wondered myself, but wasnt in the mood to push him. > I can't complain, I don't speak enough Perl

Re: dpkg-shlibdeps, ldd and /usr -> .

On Thu, Oct 10, 2002 at 11:27:43AM +1000, Glenn McGrath wrote: > >The .shlibs file doesnt mention any path, so does the path (/usr/lib or > > /lib) really need to be considered when dpkg-shlibdeps tries to find a > > match ? (maybe its a dumb question) > Im told on #deiban-

Re: dpkg-shlibdeps, ldd and /usr -> .

>The .shlibs file doesnt mention any path, so does the path (/usr/lib or > /lib) really need to be considered when dpkg-shlibdeps tries to find a > match ? (maybe its a dumb question) > Im told on #deiban-devel the plan is to have dpkg strip the path, match on filename, then on t

dpkg-shlibdeps, ldd and /usr -> .

[EMAIL PROTECTED]:/build/expect-5.38.0/debian$ ldd /usr/bin/expect libexpect5.37.so.1 => /lib/libexpect5.37.so.1 (0x01028000) libtcl8.3.so.1 => /lib/libtcl8.3.so.1 (0x0104e000) libdl.so.2 => /lib/libdl.so.2 (0x010d2000) libm.so.6 => /lib/libm.so.6 (0x010d5000)

Re: /usr -> . transition

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.

Re: /usr -> . transition

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 package

/usr -> . transition

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

Re: /usr in /etc/profile

On Sun, 1 Jul 2001 [EMAIL PROTECTED] wrote: > base-files provides /etc/profile > > /etc/profiles sets the default $PATH. > > The default $PATH contains /usr path elements. > > Would it be a good idea to remove the redundant /usr parts of the > path element

/usr in /etc/profile

base-files provides /etc/profile /etc/profiles sets the default $PATH. The default $PATH contains /usr path elements. Would it be a good idea to remove the redundant /usr parts of the path elements? Paul.

  1   2   >