Re: __memcpy_chk family of functions
Marcin Cieslak writes: > I have updated some binary packages using pkg(8) but neglected to > rebuild the world and my favourite web browsers no longer started > complaining about the undefined symbol __memcpy_chk@FBSD_1.8 > > Would that be a good idea to add that information to the Handbook and > possible bump FreeBSD_version and add this info to UPDATING? The purpose of UPDATING is to document changes that break backward compatibility, i.e. running old binaries on a newer world. What happened here is that you tried to run newer binaries on an older world, an issue of _forward_ compatibility, which we've never promised. Besides, an entry in UPDATING wouldn't have helped you since your source tree predated the change that would have added it. DES -- Dag-Erling Smørgrav - d...@freebsd.org
__memcpy_chk family of functions
Hello, I have updated some binary packages using pkg(8) but neglected to rebuild the world and my favourite web browsers no longer started complaining about the undefined symbol __memcpy_chk@FBSD_1.8 Would that be a good idea to add that information to the Handbook and possible bump FreeBSD_version and add this info to UPDATING? I fully accept that running -CURRENT as a daily driver leads to surprises like this, but it took me a bit long to figure out which change has caused this [1]. I was also thinking, would that be ok to add the synopsis of _memcpy_chk and other functions to the relevant memcpy(3) etc. manpages? Only when viewing the diff I found out I could learn about those from ssp(3). Thanks for keeping FreeBSD alive, Marcin [1] spoiler alert: https://reviews.freebsd.org/D32306
Re: bsdinstall wifi setup is broken on CURRENT
On 18/05/24 11:33, Alfonso S. Siciliano wrote: On 5/16/24 20:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself. I was able to reproduce the problem and also noticed another one. Thank you for your report, the video is highly appreciated to understand the problem quickly and exactly. I noticed Network Selection screen only shows one line, it's not beautiful to navigate through items this way. On 14.1-BETA2 it shows multiple lines so it seems to be a regression. Problem 1. Looking at wlanconfig it seems related to $height $width $rows for the selecting menu. Please could you open a PR adding me, so we can test and solve. I've fixed it locally and submitted a fix for review https://reviews.freebsd.org/D45271 The problem users reported was: after selecting desired network it just starts over instead of asking for password. I made a video [1] showing the problem. Problem 2. I know this issue about --mixedform, my last import 2 day ago should solve a6d8be451f62d425b71a4874f7d4e133b9fb393c. You could try the last main snapshot (yesterday 17 May), please let me know any problem. Last snapshot still contains bsddialog 1.0 so I'll wait for the next one and give it a try. Jessica, I've cc'd you because git shows you were the last person making changes in this area. If it's not related and I made a mistake, just ignore me. [1] https://youtube.com/shorts/Gmeckokw2a0 Again thanks for the video. Best Regards, Alfonso -- Renato Botelho
RES: RES: RES: usb mouse not work on boot
> -Mensagem original- > De: owner-freebsd-curr...@freebsd.org curr...@freebsd.org> Em nome de Dag-Erling Smørgrav > Enviada em: segunda-feira, 20 de maio de 2024 06:01 > Para: Ivan Quitschal > Cc: Vladimir Kondratyev ; Warner Losh > ; Oleksandr Kryvulia ; FreeBSD > Current > Assunto: Re: RES: RES: usb mouse not work on boot > > Ivan Quitschal writes: > > > Ivan Quitschal writes: > > > > diff --git a/sys/dev/usb/input/usbhid.c > > > > b/sys/dev/usb/input/usbhid.c index 174e1c28ae96..7b19d713c943 > > > > 100644 > > > > --- a/sys/dev/usb/input/usbhid.c > > > > +++ b/sys/dev/usb/input/usbhid.c > > > > @@ -802,6 +802,7 @@ usbhid_probe(device_t dev) > > > > if (hid_test_quirk(&sc->sc_hw, HQ_HID_IGNORE)) > > > > return (ENXIO); > > > > +// return (BUS_PROBE_GENERIC + 1); > > > > return (BUS_PROBE_DEFAULT + 1); } > > > You realize this diff does nothing at all, right? > > Yeap, i also said it worked in 14-current old code only ,and has more > > than 2 years already > > No, I mean all this does is add a comment. It has no effect on the code. > > DES > -- > Dag-Erling Smørgrav - d...@freebsd.org Oh ok,, sorry But actually it did change one return for another Usbhid.ko used to return this return (BUS_PROBE_GENERIC + 1); and ums.ko used to take place instead , messing up our multimedia kbds and all Was a priority issue when it shouldn’t matter Then Vladmir changed to this return (BUS_PROBE_DEFAULT + 1); and everything went to "voil" 😊 sorry for the miss communication regards tzk
Re: RES: RES: usb mouse not work on boot
Ivan Quitschal writes: > > Ivan Quitschal writes: > > > diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c > > > index 174e1c28ae96..7b19d713c943 100644 > > > --- a/sys/dev/usb/input/usbhid.c > > > +++ b/sys/dev/usb/input/usbhid.c > > > @@ -802,6 +802,7 @@ usbhid_probe(device_t dev) > > > if (hid_test_quirk(&sc->sc_hw, HQ_HID_IGNORE)) > > > return (ENXIO); > > > +// return (BUS_PROBE_GENERIC + 1); > > > return (BUS_PROBE_DEFAULT + 1); > > > } > > You realize this diff does nothing at all, right? > Yeap, i also said it worked in 14-current old code only ,and has more > than 2 years already No, I mean all this does is add a comment. It has no effect on the code. DES -- Dag-Erling Smørgrav - d...@freebsd.org
