Comment 7 for bug 1813456
Revision history for this message
| Joël Krähemann (jkraehemann) wrote Re: [Bug 1813456] [NEW] gsequencer fails autopkg tests on anything except amd64 | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Hi,
Just figured out the memory leak within the test is not that grave. But
rather the AgsOscMeterCont
AgsOscResponse object.
I think this should be definitely fixed.
Bests,
Joël
On Sun, Jan 27, 2019 at 9:35 AM Matthias Klose <email address hidden> wrote:
>
> Public bug reported:
>
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> it complained, that it can't allocate memory.
>
> After assigning 8 GB of RAM the functional tests all passed on i386.
>
> By the way I would love to mark the functional tests as flaky (see DEP-8)
> https:/
>
> If we would package a more recent version of GSequencer we would be able
> to run the unit-tests during autopkgtest.
>
> Note, there 2 different types of tests unit-tests and functional
> integration-tests. The
> later are not mandatory to pass at my opinion. Especially if the VM
> doesn't get enough
> computing power. I have seen VMs taking more than 2 seconds to show a GtkMenu,
> if the delay is too long (not enough computing power) the tests aren't
> reliable anymore.
>
> To target this issue, I had to adjust the timeouts and delays. Yes,
> the tests could run much
> faster. But I decided to throttle them, to target environments will
> lesser CPU resources than
> I have on my workstation.
>
> Here is the reaction time specified:
>
> http://
>
> Here are the unit-tests to run against the installation:
>
> http://
> tests.mk.am?h=2.1.x
>
> This is new for autopkgtest and not yet available:
>
> https:/
> team/gsequencer
>
> ** Affects: gsequencer (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to
> gsequencer in Ubuntu.
> Matching subscriptions: gsequencer, ubuntu-
> https:/
>
> Title:
> gsequencer fails autopkg tests on anything except amd64
>
> Status in gsequencer package in Ubuntu:
> New
>
> Bug description:
> gsequencer (1.4.34-1 to 2.1.34-1)
> Maintainer: Debian Multimedia Maintainers
> Section: universe/misc
> 15 days old
> autopkgtest for gsequencer/
>
> The Debian maintainer provided this analysis:
> The qemu image has only 1 GB RAM assigned. This is not enough, I was able to
> reproduce the failure with 1 GB RAM, as wanting to obtain a stack-trace with GDB
> it complained, that it can't allocate memory.
>
> After assigning 8 GB of RAM the functional tests all passed on i386.
>
> By the way I would love to mark the functional tests as flaky (see DEP-8)
> https:/
>
> If we would package a more recent version of GSequencer we would be able
> to run the unit-tests during autopkgtest.
>
> Note, there 2 different types of tests unit-tests and functional
> integration-tests. The
> later are not mandatory to pass at my opinion. Especially if the VM
> doesn't get enough
> computing power. I have seen VMs taking more than 2 seconds to show a GtkMenu,
> if the delay is too long (not enough computing power) the tests aren't
> reliable anymore.
>
> To target this issue, I had to adjust the timeouts and delays. Yes,
> the tests could run much
> faster. But I decided to throttle them, to target environments will
> lesser CPU resources than
> I have on my workstation.
>
> Here is the reaction time specified:
>
> http://
>
> Here are the unit-tests to run against the installation:
>
> http://
> tests.mk.am?h=2.1.x
>
> This is new for autopkgtest and not yet available:
>
> https:/
> team/gsequencer
>
> To manage notifications about this bug go to:
> https:/