On Wed, Oct 27, 2021 at 09:41:05PM +0200, Miroslav Suchý wrote:
> Dne 27. 10. 21 v 21:35 Luca Boccassi napsal(a):
> >>??? The build-id can be
> >>always retrieved from the dnf repository.
> >>
> >>Miroslav
> >Which dnf repository? What if it's not dnf but apt? Or zypper? What if it's
> >none? How
On Wed, Oct 27, 2021 at 12:44:27PM -0400, Frank Ch. Eigler wrote:
>
> sgrubb wrote:
>
> > This brings up an interesting tangent (sorry), which I've asked on the KDE
> > list with no answer. When kontact segfaults, and it does a lot, it starts
> > Dr.
> > Konqi and asks if you want to file a
> Daniel P. Berrangé wrote:
>
> Well, my take is that it is really weird that the response to "I deleted the
> metadata from my container and now I cannot query the very metadata I
> deleted." (hardly a surprise!) is "Let us just duplicate the same metadata
> somewhere else, bloating the files
On Wed, Oct 27, 2021 at 09:13:04PM +0200, Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
> > AFAIK, that assumes the package NEVRs on disk haven't changed on disk
> > since the process was spawned.
>
> How common is it even that this happens? Especially nowadays where offline
>
On Wed, Oct 27, 2021 at 08:14:43PM +0200, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
>
> > On Wed, Oct 27, 2021 at 02:00:36PM +0200, Kevin Kofler via devel wrote:
> >> offer" clause is in practice very hard to comply with. (Especially for
> >> GPLv2-only projects. The
Miroslav Suchý writes:
> You do not need a crash for that
> /usr/libexec/drkonqi --dialog --keeprunning --pid $PID
> will try to debug running application. I tried that with PID of
> running vim.
Nice, thanks. In the "Developer Information" tab, one can watch gdb
"Downloading separate debug
Dne 27. 10. 21 v 21:35 Luca Boccassi napsal(a):
??? The build-id can be
always retrieved from the dnf repository.
Miroslav
Which dnf repository? What if it's not dnf but apt? Or zypper? What if it's
none? How do you know?
In repository in general (can be deb, zypper, local directory). Even
> On 27/10/2021 18:40, Daniel P. Berrangé wrote:
>
> As an upstream developer, I prefer only backtraces with debuginfo installed.
As an upstream developer, you get what users send you, which might or might not
be what you prefer. With this change, the bare minimum produced as a corefile
is
> Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a):
>
> Why you hesitate to use network? When you allow network access then
> debuginfod already do
> that (more or less).
There can be many reasons, for example:
- privacy: it reveals what you are running to an external service
- security: airgapped
Dne 27. 10. 21 v 18:44 Frank Ch. Eigler napsal(a):
Do you have a recipe for
triggering this crash and the dr. konqi processing?
You do not need a crash for that
/usr/libexec/drkonqi--dialog \
--keeprunning--pid$PID
will try to debug running application. I tried that with PID of running
Daniel P. Berrangé wrote:
> AFAIK, that assumes the package NEVRs on disk haven't changed on disk
> since the process was spawned.
How common is it even that this happens? Especially nowadays where offline
updates are the default.
Kevin Kofler
Daniel P. Berrangé wrote:
> Container images are often not used and maintained in the same way as
> a traditional OS. If people want to pull in the latest RPM updates,
> they won't run 'dnf update' in the container, they'll simply build
> a new container image. Being able to query/manipulate the
Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Oct 27, 2021 at 02:00:36PM +0200, Kevin Kofler via devel wrote:
>> offer" clause is in practice very hard to comply with. (Especially for
>> GPLv2-only projects. The GPLv3 has made it slightly more practical,
>> admittedly.) In my experience, most
Hi -
> > If I read drkonqi sources correctly in that gdb is being used as the
> > backtracing backend. That suggests that its automatic debuginfod-based
> > downloading should be working on F35. Do you have a recipe for
> > triggering this crash and the dr. konqi processing?
> No good way [to
On 27/10/2021 18:40, Daniel P. Berrangé wrote:
It is a benefit to Fedora & upstream maintainers who are on the receiving
end of bug reports from users.
As an upstream developer, I prefer only backtraces with debuginfo installed.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On Wednesday, October 27, 2021 12:44:27 PM EDT Frank Ch. Eigler wrote:
> sgrubb wrote:
> > This brings up an interesting tangent (sorry), which I've asked on the
> > KDE
> > list with no answer. When kontact segfaults, and it does a lot, it starts
> > Dr. Konqi and asks if you want to file a
Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a):
But those
mechanisms will be different for different distributions and will
often require network access. With this change we aim to provide a
mechanism that is is very simple, provides a "human-readable" origin
information without further processing,
sgrubb wrote:
> This brings up an interesting tangent (sorry), which I've asked on the KDE
> list with no answer. When kontact segfaults, and it does a lot, it starts Dr.
> Konqi and asks if you want to file a report. But because debuginfo rpms are
> not installed it fails and says not enough
On Wed, Oct 27, 2021 at 05:37:01PM +0200, Vitaly Zaitsev via devel 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 be identified
On Wed, Oct 27 2021 at 05:37:01 PM +0200, Vitaly Zaitsev via devel
wrote:
-1 for this change, because it will consume file system space and
99.99%
of users don't need this feature at all.
That doesn't seem fair:
The overhead is about 200 bytes for each ELF object.
We have about overall
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 be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses
On Wednesday, October 27, 2021 8:12:43 AM EDT Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
> > Furthermore as someone dealing with bug reports I don't have access
> > to the RPM database. That is on the end user's machine. Often all I
> > get is a core dump attached to a bug report,
On Mi, 27.10.21 14:00, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> Sorry, but I do not see what is "baseless" about the licensing issue (see
> also the further details I added above). And the idea is not to "force
> people to stop using" stuff, but to not spend time making it
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 licensing violations easier (in some cases,
> > primarily when distributing
On Wed, Oct 27, 2021 at 02:00:36PM +0200, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > How so? It was rejected with the request to enhance the motivation section
> > and to answer some specific questions about upgrades. This has been done.
> > Why do you say an update to
On Wed, Oct 27, 2021 at 02:12:43PM +0200, Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
> > Furthermore as someone dealing with bug reports I don't have access
> > to the RPM database. That is on the end user's machine. Often all I
> > get is a core dump attached to a bug report, and
On Wed, Oct 27, 2021 at 12:47:03PM +0200, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
>
> > On Wed, Oct 27, 2021 at 09:38:35AM +0200, Florian Weimer wrote:
> >> * Ben Cotton:
> >>
> >> > https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
> >> >
> >> > == Summary
Florian Weimer wrote:
> Can we enhance this to collect the package versions of all code that is
> linked statically?
That would make the bloat even larger.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
Daniel P. Berrangé wrote:
> Furthermore as someone dealing with bug reports I don't have access
> to the RPM database. That is on the end user's machine. Often all I
> get is a core dump attached to a bug report, and if I'm lucky they
> manually typed a couple of RPM NEVRs into the bug
Zbigniew Jędrzejewski-Szmek wrote:
> How so? It was rejected with the request to enhance the motivation section
> and to answer some specific questions about upgrades. This has been done.
> Why do you say an update to a proposal that answers the issues that were
> raised should not be resubmitted?
On Wed, Oct 27, 2021 at 7:32 AM Luca Boccassi wrote:
>
> > * 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.
> >
> > Thanks,
> >
> * 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.
>
> Thanks,
> Florian
This would be indeed useful, but quite harder to do
* Zbigniew Jędrzejewski-Szmek:
> On Wed, Oct 27, 2021 at 09:38:35AM +0200, Florian Weimer wrote:
>> * Ben Cotton:
>>
>> > https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
>> >
>> > == Summary ==
>> > All binaries (executables and shared libraries) are annotated with an
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
> ELF note that identifies the rpm for which this file was built. This
On Wed, Oct 27, 2021 at 10:01:30AM +0200, Jakub Jelinek wrote:
> On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote:
> > === New system: `.note.package` ===
> >
> > The new note is created and propagated similarly to
> > `.note.gnu.build-id`. The difference is that we inject the
On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote:
> === New system: `.note.package` ===
>
> The new note is created and propagated similarly to
> `.note.gnu.build-id`. The difference is that we inject the information
> about package ''nevra'' from the build system.
Is the .note.package
On Wed, Oct 27, 2021 at 09:38:35AM +0200, Florian Weimer wrote:
> * Ben Cotton:
>
> > 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
* Ben Cotton:
> 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 identified when they
On Wed, Oct 27, 2021 at 03:24:07AM +0200, Kevin Kofler via devel wrote:
> > == Owner ==
> > * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
> > * Email: zbys...@in.waw.pl
> > * Name: Lennart Poettering
> > * Email: mzsrq...@0pointer.net
>
> > All binaries (executables and shared libraries)
> == Owner ==
> * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
> * Email: zbys...@in.waw.pl
> * Name: Lennart Poettering
> * Email: mzsrq...@0pointer.net
> All binaries (executables and shared libraries) are annotated with an
> ELF note that identifies the rpm for which this file was built.
> Hi,
>
> On Mon, 2021-10-25 at 15:09 -0400, Ben Cotton wrote:
>
> I like this idea. It will be really useful when multiple distros adopt
> it.
>
>
> It isn't immediately clear to me which of the key's will be included.
> The format describes 6 standard ones: type, os, osVersion, name,
>
Hi,
On Mon, 2021-10-25 at 15:09 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
I like this idea. It will be really useful when multiple distros adopt
it.
> === New system: `.note.package` ===
>
> The new note is created and propagated
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
> ELF note that identifies the rpm for which this file was built. This
101 - 143 of 143 matches
Mail list logo
