CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2018/07/02 23:06:54 Modified files: graphics/nomacs: Makefile distinfo graphics/nomacs/patches: patch-cmake_Unix_cmake graphics/nomacs/pkg: PLIST Log message: Update nomacs-3.10.0
UPDATE: sysutils/coreutils 8.29 => 8.30
Hi ports --
Attached is a fairly trivial update to the GNU coreutils. The NEWS file
indicates that this is mostly a bugfix update.
All but 2 tests pass (on amd64).
Giving this a spin on lesser user archs appreciated. I can do arm{,64}.
OK?
~Brian
Index: Makefile
===
RCS file: /cvs/ports/sysutils/coreutils/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile 30 Dec 2017 13:32:53 - 1.14
+++ Makefile 3 Jul 2018 04:19:54 -
@@ -2,7 +2,7 @@
COMMENT = file, shell and text manipulation utilities
-DISTNAME = coreutils-8.29
+DISTNAME = coreutils-8.30
CATEGORIES = sysutils
MAINTAINER = Brian Callahan
Index: distinfo
===
RCS file: /cvs/ports/sysutils/coreutils/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo 30 Dec 2017 13:32:53 - 1.8
+++ distinfo 3 Jul 2018 04:19:54 -
@@ -1,2 +1,2 @@
-SHA256 (coreutils-8.29.tar.xz) = ktD6HDEcrO+omFO9tTxi9BEM39o4IDRrWcvQmPQPlV4=
-SIZE (coreutils-8.29.tar.xz) = 5286588
+SHA256 (coreutils-8.30.tar.xz) = 6DGzqGCRSWzbpyBBH5dI3oFQd5j2Ewrervhy0gbhsFc=
+SIZE (coreutils-8.30.tar.xz) = 5359532
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/sysutils/coreutils/patches/patch-Makefile_in,v
retrieving revision 1.7
diff -u -p -r1.7 patch-Makefile_in
--- patches/patch-Makefile_in 30 Dec 2017 13:32:53 - 1.7
+++ patches/patch-Makefile_in 3 Jul 2018 04:19:54 -
@@ -5,7 +5,7 @@ XXX: Avoid rebuilding coreutils.info; ou
Index: Makefile.in
--- Makefile.in.orig
+++ Makefile.in
-@@ -11519,6 +11519,7 @@ doc/$(am__dirstamp):
+@@ -11527,6 +11527,7 @@ doc/$(am__dirstamp):
@: > doc/$(am__dirstamp)
$(srcdir)/doc/coreutils.info: doc/coreutils.texi $(srcdir)/doc/version.texi $(doc_coreutils_TEXINFOS)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2018/07/02 22:04:11 Modified files: lang/flang/flang: Makefile distinfo lang/flang/flang/patches: patch-runtime_flang_open_c patch-runtime_flang_unf_c lang/flang/libpgmath: Makefile distinfo Log message: Update to yesterday's flang version. Note the minor bump to libflang.
Re: Port submission tracking?
On 2018-07-02 18.02.08 -0500, Edward Lopez-Acosta wrote: > Is there another way ports are tracked besides the mailing list so > anyone can find a status without searching the archives? Not really, no. Mailing list archive + CVS repo are the best we have right now. It's not that no one wants this to change, but the change itself requires a lot of work. Really long, slightly ongoing, thread on how we could improve this, from misc@: https://marc.info/?l=openbsd-misc=149789110906191=2 (That thread starts as being about bugs@ but ports is mentioned somewhere in there, and the same concepts and concerns apply.) > I know I have some submissions which I fixed up upon request but no > idea if they were merged, and they are pending in the jasperla GitHub. > Additionally, there may be half done ports already out there that were > not merged, pending changes, no sense in people starting over on these The jasperla GitHub repo is convenient and nice for communicating whether someone is working on a difficult port, but it is not a source of truth. Note that I am just an observer (and port maintainer). -Mike
[UPDATE] security/plaso
Hi,
this is the diff to update plaso to latest release.
Ok?
Cheers,
Remi.
Index: Makefile
===
RCS file: /cvs/ports/security/plaso/Makefile,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 Makefile
--- Makefile 2 Jun 2018 12:01:59 - 1.9
+++ Makefile 2 Jul 2018 14:56:25 -
@@ -2,11 +2,8 @@
COMMENT = engine and tools to automate creation of super timeline
-MODPY_EGG_VERSION = 20180524
+MODPY_EGG_VERSION = 20180630
DISTNAME = plaso-${MODPY_EGG_VERSION}
-REVISION = 0
-
-DISTFILES = ${DISTNAME}_1{${DISTNAME}}${EXTRACT_SUFX}
CATEGORIES = security
@@ -77,16 +74,17 @@ RUN_DEPENDS += devel/ipython \
textproc/py-yaml \
www/py-requests \
www/py-urllib3 \
- textproc/py-elasticsearch \
devel/py-dtfabric \
devel/py-biplist
TEST_DEPENDS += devel/py-test \
${RUN_DEPENDS}
-# py-elasticsearch in ports in > 5.5.1, ignore error
+# py-elasticsearch in ports is > 5.5.1
+# mark elasticsearch as not required, so we can use plaso
post-extract:
- sed -i "s/maximum_version: 5.5.1/#maximum_version: 5.5.1/" ${WRKSRC}/dependencies.ini
+ sed -i "s/'5.5.1', True)/'5.5.1', False)/" ${WRKSRC}/plaso/dependencies.py
+ sed "/maximum_version: 5.5.1/d" ${WRKSRC}/dependencies.ini
pre-test:
touch ${WRKSRC}/utils/__init__.py
Index: distinfo
===
RCS file: /cvs/ports/security/plaso/distinfo,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 distinfo
--- distinfo 30 May 2018 09:13:46 - 1.7
+++ distinfo 2 Jul 2018 14:56:25 -
@@ -1,2 +1,2 @@
-SHA256 (plaso-20180524_1.tar.gz) = bjzAwg+eCK7He2fV9GbfJ55e+G3fEyWNB4zLMpPc4gc=
-SIZE (plaso-20180524_1.tar.gz) = 109661713
+SHA256 (plaso-20180630.tar.gz) = ADrsAu/wTvsSVosrua+GoopP4kFx07eGPo3rYmFMpbY=
+SIZE (plaso-20180630.tar.gz) = 109676002
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/plaso/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- pkg/PLIST 30 May 2018 09:13:46 - 1.6
+++ pkg/PLIST 2 Jul 2018 14:56:25 -
@@ -1,11 +1,10 @@
@comment $OpenBSD: PLIST,v 1.6 2018/05/30 09:13:46 rpointel Exp $
+@comment bin/__init__.py
bin/image_export.py
bin/log2timeline.py
bin/pinfo.py
bin/psort.py
bin/psteal.py
-lib/python${MODPY_VERSION}/
-lib/python${MODPY_VERSION}/site-packages/
lib/python${MODPY_VERSION}/site-packages/plaso/
lib/python${MODPY_VERSION}/site-packages/plaso-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/plaso-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
@@ -85,6 +84,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/plaso/cli/helpers/analysis_plugins.pyc
lib/python${MODPY_VERSION}/site-packages/plaso/cli/helpers/artifact_definitions.py
lib/python${MODPY_VERSION}/site-packages/plaso/cli/helpers/artifact_definitions.pyc
+lib/python${MODPY_VERSION}/site-packages/plaso/cli/helpers/artifact_filters.py
+lib/python${MODPY_VERSION}/site-packages/plaso/cli/helpers/artifact_filters.pyc
lib/python${MODPY_VERSION}/site-packages/plaso/cli/helpers/data_location.py
lib/python${MODPY_VERSION}/site-packages/plaso/cli/helpers/data_location.pyc
lib/python${MODPY_VERSION}/site-packages/plaso/cli/helpers/database_config.py
@@ -219,6 +220,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/plaso/engine/
lib/python${MODPY_VERSION}/site-packages/plaso/engine/__init__.py
lib/python${MODPY_VERSION}/site-packages/plaso/engine/__init__.pyc
+lib/python${MODPY_VERSION}/site-packages/plaso/engine/artifact_filters.py
+lib/python${MODPY_VERSION}/site-packages/plaso/engine/artifact_filters.pyc
lib/python${MODPY_VERSION}/site-packages/plaso/engine/configurations.py
lib/python${MODPY_VERSION}/site-packages/plaso/engine/configurations.pyc
lib/python${MODPY_VERSION}/site-packages/plaso/engine/engine.py
@@ -500,8 +503,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/plaso/lib/specification.pyc
lib/python${MODPY_VERSION}/site-packages/plaso/lib/timelib.py
lib/python${MODPY_VERSION}/site-packages/plaso/lib/timelib.pyc
-lib/python${MODPY_VERSION}/site-packages/plaso/lib/utils.py
-lib/python${MODPY_VERSION}/site-packages/plaso/lib/utils.pyc
lib/python${MODPY_VERSION}/site-packages/plaso/multi_processing/
lib/python${MODPY_VERSION}/site-packages/plaso/multi_processing/__init__.py
lib/python${MODPY_VERSION}/site-packages/plaso/multi_processing/__init__.pyc
@@ -577,6 +578,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/plaso/parsers/android_app_usage.pyc
lib/python${MODPY_VERSION}/site-packages/plaso/parsers/asl.py
lib/python${MODPY_VERSION}/site-packages/plaso/parsers/asl.pyc
+lib/python${MODPY_VERSION}/site-packages/plaso/parsers/asl.yaml
lib/python${MODPY_VERSION}/site-packages/plaso/parsers/bash_history.py
Port submission tracking?
Hello all, Is there another way ports are tracked besides the mailing list so anyone can find a status without searching the archives? I know about the jasperla repository on GitHub for ports but I was curious if they were tracked in some other way as well. For instance FreeBSD uses bugzilla for submissions and then the issue is closed when the port is merged. I understand OpenBSD does stuff in their own way, but this just had me thinking. I know I have some submissions which I fixed up upon request but no idea if they were merged, and they are pending in the jasperla GitHub. Additionally, there may be half done ports already out there that were not merged, pending changes, no sense in people starting over on these if someone already started the process. Thank you. -- Edward Lopez-Acosta
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2018/07/02 16:20:20 Modified files: lang/myrddin : Makefile distinfo Log message: Update myrddin to 0.3.1 which is a noop on OpenBSD, but brings us up to date none the less.
Re: NEW: net/bitcoin
add here's the missing diff xD Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz < fabian.ra...@gmail.com>: > Hi > > i've been running a bitcoin node for the last two weeks and everything > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and > used it in combination with lnd [0] (in testnet) > > Please find the attached diff with two small improvements to the rc file: > - add daemon_timeout=300. The daemon need time to shutdown successfully > (syncing to disk). 300 sec. was choosen randomly but this value worked for > me in several restarts. > - remove pid_file. It works even without specifying it. > > With this, the port looks ok to me :) > > Cheer, > Fabian > > [0] https://github.com/lightningnetwork/lnd > > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski < > raf...@sizeofvoid.org>: > >> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote: >> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: >> > > On 2018-06-23 09:07:38, Thomas Frohwein >> wrote: >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com >> wrote: >> > > > > I think the blockchain size is a deterrent. I can test it when >> I'm back from traveling in ~ 10 days and have access to additional GB on my >> external drive, in case that helps. >> > > > > >> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski < >> raf...@sizeofvoid.org> wrote: >> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. >> > > > > > >> > > > > >It's not evil! It's NOT mining. ;) >> > > > >> > > > I installed it and tried to sync the 200GB blockchain to my >> external HDD >> > > > (because that's the only one that got this much space available). It >> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at >> about >> > > > 30-40% of the blockchain synced, it now starts throwing an error: >> > > > >> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - >> CAutoFile::read:fread failed: unspecified iostream_category error at >> CBlockDiskPos(nFile=613, nPos=6513581) >> > > > >> > > > When this happens, the following lines appear in dmesg: >> > > > >> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 >> > > > SENSE KEY: Media Error >> > > > ASC/ASCQ: Unrecovered Read Error >> > > > >> > > > Fortunately, the drive still seems to be functional otherwise, can >> be >> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear >> > > > whenever mounting or unmounting said drive until I disconnect and >> > > > reconnect the drive from the USB port. >> > > > >> > > >> > > This is almost certainly a problem with the drive. I've had >> > > several hard drives fail over the ~13 years or so I've been using >> > > OpenBSD, and this is exactly the kind of error I see when the >> > > drive is wearing out. >> > > >> > > The message means that the kernel could not read a sector on the >> > > drive despite trying to do so. I've had drives continue to >> > > otherwise work for years after throwing errors like that (though I >> > > made sure to back them up and only used them as "scratch" drives). >> > > Another time I had a drive fail within weeks of throwing an error >> > > like that. >> > > >> > > If it's still under warranty, I'd recommend sending it in for >> > > replacement. If it's not, I'd *highly* recommend backing up >> > > anything on there to another drive. >> > > >> > > Sometimes, sectors can be "weak" and if you give the drive enough >> > > time it will be able to read it, so if it can't be backed up >> > > entirely, back up as much as you can, then let the drive sit for a >> > > few days and try again. >> > > >> > > Some ports that may help: >> > > sysutils/ddrescue >> > > sysutils/testdisk >> > > sysutils/e2fsprogs (for the "badblocks" program) >> > > net/rsync (probably obvious, but still worth mentioning) >> > > >> > > Modern drives keep "spare sectors" in which to remap failing ones >> > > like this, but they usually only do so when *writing* to the >> > > sector, not when *reading* it. >> > > >> > > You could try backing up the drive, then writing zeros to the >> > > entire drive with dd(1) to try to see if it helps. You could also >> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs). >> > > >> > > -nUse non-destructive read-write mode. By default only a non- >> > > destructive read-only test is done. This option must >> not be >> > > combined with the -w option, as they are mutually >> exclusive. >> > > >> > > "badblocks -n" will read all sectors on the drive and write back >> > > the same data to the sector. If it's "weak", and the program can >> > > manage to read the sector, the drive may then remap that sector to >> > > a spare. >> > > >> > > But! How much do you really trust a drive that has started to >> > > fail? Drives are cheap. Cheaper than they've ever been. If this >> > > drive contains the only copy of family photos
Re: NEW: net/bitcoin
Hi i've been running a bitcoin node for the last two weeks and everything seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and used it in combination with lnd [0] (in testnet) Please find the attached diff with two small improvements to the rc file: - add daemon_timeout=300. The daemon need time to shutdown successfully (syncing to disk). 300 sec. was choosen randomly but this value worked for me in several restarts. - remove pid_file. It works even without specifying it. With this, the port looks ok to me :) Cheer, Fabian [0] https://github.com/lightningnetwork/lnd Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski < raf...@sizeofvoid.org>: > On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote: > > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: > > > On 2018-06-23 09:07:38, Thomas Frohwein > wrote: > > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com > wrote: > > > > > I think the blockchain size is a deterrent. I can test it when I'm > back from traveling in ~ 10 days and have access to additional GB on my > external drive, in case that helps. > > > > > > > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski < > raf...@sizeofvoid.org> wrote: > > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > > > > > > > > > > > >It's not evil! It's NOT mining. ;) > > > > > > > > I installed it and tried to sync the 200GB blockchain to my external > HDD > > > > (because that's the only one that got this much space available). It > > > > synced fine for 1-2 days with the bitcoin-qt client, but then at > about > > > > 30-40% of the blockchain synced, it now starts throwing an error: > > > > > > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - > CAutoFile::read:fread failed: unspecified iostream_category error at > CBlockDiskPos(nFile=613, nPos=6513581) > > > > > > > > When this happens, the following lines appear in dmesg: > > > > > > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 > > > > SENSE KEY: Media Error > > > > ASC/ASCQ: Unrecovered Read Error > > > > > > > > Fortunately, the drive still seems to be functional otherwise, can be > > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear > > > > whenever mounting or unmounting said drive until I disconnect and > > > > reconnect the drive from the USB port. > > > > > > > > > > This is almost certainly a problem with the drive. I've had > > > several hard drives fail over the ~13 years or so I've been using > > > OpenBSD, and this is exactly the kind of error I see when the > > > drive is wearing out. > > > > > > The message means that the kernel could not read a sector on the > > > drive despite trying to do so. I've had drives continue to > > > otherwise work for years after throwing errors like that (though I > > > made sure to back them up and only used them as "scratch" drives). > > > Another time I had a drive fail within weeks of throwing an error > > > like that. > > > > > > If it's still under warranty, I'd recommend sending it in for > > > replacement. If it's not, I'd *highly* recommend backing up > > > anything on there to another drive. > > > > > > Sometimes, sectors can be "weak" and if you give the drive enough > > > time it will be able to read it, so if it can't be backed up > > > entirely, back up as much as you can, then let the drive sit for a > > > few days and try again. > > > > > > Some ports that may help: > > > sysutils/ddrescue > > > sysutils/testdisk > > > sysutils/e2fsprogs (for the "badblocks" program) > > > net/rsync (probably obvious, but still worth mentioning) > > > > > > Modern drives keep "spare sectors" in which to remap failing ones > > > like this, but they usually only do so when *writing* to the > > > sector, not when *reading* it. > > > > > > You could try backing up the drive, then writing zeros to the > > > entire drive with dd(1) to try to see if it helps. You could also > > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs). > > > > > > -nUse non-destructive read-write mode. By default only a non- > > > destructive read-only test is done. This option must > not be > > > combined with the -w option, as they are mutually > exclusive. > > > > > > "badblocks -n" will read all sectors on the drive and write back > > > the same data to the sector. If it's "weak", and the program can > > > manage to read the sector, the drive may then remap that sector to > > > a spare. > > > > > > But! How much do you really trust a drive that has started to > > > fail? Drives are cheap. Cheaper than they've ever been. If this > > > drive contains the only copy of family photos of your dearly > > > departed grandmother, are you willing to risk it? > > > > > > sd4 at scsibus4 targ 1 lun 0: SCSI4 > 0/direct fixed > > > sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors > > > > > > I see a 3TB Western Digital
Re: NEW OCaml sysutils/dune math/ocaml-{num,zarith}
On Mon, Jul 02, 2018 at 10:01:54PM +0200, Christopher Zimmermann wrote:
> On 2018-06-21 Christopher Zimmermann wrote:
> > Hi,
> >
> > the last few days I prepared an update of ocaml to 4.06 and opam to
> > 2.00rc2 and along with it updates or REVISION bumps of the dependent
> > ports.
> >
> > two ports have been added since num has been removed from the OCaml
> > distribution.
> > math/ocaml-num
> > math/Zarith
>
> Thanks a lot for the reviews so far. I fixed few issues and
> renamed math/Zarith to math/ocaml-zarith. Before committing the update
> of OCaml and dependent ports I need to import the new ports
>
> sysutils/dune
> math/ocaml-{num,zarith}
>
> which are attached as single tarball. They will be enabled in the
> category Makefiles with the OCaml upgrade diff. OK to import this?
>
>
> Christopher
>
>
> --
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
I have no objections.
Ken
NEW OCaml sysutils/dune math/ocaml-{num,zarith}
On 2018-06-21 Christopher Zimmermann wrote:
> Hi,
>
> the last few days I prepared an update of ocaml to 4.06 and opam to
> 2.00rc2 and along with it updates or REVISION bumps of the dependent
> ports.
>
> two ports have been added since num has been removed from the OCaml
> distribution.
> math/ocaml-num
> math/Zarith
Thanks a lot for the reviews so far. I fixed few issues and
renamed math/Zarith to math/ocaml-zarith. Before committing the update
of OCaml and dependent ports I need to import the new ports
sysutils/dune
math/ocaml-{num,zarith}
which are attached as single tarball. They will be enabled in the
category Makefiles with the OCaml upgrade diff. OK to import this?
Christopher
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
ocaml-num_zarith_dune.tgz
Description: application/compressed-tar
pgpsCJ8xrE_dK.pgp
Description: OpenPGP digital signature
Re: Getting update signature from package file
On Mon, Jul 02, 2018 at 02:15:12PM +0200, Marc Espie wrote: > On Mon, Jul 02, 2018 at 02:01:53PM +0200, Andreas Kusalananda Kähäri wrote: > > Is it possible to get the update signature from an uninstalled, locally > > built, package? > > > > I tried with > > > > doas pkg_info -q -S > > /usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz > > > > but got > > > > file:/usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz: unsigned package > > (signify(1) doesn't see old-style signatures) > > So use -Dunsigned, as documented for pkg_add. Ah, much thanks! -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden. När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/om-uu/dataskydd-personuppgifter/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2018/07/02 11:49:16 Modified files: www/py-werkzeug: Makefile www/py-flask : Makefile Log message: Drop maintainership
Re: NEW: devel/py-magic
On Thu, 28 Jun 2018 15:27:04 +0100, Stuart Henderson
wrote:
> > > > This has a conflict:
> > > >
> > > > $ make plist
> > > > Warning: py-magic-0.4.15 conflicts with py-libmagic-5.32
> > > > (devel/py-libmagic):/usr/local/lib/python2.7/site-packages/magic.py
> > > > /usr/local/lib/python2.7/site-packages/magic.pyc
> > > > /usr/local/lib/python2.7/site-packages/magic.pyc
> > > > /usr/ports/openbsd-wip/devel/py-magic/pkg/PLIST
> > > > changed
> > >
> > > Yes and py-libmagic is only needed by print/py-relatorio so my
> > > plan was to check if py-relatorio could be switched to it but I
> > > didn't go further than asking semarie about it.
> >
> > there is no problem for py-relatorio for switching to py-magic
> > instead of py-libmagic. And in fact, py-magic is the intented
> > dependency for upstream (and from reading py-relatorio code, it is
> > possible that with py-libmagic, it doesn't work as expected).
> >
> > I ran the testsuite of py3-relatorio with both (py3-magic and
> > py3-libmagic), and the result are same: all 23 tests passes.
> >
> > If py-libmagic has no other reverse dependencies than py-relatorio,
> > I would be in favor to remove it, and use py-magic as dependency
> > instead of. Below a diff that do it, and while here taking
> > maintainership of py-relatorio.
>
> Great, I'm OK with that approach.
>
> I think if we're doing this, it would make sense to auto update
> py-libmagic to py-magic. We'll need some magic in devel/py-magic so
> that conflict/pkgpath lines are set correctly, I think this should do
> the trick:
>
> @conflict ${MODPY_PY_PREFIX}libmagic-*
> @pkgpath devel/py-libmagic${MODPY_FLAVOR}
I'm ok as well with this move and the new port.
Re: NEW: textproc/py-black
On Mon, 02 Jul 2018 14:42:31 + Edward Lopez-Acosta wrote: > Seems to work, however an error is thrown by click due to a locale > issue. Not sure if that can be set here to resolve this. > > Exporting LC_ALL=C.UTF-8 seems to help. > Clean install of -current build #82. That's right, because the program requires an UTF-8 output. If you want support for UTF-8, use a locale with UTF-8 :) . The problem is not on black or click. > > Also with Brian I would suggest explicitly set ports@ as maintainer > if you don't want to put your email on the package. The ports framework defaults to ports@ when MAINTAINER is not used. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: dbus autolaunch (was Re: [UPDATE] net/gpodder -> 3.10.3)
On Mon, Jul 02, 2018 at 01:19:55PM +0200, Antoine Jacoutot wrote: > On Mon, Jul 02, 2018 at 09:06:50AM +0100, Stuart Henderson wrote: > > On 2018/06/28 08:47, Sebastien Marie wrote: > > > > > > I think last patch on firefox workarounded efficiently fork+exec > > > problem (setting DBUS_SESSION_BUS_ADDRESS if not present). so no wrapper > > > script should be needed. > > > > > > So reenabling autolaunch on dbus port is possible and should not impact > > > firefox. > > > > > > On the other side, it only hides the underline problem of dbus session. > > > If I correctly understood have dbus-launch works, When a program starts > > > it at program level (opposite to Xsession level), the session is only > > > "local" to the program: only this particular program will speak with > > > this dbus daemon. And it could result on starting a dbus session per > > > program that could need it. I have already seen several dbus deamon > > > running because starting several firefox -no-remote. > > > > Even if we're going to make changes in Xsession I think we should > > reenable autolaunch in dbus for now as there is too much hard-to-debug > > breakage. > > OK, I'll re-enable it for the time being then. I'm fine with re-enabling it too. -- Sebastien Marie
Re: NEW: textproc/py-black
On 07/02/18 10:42, Edward Lopez-Acosta wrote: Seems to work, however an error is thrown by click due to a locale issue. Not sure if that can be set here to resolve this. Exporting LC_ALL=C.UTF-8 seems to help. Clean install of -current build #82. Also with Brian I would suggest explicitly set ports@ as maintainer if you don't want to put your email on the package. Hmm? I didn't suggest he set MAINTAINER to ports@ (which is done automatically if there is no MAINTAINER), I asked if he wanted to *be* MAINTAINER, seeing as how he was submitting the port in the first place. I generally always ask that if I see a new port missing the line, because sometimes people forget it. ~Brian
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2018/07/02 10:09:01 Modified files: audio/quodlibet: Makefile Log message: re-bump for @tag gtk-update-icon-cache
Re: NEW: textproc/py-black
Turns out my local got somehow unset. Reset it and things look fine. Could the description be expanded rather than just the tagline of the program? Was actually thinking of porting this myself too, so thanks for being ahead of me. -- Sent from my mobile device. Please excuse my brevity and formatting issues. On July 2, 2018 3:19:51 PM UTC, Juan Francisco Cantero Hurtado wrote: >On Mon, 02 Jul 2018 14:42:31 + >Edward Lopez-Acosta wrote: > >> Seems to work, however an error is thrown by click due to a locale >> issue. Not sure if that can be set here to resolve this. >> >> Exporting LC_ALL=C.UTF-8 seems to help. >> Clean install of -current build #82. > >That's right, because the program requires an UTF-8 output. If you want >support for UTF-8, use a locale with UTF-8 :) . The problem is not on >black or click. > >> >> Also with Brian I would suggest explicitly set ports@ as maintainer >> if you don't want to put your email on the package. > >The ports framework defaults to ports@ when MAINTAINER is not used.
[UPDATE] security/py-dfdatetime
Hi,
this is the diff to update dfdatetime to latest release (needed for the
incoming plaso update).
Ok?
Cheers,
Remi.
Index: Makefile
===
RCS file: /cvs/ports/security/py-dfdatetime/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- Makefile 30 May 2018 09:10:19 - 1.8
+++ Makefile 2 Jul 2018 13:44:46 -
@@ -2,7 +2,7 @@
COMMENT = Digital Forensics date and time
-MODPY_EGG_VERSION = 20180510
+MODPY_EGG_VERSION = 20180606
DISTNAME = dfdatetime-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
Index: distinfo
===
RCS file: /cvs/ports/security/py-dfdatetime/distinfo,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 distinfo
--- distinfo 30 May 2018 09:10:19 - 1.7
+++ distinfo 2 Jul 2018 13:44:46 -
@@ -1,2 +1,2 @@
-SHA256 (dfdatetime-20180510.tar.gz) = xrX8FwLMrjw/eiPEHpV9sIl7sBff4cMVXKBW4C7b9BY=
-SIZE (dfdatetime-20180510.tar.gz) = 40824
+SHA256 (dfdatetime-20180606.tar.gz) = X27G4o12EsnT1vSAMnSYGwAJRlllKgICw5YjbfXVbiY=
+SIZE (dfdatetime-20180606.tar.gz) = 41282
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/py-dfdatetime/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- pkg/PLIST 30 May 2018 09:10:19 - 1.6
+++ pkg/PLIST 2 Jul 2018 13:44:46 -
@@ -1,6 +1,4 @@
@comment $OpenBSD: PLIST,v 1.6 2018/05/30 09:10:19 rpointel Exp $
-lib/python${MODPY_VERSION}/
-lib/python${MODPY_VERSION}/site-packages/
lib/python${MODPY_VERSION}/site-packages/dfdatetime/
lib/python${MODPY_VERSION}/site-packages/dfdatetime-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/dfdatetime-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
@@ -8,7 +6,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/dfdatetime-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
lib/python${MODPY_VERSION}/site-packages/dfdatetime-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/dfdatetime/__init__.py
-${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/dfdatetime/${MODPY_PYCACHE}
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/dfdatetime/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/dfdatetime/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/dfdatetime/${MODPY_PYCACHE}cocoa_time.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/dfdatetime/${MODPY_PYCACHE}decorators.${MODPY_PYC_MAGIC_TAG}pyc
[UPDATE] devel/py-dtfabric
Hi,
this is the diff to update dtfabric to latest release (needed for the
incoming plaso update).
Ok?
Cheers,
Remi.
Index: Makefile
===
RCS file: /cvs/ports/devel/py-dtfabric/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 Makefile
--- Makefile 29 May 2018 18:50:25 - 1.1.1.1
+++ Makefile 2 Jul 2018 14:06:15 -
@@ -2,7 +2,7 @@
COMMENT = data type fabric
-MODPY_EGG_VERSION = 20180522
+MODPY_EGG_VERSION = 20180604
DISTNAME = dtfabric-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
Index: distinfo
===
RCS file: /cvs/ports/devel/py-dtfabric/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- distinfo 29 May 2018 18:50:25 - 1.1.1.1
+++ distinfo 2 Jul 2018 14:06:15 -
@@ -1,2 +1,2 @@
-SHA256 (dtfabric-20180522.tar.gz) = Ji0p2XzYsfuAHoDfmRlPc4RkHmWBB6z2OASXrjcBw1k=
-SIZE (dtfabric-20180522.tar.gz) = 41555
+SHA256 (dtfabric-20180604.tar.gz) = eXH11U+bdW+TMjbUPzfywfaw/L6WhkEUU8fr9b5SSQk=
+SIZE (dtfabric-20180604.tar.gz) = 41615
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-dtfabric/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 29 May 2018 18:50:25 - 1.1.1.1
+++ pkg/PLIST 2 Jul 2018 14:06:15 -
@@ -1,7 +1,5 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2018/05/29 18:50:25 rpointel Exp $
bin/validate-definitions${MODPY_BIN_SUFFIX}
-lib/python${MODPY_VERSION}/
-lib/python${MODPY_VERSION}/site-packages/
lib/python${MODPY_VERSION}/site-packages/dtfabric/
lib/python${MODPY_VERSION}/site-packages/dtfabric-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/dtfabric-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
NEW: textproc/py-black
Seems to work, however an error is thrown by click due to a locale issue. Not sure if that can be set here to resolve this. Exporting LC_ALL=C.UTF-8 seems to help. Clean install of -current build #82. Also with Brian I would suggest explicitly set ports@ as maintainer if you don't want to put your email on the package. -- Sent from my mobile device. Please excuse my brevity and formatting issues.
Re: organize www/py-django
Any update on this? Django bugfix releases 2.0.7 and 1.11.14 are out.
Re: Getting update signature from package file
On Mon, Jul 02, 2018 at 02:01:53PM +0200, Andreas Kusalananda Kähäri wrote: > Is it possible to get the update signature from an uninstalled, locally > built, package? > > I tried with > > doas pkg_info -q -S > /usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz > > but got > > file:/usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz: unsigned package > (signify(1) doesn't see old-style signatures) So use -Dunsigned, as documented for pkg_add.
Getting update signature from package file
Is it possible to get the update signature from an uninstalled, locally built, package? I tried with doas pkg_info -q -S /usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz but got file:/usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz: unsigned package (signify(1) doesn't see old-style signatures) After installing the package, one can do "pkg_info -q -S", but I'd like to see the signature without having to install it. Regards, -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden. När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/om-uu/dataskydd-personuppgifter/
Re: dbus autolaunch (was Re: [UPDATE] net/gpodder -> 3.10.3)
On Mon, Jul 02, 2018 at 01:19:55PM +0200, Antoine Jacoutot wrote: > On Mon, Jul 02, 2018 at 09:06:50AM +0100, Stuart Henderson wrote: > > On 2018/06/28 08:47, Sebastien Marie wrote: > > > > > > I think last patch on firefox workarounded efficiently fork+exec > > > problem (setting DBUS_SESSION_BUS_ADDRESS if not present). so no wrapper > > > script should be needed. > > > > > > So reenabling autolaunch on dbus port is possible and should not impact > > > firefox. > > > > > > On the other side, it only hides the underline problem of dbus session. > > > If I correctly understood have dbus-launch works, When a program starts > > > it at program level (opposite to Xsession level), the session is only > > > "local" to the program: only this particular program will speak with > > > this dbus daemon. And it could result on starting a dbus session per > > > program that could need it. I have already seen several dbus deamon > > > running because starting several firefox -no-remote. > > > > Even if we're going to make changes in Xsession I think we should > > reenable autolaunch in dbus for now as there is too much hard-to-debug > > breakage. > > OK, I'll re-enable it for the time being then. > > -- > Antoine > I suspect this is also behind 'emacsclient -a "" -c' not doing what I expected recently. i.e. starting up an emacs daemon if one is not already running. Ken
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2018/07/02 05:24:24 Modified files: games/openrct2 : Makefile Log message: re-bump for @tag gtk-update-icon-cache
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2018/07/02 05:21:29 Modified files: sysutils/grive2: Makefile Log message: actually bump
Re: dbus autolaunch (was Re: [UPDATE] net/gpodder -> 3.10.3)
On Mon, Jul 02, 2018 at 09:06:50AM +0100, Stuart Henderson wrote: > On 2018/06/28 08:47, Sebastien Marie wrote: > > > > I think last patch on firefox workarounded efficiently fork+exec > > problem (setting DBUS_SESSION_BUS_ADDRESS if not present). so no wrapper > > script should be needed. > > > > So reenabling autolaunch on dbus port is possible and should not impact > > firefox. > > > > On the other side, it only hides the underline problem of dbus session. > > If I correctly understood have dbus-launch works, When a program starts > > it at program level (opposite to Xsession level), the session is only > > "local" to the program: only this particular program will speak with > > this dbus daemon. And it could result on starting a dbus session per > > program that could need it. I have already seen several dbus deamon > > running because starting several firefox -no-remote. > > Even if we're going to make changes in Xsession I think we should > reenable autolaunch in dbus for now as there is too much hard-to-debug > breakage. OK, I'll re-enable it for the time being then. -- Antoine
Re: NEW games/gzdoom
Solene Rapenne writes:
> Rafael Sadowski writes:
>
>> On Sat Jun 30, 2018 at 11:21:28AM +0200, Solene Rapenne wrote:
>>> Hello
>>>
>>> Does someone already started porting gzdoom? I would like to port it.
>>>
>>> At first I wasn't sure we would need another doom engine, but this
>>> one does opengl rendering and allow to play lot of mods which some
>>> are real games. And good news, last release compile just fine.
>>>
>>> So, if nobody is currently working on a port, i'll take care of it. If
>>> someone already have some wip port I'd be happy to continue the work.
>>>
>>
>> Nothing on the list and nothing in openbsd-wip. Go ahead!
>
> Please find a port of games/gzdoom.
>
> About the name, the website hosting it is zdoom, but gzdoom is the
> project replacing the abandoned zdoom engine, but it's hosted by zdoom
> as gzdoom is a fork of zdoom that continues to live.
>
>
> It requires doom 2 files in ${PREFIX}/share/doom/ for most of mods, but
> you can also play doom 1, heretic, hexen etc...
>
>
> A few mods to play with it for lot of fun:
>
> - Castlevania : https://www.moddb.com/mods/castlevania-simons-destiny
> - Golden Souls 2 : https://www.moddb.com/mods/doom-the-golden-souls-2
I'd say the port needs few more dependencies listed.
My gzdoom port had following listed:
BUILD_DEPENDS = archivers/bzip2 \
audio/libsndfile \
audio/mpg123 \
audio/openal \
devel/nasm \
devel/sdl2 \
graphics/jpeg
CONFIGURE_ARGS+=-DCMAKE_EXE_LINKER_FLAGS="-lpthread -lc++abi"
RUN_DEPENDS = audio/fluidsynth \
audio/generaluser-gs-soundfont \
audio/timidity \
x11/gxmessage
I don't remember why some of them are listed anymore. I made the port a while
ago. Gxmessage is needed when the game crash, the code calls gxmessage to
display messages.
When building the port on my amd64 I noticed following flags passed to build
process:
-DDYN_FLUIDSYNTH
-DDYN_GTK=1
-DDYN_MPG123
-DDYN_OPENAL
-DDYN_SNDFILE
-DHAVE_FLUIDSYNTH
-DHAVE_MPG123
-DHAVE_SNDFILE
But the port make file doesn't mention them.
I think my previous problems at wad/pk3 loading were due to custom gzdoom.ini
file in ~/.config/gzdoom. After I removed it the game started with the doomdata
wad file just fine. But the starting the game takes about 11 seconds to start
for me on Thinkpad T430s with SSD drive. It seems a bit slow.
M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
adding /usr/local/share/games/doom/gzdoom.pk3, 625 lumps
adding /usr/local/share/games/doom/zd_extra.pk3, 132 lumps
adding /usr/local/share/doom/doom1.wad, 1264 lumps
I_Init: Setting up machine state.
CPU Vendor ID: GenuineIntel
Name: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
Family 6, Model 58, Stepping 9
Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 HyperThreading
I_InitSound: Initializing OpenAL
Opened device SndIO Default
EFX enabled
V_Init: allocate screen.
S_Init: Setting up sound.
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 365.13 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Using video driver x11
GL_VENDOR: Intel Open Source Technology Center
GL_RENDERER: Mesa DRI Intel(R) Ivybridge Mobile
GL_VERSION: 3.3 (Core Profile) Mesa 13.0.6 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 3.30
Max. texture size: 8192
Max. texture units: 16
Max. varying: 128
Max. uniform block size: 65536
Uniform block alignment: 16
<... stuck here for ~11s ...>
Resolution: 640 x 480
Also, when I change the audio backends I get following messages in console:
Playing demo DEMO1
Cannot play non-GZDoom demos.
libWildMidi(_WM_InitReader:52): ERROR Unable to load (No such file or
directory)
Unable to create WildMidi MIDI device. Falling back to GUS
libWildMidi(_WM_InitReader:52): ERROR Unable to load (No such file or
directory)
Unable to create Timidity++ MIDI device. Falling back to GUS
libWildMidi(_WM_InitReader:52): ERROR Unable to load (No such file or
directory)
Unable to create FluidSynth MIDI device. Falling back to GUS
libWildMidi(_WM_InitReader:52): ERROR Unable to load (No such file or
directory)
Playing demo DEMO2
Should we add other backends so they can be used?
Here's my few notes about the port.
Timo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2018/07/02 04:00:41 Modified files: net/tor: Makefile net/tor/pkg: PLIST Log message: Install doc/TUNING Some error messages point to this file containing useful bits system resource limits such as `kern.maxfiles' (sysctl.conf) and `openfiles' (login.conf). OK jca pascal (maintainer)
Re: dbus autolaunch (was Re: [UPDATE] net/gpodder -> 3.10.3)
On Thu, Jun 28, 2018 at 08:47:41AM +0200, Sebastien Marie wrote: > > The proper fix would be changing /etc/X11/xenodm/Xsession. We've been there and have done that, and we've backed that out. for xinit see: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/app/xinit/xinitrc.cpp (rev 1.9 and 1.13) and for xdm see: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/app/xdm/config/Attic/Xsession.cpp (rev 1.11 and 1.14) > But it should > be done in proper way. Personally I would be in favor of generic code to > load (shell sourcing) files in /etc/X11/xenodm/Xsession.d directory, > with mecanism a-la "rcctl enable" to know which files are explicitly > asked for inclusion. > If the default is NO and the instructions on how to enable it are specific to OpenBSD, I'm not sure if it will be useful. -- Matthieu Herrb
Re: tor: install doc/TUNING
On Thu, 28 Jun 2018 17:46:10 +0200, Klemens Nanni wrote:
> Stumbled across the following error on a new relay:
>
> Failing because we have 991 connections already. Please read doc/TUNING
> for guidance.
>
> This document contains information about `kern.maxfiles' (sysctl) and
> `openfiles-max' (login.conf).
>
> OK?
OK.
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/tor/Makefile,v
> retrieving revision 1.114
> diff -u -p -r1.114 Makefile
> --- Makefile 13 Jun 2018 13:59:57 - 1.114
> +++ Makefile 28 Jun 2018 15:41:17 -
> @@ -3,6 +3,7 @@
> COMMENT= anonymity service using onion routing
>
> DISTNAME=tor-0.3.3.7
> +REVISION=0
> CATEGORIES= net
> HOMEPAGE=https://www.torproject.org/
>
> @@ -31,5 +32,8 @@ DB_DIR= /var/tor
> SUBST_VARS+= DB_DIR
>
> FAKE_FLAGS= sysconfdir=${PREFIX}/share/examples
> +
> +post-install:
> + ${INSTALL_DATA} ${WRKSRC}/doc/TUNING ${PREFIX}/share/doc/tor/
>
> .include
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/net/tor/pkg/PLIST,v
> retrieving revision 1.8
> diff -u -p -r1.8 PLIST
> --- pkg/PLIST 11 Sep 2013 15:57:37 - 1.8
> +++ pkg/PLIST 28 Jun 2018 15:41:32 -
> @@ -1,6 +1,7 @@
> @comment $OpenBSD: PLIST,v 1.8 2013/09/11 15:57:37 pascal Exp $
> @newgroup _tor:566
> @newuser _tor:566:566:daemon:tor:/nonexistent:/sbin/nologin
> +@rcscript ${RCDIR}/tor
> @bin bin/tor
> @bin bin/tor-gencert
> @bin bin/tor-resolve
> @@ -10,6 +11,7 @@
> @man man/man1/tor.1
> @comment @man man/man1/torify.1
> share/doc/tor/
> +share/doc/tor/TUNING
> share/doc/tor/tor-gencert.html
> share/doc/tor/tor-resolve.html
> share/doc/tor/tor.html
> @@ -28,4 +30,3 @@ share/examples/tor/torrc.sample
> share/tor/
> share/tor/geoip
> share/tor/geoip6
> -@rcscript ${RCDIR}/tor
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2018/07/02 02:22:25 Modified files: audio/cantata : Makefile distinfo audio/cantata/pkg: PLIST Added files: audio/cantata/patches: patch-3rdparty_solid-lite_CMakeLists_txt Log message: Update to cantata 2.3.1. Add a patch to disable udev check.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2018/07/02 02:19:56 Modified files: x11/xfce4/ristretto: Makefile distinfo x11/xfce4/ristretto/pkg: PLIST Log message: Update to ristretto 0.8.3.
Re: dbus autolaunch (was Re: [UPDATE] net/gpodder -> 3.10.3)
On 2018/06/28 08:47, Sebastien Marie wrote: > > I think last patch on firefox workarounded efficiently fork+exec > problem (setting DBUS_SESSION_BUS_ADDRESS if not present). so no wrapper > script should be needed. > > So reenabling autolaunch on dbus port is possible and should not impact > firefox. > > On the other side, it only hides the underline problem of dbus session. > If I correctly understood have dbus-launch works, When a program starts > it at program level (opposite to Xsession level), the session is only > "local" to the program: only this particular program will speak with > this dbus daemon. And it could result on starting a dbus session per > program that could need it. I have already seen several dbus deamon > running because starting several firefox -no-remote. Even if we're going to make changes in Xsession I think we should reenable autolaunch in dbus for now as there is too much hard-to-debug breakage. > The proper fix would be changing /etc/X11/xenodm/Xsession. But it should > be done in proper way. Personally I would be in favor of generic code to > load (shell sourcing) files in /etc/X11/xenodm/Xsession.d directory, > with mecanism a-la "rcctl enable" to know which files are explicitly > asked for inclusion. > > So dbus port would provide a /etc/X11/xenodm/Xsession/dbus.script file, > and administrator would have to enable the inclusion of the file for > make it sourced by /etc/X11/xenodm/Xsession.d Anything that the administrator has to do themselves is going to result in the same problem. If people were already following dbus' pkg-readme then we wouldn't have had any problems with disabling autolaunch..
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/07/02 01:21:10 Modified files: misc/ttyrec: Makefile Log message: Fix HOMEPAGE.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2018/07/02 00:14:43 Modified files: geo/gdal : Makefile distinfo geo/gdal/patches: patch-swig_perl_GNUmakefile geo/gdal/pkg : PLIST-main PLIST-python Log message: Update to gdal 2.3.1. Cf https://trac.osgeo.org/gdal/wiki/Release/2.3.1-News
