Bug#925672: efivar: diff for NMU version 37-2.1

[Mario.Limonciello]

I don't have a concern to this, but would you mind also submitting
it to Salsa and linking back so we can get it into VCS?

> -Original Message-
> From: David da Silva Polverari 
> Sent: Wednesday, June 10, 2020 12:06 AM
> To: 925...@bugs.debian.org
> Subject: Bug#925672: efivar: diff for NMU version 37-2.1
> 
> 
> [EXTERNAL EMAIL]
> 
> Control: tags 925672 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for efivar (versioned as 37-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer or cancel the NMU.
> 
> Regards,
> 
> David Polverari.

Bug#961490: fwupd: version in stable too old, no updates possible

[Mario.Limonciello]

> -Original Message-
> From: Ansgar 
> Sent: Tuesday, May 26, 2020 8:01 AM
> To: Steffen Schreiber; 961...@bugs.debian.org
> Subject: Bug#961490: fwupd: version in stable too old, no updates possible
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> On Tue, 2020-05-26 at 13:56 +0200, Steffen Schreiber wrote:
> > So I see you marked this bug as fixed/resolved.
> 
> Someone (not the maintainer) did so, but please note that the bug
> remains open even when marked as fixed in a newer version.  Debian's
> stable release team prefers bugs to be fixed in unstable/testing before
> they get fixed in (old)stable, so this is good.

The particular circumstances of this issue are that the update in question 
requires
a newer version of fwupd than is in stable.  This is not a matter of just 
backporting
a change or two and it works.  There are daemon and plugin level changes that 
have to
go together to guarantee a proper update.

This seems incompatible with the documentation around uploading to stable.
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 
> > What's the way going forward for users of stable? Installing packages
> > from testing? Are you recommending to just forget about running Debian
> > stable as is?
> 
> The maintainer hasn't yet commented on how he wants to proceed.
> Reasonable options seem to be to either update stable to the version
> currently in testing (1.3.9) or to update to a later version of 1.2.X.
> 
> Ansgar

If a particular update requires a newer fwupd version I don't think it's 
reasonable
to push that version to all Debian users who may not need the newer fwupd 
version
and might not be willing to accept the risk of regressions in a newer version.

"Fixes must be minimal and relevant"

So in this circumstance if your device needs the newer version you should 
probably
take the package from testing instead.

Bug#960688: fwupd: missing Breaks: fwupdate (<< 12-7)

[Mario.Limonciello]

Let me elaborate the timeline.

* Originally fwupdate contained /usr/bin/fwupdate.
* It was merged into fwupd and fwupdate went into maintenance only mode.
* In Debian we made fwupdate a transition package with nothing in it.
This is when the Replaces got put into place.

* Because it was a transition package, there is a chance that a user already
removed /var/lib/fwupdate and so a request was put in for fwupd to clean that 
up.

* Later, a compatibility binary /usr/bin/fwupdate was added into fwupd.
This performs similar actions as the old fwupdate provided /usr/bin/fwupdate.

Hopefully that illustrates the timeline.  As fwupdate is a transition package 
now,
I don't know that it makes sense to add the Breaks now, please advise.


> -Original Message-
> From: Andreas Beckmann 
> Sent: Friday, May 15, 2020 7:28 AM
> To: Debian Bug Tracking System
> Subject: Bug#960688: fwupd: missing Breaks: fwupdate (<< 12-7)
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.3.9-4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts replaces-without-breaks
> 
> Hi,
> 
> during a test with piuparts and DOSE tools I noticed your package causes
> removal of files that also belong to another package.
> This is caused by using Replaces without corresponding Breaks.
> 
> The installation sequence to reproduce this problem is
> 
>   apt-get install fwupdate/stable
>   # (1)
>   apt-get install fwupd
>   apt-get remove fwupd
>   # (2)
> 
> The list of installed files at points (1) and (2) should be identical,
> but the following files have disappeared:
> 
>   /usr/bin/fwupdate
>   /usr/share/man/man1/fwupdate.1.gz
>   /var/lib/fwupdate/
> 
> This is a serious bug violating policy 7.6, see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-
> files-and-replacing-packages-replaces
> and also see the footnote that describes this incorrect behavior:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#id13
> 
> The fwupd package has the following relationships with fwupdate:
> 
>   Conflicts: n/a
>   Breaks:n/a
>   Replaces:  fwupdate (<< 12-7)
>   Provides:  fwupdate
> 
> >From the attached log (scroll to the bottom...):
> 
> 0m32.0s ERROR: FAIL: After purging files have disappeared:
>   /usr/bin/fwupdate  owned by: fwupd
>   /usr/share/man/man1/fwupdate.1.gz  owned by: fwupd
>   /var/lib/fwupdate/ owned by: fwupdate
> 
> 0m32.0s ERROR: FAIL: After purging files have been modified:
>   /var/lib/dpkg/info/fwupdate.list   not owned
> 
> 
> cheers,
> 
> Andreas

Bug#955387: Regression: flashrom programmer support reduced on non-x86

[Mario.Limonciello]

> -Original Message-
> From: Carl-Daniel Hailfinger 
> Sent: Monday, March 30, 2020 5:06 PM
> To: sub...@bugs.debian.org
> Subject: Bug#955387: Regression: flashrom programmer support reduced on
> non-x86
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: flashrom
> Version: 1.2-5
> 
> Dear maintainers,
> 
> Compared to version 1.1-1 arm64, the following programmers are missing in
> version 1.2-5 on arm64:
> ATAVIA
> DRKAISER
> GFXNVIDIA
> IT8212
> NICINTEL
> NICINTEL_EEPROM
> NICINTEL_SPI
> OGP_SPI
> SATASII
> 
> This might be related to switching the build from GNU Make to Meson. The
> flashrom meson build files currently do not handle arch-specific enabling
> of programmers.
> 
> To solve this, the meson build files can be patched or the packaging can
> add special rules for each architecture similar to the rules introduced in
> 1.2-4. Caveat: Differentiating between x86 and non-x86 is not enough.
> Future upstream versions of flashrom will ship with more complete meson
> build files matching the makefile.
> 
> As an alternative, building with the flashrom makefile should result in a
> build with the maximum functionality supported on each architecture like
> before.

The meson based flashrom is built so that libflashrom can be distributed.
Switching to a Makefile based flashrom build does not include libflashrom.

So my preference here is that this be fixed by the meson build files and we
bring that patch back to Debian.  Would you be able to work with upstream
to make that happen?

Bug#955259: libjcat: Please add consider adding autopkgtest coverage

[Mario.Limonciello]

> -Original Message-
> From: Simon McVittie 
> Sent: Monday, March 30, 2020 5:23 PM
> To: Limonciello, Mario
> Cc: 955...@bugs.debian.org; sub...@bugs.debian.org
> Subject: Re: Bug#955259: libjcat: Please add consider adding autopkgtest
> coverage
> 
> 
> [EXTERNAL EMAIL]
> 
> On Mon, 30 Mar 2020 at 19:09:23 +, mario.limoncie...@dell.com wrote:
> > Upstream the following was recently accepted to allow installed-tests to
> work
> > Without the source tree nearby.
> >
> https://github.com/hughsie/libjcat/commit/d6dc3e90b0c805cc50bff9d1d1b87ff57
> 5e53769
> 
> That's a lot like what I did. I'll recheck soon whether my branch would
> work with their patch instead of mine.

Thanks!

> 
> Salsa was mid-upgrade and not working very well when I sent the initial
> patches, but I'll send a MR for the new version.
> 
> smcv

As a general statement since we have a super responsive upstream I would rather
flesh out non debian/* patches upstream immediately and then pull them back as
cherry-picks and add packaging to match them at the same time.

Bug#955258: libjcat-dev: -dev package missing some required dependencies

[Mario.Limonciello]

Thanks, I saw this was fixed by this MR:
https://salsa.debian.org/efi-team/libjcat/-/merge_requests/2

> -Original Message-
> From: Simon McVittie 
> Sent: Saturday, March 28, 2020 3:20 PM
> To: Debian Bug Tracking System
> Subject: Bug#955258: libjcat-dev: -dev package missing some required
> dependencies
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: libjcat-dev
> Version: 0.1.0-1
> Severity: important
> Tags: patch
> 
> I tried adding some basic autopkgtests to libjcat. One useful thing to do
> in an autopkgtest for a library is to compile a "hello world" program
> against the library. This often reveals missing -dev dependencies, and in
> the case of libjcat that's exactly what happened.
> 
> Please see attached.
> 
> smcv

Bug#955259: libjcat: Please add consider adding autopkgtest coverage

[Mario.Limonciello]

Upstream the following was recently accepted to allow installed-tests to work
Without the source tree nearby.
https://github.com/hughsie/libjcat/commit/d6dc3e90b0c805cc50bff9d1d1b87ff575e53769


> -Original Message-
> From: Simon McVittie 
> Sent: Saturday, March 28, 2020 3:29 PM
> To: Debian Bug Tracking System
> Subject: Bug#955259: libjcat: Please add consider adding autopkgtest
> coverage
> 
> 
> [EXTERNAL EMAIL]
> 
> Source: libjcat
> Version: 0.1.0-1
> Severity: wishlist
> Tags: patch
> Control: block -1 by 955258
> 
> I noticed that libjcat has GNOME-style installed-tests, which in principle
> make it easy to add autopkgtest coverage, so I tried to contribute a
> trivial patch to do so. Unfortunately, the installed-tests don't actually
> work when run installed (they rely on the original source tree), so it
> turned out to be less trivial than I'd hoped.
> 
> I've attached patches, but the patch added in debian/patches should
> probably be discussed with upstream. As well as making the test pass, it
> also fixes a source of non-reproducibility.
> 
> For it to pass, the test for libjcat-dev requires the patches I attached
> to #955258.
> 
> smcv

Bug#932617: any update on this as I still got it today with the update (again)

[Mario.Limonciello]

1.3.9.2?  You mean 1.3.9-2?

They were supposed to be removed about 5 months ago.  The preinst, postrm, and 
postinst has the stuff for doing these:
https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.preinst
https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.postrm
https://salsa.debian.org/efi-team/fwupd/-/blob/debian/debian/fwupd.postinst


> -Original Message-
> From: shirish शिरीष 
> Sent: Thursday, March 19, 2020 11:02 AM
> To: 932...@bugs.debian.org
> Subject: Bug#932617: any update on this as I still got it today with the 
> update
> (again)
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi all,
> 
> See -
> 
> $ adequate fwupd
> fwupd: obsolete-conffile /etc/dbus-
> 1/system.d/org.freedesktop.fwupd.conf
> fwupd: obsolete-conffile /etc/fwupd/remotes.d/fwupd.conf
> 
> I wanna try fwupd but once the above obsolete conffiles are removed. I do
> know it's a work in progress but still. FWIW, the package got updated to
> 1.3.9.2
> 
> --
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
> 
> E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

> From: Limonciello, Mario
> Sent: Thursday, March 19, 2020 8:58 AM
> To: Diederik de Haas
> Cc: 943...@bugs.debian.org
> Subject: RE: Bug#943343: fwupd: fwupd-refresh.service failed to start
> Refresh fwupd metadata and update motd.
> 
> > -Original Message-
> > From: Diederik de Haas 
> > Sent: Thursday, March 19, 2020 8:53 AM
> > To: Limonciello, Mario
> > Cc: 943...@bugs.debian.org
> > Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start
> > Refresh fwupd metadata and update motd.
> >
> > On donderdag 19 maart 2020 14:42:56 CET mario.limoncie...@dell.com
> > wrote:
> > > Has your system been rebooted recently?
> >
> > Yes. I usually shutdown my system at night.
> >
> > > I check on my (working) system and I don't have /run/motd.d as a
> > > symlink to /run/private/motd.d. For my system /run/motd.d is a real
> > > directory with a subdirectory "fwupd".
> > >
> > > I have a suspicion this is related to the issue.
> >
> > I don't have a /run/private directory and also no /run/motd.d.
> > I do have /run/motd.dynamic which is the same as "uname -nrsvm"
> (uname
> > - a minus the GNU/Linux part)
> 
> In your first post you had:
> 
> And about the runtime directory:
> $ ls -ld /run/motd.d
> lrwxrwxrwx 1 root root 14 oct 23 16:06 /run/motd.d -> private/motd.d $ ls -ld
> /run/private/
> drwx-- 3 root root 60 oct 23 16:06 /run/private/ $ sudo ls -ld
> /run/private/motd.d drwxr-xr-x 2 62803 62803 40 oct 23 16:06
> /run/private/motd.d $ sudo ls -l /run/private/motd.d total 0

Sorry - I see now that was from a while back.

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

> -Original Message-
> From: Diederik de Haas 
> Sent: Thursday, March 19, 2020 8:53 AM
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start
> Refresh fwupd metadata and update motd.
> 
> On donderdag 19 maart 2020 14:42:56 CET mario.limoncie...@dell.com
> wrote:
> > Has your system been rebooted recently?
> 
> Yes. I usually shutdown my system at night.
> 
> > I check on my (working) system and I don't have /run/motd.d as a
> > symlink to /run/private/motd.d. For my system /run/motd.d is a real
> > directory with a subdirectory "fwupd".
> >
> > I have a suspicion this is related to the issue.
> 
> I don't have a /run/private directory and also no /run/motd.d.
> I do have /run/motd.dynamic which is the same as "uname -nrsvm" (uname -
> a minus the GNU/Linux part)

In your first post you had:

And about the runtime directory:
$ ls -ld /run/motd.d
lrwxrwxrwx 1 root root 14 oct 23 16:06 /run/motd.d -> private/motd.d
$ ls -ld /run/private/
drwx-- 3 root root 60 oct 23 16:06 /run/private/
$ sudo ls -ld /run/private/motd.d
drwxr-xr-x 2 62803 62803 40 oct 23 16:06 /run/private/motd.d
$ sudo ls -l /run/private/motd.d
total 0

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

> -Original Message-
> From: Diederik de Haas 
> Sent: Thursday, March 19, 2020 7:57 AM
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start
> Refresh fwupd metadata and update motd.
> 
> On woensdag 18 maart 2020 22:40:22 CET mario.limoncie...@dell.com wrote:
> > I suspect this is related to an upgrade from the intermediary version
> > that had problematic objects/permissions created.
> 
> > Can you please try to check whether there are broken symlinks in
> > /var/lib/private or /var/cache/private?
> 
> It seems there are no symlinks, so also not broken symlinks.
> 
> root@bagend:~# ls -la /var/lib/private/
> total 12
> drwx--  3 root root 4096 mei  3  2018 .
> drwxr-xr-x 82 root root 4096 mrt 19 08:47 ..
> drwxr-xr-x  2 root root 4096 jan 10  2019 systemd root@bagend:~# ls -la
> /var/lib/private/systemd/ total 8 drwxr-xr-x 2 root root 4096 jan 10  2019 .
> drwx-- 3 root root 4096 mei  3  2018 ..
> root@bagend:~# ls -la /var/cache/private/ total 16
> drwx--  4 root  root  4096 okt  9 21:36 .
> drwxr-xr-x 22 root  root  4096 mrt  9 11:56 ..
> drwxr-xr-x  2 62803 62803 4096 jul 30  2019 fwupd drwxr-xr-x  2 62803 62803
> 4096 okt  9 21:36 fwupdmgr root@bagend:~# ls -la
> /var/cache/private/fwupd/ total 720
> drwxr-xr-x 2 62803 62803   4096 jul 30  2019 .
> drwx-- 4 root  root4096 okt  9 21:36 ..
> -rw-r--r-- 1 62803 62803 722862 jul 30  2019 metadata.xmlb
> -rw-r--r-- 1 62803 62803   1471 jul 30  2019 metainfo.xmlb
> root@bagend:~# ls -la /var/cache/private/fwupdmgr/ total 8 drwxr-xr-x 2
> 62803 62803 4096 okt  9 21:36 .
> drwx-- 4 root  root  4096 okt  9 21:36 ..
> 
> 
> FTR: My system is a fully up-to-date Sid system # systemd --version systemd
> 245 (245.2-1)
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
> ++LIBCRYPTSETUP GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID
> +ELFUTILS
> ++KMOD +IDN2 -IDN
> +PCRE2 default-hierarchy=hybrid

Has your system been rebooted recently?  
I check on my (working) system and I don't have /run/motd.d as a symlink to 
/run/private/motd.d.
For my system /run/motd.d is a real directory with a subdirectory "fwupd".

I have a suspicion this is related to the issue.

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

I suspect this is related to an upgrade from the intermediary version that had 
problematic objects/permissions created.

Can you please try to check whether there are broken symlinks in 
/var/lib/private or /var/cache/private?

Thanks,

> -Original Message-
> From: Diederik de Haas 
> Sent: Saturday, March 14, 2020 7:26 AM
> To: Debian Bug Tracking System
> Subject: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.3.9-2
> Followup-For: Bug #943343
> 
> Essentially the same issue as initially reported, but just got version
> 1.3.9-2 and it's still happening.
> Running the 'ExecStart' line manually succeeded successfully.
> 
> root@bagend:~# systemctl status fwupd-refresh.service ● fwupd-
> refresh.service - Refresh fwupd metadata and update motd
>  Loaded: loaded (/lib/systemd/system/fwupd-refresh.service; static; vendor
> preset: disabled)
>  Active: failed (Result: exit-code) since Sat 2020-03-14 09:37:54 CET; 3h 
> 32min
> ago
> TriggeredBy: ● fwupd-refresh.timer
>Docs: man:fwupdmgr(1)
>Main PID: 13148 (code=exited, status=1/FAILURE)
> 
> mrt 14 09:37:54 bagend systemd[1]: Starting Refresh fwupd metadata and
> update motd...
> mrt 14 09:37:54 bagend systemd[1]: fwupd-refresh.service: Main process exited,
> code=exited, status=1/FAILURE mrt 14 09:37:54 bagend systemd[1]: fwupd-
> refresh.service: Failed with result 'exit-code'.
> mrt 14 09:37:54 bagend systemd[1]: Failed to start Refresh fwupd metadata and
> update motd.
> root@bagend:~# systemctl restart fwupd-refresh.service Job for fwupd-
> refresh.service failed because the control process exited with error code.
> See "systemctl status fwupd-refresh.service" and "journalctl -xe" for details.
> root@bagend:~# journalctl -xe
> -- A start job for unit fwupd-refresh.timer has finished successfully.
> --
> -- The job identifier is 5651.
> mrt 14 13:08:51 bagend systemd[1]: Reloading.
> mrt 14 13:08:51 bagend systemd[1]: /lib/systemd/system/dbus.socket:5:
> ListenStream= references a path below legacy directory /var/run/, updating
> /var/run/d> mrt 14 13:08:52 bagend systemd[1]: Reloading.
> mrt 14 13:08:52 bagend systemd[1]: /lib/systemd/system/dbus.socket:5:
> ListenStream= references a path below legacy directory /var/run/, updating
> /var/run/d> mrt 14 13:08:55 bagend dbus-daemon[828]: [system] Reloaded
> configuration mrt 14 13:10:24 bagend systemd[1]: Starting Refresh fwupd
> metadata and update motd...
> -- Subject: A start job for unit fwupd-refresh.service has begun execution
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> --
> -- A start job for unit fwupd-refresh.service has begun execution.
> --
> -- The job identifier is 5965.
> mrt 14 13:10:24 bagend systemd[1]: fwupd-refresh.service: Main process exited,
> code=exited, status=1/FAILURE
> -- Subject: Unit process exited
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> --
> -- An ExecStart= process belonging to unit fwupd-refresh.service has exited.
> --
> -- The process' exit code is 'exited' and its exit status is 1.
> mrt 14 13:10:24 bagend systemd[1]: fwupd-refresh.service: Failed with result
> 'exit-code'.
> -- Subject: Unit failed
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> --
> -- The unit fwupd-refresh.service has entered the 'failed' state with result 
> 'exit-
> code'.
> mrt 14 13:10:24 bagend systemd[1]: Failed to start Refresh fwupd metadata and
> update motd.
> -- Subject: A start job for unit fwupd-refresh.service has failed
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> --
> -- A start job for unit fwupd-refresh.service has finished with a failure.
> --
> -- The job identifier is 5965 and the job result is failed.
> root@bagend:~# cat $(locate fwupd-refresh.service) [Unit] Description=Refresh
> fwupd metadata and update motd
> Documentation=man:fwupdmgr(1)
> After=network.target network-online.target systemd-networkd.service
> NetworkManager.service connman.service
> 
> [Service]
> Type=oneshot
> CacheDirectory=fwupdmgr
> StandardError=null
> DynamicUser=yes
> RestrictAddressFamilies=AF_NETLINK AF_UNIX AF_INET AF_INET6
> SystemCallFilter=~@mount ProtectKernelModules=yes
> ProtectControlGroups=yes RestrictRealtime=yes
> SuccessExitStatus=2
> ExecStart=/usr/bin/fwupdmgr refresh --no-metadata-check root@bagend:~#
> /usr/bin/fwupdmgr refresh --no-metadata-check Fetching metadata
> https://cdn.fwupd.org/downloads/firmware.xml.gz
> Downloading… [***]
> Fetching signature https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
> 
> Successfully downloaded new metadata: 1 local device supported
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
> (101,
> 'experimental'), (1, 

Bug#951589: flashrom: Update to version 1.2

[Mario.Limonciello]

With the new stuff I think you need to actually split it into 3 distinct binary 
packages in debian/ :

flashrom
libflashrom
libflashrom-dev


Also I think you need to explicitly build with meson rather than autotools to 
get it to make the pkgconfig file IIRC.

From: Gürkan Myczko 
Sent: Tuesday, February 18, 2020 9:09 AM
To: Limonciello, Mario; 951...@bugs.debian.org
Cc: Debian Bug Tracking System
Subject: Re: Bug#951589: flashrom: Update to version 1.2


[EXTERNAL EMAIL]
Hi

If you dont mind with 1.2-2

waiting for the update atm

http://phd-sid.ethz.ch/debian/flashrom/2020/
Gürkan




On Feb 18, 2020, at 15:51, Mario Limonciello 
mailto:mario.limoncie...@dell.com>> wrote:
Package: flashrom
Severity: wishlist
Tags: upstream

Dear Maintainer,

Can you please upgrade to the recently released version 1.2?

This package now supports a library for other applications to compile against
it.  As part of upgrading to 1.2, can you please introduce new binary packages
for that library and pkgconfig/headers too?

I would like to compile fwupd against it to introduce flashrom support for
fwupd in Debian.



-- System Information:
Debian Release: bullseye/sid
 APT prefers focal
 APT policy: (500, 'focal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flashrom depends on:
ii  libc6 2.30-0ubuntu3
ii  libftdi1-21.4-2build1
ii  libpci3   1:3.6.4-1
ii  libusb-0.1-4  2:0.1.12-32
ii  libusb-1.0-0  2:1.0.23-2build1

flashrom recommends no packages.

flashrom suggests no packages.

Bug#943343:

[Mario.Limonciello]

I expect that this should not be happening with current systemd in testing and 
fwupd in testing (or unstable).  Can you please confirm?

Bug#948546:

[Mario.Limonciello]

If you adopt this release, please also backport this commit:
https://github.com/hughsie/libgusb/commit/17f9cda073459fc673a99bd281e929a999643374

To avoid causing significantly higher power consumption in software that uses 
libgusb.

Bug#947205: fwupd.shutdown failed with exit status 2

[Mario.Limonciello]

It's fixed upstream by this commit:

https://github.com/fwupd/fwupd/commit/1db7e987ae9cf1b81117040762e90db6c15b5202

Which should be part of next release.

On Dec 22, 2019 16:00, Jochen Sprickerhof  wrote:

[EXTERNAL EMAIL]

Package: fwupd
Version: 1.3.5-1
Severity: normal

Hi,

when shutting down my system, systemd prints:

/lib/systemd/system-shutdown/fwupd.shutdown failed with exit status 2

looking into fwupd.shutdown, I guess this should normally be prevented by

[ -f /var/lib/fwupd/pending.db ] || exit 0

And it's all fine if I remove the pending.db. But running

fwupdmgr refresh

creates the file again, although

fwupdmgr get-updates

tells me that there are no updates.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwupd depends on:
ii  libc6  2.29-6
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.5-1
ii  libfwupdplugin11.3.5-1
ii  libglib2.0-0   2.62.3-2
ii  libgnutls303.6.11.1-2
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.68.2-1
ii  libsqlite3-0   3.30.1-1
ii  libtss2-esys0  2.3.1-3
ii  libxmlb1   0.1.14-1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
pn  bolt  
pn  fwupd-signed  
ii  python3   3.7.5-3

fwupd suggests no packages.

-- no debconf information

Bug#946072:

[Mario.Limonciello]

I've got a fix for this in 
https://salsa.debian.org/debian/tpm-udev/merge_requests/1

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

Internal Use - Confidential

> -Original Message-
> From: Werner Mahr 
> Sent: Tuesday, December 3, 2019 6:52 AM
> To: 943...@bugs.debian.org
> Subject: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh 
> fwupd
> metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> > > Internal Use - Confidential
> > >
> > > In 1.3.2-5 the service is disabled by default (and also this issue should
> be fixed).
> 
> > Okay.  So, the bug can be closed, I guess.
> 
> I'm sorry, but it seems that it at least was reintroduced somewhen. I have
> 1.3.4-1 installed on testing and it fails to start. Unfortunately is is not
> that verbose on the logs.
> 
> $ service fwupd-refresh status
> ● fwupd-refresh.service - Refresh fwupd metadata and update motd
> Loaded: loaded (/lib/systemd/system/fwupd-refresh.service; static; vendor
> preset: disabled)
> Active: failed (Result: exit-code) since Mon 2019-12-02 09:16:34 CET; 2h 8min
> ago
> Docs: man:fwupdmgr(1)
> Process: 144751 ExecStart=/usr/bin/fwupdmgr refresh --no-metadata-check
> (code=exited, status=1/FAILURE)
> Main PID: 144751 (code=exited, status=1/FAILURE)
> Dez 02 09:16:34 werner1 systemd[1]: Starting Refresh fwupd metadata and
> update
> motd...
> Dez 02 09:16:34 werner1 systemd[1]: fwupd-refresh.service: Main process
> exited, code=exited, status=1/FAILURE
> Dez 02 09:16:34 werner1 systemd[1]: fwupd-refresh.service: Failed with result
> 'exit-code'.
> Dez 02 09:16:34 werner1 systemd[1]: Failed to start Refresh fwupd metadata and
> update motd.
> 
> Called from cmdline directly it still works.
> 
> --
> MfG usw.
> 
> Werner Mahr

What version of systemd are you running on your local system?  Did you bring 
that back
from unstable as well?

Bug#945203: fwupd: Cannot update firmware

[Mario.Limonciello]

Nothing fwupd can do about this.  It's either efivarfs NV store is full on your 
box or BIOS is locking it down.

Bug#945204: Incorrect unversioned dependency on libxmlb1

[Mario.Limonciello]

I believe libxmlb1 may be missing debian/symbols leading to this behavior.

On Nov 21, 2019 01:18, Arto Jantunen  wrote:

[EXTERNAL EMAIL]

Package: fwupd
Version: 1.3.3-3
Severity: serious


The unversioned dependency on libxmlb1 is incorrect. On a partially upgraded
system it reports this at startup (all dependencies are satisfied):

fwupdmgr: /lib/x86_64-linux-gnu/libxmlb.so.1: version `LIBXMLB_0.1.7' not
found (required by fwupdmgr)
fwupdmgr: /lib/x86_64-linux-gnu/libxmlb.so.1: version `LIBXMLB_0.1.13' not
found (required by fwupdmgr)

This may also be a bug in libxmlb, depending on how the dependency is being
generated. I did not check, please reassign if needed.

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwupd depends on:
ii  libarchive13   3.3.3-4+deb10u1
ii  libc6  2.29-2
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.3-3
ii  libgcab-1.0-0  1.2-3~deb10u1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libgnutls303.6.7-4
ii  libgpg-error0  1.35-1
ii  libgpgme11 1.12.0-6
ii  libgudev-1.0-0 232-2
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-25
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.64.2-2
ii  libsqlite3-0   3.29.0-2
ii  libtss2-esys0  2.1.0-4
ii  libxmlb1   0.1.6-2
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
pn  bolt  
pn  fwupd-signed  
ii  python3   3.7.3-1

fwupd suggests no packages.

-- no debconf information

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

> On Mon, Oct 28, 2019 at 02:46:03PM +, mario.limoncie...@dell.com wrote:
> > I guess by this argument it really should be made into a Depends not
> > a Recommends not because fwupd internally needs it to work but to ensure
> > those architecture constraints get met effectively.
> 
> Recommends work no different from depends when it comes to the
> architecture constraint.
> 
> > Part of the reason to make it Recommends is that it only is needed for 4
> architectures.
> > I'm not sure if setting architecture specific dependencies is valid syntax, 
> > but if so
> > this updated changeset should accomplish the goal.
> 
> Yes, this syntax does work. The architecture qualification is resolved
> at build time and the resulting binary packages will have the dependency
> exactly for those architectures that need it.

Thanks for your confirmation.

> 
> >
> https://github.com/fwupd/fwupd/commit/88623a90fae36b61093c84198acfdba6b
> ce3e533

Steve, what do you think of this?  Since it's going to need to be a NEW binary 
package
I suspect you'll need to sponsor it for me if we agree to go this route.

> 
> This looks sane to me. Keep in mind that you also need to upload
> fwupd-*-signed.

That part gets handled by some backend service when the new template packages 
are made.

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

> -Original Message-
> From: Helmut Grohne 
> Sent: Saturday, October 26, 2019 1:16 AM
> To: Steve McIntyre
> Cc: 943...@bugs.debian.org; debian-cr...@lists.debian.org
> Subject: Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi Steve,
> 
> On Fri, Oct 25, 2019 at 10:55:30PM +0100, Steve McIntyre wrote:
> > >So I see two possible routes here:
> > > 1. Remove M-A:foreign. (Nobody likes that)
> > > 2. a. Move the efi packages to a separate non-M-A:foreign package.
> > >b. Have fwupd depend on that new package.
> > >c. Rename the fwupd dependency of fwupd-armhf-signed to that new
> > >   package.
> >
> > Ummm, I don't think I follow your logic here at all. The normal system
> > pieces of the fwupd package (i.e. the bits that are executed by the
> > running Linux system need to match the arch you're running (to be
> > useful). But to be able to work on a normal system, the underlying EFI
> > binaries *must* match the hardware that's running (otherwise the EFI
> > firmware won't be able to use them at all). *However*, in some
> > circumstances (like building a live image) we want to allow
> > installation of all versions of the fwupd EFI binaries.
> 
> I think I follow your requirements.
> 
> > I think this particular situation is not well-described at all by M-A!
> 
> Unfortunately, I very much concur with this. I (and others) tried hard
> to describe M-A, but we always run into a roadblock: M-A must talk about
> "interfaces" of a package and "interfaces" are not well-described at all
> by Debian. In other words: In order to describe M-A, we must describe
> what "interface of a package" means. Essentially it means "not
> everything a package ships is part of its interface, but sometimes it is
> an implementation detail".
> 
> So here we were first thinking "the *.efi files are not part of the
> interface, so M-A:foreign is fine". Then I noticed that they're used by
> the sign package and thus I concluded that "oh they art part of the
> interface and M-A:foreign is thus wrong". Now we have a choice between
> removing M-A:foreign and changing interfaces (i.e. moving files to
> different packages).
> 
> > Maybe we could do something like:
> >
> >  * fwupd (non-M-A) - bits in /usr/{s,}bin, must have the right arch
> >installed
> >  * (we could possibly split out some of the common data into a
> >M-A:foreign fwupd-data package)
> >  * fwupd-efi (M-A:same) for each architecture
> 
> I don't see why removing M-A:foreign (or splitting a fwupd-data package)
> from fwupd would be required. All I said was that the *.efi files must
> not reside in a M-A:foreign package.
> 
> > but I don't see how to ensure that the *right* fwupd-efi package is
> > installed for a system that wants to run it...
> 
> Let me try to explain this in terms of interfaces. Suppose we keep the
> fwupd-efi (or fwupd-unsigned as it was previously called) package, have
> it contain the *.efi binaries and be M-A:same. Now we keep fwupd
> M-A:foreign. What does this do to multiarch?
> 
> The package building that uses the *.efi files must not build depend on
> fwupd for that matter, because we say that the *.efi files are not part
> of the interface "fwupd". They're still used internally by fwupd.
> Instead you build depend on fwupd-efi (or fwupd-unsigned as it was
> called in the patch). All is well here.
> 
> Now fwupd can depend on fwupd-efi. Given that dependencies always ensure
> same-arch constraints (unless M-A:foreign on the dependee, :any or
> :native is involved), fwupd will always get the fwupd-efi instance of
> the same architecture as itself. The M-A:foreign will practically ensure
> that the native fwupd is installed. The latest patch doesn't have that
> dependency, but turned it into a recommendation instead. Like
> dependencies, these are also preserving the architecture constraint by
> default.
> 

I guess by this argument it really should be made into a Depends not
a Recommends not because fwupd internally needs it to work but to ensure
those architecture constraints get met effectively.

Part of the reason to make it Recommends is that it only is needed for 4 
architectures.
I'm not sure if setting architecture specific dependencies is valid syntax, but 
if so
this updated changeset should accomplish the goal.

https://github.com/fwupd/fwupd/commit/88623a90fae36b61093c84198acfdba6bce3e533

> Does this help you, Steve? I don't feel like I've explained it
> particularly well. I've Cced d-cross@l.d.o now. Please keep them in the
> loop so maybe Guillem or Josch can do a better job at explaining this.
> Please bear with us and don't give up.
> 
> Helmut

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

On Oct 25, 2019 14:46, Helmut Grohne  wrote:

[EXTERNAL EMAIL]

On Fri, Oct 25, 2019 at 04:01:10PM +, mario.limoncie...@dell.com wrote:
> I made some modifications and think I captured your suggestion here
> https://github.com/fwupd/fwupd/commit/3508aecefdbd81924314834ac9e14bcd71aa253f
>
> Can you make sure that looks good now?

Unfortunately, no. Ansgar Burchardt kindly pointed out that Built-Using
must refer to a source package, not a binary package. This was wrong in
the previous iteration and I didn't spot it. Refer to the debian policy
section 7.8.

Now there are two other subtle things left.

Previously, fwupd included the *.efi images. Now it recommends them. Is
that enough or should that be a hard dependency to retain the old
behaviour? I don't know. Does fwupd actually work without the *.efi
binaries?

It used to be a hard dependency, but these days the runtime will detect this 
situation and show the user an error that the efi binary is missing so they 
can't do UEFI updates until installed.

It was introduced about the same time we introduced signed binaries to Debian.



I'm also wondering why the signing-template includes the SIGNARCH in the
package name. This is not a regression, but it should follow the same
reasoning as for why fwupd-unsigned doesn't have to include an
architecture. Do note that the same binary package may be built from
different source packages for different architectures as long as now two
source packages build it for the same architecture. For instance
libsystemd-dev used to be built from different source packages for
linux-any and kfreebsd-any. Can we simplify that part as well?

Helmut

This was mostly copied off of what grub2 did, which split it up this way. I 
don't see a strong reason that it can't be adjusted (of course need to do 
package transitions and stuff).

Steve, any thoughts?

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

> -Original Message-
> From: Helmut Grohne 
> Sent: Friday, October 25, 2019 9:30 AM
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
> 
> 
> [EXTERNAL EMAIL]
> 
> On Fri, Oct 25, 2019 at 02:08:34PM +, mario.limoncie...@dell.com wrote:
> > I took a stab at how this should work here (not yet merged):
> >
> https://github.com/fwupd/fwupd/commit/809eb181f57dc5158b5d37d2855a0a48
> eafc3565
> >
> > Can you please review that and make sure you agree it's done correctly?
> 
> I think this should technically work, but it seems unnecessarily
> complex.

Thanks for reviewing it.

> 
> You split the various firmware packages into
> fwupd-$(DEB_HOST_ARCH)-unsigned. Why did you do that? Why not have one
> real fwupd-unsigned package? Clearly you intend them to be
> coinstallable, which is why you marked them M-A:same. Note that M-A:same
> doesn't make sense, when you only list one specific architecture in the
> Architecture field. Can you maybe do the following?
> 
> d/control:
> Package: fwupd-unsigned
> Architecture: amd64 i386 ...
> Multi-Arch: same
> no Provides:
> 
> I also think that Built-Using must refer to real packages, which is not
> presently the case. My suggestion would ensure that.
> 

I made some modifications and think I captured your suggestion here
https://github.com/fwupd/fwupd/commit/3508aecefdbd81924314834ac9e14bcd71aa253f

Can you make sure that looks good now?

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

Thanks for the heads up.

I took a stab at how this should work here (not yet merged):
https://github.com/fwupd/fwupd/commit/809eb181f57dc5158b5d37d2855a0a48eafc3565

Can you please review that and make sure you agree it's done correctly?

> -Original Message-
> From: Helmut Grohne 
> Sent: Thursday, October 24, 2019 11:33 PM
> To: Debian Bug Tracking System
> Subject: Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.3.2-5
> Severity: important
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> Control: affects -1 + src:fwupd-armhf-signed
> 
> TL;DR: The *.efi images must not live in a M-A:foreign binary package.
> 
> fwupd is presently marked Multi-Arch: foreign. Likely for good reasons.
> Unfortunately, this is subtly wrong. fwupd contains (unsigned) efi
> binaries in /usr/lib/fwupd/efi. These binaries have
> architecture-dependent names. When you cross build fwupd-armhf-signed
> from amd64, it tries to sign fwupdx64.efi and the build fails.
> 
> Now we have two possible routes. Either fwupdx64.efi is part of the
> interface of fwupd. Then clearly the interface is architecture-dependent
> and the Multi-Arch: foreign marking is wrong. In the other case,
> fwupd-armhf-signed is accessing an internal aspect of fwupd and must not
> do that. The latter would essentially mean that cannot have
> fwupd-armhf-signed, so the former seems more plausible.
> 
> Simply removing the foreign marking isn't going to make us much happier
> either (though it might fix cross building fwupd-armhf-signed). I think
> what we need here is recognizing that fwupd has both
> architecture-independent and architecture-dependent interfaces. The
> logical consequence is splitting the package into two (usually one being
> M-A:foreign and the other M-A:same).
> 
> So I see two possible routes here:
>  1. Remove M-A:foreign. (Nobody likes that)
>  2. a. Move the efi packages to a separate non-M-A:foreign package.
> b. Have fwupd depend on that new package.
> c. Rename the fwupd dependency of fwupd-armhf-signed to that new
>package.
> 
> Helmut

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

Internal Use - Confidential

In 1.3.2-5 the service is disabled by default (and also this issue should be 
fixed).

> -Original Message-
> From: Jean-Marc 
> Sent: Wednesday, October 23, 2019 11:37 AM
> To: Debian Bug Tracking System
> Subject: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.3.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> On my PC, fwupd-refresh.service failed to start.
> 
> $ systemctl status fwupd-refresh.service ● fwupd-refresh.service - Refresh
> fwupd metadata and update motd
>Loaded: loaded (/lib/systemd/system/fwupd-refresh.service; static; vendor
> preset: enabled)
>Active: failed (Result: exit-code) since Wed 2019-10-23 16:06:35 CEST; 2h
> 13min ago
>  Docs: man:fwupdmgr(1)
>   Process: 4608 ExecStart=/usr/bin/fwupdmgr refresh (code=exited,
> status=0/SUCCESS)
>   Process: 4624 ExecStart=/usr/bin/fwupdmgr get-updates --log 85-fwupd
> (code=exited, status=1/FAILURE)  Main PID: 4624 (code=exited,
> status=1/FAILURE)
> 
> oct 23 16:06:35 svrname systemd[1]: Starting Refresh fwupd metadata and
> update motd...
> oct 23 16:06:35 svrname fwupdmgr[4608]: Fetching metadata
> https://cdn.fwupd.org/downloads/firmware.xml.gz
> oct 23 16:06:35 svrname fwupdmgr[4608]: Fetching signature
> https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
> oct 23 16:06:35 svrname systemd[1]: fwupd-refresh.service: Main process
> exited, code=exited, status=1/FAILURE oct 23 16:06:35 svrname systemd[1]:
> fwupd-refresh.service: Failed with result 'exit-code'.
> oct 23 16:06:35 svrname systemd[1]: Failed to start Refresh fwupd metadata
> and update motd.
> 
> That's the service definition:
> $ systemctl cat fwupd-refresh.service
> # /lib/systemd/system/fwupd-refresh.service
> [Unit]
> Description=Refresh fwupd metadata and update motd
> Documentation=man:fwupdmgr(1)
> After=network.target network-online.target systemd-networkd.service
> NetworkManager.service connman.service
> 
> [Service]
> Type=oneshot
> RuntimeDirectory=motd.d
> CacheDirectory=fwupdmgr
> RuntimeDirectoryPreserve=yes
> StandardError=null
> ExecStart=/usr/bin/fwupdmgr refresh
> ExecStart=/usr/bin/fwupdmgr get-updates --log 85-fwupd DynamicUser=yes
> RestrictAddressFamilies=AF_NETLINK AF_UNIX AF_INET AF_INET6
> SystemCallFilter=~@mount ProtectKernelModules=yes
> ProtectControlGroups=yes RestrictRealtime=yes
> 
> And about the runtime directory:
> $ ls -ld /run/motd.d
> lrwxrwxrwx 1 root root 14 oct 23 16:06 /run/motd.d -> private/motd.d $ ls -ld
> /run/private/
> drwx-- 3 root root 60 oct 23 16:06 /run/private/ $ sudo ls -ld
> /run/private/motd.d drwxr-xr-x 2 62803 62803 40 oct 23 16:06
> /run/private/motd.d $ sudo ls -l /run/private/motd.d total 0
> 
> 
> Kind Regards,
> 
> Jean-Marc
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_BE:fr (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libarchive13   3.4.0-1
> ii  libc6  2.29-2
> ii  libefiboot137-2
> ii  libefivar1 37-2
> ii  libelf10.176-1.1
> ii  libfwupd2  1.3.2-2
> ii  libgcab-1.0-0  1.3-1
> ii  libglib2.0-0   2.62.1-1
> ii  libgnutls303.6.9-5
> ii  libgpg-error0  1.36-7
> ii  libgpgme11 1.13.1-1
> ii  libgudev-1.0-0 233-1
> ii  libgusb2   0.3.0-1
> ii  libjson-glib-1.0-0 1.4.4-2
> ii  libpolkit-gobject-1-0  0.105-26
> ii  libsmbios-c2   2.4.1-1
> ii  libsoup2.4-1   2.68.2-1
> ii  libsqlite3-0   3.30.1-1
> ii  libtss2-esys0  2.1.0-4+b1
> ii  libxmlb1   0.1.13-1
> ii  shared-mime-info   1.10-1
> 
> Versions of packages fwupd recommends:
> ii  bolt   0.8-4
> ii  fwupd-amd64-signed [fwupd-signed]  1.3.2+2
> ii  python33.7.5-1
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#942567: Info received (Bug#942567: fwupd: fails to update metadata)

[Mario.Limonciello]

I had a newer systemd on my system when I tested. It is specifically a bug in 
systemd leading to this behavior.

1.3.2-3 will work around it until newer systemd lands.

On Oct 19, 2019 09:15, Debian Bug Tracking System  wrote:

[EXTERNAL EMAIL]

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian EFI 

If you wish to submit further information on this problem, please
send it to 942...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
942567: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942567
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#942567: fwupd: fails to update metadata

[Mario.Limonciello]

Ah yes.  It's the same as I reported upstream to systemd.
https://github.com/systemd/systemd/issues/13688

I just uploaded fwupd 1.3.2-3.
* For now the motd part of the unit is disabled unless on systemd 243+

From: Ritesh Raj Sarraf  on behalf of Ritesh Raj Sarraf 

Sent: Friday, October 18, 2019 10:11
To: Limonciello, Mario; 942...@bugs.debian.org
Subject: Re: Bug#942567: fwupd: fails to update metadata

On Fri, 2019-10-18 at 13:57 +, mario.limoncie...@dell.com wrote:
> Could you please try to remove "StandardError=null" from the service
> and see if the errors are clearer on the failure?

Here you go:

Oct 18 20:35:32 priyasi systemd[1]: Starting Refresh fwupd metadata and update 
motd...
Oct 18 20:35:32 priyasi fwupdmgr[31117]: Fetching metadata 
https://cdn.fwupd.org/downloads/firmware.xml.gz
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:32 priyasi fwupdmgr[31117]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31117]: Fetching signature 
https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
Oct 18 20:35:33 priyasi fwupdmgr[31133]: _g_io_module_get_default: Found 
default implementation local (GLocalVfs) for ‘gio-vfs’
Oct 18 20:35:33 priyasi fwupdmgr[31133]: Error opening file 
“/run/motd.d/85-fwupd”: Permission denied
Oct 18 20:35:33 priyasi systemd[1]: fwupd-refresh.service: Main process exited, 
code=exited, status=1/FAILURE
Oct 18 20:35:33 priyasi systemd[1]: fwupd-refresh.service: Failed with result 
'exit-code'.
Oct 18 20:35:33 priyasi systemd[1]: Failed to start Refresh fwupd metadata and 
update motd.
Oct 18 20:35:33 priyasi systemd[1]: Starting Refresh fwupd metadata and update 
motd...
Oct 18 20:35:33 priyasi fwupdmgr[31138]: Fetching metadata 
https://cdn.fwupd.org/downloads/firmware.xml.gz
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: unable to create directory 
'/.cache/dconf': Permission denied.  dconf will not work properly.
Oct 18 20:35:33 priyasi fwupdmgr[31138]: Fetching signature 
https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
Oct 18 20:35:34 priyasi fwupdmgr[31160]: _g_io_module_get_default: Found 
default implementation local (GLocalVfs) for ‘gio-vfs’
Oct 18 20:35:34 priyasi fwupdmgr[31160]: Error opening file 
“/run/motd.d/85-fwupd”: Permission denied
Oct 18 20:35:34 priyasi systemd[1]: fwupd-refresh.service: Main process exited, 
code=exited, status=1/FAILURE
Oct 18 20:35:34 priyasi systemd[1]: fwupd-refresh.service: Failed with result 
'exit-code'.
Oct 18 20:35:34 priyasi systemd[1]: 

Bug#942568: [fwupd] busy spinning in fu_util_prompt_for_boolean

[Mario.Limonciello]

Thanks for submitting.  I guess you don't have LVFS remote enabled for your 
setup and it's hanging trying to enable it.  I've filed this upstream to try to 
fix it: https://github.com/fwupd/fwupd/pull/1484

Sent from Workspace ONE Boxer

On Oct 18, 2019 03:30, Giovanni Mascellani  wrote:
Package: fwupd
Version: 1.3.2-2
Severity: normal

Hi,

approximately a few times a day fwupd is automatically called as "fwupd
refresh". Unfortunately on my system it gets stuck in a busy loop trying
to read from a stream. I believe that it fails to read, but it also
fails to acknowledge an error condition, therefore keeping trying.

Here is the gdb session:

> (gdb) attach 6735
> Attaching to process 6735
> [New LWP 6736]
> [New LWP 6737]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 0x7fc5d7e115ce in _IO_fgets (buf=buf@entry=0x7fff674457b4 "", 
> n=n@entry=4, fp=0x7fc5d7f58a00 <_IO_2_1_stdin_>) at iofgets.c:39
> 39iofgets.c: File o directory non esistente.
> (gdb) info threads
>   Id   Target Id   Frame
> * 1Thread 0x7fc5d530b8c0 (LWP 6735) "fwupdmgr" 0x7fc5d7e115ce in 
> _IO_fgets (buf=buf@entry=0x7fff674457b4 "", n=n@entry=4, fp=0x7fc5d7f58a00 
> <_IO_2_1_stdin_>) at iofgets.c:39
>   2Thread 0x7fc5d5023700 (LWP 6736) "gmain"0x7fc5d7e8ed2f in 
> __GI___poll (fds=0x556a5107a1b0, nfds=1, timeout=-1) at 
> ../sysdeps/unix/sysv/linux/poll.c:29
>   3Thread 0x7fc5d4822700 (LWP 6737) "gdbus"0x7fc5d7e8ed2f in 
> __GI___poll (fds=0x556a510988a0, nfds=2, timeout=-1) at 
> ../sysdeps/unix/sysv/linux/poll.c:29
> (gdb) bt
> #0  0x7fc5d7e115ce in _IO_fgets (buf=buf@entry=0x7fff674457b4 "", 
> n=n@entry=4, fp=0x7fc5d7f58a00 <_IO_2_1_stdin_>) at iofgets.c:39
> #1  0x556a4f0d58e4 in fgets (__stream=, __n=4, 
> __s=0x7fff674457b4 "") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:265
> #2  fu_util_prompt_for_boolean (def=1) at ../src/fu-util-common.c:126
> #3  0x556a4f0d4327 in fu_util_download_metadata_enable_lvfs 
> (error=0x7fff67445870, priv=0x556a51073a90) at ../src/fu-util.c:1203
> #4  fu_util_download_metadata (priv=0x556a51073a90, error=0x7fff67445870) at 
> ../src/fu-util.c:1234
> #5  0x556a4f0d079f in main (argc=, argv=) 
> at ../src/fu-util.c:2478
> (gdb) continue
> Continuing.
> ^C
> Thread 1 "fwupdmgr" received signal SIGINT, Interrupt.
> __GI___uflow (fp=0x7fc5d7f58a00 <_IO_2_1_stdin_>) at genops.c:298
> 298   genops.c: File o directory non esistente.
> (gdb) bt
> #0  __GI___uflow (fp=0x7fc5d7f58a00 <_IO_2_1_stdin_>) at genops.c:298
> #1  0x7fc5d7e125bc in __GI__IO_getline_info (fp=fp@entry=0x7fc5d7f58a00 
> <_IO_2_1_stdin_>, buf=buf@entry=0x7fff674457b4 "", n=n@entry=3, 
> delim=delim@entry=10, extract_delim=extract_delim@entry=1, eof=eof@entry=0x0) 
> at iogetline.c:60
> #2  0x7fc5d7e126b8 in __GI__IO_getline (fp=fp@entry=0x7fc5d7f58a00 
> <_IO_2_1_stdin_>, buf=buf@entry=0x7fff674457b4 "", n=n@entry=3, 
> delim=delim@entry=10, extract_delim=extract_delim@entry=1) at iogetline.c:34
> #3  0x7fc5d7e1166d in _IO_fgets (buf=buf@entry=0x7fff674457b4 "", 
> n=n@entry=4, fp=0x7fc5d7f58a00 <_IO_2_1_stdin_>) at iofgets.c:53
> #4  0x556a4f0d58e4 in fgets (__stream=, __n=4, 
> __s=0x7fff674457b4 "") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:265
> #5  fu_util_prompt_for_boolean (def=1) at ../src/fu-util-common.c:126
> #6  0x556a4f0d4327 in fu_util_download_metadata_enable_lvfs 
> (error=0x7fff67445870, priv=0x556a51073a90) at ../src/fu-util.c:1203
> #7  fu_util_download_metadata (priv=0x556a51073a90, error=0x7fff67445870) at 
> ../src/fu-util.c:1234
> #8  0x556a4f0d079f in main (argc=, argv=) 
> at ../src/fu-util.c:2478

The only way I can get rid of it is by killing it with SIGKILL.

Please, let me know how I can provide more useful information.

Thanks, Giovanni.


--- System information. ---
Architecture: Kernel:   Linux 5.2.0-3-amd64

Debian Release: bullseye/sid
  500 xenial  updates.signal.org   500 unstable-debug
debug.mirrors.debian.org   500 unstabledeb.debian.org   500
testing deb.debian.org   500 stable  repo.skype.com
500 stable  dl.google.com 1 experimentaldeb.debian.org
--- Package information. ---
Depends  (Version) | Installed
==-+-=
libarchive13(>= 3.0.4) | 3.4.0-1
libc6(>= 2.17) | libefiboot1
(>= 37) | libefivar1 (>= 37) | libelf1
   (>= 0.142) | libfwupd2   (>= 1.3.2) |
libgcab-1.0-0 (>= 1.0) | libglib2.0-0   (>=
2.53.2) | libgnutls30 (>= 3.6.5) | libgpg-error0
(>= 1.14) | libgpgme11  (>= 1.2.0) |
libgudev-1.0-0(>= 212) | libgusb2   (>=
0.2.10) | libjson-glib-1.0-0  (>= 1.2.0) | libpolkit-gobject-1-0
   (>= 0.99) 

Bug#942567: fwupd: fails to update metadata

[Mario.Limonciello]

Could you please try to remove "StandardError=null" from the service and see if 
the errors are clearer on the failure?

Sent from Workspace ONE Boxer

On Oct 18, 2019 03:37, Ritesh Raj Sarraf  wrote:

[EXTERNAL EMAIL]

Package: fwupd
Version: 1.3.2-2
Severity: important

So what is happening now, with the new fwupd-refresh service is:


$ systemctl status fwupd-refresh.service
● fwupd-refresh.service - Refresh fwupd metadata and update motd
   Loaded: loaded (/etc/systemd/system/fwupd-refresh.service; static; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2019-10-18 13:48:28 IST; 1min 
16s ago
 Docs: man:fwupdmgr(1)
  Process: 8815 ExecStart=/usr/bin/fwupdmgr refresh (code=exited, 
status=0/SUCCESS)
  Process: 8832 ExecStart=/usr/bin/fwupdmgr get-updates --verbose --log 
85-fwupd (code=exited, status=1/FAILURE)
 Main PID: 8832 (code=exited, status=1/FAILURE)

Oct 18 13:48:27 priyasi systemd[1]: Starting Refresh fwupd metadata and update 
motd...
Oct 18 13:48:27 priyasi fwupdmgr[8815]: Fetching metadata 
https://cdn.fwupd.org/downloads/firmware.xml.gz
Oct 18 13:48:28 priyasi fwupdmgr[8815]: Fetching signature 
https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
Oct 18 13:48:28 priyasi fwupdmgr[8832]: (fwupdmgr:8832): GLib-GIO-DEBUG: 
13:48:28.310: _g_io_module_get_default: Found default implementation loc>
Oct 18 13:48:28 priyasi systemd[1]: fwupd-refresh.service: Main process exited, 
code=exited, status=1/FAILURE
Oct 18 13:48:28 priyasi systemd[1]: fwupd-refresh.service: Failed with result 
'exit-code'.
Oct 18 13:48:28 priyasi systemd[1]: Failed to start Refresh fwupd metadata and 
update motd.


If I run the same command from the console as user root, it works proper
If I drop the --log option, then it passes


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwupd depends on:
ii  libarchive13   3.4.0-1
ii  libc6  2.29-2
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.2-2
ii  libgcab-1.0-0  1.3-1
ii  libglib2.0-0   2.62.1-1
ii  libgnutls303.6.9-5
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.68.2-1
ii  libsqlite3-0   3.30.1-1
ii  libtss2-esys0  2.1.0-4+b1
ii  libxmlb1   0.1.8-1+b1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
ii  bolt   0.8-4
ii  fwupd-amd64-signed [fwupd-signed]  1.3.2+2
ii  python33.7.5-1

fwupd suggests no packages.

-- no debconf information

Bug#941661: daemon fails to start

[Mario.Limonciello]

This is a duplicate of 941360, which is fixed in git but waiting for review on 
some other important changes before upload:
https://salsa.debian.org/efi-team/fwupd/commit/04cb53bdce9037c4af09b70486efd26eb89686e0

> -Original Message-
> From: Laurent Bigonville 
> Sent: Thursday, October 3, 2019 8:29 AM
> To: Debian Bug Tracking System
> Subject: Bug#941661: daemon fails to start
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.3.2-1
> Severity: serious
> 
> Hi,
> 
> It seems that the fwupd daemon fails to start:
> 
> oct 03 15:23:38 edoras systemd[1]: Starting Firmware update daemon...
> oct 03 15:23:38 edoras systemd[3854]: fwupd.service: Failed to set up special
> execution directory in /var/cache: Not a directory
> oct 03 15:23:38 edoras systemd[3854]: fwupd.service: Failed at step
> CACHE_DIRECTORY spawning /usr/lib/fwupd/fwupd: Not a directory
> oct 03 15:23:38 edoras systemd[1]: fwupd.service: Main process exited,
> code=exited, status=239/CACHE_DIRECTORY
> oct 03 15:23:38 edoras systemd[1]: fwupd.service: Failed with result 
> 'exit-code'.
> oct 03 15:23:38 edoras systemd[1]: Failed to start Firmware update daemon.
> 
> 
> Looking at /var/cache, I see:
> 
> ls -la /var/cache/fwupd/
> [...]
> lrwxr-xr-x.  1 root  root13 sep 28 22:49 fwupd -> 
> private/fwupd
> [...]
> 
> /var/cache/private/fwupd also exists
> 
> Kind regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'),
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_BE:fr (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
> 
> Versions of packages fwupd depends on:
> ii  libarchive13   3.4.0-1
> ii  libc6  2.29-2
> ii  libefiboot137-2
> ii  libefivar1 37-2
> ii  libelf10.176-1.1
> ii  libfwupd2  1.3.2-1
> ii  libgcab-1.0-0  1.2-5
> ii  libglib2.0-0   2.62.0-3
> ii  libgnutls303.6.9-5
> ii  libgpg-error0  1.36-7
> ii  libgpgme11 1.13.1-1
> ii  libgudev-1.0-0 233-1
> ii  libgusb2   0.3.0-1
> ii  libjson-glib-1.0-0 1.4.4-2
> ii  libpolkit-gobject-1-0  0.105-26
> ii  libsmbios-c2   2.4.1-1
> ii  libsoup2.4-1   2.68.1-2
> ii  libsqlite3-0   3.29.0-2
> ii  libtss2-esys0  2.1.0-4+b1
> ii  libxmlb1   0.1.8-1+b1
> ii  shared-mime-info   1.10-1
> 
> Versions of packages fwupd recommends:
> ii  bolt   0.8-4
> ii  fwupd-amd64-signed [fwupd-signed]  1.3.2+1
> ii  python33.7.5-1
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#941360: fwupd: Failed to activate service: timed out

[Mario.Limonciello]

Here is a fix for it. I believe it's because of a clash with fwupd-refresh and 
fwupd specifically in systemd 242 and newer.

https://github.com/fwupd/fwupd/commit/dc7e7c3808d564d5769b2845dbd66a3651f72e07

On Sep 30, 2019 10:37, Francois Marier  wrote:

[EXTERNAL EMAIL]

On 2019-09-29 at 23:57:02, mario.limoncie...@dell.com wrote:
> What version did you upgrade from? And was that directory already existing or 
> did it get created with the package?

I'm also affected by this problem. In my case, I also purged the package and
reinstalled it. The problem persists and the cache symlink looks like this:

$ ls -l /var/cache/fwupd
lrwxr-xr-x 1 root root 13 sep 28 20:48 /var/cache/fwupd -> private/fwupd

Francois

--
https://fmarier.org/

Bug#941360: fwupd: Failed to activate service: timed out

[Mario.Limonciello]

What version did you upgrade from? And was that directory already existing or 
did it get created with the package?

On Sep 29, 2019 08:21, definetti  wrote:

[EXTERNAL EMAIL]

Package: fwupd
Version: 1.3.2-1
Severity: important

Dear Maintainer,

after updating to 1.3.2-1 the fwupd service fails to run. I think this depends
on the permissions on the /var/cache/fwupd folder, which is a link to
/var/cache/private/fwupd.


● fwupd.service - Firmware update daemon
   Loaded: loaded (/lib/systemd/system/fwupd.service; static; vendor preset:
enabled)
   Active: failed (Result: exit-code) since Sun 2019-09-29 15:15:51 CEST; 24s
ago
 Docs: https://fwupd.org/
  Process: 16141 ExecStart=/usr/lib/fwupd/fwupd (code=exited,
status=239/CACHE_DIRECTORY)
 Main PID: 16141 (code=exited, status=239/CACHE_DIRECTORY)

running fwupd with superuser permissions results in no error



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwupd depends on:
ii  libarchive13   3.4.0-1
ii  libc6  2.29-2
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.2-1
ii  libgcab-1.0-0  1.2-5
ii  libglib2.0-0   2.61.2-2
ii  libgnutls303.6.9-5
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.68.1-2
ii  libsqlite3-0   3.29.0-2
ii  libtss2-esys0  2.1.0-4+b1
ii  libxmlb1   0.1.8-1+b1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
ii  bolt  0.8-4
pn  fwupd-signed  
ii  python3   3.7.3-1

fwupd suggests no packages.

-- no debconf information

Bug#941048: fwupd: provide option to never send report

[Mario.Limonciello]

> -Original Message-
> From: brian m. carlson 
> Sent: Tuesday, September 24, 2019 5:38 PM
> To: Limonciello, Mario
> Cc: 941...@bugs.debian.org
> Subject: Re: Bug#941048: fwupd: provide option to never send report
> 
> On 2019-09-24 at 02:22:44, mario.limoncie...@dell.com wrote:
> > Oh it looks like that just stops it from actually going out.  To
> > prevent the prompt you'll need to launch fwupdmgr with
> > --no-unreported-check.
> 
> Yes, I appreciate that the command-line option is there.  However, the
> idea is not to need this option every time and to disable the feature
> globally, which is why I opened this bug report.
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

OK, 1.3.2 release of fwupd will have this:
https://github.com/fwupd/fwupd/commit/f1accad201b24565f3e19daa09d26b477c3f4b9c

Bug#941048: fwupd: provide option to never send report

[Mario.Limonciello]

Oh it looks like that just stops it from actually going out.  To prevent the 
prompt you'll need to launch fwupdmgr with --no-unreported-check.

https://github.com/fwupd/fwupd/blob/ce94d163f8d7bef4748a75def1ace0326083eea5/src/fu-util.c#L2092

> -Original Message-
> From: brian m. carlson 
> Sent: Monday, September 23, 2019 9:06 PM
> To: Limonciello, Mario
> Cc: 941...@bugs.debian.org
> Subject: Re: Bug#941048: fwupd: provide option to never send report
> 
> On 2019-09-24 at 01:00:01, mario.limoncie...@dell.com wrote:
> > To accomplish this, I believe you can just comment out ReportURI= in
> > the LVFS remote and restart the daemon. (IE
> > /etc/fwupd/remotes.d/lvfs.conf)
> 
> That doesn't seem to be effective.  Running "fwupdmgr get-updates"
> still prompts, even after restarting the daemon.
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

Bug#941048: fwupd: provide option to never send report

[Mario.Limonciello]

To accomplish this, I believe you can just comment out ReportURI= in the LVFS 
remote and restart the daemon. (IE /etc/fwupd/remotes.d/lvfs.conf)

> -Original Message-
> From: brian m. carlson 
> Sent: Monday, September 23, 2019 7:02 PM
> To: Debian Bug Tracking System
> Subject: Bug#941048: fwupd: provide option to never send report
> 
> Package: fwupd
> Version: 1.2.10-2
> Severity: wishlist
> 
> There are a wide variety of situations where a user may never want to send a
> report about successful firmware update.  For example, I've worked at a
> nonprofit dealing with mental health where sending reports to the vendor was
> forbidden as a blanket policy because they might contain sensitive client 
> data.
> Other people are concerned about privacy, and yet others may be on a metered
> or slow connection and wish not to send unneeded data.
> 
> Currently, every time "fwupd get-updates" runs, it prompts to send a report
> about the last update.  This is bothersome for users who never wish to send an
> update.  It would be beneficial if fwupd learned a configuration option to 
> never
> send an update for any reason and to avoid prompting to do so.
> 
> If a configuration option already exists to do this, consider this a request 
> to
> document the behavior or refer to a manual page for the configuration file in
> the fwupdmgr(1) manual page so it can be easily discovered.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.3.0-rc5-amd64 (SMP w/8 CPU cores) Kernel taint flags:
> TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libarchive13   3.4.0-1
> ii  libc6  2.29-2
> ii  libefiboot137-2
> ii  libefivar1 37-2
> ii  libelf10.176-1.1
> ii  libfwupd2  1.2.10-2
> ii  libgcab-1.0-0  1.2-5
> ii  libglib2.0-0   2.60.6-2
> ii  libgnutls303.6.9-5
> ii  libgpg-error0  1.36-7
> ii  libgpgme11 1.13.1-1
> ii  libgudev-1.0-0 233-1
> ii  libgusb2   0.3.0-1
> ii  libjson-glib-1.0-0 1.4.4-2
> ii  libpolkit-gobject-1-0  0.105-26
> ii  libsmbios-c2   2.4.1-1
> ii  libsoup2.4-1   2.64.2-2
> ii  libsqlite3-0   3.29.0-2
> ii  libxmlb1   0.1.8-1+b1
> ii  shared-mime-info   1.10-1
> 
> Versions of packages fwupd recommends:
> ii  bolt   0.8-4
> ii  fwupd-amd64-signed [fwupd-signed]  1.2.10+2
> ii  python33.7.3-1
> ii  tpm2-abrmd 2.1.1-1+b1
> ii  tpm2-tools 3.1.3-2+b1
> 
> fwupd suggests no packages.
> 
> -- no debconf information
> 
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

Bug#939604: /var/lib/fwupdate/done not removed on uninstall

[Mario.Limonciello]

Yeah I  think that shouldn't be a problem to cleanup, especially given it's a 
transition package.

Overall did everything else go smoothly?

> -Original Message-
> From: dann frazier 
> Sent: Friday, September 6, 2019 2:07 PM
> To: Debian Bug Tracking System
> Subject: Bug#939604: /var/lib/fwupdate/done not removed on uninstall
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupdate
> Version: 12-6
> Severity: normal
> 
> During the apt upgrade transitioning me to fwupd, I noticed:
> 
> Unpacking fwupdate (12-6) over (12-5) ...
> dpkg: warning: unable to delete old directory '/var/lib/fwupdate': Directory 
> not
> empty
> 
> Under that directory is a 0-length file called "done". Can that be removed
> during postrm?
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'),
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupdate depends on:
> ii  fwupd  1.2.10-2
> 
> fwupdate recommends no packages.
> 
> fwupdate suggests no packages.
> 
> -- no debconf information

Bug#918973:

[Mario.Limonciello]

With Buster out now, can this effort be resumed?

Bug#912414: Workaround failed

[Mario.Limonciello]

The issue reported here is different than the CNAME issue.

Basically LVFS has gotten a lot bigger and the fwupd 0.7.x release couldn't 
handle the size of the metadata now.
Please reference this bug in Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1829813

This workaround can be backported for it: 
https://github.com/hughsie/fwupd/commit/a1e6e7ff254f3409e0bced0fb400073d6e2b96e8

> -Original Message-
> From: Xavier Bestel 
> Sent: Monday, July 29, 2019 5:09 AM
> To: 912...@bugs.debian.org
> Subject: Bug#912414: Workaround failed
> 
> 
> [EXTERNAL EMAIL]
> 
> FWIW, even changing the configuration file as described fails:
> 
> root@gitlab:~# fwupdmgr --verbose refresh
> failed to update metadata: Failed to parse XML: Mismatched XML

Bug#932757: fwupd: should include Built-Using fields in the signed packages

[Mario.Limonciello]

Dell Customer Communication - Confidential

Sure.  Will be part of next fwupd release.

https://github.com/hughsie/fwupd/commit/09700bbce8b2016056079cf73b0408e9afbc5301


> -Original Message-
> From: Adam D. Barratt 
> Sent: Monday, July 22, 2019 2:05 PM
> To: sub...@bugs.debian.org
> Subject: Bug#932757: fwupd: should include Built-Using fields in the signed
> packages
> 
> 
> [EXTERNAL EMAIL]
> 
> Source: fwupd
> Version: 1.2.5-2
> 
> Hi,
> 
> As discussed with Steve at Debconf, the fwupd-*-signed binary packages
> are missing Built-Using fields pointing back to the unsigned source
> package. Please add them. :-)
> 
> Regards,
> 
> Adam

Bug#931794:

[Mario.Limonciello]

Now that buster is out, I've just uploaded the latest released 1.2.9 to 
unstable.
Dell Corporation Limited is registered in England and Wales. Company 
Registration Number: 2081369
Registered address: Dell House, The Boulevard, Cain Road, Bracknell,  
Berkshire, RG12 1LF, UK.
Company details for other Dell UK entities can be found on  www.dell.co.uk.

Bug#921820: fwupd: provide a network service file

[Mario.Limonciello]

I think for some people downloading metadata automatically in a timer/cron type 
way, may be useful but I think it's missing the last piece of integration to 
notify folks; motd messaging to let people know updates are available.

Would you please consider bringing this discussion upstream?  I think this even 
makes sense outside of Debian and would like to see it implemented in a future 
fwupd release directly.

> -Original Message-
> From: Ritesh Raj Sarraf  On Behalf Of Ritesh Raj Sarraf
> Sent: Thursday, July 11, 2019 6:53 AM
> To: Debian Bug Tracking System
> Subject: Bug#921820: fwupd: provide a network service file
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.2.5-2
> Followup-For: Bug #921820
> 
> Hello Mario,
> 
> You also need to acknowledge the fact that there are many more users beyond
> the GNOME desktop. And then there's also the minimal, server and remote
> users. fwupd can work perfectly for those use cases.
> 
> Attached is a .service and a .timer file for this use case.
> 
> Please consider integrating them into the package.
> 
> And below is the results:
> 
> 
> Jul 11 19:10:05 priyasi systemd[1]: Starting Daily fwupd download 
> activities...
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: XPS 13 9370 System Firmware has
> firmware updates:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: GUID:
> 7ceaf7a8-0611-4480-
> 9e30-64d8de420c7c
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: ID:
> com.dell.uefi7ceaf7a8.firmware
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Version:  0.1.10.0
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Name: XPS 13 9370
> System Update
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Summary:  Firmware for
> the Dell XPS 13 9370
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Remote ID:lvfs
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Checksum:
> SHA1(ffeea823f8af0e10084c8db90bfd066ff80c4580)
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Location:
> https://fwupd.org/downloads/19395e228ff2e832797d74a5a9afaf6574f21ca7-
> XPS_9370_1.10.0.cab
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Description:  This stable
> release fixes the following issues:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: ID:
> com.dell.uefi7ceaf7a8.firmware
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Version:  0.1.9.0
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Name: XPS 13 9370
> System Update
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Summary:  Firmware for
> the Dell XPS 13 9370
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Remote ID:lvfs
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Checksum:
> SHA1(754e29b7c26299d10aa1069cc42e9d65cc318876)
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Location:
> https://fwupd.org/downloads/694da421c22f0f6457a820ce0f77ce29465de32f-
> XPS_9370_1.9.0.cab
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Description:  This stable
> release fixes the following issues:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:   • Firmware 
> updates to
> address security advisories INTEL-SA-00191(CVE-2018-12201, CVE-2018- 12202,
> CVE-2018-12203).
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:   • Fixed an 
> issue with
> Secure Boot Option ROM Signature Verification.
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:   • Not 
> Applicable.
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: ID:
> com.dell.uefi7ceaf7a8.firmware
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Version:  0.1.8.1
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Name: XPS 13 9370
> System Update
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Summary:  Firmware for
> the Dell XPS 13 9370
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Remote ID:lvfs
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Checksum:
> SHA1(d0fb3e0b49f70fb4bc07790a70073306fa356fa3)
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Location:
> https://fwupd.org/downloads/3730feea49972ec78c61a8776dd518f2ffa98403-
> Signed_1152921504627936323.cab
> Jul 11 19:10:05 priyasi fwupdmgr[28271]: Update Description:  This stable
> release fixes the following issues:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:  system is 
> started with
> Dell Thunderbolt Dock TB16 connected to it
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:   • This 
> update integrates
> the BIOSConnect feature into Dell SupportAssist OS Recovery. This feature
> connects 　the system to the Dell image server to download and recover the
> operating system
> Jul 11 19:10:05 priyasi fwupdmgr[28271]:
> Jul 11 19:10:05 

Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt

[Mario.Limonciello]

Would you be able to check if this also affects fwupd?  The fwupdate binary was 
also merged into that project a while back and I would suspect it's affecting 
both.

-Original Message-
From: Ard Biesheuvel  
Sent: Sunday, April 7, 2019 10:46 PM
To: Debian Bug Tracking System
Subject: Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt


[EXTERNAL EMAIL] 

Package: fwupdate
Version: 12-4
Severity: important

Dear Maintainer,

Version 12-4 of fwupdate is broken for arm64. The included binary fwupaa64.efi 
is corrupt, resulting in EFI_LOAD_ERROR to be returned by the firmware when 
trying to invoke it.

The binary layout looks like this:

Detected 'AArch64' type PE/COFF image consisting of 2 sections Section 
alignment: 0x1000 File alignment: 0x200 Image size: 0xd890 Section '.text' @ 
0x1000 File offset: 0x1000 Virtual size: 0xac20 Raw size: 0xac20 Section 
'.data' @ 0xbc20 File offset: 0xbc20 Virtual size: 0x1d70 Raw size: 0x1d70

Note that file offset + size of section #2 exceeds the total image size. But 
the file offset of that section is not even a multiple of the file alignment, 
so the whole image seems pretty broken.



-- System Information:
Debian Release: 9.8
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.1.0-rc2+ (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fwupdate depends on:
ii  e2fsprogs1.43.4-2
ii  efibootmgr   14-2
ii  libc62.28-8
ii  libefiboot1  37-2
ii  libefivar1   37-2
ii  libfwup1 12-4
ii  libpopt0 1.16-10+b2

Versions of packages fwupdate recommends:
ii  fwupdate-arm64-signed [fwupdate-signed]  12+4

fwupdate suggests no packages.

-- no debconf information

Bug#922770: lvfs: GRUB disappeared after Thinkpad T480s firmware update

[Mario.Limonciello]

> -Original Message-
> From: Steve McIntyre 
> Sent: Wednesday, February 20, 2019 7:29 AM
> To: Alejandro Sanchez; 922...@bugs.debian.org
> Subject: Bug#922770: lvfs: GRUB disappeared after Thinkpad T480s firmware
> update
> 
> 
> [EXTERNAL EMAIL]
> 
> Control: severity -1 normal
> 
> On Wed, Feb 20, 2019 at 02:16:20PM +0100, Alejandro Sanchez wrote:
> >Package: fwupd
> >Version: 1.1.4-1
> >Severity: critical
> >File: lvfs
> >Justification: breaks the whole system
> >
> >Dear Maintainer,
> >
> >The Software Update manager popped up a message for a Thinkpad T480s
> firmware
> >update. I proceeded with the Install & Reboot, and after the update finished
> >and laptop restarted, GRUB completely disappeared. Then I had to follow the
> >instructions in the following page to reinstall grub:
> >
> >https://wiki.debian.org/GrubEFIReinstall
> >
> >I can't find any references to 'fw' and/or 'lvfs' in either:
> >
> >/var/log/apt/history.log
> >
> >or
> >
> >/var/log/apt/term.log
> >
> >but I believe that the Firmware update was this one:
> >
> >https://fwupd.org/lvfs/device/ebfe8df8-dee7-4692-a721-cbcf5095c5cf
> >
> >Lenovo ThinkPad T480s System Firmware Version 1.29.
> 
> This isn't a bug in fwupd, it's a problem with the Lenovo firmware
> throwing away boot entries on upgrade. There's very little we can do
> about that. :-/
> 

Completely agree, nothing that fwupd has done here directly.
It's all the Lenovo firmware messing up.

Can you please report this to the upstream LVFS tracker?
https://github.com/hughsie/lvfs-website

Then that can be forwarded to the appropriate folks at Lenovo and this firmware
pulled from LVFS until this is fixed.

Bug#922331: Info received (Bug#922331: Info received (Bug#922331: fwupd: autopkgtest regression: Error calling StartServiceByName for org.freedesktop.fwupd: Timeout was reached))

[Mario.Limonciello]

I've made some headway in figuring out whats going on.

I've compared the qemu and lxc backends for autopkgtest and found two very 
notable differences.

1) The qemu one installs shared-mime-info.  lxc doesn't.
2) Apparmor rules in lxc lead to namespace failures.

Here's how I compared the two.

Launching qemu like this:
#autopkgtest --apt-upgrade --add-apt-release=unstable 
--pin-packages=unstable=src:fwupd,src:libxmlb fwupd -- qemu 
autopkgtest-testing.img

Launching lxc like this
# autopkgtest  --apt-upgrade --add-apt-release=unstable 
--pin-packages=unstable=src:fwupd,src:libxmlb fwupd -- lxc autopkgtest-testing

shared-mime-info
--
shared-mime-info gets install in qemu but not in lxc.  In lxc, fwupd daemon 
fails with this error:
Failed to load engine: Failed to load config: cannot process file of type 
application/x-zerosize

namespace failures
--
In LXC the host shows this in dmesg when trying to start the daemon:
[ 3760.599980] audit: type=1400 audit(1550199530.985:19): apparmor="DENIED" 
operation="mount" info="failed flags match" error=-13 
profile="lxc-container-default-cgns" name="/" pid=13833 comm="(fwupd)" 
flags="rw, rslave"

Checking the systemd unit journal this is shown:

● fwupd.service - Firmware update daemon
   Loaded: loaded (/lib/systemd/system/fwupd.service; static; vendor preset: 
enabled)
   Active: failed (Result: exit-code) since Fri 2019-02-15 02:52:33 UTC; 8s ago
 Docs: https://fwupd.org/
  Process: 3945 ExecStart=/usr/lib/fwupd/fwupd (code=exited, 
status=226/NAMESPACE)
 Main PID: 3945 (code=exited, status=226/NAMESPACE)

Feb 15 02:52:33 autopkgtest-testing systemd[1]: Starting Firmware update 
daemon...
Feb 15 02:52:33 autopkgtest-testing systemd[3945]: fwupd.service: Failed to set 
up mount namespacing: Permission denied
Feb 15 02:52:33 autopkgtest-testing systemd[3945]: fwupd.service: Failed at 
step NAMESPACE spawning /usr/lib/fwupd/fwupd: Permission denied
Feb 15 02:52:33 autopkgtest-testing systemd[1]: fwupd.service: Main process 
exited, code=exited, status=226/NAMESPACE
Feb 15 02:52:33 autopkgtest-testing systemd[1]: fwupd.service: Failed with 
result 'exit-code'.
Feb 15 02:52:33 autopkgtest-testing systemd[1]: Failed to start Firmware update 
daemon.

Looking around this points at the following apparmor issue potentially.
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1811248

Bug#922331: Info received (Bug#922331: fwupd: autopkgtest regression: Error calling StartServiceByName for org.freedesktop.fwupd: Timeout was reached)

[Mario.Limonciello]

After hacking around bug 916493 I did manage to run autopkgtest locally with a 
qemu backends and it runs just fine.
autopkgtest fwupd -- qemu ./qemu-unstable.img

So what's different with LXC and QEMU backends?

> -Original Message-
> From: Debian Bug Tracking System 
> Sent: Thursday, February 14, 2019 4:27 PM
> To: Limonciello, Mario
> Subject: Bug#922331: Info received (Bug#922331: fwupd: autopkgtest regression:
> Error calling StartServiceByName for org.freedesktop.fwupd: Timeout was 
> reached)
> 
> 
> [EXTERNAL EMAIL]
> 
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian EFI 
> 
> If you wish to submit further information on this problem, please
> send it to 922...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 922331: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922331
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#922331: fwupd: autopkgtest regression: Error calling StartServiceByName for org.freedesktop.fwupd: Timeout was reached

[Mario.Limonciello]

I'm aware of this failure, but rather confused on how to debug it.

I just set up a buster machine and installed fwupd from unstable (using pinning)
but fwupd runtime tests work just fine (and talking to real hardware does too)

> -Original Message-
> From: Paul Gevers 
> Sent: Thursday, February 14, 2019 11:23 AM
> To: sub...@bugs.debian.org
> Subject: Bug#922331: fwupd: autopkgtest regression: Error calling
> StartServiceByName for org.freedesktop.fwupd: Timeout was reached
> 
> Source: fwupd
> Version: 1.2.4-1
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainers,
> 
> With a recent upload of fwupd the autopkgtest of fwupd fails in testing
> when that autopkgtest is run with the binary packages of fwupd from
> unstable. It passes when run with only packages from testing. In tabular
> form:
>passfail
> fwupd  from testing1.2.4-1
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it? If needed, please
> change the bug's severity.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [0] You can see what packages were added from the second line of the log
> file quoted below. The migration software adds source package from
> unstable to the list if they are needed to install packages from
> fwupd/1.2.4-1. I.e. due to versioned dependencies or breaks/conflicts.
> [1] https://qa.debian.org/excuses.php?package=fwupd
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/f/fwupd/1929216/log.gz
> 
> autopkgtest [09:11:14]: test ci: [---
> Running test: fwupd/fwupdmgr.test
> Getting the list of remotes...
> Executing: fwupd/fwupdmgr.test
> Executing: fwupd/fwupdmgr.test
> Executing: fwupd/fwupdmgr.test
> Executing: fwupd/fwupdmgr.test
> Executing: fwupd/fwupdmgr.test
> Failed to connect to daemon: Error calling StartServiceByName for
> org.freedesktop.fwupd: Timeout was reached
> FAIL: fwupd/fwupdmgr.test (Child process exited with code 1)
> SUMMARY: total=1; passed=0; skipped=0; failed=1; user=0.0s; system=0.0s;
> maxrss=11700
> FAIL: fwupd/fwupdmgr.test (Child process exited with code 1)
> autopkgtest [09:11:39]: test ci: ---]

Bug#921820: fwupd: provide a network service file

[Mario.Limonciello]

Per design this functionality exists in the frontend that runs as reduced 
privilege user. For example gnome-software which runs in a users session and 
regularly checks for apt metadata also will automatically check for firmware 
updates too.

Bug#920777: Acknowledgement (ITP: libxmlb -- XML binary library)

[Mario.Limonciello]

Packaging moved to https://salsa.debian.org/efi-team/libxmlb/tree/debian


> -Original Message-
> From: Limonciello, Mario
> Sent: Monday, January 28, 2019 8:44 PM
> To: 920...@bugs.debian.org
> Subject: Bug#920777: Acknowledgement (ITP: libxmlb -- XML binary library)
> 
> 
> [EXTERNAL EMAIL]
> 
> Initial packaging available here: 
> https://github.com/superm1/libxmlb/tree/debian

Bug#920777: Acknowledgement (ITP: libxmlb -- XML binary library)

[Mario.Limonciello]

Initial packaging available here: https://github.com/superm1/libxmlb/tree/debian

Bug#920012: fwupd breaks xbox360 controller support

[Mario.Limonciello]

Moving to a newer release is problematic because newer releases need
libxmlb which isn't in Debian and doesn't yet have an ITP or team willing to 
adopt it yet even.

This commit has been backported to 1_1_X branch so when a 1.1.5 release is 
released it will be included.
Alternatively this commit can be cherry picked.
https://github.com/hughsie/fwupd/commit/76bdc8c3487f687009a51359d32a27a2a560d319

> -Original Message-
> From: Phil Armstrong 
> Sent: Monday, January 21, 2019 9:03 AM
> To: Debian Bug Tracking System
> Subject: Bug#920012: fwupd breaks xbox360 controller support
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.1.4-1
> Severity: normal
> 
> Dear Maintainer,
> 
> As outlined in https://github.com/hughsie/fwupd/pull/836 fwupd as
> currently in Debian testing breaks xbox 360 controller support.
> 
> Can we pull a more recent version of fwupd into buster?
> 
> cheers, Phil
> 
> -- System Information:
> Debian Release: buster/sid
>    APT prefers testing
>    APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libappstream-glib8 0.7.14-1
> ii  libarchive13   3.3.3-3
> ii  libc6  2.28-5
> ii  libefiboot1    37-1
> ii  libefivar1 37-1
> ii  libelf1    0.175-2
> ii  libfwupd2  1.1.4-1
> ii  libgcab-1.0-0  1.2-2
> ii  libglib2.0-0   2.58.2-3
> ii  libgnutls30    3.6.5-2
> ii  libgpg-error0  1.33-3
> ii  libgpgme11 1.12.0-4
> ii  libgudev-1.0-0 232-2
> ii  libgusb2   0.3.0-1
> ii  libjson-glib-1.0-0 1.4.4-2
> ii  libpolkit-gobject-1-0  0.105-25
> ii  libsmbios-c2   2.4.1-1
> ii  libsoup2.4-1   2.64.2-2
> ii  libsqlite3-0   3.26.0+fossilbc891ac6b-1
> ii  libuuid1   2.33.1-0.1
> 
> Versions of packages fwupd recommends:
> ii  bolt   0.7-2
> ii  fwupd-amd64-signed [fwupd-signed]  1.1.4+1
> ii  python3    3.7.1-3
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#916036: Install fwupd on a default installation

[Mario.Limonciello]

> Just the fact that the update claims that the hardware only accepts
> signed updates or something else? :)

At a minimum a claim.

> I will note - although slightly off-topic to the discussion at hand -
> that it would be useful to people to be able to run their own repository
> of updates and control the rollouts (and staging percentages)
> themselves. I'm not actually suggesting that Debian would need to run
> their own, but it'd be a useful service to the users who don't want to
> send telemetry to the Linux Foundation - and furthermore have a
> significant deployment where it's worth canarying the updates.

Entirely doable.  LVFS can be set up locally with the firmware that is 
interesting
uploaded to that "instance".  This will mean setting up a GPG key pair and 
signing
the firmware with that instance as well.

On fwupd clients a "remote" needs to be registered for that instance with the 
public
key and instance location.

FYI: Telemetry related to the update is entirely optional and "opt-in" after 
you've
performed an update.

> Fair enough. Do you have a pointer for examples of such updates?
> Unfortunately I updated my own Dell dock recently from Windows, so I
>can't easily check. Mostly I'm interested if it's a proprietary binary
>run on the host. That's its own can of worms. (Which technically is true
>for the EFI update too, but it's staged from outside of Linux on
>boot-up.)

Executing proprietary binaries distributed in the CAB file is against fwupd
philosophy and prohibited.  All code for the plugin that executes in Linux and
is distributed with fwupd must be open source.

fwupd only pulls "payloads" from the CAB files.

Regarding the examples I called out:
You can review the fwupd tree in the plugins/ directory to see the
* thunderbolt/ plugin which uses the kernel Thunderbolt interface
* dell-dock/ plugin which uses kernel USB interfaces
* dell/ plugin which uses a EFI binary for TPM and dock updates
* ebitdo/ plugin which uses kernel USB interfaces
* rts54hid/ rts54hub/ plugins which use kernel USB interfaces

There are many more, you can look more closely at your leisure.

The matching binaries that are on LVFS.
Here's some examples:
Thunderbolt: https://fwupd.org/lvfs/device/4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
MST: https://fwupd.org/lvfs/device/be025b25-ca5c-546c-97c6-ee2160ba489d
8bitdo: https://fwupd.org/lvfs/device/8baed357-638e-5b54-b582-0476bf7d6348
TPM: https://fwupd.org/lvfs/device/e58a5f6d-ba78-5f0f-a35f-612f97ca8c9a

Bug#916036: Install fwupd on a default installation

[Mario.Limonciello]

Something I think worth mentioning is that LVFS is being transitioned to being 
run
and managed by the Linux Foundation.

>Interestingly enough the vendor signs a blob (CAB file) and LVFS throws
> it away and re-signs the blob with its own key. But then again I think
> the base assumption is that the contained firmware images are themselves
> signed as well and the BIOS does a check before ingesting them.

Speaking on behalf of one of the biggest distributors of firmware on LVFS (Dell)
I can say that all of the firmware images are signed by Dell PKI infrastructure 
and
will not flash on the system if modified.

LVFS is currently in the process of plumbing this information through to the U/I
as well.

> Obviously you end up with the usual concerns like the repository being
> able to hold back updates from certain clients. The website's code is
> supposedly available on https://github.com/hughsie/lvfs-website/ though
> and I suppose a transparency effort could solve that particular problem,
> too.

LVFS is able to prevent distributing updates in two situations:

1) when there are known bad SW combinations (say vendor knew bug existed in 
fwupd
1.0.x but was fixed in 1.1.x - set minimum version for the update to be 1.1.x).
or need to update device XYZ before device ABC.

2) rate limiting of updates
To stage rollouts and monitor optional feedback in the event of a problem.

> Oh yes. Not just that, also finding the right image to apply and then
> figuring out how the hell to apply it is a solved problem with EFI-based
> fwupdate.

Please keep in mind it's much much more than EFI updates now too.  There are 
updates
that can apply "in Debian" without a reboot for things like Thunderbolt 
controllers, docks, 
MST hubs, and various USB devices.

Bug#911505: fwupd: Change package description to be more open ended

[Mario.Limonciello]

I've committed this upstream.
https://github.com/hughsie/fwupd/commit/2aaa38d77df06f10968bda089156a29446435141

It will be included the 1.2.0-1 release into Debian.

Bug#911023: memory leak in the backlight control of the dell-laptop module

[Mario.Limonciello]

We did fix a memory leak recently.

Please backport this and see it it helps

https://github.com/torvalds/linux/commit/affab51082174f60ef71ced8ab5fbe71f00e9ae3

On Oct 14, 2018 15:26, Pali Rohár  wrote:
Adding Mario to loop.

Memory leak can be also in ACPI/WMI or in the new dell-smbios.ko module.

On Sunday 14 October 2018 22:18:21 Marco d'Itri wrote:
> Package: src:linux
> Version: 4.18.10-2
> Severity: normal
> Tags: upstream
>
> (I am Cc'in the maintainers of the dell-laptop module, accordingly to
> modinfo.)
>
> After running this for about 1H:
>
> while true; do
>  echo 1 > 
> /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight/brightness
>  sleep 0.25
>  echo 0 > 
> /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight/brightness
>  sleep 0.25
> done
>
> most of the memory on my system is used and I get a flood of errors
> like these.
>
> This is a regression, I have noticed this behaviour for at least the
> past 4 months.
>
> Oct 14 16:01:37 bongo kernel: [534600.964709] kworker/1:3: page allocation 
> failure: order:4, mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
> Oct 14 16:01:37 bongo kernel: [534600.964715] kworker/1:3 cpuset=/ 
> mems_allowed=0
> Oct 14 16:01:37 bongo kernel: [534600.964725] CPU: 1 PID: 32257 Comm: 
> kworker/1:3 Tainted: GW  O  4.18.0-2-amd64 #1 Debian 4.18.10-1
> Oct 14 16:01:37 bongo kernel: [534600.964728] Hardware name: Dell Inc. 
> Latitude 7480/0R0YRF, BIOS 1.10.1 05/28/2018
> Oct 14 16:01:37 bongo kernel: [534600.964736] Workqueue: events 
> set_brightness_delayed
> Oct 14 16:01:37 bongo kernel: [534600.964739] Call Trace:
> Oct 14 16:01:37 bongo kernel: [534600.964749]  dump_stack+0x5c/0x7b
> Oct 14 16:01:37 bongo kernel: [534600.964756]  warn_alloc+0xfc/0x180
> Oct 14 16:01:37 bongo kernel: [534600.964763]  ? _cond_resched+0x15/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964769]  
> __alloc_pages_slowpath+0xcfe/0xd40
> Oct 14 16:01:37 bongo kernel: [534600.964775]  
> __alloc_pages_nodemask+0x236/0x250
> Oct 14 16:01:37 bongo kernel: [534600.964782]  kmalloc_order+0x14/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964787]  kmalloc_order_trace+0x1d/0xa0
> Oct 14 16:01:37 bongo kernel: [534600.964793]  
> acpi_ut_initialize_buffer+0x35/0x6b
> Oct 14 16:01:37 bongo kernel: [534600.964799]  
> acpi_evaluate_object+0x1d6/0x240
> Oct 14 16:01:37 bongo kernel: [534600.964810]  
> wmidev_evaluate_method+0x107/0x150 [wmi]
> Oct 14 16:01:37 bongo kernel: [534600.964819]  run_smbios_call+0x6d/0x1a0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964825]  dell_smbios_wmi_call+0x82/0xd0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964830]  dell_smbios_call+0x6f/0xc0 
> [dell_smbios]
> Oct 14 16:01:37 bongo kernel: [534600.964836]  kbd_get_state+0x42/0xf0 
> [dell_laptop]
> Oct 14 16:01:37 bongo kernel: [534600.964843]  kbd_led_level_set+0x3c/0x1a0 
> [dell_laptop]
> Oct 14 16:01:37 bongo kernel: [534600.964848]  
> set_brightness_delayed+0x5b/0xa0
> Oct 14 16:01:37 bongo kernel: [534600.964854]  process_one_work+0x195/0x370
> Oct 14 16:01:37 bongo kernel: [534600.964859]  worker_thread+0x30/0x390
> Oct 14 16:01:37 bongo kernel: [534600.964864]  ? process_one_work+0x370/0x370
> Oct 14 16:01:37 bongo kernel: [534600.964868]  kthread+0x113/0x130
> Oct 14 16:01:37 bongo kernel: [534600.964872]  ? 
> kthread_create_worker_on_cpu+0x70/0x70
> Oct 14 16:01:37 bongo kernel: [534600.964876]  ret_from_fork+0x35/0x40
> Oct 14 16:01:37 bongo kernel: [534600.964881] warn_alloc_show_mem: 2 
> callbacks suppressed
> Oct 14 16:01:37 bongo kernel: [534600.964881] Mem-Info:
> Oct 14 16:01:37 bongo kernel: [534600.964891] active_anon:472110 
> inactive_anon:155641 isolated_anon:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  active_file:302512 
> inactive_file:103400 isolated_file:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  unevictable:52 dirty:2 
> writeback:0 unstable:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  slab_reclaimable:34039 
> slab_unreclaimable:27446
> Oct 14 16:01:37 bongo kernel: [534600.964891]  mapped:104119 shmem:28056 
> pagetables:8196 bounce:0
> Oct 14 16:01:37 bongo kernel: [534600.964891]  free:108743 free_pcp:1 
> free_cma:0
> Oct 14 16:01:37 bongo kernel: [534600.964903] Node 0 active_anon:1888440kB 
> inactive_anon:622564kB active_file:1210048kB inactive_file:413600kB 
> unevictable:208kB isolated(anon):0kB isolated(file):0kB mapped:416476kB 
> dirty:8kB writeback:0kB shmem:112224kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
> anon_thp: 817152kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
> Oct 14 16:01:37 bongo kernel: [534600.964906] Node 0 DMA free:15888kB 
> min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB 
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB 
> present:15988kB managed:15888kB mlocked:0kB kernel_stack:0kB pagetables:0kB 
> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> Oct 14 16:01:37 bongo kernel: [534600.964915] lowmem_reserve[]: 0 3123 

Bug#906599:

[Mario.Limonciello]

Fixed for next upload.

https://github.com/hughsie/fwupd/commit/840920e928df4026652dc15fec86633c945eeb7a

Bug#906357: fwupd: FTBFS in buster/sid (dh_missing: missing files, aborting)

[Mario.Limonciello]

It's a bit odd to me that reproducible builds is failing like that.  The upload 
was built using git-pbuilder and it built just fine.
Also it builds fine in Ubuntu cosmic (who synced from sid).

I don't believe your failure is the same root cause.
I believe this will fix your failure:
https://github.com/hughsie/fwupd/commit/e43765e9a4ff378d612a932c4637ef0a766cc4a0

> -Original Message-
> From: Santiago Vila [mailto:sanv...@debian.org]
> Sent: Friday, August 17, 2018 6:20 AM
> To: Debian BTS
> Subject: Bug#906357: fwupd: FTBFS in buster/sid (dh_missing: missing files,
> aborting)
> 
> Package: src:fwupd
> Version: 1.1.1-1
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> [ -f debian/control ] || debian/rules regenerate_control
> dh build-indep --with gir,systemd
>dh_update_autotools_config -i
>dh_autoreconf -i
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> if pkg-config --exists libsmbios_c; then \
>   export DELL="-Dplugin_dell=true"; \
> else \
>   export DELL="-Dplugin_dell=false"; \
> fi; \
> if pkg-config --exists efivar; then \
>   export UEFI="-Dplugin_uefi=true -Dplugin_redfish=true"; \
> 
> [... snipped ...]
> 
> Installing /<>/obj-x86_64-linux-gnu/meson-private/fwupd.deps to
> /<>/debian/tmp/usr/share/vala/vapi
> Installing /<>/policy/org.freedesktop.fwupd.rules to
> /<>/debian/tmp/usr/share/polkit-1/rules.d
> Installing /<>/src/org.freedesktop.fwupd.xml to
> /<>/debian/tmp/usr/share/dbus-1/interfaces
> Installing /<>/plugins/dfu/dfu.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/colorhug/colorhug.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/ebitdo/ebitdo.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/steelseries/steelseries.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/nitrokey/nitrokey.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/wacomhid/wacomhid.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/csr/csr-aiaiai.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/altos/altos.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/redfish/redfish.conf to
> /<>/debian/tmp/etc/fwupd
> Installing /<>/plugins/dell/dell.quirk to
> /<>/debian/tmp/usr/share/fwupd/quirks.d
> Installing /<>/plugins/uefi/uefi.conf to
> /<>/debian/tmp/etc/fwupd
> Installing /<>/contrib/firmware-packager/firmware-packager to
> /<>/debian/tmp/usr/share/fwupd
> Running custom install script '/usr/bin/python3 /usr/bin/meson --internal 
> gtkdoc --
> sourcedir=/<> --builddir=/<>/obj-x86_64-linux-gnu
> --subdir=docs/libfwupd --
> headerdirs=/<>/libfwupd@@/<>/src@@/< UILDDIR>>/obj-x86_64-linux-gnu/libfwupd@@/<>/obj-x86_64-
> linux-gnu/src --mainfile=libfwupd-docs.xml --modulename=libfwupd --mode=auto -
> -content-files= --cflags=-g -O2 -fdebug-prefix-map=/<>=. -fstack-
> protector-strong -Wformat -Werror=format-security -Wdate-time -
> D_FORTIFY_SOURCE=2 --ldflags=-g -O2 -fdebug-prefix-map=/<>=. -
> fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
> -Wl,-z,now -
> -cc=cc --ld=cc'
> Running custom install script '/usr/bin/python3 /usr/bin/meson --internal 
> gettext
> install --subdir=po --localedir=share/locale --pkgname=fwupd'
> Running custom install script '/<>/po/make-images.sh
> /usr/share/locale'
> Running custom install script '/<>/meson_post_install.sh
> /lib/systemd/system /var'
>debian/rules override_dh_install
> make[1]: Entering directory '/<>'
> find debian/tmp/usr -type f -name "*a" -print | xargs rm -f
> sed -i 's,wheel,sudo,' ./debian/tmp/usr/share/polkit-
> 1/rules.d/org.freedesktop.fwupd.rules
> dh_install
> #install the EFI binaries if needed
> if [ -d debian/tmp/usr/lib/fwupd/efi/ ]; then \
>   dh_install -pfwupd usr/lib/fwupd/efi ;\
>   dh_install -pfwupd usr/lib/fwupd/fwupdate; \
> fi
> dh_install: No packages to build. Architecture mismatch: amd64, want: all 
> amd64
> arm64 armhf i386 linux-any
> dh_install: No packages to build. Architecture mismatch: amd64, want: all 
> amd64
> arm64 armhf i386 linux-any
> dh_missing --fail-missing
> dh_missing: usr/lib/fwupd/fwupdate exists in debian/tmp but is not installed 
> to
> anywhere
> dh_missing: usr/lib/fwupd/efi/fwupdx64.efi exists in debian/tmp but is not
> installed to anywhere
> dh_missing: missing files, aborting
>   The following debhelper tools have reported what they installed (with 
> files
> per package)
>* dh_install: fwupd (48), fwupd-amd64-signed-template (0), fwupd-arm64-
> signed-template (0), fwupd-armhf-signed-template (0), fwupd-doc (1), 
> fwupd-i386-
> signed-template (0), fwupd-tests (3), gir1.2-fwupd-2.0 (1), libfwupd-dev (6),
> 

Bug#906216: Info received (Bug#906216: fwupd: ESP filesystem detection code does not like autofs)

[Mario.Limonciello]

Can you please try this patch?
https://github.com/hughsie/fwupd/pull/661


> -Original Message-
> From: Debian Bug Tracking System [mailto:ow...@bugs.debian.org]
> Sent: Wednesday, August 15, 2018 10:24 AM
> To: Limonciello, Mario
> Subject: Bug#906216: Info received (Bug#906216: fwupd: ESP filesystem 
> detection
> code does not like autofs)
> 
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian EFI 
> 
> If you wish to submit further information on this problem, please
> send it to 906...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 906216: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906216
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#906216: fwupd: ESP filesystem detection code does not like autofs

[Mario.Limonciello]

Forwarded upstream here
https://github.com/hughsie/fwupd/issues/660

Please subscribe and comment as necessary.

> -Original Message-
> From: Sam Morris [mailto:s...@robots.org.uk]
> Sent: Wednesday, August 15, 2018 9:56 AM
> To: Debian Bug Tracking System
> Subject: Bug#906216: fwupd: ESP filesystem detection code does not like autofs
> 
> Package: fwupd
> Version: 1.1.1-1
> Severity: normal
> 
> My ESP is mounted via autofs so that it's unmounted when not in use:
> 
> $ grep /boot/efi /etc/fstab
> PARTLABEL=joyeux-esp /boot/efi vfat umask=0077,x-systemd.automount,x-
> systemd.idle-timeout=10 0 2
> 
> This leads to:
> 
> # /usr/lib/fwupd/fwupdate --info
> Unable to determine EFI system partition location, override using 
> --esp-path
> 
> # /usr/lib/fwupd/fwupdate --info --esp-path /boot/efi
> ESP specified was not valid: /boot/efi has an invalid type, expected
> vfat|ntfs|exfat
> 
> fwupd seems to be looking through existing mounts for one of the correct
> type, which won't work where the ESP is mounted via autofs, since it's
> not mounted yet...
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (570, 'testing-debug'), (570, 'testing'), (540, 
> 'unstable-debug'), (540,
> 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libappstream-glib8 0.7.10-1
> ii  libarchive13   3.2.2-4.1
> ii  libc6  2.27-5
> ii  libefiboot134-1
> ii  libefivar1 34-1
> ii  libelf10.170-0.5
> ii  libfwupd2  1.1.1-1
> ii  libgcab-1.0-0  1.1-3
> ii  libglib2.0-0   2.56.1-2
> ii  libgnutls303.5.19-1
> ii  libgpg-error0  1.32-1
> ii  libgpgme11 1.11.1-1
> ii  libgudev-1.0-0 232-2
> ii  libgusb2   0.2.11-1
> ii  libjson-glib-1.0-0 1.4.2-4
> ii  libpolkit-gobject-1-0  0.105-21
> ii  libsmbios-c2   2.4.1-1
> ii  libsoup2.4-1   2.62.2-2
> ii  libsqlite3-0   3.24.0-1
> ii  libuuid1   2.32.1-0.1
> 
> Versions of packages fwupd recommends:
> pn  fwupd-signed  
> ii  python3   3.6.5-3
> 
> fwupd suggests no packages.
> 
> -- Configuration Files:
> /etc/fwupd/uefi.conf changed:
> [uefi]
> OverrideESPMountPoint=/boot/efi
> 
> 
> -- no debconf information

Bug#905570: Info received (Bug#905570: fwupd: Firmware update failed on Lenovo P50)

[Mario.Limonciello]

This bug will be fixed in the fwupd 1.1.1 release.

> -Original Message-
> From: Debian Bug Tracking System [mailto:ow...@bugs.debian.org]
> Sent: Monday, August 6, 2018 7:39 AM
> To: Limonciello, Mario
> Subject: Bug#905570: Info received (Bug#905570: fwupd: Firmware update failed
> on Lenovo P50)
> 
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian EFI 
> 
> If you wish to submit further information on this problem, please
> send it to 905...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 905570: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905570
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#905570: fwupd: Firmware update failed on Lenovo P50

[Mario.Limonciello]

This sounds like it matches https://github.com/hughsie/fwupd/issues/619 pretty 
closely if I'm not mistaken, just a different model number.

Can you please comment there?

Bug#904671: fwupd: Incomplete debian/copyright?

[Mario.Limonciello]

Chris,

OK.

Can you please look again?  I've adjusted the script to group together files in 
the same directory.
https://github.com/hughsie/fwupd/pull/611

Thanks,

Bug#904671: fwupd: Incomplete debian/copyright?

[Mario.Limonciello]

Chris,

Thanks for accepting it.  I've made this PR upstream to fill in debian/copyright
properly automatically.  We'll pull that in in the future (unless you or anyone
else has a concern).

https://github.com/hughsie/fwupd/pull/611

Thanks,

> -Original Message-
> From: Chris Lamb [mailto:la...@debian.org]
> Sent: Thursday, July 26, 2018 8:09 AM
> To: sub...@bugs.debian.org
> Subject: Bug#904671: fwupd: Incomplete debian/copyright?
> 
> Source: fwupd
> Version: 1.1.0-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Mario Limonciello 
> 
> Hi,
> 
> I just ACCEPTed fwupd from NEW but noticed it was missing attribution
> in debian/copyright for at least a bunch of code copies (or similar)
> under "plugins/".
> 
> This is in no way exhaustive so please check over the entire package
> carefully and address these on your next upload. :)
> 
> 
> Regards,
> 
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade

[Mario.Limonciello]

> -Original Message-
> From: Joel Cross [mailto:j...@kazbak.co.uk]
> Sent: Saturday, July 7, 2018 10:00 AM
> To: Michael Biebl; Limonciello, Mario; 902...@bugs.debian.org
> Subject: Re: Bug#902416: systemd: systemctl hibernate: unable to resume after
> upgrade
> 
> On Fri, 6 Jul 2018, at 5:31 PM, Michael Biebl wrote:
> > Am 06.07.2018 um 17:02 schrieb mario.limoncie...@dell.com:
> > >> -Original Message-
> > >> From: Michael Biebl [mailto:bi...@debian.org]
> >
> > >> If you have multiple swap partitions and you run
> > >> echo "disk" > /sys/power/state
> > >> which partition does the kernel use?
> > >>
> > >
> > > Whichever one was configured in /sys/power/resume prior to running that
> command.
> > >
> > > The kernel can't know which one /to/ hibernate to unless it was 
> > > configured in
> advance.
> > > Just like the initramfs can't know which one to resume /from/ unless it 
> > > knew
> which one
> > > it resumed to.
> > >
> >
> > Joel, can you please tell us,
> > - which partition you have configured in /etc/initramfs-tools/conf.d/resume
> > - which partition you have configured in /sys/power/resume
> > - the size of both swap partitions
> >
> 
> $ cat /proc/swaps
> Filename  TypeSizeUsedPriority
> /dev/sdb4   partition 9752572 1473128 100
> /dev/sda8   partition 6236156 0   10
> 
> $ blkid /dev/sdb4 /dev/sda8
> /dev/sdb4: LABEL="Swap" UUID="0797ee37-d1b9-49ea-a865-c73682cd96a7"
> TYPE="swap" PARTUUID="57f4c922-04"
> /dev/sda8: UUID="84f3e7a4-c3af-4ac1-a789-cc554395a50b" TYPE="swap"
> PARTUUID="170bc00e-08"
> 
> $ grep resume /boot/grub/grub.cfg|head -n 1
>   linux   /vmlinuz-4.16.0-2-amd64 root=UUID=033d10f2-5402-4632-bed0-
> 5e24842cf1b7 ro  quiet splash resume=UUID=84f3e7a4-c3af-4ac1-a789-
> cc554395a50b
> 
> $ cat /etc/initramfs-tools/conf.d/resume
> cat: /etc/initramfs-tools/conf.d/resume: No such file or directory
> 
> $ cat /sys/power/resume
> 8:8
> 
> From the above (especially grub.cfg) you can see that the smaller, 
> lower-priority
> partition is set as the resume partition (this was actually an oversight on 
> my part
> when I installed the second drive). Do you think this could be what's 
> preventing
> hibernate from working properly?
> 
> Also, do you think it is significant that the 
> /etc/initramfs-tools/conf.d/resume file
> does not exist on my system?
> 
> -Joel

I think I have an understanding on what's happening here.  So when you 
configured
your system to have a RESUME= variable on the DEFAULT kernel command line then
the kernel chooses to fill this one at bootup (hence the 8:8).  This kernel 
command line
is also what's passed to the initramfs, so even if you didn't configure that 
resume file
it's what is used for resuming.

Now the systemd changes have messed this up for you because they are writing to 
the
biggest swap (changing your 8:8).

As a simple fix, I expect if you change your RESUME= to the other swap 
partition your
resume behavior will be fine.

That being said, I think it makes sense to amend the systemd logic to also look 
for the
kernel command line RESUME= variable and choose that if the user had put it on 
kernel
command line.

Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade

[Mario.Limonciello]

> -Original Message-
> From: Michael Biebl [mailto:bi...@debian.org]
> Sent: Friday, July 6, 2018 9:53 AM
> To: Limonciello, Mario; j...@kazbak.co.uk; 902...@bugs.debian.org
> Subject: Re: Bug#902416: systemd: systemctl hibernate: unable to resume after
> upgrade
> 
> Am 06.07.2018 um 14:41 schrieb mario.limoncie...@dell.com:
> 
> > Yes I could see two swap partitions causing the wrong one to be picked.
> > It's trying to select the bigger of the two.
> >
> > If they don't match the one you're putting in 
> > /etc/initramfs-tools/conf.d/resume
> > then that would cause problems.  Please do confirm if you switch what's in
> > initramfs conf.d/resume that the problem is fixed.
> 
> If you have multiple swap partitions and you run
> echo "disk" > /sys/power/state
> which partition does the kernel use?
> 

Whichever one was configured in /sys/power/resume prior to running that command.

The kernel can't know which one /to/ hibernate to unless it was configured in 
advance.
Just like the initramfs can't know which one to resume /from/ unless it knew 
which one
it resumed to.

You can confirm which one the kernel is using by turning on debugging for 
hibernate and looking
for this message:
https://github.com/torvalds/linux/commit/648464076160ee7a4112d05eea13621790ab9d04#diff-4bc504812a6e5edefe9068b56aa3ddf0

Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade

[Mario.Limonciello]

> -Original Message-
> From: Michael Biebl [mailto:bi...@debian.org]
> Sent: Friday, July 6, 2018 5:46 AM
> To: Joel Cross; 902...@bugs.debian.org; Limonciello, Mario
> Subject: Re: Bug#902416: systemd: systemctl hibernate: unable to resume after
> upgrade
> 
> Am 06.07.2018 um 12:32 schrieb Joel Cross:
> > On Thu, 5 Jul 2018, at 1:17 PM, Michael Biebl wrote:
> >> Am 05.07.2018 um 13:46 schrieb Joel Cross:
> >>> Yes, I can confirm, after downgrading to 238-5 (I also downgraded the
> libsystemd0, udev and libudev0 packages) that I no longer experience the 
> issue.
> >>
> >> Do you know how to use git bisect? If so, it would be great if you can
> >> find the offending commit in systemd-sleep. There aren't that many.
> >>
> >> If not, please upgrade to v239 again, unpack the binary from the
> >> attached zip file and run
> >> sudo ./systemd-sleep hibernate
> >>
> >> (this binary disables a certain commit which I suspect might be what's
> >> causing your trouble).
> > Hibernate seems to work fine with the binary that you attached.
> >
> 
> So, the offending commit seems to be
> 
> https://github.com/systemd/systemd/commit/17c40b3a8fbfb797110c88d749bd5
> d37e6ee6e3c#diff-f1a8ef48b9daffd7280cdacb9044c80f
> 
> I'm bringing Mario into the loop here, the author of this commit.
> Mario, please see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902416 for the
> complete bug report.
> Do you have any idea why this commit could break hibernate/resume for Joel?
> 
> Joel, I see you have multiple swap partitons defined in
> https://bugs.debian.org/cgi-
> bin/bugreport.cgi?att=4;bug=902416;filename=fstab;msg=5
> 
> Which one of those is setup as your resume partition in
> /etc/initramfs-tools/conf.d/resume?
> 
> Mario, could the systemd code be confused by the existence of two swap
> partitions and pick the wrong one?
> 
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?

Yes I could see two swap partitions causing the wrong one to be picked.
It's trying to select the bigger of the two.

If they don't match the one you're putting in /etc/initramfs-tools/conf.d/resume
then that would cause problems.  Please do confirm if you switch what's in
initramfs conf.d/resume that the problem is fixed.

Really matching code is needed for the initramfs-tools.  I submitted some 
patches
that may help here.  You can refer to them at the end of this bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890950

Bug#896148: fwupd: Please add ia64, riscv64 and x32 to the ports without valgrind

[Mario.Limonciello]

 -Original Message-
> From: Adrian Bunk [mailto:b...@debian.org]
> Sent: Friday, April 20, 2018 3:32 AM
> To: Debian Bug Tracking System
> Subject: Bug#896148: fwupd: Please add ia64, riscv64 and x32 to the ports 
> without
> valgrind
> 
> Source: fwupd
> Version: 1.0.6-2
> Severity: normal
> 
> Please add ia64, riscv64 and x32 to the ports without valgrind
> none of them is likely to have valgrind soon.

Adrian,

Sure, just added them upstream so this change will be affected in the next 
upstream release.
https://github.com/hughsie/fwupd/commit/58fc7d746778154e3bf8730d093847286beed63b

Thanks

Bug#896012: Regression from gcc-7 7.3.0-16

[Mario.Limonciello]

> -Original Message-
> From: Matthias Klose [mailto:d...@debian.org]
> Sent: Wednesday, April 18, 2018 9:29 PM
> To: Limonciello, Mario; 896...@bugs.debian.org
> Subject: Re: Bug#896012: Regression from gcc-7 7.3.0-16
> 
> On 18.04.2018 19:34, mario.limoncie...@dell.com wrote:
> > Package: gcc-7
> > Version: 7.3.0-16
> >
> > The fwupd project as one of the CI tasks runs packaged builds and lintian 
> > after the
> build.
> > CI recently started failing with this error:
> >
> > E: fwupd: library-not-linked-against-libc 
> > usr/lib/x86_64-linux-gnu/fwupd-plugins-
> 3/libfu_plugin_upower.so
> > E: fwupd-tests: library-not-linked-against-libc 
> > usr/lib/x86_64-linux-gnu/fwupd-
> plugins-3/libfu_plugin_test.so
> >
> > We narrowed it down to be caused after upgrading to GCC 7.3.0-16 from Debian
> testing.
> > Builds with 7.3.0-15 and no source changes to fwupd are not affected.
> >
> > We also found that changing compiler optimization (-O2 to -O0) with the new 
> > GCC
> this error
> > goes away.
> 
> please could you attach the linker command, run with -v, and maybe all linker
> scripts?

Here are both compiler and linker commands when run with -v.

# cc  -Iplugins/test/fu_plugin_test@sha -Iplugins/test -I../plugins/test 
-Iplugins/test/../.. -I../plugins/test/../.. -Iplugins/test/../../src 
-I../plugins/test/../../src -Iplugins/test/../../libfwupd 
-I../plugins/test/../../libfwupd -I/usr/include/libappstream-glib 
-I/usr/include/uuid -I/usr/include/gio-unix-2.0/ -I/usr/include/libgcab-1.0 
-I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng16 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gusb-1 
-I/usr/include/libusb-1.0 -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -std=c99 -fstack-protector-strong -Waggregate-return 
-Wunused -Warray-bounds -Wcast-align -Wclobbered -Wdeclaration-after-statement 
-Wduplicated-branches -Wduplicated-cond -Wempty-body -Wformat=2 
-Wformat-nonliteral -Wformat-security -Wformat-signedness -Wignored-qualifiers 
-Wimplicit-function-declaration -Winit-self -Wlogical-op -Wmissing-declarations 
-Wmissing-format-attribute -Wmissing-include-dirs -Wmissing-noreturn 
-Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wno-error=cpp 
-Wno-unknown-pragmas -Wno-discarded-qualifiers -Wno-missing-field-initializers 
-Wno-strict-aliasing -Wno-suggest-attribute=format -Wno-unused-parameter 
-Wnull-dereference -Wold-style-definition -Woverride-init -Wpointer-arith 
-Wredundant-decls -Wreturn-type -Wshadow -Wsign-compare -Wstrict-aliasing 
-Wstrict-prototypes -Wswitch-default -Wtype-limits -Wundef -Wuninitialized 
-Wunused-but-set-variable -Wunused-variable -Wwrite-strings -D_DEFAULT_SOURCE 
-DFWUPD_DISABLE_DEPRECATED -D_GNU_SOURCE -g -O2 
-fdebug-prefix-map=/build/build=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
'-DG_LOG_DOMAIN="FuPluginTest"' -MD -MQ 
'plugins/test/fu_plugin_test@sha/fu-plugin-test.c.o' -MF 
'plugins/test/fu_plugin_test@sha/fu-plugin-test.c.o.d' -o 
'plugins/test/fu_plugin_test@sha/fu-plugin-test.c.o' -c 
../plugins/test/fu-plugin-test.c -v
Using built-in specs.
COLLECT_GCC=cc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-16' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as 
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-16) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-I' 
'plugins/test/fu_plugin_test@sha' '-I' 'plugins/test' '-I' '../plugins/test' 
'-I' 'plugins/test/../..' '-I' '../plugins/test/../..' '-I' 
'plugins/test/../../src' '-I' '../plugins/test/../../src' '-I' 
'plugins/test/../../libfwupd' '-I' '../plugins/test/../../libfwupd' '-I' 
'/usr/include/libappstream-glib' '-I' '/usr/include/uuid' '-I' 
'/usr/include/gio-unix-2.0/' '-I' '/usr/include/libgcab-1.0' '-I' 
'/usr/include/libsoup-2.4' 

Bug#896012: Regression from gcc-7 7.3.0-16

[Mario.Limonciello]

Package: gcc-7
Version: 7.3.0-16

The fwupd project as one of the CI tasks runs packaged builds and lintian after 
the build.
CI recently started failing with this error:

E: fwupd: library-not-linked-against-libc 
usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_upower.so
E: fwupd-tests: library-not-linked-against-libc 
usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_test.so

We narrowed it down to be caused after upgrading to GCC 7.3.0-16 from Debian 
testing.
Builds with 7.3.0-15 and no source changes to fwupd are not affected.

We also found that changing compiler optimization (-O2 to -O0) with the new GCC 
this error
goes away.

Bug#890950: Info received (Bug#890950: initramfs-tools: Resuming from hibernated swapfile fails)

[Mario.Limonciello]

Hi,

I've had some more testing this week and developed some changes that I think 
are more sustainable.
1) No longer revert the setting offset via /bin/resume.
I've started a discussion upstream to allow reading offset this way.  If it's 
adopted then this should
definitely stay.
Otherwise it's harmless.
2) Detect the offset both from kernel command line as well as filename.

Can you please ignore my old ones, and re-review my new patches and consider 
them for initramfs-tools?
https://salsa.debian.org/superm1-guest/initramfs-tools/commit/f74423c610bd3b9ee9baf97d42bfa0219bfb4826
https://salsa.debian.org/superm1-guest/initramfs-tools/commit/a39f61e48eca03e264a7235ee984db76e8c10aa9

Thanks,

Bug#890064: smbios-utils: properly clean up legacy config files

[Mario.Limonciello]

Th warnings come from the dpkg maintscript helper.  You're supposed to put it 
in all the helper scripts and they show warnings for the prerm IIRC.
I guess a separate upgrade task may be needed to delete the directories then 
too if empty.

> -Original Message-
> From: Christoph Anton Mitterer [mailto:cales...@scientia.net]
> Sent: Tuesday, February 27, 2018 2:44 PM
> To: 890...@bugs.debian.org
> Subject: Bug#890064: smbios-utils: properly clean up legacy config files
> 
> Hi.
> 
> Are you sure this has been fixed properly?
> 
> On an upgrade to the new package version I saw:
> Unpacking smbios-utils (2.4.1-1) over (2.3.1-2) ...
> dpkg: warning: unable to delete old directory '/etc/yum/pluginconf.d': 
> Directory
> not empty
> dpkg: warning: unable to delete old directory '/etc/yum': Directory not empty
> 
> and while all these are empty, the dirs are still not removed.
> 
> Cheers,
> Chris.

Bug#890950:

[Mario.Limonciello]

I've reworked my patches and split to 3 segments that take your feedback into 
account.  Can you please review these?

With setting resume_offset on kernel command line I confirmed this works out of 
the box for me.

https://salsa.debian.org/superm1-guest/initramfs-tools/commit/c8f4ae22a3332941940fb4b7d65583e2e29efb56
https://salsa.debian.org/superm1-guest/initramfs-tools/commit/20caffa22848372084893da5b2186167b8b143cb
https://salsa.debian.org/superm1-guest/initramfs-tools/commit/1ec25e76395a8108bfc3c8452a8b916db970dfe1

Bug#890950: initramfs-tools: Resuming from hibernated swapfile fails

[Mario.Limonciello]

Thanks, I appreciate your feedback.  
Some more comments nested below.
> >
> > 1) It requires that uswpswp is installed (to provide /bin/resume)[...]

> 
> No, it runs /bin/resume which is installed by klibc-utils.  (uswsusp
> installs its resume implementation as /sbin/resume.  That's what the
> comment is about.)

Ah thanks - this wasn't clear.  I wasn't seeing /bin/resume on a standard
system and that's because it's in /usr/lib/klibc/bin/resume on a standard
system and copied to initramfs.

> 
> > 2) It doesn't properly detect offsets
> 
> So far as I can see, the kernel has never really supported an offset
> being passed through /sys/power/resume.  However:
> 
> 1. The kernel parses the resume_offset parameter, and uses that for
> every resume request.
> 2. The implementation of /sys/power/resume is not very strict, and
> ignores the trailing ":offset".
> 
> This second feature was briefly broken between Linux 4.1-rc1 and 4.1-
> rc3, but otherwise still seems to work.  So I don't see what your
> change is fixing.
> 
> However I do think that either:
> 
> 1. The kernel should add real support for setting the resume offset
> after boot.
> 2. klibc should stop writing the unused offset parameter.

If you don't mind, I'm going to follow up with an updated patch
that drops klibc /bin/resume writing the unused parameter.

Also there was a few other aspects of my patch that I think are relevant
that I'll make sure are still present when I follow up.

1) using Plymouth if present to indicate resuming
2) Detection of swapfile via blkid (the current "auto") stuff doesn't work
otherwise.

Bug#890950: initramfs-tools: Resuming from hibernated swapfile fails

[Mario.Limonciello]

Package: initramfs-tools
Version: 0.130ubuntu2
Severity: important

Dear Maintainer,

I've found that resuming from a hibernated swapfile using the kernel hibernate
implementation fails.  This is due to some assumptions made in initramfs-tools:

1) It requires that uswpswp is installed (to provide /bin/resume)
2) It doesn't properly detect offsets

I've produced a patch that resolves these problems (and also merges some
improvements found in Ubuntu's implementation of this).

Would you please consider to adopt it in Debian?

It's available on my Gitlab profile:
https://salsa.debian.org/superm1-guest/initramfs-tools/commit/8578edf9af9484f65095455bb2355968eef4

Thanks,

Bug#822078:

[Mario.Limonciello]

This is a big of an old issue, but I got referred to it from someone else.

As a hunch - can you (or anyone else who comes to this) please try to disable
Legacy option ROMs in BIOS setup and try again?

Bug#890064: smbios-utils: properly clean up legacy config files

[Mario.Limonciello]

Thanks for the report.
I've added this for the next upload:
https://github.com/dell/libsmbios/commit/42379a462ec777cf5ae8ba87df40e5432faa8585

> -Original Message-
> From: Christoph Anton Mitterer [mailto:cales...@scientia.net]
> Sent: Saturday, February 10, 2018 11:28 AM
> To: Debian Bug Tracking System 
> Subject: Bug#890064: smbios-utils: properly clean up legacy config files
> 
> Package: smbios-utils
> Version: 2.4.0-1
> Severity: normal
> 
> 
> Hi.
> 
> Apparently the package smbios-utils used to contain:
> /etc/yum/pluginconf.d/dellsysid.conf
> but no longer does.
> 
> Therefore, the following happens on upgrade:
> Unpacking smbios-utils (2.4.0-1) over (2.3.1-2) ...
> dpkg: warning: unable to delete old directory '/etc/yum/pluginconf.d': 
> Directory
> not empty
> dpkg: warning: unable to delete old directory '/etc/yum': Directory not empty
> 
> 
> Please remove the obsolete config file on one of the next upgrades with the
> appropriate
> maintainer script helpers.
> 
> Thanks,
> Chris.

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Mario.Limonciello]

Pierre,

There have been a few times the patches got synced between the two, but I'll 
admit
I don't know the current home to the patches that live in the Debian package.

Hopefully some of the Debian maintainers can speak up since I haven't tracked 
it.

I think it would be good to make sure that all patches that are currently in 
2.3 in Debian
are no longer applicable in 2.5 and then update to 2.5 in Debian as well.

Thanks,

> -Original Message-
> From: Pierre Neyron [mailto:pierre.ney...@free.fr]
> Sent: Monday, February 12, 2018 11:54 AM
> To: Limonciello, Mario ; 832...@bugs.debian.org;
> pkg-dkms-ma...@lists.alioth.debian.org
> Subject: Re: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
> 
> Hi Marco,
> 
> Problem is Debian dkms (v2.3) seems to be an old fork of github/dell
> dkms (v2.5). Support for mkbmdeb comes from a patch in the Debian
> package but does not exist upstream. As a result my patch is not so
> relevant for upstream.
> 
> Do you know if the current Debian patches were already proposed to
> upstream ? Do you know the roadmap for a possible merge from upstream
> (bump Debian package version to 2.5) ?
> 
> Last be not least, since I do not have all the test cases in mind, I'd
> be glad to get a review from the Debian maintainers before sending upstream.
> 
> 
> Thanks,
> Best regards,
> Pierre
> 
> On 02/12/2018 06:27 PM, mario.limoncie...@dell.com wrote:
> >> -Original Message-
> >> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
> >> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of
> Pierre
> >> Neyron
> >> Sent: Monday, February 12, 2018 11:21 AM
> >> To: 832...@bugs.debian.org
> >> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
> >>
> >> Please find attached a patch for the dkms script (package version 2.3-3)
> >> that fixes the following issues:
> >>
> >> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
> >> package filename with -${debian_build_arch} instead of -all.
> >>
> >> - fix mkdeb (2): allow creating a dkms package without requiring to
> >> build the binary module beforehand . The patch actually makes
> >> --source-only de facto for mkdeb and mkdsc.
> >>
> >> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
> >>
> >> - fix usage: lacked mkdsc
> >>
> >> Regards
> >> Pierre
> >
> > Pierre,
> >
> > Can you please submit the patches to upstream at github?
> >

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Mario.Limonciello]

> -Original Message-
> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of 
> Pierre
> Neyron
> Sent: Monday, February 12, 2018 11:21 AM
> To: 832...@bugs.debian.org
> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
> 
> Please find attached a patch for the dkms script (package version 2.3-3)
> that fixes the following issues:
> 
> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
> package filename with -${debian_build_arch} instead of -all.
> 
> - fix mkdeb (2): allow creating a dkms package without requiring to
> build the binary module beforehand . The patch actually makes
> --source-only de facto for mkdeb and mkdsc.
> 
> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
> 
> - fix usage: lacked mkdsc
> 
> Regards
> Pierre

Pierre,

Can you please submit the patches to upstream at github?

Bug#887263: [Pkg-dkms-maint] Bug#887263: dkms should depend on e2fsprogs explicitly

[Mario.Limonciello]

> -Original Message-
> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of
> Andreas Henriksson
> Sent: Sunday, January 21, 2018 3:47 AM
> To: Helmut Grohne ; 887...@bugs.debian.org
> Subject: [Pkg-dkms-maint] Bug#887263: dkms should depend on e2fsprogs
> explicitly
> 
> On Sun, Jan 14, 2018 at 08:03:50PM +0100, Helmut Grohne wrote:
> > Package: dkms
> [...]
> > /usr/sbin/dkms contains mke2fs. According to file it is a Bourne-Again 
> > shell script,
> ASCII text executable, with very long lines
> [...]
> 
> Indeed dkms uses both mke2fs and mkdosfs. There's no relation from dkms
> towards dosfstools specified in the dkms package either, which would
> otherwise be a sign of how important these commands are to dkms
> functionality.
> 
> The commands are (only) used from a function called
> "make_driver_disk_floppy" which in turn is invoked (via a call chain)
> from "make_driver_disk" and that function checks distro which seems to
> be specified from commandline flag -d . (Note that there's no
> debian alternative! There is one for ubuntu though.)
> The command to invoke the code path seems to be something like
> 'dkms mkdriverdisk -d  [...]'.
> Note that while today we can probably consider floppies to not be so
> common anymore, the default media type in dkms mkdriverdisk is floppy.
> 
> I'm not sure how important this functionality is, but the entire thing
> seems to be pretty overlooked from a Debian perspective which leads
> me to assume a Suggests (rather than Recommends or Depends) might be
> suitable.

I would agree Suggests makes sense in this context.

> 
> I'm left with a few questions that it would be great to hear maintainers
> view on
> * Is the mkdriverdisk functionality useful at all these days? Maybe
>   it should just be patched out (and possibly even removed upstream)?
It's (obviously) not too useful for Debian, but I believe it's useful for other
distros.

> * If useful, shouldn't someone work on a debian distro code-path?
The ubuntu code path relies on changes that were made to include a special
driver disk handler in d-i.  I'm unsure that it made it back to Debian.

If it did, then it should be as simple as recognizing both Debian and Ubuntu
as the same codepaths.

> * Shouldn't floppies be considered uncommon enough that the default
>   should be changed to something else?

Probably.  I think it is worth proposing this to upstream issue tracker.

> All of these are off-topic in this particular bug report though and
> separate bug reports should probably be opened if there's a need
> to discuss any of that. Possibly upstream rather than in Debian.
> 
> My conclusion here is that it's likely not the end of the world if
> we just closed this bug report. If a package relationship should be
> added using 'Suggests: dosfstools, e2fsprogs' would likely be the
> most suitable. Maintainers view on this would be nice to hear!

I'm not active in DKMS anymore (Someone else in Dell maintains it now),
but hope my comments are useful since I had some history from this.

Bug#886878:

[Mario.Limonciello]

I tried in a fully up to date debian unstable VM and can not reproduce this 
myself.

Bug#886878: fwupd service startup fails.

[Mario.Limonciello]

The 4.14 kernel you are running, does it have the various spectre and meltdown 
fixes integrated already?

If so, could you please check with an older kernel without them to see if it's 
also affected?  I'm wondering if those might be causing a problem.

Bug#886878: fwupd service startup fails.

[Mario.Limonciello]

I couldn't reproduce this myself.  As far as I'm aware there is no FFI 
generated code in fwupd.

I think we'll need to see some more logs and/or journal output to figure out 
what's going on for you.

Also filed this upstream, so please feel free to discuss there as well.
https://github.com/hughsie/fwupd/issues/359


> -Original Message-
> From: Limonciello, Mario
> Sent: Wednesday, January 10, 2018 2:47 PM
> To: 'Abhijit Hoskeri' ; '886...@bugs.debian.org'
> <886...@bugs.debian.org>; Debian Bug Tracking System
> 
> Subject: RE: Bug#886878: fwupd service startup fails.
> 
> Thanks for filing this.
> 
> Can you please share the associated journal output when it tries to launch?
> Does it hang?
> 
> Or does it just not launch at all?
> 
> > -Original Message-
> > From: Abhijit Hoskeri [mailto:abhijithosk...@icloud.com]
> > Sent: Wednesday, January 10, 2018 1:40 PM
> > To: Debian Bug Tracking System 
> > Subject: Bug#886878: fwupd service startup fails.
> >
> > Package: fwupd
> > Version: 1.0.3-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > fwupd startup fails with the default systemd service configuation - the
> > service seems to require libffi generated code, and the systemd
> > directive 'MemoryDenyWriteExecute=yes' prevents libffi from executing
> > generated code.
> >
> > Disabling this in the systemd service MemoryDenyWriteExecute allows the
> > service startup to proceed as expected.
> >
> > Thanks,
> > Abhijit
> >
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> > 'unstable'), (500,
> > 'testing'), (1, 'experimental-debug'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages fwupd depends on:
> > ii  libappstream-glib8 0.7.4-1
> > ii  libarchive13   3.2.2-3.1
> > ii  libc6  2.26.9000+20180108.401311cf-0experimental0
> > ii  libcolorhug2   1.3.3-2
> > ii  libefivar1 32-2
> > ii  libelf10.170-0.2
> > ii  libfwup1   10-1
> > ii  libfwupd2  1.0.3-1
> > ii  libglib2.0-0   2.54.3-1
> > ii  libgnutls303.6.1-1
> > ii  libgpg-error0  1.27-5
> > ii  libgpgme11 1.10.0-1
> > ii  libgudev-1.0-0 232-1
> > ii  libgusb2   0.2.11-1
> > ii  libpolkit-gobject-1-0  0.113-6
> > ii  libsmbios2 2.3.1-2
> > ii  libsoup2.4-1   2.60.2-2
> > ii  libsqlite3-0   3.21.0-1
> > ii  libuuid1   2.30.2-0.1
> >
> > Versions of packages fwupd recommends:
> > ii  fwupdate  10-1
> > ii  python3   3.6.4-1
> >
> > fwupd suggests no packages.
> >
> > -- no debconf information

Bug#886878: fwupd service startup fails.

[Mario.Limonciello]

Thanks for filing this.

Can you please share the associated journal output when it tries to launch?
Does it hang?

Or does it just not launch at all?

> -Original Message-
> From: Abhijit Hoskeri [mailto:abhijithosk...@icloud.com]
> Sent: Wednesday, January 10, 2018 1:40 PM
> To: Debian Bug Tracking System 
> Subject: Bug#886878: fwupd service startup fails.
> 
> Package: fwupd
> Version: 1.0.3-1
> Severity: important
> 
> Dear Maintainer,
> 
> fwupd startup fails with the default systemd service configuation - the
> service seems to require libffi generated code, and the systemd
> directive 'MemoryDenyWriteExecute=yes' prevents libffi from executing
> generated code.
> 
> Disabling this in the systemd service MemoryDenyWriteExecute allows the
> service startup to proceed as expected.
> 
> Thanks,
> Abhijit
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> 'unstable'), (500,
> 'testing'), (1, 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages fwupd depends on:
> ii  libappstream-glib8 0.7.4-1
> ii  libarchive13   3.2.2-3.1
> ii  libc6  2.26.9000+20180108.401311cf-0experimental0
> ii  libcolorhug2   1.3.3-2
> ii  libefivar1 32-2
> ii  libelf10.170-0.2
> ii  libfwup1   10-1
> ii  libfwupd2  1.0.3-1
> ii  libglib2.0-0   2.54.3-1
> ii  libgnutls303.6.1-1
> ii  libgpg-error0  1.27-5
> ii  libgpgme11 1.10.0-1
> ii  libgudev-1.0-0 232-1
> ii  libgusb2   0.2.11-1
> ii  libpolkit-gobject-1-0  0.113-6
> ii  libsmbios2 2.3.1-2
> ii  libsoup2.4-1   2.60.2-2
> ii  libsqlite3-0   3.21.0-1
> ii  libuuid1   2.30.2-0.1
> 
> Versions of packages fwupd recommends:
> ii  fwupdate  10-1
> ii  python3   3.6.4-1
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#886349: initramfs-tools: Missing vmd driver in hook-functions

[Mario.Limonciello]

Package: initramfs-tools
Version: 0.130
Severity: important

Dear Maintainer,

initramfs-tools is missing the Intel Volume Management Device (vmd.ko)
that was included in kernel 4.9 and later.

This sets up NVME disks in a separate PCI domain and is needed to access
them when the system is configured this way.  It must be available in
the initramfs to locate the root disk if configured as boot.

This can be fixed with the following trivial patch:
--- hook-functions.old  2018-01-04 13:58:03.256828153 -0500
+++ hook-functions  2017-10-13 15:09:26.0 -0400
@@ -583,7 +583,7 @@
block)
copy_modules_dir kernel/drivers/block
copy_modules_dir kernel/drivers/nvme
-   modules="$modules"
+   modules="$modules vmd"
;;
ubi)
modules="$modules deflate zlib lzo ubi ubifs"

Bug#882524:

[Mario.Limonciello]

Does it even make sense to compile on kFreeBSD?  This package relies on the 
behavior of the thunderbolt module in the Linux kernel.

Bug#883489: fwupdate FTCBFS: multiple reasons

[Mario.Limonciello]

Thank you for the diff.  It looks fine to me and something we can apply for the 
next upload.
Would you please also submit a PR to upstream for the upstream applicable parts 
(0003-cross.patch).

> -Original Message-
> From: Helmut Grohne [mailto:hel...@subdivi.de]
> Sent: Monday, December 4, 2017 10:53 AM
> To: Debian Bug Tracking System 
> Subject: Bug#883489: fwupdate FTCBFS: multiple reasons
> 
> Source: fwupdate
> Version: 9-3
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> fwupdate fails to cross build from source for a number of reasons:
>  1. It uses the build architecture objcopy, because dh_auto_build passes
> neither OBJCOPY nor CROSS_COMPILE. While the CROSS_COMPILE variable
> is somewhat general, it's not as widely adopted. dh_auto_build
> explicitly sets tools such as CC or PKG_CONFIG. Explicitly passing
> CROSS_COMPILE makes this part work.
>  2. The upstream build system hard codes the use of the build
> architecture pkg-config. While it considers CROSS_COMPILE for other
> tools (including CC, LD and OBJCOPY) it fails to do so for
> pkg-config. I think this is an upstream bug and it should allow
> substituting pkg-config just like the other tools.
>  3. It derives FWUP in efi/Makefile from ARCH and ARCH from CC.
> Unfortunately, dh_auto_install doesn't pass CC (only dh_auto_build
> does). Thus FWUP differs between build and install and thus tries to
> build more stuff. An easy way to solve this is to simply pass
> CROSS_COMPILE to make install as well.
> After fixing all of the above, fwupdate cross builds successfully.
> Please consider applying the attached patch.
> 
> Helmut

Bug#878311:

[Mario.Limonciello]

This particular issue is fixed with 
https://github.com/hughsie/appstream-glib/commit/a1481d201d089f9e70a0cf48a0424315e0f6cdaf
 which is part of the recently tagged 0.7.4 release.

Bug#879022: fwupd: FTBFS on alpha and hppa: -fstack-protector not supported

[Mario.Limonciello]

> -Original Message-
> From: Aaron M. Ucko [mailto:u...@debian.org]
> Sent: Wednesday, October 18, 2017 9:47 AM
> To: Debian Bug Tracking System 
> Subject: Bug#879022: fwupd: FTBFS on alpha and hppa: -fstack-protector not
> supported
> 
> Source: fwupd
> Version: 1.0.0-1
> Severity: important
> Justification: fails to build from source (but built successfully in the past)
> User: debian-al...@lists.debian.org
> 
> The latest builds of fwupd for alpha and hppa (admittedly not release
> architectures) failed:
> 
>   cc1: error: -fstack-protector not supported for this target [-Werror]
>   cc1: all warnings being treated as errors
>   ninja: build stopped: subcommand failed.

Yep, on it.  It looks like an option that was intended for CI only was
leaked into a release build.  Those shouldn't have been fatal errors.

> 
> Curiously, meson reports
> 
>   Compiler for C supports argument -fstack-protector-strong: YES
> 
> on both architectures.  Could you please take a look?
> 
> Thanks!
> 

Now this is the weird part.  Why is gcc reporting it's supported?

Bug#874521: 1.0.0

[Mario.Limonciello]

I've uploaded 1.0.0-1 into unstable recently.  Although the patch that was 
submitted didn't work for you on top of 0.9.7, can you please check if the 
problem persists in 1.0.0?  There have been other changes that may affect this. 
 If not, please continue with debugging upstream.

Bug#877991: fwupd: Missing call to dh_systemd

[Mario.Limonciello]

Thanks, added this to upstream packaging.
https://github.com/hughsie/fwupd/commit/a46c01905b9a62c09a4654e86748c7f82d86eed5

Holding off on a new release to unstable until we've got a solution to that 
segfault problem
though.

> -Original Message-
> From: Laurent Bigonville [mailto:bi...@debian.org]
> Sent: Sunday, October 8, 2017 5:15 AM
> To: Debian Bug Tracking System 
> Subject: Bug#877991: fwupd: Missing call to dh_systemd
> 
> Source: fwupd
> Version: 0.7.4-2
> Severity: important
> 
> Hi,
> 
> It seems that fwupd is not calling dh_systemd during the build.
> 
> Even if the .service are statically enabled or dbus activated, calls to
> dh_systemd are still needed to reload systemd or to properly stop the
> services when removing the package.
> 
> Regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'),
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> -- no debconf information

Bug#874521:

[Mario.Limonciello]

So I can't reproduce this.  More details will be needed.  If you can please 
file a bug upstream (https://github.com/hughsie/fwupd/) it would be best for 
upstream to work on solving this.

The following items are needed:


  1.  /usr/lib/fwupd/fwupd -v output
  2.  Information about the hardware you're running on (OEM, model)?
  3.  Is this a notebook?  Are you docked?  What dock?
  4.  Any USB devices that you have plugged in.  Especially interesting is if 
you have a USB Logitech unifying dongle plugged in.
  5.  If you have a Logitech unifying dongle plugged in can you reproduce this 
without it plugged in?

If you can share a core dump, that would be especially useful too.

Thanks,

Bug#874521: fwupd segfaults at start

[Mario.Limonciello]

Is this 100% reproductible for you?

Can you describe more about your machine?

I suspect this is an upstream issue, it may be useful to file it upstream so 
that it can be debugged there.

Sent from VMware Boxer

On Sep 6, 2017 15:27, Laurent Bigonville  wrote:

Package: fwupd
Version: 0.9.7-2
Severity: grave
Justification: renders package unusable

Hi,

fwupd segfaults at start with the following trace:

#0  0x556f337e7dd2 in FU_IS_DEVICE (ptr=0x556f34bdc170) at 
../src/fu-device.h:31
#1  0x556f337e7dd2 in fu_plugin_device_add (plugin=0x556f34bab840 
[FuPlugin], device=0x556f34bdc170) at ../src/fu-plugin.c:317
#2  0x556f337e7eed in fu_plugin_device_add_delay_cb 
(user_data=0x556f34bdedf0, user_data@entry=) at ../src/fu-plugin.c:374
#3  0x7fe839841853 in g_timeout_dispatch 
(source=source@entry=0x556f34bde830, callback=, 
user_data=) at ../../../../glib/gmain.c:4633
#4  0x7fe839840dd5 in g_main_dispatch (context=0x556f34b6c800) at 
../../../../glib/gmain.c:3148
#5  0x7fe839840dd5 in g_main_context_dispatch 
(context=context@entry=0x556f34b6c800) at ../../../../glib/gmain.c:3813
#6  0x7fe8398411a0 in g_main_context_iterate (context=0x556f34b6c800, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../../glib/gmain.c:3886
#7  0x7fe8398414b2 in g_main_loop_run (loop=0x556f34b4edf0) at 
../../../../glib/gmain.c:4082
#8  0x556f337d9dca in main (argc=, argv=) at 
../src/fu-main.c:947

Regards,

Laurent Bigonville

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-rc5-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fwupd depends on:
ii  libappstream-glib8 0.7.1-2
ii  libarchive13   3.2.2-2
ii  libc6  2.24-17
ii  libcolorhug2   1.3.3-2
ii  libdfu10.9.7-2
ii  libefivar1 31-1
ii  libfwup1   9-2
ii  libfwupd1  0.9.7-2
ii  libglib2.0-0   2.53.6-1
ii  libgnutls303.5.15-2
ii  libgpg-error0  1.27-3
ii  libgpgme11 1.9.0-4
ii  libgudev-1.0-0 232-1
ii  libgusb2   0.2.11-1
ii  libpolkit-gobject-1-0  0.113-6
ii  libsmbios2 2.3.1-2
ii  libsoup2.4-1   2.59.90.1-1
ii  libsqlite3-0   3.20.1-1
ii  libuuid1   2.29.2-4

Versions of packages fwupd recommends:
ii  fwupdate  9-2
ii  python3   3.5.3-3

fwupd suggests no packages.

-- no debconf information

Bug#872458: closed by Mario Limonciello <mario.limoncie...@dell.com> (Bug#872458: fixed in fwupd 0.9.7-1)

[Mario.Limonciello]

Hi Chris,
> If this is a commonly-owned directory, perhaps we should add an
> exception to Lintian instead of overriding in leaf packages?

Lintian didn't actually complain.  It was just a common added to 
fwupd-tests.install so
that if another developer is looking at this they can understand why it's where 
it is.
https://github.com/hughsie/fwupd/blob/master/contrib/debian/fwupd-tests.install#L4

Bug#872458: fwupd-tests: Please don't ship test files to generic /usr/share/installed-tests dir

[Mario.Limonciello]

> -Original Message-
> From: Chris Lamb [mailto:la...@debian.org]
> Sent: Thursday, August 17, 2017 11:59 AM
> To: Limonciello, Mario ; 872...@bugs.debian.org
> Subject: Re: Bug#872458: fwupd-tests: Please don't ship test files to generic
> /usr/share/installed-tests dir
> 
> Hi Mario,
> 
> > That's actually how gnome-desktop-testing's installed-tests stuff works.
> > https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
> 
> Ah, didn't know that!
> 
> Fancy adding a quick comment to the package to avoid a potential bug from
> another DD in the future? (Possibly in your .install file?)
> 
> 
> Best wishes,
> 
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Thanks for checking!

https://github.com/hughsie/fwupd/commit/aa20ca2e7abaef09e00a210c8dc79f210954039d
It will be part of the next released version of fwupd (0.9.7)

Thanks,

Bug#872458: fwupd-tests: Please don't ship test files to generic /usr/share/installed-tests dir

[Mario.Limonciello]

Chris,

That's actually how gnome-desktop-testing's installed-tests stuff works.
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests

With the files in that directory like they are it's executed like this:
# gnome-desktop-testing-runner fwupd

> -Original Message-
> From: Chris Lamb [mailto:la...@debian.org]
> Sent: Thursday, August 17, 2017 11:29 AM
> To: sub...@bugs.debian.org
> Subject: Bug#872458: fwupd-tests: Please don't ship test files to generic
> /usr/share/installed-tests dir
> 
> Package: fwupd-tests
> Version: 0.9.6-1
> Severity: minor
> 
> Hi,
> 
> fwupd-tests ships tests in a "/usr/share/installed-tests" dir which sounds
> a little bit too generic. It's unlikely to clash with anything, but browsing
> /usr/share one would not immediately know what this directory is for.
> 
> 
> Regards,
> 
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#853409:

[Mario.Limonciello]

This particular problem is fixed upstream but not yet in a release of fwupdate.
https://github.com/rhboot/fwupdate/commit/cd8f7d79f84155d1dfbff3bb169558a8b06fb719

Bug#868465: Leaves behind /var/cache/app-info/xmls/fwupd.xml

[Mario.Limonciello]

Thanks, I've committed a fix to git.  Will be in next upload.
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=68dd0bf14227aad93d906b2a47a1803be5790191
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=5cdc4900c5fe43575dfc4d7d5b1f8d0a66b7067c


> -Original Message-
> From: Josh Triplett [mailto:j...@joshtriplett.org]
> Sent: Saturday, July 15, 2017 2:04 PM
> To: Debian Bug Tracking System 
> Subject: Bug#868465: Leaves behind /var/cache/app-info/xmls/fwupd.xml
> 
> Source: fwupd
> Version: 0.8.2-2
> Severity: normal
> 
> Purging fwupd leaves behind a file /var/cache/app-info/xmls/fwupd.xml .
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Bug#868464: Leaves behind /var/lib/fwupd/ directory

[Mario.Limonciello]

Thanks, I've committed a fix to git.  Will be in next upload.
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=68dd0bf14227aad93d906b2a47a1803be5790191
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=5cdc4900c5fe43575dfc4d7d5b1f8d0a66b7067c


> -Original Message-
> From: Josh Triplett [mailto:j...@joshtriplett.org]
> Sent: Saturday, July 15, 2017 2:02 PM
> To: Debian Bug Tracking System 
> Subject: Bug#868464: Leaves behind /var/lib/fwupd/ directory
> 
> Source: fwupd
> Version: 0.8.2-2
> Severity: normal
> 
> Purging fwupd leaves behind the following files in /var/lib/fwupd/gnupg:
> 
> total 16
> srwx-- 1 root root0 Jul 15 11:55 S.gpg-agent
> srwx-- 1 root root0 Jul 15 11:55 S.gpg-agent.browser
> srwx-- 1 root root0 Jul 15 11:55 S.gpg-agent.extra
> srwx-- 1 root root0 Jul 15 11:55 S.gpg-agent.ssh
> drwx-- 2 root root 4096 Jul 15 11:55 private-keys-v1.d
> -rw-r--r-- 1 root root  780 Jul 15 11:55 pubring.kbx
> -rw--- 1 root root   32 Jul 15 11:55 pubring.kbx~
> -rw--- 1 root root 1200 Jul 15 11:55 trustdb.gpg
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Bug#868457: fwupd: Upload new 0.9.5 version

[Mario.Limonciello]

s/unstable/experimental/

Sent from VMware Boxer

On Jul 15, 2017 14:46, "Limonciello, Mario"  wrote:
Matthias,

Can you sponsor it to unstable in the meanwhile?
I can't upload it because it has NEW binary package introduced (fwupd-tests).

Sent from VMware Boxer

On Jul 15, 2017 11:30, Matthias Klumpp  wrote:

2017-07-15 18:15 GMT+02:00 Nelson A. de Oliveira :
> Source: fwupd
> Severity: wishlist
>
> Hi!
>
> While I see that version 0.9.5 was tagged almost 10 days ago
> https://anonscm.debian.org/gitweb/?p=uefi/fwupd.git I can't see it
> uploaded to Debian:
>
> $ rmadison fwupd
> fwupd  | 0.7.4-2   | stable | source, amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> fwupd  | 0.8.2-2   | testing| source, amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> fwupd  | 0.8.2-2   | unstable   | source, amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
> fwupd  | 0.8.2-2   | unstable-debug | source
> fwupd  | 0.9.2-6   | experimental   | source, powerpc, s390x
> fwupd  | 0.9.2-6   | experimental-debug | source
> fwupd  | 0.9.4-1   | experimental   | source, amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el
> fwupd  | 0.9.4-1   | experimental-debug | source
>
>
> Nor it's available in NEW https://ftp-master.debian.org/new.html
>
> Maybe you forgot to upload it? :-)

This is blocked on an appstream-glib upload, which is waiting for a
gobject-introspection upload which is waiting for glib to be updated
in unstable.

So this might take a while.

Cheers,
Matthias

Bug#868457: fwupd: Upload new 0.9.5 version

[Mario.Limonciello]

Matthias,

Can you sponsor it to unstable in the meanwhile?
I can't upload it because it has NEW binary package introduced (fwupd-tests).

Sent from VMware Boxer

On Jul 15, 2017 11:30, Matthias Klumpp  wrote:

2017-07-15 18:15 GMT+02:00 Nelson A. de Oliveira :
> Source: fwupd
> Severity: wishlist
>
> Hi!
>
> While I see that version 0.9.5 was tagged almost 10 days ago
> https://anonscm.debian.org/gitweb/?p=uefi/fwupd.git I can't see it
> uploaded to Debian:
>
> $ rmadison fwupd
> fwupd  | 0.7.4-2   | stable | source, amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> fwupd  | 0.8.2-2   | testing| source, amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> fwupd  | 0.8.2-2   | unstable   | source, amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
> fwupd  | 0.8.2-2   | unstable-debug | source
> fwupd  | 0.9.2-6   | experimental   | source, powerpc, s390x
> fwupd  | 0.9.2-6   | experimental-debug | source
> fwupd  | 0.9.4-1   | experimental   | source, amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el
> fwupd  | 0.9.4-1   | experimental-debug | source
>
>
> Nor it's available in NEW https://ftp-master.debian.org/new.html
>
> Maybe you forgot to upload it? :-)

This is blocked on an appstream-glib upload, which is waiting for a
gobject-introspection upload which is waiting for glib to be updated
in unstable.

So this might take a while.

Cheers,
Matthias