Re: Rolling new releases

[Thomas Schwinge]

Hi!

On Mon, 26 Oct 2015 20:57:25 +0100, Justus Winter 
<4win...@informatik.uni-hamburg.de> wrote:
> Quoting Justus Winter (2015-10-05 16:39:46)
> > as agreed earlier, we're trying to produce two releases a year.  We
> > released GNU Mach 1.5, GNU MIG 1.5, and GNU Hurd 0.6 in April, hence
> > it is time for our next release :)
> > 
> > I have curated a list of noteworthy changes and populated the NEWS
> > files with them.

Many thanks!

> > Feel free to commit or suggest any changes.  As a
> > reminder to anyone (including me ;), feel free to add a note to NEWS
> > along with any significant change you propose.
> 
> this your friendly yet mildly annoyed reminder.  It has been three
> weeks now, and there is not much October left to work with.  We agreed
> on bi-yearly releases, and I consider reasonably up-to-date snapshots
> important for downstream users.

ACK.  I've been working on that last weekend, but had too many
interruptions, so couldn't complete.  Will get it done this week.


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: Rolling new releases

[Justus Winter]

Hello,

Quoting Justus Winter (2015-10-05 16:39:46)
> as agreed earlier, we're trying to produce two releases a year.  We
> released GNU Mach 1.5, GNU MIG 1.5, and GNU Hurd 0.6 in April, hence
> it is time for our next release :)
> 
> I have curated a list of noteworthy changes and populated the NEWS
> files with them.  Feel free to commit or suggest any changes.  As a
> reminder to anyone (including me ;), feel free to add a note to NEWS
> along with any significant change you propose.

this your friendly yet mildly annoyed reminder.  It has been three
weeks now, and there is not much October left to work with.  We agreed
on bi-yearly releases, and I consider reasonably up-to-date snapshots
important for downstream users.

Furthermore, producing releases on a regular basis makes a project
look healthy and well maintained.  Let's get our shit together!

If there is anything more that I can do, please let me know.

Cheers,
Justus


signature.asc
Description: signature

Re: Rolling new releases

[David Michael]

On Thu, Oct 8, 2015 at 6:18 PM, Samuel Thibault  wrote:
> David Michael, le Thu 08 Oct 2015 12:55:13 -0400, a écrit :
>> Static linking libpthread doesn't work without it.
>
> Right.  Perhaps libpthread shouldn't be defining __libc_getspecific
> actually.

Thanks for applying all those.  After cherry-picking that last commit
into libpthread's master-glibc branch, I was able to build Hurd's
glibc+libpthread directly from Git without having to manually patch
anything for the first time.

David

Re: Rolling new releases

[Samuel Thibault]

David Michael, le Mon 12 Oct 2015 17:16:47 -0400, a écrit :
> On Thu, Oct 8, 2015 at 6:18 PM, Samuel Thibault  
> wrote:
> > David Michael, le Thu 08 Oct 2015 12:55:13 -0400, a écrit :
> >> Static linking libpthread doesn't work without it.
> >
> > Right.  Perhaps libpthread shouldn't be defining __libc_getspecific
> > actually.
> 
> Thanks for applying all those.  After cherry-picking that last commit
> into libpthread's master-glibc branch, I was able to build Hurd's
> glibc+libpthread directly from Git without having to manually patch
> anything for the first time.

Groovy!

Thanks for the heads-up,
Samuel

Re: Rolling new releases

[David Michael]

On Wed, Oct 7, 2015 at 8:17 PM, Samuel Thibault  wrote:
> David Michael, le Tue 06 Oct 2015 17:49:00 -0400, a écrit :
>> This one avoids problems with a symbol that is also provided by libpthread:
>> https://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/tg-libc_getspecific.diff?view=co
>
> What problem does it actually solve?  Apparently I didn't put enough
> comments to remember what this is about.  AIUI, it should be working
> fine already since this non-weak __libc_getspecific function calls
> cthread_getspecific, which calls pthread_getspecific.

Static linking libpthread doesn't work without it.  The following
commands work with the patch:

$ echo 'int main(){return 42;}' | i686-pc-gnu-gcc -pthread -xc -
$ echo 'int main(){return 42;}' | i686-pc-gnu-gcc -static -pthread -xc -

Without the patch, the second command fails:

$ echo 'int main(){return 42;}' | i686-pc-gnu-gcc -pthread -xc -
$ echo 'int main(){return 42;}' | i686-pc-gnu-gcc -static -pthread -xc -
/usr/i686-pc-gnu/sys-root/lib/libcrt.a(cthreads.o): In function
`__libc_getspecific':
(.text+0x70): multiple definition of `__libc_getspecific'
/usr/i686-pc-gnu/sys-root/lib/libpthread2.a(cthreads-compat.o):(.text+0xd0):
first defined here
collect2: error: ld returned 1 exit status

There may have been other subtle issues with running X or xdm from
this, but I might be thinking of an earlier bad workaround I had...  I
also didn't comment enough to remember the whole story.

Thanks.

David

Re: Rolling new releases

[Ludovic Courtès]

Justus Winter <4win...@informatik.uni-hamburg.de> skribis:

> as agreed earlier, we're trying to produce two releases a year.  We
> released GNU Mach 1.5, GNU MIG 1.5, and GNU Hurd 0.6 in April, hence
> it is time for our next release :)

Don’t forget libc!  :-)

Ludo’.

Re: Rolling new releases

[Samuel Thibault]

David Michael, le Thu 08 Oct 2015 12:55:13 -0400, a écrit :
> Static linking libpthread doesn't work without it.

Right.  Perhaps libpthread shouldn't be defining __libc_getspecific
actually.

Samuel

Re: Rolling new releases

[Samuel Thibault]

Manolis Ragkousis, le Wed 07 Oct 2015 17:34:39 +0300, a écrit :
> There is also a patch in the debian glibc called
> "unsubmitted-clock_t_centiseconds.diff" that fixes some test failures
> for programs like guile.
> 
> Could this patch be included as well, if a new glibc+libpthread
> snapshot is created?

Note: this is really a workaround, applications shouldn't be assuming
the value of the clock tick, and use sysconf(_SC_CLK_TCK) instead.

Samuel

Re: Rolling new releases

[Samuel Thibault]

Hello,

Thanks for the pending patches notices!

David Michael, le Tue 06 Oct 2015 17:49:00 -0400, a écrit :
> This one avoids problems with a symbol that is also provided by libpthread:
> https://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/tg-libc_getspecific.diff?view=co

What problem does it actually solve?  Apparently I didn't put enough
comments to remember what this is about.  AIUI, it should be working
fine already since this non-weak __libc_getspecific function calls
cthread_getspecific, which calls pthread_getspecific.

> I haven't checked if there's a new Debian patch for this, but there is
> an IS_IN macro from the future (build failure) since commit 8042775.
> Use IS_IN_rtld instead:
> http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/cthreads.c?h=tschwinge/Roger_Whittaker#n23

Ah, right, this patch was for 2.22. In Debian we have different versions
of this change according to the version. Since Whittaker is still based
on 2.19, I have added the fix.

> Also, I believe either you or Samuel told me at some point that
> task_notify should be built in libmachuser instead of the proc server.

Yes.  I didn't realize the change was still not done in glibc.  I've now
pushed to upstream and our topgit.  I'll commit to Debian after a build
test (for the new symbols).

> and you can drop Debian's Hurd patch?

Yes.

> (Note to packagers that this will make glibc install a new file,
> .)

That's not a problem.

Thanks,
Samuel

Re: Rolling new releases

[Manolis Ragkousis]

There is also a patch in the debian glibc called
"unsubmitted-clock_t_centiseconds.diff" that fixes some test failures
for programs like guile.

Could this patch be included as well, if a new glibc+libpthread
snapshot is created?

Thanks,
Manolis

Re: Rolling new releases

[David Michael]

Hi,

On Mon, Oct 5, 2015 at 10:39 AM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> as agreed earlier, we're trying to produce two releases a year.  We
> released GNU Mach 1.5, GNU MIG 1.5, and GNU Hurd 0.6 in April, hence
> it is time for our next release :)

If a new glibc+libpthread snapshot is going to be made for the next
release, can I suggest applying these patches to the
tschwinge/Roger_Whittaker branch?

This patch corrects a build failure:
https://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/unsubmitted-NO_HIDDEN.diff?view=co

This one automatically links libhurduser and libmachuser, which is
required to build a lot of things:
https://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/submitted-add-needed.diff?view=co

This one avoids problems with a symbol that is also provided by libpthread:
https://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/tg-libc_getspecific.diff?view=co

I haven't checked if there's a new Debian patch for this, but there is
an IS_IN macro from the future (build failure) since commit 8042775.
Use IS_IN_rtld instead:
http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/cthreads.c?h=tschwinge/Roger_Whittaker#n23

Also, I believe either you or Samuel told me at some point that
task_notify should be built in libmachuser instead of the proc server.
I've been running a patch locally that makes the following edit, which
seems to work.  Maybe this change can be tacked onto the t/gnumach
branch and you can drop Debian's Hurd patch?  (Note to packagers that
this will make glibc install a new file, .)
sed -i -e 's/ gnumach /_notify /' sysdeps/mach/configure{.ac,}

Finally, a question on a somewhat related note ... maybe for the next
release:  I haven't looked into it much yet, but I was thinking maybe
gnumach's new boot-time clock could be exported to provide real
CLOCK_MONOTONIC support for glibc.  Are you aware of any details in
its implementation that would make it inapplicable?  Linux apparently
uses time since boot as the return value for CLOCK_MONOTONIC as well.

Thanks.

David

Re: Rolling new releases

[Samuel Thibault]

Hello,

It'd be good to work out the pending permission issue with fakeroot
before the release (see the "fakeroot-hurd bug or not?" thread).

Samuel