[Expired for Auto Package Testing because there has been no activity for
60 days.]
** Changed in: auto-package-testing
Status: Incomplete => Expired
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https:
We're not going to re-introduce those tests in fwupd outside of upstream
CI.
** Changed in: fwupd (Ubuntu)
Status: New => Won't Fix
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.
** Tags removed: update-excuse
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2021908
Title:
fwupd: network-based tests failed to run
Status in Auto Package Testing:
Incomp
To reiterate on comment 15, I believe the failure is not due to a proxy
issue.
** Changed in: auto-package-testing
Status: New => Incomplete
** Changed in: fwupd (Ubuntu)
Status: Won't Fix => New
--
You received this bug notification because you are a member of
Canonical's Ubuntu
Using fwupdmgr refresh also worked in both data centers, here is one
example:
ubuntu@creation-test-1:~$ fwupdmgr refresh
Updating lvfs
Downloading… [ |]
failed to download file: Failed to connect to cdn.fwupd.org port 443 after
6 ms: Timeout wa
fwupdmgr refresh would download content from the CDN.
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2021908
Title:
fwupd: network-based tests failed to run
Status in Auto Pa
I've tested using wget with the proxy server configured to download a
file from fwupd.org in both data centers and did not encounter an issue.
http_proxy=http://squid.internal:3128
https_proxy=http://squid.internal:3128 wget
http://cdn.fwupd.org/downloads/01b95b0206f1a42a2bf95a432d162ef1f9f1f71edb
** Tags added: adt-297
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2021908
Title:
fwupd: network-based tests failed to run
Status in Auto Package Testing:
New
Status in
Because of this in fwupd 1.9.3 release we've disabled network tests by
default, and CI test suites will need to opt in.
https://github.com/fwupd/fwupd/commit/1d1e03fe02ad4b4bea41e9f7888d37fceb351174
1.9.3 is now in Debian unstable and mantic/proposed and I confirmed it's
working.
If the autopkg
** Tags added: update-excuse
** Tags added: mantic
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2021908
Title:
fwupd: network-based tests failed to run
Status in Auto Pack
On line 749 of the https://autopkgtest.ubuntu.com/results/autopkgtest-
mantic-vorlon-ppa/mantic/s390x/f/fwupd/20230623_011450_1ce26@/log.gz
log, it showed:
```
452s FuEngine plugins disabled: test, test_ble
```
Somehow the test plugins were disabled. This likely caused the failures.
The `failed to find 08d460be0f1f9f128413f816022a6439e0078018` part is
suspicious.
The `failed to load emulation data` was likely the old network/proxy problem.
The patch only included the endianness handling for a particular device.
The hash is probably in the wrong endianness order, I suppose?
To me; looks like the same proxy issue as before.
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2021908
Title:
fwupd: network-based tests failed to run
Status in Auto Packag
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-vorlon-
ppa/mantic/s390x/f/fwupd/20230623_011450_1ce26@/log.gz shows a failure:
[...]
165s failed to load emulation data: emulation is not allowed from config
165s FAIL: fwupd/fwupd.test (Child process exited with code 1)
[...]
165s Update
working on building it in a ppa here https://launchpad.net/~canonical-
foundations/+archive/ubuntu/ppa (just have to wait a cycle because I set
up the new ppa with the wrong options initially) then will trigger an
autopkgtest for it.
--
You received this bug notification because you are a member
Any chance you can test the potential fix on the real hardware without
needing to make a round trip to the archive to see if it works?
https://github.com/fwupd/fwupd/pull/5929
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Pac
This looks like a real failure now with the emulated "Wacom Intuos"
device. I'll bring it upstream.
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2021908
Title:
fwupd: netwo
I also think it is no longer, but was at one point, a proxy issue. The
amd64 tests have now passed although we did not make any changes to the
proxy configuration.
Additionally, as Paride mentioned the tests are failing on s390x
regardless of the data center. Does s390x have the necessary
capabili
I am not sure anymore it's a proxy issue; can we make a step back and
re-check that conclusion?
>From the test logs I don't see obvious "failed to download" errors, on
the contrary looks like the download is working. Moreover looks like to
me that fwupd/1.9.1-1 always failed on s390x regardless of
It's not the daemon that downloads stuff, it's the client (via
fwupdmgr). This should respect the environment variables http_proxy and
https_proxy, so perhaps they're not set in the process environment for
some reason.
Can you set them in /etc/environment perhaps?
--
You received this bug notifi
On the proxy settings: looks like this is one case where we set the
proxy variables in autopkgtest environment, but there's is a daemon
involved (fwupd) with its own environment where proxy vars are not set
(same situation we have e.g. with Docker).
I had a quick look at fwupd and apparently it us
As a fundamental question - do you think that pulling artifacts from
LVFS by autopkgtest is reasonable? These were originally intended for
gating upstream CI so that no code got introduced that broke existing
devices that supported emulation data.
It's a LOT less likely that such breakage happens
I'll retry the s390x test as that also ran in bos01 as we might get
lucky.
Getting the amd64 tests to pass will require some proxy server changes
though.
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://
Thanks for the links Mario, this is quite helpful.
In one of the test runs,
https://autopkgtest.ubuntu.com/results/autopkgtest-
mantic/mantic/ppc64el/f/fwupd/20230513_202849_b9c5e@/log.gz, we can see
fwupd.test fail downloading.
Downloading… [***
]Downloading…
Thanks for sharing link. Here's one that failed and I retried and it
worked.
https://autopkgtest.ubuntu.com/results/autopkgtest-
mantic/mantic/ppc64el/f/fwupd/20230513_202849_b9c5e@/log.gz
https://autopkgtest.ubuntu.com/results/autopkgtest-
mantic/mantic/ppc64el/f/fwupd/20230514_032026_71fd9@/log
On Tue, Jun 06, 2023 at 10:37:02PM -, Mario Limonciello wrote:
> Yes, but the logs are destroyed when you hit retry so I don't have the
> logs of fail followed by pass.
This is true of build logs but not autopkgtest log files. Here you can
see multiple failures with fwupd 1.9.1-1 on amd64.
ht
On Tue, Jun 06, 2023 at 10:37:02PM -, Mario Limonciello wrote:
> Yes, but the logs are destroyed when you hit retry so I don't have the
> logs of fail followed by pass.
No, autopkgtest logs are not destroyed. That is only true for package build
logs.
--
You received this bug notification be
Yes, but the logs are destroyed when you hit retry so I don't have the
logs of fail followed by pass.
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2021908
Title:
fwupd: netw
Mario, you asserted that there were jobs that "failed once and hit retry
and they pass". But the links you posted are to the test runs for fwupd
1.9.1-1, which have never passed. Are you saying that there were
individual tests within the two runs of 1.9.1-1/amd64 that demonstrated
flakiness? (if
Look at proposed migration.
Here's two:
https://autopkgtest.ubuntu.com/results/autopkgtest-
mantic/mantic/amd64/f/fwupd/20230518_091353_f87ab@/log.gz
https://autopkgtest.ubuntu.com/results/autopkgtest-
mantic/mantic/arm64/f/fwupd/20230514_021241_b9c5e@/log.gz
--
You received this bug notificat
@Mario - Could you elaborate on the issues you are seeing with the
autopkgtest environment including links to log files and examples? My
team and I would like to resolve any issues you are seeing.
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is su
I noticed that a bunch of the test runs blocking promotion passes, but
some failed.
Including some jobs that failed once and hit retry and they pass.
So perhaps this is specific to certain autopkgtest hosts?
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA
We should definitely look into the logging and why it is more cryptic in
the autopkgtest environment.
However, I also wonder if the test would succeed in lgw01. This is
something that could be tested from the staging environment.
--
You received this bug notification because you are a member of
** Also affects: fwupd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/2021908
Title:
fwupd: network-based tests failed to
34 matches
Mail list logo
