On Tuesday, February 19, 2019 7:02:08 PM CET Bruno Haible wrote:
> Hi Pavel,
>
> > > [...]
> > > This patch fixes both issues, and makes the IFS handling a bit more
> > > robust.
> > > [...]
> >
> > > -case $_fpf_arg in
> > > +case "$_fpf_arg" in
> > > [...]
> > > - fpf_dirs=$1 ; shift
On Tuesday, February 19, 2019 7:18:57 PM CET Bruno Haible wrote:
> Hi Pavel,
>
> > > makes the IFS handling a bit more robust.
>
> What I meant is that
>
>save_IFS="$IFS"
>for fpf_dir in $fpf_dirs
>do
> IFS="$save_IFS"
> [Some more code]
>done
>IFS="$save_IFS"
>
>
Thanks for working on this, Bruno! Only nits..
On Thursday, February 14, 2019 8:53:33 PM CET Bruno Haible wrote:
> [...]
> This patch fixes both issues, and makes the IFS handling a bit more robust.
> [...]
> -case $_fpf_arg in
> +case "$_fpf_arg" in
> [...]
> - fpf_dirs=$1 ; shift
> -
On Thursday, January 4, 2018 7:08:41 PM CET Eric Blake wrote:
> On 01/04/2018 11:55 AM, Pavel Raiskup wrote:
> > Previously the '--checkpoint-action=echo' was triggered after
> > '--checkpoint-action=sleep=1' - so the order of events *usually*
> > was (f
Previously the '--checkpoint-action=echo' was triggered after
'--checkpoint-action=sleep=1' - so the order of events *usually*
was (for --format='gnu'):
...
1. checkpoint handler before write of 'dir/sub' member
2. one-second delay
3. stderr write: 'tar: Write checkpoint 3'
4. write the
Issue observed because the new GCC 7 -Wimplicit-fallthrough is
whining when useless 'break;' is not specified after argp_error
call.
* lib/argp.h (__argp_error): Declare as _Noreturn.
* lib/argp-help.c (__argp_error): Explicitly throw backtrace if
the function was about to return.
---
lib/argp-he
[+cc gnulib, the selinux-at code comes from there]
Thanks for the report!
On Tuesday, February 14, 2017 10:16:02 AM CET Lorinczy Zsigmond wrote:
> It might be selinux (even if you didn't specify the platform you use).
> You could try to disable it with configure option '--without-selinux'
Yes, f
On Thursday, January 5, 2017 7:51:00 PM CET Bruno Haible wrote:
> Pavel Raiskup wrote:
> > Thanks. Minor report is that gl_thread_join() is not handled properly for
> > joined thread statuses.
> >
> > This leads to situation that Koji build system tries to gently te
Thanks. Minor report is that gl_thread_join() is not handled properly for
joined thread statuses.
This leads to situation that Koji build system tries to gently terminate
the build first (after two days) ... which (sometimes?) leads to successful
'test-lock' run in the end and the build succeeds
On Wednesday, January 4, 2017 3:17:01 PM CET Bruno Haible wrote:
> Pádraig Brady:
> > Now that test-lock.c is relatively fast on numa/multicore systems,
> > it seems like it would be useful to first alarm(30) or something
> > to protect against infinite hangs?
>
> If we could not pinpoint the orig
On Wednesday, January 4, 2017 1:19:36 PM CET Pavel Raiskup wrote:
> I don't want to claim rwlocks are not reliable. IMO rwlocks do what we
> ask to do... One writer OR multiple readers.
>
> The question is what should be the default policy ... who should be more
> p
Hi Bruno,
On Wednesday, January 4, 2017 11:54:27 AM CET Bruno Haible wrote:
> Hi Pavel,
>
> > Can we assume all systems supporting pthreads are conforming to this
> > specs? That was pretty big (and pretty recent) change of specification.
>
> The change in the specification [4] mentions that th
On Wednesday, January 4, 2017 12:43:17 AM CET Bruno Haible wrote:
> Pavel Raiskup wrote:
> > POSIX says (for pthread_rwlock_wrlock()):
> >
> > Implementations may favor writers over readers to avoid writer
> > starvation.
> >
> > But that's too fa
Hello Berny,
On Monday, January 2, 2017 8:02:03 PM CET Bernhard Voelker wrote:
> On 01/02/2017 05:37 PM, Pavel Raiskup wrote:
> > On Monday, January 2, 2017 4:50:28 PM CET Bruno Haible wrote:
> >> Especially since the problem occurs only on one architecture.
> >
> &g
On Monday, January 2, 2017 4:50:28 PM CET Bruno Haible wrote:
> Hi Pavel,
>
> > One thing I'm afraid of is that writers could finish too
> > early. Could we could artificially slow them down?
>
> In test_rwlock the test does this:
>
> /* Wait for the threads to terminate. */
> for (i = 0;
On Saturday, December 24, 2016 6:52:07 PM CET Bruno Haible wrote:
> Wow, a 30x speed increase by using a lock instead of 'volatile'!
>
> Thanks for the testing. I cleaned up the patch to do less
> code duplication and pushed it.
Thanks, that's nice speedup! And sorry for the delay..
I still see
Hi all, has anybody experienced issues with 'test-lock'?
I haven't been able to reproduce this on my box, yet .. so I need to get and
access to machines in Fedora's Koji (or get builder specs) and I'll have a look
at this ASAP.
But I'm rather asking whether we know about recent issues.
Firstly I
On Friday 27 of November 2015 12:08:53 Pavel Raiskup wrote:
> On Monday 23 of November 2015 11:31:15 Pádraig Brady wrote:
> > On 23/11/15 08:30, Pavel Raiskup wrote:
> > > Hello maintainers,
> > >
> > > I planned to reuse some of my local gnulib modules in mul
On Monday 23 of November 2015 11:31:15 Pádraig Brady wrote:
> On 23/11/15 08:30, Pavel Raiskup wrote:
> > Hello maintainers,
> >
> > I planned to reuse some of my local gnulib modules in multiple projects.
> >
> > Because the modules are not yet ready to be prop
On Monday 23 of November 2015 11:31:15 Pádraig Brady wrote:
> On 23/11/15 08:30, Pavel Raiskup wrote:
> > Hello maintainers,
> >
> > I planned to reuse some of my local gnulib modules in multiple projects.
> >
> > Because the modules are not yet ready to be prop
m project_A to project_B.
The attached patch would help a lot:
$ cd project_A
$ git submodule add project_B /path/to_project_B
$ gnulib --local-dir project_B/gl --local-dir gl ...
Thanks for cosidering,
Pavel
>From c110309df9477f0b687c5c2ebffe59a55c440942 Mon Sep 17 00:00:00 2001
From: Pa
On Tuesday 06 of October 2015 00:42:01 Paul Eggert wrote:
> Pavel Raiskup wrote:
> > Adjusted patch re-attached.
>
> Whoops, it looks like that patch has a problem with unicase/locale-language;
> could you please look into it? Here's how to reproduce it:
>
> ./gnul
tching:
>
>nl='
>'
>case "${nl}${final_modules}${nl}" in
> *"${nl}extensions${nl}"*) ...
>esac
.. this seems to work and without pipes.
Adjusted patch re-attached.
Pavel
>From b8239cff1daec7485f1692719ba7f0a2997330d2 Mon Se
-1,3 +1,15 @@
+2015-09-24 Pavel Raiskup
+
+ gitlog-to-changelog: trim only trailing whitespaces
+ This is fix for --format regression introduced by commit
+ 2b93079a5d1baa4d; it caused that --format='%s%n%n%b%n' (see the
+ doubled %n string) had no effect a
otes around the regexp, when possible:
Thanks! Re-attached.
Pavel
>From 70ec1d7961abbeed6d613ac9035fba4f8690626c Mon Sep 17 00:00:00 2001
From: Pavel Raiskup
Date: Thu, 2 Jul 2015 13:58:22 +0200
Subject: [PATCH] gnulib-common.m4: fix gl_PROG_AR_RANLIB/AM_PROG_AR clash
The gl_PROG_AR_RANLIB (it i
On Tuesday 14 of July 2015 06:29:15 Eric Blake wrote:
> Overall, seems like it is correct, once you fix the typos.
Thanks for your review, fixed patch attached.
Pavel
>From cc0cd1c751d54af0d7211e321f40ce99b0f68b62 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup
Date: Thu, 2 Jul 2015 13:58:22
On Wednesday 01 of July 2015 16:38:57 Pádraig Brady wrote:
> On 01/07/15 16:22, Pavel Raiskup wrote:
> > Yes, there is still nothing like that in gnulib-tool, am I right? I mean
> > dependency among configure.ac-early snippets -- those seem to be all just
> > sorted by nam
On Wednesday 01 of July 2015 15:19:15 Pádraig Brady wrote:
> On 01/07/15 14:57, Pavel Raiskup wrote:
> > On Wednesday 01 of July 2015 13:42:35 Pádraig Brady wrote:
> >>>> On 01/07/15 09:00, Pavel Raiskup wrote:
> >>> This becomes painfully complicated, sorry to
r to NULL directly in
'map_to_failure()' gnulib function. This is not very precisely spelled in
getfilecon(3), but based on statement:
The returned context should be freed with freecon(3) if non-NULL.
.. seems like in this case *getfilecon() should rather return NULL in
context pointer rat
On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote:
> To gnulib guys: I haven't done proper analysis yet. Is the
> gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib'
> dependant project? If yes, could we possibly at least set the ARFLAGS
> defau
On Wednesday 17 of June 2015 09:22:31 Pavel Raiskup wrote:
> Not sure whether some review has been done, so pinging once more to get
> some attention. Otherwise I'll probably push those changes.
OK, I updated the patches a bit more and now just holding them in
praiskup-ARFLAGS branch
any principal/technical
mistake I'll be able to.
Or do you think that this is unacceptable in general?
Thank you,
Pavel
>From aa80da8643a3c3025b547df765886f4c5c2dc7a4 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup
Date: Mon, 6 Aug 2012 13:15:16 +0200
Subject: [PATCH
any principal/technical
mistake I'll be able to.
Or do you think that this is unacceptable in general?
Thank you,
Pavel
>From aa80da8643a3c3025b547df765886f4c5c2dc7a4 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup
Date: Mon, 6 Aug 2012 13:15:16 +0200
Subject: [PATCH
nded attributes calls.
This is my first gnulib proposal - please, forgive me if I made any
mistake. I tried inspire with selinux-at module and others as much as
possible. But I'll be happy to repair any possible problem.
Pavel
>From b00fff657574e7ca98336af9a35d672d349dc9be Mon Sep 17 00:
34 matches
Mail list logo
