Re: NEW: audio/canata 1.5.1
ping?
NEW: audio/canata 1.5.1
Hi ports@,
i ported cantata 1.5.1, a graphical mpd client written in qt. It can be
built agains qt4, qt5 or the kde4 libs. However, i could only get it to
build with kde4 bindings.
An outdated port for version 1.2.2 was available in the
openbsd-wip github-repo, so i used that source as inspiration:
https://github.com/jasperla/openbsd-wip/tree/master/audio/cantata
The port works for me on amd64, however i'm not sure if all the libs
in WANTLIB are needed. After running "make port-lib-depends-check", i
got the following output:
$ make port-lib-depends-check
Asking ports for dependency libiconv-1.14p1(converters/libiconv)
Asking ports for dependency kdelibs-4.14.2p0(x11/kde4/libs,-main)
Asking ports for dependency libstdc++-4.8.4(lang/gcc/4.8,-estdc)
Asking ports for dependency gtk-update-icon-cache-2.24.25(x11/gtk+2,-guic)
Asking ports for dependency phonon-vlc-0.8.0(multimedia/phonon-backend/vlc)
Asking ports for dependency gettext-0.19.3(devel/gettext)
Asking ports for dependency cdparanoia-3.a9.8p0(audio/cdparanoia)
Asking ports for dependency libcddb-1.3.2(audio/libcddb)
Asking ports for dependency taglib-1.9.1p1(audio/taglib)
Asking ports for dependency desktop-file-utils-0.22(devel/desktop-file-utils)
Asking ports for dependency ffmpeg-20150107(graphics/ffmpeg)
Asking ports for dependency libmusicbrainz5-5.0.1p1(audio/libmusicbrainz5)
Asking ports for dependency phonon-4.8.1p0(multimedia/phonon)
Asking ports for dependency libmtp-1.1.6p0(devel/libmtp)
Asking ports for dependency oxygen-icons-4.14.2(x11/kde4/oxygen-icons)
Asking ports for dependency speex-1.2rc1p0(audio/speex)
Asking ports for dependency qjson-0.8.1p0(devel/qjson)
Asking ports for dependency qt4-4.8.6p0(x11/qt4,-main)
Asking ports for dependency mpg123-1.21.0(audio/mpg123)
cantata-1.5.1(audio/cantata):
Extra: iconv.6 intl.6 phonon_s.2
Now i added the three libs listed in 'Extra',
but still get the same output. What does Extra mean? Do these libs have
to be in WANTLIB, or not?
Also, /usr/ports/infrastructure/bin/portcheck reported the following:
$ /usr/ports/infrastructure/bin/portcheck
1 line(s) longer than 80 chars in Makefile
kdeui instead of ${KDE4LIB}/kdeui in WANTLIB (check other libs, too!)
kio instead of ${KDE4LIB}/kio in WANTLIB (check other libs, too!)
missing @exec of gtk-update-icon-cache for icon theme hicolor
missing @unexec-delete of gtk-update-icon-cache for icon theme hicolor
missing @exec of update-desktop-database
missing @unexec-delete of update-desktop-database
translation file(s) found without devel/gettext dependency in MODULES or
RUN_DEPENDS
audio/cantata
So i added devel/gettext to MODULES and these 4 line (found in other
plists) to pkg/PLIST:
@exec %D/bin/update-desktop-database
@unexec-delete %D/bin/update-desktop-database
@exec %D/bin/gtk-update-icon-cache -q -t %D/share/icons/hicolor
@unexec-delete %D/bin/gtk-update-icon-cache -q -t %D/share/icons/hicolor
Finally, since google code doesn't offer a way to download tarballs
anymore, the author hosts all sourcefiles on google drive. As i could not
find a way to download them from vie the port infrastructure, i mirrored
the file on my webspace.
Comments?
Regards
Nils
cantata-1.5.1.tar.gz
Description: GNU Zip compressed data
UPDATE: mpd 0.19.7 with sticker support
Hi,
i updated mpd to the latest stable version (0.19.7) and enabled the
sqlite-option to gain sticker support, which i use to rate my songs.
Tested on amd64, works for me (sticker support tested with cantata,
for which i'm preparing a port, and mpc).
Nils
Index: Makefile
===
RCS file: /cvs/ports/audio/mpd/Makefile,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile
--- Makefile27 Nov 2014 19:57:16 - 1.69
+++ Makefile14 Jan 2015 23:17:53 -
@@ -1,8 +1,7 @@
# $OpenBSD: Makefile,v 1.69 2014/11/27 19:57:16 ajacoutot Exp $
COMMENT = Music Player Daemon
-DISTNAME = mpd-0.19.5
-REVISION = 1
+DISTNAME = mpd-0.19.7
CATEGORIES = audio
HOMEPAGE = http://www.musicpd.org/
MAINTAINER = David Coppa
@@ -17,7 +16,7 @@ WANTLIB = FLAC ao audiofile avcodec avf
m mikmod mp3lame mpcdec mpdclient ogg \
opus pthread samplerate shout sndfile \
sndio speex theora vorbis vorbisenc \
- vorbisfile z
+ vorbisfile z sqlite3
MASTER_SITES = http://www.musicpd.org/download/mpd/stable/
@@ -71,7 +70,6 @@ CONFIGURE_ARGS += --bindir=${PREFIX}/sbi
--disable-smbclient \
--disable-soundcloud \
--disable-soxr \
- --disable-sqlite \
--disable-systemd-daemon \
--disable-twolame-encoder \
--disable-upnp \
@@ -92,6 +90,7 @@ CONFIGURE_ARGS += --bindir=${PREFIX}/sbi
--enable-pipe-output \
--enable-shout \
--enable-sndfile \
+ --enable-sqlite \
--enable-vorbis \
--enable-vorbis-encoder \
--enable-wave-encoder \
Index: distinfo
===
RCS file: /cvs/ports/audio/mpd/distinfo,v
retrieving revision 1.28
diff -u -p -r1.28 distinfo
--- distinfo27 Nov 2014 13:52:08 - 1.28
+++ distinfo14 Jan 2015 23:17:53 -
@@ -1,2 +1,2 @@
-SHA256 (mpd-0.19.5.tar.gz) = Y1TRnjTD6URJqr0ImqJ5M2v1wllo5/GlPB3+q929MCc=
-SIZE (mpd-0.19.5.tar.gz) = 976334
+SHA256 (mpd-0.19.7.tar.gz) = JocNt41ZWJuYimSh+hMk2MUzAVWsE/tXIDZ9XfGXfWY=
+SIZE (mpd-0.19.7.tar.gz) = 977504
Re: Problems linking again stdc++ and estdc++
Stuart Henderson schrieb am 19.05.2014 23:23:
> On 2014/05/19 18:07, Nils R wrote:
>> >> # some source files contain a BOM which gcc 4.2.1 can't handle
>> >
>> > If that's the only reason for using a gplv3 GCC, can these files just
>> > be patched instead? Alternatively, how does clang handle them?
>> >
>>
>> clang fails to build because of some problems with gtest, but i had no time
>> to look into it. Might not be a big issue though. Should i conclude from
>> this that clang is favoured over a gpl3 licensed gcc? If so, is there a
>> reason to favor non-gpl3 compilers for ports?
>
> My preferences in order (*if* things work properly with that compiler) :-
>
> 1. default compiler from the base os
> 2. ports clang
> 3. ports gcc
>
> If it's just a small fix to be able to use 1) then do that, don't stack
> things in a bulk build behind a (slow) build of an additional C compiler
> if that isn't needed.
>
> 1) and 2) currently use libstdc++ from base, avoiding conflicts.
>
Ok, makes sense. Thank you for the explanation.
> Some specific points about this port; please add this:
>
> MAKE_FLAGS= Q= CXX="${CXX}" CC="${CC}"
>
> Q= disables hiding command lines in upstream's Makefile, the others
> honour user choices of compiler.
>
done
> As for the BOM it can just be stripped
>
> # strip BOM, gcc 4.2.1 doesn't understand it
> post-extract:
> perl -pi -e 's,\xef\xbb\xbf,,' ${WRKSRC}/Build/Utils/_*Text.cc
>
Thanks, this won't be fixed upstream because Visual Studio adds a BOM every
time the file is saved, but this line is a quick and easy fix.
> it runs into various gtest-related problems e.g.
>
> _build/lib-gtest/src/gtest-internal-inl.h:86: error: expected constructor,
> destructor, or type conversion before 'extern'
> _build/lib-gtest/src/gtest-internal-inl.h:109: error: expected constructor,
> destructor, or type conversion before 'extern'
> _build/lib-gtest/src/gtest-internal-inl.h:112: error: 'GTEST_API_' does not
> name a type
> [...]
>
> do we need the tests anyway though? adding WITH_UNITTESTS=0 to MAKE_FLAGS
> skips them and then it builds with base gcc.
>
We don't need the tests, but there still is this weird thing i still don't get:
when i compile the source code directly (with a new gcc/g++), there are no gtest
problems, and all tests pass (without the stdc++ confusion). However, when
compiling it with the ports Makefile, these problems show up. I'll try to
find the reason for this tomorrow.
Nils
Re: Problems linking again stdc++ and estdc++
Stuart Henderson schrieb am 19.05.2014 15:57:
> On 2014/05/19 15:22, Nils R wrote:
>> Hi ports@,
>>
>> i'm currently porting the game engine for jagged alliance 2 [1]
>> to openbsd. If i clone the repository and do
>>
>> # pkg_add sdl gmake gcc g++
>> $ CC=egcc CXX=eg++ gmake
>>
>> the program builds and runs fine. It also ships with unittests,
>> which all pass. However, i now tried to build a port (see
>> attachment). It also builds, but when i run the unittests, the
>> following line is printed:
>>
>> ja2:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.16.0 :
>> WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch,
>> relink your program
>>
>> What can i do to link against estdc++?
>
> This program *is* linking against estdc++, but a library it depends on
> links against stdc++, hence the warning as the two conflicting libraries
> are loaded into the same address space, so you can't be sure which one
> is used for function calls and they don't have a fully compatible ABI.
> (Note that this may work "OK" for some programs but this doesn't mean
> it will work for every program).
>
> This is an increasing problem again as we run into more and more
> programs using features from newer language specifications not supported
> by old compilers..
>
The funny thing is that if i compile it directly from git in my home folder,
the warning doesn't show up and all tests pass. With the ports version, the
warning shows and some tests fail.
>> Please note that this port is a WIP, the license doesn't allow
>> commercial use, so i'm unsure if the package would be allowed on
>> cd or only on ftp.
>
> The CD is commercial, so PERMIT_PACKAGE_CDROM cannot be set to "yes".
> (generally games need fairly careful checking, especially with
> artwork/audio etc, even for ftp).
>
Yes, that's what i thought. This port is only for the engine though, to
play the game, one needs the official game data which does not come with
the port, so ftp distribution should be allowed.
>> DISTNAME = 9f7f461f0a2d
>
> this isn't an acceptable distname for the ports tree, this would probably
> want something like this:
>
> DISTNAME= ja2-stracciatella-[something]
> DISTFILES= ${DISTNAME}{9f7f461f0a2d}${EXTRACT_SUFX}
>
> the [something] would usually be based on the date (e.g. 0.20140519) if
> you cannot persuade upstream to make a real release.
>
Upstream offers releases, but i wanted to test the latest git to see if a
problem was fixed. For the real port, i will stick to releases of course.
>> # some source files contain a BOM which gcc 4.2.1 can't handle
>
> If that's the only reason for using a gplv3 GCC, can these files just
> be patched instead? Alternatively, how does clang handle them?
>
clang fails to build because of some problems with gtest, but i had no time
to look into it. Might not be a big issue though. Should i conclude from
this that clang is favoured over a gpl3 licensed gcc? If so, is there a
reason to favor non-gpl3 compilers for ports?
Nils
Problems linking again stdc++ and estdc++
Hi ports@,
i'm currently porting the game engine for jagged alliance 2 [1]
to openbsd. If i clone the repository and do
# pkg_add sdl gmake gcc g++
$ CC=egcc CXX=eg++ gmake
the program builds and runs fine. It also ships with unittests,
which all pass. However, i now tried to build a port (see
attachment). It also builds, but when i run the unittests, the
following line is printed:
ja2:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.16.0 :
WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
What can i do to link against estdc++?
Please note that this port is a WIP, the license doesn't allow
commercial use, so i'm unsure if the package would be allowed on
cd or only on ftp.
Here is the Makefile for convenience:
-
# $OpenBSD: Makefile.template,v 1.68 2013/10/02 07:34:45 ajacoutot Exp $
COMMENT = Jagged Alliance 2 engine with bugfixes
DISTNAME = 9f7f461f0a2d
PKGNAME = ja2-stracciatella-${DISTNAME}
REVISION = 3
CATEGORIES =games
HOMEPAGE = https://bitbucket.org/gennady/ja2-stracciatella/overview
# SFI-SCLA / public domain
#PERMIT_PACKAGE_CDROM = No #is publishing the package a commercial use?
PERMIT_PACKAGE_CDROM = Yes
# "make port-lib-depends-check" can help
WANTLIB += boost_filesystem boost_system c m pthread SDL stdc++ # gtest
gtest_main
MASTER_SITES = https://bitbucket.org/gennady/ja2-stracciatella/get/
# some source files contain a BOM which gcc 4.2.1 can't handle
MODULES = gcc4
MODGCC4_LANGS = c c++
MODGCC4_ARCHS = *
BUILD_DEPENDS = devel/sdl \
devel/boost
#devel/gtest
LIB_DEPENDS = devel/sdl \
devel/boost
# devel/gtest
USE_GMAKE = Yes
WRKDIST = ${WRKDIR}/gennady-ja2-stracciatella-${DISTNAME}/
NO_TEST = Yes
.include
-
Thanks for help,
Nils
[1]: https://bitbucket.org/gennady/ja2-stracciatella/
ja2-stracciatella.tgz
Description: GNU Zip compressed data
Re: [new] audio/py-discogs-client
Johan Huldtgren schrieb am 16.05.2014 21:06: > hello, > > this is a port of py-discogs-client which is an optional plugin > for audio/beets so you can query the Discogs database instead of > only Musicbrainz. > > tested on amd64 > > thanks, > > .jh > Hi Johan, i checked my port, and it's exactly the same as yours (except for the maintainer) :) I already tested it on amd64 and it works fine. Thanks! Nils
Re: [NEW] beets
Johan Huldtgren schrieb am 16.05.2014 21:04: > On 5/15/14, 2:23 PM, Nils R wrote: > >> Thanks :) It's a nice program indeed. Finally a tagger with a sane >> config syntax, low overhead and which allows to get tags from >> musicbrainz *and* discogs. Btw, i use to browse the ports tree on >> ports.su from time to time to look for nice programs i would otherwise >> never notice, e.g. xbanish, youtube-dl, lumail, and many more. > > I've been using beets on FreeBSD so I moved over my library.db and > config.yaml to test this out. However I had quite a few plugins enabled > that don't work in the port yet (as per your earlier e-mail). So here is > what I needed to do to get it all working: > > fetchart just needs www/py-requests, which we have and doesn't pull > in anything additional, so adding it as a RUN_DEPENDS seems like a > reasonable idea. > > I created a port for py-discogs-client, see separate e-mail. > > I created a pkg/MESSAGE to mention it and a few other plugins which > require additional packages to be installed. > > Finally the man pages for beet and beetsconfig weren't installed by > your port so I added that step. > > updated port is attached. > > .jh > Hi Johan, thanks for spotting these issues. I also came across the problem that dependencies for the plugins are missing, but decided that this should not be part of beets, because we can't pull in all dependencies for all plugins, and they are documented on the beets documentation. py-request won't hurt though, and it is needed by a fair amount of plugins, so i think it's a good idea to just have it pulled in by beets, thats less confusing for the users. I also created a port for discogs, but didn't post it to the list yet :) I'll compare them and then post in the other thread. Thanks for your help! Nils
Re: [NEW] py-acoustid
Stuart Henderson schrieb am 16.05.2014 18:24: > This is nearly there, but "make test" still downloads audioread .. > Perhaps for the sake of getting it imported, the best option might be > to add this? > > # tests require https://pypi.python.org/pypi/audioread/ > NO_TEST= Yes > Sorry, i always forget about the tests. I think they can be ignored in this case, and i will do my best to remember tests in my next port :) Nils
Re: [NEW] beets
>> I really ask myself why I didn't discover this piece of software >> earlier - never heard of it before. It would have saved me so much >> work a year ago. Very excited to see it in ports/packages. >> Thanks a lot for bringing it in > > Yeah. Thanks a lot, Nils! > > Erling > Thanks :) It's a nice program indeed. Finally a tagger with a sane config syntax, low overhead and which allows to get tags from musicbrainz *and* discogs. Btw, i use to browse the ports tree on ports.su from time to time to look for nice programs i would otherwise never notice, e.g. xbanish, youtube-dl, lumail, and many more. Nils
Re: [NEW] beets
Stuart Henderson schrieb am 13.05.2014 17:13:
> On 2014/05/13 17:07, Nils R wrote:
>> Brian Callahan schrieb am 13.05.2014 16:57:
>>
>> >
>> > On 05/13/14 10:41, Nils R wrote:
>> >> Now that all dependencies are in the tree, here's an updated port
>> >> for the new beets version 1.3.6.
>> >>
>> >> Any comments?
>> >>
>> >> Nils
>> >
>> > Do you not want to be maintainer?
>> >
>> > 'make test' downloads a whole bunch of stuff from the Internet, then
>> > fails for me:
>> > AttributeError: 'module' object has no attribute 'suite'
>> > So something needs to be done about that. Maybe just NO_TEST=Yes
>> >
>> > Otherwise looks ok.
>> >
>> > ~Brian
>> >
>>
>> Hi Brian,
>>
>> i have to get more comfortable with all that ports stuff before i become
>> a maintainer. So it looks like there are tests, but for now i disabled
>> them. When i have more time i will have a look at this and maybe enable
>> it later.
>>
>> Added NO_TEST = Yes to the Makefile.
>
> The question there is, whether there are non-test codepaths that
> would also try to install things from the internet at runtime...
>
I checked the setup.py file, which lists the dependencies for the various
targets (main program, tests, plugins):
install_requires=[
'enum34',
'mutagen>=1.22',
'munkres',
'unidecode',
'musicbrainzngs>=0.4',
'pyyaml',
]
+ (['colorama'] if (sys.platform == 'win32') else [])
+ (['ordereddict'] if sys.version_info < (2, 7, 0) else []),
tests_require=[
'responses',
'pyechonest',
'mock',
'flask',
'rarfile',
'pylast',
],
# Plugin (optional) dependencies:
extras_require={
'beatport': ['requests'],
'fetchart': ['requests'],
'chroma': ['pyacoustid'],
'discogs': ['discogs-client'],
'echonest': ['pyechonest'],
'echonest_tempo': ['pyechonest'],
'lastgenre': ['pylast'],
'mpdstats': ['python-mpd'],
'web': ['flask'],
'import': ['rarfile'],
Until all test dependencies are ported, i would go for a NO_TEST=Yes.
What do you think?
Nils
Re: [NEW] beets
Brian Callahan schrieb am 13.05.2014 16:57: > > On 05/13/14 10:41, Nils R wrote: >> Now that all dependencies are in the tree, here's an updated port >> for the new beets version 1.3.6. >> >> Any comments? >> >> Nils > > Do you not want to be maintainer? > > 'make test' downloads a whole bunch of stuff from the Internet, then > fails for me: > AttributeError: 'module' object has no attribute 'suite' > So something needs to be done about that. Maybe just NO_TEST=Yes > > Otherwise looks ok. > > ~Brian > Hi Brian, i have to get more comfortable with all that ports stuff before i become a maintainer. So it looks like there are tests, but for now i disabled them. When i have more time i will have a look at this and maybe enable it later. Added NO_TEST = Yes to the Makefile. Nils beets-1.3.6-1.tgz Description: GNU Zip compressed data
Re: [NEW] beets
Now that all dependencies are in the tree, here's an updated port for the new beets version 1.3.6. Any comments? Nils beets-1.3.6.tgz Description: GNU Zip compressed data
Re: [NEW] py-enum34
Benoit Lecocq schrieb am 11.05.2014 10:39:
> On 05/06/14 17:20, Nils R wrote:
>> Hi,
>>
>> as Aaron pointed out, i was missing enum34 as a dependency for beets.
>>
>> Here is a port, comments welcome :)
>>
>> Nils
>>
>
> Hi,
>
> You can add :
>
> PKGNAME = py-${DISTNAME}
>
> and
>
> NO_TEST = Yes
>
> Cheers,
> benoit
>
Done, here's the updated tarball.
Nils
py-enum34.tgz
Description: GNU Zip compressed data
Re: [NEW] py-musicbrainzngs
Benoit Lecocq schrieb am 12.05.2014 09:40:
> Le 06/05/2014 15:36, Nils R a écrit :
>> Hi,
>>
>> this is a dependency for beets.
>>
>> Nils
>>
>
> Hi,
>
> You can add :
>
> do-test:
> @${MODPY_TEST_TARGET}
>
> and a newline before COMMENT.
>
> Cheers,
> benoit
>
Hi Benoit,
here's an updated tarball.
Nils
py-musicbrainzngs-2.tgz
Description: GNU Zip compressed data
Re: [NEW] py-acoustid
Stuart Henderson schrieb am 08.05.2014 16:38: > On 2014/05/08 13:24, Nils R wrote: >> Stuart Henderson schrieb am 08.05.2014 13:13: >> >> > On 2014/05/08 13:04, Nils R wrote: >> >> Hi, >> >> >> >> this is a port for pyacoustid. From the homepage: >> >> >> >> Chromaprint and its associated Acoustid Web service make up a >> >> high-quality, open-source acoustic fingerprinting system. This package >> >> provides Python bindings for both the fingerprinting algorithm library, >> >> which is written in C but portable, and the Web service, which provides >> >> fingerprint lookups. >> >> >> >> >> >> This is an (optional) dependency for beets, allowing to query the acoustid >> >> database for tags while tagging, storing acoustid fingerprints in files, >> >> and uploading new fingerprints to the database. >> >> >> >> >> >> Tested with beets 1.3.5. >> >> >> >> Any comments? >> >> >> >> Nils >> > >> > >> > Remove REVISION and don't explicitly list lang/python in CATEGORIES, >> > but also it seems this needs audioread to be ported as a dependency. >> > >> >> Hi Stuart, >> >> the program uses fpcalc if available (it is with new chromaprint port): >> >> This library uses audioread to do audio decoding when not using fpcalc >> ^ >> and requests to talk to the HTTP API (pip should automatically install >> these dependencies). > > ah; in that case, it needs an explicit version in the dependency on > chromaprint to make sure that it gets a version with fpcalc. > >> I also modified the Makefile, sorry that i alway forget to remove the >> REVISION. >> Thats used by me because often, things go wrong, so i bump REVISION to get a >> fresh rebuilt. Is there a better way? I will take more care in the future. > > I normally do something like 'make clean; make PLIST_DB= repackage reinstall' > (or in the case of packages where uninstalling would be a major pain, > I repackage and then do "PKG_PATH=/usr/ports/packages/amd64/all sudo pkg_add > -r -D installed "). > Ok, i added audio/chromaprint>=1.1 to RUN_DEPENDS. And thanks for your workflow :) Nils py-acoustid-2.tgz Description: GNU Zip compressed data
Re: [NEW] py-acoustid
Stuart Henderson schrieb am 08.05.2014 13:13: > On 2014/05/08 13:04, Nils R wrote: >> Hi, >> >> this is a port for pyacoustid. From the homepage: >> >> Chromaprint and its associated Acoustid Web service make up a >> high-quality, open-source acoustic fingerprinting system. This package >> provides Python bindings for both the fingerprinting algorithm library, >> which is written in C but portable, and the Web service, which provides >> fingerprint lookups. >> >> >> This is an (optional) dependency for beets, allowing to query the acoustid >> database for tags while tagging, storing acoustid fingerprints in files, >> and uploading new fingerprints to the database. >> >> >> Tested with beets 1.3.5. >> >> Any comments? >> >> Nils > > > Remove REVISION and don't explicitly list lang/python in CATEGORIES, > but also it seems this needs audioread to be ported as a dependency. > Hi Stuart, the program uses fpcalc if available (it is with new chromaprint port): This library uses audioread to do audio decoding when not using fpcalc ^ and requests to talk to the HTTP API (pip should automatically install these dependencies). I also modified the Makefile, sorry that i alway forget to remove the REVISION. Thats used by me because often, things go wrong, so i bump REVISION to get a fresh rebuilt. Is there a better way? I will take more care in the future. Nils py-acoustid-1.tgz Description: GNU Zip compressed data
[NEW] py-acoustid
Hi, this is a port for pyacoustid. From the homepage: Chromaprint and its associated Acoustid Web service make up a high-quality, open-source acoustic fingerprinting system. This package provides Python bindings for both the fingerprinting algorithm library, which is written in C but portable, and the Web service, which provides fingerprint lookups. This is an (optional) dependency for beets, allowing to query the acoustid database for tags while tagging, storing acoustid fingerprints in files, and uploading new fingerprints to the database. Tested with beets 1.3.5. Any comments? Nils py-acoustid.tgz Description: GNU Zip compressed data
Re: [UPDATE] chromaprint 1.1
David Coppa schrieb am 08.05.2014 09:10: > On Thu, May 8, 2014 at 8:50 AM, Nils R wrote: > >> Regarding 2), no ABI change was documented, but how can i be sure? > > I use this: > https://github.com/jasperla/openbsd-wip/tree/master/devel/abi-compliance-checker > > http://ispras.linuxbase.org/index.php/ABI_compliance_checker > >> Nils > > Ciao! > David > Ok, the tool gave me this: $ sudo abi-compliance-checker -lib chromaprint -old chromaprint-0.6.xml -new chromaprint-1.1.xml preparation, please wait ... Using GCC 4.2.1 (amd64-unknown-openbsd5.5) checking header(s) 0.6 ... checking header(s) 1.1 ... comparing ABIs ... comparing APIs ... creating compatibility report ... result: COMPATIBLE total "Binary" compatibility problems: 0, warnings: 0 total "Source" compatibility problems: 0, warnings: 2 see detailed report: compat_reports/chromaprint/0.6_to_1.1/compat_report.html I'll attach the report, but it looks good. Still can't build clementine though. Nils
Re: [UPDATE] chromaprint 1.1
Vadim Zhukov schrieb am 07.05.2014 23:20: > 2014-05-07 20:24 GMT+04:00, Nils R : >>> Hi ports@, >>> >>> this is an update of chromaprint to the latest version. >>> >>> It builds on amd64, and the tests run fine with `make test` >>> (the command for running the tests in the current port >>> doesn't work). >>> >>> I will try this out now with puddletag ;) >>> >>> Any comments? Please test. >>> >>> Nils >>> >>> >>> PS. I would have sent diffs, but i could not add the patch >>> directory to cvs, so i made a tarball. >> >> Puddletag needs the fpcalc utility program that ships with >> chromaprint. With this tarball, it gets build and installed >> by default. >> >> Now, tagging through AcousticID works in puddletag. > > Thank you for your submission. Two questions there: > > 1) Did you check that audio/clementine (the only user of chromaprint > as of now) still builds and works? > > 2) Did actual shared library ABI change? If so, SHARED_LIBS need bump. > > -- > WBR, > Vadim Zhukov > Hi Vadim, i tried to install clementine, but building the dependency devel/sparsehash failed with "virtual memory exhausted: Cannot allocate memory" (with freshly pulled ports): In file included from /usr/ports/pobj/sparsehash-2.0.2/sparsehash-2.0.2/src/sparsehash/sparse_hash_map:94, from /usr/ports/pobj/sparsehash-2.0.2/sparsehash-2.0.2/src/hash_test_interface.h:51, from /usr/ports/pobj/sparsehash-2.0.2/sparsehash-2.0.2/src/hashtable_test.cc:63: /usr/include/g++/tr1/functional: In constructor 'std::tr1::_Simple_type_wrapper<_Tp>::_Simple_type_wrapper(_Tp)': /usr/include/g++/tr1/functional:804: warning: declaration of '__value' shadows a member of 'this' virtual memory exhausted: Cannot allocate memory *** Error 1 in . (Makefile:581 'hashtable_test.o') *** Error 1 in /usr/ports/pobj/sparsehash-2.0.2/build-amd64 (Makefile:437 'all') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2691 '/usr/ports/pobj/sparsehash-2.0.2/build-amd64/.build_done') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1886 '/usr/ports/packages/amd64/all/sparsehash-2.0.2p1.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2439 '_internal-package') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'package') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1903 '/var/db/pkg/sparsehash-2.0.2p1/+CONTENTS') *** Error 1 in /usr/ports/devel/sparsehash (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'install') Regarding 2), no ABI change was documented, but how can i be sure? Nils
Re: [UPDATE] chromaprint 1.1
> Hi ports@, > > this is an update of chromaprint to the latest version. > > It builds on amd64, and the tests run fine with `make test` > (the command for running the tests in the current port > doesn't work). > > I will try this out now with puddletag ;) > > Any comments? Please test. > > Nils > > > PS. I would have sent diffs, but i could not add the patch > directory to cvs, so i made a tarball. Puddletag needs the fpcalc utility program that ships with chromaprint. With this tarball, it gets build and installed by default. Now, tagging through AcousticID works in puddletag. Nils chromaprint-1.1-rev0.tgz Description: GNU Zip compressed data
[UPDATE] chromaprint 1.1
Hi ports@, this is an update of chromaprint to the latest version. It builds on amd64, and the tests run fine with `make test` (the command for running the tests in the current port doesn't work). I will try this out now with puddletag ;) Any comments? Please test. Nils PS. I would have sent diffs, but i could not add the patch directory to cvs, so i made a tarball. chromaprint-1.1.tgz Description: GNU Zip compressed data
UPDATE: add chromaprint to puddletag
Hi ports@,
i missed this (optional) dependency on chromaprint in puddletag.
Attached is a diff for the Makefile.
NilsIndex: Makefile
===
RCS file: /cvs/ports/audio/puddletag/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile 6 May 2014 14:01:16 - 1.1.1.1
+++ Makefile 6 May 2014 20:02:53 -
@@ -4,6 +4,7 @@
MODPY_EGG_VERSION = 1.0.3
DISTNAME = puddletag-${MODPY_EGG_VERSION}
+REVISION = 0
CATEGORIES = audio
PERMIT_PACKAGE_CDROM = Yes
@@ -13,7 +14,8 @@
NO_TEST = Yes
MODULES = lang/python
-RUN_DEPENDS = audio/py-mutagen \
+RUN_DEPENDS = audio/chromaprint \
+ audio/py-mutagen \
devel/py-configobj \
devel/py-parsing \
devel/desktop-file-utils \
Re: [NEW] beets
Added a missing dependency on py-enum34. Nils beets-2.tgz Description: GNU Zip compressed data
[NEW] py-enum34
Hi, as Aaron pointed out, i was missing enum34 as a dependency for beets. Here is a port, comments welcome :) Nils py-enum34.tgz Description: GNU Zip compressed data
Re: [NEW] py-algorithm-munkres
Cleaned up the Makefile with hints from sthen@. Nils py-algorithm-munkres-1.tgz Description: GNU Zip compressed data
Re: [NEW] beets
Cleaned up the Makefile with hints from sthen@. Nils beets-1.tgz Description: GNU Zip compressed data
Re: [NEW] py-unidecode
Stuart Henderson schrieb am 06.05.2014 16:19:
> On 2014/05/06 15:35, Nils R wrote:
>> Hi,
>>
>> this is a dependency for beets.
>>
>> Nils
>
> a few tweaks:
>
> add a blank line between "# $OpenBSD$" line and COMMENT
>
> MODPY_EGG_VERSION=0.04.14 -> MODPY_EGG_VERSION = 0.04.14 (variable name is too
> long to align nicely, but please use the same whitespace style around = as
> other lines)
>
> "either version 2 of the License, or (at your option) any later version" ->
> use "GPLv2+" in the license marker
>
> add this:
>
> do-test:
> @${MODPY_TEST_TARGET}
>
Thanks,
this should be better.
Nils
py-unidecode-1.tgz
Description: GNU Zip compressed data
[NEW] py-algorithm-munkres
Hi, this is a dependency for beets. Nils py-algorithm-munkres.tgz Description: GNU Zip compressed data
[NEW] py-algorithm-munkres
Hi, this is a dependency for beets. Nils py-algorithm-munkres.tgz Description: GNU Zip compressed data
[NEW] py-musicbrainzngs
Hi, this is a dependency for beets. Nils py-musicbrainzngs.tgz Description: GNU Zip compressed data
[NEW] py-unidecode
Hi, this is a dependency for beets. Nils py-unidecode.tgz Description: GNU Zip compressed data
[NEW] beets
Hi ports@, i ported beets, including it's missing dependencies. I'll send a single mail for each port. Please comment. Nils beets.tgz Description: GNU Zip compressed data
Re: [NEW] Puddletag
Stuart Henderson schrieb am 06.05.2014 12:30: > On 2014/05/05 13:02, Nils R wrote: >> Updated port, i messed up BUILD_DEPENDS with RUN_DEPENDS. Pulls dependencies >> now. >> >> Any comment? >> >> Nils > > share/man/man1/ - wrong manpage location, should be man/man1 > > Makefile - make this look more like the other Makefiles in the tree > (whitespace, excess PERMIT_* lines) - V= is unnecessary, just use > MODPY_EGG_VERSION > Thanks for your hints, Stuart. I hope this one is better. I'm unsure if the replacement of the man-path should take place in setup.py, and if pre-fake is the right target (see the Makefile). Also, after deinstallation, it prints a warning that /usr/local/man/man1 can't be removed: ===> Deinstalling for puddletag-1.0.3p6 puddletag-1.0.3p6: ok Read shared items: ok --- -puddletag-1.0.3p6 --- Error deleting directory /usr/local/man/man1: Directory not empty Error deleting directory /usr/local/man: Directory not empty Is there a way to prevent this behaviour? Thanks, Nils puddletag-2.tgz Description: GNU Zip compressed data
Re: [NEW] Puddletag
Updated port, i messed up BUILD_DEPENDS with RUN_DEPENDS. Pulls dependencies now. Any comment? Nils puddletag-1.tgz Description: GNU Zip compressed data
[NEW] Puddletag
Hi ports@, this is a port for puddletag, a music file tagging program. Works fine for me on amd64. The portcheck program complained about missing @exec update-desktop-database, so i added @exec %D/bin/update-desktop-database @unexec-delete %D/bin/update-desktop-database by hand to PLIST, is that correct? (found that by grepping the ports tree) Best, Nils puddletag.tgz Description: GNU Zip compressed data
Problem with python PLIST and ${FULLPKGNAME\-}
Hi ports@,
i currently try to port puddletag, a python audio file tagger [1]. So
far, everything works fine, except for one thing: When i make package,
it throws this error:
`/usr/ports/pobj/puddletag-1.0.3/fake-amd64/.fake_done' is up to date.
===> Building package for puddletag-1.0.3
Create /usr/ports/packages/amd64/all/puddletag-1.0.3.tgz
Error:
/usr/ports/pobj/puddletag-1.0.3/fake-amd64/usr/local/lib/python2.7/site-packages/${FULLPKGNAME\-}-py2.7.egg-info
does not exist
Fatal error: can't continue
at /usr/libdata/perl5/OpenBSD/PkgCreate.pm line 1450.
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1890
'/usr/ports/packages/amd64/all/puddletag-1.0.3.tgz')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2439
'_internal-package')
*** Error 1 in /usr/ports/mystuff/audio/puddletag
(/usr/ports/infrastructure/mk/bsd.port.mk:2419 'package')
I could resolve it by replacing ${FULLPKGNAME\-} with ${FULLPKGNAME} in
PLIST. After that, the package builds, can be installed and starts
(did not test functionality so far). On the web, i found a link to this
thread from last year [2], but maybe i'm just doing something wrong.
Please see my port attached.
Thanks,
Nils
[1]: http://puddletag.sourceforge.net/index.html
[2]:
http://openbsd.7691.n7.nabble.com/PORTS-framework-plist-with-FULLPKGNAME-problem-td228225.html
puddletag.tgz
Description: GNU Zip compressed data
