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