Deprecating lua-language-server

[Adam Weinberger]

To all users of LuaLS: I’ve deprecated the devel/lua-language-server port, and 
set it to expire on 8/15.

LuaLS is a phenomenal Lua LSP, and makes Neovim configuration so much more 
pleasant. However, all versions after 3.6.9 dump core immediately after startup 
in Neovim, and I have no idea why.

If anyone wants to debug later versions, I’d be exceptionally grateful, but 
barring that it’ll disappear on 8/15.

# Adam


—
Adam Weinberger
ad...@adamw.org
https://www.adamw.org it 

glib2 deprecated declarations failing on clang16

[Nuno Teixeira]

Hello,

I'm getting build errors from current with www/bluefish about deprecated
glib2 declarations and causing build to fail with clang16:
---
/usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded from
macro 'G_DEPRECATED'
#define G_DEPRECATED __attribute__((__deprecated__))
^
mv -f .deps/bluefish.Tpo .deps/bluefish.Po
bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is
deprecated: Use 'g_thread_new' instead [-Wdeprecated-declarations]
g_thread_create_full(build_bflang2scan_thread, NULL, 0, FALSE,
FALSE, G_THREAD_PRIORITY_LOW, &gerror);
---

Any help is welcome on finding out its cause.

a related issue: https://github.com/PCSX2/pcsx2/issues/3315

Build log:
https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: glib2 deprecated declarations failing on clang16

[Dimitry Andric]

On 4 Jul 2023, at 14:37, Nuno Teixeira  wrote:
> 
> I'm getting build errors from current with www/bluefish about deprecated 
> glib2 declarations and causing build to fail with clang16:
> ---
> /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded from macro 
> 'G_DEPRECATED'
> #define G_DEPRECATED __attribute__((__deprecated__))
> ^
> mv -f .deps/bluefish.Tpo .deps/bluefish.Po
> bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is deprecated: 
> Use 'g_thread_new' instead [-Wdeprecated-declarations]
> g_thread_create_full(build_bflang2scan_thread, NULL, 0, FALSE, FALSE, 
> G_THREAD_PRIORITY_LOW, &gerror);
> ---
> 
> Any help is welcome on finding out its cause.
> 
> a related issue: https://github.com/PCSX2/pcsx2/issues/3315
> 
> Build log: 
> https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log

The actual error is an incompatible callback function signature:

bftextview2_autocomp.c:432:2: error: incompatible function pointer types 
passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka 'int (struct _GtkLabel 
*, char *, void *)') to parameter of type 'GCallback' (aka 'void (*)(void)') 
[-Wincompatible-function-pointer-types]
g_signal_connect(acw->reflabel, "activate-link", acw_label_active_link_lcb, 
acw);
^~~~
/usr/local/include/glib-2.0/gobject/gsignal.h:515:59: note: expanded from macro 
'g_signal_connect'
g_signal_connect_data ((instance), (detailed_signal), (c_handler), (data), 
NULL, (GConnectFlags) 0)
^~~
/usr/local/include/glib-2.0/gobject/gsignal.h:411:25: note: passing argument to 
parameter 'c_handler' here
GCallback c_handler,
^

I have seen these more often with glib-based applications. In some cases
it is feasible to fix the callback function to have the correct
signature, in other cases you can slap a cast in place. Or, if the
affected code is vala-generated (also happens), the big hammer is to
suppress the warning(s).

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: glib2 deprecated declarations failing on clang16

[Danilo Egea Gondolfo]

On 04/07/2023 14:56, Dimitry Andric wrote:


On 4 Jul 2023, at 14:37, Nuno Teixeira  wrote:

I'm getting build errors from current with www/bluefish about deprecated glib2 
declarations and causing build to fail with clang16:
---
/usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded from macro 
'G_DEPRECATED'
#define G_DEPRECATED __attribute__((__deprecated__))
 ^
mv -f .deps/bluefish.Tpo .deps/bluefish.Po
bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is deprecated: 
Use 'g_thread_new' instead [-Wdeprecated-declarations]
 g_thread_create_full(build_bflang2scan_thread, NULL, 0, FALSE, FALSE, 
G_THREAD_PRIORITY_LOW, &gerror);
---

Any help is welcome on finding out its cause.

a related issue: https://github.com/PCSX2/pcsx2/issues/3315

Build log: 
https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log

The actual error is an incompatible callback function signature:

bftextview2_autocomp.c:432:2: error: incompatible function pointer types 
passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka 'int (struct _GtkLabel 
*, char *, void *)') to parameter of type 'GCallback' (aka 'void (*)(void)') 
[-Wincompatible-function-pointer-types]
g_signal_connect(acw->reflabel, "activate-link", acw_label_active_link_lcb, 
acw);
^~~~
/usr/local/include/glib-2.0/gobject/gsignal.h:515:59: note: expanded from macro 
'g_signal_connect'
g_signal_connect_data ((instance), (detailed_signal), (c_handler), (data), 
NULL, (GConnectFlags) 0)
^~~
/usr/local/include/glib-2.0/gobject/gsignal.h:411:25: note: passing argument to 
parameter 'c_handler' here
GCallback c_handler,
^

I have seen these more often with glib-based applications. In some cases
it is feasible to fix the callback function to have the correct
signature, in other cases you can slap a cast in place. Or, if the
affected code is vala-generated (also happens), the big hammer is to
suppress the warning(s).

-Dimitry


Not a glib expert here, but you can try this https://pastebin.com/ty8hLjVU

Re: glib2 deprecated declarations failing on clang16

[Nuno Teixeira]

So what could be done here?

Suppress warnings at port or something need to be fixed at devel/glib20?

Thanks,

Dimitry Andric  escreveu no dia terça, 4/07/2023 à(s)
14:56:

> On 4 Jul 2023, at 14:37, Nuno Teixeira  wrote:
> >
> > I'm getting build errors from current with www/bluefish about deprecated
> glib2 declarations and causing build to fail with clang16:
> > ---
> > /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded from
> macro 'G_DEPRECATED'
> > #define G_DEPRECATED __attribute__((__deprecated__))
> > ^
> > mv -f .deps/bluefish.Tpo .deps/bluefish.Po
> > bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is
> deprecated: Use 'g_thread_new' instead [-Wdeprecated-declarations]
> > g_thread_create_full(build_bflang2scan_thread, NULL, 0, FALSE,
> FALSE, G_THREAD_PRIORITY_LOW, &gerror);
> > ---
> >
> > Any help is welcome on finding out its cause.
> >
> > a related issue: https://github.com/PCSX2/pcsx2/issues/3315
> >
> > Build log:
> https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log
>
> The actual error is an incompatible callback function signature:
>
> bftextview2_autocomp.c:432:2: error: incompatible function pointer types
> passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka 'int (struct
> _GtkLabel *, char *, void *)') to parameter of type 'GCallback' (aka 'void
> (*)(void)') [-Wincompatible-function-pointer-types]
> g_signal_connect(acw->reflabel, "activate-link",
> acw_label_active_link_lcb, acw);
>
> ^~~~
> /usr/local/include/glib-2.0/gobject/gsignal.h:515:59: note: expanded from
> macro 'g_signal_connect'
> g_signal_connect_data ((instance), (detailed_signal), (c_handler), (data),
> NULL, (GConnectFlags) 0)
> ^~~
> /usr/local/include/glib-2.0/gobject/gsignal.h:411:25: note: passing
> argument to parameter 'c_handler' here
> GCallback c_handler,
> ^
>
> I have seen these more often with glib-based applications. In some cases
> it is feasible to fix the callback function to have the correct
> signature, in other cases you can slap a cast in place. Or, if the
> affected code is vala-generated (also happens), the big hammer is to
> suppress the warning(s).
>
> -Dimitry
>
>

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: glib2 deprecated declarations failing on clang16

[Nuno Teixeira]

Hello Danilo!

Yes, it builds ok.

I will do a run test tomorrow on bluefish.

Any hint on how to explain it in commit:

---
--- src/bftextview2_autocomp.c.orig 2023-07-04 14:09:37 UTC
+++ src/bftextview2_autocomp.c
@@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)
/*gtk_widget_set_size_request(acw->reflabel,150,-1); */
gtk_widget_show_all(acw->scroll);
gtk_widget_show(hbox);
-   g_signal_connect(acw->reflabel, "activate-link",
acw_label_active_link_lcb, acw);
+   g_signal_connect(acw->reflabel, "activate-link",
G_CALLBACK(acw_label_active_link_lcb), acw);
/*gtk_widget_set_size_request(GTK_WIDGET(acw->tree),100,200); */
/*gtk_widget_set_size_request(acw->win, 150, 200); */

/*g_signal_connect(G_OBJECT(acw->win),"key-release-event",G_CALLBACK(acwin_key_release_lcb),acw);
*/
---
and
---
--- src/external_commands.c.orig2023-07-04 14:12:18 UTC
+++ src/external_commands.c
@@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep, const gchar * fo

gtk_dialog_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);
tmp = g_strdup_printf(_("Supply arguments to define %%a in
'%s'"), formatstring);
entry = dialog_entry_labeled(NULL, tmp,
gtk_dialog_get_content_area(GTK_DIALOG(dialog)), 6);
-   g_signal_connect(G_OBJECT(entry), "activate",
command_dialog_entry_activated_lcb, dialog);
+   g_signal_connect(G_OBJECT(entry), "activate",
G_CALLBACK(command_dialog_entry_activated_lcb), dialog);
g_free(tmp);
gtk_widget_show_all(dialog);
result = gtk_dialog_run(GTK_DIALOG(dialog));
---

Thanks!

Danilo Egea Gondolfo  escreveu no dia terça, 4/07/2023
à(s) 15:00:

> On 04/07/2023 14:56, Dimitry Andric wrote:
>
> > On 4 Jul 2023, at 14:37, Nuno Teixeira  wrote:
> >> I'm getting build errors from current with www/bluefish about
> deprecated glib2 declarations and causing build to fail with clang16:
> >> ---
> >> /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded from
> macro 'G_DEPRECATED'
> >> #define G_DEPRECATED __attribute__((__deprecated__))
> >>  ^
> >> mv -f .deps/bluefish.Tpo .deps/bluefish.Po
> >> bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is
> deprecated: Use 'g_thread_new' instead [-Wdeprecated-declarations]
> >>  g_thread_create_full(build_bflang2scan_thread, NULL, 0, FALSE,
> FALSE, G_THREAD_PRIORITY_LOW, &gerror);
> >> ---
> >>
> >> Any help is welcome on finding out its cause.
> >>
> >> a related issue: https://github.com/PCSX2/pcsx2/issues/3315
> >>
> >> Build log:
> https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log
> > The actual error is an incompatible callback function signature:
> >
> > bftextview2_autocomp.c:432:2: error: incompatible function pointer types
> passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka 'int (struct
> _GtkLabel *, char *, void *)') to parameter of type 'GCallback' (aka 'void
> (*)(void)') [-Wincompatible-function-pointer-types]
> > g_signal_connect(acw->reflabel, "activate-link",
> acw_label_active_link_lcb, acw);
> >
> ^~~~
> > /usr/local/include/glib-2.0/gobject/gsignal.h:515:59: note: expanded
> from macro 'g_signal_connect'
> > g_signal_connect_data ((instance), (detailed_signal), (c_handler),
> (data), NULL, (GConnectFlags) 0)
> > ^~~
> > /usr/local/include/glib-2.0/gobject/gsignal.h:411:25: note: passing
> argument to parameter 'c_handler' here
> > GCallback c_handler,
> > ^
> >
> > I have seen these more often with glib-based applications. In some cases
> > it is feasible to fix the callback function to have the correct
> > signature, in other cases you can slap a cast in place. Or, if the
> > affected code is vala-generated (also happens), the big hammer is to
> > suppress the warning(s).
> >
> > -Dimitry
> >
> Not a glib expert here, but you can try this https://pastebin.com/ty8hLjVU
>
>

-- 
Nuno Teixeira
FreeBSD Committer (ports)

Re: glib2 deprecated declarations failing on clang16

[Dimitry Andric]

I got to exactly the same patches. This is due to how glib's gclosure.h
header declares its callback function type as '(void)', even though in
reality the number and type of the arguments varies:

  /**
   * GCallback:
   *
   * The type used for callback functions in structure definitions and function
   * signatures.
   *
   * This doesn't mean that all callback functions must take no  parameters and
   * return void. The required signature of a callback function is determined 
by  
* the context in which is used (e.g. 
the signal to which it is connected).
   *
   * Use G_CALLBACK() to cast the callback function to a #GCallback.
   */
  typedef void  (*GCallback)  (void);

It would have been better if glib had just used '(...)', but the
solution they have chosen requires each callback function to be cast
using the G_CALLBACK() macro.

That basically shuts up any incompatible function pointer warnings, and
disables any argument checks.

-Dimitry

> On 4 Jul 2023, at 16:21, Nuno Teixeira  wrote:
> 
> Hello Danilo!
> 
> Yes, it builds ok.
> 
> I will do a run test tomorrow on bluefish.
> 
> Any hint on how to explain it in commit:
> 
> ---
> --- src/bftextview2_autocomp.c.orig 2023-07-04 14:09:37 UTC
> +++ src/bftextview2_autocomp.c
> @@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)
> /*gtk_widget_set_size_request(acw->reflabel,150,-1); */
> gtk_widget_show_all(acw->scroll);
> gtk_widget_show(hbox);
> -   g_signal_connect(acw->reflabel, "activate-link", 
> acw_label_active_link_lcb, acw);
> +   g_signal_connect(acw->reflabel, "activate-link", 
> G_CALLBACK(acw_label_active_link_lcb), acw);
> /*gtk_widget_set_size_request(GTK_WIDGET(acw->tree),100,200); */
> /*gtk_widget_set_size_request(acw->win, 150, 200); */
> 
> /*g_signal_connect(G_OBJECT(acw->win),"key-release-event",G_CALLBACK(acwin_key_release_lcb),acw);
>  */
> ---
> and
> ---
> --- src/external_commands.c.orig2023-07-04 14:12:18 UTC
> +++ src/external_commands.c
> @@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep, const gchar * fo
> 
> gtk_dialog_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);
> tmp = g_strdup_printf(_("Supply arguments to define %%a in 
> '%s'"), formatstring);
> entry = dialog_entry_labeled(NULL, tmp, 
> gtk_dialog_get_content_area(GTK_DIALOG(dialog)), 6);
> -   g_signal_connect(G_OBJECT(entry), "activate", 
> command_dialog_entry_activated_lcb, dialog);
> +   g_signal_connect(G_OBJECT(entry), "activate", 
> G_CALLBACK(command_dialog_entry_activated_lcb), dialog);
> g_free(tmp);
> gtk_widget_show_all(dialog);
> result = gtk_dialog_run(GTK_DIALOG(dialog));
> ---
> 
> Thanks!
> 
> Danilo Egea Gondolfo  escreveu no dia terça, 4/07/2023 
> à(s) 15:00:
> On 04/07/2023 14:56, Dimitry Andric wrote:
> 
> > On 4 Jul 2023, at 14:37, Nuno Teixeira  wrote:
> >> I'm getting build errors from current with www/bluefish about deprecated 
> >> glib2 declarations and causing build to fail with clang16:
> >> ---
> >> /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded from 
> >> macro 'G_DEPRECATED'
> >> #define G_DEPRECATED __attribute__((__deprecated__))
> >>  ^
> >> mv -f .deps/bluefish.Tpo .deps/bluefish.Po
> >> bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is 
> >> deprecated: Use 'g_thread_new' instead [-Wdeprecated-declarations]
> >>  g_thread_create_full(build_bflang2scan_thread, NULL, 0, FALSE, 
> >> FALSE, G_THREAD_PRIORITY_LOW, &gerror);
> >> ---
> >>
> >> Any help is welcome on finding out its cause.
> >>
> >> a related issue: https://github.com/PCSX2/pcsx2/issues/3315
> >>
> >> Build log: 
> >> https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log
> > The actual error is an incompatible callback function signature:
> >
> > bftextview2_autocomp.c:432:2: error: incompatible function pointer types 
> > passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka 'int (struct 
> > _GtkLabel *, char *, void *)') to parameter of type 'GCallback' (aka 'void 
> > (*)(void)') [-Wincompatible-function-pointer-types]
> > g_signal_connect(acw->reflabel, "activate-link", acw_label_active_link_lcb, 
> > acw);
> > ^~~~
> > /usr/local/include/glib-2.0/gobject/gsignal.h:515:59: note: expanded from 
> > macro 'g_signal_connect'
> > g_signal_connect_data ((instance), (detailed_signal), (c_handler), (data), 
> > NULL, (GConnectFlags) 0)
> > ^~~
> > /usr/local/include/glib-2.0/gobject/gsignal.h:411:25: note: passing 
> > argument to parameter 'c_handler' here
> > GCallback c_handler,
> > ^
> >
> > I have see

Re: glib2 deprecated declarations failing on clang16

[Nuno Teixeira]

And run test sucess at main-n263935-e8423423737e

I will do more testport builds with gtk2 and gtk3.

I will use something like in commit msg:
---
Fix build with clang16
Use G_CALLBACK() macro to silence incompatible function pointer warnings and
disables any argument checks.

Reported by: dim
---

Cheers,

Dimitry Andric  escreveu no dia terça, 4/07/2023 à(s)
15:31:

> I got to exactly the same patches. This is due to how glib's gclosure.h
> header declares its callback function type as '(void)', even though in
> reality the number and type of the arguments varies:
>
>   /**
>* GCallback:
>*
>* The type used for callback functions in structure definitions and
> function
>* signatures.
>*
>* This doesn't mean that all callback functions must take no
> parameters and
>* return void. The required signature of a callback function is
> determined by
> * the context in
> which is used (e.g. the signal to which it is connected).
>*
>* Use G_CALLBACK() to cast the callback function to a #GCallback.
>*/
>   typedef void  (*GCallback)  (void);
>
> It would have been better if glib had just used '(...)', but the
> solution they have chosen requires each callback function to be cast
> using the G_CALLBACK() macro.
>
> That basically shuts up any incompatible function pointer warnings, and
> disables any argument checks.
>
> -Dimitry
>
> > On 4 Jul 2023, at 16:21, Nuno Teixeira  wrote:
> >
> > Hello Danilo!
> >
> > Yes, it builds ok.
> >
> > I will do a run test tomorrow on bluefish.
> >
> > Any hint on how to explain it in commit:
> >
> > ---
> > --- src/bftextview2_autocomp.c.orig 2023-07-04 14:09:37 UTC
> > +++ src/bftextview2_autocomp.c
> > @@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)
> > /*gtk_widget_set_size_request(acw->reflabel,150,-1); */
> > gtk_widget_show_all(acw->scroll);
> > gtk_widget_show(hbox);
> > -   g_signal_connect(acw->reflabel, "activate-link",
> acw_label_active_link_lcb, acw);
> > +   g_signal_connect(acw->reflabel, "activate-link",
> G_CALLBACK(acw_label_active_link_lcb), acw);
> > /*gtk_widget_set_size_request(GTK_WIDGET(acw->tree),100,200); */
> > /*gtk_widget_set_size_request(acw->win, 150, 200); */
> >
>  
> /*g_signal_connect(G_OBJECT(acw->win),"key-release-event",G_CALLBACK(acwin_key_release_lcb),acw);
> */
> > ---
> > and
> > ---
> > --- src/external_commands.c.orig2023-07-04 14:12:18 UTC
> > +++ src/external_commands.c
> > @@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep, const gchar *
> fo
> >
>  gtk_dialog_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);
> > tmp = g_strdup_printf(_("Supply arguments to define %%a
> in '%s'"), formatstring);
> > entry = dialog_entry_labeled(NULL, tmp,
> gtk_dialog_get_content_area(GTK_DIALOG(dialog)), 6);
> > -   g_signal_connect(G_OBJECT(entry), "activate",
> command_dialog_entry_activated_lcb, dialog);
> > +   g_signal_connect(G_OBJECT(entry), "activate",
> G_CALLBACK(command_dialog_entry_activated_lcb), dialog);
> > g_free(tmp);
> > gtk_widget_show_all(dialog);
> > result = gtk_dialog_run(GTK_DIALOG(dialog));
> > ---
> >
> > Thanks!
> >
> > Danilo Egea Gondolfo  escreveu no dia terça,
> 4/07/2023 à(s) 15:00:
> > On 04/07/2023 14:56, Dimitry Andric wrote:
> >
> > > On 4 Jul 2023, at 14:37, Nuno Teixeira  wrote:
> > >> I'm getting build errors from current with www/bluefish about
> deprecated glib2 declarations and causing build to fail with clang16:
> > >> ---
> > >> /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded
> from macro 'G_DEPRECATED'
> > >> #define G_DEPRECATED __attribute__((__deprecated__))
> > >>  ^
> > >> mv -f .deps/bluefish.Tpo .deps/bluefish.Po
> > >> bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is
> deprecated: Use 'g_thread_new' instead [-Wdeprecated-declarations]
> > >>  g_thread_create_full(build_bflang2scan_thread, NULL, 0,
> FALSE, FALSE, G_THREAD_PRIORITY_LOW, &gerror);
> > >> ---
> > >>
> > >> Any help is welcome on finding out its cause.
> > >>
> > >> a related issue: https://github.com/PCSX2/pcsx2/issues/3315
> > >>
> > >> Build log:
> https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log
> > > The actual error is an incompatible callback function signature:
> > >
> > > bftextview2_autocomp.c:432:2: error: incompatible function pointer
> types passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka 'int (struct
> _GtkLabel *, char *, void *)') to parameter of type 'GCallback' (aka 'void
> (*)(void)') [-Wincompatible-function-pointer-types]
> > > g_signal_connect(acw->reflabel, "activate-link",
> acw_label_active_link_lcb, acw);
> > >
> ^

Re: glib2 deprecated declarations failing on clang16

[Nuno Teixeira]

(...)

Should this be applied upstream?
I could open a upstream PR about it.

Thanks,

Nuno Teixeira  escreveu no dia terça, 4/07/2023 à(s)
15:42:

> And run test sucess at main-n263935-e8423423737e
>
> I will do more testport builds with gtk2 and gtk3.
>
> I will use something like in commit msg:
> ---
> Fix build with clang16
> Use G_CALLBACK() macro to silence incompatible function pointer warnings
> and
> disables any argument checks.
>
> Reported by: dim
> ---
>
> Cheers,
>
> Dimitry Andric  escreveu no dia terça, 4/07/2023 à(s)
> 15:31:
>
>> I got to exactly the same patches. This is due to how glib's gclosure.h
>> header declares its callback function type as '(void)', even though in
>> reality the number and type of the arguments varies:
>>
>>   /**
>>* GCallback:
>>*
>>* The type used for callback functions in structure definitions and
>> function
>>* signatures.
>>*
>>* This doesn't mean that all callback functions must take no
>> parameters and
>>* return void. The required signature of a callback function is
>> determined by
>> * the context in
>> which is used (e.g. the signal to which it is connected).
>>*
>>* Use G_CALLBACK() to cast the callback function to a #GCallback.
>>*/
>>   typedef void  (*GCallback)  (void);
>>
>> It would have been better if glib had just used '(...)', but the
>> solution they have chosen requires each callback function to be cast
>> using the G_CALLBACK() macro.
>>
>> That basically shuts up any incompatible function pointer warnings, and
>> disables any argument checks.
>>
>> -Dimitry
>>
>> > On 4 Jul 2023, at 16:21, Nuno Teixeira  wrote:
>> >
>> > Hello Danilo!
>> >
>> > Yes, it builds ok.
>> >
>> > I will do a run test tomorrow on bluefish.
>> >
>> > Any hint on how to explain it in commit:
>> >
>> > ---
>> > --- src/bftextview2_autocomp.c.orig 2023-07-04 14:09:37 UTC
>> > +++ src/bftextview2_autocomp.c
>> > @@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)
>> > /*gtk_widget_set_size_request(acw->reflabel,150,-1); */
>> > gtk_widget_show_all(acw->scroll);
>> > gtk_widget_show(hbox);
>> > -   g_signal_connect(acw->reflabel, "activate-link",
>> acw_label_active_link_lcb, acw);
>> > +   g_signal_connect(acw->reflabel, "activate-link",
>> G_CALLBACK(acw_label_active_link_lcb), acw);
>> > /*gtk_widget_set_size_request(GTK_WIDGET(acw->tree),100,200); */
>> > /*gtk_widget_set_size_request(acw->win, 150, 200); */
>> >
>>  
>> /*g_signal_connect(G_OBJECT(acw->win),"key-release-event",G_CALLBACK(acwin_key_release_lcb),acw);
>> */
>> > ---
>> > and
>> > ---
>> > --- src/external_commands.c.orig2023-07-04 14:12:18 UTC
>> > +++ src/external_commands.c
>> > @@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep, const gchar *
>> fo
>> >
>>  gtk_dialog_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);
>> > tmp = g_strdup_printf(_("Supply arguments to define %%a
>> in '%s'"), formatstring);
>> > entry = dialog_entry_labeled(NULL, tmp,
>> gtk_dialog_get_content_area(GTK_DIALOG(dialog)), 6);
>> > -   g_signal_connect(G_OBJECT(entry), "activate",
>> command_dialog_entry_activated_lcb, dialog);
>> > +   g_signal_connect(G_OBJECT(entry), "activate",
>> G_CALLBACK(command_dialog_entry_activated_lcb), dialog);
>> > g_free(tmp);
>> > gtk_widget_show_all(dialog);
>> > result = gtk_dialog_run(GTK_DIALOG(dialog));
>> > ---
>> >
>> > Thanks!
>> >
>> > Danilo Egea Gondolfo  escreveu no dia terça,
>> 4/07/2023 à(s) 15:00:
>> > On 04/07/2023 14:56, Dimitry Andric wrote:
>> >
>> > > On 4 Jul 2023, at 14:37, Nuno Teixeira  wrote:
>> > >> I'm getting build errors from current with www/bluefish about
>> deprecated glib2 declarations and causing build to fail with clang16:
>> > >> ---
>> > >> /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: expanded
>> from macro 'G_DEPRECATED'
>> > >> #define G_DEPRECATED __attribute__((__deprecated__))
>> > >>  ^
>> > >> mv -f .deps/bluefish.Tpo .deps/bluefish.Po
>> > >> bftextview2_langmgr.c:2665:2: warning: 'g_thread_create_full' is
>> deprecated: Use 'g_thread_new' instead [-Wdeprecated-declarations]
>> > >>  g_thread_create_full(build_bflang2scan_thread, NULL, 0,
>> FALSE, FALSE, G_THREAD_PRIORITY_LOW, &gerror);
>> > >> ---
>> > >>
>> > >> Any help is welcome on finding out its cause.
>> > >>
>> > >> a related issue: https://github.com/PCSX2/pcsx2/issues/3315
>> > >>
>> > >> Build log:
>> https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log
>> > > The actual error is an incompatible callback function signature:
>> > >
>> > > bftextview2_autocomp.c:432:2: error: incompatible function pointer
>> types passing 'gboolean (GtkLabel *, gchar *, gpointer)' (aka 'int

Re: glib2 deprecated declarations failing on clang16

[Charlie Li]

Nuno Teixeira wrote:

(...)

Should this be applied upstream?
I could open a upstream PR about it.

After looking through some history on the glib side (which have been 
fixing incompatible function pointer conditions as they appear), 
G_CALLBACK() should be applied to bluefish. Upstreaming is a good idea.
Nuno Teixeira mailto:edua...@freebsd.org>> 
escreveu no dia terça, 4/07/2023 à(s) 15:42:


And run test sucess at main-n263935-e8423423737e

I will do more testport builds with gtk2 and gtk3.

I will use something like in commit msg:
---
Fix build with clang16
Use G_CALLBACK() macro to silence incompatible function pointer
warnings and
disables any argument checks.

Reported by: dim
---

Cheers,

Dimitry Andric mailto:d...@freebsd.org>> escreveu
no dia terça, 4/07/2023 à(s) 15:31:

I got to exactly the same patches. This is due to how glib's
gclosure.h
header declares its callback function type as '(void)', even
though in
reality the number and type of the arguments varies:

   /**
    * GCallback:
    *
    * The type used for callback functions in structure
definitions and function
    * signatures.
    *
    * This doesn't mean that all callback functions must take
no  parameters and
    * return void. The required signature of a callback function
is determined by   

       * the context in which is used (e.g. the signal to which

it is connected).
    *
    * Use G_CALLBACK() to cast the callback function to a
#GCallback.
    */
   typedef void  (*GCallback)              (void);

It would have been better if glib had just used '(...)', but the
solution they have chosen requires each callback function to be cast
using the G_CALLBACK() macro.

That basically shuts up any incompatible function pointer
warnings, and
disables any argument checks.

-Dimitry

 > On 4 Jul 2023, at 16:21, Nuno Teixeira mailto:edua...@freebsd.org>> wrote:
 >
 > Hello Danilo!
 >
 > Yes, it builds ok.
 >
 > I will do a run test tomorrow on bluefish.
 >
 > Any hint on how to explain it in commit:
 >
 > ---
 > --- src/bftextview2_autocomp.c.orig     2023-07-04 14:09:37 UTC
 > +++ src/bftextview2_autocomp.c
 > @@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)
 >         /*gtk_widget_set_size_request(acw->reflabel,150,-1); */
 >         gtk_widget_show_all(acw->scroll);
 >         gtk_widget_show(hbox);
 > -       g_signal_connect(acw->reflabel, "activate-link",
acw_label_active_link_lcb, acw);
 > +       g_signal_connect(acw->reflabel, "activate-link",
G_CALLBACK(acw_label_active_link_lcb), acw);
 >   
  /*gtk_widget_set_size_request(GTK_WIDGET(acw->tree),100,200); */

 >         /*gtk_widget_set_size_request(acw->win, 150, 200); */
 >   
  /*g_signal_connect(G_OBJECT(acw->win),"key-release-event",G_CALLBACK(acwin_key_release_lcb),acw); */

 > ---
 > and
 > ---
 > --- src/external_commands.c.orig        2023-07-04 14:12:18 UTC
 > +++ src/external_commands.c
 > @@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep,
const gchar * fo
 >   
  gtk_dialog_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);

 >                 tmp = g_strdup_printf(_("Supply arguments to
define %%a in '%s'"), formatstring);
 >                 entry = dialog_entry_labeled(NULL, tmp,
gtk_dialog_get_content_area(GTK_DIALOG(dialog)), 6);
 > -               g_signal_connect(G_OBJECT(entry), "activate",
command_dialog_entry_activated_lcb, dialog);
 > +               g_signal_connect(G_OBJECT(entry), "activate",
G_CALLBACK(command_dialog_entry_activated_lcb), dialog);
 >                 g_free(tmp);
 >                 gtk_widget_show_all(dialog);
 >                 result = gtk_dialog_run(GTK_DIALOG(dialog));
 > ---
 >
 > Thanks!
 >
 > Danilo Egea Gondolfo mailto:dan...@freebsd.org>> escreveu no dia terça, 4/07/2023
à(s) 15:00:
 > On 04/07/2023 14:56, Dimitry Andric wrote:
 >
 > > On 4 Jul 2023, at 14:37, Nuno Teixeira mailto:edua...@freebsd.org>> wrote:
 > >> I'm getting build errors from current with www/bluefish
about deprecated glib2 declarations and causing build to fail
with clang16:
 > >> ---
 > >> /usr/local/include/glib-2.0/glib/gmacros.h:12

More swap trouble with armv7, was Re: -current on armv7 stuck with flashing disk light

[bob prohaska]

On Tue, Jun 27, 2023 at 10:16:57AM -0700, bob prohaska wrote:
> On Tue, Jun 27, 2023 at 09:59:40AM -0700, Mark Millard wrote:
> > > 
> > > If you want to identify system hangs, please
> > > put back:
> > > 
> > > vm.swap_enabled=0
> > > vm.swap_idle_enabled=0
> > > 
> 
> They're reinstated now, but I don't want to disturb the system
> while it seems to be building world acceptably. 
> 
Reinstating 
vm.swap_enabled=0
vm.swap_idle_enabled=0

and limiting buildworld to -j3 allows buildworld to complete successfully in 1 
GB of swap.

Meanwhile, attempts to compile sysutils/usbtop using poudriere still cause swap 
exhaustion
while compiling /devel/llvm15 even with 2 GB of swap allocated. 

The messages are
Jul  4 11:18:48 www kernel: pid 1074 (getty), jid 0, uid 0, was killed: out of 
swap space
swap blk zone exhausted, increase kern.maxswzone
swblk zone ok

IIRC the "increase kern.maxswzone" is unhelpful, if not impossible. The
"swblk zone ok" seems new. 

>From the gstat output near peak swap use the system wasn't I/O bound,
the disk was less than 25% busy at the time of the first OOMA kill.
Eventually it was possible to log in on the serial console and run top:

33 processes:  1 running, 29 sleeping, 3 zombie
CPU:  0.0% user,  0.0% nice, 10.6% system,  0.2% interrupt, 89.2% idle
Mem: 139M Active, 8256K Inact, 252M Laundry, 221M Wired, 98M Buf, 292M Free
Swap: 2048M Total, 1291M Used, 756M Free, 63% Inuse

  PID   JID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU 
COMMAND
40719 0 root  1  20  -20 0B  8192B swzonx   0   0:12   9.15% 
cron
40717 0 root  1  20  -20 0B  8192B swzonx   0   0:34   9.08% sh
40709 0 root  1  20  -20 0B  8192B swzonx   0   0:38   9.01% 
sshd
40720 0 root  1  20  -20 0B  8192B swzonx   3   0:13   7.47% sh
40721 0 bob   1  200  6608K  2600K CPU1 1   0:00   0.32% top
25761 0 bob   1  20014M  6136K select   0   0:02   0.03% 
sshd
25852 0 root  1  200  4668K  1648K ttyin1   0:01   0.03% tip
 1237 0 root  1  200  5820K  1540K wait 1   0:12   0.00% sh
25381 0 root  1  23014M  5868K select   1   0:01   0.00% 
sshd
 1030 0 root  1  24013M  2416K vmbckw   1   0:00   0.00% 
sshd
12715 0 root  1  680  5820K  1660K wait 0   0:00   0.00% sh
12710 0 root  1  200  5820K  1556K piperd   1   0:00   0.00% sh
  929 0 root  1  200  5356K  1256K select   3   0:00   0.00% 
syslogd
 1014 0 root  1  200  5124K  1356K nanslp   2   0:00   0.00% 
cron
25770 0 bob   1  360  6844K  3116K pause1   0:00   0.00% 
tcsh
25794 0 bob   1  240  5380K  2188K wait 2   0:00   0.00% su
39626 0 root  1  200  5424K  2404K wait 2   0:00   0.00% 
login
40635 0 bob   1  200  6824K  3272K pause1   0:00   0.00% 
tcsh
25820 0 root  1  210  5608K  2204K wait 0   0:00   0.00% sh
25851 0 root  1  200  4668K  1656K ttyin3   0:00   0.00% tip
40454 0 root  1  240  4636K  1780K ttyin3   0:00   0.00% 
getty

I'll let it go for a while to see if poudriere notices it's failed and cleans 
up.

At the moment /boot/loader.conf contains

# Configure USB OTG; see usb_template(4).
hw.usb.template=3
umodem_load="YES"
# Disable the beastie menu and color
beastie_disable="YES"
loader_color="NO"
vm.pageout_oom_seq="4096"
vm.pfault_oom_attempts="3"
vm.pfault_oom_attempts="120"
vm.pfault_oom_wait="20"
kern.cam.boot_delay="2"
vfs.ffs.dotrimcons="1"
vfs.root_mount_always_wait="1"
filemon_load="YES"

/usr/local/etc/poudriere.conf contains
USE_TMPFS=no
NOHANG_TIME=28800
MAX_EXECUTION_TIME_EXTRACT=14400
MAX_EXECUTION_TIME_INSTALL=14400
MAX_EXECUTION_TIME_PACKAGE=432000
ALLOW_MAKE_JOBS=yes
MAX_JOBS_NUMBER=2
MAKE_JOBS_NUMBER=2

Do these settings look reasonable?

Thanks for writing!

bob prohaska

commiter needed for pecl-imagick merge (6 and 7) PR 268833

[Miroslav Lachman]

For historic reason there are pecl-imagick depending on ImageMagick 6 
and pecl-imagick-im7 depending on ImageMagick 7. As far as I know no 
ports depend on pecl-imagick with ImageMagic 6 by default now so it is 
safe to remove pecl-imagick-im7 and use pecl-imagick with the new 
USES=imagick to build with the right ImageMagick version.
It should also be added to MOVED and there should be small update of 
dependencies in Makefile of ports: Nextcloud, Piwigo and Wordpress.
I created one large patch for all this steps and also small patches for 
each of this step alone.

Please check it / test it and commit it.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268833

(my last patches for pecl-imagick were left uncommitted from March 2023)

Kind regards
Miroslav Lachman

Re: More swap trouble with armv7, was Re: -current on armv7 stuck with flashing disk light

[Mark Millard]

On Jul 4, 2023, at 12:07, bob prohaska  wrote:

> On Tue, Jun 27, 2023 at 10:16:57AM -0700, bob prohaska wrote:
>> On Tue, Jun 27, 2023 at 09:59:40AM -0700, Mark Millard wrote:
 
 If you want to identify system hangs, please
 put back:
 
 vm.swap_enabled=0
 vm.swap_idle_enabled=0
 
>> 
>> They're reinstated now, but I don't want to disturb the system
>> while it seems to be building world acceptably. 
>> 
> Reinstating 
> vm.swap_enabled=0
> vm.swap_idle_enabled=0
> 
> and limiting buildworld to -j3 allows buildworld to complete successfully in 
> 1 GB of swap.
> 
> Meanwhile, attempts to compile sysutils/usbtop using poudriere still cause 
> swap exhaustion
> while compiling /devel/llvm15 even with 2 GB of swap allocated. 

What sort of parallelism settings in poudriere for the
devel/llvm15 build attempt? Have you tried allowing
less parallelism (if there is a less for what you have
tried)?

What options are enabled vs. disabled for devel/llvm15 ?

BE_STANDARD vs. BE_FREEBSD vs. BE_NATIVE ?

BE_NATIVE probably help limit resource use the most if it
happens to be sufficient. BE_FREEBSD would be in the
middle of the 3 options for this issue.

Is MLIR enabled? If having it disabled is sufficient, it
being disabled should help avoid as much resource use.
Simiarly for FLANG. (Building FLANG requires MLIR, so
having MLIR disabled implies FLANG needing to also be
disabled.)

> The messages are
> Jul  4 11:18:48 www kernel: pid 1074 (getty), jid 0, uid 0, was killed: out 
> of swap space

In my view the "out of swap space" is still a misleading
misnomer for this context, but at least the following
messages are more specific to the actual internal
data-structure(s) problem(s). My understanding is that
the data structures can have fragmentation issues.

For fragmentation issues, prior history since booting
might contribute, and building just after a reboot may
end up with less fragmentation. (Unknown if sufficiently
less.)

Also, over allocating the swap partition (by not having
kern.maxswzone appropriately matching) likely makes
"swap blk zone exhausted" more likely. It is one of the
reasons I avoid using swap partitioning with a total
size that generates the message about possible
mistuning.

> swap blk zone exhausted, increase kern.maxswzone

Have you ever gotten the above line before? I was
unaware of any examples of it showing up.

> swblk zone ok

I'll note that there is another potential message
pair for "swap pctrie zone exhausted"/"swpctrie zone ok"
that you have not reported getting.

Have you ever seen the "swap pctrie zone exhausted"
notice? (Just curiosity on my part.)

> IIRC the "increase kern.maxswzone" is unhelpful, if not impossible. The
> "swblk zone ok" seems new. 

Are you using the default kern.maxswzone for your context?
What is its value?

Did you get the notice about possible mistuning for your
combination of swap partition sizing and kern.maxswzone
value? Or did "swap blk zone" happen even without that
notice happening?

> From the gstat output near peak swap use the system wasn't I/O bound,

The "swap blk zone" contains an in-kernel-RAM data
structure that is involved in managing the swap space
usage.

> the disk was less than 25% busy at the time of the first OOMA kill.

"swap blk zone" can end up with fragmentation issues, where
the total available is only made up of a bunch of tiny chunks
and nothing large can be handled as a unit any more. (A general
description of "fragmented".)

> Eventually it was possible to log in on the serial console and run top:
> 
> 33 processes:  1 running, 29 sleeping, 3 zombie
> CPU:  0.0% user,  0.0% nice, 10.6% system,  0.2% interrupt, 89.2% idle
> Mem: 139M Active, 8256K Inact, 252M Laundry, 221M Wired, 98M Buf, 292M Free
> Swap: 2048M Total, 1291M Used, 756M Free, 63% Inuse
> 
>  PID   JID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU 
> COMMAND
> 40719 0 root  1  20  -20 0B  8192B swzonx   0   0:12   9.15% 
> cron
> 40717 0 root  1  20  -20 0B  8192B swzonx   0   0:34   9.08% 
> sh
> 40709 0 root  1  20  -20 0B  8192B swzonx   0   0:38   9.01% 
> sshd
> 40720 0 root  1  20  -20 0B  8192B swzonx   3   0:13   7.47% 
> sh

Unfortunately the swzonx text is truncated. There is
actually:

pause("swzonxb", 10); for swblk zone
and:
pause("swzonxp", 10); for swap pctrie zone

top's display leaves it unclear which was involved.

> 40721 0 bob   1  200  6608K  2600K CPU1 1   0:00   0.32% 
> top
> 25761 0 bob   1  20014M  6136K select   0   0:02   0.03% 
> sshd
> 25852 0 root  1  200  4668K  1648K ttyin1   0:01   0.03% 
> tip
> 1237 0 root  1  200  5820K  1540K wait 1   0:12   0.00% sh
> 25381 0 root  1  23014M  5868K select   1   0:01   0.00% 
> sshd
> 1030 0 root  1  24013M  2416K vmbckw   1   0:00   0.00% 
> sshd
> 12715 0 root  

Re: More swap trouble with armv7, was Re: -current on armv7 stuck with flashing disk light

[Mark Millard]

[I continued to type MAX_JOBS_NUMBER where
MAKE_JOBS_NUMBER should have been what I
typed.]

On Jul 4, 2023, at 14:22, Mark Millard  wrote:

> On Jul 4, 2023, at 12:07, bob prohaska  wrote:
> 
>> On Tue, Jun 27, 2023 at 10:16:57AM -0700, bob prohaska wrote:
>>> On Tue, Jun 27, 2023 at 09:59:40AM -0700, Mark Millard wrote:
> 
> If you want to identify system hangs, please
> put back:
> 
> vm.swap_enabled=0
> vm.swap_idle_enabled=0
> 
>>> 
>>> They're reinstated now, but I don't want to disturb the system
>>> while it seems to be building world acceptably. 
>>> 
>> Reinstating 
>> vm.swap_enabled=0
>> vm.swap_idle_enabled=0
>> 
>> and limiting buildworld to -j3 allows buildworld to complete successfully in 
>> 1 GB of swap.
>> 
>> Meanwhile, attempts to compile sysutils/usbtop using poudriere still cause 
>> swap exhaustion
>> while compiling /devel/llvm15 even with 2 GB of swap allocated. 
> 
> What sort of parallelism settings in poudriere for the
> devel/llvm15 build attempt? Have you tried allowing
> less parallelism (if there is a less for what you have
> tried)?
> 
> What options are enabled vs. disabled for devel/llvm15 ?
> 
> BE_STANDARD vs. BE_FREEBSD vs. BE_NATIVE ?
> 
> BE_NATIVE probably help limit resource use the most if it
> happens to be sufficient. BE_FREEBSD would be in the
> middle of the 3 options for this issue.
> 
> Is MLIR enabled? If having it disabled is sufficient, it
> being disabled should help avoid as much resource use.
> Simiarly for FLANG. (Building FLANG requires MLIR, so
> having MLIR disabled implies FLANG needing to also be
> disabled.)
> 
>> The messages are
>> Jul  4 11:18:48 www kernel: pid 1074 (getty), jid 0, uid 0, was killed: out 
>> of swap space
> 
> In my view the "out of swap space" is still a misleading
> misnomer for this context, but at least the following
> messages are more specific to the actual internal
> data-structure(s) problem(s). My understanding is that
> the data structures can have fragmentation issues.
> 
> For fragmentation issues, prior history since booting
> might contribute, and building just after a reboot may
> end up with less fragmentation. (Unknown if sufficiently
> less.)
> 
> Also, over allocating the swap partition (by not having
> kern.maxswzone appropriately matching) likely makes
> "swap blk zone exhausted" more likely. It is one of the
> reasons I avoid using swap partitioning with a total
> size that generates the message about possible
> mistuning.
> 
>> swap blk zone exhausted, increase kern.maxswzone
> 
> Have you ever gotten the above line before? I was
> unaware of any examples of it showing up.
> 
>> swblk zone ok
> 
> I'll note that there is another potential message
> pair for "swap pctrie zone exhausted"/"swpctrie zone ok"
> that you have not reported getting.
> 
> Have you ever seen the "swap pctrie zone exhausted"
> notice? (Just curiosity on my part.)
> 
>> IIRC the "increase kern.maxswzone" is unhelpful, if not impossible. The
>> "swblk zone ok" seems new. 
> 
> Are you using the default kern.maxswzone for your context?
> What is its value?
> 
> Did you get the notice about possible mistuning for your
> combination of swap partition sizing and kern.maxswzone
> value? Or did "swap blk zone" happen even without that
> notice happening?
> 
>> From the gstat output near peak swap use the system wasn't I/O bound,
> 
> The "swap blk zone" contains an in-kernel-RAM data
> structure that is involved in managing the swap space
> usage.
> 
>> the disk was less than 25% busy at the time of the first OOMA kill.
> 
> "swap blk zone" can end up with fragmentation issues, where
> the total available is only made up of a bunch of tiny chunks
> and nothing large can be handled as a unit any more. (A general
> description of "fragmented".)
> 
>> Eventually it was possible to log in on the serial console and run top:
>> 
>> 33 processes:  1 running, 29 sleeping, 3 zombie
>> CPU:  0.0% user,  0.0% nice, 10.6% system,  0.2% interrupt, 89.2% idle
>> Mem: 139M Active, 8256K Inact, 252M Laundry, 221M Wired, 98M Buf, 292M Free
>> Swap: 2048M Total, 1291M Used, 756M Free, 63% Inuse
>> 
>> PID   JID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU 
>> COMMAND
>> 40719 0 root  1  20  -20 0B  8192B swzonx   0   0:12   9.15% 
>> cron
>> 40717 0 root  1  20  -20 0B  8192B swzonx   0   0:34   9.08% 
>> sh
>> 40709 0 root  1  20  -20 0B  8192B swzonx   0   0:38   9.01% 
>> sshd
>> 40720 0 root  1  20  -20 0B  8192B swzonx   3   0:13   7.47% 
>> sh
> 
> Unfortunately the swzonx text is truncated. There is
> actually:
> 
> pause("swzonxb", 10); for swblk zone
> and:
> pause("swzonxp", 10); for swap pctrie zone
> 
> top's display leaves it unclear which was involved.
> 
>> 40721 0 bob   1  200  6608K  2600K CPU1 1   0:00   0.32% 
>> top
>> 25761 0 bob   1  20014M  6136K select   0   0:02   0.03% 
>> sshd
>

Update dependencies for mailman3

[Einar Bjarni Halldórsson]

Hi,

Today mailman3 stopped working, probably because of update of 
py-setuptools. Needed dependecies are not listed by mail/mailman3 and 
some are wrong.


I've created two PR to fix the problem.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272375 - upgrade 
mail/py-authheaders to latest version and become maintainer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272376 - Update 
dependencies for mail/mailman3. Update versions and add missing dependencies


I've built all packages with these changes in poudriere and I'm running 
with them now.


I'd appreciate if a committer could take a look and get these committed 
since the port is broken as-is.


.einar

Re: More swap trouble with armv7, was Re: -current on armv7 stuck with flashing disk light

[Tatsuki Makino]

Hello.

Mark Millard wrote on 2023/07/05 06:51:
> [I continued to type MAX_JOBS_NUMBER where
> MAKE_JOBS_NUMBER should have been what I
> typed.]
> 

It may be possible to set stricter restrictions on selected ports in 
/usr/local/etc/poudriere.d/make.conf.
For example,

# normally
.if ${.CURDIR:tA} == "/usr/ports/devel/llvm15"
MAKE_JOBS_NUMBER=   1
.endif

# pattern matching can be performed
.if !empty(.CURDIR:tA:M/usr/ports/devel/llvm15) ||
!empty(.CURDIR:tA:M/usr/ports/devel/llvm*)
MAKE_JOBS_NUMBER=   1
.endif

# not limited to /usr/ports
.if !empty(.CURDIR:tA:T:Mllvm*) && !empty(.CURDIR:tA:H:T:Mdevel)
MAKE_JOBS_NUMBER=   1
.endif

If we write this on an individual port basis, we can use the resources to the 
very limit where they don't overflow :)

Regards.

Re: glib2 deprecated declarations failing on clang16

[Nuno Teixeira]

Hello all,

Ticket opened at upstream: https://sourceforge.net/p/bluefish/tickets/75/

https://cgit.freebsd.org/ports/commit/?id=e95c4bea425b3e3c49b63e0cf4eff24af40c574b

Thank you!

Charlie Li  escreveu no dia terça, 4/07/2023 à(s)
18:33:

> Nuno Teixeira wrote:
> > (...)
> >
> > Should this be applied upstream?
> > I could open a upstream PR about it.
> >
> After looking through some history on the glib side (which have been
> fixing incompatible function pointer conditions as they appear),
> G_CALLBACK() should be applied to bluefish. Upstreaming is a good idea.
> > Nuno Teixeira mailto:edua...@freebsd.org>>
> > escreveu no dia terça, 4/07/2023 à(s) 15:42:
> >
> > And run test sucess at main-n263935-e8423423737e
> >
> > I will do more testport builds with gtk2 and gtk3.
> >
> > I will use something like in commit msg:
> > ---
> > Fix build with clang16
> > Use G_CALLBACK() macro to silence incompatible function pointer
> > warnings and
> > disables any argument checks.
> >
> > Reported by: dim
> > ---
> >
> > Cheers,
> >
> > Dimitry Andric mailto:d...@freebsd.org>> escreveu
> > no dia terça, 4/07/2023 à(s) 15:31:
> >
> > I got to exactly the same patches. This is due to how glib's
> > gclosure.h
> > header declares its callback function type as '(void)', even
> > though in
> > reality the number and type of the arguments varies:
> >
> >/**
> > * GCallback:
> > *
> > * The type used for callback functions in structure
> > definitions and function
> > * signatures.
> > *
> > * This doesn't mean that all callback functions must take
> > no  parameters and
> > * return void. The required signature of a callback function
> > is determined by
> >
> >* the context in which is used (e.g. the signal to which
> > it is connected).
> > *
> > * Use G_CALLBACK() to cast the callback function to a
> > #GCallback.
> > */
> >typedef void  (*GCallback)  (void);
> >
> > It would have been better if glib had just used '(...)', but the
> > solution they have chosen requires each callback function to be
> cast
> > using the G_CALLBACK() macro.
> >
> > That basically shuts up any incompatible function pointer
> > warnings, and
> > disables any argument checks.
> >
> > -Dimitry
> >
> >  > On 4 Jul 2023, at 16:21, Nuno Teixeira  > > wrote:
> >  >
> >  > Hello Danilo!
> >  >
> >  > Yes, it builds ok.
> >  >
> >  > I will do a run test tomorrow on bluefish.
> >  >
> >  > Any hint on how to explain it in commit:
> >  >
> >  > ---
> >  > --- src/bftextview2_autocomp.c.orig 2023-07-04 14:09:37
> UTC
> >  > +++ src/bftextview2_autocomp.c
> >  > @@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)
> >  > /*gtk_widget_set_size_request(acw->reflabel,150,-1);
> */
> >  > gtk_widget_show_all(acw->scroll);
> >  > gtk_widget_show(hbox);
> >  > -   g_signal_connect(acw->reflabel, "activate-link",
> > acw_label_active_link_lcb, acw);
> >  > +   g_signal_connect(acw->reflabel, "activate-link",
> > G_CALLBACK(acw_label_active_link_lcb), acw);
> >  >
> >   /*gtk_widget_set_size_request(GTK_WIDGET(acw->tree),100,200);
> */
> >  > /*gtk_widget_set_size_request(acw->win, 150, 200); */
> >  >
> >
>  
> /*g_signal_connect(G_OBJECT(acw->win),"key-release-event",G_CALLBACK(acwin_key_release_lcb),acw);
> */
> >  > ---
> >  > and
> >  > ---
> >  > --- src/external_commands.c.orig2023-07-04 14:12:18
> UTC
> >  > +++ src/external_commands.c
> >  > @@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep,
> > const gchar * fo
> >  >
> >
>  gtk_dialog_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);
> >  > tmp = g_strdup_printf(_("Supply arguments to
> > define %%a in '%s'"), formatstring);
> >  > entry = dialog_entry_labeled(NULL, tmp,
> > gtk_dialog_get_content_area(GTK_DIALOG(dialog)), 6);
> >  > -   g_signal_connect(G_OBJECT(entry), "activate",
> > command_dialog_entry_activated_lcb, dialog);
> >  > +   g_signal_connect(G_OBJECT(entry), "activate",
> > G_CALLBACK(command_dialog_entry_activated_lcb), dialog);
> >  > g_free(tmp);
> >  > gtk_widget_show_all(dialog);
> >  > result = gtk_dialog_run(GTK_DIALOG(dialog));
> >  > ---
> >  >
> 

Re: More swap trouble with armv7, was Re: -current on armv7 stuck with flashing disk light

[bob prohaska]

On Wed, Jul 05, 2023 at 08:22:43AM +0900, Tatsuki Makino wrote:
> Hello.
> 
> 
> It may be possible to set stricter restrictions on selected ports in 
> /usr/local/etc/poudriere.d/make.conf.
> For example,
> 
> # normally
> .if ${.CURDIR:tA} == "/usr/ports/devel/llvm15"
> MAKE_JOBS_NUMBER= 1
> .endif
> 
> # pattern matching can be performed
> .if !empty(.CURDIR:tA:M/usr/ports/devel/llvm15) ||
> !empty(.CURDIR:tA:M/usr/ports/devel/llvm*)
> MAKE_JOBS_NUMBER= 1
> .endif
> 
> # not limited to /usr/ports
> .if !empty(.CURDIR:tA:T:Mllvm*) && !empty(.CURDIR:tA:H:T:Mdevel)
> MAKE_JOBS_NUMBER= 1
> .endif
> 
> If we write this on an individual port basis, we can use the resources to the 
> very limit where they don't overflow :)
> 

I just tried to turn off parallel jobs entirely by omitting
ALLOW_MAKE_JOBS
from /usr/local/etc/poudriere.conf. The machine ran out of 
swap as usual, in about the same time, despite having only
two processes running that were visibly related to poudriere
with a total size of ~250 MB. The number of threads roughly
halved, but the time to swap exhaustion didn't. 

While poudriere makes /devel/llvm15 by itself, top reports

last pid: 15623;  load averages:  0.88,  0.88,  0.75up 0+00:26:27  
17:39:54
34 processes:  2 running, 32 sleeping
CPU: 27.9% user,  0.0% nice,  7.3% system,  0.0% interrupt, 64.8% idle
Mem: 274M Active, 219M Inact, 177M Laundry, 221M Wired, 97M Buf, 22M Free
Swap: 2048M Total, 1032M Used, 1016M Free, 50% Inuse

  PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU COMMAND
14989 root  1  20041M25M select   2   0:10   0.01% 
pkg-static
 1080 bob   1  20014M  1460K select   0   0:00   0.00% sshd
 1077 root  1  31014M  1420K select   0   0:00   0.00% sshd
 1029 root  1  23013M  1600K select   1   0:00   0.00% sshd
 1042 root  1  20010M  1616K select   0   0:00   0.00% sendmail
14988 root  1  68010M  2976K wait 0   0:00   0.00% 
pkg-static
 1045 smmsp 1  68010M  1344K pause0   0:00   0.00% sendmail
15405 root  1 1260  9432K  6636K CPU1 1   0:15 100.04% 
makewhatis
 1081 bob   1  480  6852K  1016K pause1   0:00   0.00% tcsh
 1162 bob   1  520  6824K  1016K pause3   0:00   0.00% tcsh
 1166 bob   1  200  6688K  1784K CPU3 3   0:05   0.30% top
  726 root  1  200  6612K  1348K select   3   0:00   0.00% devd
11515 root  1  680  6568K  2812K wait 3   0:01   0.00% make
 1399 root  1  680  6212K  1712K nanslp   1   0:33   4.92% sh
 8353 root  1  530  5820K  1632K piperd   0   0:00   0.00% sh
 1099 root  1  200  5820K  1624K select   1   0:10   0.00% sh
 8360 root  1  680  5820K  1588K wait 3   0:00   0.00% sh
 1086 root  1  200  5584K  1048K ttyin2   0:00   0.00% sh
11543 root  1  680  5480K  1548K wait 1   0:00   0.00% sh
 1076 root  1  210  5424K  1120K wait 2   0:00   0.00% login
 1085 bob   1  240  5380K  1116K wait 3   0:00   0.00% su



The SIZE numbers in relation to swap used are puzzling. Shouldn't
swap be roughly the difference between total of SIZE minus total of RES?
That's not the case, unless my eyeball math is way off.

The poudriere run just failed, in the same way as before, with 1228 MB
of swap in use.

It's tempting to try running make in /usr/ports/devel/llvm15, just
to see if there's a difference in behavior.

Thanks for reading,

bob prohaska

Unmaintained FreeBSD ports which are out of date

[portscout]

Dear port maintainers,

The portscout new distfile checker has detected that one or more
unmaintained ports appears to be out of date. Please take the opportunity
to check each of the ports listed below, and if possible and appropriate,
submit/commit an update. Please consider also adopting this port.
If any ports have already been updated, you can safely ignore the entry.

An e-mail will not be sent again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/py-archinfo   | 9.0.5405| v9.2.58
+-+
security/py-ailment | 9.0.5405| v9.2.58
+-+
security/py-angr| 9.0.5405| v9.2.58
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!