Re: [gentoo-dev] musl doesn't provide execinfo.h
On Mon, 23 Mar 2020 21:09:15 +0200 Jaco Kroon wrote: > Hi Michał, > > On 2020/03/23 18:25, Michał Górny wrote: > > > On Mon, 2020-03-23 at 10:21 +0200, Jaco Kroon wrote: > >> Hi, > >> > >> https://bugs.gentoo.org/713668 relates. > >> > >> * Searching for /usr/include/execinfo.h ... > >> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) > >> > >> As I see I can either add an explicit depend on glibc which I'd prefer > >> not to. Or someone from the musl team could possibly assist on how to > >> get the backtrace() set of calls on musl please? > >> > > As someone not on musl team, I think libunwind provides > > an implementation of backtrace(). > > > Thanks. That indeed looks interesting. > > Let's say I do go that route rather than simply no-opping it, would I > add a BDEPEND + RDEPEND of the form: > > || ( sys-libs/glibc sys-libs/libunwind ) > > To the ebuild? > > The code (./configure and actual "C" I'll manage). > > Kind Regards, > Jaco > > if libunwind can be used, you should use this dep elibc_musl? ( sys-libs/libunwind:= ) but idk if it's usable as is on musl. best way to check is to get musl stage3 tarball and test it. alpine does have a musl patch, but it seems they just patch it out completely. https://git.alpinelinux.org/aports/tree/main/dahdi-tools/fix-musl.patch -- Georgy Yakovlev pgpb0FaDXw7ig.pgp Description: PGP signature
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, 2020-03-23 at 14:26 -0500, William Hubbs wrote:
> On Mon, Mar 23, 2020 at 08:19:20PM +0100, Michał Górny wrote:
> > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> > > Hey all,
> > >
> > > it has been brought to my attention that there have been several
> > > backward-incompatible changes made to the python eclasses lately.
> >
> > Does 'several' in this case mean more than one? Please correct me if
> > I'm mistaken but the only change I can think of were the changes
> > in python-single-r1.
> >
> > > It is true that everything in ::gentoo has been fixed along with the
> > > changes to the eclasses; however, when a change like this goes into a
> > > widely used eclass it breaks overlays with little to no notice;
> > > especially since we do not require developers to be subscribed to this
> > > mailing list.
> > >
> > > I do agree that overlay authors are on their own to fix things, but we
> > > need to
> > > find a way to notify them when a breaking change is going into a widely
> > > used eclass and give them time to adjust their ebuilds.
> > >
> > > If the old way of doing things cannot be supported
> > > along side the new way the correct path forward is a new version of the
> > > eclass then a lastrites on the old version. That would give overlay
> > > authors time to switch to the new eclass.
> > >
> > > If the old and new way can be supported in the same code base, a
> > > reasonable way forward is to allow both ways to exist while ::gentoo is
> > > migrated to the new code path then do the equivalent of a lastrites for
> > > the old code path so overlay authors can adjust their ebuilds.
> > >
> >
> > The lesson was learned. If a similar change would be necessary
> > in the future, I will bump the eclass instead. I don't understand why
> > you bring that today.
>
> The change that blew us up today was
>
> https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258
I'm not sure if you're referring to that specific patch or the whole
thread. Because I don't see how that patch could break anything. It's
switching between two methods of getting scriptdir that were added
simultaneously.
> and this is the reason I brought it to the ml.
>
> The previous change that blew us up was
>
> https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871
I don't understand how that could break anything either. Before
the change, '${PYTHON_USEDEP}' wasn't valid (anymore) in dep strings,
so I don't see how anything could be more broken after the change.
In any case, there could be a little chance it could *fix* some old
ebuilds that just happened to use the right combination.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs: app-office/magicpoint, sys-apps/flashrom
Dear all, The following packages are up for grabs: app-office/magicpoint sys-apps/flashrom after retirement of the proxied maintainer. https://packages.gentoo.org/packages/app-office/magicpoint https://packages.gentoo.org/packages/sys-apps/flashrom There are open bugs. Some with patches: https://bugs.gentoo.org/709986 -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, Mar 23, 2020 at 08:19:20PM +0100, Michał Górny wrote: > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > > Hey all, > > > > it has been brought to my attention that there have been several > > backward-incompatible changes made to the python eclasses lately. > > Does 'several' in this case mean more than one? Please correct me if > I'm mistaken but the only change I can think of were the changes > in python-single-r1. > > > It is true that everything in ::gentoo has been fixed along with the > > changes to the eclasses; however, when a change like this goes into a > > widely used eclass it breaks overlays with little to no notice; > > especially since we do not require developers to be subscribed to this > > mailing list. > > > > I do agree that overlay authors are on their own to fix things, but we need > > to > > find a way to notify them when a breaking change is going into a widely > > used eclass and give them time to adjust their ebuilds. > > > > If the old way of doing things cannot be supported > > along side the new way the correct path forward is a new version of the > > eclass then a lastrites on the old version. That would give overlay > > authors time to switch to the new eclass. > > > > If the old and new way can be supported in the same code base, a > > reasonable way forward is to allow both ways to exist while ::gentoo is > > migrated to the new code path then do the equivalent of a lastrites for > > the old code path so overlay authors can adjust their ebuilds. > > > > The lesson was learned. If a similar change would be necessary > in the future, I will bump the eclass instead. I don't understand why > you bring that today. The change that blew us up today was https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258 and this is the reason I brought it to the ml. The previous change that blew us up was https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871 Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote: > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote: > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > > > Hey all, > > > > > > it has been brought to my attention that there have been several > > > backward-incompatible changes made to the python eclasses lately. > > > > > > It is true that everything in ::gentoo has been fixed along with the > > > changes to the eclasses; however, when a change like this goes into a > > > widely used eclass it breaks overlays with little to no notice; > > > especially since we do not require developers to be subscribed to this > > > mailing list. > > > > > > I do agree that overlay authors are on their own to fix things, but we > > > need to > > > find a way to notify them when a breaking change is going into a widely > > > used eclass and give them time to adjust their ebuilds. > > > > > > If the old way of doing things cannot be supported > > > along side the new way the correct path forward is a new version of the > > > eclass then a lastrites on the old version. That would give overlay > > > authors time to switch to the new eclass. > > > > > > If the old and new way can be supported in the same code base, a > > > reasonable way forward is to allow both ways to exist while ::gentoo is > > > migrated to the new code path then do the equivalent of a lastrites for > > > the old code path so overlay authors can adjust their ebuilds. > > > > > > Thoughts? > > > > > > William > > > > > > > All of this was announced with a 3 month timeout, using the right channels. > > Have > > you checked all python-related eclasses changes submitted to the ML? In this > > case, eqawarn would not have been possible, because the change involved > > dereferencing a variable. > > This is the change that broke us today. > > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258 > > Where is the three month timeout for it? > This is *not* a breaking API change. No public API changes, only a warning message is added. Private API functions aren't removed either. Don't you think it would be more appropriate to do some research or simply *ask* before spreading FUD? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > Hey all, > > it has been brought to my attention that there have been several > backward-incompatible changes made to the python eclasses lately. Does 'several' in this case mean more than one? Please correct me if I'm mistaken but the only change I can think of were the changes in python-single-r1. > It is true that everything in ::gentoo has been fixed along with the > changes to the eclasses; however, when a change like this goes into a > widely used eclass it breaks overlays with little to no notice; > especially since we do not require developers to be subscribed to this > mailing list. > > I do agree that overlay authors are on their own to fix things, but we need to > find a way to notify them when a breaking change is going into a widely > used eclass and give them time to adjust their ebuilds. > > If the old way of doing things cannot be supported > along side the new way the correct path forward is a new version of the > eclass then a lastrites on the old version. That would give overlay > authors time to switch to the new eclass. > > If the old and new way can be supported in the same code base, a > reasonable way forward is to allow both ways to exist while ::gentoo is > migrated to the new code path then do the equivalent of a lastrites for > the old code path so overlay authors can adjust their ebuilds. > The lesson was learned. If a similar change would be necessary in the future, I will bump the eclass instead. I don't understand why you bring that today. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, Mar 23, 2020 at 02:14:06PM -0500, William Hubbs wrote: > On Mon, Mar 23, 2020 at 08:03:47PM +0100, David Seifert wrote: > > On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote: > > > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote: > > > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > > > > > Hey all, > > > > > > > > > > it has been brought to my attention that there have been several > > > > > backward-incompatible changes made to the python eclasses lately. > > > > > > > > > > It is true that everything in ::gentoo has been fixed along with the > > > > > changes to the eclasses; however, when a change like this goes into a > > > > > widely used eclass it breaks overlays with little to no notice; > > > > > especially since we do not require developers to be subscribed to this > > > > > mailing list. > > > > > > > > > > I do agree that overlay authors are on their own to fix things, but we > > > > > need to > > > > > find a way to notify them when a breaking change is going into a > > > > > widely > > > > > used eclass and give them time to adjust their ebuilds. > > > > > > > > > > If the old way of doing things cannot be supported > > > > > along side the new way the correct path forward is a new version of > > > > > the > > > > > eclass then a lastrites on the old version. That would give overlay > > > > > authors time to switch to the new eclass. > > > > > > > > > > If the old and new way can be supported in the same code base, a > > > > > reasonable way forward is to allow both ways to exist while ::gentoo > > > > > is > > > > > migrated to the new code path then do the equivalent of a lastrites > > > > > for > > > > > the old code path so overlay authors can adjust their ebuilds. > > > > > > > > > > Thoughts? > > > > > > > > > > William > > > > > > > > > > > > > All of this was announced with a 3 month timeout, using the right > > > > channels. > > > > Have > > > > you checked all python-related eclasses changes submitted to the ML? In > > > > this > > > > case, eqawarn would not have been possible, because the change involved > > > > dereferencing a variable. > > > > > > This is the change that broke us today. > > > > > > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258 > > > > > > Where is the three month timeout for it? > > > > > > Thanks, > > > > > > William > > > > > > > Oh I thought you meant the python-single-r1 change from a month ago. > > The other one that is being pointed out to me is this one: > > https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871 > > Is that the python-single-r1 change you were talking about? > > If it is, what do we consider the appropriate channels for api change > announcements to be? Sorry about sending too quickly on this message. We have mostly fixed this one by now. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, Mar 23, 2020 at 08:03:47PM +0100, David Seifert wrote: > On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote: > > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote: > > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > > > > Hey all, > > > > > > > > it has been brought to my attention that there have been several > > > > backward-incompatible changes made to the python eclasses lately. > > > > > > > > It is true that everything in ::gentoo has been fixed along with the > > > > changes to the eclasses; however, when a change like this goes into a > > > > widely used eclass it breaks overlays with little to no notice; > > > > especially since we do not require developers to be subscribed to this > > > > mailing list. > > > > > > > > I do agree that overlay authors are on their own to fix things, but we > > > > need to > > > > find a way to notify them when a breaking change is going into a widely > > > > used eclass and give them time to adjust their ebuilds. > > > > > > > > If the old way of doing things cannot be supported > > > > along side the new way the correct path forward is a new version of the > > > > eclass then a lastrites on the old version. That would give overlay > > > > authors time to switch to the new eclass. > > > > > > > > If the old and new way can be supported in the same code base, a > > > > reasonable way forward is to allow both ways to exist while ::gentoo is > > > > migrated to the new code path then do the equivalent of a lastrites for > > > > the old code path so overlay authors can adjust their ebuilds. > > > > > > > > Thoughts? > > > > > > > > William > > > > > > > > > > All of this was announced with a 3 month timeout, using the right > > > channels. > > > Have > > > you checked all python-related eclasses changes submitted to the ML? In > > > this > > > case, eqawarn would not have been possible, because the change involved > > > dereferencing a variable. > > > > This is the change that broke us today. > > > > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258 > > > > Where is the three month timeout for it? > > > > Thanks, > > > > William > > > > Oh I thought you meant the python-single-r1 change from a month ago. The other one that is being pointed out to me is this one: https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871 Is that the python-single-r1 change you were talking about? If it is, what do we consider the appropriate channels for api change announcements to be? Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] musl doesn't provide execinfo.h
Hi Michał, On 2020/03/23 18:25, Michał Górny wrote: > On Mon, 2020-03-23 at 10:21 +0200, Jaco Kroon wrote: >> Hi, >> >> https://bugs.gentoo.org/713668 relates. >> >> * Searching for /usr/include/execinfo.h ... >> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) >> >> As I see I can either add an explicit depend on glibc which I'd prefer >> not to. Or someone from the musl team could possibly assist on how to >> get the backtrace() set of calls on musl please? >> > As someone not on musl team, I think libunwind provides > an implementation of backtrace(). > Thanks. That indeed looks interesting. Let's say I do go that route rather than simply no-opping it, would I add a BDEPEND + RDEPEND of the form: || ( sys-libs/glibc sys-libs/libunwind ) To the ebuild? The code (./configure and actual "C" I'll manage). Kind Regards, Jaco
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote: > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote: > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > > > Hey all, > > > > > > it has been brought to my attention that there have been several > > > backward-incompatible changes made to the python eclasses lately. > > > > > > It is true that everything in ::gentoo has been fixed along with the > > > changes to the eclasses; however, when a change like this goes into a > > > widely used eclass it breaks overlays with little to no notice; > > > especially since we do not require developers to be subscribed to this > > > mailing list. > > > > > > I do agree that overlay authors are on their own to fix things, but we > > > need to > > > find a way to notify them when a breaking change is going into a widely > > > used eclass and give them time to adjust their ebuilds. > > > > > > If the old way of doing things cannot be supported > > > along side the new way the correct path forward is a new version of the > > > eclass then a lastrites on the old version. That would give overlay > > > authors time to switch to the new eclass. > > > > > > If the old and new way can be supported in the same code base, a > > > reasonable way forward is to allow both ways to exist while ::gentoo is > > > migrated to the new code path then do the equivalent of a lastrites for > > > the old code path so overlay authors can adjust their ebuilds. > > > > > > Thoughts? > > > > > > William > > > > > > > All of this was announced with a 3 month timeout, using the right channels. > > Have > > you checked all python-related eclasses changes submitted to the ML? In this > > case, eqawarn would not have been possible, because the change involved > > dereferencing a variable. > > This is the change that broke us today. > > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258 > > Where is the three month timeout for it? > > Thanks, > > William > Oh I thought you meant the python-single-r1 change from a month ago.
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote: > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > > Hey all, > > > > it has been brought to my attention that there have been several > > backward-incompatible changes made to the python eclasses lately. > > > > It is true that everything in ::gentoo has been fixed along with the > > changes to the eclasses; however, when a change like this goes into a > > widely used eclass it breaks overlays with little to no notice; > > especially since we do not require developers to be subscribed to this > > mailing list. > > > > I do agree that overlay authors are on their own to fix things, but we need > > to > > find a way to notify them when a breaking change is going into a widely > > used eclass and give them time to adjust their ebuilds. > > > > If the old way of doing things cannot be supported > > along side the new way the correct path forward is a new version of the > > eclass then a lastrites on the old version. That would give overlay > > authors time to switch to the new eclass. > > > > If the old and new way can be supported in the same code base, a > > reasonable way forward is to allow both ways to exist while ::gentoo is > > migrated to the new code path then do the equivalent of a lastrites for > > the old code path so overlay authors can adjust their ebuilds. > > > > Thoughts? > > > > William > > > > All of this was announced with a 3 month timeout, using the right channels. > Have > you checked all python-related eclasses changes submitted to the ML? In this > case, eqawarn would not have been possible, because the change involved > dereferencing a variable. This is the change that broke us today. https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258 Where is the three month timeout for it? Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On 3/23/20 2:27 PM, Joonas Niilola wrote: > On 3/23/20 8:23 PM, William Hubbs wrote: >> but we need to >> find a way to notify them when a breaking change is going into a widely >> used eclass and give them time to adjust their ebuilds. >> >> >> Thoughts? >> > Subscribe to this mailing list. > > AFAIK all major changes have been posted here and pushed with some delay. > > -- juippis > > Indeed, that's what I'm doing with my popcorn `kernel`s (and also what most others have advised, even on the irc's). It's quiet enough to not clutter but useful. Aisha signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
[2020-03-23 20:27:51+0200] Joonas Niilola: > On 3/23/20 8:23 PM, William Hubbs wrote: > > but we need to > > find a way to notify them when a breaking change is going into a widely > > used eclass and give them time to adjust their ebuilds. > > > > > > Thoughts? > > > Subscribe to this mailing list. > > AFAIK all major changes have been posted here and pushed with some delay. If this one would be taken it would be nice to have breaking changes be noted as so in the Subject. I probably should but for packages in my overlay, I have no idea what eclasses are used and doesn't have much quality needs if any that I would read eclass changed to potentially improve the ebuilds in it. (I do read them for the eclasses that I use in the gentoo & guru repos)
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote: > Hey all, > > it has been brought to my attention that there have been several > backward-incompatible changes made to the python eclasses lately. > > It is true that everything in ::gentoo has been fixed along with the > changes to the eclasses; however, when a change like this goes into a > widely used eclass it breaks overlays with little to no notice; > especially since we do not require developers to be subscribed to this > mailing list. > > I do agree that overlay authors are on their own to fix things, but we need to > find a way to notify them when a breaking change is going into a widely > used eclass and give them time to adjust their ebuilds. > > If the old way of doing things cannot be supported > along side the new way the correct path forward is a new version of the > eclass then a lastrites on the old version. That would give overlay > authors time to switch to the new eclass. > > If the old and new way can be supported in the same code base, a > reasonable way forward is to allow both ways to exist while ::gentoo is > migrated to the new code path then do the equivalent of a lastrites for > the old code path so overlay authors can adjust their ebuilds. > > Thoughts? > > William > All of this was announced with a 3 month timeout, using the right channels. Have you checked all python-related eclasses changes submitted to the ML? In this case, eqawarn would not have been possible, because the change involved dereferencing a variable. Check the git-2 debacle: 6.5 years of deprecation, and still a bunch of overlays exploded. There comes a point where you just have to suck it up and move on.
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
On 3/23/20 8:23 PM, William Hubbs wrote: > but we need to > find a way to notify them when a breaking change is going into a widely > used eclass and give them time to adjust their ebuilds. > > > Thoughts? > Subscribe to this mailing list. AFAIK all major changes have been posted here and pushed with some delay. -- juippis signature.asc Description: OpenPGP digital signature
[gentoo-dev] rfc: backward-incompatible changes in eclasses
Hey all, it has been brought to my attention that there have been several backward-incompatible changes made to the python eclasses lately. It is true that everything in ::gentoo has been fixed along with the changes to the eclasses; however, when a change like this goes into a widely used eclass it breaks overlays with little to no notice; especially since we do not require developers to be subscribed to this mailing list. I do agree that overlay authors are on their own to fix things, but we need to find a way to notify them when a breaking change is going into a widely used eclass and give them time to adjust their ebuilds. If the old way of doing things cannot be supported along side the new way the correct path forward is a new version of the eclass then a lastrites on the old version. That would give overlay authors time to switch to the new eclass. If the old and new way can be supported in the same code base, a reasonable way forward is to allow both ways to exist while ::gentoo is migrated to the new code path then do the equivalent of a lastrites for the old code path so overlay authors can adjust their ebuilds. Thoughts? William signature.asc Description: Digital signature
Re: [gentoo-dev] musl doesn't provide execinfo.h
On Mon, 2020-03-23 at 10:21 +0200, Jaco Kroon wrote: > Hi, > > https://bugs.gentoo.org/713668 relates. > > * Searching for /usr/include/execinfo.h ... > sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) > > As I see I can either add an explicit depend on glibc which I'd prefer > not to. Or someone from the musl team could possibly assist on how to > get the backtrace() set of calls on musl please? > As someone not on musl team, I think libunwind provides an implementation of backtrace(). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dev.gentoo.org unreachable
On Mon, Mar 23, 2020 at 7:29 AM malc wrote: > On Mon, Mar 23, 2020 at 9:13 AM Jaco Kroon wrote: > > > > Hi All, > > > > Is there a known issue with dev.gentoo.org? > > https://infra-status.gentoo.org/ agrees with your analysis... (at > 10:50 UTC) I would keep checking there as infra wakes up and updates > the status. > > This is resolved now. -A
Re: [gentoo-dev] Last-rites: media-video/gtk-recordmydesktop
On Mon, 23 Mar 2020 00:13:46 +0100 Andreas Sturmlechner wrote: > # Andreas Sturmlechner (2020-03-22) > # Unmaintained revdep on dev-python/pygtk blocking its removal, py2-only > # Bug #710172, masked for removal in 30 days. > media-video/gtk-recordmydesktop You may want to suggest media-video/simplescreenrecorder as a good alternative. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpLIMw17qzq3.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] dev.gentoo.org unreachable
On Mon, Mar 23, 2020 at 9:13 AM Jaco Kroon wrote: > > Hi All, > > Is there a known issue with dev.gentoo.org? https://infra-status.gentoo.org/ agrees with your analysis... (at 10:50 UTC) I would keep checking there as infra wakes up and updates the status.
[gentoo-dev] dev.gentoo.org unreachable
Hi All, Is there a known issue with dev.gentoo.org? I initially thought it might just be a routing issue from our network but have since confirmed at least two other sources with the same problem. One of these are IPv4 only, the other two are trying IPv6 too. All failing. One v6 and v4: 1?: [LOCALHOST] 0.011ms pmtu 1500 1: 2c0f:f720::0:764d:28ff:fe3f:1a4d 0.324ms 1: 2c0f:f720::0:764d:28ff:fe3f:1a4d 0.285ms 2: 2c0f:f720::5 3.418ms 3: 2001:43f8:6d0::42 3.264ms 4: 2001:470:0:191::1 159.733ms 5: 2001:470:0:2cf::2 228.372ms 6: 2001:470:0:4b8::1 245.058ms 7: 2001:470:0:18e::2 251.433ms 8: 2001:470:0:22a::1 284.263ms 9: 2001:470:0:9b::2 283.906ms 10: 2001:470:0:9b::2 288.137ms pmtu 1280 10: no reply 1?: [LOCALHOST] pmtu 1500 1: 154.73.34.153 0.360ms 1: 154.73.34.153 0.236ms 2: 154.73.32.3 2.373ms 3: 197.96.224.9 3.090ms 4: 168.209.86.218 3.315ms asymm 6 5: 168.209.88.125 6.001ms 6: 196.26.0.62 5.804ms 7: 168.209.100.19 173.349ms 8: 149.6.148.133 179.961ms 9: 154.54.57.105 178.710ms 10: 154.54.82.34 232.281ms asymm 11 11: 154.54.0.221 244.550ms 12: 154.54.26.129 256.873ms 13: 154.54.7.129 280.141ms asymm 14 14: 154.54.42.165 265.994ms asymm 15 15: 154.54.31.89 285.354ms 16: 154.54.42.97 296.996ms 17: 154.54.44.73 306.417ms asymm 18 18: 154.54.31.78 320.279ms 19: 38.142.108.50 322.589ms asymm 20 20: 207.98.64.170 313.345ms asymm 21 21: 207.98.64.25 349.141ms asymm 16 22: 207.98.64.17 307.354ms asymm 16 23: no reply Kind Regards, Jaco
[gentoo-dev] musl doesn't provide execinfo.h
Hi, https://bugs.gentoo.org/713668 relates. * Searching for /usr/include/execinfo.h ... sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) As I see I can either add an explicit depend on glibc which I'd prefer not to. Or someone from the musl team could possibly assist on how to get the backtrace() set of calls on musl please? Alternatively I need to add a test and simply path debug.c to only provide stub function for print_backtrace(FILE *fp) that just does fprintf(fp, "No backtrace() available to print a backtrace.\n"); Suggestions? Kind Regards, Jaco
