Re: snapshot of today, pkg_add -u changed behaviour
sven.falem...@gmail.com (Sven F.), 2021.02.24 (Wed) 19:04 (CET): > On Wed, Feb 24, 2021 at 12:06 PM Stuart Henderson > wrote: > > > > On 2021-02-24, Marcus MERIGHI wrote: > > > Hello! > > > > > > I just ugraded two machines to the snapshot of the day: > > > > > > OpenBSD 6.9-beta (GENERIC.MP) #357: Tue Feb 23 22:09:48 MST 2021 > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > When I run pkg_add -u afterwards, it just sits there, without output, > > > for an unusually long time. > > > > > > With ^T it says: Processing Parameters. > > > > > > After some minutes the usual output starts. > > > > > > Just thought I'd mention it here, in case someone is worried about not > > > seeing the familiar behaviour (as I was). > > > > > > Marcus > > > > > > > > > > Check for running ftp processes and you might get a better idea what > > it's doing. Do you have a slow connection to the mirror you're using? > > > > FETCH_CMD="ftp -v" pkg_add -u ? Thanks for your assistance, Sven and Stuart! It's just that ftp2.eu.openbsd.org is slow for me. As nothing in my environment had changed and the download of the base system didn't take longer than usual, I thought pkg_add(1) might be doing something differently. speedtest-cli says 20 Mbit/s download speed, while lynx http://ftp2.eu.openbsd.org/pub/OpenBSD//snapshots/packages/amd64/ takes ages. FETCH_CMD="ftp -v" did not make much of a difference, as it's the initial ftp -v -o - http://ftp2.eu.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ that takes so long (I'm ctrl-c'ing it after 10 minutes right now, on my third machine to upgrade.) ftp.hostserver.de to the rescue... Sorry for the noise! Marcus
Re: baresip-gtk
On 2/24/21 2:59 PM, Mihai Popescu wrote: >> How do you use baresip-gtk? > If I recall correctly, all you get is an icon in the system tray bar if you > have one. You can click there and get a not very rich GUI. Hmm, I understood. I am not using a DE, prefer spectrwm.
Re: snapshot of today, pkg_add -u changed behaviour
On Wed, Feb 24, 2021 at 12:06 PM Stuart Henderson wrote: > > On 2021-02-24, Marcus MERIGHI wrote: > > Hello! > > > > I just ugraded two machines to the snapshot of the day: > > > > OpenBSD 6.9-beta (GENERIC.MP) #357: Tue Feb 23 22:09:48 MST 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > When I run pkg_add -u afterwards, it just sits there, without output, > > for an unusually long time. > > > > With ^T it says: Processing Parameters. > > > > After some minutes the usual output starts. > > > > Just thought I'd mention it here, in case someone is worried about not > > seeing the familiar behaviour (as I was). > > > > Marcus > > > > > > Check for running ftp processes and you might get a better idea what > it's doing. Do you have a slow connection to the mirror you're using? > FETCH_CMD="ftp -v" pkg_add -u ? -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: Attempting to use Brother DCP-L2510D printer on BSD
On 2/24/21 9:43 AM, Sylvain S wrote: > Hello, > > I see that, if I understand correctly, you have been > able to make this printer work on ArchLinux from the > officially provided RPM driver package. > https://aur.archlinux.org/packages/brother-dcp-l2510d/ > > May I ask, what kind of porting work did that require ? > I have acquired this model from Brother and have not been > successful at making it work/print yet. > For reference, here is the thread on the French community forums > https://forum.openbsd.fr.eu.org/showthread.php?tid=2846 > > I also note that the printer is absent from the foomatic > database maintained by Fedora. This seems strange as a > driver package is available for their distribution format, > but perhaps I am missing something here ? > https://src.fedoraproject.org/repo/extras/foomatic-db/ > > Finally, I notice from the documentation (to the mailing list's attention) : > > The Foomatic framework supports direct printing which does not rely on CUPS > (nor > any spooler). > > Complete documentation can be found at: > > https://wiki.linuxfoundation.org/openprinting/database/nospoolerdocumentation > > I would gladly do that, but am still clueless as of now > > Thanks to anyone who would help > It feels like we repeat this thread every couple months... If your printer supports postscript (as yours and most other Brother brand laser printers seem to) you can use something like this in your /etc/printcap file to print postscript data directly to the printer: ... lp|remote line printer:\ :lp=:rm=172.20.200.5:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: ... Then check out stuff like the 'pdftops' utility etc for converting documents to postscript. With a bit of fiddling, LibreOffice can be configured to print raw postscript to the device as well. No drivers or other garbage needed. Everybody always wants to connect to their printer over USB, just don't -- its annoying. If you get your postscript printer setup on the network like this, then you can move forward into broad sunlit uplands. Printing truly can be as easy as '$ lpr mydoc.ps' Regards, Jordan
Attempting to use Brother DCP-L2510D printer on BSD
Hello, I see that, if I understand correctly, you have been able to make this printer work on ArchLinux from the officially provided RPM driver package. https://aur.archlinux.org/packages/brother-dcp-l2510d/ May I ask, what kind of porting work did that require ? I have acquired this model from Brother and have not been successful at making it work/print yet. For reference, here is the thread on the French community forums https://forum.openbsd.fr.eu.org/showthread.php?tid=2846 I also note that the printer is absent from the foomatic database maintained by Fedora. This seems strange as a driver package is available for their distribution format, but perhaps I am missing something here ? https://src.fedoraproject.org/repo/extras/foomatic-db/ Finally, I notice from the documentation (to the mailing list's attention) : The Foomatic framework supports direct printing which does not rely on CUPS (nor any spooler). Complete documentation can be found at: https://wiki.linuxfoundation.org/openprinting/database/nospoolerdocumentation I would gladly do that, but am still clueless as of now Thanks to anyone who would help -- Sylvain S from webmail
Re: snapshot of today, pkg_add -u changed behaviour
On 2021-02-24, Marcus MERIGHI wrote: > Hello! > > I just ugraded two machines to the snapshot of the day: > > OpenBSD 6.9-beta (GENERIC.MP) #357: Tue Feb 23 22:09:48 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > When I run pkg_add -u afterwards, it just sits there, without output, > for an unusually long time. > > With ^T it says: Processing Parameters. > > After some minutes the usual output starts. > > Just thought I'd mention it here, in case someone is worried about not > seeing the familiar behaviour (as I was). > > Marcus > > Check for running ftp processes and you might get a better idea what it's doing. Do you have a slow connection to the mirror you're using?
Re: Bufferbloat, FQ-CoDel, and performance
On Tue, Feb 23, 2021 at 09:04:13PM -, Stuart Henderson wrote: > On 2021-02-23, Stuart Henderson wrote: > > On 2021-02-23, Steven Shockley wrote: > >> I have OpenBSD 6.8 running on a Dell R210-II acting as a > >> firewall/router. To combat bufferbloat I tried implementing FQ-CoDel > >> queueing. The WAN bandwidth is advertised as 940 Mbit/sec down and 840 > >> Mbit/sec up. > > > > Flow queues are broken in 6.8 on interfaces with hw checksum offloading. > > Fix is in -current or sys/net/pf.c r1.1096 > > Oops, on interfaces *without* hw checksum offloading, like this: > > $ ifconfig em0 hwfeatures > em0: flags=8843 mtu 1500 > hwfeatures=10 hardmtu 9216 > .. > Thank you Stuart! This seems to have fixed the issue for me (on a 6.8 system which now also carries the r1.1096 pf.c patch).
Re: OpenBSD: Failing to link custom libpng to custom libz, any thoughts how fix?
On Wed, Feb 24, 2021 at 02:17:14PM -, Stuart Henderson wrote: > On 2021-02-23, Bob wrote: > > Hi, > > > > I am trying to make a custom build of libpng in my home directory, > > using a libz build that I made in my home directory also. > > > > Both are latest version, libpng 1.6.37 same as OpenBSD's port > > https://cvsweb.openbsd.org/ports/graphics/png/Makefile?rev=1.125&content-type=text/x-cvsweb-markup > > and libz the latest one they published. For zlib it's 1.2.11 > > from http://zlib.net/ from 2017, OpenBSD does not have a port but > > base bundles a 2009 version. Since 2009, significantly an export > > "inflateReset2" has been added. > > As you have seen it is difficult to have library functions in one > version in base and in another version built elsewhere (whether that's > in $HOME or in ports). Ports only does this for libraries where there's > really no other choice and where that has been done they're used *very* > rarely (the port can then not depend on any libraries which pull in the > library from base). Currently that is libbind (used only by asdig and > zeek) and openssl (used as a static library by sslscan, and dynamic > for nrpe and nsca-ng). > > > I'll start with the detail problem, and discuss the reproduction at the > > bottom: > > > > > > This has brought me to the bizarre issue that the libpng build plainly > > refuses to link to my custom libz file /home/myuser/lib/libz.so.1 . > > Instead, it insists with linking to the OS' global > > /usr/lib/libz.so.5.0 . > > This is as expected really, it looks for the higher library version > number. Not really, it's more that you have to make sure to put your own directory before the system directory, which requires a bit more magic than just -L. (remember that linking will stop at the first directory with a satisfying library, and link with the highest version number found in there, which is fortunate for stuff like libtool!)
snapshot of today, pkg_add -u changed behaviour
Hello! I just ugraded two machines to the snapshot of the day: OpenBSD 6.9-beta (GENERIC.MP) #357: Tue Feb 23 22:09:48 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP When I run pkg_add -u afterwards, it just sits there, without output, for an unusually long time. With ^T it says: Processing Parameters. After some minutes the usual output starts. Just thought I'd mention it here, in case someone is worried about not seeing the familiar behaviour (as I was). Marcus
Re: OpenBSD: Failing to link custom libpng to custom libz, any thoughts how fix?
On 2021-02-23, Bob wrote: > Hi, > > I am trying to make a custom build of libpng in my home directory, > using a libz build that I made in my home directory also. > > Both are latest version, libpng 1.6.37 same as OpenBSD's port > https://cvsweb.openbsd.org/ports/graphics/png/Makefile?rev=1.125&content-type=text/x-cvsweb-markup > and libz the latest one they published. For zlib it's 1.2.11 > from http://zlib.net/ from 2017, OpenBSD does not have a port but > base bundles a 2009 version. Since 2009, significantly an export > "inflateReset2" has been added. As you have seen it is difficult to have library functions in one version in base and in another version built elsewhere (whether that's in $HOME or in ports). Ports only does this for libraries where there's really no other choice and where that has been done they're used *very* rarely (the port can then not depend on any libraries which pull in the library from base). Currently that is libbind (used only by asdig and zeek) and openssl (used as a static library by sslscan, and dynamic for nrpe and nsca-ng). > I'll start with the detail problem, and discuss the reproduction at the > bottom: > > > This has brought me to the bizarre issue that the libpng build plainly > refuses to link to my custom libz file /home/myuser/lib/libz.so.1 . > Instead, it insists with linking to the OS' global > /usr/lib/libz.so.5.0 . This is as expected really, it looks for the higher library version number. > I have reduced the issue to the libpng build step where it produces > libpng.so: > > /usr/local/bin/egcc -shared -fPIC -DPIC -o .libs/libpng.so.16.37 > .libs/png.o .libs/pngerror.o .libs/pngget.o .libs/pngmem.o > .libs/pngpread.o .libs/pngread.o .libs/pngrio.o .libs/pngrtran.o > .libs/pngrutil.o .libs/pngset.o .libs/pngtrans.o .libs/pngwio.o > .libs/pngwrite.o .libs/pngwtran.o .libs/pngwutil.o -L/home/myuser/lib > -lm -lz -Og -g -fstack-protector-all > [with or without: -Wl,--version-script=libpng.vers] > [with or without: -Wl,-t] You might get somewhere further with something like "-nostdlib -L/home/myuser/lib -L/usr/lib". You might need either rpath or change to using static libs. (not relevant to libpng which is in C, but if you try to build C++ software with GCC rather than Clang you will often run into problems with incompatible standard libraries too). > What appears is that GCC ignores the "-L" search path given to it. -L adds, it doesn't overwrite. Hopefully you're just doing this to use pngfix; if you try and replace the installed libpng with one built like this you're likely to end up with all sorts of problems.
Re: baresip-gtk
> How do you use baresip-gtk? If I recall correctly, all you get is an icon in the system tray bar if you have one. You can click there and get a not very rich GUI.
