Re: Using ZChunk for setup…
Jon Turney writes: > How would the signature be checked? Is it for the reconstructed full > zchunk file? The signature should be for the full (reconstructed) file I think, the individual chunks of the changeset are locked in by SHA256 checksums anyway. > One slightly related issue which it would be good to address if > possible when adding this is that rsync is only file-atomic, not > repo-atomic, so we may get a compressed ini file and signature which > don't match as they are different moments in time during an update. I > think currently no-one notices this if it happens, as setup silently > falls back to an older compression type, but it would be nice to stop > generating those eventually. One of the things I am still thinking about is switching from the ini format to YAML. In this case the signature could/should be part of the data structure (JOSE/COSE style), so you'd only ever have to look at a single file and it wouldn't matter how you got it together. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Using ZChunk for setup…
On 09/01/2022 11:05, Achim Gratz wrote: I've been experimenting with ZChunk with the idea of eventually using it for setup: https://www.jdieter.net/posts/2018/05/31/what-is-zchunk/ https://github.com/zchunk/zchunk The chunked ini file is ~10…15% larger than the original (after compression). In order to minimize the overhead, I've re-arranged the package entries to have one chunk for every source package. The actual benefit is that the typical download size reduces to less than 5% of the original. Two examples of much longer timespans between updates are provided at the end, which would still download only around a third of the original: [...] WDYT? This seems like a nice thing to have. How would the signature be checked? Is it for the reconstructed full zchunk file? One slightly related issue which it would be good to address if possible when adding this is that rsync is only file-atomic, not repo-atomic, so we may get a compressed ini file and signature which don't match as they are different moments in time during an update. I think currently no-one notices this if it happens, as setup silently falls back to an older compression type, but it would be nice to stop generating those eventually.
Re: [ITP] biosig [was: Re: newcomer issues when packaging biosig, stimfit, etc.]
On 16.01.2022 23:13, Alois Schlögl wrote:
Dear Marco,
attached is the revised version.
In addition, I'm trying also to include the python39-biosig package.
Could you please check whether this would work ?
Cheers,
Alois
Hi Alois,
I finally had some time to work on the package.
See attachment.
Instead of complicating the cygport I decided
to adapt the Makefile.in to be Cygwin aware,
so using a much simple biosig.cygport
It is not perfect, and you could need to adopt
other parts to make the overall consistent.
A better solution will be to use not only Autoconf but also
also Automake so that all platforms will be managed in the same way,
without the need of a lot of customization.
Alternative you can use cmake to obtain a similar results.
Now the DLL's are respecting the Cygwin format
and also the Python 3.9 package is available.
$ nice cygport biosig.cygport list |grep dll
/usr/bin/cygbiosig-3.dll
/usr/bin/cygphysicalunits-3.dll
/usr/lib/libbiosig.dll.a
/usr/lib/libphysicalunits.dll.a
/usr/lib/python3.9/site-packages/biosig.cpython-39-x86_64-cygwin.dll
$ nice cygport biosig.cygport list |grep usr/bin
/usr/bin/bin2rec
/usr/bin/biosig2gdf.exe
/usr/bin/biosig_fhir.exe
/usr/bin/cygbiosig-3.dll
/usr/bin/cygphysicalunits-3.dll
/usr/bin/heka2itx
/usr/bin/physicalunits.exe
/usr/bin/rec2bin
/usr/bin/save2aecg
/usr/bin/save2gdf.exe
/usr/bin/save2scp
please check that I have not missed something
and inadvertently crippled some of the utility.
It seems that the build is unable to use the
libcholmod-devel
libtinyxml2-devel
libraries. I suspect the configure is missing something
I left the static libraries, but they should be superflous
as the shared libs are present.
Regards
Marco--- origsrc/biosig-2.3.3/biosig4c++/Makefile.in 2021-08-13 11:17:15.0
+0200
+++ src/biosig-2.3.3/biosig4c++/Makefile.in 2022-01-22 15:13:42.122963600
+0100
@@ -137,6 +137,7 @@ else
endif
SONAMEVERSION ?= 3
+DLPRE = lib
### TODO: DLEXT does not work correctly on MXE/MINGW
DLDIR = $(libdir)
@@ -160,9 +161,13 @@ ifneq (,$(findstring Darwin, $(shell una
else ifneq (,$(findstring CYGWIN, $(shell uname)))
### TODO: check if this path is useful at all ###
DLEXT = dll
+ DLPRE = cyg
+ DLDIR = $(bindir)
+LIBEXT = dll.a
+BINEXT = .exe
LD = $(CXX)
LDLIBS+= -liconv -lstdc++
- FULLDLEXT = ${SONAMEVERSION}.dll
+ FULLDLEXT = -${SONAMEVERSION}.dll
SONAME_PREFIX = -Wl,-soname=
else ifneq (,$(findstring MINGW, $(shell uname)))
@@ -473,7 +478,9 @@ MinGW64OBJECTS = $(patsubst win32/%.obj
TARGET = save2gdf libbiosig.a
LIB_OBJECTS = libbiosig.a libgdf.a libphysicalunits.a libbiosig.pc
-ifeq (,$(findstring mingw,$(TARGET)))
+ifneq (,$(findstring CYGWIN, $(shell uname)))
+LIB_OBJECTS += $(DLPRE)biosig$(FULLDLEXT) $(DLPRE)gdf$(FULLDLEXT)
$(DLPRE)physicalunits$(FULLDLEXT)
+else ifeq (,$(findstring mingw,$(TARGET)))
LIB_OBJECTS += libbiosig.$(DLEXT) libgdf.$(DLEXT) libphysicalunits.$(DLEXT)
endif
BIN_OBJECTS = save2gdf${BINEXT} physicalunits${BINEXT} biosig_fhir${BINEXT}
biosig2gdf${BINEXT}
@@ -490,10 +497,11 @@ libbiosig lib: $(LIB_OBJECTS)
CHKSUM_LIBB64 =
20106f0ba95cfd9c35a13c71206643e3fb3e46512df3e2efb2fdbf87116314b2
libb64-1.2.1.zip:
curl -SLO
https://downloads.sourceforge.net/project/libb64/libb64/libb64/libb64-1.2.1.zip
- test $(shell sha256sum libb64-1.2.1.zip | cut -d " " -f 1) =
$(CHKSUM_LIBB64) || rm libb64-1.2.1.zip
+# test $(shell sha256sum libb64-1.2.1.zip | cut -d " " -f 1) =
$(CHKSUM_LIBB64) || rm libb64-1.2.1.zip
libb64-1.2.1/src/cencode.c: libb64-1.2.1.zip
- test $(shell sha256sum libb64-1.2.1.zip | cut -d " " -f 1) =
$(CHKSUM_LIBB64) && unzip -o libb64-1.2.1.zip -d .
+# test $(shell sha256sum libb64-1.2.1.zip | cut -d " " -f 1) =
$(CHKSUM_LIBB64) && unzip -o libb64-1.2.1.zip -d .
+ unzip -o libb64-1.2.1.zip -d .
touch $@
vpath %.c ./:./t210:./t220:./t240:./test0:./src:./mma
@@ -668,7 +676,7 @@ win32: mexw32 win32mma
win64/%.exe: %.c
$(MinGW64CXX) $(DEFINES) $(MinGW64CFLAGS) "$<" $(MinGW64LIBS) -o "$@"
win64/physicalunits.exe: pu.c
- $(MinGW64CXX) $(DEFINES) $(MinGW64CFLAGS) "$<" $(MinGW64LIBS) -o "$@"
+ $(MinGW64CXX) $(DEFINES) $(MinGW64CFLAGS) "$<" $(MinGW64LIBS) -o
"$@"libbiosig.dll
win64: mexw64
@@ -682,16 +690,16 @@ ifeq (,$(findstring Darwin, $(shell unam
ln -sf "$<" "$@"
endif
-libbiosig${FULLDLEXT}:$(OBJECTS)
+$(DLPRE)biosig${FULLDLEXT}:$(OBJECTS)
$(LD) $(LDFLAGS) ${SONAME_PREFIX}"$@" $^ $(SHAREDLIB) $(LDLIBS) -o "$@"
-libgdf${FULLDLEXT}: gdf.o gdftime.o physicalunits.o getlogin.o
+$(DLPRE)gdf${FULLDLEXT}: gdf.o gdftime.o physicalunits.o getlogin.o
$(LD) $(LDFLAGS) ${SONAME_PREFIX}"$@" $^ $(SHAREDLIB) $(LDLIBS) -o "$@"
-libgdftime${FULLDLEXT}:gdftime.o
+$(DLPRE)gdftime${FULLDLEXT}:gdftime.o
$(LD) $(LDFLAGS) ${SONAME_PREFIX}"$@" $^ $(SHAREDLIB)
Re: CI system cryptic error
On 22/01/2022 05:34, Marco Atzeri wrote: On 21.01.2022 17:03, Hamish McIntyre-Bhatty wrote: On 21/01/2022 14:06, Jon Turney wrote: On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 Yep, sorry I forgot to add the link. In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. No I did a local i686 build too, and it was fine... This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why! Hmm, very strange. Maybe just a freak error? I'll try building again, seeing as I have a new version now anyway, and see what happens. I guess seeing as 64-bit builds are the future for Cygwin, I'll just ignore this issue if it happens again, as long as I check the 32-bit builds I built work. Hamish I saw something similar but I do not remember the details. Cygport is looking for something that has changed name or it is not available anymore. Probably the old name is still used by Python2 and it is the reason why the error seldom show up in local build of maintainers. cygport --debug should provide some hints Good idea, I'll try that, and I'll also remove python 2 from my cygwin install if I can. Cheers, Hamish
