Re: [PATCH] build: drop support for gmime-2.6
On Wed, May 01 2019, David Bremner wrote: > I was thinking of a minimal change now, so it isn't blocking other > things, and then a gradual cleanup. just go for it. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] build: drop support for gmime-2.6
>>> I was thinking of a minimal change now, so it isn't blocking other >>> things, and then a gradual cleanup. >> >> just go for it. > > You mean this patch, or the other more extensive patch that someone (TM) > has to write? Go for the full cleanup all at once. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] build: drop support for gmime-2.6
"Rollins, Jameson" writes: > On Wed, May 01 2019, David Bremner wrote: >> I was thinking of a minimal change now, so it isn't blocking other >> things, and then a gradual cleanup. > > just go for it. You mean this patch, or the other more extensive patch that someone (TM) has to write? d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] build: drop support for gmime-2.6
Tomi Ollila writes: >> -# we need to have a version >= 2.6.5 to avoid a crypto bug. We need >> -# 2.6.7 for permissive "From " header handling. >> -GMIME_MINVER=2.6.7 >> GMIME3_MINVER=3.0.3 > > This series looks good, but why change GMIME_MINVER to GMIME3_MINVER ? > Both existed before, and I just dropped one. It helped catch a few places where GMIME_MINVER was still used. But maybe you're right, maybe that's too lazy. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] build: drop support for gmime-2.6
Daniel Kahn Gillmor writes: > On Wed 2019-05-01 07:46:43 -0300, David Bremner wrote: >> GMime 3.0 is over 2 years old now, and 2.6 has been deprecated in >> notmuch for about 1.5 years. > > I was just looking at this change myself. > > As a gmime maintainer in debian, I'd love to see it happen, but i think > the right way to do that is to prune/reverse many of the versioned > translations in util/gmime-extra.h, so that we're using the "native" > gmime 3.0 API, rather than a mishmash of the 2.6 and 3.0 API. > > And we should probably tear out all the #if (GMIME_MAJOR_VERSION < 3) > stanzas in the source as well. > > --dkg I was thinking of a minimal change now, so it isn't blocking other things, and then a gradual cleanup. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] build: drop support for gmime-2.6
On Wed 2019-05-01 07:46:43 -0300, David Bremner wrote: > GMime 3.0 is over 2 years old now, and 2.6 has been deprecated in > notmuch for about 1.5 years. I was just looking at this change myself. As a gmime maintainer in debian, I'd love to see it happen, but i think the right way to do that is to prune/reverse many of the versioned translations in util/gmime-extra.h, so that we're using the "native" gmime 3.0 API, rather than a mishmash of the 2.6 and 3.0 API. And we should probably tear out all the #if (GMIME_MAJOR_VERSION < 3) stanzas in the source as well. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] build: drop support for gmime-2.6
On Wed, May 01 2019, David Bremner wrote: > GMime 3.0 is over 2 years old now, and 2.6 has been deprecated in > notmuch for about 1.5 years. > --- > > Thanks to Rob Browning, I realized that the gzipped-mail-file series I > have recently posted does not compile with GMime 2.6. This made me > think that maybe it's the right time to drop support for GMime > 2.6. > > Travis will need some fix if we take this step. The alternative is to > add more gmime-2.6 compatibility code. I think the particular case > that I hit with the gzip patches (g_mime_stream_fs_open) is not that > hard to paper over, but I do wonder if that's a good use of our time > as developers. > > I guess we could run a GMime PPA. Or we could migrate to some other CI > system. So far the latter is heavy on the talk, light on the action. > > configure | 18 ++ > 1 file changed, 2 insertions(+), 16 deletions(-) > > diff --git a/configure b/configure > index 5e7e5aa9..4163b584 100755 > --- a/configure > +++ b/configure > @@ -489,9 +489,6 @@ EOF > rm -rf test.db _default_backend _default_backend.cc > fi > > -# we need to have a version >= 2.6.5 to avoid a crypto bug. We need > -# 2.6.7 for permissive "From " header handling. > -GMIME_MINVER=2.6.7 > GMIME3_MINVER=3.0.3 This series looks good, but why change GMIME_MINVER to GMIME3_MINVER ? > > printf "Checking for GMime development files... " > @@ -502,17 +499,6 @@ if pkg-config --exists "gmime-3.0 > $GMIME3_MINVER"; then > gmime_ldflags=$(pkg-config --libs gmime-3.0) > gmime_major=3 > have_gmime_session_keys=1 > -elif pkg-config --exists "gmime-2.6 >= $GMIME_MINVER"; then > -printf "Yes (2.6).\n" > -have_gmime=1 > -gmime_cflags=$(pkg-config --cflags gmime-2.6) > -gmime_ldflags=$(pkg-config --libs gmime-2.6) > -gmime_major=2 > -if pkg-config --exists "gmime-2.6 >= 2.6.21"; then > -have_gmime_session_keys=1 > -else > -have_gmime_session_keys=0 > -fi > else > have_gmime=0 > have_gmime_session_keys=0 > @@ -788,7 +774,7 @@ EOF > echo > fi > if [ $have_gmime -eq 0 ]; then > - echo " GMime 2.6 library >= $GMIME_MINVER" > + echo " GMime 3.0 library >= $GMIME3_MINVER" > echo " (including development files such as headers)" > echo " https://github.com/jstedfast/gmime/; > echo > @@ -810,7 +796,7 @@ case a simple command will install everything you need. > For example: > > On Debian and similar systems: > > - sudo apt-get install libxapian-dev libgmime-2.6-dev libtalloc-dev > zlib1g-dev > + sudo apt-get install libxapian-dev libgmime-3.0-dev libtalloc-dev > zlib1g-dev > > Or on Fedora and similar systems: > > -- > 2.20.1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch