Re: Bug #961990
Hi, On Sun, 19 Jul 2020 18:47:37 -0400 The Wanderer wrote: > Looking at it, I don't see anything which strikes me as qualifying as > buggy. Can you clarify what about it you see as being a misbehavior > problem? > (...) > It appears that the software previously provided in libgcc1 is now being > provided, in a newer version, in libgcc-s1. not sure if I am missing something here, but from the things I read in this thread this strikes me as a situation that is crying for a transitional meta-package "libgcc1" which would remove the old libgcc1, pull in libgcc1-s1 and thus leave dependencies intact. Just a thought, though. Regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. There's coffee in that nebula! -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"
Re: Bug #961990
On 2020-07-19 at 18:14, Default User wrote: > On 2020-07-19 at 16:27, Stefan Monnier wrote: > >>> This has been going on since the beginning of June, 2020, with >>> no end in sight. >>> Bug #961990 - IIUC, no activity since 2020-06-02. >>> >> You show a session where you reject all the proposed solutions, but >> I don't see any justification why you reject those choices, so I don't >> know what you consider to be a bug. >> >>> Remove the following packages: >>> 1) libgcc1 [1:10.1.0-1 (now, unstable)] >>> Accept this solution? [Y/n/q/?] n >> >> I said `y` here and lived happily ever after. > > Yes. Each time (many times, since the beginning of June) I went > through the solutions offered, each worse than the last. I consider > Bug #961990 to be just that - a bug. I do wish that if this bug is > not going to be fixed, that the maintainers would say so. Looking at it, I don't see anything which strikes me as qualifying as buggy. Can you clarify what about it you see as being a misbehavior problem? > The least "damaging" solution offered seemed to be, as you noted, to > remove libgcc1. I have often been tempted to do that, just to not > have 12 stale packages hanging around each time I update. I may end up > removing libgcc1, since I do not currently do any C programming, but I > hope that would not "come back to bite me". It appears that the software previously provided in libgcc1 is now being provided, in a newer version, in libgcc-s1. So you aren't losing any software, just changing which package it comes in. The only real downside of this is breaking dependency expectations from packages built against the previous package name. As long as you don't need to install any such packages, then you shouldn't have any problems. (Doing or not doing C programming isn't really relevant to whether you want to have a particular library installed; more important is whether you want to use any program which has been compiled against that library.) > On Sun, Jul 19, 2020 at 4:42 PM The Wanderer > wrote: > >> As he made clear later on, he rejected this because he has (or >> wants to >> have) packages from external repositories which depend on libgcc1 by >> that name and which he isn't willing to give up. >> >> IOW, not only is he running sid (unofficial motto: "whenever it breaks, >> you get to keep all the pieces"), he's also running a partial >> FrankenDebian (those external repositories' URLs indicate that they >> correspond to buster, not to sid), and is complaining that an apparently >> internally consistent state of packages in sid isn't consistent with the >> state of packages in those external repositories. > I am puzzled that you refer to a FrankenDebian, using external repositories. > The original installation was made 2018-08-10, just before the switch > from Stretch to Buster. I IMMEDIATELY upgraded to Unstable, with this > /etc/apt/sources.list: > I did not use Testing on the way to Unstable, and have always > scrupulously avoided third party repositories of any kind. And I have > no intention of trying to downgrade to Buster, or even Testing. I do > not mix repositories between Stable, Testing and Unstable. I really > do know better than that. > > > > Am I missing something? I'm sorry - I somehow managed to blindly misread bug #961990 as being (and involving comments) from you. Looking at it again, I see that it's from someone else, and the references to third-party repositories which mention buster are from that same person. My previous FrankenDebian, etc., comments should be taken as being in regard to that person. If you aren't interested in external repositories in that way, then you should have no hesitation about removing libgcc1 in favor of libgcc-s1. > BTW, I love the classic quote from George Bernard Shaw. > : ) Thanks. ^_^ -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug #961990
On 2020-07-19 at 16:27, Stefan Monnier wrote: >> This has been going on since the beginning of June, 2020, with no end in >> sight. >> Bug #961990 - IIUC, no activity since 2020-06-02. >> > You show a session where you reject all the proposed solutions, but > I don't see any justification why you reject those choices, so I don't > know what you consider to be a bug. > >> Remove the following packages: >> 1) libgcc1 [1:10.1.0-1 (now, unstable)] >> Accept this solution? [Y/n/q/?] n >> > I said `y` here and lived happily ever after. Yes. Each time (many times, since the beginning of June) I went through the solutions offered, each worse than the last. I consider Bug #961990 to be just that - a bug. I do wish that if this bug is not going to be fixed, that the maintainers would say so. The least "damaging" solution offered seemed to be, as you noted, to remove libgcc1. I have often been tempted to do that, just to not have 12 stale packages hanging around each time I update. I may end up removing libgcc1, since I do not currently do any C programming, but I hope that would not "come back to bite me". On Sun, Jul 19, 2020 at 4:42 PM The Wanderer wrote: > As he made clear later on, he rejected this because he has (or wants to > have) packages from external repositories which depend on libgcc1 by > that name and which he isn't willing to give up. > > IOW, not only is he running sid (unofficial motto: "whenever it breaks, > you get to keep all the pieces"), he's also running a partial > FrankenDebian (those external repositories' URLs indicate that they > correspond to buster, not to sid), and is complaining that an apparently > internally consistent state of packages in sid isn't consistent with the > state of packages in those external repositories. > > The only solution here I can think of offhand would be to rebuild the > packages from those external repositories to reflect the new package > names that exist in sid. As it happens, libgcc-s1 is also the package in > testing at the moment (albeit at an earlier version), so there's more of > a case for convincing the upstreams of those repositories to do that > rebuild now rather than later - but it's probably theoretically possible > to do it locally, too. > > (Well, switching to track a newer-than-buster version of those external > repositories, or to track buster itself instead of sid for the internal > repositories, would also resolve the conflict. But the former may not > exist, and the latter would involve significant downgrades from what > he's probably already installed, so neiterh is likely to be considered a > real solution.) > > -- >The Wanderer > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. -- George Bernard Shaw > I am puzzled that you refer to a FrankenDebian, using external repositories. The original installation was made 2018-08-10, just before the switch from Stretch to Buster. I IMMEDIATELY upgraded to Unstable, with this /etc/apt/sources.list: # deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST 20180310-11:21]/ buster contrib main non-free debhttp://ftp.us.debian.org/debian/unstable main non-free contrib deb-srchttp://ftp.us.debian.org/debian/unstable main non-free contrib # deb http://security.debian.org/debian-security buster/updates main non-free contrib # deb-src http://security.debian.org/debian-security buster/updates main non-free contrib # buster-updates, previously known as 'volatile' # deb http://ftp.us.debian.org/debian/buster-updates main non-free contrib # deb-src http://ftp.us.debian.org/debian/buster-updates main non-free contrib Here is my current /etc/apt/sources.list: # deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST 20180310-11:21]/ buster contrib> deb http://ftp.us.debian.org/debian/unstable main contrib non-free # deb-src http://ftp.us.debian.org/debian/unstable main contrib non-free # deb http://security.debian.org/debian-security buster/updates main contrib non-free # deb-src http://security.debian.org/debian-security buster/updates main contrib non-free # buster-updates, previously known as 'volatile' # deb http://ftp.us.debian.org/debian/buster-updates main contrib non-free # deb-src http://ftp.us.debian.org/debian/buster-updates main contrib non-free The only uncommented line seems to be: deb http://ftp.us.debian.org/debian/unstable main co
Re: Bug #961990
On 2020-07-19 at 16:27, Stefan Monnier wrote: >> This has been going on since the beginning of June, 2020, with no end in >> sight. >> Bug #961990 - IIUC, no activity since 2020-06-02. > > You show a session where you reject all the proposed solutions, but > I don't see any justification why you reject those choices, so I don't > know what you consider to be a bug. > >> Remove the following packages: >> 1) libgcc1 [1:10.1.0-1 (now, unstable)] >> Accept this solution? [Y/n/q/?] n > > I said `y` here and lived happily ever after. As he made clear later on, he rejected this because he has (or wants to have) packages from external repositories which depend on libgcc1 by that name and which he isn't willing to give up. IOW, not only is he running sid (unofficial motto: "whenever it breaks, you get to keep all the pieces"), he's also running a partial FrankenDebian (those external repositories' URLs indicate that they correspond to buster, not to sid), and is complaining that an apparently internally consistent state of packages in sid isn't consistent with the state of packages in those external repositories. The only solution here I can think of offhand would be to rebuild the packages from those external repositories to reflect the new package names that exist in sid. As it happens, libgcc-s1 is also the package in testing at the moment (albeit at an earlier version), so there's more of a case for convincing the upstreams of those repositories to do that rebuild now rather than later - but it's probably theoretically possible to do it locally, too. (Well, switching to track a newer-than-buster version of those external repositories, or to track buster itself instead of sid for the internal repositories, would also resolve the conflict. But the former may not exist, and the latter would involve significant downgrades from what he's probably already installed, so neiterh is likely to be considered a real solution.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug #961990
> This has been going on since the beginning of June, 2020, with no end in > sight. > Bug #961990 - IIUC, no activity since 2020-06-02. You show a session where you reject all the proposed solutions, but I don't see any justification why you reject those choices, so I don't know what you consider to be a bug. > Remove the following packages: > 1) libgcc1 [1:10.1.0-1 (now, unstable)] > Accept this solution? [Y/n/q/?] n I said `y` here and lived happily ever after. Stefan
Bug #961990
Hi. I'm running 64-bit Debian Unstable. This has been going on since the beginning of June, 2020, with no end in sight. Bug #961990 - IIUC, no activity since 2020-06-02. dimwit@dimwit:~$ date; sudo aptitude -Pvvv update Sun 19 Jul 2020 02:25:08 PM EDT Hit http://ftp.us.debian.org/debian unstable InRelease Current status: 0 (+0) broken, 12 (+0) upgradable, 59230 (+0) new. dimwit@dimwit:~$ date; sudo aptitude -Pvvv full-upgrade Sun 19 Jul 2020 02:25:20 PM EDT The following packages will be upgraded: gcc-10-base libatomic1 libcc1-0 libgcc-s1 libgfortran5 libgomp1 libitm1 liblsan0 libquadmath0 libstdc++6 libtsan0 libubsan1 12 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 2,368 kB of archives. After unpacking 10.2 kB will be used. The following packages have unmet dependencies: libgcc1 : Depends: gcc-10-base (= 10.1.0-1) but 10.1.0-6 is to be installed The following actions will resolve these dependencies: Keep the following packages at their current version: 1) gcc-10-base [10.1.0-1 (now)] 2) libatomic1 [10.1.0-1 (now)] 3) libcc1-0 [10.1.0-1 (now)] 4) libgcc-s1 [10.1.0-1 (now)] 5) libgfortran5 [10.1.0-1 (now)] 6) libgomp1 [10.1.0-1 (now)] 7) libitm1 [10.1.0-1 (now)] 8) liblsan0 [10.1.0-1 (now)] 9) libquadmath0 [10.1.0-1 (now)] 10) libstdc++6 [10.1.0-1 (now)] 11) libtsan0 [10.1.0-1 (now)] 12) libubsan1 [10.1.0-1 (now)] Accept this solution? [Y/n/q/?] n The following actions will resolve these dependencies: Remove the following packages: 1) libgcc1 [1:10.1.0-1 (now, unstable)] Accept this solution? [Y/n/q/?] n The following actions will resolve these dependencies: Remove the following packages: 1) build-essential [12.8 (now, unstable)] 2) g++ [4:9.2.1-3.1 (now, unstable)] 3) g++-9 [9.3.0-15 (now, unstable)] 4) gcc [4:9.2.1-3.1 (now, unstable)] 5) gcc-9 [9.3.0-15 (now, unstable)] 6) libgcc-9-dev [9.3.0-15 (now, unstable)] 7) libstdc++-9-dev [9.3.0-15 (now, unstable)] 8) libubsan1 [10.1.0-1 (now)] Install the following packages: 9) tcc [0.9.27-8 (unstable)] Keep the following packages at their current version: 10) gcc-10-base [10.1.0-1 (now)] 11) libatomic1 [10.1.0-1 (now)] 12) libcc1-0 [10.1.0-1 (now)] 13) libgcc-s1 [10.1.0-1 (now)] 14) libgfortran5 [10.1.0-1 (now)] 15) libgomp1 [10.1.0-1 (now)] 16) libitm1 [10.1.0-1 (now)] 17) liblsan0 [10.1.0-1 (now)] 18) libquadmath0 [10.1.0-1 (now)] 19) libstdc++6 [10.1.0-1 (now)] 20) libtsan0 [10.1.0-1 (now)] Leave the following dependencies unresolved: 21) dpkg-dev recommends build-essential 22) python3-pip recommends build-essential Accept this solution? [Y/n/q/?] n The following actions will resolve these dependencies: Remove the following packages: 1) build-essential [12.8 (now, unstable)] 2) g++ [4:9.2.1-3.1 (now, unstable)] 3) g++-9 [9.3.0-15 (now, unstable)] 4) gcc [4:9.2.1-3.1 (now, unstable)] 5) gcc-9 [9.3.0-15 (now, unstable)] 6) libcc1-0 [10.1.0-1 (now)] Install the following packages: 7) tcc [0.9.27-8 (unstable)] Keep the following packages at their current version: 8) gcc-10-base [10.1.0-1 (now)] 9) libatomic1 [10.1.0-1 (now)] 10) libgcc-s1 [10.1.0-1 (now)] 11) libgfortran5 [10.1.0-1 (now)] 12) libgomp1 [10.1.0-1 (now)] 13) libitm1 [10.1.0-1 (now)] 14) liblsan0 [10.1.0-1 (now)] 15) libquadmath0 [10.1.0-1 (now)] 16) libstdc++6 [10.1.0-1 (now)] 17) libtsan0 [10.1.0-1 (now)] 18) libubsan1 [10.1.0-1 (now)] Leave the following dependencies unresolved: 19) dpkg-dev recommends build-essential 20) python3-pip recommends build-essential Accept this solution? [Y/n/q/?] n The following actions will resolve these dependencies: Remove the following packages: 1) build-essential [12.8 (now, unstable)] 2) g++ [4:9.2.1-3.1 (now, unstable)] 3) g++-9 [9.3.0-15 (now, unstable)] 4) gcc [4:9.2.1-3.1 (now, unstable)] 5) gcc-9 [9.3.0-15 (now, unstable)] 6) libatomic1 [10.1.0-1 (now)] 7) libgcc-9-dev [9.3.0-15 (now, unstable)] 8) libstdc++-9-dev [9.3.0-15 (now, unstable)] Install the following packages: 9) tcc [0.9.27-8 (unstable)] Keep the following packages at their current version: 10) gcc-10-base [10.1.0-1 (now)] 11) libcc1-0 [10.1.0-1 (now)] 12) libgcc-s1 [10.1.0-1 (now)] 13) libgfortran5 [10.1.0-1 (now)] 14) libgomp1 [10.1.0-1 (now)] 15) libitm1 [10.1.0-1 (now)] 16) liblsan0 [10.1.0-1 (now)] 17) libquadmath0 [10.1.0-1 (now)] 18) libstdc++6 [10.1.0-1 (now)] 19) libtsan0 [10.1.0-1 (now)] 20) libubsan1 [10.1.0-1 (now)] Leave the following dependencies unresolved: 21) dpkg-dev recommends build-essential 22) python3-pip recommends build-essential . . . Accept this solution? [Y/n/q/?] q
