Re: Re : Re: [gentoo-portage-dev] precisions on installed packages' dependencies

2020-03-23 Thread Zac Medico
On 3/23/20 3:21 PM, michael.lienha...@laposte.net wrote:
> - Zac Medico  a écrit :
> 
>>>  3. before removing a library, "ebuild unmerge" always checks if it is used 
>>> by another package: this means that installed packages' dependencies are 
>>> never broken.
>>
>> That's true if the package is removed via emerge --depclean, but emerge
>> --unmerge does not account for dependencies.
>>
>> Also, it's possible for dependencies of installed packages to be
>> temporarily broken by upgrades. In cases like this, the breakage will
>> eventually be resolved by a rebuild (which occurs automatically for slot
>> operator := deps), upgraded, or by emerge --depclean (which removes
>> unneeded packages).
> 
> Many thanks for your answers.
> They made me realize that the problem I'm facing is a bit more tricky than I 
> first quickly though.
> 
> I'll try to explain the problem, tell me if I'm not clear somewhere.
> 
> The goal of my tool is to have correct manipulation of package dependencies, 
> and in particular here, I focus on the packages that are installed but not in 
> the portage tree/a local overlay anymore (the problem does not occur for 
> other packages).
> It seems that installed packages do not store which are the actual cpv they 
> depend on. Correct?

Right, because unfortunately that's something that changes over time.

Also, we may not be able to pin it down at any given moment if we have
inconsistent || preferences as described here:

https://archives.gentoo.org/gentoo-dev/message/550d3859dea6d0fb0b39064628992634

> Hence, when an installed package cannot be updated/recompiled because it is 
> not in the tree anymore, like you said, its dependencies can be broken (due 
> to the package it depends on being updated).
> Currently, this issue is circumvented (only using depclean) by keeping the 
> libs: the package's dependencies are broken, but it's ok because it can still 
> run (which, in the end of the day, is what we want).
> However, from your answer, it seems that this fix is not entirely integrated 
> in the emerge/portage toolchain (like you said, emerge --unmerge removes 
> everything, and emerge -u removes the old libs).
> 
> To sum up, the problem I'm facing is that with the current way installed 
> packages are managed, we can break dependencies (and the only way to fix them 
> is to remove the installed package with the broken dependencies, that can 
> never be installed again).
> 
> Hence, for my tool, I have two solutions for that problem: either I forbid 
> for dependencies to ever be broken, or I allow it.
> 
> Solution 1: forbid broken dependencies.
> This requires to extend the information stored on installed package with the 
> list of the actual cpvs they depend (or at least the cp+slot, which is enough 
> to get back the cpvs).
> That way, I can say in the solver "if you want to keep that package, you need 
> to keep these packages as they currently are".
> However, I have no idea on how to do that, and doing this only for my tool 
> would mean that one cannot switch between emerge (quick) and my tool 
> (correct), which is a feature I think is essential.
> Do you think adding this new information to installed packages could be 
> integrated into emerge/portage itself? I could work on it (expect question 
> ^^), test it on my prototype, and do a pull request when everything's working.

It's possible to store this information in a cache of the most recently
calculated dependency graph.

> Solution 2: allow broken dependencies.
> Here, the idea is to use the same fix as is currently done with depclean, but 
> in my tool's planner (i.e., the part that install/unistall the packages) 
> directly.
> That way, I say in the solver "that installed package has no dependency", but 
> when I upgrade/remove packages, I say "Oh but wait, that other package still 
> need these libs, let's keep them".
> This solution may not require any change in portage/emerge, but I have no 
> idea on how to know which libs are needed by a package, and how to track 
> these libs owners without looking at every installed package's files (which 
> are stored in the CONTENT file, if I'm not mistaken).

For soname dependencies, we've got PROVIDES and REQUIRES metadata.

> Also, I wanted to use the ebuild tool to install/uninstall package, which is 
> not possible with this solution apparently.

Why not? Would the preserve-libs feature solve your problem?

> In case I need to implement this, could you give me some clue on how to 
> achieve it?
> 
> 
> Among these two solutions, I prefer the first one: we stay at the level of 
> package dependencies (and it looks simpler to implement).
> However, it is maybe easier/better to use the second approach, I don't know.
> Do you have some suggestions?

Well, there are a lot of upgrades that can't be performed without
temporarily breaking something, so the "forbid broken dependencies" idea
doesn't sound feasible to me.

> Thanks!
> Michael
-- 
Thanks,
Zac




Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-23 Thread Georgy Yakovlev
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 : Re: [gentoo-portage-dev] precisions on installed packages' dependencies

2020-03-23 Thread michael . lienhardt
- Zac Medico  a écrit :

> >  3. before removing a library, "ebuild unmerge" always checks if it is used 
> > by another package: this means that installed packages' dependencies are 
> > never broken.
> 
> That's true if the package is removed via emerge --depclean, but emerge
> --unmerge does not account for dependencies.
> 
> Also, it's possible for dependencies of installed packages to be
> temporarily broken by upgrades. In cases like this, the breakage will
> eventually be resolved by a rebuild (which occurs automatically for slot
> operator := deps), upgraded, or by emerge --depclean (which removes
> unneeded packages).

Many thanks for your answers.
They made me realize that the problem I'm facing is a bit more tricky than I 
first quickly though.

I'll try to explain the problem, tell me if I'm not clear somewhere.

The goal of my tool is to have correct manipulation of package dependencies, 
and in particular here, I focus on the packages that are installed but not in 
the portage tree/a local overlay anymore (the problem does not occur for other 
packages).
It seems that installed packages do not store which are the actual cpv they 
depend on. Correct?
Hence, when an installed package cannot be updated/recompiled because it is not 
in the tree anymore, like you said, its dependencies can be broken (due to the 
package it depends on being updated).
Currently, this issue is circumvented (only using depclean) by keeping the 
libs: the package's dependencies are broken, but it's ok because it can still 
run (which, in the end of the day, is what we want).
However, from your answer, it seems that this fix is not entirely integrated in 
the emerge/portage toolchain (like you said, emerge --unmerge removes 
everything, and emerge -u removes the old libs).

To sum up, the problem I'm facing is that with the current way installed 
packages are managed, we can break dependencies (and the only way to fix them 
is to remove the installed package with the broken dependencies, that can never 
be installed again).

Hence, for my tool, I have two solutions for that problem: either I forbid for 
dependencies to ever be broken, or I allow it.

Solution 1: forbid broken dependencies.
This requires to extend the information stored on installed package with the 
list of the actual cpvs they depend (or at least the cp+slot, which is enough 
to get back the cpvs).
That way, I can say in the solver "if you want to keep that package, you need 
to keep these packages as they currently are".
However, I have no idea on how to do that, and doing this only for my tool 
would mean that one cannot switch between emerge (quick) and my tool (correct), 
which is a feature I think is essential.
Do you think adding this new information to installed packages could be 
integrated into emerge/portage itself? I could work on it (expect question ^^), 
test it on my prototype, and do a pull request when everything's working.

Solution 2: allow broken dependencies.
Here, the idea is to use the same fix as is currently done with depclean, but 
in my tool's planner (i.e., the part that install/unistall the packages) 
directly.
That way, I say in the solver "that installed package has no dependency", but 
when I upgrade/remove packages, I say "Oh but wait, that other package still 
need these libs, let's keep them".
This solution may not require any change in portage/emerge, but I have no idea 
on how to know which libs are needed by a package, and how to track these libs 
owners without looking at every installed package's files (which are stored in 
the CONTENT file, if I'm not mistaken).
Also, I wanted to use the ebuild tool to install/uninstall package, which is 
not possible with this solution apparently.
In case I need to implement this, could you give me some clue on how to achieve 
it?


Among these two solutions, I prefer the first one: we stay at the level of 
package dependencies (and it looks simpler to implement).
However, it is maybe easier/better to use the second approach, I don't know.
Do you have some suggestions?

Thanks!
Michael



Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread Michał Górny
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

2020-03-23 Thread Jonas Stein
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

2020-03-23 Thread William Hubbs
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

2020-03-23 Thread Michał Górny
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

2020-03-23 Thread Michał Górny
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

2020-03-23 Thread William Hubbs
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

2020-03-23 Thread William Hubbs
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

2020-03-23 Thread Jaco Kroon
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

2020-03-23 Thread David Seifert
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

2020-03-23 Thread William Hubbs
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

2020-03-23 Thread Aisha Tammy

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 Thread Haelwenn (lanodan) Monnier
[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

2020-03-23 Thread David Seifert
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

2020-03-23 Thread 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.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread William Hubbs
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

2020-03-23 Thread Michał Górny
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

2020-03-23 Thread Alec Warner
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

2020-03-23 Thread James Le Cuirot
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

2020-03-23 Thread malc
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

2020-03-23 Thread Jaco Kroon
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

2020-03-23 Thread Jaco Kroon
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