Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2024/05/08 01:14, Volker Schlecht wrote:
> > > aisha@ identified a rather recent problem with lang/node, as in the
> > > following
> > > would immediately crash (nevermind the node version. It'
Stuart Henderson wrote:
> On 2024/05/08 01:14, Volker Schlecht wrote:
> > aisha@ identified a rather recent problem with lang/node, as in the
> > following
> > would immediately crash (nevermind the node version. It's 100% reproducible
> > in 7.5 and -current):
> >
> > $ node
> > Welcome to
Lennart Jablonka wrote:
> Quoth Landry Breuil:
> >Le Thu, Mar 28, 2024 at 02:52:52PM +, Lennart Jablonka a écrit :
> >> I’m trying to get himitsu-firefox¹ working on OpenBSD. It’s a Firefox
> >> extension that talks to a daemon² using “native messaging”: The extension
> >> calls
Thomas Dettbarn wrote:
> I know sir.
> My apologies.
>
> What I actually meant to say was
>
> "Please, Sirs, somebody check the port! I am not qualified enough to
> do so myself."
That is why it was mailed out. So that people could review it.
The peanut gallery who isn't going to review,
Thomas Dettbarn wrote:
> Hello.
>
>
> Yeah... You know how the social engineering part of this xz
> backhole was done?
>
> Somebody pressured the Maintainer, that he needs to add new
> features.
>
> Afterwards, the maintainers of distributions were pressured to
> update, because there were
With a bit of effort, the address you see:
addr=0x67cb1d220
can be compared in the ktrace to earlier mmap() operations (done by the
shared library linker ld.so); those mmap are mappings against a file descriptor,
and you can see what library file ld.so opened just previously... then we know
Crazy. Looks good.
Mark Kettenis wrote:
> This one was a bit tricky as I had to adjust the offsets used in the
> instructions. But with this lang/guile3 no longer generates SIGILL
> when running the tests.
>
> ok?
>
>
> Index: devel/libffi/Makefile
>
This is because the fbtab subsystem is quite broken. No good
alternative designs have come forward.
Stefan Hagen wrote:
> beecdadd...@danwin1210.de wrote (2024-02-26 22:54 CET):
> > libEGL warning: failed to open /dev/dri/card0: Permission denied
>
> You can fix it with: chown /dev/dri/card0
Christopher Zimmermann wrote:
> Thanks for your feedback guys. I tried to improve the interface by
> calling the hook for each challenge challenge individually and send
> information from acme-client via environment variables, which are
> checked against a restrictive alphabet. This makes
> populated by the acme-client hook and cleared after authorization.
> nsd can reload zonefiles on SIGHUP.
Sending the signal requires privs. What's the plan?
Jonathan Schleifer wrote:
> Fixed upstream:
> https://objfw.nil.im/info/262baf76e7e66bc4
> https://objfw.nil.im/info/d73a388ecaf73b2a
>
> New release:
> https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz
> https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz.sig
>
> Am 24.02.24 um 22:17 schrieb
That is a missing BTI instruction. Next package snapshot fixes it.
Mikhail wrote:
> core:~$ sysctl kern.version
> kern.version=OpenBSD 7.5-beta (GENERIC.MP) #22: Fri Feb 23 19:29:07 MST 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Latest packages.
>
>
Looks good enough. (I mean good enough for those two stupid ports)
Florian Obser wrote:
> On 2024-02-20 22:32 +01, Christopher Zimmermann wrote:
> > Hi,
> >
> > this diff adds a challenge hook to acme-client. This hook can be used
> > to fulfill challenges. For example by putting the requested files onto
> > a remote http server (http-01 challenge) or by
Rafael Sadowski wrote:
> I see the same illegal instruction with the latest packages and latest
> base:
>
> fuckup$ hugo
> Illegal instruction (core dumped)
>
> fuckup$ dmesg | head -1
> OpenBSD 7.5-beta (GENERIC.MP) #7: Tue Feb 20 11:09:18 MST 2024
>
> ktrace:
>
> 92986 hugo CALL
>
t least give me that
> at least tell me is this how things stand FD-wise/limit-wise/whatever, you
> probably know the best out of all I e-mailed with
>
> no attempt yet,in future I hope,it's not a I am too lazy reason
>
> On Tue, January 30, 2024 3:58 pm, Theo de Raadt wrote:
> > beec
beecdadd...@danwin1210.de wrote:
> I know system shares all resources including FDs
> as far as I know there's what kernel/OS needs and is using and the rest of
> users including but not limited to staff and daemon users/programs like i2pd
> all I was wondering is the limit or amount of FDs and
beecdadd...@danwin1210.de wrote:
> maybe not automatically, but having a utility that does this for you and you
> can run it once after each hardare change to find out, but I am not sure you
> say it depends on use-case, I do not understand what you mean
>
> if you read my earlier replies, you
> wouldn't cause crashes (I assume that's what happens when system runs out of
> file descriptors I read it)
>
> - best regards, didn't sleep who sleeps these days?
>
> On Sun, January 28, 2024 8:21 pm, Theo de Raadt wrote:
> > beecdadd...@danwin1210.de wrote:
> &g
beecdadd...@danwin1210.de wrote:
> why are yo uignoring my reply? 4096 doesn't cover everyone like I said people
> can become floodfills automatically and floodfills means 8192
the 1 person who cares can change the default.
> To my understanding it's an old BSDism and it's used to implement
> isupper(3), islower(3), etc.
The names may be old BSD, but this is following a pretty strong ISO rule
that names starting with '_' are in reserved, and trying to use them
yourself is undefined.
Changing them to another name
I think it is funny how exceedingly precise we are being in .S files
to not place *one extra dangerous bti* instruction.
Meanwhile, the C compilers don't know what will happen, so they slam
unused bti all over the place! But that's why we hope purging these
at link time, as "mold" now does, is
Theo Buehler wrote:
> > security/pivy configure: cannot compute sizeof (int)
>
> A function call while compiled with -fzero-call-used-regs=all runs into
> retguard. Downgrading to -fzero-call-used-regs=used makes it work.
this suggests that zero-call-used-regs is broken and
you would need to talk to socat upstream, because in general the ports
team do not add features
Luca Di Gregorio wrote:
> I would like to set a point to point interface encapsulating packets via
> UDP.
>
> It would be like a point to point wireguard but:
> - without authentication (I can set
+Beware this may allow the user unintended access to other hardware
+associated to the same usb(4) controller, so do this with extreme
+caution.
Can you explain what extreme caution means?
Stuart Henderson wrote:
> On 2023/11/09 11:38, Landry Breuil wrote:
> > The wordexp() use is awkward so i've replaced it by an ugly handrolled
> > lookup for configs in:
> > - $HOME/.sway{idle,lock}/config
> > - $XDG_CONFIG_HOME/sway{idle,lock}/config
> > - $HOME/.config/sway{idle,lock}/config
On amd64, this makes no sense because we don't use stack protector.
It is retguard. So something smells, it is like their handwritten
context switcher wasn't handling the full context before. But that
might only matter if it unrolls via two seperate methods, or if a
new function above has
Chris Narkiewicz wrote:
> TL;DR, the writing is on the wall
The writing has been on the wall a very long time that some people believe
their role in the ecosystem is to reduce software choice and push everyone
into vertical software monocultures.
Renaud Allard wrote:
> On 30/09/2023 16:32, Theo de Raadt wrote:
> > I'll try to summarize my point.
> >
> > When less-secure AND more-secure pieces of software exist in the
> > the same role/service area, I think it is valid for developers who
> > care
I'll try to summarize my point.
When less-secure AND more-secure pieces of software exist in the
the same role/service area, I think it is valid for developers who
care about security of their userbase to *DEMOTE* the less-secure
variations.
This kind of "hide the garbage" policy needs to exist
Right, it is not the first time.
Will it be the last time?
Doubtful.
If it won't be the last time, will the next time be just as bad?
For sure, because there is no security architecture in it.
po...@phosphorus.com.br wrote:
> Unfortunately I like/use exim for years - pretty simple config file syntax.
Yes, you like unsafe software.
> https://seclists.org/oss-sec/2023/q3/254
>
> So... I suppose those fixes were shared also with Exim's OpenBSD manteiners?
Wow. Are you not listening?
Stuart Henderson wrote:
> 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.
That's almost too kind.
> And also consider whether we want to keep this in ports at all...
>
Thank you for locking ports.
To help prepare for this, I am now locking base + X ABI.
Mark Kettenis wrote:
> > From: Theo de Raadt
> > Date: Thu, 14 Sep 2023 01:02:14 -0600 (MDT)
> >
> > I do not think this should be enabled.
> > Our stacks work differently.
> > We don't put shit near the bottom of the main stack, because we
> > res
I do not think this should be enabled.
Our stacks work differently.
We don't put shit near the bottom of the main stack, because we
reserve the space.
For pthread stacks, we allocate them randomly also so you cannot
determistically trash a specific object.
This change also make very small stacks
If you use unveil() without pledge(), you do not get the
special-case-file-exposures-for-libc behaviours that pledge() brings.
You are then responsible for all path exposure.
Morgan Aldridge wrote:
> On Mon, Aug 7, 2023 at 3:57 AM Landry Breuil wrote:
>
> > Le Sat, Aug 05, 2023 at 07:41:12PM
> yes, -current has it enabled now. But in order to catch those problems
> you'll need a CPU that supports it, too ... on amd64 that would be
> Tiger Lake(?) and later. I think.
it is any "laptop / desktop" cpu from gen11 onwards, which is most things
in the last 3 years
Mark Kettenis wrote:
> I'm not sure to what extent this makes IBT less effective. Can the
> retpolines be used as gadgets to bypass IBT? Should we stop enabling
> retpolines by default?
>
> What *is* obvious is that retpolines are incompatible wuth shadow
> stacks. Is there an alternative
Christian Weisgerber wrote:
> Mark Kettenis:
>
> > This port has some infrastructure to use an optimized function that
> > uses a function pointer. Not sure why for arm64 it actually uses that
> > infrastructure, since the only alternative is the generic C
> > implementation. But adding a BTI
Morgan Aldridge wrote:
> Since Ian mentioned devel/zeal for a USE_NOBTCFI update in -current, I
> figured I'd give it a try. Unfortunately, under OpenBSD
> amd64/6.3-stable, I get the following error when attempting to execute
> it:
>
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
Christian Weisgerber wrote:
> (Let's call it "IBT" because this is on amd64.)
>
> The remaining build failures in lang/* are:
>
> lang/crystal
> lang/gprolog
> lang/ldc
> lang/ocaml
> lang/racket-minimal
>
> Is anybody doing full package bulk builds on hardware that enforces
> IBT? I could
Brian Callahan wrote:
> On 7/10/2023 9:33 AM, Theo de Raadt wrote:
> > Brian Callahan wrote:
> >
> >> Pushed a nobtcfi fix for DMD.
> >
> > nobtcfi should never be considered a "fix". It is a workaround we make
> > available to allow
Brian Callahan wrote:
> Pushed a nobtcfi fix for DMD.
nobtcfi should never be considered a "fix". It is a workaround we make
available to allow laggard software to continue running -- nothing more.
Christian Weisgerber wrote:
> The remaining build failures are:
>
> lang/crystal
> lang/dmd
> lang/gprolog
> lang/ldc
> lang/mono
> lang/ocaml
> lang/racket-minimal
Have the upstreams been told that IBT/BTI instructions are going to
be required in all software (sometime in the future).
at g2k23 we talked about this issue for a bit. The make(1) manual
page can be confusing because it says:
-j max_processes
Specify the maximum number of processes that make may have
running at any one time.
Nope, that's wrong. It can create vast number of processes
Marc Espie wrote:
> On Mon, Jul 03, 2023 at 12:11:09AM +0200, Christian Weisgerber wrote:
> > lang/ocaml
>
> >
> > I guess for ocaml the big hammer would be to disable native code
> > compilation altogether and fall back to bytecode.
>
> How far behind are we on ocaml code releases ?
>
>
amd64 snapshot contains a different IBT diff which appears to fix go.
Solène Rapenne wrote:
> 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.
> >
>
>
Sebastien Marie wrote:
> sbcl compilation works by generating native code inside live managed memory,
> and
> permits to save the whole memory image to a file.
>
> it is why the binary currently also needs WX and RX memory (I intent to work
> a
> bit on it if possible).
>
> When generating
We know. Wait a little bit longer.
Rémi Bougard wrote:
> Hi,
>
> On the latest snapshot node (node-18.16.1v0) crash immediately after starting.
> After recompiling it from /usr/ports with USE_NOBTCFI=Yes everything works as
> before.
>
> I can provide further data if needed.
>
> All the
Theo Buehler wrote:
> On Mon, Jun 19, 2023 at 08:50:44AM -0600, Theo de Raadt wrote:
> > If you disable XSAVE_XSAVES, then userland IBT enforcement is also disabled.
> >
> > XSAVES is required to manage the IBT enforcement mechanism's internal state
> > over a c
If you disable XSAVE_XSAVES, then userland IBT enforcement is also disabled.
XSAVES is required to manage the IBT enforcement mechanism's internal state
over a context switch.
All machines with IBT have XSAVES.
If I understand right, there are other ways of managing the state, but
this is the
Greg Steuck wrote:
> Matthias Kilian writes:
>
> > still slacking around like hell, but I guess we need a new bootstrap
> > for lang/ghc. If so, I'll try to enable USE_NOBTCFI, build a new
> > bootstrap with it, and then use that for building the regular ghc
> > package.
>
> Yeah, sounds
That looks right to me.
Should there perhaps be a vague mention here that the compiler defaults
have been changed, but if in doubt mention the name of the options that
cause the compiler to do so?
The compiler options are different between arm64 and amd64. Because the
teams didn't talk and
Stuart Henderson wrote:
> On 2023/06/11 12:56, Benjamin Stürz wrote:
> > On 11.06.23 09:34, Stuart Henderson wrote:
> > > On 2023/06/10 23:40, Benjamin Stürz wrote:
> > > > Hi,
> > > >
> > > > what should I do next?
> > > > I have at least 2 OKs now, but I don't have any commit rights.
> > >
>
For some of those, I think you have old packages.
The versions were not increased during this test.
Run pkg_add -u -Dinstalled
There is a test being run in snapshots.
We are enumerating the programs that fail.
Thank you for participating.
sprits killshot wrote:
> I'm running OpenBSD GENERIC.MP#1223 amd64 on a framework laptop.
>
> I upgraded to the latest snapshot and updated packages. Then, a bunch of
> programs
Vlad Meșco wrote:
> On 7 June 2023 19:25:17 EEST, Allan Streib wrote:
> >My goal is to copy from stdin to a remote system via sftp in a pipeline.
> >I thought curl would allow this with its "-T" argument by providing "-"
> >as the local filename to transfer, but the result was:
> >
> >curl: (1)
Mark Kettenis wrote:
> So as far as I can tell, only arm64 has the -mmark-bti-property
> option. On x86 there is a include file that, when included,
> emits the "right" .note.gnu.property based on preprocessor macros that
> get set based on the compiler options. As far as I can tell, this
>
> The downside of this
> approach is that it requires modifications to every x86 assembly file.
What happens if I don't do that to an asm file included in the linux
plex client???
+.if ${MACHINE_ARCH:Maarch64}
+CONFIGURE_ENV+= ASMFLAGS=-mmark-bti-property
+.endif
For some of these diffs, it might help to consider amd64 (and i386?) at
the same time. Or, all architectures. In theory this type of thing will
eventually show up on some other architectures.
The ELF tag
Martin Schröder wrote:
> Am So., 16. Apr. 2023 um 15:49 Uhr schrieb Stuart Henderson
> :
> > At this point I think you might be better served by dumping the
> > package list, uninstalling them all, and reinstalling with 022 umask.
> >
> > Borrowing the old instructions from the 5.5 time_t flag
> I question our wisdom of having printf() log instances of %s NULL,
> but then declaring that we can't fix the offenders and need to
> resort to intercepting arguments passed to printf().
Indeed, let's step back here.
The logging has cleaned numerous bugs in our base tree.
But ports, that's
Christian Weisgerber wrote:
> Landry Breuil:
>
> > I've had a quick look and got a bit lost in the maze, but my
> > understanding is that via various aliases/defines, the function called
> > is g_logv in
> > https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gmessages.c#L1291 -
> > so the
Stuart Henderson wrote:
> > I've looked into fexecve() numerous times and I just cannot for the life
> > of me see how to avoid it becoming a component of attack methodology.
> >
> > The people who invented must be completely unaware of the dangerous
> > tooling this brings to the table.
> >
>
Christian Weisgerber wrote:
e> Theo Buehler:
>
> > devel/p5-IO-AIO
> > (?) strange mix of perl + m4
>
> The m4 part are just autoconf macros that are included by the
> top-level configure.ac. I looked over this and the syscalls are
> Linux-specific and behind #ifdef guards. On OpenBSD this
Stuart Henderson wrote:
> This port is broken; doesn't work with our Perl version. 4.79 needs
> a patch to avoid segfaults because we don't have fexecve() and with
> that fixed still doesn't work (same errors as 4.75).
I've looked into fexecve() numerous times and I just cannot for the life
of
The question remains: why the upstream doing that.
Sometihng is missing here, and it may not just be mechanical.
Klemens Nanni wrote:
> Still waiting for pkg_add and then my build to finish, but the idea is
>
> - make the existing maros NO-OPs, align with spaces to make it obvious
> - remove
Josh Elsasser wrote:
> On Fri, Jan 27, 2023 at 05:02:33PM +0100, Christian Weisgerber wrote:
> > lang/sbcl will not work with x-only.
> >
> > I took another look at the warnings about data directives in .text.
> > In runtime/x86-64-assem.S we have snippets like these:
> >
> >
So there is an approach which can be taken for these big chunks, which
I came up with yesterday.
Put them into .openbsd.mutable section.
At program startup they will be RW, so Immediately mprotect)
PROT_EXEC|PROT_READ, and if you feel like it use mimmutable() also,
which they would have been if
Theo Buehler wrote:
> On Sat, Jan 21, 2023 at 05:36:17PM +0100, Volker Schlecht wrote:
> > Here's a patch that builds node without USE_NOEXECONLY and without those
> > warnings, producing a working binary on amd64 ... I'm starting builds on
> > i386 and arm64, but since I'm not sure I understand
Stuart Henderson wrote:
> On 2023/01/21 17:36, Volker Schlecht wrote:
> >
> >
> > On 1/19/23 22:56, Theo Buehler wrote:
> >
> > > The trick to apply such patches is to add .diff to the
> > > github link.
>
> Or .patch, then you get a nice header to paste into the top of
> the patch file too.
onatinadr...@tutanota.com wrote:
> I have no intention to disable unveil permanently. I was just trying
> to solve a bug.
But it does not solve a bug.
It does not even identify the bugs.
If you really wanted to try to act like a developer, you would grab a
huge piece of disk and ktrace -di the
At some point you have to realize two things
- the restrictions we added to browsers inside are *intentional*
to reduce access outside of their general usage, in particular
restrictions inside your home directory
- But some libraries and applications you are trying to use are
designed to
> makedepend: error: out of space: increase MAXFILES
Software that demands infinite resources and will not accept and cope
with failure -- including transient and temporary failure -- on
shared-resource machines, is utterly offensive. Go back to your
one-program-at-time VIC-20 please.
How about we delete LD_PRELOAD support from ld.so?
This concept of extending programs underneath is utterly retarded,
because it is fragile in precisely this way, and there is absolutely
nothing we can or should do to help it work.
Caspar Schutijser wrote:
> Hi all,
>
> Using socksify (from
597 undo_size = gimp_get_physical_memory_size ();
Any software which does this is written by stupid people.
I have tried to push back against this, but it keeps happening.
The only way the ports community will ever fix this general problem
which keeps being repeated, is by finding a way to
Stuart Henderson wrote:
> On 2022/09/20 14:07, Marc Espie wrote:
> > Note that gimp itself has some control over memory used
> > under various circumstances in its Preferences.
> >
> > I haven't seen any indication that authors in this thread
> > are even aware those parameters exist.
>
>
Yifei Zhan wrote:
> > WASM is not required on the open internet. Not required Today. Hopefully
> > never.
>
> I think we unfortunately now already live in such a world, both
> BigBlueButton and jitsi make use of WASM, and BigBlueButton won't let
> me join a meeting without having WASM
My take on this is that WASM is quite simply just new attack surface.
Hear me out.
Imagine tomorrow someone invents WebX86. One website uses it. Support
arrives for browsers, now 10 websites use it. So it gets added.
And next year, someone inventest webARM64thingy. One website uses it.
> You mean to tell us that nmap is currently segfaulting for an industry
No, it is not segfaulting, and it is not exploitable.
Our libc contains a feature to detect backwards memcpy, in that case
it logs and KILLS THE PROCESS dead. There is no way to consider this
a risk.
The problem here is
Stuart Henderson wrote:
> On 2022/05/22 08:58, Theo de Raadt wrote:
> > The existing code uses mlock. It appears to be using mlock for a
> > privacy reason. But mlock has no privacy reason.
> > The mlock page does not make any privacy or security promises at all.
>
&
Stuart Henderson wrote:
> On 2022/05/22 13:49, Caspar Schutijser wrote:
> > I haven't tested this but shouldn't this be HAVE_CALLOC_CONCEAL?
I really don't understand the approach being taken here.
The existing code uses mlock. It appears to be using mlock for a
privacy reason. But mlock has
Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2022/05/19 08:54, Theo de Raadt wrote:
> > > I have argued in the past that mlock() in our kernel should probably be
> > > a NOOP, return success all the time, and doing nothing.
> >
> > Woul
Stuart Henderson wrote:
> On 2022/05/19 08:54, Theo de Raadt wrote:
> > I have argued in the past that mlock() in our kernel should probably be
> > a NOOP, return success all the time, and doing nothing.
>
> Would it make any sense to do that rather than abort if pledg
Klemens Nanni wrote:
> Otherwise it gets killed due to mlock(2) whenever I click on the login
> button that causes the PIN prompt to appear:
>
> firefox[71624]: pledge "", syscall 203
>
>
> mlock(2) is not covered in any pledge(2) promise.
>
> Does such use case fall under "just
> Should we continue to distribute that file is it's broken due to tar
> limitations?
Yes, we should. People can extract the tar, then update on top of it, and
at minimum this is much faster. At maximum, the small amounts of damage
people find in the tar file are not going to hurt the majority.
> - create a "gnome" login class and add users to it (recommended, see below)
I think this a really sad approach.
Suddenly a user who is in that group, has all the ridiculous limits for all
their processes.
Daniel Jakots wrote:
> On Sat, 16 Apr 2022 20:59:08 -0400, Kurt Mosiejczuk
> wrote:
>
> > I'd like to lose that whole section since most of it is many many
> > years old and seems more of historical interest rather than practical
> > advice at this point.
> >
> > ok?
>
> ok danj@
I don't
> It would be good to have Go 1.18 make release - if we're not able
> to do that, then we should update to 1.17.8.
Be very careful, the user testing time for such large software is becoming
exceedingly short, and quickly.
Christian Weisgerber wrote:
> Mark Kettenis:
>
> > There is a scenario where this goes wrong. If a shared library lacks
> > a DT_SONAME entry, the library filename is used to generate the
> > DT_NEEDED entries. But I would consider such a shared library broken
> > and we fixed base a lng
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Mon, 14 Feb 2022 00:34:53 -0700
> >
> > > The solution would be to add symlinks like all the other OSes do. But
> > > Theo doesn't like that.
> >
> > No, the problem is you a
Mark Kettenis wrote:
> > From: Philip Guenther
> > Date: Sun, 13 Feb 2022 23:29:06 -0800
> >
> > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis
> > wrote:
> >
> > > From: Greg Steuck
> > > Date: Sun, 13 Feb 2022 22:37:13 -0800
> > >
> > > To give a sense of the kind of change required
Philip Guenther wrote:
> On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis
> wrote:
>
> > > From: Greg Steuck
> > > Date: Sun, 13 Feb 2022 22:37:13 -0800
> > >
> > > To give a sense of the kind of change required to get the feature I
> > > want, see the patch at the end. The change in
Philip Guenther wrote:
> Those of long memory will recall a hackathon where dependencies on libc
> were put in place, the libm vs libc deps were changed as functions were
> moved from libm to libc, and base builds completely broke. My recall is
> that the diffs had to basically be unrolled to
> The solution would be to add symlinks like all the other OSes do. But
> Theo doesn't like that.
No, the problem is you add symbolic links, how long before software
ecosystems in ports choose the short names in linkage -- "because it
also works"? If they do so, all the transition benefits we
Alexander Bluhm wrote:
> > and those experts can stop running fw_update and do it by hand.
>
> I was testing new firmware package that is not released yet. That's
> an expert job. Now I know what to do.
The ability to go back-and-forth was part of pkg_add
We can't do that with the new
Andrew Hewus Fresh wrote:
> On Thu, Feb 10, 2022 at 12:40:43PM +0100, Alexander Bluhm wrote:
> > Does the new fw_update not check the version number of the file? Does
> > it always overwrite with the tgz from firmware.openbsd.org?
>
> It only checks whether the versions match, one of the
Stuart Henderson wrote:
> On 2022/01/24 22:17, Jonathan Matthew wrote:
> > The proposed update to lang/node makes this irrelevant, but I thought I'd
> > send
> > it anyway since it may come up elsewhere too.
> >
> > I noticed that on one system, 'npm install less' would abort, logging
> >
Stefan Hagen wrote:
> Crystal Kolipe wrote:
> > On Sat, Jan 08, 2022 at 08:15:43PM +0100, Stefan Hagen wrote:
> > > Start X via xenodm and not via startx. Then it runs through
> > > /etc/X11/xenodm/GiveConsole, which contains:
> > >
> > > if [ -c /dev/dri/card0 ]; then
> > > chown $USER
1 - 100 of 462 matches
Mail list logo
