> On Tue, Apr 13, 2021 at 8:09 AM Zbigniew Jędrzejewski-Szmek
>
> The new metadata guarantees that the ELF data churns, though. For
> example, if I bump the Release in a spec file for something unrelated
> to the build, all the ELF blobs change. The current state means that
> this is deduplicated
On Do, 15.04.21 10:20, Luca Boccassi (bl...@debian.org) wrote:
> > I'm confused about this - I had put forth an idea for how to make rpm
> > create this when installing packages (so it works with older or third
> > party packages) but the same xattr could be created for any packaging
> > system. C
> On Wed, 2021-04-14 at 15:29 +, Zbigniew Jędrzejewski-Szmek wrote:
>
> That's fair - if it were possible to get an fd during dump, we could
> use fgetxattr. If not, we can use /proc/$pid/exe - even when deleted
> you can interact with it:
>
> [malmond@malmond-x1 ~]$ ls -l /proc/$$/exe
> lrwx
Sorry for not responding to this in my previous reply.
On Wed, 2021-04-14 at 15:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> I wanted to investigate this, but unfortunately, it's hard to check
> right now, because all builds are non-reproducible (in the sense of
> reproducible-builds.org), becau
On Wed, 2021-04-14 at 15:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> Unfortunately this doesn't work for two important cases:
> - when a binary or shared library has been replaced on disk. E.g.
> it is fairly common for packages to crash on upgrade, and the crash
> could be in the _old_ code
On Wed, Apr 14, 2021 at 11:47:42AM -0400, Neal Gompa wrote:
> On Wed, Apr 14, 2021 at 11:30 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Tue, Apr 13, 2021 at 12:44:42AM +, Matthew Almond via devel wrote:
> > > On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote:
> > > > Or in oth
On Wed, Apr 14, 2021 at 11:30 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Apr 13, 2021 at 12:44:42AM +, Matthew Almond via devel wrote:
> > On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote:
> > > Or in other words: packaging metadata are sources too. If they change
> > > (and
On Tue, Apr 13, 2021 at 12:44:42AM +, Matthew Almond via devel wrote:
> On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote:
> > Or in other words: packaging metadata are sources too. If they change
> > (and a version bump constitutes a change) the output might change,
> > and
> > that'
On Mon, Apr 12, 2021, at 8:44 PM, Matthew Almond via devel wrote:
>
> I think we should be careful to de-couple these two things. Just
> because $SOURCE_DATE_EPOCH is likely to affect a lot of binaries is not
> proof that all binaries will.
Agreed; it'd be interesting to gather some data here,
On Tue, Apr 13, 2021 at 8:09 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Mon, Apr 12, 2021 at 10:57:30PM +0200, Lennart Poettering wrote:
> > On Mo, 12.04.21 16:14, David Malcolm (dmalc...@redhat.com) wrote:
> >
> > > So I want to push back on the idea that a single package can be
> > > associate
On Mon, Apr 12, 2021 at 10:57:30PM +0200, Lennart Poettering wrote:
> On Mo, 12.04.21 16:14, David Malcolm (dmalc...@redhat.com) wrote:
>
> > So I want to push back on the idea that a single package can be
> > associated with a coredump, or be the one responsible for the crash:
> > any or all of t
On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote:
> Or in other words: packaging metadata are sources too. If they change
> (and a version bump constitutes a change) the output might change,
> and
> that's expected. What's key really is that the only things that can
> effect generated ou
On Mo, 12.04.21 20:40, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On Mon, 2021-04-12 at 15:46 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
>
> Putting packaging info into a binary guarantees that each successive
> packa
On Mo, 12.04.21 16:14, David Malcolm (dmalc...@redhat.com) wrote:
> So I want to push back on the idea that a single package can be
> associated with a coredump, or be the one responsible for the crash:
> any or all of the ELF objects linked into the process could be at
> fault.
The example in th
On Mon, 2021-04-12 at 15:46 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
Putting packaging info into a binary guarantees that each successive
package containing ELF binaries will not contain exactly the same
binaries, even if there are no cha
On Mon, 2021-04-12 at 15:46 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
>
> == Summary ==
> All binaries (executables and shared libraries) are annotated with an
> ELF
> note that identifies the rpm distributing this file.
>
> == Owner ==
>
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
== Summary ==
All binaries (executables and shared libraries) are annotated with an ELF
note that identifies the rpm distributing this file.
== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@
17 matches
Mail list logo
