Re: Freetype FT_CONFIG_OPTION_USE_PNG
Stuart, thank you. Is it possible to builtin / bundle freetype with sdl2 / sdl2-ttf and enable this option? I think op@ did something similar with godot... Am 21. Dez. 2023, 22:29, um 22:29, Stuart Henderson schrieb: >On 2023-12-21, Robert Palm wrote: >> >> I wanted to ask if in xenocaras freetype the FT_CONFIG_OPTION_USE_PNG > >> is enabled. > >It's not, afaik it can't be done unless libpng would be moved from >ports to xenocara. > >-- >Please keep replies on the mailing list.
Re: man.openbsd.org failure?
Oops! I did see that message but forgot that it mentioned man.openbsd.org. Apologies for the noise. (But that Safari error message sucks!) Dave Anderson d...@daveanderson.com > On Dec 21, 2023, at 21:55, Daniel Jakots wrote: > > On Thu, 21 Dec 2023 21:22:49 -0500, Dave Anderson wrote: > >> Safari isn=E2=80=99t providing much useful information, but starting today >> I=E2=80=99m consistently getting a =E2=80=9Cserver stopped responding=E2= > =80=9D error when >> trying to access the online man pages at man.openbsd.org. >> www.openbsd.org is working fine. > > Yes, it's a maintenance: > https://marc.info/?l=3Dopenbsd-misc=3D170301839017559=3D
Re: man.openbsd.org failure?
On Thu, 21 Dec 2023 21:22:49 -0500, Dave Anderson wrote: > Safari isn’t providing much useful information, but starting today > I’m consistently getting a “server stopped responding” error when > trying to access the online man pages at man.openbsd.org. > www.openbsd.org is working fine. Yes, it's a maintenance: https://marc.info/?l=openbsd-misc=170301839017559=2 Cheers, Daniel
man.openbsd.org failure?
Safari isn’t providing much useful information, but starting today I’m consistently getting a “server stopped responding” error when trying to access the online man pages at man.openbsd.org. www.openbsd.org is working fine. Dave Anderson d...@daveanderson.com
Re: Freetype FT_CONFIG_OPTION_USE_PNG
On 2023-12-21, Robert Palm wrote: > > I wanted to ask if in xenocaras freetype the FT_CONFIG_OPTION_USE_PNG > is enabled. It's not, afaik it can't be done unless libpng would be moved from ports to xenocara. -- Please keep replies on the mailing list.
Freetype FT_CONFIG_OPTION_USE_PNG
I wanted to ask if in xenocaras freetype the FT_CONFIG_OPTION_USE_PNG is enabled.
Re: Post (snap) update emails: fsck errors and (in)security output
On Thu, Dec 21, 2023 at 10:54:14AM -, Stuart Henderson wrote: > On 2023-12-20, Why 42? The lists account. wrote: > > > > Just tried the mount of /tmp manually from the command line at got: > > mount_mfs: mmap: Cannot allocate memory > > > > When I halved the size (memory) allocated (-s=2097152) it mounts > > successfully: > > mjoelnir:robb 20.12 19:50:02 # df -h /tmp > > Filesystem SizeUsed Avail Capacity Mounted on > > mfs:75507 1.9G1.0K1.8G 1%/tmp > > > > Strange that it used to work. One day (!) I'll re-partition and allocate > > a partition/slice of "real" storage to /tmp instead of using mfs. > > login.conf used to allow unlimited datasize for the 'daemon' class. That was > changed to cap at 4G Actually the value is an architecture dependent setting. On amd64 it is indeed 4G, but typically 1024 Mb on the smaller archs which until recently, (post 7.4), included i386, which has now been increased to 1500 Mb. BTW, we already had this exact same discussion with Robb on the list back in February: https://marc.info/?l=openbsd-misc=167561903118994 So when I asked why he didn't just bump the value, it was indeed a question and not a suggestion to just do it.
Re: Post (snap) update emails: fsck errors and (in)security output
On 2023-12-20, Why 42? The lists account. wrote: > > Just tried the mount of /tmp manually from the command line at got: > mount_mfs: mmap: Cannot allocate memory > > When I halved the size (memory) allocated (-s=2097152) it mounts > successfully: > mjoelnir:robb 20.12 19:50:02 # df -h /tmp > Filesystem SizeUsed Avail Capacity Mounted on > mfs:75507 1.9G1.0K1.8G 1%/tmp > > Strange that it used to work. One day (!) I'll re-partition and allocate > a partition/slice of "real" storage to /tmp instead of using mfs. login.conf used to allow unlimited datasize for the 'daemon' class. That was changed to cap at 4G (IIRC that was a prerequisite before we were allowed to bump MAXDSIZ but I don't remember all the details now). This affects things started from rc - the things particularly likely to run into memory limits here are fsck, mounting mfs filesystems, maybe also running dump or restore from single user mode - also ports daemons, though in most cases we now provide a separate /etc/login.conf.d/daemonname file which raises limits where needed. If you have plenty of RAM you may want to bump that value.
Re: XFCE Thunar filemanager core dumps ...
On 2023-12-20, Why 42? The lists account. wrote: > > On Wed, Dec 20, 2023 at 03:23:52PM -, Stuart Henderson wrote: >> > ... >> > When I started gdb (no expert) I noticed this "Dwarf error": >> > mjoelnir:/tmp 20.12 12:04:38 % gdb -e /usr/local/bin/Thunar -c thunar.core >> > GNU gdb 6.3 >> >> https://www.openbsd.org/faq/ports/ports.html#Backtrace > > Thanks. What I understood from there then was to install the debug > package and run egdb + "bt". Hopefully that's what you had in mind. Also install debug packages for relevant libraries - here, debug-glib2 and debug-gtk+3 may be useful. > Here's the resulting stack trace, the "optimized out" sounds a bit > worrying :-): That doesn't indicate a problem. Probably best to move this to ports@ btw. > (gdb) bt > #0 0x084822eb0565 in g_node_traverse_pre_order () from > /usr/local/lib/libglib-2.0.so.4201.11 > #1 0x084822eb0577 in g_node_traverse_pre_order () from > /usr/local/lib/libglib-2.0.so.4201.11 > #2 0x084822eb0577 in g_node_traverse_pre_order () from > /usr/local/lib/libglib-2.0.so.4201.11 > #3 0x084570b35046 in thunar_tree_view_set_show_hidden > (view=0x848252483c0, show_hidden=) at thunar-tree-view.c:1990 > #4 thunar_tree_view_set_property (object=0x848252483c0, prop_id= out>, value=, pspec=) at thunar-tree-view.c:509 > #5 0x084827e3c82a in object_set_property () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #6 0x084827e3c5a8 in g_object_setv () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #7 0x084827e3d94b in g_object_set_property () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #8 0x084827e2cf19 in on_source_notify () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #9 0x084827e3442b in g_closure_invoke () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #10 0x084827e50f4c in signal_emit_unlocked_R.123 () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #11 0x084827e4ebab in signal_emit_valist_unlocked () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #12 0x084827e4f39f in g_signal_emit () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #13 0x084827e40a53 in g_object_dispatch_properties_changed () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #14 0x084827e3ae1c in g_object_notify_by_spec_internal () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #15 0x084570b43c07 in thunar_window_action_show_hidden > (window=0x848393b6760) at thunar-window.c:4727 > #16 0x0847e652dc4e in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from > /usr/local/lib/libgtk-3.so.2201.0 > #17 0x084827e3442b in g_closure_invoke () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #18 0x084827e4ff6d in signal_emit_unlocked_R () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #19 0x084827e4ec0f in signal_emit_valist_unlocked () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #20 0x084827e4f39f in g_signal_emit () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #21 0x0847e65498d2 in gtk_accel_group_activate () from > /usr/local/lib/libgtk-3.so.2201.0 > #22 0x0847e6549a24 in gtk_accel_groups_activate () from > /usr/local/lib/libgtk-3.so.2201.0 > #23 0x0847e686e048 in gtk_window_activate_key () from > /usr/local/lib/libgtk-3.so.2201.0 > #24 0x0847e6874325 in gtk_window_key_press_event () from > /usr/local/lib/libgtk-3.so.2201.0 > #25 0x0847e652ceb0 in _gtk_marshal_BOOLEAN__BOXED () from > /usr/local/lib/libgtk-3.so.2201.0 > #26 0x084827e3442b in g_closure_invoke () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #27 0x084827e50100 in signal_emit_unlocked_R () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #28 0x084827e4ec0f in signal_emit_valist_unlocked () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #29 0x084827e4f39f in g_signal_emit () from > /usr/local/lib/libgobject-2.0.so.4200.18 > #30 0x0847e684e22a in gtk_widget_event_internal () from > /usr/local/lib/libgtk-3.so.2201.0 > #31 0x0847e66ce1cf in gtk_propagate_event () from > /usr/local/lib/libgtk-3.so.2201.0 > #32 0x0847e66cdbe1 in gtk_main_do_event () from > /usr/local/lib/libgtk-3.so.2201.0 > #33 0x08477220a65b in _gdk_event_emit () from > /usr/local/lib/libgdk-3.so.2201.1 > #34 0x084772263c88 in gdk_event_source_dispatch () from > /usr/local/lib/libgdk-3.so.2201.1 > #35 0x084822ea320d in g_main_context_dispatch_unlocked () from > /usr/local/lib/libglib-2.0.so.4201.11 > #36 0x084822ea35ec in g_main_context_iterate_unlocked () from > /usr/local/lib/libglib-2.0.so.4201.11 > #37 0x084822ea369b in g_main_context_iteration () from > /usr/local/lib/libglib-2.0.so.4201.11 > #38 0x0847e42d987d in g_application_run () from > /usr/local/lib/libgio-2.0.so.4200.18 > #39 0x084570acf399 in main (argc=1, argv=0x7ee77838c528) at main.c:86 > > > mjoelnir:robb 20.12 18:42:54 # pkg_info | grep thunar > debug-thunar-4.18.8 debug info for thunar > thunar-4.18.8 Xfce4 file manager >
Re: Weird network performance with iwn(4)
On Wed, Dec 20, 2023 at 07:54:47PM +, Lévai, Dániel wrote: > Danel Levai wrote: > > Stuart Henderson wrote: > > > I checked for openwrt support but your AP has a relatively uncommon > > > Realtek SoC and it seems fairly unlikely to happen so you're probably > > > stuck with the vendor firmware. > > > > > > Maybe try forcing "mode 11n" or "mode 11g" with ifconfig and see if > > > that's any better. > > > > Interestingly enough, "mode 11g" won't join the AP. 11n works and it's a > > steady > > 300KByte/sec, it doesn't go up and down like with 11ac. > > > > Anyway, I'll see if I can find myself another AP to deploy here, maybe it's > > just some > > fringe compatibility issue. > > > > Daniel > > Just for the record, I totally missed trying the 2.4GHz SSID of this AP (it > has a different name). I was only trying 5GHz with all modes - no wonder .11g > wouldn't join (brain freeze)... > So .11n actually works on 2.4GHz with this AP and iwm(4), and has a download > speed of around 1,5-2,0MByte. > > Daniel > > This means the performance issue is specific to 11ac mode, correct? If so, could you send me a pcap of 5GHz beacons from this AP? To capture beacons, associate to the AP again (the easy way to ensure we don't capture unrelated things): ifconfig iwm0 join apname chan 44 wpakey ... Once 'status:' shown by ifconfig iwm0 is "actve", run this for about one second, then terminate with Ctrl-C: tcpdump -n -i iwm0 -s 1500 -w /tmp/iwm.pcap -y IEEE802_11_RADIO type mgt subtype beacon To verify whether the file contains the expected beacons, run: tcpdump -r /tmp/iwm.pcap | grep beacon You should see at least one line such as: 09:18:15.918261 802.11: beacon, ssid (apname), rates, ds, tim, country, rsn, 70:5, 59:2, htcaps, htop, 127:8, vhtcaps, vhtop Now send me the iwm.pcap file offlist. Thanks!
