Refresh hangs indefinitely, appstreamcli using 100% CPU

Bug #1579712 reported by Matthias Klumpp on 2016-05-09
This bug affects 299 people
Affects Status Importance Assigned to Milestone
appstream (Ubuntu)
Matthias Klumpp

Bug Description


 * The cache refresh is blocked on a strdup on a non-NULL-terminated string in some very rare occasions (very rare because this bug is present for almost 3y without a single report).
 * Fixing this bug resolves the issue for people who might experience it.
 * See for details.

[Test Case 1]

 * Run `sudo appstreamcli refresh --force`
 * The AppStream cache should be updated, no change in behavior should be seen.

[Test Case 2]

 * In case you were experiencing the almost-infinite hang when running `sudo appstreamcli refresh --force`, this issue should be fixed with the SRU.

[Regression Potential]

 * Very low, since this only fixes the decompression code. There should be no sideeffects of that (given that the patch itself doesn't break anything, which it shouldn't, since it has been tested upstream for a while)

[Other Info]

 * This fix has been applied upstream:
 * A smaller version of the patch (one-liner) is available, at the expense of not having reduced memory usage:


/!\ Installing the bugfix from xenial-proposed, without going through APT:
To install the fixed packages manually, please execute the following commands (for amd64, adjust URLs for other architectures):

cd /tmp && mkdir asfix
cd asfix
sudo dpkg -i libappstream3*.deb
sudo dpkg -i appstream*.deb

Matthias Klumpp (ximion) wrote :

Hmm, since LP doesn't allow me to add the upstream bug URL directly:

Matthias Klumpp (ximion) on 2016-05-09
description: updated
Matthias Klumpp (ximion) wrote :

Patch for this issue, together with the fix for LP: #1574896

The attachment "Fix for LP#1574896 and LP#1579712" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Iain Lane (laney) wrote :

I uploaded it - could you please upload to Debian too so that yakkety gets this fix?

Matthias Klumpp (ximion) wrote :

This will be in the upcoming 0.9.6 release, which I will release this week. So Debian (and Yakkety) will have it very soon.

Neil Mayhew (neil.mayhew) wrote :

I would really like to see this go through as an SRU to Xenial. I am hitting a problem with my third-party repo 100% of the time. When I have the repo enabled, apt-get update hangs indefinitely when it runs appstreamcli at the end, and I assume all of the users of my repo are experiencing the same problem. With a package built using the debdiff given here, apt-get and appstreamcli run just fine.

If the size of the changes here are a problem, the one-liner mentioned above would be sufficient for me.

Hello Matthias, or anyone else affected,

Accepted appstream into xenial-proposed. The package will build now and be available at in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at . Thank you in advance!

Changed in appstream (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed

@Laney: Debian has the fix too now, included in the 0.9.6 release which should show up in Yakkety soonish.

Mathew Hodson (mhodson) on 2016-05-12
Changed in appstream (Ubuntu Xenial):
importance: Undecided → Medium
milestone: none → xenial-updates
Changed in appstream (Ubuntu):
milestone: xenial-updates → none
Matthias Klumpp (ximion) wrote :

This issue is resolved in Yakkety, nedds fixing in Xenial still.

The patch in -proposed resolves this issue for me.

Changed in appstream (Ubuntu):
status: Fix Committed → Fix Released
Neil Mayhew (neil.mayhew) wrote :

Sorry to be slow in responding. I thought I was subscribed but wasn't.

The version from -proposed (0.9.4-1ubuntu1) resolves this issue for me.

Thanks! Great to have this.

tags: added: verification-done
removed: verification-needed
Peter Bennett (pgbennett) wrote :

I find it is not possible to use "software and updates" to enable proposed or to install the fix because every repository related action results in a hang with appstreamcli using 100% CPU.

Peter Bennett (pgbennett) wrote :

Can somebody post a URL where I can download the proposed package directly as I cannot install it using apt-get, which hangs because of this bug. I am using amd64 xenial.

Grant (granta) wrote :

Like Peter in #11, I cannot enable proposed because appstreamcli is hanging on every single run. Any invocation of appstreamcli or apt update gets stuck.

Jacob Taylor (orangewinds) wrote :

I have appstream 0.9.4-1 installed and every time it is run (automatically, not by me) it spikes cpu to 100%. I cannot even purge and reinstall it, because it is run during the setup phase (to force a new index) which pegs the cpu. Is 0.9.4-1 supposed to be ~= 0.9.6 of upstream?

Eduardo (ludentico) wrote :

Neither can I install any update, even after disabling third-party repositories.

appstreamcli hangs refreshing with 100% cpu use

apt update hangs after 'Fetched XXX kb in Xs (XXX kb/s)'

John Wang (johnwang) wrote :


I'm not sure how to discover which particular repo is causing appstreamcli to hang, so you could try disabling *all* your third party repos then update. Or disable them one-by-one, but that could be tedious.

strav (strav) wrote :

Peter, the package can be found at: (as previously posted) but I'm kinda at a loss here: dpkg -i launches appstreamcli when setting up the package which results in me not being able to install it so far.

Eduardo (ludentico) wrote :

Removing appstreamcli seems to do the trick. I'm not aware of side effects

sudo rm /usr/bin/appstreamcli


John Wang (johnwang) wrote :

@ludentico: Never `rm` files without also removing the package they belong to.

I discovered a workaround:

$ sudo mv 50appstream 50appstream.disabled
$ sudo apt-get update
$ ... [do what you need here] ...
$ sudo 50appstream.disabled 50appstream

John Wang (johnwang) wrote :

That last command should have been:

$ sudo mv 50appstream.disabled 50appstream

strav (strav) wrote :

Disabled all my repositories by commenting out everything in /etc/apt/sources.list and moving everything out of /etc/apt/sources.list.d; it did the trick: could update appstream from proposed repository. Thanks!

Eduardo (ludentico) wrote :


I guess you meant

$ sudo mv /etc/apt/apt.conf.d/50appstream /etc/apt/apt.conf.d/50appstream.disabled

John Wang (johnwang) wrote :

Okay, I've successfully upgraded to appstream 0.9.4-1ubuntu1 from the -proposed repo, but subsequent `sudo apt-get update` invocations still hang on appstreamcli. I have no idea what to do now.

@ludentico: Yes, sorry, I was in a hurry and didn't include full paths.

Matthias Klumpp (ximion) wrote :

Weird, I wonder what happened that many people are experiencing this now...
Removing `/usr/bin/appstreamcli` is fine if you install the fixed package afterwards.

To install this manually, please do (for amd64, adjust URLs for other architectures):

cd /tmp && mkdir asfix
cd asfix
sudo dpkg -i *.deb

This should solve the issue. Please report back if this is fixed, or if you are still experiencing issues!

Matthias Klumpp (ximion) wrote :

@John Wang: Did you also update libappstream3? Because that's where the bug actually is ;-)

Tomas Caram (tomich) wrote :

Downloading and installing deb fixed it for me. Thanks!.

I tried to update after a fresh install and could not get past the appstreamcli infinite 100% processor utilization:

My laptop got almost smoking hot before I finally killed the appstreamcli process!

Updated appstream & libappstream3 to version 0.9.4-1ubuntu1, and libappstream-glib8 to 0.5.13-1ubuntu1 just in case... Fixed for me. Thanks you!

Matthias Klumpp (ximion) wrote :

@Lonnie: this is the same bug. Install the package via dpkg as described in post #24, that should solve the 100% CPU issue too - the issue manifests itself in some very interesting ways sometimes.

Changed in appstream (Ubuntu):
assignee: nobody → Matthias Klumpp (ximion)
John Wang (johnwang) wrote :

@ximion: I missed that. After upgrading libappstream3 from -proposed, everything works fine. Thanks.

The reason I warned against removing the binary is because it's a bad practice in general, even though in this particular problem scenario the removed binary gets restored when its package is upgraded. Package-managed files should only be removed as a last resort when there isn't a better/safer workaround that won't potentially leave any part of the system in a broken or inconsistent state at any point in time. In this case, a safe workaround does exist, which is to disable appstream's apt config in the canonically-prescribed manner: appending ".disabled" to the config's filename.

So the complete procedure to fix this safely would be:

$ sudo mv /etc/apt/apt.conf.d/50appstream /etc/apt/apt.conf.d/50appstream.disabled
$ cd /tmp && mkdir asfix
$ cd asfix
$ wget
$ wget
$ sudo dpkg -i *.deb
$ sudo mv /etc/apt/apt.conf.d/50appstream.disabled /etc/apt/apt.conf.d/50appstream

Thanks. "Medium" importance for this bug? This seems like the most critical bug I've ever encountered, considering that if I had left my laptop alone to "finish updating" it might have melted and caused a forest fire before I got back :)

Yeah, I think this one deserves a critical status; the fix needs to be in the main repo ASAP.

Todd Bossaller (teche70) wrote :

I ran the fix Matthias mentioned in post #24 and it fixed my issue.

Chuck Burgess (ashnazg) wrote :

+1 on Matthias' instructions on installing the patches ( this fixed the issue for me.

John Wang (johnwang) wrote :

In comment #30 I took the procedure from comment #24 and added two commands to rename appstream's apt config file, but those commands aren't necessary because they have no effect when appstream is installed via the `dpkg` command.

The appstream package's postinst file explicitly calls `appstreamcli refresh-index --force`, so reported in comment #17, the hanging problem is probably still present even when `dpkg` is used to upgrade the appstream packages instead of apt. In that case, upgrading the libappstream3 package *before* the appstream package may avoid the hanging.

Trent V. (shadyatv) wrote :

Matthias post #24
worked for me also thank you!

Brett Bogert (bbogert24) wrote :

Folks, Updates had been working fine for me until today (5/19/2016).

I updated my machines last night(all 11 of them) and now all are
experiencing the aforementioned problem with 100% CPU usage from

It appears that in my case at least that something applied last
night must be triggering the problem as I have had no problems
with apt update until today.

I was able to "Ctrl C" out of the update command and install
some updates but have to "assume" that I had gotten them all
since the update command never completed.

I will try and get the above fix applied to at least some of my
machines tomorrow.

How will users be able to apply the fix if they can't get past
the apt update command hanging (other than manual intervention
that is)?


Matthias Klumpp (ximion) wrote :

I think a high priority is the better fit now, since this - for some reason - started to hit more users than expected now, and the manifestations of this bug are very annoying. It doesn't cause data loss or is a critical security issue though.

Changed in appstream (Ubuntu Xenial):
importance: Medium → High
Matthias Klumpp (ximion) wrote :

@Brett: When the AppStream cache update is triggered, the APT cache is updated, so updates will still be installed. Ideally, the fixed package is shipped via x-updates soon, so no more people get trapped.
SRU verification is done at least, and we now have more than enough people confirming the bugfix :)

kimr (reivanen-gmail) wrote :

Today i woke up to my server's cpu fan going at full speed. Puzzled by this i check my virtualbox machines and notice my ubuntu 16.04 installation has appstream stuck at 100% on one core. This has not happened before.

Goddard (kinggoddard) wrote :

This runs up my CPU on Kubuntu... appstreamcli was using 13% cpu.

Also hit by this. And unable to manually install the deb, even after rm /usr/bin/appstreamcli

Preparing to unpack appstream_0.9.4-1ubuntu1_amd64.deb ...
Unpacking appstream (0.9.4-1ubuntu1) over (0.9.4-1ubuntu1) ...
Setting up appstream (0.9.4-1ubuntu1) ...

CPU stuck at 100%

John Wang (johnwang) wrote :

@dsfkljo322332: Are you using dpkg to install the upgrades? Try upgrading the libappstream3 package first, then the appstream package.

My bad. I forgot to install libappstream3_0.9.4-1ubuntu1_amd64.deb

installing libappstream3_0.9.4-1ubuntu1_amd64.deb wtih dpkg first did fix the problem. I think I was using gdebi. Does this bug break gdebi somehow?

Goddard (kinggoddard) wrote :

sudo apt remove appstream works for me, but plasma-discover depends on it so it is also removed. Lucky for me I didn't really use that any way.

John Wang (johnwang) wrote :

@dsfkljo322332: This bug affects upgrades via apt as well as dpkg. Gdebi uses one of those on the back end, not sure which. See comment #34 and #30 for more details.

Matthias Klumpp (ximion) on 2016-05-20
summary: - Refresh hangs due to strdup on non-NULL terminated string
+ Refresh hangs indefinitely, appstreamcli using 100% CPU
description: updated
Matthias Klumpp (ximion) wrote :

I made the summary less technical, so maybe fewer duplicates of this get reported when people go through the bug list. I also added instructions on how to fix this immediately without removing packages or moving config files around to the bug description, so people who find this bug don't need to read the whole thread to get their machines working properly again.

Hélio Nunes (dedalu-dedalu) wrote :

Matthias' #24 workaround works for me. Thank you. But how the amateur, non-technical, regular user of a !!!LTS!!! release will deal with this bug? Fixed for me and for (lets see) 300 users... and the others?

Deep Kumar Halwai (kumar981) wrote :

As per Matthias' comment #24, deleting the rm /usr/bin/appstreamcli and installing the .deb packages worked for me as well.

Thank you Matthias'

Boenadi Agustian (boenadi) wrote :

As per Matthias' comment #24, not working for i386

Boenadi Agustian (boenadi) wrote :

As per Matthias' comment #24, not working for i386 all package for i386 still get stuck and appstreamcli get 100%

Edwin Khoo (edwinksl) wrote :

This bug appears to also affect clean 16.04 installs as of today. Specifically, the installer gets stuck at "Retrieving file 56 of 56".

Set Hallstrom (sakrecoer) wrote :

Might be completely unrelated, but i noticed most mirrors have this weird loop:

i write "most", but I haven't yet found any mirror that hasn't got it.

Dennis W. (dennisw50-300) wrote :

i had problems today to make "sudo apt update" it don't went away so that i can got "sudo apt dist-upgrade"

i can terminate appstreamcli in system-monitor but that loading not all packets

This fix has "repaired" the Problem, i quete the #24

After this working there came any Pakets it wont's to have install, is that normally and or regulate Updates ?

"Weird, I wonder what happened that many people are experiencing this now...
Removing `/usr/bin/appstreamcli` is fine if you install the fixed package afterwards.

To install this manually, please do (for amd64, adjust URLs for other architectures):

cd /tmp && mkdir asfix
cd asfix
sudo dpkg -i *.deb

This should solve the issue. Please report back if this is fixed, or if you are still experiencing issues!"

Neil Mayhew (neil.mayhew) wrote :

The simplest workaround seems to be to use Ctrl-C when apt update hangs at the end. It's already done most of the work, and this just aborts the running of appstreamcli at the end. You can then go ahead and update any binary packages built from the appstream source package (ie any of appstream appstream-doc appstream-index gir1.2-appstream libappstream-dev libappstream3 libappstreamqt-dev libappstreamqt1 that are already installed). The use of appstreamcli in the postinst shouldn't hang because the new versions of appstreamcli and will already be in place.

However, using Ctrl-C is possible only when using the command line. I'm not sure what happens if someone is using Synaptic or Gnome Software. I assume it would be necessary to use System Monitor to kill off appstreamcli. I'm concerned that we could see breakage in a very large number of Xenial installations, all of which would require manual intervention to get them unstuck.

The fact that this is happening now, when it hasn't been reported in the past 3 years, must be due to a subtle change in the execution environment, maybe due to updates in other shared libraries that appstreamcli uses. The problem is a result of reading uninitialized memory, and in the past it must have been pure luck that the memory always contained zeroes.

Olli Niemi (olliniem) wrote :

I'm running Ubuntu Gnome and the user experience is horrible with this bug when using the UI: "Software Updater" has "X" and "Stop" buttons: "Stop" button stays gray (inactive) during the update (what is the point of having gray Stop buttons?). It is even worse if the user (such as me) tried to change the repository, thinking there might be something wrong with that: "Software & Updates" -> "Ubuntu Software" -> "Download from:" [select your mirror] -> "Choose Server" -> "Close". Then there is the notification "The information about available software is out-of-date" -> "Reload". And the result: forever inactive window with no possibility to interfere.

I don't know how this is handled by the UI in the regular Ubuntu but this case seems to be a good test case for user interaction.

Mikko Niemelä (fatordee) wrote :

I was able to resolve the problem by disabling backports, it allowed me to do apt-get update which previously hanged up.

Stefan Leitner (s-o-l) wrote :

Disabling the xenial-backports is working for me to! Thanks Mikko Niemelä!

I really wonder how unexperienced user will deal with that problem!

fubuntu (ejmhw1ui57c6fgdo) wrote :

It took quite some time for me to find this solution. When the average user starts googling this, they are going to find all sorts of things which do not apply, for example:

What a nightmare! This demonstrates why the system update utility needs to include a twitter-type client to inform the user of emerging issues related to broken update functionality. How else will the average user cope with a new issue like this, when there are so many possible causes for the same type of problem?

Yes I know, it poses the question of who should have the authority to broadcast alerts. Perhaps a majority vote by a jury of lead developers or team managers who could activate the feature by signing a proposed broadcast message with their PGP key. Moderators of the forum or the bug tracker would then submit proposals for broadcast messages to a mailing list that goes to the jury. This would eliminate the possibility of using the broadcast system for spam.

In any case, the manual fix in the description is not sufficiently clear: many people who are capable of typing terminal commands will not know to replace 'amd64' with 'i386' or whatever is appropriate. A script which automates this might be a better solution.


> I'm not sure what happens if someone is using Synaptic or Gnome Software. I assume it would be necessary to use System Monitor to kill off appstreamcli.


> forever inactive window with no possibility to interfere

Best quick recovery method is to launch 'top' in terminal & kill that process ID. It does affect Software Center, Software Updater, adding PPA's, et cetera.

kajhaul (kaj-haulrich) wrote :

For some reason Kubuntu users seems able to run 'Update Manager' without the 100% CPU issue. Otherwise I agree: this bug is a showstopper for the average (non-geek) user.

kimr (reivanen-gmail) wrote :

Disabling the xenial-backports solves the issue for me. Take note to not reload the package list when the software&updates asks you to, as it will hang.

RH (rh-t) wrote :

+1 the updated package posted by Matthias is working for me denial 16.04 xubuntu.

doekia (doekia) wrote :

Too my lap was burning due this bug

Solution in post #30 was the only way to fix the issue for me.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package appstream - 0.9.4-1ubuntu1

appstream (0.9.4-1ubuntu1) xenial; urgency=medium

  * iconfinding-refactor.patch: Fix double-free corruption which
    happens with certain metadata. (LP: #1574896)
  * fix-decompression.patch: Fix hang when refreshing the metadata
    cache. (LP: #1579712)

 -- Matthias Klumpp <email address hidden> Tue, 26 Apr 2016 10:18:14 +0200

Changed in appstream (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for appstream has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Me (wmsopou) wrote :

#24 worked for me BUT with the addition of removing leftover lock files first:

sudo rm /var/lib/dpkg/lock
sudo rm /var/cache/apt/archives/lock

Dangerous if anything apt related still running - but I think a lot of people will CTRL-C their way out of "apt-get update" of somehow try to kill a hung update-manager.

ianrumford (p-ian-s) wrote :

#24 worked for me. Thanks to all.

HarzG (harzg) wrote :

#56 & #60: Thanks Mikko & kimr - Disabling the xenial-backports is working for me to.
In a 16.04 live-system backports are disabled. By a fresh install of 16.04 backports are ENabled?
This is not an "user issue" because a lot of users never changed the backports ON/OFF.
It's a showstopper for 16.04 LTS.

Will Cooke (willcooke) wrote :

If you've experienced this issue today (20 May 2016) then it should now be fixed in the archives. Please allow a little time for the changes to replicate around. You can then re-enable backports if you wish.

Maik (maik-lindner) wrote :

#24 worked for me. thanks matthias!

Arup (arup-chowdhury) wrote :

The big issue here is that fresh installs all hang due to this error. How do we get past that? Would an updated installation package be issued by Canonical to fix this?

Matthew Ames (supermatt) wrote :

Following on for #70, one cannot install new packages for appstream if the packages cannot be refreshed. What will be done to advise users how to get around this problem. Finding this bug report was more luck than skill.

Will Cooke (willcooke) wrote :

The issue causing the refresh to hang is fixed in the archive, so everyone should be able to upgrade without problem.

Oliver Leitner (shadow333) wrote :

i can confirm this being present in xenial.

it seems to correlate with a system hard reset, maybe that system hard reset breaks the "database" behind the program? any way to have it autocheck for integrity every n loads or after a hard reset?

Jacob Taylor (orangewinds) wrote :

I can confirm the steps in comment 24 fixed the issue. Thanks!

(and now everyone waits for uplift from -proposed)

Greg (gregrobinz) wrote :

I can also confirm that comment 24 has fixed the issue for me. Thanks All

In order to install IBM SPSS, I had to install "libstdc++5" package. I noticed this bug was happening after installing this package and IBM SPSS. After removing libstdc++5 (not required to use IBM SPSS, just to install it), I didn't experience this bug. However, this all happened in last two days, so it could be that Ubuntu updates fixed the issue.

information type: Public → Public Security
information type: Public Security → Public
Fredrik Staxäng (fstx01) wrote :

I got this when I tried to update today. This fixed it for me:

sudo pkill appstreamcli
sudo rm /usr/bin/appstreamcli

Then the updates worked, and a new /usr/bin/appstreamcli got installed.

Poldi (poldi) wrote :

I can also confirm that comment 24 has fixed the issue for me.

Usievaład Kimajeŭ (anibyl) wrote :

For me issue was fixed by mixing comments #77 and #24.

PS: can hardly imagine that such bugs live on stable channel :\

Nader Aeinehchi (nader-f) wrote :

I had the same problem in a fresh copy of Ubuntu 16.04 running as a VMWare Guest.

I followed the instructions as #24. Everything works now. Thanks a lot for the instructions.

Neil Mayhew (neil.mayhew) wrote :

@nader-f: You're probably using an out-of-date ISO for your VM. This issue was fixed in 16.04 a long time ago. Be sure to use the 16.04.1 ISO and not the original 16.04 ISO in the future. The [change summary for 16.04.1][1] specifically mentions this bug as having been fixed.


vigilian (vigilian) wrote :
Download full text (5.1 KiB)

even with the fix on my production server I still have some problems. :

@docker:~$ sudo apt update
[sudo] Mot de passe de vigilian :
Atteint:1 xenial InRelease
Atteint:2 xenial InRelease
Réception de:3 xenial-updates InRelease [102 kB]
Atteint:4 xenial InRelease
Réception de:5 xenial-backports InRelease [102 kB]
Atteint:6 ubuntu-xenial InRelease
Réception de:7 xenial-updates/main amd64 Packages [441 kB]
Réception de:8 xenial-updates/main i386 Packages [433 kB]
Réception de:9 xenial-updates/main amd64 DEP-11 Metadata [303 kB]
Réception de:10 xenial-updates/main DEP-11 64x64 Icons [186 kB]
Réception de:11 xenial-updates/universe amd64 DEP-11 Metadata [121 kB]
Réception de:12 xenial-updates/universe DEP-11 64x64 Icons [145 kB]
Réception de:13 xenial-updates/multiverse amd64 DEP-11 Metadata [2.516 B]
Réception de:14 xenial-backports/main amd64 DEP-11 Metadata [208 B]
Réception de:15 xenial-backports/universe amd64 DEP-11 Metadata [212 B]
Réception de:16 xenial-backports/multiverse amd64 DEP-11 Metadata [212 B]
Réception de:17 xenial InRelease [3.651 B]
Réception de:18 xenial-security InRelease [102 kB]
Réception de:19 xenial-security/main amd64 DEP-11 Metadata [68,2 kB]
Réception de:20 xenial-security/main DEP-11 64x64 Icons [48,0 kB]
Réception de:21 xenial-security/universe amd64 DEP-11 Metadata [19,4 kB]
Réception de:22 xenial-security/universe DEP-11 64x64 Icons [25,6 kB]
Réception de:23 xenial-security/multiverse amd64 DEP-11 Metadata [212 B]
2.103 ko réceptionnés en 5s (392 ko/s)
AppStream cache update completed, but some metadata was ignored due to errors.
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
All packages are up to date.
W: Signature by key 09D6EF97BFB38E916EF060E756A3DEF863961D39 uses weak ...


vigilian (vigilian) wrote :

vigilian@docker:/tmp/asfix$ sudo dpkg -i *.deb
(Lecture de la base de données... 234098 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de appstream_0.9.4-1ubuntu1_amd64.deb ...
Dépaquetage de appstream (0.9.4-1ubuntu1) sur (0.9.4-1ubuntu1) ...
Préparation du dépaquetage de libappstream3_0.9.4-1ubuntu1_amd64.deb ...
Dépaquetage de libappstream3:amd64 (0.9.4-1ubuntu1) sur (0.9.4-1ubuntu1) ...
Paramétrage de libappstream3:amd64 (0.9.4-1ubuntu1) ...
Paramétrage de appstream (0.9.4-1ubuntu1) ...
AppStream cache update completed, but some metadata was ignored due to errors.
Traitement des actions différées (« triggers ») pour man-db (2.7.5-1) ...
Traitement des actions différées (« triggers ») pour libc-bin (2.23-0ubuntu5) ...
vigilian@docker:/tmp/asfix$ sudo appstreamcli refresh --force
AppStream cache update completed, but some metadata was ignored due to errors.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers