On Sun, 31 May 2020, at 21:43, Joerg Jung wrote:
> IMHO this includes keeping Terminus, despite upstream dropped it long
> time ago already. So, I'm not in favor of the proposed patch, but would
> not object, if you insist on moving on this way.
My preference is for a maintained port and a happy maintainer over what
style choices are ultimately chosen. I am happy to let things be.
Sunday, May 31, 2020
Re: suckless font configuration
On Sun, May 31, 2020 at 10:43:20PM +0200, Joerg Jung wrote:
>
>> Am 31.05.2020 um 15:49 schrieb Klemens Nanni <kn@openbsd.org>:
>> Let's do one thing at a time, if others later decide to change colors
>> they can do so, I'd like to fix the fonts due the implied dependencies,
>> all else I'd like to leave the any future porter/MAINTAINER.
>
>This topic comes up every few months for either of the suckless ports,
>see archives. Developers (e.g. tedu and myself), who are actively using
>dwm have stated that they prefer to keep color patches (across suckless
>ports) instead of following the randomly changing upstream colors -
>think of it as principal of least surprise after upgrades.
>
>IMHO this includes keeping Terminus, despite upstream dropped it long
>time ago already. So, I'm not in favor of the proposed patch, but would
>not object, if you insist on moving on this way.
>
>Either way, I can take care of maintaining DWM.
While fixing another font issue (bitmap fonts in gtk vim with new
pango), I figured out how to force a font upon a select program by
fontconfig. This might be used to "configure" suckless ports at least
fontwise.
This is how its done in `~/.fonts.conf`:
```
<fontconfig>
<match>
<test name="prgname">
<string>gvim</string>
</test>
<edit mode="assign" name="family">
<string>Ttyp0</string>
</edit>
<edit mode="assign" name="pixelsize">
<double>15</double>
</edit>
</match>
</fontconfig>
```
I believe there is also a st patch to use X resources for configuration.
Christopher
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
>
>> Am 31.05.2020 um 15:49 schrieb Klemens Nanni <kn@openbsd.org>:
>> Let's do one thing at a time, if others later decide to change colors
>> they can do so, I'd like to fix the fonts due the implied dependencies,
>> all else I'd like to leave the any future porter/MAINTAINER.
>
>This topic comes up every few months for either of the suckless ports,
>see archives. Developers (e.g. tedu and myself), who are actively using
>dwm have stated that they prefer to keep color patches (across suckless
>ports) instead of following the randomly changing upstream colors -
>think of it as principal of least surprise after upgrades.
>
>IMHO this includes keeping Terminus, despite upstream dropped it long
>time ago already. So, I'm not in favor of the proposed patch, but would
>not object, if you insist on moving on this way.
>
>Either way, I can take care of maintaining DWM.
While fixing another font issue (bitmap fonts in gtk vim with new
pango), I figured out how to force a font upon a select program by
fontconfig. This might be used to "configure" suckless ports at least
fontwise.
This is how its done in `~/.fonts.conf`:
```
<fontconfig>
<match>
<test name="prgname">
<string>gvim</string>
</test>
<edit mode="assign" name="family">
<string>Ttyp0</string>
</edit>
<edit mode="assign" name="pixelsize">
<double>15</double>
</edit>
</match>
</fontconfig>
```
I believe there is also a st patch to use X resources for configuration.
Christopher
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
Re: Problem with isc_named
On Sun, May 31, 2020 at 8:45 PM Noth <nothingness@citycable.ch> wrote:
>
> Hi,
>
> Why are you putting the zone files in /var/named/tmp? That's probably
> the source of the problem. Use /var/named/{master,slave} for those...
>
I used to I them in slave, but that failed as well.
--
chs
>
> Hi,
>
> Why are you putting the zone files in /var/named/tmp? That's probably
> the source of the problem. Use /var/named/{master,slave} for those...
>
I used to I them in slave, but that failed as well.
--
chs
[new package] mutt-wizard - automated configuration manager for neomutt
Hi,
This is quite a handy package for autoconfiguration of neomutt
and other utilities. I'm hoping we can get it so that a lot of the
newcomers who want to use neomutt won't be that daunted by the dotfiles.
I've attached the port but upstream doesn't make any tagged releases, so
I've made it using a dated format. I'm not sure what the proper method is
when adding versions to such packages.
PS: upstream calls it mutt-wizard but it needs neomutt as told by upstream.
Aisha
This is quite a handy package for autoconfiguration of neomutt
and other utilities. I'm hoping we can get it so that a lot of the
newcomers who want to use neomutt won't be that daunted by the dotfiles.
I've attached the port but upstream doesn't make any tagged releases, so
I've made it using a dated format. I'm not sure what the proper method is
when adding versions to such packages.
PS: upstream calls it mutt-wizard but it needs neomutt as told by upstream.
Aisha
Re: games/ioquake3 cvs current diffs adding ppc support
> Sent: Sunday, May 31, 2020 at 10:43 AM
> From: "Charlene Wendling" <julianaito@posteo.jp>
> To: "Kirill Bychkov" <kirby@linklevel.net>
> Cc: "Alex Free" <alexjf@mail.com>, "Landry Breuil" <landry@openbsd.org>, ports@openbsd.org, abieber@openbsd.org
> Subject: Re: games/ioquake3 cvs current diffs adding ppc support
>
> Huh, looks my mail never made it to ports@ :D
>
> On Sun, 31 May 2020 09:43:46 +0300
> Kirill Bychkov wrote:
>
> > On Sun, May 31, 2020 02:28, Alex Free wrote:
> > >> Sent: Saturday, May 30, 2020 at 9:45 PM
> > >> From: "Charlene Wendling" <julianaito@posteo.jp>
> > >> To: "Landry Breuil" <landry@openbsd.org>
> > >> Cc: "Alex Free" <alexjf@mail.com>, ports@openbsd.org,
> > >> abieber@openbsd.org Subject: Re: games/ioquake3 cvs current diffs
> > >> adding ppc support
> > >>
> > >> Hi,
> > >>
> > >> On Sat, 30 May 2020 09:36:25 +0200
> > >> Landry Breuil wrote:
> > >>
> > >> > On Sat, May 30, 2020 at 09:09:13AM +0200, Alex Free wrote:
> > >> > > Successfully built and tested against current.
> > >> > >
> > >> > > Let me know if I can do anything else to make this happen.
> > >> > >
> > >> > > A new file named patch-code_qcommon_q_platform_h contains the
> > >> > > following immediately below.
> > >> >
> > >> > note that you can do a cvs add of that new file, and cvs diff
> > >> > will show it.
> > >> >
> > >> > > Below are the CVS diffs.
> > >> >
> > >> > usually, when sending a diff for a port, you to the cvs diff
> > >> > from the port directory, otherwise the person applying it will
> > >> > have to cd to /usr or use patch -p2 in that case.
> > >> >
> > >> > those are not strong remarks, your diff itself is fine, it's just
> > >> > 'best practice to get used to' if you plan to send more diffs
> > >> > (which are always welcome!)
> > >>
> > >> ^ Agreed :)
> > >>
> > >> It builds fine on macppc indeed, there are font glitches, but i
> > >> don't have much time to fiddle with q3config.cfg since i can't
> > >> read options. It requires to disable HDR at least to have proper
> > >> weapons/font textures with my Radeon 9700.
> >
> > Hi,
> > I see weapons, main menu (when option is highlighted) and console on
> > my G5 with Radeon 9600 Pro.
> > ok kirby@
> >
> > >>
> > >> Alex, if you had the issue and know what is needed to make glitches
> > >> disappear, we should add it to pkg/README :)
> > >>
> > >> OK cwen@ either way, here is the diff as we usually expect it by
> > >> the way.
> > >>
> > >> Charl?ne.
> > >>
> > >>
>
> [diff was here]
>
> > > Thank you all for informing me of how to submit things correctly. I
> > > greatly appreciate the correct format for the patches submitted
> > > here.
> > >
> > > As for the font issues, I only have one powerpc machine with
> > > graphics acceleration support in OpenBSD 6.7. Mach64 DRI was
> > > dropped years ago.
> > >
> > > My one machine has a Radeon 9200 32MB graphics card so I had to
> > > change the renderer to opengl1 in q3cfg.cfg using the text below.
> > >
> > > seta cl_renderer "opengl1"
> > >
> > > Also, fullscreen is scaled incorrectly on my card, it is in the
> > > corner of the screen and not completely visible. Windowed mode
> > > works fine, I have it set in q3cfg.cfg using the text below.
> > >
> > > seta r_fullscreen "0"
> > >
> > > As I believe we are using different renderers (9700 supports
> > > OpenGL2.0 AFAIK), maybe the opengl1 renderer will work better? I
> > > haven?t had any font issues on my OpenGL 1.3 card, just the
> > > fullscreen one which I work around by setting xrandr -s 640x480.
> > >
> > > Another thing I think might be important, on my radeon 9200 I have
> > > to use the fastest preset for a playable game. Resolution can be
> > > then be changed.
> > >
> > > Is this good to include in the readme? I can submit a new patch for
> > > an updated readme if that is what should be done next.
>
> I think we should add a subsection that details that. See
> /usr/ports/infrastructure/templates/README.template for the
> format we're using.
>
> It works 100% fine in fullscreen here with the standard configuration
> and:
>
> seta cl_renderer "opengl1"
> seta r_allowExtensions "0"
> seta r_hdr "0"
>
> I can get 40-ish fps with that. The tricky part when setting up
> graphics settings is to remember to use 32-bit depth and textures,
> otherwise it's a complete mess.
>
> I'm replying to your next mail while here:
>
> > Thank you all for testing and helping in the process. What's
> > the next step to get this into ports? Everything works as expected,
> > some graphics cards just need a few tweaks in the config file that
> > should be documented.
>
> Once we have a final diff that everyone agree upon, we've to wait for
> abieber@ that maintains the port to be OK with it/commit it.
>
>
I've created a patch for the readme, does it cover everything you had in mind and is it
done correctly?
Index: games/ioquake3/pkg/README
===================================================================
RCS file: /cvs/ports/games/ioquake3/pkg/README,v
retrieving revision 1.5
diff -u -p -u -r1.5 README
--- games/ioquake3/pkg/README 4 Sep 2018 12:46:13 -0000 1.5
+++ games/ioquake3/pkg/README 1 Jun 2020 03:16:56 -0000
@@ -19,3 +19,30 @@ rcctl enable ioq3ded && rcctl set ioq3de
For more information on the dedicated server see here:
http://wiki.ioquake3.org/Sys_Admin_Guide#Configuration_Files
+
+Macppc specifics
+================
+Additional configuration may be required, as noted below.
+
+OpenGL renderer
+---------------
+The opengl2 renderer is not available on many of the supported graphics cards and will prevent ioquake3 from starting with the default configuration. Specifiying seta cl_renderer "opengl1" in the config file will allow use of
+the opengl1 renderer.
+
+16-bit textures
+---------------
+Graphical issues occur when using 16-bit textures on the Radeon 9200, 9600, and 9700. 32-bit textures should be used if this happens.
+
+Radeon 9700
+-----------
+Weapons and fonts will not appear without specifying seta r_hdr "0" in the config file. The Radeon 9200 and 9600 do not have this issue.
+
+Extensions should also be turned off by specifying seta r_allowExtensions "0" in the config file.
+
+Radeon 9200
+-----------
+Fullscreen requires the X11 resolution to match the one specified in the ioquake3 config file. This has been tested in FVWM and Window Maker, and only Window Maker displays fullscreen correctly out of the 2.
+
+The fastest graphics preset should be used in ioquake3. Resolution can then be modifed from there for a playable game.
+
+The main menu in ioquake3 has poor performance that other parts of the game do not suffer from.
> From: "Charlene Wendling" <julianaito@posteo.jp>
> To: "Kirill Bychkov" <kirby@linklevel.net>
> Cc: "Alex Free" <alexjf@mail.com>, "Landry Breuil" <landry@openbsd.org>, ports@openbsd.org, abieber@openbsd.org
> Subject: Re: games/ioquake3 cvs current diffs adding ppc support
>
> Huh, looks my mail never made it to ports@ :D
>
> On Sun, 31 May 2020 09:43:46 +0300
> Kirill Bychkov wrote:
>
> > On Sun, May 31, 2020 02:28, Alex Free wrote:
> > >> Sent: Saturday, May 30, 2020 at 9:45 PM
> > >> From: "Charlene Wendling" <julianaito@posteo.jp>
> > >> To: "Landry Breuil" <landry@openbsd.org>
> > >> Cc: "Alex Free" <alexjf@mail.com>, ports@openbsd.org,
> > >> abieber@openbsd.org Subject: Re: games/ioquake3 cvs current diffs
> > >> adding ppc support
> > >>
> > >> Hi,
> > >>
> > >> On Sat, 30 May 2020 09:36:25 +0200
> > >> Landry Breuil wrote:
> > >>
> > >> > On Sat, May 30, 2020 at 09:09:13AM +0200, Alex Free wrote:
> > >> > > Successfully built and tested against current.
> > >> > >
> > >> > > Let me know if I can do anything else to make this happen.
> > >> > >
> > >> > > A new file named patch-code_qcommon_q_platform_h contains the
> > >> > > following immediately below.
> > >> >
> > >> > note that you can do a cvs add of that new file, and cvs diff
> > >> > will show it.
> > >> >
> > >> > > Below are the CVS diffs.
> > >> >
> > >> > usually, when sending a diff for a port, you to the cvs diff
> > >> > from the port directory, otherwise the person applying it will
> > >> > have to cd to /usr or use patch -p2 in that case.
> > >> >
> > >> > those are not strong remarks, your diff itself is fine, it's just
> > >> > 'best practice to get used to' if you plan to send more diffs
> > >> > (which are always welcome!)
> > >>
> > >> ^ Agreed :)
> > >>
> > >> It builds fine on macppc indeed, there are font glitches, but i
> > >> don't have much time to fiddle with q3config.cfg since i can't
> > >> read options. It requires to disable HDR at least to have proper
> > >> weapons/font textures with my Radeon 9700.
> >
> > Hi,
> > I see weapons, main menu (when option is highlighted) and console on
> > my G5 with Radeon 9600 Pro.
> > ok kirby@
> >
> > >>
> > >> Alex, if you had the issue and know what is needed to make glitches
> > >> disappear, we should add it to pkg/README :)
> > >>
> > >> OK cwen@ either way, here is the diff as we usually expect it by
> > >> the way.
> > >>
> > >> Charl?ne.
> > >>
> > >>
>
> [diff was here]
>
> > > Thank you all for informing me of how to submit things correctly. I
> > > greatly appreciate the correct format for the patches submitted
> > > here.
> > >
> > > As for the font issues, I only have one powerpc machine with
> > > graphics acceleration support in OpenBSD 6.7. Mach64 DRI was
> > > dropped years ago.
> > >
> > > My one machine has a Radeon 9200 32MB graphics card so I had to
> > > change the renderer to opengl1 in q3cfg.cfg using the text below.
> > >
> > > seta cl_renderer "opengl1"
> > >
> > > Also, fullscreen is scaled incorrectly on my card, it is in the
> > > corner of the screen and not completely visible. Windowed mode
> > > works fine, I have it set in q3cfg.cfg using the text below.
> > >
> > > seta r_fullscreen "0"
> > >
> > > As I believe we are using different renderers (9700 supports
> > > OpenGL2.0 AFAIK), maybe the opengl1 renderer will work better? I
> > > haven?t had any font issues on my OpenGL 1.3 card, just the
> > > fullscreen one which I work around by setting xrandr -s 640x480.
> > >
> > > Another thing I think might be important, on my radeon 9200 I have
> > > to use the fastest preset for a playable game. Resolution can be
> > > then be changed.
> > >
> > > Is this good to include in the readme? I can submit a new patch for
> > > an updated readme if that is what should be done next.
>
> I think we should add a subsection that details that. See
> /usr/ports/infrastructure/templates/README.template for the
> format we're using.
>
> It works 100% fine in fullscreen here with the standard configuration
> and:
>
> seta cl_renderer "opengl1"
> seta r_allowExtensions "0"
> seta r_hdr "0"
>
> I can get 40-ish fps with that. The tricky part when setting up
> graphics settings is to remember to use 32-bit depth and textures,
> otherwise it's a complete mess.
>
> I'm replying to your next mail while here:
>
> > Thank you all for testing and helping in the process. What's
> > the next step to get this into ports? Everything works as expected,
> > some graphics cards just need a few tweaks in the config file that
> > should be documented.
>
> Once we have a final diff that everyone agree upon, we've to wait for
> abieber@ that maintains the port to be OK with it/commit it.
>
>
I've created a patch for the readme, does it cover everything you had in mind and is it
done correctly?
Index: games/ioquake3/pkg/README
===================================================================
RCS file: /cvs/ports/games/ioquake3/pkg/README,v
retrieving revision 1.5
diff -u -p -u -r1.5 README
--- games/ioquake3/pkg/README 4 Sep 2018 12:46:13 -0000 1.5
+++ games/ioquake3/pkg/README 1 Jun 2020 03:16:56 -0000
@@ -19,3 +19,30 @@ rcctl enable ioq3ded && rcctl set ioq3de
For more information on the dedicated server see here:
http://wiki.ioquake3.org/Sys_Admin_Guide#Configuration_Files
+
+Macppc specifics
+================
+Additional configuration may be required, as noted below.
+
+OpenGL renderer
+---------------
+The opengl2 renderer is not available on many of the supported graphics cards and will prevent ioquake3 from starting with the default configuration. Specifiying seta cl_renderer "opengl1" in the config file will allow use of
+the opengl1 renderer.
+
+16-bit textures
+---------------
+Graphical issues occur when using 16-bit textures on the Radeon 9200, 9600, and 9700. 32-bit textures should be used if this happens.
+
+Radeon 9700
+-----------
+Weapons and fonts will not appear without specifying seta r_hdr "0" in the config file. The Radeon 9200 and 9600 do not have this issue.
+
+Extensions should also be turned off by specifying seta r_allowExtensions "0" in the config file.
+
+Radeon 9200
+-----------
+Fullscreen requires the X11 resolution to match the one specified in the ioquake3 config file. This has been tested in FVWM and Window Maker, and only Window Maker displays fullscreen correctly out of the 2.
+
+The fastest graphics preset should be used in ioquake3. Resolution can then be modifed from there for a playable game.
+
+The main menu in ioquake3 has poor performance that other parts of the game do not suffer from.
Re: purritobin-0.1.2 - new package + dependencies
Hi,
I've attached the port again, with a few more fixes.
Would love to see this added.
A few words about this port:
It is a minimalistic pastebin client which allows you to also
paste encrypted texts and has a simple javascript decryptor frontend.
It is asynchronous and allows you to limit the paste size and a
location where the pastes are stored.
It uses unveil and pledge to make sure that only the necessary
folders and permissions are used.
Really hope this can be added and would love to get any advice about
how to improve this port :)
Aisha
I've attached the port again, with a few more fixes.
Would love to see this added.
A few words about this port:
It is a minimalistic pastebin client which allows you to also
paste encrypted texts and has a simple javascript decryptor frontend.
It is asynchronous and allows you to limit the paste size and a
location where the pastes are stored.
It uses unveil and pledge to make sure that only the necessary
folders and permissions are used.
Really hope this can be added and would love to get any advice about
how to improve this port :)
Aisha
Re: [update] devel/libtermkey
On Sun, May 31, 2020 at 10:12:47PM +0100, Edd Barrett wrote:
> Hi Matthew,
>
> On Sun, May 31, 2020 at 11:11:59AM -0500, Matthew Martin wrote:
> > ping
>
> This and you unibilium diff look fine to me. One small comment below
> (applicable to both).
>
> > > No change in symbols and the diff doesn't seem to touch any public
> > > functions. Only bumped minor because upstream did.
>
> ^ Sounds like it may not strictly be necessary ABI-wise, but I'd be
> tempted to leave your bump in anyway.
>
> Did you check the public types as well as the functions?
unibilium.h and termkey.h are unchanged in the updates save for a bump
to TERMKEY_VERSION_MINOR in the latter.
> Hi Matthew,
>
> On Sun, May 31, 2020 at 11:11:59AM -0500, Matthew Martin wrote:
> > ping
>
> This and you unibilium diff look fine to me. One small comment below
> (applicable to both).
>
> > > No change in symbols and the diff doesn't seem to touch any public
> > > functions. Only bumped minor because upstream did.
>
> ^ Sounds like it may not strictly be necessary ABI-wise, but I'd be
> tempted to leave your bump in anyway.
>
> Did you check the public types as well as the functions?
unibilium.h and termkey.h are unchanged in the updates save for a bump
to TERMKEY_VERSION_MINOR in the latter.
6.7 trouble reaching ipmi on supermicro atom
ipmitool is timing out on my system with the kernel driver loaded, where I havent seen this in previous releases.
I looked at the changes in 6.7 for ipmi.c, there's a number of them (thank you!) My intention is to bisect for which change may have caused this, but if someone knows what's going on, I'm all ears.
This behavior has happened on two systems that I've tried so far:
cobalt# ipmitool sel
Unable to send command: Device busy
Get Device ID command failed
No data available
Unable to send command: Device busy
No valid response received
No data available
Get SEL Info command failed
I loaded ipmi in this kernel as I have in previous releases, seems to be present:
cobalt# echo find ipmi | config -e -o /bsd.test /bsd
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
root@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Enter 'help' for information
ukc> find ipmi
447 ipmi0 at acpi0 flags 0x0
448 ipmi0 at mainbus0 apid -1 flags 0x0
ukc> config: eof
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
root@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277665792 (4079MB)
avail mem = 4135411712 (3943MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9ac00 (19 entries)
bios0: vendor American Megatrends Inc. version "1.2b" date 07/19/13
bios0: Supermicro X7SPA-HF
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.91 MHz, 06-1c-0a
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.68 MHz, 06-1c-0a
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec00000, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpipci0 at acpi0 PCI0: 0x00000010 0x00000011 0x00000000
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 19
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 3 int 16, address 00:1b:21:88:9f:20
em1 at pci1 dev 0 function 1 "Intel 82571EB" rev 0x06: apic 3 int 17, address 00:1b:21:88:9f:21
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em2 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:25:90:0a:40:72
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
em3 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:25:90:0a:40:73
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 23
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 19
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci4 at ppb3 bus 4
vga1 at pci4 dev 4 function 0 "Matrox MGA G200eW" rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel 82801IR LPC" rev 0x02
pciide0 at pci0 dev 31 function 2 "Intel 82801I SATA" rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using apic 3 int 19 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: <INTEL SSDSC2BB120G4>
wd0: 1-sector PIO, LBA48, 114473MB, 234441648 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 3 int 18
iic0 at ichiic0
iic0: skipping sensors to avoid ipmi0 interactions
spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
spdmem1 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
pciide1 at pci0 dev 31 function 5 "Intel 82801I SATA" rev 0x02: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide1: using apic 3 int 19 for native-PCI interrupt
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb7 at uhci5: USB revision 1.0
uhub7 at usb7 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25
uhidev0 at uhub4 port 2 configuration 1 interface 0 "Winbond Electronics Corp Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub4 port 2 configuration 1 interface 1 "Winbond Electronics Corp Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (d19a675ad2509822.a) swap on wd0b dump on wd0b
I looked at the changes in 6.7 for ipmi.c, there's a number of them (thank you!) My intention is to bisect for which change may have caused this, but if someone knows what's going on, I'm all ears.
This behavior has happened on two systems that I've tried so far:
cobalt# ipmitool sel
Unable to send command: Device busy
Get Device ID command failed
No data available
Unable to send command: Device busy
No valid response received
No data available
Get SEL Info command failed
I loaded ipmi in this kernel as I have in previous releases, seems to be present:
cobalt# echo find ipmi | config -e -o /bsd.test /bsd
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
root@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Enter 'help' for information
ukc> find ipmi
447 ipmi0 at acpi0 flags 0x0
448 ipmi0 at mainbus0 apid -1 flags 0x0
ukc> config: eof
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
root@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277665792 (4079MB)
avail mem = 4135411712 (3943MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9ac00 (19 entries)
bios0: vendor American Megatrends Inc. version "1.2b" date 07/19/13
bios0: Supermicro X7SPA-HF
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.91 MHz, 06-1c-0a
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.68 MHz, 06-1c-0a
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec00000, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpipci0 at acpi0 PCI0: 0x00000010 0x00000011 0x00000000
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 19
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 3 int 16, address 00:1b:21:88:9f:20
em1 at pci1 dev 0 function 1 "Intel 82571EB" rev 0x06: apic 3 int 17, address 00:1b:21:88:9f:21
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em2 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:25:90:0a:40:72
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
em3 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:25:90:0a:40:73
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 23
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 19
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci4 at ppb3 bus 4
vga1 at pci4 dev 4 function 0 "Matrox MGA G200eW" rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel 82801IR LPC" rev 0x02
pciide0 at pci0 dev 31 function 2 "Intel 82801I SATA" rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using apic 3 int 19 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: <INTEL SSDSC2BB120G4>
wd0: 1-sector PIO, LBA48, 114473MB, 234441648 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 3 int 18
iic0 at ichiic0
iic0: skipping sensors to avoid ipmi0 interactions
spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
spdmem1 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
pciide1 at pci0 dev 31 function 5 "Intel 82801I SATA" rev 0x02: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide1: using apic 3 int 19 for native-PCI interrupt
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb7 at uhci5: USB revision 1.0
uhub7 at usb7 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25
uhidev0 at uhub4 port 2 configuration 1 interface 0 "Winbond Electronics Corp Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub4 port 2 configuration 1 interface 1 "Winbond Electronics Corp Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (d19a675ad2509822.a) swap on wd0b dump on wd0b
sysupgrade with sysmerge failure
Hi.
I just used the new 'sysupgrade' to upgrade my little Alix boxes to 6.7. It worked very well, and thank you for this upgrade simplification tool.
I do have one question. After upgrading the first machine, when I ran syspatch to patch the system, I got a failure saying that the user _rpki_client didn't exist. My question is not about that, but I realized that the sysmerge script apparently did not finish successfully. I ran it and merged the files and then was able to proceed normally. On another box, this time I was watching for it (I have a little terminal server on the alix machines), and indeed:
---- /etc/mail/smtpd.conf unhandled, re-run sysmerge to merge the new version
My question is, is there a "standard" place/way to confirm that sysmerge finished successfully (other than looking at the console output on first boot)? For some reason (I don't know if I'm editing in a way that sysmerge doesn't like to merge) this seems to happen a lot with unbound.conf, nsd.conf and smtpd.conf (for example), so I run into sysmerge conflicts often.
Sean
I just used the new 'sysupgrade' to upgrade my little Alix boxes to 6.7. It worked very well, and thank you for this upgrade simplification tool.
I do have one question. After upgrading the first machine, when I ran syspatch to patch the system, I got a failure saying that the user _rpki_client didn't exist. My question is not about that, but I realized that the sysmerge script apparently did not finish successfully. I ran it and merged the files and then was able to proceed normally. On another box, this time I was watching for it (I have a little terminal server on the alix machines), and indeed:
---- /etc/mail/smtpd.conf unhandled, re-run sysmerge to merge the new version
My question is, is there a "standard" place/way to confirm that sysmerge finished successfully (other than looking at the console output on first boot)? For some reason (I don't know if I'm editing in a way that sysmerge doesn't like to merge) this seems to happen a lot with unbound.conf, nsd.conf and smtpd.conf (for example), so I run into sysmerge conflicts often.
Sean
Re: sndio: troubleshooting no input
No, it was set to 0. I set it to 1 and that fixed the issue.
Thanks!
Also, Maurice mentioned "sndioctl -d" so here is the output:
073:input[0].level=0..255 (120)074:input[1].level=0..255
(120)105:input[0].mute=0..1 (0)106:input[1].mute=0..1
(0)009:output[0].level=0..255 (126)010:output[1].level=0..255
(126)041:output[0].mute=0..1 (0)042:output[1].mute=0..1
(0)001:mpv0.level=0..127 (127)000:test0.level=0..127 (127)
--Aaron
On Sun, 2020-05-31 at 18:29 +0200, Jan Stary wrote:
> Do you have sysctl kern.audio.record=1 ?
> Jan
> On May 30 18:17:02, aaron@iforgotmy.name wrote:
> > Hello,
> > I have an amd64 laptop with OpenBSD 6.7 and I am only
> > gettingzero-valued samples when recording. Is there any
> > checklist I cango through to ensure nothing is muted and that
> > I am reading fromthe correct input device?
> > I have tried both aucat and a C program I wrote (attached).
> > Thanks,Aaron Miller
> > #include <stdio.h>#include <sndio.h>#include
> > <stdlib.h>#include <errno.h>
> > #define BUF_SAMPLES 4800#define OUTFILE "recorded.pcm"#define
> > ITERATIONS 500
> > // ffmpeg -y -f s16le -ar 48000 -ac 1 -i recorded.pcm
> > recorded.mp3 && mpv recorded.mp3
> > void print_par(struct sio_par *par);
> > int main(int argc, char* argv[]) { short *sample_buf =
> > NULL; struct sio_hdl *h; int fail = 0; int started =
> > 0; size_t total_bytes_read = 0; int i; size_t
> > bytes_read; FILE *out = NULL; h = sio_open(SIO_DEVANY,
> > SIO_REC, 0); if (h == NULL) { fprintf(stderr, "%s:
> > we're fucked man\n", argv[0]); fail = 1; goto
> > done; }
> > struct sio_par par; sio_initpar(&par);
> > par.bits = 8*sizeof(short); //par.bps =
> > sizeof(short); par.sig = 1; par.le = 1; par.rchan =
> > 1; par.pchan = 2; // unused par.rate =
> > 48000; par.xrun = SIO_IGNORE;
> > //print_par(&par); printf("running
> > sio_setpar...\n"); if (sio_setpar(h, &par) == 0)
> > { fprintf(stderr, "%s: sio_setpar failed\n",
> > argv[0]); fail = 1; goto
> > done; }; //print_par(&par);
> > printf("running sio_getpar...\n"); if (sio_getpar(h,
> > &par) == 0) { fprintf(stderr, "%s: sio_getpar
> > failed\n", argv[0]); fail = 1; goto
> > done; }; print_par(&par);
> > if (BUF_SAMPLES % par.round != 0) { fprintf(stderr,
> > "%s: samples in buf (%d) not mult of round (%d)\n", argv[0],
> > BUF_SAMPLES, par.round); fail = 1; goto done; }
> > if ((sample_buf = malloc(BUF_SAMPLES * sizeof(short))) ==
> > NULL) { fprintf(stderr, "%s: oh we are sooo fucked.
> > GAME OVER MAN\n", argv[0]); fail = 1; goto done; }
> > if ((out = fopen(OUTFILE, "wb")) == NULL)
> > { fprintf(stderr, "%s: failed to open %s for
> > writing\n", argv[0], OUTFILE); fail = 1; goto
> > done; }
> > if (sio_start(h) == 0) { fprintf(stderr, "%s:
> > failed to sio_start\n", argv[0]); fail = 1; goto
> > done; } started = 1; int retries =
> > 0; printf("START\n"); for (i = 0; i < ITERATIONS; i++)
> > { if ((bytes_read = sio_read(h, sample_buf, BUF_SAMPLES
> > * sizeof(short))) == 0) { fprintf(stderr, "%s:
> > failed to sio_read\n", argv[0]); fail = 1; goto
> > done; } total_bytes_read += bytes_read;
> > size_t bytes_written; size_t bw; char*
> > buf_ptr = (char *) sample_buf; for (bytes_written = 0;
> > bytes_written < bytes_read; bytes_written += bw)
> > { size_t bytes_left = bytes_read -
> > bytes_written; bw = fwrite(buf_ptr, 1, bytes_left,
> > out); if (bw < bytes_left && errno != EAGAIN)
> > { fprintf(stderr, "%s: failed to write to
> > file\n",
> > argv[0]); perror(argv[0]); fail
> > = 1; goto done; } buf_ptr +=
> > bw; } } printf("TOTAL BYTES READ: %d\n",
> > total_bytes_read);
> > // cleanupdone: if (started)
> > { sio_stop(h); } if (out != NULL)
> > { fclose(out); } if (sample_buf != NULL)
> > { free(sample_buf); } if (h != NULL)
> > { sio_close(h); } return fail;}
> > void print_par(struct sio_par *par) { char *xrun; switch
> > (par->xrun) { default: xrun = "<unknown xrun
> > val>"; break; case 0: xrun =
> > "SIO_IGNORE"; break; case 1: xrun
> > = "SIO_SYNC"; break; case 2: xrun
> > =
> > "SIO_ERROR"; break; } printf("&sio_par{\n"
> > " bits: %d,\n" " bps:
> > %d,\n" " sig: %d,\n" " le:
> > %d,\n" " msb: %d,\n" " rchan:
> > %d,\n" " pchan: %d,\n" " rate:
> > %d,\n" " appbufsz: %d,\n" " bufsz:
> > %d,\n" " round: %d,\n" " xrun: %s
> > (%d),\n" "}\n", par->bits, /* bits
> > per sample */ par->bps, /* bytes per sample
> > */ par->sig, /* 1 = signed, 0 = unsigned int
> > */ par->le, /* 1 = LE, 0 = BE byte order
> > */ par->msb, /* 1 = MSB, 0 = LSB aligned
> > */ par->rchan, /* number channels for recording
> > */ par->pchan, /* number channels for playback
> > */ par->rate, /* frames per second
> > */ par->appbufsz, /* minimum buffer size without
> > xruns */ par->bufsz, /* end-to-end buffer size
> > (read-only) */ par->round, /* optimal buffer
> > size divisor */ xrun, /* what to do on
> > overrun/underrun */ par->xrun );}
Thanks!
Also, Maurice mentioned "sndioctl -d" so here is the output:
073:input[0].level=0..255 (120)074:input[1].level=0..255
(120)105:input[0].mute=0..1 (0)106:input[1].mute=0..1
(0)009:output[0].level=0..255 (126)010:output[1].level=0..255
(126)041:output[0].mute=0..1 (0)042:output[1].mute=0..1
(0)001:mpv0.level=0..127 (127)000:test0.level=0..127 (127)
--Aaron
On Sun, 2020-05-31 at 18:29 +0200, Jan Stary wrote:
> Do you have sysctl kern.audio.record=1 ?
> Jan
> On May 30 18:17:02, aaron@iforgotmy.name wrote:
> > Hello,
> > I have an amd64 laptop with OpenBSD 6.7 and I am only
> > gettingzero-valued samples when recording. Is there any
> > checklist I cango through to ensure nothing is muted and that
> > I am reading fromthe correct input device?
> > I have tried both aucat and a C program I wrote (attached).
> > Thanks,Aaron Miller
> > #include <stdio.h>#include <sndio.h>#include
> > <stdlib.h>#include <errno.h>
> > #define BUF_SAMPLES 4800#define OUTFILE "recorded.pcm"#define
> > ITERATIONS 500
> > // ffmpeg -y -f s16le -ar 48000 -ac 1 -i recorded.pcm
> > recorded.mp3 && mpv recorded.mp3
> > void print_par(struct sio_par *par);
> > int main(int argc, char* argv[]) { short *sample_buf =
> > NULL; struct sio_hdl *h; int fail = 0; int started =
> > 0; size_t total_bytes_read = 0; int i; size_t
> > bytes_read; FILE *out = NULL; h = sio_open(SIO_DEVANY,
> > SIO_REC, 0); if (h == NULL) { fprintf(stderr, "%s:
> > we're fucked man\n", argv[0]); fail = 1; goto
> > done; }
> > struct sio_par par; sio_initpar(&par);
> > par.bits = 8*sizeof(short); //par.bps =
> > sizeof(short); par.sig = 1; par.le = 1; par.rchan =
> > 1; par.pchan = 2; // unused par.rate =
> > 48000; par.xrun = SIO_IGNORE;
> > //print_par(&par); printf("running
> > sio_setpar...\n"); if (sio_setpar(h, &par) == 0)
> > { fprintf(stderr, "%s: sio_setpar failed\n",
> > argv[0]); fail = 1; goto
> > done; }; //print_par(&par);
> > printf("running sio_getpar...\n"); if (sio_getpar(h,
> > &par) == 0) { fprintf(stderr, "%s: sio_getpar
> > failed\n", argv[0]); fail = 1; goto
> > done; }; print_par(&par);
> > if (BUF_SAMPLES % par.round != 0) { fprintf(stderr,
> > "%s: samples in buf (%d) not mult of round (%d)\n", argv[0],
> > BUF_SAMPLES, par.round); fail = 1; goto done; }
> > if ((sample_buf = malloc(BUF_SAMPLES * sizeof(short))) ==
> > NULL) { fprintf(stderr, "%s: oh we are sooo fucked.
> > GAME OVER MAN\n", argv[0]); fail = 1; goto done; }
> > if ((out = fopen(OUTFILE, "wb")) == NULL)
> > { fprintf(stderr, "%s: failed to open %s for
> > writing\n", argv[0], OUTFILE); fail = 1; goto
> > done; }
> > if (sio_start(h) == 0) { fprintf(stderr, "%s:
> > failed to sio_start\n", argv[0]); fail = 1; goto
> > done; } started = 1; int retries =
> > 0; printf("START\n"); for (i = 0; i < ITERATIONS; i++)
> > { if ((bytes_read = sio_read(h, sample_buf, BUF_SAMPLES
> > * sizeof(short))) == 0) { fprintf(stderr, "%s:
> > failed to sio_read\n", argv[0]); fail = 1; goto
> > done; } total_bytes_read += bytes_read;
> > size_t bytes_written; size_t bw; char*
> > buf_ptr = (char *) sample_buf; for (bytes_written = 0;
> > bytes_written < bytes_read; bytes_written += bw)
> > { size_t bytes_left = bytes_read -
> > bytes_written; bw = fwrite(buf_ptr, 1, bytes_left,
> > out); if (bw < bytes_left && errno != EAGAIN)
> > { fprintf(stderr, "%s: failed to write to
> > file\n",
> > argv[0]); perror(argv[0]); fail
> > = 1; goto done; } buf_ptr +=
> > bw; } } printf("TOTAL BYTES READ: %d\n",
> > total_bytes_read);
> > // cleanupdone: if (started)
> > { sio_stop(h); } if (out != NULL)
> > { fclose(out); } if (sample_buf != NULL)
> > { free(sample_buf); } if (h != NULL)
> > { sio_close(h); } return fail;}
> > void print_par(struct sio_par *par) { char *xrun; switch
> > (par->xrun) { default: xrun = "<unknown xrun
> > val>"; break; case 0: xrun =
> > "SIO_IGNORE"; break; case 1: xrun
> > = "SIO_SYNC"; break; case 2: xrun
> > =
> > "SIO_ERROR"; break; } printf("&sio_par{\n"
> > " bits: %d,\n" " bps:
> > %d,\n" " sig: %d,\n" " le:
> > %d,\n" " msb: %d,\n" " rchan:
> > %d,\n" " pchan: %d,\n" " rate:
> > %d,\n" " appbufsz: %d,\n" " bufsz:
> > %d,\n" " round: %d,\n" " xrun: %s
> > (%d),\n" "}\n", par->bits, /* bits
> > per sample */ par->bps, /* bytes per sample
> > */ par->sig, /* 1 = signed, 0 = unsigned int
> > */ par->le, /* 1 = LE, 0 = BE byte order
> > */ par->msb, /* 1 = MSB, 0 = LSB aligned
> > */ par->rchan, /* number channels for recording
> > */ par->pchan, /* number channels for playback
> > */ par->rate, /* frames per second
> > */ par->appbufsz, /* minimum buffer size without
> > xruns */ par->bufsz, /* end-to-end buffer size
> > (read-only) */ par->round, /* optimal buffer
> > size divisor */ xrun, /* what to do on
> > overrun/underrun */ par->xrun );}
Re: RENAME: math/ebc => math/bc-gh
On Sat, May 30 2020, Brian Callahan <bcallah@protonmail.com> wrote:
> Hi ports --
>
> As begun here [0], I think it makes sense to rename our ebc package to
> bc-gh. The attached new port does exactly that (and updates to the
> latest version of bc-gh at the same time).
>
> Also attached is a quirks entry. Will of course remove math/ebc and
> update math/Makefile as appropriate.
>
> OK?
Unless I'm missing something @conflict isn't needed, I suggest to drop
it. ok jca@
I'd also suggest to use bsd.port.arch.mk and ${PROPERTIES:Mlp64} instead
of hardcoding a list of 64 bits architectures.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
> Hi ports --
>
> As begun here [0], I think it makes sense to rename our ebc package to
> bc-gh. The attached new port does exactly that (and updates to the
> latest version of bc-gh at the same time).
>
> Also attached is a quirks entry. Will of course remove math/ebc and
> update math/Makefile as appropriate.
>
> OK?
Unless I'm missing something @conflict isn't needed, I suggest to drop
it. ok jca@
I'd also suggest to use bsd.port.arch.mk and ${PROPERTIES:Mlp64} instead
of hardcoding a list of 64 bits architectures.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: macbook only sees 1GB of a 2GB RAM module
On Sat, May 30, 2020 at 07:23:58PM +0200, Jan Stary wrote:
> This is current/amd64 on a macbook2,1 (dmesg below).
> It has two RAM slots, each holding a 2GB module:
if you like using older Apple HW then
https://everymac.com/
is a very good resource. searching Macbook2,1 reveals the HW issue.
this specific limitation
https://everymac.com/systems/apple/macbook_pro/faq/macbook-pro-core-2-duo-3-gb-memory-limitation-details.html
>
> spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
> spdmem1 at iic0 addr 0x52: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
>
> But of one of the 2GB, only 1GB is seen:
>
> real mem = 3171909632 (3024MB)
>
> I have tried swapping the mdules, it only happens
> in one of the two slots. If I put a 1GB module in there,
> the available memory is the same (in the other slot,
> 2GB is 2GB and 1GB is 1GB).
>
> Why is this? Does it have anthing to do with
> the memory map conflicts I see in the dmesg?
>
~rgc
> This is current/amd64 on a macbook2,1 (dmesg below).
> It has two RAM slots, each holding a 2GB module:
if you like using older Apple HW then
https://everymac.com/
is a very good resource. searching Macbook2,1 reveals the HW issue.
this specific limitation
https://everymac.com/systems/apple/macbook_pro/faq/macbook-pro-core-2-duo-3-gb-memory-limitation-details.html
>
> spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
> spdmem1 at iic0 addr 0x52: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
>
> But of one of the 2GB, only 1GB is seen:
>
> real mem = 3171909632 (3024MB)
>
> I have tried swapping the mdules, it only happens
> in one of the two slots. If I put a 1GB module in there,
> the available memory is the same (in the other slot,
> 2GB is 2GB and 1GB is 1GB).
>
> Why is this? Does it have anthing to do with
> the memory map conflicts I see in the dmesg?
>
~rgc
Re: [update] devel/libtermkey
Hi Matthew,
On Sun, May 31, 2020 at 11:11:59AM -0500, Matthew Martin wrote:
> ping
This and you unibilium diff look fine to me. One small comment below
(applicable to both).
> > No change in symbols and the diff doesn't seem to touch any public
> > functions. Only bumped minor because upstream did.
^ Sounds like it may not strictly be necessary ABI-wise, but I'd be
tempted to leave your bump in anyway.
Did you check the public types as well as the functions?
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
On Sun, May 31, 2020 at 11:11:59AM -0500, Matthew Martin wrote:
> ping
This and you unibilium diff look fine to me. One small comment below
(applicable to both).
> > No change in symbols and the diff doesn't seem to touch any public
> > functions. Only bumped minor because upstream did.
^ Sounds like it may not strictly be necessary ABI-wise, but I'd be
tempted to leave your bump in anyway.
Did you check the public types as well as the functions?
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: x11/dmenu: drop fonts/terminus-font from RUN_DEPENDS
On Sun, May 31, 2020 at 10:43:20PM +0200, Joerg Jung wrote:
> This topic comes up every few months for either of the suckless ports,
> see archives. Developers (e.g. tedu and myself), who are actively using
> dwm have stated that they prefer to keep color patches (across suckless
> ports) instead of following the randomly changing upstream colors -
> think of it as principal of least surprise after upgrades.
>
> IMHO this includes keeping Terminus, despite upstream dropped it long
> time ago already. So, I'm not in favor of the proposed patch, but would
> not object, if you insist on moving on this way.
>
> Either way, I can take care of maintaining DWM.
Feel free to go ahead, apparently there are enough people that care more
about dwm and dmenu than I do, so I have no further intentions to
discuss these ports any further.
> This topic comes up every few months for either of the suckless ports,
> see archives. Developers (e.g. tedu and myself), who are actively using
> dwm have stated that they prefer to keep color patches (across suckless
> ports) instead of following the randomly changing upstream colors -
> think of it as principal of least surprise after upgrades.
>
> IMHO this includes keeping Terminus, despite upstream dropped it long
> time ago already. So, I'm not in favor of the proposed patch, but would
> not object, if you insist on moving on this way.
>
> Either way, I can take care of maintaining DWM.
Feel free to go ahead, apparently there are enough people that care more
about dwm and dmenu than I do, so I have no further intentions to
discuss these ports any further.
Re: x11/dmenu: drop fonts/terminus-font from RUN_DEPENDS
> Am 31.05.2020 um 15:49 schrieb Klemens Nanni <kn@openbsd.org>:
> On Sun, May 31, 2020 at 01:39:30PM +0000, Lucas wrote:
>> FTR, I originally removed the patch for config.def.h completely in
>> dmenu as I didn't see much point in introducing a patch just for
>> changing some colors, which can be changed with parameters and seem
>> quite randomly chosen (they don't match CSS for OpenBSD site, which I
>> think is the only official thing that can be considered as some sort of
>> colorscheme).
> Let's do one thing at a time, if others later decide to change colors
> they can do so, I'd like to fix the fonts due the implied dependencies,
> all else I'd like to leave the any future porter/MAINTAINER.
This topic comes up every few months for either of the suckless ports,
see archives. Developers (e.g. tedu and myself), who are actively using
dwm have stated that they prefer to keep color patches (across suckless
ports) instead of following the randomly changing upstream colors -
think of it as principal of least surprise after upgrades.
IMHO this includes keeping Terminus, despite upstream dropped it long
time ago already. So, I'm not in favor of the proposed patch, but would
not object, if you insist on moving on this way.
Either way, I can take care of maintaining DWM.
Thanks,
Regards,
Joerg (jung@)
> On Sun, May 31, 2020 at 01:39:30PM +0000, Lucas wrote:
>> FTR, I originally removed the patch for config.def.h completely in
>> dmenu as I didn't see much point in introducing a patch just for
>> changing some colors, which can be changed with parameters and seem
>> quite randomly chosen (they don't match CSS for OpenBSD site, which I
>> think is the only official thing that can be considered as some sort of
>> colorscheme).
> Let's do one thing at a time, if others later decide to change colors
> they can do so, I'd like to fix the fonts due the implied dependencies,
> all else I'd like to leave the any future porter/MAINTAINER.
This topic comes up every few months for either of the suckless ports,
see archives. Developers (e.g. tedu and myself), who are actively using
dwm have stated that they prefer to keep color patches (across suckless
ports) instead of following the randomly changing upstream colors -
think of it as principal of least surprise after upgrades.
IMHO this includes keeping Terminus, despite upstream dropped it long
time ago already. So, I'm not in favor of the proposed patch, but would
not object, if you insist on moving on this way.
Either way, I can take care of maintaining DWM.
Thanks,
Regards,
Joerg (jung@)
Re: NEW: devel/py-patiencediff
On Sun, 31 May 2020 20:25:30 +0100
Stuart Henderson <stu@spacehopper.org> wrote:
> On 2020/05/31 00:33, Juan Francisco Cantero Hurtado wrote:
> > This package is a dependency of another new package. OK?
> >
> > ----
> > Information for inst:py3-patiencediff-0.1.0
> >
> > Comment:
> > python implementation of the patiencediff algorithm
>
> capital 'P' for Python please, and I think this would be better in
> textproc/ (like gdiff) rather than devel/.
>
> otherwise OK.
>
> > - A C implementation implementation (_patiencediff_c.c); this
> > implementation is faster, but requires a C compiler and is less
> > readable
>
> A bunch of tests are skipped, running with 'make MODPY_PYTEST_ARGS="-v
> patiencediff" test' shows the details and it turns out these are the
> tests for the C version. Could you either add
>
> MODPY_TEST_DIR = ${WRKSRC}/lib*
>
> or fix it another way please?
Committed with all your suggestions. Thanks for the help.
>
>
> $ make MODPY_PYTEST_ARGS="-v patiencediff" test
> ===> Regression tests for py3-patiencediff-0.1.0
> ============================= test session starts
> ============================== platform openbsd6 -- Python 3.7.7,
> pytest-4.4.0, py-1.8.0, pluggy-0.11.0 -- /usr/local/bin/python3.7
> cachedir: .pytest_cache hypothesis profile 'default' ->
> database=DirectoryBasedExampleDatabase('/usr/obj/ports/py-patiencediff-0.1.0-python3/patiencediff-0.1.0/.hypothesis/examples')
> rootdir:
> /usr/obj/ports/py-patiencediff-0.1.0-python3/patiencediff-0.1.0
> plugins: hypothesis-4.15.0 collecting ... collected 26 items
>
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_diff_unicode_string
> PASSED [ 3%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_grouped_opcodes
> PASSED [ 7%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_matching_blocks
> PASSED [ 11%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_matching_blocks_tuples
> PASSED [ 15%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_multiple_ranges
> PASSED [ 19%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_opcodes
> PASSED [ 23%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_patience_unified_diff
> PASSED [ 26%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_patience_unified_diff_with_dates
> PASSED [ 30%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_recurse_matches
> PASSED [ 34%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_unique_lcs
> PASSED [ 38%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_diff_unicode_string
> SKIPPED [ 42%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_grouped_opcodes
> SKIPPED [ 46%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_matching_blocks
> SKIPPED [ 50%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_matching_blocks_tuples
> SKIPPED [ 53%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_multiple_ranges
> SKIPPED [ 57%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_opcodes
> SKIPPED [ 61%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_patience_unified_diff
> SKIPPED [ 65%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_patience_unified_diff_with_dates
> SKIPPED [ 69%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_recurse_matches
> SKIPPED [ 73%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_unhashable
> SKIPPED [ 76%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_unique_lcs
> SKIPPED [ 80%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLibFiles::test_patience_unified_diff_files
> PASSED [ 84%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLibFiles_c::test_patience_unified_diff_files
> SKIPPED [ 88%]
> patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_PatienceSequenceMatcher
> PASSED [ 92%]
> patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_recurse_matches
> PASSED [ 96%]
> patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_unique_lcs
> PASSED [100%]
>
> ==================== 14 passed, 12 skipped in 0.15 seconds
> =====================
>
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Stuart Henderson <stu@spacehopper.org> wrote:
> On 2020/05/31 00:33, Juan Francisco Cantero Hurtado wrote:
> > This package is a dependency of another new package. OK?
> >
> > ----
> > Information for inst:py3-patiencediff-0.1.0
> >
> > Comment:
> > python implementation of the patiencediff algorithm
>
> capital 'P' for Python please, and I think this would be better in
> textproc/ (like gdiff) rather than devel/.
>
> otherwise OK.
>
> > - A C implementation implementation (_patiencediff_c.c); this
> > implementation is faster, but requires a C compiler and is less
> > readable
>
> A bunch of tests are skipped, running with 'make MODPY_PYTEST_ARGS="-v
> patiencediff" test' shows the details and it turns out these are the
> tests for the C version. Could you either add
>
> MODPY_TEST_DIR = ${WRKSRC}/lib*
>
> or fix it another way please?
Committed with all your suggestions. Thanks for the help.
>
>
> $ make MODPY_PYTEST_ARGS="-v patiencediff" test
> ===> Regression tests for py3-patiencediff-0.1.0
> ============================= test session starts
> ============================== platform openbsd6 -- Python 3.7.7,
> pytest-4.4.0, py-1.8.0, pluggy-0.11.0 -- /usr/local/bin/python3.7
> cachedir: .pytest_cache hypothesis profile 'default' ->
> database=DirectoryBasedExampleDatabase('/usr/obj/ports/py-patiencediff-0.1.0-python3/patiencediff-0.1.0/.hypothesis/examples')
> rootdir:
> /usr/obj/ports/py-patiencediff-0.1.0-python3/patiencediff-0.1.0
> plugins: hypothesis-4.15.0 collecting ... collected 26 items
>
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_diff_unicode_string
> PASSED [ 3%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_grouped_opcodes
> PASSED [ 7%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_matching_blocks
> PASSED [ 11%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_matching_blocks_tuples
> PASSED [ 15%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_multiple_ranges
> PASSED [ 19%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_opcodes
> PASSED [ 23%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_patience_unified_diff
> PASSED [ 26%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_patience_unified_diff_with_dates
> PASSED [ 30%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_recurse_matches
> PASSED [ 34%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_unique_lcs
> PASSED [ 38%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_diff_unicode_string
> SKIPPED [ 42%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_grouped_opcodes
> SKIPPED [ 46%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_matching_blocks
> SKIPPED [ 50%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_matching_blocks_tuples
> SKIPPED [ 53%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_multiple_ranges
> SKIPPED [ 57%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_opcodes
> SKIPPED [ 61%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_patience_unified_diff
> SKIPPED [ 65%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_patience_unified_diff_with_dates
> SKIPPED [ 69%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_recurse_matches
> SKIPPED [ 73%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_unhashable
> SKIPPED [ 76%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_unique_lcs
> SKIPPED [ 80%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLibFiles::test_patience_unified_diff_files
> PASSED [ 84%]
> patiencediff/test_patiencediff.py::TestPatienceDiffLibFiles_c::test_patience_unified_diff_files
> SKIPPED [ 88%]
> patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_PatienceSequenceMatcher
> PASSED [ 92%]
> patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_recurse_matches
> PASSED [ 96%]
> patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_unique_lcs
> PASSED [100%]
>
> ==================== 14 passed, 12 skipped in 0.15 seconds
> =====================
>
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: NEW: devel/py-patiencediff
On 2020/05/31 00:33, Juan Francisco Cantero Hurtado wrote:
> This package is a dependency of another new package. OK?
>
> ----
> Information for inst:py3-patiencediff-0.1.0
>
> Comment:
> python implementation of the patiencediff algorithm
capital 'P' for Python please, and I think this would be better in
textproc/ (like gdiff) rather than devel/.
otherwise OK.
> - A C implementation implementation (_patiencediff_c.c); this implementation is
> faster, but requires a C compiler and is less readable
A bunch of tests are skipped, running with 'make MODPY_PYTEST_ARGS="-v
patiencediff" test' shows the details and it turns out these are the
tests for the C version. Could you either add
MODPY_TEST_DIR = ${WRKSRC}/lib*
or fix it another way please?
$ make MODPY_PYTEST_ARGS="-v patiencediff" test
===> Regression tests for py3-patiencediff-0.1.0
============================= test session starts ==============================
platform openbsd6 -- Python 3.7.7, pytest-4.4.0, py-1.8.0, pluggy-0.11.0 -- /usr/local/bin/python3.7
cachedir: .pytest_cache
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/usr/obj/ports/py-patiencediff-0.1.0-python3/patiencediff-0.1.0/.hypothesis/examples')
rootdir: /usr/obj/ports/py-patiencediff-0.1.0-python3/patiencediff-0.1.0
plugins: hypothesis-4.15.0
collecting ... collected 26 items
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_diff_unicode_string PASSED [ 3%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_grouped_opcodes PASSED [ 7%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_matching_blocks PASSED [ 11%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_matching_blocks_tuples PASSED [ 15%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_multiple_ranges PASSED [ 19%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_opcodes PASSED [ 23%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_patience_unified_diff PASSED [ 26%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_patience_unified_diff_with_dates PASSED [ 30%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_recurse_matches PASSED [ 34%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_unique_lcs PASSED [ 38%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_diff_unicode_string SKIPPED [ 42%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_grouped_opcodes SKIPPED [ 46%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_matching_blocks SKIPPED [ 50%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_matching_blocks_tuples SKIPPED [ 53%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_multiple_ranges SKIPPED [ 57%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_opcodes SKIPPED [ 61%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_patience_unified_diff SKIPPED [ 65%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_patience_unified_diff_with_dates SKIPPED [ 69%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_recurse_matches SKIPPED [ 73%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_unhashable SKIPPED [ 76%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_unique_lcs SKIPPED [ 80%]
patiencediff/test_patiencediff.py::TestPatienceDiffLibFiles::test_patience_unified_diff_files PASSED [ 84%]
patiencediff/test_patiencediff.py::TestPatienceDiffLibFiles_c::test_patience_unified_diff_files SKIPPED [ 88%]
patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_PatienceSequenceMatcher PASSED [ 92%]
patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_recurse_matches PASSED [ 96%]
patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_unique_lcs PASSED [100%]
==================== 14 passed, 12 skipped in 0.15 seconds =====================
> This package is a dependency of another new package. OK?
>
> ----
> Information for inst:py3-patiencediff-0.1.0
>
> Comment:
> python implementation of the patiencediff algorithm
capital 'P' for Python please, and I think this would be better in
textproc/ (like gdiff) rather than devel/.
otherwise OK.
> - A C implementation implementation (_patiencediff_c.c); this implementation is
> faster, but requires a C compiler and is less readable
A bunch of tests are skipped, running with 'make MODPY_PYTEST_ARGS="-v
patiencediff" test' shows the details and it turns out these are the
tests for the C version. Could you either add
MODPY_TEST_DIR = ${WRKSRC}/lib*
or fix it another way please?
$ make MODPY_PYTEST_ARGS="-v patiencediff" test
===> Regression tests for py3-patiencediff-0.1.0
============================= test session starts ==============================
platform openbsd6 -- Python 3.7.7, pytest-4.4.0, py-1.8.0, pluggy-0.11.0 -- /usr/local/bin/python3.7
cachedir: .pytest_cache
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/usr/obj/ports/py-patiencediff-0.1.0-python3/patiencediff-0.1.0/.hypothesis/examples')
rootdir: /usr/obj/ports/py-patiencediff-0.1.0-python3/patiencediff-0.1.0
plugins: hypothesis-4.15.0
collecting ... collected 26 items
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_diff_unicode_string PASSED [ 3%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_grouped_opcodes PASSED [ 7%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_matching_blocks PASSED [ 11%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_matching_blocks_tuples PASSED [ 15%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_multiple_ranges PASSED [ 19%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_opcodes PASSED [ 23%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_patience_unified_diff PASSED [ 26%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_patience_unified_diff_with_dates PASSED [ 30%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_recurse_matches PASSED [ 34%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib::test_unique_lcs PASSED [ 38%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_diff_unicode_string SKIPPED [ 42%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_grouped_opcodes SKIPPED [ 46%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_matching_blocks SKIPPED [ 50%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_matching_blocks_tuples SKIPPED [ 53%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_multiple_ranges SKIPPED [ 57%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_opcodes SKIPPED [ 61%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_patience_unified_diff SKIPPED [ 65%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_patience_unified_diff_with_dates SKIPPED [ 69%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_recurse_matches SKIPPED [ 73%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_unhashable SKIPPED [ 76%]
patiencediff/test_patiencediff.py::TestPatienceDiffLib_c::test_unique_lcs SKIPPED [ 80%]
patiencediff/test_patiencediff.py::TestPatienceDiffLibFiles::test_patience_unified_diff_files PASSED [ 84%]
patiencediff/test_patiencediff.py::TestPatienceDiffLibFiles_c::test_patience_unified_diff_files SKIPPED [ 88%]
patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_PatienceSequenceMatcher PASSED [ 92%]
patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_recurse_matches PASSED [ 96%]
patiencediff/test_patiencediff.py::TestUsingCompiledIfAvailable::test_unique_lcs PASSED [100%]
==================== 14 passed, 12 skipped in 0.15 seconds =====================
Re: Problem with isc_named
After upgrade to 6.7 I had to change all of isc_named's file statements to have a / before their path. Fwiw, I don't see this in the Changelog, nor does sysmerge handle this, so I'm guessing this is some sort of new bug.
Before 6.7, this always worked:
file "master/loopw.com"
after, I have to do this:
file "/master/loopw.com"
where it's actually /var/named/master/loopw.com on the filesystem.
so outside of that problem, my two cents: I wouldn't put my zone files in tmp, I put those in file /var/named/secondary
> On May 31, 2020, at 11:00 AM, Christer Solskogen <christer.solskogen@gmail.com> wrote:
>
> Hi!
>
> With current (OpenBSD 6.7-current (GENERIC.MP) #232: Sat May 30 18:17:19
> MDT 2020) and up-to-date packages, I'm having a hard time running isc_named
> as a slave dns.
>
> I get this in the log:
> dumping master file: tmp/tmp-lxMn2v1tJx: open: file not found
>
> named.conf is like this:
> options {
> directory "/tmp"; // working directory, inside the /var/named
> chroot
> // - must be writable by _bind
> version ""; // remove this to allow version queries
>
> listen-on { any; };
> listen-on-v6 { any; };
>
> empty-zones-enable yes;
>
> allow-recursion { clients; };
> };
>
> zone "0.168.192.in-addr.arpa" {
> type slave;
> masterfile-format text;
> file "tmp/0.168.192.in-addr.arpa";
> masters { 192.168.0.4; };
> };
>
> zone "antarctica.no" {
> type slave;
> masterfile-format text;
> file "tmp/antarctica.no";
> masters { 192.168.0.4; };
> };
>
> zone "carebears.no" {
> type slave;
> masterfile-format text;
> file "tmp/carebears.no";
> masters { 192.168.0.4; };
> };
>
>
> /var/named/tmp is owned by _bind:_bind with drwxrwxr-x
>
> I can't seem to find any error in my config. Could there be something wrong
> with the package?
> isc-bind-9.16.3p0v0 is the one I have installed.
Before 6.7, this always worked:
file "master/loopw.com"
after, I have to do this:
file "/master/loopw.com"
where it's actually /var/named/master/loopw.com on the filesystem.
so outside of that problem, my two cents: I wouldn't put my zone files in tmp, I put those in file /var/named/secondary
> On May 31, 2020, at 11:00 AM, Christer Solskogen <christer.solskogen@gmail.com> wrote:
>
> Hi!
>
> With current (OpenBSD 6.7-current (GENERIC.MP) #232: Sat May 30 18:17:19
> MDT 2020) and up-to-date packages, I'm having a hard time running isc_named
> as a slave dns.
>
> I get this in the log:
> dumping master file: tmp/tmp-lxMn2v1tJx: open: file not found
>
> named.conf is like this:
> options {
> directory "/tmp"; // working directory, inside the /var/named
> chroot
> // - must be writable by _bind
> version ""; // remove this to allow version queries
>
> listen-on { any; };
> listen-on-v6 { any; };
>
> empty-zones-enable yes;
>
> allow-recursion { clients; };
> };
>
> zone "0.168.192.in-addr.arpa" {
> type slave;
> masterfile-format text;
> file "tmp/0.168.192.in-addr.arpa";
> masters { 192.168.0.4; };
> };
>
> zone "antarctica.no" {
> type slave;
> masterfile-format text;
> file "tmp/antarctica.no";
> masters { 192.168.0.4; };
> };
>
> zone "carebears.no" {
> type slave;
> masterfile-format text;
> file "tmp/carebears.no";
> masters { 192.168.0.4; };
> };
>
>
> /var/named/tmp is owned by _bind:_bind with drwxrwxr-x
>
> I can't seem to find any error in my config. Could there be something wrong
> with the package?
> isc-bind-9.16.3p0v0 is the one I have installed.
Re: OK to GC net/hpodder?
Hi,
On Sun, May 24, 2020 at 03:17:55PM -0700, Greg Steuck wrote:
[...]
> sqlite> select fullpkgpath from ports where build_depends like
> '%hs-HDBC-sqlite3%';
> net/hpodder
[...]
and hs-HDBC, too, which is only used by hs-HDBC-sqlite3
Ciao,
Kili
On Sun, May 24, 2020 at 03:17:55PM -0700, Greg Steuck wrote:
[...]
> sqlite> select fullpkgpath from ports where build_depends like
> '%hs-HDBC-sqlite3%';
> net/hpodder
[...]
and hs-HDBC, too, which is only used by hs-HDBC-sqlite3
Ciao,
Kili
Re: Problem with isc_named
On 31/05/2020 20:00, Christer Solskogen wrote:
> Hi!
>
> With current (OpenBSD 6.7-current (GENERIC.MP) #232: Sat May 30 18:17:19
> MDT 2020) and up-to-date packages, I'm having a hard time running isc_named
> as a slave dns.
>
> I get this in the log:
> dumping master file: tmp/tmp-lxMn2v1tJx: open: file not found
>
> named.conf is like this:
> options {
> directory "/tmp"; // working directory, inside the /var/named
> chroot
> // - must be writable by _bind
> version ""; // remove this to allow version queries
>
> listen-on { any; };
> listen-on-v6 { any; };
>
> empty-zones-enable yes;
>
> allow-recursion { clients; };
> };
>
> zone "0.168.192.in-addr.arpa" {
> type slave;
> masterfile-format text;
> file "tmp/0.168.192.in-addr.arpa";
> masters { 192.168.0.4; };
> };
>
> zone "antarctica.no" {
> type slave;
> masterfile-format text;
> file "tmp/antarctica.no";
> masters { 192.168.0.4; };
> };
>
> zone "carebears.no" {
> type slave;
> masterfile-format text;
> file "tmp/carebears.no";
> masters { 192.168.0.4; };
> };
>
>
> /var/named/tmp is owned by _bind:_bind with drwxrwxr-x
>
> I can't seem to find any error in my config. Could there be something wrong
> with the package?
> isc-bind-9.16.3p0v0 is the one I have installed.
Hi,
Why are you putting the zone files in /var/named/tmp? That's probably
the source of the problem. Use /var/named/{master,slave} for those...
Cheers,
Noth
> Hi!
>
> With current (OpenBSD 6.7-current (GENERIC.MP) #232: Sat May 30 18:17:19
> MDT 2020) and up-to-date packages, I'm having a hard time running isc_named
> as a slave dns.
>
> I get this in the log:
> dumping master file: tmp/tmp-lxMn2v1tJx: open: file not found
>
> named.conf is like this:
> options {
> directory "/tmp"; // working directory, inside the /var/named
> chroot
> // - must be writable by _bind
> version ""; // remove this to allow version queries
>
> listen-on { any; };
> listen-on-v6 { any; };
>
> empty-zones-enable yes;
>
> allow-recursion { clients; };
> };
>
> zone "0.168.192.in-addr.arpa" {
> type slave;
> masterfile-format text;
> file "tmp/0.168.192.in-addr.arpa";
> masters { 192.168.0.4; };
> };
>
> zone "antarctica.no" {
> type slave;
> masterfile-format text;
> file "tmp/antarctica.no";
> masters { 192.168.0.4; };
> };
>
> zone "carebears.no" {
> type slave;
> masterfile-format text;
> file "tmp/carebears.no";
> masters { 192.168.0.4; };
> };
>
>
> /var/named/tmp is owned by _bind:_bind with drwxrwxr-x
>
> I can't seem to find any error in my config. Could there be something wrong
> with the package?
> isc-bind-9.16.3p0v0 is the one I have installed.
Hi,
Why are you putting the zone files in /var/named/tmp? That's probably
the source of the problem. Use /var/named/{master,slave} for those...
Cheers,
Noth
Re: Forgetting pkg_add -u after sysupgrade can cause ansible msyscall errors
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.
> 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: Fix GNU patch CVE-2018-1000156
On Sun, May 31, 2020 at 01:40:17AM +0000, Brian Callahan wrote:
> Hi ports --
>
> repology.org has a new feature where it tracks the CVEs against its
> database of software. I decided to check it out to see if any of my
> ports were vulnerable. I discovered that our GNU patch is vulnerable
> to CVE-2018-1000156. It has been fixed upstream but no new release
> has been made including the fix. So I cherry-picked it for our
> package.
>
> Upstream does have a test with it, but adding the test to the build
> would bring in a dependency on autotools, so I left it out but I did
> confirm that the test passes on amd64 and sparc64.
>
> Tested on amd64 and sparc64. Additionally, on amd64 I built
> everything that depends on gpatch. Libreoffice is still building;
> will report back if it fails to build.
Looks good. Perhaps you want to indicate that the first hunk fixes
something else?
Note that upstream added a few fixes for this patch on top of this patch
(e.g., fwrite return value checks and cleanup for the tempfile on error)
You might want to pull those in as well - your call.
ok tb
as it is.
> Should this be backported to -stable?
If you want to do the work, sure. I don't think it's that big a deal if
you don't. Note though that it is used as a BDEP for a handful of ports.
> Hi ports --
>
> repology.org has a new feature where it tracks the CVEs against its
> database of software. I decided to check it out to see if any of my
> ports were vulnerable. I discovered that our GNU patch is vulnerable
> to CVE-2018-1000156. It has been fixed upstream but no new release
> has been made including the fix. So I cherry-picked it for our
> package.
>
> Upstream does have a test with it, but adding the test to the build
> would bring in a dependency on autotools, so I left it out but I did
> confirm that the test passes on amd64 and sparc64.
>
> Tested on amd64 and sparc64. Additionally, on amd64 I built
> everything that depends on gpatch. Libreoffice is still building;
> will report back if it fails to build.
Looks good. Perhaps you want to indicate that the first hunk fixes
something else?
Note that upstream added a few fixes for this patch on top of this patch
(e.g., fwrite return value checks and cleanup for the tempfile on error)
You might want to pull those in as well - your call.
ok tb
as it is.
> Should this be backported to -stable?
If you want to do the work, sure. I don't think it's that big a deal if
you don't. Note though that it is used as a BDEP for a handful of ports.
Forgetting pkg_add -u after sysupgrade can cause ansible msyscall errors
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.
Regards,
Jurjen Oskam
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.
Regards,
Jurjen Oskam
Problem with isc_named
Hi!
With current (OpenBSD 6.7-current (GENERIC.MP) #232: Sat May 30 18:17:19
MDT 2020) and up-to-date packages, I'm having a hard time running isc_named
as a slave dns.
I get this in the log:
dumping master file: tmp/tmp-lxMn2v1tJx: open: file not found
named.conf is like this:
options {
directory "/tmp"; // working directory, inside the /var/named
chroot
// - must be writable by _bind
version ""; // remove this to allow version queries
listen-on { any; };
listen-on-v6 { any; };
empty-zones-enable yes;
allow-recursion { clients; };
};
zone "0.168.192.in-addr.arpa" {
type slave;
masterfile-format text;
file "tmp/0.168.192.in-addr.arpa";
masters { 192.168.0.4; };
};
zone "antarctica.no" {
type slave;
masterfile-format text;
file "tmp/antarctica.no";
masters { 192.168.0.4; };
};
zone "carebears.no" {
type slave;
masterfile-format text;
file "tmp/carebears.no";
masters { 192.168.0.4; };
};
/var/named/tmp is owned by _bind:_bind with drwxrwxr-x
I can't seem to find any error in my config. Could there be something wrong
with the package?
isc-bind-9.16.3p0v0 is the one I have installed.
With current (OpenBSD 6.7-current (GENERIC.MP) #232: Sat May 30 18:17:19
MDT 2020) and up-to-date packages, I'm having a hard time running isc_named
as a slave dns.
I get this in the log:
dumping master file: tmp/tmp-lxMn2v1tJx: open: file not found
named.conf is like this:
options {
directory "/tmp"; // working directory, inside the /var/named
chroot
// - must be writable by _bind
version ""; // remove this to allow version queries
listen-on { any; };
listen-on-v6 { any; };
empty-zones-enable yes;
allow-recursion { clients; };
};
zone "0.168.192.in-addr.arpa" {
type slave;
masterfile-format text;
file "tmp/0.168.192.in-addr.arpa";
masters { 192.168.0.4; };
};
zone "antarctica.no" {
type slave;
masterfile-format text;
file "tmp/antarctica.no";
masters { 192.168.0.4; };
};
zone "carebears.no" {
type slave;
masterfile-format text;
file "tmp/carebears.no";
masters { 192.168.0.4; };
};
/var/named/tmp is owned by _bind:_bind with drwxrwxr-x
I can't seem to find any error in my config. Could there be something wrong
with the package?
isc-bind-9.16.3p0v0 is the one I have installed.
New: devel/libtickit
libtermkey is deprecated for new applications in favor of libtickit;
however, currently nothing in the ports tree will use it. I'm using
libtickit for a personal project, but can maintain it in my tree until
neovim or another port uses it.
This library provides an abstracted mechanism for building interactive
full-screen terminal programs. It provides a full set of output drawing
functions, and handles keyboard and mouse input events.
however, currently nothing in the ports tree will use it. I'm using
libtickit for a personal project, but can maintain it in my tree until
neovim or another port uses it.
This library provides an abstracted mechanism for building interactive
full-screen terminal programs. It provides a full set of output drawing
functions, and handles keyboard and mouse input events.
Re: sndio: troubleshooting no input
Do you have sysctl kern.audio.record=1 ?
Jan
On May 30 18:17:02, aaron@iforgotmy.name wrote:
> Hello,
>
> I have an amd64 laptop with OpenBSD 6.7 and I am only getting
> zero-valued samples when recording. Is there any checklist I can
> go through to ensure nothing is muted and that I am reading from
> the correct input device?
>
> I have tried both aucat and a C program I wrote (attached).
>
> Thanks,
> Aaron Miller
> #include <stdio.h>
> #include <sndio.h>
> #include <stdlib.h>
> #include <errno.h>
>
> #define BUF_SAMPLES 4800
> #define OUTFILE "recorded.pcm"
> #define ITERATIONS 500
>
> // ffmpeg -y -f s16le -ar 48000 -ac 1 -i recorded.pcm recorded.mp3 && mpv recorded.mp3
>
> void print_par(struct sio_par *par);
>
> int main(int argc, char* argv[]) {
> short *sample_buf = NULL;
> struct sio_hdl *h;
> int fail = 0;
> int started = 0;
> size_t total_bytes_read = 0;
> int i;
> size_t bytes_read;
> FILE *out = NULL;
> h = sio_open(SIO_DEVANY, SIO_REC, 0);
> if (h == NULL) {
> fprintf(stderr, "%s: we're fucked man\n", argv[0]);
> fail = 1; goto done;
> }
>
> struct sio_par par;
> sio_initpar(&par);
>
> par.bits = 8*sizeof(short);
> //par.bps = sizeof(short);
> par.sig = 1;
> par.le = 1;
> par.rchan = 1;
> par.pchan = 2; // unused
> par.rate = 48000;
> par.xrun = SIO_IGNORE;
>
> //print_par(&par);
> printf("running sio_setpar...\n");
> if (sio_setpar(h, &par) == 0) {
> fprintf(stderr, "%s: sio_setpar failed\n", argv[0]);
> fail = 1; goto done;
> };
> //print_par(&par);
>
> printf("running sio_getpar...\n");
> if (sio_getpar(h, &par) == 0) {
> fprintf(stderr, "%s: sio_getpar failed\n", argv[0]);
> fail = 1; goto done;
> };
> print_par(&par);
>
> if (BUF_SAMPLES % par.round != 0) {
> fprintf(stderr, "%s: samples in buf (%d) not mult of round (%d)\n", argv[0], BUF_SAMPLES, par.round);
> fail = 1; goto done;
> }
>
> if ((sample_buf = malloc(BUF_SAMPLES * sizeof(short))) == NULL) {
> fprintf(stderr, "%s: oh we are sooo fucked. GAME OVER MAN\n", argv[0]);
> fail = 1; goto done;
> }
>
> if ((out = fopen(OUTFILE, "wb")) == NULL) {
> fprintf(stderr, "%s: failed to open %s for writing\n", argv[0], OUTFILE);
> fail = 1; goto done;
> }
>
> if (sio_start(h) == 0) {
> fprintf(stderr, "%s: failed to sio_start\n", argv[0]);
> fail = 1; goto done;
> }
> started = 1;
> int retries = 0;
> printf("START\n");
> for (i = 0; i < ITERATIONS; i++) {
> if ((bytes_read = sio_read(h, sample_buf, BUF_SAMPLES * sizeof(short))) == 0) {
> fprintf(stderr, "%s: failed to sio_read\n", argv[0]);
> fail = 1; goto done;
> }
> total_bytes_read += bytes_read;
>
> size_t bytes_written;
> size_t bw;
> char* buf_ptr = (char *) sample_buf;
> for (bytes_written = 0; bytes_written < bytes_read; bytes_written += bw) {
> size_t bytes_left = bytes_read - bytes_written;
> bw = fwrite(buf_ptr, 1, bytes_left, out);
> if (bw < bytes_left && errno != EAGAIN) {
> fprintf(stderr, "%s: failed to write to file\n", argv[0]);
> perror(argv[0]);
> fail = 1; goto done;
> }
> buf_ptr += bw;
> }
> }
> printf("TOTAL BYTES READ: %d\n", total_bytes_read);
>
> // cleanup
> done:
> if (started) {
> sio_stop(h);
> }
> if (out != NULL) {
> fclose(out);
> }
> if (sample_buf != NULL) {
> free(sample_buf);
> }
> if (h != NULL) {
> sio_close(h);
> }
> return fail;
> }
>
> void print_par(struct sio_par *par) {
> char *xrun;
> switch (par->xrun) {
> default:
> xrun = "<unknown xrun val>";
> break;
> case 0:
> xrun = "SIO_IGNORE";
> break;
> case 1:
> xrun = "SIO_SYNC";
> break;
> case 2:
> xrun = "SIO_ERROR";
> break;
> }
> printf("&sio_par{\n"
> " bits: %d,\n"
> " bps: %d,\n"
> " sig: %d,\n"
> " le: %d,\n"
> " msb: %d,\n"
> " rchan: %d,\n"
> " pchan: %d,\n"
> " rate: %d,\n"
> " appbufsz: %d,\n"
> " bufsz: %d,\n"
> " round: %d,\n"
> " xrun: %s (%d),\n"
> "}\n",
> par->bits, /* bits per sample */
> par->bps, /* bytes per sample */
> par->sig, /* 1 = signed, 0 = unsigned int */
> par->le, /* 1 = LE, 0 = BE byte order */
> par->msb, /* 1 = MSB, 0 = LSB aligned */
> par->rchan, /* number channels for recording */
> par->pchan, /* number channels for playback */
> par->rate, /* frames per second */
> par->appbufsz, /* minimum buffer size without xruns */
> par->bufsz, /* end-to-end buffer size (read-only) */
> par->round, /* optimal buffer size divisor */
> xrun, /* what to do on overrun/underrun */
> par->xrun
> );
> }
Jan
On May 30 18:17:02, aaron@iforgotmy.name wrote:
> Hello,
>
> I have an amd64 laptop with OpenBSD 6.7 and I am only getting
> zero-valued samples when recording. Is there any checklist I can
> go through to ensure nothing is muted and that I am reading from
> the correct input device?
>
> I have tried both aucat and a C program I wrote (attached).
>
> Thanks,
> Aaron Miller
> #include <stdio.h>
> #include <sndio.h>
> #include <stdlib.h>
> #include <errno.h>
>
> #define BUF_SAMPLES 4800
> #define OUTFILE "recorded.pcm"
> #define ITERATIONS 500
>
> // ffmpeg -y -f s16le -ar 48000 -ac 1 -i recorded.pcm recorded.mp3 && mpv recorded.mp3
>
> void print_par(struct sio_par *par);
>
> int main(int argc, char* argv[]) {
> short *sample_buf = NULL;
> struct sio_hdl *h;
> int fail = 0;
> int started = 0;
> size_t total_bytes_read = 0;
> int i;
> size_t bytes_read;
> FILE *out = NULL;
> h = sio_open(SIO_DEVANY, SIO_REC, 0);
> if (h == NULL) {
> fprintf(stderr, "%s: we're fucked man\n", argv[0]);
> fail = 1; goto done;
> }
>
> struct sio_par par;
> sio_initpar(&par);
>
> par.bits = 8*sizeof(short);
> //par.bps = sizeof(short);
> par.sig = 1;
> par.le = 1;
> par.rchan = 1;
> par.pchan = 2; // unused
> par.rate = 48000;
> par.xrun = SIO_IGNORE;
>
> //print_par(&par);
> printf("running sio_setpar...\n");
> if (sio_setpar(h, &par) == 0) {
> fprintf(stderr, "%s: sio_setpar failed\n", argv[0]);
> fail = 1; goto done;
> };
> //print_par(&par);
>
> printf("running sio_getpar...\n");
> if (sio_getpar(h, &par) == 0) {
> fprintf(stderr, "%s: sio_getpar failed\n", argv[0]);
> fail = 1; goto done;
> };
> print_par(&par);
>
> if (BUF_SAMPLES % par.round != 0) {
> fprintf(stderr, "%s: samples in buf (%d) not mult of round (%d)\n", argv[0], BUF_SAMPLES, par.round);
> fail = 1; goto done;
> }
>
> if ((sample_buf = malloc(BUF_SAMPLES * sizeof(short))) == NULL) {
> fprintf(stderr, "%s: oh we are sooo fucked. GAME OVER MAN\n", argv[0]);
> fail = 1; goto done;
> }
>
> if ((out = fopen(OUTFILE, "wb")) == NULL) {
> fprintf(stderr, "%s: failed to open %s for writing\n", argv[0], OUTFILE);
> fail = 1; goto done;
> }
>
> if (sio_start(h) == 0) {
> fprintf(stderr, "%s: failed to sio_start\n", argv[0]);
> fail = 1; goto done;
> }
> started = 1;
> int retries = 0;
> printf("START\n");
> for (i = 0; i < ITERATIONS; i++) {
> if ((bytes_read = sio_read(h, sample_buf, BUF_SAMPLES * sizeof(short))) == 0) {
> fprintf(stderr, "%s: failed to sio_read\n", argv[0]);
> fail = 1; goto done;
> }
> total_bytes_read += bytes_read;
>
> size_t bytes_written;
> size_t bw;
> char* buf_ptr = (char *) sample_buf;
> for (bytes_written = 0; bytes_written < bytes_read; bytes_written += bw) {
> size_t bytes_left = bytes_read - bytes_written;
> bw = fwrite(buf_ptr, 1, bytes_left, out);
> if (bw < bytes_left && errno != EAGAIN) {
> fprintf(stderr, "%s: failed to write to file\n", argv[0]);
> perror(argv[0]);
> fail = 1; goto done;
> }
> buf_ptr += bw;
> }
> }
> printf("TOTAL BYTES READ: %d\n", total_bytes_read);
>
> // cleanup
> done:
> if (started) {
> sio_stop(h);
> }
> if (out != NULL) {
> fclose(out);
> }
> if (sample_buf != NULL) {
> free(sample_buf);
> }
> if (h != NULL) {
> sio_close(h);
> }
> return fail;
> }
>
> void print_par(struct sio_par *par) {
> char *xrun;
> switch (par->xrun) {
> default:
> xrun = "<unknown xrun val>";
> break;
> case 0:
> xrun = "SIO_IGNORE";
> break;
> case 1:
> xrun = "SIO_SYNC";
> break;
> case 2:
> xrun = "SIO_ERROR";
> break;
> }
> printf("&sio_par{\n"
> " bits: %d,\n"
> " bps: %d,\n"
> " sig: %d,\n"
> " le: %d,\n"
> " msb: %d,\n"
> " rchan: %d,\n"
> " pchan: %d,\n"
> " rate: %d,\n"
> " appbufsz: %d,\n"
> " bufsz: %d,\n"
> " round: %d,\n"
> " xrun: %s (%d),\n"
> "}\n",
> par->bits, /* bits per sample */
> par->bps, /* bytes per sample */
> par->sig, /* 1 = signed, 0 = unsigned int */
> par->le, /* 1 = LE, 0 = BE byte order */
> par->msb, /* 1 = MSB, 0 = LSB aligned */
> par->rchan, /* number channels for recording */
> par->pchan, /* number channels for playback */
> par->rate, /* frames per second */
> par->appbufsz, /* minimum buffer size without xruns */
> par->bufsz, /* end-to-end buffer size (read-only) */
> par->round, /* optimal buffer size divisor */
> xrun, /* what to do on overrun/underrun */
> par->xrun
> );
> }
Re: macbook - uvideo0: can't find video interface
On May 31 13:24:20, hans@stare.cz wrote:
> On May 31 12:16:58, hans@stare.cz wrote:
> > Hi,
> >
> > On May 26 22:15:28, feinerer@logic.at wrote:
> > > I think that my fix for video(1) posted at
> > > https://marc.info/?l=openbsd-tech&m=159048565528060&w=2 could also
> > > remedy your problem of video(1) crashing reported at
> > > https://marc.info/?l=openbsd-misc&m=158800058009113&w=2 .
> >
> > On May 30 23:52:43, patrick@blueri.se wrote:
> > > On Sat, May 30, 2020 at 07:47:17PM +0200, Jan Stary wrote:
> > > > On May 30 18:50:12, hans@stare.cz wrote:
> > > > > This is current/amd64 on a MacBook2,1 (dmesg below)
> > > > > With the latest upgrade, it has lost video0:
> > > > >
> > > > > uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight" rev 2.00/1.84 addr 2
> > > > > uvideo0: can't find interface assoc descriptor
> > > >
> > > > Similar thing happens with current/i386 on a MacBook1,1 (dmesg below):
> > > > uvideo0: can't find video interface
> > > >
> > > > Jan
> > >
> > > Yeah, this is due to the change to support multiple cameras in one
> > > device. You can try this diff, let me know if this works on both
> > > of your machines.
> >
> > With Patrick's diff, my amd64 Macbook2,1 has video0 at uvideo0 again.
> > I compiled the patched kernel with UVIDEO_DEBUG, dmesg below. Thanks!
>
> On the i386 macbook, the UVIDEO_DEBUG messages spam the dmesg so much
> that I only have the uvideo tail in dmesg.boot (see below).
> I will recompile without UVIDEO_DEBUG.
dmesg below
Notice how uvideo0 frst ataches as "Apple Computer Bluetooth",
detaches, and ataches again as "Micron Built-in iSight"
Jan
OpenBSD 6.7-current (GENERIC.MP) #0: Sun May 31 13:44:04 CEST 2020
hans@mb32.stare.cz:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem = 2113323008 (2015MB)
avail mem = 2059010048 (1963MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 07/29/05, SMBIOS rev. 2.4 @ 0xe7490 (36 entries)
bios0: vendor Apple Computer, Inc. version "MB11.88Z.0061.B03.0610121324" date 10/12/06
bios0: Apple Computer, Inc. MacBook1,1
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT
acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB7(S3) EC__(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU T2500 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz, 06-0e-08
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2500 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz, 06-0e-08
cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
gcpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (PCIB)
acpicpu0 at acpi0: !C4(100@55 mwait@0x31), !C3(500@1 mwait@0x20), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS
acpicpu1 at acpi0: !C4(100@55 mwait@0x31), !C3(500@1 mwait@0x20), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS
acpisbs0 at acpi0: SBS0 model "ASMB016" serial 35580 type LION oem "DP"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
"APP0002" at acpi0 not configured
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0A08" at acpi0 not configured
"APP0001" at acpi0 not configured
"APP0003" at acpi0 not configured
"ACPI0001" at acpi0 not configured
"IFX0101" at acpi0 not configured
acpicmos0 at acpi0
acpivideo0 at acpi0: GFX0
bios0: ROM list: 0xc0000/0xe600!
cpu0: Enhanced SpeedStep 1998 MHz: speeds: 2000, 1833, 1667, 1500, 1333, 1000 MHz
memory map conflict 0xe00f8000/0x1000
memory map conflict 0xfed1c000/0x4000
memory map conflict 0xfffb0000/0x30000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0x80000000, size 0x10000000
inteldrm0: apic 1 int 16, I945GM, gen 3
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
vendor "Intel", unknown product 0x27a3 (class DASP subclass Time and Frequency, rev 0x03) at pci0 dev 7 function 0 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Sigmatel STAC9220/1
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 17
pci1 at ppb0 bus 1
mskc0 at pci1 dev 0 function 0 "Marvell Yukon 88E8053" rev 0x22, Yukon-2 EC rev. A3 (0x2): apic 1 int 16
msk0 at mskc0 port A: address 00:16:cb:d0:c4:3c
eephy0 at msk0 phy 0: 88E1111 Gigabit PHY, rev. 2
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 16
pci2 at ppb1 bus 2
ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 17
ath0: AR5424 10.3 phy 6.1 rf 10.2 eeprom 5.3, WORAW, address 00:16:cb:bf:f6:88
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 21
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 21
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci3 at ppb2 bus 3
"AT&T/Lucent FW322 1394" rev 0x61 at pci3 dev 3 function 0 not configured
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <MATSHITA, DVD-R UJ-857, HBEA> removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 31 function 2 "Intel 82801GBM SATA" rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 1 int 19 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 1: <ST960813AS>
wd0: 16-sector PIO, LBA48, 57231MB, 117210240 sectors
wd0(pciide1:0:1): using PIO mode 4, Ultra-DMA mode 5
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x02: apic 1 int 19
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
asmc0 at isa0 port 0x300/32: rev 1.4f504, 203 keys
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Apple Computer Bluetooth" rev 2.00/0.0c addr 2
uhidev0 at uhub1 port 2 configuration 1 interface 0 "Apple Inc. Apple Internal Keyboard / Trackpad" rev 2.00/0.09 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 5 key codes, country code 13
wskbd0 at ukbd0: console keyboard
uhidev1 at uhub1 port 2 configuration 1 interface 1 "Apple Inc. Apple Internal Keyboard / Trackpad" rev 2.00/0.09 addr 2
uhidev1: iclass 3/1, 5 report ids
ums0 at uhidev1 reportid 2: 3 buttons
wsmouse0 at ums0 mux 0
ums1 at uhidev1 reportid 5
ums1: mouse has no X report
uhidev2 at uhub1 port 2 configuration 1 interface 2 "Apple Inc. Apple Internal Keyboard / Trackpad" rev 2.00/0.09 addr 2
uhidev2: iclass 3/0
uhid0 at uhidev2: input=1, output=0, feature=0
uhidev3 at uhub3 port 2 configuration 1 interface 0 "Apple Computer, Inc. IR Receiver" rev 2.00/1.10 addr 2
uhidev3: iclass 3/0, 38 report ids
uhid1 at uhidev3 reportid 36: input=4, output=0, feature=0
uhid2 at uhidev3 reportid 37: input=4, output=0, feature=0
uhid3 at uhidev3 reportid 38: input=4, output=0, feature=0
uhidev4 at uhub4 port 1 configuration 1 interface 0 "Apple Computer HID-proxy" rev 2.00/19.65 addr 2
uhidev4: iclass 3/1
ukbd1 at uhidev4: 8 variable keys, 6 key codes
wskbd1 at ukbd1 mux 1
uhidev5 at uhub4 port 1 configuration 1 interface 1 "Apple Computer HID-proxy" rev 2.00/19.65 addr 2
uhidev5: iclass 3/1
ums2 at uhidev5: 5 buttons
wsmouse1 at ums2 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (d56fb6b19bfb4252.a) swap on wd0b dump on wd0b
inteldrm0: 1280x800, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uvideo0 detached
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight" rev 2.00/1.84 addr 2
video0 at uvideo0
> On May 31 12:16:58, hans@stare.cz wrote:
> > Hi,
> >
> > On May 26 22:15:28, feinerer@logic.at wrote:
> > > I think that my fix for video(1) posted at
> > > https://marc.info/?l=openbsd-tech&m=159048565528060&w=2 could also
> > > remedy your problem of video(1) crashing reported at
> > > https://marc.info/?l=openbsd-misc&m=158800058009113&w=2 .
> >
> > On May 30 23:52:43, patrick@blueri.se wrote:
> > > On Sat, May 30, 2020 at 07:47:17PM +0200, Jan Stary wrote:
> > > > On May 30 18:50:12, hans@stare.cz wrote:
> > > > > This is current/amd64 on a MacBook2,1 (dmesg below)
> > > > > With the latest upgrade, it has lost video0:
> > > > >
> > > > > uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight" rev 2.00/1.84 addr 2
> > > > > uvideo0: can't find interface assoc descriptor
> > > >
> > > > Similar thing happens with current/i386 on a MacBook1,1 (dmesg below):
> > > > uvideo0: can't find video interface
> > > >
> > > > Jan
> > >
> > > Yeah, this is due to the change to support multiple cameras in one
> > > device. You can try this diff, let me know if this works on both
> > > of your machines.
> >
> > With Patrick's diff, my amd64 Macbook2,1 has video0 at uvideo0 again.
> > I compiled the patched kernel with UVIDEO_DEBUG, dmesg below. Thanks!
>
> On the i386 macbook, the UVIDEO_DEBUG messages spam the dmesg so much
> that I only have the uvideo tail in dmesg.boot (see below).
> I will recompile without UVIDEO_DEBUG.
dmesg below
Notice how uvideo0 frst ataches as "Apple Computer Bluetooth",
detaches, and ataches again as "Micron Built-in iSight"
Jan
OpenBSD 6.7-current (GENERIC.MP) #0: Sun May 31 13:44:04 CEST 2020
hans@mb32.stare.cz:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem = 2113323008 (2015MB)
avail mem = 2059010048 (1963MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 07/29/05, SMBIOS rev. 2.4 @ 0xe7490 (36 entries)
bios0: vendor Apple Computer, Inc. version "MB11.88Z.0061.B03.0610121324" date 10/12/06
bios0: Apple Computer, Inc. MacBook1,1
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT
acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB7(S3) EC__(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU T2500 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz, 06-0e-08
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2500 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz, 06-0e-08
cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
gcpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (PCIB)
acpicpu0 at acpi0: !C4(100@55 mwait@0x31), !C3(500@1 mwait@0x20), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS
acpicpu1 at acpi0: !C4(100@55 mwait@0x31), !C3(500@1 mwait@0x20), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS
acpisbs0 at acpi0: SBS0 model "ASMB016" serial 35580 type LION oem "DP"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
"APP0002" at acpi0 not configured
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0A08" at acpi0 not configured
"APP0001" at acpi0 not configured
"APP0003" at acpi0 not configured
"ACPI0001" at acpi0 not configured
"IFX0101" at acpi0 not configured
acpicmos0 at acpi0
acpivideo0 at acpi0: GFX0
bios0: ROM list: 0xc0000/0xe600!
cpu0: Enhanced SpeedStep 1998 MHz: speeds: 2000, 1833, 1667, 1500, 1333, 1000 MHz
memory map conflict 0xe00f8000/0x1000
memory map conflict 0xfed1c000/0x4000
memory map conflict 0xfffb0000/0x30000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0x80000000, size 0x10000000
inteldrm0: apic 1 int 16, I945GM, gen 3
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
vendor "Intel", unknown product 0x27a3 (class DASP subclass Time and Frequency, rev 0x03) at pci0 dev 7 function 0 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Sigmatel STAC9220/1
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 17
pci1 at ppb0 bus 1
mskc0 at pci1 dev 0 function 0 "Marvell Yukon 88E8053" rev 0x22, Yukon-2 EC rev. A3 (0x2): apic 1 int 16
msk0 at mskc0 port A: address 00:16:cb:d0:c4:3c
eephy0 at msk0 phy 0: 88E1111 Gigabit PHY, rev. 2
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 16
pci2 at ppb1 bus 2
ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 17
ath0: AR5424 10.3 phy 6.1 rf 10.2 eeprom 5.3, WORAW, address 00:16:cb:bf:f6:88
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 21
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 21
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci3 at ppb2 bus 3
"AT&T/Lucent FW322 1394" rev 0x61 at pci3 dev 3 function 0 not configured
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <MATSHITA, DVD-R UJ-857, HBEA> removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 31 function 2 "Intel 82801GBM SATA" rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 1 int 19 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 1: <ST960813AS>
wd0: 16-sector PIO, LBA48, 57231MB, 117210240 sectors
wd0(pciide1:0:1): using PIO mode 4, Ultra-DMA mode 5
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x02: apic 1 int 19
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
asmc0 at isa0 port 0x300/32: rev 1.4f504, 203 keys
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Apple Computer Bluetooth" rev 2.00/0.0c addr 2
uhidev0 at uhub1 port 2 configuration 1 interface 0 "Apple Inc. Apple Internal Keyboard / Trackpad" rev 2.00/0.09 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 5 key codes, country code 13
wskbd0 at ukbd0: console keyboard
uhidev1 at uhub1 port 2 configuration 1 interface 1 "Apple Inc. Apple Internal Keyboard / Trackpad" rev 2.00/0.09 addr 2
uhidev1: iclass 3/1, 5 report ids
ums0 at uhidev1 reportid 2: 3 buttons
wsmouse0 at ums0 mux 0
ums1 at uhidev1 reportid 5
ums1: mouse has no X report
uhidev2 at uhub1 port 2 configuration 1 interface 2 "Apple Inc. Apple Internal Keyboard / Trackpad" rev 2.00/0.09 addr 2
uhidev2: iclass 3/0
uhid0 at uhidev2: input=1, output=0, feature=0
uhidev3 at uhub3 port 2 configuration 1 interface 0 "Apple Computer, Inc. IR Receiver" rev 2.00/1.10 addr 2
uhidev3: iclass 3/0, 38 report ids
uhid1 at uhidev3 reportid 36: input=4, output=0, feature=0
uhid2 at uhidev3 reportid 37: input=4, output=0, feature=0
uhid3 at uhidev3 reportid 38: input=4, output=0, feature=0
uhidev4 at uhub4 port 1 configuration 1 interface 0 "Apple Computer HID-proxy" rev 2.00/19.65 addr 2
uhidev4: iclass 3/1
ukbd1 at uhidev4: 8 variable keys, 6 key codes
wskbd1 at ukbd1 mux 1
uhidev5 at uhub4 port 1 configuration 1 interface 1 "Apple Computer HID-proxy" rev 2.00/19.65 addr 2
uhidev5: iclass 3/1
ums2 at uhidev5: 5 buttons
wsmouse1 at ums2 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (d56fb6b19bfb4252.a) swap on wd0b dump on wd0b
inteldrm0: 1280x800, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uvideo0 detached
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight" rev 2.00/1.84 addr 2
video0 at uvideo0
Re: [update] devel/libtermkey
ping
On Sat, May 23, 2020 at 08:12:11PM -0500, Matthew Martin wrote:
> No change in symbols and the diff doesn't seem to touch any public
> functions. Only bumped minor because upstream did.
>
> neovim and vis run fine with this. The new patch allows the vis test
> suite to run without the TEST_ENV = TERM=${TERM} hack. I'll ask upstream
> about adding the patch, but libtermkey is deprecated in favor of
> libtickit (will send that port after the 0.4.0 release).
>
> 0.22 - changes: bugfixes for unit tests on BSD platforms
> 0.21.1 - changes: internal bugfixes, valgrind neatness
>
diff --git Makefile Makefile
index e5bd66764f9..2ea5107ffc2 100644
--- Makefile
+++ Makefile
@@ -1,10 +1,9 @@
# $OpenBSD: Makefile,v 1.4 2019/07/12 20:44:40 sthen Exp $
COMMENT = library for processing of keyboard entry from a terminal
-DISTNAME = libtermkey-0.20
-REVISION = 0
+DISTNAME = libtermkey-0.22
-SHARED_LIBS += termkey 0.1 # 15.0
+SHARED_LIBS += termkey 0.2 # 15.2
CATEGORIES = devel
HOMEPAGE = http://www.leonerd.org.uk/code/libtermkey/
diff --git distinfo distinfo
index 522108c35ed..81ce3702ceb 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libtermkey-0.20.tar.gz) = bA2HyUq5kV527NMTuuwI3t871W3oN0PZqpI6CBk10vU=
-SIZE (libtermkey-0.20.tar.gz) = 45167
+SHA256 (libtermkey-0.22.tar.gz) = aUW9PEqqg9qD2AoEXFVj2k7dfQN0xiwNNa7AnrMBRgA=
+SIZE (libtermkey-0.22.tar.gz) = 46147
diff --git patches/patch-Makefile patches/patch-Makefile
index aee3dddc084..4ef14700525 100644
--- patches/patch-Makefile
+++ patches/patch-Makefile
@@ -3,9 +3,10 @@ $OpenBSD: patch-Makefile,v 1.1.1.1 2017/01/19 20:34:04 edd Exp $
Don't compresss manuals and remove odd symlinking scheme to alias man pages. As
it happens mandoc is clever enough to figure out the aliases.
---- Makefile.orig Fri Dec 16 16:08:07 2016
-+++ Makefile Tue Jan 17 23:15:29 2017
-@@ -120,12 +120,9 @@ install-man:
+Index: Makefile
+--- Makefile.orig
++++ Makefile
+@@ -122,12 +122,9 @@ install-man:
install -d $(DESTDIR)$(MAN3DIR)
install -d $(DESTDIR)$(MAN7DIR)
for F in man/*.3; do \
diff --git patches/patch-termkey_c patches/patch-termkey_c
new file mode 100644
index 00000000000..a6a94f6feac
--- /dev/null
+++ patches/patch-termkey_c
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+unibi_from_term requires term to be non-NULL
+
+Index: termkey.c
+--- termkey.c.orig
++++ termkey.c
+@@ -420,6 +420,9 @@ TermKey *termkey_new(int fd, int flags)
+ termkey_set_flags(tk, flags);
+
+ const char *term = getenv("TERM");
++ if (!term) {
++ term = "xterm";
++ }
+
+ if(!termkey_init(tk, term))
+ goto abort;
On Sat, May 23, 2020 at 08:12:11PM -0500, Matthew Martin wrote:
> No change in symbols and the diff doesn't seem to touch any public
> functions. Only bumped minor because upstream did.
>
> neovim and vis run fine with this. The new patch allows the vis test
> suite to run without the TEST_ENV = TERM=${TERM} hack. I'll ask upstream
> about adding the patch, but libtermkey is deprecated in favor of
> libtickit (will send that port after the 0.4.0 release).
>
> 0.22 - changes: bugfixes for unit tests on BSD platforms
> 0.21.1 - changes: internal bugfixes, valgrind neatness
>
diff --git Makefile Makefile
index e5bd66764f9..2ea5107ffc2 100644
--- Makefile
+++ Makefile
@@ -1,10 +1,9 @@
# $OpenBSD: Makefile,v 1.4 2019/07/12 20:44:40 sthen Exp $
COMMENT = library for processing of keyboard entry from a terminal
-DISTNAME = libtermkey-0.20
-REVISION = 0
+DISTNAME = libtermkey-0.22
-SHARED_LIBS += termkey 0.1 # 15.0
+SHARED_LIBS += termkey 0.2 # 15.2
CATEGORIES = devel
HOMEPAGE = http://www.leonerd.org.uk/code/libtermkey/
diff --git distinfo distinfo
index 522108c35ed..81ce3702ceb 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (libtermkey-0.20.tar.gz) = bA2HyUq5kV527NMTuuwI3t871W3oN0PZqpI6CBk10vU=
-SIZE (libtermkey-0.20.tar.gz) = 45167
+SHA256 (libtermkey-0.22.tar.gz) = aUW9PEqqg9qD2AoEXFVj2k7dfQN0xiwNNa7AnrMBRgA=
+SIZE (libtermkey-0.22.tar.gz) = 46147
diff --git patches/patch-Makefile patches/patch-Makefile
index aee3dddc084..4ef14700525 100644
--- patches/patch-Makefile
+++ patches/patch-Makefile
@@ -3,9 +3,10 @@ $OpenBSD: patch-Makefile,v 1.1.1.1 2017/01/19 20:34:04 edd Exp $
Don't compresss manuals and remove odd symlinking scheme to alias man pages. As
it happens mandoc is clever enough to figure out the aliases.
---- Makefile.orig Fri Dec 16 16:08:07 2016
-+++ Makefile Tue Jan 17 23:15:29 2017
-@@ -120,12 +120,9 @@ install-man:
+Index: Makefile
+--- Makefile.orig
++++ Makefile
+@@ -122,12 +122,9 @@ install-man:
install -d $(DESTDIR)$(MAN3DIR)
install -d $(DESTDIR)$(MAN7DIR)
for F in man/*.3; do \
diff --git patches/patch-termkey_c patches/patch-termkey_c
new file mode 100644
index 00000000000..a6a94f6feac
--- /dev/null
+++ patches/patch-termkey_c
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+unibi_from_term requires term to be non-NULL
+
+Index: termkey.c
+--- termkey.c.orig
++++ termkey.c
+@@ -420,6 +420,9 @@ TermKey *termkey_new(int fd, int flags)
+ termkey_set_flags(tk, flags);
+
+ const char *term = getenv("TERM");
++ if (!term) {
++ term = "xterm";
++ }
+
+ if(!termkey_init(tk, term))
+ goto abort;
Re: [update] devel/unibilium
ping
On Sat, May 23, 2020 at 08:11:32PM -0500, Matthew Martin wrote:
> Update to unibilium. No change in symbols and the diff doesn't seem to
> touch any public functions. Only bumped minor because upstream did.
>
> Tests pass and libtermkey (up next), neovim, and vis seem ok.
>
> 2.1.0 2020-02-11
> - Makefile: use "-f" with prove always (to show failed tests) (#13)
> - Stop searching in further dirs on errors except ENOENT #12
> - Makefile: do not rebuild t/static_%.c with updated gen-static-test
> - Add CMakeLists.txt and support for MSVC (#3)
> - Relax checks for extended capability to support new format (#5)
> - Makefile: use -Og with DEBUG=1 (#7)
> - unibi_from_mem: fix [clang-analyzer-deadcode.DeadStores] (#8)
> - Makefile: revisit regenerate-tests rule (#6)
> - unibi_from_term: handle $TERMINFO as curses does #2
>
diff --git Makefile Makefile
index 8af2e12f4fa..25e88c9f8b4 100644
--- Makefile
+++ Makefile
@@ -4,9 +4,9 @@ COMMENT = very basic terminfo library
GH_ACCOUNT = neovim
GH_PROJECT = unibilium
-GH_TAGNAME = v2.0.0
+GH_TAGNAME = v2.1.0
-SHARED_LIBS += unibilium 1.0 # 4.0
+SHARED_LIBS += unibilium 1.1 # 4.1
CATEGORIES = devel
diff --git distinfo distinfo
index b531af481ad..3d6bd8e15fd 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (unibilium-2.0.0.tar.gz) = eJl9ONTIF3xg09DBqoxT/QgG6yGCW3szWxdo1xFrwcE=
-SIZE (unibilium-2.0.0.tar.gz) = 112570
+SHA256 (unibilium-2.1.0.tar.gz) = Bb+X41dhXiGBJvesCG5wVqI9wBPPrHFkO1ChitOQx9Q=
+SIZE (unibilium-2.1.0.tar.gz) = 121971
diff --git patches/patch-Makefile patches/patch-Makefile
index 397d2e8fe7f..3a069bd7379 100644
--- patches/patch-Makefile
+++ patches/patch-Makefile
@@ -24,4 +24,4 @@ Index: Makefile
+ $(POD2MAN) $(POD2MAN_OPTS) $< > $@
- .PHONY: regenerate-tests
+ # Regenerate static test files, based on existing terminfo entries.
On Sat, May 23, 2020 at 08:11:32PM -0500, Matthew Martin wrote:
> Update to unibilium. No change in symbols and the diff doesn't seem to
> touch any public functions. Only bumped minor because upstream did.
>
> Tests pass and libtermkey (up next), neovim, and vis seem ok.
>
> 2.1.0 2020-02-11
> - Makefile: use "-f" with prove always (to show failed tests) (#13)
> - Stop searching in further dirs on errors except ENOENT #12
> - Makefile: do not rebuild t/static_%.c with updated gen-static-test
> - Add CMakeLists.txt and support for MSVC (#3)
> - Relax checks for extended capability to support new format (#5)
> - Makefile: use -Og with DEBUG=1 (#7)
> - unibi_from_mem: fix [clang-analyzer-deadcode.DeadStores] (#8)
> - Makefile: revisit regenerate-tests rule (#6)
> - unibi_from_term: handle $TERMINFO as curses does #2
>
diff --git Makefile Makefile
index 8af2e12f4fa..25e88c9f8b4 100644
--- Makefile
+++ Makefile
@@ -4,9 +4,9 @@ COMMENT = very basic terminfo library
GH_ACCOUNT = neovim
GH_PROJECT = unibilium
-GH_TAGNAME = v2.0.0
+GH_TAGNAME = v2.1.0
-SHARED_LIBS += unibilium 1.0 # 4.0
+SHARED_LIBS += unibilium 1.1 # 4.1
CATEGORIES = devel
diff --git distinfo distinfo
index b531af481ad..3d6bd8e15fd 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (unibilium-2.0.0.tar.gz) = eJl9ONTIF3xg09DBqoxT/QgG6yGCW3szWxdo1xFrwcE=
-SIZE (unibilium-2.0.0.tar.gz) = 112570
+SHA256 (unibilium-2.1.0.tar.gz) = Bb+X41dhXiGBJvesCG5wVqI9wBPPrHFkO1ChitOQx9Q=
+SIZE (unibilium-2.1.0.tar.gz) = 121971
diff --git patches/patch-Makefile patches/patch-Makefile
index 397d2e8fe7f..3a069bd7379 100644
--- patches/patch-Makefile
+++ patches/patch-Makefile
@@ -24,4 +24,4 @@ Index: Makefile
+ $(POD2MAN) $(POD2MAN_OPTS) $< > $@
- .PHONY: regenerate-tests
+ # Regenerate static test files, based on existing terminfo entries.
Re: UPDATE: games/uhexen2 1.5.9
Hi,
On Thu, May 28, 2020 at 04:18:04PM -0500, Paul Valencia wrote:
> ping.
This looks for the most part fine. I was unable to test because fetching the
tarball seems to be timing out (possible issues at sourceforge?).
I was also wondering if hunks like the following are necessary:
-CPPFLAGS=
-LDFLAGS =
+CPPFLAGS +=
+LDFLAGS +=
We might be able to simplify our patches by simply removing those
assignments altogether?
I'll try the distfiles again tomorrow.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
On Thu, May 28, 2020 at 04:18:04PM -0500, Paul Valencia wrote:
> ping.
This looks for the most part fine. I was unable to test because fetching the
tarball seems to be timing out (possible issues at sourceforge?).
I was also wondering if hunks like the following are necessary:
-CPPFLAGS=
-LDFLAGS =
+CPPFLAGS +=
+LDFLAGS +=
We might be able to simplify our patches by simply removing those
assignments altogether?
I'll try the distfiles again tomorrow.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: x11/dmenu: drop fonts/terminus-font from RUN_DEPENDS
On Sun, May 31, 2020 at 01:39:30PM +0000, Lucas wrote:
> FTR, I originally removed the patch for config.def.h completely in
> dmenu as I didn't see much point in introducing a patch just for
> changing some colors, which can be changed with parameters and seem
> quite randomly chosen (they don't match CSS for OpenBSD site, which I
> think is the only official thing that can be considered as some sort of
> colorscheme).
Let's do one thing at a time, if others later decide to change colors
they can do so, I'd like to fix the fonts due the implied dependencies,
all else I'd like to leave the any future porter/MAINTAINER.
> FTR, I originally removed the patch for config.def.h completely in
> dmenu as I didn't see much point in introducing a patch just for
> changing some colors, which can be changed with parameters and seem
> quite randomly chosen (they don't match CSS for OpenBSD site, which I
> think is the only official thing that can be considered as some sort of
> colorscheme).
Let's do one thing at a time, if others later decide to change colors
they can do so, I'd like to fix the fonts due the implied dependencies,
all else I'd like to leave the any future porter/MAINTAINER.
Re: x11/dmenu: drop fonts/terminus-font from RUN_DEPENDS
Klemens Nanni <kn@openbsd.org> wrote:
> I tested the update more thoroughly now, fixed a missing REVISION bump
> in dmenu and also noticed that dwm passes its fonts to dmenu via command
> line, so strictly speaking we wouldn't have to adjust dmenu along with
> dwm to ensure the same font across both tools because one already forces
> the other; still, I'd like to keep stuff in sync in general.
>
> Updated diff below to drop terminus-font after I already committed my
> MAINTAINER drop.
Thanks for taking care of dwm too, it didn't cross my mind to take a
look at it. FWIW, the diffs looks good to me.
FTR, I originally removed the patch for config.def.h completely in
dmenu as I didn't see much point in introducing a patch just for
changing some colors, which can be changed with parameters and seem
quite randomly chosen (they don't match CSS for OpenBSD site, which I
think is the only official thing that can be considered as some sort of
colorscheme).
> I tested the update more thoroughly now, fixed a missing REVISION bump
> in dmenu and also noticed that dwm passes its fonts to dmenu via command
> line, so strictly speaking we wouldn't have to adjust dmenu along with
> dwm to ensure the same font across both tools because one already forces
> the other; still, I'd like to keep stuff in sync in general.
>
> Updated diff below to drop terminus-font after I already committed my
> MAINTAINER drop.
Thanks for taking care of dwm too, it didn't cross my mind to take a
look at it. FWIW, the diffs looks good to me.
FTR, I originally removed the patch for config.def.h completely in
dmenu as I didn't see much point in introducing a patch just for
changing some colors, which can be changed with parameters and seem
quite randomly chosen (they don't match CSS for OpenBSD site, which I
think is the only official thing that can be considered as some sort of
colorscheme).
Re: x11/dmenu: drop fonts/terminus-font from RUN_DEPENDS
On Sun, May 31, 2020 at 12:37:52PM +0100, Chris Rawnsley wrote:
> I did some digging and it looks like it was dwm's default up until the
> 5.6 release. I guess it was kept around from an abundance of nostalgia.
Much appreciated, thanks.
I tested the update more thoroughly now, fixed a missing REVISION bump
in dmenu and also noticed that dwm passes its fonts to dmenu via command
line, so strictly speaking we wouldn't have to adjust dmenu along with
dwm to ensure the same font across both tools because one already forces
the other; still, I'd like to keep stuff in sync in general.
Updated diff below to drop terminus-font after I already committed my
MAINTAINER drop.
OKs welcome; Unless I hear objections in the next few days, I'll just
go ahead and commit it.
Index: dwm/Makefile
===================================================================
RCS file: /cvs/ports/x11/dwm/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- dwm/Makefile 31 May 2020 11:46:46 -0000 1.35
+++ dwm/Makefile 31 May 2020 11:58:19 -0000
@@ -4,7 +4,7 @@ COMMENT= dynamic window manager
V= 6.2
DISTNAME= dwm-${V}
-REVISION= 1
+REVISION= 2
CATEGORIES= x11
@@ -18,8 +18,7 @@ WANTLIB= X11 Xinerama Xft c fontconfig
MASTER_SITES= https://dl.suckless.org/dwm/
-RUN_DEPENDS= x11/dmenu>=4.6 \
- fonts/terminus-font
+RUN_DEPENDS= x11/dmenu>=4.6
MAKE_ENV= LDFLAGS="${LDFLAGS}" \
X11INC=${X11BASE}/include \
Index: dwm/patches/patch-config_def_h
===================================================================
RCS file: /cvs/ports/x11/dwm/patches/patch-config_def_h,v
retrieving revision 1.15
diff -u -p -r1.15 patch-config_def_h
--- dwm/patches/patch-config_def_h 5 Mar 2019 19:35:08 -0000 1.15
+++ dwm/patches/patch-config_def_h 31 May 2020 11:58:19 -0000
@@ -2,19 +2,15 @@ $OpenBSD: patch-config_def_h,v 1.15 2019
Index: config.def.h
--- config.def.h.orig
+++ config.def.h
-@@ -5,17 +5,17 @@ static const unsigned int borderpx = 1; /* bor
- static const unsigned int snap = 32; /* snap pixel */
- static const int showbar = 1; /* 0 means no bar */
+@@ -7,15 +7,15 @@ static const int showbar = 1; /* 0 m
static const int topbar = 1; /* 0 means bottom bar */
--static const char *fonts[] = { "monospace:size=10" };
--static const char dmenufont[] = "monospace:size=10";
+ static const char *fonts[] = { "monospace:size=10" };
+ static const char dmenufont[] = "monospace:size=10";
-static const char col_gray1[] = "#222222";
-static const char col_gray2[] = "#444444";
-static const char col_gray3[] = "#bbbbbb";
-static const char col_gray4[] = "#eeeeee";
-static const char col_cyan[] = "#005577";
-+static const char *fonts[] = { "terminus:size=8" };
-+static const char dmenufont[] = "terminus:size=8";
+static const char col_gray1[] = "#202020";
+static const char col_gray2[] = "#404040";
+static const char col_gray3[] = "#c0c0c0";
Index: dmenu/Makefile
===================================================================
RCS file: /cvs/ports/x11/dmenu/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- dmenu/Makefile 31 May 2020 11:46:46 -0000 1.26
+++ dmenu/Makefile 31 May 2020 11:58:19 -0000
@@ -4,7 +4,7 @@ COMMENT= dynamic menu for X11
V= 4.9
DISTNAME= dmenu-${V}
-REVISION= 0
+REVISION= 1
CATEGORIES= x11
@@ -17,8 +17,6 @@ PERMIT_PACKAGE= Yes
WANTLIB= X11 Xft Xinerama c fontconfig
MASTER_SITES= https://dl.suckless.org/tools/
-
-RUN_DEPENDS= fonts/terminus-font
MAKE_ENV= LDFLAGS="${LDFLAGS}" \
X11INC=${X11BASE}/include \
Index: dmenu/patches/patch-config_def_h
===================================================================
RCS file: /cvs/ports/x11/dmenu/patches/patch-config_def_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-config_def_h
--- dmenu/patches/patch-config_def_h 10 May 2017 22:06:33 -0000 1.2
+++ dmenu/patches/patch-config_def_h 31 May 2020 11:58:19 -0000
@@ -1,13 +1,8 @@
$OpenBSD: patch-config_def_h,v 1.2 2017/05/10 22:06:33 jung Exp $
---- config.def.h.orig Mon May 8 19:27:54 2017
-+++ config.def.h Mon May 8 19:27:30 2017
-@@ -4,13 +4,13 @@
- static int topbar = 1; /* -b option; if 0, dmenu appears at bottom */
- /* -fn option overrides fonts[0]; default X11 font or font set */
- static const char *fonts[] = {
-- "monospace:size=10"
-+ "terminus:size=8"
- };
+Index: config.def.h
+--- config.def.h.orig
++++ config.def.h
+@@ -9,8 +9,8 @@ static const char *fonts[] = {
static const char *prompt = NULL; /* -p option; prompt to the left of input field */
static const char *colors[SchemeLast][2] = {
/* fg bg */
> I did some digging and it looks like it was dwm's default up until the
> 5.6 release. I guess it was kept around from an abundance of nostalgia.
Much appreciated, thanks.
I tested the update more thoroughly now, fixed a missing REVISION bump
in dmenu and also noticed that dwm passes its fonts to dmenu via command
line, so strictly speaking we wouldn't have to adjust dmenu along with
dwm to ensure the same font across both tools because one already forces
the other; still, I'd like to keep stuff in sync in general.
Updated diff below to drop terminus-font after I already committed my
MAINTAINER drop.
OKs welcome; Unless I hear objections in the next few days, I'll just
go ahead and commit it.
Index: dwm/Makefile
===================================================================
RCS file: /cvs/ports/x11/dwm/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- dwm/Makefile 31 May 2020 11:46:46 -0000 1.35
+++ dwm/Makefile 31 May 2020 11:58:19 -0000
@@ -4,7 +4,7 @@ COMMENT= dynamic window manager
V= 6.2
DISTNAME= dwm-${V}
-REVISION= 1
+REVISION= 2
CATEGORIES= x11
@@ -18,8 +18,7 @@ WANTLIB= X11 Xinerama Xft c fontconfig
MASTER_SITES= https://dl.suckless.org/dwm/
-RUN_DEPENDS= x11/dmenu>=4.6 \
- fonts/terminus-font
+RUN_DEPENDS= x11/dmenu>=4.6
MAKE_ENV= LDFLAGS="${LDFLAGS}" \
X11INC=${X11BASE}/include \
Index: dwm/patches/patch-config_def_h
===================================================================
RCS file: /cvs/ports/x11/dwm/patches/patch-config_def_h,v
retrieving revision 1.15
diff -u -p -r1.15 patch-config_def_h
--- dwm/patches/patch-config_def_h 5 Mar 2019 19:35:08 -0000 1.15
+++ dwm/patches/patch-config_def_h 31 May 2020 11:58:19 -0000
@@ -2,19 +2,15 @@ $OpenBSD: patch-config_def_h,v 1.15 2019
Index: config.def.h
--- config.def.h.orig
+++ config.def.h
-@@ -5,17 +5,17 @@ static const unsigned int borderpx = 1; /* bor
- static const unsigned int snap = 32; /* snap pixel */
- static const int showbar = 1; /* 0 means no bar */
+@@ -7,15 +7,15 @@ static const int showbar = 1; /* 0 m
static const int topbar = 1; /* 0 means bottom bar */
--static const char *fonts[] = { "monospace:size=10" };
--static const char dmenufont[] = "monospace:size=10";
+ static const char *fonts[] = { "monospace:size=10" };
+ static const char dmenufont[] = "monospace:size=10";
-static const char col_gray1[] = "#222222";
-static const char col_gray2[] = "#444444";
-static const char col_gray3[] = "#bbbbbb";
-static const char col_gray4[] = "#eeeeee";
-static const char col_cyan[] = "#005577";
-+static const char *fonts[] = { "terminus:size=8" };
-+static const char dmenufont[] = "terminus:size=8";
+static const char col_gray1[] = "#202020";
+static const char col_gray2[] = "#404040";
+static const char col_gray3[] = "#c0c0c0";
Index: dmenu/Makefile
===================================================================
RCS file: /cvs/ports/x11/dmenu/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- dmenu/Makefile 31 May 2020 11:46:46 -0000 1.26
+++ dmenu/Makefile 31 May 2020 11:58:19 -0000
@@ -4,7 +4,7 @@ COMMENT= dynamic menu for X11
V= 4.9
DISTNAME= dmenu-${V}
-REVISION= 0
+REVISION= 1
CATEGORIES= x11
@@ -17,8 +17,6 @@ PERMIT_PACKAGE= Yes
WANTLIB= X11 Xft Xinerama c fontconfig
MASTER_SITES= https://dl.suckless.org/tools/
-
-RUN_DEPENDS= fonts/terminus-font
MAKE_ENV= LDFLAGS="${LDFLAGS}" \
X11INC=${X11BASE}/include \
Index: dmenu/patches/patch-config_def_h
===================================================================
RCS file: /cvs/ports/x11/dmenu/patches/patch-config_def_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-config_def_h
--- dmenu/patches/patch-config_def_h 10 May 2017 22:06:33 -0000 1.2
+++ dmenu/patches/patch-config_def_h 31 May 2020 11:58:19 -0000
@@ -1,13 +1,8 @@
$OpenBSD: patch-config_def_h,v 1.2 2017/05/10 22:06:33 jung Exp $
---- config.def.h.orig Mon May 8 19:27:54 2017
-+++ config.def.h Mon May 8 19:27:30 2017
-@@ -4,13 +4,13 @@
- static int topbar = 1; /* -b option; if 0, dmenu appears at bottom */
- /* -fn option overrides fonts[0]; default X11 font or font set */
- static const char *fonts[] = {
-- "monospace:size=10"
-+ "terminus:size=8"
- };
+Index: config.def.h
+--- config.def.h.orig
++++ config.def.h
+@@ -9,8 +9,8 @@ static const char *fonts[] = {
static const char *prompt = NULL; /* -p option; prompt to the left of input field */
static const char *colors[SchemeLast][2] = {
/* fg bg */
Re: x11/dmenu: drop fonts/terminus-font from RUN_DEPENDS
Hi Klemens,
On Sun, 31 May 2020, at 11:43, Klemens Nanni wrote:
> On Sun, May 31, 2020 at 08:27:42AM +0100, Chris Rawnsley wrote:
> > On Sun, 31 May 2020, at 04:34, Lucas wrote:
> > > fonts/terminus-font gets pulled in by x11/dmenu because of a
> > > customization > patch for look-and-feel.
> Whoever imported dmenu and dwm probably felt it was nicer, I don't know,
> but I'd say that having less dependencies is favourable; the port is
> meant to be customised anyway, so people wanting stuff like fonts can
> rather just add it.
I did some digging and it looks like it was dwm's default up until the
5.6 release. I guess it was kept around from an abundance of nostalgia.
> > I have felt this pain with x11/dwm as well.
> Either ways, those ports should be kept in sync, otherwise dmenu
> seemingly integrating with dwm's look would be off.
Agreed.
> What does "SOL" mean?
Sadly outta luck (if you want to be polite... :)
> Feedback? OK?
It looks okay to me.
On Sun, 31 May 2020, at 11:43, Klemens Nanni wrote:
> On Sun, May 31, 2020 at 08:27:42AM +0100, Chris Rawnsley wrote:
> > On Sun, 31 May 2020, at 04:34, Lucas wrote:
> > > fonts/terminus-font gets pulled in by x11/dmenu because of a
> > > customization > patch for look-and-feel.
> Whoever imported dmenu and dwm probably felt it was nicer, I don't know,
> but I'd say that having less dependencies is favourable; the port is
> meant to be customised anyway, so people wanting stuff like fonts can
> rather just add it.
I did some digging and it looks like it was dwm's default up until the
5.6 release. I guess it was kept around from an abundance of nostalgia.
> > I have felt this pain with x11/dwm as well.
> Either ways, those ports should be kept in sync, otherwise dmenu
> seemingly integrating with dwm's look would be off.
Agreed.
> What does "SOL" mean?
Sadly outta luck (if you want to be polite... :)
> Feedback? OK?
It looks okay to me.
Take maintainership of x11/dmenu and x11/dwm
Hello,
As seen in one of the recent threads in ports@, x11/dmenu and x11/dwm are looking for a maintainer. I'd like to
take on that role, as both are used pretty intensely by me and, while I don't have experience with maintaining OpenBSD
ports, I am a port maintainer for three FreeBSD ports, so the general knowledge is there. I have read faq/ports/guide.
Best regards,
Rares
As seen in one of the recent threads in ports@, x11/dmenu and x11/dwm are looking for a maintainer. I'd like to
take on that role, as both are used pretty intensely by me and, while I don't have experience with maintaining OpenBSD
ports, I am a port maintainer for three FreeBSD ports, so the general knowledge is there. I have read faq/ports/guide.
Best regards,
Rares
Re: macbook - uvideo0: can't find video interface
On May 31 12:16:58, hans@stare.cz wrote:
> Hi,
>
> On May 26 22:15:28, feinerer@logic.at wrote:
> > I think that my fix for video(1) posted at
> > https://marc.info/?l=openbsd-tech&m=159048565528060&w=2 could also
> > remedy your problem of video(1) crashing reported at
> > https://marc.info/?l=openbsd-misc&m=158800058009113&w=2 .
>
> On May 30 23:52:43, patrick@blueri.se wrote:
> > On Sat, May 30, 2020 at 07:47:17PM +0200, Jan Stary wrote:
> > > On May 30 18:50:12, hans@stare.cz wrote:
> > > > This is current/amd64 on a MacBook2,1 (dmesg below)
> > > > With the latest upgrade, it has lost video0:
> > > >
> > > > uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight" rev 2.00/1.84 addr 2
> > > > uvideo0: can't find interface assoc descriptor
> > >
> > > Similar thing happens with current/i386 on a MacBook1,1 (dmesg below):
> > > uvideo0: can't find video interface
> > >
> > > Jan
> >
> > Yeah, this is due to the change to support multiple cameras in one
> > device. You can try this diff, let me know if this works on both
> > of your machines.
>
> With Patrick's diff, my amd64 Macbook2,1 has video0 at uvideo0 again.
> I compiled the patched kernel with UVIDEO_DEBUG, dmesg below. Thanks!
On the i386 macbook, the UVIDEO_DEBUG messages spam the dmesg so much
that I only have the uvideo tail in dmesg.boot (see below).
I will recompile without UVIDEO_DEBUG.
At any rate, video0 at uvideo0 exists now - thanks.
Jan
uvideo0: send 3 bytes data to offset 0x1b
uvideo0: ucode data len=3, request=0x33
uvideo0: send 3 bytes data to offset 0x33
uvideo0: ucode data len=3, request=0x43
uvideo0: send 3 bytes data to offset 0x43
uvideo0: ucode data len=3, request=0x4b
uvideo0: send 3 bytes data to offset 0x4b
uvideo0: ucode data len=3, request=0x53
uvideo0: send 3 bytes data to offset 0x53
uvideo0: ucode data len=1023, request=0x100
uvideo0: send 50 bytes data to offset 0x100
uvideo0: send 50 bytes data to offset 0x132
uvideo0: send 50 bytes data to offset 0x164
uvideo0: send 50 bytes data to offset 0x196
uvideo0: send 50 bytes data to offset 0x1c8
uvideo0: send 50 bytes data to offset 0x1fa
uvideo0: send 50 bytes data to offset 0x22c
uvideo0: send 50 bytes data to offset 0x25e
uvideo0: send 50 bytes data to offset 0x290
uvideo0: send 50 bytes data to offset 0x2c2
uvideo0: send 50 bytes data to offset 0x2f4
uvideo0: send 50 bytes data to offset 0x326
uvideo0: send 50 bytes data to offset 0x358
uvideo0: send 50 bytes data to offset 0x38a
uvideo0: send 50 bytes data to offset 0x3bc
uvideo0: send 50 bytes data to offset 0x3ee
uvideo0: send 50 bytes data to offset 0x420
uvideo0: send 50 bytes data to offset 0x452
uvideo0: send 50 bytes data to offset 0x484
uvideo0: send 50 bytes data to offset 0x4b6
uvideo0: send 23 bytes data to offset 0x4e8
uvideo0: ucode data len=1023, request=0x4ff
uvideo0: send 50 bytes data to offset 0x4ff
uvideo0: send 50 bytes data to offset 0x531
uvideo0: send 50 bytes data to offset 0x563
uvideo0: send 50 bytes data to offset 0x595
uvideo0: send 50 bytes data to offset 0x5c7
uvideo0: send 50 bytes data to offset 0x5f9
uvideo0: send 50 bytes data to offset 0x62b
uvideo0: send 50 bytes data to offset 0x65d
uvideo0: send 50 bytes data to offset 0x68f
uvideo0: send 50 bytes data to offset 0x6c1
uvideo0: send 50 bytes data to offset 0x6f3
uvideo0: send 50 bytes data to offset 0x725
uvideo0: send 50 bytes data to offset 0x757
uvideo0: send 50 bytes data to offset 0x789
uvideo0: send 50 bytes data to offset 0x7bb
uvideo0: send 50 bytes data to offset 0x7ed
uvideo0: send 50 bytes data to offset 0x81f
uvideo0: send 50 bytes data to offset 0x851
uvideo0: send 50 bytes data to offset 0x883
uvideo0: send 50 bytes data to offset 0x8b5
uvideo0: send 23 bytes data to offset 0x8e7
uvideo0: ucode data len=1023, request=0x8fe
uvideo0: send 50 bytes data to offset 0x8fe
uvideo0: send 50 bytes data to offset 0x930
uvideo0: send 50 bytes data to offset 0x962
uvideo0: send 50 bytes data to offset 0x994
uvideo0: send 50 bytes data to offset 0x9c6
uvideo0: send 50 bytes data to offset 0x9f8
uvideo0: send 50 bytes data to offset 0xa2a
uvideo0: send 50 bytes data to offset 0xa5c
uvideo0: send 50 bytes data to offset 0xa8e
uvideo0: send 50 bytes data to offset 0xac0
uvideo0: send 50 bytes data to offset 0xaf2
uvideo0: send 50 bytes data to offset 0xb24
uvideo0: send 50 bytes data to offset 0xb56
uvideo0: send 50 bytes data to offset 0xb88
uvideo0: send 50 bytes data to offset 0xbba
uvideo0: send 50 bytes data to offset 0xbec
uvideo0: send 50 bytes data to offset 0xc1e
uvideo0: send 50 bytes data to offset 0xc50
uvideo0: send 50 bytes data to offset 0xc82
uvideo0: send 50 bytes data to offset 0xcb4
uvideo0: send 23 bytes data to offset 0xce6
uvideo0: ucode data len=1023, request=0xcfd
uvideo0: send 50 bytes data to offset 0xcfd
uvideo0: send 50 bytes data to offset 0xd2f
uvideo0: send 50 bytes data to offset 0xd61
uvideo0: send 50 bytes data to offset 0xd93
uvideo0: send 50 bytes data to offset 0xdc5
uvideo0: send 50 bytes data to offset 0xdf7
uvideo0: send 50 bytes data to offset 0xe29
uvideo0: send 50 bytes data to offset 0xe5b
uvideo0: send 50 bytes data to offset 0xe8d
uvideo0: send 50 bytes data to offset 0xebf
uvideo0: send 50 bytes data to offset 0xef1
uvideo0: send 50 bytes data to offset 0xf23
uvideo0: send 50 bytes data to offset 0xf55
uvideo0: send 50 bytes data to offset 0xf87
uvideo0: send 50 bytes data to offset 0xfb9
uvideo0: send 50 bytes data to offset 0xfeb
uvideo0: send 50 bytes data to offset 0x101d
uvideo0: send 50 bytes data to offset 0x104f
uvideo0: send 50 bytes data to offset 0x1081
uvideo0: send 50 bytes data to offset 0x10b3
uvideo0: send 23 bytes data to offset 0x10e5
uvideo0: ucode data len=1023, request=0x10fc
uvideo0: send 50 bytes data to offset 0x10fc
uvideo0: send 50 bytes data to offset 0x112e
uvideo0: send 50 bytes data to offset 0x1160
uvideo0: send 50 bytes data to offset 0x1192
uvideo0: send 50 bytes data to offset 0x11c4
uvideo0: send 50 bytes data to offset 0x11f6
uvideo0: send 50 bytes data to offset 0x1228
uvideo0: send 50 bytes data to offset 0x125a
uvideo0: send 50 bytes data to offset 0x128c
uvideo0: send 50 bytes data to offset 0x12be
uvideo0: send 50 bytes data to offset 0x12f0
uvideo0: send 50 bytes data to offset 0x1322
uvideo0: send 50 bytes data to offset 0x1354
uvideo0: send 50 bytes data to offset 0x1386
uvideo0: send 50 bytes data to offset 0x13b8
uvideo0: send 50 bytes data to offset 0x13ea
uvideo0: send 50 bytes data to offset 0x141c
uvideo0: send 50 bytes data to offset 0x144e
uvideo0: send 50 bytes data to offset 0x1480
uvideo0: send 50 bytes data to offset 0x14b2
uvideo0: send 23 bytes data to offset 0x14e4
uvideo0: ucode data len=1023, request=0x14fb
uvideo0: send 50 bytes data to offset 0x14fb
uvideo0: send 50 bytes data to offset 0x152d
uvideo0: send 50 bytes data to offset 0x155f
uvideo0: send 50 bytes data to offset 0x1591
uvideo0: send 50 bytes data to offset 0x15c3
uvideo0: send 50 bytes data to offset 0x15f5
uvideo0: send 50 bytes data to offset 0x1627
uvideo0: send 50 bytes data to offset 0x1659
uvideo0: send 50 bytes data to offset 0x168b
uvideo0: send 50 bytes data to offset 0x16bd
uvideo0: send 50 bytes data to offset 0x16ef
uvideo0: send 50 bytes data to offset 0x1721
uvideo0: send 50 bytes data to offset 0x1753
uvideo0: send 50 bytes data to offset 0x1785
uvideo0: send 50 bytes data to offset 0x17b7
uvideo0: send 50 bytes data to offset 0x17e9
uvideo0: send 50 bytes data to offset 0x181b
uvideo0: send 50 bytes data to offset 0x184d
uvideo0: send 50 bytes data to offset 0x187f
uvideo0: send 50 bytes data to offset 0x18b1
uvideo0: send 23 bytes data to offset 0x18e3
uvideo0: ucode data len=1023, request=0x18fa
uvideo0: send 50 bytes data to offset 0x18fa
uvideo0: send 50 bytes data to offset 0x192c
uvideo0: send 50 bytes data to offset 0x195e
uvideo0: send 50 bytes data to offset 0x1990
uvideo0: send 50 bytes data to offset 0x19c2
uvideo0: send 50 bytes data to offset 0x19f4
uvideo0: send 50 bytes data to offset 0x1a26
uvideo0: send 50 bytes data to offset 0x1a58
uvideo0: send 50 bytes data to offset 0x1a8a
uvideo0: send 50 bytes data to offset 0x1abc
uvideo0: send 50 bytes data to offset 0x1aee
uvideo0: send 50 bytes data to offset 0x1b20
uvideo0: send 50 bytes data to offset 0x1b52
uvideo0: send 50 bytes data to offset 0x1b84
uvideo0: send 50 bytes data to offset 0x1bb6
uvideo0: send 50 bytes data to offset 0x1be8
uvideo0: send 50 bytes data to offset 0x1c1a
uvideo0: send 50 bytes data to offset 0x1c4c
uvideo0: send 50 bytes data to offset 0x1c7e
uvideo0: send 50 bytes data to offset 0x1cb0
uvideo0: send 23 bytes data to offset 0x1ce2
uvideo0: ucode data len=1023, request=0x1cf9
uvideo0: send 50 bytes data to offset 0x1cf9
uvideo0: send 50 bytes data to offset 0x1d2b
uvideo0: send 50 bytes data to offset 0x1d5d
uvideo0: send 50 bytes data to offset 0x1d8f
uvideo0: send 50 bytes data to offset 0x1dc1
uvideo0: send 50 bytes data to offset 0x1df3
uvideo0: send 50 bytes data to offset 0x1e25
uvideo0: send 50 bytes data to offset 0x1e57
uvideo0: send 50 bytes data to offset 0x1e89
uvideo0: send 50 bytes data to offset 0x1ebb
uvideo0: send 50 bytes data to offset 0x1eed
uvideo0: send 50 bytes data to offset 0x1f1f
uvideo0: send 50 bytes data to offset 0x1f51
uvideo0: send 50 bytes data to offset 0x1f83
uvideo0: send 50 bytes data to offset 0x1fb5
uvideo0: send 50 bytes data to offset 0x1fe7
uvideo0: send 50 bytes data to offset 0x2019
uvideo0: send 50 bytes data to offset 0x204b
uvideo0: send 50 bytes data to offset 0x207d
uvideo0: send 50 bytes data to offset 0x20af
uvideo0: send 23 bytes data to offset 0x20e1
uvideo0: ucode data len=1023, request=0x20f8
uvideo0: send 50 bytes data to offset 0x20f8
uvideo0: send 50 bytes data to offset 0x212a
uvideo0: send 50 bytes data to offset 0x215c
uvideo0: send 50 bytes data to offset 0x218e
uvideo0: send 50 bytes data to offset 0x21c0
uvideo0: send 50 bytes data to offset 0x21f2
uvideo0: send 50 bytes data to offset 0x2224
uvideo0: send 50 bytes data to offset 0x2256
uvideo0: send 50 bytes data to offset 0x2288
uvideo0: send 50 bytes data to offset 0x22ba
uvideo0: send 50 bytes data to offset 0x22ec
uvideo0: send 50 bytes data to offset 0x231e
uvideo0: send 50 bytes data to offset 0x2350
uvideo0: send 50 bytes data to offset 0x2382
uvideo0: send 50 bytes data to offset 0x23b4
uvideo0: send 50 bytes data to offset 0x23e6
uvideo0: send 50 bytes data to offset 0x2418
uvideo0: send 50 bytes data to offset 0x244a
uvideo0: send 50 bytes data to offset 0x247c
uvideo0: send 50 bytes data to offset 0x24ae
uvideo0: send 23 bytes data to offset 0x24e0
uvideo0: ucode data len=1023, request=0x24f7
uvideo0: send 50 bytes data to offset 0x24f7
uvideo0: send 50 bytes data to offset 0x2529
uvideo0: send 50 bytes data to offset 0x255b
uvideo0: send 50 bytes data to offset 0x258d
uvideo0: send 50 bytes data to offset 0x25bf
uvideo0: send 50 bytes data to offset 0x25f1
uvideo0: send 50 bytes data to offset 0x2623
uvideo0: send 50 bytes data to offset 0x2655
uvideo0: send 50 bytes data to offset 0x2687
uvideo0: send 50 bytes data to offset 0x26b9
uvideo0: send 50 bytes data to offset 0x26eb
uvideo0: send 50 bytes data to offset 0x271d
uvideo0: send 50 bytes data to offset 0x274f
uvideo0: send 50 bytes data to offset 0x2781
uvideo0: send 50 bytes data to offset 0x27b3
uvideo0: send 50 bytes data to offset 0x27e5
uvideo0: send 50 bytes data to offset 0x2817
uvideo0: send 50 bytes data to offset 0x2849
uvideo0: send 50 bytes data to offset 0x287b
uvideo0: send 50 bytes data to offset 0x28ad
uvideo0: send 23 bytes data to offset 0x28df
uvideo0: ucode data len=555, request=0x28f6
uvideo0: send 50 bytes data to offset 0x28f6
uvideo0: send 50 bytes data to offset 0x2928
uvideo0: send 50 bytes data to offset 0x295a
uvideo0: send 50 bytes data to offset 0x298c
uvideo0: send 50 bytes data to offset 0x29be
uvideo0: send 50 bytes data to offset 0x29f0
uvideo0: send 50 bytes data to offset 0x2a22
uvideo0: send 50 bytes data to offset 0x2a54
uvideo0: send 50 bytes data to offset 0x2a86
uvideo0: send 50 bytes data to offset 0x2ab8
uvideo0: send 50 bytes data to offset 0x2aea
uvideo0: send 5 bytes data to offset 0x2b1c
uvideo0: ucode activated
uvideo0 detached
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight" rev 2.00/1.84 addr 2
bLength=9
bDescriptorType=0x02 (UDESC_CONFIG)
|
bLength=9
bDescriptorType=0x02
wTotalLength=267
bNumInterface=0x02
bConfigurationValue=0x01
iConfiguration=0x00
bmAttributes=0x80
bMaxPower=0x32
bLength=8
bDescriptorType=0x24 (CS_INTERFACE)
bLength=9
bDescriptorType=0x04 (UDESC_INTERFACE)
|
bLength=9
bDescriptorType=0x04
bInterfaceNumber=0x00
bAlternateSetting=0x00
bNumEndpoints=1
bInterfaceClass=0x0e
bInterfaceSubClass=0x01
bInterfaceProtocol=0x00
iInterface=0x00
bLength=13
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x01 (UDESCSUB_VC_HEADER)
|
bLength=13
bDescriptorType=0x24
bDescriptorSubtype=0x01
bcdUVC=0x0100
wTotalLength=49
dwClockFrequency=13500000
bInCollection=0x01
bLength=16
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x02 (UDESCSUB_VC_INPUT_TERMINAL)
|
bLength=16
bDescriptorType=0x24
bDescriptorSubtype=0x02
bTerminalID=0x01
wTerminalType=0x0201
bAssocTerminal=0x00
iTerminal=0x00
bLength=11
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x05 (UDESCSUB_VC_PROCESSING_UNIT)
|
bLength=11
bDescriptorType=0x24
bDescriptorSubtype=0x05
bUnitID=0x02
bSourceID=0x01
wMaxMultiplier=0
bControlSize=2
bmControls=0x3900
iProcessing=0x00
bmVideoStandards=0x09
bLength=9
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x03 (UDESCSUB_VC_OUTPUT)
|
bLength=9
bDescriptorType=0x24
bDescriptorSubtype=0x03
bTerminalID=0x03
bAssocTerminal=0x00
bSourceID=0x02
iTerminal=0x00
bLength=7
bDescriptorType=0x05 (UDESC_ENDPOINT)
|
bLength=7
bDescriptorType=0x05
bEndpointAddress=0x81 (IN)
bmAttributes=0x03 (UE_INTERRUPT)
wMaxPacketSize=8
bInterval=0x0a
bLength=5
bDescriptorType=0x25 (UDESC_CS_ENDPOINT)
bDescriptorSubtype=0x03 (EP_INTERRUPT)
|
bLength=5
bDescriptorType=0x25
bDescriptorSubtype=0x03
wMaxTransferSize=16
bLength=9
bDescriptorType=0x04 (UDESC_INTERFACE)
|
bLength=9
bDescriptorType=0x04
bInterfaceNumber=0x01
bAlternateSetting=0x00
bNumEndpoints=0
bInterfaceClass=0x0e
bInterfaceSubClass=0x02
bInterfaceProtocol=0x00
iInterface=0x00
bLength=14
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x01 (UDESCSUB_VS_INPUT_HEADER)
|
bLength=14
bDescriptorType=0x24
bDescriptorSubtype=0x01
bNumFormats=1
wTotalLength=155
bEndpointAddress=0x82
bmInfo=0x00
bTerminalLink=0x03
bStillCaptureMethod=0x00
bTriggerSupport=0x00
bTriggerUsage=0x00
bControlSize=1
bLength=27
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x04 (UDESCSUB_VS_FORMAT_UNCOMPRESSED)
bLength=27
bDescriptorType=0x24
bDescriptorSubtype=0x04
bFormatIndex=0x01
bNumFrameDescriptors=0x03
guidFormat=UYVY
bBitsPerPixel=0x10
bDefaultFrameIndex=0x01
bAspectRatioX=0x00
bAspectRatioY=0x00
bmInterlaceFlags=0x00
bCopyProtect=0x00
bLength=38
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x05 (UDESCSUB_VS_FRAME_UNCOMPRESSED)
bLength=38
bDescriptorType=0x24
bDescriptorSubtype=0x05
bFrameIndex=0x01
bmCapabilities=0x00
wWidth=640
wHeight=480
dwMinBitRate=383976960
dwMaxBitRate=383976960
dwMaxVideoFrameBufferSize=614400
dwDefaultFrameInterval=333333
bFrameIntervalType=0x00
dwMinFrameInterval = 333333
dwMaxFrameInterval = 333333
dwFrameIntervalStep = 0
bLength=38
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x05 (UDESCSUB_VS_FRAME_UNCOMPRESSED)
bLength=38
bDescriptorType=0x24
bDescriptorSubtype=0x05
bFrameIndex=0x02
bmCapabilities=0x00
wWidth=352
wHeight=288
dwMinBitRate=383976960
dwMaxBitRate=383976960
dwMaxVideoFrameBufferSize=202752
dwDefaultFrameInterval=333333
bFrameIntervalType=0x00
dwMinFrameInterval = 333333
dwMaxFrameInterval = 333333
dwFrameIntervalStep = 0
bLength=38
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x05 (UDESCSUB_VS_FRAME_UNCOMPRESSED)
bLength=38
bDescriptorType=0x24
bDescriptorSubtype=0x05
bFrameIndex=0x03
bmCapabilities=0x00
wWidth=320
wHeight=240
dwMinBitRate=383976960
dwMaxBitRate=383976960
dwMaxVideoFrameBufferSize=153600
dwDefaultFrameInterval=333333
bFrameIntervalType=0x00
dwMinFrameInterval = 333333
dwMaxFrameInterval = 333333
dwFrameIntervalStep = 0
bLength=9
bDescriptorType=0x04 (UDESC_INTERFACE)
|
bLength=9
bDescriptorType=0x04
bInterfaceNumber=0x01
bAlternateSetting=0x01
bNumEndpoints=1
bInterfaceClass=0x0e
bInterfaceSubClass=0x02
bInterfaceProtocol=0x00
iInterface=0x00
bLength=7
bDescriptorType=0x05 (UDESC_ENDPOINT)
|
bLength=7
bDescriptorType=0x05
bEndpointAddress=0x82 (IN)
bmAttributes=0x05 (UE_ISOCHRONOUS, UE_ISO_ASYNC)
wMaxPacketSize=5120
bInterval=0x01
uvideo0: uvideo_vc_parse_desc
uvideo0: number of total interfaces=2
uvideo0: number of VS interfaces=1
uvideo0: uvideo_vs_parse_desc_format
uvideo0: number of total format descriptors=1
uvideo0: uvideo_vs_parse_desc_frame
uvideo0: VS interface 0, bInterfaceNumber=0x01, numalts=2
uvideo0: bAlternateSetting=0x00, no endpoint descriptor
uvideo0: bAlternateSetting=0x01, bEndpointAddress=0x82, wMaxPacketSize=5120
uvideo0: SET probe request successfully
bmHint=0x01
bFormatIndex=0x01
bFrameIndex=0x01
dwFrameInterval=333333 (100ns units)
wKeyFrameRate=0
wPFrameRate=0
wCompQuality=0
wCompWindowSize=0
wDelay=0 (ms)
dwMaxVideoFrameSize=0 (bytes)
dwMaxPayloadTransferSize=0 (bytes)
uvideo0: GET probe request successfully
bmHint=0x00
bFormatIndex=0x01
bFrameIndex=0x01
dwFrameInterval=333333 (100ns units)
wKeyFrameRate=0
wPFrameRate=0
wCompQuality=0
wCompWindowSize=0
wDelay=33 (ms)
dwMaxVideoFrameSize=614400 (bytes)
dwMaxPayloadTransferSize=3072 (bytes)
fixed dwMaxVideoFrameSize=614400, width=640 height=480 bpp=16
uvideo_attach: doing video_attach_mi
video0 at uvideo0
> Hi,
>
> On May 26 22:15:28, feinerer@logic.at wrote:
> > I think that my fix for video(1) posted at
> > https://marc.info/?l=openbsd-tech&m=159048565528060&w=2 could also
> > remedy your problem of video(1) crashing reported at
> > https://marc.info/?l=openbsd-misc&m=158800058009113&w=2 .
>
> On May 30 23:52:43, patrick@blueri.se wrote:
> > On Sat, May 30, 2020 at 07:47:17PM +0200, Jan Stary wrote:
> > > On May 30 18:50:12, hans@stare.cz wrote:
> > > > This is current/amd64 on a MacBook2,1 (dmesg below)
> > > > With the latest upgrade, it has lost video0:
> > > >
> > > > uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight" rev 2.00/1.84 addr 2
> > > > uvideo0: can't find interface assoc descriptor
> > >
> > > Similar thing happens with current/i386 on a MacBook1,1 (dmesg below):
> > > uvideo0: can't find video interface
> > >
> > > Jan
> >
> > Yeah, this is due to the change to support multiple cameras in one
> > device. You can try this diff, let me know if this works on both
> > of your machines.
>
> With Patrick's diff, my amd64 Macbook2,1 has video0 at uvideo0 again.
> I compiled the patched kernel with UVIDEO_DEBUG, dmesg below. Thanks!
On the i386 macbook, the UVIDEO_DEBUG messages spam the dmesg so much
that I only have the uvideo tail in dmesg.boot (see below).
I will recompile without UVIDEO_DEBUG.
At any rate, video0 at uvideo0 exists now - thanks.
Jan
uvideo0: send 3 bytes data to offset 0x1b
uvideo0: ucode data len=3, request=0x33
uvideo0: send 3 bytes data to offset 0x33
uvideo0: ucode data len=3, request=0x43
uvideo0: send 3 bytes data to offset 0x43
uvideo0: ucode data len=3, request=0x4b
uvideo0: send 3 bytes data to offset 0x4b
uvideo0: ucode data len=3, request=0x53
uvideo0: send 3 bytes data to offset 0x53
uvideo0: ucode data len=1023, request=0x100
uvideo0: send 50 bytes data to offset 0x100
uvideo0: send 50 bytes data to offset 0x132
uvideo0: send 50 bytes data to offset 0x164
uvideo0: send 50 bytes data to offset 0x196
uvideo0: send 50 bytes data to offset 0x1c8
uvideo0: send 50 bytes data to offset 0x1fa
uvideo0: send 50 bytes data to offset 0x22c
uvideo0: send 50 bytes data to offset 0x25e
uvideo0: send 50 bytes data to offset 0x290
uvideo0: send 50 bytes data to offset 0x2c2
uvideo0: send 50 bytes data to offset 0x2f4
uvideo0: send 50 bytes data to offset 0x326
uvideo0: send 50 bytes data to offset 0x358
uvideo0: send 50 bytes data to offset 0x38a
uvideo0: send 50 bytes data to offset 0x3bc
uvideo0: send 50 bytes data to offset 0x3ee
uvideo0: send 50 bytes data to offset 0x420
uvideo0: send 50 bytes data to offset 0x452
uvideo0: send 50 bytes data to offset 0x484
uvideo0: send 50 bytes data to offset 0x4b6
uvideo0: send 23 bytes data to offset 0x4e8
uvideo0: ucode data len=1023, request=0x4ff
uvideo0: send 50 bytes data to offset 0x4ff
uvideo0: send 50 bytes data to offset 0x531
uvideo0: send 50 bytes data to offset 0x563
uvideo0: send 50 bytes data to offset 0x595
uvideo0: send 50 bytes data to offset 0x5c7
uvideo0: send 50 bytes data to offset 0x5f9
uvideo0: send 50 bytes data to offset 0x62b
uvideo0: send 50 bytes data to offset 0x65d
uvideo0: send 50 bytes data to offset 0x68f
uvideo0: send 50 bytes data to offset 0x6c1
uvideo0: send 50 bytes data to offset 0x6f3
uvideo0: send 50 bytes data to offset 0x725
uvideo0: send 50 bytes data to offset 0x757
uvideo0: send 50 bytes data to offset 0x789
uvideo0: send 50 bytes data to offset 0x7bb
uvideo0: send 50 bytes data to offset 0x7ed
uvideo0: send 50 bytes data to offset 0x81f
uvideo0: send 50 bytes data to offset 0x851
uvideo0: send 50 bytes data to offset 0x883
uvideo0: send 50 bytes data to offset 0x8b5
uvideo0: send 23 bytes data to offset 0x8e7
uvideo0: ucode data len=1023, request=0x8fe
uvideo0: send 50 bytes data to offset 0x8fe
uvideo0: send 50 bytes data to offset 0x930
uvideo0: send 50 bytes data to offset 0x962
uvideo0: send 50 bytes data to offset 0x994
uvideo0: send 50 bytes data to offset 0x9c6
uvideo0: send 50 bytes data to offset 0x9f8
uvideo0: send 50 bytes data to offset 0xa2a
uvideo0: send 50 bytes data to offset 0xa5c
uvideo0: send 50 bytes data to offset 0xa8e
uvideo0: send 50 bytes data to offset 0xac0
uvideo0: send 50 bytes data to offset 0xaf2
uvideo0: send 50 bytes data to offset 0xb24
uvideo0: send 50 bytes data to offset 0xb56
uvideo0: send 50 bytes data to offset 0xb88
uvideo0: send 50 bytes data to offset 0xbba
uvideo0: send 50 bytes data to offset 0xbec
uvideo0: send 50 bytes data to offset 0xc1e
uvideo0: send 50 bytes data to offset 0xc50
uvideo0: send 50 bytes data to offset 0xc82
uvideo0: send 50 bytes data to offset 0xcb4
uvideo0: send 23 bytes data to offset 0xce6
uvideo0: ucode data len=1023, request=0xcfd
uvideo0: send 50 bytes data to offset 0xcfd
uvideo0: send 50 bytes data to offset 0xd2f
uvideo0: send 50 bytes data to offset 0xd61
uvideo0: send 50 bytes data to offset 0xd93
uvideo0: send 50 bytes data to offset 0xdc5
uvideo0: send 50 bytes data to offset 0xdf7
uvideo0: send 50 bytes data to offset 0xe29
uvideo0: send 50 bytes data to offset 0xe5b
uvideo0: send 50 bytes data to offset 0xe8d
uvideo0: send 50 bytes data to offset 0xebf
uvideo0: send 50 bytes data to offset 0xef1
uvideo0: send 50 bytes data to offset 0xf23
uvideo0: send 50 bytes data to offset 0xf55
uvideo0: send 50 bytes data to offset 0xf87
uvideo0: send 50 bytes data to offset 0xfb9
uvideo0: send 50 bytes data to offset 0xfeb
uvideo0: send 50 bytes data to offset 0x101d
uvideo0: send 50 bytes data to offset 0x104f
uvideo0: send 50 bytes data to offset 0x1081
uvideo0: send 50 bytes data to offset 0x10b3
uvideo0: send 23 bytes data to offset 0x10e5
uvideo0: ucode data len=1023, request=0x10fc
uvideo0: send 50 bytes data to offset 0x10fc
uvideo0: send 50 bytes data to offset 0x112e
uvideo0: send 50 bytes data to offset 0x1160
uvideo0: send 50 bytes data to offset 0x1192
uvideo0: send 50 bytes data to offset 0x11c4
uvideo0: send 50 bytes data to offset 0x11f6
uvideo0: send 50 bytes data to offset 0x1228
uvideo0: send 50 bytes data to offset 0x125a
uvideo0: send 50 bytes data to offset 0x128c
uvideo0: send 50 bytes data to offset 0x12be
uvideo0: send 50 bytes data to offset 0x12f0
uvideo0: send 50 bytes data to offset 0x1322
uvideo0: send 50 bytes data to offset 0x1354
uvideo0: send 50 bytes data to offset 0x1386
uvideo0: send 50 bytes data to offset 0x13b8
uvideo0: send 50 bytes data to offset 0x13ea
uvideo0: send 50 bytes data to offset 0x141c
uvideo0: send 50 bytes data to offset 0x144e
uvideo0: send 50 bytes data to offset 0x1480
uvideo0: send 50 bytes data to offset 0x14b2
uvideo0: send 23 bytes data to offset 0x14e4
uvideo0: ucode data len=1023, request=0x14fb
uvideo0: send 50 bytes data to offset 0x14fb
uvideo0: send 50 bytes data to offset 0x152d
uvideo0: send 50 bytes data to offset 0x155f
uvideo0: send 50 bytes data to offset 0x1591
uvideo0: send 50 bytes data to offset 0x15c3
uvideo0: send 50 bytes data to offset 0x15f5
uvideo0: send 50 bytes data to offset 0x1627
uvideo0: send 50 bytes data to offset 0x1659
uvideo0: send 50 bytes data to offset 0x168b
uvideo0: send 50 bytes data to offset 0x16bd
uvideo0: send 50 bytes data to offset 0x16ef
uvideo0: send 50 bytes data to offset 0x1721
uvideo0: send 50 bytes data to offset 0x1753
uvideo0: send 50 bytes data to offset 0x1785
uvideo0: send 50 bytes data to offset 0x17b7
uvideo0: send 50 bytes data to offset 0x17e9
uvideo0: send 50 bytes data to offset 0x181b
uvideo0: send 50 bytes data to offset 0x184d
uvideo0: send 50 bytes data to offset 0x187f
uvideo0: send 50 bytes data to offset 0x18b1
uvideo0: send 23 bytes data to offset 0x18e3
uvideo0: ucode data len=1023, request=0x18fa
uvideo0: send 50 bytes data to offset 0x18fa
uvideo0: send 50 bytes data to offset 0x192c
uvideo0: send 50 bytes data to offset 0x195e
uvideo0: send 50 bytes data to offset 0x1990
uvideo0: send 50 bytes data to offset 0x19c2
uvideo0: send 50 bytes data to offset 0x19f4
uvideo0: send 50 bytes data to offset 0x1a26
uvideo0: send 50 bytes data to offset 0x1a58
uvideo0: send 50 bytes data to offset 0x1a8a
uvideo0: send 50 bytes data to offset 0x1abc
uvideo0: send 50 bytes data to offset 0x1aee
uvideo0: send 50 bytes data to offset 0x1b20
uvideo0: send 50 bytes data to offset 0x1b52
uvideo0: send 50 bytes data to offset 0x1b84
uvideo0: send 50 bytes data to offset 0x1bb6
uvideo0: send 50 bytes data to offset 0x1be8
uvideo0: send 50 bytes data to offset 0x1c1a
uvideo0: send 50 bytes data to offset 0x1c4c
uvideo0: send 50 bytes data to offset 0x1c7e
uvideo0: send 50 bytes data to offset 0x1cb0
uvideo0: send 23 bytes data to offset 0x1ce2
uvideo0: ucode data len=1023, request=0x1cf9
uvideo0: send 50 bytes data to offset 0x1cf9
uvideo0: send 50 bytes data to offset 0x1d2b
uvideo0: send 50 bytes data to offset 0x1d5d
uvideo0: send 50 bytes data to offset 0x1d8f
uvideo0: send 50 bytes data to offset 0x1dc1
uvideo0: send 50 bytes data to offset 0x1df3
uvideo0: send 50 bytes data to offset 0x1e25
uvideo0: send 50 bytes data to offset 0x1e57
uvideo0: send 50 bytes data to offset 0x1e89
uvideo0: send 50 bytes data to offset 0x1ebb
uvideo0: send 50 bytes data to offset 0x1eed
uvideo0: send 50 bytes data to offset 0x1f1f
uvideo0: send 50 bytes data to offset 0x1f51
uvideo0: send 50 bytes data to offset 0x1f83
uvideo0: send 50 bytes data to offset 0x1fb5
uvideo0: send 50 bytes data to offset 0x1fe7
uvideo0: send 50 bytes data to offset 0x2019
uvideo0: send 50 bytes data to offset 0x204b
uvideo0: send 50 bytes data to offset 0x207d
uvideo0: send 50 bytes data to offset 0x20af
uvideo0: send 23 bytes data to offset 0x20e1
uvideo0: ucode data len=1023, request=0x20f8
uvideo0: send 50 bytes data to offset 0x20f8
uvideo0: send 50 bytes data to offset 0x212a
uvideo0: send 50 bytes data to offset 0x215c
uvideo0: send 50 bytes data to offset 0x218e
uvideo0: send 50 bytes data to offset 0x21c0
uvideo0: send 50 bytes data to offset 0x21f2
uvideo0: send 50 bytes data to offset 0x2224
uvideo0: send 50 bytes data to offset 0x2256
uvideo0: send 50 bytes data to offset 0x2288
uvideo0: send 50 bytes data to offset 0x22ba
uvideo0: send 50 bytes data to offset 0x22ec
uvideo0: send 50 bytes data to offset 0x231e
uvideo0: send 50 bytes data to offset 0x2350
uvideo0: send 50 bytes data to offset 0x2382
uvideo0: send 50 bytes data to offset 0x23b4
uvideo0: send 50 bytes data to offset 0x23e6
uvideo0: send 50 bytes data to offset 0x2418
uvideo0: send 50 bytes data to offset 0x244a
uvideo0: send 50 bytes data to offset 0x247c
uvideo0: send 50 bytes data to offset 0x24ae
uvideo0: send 23 bytes data to offset 0x24e0
uvideo0: ucode data len=1023, request=0x24f7
uvideo0: send 50 bytes data to offset 0x24f7
uvideo0: send 50 bytes data to offset 0x2529
uvideo0: send 50 bytes data to offset 0x255b
uvideo0: send 50 bytes data to offset 0x258d
uvideo0: send 50 bytes data to offset 0x25bf
uvideo0: send 50 bytes data to offset 0x25f1
uvideo0: send 50 bytes data to offset 0x2623
uvideo0: send 50 bytes data to offset 0x2655
uvideo0: send 50 bytes data to offset 0x2687
uvideo0: send 50 bytes data to offset 0x26b9
uvideo0: send 50 bytes data to offset 0x26eb
uvideo0: send 50 bytes data to offset 0x271d
uvideo0: send 50 bytes data to offset 0x274f
uvideo0: send 50 bytes data to offset 0x2781
uvideo0: send 50 bytes data to offset 0x27b3
uvideo0: send 50 bytes data to offset 0x27e5
uvideo0: send 50 bytes data to offset 0x2817
uvideo0: send 50 bytes data to offset 0x2849
uvideo0: send 50 bytes data to offset 0x287b
uvideo0: send 50 bytes data to offset 0x28ad
uvideo0: send 23 bytes data to offset 0x28df
uvideo0: ucode data len=555, request=0x28f6
uvideo0: send 50 bytes data to offset 0x28f6
uvideo0: send 50 bytes data to offset 0x2928
uvideo0: send 50 bytes data to offset 0x295a
uvideo0: send 50 bytes data to offset 0x298c
uvideo0: send 50 bytes data to offset 0x29be
uvideo0: send 50 bytes data to offset 0x29f0
uvideo0: send 50 bytes data to offset 0x2a22
uvideo0: send 50 bytes data to offset 0x2a54
uvideo0: send 50 bytes data to offset 0x2a86
uvideo0: send 50 bytes data to offset 0x2ab8
uvideo0: send 50 bytes data to offset 0x2aea
uvideo0: send 5 bytes data to offset 0x2b1c
uvideo0: ucode activated
uvideo0 detached
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight" rev 2.00/1.84 addr 2
bLength=9
bDescriptorType=0x02 (UDESC_CONFIG)
|
bLength=9
bDescriptorType=0x02
wTotalLength=267
bNumInterface=0x02
bConfigurationValue=0x01
iConfiguration=0x00
bmAttributes=0x80
bMaxPower=0x32
bLength=8
bDescriptorType=0x24 (CS_INTERFACE)
bLength=9
bDescriptorType=0x04 (UDESC_INTERFACE)
|
bLength=9
bDescriptorType=0x04
bInterfaceNumber=0x00
bAlternateSetting=0x00
bNumEndpoints=1
bInterfaceClass=0x0e
bInterfaceSubClass=0x01
bInterfaceProtocol=0x00
iInterface=0x00
bLength=13
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x01 (UDESCSUB_VC_HEADER)
|
bLength=13
bDescriptorType=0x24
bDescriptorSubtype=0x01
bcdUVC=0x0100
wTotalLength=49
dwClockFrequency=13500000
bInCollection=0x01
bLength=16
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x02 (UDESCSUB_VC_INPUT_TERMINAL)
|
bLength=16
bDescriptorType=0x24
bDescriptorSubtype=0x02
bTerminalID=0x01
wTerminalType=0x0201
bAssocTerminal=0x00
iTerminal=0x00
bLength=11
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x05 (UDESCSUB_VC_PROCESSING_UNIT)
|
bLength=11
bDescriptorType=0x24
bDescriptorSubtype=0x05
bUnitID=0x02
bSourceID=0x01
wMaxMultiplier=0
bControlSize=2
bmControls=0x3900
iProcessing=0x00
bmVideoStandards=0x09
bLength=9
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x03 (UDESCSUB_VC_OUTPUT)
|
bLength=9
bDescriptorType=0x24
bDescriptorSubtype=0x03
bTerminalID=0x03
bAssocTerminal=0x00
bSourceID=0x02
iTerminal=0x00
bLength=7
bDescriptorType=0x05 (UDESC_ENDPOINT)
|
bLength=7
bDescriptorType=0x05
bEndpointAddress=0x81 (IN)
bmAttributes=0x03 (UE_INTERRUPT)
wMaxPacketSize=8
bInterval=0x0a
bLength=5
bDescriptorType=0x25 (UDESC_CS_ENDPOINT)
bDescriptorSubtype=0x03 (EP_INTERRUPT)
|
bLength=5
bDescriptorType=0x25
bDescriptorSubtype=0x03
wMaxTransferSize=16
bLength=9
bDescriptorType=0x04 (UDESC_INTERFACE)
|
bLength=9
bDescriptorType=0x04
bInterfaceNumber=0x01
bAlternateSetting=0x00
bNumEndpoints=0
bInterfaceClass=0x0e
bInterfaceSubClass=0x02
bInterfaceProtocol=0x00
iInterface=0x00
bLength=14
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x01 (UDESCSUB_VS_INPUT_HEADER)
|
bLength=14
bDescriptorType=0x24
bDescriptorSubtype=0x01
bNumFormats=1
wTotalLength=155
bEndpointAddress=0x82
bmInfo=0x00
bTerminalLink=0x03
bStillCaptureMethod=0x00
bTriggerSupport=0x00
bTriggerUsage=0x00
bControlSize=1
bLength=27
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x04 (UDESCSUB_VS_FORMAT_UNCOMPRESSED)
bLength=27
bDescriptorType=0x24
bDescriptorSubtype=0x04
bFormatIndex=0x01
bNumFrameDescriptors=0x03
guidFormat=UYVY
bBitsPerPixel=0x10
bDefaultFrameIndex=0x01
bAspectRatioX=0x00
bAspectRatioY=0x00
bmInterlaceFlags=0x00
bCopyProtect=0x00
bLength=38
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x05 (UDESCSUB_VS_FRAME_UNCOMPRESSED)
bLength=38
bDescriptorType=0x24
bDescriptorSubtype=0x05
bFrameIndex=0x01
bmCapabilities=0x00
wWidth=640
wHeight=480
dwMinBitRate=383976960
dwMaxBitRate=383976960
dwMaxVideoFrameBufferSize=614400
dwDefaultFrameInterval=333333
bFrameIntervalType=0x00
dwMinFrameInterval = 333333
dwMaxFrameInterval = 333333
dwFrameIntervalStep = 0
bLength=38
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x05 (UDESCSUB_VS_FRAME_UNCOMPRESSED)
bLength=38
bDescriptorType=0x24
bDescriptorSubtype=0x05
bFrameIndex=0x02
bmCapabilities=0x00
wWidth=352
wHeight=288
dwMinBitRate=383976960
dwMaxBitRate=383976960
dwMaxVideoFrameBufferSize=202752
dwDefaultFrameInterval=333333
bFrameIntervalType=0x00
dwMinFrameInterval = 333333
dwMaxFrameInterval = 333333
dwFrameIntervalStep = 0
bLength=38
bDescriptorType=0x24 (CS_INTERFACE)
bDescriptorSubtype=0x05 (UDESCSUB_VS_FRAME_UNCOMPRESSED)
bLength=38
bDescriptorType=0x24
bDescriptorSubtype=0x05
bFrameIndex=0x03
bmCapabilities=0x00
wWidth=320
wHeight=240
dwMinBitRate=383976960
dwMaxBitRate=383976960
dwMaxVideoFrameBufferSize=153600
dwDefaultFrameInterval=333333
bFrameIntervalType=0x00
dwMinFrameInterval = 333333
dwMaxFrameInterval = 333333
dwFrameIntervalStep = 0
bLength=9
bDescriptorType=0x04 (UDESC_INTERFACE)
|
bLength=9
bDescriptorType=0x04
bInterfaceNumber=0x01
bAlternateSetting=0x01
bNumEndpoints=1
bInterfaceClass=0x0e
bInterfaceSubClass=0x02
bInterfaceProtocol=0x00
iInterface=0x00
bLength=7
bDescriptorType=0x05 (UDESC_ENDPOINT)
|
bLength=7
bDescriptorType=0x05
bEndpointAddress=0x82 (IN)
bmAttributes=0x05 (UE_ISOCHRONOUS, UE_ISO_ASYNC)
wMaxPacketSize=5120
bInterval=0x01
uvideo0: uvideo_vc_parse_desc
uvideo0: number of total interfaces=2
uvideo0: number of VS interfaces=1
uvideo0: uvideo_vs_parse_desc_format
uvideo0: number of total format descriptors=1
uvideo0: uvideo_vs_parse_desc_frame
uvideo0: VS interface 0, bInterfaceNumber=0x01, numalts=2
uvideo0: bAlternateSetting=0x00, no endpoint descriptor
uvideo0: bAlternateSetting=0x01, bEndpointAddress=0x82, wMaxPacketSize=5120
uvideo0: SET probe request successfully
bmHint=0x01
bFormatIndex=0x01
bFrameIndex=0x01
dwFrameInterval=333333 (100ns units)
wKeyFrameRate=0
wPFrameRate=0
wCompQuality=0
wCompWindowSize=0
wDelay=0 (ms)
dwMaxVideoFrameSize=0 (bytes)
dwMaxPayloadTransferSize=0 (bytes)
uvideo0: GET probe request successfully
bmHint=0x00
bFormatIndex=0x01
bFrameIndex=0x01
dwFrameInterval=333333 (100ns units)
wKeyFrameRate=0
wPFrameRate=0
wCompQuality=0
wCompWindowSize=0
wDelay=33 (ms)
dwMaxVideoFrameSize=614400 (bytes)
dwMaxPayloadTransferSize=3072 (bytes)
fixed dwMaxVideoFrameSize=614400, width=640 height=480 bpp=16
uvideo_attach: doing video_attach_mi
video0 at uvideo0
Subscribe to:
Posts (Atom)