[SID - Unstable] update stuck at resolving dependencies

[athmoss]

Hello Forums' Members,

I have installed Debian Sid with Mate desktop environment on my laptop cca. 7 years ago and been happily using it since. Updating it a couple of times per week using aptitude and only installing software from the official repositories.
However yesterday for probably the first time I didn't proceed with the update (there were about 130 packages to update). Examining with the 'e' key, aptitude wanted to remove atril and quite a few other packages to resolve dependencies. I cancelled all actions and let it be just to discover that today aptitude isn't able to resolve the dependencies anymore (there's 233 upgradable packages as of now). Hitting the 'e' key, it's resolving dependencies for a solid 20 minutes already and I don't know if it will finish. The count for 'open' and 'closed' dependencies is in the millions and continues to rise, with 'defer' and 'conflict' being close to a 100 and incrementing occassionally too.

Screenshot at 2024-03-01 18-27-30.png

What I tried so far:

• I'm using my country's official repository, tried to switch it to a neighboring country's but the result is the same.
• Removed non-free, non-free-firmware and contrib from sources.list (nothing in sources.list.d), there's still 230 upgradable packages and the result is the same.

Do you have suggestions what to check, where to look, how to update? Any pointers are welcome. Thank you!

[wizard10000]

Sid is in the middle of a big time_t transition. My own machines had > 40 packages held back this morning so I decided to skip upgrading until things calmed down a little bit.

If an upgrade doesn't look safe don't upgrade

[maloosheck]

I have the same problem: over 250 packages in the aptitude queue. Most of them throw dependency errors with uninstalled lib*t64 packages.

Is there any write up how to handle this? Shall I manually install lib*t64 versions of missing library packages?

[CwF]

Is there any write up how to handle this?

Wait.
If one was to attempt an update, note the count and size, everyday, yet never click ok - one would see the count and size vary in ways unexpected. It could be 250 pkgs@485MB today, and 242 pkgs@ 178MB in a week. As the wizard indicated, use some judgement when you have it, or just be patient.

During many transitions things get temporarily fat while bridging from this to that. Wait.

[wizard10000]

IMO this is one of the the main differences between Unstable and Testing. Sid is a staging area, Testing is not. During a large transition like this packages will trickle into Unstable and this is when Sid will enthusiastically break your toys if you're not paying attention during upgrades.

Two recommendations -

As mentioned, if an upgrade doesn't look safe cancel the upgrade and try again in a day or two. Unstable repos are updated every six hours and it may take one day or several days for large transitions to all get into Unstable.

Also, consider using aptitude instead of apt/apt-get for routine upgrades. aptitude will stop you and offer solutions if you try to install a package that will break other packages.

[graemev2]

I came here because I was seeing similar "large churn of packages" (e.g. cups is removed) ... I had decided to wait and see , several days ago .

I note this thread starts on 1st Mar 2024 ... it's now the 7th Mar ... any thoughts on what a reasonable period to wait is? ...a couple of days or a month ? ... I know that's how long is a piece of string (1m with SD of 0.5m BTW) but waiting way too long means things are not getting tested.

[brunon63rt]

You guys actually have a nice thing going on there. I'm stuck between the newest and last kernel. All drives like Nvidia, etc run smoothly on the last kernel, while the new one is waiting for linux-headers, which will remove 60% of my packages if I force install it. This is in fact more of a behavior problem then technical one: I always forget to choose the last kernel when I boot, so I have to reboot and pick the right one. After logging in, I always forget to set the last one as default, which is the next thing I'm going to do today since I just remembered it.

No need to worries guys! I'm sure that our Debian geniuses will have this fixed in a couple of days!

That's the price of living the wild life with sid every now and then

[sunrat]

Sid is still undergoing a major transition. You can read a lengthy discussion about it at https://forum.siduction.org/index.php?topic=9297.0
Nvidia and some other kernel modules will almost always fail to build on a new point release kernel eg. 6.6 to 6.7.
As always, the advice is to wait before upgrading if packages are flagged for removal.

I used Sid (siduction) for years, now I use Stable and have much less stress.

[brunon63rt]

To sum up for those in a hurry, Debian is transitioning packages to 64-bit time_t. Package names are being replaced to (package_name)t64.

This is being done to avoid the 2038 bug, which is kind of a second version of the Y2K / millenium bug.

https://wiki.debian.org/ReleaseGoals/64bit-time

[froggit9000]

To sum up for those in a hurry, Debian is transitioning packages to 64-bit time_t. Package names are being replaced to (package_name)t64.

This is being done to avoid the 2038 bug, which is kind of a second version of the Y2K / millenium bug.

https://wiki.debian.org/ReleaseGoals/64bit-time

Do you or anyone else have an idea when this package transitioning work will complete, approximately?

Currently I have 668 packages being held back when I try updating / upgrading, which I assume is due to this, unless it's due to something I have broken.

[froggit9000]

I fixed the packages held back issue by doing an apt update / full-upgrade

[El_Rapha]

During this transitional period, I use to update my Debian by using "aptitude" instead of apt or apt-get. "Aptitude" is able to propose a solution that update only packages that don't break the distro. I always choose the solution without packages removal.

[zelea2]

I've decided to skip this transitional period altogether (while still having my systems updated) because it just creates too many headaches:
no-debian-t64-libs