Dank Software Depot 1.1.5

• Flatpak updates that libostree refuses are pulled the long way instead.
  libostree 2026.3 caps how large a decompressed delta part may be — a guard
  against decompression bombs, set too low — so an app whose delta crosses it
  cannot be pulled at all: "While pulling app/… from remote flathub:
  Decompressed delta part exceeds configured limit of 67386875 bytes". It is
  a libostree regression, fixed in 2026.4, and by upstream's own account
  nothing Flatpak itself can do about. But the update is fine; only the
  shortcut is broken. An operation that hits the cap is now retried once with
  static deltas switched off — the whole objects instead of the difference,
  more bytes for the same result, which is what flatpak update --no-static-deltas does by hand. Installing takes the same way around it
• Neither the failure nor the retry is reported as a failed update, because it
  is not one. It is said out loud in the event stream, and a row that fails
  for a different reason is still reported the moment it does
• The Flatpak path has tests now, run against a stand-in for libflatpak that
  can fail on cue — the real case needs an app whose delta happens to be big
  enough, which is not something a machine can be asked for

Dank Software Depot 1.1.4

Thanks to @qu33rz for reporting #13.

• Updating system packages on Arch works. The transaction resolved package
  names against the sync databases exactly as they sit on disk, and nothing in
  this plugin ever refreshed them — while the list of pending updates comes
  from checkupdates, which refreshes a private copy of those databases and
  throws it away. So the list was right, the transaction was resolved against
  yesterday's answer, libalpm replied "is up to date -- reinstalling" for every
  package, and the check afterwards correctly reported that nothing had reached
  its new version. The databases are refreshed before a transaction now
• A package already at the version the repositories offer is left alone,
  which is what pacman's own --needed does and what the daemon's pacman -Syu has always used. Those reinstall-the-same-files lines are gone
• A failed refresh — one unreachable mirror — is a reason to attempt the
  transaction with what is on disk, not to refuse it, and the reason travels
  with the result either way
• The Arch path now has a test, run against a stand-in for pyalpm, so it is
  checked on machines that have neither pacman nor Arch — which is every
  machine this plugin is developed on

One thing to know on Arch: updating a single package refreshes the databases
first, which makes it a partial upgrade — the thing Arch tells you not to do.
Update All sends the whole pending list and is the safe path. Arch support is
still marked experimental for reasons like this one.

Dank Software Depot 1.1.3

Thanks to @pdf for both reports.

• "Hide when up to date" works. It never has, for anyone, on any
  distribution: the pill expressed its visibility by binding a host property
  that the host only reads when the plugin also supplies a shell command to
  decide visibility — and with none supplied, the host assigns that property
  itself, destroying the binding. The pill now tells the host directly (#12)
• The readiness banner is about your package manager. On Arch, the first
  window after a boot could carry a banner headed "pyalpm could not be loaded"
  over a line about python3-libdnf5, on a machine with pyalpm installed. The
  check runs at startup while the backend is still assumed to be dnf, and the
  re-check that follows once /etc/os-release has been read was being dropped
  rather than deferred, because the first one was still running. The same
  fault could also hide a genuinely missing binding, when the wrong probe
  happened to succeed. Atomic Fedora was affected by the same race (#11)
• A package that fails with nothing to show for it now shows something.
  When the update service reports a pass as clean and the packages are not
  there, it hands over no error — so the details panel was empty. The last of
  what the service said goes in there instead

Dank Software Depot 1.1.2

A log entry saying three packages over a list of thirty-seven, thirty-four of
them marked unfinished while every one was on disk. Two faults, both of them
in the commit that was supposed to have fixed this in 1.1.0.

• The replay that heals a torn-down run asked the wrong question. After a
  DMS update reloads the shell, the entry is written again and checked against
  the package database. That check was widened to cover every row the run did
  not see finish — but the list of names actually sent to the database still
  only collected the rows that had failed. So the pending rows were healed
  against an answer nobody had asked for, and stayed pending forever
• The log was written before the verification could answer. A run ends by
  moving every system and Flatpak row into "confirming", starting the pass
  that checks the packages are really no longer offered, and then emitting
  finished — which is where the log entry was written. It recorded that
  moment: a grey clock next to a package that installed perfectly, on any run
  at all, no shell reload needed. The entry now waits for the answer, which
  also means a package the check still finds pending arrives in the log as the
  failure it is rather than as a success
• Existing entries are not rewritten automatically — a log is a record, and
  this one silently repairing itself is a worse habit than the bug. If yours
  has grey clocks on packages you know landed, they are wrong about the past
  and right from here on

Dank Software Depot 1.1.1

Thanks to @kmf for reporting #10.

• Homebrew formulae no longer call themselves system packages. One mapping
  from a row to the name of its source had been written out in four places,
  each copy with a different hole in it: the update card knew Flatpak and DMS
  plugins, the action log knew four kinds, the details popup knew three, and
  none of them knew Homebrew. Everything that fell through said System — so
  AppImage and firmware rows were quietly saying it too. There is one now,
  used by all four
• The details popup for a formula stops asking the system about it. It was
  offering a dnf source for something that lives in brew's own prefix, and
  asking the package manager for the changelog of a package it never installed
  — which is what left Loading changelog… on screen for good. It is filled
  from brew instead: version, licence, homepage, dependencies and installs
  last month, the same panel the Install tab shows
• Rows are named by the name meant to be read, so the list no longer says
  charmbracelet/tap/crush where the popup one click away says crush
• The source chip is gone where the heading above already says it — under
  System packages, Firmware, Homebrew and DMS plugins it was the heading again
  in smaller type. It stays under Applications, which holds Flatpaks and
  AppImages together, under Held, which holds anything, and during a run,
  where the groups are In progress and Waiting and the chip is the only thing
  saying what a row is
• Section headings stay put while you scroll, in all four lists: which
  group you are in, which day of the log you have reached, which storefront
  category you are hundreds of rows into. Worth more now that the rows beneath
  a heading no longer each repeat it
• The bug report form has boxes for Homebrew and DMS plugins, which is why
  #10 arrived with none of them ticked

Dank Software Depot 1.1.0

Homebrew becomes somewhere you install from, not only a section that gets
updated — and with it the round of corrections that a day of actually using
1.0.0 turned up.

• Install from Homebrew. Brew joins the Install tab the way Copr did,
  because it poses the same question: a catalogue this machine keeps and this
  storefront does not index. So it is one deliberate press at the end of the
  results rather than a search per keystroke, and only where brew exists. The
  search goes through brew's own copy of the index rather than fetching the
  30 MB document again; opening a result shows what brew knows — version,
  licence, homepage, dependencies, and how often it was installed in the last
  thirty days, from Homebrew's own analytics. Homebrew grew up on macOS,
  and its core still carries formulae that cannot run here: those are listed
  greyed with the reason rather than dropped, because "this exists, but not
  for you" is an answer and silently returning nothing is not
• A Homebrew chip in the Install tab's filter, next to the Copr one, each
  appearing only on a machine where it means anything. Picking one narrows the
  offer to search elsewhere along with it — an offer whose results the current
  filter would throw away is worse than no offer
• The stepper stops running ahead of the work. During the Flatpak phase it
  would move to Install while rows underneath were still counting up download
  percentages: several refs install at once, and the first to get there moved
  the whole stepper. It is a statement about all of them now. The DMS package
  pass no longer reads as Install through the minutes it spends downloading,
  and the AppImage phase no longer reads as Download while it writes the
  desktop entry. Firmware, Homebrew and the plugin pass are deliberately left
  as they were: a step that is wrong in a new way is not an improvement on one
  that is wrong in a known way
• The strips on the Updates tab moved below the tab bar. Pending updates,
  a manual pass, end-of-life components, a newer Fedora, unread Arch news —
  all five used to push the tabs down as they appeared and let them spring
  back when you switched tab, which is precisely when you are aiming at one.
  The header and the reboot banner stay above, because the reboot notice is
  true wherever you are
• Update All lands at the top of the list, instead of somewhere in the
  middle of it: the jump ran in the same instant the dashboard header left and
  the run's own rows arrived, so the content moved out from under it
• Progress bars stop replaying finished downloads. A card scrolled back
  into view animated its bar from zero again, which is what made scrolling
  during a run feel busy
• The log tells three outcomes apart. A row that never finished is drawn
  as unfinished rather than as a success — an entry could say "2 packages
  updated" over three green ticks. Behind that: the replay that runs after a
  DMS update reloads the shell now re-checks every row it did not see finish,
  not only the ones it saw fail, so a package that went in during the reload
  stops being pending forever; and it can no longer write an entry with
  nothing in it
• The item-count chip is gone from the right of every log entry. It
  repeated the number already in the title, and on the entries where it did
  not, what it had to say was one click away in the entry itself

Dank Software Depot 1.0.0

1.0.0 is where the numbering arrived, not a claim that this is finished.
It is the same software as 0.9.9 with Homebrew added; it is still in beta, it
still changes quickly, and the status section of the README still says so. If
you were waiting for a version number to mean "safe now", keep waiting — what
it means is that thirty-five releases came before this one, the first of them
on 5 August, a fortnight ago.

Thanks to @kmf for asking for Homebrew.

• Homebrew support. On a machine that has brew, its formulae are a kind of
  software this window manages: their own section in Updates, their own group
  and filter in Installed, a line on the dashboard's installed-software card,
  a place in the bar pill's count, and their own phase in Update All. Brew
  needs no privileges, so this asks for nothing — no password, no polkit, no
  daemon. It reports no machine-readable progress either, so a formula goes
  from active to done rather than filling up, and the phase says out loud that
  a formula without a bottle is compiled from source and can take a while. A
  pinned formula is brew's word for held and is left alone. brew update is a
  git fetch, so the formula index is refreshed at most every six hours rather
  than on every check.

  Tested against a real Homebrew, in a basic setup: installed, a formula
  taken from one version to the next, upgraded through this window, confirmed
  by brew as no longer outdated. That is the extent of it — the author does
  not run Homebrew day to day, so nothing here has met a large installation,
  a machine that leans on taps, or a formula that takes twenty minutes to
  compile. If you do run brew and something reads wrong, the issue tracker is
  the fastest way to have it fixed.

• The phase stepper stays for its own last two steps. Verify and Done were
  both on the stepper and neither was ever on screen: the panel around it hid
  itself during verification, and the stepper hid itself once the run was
  done.

• A result card that clears itself says so first. A finished run with
  nothing to report clears its panel after a few seconds; a line now runs out
  along the bottom edge for exactly that long, so the card leaving is
  something you watched approach. It does not count down when the panel is
  staying — during a run, or after one with a failure to report.

Dank Software Depot 0.9.9

• Three numbers for one thing, and two of them wrong. The header counted a
  package the daemon names twice — it does that when two enabled repositories
  carry the same one — while the list below it had always collapsed those. And
  the transaction line counted both halves of every upgrade, since libdnf5
  resolves one into the new package arriving and the old one being replaced:
  three updates were summarised as six packages. All three places agree now.
• The up-to-date mark, the DMS penguin and the pulse follow the theme. The
  mark was the only green thing on a dashboard that is otherwise the accent,
  the penguin the only untinted one, and the pulse was drawn in two colours,
  which made one wave read as two marks chasing each other. A failed check
  keeps its red, where the colour is the message. Light mode is unchanged
  there: the disc behind the mark is already the accent, with the mark white
  on top of it.
• Buttons that are the only thing to do no longer look like the second
  choice. Open, Write a review, the two at the foot of the settings dialog
  and the one that opens this window from DMS Settings all wore the muted tone
  this app uses for the alternative in a pair. They take the accent, which
  also means they follow the button-colour setting. What keeps the muted tone
  is the alternative install source, where it means what it says.
• App icons are tinted with the theme colour by default. The switch stays
  for anyone who prefers each app's own artwork; turning it off keeps it off.
• Smaller things. The Recently updated card no longer labels every row
  with where it came from — the log answers that per entry, in a view built
  for it. A plugin's "Manage plugins" button moved out of the middle of the
  facts it was interrupting, to the row of actions at the bottom.

Dank Software Depot 0.9.8

Thanks to @BadLemon5267 for catching the first one within a day of it going
out.

• Fixes 0.9.7, which could not be enabled at all on DMS 1.5.x. The window
  was rebuilt on DankFloatingWindow, which is what DMS uses for its own
  windows — and which arrived upstream after 1.5.3. A QML file naming a type
  that does not exist does not fall back to something simpler; it fails to
  load, and takes the widget and the whole plugin with it. The window asks for
  the colour by name again instead of inheriting the component that has it,
  and falls back to the tone that colour is derived from where it is missing.
  The background still matches DMS on a shell that is new enough to have one
  to match.
• One password per update run. A run carrying DMS's own packages asked
  twice, which is why it seemed to come and go: the ordinary packages go
  through a helper under pkexec and the DMS ones through the daemon, because
  that transaction has to outlive the shell reload it causes, and those are
  two different polkit actions. When the shell's packages are in a run, all
  system packages now travel with them in that single daemon transaction.
  Runs without them are unchanged and were never the ones asking twice.
• The up-to-date mark and the DMS penguin follow the theme instead of
  being the only green and the only untinted thing on the dashboard. A failed
  check keeps its red, where the colour is the message.

Dank Software Depot 0.9.7

Thanks to @gitblit for the report and the screenshot behind this one.

• The window uses the theme's own background, like the rest of DMS. It
  reacted to theme changes and stayed within the spirit of the palette, but it
  painted a surface of its own choosing, which read as slightly out of place
  next to DMS Settings. It is now built on the same floating window the shell
  uses for its own: the same background tone, the same rounded corners, the
  blur behind it, and the border the shell gives every floating window. It
  also follows the floating-window transparency setting, which it used to be
  deaf to.