Am Fr., 13. Nov. 2020 um 01:28 Uhr schrieb Gunnar Hjalmarsson
:
>
> On 2020-11-12 23:20, Matthias Klumpp wrote:
> > You want this patch for AppStream:
> > https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248
>
> But only comments are changed there!?
>
> Still... I
On 2020-11-12 23:20, Matthias Klumpp wrote:
You want this patch for AppStream:
https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248
But only comments are changed there!?
Still... I built AppStream with that commit applied:
[Matthias Klumpp]
> Oh, btw: Thank you all for the last messages, knowing which commands
> to run to reproduce this easily helped quite a bit with finding the
> culprit quite quickly (and I also looked in the code for other
> instances of this, but found only the ones in AsPool).
Well, thank you
Am Do., 12. Nov. 2020 um 23:20 Uhr schrieb Matthias Klumpp :
> [...]
> You want this patch for AppStream:
> https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248
> Basically, Python thought it could free more objects than it should
> actually have freed - not sure why
Am Do., 12. Nov. 2020 um 22:21 Uhr schrieb Gunnar Hjalmarsson
:
>
> On 2020-11-12 21:28, Petter Reinholdtsen wrote:
> > [Gunnar Hjalmarsson]
> >> Additional observations:
> >>
> >> * The testing failure in Ubuntu started around October 31.
> >>
> >> * The test-command-line script fails on amd64
On 2020-11-12 21:28, Petter Reinholdtsen wrote:
[Gunnar Hjalmarsson]
Additional observations:
* The testing failure in Ubuntu started around October 31.
* The test-command-line script fails on amd64 and i386 but succeeds on
other architectures.
Is it possible to 'diff' the logs from a
[Gunnar Hjalmarsson]
> Additional observations:
>
> * The testing failure in Ubuntu started around October 31.
>
> * The test-command-line script fails on amd64 and i386 but succeeds on
>other architectures.
Is it possible to 'diff' the logs from a successful and a failing test,
to see what
Attached please find the stdout from Ubuntu's autopkgtest when running
the test-command-line script in amd64.
--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj
test-command-line-stdout.gz
Description: application/gzip
Additional observations:
* The testing failure in Ubuntu started around October 31.
* The test-command-line script fails on amd64 and i386 but succeeds on
other architectures.
--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj
[Matthias Klumpp]
> Can you give me some context for this code? If this is a warning
> coming from libappstream, it means that it somehow got fed a null
> pointer instead of a valid AsProvided object into its list, which
> shouldn't happen - is your code doing that? Are you feeding it some
>
Am Di., 10. Nov. 2020 um 01:08 Uhr schrieb Petter Reinholdtsen
:
>
> [Gunnar Hjalmarsson]
> > On an updated Debian testing:
> >
> > $ isenkram-lookup
> > /usr/lib/python3/dist-packages/isenkram/lookup.py:85: Warning invalid
> > uninstantiatable type '(null)' in cast to 'AsProvided'
> >provided
[Gunnar Hjalmarsson]
> On an updated Debian testing:
>
> $ isenkram-lookup
> /usr/lib/python3/dist-packages/isenkram/lookup.py:85: Warning invalid
> uninstantiatable type '(null)' in cast to 'AsProvided'
>provided = cpt.get_provided_for_kind(AppStream.ProvidedKind.MODALIAS)
> Segmentation
Package: isenkram-cli
Version: 0.44
Severity: serious
On an updated Debian testing:
$ isenkram-lookup
/usr/lib/python3/dist-packages/isenkram/lookup.py:85: Warning invalid
uninstantiatable type '(null)' in cast to 'AsProvided'
provided =
13 matches
Mail list logo
