Re: makeinfo dumps core
> This works indeed. I'd rather ditch techinfo from base, but i guess > that is not feasible yet. > > So ok? ok tb
Re: makeinfo dumps core
On Sat, May 25, 2019 at 09:53:26PM +0200, Otto Moerbeek wrote:
> On Sat, May 25, 2019 at 10:45:48AM -0500, athom...@athompso.net wrote:
>
> > >Synopsis: makeinfo dumps core on amdref.info when outputting docbook
> > >Category: user
> > >Environment:
> > ***also tested on 6.5-STABLE, same problem occurs there***
> > System : OpenBSD 6.4
> > Details : OpenBSD 6.4 (GENERIC) #6: Sat Jan 26 19:51:53 CET 2019
> >
> > r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > When using makeinfo(1) to convert a Texinfo file to Docbook, instead of
> > performing the conversion, makeinfo dumps core instead.
> > Error shown here with debugger attached:
> >
> > (gdb) run
> > Starting program: /usr/bin/makeinfo -v --force --docbook amdref.texinfo
> > (no debugging symbols found)
> > makeinfo (GNU texinfo) 4.8
> > Making XML file `/home/athompso/amdref.xml' from `amdref.texinfo'.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x10db1bc010eb in cm_no_op () from /usr/bin/makeinfo
> > Current language: auto; currently minimal
> >
> > >How-To-Repeat:
> > Run "makeinfo --docbook" on amdref.texinfo from
> > /usr/src/usr.sbin/amd/doc/amdref.texinfo.
> > Crashes every time, pretty much instantly, leaving amdref.xml as a
> > 0-byte file.
> > >Fix:
> > No known fix.
> >
> >
[dmesg snip]
>
> Try this.
>
> -Otto
This works indeed. I'd rather ditch techinfo from base, but i guess
that is not feasible yet.
So ok?
-Otto
>
> Index: makeinfo/cmds.c
> ===
> RCS file: /cvs/src/gnu/usr.bin/texinfo/makeinfo/cmds.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 cmds.c
> --- makeinfo/cmds.c 17 Jul 2006 16:12:36 - 1.3
> +++ makeinfo/cmds.c 25 May 2019 19:52:47 -
> @@ -624,6 +624,7 @@ cm_comment (void)
>/* Use insert for HTML, and XML when indentation is enabled.
> For Docbook, use add_char. */
>if (xml && xml_indentation_increment > 0
> + && output_paragraph_offset > 0
>&& output_paragraph[output_paragraph_offset-1] != '\n')
> insert ('\n');
>
> Index: makeinfo/xml.c
> ===
> RCS file: /cvs/src/gnu/usr.bin/texinfo/makeinfo/xml.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 xml.c
> --- makeinfo/xml.c8 Oct 2008 07:09:37 - 1.2
> +++ makeinfo/xml.c25 May 2019 19:52:47 -
> @@ -1845,7 +1845,8 @@ xml_begin_index (void)
>if (xml_index_titles)
> {
>/* Remove the final > */
> - output_paragraph_offset--;
> + if (output_paragraph_offset)
> + output_paragraph_offset--;
>/* and put ID="node-name">Title */
>insert_string (xml_index_titles->title);
>free (xml_index_titles->title);
>
Re: update sysupgrade manpage
On Mon, May 27, 2019 at 04:16:01AM +0200, giovani...@tuta.io wrote:
> Hello,
>
> I tried to make sysupgrade man page more readable and fixed a small mistake.
> The man page stated:
>
> > .It Fl s
> > Upgrade to a snapshot.
> > The default is to find out if the system is running a release or a snapshot.
> > In case of release> .Nm
> > downloads the next release.
>
> But if SNAP is set, even in release systems, sysupgrade targets snapshots:
Yes, but the sentence describes the default beahviour as I read it.
Your chanche is equally confusing, imo.
I think it is better to move the description of the default behaviour
to the start and only describe the non-default with the options.
The rest of your changes I'll leave to a native speaker.
-Otto
>
> > if $SNAP; then
> > URL=${MIRROR}/snapshots/${ARCH}/
> > else
> > URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
> > fi
>
> Here is the patch:
>
> Index: usr.sbin/sysupgrade/sysupgrade.8
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
> retrieving revision 1.8
> diff -u -p -u -p -r1.8 sysupgrade.8
> --- usr.sbin/sysupgrade/sysupgrade.8 9 May 2019 21:09:37 - 1.8
> +++ usr.sbin/sysupgrade/sysupgrade.8 27 May 2019 00:07:11 -
> @@ -19,7 +19,7 @@
> .Os
> .Sh NAME
> .Nm sysupgrade
> -.Nd upgrade system to the next release or a new snapshot
> +.Nd upgrade system to the next release or latest snapshot
> .Sh SYNOPSIS
> .Nm
> .Op Fl fkn
> @@ -29,7 +29,7 @@
> .Nm
> is a utility to upgrade
> .Ox
> -to the next release or a new snapshot if available.
> +to the next release or latest snapshot, if available.
> .Pp
> .Nm
> downloads the necessary files to
> @@ -39,8 +39,9 @@ verifies them with
> and copies bsd.rd to
> .Pa /bsd.upgrade .
> .Pp
> +Then, by default,
> .Nm
> -by default then reboots the system.
> +reboots the system.
> The bootloader will automatically choose
> .Pa /bsd.upgrade ,
> triggering a one-shot upgrade using the files in
> @@ -55,23 +56,22 @@ This option has no effect on releases.
> .It Fl k
> Keep the files in
> .Pa /home/_sysupgrade .
> -By default they will be deleted after the upgrade.
> +By default, they are deleted after the upgrade.
> .It Fl n
> -Fetch and verify the files and create
> -.Pa /bsd.upgrade
> -but do not reboot.
> +Do not reboot the system after creating
> +.Pa /bsd.upgrade .
> .It Fl r
> Upgrade to the next release.
> The default is to find out if the system is running a release or a snapshot.
> -In case of release
> +In case of release,
> .Nm
> downloads the next release.
> .It Fl s
> Upgrade to a snapshot.
> The default is to find out if the system is running a release or a snapshot.
> -In case of release
> +In case of release,
> .Nm
> -downloads the next release.
> +downloads the latest snapshot.
> .El
> .Sh FILES
> .Bl -tag -width "/home/_sysupgrade" -compact
>
>
>
update sysupgrade manpage
Hello,
I tried to make sysupgrade man page more readable and fixed a small mistake.
The man page stated:
> .It Fl s
> Upgrade to a snapshot.
> The default is to find out if the system is running a release or a snapshot.
> In case of release> .Nm
> downloads the next release.
But if SNAP is set, even in release systems, sysupgrade targets snapshots:
> if $SNAP; then
> URL=${MIRROR}/snapshots/${ARCH}/
> else
> URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
> fi
Here is the patch:
Index: usr.sbin/sysupgrade/sysupgrade.8
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 sysupgrade.8
--- usr.sbin/sysupgrade/sysupgrade.8 9 May 2019 21:09:37 - 1.8
+++ usr.sbin/sysupgrade/sysupgrade.8 27 May 2019 00:07:11 -
@@ -19,7 +19,7 @@
.Os
.Sh NAME
.Nm sysupgrade
-.Nd upgrade system to the next release or a new snapshot
+.Nd upgrade system to the next release or latest snapshot
.Sh SYNOPSIS
.Nm
.Op Fl fkn
@@ -29,7 +29,7 @@
.Nm
is a utility to upgrade
.Ox
-to the next release or a new snapshot if available.
+to the next release or latest snapshot, if available.
.Pp
.Nm
downloads the necessary files to
@@ -39,8 +39,9 @@ verifies them with
and copies bsd.rd to
.Pa /bsd.upgrade .
.Pp
+Then, by default,
.Nm
-by default then reboots the system.
+reboots the system.
The bootloader will automatically choose
.Pa /bsd.upgrade ,
triggering a one-shot upgrade using the files in
@@ -55,23 +56,22 @@ This option has no effect on releases.
.It Fl k
Keep the files in
.Pa /home/_sysupgrade .
-By default they will be deleted after the upgrade.
+By default, they are deleted after the upgrade.
.It Fl n
-Fetch and verify the files and create
-.Pa /bsd.upgrade
-but do not reboot.
+Do not reboot the system after creating
+.Pa /bsd.upgrade .
.It Fl r
Upgrade to the next release.
The default is to find out if the system is running a release or a snapshot.
-In case of release
+In case of release,
.Nm
downloads the next release.
.It Fl s
Upgrade to a snapshot.
The default is to find out if the system is running a release or a snapshot.
-In case of release
+In case of release,
.Nm
-downloads the next release.
+downloads the latest snapshot.
.El
.Sh FILES
.Bl -tag -width "/home/_sysupgrade" -compact
Re: vmd: tweak mc146818 periodic interrupt updating
On Sun, May 26, 2019 at 08:14:43PM +0200, Jasper Lievisse Adriaanse wrote: > Hi, > > Whilst looking at the mc146818 code in vmd I noticed something that initially > struck > me as a pasto as the same code is present in the rtc_update_regb() function. > However > it led me to look at how other emulators handle the updating of registers. > Based on > that here's a diff to only reschedule the periodic interrupt after updating > register A > if something changed in register A. > > When updating register A we were checking in register B if the > PIE bit was set in order to decide if rtc_reschedule_per needed > to be called. if that bit was changed then the timer rate would > already have been adjusted by rtc_update_regb so the call from > rtc_update_rega is not needed. This now matches what qemu and > other emulators are doing too. > > This has been running fine for a few days in a number of VMs. > > OK? > sure, ok mlarkin > Index: mc146818.c > === > RCS file: /cvs/src/usr.sbin/vmd/mc146818.c,v > retrieving revision 1.18 > diff -u -p -r1.18 mc146818.c > --- mc146818.c12 Jul 2018 10:15:44 - 1.18 > +++ mc146818.c26 May 2019 12:13:32 - > @@ -216,7 +216,7 @@ rtc_update_rega(uint32_t data) > __func__); > > rtc.regs[MC_REGA] = data; > - if (rtc.regs[MC_REGB] & MC_REGB_PIE) > + if ((rtc.regs[MC_REGA] ^ data) & 0x0f) > rtc_reschedule_per(); > } > > > -- > jasper >
vmd: tweak mc146818 periodic interrupt updating
Hi, Whilst looking at the mc146818 code in vmd I noticed something that initially struck me as a pasto as the same code is present in the rtc_update_regb() function. However it led me to look at how other emulators handle the updating of registers. Based on that here's a diff to only reschedule the periodic interrupt after updating register A if something changed in register A. When updating register A we were checking in register B if the PIE bit was set in order to decide if rtc_reschedule_per needed to be called. if that bit was changed then the timer rate would already have been adjusted by rtc_update_regb so the call from rtc_update_rega is not needed. This now matches what qemu and other emulators are doing too. This has been running fine for a few days in a number of VMs. OK? Index: mc146818.c === RCS file: /cvs/src/usr.sbin/vmd/mc146818.c,v retrieving revision 1.18 diff -u -p -r1.18 mc146818.c --- mc146818.c 12 Jul 2018 10:15:44 - 1.18 +++ mc146818.c 26 May 2019 12:13:32 - @@ -216,7 +216,7 @@ rtc_update_rega(uint32_t data) __func__); rtc.regs[MC_REGA] = data; - if (rtc.regs[MC_REGB] & MC_REGB_PIE) + if ((rtc.regs[MC_REGA] ^ data) & 0x0f) rtc_reschedule_per(); } -- jasper
success on 6.5: wscons 'many ttys' patches
[not subscribed, please Cc, thanks] Haai, Just a quick note to whomever may be interested: me 'many ttys' wscons patches still work fine on 6.5, including the ps(1), w(1), and X ones. Patch #3 of the original set has been committed by Otto Moerbeek (thanks!) and thus will no longer need to be applied in the future. Baai, --De Zeurkous. -- Friggin' Machines!
ping: patch: minor comment tyop in xserver
This is still in 6.5. Anyone feel sufficiently bothered to commit this? --zeurkous. > See below. Bit hasty, weren't we? :P > --zeur. > > Index: xenocara/xserver/hw/xfree86/os-support/bsd/bsd_init.c > === > RCS file: /cvs/xenocara/xserver/hw/xfree86/os-support/bsd/bsd_init.c,v > retrieving revision 1.21 > diff -u -p -r1.21 bsd_init.c > --- xenocara/xserver/hw/xfree86/os-support/bsd/bsd_init.c 8 Dec 2017 > 15:02:01 - 1.21 > +++ xenocara/xserver/hw/xfree86/os-support/bsd/bsd_init.c 26 Dec 2018 > 07:47:12 - > @@ -763,7 +763,7 @@ xf86ProcessArgument(int argc, char *argv > } > return 1; > } > -#endif /* SYSCONS_SUPPORT || PCVT_SUPPORT ||WSCONS_SUPPRT */ > +#endif /* SYSCONS_SUPPORT || PCVT_SUPPORT || WSCONS_SUPPORT */ > return 0; > } > -- Friggin' Machines!
Re: remove mention of YP from hosts(5)
On Sun, May 26, 2019 at 03:57:48PM +0200, Jan-Piet Mens wrote: > I noticed hosts(5) still mentions YP in spite of support for the latter > having been removed in [1]. This minuscule patch corrects the man page. > > Index: share/man/man5/hosts.5 > === > RCS file: /cvs/src/share/man/man5/hosts.5,v > retrieving revision 1.24 > diff -u -p -u -r1.24 hosts.5 > --- share/man/man5/hosts.530 Apr 2018 18:01:24 - 1.24 > +++ share/man/man5/hosts.526 May 2019 13:40:20 - > @@ -58,7 +58,6 @@ The system configuration file > controls where host name information will be searched for. > The mechanism provided permits the administrator to describe the > databases to search; the databases currently known include > -.Xr yp 8 , > DNS > and the > .Nm hosts > > > [1] https://marc.info/?l=openbsd-cvs=144830197501354=2 Nice find! ok brynet@
remove mention of YP from hosts(5)
I noticed hosts(5) still mentions YP in spite of support for the latter having been removed in [1]. This minuscule patch corrects the man page. Index: share/man/man5/hosts.5 === RCS file: /cvs/src/share/man/man5/hosts.5,v retrieving revision 1.24 diff -u -p -u -r1.24 hosts.5 --- share/man/man5/hosts.5 30 Apr 2018 18:01:24 - 1.24 +++ share/man/man5/hosts.5 26 May 2019 13:40:20 - @@ -58,7 +58,6 @@ The system configuration file controls where host name information will be searched for. The mechanism provided permits the administrator to describe the databases to search; the databases currently known include -.Xr yp 8 , DNS and the .Nm hosts [1] https://marc.info/?l=openbsd-cvs=144830197501354=2
Re: intro.8: .Xr rcctl 8 -- http://man.openbsd.org/intro.8
Ingo Schwarze: > > Not sure what do about "ELF(3)" in elf(3). > Index: elf.3 > Index: elf_flagdata.3 > Index: elf_open.3 > Index: gelf.3 > Index: gelf_newehdr.3 > Index: gelf_newphdr.3 -snip- OK, but note that there are also three instances of .Xr ELF 3 in elf.3. -- Christian "naddy" Weisgerber na...@mips.inka.de
