mini-buildd (2.3.1) unstable; urgency=medium

  With 2.2.x, mini-buildd no longer uses ``numix-icon-theme``
  but provides a custom icon theme (in
  ``/usr/lib/python3/dist-packages/mini_buildd/static/icons``).

  Until version 2.2.2, this change was not properly handled,
  causing the symlink to just stay and the new custom icon
  theme to be installed to the ``numix-icon-theme`` package
  path on upgrade.

  Version 2.2.2 fixes this. However, if you had 2.2.0|1 installed
  previously, you may end with cruft files in
  ``/usr/share/icons/Numix/32`` that will not be handled by dpkg.

  You may want to remove these superfluous files manually.

 -- Stephan Sürken <absurd@debian.org>  Sun, 23 Jun 2024 08:57:44 +0200

mini-buildd (2.1.11) experimental; urgency=medium

  Support for deprecated ``<host>:<port>`` endpoint syntax has been
  removed for good. You will need to update all command line arguments
  (like ``-E,--http-endpoint``) or values in models (like in
  ``Daemon.ftpd_bind``, ``Remote``) now if not already done.

 -- Stephan Sürken <absurd@debian.org>  Mon, 11 Dec 2023 18:26:22 +0100

mini-buildd (2.1.6) experimental; urgency=medium

  Deprecated ``-v,--verbose,-q,--quiet`` options are now gone
  for good (for all python-based command line tools). You really
  now need to remove them or replace by resp. ``-l,--log-level``
  option.

  Deprecated ``-W,--httpd-bind`` option of ``mini-buildd`` is
  now gone for good. You really now need to remove them or replace
  by resp. ``-E,--http-endpoint`` option.

 -- Stephan Sürken <absurd@debian.org>  Fri, 15 Sep 2023 14:24:07 +0200

mini-buildd (1.9.111) unstable; urgency=medium

  While 2.0.x should be fully upgradeable from 1.0.x w/o any changes
  required, please see the manual's ``roadmap`` document for a
  checklist of higly recommended post upgrade maintenance.

 -- Stephan Sürken <absurd@debian.org>  Mon, 19 Dec 2022 07:25:31 +0100

mini-buildd (1.0.5) unstable; urgency=medium

  This version upgrade unfortunately requires some manual
  maintenance:

  (1) "sudo chroot workaround" removed:

  This version removes the "sudo workaround" for the per-build
  chroot setup (as the resp. bug #608840 in 'sbuild' is now
  fixed).

  You must RE-CREATE ALL CHROOTS ONCE NOW to get rid of the
  workaround's '/etc/sudoers' file in chroots, which imposes a
  potential security risk.

  FWIW: These chroots will all be automatically disabled in the
  next 'check' run (which automatically is done weekly). All
  1.0.x versions will still remove the '/etc/sudoers' in
  snapshots prior to builds (i.e., you keep the same level of
  security as before even if you do nothing until the chroot is
  actually disabled).

  To re-create chroots, enter the web configuration frontend as
  'admin' user, and first run 'Remove' and then 'PCA' on each
  chroot instance.

  (2) Updated default snippets for eatmydata 82:

  The new eatmydata 82 (sid/jessie) breaks the old eatmydata
  shell snippet (which is automatically added for newly created
  Distributions to the -- otherwise freely configurable --
  distribution's "chroot setup script").

  This breakage usually only means eatmydata is not enabled in
  builds (which may dramatically increase your build times), and
  ugly error messages in build logs.

  To update the snippet, enter the web configuration frontend as
  'admin' user, and fix up (or entirely remove) the snippet for
  each distribution instance from "Chroot setup options/Chroot
  setup script" (for your cut&paste pleasure, an updated snippet
  is shown there in the example script).

  Note that you also need to 'PCA' all depending repositories
  afterwards.

 -- Stephan Sürken <absurd@debian.org>  Wed, 22 Oct 2014 14:01:36 +0000

mini-buildd (1.0.0) unstable; urgency=low

  An 0.8.x (mini-dinstall/flat/multipackage) repository is
  _not_ automatically migrated into the new 1.0
  (reprepro/pool/migration) one. If you have upgraded from
  0.8.x, your complete "old" repository will still be accessible
  like before (you can not build for it anymore, though).

  It's recommendend to just keep the old repository (located in
  '$HOME/rep/*') as-is, and use it as "Source" in your new
  (replacing) 1.0.x setup (located in '$HOME/repositories/*').

  In case you actually want to migrate your packages, please
  check out the resp. Admin Manual section:

  http://localhost:8066/doc/admin.html#migrate-packages-from-0-8-x

 -- Stephan Sürken <absurd@debian.org>  Thu, 23 Oct 2014 11:11:44 +0000
