Re: CVS: cvs.openbsd.org: ports
On Wed, 19 Aug 2020 08:06:51 -0600 (MDT) Charlene Wendling wrote: > CVSROOT: /cvs > Module name: ports > Changes by: c...@cvs.openbsd.org2020/08/19 08:06:51 > > Log message: > Import www/p5-Catalyst-Action-REST > > This Action handles doing automatic method dispatching for REST > requests. It takes a normal Catalyst action, and changes the > dispatch to append an underscore and method name. First it will try > dispatching to an action with the generated name, and failing that it > will try to dispatch to a regular method. > > OK afresh1@ > > Status: > > Vendor Tag: cwen > Release Tags: cwen_20200819 > > N ports/www/p5-Catalyst-Action-REST/Makefile > N ports/www/p5-Catalyst-Action-REST/distinfo > N ports/www/p5-Catalyst-Action-REST/pkg/DESCR > N ports/www/p5-Catalyst-Action-REST/pkg/PLIST > > No conflicts created by this import > Sorry i forgot to mention this comes from Wen Heping!
Re: CVS: cvs.openbsd.org: ports
On Fri, 24 Apr 2020 10:17:35 -0600 (MDT) Charlene Wendling wrote: > CVSROOT: /cvs > Module name: ports > Changes by: c...@cvs.openbsd.org2020/04/24 10:17:35 > > Modified files: > productivity/novprog: Makefile > > Log message: > novprog: drop 'atomic' from WANTLIB for powerpc, it breaks the build > and is not needed anymore with base-clang on this arch. > > OK bcallah@ (maintainer) > And OK kmos@ as well.
Re: CVS: cvs.openbsd.org: ports
On Tue, 4 Feb 2020 15:54:09 -0700 (MST)
Charlene Wendling wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: c...@cvs.openbsd.org2020/02/04 15:54:09
>
> Modified files:
> games/frozen-bubble: Makefile
> Added files:
> games/frozen-bubble/patches: patch-c_stuff_fb_c_stuff_xs
>patch-c_stuff_lib_FBLE_pm
>patch-frozen-bubble
>
> Log message:
> Add various fixes to frozen-bubble:
>
> - allow building with base-clang (from gkoehler@, thanks!)
> - remove BROKEN-{amd64,i386} after gkoehler@'s p5-SDL fix
^ Wrong, actually the BROKEN lines were removed in the p5-SDL
commit/Makefile. But frozen-bubble is unbroken on these archs for
real.
> - replace various use of my() in false conditionals, it's fatal
> with Perl 5.30
> - deinterlace some PNGs to silence some libpng warnings
>
> OK gkoehler@ afresh1@ (who tested on sparc64 and i386)
>
Re: CVS: cvs.openbsd.org: ports
On Sun, 24 Nov 2019 03:53:42 -0700 (MST) Charlene Wendling wrote: > CVSROOT: /cvs > Module name: ports > Changes by: c...@cvs.openbsd.org2019/11/24 03:53:42 > > Modified files: > devel/libvterm/patches: patch-bin_vterm-ctrl_c > Added files: > devel/libvterm/patches: patch-Makefile > > Log message: > > (cvs did not abort on blank commit message as i expected) libvterm: drop `-Wpedantic' so it still builds on base-gcc archs with the default compiler. While here, convert a git-styled patch to what cvs(1) expect, making update-patches(1) happy. OK edd@ (maintainer)
Re: CVS: cvs.openbsd.org: ports
On Fri, 30 Aug 2019 13:54:47 -0600 (MDT) Charlene Wendling wrote: > CVSROOT: /cvs > Module name: ports > Changes by: c...@cvs.openbsd.org2019/08/30 13:54:47 > > Modified files: > databases/p5-Mojo-Pg: Makefile distinfo > > Log message: > p5-Mojo-Pg: update to 4.15 > Changelog: > https://metacpan.org/source/SRI/Mojo-Pg-4.15/Changes > > OK maintainer > Sorry! I forgot to mention it was from Wen Heping.
Re: CVS: cvs.openbsd.org: ports
On Fri, 16 Aug 2019 17:27:09 -0600 (MDT) Charlene Wendling wrote: > CVSROOT: /cvs > Module name: ports > Changes by: c...@cvs.openbsd.org2019/08/16 17:27:09 > > Modified files: > devel/angr/py-z3-solver: Makefile > Added files: > devel/angr/py-z3-solver/patches: > > patch-core_src_util_lp_permutation_matrix_h > > Log message: > py-z3-solver: unbreak with ports-gcc, by fixing an incorrect > conversion. Tested on sparc64 (by kmos@, thanks!) and macppc. > > OK kmos@ kn@ (maintainer) > And OK jasper@ who co-maintains the port.
Re: CVS: cvs.openbsd.org: ports
On Sun, 7 Jul 2019 10:58:46 -0600 (MDT) Charlene Wendling wrote: > CVSROOT: /cvs > Module name: ports > Changes by: c...@cvs.openbsd.org2019/07/07 10:58:46 > > Modified files: > audio/taglib : Makefile > Added files: > audio/taglib/patches: patch-tests_test_synchdata_cpp > > Log message: > taglib: fix narrowing issues on arm and ppc, unbreak the build. > Tested on macppc. I've forgotten to mention that i moved to PERMIT_PACKAGE. > OK jca@ >
Re: CVS: cvs.openbsd.org: ports
On Fri, 17 May 2019 14:23:24 -0600 (MDT) Charlene Wendling wrote: > CVSROOT: /cvs > Module name: ports > Changes by: c...@cvs.openbsd.org2019/05/17 14:23:24 > > Modified files: > devel/p5-Term-Encoding: Makefile distinfo > > Log message: > p5-Term-Encoding: update to 0.03 > Changelog: > https://metacpan.org/release/MIYAGAWA/Term-Encoding-0.03 > *sigh* This one wasn't OK'ed, i've taken the wrong list. Sorry.
Re: CVS: cvs.openbsd.org: ports
On Wed, 15 May 2019 07:34:58 -0600 (MDT) Charlene Wendling wrote: > CVSROOT: /cvs > Module name: ports > Changes by: c...@cvs.openbsd.org2019/05/15 07:34:58 > > Modified files: > www/p5-HTTP-Headers-Fast: Makefile distinfo > > Log message: > p5-HTTP-Headers-Fast: update to 0.22 > Changelog: > https://metacpan.org/source/TOKUHIROM/HTTP-Headers-Fast-0.22/Changes > > tweaks and OK afresh1@ > I've totally forgotten to mention that it's an original submission from Wen Heping (thanks!), sorry.
Re: untangling some bsd.port.mk permissions
On Thu, 9 May 2019 22:35:10 +0200
Marc Espie wrote:
> On Thu, May 09, 2019 at 10:22:48PM +0200, Charlène Wendling wrote:
> > make update-plist
> > =
> >
> > => doas /usr/bin/perl /usr/ports/infrastructure/bin/update-plist
> >
> > In mk/pkgpath.mk there is this:
> >
> > _PERLSCRIPT = /usr/bin/perl ${PORTSDIR}/infrastructure/bin
> >
> > After removing the perl invocation the problem is getting fishier:
> >
> > - /usr/ports/infrastructure/bin/update-plist is executable, fine
> > - /usr/ports/infrastructure/bin/port-getpkgpath-helper is not
> > executable, i chmoded +x it to see how deep it goes
> > - then it calls 'doas /usr/ports/infrastructure/bin/update-plist'
> > - and it croaks:
>
> Those are a problem, because you can't really enforce +x under source
> directories. Removing the _PERLSCRIPT everywhere is a bad idea.
>
> (note that src suffers from the same issue and explicitly prefix with
> /bin/sh every script it's going to run).
>
> The only script that really wants root is update-plist. Entering a
> password for that one looks admissible.
I agree, as you propose it, i think it's already nice enough, this
reduces massively the count of password prompts with PORT_PRIVSEP
and "permit keepenv $USER", and anyway if you set doas as this,
you know you're gonna type your password often.
> > make clean=packages
> > ===
> >
> > - my user account wants to rm:
> > /usr/ports/packages/amd64/cache/portname.tgz
> > and it belongs to _pfetch, so i needed this in bsd.port.mk:
> >
> > @@ -3120,10 +3120,10 @@ _internal-clean:
> > .endif
> > .if ${_clean:Mpackages} || ${_clean:Mpackage} && ${_clean:Msub}
> > ${_PBUILD} rm -f ${_PACKAGE_COOKIES}
> > - rm -f ${_UPDATE_COOKIES} ${_CACHE_PACKAGE_COOKIES}
> > + ${_PFETCH} rm -f ${_UPDATE_COOKIES} $
> > {_CACHE_PACKAGE_COOKIES} .elif ${_clean:Mpackage}
> > ${_PBUILD} rm -f ${_PACKAGE_COOKIES${SUBPACKAGE}}
> > - rm -f ${_UPDATE_COOKIE${SUBPACKAGE}}
> > + ${_PFETCH} rm -f ${_UPDATE_COOKIE${SUBPACKAGE}}
>
>
> Err, this is weird. ${_CACHE_PACKAGE_COOKIES} will indeed belong to
> _pfetch. Not so for ${_UPDATE_COOKIES}
>
It was a wild guess, after the mess i did to get up to this point, i
understood that there was no future for this, and cut to the chase.
Re: untangling some bsd.port.mk permissions
Hi,
On Wed, 8 May 2019 21:00:57 +0200
Marc Espie wrote:
> In a few places, bsd.port.mk does
> doas /usr/bin/env -i ${_TERM_ENV}
> TRUSTED_PKG_PATH=... /usr/sbin/pkg_add
>
> On the one hand, env allows virtually everything to execute;
> on the other hand, swapping things around means keepenv has to be used
> correctly.
>
> Looking closer at the actual usage pattern, the env variables
> concerned are:
>
> - TERM: necessary for correct progressmeter
> - TERMCAP: good for people with bad terminal configuration.
> Definitely not something to trust in doas.conf
> - ftp_proxy/http_proxy: useful in general, but those pkg_add
> invocations are actually local
> - TRUSTED_PKG_PATH: *TOTALLY* necessary. This prevents pkg_add from
> looking in other locations, and replaces a former -Dunsigned which
> did remove signature handling from everywhere and not just the
> correct directory.
>
> Inspired by Charlene's idea of fixing the path to touch, I think we
> want the patch that follows.
As you already know, it works fine for me, thanks!
> Plus: people will have a full list of what's needed to run as root for
> ports work.
I've found more (i'm describing issues as i have met them) to make it
"seamless":
make update-plist
=
=> doas /usr/bin/perl /usr/ports/infrastructure/bin/update-plist
In mk/pkgpath.mk there is this:
_PERLSCRIPT = /usr/bin/perl ${PORTSDIR}/infrastructure/bin
After removing the perl invocation the problem is getting fishier:
- /usr/ports/infrastructure/bin/update-plist is executable, fine
- /usr/ports/infrastructure/bin/port-getpkgpath-helper is not
executable, i chmoded +x it to see how deep it goes
- then it calls 'doas /usr/ports/infrastructure/bin/update-plist'
- and it croaks:
DON'T BUILD PORTS AS ROOT!
(or make sure you pass env variables PORTS_TREE_OWNER and
FAKE_TREE_OWNER thru doas to root)
- So i've changed my doas.conf accordingly, after reading
update-plist, i noticed it requires PORTSDIR to be set as
well, as seen in strip_dependency_directories() iiuc,
or i have this:
update-plist: Prefix required
- /usr/ports/infrastructure/bin/port-resolve-lib-helper needs
also to be chmoded +x
make install/reinstall
==
- /usr/ports/infrastructure/bin/register-plist requires to be
chmoded +x as well
make clean=packages
===
- my user account wants to rm:
/usr/ports/packages/amd64/cache/portname.tgz
and it belongs to _pfetch, so i needed this in bsd.port.mk:
@@ -3120,10 +3120,10 @@ _internal-clean:
.endif
.if ${_clean:Mpackages} || ${_clean:Mpackage} && ${_clean:Msub}
${_PBUILD} rm -f ${_PACKAGE_COOKIES}
- rm -f ${_UPDATE_COOKIES} ${_CACHE_PACKAGE_COOKIES}
+ ${_PFETCH} rm -f ${_UPDATE_COOKIES} ${_CACHE_PACKAGE_COOKIES}
.elif ${_clean:Mpackage}
${_PBUILD} rm -f ${_PACKAGE_COOKIES${SUBPACKAGE}}
- rm -f ${_UPDATE_COOKIE${SUBPACKAGE}}
+ ${_PFETCH} rm -f ${_UPDATE_COOKIE${SUBPACKAGE}}
doas.conf
=
permit keepenv charlene
[...]
permit nopass keepenv charlene as _pbuild
permit nopass keepenv charlene as _pfetch
permit nopass setenv { TRUSTED_PKG_PATH TERM } charlene cmd /usr/bin/touch
permit nopass setenv { TRUSTED_PKG_PATH TERM } charlene cmd /usr/sbin/pkg_delete
permit nopass setenv { TRUSTED_PKG_PATH TERM } charlene cmd /usr/sbin/pkg_add
permit nopass setenv { PORTSDIR PORTS_TREE_OWNER FAKE_TREE_OWNER
TRUSTED_PKG_PATH TERM } \
charlene cmd /usr/ports/infrastructure/bin/update-plist
> Minus: if you don't keepenv TRUSTED_PKG_PATH, things will stop
> working. If you don't keepenv TERM, pkg_add will lose its
> progressmeter.
>
> (that said, pkg_delete already has the same issue and it doesn't look
> like people protest)
>
> okay, objections ?
None of these two in my case, i just wanted to report the issues i met
if one doesn't want to input root password during port works. I may
have missed some stuff, or lacking foresight though.
I had fun anyway!
Charlène.
[PATCH] sysutils/neofetch
Hi ports! Here is a patch for neofetch that got upstreamed [1]. It adds support for hw.sensors.acpibat0.amphour kernel states so battery status is reported on any laptop, and charging status. To test the feature you'll need to uncomment info "Battery" in ~/.config/neofetch/config.conf They're still non-working-but-silented features for neofetch on OpenBSD, that i've added/fixed [2]. My plan was to wait to make a single patch, but upstream is slow to react (almost 1 month as i'm writing this), and the code tested only on my machines, so i won't add them for now. Reviews and OK are welcome! Charlène. [1] https://github.com/dylanaraps/neofetch/pull/1056 [2] https://github.com/dylanaraps/neofetch/pull/1058 neofetch.diff Description: Binary data
Re: NEW: devel/cmark
On Fri, 10 Aug 2018 14:45:19 +0100 Stuart Henderson wrote: > It's already committed. > Sorry for the noise, i may have not noticed something has gone wrong during the initial tree fetch on this machine :( > On 2018/08/10 15:19, Charlène wrote: > > On Thu, 2 Aug 2018 20:34:36 +0200 > > Jan Klemkow wrote: > > > > > Hi Rafael, > > > > > > On Thu, Aug 02, 2018 at 06:31:53PM +0200, Rafael Sadowski wrote: > > > > On Thu Aug 02, 2018 at 05:36:13PM +0200, Jan Klemkow wrote: > > > > > Hi Rafael, > > > > > > > > > > I also worked on an cmark port. I took your tar ball and > > > > > fixed all comments Stuart pointed out. Just, the MAINTAINER > > > > > field is still unset, But, a portscheck run does not require > > > > > this field. > > > > > > > > > > I replaced the manual DISTFILE and MASTER_SITE handling by the > > > > > GH_* variables, moved it to category "textproc" and correct > > > > > some spacing. > > > > > > > > That wasn't the way to go and the spacing was fine -- trust me > > > > or use vim. Please see my traball. > > > > > > You are right, I missed some spaces. But, I already used vim ;-) > > > > > > > > > > > > > Hopefully that helps you. I also need this tool for a private > > > > > project of mine. > > > > > > > > Would you like to take MAINTAINER? > > > > > > Yes, I can do that. See my attached tar ball. I removed a > > > useless line and replaced some spaces by tabs. And it uses the > > > GH_* variables. > > > > > > Hope that's fine for all so far. > > > > > > Thanks, > > > Jan > > > > Hi! > > > > I'd be happy to see cmark added to ports too. > > > > The build and runtime works fine on i386, i tested old personal > > projects that used it and John Gruber's test suite [1] without any > > issue. > > > > Charlène. > > > > [1] > > http://daringfireball.net/projects/downloads/MarkdownTest_1.0.zip > > > > >
Re: NEW: devel/cmark
On Thu, 2 Aug 2018 20:34:36 +0200 Jan Klemkow wrote: > Hi Rafael, > > On Thu, Aug 02, 2018 at 06:31:53PM +0200, Rafael Sadowski wrote: > > On Thu Aug 02, 2018 at 05:36:13PM +0200, Jan Klemkow wrote: > > > Hi Rafael, > > > > > > I also worked on an cmark port. I took your tar ball and fixed > > > all comments Stuart pointed out. Just, the MAINTAINER field is > > > still unset, But, a portscheck run does not require this field. > > > > > > I replaced the manual DISTFILE and MASTER_SITE handling by the > > > GH_* variables, moved it to category "textproc" and correct some > > > spacing. > > > > That wasn't the way to go and the spacing was fine -- trust me or > > use vim. Please see my traball. > > You are right, I missed some spaces. But, I already used vim ;-) > > > > > > > Hopefully that helps you. I also need this tool for a private > > > project of mine. > > > > Would you like to take MAINTAINER? > > Yes, I can do that. See my attached tar ball. I removed a useless > line and replaced some spaces by tabs. And it uses the GH_* > variables. > > Hope that's fine for all so far. > > Thanks, > Jan Hi! I'd be happy to see cmark added to ports too. The build and runtime works fine on i386, i tested old personal projects that used it and John Gruber's test suite [1] without any issue. Charlène. [1] http://daringfireball.net/projects/downloads/MarkdownTest_1.0.zip
Re: [UPDATE] www/p5-WebService-MusicBrainz-1.0.4 for audio/abcde
On Wed, 8 Aug 2018 09:17:52 +0100 Stuart Henderson wrote: > On 2018/08/07 20:27, Charlène wrote: > > On Mon, 6 Aug 2018 10:52:23 +0200 > > Charlène wrote: > > > > > Hi, > > > > > > I'm currently working on an update for audio/abcde, that requires > > > this update and a new port (audio/p5-MusicBrainz-DiscID). > > > > > > Abcde wants WebService::MusicBrainz v1.0.4, the latest release as > > > i'm writing this. > > > > > > Many things changed, i'm quoting upstream: > > > > > > « Version 1.0 and future releases are not backward compatible with > > > pre-1.0 releases. This is a complete re-write using version 2.0 > > > of the MusicBrainz API and Mojolicious. » > > > > > > So i've checked with sqlports, no other ports than the future > > > updated audio/abcde depends on this port. > > > > > > I'm also joining a very basic script, if you want to test the > > > module. > > > > > > Comments and OK are welcome! > > > > > > Charlène. > > > > Hi, > > > > I'm proposing myself as MAINTAINER for this port, so i'm joining a > > new diff. > > > > Charlène. > > +LIB_DEPENDS= www/p5-Mojo>=7.13 > > LIB_DEPENDS is the wrong thing for Perl modules, they are RUN_DEPENDS. > > LIB_DEPENDS without an associated WANTLIB is always wrong. > > Hi Stuart, Thanks for reviewing, i'm taking note of it and changed accordingly, also removed a spacing inconsistency on MAINTAINER line. I've retested those changes, it builds and runs fine on my amd64 machine. Charlène. p5-WebService-MusicBrainz.diff Description: Binary data
Re: [UPDATE] audio/abcde 2.7.2 -> 2.9.2
On Mon, 6 Aug 2018 11:14:18 +0200 Charlène wrote: > Hi! > > Here is an update for audio/abcde, that requires the updated > www/p5-WebService-MusicBrainz and the new audio/p5-MusicBrainz-DiscID > ports i've submitted earlier. > > We are currently several versions behind and the changelog is too huge > to detail here [1]. The biggest changes: > > - It now requires Perl to access the musicbrainz.org v2.0 API, that > has become the default over CDDB (which is still available) to fetch > tracks informations. > - MP3 encoding now requires audio/py-eyed3 with the default > configuration file. Our port only supports the default OGG Vorbis > encoding, so it hasn't been added to the Makefile as a RUN_DEPENDS, > but DESCR has been updated accordingly. > > I also added a patch because abcde wasn't able to get tracks offsets > from cdparanoia on OpenBSD and submitted a bug report to upstream [2] Good news, the issue has been fixed upstream: https://abcde.einval.com/bugzilla/show_bug.cgi?id=86#c2 Their solution is a bit different, my patch has been changed accordingly, also i'm proposing to maintain this port. Charlène. > As usual, any comment is welcome! > > Charlène. > > > [1] > https://git.einval.com/cgi-bin/gitweb.cgi?p=abcde.git;a=blob;f=changelog;h=aff1e8fff4105ee636203766562242465c899009;hb=7f06cdc02d1ef02794d9a0ee2f5ab28470420548 > [2] https://abcde.einval.com/bugzilla/show_bug.cgi?id=86 abcde.diff Description: Binary data
Re: [UPDATE] www/p5-WebService-MusicBrainz-1.0.4 for audio/abcde
On Mon, 6 Aug 2018 10:52:23 +0200 Charlène wrote: > Hi, > > I'm currently working on an update for audio/abcde, that requires > this update and a new port (audio/p5-MusicBrainz-DiscID). > > Abcde wants WebService::MusicBrainz v1.0.4, the latest release as i'm > writing this. > > Many things changed, i'm quoting upstream: > > « Version 1.0 and future releases are not backward compatible with > pre-1.0 releases. This is a complete re-write using version 2.0 > of the MusicBrainz API and Mojolicious. » > > So i've checked with sqlports, no other ports than the future updated > audio/abcde depends on this port. > > I'm also joining a very basic script, if you want to test the module. > > Comments and OK are welcome! > > Charlène. Hi, I'm proposing myself as MAINTAINER for this port, so i'm joining a new diff. Charlène. p5-WebService-MusicBrainz.diff Description: Binary data
Re: [NEW] audio/p5-MusicBrainz-DiscID-0.0.4 for audio/abcde
On Mon, 6 Aug 2018 16:31:04 -0400 Brian Callahan wrote: > > On 8/6/18 4:59 AM, Charlène wrote: > > Hi, > > > > I'm proposing this XS Perl module, because it will be required in > > order to update audio/abcde to its latest release. > > > > >From DESCR: > > > > MusicBrainz::DiscID is a Perl class to calculate a MusicBrainz > > DiscID from an audio CD in the drive. > > > > Homepage: http://search.cpan.org/dist/MusicBrainz-DiscID/ > > > > It builds and works on amd64, but i have no other architecture to > > test against, so testing and comments are welcome! > > > > I'm also joining a small test script that gives you a link to the > > MusicBrainz' table of content of the currently inserted audio CD. > > > > Charlène. > > Super minor style nit, as I understand it we prefer a space before > the = for variables (this also aligns with Makefile.template). > > Also, do you want to be MAINTAINER? Hi, I had to look at the XS code before giving an answer, it's a almost 1:1 interface to libdiscid, so i'll maintain it. I changed the Makefile as such. Charlène. > > ~Brian > p5-MusicBrainz-DiscID.tgz Description: Binary data
Re: [UPDATE] audio/abcde 2.7.2 -> 2.9.2
On Mon, 6 Aug 2018 11:44:16 +0200 Landry Breuil wrote: > On Mon, Aug 06, 2018 at 11:14:18AM +0200, Charlène wrote: > > Hi! > > > > Here is an update for audio/abcde, that requires the updated > > www/p5-WebService-MusicBrainz and the new > > audio/p5-MusicBrainz-DiscID ports i've submitted earlier. > > > > We are currently several versions behind and the changelog is too > > huge to detail here [1]. The biggest changes: > > > > - It now requires Perl to access the musicbrainz.org v2.0 API, that > > has become the default over CDDB (which is still available) to > > fetch tracks informations. > > - MP3 encoding now requires audio/py-eyed3 with the default > > configuration file. Our port only supports the default OGG Vorbis > > encoding, so it hasn't been added to the Makefile as a RUN_DEPENDS, > > but DESCR has been updated accordingly. > > > > I also added a patch because abcde wasn't able to get tracks offsets > > from cdparanoia on OpenBSD and submitted a bug report to upstream > > [2] > > > > As usual, any comment is welcome! > > This is nice but how much has this been tested ? There were attempts > to update it in the past months, and it was busted (cf > https://marc.info/?l=openbsd-ports=151722260128733=2, > https://marc.info/?t=15214970037=1=2) - a bug reporte was > opened upstream at > https://abcde.einval.com/bugzilla/show_bug.cgi?id=66. What i've successfully tested, under chroot build and runtime indeed, but also on my own system: - Using a 2.7.2 default ~/.abcde.conf with a 2.9.2 build causes no issues - MusicBrainz works, and CDDB still works if you instruct abcde to use it instead - Encoding: vorbis, speex, flac, mp3, aiff. Standalone and combined ( -o ogg,mp3...) - `abcde 1 3-5` rips tracks 1, 3, 4, 5 as expected. Due to the vast amount of options available, everything cannot be tested, but if somebody has a feature not included here they need to test with that port update, and has no time to build it and its new dependencies, feel free to send me a test case! > I dunno if that's the same issue, and if your patch from > https://abcde.einval.com/bugzilla/show_bug.cgi?id=86 fixes it, but it > would be nicer to clarify how much testing you've done :) > Oh, i should search the archive next time! The root issue is similar, but it has not the same consequences, on 2.9.1 and 2.9.2 it's a bash math evaluation failure instead. My awk proposal to upstream *may* be more portable because it's more basic, but as the wording in my upstream bug report implies, i would like to hear from them about it. Charlène. PS: This is how a successful run looks from here - https://octodon.social/@julianaito/100499923240970547
[UPDATE] audio/abcde 2.7.2 -> 2.9.2
Hi! Here is an update for audio/abcde, that requires the updated www/p5-WebService-MusicBrainz and the new audio/p5-MusicBrainz-DiscID ports i've submitted earlier. We are currently several versions behind and the changelog is too huge to detail here [1]. The biggest changes: - It now requires Perl to access the musicbrainz.org v2.0 API, that has become the default over CDDB (which is still available) to fetch tracks informations. - MP3 encoding now requires audio/py-eyed3 with the default configuration file. Our port only supports the default OGG Vorbis encoding, so it hasn't been added to the Makefile as a RUN_DEPENDS, but DESCR has been updated accordingly. I also added a patch because abcde wasn't able to get tracks offsets from cdparanoia on OpenBSD and submitted a bug report to upstream [2] As usual, any comment is welcome! Charlène. [1] https://git.einval.com/cgi-bin/gitweb.cgi?p=abcde.git;a=blob;f=changelog;h=aff1e8fff4105ee636203766562242465c899009;hb=7f06cdc02d1ef02794d9a0ee2f5ab28470420548 [2] https://abcde.einval.com/bugzilla/show_bug.cgi?id=86 abcde.diff Description: Binary data
[NEW] audio/p5-MusicBrainz-DiscID-0.0.4 for audio/abcde
Hi, I'm proposing this XS Perl module, because it will be required in order to update audio/abcde to its latest release. >From DESCR: MusicBrainz::DiscID is a Perl class to calculate a MusicBrainz DiscID from an audio CD in the drive. Homepage: http://search.cpan.org/dist/MusicBrainz-DiscID/ It builds and works on amd64, but i have no other architecture to test against, so testing and comments are welcome! I'm also joining a small test script that gives you a link to the MusicBrainz' table of content of the currently inserted audio CD. Charlène. test_p5-MBDI.pl Description: Binary data p5-MusicBrainz-DiscID.tgz Description: Binary data
[UPDATE] www/p5-WebService-MusicBrainz-1.0.4 for audio/abcde
Hi, I'm currently working on an update for audio/abcde, that requires this update and a new port (audio/p5-MusicBrainz-DiscID). Abcde wants WebService::MusicBrainz v1.0.4, the latest release as i'm writing this. Many things changed, i'm quoting upstream: « Version 1.0 and future releases are not backward compatible with pre-1.0 releases. This is a complete re-write using version 2.0 of the MusicBrainz API and Mojolicious. » So i've checked with sqlports, no other ports than the future updated audio/abcde depends on this port. I'm also joining a very basic script, if you want to test the module. Comments and OK are welcome! Charlène. test_p5-WSMB.pl Description: Binary data p5-WebService-MusicBrainz.diff Description: Binary data
Re: [PATCH] sysutils/screenfetch
Hi,
On Thu, 2 Aug 2018 18:07:33 -0400
Brian Callahan wrote:
> Hi Charlène --
>
> On 08/01/18 16:06, Charlène wrote:
> > Hi,
> >
> > I'm joining a new diff after Brian's comments.
> >
> > On Wed, 1 Aug 2018 02:17:37 -0400
> > Brian Callahan wrote:
> >
> >> Hi Charlène --
> >>
> >> On 07/30/18 14:22, Charlène wrote:
> >>> Hi,
> >>>
> >>> I'm proposing several changes to this port:
> >>>
> >>> Makefile:
> >>>
> >>> * cleaned extra tabs after '='
> >>> * use INSTALL_MAN instead of INSTALL_SCRIPT for the
> >>> manpage
> >>> * added myself as MAINTAINER, currently it's "orphaned"
> >>> * incremented REVISION
> >>> * added braces for variables
> >> Some of these I'm OK with, some I'm not super sure about.
> >> Yes, I think it's worthwhile to use INSTALL_MAN.
> >> Glad to see you taking MAINTAINER.
> >> Glad to see the updated patches.
> >>
> >> Braces around variables are not strictly needed in this case; it
> >> becomes a matter of style in this particular instance. But it might
> >> be even better to change PKGNAME to ${DISTNAME:L} and change
> >> GH_TAGNAME to v3.8.0 -- that would completely eliminate the need
> >> for a V variable in the first place.
> > I changed to what you recommend. You made me finally understand
> > that bsd.port.mk is a great source of documentation by itself,
> > thanks!
>
> Since it looks like we're going this route, Makefile.template says
> CATEGORIES comes after PKGNAME.
> So the first block should be:
> COMMENT
> PKGNAME
> REVISION
>
> Makefile.template also says that CATEGORIES comes after the GH_*
> variables, though I see plenty of ports that put CATEGORIES directly
> under DISTNAME/PKGNAME, as it would be if there were no GH_*
> variables. According to your diff, CATEGORIES was placed according to
> Makefile.template and be kept there.
>
> ~Brian
I reordered the Makefile according to Makefile.template.
Charlène.
> >> I'm more inclined to leave extra tabs in once a port has been
> >> imported, unless you're otherwise changing the line anyway, which
> >> you're not here. Especially in this case, where things are aligned
> >> anyway, I'm not sure removing the extra tabs improves readability.
> >> But I guess if you're going to do this, now would be the time.
> > I was advised to do so for sysutils/neofetch, so i applied the same
> > thing for this port. I entirely agree about the fact that it doesn't
> > improve (or worsen) readability here. I've let it as-is for this
> > time, but i take note for future works.
> >
> > Charlène.
> >
> >> ~Brian
> >>
> >>> patches, already in upstream's master branch but not in a release:
> >>>
> >>> * fixed "awk: cannot open /proc/fb" [1]
> >>> * fixed "unary operator expected" when no GPU is detected
> >>> [2]
> >>>
> >>> Testing:
> >>>
> >>> It has been successfully tested using proot, but you'll need to
> >>> copy /var/run/dmesg.boot in your chroot to check the output of the
> >>> program, as it uses this file for OS detection.
> >>>
> >>> Comments and OK are welcome!
> >>>
> >>> Charlène.
> >>>
> >>> [1]
> >>> https://github.com/KittyKatt/screenFetch/commit/dc72b5932e86ba9c4e36110408690abeb2004070
> >>> [2]
> >>> https://github.com/KittyKatt/screenFetch/commit/8346a75068323692243805fa702d02ec7538f3b9
> >>>
> >>>
>
screenfetch.diff
Description: Binary data
Re: [PATCH] sysutils/screenfetch
Hi,
I'm joining a new diff after Brian's comments.
On Wed, 1 Aug 2018 02:17:37 -0400
Brian Callahan wrote:
> Hi Charlène --
>
> On 07/30/18 14:22, Charlène wrote:
> > Hi,
> >
> > I'm proposing several changes to this port:
> >
> > Makefile:
> >
> > * cleaned extra tabs after '='
> > * use INSTALL_MAN instead of INSTALL_SCRIPT for the manpage
> > * added myself as MAINTAINER, currently it's "orphaned"
> > * incremented REVISION
> > * added braces for variables
>
> Some of these I'm OK with, some I'm not super sure about.
> Yes, I think it's worthwhile to use INSTALL_MAN.
> Glad to see you taking MAINTAINER.
> Glad to see the updated patches.
>
> Braces around variables are not strictly needed in this case; it
> becomes a matter of style in this particular instance. But it might
> be even better to change PKGNAME to ${DISTNAME:L} and change
> GH_TAGNAME to v3.8.0 -- that would completely eliminate the need for
> a V variable in the first place.
I changed to what you recommend. You made me finally understand
that bsd.port.mk is a great source of documentation by itself,
thanks!
> I'm more inclined to leave extra tabs in once a port has been
> imported, unless you're otherwise changing the line anyway, which
> you're not here. Especially in this case, where things are aligned
> anyway, I'm not sure removing the extra tabs improves readability.
> But I guess if you're going to do this, now would be the time.
I was advised to do so for sysutils/neofetch, so i applied the same
thing for this port. I entirely agree about the fact that it doesn't
improve (or worsen) readability here. I've let it as-is for this time,
but i take note for future works.
Charlène.
> ~Brian
>
> > patches, already in upstream's master branch but not in a release:
> >
> > * fixed "awk: cannot open /proc/fb" [1]
> > * fixed "unary operator expected" when no GPU is detected
> > [2]
> >
> > Testing:
> >
> > It has been successfully tested using proot, but you'll need to
> > copy /var/run/dmesg.boot in your chroot to check the output of the
> > program, as it uses this file for OS detection.
> >
> > Comments and OK are welcome!
> >
> > Charlène.
> >
> > [1]
> > https://github.com/KittyKatt/screenFetch/commit/dc72b5932e86ba9c4e36110408690abeb2004070
> > [2]
> > https://github.com/KittyKatt/screenFetch/commit/8346a75068323692243805fa702d02ec7538f3b9
> >
> >
>
screenfetch.diff
Description: Binary data
[PATCH] sysutils/screenfetch
Hi, I'm proposing several changes to this port: Makefile: * cleaned extra tabs after '=' * use INSTALL_MAN instead of INSTALL_SCRIPT for the manpage * added myself as MAINTAINER, currently it's "orphaned" * incremented REVISION * added braces for variables patches, already in upstream's master branch but not in a release: * fixed "awk: cannot open /proc/fb" [1] * fixed "unary operator expected" when no GPU is detected [2] Testing: It has been successfully tested using proot, but you'll need to copy /var/run/dmesg.boot in your chroot to check the output of the program, as it uses this file for OS detection. Comments and OK are welcome! Charlène. [1] https://github.com/KittyKatt/screenFetch/commit/dc72b5932e86ba9c4e36110408690abeb2004070 [2] https://github.com/KittyKatt/screenFetch/commit/8346a75068323692243805fa702d02ec7538f3b9 screenfetch.diff Description: Binary data
Re: NEW: lang/mujs
On Mon, 23 Jul 2018 17:05:34 -0400 Brian Callahan wrote: > Hi ports -- > > Attached is a new port, lang/mujs. MuJS is a lightweight, embeddable > Javascript interpreter. > > Works for me on amd64, armv7, and macppc. > > OK? > Hi! I've successfully tried some examples found in the html docs - by the way the port doesn't install them - and also tested the standalone interpreter: it's OK here on amd64. Charlène.
Re: NEW: sysutils/neofetch
Hi, Made 2 fixes to the port (thanks to Rafael Sadowski): - zapped extra space after GH_* - used INSTALL_MANPAGE for manpage installation instead of INSTALL_SCRIPT Charlène. neofetch.tgz Description: Binary data
NEW: sysutils/neofetch
Hi, I'm proposing neofetch, a command-line system information tool often used in desktop screenshots. Similar to sysutils/screenfetch, but with a different set of features. Homepage: https://github.com/dylanaraps/neofetch The port has been adapted from sysutils/screenfetch with tweaks from Brian Callahan after i asked him for a review. Any comments and tests are appreciated. Charlène. neofetch.tgz Description: Binary data
