Re: maintainer update: www/hugo
> Sent: Friday, May 22, 2020 at 10:04 AM
> From: "Paco Esteban"
> To: "Rafael Sadowski"
> Cc: "Todd C. Miller" , ports@openbsd.org
> Subject: Re: maintainer update: www/hugo
>
> On Fri, 22 May 2020, Rafael Sadowski wrote:
>
> > On Thu May 21, 2020 at 02:52:24PM -0600, Todd C. Miller wrote:
> > > On Thu, 21 May 2020 21:03:37 +0200, Paco Esteban wrote:
> > >
> > > > For now it does not work for me with the patch you sent. I get:
> > > >
> > > > #
> > > > github.com/gohugoio/hugo/vendor/github.com/bep/golibsass/internal/libsass
> > > > c99func.c:2:10: fatal error: '../../libsass_src/src/c99func.c' file not
> > > > found
> > > >
> > > > I'll take a deeper look tomorrow probably.
> >
> > That could be useful for SASS themes users. FLAVOR note is missing in
> > pkg/DESCR. The diff below builds fine.
>
> It builds now and works with one of the SASS themes I've found.
> I added the flavor description, diff at the end.
>
> Thank you Todd and Rafael.
>
> Comments ? ok ?
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/www/hugo/Makefile,v
> retrieving revision 1.20
> diff -u -p -r1.20 Makefile
> --- Makefile 21 May 2020 16:37:44 - 1.20
> +++ Makefile 22 May 2020 07:51:18 -
> @@ -26,6 +26,16 @@ ALL_TARGET = github.com/gohugoio/hugo
>
> SEPARATE_BUILD = Yes
>
> +FLAVORS =extended
> +FLAVOR ?=
> +
> +.if ${FLAVOR:Mextended}
> +MODGO_FLAGS += --tags extended
> +LIB_DEPENDS += www/libsass
> +WANTLIB += sass
> +MAKE_ENV += CGO_CPPFLAGS='-I${LOCALBASE}/include -DUSE_LIBSASS_SRC'
> CGO_LDFLAGS='-L${LOCALBASE}/lib -lsass'
> +.endif
> +
> post-build:
> cd ${MODGO_WORKSPACE}/bin/ && ./hugo gen man
>
> Index: pkg/DESCR
> ===
> RCS file: /home/cvs/ports/www/hugo/pkg/DESCR,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 DESCR
> --- pkg/DESCR 11 Jun 2018 21:17:14 - 1.1.1.1
> +++ pkg/DESCR 22 May 2020 07:56:30 -
> @@ -4,3 +4,7 @@ Hugo takes a directory with content and
> them into a full HTML website.
>
> Hugo relies on Markdown files with front matter for metadata.
> +
> +Flavors:
> + extended- build hugo extended version with Sass/SCSS
> + support amongst others
>
> --
> Paco Esteban.
> 0x5818130B8A6DBC03
Namaste Paco,
Would it be possible for us to fetch and build hugo directly from the
authoritative Github source, replacing https://e1e0.net/dist/?
I ask this because, if I am not wrong, @abieber has recently updated [1]
the portgen code with the following message:
...
With this a port can be easily generated for Go applications that
support Go modules (there will be a go.mod file in the root of the
project).
...
Namaste Aaron,
Thank you for your patience [2].
If I am not wrong, you specifically tested building hugo with the patch
while working on it. Unfortunately, I could not determine whether the
committed patch can build hugo or not.
Dhanyavaad,
ab
[1] -
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/infrastructure/bin/portgen?rev=1.2=text/x-cvsweb-markup
[2] - https://marc.info/?t=15758306843=1=2
-|-|-|-|-|-|-|--
Re: postgresql readme
> Sent: Tuesday, February 11, 2020 at 9:02 PM
> From: "Stuart Henderson"
> To: ports , "Pierre-Emmanuel André"
> Subject: postgresql readme
>
> It's always annoying to look through postgresql.conf to figure out which
> things you've changed and which are default settings.
>
> Fortunately with postgresql-previous we have a default postgresql.conf
> that's likely to be close to the one in the old version, so we can diff it
> to give a better picture. It's not perfect because it may have changed
> slightly in a minor release, and initdb makes some locale-related
> changes when it copies the file to /var/postgresql/data, but it beats
> going through 700+ lines by eye.
>
> OK to add that to the pkg-readme?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/databases/postgresql/Makefile,v
> retrieving revision 1.259
> diff -u -p -r1.259 Makefile
> --- Makefile 9 Feb 2020 09:38:45 - 1.259
> +++ Makefile 11 Feb 2020 20:57:45 -
> @@ -16,7 +16,7 @@ PKGNAME-docs= postgresql-docs-${VERSION}
> PKGNAME-contrib=postgresql-contrib-${VERSION}
> PKGNAME-plpython=postgresql-plpython-${VERSION}
> PKGNAME-pg_upgrade=postgresql-pg_upgrade-${VERSION}
> -REVISION-server=0
> +REVISION-server= 1
Namaste Stuart,
Thank you for the patch.
Would it be preferable to remove the extra space after the equal sign in
the REVISION-server line above?
>
> CATEGORIES= databases
> SHARED_LIBS= ecpg7.10 \
> Index: pkg/README-server
> ===
> RCS file: /cvs/ports/databases/postgresql/pkg/README-server,v
> retrieving revision 1.28
> diff -u -p -r1.28 README-server
> --- pkg/README-server 9 Feb 2020 09:38:45 - 1.28
> +++ pkg/README-server 11 Feb 2020 20:57:45 -
> @@ -131,7 +131,12 @@ to the current version.
> "cp /var/postgresql/data-${PREV_MAJOR}/server.{crt,key}
> /var/postgresql/data/"
>
> Some postgresql.conf settings changed or disappeared in this version.
> -Examine your old file for local changes and apply them to the new version.
> +Examine your old file for local changes and apply them to the new version
> +(/var/postgresql/data/postgresql.conf). The following command may help
> +identify them:
> +
> +# diff -wu
> ${LOCALBASE}/share/postgresql-${PREV_MAJOR}/postgresql.conf.sample \
> +/var/postgresql/data-${PREV_MAJOR}/postgresql.conf
>
> 7) Start PostgreSQL:
> # rcctl start postgresql
Dhanyavaad,
ab
-|-|-|-|-|-|-|--
Re: UPDATE fonts/overpass to 3.0.4
> Sent: Friday, January 24, 2020 at 1:40 PM
> From: "Stuart Henderson"
>
> On 2020/01/24 13:35, Aham Brahmasmi wrote:
> > Hi Stuart,
> >
> > > From: "Stuart Henderson"
> > > Subject: Re: UPDATE fonts/overpass to 3.0.4
> > >
> > > Is it really useful to include webfonts in the font packages? 4 copies of
> > > the same fonts in different formats does seem a bit much.
> >
> > I may be wrong here, but the webfonts might be useful in serving html
> > content - the user may install the font package for the webfont files
> > and serve the webfont files along with html content using httpd/relayd.
>
> Not from /usr/local though.
Agreed.
I imagine one may perhaps want to setup some symlinks from
/usr/local/ to /var/www/htdocs/fonts. Or rsync fonts
using a daily cron job to that directory. On the httpd/relayd side, one
could perhaps create, within individual server sections, a
location "/assets/fonts/*" {
root "/fonts"
request strip 2
}
Dhanyavaad,
ab
-|-|-|-|-|-|-|--
Re: UPDATE fonts/overpass to 3.0.4
Hi Stuart, > From: "Stuart Henderson" > Subject: Re: UPDATE fonts/overpass to 3.0.4 > > Is it really useful to include webfonts in the font packages? 4 copies of > the same fonts in different formats does seem a bit much. I may be wrong here, but the webfonts might be useful in serving html content - the user may install the font package for the webfont files and serve the webfont files along with html content using httpd/relayd. > -- > Sent from a phone, apologies for poor formatting. > > On 24 January 2020 02:07:02 George Rosamond > wrote: > > > Update to 3.0.4 attached. > > > > Minor changes to font, but Makefile changes include: > > > > - addition of README.md and LICENSE.md > > - inclusion of woff and woff2 fonts > > - www site to https > > > > Thanks > > > > g Dhanyavaad, ab -|-|-|-|-|-|-|--
Re: UPDATE: security/opendnssec
Hi Patrik, Pavel, > On Sun, Dec 30, 2018 at 03:27:42PM +0100, Rafael Sadowski wrote: > > On Sun Nov 18, 2018 at 04:57:55PM +0300, Pavel Korovin wrote: > > > Dear all, > > > please find the update for the latest OpenDNSSEC attached. > > > Tested with sqlite3, softhsm/softhsm2 on amd64. > > > Also tested migration from v1.4 (enforcer database migration is > > > required for v2). Спасибо Pavel for the v2 port. If I may ask, are there any specific OpenBSD related things to keep in mind while running OpenDNSSec v2? I ask this because it appears that there are some changes in the architecture in this version. > > It seems I missed this work completely somehow, sorry about that! > > Nice to see you are working on both opendnssec and softhsm 2.x :). > > I am actually not running opendnssec any more[1], if you would like to > take over maintainership I would be fine with that. This goes for > softhsm 1.x as well. > > > > > Is there any howto to migrate from 1.4? A note or an howto/link to > > current.html would be nice! > > > > There is an official note about this here: > https://wiki.opendnssec.org/pages/viewpage.action?pageId=10125376#HowdoI...?-UpgradeOpenDNSSEC1.4.9toOpenDNSSEC2.0 > > -- > Patrik Lundin > > [1]: https://blog.sigterm.se/posts/to-the-cloud-dns-edition/ Tack så mycket Patrik for that informative blog post. Could I request you to please help me with my queries: 1) Since the capability to run OpenBSD virtual machines is now present in the base, would you still suggest running authoritative DNS in "cloud" vs on VMs in on-premise/rented baremetal OpenBSD machines? I ask this because I have trouble relying on cloud, and as I have learnt, "free" in cloud usually translates to "you do not know how you pay". 2) Could you please elaborate on the custom built DNS server daemon? I find that very interesting, especially when combined with OpenDNSSEC. Dhanyavaad. Regards, ab -|-|-|-|-|-|-|--
Re: update: devel/subversion 1.11.0
Danke Stefan for your very helpful response. I apologize for the delay in my response. > > 2) If yes, would rw,nodev,nosuid,softdep,sync be appropriate fstab > > options to mount /var/svn? > > Don't use softdep! It risks repository corruption during a system crash. > > Use the same mount flags as the defaults for /var. I went back to the man page for mount(8) [1] to try to understand why I might have chosen softdep as a mount option. The explanation for softdep includes the following line: " Instead of metadata being written immediately, it is written in an ordered fashion to keep the on-disk state of the file system consistent. " I am a relative newcomer, so I inferred softdep as better because it helped "keep the on-disk state of the file system consistent". Clearly, I parsed it incorrectly if softdep can cause repository corruption during a crash. > > 3) What is a good svn repository backup routine? Any gotchas that should > > be kept in mind? > > The biggest concern is that backups should be created immediately after > a change has been committed, and that your backup should preferrably go to > a different physical machine. Use the post-commit hook to trigger a backup > (and the post-revprop-change hook, too, if your repository is configured > to allow revprop changes). > > As for getting a copy of repository data, there are a number of options. > > The fastest and smallest backup is provided by: > svnadmin hotcopy --incremental /var/svn/repo /data/backup/repo > It is safe to run this command in a post-commit hook. > But a local mount point for the destination is required. Incremental hotcopy > relies on file sizes and last-modified timestamps recorded in the filesystems > of source and destination. > If the destination is a network drive, make sure clocks between machine stay > in sync. No harm will be done when the clocks are out of sync, but it can > take a lot more time if timestamps don't match since data might be copied > redundantly. > > If you need to backup a repository across a network connection, then > take a look at 'svnsync' (requires a second SVN server) and 'svnrdump' > (backup requires read-access over network, backup can be restored > locally with 'svnadmin load'). > > There is also 'svnadmin freeze' but that is intended for use with an > underlying filesystem which supports snapshots, and OpenBSD does not > support any such filesystem. Danke for the exhaustive backup advice. Reading the useful SVN Redbook [2] highlighted some more distinctions between these approaches. Regards, ab [1] - https://man.openbsd.org/man8/mount.8 [2] - http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication -|-|-|-|-|-|-|--
Re: update: devel/subversion 1.11.0
Danke Stefan for your response. > I like your idea. I suppose /var/svn is a sane default path, and there > are already other cases where other parts create directories in /var. Yes, the Postgresql port uses /var/postgresql. I tried to find a best practice for the subversion directory. Most volks seemed to use /var/svn. > Would you be able to submit a diff to the port which implements > this idea? Unfortunately, I would not be able to as of now. But sometime in future, I do hope to contribute. I am sorry for this. While trying to determine the best practices, I encountered a few ideas. Would it be possible for volks to please share their thoughts on them: 1) Is it a good idea to make a separate disklabel partition /var/svn? 2) If yes, would rw,nodev,nosuid,softdep,sync be appropriate fstab options to mount /var/svn? 3) What is a good svn repository backup routine? Any gotchas that should be kept in mind? Regards, ab -|-|-|-|-|-|-|--
Re: update: devel/subversion 1.11.0
Hello ports, Apologies for removing the context, I joined the ports list recently and do not have stsp's original mail. I may be wrong here, but I was wondering whether we could change the home of the _svnserve user to /var/svn from the current /nonexistent. In other words, could we change from @newuser _svnserve:777:_svnserve:daemon:SVN Daemon:/nonexistent:/sbin/nologin to @newuser _svnserve:777:_svnserve:daemon:SVN Daemon:/var/svn:/sbin/nologin The idea is that post installation, one has to change the owner of the /var/svn/reponame directory to _svnserve anyways. Steps: $ doas pkg_add subversion $ cd /var $ doas mkdir svn $ cd /var/svn $ doas svnadmin create reponame $ doas chown -R _svnserve:_svnserve /var/svn/reponame $ doas mkdir log $ doas chown -R _svnserve:_svnserve /var/svn/log For more context, could I please refer you to my recent mail on misc - https://marc.info/?l=openbsd-misc=154221094309572=2. In case I am missing something or doing something stupid, please feel free to point it out. Thanks. Regards, ab -|-|-|-|-|-|-|--
Re: CVE-2018-18820 - Request to update Icecast to 2.4.4 security release
> > OK kn > > Thanks you, this has been committed to -current. > > > (note to myself) We should also add an CVE quirk for this. > > Done, along with a backport to 6.4. Thank you Jeremie and Klemens. Regards, ab -|-|-|-|-|-|-|--
CVE-2018-18820 - Request to update Icecast to 2.4.4 security release
Hello ports, Could I request the list to please update the Icecast port to 2.4.4? >From http://icecast.org/news/icecast-release_2_4_4/ : "We released a new version of Icecast. It is a security release and we recommend to update all Icecast installations of versions below 2.4.4 to it. ... Fixes Fix buffer overflows in URL auth code, [CVE-2018-18820] ... " I am writing to the list because the maintainer is listed as "The OpenBSD ports mailing-list" at http://openports.se/net/icecast. Regards, ab -|-|-|-|-|-|-|--
