Re: Debian GNU/Hurd 2015 released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/29/2015 6:46 PM, Samuel Thibault wrote: Debian GNU/Hurd 2015 released! It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2015. snip Awesome work folks, congrats! Nice to see you all still chugging away and I wish I was around more/still to work with you! - -- Barry deFreese Sometimes helper, sometimes hinderer to: Debian Games, QA, GNU/Hurd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) iEYEARECAAYFAlVCLDsACgkQ5ItltUs5T36FmACg5t25Td7LvtHa9beRA6xbWeP4 r8gAmwU30JiCfaS1WfLzgGCZMqmUJNkg =jp57 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55422c3b.7000...@gmail.com
Re: Weekly report (14th week) - Debian GNU/Hurd Debianish initialization
I third that, nice work! -- Barry deFreese Sometimes helper, sometimes hinderer to: Debian Games, QA, GNU/Hurd On 9/23/2013 8:37 AM, Richard Braun wrote: On Mon, Sep 23, 2013 at 01:38:26PM +0200, 4win...@informatik.uni-hamburg.de wrote: It has been a lot of fun and I will definitively see you around :) Congratulations, well done indeed. -- 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/52403c26.5010...@gmail.com
Re: Hurd and the archive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I have been significantly out of the loop for a while now but what do you base that on? What requirements are we still falling short on? Thanks, Barry deFreese On 5/6/2013 7:08 AM, Neil McGovern wrote: On Sun, May 05, 2013 at 05:07:13PM +0200, Joerg Jaspert wrote: So, release people: How likely is it that Hurd gets added to jessie? Within the next one or two months I mean, not maybe in a years time. :) I don't see it happening, to be honest. Neil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGHsfYACgkQ5ItltUs5T36WwgCguHojqq0bKSU3CPoAbsrviQR7 CgMAn0Ij4Tdkei+BeLn+vzhMARplG474 =fS3d -END PGP SIGNATURE- -- 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/5187b1f7.9060...@verizon.net
Re: Hurd and the archive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fair enough and no offense taken. As I said, I haven't been contributing for quite a while now so they were more questions for myself than anything. Niels actually showed me the graph and it is a bit sadder than I had hoped. :( Though we do have an installer now and they have done some great work over the year. Thanks, Barry On 5/6/2013 12:17 PM, Neil McGovern wrote: On Mon, May 06, 2013 at 05:15:44PM +0100, Neil McGovern wrote: Percentage built, percentage up to date, and (as far as I know) a working port and installer for a modern desktop machine? Um, having read back the above, it may have sounded a bit more curt than I was expecting, apologies! Those are meant to be genuine questions. Blame the release etc... :) Neil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGH6RQACgkQ5ItltUs5T34VoACbBOFdUNXs3p6buSak9bRQ+0dO V7cAoN3eGJOoGa4oocx34jbypQeb0uoe =beuB -END PGP SIGNATURE- -- 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/5187e914.6080...@verizon.net
Re: Hurd and the archive
Well maybe that was a poor choice of words. I don't even quite understand what some of the columns mean, to be honest. But a visceral response to all of the red and yellow blocks was kind of sad knowing how much you all (and myself to a MUCH lesser degree) have put into it over the last couple of years. I guess I just mean that we seem so close... I didn't mean it in any way to be a slight to you all or the GNU/Hurd in general.. Barry On 5/6/2013 4:28 PM, Samuel Thibault wrote: Barry deFreese, le Mon 06 May 2013 13:32:04 -0400, a écrit : Fair enough and no offense taken. As I said, I haven't been contributing for quite a while now so they were more questions for myself than anything. Niels actually showed me the graph and it is a bit sadder than I had hoped. What do you mean? I don't see where how it is sad. Nothing happend during the freeze, sure. That's completely expected. 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/51881678.8000...@verizon.net
Re: Hurd_condition_wait in glibc libpthreads in Debian
Here is an updated patch that builds with Debian. Haven't tested it yet, I am
working on creating a
test environment. I essentially just moved the changes Thomas made into
pt-cond-wait.c in
libpthread in glibc.
Thanks,
Barry
On 7/30/2012 9:45 AM, Barry deFreese wrote:
Hi folks,
OK, I have a patch that adds pthread_hurd_cond_wait into the libpthreads that
Samuel has migrated
into Debian's glibc. It builds but it isn't creating the symbol in
libpthreads.so. What stupid
thing am I missing?
Attached is the patch.
Thanks!
Barry deFreese
diff -pruN libpthread.orig/forward.c libpthread/forward.c
--- a/libpthread.orig/forward.c 2012-07-27 23:19:19.0 +
+++ b/libpthread/forward.c 2012-07-27 23:22:03.0 +
@@ -84,6 +84,8 @@ FORWARD (pthread_cond_init,
FORWARD (pthread_cond_signal, (pthread_cond_t *cond), (cond), 0)
FORWARD (pthread_cond_wait, (pthread_cond_t *cond, pthread_mutex_t *mutex),
(cond, mutex), 0)
+FORWARD (pthread_hurd_cond_wait, (pthread_cond_t *cond, pthread_mutex_t
*mutex),
+(cond, mutex), 0)
FORWARD (pthread_cond_timedwait,
(pthread_cond_t *cond, pthread_mutex_t *mutex,
const struct timespec *abstime), (cond, mutex, abstime), 0)
diff -pruN libpthread.orig/include/pthread/pthread.h
libpthread/include/pthread/pthread.h
--- a/libpthread.orig/include/pthread/pthread.h 2012-07-27 23:19:19.0
+
+++ b/libpthread/include/pthread/pthread.h 2012-07-27 23:19:54.0
+
@@ -421,6 +421,10 @@ extern int pthread_cond_broadcast (pthre
extern int pthread_cond_wait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex);
+/* Same as pthread_cond_wait but cancellable. */
+extern int pthread_hurd_cond_wait (pthread_cond_t *__restrict __cond,
+ pthread_mutex_t *__restrict __mutex);
+
/* Block on condition variable COND. MUTEX should be held by the
calling thread. On success, MUTEX will be held by the calling
thread. If the time specified by ABSTIME passes, ETIMEDOUT is
diff -pruN libpthread.orig/sysdeps/generic/pt-cond-wait.c
libpthread/sysdeps/generic/pt-cond-wait.c
--- a/libpthread.orig/sysdeps/generic/pt-cond-wait.c2012-07-27
23:19:20.0 +
+++ b/libpthread/sysdeps/generic/pt-cond-wait.c 2012-07-27 23:20:48.0
+
@@ -21,6 +21,9 @@
#include pt-internal.h
+#include hurd/signal.h
+#include assert.h
+
/* Implemented in pt-cond-timedwait.c. */
extern int __pthread_cond_timedwait_internal (pthread_cond_t *cond,
pthread_mutex_t *mutex,
@@ -36,4 +39,93 @@ __pthread_cond_wait (pthread_cond_t *con
return __pthread_cond_timedwait_internal (cond, mutex, 0);
}
+/* Just like condition_wait, but cancellable. Returns true if cancelled. */
+int
+__pthread_hurd_cond_wait (pthread_cond_t *c, pthread_mutex_t *m)
+{
+ /* This function will be called by hurd_thread_cancel while we are blocked
+ in the condition_wait. We wake up all threads blocked on C,
+ so our thread will wake up and notice the cancellation flag. */
+ struct __pthread *self = _pthread_self ();
+
+ void cancel_me (void)
+{
+ __pthread_spin_lock (c-__lock);
+
+ /* If self has been dequeued, self-prevp == 0 */
+ if (self-prevp)
+{
+ __pthread_dequeue (self);
+ __pthread_spin_unlock (c-__lock);
+ __pthread_wakeup (self);
+}
+ else
+{
+ /* There is no thread to wakeup */
+ __pthread_spin_unlock (c-__lock);
+}
+}
+
+ struct hurd_sigstate *ss = _hurd_self_sigstate ();
+
+ int cancel;
+
+ assert (ss-intr_port == MACH_PORT_NULL); /* Sanity check for signal bugs. */
+
+
+ /* Atomically enqueue our cproc on the condition variable's queue of
+ waiters, and mark our sigstate to indicate that `cancel_me' must be
+ called to wake us up. We must hold the sigstate lock while acquiring
+ the condition variable's lock and tweaking it, so that
+ hurd_thread_cancel can never suspend us and then deadlock in
+ condition_broadcast waiting for the condition variable's lock. */
+
+ __pthread_spin_lock (ss-lock);
+ __pthread_spin_lock (c-__lock);
+ cancel = ss-cancel;
+ if (cancel)
+/* We were cancelled before doing anything. Don't block at all. */
+ss-cancel = 0;
+ else
+{
+ /* Put us on the queue so that condition_broadcast will know to wake
+ us up. */
+ __pthread_enqueue (c-__queue, self);
+ /* Tell hurd_thread_cancel how to unblock us. */
+ ss-cancel_hook = cancel_me;
+}
+ __pthread_spin_unlock (c-__lock);
+ __pthread_spin_unlock (ss-lock);
+
+ if (cancel)
+{
+ /* Cancelled on entry. Just leave the mutex locked. */
+ m = NULL;
+}
+ else
+{
+ /* Now unlock the mutex and block until woken. */
+ pthread_mutex_unlock (m);
+ __pthread_block (self
Hurd_condition_wait in glibc libpthreads in Debian
Hi folks,
OK, I have a patch that adds pthread_hurd_cond_wait into the libpthreads that
Samuel has migrated
into Debian's glibc. It builds but it isn't creating the symbol in
libpthreads.so. What stupid
thing am I missing?
Attached is the patch.
Thanks!
Barry deFreese
diff -pruN libpthread.orig/forward.c libpthread/forward.c
--- a/libpthread.orig/forward.c 2012-07-27 23:19:19.0 +
+++ b/libpthread/forward.c 2012-07-27 23:22:03.0 +
@@ -84,6 +84,8 @@ FORWARD (pthread_cond_init,
FORWARD (pthread_cond_signal, (pthread_cond_t *cond), (cond), 0)
FORWARD (pthread_cond_wait, (pthread_cond_t *cond, pthread_mutex_t *mutex),
(cond, mutex), 0)
+FORWARD (pthread_hurd_cond_wait, (pthread_cond_t *cond, pthread_mutex_t
*mutex),
+(cond, mutex), 0)
FORWARD (pthread_cond_timedwait,
(pthread_cond_t *cond, pthread_mutex_t *mutex,
const struct timespec *abstime), (cond, mutex, abstime), 0)
diff -pruN libpthread.orig/include/pthread/pthread.h
libpthread/include/pthread/pthread.h
--- a/libpthread.orig/include/pthread/pthread.h 2012-07-27 23:19:19.0
+
+++ b/libpthread/include/pthread/pthread.h 2012-07-27 23:19:54.0
+
@@ -421,6 +421,10 @@ extern int pthread_cond_broadcast (pthre
extern int pthread_cond_wait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex);
+/* Same as pthread_cond_wait but cancellable. */
+extern int pthread_hurd_cond_wait (pthread_cond_t *__restrict __cond,
+ pthread_mutex_t *__restrict __mutex);
+
/* Block on condition variable COND. MUTEX should be held by the
calling thread. On success, MUTEX will be held by the calling
thread. If the time specified by ABSTIME passes, ETIMEDOUT is
diff -pruN libpthread.orig/sysdeps/generic/pt-cond-wait.c
libpthread/sysdeps/generic/pt-cond-wait.c
--- a/libpthread.orig/sysdeps/generic/pt-cond-wait.c2012-07-27
23:19:20.0 +
+++ b/libpthread/sysdeps/generic/pt-cond-wait.c 2012-07-27 23:20:48.0
+
@@ -21,6 +21,9 @@
#include pt-internal.h
+#include hurd/signal.h
+#include assert.h
+
/* Implemented in pt-cond-timedwait.c. */
extern int __pthread_cond_timedwait_internal (pthread_cond_t *cond,
pthread_mutex_t *mutex,
@@ -36,4 +39,93 @@ __pthread_cond_wait (pthread_cond_t *con
return __pthread_cond_timedwait_internal (cond, mutex, 0);
}
+/* Just like condition_wait, but cancellable. Returns true if cancelled. */
+int
+__pthread_hurd_cond_wait (pthread_cond_t *c, pthread_mutex_t *m)
+{
+ /* This function will be called by hurd_thread_cancel while we are blocked
+ in the condition_wait. We wake up all threads blocked on C,
+ so our thread will wake up and notice the cancellation flag. */
+ struct __pthread *self = _pthread_self ();
+
+ void cancel_me (void)
+{
+ __pthread_spin_lock (c-__lock);
+
+ /* If self has been dequeued, self-prevp == 0 */
+ if (self-prevp)
+{
+ __pthread_dequeue (self);
+ __pthread_spin_unlock (c-__lock);
+ __pthread_wakeup (self);
+}
+ else
+{
+ /* There is no thread to wakeup */
+ __pthread_spin_unlock (c-__lock);
+}
+}
+
+ struct hurd_sigstate *ss = _hurd_self_sigstate ();
+
+ int cancel;
+
+ assert (ss-intr_port == MACH_PORT_NULL); /* Sanity check for signal bugs. */
+
+
+ /* Atomically enqueue our cproc on the condition variable's queue of
+ waiters, and mark our sigstate to indicate that `cancel_me' must be
+ called to wake us up. We must hold the sigstate lock while acquiring
+ the condition variable's lock and tweaking it, so that
+ hurd_thread_cancel can never suspend us and then deadlock in
+ condition_broadcast waiting for the condition variable's lock. */
+
+ __pthread_spin_lock (ss-lock);
+ __pthread_spin_lock (c-__lock);
+ cancel = ss-cancel;
+ if (cancel)
+/* We were cancelled before doing anything. Don't block at all. */
+ss-cancel = 0;
+ else
+{
+ /* Put us on the queue so that condition_broadcast will know to wake
+ us up. */
+ __pthread_enqueue (c-__queue, self);
+ /* Tell hurd_thread_cancel how to unblock us. */
+ ss-cancel_hook = cancel_me;
+}
+ __pthread_spin_unlock (c-__lock);
+ __pthread_spin_unlock (ss-lock);
+
+ if (cancel)
+{
+ /* Cancelled on entry. Just leave the mutex locked. */
+ m = NULL;
+}
+ else
+{
+ /* Now unlock the mutex and block until woken. */
+ pthread_mutex_unlock (m);
+ __pthread_block (self);
+}
+
+ __pthread_spin_lock (ss-lock);
+ /* Clear the hook, now that we are done blocking. */
+ ss-cancel_hook = NULL;
+ /* Check the cancellation flag; we might have unblocked due to
+ cancellation rather than a normal condition_signal or
+ condition_broadcast (or we might have just
Re: netdde not detecting cards
On 7/6/2012 12:10 AM, Samuel Thibault wrote: Hello, To people who were having problems of network card detection with netdde, I've found that it was hardcoded that only bus 0 and 2 were probed for. The attached patch should probe for all buses, and probably fix the issue you were having. Check your lspci output, if it looked like 03:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) i.e. first number for the network board is neither 00 nor 02, then it's normal that netdde was not finding your card. You can apply the attached patch to the hurd package, install it, and rebuild netdde, or just wait for the next hurd+netdde upload, or CD image build. Samuel Samuel, This patch is working great on both of my machines now. As a side note, on one of the machines I am successfully using the 3c59x driver. To build it I just added a int nr_irqs = 255; line directly in 3c59x.c. I can try to look into a more appropriate solution if you would like. Thanks for all you do!! Barry deFreese -- 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/4ffadffe.9040...@verizon.net
Re: Cannot get netdde working on any of my machines
On 6/29/2012 12:02 PM, Samuel Thibault wrote: Barry deFreese, le Fri 29 Jun 2012 11:27:06 -0400, a écrit : this morning Svante built scanpci for me and it is picking up the cards so I assume it must be something still in netdde. Indeed, it's good to know that libpciaccess is working fine and the issue is not in there. Note that it's probably not netdde at fault, but the libdde_linux26 from the hurd package. Samuel As usual I wasn't clear enough, yes that is what I meant. I will try to do some debugging when I get back. Thanks again! Barry -- 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/4fedd2fb.2020...@verizon.net
Re: Cannot get netdde working on any of my machines
On 6/26/2012 11:51 PM, Samuel Thibault wrote: Barry deFreese, le Tue 26 Jun 2012 22:01:55 -0400, a écrit : settrans -cap /servers/socket/2 /hurd/pfinet -i /dev/ethX (0,1,2 nothing) -a 192.168.10.xx -g 192.168.10.1 -m 255.255.255.0 Then no matter what device I choose I get: /hurd/pfinet: device_open on /dev/ethX: (os/device) no such device See http://www.debian.org/ports/hurd/hurd-install : use # settrans -fgap /dev/netdde /hurd/netdde To get actually useful information about device detection. Also post lspci and lspci -n. Samuel Samuel, Well since I am unable to mount a CD or floppy I tried installing a GNU/Linux partition and now cannot boot my GNU/Hurd partition to get the output from one of the machines. I did re-install on the other machine to use gnumach drivers for now so I will get the output from netdde as soon as I can. Here is the lspci and lspci -n output though: New clubber: lspci: 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01) 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 01:07.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) lspci -n: 00:00.0 0600: 8086:2560 (rev 01) 00:02.0 0300: 8086:2562 (rev 01) 00:1e.0 0604: 8086:244e (rev 81) 00:1f.0 0601: 8086:24c0 (rev 01) 00:1f.1 0101: 8086:24cb (rev 01) 00:1f.3 0c05: 8086:24c3 (rev 01) 01:07.0 0200: 10b7:9055 (rev 24) New machine: lspci: 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01) 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) 00:1d.0 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.7 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 05:04.0 Ethernet controller: D-Link System Inc DGE-530T Gigabit Ethernet Adapter (rev 11) (rev 11) 05:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VM (LOM) Ethernet Controller (rev 81) lspci -n: 00:00.0 0600: 8086:2560 (rev 01) 00:02.0 0300: 8086:2562 (rev 01) 00:1d.0 0c03: 8086:24c2 (rev 01) 00:1d.1 0c03: 8086:24c4 (rev 01) 00:1d.7 0c03: 8086:24cd (rev 01) 00:1e.0 0604: 8086:244e (rev 81) 00:1f.0 0601: 8086:24c0 (rev 01) 00:1f.1 0101: 8086:24cb (rev 01) 00:1f.3 0c05: 8086:24c3 (rev 01) 00:1f.5 0401: 8086:24c5 (rev 01) 05:04.0 0200: 1186:4b01 (rev 11) 05:08.0 0200: 8086:103b (rev 81) Thanks, Barry -- 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/4fec5796.5000...@verizon.net
Re: Cannot get netdde working on any of my machines
On 6/28/2012 9:41 AM, Samuel Thibault wrote: Barry deFreese, le Thu 28 Jun 2012 09:09:42 -0400, a écrit : 01:07.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) 01:07.0 0200: 10b7:9055 (rev 24) That one is handled by the 3c59x driver, which is currently disabled because it's missing the nr_irqs symbol. Just needs to be fixed. 05:04.0 Ethernet controller: D-Link System Inc DGE-530T Gigabit Ethernet Adapter (rev 11) (rev 11) 05:04.0 0200: 1186:4b01 (rev 11) That one should be recognized by the skge driver, compiled in. Debugging why it's not so would be useful. 05:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VM (LOM) Ethernet Controller (rev 81) 05:08.0 0200: 8086:103b (rev 81) Driver e100, ditto. Samuel Well because I cannot get to the net or mount a CD I can't get the source (that is what I was trying on the machine with the e100 and d-link last night). I did pull the source code on the machine with the 3c905 last night since the gnumach driver works. Now I can dist-upgrade to get netdde (since that will break the networking) but at least I can build the package since I pulled the source first. Thanks, Barry -- 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/4fec67bb.9050...@verizon.net
Re: Cannot get netdde working on any of my machines
On 6/28/2012 9:41 AM, Samuel Thibault wrote: Barry deFreese, le Thu 28 Jun 2012 09:09:42 -0400, a écrit : 01:07.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) 01:07.0 0200: 10b7:9055 (rev 24) That one is handled by the 3c59x driver, which is currently disabled because it's missing the nr_irqs symbol. Just needs to be fixed. 05:04.0 Ethernet controller: D-Link System Inc DGE-530T Gigabit Ethernet Adapter (rev 11) (rev 11) 05:04.0 0200: 1186:4b01 (rev 11) That one should be recognized by the skge driver, compiled in. Debugging why it's not so would be useful. 05:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VM (LOM) Ethernet Controller (rev 81) 05:08.0 0200: 8086:103b (rev 81) Driver e100, ditto. Samuel Don't know if it will help any but here is the output from settrans -fgap /dev/netdde /hurd/netdde on the one with the D-link and e100: Initialized DDELinux 2.6 Initializing skb subsystem Softirq daemon starting Initializing DDE page cache 6Calibrating delay using timer specific routine.. 4521.93 BogoMIPS (lpj=22609692) 6net_namespace: 636 bytes IO: name: 3c509-control, start: 110, len: 1 6atp.c:v1.09=ac 2002/10/01 Donald Becker bec...@scyld.com IO: name: de600, start: 378, len: 3 6eth%d: D-Link DE-600 pocket adapter: not at I/O 0x378. IO: name: depca, start: 300, len: 16 IO: name: depca, start: 200, len: 16 6e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI 6e100: Copyright(c) 1999-2006 Intel Corporation 6Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI 6Copyright (c) 1999-2006 Intel Corporation. 6e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2 6e1000e: Copyright (c) 1999-2008 Intel Corporation. 6Intel(R) Virtual Function Network Driver - version 1.0.0-k0 6Copyright (c) 2009 Intel Corporation. 6Intel(R) PRO/10GbE Network Driver - version 1.0.135-k2-NAPI 6Copyright (c) 1999-2008 Intel Corporation. 6jme: JMicron JMC2XX ethernet driver version 1.0.5 IO: name: lp486e, start: cb0, len: 16 eth%d: i82596 initialization timed out 6NetXen Network Driver version 4.0.50 6ns83820.c: National Semiconductor DP83820 10/100/1000 driver. 6pcnet32.c:v1.35 21.Apr.2008 tsbog...@alpha.franken.de 6sky2 driver version 1.25 6tehuti: Tehuti Networks(R) Network Driver, 7.29.3 6tehuti: Options: hw_csum 6ThunderLAN driver v1.15a 6TLAN: 0 devices installed, PCI: 0 EISA: 0 6VMware vmxnet3 virtual NIC driver - version 1.0.5.0-k-NAPI l4dde26_register_rx_callback: New rx callback @ 0x81c3120. Thanks, Barry -- 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/4fece1a4.1030...@verizon.net
Cannot get netdde working on any of my machines
Hi folks (Samuel mainly I guess?) I am unable to get netdde working on any of the new machines I have set up in the last week or so. I've tried with a 3com 3c905b/c (doesn't seem to be listed specifically in the drivers_list). I have tried with the embedded Intel e100 and I just stuck a d-link in today with the Realtek RTL8129 based chipset in it. I do the following: settrans -fg /dev/eth0 settrans -fg /dev/netdde settrans -fg /servers/socket/2 dpkg-reconfigure hurd Seems to set the appropriate translators on /dev/netdde and /dev/ethX but doesn't do anything for /servers/socket/2. So I try: settrans -cap /servers/socket/2 /hurd/pfinet -i /dev/ethX (0,1,2 nothing) -a 192.168.10.xx -g 192.168.10.1 -m 255.255.255.0 Then no matter what device I choose I get: /hurd/pfinet: device_open on /dev/ethX: (os/device) no such device Am I doing something stupid? Thanks, Barry -- 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/4fea6993.5020...@verizon.net
Re: pong2 - PATH_MAX patch for review
On 6/25/2012 8:39 AM, Samuel Thibault wrote: Barry deFreese, le Tue 19 Jun 2012 23:20:04 -0400, a écrit : +#ifdef __linux__ #include linux/limits.h +#endif Better check that it simply works on Linux with limits.h instead of linux/limits.h Samuel Samuel, Do you mean something like: #ifdef _LIBC_LIMITS_H_ #include limits.h #endif ?? Thanks, Barry -- 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/4fe86a1f.7040...@debian.org
Re: pong2 - PATH_MAX patch for review
On 6/20/2012 8:13 AM, Cyril Roelandt wrote: On 06/20/2012 05:20 AM, Barry deFreese wrote: Hi again, Here is a simple little patch to build pong2 (uses PATH_MAX). Let me know if this looks sane. Why not do this : size = strlen(...) + 1; filename = malloc(size); #ifdef PATH_MAX if (size PATH_MAX) handle_error(); #endif snprintf(filename, size, ...); This avoids duplicating the whole if (writer) ... else ... thing, plus we do not check whether __GLIBC__ is defined. I think it would be more likely to be accepted upstream. Cyril. Cyril, Thanks but what are you doing there if you overrun the size of filename (not that they are handling it now either but PATH_MAX is fairly large). Thanks again, Barry -- 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/4fe1c3fa.2020...@verizon.net
dwarfutils - Patch for review
Hi folks,
Honestly I am not quite sure why this is working on GNU/Linux but dwarfutils
was failing with the
following errors:
g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -I. -I.
-I./../libdwarf
-DCONFPREFIX=/build/buildd-dwarfutils_20120410-1-hurd-i386-zvAcOM/dwarfutils-20120410/debian/dwarfdump2/lib
-D_FORTIFY_SOURCE=2 -c -o print_die.o print_die.cc
print_die.cc:1225:36: error: invalid pure specifier (only '= 0' is allowed)
before '(' token
print_die.cc:1225:40: error: function 'int* __errno_location()' is initialized
like a variable
print_die.cc:1237:17: warning: declaration of 'int* __errno_location()' has
'extern' and is
initialized [enabled by default]
print_die.cc:1237:36: error: invalid pure specifier (only '= 0' is allowed)
before '(' token
print_die.cc:1237:40: error: function 'int* __errno_location()' is initialized
like a variable
make[2]: *** [print_die.o] Error 1
make[1]: *** [override_dh_auto_build] Error 2
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
I just changed that block of code to use a different variable name rather than
errno (see attached
patch). Does this make sense?
Thanks!
Barry
Index: dwarfutils-20120410/dwarfdump2/print_die.cc
===
--- dwarfutils-20120410.orig/dwarfdump2/print_die.cc2012-06-19
16:52:34.0 +
+++ dwarfutils-20120410/dwarfdump2/print_die.cc 2012-06-19 16:53:19.0
+
@@ -1222,8 +1222,8 @@
/* Get the global offset for reference */
res = dwarf_global_formref(attrib, ref_off, err);
if (res != DW_DLV_OK) {
-int errno = dwarf_errno(err);
-if (errno == DW_DLE_REF_SIG8_NOT_HANDLED ) {
+int ferrno = dwarf_errno(err);
+if (ferrno == DW_DLE_REF_SIG8_NOT_HANDLED ) {
// No need to stop, ref_sig8 refers out of
// the current section.
break;
@@ -1234,8 +1234,8 @@
}
res = dwarf_dieoffset(die, die_off, err);
if (res != DW_DLV_OK) {
-int errno = dwarf_errno(err);
-if (errno == DW_DLE_REF_SIG8_NOT_HANDLED ) {
+int ferrno = dwarf_errno(err);
+if (ferrno == DW_DLE_REF_SIG8_NOT_HANDLED ) {
// No need to stop, ref_sig8 refers out of
// the current section.
break;
Re: dwarfutils - Patch for review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/19/2012 1:45 PM, Pino Toscano wrote: Hi, Alle martedì 19 giugno 2012, Barry deFreese ha scritto: Honestly I am not quite sure why this is working on GNU/Linux but dwarfutils was failing with the following errors: [...] It does not matter, errno is a reserved identifier, so shadowing it might not be the best idea. I just changed that block of code to use a different variable name rather than errno (see attached patch). Does this make sense? Yes, it does. (I usually put errnum, but it's mostly style.) Thanks Pino! Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gwIYACgkQ5ItltUs5T36NLwCfTJ6LxCByGLXW3iVRC/SEYQ+O pxMAoPh6QYFZ0DL8ErMY6mo4IDuhMtZ8 =s/mu -END PGP SIGNATURE- -- 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/4fe0c086.4060...@verizon.net
pong2 - PATH_MAX patch for review
Hi again,
Here is a simple little patch to build pong2 (uses PATH_MAX).
Let me know if this looks sane.
Thanks!
Barry deFreese
--- pong2-0.1.3.orig/src/grapple/socket.h
+++ pong2-0.1.3/src/grapple/socket.h
@@ -27,7 +27,9 @@
#include sys/time.h
#include netinet/in.h
+#ifdef __linux__
#include linux/limits.h
+#endif
#ifndef HOST_NAME_MAX
# define HOST_NAME_MAX 255
only in patch2:
unchanged:
--- pong2-0.1.3.orig/src/grapple/socket.c
+++ pong2-0.1.3/src/grapple/socket.c
@@ -35,7 +35,9 @@
#include sys/ioctl.h
#include errno.h
#include time.h
+#ifdef __linux__
#include linux/limits.h
+#endif
#ifdef SOCK_SSL
#include openssl/ssl.h
#endif
@@ -344,6 +346,16 @@
{
FILE *fp;
int loopa;
+
+#ifdef __GLIBC__
+ char *filename;
+
+ //Set the filename
+ if (writer)
+asprintf(filename,/tmp/socket_%d.write,sock-fd);
+ else
+asprintf(filename,/tmp/socket_%d.read,sock-fd);
+#else
char filename[PATH_MAX];
//Set the filename
@@ -352,6 +364,8 @@
else
sprintf(filename,/tmp/socket_%d.read,sock-fd);
+#endif //GLIBC
+
//Open the file for appending
fp=fopen(filename,a);
if (fp)
@@ -371,6 +385,11 @@
//Close the file, we're done
fclose(fp);
+
+#ifdef __GLIBC__
+ free(filename);
+#endif
+
}
return;
}
gearmand - PATH_MAX patch review
Howdy, Attached is a patch for gearmand to fix an FTBFS on PATH_MAX. Could you please take a look and if it looks sane I will submit to Debian. Thanks! Barry Index: gearmand-0.32/libtest/server.cc === --- gearmand-0.32.orig/libtest/server.cc2012-06-18 01:26:30.0 + +++ gearmand-0.32/libtest/server.cc 2012-06-18 01:37:08.0 + @@ -204,13 +204,20 @@ continue; } +#ifdef _GNU_SOURCE +char *getcwd_buf= get_current_dir_name(); +#else char buf[PATH_MAX]; char *getcwd_buf= getcwd(buf, sizeof(buf)); +#endif throw libtest::fatal(LIBYATL_DEFAULT_PARAM, Unable to open pidfile in %s for: %s stderr:%s, getcwd_buf ? getcwd_buf : , _running.c_str(), _app.stderr_c_str()); +#ifdef _GNU_SOURCE +free(getcwd_buf); +#endif } } }
python-psutil patch failing test suite
Hi again,
Here is another patch that I could use some help with. I was essentially
trying to cheat by just
using the posix files. It does allow the package to build, however it fails
the test suites because
_EXTRA_ALL isn't defined.
I was going to copy the _pslinux and _psutil_linux files to something like
_psgnu and _psutil_gnu.
However, the linux code relies a lot on /proc and uses /proc/cpuinfo which we
don't have.
The other option would be to try to use the _psbsd and _psutil_bsd files.
I am open to suggestions or help..
Thanks!
Barry deFreese
Index: python-psutil-0.4.1/setup.py
===
--- python-psutil-0.4.1.orig/setup.py 2012-06-10 10:24:51.0 +
+++ python-psutil-0.4.1/setup.py2012-06-10 10:35:34.0 +
@@ -72,6 +72,12 @@
sources=['psutil/_psutil_linux.c'],
),
posix_extension]
+# GNU
+elif sys.platform.lower().startswith(gnu):
+extensions = [Extension('_psutil_posix',
+sources=['psutil/_psutil_posix.c'],
+),
+ posix_extension]
else:
raise NotImplementedError('platform %s is not supported' % sys.platform)
Index: python-psutil-0.4.1/psutil/__init__.py
===
--- python-psutil-0.4.1.orig/psutil/__init__.py 2012-06-10 10:24:51.0
+
+++ python-psutil-0.4.1/psutil/__init__.py 2012-06-10 10:36:46.0
+
@@ -79,6 +79,9 @@
elif sys.platform.lower().startswith(freebsd):
import psutil._psbsd as _psplatform
+elif sys.platform.lower().startswith(gnu):
+import psutil._psposix as _psplatform
+
else:
raise NotImplementedError('platform %s is not supported' % sys.platform)
Partial patch for aster
Hi folks,
Here is another partial patch. It allows building of most of aster but it took
two days to build.
If someone gets bored, have fun with it. :)
Thanks,
Barry
Index: aster-10.6.0-1/setup.py
===
--- aster-10.6.0-1.orig/setup.py2012-06-11 21:46:45.0 +
+++ aster-10.6.0-1/setup.py 2012-06-11 22:06:53.0 +
@@ -344,6 +344,8 @@
#cfg['IFDEF']='IRIX64'
elif sys.platform[:4] == 'irix':
cfg['IFDEF'] = 'IRIX'
+ elif sys.platform[:3] == 'gnu':
+ cfg['IFDEF'] = 'GNU'
else:
raise SetupError(_(Unsupported platform : sys.platform=%s,
os.name=%s) % \
(sys.platform, os.name))
@@ -506,7 +508,7 @@
# 1.4.1g. - check for system dependent libraries (and only used by
Code_Aster)
cfg['SYSLIB'] = cfg.get('SYSLIB', '')
aster_sys_lib = []
- if cfg['IFDEF'] in ('LINUX', 'P_LINUX', 'LINUX64'):
+ if cfg['IFDEF'] in ('LINUX', 'P_LINUX', 'LINUX64', 'GNU'):
cfg['SYSLIB'] += ' -Wl,--allow-multiple-definition -Wl,--export-dynamic'
aster_sys_lib.extend(['dl', 'util', 'm'])
elif cfg['IFDEF'] == 'TRU64':
tslib on GNU/Hurd
Hi folks,
Another partial patch over my head. I got further by adding --enable-input=no
to configure in
debian/rules and the following patch.
However, now it is including the following:
linux/vt.h
linux/kd.h
linux/fb.h
So I am thinking tslib should be not-for-us?
Thanks,
Barry deFreese
Index: tslib-1.0/tests/fbutils.h
===
--- tslib-1.0.orig/tests/fbutils.h 2012-06-13 23:38:27.0 +
+++ tslib-1.0/tests/fbutils.h 2012-06-13 23:57:45.0 +
@@ -13,7 +13,7 @@
#ifndef _FBUTILS_H
#define _FBUTILS_H
-#include asm/types.h
+#include stdint.h
/* This constant, being ORed with the color index tells the library
* to draw in exclusive-or mode (that is, drawing the same second time
@@ -21,7 +21,7 @@
*/
#define XORMODE0x8000
-extern __u32 xres, yres;
+extern uint32_t xres, yres;
int open_framebuffer(void);
void close_framebuffer(void);
Index: tslib-1.0/tests/fbutils.c
===
--- tslib-1.0.orig/tests/fbutils.c 2012-06-13 23:58:21.0 +
+++ tslib-1.0/tests/fbutils.c 2012-06-13 23:59:55.0 +
@@ -42,7 +42,7 @@
static int fb_fd=0;
static int bytes_per_pixel;
static unsigned colormap [256];
-__u32 xres, yres;
+uint32_t xres, yres;
static char *defaultfbdevice = /dev/fb0;
static char *defaultconsoledevice = /dev/tty;
@@ -136,7 +136,7 @@
memset(fbuffer,0,fix.smem_len);
bytes_per_pixel = (var.bits_per_pixel + 7) / 8;
- line_addr = malloc (sizeof (__u32) * var.yres_virtual);
+ line_addr = malloc (sizeof (uint32_t) * var.yres_virtual);
addr = 0;
for (y = 0; y var.yres_virtual; y++, addr += fix.line_length)
line_addr [y] = fbuffer + addr;
@@ -288,8 +288,8 @@
unsigned xormode;
union multiptr loc;
- if ((x 0) || ((__u32)x = var.xres_virtual) ||
- (y 0) || ((__u32)y = var.yres_virtual))
+ if ((x 0) || ((uint32_t)x = var.xres_virtual) ||
+ (y 0) || ((uint32_t)y = var.yres_virtual))
return;
xormode = colidx XORMODE;
@@ -360,10 +360,10 @@
/* Clipping and sanity checking */
if (x1 x2) { tmp = x1; x1 = x2; x2 = tmp; }
if (y1 y2) { tmp = y1; y1 = y2; y2 = tmp; }
- if (x1 0) x1 = 0; if ((__u32)x1 = xres) x1 = xres - 1;
- if (x2 0) x2 = 0; if ((__u32)x2 = xres) x2 = xres - 1;
- if (y1 0) y1 = 0; if ((__u32)y1 = yres) y1 = yres - 1;
- if (y2 0) y2 = 0; if ((__u32)y2 = yres) y2 = yres - 1;
+ if (x1 0) x1 = 0; if ((uint32_t)x1 = xres) x1 = xres - 1;
+ if (x2 0) x2 = 0; if ((uint32_t)x2 = xres) x2 = xres - 1;
+ if (y1 0) y1 = 0; if ((uint32_t)y1 = yres) y1 = yres - 1;
+ if (y2 0) y2 = 0; if ((uint32_t)y2 = yres) y2 = yres - 1;
if ((x1 x2) || (y1 y2))
return;
Re: New CD snapshot
On 6/10/2012 9:23 PM, Samuel Thibault wrote: Hello, Now that the archive rebuild is almost complete, I have rebuilt installation CDs. A notable change is that they include the netdde drivers, and can thus work on a wide range of network boards! Samuel Yeah! Nice work Samuel! Barry -- 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/4fd55769.5080...@verizon.net
Patch started for ST
Hi folks, I started working on st which doesn't recognize GNU OS. Somehow I have managed to jack up the md.h file. If some brave soul feels like checking this out, I would appreciate it. Thanks, Barry deFreese diff -Nur -x '*.orig' -x '*~' st-1.9//Makefile st-1.9.new//Makefile --- st-1.9//Makefile2012-06-06 03:49:34.0 + +++ st-1.9.new//Makefile2012-06-06 03:52:24.0 + @@ -96,6 +96,7 @@ openbsd-debug openbsd-optimized \ osf1-debug osf1-optimized \ solaris-debug solaris-optimized \ + gnu-debug gnu-optimized \ solaris-64-debug solaris-64-optimized # @@ -190,6 +191,16 @@ endif endif +ifeq ($(OS), GNU) +EXTRA_OBJS = $(TARGETDIR)/md.o +SFLAGS = -fPIC +LDFLAGS = -shared -soname=$(SONAME) -lc +OTHER_FLAGS = -Wall +ifeq ($(shell test -f /usr/include/sys/epoll.h echo yes), yes) +DEFINES += -DMD_HAVE_EPOLL +endif +endif + ifeq ($(OS), NETBSD) SFLAGS = -fPIC LDFLAGS = -shared -soname=$(SONAME) -lc @@ -465,5 +476,10 @@ solaris-64-optimized: $(MAKE) OS=SOLARIS_64 BUILD=OPT +gnu-debug: + $(MAKE) OS=GNU BUILD=DBG +gnu-optimized: + $(MAKE) OS=GNU BUILD=OPT + ## diff -Nur -x '*.orig' -x '*~' st-1.9//md.h st-1.9.new//md.h --- st-1.9//md.h2012-06-06 03:52:06.0 + +++ st-1.9.new//md.h2012-06-06 03:56:15.0 + @@ -609,6 +609,47 @@ #define MD_GET_UTIME() \ return (gethrtime() / 1000) +#elif defined (GNU) + +/* + * These are properties of the GNU kernel and are the same on every + * flavor and architecture. + */ +#define MD_USE_BSD_ANON_MMAP +#define MD_ACCEPT_NB_NOT_INHERITED +#define MD_ALWAYS_UNSERIALIZED_ACCEPT +/* + * GNU syste is Posix.1g compliant. + */ +#define MD_HAVE_SOCKLEN_T + +/* + * All architectures have the gettimeofday + * function but if you know of a faster way, use it. + */ +#define MD_GET_UTIME()\ + struct timeval tv; \ + (void) gettimeofday(tv, NULL); \ + return (tv.tv_sec * 100LL + tv.tv_usec) + +#if defined(__i386__) +#define MD_STACK_GROWS_DOWN +#define MD_USE_BUILTIN_SETJMP + +#if defined(__GLIBC__) __GLIBC__ = 2 +#ifndef JB_SP +#define JB_SP 4 +#endif +#define MD_GET_SP(_t) (_t)-context[0].__jmpbuf[JB_SP] +#else +/* not an error but certainly cause for caution */ +#error Untested use of old glibc on i386 +#define MD_GET_SP(_t) (_t)-context[0].__jmpbuf[0].__sp +#endif +#else +#error Unknown CPU architecture +#endif + #else #error Unknown OS #endif /* OS */ diff -Nur -x '*.orig' -x '*~' st-1.9//osguess.sh st-1.9.new//osguess.sh --- st-1.9//osguess.sh 2012-06-06 03:52:05.0 + +++ st-1.9.new//osguess.sh 2012-06-06 03:52:24.0 + @@ -37,6 +37,7 @@ *-dec-osf* ) OS=OSF1 ;; *-solaris2* ) OS=SOLARIS;; *-darwin* ) OS=DARWIN ;; + *-gnu* ) OS=GNU;; * ) OS= echo Sorry, unsupported OS exit 1;;
Re: Patch started for ST
On 6/6/2012 5:10 PM, Samuel Thibault wrote: Barry deFreese, le Wed 06 Jun 2012 11:52:44 -0400, a écrit : Somehow I have managed to jack up the md.h file. If some brave soul feels like checking this out, I would appreciate it. It looks just right. Samuel I have an #endif or something out of place and I cannot find it. :( Barry -- 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/4fcfd967.2040...@verizon.net
Re: Build of ptop keeps failing
Bas,
Here is an untested patch but should at least give you an idea of what you need
to do...
Barry deFreese
On 6/3/2012 6:19 AM, Bas van den Dikkenberg wrote:
Can you help me with that don´t know how to do that
-Oorspronkelijk bericht-
Van: Samuel Thibault [mailto:sthiba...@debian.org]
Verzonden: zondag 3 juni 2012 11:49
Aan: Bas van den Dikkenberg
CC: debian-hurd@lists.debian.org
Onderwerp: Re: Build of ptop keeps failing
Bas van den Dikkenberg, le Sun 03 Jun 2012 07:58:56 +, a écrit :
The build of ptop keeps failing on hurd can some help me?
See also bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675757
whose important line is:
configure: error: System type gnu unrecognized
you need to fix configure.ac to define the gnu system, and then create a
machine/m_gnu.c file, most probably by copying the existing machine/m_linux.c
and dropping what doesn't work.
Samuel
Index: ptop-3.6.2/configure
===
--- ptop-3.6.2.orig/configure 2012-06-03 08:55:31.0 +
+++ ptop-3.6.2/configure2012-06-03 08:55:54.0 +
@@ -6633,6 +6633,7 @@
sysv4*) MODULE=svr4;;
sysv5*) MODULE=svr5;;
darwin*)MODULE=macosx;;
+ gnu*) MODULE=gnu;;
*) echo none
echo Configure doesn't recognize this system and doesn't know
echo what module to assign to it. Help the cause and run the
Index: ptop-3.6.2/machine/m_gnu.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ ptop-3.6.2/machine/m_gnu.c 2012-06-03 08:55:55.0 +
@@ -0,0 +1,1132 @@
+/*
+ * pg_top - a top PostgreSQL users display for Unix
+ *
+ * SYNOPSIS: Linux 1.2.x, 1.3.x, 2.x, using the /proc filesystem
+ *
+ * DESCRIPTION:
+ * This is the machine-dependent module for Linux 1.2.x, 1.3.x or 2.x.
+ *
+ * LIBS:
+ *
+ * CFLAGS: -DHAVE_GETOPT -DHAVE_STRERROR -DORDER
+ *
+ * TERMCAP: -lcurses
+ *
+ * AUTHOR: Richard Henderson r...@tamu.edu
+ * Order support added by Alexey Klimkin k...@klon.tme.mcst.ru
+ * Ported to 2.4 by William LeFebvre
+ */
+
+#include config.h
+
+#include sys/types.h
+#include time.h
+#include stdio.h
+#include fcntl.h
+#include unistd.h
+#include stdlib.h
+#include errno.h
+#include dirent.h
+#include string.h
+#include math.h
+#include ctype.h
+#include sys/time.h
+#include sys/stat.h
+#include sys/vfs.h
+
+#include sys/param.h /* for HZ */
+
+#if 0
+#include linux/proc_fs.h /* for PROC_SUPER_MAGIC */
+#else
+#define PROC_SUPER_MAGIC 0x9fa0
+#endif
+
+#include machine.h
+#include utils.h
+
+#define PROCFS /proc
+extern char *myname;
+
+/*=PROCESS INFORMATION==*/
+
+struct top_proc
+{
+ pid_t pid;
+ uid_t uid;
+ char *name;
+ int pri,
+ nice;
+ unsigned long size,
+ rss;/* in k */
+ int state;
+ unsigned long time;
+ unsigned long start_time;
+ double pcpu,
+ wcpu;
+ struct top_proc *next;
+};
+
+
+/*=STATE IDENT STRINGS==*/
+
+#define NPROCSTATES 7
+static char *state_abbrev[NPROCSTATES + 1] =
+{
+ , run, sleep, disk, zomb, stop, swap,
+ NULL
+};
+
+static char *procstatenames[NPROCSTATES + 1] =
+{
+ , running, , sleeping, , uninterruptable, ,
+zombie, , stopped, , swapping, ,
+ NULL
+};
+
+#define NCPUSTATES 5
+static char *cpustatenames[NCPUSTATES + 1] =
+{
+ user, nice, system, idle, iowait,
+ NULL
+};
+static int show_iowait = 0;
+
+#define MEMUSED0
+#define MEMFREE1
+#define MEMSHARED 2
+#define MEMBUFFERS 3
+#define MEMCACHED 4
+#define NMEMSTATS 5
+static char *memorynames[NMEMSTATS + 1] =
+{
+ K used, , K free, , K shared, , K buffers, , K cached,
+ NULL
+};
+
+#define SWAPUSED 0
+#define SWAPFREE 1
+#define SWAPCACHED 2
+#define NSWAPSTATS 3
+static char *swapnames[NSWAPSTATS + 1] =
+{
+ K used, , K free, , K cached,
+ NULL
+};
+
+static char fmt_header[] =
+ PID XPRI NICE SIZE RES STATE TIME WCPUCPU COMMAND;
+
+/* these are names given to allowed sorting orders -- first is default */
+static char *ordernames[] = {cpu, size, res, time, command, NULL};
+
+/* forward definitions for comparison functions */
+intcompare_cpu();
+intcompare_size();
+intcompare_res();
+intcompare_time();
+intcompare_cmd();
+
+int(*proc_compares[]) () =
+{
+ compare_cpu,
+ compare_size,
+ compare_res,
+ compare_time,
+ compare_cmd
Patch for ion
Hi folks,
Here is a patch to build ion 3.0.0~dfsg1-1. Unfortunately it has a lot of use
of MAXHOSTNAMELEN and
MAXPATHLEN so I hardcoded those values for now. (They did the same for
MAXHOSTNAMELEN for mingw).
Should we attempt to fix those issues more correctly?
Thanks,
Barry deFreese (bddebian for those who don't remember me :) )
Index: ion-3.0.0~dfsg1/ici/include/platform.h
===
--- ion-3.0.0~dfsg1.orig/ici/include/platform.h 2012-05-31 11:46:40.0
+
+++ ion-3.0.0~dfsg1/ici/include/platform.h 2012-05-31 11:47:14.0
+
@@ -361,6 +361,18 @@
#endif / End of #ifdef freebsd/
+#ifdef gnu / GNU /
+
+#include malloc.h/ For memalign /
+#include sys/param.h
+#include pthread.h
+
+#define MAXHOSTNAMELEN 256 / GNU doesn't define MAXHOSTNAMELEN /
+#define MAXPATHLEN 1024/ Another ugly hack, neither should
be used /
+#define_MULTITHREADED
+
+#endif / End of #ifdef GNU/
+
#ifdef darwin / Mac OS X /
#include sys/malloc.h
Index: ion-3.0.0~dfsg1/configure.ac
===
--- ion-3.0.0~dfsg1.orig/configure.ac 2012-05-31 11:46:40.0 +
+++ ion-3.0.0~dfsg1/configure.ac2012-05-31 11:47:14.0 +
@@ -214,6 +214,11 @@
fi
;;
vxworks*) AC_DEFINE([vxworks],[1],[Build VXWorks specific platform
code.]) ;;
+ gnu*)
+ AC_DEFINE([gnu],[1],[Build 32-bit GNU specific platform code.])
+ AC_SUBST([ION_CFLAGS], -Dgnu -fno-strict-aliasing)
+ echo Build 32-bit GNU specific platform code.
+ ;;
esac
AC_C_CONST
Index: ion-3.0.0~dfsg1/ici/library/platform.c
===
--- ion-3.0.0~dfsg1.orig/ici/library/platform.c 2012-05-31 11:46:40.0
+
+++ ion-3.0.0~dfsg1/ici/library/platform.c 2012-05-31 11:47:14.0
+
@@ -476,7 +476,7 @@
#endif /* end #ifdef _MULTITHREADED */
-#if (!defined (linux) !defined (freebsd) !defined (darwin) !defined
(RTEMS)) !defined (mingw)
+#if (!defined (linux) !defined (freebsd) !defined (darwin) !defined
(RTEMS) !defined(gnu)) !defined (mingw)
/* These things are defined elsewhere for Linux-like op systems. */
extern int sys_nerr;
@@ -966,7 +966,7 @@
#endif /* end of #if defined (mingw) */
-#if (defined (linux) || defined (freebsd) || defined (darwin) || defined
(RTEMS))
+#if (defined (linux) || defined (freebsd) || defined (darwin) || defined
(RTEMS) || defined(gnu))
char *system_error_msg()
{
Index: ion-3.0.0~dfsg1/ltp/udp/udplso.c
===
--- ion-3.0.0~dfsg1.orig/ltp/udp/udplso.c 2012-04-06 22:39:37.0
+
+++ ion-3.0.0~dfsg1/ltp/udp/udplso.c2012-05-31 12:46:20.0 +
@@ -24,6 +24,10 @@
#define IPHDR_SIZE (20 + 8)
+#elif defined(gnu)
+
+#define IPHDR_SIZE (sizeof(struct iphdr) + sizeof(struct udphdr))
+
#else
#include netinet/ip_var.h
Re: openjdk-6 rules diff
Samuel Thibault wrote: Hello, Barry deFreese, le Tue 26 May 2009 10:47:47 -0400, a écrit : I can't seem to get anywhere with openjdk-6 at the moment. But if someone with lots of memory/swap space wants to try it, attached are the changes I made to debian/rules. You probably have also changed autoconf stuff, haven't you? Samuel Samuel, I don't recall changing any autoconf stuff but you could be right. Barry -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: zsh-beta
Samuel Thibault wrote: Barry deFreese, le Wed 27 May 2009 23:09:29 -0400, a écrit : This block of code in Src/cond.c seems to be the initial issue with zsh-beta: Yes it is. #if defined(GET_ST_MTIME_NSEC) defined(GET_ST_ATIME_NSEC) if (!(st = getstat(left))) return 1; return (st-st_atime == st-st_mtime) ? GET_ST_ATIME_NSEC(*st) GET_ST_MTIME_NSEC(*st) : st-st_atime st-st_mtime; #else return !((st = getstat(left)) st-st_atime = st-st_mtime); #endif The GET_ST_* macros use the st_atim field, which we do provide (as we should and as Linux does) when __USE_MISC gets defined by features.h. IIRC the configure script of zsh properly sets some _BSD_SOURCE to get it but apparently it is not propagated up to here, that's what should be tracked. Samuel Samuel, Neither __USE_MISC nor _BSD_SOURCE are used. _XOPEN_SOURCE is there but only in a minute case and Im not sure what _XOPEN_SOURCE_EXTENDED does but it's only defined for the BSDs and AIX. _GNU_SOURCE is defined but I don't think that brings in __USE_MISC, right? Thanks! Barry -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
zsh-beta
Hi folks, This block of code in Src/cond.c seems to be the initial issue with zsh-beta: 1. #if defined(GET_ST_MTIME_NSEC) defined(GET_ST_ATIME_NSEC) 2. if (!(st = getstat(left))) 3. return 1; 4. return (st-st_atime == st-st_mtime) ? 5. GET_ST_ATIME_NSEC(*st) GET_ST_MTIME_NSEC(*st) : 6. st-st_atime st-st_mtime; 7. #else 8. return !((st = getstat(left)) st-st_atime = st-st_mtime); 9. #endif Barry -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
openjdk-6 rules diff
Hi folks, I can't seem to get anywhere with openjdk-6 at the moment. But if someone with lots of memory/swap space wants to try it, attached are the changes I made to debian/rules. I do know that enabling cacao seems to cause problems. Thanks, Barry --- debian/rules.orig 2009-05-26 10:47:31.65000 -0400 +++ debian/rules2009-05-24 16:28:32.15000 -0400 @@ -25,8 +25,8 @@ PKGSOURCE := $(call vafilt,$(CHANGELOG_VARS),Source) PKGVERSION := $(call vafilt,$(CHANGELOG_VARS),Version) -hotspot_archs = amd64 i386 lpia sparc -shark_archs= amd64 i386 lpia +hotspot_archs = amd64 i386 lpia sparc hurd-i386 +shark_archs= amd64 i386 lpia hurd-i386 shark_archs= no_bootstrap_archs = alpha armel @@ -84,8 +84,8 @@ with_wgy_zenhai = $(if $(filter $(distrel),hardy intrepid jaunty karmic squeeze sid),yes) -arch_map := alpha=alpha arm=arm armel=arm amd64=amd64 hppa=parisc i386=i586 lpia=i586 m68k=m68k mips=mips mipsel=mipsel powerpc=ppc sparc=sparc s390=s390 ia64=ia64 -archdir_map:= alpha=alpha arm=arm armel=arm amd64=amd64 hppa=parisc i386=i386 lpia=i386 m68k=m68k mips=mips mipsel=mipsel powerpc=ppc sparc=sparc s390=s390 ia64=ia64 +arch_map := alpha=alpha arm=arm armel=arm amd64=amd64 hppa=parisc i386=i586 lpia=i586 m68k=m68k mips=mips mipsel=mipsel powerpc=ppc sparc=sparc s390=s390 ia64=ia64 hurd-i386=i586 +archdir_map:= alpha=alpha arm=arm armel=arm amd64=amd64 hppa=parisc i386=i386 lpia=i386 m68k=m68k mips=mips mipsel=mipsel powerpc=ppc sparc=sparc s390=s390 ia64=ia64 hurd-i386=i386 jvmarch:= $(strip $(patsubst $(DEB_HOST_ARCH)=%, %, \ $(filter $(DEB_HOST_ARCH)=%, $(arch_map @@ -94,7 +94,7 @@ default_vm = $(if $(filter $(DEB_HOST_ARCH), $(hotspot_archs)),hotspot,zero) -stage1_gcj_archs = amd64 hppa i386 ia64 lpia powerpc m68k mips mipsel sparc s390 +stage1_gcj_archs = amd64 hppa i386 hurd-i386 ia64 lpia powerpc m68k mips mipsel sparc s390 stage1_openjdk_archs = alpha armel stage1_cacao_archs = @@ -155,7 +155,7 @@ endif ifneq (,$(filter $(distrel),jaunty karmic unstable experimental sid)) - with_pulse = yes + with_pulse = no endif ifneq (,$(filter $(distrel),karmic sid squeeze)) @@ -297,7 +297,7 @@ # assume we don't build binary indep packages on these architectures ifeq ($(with_docs),yes) - ifeq (,$(filter $(DEB_HOST_ARCH), amd64 i386 lpia)) + ifeq (,$(filter $(DEB_HOST_ARCH), amd64 i386 lpia hurd-i386)) CONFIGURE_ARGS += --disable-docs endif else @@ -580,7 +577,7 @@ -e 's/@cjk_fonts@/$(cjk_fonts)/g' \ $$f $$f2; \ done -ifneq (,$(filter $(DEB_HOST_ARCH), i386 lpia)) +ifneq (,$(filter $(DEB_HOST_ARCH), i386 lpia hurd-i386)) # not yet in OpenJDK # cat debian/$(p_jre)-i586.menu $(d_jre).menu rm -f debian/$(p_jre)-i586.menu @@ -645,22 +642,22 @@ endif ifneq (,$(filter cacao, $(alternate_vms))) - ifneq (,$(filter $(DEB_HOST_ARCH), amd64 i386 lpia powerpc sparc)) + ifneq (,$(filter $(DEB_HOST_ARCH), amd64 i386 lpia hurd-i386 powerpc sparc)) # only activate after testing; problems on s390 with_mauve_check += cacao endif - ifneq (,$(filter $(DEB_HOST_ARCH), alpha amd64 armel i386 lpia mips mipsel powerpc s390)) + ifneq (,$(filter $(DEB_HOST_ARCH), alpha amd64 armel i386 hurd-i386 lpia mips mipsel powerpc s390)) # only activate after testing; hangs several tests. with_jtreg_check += cacao endif endif ifneq (,$(filter zero, $(alternate_vms))) - ifneq (,$(filter $(DEB_HOST_ARCH), amd64 i386 lpia)) + ifneq (,$(filter $(DEB_HOST_ARCH), amd64 i386 hurd-i386 lpia)) # only activate after testing with_mauve_check += zero endif - ifneq (,$(filter $(DEB_HOST_ARCH), amd64 i386 lpia)) + ifneq (,$(filter $(DEB_HOST_ARCH), amd64 i386 hurd-i386 lpia)) # only activate after testing; hangs several tests. with_jtreg_check += zero endif
Potential Patch for vala
Hi gents,
Here is a potential patch for vala, based on some feedback from Samuel,
Guillem, and Alan (thanks!).
Thanks,
Barry
diff -urN vala-0.7.2.orig/gobject-introspection/grealpath.h
vala-0.7.2/gobject-introspection/grealpath.h
--- vala-0.7.2.orig/gobject-introspection/grealpath.h 2009-04-09
16:01:10.0 -0400
+++ vala-0.7.2/gobject-introspection/grealpath.h2009-05-25
18:19:15.0 -0400
@@ -10,11 +10,23 @@
static inline gchar*
g_realpath (const char *path)
{
+#ifdef (__GLIBC__) || _POSIX_VERSION = 200809L
+ char *buffer;
+ gchar *gret;
+ if ((buffer = realpath(path, NULL) != NULL)) {
+ gret = g_strdup(buffer);
+ free(buffer);
+ return gret;
+ } else {
+ return NULL;
+ }
+#else
char buffer [PATH_MAX];
if (realpath(path, buffer))
return g_strdup(buffer);
else
return NULL;
+#endif
}
#endif
Re: Potential Patch for consolekit?
Samuel Thibault wrote:
Hello,
Barry deFreese, le Sat 23 May 2009 00:01:17 -0400, a écrit :
@@ -235,7 +235,7 @@
const char *s;
uid_t uid;
charbuf[256];
-charttybuf[PATH_MAX];
+char*ttybuf;
DBusError error;
dbus_bool_t is_local;
@@ -286,8 +286,14 @@
x11_display = display_device;
display_device = ;
} else if (strncmp (_PATH_DEV, display_device, 5) != 0) {
+int tmp_buf = strlen(_PATH_DEV) + strlen(display_device) + 1;
+ if (( ttybuf = malloc(tmp_buf) ) == NULL ) {
+printf(Unable to allocate TTY buffer\n);
+ goto out;
+ }
snprintf (ttybuf, sizeof (ttybuf), _PATH_DEV %s,
display_device);
display_device = ttybuf;
+ free(ttybuf);
}
You can also move the ttybuf declaration inside the if branch, so that
you can keep it as an array, whose size will be
strlen(_PATH_DEV) + strlen(display_device) + 1;
That will fix the now-erroneous sizeof(ttybuf) (when ttybuf is a
pointer, that would return the size of the pointer, not the size of what
is allocated).
+/* adapted from procps */
+/* Load /proc/tty/drivers for device name mapping use. */
We don't have that, and I don't think we should have it anyway, so you
can drop that part of the code.
Samuel
Here is an updated patch. Duck has done some testing. I still haven't
ripped out the procps stuff yet. And I will post to Alioth once I get
my account stuff straightened out.
Thanks,
Barry
diff -urN repo/consolekit-0.3.0/configure.ac consolekit-0.3.0/configure.ac
--- repo/consolekit-0.3.0/configure.ac 2009-05-22 23:56:38.29000 -0400
+++ consolekit-0.3.0/configure.ac 2009-05-16 14:59:07.0 -0400
@@ -189,12 +189,16 @@
;;
*-*-solaris*)
CK_BACKEND=solaris
+ ;;
+ *-*-gnu*)
+ CK_BACKEND=gnu
;;
esac
AC_SUBST(KVM_LIBS)
AM_CONDITIONAL(CK_COMPILE_LINUX, test x$CK_BACKEND = xlinux, [Compiling for
Linux])
+AM_CONDITIONAL(CK_COMPILE_GNU, test x$CK_BACKEND = xgnu, [Compiling for GNU])
AM_CONDITIONAL(CK_COMPILE_FREEBSD, test x$CK_BACKEND = xfreebsd, [Compiling
for FreeBSD])
AM_CONDITIONAL(CK_COMPILE_SOLARIS, test x$CK_BACKEND = xsolaris, [Compiling
for Solaris])
AC_SUBST(CK_BACKEND)
@@ -441,4 +445,4 @@
echo a huge SECURITY HOLE. I repeat: YOU NEED TO EDIT THE FILE
echo ConsoleKit.conf to match your distro/site to avoid NASTY
SECURITY HOLES.
echo
-fi
\ No newline at end of file
+fi
diff -urN repo/consolekit-0.3.0/pam-ck-connector/pam-ck-connector.c
consolekit-0.3.0/pam-ck-connector/pam-ck-connector.c
--- repo/consolekit-0.3.0/pam-ck-connector/pam-ck-connector.c 2009-05-22
23:56:37.11000 -0400
+++ consolekit-0.3.0/pam-ck-connector/pam-ck-connector.c2009-05-23
16:31:13.54000 -0400
@@ -235,7 +235,6 @@
const char *s;
uid_t uid;
charbuf[256];
-charttybuf[PATH_MAX];
DBusError error;
dbus_bool_t is_local;
@@ -286,6 +285,7 @@
x11_display = display_device;
display_device = ;
} else if (strncmp (_PATH_DEV, display_device, 5) != 0) {
+char ttybuf[(strlen(_PATH_DEV) + strlen(display_device) + 1)];
snprintf (ttybuf, sizeof (ttybuf), _PATH_DEV %s,
display_device);
display_device = ttybuf;
}
diff -urN repo/consolekit-0.3.0/src/Makefile.am consolekit-0.3.0/src/Makefile.am
--- repo/consolekit-0.3.0/src/Makefile.am 2008-07-25 14:38:56.01000
-0400
+++ consolekit-0.3.0/src/Makefile.am2009-05-16 15:00:11.0 -0400
@@ -45,6 +45,13 @@
ck-sysdeps-linux.c \
$(NULL)
endif
+
+if CK_COMPILE_GNU
+libck_la_SOURCES +=\
+ ck-sysdeps-gnu.c\
+ $(NULL)
+endif
+
if CK_COMPILE_SOLARIS
libck_la_SOURCES +=\
ck-sysdeps-solaris.c\
@@ -61,6 +68,7 @@
ck-sysdeps-linux.c \
ck-sysdeps-solaris.c\
ck-sysdeps-freebsd.c\
+ ck-sysdeps-gnu.c\
$(NULL)
sbin_PROGRAMS =\
diff -urN repo/consolekit-0.3.0/src/ck-sysdeps-gnu.c
consolekit-0.3.0/src/ck-sysdeps-gnu.c
--- repo/consolekit-0.3.0/src/ck-sysdeps-gnu.c 1969-12-31 19:00:00.0
-0500
+++ consolekit-0.3.0/src/ck-sysdeps-gnu.c 2009-05-22 15:02:29.0
-0400
@@ -0,0 +1,776 @@
+/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 8 -*-
+ *
+ * Copyright (C) 2006 William Jon McCann mcc...@jhu.edu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License
Potential Patch for consolekit?
Hi folks,
Here is a potential patch for consolekit. It does build but most likely
needs review and testing. I will try to test it once I figure out why I
cannot run console on goober.
Thanks,
Barry deFreese
diff -urN repo/consolekit-0.3.0/configure.ac consolekit-0.3.0/configure.ac
--- repo/consolekit-0.3.0/configure.ac 2009-05-22 23:56:38.29000 -0400
+++ consolekit-0.3.0/configure.ac 2009-05-16 14:59:07.0 -0400
@@ -189,12 +189,16 @@
;;
*-*-solaris*)
CK_BACKEND=solaris
+ ;;
+ *-*-gnu*)
+ CK_BACKEND=gnu
;;
esac
AC_SUBST(KVM_LIBS)
AM_CONDITIONAL(CK_COMPILE_LINUX, test x$CK_BACKEND = xlinux, [Compiling for
Linux])
+AM_CONDITIONAL(CK_COMPILE_GNU, test x$CK_BACKEND = xgnu, [Compiling for GNU])
AM_CONDITIONAL(CK_COMPILE_FREEBSD, test x$CK_BACKEND = xfreebsd, [Compiling
for FreeBSD])
AM_CONDITIONAL(CK_COMPILE_SOLARIS, test x$CK_BACKEND = xsolaris, [Compiling
for Solaris])
AC_SUBST(CK_BACKEND)
@@ -441,4 +445,4 @@
echo a huge SECURITY HOLE. I repeat: YOU NEED TO EDIT THE FILE
echo ConsoleKit.conf to match your distro/site to avoid NASTY
SECURITY HOLES.
echo
-fi
\ No newline at end of file
+fi
diff -urN repo/consolekit-0.3.0/pam-ck-connector/pam-ck-connector.c
consolekit-0.3.0/pam-ck-connector/pam-ck-connector.c
--- repo/consolekit-0.3.0/pam-ck-connector/pam-ck-connector.c 2009-05-22
23:56:37.11000 -0400
+++ consolekit-0.3.0/pam-ck-connector/pam-ck-connector.c2009-05-22
23:45:01.84000 -0400
@@ -235,7 +235,7 @@
const char *s;
uid_t uid;
charbuf[256];
-charttybuf[PATH_MAX];
+char*ttybuf;
DBusError error;
dbus_bool_t is_local;
@@ -286,8 +286,14 @@
x11_display = display_device;
display_device = ;
} else if (strncmp (_PATH_DEV, display_device, 5) != 0) {
+int tmp_buf = strlen(_PATH_DEV) + strlen(display_device) + 1;
+ if (( ttybuf = malloc(tmp_buf) ) == NULL ) {
+printf(Unable to allocate TTY buffer\n);
+ goto out;
+ }
snprintf (ttybuf, sizeof (ttybuf), _PATH_DEV %s,
display_device);
display_device = ttybuf;
+ free(ttybuf);
}
remote_host_name = NULL;
diff -urN repo/consolekit-0.3.0/src/Makefile.am consolekit-0.3.0/src/Makefile.am
--- repo/consolekit-0.3.0/src/Makefile.am 2008-07-25 14:38:56.01000
-0400
+++ consolekit-0.3.0/src/Makefile.am2009-05-16 15:00:11.0 -0400
@@ -45,6 +45,13 @@
ck-sysdeps-linux.c \
$(NULL)
endif
+
+if CK_COMPILE_GNU
+libck_la_SOURCES +=\
+ ck-sysdeps-gnu.c\
+ $(NULL)
+endif
+
if CK_COMPILE_SOLARIS
libck_la_SOURCES +=\
ck-sysdeps-solaris.c\
@@ -61,6 +68,7 @@
ck-sysdeps-linux.c \
ck-sysdeps-solaris.c\
ck-sysdeps-freebsd.c\
+ ck-sysdeps-gnu.c\
$(NULL)
sbin_PROGRAMS =\
diff -urN repo/consolekit-0.3.0/src/ck-sysdeps-gnu.c
consolekit-0.3.0/src/ck-sysdeps-gnu.c
--- repo/consolekit-0.3.0/src/ck-sysdeps-gnu.c 1969-12-31 19:00:00.0
-0500
+++ consolekit-0.3.0/src/ck-sysdeps-gnu.c 2009-05-22 15:02:29.0
-0400
@@ -0,0 +1,776 @@
+/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 8 -*-
+ *
+ * Copyright (C) 2006 William Jon McCann mcc...@jhu.edu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ */
+
+#include config.h
+
+#include stdlib.h
+#include stdio.h
+#include fcntl.h
+#include unistd.h
+#include string.h
+#include errno.h
+#include sys/types.h
+#include sys/stat.h
+#include sys/ioctl.h
+
+#include hurd/console.h
+#include dirent.h
+/* #include linux/tty.h */
+/* #include linux/kd.h */
+
+#ifdef HAVE_PATHS_H
+#include paths.h
+#endif /* HAVE_PATHS_H */
+
+#include ck-sysdeps.h
+
+#ifndef ERROR
+#define ERROR -1
+#endif
+
+/* adapted from procps */
+struct _CkProcessStat
+{
+int pid;
+int ppid; /* stat,status pid of parent
process */
+char state; /* stat,status single
Re: openssh
Russell Shaw wrote: Will wrote: On Fri, Oct 31, 2008 at 4:06 AM, Russell Shaw [EMAIL PROTECTED] wrote: Will wrote: On Thu, Oct 30, 2008 at 11:27 PM, Russell Shaw [EMAIL PROTECTED] wrote: Hi, I did apt-get install openssh-server The install script bombs out saying: Creating SSH2 RSA key; this may take some time ...PRNG is not seeded I set RANDFILE=/hurd/ext2fs as a source of randomness, but it didn't help. Install a package called random-egd, then use /dev/random as a source. It worked for me. Hi, I can't find any package by that name, and there's no /dev/random. deb http://ftp.debian-ports.org/debian unreleased main The official debian ports repo will help. There's some hurd exclusive stuff that resides in there. Hi, Now i can get random-egd. However, the deb setup script says: Setting up random-egd (0.5-0+hurd.1) showtrans: /dev/random: No such file or directory showtrans: /dev/urandom: No such file or directory ... How do i get /dev/random? Typically just by copying something in to /dev/random. You can find something a little more random or many times I'll just copy a binary in there. Obviously not very secure but it works. Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New machine for shitbox
Hi folks, OK, I have finally put a new machine in for shitbox. It's still not super high-end (700Mhz PIII with 384Mb) but it should at least be more stable and come back up when rebooting. I also did a dist-upgrade. I hope that wasn't a bad thing. I'm still a little concerned about the HD but I'm not sure how much trouble it would be to get it up on a new one. I'm up for suggestions, etc. I also have a nicer machine P4 (2.4Ghz or so I think) that I was thinking about replacing flubber with but I am wondering if that makes the most sense? Since flubber is now the wiki code and such, should it be taken out of the more public role? I'm thinking maybe using the gnubber hardware for flubber and set up a new gnubber might make more sense. Thoughts? Thanks! Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On vacation
Folks, I am going to be on vacation from June 17th to about the 27th so if any of the public boxes or the wiki dies I, unfortunately, will not be able to bring them back up until I return. I apologize ahead of time for any inconvenience this may cause and the fact that I have not gotten the replacement hardware installed yet. I swear I will work on new hardware for at least the wiki box and flubber when I return from vacation. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
djvulibre
Hi folks, Normally I don't like this type of fix for MAXPATHLEN but he seems to be doing it all over the place in the source so... Here is a fix for djvulibre: diff -u djvulibre-3.5.20/gui/shared/QT/qd_print_dialog.cpp djvulibre-3.5.20/gui/shared/QT/qd_print_dialog.cpp --- djvulibre-3.5.20/gui/shared/QT/qd_print_dialog.cpp +++ djvulibre-3.5.20/gui/shared/QT/qd_print_dialog.cpp @@ -106,6 +106,10 @@ # undef EPS #endif +#ifndef MAXPATHLEN +# define MAXPATHLEN 1024 +#endif + static const QString print_page_str = QT_TRANSLATE_NOOP(QDPrintDialog,of the current page); static const QString print_custom_str Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xpdf
Hey folks, xpdf seems to build OK if you add -lpthreads to LDFLAGS in xpdf/Makefile.in. (And thanks to Ben :-) ) I don't know that it is a portable solution for other architectures though. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libgc: [patch] Thread support for GNU/Hurd
tags 401724 + patch
thank you
Hi,
Here is an updated patch that should apply fine and has moved the gnu
triplet below the kfreebsd check. As with Michael's original diff, you
will need to reconfigure as I have not included those in the diff.
Thank you,
Barry deFreese
diff -urN libgc-6.8.org/configure.in libgc-6.8/configure.in
--- libgc-6.8.org/configure.in 2007-12-30 12:38:32.0 +
+++ libgc-6.8/configure.in 2007-12-29 22:30:20.62000 +
@@ -122,6 +122,11 @@
AC_DEFINE(THREAD_LOCAL_ALLOC)
AC_DEFINE(USE_COMPILER_TLS)
;;
+ *-*-gnu*)
+ AC_DEFINE(GC_GNU_THREADS)
+ AC_DEFINE(_REENTRANT)
+ AC_DEFINE(THREAD_LOCAL_ALLOC)
+ ;;
*-*-netbsd*)
AC_MSG_WARN(Only on NetBSD 2.0 or later.)
AC_DEFINE(GC_NETBSD_THREADS)
diff -urN libgc-6.8.org/debian/rules libgc-6.8/debian/rules
--- libgc-6.8.org/debian/rules 2007-12-30 12:38:32.0 +
+++ libgc-6.8/debian/rules 2007-12-29 22:22:16.0 +
@@ -4,12 +4,6 @@
DEB_BUILD_ARCH:=$(shell dpkg --print-installation-architecture)
-ifeq ($(DEB_BUILD_ARCH),hurd-i386)
- CONFIG_OPTS:=--disable-threads
-else
- CONFIG_OPTS:=
-endif
-
export DH_COMPAT=4
# Uncomment this to turn on verbose mode.
@@ -20,7 +14,7 @@
dh_testdir
# First build the shared library
- ./configure $(CONFIG_OPTS) --enable-cplusplus
--disable-dependency-tracking \
+ ./configure --enable-cplusplus --disable-dependency-tracking \
--with-tags=CXX --prefix=/usr --mandir=\$${prefix}/share/man\
--sysconfdir=/etc --localstatedir=/var/lib\
--datadir=\$${prefix}/share/doc
diff -urN libgc-6.8.org/dyn_load.c libgc-6.8/dyn_load.c
--- libgc-6.8.org/dyn_load.c2006-06-07 05:01:52.0 +
+++ libgc-6.8/dyn_load.c2007-12-29 22:24:31.14000 +
@@ -26,7 +26,8 @@
* None of this is safe with dlclose and incremental collection.
* But then not much of anything is safe in the presence of dlclose.
*/
-#if (defined(__linux__) || defined(__GLIBC__)) !defined(_GNU_SOURCE)
+#if (defined(__linux__) || defined(__GLIBC__)) || defined(__GNU__) \
+!defined(_GNU_SOURCE)
/* Can't test LINUX, since this must be define before other includes */
# define _GNU_SOURCE
#endif
diff -urN libgc-6.8.org/include/gc_config_macros.h
libgc-6.8/include/gc_config_macros.h
--- libgc-6.8.org/include/gc_config_macros.h2006-03-10 22:15:43.0
+
+++ libgc-6.8/include/gc_config_macros.h2007-12-29 22:48:21.78000
+
@@ -43,7 +43,8 @@
|| defined(GC_HPUX_THREADS) \
|| defined(GC_AIX_THREADS) \
|| defined(GC_LINUX_THREADS) \
-|| defined(GC_NETBSD_THREADS))
+|| defined(GC_NETBSD_THREADS)) \
+|| defined(GC_GNU_THREADS)
# define _REENTRANT
/* Better late than never. This fails if system headers that */
/* depend on this were previously included. */
@@ -62,7 +63,8 @@
defined(GC_HPUX_THREADS) || defined(GC_OSF1_THREADS) || \
defined(GC_DGUX386_THREADS) || defined(GC_DARWIN_THREADS) || \
defined(GC_AIX_THREADS) || defined(GC_NETBSD_THREADS) || \
-(defined(GC_WIN32_THREADS) defined(__CYGWIN32__))
+(defined(GC_WIN32_THREADS) defined(__CYGWIN32__)) || \
+ defined(GC_GNU_THREADS)
# define GC_PTHREADS
# endif
diff -urN libgc-6.8.org/include/private/gcconfig.h
libgc-6.8/include/private/gcconfig.h
--- libgc-6.8.org/include/private/gcconfig.h2007-12-30 12:38:32.0
+
+++ libgc-6.8/include/private/gcconfig.h2007-12-29 22:21:16.006350696
+
@@ -1316,10 +1316,11 @@
# define OS_TYPE HURD
# define STACK_GROWS_DOWN
# define HEURISTIC2
- extern int __data_start[];
-# define DATASTART ( (ptr_t) (__data_start))
- extern int _end[];
-# define DATAEND ( (ptr_t) (_end))
+# define SIG_SUSPEND SIGUSR1
+# define SIG_THR_RESTART SIGUSR2
+# define SEARCH_FOR_DATA_START
+ extern int _end[];
+# define DATAEND ((ptr_t) (_end))
/* # define MPROTECT_VDB Not quite working yet? */
# define DYNAMIC_LOADING
# endif
@@ -2154,7 +2155,8 @@
# if defined(SVR4) || defined(LINUX) || defined(IRIX5) || defined(HPUX) \
|| defined(OPENBSD) || defined(NETBSD) || defined(FREEBSD) \
|| defined(DGUX) || defined(BSD) || defined(SUNOS4) \
- || defined(_AIX) || defined(DARWIN) || defined(OSF1)
+ || defined(_AIX) || defined(DARWIN) || defined(OSF1) \
+ || defined(HURD)
# define UNIX_LIKE /* Basic Unix-like system calls work. */
# endif
@@ -2210,7 +2212,7 @@
# define CACHE_LINE_SIZE 32 /* Wild guess */
# endif
-# if defined(LINUX) || defined(__GLIBC__)
+# if defined(LINUX) || defined(HURD
Re: wxwidgets2.6
Samuel Thibault wrote: Samuel Thibault, le Sat 29 Dec 2007 14:48:08 +, a écrit : If somebody encounters such a bug, it would be valuable to try a clean GNU/Linux build first and see whether that fails as well, and then file a regular bug without mentioning Debian GNU/Hurd. I'm running the build right now. No problem with unstable debian/linux :/ I'm upgrading goober and retrying, in case the build tools were a bit too old. Samuel I built it on a freshly dist-upgraded goober so it shouldn't be an old tools issue.. Thanks, Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
wxwidgets2.6
Hi folks, Getting wxwidgets2.6 to build is a fairly easy fix. Line 45093 *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | *-*-k*bsd*-gnu | \ Should be: *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | *-*-gnu* | *-*-k*bsd*-gnu | \ However it fails to finish building with the private libs issues: dpkg-shlibdeps: failure: couldn't find library libwx_baseu-2.6.so needed by debian/libwxgtk2.6-dev/usr/lib/libwx_gtk2u_plot-2.6.so (its RPATH is ''). Note: libraries are not searched in other binary packages that do not have any shlibs file. To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH. dh_shlibdeps: command returned error code 512 make[1]: *** [binary-common] Error 1 Thanks, Barry deFreese (bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LX1 installer and Debian GNU/Hurd
snip * The installation results in a /usr symlink. Debian GNU/Hurd should have a real /usr directory, rather. Now, the question is how to proceed from here. It seems there is one LX1 miniISO being distributed via rapidshare and mirrored at some lesser known locations. See http://projecthurd.googlepages.com/ Ah, that is a quite good overview page with the europe mirror, good. This would be awesome. I know there is a lot of debate about having /usr but I have run in to several issues with packages not building without a real /usr. One question that has always stuck out in my mind though is glibc. Isn't our glibc build using --prefix= ?? Thanks folks! Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please test TLS
Samuel Thibault wrote: Samuel Thibault, le Tue 17 Jul 2007 21:48:21 +0200, a écrit : Note however that mach-defpager still has problems, I still have to dig that. Ok, I fixed that too in the latest package. Samuel YOU DA MAN!! Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compiling glibc-2.5
k. bottle wrote: Hi, I am trying to compiling glibc-2.5 on Hurd but have not succeeded until now. I list my steps below and expect your help. (1) Install Hurd using Debian-k14-Hurd cd1. (2) apt-get libc0.3-dev and mig. and so update glibc to version 2.5 and gcc to 4.1.3. (3) Download lastest glibc-2.5 tarball (do I need to apply any patches?) (4) configure --without-cvs --disable-profile --prefix= ; make I met some warnings and mainly two errors during the compiling course. The first error occurs in stdlib/fmtmsg.c and it says: uint32_t is not defined; another is in sysdeps/posix/getaddrinfo.c and it says: structure stat64 has no member st_mtim. I directly modified the two source files to let the compiling continue, however it finally broke down again when linking ld.so and says: no rule to make ld.map, needed by elf/ld.so. Anyone can help? Thanks! Number one, I don't know if you meant it to come off that way but it is fairly obnoxious to expect help. Number two, compiling glibc2.5 on Hurd from upstream is no small task. You should search through the mailing lists, as there are a ton of patches you need. Is there a specific reason you need to compile glibc? Good Luck, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please test TLS
Samuel Thibault wrote: Samuel Thibault, le Mon 25 Jun 2007 01:24:41 +0200, a écrit : Samuel Thibault, le Sun 24 Jun 2007 21:29:50 +0200, a écrit : Samuel Thibault, le Sun 24 Jun 2007 17:51:25 +0200, a écrit : I've uploaded some experimental TLS-enabled hurd and libc packages for testing to http://dept-info.labri.fr/~thibault/debian-hurd/tls/ They need the gdt user_ldt.c update, so make sure to have gnumach = 20070405. Note: though it works nicely on my box (I'm compiling glibc HEAD with it right now), it looks like it fails completely on others (Thomas and Olaf's at least), so please be careful :) The problem I was having with Xen was when switch_ktss changes() the descriptors, because in an interrupt context, gs is still loaded with the user-level value. In january 2006, Jeroen made trap handlers load kernel data segments in fs and gs, here is a patch to do the same on interrupts (with it, I don't have issues on Xen any more). Could people try TLS with a patched gnumach? Note: there is still an issue with mach-defpager. Samuel Sure I disappear for a while and you guys do the good stuff. Maybe I should take that as a hint?? :) Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Pierre Habouzit wrote: Hi m68k and Hurd porters, You were previously made aware[0] that glibc-2.6 needs TLS to be implemented for your ports to build and work properly, sadly this is still not the case for m68k, and insufficient for Hurd in the current state. We want to release lenny with glibc 2.6 (see discussion with the Release Team in [1]), and it has been released upstream yesterday. We don't plan an upload to unstable immediately, we already have to make glibc 2.5 reach lenny first. Though, we hope to make the first uploads during DebConf. Bringing a new glibc upstream into Debian is a lot of work, and waiting for m68k and Hurd to support TLS properly is sadly not an option we can consider. [0] http://www.mail-archive.com/debian-glibc%40lists.debian.org/msg31594.html [1] http://lists.debian.org/debian-release/2007/04/msg00161.html On behalf of the Glibc Packaging Team, Hi Pierre, I got 2.5 to build with TLS but we need some changes to Hurd and gnumach to handle it. As I understand it we have even more issues with 2.6. Of course I'm certainly not the expert on the issue.. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix for building ntp 4.2.2
[EMAIL PROTECTED] wrote: Hi, On Tue, Apr 10, 2007 at 09:19:17PM -0400, Barry deFreese wrote: OK, attempt #2. Looks good. But is it really intentional, that this patch needs to be applied on top of the previous one?... -antrik- Olaf, You lost me there, what gives that impression? (I may have screwed up my e-mail for sure). Thanks, Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fix for building ntp 4.2.2
Hey folks, Here is what I did to build ntp 4.2.2. Let me know what you think. diff -urN ntpdate/ntp-4.2.2.p4+dfsg/debian/changelog ntp/ntp-4.2.2.p4+dfsg/debian/changelog --- ntpdate/ntp-4.2.2.p4+dfsg/debian/changelog 2007-04-10 16:29:14.0 + +++ ntp/ntp-4.2.2.p4+dfsg/debian/changelog 2007-04-10 15:59:06.0 + @@ -1,3 +1,10 @@ +ntp (1:4.2.2.p4+dfsg-2bd1) unstable; urgency=low + + * debian/rules: disable ipv6 on GNU/Hurd + * debian/rules: Don't move non-existant ntptime + + -- Barry deFreese [EMAIL PROTECTED] Tue, 10 Apr 2007 15:57:33 + + ntp (1:4.2.2.p4+dfsg-2) unstable; urgency=low [ Peter Eisentraut ] diff -urN ntpdate/ntp-4.2.2.p4+dfsg/debian/rules ntp/ntp-4.2.2.p4+dfsg/debian/rules --- ntpdate/ntp-4.2.2.p4+dfsg/debian/rules 2007-04-10 16:29:14.0 + +++ ntp/ntp-4.2.2.p4+dfsg/debian/rules 2007-04-10 16:07:45.0 + @@ -1,5 +1,7 @@ #!/usr/bin/make -f +DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) + include /usr/share/quilt/quilt.make # hacks to avoid running these things during the build @@ -18,6 +20,16 @@ config: patch config.status config.status: $(QUILT_STAMPFN) dh_testdir +ifeq ($(DEB_HOST_ARCH_OS),hurd) + ./configure CFLAGS='$(CFLAGS)' \ + --prefix=/usr \ + --enable-all-clocks --enable-parse-clocks --enable-SHM \ + --disable-debugging --sysconfdir=/var/lib/ntp \ + --with-sntp=no \ + --enable-linuxcaps \ + --enable-ipv6=no \ + --disable-dependency-tracking +else ./configure CFLAGS='$(CFLAGS)' \ --prefix=/usr \ --enable-all-clocks --enable-parse-clocks --enable-SHM \ @@ -25,6 +37,7 @@ --with-sntp=no \ --enable-linuxcaps \ --disable-dependency-tracking +endif build: config build-stamp build-stamp: config.status @@ -55,9 +68,15 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/ntp # move the administrator programs from /usr/bin to /usr/sbin +ifeq ($(DEB_HOST_ARCH_OS),hurd) + for file in ntpdate ntp-wait ntpd tickadj ntp-keygen; do \ + mv debian/ntp/usr/bin/$$file debian/ntp/usr/sbin/$$file || exit; \ + done +else for file in ntpdate ntp-wait ntpd ntptime tickadj ntp-keygen; do \ mv debian/ntp/usr/bin/$$file debian/ntp/usr/sbin/$$file || exit; \ done +endif install -D -m 0755 debian/ntp.ifup debian/ntp/etc/network/if-up.d/ntp install -D -m 0755 debian/ntpdate.ifup debian/ntpdate/etc/network/if-up.d/ntpdate Thanks, Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix for building ntp 4.2.2
Guillem Jover wrote: Hey Barry, On Tue, 2007-04-10 at 17:27:10 -0400, Barry deFreese wrote: snip build: config build-stamp build-stamp: config.status Given that the difference should be minimal it's better to set a variable instead and use it on the configure argument line instead of duping the whole thing, this way it will be easy to maintin (you can check qemu for example on how to do something like that). Also is that «--enable-linuxcaps» there right? snip install -D -m 0755 debian/ntp.ifup debian/ntp/etc/network/if-up.d/ntp install -D -m 0755 debian/ntpdate.ifup debian/ntpdate/etc/network/if-up.d/ntpdate The same here, you could use a varuable with the list instead, so no code is duped. regards, guillem OK, attempt #2. Better or should I not use two var and use like DEB_EXTRA_CONFIGURE_FLAGS or some such? --- ntp/ntp-4.2.2.p4+dfsg/debian/rules 2007-04-10 16:07:45.0 + +++ ntp2/ntp-4.2.2.p4+dfsg/debian/rules 2007-04-10 20:17:45.0 + @@ -4,6 +4,16 @@ include /usr/share/quilt/quilt.make +ifeq ($(DEB_HOST_ARCH_OS),hurd) + IPV6_OPT = --enable-ipv6=no + LINUXCAP_OPT = --disable-linuxcaps + NTP_BINARIES = ntpdate ntp-wait ntpd tickadj ntp-keygen +else + IPV6_OPT = --enable-ipv6 + LINUXCAP_OPT = --enable-linuxcaps + NTP_BINARIES = ntpdate ntp-wait ntpd ntptime tickadj ntp-keygen +endif + # hacks to avoid running these things during the build export ACLOCAL= : aclocal export AUTOCONF = : autoconf @@ -20,24 +30,14 @@ config: patch config.status config.status: $(QUILT_STAMPFN) dh_testdir -ifeq ($(DEB_HOST_ARCH_OS),hurd) - ./configure CFLAGS='$(CFLAGS)' \ - --prefix=/usr \ - --enable-all-clocks --enable-parse-clocks --enable-SHM \ - --disable-debugging --sysconfdir=/var/lib/ntp \ - --with-sntp=no \ - --enable-linuxcaps \ - --enable-ipv6=no \ - --disable-dependency-tracking -else ./configure CFLAGS='$(CFLAGS)' \ --prefix=/usr \ --enable-all-clocks --enable-parse-clocks --enable-SHM \ --disable-debugging --sysconfdir=/var/lib/ntp \ --with-sntp=no \ - --enable-linuxcaps \ + $(LINUXCAP_OPT) \ + $(IPV6_OPT) \ --disable-dependency-tracking -endif build: config build-stamp build-stamp: config.status @@ -68,15 +68,9 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/ntp # move the administrator programs from /usr/bin to /usr/sbin -ifeq ($(DEB_HOST_ARCH_OS),hurd) - for file in ntpdate ntp-wait ntpd tickadj ntp-keygen; do \ + for file in $(NTP_BINARIES); do \ mv debian/ntp/usr/bin/$$file debian/ntp/usr/sbin/$$file || exit; \ done -else - for file in ntpdate ntp-wait ntpd ntptime tickadj ntp-keygen; do \ - mv debian/ntp/usr/bin/$$file debian/ntp/usr/sbin/$$file || exit; \ - done -endif install -D -m 0755 debian/ntp.ifup debian/ntp/etc/network/if-up.d/ntp install -D -m 0755 debian/ntpdate.ifup debian/ntpdate/etc/network/if-up.d/ntpdate Thanks, Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd-tools sbuild post-etch
Roger Leigh wrote: Santiago Vila [EMAIL PROTECTED] writes: 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 did not work well enough to be used on an autobuilder. Will sbuild need to be patched (more than before) for it to work at all? I've had some further thoughts on this. schroot is now required, but looking at the PTS and archive, I don't see any record of schroot having been built on hurd-i386. Has anyone tried this? I wrote schroot on powerpc-linux, and it works on all other other Linux architectures. However, I haven't heard any reports of it being compiled on any non-Linux systems. It's all ISO C++ and some shell script, so it /should/ compile just fine. But, it would be nice to know if it does, and if not to iron out any wrinkles which might be present--there may be some unintentional Linux-isms which need removing. Additionally, the shell scripts used to setup the chroot environment make some Linux-centric assumptions such as the need to mount the procfs/sysfs filesystems inside the chroot, and the ability to bind mount filesystems outside the chroot inside it. None of these are essential, and can easily be special-cased for the Hurd, but this would need doing before schroot will work fully on the Hurd. None of these tasks should be difficult, but I can't do them myself unfortunately--I lack the hardware and time to run Hurd at the moment. However, I would be happy to provide whatever assistance and coding is required to get schroot running once any problems have been identified. Kind regards, Roger [PS. I'm not subscribed to the list, so I would appreciate a CC on any replies. Thanks!] Roger, Well at a quick glance, it appears that schroot build-deps libpam0g-dev which we don't have. Is PAM a strict requirement? Thanks, Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building glibc 2.5 on Hurd: tls
Thomas Schwinge wrote: Hello! Support for tls for Hurd systems is still not fixed properly. Details are at http://savannah.gnu.org/bugs/?17644. To get a functional glibc-2_5-branch, this either needs to be fixed or the tls-requiring bits of glibc-2_5-branch have to be bend over to not require it. Regards, Thomas Hi folks, Just an FYI, I have built glibc-2.5 with all of Thomas's patches. Currently I am getting the following error: /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `mach_open_devstream': /devel3/bdefreese/glibc-2.5/glibc-2.5/mach/devstream.c:137: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `dealloc_ref': /devel3/bdefreese/glibc-2.5/glibc-2.5/mach/devstream.c:117: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `write_some': /devel3/bdefreese/glibc-2.5/glibc-2.5/mach/devstream.c:47: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `devstream_read': /devel3/bdefreese/glibc-2.5/glibc-2.5/mach/devstream.c:94: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `__hurd_fail': ../hurd/hurd.h:76: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os:/devel3/bdefreese/glibc-2.5/glibc-2.5/hurd/hurdselect.c:202: more undefined references to `__libc_errno' follow /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `__pause_nocancel': ../sysdeps/posix/pause.c:55: undefined reference to `sigsuspend_not_cancel' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `__hurd_fail': ../hurd/hurd.h:76: undefined reference to `__libc_errno' ../hurd/hurd.h:76: undefined reference to `__libc_errno' ../hurd/hurd.h:76: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function `execvp': /devel3/bdefreese/glibc-2.5/glibc-2.5/posix/execvp.c:66: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/posix/execvp.c:77: undefined reference to `__libc_errno' /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os:/devel3/bdefreese/glibc-2.5/glibc-2.5/posix/execvp.c:115: more undefined references to `__libc_errno' follow collect2: ld returned 1 exit status make[1]: *** [/devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc.so] Error 1 make[1]: Leaving directory `/devel3/bdefreese/glibc-2.5/glibc-2.5' make: *** [all] Error 2 Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building glibc 2.5 on Hurd: tls
Aurelien Jarno wrote: Thomas Schwinge a écrit : Hello! Support for tls for Hurd systems is still not fixed properly. Details are at http://savannah.gnu.org/bugs/?17644. To get a functional glibc-2_5-branch, this either needs to be fixed or the tls-requiring bits of glibc-2_5-branch have to be bend over to not require it. Thanks to Petr Salinger who send me a patch we have chosen this solution (as m68k is also affected). That's why I tried to build the glibc on Hurd (it was easier than on m68k), to make sure the patch was enough. Oh, I forgot to mention. I also have Jeroen's patch built into the gnumach that I am building with on my machine. If any of you want access to the Hurd box I'm building on, please let me know. Maybe we can co-ordinate efforts? Even though I'm way over my head as usual. Thanks! Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
clisp
Heya gang, You might already know this but clisp did build OK now. However, after install, I get the following: goober:~# clisp /usr/lib/clisp/base/lisp.run: initialization file `/usr/lib/clisp/base/lispinit.mem' was not created by this version of CLISP runtime goober:~# clisp --version /usr/lib/clisp/base/lisp.run: initialization file `/usr/lib/clisp/base/lispinit.mem' was not created by this version of CLISP runtime Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 packages are maintained, I guess, and we Hurd people don't have the resources to fix those where it breaks. The `crosshurd' installation method already allows choosing between having a real `/usr' directory or having the symlink, but the CD installation method does not. Philip, can you change the CD scripts to not create the ``/usr - .'' symbolic link? For simplicity I'd suggest to do it that way instead of making it configurable at installation time, which could also be done, of course. And: congratulations as well from my side for the K14 release. I didn't need it so far, as there was so far no reason to re-install my box, but the day will come, I guess... ;-) Regards, Thomas Thomas, I'm all for it. I realize that it isn't the GNU way but it is the Debian way and it does cause issues building some packages on Debian. Thanks! Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: K14 being uploaded
Philip Charles wrote: Hi folks, The K14 iso's are being uploaded to ftp.gnuab.org/incoming. The first CD should be uploaded in about two hours. The tarball and min-iso have already been uploaded. There is no DVD this time because of the problem with apt-get. A work-around was discovered for the X11 problem. The tarball/baseGNU is suffering from bloat and is untidy, but it works well. Phil. W00t, thanks Philip! Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mono
Hey folks, Now that we have graphviz, I decided to try to build mono. Aside from a PATH_MAX issue, it appears that we don't define: PTHREAD_STACK_MIN The following code seems to be the culprit: mono/io-layer/collection.c #ifdef HAVE_PTHREAD_ATTR_SETSTACKSIZE #ifdef __FreeBSD__ ret = pthread_attr_setstacksize (attr, 65536); #else ret = pthread_attr_setstacksize (attr, PTHREAD_STACK_MIN); #endif g_assert (ret == 0); #endif Should we be defining PTHREAD_STACK_MIN or should I add something like #ifdef __FreeBSD__ || __GNU__ Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installing hurd from cd iso downloaded
itom wrote: hi I'm intresting to install and try Hurd microkernel I found this for download last iso: http://ftp.gnuab.org/pub/debian-cd/ but I see only K11/ and in this newsgroup you talk about K14 where I can download the last? K14 is not created yet and beware of K11, it can have problems. My advice would be to use K10 for now. Good luck, Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6 2.5 and Etch
- Original Message - From: Michael Banck [EMAIL PROTECTED] To: debian-devel@lists.debian.org Cc: debian-hurd@lists.debian.org Sent: Thursday, October 26, 2006 11:45 AM Subject: Re: libc6 2.5 and Etch On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote: We plan to upload [glibc-2.5] right after the release of etch. This version works on all architectures, but m68k, hurd and hppa which don't have TLS support. For hppa the work is almost done, I am currently building the packages (but on a slow machine) to test them. For m68k and hurd, I have sent a mail to the porters a few months ago, I haven't received any answer. Maybe we should have to drop those architectures, at least temporarily. Speaking for the Hurd porters, we know that this needs to be done, but so far nobody either had enough time or enough skill to do the necessary work for it. Michael I have looked at it pretty in-depth. Unfortunately as most of you know it is way outside of my skillset. :-( - Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Rich Cook. Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
squid
Hey folks, Playing around with squid tonight I found the following: debian/rules: ifeq ($(DEB_HOST_ARCH_OS),) DEB_HOST_ARCH_OS := $(subst -gnu,,$(shell dpkg-architecture -qDEB_HOST_GNU_SY$ ifeq ($(DEB_HOST_ARCH_OS),gnu) DEB_HOST_ARCH_OS := hurd endif endif This whole block can be removed. I changed this: # The HURD doesn't have pthreads yet. ifeq ($(DEB_HOST_ARCH_OS), gnu) with_pthreads = --enable-storeio=ufs,diskd,null with_netfilter = with_arp_acl = with_epoll = else to this: ifeq ($(DEB_BUILD_GNU_SYSTEM), gnu) with_pthreads = --with-pthreads --enable-storeio=ufs,diskd,null with_netfilter = with_arp_acl = with_epoll = else And finally in debian/rules, I changed: --with-large-files \ $(DEB_HOST_ARCH_CPU)-debian-$(DEB_HOST_ARCH_OS) to --with-large-files \ $(DEB_HOST_ARCH_CPU)-debian-gnu Obviously we would want to do that dynamically somehow. I tried the ifeq ($(DEB_BUILD_GNU_SYSTE), hurd-i386) ... else ... route to no avail. Finally, there are three MAXPATHLENS. ./helpers/basic_auth/MSNT/allowusers.c ./helpers/basic_auth/MSNT/denyusers.c ./helpers/basic_auth/MSNT/confload.c All three of them are merely used to instantiate char arrays. (ie 'char foo[MAXPATHLEN]') Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xpdf-reader: missing build on hurd-i386
- Original Message - From: Lars Wirzenius [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Sent: Saturday, August 12, 2006 2:21 PM Subject: xpdf-reader: missing build on hurd-i386 Looking at the http://bts.turmzimmer.net/details.php page of release critical bugs, I noticed that xpdf-reader has a bug that is closed since May, but it's listed as an active RC bug because there is an older version built for hurd-i386 in unstable: xpdf-reader | 1.00-3.4 | oldstable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc xpdf-reader | 3.00-13.6 |stable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc xpdf-reader | 3.01-7 | unstable | hurd-i386 xpdf-reader | 3.01-9 | testing | alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc xpdf-reader | 3.01-9 | unstable | alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc I was told on IRC that turmzimmer's page would list it as fixed if someone could build the new version on hurd-i386, and upload it. Assuming this is correct, would someone like to do that? (I'm not on the list, Cc me on replies you want me to see, thanks.) -- The world is not black and white, but different shades of pink. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Lars, I'll see if I can't take a look. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bluez-libs FTBFS
- Original Message - From: Samuel Thibault [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Sent: Wednesday, July 05, 2006 9:54 AM Subject: bluez-libs FTBFS Hi, bluez-libs FTBFS just because the Hurd doesn't define EBADRQC in errno.h (it's not a posix standard error code). Should we add it to the hurd headers, or ask bluez-libs to use another error code? Samuel -- It's probably a double edged sword. If there is a POSIX equivalent it would probably be preferred, but at the same time, the hurd headers and hurd portions of glibc needs some lovin' ;-) Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing GNOME
- Original Message - From: Alejandro Serrano [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Sent: Tuesday, April 04, 2006 10:28 AM Subject: Installing GNOME Well, I continue trying to get my GNU/Hurd system running and as I would like. I've seen in both: http://lists.debian.org/debian-hurd/2005/05/msg00109.html and http://hurd.gnufans.org/bin/view/Hurd/GNOME, that you can get GNOME running on GNU/Hurd. I've added both http://people.debian.org/~mbanck/hurd and http://people.debian.org/~mbanck/hurd-gnome repositories to my /etc/apt/sources.lst, but when I run apt'get install gnome-applets nautilus (and so on) I get a lot of error messages telling that it can't find some packages or that other can't be installed becouse they differ in version. What can I do? I don't mind compiling sources if there's an easy way to do it. Thanks in advance, and for the help you gave me for running X.org Serras Alejandro, Last I had heard we have an issue with Gnome in Debian due to some problem with libonobo or some such. Maybe it has been resolved I don't know. Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making X.org work
snip Thanks you very much. Now it seems to work, but when I execute startx, I get a plain checker-like screen with mouse support (you know, the one that tells startx is working), but nothing else happens. I've tried installing twm, without result, and also wmaker. I'm not very keen on X-Windows, so maybe it's just a silly question, but, what should I do next? As I have said, executing startx just gives me a plain X-Windows screen :-( Serras Have you tried these wiki pages? : http://hurd.gnufans.org/bin/view/Hurd/DebianXorg http://hurd.gnufans.org/bin/view/Hurd/DebianX Good luck, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: brltty FTBFS on hurd-i386 because of lack of sound support
- Original Message - From: Samuel Thibault [EMAIL PROTECTED] To: Barry deFreese [EMAIL PROTECTED] Cc: debian-hurd@lists.debian.org Sent: Tuesday, March 28, 2006 11:31 AM Subject: Re: brltty FTBFS on hurd-i386 because of lack of sound support Hi, Barry deFreese, le Tue 28 Mar 2006 11:11:43 -0500, a écrit : I don't know if this is clean, but flite builds with the following change to debian/rules: --with-audio=none Well, actually the question is a bit the same: should we drop sound dependencies for now from debian packages that don't really _require_ it, because the Hurd doesn't yet have support for it? Regards, Samuel No, you should get to work on writing sound support. ;-) Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: brltty FTBFS on hurd-i386 because of lack of sound support
- Original Message - From: Thomas Schwinge [EMAIL PROTECTED] To: Barry deFreese [EMAIL PROTECTED] Cc: Samuel Thibault [EMAIL PROTECTED]; debian-hurd@lists.debian.org Sent: Tuesday, March 28, 2006 11:54 AM Subject: Re: brltty FTBFS on hurd-i386 because of lack of sound support On Tue, Mar 28, 2006 at 11:49:51AM -0500, Barry deFreese wrote: From: Samuel Thibault [EMAIL PROTECTED] Barry deFreese, le Tue 28 Mar 2006 11:11:43 -0500, a ?crit : I don't know if this is clean, but flite builds with the following change to debian/rules: --with-audio=none Well, actually the question is a bit the same: should we drop sound dependencies for now from debian packages that don't really _require_ it, because the Hurd doesn't yet have support for it? No, you should get to work on writing sound support. ;-) I think we can already have sound on the Hurd, by using one of the networked sound protocols. But then, for this example it sounded like the build system would need OSS's headers. Would it be hard to create OSS header files (and ship them with GNU Mach?) which only make the build system / runtime know that there are no physical sound devices? Same deal for USB, which Barry was working on--what's the state there? Regards, Thomas libusb is problematic because we seem to have a broken jade. Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: brltty FTBFS on hurd-i386 because of lack of sound support
- Original Message - From: Gianluca Guida [EMAIL PROTECTED] To: Thomas Schwinge [EMAIL PROTECTED] Cc: Barry deFreese [EMAIL PROTECTED]; Samuel Thibault [EMAIL PROTECTED]; debian-hurd@lists.debian.org Sent: Tuesday, March 28, 2006 2:38 PM Subject: Re: brltty FTBFS on hurd-i386 because of lack of sound support Hi there, long time. On 3/28/06, Thomas Schwinge [EMAIL PROTECTED] wrote: Would it be hard to create OSS header files (and ship them with GNU Mach?) which only make the build system / runtime know that there are no physical sound devices? Same deal for USB, which Barry was working on--what's the state there? Well, as far as I saw in include/mach (I am writing without having sources, but should be somewhere in the public headers), we have a mach-exported sound interface. All we 'd need is to let the hurd and its application support that. We might even write a null sound device for testing. Then all we need is linkage to linux sound drivers to that interface. Shouldn't be that hard. What do you think? Gianluca I realize that I am a little clueless but I can't find any sound stuff in Mach?? Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to change IP address?
- Original Message - From: Stephen Baird [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Sent: Wednesday, March 08, 2006 7:59 AM Subject: Re: how to change IP address? How do I change my IP address? Stephan, settrans -fg /servers/socket/2 -- Removes current settings settrans -fcap /servers/socket/2 /hurd/pfinet -i interface -a ip address -m subnet mask -g gateway ip Enjoy, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ncurses 5.5
Hey folks, ncurses 5.5 fails to build because it tries to build 64bit libraries. Should be an easy fix if someone knows the proper Debian way to not build the 64bit stuff. Thanks, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hugs_98 and cpphs
Hey folks, hugs_98 is a build-dep for cpphs. hugs builds and installs fine but hasn't been built on the buildd yet. cpphs also builds and installs fine. Thanks, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bazaar
Hey folks, OK, building bazaar. There is a MAXHOSTNAMELEN issue, which I just defined for now. Then I get an error running /usr/bin/gpg even though the file is there. I changed debian/rules to use prefix / instead of /usr, but now I am getting this: Upgrading configuration for registered name: [EMAIL PROTECTED] Test 4: FAILED: the readonly flag is not set. make[3]: *** [tests-timestamp] Error 1 make[3]: Leaving directory `/devel3/bdefreese/debian/bazaar-1.4.2/debian/build/baz/tests' make[2]: *** [test] Error 2 make[2]: Leaving directory `/devel3/bdefreese/debian/bazaar-1.4.2/debian/build/baz' make[1]: *** [test] Error 2 make[1]: Leaving directory `/devel3/bdefreese/debian/bazaar-1.4.2/debian/build' make: *** [debian/build-stamp] Error 2 Thanks, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
agg
Hello, Stuck a patch for agg up on alioth, but here is it also: --- /dev/null 2006-01-20 19:17:40.0 -0500 +++ agg-2.3/Makefile.in.GNU 2006-02-28 18:06:43.0 -0500 @@ -0,0 +1,8 @@ +AGGLIBS= -lagg +AGGCXXFLAGS = -O3 -I/X11R6/include -L/X11R6/lib +CXX = g++ +C = gcc +#CXX = icc +LIB = ar cr + +.PHONY : clean Thanks, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gcl
Howdy folks, In trying to build gcl, I ran across what I think is a bug in tclsh. When gcl checks for tclsh it attempts to set a variable to the output of `tclsh conftest.tcl`. If I run tclsh conftest.tcl from the CL, I get /lib/tcl8.4.so or some such. If I do something like: FOO=`tclsh conftest.tcl` it hangs. I'm not quite sure how to debug this so if anyone has any ideas I would appreciate it. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vsftpd
Physicman, I was actually working on trying to build libcap :-) Barry (aka bddebian) - Original Message - From: Physicman [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Sent: Thursday, February 23, 2006 2:28 AM Subject: vsftpd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
openjade_1.4devel1
Hey folks, OK, I was able to build opensp 1.5 from the orig.tar.gz with a small MAXPATHLEN fix. Then I was able to build openjade_1.4devel1 from source. If someone can bootstrap this and upload, I can probably build opensp 1.5 from Debian source then. (I think) Don't know who can do anything about that. Thanks, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openjade_1.4devel1
- Original Message - From: Michael Banck [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Sent: Wednesday, February 22, 2006 8:03 PM Subject: Re: openjade_1.4devel1 On Wed, Feb 22, 2006 at 05:00:28PM -0500, Barry deFreese wrote: OK, I was able to build opensp 1.5 from the orig.tar.gz with a small MAXPATHLEN fix. Then I was able to build openjade_1.4devel1 from source. Great! If someone can bootstrap this and upload, I can probably build opensp 1.5 from Debian source then. (I think) Don't know who can do anything about that. Well, we need to have the MAXPATHLEN issue fixed in Debian to be able to bootstrap this. Did you file a bug? No, I haven't. I am trying to find a decent solution for the MAXPATHLEN issue. thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
aegis FTBFS
Folks, In trying to build aegis, we have the normal PATH_MAX problem. Digging through the code, it appeared like they were just using PATH_MAX as an abitrary starting allocation size for next_line.c. I e-mailed the Debian maintainer and he concurred and suggested using getpagesize(2) instead. Substituting PATH_MAX with getpagesize(2) builds clean. I'll see if he is willing to make the change. Thanks, Barry deFreese (aka bddebian) Back in business -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
aegis e-mail should have been acl
That last e-mail about aegis should have been the acl package NOT aegis. Sorry, Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
aegis FTBFS (really aegis this time)
OK, in looking at the aegis FTBFS from the buildd it appears that we do not define RLIMIT_AS (Address Space Limit). I am cross-posting this bug-hurd in case this is a missing implementation. On my Ubuntu GNU/Linux box, RLIMIT_AS is defined as 9. However, even after the usual #ifndef magic the package fails on several of the tests and therefore still does not build. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: how to change IP address?
Unset the translator i.e.: settrans -fg /servers/socket/2 Then reset the translator with the new ip i.e.: settrans -fcap /servers/socket/2 /hurd/pfinet -i eth0 -a ip addr -m subnet mask -g gateway Barry deFreese (aka bddebian) Old School N00b :-) - Original Message - From: Stephen Baird [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Sent: Thursday, January 26, 2006 8:19 PM Subject: Re: Re: how to change IP address? How do I change my IP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] __ NOD32 1.1382 (20060127) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.0 uploaded
Michael Banck wrote: Hi, just letting everybody know that gcc-4.0 and an accompanying gcc-defaults have been uploaded Tuesday and should be hitting mirrors right now. Please let us know of any issues you encounter. Michael W00t, good job folks! Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libdiskfs error after upgrade
Heya folks, After my latest update/upgrade, I get the following error: Hurd server bootstrap: ext2fs.static [device:hd0s1] ext2fs.static: /home/mbanck/tmp/hurd-20050119/build-tree/hurd/libdiskfs/node-drop.c:45: diskfs_drop_node: Assertion '!diskfs_readonly' failed. I tried booting an Ubuntu live CD and copying my /hurd dir and /lib/libdisfs* over from flubber but still get the same error. Any other thoughts on reviving my box?? Thanks!! Barry (aka bddebian) BTW, I might be unsubscribed from the list after being off for so long and my ISP bouncing messages so please respond back to me also until I can get re-subscribed to everything. Thanks again! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emacs24.4.1 followup
Thomas Schwinge wrote: On Sat, Apr 16, 2005 at 05:44:41PM -0400, Barry deFreese wrote: Well I moved the debs I built on clubber to flubber and now I get the segfault on installing emacs.. I built (better: tried to build) emacs-21.3 on an up-to-date Debian GNU/Hurd system using only Debian's hurd-libio-glibc.dpatch and CFLAGS='-O0 -g -pipe'. For those who have not yet seen it for theirselves: #v+ [...] ../src/bootstrap-emacs -batch --no-site-file --multibyte -l autoload --eval '(setq generated-autoload-file /var/tmp/build/emacs/emacs-21.3/lisp/loaddefs.el )' -f batch-update-autoloads $wins Directories: /var/tmp/build/emacs/emacs-21.3/lisp /var/tmp/build/emacs/emacs-21.3/lisp/calendar /var/tmp/build/emacs/emacs-21.3/lisp/emacs-lisp /var/tmp/bui ld/emacs/emacs-21.3/lisp/emulation /var/tmp/build/emacs/emacs-21.3/lisp/eshell /var/tmp/build/emacs/emacs-21.3/lisp/gnus /var/tmp/build/emacs/emacs-21.3/lis p/international /var/tmp/build/emacs/emacs-21.3/lisp/language /var/tmp/build/emacs/emacs-21.3/lisp/mail /var/tmp/build/emacs/emacs-21.3/lisp/net /var/tmp/bu ild/emacs/emacs-21.3/lisp/obsolete /var/tmp/build/emacs/emacs-21.3/lisp/play /var/tmp/build/emacs/emacs-21.3/lisp/progmodes /var/tmp/build/emacs/emacs-21.3/ lisp/term /var/tmp/build/emacs/emacs-21.3/lisp/textmodes /var/tmp/build/emacs/emacs-21.3/lisp/toolbar Fatal error (11)./bin/sh: line 1: 24027 Segmentation fault ../src/bootstrap-emacs -batch --no-site-file --multibyte -l autoload --eval '(setq generated -autoload-file /var/tmp/build/emacs/emacs-21.3/lisp/loaddefs.el)' -f batch-update-autoloads $wins make[2]: *** [autoloads] Error 139 make[2]: Leaving directory `/var/tmp/build/emacs/emacs-21.3/lisp' make[1]: *** [bootstrap-lisp] Error 2 make[1]: Leaving directory `/var/tmp/build/emacs/emacs-21.3' make: *** [maybe_bootstrap] Error 2 #v- #v+ [EMAIL PROTECTED]:/var/tmp/build/emacs/emacs-21.3 SHELL=/bin/sh LD_LIBRARY_PATH=/lib/debug gdb src/bootstrap-emacs GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-gnu... (gdb) r Starting program: /var/tmp/build/emacs/emacs-21.3/src/bootstrap-emacs Program received signal SIGSEGV, Segmentation fault. 0x01126b10 in _obstack_begin_1 (h=0x6c0, size=0, alignment=-858993460, chunkfun=0x28000, freefun=0x1126b10 _obstack_begin_1+64, arg=0x0) at obstack.c:257 257 obstack.c: No such file or directory. in obstack.c (gdb) bt #0 0x01126b10 in _obstack_begin_1 (h=0x6c0, size=0, alignment=-858993460, chunkfun=0x28000, freefun=0x1126b10 _obstack_begin_1+64, arg=0x0) at obstack.c:257 #1 0x01123508 in sYSMALLOc (nb=32784, av=0x120d140) at malloc.c:2895 #2 0x011237f9 in __libc_malloc (bytes=32776) at malloc.c:3296 #3 0x081049a5 in emacs_blocked_malloc (size=32776) at alloc.c:737 #4 0x01123785 in __libc_malloc (bytes=32776) at malloc.c:3291 #5 0x08104790 in lisp_malloc (nbytes=32776, type=MEM_TYPE_VECTOR) at alloc.c:594 #6 0x08105f7f in allocate_vectorlike (len=8192, type=MEM_TYPE_VECTOR) at alloc.c:2230 #7 0x0810600c in allocate_vector (nslots=8192) at alloc.c:2254 #8 0x0810620e in Fmake_vector (length=8192, init=409516756) at alloc.c:2350 #9 0x080baec1 in init_keyboard () at keyboard.c:10173 #10 0x080acd6c in main (argc=1, argv=0x101adc4, envp=0x101adcc) at emacs.c:1452 #v- So, the segmentation fault happens in glibc's malloc code. I'll try to rebuild with a fresher glibc than Debian's one during the next days. The strange thing is that I had it partly working yesterday, i.e. I was able to start emacs using 'env - TERM=$TERM emacs' and I'm quite sure that I didn't change anything between yesterday and today. :-| Regards, Thomas Ahh, that might explain why it built on clubber but not flubber. I think I have a new glibc built on clubber that I made with Roland's xattr patches.. Hmm Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
More packages
Heya gang, here are some more packages info: nvi - Builds clean man-db - Builds clean apt - Builds clean gdbm - Builds clean cron - build depends on selinux1-dev (WTF is that all about?) libgpg-error - Problem with mkerrcodes.awk. Submitted to alioth with no patch yet. Enjoy, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Emacs 24.4.1
Hey gang, This message is mainly for azeem and bing but anyone else that is interested. I was able to build emacs21-21.4.1 on clubber with no problems and it runs with no segfaults??? Thanks, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Emacs24.4.1 followup
Damnit, I sent that last one to the wrong ML, sorry. Well I moved the debs I built on clubber to flubber and now I get the segfault on installing emacs.. Lame, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emacs24.4.1 followup
Barry deFreese wrote: Damnit, I sent that last one to the wrong ML, sorry. Well I moved the debs I built on clubber to flubber and now I get the segfault on installing emacs.. Lame, Barry (aka bddebian) OK, if anyone wants to test them, I put the debs out on http://www.bddebian.com/debs/emacs21-21.4 I'll try to build an unstripped version tonight Thanks, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
jbofihe
Hey gang, Themaintainer of jbofihe jumped on #hug today and asked why the hurd version of the package wasn't up to date. I built it today and it builds clean so can someone upload it? Thanks, Barry
Re: heads up
- Original Message - From: Thomas Bushnell BSG [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Sent: Wednesday, March 16, 2005 2:04 PM Subject: heads up WE??? Does that mean you are joining us again?? /me hides. :-) Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: heads up
- Original Message - From: Thomas Bushnell BSG [EMAIL PROTECTED] To: Barry deFreese [EMAIL PROTECTED] Cc: debian-hurd@lists.debian.org Sent: Wednesday, March 16, 2005 2:15 PM Subject: Re: heads up Barry deFreese [EMAIL PROTECTED] writes: WE??? Does that mean you are joining us again?? Hrm. I mean, let's see some code, some patches, some input man. We miss you.. :-) Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: heads up
- Original Message - From: Alfred M. Szmidt [EMAIL PROTECTED] To: Barry deFreese [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; debian-hurd@lists.debian.org Sent: Wednesday, March 16, 2005 2:37 PM Subject: Re: heads up WE??? Does that mean you are joining us again?? Hrm. I mean, let's see some code, some patches, some input man. We miss you.. :-) Where are your patches, Barry? Where is your code, Barry? Did you give any input lately, Barry? (and I agree about the missing bit...) Have you checked debian-hurd on Alioth lately?? Who compiled Rolands xattr stuff? Who is trying to push Marcus to get us Sysv IPC? Yes, I haven't sent patches to Hurd sources specificially but on the Debian side with packages I am trying to do what I can. I have also offered up one of my machines for a buildd. Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: heads up
- Original Message - From: Alfred M. Szmidt [EMAIL PROTECTED] To: Thomas Bushnell BSG [EMAIL PROTECTED] Cc: debian-hurd@lists.debian.org Sent: Wednesday, March 16, 2005 2:33 PM Subject: Re: heads up 2. the architecture must be able to run a buildd 24/7 sustained (without crashing) 3. the architecture must have an actual, running, working buildd This, I think needs to be our target. I think the without crashing is the only thing that needs the target. Just compiling glibc can kill the system. Yes, that is going to be a tough one. I was hoping to use my new box with an 80Gb drive but it has been very unstable. 8. 5 developers who will use or work on the port must send in signed requests for its addition 9. the port must demonstrate that they have at least 50 users We should be able to do these (right?). If we need to add developers, we can do that, but we need to do it ASAP because it takes time to get through the process. This one should be easy, I think there are atleast 5 DDs that do the maintaining of the Hurd specific parts for Debian. We do? Guillem and Michael are active DDs. Who else? Thomas is I think. What about Marcus and Neal, are they both DDs? How is one supposed to demonstrate that a port has atleast 50 users by the way? Define users. Currently running an active Hurd box??? That may be harder to quantify. Thanks. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: heads up
- Original Message - From: Thomas Bushnell BSG [EMAIL PROTECTED] To: Barry deFreese [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; debian-hurd@lists.debian.org Sent: Wednesday, March 16, 2005 3:14 PM Subject: Re: heads up Barry deFreese [EMAIL PROTECTED] writes: So what we need then are bug fixes. :) What are the crashes? I saw messages about crashing during libc, but the talk was all about how to reconfigure libc so it wouldn't crash when compiling...though we shouldn't crash even for bogus compiles. Yeah, so I restate, get to work.. ;-P Unfortunately there aren't any real errors. I don't know if that is because of crash problems or what. I have seen a couple of _pthread_spin_mutex issues on the console but not consistently. Usually it just kind of hangs there. The console is there but the system is just dead. I am afraid that it might be the 2gb ext2fs stuff with the big partitions since my other machine is relatively stable (though it dies on big builds like glibc too). We do? Guillem and Michael are active DDs. Who else? Thomas is I think. What about Marcus and Neal, are they both DDs? I am, and Marcus is. There's 4. I would like to throw my name in the NM queue but that might take a while. Who else? Define users. Currently running an active Hurd box??? That may be harder to quantify. It's a rule of thumb. Fifty people saying yes, I'm a user may be what's needed. If everything else is met, this shouldn't be hard. We can just give them the list of names from #hurd.. ;-P Thomas Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#298856: RFA: libsem
- Original Message - From: Michael Banck [EMAIL PROTECTED] To: debian-hurd@lists.debian.org Cc: Robert Millan [EMAIL PROTECTED] Sent: Thursday, March 10, 2005 10:33 AM Subject: Re: Bug#298856: RFA: libsem On Thu, Mar 10, 2005 at 12:51:03PM +0100, Robert Millan wrote: The GNU/kFreeBSD port no longer depends on libsem (as it switched to linuxthreads) and I'm told the GNU/Hurd port will soon switch to NPTL, so it won't need libsem either. Who told you that? Soon in conjunction with the Hurd is to be taken with a grain of salt. Unless someone who is actualy interested in libsem volunteers to maintain it, I'll request its removal within a week or so. You can't make libsem-dev build-essential for us (without consultation) and then just drop like a hot potato once your currently favoured port doesn't need it anymore. Orphan it if you want, but a request for removal goes too far right now. We'll get it removed once we are certain we don't need it anymore. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html Do we still utilize it? I can try to adopt it if necessary. Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gcc-3.4
Hey folks, gcc-3.4 builds cleanly. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Link Broken
- Original Message - From: Marcus Brinkmann [EMAIL PROTECTED] To: [EMAIL PROTECTED]; debian-hurd@lists.debian.org Sent: Tuesday, March 01, 2005 8:48 AM Subject: Re: Link Broken Hi, this is probably ok, although I have reservations. Specifically, I am not sure anybody is really maintaining the Debian GNU/Hurd web page. I would feel much better about just referring to the Debian web page if I knew that somebody has an eye on it. Any volunteers on the Debian side to give http://www.debian.org/ports/hurd/ a lift? Thanks, Marcus At Mon, 28 Feb 2005 04:07:09 +0100, Alfred M Szmidt wrote: The GNU/Hurd Installation guide link in the page http://www.gnu.org/software/hurd/install.html is broken. Please fix it. Thank you, I have fixed this by removing the redundant information, users are now pointed to the Debian GNU/Hurd projects web page for further details on how to install Debian GNU/Hurd. --- install.html 09 Oct 2004 18:57:52 +0200 1.20 +++ install.html 28 Feb 2005 04:03:51 +0100 @@ -51,8 +51,6 @@ H3A NAME=contentsTable of Contents/A/H3 UL LIA HREF=#version NAME=TOCversionLatest version/A - LIA HREF=#install NAME=TOCinstallInstallation instructions/A - LIA HREF=#cdimage NAME=TOCcdimageCD ROM images/A /UL HR @@ -72,29 +70,9 @@ installation routine which is easy to us The Debian project has commited to provide such a binary distribution. A HREF=http://www.debian.org/ports/hurd/;Debian GNU/Hurd/A is currently under development and available in the sid/unstable branch -of the Debian archive. - -H3A HREF=#TOCinstall NAME=installInstallation instructions/A/H3 -P -A HREF=http://web.walfield.org/papers/hurd-installation-guide/english/hurd-in stall-guide.html -The GNU/Hurd installation guide/A written by Neal Walfield explains how -to install the Debian GNU/Hurd binary distribution of the Hurd. -Also available: -UL -LIformatted in A HREF=http://web.walfield.org/papers/hurd-installation-guide/english/hurd-in stall-guide.pdfPDF (105k characters)/A. -LIformatted as an A HREF=http://web.walfield.org/papers/hurd-installation-guide/english/hurd-in stall-guide.infoInfo document (24k characters)/A. -LIis the A HREF=http://web.walfield.org/papers/hurd-installation-guide/english/hurd-in stall-guide.texiTexinfo source (25k characters)/A. -/UL - -H3A HREF=#TOCcdimage NAME=cdimageCD ROM images/A/H3 -P -The Debian GNU/Hurd binary distribution of the GNU/Hurd system can be -installed most conveniently from CD ROM. The complete Debian GNU/Hurd -snapshot fits on three CDs. Information on -A HREF=http://www.debian.org/ports/hurd/hurd-cd;where to find images -of the current CD ROM set/A are available from the -A HREF=http://www.debian.org/ports/hurd/;Debian GNU/Hurd/A web -pages. +of the Debian archive. Please see +the A HREF=http://www.debian.org/ports/hurd/;Debian GNU/Hurd/A +project web page installation instructions. P EMSome of these links are at other web sites not maintained by the ___ Web-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/web-hurd Marcus, Well I guess I'm not one of the Debian guys but I'd be happy to. :-) Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xchat ?
Mike Small wrote:
On Fri, Feb 18, 2005 at 06:42:12PM -0800, Barry deFreese wrote:
@@ -327,12 +328,18 @@ Util_BuildList(char *word[])
static void
Util_Autoload()
{
-char oldcwd[PATH_MAX];
+#ifdef HAVE_GET_CURRENT_DIR_NAME
+ char *oldcwd = get_current_dir_name ();
+#else
+ char oldcwd[PATH_MAX];
+#endif
const char *dir_name;
struct dirent *ent;
DIR *dir;
-if (getcwd(oldcwd, PATH_MAX) == NULL)
+#ifndef HAVE_GET_CURRENT_DIR_NAME
+ if (getcwd(oldcwd, PATH_MAX) == NULL)
return;
+#endif
/* we need local filesystem encoding for chdir, opendir etc */
dir_name = xchat_get_info(ph, xchatdirfs);
/* fallback for pre-2.0.9 xchat */
@@ -350,6 +357,9 @@ Util_Autoload()
}
closedir(dir);
chdir(oldcwd);
+#ifdef HAVE_GET_CURRENT_DIR_NAME
+ free(oldcwd);
+#endif
}
What happens if get_current_dir_name returns NULL?
HAVE_GET_CURRENT_DIR_NAME won't get set and it will fall through the
getcwd() code.
Michael,
I didn't play with the spacing, I just modified what Chris had already
done. If everyone thinks this is OK, I can change that.
Thanks,
--
Barry deFreese
Debian 3.0r1 Woody
GNU/Hurd
Registered Linux Newbie #302256 - Hurd H4XX0r wannabe
Programming today is a race between software engineers striving
to build bigger and better idiot-proof programs, and the Universe
trying to produce bigger and better idiots. So far, the Universe is
winning. Rich Cook.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xchat ?
Mike Small wrote: I mean that if HAVE_GET_CURRENT_DIR_NAME is set and then at run time the call to get_current_dir_name returns NULL you will have chdir called with a NULL value. Maybe that is harmless, I don't know, but the getcwd code has a check to avoid it. Ahh, I see your point. I'll look at that. Though I hate to do too much with this since it was Chris's work and he has yet to respond. Thanks, -- Barry deFreese Debian 3.0r1 Woody GNU/Hurd Registered Linux Newbie #302256 - Hurd H4XX0r wannabe Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Rich Cook. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xchat ?
- Original Message - From: Barry deFreese [EMAIL PROTECTED] To: Physicman [EMAIL PROTECTED] Cc: Physicman [EMAIL PROTECTED]; debian-hurd@lists.debian.org Sent: Wednesday, February 16, 2005 10:36 AM Subject: Re: Xchat ? - Original Message - From: Physicman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Physicman [EMAIL PROTECTED]; debian-hurd@lists.debian.org Sent: Wednesday, February 16, 2005 9:50 AM Subject: Re: Xchat ? Physicman, Have you tried AC_CHECK_LIB(c, get_current_dirname) ?? Barry Physicman, What are you trying to do here? I pulled the source for xchat-2.4.1 applied your patch and it built clean. What needs to be fixed yet? Thanks, Barry (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xchat ?
Physicman wrote:
The current patch uses _GNU_SOURCE which isn't apparently such a good
idea. So, Alfred suggested to use autoconf to find out if
get_current_dir_name() is available and use that in the #ifdef instead
of _GNU_SOURCE.
Best regards,
Chris
Chris,
How about this: ??
diff -urp xchat-2.4.1.org/configure.in xchat-2.4.1/configure.in
--- xchat-2.4.1.org/configure.in2005-02-18 15:47:17.0 -0500
+++ xchat-2.4.1/configure.in2005-02-18 15:44:16.0 -0500
@@ -590,6 +590,9 @@ AC_CHECK_FUNCS(snprintf)
AC_CHECK_FUNCS(vsnprintf)
AC_CHECK_FUNCS(memrchr)
+dnl Check for get_current_dir_name for GNU System
+AC_CHECK_FUNCS(get_current_dir_name)
+
AC_CHECK_FUNC(gethostbyname, ,
AC_CHECK_LIB(resolv, gethostbyname, ,
AC_CHECK_LIB(nsl, gethostbyname)))
diff -urp xchat-2.4.1.org/plugins/python/python.c
xchat-2.4.1/plugins/python/python.c
--- xchat-2.4.1.org/plugins/python/python.c2005-02-18
15:47:43.0 -0500
+++ xchat-2.4.1/plugins/python/python.c2005-02-18 15:45:52.0
-0500
@@ -58,6 +58,7 @@
#include sys/types.h
#include dirent.h
+#include config.h
#include xchat-plugin.h
#include Python.h
#include structmember.h
@@ -327,12 +328,18 @@ Util_BuildList(char *word[])
static void
Util_Autoload()
{
-char oldcwd[PATH_MAX];
+#ifdef HAVE_GET_CURRENT_DIR_NAME
+ char *oldcwd = get_current_dir_name ();
+#else
+ char oldcwd[PATH_MAX];
+#endif
const char *dir_name;
struct dirent *ent;
DIR *dir;
-if (getcwd(oldcwd, PATH_MAX) == NULL)
+#ifndef HAVE_GET_CURRENT_DIR_NAME
+ if (getcwd(oldcwd, PATH_MAX) == NULL)
return;
+#endif
/* we need local filesystem encoding for chdir, opendir etc */
dir_name = xchat_get_info(ph, xchatdirfs);
/* fallback for pre-2.0.9 xchat */
@@ -350,6 +357,9 @@ Util_Autoload()
}
closedir(dir);
chdir(oldcwd);
+#ifdef HAVE_GET_CURRENT_DIR_NAME
+ free(oldcwd);
+#endif
}
static char *
--
Barry deFreese
Debian 3.0r1 Woody
GNU/Hurd
Registered Linux Newbie #302256 - Hurd H4XX0r wannabe
Programming today is a race between software engineers striving
to build bigger and better idiot-proof programs, and the Universe
trying to produce bigger and better idiots. So far, the Universe is
winning. Rich Cook.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
