Sent from my brhvrgrb4?444))) r4(;;:555/;5;5;:
On December 3, 2021 12:12:47 PM UTC, Stephan Lachnit
wrote:
>On Thu, Dec 2, 2021 at 11:52 PM Paul Wise wrote:
>>
>> On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote:
>>
>> > If I understand correctly, release-monitoring already offers such a
>> > mapping [1].
>>
>> It seems like the A
On Fri, 2021-12-03 at 13:12 +0100, Stephan Lachnit wrote:
> I mean it looks rather easy to do, just a couple of mouse clicks.
> Compare that to writing a watch file at the moment (assuming one has
> to do more than copy and paste the github example).
Repology gets you mappings for all the source
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-clbanning-mxj
Version : 2.5.5-1
Upstream Author : Charles Banning
* URL : https://github.com/clbanning/mxj
* License : Expat
Programming Lang: Go
Description : mxj - to/fr
On Fri, Dec 03, 2021 at 05:59:17PM +0100, Florian Weimer wrote:
> * Theodore Y. Ts'o:
>
> > * How does ld.so --preload *work*?
>
> The dynamic loader has an array of preloaded sonames, and it processes
> them before loading the dependencies of the main program. This way,
> definitions in the pre
Package: wnpp
Severity: wishlist
Owner: Daniel Leidert
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: ruby-thread-local
Version : 1.1.0
Upstream Author : Samuel Williams
* URL :
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
X-Debbugs-Cc: debian-devel@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: meli
Version : 0.7.2
Upstream Author : Manos Pitsidianakis
* URL : https://meli.delivery/
* License
On Fri, 03 Dec 2021 at 18:29:33 +0100, Florian Weimer wrote:
> > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> >> If someone wants to upstream the multi-arch patches, that would be
> >> great.
> >
> > I think multiarch is mostly build-time configuration rather than patches.
>
> We
* Simon McVittie:
> On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
>> Having ld.so as a real command makes the name architecture-agnostic.
>> This discourages from hard-coding non-portable paths such as
>> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
>> /lib/x86_64-lin
On Fri, Dec 03, 2021 at 11:33:25AM -0500, Theodore Y. Ts'o wrote:
> Some stupid questions that I couldn't answer by reading the man page
> or doing a quick google search
> * How does ld.so --preload *work*?
ld.so is the ELF interpreter. If you run a normal binary, the kernel
rewrites this req
On Fri, Dec 03, 2021 at 04:16:04PM +0200, Timo Lindfors wrote:
> Just a random thought: If you have configured a restricted shell (e.g.
> rbash) that only lets you execute commands in PATH, will this make it
> possible to bypass the restriction with "ld.so /tmp/some-random-binary"?
> This is not ne
* Theodore Y. Ts'o:
> * How does ld.so --preload *work*?
The dynamic loader has an array of preloaded sonames, and it processes
them before loading the dependencies of the main program. This way,
definitions in the preloaded objects preempt definitions in the shared
objects.
> * Does it modify
On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> Having ld.so as a real command makes the name architecture-agnostic.
> This discourages from hard-coding non-portable paths such as
> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
> /lib/x86_64-linux-gnu/ld-linux-x86-64.so
On Fri, Dec 03, 2021 at 02:46:27PM +0100, Bastian Blank wrote:
> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> > Right, thanks for providing a concrete example. A (somewhat) portable
> > version would look like this:
> > ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/
Hi,
On Fri, 3 Dec 2021, Florian Weimer wrote:
No objects to /usr/bin/ld.so then?
Just a random thought: If you have configured a restricted shell (e.g.
rbash) that only lets you execute commands in PATH, will this make it
possible to bypass the restriction with "ld.so /tmp/some-random-binary
* Bastian Blank:
> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
>> Right, thanks for providing a concrete example. A (somewhat) portable
>> version would look like this:
>> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
>
> You mean
> ld.so --preload libeatmydata
On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> Right, thanks for providing a concrete example. A (somewhat) portable
> version would look like this:
> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
You mean
ld.so --preload libeatmydata.so.1.3.0 /bin/ls
?
ld.so i
* Paul Wise:
> Florian Weimer wrote:
>
>> I'd like to provide an ld.so command as part of glibc.
>
> Will this happen in glibc upstream or just in Debian?
Upstream, and then Debian. The symbolic link would likely and up in
libc-bin in Debian.
>> Today, ld.so can be used to activate preloading,
On Thu, Dec 2, 2021 at 11:52 PM Paul Wise wrote:
>
> On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote:
>
> > If I understand correctly, release-monitoring already offers such a
> > mapping [1].
>
> It seems like the Ayanita distro mapping needs to be done manually once
> per package, while
19 matches
Mail list logo
