Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #268414 > unrolled thread
| Started by | Detlef Vollmann <dv@vollmann.ch> |
|---|---|
| First post | 2024-03-20 08:50 +0100 |
| Last post | 2024-03-23 18:30 +0100 |
| Articles | 8 — 6 participants |
Back to article view | Back to linux.debian.user
How does the 64bits time_t transition work? Detlef Vollmann <dv@vollmann.ch> - 2024-03-20 08:50 +0100
Re: How does the 64bits time_t transition work? Marco Moock <mm@dorfdsl.de> - 2024-03-20 09:20 +0100
Re: How does the 64bits time_t transition work? Erwan David <erwan@rail.eu.org> - 2024-03-20 09:30 +0100
Re: How does the 64bits time_t transition work? Marco Moock <mm@dorfdsl.de> - 2024-03-20 10:30 +0100
Re: How does the 64bits time_t transition work? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-03-20 09:50 +0100
Re: How does the 64bits time_t transition work? Detlef Vollmann <dv@vollmann.ch> - 2024-03-20 10:50 +0100
Re: How does the 64bits time_t transition work? songbird <songbird@anthive.com> - 2024-03-20 17:50 +0100
Re: How does the 64bits time_t transition work? Jeffrey Walton <noloader@gmail.com> - 2024-03-23 18:30 +0100
| From | Detlef Vollmann <dv@vollmann.ch> |
|---|---|
| Date | 2024-03-20 08:50 +0100 |
| Subject | How does the 64bits time_t transition work? |
| Message-ID | <IjYRX-mcd-1@gated-at.bofh.it> |
Is there a description anywhere how the 64bit time transition works? I'm currently stuck with a hard to maintain Sid system. It currently has "871 not upgraded" and it's nearly impossible to install new packages. I've looked e.g. into gnutls (on amd64), and libgnutls30t64 (3.8.3-1.1) as well as libgnutls30 (3.8.3-1) both install /usr/lib/x86_64-linux-gnu/libgnutls.so.30.37.1. Does the new libgnutls.so.30.37.1 provide both ABIs? Detlef
[toc] | [next] | [standalone]
| From | Marco Moock <mm@dorfdsl.de> |
|---|---|
| Date | 2024-03-20 09:20 +0100 |
| Message-ID | <IjZkZ-mBf-1@gated-at.bofh.it> |
| In reply to | #268414 |
Am 20.03.2024 um 08:22:16 Uhr schrieb Detlef Vollmann: > It currently has "871 not upgraded" and it's nearly impossible to > install new packages. The libs will have a suffix of t64, so you need to use dist-upgrade to upgrade the packages if they depend on the t64 libs. Although, carefully read what it wants to remove. If it wants to remove packages you need, don't hit y. Then upgrade the packages manually and look which package creates dependency problems. -- kind regards Marco Send unsolicited bulk mail to 1710919336muell@cartoonies.org
[toc] | [prev] | [next] | [standalone]
| From | Erwan David <erwan@rail.eu.org> |
|---|---|
| Date | 2024-03-20 09:30 +0100 |
| Message-ID | <IjZuF-mEe-1@gated-at.bofh.it> |
| In reply to | #268415 |
Le 20/03/2024 à 09:09, Marco Moock a écrit : > Am 20.03.2024 um 08:22:16 Uhr schrieb Detlef Vollmann: > >> It currently has "871 not upgraded" and it's nearly impossible to >> install new packages. > The libs will have a suffix of t64, so you need to use dist-upgrade to > upgrade the packages if they depend on the t64 libs. > > Although, carefully read what it wants to remove. If it wants to remove > packages you need, don't hit y. > > Then upgrade the packages manually and look which package creates > dependency problems. > Since I begin to have this in tetsing : and what should we do when a package tries to remove other (except wait) ? eg, now in testing upgrading nextcloud-desktop would remove plasma-discover, and fwbuilder would remove cups. -- Erwan David
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mm@dorfdsl.de> |
|---|---|
| Date | 2024-03-20 10:30 +0100 |
| Message-ID | <Ik0qK-ncB-15@gated-at.bofh.it> |
| In reply to | #268417 |
Am 20.03.2024 um 09:29:12 Uhr schrieb Erwan David: > Since I begin to have this in tetsing : and what should we do when a > package tries to remove other (except wait) ? > > eg, now in testing upgrading nextcloud-desktop would remove > plasma-discover, and fwbuilder would remove cups. Be aware that unstable or testing is, as the name says, unstable. :-) You can file a bug report, but it will take time until every dependency problem is fixed. It did take ~ 2 weeks for my system to fulfill all dependencies. -- kind regards Marco Send unsolicited bulk mail to 1710923352muell@cartoonies.org
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-03-20 09:50 +0100 |
| Message-ID | <IjZO1-mKk-1@gated-at.bofh.it> |
| In reply to | #268415 |
Hi, Marco Moock wrote: > The libs will have a suffix of t64 I wonder whether those suffixes will go away at some stage of this effort. (Further i wonder when the package tracker appearance of libisoburn will become less ugly than currently: https://tracker.debian.org/pkg/libisoburn and how i shall deal with a bug report which complains about the inconsistent state of the control file in respect to libburn and libisofs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067103 ) Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Detlef Vollmann <dv@vollmann.ch> |
|---|---|
| Date | 2024-03-20 10:50 +0100 |
| Message-ID | <Ik0K5-njH-7@gated-at.bofh.it> |
| In reply to | #268415 |
Marco Moock wrote: >> It currently has "871 not upgraded" and it's nearly impossible to >> install new packages. > > The libs will have a suffix of t64, so you need to use dist-upgrade to > upgrade the packages if they depend on the t64 libs. No, only the package names have the 't64' suffix, the libraries still have the same name as before. Hence my question whether the libraries provide both ABIs. > Although, carefully read what it wants to remove. If it wants to remove > packages you need, don't hit y. I did this before, and it threatened to remove a number of critical packages (like qemu). But thanks for the tip: I just ran it again and now it's nearly only old libraries that are removed. Unfortunately it will upgrade packages that I don't want to, but now the manual upgrade actually works (it didn't some hours ago, so waiting helps ;-) Thanks, Detlef
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2024-03-20 17:50 +0100 |
| Message-ID | <Ik7ix-rev-1@gated-at.bofh.it> |
| In reply to | #268414 |
Detlef Vollmann wrote: > Is there a description anywhere how the 64bit time transition works? > I'm currently stuck with a hard to maintain Sid system. > It currently has "871 not upgraded" and it's nearly impossible to > install new packages. > > I've looked e.g. into gnutls (on amd64), and libgnutls30t64 (3.8.3-1.1) > as well as libgnutls30 (3.8.3-1) both install > /usr/lib/x86_64-linux-gnu/libgnutls.so.30.37.1. > Does the new libgnutls.so.30.37.1 provide both ABIs? > > Detlef it's an on-going transition, it may be a few weeks before things settle down. that's what happens with unstable at times. there are the release mailing lists and the debian-devel mailing list which will give you some idea of how things are going. songbird
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2024-03-23 18:30 +0100 |
| Message-ID | <IldlT-1aE6-1@gated-at.bofh.it> |
| In reply to | #268414 |
On Wed, Mar 20, 2024 at 4:23 AM Brad Rogers <brad@fineby.me.uk> wrote: > > On Wed, 20 Mar 2024 08:22:16 +0100 > Detlef Vollmann <dv@vollmann.ch> wrote: > > >Is there a description anywhere how the 64bit time transition works? > > I'm far from an expert, but from what I've read, this transition is > *huge*. Possibly the largest that has ever occurred in Debian. It's > going to take time to get it done. Lots, and lots, of time. In the > meanwhile, it means a good deal of disruption in Sid/unstable. > > You should already be aware that running sid comes with certain > difficulties, and if you're not prepared/willing to deal with them then, > in all likelihood, Sid isn't for you. Some folks don't have a choice. To run Debian ports in a Debian QEMU/Chroot, you have to run Unstable in the guest. You cannot run Stable or Testing in the guest. I guess the other choice is to forgo testing on various Debian architectures. But that seems like a worse choice for everyone involved. Personally, I would not feel good about this path. I don't want Debian users and Debian packagers to experience problems I should have caught during testing. > Following Marco's advice would be a good first step, IMO. I don't think this migration was planned well. Debian should have created a temporary *-t64 port, and then released the appropriate ISOs. Later, when things got stable, the *-t64 port could have been merged back into the standard port all at once. Jeff
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web