On Wed, 26 Jan 2022 at 16:23, Vít Ondruch wrote:
>
>
> Dne 26. 01. 22 v 15:48 Iñaki Ucar napsal(a):
> > On Wed, 26 Jan 2022 at 15:46, Iñaki Ucar wrote:
> >> More issues with this change:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2046246
> >>
> >> Packages such as R (octave and others, I
Dne 26. 01. 22 v 15:48 Iñaki Ucar napsal(a):
On Wed, 26 Jan 2022 at 15:46, Iñaki Ucar wrote:
More issues with this change:
https://bugzilla.redhat.com/show_bug.cgi?id=2046246
Packages such as R (octave and others, I suppose, as well) save the
build flags because they are needed to build
On Wed, 26 Jan 2022 at 15:46, Iñaki Ucar wrote:
>
> More issues with this change:
> https://bugzilla.redhat.com/show_bug.cgi?id=2046246
>
> Packages such as R (octave and others, I suppose, as well) save the
> build flags because they are needed to build package extensions. With
> this change, a
More issues with this change:
https://bugzilla.redhat.com/show_bug.cgi?id=2046246
Packages such as R (octave and others, I suppose, as well) save the
build flags because they are needed to build package extensions. With
this change, a path that only exists during the parent package build
stage is
Zbigniew Jędrzejewski-Szmek wrote on 2022/01/24 17:55:
On Sat, Jan 22, 2022 at 08:54:02PM -0700, Jerry James wrote:
On Fri, Jan 21, 2022 at 5:35 PM Robert-André Mauchin wrote:
Sorry for the necro but there seems to be a problem with this change. It
broke multiple packages at the linking
On Mon, Jan 24, 2022 at 1:58 AM Zbigniew Jędrzejewski-Szmek
wrote:
> the problem was that the %_package_note_file macro uses %buildsubdir,
> and %buildsubdir is set during %prep, but it seems it only available
> during %build and later. So the path was set wrong… I pushed a work-around
> to set
On Sat, Jan 22, 2022 at 05:56:40PM -0500, Neal Gompa wrote:
> On Sat, Jan 22, 2022 at 5:47 PM Kevin Kofler via devel
> wrote:
> >
> > Kevin Kofler via devel wrote:
> > > It breaks ALL packages using gold to link, and the "fix" is to explicitly
> > > add a macro to generate gold-compatible output
On Sat, Jan 22, 2022 at 08:54:02PM -0700, Jerry James wrote:
> On Fri, Jan 21, 2022 at 5:35 PM Robert-André Mauchin
> wrote:
> > Sorry for the necro but there seems to be a problem with this change. It
> > broke multiple packages at the linking stage:
> >
On Fri, Jan 21, 2022 at 5:35 PM Robert-André Mauchin wrote:
> Sorry for the necro but there seems to be a problem with this change. It
> broke multiple packages at the linking stage:
> https://bugzilla.redhat.com/show_bug.cgi?id=2043178
>
> On the package-note repo
On Sat, Jan 22, 2022 at 5:47 PM Kevin Kofler via devel
wrote:
>
> Kevin Kofler via devel wrote:
> > It breaks ALL packages using gold to link, and the "fix" is to explicitly
> > add a macro to generate gold-compatible output or to stop using gold. Also
> > affects qt5-qtwebengine:
> >
Kevin Kofler via devel wrote:
> It breaks ALL packages using gold to link, and the "fix" is to explicitly
> add a macro to generate gold-compatible output or to stop using gold. Also
> affects qt5-qtwebengine:
> https://bugzilla.redhat.com/show_bug.cgi?id=2043178#c10
And worse, neither of the
Robert-André Mauchin wrote:
> Sorry for the necro but there seems to be a problem with this change. It
> broke multiple packages at the linking stage:
> https://bugzilla.redhat.com/show_bug.cgi?id=2043178
It breaks ALL packages using gold to link, and the "fix" is to explicitly
add a macro to
On 10/25/21 21:09, 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 for which this file was built. This
allows binaries to be
> On Mon, Nov 15, 2021 at 10:33 AM Luca Boccassi
> Please mention RPMCoW directly.
Mentioned and also linked the mailing list post you linked above as a
reference, let me know if there's other changes I can do.
___
devel mailing list --
On Mon, Nov 15, 2021 at 10:33 AM Luca Boccassi wrote:
>
> > On Mon, Nov 15, 2021 at 10:18 AM Luca Boccassi > wrote:
> >
> > Huh, I guess it was. :/
>
> Does that paragraph address your concerns? If so, I can update it to mention
> RPMCoW directly, for future reference.
Please mention RPMCoW
> On Mon, Nov 15, 2021 at 10:18 AM Luca Boccassi
> Huh, I guess it was. :/
Does that paragraph address your concerns? If so, I can update it to mention
RPMCoW directly, for future reference.
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Mon, Nov 15, 2021 at 10:18 AM Luca Boccassi wrote:
>
> > On Mon, Nov 8, 2021 at 2:06 PM David Cantrell > wrote:
> >
> > Last cycle, I brought up the problem that it being part of the ELF
> > data destroys a lot of the value of the RPMCoW change[1] that is also
> > in development for this
> On Mon, Nov 8, 2021 at 2:06 PM David Cantrell wrote:
>
> Last cycle, I brought up the problem that it being part of the ELF
> data destroys a lot of the value of the RPMCoW change[1] that is also
> in development for this release. I'm disappointed that the Change
> authors didn't care to
On Mon, Nov 8, 2021 at 2:06 PM David Cantrell wrote:
>
> On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:
> >On Do, 28.10.21 12:10, David Cantrell (dcantr...@redhat.com) wrote:
> >
> >> Thanks for revising the change proposal and filling in more details.
> >> After reading
On Do, 11.11.21 19:02, Florian Weimer (fwei...@redhat.com) wrote:
> * Lennart Poettering:
>
> > And I think that's a *good* thing: JSON might not be perfect — because
> > nothing is —, but it's certainly one of the better designed generic
> > data formats around, and it's complexity is absolutely
On Thu, Nov 11, 2021 at 07:02:10PM +0100, Florian Weimer wrote:
> * Lennart Poettering:
>
> > And I think that's a *good* thing: JSON might not be perfect — because
> > nothing is —, but it's certainly one of the better designed generic
> > data formats around, and it's complexity is absolutely
* Lennart Poettering:
> And I think that's a *good* thing: JSON might not be perfect — because
> nothing is —, but it's certainly one of the better designed generic
> data formats around, and it's complexity is absolutely managable.
Number handling in JSON is underspecified, and some variants
On Di, 09.11.21 10:14, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 08/11/2021 22:24, Lennart Poettering wrote:
> > And I think that's a*good* thing: JSON might not be perfect — because
> > nothing is —, but it's certainly one of the better designed generic
> > data formats
On Tue, Nov 09, 2021 at 10:14:25AM +0100, Vitaly Zaitsev via devel wrote:
> On 08/11/2021 22:24, Lennart Poettering wrote:
> > And I think that's a*good* thing: JSON might not be perfect — because
> > nothing is —, but it's certainly one of the better designed generic
> > data formats around, and
Dne 09. 11. 21 v 10:14 Vitaly Zaitsev via devel napsal(a):
On 08/11/2021 22:24, Lennart Poettering wrote:
And I think that's a*good* thing: JSON might not be perfect — because
nothing is —, but it's certainly one of the better designed generic
data formats around, and it's complexity is
On 08/11/2021 22:24, Lennart Poettering wrote:
And I think that's a*good* thing: JSON might not be perfect — because
nothing is —, but it's certainly one of the better designed generic
data formats around, and it's complexity is absolutely managable.
What about YAML?
--
Sincerely,
Vitaly
On Mo, 08.11.21 13:54, David Cantrell (dcantr...@redhat.com) wrote:
> > > One of the reasons we are sticking to JSON here is so that we can use
> > > battle-tested parsers we already use for other stuff. you want a
> > > parser that is already used, verified, tested elsewhere, and JSON
> > >
On Mon, Nov 08, 2021 at 02:06:17PM -0500, David Cantrell wrote:
> I was thinking more about this proposal over the past weekend and
> where I keep ending up is that this is really optimizing for a small
> use case by touching ELF metadata all over the system. And that
> strikes me as pretty
> On Thu, Nov 04, 2021 at 10:26:20AM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> But a binary representation of that could strip it down into ~50%.
Would it though? Have you tested and checked it to make that determination? Can
you share the code to reproduce it?
The values necessarily have
> On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:
>
> I was thinking more about this proposal over the past weekend and
> where I keep ending up is that this is really optimizing for a small
> use case by touching ELF metadata all over the system. And that
> strikes me as
On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:
On Do, 28.10.21 12:10, David Cantrell (dcantr...@redhat.com) wrote:
Thanks for revising the change proposal and filling in more details.
After reading through it, I have some questions:
1) The proposal notes that users tend
On Fri, Oct 29, 2021 at 10:17:09PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Oct 29, 2021 at 09:53:25PM +0200, Lennart Poettering wrote:
On Fr, 29.10.21 13:57, David Cantrell (dcantr...@redhat.com) wrote:
> Has there been any consideration for potential security risks with
> regards to
bluca wrote:
> This [tags for statically linked parts] would be indeed useful [...]
For the original task of assisting with crash analysis, how would it be
useful? The idea is that the overall binary's tags would let someone
fetch the corresponding distro / debuginfo and go from there. That
On Thu, Nov 04, 2021 at 10:26:20AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > We checked compression, and it just isn't worth it. When you compress
> > 100–200 bytes, the output might be a tiny bit smaller, but then the
> > compression alg header is added it becomes a wash. And we lose an
On Thu, Nov 04, 2021 at 10:20:35AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Nov 04, 2021 at 11:12:37AM +0100, Jakub Jelinek wrote:
> > On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote:
> > > >> The general case of any statically linked code. It could be libgcc,
> > > >>
On Thu, Nov 04, 2021 at 11:12:37AM +0100, Jakub Jelinek wrote:
> On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote:
> > >> The general case of any statically linked code. It could be libgcc,
> > >> startup files, the non-shared bits of glibc, static-only libraries, or
> > >>
On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote:
> * Luca Boccassi:
>
> >> * Zbigniew Jędrzejewski-Szmek:
> >>
> >>
> >> The general case of any statically linked code. It could be libgcc,
> >> startup files, the non-shared bits of glibc, static-only libraries, or
> >>
On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote:
> >> The general case of any statically linked code. It could be libgcc,
> >> startup files, the non-shared bits of glibc, static-only libraries, or
> >> header-only C++ libraries.
>
> > This would be indeed useful, but quite harder
* Luca Boccassi:
>> * Zbigniew Jędrzejewski-Szmek:
>>
>>
>> The general case of any statically linked code. It could be libgcc,
>> startup files, the non-shared bits of glibc, static-only libraries, or
>> header-only C++ libraries.
> This would be indeed useful, but quite harder to do
* Steve Grubb:
> Hello,
>
> On Wednesday, November 3, 2021 10:00:05 AM EDT David Sastre wrote:
>> I assume that the people who worked on it looked into various different
>> possibilities for its implementation and decide on the current one, but I
>> have a few questions:
>>
>>- Since there
On Wed, Nov 03, 2021 at 01:31:50PM -0400, Steve Grubb wrote:
> Hello,
>
> On Wednesday, November 3, 2021 10:00:05 AM EDT David Sastre wrote:
> > I assume that the people who worked on it looked into various different
> > possibilities for its implementation and decide on the current one, but I
>
Hello,
On Wednesday, November 3, 2021 10:00:05 AM EDT David Sastre wrote:
> I assume that the people who worked on it looked into various different
> possibilities for its implementation and decide on the current one, but I
> have a few questions:
>
>- Since there are people concerned about
On Mi, 03.11.21 15:00, David Sastre (d.sastre.med...@gmail.com) wrote:
>- There are a few existing formats for software identification and SBOMs:
> - SPDX[2], used in the example spec in the proposal
> - SWID tags[3][4]
> - OWASP CycloneDX[5]
> - CPE[6], used in the
This is an interesting proposal and discussion.
I assume that the people who worked on it looked into various different
possibilities for its implementation and decide on the current one, but I
have a few questions:
- Since there are people concerned about the increased size of the
binary,
On Wed, Nov 3, 2021 at 9:41 AM Petr Pisar wrote:
>
> V Wed, Nov 03, 2021 at 01:45:00AM +0100, Miroslav Suchý napsal(a):
> > Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a):
> > > === Why not just use the rpm database? ===
> > >
> > >
> > > 17:34:33 The main reason for this appears to be that we
> >
On Wed, Nov 03, 2021 at 09:39:28AM +0100, Petr Pisar wrote:
> > Devil advocate here:
> >
> > **Some** people wipe `/var/lib/rpm` to save 5.9 MB. And because of this we
> > will put another 5.9 MB [citation needed] as metadata split across various
> > ELF objects for **everybody**.
This was
V Wed, Nov 03, 2021 at 01:45:00AM +0100, Miroslav Suchý napsal(a):
> Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a):
> > === Why not just use the rpm database? ===
> >
> >
> > 17:34:33 The main reason for this appears to be that we
> > need the RPM db locally to resolve build-ids to package names.
Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a):
=== Why not just use the rpm database? ===
17:34:33 The main reason for this appears to be that we
need the RPM db locally to resolve build-ids to package names. But
since containers wipe /var/lib/rpm, we can't do that. So the solution
is to put
> On Thu, Oct 28, 2021 at 07:37:27PM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> These are reasonable examples that demonstrate how developers and
> users could benefit from the change proposal. Could more things like
> this be added to:
>
>
On Fr, 29.10.21 16:37, Neal Gompa (ngomp...@gmail.com) wrote:
> > {
> > …
> > "originatingBuildSystem" : "koji.fedoraproject.org",
> > …
> > }
> >
> > With such a simple field we could easily distinguish builds from
> > Fedora from those people might have rebuilt
On Sat, Oct 30, 2021 at 6:56 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sat, Oct 30, 2021 at 10:06:36AM -, Luca Boccassi wrote:
> > > On 10/29/21 3:53 PM, Lennart Poettering wrote:
> > >
> > > Does there need to be any parsing at all? WireGuard avoids the problem
> > > by only using
On Sat, Oct 30, 2021 at 10:06:36AM -, Luca Boccassi wrote:
> > On 10/29/21 3:53 PM, Lennart Poettering wrote:
> >
> > Does there need to be any parsing at all? WireGuard avoids the problem
> > by only using fixed-size fields, so one only needs to check that the
> > field is of the correct
> On 10/29/21 3:53 PM, Lennart Poettering wrote:
>
> Does there need to be any parsing at all? WireGuard avoids the problem
> by only using fixed-size fields, so one only needs to check that the
> field is of the correct length. Qubes OS uses the same solution in
> at least its GUI protocol.
>
On 10/29/21 3:53 PM, Lennart Poettering wrote:
> On Fr, 29.10.21 13:57, David Cantrell (dcantr...@redhat.com) wrote:
>
>> Has there been any consideration for potential security risks with
>> regards to the data in this string? Of concern to me are encoding
>> formats, size limits or reporting,
On Fri, Oct 29, 2021 at 09:53:25PM +0200, Lennart Poettering wrote:
> On Fr, 29.10.21 13:57, David Cantrell (dcantr...@redhat.com) wrote:
>
> > Has there been any consideration for potential security risks with
> > regards to the data in this string? Of concern to me are encoding
> > formats,
> On Thu, Oct 28, 2021 at 06:39:38PM -, Luca Boccassi wrote:
>
> It depends on how wide of a net you cast. Since package naming is
> user-controlled and distribution-wide rules are enforced by disparate
> build systems and environments, an NVR (or NEVRA) is not unique. It's
> close to
On Fri, Oct 29, 2021 at 4:00 PM Lennart Poettering wrote:
>
> On Fr, 29.10.21 14:09, David Cantrell (dcantr...@redhat.com) wrote:
>
> > > the information may be useful: maybe the software is in an older
> > > version that you don't support, or maybe the bug was already fixed in
> > > a later
On Fr, 29.10.21 14:09, David Cantrell (dcantr...@redhat.com) wrote:
> > the information may be useful: maybe the software is in an older
> > version that you don't support, or maybe the bug was already fixed in
> > a later version, etc.
> >
> > That said, for Fedora official builds, package NVR
On Fr, 29.10.21 13:57, David Cantrell (dcantr...@redhat.com) wrote:
> Has there been any consideration for potential security risks with
> regards to the data in this string? Of concern to me are encoding
> formats, size limits or reporting, and structure formats. The
> proposal notes JSON,
On Thu, Oct 28, 2021 at 06:39:38PM -, Luca Boccassi wrote:
On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
2) The proposal is built around using the package NVR to indicate
where it came from. But those names aren't unique. In some cases
it'll work, but in
On Thu, Oct 28, 2021 at 07:37:27PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Oct 28, 2021 at 12:10:15PM -0400, David Cantrell wrote:
On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
>On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote:
On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:
On Do, 28.10.21 12:10, David Cantrell (dcantr...@redhat.com) wrote:
Thanks for revising the change proposal and filling in more details.
After reading through it, I have some questions:
1) The proposal notes that users tend
> On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi
> It is not enough. It's not enough in *any* distribution, because
> people can (re)build and deploy the same NEVRA. You *need* a build-id
> to guarantee uniqueness of the binary. If the NVR is the same but the
> build has been modified, the
On Do, 28.10.21 15:10, Neal Gompa (ngomp...@gmail.com) wrote:
> It is not enough. It's not enough in *any* distribution, because
> people can (re)build and deploy the same NEVRA. You *need* a
> build-id to guarantee uniqueness of the binary. If the NVR is the
> same but the build has been
On Thu, Oct 28, 2021 at 12:10:15PM -0400, David Cantrell wrote:
> On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
> >On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote:
> >>https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
> >>
> >>==
On Do, 28.10.21 12:10, David Cantrell (dcantr...@redhat.com) wrote:
> Thanks for revising the change proposal and filling in more details.
> After reading through it, I have some questions:
>
> 1) The proposal notes that users tend to combine built packages from
> different distributions. Even
On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi wrote:
>
> > On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > Thanks for revising the change proposal and filling in more details.
> > After reading through it, I have some questions:
> >
> > 1) The proposal notes
On Thu, Oct 28, 2021 at 05:44:44PM +0200, Vitaly Zaitsev via devel wrote:
> On 28/10/2021 15:53, Chris Adams wrote:
> > New 500G SSDs are available under $50, and 1TB under $90.
>
> QLC is not an option. Too slow outside of the SLC cache.
Stop moving the goalposts, okay?
--
Tomasz Torcz
> On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> Thanks for revising the change proposal and filling in more details.
> After reading through it, I have some questions:
>
> 1) The proposal notes that users tend to combine built packages from
> different
On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 25, 2021 at 03:09:00PM -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
On 28/10/2021 15:53, Chris Adams wrote:
New 500G SSDs are available under $50, and 1TB under $90.
QLC is not an option. Too slow outside of the SLC cache.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
On Thu, 28 Oct 2021 at 10:03, Kevin Kofler via devel
wrote:
>
> Stephen John Smoogen wrote:
> > a) Not have Lennart's name tied to a request. That just pulls in all
> > kinds of over-the-top statements where people will say 99.99% of the
> > people won't use it without any evidence.
>
> What does
> On Wed, Oct 27, 2021 at 02:10:37PM +0100, Daniel P. Berrangé wrote:
>
> It breaks libguestfs. It also breaks basic stuff like "what is
> installed in this container?" "Is this file owned by RPM?" "Has
> this
> file been modified?" I think deleting the RPM database is broken, and
> tools
On Do, 28.10.21 14:24, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> Lennart Poettering wrote:
> > I understand you are not working with backtraces/coredumps every
> > day.
>
> For core dumps, this is true. (I have found those to not be of much use,
> other than getting a
Michael Catanzaro wrote:
> What I just don't understand is why so much argument over a minuscule
> disk space increase. We can argue over the best way to create
> backtraces. But trying to step on the toes of other people who are
> working on this problem just because their work requires a tiny
>
On Wed, Oct 27, 2021 at 02:10:37PM +0100, Daniel P. Berrangé wrote:
> On Wed, Oct 27, 2021 at 02:00:36PM +0200, Kevin Kofler via devel wrote:
> > Zbigniew Jędrzejewski-Szmek wrote:
> > > 5. This proposal is not about licensing, but if it is adopted, it'll only
> > > make figuring out potential
Stephen John Smoogen wrote:
> a) Not have Lennart's name tied to a request. That just pulls in all
> kinds of over-the-top statements where people will say 99.99% of the
> people won't use it without any evidence.
What does Lennart's name have to do with this? I would have objected the
same way
On Wed, Oct 27, 2021 at 03:24:07AM +0200, Kevin Kofler via devel wrote:
> > == Owner ==
> > (for example using Fedora containers on Debian or vice versa),
>
> Containers ought to include the (guest) distribution's package database.
> Everything else is just broken and needs to be fixed.
Indeed.
Once upon a time, Vitaly Zaitsev via devel said:
> SSD is must have nowadays. Typical SSD size is still 128/256 GB,
> because 500+ GB is too expensive for now.
New 500G SSDs are available under $50, and 1TB under $90.
--
Chris Adams
___
devel mailing
On Thu, 28 Oct 2021 at 08:51, Michael Catanzaro wrote:
>
>
> What I just don't understand is why so much argument over a minuscule
> disk space increase. We can argue over the best way to create
> backtraces. But trying to step on the toes of other people who are
> working on this problem just
What I just don't understand is why so much argument over a minuscule
disk space increase. We can argue over the best way to create
backtraces. But trying to step on the toes of other people who are
working on this problem just because their work requires a tiny
annotation in each binary
Lennart Poettering wrote:
> I understand you are not working with backtraces/coredumps every
> day.
For core dumps, this is true. (I have found those to not be of much use,
other than getting a backtrace, but I would rather just get the backtrace
directly.) For backtraces, it is not. I
Hi Lennart,
On Thu, 2021-10-28 at 09:56 +0200, Lennart Poettering wrote:
> But as someone who's at the upstream receiving end of bug
> reports
> of one major project I can tell you that MiniDebugInfo is literally
> the best thing since sliced bread: in systemd upstream the bug reports
> we get
Hi Daniel,
On Wed, 2021-10-27 at 10:01 +0100, Daniel P. Berrangé wrote:
> Getting RPM NEVRs directly from the coredumps is something that
> will be incredibly helpful for people dealing with support
> requests after crashes. build-ids have always been very tedious
> to deal with and as you say
> On 27/10/2021 21:38, Luca Boccassi wrote:
>
> I will ask additional information from user if the bug report has no
> useful backtrace.
Which you might get or not, and might be correct or not. This is what we
experience daily - just because you are lucky and don't need it, it doesn't
mean
On 28/10/2021 00:22, Kevin Kofler via devel wrote:
IMHO, core dumps should not even be enabled by default to begin with. They
are typically just a useless waste of disk space. Uploading them is a bad
idea because they are huge and can contain sensitive personal information.
Yes, publishing and
On 27/10/2021 22:22, Lennart Poettering wrote:
So no, if you aren't interested in reading coredumps yourself you
won't benefit immediately. But if you want to increase the chance that
the various bugs you undoubtly run into every now and then have the
highest chance to be fixed quickly, then
On 27/10/2021 21:38, Luca Boccassi wrote:
As an upstream developer, you get what users send you, which might or might not
be what you prefer
I will ask additional information from user if the bug report has no
useful backtrace.
With this change, the bare minimum produced as a corefile is
On Do, 28.10.21 00:22, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> And me mentioning "crash handler" and "no core dumps" together is
> not a mistake. A well-designed crash handler does NOT operate on
> core dumps, but on live processes. This implies that it should be
>
On Do, 28.10.21 01:48, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> That said, you are probably right that this change proposal is not the worst
> source of bloat we have ever encountered. There has been much worse. (Just
> in terms of bloat added to each ELF binary by
On 28/10/2021 00:43, Luca Boccassi wrote:
Today, 1 TB+ hard drives are common
Have you tried using modern GNU/Linux distributions on hard drives? I
tried. They were too slw.
SSD is must have nowadays. Typical SSD size is still 128/256 GB, because
500+ GB is too expensive for now.
--
Luca Boccassi wrote:
> If I am reading this correctly, when Fedora was first released in 2003,
> common hard drive capacity was around 80 GB:
>
https://upload.wikimedia.org/wikipedia/commons/a/a1/Hard_drive_capacity_over_time.png
> Today, 1 TB+ hard drives are common.
SSD capacity has been
> Luca Boccassi wrote:
>
> The problem with your argument is that one "ridiculously negligible"
> overhead and then another and then yet another etc. ends up accumulating and
> we end up with minimum RAM and disk space requirements increased by a factor
> of 10 (!) since the day Fedora was
Lennart Poettering wrote:
> For one moment consider the life of the people who provide you with
> the software you run: coredumps become infinitely more useful if you
> can quickly derive which package they come from.
IMHO, core dumps should not even be enabled by default to begin with. They
are
Steve Grubb wrote:
> No good way. After composing the above email, I noticed it was lingering
> in the outbox. After some poking around, I found that one of the mail
> agents was no longer on dbus. I can only speculate it segfaulted.
That is quite likely. Akonadi agents just crash whenever they
Steve Grubb wrote:
> This brings up an interesting tangent (sorry), which I've asked on the KDE
> list with no answer.
Do not expect an answer from me on the k...@lists.fp.o list, as I have been
(IMHO unfairly) banned from all KDE SIG communication channels.
> When kontact segfaults, and it
Luca Boccassi wrote:
> Whether you follow it or not, it has happened, it is happening and it will
> keep happening, because for others it is perfectly logical and highly
> desirable. So one can either stay here and complain all day long that
> containers are bad and they are all doing them wrong,
On Mi, 27.10.21 17:37, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 25/10/2021 21:09, Ben Cotton wrote:
> > All binaries (executables and shared libraries) are annotated with an
> > ELF note that identifies the rpm for which this file was built. This
> > allows binaries to
On Wed, Oct 27, 2021 at 4:07 PM Luca Boccassi wrote:
>
> > Dne 27. 10. 21 v 21:35 Luca Boccassi napsal(a):
> >
> > In repository in general (can be deb, zypper, local directory). Even the
> > offline systems
> > have some repository where they
> > get the packages from.
> >
> > Miroslav
>
> How
> Dne 27. 10. 21 v 21:35 Luca Boccassi napsal(a):
>
> In repository in general (can be deb, zypper, local directory). Even the
> offline systems
> have some repository where they
> get the packages from.
>
> Miroslav
How do you know which one is it then? You have a core file from a container
1 - 100 of 143 matches
Mail list logo
