Re: CVS: cvs.openbsd.org: ports

2024-04-25 Thread Solène Rapenne

Le 25/04/2024 à 16:44, Frederic Cambus a écrit :

CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2024/04/25 08:44:10

Modified files:
misc   : Makefile
Removed files:
misc/gone  : Makefile distinfo
misc/gone/patches: patch-Makefile_in
misc/gone/pkg  : DESCR PLIST

Log message:
Remove misc/gone.

Last release is from 2003 and the program is crashing on at least amd64
and arm64 when entering a passphrase.

$ gone
Password:
Segmentation fault (core dumped)

OK solene@



seems gone is gone :-D



7.5: www/ungoogled-chromium is missing a lib

2024-04-05 Thread Solène Rapenne

on a fresh 7.5

$ ungoogled-chromium
ld.so: ungoogled-chromium: can't load library 'libvpx.so.17.0'

installing libvpx package seems to solve, but chromim instantly reboots 
my computer




Re: Chromium browsers: Meet + webcam = SIGILL?

2024-03-11 Thread Solène Rapenne

Le 11/03/2024 à 09:55, Laurence Tratt a écrit :

Hello all,

On current, with packages upto date as of Saturday, I get a consistent
SIGILL with Google Meet and the 3 Chromium browsers I'm aware of (Chromium,
Iridium, Ungoogled-Chromium). It seems like it might be something to do
with webcam/video processing in these browsers, but I'm far from sure.

To replicate here's what I do:

   1. Open a new private window (this probably isn't important but force of
   habit, but does mean a somewhat more consistent setup).

   2. Go to meet.google.com and sign in.

   3. Start a new meeting, and enable both microphone and webcam. As soon as
   the main "you should be able to see everyone else screen" is about to
   start, I get SIGILL.

Interestingly, I can use the webcam successfully with other sites in these
browsers, and Meet works OK in Firefox.

Perhaps there's something odd about my setup that causes this --- has
anyone else encountered it?


Laurie



Do you have a pledge violation in dmesg output?



Re: New: KeeperRL - evil wizard simulator/dungeon colony builder game

2024-03-02 Thread Solène Rapenne
Le vendredi 01 mars 2024 à 22:12 -0500, Thomas Frohwein a écrit :
> Hi,
> 
> Please find attached the port of KeeperRL, an open source game in the
> spirit of Dungeon Keeper or Overlord. This means that this game is
> about reversing the role of tropy RPG heroes and villains, and tasking
> the player with building a dungeon, raiding nearby villages,
> collecting resources, building traps for heroes that try to attack the
> dungeon, etc. This has been in development for many years and now has
> seen the 1.0 release.
> 
> The port is built with C++, using the usual suspects of openal and
> sdl2 libraries. It comes with free (and primitive) assets that can be
> used, though the better supported way is to run the commercially
> available game which includes music, sound effects, nicer graphics, and
> a tutorial. The website links to all places where those can be obtained
> [1], including itch.io, GOG.com.
> 
> I've launched both versions and played through the tutorial with the
> commercial version. The README explains how to launch each one. A few
> more technical notes about the port:
> 
> - It currently builds with Steam features that link to the goldberg
>   emulator library. There is a flag to skip Steam integration
>   (NO_STEAMWORKS), but that currently runs into build problems with
>   missing Steam-related symbols. Hopefully with future updates, the
>   Steam/goldberg dependency can be dropped.
> - While the 1.0 release has been announced officially and the engine
>   itself advertises version 1.0, there is no 1.0 GitHub release or tag.
> 
> ok for import?
> 
> [1] https://keeperrl.com/

sounds cool!

can you play the free ascii version with this port? you said it comes
with free assets, while on the official website there is either the paid
or free ascii version, does this mean open source users have an
advantage here? :-)



Re: update games/wrath to 1.0

2024-03-01 Thread Solène Rapenne

On 28/02/2024 14:48, Solène Rapenne wrote:

On 28/02/2024 12:11, Jonathan Gray wrote:

Wrath left early access and the old repo was removed.
Build tested only.



game runs, but crash at the end of the tutorial when loading next area 
"Mourningvale", i was able to repeat the issue twice, I didn't try 
another time. (fortunately the game makes a save ~30s before the loading 
area if someone wants to debug)


Memory pool 0x591a2a38b60 has sprung a leak totalling 44905033 bytes 
(42.825MB)!  Listing contents...

   44905033 bytes allocated at ../../../fs.c:3194
Quake Error: Mem_Alloc: out of memory (alloc at 
../../../model_shared.c:1046)

Client "player" dropped
pthread_mutex_destroy on mutex with waiters!



problem solved by increasing ulimit -d value

ok solene@



Re: update games/wrath to 1.0

2024-02-28 Thread Solène Rapenne

On 28/02/2024 12:11, Jonathan Gray wrote:

Wrath left early access and the old repo was removed.
Build tested only.



game runs, but crash at the end of the tutorial when loading next area 
"Mourningvale", i was able to repeat the issue twice, I didn't try 
another time. (fortunately the game makes a save ~30s before the loading 
area if someone wants to debug)


Memory pool 0x591a2a38b60 has sprung a leak totalling 44905033 bytes 
(42.825MB)!  Listing contents...

  44905033 bytes allocated at ../../../fs.c:3194
Quake Error: Mem_Alloc: out of memory (alloc at 
../../../model_shared.c:1046)

Client "player" dropped
pthread_mutex_destroy on mutex with waiters!



Re: remove net/p5-Net-XMPP and net/p5-Net-Jabber

2024-02-27 Thread Solène Rapenne
Le mardi 27 février 2024, 18:46:18 CET Alexander Bluhm a écrit :
> On Tue, Feb 27, 2024 at 05:58:59PM +0100, Solene Rapenne wrote:
> > I removed net/sendxmpp which had net/p5-Net-XMPP as a run dependency,
> > however p5-Net-XMPP is used by p5-Net-Jabber but the latter doesn't
> > have any reverse dep.
> > 
> > I suggest to remove both as we have no programs using them in ports.
> 
> Having Perl modules in the ports tree without program using them
> is common.  I maintain a lot to such ports that I use for my own
> projects.
> 
> Personally I have no need for p5-Net-XMPP or p5-Net-Jabber.  But
> as long as they work and are not completely outdated, why remove
> them?
> 
> bluhm

I get your point, from my perspective p5-Net-Jabber 2.0 was released in 2004 
and p5-Net-XMPP in 2014, and only one has a maintainer. Their old age doesn't 
mean they can't be used, but for sure they are not maintained and not up to 
date with XMPP protocol. 

We have no consumers to know if these libs are still working fine, given 
sendxmpp wasn't working with TLS servers, I suppose p5-Net-XMPP is not 
reliable.

I don't really care if we remove them or not to be honest, I thought we had to 
clean libs that didn't had consumers like in this case.




net/kubo not working on current

2024-02-20 Thread Solène Rapenne
on current amd64, kubo isn't working, either from regular user or the
dedicated daemon user

> $ ipfs daemon 
> Initializing daemon...
> Kubo version: 0.24.0
> Repo version: 15
> System version: amd64/openbsd
> Golang version: go1.22.0
> 
> Error: cannot acquire lock: Lock FcntlFlock of
> /home/solene/.ipfs/repo.lock failed: function not implemented
> 

the FnctlFlock error happens on many ipfs commands, including ipfs init


> # su -l -s /bin/sh _go-ipfs -c "IPFS_PATH=/var/kubo
> /usr/local/bin/ipfs init"
> generating ED25519 keypair...done
> peer identity: 12D3KooWHguoZzAbWGM8jDtkdLCuQs6sLzZ3zbsTv98uRMAXdy7v
> initializing IPFS node at /var/kubo
> Error: cannot acquire lock: Lock FcntlFlock of /var/kubo/repo.lock
> failed: function not implemented

I didn't use kubo/ipfs for at least 12 months, so I don't really know
when it stopped working.



Re: Remove: mail/trojita

2024-02-02 Thread Solène Rapenne
Le vendredi 02 février 2024 à 22:55 +0100, Rafael Sadowski a écrit :
> Hi Caspar, Hi ports@,
> 
> I'm trying to remove x11/qt5/qtwebkit. It's an very outdated and
> unsecure web engine. Which is also dead upstream. Other distributors
> have already got rid of it. Let's go the way too!
> 
> First trojita, it looks dead upstream and no one has it in their
> package
> catalog anymore. I hope that people will not use it to read their e-
> mail.
> 
> Anyway, Caspar, ports@, are we ready to get rid of it?
> 
> Rafael
> 

ok solene@ for removing it

it was a great email client but it has been inactive for a long time now



Re: CVS: cvs.openbsd.org: ports

2024-02-01 Thread Solène Rapenne
Le jeudi 01 février 2024 à 07:11 -0700, Landry Breuil a écrit :

> > CVSROOT: /cvs  
> > Module name: ports  
> > Changes by: 
> > [[lan...@cvs.openbsd.org](mailto:lan...@cvs.openbsd.org)](mailto:[lan...@cvs.openbsd.org](mailto:lan...@cvs.openbsd.org))
> >  2024/02/01 07:11:12  
> >  
> > Modified files:  
> > www/mozilla-firefox: Tag: OPENBSD_7_4 Makefile  
> > Added files:  
> > www/mozilla-firefox/patches: Tag: OPENBSD_7_4  
> >   
> > patch-third_party_libwebrtc_modules_video_capture_video_capture_facto  
> > ry_cc  
> >  
> > Log message:  
> > www/mozilla-firefox: MFC fix webcam detection  
> >  
> > gypped from 
> > [[freebsd/freebsd-ports@53a70f1248](mailto:freebsd/freebsd-ports@53a70f1248)](mailto:[freebsd/freebsd-ports@53a70f1248](mailto:freebsd/freebsd-ports@53a70f1248))
> >   
> > cf #1878010  
> >


this doesn't compile on arm64 (I made sure the whole ports tree is up to date)
I think this failed one or two commits earlier

gmake[3]: Leaving directory 
'/build/tmp/pobj/firefox-122.0/build-aarch64/config/external/sqlite'  
gmake[3]: Entering directory 
'/build/tmp/pobj/firefox-122.0/build-aarch64/third_party/sqlite3/src'  
mkdir -p '.deps/'  
third_party/sqlite3/src/sqlite3.o  
/build/tmp/pobj//firefox-122.0/bin/cc -std=gnu99 -o sqlite3.o -c -flto=thin 
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DNDEBUG=1 
-DTRIMMED=1 -DSQLITE_SECURE_DELETE=1 -DSQLITE_THREADSAFE=1 
-DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -DSQLITE_ENABLE_DBSTAT_VTAB=1 
-DSQLITE_DEFAULT_PAGE_SIZE=32768 -DSQLITE_MAX_DEFAULT_PAGE_SIZE=32768 
-DSQLITE_OMIT_COMPILEOPTION_DIAGS=1 -DSQLITE_OMIT_DEPRECATED 
-DSQLITE_OMIT_BUILTIN_TEST -DSQLITE_TEMP_STORE=2 
'-DSQLITE_TEMP_FILE_PREFIX="mz_etilqs_"' -DSQLITE_ENABLE_MATH_FUNCTIONS 
-DSQLITE_DEFAULT_JOURNAL_SIZE_LIMIT=1572864 
-I/build/tmp/pobj/firefox-122.0/firefox-122.0/third_party/sqlite3/src 
-I/build/tmp/pobj/firefox-122.0/build-aarch64/third_party/sqlite3/src 
-I/build/tmp/pobj/firefox-122.0/build-aarch64/dist/include 
-I/usr/local/include/nspr -I/usr/local/include/nss -I/usr/local/include/nspr 
-I/build/tmp/pobj/firefox-122.0/build-aarch64/dist/include/nss 
-I/usr/local/include -include 
/build/tmp/pobj/firefox-122.0/build-aarch64/mozilla-config.h -DMOZILLA_CLIENT 
-Wno-backend-plugin -O2 -pipe -g -fPIC -ffunction-sections -fdata-sections 
-fno-math-errno -pthread -pipe -gdwarf-4 -O2 -pipe -g -fomit-frame-pointer 
-funwind-tables -Wall -Wbitfield-enum-conversion -Wempty-body 
-Wformat-type-confusion -Wignored-qualifiers -Wpointer-arith 
-Wshadow-field-in-constructor-modified -Wsign-compare 
-Wtautological-constant-in-range-compare -Wtype-limits 
-Wno-error=tautological-type-limit-compare -Wunreachable-code 
-Wunreachable-code-return -Wunused-but-set-parameter -Wclass-varargs 
-Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis 
-Wno-range-loop-analysis -Wenum-compare-conditional -Wenum-float-conversion 
-Wstring-conversion -Wno-error=deprecated-declarations -Wno-error=array-bounds 
-Wno-error=free-nonheap-object -Wno-error=atomic-alignment -Wformat 
-Wformat-security -Werror=implicit-function-declaration -Wno-psabi 
-Wthread-safety -Wno-error=builtin-macro-redefined -Wno-unknown-warning-option 
-Wno-sign-compare -Wno-type-limits -fno-strict-aliasing -ffp-contract=off 
-fprofile-use=/build/tmp/pobj//firefox-122.0/merged.profdata 
-Wno-error=backend-plugin -MD -MP -MF .deps/sqlite3.o.pp   
/build/tmp/pobj/firefox-122.0/firefox-122.0/third_party/sqlite3/src/sqlite3.c  
gmake[3]: Leaving directory 
'/build/tmp/pobj/firefox-122.0/build-aarch64/media/libvpx'  
gmake[2]: *** 
[/build/tmp/pobj/firefox-122.0/firefox-122.0/config/recurse.mk:72: 
media/libvpx/target-objects] Error 2  
gmake[2]: *** Waiting for unfinished jobs  
/build/tmp/pobj/firefox-122.0/firefox-122.0/third_party/sqlite3/src/sqlite3.c:88121:3:
 warning: 'return' will never be executed [-Wunreachable-code-return]  
return;  
^~  
/build/tmp/pobj/firefox-122.0/firefox-122.0/third_party/sqlite3/src/sqlite3.c:92699:10:
 warning: 'return' will never be executed [-Wunreachable-code-return]  
return 0;  
^  
/build/tmp/pobj/firefox-122.0/firefox-122.0/third_party/sqlite3/src/sqlite3.c:173973:9:
 warning: code will never be executed [-Wunreachable-code]  
YYMINORTYPE yylhsminor;  
^~~  
3 warnings generated.  
gmake[3]: Leaving directory 
'/build/tmp/pobj/firefox-122.0/build-aarch64/third_party/sqlite3/src'  
fts5parse.sql:1012:9: warning: code will never be executed [-Wunreachable-code] 
 
fts5YYMINORTYPE fts5yylhsminor;  
^~~  
1 warning generated.  
gmake[3]: Leaving directory 
'/build/tmp/pobj/firefox-122.0/build-aarch64/third_party/sqlite3/ext'  
gmake[3]: Leaving directory 
'/build/tmp/pobj/firefox-122.0/build-aarch64/browser/app'  
gmake[2]: Leaving directory '/build/tmp/pobj/firefox-122.0/build-aarch64'  
gmake[1]: *** 
[/build/tmp/pobj/firefox-122.0/firefox-122.0/config/recurse.mk:34: compile] 
Error 2  

Re: CVS: cvs.openbsd.org: ports

2024-01-25 Thread Solène Rapenne
Le jeudi 25 janvier 2024 à 10:52 +0100, Landry Breuil a écrit :
> Le Thu, Jan 25, 2024 at 10:00:15AM +0100, Solène Rapenne a écrit :
> > Le jeudi 25 janvier 2024 à 08:40 +0100, Landry Breuil a écrit :
> > > Le Wed, Jan 24, 2024 at 06:11:22PM +0100, Solène Rapenne a écrit :
> > > > On 23/01/2024 15:29, Landry Breuil wrote:
> > > > > CVSROOT:/cvs
> > > > > Module name:ports
> > > > > Changes by: lan...@cvs.openbsd.org   2024/01/23 07:29:57
> > > > > 
> > > > > Modified files:
> > > > > www/mozilla-firefox: Tag: OPENBSD_7_4 Makefile distinfo
> > > > > Removed files:
> > > > > www/mozilla-firefox/patches: Tag: OPENBSD_7_4
> > > > >  
> > > > > patch-toolkit_xre_glxtest_glxtest_cpp
> > > > > 
> > > > > Log message:
> > > > > www/mozilla-firefox: MFC update to 122.0.
> > > > > 
> > > > > see https://www.mozilla.org/en-US/firefox/122.0/releasenotes/
> > > > > fixes https://www.mozilla.org/en-US/security/advisories/mfsa2024-01/
> > > > > 
> > > > > drop patch from #1868782, merged upstream
> > > > > 
> > > > 
> > > > for some reasons, doesn't compile on arm64 -stable , it didn't compile 
> > > > last
> > > > backport either but I didn't have the time to check why
> > > 
> > > if it's only on arm64-stable and amd64-stable built fine, i'd triple
> > > check that www/mozilla/mozilla.port.mk is at r1.163.2.1, cf
> > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/mozilla/mozilla.port.mk?only_with_tag=OPENBSD_7_4
> > > 
> > > >  ===>  Checking files for firefox-122.0
> > > >  `/mnt/distfiles/mozilla/firefox-122.0.source.tar.xz' is up to date.
> > > > > > No size recorded for mozilla/firefox-122.0.source-profdata.tar.xz
> > > 
> > > it should be prefixed with -repacked, as is the case since 121 was
> > > merged in 7.4 stable
> > > 
> > > can you check make show=DISTFILES.profdata ? here on my 7.4-stable tree
> > > its firefox-122.0.source-profdata-repacked.tar.xz
> > > 
> > > esr is probably the same thing.
> > > 
> > 
> > this is super weird, I have different results on arm64 and amd64 but
> > both distinfo have the same checksum
> > 
> > arm64-stable$ pwd
> > /home/ports/www/firefox-esr
> > arm64-stable$ make show=DISTFILES.profdata 
> > firefox-115.7.0esr.source-profdata.tar.xz
> > 
> > arm64-stable$ cd ../mozilla-firefox
> > arm64-stable$ make show=DISTFILES.profdata 
> > firefox-122.0.source-profdata.tar.xz
> 
> compare the content of www/mozilla/mozilla.port.mk, there's nothing
> arch-specific there afaict..
> 
> SHA256 (firefox-122.0.source-profdata-repacked.tar.xz) = 
> 5616619c86e99b64d207c319a49a77c8415f0f9d3ab26c6a5c132d85829e464f
> SHA256 (firefox-115.7.0esr.source-profdata-repacked.tar.xz) = 
> 5f47d1013cb00f4d59638a7f472ec92629d8331bf4ce7f451a137b5434c0840c
> 
> is what i have on the SITES.profdata.
> 

the directory www/mozilla wasn't updated on arm64 as it's not
part of a package that got updated, hence the issue.

the problem was on my side, thank you for the help

I'll see how I can do this better without doing a full cvs up
every time on all 4 machines



Re: CVS: cvs.openbsd.org: ports

2024-01-25 Thread Solène Rapenne
Le jeudi 25 janvier 2024 à 08:40 +0100, Landry Breuil a écrit :
> Le Wed, Jan 24, 2024 at 06:11:22PM +0100, Solène Rapenne a écrit :
> > On 23/01/2024 15:29, Landry Breuil wrote:
> > > CVSROOT:/cvs
> > > Module name:ports
> > > Changes by: lan...@cvs.openbsd.org   2024/01/23 07:29:57
> > > 
> > > Modified files:
> > > www/mozilla-firefox: Tag: OPENBSD_7_4 Makefile distinfo
> > > Removed files:
> > > www/mozilla-firefox/patches: Tag: OPENBSD_7_4
> > >  patch-toolkit_xre_glxtest_glxtest_cpp
> > > 
> > > Log message:
> > > www/mozilla-firefox: MFC update to 122.0.
> > > 
> > > see https://www.mozilla.org/en-US/firefox/122.0/releasenotes/
> > > fixes https://www.mozilla.org/en-US/security/advisories/mfsa2024-01/
> > > 
> > > drop patch from #1868782, merged upstream
> > > 
> > 
> > for some reasons, doesn't compile on arm64 -stable , it didn't compile last
> > backport either but I didn't have the time to check why
> 
> if it's only on arm64-stable and amd64-stable built fine, i'd triple
> check that www/mozilla/mozilla.port.mk is at r1.163.2.1, cf
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/mozilla/mozilla.port.mk?only_with_tag=OPENBSD_7_4
> 
> >  ===>  Checking files for firefox-122.0
> >  `/mnt/distfiles/mozilla/firefox-122.0.source.tar.xz' is up to date.
> > > > No size recorded for mozilla/firefox-122.0.source-profdata.tar.xz
> 
> it should be prefixed with -repacked, as is the case since 121 was
> merged in 7.4 stable
> 
> can you check make show=DISTFILES.profdata ? here on my 7.4-stable tree
> its firefox-122.0.source-profdata-repacked.tar.xz
> 
> esr is probably the same thing.
> 

this is super weird, I have different results on arm64 and amd64 but
both distinfo have the same checksum

arm64-stable$ pwd
/home/ports/www/firefox-esr
arm64-stable$ make show=DISTFILES.profdata 
firefox-115.7.0esr.source-profdata.tar.xz

arm64-stable$ cd ../mozilla-firefox
arm64-stable$ make show=DISTFILES.profdata 
firefox-122.0.source-profdata.tar.xz


amd64-stable$ pwd 
/home/ports/www/firefox-esr
amd64-stable$ make show=DISTFILES.profdata 
firefox-115.7.0esr.source-profdata-repacked.tar.xz

amd64-stable$ cd ../mozilla-firefox 
amd64-stable$ make show=DISTFILES.profdata 
firefox-122.0.source-profdata-repacked.tar.xz



Re: CVS: cvs.openbsd.org: ports

2024-01-24 Thread Solène Rapenne

On 23/01/2024 15:29, Landry Breuil wrote:

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2024/01/23 07:29:57

Modified files:
www/mozilla-firefox: Tag: OPENBSD_7_4 Makefile distinfo
Removed files:
www/mozilla-firefox/patches: Tag: OPENBSD_7_4
 patch-toolkit_xre_glxtest_glxtest_cpp

Log message:
www/mozilla-firefox: MFC update to 122.0.

see https://www.mozilla.org/en-US/firefox/122.0/releasenotes/
fixes https://www.mozilla.org/en-US/security/advisories/mfsa2024-01/

drop patch from #1868782, merged upstream



for some reasons, doesn't compile on arm64 -stable , it didn't compile 
last backport either but I didn't have the time to check why


 ===>  Checking files for firefox-122.0
 `/mnt/distfiles/mozilla/firefox-122.0.source.tar.xz' is up to date.

No size recorded for mozilla/firefox-122.0.source-profdata.tar.xz
 *** Error 1 in . (/home/ports//infrastructure/mk/bsd.port.mk:3277 
'/mnt/distfiles/mozilla/firefox-122.0.source-profdata.tar.xz': 
@lock=firef...)
 *** Error 2 in . (/home/ports//infrastructure/mk/bsd.port.mk:2551 
'_internal-fetch': @cd /home/ports/www/mozilla-firefox && 
PKGPATH=www/mozi...)
 *** Error 2 in . (/home/ports//infrastructure/mk/bsd.port.mk:2769 
'/build/tmp/pobj//firefox-122.0/.extract_done': @cd 
/home/ports/www/mozill...)
 *** Error 2 in /home/ports/www/mozilla-firefox 
(/home/ports//infrastructure/mk/bsd.port.mk:2677 'all': 
@lock=firefox-122.0;  export _LOCKS_H...)


a similar error for the esr flavor

 ===>  Checking files for firefox-esr-115.7.0
 `/mnt/distfiles/mozilla/firefox-115.7.0esr.source.tar.xz' is up to date.
 `/mnt/distfiles/mozilla/firefox-115.7.0esr.source-profdata.tar.xz' is 
up to date.
 !!! Extra file 
'mozilla/firefox-115.7.0esr.source-profdata-repacked.tar.xz' in 
/home/ports/www/firefox-esr/distinfo

 !!! Read up on SUPDISTFILES in bsd.port.mk(5)
 *** Error 1 in . (/home/ports//infrastructure/mk/bsd.port.mk:2574 
'_internal-checksum': @grep 2>/dev/null ^SIZE 
/home/ports/www/firefox-esr/...)
 *** Error 2 in . (/home/ports//infrastructure/mk/bsd.port.mk:2769 
'/build/tmp/pobj//firefox-esr-115.7.0/.extract_done': @cd 
/home/ports/www/...)
 *** Error 2 in /home/ports/www/firefox-esr 
(/home/ports//infrastructure/mk/bsd.port.mk:2677 'all': 
@lock=firefox-esr-115.7.0;  export _LOCKS...)




Re: fluidsynth update 2.3.4

2024-01-18 Thread Solène Rapenne
Le mercredi 17 janvier 2024 à 12:01 -0500, Thomas Frohwein a écrit :
> Hi,
> 
> Following up on [1], I adjusted the fluidsynth diff to the latest
> version 2.3.4. Got interested in this when revisiting simutrans [2]
> which looks for fluidsynth>=2.1. I tested fluidsynth with shockolate
> and generaluser-gs-soundfont which works as previously. I assume from
> looking at the prior discussion that updating fluidsynth would require
> updating qsynth (see [3]).
> 
> One (minor?) issue is that the test binaries aren't built and so `make
> test` doesn't show any useful results. I looked a little through the
> cmake files and couldn't spot the problem, but that could probably be
> revisited later...?
> 
> ok to catch up our fluidsynth port?
> 

I don't have much opinion about the diff, but the ports using
audio/fluidsynth all build well with it



Re: error on quirks

2023-11-20 Thread Solène Rapenne

Le 20/11/2023 à 13:56, Manuel Giraud a écrit :

Hi,

For the first time, I have to touch devel/quirks after a port
modification.  But when I try to update the patched devel/quirks from
port I get the following error:

$ cd /usr/ports/devel/quirks
$ make package
===>  Faking installation for quirks-6.197
/usr/ports/pobj/quirks-6.197/bin/install -d -m 755 
/usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/libdata/perl5/site_perl/OpenBSD/Quirks
/usr/ports/pobj/quirks-6.197/bin/install -c -m 644 
/usr/ports/devel/quirks/files/Quirks.pm 
/usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/libdata/perl5/site_perl/OpenBSD/Quirks.pm
/usr/libexec/locate.mklocatedb /usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/share/update.db
locate.code: bigram array too small to build db, index more files
*** Error 1 in . (Makefile:29 'do-install')
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3139 
'/usr/ports/pobj/quirks-6.197/fake-amd64/.fake_done': @cd /usr/ports/devel/q...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2233 
'/usr/ports/packages/amd64/no-arch/quirks-6.197.tgz': @cd /usr/ports/devel/q...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2723 
'_internal-package': @case X${_DEPENDS_CACHE} in  X) _DEPENDS_CACHE=$( mktem...)
*** Error 2 in /usr/ports/devel/quirks 
(/usr/ports/infrastructure/mk/bsd.port.mk:2702 'package': @lock=quirks-6.197;  
export _LOCKS_HELD=" q...)

BTW, I'm running -current.  What might cause this error?  Thanks.


What did you change in quirks? It's certainly a syntax error



Re: CVS: cvs.openbsd.org: ports

2023-10-26 Thread Solène Rapenne
Le mercredi 25 octobre 2023 à 10:06 -0600, Stuart Henderson a écrit :
> CVSROOT:/cvs
> Module name:ports
> Changes by: st...@cvs.openbsd.org  2023/10/25 10:06:17
> 
> Modified files:
> www/squid  : Tag: OPENBSD_7_4 Makefile distinfo 
> 
> Log message:
> backout to squid-6.3, there's an issue with one of the security fixes
> in 6.4 (triggering assertions).
> 

that didn't work for the LDAP flavor

===>  Building package for squid-ldap-6.3v0
Create /home/packages/amd64/all/squid-ldap-6.3v0.tgz
Creating package squid-ldap-6.3v0
checking dependencies|www/squid,-main  
Error: Dependency squid-6.3 doesn't match FULLPKGNAME: squid-6.3v0
checksumming...
Error: @depend www/squid,-main:squid-6.3:squid-6.3v0
  pattern squid-6.3 doesn't match default squid-6.3v0

pkg_create: can't continue
*** Error 1 in www/squid (/home/ports//infrastructure/mk/bsd.port.mk:2216 
'/home/packages/amd64/all/squid-ldap-6.3v0.tgz': @trap "cd /home/p...)
*** Error 2 in www/squid (/home/ports//infrastructure/mk/bsd.port.mk:2698 
'_internal-package': @case X${_DEPENDS_CACHE} in  X) _DEPENDS_CACH...)
*** Error 2 in www/squid (/home/ports//infrastructure/mk/bsd.port.mk:2677 
'package': @lock=squid-6.3-krb5;  export _LOCKS_HELD=" squid-6.3-k...)
--- Wed Oct 25 16:30:28 MDT 2023



Re: games/barony - face reality and retire?

2023-10-23 Thread Solène Rapenne
Le dimanche 22 octobre 2023 à 19:33 -0400, Thomas Frohwein a écrit :
> Hi,
> 
> I'm reaching out after trying to update barony unsuccessfully. First
> some background: Barony is a commercial game by TurningWheel with
> "open-source" engine development. "open-source" with quotation marks
> because the primary audio backend has been FMOD, which is a closed-
> source proprietary audio library. What makes this one a particularly
> painful port, to me at least, is the fact that updates to the game
> data, as downloaded from the digital storefronts depend on having a
> matching version of the game binaries. Multiple times in the past and
> present there has been a prolonged mismatch, meaning that the version
> accessible on the digital storefront isn't runnable at all with our
> port.
> 
> At this moment, this problem is particularly clear as can be seen in
> the github issue from 1 year ago [1]. Since (before) then, the OpenAL
> audio backend has been broken, with a comment [2] indicating that
> upstream is well aware of the broken implementation, but no fix or
> even
> response in sight.
> 
> I tested the current downloadable version (4.1) with our 3.3.7 port.
> As
> expected, it was not possible to run it, similar to when we had prior
> version desyncs:
> 
> $ barony -datadir=$HOME/games/barony/data/noarch/game
> [19-23-31] Data path is /home/thfr/games/barony/data/noarch/game
> [19-23-31] Output path is /home/thfr/.barony
> Caught segfault at address 0x0
> 
> I think the usefulness of the port is very low, given that for a
> significant portion over time the port is not in sync with the
> data that can be obtained, and maintenance seems quite hard especially
> with upstream showing little interest in keeping OpenAL as a viable
> backend at all. That's why I want to raise the question if it may be
> best to retire this port?
> 
> [1] https://github.com/TurningWheel/Barony/issues/691
> [2]
> https://github.com/TurningWheel/Barony/blob/master/src/init_game.cpp#L534

That's sad, but I'm ok for removal.

I've lost too much time trying to figure why it wasn't working, and
hunting for the right installer on different stores without success.

It was nice having it, maybe we could import it again in a few years
when they would really stop the development of the game and there will
be no risk of upstream version change.



Re: new net/go-sendxmpp

2023-10-12 Thread Solène Rapenne
On Sun, 2023-09-24 at 15:12 +0200, Solene Rapenne wrote:
> this program is meant to replace net/sendxmpp which is unmaintained
> and
> broken for most users (one person reported it worked for them but
> would
> be happy to switch to something maintained)
> 
> it's just a command line tool that takes a message in parameter or on
> stdin and send it to XMPP contacts/MUC. It's working well and
> maintained
> 
> ok to import?
> 
> Once done, I'll ask to remove net/sendxmpp and add a quirk entry to
> automatically upgrade net/sendxmpp to net/go-sendxmpp, and add a FAQ
> entry about this change because the configuration file format changed.

ping :)



Re: Ports-tree fetch: No space left on device

2023-10-01 Thread Solène Rapenne

Le 01/10/2023 à 16:27, Johannes Thyssen Tishman a écrit :

Hi,

I'm trying to update my ports tree with 'cvs -q up -Pd -A' and I'm
getting the following error:


cannot create_adm_p /tmp/cvs-serv54231/textproc/cdiff
No space left on device


 From this I assume that there may not be enough space on /tmp but
based on the output of 'df -h' it should:

Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd1a  986M135M801M15%/
/dev/sd1l  295G   17.1G263G 7%/home
/dev/sd1d  3.9G2.0M3.7G 1%/tmp
/dev/sd1f 29.1G3.7G   23.9G14%/usr
/dev/sd1g  986M290M647M31%/usr/X11R6
/dev/sd1h 19.4G8.4G   10.0G46%/usr/local
/dev/sd1k  5.8G2.0K5.5G 1%/usr/obj
/dev/sd1j  2.9G2.0K2.8G 1%/usr/src
/dev/sd1e 19.1G   65.0M   18.1G 1%/var

Is this not enough? IIRC my ports-tree should not be outdated by
more than a week or two. I really only use CVS for ports by running
the above mentioned command everytime I'm working with ports.

Thanks.

Kind regards,
Johannes



I guess /tmp/ is running out of inodes, try to check df -i



Re: exim

2023-09-30 Thread Solène Rapenne

Le 30/09/2023 à 15:27, Stuart Henderson a écrit :

With OpenBSD release fast approaching and considering the lack of solid
information about the vulnerabilities, I think we should probably mark
mail/exim BROKEN for now.

And also consider whether we want to keep this in ports at all...
The response to this was much weaker than I'd expect from maintainers
of software like this (note that it is a huge setuid root binary so
it'd really be nice if they were a bit more active on that front)

Index: Makefile
===
RCS file: /cvs/ports/mail/exim/Makefile,v
retrieving revision 1.143
diff -u -p -r1.143 Makefile
--- Makefile26 Sep 2023 12:28:11 -  1.143
+++ Makefile30 Sep 2023 12:52:52 -
@@ -1,3 +1,7 @@
+BROKEN =   known unfixed remote vulnerabilities, likely serious
+# https://www.openwall.com/lists/oss-security/2023/09/29/5
+# https://www.openwall.com/lists/oss-security/2023/09/29/10
+
  COMMENT-main =flexible mail transfer agent
  COMMENT-eximon =  X11 monitor tool for Exim MTA
  



What would marking it BROKEN solve? People upgrading to 7.4 will keep
the old version, but indeed new user won't be able to install it.

I'd prefer to see it removed, including a quirks entry with the reason,
if it's such a trashfire that shouldn't be used



Re: CVS: cvs.openbsd.org: ports

2023-09-29 Thread Solène Rapenne

Le 28/09/2023 à 23:37, Stuart Henderson a écrit :

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2023/09/28 15:37:21

Modified files:
www/ap2-mod_jk : Tag: OPENBSD_7_3 Makefile
www/ap2-mod_jk/patches: Tag: OPENBSD_7_3 patch-native_configure
Added files:
www/ap2-mod_jk/patches: Tag: OPENBSD_7_3
patch-native_apache-2_0_Makefile_in

Log message:
update to ap2-mod_jk-1.2.49, CVE-2023-41081:
Unexpected use of first declared worker in mod_jk for unmapped request



this fails to compile


amd64-stable$ make
===> ap2-mod_jk-1.2.49 depends on: apache-httpd-* -> apache-httpd-2.4.56
===> ap2-mod_jk-1.2.49 depends on: gmake-* -> gmake-4.3
===>  Verifying specs:  pthread
===>  found pthread.27.0
===>  Checking files for ap2-mod_jk-1.2.49
`/mnt/distfiles/tomcat-connectors-1.2.49-src.tar.gz' is up to date.
!!! Extra file 'tomcat-connectors-1.2.48-src.tar.gz' in 
/home/ports/www/ap2-mod_jk/distinfo
!!! Read up on SUPDISTFILES in bsd.port.mk(5)
*** Error 1 in . (/home/ports//infrastructure/mk/bsd.port.mk:2497 
'_internal-checksum': @grep 2>/dev/null ^SIZE /home/ports/www/ap2-mod_jk/d...)
*** Error 2 in . (/home/ports//infrastructure/mk/bsd.port.mk:2694 
'/build/tmp/pobj//ap2-mod_jk-1.2.49/.extract_done': @cd /home/ports/www/ap...)
*** Error 2 in /home/ports/www/ap2-mod_jk 
(/home/ports//infrastructure/mk/bsd.port.mk:2600 'all': 
@lock=ap2-mod_jk-1.2.49;  export _LOCKS_HE...)



Re: [new] Nickel configuration language

2023-09-26 Thread Solène Rapenne
Le lundi 25 septembre 2023 à 22:25 -0700, Evan Silberman a écrit :
> Hi ports,
> 
> Here's a port of Nickel (https://nickel-lang.org/), a programmable
> configuration language that allows both strong-typing and more dynamic
> contract-driven specification of configurations.
> 
> There doesn't seem to be a uniform approach to building ports of
> applications that happen to be distributed as Rust crates; I'm just
> using the cargo index as SITES here.
> 
> Not hopping on MAINTAINER at this time, but maybe later.
> 
> Evan

thanks! As you used crates, it's really different than my port
submission I sent a while ago, but it should be easier to maintain.

however, "make test" fails, I'm not sure why though, maybe some missing
crates?



Re: UPDATE net/prosody from MAINTAINER

2023-09-06 Thread Solène Rapenne
Le mercredi 06 septembre 2023 à 15:04 +, Lucas a écrit :
> Hi ports,
> 
> Update for Prosody 0.12.4, fresh out of the oven. Maintainance
> release,
> with bugfixes small improvements. Changelog:
> 
>  - core.certmanager: Update Mozilla TLS config to version 5.7
>  - util.error: Fix error on conversion of invalid error stanza
>  - util.array: Fix new() library function
>  - util.array: Expose new() on module table
>  - prosodyctl: Fix output of error messages containing '%'
>  - util.prosodyctl.check: Correct suggested replacement for
>    'disallow_s2s'
>  - util.prosodyctl.check: Allow same config syntax variants as in
>    Prosody for some options
>  - util.prosodyctl.check: Fix error where hostname can't be turned
> into
>    A label
>  - util.prosodyctl.check: Hint about the 'external_addresses' config
>    option
>  - util.prosodyctl.check: Suggest 'http_cors_override' instead of
> older
>    CORS settings
>  - util.prosodyctl.check: Validate format of module list options
>  - mod_websocket: Add a 'pre-session-close' event
>  - mod_smacks: Fix stray watchdog closing sessions
>  - mod_csi_simple: Disable revert-to-inactive timer when going to
> active
>    mode
>  - mod_csi_simple: Clear delayed active mode timer on disable
>  - mod_admin_shell: Fix display of remote cert status when expired etc
>  - mod_smacks: Replace existing watchdog when starting hibernation
>  - mod_http: Fix error if 'access_control_allow_origins' is set
>  - mod_pubsub: Send correct 'jid' attribute in disco#items
>  - mod_http: Unhook CORS handlers only if active to fix an error
>  - mod_s2s: Add event where resolver for s2sout can be tweaked
> 
> It's already running fine in my server.
> 
> Partly related: I wanted to switch it to Lua 5.4, but that requires
> adding lua54 FLAVOR to almost all the deps. Should I make that change
> in two parts, first enabling the FLAVORs and then switching Prosody to
> Lua 5.4, or should I fold all those changes into this patch?
> 
> -Lucas
> 
> 
> diff /usr/ports
> commit - d2d0ce8a223822322e5653ad5efe79e7a205019a
> path + /usr/ports
> blob - 9c12606c38f94966b6da741b6a5597cefbbbef60
> file + net/prosody/Makefile
> --- net/prosody/Makefile
> +++ net/prosody/Makefile
> @@ -1,9 +1,9 @@
>  COMMENT =  communications server for Jabber/XMPP written in Lua
> -DISTNAME = prosody-0.12.3
> +DISTNAME = prosody-0.12.4
>  CATEGORIES =   net
>  HOMEPAGE = https://prosody.im/
>  
> -MAINTAINER =   Lucas 
> +MAINTAINER =   Lucas Gabriel Vuotto 
>  
>  MASTER_SITES = https://prosody.im/downloads/source/
>  
> blob - 5cd92532a69aeebcbe5d4d247328e933a34069e7
> file + net/prosody/distinfo
> --- net/prosody/distinfo
> +++ net/prosody/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (prosody-0.12.3.tar.gz) =
> NdoNAx/0YECi1jjgBNQlXiSbYyP+YhLbnd12tAHbIQE=
> -SIZE (prosody-0.12.3.tar.gz) = 615302
> +SHA256 (prosody-0.12.4.tar.gz) =
> R9cSJzwvKVWMQS9s2uwHMmC7wmt92iQ9tYAzAYPWWFY=
> +SIZE (prosody-0.12.4.tar.gz) = 616043
> 

ok solene@

I tested it on 7.3-stable though, so ok to backport too :)



Re: WXNEEDED flag stripped when installing

2023-09-06 Thread Solène Rapenne
> 
> 
> Forgot to add REVISION=0 to the Makefile. Facepalm.
> I knew this _had_ to be my fault, just wasn't getting there, and was
> too
> trigger happy with the emails.  Sorry for the noise.
> 

if you don't want to bother with REVISION when working on a port, you
can use "make clean=all" that should clean pobj,plist,package (and not
the distfiles IIRC) before trying again



Re: net/mldonkey and lang/ocaml-camlp4 still needed?

2023-09-05 Thread Solène Rapenne
Le mardi 05 septembre 2023 à 18:26 +0200, Volker Schlecht a écrit :
> Looking towards an upgrade to Ocaml 5.x sometime in the not-so-distant
> future,
> what are the opinions on net/mldonkey which still ties us to keeping
> lang/ocaml-camlp4
> around?
> 
> Maybe it's just me, but for net/mldonkey not even the homepage still
> loads ...
> 

ok solene@ to remove mldonkey , we still have amule for eDonkey P2P
which is still maintained (last release in 2022)



Re: games/tome4: update to 1.7.6 (still SIGILL)

2023-09-02 Thread Solène Rapenne
Le samedi 02 septembre 2023 à 17:52 +, Klemens Nanni a écrit :
> Both packages 1.7.4 and new 1.7.6 fail the same way on my T14 gen3
> Intel:
> 
> WebCore config: library(/usr/local/share/libte4-web.so)
> spawn(/usr/local/share/cef3spawn)
> Loading WebCore: Failed loading /usr/local/share/libte4-web.so: File
> not found
> [CPU] Detected 12 CPUs
> OpenAL device available: OpenAL Soft (default OpenAL Soft)
> Available video driver: x11
> Available video driver: KMSDRM
> Available video driver: offscreen
> Available video driver: dummy
> Illegal instruction (core dumped) 
> 
> #0  0x0593bb884587 in ?? ()
> [Current thread is 1 (process 336493)]
> #0  0x0593bb884587 in ?? ()
> #1  0x0593bb841765 in ?? ()
> #2  0x0593bb7d1d75 in ?? ()
> #3  0x0593bb7d2681 in ?? ()
> #4  0x0593bb74ee72 in ?? ()
> #5  0x in ?? ()
> 
> 
> It used to work on my X230 just fine (although long ago),
> pretty sure it did start on the T14 at some point.
> 
> Anyone else being able to run this game on their machine?
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/tome4/Makefile,v
> retrieving revision 1.29
> diff -u -p -r1.29 Makefile
> --- Makefile8 May 2022 09:39:33 -   1.29
> +++ Makefile2 Sep 2023 17:30:43 -
> @@ -8,10 +8,9 @@ ONLY_FOR_ARCHS = i386 amd64
>  COMMENT-main = graphical sdl rogue-like game
>  COMMENT-data = data for Tales of Maj'Eyal
>  
> -V =1.7.4
> +V =1.7.6
>  PKGNAME =  tome4-${V}
>  CATEGORIES =   games x11
> -REVISION = 0
>  
>  MASTER_SITES = https://te4.org/dl/t-engine/
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/tome4/distinfo,v
> retrieving revision 1.12
> diff -u -p -r1.12 distinfo
> --- distinfo29 Jun 2021 06:45:08 -  1.12
> +++ distinfo2 Sep 2023 17:31:36 -
> @@ -1,2 +1,2 @@
> -SHA256 (t-engine4-src-1.7.4.tar.bz2) =
> w1NPM/SMnPAnAl6z9E6Xsj3mEqZtXzFe1IMPmlKr8qQ=
> -SIZE (t-engine4-src-1.7.4.tar.bz2) = 486263402
> +SHA256 (t-engine4-src-1.7.6.tar.bz2) =
> mJ3qAIA/jNyt4CT0ZH1IC7GsDUN8JUKSwHVJwnKkaAw=
> +SIZE (t-engine4-src-1.7.6.tar.bz2) = 500085010
> 

isn't this an IBT issue? I tried a month ago and it "worked" if running
in window mode (there is a white screen issue too)



Re: CVS: cvs.openbsd.org: ports

2023-09-01 Thread Solène Rapenne
Le mardi 29 août 2023 à 07:00 -0600, Landry Breuil a écrit :
> CVSROOT:/cvs
> Module name:ports
> Changes by: lan...@cvs.openbsd.org   2023/08/29 07:00:13
> 
> Modified files:
> www/mozilla-firefox: Tag: OPENBSD_7_3 Makefile distinfo 
> www/mozilla-firefox/patches: Tag: OPENBSD_7_3 
>  patch-build_moz_configure_nss_configure 
> www/mozilla-firefox/pkg: Tag: OPENBSD_7_3 PLIST 
> 
> Log message:
> www/mozilla-firefox: MFC update to 117.0.
> 
> see https://www.mozilla.org/en-US/firefox/117.0/releasenotes/
> fixes https://www.mozilla.org/en-US/security/advisories/mfsa2023-34/
> 

it doesn't compile for me, on aarch64 and amd64

here are the last ~50 lines of the build log

/build/tmp/pobj//firefox-117.0/bin/c++ -std=gnu++17 -o vaapitest.o -c 
-flto=thin -I/build/tmp/pobj/firefox-117.0/build-aarch64/dist/stl_wrappers 
-I/build/tmp/pobj/firefox-117.0/build-
aarch64/dist/system_wrappers -include 
/build/tmp/pobj/firefox-117.0/firefox-117.0/config/gcc_hidden.h 
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DNDEBUG=1 
-DTRIMMED=1 -
I/build/tmp/pobj/firefox-117.0/firefox-117.0/widget/gtk/vaapitest 
-I/build/tmp/pobj/firefox-117.0/build-aarch64/widget/gtk/vaapitest 
-I/build/tmp/pobj/firefox-117.0/firefox-117.0/media/mozva -
I/build/tmp/pobj/firefox-117.0/build-aarch64/dist/include 
-I/usr/local/include/nspr -I/usr/local/include/nss -I/usr/local/include/nspr 
-I/build/tmp/pobj/firefox-117.0/build-aarch64/dist/include/nss -
DMOZILLA_CLIENT -include 
/build/tmp/pobj/firefox-117.0/build-aarch64/mozilla-config.h 
-Wno-backend-plugin -fno-sized-deallocation -fno-aligned-new -O2 -pipe -g 
-fno-exceptions -fPIC -fno-rtti -
ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread 
-pipe -gdwarf-4 -O2 -pipe -g -fomit-frame-pointer -funwind-tables -Wall 
-Wbitfield-enum-conversion -Wdeprecated-this-capture
-Wempty-body -Wformat-type-confusion -Wignored-qualifiers -Wpointer-arith 
-Wshadow-field-in-constructor-modified -Wsign-compare 
-Wtautological-constant-in-range-compare -Wtype-limits -Wno-
error=tautological-type-limit-compare -Wunreachable-code 
-Wunreachable-code-return -Wunused-but-set-parameter -Wno-invalid-offsetof 
-Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -
Wfloat-zero-conversion -Wloop-analysis -Wno-range-loop-analysis -Wc++2a-compat 
-Wenum-compare-conditional -Wenum-float-conversion -Wno-error=deprecated 
-Wno-error=deprecated-anon-enum-enum-conversion
-Wno-error=deprecated-enum-enum-conversion -Wno-error=deprecated-this-capture 
-Wcomma -Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete 
-Wno-error=deprecated-declarations -Wno-
error=array-bounds -Wno-error=free-nonheap-object -Wno-error=atomic-alignment 
-Wformat -Wformat-security -Wno-psabi -Wthread-safety 
-Wno-error=builtin-macro-redefined -Wno-unknown-warning-option -
I/usr/local/include/gtk-3.0/unix-print -I/usr/local/include/gtk-3.0 
-I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 
-I/usr/X11R6/include -I/usr/local/include/dbus-1.0 -
I/usr/local/lib/dbus-1.0/include -I/usr/local/include 
-I/usr/X11R6/include/libdrm -I/usr/local/include/pango-1.0 
-I/usr/local/include/harfbuzz -I/usr/local/include/fribidi 
-I/usr/local/include/atk-1.0
-I/usr/local/include/cairo -I/usr/X11R6/include/freetype2 
-I/usr/X11R6/include/pixman-1 -I/usr/local/include/gdk-pixbuf-2.0 
-I/usr/local/include/libpng16 -I/usr/local/include/gio-unix-2.0 -pthread -
I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
-I/usr/local/include/pango-1.0 -I/usr/local/include -pthread 
-I/usr/local/include/fribidi -I/usr/X11R6/include -I/usr/local/include/cairo
-I/usr/local/include/libpng16 -I/usr/X11R6/include/pixman-1 
-I/usr/local/include/harfbuzz -I/usr/X11R6/include/freetype2 
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -fno-strict-
aliasing -ffp-contract=off 
-fprofile-use=/build/tmp/pobj//firefox-117.0/merged.profdata 
-Wno-error=backend-plugin -MD -MP -MF .deps/vaapitest.o.pp   
/build/tmp/pobj/firefox-117.0/firefox-
117.0/widget/gtk/vaapitest/vaapitest.cpp
/build/tmp/pobj/firefox-117.0/firefox-117.0/toolkit/xre/glxtest/glxtest.cpp:196:3:
 warning: code will never be executed [-Wunreachable-code]
  log("GLX_TEST: get_pci_status start\n");
  ^~~
1 warning generated.
gmake[3]: Leaving directory 
'/build/tmp/pobj/firefox-117.0/build-aarch64/toolkit/xre/glxtest'
gmake[3]: Entering directory 
'/build/tmp/pobj/firefox-117.0/build-aarch64/security/manager/ssl/builtins'
security/manager/ssl/builtins/force-cargo-library-build
/usr/local/bin/cargo rustc -j4 --release --frozen --manifest-path 
/build/tmp/pobj/firefox-117.0/firefox-117.0/security/manager/ssl/builtins/Cargo.toml
 -vv--lib --target=aarch64-unknown-openbsd --
features 'mozilla-central-workspace-hack' --  -Clto=thin
warning: a `-j` argument was passed to Cargo but Cargo is also configured with 
an external jobserver in its 

Re: net/dendrite out of date

2023-08-30 Thread Solène Rapenne
Le mercredi 30 août 2023 à 17:37 +, lino.n...@mailbox.org a écrit :
> The net/dendrite port is out of date. Latest version is 0.13.2, ports
> version is 0.12.0.
> 

per the tool used to track which ports are outdated, we have 1491
outdated sources, which represents 16.30% of all the sources.

https://portroach.openbsd.org/

it's pointless to report outdated packages on the mailing list



Re: update games/openttd

2023-08-03 Thread Solène Rapenne
Le Wednesday 02 August 2023 à 23:59 -0400, George Koehler a écrit :
> On Wed, 2 Aug 2023 21:35:32 +0100
> Stuart Henderson  wrote:
> 
> > On 2023/08/02 21:42, Florian Viehweger wrote:
> > > I'd like to do a test on i386 first before committing it. There
> > > was a
> > > problem with SDL in the past [1] which prevented it from being
> > > built.
> > 
> > that issue was fixed (and the fix is still present after your diff)
> > so no need to test for that.
> 
> I committed openttd 13.4 without an i386 test.
> 
> I tried 13.4 on powerpc; the game runs slowly on my 1 GHz single-core
> PowerPC G4, with low frame rate and stuttering music.  I prefer to
> play OpenTTD on amd64.

there is a command line flag to change something in openttd and it
works fine on the G4 without much graphical difference.

using openttd --help you will get a list of "blitters" that could be
used with -b parameter, the default one doesn't work fine on the G4 but
you could try another one



Re: rclone

2023-07-03 Thread Solène Rapenne
On Sun, 2023-07-02 at 18:36 -0500, Edward Ahlsen-Girard wrote:
> Has it been removed from packages? rclone-browser is still a package,
> but it can't install. I've tried number mirrors.
> 

lang/go is broken on snapshots due to a general work on IBT

See https://marc.info/?t=16871853121=1=2

as a result, go programs can't be built at the moment



Re: Port Request

2023-07-01 Thread Solène Rapenne
On Sat, 2023-07-01 at 12:31 +, Mikolaj Kucharski wrote:
> On Sat, Jul 01, 2023 at 02:03:26PM +0200, Solène Rapenne wrote:
> > On Sat, 2023-07-01 at 11:48 +, Umgeher Torgersen wrote:
> > > On Fri, Jun 30, 2023 at 09:24:54AM +, luffy20201 wrote:
> > > > Hello OpenBSD Devs! I want to make a request, can you guys
> > > > please
> > > > try to port ytfzf to OBSD. I used it a lot on GNU/linux, and I
> > > > would
> > > > greatly appreciate if you guys could. Thank You
> > > 
> > > sure! with fries?
> > > 
> > > thank you for your order!
> > > 
> > 
> > there is no need to be condescending for free, at best, just don't
> > reply.
> > 
> > The program actually looks interesting, it only requires curl and jq
> > as
> > dependencies. However, it may be so trivial to install it locally,
> > I'm
> > not sure this deserve to be packaged. I'll give it a try.
> > 
> 
> It also seems to depend on fzf:
> 
> $ sh ytfzf -m music
> Scraping YouTube (with https://invidious.flokinet.to) (music, pg: 1)
> [ERROR]: fzf not installed, cannot use the default menu
> 

it only requires curl and jq to work, but it has a lot of extra
dependencies for more features

I suppose a package should enable all the features as long as it doesn't
pull an entire desktop like GNOME as a dependency



Re: Port Request

2023-07-01 Thread Solène Rapenne
On Sat, 2023-07-01 at 11:48 +, Umgeher Torgersen wrote:
> On Fri, Jun 30, 2023 at 09:24:54AM +, luffy20201 wrote:
> > Hello OpenBSD Devs! I want to make a request, can you guys please
> > try to port ytfzf to OBSD. I used it a lot on GNU/linux, and I would
> > greatly appreciate if you guys could. Thank You
> 
> sure! with fries?
> 
> thank you for your order!
> 

there is no need to be condescending for free, at best, just don't
reply.

The program actually looks interesting, it only requires curl and jq as
dependencies. However, it may be so trivial to install it locally, I'm
not sure this deserve to be packaged. I'll give it a try.



Re: CVS: cvs.openbsd.org: ports

2023-06-25 Thread Solène Rapenne
On Mon, 2023-06-19 at 13:52 -0600, Kurt Mosiejczuk wrote:
> CVSROOT:/cvs
> Module name:ports
> Changes by: k...@cvs.openbsd.org 2023/06/19 13:52:01
> 
> Modified files:
> lang/python/3.9: Tag: OPENBSD_7_3 Makefile distinfo 
> lang/python/3.9/pkg: Tag: OPENBSD_7_3 PLIST-main 
> 
> Log message:
> Update to Python 3.9.17
> 
> MFC
> 
> https://docs.python.org/release/3.9.17/whatsnew/changelog.html#changelog
> 

this doesn't package

===>  Building package for python-3.9.17
Create /home/packages/amd64/all/python-3.9.17.tgz
Creating package python-3.9.17
checksumming|* 
| 22%
Error: /build/tmp/pobj//Python-3.9.17/fake-
amd64/usr/local/lib/python3.9/config-3.9/__pycache__/python-
config.cpython-39.opt-1.pyc does not exist
Error: /build/tmp/pobj//Python-3.9.17/fake-
amd64/usr/local/lib/python3.9/config-3.9/__pycache__/python-
config.cpython-39.opt-2.pyc does not exist
Error: /build/tmp/pobj//Python-3.9.17/fake-
amd64/usr/local/lib/python3.9/config-3.9/__pycache__/python-
config.cpython-39.pyc does not exist
pkg_create: can't continue
*** Error 1 in lang/python/3.9
(/home/ports//infrastructure/mk/bsd.port.mk:2140
'/home/packages/amd64/all/python-3.9.17.tgz': @trap "cd /hom...)
*** Error 2 in lang/python/3.9
(/home/ports//infrastructure/mk/bsd.port.mk:2621 '_internal-package':
@case X${_DEPENDS_CACHE} in  X) _DEPEND...)
*** Error 2 in lang/python/3.9
(/home/ports//infrastructure/mk/bsd.port.mk:2600 'package':
@lock=Python-3.9.17;  export _LOCKS_HELD=" Python...)
===> Exiting lang/python/3.9 with an error



Re: musikcube failed to build

2023-06-11 Thread Solène Rapenne
On Sun, 11 Jun 2023 22:41:18 +0200
Antoine Jacoutot  wrote:

> Hi.
> 
> It seems that if textproc/nlohmann-json is around then dpb(1) junks
> it, the build fails.
> 
> Full log attached.
> 

I'm not very familiar with junking in dpb.

Does it mean textproc/nlohmann-json should be added as a build
dependency for musikcube, or that junking should be disabled in
musikcube?



Re: [Update] shells/nushell 0.81.0

2023-06-09 Thread Solène Rapenne
On Fri, 2023-06-09 at 13:51 +0200, Volker Schlecht wrote:
> * Updates nushell to 0.81.0
> https://www.nushell.sh/blog/2023-06-06-nushell_0_81.html
> 
> * Make COMMENT the same as in the project's homepage
> 
> * This release (temporarily) removes support for ARMv7
>    and RISC-V, added those to NOT_FOR_ARCHS
> 
> Built and tested on amd64.

the port is fine for me, but that new version seems to have a huge
regression, or did they change too much things?

The output of this command is completely wrong with the new version

ls /bsd | find str bsd




Re: installing unsigned packages

2023-06-05 Thread Solène Rapenne
On Mon, 2023-06-05 at 22:23 +0200, Jan Stary wrote:
> This is current/amd64.  I just build the rsync package
> as currently tweaked for xxhash, up to make package;
> now I'm trying to install it.
> 
> $ env TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all/ make update
> ===> Updating for rsync-3.2.7p0
> Upgrading from rsync-3.2.7
> doas (h...@box.stare.cz) password: 
> quirks-6.133 signed on 2023-06-04T21:20:32Z
> file:/usr/ports/packages/amd64/all/rsync-3.2.7p0.tgz: unsigned
> package
> Can't find /usr/ports/packages/amd64/all/rsync-3.2.7p0.tgz
> Couldn't install rsync-3.2.7p0
> 
> Isn't TRUSTED_PKG_PATH supposed to enforce pkg_add -Dunsigned?
> 
> Also, "Can't find /usr/ports/packages/amd64/all/rsync-3.2.7p0.tgz"
> seems odd as the file exists.
> 
> Jan
> 
hi

a wild guess is that you use PORTS_PRIVSEP but your doas configuration
line doesn't have "keepenv", so pkg_add is run without TRUSTED_PKG_PATH
because of doas not keeping it



Re: update productivity/vym

2023-06-04 Thread Solène Rapenne
On Sun, 2023-05-07 at 20:12 +0200, Solène Rapenne wrote:
> Le Sun, 7 May 2023 17:07:06 +0200,
> Solène Rapenne  a écrit :
> 
> > I updated vym to latest version, a lot of changes, it moved to
> > GitHub
> > and from gmake to cmake, which simplify the port
> > 
> > it works fine for me, I needed to add a patch to fix unzip/zip
> > binaries
> > path because it's hardcoded.
> > 
> > However, all the icons are installed in /usr/local/share/icons/
> > which
> > seems wrong (and portcheck reports it), but I don't know how to
> > change
> > the path here, a little help would be appreciated :)
> > 
> 

ping



Re: NEW: devel/bazel

2023-06-04 Thread Solène Rapenne
On Sun, 2023-01-29 at 17:34 -0500, Matt Hildebrand wrote:
> This port is now updated to Bazel 6.0.0. The port is at:
> https://github.com/aldersondrive/bazel_openbsd_port
> 
> Bazel is a polyglot build tool.
> 
> Web site: https://bazel.build/
> 
> In my testing, this port works on amd64. The build fails on i386,
> due to C++ code that requires a 64-bit platform.
> 
> Feedback/suggestions are welcome.
> 
> Thank you.
> 

hi, thanks for your interest into porting bazel to OpenBSD

I've been able to compile the port successfully, but if I run it by
typing "bazel", I have the following error message:

ERROR: couldn't find java at '/usr/local/bin/jdk-17/bin/java'

I'm not sure why... I only have jdk-11 installed as a dependency.



remove net/sendxmpp

2023-06-04 Thread Solène Rapenne
I'd like to remove net/sendxmpp, it's dead and not working.

https://github.com/lhost/sendxmpp/issues

While there, we could remove net/p5-Net-XMPP as it's only used by
net/sendxmpp.

There is a working and maintained Go alternative we could import as a
replacement https://salsa.debian.org/mdosch/go-sendxmpp



Re: UPDATE: Dolphin 20230523

2023-06-04 Thread Solène Rapenne
On Wed, 2023-05-24 at 00:19 -0400, Brad Smith wrote:
> Here is an update to Dolphin 20230523 snapshot.
> 
> Rolling up 4 years worth of work. I don't see any sort of change log.
> 

Nice, thanks!

It builds fine on amd64, and the GUI runs. The diff looks good. I can't
try dolphin more, but I'd be happy to commit if someone else is ok.



Re: CVS: cvs.openbsd.org: ports

2023-06-03 Thread Solène Rapenne
On Fri, 2023-06-02 at 17:07 -0600, Aisha Tammy wrote:
> CVSROOT:/cvs
> Module name:ports
> Changes by: ai...@cvs.openbsd.org  2023/06/02 17:07:35
> 
> Modified files:
> meta   : Tag: OPENBSD_7_3 Makefile 
> 
> Log message:
> hook jitsi into the build
> 

Is it a mistake or done on purpose?

It looks like you added a new software into 7.3


Re: update productivity/vym

2023-05-07 Thread Solène Rapenne
Le Sun, 7 May 2023 17:07:06 +0200,
Solène Rapenne  a écrit :

> I updated vym to latest version, a lot of changes, it moved to GitHub
> and from gmake to cmake, which simplify the port
> 
> it works fine for me, I needed to add a patch to fix unzip/zip binaries
> path because it's hardcoded.
> 
> However, all the icons are installed in /usr/local/share/icons/ which
> seems wrong (and portcheck reports it), but I don't know how to change
> the path here, a little help would be appreciated :)
> 

patch was missing

Index: Makefile
===
RCS file: /home/cvs/ports/productivity/vym/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile3 Oct 2022 21:18:19 -   1.33
+++ Makefile7 May 2023 15:00:48 -
@@ -1,55 +1,35 @@
 COMMENT=   generate and manipulate maps of your thoughts
 
-DISTNAME=  vym-2.6.0
+VERSION =  2.9.0
+GH_ACCOUNT =   insilmaril
+GH_PROJECT =   vym
+GH_TAGNAME =   v${VERSION}
+DISTNAME=  vym-${VERSION}
 CATEGORIES=productivity x11
-REVISION=  3
 
 HOMEPAGE=  https://www.insilmaril.de/vym/
 
 # modified GPLv2
 PERMIT_PACKAGE=Yes
 
-MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=vym/}
-EXTRACT_SUFX=  .tar.bz2
-
-WANTLIB += GL Qt5Core Qt5DBus Qt5Gui Qt5Network Qt5PrintSupport
-WANTLIB += Qt5Svg Qt5Widgets Qt5Xml c m pthread
+WANTLIB += Qt5Core Qt5DBus Qt5Gui Qt5Network Qt5PrintSupport
+WANTLIB += Qt5Script Qt5Svg Qt5Widgets Qt5Xml c m pthread
 WANTLIB += ${COMPILER_LIBCXX}
 
-MODULES=   devel/qmake \
+MODULES=   devel/cmake \
x11/qt5
-MODQMAKE_ARGS= DEFINES+=VYM_DOCDIR=\\\"${PREFIX}/share/doc/vym\\\"
 
 RUN_DEPENDS=   archivers/zip \
archivers/unzip \
-   textproc/libxslt
+   devel/desktop-file-utils \
+   misc/shared-mime-info \
+   textproc/libxslt \
+   x11/gtk+4,-guic
 
-LIB_DEPENDS=   x11/qt5/qtsvg
+LIB_DEPENDS=   x11/qt5/qtscript \
+   x11/qt5/qtsvg
 
-PORTHOME=  ${WRKDIR}
+#PORTHOME= ${WRKDIR}
 NO_TEST=   Yes
-
-SHARE_DIRS=flags flags/freemind icons scripts styles
-
-pre-configure:
-   @echo "QMAKE_CXXFLAGS_RELEASE=${CXXFLAGS}" \
-   >> ${WRKSRC}/vym.pro
-   ${SUBST_CMD} ${WRKSRC}/mainwindow.cpp ${WRKSRC}/main.cpp
-
-do-install:
-   ${INSTALL_PROGRAM} ${WRKBUILD}/vym ${PREFIX}/bin
-   ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/vym/
-   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/vym/
-   ${INSTALL_DATA} ${WRKSRC}/doc/*.pdf ${PREFIX}/share/doc/vym/
-   ${INSTALL_DATA} ${WRKSRC}/demos/* ${PREFIX}/share/examples/vym/
-.for i in ${SHARE_DIRS}
-   ${INSTALL_DATA_DIR} ${PREFIX}/share/vym/${i}
-   find ${WRKSRC}/${i}/ -type f -exec \
-   ${INSTALL_DATA} {} ${PREFIX}/share/vym/${i} \;
-.endfor
-   ${INSTALL_DATA} ${WRKSRC}/doc/vym.1.gz ${PREFIX}/man/man1
-   gunzip -f ${PREFIX}/man/man1/vym.1.gz
-   sed -i 's,/usr/share/doc/packages,${TRUEPREFIX}/share/doc,' \
-   ${PREFIX}/man/man1/vym.1
 
 .include 
Index: distinfo
===
RCS file: /home/cvs/ports/productivity/vym/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo29 Apr 2018 08:13:07 -  1.9
+++ distinfo7 May 2023 13:17:59 -
@@ -1,2 +1,2 @@
-SHA256 (vym-2.6.0.tar.bz2) = fcFyGvsnEJrcS0rqrGIX/dEpSzjoGzOgikdlYvvfoUE=
-SIZE (vym-2.6.0.tar.bz2) = 6766806
+SHA256 (vym-2.9.0.tar.gz) = ckUWgaOk4UlPJcH/nUEQwTgJXWPtTRRxx27ZB2BqfNs=
+SIZE (vym-2.9.0.tar.gz) = 8594682
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/productivity/vym/pkg/PLIST,v
retrieving revision 1.8
diff -u -p -r1.8 PLIST
--- pkg/PLIST   11 Mar 2022 19:51:48 -  1.8
+++ pkg/PLIST   7 May 2023 14:02:43 -
@@ -1,211 +1,243 @@
 @bin bin/vym
-@man man/man1/vym.1
-share/doc/vym/
-share/doc/vym/vym.pdf
-share/doc/vym/vym_es.pdf
-share/doc/vym/vym_fr.pdf
-share/examples/vym/
-share/examples/vym/ao-report-example.vym
-share/examples/vym/frames.vym
-share/examples/vym/lifeforms.vym
-share/examples/vym/math.vym
-share/examples/vym/time-management.vym
-share/examples/vym/vym-contribute.vym
-share/vym/
-share/vym/flags/
-share/vym/flags/attach.png
-share/vym/flags/back.png
-share/vym/flags/bell.png
-share/vym/flags/bookmark.png
-share/vym/flags/clanbomber.png
-share/vym/flags/desktopnew.png
-share/vym/flags/flag-2arrow-down.png
-share/vym/flags/flag-2arrow-up.png
-share/vym/flags/flag-arrow-down.png
-share/vym/flags/flag-arrow-up.png
-share/vym/flags/flag-clock.png
-share/vym/flags/flag-cross-red.png
-share/vym/flags/flag-exclamationmark.png
-share/vym/flags/flag-flash.png
-share/vym/flags/flag-heart.png
-share/vym/flags/flag-hideexport.png
-share/vym/flags/flag-hook-green.png
-share/vym/flags/flag-info.png
-share/vym/flags/flag-lamp

Re: update audio/cozy

2023-05-07 Thread Solène Rapenne
Le Sun, 7 May 2023 17:26:19 +0200,
Stefan Hagen  a écrit :

> Solène Rapenne wrote (2023-05-07 15:39 CEST):
>  [...]  
> 
> I think you forgot to cvs add the patch :-)
> I'm seeing:
> 
> $ cozy
> ['/usr/local/bin/cozy']
> 17:23:13 [MainThread  ] [applicatio] [INFO ]  ('openbsd', '7.3', '')
> 17:23:13 [MainThread  ] [applicatio] [INFO ]  Starting up cozy 1.2.1
> 17:23:13 [MainThread  ] [db] [INFO ]  SQLite version: 3.41.2
> 17:23:13 [Thread-1 (ru] [peewee.sql] [INFO ]  writer received shutdown 
> request, exiting.
> 17:23:13 [MainThread  ] [applicatio] [INFO ]  libhandy version: 1
> handle exception
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.10/site-packages/cozy/application.py", line 
> 99, in do_activate
> self.app_controller = AppController(self, main_window_builder, self.ui)
>   File 
> "/usr/local/lib/python3.10/site-packages/cozy/architecture/singleton.py", 
> line 5, in __call__
> cls._instances[cls] = super(Singleton, cls).__call__(*args, **kwargs)
>   File "/usr/local/lib/python3.10/site-packages/cozy/app_controller.py", line 
> 52, in __init__
> self.whats_new_window: WhatsNewWindow = WhatsNewWindow()
>   File 
> "/usr/local/lib/python3.10/site-packages/cozy/ui/widgets/whats_new_window.py",
>  line 36, in __init__
> self._fill_window()
>   File 
> "/usr/local/lib/python3.10/site-packages/cozy/ui/widgets/whats_new_window.py",
>  line 54, in _fill_window
> last_launched_version = 
> version.parse(self.app_settings.last_launched_version)
>   File "/usr/local/lib/python3.10/site-packages/packaging/version.py", line 
> 52, in parse
> return Version(version)
>   File "/usr/local/lib/python3.10/site-packages/packaging/version.py", line 
> 197, in __init__
> raise InvalidVersion(f"Invalid version: '{version}'")
> packaging.version.InvalidVersion: Invalid version: 'None'
> 
> Best Regards,
> Stefan
> 
>  [...]  
> 

thanks for the -N flag for cvs diff :)

Index: Makefile
===
RCS file: /home/cvs/ports/audio/cozy/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile24 Apr 2023 11:40:34 -  1.4
+++ Makefile7 May 2023 13:28:19 -
@@ -2,8 +2,7 @@ COMMENT =   gtk3 audiobook player
 
 GH_ACCOUNT =   geigi
 GH_PROJECT =   cozy
-GH_TAGNAME =   1.1.2
-REVISION = 1
+GH_TAGNAME =   1.2.1
 
 CATEGORIES =   audio
 
@@ -18,7 +17,6 @@ MODULES = devel/dconf \
 
 COMMON_DEPENDS =   audio/py-mutagen${MODPY_FLAVOR} \
 databases/py-peewee${MODPY_FLAVOR} \
-   devel/py-gobject3${MODPY_FLAVOR} \
sysutils/py-distro${MODPY_FLAVOR} \
x11/elementary/granite \
x11/libhandy
@@ -28,9 +26,15 @@ BUILD_DEPENDS =  ${COMMON_DEPENDS} \
 
 RUN_DEPENDS =  ${COMMON_DEPENDS} \
devel/desktop-file-utils \
+   devel/py-tz${MODPY_FLAVOR} \
multimedia/gstreamer1/plugins-libav \
+   www/py-requests${MODPY_FLAVOR} \
x11/gnome/libdazzle \
x11/gtk+4,-guic
+
+# required for running tests
+# one failing test due to missing network
+PORTHOME=  ${WRKDIR}
 
 post-install:
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py ${PREFIX}
Index: distinfo
===
RCS file: /home/cvs/ports/audio/cozy/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo8 Dec 2021 20:34:13 -   1.1.1.1
+++ distinfo7 May 2023 13:01:16 -
@@ -1,2 +1,2 @@
-SHA256 (cozy-1.1.2.tar.gz) = BBIK0XIWURsesb2zzfsLYa0VsyTUeK+sRkYWKLo0Vw4=
-SIZE (cozy-1.1.2.tar.gz) = 812775
+SHA256 (cozy-1.2.1.tar.gz) = VSLdPiqop1R4UVxK4pnnH6MqkZcDzEpTL7p5c2PMWEQ=
+SIZE (cozy-1.2.1.tar.gz) = 831167
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/audio/cozy/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST   11 Mar 2022 18:20:07 -  1.2
+++ pkg/PLIST   7 May 2023 13:03:18 -
@@ -53,6 +53,7 @@ ${MODPY_COMMENT}lib/python${MODPY_VERSIO
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}artwork_cache.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}book.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}collation.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/c

Re: meta/xfce README change

2023-05-07 Thread Solène Rapenne
Le Sun,  7 May 2023 15:39:17 +,
Klemens Nanni  a écrit :

> On Sun, May 07, 2023 at 05:34:42PM +0200, Solene Rapenne wrote:
>  [...]  
> 
> If that works out of the box...
> 
>  [...]  
> 
> ... you could also say something like
> 
> If you want to use gdm, install it and select xfce in the menu, bla bla.
> 
> Would such a specific hint be more helpful than leaving users figure out
> gdm/xfce interaction on their own?
> 
>  [...]  

Nowadays, I'd expect any desktop environment to be available in GDM
without having to create an according .desktop file

I'm fine replacing the comment by what you suggest, but I don't think
it's useful.



meta/xfce README change

2023-05-07 Thread Solène Rapenne
if you have gdm and xfce4 installed, gdm offers xfce out of the box.

The package xfce4-session provides the magic file that make it work in
/usr/local/share/xsessions/xfce.desktop

Index: Makefile
===
RCS file: /home/cvs/ports/meta/xfce/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- Makefile16 Apr 2023 18:29:39 -  1.30
+++ Makefile7 May 2023 15:31:25 -
@@ -7,7 +7,7 @@
 PKGNAME-main = xfce-${V}
 PKGNAME-extras =   xfce-extras-${V}
 REVISION-extras =  3
-REVISION-main =3
+REVISION-main =4
 
 MAINTAINER =   Landry Breuil 
 
Index: pkg/README-main
===
RCS file: /home/cvs/ports/meta/xfce/pkg/README-main,v
retrieving revision 1.20
diff -u -r1.20 README-main
--- pkg/README-main 24 Dec 2022 20:49:58 -  1.20
+++ pkg/README-main 7 May 2023 15:31:20 -
@@ -12,9 +12,6 @@
 Simply add '${LOCALBASE}/bin/startxfce4' to your .xinitrc .xsession
 script if you use startx(1) or xenodm(1), respectively.
 
-If you use gdm, have a look at https://wiki.xfce.org/faq#starting_xfce
-which provides an xfce4.desktop for it.
-
 Logging out and shutting down the computer
 ==
 If your installation supports complete shutdown, clicking on the logout



update productivity/vym

2023-05-07 Thread Solène Rapenne
I updated vym to latest version, a lot of changes, it moved to GitHub
and from gmake to cmake, which simplify the port

it works fine for me, I needed to add a patch to fix unzip/zip binaries
path because it's hardcoded.

However, all the icons are installed in /usr/local/share/icons/ which
seems wrong (and portcheck reports it), but I don't know how to change
the path here, a little help would be appreciated :)

Index: Makefile
===
RCS file: /home/cvs/ports/productivity/vym/Makefile,v
retrieving revision 1.33
diff -u -r1.33 Makefile
--- Makefile3 Oct 2022 21:18:19 -   1.33
+++ Makefile7 May 2023 15:00:48 -
@@ -1,55 +1,35 @@
 COMMENT=   generate and manipulate maps of your thoughts
 
-DISTNAME=  vym-2.6.0
+VERSION =  2.9.0
+GH_ACCOUNT =   insilmaril
+GH_PROJECT =   vym
+GH_TAGNAME =   v${VERSION}
+DISTNAME=  vym-${VERSION}
 CATEGORIES=productivity x11
-REVISION=  3
 
 HOMEPAGE=  https://www.insilmaril.de/vym/
 
 # modified GPLv2
 PERMIT_PACKAGE=Yes
 
-MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=vym/}
-EXTRACT_SUFX=  .tar.bz2
-
-WANTLIB += GL Qt5Core Qt5DBus Qt5Gui Qt5Network Qt5PrintSupport
-WANTLIB += Qt5Svg Qt5Widgets Qt5Xml c m pthread
+WANTLIB += Qt5Core Qt5DBus Qt5Gui Qt5Network Qt5PrintSupport
+WANTLIB += Qt5Script Qt5Svg Qt5Widgets Qt5Xml c m pthread
 WANTLIB += ${COMPILER_LIBCXX}
 
-MODULES=   devel/qmake \
+MODULES=   devel/cmake \
x11/qt5
-MODQMAKE_ARGS= DEFINES+=VYM_DOCDIR=\\\"${PREFIX}/share/doc/vym\\\"
 
 RUN_DEPENDS=   archivers/zip \
archivers/unzip \
-   textproc/libxslt
+   devel/desktop-file-utils \
+   misc/shared-mime-info \
+   textproc/libxslt \
+   x11/gtk+4,-guic
 
-LIB_DEPENDS=   x11/qt5/qtsvg
+LIB_DEPENDS=   x11/qt5/qtscript \
+   x11/qt5/qtsvg
 
-PORTHOME=  ${WRKDIR}
+#PORTHOME= ${WRKDIR}
 NO_TEST=   Yes
-
-SHARE_DIRS=flags flags/freemind icons scripts styles
-
-pre-configure:
-   @echo "QMAKE_CXXFLAGS_RELEASE=${CXXFLAGS}" \
-   >> ${WRKSRC}/vym.pro
-   ${SUBST_CMD} ${WRKSRC}/mainwindow.cpp ${WRKSRC}/main.cpp
-
-do-install:
-   ${INSTALL_PROGRAM} ${WRKBUILD}/vym ${PREFIX}/bin
-   ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/vym/
-   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/vym/
-   ${INSTALL_DATA} ${WRKSRC}/doc/*.pdf ${PREFIX}/share/doc/vym/
-   ${INSTALL_DATA} ${WRKSRC}/demos/* ${PREFIX}/share/examples/vym/
-.for i in ${SHARE_DIRS}
-   ${INSTALL_DATA_DIR} ${PREFIX}/share/vym/${i}
-   find ${WRKSRC}/${i}/ -type f -exec \
-   ${INSTALL_DATA} {} ${PREFIX}/share/vym/${i} \;
-.endfor
-   ${INSTALL_DATA} ${WRKSRC}/doc/vym.1.gz ${PREFIX}/man/man1
-   gunzip -f ${PREFIX}/man/man1/vym.1.gz
-   sed -i 's,/usr/share/doc/packages,${TRUEPREFIX}/share/doc,' \
-   ${PREFIX}/man/man1/vym.1
 
 .include 
Index: distinfo
===
RCS file: /home/cvs/ports/productivity/vym/distinfo,v
retrieving revision 1.9
diff -u -r1.9 distinfo
--- distinfo29 Apr 2018 08:13:07 -  1.9
+++ distinfo7 May 2023 13:17:59 -
@@ -1,2 +1,2 @@
-SHA256 (vym-2.6.0.tar.bz2) = fcFyGvsnEJrcS0rqrGIX/dEpSzjoGzOgikdlYvvfoUE=
-SIZE (vym-2.6.0.tar.bz2) = 6766806
+SHA256 (vym-2.9.0.tar.gz) = ckUWgaOk4UlPJcH/nUEQwTgJXWPtTRRxx27ZB2BqfNs=
+SIZE (vym-2.9.0.tar.gz) = 8594682
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/productivity/vym/pkg/PLIST,v
retrieving revision 1.8
diff -u -r1.8 PLIST
--- pkg/PLIST   11 Mar 2022 19:51:48 -  1.8
+++ pkg/PLIST   7 May 2023 14:02:43 -
@@ -1,211 +1,243 @@
 @bin bin/vym
-@man man/man1/vym.1
-share/doc/vym/
-share/doc/vym/vym.pdf
-share/doc/vym/vym_es.pdf
-share/doc/vym/vym_fr.pdf
-share/examples/vym/
-share/examples/vym/ao-report-example.vym
-share/examples/vym/frames.vym
-share/examples/vym/lifeforms.vym
-share/examples/vym/math.vym
-share/examples/vym/time-management.vym
-share/examples/vym/vym-contribute.vym
-share/vym/
-share/vym/flags/
-share/vym/flags/attach.png
-share/vym/flags/back.png
-share/vym/flags/bell.png
-share/vym/flags/bookmark.png
-share/vym/flags/clanbomber.png
-share/vym/flags/desktopnew.png
-share/vym/flags/flag-2arrow-down.png
-share/vym/flags/flag-2arrow-up.png
-share/vym/flags/flag-arrow-down.png
-share/vym/flags/flag-arrow-up.png
-share/vym/flags/flag-clock.png
-share/vym/flags/flag-cross-red.png
-share/vym/flags/flag-exclamationmark.png
-share/vym/flags/flag-flash.png
-share/vym/flags/flag-heart.png
-share/vym/flags/flag-hideexport.png
-share/vym/flags/flag-hook-green.png
-share/vym/flags/flag-info.png
-share/vym/flags/flag-lamp.png
-share/vym/flags/flag-lifebelt.png
-share/vym/flags/flag-note.png
-share/vym/flags/flag-phone.png
-share/vym/flags/flag-present.png

update audio/cozy

2023-05-07 Thread Solène Rapenne
this updates cozy to latest version

pygobject isn't required anymore, a few other python are now required
for runtime. I included a patch that isn't merged in upstream yet, but
without it you can't start cozy at all, except if you want to have to
set 2 variables in your gsettings

Index: Makefile
===
RCS file: /home/cvs/ports/audio/cozy/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile24 Apr 2023 11:40:34 -  1.4
+++ Makefile7 May 2023 13:28:19 -
@@ -2,8 +2,7 @@
 
 GH_ACCOUNT =   geigi
 GH_PROJECT =   cozy
-GH_TAGNAME =   1.1.2
-REVISION = 1
+GH_TAGNAME =   1.2.1
 
 CATEGORIES =   audio
 
@@ -18,7 +17,6 @@
 
 COMMON_DEPENDS =   audio/py-mutagen${MODPY_FLAVOR} \
 databases/py-peewee${MODPY_FLAVOR} \
-   devel/py-gobject3${MODPY_FLAVOR} \
sysutils/py-distro${MODPY_FLAVOR} \
x11/elementary/granite \
x11/libhandy
@@ -28,9 +26,15 @@
 
 RUN_DEPENDS =  ${COMMON_DEPENDS} \
devel/desktop-file-utils \
+   devel/py-tz${MODPY_FLAVOR} \
multimedia/gstreamer1/plugins-libav \
+   www/py-requests${MODPY_FLAVOR} \
x11/gnome/libdazzle \
x11/gtk+4,-guic
+
+# required for running tests
+# one failing test due to missing network
+PORTHOME=  ${WRKDIR}
 
 post-install:
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py ${PREFIX}
Index: distinfo
===
RCS file: /home/cvs/ports/audio/cozy/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- distinfo8 Dec 2021 20:34:13 -   1.1.1.1
+++ distinfo7 May 2023 13:01:16 -
@@ -1,2 +1,2 @@
-SHA256 (cozy-1.1.2.tar.gz) = BBIK0XIWURsesb2zzfsLYa0VsyTUeK+sRkYWKLo0Vw4=
-SIZE (cozy-1.1.2.tar.gz) = 812775
+SHA256 (cozy-1.2.1.tar.gz) = VSLdPiqop1R4UVxK4pnnH6MqkZcDzEpTL7p5c2PMWEQ=
+SIZE (cozy-1.2.1.tar.gz) = 831167
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/audio/cozy/pkg/PLIST,v
retrieving revision 1.2
diff -u -r1.2 PLIST
--- pkg/PLIST   11 Mar 2022 18:20:07 -  1.2
+++ pkg/PLIST   7 May 2023 13:03:18 -
@@ -53,6 +53,7 @@
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}artwork_cache.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}book.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}collation.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}file.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}model_base.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}offline_cache.${MODPY_PYC_MAGIC_TAG}pyc
@@ -63,6 +64,7 @@
 
lib/python${MODPY_VERSION}/site-packages/cozy/db/${MODPY_PYCACHE}track_to_file.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/cozy/db/artwork_cache.py
 lib/python${MODPY_VERSION}/site-packages/cozy/db/book.py
+lib/python${MODPY_VERSION}/site-packages/cozy/db/collation.py
 lib/python${MODPY_VERSION}/site-packages/cozy/db/file.py
 lib/python${MODPY_VERSION}/site-packages/cozy/db/model_base.py
 lib/python${MODPY_VERSION}/site-packages/cozy/db/offline_cache.py
@@ -122,7 +124,6 @@
 
lib/python${MODPY_VERSION}/site-packages/cozy/model/${MODPY_PYCACHE}settings.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/model/${MODPY_PYCACHE}single_file_chapter.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/model/${MODPY_PYCACHE}storage.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/cozy/model/${MODPY_PYCACHE}storage_block_list.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/cozy/model/${MODPY_PYCACHE}track.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/cozy/model/book.py
 lib/python${MODPY_VERSION}/site-packages/cozy/model/chapter.py
@@ -131,7 +132,6 @@
 lib/python${MODPY_VERSION}/site-packages/cozy/model/settings.py
 lib/python${MODPY_VERSION}/site-packages/cozy/model/single_file_chapter.py
 lib/python${MODPY_VERSION}/site-packages/cozy/model/storage.py
-lib/python${MODPY_VERSION}/site-packages/cozy/model/storage_block_list.py
 lib/python${MODPY_VERSION}/site-packages/cozy/model/track.py
 lib/python${MODPY_VERSION}/site-packages/cozy/open_view.py
 lib/python${MODPY_VERSION}/site-packages/cozy/power_manager.py
@@ -167,8 +167,8 @@
 
lib/python${MODPY_VERSION}/site-packages/cozy/ui/${MODPY_PYCACHE}media_controller.${MODPY_PYC_MAGIC_TAG}pyc
 

Re: CVS: cvs.openbsd.org: ports

2023-04-13 Thread Solène Rapenne
Le Wed, 12 Apr 2023 12:51:57 -0600 (MDT),
Landry Breuil  a écrit :

> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   lan...@cvs.openbsd.org  2023/04/12 12:51:57
> 
> Modified files:
>   www/nextcloud/24: Tag: OPENBSD_7_3 Makefile distinfo 
>   www/nextcloud/24/pkg: Tag: OPENBSD_7_3 PLIST 
> 
> Log message:
> www/nextcloud/24: MFC update to 24.0.11.
> 
> see https://nextcloud.com/changelog/#latest24
> discussed with & ok gonzalo@ (MAINTAINER)
> 

fails on -stable

===>  Building package for nextcloud-24.0.11 
Create /home/packages/amd64/all/nextcloud-24.0.11.tgz   
   
Creating package nextcloud-24.0.11   
Error: change in plist 
| Assuming the old and new builds were done correctly
| (fully up-to-date ports tree including relevant MODULES),  
| then someone probably forgot to bump a REVISION.   
| (see bsd.port.mk(5), PACKAGE_REPOSITORY)  
   
|
| Note that registered plist doesn't have @version info 
   
| So we can't know anything about @version bumps  



Re: gtk+4 slow application startup

2023-02-22 Thread Solène Rapenne
Le Tue, 21 Feb 2023 12:15:31 +0100,
Antoine Jacoutot  a écrit :

> On Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray wrote:
> > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote:  
> > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote:  
> > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote:  
> > > > > Hi.
> > > > > 
> > > > > There seems to be a regression with mesa that makes gtk+4 application 
> > > > > very slow
> > > > > to start.
> > > > > By default the GSK renderer uses OpenGL.
> > > > > As a workaround, you can temporarily use this to go back to the cairo 
> > > > > renderer
> > > > > which makes gtk+4 applications fast again:
> > > > > 
> > > > > export GSK_RENDERER=cairo  
> > > > 
> > > > What hardware is this on?  Is there a Mesa or gtk bug for it?  
> > > 
> > > See dmesg below.
> > >   
> > > > When did this behaviour start?  Before the gtk update that recently
> > > > went in? Does it occur with GSK_RENDERER=vulkan?
> > > > GSK_RENDERER described in
> > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer  
> > > 
> > > It did not happen on my previous amd ryzen.
> > > As soon as I switched to the new intel laptop, I was that bug (exact same
> > > installation, I rsync'd everything).
> > > 
> > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is buggy 
> > > (not
> > > built by default) and segfaults on a regular basis.
> > >   
> > > > There is
> > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113
> > > > which briefly touches on shader cache.  We disable the shader
> > > > cache to be able to uses pledge(2).  
> > > 
> > > Yes, that is the bug I was looking into.  
> > 
> > Here is a xenocara diff to enable the shader cache.
> > It is created in ~/.cache/mesa_shader_cache/
> > 
> > On an Intel system (x250 with Broadwell) launching gtk4-demo results in
> > a 1.6M cache.  The time to a window appearing is noticeably shorter
> > running it again after that.
> > 
> > The various firefox and chromium ports will need to change
> > unveil/pledge policies to use it.  Chromium at least still runs but
> > there are multiple warnings that directories can't be created.  
> 
> Wow, that makes a crazy improvement!
> Running a full blown GNOME right now and I can definitely tell the difference.
> Thanks :-)
> 
> 
> > Index: lib/mesa/src/util/disk_cache.c
> > ===
> > RCS file: /cvs/xenocara/lib/mesa/src/util/disk_cache.c,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 disk_cache.c
> > --- lib/mesa/src/util/disk_cache.c  28 Jan 2023 08:56:53 -  1.13
> > +++ lib/mesa/src/util/disk_cache.c  20 Feb 2023 12:42:45 -
> > @@ -80,11 +80,6 @@ disk_cache_create(const char *gpu_name, 
> > uint8_t cache_version = CACHE_VERSION;
> > size_t cv_size = sizeof(cache_version);
> >  
> > -#ifdef __OpenBSD__
> > -   /* default to no disk shader cache to avoid pledge violations in 
> > chromium */
> > -  return NULL;
> > -#endif
> > -
> > if (!disk_cache_enabled())
> >return NULL;
> >  
> >   
> 

+1, with this diff, it's day and night when using GNOME



Re: stable versus snapshots

2023-02-14 Thread Solène Rapenne
Le Tue, 14 Feb 2023 06:25:02 +,
Tiemen Werkman  a écrit :

> Hey all,
> 
> Which OpenBSD release version am I supposed to use?
> I have just started learning to update a port. I simply started all the
> work on the stable release(7.2) and submitted the update. Only now did
> it occur to me that there is of course also snapshots. Does this matter?
> 
> Second question:
> New packages are not made available for older releases. However updates
> for some packages are available. Are all updates to packages made
> available to the supported stable release or do some package updates
> have to wait for the next release?
> 
> Tiemen Werkman

The binary packages of the last stable release are only receiving
security updates, or fixes to unbreak a program (mostly only after the
release is out).

They are provided on the mirrors, so you just have to use pkg_add -u to
keep your packages up to date, and sysupdate to keep the base system up
to date.



Re: Port for Mini vMac?

2022-11-21 Thread Solène Rapenne
Le Mon, 21 Nov 2022 12:03:10 -0500,
Jag Talon  a écrit :

> Hello,
> 
> I was wondering if anyone has worked on a port for Mini vMac emulator?
> I got it to compile on 7.2 (i386), but I don't think I have the
> technical skills or the energy at the moment to be a maintainer.
> 
> I'm also new to OpenBSD so I think I'll be a poor porter as well, but if
> anyone is interested in it I can at least collaborate and share
> the changes with you!
> 

we have emulators/gsplus, is this different?

https://apple2.gs/plus/



Re: gopass outdated

2022-11-14 Thread Solène Rapenne
Le Mon, 14 Nov 2022 10:41:58 +,
Krassy Boykinov  a écrit :

> Dear maintainer,
> 
> i want to kindly inform you, that as of now
> the gopass package is outdated. Currently
> the packaged version is v1.13.0 and the latest
> available release is v1.14.10.
> 
> Thank you for your effort and best regards,
> 
> Krassy Boykinov
> 

Thanks for the heads up

If you rely on it, could you try to update it and send us the patch?
This may sound a lot of work, but if everything goes fine (and this
happen sometimes!), it's not much more work than bumping the version,
updating the distfiles, ensure pkg/PLIST is fine with "make
update-plist" and send the diff if the result works for you

You can find information in https://www.openbsd.org/faq/ports/ if you
want to learn more about the porting / packaging processes



Re: [new] editors/helix version 22.08.1

2022-11-06 Thread Solène Rapenne
Le Tue, 1 Nov 2022 17:50:38 - (UTC),
Laurent Cheylus  a écrit :

> Hi,
> 
> On Mon, 31 Oct 2022 19:47:31 +0100, Solène Rapenne wrote:
> 
> > the ports looks in good shape and works fine, including LSP support
> > which I tested with gopls and clangd.  
> 
> Thanks Solene for your review of my port.
>  
> > in pkg/DESCR, delete "written in Rust" because this brings nothing
> > useful, and wrap the long line
> > 
> > remove "post-modern" in the COMMENT, that's not useful
> > 
> > please add ${WRKSRC}/languages.toml into ${PREFIX}/share/helix,
> > regenerate PLIST after this. this file is useful to use it as a
> > reference for local tweaks.
> > 
> > with theses changes, it's ok solene@ for import  
> 
> OK for the changes requested, see my diff below.
> 
> Laurent
> 
> diff --git a/editors/helix/Makefile b/editors/helix/Makefile
> index b0e36f063..adc20f67b 100644
> --- a/editors/helix/Makefile
> +++ b/editors/helix/Makefile
> @@ -1,4 +1,4 @@
> -COMMENT =post-modern modal text editor
> +COMMENT =modal text editor
> 
>  VER =22.08.1
>  DISTNAME =   helix-${VER}
> @@ -51,7 +51,8 @@ do-install:
>   cp -a {} ${PREFIX}/share/helix/runtime/grammars \;
> 
>   ${INSTALL_DATA} ${WRKSRC}/runtime/tutor.txt \
> - ${PREFIX}/share/helix/runtime/tutor.txt
> + ${PREFIX}/share/helix/runtime
> + ${INSTALL_DATA} ${WRKSRC}/languages.toml ${PREFIX}/share/helix
> 
>  .include "crates.inc"
> 
> diff --git a/editors/helix/pkg/DESCR b/editors/helix/pkg/DESCR
> index f267ea457..0baab06c5 100644
> --- a/editors/helix/pkg/DESCR
> +++ b/editors/helix/pkg/DESCR
> @@ -1,7 +1,8 @@
> -A Kakoune / Neovim inspired editor, written in Rust.
> +A Kakoune / Neovim inspired text editor.
> 
>  Features:
>- Vim-like modal editing
>- Multiple selections
>- Built-in language server support
> -  - Smart, incremental syntax highlighting and code editing via tree-sitter
> +  - Smart, incremental syntax highlighting and code editing
> +  via tree-sitter
> diff --git a/editors/helix/pkg/PLIST b/editors/helix/pkg/PLIST
> index bea09c806..2ab38cefd 100644
> --- a/editors/helix/pkg/PLIST
> +++ b/editors/helix/pkg/PLIST
> @@ -1,5 +1,6 @@
>  @bin bin/hx
>  share/helix/
> +share/helix/languages.toml
>  share/helix/runtime/
>  share/helix/runtime/grammars/
>  @so share/helix/runtime/grammars/awk.so
> 

looks fine to me, but could you provide a tarball of the latest version?
It's easier for people to review :) otherwise they need to find a tarball
and look for all the thread to look for pathces, which isn't ideal



Re: NEW: www/profile-sync-daemon

2022-11-04 Thread Solène Rapenne
Le Fri, 4 Nov 2022 16:20:22 -0400,
Morgan Aldridge  a écrit :

> Attached is a port for profile-sync-daemon[0], which is a bash script
> to synchronize web browser profiles to/from a ramdisk with the goal of
> reducing HDD/SDD wear and providing backup functionality. Tested on
> amd64. Additional details can be found on the ArchWiki page[1].
> 
> Naturally, one needs to have enough extra RAM available and move /tmp
> to a ramdisk (as solene@ has documented[2] on her blog). For this
> reason, while I tried to not be too verbose and direct users to
> appropriate manual pages for specifics, there are a number of
> considerations & configuration steps described in the pkg-readme. I'm
> happy to make it more concise.
> 
> I have a couple of upstream issues[3][4] open where I hope to get
> portions of the changes merged in to reduce OpenBSD-specific patches.
> 
> [0] - 
> [1] - 
> [2] - 
> [3] - 
> [4] - 
> 
> Morgan

hi, you may want to look at this, basically restoring/saving a MFS
using 20 lines of shell in a rc file.
I'm not really sure we need a port for this.

https://dataswamp.org/~solene/2021-12-15-openbsd-mfs-persistency.html



Re: [new] editors/helix version 22.08.1

2022-10-31 Thread Solène Rapenne
Le Mon, 31 Oct 2022 10:07:04 +0100,
Laurent Cheylus  a écrit :

> Hi,
> 
> this is a port for Helix (text editor) https://helix-editor.com
> 
> Features:
>- Vim-like modal editing
>- Multiple selections
>- Built-in language server support
>- Smart, incremental syntax highlighting and code editing via 
> tree-sitter
> 
> It's my first port for a Rust tool. Tested on amd64, works fine.
> 
> - Makefile defines MASTER_SITES to download helix-22.08.1-source.tar.xz 
> : full sources (Helix + TreeSitter grammars)
> - Special case with EXTRACT_CASES to decompress sources in WRKDIST
> 
> - Patches (derived from those of the FreeBSD port 
> https://github.com/freebsd/freebsd-ports/tree/main/editors/helix/)
>* patch-helix-term_build_rs: remove Git hash in internal version
>* patch-helix-loader_src_lib_rs: define path for data directory 
> (${PREFIX}/share/helix)
>* patch-helix-loader_src_grammar_rs: disable internal command 'hx 
> --grammar fetch' to fetch TreeSitter grammar with Git
> 
> - Install tutor.txt, themes, queries and grammars (.so files built from 
> TreeSitter sources) in ${PREFIX}/share/helix/runtime
> 
> 
> Port also available on GH openbsd-wip 
> https://github.com/jasperla/openbsd-wip/tree/master/editors/helix
> 
> 
> comments welcome, Laurent

the ports looks in good shape and works fine, including LSP support
which I tested with gopls and clangd.

in pkg/DESCR, delete "written in Rust" because this brings
nothing useful, and wrap the long line

remove "post-modern" in the COMMENT, that's not useful

please add ${WRKSRC}/languages.toml into ${PREFIX}/share/helix,
regenerate PLIST after this. this file is useful to use it as a
reference for local tweaks.

with theses changes, it's ok solene@ for import



update sysutils/obsdfreqd

2022-10-31 Thread Solène Rapenne
I made a new release of obsdfreqd. The temperature mode is now trying
to detect a CPU temperature sensor instead of using the first sensor
found, or you can give it a specific temperature sensor to use.

Improvement by Vlad Meşco

diff --git a/sysutils/obsdfreqd/Makefile b/sysutils/obsdfreqd/Makefile
index 9c1de2641d2..4d823cb6632 100644
--- a/sysutils/obsdfreqd/Makefile
+++ b/sysutils/obsdfreqd/Makefile
@@ -1,7 +1,6 @@
 COMMENT =  userland daemon to manage CPU frequency
-V =1.0.3
+V =1.1.0
 DISTNAME = obsdfreqd-${V}
-REVISION = 0
 
 CATEGORIES =   sysutils
 
diff --git a/sysutils/obsdfreqd/distinfo b/sysutils/obsdfreqd/distinfo
index 73e89d4b8ba..e77741dba2f 100644
--- a/sysutils/obsdfreqd/distinfo
+++ b/sysutils/obsdfreqd/distinfo
@@ -1,2 +1,2 @@
-SHA256 (obsdfreqd-1.0.3.tar.gz) = la7GN2AE2ZRZXdWLBOf7f4VXlljJze6mPQULfJEOW+M=
-SIZE (obsdfreqd-1.0.3.tar.gz) = 6338
+SHA256 (obsdfreqd-1.1.0.tar.gz) = GueIAUG4GnBT22X5St6v0yKJ1ow5G5crLyPYEw77sFA=
+SIZE (obsdfreqd-1.1.0.tar.gz) = 8745



Re: [new] shells/nushell - about c++abi in Rust port

2022-10-30 Thread Solène Rapenne
Le Sun, 30 Oct 2022 06:58:04 +0100,
Sebastien Marie  a écrit :

> On Sat, Oct 29, 2022 at 11:35:26PM +0200, Theo Buehler wrote:
> > > with ${COMPILER_LIBCXX}, make port-lib-depends-check complains about an
> > > extra "c++", another rust port I looked at have c++abi, adding it make
> > > port-lib-depends-check happy (in addition to other libs used)  
> > 
> > I guess that's fine then.
> >   
> 
> I should look at it to solve that in a sane way, and have it managed at cargo 
> module level.
> 
> From my current understanding of the code, on amd64, c++abi is required as it 
> provides the LLVM "libunwind" part. It is the case for all RUST_ARCHS except 
> sparc64 (where the unwinding code comes from libgcc which is static library).
> 
> For now, I think that on sparc64 it doesn't hurt to have c++abi in WANTLIB, 
> even 
> if it isn't strictly required. I will try to look at it.
> 
> Please note that if the rust port uses C++, it will need ${COMPILER_LIBCXX}.

new version, it compiled finein a clean chroot (1800 seconds on a i5-46xx)

- Git isn't required for building/running it
- no need to use --workspace
- there are no plugins / other binaries provided in the sources, the
  things listed with --workspace are the builtins commands and shouldn't
  exist as standalone binaries
- it doesn't seem to be using C++ (but WANTLIB requires c++abi ?)
- make port-lib-depends-check is happy on amd64


if you want to experiment with it, here are a few snippets to play with on 
OpenBSD

open /etc/fstab | from ssv -m 1 -n
open /etc/fstab | from ssv -m 1 -n | rename device mountpoint fs options freq 
passno
open /etc/fstab | from ssv -m 1 -n | rename device mountpoint fs options freq 
passno | where fs != "ffs"
open /etc/fstab | from ssv -m 1 -n | rename device mountpoint fs options freq 
passno | to yaml

pkg_info | str trim |  parse -r "(?.*?)-(?[a-zA-Z0-9\\.]*?) 
(?.*)"  | str trim description
pkg_info | str trim |  parse -r "(?.*?)-(?[a-zA-Z0-9\\.]*?) 
(?.*)"  | str trim description | to json

ls /usr/ports/**/Makefile | sort-by modified | last 10

help commands
help commands | find uniq
help commands | sort-by category
help commands | where category == network
help where
help sort-by


nushell.tgz
Description: application/compressed-tar


Re: [new] shells/nushell

2022-10-29 Thread Solène Rapenne
Le Sat, 29 Oct 2022 21:02:54 +0200,
Theo Buehler  a écrit :

> On Sat, Oct 29, 2022 at 07:07:52PM +0200, Solène Rapenne wrote:
> > hi,
> > 
> > this is a port for the shell nushell (non POSIX)
> > 
> > - https://www.nushell.sh/
> > 
> > It's my first Rust port, I took example from other, especially for the
> > line MODCARGO_CRATES_UPDATE
> > 
> > tested on amd64, works fine  
> 
> I've only given it a quick look. At least devel/libgit2/libgit2 should
> be added as an LDEP.

indeed, I added it in the new tarball

> All rust binaries link against c++abi and pthread, you'll want at least
> 
> WANTLIB +=  ${COMPILER_LIBCXX} crypto m pthread ssl

with ${COMPILER_LIBCXX}, make port-lib-depends-check complains about an
extra "c++", another rust port I looked at have c++abi, adding it make
port-lib-depends-check happy (in addition to other libs used)

> in addition to what you have.
> 
> Under ${WRKBUILD}/target/release there are a few binaries (plugins) and
> libraries that you will probably want to install as well.

I couldn't find them, I took a look in the subdirectories but nothing
seemed useful there. Maybe I should let cargo do the "do-install" step?
I skipped this because it was very long and I originally only wanted
the shell binary.

solene@fx6 nushell 2$ ls -l 
/build/pobj/nushell-0.70.0/build-amd64/target/release/
total 59492
drwxr-xr-x  122 _pbuild  _pbuild  4608 Oct 29 21:34 build
drwxr-xr-x2 _pbuild  _pbuild 45568 Oct 29 22:24 deps
drwxr-xr-x2 _pbuild  _pbuild   512 Oct 29 21:34 examples
drwxr-xr-x2 _pbuild  _pbuild   512 Oct 29 21:34 incremental
-rwxr-xr-x2 _pbuild  _pbuild  30361008 Oct 29 22:24 nu
-rw-r--r--1 _pbuild  _pbuild 42982 Oct 29 22:24 nu.d
 
> 'make port-lib-depends-check'
> 
> will then help getting WANTLIB and dependencies right.

oh right, I forgot about it, I became a bit... Rusty =D


nushell.tgz
Description: application/compressed-tar


[new] shells/nushell

2022-10-29 Thread Solène Rapenne
hi,

this is a port for the shell nushell (non POSIX)

- https://www.nushell.sh/

It's my first Rust port, I took example from other, especially for the
line MODCARGO_CRATES_UPDATE

tested on amd64, works fine


nushell.tgz
Description: application/compressed-tar


Re: [update] collectd 5.12

2022-10-21 Thread Solène Rapenne
Le Thu, 20 Oct 2022 16:27:20 +0200,
Landry Breuil  a écrit :

> Hi,
> 
> here's an update to collectd 5.12, cf
> https://github.com/collectd/collectd/blob/main/ChangeLog for changelog.
> 
> apparently upstream went on a v6 branch to break the ABI
> (https://github.com/orgs/collectd/projects/1) but not
> everyone is liking it, cf
> https://github.com/collectd/collectd/issues/4048 - so the v5 branch isnt
> maintained that much, but we're still lagging behind many releases
> anyway :)
> 
> builds fine, totally untested. Feedback welcome !
> 
> Landry

as I made a change meanwhile, I'm joining the update diff for the bump

However with this new version, it fails to start

Oct 21 23:42:07 t400 collectd[26742]: fopen (/var/collectd.pid): Permission 
denied

Index: Makefile
===
RCS file: /cvs/ports/sysutils/collectd/Makefile,v
retrieving revision 1.72
diff -u -p -r1.72 Makefile
--- Makefile21 Oct 2022 15:32:04 -  1.72
+++ Makefile21 Oct 2022 21:41:10 -
@@ -13,7 +13,7 @@ COMMENT-redis =   collectd redis plugin
 COMMENT-prometheus =   collectd prometheus plugin
 COMMENT-ping = collectd ping plugin
 
-V =5.8.1
+V =5.12.0
 DISTNAME = collectd-$V
 PKGNAME-main = collectd-$V
 PKGNAME-mysql =collectd-mysql-$V
@@ -30,20 +30,6 @@ PKGNAME-redis =  collectd-redis-$V
 PKGNAME-prometheus =   collectd-prometheus-$V
 PKGNAME-ping = collectd-ping-$V
 CATEGORIES =   sysutils
-REVISION-main =2
-REVISION-memcachec =   2
-REVISION-mqtt =1
-REVISION-mysql =   2
-REVISION-nut = 3
-REVISION-pgsql =   1
-REVISION-ping =1
-REVISION-prometheus =  4
-REVISION-python =  3
-REVISION-redis =   1
-REVISION-riemann = 4
-REVISION-rrdtool = 4
-REVISION-snmp =1
-REVISION-virt =4
 
 HOMEPAGE = http://www.collectd.org/
 SHARED_LIBS += collectdclient 1.0
@@ -78,7 +64,7 @@ LIB_DEPENDS-rrdtool = net/rrdtool
 RUN_DEPENDS-rrdtool =  collectd-$V:${BASE_PKGPATH},-main
 
 LIB_DEPENDS-snmp = net/net-snmp
-WANTLIB-snmp = crypto netsnmp pthread c kvm m netsnmpagent perl
+WANTLIB-snmp = crypto netsnmp pthread c kvm m netsnmpagent perl ssl
 RUN_DEPENDS-snmp = collectd-$V:${BASE_PKGPATH},-main
 
 LIB_DEPENDS-virt = sysutils/libvirt
Index: distinfo
===
RCS file: /cvs/ports/sysutils/collectd/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo18 Nov 2018 19:39:29 -  1.12
+++ distinfo21 Oct 2022 21:41:10 -
@@ -1,2 +1,2 @@
-SHA256 (collectd-5.8.1.tar.bz2) = 55b9onzgY3f0ka2RqihpYqaMK1QHaqd6KWc9UyBEU9o=
-SIZE (collectd-5.8.1.tar.bz2) = 1789228
+SHA256 (collectd-5.12.0.tar.bz2) = W64EMELBnDH3frhGTlagGlRU4LOfoHz3rQ8b/Jw6CdY=
+SIZE (collectd-5.12.0.tar.bz2) = 1902756
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/sysutils/collectd/patches/patch-Makefile_in,v
retrieving revision 1.11
diff -u -p -r1.11 patch-Makefile_in
--- patches/patch-Makefile_in   11 Mar 2022 19:57:17 -  1.11
+++ patches/patch-Makefile_in   21 Oct 2022 21:41:10 -
@@ -1,26 +1,26 @@
 Index: Makefile.in
 --- Makefile.in.orig
 +++ Makefile.in
-@@ -109,7 +109,7 @@ check_PROGRAMS = test_common$(EXEEXT) test_format_grap
- @BUILD_WITH_LIBSOCKET_TRUE@am__append_4 = -lsocket
- @BUILD_WITH_LIBKSTAT_TRUE@am__append_5 = -lkstat
- @BUILD_WITH_LIBDEVINFO_TRUE@am__append_6 = -ldevinfo
--@BUILD_FEATURE_DAEMON_TRUE@am__append_7 = 
-DPIDFILE='"${localstatedir}/run/${PACKAGE_NAME}.pid"'
-+@BUILD_FEATURE_DAEMON_TRUE@am__append_7 = 
-DPIDFILE='"${localstatedir}/${PACKAGE_NAME}/${PACKAGE_NAME}.pid"'
+@@ -129,7 +129,7 @@ TESTS = $(check_PROGRAMS) $(am__EXEEXT_3) $(am__EXEEXT
+ @BUILD_WIN32_TRUE@am__append_13 = -ldl -Wl,--out-implib,libcollectd.a \
+ @BUILD_WIN32_TRUE@-Wl,--out-implib,libcollectd.a
+ @BUILD_WIN32_FALSE@am__append_14 = src/daemon/cmd.c
+-@BUILD_FEATURE_DAEMON_TRUE@am__append_15 = 
-DPIDFILE='"${localstatedir}/run/${PACKAGE_NAME}.pid"'
++@BUILD_FEATURE_DAEMON_TRUE@am__append_15 = 
-DPIDFILE='"${localstatedir}/${PACKAGE_NAME}.pid"'
  
  # The daemon needs to call sg_init, so we need to link it against libstatgrab,
  # too. -octo
-@@ -3210,7 +3210,7 @@ AM_CPPFLAGS = \
-   -DPREFIX='"${prefix}"' \
-   -DCONFIGFILE='"${sysconfdir}/${PACKAGE_NAME}.conf"' \
-   -DLOCALSTATEDIR='"${localstatedir}"' \
--  -DPKGLOCALSTATEDIR='"${localstatedir}/lib/${PACKAGE_NAME}"' \
-+  -DPKGLOCALSTATEDIR='"${localstatedir}/${PACKAGE_NAME}"' \
-   -DPLUGINDIR='"${pkglibdir}"' \
-   -DPKGDATADIR='"${pkgdatadir}"'
- 
-@@ -7821,16 +7821,8 @@ uninstall-man: uninstall-man1 uninstall-man5
- @HAVE_GRPC_CPP_TRUE@@HAVE_PROTOC3_TRUE@   $(V_PROTOC)$(PROTOC) 

sysutils/obsdfreqd increase priority

2022-10-11 Thread Solène Rapenne
This diff adds a file in /etc/login.conf.d to set the priority of
obsdfreqd to -15, this will help it to kick in faster under load.

tested on powerpc


Index: Makefile
===
RCS file: /cvs/ports/sysutils/obsdfreqd/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile13 Sep 2022 11:16:15 -  1.6
+++ Makefile11 Oct 2022 16:49:45 -
@@ -1,6 +1,7 @@
 COMMENT =  userland daemon to manage CPU frequency
 V =1.0.3
 DISTNAME = obsdfreqd-${V}
+REVISION = 0
 
 CATEGORIES =   sysutils
 
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/obsdfreqd/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST   21 Apr 2022 17:12:31 -  1.1.1.1
+++ pkg/PLIST   11 Oct 2022 16:49:45 -
@@ -1,3 +1,5 @@
 @rcscript ${RCDIR}/obsdfreqd
 @man man/man1/obsdfreqd.1
 @bin sbin/obsdfreqd
+share/examples/login.conf.d/obsdfreqd
+@sample ${SYSCONFDIR}/login.conf.d/obsdfreqd
Index: pkg/obsdfreqd.login
===
RCS file: pkg/obsdfreqd.login
diff -N pkg/obsdfreqd.login
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pkg/obsdfreqd.login 11 Oct 2022 16:49:45 -
@@ -0,0 +1,3 @@
+obsdfreqd:\
+   :priority=-15:\
+   :tc=daemon:



Re: iblock : update to 1.1.0

2022-09-18 Thread Solène Rapenne
Le Sat, 17 Sep 2022 20:54:38 +0200,
prx  a écrit :

> iblock now kill established connections after banning an IP.
> 
> Find attached a diff to update the port to 1.1.0.
> 
> Regards.
> 
> prx

hold on, it seems this version is buggy



Re: CVS: cvs.openbsd.org: ports

2022-08-22 Thread Solène Rapenne
Le Sun, 21 Aug 2022 07:35:42 -0600 (MDT),
Stuart Henderson  a écrit :

> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   st...@cvs.openbsd.org   2022/08/21 07:35:42
> 
> Modified files:
>   databases/mariadb: Tag: OPENBSD_7_1 Makefile distinfo 
>   databases/mariadb/patches: Tag: OPENBSD_7_1 
>  patch-include_ssl_compat_h 
>  patch-libmariadb_libmariadb_CMakeLists_txt 
>   databases/mariadb/pkg: Tag: OPENBSD_7_1 PLIST-server PLIST-tests 
> 
> Log message:
> update to MariaDB 10.6.9, from Brad
> CVE-2018-25032, CVE-2022-32081, CVE-2022-32082, CVE-2022-32084, 
> CVE-2022-32089, CVE-2022-32091
> 

fails to build on OpenBSD 7.1

-- Configuring done
-- Generating done
-- Build files have been written to: /build/tmp/pobj/mariadb-10.6.9/build-amd64
===>  Building for mariadb-10.6.9
[1/1867] cd /build/tmp/pobj/mariadb-10.6.9/build-amd64 && /usr/local/bin/cmake 
-P /build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/cmake/info_src.cmake
[2/1867] cd /build/tmp/pobj/mariadb-10.6.9/build-amd64 && /usr/local/bin/cmake 
-P /build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/cmake/info_bin.cmake
[3/1867] /build/tmp/pobj/mariadb-10.6.9/bin/c++ -DNDEBUG 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/include 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API/v26 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API -O2 -pipe  
-I/usr/local/include -fstack-protector --param=ssp-buffer-size=4 -Wall -Wextra 
-Woverloaded-virtual -Wconversion -g -Wsuggest-override -DNDEBUG 
-D_FORTIFY_SOURCE=2 -std=gnu++11 -MD -MT 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/client_state.cpp.o -MF 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/client_state.cpp.o.d -o 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/client_state.cpp.o -c 
/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/src/client_state.cpp
[4/1867] /build/tmp/pobj/mariadb-10.6.9/bin/c++ -DNDEBUG 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/include 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API/v26 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API -O2 -pipe  
-I/usr/local/include -fstack-protector --param=ssp-buffer-size=4 -Wall -Wextra 
-Woverloaded-virtual -Wconversion -g -Wsuggest-override -DNDEBUG 
-D_FORTIFY_SOURCE=2 -std=gnu++11 -MD -MT 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/exception.cpp.o -MF 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/exception.cpp.o.d -o 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/exception.cpp.o -c 
/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/src/exception.cpp
[5/1867] /build/tmp/pobj/mariadb-10.6.9/bin/c++ -DNDEBUG 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/include 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API/v26 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API -O2 -pipe  
-I/usr/local/include -fstack-protector --param=ssp-buffer-size=4 -Wall -Wextra 
-Woverloaded-virtual -Wconversion -g -Wsuggest-override -DNDEBUG 
-D_FORTIFY_SOURCE=2 -std=gnu++11 -MD -MT 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/gtid.cpp.o -MF 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/gtid.cpp.o.d -o 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/gtid.cpp.o -c 
/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/src/gtid.cpp
[6/1867] /build/tmp/pobj/mariadb-10.6.9/bin/c++ -DNDEBUG 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/include 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API/v26 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API -O2 -pipe  
-I/usr/local/include -fstack-protector --param=ssp-buffer-size=4 -Wall -Wextra 
-Woverloaded-virtual -Wconversion -g -Wsuggest-override -DNDEBUG 
-D_FORTIFY_SOURCE=2 -std=gnu++11 -MD -MT 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/id.cpp.o -MF 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/id.cpp.o.d -o 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/id.cpp.o -c 
/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/src/id.cpp
[7/1867] /build/tmp/pobj/mariadb-10.6.9/bin/c++ -DNDEBUG 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/include 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API/v26 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API -O2 -pipe  
-I/usr/local/include -fstack-protector --param=ssp-buffer-size=4 -Wall -Wextra 
-Woverloaded-virtual -Wconversion -g -Wsuggest-override -DNDEBUG 
-D_FORTIFY_SOURCE=2 -std=gnu++11 -MD -MT 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/xid.cpp.o -MF 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/xid.cpp.o.d -o 
wsrep-lib/src/CMakeFiles/wsrep-lib.dir/xid.cpp.o -c 
/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/src/xid.cpp
[8/1867] /build/tmp/pobj/mariadb-10.6.9/bin/c++ -DNDEBUG 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/include 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API/v26 
-I/build/tmp/pobj/mariadb-10.6.9/mariadb-10.6.9/wsrep-lib/wsrep-API -O2 -pipe  

Re: [EXTERNAL] free - can only display usage

2022-06-14 Thread Solène Rapenne
Le Tue, 14 Jun 2022 12:52:45 +0100,
Matthew  a écrit :

> Hi Brian,
> 
> Thanks for your response. I'll use ports@ in future - noted.
> 
> I understand the fallback to print usage() in the event of passing more
> than one param, however in my case usage() is being called regardless.
> 
> I have /usr/ports on my system but I'm not familiar with the build
> process in OpenBSD ports yet to be able discern what's going on.
> 
> However, I have built from upstream and behaviour is as expected:
> 
> me@box:~/free$ ./free
> 
>   total  used  free
>   Mem:  7.9G  7.3G
>   545M
>   Swap: 8.1G0B
>   8.1G
> 
> Grateful if you could let me know if I'm doing anything wrong. Many
> thanks.
> 
> Matthew

I think free is a command available on Linux systems. Maybe you have an
alias for free doing free -flag, this wouldn't be triggered when using
./free from sources.

Try "type free" to see if it's an alias or the real binary path.



Re: make: don't know how to make .tgz (prerequisite of: _internal-package-only)

2021-07-31 Thread Solène Rapenne
Le Sat, 31 Jul 2021 15:37:31 +0200,
Alessandro De Laurenzis  a écrit :

> Greetings,
> 
> I'm trying to update math/eigen3 (which makes use of PSEUDO_FLAVORS).
> 
> Even using the version currently in the tree, when I try to make the 
> package, the following error is issued:
> 
> > $ make package
> > make: don't know how to make
> > /usr/ports/packages/amd64/all//eigen3-3.2.2p5.tgz (prerequisite of:
> > _internal-package-only) Stop in . *** Error 2 in .
> > (/usr/ports/infrastructure/mk/bsd.port.mk:2623 '_internal-package')
> > *** Error 2 in /usr/ports/math/eigen3
> > (/usr/ports/infrastructure/mk/bsd.port.mk:2602 'package')  
> 
> Could you please give me some hints? I read the FAQ (probably not
> very carefully, I have to admit...), but I didn't find anything
> relevant for this specific problem.
> 
> Cheers
> 

hello, could you share the changes you did to the port?



Re: Remove net/pcapdiff?

2020-09-19 Thread Solène Rapenne

Le 2020-09-19 19:48, Kurt Mosiejczuk a écrit :

pcapdiff doesn't have any consumers and is python2 only. pcapdiff
is no longer under development. (It's homepage at EFF refers one
to another project instead).

Remove it?

--Kurt


Why remove it? Because it's python2? Do we have a python2 expiration
policy? (I see others OS have a deadline for python2 removal, maybe
we should do the same)

If it works and that we don't have alternative in ports I think
we should keep it.

There is a python3 pcapdiff at https://github.com/isginf/pcap-diff
I don't know if it's a fork of net/pcapdiff though.



Re: Killing gpg1

2020-09-05 Thread Solène Rapenne

Le 2020-09-05 13:25, Edd Barrett a écrit :

Hi all,

We've been talking about trying to remove security/gnupg (i.e. gpg
version 1) for some time, and the recent plist clash has given me the
kick up the butt I needed to look more seriously at this.

Below is a list of things that still depend upon gpg1, by maintainer, 
as

determined by:

select fullpkgpath from ports where build_depends glob
'*security/gnupg[^2]*' or run_depends glob '*security/gnupg[^2]*'
order by maintainer;

Let's see if we can move these to gpg2. I'll start by working my way
through the ports with no maintainer. I'd appreciate it if maintainers
could help out with their ports.
solene@:
mail/mailpile


It seems mailpile isn't going to support gpg2 before some time.
https://github.com/mailpile/Mailpile/issues/1133

The development has slowed in the last years, maybe we should remove
mailpile from ports, the project doesn't seem to be going anywhere.



Re: update: games/openttd

2020-04-19 Thread Solène Rapenne

Le 2020-04-19 11:30, Paco Esteban a écrit :

Hi ports@,

This is a simple update to games/openttd.  They released a bugfix
release recently.  Here is the changelog:

https://cdn.openttd.org/openttd-releases/1.10.1/changelog.txt

CCing maintainer.

Builds and works ok for me on amd64.  I haven't played much, so it 
would

be nice if more regular users of this game could take a look.

Index: Makefile
===
RCS file: /home/cvs/ports/games/openttd/Makefile,v
retrieving revision 1.67
diff -u -p -r1.67 Makefile
--- Makefile7 Apr 2020 15:13:34 -   1.67
+++ Makefile18 Apr 2020 08:08:34 -
@@ -2,7 +2,7 @@

 COMMENT=   open source clone of the game Transport Tycoon Deluxe

-V =1.10.0
+V =1.10.1
 DISTNAME = openttd-$V-source
 PKGNAME =  openttd-$V

Index: distinfo
===
RCS file: /home/cvs/ports/games/openttd/distinfo,v
retrieving revision 1.34
diff -u -p -r1.34 distinfo
--- distinfo7 Apr 2020 15:13:34 -   1.34
+++ distinfo18 Apr 2020 08:08:43 -
@@ -1,2 +1,2 @@
-SHA256 (openttd/openttd-1.10.0-source.tar.xz) =
G6IarJod6Ysj+A/ulStLnF4tPMSsGH9SA3MIJrPw4lM=
-SIZE (openttd/openttd-1.10.0-source.tar.xz) = 6801228
+SHA256 (openttd/openttd-1.10.1-source.tar.xz) =
DSKjxQ96Mh9PIRWU9Jh6wWw4Ho4+QPEWhI5j6R5/u5s=
+SIZE (openttd/openttd-1.10.1-source.tar.xz) = 6741548


Hello,

Thank you for your update although I updated it one hour ago :-)



Re: cannot set firefox as default

2020-02-08 Thread Solène Rapenne

Le 2020-02-08 14:45, Jan Stary a écrit :

This is firefox-72.0.2 on a fresh current/amd64.

Upon start, it asks to be the default browser.
I click yes, but the setting does not get saved:


do you have dbus started?



Re: Update devel/scons

2020-02-06 Thread Solène Rapenne

Le 2020-02-06 21:01, Denis Fondras a écrit :

Update to 3.1.2. Will be useful to upgrade MongoDB.



-@comment $OpenBSD: PLIST,v 1.11 2017/06/28 16:26:55 bcallah Exp $
+@comment $OpenBSD: PLIST,v$



+bin/scons-${VERSION}.bat
+bin/scons.bat


I'm not sure we need those bat files



Re: Remove: audio/puddletag

2020-02-01 Thread Solène Rapenne

Le 2020-02-01 17:59, Rafael Sadowski a écrit :

Here is a py2-only/py-qt4 audio tag editor. Don't we have enough of
that in the tree? Does anybody use it?


I use it, alternatives I tried in the past were not as effective as
puddletag which displays all songs as a spreadsheet, and you can do
mass changes.
But if you know some good alternatives, I'm ok for removal.



games/jumpnbump networking game not working?

2019-12-17 Thread Solène Rapenne

Hi,

I tried to play jumpnbump in network but it doesn't seem to work.

Official "website" https://gitlab.com/LibreGames/jumpnbump explains the 
network parameters as this


Player 1: jumpnbump -port  -net 0  



Player 2: jumpnbump -port  -net 1  




if I run

jumpnbump -port 1234 -net 0 127.0.0.1 1236

and run fstat | grep 1234 I have no output while it should listen on UDP

if I try running another game with this command:

jumpnbump -port 1236 -net 1 127.0.0.1 1234

nothing happen and I have 2 games running with no connection.

Any idea why?



Re: [wip] firefox 71.0b8 with unveil integration

2019-11-08 Thread Solène Rapenne
If someone can confirm a behavior I had with firefox patched for pledge and 
unveil
I was not able to delete extensions, but it wasn't triggering a pledge error 
and I've not been able to deal with the huge ktrace...Le 8 nov. 2019 23:48, 
Landry Breuil  a écrit :
>
> Hi, 
>
> now that jcs@'s work has been commited upstream and will be in firefox 
> 72 (cf https://bugzilla.mozilla.org/show_bug.cgi?id=1580268, 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1584839 & 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1580271) i've backported 
> all the corresponding commits to the upcoming 71 release (due beginning 
> of december) in my git repo (in the unveil branch) and adapted the 
> corresponding pledge/unveil per-process configs - cf 
> https://cgit.rhaalovely.net/mozilla-firefox/?h=unveil 
>
> see 
> https://cgit.rhaalovely.net/mozilla-firefox/tree/pkg/README?h=unveil#n17 
> for the details on the configuration, and note that this will 
> break/ignore the file associations configured in firefox, relying on 
> xdg-open to rely on the file associations configured via xdg-mime. 
> https://cgit.rhaalovely.net/mozilla-firefox/tree/pkg/README?h=unveil#n68 
> has more bits on specific logging/debugging. 
>
> https://packages.rhaalovely.net/ has amd64 pkgs for 71.0b8 built from 
> this branch, and i'm running it now. This needs more testing from anyone 
> actually using firefox in weird environments so that we figure out more 
> missing paths. 
>
> Landry 
>


Re: Tor-Browser port

2019-10-08 Thread Solène Rapenne
And it's now marked BROKEN so it's unlikely it will ship in 6.6 except if 
someone fix it in the next days.Le 8 oct. 2019 23:55, Stuart Henderson 
 a écrit :
>
> On 2019/10/08 23:35, ports wrote: 
> > Hello, 
> > 
> > it seems to me that the tor-browser port is pretty outdated. Is there a 
> > good reason for that circumstance ? 
> > 
> > May I help there ? 
>
> Better to ask the maintainer, but afaik it "just" needs someone with time 
> to do the work. 
>


Re: [update] sbcl-1.5.6

2019-09-14 Thread Solène Rapenne

Le 2019-09-14 17:39, Josh Elsasser a écrit :

On Sat, Sep 14, 2019 at 08:03:25AM +0300, Timo Myyrä wrote:

Hi,

Here's simple update for sbcl to latest release.
Tested on amd64.

Timo


It looks like 1.5.6 is currently broken on older ppc hardware, likely
because of recent ppc64 work. Perhaps it would be better to update to
1.5.5 instead until ppc is fixed upstream.

I tested an update to 1.5.5 recently on all three arches, anyone
interested in testing their favorite code, or in committing this 
update?



Index: Makefile
===
RCS file: /cvs/ports/lang/sbcl/Makefile,v
retrieving revision 1.42
diff -u -r1.42 Makefile
--- Makefile12 Jul 2019 20:47:22 -  1.42
+++ Makefile14 Sep 2019 15:30:08 -
@@ -6,7 +6,7 @@

 COMMENT=   compiler and runtime system for ANSI Common Lisp

-V =1.5.2
+V =1.5.5
 DISTNAME=  sbcl-${V}-source
 PKGNAME=   sbcl-${V}
 WRKDIST=   ${WRKDIR}/sbcl-${V}
Index: distinfo
===
RCS file: /cvs/ports/lang/sbcl/distinfo,v
retrieving revision 1.17
diff -u -r1.17 distinfo
--- distinfo13 May 2019 12:58:58 -  1.17
+++ distinfo14 Sep 2019 15:30:08 -
@@ -1,2 +1,2 @@
-SHA256 (sbcl-1.5.2-source.tar.bz2) =
2sau8+x2KMKEox8iIu3l1H2dlPnP3/4PAO9A+VMePD8=
-SIZE (sbcl-1.5.2-source.tar.bz2) = 6343957
+SHA256 (sbcl-1.5.5-source.tar.bz2) =
y0f65qhvDFxXQxYE+05fEcioI/lM4SjVaLh3D8W8quI=
+SIZE (sbcl-1.5.5-source.tar.bz2) = 6351480


I've been using it with no issue.
I will commit it tomorrow if nobody says something.



Re: [maintainer update] gzdoom-4.1.2

2019-06-09 Thread Solène Rapenne

Le 2019-06-03 13:38, Solene Rapenne a écrit :

On Mon, Jun 03, 2019 at 01:47:29PM +0300, Timo Myyrä wrote:

Hi,

Isn't the patch included on the second diff?

Timo



indeed, I was using the diff in your first mail.

ok solene@ for the diff in the second mail


I'll commit it soon, but I found that old saves are not compatibles
with this new version, this is a bit embarassing.

I did not find a way to convert them. I think this is worth
an entry in current.html



Re: backport net/tor update

2019-05-31 Thread Solène Rapenne

Le 2019-05-31 16:58, Pascal Stumpf a écrit :

On Wed, 29 May 2019 08:31:04 +0200, Solene Rapenne wrote:

Hi

I'd like to backport the net/tor update to 6.5, works fine for me on
various machines.


Why?  -stable is usually reserved for security or otherwise very
important updates.  As far as I'm aware, there's no compelling reason
for chasing the 0.3.5 -> 0.4.0 switch: The old series is still 
supported

security-wise and the network is still very much functional with the
old version.

-Pascal



Right, I tought it was a new release but since your reply I've seen that
0.3.5 will receive updates until Feb 2022.

sorry for the noise, I'll think more next time instead of wasting people 
time.




Re: [new] sysutils/yabitrot

2019-02-12 Thread Solène Rapenne


Le 12 févr. 2019 23:06, Daniel Jakots  a écrit :
>
> On Tue, 12 Feb 2019 22:39:24 +0100, Solene Rapenne  
> wrote: 
>
> > It's just a python script. 
>
> what's the point of packaging it then? 
>

I was pretty sure this question would rise.
So, I think it's worth having it in ports, I reviewed it to make sure it's not 
harmful or not functional and it makes easier for installation, users can trust 
the package.
 I will understand if people think packaging a script is not worth.



Re: devel/help2man fix build

2018-07-26 Thread Solène Rapenne

Le 2018-07-26 11:15, Solene Rapenne a écrit :

devel/help2man uses a .tar.xz distfile, if archivers/xz is not
installed, you can't build it because xzdec is not installed.

Index: Makefile
===
RCS file: /cvs/ports/devel/help2man/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile2 Apr 2018 08:42:31 -   1.24
+++ Makefile26 Jul 2018 09:13:58 -
@@ -12,6 +12,8 @@ HOMEPAGE= https://www.gnu.org/software/h
 # GPLv3
 PERMIT_PACKAGE_CDROM=  Yes

+BUILD_DEPENDS= archivers/xz
+
 SEPARATE_BUILD=Yes
 NO_TEST=   Yes


nevermind, forget this :)



Re: new: games/barony

2018-04-30 Thread Solène Rapenne

Le 2018-04-30 14:08, David CARLIER a écrit :
Thanks for the feedback, in case you can always force the Debug mode 
via

cmake e.g. -DCMAKE_BUILD_TYPE=Debug
If I recall correctly you re running it into ppc arch ? Would like to 
see

classic x86 archs users feedbacks too.
Will try myself in some hours.

On 30 April 2018 at 11:01, Solene Rapenne  wrote:



Thomas Frohwein writes:

> On Fri, Mar 30, 2018 at 12:42:36AM +0200, Solene Rapenne wrote:
>
> I tried it on amd64 - installed the package, downloaded Barony: Cursed
Edition
> from gog.com, innoextract, then copied all the game files to
> /usr/local/share/games/barony. It counts through all the 400-something
assets
> that it loads, but afterwards just exits without any error.
>
> The version on gog.com is listed as 2.0.7 and is probably outdated. I
think
> a README with some details on this and maybe the game data folder may be
> useful.
>
> I'll probably have to wait for an update on gog.com before being able
to test.

GOG now has 3.1.4 version. I still can't get the game to work, using
latest port version.

I did :

$ innoextract 'setup_barony_cursed_edition_3.1.4_(20340).exe'
$ doas rsync -av tmp/ /usr/local/share/games/barony/
$ barony
[12-58-43] Data path is /usr/local/share/games/barony
$ echo $?
$ 1

I don't succeed having a backtrace with gdb.



I did use an amd64 -current system with a fresh 
/usr/local/share/games/barony

folder. I will try again with the cmake debug flags. :)



Re: [UPDATE] databases/p5-DBI

2018-03-08 Thread Solène Rapenne

Le 2018-02-28 10:09, Solene Rapenne a écrit :
Update p5-DBI from 1.633 to 1.640, it pass all the tests using make 
test


up ?



Re: Update: lang/sbcl to 1.4.5 and patch for MAP_STACK

2018-03-08 Thread Solène Rapenne

Le 2018-03-07 23:03, Josh Elsasser a écrit :

Builds and passes tests on amd64 and i386, builds on macppc and test
results don't look much worse. Any sbcl users care to give the update
a try?

diff -ruN ./Makefile ../../mystuff/lang/sbcl/Makefile
--- ./Makefile  Tue Jan 23 08:15:57 2018
+++ ../../mystuff/lang/sbcl/MakefileWed Mar  7 11:32:54 2018


Hello,

Your diff has wrong paths, it doesn't apply correctly with patch.

I tested your diff neverthless, sbcl works fine on amd64, I'm able to
compile and use x11/stumpwm. I used a few lisp programs with the
new version and I had no issue so far. I tried the -threads flavor
which compiled fine, maybe it will fix the issue added in comments
in the Makefile that the thread flavor crash from time to time
at the build stage. The -threads flavors also let compiling stumpwm
and some other common lisp code.



Re: [Patch] Python for non wxallowed /usr/local

2018-01-26 Thread Solène Rapenne

Le 2018-01-26 15:36, mazocomp a écrit :

 # Python itself is clean, but some extensions e.g. py-cryptography
 # and QtWebKit require W|X mappings.
+.if ${FLAVOR} == "wx"
 USE_WXNEEDED = Yes
+.endif

 .if ${VERSION} == "3.6"
 ALL_TARGET =   all


IIRC python doesn't have W^X issue but some python libraries will load
shared libraries requiring W^X so python has to be compiled with 
wxneeded

to load those libraries.



Re: webmail

2018-01-23 Thread Solène Rapenne

Le 2018-01-22 17:33, Jan Stary a écrit :

What do people use as a light-weight webmail above smtpd?
Does smptd need to store in Maildirs as opposed to mbox?

Thanks,

Jan


Hello,

You can try https://www.mailpile.is/ it's a webmail
intended to be used by only one person, it gather mails
from different places and doesn't synchronize. It aims
security by encrypting every mail on the disk and manage
easily PGP keys and signed mails, but I'm not able to say
if the security is done well.

I made a port I never commited if you want to try, it works
well on OpenBSD. It can also be easily installed using
virtual-env as it's a python software.



Re: PDF and PS viewers

2017-12-07 Thread Solène Rapenne

Le 2017-12-07 21:37, Jan Stary a écrit :

What do people use as a lightweight PDF and/or PS viewer?
I switched from xpdf to mupdf some time ago for pdf,
and still use gv for PS.

Would you recommed something else, light, not tied
to GNOME or KDE or some huge grraphic framework?

Thank you

Jan


Hi, mupdf is fine. Why do you want to change ?



Re: games/tome4 - remove powerpc arch

2017-11-21 Thread Solène Rapenne

Le 2017-11-21 17:19, Jeremie Courreges-Anglas a écrit :

On Tue, Nov 21 2017, Solène Rapenne <sol...@perso.pw> wrote:

Building games/tome4 on powerpc (macppc kernel) fail

I propose to remove powerpc as a supported arch


Fair proposal.  lang/luajit has a patch to explicitely disable this
error message, plus another one for the generated asm.

What I don't understand, though, is why luajit thinks that powerpc is
little-endian: our powerpc architecture is definitely big-endian.

Could you please try to run ''make test'' in lang/luajit on powerpc?



`make test` in lang/luajit on powerpc shows "hello world" as expected
and the package compile fine.



lang/gcc gnat : seems that sockets doesn't work

2017-08-30 Thread Solène Rapenne

Hello,

I'm learning Ada language and found that the following code
raise an error at runtime on OpenBSD 6.1 :

raised GNAT.SOCKETS.SOCKET_ERROR : [47] Address family not supported by 
protocol family


The following code works on another operating system also using gnat

-->B>B---
with Ada.Text_IO; use Ada.Text_IO;
with GNAT.Sockets;  use GNAT.Sockets;
with Ada.Streams; use Ada.Streams;

procedure Main is
   Client : Socket_Type;
   Address : Sock_Addr_Type;
   Channel : Stream_Access;
   Send   : String := (1 => ASCII.CR, 2 => ASCII.LF,
   3 => ASCII.CR, 4 => ASCII.LF);
   Offset : Ada.Streams.Stream_Element_Count;
   Data   : Ada.Streams.Stream_Element_Array (1 .. 256);
begin
   Address.Addr := Inet_Addr("163.172.223.238");
   Address.Port := 70;
   Create_Socket (Client);
   Connect_Socket (Client, Address);
   Channel := Stream(Client);

   String'Write (Channel, "/" & Send);
   loop
  Read (Channel.All, Data, Offset);
  exit when Offset = 0;
  for I in 1 .. Offset loop
 Ada.Text_IO.Put (Character'Val (Data (I)));
  end loop;
   end loop;
end Main;
-->B>B---



Re: New: devel/noweb 2.11b

2017-05-03 Thread Solène Rapenne

Le 2016-11-07 23:20, Jeremie Courreges-Anglas a écrit :

Ray Lai  writes:


On 10/23/16 18:53, Ray Lai wrote:

Based on Carlos Alberto Pereira Gomes's work:
https://marc.info/?l=openbsd-ports=105265115901089=2

DESCR:
noweb is designed to meet the needs of literate programmers while
remaining as simple as possible. Its primary advantages are 
simplicity,

extensibility, and language-independence—especially noticeable
when compared with other literate-programming tools. noweb uses 5
control sequences to WEB's 27. The noweb manual is only 4 pages;
an additional page explains how to customize its LaTeX output. noweb
works ``out of the box'' with any programming language, and supports
TeX, latex, HTML, and troff back ends. A back end to support full
hypertext or indexing takes about 250 lines; a simpler one can be
written in 40 lines of awk.  The primary sacrifice relative to WEB
is that code is seldom prettyprinted.



I removed the elisp support, as the homepage states "In 2012, I 
learned

that there is no longer any Emacs mode that supports Noweb and really
works with Emacs 23 or Emacs 24."

Enjoy!


Cleaned things up (strcpy, some malloc checks).


Looks fine, except for the following items:
- COMMENT should not start with a capital letter or an article
- kill the first line of DESCR, as it is the same as COMMENT.  I'm
  wondering whether the last paragraph actually adds value. *shrug*

The strcpy/malloc/etc changes don't seem to fix actual problems (sorry
if I'm wrong here). Checking for malloc returning NULL is good 
practice,

but the only gain here would be a fatal error message instead of
a crash. Also it feels weird to introduce strlcat in an old codebase
that still uses a local getline function. I suggest that you propose
improvements upstream first.

Here's an updated tarball.  Can I get another review?


Up ? That would be cool to have noweb in ports



Re: lang/erlang : erlc17 not working

2017-05-03 Thread Solène Rapenne

Le 2017-05-03 10:51, Paul Fariello a écrit :

On 2016-04-06 12:35:58, Solène Rapenne wrote:

Le 2016-03-29 17:23, Solène Rapenne a écrit :
> Hello,
>
> My system : (current, amd64)
> OpenBSD 5.9-current (GENERIC.MP) #1970: Mon Mar 28 17:02:06 MDT 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
>
> I installed lang/erlang17 (erlang-17.5p5v0) and the command are
> suffixed by 17 (erl17 for erl, erlc17 for erlc). Problem, erlc17 tries
> to call "erl" binary, which doesn't exist.
>
> ~~~ Terminal ~~~
> # erlc17
> erlc: Error 2 executing 'erl'.
> 
>

Hello,

With this patch, lang/erlang/17 gives erlc17 which works. No 
regression

found.

I think the same work should be done for 16 and 18 too. While the
pre-configure is common for the 3 versions, the substitution isn't 
done
for every file for the 3 versions but they still compile fine and 
there

is no error issued.


Hi all,

I'm exhuming this quite old mail from Solène.
I'm having the exact same issue on both erlang17 and erlang18.


OpenBSD 5.9 (GENERIC.MP) #1616: Fri Feb 26 01:28:13 MST 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP


I'm not currently running 6.1 (shame on me !) but erlang{17,18} ports 
doesn't

seems to have changes concerning this issue.

Is there any plan of merging Solène's patches ?
If not, how can we help fixing the issue ?


Regards,


Hello
A workaround is to create a symbolic link erl in $PATH to the installed 
erl.




Re: Anyone been able to run multimedia/lives?

2017-04-16 Thread Solène Rapenne

Le 2017-04-15 15:31, Kristaps Dzonsons a écrit :

Hello,

Has anybody been able to actually edit video with multimedia/lives?
I've never been able to get past loading a video, at which point the
application crashes without any debug message except the now-familiar
"lives has crashed" message.  When I run the application in gdb, I get 
a

segv here:

Program received signal SIGSEGV, Segmentation fault.
0x1d2688b95c30 in gdk_rgb_convert_0888 () from
/usr/local/lib/libgdk-x11-2.0.so.2400.0
(gdb) bt
#0  0x1d2688b95c30 in gdk_rgb_convert_0888 () from
/usr/local/lib/libgdk-x11-2.0.so.2400.0

The backtrace doesn't say much more than that.  This has happened on
amd64 with 6.0 and 6.1.

Best,

Kristaps


hello,

I don't know much about lives, but could you try to increase the memory
limit allowed for a process ? I think it may takes too much memory.

Regards



Re: Ports with hardcoded "gcc", "g++"

2017-03-02 Thread Solène Rapenne

Le 2017-02-26 16:00, Christian Weisgerber a écrit :

Here is a first batch of ports that fail to build without "gcc" or
"g++" being present.  More will come to light eventually.  At the
moment, failing dependencies prevent about a third of the ports
tree from being built.

devel/premake4


hello

I see that devel/premake4 has been fixed.

Sadly, premake4 has gcc hardcoded when invocated. premake5
seems to have a way to choose between gcc or clang but that's still
not honoring CC variable and I'm not sure that current port
(games/tome4) needing premake4 builds with premake5.

regards



Re: sysctl set up in packages

2017-02-28 Thread Solène Rapenne

Le 2017-02-28 17:44, sven falempin a écrit :

Dear ports makers and pkg_xxx creators,

Manual states :
@sysctl var=val @sysctl var≥val During pkg_add(1), check that
sysctl(8) variable var is set to exactly/at least a given value val.
Adjust it otherwise.

This is live adjusting the value but do not change  and create 
/etc/sysctl.conf

thus the modification is not permanent,

Is there a way ( a pkg_add option hidden somewhere or just in front my 
eyes ).

do have this configure by the package even after reboot.

Cheers.


--
-
() ascii ribbon campaign - against html e-mail
/\



Hello, currently It seems that no package use this option.

Usually, tweaks needed for a package are described in the
pkg/README file in the ports, which goes into 
/usr/local/share/doc/pkg-readme

after install.



Re: [wip] Firefox 50.0beta6 & Thunderbird 52.0beta2

2017-02-17 Thread Solène Rapenne

Le 2017-02-15 08:55, Landry Breuil a écrit :

Yo,

i realized i missed the every-six-weeks email for 51, so here's one for
52, which i dunno will make the cut for 6.1 - would be nice as it's an
ESR and would allow www/firefox-esr to be 'supported' for longer than
the 45 branch in the -stable series.
Tb is at 52.0b2, soon b3 - it needs testing !

Landry


Hello,

I am using firefox 52.0beta6 on amd64 since 2 days and no problem
so far.



Re: rm -rf Xombrero

2017-02-01 Thread Solène Rapenne

Davide Gerhard writes:

> On Tuesday, 31/01/2017 22:51 GMT, Uwe Werler wrote:
>
>> On 31 Jan 23:48, Erling Westenvik wrote:
>>> > > Mmh, I use it. For me the best browser around.
>>> >
>>> > I use it as well - its the only functional graphical browser that works
>>> > on my old single-core, 2GB memory celeron.
>>> 
>>> How about surf(1). Not tabbed, and cannot be used solely by keyboard,
>>> but better rendering in general IMO. I use it now and then. It even
>>> manages to load Facebook.
>>
>> I like vimb - it's completely keyboard driven. They suggest to use tabbed 
>> with
>> it but inside tabbed the refresh takes very long.
>
> try surf2 that use webkitgtk4 and if you want tabbing you can use
> x11/tabbed. (or maybe www/epiphany)
>
> surf and vimb are using www/webkit therefore avoid it.

you can try qutebrowser, I don't. It has not been listed in the removal
list, but maybe it should be added to the list ?



Re: www/firefox can't connect to google.com

2017-01-06 Thread Solène Rapenne

Le 2017-01-06 10:47, Solène Rapenne a écrit :

Le 2017-01-06 10:38, Landry Breuil a écrit :

On Fri, Jan 06, 2017 at 10:33:04AM +0100, Solène Rapenne wrote:

Hello,

I upgraded my amd64 -current this morning (OpenBSD 6.0-current 
(GENERIC.MP)

#110: Thu Jan  5 20:32:18 MST 2017)

With the latest firefox version (firefox-50.1.0) I can't connect to
www.google.com, I get the following message

Your connection is not secure
The website tried to negotiate an inadequate level of security.
google.com uses security technology that is outdated and vulnerable 
to
attack. An attacker could easily reveal information which you thought 
to be
safe. The website administrator will need to fix the server first 
before you

can visit the site.
Error code: NS_ERROR_NET_INADEQUATE_SECURITY


I tried a few others SSL websites and they all works.


Iirc that's due to the fact that some certs were removed from cert.pem
and those were in the cert chain for google. Should be fixed or a fix 
is

in the works.

That's the perfect occasion to start using another search engine which
respects users' privacy :)

Landry


For what it worth, the problem occurs with firefox-esr too, but it 
doesn't

show an error, it just fails silently and keep the current page viewed.


thanks to johany@ on IRC, setting network.http.spdy.enabled.http2 to 
false in

about:config works as a workaround



Re: www/firefox can't connect to google.com

2017-01-06 Thread Solène Rapenne

Le 2017-01-06 10:38, Landry Breuil a écrit :

On Fri, Jan 06, 2017 at 10:33:04AM +0100, Solène Rapenne wrote:

Hello,

I upgraded my amd64 -current this morning (OpenBSD 6.0-current 
(GENERIC.MP)

#110: Thu Jan  5 20:32:18 MST 2017)

With the latest firefox version (firefox-50.1.0) I can't connect to
www.google.com, I get the following message

Your connection is not secure
The website tried to negotiate an inadequate level of security.
google.com uses security technology that is outdated and vulnerable to
attack. An attacker could easily reveal information which you thought 
to be
safe. The website administrator will need to fix the server first 
before you

can visit the site.
Error code: NS_ERROR_NET_INADEQUATE_SECURITY


I tried a few others SSL websites and they all works.


Iirc that's due to the fact that some certs were removed from cert.pem
and those were in the cert chain for google. Should be fixed or a fix 
is

in the works.

That's the perfect occasion to start using another search engine which
respects users' privacy :)

Landry


For what it worth, the problem occurs with firefox-esr too, but it 
doesn't

show an error, it just fails silently and keep the current page viewed.



www/firefox can't connect to google.com

2017-01-06 Thread Solène Rapenne

Hello,

I upgraded my amd64 -current this morning (OpenBSD 6.0-current 
(GENERIC.MP) #110: Thu Jan  5 20:32:18 MST 2017)


With the latest firefox version (firefox-50.1.0) I can't connect to 
www.google.com, I get the following message


Your connection is not secure
The website tried to negotiate an inadequate level of security.
google.com uses security technology that is outdated and vulnerable to 
attack. An attacker could easily reveal information which you thought to 
be safe. The website administrator will need to fix the server first 
before you can visit the site.

Error code: NS_ERROR_NET_INADEQUATE_SECURITY


I tried a few others SSL websites and they all works.



Re: [New] games/tome4 (previously t-engine)

2016-12-28 Thread Solène Rapenne

Le 2016-12-27 22:57, Frederic Cambus a écrit :

On Tue, Dec 27, 2016 at 06:23:33PM +0100, Sol??ne Rapenne wrote:


> > Did upstream silently re-roll the 1.4.9 distfile?



> Thanks for this analysis. I reported it upstream to know if it was
> attended and if this is something common for them.

ToME's developer say that this kind of update doesn't occur often and 
that

now he will warn about this.
That won't fix the problem for us but at least we will have the 
information

that it's an update

http://forums.te4.org/viewtopic.php?f=42=47073=220333#p220333


Thanks for bringing the issue to upstream. In this case, I suppose we
can just run makesum again before importing.

Tested the new version with split packages for core and data and it
looks good to me, with one caveat though: we should get rid of debug
symbols. I noticed they were explicitely added when patching
premake4.lua, this should be left out. Is there any specific reason
to include them?

With this change in, OK fcambus@ to import.


jca@ asked me to enable debug symbols by default because the only way to 
have
symbols is to use the patch to add it explicitly. If you want to build 
this port

with debug symbols using DEBUG=-g that won't do anything.



Re: [New] games/tome4 (previously t-engine)

2016-12-27 Thread Solène Rapenne

Le 2016-12-23 09:24, Solène Rapenne a écrit :

Hi Solene,

while testing the update fcambus@ noticed that the checksum of the 
downloaded

file doesn't match.

I was able to confirm the same issue after moving aside my already 
downloaded

distfile from previous tests.

Did upstream silently re-roll the 1.4.9 distfile?

SHA512 (t-engine4-src-1.4.9.tar.bz2-new) =
0d527f18f9844c38478f71829d4944c3221aa0817f52ab4f44aed5990493a769e206228b367dad413bc9f111be9404db8e9e6b6f9f0e0c821ffc27c721ccc1da
SHA512 (t-engine4-src-1.4.9.tar.bz2-old) =
f604fe2e65cafb17f173c69f84af292dbd7dd8d74f43947fec3a6ced749d1c1973453ceb2f83e75025a2447b7e0bd6d822801cdfedacffa6680625b4f8ba0999

$ diff -ru t-engine4-src-1.4.9-old t-engine4-src-1.4.9-new/
Binary files t-engine4-src-1.4.9-old/game/engines/te4-1.4.9.teae and
t-engine4-src-1.4.9-new/game/engines/te4-1.4.9.teae differ
Binary files t-engine4-src-1.4.9-old/game/modules/boot-te4-1.4.9.team
and t-engine4-src-1.4.9-new/game/modules/boot-te4-1.4.9.team differ
Binary files t-engine4-src-1.4.9-old/game/modules/tome-1.4.9-gfx.team
and t-engine4-src-1.4.9-new/game/modules/tome-1.4.9-gfx.team differ
Binary files
t-engine4-src-1.4.9-old/game/modules/tome-1.4.9-music.team and
t-engine4-src-1.4.9-new/game/modules/tome-1.4.9-music.team differ
Binary files t-engine4-src-1.4.9-old/game/modules/tome-1.4.9.team and
t-engine4-src-1.4.9-new/game/modules/tome-1.4.9.team differ


Thanks for this analysis. I reported it upstream to know if it was
attended and if this is something common for them.


ToME's developer say that this kind of update doesn't occur often and 
that now he will warn about this.
That won't fix the problem for us but at least we will have the 
information that it's an update


http://forums.te4.org/viewtopic.php?f=42=47073=220333#p220333



Re: [New] games/tome4 (previously t-engine)

2016-12-23 Thread Solène Rapenne



Hi Solene,

while testing the update fcambus@ noticed that the checksum of the 
downloaded

file doesn't match.

I was able to confirm the same issue after moving aside my already 
downloaded

distfile from previous tests.

Did upstream silently re-roll the 1.4.9 distfile?

SHA512 (t-engine4-src-1.4.9.tar.bz2-new) =
0d527f18f9844c38478f71829d4944c3221aa0817f52ab4f44aed5990493a769e206228b367dad413bc9f111be9404db8e9e6b6f9f0e0c821ffc27c721ccc1da
SHA512 (t-engine4-src-1.4.9.tar.bz2-old) =
f604fe2e65cafb17f173c69f84af292dbd7dd8d74f43947fec3a6ced749d1c1973453ceb2f83e75025a2447b7e0bd6d822801cdfedacffa6680625b4f8ba0999

$ diff -ru t-engine4-src-1.4.9-old t-engine4-src-1.4.9-new/
Binary files t-engine4-src-1.4.9-old/game/engines/te4-1.4.9.teae and
t-engine4-src-1.4.9-new/game/engines/te4-1.4.9.teae differ
Binary files t-engine4-src-1.4.9-old/game/modules/boot-te4-1.4.9.team
and t-engine4-src-1.4.9-new/game/modules/boot-te4-1.4.9.team differ
Binary files t-engine4-src-1.4.9-old/game/modules/tome-1.4.9-gfx.team
and t-engine4-src-1.4.9-new/game/modules/tome-1.4.9-gfx.team differ
Binary files
t-engine4-src-1.4.9-old/game/modules/tome-1.4.9-music.team and
t-engine4-src-1.4.9-new/game/modules/tome-1.4.9-music.team differ
Binary files t-engine4-src-1.4.9-old/game/modules/tome-1.4.9.team and
t-engine4-src-1.4.9-new/game/modules/tome-1.4.9.team differ


Thanks for this analysis. I reported it upstream to know if it was 
attended and if this is something common for them.




  1   2   >