Package: src:gettext
Version: 0.22.5-1
Hello Samuel.
I see that the new gettext (0.22.5) currently has a FTBFS problem in hurd-i386.
https://buildd.debian.org/status/fetch.php?pkg=gettext=hurd-i386=0.22.5-2=1721996687=0
I'm reporting this bug myself as a placeholder: If you happen to find a
El 20/5/23 a las 9:29, Petter Reinholdtsen escribió:
[Guillem Jover 2005]
Can you reproduce #35970 with the latest gnumach packages?
[Santiago Vila 2005]
I don't know, and it is going to be quite difficult for me to check, because
the computer is currently running woody as a server
Package: src:gettext
Version: 0.21-9
X-Debbugs-CC: sanv...@debian.org,debian-hurd@lists.debian.org
After applying the patch proposed in Bug#982085 (with minor changes),
the build-dependencies of gettext now allow building under hurd-i386,
but currently it fails some tests. Example:
FAIL:
On Sat, May 21, 2016 at 10:48:01PM +, Gage Morgan wrote:
> Another thing: Apparently Debian is having issues with compiling
> things to 32bit architectures due to removal of features in GCC,
That's not accurate.
Support for very old CPUs have been removed, that's all.
So, there may be
On Fri, 22 Jun 2007, DDPOMail robot wrote:
Dear GNU Hurd Maintainers,
The following possible problem(s) were detected in the package(s)
you maintain in Debian:
gnumach:
This package has not been in testing for more than 751 days.
This package has not been able to migrate from
On Tue, 10 Apr 2007, Barry deFreese wrote:
OK, attempt #2. Better or should I not use two var and use like
DEB_EXTRA_CONFIGURE_FLAGS or some such?
Much better, yes. There is no policy about that, so maintainers have
full freedom about this. Try filing a bug, and the ntp maintainer will
adapt
On Tue, 10 Apr 2007, Barry deFreese wrote:
Hey folks,
Here is what I did to build ntp 4.2.2. Let me know what you think.
I believe the patch could be a little bit smaller.
+ifeq ($(DEB_HOST_ARCH_OS),hurd)
+ ./configure CFLAGS='$(CFLAGS)' \
+ --prefix=/usr \
+
On Mon, 9 Apr 2007, Roger Leigh wrote:
2. Security (and Extensibility)
---
[remove sudo support for security, and use schroot to manage chroots]
[remove building on host]
I'm curious: What will happen on the hurd-i386 architecture? Last time
I checked fakeroot
Hmm, correction. I said:
ncurses_5.4-7_hurd-i386 is in incoming.debian.org. Will be in
unstable in 24 hours.
It seems today's mirror sync has been several hours later than usual,
so it's in unstable now.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Greetings.
After an apt-get upgrade today, my Hurd didn't boot properly anymore,
giving this error message:
panic: kmem_suballoc
and rebooting afterwards.
I was able to fix this by reducing the value of uppermem in menu.lst
(the machine has 1GB of RAM and there was already an uppermem line).
On Tue, 7 Jun 2005, Neal H. Walfield wrote:
At Tue, 7 Jun 2005 20:18:48 +0200 (CEST),
Santiago Vila wrote:
After an apt-get upgrade today, my Hurd didn't boot properly anymore,
giving this error message:
panic: kmem_suballoc
and rebooting afterwards.
I was able to fix
On Mon, 23 May 2005, Michael Banck wrote:
It seems to work on some machines and not on others; for example, it
used to work in my building chroot and in the main root on my notebook,
but nowhere else.
I think it depends on the installed packages, more than the machine.
On the kfreebsd-i386
On Sat, 14 May 2005, Guillem Jover wrote:
Hi Santiago,
Can you reproduce #35970 with the latest gnumach packages?
I don't know, and it is going to be quite difficult for me to check, because
the computer is currently running woody as a server for a lot of people...
--
To UNSUBSCRIBE,
On Fri, 13 May 2005, Jojumon Kavalan wrote:
Have not got a solution for this problem (getting segmentation fault
while running emacs from console itself). No help?
Try running an old version of emacs from snapshot.debian.net.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Wed, 4 May 2005, Michael Banck wrote:
On Mon, May 02, 2005 at 06:09:04PM +0200, Matthias Klose wrote:
Anyway, back to the gcc-3.4 build log:
./xgcc -B./ -B/usr/i586-gnu/bin/ -isystem /usr/i586-gnu/include
-isystem /usr/i586-gnu/sys-include
Hello.
While compiling stuff I noticed that there are a lot of packages
(at least 72 by my count) which fail because of X related linking
errors. A simple example is the xwatch package. This is the error:
[...]
cc -o xwatch xwatch.o usage.o ui.o parsegag.o xmalloc.o xrealloc.o xstrdup.o
On Mon, 11 Apr 2005, Michael Banck wrote:
What I am doing is hacking sbuild to add an
LD_LIBRARY_PATH=/usr/X11R6/lib before the dpkg-buildpackage call.
Ah, that's it! I'll use this then:
diff -ru sbuild-0.35.orig/sbuild sbuild-0.35/sbuild
--- sbuild-0.35.orig/sbuild 2005-03-31
On Wed, 30 Mar 2005, Stou Sandalski wrote:
I just installed the hurd, setup networking (i can ping the box from
other machines), but when i try ping or SSH [EMAIL PROTECTED] it produces
only output of KILLED, and dies.
Also sshd starts up, but everytime i try to ssh into it, it dies, sshd
On Fri, 11 Jun 2004, Carson Chittom wrote:
Guillem Jover said:
That's caused by start-stop-daemon, just wait until dpkg 1.10.22 is
built for hurd-i386.
Sorry to keep coming back to this, but just for my curiousity, is there an
estimated time frame on when this will get built? It's been
On Wed, 9 Jun 2004, Alfred M. Szmidt wrote:
Currently libc0.1 is the official glibc version for the hurd in the
main archive.
I suggest that you do your research a bit better; or maybe the Debian
GNU/*BSD people should make it clearer, the naming of the package
isn't exactly
Jordi Mallach wrote:
Apparently Gürkan's box doesn't have a fixed dpkg-shlibdeps, so the
packages are not being built as they should. Do you have a current
version somewhere?
This is what I use currently.
[ Note that I have put dpkg-dev on hold since I applied the patch ]
#! /usr/bin/perl
#
On Wed, 7 Jan 2004, Michael Banck wrote:
On Wed, Jan 07, 2004 at 06:58:07PM +0100, Roland Stigge wrote:
What do you mean with that? It works, but it doesn't work? ;)
Well, it works, just not out-of-the-box ;)
Take a close look at any package's metadata before you upload anything.
Or even
On Fri, 21 Nov 2003, Robert Millan wrote:
On Thu, Nov 20, 2003 at 12:55:02PM +0100, Santiago Vila wrote:
I could try to build a hacked perl and upload it for ftp.gnuab.org as
unreleased, if that's better than nothing, but then packages which
build-depend on perl would have to be uploaded
On Fri, 21 Nov 2003, Philip Charles wrote:
Any chance of getting perl_5.8.2? perl depends on perl-modules and the
current perl-modules depends on perl_5.8.2, the current perl version is
5.6.1
See my message several weeks ago: FTBFS: perl and especially the
comments by Jeff Bailey.
Even if
On Thu, 20 Nov 2003, Robert Millan wrote:
On Wed, Nov 19, 2003 at 11:56:06PM +0100, Santiago Vila wrote:
It's Debian who decided (implicitly, by not special-casing the Hurd) that
the Debian python package (for which I asked for help to compile) should be
compiled with threads support
On Thu, 20 Nov 2003, Steve King wrote:
Sorry in advance for the troll,
I am trying to get to grips with the hurd. It seems to me like it
has gone backwards since I last dipped my toe in a couple of years
ago. Have I just got the wrong set up?
I installed using crosshurd, so it should be
On Fri, 21 Nov 2003, Philip Charles wrote:
On Thu, 20 Nov 2003, Santiago Vila wrote:
I could try to build a hacked perl and upload it for ftp.gnuab.org as
unreleased, if that's better than nothing, but then packages which
build-depend on perl would have to be uploaded there as well
On Wed, 19 Nov 2003, Robert Millan wrote:
On Mon, Nov 17, 2003 at 02:10:07PM +0100, Alfred M. Szmidt wrote:
[Moving this to bug-hurd since this has nothing todo with Debian]
Ok but don't drop the CC, it's still a porting issue Debian is interested in.
Indeed.
It's Debian who decided
On Sun, 9 Nov 2003, Jeff Bailey wrote:
On Sun, Nov 09, 2003 at 03:49:20PM +0100, Santiago Vila wrote:
Update: This does no longer happen with the new perl_5.8.2-1, but now
there are problems with threads, so I'm considering to ask the perl
maintainer to disable threads temporarily for GNU
On Sun, 9 Nov 2003, Jeff Bailey wrote:
On Sun, Nov 09, 2003 at 04:42:30PM +0100, Santiago Vila wrote:
Still, there are 19 tests which fail even when threads are disabled.
These are the build log and the patch I used to disable threads:
The only ones I'd take any time exploring
On Sun, 9 Nov 2003, Jeff Bailey wrote:
I'm hoping that glibc 2.3.2.ds1-10 will be suitable for hurd-i386 again,
which includes a CVS update.
Do I need a cvs-hurd or a cvs-gnumach to compile it?
This is what I get:
make[3]: Entering directory
On Sun, 2 Nov 2003, Neal H. Walfield wrote:
At Sun, 2 Nov 2003 19:53:31 +0100 (CET),
Santiago Vila wrote:
And this is what happens when compiling python2.3:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing
-DWITH_APPINIT=1 -DWITH_BLT=1 -I/usr/include/tcl8.4 -I
Hi.
This is what happens when one tries to compile perl_5.8.1-4 currently
in unstable:
[...]
Now you must run 'make'.
If you compile perl5 on a different machine or from a different object
directory, copy the Policy.sh file from this object directory to the
new one before you run Configure --
And this is what happens when compiling python2.3:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing
-DWITH_APPINIT=1 -DWITH_BLT=1 -I/usr/include/tcl8.4 -I/usr/X11R6/include -I.
-I/build/buildd/python2.3-2.3.2/./Include
-I/build/buildd/python2.3-2.3.2/Include
On Tue, 21 Oct 2003, Robert Millan wrote:
On Mon, Oct 20, 2003 at 03:53:10PM +0200, Santiago Vila wrote:
James A Morrison wrote:
No, fix sub rewrite_gnu to something like (.*linux|.*gnu).
That's it! I've tested that and it works, so I will ask dpkg
maintainers to do
James A Morrison wrote:
The following patch to dpkg-architecture seems to remove the warning:
--- /usr/bin/dpkg-architecture 2003-09-20 03:06:39.0 +0200
+++ dpkg-architecture 2003-10-19 21:59:16.0 +0200
@@ -61,7 +61,7 @@
'sh3eb',
Hello.
Robert has updated both gcc-defaults and the gcc compilers, which means
gcc-3.3 is now the default compiler if you use gcc and we are now mostly
in sync with the Linux-based architectures.
Before I update the cheap gcc-i386-gnu cross-compiler acccordingly:
Are the gnumach and hurd
On Fri, 10 Oct 2003, Robert Millan wrote:
In order to ensure the Hurd is properly maintained within Debian,
I'm going to NMU the Debian Hurd package. I intend to do the
following:
- CVS update.
- change Maintainer to debian-hurd@lists.debian.org.
- add myself to Uploaders.
- re-write
jls wrote:
I have installed a basic Hurd system and wanted to fetch files via net using
apt. An error popped up wich I boiled down to an unmet dependency
apt-get upgrade debianutils
debianutils: PreDepends coreutils (=4.5.8-1) but 4.5.3-1 is installed.
trying
apt-get upgrade coreutils
Hello.
I've found two problems while using cross-install:
* There is no ftp.de.debian.org/pub/debian anymore, the current location
is now just ftp.de.debian.org/debian. Fortunately, this is very easy to fix.
* The code for getting packages from a hierarchical repository worked
very well when it
On Sat, 27 Apr 2002, Adam Lazur wrote:
Marcus Brinkmann ([EMAIL PROTECTED]) said:
Some important packages are still not in the archives:
* screen (for virtual terminals)
Will be there in 6:30, suffered from the gid bug.
Hmm, which gid bug?
The one that makes some files or
Hong Feng wrote:
can anyone offer me a list of Debian packages which
have been ported to Hurd? I might publish the list
in issue04 of FSM.
Try this: (sorry for the long line)
wget -q -O -
ftp://ftp.debian.org/debian/dists/unstable/main/binary-hurd-i386/Packages.gz |
zcat | awk
Sebastien Geffroy wrote:
I've build a debian package for vim6.0, and i plan to build and maintain
others debian package for Debian GNU/hurd.
Packages do not have maintainers on a per-architecture basis.
The person who maintain the source package is what we call the maintainer.
Who i have to
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 elements?
The idea is that not symlinking /usr
On Sat, 19 May 2001, Marco Parrone wrote:
i'm a new hurd user and i want to ask some questions :
exist gcc for hurd ?
if yes where is it?
In the gcc package, of course.
if no i've a problem:
i've installed the linux's package gcc-i386-gnu, that is a cross-compiler
for the hurd, but if i
Naheed Vora wrote:
I tried to cross compile mach using gcc-i386-gnu (1.7-4), but there
were some broken links.
[...]
Shouldn't this thing be done by the gcc-i386-gnu package or else it
should provide all those files and install in the corresponding
directory ???
You are using
Jeff Bailey wrote:
What would it take for hurd-i386 to participate in the woody release?
At least: Having a `testing' distribution, like the released architectures.
Also, every required dummy package from alpha.gnu.org should be moved to
ftp.debian.org, or (alternatively) the problems they
On Mon, 16 Apr 2001, Jeff Bailey wrote:
Well, if I meet my goal of building all packages in a timely manner
within a month, how would I get us into testing?
Someone should convince AJ to make a testing distribution for all
unreleased architectures.
A testing distribution will always be useful
Do you have a good suggestion for what to sbstitute for the : ?
It must be something that can never be a different valid version number in
Debian and works with make and at other places without special quoting.
Perhaps colon: [...]/package/gawk/version/1colon3.0.6-1
Packages using epochs will
Jeff Bailey wrote:
I would like to see testing, too - but one of the main reasons there have
been broken packages in unstable is that noone was building them.
Exactly my point. Even if unstable were broken, we would have an
usable distribution in testing. The recent problem with gcc and
friends
On Tue, 27 Mar 2001, Philip Charles wrote:
Comments, suggestions, discussion, flames?
Wish: Someone please implement the testing distribution for the
hurd-i386 architecture, so that packages for CDs are taken from
testing, not unstable. This would automatically solve some problems we
have had
Any more suggestions?
Compare the config.log, config.status and the build log between hurd and
linux. Wathc out for any suspicious differences. Grep for architecture
specific stuff in configure.in of recode.
Everything seems to be identical. I think there must be something wrong
with the
Is this a bug in libtool, a bug in recode, a bug in lintian, or am I
doing something wrong with the packaging?
What version of libtool is in the package?
[...] Generated automatically by ltconfig (GNU libtool 1.3.4 [...]
I can't say for sure that this is the reason, but there
Hello.
I need help here. When I compile recode-3.6 (not released yet) for
the Hurd, lintian says shlib-with-non-pic-code for librecode0.
This does not happen under Linux.
Is this a bug in libtool, a bug in recode, a bug in lintian, or am I
doing something wrong with the packaging?
I've put the
Marcus Brinkmann wrote:
Santiago Vila wrote:
3.5. Make makedev Arch: any, and modify it so that under hurd-i386 the
package does nothing (i.e. it is really a dummy package). It has an
Installed-Size: of 72Kb. Even if we multiply this by the number of
architectures, I think we can live
On Wed, 28 Feb 2001, Marcus Brinkmann wrote:
3. makedev MUST be something else than binary-all. It should be
binary-all-linux, but that is not implemented in our packaging system. It
should be. This requires some global effort and some lobbying for this
feature. It could list all linu arches
Marcus Brinkmann wrote:
The broader problem is that dpkg doesn't cope with versioned dependencies on
provided packages.
Indeed.
In this particular case, however, I wonder what is the point of making
libstdc++2.10-dev to depend on a specific version of libc6-dev at all,
since it already depends
Vadim Chekan wrote:
I can't install g++ on my Hurd based on D1 dist.
apt-get install g++
g++: depends: libstdc++2.10-dev (=1:2.95.2-10) but it not going to be
installed
apt-get install libstdc++2.10-dev
libstdc++2.10-dev : Depends: libc6-dev (=2.1.95)
apt-get install libc6-dev
Note,
Hello.
A Hurd install yesterday failed because libc6 depends on
libnss-db, which was not on the list of packages to be installed, so
libc6 did not configure, and a lot of packages did not configure either.
Could this package be added to the list in cross-install to match the
current package
On 24 Nov 2000, Robert Bihlmeyer wrote:
* Ignore the warnings about unknown Origin and Bugs fields. These
can be ignored without loss, and if these are the only problems,
installation should not abort.
Tested it yesterday and yes, these are the only problems.
[ I was going to post a
I said, to cross-compile gnumach you need:
gcc-i386-gnu (please take the version from woody).
mig-i386-gnu
some other I do not remember. Last time I tried it worked but this was
a lng time ago...
some other == dpkg-cross
This one is required to make an Architecture: hurd-i386 package
On Thu, 14 Sep 2000, you wrote:
I've seen in some message that gnumach can be compiled under
linux... sure?
Yes.
I've debian woody with 2.2.14 kernel, and gnumach won't compile. It
stops when checking for the host os.
Can it be compiled in some way or I need to do it under hurd as I did
On Wed, 9 Aug 2000, Marcus Brinkmann wrote:
On Tue, Aug 08, 2000 at 01:56:25PM +0200, Juli-Manel Merino Vidal wrote:
I have been looking for where is print a message... I mean the message
that is print before /etc/motd. It is that says:
GNU 0.2 (hurd) (console)
I don't know where
Greetings.
cross-install does not work properly if the locale is different than C,
because it considers every non-english dpkg message as unusual, and
it fails.
Either LANG=C (or LC_ALL=C) is added to cross-install, or else it should
not consider unusual messages as a fatal error.
Note: This is
On Mon, 15 Nov 1999, Marcus Brinkmann wrote:
Package: base-files
Version: N/A
On Sun, Nov 14, 1999 at 03:59:38PM -0500, Thomas Bushnell, BSG wrote:
Marcus Brinkmann [EMAIL PROTECTED] writes:
/proc is not used on the Hurd at all. The existence is an artifact of the
generic debian
[ Sorry for answering so late ].
On Fri, 21 May 1999, Marcus Brinkmann wrote:
On Fri, May 21, 1999 at 02:14:34PM +0200, Santiago Vila wrote:
If you like, you may just take the existing cross mig, change a few bits
of it and call it native. I would maintain it myself but my building
[ reply to debian-hurd ].
On Thu, 20 May 1999, Marcus Brinkmann wrote:
It will be hurd-i386 only. Not that it can't be compiled and used for other
arhces, too, but it will be completely useless to them. We don't want
unnecessary bloat, do we?
There is a cross mig for i386 there, it is in a
On 29 Apr 1999, Gordon Matzigkeit wrote:
eliminate the steps that are irrelevant to the Hurd (choosing charset, ...
Arg! choosing the keyboard layout should not be irrelevant ;-)
Using the Hurd with a non-US keyboard is certainly difficult.
I guess a lot of new volunteers will arrive as soon
Hello.
Since we have not switched to GPG yet, I have compiled PGP for the Hurd.
The packages are currently in the Incoming dir in nonus.debian.org.
I just wanted to warn everybody that while compiling this, the following
message was issued:
Warning: getrusage is not implemented and it will
On Mon, 21 Dec 1998, John Tobey wrote:
Marcus Brinkmann wrote:
I uploaded gnumach 19981118 from contrib and hurd 19981204 today.
Marcus, where can I get it? The only logical places I know about are:
ftp.debian.org:/debian/dists/unstable/contrib/binary-hurd-i386/
No, gnumach and hurd
On 15 Dec 1998, Gordon Matzigkeit wrote:
Hi, all!
I'm pleased to announce the availability of glibc-1.0.106 packages for
Debian GNU/Hurd i386. Unfortunately, I don't have any way to upload
them to master.debian.org (due to administrative problems involving an
out-of-date PGP key and my
On Sun, 6 Dec 1998, M.C. Vernon wrote:
On Fri, 4 Dec 1998, Santiago Vila wrote:
On Fri, 4 Dec 1998, M.C. Vernon wrote:
Please, for cross-compiling, try dpkg-cross_1.3, which now
supports GNU/Hurd (thanks to Roman Hodek).
Would this make the procedure:
dpkg-cross
Hi.
The Debian apache source seems not to be Hurd-friendly yet, so it may need
some tweaking. [ In fact, dpkg itself is not Hurd-friendly ].
Take a look at the debian/rules, it says:
arch=$(shell dpkg --print-architecture)
This is i386 for intel, but should be really hurd-i386.
A common
On Fri, 4 Dec 1998, M.C. Vernon wrote:
Please, for cross-compiling, try dpkg-cross_1.3, which now
supports GNU/Hurd (thanks to Roman Hodek).
Would this make the procedure:
dpkg-cross -a hurd-i386 -B -rfakeroot
or do I need to
PATH=/usr/i386-gnu/bin:$PATH first too?
No, in
On Fri, 4 Dec 1998, M.C. Vernon wrote:
The Debian apache source seems not to be Hurd-friendly yet, so it may need
some tweaking. [ In fact, dpkg itself is not Hurd-friendly ].
Take a look at the debian/rules, it says:
arch=$(shell dpkg --print-architecture)
This is i386 for
On Thu, 12 Nov 1998, M.C. Vernon wrote:
and I get this error:
filesystem type unknown, partition type 0x63
(which IIRC is the hurd type)
Please use an ordinary ext2 filesystem (type 83).
You may format it using mke2fs -o hurd or change the owner afterwards
by using the e2os utility.
--
On Sat, 7 Nov 1998, Marcus Brinkmann wrote:
Good News:
[...]
++
| unpacked |
| The package is unpacked, but not configured. |
On Thu, 5 Nov 1998, Ed Boraas wrote:
In any case, has anyone got make to build? Is there perhaps a binary for
hurd out there somewhere?
make should be available in any of the Debian ftp archives:
(ftp://ftp.debian.org/pub/debian or mirrors)
as
Hi.
I received this from Mark:
The development version of ncurses (see the patches on
ftp://ftp.clark.net/pub/dickey/ncurses/4.2) solve this by using
access() to check if the files are readable by the real user.
This is of course the way to do it, do I'd suggest to take a look at
these
On Mon, 2 Nov 1998, Roland McGrath wrote:
On Mon, 2 Nov 1998, Roland McGrath wrote:
Where does your libc come from?
GNU 0.2 (i.e. 2.0.4).
Hmm. And you are not using symbol versioning or anything funny?
I don't know.
I just try to compile with as little changes as I can from
Hi.
This is a question for the Hurd developers:
I noticed that the libc in GNU 0.2, libc.so.0.2, has 0.2 as version
number. Does this mean that the libc in GNU 0.3 will have 0.3 as version
number? Will this break every executable? Will a simple symlink
libc.so.0.2 - libc.so.0.3 be enough for
On Wed, 7 Oct 1998, Nelanka Perera wrote:
I'm an undergraduate cs student, and would like to know if there is any
way i can help. I know C, C++ and java, but have not worked on large
projects with either of these languages.
Yes, we would like to know how many Debian source packages may be
-genchanges (which is automatically called by dpkg-buildpackage) is:
#!/bin/sh
/usr/bin/dpkg-genchanges -DArchitecture=hurd-i386 -DDistribution=unstable \
-DUrgency=low -DMaintainer=Santiago Vila [EMAIL PROTECTED] $@
This tells dpkg-genchanges to use hurd-i386 for the Architecture
field in the .changes
-BEGIN PGP SIGNED MESSAGE-
Hi.
I have still to talk about shared lib dependencies.
When cross-compiling, there is a little problem with this.
Normally a Debian package has, in the control file, a Depends: line like
this one: Depends: libc6 which tells dpkg that if you install this
84 matches
Mail list logo
