The officially official Devuan Forum!

delgado

Member

Registered: 2022-07-14

Posts: 213  

[SOLVED] Package name extension "t64" in excalibur

The day before yesterday I switched my main installation to excalibur. A lot of package names seems to have suddenly a "t64"-string appended, e.g.: "SomePackageName" vs. "SomePackageNamet64". Most of them seem to be libraries, but not sure.

What's the matter with that?

steve_v

Member

Registered: 2018-01-11

Posts: 381  

Re: [SOLVED] Package name extension "t64" in excalibur

64bit time transition.
Now is not a particularly good time to volunteer your main rig as a testing/unstable guinea pig, at least not if you want to get anything (besides being a guinea pig) done.

---

Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

delgado

Member

Registered: 2022-07-14

Posts: 213  

Re: [SOLVED] Package name extension "t64" in excalibur

Thanks for the info.
The last years with devuan/debian testing were quite convincing, but I'm going back to daedalus by now.

stultumanto

Member

Registered: 2023-12-12

Posts: 68  

Re: [SOLVED] Package name extension "t64" in excalibur

I came here to search for information on this issue because I noticed today that one of my Excalibur installations had 68 packages held back. Running a dist-upgrade would clear the holds, but would also remove dozens of packages without installing replacements. I'm not sure whether I should wait for this issue to be resolved, or run the dist-upgrade now before it gets any worse. Discussions around the web are confusing and contradictory. Some say to wait, while others say get it over with. Is anyone else dealing with this issue?

Update: The number of held back packages jumped to 120 today. If this continues, it may end up being easier to just reinstall these systems from scratch. I'm kind of surprised no one else is dealing with this issue. Maybe it's because I installed a lot of development libraries when I was building the latest version of GNUstep/libobjc2. I do have one system that has no held back packages at all, but there's almost nothing installed on it but the base system and a simple C+X11 toolchain.

Last edited by stultumanto (2024-04-27 23:23:40)

EDX-0

Member

Registered: 2020-12-12

Posts: 81  

Re: [SOLVED] Package name extension "t64" in excalibur

in march i had to move from devuan unstable to testing because the t64 migration wasn't kind to my system and i needed some extra time running as i was, i really want to avoid a re-install but seems like that is what i will have to do.

stultumanto

Member

Registered: 2023-12-12

Posts: 68  

Re: [SOLVED] Package name extension "t64" in excalibur

I went ahead and did the dist-upgrade on two systems, and everything seems OK so far. In both cases, only gdb was uninstalled without a replacement. It wasn't clear why. I was able to reinstall it immediately after the upgrade.

One system got up to 154 held packages before I ran the upgrade. That's almost 120 new packages released in less than 24 hours. It seems there's a big push going on right now to get the transition done, maybe before the end of the month. When I checked 24 hours ago, the dist-upgrade would have removed some really important applications, including LibreOffice. The list of removals was much shorter today. There's probably no harm in waiting a while longer if you aren't in a hurry to upgrade.

delgado

Member

Registered: 2022-07-14

Posts: 213  

Re: [SOLVED] Package name extension "t64" in excalibur

Update:
Yesterday's re-switch to excalibur went flawless. The t64 library issue seems settled so far - at least for the programs in this particular installation.

Since excalibur is testing, there are issues to solve. In my case: LXDE
lxpannel-gtk3 is still broken. Therefore dadalus' version (gtk2-based) is preserved through the following pinning:

$ cat /etc/apt/preferences.d/lxde.pref 

Package: lxde* 
Pin: release n=daedalus
Pin-Priority: 1011

Package: pcmanfm  libfm4 libfm-gtk4 libfm-modules libfm-tools
Pin: release n=daedalus
Pin-Priority: 1011

Package: libfm-d* libfm-extra* libfm-gtk-*
# Package: libfm-doc  libfm-dev libfm-extra-dev libfm-gtk-dev  libfm-data libfm-gtk-data  libfm-extra4
Pin: release n=daedalus
Pin-Priority: 1011

Package: lxappearance* lxpanel* lxhotkey* 
Pin: release n=daedalus
Pin-Priority: 1011

#Package: libfm4t64 
#Pin: release *
#Pin-Priority: -1

################################################################################
# daedalus' lxde is gtk2-based
# excalibur's lxde is gtk3-based
# Q: Why?
# A: "lxpannel-gtk3" is not working ... so "lxde-gtk2" it is.
#

# apt pinning
# Package: libfm-*  # matches "gtk3" and "qt" versions too
#  
#      -gtk3       # we want to avoid these!
#      -qt         # lxqt - don't touch.
#
# "menu-cache" program: packages not pinned!
# lxmenu-data libmenu-cache3  libmenu-cache-bin   # libfm-extra4t64 libfm-extra4
#

# Remarks:
# "libfm-gtk4": Does NOT refer to "gtk version 4"
# "lxappearance-gtk3": seems to work meanwhile (May 2024), still lxpannel to fix
#  
# 
# lxde-gtk2 and lxde-gtk3 do not mixed-up
# possible exception: The "menu-cache" program 
# 

It is a moving target, notes are included.