Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Jul 2023 15:50:54 +0100
From:      Nuno Teixeira <eduardo@freebsd.org>
To:        Dimitry Andric <dim@freebsd.org>
Cc:        Danilo Egea Gondolfo <danilo@freebsd.org>, FreeBSD Ports <ports@freebsd.org>
Subject:   Re: glib2 deprecated declarations failing on clang16
Message-ID:  <CAFDf7ULvS9cQZ4Exzpn5j3hohU03SWjenLHG_XcRCN=pN0RfXQ@mail.gmail.com>
In-Reply-To: <CAFDf7UJmiM8Lk4Ua--h2YY6WCwsNgXDHnPJrv4YaJCyGqj3fAw@mail.gmail.com>
References:  <CAFDf7U%2B-M1D7xL_AkB-eY%2B0jq2JjjdhzoZUZtnmanVoa25vOtQ@mail.gmail.com> <BBD89BC1-8E9D-4E6D-887E-4A785F4A21D4@FreeBSD.org> <ffcb1751-dc86-b241-d7aa-f54896851697@FreeBSD.org> <CAFDf7ULBM1pV_X6OeRKbEggfyGcd0j-LuF720usWtM8KaG%2BJFA@mail.gmail.com> <22F61A7B-3566-4761-8D7A-DC78B9CF20E6@FreeBSD.org> <CAFDf7UJmiM8Lk4Ua--h2YY6WCwsNgXDHnPJrv4YaJCyGqj3fAw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000a9911205ffaa69dd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

(...)

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

Thanks,

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia ter=C3=A7a, 4/07/2023 =
=C3=A0(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 <dim@freebsd.org> escreveu no dia ter=C3=A7a, 4/07/2023 =
=C3=A0(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 <eduardo@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(ac=
win_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 =3D g_strdup_printf(_("Supply arguments to define =
%%a
>> in '%s'"), formatstring);
>> >                 entry =3D 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 =3D gtk_dialog_run(GTK_DIALOG(dialog));
>> > ---
>> >
>> > Thanks!
>> >
>> > Danilo Egea Gondolfo <danilo@freebsd.org> escreveu no dia ter=C3=A7a,
>> 4/07/2023 =C3=A0(s) 15:00:
>> > On 04/07/2023 14:56, Dimitry Andric wrote:
>> >
>> > > On 4 Jul 2023, at 14:37, Nuno Teixeira <eduardo@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: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/pf46bd2c58=
425_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 (stru=
ct
>> _GtkLabel *, char *, void *)') to parameter of type 'GCallback' (aka 'vo=
id
>> (*)(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)
>>
>>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000a9911205ffaa69dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>(...)</div><div><br></div><div>Should this be applied=
 upstream?<br></div><div>I could open a upstream PR about it.<br></div><div=
><br></div><div>Thanks,<br></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">Nuno Teixeira &lt;<a href=3D"mailto:eduard=
o@freebsd.org">eduardo@freebsd.org</a>&gt; escreveu no dia ter=C3=A7a, 4/07=
/2023 =C3=A0(s) 15:42:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div>And run test sucess at main-n263935-e842342373=
7e</div><div><br></div><div>I will do more testport builds with gtk2 and gt=
k3.</div><div><br></div><div>I will use something like in commit msg:</div>=
<div>---</div><div>Fix build with clang16<br></div><div>Use G_CALLBACK() ma=
cro to silence incompatible function pointer warnings and<br>
disables any argument checks.<br><br>Reported by: dim<br>---</div><div><br>=
</div><div>Cheers,<br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">Dimitry Andric &lt;<a href=3D"mailto:dim@free=
bsd.org" target=3D"_blank">dim@freebsd.org</a>&gt; escreveu no dia ter=C3=
=A7a, 4/07/2023 =C3=A0(s) 15:31:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">I got to exactly the same patches. This is due to how glib=
&#39;s gclosure.h<br>
header declares its callback function type as &#39;(void)&#39;, even though=
 in<br>
reality the number and type of the arguments varies:<br>
<br>
=C2=A0 /**<br>
=C2=A0 =C2=A0* GCallback:<br>
=C2=A0 =C2=A0*<br>
=C2=A0 =C2=A0* The type used for callback functions in structure definition=
s and function<br>
=C2=A0 =C2=A0* signatures.<br>
=C2=A0 =C2=A0*<br>
=C2=A0 =C2=A0* This doesn&#39;t mean that all callback functions must take =
no=C2=A0 parameters and<br>
=C2=A0 =C2=A0* return void. The required signature of a callback function i=
s determined by=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * the context i=
n which is used (e.g. the signal to which it is connected).<br>
=C2=A0 =C2=A0*<br>
=C2=A0 =C2=A0* Use G_CALLBACK() to cast the callback function to a #GCallba=
ck.<br>
=C2=A0 =C2=A0*/<br>
=C2=A0 typedef void=C2=A0 (*GCallback)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 (void);<br>
<br>
It would have been better if glib had just used &#39;(...)&#39;, but the<br=
>
solution they have chosen requires each callback function to be cast<br>
using the G_CALLBACK() macro.<br>
<br>
That basically shuts up any incompatible function pointer warnings, and<br>
disables any argument checks.<br>
<br>
-Dimitry<br>
<br>
&gt; On 4 Jul 2023, at 16:21, Nuno Teixeira &lt;<a href=3D"mailto:eduardo@f=
reebsd.org" target=3D"_blank">eduardo@freebsd.org</a>&gt; wrote:<br>
&gt; <br>
&gt; Hello Danilo!<br>
&gt; <br>
&gt; Yes, it builds ok.<br>
&gt; <br>
&gt; I will do a run test tomorrow on bluefish.<br>
&gt; <br>
&gt; Any hint on how to explain it in commit:<br>
&gt; <br>
&gt; ---<br>
&gt; --- src/bftextview2_autocomp.c.orig=C2=A0 =C2=A0 =C2=A02023-07-04 14:0=
9:37 UTC<br>
&gt; +++ src/bftextview2_autocomp.c<br>
&gt; @@ -429,7 +429,7 @@ acwin_create(BluefishTextView * btv)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*gtk_widget_set_size_request(acw-&gt=
;reflabel,150,-1); */<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_widget_show_all(acw-&gt;scroll);<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_widget_show(hbox);<br>
&gt; -=C2=A0 =C2=A0 =C2=A0 =C2=A0g_signal_connect(acw-&gt;reflabel, &quot;a=
ctivate-link&quot;, acw_label_active_link_lcb, acw);<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0g_signal_connect(acw-&gt;reflabel, &quot;a=
ctivate-link&quot;, G_CALLBACK(acw_label_active_link_lcb), acw);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*gtk_widget_set_size_request(GTK_WID=
GET(acw-&gt;tree),100,200); */<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*gtk_widget_set_size_request(acw-&gt=
;win, 150, 200); */<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*g_signal_connect(G_OBJECT(acw-&gt;w=
in),&quot;key-release-event&quot;,G_CALLBACK(acwin_key_release_lcb),acw); *=
/<br>
&gt; ---<br>
&gt; and<br>
&gt; ---<br>
&gt; --- src/external_commands.c.orig=C2=A0 =C2=A0 =C2=A0 =C2=A0 2023-07-04=
 14:12:18 UTC<br>
&gt; +++ src/external_commands.c<br>
&gt; @@ -483,7 +483,7 @@ create_commandstring(Texternalp * ep, const gchar =
* fo<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_dialo=
g_set_default_response(GTK_DIALOG(dialog),GTK_RESPONSE_ACCEPT);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tmp =3D g=
_strdup_printf(_(&quot;Supply arguments to define %%a in &#39;%s&#39;&quot;=
), formatstring);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entry =3D=
 dialog_entry_labeled(NULL, tmp, gtk_dialog_get_content_area(GTK_DIALOG(dia=
log)), 6);<br>
&gt; -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g_signal_conne=
ct(G_OBJECT(entry), &quot;activate&quot;, command_dialog_entry_activated_lc=
b, dialog);<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g_signal_conne=
ct(G_OBJECT(entry), &quot;activate&quot;, G_CALLBACK(command_dialog_entry_a=
ctivated_lcb), dialog);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g_free(tm=
p);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_widge=
t_show_all(dialog);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0result =
=3D gtk_dialog_run(GTK_DIALOG(dialog));<br>
&gt; ---<br>
&gt; <br>
&gt; Thanks!<br>
&gt; <br>
&gt; Danilo Egea Gondolfo &lt;<a href=3D"mailto:danilo@freebsd.org" target=
=3D"_blank">danilo@freebsd.org</a>&gt; escreveu no dia ter=C3=A7a, 4/07/202=
3 =C3=A0(s) 15:00:<br>
&gt; On 04/07/2023 14:56, Dimitry Andric wrote:<br>
&gt; <br>
&gt; &gt; On 4 Jul 2023, at 14:37, Nuno Teixeira &lt;<a href=3D"mailto:edua=
rdo@freebsd.org" target=3D"_blank">eduardo@freebsd.org</a>&gt; wrote:<br>
&gt; &gt;&gt; I&#39;m getting build errors from current with www/bluefish a=
bout deprecated glib2 declarations and causing build to fail with clang16:<=
br>
&gt; &gt;&gt; ---<br>
&gt; &gt;&gt; /usr/local/include/glib-2.0/glib/gmacros.h:1262:37: note: exp=
anded from macro &#39;G_DEPRECATED&#39;<br>
&gt; &gt;&gt; #define G_DEPRECATED __attribute__((__deprecated__))<br>
&gt; &gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^<br=
>
&gt; &gt;&gt; mv -f .deps/bluefish.Tpo .deps/bluefish.Po<br>
&gt; &gt;&gt; bftextview2_langmgr.c:2665:2: warning: &#39;g_thread_create_f=
ull&#39; is deprecated: Use &#39;g_thread_new&#39; instead [-Wdeprecated-de=
clarations]<br>
&gt; &gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 g_thread_create_full(build_=
bflang2scan_thread, NULL, 0, FALSE, FALSE, G_THREAD_PRIORITY_LOW, &amp;gerr=
or);<br>
&gt; &gt;&gt; ---<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Any help is welcome on finding out its cause.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; a related issue: <a href=3D"https://github.com/PCSX2/pcsx2/is=
sues/3315" rel=3D"noreferrer" target=3D"_blank">https://github.com/PCSX2/pc=
sx2/issues/3315</a><br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Build log: <a href=3D"https://pkg-status.freebsd.org/beefy17/=
data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log" =
rel=3D"noreferrer" target=3D"_blank">https://pkg-status.freebsd.org/beefy17=
/data/main-i386-default/pf46bd2c58425_s0631830a7a/logs/bluefish-2.2.14.log<=
/a><br>
&gt; &gt; The actual error is an incompatible callback function signature:<=
br>
&gt; &gt;<br>
&gt; &gt; bftextview2_autocomp.c:432:2: error: incompatible function pointe=
r types passing &#39;gboolean (GtkLabel *, gchar *, gpointer)&#39; (aka &#3=
9;int (struct _GtkLabel *, char *, void *)&#39;) to parameter of type &#39;=
GCallback&#39; (aka &#39;void (*)(void)&#39;) [-Wincompatible-function-poin=
ter-types]<br>
&gt; &gt; g_signal_connect(acw-&gt;reflabel, &quot;activate-link&quot;, acw=
_label_active_link_lcb, acw);<br>
&gt; &gt; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~<br>
&gt; &gt; /usr/local/include/glib-2.0/gobject/gsignal.h:515:59: note: expan=
ded from macro &#39;g_signal_connect&#39;<br>
&gt; &gt; g_signal_connect_data ((instance), (detailed_signal), (c_handler)=
, (data), NULL, (GConnectFlags) 0)<br>
&gt; &gt; ^~~~~~~~~~~<br>
&gt; &gt; /usr/local/include/glib-2.0/gobject/gsignal.h:411:25: note: passi=
ng argument to parameter &#39;c_handler&#39; here<br>
&gt; &gt; GCallback c_handler,<br>
&gt; &gt; ^<br>
&gt; &gt;<br>
&gt; &gt; I have seen these more often with glib-based applications. In som=
e cases<br>
&gt; &gt; it is feasible to fix the callback function to have the correct<b=
r>
&gt; &gt; signature, in other cases you can slap a cast in place. Or, if th=
e<br>
&gt; &gt; affected code is vala-generated (also happens), the big hammer is=
 to<br>
&gt; &gt; suppress the warning(s).<br>
&gt; &gt;<br>
&gt; &gt; -Dimitry<br>
&gt; &gt;<br>
&gt; Not a glib expert here, but you can try this <a href=3D"https://pasteb=
in.com/ty8hLjVU" rel=3D"noreferrer" target=3D"_blank">https://pastebin.com/=
ty8hLjVU</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; Nuno Teixeira<br>
&gt; FreeBSD Committer (ports)<br>
<br>
</blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre=
fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"l=
tr"><span style=3D"color:rgb(102,102,102)">Nuno Teixeira<br>FreeBSD Committ=
er (ports)</span></div></div>
</blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre=
fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"l=
tr"><span style=3D"color:rgb(102,102,102)">Nuno Teixeira<br>FreeBSD Committ=
er (ports)</span></div></div>

--000000000000a9911205ffaa69dd--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7ULvS9cQZ4Exzpn5j3hohU03SWjenLHG_XcRCN=pN0RfXQ>