Amos Jeffries, le jeu. 05 sept. 2019 17:18:22 +1200, a ecrit:
> On 5/09/19 10:03 am, Samuel Thibault wrote:
> > Just for the note: this is expected. The hurd-doc arch:all currently
> > can't be built on the amd64 buildd, it'd need configure to accept being
> > run on non-Linux.
I meant non-GNU of
On 5/09/19 10:03 am, Samuel Thibault wrote:
> Julian Gilbey, le mer. 04 sept. 2019 22:10:18 +0100, a ecrit:
>> Source package: hurd
>> Version: 1:0.9.git20190331-8
>> One relevant line of the excuse file (including the uploader):
>> Not built on buildd: arch all binaries uploaded by sthibault, a
Julian Gilbey, le mer. 04 sept. 2019 22:10:18 +0100, a ecrit:
> Source package: hurd
> Version: 1:0.9.git20190331-8
> One relevant line of the excuse file (including the uploader):
> Not built on buildd: arch all binaries uploaded by sthibault, a new
> source-only upload is needed to allow migra
Dear GNU Hurd Maintainers,
This is a courtesy message about your package(s) which is/are
stuck in sid, and will not migrate to testing, in case you
are unaware; they are listed below.
The release managers announced on 7th July 2019 in their email
to debian-devel-announce and debian-release
(Mes
Hello,
Just to close this thread:
Justus Winter, le Sun 09 Jun 2013 15:26:22 +0200, a écrit :
> /usr/include/hurd/io.h:422:2: error: unknown type name ‘timespec_t’
This is now fixed by the latest glibc & hurd uploads.
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
wi
On Wed, 2013-06-12 at 15:41 +0200, Thomas Schwinge wrote:
> Hi!
>
> On Mon, 10 Jun 2013 16:28:40 +0200, Richard Braun wrote:
> > On Mon, Jun 10, 2013 at 04:10:57PM +0200, Justus Winter wrote:
> > > Any reason not to serve source packages from debian-ports.org?
> >
> > I'd like to know as well.
>
Hi!
On Mon, 10 Jun 2013 16:28:40 +0200, Richard Braun wrote:
> On Mon, Jun 10, 2013 at 04:10:57PM +0200, Justus Winter wrote:
> > Any reason not to serve source packages from debian-ports.org?
>
> I'd like to know as well.
Additionally to that, I'd also find it useful if the following worked,
w
On Mon, Jun 10, 2013 at 07:30:58PM +0200, Justus Winter wrote:
> Quoting Richard Braun (2013-06-10 16:28:40)
> > On Mon, Jun 10, 2013 at 04:10:57PM +0200, Justus Winter wrote:
> > > Awesome, didn't know this one. Still I was hoping to get a git repo
> > > since that way I could plug it into my pack
Quoting Richard Braun (2013-06-10 16:28:40)
> On Mon, Jun 10, 2013 at 04:10:57PM +0200, Justus Winter wrote:
> > Awesome, didn't know this one. Still I was hoping to get a git repo
> > since that way I could plug it into my package building solution.
>
> There are debian repositories for GNU Mach
Quoting Emilio Pozuelo Monfort (2013-06-10 16:28:06)
> On 10/06/13 16:10, Justus Winter wrote:
> > Awesome, didn't know this one. Still I was hoping to get a git repo
> > since that way I could plug it into my package building solution.
>
> The debian packaging with the upstream sources + patches
On 10/06/13 16:10, Justus Winter wrote:
> Awesome, didn't know this one. Still I was hoping to get a git repo
> since that way I could plug it into my package building solution.
The debian packaging with the upstream sources + patches are in a git repo:
emilio@titan:~$ apt-cache showsrc hurd | gr
On Mon, Jun 10, 2013 at 04:10:57PM +0200, Justus Winter wrote:
> Awesome, didn't know this one. Still I was hoping to get a git repo
> since that way I could plug it into my package building solution.
There are debian repositories for GNU Mach and the Hurd :
git://anonscm.debian.org/pkg-hurd/gnum
Quoting Svante Signell (2013-06-09 20:10:59)
> On Sun, 2013-06-09 at 18:56 +0200, Svante Signell wrote:
> > On Sun, 2013-06-09 at 17:48 +0200, Justus Winter wrote
> ..
> > apt-get source --download-only eglibc=2.13-38
> > dget \
> > ftp://ftp.debian-ports.org/debian/pool-hurd-i386/main/e/eglibc/egl
On Sun, 2013-06-09 at 18:56 +0200, Svante Signell wrote:
> On Sun, 2013-06-09 at 17:48 +0200, Justus Winter wrote
..
> apt-get source --download-only eglibc=2.13-38
> dget \
> ftp://ftp.debian-ports.org/debian/pool-hurd-i386/main/e/eglibc/eglibc_2.13-39+hurd.3.dsc
I forgot
dget \
ftp://ftp.debian-
On Sun, 2013-06-09 at 17:48 +0200, Justus Winter wrote:
> Quoting Richard Braun (2013-06-09 17:14:36)
> > On Sun, Jun 09, 2013 at 03:26:22PM +0200, Justus Winter wrote:
> > > I cannot rebuild the hurd package (both the one from sid & from
> > > alioth). Before digging deeper into this, I just wante
Quoting Richard Braun (2013-06-09 17:14:36)
> On Sun, Jun 09, 2013 at 03:26:22PM +0200, Justus Winter wrote:
> > I cannot rebuild the hurd package (both the one from sid & from
> > alioth). Before digging deeper into this, I just wanted to ask if I'm
> > missing something obvious here:
> >
> > [..
On Sun, Jun 09, 2013 at 03:26:22PM +0200, Justus Winter wrote:
> I cannot rebuild the hurd package (both the one from sid & from
> alioth). Before digging deeper into this, I just wanted to ask if I'm
> missing something obvious here:
>
> [...]
> make -C libshouldbeinlibc all
> make[3]: Entering d
Hi,
I cannot rebuild the hurd package (both the one from sid & from
alioth). Before digging deeper into this, I just wanted to ask if I'm
missing something obvious here:
[...]
make -C libshouldbeinlibc all
make[3]: Entering directory
`/media/scratch/teythoon/packages/hurd-pkg/build/libshouldbein
Hello,
I did a Debian package of XKB for the new Hurd console. Marco has
written this one, i packaged it for Debian users. Feel free to send any
comment about this package ;). I hope it will be useful.
URL : deb ftp://ftp.duckcorp.org/hurdfr/deb ./
++ Arnaud
--
Arnaud Fontaine <[EM
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
Hi list,
I've build a debian package for vim6.0, and i plan to build and maintain
others debian package for Debian GNU/hurd.
Who i have to ask to for put it on the server ?
Regards,
--
Seb -- [EMAIL PROTECTED]
--
Kernel is like sex, it's better when it's free
GNU/Hurd, free the kernel !
Roland McGrath <[EMAIL PROTECTED]> writes:
> > So, for an able person like yourself, I can't think of any real
> > danger in doing a 'make install' over the running Hurd.
>
> Don't forget /libexec/runsystem.
>
> > I've been wondering about this myself. Since the Hurd is in such
> > a changing s
On Thu, Oct 14, 1999 at 03:23:46PM -0400, Daniel Burrows wrote:
>
> Maybe the hurd source package could build -dbg versions of the core
> libraries
> which have the debugging symbols compiled in? Eg, hurd-dbg, lib0.2-dbg, etc.
> I notice that there appears to be a libc6-dbg (and libglib1.2-dbg
On Thu, Oct 14, 1999 at 09:11:51AM -0700, Brent Fulgham was heard to say:
> > It installs executables and libraries with debug information; I
> > consider that an advantage. It also installs profiling libraries
> > which don't exist in the Debian package; those might cause
> So, for an able person like yourself, I can't think of any real
> danger in doing a 'make install' over the running Hurd.
Don't forget /libexec/runsystem.
> I've been wondering about this myself. Since the Hurd is in such
> a changing state, I wonder if there is any advantage is building
> all
nstalling libraries (and even executables) that
are not part of the standard Debian package, the uninstall features
of dselect/apt will not know to remove them. This is most likely
not going to be a big issue for you (if you know how to build
your own programs, you can most likely figure out what belongs
lls executables and libraries with debug information; I
> consider that an advantage. It also installs profiling libraries
> which don't exist in the Debian package; those might cause
> problems later if I install a newer Debian package and they are
> left on the disk. Anything
Is there any danger in overwriting the files of the Debian "hurd"
package by doing "make install" in a Hurd build tree?
It installs executables and libraries with debug information; I
consider that an advantage. It also installs profiling libraries
which don't exist in
On Tue, Aug 31, 1999 at 04:32:49PM +0100, Andrew Stribblehill wrote:
> In the snapshot I took of main/binary-hurd-i386/ yesterday, I find that
> bsdutils is dependant upon sysvinit, although sysvinit doesn't exist. Is the
> bsdutils package as Essential as the description says it is, or can I live
In the snapshot I took of main/binary-hurd-i386/ yesterday, I find that
bsdutils is dependant upon sysvinit, although sysvinit doesn't exist. Is the
bsdutils package as Essential as the description says it is, or can I live
without it? If it's working OK with the Hurd, why should I need sysVinit?
On Thu, May 20, 1999 at 08:36:32AM +0200, Mark Kettenis wrote:
>Date: Wed, 19 May 1999 22:45:44 -0400
>From: Roland McGrath <[EMAIL PROTECTED]>
>
>> This is disturbing:
>>
>> ext2fs: hd0s4: panic: main: device too small for superblock (0 bytes)
>
> Argh. I should have noticed
Date: Wed, 19 May 1999 22:45:44 -0400
From: Roland McGrath <[EMAIL PROTECTED]>
> This is disturbing:
>
> ext2fs: hd0s4: panic: main: device too small for superblock (0 bytes)
Indeed. That suggests that perhaps the store is not accessing the device
properly at all. Can you
> This is disturbing:
>
> ext2fs: hd0s4: panic: main: device too small for superblock (0 bytes)
Indeed. That suggests that perhaps the store is not accessing the device
properly at all. Can you put some printfs in libstore/device.c where it
calls device_get_status to print out the results?
> I
On Wed, May 19, 1999 at 08:13:14PM -0400, Roland McGrath wrote:
> Well, I would like to figure out exactly what your problem really is.
> Earlier today I checked in a couple of changes to ext2fs and libdiskfs
> (appended below) that should give some more details in the error output.
> Please show u
> The reformat didn't help, so I may try that to see if I can come up with
> a good answer.
Well, I would like to figure out exactly what your problem really is.
Earlier today I checked in a couple of changes to ext2fs and libdiskfs
(appended below) that should give some more details in the error
On Wed, May 19, 1999 at 02:54:22PM -0400, Roland McGrath wrote:
> > Is there anything I can do to make it at least work as well as it has
> > been?
>
> Well, you could comment out the size check in ext2fs/ext2fs.c.
> I don't know if that would do what you want or not.
The reformat didn't help,
> Not 100% certain. Also, I think that fdisk is reporting 1k blocks, as I
> know that I have a 2GB 98 Partition, and a 3GB Linux partition.
Hokay.
> I'll try that if the reformat doesn't work. I don't really know enough
> about ext2 partitions to know if I'm doing something bad (My guidebook
On Wed, May 19, 1999 at 02:54:22PM -0400, Roland McGrath wrote:
> > Disk /dev/hda: 255 heads, 63 sectors, 784 cylinders
> > Units = cylinders of 16065 * 512 bytes
> >
> >Device BootStart End Blocks Id System
> > /dev/hda1 1 262 2104483+ b Win95 FAT32
> > /dev
> Disk /dev/hda: 255 heads, 63 sectors, 784 cylinders
> Units = cylinders of 16065 * 512 bytes
>
>Device BootStart End Blocks Id System
> /dev/hda1 1 262 2104483+ b Win95 FAT32
> /dev/hda2 * 263 654 3148740 83 Linux native
> /dev/hda3
On Wed, May 19, 1999 at 02:18:45PM -0400, Roland McGrath wrote:
> > Filesystem 1024-blocks Used Available Capacity Mounted on
> > /dev/hda23044019 2547456 339126 88% /
> > /dev/hda4 878478 567372 265723 68% /gnu
> > /dev/hda12100360 1788
> Filesystem 1024-blocks Used Available Capacity Mounted on
> /dev/hda23044019 2547456 339126 88% /
> /dev/hda4 878478 567372 265723 68% /gnu
> /dev/hda12100360 1788172 312188 85% /mnt/fat32-cdrive
df shows the available space f
On Wed, May 19, 1999 at 02:01:14PM -0400, Roland McGrath wrote:
> > After I updated from hurd_19990425-1.deb to hurd_19990517fixed.deb, I
> > wound up with the following problem immediately after it initialized the
> > swap partition:
> >
> > ext2fs: hd0s4: panic: main: superblock won't fit on t
> After I updated from hurd_19990425-1.deb to hurd_19990517fixed.deb, I
> wound up with the following problem immediately after it initialized the
> swap partition:
>
> ext2fs: hd0s4: panic: main: superblock won't fit on the device!
>
> Reverting to 0425 works fine. I then compiled it myself,
After I updated from hurd_19990425-1.deb to hurd_19990517fixed.deb, I
wound up with the following problem immediately after it initialized the
swap partition:
ext2fs: hd0s4: panic: main: superblock won't fit on the device!
Reverting to 0425 works fine. I then compiled it myself, and had the
s
44 matches
Mail list logo
