Re: [Patch] Correct the version of OpenSSH in 67.html
That text hasn't been updated yet. 67.html is still a work in progress for the upcoming release. Ross L Richardson wrote: > Should be 8.3, shouldn't it? > > Ross > > > Index: 67.html > === > RCS file: /cvs/www/67.html,v > retrieving revision 1.65 > diff -u -p -r1.65 67.html > --- 67.html 11 May 2020 19:24:58 - 1.65 > +++ 67.html 12 May 2020 04:45:33 - > @@ -1178,7 +1178,7 @@ and https://www.openbsd.org/arm > > > > -OpenSSH 8.1 > +OpenSSH 8.3 > > New Features > >
[Patch] Correct the version of OpenSSH in 67.html
Should be 8.3, shouldn't it? Ross Index: 67.html === RCS file: /cvs/www/67.html,v retrieving revision 1.65 diff -u -p -r1.65 67.html --- 67.html 11 May 2020 19:24:58 - 1.65 +++ 67.html 12 May 2020 04:45:33 - @@ -1178,7 +1178,7 @@ and https://www.openbsd.org/arm -OpenSSH 8.1 +OpenSSH 8.3 New Features
Re: ospfctl json support
Hi,
Behaviour for certain actions needs discussion and the behaviour crosses over
with the work on bgpctl. A command such as bgpctl -j log brief currently
results in a return such as:
“
Logging request sent.
{
}
"
I think this behaviour would be common to anything which effectively does a
fire and forget. We could either remove the json output by doing something
like (but not!):
if(!done) {
//output head
//output tail
}
This would stop a json response altogether. Alternatively we could update
the code to return something like:
“{ response: “Logging request sent” }
Finally we could just error if you call one of those methods with a -j flag?
Just hit the same pattern/issue on ospfctl, so looking to source some
direction. Using openbsd, there has always felt like lots of synergy
between cli interfaces, so just hoping to help continue that :)
Cheers
Richard
> On 11 May 2020, at 13:52, Claudio Jeker wrote:
>
> On Mon, May 11, 2020 at 12:38:38PM +0100, Richard Chivers wrote:
>> Hi,
>>
>> I have done some work over the last few days to implement json support
>> into ospfctl following the work done recently in bgpctl.
>>
>> I have some queries, hoping to get some help with.
>>
>> The change involves a refactor of ospfctl, but reuses the recent
>> json.c written by Claudio, that is in the
>> usr.sbin/bgpctl directory. At present no changes have been required at all.
>> What is the best approach here, should/could this be centralised somewhere?
>
> At the moment just copy the files into ospfctl. We did the same thing with
> other bits in the tree. My json API is super minimal and is for sure not
> something that should be put into a common framework right now. The way
> objects and arrays are opened and closed is a bit rough and does not
> always work well.
>
>> In some cases there is room for change, for example ospfctl sh rib &
>> ospfctl sh rib detail.
>>
>> In my view here, it makes sense to have a full list returned rather
>> than splitting json into multiple lists of Router, Network and
>> External.
>> I looked for inspiration in the bgpctl, but couldn't find a similar
>> pattern. The reason for a single list is that if consuming the json,
>> I expect you will not want code that has to iterate over three
>> separate arrays. Just looking for some feedback really. The original
>> split
>> made sense for screen use, just not so sure about machine readability.
>> This issue also applies to ospfctl sh data, which returns 3 lists.
>
> A lot of this is depending on the imsgs used between ospfctl and ospfd.
> IIRC ospfd sends all data in one batch so the multiple lists just happen
> by ospfctl and indeed for json output it would be best to display the rib
> as a single array of entries (which have a similar structure but probably
> per LSA specific attributes).
>
>> When I am finished, should I just post the diff on here? Just
>> conscious it is quite a big refactor, albeit much of the code is
>> reused just moved into output.c as
>> was done for bgpctl.
>
> Please split it up like I did it for bgpctl. I first did a lot of the
> moving and cleanup and only later added the new input mode. This makes the
> individual steps smaller to review.
>
>> I am testing each call individually against a set of openbsd 6.6 boxes
>> we have running, which is great for ospfd. What is the normal
>> practise for ospf6, is there a script run to replicate code changes or
>> is it just a case of making very similar changes line by line?
>
> There is no script, you do it by hand it is quicker.
>
>> Just looking for the general thinking and approach I guess. I don't
>> currently have ospf6 set-up so that would be some overhead.
>> Happy to configure it though if needed/expected.
>
> Get ospfctl first, after that ospf6ctl can be done (and maybe somebody
> else will take care of that).
>
>> Finally what was the driver under bgpctl for the json output, ours is
>> for reading metrics to populate telemetry, just interested as the
>> purpose other
>> people have. Having this context will help in micro decisions when
>> implementing the json structure.
>
> I'm doing this work to provide JSON payloads to external looking glasses.
> I would not put the RIB into telemetry (that is just useless churn and
> load on the telemetry system). In bgpctl the terse outputs are simple
> space separated outputs for telemetry scripting but I guess people will
> also use the JSON output for this.
>
>> As a final thought is this something that is actually wanted
>> generally, I assumed it was as bgpctl has gone/is going in that
>> direction, but just don't want to assume.
>
> I see no reason why not. At least I wont veto it.
>
> --
> :wq Claudio
Broken links to the usb.org document library
Hello, The link to the specification in the SEE ALSO section of the umb(4) manpage returns an error 404 Not Found. Grepping for 'usb.org' I've found 26 references: 1/ 6 links work by redirecting to a new location. 2/ 18 links aren't working (404) but a new link exist. 3/ 2 links aren't working (404) same "new URL" format than others doesn't work and I couldn't manually find them searching the document library It's pretty much just a matter of replacing /developers/docs/devclass_docs/ with /sites/default/files/ in the URL. With a few exceptions. I would like to check if there would be a preferred way to proceed. (Before sending any patch). - Should we update those links? - Should we only refer to the document name/version and people can go an search on whatever document library will be available in the future? For the couple missing I can try to contact them. (Otherwise there's mirror available if that's acceptable). I couldn't find previous conversation on tech@ in regards to maintaining URL and external link. More details below: 1/ "working" rdr: src/lib/libusbhid/usbhid.3:.Lk http://www.usb.org/developers/docs/ OK - rdr to https://www.usb.org/documents src/share/man/man4/cdce.4:.%U http://www.usb.org/developers/docs/devclass_docs/ OK - rdr to https://www.usb.org/documents?search=%5B0%5D=55_per_page=50 src/share/man/man4/upd.4:.Lk http://www.usb.org/developers/hidpage/ OK - rdr to https://www.usb.org/hid src/share/man/man4/usb.4:.Lk http://www.usb.org/developers/docs/ OK - rdr to https://www.usb.org/documents src/sys/dev/hid/hidmt.c: * a standard here, see (from www.usb.org) OK src/sys/dev/usb/usb.c: * http://www.usb.org/developers/docs/ and OK - rdr to https://www.usb.org/documents 2/ broken but could find the new valid link src/share/man/man4/umb.4:.%U http://www.usb.org/developers/docs/devclass_docs/MBIM10Errata1_073013.zip 404 - should be: https://www.usb.org/sites/default/files/MBIM10Errata1_073013.zip src/sys/dev/hid/hidkbd.c: * HID spec: http://www.usb.org/developers/devclass_docs/HID1_11.pdf 404 - should be: https://www.usb.org/sites/default/files/documents/hid1_11.pdf src/sys/dev/hid/hidms.c: * HID spec: http://www.usb.org/developers/devclass_docs/HID1_11.pdf 404 - should be: https://www.usb.org/sites/default/files/documents/hid1_11.pdf src/sys/dev/usb/mbim.h: * http://www.usb.org/developers/docs/devclass_docs/MBIM-Compliance-1.0.pdf 404 - should be: https://www.usb.org/sites/default/files/MBIM-Compliance-1.0.pdf src/sys/dev/usb/if_umb.c: * http://www.usb.org/developers/docs/devclass_docs/MBIM10Errata1_073013.zip 404 - should be https://www.usb.org/sites/default/files/MBIM10Errata1_073013.zip src/sys/dev/usb/if_umb.c: * http://www.usb.org/developers/docs/devclass_docs/MBIM-Compliance-1.0.pdf 404 - should be: https://www.usb.org/sites/default/files/MBIM-Compliance-1.0.pdf src/sys/dev/usb/if_umb.h: * http://www.usb.org/developers/docs/devclass_docs/MBIM-Compliance-1.0.pdf 404 - should be: https://www.usb.org/sites/default/files/MBIM-Compliance-1.0.pdf src/sys/dev/usb/uhid.c: * HID spec: http://www.usb.org/developers/devclass_docs/HID1_11.pdf 404 - should be: https://www.usb.org/sites/default/files/documents/hid1_11.pdf src/sys/dev/usb/uhidev.c: * HID spec: http://www.usb.org/developers/devclass_docs/HID1_11.pdf 404 - should be: https://usb.org/sites/default/files/documents/hid1_11.pdf src/sys/dev/usb/ukbd.c: * HID spec: http://www.usb.org/developers/devclass_docs/HID1_11.pdf 404 - should be: https://www.usb.org/sites/default/files/documents/hid1_11.pdf src/sys/dev/usb/ulpt.c: * http://www.usb.org/developers/devclass_docs/usbprint11.pdf 404 - should be: https://www.usb.org/sites/default/files/usbprint11a021811.pdf src/sys/dev/usb/umodem.c: * http://www.usb.org/developers/devclass_docs/usbcdc11.pdf 404 - should be: https://www.usb.org/sites/default/files/CDC1.2_WMC1.1_052013.zip src/sys/dev/usb/ums.c: * HID spec: http://www.usb.org/developers/devclass_docs/HID1_11.pdf 404 - should be https://www.usb.org/sites/default/files/documents/hid1_11.pdf src/sys/dev/usb/usb.c: * http://www.usb.org/developers/devclass_docs/ 404 - should be: https://www.usb.org/documents?search=%5B0%5D=55_per_page=50 src/sys/dev/usb/umass.c: * http://www.usb.org/developers/devclass_docs/usbmass-ufi10.pdf 404 - should be: https://www.usb.org/sites/default/files/usbmass-ufi10.pdf src/sys/dev/usb/umass.c: * http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf 404 - should be: https://www.usb.org/sites/default/files/usbmassbulk_10.pdf src/sys/dev/usb/umass.c: * http://www.usb.org/developers/devclass_docs/usb_msc_cbi_1.1.pdf 404 - should be: https://www.usb.org/sites/default/files/usb_msc_cbi_1.1.pdf src/sys/dev/usb/umodem.c: * Comm Class spec: http://www.usb.org/developers/devclass_docs/usbccs10.pdf 404 - should be: https://www.usb.org/sites/default/files/usbccs10.pdf 3/ can't
Re: Removing old video drivers
Touché. I should probably rephrase this as "operating a slightly less insecure environment as compared to running vanilla Windows 10 on contemporary COTS hardware". And finding it really hard to throw away perfectly good hardware that suited the intended purposes really well until Matthieu unfortunately retired a series of old video drivers. For reasons which, for the record, I do understand. Keep up the good work. Dirk -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html
Re: acpibat(4): remaining battery power with multiple batteries
On Mon, May 11 2020, "Theo de Raadt" wrote:
> You sure about that? In this code, acpi.c is collecting abstracted
> information from the 3 battery drivers.
(One A/C driver and two battery drivers.)
> Maybe one of the drivers
> isn't providing enough information?
>
> Mark Kettenis wrote:
>
>> This wouldn't do the right thing if you have both acpibat(4) and
>> acpisbs(4), but I think that is already broken.
acpibat(4) doesn't attach if acpisbs(4) is present:
int
acpibat_match(struct device *parent, void *match, void *aux)
{
struct acpi_attach_args *aa = aux;
struct cfdata *cf = match;
if (((struct acpi_softc *)parent)->sc_havesbs)
return (0);
I guess this could be made more explicit by splitting those loops.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much
On Mon, May 11, 2020 at 5:52 AM Stefan Sperling wrote: > On Sun, May 10, 2020 at 04:17:46PM -0400, sven falempin wrote: > > On Sun, May 10, 2020 at 4:51 AM Stefan Sperling wrote: > > > > > On Sat, May 09, 2020 at 04:23:08PM -0400, sven falempin wrote: > > > > "no config, interface is down", Did not do anything special, > > > > upgrade => Plug card => boot => crash > > > > > > > I tested with the intel firmware it does the same. > > > > > > I'm sorry, but there is really not enough information in your messages > > > that would allow me to do anything other than just trying to somehow > > > reproduce this problem by chance. > > > > > > > I understand. > > > > there is nothing I did that is outside what I tell, > > the problem is constant, > > unavoidable > > and requires 0 config > > nor any command to enter. > > Yes, I believe what you are saying. > > The problem is that this error is not happening to me, and to diagnose it > I need to see this same error happen on a machine I have in front of me. > Once we reach that point, I can silently work on it until I find a fix. > But before then, I cannot do anything. In order to try to replicate your > setup as closely as possible, I need to know what your setup looks like. > > So, for example, knowing what hardware you have in front of you would be > a good first step. But your report lacks a dmesg. > > Please follow the guidance given on https://www.openbsd.org/report.html > Any bit of information that is requested there, if you can tell us about > it, > then please include it in your report. It will save us time in the long > term. > I changed the PCI slot used , verify the USB power, removed the other PCI card ( cleaner dmesg ). I also have two m2 modules , both of them do the same :-( Dmesg OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7975399424 (7605MB) avail mem = 7721070592 (7363MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebee0 (48 entries) bios0: vendor American Megatrends Inc. version "F2" date 06/20/2014 bios0: Gigabyte Technology Co., Ltd. AM1M-S2H acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT acpi0: wakeup devices BR11(S4) GPP0(S4) GPP1(S4) GBE_(S4) GPP2(S4) GPP3(S4) SBAZ(S4) PS2K(S3) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) XHC0(S4) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.43 MHz, 16-00-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.16 MHz, 16-00-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.16 MHz, 16-00-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.16 MHz, 16-00-01
Re: Removing old video drivers
Dirk Praet wrote: > Hi Matthieu, > > It would seem I'm a bit (too) late to this party. In short: I'm running a > high security environment leveraging the combined power of contemporary ^ > OpenBSD and ancient i386 hardware stuffed with RAM, but untouched by all ^ I'm glad this delusion is not highly infectious.
Re: Removing old video drivers
Hi Matthieu, It would seem I'm a bit (too) late to this party. In short: I'm running a high security environment leveraging the combined power of contemporary OpenBSD and ancient i386 hardware stuffed with RAM, but untouched by all kinds of modern BIOS/EFI/processor "management" technology. My recent upgrade to 6.6 has crippled several machines using the Trident video chipset, which I then found out was removed from both the 6.6 binary distribution and the Xenocara tree. Which begs the following questions: - Is it possible to bring the Trident-module back ? - If not, is there any (documented) way to still get X to work on the affected (laptop) machines using a framebuffer or other module, blacklisting in some way the Trident module which Xorg detects as the chipset in use but then bails out on because it is no longer there ? - Is the removal of additional graphics modules in the future not effectively rendering the i386 port useless for anything else than pure CLI, router or headless systems, and, shouldn't , in that case, an explicit warning be added to release notes/installer/sysupgrade ? Kind regards, Dirk PS It would seem these are bad times for anything "Trident". I recently also had to let go of several FreeBSD Trident (successor of PC-BSD/TrueOS) VM's as its developers suddenly decided to ditch FreeBSD in favor of Linux. -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html
Re: acpibat(4): remaining battery power with multiple batteries
You sure about that? In this code, acpi.c is collecting abstracted
information from the 3 battery drivers. Maybe one of the drivers
isn't providing enough information?
Mark Kettenis wrote:
> This wouldn't do the right thing if you have both acpibat(4) and
> acpisbs(4), but I think that is already broken.
>
> ok kettenis@
>
> > Index: acpi.c
> > ===
> > RCS file: /d/cvs/src/sys/dev/acpi/acpi.c,v
> > retrieving revision 1.383
> > diff -u -p -p -u -r1.383 acpi.c
> > --- acpi.c 8 May 2020 11:18:01 - 1.383
> > +++ acpi.c 8 May 2020 15:04:50 -
> > @@ -3503,7 +3503,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> > struct acpi_sbs *sbs;
> > struct apm_power_info *pi = (struct apm_power_info *)data;
> > int bats;
> > - unsigned int remaining, rem, minutes, rate;
> > + unsigned int capacity, remaining, minutes, rate;
> > int s;
> >
> > if (!acpi_cd.cd_ndevs || APMUNIT(dev) != 0 ||
> > @@ -3554,7 +3554,8 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> > pi->battery_life = 0;
> > pi->minutes_left = 0;
> > bats = 0;
> > - remaining = rem = 0;
> > + capacity = 0;
> > + remaining = 0;
> > minutes = 0;
> > rate = 0;
> > SLIST_FOREACH(bat, >sc_bat, aba_link) {
> > @@ -3565,11 +3566,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> > continue;
> >
> > bats++;
> > - rem = (bat->aba_softc->sc_bst.bst_capacity * 100) /
> > - bat->aba_softc->sc_bix.bix_last_capacity;
> > - if (rem > 100)
> > - rem = 100;
> > - remaining += rem;
> > + capacity += bat->aba_softc->sc_bix.bix_last_capacity;
> > + remaining += min(bat->aba_softc->sc_bst.bst_capacity,
> > + bat->aba_softc->sc_bix.bix_last_capacity);
> >
> > if (bat->aba_softc->sc_bst.bst_rate == BST_UNKNOWN)
> > continue;
> > @@ -3587,10 +3586,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> > continue;
> >
> > bats++;
> > - rem = sbs->asbs_softc->sc_battery.rel_charge;
> > - if (rem > 100)
> > - rem = 100;
> > - remaining += rem;
> > + capacity += 100;
> > + remaining += min(100,
> > + sbs->asbs_softc->sc_battery.rel_charge);
> >
> > if (sbs->asbs_softc->sc_battery.run_time ==
> > ACPISBS_VALUE_UNKNOWN)
> > @@ -3613,7 +3611,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> > pi->minutes_left = 60 * minutes / rate;
> >
> > /* running on battery */
> > - pi->battery_life = remaining / bats;
> > + pi->battery_life = remaining * 100 / capacity;
> > if (pi->battery_life > 50)
> > pi->battery_state = APM_BATT_HIGH;
> > else if (pi->battery_life > 25)
> >
> > --
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
> >
> >
>
Re: httpd(8): add a "dark mode" in directory listings and error pages
On Mon, May 11, 2020 at 03:43:39PM +0200, Charlene Wendling wrote: > On Mon, 11 May 2020 14:06:33 +0200 > Klemens Nanni wrote: > > > On Mon, May 11, 2020 at 11:20:58AM +0200, Charlene Wendling wrote: > > > Hi, > > > > > > Similarly to what has been done for the OpenBSD project pages [0], > > > this diff adds a "dark mode" to directory listings and error pages > > > in httpd, using OpenBSD's dark color scheme. > > Will this work for all pages served by httpd? > > No, this only works for directory listings and html error pages. > > As far as i (and grep) know they're the only html pages generated by > httpd itself. Indeed, those are the only ones. kn: httpd is not changing static files or content served via fcgi. If you want a dark mode for those you need to arrange your own css. > > > I used bgplg(8) again yesterday and thought about adapting the dark > > mode from openbsd.org to this little frontend (but didn't know how). > > > -- I'm not entirely sure you are real.
Re: httpd(8): add a "dark mode" in directory listings and error pages
On Mon, 11 May 2020 14:06:33 +0200 Klemens Nanni wrote: > On Mon, May 11, 2020 at 11:20:58AM +0200, Charlene Wendling wrote: > > Hi, > > > > Similarly to what has been done for the OpenBSD project pages [0], > > this diff adds a "dark mode" to directory listings and error pages > > in httpd, using OpenBSD's dark color scheme. > Will this work for all pages served by httpd? No, this only works for directory listings and html error pages. As far as i (and grep) know they're the only html pages generated by httpd itself. > I used bgplg(8) again yesterday and thought about adapting the dark > mode from openbsd.org to this little frontend (but didn't know how). >
Re: ospfctl json support
On Mon, May 11, 2020 at 12:38:38PM +0100, Richard Chivers wrote: > Hi, > > I have done some work over the last few days to implement json support > into ospfctl following the work done recently in bgpctl. > > I have some queries, hoping to get some help with. > > The change involves a refactor of ospfctl, but reuses the recent > json.c written by Claudio, that is in the > usr.sbin/bgpctl directory. At present no changes have been required at all. > What is the best approach here, should/could this be centralised somewhere? At the moment just copy the files into ospfctl. We did the same thing with other bits in the tree. My json API is super minimal and is for sure not something that should be put into a common framework right now. The way objects and arrays are opened and closed is a bit rough and does not always work well. > In some cases there is room for change, for example ospfctl sh rib & > ospfctl sh rib detail. > > In my view here, it makes sense to have a full list returned rather > than splitting json into multiple lists of Router, Network and > External. > I looked for inspiration in the bgpctl, but couldn't find a similar > pattern. The reason for a single list is that if consuming the json, > I expect you will not want code that has to iterate over three > separate arrays. Just looking for some feedback really. The original > split > made sense for screen use, just not so sure about machine readability. > This issue also applies to ospfctl sh data, which returns 3 lists. A lot of this is depending on the imsgs used between ospfctl and ospfd. IIRC ospfd sends all data in one batch so the multiple lists just happen by ospfctl and indeed for json output it would be best to display the rib as a single array of entries (which have a similar structure but probably per LSA specific attributes). > When I am finished, should I just post the diff on here? Just > conscious it is quite a big refactor, albeit much of the code is > reused just moved into output.c as > was done for bgpctl. Please split it up like I did it for bgpctl. I first did a lot of the moving and cleanup and only later added the new input mode. This makes the individual steps smaller to review. > I am testing each call individually against a set of openbsd 6.6 boxes > we have running, which is great for ospfd. What is the normal > practise for ospf6, is there a script run to replicate code changes or > is it just a case of making very similar changes line by line? There is no script, you do it by hand it is quicker. > Just looking for the general thinking and approach I guess. I don't > currently have ospf6 set-up so that would be some overhead. > Happy to configure it though if needed/expected. Get ospfctl first, after that ospf6ctl can be done (and maybe somebody else will take care of that). > Finally what was the driver under bgpctl for the json output, ours is > for reading metrics to populate telemetry, just interested as the > purpose other > people have. Having this context will help in micro decisions when > implementing the json structure. I'm doing this work to provide JSON payloads to external looking glasses. I would not put the RIB into telemetry (that is just useless churn and load on the telemetry system). In bgpctl the terse outputs are simple space separated outputs for telemetry scripting but I guess people will also use the JSON output for this. > As a final thought is this something that is actually wanted > generally, I assumed it was as bgpctl has gone/is going in that > direction, but just don't want to assume. I see no reason why not. At least I wont veto it. -- :wq Claudio
Re: httpd(8): add a "dark mode" in directory listings and error pages
On Mon, May 11, 2020 at 11:20:58AM +0200, Charlene Wendling wrote: > Hi, > > Similarly to what has been done for the OpenBSD project pages [0], this > diff adds a "dark mode" to directory listings and error pages in httpd, > using OpenBSD's dark color scheme. Will this work for all pages served by httpd? I used bgplg(8) again yesterday and thought about adapting the dark mode from openbsd.org to this little frontend (but didn't know how).
Re: httpd(8): add a "dark mode" in directory listings and error pages
On Mon, 11 May 2020 13:05:08 +0200
Florian Obser wrote:
> On Mon, May 11, 2020 at 11:20:58AM +0200, Charlene Wendling wrote:
> > Hi,
> >
> > Similarly to what has been done for the OpenBSD project pages [0],
> > this diff adds a "dark mode" to directory listings and error pages
> > in httpd, using OpenBSD's dark color scheme.
> >
> > The goal is to avoid switching from a "dark mode" html page to a
> > pure white {directory listing,error} one, and this on the same site,
> > because it's very upsetting.
> >
> > This is how it looks like [1] in Firefox (Iridium is in light mode).
> >
> > I already had some comments and feedback from florian@ (error pages
> > need love too), clematis (correct background color), danj@
> > (improve code readability) amongst others, but more is welcome :)
> >
> > Charlène.
> >
> >
> > [0] https://marc.info/?l=openbsd-cvs=155942699008642=2
> > [1] http://0x0.st/i_yc.png
> >
> > [...]
> > + "body { background-color: #1e1f21; color: #EEEFF1; }\n"
>
> please use uppercase here ^^^
>
> > + "body { background-color: #1e1f21; color: #EEEFF1; }\n"
>
> and here ^^^
> with those fixed OK florian@
> --
> I'm not entirely sure you are real.
I modified the diff so it has consistent casing this time:
Index: usr.sbin/httpd/server_file.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
retrieving revision 1.66
diff -u -p -r1.66 server_file.c
--- usr.sbin/httpd/server_file.c15 Jun 2018 12:36:05 - 1.66
+++ usr.sbin/httpd/server_file.c10 May 2020 22:29:59 -
@@ -477,7 +477,11 @@ server_file_index(struct httpd *env, str
/* A CSS stylesheet allows minimal customization by the user */
style = "body { background-color: white; color: black; font-family: "
- "sans-serif; }\nhr { border: 0; border-bottom: 1px dashed; }\n";
+ "sans-serif; }\nhr { border: 0; border-bottom: 1px dashed; }\n"
+ "@media (prefers-color-scheme: dark) {\n"
+ "body { background-color: #1E1F21; color: #EEEFF1; }\n"
+ "a { color: #BAD7FF; }\n}";
+
/* Generate simple HTML index document */
if (evbuffer_add_printf(evb,
"\n"
Index: usr.sbin/httpd/server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.137
diff -u -p -r1.137 server_http.c
--- usr.sbin/httpd/server_http.c25 Feb 2020 15:18:41 - 1.137
+++ usr.sbin/httpd/server_http.c10 May 2020 22:30:00 -
@@ -921,7 +921,10 @@ server_abort_http(struct client *clt, un
/* A CSS stylesheet allows minimal customization by the user */
style = "body { background-color: white; color: black; font-family: "
"'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
- "hr { border: 0; border-bottom: 1px dashed; }\n";
+ "hr { border: 0; border-bottom: 1px dashed; }\n"
+ "@media (prefers-color-scheme: dark) {\n"
+ "body { background-color: #1E1F21; color: #EEEFF1; }\n"
+ "a { color: #BAD7FF; }\n}";
/* Generate simple HTML error document */
if ((bodylen = asprintf(,
ospfctl json support
Hi, I have done some work over the last few days to implement json support into ospfctl following the work done recently in bgpctl. I have some queries, hoping to get some help with. The change involves a refactor of ospfctl, but reuses the recent json.c written by Claudio, that is in the usr.sbin/bgpctl directory. At present no changes have been required at all. What is the best approach here, should/could this be centralised somewhere? In some cases there is room for change, for example ospfctl sh rib & ospfctl sh rib detail. In my view here, it makes sense to have a full list returned rather than splitting json into multiple lists of Router, Network and External. I looked for inspiration in the bgpctl, but couldn't find a similar pattern. The reason for a single list is that if consuming the json, I expect you will not want code that has to iterate over three separate arrays. Just looking for some feedback really. The original split made sense for screen use, just not so sure about machine readability. This issue also applies to ospfctl sh data, which returns 3 lists. When I am finished, should I just post the diff on here? Just conscious it is quite a big refactor, albeit much of the code is reused just moved into output.c as was done for bgpctl. I am testing each call individually against a set of openbsd 6.6 boxes we have running, which is great for ospfd. What is the normal practise for ospf6, is there a script run to replicate code changes or is it just a case of making very similar changes line by line? Just looking for the general thinking and approach I guess. I don't currently have ospf6 set-up so that would be some overhead. Happy to configure it though if needed/expected. Finally what was the driver under bgpctl for the json output, ours is for reading metrics to populate telemetry, just interested as the purpose other people have. Having this context will help in micro decisions when implementing the json structure. As a final thought is this something that is actually wanted generally, I assumed it was as bgpctl has gone/is going in that direction, but just don't want to assume. Cheers Rich
Re: httpd(8): add a "dark mode" in directory listings and error pages
On Mon, May 11, 2020 at 11:20:58AM +0200, Charlene Wendling wrote:
> Hi,
>
> Similarly to what has been done for the OpenBSD project pages [0], this
> diff adds a "dark mode" to directory listings and error pages in httpd,
> using OpenBSD's dark color scheme.
>
> The goal is to avoid switching from a "dark mode" html page to a pure
> white {directory listing,error} one, and this on the same site,
> because it's very upsetting.
>
> This is how it looks like [1] in Firefox (Iridium is in light mode).
>
> I already had some comments and feedback from florian@ (error pages
> need love too), clematis (correct background color), danj@
> (improve code readability) amongst others, but more is welcome :)
>
> Charlène.
>
>
> [0] https://marc.info/?l=openbsd-cvs=155942699008642=2
> [1] http://0x0.st/i_yc.png
>
>
> Index: usr.sbin/httpd/server_file.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 server_file.c
> --- usr.sbin/httpd/server_file.c 15 Jun 2018 12:36:05 - 1.66
> +++ usr.sbin/httpd/server_file.c 10 May 2020 22:29:59 -
> @@ -477,7 +477,11 @@ server_file_index(struct httpd *env, str
>
> /* A CSS stylesheet allows minimal customization by the user */
> style = "body { background-color: white; color: black; font-family: "
> - "sans-serif; }\nhr { border: 0; border-bottom: 1px dashed; }\n";
> + "sans-serif; }\nhr { border: 0; border-bottom: 1px dashed; }\n"
> + "@media (prefers-color-scheme: dark) {\n"
> + "body { background-color: #1e1f21; color: #EEEFF1; }\n"
please use uppercase here ^^^
> + "a { color: #BAD7FF; }\n}";
> +
> /* Generate simple HTML index document */
> if (evbuffer_add_printf(evb,
> "\n"
> Index: usr.sbin/httpd/server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.137
> diff -u -p -r1.137 server_http.c
> --- usr.sbin/httpd/server_http.c 25 Feb 2020 15:18:41 - 1.137
> +++ usr.sbin/httpd/server_http.c 10 May 2020 22:30:00 -
> @@ -921,7 +921,10 @@ server_abort_http(struct client *clt, un
> /* A CSS stylesheet allows minimal customization by the user */
> style = "body { background-color: white; color: black; font-family: "
> "'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
> - "hr { border: 0; border-bottom: 1px dashed; }\n";
> + "hr { border: 0; border-bottom: 1px dashed; }\n"
> + "@media (prefers-color-scheme: dark) {\n"
> + "body { background-color: #1e1f21; color: #EEEFF1; }\n"
and here ^^^
with those fixed OK florian@
> + "a { color: #BAD7FF; }\n}";
>
> /* Generate simple HTML error document */
> if ((bodylen = asprintf(,
>
--
I'm not entirely sure you are real.
Re: acpibat(4): remaining battery power with multiple batteries
> From: Jeremie Courreges-Anglas
> Date: Mon, 11 May 2020 11:40:23 +0200
> Content-Type: text/plain
>
> On Fri, May 08 2020, Jeremie Courreges-Anglas wrote:
> > Overall remaining battery power is currently the average of the
> > remaining power (in percents) of each battery. This is misleading if
> > your laptop uses a large external battery which drains out first, and
> > a smaller internal battery (common scheme on eg thinkpad machines).
> > Overall battery power decreases much faster when you switch to the
> > smaller battery. This odd behavior was reported by a friend a few weeks
> > ago.
> >
> > The diff below attempts to fix this: compute the sum of the remaining
> > power and capacity, *then* compute the overall remaining percentage.
> > No regression on my thinkpad x270 with two batteries of similar
> > capacity. I don't know whether the original reporter will be able to
> > test this soon.
> >
> > The code touches the acpisbs(4) bits, hopefully without changing the
> > current behavior. acpisbs(4) currently doesn't support multiple
> > batteries.
> >
> > Test reports, feedback, oks welcome.
>
> I got successful test reports from benno@ and fellow lidstah (original
> reporter). With a 6600mAh external battery and a 2200mAh internal
> battery, lidstah sees an overall battery percentage at ~22% instead of
> ~50% when the external battery drains out.
>
> Still looking for oks :)
This wouldn't do the right thing if you have both acpibat(4) and
acpisbs(4), but I think that is already broken.
ok kettenis@
> Index: acpi.c
> ===
> RCS file: /d/cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.383
> diff -u -p -p -u -r1.383 acpi.c
> --- acpi.c8 May 2020 11:18:01 - 1.383
> +++ acpi.c8 May 2020 15:04:50 -
> @@ -3503,7 +3503,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> struct acpi_sbs *sbs;
> struct apm_power_info *pi = (struct apm_power_info *)data;
> int bats;
> - unsigned int remaining, rem, minutes, rate;
> + unsigned int capacity, remaining, minutes, rate;
> int s;
>
> if (!acpi_cd.cd_ndevs || APMUNIT(dev) != 0 ||
> @@ -3554,7 +3554,8 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> pi->battery_life = 0;
> pi->minutes_left = 0;
> bats = 0;
> - remaining = rem = 0;
> + capacity = 0;
> + remaining = 0;
> minutes = 0;
> rate = 0;
> SLIST_FOREACH(bat, >sc_bat, aba_link) {
> @@ -3565,11 +3566,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> continue;
>
> bats++;
> - rem = (bat->aba_softc->sc_bst.bst_capacity * 100) /
> - bat->aba_softc->sc_bix.bix_last_capacity;
> - if (rem > 100)
> - rem = 100;
> - remaining += rem;
> + capacity += bat->aba_softc->sc_bix.bix_last_capacity;
> + remaining += min(bat->aba_softc->sc_bst.bst_capacity,
> + bat->aba_softc->sc_bix.bix_last_capacity);
>
> if (bat->aba_softc->sc_bst.bst_rate == BST_UNKNOWN)
> continue;
> @@ -3587,10 +3586,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> continue;
>
> bats++;
> - rem = sbs->asbs_softc->sc_battery.rel_charge;
> - if (rem > 100)
> - rem = 100;
> - remaining += rem;
> + capacity += 100;
> + remaining += min(100,
> + sbs->asbs_softc->sc_battery.rel_charge);
>
> if (sbs->asbs_softc->sc_battery.run_time ==
> ACPISBS_VALUE_UNKNOWN)
> @@ -3613,7 +3611,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
> pi->minutes_left = 60 * minutes / rate;
>
> /* running on battery */
> - pi->battery_life = remaining / bats;
> + pi->battery_life = remaining * 100 / capacity;
> if (pi->battery_life > 50)
> pi->battery_state = APM_BATT_HIGH;
> else if (pi->battery_life > 25)
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
>
Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much
On Sun, May 10, 2020 at 04:17:46PM -0400, sven falempin wrote: > On Sun, May 10, 2020 at 4:51 AM Stefan Sperling wrote: > > > On Sat, May 09, 2020 at 04:23:08PM -0400, sven falempin wrote: > > > "no config, interface is down", Did not do anything special, > > > upgrade => Plug card => boot => crash > > > > > I tested with the intel firmware it does the same. > > > > I'm sorry, but there is really not enough information in your messages > > that would allow me to do anything other than just trying to somehow > > reproduce this problem by chance. > > > > I understand. > > there is nothing I did that is outside what I tell, > the problem is constant, > unavoidable > and requires 0 config > nor any command to enter. Yes, I believe what you are saying. The problem is that this error is not happening to me, and to diagnose it I need to see this same error happen on a machine I have in front of me. Once we reach that point, I can silently work on it until I find a fix. But before then, I cannot do anything. In order to try to replicate your setup as closely as possible, I need to know what your setup looks like. So, for example, knowing what hardware you have in front of you would be a good first step. But your report lacks a dmesg. Please follow the guidance given on https://www.openbsd.org/report.html Any bit of information that is requested there, if you can tell us about it, then please include it in your report. It will save us time in the long term.
Re: acpibat(4): remaining battery power with multiple batteries
On Fri, May 08 2020, Jeremie Courreges-Anglas wrote:
> Overall remaining battery power is currently the average of the
> remaining power (in percents) of each battery. This is misleading if
> your laptop uses a large external battery which drains out first, and
> a smaller internal battery (common scheme on eg thinkpad machines).
> Overall battery power decreases much faster when you switch to the
> smaller battery. This odd behavior was reported by a friend a few weeks
> ago.
>
> The diff below attempts to fix this: compute the sum of the remaining
> power and capacity, *then* compute the overall remaining percentage.
> No regression on my thinkpad x270 with two batteries of similar
> capacity. I don't know whether the original reporter will be able to
> test this soon.
>
> The code touches the acpisbs(4) bits, hopefully without changing the
> current behavior. acpisbs(4) currently doesn't support multiple
> batteries.
>
> Test reports, feedback, oks welcome.
I got successful test reports from benno@ and fellow lidstah (original
reporter). With a 6600mAh external battery and a 2200mAh internal
battery, lidstah sees an overall battery percentage at ~22% instead of
~50% when the external battery drains out.
Still looking for oks :)
Index: acpi.c
===
RCS file: /d/cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.383
diff -u -p -p -u -r1.383 acpi.c
--- acpi.c 8 May 2020 11:18:01 - 1.383
+++ acpi.c 8 May 2020 15:04:50 -
@@ -3503,7 +3503,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
struct acpi_sbs *sbs;
struct apm_power_info *pi = (struct apm_power_info *)data;
int bats;
- unsigned int remaining, rem, minutes, rate;
+ unsigned int capacity, remaining, minutes, rate;
int s;
if (!acpi_cd.cd_ndevs || APMUNIT(dev) != 0 ||
@@ -3554,7 +3554,8 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
pi->battery_life = 0;
pi->minutes_left = 0;
bats = 0;
- remaining = rem = 0;
+ capacity = 0;
+ remaining = 0;
minutes = 0;
rate = 0;
SLIST_FOREACH(bat, >sc_bat, aba_link) {
@@ -3565,11 +3566,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
continue;
bats++;
- rem = (bat->aba_softc->sc_bst.bst_capacity * 100) /
- bat->aba_softc->sc_bix.bix_last_capacity;
- if (rem > 100)
- rem = 100;
- remaining += rem;
+ capacity += bat->aba_softc->sc_bix.bix_last_capacity;
+ remaining += min(bat->aba_softc->sc_bst.bst_capacity,
+ bat->aba_softc->sc_bix.bix_last_capacity);
if (bat->aba_softc->sc_bst.bst_rate == BST_UNKNOWN)
continue;
@@ -3587,10 +3586,9 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
continue;
bats++;
- rem = sbs->asbs_softc->sc_battery.rel_charge;
- if (rem > 100)
- rem = 100;
- remaining += rem;
+ capacity += 100;
+ remaining += min(100,
+ sbs->asbs_softc->sc_battery.rel_charge);
if (sbs->asbs_softc->sc_battery.run_time ==
ACPISBS_VALUE_UNKNOWN)
@@ -3613,7 +3611,7 @@ acpiioctl(dev_t dev, u_long cmd, caddr_t
pi->minutes_left = 60 * minutes / rate;
/* running on battery */
- pi->battery_life = remaining / bats;
+ pi->battery_life = remaining * 100 / capacity;
if (pi->battery_life > 50)
pi->battery_state = APM_BATT_HIGH;
else if (pi->battery_life > 25)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
`seltrue_kqfilter' corresponding to `seltrue'
Match direct `seltrue' usages with a corresponding `seltrue_kqfilter'.
This ensure spec_kqfilter() won't return an error when spec_poll()
returns success for a given device.
Ok?
Index: arch/arm64/arm64/conf.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/conf.c,v
retrieving revision 1.12
diff -u -p -r1.12 conf.c
--- arch/arm64/arm64/conf.c 23 Jan 2020 02:40:21 - 1.12
+++ arch/arm64/arm64/conf.c 11 May 2020 09:22:58 -
@@ -83,7 +83,7 @@ int nblkdev = nitems(bdevsw);
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
(dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
(dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev }
+ (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
/* open, close, ioctl, select -- XXX should be a generic device */
#define cdev_ocis_init(c,n) { \
@@ -97,7 +97,7 @@ int nblkdev = nitems(bdevsw);
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
(dev_type_write((*))) enodev, (dev_type_ioctl((*))) enodev, \
(dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev, 0 }
+ (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
#definemmread mmrw
Index: arch/luna88k/include/conf.h
===
RCS file: /cvs/src/sys/arch/luna88k/include/conf.h,v
retrieving revision 1.5
diff -u -p -r1.5 conf.h
--- arch/luna88k/include/conf.h 17 Dec 2016 05:22:34 - 1.5
+++ arch/luna88k/include/conf.h 11 May 2020 09:22:58 -
@@ -53,7 +53,7 @@ cdev_decl(wd);
dev_init(c,n,open), dev_init(c,n,close), \
(dev_type_read((*))) enodev, dev_init(c,n,write), \
dev_init(c,n,ioctl), (dev_type_stop((*))) enodev, \
- 0, seltrue, (dev_type_mmap((*))) enodev }
+ 0, seltrue, (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
/* open, close, ioctl, mmap */
#define cdev_pcex_init(c,n) { \
Index: arch/sparc64/include/conf.h
===
RCS file: /cvs/src/sys/arch/sparc64/include/conf.h,v
retrieving revision 1.24
diff -u -p -r1.24 conf.h
--- arch/sparc64/include/conf.h 8 Dec 2012 20:38:10 - 1.24
+++ arch/sparc64/include/conf.h 11 May 2020 09:22:58 -
@@ -124,6 +124,6 @@ cdev_decl(sbpp);
#definecdev_bpp_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), (dev_type_read((*))) enodev, \
dev_init(c,n,write), dev_init(c,n,ioctl), (dev_type_stop((*))) nullop, \
- 0, seltrue, (dev_type_mmap((*))) enodev }
+ 0, seltrue, (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
cdev_decl(bpp);
Index: sys/conf.h
===
RCS file: /cvs/src/sys/sys/conf.h,v
retrieving revision 1.150
diff -u -p -r1.150 conf.h
--- sys/conf.h 21 Apr 2020 08:29:27 - 1.150
+++ sys/conf.h 11 May 2020 09:22:58 -
@@ -200,7 +200,7 @@ extern struct cdevsw cdevsw[];
(dev_type_open((*))) enodev, (dev_type_close((*))) enodev, \
(dev_type_read((*))) enodev, (dev_type_write((*))) enodev, \
(dev_type_ioctl((*))) enodev, (dev_type_stop((*))) enodev, \
- 0, seltrue, (dev_type_mmap((*))) enodev }
+ 0, seltrue, (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
/* open, close, read, write, ioctl, poll, kqfilter -- XXX should be a tty */
#definecdev_cn_init(c,n) { \
Re: httpd(8): add a "dark mode" in directory listings and error pages
On Mon, May 11, 2020 at 11:20:58AM +0200, Charlene Wendling wrote:
> Hi,
>
> Similarly to what has been done for the OpenBSD project pages [0], this
> diff adds a "dark mode" to directory listings and error pages in httpd,
> using OpenBSD's dark color scheme.
>
> The goal is to avoid switching from a "dark mode" html page to a pure
> white {directory listing,error} one, and this on the same site,
> because it's very upsetting.
>
> This is how it looks like [1] in Firefox (Iridium is in light mode).
>
> I already had some comments and feedback from florian@ (error pages
> need love too), clematis (correct background color), danj@
> (improve code readability) amongst others, but more is welcome :)
>
> Charlène.
>
>
Hi,
Afaik dark mode is still in editor's draft status:
https://drafts.csswg.org/mediaqueries-5/#descdef-media-prefers-color-scheme
Maybe an other option is to remove the default body background-color and text
color so the default client preference is used?
> [0] https://marc.info/?l=openbsd-cvs=155942699008642=2
> [1] http://0x0.st/i_yc.png
>
>
> Index: usr.sbin/httpd/server_file.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 server_file.c
> --- usr.sbin/httpd/server_file.c 15 Jun 2018 12:36:05 - 1.66
> +++ usr.sbin/httpd/server_file.c 10 May 2020 22:29:59 -
> @@ -477,7 +477,11 @@ server_file_index(struct httpd *env, str
>
> /* A CSS stylesheet allows minimal customization by the user */
> style = "body { background-color: white; color: black; font-family: "
> - "sans-serif; }\nhr { border: 0; border-bottom: 1px dashed; }\n";
> + "sans-serif; }\nhr { border: 0; border-bottom: 1px dashed; }\n"
> + "@media (prefers-color-scheme: dark) {\n"
> + "body { background-color: #1e1f21; color: #EEEFF1; }\n"
> + "a { color: #BAD7FF; }\n}";
> +
> /* Generate simple HTML index document */
> if (evbuffer_add_printf(evb,
> "\n"
> Index: usr.sbin/httpd/server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.137
> diff -u -p -r1.137 server_http.c
> --- usr.sbin/httpd/server_http.c 25 Feb 2020 15:18:41 - 1.137
> +++ usr.sbin/httpd/server_http.c 10 May 2020 22:30:00 -
> @@ -921,7 +921,10 @@ server_abort_http(struct client *clt, un
> /* A CSS stylesheet allows minimal customization by the user */
> style = "body { background-color: white; color: black; font-family: "
> "'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
> - "hr { border: 0; border-bottom: 1px dashed; }\n";
> + "hr { border: 0; border-bottom: 1px dashed; }\n"
> + "@media (prefers-color-scheme: dark) {\n"
> + "body { background-color: #1e1f21; color: #EEEFF1; }\n"
> + "a { color: #BAD7FF; }\n}";
>
> /* Generate simple HTML error document */
> if ((bodylen = asprintf(,
>
--
Kind regards,
Hiltjo
Prefer seltrue_kqfilter() over filt_seltrue()
Instead of redefining a custom `filterop' with the same `f_event'
handler pointing to filt_seltrue() simply use seltrue_kqfilter().
Ok?
Index: dev/usb/ugen.c
===
RCS file: /cvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.105
diff -u -p -r1.105 ugen.c
--- dev/usb/ugen.c 7 Apr 2020 13:27:51 - 1.105
+++ dev/usb/ugen.c 11 May 2020 09:17:34 -
@@ -1342,13 +1342,6 @@ const struct filterops ugenread_isoc_fil
.f_event= filt_ugenread_isoc,
};
-const struct filterops ugen_seltrue_filtops = {
- .f_flags= FILTEROP_ISFD,
- .f_attach = NULL,
- .f_detach = filt_ugenrdetach,
- .f_event= filt_seltrue,
-};
-
int
ugenkqfilter(dev_t dev, struct knote *kn)
{
@@ -1378,13 +1371,11 @@ ugenkqfilter(dev_t dev, struct knote *kn
kn->kn_fop = _isoc_filtops;
break;
case UE_BULK:
- /*
+ /*
* We have no easy way of determining if a read will
* yield any data or a write will happen.
-* So, emulate "seltrue".
*/
- kn->kn_fop = _seltrue_filtops;
- break;
+ return (seltrue_kqfilter(dev, kn));
default:
return (EINVAL);
}
@@ -1402,10 +1393,8 @@ ugenkqfilter(dev_t dev, struct knote *kn
/*
* We have no easy way of determining if a read will
* yield any data or a write will happen.
-* So, emulate "seltrue".
*/
- kn->kn_fop = _seltrue_filtops;
- break;
+ return (seltrue_kqfilter(dev, kn));
default:
return (EINVAL);
}
Index: dev/usb/uhid.c
===
RCS file: /cvs/src/sys/dev/usb/uhid.c,v
retrieving revision 1.79
diff -u -p -r1.79 uhid.c
--- dev/usb/uhid.c 7 Apr 2020 13:27:51 - 1.79
+++ dev/usb/uhid.c 11 May 2020 09:17:34 -
@@ -467,13 +467,6 @@ const struct filterops uhidread_filtops
.f_event= filt_uhidread,
};
-const struct filterops uhid_seltrue_filtops = {
- .f_flags= FILTEROP_ISFD,
- .f_attach = NULL,
- .f_detach = filt_uhidrdetach,
- .f_event= filt_seltrue,
-};
-
int
uhidkqfilter(dev_t dev, struct knote *kn)
{
@@ -494,9 +487,7 @@ uhidkqfilter(dev_t dev, struct knote *kn
break;
case EVFILT_WRITE:
- klist = >sc_rsel.si_note;
- kn->kn_fop = _seltrue_filtops;
- break;
+ return (seltrue_kqfilter(dev, kn));
default:
return (EINVAL);
Index: miscfs/fuse/fuse_device.c
===
RCS file: /cvs/src/sys/miscfs/fuse/fuse_device.c,v
retrieving revision 1.33
diff -u -p -r1.33 fuse_device.c
--- miscfs/fuse/fuse_device.c 7 Apr 2020 13:27:51 - 1.33
+++ miscfs/fuse/fuse_device.c 11 May 2020 09:17:34 -
@@ -76,13 +76,6 @@ const static struct filterops fuse_rd_fi
.f_event= filt_fuse_read,
};
-const static struct filterops fuse_seltrue_filtops = {
- .f_flags= FILTEROP_ISFD,
- .f_attach = NULL,
- .f_detach = filt_fuse_rdetach,
- .f_event= filt_seltrue,
-};
-
#ifdef FUSE_DEBUG
static void
fuse_dump_buff(char *buff, int len)
@@ -555,9 +548,7 @@ fusekqfilter(dev_t dev, struct knote *kn
kn->kn_fop = _rd_filtops;
break;
case EVFILT_WRITE:
- klist = >fd_rsel.si_note;
- kn->kn_fop = _seltrue_filtops;
- break;
+ return (seltrue_kqfilter(dev, kn));
default:
return (EINVAL);
}
httpd(8): add a "dark mode" in directory listings and error pages
Hi,
Similarly to what has been done for the OpenBSD project pages [0], this
diff adds a "dark mode" to directory listings and error pages in httpd,
using OpenBSD's dark color scheme.
The goal is to avoid switching from a "dark mode" html page to a pure
white {directory listing,error} one, and this on the same site,
because it's very upsetting.
This is how it looks like [1] in Firefox (Iridium is in light mode).
I already had some comments and feedback from florian@ (error pages
need love too), clematis (correct background color), danj@
(improve code readability) amongst others, but more is welcome :)
Charlène.
[0] https://marc.info/?l=openbsd-cvs=155942699008642=2
[1] http://0x0.st/i_yc.png
Index: usr.sbin/httpd/server_file.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
retrieving revision 1.66
diff -u -p -r1.66 server_file.c
--- usr.sbin/httpd/server_file.c15 Jun 2018 12:36:05 - 1.66
+++ usr.sbin/httpd/server_file.c10 May 2020 22:29:59 -
@@ -477,7 +477,11 @@ server_file_index(struct httpd *env, str
/* A CSS stylesheet allows minimal customization by the user */
style = "body { background-color: white; color: black; font-family: "
- "sans-serif; }\nhr { border: 0; border-bottom: 1px dashed; }\n";
+ "sans-serif; }\nhr { border: 0; border-bottom: 1px dashed; }\n"
+ "@media (prefers-color-scheme: dark) {\n"
+ "body { background-color: #1e1f21; color: #EEEFF1; }\n"
+ "a { color: #BAD7FF; }\n}";
+
/* Generate simple HTML index document */
if (evbuffer_add_printf(evb,
"\n"
Index: usr.sbin/httpd/server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.137
diff -u -p -r1.137 server_http.c
--- usr.sbin/httpd/server_http.c25 Feb 2020 15:18:41 - 1.137
+++ usr.sbin/httpd/server_http.c10 May 2020 22:30:00 -
@@ -921,7 +921,10 @@ server_abort_http(struct client *clt, un
/* A CSS stylesheet allows minimal customization by the user */
style = "body { background-color: white; color: black; font-family: "
"'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
- "hr { border: 0; border-bottom: 1px dashed; }\n";
+ "hr { border: 0; border-bottom: 1px dashed; }\n"
+ "@media (prefers-color-scheme: dark) {\n"
+ "body { background-color: #1e1f21; color: #EEEFF1; }\n"
+ "a { color: #BAD7FF; }\n}";
/* Generate simple HTML error document */
if ((bodylen = asprintf(,
Kill biosselect/biospoll/pctrpoll defines
Instead of using a define, put `seltrue' directly in the custom
cdev_*_init() macro. This is the approach taken by various MI
macros in sys/conf.h.
While here use the kqfilter equivalent to `seltrue' to ensure both
interfaces are coherent. Without this spec_kqfilter() returns an
error while spec_poll() returns success.
ok?
Index: arch/amd64/amd64/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v
retrieving revision 1.68
diff -u -p -r1.68 conf.c
--- arch/amd64/amd64/conf.c 24 Jan 2020 05:14:51 - 1.68
+++ arch/amd64/amd64/conf.c 11 May 2020 08:39:54 -
@@ -86,21 +86,21 @@ int nblkdev = nitems(bdevsw);
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
(dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
(dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev }
+ (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
-/* open, close, ioctl, select -- XXX should be a generic device */
+/* open, close, ioctl, seltrue, seltrue_kqfilter */
#define cdev_ocis_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), (dev_type_read((*))) enodev, \
(dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
-(dev_type_stop((*))) enodev, 0, dev_init(c,n,poll), \
-(dev_type_mmap((*))) enodev, 0 }
+(dev_type_stop((*))) enodev, 0, seltrue, \
+(dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
/* open, close, read */
#define cdev_nvram_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
(dev_type_write((*))) enodev, (dev_type_ioctl((*))) enodev, \
(dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev, 0 }
+ (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
/* open, close, ioctl */
#define cdev_vmm_init(c,n) { \
@@ -109,7 +109,7 @@ int nblkdev = nitems(bdevsw);
(dev_type_write((*))) enodev, \
dev_init(c,n,ioctl), \
(dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev }
+ (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
#definemmread mmrw
#definemmwrite mmrw
Index: arch/amd64/include/conf.h
===
RCS file: /cvs/src/sys/arch/amd64/include/conf.h,v
retrieving revision 1.7
diff -u -p -r1.7 conf.h
--- arch/amd64/include/conf.h 8 Jan 2016 11:20:58 - 1.7
+++ arch/amd64/include/conf.h 11 May 2020 08:39:54 -
@@ -41,7 +41,6 @@ cdev_decl(fd);
cdev_decl(spkr);
-#define biosselect seltrue
cdev_decl(bios);
#definecdev_acpi_init(c,n) {\
@@ -51,7 +50,6 @@ cdev_decl(bios);
(dev_type_mmap((*))) enodev, 0, 0, dev_init(c,n,kqfilter) }
cdev_decl(acpi);
-#define pctrpoll seltrue
cdev_decl(pctr);
#include "vmm.h"
Index: arch/i386/i386/conf.c
===
RCS file: /cvs/src/sys/arch/i386/i386/conf.c,v
retrieving revision 1.167
diff -u -p -r1.167 conf.c
--- arch/i386/i386/conf.c 24 Jan 2020 05:14:51 - 1.167
+++ arch/i386/i386/conf.c 11 May 2020 08:39:54 -
@@ -88,21 +88,21 @@ int nblkdev = nitems(bdevsw);
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
(dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
(dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev }
+(dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
-/* open, close, ioctl, poll -- XXX should be a generic device */
+/* open, close, ioctl, seltrue, seltrue_kqfilter */
#define cdev_ocis_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), (dev_type_read((*))) enodev, \
(dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
-(dev_type_stop((*))) enodev, 0, dev_init(c,n,poll), \
-(dev_type_mmap((*))) enodev, 0 }
+(dev_type_stop((*))) enodev, 0, seltrue, \
+(dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
/* open, close, read */
#define cdev_nvram_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
(dev_type_write((*))) enodev, (dev_type_ioctl((*))) enodev, \
(dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev, 0 }
+(dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
#definemmread mmrw
#definemmwrite mmrw
Index: arch/i386/include/conf.h
===
RCS file: /cvs/src/sys/arch/i386/include/conf.h,v
retrieving revision 1.17
diff -u -p -r1.17 conf.h
--- arch/i386/include/conf.h18 Jan 2019 01:34:50 - 1.17
+++ arch/i386/include/conf.h11 May 2020 08:39:54 -
@@ -65,7 +65,6 @@ cdev_decl(pms);
cdev_decl(joy);
-#define biospoll seltrue
cdev_decl(bios);
cdev_decl(acpi);
@@ -74,5 +73,4 @@ cdev_decl(apm);
minor bgpd cleanup
There is no need to limit the number of chars printed by log_reason().
log_reason() returns a strnvis cleaned buffer and so %s is good enough.
While there wrap a long line.
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.228
diff -u -p -r1.228 bgpd.c
--- bgpd.c 10 May 2020 13:38:46 - 1.228
+++ bgpd.c 11 May 2020 07:58:02 -
@@ -829,10 +829,10 @@ dispatch_imsg(struct imsgbuf *ibuf, int
else {
reconfig = 1;
reconfpid = imsg.hdr.pid;
- if (imsg.hdr.len == IMSG_HEADER_SIZE +
REASON_LEN &&
- ((char *)imsg.data)[0])
- log_info("reload due to: %.*s",
- REASON_LEN, log_reason(imsg.data));
+ if (imsg.hdr.len == IMSG_HEADER_SIZE +
+ REASON_LEN && ((char *)imsg.data)[0])
+ log_info("reload due to: %s",
+ log_reason(imsg.data));
}
break;
case IMSG_CTL_FIB_COUPLE:
paste: treat '\0' delim as empty string
Hi,
This patch makes paste treat '\0' in the delim list as an empty string
instead of a null character as per POSIX[1].
before:
% echo -e 'hello\nworld' | ./paste -s -d '\0' - | od -b
000 150 145 154 154 157 000 167 157 162 154 144 012
014
after:
% echo -e 'hello\nworld' | ./paste -s -d '\0' - | od -b
000 150 145 154 154 157 167 157 162 154 144 012
013
Thanks,
Richard
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/paste.html
diff --git usr.bin/paste/paste.c usr.bin/paste/paste.c
index 77c9f328755..68ed12898a4 100644
--- usr.bin/paste/paste.c
+++ usr.bin/paste/paste.c
@@ -193,7 +193,7 @@ sequential(char **argv)
while ((len = getline(, , fp)) != -1) {
if (line[len - 1] == '\n')
line[len - 1] = '\0';
- if (cnt >= 0)
+ if (cnt >= 0 && delim[cnt] != '\0')
putchar(delim[cnt]);
if (++cnt == delimcnt)
cnt = 0;
update libelf from elftoolchain r3717 to r3833
update libelf from elftoolchain r3717 to r3833
no need for a crank according to src/lib/check_sym
r3833 | jkoshy | 2020-03-02 18:19:04 +1100 (Mon, 02 Mar 2020) | 4 lines
Minor: add comments.
Ticket: [#584]
r3764 | emaste | 2019-06-29 07:44:46 +1000 (Sat, 29 Jun 2019) | 3 lines
libelf: add config for RISC-V ISA
Obtained from FreeBSD r294664 by br.
r3763 | emaste | 2019-06-29 07:43:27 +1000 (Sat, 29 Jun 2019) | 5 lines
libelf: assert that msz is non-zero
Reported by FreeBSD Coverity, CID 976023
Obtained from FreeBSD r316685 by emaste.
r3743 | jkoshy | 2019-06-13 05:36:30 +1000 (Thu, 13 Jun 2019) | 3 lines
Incorporate manual page fixes from OpenBSD.
Submitted by: Sunil Nimmagadda
r3740 | jkoshy | 2019-05-06 15:18:34 +1000 (Mon, 06 May 2019) | 2 lines
Verify that only one of the LIBELF_F_RAWFILE_{MALLOC,MMAP}
flags is set on an ELF descriptor.
r3739 | jkoshy | 2019-05-06 15:18:15 +1000 (Mon, 06 May 2019) | 3 lines
Bug fix: use integer literals of the correct size.
Found by: Coverity Scan
r3738 | jkoshy | 2019-05-06 07:49:06 +1000 (Mon, 06 May 2019) | 3 lines
Improve an internal API: a return type of 'void'
would be a better fit for an internal function that
never returns a usable value.
r3737 | jkoshy | 2019-05-06 00:49:50 +1000 (Mon, 06 May 2019) | 3 lines
Eliminate an always true sub-expression.
Pointed out by: Sunil Nimmagadda
r3736 | jkoshy | 2019-05-05 23:22:07 +1000 (Sun, 05 May 2019) | 3 lines
Add a few assertions.
Submitted by: Sunil Nimmagadda
r3734 | jkoshy | 2019-04-23 00:10:49 +1000 (Tue, 23 Apr 2019) | 2 lines
Document the additional errors possible for the APIs
updated by revision r3732.
r3732 | jkoshy | 2019-04-22 21:08:38 +1000 (Mon, 22 Apr 2019) | 4 lines
Handle error returns from the _libelf_msize() helper
function consistently.
Pointed out by: Sunil Nimmagadda on -developers
Index: _libelf.h
===
RCS file: /cvs/src/lib/libelf/_libelf.h,v
retrieving revision 1.2
diff -u -p -r1.2 _libelf.h
--- _libelf.h 19 Mar 2019 02:31:35 - 1.2
+++ _libelf.h 11 May 2020 06:10:12 -
@@ -226,7 +226,7 @@ size_t _libelf_msize(Elf_Type _t, int _e
void *_libelf_newphdr(Elf *_e, int _elfclass, size_t _count);
Elf*_libelf_open_object(int _fd, Elf_Cmd _c, int _reporterror);
struct _Libelf_Data *_libelf_release_data(struct _Libelf_Data *_d);
-Elf*_libelf_release_elf(Elf *_e);
+void _libelf_release_elf(Elf *_e);
Elf_Scn*_libelf_release_scn(Elf_Scn *_s);
int_libelf_setphnum(Elf *_e, void *_eh, int _elfclass, size_t _phnum);
int_libelf_setshnum(Elf *_e, void *_eh, int _elfclass, size_t _shnum);
Index: _libelf_config.h
===
RCS file: /cvs/src/lib/libelf/_libelf_config.h,v
retrieving revision 1.1
diff -u -p -r1.1 _libelf_config.h
--- _libelf_config.h1 Feb 2019 05:27:37 - 1.1
+++ _libelf_config.h11 May 2020 06:10:12 -
@@ -103,6 +103,12 @@
#defineLIBELF_BYTEORDERELFDATA2LSB
#defineLIBELF_CLASSELFCLASS64
+#elif defined(__riscv64)
+
+#defineLIBELF_ARCH EM_RISCV
+#defineLIBELF_BYTEORDERELFDATA2LSB
+#defineLIBELF_CLASSELFCLASS64
+
#elif defined(__sparc__)
#defineLIBELF_ARCH EM_SPARCV9
Index: elf.3
===
RCS file: /cvs/src/lib/libelf/elf.3,v
retrieving revision 1.4
diff -u -p -r1.4 elf.3
--- elf.3 11 Jun 2019 18:38:46 - 1.4
+++ elf.3 11 May 2020 06:10:12 -
@@ -23,7 +23,7 @@
.\"
.\" $Id: elf.3,v 1.4 2019/06/11 18:38:46 schwarze Exp $
.\"
-.Dd February 5, 2019
+.Dd June 12, 2019
.Dt ELF 3
.Os
.Sh NAME
Index: elf_data.c
===
RCS file: /cvs/src/lib/libelf/elf_data.c,v
retrieving revision 1.2
diff -u -p -r1.2 elf_data.c
--- elf_data.c 19 Mar 2019 02:31:35 - 1.2
+++ elf_data.c 11 May 2020 06:10:12 -
@@ -118,7 +118,8 @@ elf_getdata(Elf_Scn *s,
