Re: [ITP] neomutt
On 01/28/2018 03:43 PM, Jon Turney wrote: On 28/01/2018 11:38, Federico Kircheis wrote: Name: Federico Kircheis Package: neomutt Done Uploaded.
Re: stunnel 5.44 build fails
On 1/29/2018 3:32 PM, Andrew Schulman wrote: Prior to stunnel 5.42, I could build stunnel in Cygport with no src_compile function, just CYGCONF=--disable-fips Beginning with stunnel 5.42, the build fails with errors about "possibly undefined macro" AC_MSG_NOTICE and AC_DEFINE: I don't know why this is happening, but... configure.ac:9: error: version mismatch. This is Automake 1.15.1, configure.ac:9: but the definition used by this AM_INIT_AUTOMAKE configure.ac:9: comes from Automake 1.15. You should recreate configure.ac:9: aclocal.m4 with aclocal and run automake again. you've patched src/Makefile.am, causing src/Makefile to run automake. If you drop stunnel-ldflags.patch and just patch src/Makefile.in as you did for 5.42 in stunnel-5.42-1.src.patch, I think you should be OK. Ken
stunnel 5.44 build fails
Prior to stunnel 5.42, I could build stunnel in Cygport with no src_compile
function, just
CYGCONF=--disable-fips
Beginning with stunnel 5.42, the build fails with errors about "possibly
undefined macro" AC_MSG_NOTICE and AC_DEFINE:
$ cygport stunnel.cygport build
>>> Compiling stunnel-5.44-1.x86_64
autoreconf-2.69: Entering directory `.'
autoreconf-2.69: configure.ac: not using Gettext
autoreconf-2.69: running: aclocal --force -I m4
autoreconf-2.69: configure.ac: tracing
autoreconf-2.69: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'auto'.
libtoolize: copying file 'auto/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf-2.69: running: /usr/bin/autoconf-2.69 --force
configure.ac:4: error: possibly undefined macro: AC_MSG_NOTICE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:23: error: possibly undefined macro: AC_DEFINE
autoreconf-2.69: /usr/bin/autoconf-2.69 failed with exit status: 1
*** ERROR: autoreconf failed
Nice. So I tried adding a custom src_compile:
src_compile ()
{
cd "${B}"
cygconf
cygmake
}
But then although configure completes, the build fails with
configure.ac:9: error: version mismatch. This is Automake 1.15.1,
configure.ac:9: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:9: comes from Automake 1.15. You should recreate
configure.ac:9: aclocal.m4 with aclocal and run automake again.
The full build log is below.
Can someone please suggest how to get past this? autoconf and automake are
mysteries to me.
Thanks,
Andrew
$ cygport stunnel.cygport build
>>> Compiling stunnel-5.44-1.x86_64
/home/ASchulma/dev/cygwin/stunnel/stunnel-5.44-1.x86_64/src/stunnel-5.44/configure
--srcdir=/home/ASchulma/dev/cygwin/stunnel/stunnel-5.44-1.x86_64/src/stunnel-5.44
--prefix=/usr -
-exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/stunnel --htmldir=/usr/share/doc/stunnel/html -C
--disable-fips
configure: loading site script /usr/share/config.site
configure: creating cache config.cache
configure: initialization
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-unknown-cygwin
checking host system type... x86_64-unknown-cygwin
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether make sets $(MAKE)... (cached) yes
checking whether make supports nested variables... (cached) yes
configure: thread model
checking for a sed that does not truncate output... /usr/bin/sed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking whether gcc is Clang... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... no
configure: PTHREAD thread model detected
configure: compiler/linker flags
checking whether C compiler accepts -Wall... yes
checking whether C compiler accepts -Wextra... yes
checking whether C compiler accepts -Wpedantic... yes
checking whether C compiler accepts -Wformat=2... yes
checking whether C compiler accepts -Wconversion... yes
checking whether C compiler accepts -Wno-long-long... yes
checking whether C compiler accepts -Wno-deprecated-declarations... yes
checking whether C compiler accepts -fPIE... yes
checking whether C compiler accepts -fstack-protector... yes
checking whether the linker accepts -fPIE... yes
checking whether the linker accepts -pie... yes
checking whether the linker accepts -Wl,-z,relro... no
checking whether the linker accepts -Wl,-z,now... no
checking whether the linker accepts -Wl,-z,noexecstack... no
checking whether C compiler accepts -D_FORTIFY_SOURCE=2... yes
configure:
Re: setup 2.885 release candidate - please test
Jon Turney writes: > Since this contains many internal changes, I think this could use some > wider testing before being deployed. Please test and report any > problems here. I've built these myself, but I don't think that changes anything below. > User visible changes: > - 'Current' is replaced by 'Best' (which is slightly different in ways > it's difficult to summarize briefly) and 'Sync' (which exposes the > --force-current option through the UI). These are modified by a > 'Test' checkbox, which allows test packages to be used. I am always running setup with options to install a selected category w/ orphan removal and removal of non-selected packages. The selected category comprises _all_ packages that are supposed to be installed, so no dependencies need to be found. In order to see what's going on I also selected chooser mode (the normal install just does whatever it's told to do). That still works apparently, but whenever I click anywhere to change the mode from "Best" to something else and then back the transaction list gets emptied. As I said, I normally don't do this and clicking on those buttons serves no useful purpose for me in that situation, but I think the result is still wrong. I think that maybe the command line parameters are forgotten when doing this. > - The "prereq" page showing dependencies which will be added is > replaced by "problems" page showing problems found by the dependency > solver, with default solutions. > - A "confirm" page is added showing all the changes which will be made. I've not actually commenced the installation yet due to other things I want to fix first, so I can't say whether these two pages work. I guess I should not see them with my normal install script. The interesting part would be if they are skipped when non-interactive mode is given and there was something to add due to dependencies? > - Add support for 'depends2: package (relation version) [...]', in a > version section in setup.ini Those lines don't seem to get generated for all packages yet. I currently merge with requires: to produce a working setup.ini re-write and will switch to using requires: when I find no depends2:. Can I assume that all versions have a depends2: line when I find one for [curr]? I don't like the syntax with the commas, could we just drop the space between the package name and the paren for the version expression and keep the version-relations separated by plain whitespace? > - Add support for 'obsoletes:' in setup.ini, likewise These don't appear to be produced by calm yet. Also, it would be useful if the obsoleted package showed the replacement package more explicitly, so maybe "obsoleted-by:" instead of requires:/depends2: > - Add support for 'replace-versions:' in a package section setup.ini, > to indicate problematic versions. Any examples for this yet? As you surely know, all the new syntax is not yet described in https://sourceware.org/cygwin-apps/setup.ini.html Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
