> Looks like that's not enough, I happened to look at the screen at
> just the right time and noticed some undefined symbol errors from ld.lld
> relating to dav1d scrolling past while it was building.
>
> Next attempt is with this diff, results in the morning probably.
oh, build was quicker than
On 2024/09/23 23:08, Stuart Henderson wrote:
> On 2024/09/23 23:21, Theo Buehler wrote:
> > In addition to what sthen posted, I ran into these, the first one smells
> > like a noexeconly issue. Not sure about the second one (I modified kdump
> > to print the trap as hexadecimal since I got tired of
On 2024/09/23 23:21, Theo Buehler wrote:
> In addition to what sthen posted, I ran into these, the first one smells
> like a noexeconly issue. Not sure about the second one (I modified kdump
> to print the trap as hexadecimal since I got tired of translating
> decimal to hex)
The files in ports/mu
On Mon, Sep 23, 2024 at 09:50:04PM +0100, Stuart Henderson wrote:
> Does that want @sample'ing somewhere or is it just something you
> need to source into a .muttrc?
As far as I can see, it's a fragment of a muttrc designed to be included, or
copied/adapted.
The Makefile wanted to install it in /
In addition to what sthen posted, I ran into these, the first one smells
like a noexeconly issue. Not sure about the second one (I modified kdump
to print the trap as hexadecimal since I got tired of translating
decimal to hex)
67550 firefox PSIG SIGSEGV caught handler=0x2027faaeb8 mask=0<>
co
I'll wait for a bit more input, then I'd be happy to commit this
and bring it into release.
> > On 2024/09/23 20:26, Stuart Henderson wrote:
> > > This is done in a content process:
> > >
> > > firefox(1142): pledge sysctl 2: 7 3
> > > firefox[1142]: pledge "", syscall 202
> > >
> > > Looking at sys/arch/arm64/include/cpu.h I think this translates to
> > > machdep.id_aa64isar1 (I tried
Theo Buehler wrote:
> On Mon, Sep 23, 2024 at 03:01:17PM -0600, Theo de Raadt wrote:
> > Does this help?
> >
> > Since we are close to release, I'm intentionally making it a seperate
> > block, and we can trust the compiler's common-subexpression-elimination
> > to clean it up. If there was a 3
On Mon, Sep 23, 2024 at 03:01:17PM -0600, Theo de Raadt wrote:
> Does this help?
>
> Since we are close to release, I'm intentionally making it a seperate
> block, and we can trust the compiler's common-subexpression-elimination
> to clean it up. If there was a 3rd entry we would make it a switc
Does this help?
Since we are close to release, I'm intentionally making it a seperate
block, and we can trust the compiler's common-subexpression-elimination
to clean it up. If there was a 3rd entry we would make it a switch().
Index: kern_pledge.c
==
Stuart Henderson wrote:
> > Managed to capture some ktrace -di by pointing it at the running main proc
> > after startup and reloading the tab. Instead of getting killed by pledge, I
> > get a SIGILL instead, trapped by firefox's handler.
> >
> > 23282 firefox PSIG SIGILL caught handler=0xc804ce
On 2024/09/23 21:42, Edd Barrett wrote:
> Hi,
>
> This diff adds a subpackage to notmuch to install the mutt integration.
>
> Seems to work well. The search functionality is very similar to `mu find
> --format=links`, if you are already familiar with that.
>
> Comments, OK?
>
>
> Index: Makefi
On 2024/09/23 20:26, Stuart Henderson wrote:
> This is done in a content process:
>
> firefox(1142): pledge sysctl 2: 7 3
> firefox[1142]: pledge "", syscall 202
>
> Looking at sys/arch/arm64/include/cpu.h I think this translates to
> machdep.id_aa64isar1 (I tried running it under ktrace but I ju
Hi,
This diff adds a subpackage to notmuch to install the mutt integration.
Seems to work well. The search functionality is very similar to `mu find
--format=links`, if you are already familiar with that.
Comments, OK?
Index: Makefile
===
On 2024/09/23 21:24, Stuart Henderson wrote:
> On 2024/09/23 20:26, Stuart Henderson wrote:
> > This is done in a content process:
> >
> > firefox(1142): pledge sysctl 2: 7 3
> > firefox[1142]: pledge "", syscall 202
> >
> > Looking at sys/arch/arm64/include/cpu.h I think this translates to
> > m
This is done in a content process:
firefox(1142): pledge sysctl 2: 7 3
firefox[1142]: pledge "", syscall 202
Looking at sys/arch/arm64/include/cpu.h I think this translates to
machdep.id_aa64isar1 (I tried running it under ktrace but I just get
very fast-running fans and a frozen machine).
Will
On Mon, 23 Sep 2024 18:08:46 +0200,
Stuart Henderson wrote:
>
> IIRC the build/lib.openbsd-${OSREV}-... format is just for setuptools,
> so it may be better to define a new variable containing the directory
> name and set it as appropriate for each MODPY_PYBUILD backend.
> (They don't need to be d
Hi,
zipnote command currently fails:
$ zipnote test.zip > test.tmp
$ zipnote -w test.zip < test.tmp
zipnote error: Bad file descriptor
zipnote error: Temporary file failure (zi5N73U4)
$
Patch this by back-porting fix from zip 3.1b seems to fix it.
Timo
diff /usr/ports
commit - 8fa0c6f48793582a
OK for main and stable post the relevant unlocks.
(Note that -stable unlocks _after_ the main tree is open).
On 2024/09/23 18:35, Volker Schlecht wrote:
> Here's the fixed diff.
>
> On 2024-09-23 11:31, Stuart Henderson wrote:
> > Patches need regenerating.
> >
> > What's the reason for the bump
Here's the fixed diff.
On 2024-09-23 11:31, Stuart Henderson wrote:
Patches need regenerating.
What's the reason for the bump? I don't see new functions in the
libraries (but haven't ooked for struct changes). Library bumps in
-stable are problematic.
On 2024/09/23 00:32, Volker Schlecht wrote
On 2024/09/23 17:43, Kirill A. Korinsky wrote:
> On Tue, 03 Sep 2024 18:31:56 +0200,
> Kirill A. Korinsky wrote:
> >
> > I had dig into archivers/py-zstandard (a couple moths ago) and if I recall
> > right the cause of issue was inside zstandard/__init__.py it uses:
> >
> > from .backend_c imp
On Tue, 03 Sep 2024 18:31:56 +0200,
Kirill A. Korinsky wrote:
>
> I had dig into archivers/py-zstandard (a couple moths ago) and if I recall
> right the cause of issue was inside zstandard/__init__.py it uses:
>
> from .backend_c import *
>
> which is a root cause for this issue because . mea
This seems like something that might make sense to get in for release
if someone with an affected system (with vlc defaults i.e. hw accel
set to automatic) can get it tested quickly enough.
On 2024/09/23 00:14, Brad Smith wrote:
> On Fri, Sep 20, 2024 at 04:21:29PM +0100, Stuart Henderson wrote:
>
(this could probably do with DPB_PROPERTIES=parallel too)
On 2024/09/23 11:31, Stuart Henderson wrote:
> Patches need regenerating.
>
> What's the reason for the bump? I don't see new functions in the
> libraries (but haven't ooked for struct changes). Library bumps in
> -stable are problematic.
That would probably be better done after release builds are running.
On 2024/09/22 07:55, Rafael Sadowski wrote:
> Could some throw this into a bulk build please?
>
> The entire Qt5/Qt6 ecosystem depends on FFmpeg API >= 5.
>
> Thanks!
>
> On Sat Aug 03, 2024 at 03:15:08PM GMT, Brad Smith wrote
Patches need regenerating.
What's the reason for the bump? I don't see new functions in the
libraries (but haven't ooked for struct changes). Library bumps in
-stable are problematic.
On 2024/09/23 00:32, Volker Schlecht wrote:
> Fixes
>
> CVE-2024-46951
> CVE-2024-46952
> CVE-2024-46953
> CVE-2
On Sun, 22 Sep 2024 23:56:28 +0200,
Kirill A. Korinsky wrote:
>
> But I not sure that it worth to make it because the project is archived,
> and both forks with some stars on github is on the same state.
>
I'd like to add that seems that Tox Handshake is Vulnerable to KCI
https://github.com/Tok
27 matches
Mail list logo
