Re: Missing vlan interfaces in OPENBSD-PF-MIB::pfIfTable

[Marc Boisis]

Like Kapetanakis I have the 64 interface desc empty:
> snmpget -v2c -c public 127.0.0.1 OPENBSD-PF-MIB::pfIfDescr.64
OPENBSD-PF-MIB::pfIfDescr.64 = STRING:

So can we imagine a limit of 64 interfaces in the snmp (snmpd_metrics) code ?


> On 11 Jun 2024, at 14:34, Martijn van Duren  
> wrote:
> 
> On Tue, 2024-06-11 at 14:56 +0300, Kapetanakis Giannis wrote:
>> On 10/06/2024 18:43, Marc Boisis wrote:
>>> Hello,
>>> 
>>> I've a 7.5 openBSD router, when I'm asking OPENBSD-PF-MIB I have only 64  
>>> physicals and carp interfaces but not my 45 vlan interfaces.
>>> 
>>> My /etc/snmpd.conf
>>> ROOT:amdrg2:/root > cat /etc/snmpd.conf
>>> listen on 127.0.0.1 snmpv2c
>>> read-only community public
>>> 
>>> 
>>> "pfctl -sI" list all interfaces (carp and vlan).
>>> 
>>> Is there a setting or a limit to configure to see vlan interfaces in  
>>> OPENBSD-PF-MIB and especialy in OPENBSD-PF-MIB::pfIfTable ?
>>> 
>>> Ps: In openbsd 6.5, OPENBSD-PF-MIB::pfIfTable contain all interfaces
>>> 
>>> Regards
>>> 
>>> Marc
>>> 
>> Indeed.
>> 
>> snmpwalk -v2c -c xx localhost OPENBSD-PF-MIB::pfIfDescr | wc -l
>> 64
>> 
>> pfctl -sI | wc -l
>> 99 (groups included)
>> 
>> ifconfig | grep flags | wc -l
>> 85
>> 
>> that is on 7.5 release.
>> 
>> snmpwalk is showing only "vlan" and not the vlan interfaces. That is 
>> probably the group vlan.
>> 
>> There is also an empty one at the end.
>> 
>> OPENBSD-PF-MIB::pfIfDescr.63 = STRING: vlan
>> OPENBSD-PF-MIB::pfIfDescr.64 = STRING: 
>> 
>> G
> 
> $ snmp walk -v2c -cpublic 127.0.0.1 pfIfDescr | wc -l  
>  15
> $ doas pfctl -sI | wc -l 
>  15
> 
> pfIfDescr.13 = STRING: vlan
> pfIfDescr.14 = STRING: vlan6
> 
> 
> I'm not seeing it. I'm willing to dig into this, but without giving me a
> way to reproduce saying "me too" isn't going to help.
> 
> martijn@
> 

Missing vlan interfaces in OPENBSD-PF-MIB::pfIfTable

[Marc Boisis]

Hello,

I've a 7.5 openBSD router, when I'm asking OPENBSD-PF-MIB I have only 64  
physicals and carp interfaces but not my 45 vlan interfaces.

My /etc/snmpd.conf
ROOT:amdrg2:/root > cat /etc/snmpd.conf
listen on 127.0.0.1 snmpv2c
read-only community public


"pfctl -sI" list all interfaces (carp and vlan).

Is there a setting or a limit to configure to see vlan interfaces in  
OPENBSD-PF-MIB and especialy in OPENBSD-PF-MIB::pfIfTable ?

Ps: In openbsd 6.5, OPENBSD-PF-MIB::pfIfTable contain all interfaces

Regards

Marc

Re: ubnt edgerouter 8

[Marc Peters]

Am Tue, Apr 30, 2024 at 12:03:10PM UTC, schrieb Stuart Henderson:
> Do be aware that they often have less airflow than the original fans.
> 
> Sometimes that is not a problem, but sometimes you might want to think
> twice (especially in, say, the power supply in poe switches, which might
> end up getting a bit too warm).

They have a much higher airflow than the original ones and this particular POE 
switch model has a separate one for its PSU (with the non standard plug, which 
took me a lot longer to cut the shrinking cover and get every 3 wires 
reconnected, than to replace the other two fans)

Re: ubnt edgerouter 8

[Marc Peters]

Am Mon, Apr 29, 2024 at 05:31:14PM UTC, schrieb Daniel Gracia:
>I replaced my 8 Pro fans with Noctua units and I'm pretty happy with
>them; they came with several adapters that allow you to choose the
>speed of the fans.

+1 for the noctua fans from me. I replaced a couple of annoying Juniper ones to 
get a decent noise level and they're really silent, even my wife doesn't 
complain. As already mentioned, the come with a couple of adapter to connect 
and even a wiring solution for non standard pins is in the package. They also 
have photos on their page, eg. https://noctua.at/en/nf-a4x10-flx

hth,
Marc

Re: mountd

[Marc Espie]

On Tue, Jan 09, 2024 at 07:27:47AM +0100, Otto Moerbeek wrote:
> resreved means that the port number is below 1024. The RPC system,
> (which is used to implement NFS) iuses portmapper to determine which
> service runs on which port. What problem are you trying to solve?

I'm not a fan of that terminology, especially since
/etc/services actually contains several ports reserved for services that
are well above 1024.

For instance, see https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

(found in 30 seconds on google, which lists ports 2375-2380 as "reserved"
among others).

IANA seems to define range 0-1023 as "System ports"
see 

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Re: cumbersome mtree

[Marc Espie]

We used to use mtree for packages at well.

At some point, it was simpler to just give up and roll our own format
for the same thing. There are many many limitations to mtree

Re: Why is BRE still around? (Re: Porting shell scripts from Tiny Tools)

[Marc Chantreux]

hello,

On Fri, Nov 17, 2023 at 07:22:57PM +0100, Christian Weisgerber wrote:
> > I the same mood: I realized recently that no implementation of awk
> > seems to implement quantifiers which is really desapointing.
> Awk uses EREs, so if by quantifiers you mean {n,m}, then awk most
> certainly supports this.

I just double checked. works on OBSD as well as the other versions of
awk that are available on my debian.

does() if $awk '/ba{3}b|ba\{3\}b/' | grep -qF baaab
then >&2 echo "$awk does"
else >&2 echo "$awk don't"
fi <<-%
baaab
baab
%

for awk in gawk mawk "busybox awk"; do does
done

which leads me to

gawkdoes
mawkdon't
    busybox awk does

Sorry about the fake news :/

Regards,
Marc

Re: Why is BRE still around? (Re: Porting shell scripts from Tiny Tools)

[Marc Chantreux]

hello,

> but note that BREs are not a strict subset of EREs

I have to admit that's the way I saw BRE so thanks a lot for noticing me.

I the same mood: I realized recently that no implementation of awk
seems to implement quantifiers which is really desapointing.

I don't realize those things that much because in many cases,
perl (with flags like -p, -n, -F, -s, -0 ) let me provide shorter
and cleaner solutions than the grep|sed|awk equivalent.

> The GNU project turned BREs and EREs into one and the same feature
> set in their implementation, just with different syntaxes, causing
> a great deal of confusion.

It would be nice to compare all those langages. I just googled and
found this:

https://gist.github.com/CMCDragonkai/6c933f4a7d713ef712145c5eb94a1816

Regards and thanks again for enlightening me today.

Marc

Why is BRE still around? (Re: Porting shell scripts from Tiny Tools)

[Marc Chantreux]

hello,

> these tools by default use basic regexps (BRE).

Out of curiosity:


To me, it's just a reason of retrocompat: no people dare breaking
everything at some point. I really dislike the fact that it's
confusing (for example: + must be protected but not *).

But is there another good reason for BRE to be still alive?
(perfomance, simplicity, or anything else).

Regards.
Marc

Re: Upgrading, release by release, from 6.8 to 7.4 -- my experience

[Marc Espie]

On Wed, Nov 15, 2023 at 03:12:09PM -0700, Austin Hook wrote:
> One little glitch from all the process is that somehow I must have lost a 
> file or failed to delete a file that has something to do the default 
> character set files or pointers for xterm under "fvwm".  A new xterm 
> starts automatically in a super super small font.  Can't even read it. 
> Control-right-mouse on an xterm gives the menu for selecting the font size 
> and also the choice of using Truetype fonts, which works, OK, but I have 
> to do it each time I open a new xterm.

Some time ago, matthieu fixed the dpi hint in X, so that it wouldn't be
the default value, but would actually match the monitor or something.

You can probably get back to the size you'd expect by perusing
xrandr -dpi option.

Re: __dead

[Marc Espie]

On Tue, Nov 07, 2023 at 03:08:18PM +, Lucretia wrote:
> I've seen __dead a few places in the source code, does this mean it isn't 
> functional anymore, or maybe just deprecated?
> 

It's the old non-standard representation for  __attribute__(__noreturn__)
in code, to stop the compiler whining and unwarranted optimisations.

Re: mount softdep — does it improve the situation for unexpected shutdowns?

[Marc Espie]

Not quite sure how much has been discussed publically, but we don't
currently have the manpower to handle lots of complicated parts,
and it seems that softdep, in its current state, needs the hand of
Kirk McKusick to work.

So the current strategy has been to make the moving parts simpler
(softdep, scheduler) in order to reduce the amount of bugs, so that
hopefully we can make things faster again later once they're
rock-solid.

(in case you're wondering how softdep might be an issue, for instance
there are lots of moving parts in swap, the buffecache, the page
zeroer, that tend to run amok unless carefully tended, and until
we get a better grasp on this, something akin to softdep is unlikely
to come back)

Re: ldd error with setuid/setgid binaries

[Marc Espie]

On Wed, Oct 18, 2023 at 09:38:32PM +0200, Theo Buehler wrote:
> On Thu, Oct 19, 2023 at 01:39:00AM +0900, Yoshihiro Kawamata wrote:
> > From: Marc Espie 
> > Subject: Re: ldd error with setuid/setgid binaries
> > Date: Wed, 18 Oct 2023 18:04:45 +0200
> > 
> > > objdump -p
> > > will be as good.
> > > 
> > > Yes, it does not recurse, but it doesn't need to, since you also
> > > want to wipe libraries that link with old libraries.
> > 
> > This seems to be easier to parse in a shell script than "readelf -d".
> 
> If you need recursion you may want to try lddtree from devel/pax-utils.
> 
Admittedly, I think what Yoshihiro-kun is trying to achieve
may be under the realm of sysclean.

Re: ldd error with setuid/setgid binaries

[Marc Espie]

On Wed, Oct 18, 2023 at 11:41:12PM +0900, Yoshihiro Kawamata wrote:
> From: "Theo de Raadt" 
> Subject: Re: ldd error with setuid/setgid binaries
> Date: Wed, 18 Oct 2023 06:35:51 -0600
> 
> > You don't explain why you need to do this.  You just completely skipped 
> > that.
> > You don't justify why you need it to work.  Does that make me care?? No, it
> > really doesn't make me care.
> 
> This is to find executable binaries that use old shared libraries that
> no longer exist after an OS upgrade.
> 

objdump -p
will be as good.

Yes, it does not recurse, but it doesn't need to, since you also
want to wipe libraries that link with old libraries.

Re: Understanding -current as 7.4 is released

[Marc Espie]

On Thu, Oct 05, 2023 at 12:45:56PM -0400, Ronald Dahlgren wrote:
> Hello friends,
> 
> I’ve been running -current for several months now. Recently I started using
> “-D snap” when updating packages with pkg_add.
> 
> I ask the list to help me understand what, if anything, I need to do with
> my machines that run snapshots when 7.4 is released. Will I need to perform
> the upgrade procedures differently? Is the release just a blessed snapshot
> and everything will continue to work as-is?

The way OpenBSD versions is run is very confusing for lots of people.

Specifically, OpenBSD decides whether it's running "bleeding edge" current
(snapshot) or a release/stable based on what the kernel says.

Most of the time, this is straightforward: you're running a snapshot
and both sysupgrade/pkg_add get pointed to the snapshot directory.

Or you're running stable, and both sysupgrade/pkg_add get pointed to the
(corresponding release/stable update) directories.

HOWEVER, a few weeks before a new release, the rules get a bit confusing:
- since we're near "testing the release mode", the new kernel tells
you "hey, I am 7.4, so go grab the 7.4 release stuff". This is intentional,
so you're as close to "release mode" as possible.
- however, because the release hasn't yet happened, all the stuff
still drops in snapshots, with the user needing to point things up towards
the right location.
-> sysupgrade -s
-> pkg_add -Dsnap

in order to STILL grab stuff off the snapshots directory instead of the
release (which hasn't yet happened)

(I could probably add a helpful message to pkg_add according to the
following rules: if we're grabbing stuff from a release directory,
and the mirror used seems to contain stuff, like the previous release
and snapshots, remind the user we might be near a new release, and
to use -Dsnap to get to the snapshot)

Re: undocumented command switches -OR- fix documentation fully

[Marc Espie]

On Mon, Sep 25, 2023 at 09:05:40PM +0200, Rudolf Leitgeb wrote:
> If you document a switch, you are basically required to keep that
> functionality around forever. Given that the OpenBSD devs don't like
> these --options all that much, I don't see that happening. Submitting
> a patch won't change that.
> 
> IMHO there's nothing wrong, if software can do more than its 
> documentation shows. It's not like it breaks documented behavior.

Sometimes we're the other guy.

I regularly look at other people's tools, trying to figure out what
they implement, what they use. 


Case in point: I added .VARIABLES to our make. It didn't come out
of nowhere. It is a documented feature of gnu-make, so I reused the
exact same name.  I did locate it in the documentation first, because
it is documented.

I also routinely look at what pkgsrc and freebsd are doing, just so
we can grab good ideas from them.

Sometimes I even write portable software.

Figuring out what goes wrong based on a user's bug report on a
system that you don't have is always fun.  It is way more fun when
you can actually figure it out straight from the documentation.

Otherwise, you get to have the fun to try and reproduce their installation.

Re: undocumented command switches -OR- fix documentation fully

[Marc Espie]

Don't rant that long.

Sometimes, documentation and code get out-of-synch for a lot of reasons.

- trying out stuff and documenting later.
- plain forgetting to update the documentation.
- having some stuff for a transition period, and then killing it.

Your point that stuff that stays around, should ideally be documented,
is a good point.

Now, you gotta realize that people have limited time to do everything.

In general, patches are welcome.

In my long tenure on various tools, I've learnt that documenting
stuff is always always a good idea: if you get a new feature BUT
you can't explain it cleanly, then you should go back to the
drawing-board !

Re: undocumented command switches -OR- fix documentation fully

[Marc Espie]

Apart from the obvious troll, I believe there is a point.

>From time to time, I go to other projects and try to figure out how far
we are from compatibility...

Not documenting compat options means that somebody outside the project
would have to guess at stuff, instead of just reading the manpage and
figuring out "hey, I can just use --version here just like elsewhere".

Just because we find long options to be disgusting (tm) doesn't mean we
shouldn't try to document what's here to stay.

Face it, as much as we would like OpenBSD to stay pure, some compat stuff
is there to stay.

Let's try not to be more prickly to the outside world than we need, as much
as we have a reputation to uphold, shall we ?

Re: pkg_add -vV slow progression

[Marc Espie]

On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote:
> Hello,
> 
> Is there any recent major change in base packages or pkg_add?
> I ask because the pkg_add -vV is slower than usual at each package,
> most of the time spent in Extracting ... phase.
> I use amd64 recent snapshot. I checked my disk and https downloads,
> they are fine.

No major change, but fs got simplified recently.

Re: Update from 6.5 to 7.3

[Marc Espie]

On Fri, Sep 08, 2023 at 06:36:57PM +0200, Alessandro Baggi wrote:
> 
> 
> Il 08/09/23 18:24, Peter N. M. Hansteen ha scritto:
> > On Fri, Sep 08, 2023 at 10:01:45AM +0200, Alessandro Baggi wrote:
> > > I've a problem. I need to upgrade OpenBSD from 6.5 to 7.3 on an APU2D. 
> > > This
> > > is a firewall.
> > > The problem is that I cannot find older ISO of OpenBSD. Can someone point 
> > > me
> > > in the right direction?
> > 
> > If you are planning to go the supported route and upgrade from release to 
> > release,
> > you have eight rounds of upgrading ahead.
> > 
> > If this is a firewall that does not do anything else, I would join a few of 
> > the
> > other posters here in recommending that you back up the tiny number of files
> > that could differ from a default install do a fresh reinstall, only editing
> > in the things you need from your old /etc/ such as (likely most of) pf.conf.
> > 
> > - Peter
> > 
> 
> Actually I upgraded from 6.5 to 7.0 and I learned many new things. Wow...I
> love OpenBSD.

Please tell us about your experience ! it's probably going to be rather
interesting.

Re: Why does `pkg_info -m` show quirks?

[Marc Espie]

On Sat, Aug 19, 2023 at 07:21:58PM +0200, Ingo Schwarze wrote:
> Hi,
> 
> Stuart Henderson wrote on Fri, Aug 18, 2023 at 05:52:07PM -:
> > On 2023-08-18, l...@ena.re  wrote:
> 
> >> Also, what is the reason the quirks package does not have a man page?
> 
> Usually, there is no manual page documenting a package as a whole.
> 
> >> I believe it should have one, just like any other program.
> 
> The quirks package certainly isn't a program.
> Right now, i fail to see any evidence that it even *contains* any program.
> 
> >> Is this something that is desired?
> 
> The following is certainly not a good syllogism:
>   "There is no manual page documenting this package"
> => "We need a manual page documenting this package"
> 
> Even the folliwing, weaker syllogism may occasionally be false:
>   "This package contains no manual page"
> => "We should write a manual page to include in the package"
> 
> Is information about the quirks package missing from the manual pages?
> Maybe, it doesn't seem unlikely to me, but i'm far from sure.
> 
> >> If so, I would gladly model one after the package description.
> 
> What a terrible idea.  Most of that information is already contained
> in the manual page sthen@ mentioned:
> 
> > packages(7) - overview of the binary package system
> 
> I think what packages(7) says is also easier to understand than
> what the quirks package description says.
> 
> > not sure what such a manpage would be named.
> 
> Given that manual pages are named after programs, functions, devices,
> or file formats,
> 
>$ pkg_info -L quirks
> 
> tells me that a manual page to be included in the quirks package
> could be named:
> 
>   OpenBSD::Quirks(3p)
> 
>- that one would document the Perl API of the OpenBSD::Quirks
>  Perl package, similar to e.g. OpenBSD::PackingElement(3p)
>  or OpenBSD::State(3p)
> 
> or
> 
>   update.db(5)
> 
>- that one would document the file format of the file
>  /usr/local/share/update.db and explain how that file
>  is used, similar to mandoc.db(5) or locate(1) --
>  by the way, it does look like we are missing a
>  locate.database(5) manual page
> 
> > it is already described here though:
> > $ man -k any=quirks
> > packages(7) - overview of the binary package system
> 
> Right, any information about the quirks package that doesn't
> belong into OpenBSD::Quirks(3p) or update.db(5) probably
> belongs into packages(7) or pkg_add(1).
> 
> Yours,
>   Ingo
> 
from my phone so bear with me for the poor formatting.

the whole point of quirks is to deal with unforeseen
upgrade issues. So there's no point in documenting
an api that's meant to evolve and be abused as needs
arise.

Re: error when pkg_add'ing

[Marc Espie]

On Tue, Jun 27, 2023 at 08:56:41PM +0100, li...@xza.fr wrote:
> > Having A LOTS of problems in pkg_check usually means something in your
> > process is REALLY BAD.
> > 
> > As the guy who wrote (most of) pkg_add/pkg_check, I don't need pkg_check
> > all that often.
> 
> 
> Just wanted to say: thanks for writing pkg_add.
> 
> Don't know if it was by you, but also really appreciated also that 
> semi-recent 
> update to pkg_add which made package updates (pkg_add -u) significantly 
> faster.
> 
> 
Yeah, it was a really fun one to write.

I should talk about the technical details at eurobsdcon in coimbra
next september

Re: error when pkg_add'ing

[Marc Espie]

On Sat, Jun 24, 2023 at 06:44:11PM +0200, Pau A.S. wrote:
> thanks so much, Marcus; pkg_check helped to identify a LOT of corrupted
> files, which I deleted; after that I ran pkg_add -vu and it looks that one
> file survived:

Having A LOTS of problems in pkg_check usually means something in your
process is REALLY BAD.

As the guy who wrote (most of) pkg_add/pkg_check, I don't need pkg_check
all that often.

And it's mostly because of flakiness in the base system!!!
if you end up fixing A LOT through pkg_check, it means
that SOMETHING ELSE is usually wrong.

ifconfig vs lladdr

[Marc Espie]

Maybe I'm stupid, but the way we proceeded with disks was with
making euids integral part of mount(8).

Why not do the same with lladdr and ifconfig (and lower parts)
(possibly with an option, though 60a44ce81465  is rather recognizable
as a MAC) ?

Re: xine's ffmpegaudio doesn't downmix, sio_getpar() reports 6 channels instead of 2

[Marc Espie]

On Mon, Oct 03, 2022 at 09:26:31AM +0200, Alexandre Ratchov wrote:
> On Thu, Sep 22, 2022 at 04:31:58PM +, 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
> > uaudio0 at uhub2 port 3 configuration 1 interface 1 "GeneralPlus USB Audio 
> > Device" rev 1.10/1.00 addr 6
> > uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls
> > audio0 at uaudio0
> > uhidev2 at uhub2 port 3 configuration 1 interface 3 "GeneralPlus USB Audio 
> > Device" rev 1.10/1.00 addr 6
> > 
> > It has only 2 channels for playback.
> > 
> > The file has 5.1 aac audio:
> > $ ffprobe file.mp4
> > [...]
> > Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 
> > 224 kb/s (default)
> > [...]
> > 
> > Xine's ffmpegaudio plugin is supposed to do downmix (please, correct
> > me if I'm wrong), but:
> > 
> > $ xine --verbose=2 file.mp4
> > [...]
> > audio_out: ao_open (0x585415540)
> > audio_sndio_out: ao_sndio_open bits=16 rate=48000, mode=128
> > audio_sndio_out: ao_sndio_open 6 channels output
> > [...]
> > 
> > The code in xine-lib-1.2.12/src/audio_out/audio_sndio_out.c by Brad
> > Smith is following the recommendations at sio_open(3), there is no
> > problem there.
> > 
> > sio_getpar() is returning 6 channels as valid, so the sound ends
> > messed up. The right speaker gets mostly ambient sound and the
> > voices are almost only audible through the left speaker.
> > 
> > mplayer and mpv have means to force downmix, but xine is the only
> > media player which can play 1080p h264 video with a decent performance
> > (if the bitrate is not too high) on an rpi4 (no hardware acceleration,
> > cpu at 2.2Gz)
> > 
> > One workaround for this particular case could be adding the
> > configuration setting "audio.output.speaker_arrangement" to
> > audio_sndio_out.c.
> > 
> > I'm using the last snapshot:
> > 
> > $ doas sysupgrade -ns
> > Fetching from https://ftp.OpenBSD.org/pub/OpenBSD/snapshots/arm64/
> > SHA256.sig   100% ||  1544
> > 00:00 Signature Verified
> > Already on latest snapshot.
> > 
> > base72.tgz  21-Sep-2022 11:41   262659517
> > 
> > Is this behaviour normal and I'm just missing something?
> > Some thoughts?
> 
> Hi,
> 
> This is a known problem. While mpv and mplayer have options to turn
> the downmixing, it's not OK this to be manual.
???

Cannot parse.
If you cannot write this in english, please say what's going on in french.

> IMHO, the most appropriate (and probably simplest) is to extend sndiod
> to do the surround conversions, so the problem would be solved at
> system level and all players would benefit (as we do for all other
> conversions, btw). Less code, less bugs.

As far as I know, we still need to address liba52 levels.
Last time I checked, nobody but aja and I were concerned, and we couldn't
figure out (on most AC3 videos, sndio levels are 100% subpar).

Also, I'm questionning where master.level=1.00 makes sense. In many many cases
the application doesn't do more, but sndio could (possibly) boost to 200% and
be fine.

Moonshot: I was promised a land where sndio would take over audio(4) and where
I could get hardware AC3 through sndio. I have an USB sndcard that should
deliver this.

How far away are we from the promise ?

I couldn't care less about "real time" mixing. I really want surround sound
on video...

inaccuracy in the faq regarding ntpd

[Marc Beste]

Dear Sir or Madam,

when writing a script to check if my local NTP server is providing the
time to my network I have noticed a slight inaccuracy in the FAQ
regarding the status of ntpd in logs.

https://www.openbsd.org/faq/faq10.html#OpenNTPD

Where it says:
'a "clock now synced" message will appear in /var/log/daemon'

it should say:
'a "clock is now synced" message will appear in /var/log/daemon'

I have observed this on OpenBSD 7.1 amd64.
Thank you very much for your time and effort.

Best regards, Marc

Re: A minimal browser in base

[Marc Espie]

We used to have lynx in the base system.

It was removed because of security concerns and no-one willing to 
audit/replace it.

This is a fairly common pattern in OpenBSD. Considering the complexity of
the web, I don't see this ending any differently with any other text 
browser.

Re: port builds with inline source

[Marc Espie]

On Wed, Jun 29, 2022 at 04:51:49PM -0700, Lyndon Nerenberg (VE7TFX/VE6BBM) 
wrote:
> We have a number of in-house utilities that we push out as packages.
> Right now these are built using the standard make framework, with
> a bunch of hand-crafted glue to build and sign the packages before
> pushing them to our internal distribution server.
> 
> I would really like to take advantage of  to automate
> as much of the packing process as I can.  The problem is that port
> builds assume you're obtaining the program source from external
> distribution files, whereas I want to build right out of the port
> directory itself, i.e. have the program source live under
> /usr/ports/foo/bar/src/.
> 
> Has anyone come up with an idiomatic solution to this that doesn't
> involve surgery on /usr/share/mk/*port*?

have DISTFILES be empty, put your sources under FILESDIR
and a bit of glue to ln/mv them into WRKDIR since you got to have a WRKDIR
for ports.

reminder: ports snapshots go with base snapshots

[Marc Espie]

If you don't update base first (as you should always do),
recent package snapshots will break.

Code to parse the hash after
@option always-update 
was added on May 26.

Package snapshots built after May 28 use that new syntax.

You will notice fairly early, as quirks uses
@option always-update

the new package will refuse to install with an error
from the packing-list parsing code:

"Unknown option: always-update "

Re: broken Compress::Bzip2 module in OpenBSD 7.1

[Marc Espie]

On Mon, May 30, 2022 at 08:22:27PM -0300, Alceu Rodrigues de Freitas Junior 
wrote:
> Hello folks,
> 
> I think I might have found a bug with OpenBSD 7.1 (7.1 GENERIC.MP#465 amd64)
> default perl, but first I would like to at least investigate a bit further.
> 
> During a execution of a CPAN Smoker, I got this error:
> 
> perl:/home/goku/perl5/lib/perl5/amd64-openbsd/auto/Compress/Bzip2/Bzip2.so:
> undefined symbol 'BZ2_bzlibVersion'
> ld.so: perl: lazy binding failed!
> Killed
> 
> The Compress::Bzip2 module was being installing as part of the Smoker setup
> with the cpan client, so I'm not sure which module required it. Anyway, I
> never experienced such error before, although there is a registered failed
> test (from me!) in the past 
> (https://www.cpantesters.org/cpan/report/e3330890-c9e5-11ea-992b-d0f4c78c3247),
> but I never the smoker process was being killed.

And yet, the p5-Compress-Bzip2 package doesn't appear to have any issue.

Now, it doesn't contain that exact same symbol, but rather:
XS_Compress__Bzip2_bzlibversion

looking at things, I think your setup assumed bzip2 was present in the base
system. Not so.

The p5-Compress-Bzip2 port both has a dependency on the bzip2 library
AND a config.in change to handle stuff under /usr/local.

I would tend to assume you need to tell your home-grown setup to look
in /usr/local... which is obviously disabled by default here.

Re: OpenBSD ftp and libtls: how to use session resumption with -S

[Marc Espie]

On Sun, May 08, 2022 at 10:42:52AM +0200, Hiltjo Posthuma wrote:
> On Sat, May 07, 2022 at 10:13:40PM +0200, Marc Espie wrote:
> > On Fri, May 06, 2022 at 08:13:42AM -, Stuart Henderson wrote:
> > > On 2022-05-06, Theo Buehler  wrote:
> > > > While we could readily make libssl fall back to the legacy stack if
> > > > SSL_OP_NO_TICKET is disabled, I don't think this optimization outweighs
> > > > the overall benefit of TLSv1.3 - better protocol, cleaner code.
> > > 
> > > Especially when the major beneficiary of this is pkg_add when it
> > > searches for updates; the number of connections has been *hugely*
> > > reduced with the caching added recently.
> > 
> > I haven't enforced it, but https for pkg_add  makes zero sense
> > anyway: you don't gain any confidentiality, and the integrity of
> > the package is ensured by the signatures.
> > 
> > Note that https for base release makes little sense as well, apart
> > from the initial installs. Updates will also rely on signatures,
> > so all you gain from https is... exercising tls, and noticing
> > connections are slower.
> > 
> > (also: authentication is slow for old time architectures).
> > 
> > I'm still wondering what's the point of https for all this.
> > 
> 
> The actual HTTP data sent (not just the package data itself) is not 
> immediately
> visible, filterable or changed by a MiTM. They also cannot easily see which
> packages are installed or filter errata's, right?

Actually pkg_add is mostly predictable, for debug reasons, and all data
*sizes* are still very visible.

Knowing you talk to cdn.openbsd.org, just by looking at the packet sizes
you can predict what packages are getting installed/updated.

Re: OpenBSD ftp and libtls: how to use session resumption with -S

[Marc Espie]

On Fri, May 06, 2022 at 08:13:42AM -, Stuart Henderson wrote:
> On 2022-05-06, Theo Buehler  wrote:
> > While we could readily make libssl fall back to the legacy stack if
> > SSL_OP_NO_TICKET is disabled, I don't think this optimization outweighs
> > the overall benefit of TLSv1.3 - better protocol, cleaner code.
> 
> Especially when the major beneficiary of this is pkg_add when it
> searches for updates; the number of connections has been *hugely*
> reduced with the caching added recently.

I haven't enforced it, but https for pkg_add  makes zero sense
anyway: you don't gain any confidentiality, and the integrity of
the package is ensured by the signatures.

Note that https for base release makes little sense as well, apart
from the initial installs. Updates will also rely on signatures,
so all you gain from https is... exercising tls, and noticing
connections are slower.

(also: authentication is slow for old time architectures).

I'm still wondering what's the point of https for all this.

Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

[Marc Espie]

Look, can we all just agree it is just a question of adding appropriate
verbiage to the port/package, sticking a huge CAVEAT on the documentation
leading to it, and go back to writing actual code ?

Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

[Marc Espie]

On Wed, May 04, 2022 at 07:45:32AM -0400, Raul Miller wrote:
> On Wed, May 4, 2022 at 4:15 AM Sebastien Marie  wrote:
> > The main problem I am seeing would be maintaining such lists, and it 
> > necessary
> > means manual addition to add only "safe" files to remove (no libraries at
> > least).
> 
> Conceptually speaking, it's possible to track library dependencies,
> and it's possible to build tools for doing so, and it's possible to
> automate this. ldd already does a lot of the work here, and a
> conceptual sysclean replacement might provide toolchain and/or install
> time and/or backup time support for tracking executable locations.
> (Conceptually, this kind of tracking would use some directory
> structure to support independent updates, and would itself be subject
> to [careful] cleanup. Some small redundancy here would probably be
> fine.)

It is not that simple.

Ports has such a tool for library tracking and automatic generation of
WANTLIB.

There are lots of caveats
- it's slow,
- taking care of library paths is complicated,
- taking care of library paths is ambiguous,
- some modern software prefer dlopen.

(We have a handful of ports that have WANTLIB that are not statically detected.
Some modern stuff in qt and gnome land will tend to dlopen some specific
components like database drivers and crypto libraries, in order to be able
to use it if it's installed or not if it's not.

I *think*, from what Antoine told me, that there's even a generic framework
somewhere in gnome that tries to use this all the time instead of classic
dynamic linking).

That said, I value the information sysclean gives me... but then I clean
my system manually regularly, and most often I know exactly what I'm getting
rid of.  All the horrors stories I've seen in this discussion are related
to people trusting it blindly/automatically.

Re: pkg-readmes missing for gnome and kde?

[Marc Espie]

On Sun, May 01, 2022 at 11:31:07PM +0300, Mihai Popescu wrote:
> On Sun, May 1, 2022 at 11:17 PM Antoine Jacoutot  
> wrote:
> >
> > On Sun, May 01, 2022 at 11:06:15PM +0300, Mihai Popescu wrote:
> > > On Sun, May 1, 2022 at 9:05 PM Antoine Jacoutot  
> > > wrote:
> > > >
> > > > On Sun, 2022-05-01 at 20:51 +0300, Mihai Popescu wrote:
> > > > > Hello,
> > > > >
> > > > > I tried to enable gnome or kde after install in an openbsd snapshot 
> > > > > for amd64.
> > > > > Last time (some time ago) I know for sure there were some pkg-readmes
> > > > > for both gnome and kde start. I can't find them now, I have some
> > > > > readmes in the directory, but not for gnome nor kde.
> > > > >
> > > > > Is there some other way used to document gnome or kde start, please?
> > > > >
> > > > > Thank you.
> > > >
> > > > # pkg_add gnome
> > > >
> > > > There will be a readme under:
> > > > /usr/local/share/doc/pkg-readmes/gnome
> > > >
> > > > --
> > > > Antoine
> > >
> > > That's exactly how I installed gnome. Still no readme file. Here is what 
> > > i have:
> > > $ cd /usr/local/share/doc/pkg-readmes/
> >
> > That means gnome is not installed.
> > Check pkg_info.
> 
> It was not. I was cooking at the same time and didn't pay enough
> attention to the output.
> Issued the install command again , it seems some packages didn't come out.
> Also I sent this to misc@ instead of ports@.
> 
> p# pkg_add gnome
> quirks-5.17 signed on 2022-04-28T19:56:28Z
> Can't find sushi-41.2
> Can't find evince-42.2
> Can't install gnome-42.0p1: can't resolve sushi-41.2,evince-42.2
> Couldn't install evince-42.2 gnome-42.0p1 sushi-41.2
> 
> 
Check your mirror/wait for things to synch out.

Re: Font Path prompt in pkg_add

[Marc Espie]

On Thu, Apr 28, 2022 at 02:37:39PM -0500, Christopher Turkel wrote:
> I'm on OpenBSD AMD64 7.1, fresh install
> I noticed when adding fonts via pkg_add it no longer prints out "You may
> wish to" after installation is finished.

It's related to the evolution of X windows.

Quite a few years ago, fonts were mostly handled server-side.

Keith Packard started a large change in X fonts a few years ago.

Most modern applications deal with X fonts client side.

The rationale behind the change is that people who deal with
server-side font info will know about the way to change the
server path.

Most new font directories are related to new applications, so
those messages were irrelevant.


Side note: there's a big focus from some people in OpenBSD
to keeping tools mostly silent (as opposed to the awfully
chatty linux thingies).  Sometimes, this has disproportionate
consequences. End users do see those messages, whereas there's
a HUGE amount of churn in the tools that DON'T end in any visible
messages and has FAR MORE REACHING consequences to the quality
of those tools. ;)

Re: OpenBSD and multitasking

[Marc Espie]

On Tue, Apr 26, 2022 at 01:40:46PM +0200, Stefan Hagen wrote:
> Mihai Popescu wrote (2022-04-26 01:13 CEST):
> > I use OpenBSD amd64 snapshots on the following dmesg hardware.
> > The download rate on a browser was slow and I figured out with some
> > memory mapped partition that disk transfer rate was slow.
> > I can bear this since I'm not into large file transfer business. But
> > here is another interesting fact: each time my disk is used by some
> > file transfer, all the running applications, mostly GUI based are
> > stalling - that includes mostly chromium ( even if it is not chromium
> > that it does the disk data transfer).
> > 
> > My questions are: is something incorrectly set up on my computer,
> > regarding the multitasking?
> > I understand disk operations are slow, but may I say that kernel is
> > dragged in that slow transfer too (no DMA, no cache, etc.)?
> > Does this happens to all users, but since there are more powerful
> > configuration involved the delay is not so noticeable?
> 
> Mount your file systems with the softdep flag (described in mount(8)).
> This should bring HDD i/o to what you're used to on other operating 
> systems.

This has the unfortunate side-effect that this is not quite the official
configuration. softdep is somewhat supported but if you experience panics
related to this, good luck getting them fixed.

(I've stopped using softdep entirely on bulk machines. NFS having burps
from time to time is enough to cope with)

syspatch brought system to 7.1-stable (was Re: Sprurios errors from syspatch -c)

[Marc Peters]

On Fri, Apr 22, 2022 at 08:51:43PM -0600, Theo de Raadt wrote:
> And of course, the syspatch testing procedures will get another step or
> two to make sure this doesn't happen again
> 
> So just wait.

Thank you for explanation and clarification. Two of my systems were already hit 
by that mishap.

Best,
Marc

Re: Auto layout for disk partitions - a new user's perspective

[Marc Espie]

For people who really want to tinker with the ports system,
perhaps non intuitively, bulk(8) is the manpage that contains
the most exhaustive set of information about how you might
want to configure your system and the choices involved.

Re: [www] ports: delete note about $OpenBSD$

[Marc Espie]

On Thu, Apr 07, 2022 at 02:33:36PM +0300, Mikhail wrote:
> This advice no longer needed.
> 
> diff --git a/faq/ports/guide.html b/faq/ports/guide.html
> index 9cfe0db80..ae3d1d79c 100644
> --- a/faq/ports/guide.html
> +++ b/faq/ports/guide.html
> @@ -1303,12 +1303,6 @@ OpenBSD is strongly security-oriented.
>  You should read and understand this page's
>  security section.
>  
> -
> -Be sure to add the OpenBSD CVS tag to the Makefile.
> -The account name, version number, etc., will be filled in automatically
> -by CVS during commit, you do not need to add those or touch those lines
> -in an update.
> -
>  
>  The goal is to get all ported applications to support OpenBSD.
>  To achieve this goal, feed patches to support running on OpenBSD back to
> 
> 
Committed thx

Re: chroot for go webserver with pledge and unveil

[Marc Espie]

On Tue, Mar 15, 2022 at 11:32:19PM +0100, i...@tutanota.com wrote:
> Since Go has support for pledge and unveil, I was thinking about
> "imitating" the setup for httpd.
> 
> I basically need to run a Go webserver with access to MariaDB,
> but would like to chroot the Go webserver.
> 
> I was thinking that since Go by default doesn't run a webserver on
>  port 80 or 443, I would just spawn as www user on some higher
>  port and then use PF to redirect.

The age old practice of dropping privileges just works.

I assume go has bindings for setuid() and friends.

Re: Please put vi in base

[Marc Espie]

On Sun, Mar 13, 2022 at 05:54:03PM -0700, Jacqueline Jolicoeur wrote:
> Hi,
> 
> On Mar 12 16:39, i...@tutanota.com wrote:
> > I know I am not going to get any points for this, but I had to fix a broken 
> > OpenBSD box today that could not boot and I didn't have any network for a 
> > couple of hours, which made me stuck with ed from the boot media.
> 
> I encountered a problem just like you did. It would be nice to have vi 
> included in the install media yet the size makes it unrealistic.
> 
> > I spend hours wasting time, banging my head into the wall. Until I finally 
> > got network up on another machine and figured out a way to mount another 
> > OpenBSD disk in order to get access to vi in order to edit the files on the 
> > broken box.
> 
> This made me realize how important taking a few hours to learn and practice 
> basic edits with ed(1) was. Now is a great time to learn it.

Unless the install is badly broken, fsck on /usr, /var, mount them, set
TERM to something decent, and you got vi.

Re: What happened to www/art on CVSWeb? Why is it empty?

[Marc Espie]

On Thu, Feb 10, 2022 at 11:25:40AM -0500, Nick Holland wrote:
> On 2/10/22 6:34 AM, Kacper Wilgus wrote:
> > I tried to download some artwork from these pages:
> > 
> > https://www.openbsd.org/art1.html
> > https://www.openbsd.org/art2.html
> > https://www.openbsd.org/art3.html
> > 
> > But only the first one has an image, the rest of them give me 404
> > errors and I swear they used to be there just a year ago. And the
> > wayback machine proves this. Was it an error, or copyright issues?
> > It seems wierd it was just snapped out of existence without any warning.
> > 
> 
> art[123].html hasn't been referenced from the main page since OpenBSD 5.8
> (see the removal in version 1.686 of index.html, and they are not currently
> referenced in any page on the website other than art[123].html so I think
> it is safe to say it was not being maintained and deleted at some point.
> 
> I have no other info than it looks like the "problem" is more the
> continued existence of art[123].html more than the missing images.
> 
> Nick.
> 
> 
A quick look at the full cvs repository shows a few .jpg and QUITE a few
.gif in the Attic.

Just saying ;)

Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"

[Marc Espie]

On Mon, Jan 24, 2022 at 10:21:33AM +0100, Harald Dunkel wrote:
> I highly appreciate the carefulness, but the error message doesn't
> indicate a user "_pkgfetch", nor is it mentioned on pkg_add(1).
> Please reconsider my suggestion made on 2022-01-14:
> 

Note that smtpd(8) doesn't mention all the users and processes it used
for privilege separation either.

Those are implementation details and will work out-of-the-box unless
you fiddle with parts you're not supposed to touch.


and if you touch those parts... you're supposed to know where to look and
how things work in the background.

Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"

[Marc Espie]

On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote:
> On 2022-01-17 18:02:25, Marc Espie wrote:
> > 
> > Lol.
> > 
> > cert.pem only contains public certificates. Insisting on only root being
> > able to read it means you are going to run code as root which doesn't 
> > require
> > it. That seems way more unreasonable than your original assumption.
> > 
> 
> I am not arguing about the access permissions (which I screwed
> up), but I wonder why pkg_add run by root failed with EPERM?
> Actually root was the only one *permitted* to access this file.
> Thats not an error.

Because we use this nifty technique called privilege separation to alleviate 
issues
with bugs.

Most specifically, pkg_add runs as root, which has wy too many rights, so 
it 
doesn't connect to the network directly, it starts ftp(1), which runs as 
_pkgfetch,
which passes its result to signify which can check that the archive is properly 
signed
before decompressing it with the zlib and finally putting the result on your 
disk.

It's not rocket science, privilege separation has been around for over 20 years 
at
this point ;)

Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"

[Marc Espie]

On 2022-01-14, Harald Dunkel  wrote:
> On 2022-01-14 10:42:56, Harald Dunkel wrote:
>> 
>> Hi folks,
>> 
>> trying to upgrade the installed packages I get
>> 
>> # pkg_add -u
>> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect 
>> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied
>> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect 
>> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied
>> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty
>> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ...
>
>   chmod a+rx /etc/ssl
>
> did the trick, but this doesn't look reasonable.

Lol.

cert.pem only contains public certificates. Insisting on only root being
able to read it means you are going to run code as root which doesn't require
it. That seems way more unreasonable than your original assumption.

Re: Install latest package without prompts on OpenBSD 7.0

[Marc Espie]

On Mon, Jan 10, 2022 at 10:54:22AM -0500, Ian Darwin wrote:
> > > > I am working on OpenBSD 7.0, x86_64. I'm trying to script an install
> > > > of developer tools I use, like GCC and Git. When I attempt to install
> > > > GCC I am prompted:
> > > > 
> > > > $ sudo pkg_add gcc g++
> > > > quirks-4.54 signed on 2022-01-09T19:08:35Z
> > > > Ambiguous: choose package for gcc
> > > > a0: 
> > > > 1: gcc-8.4.0p9
> > > > 2: gcc-11.2.0p0
> > > > 
> > > > I've looked over the man page at https://man.openbsd.org/pkg_add, but
> > > > I don't see an option to tell pkg_add to install the latest version of
> > > > the package.
> > > 
> > > Sure there is. 
> > > 
> > > Quoting the manpage:
> > > There is also an ambiguity related to ports with multiple branches.  
> > > For
> > > instance ‘pkg_add python’ is ambiguous, as there are several versions 
> > > of
> > > python in the ports tree.  So is ‘pkg_add postfix’.  The special form
> > > ‘pkgname%branch’ can be used to restrict matches to a branch matching 
> > > the
> > > pkgpath(7).
> > > 
> > > pkg_add gcc%11 g++%11
> > > will do the trick

> In the context of the original post, I think he meant a way to invoke 
> "pkg_add" and have
> it just install whatever the latest is, without having to know a priori that 
> there is a version 11.
> "Just install gcc, dammit". There are many ports that have version choices 
> and in the context
> of installing the latest of everything in a "scripted install", having to 
> either stop mid-install
> and answer such a prompt, or sort out in advance what ports exist in multiple 
> versions,
> is not what's wanted. It may be unwise, but it's what some people that do 
> scripted installs want.
> I have wished for this too, but it never bothered me enough to send a query. 
> :-)

For production (and thus automated installs) you do not want the latest.

We have branches and they should be used for that.

Granted, the gcc port naming is probably not the best ever.

But... what's your arch ? do you *really* want a gcc 11 that might not work
at all on your arch.


Sorry.   There is a lot more going on.   We could have further annotations
to let scripts decide between "most stable", "best esr", "most likely
to win a beauty contest"

Re: Install latest package without prompts on OpenBSD 7.0

[Marc Espie]

[forgot to Cc the list]

On Mon, Jan 10, 2022 at 11:36:04AM +0100, Marc Espie wrote:
> On Sun, Jan 09, 2022 at 10:03:01PM -0500, Jeffrey Walton wrote:
> > Hi Everyone,
> > 
> > I am working on OpenBSD 7.0, x86_64. I'm trying to script an install
> > of developer tools I use, like GCC and Git. When I attempt to install
> > GCC I am prompted:
> > 
> > $ sudo pkg_add gcc g++
> > quirks-4.54 signed on 2022-01-09T19:08:35Z
> > Ambiguous: choose package for gcc
> > a0: 
> > 1: gcc-8.4.0p9
> > 2: gcc-11.2.0p0
> > 
> > I've looked over the man page at https://man.openbsd.org/pkg_add, but
> > I don't see an option to tell pkg_add to install the latest version of
> > the package.
> 
> Sure there is. 
> 
> Quoting the manpage:
> There is also an ambiguity related to ports with multiple branches.  For
> instance ‘pkg_add python’ is ambiguous, as there are several versions of
> python in the ports tree.  So is ‘pkg_add postfix’.  The special form
> ‘pkgname%branch’ can be used to restrict matches to a branch matching the
> pkgpath(7).
> 
> pkg_add gcc%11 g++%11
> will do the trick
> 

Re: pkg_add issues

[Marc Espie]

On Mon, Jan 03, 2022 at 12:21:17PM -, Stuart Henderson wrote:
> On 2022-01-02, Jon Fineman  wrote:
> > I am in New Jersey. Is there a way for me to tell what the cdn was 
> > pointing to to help find the slow/sick server?
> 
> It's shown in HTTP response headers from cdn. Almost certainly
> it was pointing at a machine which only serves the cdn and you cannot
> access directly.

pkg_add explicitly shows it in the first file it retrieves.

For various reasons (consistency), we don't do cdn round-robin on each
package. The Redirect from the first connection will be automatically
re-used in the subsequent connections.

Re: Exit status of pkg_add

[Marc Espie]

On Tue, Oct 19, 2021 at 10:42:04AM +0900, Yuichiro NAITO wrote:
> Following patch changes pkg_add to return a error code,
> if a package name is wrong.
> 
> diff --git a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> index 7a968cbf05d..39bee874ff1 100644
> --- a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> +++ b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> @@ -403,12 +403,13 @@ sub check_root
>  sub choose_location
>  {
>   my ($state, $name, $list, $is_quirks) = @_;
>   if (@$list == 0) {
>   if (!$is_quirks) {
>   $state->errsay("Can't find #1", $name);
> + $state->{bad}++;
>   $state->run_quirks(
>   sub {
>   my $quirks = shift;
>   $quirks->filter_obsolete([$name], $state);
>   });
>   }
> 
> Is it OK?
> 
> On 10/18/21 16:53, Yuichiro NAITO wrote:
> > Hi, I have a question about exit status of pkg_add command.
> > 
> > When I wrote a package install script which included typo in a package name
> > (of course it's my fault), the script didn't stop in spite of `set -e`.
> > 
> > Because pkg_add command returns 0 even if a package name is wrong.
> > Is this exit status intended or design policy of pkg_add command?
> > 
> > If not, I want a error status getting returned.
> > It will save my time to look for a typo or similar bug.
> > 
> > I can't see 'EXIT STATUS' section in the pkg_add manual of OpenBSD 7.0.
> > So, I e-mailed this question.
> > 

Basically, there are a few traps in pkg_add wrt exit status.

The main trap is that making pkg_add error out in cases it didn't requires
testing, because various automated situations that already exist might fail.

I will most probably fix that one, assuming there is no fallout.

Re: Keeping a personal ports branch

[Marc Espie]

On Fri, Oct 15, 2021 at 10:25:17AM -, Rubén Llorente wrote:
> Hi there!
> 
> I am wondering how does people around here keep local branches of the ports
> tree for personal use.
> 
> The reason I am asking is because I keep some patched ports which are suited
> to solve my problems, but not suited (or useful) for submission to the
> official ports tree. Ideally I would upgrade my personal ports tree alongisde
> the official one.
> 
> I suppose I could cvs import every -RELEASE of the ports into my own cvs
> repository, but ideally I would rather have something more automated.
> Besides, I am curious as to how people is doing it.

Put your own ports into mystuff...

if you think they might interest other people, see whether the WIP git repo
would be suitable for them, until they're mature enough.

Re: pkg_add still reporting incorrect actions

[Marc Espie]

On Sun, Oct 10, 2021 at 09:29:24AM -, Stuart Henderson wrote:
> On 2021-10-10, Otto Moerbeek  wrote:
> > On Sun, Oct 10, 2021 at 11:09:58AM +0300, Mihai Popescu wrote:
> >
> >> On Sat, Oct 9, 2021 at 11:55 PM Chris Bennett <
> >> cpb_m...@bennettconstruction.us> wrote:
> >> 
> >> > On Sat, Oct 09, 2021 at 09:53:46PM +0300, Mihai Popescu wrote:
> >> > > I am running amd64-current from snapshots. I am installing a lot of
> >> > > packages using pkg_add -vV pkg1 pkg2 ...
> >> > >
> >> > > I got some strange reports, see below. This is the third email about
> >> > this,
> >> > > maybe isn't it a big deal.
> >> > >
> >> >
> >> > pkg_add -Dsnap  is needed when snapshots and release are next to each
> >> > other
> >> > .
> >> > Chris
> >> >
> >> >
> >> I am not on a release kernel. This was observed on my computer on other
> >> snapshots, I have at least 2 reports on misc@.
> >> I don't know perl, so I am not able yet to figure out what is happening.
> >> But as with many other reports, sometimes it will be fixed.
> >
> > If you are running a snap kernel, it might think it is a release
> > kernel close to release. That's the whole point. Use -D snap and
> > you'll be ok.
> 
> The reported problem is nothing to do with snapshot/release, it's a strange
> ordering of the update set.
> 
> Mihai, please ask on ports@, maybe cc espie to make sure he sees it, I think
> he will know whether it's a problem or not.

I expect it's probably just the summary line being slightly out-of-date.

What's actually important is whether updates happened correctly or not, it
is fairly low on my priority list.

Re: Why is tmpfs not working on OpenBSD?

[Marc Espie]

On Wed, Sep 08, 2021 at 09:54:52AM -0700, Chris Bennett wrote:
> On Mon, Sep 06, 2021 at 12:44:59AM +, iio7 wrote:
> > > > Why isn't it removed? It is kinda "misguiding".
> > >
> > > Shucks, you must feel terrible about our decision.
> > 
> > Well, compared to the fact that you, back in 2016, wrote that,
> > "We don't spend hours of our time adding unimportant notes to that file.", 
> > concerning updating the FAQ about this, maybe
> > instead of giving these useless comments, that you apparently
> > have got plenty of time to do, you should actually provide some
> > kind of useful information somewhere!
> > 
> 
> Wow. I guess a 2500 page FAQ would be much better.
> 
> But, I do believe I have found an important issue to add to the porting
> section of the FAQ.
> Although it covers submitting a single port, it does not cover how to
> deal with submitting a larger project with 20+ submissions.
> 
> I learned the hard way that the methods I was using to submit ports for
> a larger project just didn't work for getting these looked at and getting
> the two OK's needed for new ports. Oops.

Note that the main current issue wrt OpenBSD ports is the chronical lack
of time to look at everything that gets submitted.

"perfect submissions" tend to get looked at more easily, but it is
frequent to have to nag a bit to get people to look at it, especially when
it is not the most used port in the world.

(I do follow the "okay required to new ports rule" and I have to nag to
get things in as well)

-- 
Marc

Re: Why is tmpfs not working on OpenBSD?

[Marc Espie]

On Sun, Sep 05, 2021 at 10:12:33PM +, iio7 wrote:
> > On 2021-09-05, iio7 <
> i...@protonmail.com
> > wrote:
> >> # mount -t tmpfs tmpfs /home/foo/tmp/
> >> mount_tmpfs: tmpfs on /home/foo/tmp: Operation not supported
> 
> > It isn't built into the standard kernels, disabled with this commit::
> 
> > revision 1.229
> > date: 2016/07/25 19:52:56
> > disable tmpfs because it receives zero maintainance.
> 
> Why isn't it removed? It is kinda "misguiding".
> 

There might be hope that someone who has the time would do proper 
maintenance...  

Re: vi: count occurrences of a substring

[Marc Chantreux]

> Otherwise, if I try to just type
>   :!sed s/abc/abc\/g % | grep -c abc
> and press enter, I only get the same output I also get out of

same here! I so much wish it worked!

regards
marc

(technology sucks anyway) Re: vi: count occurrences of a word

[Marc Chantreux]

hello,

> That's a neat trick -- IFF you can be *sure* that character won't show
> up in the text. I also feel it's a workaround

this is ok as you can easily check if if the caracter won't show. this
is a "good enough" principle: don't try to fix *all* the cases, just fix
yours.

> understand *why* substituting/inserting newlines is something that
> seemingly cannot be made to work in OpenBSD sed, or whether the
> information on the sed(1) man page is really consistent with actual
> behaviour.

I'm really happy that sed, awk and all those commands didn't grown to
the point they are as heavy as dynamic langages interpreters but if you
want do get the job done, perl (and raku if you install it) are there
to cover you:

:w !perl -0 -nE'say 0+(@a=/abc/g)'

:w !raku -e 'say +words.grep(/abc/)'

if you need exactly the word abc:

:w !raku -e 'say +words.grep()'

> Observed oddities:

wow ... if you go down that path, you're not finished. Unix has a very
long and complex history of experiments, backward compatibilities,
standards and habits. long time ago i had a project to make shell
programming easier by patching all the tools so they have the same
defaut behavior (for example \t as default separator):

* this is a lot of work
* i didn't bet on a large adoption

so unix sucks as all old technologies.

* if you want something conceptualy less broken, give plan9 a try
* if you want something more polished, give vim+coreutils a try
* if you want something convivialist, obenbsd is the best trade off i
  seen (you can also give try to sbase or 9base)
* if you want something more consistent, let's start our project :)
* if you want something perfect, let it go :)

> Is anyone able to make sense of this?  Does anyone know if there's a
> reason or rationale behind the BSD sed implementation when it comes to
> newlines?

life is made of trades off :) sorry.

regards,
marc

Re: vi: count occurrences of a word

[Marc Chantreux]

hello,

>   :!sed s/abc/abc\n/g % | grep -c abc

Note: in sed, "what i just matched" is noted &

> Googled information suggests that the opposite of what's described in
> the man page may be true:  You CAN use a literal newline, but you
> can't use \n.

BSD sed is more litteral AFAIK so you need to escape a real 0x10 but
both GNU and BSD support escaped newlines:

sed 's/abc/&\
/g'

This doesn't help in vi so you can fake it for a moment using tr:

sed 's/abc/&œ/g' | tr œ '\n'

Another solution is to write commands for this kind of tasks: 

<<\. cat > ~/x
#! /bin/ksh

sed -r 's/a/&\
/g'
.

then from vi, :w !~/x

> literal carriage return, not a literal newline (^J).  That's the case
> on Linux as well, and I don't know why.

neither do i.

> Your new subject line is slightly imprecise, as words are usually
> whitespace-delimited, and I was "looking for a way to count
> occurrences of
> 'abc' in FILE".  Not every substring is a word.

right ... wasn't thinking that much to the name. sorry :)

regards
marc

Re: vi: count occurrences of a word

[Marc Chantreux]

hello,

> > so you can write:
> >
> > :w|grep -c abc %
> That doesn't really fit the bill:
> 1. This error message is produced: 'The grep command is unknown'

because i wasted it by missing the bang

 :w|!grep -c abc %

is a single line way to write

 :w
 :!grep -c abc %

> 2. grep only counts the number of lines.  If the 'abc' reappears in
> the same line, grep won't catch that.  My version will, however
> crufty, though it's arguably better/shorter/more portable to use your
> %:

true. is this fine enough ?

:w !tr -cs '[:alnum:]' '\n'|grep -c abc

> > :w !grep -c
> 
> That produces a grep usage prompt here, along with this message:
> 'grep -c: exited with status 2.'

... was an example: you can add your pattern there

 :w !grep -c abc

> Are you sure you've tested this and that you're using just plain (n)vi?

nvi debian and vi from openbsd 6.9

> Wow, that's... helpful(?), I think, but truth be told

oh yes it is :)

> I've tested
> none of this, because I'm slightly overwhelmed by what to me looks
> like far greater complexity than :E, ^W etc. -- and even than my
> occurrence-counting one-liner.

Fair enough. so check the quick ref about windows (:h Q_wi) especially
the ones that makes you feel the nvi way.

CTRL-W s  or  :splitsplit window into two parts
:split {file}   split window and edit {file} in one of them
CTRL-W ]split window and jump to tag under cursor
CTRL-W fsplit window and edit file name under the cursor
CTRL-W ^split window and edit alternate file
CTRL-W jmove cursor to window below
CTRL-W kmove cursor to window above
CTRL-W CTRL-W   move cursor to window below (wrap)
CTRL-W Wmove cursor to window above (wrap)
CTRL-W tmove cursor to top window
CTRL-W bmove cursor to bottom window
CTRL-W pmove cursor to previous active window

> Maybe I'm just not truly ready for vim (though I do use it at times).

there is no such thing as 'ready for vim'. nowadays, i still find stuff
on the vim help and think 'damn! i missed it since 25 years!' vi (and
vim) is a langage the way english is: lot of experience and vocabulary
helps you to be much more concise and precise but you don't need PhD
to have helpful cheap chats.

> None of the above is intended as throwing anything back in your face
> however, and I thank you very much for your reply.

I really don't took things personally and i know that vim is an
overbloated vi but some features are really awesome and the UI is
simpler to use (i don't care about the look but vim is more forgiven
and comes with helpful visual signals). On the other hand: nvi is a too
minimal subset of it to be my daily editor but it's really helpful for
simple sysop tasks.

>From time to time, someone starts a new clone to try to reach a new
balance but vim and nvi pleases enough people so those projects are doomed.

regards,
marc

vi: count occurrences of a word

[Marc Chantreux]

> 'abc' in FILE, from within vi.

* % means 'the current file' in vi commands so you can write
* | is the command separator
* grep has a -c flag to count occurrences

so you can write:

:w|grep -c abc %

you can also write the content of the buffer to a pipe (my prefered
solution here):

:w !grep -c

> Sadly, :E doesn't actually work in vim.  It says
> > E464: Ambiguous use of user-defined command

> I don't know what works in vim. vim prolly has a dozen
> chrome-electroplated ways to do the same thing, but I don't know them.

:h windows

also:

:h :new
:h :enew
:h gf
:h :bu
:h :ls
:h :bw

the following code isfrom my ~/.vimrc so i can:
 * navigate into buffers with  and  arrows
 * come back to the first buffer with 
 * have a fzf menu of the current buffers using 

set hidden
command! -nargs=0 BU redir! > ~/.v.json | silent echo json_encode(getbufinfo()) 
| redir END
  \| silent exec "!vim_BU ~/.v.json ~/.v"
  \|so ~/.v
  \|redraw!
nnoremap  :BU
nnoremap   :bfirst!
nnoremap   :bnext!
nnoremap  :bprevious!

the code of vim_BU (i can probably get grid of perl and use jq instead):

vim_BU () {
perl -MEnv -MJSON -w0 -nE'
map +( printf "%3s %s%s %s\n"
, $$_{bufnr}
, ( $$_{hidden}   ? "h"   : "a" )
, ( $$_{changed}  ? "+"   : " " )
, ( length $$_{name}  ? $$_{name} : "NONAME" )
    ), @{ decode_json $_ }
' $1 | fzf | awk '{print "bu "$1}' > $2
}

regards
marc

Re: vi golf: command on a motion?

[Marc Chantreux]

hello,

> The bang command has an equivalent in vi.

this is the same command indeed but the ergonomy is quite different:
vi don't "generate" the begining of a command including the range so
we can't just delete a char and edit.

> The closest you
> can get to executing the same replacement via a vi command is using the
> & command which operates on one line.

i forgotten & (not that useful in vim) but yes! now you reminds me, it
makes perfect sense to use it in nvi.

thanks.
marc

vi golf: command on a motion?

[Marc Chantreux]

hello people,

Does anyone know how to get this done even faster:

ma
}
:'a,ms/foo/bar

even if it's short, I really would like to have
something which work the way I abuse the ! command in vim:

!}

actually write a range on command line like

:.,.6!

so I just have to replace the ! by s/foo/bar and i get the job done.

anything i missed in the doc to be that concise with vi?

regards.
marc

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Marc Espie]

On Thu, Jun 24, 2021 at 02:56:16PM -0600, Theo de Raadt wrote:
> > I think the easiest path here is to incorporate the new upstream into a
> > port, unless someone is familiar with zlib and can cherrypick out the
> > commit(s) that resolve the issue. (I didn't find zlib in ports already.)
> 
> That is completely impossible.  It must be in base.  There are 3 copies
> in base -- userland, kernel, and bootblocks.  They must be kept in sync.

This is not even true, there is a 4th copy in perl's library.

Re: Who is responsible for ports.su? (admittedly a non-canon resource)

[Marc Espie]

I think that his approach is doomed to fail.

There are a lot of tricky parts to flavors and multipackages and 
normalization.  If you don't use the actual ports/packages framework code,
you have to figure it out all over again by yourself.

and there are lots of gremlins.

The official code is based off sqlports.

See how many commits there were to that code... especially the tree-walker
part and normalization part... that will give you an idea of everything
that must be gotten precisely right to yield good results.

(and btw, I initially wrote bogus code. I had a large debugging session
with Robert Nagy until I got the normalization part correct!)

Re: Packages/libraries in disarray after sysupgrade

[Marc Espie]

On Thu, May 13, 2021 at 10:47:11PM +, tetrahe...@danwin1210.me wrote:
> After upgrading 6.8->6.9 (stable, not current) using sysupgrade, I am
> finding it not possible to install packages via pkg_add
> 
> When I try to install something, I get a series of errors like " dependency library name>: bad major" or ": minor is too
> small"
> 
> I am assuming I need to be installing new packages with `pkg_add -U` to
> update the dependencies as needed. However, the manpage suggests this is not
> desirable.

Sometimes, base snapshots and package snapshots are slightly out of synch.
this is what happened (rapid bumps to the crypto parts in base).

If you really know what you're doing, you can often work your way around it
by filling in the gaps. :)


As far as pkg_add -U, it's been developed as a quick solution to be able
to install a new package on-the-fly without having to update 600+ packages
first (like say, you figured you're missing an important component right
before you go live at a conference).

But you end up with a "skewed" package set coming from different snapshots,
so you're relying on everyone not missing any bump and not missing a "tight"
dependency between two library versions... works most of the time but... not
guaranteed.

Re: Can't compile php from ports

[Marc Espie]

On Fri, May 07, 2021 at 11:08:00PM +, Mik J wrote:
> Hello,
> Does anyone knows why compiling php from ports systematically fails ? It's 
> been since openbsd 6.8 that it acts this way

Why do you ask this on misc@ instead of ports@ ?

Second, it actually works for all of us... so it must be something
you're doing.

> Renaming /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/Makefile.new to 
> Makefile
> > Extracting debug info from 
> > /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/php-7.4
[...]
> Installing /usr/ports/lang/php/7.4/pkg/php74_fpm.rc as 
> /usr/ports/pobj/php-7.4.19/fake-amd64/etc/rc.d/php74_fpm
> ===>  Building package for php-7.4.19
> Create /usr/ports/packages/amd64/all/php-7.4.19.tgz
> Creating package php-7.4.19
> Creating package debug-php-7.4.19
> Link to /usr/ports/packages/amd64/ftp/php-7.4.19.tgz
> Link to /usr/ports/packages/amd64/ftp/debug-php-7.4.19.tgz
> `/usr/ports/pobj/php-7.4.19/fake-amd64/.fake_done' is up to date.
> > Extracting debug info from 
> > /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/php-7.4
> Warning: no debug-info in 
> /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/php-7.4
> dwz: /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/.debug/php-7.4.dbg: 
> .debug_info section not present
> objcopy: 
> /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/.debug/php-7.4.dbg: 
> Invalid operation


oh look, it's doing the same thing TWICE. But wait: there's a Makefile
involved.

Now why would it do that ?

It could only happen if somehow, the dates are completely wacked.

Would you by any chance use NFS for your pobj tree, or anything that
would get your clock to act strangely ?...

Re: Fwd: rethinking terminal login with security in mind

[Marc Espie]

On Wed, May 05, 2021 at 01:44:24AM +0200, Alessandro Pistocchi wrote:
> Sorry, my keyboard went crazy and the message was sent incomplete.
> 
> Continuing: normally the entry of username is immediately followed by the
> password entry.
> However, if the OS is busy for any reason between the two entries,
> character echo is still on.
> If I don't notice that, I may start typing the password before the OS stops
> echoing and so I show it
> to anybody around who cares to look.
> 
> Wouldn't it be better to have a way to turn off echoing of characters as
> soon as I entered my username,
> regardless of whether the OS is busy or not?

Not really. it's your job to pay attention. Specifically, if your OS is busy
or whatever, you just need to wait until the Password: prompt gets
displayed, because echo gets turned off *before* that prompt happens.


and the actual standard interface used won't change.

See readpassphrase(3), which does already protect you against many many
problems.

Re: Cultural underground legende Seymour Cray and his legacy

[Marc Espie]

Is this a new UMF experiment ?

Re: Documentation on OpenBSD's 3-process privsep model?

[Marc Espie]

On Tue, Mar 23, 2021 at 09:41:06AM +, Ottavio Caruso wrote:
> On 23/03/2021 05:53, misopolemiac wrote:
> > I'd appreciate some pointers to documentation or minimal examples of
> > the 3-process privilege separation model for OpenBSD's daemons.
> > Internet searches pointed to skeleton examples at
> > github.com/krwesterback/newd and github.com/krwesterback/newdctl, but
> > those repos are now dead and it's unclear how authoritative they were
> > in the first place.
> > 
> > 
> 
> Blind leading the blind here, but I think a good starting point would be
> recent presentations by Marc Espie, who, I believe but I might be wrong, is
> the developer who worked the most on privsep.
> 
> http://www.openbsd.org/events.html

Definitely not at all.

I haven't worked the most on privsep, by far.

and the examples I've worked on are highly specific and probably 
not applicable to most of the base code.

Re: GCC only on OpenBSD adds -L/usr/lib as prefix, why? Re: OpenBSD: Failing to link custom libpng to custom libz, any thoughts how fix?

[Marc Espie]

On Wed, Mar 03, 2021 at 06:10:22PM +, Bob wrote:
> Does that -L/usr/lib really need to be in the leading position???


I have zero idea how to do that purely in specs.   Have fun tinkering.

This is probably something we'll adopt but low priority.


>  * Where is GCC's default specs file say for AMD64/i386?

somewhere under /usr/lib/gcc-lib  or /usr/local/lib/gcc-lib

you can get gcc to spew it out with -dumpspecs.

>  * Using what environment variable or GCC command line argument do
>I specify an alternative one?

Oh come on, just read the man page and  /spec :)

-specs=file  is fairly prominent.

Re: GCC only on OpenBSD adds -L/usr/lib as prefix, why? Re: OpenBSD: Failing to link custom libpng to custom libz, any thoughts how fix?

[Marc Espie]

Do you have some actual reason to use gcc for that project instead of 
clang ?...

as far as -L goes you've got a lot of choices, between linking directly to
the .so, linking with --nostdlib and putting back the pieces manually.

it's been a long time since I've last looked at gcc, we've moved to clang
a few years ago for the most part. gcc is mostly there for the legacy
architectures that do not have clang support.

Oh, I remember now, it's because of ld.ldd, the linker from clang.
see, that one does not link with /usr/lib by default, which tends to break
everything.


Note that you don't have to recompile gcc to change that: the specs file
is where the magic happens, and hey, you can specify a new one on the command
line, so you just need to copy and change.

But again: why gcc ?

Re: OpenBSD: Failing to link custom libpng to custom libz, any thoughts how fix?

[Marc Espie]

On Wed, Feb 24, 2021 at 02:17:14PM -, Stuart Henderson wrote:
> On 2021-02-23, Bob  wrote:
> > Hi,
> >
> > I am trying to make a custom build of libpng in my home directory,
> > using a libz build that I made in my home directory also.
> >
> > Both are latest version, libpng 1.6.37 same as OpenBSD's port
> > https://cvsweb.openbsd.org/ports/graphics/png/Makefile?rev=1.125=text/x-cvsweb-markup
> > and libz the latest one they published. For zlib it's 1.2.11
> > from http://zlib.net/ from 2017, OpenBSD does not have a port but
> > base bundles a 2009 version. Since 2009, significantly an export
> > "inflateReset2" has been added.
> 
> As you have seen it is difficult to have library functions in one
> version in base and in another version built elsewhere (whether that's
> in $HOME or in ports). Ports only does this for libraries where there's
> really no other choice and where that has been done they're used *very*
> rarely (the port can then not depend on any libraries which pull in the
> library from base). Currently that is libbind (used only by asdig and
> zeek) and openssl (used as a static library by sslscan, and dynamic
> for nrpe and nsca-ng).
> 
> > I'll start with the detail problem, and discuss the reproduction at the
> > bottom:
> >
> >
> > This has brought me to the bizarre issue that the libpng build plainly
> > refuses to link to my custom libz file /home/myuser/lib/libz.so.1 .
> > Instead, it insists with linking to the OS' global
> > /usr/lib/libz.so.5.0 .
> 
> This is as expected really, it looks for the higher library version
> number.

Not really, it's more that you have to make sure to put your own directory
before the system directory, which requires a bit more magic than just -L.

(remember that linking will stop at the first directory with a satisfying
library, and link with the highest version number found in there, which
is fortunate for stuff like libtool!)

Re: pkg_add version scripting ?

[Marc Espie]

On Sun, Nov 01, 2020 at 12:59:22PM +, Laura Smith wrote:
> 
> 
> I did actually try "pkg_add gnupg%2" but pkg_add didn't like that.  Will go 
> try "pkg_add gnupg%gnupg2" instead

The branches are directly picked from the pkgpath in the ports tree.

It's the one case where they have an actual meaning for end user.

and there are good reasons to use them (some ports have stable and snapshot
branches)

Re: pkg_add version scripting ?

[Marc Espie]

On Sun, Nov 01, 2020 at 12:23:44PM +, Laura Smith wrote:
> Hi
> 
> As far as I can tell from the docs, only pkg_info supports spec style ?
> 
> I am trying to script an OpenBSD setup and as part of that certain packages 
> need to be installed. For most packages that is not a problem, however, for 
> example, with gnupg, there are two versions in the 6.8 repo :
> gnupg-1.4.23p4.tgz
> gnupg-2.2.23p0.tgz
> 
> I cannot seem to find a way to tell pkg_add to install >=2  (or better still, 
> install "the latest" version).

"Better still" to be discussed.

Newer is not always better, especially when some things stop working and
stuff like that.

It's generally considered that scripting is meant to give you a reliable
system...


> Any ideas ?

You should read pkg_add(1) more closely.

 pkg_add also understands ‘stems’, that is, package names without any
 version specification.  For instance, with ‘pkg_add kdelibs’, pkg_add
 will look in the current directory (or the PKG_PATH) for a kdelibs
 package.

 pkg_add may ask questions in interactive mode, or error out otherwise.
 Interactive mode is the default on a tty, see options -I/i.

 For instance ‘pkg_add screen’ is ambiguous as it matches screen-4.03p6
 and screen-4.03p6-shm.

 To avoid ambiguities, pkg_add supports ‘stems with flavors’, that is, a
 stem separated from flavors with a double dash.  For instance, the
 previous ambiguity could be resolved by using ‘pkg_add screen--’ (matches
 only the empty flavor) or ‘pkg_add screen--shm’ (matches only the shm
 flavor).

 There is also an ambiguity related to ports with multiple branches.  For
 instance ‘pkg_add python’ is ambiguous, as there are several versions of
 python in the ports tree.  So is ‘pkg_add postfix’.  The special form
 ‘pkgname%branch’ can be used to restrict matches to a branch matching the
 pkgpath(7).

 The above ambiguities can be resolved using ‘pkg_add postfix%stable’ and
 ‘pkg_add python%3.4’, respectively.


stuff like pkg_add gnupg%gnupg and pkg_add gnupg%gnupg2
in 6.8, with possibly a bit more to take care of flavors as well.

(note that pkg_info -z   will give you the exact specs you want)

Re: Using ports and updates to the release

[Marc Espie]

On Sun, Oct 11, 2020 at 09:12:13PM +0200, Ingo Schwarze wrote:
> Hi Ed,
> 
> Ed Gray wrote on Sun, Oct 11, 2020 at 07:21:32PM +0100:
> 
> > I'm still fairly new to openbsd and the idea of using ports
> > in general rather than binary packages.
> 
> You are usually better off using packages than using ports,
> especially as a new user.
> 
> Even as an experienced user doing lots of development and minor
> amounts of ports development, i use packages most of the time.

As one of the persons *responsible* for keeping the ports system
working, I do use packages all the time.

Ports are on my development setup.

The machine I write this mail from uses packages,
with about 3 ports that are just there because not committed yet.

Re: support new

[Marc Chantreux]

hello Ottavio,

> BTW, for the non-initiated, what is this?

https://www.openbsd.org/groups.html

see the "this template" link to go there:

https://www.openbsd.org/grp-tmpl.txt

cheers,
marc

Re: Does OpenBSD support Carrier Grade Nat?

[Marc Peters]

On Fri, Aug 07, 2020 at 12:46:45PM +, Edward Carver wrote:
> Can you send me sample config please?
> 

What kind of config? There's no special config needed, as the IPv4 you get for 
your external interface is out of the range 100.64.0.0/10. I receive mine via 
dhcp, but some providers may use pppoe for this. Your router will not be 
reachable via v4, of course. It's only available via IPv6.

Best,
Marc

Re: Does OpenBSD support Carrier Grade Nat?

[Marc Peters]

On Fri, Aug 07, 2020 at 12:12:14PM +, Edward Carver wrote:
> Does OpenBSD support Carrier Grade Nat (cg-nat)?
> Thanks for helping..

My router sits behind one, so yes.

hth,
Marc

Re: strlcpy version speed tests?

[Marc Espie]

On Wed, Jul 01, 2020 at 07:05:02AM -0500, Luke Small wrote:
> Are you clinging to traditions for some purpose? I gave two different
> versions. strlcpy3 is clearly more easily understood and even slightly
> faster and strlcpy4 which sets up the following workhorse lines which
> through timing the functions is hands down faster on my Xeon chips:
> 
> 
> strlcpy4:
> while (--nleft != 0)
>  if ((*++dst = *++src) == '\0')
> ...
> 
> the others:
> 
> while (--nleft != 0)
>   if ((*dst++ = *src++) == '\0')
> 
> ...
> 
> 
> I spoke to my favorite university computer science professor who said
> ++n is faster than n++ because the function needs to store the initial
> value, increment, then return the
> 
> stored value in the former case,
> 
> while the later merely increments, and returns the value. Apparently,
> he is still correct on modern hardware.

If you really care about speed, you should probably look into an
arch/
asm version instead

Re: How do I get the man page for a package I haven't installed yet?

[Marc Espie]

On Tue, Jun 23, 2020 at 12:20:35PM -0600, Theo de Raadt wrote:
> Ottavio Caruso  wrote:
> 
> > Hi,
> > 
> > Unless I've got it all wrong,  will only
> > display man pages for programs and commands in base. Is there a way to
> > display the man page for a package/port I haven't installed and/or
> > downloaded yet? (This assumes I haven't downloaded the ports cvs
> > tree).
> 
> Doing that would be very annoying and painful, and very few people
> would want it.  It would also substantially degrade the clarity at
> man.openbsd.org

Actually, it ought to be feasible to have the same mechanism in place for
base  as a third party mechanism.

I don't think it would be that difficult to setup, this obviously ought to
be separate from the main OpenBSD installation, as the quality of manpages
from ports is often not up-to-par compared to base.

Both Ingo and naddy and I, we've been routinely passing all manpages from
all packages through groff and mandoc and makewhatis to the point that
over 99% of them would be clean for a usage similar to man.openbsd.org

Re: New tool to (quickly) check for available package upgrades

[Marc Espie]

On Wed, Jun 17, 2020 at 09:12:08PM -, Stuart Henderson wrote:
> On 2020-06-17, Marc Espie  wrote:
> > The only way you end up with broken installations is when porters don't do
> > their jobs, that is they fail to bump a shared library or something like
> > that.
> 
> They do still break in some cases:
> 
> libA depends on libB
> someapp depends on libA, libB
> 
> libB has a major bump. libA gets updated but someapp is missed
> due to a mirror with an incomplete update. Now someapp wants old libB,
> but libA wants new libB, resulting in breakage.

Ouchie... that  one I can't do much about. :(

> (There are also situations where some installed packages are broken
> for part of a pkg_add -u run, though they do sort themselves out later -
> I forget the details but I think it was something to do with the timing
> of ldconfig runs, updates to things like glib2/pango often do this).

ldconfig is run just before actually exec'ing anything that might depend on it.

Have you run into the problem lately ?
I think it's mostly gone with @tags, since it delays running most things until
the end of pkg_add -u, so that things  have actually settled down.

Re: New tool to (quickly) check for available package upgrades

[Marc Espie]

On Wed, Jun 17, 2020 at 09:12:08PM -, Stuart Henderson wrote:
> This is already a problem when pkg_add fetches the directory listing
> (though a smaller one because the filenames don't change as often).
> 
> Firstly the contents of the mirror can change during the pkg_add run
> so the listing becomes invalid, that can happen on any mirror.
> 
> Secondly if the mirror involves a cache (CDNs) they will often cache
> the directory listing as an object - the other files in the directory
> can be out of sync with regard to the served index page. As the index is
> not too big and is hit on every pkg_add run against that mirror, it's
> highly likely to be cached, more so than probably anything else in the
> directory except the quirks package.

Yes, I've run into this one as well.   One more reason to hate CDNs

I have on my list to check about ignoring the index in some cases.
Namely: packages have the actual names of the dependencies they were built
against built-in.  It should be possible and not that hard to try grabbing
that package, even if it didn't appear in the index, if it appears to be
more recent than what the index says.

Re: New tool to (quickly) check for available package upgrades

[Marc Espie]

On Wed, Jun 17, 2020 at 09:44:32AM -0400, Jeremy O'Brien wrote:
> On Wed, Jun 17, 2020, at 08:47, Marc Espie wrote:
> > On Wed, Jun 17, 2020 at 08:28:02AM -0400, Jeremy O'Brien wrote:
> > > On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote:
> > > > 
> > > > The concept you need to understand is snapshot shearing.
> > > > 
> > > > A full package snapshot is large enough that it's hard to guarantee that
> > > > you will have a full snapshot on a mirror at any point in time.
> > > > 
> > > > In fact, you will sometimes encounter a mix of two snapshots (not that 
> > > > often,
> > > > recently, but still)
> > > > 
> > > > Hence, the decision to not have a central index for all packages, but to
> > > > keep (and trust) the actual meta-info within the packages proper.
> > > > 
> > > 
> > > Sorry, I guess I should've responded to this as well. Isn't snapshot 
> > > shearing going to be a problem regardless of the existence of a single 
> > > central-index? For instance, pkg_add notices a chromium update, which 
> > > requires a newer version of a dependency that hasn't been propagated to 
> > > the mirror yet.
> > > 
> > That's not a big problem, it just stops before updating... at least
> > your installation doesn't get hosed.
> >
> 
> Sorry if I'm being dense here. I'm just trying to understand this completely.
> 
> In the current implementation, does pkg_add recursively verify every 
> dependency of a package before installing *any* of them? Or does it install 
> dependency updates as it finds them? Because if it's the latter, I can still 
> envision scenarios that break a given package, such as: Package A depends on 
> B and C. B is sync'd, C is not yet. pkg_add installs the update to B, then 
> encounters the missing C update, and bails the upgrade of A. Now you have A 
> installed which doesn't work with the new version of B. Is this something 
> that can currently happen?

Nope.  That's why we have shared libraries numbers.

We keep the old libraries around, so packages will keep working.

In the rare case where some packages have tight dependencies (see cups and 
cups-libs for instance), pkg_add will update both at the same time.

An update is done in two steps: first extract the new package(s) to temporary
files, THEN delete the old package and move the temporary files in final
location.

The only way you end up with broken installations is when porters don't do
their jobs, that is they fail to bump a shared library or something like
that.

> Even with snapshot shearing though, having this index file could provide a 
> substantial speed upgrade. Instead of having to check *all* installed 
> package's header for updates, you could use the index to know the subset of 
> packages that you expect to have actually changed, and only download *those* 
> packages' headers. If the expected "combined" sha of a given package doesn't 
> match the index's version, then the mirror is clearly out of sync and we 
> could abort an update as usual.


The problem is the multiple RTT...! if you manage to keep one single 
connection open, you get a substantial speed upgrade.

Generating a single index is more problematic than it would seem at first o
glance.

When everything goes fine, you're happy. 

If anything is out-of-synch, you're in deep shit.

This would mean having several possible modes to cope with that, we don't
have enough resources to do that.

Re: New tool to (quickly) check for available package upgrades

[Marc Espie]

On Wed, Jun 17, 2020 at 08:28:02AM -0400, Jeremy O'Brien wrote:
> On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote:
> > 
> > The concept you need to understand is snapshot shearing.
> > 
> > A full package snapshot is large enough that it's hard to guarantee that
> > you will have a full snapshot on a mirror at any point in time.
> > 
> > In fact, you will sometimes encounter a mix of two snapshots (not that 
> > often,
> > recently, but still)
> > 
> > Hence, the decision to not have a central index for all packages, but to
> > keep (and trust) the actual meta-info within the packages proper.
> > 
> 
> Sorry, I guess I should've responded to this as well. Isn't snapshot shearing 
> going to be a problem regardless of the existence of a single central-index? 
> For instance, pkg_add notices a chromium update, which requires a newer 
> version of a dependency that hasn't been propagated to the mirror yet.
> 
That's not a big problem, it just stops before updating... at least
your installation doesn't get hosed.

Re: New tool to (quickly) check for available package upgrades

[Marc Espie]

On Tue, Jun 16, 2020 at 04:59:07PM -0400, Jeremy O'Brien wrote:
> Hey misc@,
> 
> I wrote a quick little tool here: 
> https://github.com/neutralinsomniac/obsdpkgup in Go to show available package 
> upgrades from your configured mirror.
> 
> It takes no more than a few seconds (the time it takes to download index.txt 
> from the package repo) to show you all packages that have received a version 
> bump. This tool *won't* show same-version package-rebuild upgrades, so it 
> shouldn't be used as a complete replacement to running 'pkg_add -u', but 
> rather as a companion to show when actual newer versions of packages are 
> released. I just noticed that in my 99% case, I was waiting anywhere from 
> 5-10 minutes for 'pkg_add -u' to complete checking all ~400 of my installed 
> packages, and it uses a considerable amount of bandwidth while doing so.
> 
> As I understand it, the pkgtools detect same-version rebuilds by downloading 
> enough of every installed package tgz to check the metadata contained within 
> to determine if an upgrade is needed. If anyone knows of an alternative way 
> to determine when a same-version package install is required, I would love to 
> know of it. In the meantime, I hope someone else can make use of this tool as 
> well.

The concept you need to understand is snapshot shearing.

A full package snapshot is large enough that it's hard to guarantee that
you will have a full snapshot on a mirror at any point in time.

In fact, you will sometimes encounter a mix of two snapshots (not that often,
recently, but still)

Hence, the decision to not have a central index for all packages, but to
keep (and trust) the actual meta-info within the packages proper.

The only way to avoid that would be to have specific tools for mirroring,
and to ask mirror sites to set aside twice as much room so that they
can rotate snapshots.

Now, each package has all dependency information in the packing-list...
which allows pkg_add to know whether to update or not.   We do a somewhat
strict check, we have tried to relax the check at some point in the past,
but this was causing more trouble than it was worth.

The amount of data transmitted during pkg_add -u  mostly depends on signify:
you have to grab at least  a full signed block, which is slightly over 64KB.

On most modern systems, the bandwidth is not an issue, the number of RTT
is more problematic.   The way to speed pkg_add -u up would be to keep the
connection alive, which means ditching ftp(1) and switching to specific code
that talks modern http together with byte-ranges.

Re: __printflike macro on OpenBSD

[Marc Espie]

On Thu, Jun 11, 2020 at 06:22:55PM +, sensiblehue wrote:
> On Thu, Jun 11, 2020 at 03:08:01PM +0200, Marc Espie wrote:
> > On Thu, Jun 11, 2020 at 04:37:34AM +, sensiblehue wrote:
> > > Hello,
> > > I was wondering why OpenBSD doesn't have a `__printflike' macro in
> > > ? FreeBSD, NetBSD, and DragonflyBSD have it and it's also
> > > available from libbsd on Linux.
> > > Personally I think it's cleaner and just as portable if not more
> > > portable, because some compilers don't support `__attribute__'.
> > 
> > 
> > What compilers ?
> 
> GCC < v2.5 and non GNU C compilers, though I see now that OpenBSD
> defines it to nothing in that case. What could be an issue is that the
> `format' attribute appeared in GCC v2.7, and invalid attributes
> generate a warning.

clang has full support for attributes, so your statement is somewhat false.

Re: __printflike macro on OpenBSD

[Marc Espie]

On Thu, Jun 11, 2020 at 04:37:34AM +, sensiblehue wrote:
> Hello,
> I was wondering why OpenBSD doesn't have a `__printflike' macro in
> ? FreeBSD, NetBSD, and DragonflyBSD have it and it's also
> available from libbsd on Linux.
> Personally I think it's cleaner and just as portable if not more
> portable, because some compilers don't support `__attribute__'.


What compilers ?

Re: writing aucat output

[Marc Espie]

On Fri, Jun 05, 2020 at 01:02:18PM +0200, Peter J. Philipp wrote:
> On Fri, Jun 05, 2020 at 12:50:53PM +0200, Marc Espie wrote:
> > On Fri, Jun 05, 2020 at 12:06:54PM +0200, Peter J. Philipp wrote:
> > > Hi,
> > > 
> > > I'm wondering how I can write to stdout on aucat?  Here is what I have:
> > > 
> > > beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o - | hexdump -C
> > > stdout: failed to seek back to header
> > > beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o /dev/stdout | 
> > > hexdump -
> > > /dev/stdout: failed to seek back to header
> > 
> > That's a bug/limitation on aucat. It tries to seek on stdout right after
> > setting it up, which is absurd.
> > 
> > I'll have a look later, should be very easy to fix!
> 
> Thanks...

I spoke too soon, it's way more complicated because the wav header has
to know how large the file will be... which means you would have to parse
the input file and figure out the resulting size before writing anything
out, so it's way more code than I hoped for.

:(

Re: writing aucat output

[Marc Espie]

On Fri, Jun 05, 2020 at 12:06:54PM +0200, Peter J. Philipp wrote:
> Hi,
> 
> I'm wondering how I can write to stdout on aucat?  Here is what I have:
> 
> beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o - | hexdump -C
> stdout: failed to seek back to header
> beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o /dev/stdout | hexdump -
> /dev/stdout: failed to seek back to header

That's a bug/limitation on aucat. It tries to seek on stdout right after
setting it up, which is absurd.

I'll have a look later, should be very easy to fix!

Re: Forgetting pkg_add -u after sysupgrade can cause ansible msyscall errors

[Marc Espie]

On Sun, May 31, 2020 at 08:19:18PM +0200, Jurjen Oskam wrote:
> Hi,
> 
> For the sake of the archives and future search engine users, I'll share what
> can happen when you use sysupgrade to upgrade your OpenBSD host but then
> forget to run update your installed packages. (Yep, silly mistake, I know...)
> 
> After upgrading my Ansible host to 6.7, I noticed that each ansible command
> outputted the following error, but it continued normally after that:
> 
> msyscall 1ba41d145000 a5000 error
> 
> The second word varied with each invocation, and I did not notice any other
> adverse effects on that box. The error occurred with all ansible commands,
> such as ansible, ansible-playbook and ansible-connection.
> 
> I was >< this close to sending a help request to this list, but I realized
> I had not tried to see what would happen on a freshly installed 6.7 box.
> It was then that I noticed that the new box had ansible-2.9.7 and
> python-3.7.7, while the upgraded box had ansible-2.7.9 and python-3.6.8p0.
> This caused me to realize I had forgotten to update my packages after doing
> the sysupgrade... A quick "pkg_add -u" later and my problem was gone. D'oh!
> 
> So, moral of the story: don't forget to update your packages after a
> sysupgrade.

Heh

Always a good idea.

msyscall was kind of a "flag day". In case you don't know, most anything
dynamic that uses syscalls has to  go through a specific area in libc now,
it makes all kinds of attacks more complex.

Some of us running current went through similar burps in case we forgot.

I must say, I'm happy I added @tag support a while back, this made this
specific package update much less painful.

Re: Article OpenBSD: Not Free Not Fuctional and Definetly Not Secure and BSD, the truth blog

[Marc Espie]

On Thu, May 28, 2020 at 01:15:36PM -0700, Amarendra Godbole wrote:
> Aha! So my hunch was right -- I thought that'd be the case seeing the
> comments under your name that were totally out of character from your
> posts here.
> 
> -ag
> 
> On Thu, May 28, 2020 at 12:08 PM Kevin Chadwick  wrote:
> >
> > On 2020-05-28 18:38, Amarendra Godbole wrote:
> > > It indeed is written by someone lacking knowledge about everything. It
> > > is funny, and gave me a good laugh - the comments are even funnier!
> >
> > Be aware that the author deletes your comments and replaces them with his 
> > own,
> > under your name, whilst hiding behind wordpress.com!
> >
> 
> 
Actually that scum is hosted at wordpress.com, I'm not sure that they
would like knowing someone is changing comments without changing the
authors' names.

Also, that shit is anonymous, meaning the bastard can't even take
responsability for his drivel

Re: Article OpenBSD: Not Free Not Fuctional and Definetly Not Secure and BSD, the truth blog

[Marc Espie]

On Thu, May 28, 2020 at 07:58:45PM +, Kevin Chadwick wrote:
> On 2020-05-28 18:38, Amarendra Godbole wrote:
> > It indeed is written by someone lacking knowledge about everything. It
> > is funny, and gave me a good laugh - the comments are even funnier!
> 
> Be aware that the author deletes your comments and replaces them with his own,
> under your name, whilst hiding behind wordpress.com!
> 
> 
Ah I saw your name and was wondering.

So that guy is a pure asshole

Re: Article OpenBSD: Not Free Not Fuctional and Definetly Not Secure and BSD, the truth blog

[Marc Espie]

On Thu, May 28, 2020 at 01:16:59AM -0300, Quantum Robin wrote:
> Hi,
> 
> While surfing on the Google to learn more about OpenBSD, I encountered this
> one: "OpenBSD: Not Free Not Fuctional and Definetly Not Secure (
> https://aboutthebsds.wordpress.com/2013/01/25/20/)
> 
> Is the author telling the truth? Or just yet another anti-BSD thing?
> 

"At meetings, people are often physically attacked for having even a minor 
disagreement with de Raadt"

Hyperbole much ?

Theo has been known to be fairly opiniated, but "physically attacked"?

How can you take this guy seriously ?

Re: Problem with pkg_add -uv after 6.7 upgrade on i386

[Marc Espie]

On Mon, May 25, 2020 at 01:01:07PM +0200, Paolo Aglialoro wrote:
> Hello Folks,
> 
> I just upgraded a PIII box freshly installed with 6.6 last month.
> Everything went right with sysupgrade (big kudos do devs).
> 
> Problems started when upgrading installed packages, here follows the output
> of pkg_add -uv. What can this be?

Corruption of your filesystem *prior* to running pkg_add -u

Run pkg_check.

> adwaita-icon-theme-3.34.3:.libs-pango+.libs1-pango+.libs2-pango+.libs3-pango+.libs4-pango+pango-1.42.4p3->pango-1.44.7p0
> 't read packing-list from installed package
> \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
> Invalid \0 character in pathname for ftis: /var/db/pkg/\0 at
> /usr/libdata/perl5/OpenBSD/PackingList.pm line 520.
> File
> /var/db/pkg/\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00/+CONTENTS
...

those are actually fairly obvious error messages.

Re: Why does OpenBSD still include Perl in its base installation?

[Marc Espie]

Another thing to consider: why is perl in the base system.

Assume you need a script language, because writing everything in C is
cumbersome.

What are the choices ?
- you need something under and acceptable licence, so python is out.
(Artistic Licence is "close enough");
- you need something that builds everywhere, so python is out (hard to build
without dynamic libraries, that was vax...);
- you want a modicum of security, so shell and tcl and php are out.
- awk would kind of work, except it's not that readable, and it wouldn't
scale up to some of the things we use perl for.

Perl constituted a great compromise back in the day I chose it to replace
pkg_add. It still IS a great compromise, and it's not THAT large compared
to other pieces.

Over the years, things have moved back from language to language.
makewhatis used to be C+shell, then it became perl, and now it's pure C
because it's integrated in mandoc... I shudder to think how much time
was spent in there.

Note that Ingo also moved /etc/security from shell to perl, so he's not
adverse to perl.

As far as I'm concerned, having perl in the base system is a strength of
OpenBSD... it does minimize the number of script languages used for
ports infrastructure as compared to other languages.

perl also has impressive support tools, be they in the base system or in
ports.   NYTProf  is still the  best profiler I've ever seen on any
language.

Re: OpenBSD sysupgrade rocks

[Marc Espie]

On Tue, May 19, 2020 at 07:06:05AM +, Frank Beuth wrote:
> On Wed, May 20, 2020 at 02:07:27PM -0400, Chris Bennett wrote:
> > Please don't beg for features.
> > That's very irritating and wastes everyone's time.
> > 
> > Please don't ask for features, once again.
> > Really, I mean it. Don't ask for features!
> 
> How about a counterpart to `sendbug` called `requestfeature`, which is an
> alias to `fortune` run with a file consisting of Theo's snarkiest remarks?


Theo's snarkiest remarks are definitely NSFW!

Re: Why isn't src included with OpenBSD? (documentation)

[Marc Espie]

On Mon, May 18, 2020 at 08:43:19PM +0100, Ottavio Caruso wrote:
> Some of these documents have a proprietary licence attached to it and
> I believe it's due to the 1994 AT settlement. There are third party
> collections (like this: https://github.com/sergev/4.4BSD-Lite2) but
> I'm not sure if one could import them all in the source tree or in the
> ports tree without violating some copyright here and there.

If the README.md is accurate, that could be imported in the ports tree,
but there would be a lot of work to extract useful stuff from there.

Looks like a standard 4-clauses old-style BSD licence.

I've had a look, and it is very strange, some of the PSD documents have
been converted to pdf, BUT not all of them.

There are also no actual releases, so you'd have to pull a specific tag
from github, always hasardous...

Re: Why isn't src included with OpenBSD? (documentation)

[Marc Espie]

On Mon, May 18, 2020 at 01:07:36PM -0400, Andras Farkas wrote:
> I saw in fsck_ffs.8
> https://man.openbsd.org/fsck_ffs.8
> that the answers could be found in
> Fsck_ffs - The UNIX File System Check Program
> This is perfectly fine.  Not every piece of information belongs in a
> man page.  Man pages are the right format for some sorts of info, and
> absolutely the wrong format for some other sorts.
> BUT: I looked and couldn't find it, and ended up using
> https://docs.freebsd.org/44doc/smm/03.fsck/paper.pdf
> which is where I found my answer.
> Only after I already solved the problem did I find that the mentioned
> file exists here:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/fsck_ffs/SMM.doc/

Most of these files haven't been updated in ages.

The few remaining in the source tree are there as reference for people
when writing documentation and updating the source.

Each time we see them, we cringe, and keep tidying the source code and
the man page.

Speaking for personal experience working on make.

If you really want the source code for documentation purposes, what prevents
you from getting it off cvs  or a github mirror ?

Seriously, *none* of those files are necessary *for beginners*. Once you
reach the stage where you might benefit from them (say, because you actually
want to become a developer, and could learn from worse sources), you should
be able to figure out how to get them.

Having an extra set here means... more options... more code that can go
wrong, and thus a SLOWER turn-around for snapshots, which is definitely
a bad thing.

Re: fw_update verify firmware?

[Marc Espie]

On Thu, May 14, 2020 at 04:25:11AM +, Mogens Jensen wrote:
> I was just trying out the fw_update program on OpenBSD 6.5, deleting/
> installing all the firmware and was wondering if fw_update will verify
> the files before installing?

Others pointed out that firmwares are signed.

For a while now, fw_update AND pkg_add have defaulted to requiring
signed packages. If you try to install or even peek at something
unsigned with pkg_info, they error out.

You have to explicitly ask for unsigned data to bypass the check.

Re: pkg_add can't resolve package - bad major

[Marc Espie]

On Sun, May 03, 2020 at 12:58:41PM -0400, Chris Bennett wrote:
> I have had this exact same problem before
> 
> pkg_info -q > packages_installed
> pkg_delete gettext.
> pkg_add gettext-runtime
> pkg_add -u
> pkg_add -zl packages_installed
> 
Update your procedures, use pkg_info -z and not pkg_add -z.
It's been there for ages.

Re: List a package's dependencies

[Marc Espie]

On Mon, Apr 20, 2020 at 07:45:37PM +0100, Kevin Chadwick wrote:
> 
> > There are some unavoidable complexities to the sheer size of the tree,
> > and the necessities of updates not to fail...
> 
> I have noticed recently that I occasionally get a gz truncated message (I 
> think
> due to tcp timeout) and then the dependent package doesn't get updated. I then
> re-run pkg_add -u.
> 
> Is the way to deal with this from a script, to; re-run pkg_add -u, if it's
> output is > 0 ?
Nope, it's definitely the wrong place to fix things.

You should fix your pipes (change the timeouts or whatever).

If worse comes to worst, pkg_add could *possibly* retry running ftp(1),
but that makes little sense. If the transport layer is *broken* my gut
feeling is that the transport layer needs fixing! Application layer should
be able to rely on a *working* transport layer.

That's what all network books have been saying for >30 years.