[ITP] python-discid-1.1.0: Python binding of libdiscid by MusicBrainz
Hi I would like to contribute and maintain the 'python-discid' package: o https://python-discid.readthedocs.org (Homepage) o https://github.com/JonnyJD/python-discid/archive/v1.1.0.tar.gz (Download location) The package can be found in the following distros: o https://packages.debian.org/search?keywords=python-libdiscid o https://aur.archlinux.org/packages/python2-discid/ o http://software.opensuse.org/package/python-discid Here is the setup.hint file: --- ./setup.hint category: Python requires: python sdesc: Python binding of libdiscid by MusicBrainz ldesc: The main purpose is the calculation of an identifier for audio discs (Disc ID) to use for the MusicBrainz database. Additionally the disc MCN and track ISRCs can be extracted. For downloading wget -x -nH --cut-dirs=2 \ http://volkerzell.de/cygwin/ITP/python-discid/setup.hint \ http://volkerzell.de/cygwin/ITP/python-discid/python-discid-1.1.0-1-src.tar.xz \ http://volkerzell.de/cygwin/ITP/python-discid/python-discid-1.1.0-1.tar.xz \ Ciao Volker
Re: [HEADSUP] Moving setup sources to git
On Feb 9, 2015, at 9:24 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: I just created a git repo for setup: About blinkin’ time. But it should have been Fossil. ;)
[HEADSUP] Moving setup sources to git
Hi guys, please don't check in anything to the setup CVS repo anymore. I just created a git repo for setup: git clone cygwin.com:/git/cygwin-setup.git The old CVS repo should be treated as R/O. The new git repo should basically work now, but I'm not a git config guru, so if stuff is missing, I appreciate configuration help! Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbyLhiImqoc.pgp Description: PGP signature
Re: [HEADSUP] Moving setup sources to git
2015-02-09 17:24 GMT+01:00 Corinna Vinschen: please don't check in anything to the setup CVS repo anymore. I just created a git repo for setup: git clone cygwin.com:/git/cygwin-setup.git Just to let you know that the anonymous read-only access works: git clone git://cygwin.com/git/cygwin-setup.git But I tried to build setup and I have a problem with the dependencies. README says I need various mingw libs. But if IIRC mingw is not recommended anymore. I have installed mingw64 and the mingw64 variants of those libs. But there is no mingw64 variant of liblzma. I've installed all 5 packages containing liblzma, but configure seems to be unable to find it. Do I still need the original mingw to compile setup or is the README outdated? Regards, Frank
Re: perl-5.14.4
Corinna Vinschen writes: Would you mind to discuss your problem on the binutils mailing list? Hopefully they know if there's a way which preserves the info so that GDB doesn't fish in muddy waters. Looking at the traffic of the past few weeks on that list (consisting mostly of patches) I'm not sure it is the right venue… Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [HEADSUP] Moving setup sources to git
2015-02-09 20:46 GMT+01:00 Achim Gratz: HOW TO BUILD: - Setup should build out-of-the-box on any Cygwin environment that has all the required packages installed: - - mingw-gcc-g++ - make - - mingw-bzip2 - - mingw-libgcrypt-devel - - mingw-liblzma-devel - - mingw-zlib - - and all packages that are dependencies of the above, i.e. gcc-mingw-core, -mingw-runtime, binutils, w*api, etc. + - mingw64-gcc-g++ + - mingw64-bzip2 + - mingw64-libgcrypt + - mingw64-xz + - mingw64-zlib + - and all packages that are dependencies of the above - upx (optional) Thanks, mingw64-xz did the trick. Frank
Re: [ITP] python-discid-1.1.0: Python binding of libdiscid by MusicBrainz
On Mon, 2015-02-09 at 14:40 +0100, Dr. Volker Zell wrote:
Yaakov Selkowitz writes:
On Mon, 2015-02-09 at 09:51 +0100, vz...@volkerzell.de wrote:
category: Python
requires: python
sdesc: Python binding of libdiscid by MusicBrainz
ldesc: The main purpose is the calculation of an identifier for audio
discs (Disc ID) to use for the MusicBrainz database. Additionally
the disc MCN and track ISRCs can be extracted.
This module loads libdiscid via ctypes, so you need an explicit
REQUIRES=libdiscid-devel in your .cygport. With that change, GTG.
Shouldn't that be:
REQUIRES=libdiscid0
No. Our python packages include a patch so that
ctypes.util.find_library('foo') will 'dlltool -I /usr/lib/libfoo.dll.a'
in order to find the DLL name it should load. Therefore, python
packages which use find_library('foo') must REQUIRES libfoo-devel.
(BTW, think this is bad? On ELF platforms, find_library uses gcc -lfoo
and ldd to discover the SONAME.)
--
Yaakov
Re: perl-5.14.4
Corinna Vinschen writes: I think it's important to keep the information in sync while building the packages. A later rebase will break the connection between debug symbols and runtime symbols as well, obviously. Obviously? I have no indication that the debug information is damaged once it's been stripped off into a separate file. Which may be a hint on what rebase might do wrong. Maybe we should think of rebasing the actual binaries as well as their debugging counterparts to keep everything in sync, but that's a bit much effort... I may not understand what is really going on, but the way I see it, rebase does exactly that while the debug information is still part of the object file. It seems to do something extra or wrong, since objcopy will the not be able to copy out that information. Looking with objdump reveals the section is still there ans has contents, but it doesn't get associated with the code in the correct manner anymore. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: perl-5.14.4
On Feb 9 18:15, Achim Gratz wrote: Corinna Vinschen writes: I think it's important to keep the information in sync while building the packages. A later rebase will break the connection between debug symbols and runtime symbols as well, obviously. Obviously? I have no indication that the debug information is damaged once it's been stripped off into a separate file. Which may be a hint on what rebase might do wrong. What I mean is this. If the debug info file does not refer to the same addresses than the file in memory, then GDB doesn't resolve the symbols correctly. Maybe we should think of rebasing the actual binaries as well as their debugging counterparts to keep everything in sync, but that's a bit much effort... I may not understand what is really going on, but the way I see it, rebase does exactly that while the debug information is still part of the object file. It seems to do something extra or wrong, since objcopy will the not be able to copy out that information. Looking with objdump reveals the section is still there ans has contents, but it doesn't get associated with the code in the correct manner anymore. I'm not an expert on this stuff either, so I can just assume that the rebasing doesn't catch the debug info and that the debug info then points into nirvana. I also don't know if there's a way around that. Would you mind to discuss your problem on the binutils mailing list? Hopefully they know if there's a way which preserves the info so that GDB doesn't fish in muddy waters. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpMcETjX_k5i.pgp Description: PGP signature
Re: [HEADSUP] Moving setup sources to git
On Feb 9 20:46, Achim Gratz wrote: Frank Fesevur writes: README says I need various mingw libs. But if IIRC mingw is not recommended anymore. I have installed mingw64 and the mingw64 variants of those libs. But there is no mingw64 variant of liblzma. I've installed all 5 packages containing liblzma, but configure seems to be unable to find it. Do I still need the original mingw to compile setup or is the README outdated? I still carry the README patch below locally since it was not accepted Please apply. That should work, given the file perms on sware... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAlIQwo_jhS.pgp Description: PGP signature
Re: [HEADSUP] Moving setup sources to git
On 09/02/2015 19:46, Achim Gratz wrote: Frank Fesevur writes: README says I need various mingw libs. But if IIRC mingw is not recommended anymore. I have installed mingw64 and the mingw64 variants of those libs. But there is no mingw64 variant of liblzma. I've installed all 5 packages containing liblzma, but configure seems to be unable to find it. Do I still need the original mingw to compile setup or is the README outdated? I still carry the README patch below locally since it was not accepted the last time around and it will likely need a few changes to be up-to-date with today's reality. For instance libgetopt++ is now included in the tree, while I'd have preferred if it was a subtree or submodule, which is more closely in line with the state it had in CVS. --8---cut here---start-8--- README index b1586de..0499c6c 100644 @@ -3,33 +3,39 @@ for the Cygwin net releases. HOW TO BUILD: - Setup should build out-of-the-box on any Cygwin environment that has all the required packages installed: - - mingw-gcc-g++ - make - - mingw-bzip2 - - mingw-libgcrypt-devel - - mingw-liblzma-devel - - mingw-zlib - - and all packages that are dependencies of the above, i.e. gcc-mingw-core, -mingw-runtime, binutils, w*api, etc. + - mingw64-gcc-g++ + - mingw64-bzip2 + - mingw64-libgcrypt + - mingw64-xz + - mingw64-zlib + - and all packages that are dependencies of the above I'm not sure these are actually package names since they are missing the arch? - upx (optional) The following additional packages are required if building from CVS, not from a source tarball, or if you want to make changes to the build system. - recent autoconf - recent automake - recent libtool - flex - bison +Additionally, libgetopt++ (also available from the cygwin-apps CVS at +sourceware.org) must be available directly as a subdirectory +libgetopt++ within the setup source directory. It should be +automatically populated by CVS, but if you are using tools like +CVSgrab, you may need to fetch this yourself. + This doesn't make sense anymore. Build commands: 1) Configure using this option $ /path/to/setup/bootstrap.sh - This will automatically rebuild configure files and run configure in the - current directory. + This will automatically rebuild configure files and run configure + in the current directory. The current directory must be outside + the source tree. This isn't true.
Re: New xemacs 32bit package upload
On Mon, 2015-02-09 at 09:57 +0100, Dr. Volker Zell wrote: I finally uploaded the first xemacs package for cygwin 1.7 (32bit) and noticed that now the former test package 21.5.28-3 is listed as the latest version. Can somebody delete all the 21.5.28-3 related packages from the release area ? xemacs, xemacs-tags and xemacs-emacs-common. Done. But note that maintainers should be able to do this yourself as well for their packages: https://sourceware.org/cygwin-apps/package-upload.html -- Yaakov
Re: Setup patch to keep test version if test version installed
On Feb 8 21:24, Achim Gratz wrote: Corinna Vinschen writes: Please apply. Done. The notice via cygwin-apps-cvs was lost while the mailer was having trouble to recognize the cygwin.com mailing lists. The patch is in, that's the important part :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpO6ECHNY8n1.pgp Description: PGP signature
Re: perl-5.14.4
On Feb 8 21:19, Achim Gratz wrote: Achim Gratz writes: Major progress: the cygport file starts to look sane. I've ripped out the rebase changes in EU::MM and replaced them with an oblivious rebase, which is the first time I could compile and test on 32bit without manual intervention. It turns out that doing so damages the debug information in the library and then it can't be extracted later, so I'll have to skip this step when building with cygport. I have no idea how and why this happens; the debug information is still there, but quite obviously it can't be correctly associated with the code after rebasing. Is that something that can be fixed in rebase or objcopy? I think it's important to keep the information in sync while building the packages. A later rebase will break the connection between debug symbols and runtime symbols as well, obviously. Maybe we should think of rebasing the actual binaries as well as their debugging counterparts to keep everything in sync, but that's a bit much effort... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSRZGzeCgPA.pgp Description: PGP signature
Re: [ITP] python-discid-1.1.0: Python binding of libdiscid by MusicBrainz
On Mon, 2015-02-09 at 09:51 +0100, vz...@volkerzell.de wrote: I would like to contribute and maintain the 'python-discid' package: o https://python-discid.readthedocs.org (Homepage) o https://github.com/JonnyJD/python-discid/archive/v1.1.0.tar.gz (Download location) Here is the setup.hint file: --- ./setup.hint category: Python requires: python sdesc: Python binding of libdiscid by MusicBrainz ldesc: The main purpose is the calculation of an identifier for audio discs (Disc ID) to use for the MusicBrainz database. Additionally the disc MCN and track ISRCs can be extracted. This module loads libdiscid via ctypes, so you need an explicit REQUIRES=libdiscid-devel in your .cygport. With that change, GTG. -- Yaakov
Re: [ITP] python-discid-1.1.0: Python binding of libdiscid by MusicBrainz
Yaakov Selkowitz writes: On Mon, 2015-02-09 at 09:51 +0100, vz...@volkerzell.de wrote: I would like to contribute and maintain the 'python-discid' package: o https://python-discid.readthedocs.org (Homepage) o https://github.com/JonnyJD/python-discid/archive/v1.1.0.tar.gz (Download location) Here is the setup.hint file: --- ./setup.hint category: Python requires: python sdesc: Python binding of libdiscid by MusicBrainz ldesc: The main purpose is the calculation of an identifier for audio discs (Disc ID) to use for the MusicBrainz database. Additionally the disc MCN and track ISRCs can be extracted. This module loads libdiscid via ctypes, so you need an explicit REQUIRES=libdiscid-devel in your .cygport. With that change, GTG. Shouldn't that be: REQUIRES=libdiscid0 Ciao Volker
Re: [ITP] hidapi 0.8.0-rc1
On Feb 9 09:10, 陳韋任 wrote: Dear all, I would like to package hidapi and propose it for inclusion in Cygwin. hidapi is a multi-platform library which allows an application to interface with USB and Bluetooth HID-Class devices on Windows, Linux, and Mac OS X. hidapi has been included in many Linux distributions. [...] Packaging looks good, GTG. We just need your ssh key now so you can upload the packages. See https://sourceware.org/cygwin-apps/package-upload.html Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbAnm535BJM.pgp Description: PGP signature
Re: [HEADSUP] Moving setup sources to git
Corinna Vinschen writes: The new git repo should basically work now, but I'm not a git config guru, so if stuff is missing, I appreciate configuration help! Looks good so far. I assume that the SSH keys are already usable? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
