Re: Time for another round of releases
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
Re: Time for another round of releases
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 Samuel
Re: Time for another round of releases
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 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 2.24 as needed, we already > >> have the required changes in Debian. > > > > I have now upgraded to 2.23. > > This seems to have fixed the static-linking weirdness, however I now > have to remove a reference to the non-existent libmvec_nonshared at: > > http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/math/Makefile?h=tschwinge/Roger_Whittaker#n102 > > Linking with -lm fails due to that missing file. Is it supposed to be built? In Debian we build with build-mathvec = no Samuel
Re: Time for another round of releases
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 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 2.24 as needed, we already >> have the required changes in Debian. > > I have now upgraded to 2.23. This seems to have fixed the static-linking weirdness, however I now have to remove a reference to the non-existent libmvec_nonshared at: http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/math/Makefile?h=tschwinge/Roger_Whittaker#n102 Linking with -lm fails due to that missing file. Is it supposed to be built? Thanks. David
Re: Time for another round of releases
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-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:78:22: > > error: large integer implicitly truncated to unsigned type > > [-Werror=overflow] > >/* msgt_name = */ MACH_MSG_TYPE_POLYMORPHIC, > > ^ > > cc1: all warnings being treated as errors > > > > Any ideas? > > In Debian we use -Wno-error, there are lots of warnings here and there, > fixing them all is a no-go for now. I have disabled -Werror in our tree. Samuel
Re: Time for another round of releases
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_notification.c:78:22: > error: large integer implicitly truncated to unsigned type [-Werror=overflow] >/* msgt_name = */ MACH_MSG_TYPE_POLYMORPHIC, > ^ > cc1: all warnings being treated as errors > > Any ideas? In Debian we use -Wno-error, there are lots of warnings here and there, fixing them all is a no-go for now. Samuel
Re: Time for another round of releases
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-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:78:22: error: large integer implicitly truncated to unsigned type [-Werror=overflow] /* msgt_name = */ MACH_MSG_TYPE_POLYMORPHIC, ^ cc1: all warnings being treated as errors http://paste.lisp.org/display/328211 Any ideas? Manolis On 10/10/16 12:15, Samuel Thibault wrote: > > For 2.23, the tschwinge/Roger_Whittaker is ready. > > Samuel 1nl08hppn6c1lpmbgw07565fbcir4f-glibc-cross-i586-pc-gnu-2.23.drv.bz2 Description: application/bzip
Re: Time for another round of releases
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/Linux (we’re currently > >> in the process of switching from 2.23 to 2.24), and we’d prefer to have > >> the same version on both GNU/Linux and GNU/Hurd, modulo the > >> Hurd-specific patches. > > > > So it's now 2.23. When Guix switched to 2.24 for Linux, please tell me, > > I'll update the tree to 2.24. > > It’s already done in a branch that is being built (hopefully merged > within a week or so). > > So you could go ahead and just let us know which tarballs or commits we > should be using for each version. Is that fine with you? Manolis, For 2.23, the tschwinge/Roger_Whittaker is ready. Samuel
Re: Time for another round of releases
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.24), and we’d prefer to have >> the same version on both GNU/Linux and GNU/Hurd, modulo the >> Hurd-specific patches. > > So it's now 2.23. When Guix switched to 2.24 for Linux, please tell me, > I'll update the tree to 2.24. It’s already done in a branch that is being built (hopefully merged within a week or so). So you could go ahead and just let us know which tarballs or commits we should be using for each version. Is that fine with you? Manolis, WDYT? Thanks! Ludo’.
