*t64 upgrades question

Forum Forums New users New Users and General Questions *t64 upgrades question

  • This topic has 23 replies, 6 voices, and was last updated May 26-3:02 pm by wildstar84.
Viewing 15 posts - 1 through 15 (of 24 total)
  • Author
    Posts
  • #140462
    Member
    wildstar84

      I vaguely remember a recent post somewhere warning to hold off upgrades that switch to packages ending in “t64”. I’m running testing (not sid). Is this still true or can we safely now begin accepting the switch to these packages (has this been officially blessed in antiX yet)?

      A 2nd question that may be related – Attempting to upgrade cups packages threatens to replace a bunch of packages, not with *t64 versions, but with “*:i386” versions?!

      Repositories (inxi -r):

        Active apt repos in: /etc/apt/sources.list.d/antix.list
          1: deb http://la.mxrepo.com/antix/testing/ testing nosystemd main nonfree
        Active apt repos in: /etc/apt/sources.list.d/debian.list
          1: deb http://ftp.us.debian.org/debian/ testing non-free-firmware contrib main
          2: deb http://security.debian.org/ testing-security main contrib non-free
        Active apt repos in: /etc/apt/sources.list.d/various.list
          1: deb http://liquorix.net/debian/ testing main
      

      Thanks,

      Jim

      #I seek official permission, since apt is not forgiving! ;)

      #140468
      Member
      abc-nix

        I am also on testing. As far as I know, some *t64 packages have migrated to testing, but many others have yet to arrive. There is issue with some antiX packages that have missing *t64 dependencies, and fail when trying to upgrade (or try to remove some other packages).

        If you put some packages on hold, you can upgrade some of the ones from Debian repos, but many others will be waiting until sid migrates the packages to testing.

        I made the mistake of upgrading apt, and I just started upgrading some packages right now, and there are many warnings. The new apt version isn’t an improvement, and seems to hide the packages that will be affected and will be removed during an upgrade. I am trying to fix this right now.

        I think it is better to wait a bit. I will be building or backporting some packages from sid to try to fix my system. There are too many issues right now.

        #140470
        Member
        Xunzi_23

          Hi abc-nix I absolutely agree with

          The new apt version isn’t an improvement, and seems to hide the packages that will be affected and will be removed during an upgrade.

          Needing an extra step or at times two due to the stupidly dummed down display of actions before upgrading is definitely a bad design.
          If you are able to fix apt please make your changes available, if possible with sid compatibility.

          #140504
          Member
          abc-nix

            If you are able to fix apt please make your changes available, if possible with sid compatibility.

            The new apt release seems to keep packages installed even if some of the dependencies have been replaced with the *t64 packages. When trying to downgrade, it wants to remove those “orphaned” packages, so I will not be touching it for now. I will be putting things on pause while creating a snapshot of my system before I continue experimenting.

            Right now my system is in a state of limbo, where everything still works even with “missing dependencies”. I will either move to sid or build the conflicting packages replacing the dependencies with the new *t64 ones.

            #140511
            Member
            Xunzi_23

              Thanks for info, at present sid is unruly and at times throwing tantrums,
              up to now manageable.

              Means running sid is interesting at present but luckily still possible.
              Hope that was not famouse last words. I need sid for my A3 printing to
              work.

              • This reply was modified 2 months, 2 weeks ago by Xunzi_23.
              #140519
              Member
              wildstar84

                re “There is issue with some antiX packages…”

                Yes, a bunch for me, mostly the “*nosystemd” ones!
                Thanks for the heads-up a/b apt! I’m at v2.7.12.0nosystemd1 and the “upgrade” offered is 2.9.2, which I know NOT to upgrade packages from *nosystemd to !nosystemd but to wait for Anti to release nosystemd vsns!

                re “at present sid is unruly and at times throwing tantrums”

                I’ve always understood that that’s to be expected with sid, but what begs the question is why testing upgrades have become so difficult of late? I’ve been using and upgrading antiX packages for over ten years and have never run into so much difficulties with upgrades until recently! I’m sure Anti, et. al. are working very hard to get a handle on all of this (much appreciated!), but What has Debian done to us here?! (My antifascist, conspiracy-theorist side would suspect that perhaps they’re deliberately trying to make life difficult for nosystemd derivatives such as antiX?)

                #140551
                Member
                stevesr0

                  Hi all,

                  In March, when these packages started appearing in Sid, they caused problems and their install forced the removal of the preceding compatible packages.

                  At least in Sid, I now find them relatively harmless, as long as I first check with
                  sudo apt install -s pkg1 pkg2 pkg3 ...
                  to make sure that nothing is being automatically removed – EXCEPT the previous nont64 version, AND that there aren’t systemd packages being installed as “extras”. Also need to look in aptitude sometimes to check the dependency paths.

                  This has been posted about in the thread started by anticapitalista (https://www.antixforum.com/forums/topic/do-not-upgrade-1-march-2024/). Last post on the 17th of April.

                  Interesting that it is causing problems (??) for testing. Wonder how this will affect stable when it gets there – hopefully, it will be “understood” and “controlled” by then…

                  • This reply was modified 2 months, 2 weeks ago by stevesr0.
                  #141857
                  Member
                  abc-nix

                    I spent the last week and a bit (on and off, as I was busy) rebuilding some packages from the antiX testing repos and now I am (almost) fully up to date on testing. I had some issues with some of the *t64 libs and packages, but I finally am 99% there (I still need to rebuild cups again).

                    I recommend backing up (which I didn’t do), updating apt first, and then see if you can update the packages that don’t remove main packages.

                    If you have issues with the antiX packages (missing dependencies, etc.), disable the antiX repo and first update the Debian packages that don’t bring in elogind (if you already have elogind, then first update it from the antiX repo).

                    I went first with apt upgrade until it tries removing important things. Then I tried updating one at a time those packages with apt install –upgrade <package-name>, if it won’t update, you either let it be removed and then you can install it again after the update, or you need to build it from the sid source.

                    Finally, apt dist-upgrade to update more t64 libs. Always pay attention to the “going to be removed” packages. I initially thought that apt hid the “going to be removed” packages, but it will only remove those that it lists. It does show a warning during the upgrade process with “dependency problems, but removing anyways as you requested”, but it doesn’t remove the packages that depend on the library. Example:

                    [1mdpkg:[0m libnettle8:amd64: dependency problems, but removing anyway as you requested:
                     wget depends on libnettle8.
                     libsrt1.5-gnutls:amd64 depends on libnettle8.
                     librtmp1:amd64 depends on libnettle8.
                     libhogweed6:amd64 depends on libnettle8.
                     libgnutls30:amd64 depends on libnettle8 (>= 3.9~).
                     libfilezilla42:amd64 depends on libnettle8 (>= 3.1).
                     libcurl3-gnutls:amd64 depends on libnettle8.
                     libarchive13:amd64 depends on libnettle8.
                     filezilla depends on libnettle8.

                    If you go little by little, and stop when something major wants to be removed or impossible to update because of dependency issues, you can do it safely. You either pin the package that cannot be updated because of missing dependency, download and install said dependency from sid, or rebuild and locally install the package.

                    I went slowly, and stopped when there were big issues or I had to use the machine for work. It is doable.

                    • This reply was modified 2 months ago by abc-nix.
                    #142002
                    Member
                    wildstar84

                      Can anyone tell me what the endgame is here – are all the *t64 packages eventually to be renamed to their regular names (sans t64) and that’s what we’re waiting on, or are we eventually going to be given the green light to start updating everything that now requires *t64 library versions?!

                      @abc-nix – re:”I spent the last week and a bit (on and off, as I was busy) rebuilding some packages from the antiX testing repos and now I am (almost) fully up to date on testing”: I’m not sure what you did, but I still can’t hardly upgrade anything (except a python, etc. package here and there) cups is still a compete no-go and pretty much none of the “antiX”-specific (*nosystemd#) packages will update (all require *t64 packages).

                      Can anyone shed some more light on these issues? I don’t use “apt dist-upgrade”, etc. (learned over the years that this often breaks things!), but rather use Synaptic to see a list of available upgrades sorted by version#, then select each update (all w/same version#, so related), check for what’s going to happen, and either ok or reject/wait. I usually select most of them (skipping beta versions, etc). This has served me extremely well, having not had to ever do a complete reinstall (until lately when all this Debian t64 foolishness started)!

                      #142057
                      Member
                      stevesr0

                        Hi wildstar84,

                        I am writing about Sid not testing.

                        At this point, it “feels” (to me) like the “flood” of incompatibility has passed Sid. By that, I mean that APPARENTLY the number of interlinked packages have now been upgraded is sufficient that new ones rarely introduce a problem (such as systemd dependencies, removal of nosystemd packages or failure because of another upgrade that hasn’t reached the repository).

                        I imagine (writing as a permanent noobie) that some necessary packages have not gotten to testing and apt upgrade or apt dist-upgrade or apt full-upgrade in its “wisdom” decides it needs to deal with this by removing packages you want to keep and giving you packages you don’t want.

                        That was happening for over a month in Sid and required close attention (for those of us who don’t rebuild packages) to avoid problematic changes. This involved the liberal use of synaptic or aptitude, simulated installs with apt install -s and the holding of packages to avoid their accidental install and to reduce apt “confusion”.

                        • This reply was modified 2 months ago by stevesr0.
                        #142060
                        Moderator
                        Brian Masinick

                          Regarding Sid as opposed to Testing:
                          All Sid packages spend a considerable amount of time – (usually ten days)
                          before moving from Sid to Testing.

                          Therefore, all of the “stuff” that HAD been taking place in Sid
                          is now taking place in Testing.

                          If you want a solid system, there’s nothing quite like our
                          antiX 23.1 Full runit.

                          If you don’t mind a full Debian experience (systemD and all),
                          the siduction distribution, despite the “bad word” above, remains
                          an excellent distribution.

                          During all of that early t64 stuff I got rid of siduction for a little
                          while, but brought it back some time in April and it’s been working
                          really well again; that tells me that our stuff, regardless of which
                          repo, will be back looking good soon.

                          I’d recommend either holding off some more if you use Testing, be
                          cautious if you use Sid – OR, as long as you have either multiple
                          systems OR multiple distributions OR both, then keep Flash Drives
                          to back you up and/or SAVE you, and put caution aside, try these,
                          even WITH their questionable *t64 packages to SEE what they do.
                          HOWEVER, I STRONGLY caution you to ONLY put that caution aside
                          on TEST systems so you can OBSERVE the consequences of these packages.
                          This is NOT a practice for the conservative person, it’s an activity
                          for the curious EXPERIMENTER ONLY!

                          I hope anyone who experiments is capable of reinstalling, understands
                          that doing experiments is NOT always safe, therefore, it’s not the place
                          to do stuff with important data or your main distribution.

                          I take my own advice. Back in the day when I always messed with
                          sidux, aptosid, siduction or ordinary Debian Sid, I also always had
                          a STABLE version of MEPIS, antiX, PCLinuxOS, Slackware, or other distros,
                          NEVER just one thing, never just one system; always CDs or DVDs. As
                          Flash Drives became more prevalent, I added them; now on some of my
                          systems that is the ONLY way I install, other than directly over
                          the network (I haven’t done much directly over the network either because
                          all I have now are either 5G networks or WiFi connected to site routers,
                          and I no longer have personal control over those “site routers”, since
                          I live in a senior citizen community. In the last 5-6 years and particularly
                          when 5G was introduced, sites deactivated (and generally removed) all previous
                          cable box or router plug in locations, which limits some methods for me.

                          I’ve changed my practices accordingly – Flash Drives are my go to devices;
                          I use them both for installation and snapshots; I generally use snapshots
                          for my backups and Cloud storage as a secondary backup.

                          --
                          Brian Masinick

                          #142065
                          Forum Admin
                          anticapitalista

                            You could switch to the sid repos and see what happens.
                            If all seems ok, then change back to testing

                            Philosophers have interpreted the world in many ways; the point is to change it.

                            antiX with runit - leaner and meaner.

                            #142069
                            Member
                            abc-nix

                              These are the packages I had to rebuild (and one I downloaded from sid directly) and install to overcome the conflicts. They are cups, bluez (bluetooth), icewm, pipewire and libasound2t64 (which is from sid, and is only needed if you need to upgrade pipewire).

                              I have the same cups version installed as the one from the antiX repos, but I built it in testing (when built in sid it doesn’t install for me on testing). I had to temporarily disable the antiX repos and use a “local repo” (I created in /repo/apt/testing and added it as a trusted source in /etc/apt/sources.list.d/local.lsit) to get apt to detect and install the packages from there without having to manually install each one, so that they can be easily updated when anticapitalista builds newer versions. After that, I could upgrade the other packages from the antiX repos.

                              You could wait a bit, but the last 3 days I haven’t seen any more new t64 packages being installed, so I think testing has migrated most of them from sid already.

                              If you don’t want to deal with the t64 packages, you could follow the suggestion in the other t64 thread, making apt ignore the t64 part in the package name. Or wait a bit to see if others on Testing are doing OK.

                              #142073
                              Member
                              wildstar84

                                I have no personal issues w/t64 packages (I understand that they are Debian’s fixes for the year2038 problem). My only issue is the warnings I’ve seen (in this forum) regarding letting them into TESTING installs at this moment. My main question is: Is the t64 naming convention temporary and they’re eventually going to be renamed to (and replace) the corresponding non t64-named versions (and that that is what I should be waiting for), or is that the permanent new-naming convention and that I should only wait for some “all clear” post in antiX News (or this thread) for TESTING users to safely begin updating everything to these new versions of the libraries (I’m certain that the t64 fixes are a good thing and inevitable); OR – should I go ahead and start updating (in TESTING) basic stuff that replaces libraries with the new t64-named ones? I definitely w/Anti in wanting to keep systemd out, but I don’t have any issues w/Debian’s t64 changes themselves (just don’t understand why libraries had to all be renamed)!

                                #142076
                                Moderator
                                Brian Masinick

                                  I have no personal issues w/t64 packages (I understand that they are Debian’s fixes for the year2038 problem). My only issue is the warnings I’ve seen (in this forum) regarding letting them into TESTING installs at this moment. My main question is: Is the t64 naming convention temporary and they’re eventually going to be renamed to (and replace) the corresponding non t64-named versions (and that that is what I should be waiting for), or is that the permanent new-naming convention and that I should only wait for some “all clear” post in antiX News (or this thread) for TESTING users to safely begin updating everything to these new versions of the libraries (I’m certain that the t64 fixes are a good thing and inevitable); OR – should I go ahead and start updating (in TESTING) basic stuff that replaces libraries with the new t64-named ones? I definitely w/Anti in wanting to keep systemd out, but I don’t have any issues w/Debian’s t64 changes themselves (just don’t understand why libraries had to all be renamed)!

                                  Jim, I don’t think anyone has a specific issue with the “functionality” of these packages. The concern for those who want to retain an “antiX” element, primarily the protections and corrections we have in place to keep systemd package creep out of the software, or anything else that may “work”, as far as the Debian packages, yet “disrupt” our work; I’m not sure if we *know* this or not.

                                  The “good news” we’ve seen in Sid is that between what Debian has done and how we’ve repackaged several of our versions in order to maintain our nosystemd philosophy, *most* of that work has been successful. Based on this, within a week or two the work will be completed sufficiently to get it into our Testing repos – and it looks as if that effort is already underway.

                                  I’ve said it before too: for those who have extra “test systems”, it may be a good thing to experiment with this stuff to figure out if they have any unexpected consequences or not; if your system IS a test system and you have other well preserved environments, perhaps you can be one of the ones who can afford to test this. My caution is NOT to do this unless you either have other systems or you can replace this one, should the t64 packages bring tainted packages into the infrastructure. (I’m not saying one way or the other if they WILL or WILL NOT because I do NOT have a system right now where I want to do this testing); I’ll just stick with the recommendation to use caution at this point.

                                  --
                                  Brian Masinick

                                Viewing 15 posts - 1 through 15 (of 24 total)
                                • You must be logged in to reply to this topic.