Dev1 Galaxy Forum / [SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

Re: [SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

dummy@example.com (zerrax) — Tue, 29 Sep 2026 12:27:42 +0000

Thanks everyone for the quick and clear replies — that solved it.

To confirm for anyone finding this thread later: my confusion came from mixing up
Devuan's codenames with Debian's. Daedalus = Debian 12 (Bookworm), Excalibur =
Debian 13 (Trixie). The tzdata "upgrade" to a deb12 build was actually correct for
Daedalus, and the tzdata-legacy conflict was expected on that release.

I've since upgraded from Daedalus to Excalibur via the command line (sources.list
edit + apt update / upgrade / dist-upgrade). Fastest major upgrade I've ever done —
everything came through cleanly, and the tzdata situation resolved itself on Excalibur.

Thanks again — together we make Devuan better. 🐧

Re: [SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

dummy@example.com (blackhole) — Sat, 26 Sep 2026 10:07:24 +0000

It's not a fork.

Honestly, I think Devuan should just follow Debian's versioning and be done with it.

Less confusion all round.

Re: [SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

dummy@example.com (SS) — Sat, 26 Sep 2026 05:48:01 +0000

I thought that there is a clear rule which goes

Devuan Version: Debian version -7 ie take the first debian version where system d is the default init which is where devuan got rid of it hence Devuan 1 forked Debian 8

Hence why
Devuan 6 forks Debian 13 (most recent stable)
Devuan 5 forks Debian 12

Devuan 7 fork Debian 14 (so testing)
So if you know the Debian versions and the first where system d became default, then devuan version is easily mapped?

And then you always map Devuan Ceres to Debian Sid as a constant for unstable?

Re: [SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

dummy@example.com (ralph.ronnquist) — Sat, 26 Sep 2026 00:25:00 +0000

"This"? Sloppy thinking?

Re: [SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

dummy@example.com (Mercury) — Fri, 25 Sep 2026 23:46:48 +0000

This is what happens when your product has a version number and a codename, and is based on another product that has a version number and a codename, and version numbers and codenames of the base and derivative product are used haphazardly all over the place, and none of them can be naturally inferred to match without doing research.

Then you got the rolling designations of stable, oldstable, oldoldstable....

Re: [SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

dummy@example.com (delgado) — Fri, 25 Sep 2026 21:07:00 +0000

daedalus is based on debian 12 "bookworm", excalibur is based on debian 13 "trixie".

Re: [SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

dummy@example.com (fsmithred) — Fri, 25 Sep 2026 21:06:05 +0000

The issue that's known is that daedalus is not trixie. It's whatever "B" was before trixie and was 12 (bookworm?).

Devuan Excalibur is Debian Trixie.

[SOLVED] tzdata from daedalus-security is a deb12 build on a deb13 system

dummy@example.com (zerrax) — Fri, 25 Sep 2026 19:26:40 +0000

Subject: tzdata from daedalus-security is a deb12 build on a deb13 system — conflicts with tzdata-legacy

Hi all,

I'd like to report what looks like a repository synchronization issue with tzdata on Devuan Daedalus, and ask whether this is a known problem.

## System

- Devuan Daedalus (based on Debian 13 / Trixie, i.e. deb13 packages)
- Architecture: amd64
- Sources: deb.devuan.org/merged (daedalus, daedalus-updates, daedalus-security)

## Problem

After a routine `apt update`, APT proposed an "upgrade" of tzdata from the installed
2026b-0+deb13u1 to 2026c-0+deb12u1. Note the version string: the candidate is a
*deb12* (Bookworm) build, while the installed package is a *deb13* build.

`apt list --upgradable -a`:

tzdata/oldstable-security 2026c-0+deb12u1 all [upgradable from: 2026b-0+deb13u1]
tzdata/now 2026b-0+deb13u1 all [installed,upgradable to: 2026c-0+deb12u1]
tzdata/oldstable 2026b-0+deb12u1 all
tzdata/oldstable-updates 2025b-0+deb12u1 all

At first, installing the candidate failed with a dependency conflict:

Dependency resolution failed:
The following packages have unmet dependencies:
tzdata-legacy: Conflicts: tzdata-bookworm

Attempting the upgrade with `apt install -t daedalus-security tzdata` still pulled the
deb12 build from daedalus-security:

Get:1 http://deb.devuan.org/merged daedalus-security/main amd64 tzdata all 2026c-0+deb12u1 [304 kB]

The upgrade then removed tzdata-legacy, and as a knock-on effect also removed:

unar, gnustep-base-common, gnustep-base-runtime, libgnustep-base1.31

`apt-cache policy tzdata` afterwards:

tzdata:
Installed: 2026c-0+deb12u1
Candidate: 2026c-0+deb12u1
Version table:
*** 2026c-0+deb12u1 500
500 http://deb.devuan.org/merged daedalus-security/main amd64 Packages
100 /var/lib/dpkg/status
2026b-0+deb12u1 500
500 http://deb.devuan.org/merged daedalus/main amd64 Packages
2025b-0+deb12u1 500
500 http://deb.devuan.org/merged daedalus-updates/main amd64 Packages

As you can see, every available version of tzdata in the daedalus repositories is a
deb12 build, even though the rest of the system is deb13.

## Questions

1. Is this a known issue? I could not find an existing bug report for it.
2. Is the deb12 build of tzdata in daedalus-security intentional, or is this a
synchronization problem where the deb13 build has not yet propagated to the
Devuan mirrors?
3. Until a proper deb13 build is available, is holding tzdata (`apt-mark hold tzdata`)
the recommended workaround?
4. Is there a known way to keep both tzdata and tzdata-legacy installed, or is the
conflict between them expected on this release?

I've held tzdata for now to avoid repeating the mismatched upgrade. Happy to provide
more logs if useful.

Thanks.