OpenBSD Mail Box: November 2024

Friday, November 01, 2024

Re: [new] databases/arrow 18.0.0

On 2024/11/01 10:56, Landry Breuil wrote:
> hi,
>
> following thrift, here's the port for the c++ part of arrow:
> https://github.com/apache/arrow/blob/main/cpp/README.md
> it provides the parquet library for https://parquet.apache.org/.
>
> some open questions:
> - i've put the port in databases because for me its sort-of a database
> format: "The universal columnar format and multi-language toolbox for
> fast data interchange and in-memory analytics"
>
> but it can go into devel or textproc, i'm not settled on it. devel is
> already a bit crowded...

databases sounds good

> - the toplevel in https://github.com/apache/arrow/ has zero build goo,
> so from the same distfile one has to build by subdir (eg setting
> WRKDIST=${WRKDIR}/${DISTNAME}/cpp), hence the pkgname being arrow-cpp
> since i'm only interested in the c++ part.

shouldn't that be WRKSRC=${WRKDIST}/cpp?

> should i name the port databases/arrow-cpp ? databases/arrow/cpp in
> preparation for potential other ports for various bindings ?

databases/arrow/cpp sounds a good plan to me. common parts can be
factored in Makefile.inc later when we find out what the common parts
are :)

> i'm still struggling to make it build fine the json part that depends on
> rapidjson so for now this is commented out. will keep working on it, but
> right now i have enough for testing the geoparquet support in gdal.
>
> feedback welcome ! oks too ofc :)
>
> Landry

[new] databases/arrow 18.0.0

hi,

following thrift, here's the port for the c++ part of arrow:
https://github.com/apache/arrow/blob/main/cpp/README.md
it provides the parquet library for https://parquet.apache.org/.

some open questions:
- i've put the port in databases because for me its sort-of a database
format: "The universal columnar format and multi-language toolbox for
fast data interchange and in-memory analytics"

but it can go into devel or textproc, i'm not settled on it. devel is
already a bit crowded...

- the toplevel in https://github.com/apache/arrow/ has zero build goo,
so from the same distfile one has to build by subdir (eg setting
WRKDIST=${WRKDIR}/${DISTNAME}/cpp), hence the pkgname being arrow-cpp
since i'm only interested in the c++ part.

should i name the port databases/arrow-cpp ? databases/arrow/cpp in
preparation for potential other ports for various bindings ?

i'm still struggling to make it build fine the json part that depends on
rapidjson so for now this is commented out. will keep working on it, but
right now i have enough for testing the geoparquet support in gdal.

feedback welcome ! oks too ofc :)

Landry

Re: [brad@comstyle.com: UPDATE: OpenSceneGraph - FFmpeg]

On Tue, 29 Oct 2024 12:31:48 +0000, Stuart Henderson wrote:
> REVISION needs re-bumping, but otherwise this still applies.
>
> +cc maintainer
>

Fine with me.

> ----- Forwarded message from Brad Smith <brad@comstyle.com> -----
>
> From: Brad Smith <brad@comstyle.com>
> Date: Sat, 3 Aug 2024 13:04:01 -0400
> To: ports@openbsd.org
> Subject: UPDATE: OpenSceneGraph - FFmpeg
>
> Here is a diff to fix building OpenSceneGraph with newer FFmpeg.
>
> Please test.
>
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/graphics/openscenegraph/Makefile,v
> retrieving revision 1.34
> diff -u -p -u -p -r1.34 Makefile
> --- Makefile 15 Nov 2023 17:55:22 -0000 1.34
> +++ Makefile 3 Aug 2024 16:51:08 -0000
> @@ -10,7 +10,7 @@ GH_ACCOUNT = openscenegraph
> GH_PROJECT = OpenSceneGraph
> GH_TAGNAME = OpenSceneGraph-$V
> DISTNAME = openscenegraph-${V}
> -REVISION = 5
> +REVISION = 6
>
> SUBST_VARS += V
>
> Index: patches/patch-src_osgPlugins_ffmpeg_FFmpegDecoderAudio_cpp
> ===================================================================
> RCS file: patches/patch-src_osgPlugins_ffmpeg_FFmpegDecoderAudio_cpp
> diff -N patches/patch-src_osgPlugins_ffmpeg_FFmpegDecoderAudio_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_osgPlugins_ffmpeg_FFmpegDecoderAudio_cpp 3 Aug 2024 16:51:08 -0000
> @@ -0,0 +1,83 @@
> +Fix building with newer FFmpeg
> +
> +Index: src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp
> +--- src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp.orig
> ++++ src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp
> +@@ -13,15 +13,6 @@
> + #define AVCODEC_MAX_AUDIO_FRAME_SIZE 192000
> +

Re: fix portcheck false positive about files not being installed in icons subdir

On 2024/11/01 10:06, Landry Breuil wrote:
> Le Fri, Nov 01, 2024 at 09:01:09AM +0000, Stuart Henderson a écrit :
> > less bogus whining from portcheck is good!
> >
> > > + share/icons/*.@(png|svg|svgz|icon))
> >
> > looking at pkglocate share/icons/|sed 's/^.*\.//'|sort|uniq -c|sort -nr,
> > could you add xpm and ico please?
>
> sure for ico, but i havent added xpm because it's handled just above, as
> iirc they should go to pixmaps subdir ?

ah ok :)

> share/icons/*.xpm)
> app=${l#share/icons/}
> app=${app%%/*}
> app=${app%%.*}
> err "${portref}installs icon ${l##*/} in ${l%/*}, it" \
> "should likely go in share/pixmaps/ instead"
>
> Landry
>

Re: fix portcheck false positive about files not being installed in icons subdir

Le Fri, Nov 01, 2024 at 09:01:09AM +0000, Stuart Henderson a écrit :
> less bogus whining from portcheck is good!
>
> > + share/icons/*.@(png|svg|svgz|icon))
>
> looking at pkglocate share/icons/|sed 's/^.*\.//'|sort|uniq -c|sort -nr,
> could you add xpm and ico please?

sure for ico, but i havent added xpm because it's handled just above, as
iirc they should go to pixmaps subdir ?

share/icons/*.xpm)
app=${l#share/icons/}
app=${app%%/*}
app=${app%%.*}
err "${portref}installs icon ${l##*/} in ${l%/*}, it" \
"should likely go in share/pixmaps/ instead"

Landry

Re: fix portcheck false positive about files not being installed in icons subdir

less bogus whining from portcheck is good!

> + share/icons/*.@(png|svg|svgz|icon))

looking at pkglocate share/icons/|sed 's/^.*\.//'|sort|uniq -c|sort -nr,
could you add xpm and ico please?

ok.

fix portcheck false positive about files not being installed in icons subdir

hi,

i never use portcheck, but i've been told this report on
elementary-xfce-icon-theme which is obviously a false positive for me:

$/usr/ports/infrastructure/bin/portcheck
installs icon AUTHORS in share/icons/elementary-xfce-dark, it should go in share/elementary-xfce-dark/icons/ or like instead
installs icon CONTRIBUTORS in share/icons/elementary-xfce-dark, it should go in share/elementary-xfce-dark/icons/ or like instead
installs icon LICENSE in share/icons/elementary-xfce-dark, it should go in share/elementary-xfce-dark/icons/ or like instead
installs icon README.md in share/icons/elementary-xfce-dark, it should go in share/elementary-xfce-dark/icons/ or like instead
installs icon AUTHORS in share/icons/elementary-xfce, it should go in share/elementary-xfce/icons/ or like instead
installs icon CONTRIBUTORS in share/icons/elementary-xfce, it should go in share/elementary-xfce/icons/ or like instead
installs icon LICENSE in share/icons/elementary-xfce, it should go in share/elementary-xfce/icons/ or like instead
installs icon README.md in share/icons/elementary-xfce, it should go in share/elementary-xfce/icons/ or like instead

the diff below 'fixes' it for me, i've taken the list from what i've found as
most regular file types/patterns for icons found in pkglocatedb:

RCS file: /cvs/ports/infrastructure/bin/portcheck,v
diff -u -r1.147 portcheck
--- bin/portcheck 10 Jun 2024 05:10:08 -0000 1.147
+++ bin/portcheck 1 Nov 2024 08:46:46 -0000
@@ -1037,7 +1037,7 @@
;;
share/icons/default.*)
;;
- share/icons/*)
+ share/icons/*.@(png|svg|svgz|icon))
app=${l#share/icons/}
app=${app%%/*}
app=${app%%.*}

note that the pattern constructed at line 1022 seems odd (first pipe without braces ?)

share/icons/*/*/*|share/icons/*/@(index.theme|iconrc?(-png)))

oks welcome.

Re: math/lapack,-cblas,-blas,-docs

> -COMMENT= library of Fortran linear algebra subroutines
> -DPB_PROPERTIES= parallel
> +COMMENT-main = library of Fortran linear algebra subroutines
> +COMMENT-blas = Basic Linear Algebra Subprograms
> +COMMENT-cblas = C interface to BLAS
> +COMMENT-docs = maunal pages for BLAS/LAPACK
>
> -VERSION= 3.8.0
> -DISTNAME= lapack-${VERSION}
> -REVISION= 2
> +PKGNAME-main = lapack-${V}
> +PKGNAME-blas = blas-${V}
> +PKGNAME-cblas = cblas-${V}
> +PKGNAME-docs = lapack-man-${V}

Is there a need to split it up? Now that the build is combined,
putting them in a single package would make sense to me, and would
simplify things.

Re: Minimum supported chipsets of amd64

On 10/30/24 23:21, Anon Loli wrote:
> On Tue, Oct 29, 2024 at 12:26:54PM +0100, Christian Schulte wrote:
>> On 10/28/24 22:53, Anon Loli wrote:
>>> On Mon, Oct 28, 2024 at 05:35:47PM +0100, Christian Schulte wrote:
>>>> On 10/24/24 03:01, Mike Larkin wrote:
>>>>>
>>>>> Every one of us who has worked in this area, at this level, has read those
>>>>> 800+ page documents. Sometimes they are many thousands of pages (eg the latest
>>>>> Intel SDM or latest ACPI spec).
>>>>>
>>>>> Tell us what you are doing and what you want to know and maybe we can point
>>>>> you to the right docs, but there is no short-cutting reading the reference
>>>>> manuals.
>>>>>
>>>>
>>>> I would really like to understand why this architecture stood the test
>>>> of time. Just because it boots in 8 bit CPU mode from the 70ties not
>>>> even capable of beating a 6502? Just because developers were not
>>>> continuously forced to throw away all knowledge and could build upon it?
>>>> Seems to be the reason. Intel tried to throw away legacy burdens and got
>>>> set straight by AMD. I am currently approaching page 4000 of
>>>> documentation. Shaking heads. Unbelievable. What I am lacking so far is
>>>> a current PCI bus specification. This seems to not be available to non
>>>> members who I am certainly not. Coming from a hardware background,
>>>> documents like this
>>>>
>>>> <https://www.intel.sg/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf>
>>>>
>>>> clearly were a waste of time, at least when your goal is not to produce
>>>> mainboards. Well. Normally you would program devices directly. It even
>>>> contains write-once-by-firmware registers. It will take some time for me
>>>> to understand the reasoning behind this. Not questioning there are no
>>>> reasons for doing it that way. I am just trying to make me stop hating
>>>> that architecture. I am still failing at this task but I would like to
>>>> overcome this. At least it has linear address space. Oh. What a wonder.
>>>> Every 68k had this decades ago. Oh sorry. Your comments are very helpful
>>>> to me so far so thank you. Because the machine independent parts in the
>>>> kernel really are abstractions of formerly machine dependent parts,
>>>> understanding the worst case of those - namely x86 and amd64 - will help
>>>> me understand those. I am still in the process of reading x86/amd64
>>>> documentation even if it make me shake my head every so often.
>>>>
>>>> Regards,
>>>> --
>>>> Christian
>>>
>>> I just wrote a whole big-ass e-mail about how hardware has been shit for
>>> decades now.
>>> I do not feel like rewriting all of it right now.... it was a genius e-mail.
>>>
>>> I fucking hate when my e-mail client goes bananas because it's terminal based.
>>> Fuck escape sequences and stupid retarded Unix.
>>> When do escape sequences actually work as intended? When?
>>>
>>> Anyways suckless.org rocks, and should be implied to hardware.
>>>
>>> Open Source is Insufficient to Solve Trust Problems in Hardware
>>> https://youtube.com/watch?v=Hzb37RyagCQ
>>>
>>> How do you know the hardware in front of you actually conforms to the hardware
>>> design you might or might not have?
>>> You can't, it's not like software, at least you can't with existing hardware,
>>> watch the video.
>>>
>>> Mud towers build on mud foundation are still mud and will collapse under mud.
>>>
>>> This was more-less the important stuff
>>> Fuck I hate re-writing emails fuck me!
>>>
>>
>> Fuck. Ass. Genius. You maybe want to watch the Youtube Channels of Ben
>> Eater [1] or James Sharman [2] for a starting point talking about
>> hardware and how to build a CPU from scratch using bread boards. Fuck.
>> Ass. Genius. Then start reading about what microelectronics is about or
>> even get a degree in microelectronics. Fuck. Ass. Genius.
>>
>> [1] <https://www.youtube.com/@BenEater/playlists>
>> [2] <https://www.youtube.com/@weirdboyjim/playlists>
>>
>> --
>> Christian
>
> Since I am autistic, I have trouble understanding when exactly someone is
> making fun of me or what tone they are using, especially trough text.

According to the messages you sent here this far, I pretty much doubt
you are suffering autism.

> For the sake of friendliness I shall assume that you said all of that in good
> spirit and were not condescending.

Everyone on these lists here will be friendly. You appear really rude. I
just used kind of the same words you are using. If this makes you feel
uncomfortable or even irritates you, what do you think those same words
make others feel about you?

> Fuck stupid retarded Unix.

Very nice posting this here. Thank you.

> Since I extremely-extremely love problem solving - creating and debugging
> hardware ought to be fun!

Then just brew your own circuits in your kitchen with a density of 5nm
and tell us how many silicon atoms you could fit on your designs.

--
Christian

sysutils/firmware/amdsev: Missing path in PLIST

Hi,

Add 'firmware/amdsev/' to PLIST, which was found by sysclean(8).

Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/sysutils/firmware/amdsev/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 29 Oct 2024 20:10:29 -0000 1.1.1.1
+++ pkg/PLIST 1 Nov 2024 08:26:00 -0000
@@ -1,4 +1,5 @@
firmware/amd-sev-license
+firmware/amdsev/
firmware/amdsev/amd_sev_fam17h_model0xh.sbin
firmware/amdsev/amd_sev_fam17h_model3xh.sbin
firmware/amdsev/amd_sev_fam19h_model0xh.sbin

[new] devel/thrift

hi,

here's a port for https://thrift.apache.org/, a dependency for arrow
that i need to enable geoparquet support in geo/gdal. ports-wise, i only
enabled what i needed, eg the c/c++ bits, the python/qt/js/nodejs bits
are disabled (npm...)

oks welcome

Landry

Re: [brad@comstyle.com: UPDATE: OpenSceneGraph - FFmpeg]

Tested on amd64 with current ffmpeg. OK rsadowski

On Tue Oct 29, 2024 at 12:31:48PM +0000, Stuart Henderson wrote:
> REVISION needs re-bumping, but otherwise this still applies.
>
> +cc maintainer
>
>
> ----- Forwarded message from Brad Smith <brad@comstyle.com> -----
>
> From: Brad Smith <brad@comstyle.com>
> Date: Sat, 3 Aug 2024 13:04:01 -0400
> To: ports@openbsd.org
> Subject: UPDATE: OpenSceneGraph - FFmpeg
>
> Here is a diff to fix building OpenSceneGraph with newer FFmpeg.
>
> Please test.
>
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/graphics/openscenegraph/Makefile,v
> retrieving revision 1.34
> diff -u -p -u -p -r1.34 Makefile
> --- Makefile 15 Nov 2023 17:55:22 -0000 1.34
> +++ Makefile 3 Aug 2024 16:51:08 -0000
> @@ -10,7 +10,7 @@ GH_ACCOUNT = openscenegraph
> GH_PROJECT = OpenSceneGraph
> GH_TAGNAME = OpenSceneGraph-$V
> DISTNAME = openscenegraph-${V}
> -REVISION = 5
> +REVISION = 6
>
> SUBST_VARS += V
>
> Index: patches/patch-src_osgPlugins_ffmpeg_FFmpegDecoderAudio_cpp
> ===================================================================
> RCS file: patches/patch-src_osgPlugins_ffmpeg_FFmpegDecoderAudio_cpp
> diff -N patches/patch-src_osgPlugins_ffmpeg_FFmpegDecoderAudio_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_osgPlugins_ffmpeg_FFmpegDecoderAudio_cpp 3 Aug 2024 16:51:08 -0000
> @@ -0,0 +1,83 @@
> +Fix building with newer FFmpeg
> +
> +Index: src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp
> +--- src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp.orig
> ++++ src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp
> +@@ -13,15 +13,6 @@
> + #define AVCODEC_MAX_AUDIO_FRAME_SIZE 192000
> +