Re: T040 fails on Fedora 39 rebuild

2023-08-15 Thread David Bremner
David Bremner  writes:

> David Bremner  writes:
>
>> Michael J Gruber  writes:
>>
>>> At first I thought we (notmuch) might have a flushing problem or such,
>>> which we should prevent. But this clearly looks like a glib2
>>> regression now which caused others' CI to fail, too. At least you're
>>> prepared in case of incoming reports now ;-)
>>
>> I am seeing related (but less obnoxious) failures with glib 2.77.1 and
>> 2.77.2: namely the comment at the beginning of the file is gone and the
>> blank lines between groups are gone. Ignoring whitespace variance is
>> easy enough, but the missing comment at the beginning indicates either a
>> glib regression or notmuch doing it wrong.
>>
>
> Seems like a glib regression, unless there is something forbidden about
> the following. Sigh, I guess I need to register for an account to report
> a glib bug.

https://gitlab.gnome.org/GNOME/glib/-/issues/3078
___
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]


Re: T040 fails on Fedora 39 rebuild

2023-08-15 Thread David Bremner
David Bremner  writes:

> Michael J Gruber  writes:
>
>> At first I thought we (notmuch) might have a flushing problem or such,
>> which we should prevent. But this clearly looks like a glib2
>> regression now which caused others' CI to fail, too. At least you're
>> prepared in case of incoming reports now ;-)
>
> I am seeing related (but less obnoxious) failures with glib 2.77.1 and
> 2.77.2: namely the comment at the beginning of the file is gone and the
> blank lines between groups are gone. Ignoring whitespace variance is
> easy enough, but the missing comment at the beginning indicates either a
> glib regression or notmuch doing it wrong.
>

Seems like a glib regression, unless there is something forbidden about
the following. Sigh, I guess I need to register for an account to report
a glib bug.

#include 
#include 
#include 
#include 

int main(int argc, char** argv){
  GKeyFile *file;
  size_t length;
  char *data, *filename;
  GError *error = NULL;
  
  file = g_key_file_new ();
  g_key_file_set_comment (file, NULL, NULL, "top comment", NULL);
  g_key_file_set_value (file, "section", "dummy_key", "dummy_val");
  g_key_file_remove_key (file, "section", "dummy_key", NULL);
  g_key_file_set_comment (file,"section",NULL, "section comment",NULL);

  data = g_key_file_to_data (file, &length, NULL);
  if (data == NULL) {
fprintf (stderr, "Out of memory.\n");
return 1;
  }

  puts(data);
  
}
___
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]


Re: T040 fails on Fedora 39 rebuild

2023-07-20 Thread Michael J Gruber
Am Fr., 21. Juli 2023 um 03:40 Uhr schrieb David Bremner :
>
> Michael J Gruber  writes:
>
> > I'm not sure we should or can work around 2.77.0's behaviour. (It
> > might get triggered by the add/remove trick.)
>
> Will FC39 definitely ship with 2.77.0 ?

There is still plenty of time, so I hope that 2.77.1 will land soon
and I can prod them to carry that (or the fix). If it lands the Fedora
notmuch rebuild against it is in my hands.

At first I thought we (notmuch) might have a flushing problem or such,
which we should prevent. But this clearly looks like a glib2
regression now which caused others' CI to fail, too. At least you're
prepared in case of incoming reports now ;-)

Cheers
Michael
___
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]


Re: T040 fails on Fedora 39 rebuild

2023-07-20 Thread David Bremner
Michael J Gruber  writes:

> I'm not sure we should or can work around 2.77.0's behaviour. (It
> might get triggered by the add/remove trick.)

Will FC39 definitely ship with 2.77.0 ?
___
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]


Re: T040 fails on Fedora 39 rebuild

2023-07-20 Thread Michael J Gruber
Am Do., 20. Juli 2023 um 20:54 Uhr schrieb Michael J Gruber
:
>
> Hi there,
>
> funny failures again during the mass rebuild for the (not quite yet)
> upcoming Fedora rebuild. This test passed just a few weeks ago, so the
> failure is related to something else changing. But still it shows that
> the order in which `notmuch config` produces new config can depend on
> something else. It looks a bit like a buffering problem, but what do I
> know ... In any case, this is with notmuch 0.37, and I did not see any
> commit in master which could change that.
>
> I vaguely remember we had g_key_file ordering issues before - maybe in
> another project?
>
> The group comment for the next group is written too early, or the keys
> for the current group are written too late. This results in a
> functionally equivalent config with "misplaced" comments.
>
> Test still passes on Fedora 38. Glib2 versions are:
>
> 2.76.4-1.fc38
> 2.77.0-6.fc39

In fact, glib2 may come with a fix when 2.77.1 is released:

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3380

I'm not sure we should or can work around 2.77.0's behaviour. (It
might get triggered by the add/remove trick.)

Cheers
Michael
___
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]