Re: Reminder: freedb.org (CDDB) has shut down

[Daniel Engberg]

Hi,

I think it might be worth considering using freedb.dbpoweramp.com which
common software such as dbpoweramp and foobar200 uses and/or recommends.
It's also recommended on Hydrogenaudio forums:
https://hydrogenaud.io/index.php?topic=119006.msg981467#msg981467

In general one might want look into something that uses Musicbrainz as
it's considered to be better overall as far as I can tell.

Without any intention of hijacking the thread, has anyone looked at
porting Whipper to *BSD? https://github.com/whipper-team/whipper

Best regards,
Daniel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: set_rcvar() function use?

[Hiroki Sato]

Pavel Timofeev  wrote
  in :

ti> Hello, dear community. I'm confused, please, help me.
ti>
ti> There is a rc.subr function which was buried[1] and resurrected[2] after a
ti> couple of years in almost the same form.
ti>
ti> I don't know what happened behind the scenes, but I have a question.
ti> Is it a preferable way to define a rc.conf variable these days in rc
ti> scripts (again/over and over)?

 I resurrected it because I wanted to change the standard style to use
 set_rcvar() to declare the user-configurable variables, their default
 values, and descriptions without losing backward compatibility.
 There is no clear consensus on this migration, however.

 The primary motivation was to add multi-instance support in rc
 scrupts[1].  To support this, the set_rcvar() style was required.

 [1] 
https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052706.html

 Another issue I am aware of is that rc scripts installed by ports/pkg
 that they cannot have related entries in /etc/defaults/rc.conf for
 the default values.  So a lot of ports tend to end up with
 assignments in the rc scripts like this:

 : ${foo_enable=YES}

 This introduces inconsistency and it is difficult to find
 documentation about which knobs are available.  The set_rcvar() style
 should mitigate this and also implements a support to obsolete a
 variable when needed.  set_rcvar_obsolete() will convert the old
 value to the new variable automatically or emit an error if there is
 no compatibility between the old and the new.

 I committed set_rcvar() part only in [1], not whole of the
 multi-instance support.  This is because it was quite difficult to
 control which version of rc.subr is installed.  If rc scipts in ports
 use set_rcvar() on older versions of FreeBSD which do not support it,
 the port breaks.  At this moment all of the supported FreeBSD
 versions have the resurrected set_rcvar(), so I think it is now safe
 to use it globally.  Probably we might want to add a version number
 or feature flags in rc.subr to prevent this kind of situation.

 I am planning to revisit the multi-instance support shortly because I
 am using it for a long time and I think it is useful.  While I did
 not receive a strong objection to it so far, it is also true that
 adopting the set_rcvar() style was not discussed properly.  I would
 like more feedback before moving forward.

-- Hiroki


pgpGu8YqCnq10.pgp
Description: PGP signature

set_rcvar() function use?

[Pavel Timofeev]

Hello, dear community. I'm confused, please, help me.

There is a rc.subr function which was buried[1] and resurrected[2] after a
couple of years in almost the same form.

I don't know what happened behind the scenes, but I have a question.
Is it a preferable way to define a rc.conf variable these days in rc
scripts (again/over and over)?

If it is then I'd like to propose changes to FreeBSD porters handbook page
where basic rc script is described[3]


Also rc.subr(8) man page is missing set_rcvar() function description. BTW
it's missing a lot more functions description from rc.subr (are missing
functions for internal use only?)

If it's not then tell me please what it was resurrected for. Just curious
and for the record. I maintain several ports and want to know what is
considered the right/preferable way to write rc scripts.

[1]
https://lists.freebsd.org/pipermail/freebsd-current/2012-January/031246.html
 https://svnweb.freebsd.org/base?view=revision=230099
 https://svnweb.freebsd.org/base?view=revision=230103
 https://svnweb.freebsd.org/base?view=revision=230105
[2] https://svnweb.freebsd.org/base?view=revision=272393
[3]
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
graphics/xaos   | 4.0 | release-4.1
+-+
net-mgmt/netdata| 1.23.0  | v1.23.1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"