Re: [ITP] biosig [was: Re: newcomer issues when packaging biosig, stimfit, etc.]
Am 1/15/22 um 19:01 schrieb Marco Atzeri:
On 14.01.2022 22:48, Alois Schlögl wrote:
Am 1/14/22 um 11:09 schrieb Marco Atzeri:
On 12.01.2022 23:59, Alois Schlögl wrote:
I was playing with the CMakeList.txt to see if that was more easy
than your deep patch of the upstream Makefile's
I'm afraid that this "deep patch" is just an accidental artifact.
When running configure, all Makefile are rebuild from Makefile.in,
The Makefile(s) were packaged just by accident in v2.3.3.
But in fact these Makefiles should not have part of the released
package.
add DIFF_EXCLUDES="Makefile" to avoid the artifact
Cheers,
Alois
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
# package name
NAME="biosig"
VERSION=2.3.3
RELEASE=1
# .hint generation
CATEGORY="Libs,Science"
SUMMARY="Tools for biomedical signal processing."
DESCRIPTION="BioSig is an open source software library for
biomedical signal processing, featuring for example the
analysis of biosignals such as the electroencephalogram (EEG),
electrocorticogram (ECoG), electrocardiogram (ECG),
electrooculogram (EOG), electromyogram (EMG), respiration,
and so on. Major application areas are: Neuroinformatics,
brain-computer interfaces, neurophysiology, psychology, c
ardiovascular systems and sleep research. The aim of the
BioSig project is to foster research in biomedical signal
processing by providing open source software tools for many
different applications. Generally, many concerns have to be a
ddressed in this scientific field. BioSig handles this by providing
solutions for data acquisition, artifact processing, quality control,
feature extraction, classification, modeling, data visualization, etc. "
# source and patch files
SRC_URI="https://sourceforge.net/projects/biosig/files/BioSig%20for%20C_C%2B%2B/src/biosig-2.3.3.src.tar.gz";
# PATCH_URI="biosig-2.3.3-fix-build.patch"
# use the standard src_compile, src_install and src_test
PKG_NAMES="libbiosig libbiosig-devel biosig-tools python39-biosig"
# PKG_NAMES="libbiosig libbiosig-devel biosig-tools"
biosig_tools_CONTENTS="
usr/bin/save2gdf.exe
usr/bin/physicalunits.exe
usr/bin/biosig2gdf.exe
usr/share/man/man1/save2gdf.1.gz
usr/share/man/man1/biosig2gdf.1.gz
usr/share/man/man1/biosig_fhir.1.gz
usr/share/man/man1/physicalunits.1.gz
usr/share/doc/biosig/COPYING
usr/share/doc/biosig/README
"
# not included yet
# usr/share/man/biosig_fhir.1 usr/share/man/sigviewer.1
libbiosig_CONTENTS="
usr/bin/libbiosig.dll
usr/bin/libphysicalunits.dll
"
libbiosig_devel_CONTENTS="
usr/include/biosig-dev.h
usr/include/biosig.h
usr/include/biosig2.h
usr/include/gdftime.h
usr/include/physicalunits.h
usr/include/biosig-network.h
usr/include/mdc_ecg_codes.h
usr/lib/libbiosig.a
usr/lib/libbiosig.dll.a
usr/lib/libphysicalunits.a
usr/lib/libphysicalunits.dll.a
usr/lib/pkgconfig/libbiosig.pc
"
#python3-biosig_CONTENTS="
# dist/Biosig-2.3.3-cp39-cp39-cygwin_3_3_3_x86_64.whl
#"
DIFF_EXCLUDES="depend Makefile"
# use not standard src_compile, src_install and src_test
src_compile() {
cd ${S}
lndirs
cd ${B}
cygautoreconf
cygconf # --prefix=/usr
# libbiosig
cygmake lib
# biosig-tools w/o biosig_fhir
cygmake -C biosig4c++ save2gdf physicalunits biosig2gdf
# python3-biosig
cygmake -C biosig4c++/python wheel
# cd ${B}/biosig4c++/python/
# python3_distutils_compile bdist_wheel
# python3_wheel_compile
}
src_install() {
cd ${S}
doinclude ${S}/biosig4c++/*.h
dobin ${B}/biosig4c++/save2gdf.exe
# dobin ${B}/biosig4c++/biosig_fhir.exe
dobin ${B}/biosig4c++/biosig2gdf.exe
dobin ${B}/biosig4c++/physicalunits.exe
dobin ${B}/biosig4c++/libbiosig.dll
dobin ${B}/biosig4c++/libphysicalunits.dll
dolib ${B}/biosig4c++/libbiosig.dll.a
dolib ${B}/biosig4c++/libbiosig.a
dolib ${B}/biosig4c++/libphysicalunits.dll.a
dolib ${B}/biosig4c++/libphysicalunits.a
dopkgconfig ${B}/biosig4c++/libbiosig.pc
# doman ${S}/biosig4c++/doc/bin2rec.1
doman ${S}/biosig4c++/doc/biosig2gdf.1
doman ${S}/biosig4c++/doc/biosig_fhir.1
doman ${S}/biosig4c++/doc/physicalunits.1
doman ${S}/biosig4c++/doc/save2gdf.1
# dowheel
${B}/biosig4c++/python/dist/Biosig-2.3.3-cp39-cp39-cygwin_3_3_3_x86_64.whl
}
src_test() {
cd ${B}
biosig4c++/physicalunits.exe
biosig4c++/save2gdf.exe --help
# biosig4c++/biosig_fhir.exe --help
python -c "import biosig"
}
# comment
sdesc: "Tools for biomedical signal processing"
ldesc: "Library for biomedical signal processing,
featuring for example the analysis of biosignals such
as the electroencephalogram (EEG), elec
Re: [PATCH setup] Show a MessageBox warning if running on a deprecated Windows version
On 16/01/2022 13:46, Adam Dinwoodie wrote: On Fri, Jan 14, 2022 at 12:45:06PM +0100, Corinna Vinschen wrote: On Jan 14 10:54, Adam Dinwoodie wrote: On Fri, 14 Jan 2022 at 09:05, Corinna Vinschen wrote: On Jan 13 15:13, Jon Turney wrote: Show a MessageBox warning if we are running on a Windows version which we have deprecated Cygwin support for: - Windows 6.0 (Windows Vista, Windows Server 2008) - 32-bit Windows This warning can be disabled with '--allow-unsupported-windows'. --- Notes: Not sure if this is needed, or maybe this is just annoying to the ~3% of users who are running effected OSes. But maybe we want to annoy them into doing something about it? Question is, how often should setup show this message? Every time might really be a bit annoying. Some kind of "I saw it, now leave me alone, at least for a while" kind of function would be great. Eh. The installer tries to add icons to my desktop every time I run it unless I provide a command-line argument every time. This behaviour seems no more or less annoying to me, and I think having users see that warning is much more important than adding a desktop icon. Point. Perhaps more constructively: I've become inured to the bits of setup's behaviour that I find annoying, and I've created my own workarounds (specifically, a bash function that wraps setup and automatically provides a bunch of arguments, including `-d` to avoid adding icons I don't want). I expect most people who are using setup have also become inured to these annoyances, and I don't think adding this additional warning is a significant additional annoyance. That said, just because I've become inured to these annoyances, doesn't mean we* couldn't do better. In particular, I think a lot of the parts of the setup UI you have to go through every time could more usefully be hidden after a user has gone through them once, and only displayed again if (a) the user requested that with a command-line option, (b) the options have legitimately changed, or possibly (c) the user clicks (say) an "Advanced mode" button on the first page of the installer. In particular, I expect the installer would be that bit friendlier to most users if the default behaviour were as if `-Mn` were specified by default every time after the first run. This is obviously well outside the scope of the immediate conversation, but I thought it worth revisiting the topic with a more constructive view, rather than my initial slightly grumpy reaction. Adam * I say "we" here; I sadly do not have the bandwidth for committing to working on even small enhancements to setup's usability. The perennial open source issue: someone has to do it, and I have far too many other things to spend time on... This reminds me: It's probably useful for me to support 32-bit even after Cygwin no longer does for my commercial project(s). Which probably means I should release said package soon (I couldn't get the rebase to work on 32-bit before, will ask another question soon. Are all the 32-bit packages going offline after support ends or will it remain as a kind of graveyard? Hamish McIntyre-Bhatty
ansible
There was a request on IRC to update the ansible package. I've had a quick look, the tentative result is on the playground branch: https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/ansible.git;a=shortlog;h=refs/heads/playground As mentioned by Yaakov, I switched over to ansible-core, updated the patches and made some changes so that th CI would have a chance to build the package. Some of the necessary packages are missing for python39 so I had to keep this at python37 and one (python37-straight.plugin) doesn't currently exist at all. The latter may not actually be needed anymore, but the package build doesn't work anyway. Someone with more knowledge of python would need to look at where exactly the problem is (the "packaging" module seems to be missing even though it's in the BUILD_REQUIRES) and provide a fix. 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: [PATCH setup] Show a MessageBox warning if running on a deprecated Windows version
On Fri, Jan 14, 2022 at 12:45:06PM +0100, Corinna Vinschen wrote: > On Jan 14 10:54, Adam Dinwoodie wrote: > > On Fri, 14 Jan 2022 at 09:05, Corinna Vinschen wrote: > > > On Jan 13 15:13, Jon Turney wrote: > > > > Show a MessageBox warning if we are running on a Windows version which > > > > we have deprecated Cygwin support for: > > > > > > > > - Windows 6.0 (Windows Vista, Windows Server 2008) > > > > - 32-bit Windows > > > > > > > > This warning can be disabled with '--allow-unsupported-windows'. > > > > --- > > > > > > > > Notes: > > > > Not sure if this is needed, or maybe this is just annoying to the > > > > ~3% of > > > > users who are running effected OSes. But maybe we want to annoy > > > > them > > > > into doing something about it? > > > > > > Question is, how often should setup show this message? Every time might > > > really be a bit annoying. Some kind of "I saw it, now leave me alone, > > > at least for a while" kind of function would be great. > > > > Eh. The installer tries to add icons to my desktop every time I run it > > unless I provide a command-line argument every time. This behaviour > > seems no more or less annoying to me, and I think having users see > > that warning is much more important than adding a desktop icon. > > Point. Perhaps more constructively: I've become inured to the bits of setup's behaviour that I find annoying, and I've created my own workarounds (specifically, a bash function that wraps setup and automatically provides a bunch of arguments, including `-d` to avoid adding icons I don't want). I expect most people who are using setup have also become inured to these annoyances, and I don't think adding this additional warning is a significant additional annoyance. That said, just because I've become inured to these annoyances, doesn't mean we* couldn't do better. In particular, I think a lot of the parts of the setup UI you have to go through every time could more usefully be hidden after a user has gone through them once, and only displayed again if (a) the user requested that with a command-line option, (b) the options have legitimately changed, or possibly (c) the user clicks (say) an "Advanced mode" button on the first page of the installer. In particular, I expect the installer would be that bit friendlier to most users if the default behaviour were as if `-Mn` were specified by default every time after the first run. This is obviously well outside the scope of the immediate conversation, but I thought it worth revisiting the topic with a more constructive view, rather than my initial slightly grumpy reaction. Adam * I say "we" here; I sadly do not have the bandwidth for committing to working on even small enhancements to setup's usability. The perennial open source issue: someone has to do it, and I have far too many other things to spend time on...
