On Thu, 2011-11-10 at 01:00 +0100, Samuel Thibault wrote:
> Most of these are simply due to dbus, actually.
What's wrong with it, the latest version, 1.4.16-1, seems to build OK.
Hi!
On Tue, 2011-11-08 at 00:13:51 +0100, Thomas Schwinge wrote:
> In GNU Mach, we have a version.m4 where these fields are defined one and
> for all. (I argue that a package's version definition does not really
> belong into a generic, otherwise version-agnostic configuration system's
> file.)
Most of these are simply due to dbus, actually.
Samuel
dillo and lynx ar OK, but text-based.
Other ones, see below when trying to start them:
arora:
Failed to load translation: "C"
QSslSocket: cannot resolve SSLv2_client_method
QSslSocket: cannot resolve SSLv2_server_method
Failed to write cookie file: Unknown error (os/kern) 303
Assertion 'pthread_
Ludovic Courtès, le Wed 09 Nov 2011 23:14:57 +0100, a écrit :
> However, I wonder if it would break software “out there”. The Debian
> people probably have some insight on this.
I doubt it. Maybe some hurdextras things.
Samuel
Hi,
Thomas Schwinge skribis:
> Should/could we also get rid of libhurdbugaddr? (Separate patch?) I
> never quite understood its purpose.
Me neither (perhaps memory savings in the old days where 512 KiB of RAM
was about to become insufficient? ;-)), and I think it would make sense
to remove it
Hi Thomas,
Thomas Schwinge skribis:
> In GNU Mach, we have a version.m4 where these fields are defined one and
> for all. (I argue that a package's version definition does not really
> belong into a generic, otherwise version-agnostic configuration system's
> file.) (But on the other hand, *ve
Hi Roland,
Roland McGrath skribis:
> I think what we used to say was that you should try to do debugging with
> sub-hurds where the console port is faked with io ports (I think).
The thing is that I was debugging a system cross-built from scratch, so
sub-hurds were not an option.
> We definite
