<div dir="ltr">Dimitri, friendly ping? Would you prefer if I took care of this? If I don’t hear back from you over the next week, I’ll go ahead :).<div><br></div><div>(An affected user just asked me in person about the status of this issue.)</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 6, 2018 at 4:51 PM Michael Stapelberg <<a href="mailto:stapelberg@debian.org">stapelberg@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Thanks for the reminder. It’s hard to keep track of everything that’s going on.<div><br></div><div>The lintian tag description states:</div><div><br></div><div><div>> The only time a binary or shared library in a Debian package should set RPATH or RUNPATH is if it is linked to private shared libraries in the same package. In that case, place those private shared libraries in /usr/lib/package. Libraries used by binaries in other packages should be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which case RPATH/RUNPATH is unnecessary.</div><div><br></div></div><div>It seems like this is exactly what’s happening here?</div><div><br></div><div>Can we try removing the rpath from where it can be removed, and overriding the lintian tag for the legitimate cases?</div><div><br></div><div>I’d prefer to not open libraries to the public unless coordinated with upstream, as they need to be aware of the stability guarantees (e.g. when to bump the SONAME).</div><div><br></div><div>Thanks!</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 6, 2018 at 4:27 PM Dimitri John Ledkov <<a href="mailto:xnox@ubuntu.com" target="_blank">xnox@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<br>
On Mon, 5 Nov 2018 at 21:07, Michael Stapelberg <<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>> wrote:<br>
><br>
> I still don’t quite understand why you stripped the rpaths to begin with. Can you explain? I think that’d be good to understand before making a decision :)<br>
><br>
<br>
Please recall that when you last tried to upload freeradius it got<br>
autorejected by ftp masters due to rpath.... email from 2nd of June<br>
from you to me....<br>
<br>
"""<br>
freeradius-postgresql: lintian output: 'binary-or-shlib-defines-rpath<br>
usr/lib/freeradius/rlm_sql_postgresql.so /usr/lib/x86_64-linux-gnu',<br>
automatically rejected package.<br>
freeradius-postgresql: If you have a good reason, you may override<br>
this lintian tag.<br>
freeradius-iodbc: lintian output: 'binary-or-shlib-defines-rpath<br>
usr/lib/freeradius/rlm_sql_iodbc.so /usr/lib', automatically rejected<br>
package.<br>
freeradius-iodbc: If you have a good reason, you may override this lintian tag.<br>
freeradius-python2: lintian output: 'binary-or-shlib-defines-rpath<br>
usr/lib/freeradius/rlm_python.so /usr/lib/python2.7/config',<br>
automatically rejected package.<br>
freeradius-python2: If you have a good reason, you may override this<br>
lintian tag.<br>
"""<br>
<br>
And spot checking this revealed that rpath is redundant for most of<br>
the modules shipped - hence i stripped rpath from them all.<br>
However, clearly that was false for all of them as some of them do use<br>
private lib as now analyzed.<br>
<br>
My preference is to not have rpath set on any of these, and simply<br>
expose libfreeradius-dhcp.so and libfreeradius-eap.so as public<br>
libraries.<br>
<br>
Also i'm pondering how come freeradius does not set ldpath when trying<br>
to dlopen the plugins from the plugin dir.... cause that would also<br>
work without rpath set on every plugin.<br>
<br>
Regards,<br>
<br>
Dimitri.<br>
<br>
<br>
<br>
> On Mon, Nov 5, 2018 at 9:06 PM Dimitri John Ledkov <<a href="mailto:xnox@ubuntu.com" target="_blank">xnox@ubuntu.com</a>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> On Mon, 5 Nov 2018 at 18:19, Michael Stapelberg <<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>> wrote:<br>
>> ><br>
>> > Sorry, didn’t see the merge request. I fixed my notification settings, merged the MR, and gave you permission to the repository.<br>
>> ><br>
>><br>
>> No worries. I myself only starting to figure out how to correctly use<br>
>> salsa. It is quite new in how everything works.<br>
>><br>
>> So about the bug, here is the full scope of affected files:<br>
>><br>
>> /usr/lib/freeradius# readelf -d *.so | grep -e '\[libfreeradius' -e File:<br>
>> File: libfreeradius-dhcp.so<br>
>> File: libfreeradius-eap.so<br>
>> File: libfreeradius-radius.so<br>
>> File: libfreeradius-server.so<br>
>> File: proto_dhcp.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-dhcp.so]<br>
>> File: proto_vmps.so<br>
>> File: rlm_always.so<br>
>> File: rlm_attr_filter.so<br>
>> File: rlm_cache.so<br>
>> File: rlm_cache_memcached.so<br>
>> File: rlm_cache_rbtree.so<br>
>> File: rlm_chap.so<br>
>> File: rlm_counter.so<br>
>> File: rlm_cram.so<br>
>> File: rlm_date.so<br>
>> File: rlm_detail.so<br>
>> File: rlm_dhcp.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-dhcp.so]<br>
>> File: rlm_digest.so<br>
>> File: rlm_dynamic_clients.so<br>
>> File: rlm_eap.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_fast.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_gtc.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_leap.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_md5.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_mschapv2.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_peap.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_pwd.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_sim.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_tls.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_eap_ttls.so<br>
>> 0x0000000000000001 (NEEDED) Shared library: [libfreeradius-eap.so]<br>
>> File: rlm_exec.so<br>
>> File: rlm_expiration.so<br>
>> File: rlm_expr.so<br>
>> File: rlm_files.so<br>
>> File: rlm_ippool.so<br>
>> File: rlm_krb5.so<br>
>> File: rlm_ldap.so<br>
>> File: rlm_linelog.so<br>
>> File: rlm_logintime.so<br>
>> File: rlm_mschap.so<br>
>> File: rlm_otp.so<br>
>> File: rlm_pam.so<br>
>> File: rlm_pap.so<br>
>> File: rlm_passwd.so<br>
>> File: rlm_perl.so<br>
>> File: rlm_preprocess.so<br>
>> File: rlm_python.so<br>
>> File: rlm_radutmp.so<br>
>> File: rlm_realm.so<br>
>> File: rlm_redis.so<br>
>> File: rlm_rediswho.so<br>
>> File: rlm_replicate.so<br>
>> File: rlm_rest.so<br>
>> File: rlm_soh.so<br>
>> File: rlm_sometimes.so<br>
>> File: rlm_sql.so<br>
>> File: rlm_sql_freetds.so<br>
>> File: rlm_sql_iodbc.so<br>
>> File: rlm_sql_mysql.so<br>
>> File: rlm_sql_null.so<br>
>> File: rlm_sql_postgresql.so<br>
>> File: rlm_sql_sqlite.so<br>
>> File: rlm_sqlcounter.so<br>
>> File: rlm_sqlippool.so<br>
>> File: rlm_test.so<br>
>> File: rlm_unix.so<br>
>> File: rlm_unpack.so<br>
>> File: rlm_utf8.so<br>
>> File: rlm_wimax.so<br>
>> File: rlm_yubikey.so<br>
>><br>
>> The majority of files indeed are fine. But a few that use<br>
>> libfreeradius-dhcp.so and libfreeradius-eap.so are not. I have two<br>
>> options to fix this:<br>
>><br>
>> (1) do not strip rpath from files that use libfreeradius-eap|dhcp.so<br>
>><br>
>> or<br>
>><br>
>> (2) make these two libraries public by creating symlinks<br>
>> /usr/lib/libfreeradius-eap|dhcp.so -><br>
>> freeradius/libfreeradius-eap|dhcp.so<br>
>><br>
>> because in practice they are public system soname-less libraries<br>
>> shipped in libfreeradius3 and one can compile against them using<br>
>> libfreeradius-dev.<br>
>><br>
>> In other packages, I went ahead and added sonames to such libraries<br>
>> and made them public - even if soname .0 and strict << versioning.<br>
>><br>
>> I can implement either of the above two options, what do you prefer?<br>
>><br>
>> > Thanks for looking into this!<br>
>> ><br>
>> > On Mon, Nov 5, 2018 at 6:53 PM Dimitri John Ledkov <<a href="mailto:xnox@ubuntu.com" target="_blank">xnox@ubuntu.com</a>> wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> On Tue, 16 Oct 2018 at 21:48, Michael Stapelberg <<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>> wrote:<br>
>> >> ><br>
>> >> > Dimitri, this is a result of your change <a href="https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919" rel="noreferrer" target="_blank">https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919</a>. Could you revert it for the time being, and, if you chose to go forward with a fix, outline the rationale? The commit only describes the what, not the why. Specifically, in which way was the rpath “bogus”?<br>
>> >> ><br>
>> >><br>
>> >> Digging more into this, to understand how to fix this right.<br>
>> >><br>
>> >> > Also, while at it, could you please ensure that <a href="https://salsa.debian.org/freeradius-team/freeradius" rel="noreferrer" target="_blank">https://salsa.debian.org/freeradius-team/freeradius</a> is in sync with what’s in the archive? Your NMU is not reflected in the changelog, for example :-/<br>
>> >> ><br>
>> >><br>
>> >> I can't actually do this. "Ready to be merged automatically. Ask<br>
>> >> someone with write access to this repository to merge this request"<br>
>> >> that's why when I uploaded NMU I opened the merge request on 25th of<br>
>> >> September at <a href="https://salsa.debian.org/freeradius-team/freeradius/merge_requests/2" rel="noreferrer" target="_blank">https://salsa.debian.org/freeradius-team/freeradius/merge_requests/2</a><br>
>> >> please merge that, I think you are the only one who has the rights to<br>
>> >> the repository.<br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Regards,<br>
>> >><br>
>> >> Dimitri.<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Best regards,<br>
>> > Michael<br>
>><br>
>><br>
>><br>
>> --<br>
>> Regards,<br>
>><br>
>> Dimitri.<br>
><br>
><br>
><br>
> --<br>
> Best regards,<br>
> Michael<br>
<br>
<br>
<br>
-- <br>
Regards,<br>
<br>
Dimitri.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_5084920311966184316gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
_______________________________________________<br>
Pkg-freeradius-maintainers mailing list<br>
<a href="mailto:Pkg-freeradius-maintainers@alioth-lists.debian.net" target="_blank">Pkg-freeradius-maintainers@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>