Thomas Schwinge writes:
>> but I'm actually glad we did have a chance to merge
>> some more stuff ;) So, anything else missing for Hurd 0.9?
>
> :-) Seems we're good to go; planning for tomorrow.
Cool!
> I'll then set the GNU Hurd 0.10 etc. release dates for 2017-06, so that
> we'll again have
Hi!
On Sat, 10 Dec 2016 18:35:16 +0100, Justus Winter wrote:
> Thomas Schwinge writes:
>
> > Will it be OK to move the release date towards end of November? (Yay,
> > one more month for getting stuff finished for inclusion...) ;'-\
>
> Or two (mea culpa)
Heh, certainly not your fault!
> bu
Svante Signell, on Sat 10 Dec 2016 20:29:51 +0100, wrote:
> Is there still time for the file record lock patches? I've been running
> hurd/glibc locally with them for years now.
Okay, but there were comments since the last submission, notably:
https://lists.gnu.org/archive/html/bug-hurd/2016-02/m
Hi Thomas,
Is there still time for the file record lock patches? I've been running
hurd/glibc locally with them for years now.
Thanks!
On Sat, 2016-12-10 at 18:35 +0100, Justus Winter wrote:
> Thomas Schwinge writes:
>
> > Will it be OK to move the release date towards end of
> > November? (Y
Thomas Schwinge writes:
> Will it be OK to move the release date towards end of November? (Yay,
> one more month for getting stuff finished for inclusion...) ;'-\
Or two (mea culpa), but I'm actually glad we did have a chance to merge
some more stuff ;) So, anything else missing for Hurd 0.9?
Hello Samuel
On 11/09/16 13:54, Samuel Thibault wrote:
> Manolis Ragkousis, on Wed 09 Nov 2016 13:02:14 +0200, wrote:
>> Now I only have problems with linking http://paste.lisp.org/display/330765
>
> __gsync_wait and __gsync_wake are gnumach RPCs. They have been added to
> gnumach quite a long ti
Manolis Ragkousis, on Wed 09 Nov 2016 13:02:14 +0200, wrote:
> Now I only have problems with linking http://paste.lisp.org/display/330765
__gsync_wait and __gsync_wake are gnumach RPCs. They have been added to
gnumach quite a long time ago, don't you have them in
gnumach/include/mach/gnumach.defs?
Hello Samuel,
The problem was that guix was using gcc-4.9 for cross-compiling which
has a bug not present in newer versions. Using the newer gcc-5 fixes
this. [1]
Now I only have problems with linking http://paste.lisp.org/display/330765
Has anyone encountered this before?
Thank you,
Manolis
[
On Wed, Oct 19, 2016 at 08:10:03PM +0200, Thomas Schwinge wrote:
> ..., and again I want to excuse my radio silence... The good news: we're
> getting married. The bad news: that basically didn't allow to spend any
> time on pet projects, in the last weeks/months. The good news (well, for
> us, a
Thomas Schwinge writes:
> On Sun, 2 Oct 2016 18:54:05 +0200, Justus Winter wrote:
>> it is October, therefore, it is time for a new set of releases :)
>
> Will it be OK to move the release date towards end of November?
Sure.
> I still need to better document/automate what needs to be done (in
>
Hi!
On Sun, 2 Oct 2016 18:54:05 +0200, Justus Winter wrote:
> it is October, therefore, it is time for a new set of releases :)
:-)
(I've set a reminder in my calender to trigger every half a year.) ;-)
..., and again I want to excuse my radio silence... The good news: we're
getting married.
Manolis Ragkousis, on Fri 14 Oct 2016 16:42:42 +0300, wrote:
> ../libpthread/sysdeps/hurd/pt-key.h: In function ‘__pthread_key_lock_ready’:
> ../libpthread/sysdeps/pthread/bits/once.h:32:10: error: initializer
> element is not constant
> (struct __pthread_once) { 0, __PTHREAD_SPIN_LOCK_INITIALIZE
Building the latest tschwinge/Roger_Whittaker fails with:
In file included from ../libpthread/include/pthread/pthreadtypes.h:120:0,
from ../libpthread/include/pthread/pthread.h:55,
from ../libpthread/include/pthread.h:2,
from ../include/pthread.h:
Justus Winter, on Sun 02 Oct 2016 18:54:05 +0200, wrote:
> I'm afraid there haven't been any commits for MIG. Does anyone have a
> patch for it?
Actually I had an unpushed typo patch :)
But I have also pushed the proposed fix for the
MACH_MSG_TYPE_POLYMORPHIC warning.
Samuel
Samuel Thibault, on Mon 10 Oct 2016 21:47:47 +0200, wrote:
> In Debian we build with build-mathvec = no
FYI I've been testing with
../configure --host=i586-gnu --build=i586-gnu --prefix=/usr
--enable-add-ons=libidn,"libpthread " --enable-pt_chown --disable-nscd
CFLAGS="-O2 -g" --disable-werror
David Michael, on Mon 10 Oct 2016 12:44:32 -0700, wrote:
> On Sun, Oct 9, 2016 at 3:35 PM, Samuel Thibault
> wrote:
> > Samuel Thibault, on Tue 04 Oct 2016 16:45:36 +0200, wrote:
> >> Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote:
> >> > FWIW Guix follows upstream glibc releases for G
On Sun, Oct 9, 2016 at 3:35 PM, Samuel Thibault wrote:
> Samuel Thibault, on Tue 04 Oct 2016 16:45:36 +0200, wrote:
>> Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote:
>> > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently
>> > in the process of switching from 2.23
Samuel Thibault, on Mon 10 Oct 2016 16:10:40 +0200, wrote:
> Manolis Ragkousis, on Mon 10 Oct 2016 17:07:52 +0300, wrote:
> > /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:
> > In function ?__register_new_task_notification?:
> > /tmp/guix-build-
Manolis Ragkousis, on Mon 10 Oct 2016 17:07:52 +0300, wrote:
> /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:
> In function ?__register_new_task_notification?:
> /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task
Hello Ludo, Hello Samuel
I am currently trying to build the latest tschwinge/Roger_Whittaker
with Guix and it fails with
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:
In function ?__register_new_task_notification?:
/tmp/guix-build-glibc-cros
Ludovic Courtès, on Mon 10 Oct 2016 10:02:36 +0200, wrote:
> Samuel Thibault skribis:
> > Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote:
> >> > Yes, but our current glibc tree is based on glibc 2.22, as guix needs
> >> > it.
> >>
> >> FWIW Guix follows upstream glibc releases for GNU/
Samuel Thibault skribis:
> Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote:
>> > Yes, but our current glibc tree is based on glibc 2.22, as guix needs
>> > it.
>>
>> FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently
>> in the process of switching from 2.23 to 2.2
Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote:
> > Yes, but our current glibc tree is based on glibc 2.22, as guix needs
> > it.
>
> FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently
> in the process of switching from 2.23 to 2.24), and we’d prefer to have
> the
Samuel Thibault, on Tue 04 Oct 2016 16:45:36 +0200, wrote:
> Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote:
> > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently
> > in the process of switching from 2.23 to 2.24),
>
> Ah! I was asking the question some time ago,
Richard Braun, on Tue 04 Oct 2016 16:45:46 +0200, wrote:
> On Tue, Oct 04, 2016 at 03:22:32PM +0200, Ludovic Courtès wrote:
> > >> Is it possible to make a release of Hurd until mlockall/munlockall is
> > >> implemented? From what I understand these functions are needed to build
> > >> Hurd on
> >
Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote:
> FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently
> in the process of switching from 2.23 to 2.24),
Ah! I was asking the question some time ago, and thought Guix was still
on 2.22. We can easily upgrade to 2.23 and
On Tue, Oct 04, 2016 at 03:22:32PM +0200, Ludovic Courtès wrote:
> >> Is it possible to make a release of Hurd until mlockall/munlockall is
> >> implemented? From what I understand these functions are needed to build
> >> Hurd on
> >> top of glibc2.24.
> >
> > Yes, but our current glibc tree is ba
Hi,
Samuel Thibault skribis:
> Svante Signell, on Tue 04 Oct 2016 12:27:12 +0200, wrote:
>> On Sun, 2016-10-02 at 18:54 +0200, Justus Winter wrote:
>> > it is October, therefore, it is time for a new set of releases :)
>> >
>> > I'll be going over the changes and update the NEWS files as usual,
Svante Signell, on Tue 04 Oct 2016 12:27:12 +0200, wrote:
> On Sun, 2016-10-02 at 18:54 +0200, Justus Winter wrote:
> > it is October, therefore, it is time for a new set of releases :)
> >
> > I'll be going over the changes and update the NEWS files as usual, but
> > feel free to beat me to that.
On Sun, 2016-10-02 at 18:54 +0200, Justus Winter wrote:
> Hello,
>
> it is October, therefore, it is time for a new set of releases :)
>
> I'll be going over the changes and update the NEWS files as usual, but
> feel free to beat me to that. Also, if anyone has some pet patches or
> fixes that w
On Sun, Oct 2, 2016 at 12:45 PM, Samuel Thibault
wrote:
> David Michael, on Sun 02 Oct 2016 12:18:50 -0700, wrote:
>> On Sun, Oct 2, 2016 at 10:53 AM, Samuel Thibault
>> wrote:
>> > David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote:
>> >> Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c bre
Hello,
David Michael, on Sun 02 Oct 2016 12:18:50 -0700, wrote:
> On Sun, Oct 2, 2016 at 10:53 AM, Samuel Thibault
> wrote:
> > David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote:
> >> Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c breaks static linking
> >> (namely ext2fs.static) from miss
On Sun, Oct 2, 2016 at 10:53 AM, Samuel Thibault
wrote:
> David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote:
>> Add a GLIBC_2.22 { __mach_host_self_; } section to mach/Versions.
>
> Alright, I forgot to cherry-pick the upstream commit for this. Note
> however that in upstream, it got version
Samuel Thibault, on Sun 02 Oct 2016 19:53:12 +0200, wrote:
> David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote:
> > There were undefined symbol errors from pthread timer sysdeps. I
> > didn't look into a real solution to this one and just worked around it
> > with `rm sysdeps/pthread/*timer*
Hello,
David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote:
> On Sun, Oct 2, 2016 at 9:54 AM, Justus Winter wrote:
> > Also, if anyone has some pet patches or
> > fixes that would be nice to include, feel free to speak up or send
> > patches.
>
> Okay, here is my semiannual list of non-Debia
Hi,
On Sun, Oct 2, 2016 at 9:54 AM, Justus Winter wrote:
> Also, if anyone has some pet patches or
> fixes that would be nice to include, feel free to speak up or send
> patches.
Okay, here is my semiannual list of non-Debian glibc/libpthread
problems (and also gnumach this time).
glibc:
Add a
Hello,
it is October, therefore, it is time for a new set of releases :)
I'll be going over the changes and update the NEWS files as usual, but
feel free to beat me to that. Also, if anyone has some pet patches or
fixes that would be nice to include, feel free to speak up or send
patches.
Perso
37 matches
Mail list logo
