I do think we want to write something specific for .for loop variables
which are actually very special compared to the rest.
I'm not incredibly happy with the way netbsd explains it, not surprisingly.
@@ -0,0 +1,122 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2008 Marc Espie
+.\"
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\&quo
On Fri, Sep 30, 2022 at 02:22:34AM +0200, Joerg Sonnenberger wrote:
> On Thu, Sep 29, 2022 at 08:39:16PM +1000, Jonathan Gray wrote:
> > wc counts items in files. Finding the longest item indeed sounds
> > like a task better suited to awk.
>
> Finding outliers, means and counting are all parts of
On Tue, Oct 04, 2022 at 10:15:51AM -0600, Theo de Raadt wrote:
> A note on why this chance is coming.
>
> malloc.c (as it is today), does mprotects back and forth between RW and
> R, to protect an internal object. This object is in bss, it is not
> allocated with mmap. With the upcoming mimmutab
On Wed, Oct 05, 2022 at 07:54:41AM -0600, Theo de Raadt wrote:
> Marc Espie wrote:
>
> > On Tue, Oct 04, 2022 at 10:15:51AM -0600, Theo de Raadt wrote:
> > > A note on why this chance is coming.
> > >
> > > malloc.c (as it is today), does mprotects ba
I'd like to add a special construct to dependencies, "=" to mean
the exact version of the package we're depending on.
The patch is trivial:
Index: OpenBSD/PackingElement.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingEleme
I'd like to add some non-regression tests for some scripts, most notably
register-plist, which is... let's say not perfect at the moment.
I believe
${PORTSDIR}/regress is probably the simplest least disturbing way to do that.
Since the manpages already exist under src, I could also (somehow) put
There was a small typo which broke xenocara, as noticed by tb@
(sidenote: I hate this shitty configure stuff that can't even give you
the warning messages from tools that ran. *OF COURSE* it's because so
much of that shit talks incessantly even when things are fine)
Index: pkg-config
===
Turns out that, due to the search rules we use, make
is mostly silent in case it couldn't read a Makefile
The following patch lets it track the makefilenames that
do exist, but that it wasn't able to open, so that
a post-mortem can include these.
Not sure if other use-cases could also use the po
On Sun, May 28, 2023 at 04:44:37PM +0200, Omar Polo wrote:
> On 2023/05/28 13:16:34 +0200, Marc Espie wrote:
> > Turns out that, due to the search rules we use, make
> > is mostly silent in case it couldn't read a Makefile
> >
> > The following patch lets it tra
Here's a slightly more specific diff avoiding useless stat(2)
Index: engine.c
===
RCS file: /cvs/src/usr.bin/make/engine.c,v
retrieving revision 1.70
diff -u -p -r1.70 engine.c
--- engine.c25 Oct 2021 19:54:29 - 1.70
+++
A bit more pkg-config tweaks.
- I missed two anonymous subs.
- somehow I did mangle the flags with respect to --libs-only-other
- so I added regress tests for those.
- I found out that stuff like --libs-only-l will tend to prepend a space like
-lalpha2
turns out the glib2 version of pkg-config do
On Sun, Jun 25, 2023 at 07:07:33PM -0300, Lucas de Sena wrote:
> The manual already describes how posix_spawn(3) behaves when passing it
> a NULL envp, but does not make it clear that it is an OpenBSD extension:
>
> > If envp is NULL, the environment is passed unchanged from the parent
> > process
Use-case: some people want to branch automated installs based on whether
pkg_add -u (or some other variation) actually did something.
As usual we ignore quirks. This adds a flag (-DSYSPATCH_LIKE)
which governs the behavior. Code is fairly self-explanatory.
I had no better idea for the flag name s
On Sun, Jul 02, 2023 at 04:49:41PM +0200, Solène Rapenne wrote:
> On Sun, 2023-07-02 at 15:51 +0200, Marc Espie wrote:
> > Use-case: some people want to branch automated installs based on
> > whether
> > pkg_add -u (or some other variation) actually did something.
> &
On Sun, Jul 02, 2023 at 06:06:28PM +0100, Stuart Henderson wrote:
> On 2023/07/02 16:49, Solène Rapenne wrote:
> > On Sun, 2023-07-02 at 15:51 +0200, Marc Espie wrote:
> > > Use-case: some people want to branch automated installs based on
> > > whether
> > >
I hope Vladimir will find the time to complete this answer.
As far as Vlad's work goes, he did a presentation last week-end:
https://www.lre.epita.fr/news_content/SS_summer_week_pres/Vladimir_Driver_OpenBSD.pptx
(sorry for the medium, fortunately we have libreoffice)
In the mean time, here is an
On Mon, Jul 03, 2023 at 03:20:33PM +0300, Matthieu Herrb wrote:
> > Index: dev/usb/usbdevs.h
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> > retrieving revision 1.769
> > diff -u -p -r1.769 usbdevs.h
> > --- dev/usb/usbdevs.
On Tue, Jul 04, 2023 at 07:20:51PM -0400, Thomas Frohwein wrote:
> Thanks, I built a kernel with this and no issues observed. I have a
> Wacom Bamboo (CTH-470, product id 0x00de) that doesn't attach yet, but
> this can be left for future work. I don't see anything glaring. hid.c
> could probably us
Hey, Philip, you wrote this a long time ago.
Now, I'm trying to get some coverage out of Devel::Cover on pkg_add,
and somehow, it gets in the way.
# perl -MDevel::Cover=+select,OpenBSD/.* /usr/sbin/pkg_add random_run
Selecting packages matching:
OpenBSD/.*
Ignoring packages matching:
/De
Contrary to the NYT profiler, which works like a charm
Devel::Cover is a tricky beast.
Right now, I've isolated two issues:
- OpenBSD::MkTemp (subject to a separate mail)
- identity changes on the fly. Even with looseperms, Devel::Cover
doesn't cope too well with multiple processes and multiple i
for non
trivial real worlds problems :(
On Sat, Jul 8, 2023 at 11:27 AM Marc Espie wrote:
>
> Contrary to the NYT profiler, which works like a charm
> Devel::Cover is a tricky beast.
>
> Right now, I've isolated two issues:
> - OpenBSD::MkTemp (subject to a separate mail)
I spent some time during the last hackathon, talking to various people over
where we're going.
I'm a bit afraid that people are going to see the ports/package framework
as "not invited" (because some of the subsystems of OpenBSD are not exactly
oustide friendly)
Right now, I got one student direc
Tl;Dr: I'm not trying too hard to use Devel::Cover
but so far it fails abysmally with BOTH pkg_add and dpb.
I'll admit that both are playing "fun" games with identity
but seriously, Devel::NYTProf didn't care at all !
I've spent a few hours trying to figure out options
(loose_perms won't help)
K
On Sun, Jul 09, 2023 at 01:29:58PM -0700, Andrew Hewus Fresh wrote:
> Here is a patch to replace perl(1)'s use of syscall(2) with a dispatcher
> that will call the libc function instead.
>
> I have to do some work on style before this is ready to commit, but it
> should be ready for some testing.
Some comments already. I haven't looked very closely.
On Sat, Aug 05, 2023 at 03:12:18PM -0400, Thomas Frohwein wrote:
> The current draft hijacks post-extract target, but it would be easy to
> add this to _post-extract-finalize in bsd.port.mk similar to how the
> post-extract commands from module
On Sat, Aug 05, 2023 at 09:50:57PM -0400, Thomas Frohwein wrote:
> On Sat, Aug 05, 2023 at 11:27:24PM +0200, Marc Espie wrote:
> > Some comments already. I haven't looked very closely.
>
> > On Sat, Aug 05, 2023 at 03:12:18PM -0400, Thomas Frohwein wrote:
> > >
I think it could be occasionally useful to know which variables have
been defined in make.
Incidentally, this DOES exist in GNU make, so I've reused the same name
for basically the same functionality.
I haven't checked whether NetBSD/FreeBSD introduced something similar.
This is a fairly straigh
On Mon, Aug 07, 2023 at 10:05:37PM -0400, Thomas Frohwein wrote:
> I looked through the file and it seems that varname_list_changed is
> never set to anything but true. Is there a bit missing, like down lower
> in varname_list_retrieve()?
Yep, I removed it at some point because it looked like some
Here's a revised diff (reordered plus actual use of the boolean)
plus concrete example use for bsd.port.mk (disregarding the fact
_ALL_VARIABLES would have to move *after* all MASTER_SITES have been defined.
Index: var.c
===
RCS file
Actually, as far as bsd.port.mk, it doesn't need to
move too much stuff around thanks to make's lazyness.
Note that having a list of defined MASTER_SITES variables simplifies
the check.
I've also added a check for the right MASTER_SITES to be defined,
since currently we do not error out until act
On Wed, Aug 09, 2023 at 12:54:12AM -0400, Thomas Frohwein wrote:
> - It includes logic that finds the first MASTER_SITESn that isn't
> otherwise used, and throws an ERROR if it overruns past
> MASTER_SITES9.
That logic will hopefully be soon 100% obsolete.
I need some okays on the .VARIABLES
Now that we got .VARIABLES in make, this is going to be put to great use
in bsd.port.mk.
Namely, instead of the currently (very clunky)
DISTFILES = sometarball:0
MASTER_SITES0 = where to get this
I propose we do something like:
DISTFILES.site = sometarball
MASTER_SITES.site = where to get this
On Sat, Aug 12, 2023 at 08:00:48AM +, Miod Vallat wrote:
> I have had a look at your diff and I think it's decent enough to go in
> after some polishing.
>
> Can Wacom tablet users try this cleaned up diff?
Works on the target tablet here (Wacom Intuos S)
On Sat, Aug 12, 2023 at 05:22:38PM +0200, Peter J. Philipp wrote:
> On Sat, Aug 12, 2023 at 02:27:13PM +, Miod Vallat wrote:
> > Third time's (hopefully) the charm. How about that diff? Too much things
> > have been removed in uwacom.
>
> partial success! The wacom driver is recognized, no pa
On Sat, Aug 12, 2023 at 03:21:00PM +, gil...@poolp.org wrote:
> August 12, 2023 4:34 PM, "Theo Buehler" wrote:
>
> > On Sat, Aug 12, 2023 at 02:29:45PM +, gil...@poolp.org wrote:
> >
> >> Hello,
> >>
> >> Someone asked about selectable curves in the OpenSMTPD portable tracker,
> >> and
We've run into a few errors due to very long variable expansion in bsd.port.mk
that overflows execve(2)
I would consider adding a modifier to give the length of a variable, so
that significant tests can be done, along the lines of
.if ${VARIABLE:len} > 20
ERRORS += "Fatal: variable may overfl
Theo pointed me in another direction
Proof of concept that appears to work just fine
(very minimal error checking so far)
Of course, if we end up running a command on somethin too large,
thi will fail as usual, but much to my surprise,
make show=_FULL_FETCH_LIST
in sysutils/telegraf worked with
On Sat, Aug 26, 2023 at 02:25:19PM -0600, Theo de Raadt wrote:
> I did not point you in this direction, not at all.
Oh you did. It was not intentional. But I was focused on make variables
instead of trying to catch the error, and you redirected me towards
execv proper.
> I said make execve failur
Turns out the exec in cmd_exec.c has absolutely zero reason to be
different from what engine does.
This small patch moves a bit of code around, so that all execv() consumers
benefit from the same optimisation (namely, no extra shell when not needed).
The only visible change should be that now, VA
On Mon, Aug 28, 2023 at 08:42:50PM +0200, Marc Espie wrote:
> Turns out the exec in cmd_exec.c has absolutely zero reason to be
> different from what engine does.
>
> This small patch moves a bit of code around, so that all execv() consumers
> benefit from the same optimisation (n
On Mon, Aug 28, 2023 at 10:03:46PM +0200, Theo Buehler wrote:
> On Mon, Aug 28, 2023 at 09:18:40PM +0200, Marc Espie wrote:
> > On Mon, Aug 28, 2023 at 08:42:50PM +0200, Marc Espie wrote:
> > > Turns out the exec in cmd_exec.c has absolutely zero reason to be
> > > diff
A long time ago, I tried to host our fork of make, in the hope it would get
picked up by other systems.
Accordingly, some features were added to mimic netbsd's extensions, hidden
behind FEATURES macros.
Turns out that, for better or for worse, FreeBSD decided to go with NetBSD's
fork of bmake, so
On Thu, Aug 31, 2023 at 08:59:53AM +0200, Marc Espie wrote:
> A long time ago, I tried to host our fork of make, in the hope it would get
> picked up by other systems.
>
> Accordingly, some features were added to mimic netbsd's extensions, hidden
> behind FEATURES macros.
>
On Tue, Sep 05, 2023 at 12:04:24AM +1000, Jonathan Gray wrote:
> inline is part of gnu89 and c99
>
> Index: defines.h
> ===
> RCS file: /cvs/src/usr.bin/make/defines.h,v
> retrieving revision 1.15
> diff -u -p -r1.15 defines.h
> --- d
On Tue, Sep 05, 2023 at 11:51:34AM +1000, Jonathan Gray wrote:
> On Mon, Sep 04, 2023 at 11:51:33PM +0200, Marc Espie wrote:
> > On Tue, Sep 05, 2023 at 12:04:24AM +1000, Jonathan Gray wrote:
> > > inline is part of gnu89 and c99
> > &
Not to pkgconf levels, but still way faster than what we had
Updated patch from what I've shown to people, turns out the second grep
wasn't quite working.
This does cache the set_variables_from_env shennanigans, speeding up large
processing of recursive files by a large factor (since we keep a ca
I was reading through ps.1, which has two slightly different options
-H Also display information about kernel visible threads.
-k Also display information about kernel threads.
It's not at all obvious what the difference between these options might be.
>From the log:
> --
> Sent from a phone, apologies for poor formatting.
>
> On 11 September 2023 10:02:32 Marc Espie wrote:
>
> > I was reading through ps.1, which has two slightly different options
> > -H Also display information about kernel visible threads.
> >
On Mon, Sep 11, 2023 at 12:10:17PM +0200, Claudio Jeker wrote:
> On Mon, Sep 11, 2023 at 11:02:00AM +0200, Marc Espie wrote:
> > I was reading through ps.1, which has two slightly different options
> > -H Also display information about kernel visible threads.
> &
On Mon, Sep 11, 2023 at 09:55:53AM +0200, Marc Espie wrote:
> Not to pkgconf levels, but still way faster than what we had
>
> Updated patch from what I've shown to people, turns out the second grep
> wasn't quite working.
>
> This does cache the set_variables_from_e
On Tue, Sep 19, 2023 at 09:48:25AM -0300, Crystal Kolipe wrote:
> deroff chokes when given lines > 2048 bytes, and produces non-deterministic
> output on little endian archs.
>
> Reproducer:
>
> $ jot -s '' -b blah 513 > /tmp/blah
> $ for i in 1 2 3 4 ; do deroff /tmp/blah | md5 ; done
> 2d8f4eeb
On Sat, Oct 14, 2023 at 11:24:08AM -0700, Andrew Hewus Fresh wrote:
> While testing another patch, I noticed that fw_update will lock the
> package database even if it's just downloading and not touching the
> installed packages.
>
> Currently we do _read_ the existing firmware as part of detectin
The max approach is bogus. It happens because the terminal uses tc, and
then tc again.
The proper approach, especially in perl, is to actually detect a loop,
which should be fairly easy by saving the tc that have already been done
in a hash.
Instead of an archaic limit, just keep track of tc's.
This is actually slightly faster, because the termcap links is a tree,
not a list.
Please test.
Index: Cap.pm
===
RCS file: /cvs/src/gnu/usr.bin/perl/cpan/Term-Cap/Cap.pm,v
retrie
I guess i will probably leave it alone after this.
This does quite a few things compared to my former patches.
- totally get rid of eval, it doen't make sense anymore
- declare variables before they get used, which tends to
simplify things.
- change quaint formatting to something more BSD like
- u
If tar can't create intermediate directories due to permission
issues, the resulting message is confusing:
./tar xf gcc.tar gcc-8.3.0/include/obstack.h
tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or directory
(here I have gcc-8.3.0 owned by root and no permissions)
The follo
On Sun, Mar 22, 2020 at 01:09:17PM +0100, Denis Fondras wrote:
> On Sun, Mar 22, 2020 at 11:41:55AM +0100, Marc Espie wrote:
> > If tar can't create intermediate directories due to permission
> > issues, the resulting message is confusing:
> >
> > ./tar xf gcc
There's some inconsistency:
lists/xserv/mi:./usr/X11R6/share/aclocal/xorg-macros.m4
lists/xshare/mi:./usr/X11R6/lib/pkgconfig/xorg-macros.pc
both should be in xshare
This does explain the failures of tightvnc on some bulk machines.
By default, proot does NOT copy xserv in the chroot, and I believ
On Thu, Apr 09, 2020 at 02:44:14PM +0200, Jeremie Courreges-Anglas wrote:
> On Thu, Apr 09 2020, Jeremie Courreges-Anglas wrote:
> > find(1) uses ARG_MAX to compute the maximum space it can pass to
> > execve(2). This doesn't fly if userland and the kernel don't agree, as
> > noticed by some afte
Our make (bsd make) has "alternate" dependency operators :: and !
Twenty years ago, we made it so that ambiguous constructs like
File::Find.3p: File/Find.pm
would no longer be ambiguous thanks to the added space.
Now, I believe that ! should be trumped by : if both are present in the
same line
On Thu, Apr 09, 2020 at 06:33:25PM +0200, Marc Espie wrote:
> Our make (bsd make) has "alternate" dependency operators :: and !
>
> Twenty years ago, we made it so that ambiguous constructs like
> File::Find.3p: File/Find.pm
>
> would no longer be ambiguous thanks to
I do think newcomers will tend to miss examples, even if /etc/examples is
somewhat documented elsewhere.
Also, queries to mandocdb will probably benefit... say "what commands do
have an example configuration file ?" kind of what you should be able to
ask with advanced queries.
I haven't used wsmoused in ages, but I tend to think ideas like (by default)
scaling to the font size have great merit.
There should be a debugging toggle (maybe) to get raw values.
It should work out-of-the-box preferably. ;)
I've had to neuter some setlocale() in mlt, since our code is definitely NOT
thread-safe. No biggie, since we do not have support for LC_NUMERIC right now.
I think we might want the thread-specific functions, namely stuff like
strtod_l, or sprintf_l and friends.
Even if they do not do anything
On Fri, May 22, 2020 at 02:31:38PM +0200, Mark Kettenis wrote:
> > Date: Fri, 22 May 2020 13:50:44 +0200
> > From: Marc Espie
> >
> > I've had to neuter some setlocale() in mlt, since our code is
> > definitely NOT thread-safe. No biggie, since we do not ha
On Fri, May 22, 2020 at 04:02:31PM +0200, Mark Kettenis wrote:
> > From: "Todd C. Miller"
> > Date: Fri, 22 May 2020 07:23:55 -0600
> >
> > On Fri, 22 May 2020 14:57:11 +0200, Marc Espie wrote:
> >
> > > From a security standpoint, is t
On Fri, May 22, 2020 at 02:31:38PM +0200, Mark Kettenis wrote:
> > Date: Fri, 22 May 2020 13:50:44 +0200
> > From: Marc Espie
> >
> > I've had to neuter some setlocale() in mlt, since our code is
> > definitely NOT thread-safe. No biggie, since we do not ha
On Tue, May 26, 2020 at 12:13:02AM +0200, Ingo Schwarze wrote:
> Hi,
>
> my impression is there are two totally independent topics in this
> thread.
>
> 1. Whether and how to make things safer, ideally terminating the
> program in a controlled manner, if it uses functions that are
> not
On Thu, May 28, 2020 at 05:44:31PM +0300, Paul Irofti wrote:
> Hi,
>
> Here is a new iteration of the diff which includes support for MD high
> resolution clocks. Currently only implements TSC on amd64. If the
> MD function is not defined, it fallsback to the syscall.
>
> There is the question of
On Fri, May 29, 2020 at 03:48:41PM +0200, Ingo Schwarze wrote:
> Hi Marc,
>
> do i understand correctly that you intend to say: there are
> legitimate reasons to use these xlocale.h functions in portable
> software, in particular in portable libraries, so we should probably
> have them all, or at
On Tue, May 26, 2020 at 12:13:02AM +0200, Ingo Schwarze wrote:
> Regarding the FreeBSD headers, i like them even less. There are both
> terrible design choices and terrible implementation choices. Regarding
> design, it appears that you *must* #include after other
> headers - if you include it b
In a trace:
> > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
Now, this is NOT the default location for WRKOBJDIR, but we are shipping
packages with debug information...
This could be a bit cumbersome, if in order to
> - have some magic I don't know in ELF handling that would allow to either
> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
Thinking some more about it, that 3rd option is possibly not that
far-fetched
we do pass most debug-info thru dwz for shrinkage, so there's one tool
On Sat, May 30, 2020 at 05:10:49PM +0200, Jeremie Courreges-Anglas wrote:
> On Sat, May 30 2020, Marc Espie wrote:
> >> - have some magic I don't know in ELF handling that would allow to either
> >> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
I occasionnally use setxkbmap 'us(intl)' in order to have diacritics
as dead keys.
I have LC_CTYPE=en_US.UTF-8
If I type 'c
I get a ç in programs like firefox or chrome, BUT I get
ć in xterm ?
why are things different ? which program is right ?
(I have just tried with a test user with nothi
On Mon, Jun 01, 2020 at 03:46:09PM +0200, Matthieu Herrb wrote:
> On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote:
> > Hello,
> >
> > Le 01/06/2020 14:55, Matthieu Herrb a écrit :
> > >
> > > >
> > > > (I have just tried with a test user with nothing configured besides
> > > > LC
On Mon, Jun 01, 2020 at 03:37:45PM -0600, Anthony J. Bentley wrote:
> Marc Espie writes:
> > > To setup the right alt key as compose, you can either:
> > >
> > > - run 'setxkbmap -option compose:ralt' somewhere in your session
> > > startup scr
On Tue, Jun 09, 2020 at 08:19:53PM -0700, jo...@armadilloaerospace.com wrote:
> Also, style(9) says that prototypes should not have variable names
> associated with the types. I try to use good names in the headers
> for documentation purposes; what is the thinking behind the rule?
function names
On Wed, Jun 10, 2020 at 05:38:36PM +1000, Jonathan Gray wrote:
> On Wed, Jun 10, 2020 at 09:19:47AM +0200, Martin Pieuchot wrote:
> > On 09/06/20(Tue) 20:19, jo...@armadilloaerospace.com wrote:
> > > Looking for some guidance to avoid proposing any unpopular diffs.
> > >
> > > Style(9) says not to
On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> On 2020-06-11 02:46, Christian Weisgerber wrote:
> > Paul Irofti:
> >
> > > This iteration of the diff adds bounds checking for tk_user and moves
> > > the usertc.c stub to every arch in libc as recommanded by deraadt@.
> > > It also f
On Thu, Jun 11, 2020 at 03:42:27PM +0300, Paul Irofti wrote:
> On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> > > On 2020-06-11 02:46, Christian Weisgerber wrote:
> > > > Paul Irofti:
>
On Thu, Jun 11, 2020 at 07:55:44AM -0600, Theo de Raadt wrote:
> I think this conversation about major numbers, and now minor numbers,
> is incredibly silly.
>
> Do we have a major number on the open(2) system call? No, and the main
> reason is because the code isn't a draft, it was completed.
>
On Tue, Jun 16, 2020 at 08:43:02PM +0100, Raf Czlonka wrote:
> Ping.
>
> CC'ing espie@ as he committed the initial code.
>
> Cheers,
>
> Raf
>
> On Sun, Jun 07, 2020 at 07:30:39PM BST, Raf Czlonka wrote:
> > Hi all,
> >
> > I've been running openbsd-backgrounds on all of my desktop machines an
On Wed, Jun 17, 2020 at 11:34:20AM +0200, Solene Rapenne wrote:
> I propose a small diff for pkg_add when using http/https mirrors.
> Don't wait 30 seconds for the ftp process to stop when closing
> file handler, send SIGHUP immediately after closing the file handler.
>
> Running pkg_add -u neovim
On Wed, Jun 24, 2020 at 05:32:57PM +0100, Jason McIntyre wrote:
> On Tue, Jun 23, 2020 at 07:28:09PM -0400, sven falempin wrote:
> > Dear readers,
> >
> > It may not be very obvious that 'dry run' mode of pkg_add
> > actually downloads packages.
> > It is a good feature and maybe the pkg_add man c
Until a patch from naddy, I wasn't even aware of getopts in sh(1)
Unless I made some mistakes, this translates the example in getopt(1)
manpage.
It's likely some stronger wording might be adequate, I suspect some
of the BUGS section in getopt(1) does not apply to the sh(1) built-in.
Index: bin/k
On Fri, Apr 30, 2021 at 12:03:00PM +0100, Raf Czlonka wrote:
> Hi Mark,
>
> You and me both ;^)
>
> Until recently, I thought that getopt(1) was POSIX, whereas it is
> in fact getopts(1), and it is not a shell built-in there, but a
> utility[0].
Nope, it is a shell built-in... the "wording" of p
On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
> >
> > Unless I made some mistakes, this translates the exampl
On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> On Fri, Apr 30, 2021 at 04:07:55PM +0200, Marc Espie wrote:
> > On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> > > On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > > &g
On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> my argument boils down to: sh(1) is small and has no examples. adding
> them changes the (deliberate) nature of the page. ksh(1) is what you
> read when you can;t get to sleep.
>
> why is it wrong to add your example to ksh(1)? why
On Fri, Apr 30, 2021 at 04:54:57PM +0200, Christian Weisgerber wrote:
> Marc Espie:
>
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
>
> Let's start the discussion with this instead.
>
> This puts the deprecation notice in getopt.1 in
So, is there a way to get a work-around ? or should we push for proper
tls sooner than later ?
It always made me queasy having all those programs segfaulting on exit.
Not sure it's exploitable, but giving people the impression it's okay
to segfault.
I thought it might be bad code in the programs,
On Fri, May 28, 2021 at 07:55:39AM -0700, Chris Cappuccio wrote:
> I tried to compile librdkafka on OpenBSD 6.5 (clang 7.0.1) and clang compiled
> the __thread parts with some built-in mechanism. I upgraded the system to
> OpenBSD 6.9 and TLS is no longer supported by the in-tree clang. Was this
>
On Fri, May 28, 2021 at 06:56:42PM +0200, Marc Espie wrote:
> On Fri, May 28, 2021 at 07:55:39AM -0700, Chris Cappuccio wrote:
> > I tried to compile librdkafka on OpenBSD 6.5 (clang 7.0.1) and clang
> > compiled
> > the __thread parts with some built-in mechanism. I u
On Sat, Jul 14, 2018 at 10:04:55AM +0200, Klemens Nanni wrote:
> OK?
>
> Index: man5/bsd.port.mk.5
> ===
> RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v
> retrieving revision 1.486
> diff -u -p -r1.486 bsd.port.mk.5
> --- man5/bsd
On Sat, Jul 14, 2018 at 06:15:59PM +0100, David CARLIER wrote:
> Hi,
>
> Just to anticipate things, the age of the version starts to show with
> some third party softwares, so I was thinking if we could update to
> the latest while keeping just the necessary code and backporting our
> internal cha
Nope.
Still some useful stuff in there.
On Wed, Aug 01, 2018 at 11:03:39AM +0200, Sebastien Marie wrote:
> Hi,
>
> After issuing a "make clean=build" on a port, I am unable to build
> again.
>
> "make" failed in 'configure' stage:
>
> $ make
> ...
> /bin/sh: cannot create
> /home/semarie/repos/openbsd/ports/pobj/rust-1.28.0/bin/acloc
On Wed, Aug 01, 2018 at 11:03:39AM +0200, Sebastien Marie wrote:
> Hi,
>
> After issuing a "make clean=build" on a port, I am unable to build
> again.
>
> "make" failed in 'configure' stage:
>
> $ make
> ...
> /bin/sh: cannot create
> /home/semarie/repos/openbsd/ports/pobj/rust-1.28.0/bin/acloc
1 - 100 of 664 matches
Mail list logo
