--- Begin Message ---
Subject: unblock: shotwell/0.25.4-0.1
Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package shotwell.
Upstream version 0.25.1 of shotwell was packaged for testing, but that
version is unsuitable for release in stretch as it contained tons of
temporary regressions due to a major change in the menu handling
code, cf. Bug#849688. These bugs have been ironed out upstream in
versin 0.25.4, which is the NMU I'm kindly requesting to be unblocked.
Oh, and BTW: I'm personally using shotwell almost daily and I can
confirm that 0.25.4 runs smoothly while 0.25.1 is so broken it's next to
useless.
$ debdiff shotwell_0.25.1-1_amd64.deb shotwell_0.25.4-0.1_amd64.deb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo-gobject2 (>=
1.10.0), libcairo2 (>= 1.2.4), libexif12 (>= 0.6.21-1~), libgck-1-0 (>=
2.91.1), libgcr-base-3-1 (>= 3.8.0), libgcr-ui-3-1 (>= 3.8.0),
libgdk-pixbuf2.0-0 (>= 2.25.2), libgee-0.8-2 (>= 0.10.1), libgexiv2-2
(>= 0.6.1), libglib2.0-0 (>= 2.41.1), libgomp1 (>= 4.2.1), libgphoto2-6
(>= 2.5.10), libgphoto2-port12 (>= 2.5.10),
libgstreamer-plugins-base1.0-0 (>= 1.0.0), libgstreamer1.0-0 (>= 1.0.0),
libgtk-3-0 (>= 3.16.2), libgudev-1.0-0 (>= 146),
libjavascriptcoregtk-4.0-18, libjson-glib-1.0-0 (>= 0.12.0), liblcms2-2
(>= 2.2+git20110628), libp11-kit0 (>= 0.2), libpango-1.0-0 (>= 1.18.0),
libpangocairo-1.0-0 (>= 1.14.0), libraw15 (>= 0.16.0), libsoup2.4-1 (>=
2.41.90), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 4.1.1),
libwebkit2gtk-4.0-37 (>= 2.5.3), libxml2 (>= 2.7.4), shotwell-common (=
[-0.25.1-1),-] {+0.25.4-0.1),+} dconf-cli, default-dbus-session-bus |
dbus-session-bus, librsvg2-common
Installed-Size: [-5833-] {+5837+}
Version: [-0.25.1-1-] {+0.25.4-0.1+}
unblock shotwell/0.25.4-0.1
-- System Information:
Debian Release: 9.0
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Control: tag -1 - moreinfo
On Sun, Feb 26, 2017 at 06:22:58PM +0100, Michael Biebl wrote:
> I've been burned by this myself in the past. A libfoo-dev package got an
> epoch and reverse dependencies were not updated accordingly (very easy
> to miss).
> Say you have a package foo which dependency on libbar-dev (>= 10).
> libbar-dev get's an epoch.
> Later on foo upstream bumps the required version to >= 11, so the
> package maintainer bumps it to libbar-dev (>= 11).
> This is still satisfied by the old, 1:10, but most likely unnoticed as
> libbar v11 is already available in the archive.
>
> I've seen this problem a lot with libx* libraries.
Ok, I understand this somewhat better now. Thanks for the additional
detail.
Making this work better in the long run might make a good high-level
project for someone in the buster cycle.
> Now, in case of shotwell, it's probably less of an issue, as it doesn't
> have that many reverse dependencies.
> Still, I prefer to not use epoch unless absolute necessary, which I
> don't consider it to be in this case. The ugly version number for one
> release cycle is an acceptable compromise in my experience.
This makes sense for things with versioned dependencies, but I'm not
convinced about shotwell. Anyway, I will stand by my commitment not to get
in the way of this.
Unblocked.
Thanks,
--
Jonathan Wiltshire jmw@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
--- End Message ---