Announcement

Collapse
No announcement yet.

Arch Linux Now Provides Debug Packages, Debuginfod Integration

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Setif View Post
    For those complaining about outdated packages, you should fellow this mailing-list conversation [arch-general] NEW RECORD! 769 packages out of date (archlinux.org)
    Wow what a clusterfuck. I didn't know snowflakes took over Arch as well...

    Comment


    • #22
      Originally posted by Almindor View Post

      Wow what a clusterfuck. I didn't know snowflakes took over Arch as well...
      Tbh that page says 700+ packages, but by the time I checked it, the list was already down to 500 something. Many of them were clones, too (64 and 32 bit variants of the same package). Considering some of them are blocked by bugs, that list isn't that scary.

      Comment


      • #23
        Originally posted by bug77 View Post

        Tbh that page says 700+ packages, but by the time I checked it, the list was already down to 500 something. Many of them were clones, too (64 and 32 bit variants of the same package). Considering some of them are blocked by bugs, that list isn't that scary.
        Yes, if you want bleeding edge, try the testing repos. Reading that mailing list thread is just wasted time. People being rude to each other.

        There was a bit of actual feedback here and there: the query is not really correct, it has many duplicates (apparently Firefox developer contributed about 100 packages itself to that count), and includes some testing packages. Some are not up-to-date for various reasons, including bugs.

        I'm glad that bugs are not merged in. For a data point on stability and robustness, I migrated an Arch install from a broken USB stick yesterday. The USB stick suddenly became read-only in 2018. I had a few conflicts to manually solve, but otherwise the install upgraded cleanly from 2018 to 2022... That's a single datapoint, but I've had smaller updates fail on non-rolling distributions.

        Now, with debug packages, and more importantly debuginfo integration, I'll be able to make useful debug reports for crashes I was not expecting, while keeping my system updated. Anybody knows how quickly new packages are added? Is manual intervention needed from the packagers? I currently use my non-stripped version of sway and wlroots, keeping in sync with arch packages would be better.

        Comment


        • #24
          Originally posted by [email protected] View Post

          Yes, if you want bleeding edge, try the testing repos. Reading that mailing list thread is just wasted time. People being rude to each other.

          There was a bit of actual feedback here and there: the query is not really correct, it has many duplicates (apparently Firefox developer contributed about 100 packages itself to that count), and includes some testing packages. Some are not up-to-date for various reasons, including bugs.

          I'm glad that bugs are not merged in. For a data point on stability and robustness, I migrated an Arch install from a broken USB stick yesterday. The USB stick suddenly became read-only in 2018. I had a few conflicts to manually solve, but otherwise the install upgraded cleanly from 2018 to 2022... That's a single datapoint, but I've had smaller updates fail on non-rolling distributions.

          Now, with debug packages, and more importantly debuginfo integration, I'll be able to make useful debug reports for crashes I was not expecting, while keeping my system updated. Anybody knows how quickly new packages are added? Is manual intervention needed from the packagers? I currently use my non-stripped version of sway and wlroots, keeping in sync with arch packages would be better.
          IME, packages are integrated in a matter of days. Nvidia driver and some kernel releases may take about a week. But most of the time, when Michael posts about a new systemd, pipewire and the likes, they're available by the time I finish my workday and chill in front of my desktop.

          Comment


          • #25
            Originally posted by bug77 View Post

            Tbh that page says 700+ packages, but by the time I checked it, the list was already down to 500 something. Many of them were clones, too (64 and 32 bit variants of the same package). Considering some of them are blocked by bugs, that list isn't that scary.
            That's good but what about glibc then? Being behind by a year is somewhat laughable. The package in Arch is on 2.33 which was released over a year ago now and the last update on the package itself is from May 2021. It seems like it's been abandoned?

            Going over that "discussion" (discarding all the trans attention whoring), it seems there's a major problem with some maintainers and way forward for packages that are under their control. It would seem people have trouble submitting update diffs purely for bureaucratic reasons.

            Comment


            • #26
              Originally posted by Almindor View Post

              That's good but what about glibc then? Being behind by a year is somewhat laughable. The package in Arch is on 2.33 which was released over a year ago now and the last update on the package itself is from May 2021. It seems like it's been abandoned?

              Going over that "discussion" (discarding all the trans attention whoring), it seems there's a major problem with some maintainers and way forward for packages that are under their control. It would seem people have trouble submitting update diffs purely for bureaucratic reasons.
              Something weird is indeed up with the C toolchain (glibc, binutils, gcc + some assorted related packages) in Arch Linux. However, apart from that Arch Linux doesn't seem to be that behind.

              All community maintened distros have issues from time to time. Be it political, technical or personal. Hopefully it is resolved soon, but I wouldn't cry doom over a singular thing like that.

              One thing that could help is migrating to a git repo for the packages. That would more easily allow third party pull requests. I read somewhere that this is an ongoing effort.

              Comment


              • #27
                Originally posted by Vorpal View Post
                One thing that could help is migrating to a git repo for the packages. That would more easily allow third party pull requests. I read somewhere that this is an ongoing effort.
                Probably related to https://gitlab.archlinux.org/archlin...e/-/issues/135 (git migration)

                Comment


                • #28
                  Originally posted by [email protected] View Post

                  Probably related to https://gitlab.archlinux.org/archlin...e/-/issues/135 (git migration)
                  that's what i am assuming, I just wish the devs were a little transparent about it

                  Comment


                  • #29
                    Originally posted by Almindor View Post

                    Wow what a clusterfuck. I didn't know snowflakes took over Arch as well...
                    they will go everywhere lol.

                    Comment


                    • #30
                      Originally posted by Alexmitter View Post
                      Arch more and more looks like a respectable serious Distro actually capable of serving the advanced user instead of just being a joke to tease people on how "hard" it is to install, it just took them 20 years.
                      Amen Brother +1

                      Comment

                      Working...
                      X