Re: bug-hurd mailing list

[Thomas Schwinge]

Hi!

On Sat, 03 Oct 2015 00:05:59 +0200, I wrote:
> On Wed, 30 Sep 2015 22:27:04 +0200, Robert Millan  wrote:
> > I suspect the
> > list server isn't forwarding neither your mails nor mine:
> > 
> >1. My previous mail doesn't show up in the list archive:
> > 
> >   https://lists.gnu.org/archive/html/bug-hurd/2015-09/index.html
> > 
> >2. I received a direct copy of your mail, but I didn't receive it
> >   through the list. And it doesn't show up in the list archives
> >   either!
> > 
> > Anyone knows what's going on? :-)
> 
> I don't have any insights into the GNU email infrastructure, but I can
> confirm that
>  is
> missing messages, that
>  is "404
> Not Found" even though there have been messages posted and delivered
> through the bug-hurd list, and that  is
> also stuck at "635184 Sep 29 09:56 2015-09".  Looking at a few messages'
> Received headers, there are big delays (many hours) between GNU machines.

OK, I learned from  that indeed there
"currently" are problems with lists.gnu.org; they're working on it.


Grüße,
 Thomas


signature.asc
Description: PGP signature

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: more clocks (was: Rolling new releases)

[Samuel Thibault]

Justus Winter, le Wed 07 Oct 2015 00:17:13 +0200, a écrit :
> Quoting David Michael (2015-10-06 23:49:00)
> > 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.
> 
> Yes, we should do that.  It is a matter of creating a new interface,
> so that one can select the clock, maybe host_{g,s}et_time2.  And the
> mapped time interface could export all the clocks.  And glibc should
> be patched to map the time source and use it instead of host_get_time.

Agreed.

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: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

[Samuel Thibault]

Flávio Cruz, le Wed 07 Oct 2015 21:12:12 +0200, a écrit :
> Have you see the new patches?

Yes, it's in my mbox, along so many other mails :/

Samuel

Re: "Recent changes" links redirect to 404

[Thomas Schwinge]

Hi!

On Mon, 28 Sep 2015 23:54:01 +0300, gk.p...@gmail.com wrote:
> When going to the "recent changes" at the hurd wiki, and clicking to one
> of the pages I am redirected to a "404 - not found" page. This also
> holds true for the hurd wiki at sceen.net.

Thanks for reporting this -- it seems the system hosting the wiki system
has been re-installed a while ago, and I needed to
re-install/re-configure some things.  Doing that, I accidentally nuked a
few configuration files, and figuring out what needs to be done, this was
a good "reminder" on how that setup is done; I have then updated

with some more details.  ;-)

Anyway, things should be working again.  I tested: git push; web edit
with local user; web edit with launchpad.net OpenID login; some CGI
functionality, including the search box in the upper right corner.


Grüße,
 Thomas


signature.asc
Description: PGP signature

Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

[Flávio Cruz]

Hi Samuel

Have you see the new patches? Let me know if anything looks wrong.

Cheers
Flavio

On 20 September 2015 at 03:04, Flávio Cruz  wrote:

> Hi Samuel
>
> On Sat, 19 Sep 2015 at 14:22 Samuel Thibault 
> wrote:
>
>> Sorry I didn't think about it at first, but inside the fallback on
>> file_utimes:
>>
>> Flávio Cruz, le Thu 17 Sep 2015 02:05:33 +, a écrit :
>> > +  if (err == MIG_BAD_ID || err == EOPNOTSUPP)
>> > +{
>> > +  time_value_t atim, mtim;
>> > +
>> > +  if (tsp == NULL)
>> > +/* Setting the number of microseconds to `-1' tells the
>> > +   underlying filesystems to use the current time.  */
>> > +atim.microseconds = mtim.microseconds = -1;
>> > +  else
>> > +{
>> > +  TIMESPEC_TO_TIME_VALUE (&atim, &(tsp[0]));
>> > +  TIMESPEC_TO_TIME_VALUE (&mtim, &(tsp[1]));
>> > +}
>> > +
>> > +  err = HURD_DPORT_USE (fd, __file_utimes (port, atim, mtim));
>>
>> We should additionally check for tv_nsec being UTIME_OMIT, and in that
>> case return EOPNOTSUPP.  Otherwise we'd be telling old translators a very
>> odd date.
>
>
> Gotcha. I'm also checking for UTIME_NOW and then setting the time_value_t
> microseconds field to -1 so that old translators use the current time.
>
> Flávio
>
>
>>
>> Samuel
>>
>


-- 
Flávio Cruz / flavioc...@gmail.com

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