Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #268414 > unrolled thread

How does the 64bits time_t transition work?

Started byDetlef Vollmann <dv@vollmann.ch>
First post2024-03-20 08:50 +0100
Last post2024-03-23 18:30 +0100
Articles 8 — 6 participants

Back to article view | Back to linux.debian.user


Contents

  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

#268414 — How does the 64bits time_t transition work?

FromDetlef Vollmann <dv@vollmann.ch>
Date2024-03-20 08:50 +0100
SubjectHow 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]


#268415

FromMarco Moock <mm@dorfdsl.de>
Date2024-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]


#268417

FromErwan David <erwan@rail.eu.org>
Date2024-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]


#268419

FromMarco Moock <mm@dorfdsl.de>
Date2024-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]


#268418

From"Thomas Schmitt" <scdbackup@gmx.net>
Date2024-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]


#268420

FromDetlef Vollmann <dv@vollmann.ch>
Date2024-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]


#268443

Fromsongbird <songbird@anthive.com>
Date2024-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]


#268505

FromJeffrey Walton <noloader@gmail.com>
Date2024-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