Attention/ Achtung, an 64-bit time_t transition is in progress in unstable

[ro_sid]

@absolut: Thanks for testing my idea! Obviously it does not do, what (I thought) it should do .
What I do not understand at all is, that the first part (detecting of packages to remove) gives different results.
Anyhow, thanks again.

[michaa7]

michaa, not bad... indeed bash scripting would work!

Not my merit, but someone's @ debianforum.de

...

Code: [Select]

for i in $(cat AA); do LANG=C aptitude why-not $i | grep Breaks; done
...


breaks != replaces

I assume it's the latter you want to search for ...

[mrfloppy74]

Ich habe nach meiner Aktuallisierung jetzt doch ein Problem festgestellt.

Ich bekomme im Thunar keine Netzwerkgeräte /Clients/Server angezeigt. Ich kann das Netzwerk nicht mehr "browsen".
Es fehlt wohl das Paket gvfs-backends.

Dazu muss folgendes installiert werden.

Code: [Select]

sudo apt-get -s  install gvfs-backends                                                                                                                   

Die folgenden zusätzlichen Pakete werden installiert:
  libcdio-cdda2t64 libcdio-paranoia2t64 libmtp-runtime libmtp9t64
Vorgeschlagene Pakete:
  bluez-obexd
Die folgenden Pakete werden ENTFERNT:
  libmtp9
Die folgenden NEUEN Pakete werden installiert:
  gvfs-backends libcdio-cdda2t64 libcdio-paranoia2t64 libmtp9t64
Die folgenden Pakete werden aktualisiert (Upgrade):
  libmtp-runtime
1 aktualisiert, 4 neu installiert, 1 zu entfernen und 225 nicht aktualisiert.
libmtp9t64 hat aber wohl einen Bug und könnte zurückgehalten werden.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065625

Code: [Select]

Explanation: Pinned by apt-listbugs at 2024-03-21 19:12:22 +0100
Explanation:   #1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common
Package: libmtp9t64
Pin: version *
Pin-Priority: -30000

Verstehe ich das Richtig, dass durch den Bug libmtp-common durch dpkg nicht entfernt werden kann?
libmtp-common  ist installiert.

dpkg --list |grep libmtp-common                                                                                                                               
ii  libmtp-common                                  1.1.21-3.1                           all          Media Transfer Protocol (MTP) common files

Ist der Fehler unkritisch und ich kann die Installation durchführen oder soll ich das Paket pinnen und warten bis der Fehler behoben wurde?

[Camelot]

Ich habe gvfs-backends, libmtp9t64 und libmtp-runtime installiert.

Code: [Select]

apt-cache policy gvfs-backends libmtp9t64 libmtp-runtime
gvfs-backends:
  Installiert:           1.54.0-1
  Installationskandidat: 1.54.0-1
  Versionstabelle:
 *** 1.54.0-1 500
        500 http://ftp.at.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
libmtp9t64:
  Installiert:           1.1.21-3.1
  Installationskandidat: 1.1.21-3.1
  Versionstabelle:
 *** 1.1.21-3.1 500
        500 http://ftp.at.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
libmtp-runtime:
  Installiert:           1.1.21-3.1
  Installationskandidat: 1.1.21-3.1
  Versionstabelle:
 *** 1.1.21-3.1 500
        500 http://ftp.at.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

Code: [Select]

apt full-upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

[dpanter]

Fully upgraded my main machine today, been slacking off for a month while all this hoopla calmed down.

Now here's an update scenario with some chest hair!

Code: [Select]

610 upgraded, 0 newly installed, 0 to remove and 1492 not upgraded.
Need to get 1 447 MB of archives.
apt update -> apt upgrade -> aptitude dist-upgrade (because I didn't like the wild amount of packages apt wanted to remove) then actually more packages unlocked for a normal apt upgrade again, then updated Mesa-git manually and installed latest kernel. One single remaining package lingered (libllvmspirvlib17) and needed a reboot to clear it for upgrade.
Boom, done, no pain.

Left with a solitary package that got orphaned for some reason, I use AMD GPU so I don't care but it was a little amusing to see libdrm-nouveau2:i386 dangling in the wind.

[sotnik]

My only concern for now is the bug #1065626

serious bugs of libgtk2.0-0t64 (→ 2.24.33-4) <Outstanding>
 b1 - #1065626 - libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common
Summary:
 libgtk2.0-0t64(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] ^CInterrupted

Is it safe to upgrade?

[tranquil]

All of this mess all because of 32-bit architectures?! 

I'm not a package maintainer, but why couldn't this have been done in phases so that users didn't have to wait so-o-o long to perform a full-upgrade?

[dpanter]

My only concern for now is the bug #1065626

serious bugs of libgtk2.0-0t64 (→ 2.24.33-4) <Outstanding>
 b1 - #1065626 - libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common
Summary:
 libgtk2.0-0t64(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] ^CInterrupted

Is it safe to upgrade?

Yes.

Code: [Select]

$ apt policy libgtk2.0-0t64 libgtk2.0-bin libgtk2.0-common

libgtk2.0-0t64:
Installed: 2.24.33-4
Candidate: 2.24.33-4
Version table:
*** 2.24.33-4 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

libgtk2.0-bin:
Installed: 2.24.33-4
Candidate: 2.24.33-4
Version table:
*** 2.24.33-4 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

libgtk2.0-common:
Installed: 2.24.33-4
Candidate: 2.24.33-4
Version table:
*** 2.24.33-4 500
500 https://deb.debian.org/debian unstable/main amd64 Packages
500 https://deb.debian.org/debian unstable/main i386 Packages
100 /var/lib/dpkg/status

[tranquil]

My only concern for now is the bug #1065626

serious bugs of libgtk2.0-0t64 (→ 2.24.33-4) <Outstanding>
 b1 - #1065626 - libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common
Summary:
 libgtk2.0-0t64(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] ^CInterrupted

Is it safe to upgrade?

Upgraded fine on my system.

[dibl]

... why couldn't this have been done in phases ...

Actually, it does appear to be proceeding in phases. Each phase is one day. Each day, a handful of packages are deleted and replaced with their _t64 updated versions. I would be concerned about waiting longer to upgrade, as the development of trixie is also continuing daily. 

[CyrusQ]

Hey folks,

it would be nice to know if my transition will be safe.

The following package will be removed WITHOUT a t64 equivalent:
gstreamer1.0-plugins-good
gstreamer1.0-pulseaudio
libdv4
libv4l-0
libwebkit2gtk-4.1-0
libzvbi0:i386
rapid-photo-downloader
vokoscreen-ng

The following packages will be NEW installed without having a predecessor:
gcr4
libgck-2-2
libgcr-4-4
libglib2.0-0t64
libglib2.0-0t64:i386
libnvidia-pkcs11-openssl3
linux-headers-6.7.10-1-siduction-amd64
linux-image-6.7.10-1-siduction-amd64

What is your opinion?

[edlin]

I was able to reinstall the packages gstreamer1.0-plugins-good, gstreamer1.0-pulseaudio, rapid-photo-downloader, vokoscreen-ng. I would perform the upgrade.

edlin

[dibl]

Code: [Select]

# apt policy gstreamer1.0-plugins-good gstreamer1.0-pulseaudio
gstreamer1.0-plugins-good:
  Installed: 1.24.1-1
  Candidate: 1.24.1-1
  Version table:
 *** 1.24.1-1 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
gstreamer1.0-pulseaudio:
  Installed: 1.24.1-1
  Candidate: 1.24.1-1
  Version table:
 *** 1.24.1-1 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

The audio packages have been the subject of many upgrades lately, but I'm not seeing a problem there.

[ro_sid]

Hey folks,

it would be nice to know if my transition will be safe.

The following package will be removed WITHOUT a t64 equivalent:
[...]
libdv4
libv4l-0
libwebkit2gtk-4.1-0
libzvbi0:i386
rapid-photo-downloader
vokoscreen-ng
[...]
What is your opinion?

If still needed (might have become an obsolete dependency):
libdv4 -> libdv4t64 (1.0.0-17.1)
libv4l-0 -> libv4l-0t64 (1.26.1-4)
libwebkit2gtk-4.1-0 (no replacement!)
libzvbi0:i386 (no replacement yet: libzvbi0t64 - wait for the i386 upgrade to occur)
rapid-photo-downloader (available - I see no conflict, all "gstreamer1.0..." available/installable)
vokoscreen-ng (made available by towo in a siduction-repository)

[CyrusQ]

@ro_sid, @dibl, @edlin thanks for you quick replies, I'll dare the transition