On Mon, 3 Oct 2022, Alexandre Ratchov wrote:
On Sun, Sep 25, 2022 at 04:17:06PM +, adr wrote:
This patch does that, following the alsa and oss drivers.
I CC'd it to ports@
could you provide a quick hint on how to test it? I rebuild xine-lib
(add a debug printf to make sure changes
first if not from the maintainer, at least
from some other dev, so I'll try again: any thoughts?
On Sun, 25 Sep 2022, adr wrote:
Date: Sun, 25 Sep 2022 16:17:06 + (UTC)
From: adr
To: m...@openbsd.org
Cc: ports@openbsd.org
Subject: Re: xine's ffmpegaudio doesn't downmix,
sio_getpar
On Thu, 22 Sep 2022, adr wrote:
Hi,
first of all, I've never contributed to the xine project, and
I don't have any experience with sndio, so bear with me...
Frustrated with the bad sound playing a 6 channels aac audio I decided to
take a look. The device is a usb one:
$ dmesg | grep -i audio
On Tue, 1 Mar 2022, Stuart Henderson wrote:
Date: Tue, 1 Mar 2022 18:08:39 +
From: Stuart Henderson
To: adr
Cc: ports@openbsd.org
Subject: Re: Add u-boot-tools flavor
On 2022/03/01 16:18, adr wrote:
On Tue, 1 Mar 2022, Stuart Henderson wrote:
I suggest doing this as a separate port
On Tue, 1 Mar 2022, Stuart Henderson wrote:
I suggest doing this as a separate port.
That was my first intention but somehow I thought it would be easer
to mantain keeping it in the same port. If you (the developers,
specially the arm ones) think this is better I could write another
port when
Hi,
this patch adds a flavor to sysutils/u-boot so tools like mkimage
can be installed in openbsd.
https://u-boot.readthedocs.io/en/latest/build/tools.html
Regards,
adr.
==
Index: Makefile
M)),)
ARCHITECTURE := _arm64_clang
else
ARCHITECTURE := _x86_clang
endif
endif
endif
endif
[...]
Even correcting this, CLANG_VERSION is not detected because grep
is using gnu basic regular expression syntax, in openbsd BRE there
is no + nor ? [re_format(7)].
Here is a diff only tested on arm64.
I left ou
I've been using it for a while, I only see improvements. Maybe someone
wants to try it.
https://sourceforge.net/projects/xine/files/xine-ui/0.99.13/
xine-ui (0.99.13)
* Add audio control window.
* Add some menu shortcuts.
* Add build optimizations.
* Better keyboard and mouse wheel
Hi,
Xine can't play ac3 audio correctly (anyone I've tried) with ffmpeg.
Compiling it with the internal a/52 solves the problem (the ports'
liba52 is incompatible, xine will end up using the internal anyway).
Just add --enable-a52dec=internal and update PLIST.
Regards,
adr.
On Thu, Jan 14, 2021 at 07:48:02PM -0500, Brad Smith wrote:
> This is missing patch removals. Here is a more appropriate diff..
Oh, sorry about that...
(hdmv mode, detection of cut TV recordings).
* Fix mpeg layer 1-4 audio timing.
* Fix some VDR issues.
* Fix HLS VOD mode.
* Many small fixes.
* Build fixes.
* BSD fixes.
* Update german translation.
* Update internal libdca to upstream 0.0.7.
Regards,
adr.
? multimedia_xine-lib.diff
I applied your corrections.
Regards,
adr.
devel_stlink.tgz
Description: application/tar-gz
Hi, thanks for the feedback.
On Mon, Oct 26, 2020 at 05:39:35PM +, Stuart Henderson wrote:
> : post-build:
> : @cd ${WRKBUILD}/bin/; strip -s st-flash st-info st-util stlink-gui
>
> Don't unconditionally strip, this should only be done under control of
> ports. Normally this is handled
chip to translate commands from USB to JTAG/SWD."
I could separate the gui in another package or use flavors if there
is any interest in the port.
I'm not offering myself as the maintainer because I'm not a cmake
user.
Regards,
adr.
devel_stlink.tgz
Description: application/tar-gz
m port doesn't use opengl
better to disable it. Those unaligned problems can be very tricky,
as you will see with your new board. I will take a look if I find
time.
Regards,
adr
Hi Brad,
we talked about this last year (and tested some other codecs).
Can you apply this?
Regards,
adr.
==
multimedia/x264:
--- Makefile.orig Thu Oct 15 09:02:38 2020
+++ MakefileThu Oct 15 09:04:07 2020
@@ -42,7 +42,8
a reason to try to fix it now.
Regards,
adr.
--- Makefile.orig Thu Oct 15 09:50:24 2020
+++ MakefileThu Oct 15 20:08:12 2020
@@ -54,9 +54,11 @@
CONFIGURE_ARGS+= --disable-atomic
.endif
-# clang can't handle simd asm
.if ${MACHINE_ARCH} == "arm"
o blacklist ports in the bulk build system?
Just for curiosity, what machine are you using to build the armv7
packages?
adr.
-d 1048576
but maybe just around 600M will be sufficient.
I had to shave twice before it finished, but it compiled.
I will try in the future disabling just FP16 intrinsics with
-U__ARM_FP16_FORMAT_IEEE
Regards,
adr.
.
Looking at the code, just documenting this seems to be the best
option.
End of my monologue.
adr
, so I suppose it's just me.
Regards,
adr.
the more sensible aproach to me is just to use another
character for command separation, but that would be a big change for
this venerable companion...
Or maybe I'm just missing something and the best option is just to
ignore me.
Regards,
adr
I forgot to update the length of the new string.
$OpenBSD$
Index: ex/ex_source.c
--- ex/ex_source.c.orig
+++ ex/ex_source.c
@@ -38,8 +38,8 @@ int
ex_source(SCR *sp, EXCMD *cmdp)
{
struct stat sb;
- int fd, len;
- char *bp;
+ int fd, len,
I found that '|' can't be used in exrc files, unless a 0x16 precedes
it. This is what the code does in seq.c. The problem is in both
editors/nvi and base.
This is a dirty hack if someone is interested. It's for editors/nvi,
but for base would be almost identical.
adr
brary uses unaligned access
for performance reasons.
So the only reason I see here is the canary in the coal mine. But you
are cutting legs and stapling wings to this poor bastard...
That is my opinion.
Now let me out of this.
Please.
adr.
Pay attention, it's not legacy, there are real actual reasons to do that.
Read again thru Theo's mail, carefully.
Pay attention, this wasn't a response to Theo's mail.
Hello,
I found a little annoying having to install vim to compile
netsurf. If you like you can try this patch, and maybe make it
less ugly, I'm not a make expert.
By the way, I've compiled netsurf on armv7. It works good.
Regards,
adr
$OpenBSD
it
was in a private mail, was to talk to some developer of the arm
port because I knew that this wasn't an small issue.
Regards,
adr
It's not clear to me that assembly code is the culprit here.
No, I bet it is their memory managment functions.
I agree with Stuart's statement. It may be terse but I don't find it
pedantic.
And I agree too, that's why I found it pedantic.
Any way, I'm out of place here.
Switching a bunch of ports to gcc is not the answer.
The answer is to talk with the developers of each of these ports
and show them the problems they'll find with llvm, so maybe they
re-implement the assembly optimization following the ARM conventions.
That was my advice to the ffmpeg and x264
unaligned. You are going to have a
lot of these problems porting assembly from gas to llvm, specially
with old code.
Regards,
adr.
echo unsigned int $name_len = $len ;
upps!, just in case: ${name}_len
int $name_len = $len ;
hexdump is in base.
Regards,
adr.
On Sun, 11 Aug 2019, Anthony J. Bentley wrote:
Date: Sun, 11 Aug 2019 09:16:22 -0600 (MDT)
From: Anthony J. Bentley
To: ports-changes@openbsd.org
Subject: CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Hello,
multimedia/x264 assembly will generate bus errors.
Tested with ffmpeg.
Regards,
adr.
RCS file: /cvs/ports/multimedia/x264/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- Makefile22 Jul 2019 06:56:33 - 1.51
bet the problem is in their memory management: source/fitz/memory.c.
Good luck!
adr.
$ mupdf somefile.pdf
Bus error (core dumped)
$ gdb mupdf mupdf-x11.core
[...]
(gdb) bt
#0 0x07e332dc in fz_paint_glyph () from /usr/local/bin/mupdf
#1 0x in ?? ()
(gdb) disassemble
Dump of assembler
problems
making my own assembly work in llvm|OpenBSD.
Regards,
adr.
I've tested 1.16.0. You still need to compile it with
gcc.
adr.
I've compiled ffmpeg with ports-gcc, and all is working
as expected. The performance is much better than disabling
neon with llvm. I strongly recommend you to change the port
to use gcc on this arch.
Regards,
adr.
On Tue, 30 Jul 2019, Stuart Henderson wrote:
Date: Tue, 30 Jul 2019 14:18:36 +0100
From: Stuart Henderson
To: adr
Cc: ports@openbsd.org
Subject: Re: mupdf on arm
On 2019/07/30 14:00, Stuart Henderson wrote:
On 2019/07/30 11:03, adr wrote:
Mupdf needs to be compiled with gcc on armv7
,<9 to LIB_DEPENDS and make plist.
adr.
and 3.7)
to be able to compile it.
Tested in 6.5 and current, on armv7 (allwinner h3).
I've been using openbsd just for a few days, so I'll
let someone with more (any) experience to fixed it in the
best way.
adr.
41 matches
Mail list logo
