Re: [gentoo-dev] Last rites: www-client/weboob

2020-03-27 Thread Zoltan Puskas
Hi,

app-office/kmymoney has dependency on weboob to import online
banking transactions. Also per linked bug there is 2.0 that is Python 3
compatible and there are ebuilds offered. Can we please reconsider this
and instead push for getting 2.0 into the tree?

Cheers,
Zoltan

On Fri, Mar 27, 2020 at 05:50:17PM +0100, Michał Górny wrote:
> # Michał Górny  (2020-03-27)
> # No Python 3 support.  Last touched by maintainer in 2014.
> # Removal in 30 days.  Bug #674734.
> www-client/weboob
> 
> -- 
> Best regards,
> Michał Górny
> 




signature.asc
Description: PGP signature


Re: [gentoo-dev] Adding hw-probe in Gentoo

2020-03-27 Thread Haelwenn (lanodan) Monnier
Hi,

[2020-03-28 00:15:41+0100] Conrad Kostecki:
> a longer time ago, there were some concerns about privacy reasons 
> discussed here. It took a long time, but there is now a new version 
> released with lot's of changes. Since all results are still by default 
> uploaded, It should be noted, that hw-probeuploads a 32-byte prefix of 
> salted SHA512 hash of MAC addresses and serial numbers to properly 
> identify unique computers and hard drives. Here is one example report of 
> one of my devices https://linux-hardware.org/?probe=6bc7d86b9c. FWICS, 
> sensetive informtion seems not to be present. I would like to gather 
> some opinion about here, if there are any objections about adding 
> hw-probe to Gentoo.

BSD systems also have a similar thing with posting a filtered dmesg
but IIRC their dmesg have much better information in them htan what 
you can get on linux.

This one has a huge bunch of information but it's basically hardware 
and bits of software configuration that most people already put on 
their websites and I'm pretty sure this kind of program is opt-in 
anyway.

You could have the same kind of issue with stuff like e-file or whatever 
was that third-party "Gentoo Social Compiling" thing which posted your 
compile time and error logs automatically.



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

2020-03-27 Thread Alexis Ballier
On Fri, 2020-03-27 at 19:07 -0400, Anthony G. Basile wrote:
> On 3/27/20 3:17 PM, Alexis Ballier wrote:
> > On Fri, 2020-03-27 at 08:03 -0400, Anthony G. Basile wrote:
> > > On 3/26/20 9:25 PM, Joshua Kinard wrote:
> > > > On 3/23/2020 04:21, 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?
> > > > > 
> > > > > 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
> > > > 
> > > > Some quick searching on google, it looks like the cleanest fix
> > > > for
> > > > that bug
> > > > is dahdi-tools needs to be patched to only include execinfo.h
> > > > or
> > > > only use
> > > > backtrace() on glibc-based systems, and that patch then sent to
> > > > the
> > > > dahdi-tools upstream developers for inclusion in a future
> > > > release.  That
> > > > way, we're not dragging that patch around forever in the tree
> > > > or in
> > > > the musl
> > > > overlay.
> > > > 
> > > > It also doesn't look like musl itself will ever implement
> > > > execinfo.h or
> > > > backtrace(), per this message in 2015 from the lead musl
> > > > developer:
> > > > https://www.openwall.com/lists/musl/2015/04/09/3
> > > > 
> > > 
> > > Correct.  I've been adding -standalone packages to provide for
> > > features
> > > like fts, obstack, argp,etc. which are bundled into glibc but not
> > > really
> > > under the POSIX standard.
> > > 
> > > So either we patch packages to turn off backtrace() or we add
> > > libunwind-standalone to the tree.
> > > 
> > 
> > BTW, we had libexecinfo for fbsd, which seems also present in
> > alpine:
> > https://pkgs.alpinelinux.org/package/edge/main/x86/libexecinfo
> > 
> > 
> 
> Had?  Is it in the tree now or should I look into adding it?

Restoring it: https://bugs.gentoo.org/683284




Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Zac Medico
On 3/27/20 4:12 PM, Alec Warner wrote:
> On Fri, Mar 27, 2020 at 3:54 PM Patrick McLean  > wrote:
> 
> On Fri, 27 Mar 2020 15:51:35 -0700
> Alec Warner mailto:anta...@gentoo.org>> wrote:
> 
> > On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean
> mailto:chutz...@gentoo.org>> wrote:
> >
> > > On Fri, 27 Mar 2020 14:48:53 -0700
> > > Matt Turner mailto:matts...@gentoo.org>>
> wrote:
> > > 
> > > > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean
> mailto:chutz...@gentoo.org>> 
> > > wrote: 
> > > > >
> > > > > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > > > > _python_impl_supported to a separate eclass, this allows
> overlays
> > > > > to easily support a different set of python implementations than
> > > > > ::gentoo without having to fork the entire suite of eclasses. 
> > > >
> > > > (I think the issue is that you have some packages that still need
> > > > Python 3.4. Correct me if I'm wrong)
> > > >
> > > > How many packages do you need to work with Python 3.4?
> Presumably just
> > > > a couple and then a pile of dependencies in ::gentoo?
> > > > 
> > >
> > > For our particular purpose, it's more complicated than that. We
> do not
> > > expect or want ::gentoo to try support Python 3.4 in any way. We
> have an
> > > overlay that is shared on a lot of machines, some of those
> machines are
> > > older than others. As such we still have ebuilds that only support
> > > python3_4 that still exist in the overlay. We would like it if the
> > > existence of these packages in the overlay, do not cause metadata
> > > generation or dependency calculation to explode on the more
> up-to-date
> > > machines.
> > > 
> >
> > > We do not need Python 3.4 packages to be installable on the newer
> > > machines, we just need them not to explode.
> > > 
> >
> > Couldn't you simply remove the ebuilds from the overlay entirely
> in this
> > case? It's my understanding that on the machines with the packages
> > installed, the merged package metadata is being used (which is why
> those
> > machines work) and since the newer machines don't have this merged
> package
> > metadata, they don't work properly.
> >
> 
> Sometimes we have to fix the older machines, so we have to keep
> everything around until none of our machines are using it any more.
> 
> 
> +Zac Medico  
> 
> I'm not following something then. One of the proposals earlier was "do
> not generate metadata for these ebuilds" which to me reads as "keep
> these ebuilds in the repo, but the ebuilds themselves will not be
> usable[0]." Then you go on to say that old machines need to be fixed
> occasionally, so either you need to reinstall a package or update it.
> The reinstall might be strictly possible from the vdb metadata, but the
> upgrade would require working repository metadata, which we said earlier
> we didn't want to generate.

The ebuilds may or may not be usable, depending on the snapshot of
::gentoo eclasses that they're paired with.

> (There is a different question of whether you could use a binpkg binhost
> to basically build versions of these packages and use those for
> reinstalls, because at least the binpkg metadata *is* nominally fixed in
> time and can be re-used easily and doesn't require eclass magic in
> theory, as the eclasses are bound in the environment.tar?) I suspect in
> essence it might be easier to just do what Robin suggested and use a
> frozen ::gentoo on the older machines.

We do use a frozen snapshot of ::gentoo on older machines. The issue is
that we've got a repository of ebuilds that can be used with many
different snapshots of ::gentoo, but we'd like to be able to support
python implementations that may not be officially supported by a
particular snapshot of ::gentoo eclasses.

> -A
> 
> [0] Perhaps the earlier proposals were ..slightly off. With more
> information it seems like what you want is to be able to easily maintain
> some python-3.4 ebuilds in your overlay, even though Gentoo is on to 3.6
> (and soon 3.7). I personally think the conversation would have gone much
> better had you just come out and said "hey we have a bunch of internal
> overlays with 3.4 and we need to keep the packages for another N months,
> how can we do this easily?" Instead of whatever happened. I tend to
> agree with mgorny that it's not simply carrying this single patch, but
> in reality it's a stronger commitment to build some kind of method to
> let you continue to support older python versions. Future changes might
> impact your ability to support your ebuilds and we have no real way of
> knowing if we broke you..so I can see why (irrespective of the tone of
> the conversation) he would be reticent to pick that up.

If you break us then that's fine, we'll deal 

[gentoo-dev] Last rites: net-dns/dnsimple-dyndns

2020-03-27 Thread Rafael Goncalves Martins
# Rafael G. Martins  (2020-03-27)
# Python 2 only. Uses old version of DNSimple API.
# Removal in 30 days.  Bug #712960
net-dns/dnsimple-dyndns

-- 
Rafael


Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Alec Warner
On Fri, Mar 27, 2020 at 3:59 PM Alec Warner  wrote:

>
>
> On Fri, Mar 27, 2020 at 3:10 PM Samuel Bernardo <
> samuelbernardo.m...@gmail.com> wrote:
>
>> Hi Alec,
>>
>> On 3/27/20 7:27 PM, Alec Warner wrote:
>> > The Gentoo Mirror system is basically a set of scripts that syncs the
>> > ::gentoo repository, enumerates all URIs in SRC_URI for all ebuilds,
>> > and fetches them.
>> > It doesn't enumerate anything in any overlays. Overlay authors are
>> > required to point SRC_URI somewhere useful (typically to an upstream
>> URI.)
>> >
>> > Gentoo Developers use "https://dev.gentoo.org/~user/distfiles; as an
>> > origin URI for items where either Gentoo *is* the upstream, or there
>> > is no upstream (e.g. a custom Gentoo patchset.) Any origin URI can be
>> > used; this just happens to be some free hosting that Gentoo Developers
>> > have access to use.
>> >
>> > -A
>>
>> Thank you for your clarification.
>>
>> So what happens when RESTRIC=mirror is used inside ebuild for an overlay
>> in git.gentoo.org?
>>
>
> I want to again re-iterate; gentoo doesn't mirror anything outside of
> gentoo.git, even if its hosted on git.gentoo.org. gentoo.git is literally
> the only repo the Gentoo Mirror system is processing.
>
> RESTRICT itself then has two potential usage sites.
>  - MIrroring. We already determined that for overlays, no mirroring
> occurs, so we can ignore that for your case.
>  - Fetching. Basically if something is RESTRICT=mirror, then we don't need
> to bother consulting the mirror network, because we know from the RESTRICT
> that mirror network will not have a copy. Fetching then proceeds from the
> origin URI (e.g. the URI in SRC_URI.)
>

I should point you at man portage(5) (search for mirrors), which has more
detail on how to set up a non-gentoo mirror network.

-A


>
>
>>
>> So, thinking on site reliability, should it be a good choice to upload
>> the necessary tar.gz, for example, to gitlab or github community
>> services using git lfs as an alternative to "https://dev.gentoo.org/;?
>>
>
> For most content served from dev.gentoo.org its not RESTRICT=mirror, so
> the reliability of the origin URI is not an issue in most cases (because it
> should be on the gentoo mirror network.)
> Cases where it is not include:
>  - RESTRICT=mirror content.
>  - Content that is pushed to an ebuild but hasn't been mirrored yet.
>- This can take up to 4h (or longer if the origin is unavailable.)
>
> In practice this hasn't been a big enough issue to do something more
> complicated. Many proposals have already been floated but none have ever
> been put into place.
> It also turns out that most of the time dev.gentoo.org is available (and
> so again, its reliability is not a major issue.) I understand that it
> recently had an incident; I'm not really convinced it was high enough
> impact to make operational changes.
>
> -A
>
>
>>
>> Best,
>>
>> Samuel
>>
>>
>>


[gentoo-dev] Adding hw-probe in Gentoo

2020-03-27 Thread Conrad Kostecki

Hi all,

a longer time ago, there were some concerns about privacy reasons 
discussed here. It took a long time, but there is now a new version 
released with lot's of changes. Since all results are still by default 
uploaded, It should be noted, that hw-probeuploads a 32-byte prefix of 
salted SHA512 hash of MAC addresses and serial numbers to properly 
identify unique computers and hard drives. Here is one example report of 
one of my devices https://linux-hardware.org/?probe=6bc7d86b9c. FWICS, 
sensetive informtion seems not to be present. I would like to gather 
some opinion about here, if there are any objections about adding 
hw-probe to Gentoo.


Cheers, Conrad



Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Alec Warner
On Fri, Mar 27, 2020 at 3:54 PM Patrick McLean  wrote:

> On Fri, 27 Mar 2020 15:51:35 -0700
> Alec Warner  wrote:
>
> > On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean 
> wrote:
> >
> > > On Fri, 27 Mar 2020 14:48:53 -0700
> > > Matt Turner  wrote:
> > >
> > > > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean 
>
> > > wrote:
> > > > >
> > > > > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > > > > _python_impl_supported to a separate eclass, this allows overlays
> > > > > to easily support a different set of python implementations than
> > > > > ::gentoo without having to fork the entire suite of eclasses.
> > > >
> > > > (I think the issue is that you have some packages that still need
> > > > Python 3.4. Correct me if I'm wrong)
> > > >
> > > > How many packages do you need to work with Python 3.4? Presumably
> just
> > > > a couple and then a pile of dependencies in ::gentoo?
> > > >
> > >
> > > For our particular purpose, it's more complicated than that. We do not
> > > expect or want ::gentoo to try support Python 3.4 in any way. We have
> an
> > > overlay that is shared on a lot of machines, some of those machines are
> > > older than others. As such we still have ebuilds that only support
> > > python3_4 that still exist in the overlay. We would like it if the
> > > existence of these packages in the overlay, do not cause metadata
> > > generation or dependency calculation to explode on the more up-to-date
> > > machines.
> > >
> >
> > > We do not need Python 3.4 packages to be installable on the newer
> > > machines, we just need them not to explode.
> > >
> >
> > Couldn't you simply remove the ebuilds from the overlay entirely in this
> > case? It's my understanding that on the machines with the packages
> > installed, the merged package metadata is being used (which is why those
> > machines work) and since the newer machines don't have this merged
> package
> > metadata, they don't work properly.
> >
>
> Sometimes we have to fix the older machines, so we have to keep
> everything around until none of our machines are using it any more.
>

+Zac Medico 

I'm not following something then. One of the proposals earlier was "do not
generate metadata for these ebuilds" which to me reads as "keep these
ebuilds in the repo, but the ebuilds themselves will not be usable[0]."
Then you go on to say that old machines need to be fixed occasionally, so
either you need to reinstall a package or update it. The reinstall might be
strictly possible from the vdb metadata, but the upgrade would require
working repository metadata, which we said earlier we didn't want to
generate.

(There is a different question of whether you could use a binpkg binhost to
basically build versions of these packages and use those for reinstalls,
because at least the binpkg metadata *is* nominally fixed in time and can
be re-used easily and doesn't require eclass magic in theory, as the
eclasses are bound in the environment.tar?) I suspect in essence it might
be easier to just do what Robin suggested and use a frozen ::gentoo on the
older machines.

-A

[0] Perhaps the earlier proposals were ..slightly off. With more
information it seems like what you want is to be able to easily maintain
some python-3.4 ebuilds in your overlay, even though Gentoo is on to 3.6
(and soon 3.7). I personally think the conversation would have gone much
better had you just come out and said "hey we have a bunch of internal
overlays with 3.4 and we need to keep the packages for another N months,
how can we do this easily?" Instead of whatever happened. I tend to agree
with mgorny that it's not simply carrying this single patch, but in reality
it's a stronger commitment to build some kind of method to let you continue
to support older python versions. Future changes might impact your ability
to support your ebuilds and we have no real way of knowing if we broke
you..so I can see why (irrespective of the tone of the conversation) he
would be reticent to pick that up.


>
> > >
> > > I am trying to come up with a solution that *any* overlay can use, I
> > > am happy to do work towards that end. Basically, it would be very
> > > nice if there was a minimal eclass that handles all the python
> > > version compatibility. Almost everything in the eclasses does not care
> > > about versions.
> > >
> > > This is not meant to be something just for our usage, we want this to
> > > be usable for *any* overlay, and are more than happy to make things as
> > > generic as possible. If some overlay wants to support Python 3.10
> alpha,
> > > resurrect jython support, or add Ironpython support, without forking
> > > all the eclasses, I would like to think that could be doable as well.
> > >
> > >
>
>


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

2020-03-27 Thread Anthony G. Basile
On 3/27/20 3:17 PM, Alexis Ballier wrote:
> On Fri, 2020-03-27 at 08:03 -0400, Anthony G. Basile wrote:
>> On 3/26/20 9:25 PM, Joshua Kinard wrote:
>>> On 3/23/2020 04:21, 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?

 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
>>>
>>> Some quick searching on google, it looks like the cleanest fix for
>>> that bug
>>> is dahdi-tools needs to be patched to only include execinfo.h or
>>> only use
>>> backtrace() on glibc-based systems, and that patch then sent to the
>>> dahdi-tools upstream developers for inclusion in a future
>>> release.  That
>>> way, we're not dragging that patch around forever in the tree or in
>>> the musl
>>> overlay.
>>>
>>> It also doesn't look like musl itself will ever implement
>>> execinfo.h or
>>> backtrace(), per this message in 2015 from the lead musl developer:
>>> https://www.openwall.com/lists/musl/2015/04/09/3
>>>
>>
>> Correct.  I've been adding -standalone packages to provide for
>> features
>> like fts, obstack, argp,etc. which are bundled into glibc but not
>> really
>> under the POSIX standard.
>>
>> So either we patch packages to turn off backtrace() or we add
>> libunwind-standalone to the tree.
>>
> 
> 
> BTW, we had libexecinfo for fbsd, which seems also present in alpine:
> https://pkgs.alpinelinux.org/package/edge/main/x86/libexecinfo
> 
> 


Had?  Is it in the tree now or should I look into adding it?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [PATCH] qt5-build.eclass: support sysroot builds

2020-03-27 Thread David Michael
On Fri, Mar 27, 2020 at 4:49 PM James Le Cuirot  wrote:
> On Fri, 27 Mar 2020 13:10:34 -0400
> David Michael  wrote:
>
> > I'd like to be able to install qt5 packages in a sysroot for staging,
> > and this is an initial patch for it.  The pkg-config variables might not
> > be required, but it seemed appropriate to pass the sysroot-configured
> > versions through the build.  There are a few caveats:
> >
> >   - The upstream configure scripts do some bad things like this:
> > https://code.qt.io/cgit/qt/qtbase.git/tree/configure.pri#n363
> > That makes the build fail for systems using lib64 (e.g. amd64).  I'm
> > able to work around this by defining PKG_CONFIG_LIBDIR for dev-qt/*.
>
> Indeed, that sucks. We should probably patch that out. I don't know
> what it means where it says "or use -pkg-config to override this test",
> do you?

I'm not sure, since -pkg-config is already being used by the eclass.
Maybe it was supposed to reference the -force-pkg-config option, which
I haven't tried.

> I suspect you could define PKG_CONFIG_LIBDIR=/ or anywhere that
> simply exists and it will still work because our wrapper redefines that
> variable anyway.
>
> >   - This isn't for real cross-compiling.  There are places where it
> > tries to execute cross-compiled programs that I haven't investigated
> > yet, so this is only for building a sysroot for an architecture
> > compatible with the build system for now.
>
> Understood. I did try to do cross-compiling with Qt4 once upon a time
> and I did make a little headway but it wasn't fun.
>
> >   - The qt packages depend on each other being installed in / as well as
> > the sysroot, so their ebuilds will need BDEPENDs added.
>
> I imagine you'd at least need qtcore for qmake and moc. Probably not
> the rest though?

I needed qtcore, qtgui, and qtwidgets in /, but it's possible there
are just bad configure scripts that I didn't dig into yet.  As for VLC
deps:
  - qtcore works as is
  - qtgui requires qtcore for bootstrap-private in /
  - qtwidgets requires qtgui in / for some opengl check
  - qtsvg and qtx11extras need qmake to build, but their packages will
be empty unless qtwidgets is installed in /

> >   - I've only gotten to testing a few packages that are dependencies of
> > other applications (like VLC), so I may be missing breakages.
> >
> > The patch basically just sets -sysroot when $SYSROOT is defined.  It
> > also needs to set -extprefix to the normal prefix, since otherwise it
> > would default to installing into /sysroot/prefix.  Is anyone involved in
> > qt maintenance more experienced with this and able to comment?
>
> I'm not the Qt guy but I am the cross guy. I'm not in a position to
> test this right now but it looks good and I love the simplicity of it.
> It's a hell of a lot simpler than Qt4 was. To be honest, we should be
> setting QMAKE_PKG_CONFIG regardless.



Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Alec Warner
On Fri, Mar 27, 2020 at 3:10 PM Samuel Bernardo <
samuelbernardo.m...@gmail.com> wrote:

> Hi Alec,
>
> On 3/27/20 7:27 PM, Alec Warner wrote:
> > The Gentoo Mirror system is basically a set of scripts that syncs the
> > ::gentoo repository, enumerates all URIs in SRC_URI for all ebuilds,
> > and fetches them.
> > It doesn't enumerate anything in any overlays. Overlay authors are
> > required to point SRC_URI somewhere useful (typically to an upstream
> URI.)
> >
> > Gentoo Developers use "https://dev.gentoo.org/~user/distfiles; as an
> > origin URI for items where either Gentoo *is* the upstream, or there
> > is no upstream (e.g. a custom Gentoo patchset.) Any origin URI can be
> > used; this just happens to be some free hosting that Gentoo Developers
> > have access to use.
> >
> > -A
>
> Thank you for your clarification.
>
> So what happens when RESTRIC=mirror is used inside ebuild for an overlay
> in git.gentoo.org?
>

I want to again re-iterate; gentoo doesn't mirror anything outside of
gentoo.git, even if its hosted on git.gentoo.org. gentoo.git is literally
the only repo the Gentoo Mirror system is processing.

RESTRICT itself then has two potential usage sites.
 - MIrroring. We already determined that for overlays, no mirroring occurs,
so we can ignore that for your case.
 - Fetching. Basically if something is RESTRICT=mirror, then we don't need
to bother consulting the mirror network, because we know from the RESTRICT
that mirror network will not have a copy. Fetching then proceeds from the
origin URI (e.g. the URI in SRC_URI.)


>
> So, thinking on site reliability, should it be a good choice to upload
> the necessary tar.gz, for example, to gitlab or github community
> services using git lfs as an alternative to "https://dev.gentoo.org/;?
>

For most content served from dev.gentoo.org its not RESTRICT=mirror, so the
reliability of the origin URI is not an issue in most cases (because it
should be on the gentoo mirror network.)
Cases where it is not include:
 - RESTRICT=mirror content.
 - Content that is pushed to an ebuild but hasn't been mirrored yet.
   - This can take up to 4h (or longer if the origin is unavailable.)

In practice this hasn't been a big enough issue to do something more
complicated. Many proposals have already been floated but none have ever
been put into place.
It also turns out that most of the time dev.gentoo.org is available (and so
again, its reliability is not a major issue.) I understand that it recently
had an incident; I'm not really convinced it was high enough impact to make
operational changes.

-A


>
> Best,
>
> Samuel
>
>
>


Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Patrick McLean
On Fri, 27 Mar 2020 15:51:35 -0700
Alec Warner  wrote:

> On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean  wrote:
> 
> > On Fri, 27 Mar 2020 14:48:53 -0700
> > Matt Turner  wrote:
> >  
> > > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean   
> > wrote:  
> > > >
> > > > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > > > _python_impl_supported to a separate eclass, this allows overlays
> > > > to easily support a different set of python implementations than
> > > > ::gentoo without having to fork the entire suite of eclasses.  
> > >
> > > (I think the issue is that you have some packages that still need
> > > Python 3.4. Correct me if I'm wrong)
> > >
> > > How many packages do you need to work with Python 3.4? Presumably just
> > > a couple and then a pile of dependencies in ::gentoo?
> > >  
> >
> > For our particular purpose, it's more complicated than that. We do not
> > expect or want ::gentoo to try support Python 3.4 in any way. We have an
> > overlay that is shared on a lot of machines, some of those machines are
> > older than others. As such we still have ebuilds that only support
> > python3_4 that still exist in the overlay. We would like it if the
> > existence of these packages in the overlay, do not cause metadata
> > generation or dependency calculation to explode on the more up-to-date
> > machines.
> >  
> 
> > We do not need Python 3.4 packages to be installable on the newer
> > machines, we just need them not to explode.
> >  
> 
> Couldn't you simply remove the ebuilds from the overlay entirely in this
> case? It's my understanding that on the machines with the packages
> installed, the merged package metadata is being used (which is why those
> machines work) and since the newer machines don't have this merged package
> metadata, they don't work properly.
> 

Sometimes we have to fix the older machines, so we have to keep
everything around until none of our machines are using it any more.

> 
> >
> > I am trying to come up with a solution that *any* overlay can use, I
> > am happy to do work towards that end. Basically, it would be very
> > nice if there was a minimal eclass that handles all the python
> > version compatibility. Almost everything in the eclasses does not care
> > about versions.
> >
> > This is not meant to be something just for our usage, we want this to
> > be usable for *any* overlay, and are more than happy to make things as
> > generic as possible. If some overlay wants to support Python 3.10 alpha,
> > resurrect jython support, or add Ironpython support, without forking
> > all the eclasses, I would like to think that could be doable as well.
> >
> >  




Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Alec Warner
On Fri, Mar 27, 2020 at 3:11 PM Patrick McLean  wrote:

> On Fri, 27 Mar 2020 14:48:53 -0700
> Matt Turner  wrote:
>
> > On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean 
> wrote:
> > >
> > > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > > _python_impl_supported to a separate eclass, this allows overlays
> > > to easily support a different set of python implementations than
> > > ::gentoo without having to fork the entire suite of eclasses.
> >
> > (I think the issue is that you have some packages that still need
> > Python 3.4. Correct me if I'm wrong)
> >
> > How many packages do you need to work with Python 3.4? Presumably just
> > a couple and then a pile of dependencies in ::gentoo?
> >
>
> For our particular purpose, it's more complicated than that. We do not
> expect or want ::gentoo to try support Python 3.4 in any way. We have an
> overlay that is shared on a lot of machines, some of those machines are
> older than others. As such we still have ebuilds that only support
> python3_4 that still exist in the overlay. We would like it if the
> existence of these packages in the overlay, do not cause metadata
> generation or dependency calculation to explode on the more up-to-date
> machines.
>

> We do not need Python 3.4 packages to be installable on the newer
> machines, we just need them not to explode.
>

Couldn't you simply remove the ebuilds from the overlay entirely in this
case? It's my understanding that on the machines with the packages
installed, the merged package metadata is being used (which is why those
machines work) and since the newer machines don't have this merged package
metadata, they don't work properly.

-A


>
> I am trying to come up with a solution that *any* overlay can use, I
> am happy to do work towards that end. Basically, it would be very
> nice if there was a minimal eclass that handles all the python
> version compatibility. Almost everything in the eclasses does not care
> about versions.
>
> This is not meant to be something just for our usage, we want this to
> be usable for *any* overlay, and are more than happy to make things as
> generic as possible. If some overlay wants to support Python 3.10 alpha,
> resurrect jython support, or add Ironpython support, without forking
> all the eclasses, I would like to think that could be doable as well.
>
>


Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-27 Thread William Hubbs
On Fri, Mar 27, 2020 at 06:54:25AM +0100, Michał Górny wrote:
> On Thu, 2020-03-26 at 22:12 +0100, Ulrich Mueller wrote:
> > > > > > > On Thu, 26 Mar 2020, William Hubbs wrote:
> > >  If there's a way inside an eclass to check that the ebuild inheriting
> > > it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
> > > and this variable is set.
> > 
> > Oh please, not this again. An ebuild or eclass is supposed to work the
> > same everywhere, independent of the repo it is located in.
> > 
> > Why don't you simply copy the eclass to your overlay and do the changes
> > there?
> > 
> 
> They did, and then they complained that every few months they have to
> update it.  See the big slander mail from William.

Michal,

I already responded here on the list and apologized for the way I
presented the original issues.

So, I would appreciate it if you drop the slander accusation.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Patrick McLean
On Fri, 27 Mar 2020 14:48:53 -0700
Matt Turner  wrote:

> On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean  wrote:
> >
> > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > _python_impl_supported to a separate eclass, this allows overlays
> > to easily support a different set of python implementations than
> > ::gentoo without having to fork the entire suite of eclasses.  
> 
> (I think the issue is that you have some packages that still need
> Python 3.4. Correct me if I'm wrong)
> 
> How many packages do you need to work with Python 3.4? Presumably just
> a couple and then a pile of dependencies in ::gentoo?
> 

For our particular purpose, it's more complicated than that. We do not
expect or want ::gentoo to try support Python 3.4 in any way. We have an
overlay that is shared on a lot of machines, some of those machines are
older than others. As such we still have ebuilds that only support
python3_4 that still exist in the overlay. We would like it if the
existence of these packages in the overlay, do not cause metadata
generation or dependency calculation to explode on the more up-to-date
machines.

We do not need Python 3.4 packages to be installable on the newer
machines, we just need them not to explode.

I am trying to come up with a solution that *any* overlay can use, I
am happy to do work towards that end. Basically, it would be very
nice if there was a minimal eclass that handles all the python 
version compatibility. Almost everything in the eclasses does not care
about versions.

This is not meant to be something just for our usage, we want this to
be usable for *any* overlay, and are more than happy to make things as
generic as possible. If some overlay wants to support Python 3.10 alpha,
resurrect jython support, or add Ironpython support, without forking
all the eclasses, I would like to think that could be doable as well.



Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Samuel Bernardo
Hi Alec,

On 3/27/20 7:27 PM, Alec Warner wrote:
> The Gentoo Mirror system is basically a set of scripts that syncs the
> ::gentoo repository, enumerates all URIs in SRC_URI for all ebuilds,
> and fetches them.
> It doesn't enumerate anything in any overlays. Overlay authors are
> required to point SRC_URI somewhere useful (typically to an upstream URI.)
>
> Gentoo Developers use "https://dev.gentoo.org/~user/distfiles; as an
> origin URI for items where either Gentoo *is* the upstream, or there
> is no upstream (e.g. a custom Gentoo patchset.) Any origin URI can be
> used; this just happens to be some free hosting that Gentoo Developers
> have access to use.
>
> -A

Thank you for your clarification.

So what happens when RESTRIC=mirror is used inside ebuild for an overlay
in git.gentoo.org?

So, thinking on site reliability, should it be a good choice to upload
the necessary tar.gz, for example, to gitlab or github community
services using git lfs as an alternative to "https://dev.gentoo.org/;?

Best,

Samuel




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Matt Turner
On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean  wrote:
>
> This patch splits the definition of _PYTHON_ALL_IMPLS and
> _python_impl_supported to a separate eclass, this allows overlays
> to easily support a different set of python implementations than
> ::gentoo without having to fork the entire suite of eclasses.

(I think the issue is that you have some packages that still need
Python 3.4. Correct me if I'm wrong)

How many packages do you need to work with Python 3.4? Presumably just
a couple and then a pile of dependencies in ::gentoo?



Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Michał Górny
On Fri, 2020-03-27 at 06:53 +0100, Michał Górny wrote:
> 
> To say it bluntly: if you want to do stupid things, do them yourselves
> and don't expect others to help.  You get paid for that.  We just waste
> our time.

I'm sorry, this paragraph turned out to be aggressive.  I didn't mean to
insult anyone.  I retract what I said here, and apologize to anyone
offended by it.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Michał Górny
On Fri, 2020-03-27 at 13:22 -0700, Patrick McLean wrote:
> On Fri, 27 Mar 2020 06:53:13 +0100
> Michał Górny  wrote:
> 
> > On Thu, 2020-03-26 at 14:03 -0700, Patrick McLean wrote:
> > > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > > _python_impl_supported to a separate eclass, this allows overlays
> > > to easily support a different set of python implementations than
> > > ::gentoo without having to fork the entire suite of eclasses.  
> > 
> > NAK.  This increases the maintenance effort (even if it means having to
> > open yet another file) for *zero* gain to Gentoo users.  Your policy is
> > entirely broken by design and I'm against supporting it officially.
> > 
> > The existing number of eclasses is already causing confusion and added
> > maintenance effort, and it has strong justification in *a lot of shared
> > code*.
> > 
> > To say it bluntly: if you want to do stupid things, do them yourselves
> > and don't expect others to help.  You get paid for that.  We just waste
> > our time.
> > 
> It can hard to keep the size of network we have in sync with upstream,
> and we have quite a large number of internal repositories. The
> approaches we are using are trying to strike a balance between
> backwards compatibility and moving forward.
> 
> We get paid to do our job, which sometimes coincides with doing
> upstream Gentoo work, and often doesn't. We have a policy to work
> upstream wherever possible, this often makes certain types of tasks
> take significantly more effort than if we just decided to fork
> everything and work an internal overlay. These small changes are an
> attempt to reduce the extra work that working upstream can create (we
> generally work to support the general use case of all Gentoo users, not
> just our limited use cases).
> 
> Would Gentoo as a whole be better served if we just forked everything
> and stopped trying to contribute as much as possible upstream? Are some
> small changes to some shared code to help us worth the amount of
> contributions that we push back upstream.

I was thinking about it, and how about you ask Portage people to provide
an option to silently ignore dying ebuilds, rather than trying hard to
prevent the eclass from exploding when it's supposed to explode?  That
would certainly be better than turning the eclasses into a minefield,
and expecting me to consider 'will this cause some eclass fork to
explode?' every time I change some internal eclass bit.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] qt5-build.eclass: support sysroot builds

2020-03-27 Thread James Le Cuirot
On Fri, 27 Mar 2020 13:10:34 -0400
David Michael  wrote:

> I'd like to be able to install qt5 packages in a sysroot for staging,
> and this is an initial patch for it.  The pkg-config variables might not
> be required, but it seemed appropriate to pass the sysroot-configured
> versions through the build.  There are a few caveats:
> 
>   - The upstream configure scripts do some bad things like this:
> https://code.qt.io/cgit/qt/qtbase.git/tree/configure.pri#n363
> That makes the build fail for systems using lib64 (e.g. amd64).  I'm
> able to work around this by defining PKG_CONFIG_LIBDIR for dev-qt/*.

Indeed, that sucks. We should probably patch that out. I don't know
what it means where it says "or use -pkg-config to override this test",
do you? I suspect you could define PKG_CONFIG_LIBDIR=/ or anywhere that
simply exists and it will still work because our wrapper redefines that
variable anyway.

>   - This isn't for real cross-compiling.  There are places where it
> tries to execute cross-compiled programs that I haven't investigated
> yet, so this is only for building a sysroot for an architecture
> compatible with the build system for now.

Understood. I did try to do cross-compiling with Qt4 once upon a time
and I did make a little headway but it wasn't fun.

>   - The qt packages depend on each other being installed in / as well as
> the sysroot, so their ebuilds will need BDEPENDs added.

I imagine you'd at least need qtcore for qmake and moc. Probably not
the rest though?

>   - I've only gotten to testing a few packages that are dependencies of
> other applications (like VLC), so I may be missing breakages.
> 
> The patch basically just sets -sysroot when $SYSROOT is defined.  It
> also needs to set -extprefix to the normal prefix, since otherwise it
> would default to installing into /sysroot/prefix.  Is anyone involved in
> qt maintenance more experienced with this and able to comment?

I'm not the Qt guy but I am the cross guy. I'm not in a position to
test this right now but it looks good and I love the simplicity of it.
It's a hell of a lot simpler than Qt4 was. To be honest, we should be
setting QMAKE_PKG_CONFIG regardless.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgppueAPzt7VC.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-27 Thread Patrick McLean
On Fri, 27 Mar 2020 06:53:13 +0100
Michał Górny  wrote:

> On Thu, 2020-03-26 at 14:03 -0700, Patrick McLean wrote:
> > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > _python_impl_supported to a separate eclass, this allows overlays
> > to easily support a different set of python implementations than
> > ::gentoo without having to fork the entire suite of eclasses.  
> 
> NAK.  This increases the maintenance effort (even if it means having to
> open yet another file) for *zero* gain to Gentoo users.  Your policy is
> entirely broken by design and I'm against supporting it officially.
> 
> The existing number of eclasses is already causing confusion and added
> maintenance effort, and it has strong justification in *a lot of shared
> code*.
> 
> To say it bluntly: if you want to do stupid things, do them yourselves
> and don't expect others to help.  You get paid for that.  We just waste
> our time.
> 
It can hard to keep the size of network we have in sync with upstream,
and we have quite a large number of internal repositories. The
approaches we are using are trying to strike a balance between
backwards compatibility and moving forward.

We get paid to do our job, which sometimes coincides with doing
upstream Gentoo work, and often doesn't. We have a policy to work
upstream wherever possible, this often makes certain types of tasks
take significantly more effort than if we just decided to fork
everything and work an internal overlay. These small changes are an
attempt to reduce the extra work that working upstream can create (we
generally work to support the general use case of all Gentoo users, not
just our limited use cases).

Would Gentoo as a whole be better served if we just forked everything
and stopped trying to contribute as much as possible upstream? Are some
small changes to some shared code to help us worth the amount of
contributions that we push back upstream.



Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Alec Warner
On Fri, Mar 27, 2020 at 5:17 AM Samuel Bernardo <
samuelbernardo.m...@gmail.com> wrote:

> Hi again Michał,
> On 3/27/20 11:48 AM, Michał Górny wrote:
> > Nope, just ::gentoo.  Minus ebuilds with RESTRICT=mirror.
>
> I have some doubts after reading the mirror documentation[1] in the
> context of personal overlays (not official).
>
> There is two procedures defined as I could understand:
> - manually upload a file to mirror://gentoo, scp it to
> dev.gentoo.org:/space/distfiles-local
>
> - having SRC_URI defined as
> SRC_URI="https://dev.gentoo.org/~myname/distfiles/${P}.tar.gz; to avoid
> namespace collisions with RESTRIC=mirror in ebuild would be uploaded
> automatically
>
> The use of mirror://gentoo directly is a deprecated policy. So it must
> be used https instead.
>
> 1) Did I understand it right?
>
> 2) What is dev.gentoo.org:~/public_html? Do this means that is only
> available to Gentoo official developers the access to the mirror[2]?
>
>
The Gentoo Mirror system is basically a set of scripts that syncs the
::gentoo repository, enumerates all URIs in SRC_URI for all ebuilds, and
fetches them.
It doesn't enumerate anything in any overlays. Overlay authors are required
to point SRC_URI somewhere useful (typically to an upstream URI.)

Gentoo Developers use "https://dev.gentoo.org/~user/distfiles; as an origin
URI for items where either Gentoo *is* the upstream, or there is no
upstream (e.g. a custom Gentoo patchset.) Any origin URI can be used; this
just happens to be some free hosting that Gentoo Developers have access to
use.

-A



> Best,
>
> Samuel
>
> [1] https://devmanual.gentoo.org/general-concepts/mirrors/index.html
>
> [2] https://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Webspace
>
>
>


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

2020-03-27 Thread Alexis Ballier
On Fri, 2020-03-27 at 08:03 -0400, Anthony G. Basile wrote:
> On 3/26/20 9:25 PM, Joshua Kinard wrote:
> > On 3/23/2020 04:21, 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?
> > > 
> > > 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
> > 
> > Some quick searching on google, it looks like the cleanest fix for
> > that bug
> > is dahdi-tools needs to be patched to only include execinfo.h or
> > only use
> > backtrace() on glibc-based systems, and that patch then sent to the
> > dahdi-tools upstream developers for inclusion in a future
> > release.  That
> > way, we're not dragging that patch around forever in the tree or in
> > the musl
> > overlay.
> > 
> > It also doesn't look like musl itself will ever implement
> > execinfo.h or
> > backtrace(), per this message in 2015 from the lead musl developer:
> > https://www.openwall.com/lists/musl/2015/04/09/3
> > 
> 
> Correct.  I've been adding -standalone packages to provide for
> features
> like fts, obstack, argp,etc. which are bundled into glibc but not
> really
> under the POSIX standard.
> 
> So either we patch packages to turn off backtrace() or we add
> libunwind-standalone to the tree.
> 


BTW, we had libexecinfo for fbsd, which seems also present in alpine:
https://pkgs.alpinelinux.org/package/edge/main/x86/libexecinfo




Re: [gentoo-portage-dev] [PATCH] process: Unshare UTS namespace, and set hostname to 'localhost'

2020-03-27 Thread Zac Medico
On 3/27/20 9:05 AM, Michał Górny wrote:
> Use UTS namespace to override hostname when network-sandbox is enabled.
> Set it to 'localhost' as that has a better chance of being present
> in /etc/hosts.  This fixes tests in some packages that try to connect
> to localhost via hostname obtained using gethostname(), e.g. docker-py,
> and suffer resolution problems due to the system hostname not being
> defined in /etc/hosts.
> ---
>  lib/portage/process.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/portage/process.py b/lib/portage/process.py
> index c1fc4bcf6..0f9789acb 100644
> --- a/lib/portage/process.py
> +++ b/lib/portage/process.py
> @@ -348,12 +348,14 @@ def spawn(mycommand, env=None, opt_name=None, 
> fd_pipes=None, returnpid=False,
>   if unshare_net or unshare_ipc or unshare_mount or unshare_pid:
>   # from /usr/include/bits/sched.h
>   CLONE_NEWNS = 0x0002
> + CLONE_NEWUTS = 0x0400
>   CLONE_NEWIPC = 0x0800
>   CLONE_NEWPID = 0x2000
>   CLONE_NEWNET = 0x4000
>  
>   if unshare_net:
> - unshare_flags |= CLONE_NEWNET
> + # UTS namespace to override hostname
> + unshare_flags |= CLONE_NEWNET | CLONE_NEWUTS
>   if unshare_ipc:
>   unshare_flags |= CLONE_NEWIPC
>   if unshare_mount:
> @@ -704,6 +706,8 @@ def _exec(binary, mycommand, opt_name, fd_pipes,
>   
> noiselevel=-1)
>   os._exit(1)
>   if unshare_net:
> + # use 'localhost' to 
> avoid hostname resolution problems
> + 
> socket.sethostname('localhost')
>   
> _configure_loopback_interface()
>   except AttributeError:
>   # unshare() not supported by libc
> 

Looks good with latest changes in
https://github.com/gentoo/portage/pull/539. Please merge.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-vcs/pwclient

2020-03-27 Thread Michał Górny
# Michał Górny  (2020-03-27)
# Unmaintained.  Not tested for py3.7.  Last bumped in 2015.
# Bad quality ebuild.
# Removal in 30 days.  Bug #710230.
dev-vcs/pwclient

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-util/fatrace

2020-03-27 Thread Michał Górny
# Michał Górny  (2020-03-27)
# Unmaintained.  Not tested for py3.7.  Last bumped in 2017.
# Bad quality ebuild.
# Removal in 30 days.  Bug #710226.
dev-util/fatrace

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH] qt5-build.eclass: support sysroot builds

2020-03-27 Thread David Michael
Signed-off-by: David Michael 
---

Hi,

I'd like to be able to install qt5 packages in a sysroot for staging,
and this is an initial patch for it.  The pkg-config variables might not
be required, but it seemed appropriate to pass the sysroot-configured
versions through the build.  There are a few caveats:

  - The upstream configure scripts do some bad things like this:
https://code.qt.io/cgit/qt/qtbase.git/tree/configure.pri#n363
That makes the build fail for systems using lib64 (e.g. amd64).  I'm
able to work around this by defining PKG_CONFIG_LIBDIR for dev-qt/*.

  - This isn't for real cross-compiling.  There are places where it
tries to execute cross-compiled programs that I haven't investigated
yet, so this is only for building a sysroot for an architecture
compatible with the build system for now.

  - The qt packages depend on each other being installed in / as well as
the sysroot, so their ebuilds will need BDEPENDs added.

  - I've only gotten to testing a few packages that are dependencies of
other applications (like VLC), so I may be missing breakages.

The patch basically just sets -sysroot when $SYSROOT is defined.  It
also needs to set -extprefix to the normal prefix, since otherwise it
would default to installing into /sysroot/prefix.  Is anyone involved in
qt maintenance more experienced with this and able to comment?

Thanks.

David

 eclass/qt5-build.eclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/eclass/qt5-build.eclass b/eclass/qt5-build.eclass
index 70e9be80c98..7fe39e6a23b 100644
--- a/eclass/qt5-build.eclass
+++ b/eclass/qt5-build.eclass
@@ -479,7 +479,7 @@ qt5_symlink_tools_to_build_dir() {
 # Runs ./configure for modules belonging to qtbase.
 qt5_base_configure() {
# setup toolchain variables used by configure
-   tc-export AR CC CXX OBJDUMP RANLIB STRIP
+   tc-export AR CC CXX OBJDUMP PKG_CONFIG RANLIB STRIP
export LD="$(tc-getCXX)"
 
# bug 633838
@@ -487,6 +487,8 @@ qt5_base_configure() {
 
# configure arguments
local conf=(
+   ${SYSROOT:+-extprefix "${QT5_PREFIX}" -sysroot "${SYSROOT}"}
+
# installation paths
-prefix "${QT5_PREFIX}"
-bindir "${QT5_BINDIR}"
@@ -677,6 +679,7 @@ qt5_qmake_args() {
QMAKE_LINK=\"$(tc-getCXX)\" \
QMAKE_LINK_SHLIB=\"$(tc-getCXX)\" \
QMAKE_OBJCOPY=\"$(tc-getOBJCOPY)\" \
+   QMAKE_PKG_CONFIG=\"$(tc-getPKG_CONFIG)\" \
QMAKE_RANLIB= \
QMAKE_STRIP=\"$(tc-getSTRIP)\" \
QMAKE_CFLAGS=\"${CFLAGS}\" \
@@ -716,6 +719,7 @@ qt5_qmake() {
QMAKE_LINK="$(tc-getCXX)" \
QMAKE_LINK_SHLIB="$(tc-getCXX)" \
QMAKE_OBJCOPY="$(tc-getOBJCOPY)" \
+   QMAKE_PKG_CONFIG="$(tc-getPKG_CONFIG)" \
QMAKE_RANLIB= \
QMAKE_STRIP="$(tc-getSTRIP)" \
QMAKE_CFLAGS="${CFLAGS}" \
-- 
2.21.1




[gentoo-dev] Last rites: dev-python/ufoLib

2020-03-27 Thread Michał Górny
# Michał Górny  (2020-03-27)
# It was integrated into dev-python/fonttools, and has no reverse
# dependencies.
# Removal in 30 days.  Bug #682146.
dev-python/ufoLib

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Missing ebuild for Mirror and CI scripts

2020-03-27 Thread Samuel Bernardo
Hi Mike,

On 3/27/20 4:31 PM, Mike Gilbert wrote:
> On Fri, Mar 27, 2020 at 12:19 PM Samuel Bernardo
>  wrote:
>> Dear all,
>>
>> Would it be possible to create official ebuilds for Gentoo
>> infrastructure projects, such as:
>>
>> https://github.com/mgorny/repo-mirror-ci
>>
>> https://github.com/mgorny/pkgcheck-result-parser
>>
> Neither repo has any tagged "releases". I don't see how an ebuild
> would be particularly useful. How do you intend to use them?

I was looking into the Gentoo Build Service[1] project and then realized
that you already have the tools I could use for my local CI.

For instance, looking into both projects that are being used in Gentoo
Infrastructure I could create easily my own development and
infrastructure environment using third party resources.

If the repositories owner doesn't want to create the tags I could fork
them, create the releases and publish the ebuilds in my overlay.

But I believe the owner would create them and then we could have
official ebuilds... I can ask him gently if he don't mind to create tags.

Best,

Samuel

[1] https://wiki.gentoo.org/wiki/Project:Build_Service




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: www-client/weboob

2020-03-27 Thread Michał Górny
# Michał Górny  (2020-03-27)
# No Python 3 support.  Last touched by maintainer in 2014.
# Removal in 30 days.  Bug #674734.
www-client/weboob

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Missing ebuild for Mirror and CI scripts

2020-03-27 Thread Mike Gilbert
On Fri, Mar 27, 2020 at 12:19 PM Samuel Bernardo
 wrote:
>
> Dear all,
>
> Would it be possible to create official ebuilds for Gentoo
> infrastructure projects, such as:
>
> https://github.com/mgorny/repo-mirror-ci
>
> https://github.com/mgorny/pkgcheck-result-parser
>

Neither repo has any tagged "releases". I don't see how an ebuild
would be particularly useful. How do you intend to use them?



Re: [gentoo-dev] Missing ebuild for Mirror and CI scripts

2020-03-27 Thread Michał Górny
On Fri, 2020-03-27 at 16:19 +, Samuel Bernardo wrote:
> Dear all,
> 
> Would it be possible to create official ebuilds for Gentoo
> infrastructure projects, such as:
> 
> https://github.com/mgorny/repo-mirror-ci
> 
> https://github.com/mgorny/pkgcheck-result-parser
> 

I don't know.  They were designed to run from git checkout.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Missing ebuild for Mirror and CI scripts

2020-03-27 Thread Samuel Bernardo
Dear all,

Would it be possible to create official ebuilds for Gentoo
infrastructure projects, such as:

https://github.com/mgorny/repo-mirror-ci

https://github.com/mgorny/pkgcheck-result-parser

Thank you,

Samuel




signature.asc
Description: OpenPGP digital signature


[gentoo-portage-dev] [PATCH] process: Unshare UTS namespace, and set hostname to 'localhost'

2020-03-27 Thread Michał Górny
Use UTS namespace to override hostname when network-sandbox is enabled.
Set it to 'localhost' as that has a better chance of being present
in /etc/hosts.  This fixes tests in some packages that try to connect
to localhost via hostname obtained using gethostname(), e.g. docker-py,
and suffer resolution problems due to the system hostname not being
defined in /etc/hosts.
---
 lib/portage/process.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/portage/process.py b/lib/portage/process.py
index c1fc4bcf6..0f9789acb 100644
--- a/lib/portage/process.py
+++ b/lib/portage/process.py
@@ -348,12 +348,14 @@ def spawn(mycommand, env=None, opt_name=None, 
fd_pipes=None, returnpid=False,
if unshare_net or unshare_ipc or unshare_mount or unshare_pid:
# from /usr/include/bits/sched.h
CLONE_NEWNS = 0x0002
+   CLONE_NEWUTS = 0x0400
CLONE_NEWIPC = 0x0800
CLONE_NEWPID = 0x2000
CLONE_NEWNET = 0x4000
 
if unshare_net:
-   unshare_flags |= CLONE_NEWNET
+   # UTS namespace to override hostname
+   unshare_flags |= CLONE_NEWNET | CLONE_NEWUTS
if unshare_ipc:
unshare_flags |= CLONE_NEWIPC
if unshare_mount:
@@ -704,6 +706,8 @@ def _exec(binary, mycommand, opt_name, fd_pipes,

noiselevel=-1)
os._exit(1)
if unshare_net:
+   # use 'localhost' to 
avoid hostname resolution problems
+   
socket.sethostname('localhost')

_configure_loopback_interface()
except AttributeError:
# unshare() not supported by libc
-- 
2.26.0




Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Michał Górny
On Fri, 2020-03-27 at 12:17 +, Samuel Bernardo wrote:
> Hi again Michał,
> On 3/27/20 11:48 AM, Michał Górny wrote:
> > Nope, just ::gentoo.  Minus ebuilds with RESTRICT=mirror.
> 
> I have some doubts after reading the mirror documentation[1] in the
> context of personal overlays (not official).
> 
> There is two procedures defined as I could understand:
> - manually upload a file to mirror://gentoo, scp it to
> dev.gentoo.org:/space/distfiles-local
> 
> - having SRC_URI defined as
> SRC_URI="https://dev.gentoo.org/~myname/distfiles/${P}.tar.gz; to avoid
> namespace collisions with RESTRIC=mirror in ebuild would be uploaded
> automatically
> 
> The use of mirror://gentoo directly is a deprecated policy. So it must
> be used https instead.
> 
> 1) Did I understand it right?

Yes, I think so.

> 
> 2) What is dev.gentoo.org:~/public_html? Do this means that is only
> available to Gentoo official developers the access to the mirror[2]?

It's just a web server.  Technically, you can use any server, either
private or public, as long as it provides reliable download.

Yes, only developers and proxied maintainers whose packages are
in ::gentoo.  In the latter case, we either upload their files for them
or they use some other hosting.

> 
> Best,
> 
> Samuel
> 
> [1] https://devmanual.gentoo.org/general-concepts/mirrors/index.html
> 
> [2] https://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Webspace
> 
> 

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2020-03-27 Thread michael . lienhardt


- Alec Warner  a écrit :
> On Tue, Mar 24, 2020 at 11:31 AM  wrote:
> > However, I still doubt that only storing the soname dependencies is enough.
> > Consider package A (that cannot be recompiled) that depends on package B
> > which provides lib L.so.
> > B is recompiled with different use flags, which put different
> > functionalities in L.so.
> > The dependencies of A are still satisfied (B is installed, L.so is
> > available), but since the content of L.so changed, A cannot execute anymore.
> > Hypothetically, can this scenario occur?
> > Can this scenario occur in practice?
> > Is there a way in emerge/portage to avoid it?


> > You have far more experience than me on this, and it would be nice for me
> > to know what I'm up against.
> 
> A lot of this has to do with the specifics of how package managers manage
> system state, as well as various quirks of subsets of the tree. For
> example, a perl upgrade (X->Y) will often break perl modules who expect
> perl-X, but get perl-Y. So one fix is to try to keep perl-X installed (so
> we SLOT perl and have N perls installed.) Then you need to decide which
> version of perl to build things against (X or Y, or both?) We took this
> tactic in the python ecosystem; but perl is not slotted in Gentoo, and so
> upgrading perl breaks all perl modules. There is a tool
> (gentoo-perl-cleaner) that will walk the deptree and fix all of these
> broken packages that you run after an upgrade.
> 
> I'm not sure it's strictly avoidable. You could build perl-Y, then rebuild
> all perl-modules against perl-Y, then merge the entire result to the
> livefs. This will reduce the breakage time but likely not eliminate it;
> plus it seems hard to implement in practice without modern filesystem tools
> (overlayfs, btrfs, zfs or similar tech to make it atomic.) It also doesn't
> account for executing code. What happens to perl-X code that is executing
> when you unmerge perl-X? The short answer is that code might break and
> 'proper' management means you should restart services after an upgrade
> (something Gentoo doesn't typically do; but is common in Debian for
> example.)

Many thanks for this answer.
To sum up what I understood, the problem is not really the dependencies, but 
which recompilation (and service restart) are triggered with an update.
In gentoo, there is the ":=" slot operator (and others similar) in dependencies 
that trigger the recompilation when the dependency's slot change, but this is 
the only existing mechanism.
And this is why every time perl changes, the compilation of its modules is not 
triggered and they are most probably broken.
Correct?
And then, in this context, keeping the installed packages' dependencies 
consistent is up to debate: packages will get broken in any case...
It is clearly impossible to have a tool that automatically detect all 
implementation dependency breakage.

Again, there's something I probably don't see: why was slot operators chosen 
(among other possibilities) as a mechanism to trigger recompilation?
I'm very grateful to you all for the time you take to read and answer my 
questions.

Best,
Michael



Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Rich Freeman
On Fri, Mar 27, 2020 at 7:33 AM Michał Górny  wrote:
>
> On Fri, 2020-03-27 at 11:29 +, Samuel Bernardo wrote:
>
> > Same question for unpack context when using directly the source
> > repository with vcs functions.
>
> VCS ebuilds generally suck, for multiple reasons.  We allow users to use
> them but with minimal support.  However, e.g. git-r3 supports local
> mirrors to resolve some problems.
>

Any guides on using that from an ebuild maintenance standpoint?  The
eclass docs make it appear more for local sysadmin use vs as a way to
distribute things, but I could be reading into it.

Usually my solution to VCS ebuilds when that is all upstream supports
is to just create my own github mirror of the repo, tag an appropriate
commit, and then fetch the resulting tarball directly as a non-VCS
ebuild.  Essentially I end up running my own private fork of upstream.
At least, this is what I do for actual releases that upstream can't be
bothered to release properly - for a live - VCS ebuild I just
point to upstream.

I don't believe Gentoo has any kind of recommended/standardized
solution for this, but having ebuilds point to my own private fork of
things obviously is non-ideal.  However, I think it is still more
transparent than just bundling up a tarball manually and sticking it
in my devspace since at least with my forked repo everybody can see
where it came from and what state it is in, and of course it is easier
to maintain.

If there is a more preferred way of doing this I'd be interested to
hear about it.

-- 
Rich



Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Samuel Bernardo
Hi again Michał,
On 3/27/20 11:48 AM, Michał Górny wrote:
> Nope, just ::gentoo.  Minus ebuilds with RESTRICT=mirror.

I have some doubts after reading the mirror documentation[1] in the
context of personal overlays (not official).

There is two procedures defined as I could understand:
- manually upload a file to mirror://gentoo, scp it to
dev.gentoo.org:/space/distfiles-local

- having SRC_URI defined as
SRC_URI="https://dev.gentoo.org/~myname/distfiles/${P}.tar.gz; to avoid
namespace collisions with RESTRIC=mirror in ebuild would be uploaded
automatically

The use of mirror://gentoo directly is a deprecated policy. So it must
be used https instead.

1) Did I understand it right?

2) What is dev.gentoo.org:~/public_html? Do this means that is only
available to Gentoo official developers the access to the mirror[2]?

Best,

Samuel

[1] https://devmanual.gentoo.org/general-concepts/mirrors/index.html

[2] https://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Webspace




signature.asc
Description: OpenPGP digital signature


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

2020-03-27 Thread Anthony G. Basile
On 3/26/20 9:25 PM, Joshua Kinard wrote:
> On 3/23/2020 04:21, 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?
>>
>> 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
> 
> Some quick searching on google, it looks like the cleanest fix for that bug
> is dahdi-tools needs to be patched to only include execinfo.h or only use
> backtrace() on glibc-based systems, and that patch then sent to the
> dahdi-tools upstream developers for inclusion in a future release.  That
> way, we're not dragging that patch around forever in the tree or in the musl
> overlay.
> 
> It also doesn't look like musl itself will ever implement execinfo.h or
> backtrace(), per this message in 2015 from the lead musl developer:
> https://www.openwall.com/lists/musl/2015/04/09/3
> 

Correct.  I've been adding -standalone packages to provide for features
like fts, obstack, argp,etc. which are bundled into glibc but not really
under the POSIX standard.

So either we patch packages to turn off backtrace() or we add
libunwind-standalone to the tree.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Michał Górny
On Fri, 2020-03-27 at 11:45 +, Samuel Bernardo wrote:
> Hi Michał,
> 
> On 3/27/20 11:33 AM, Michał Górny wrote:
> > SRC_URI is well-defined, and that makes it possible for us and users to
> > develop consistent solutions.  We have Gentoo mirror network to increase
> > reliability when upstream servers fail.  Users can deploy local mirrors
> > to increase reliability further, improve throughput and make things work
> > in semi-isolated networks.
> 
> This is news for me. So to see if I understand the Gentoo mirror
> network, everything I place in SRC_URI is already mirrored when using my
> personal overlay in git.gentoo.org?

Nope, just ::gentoo.  Minus ebuilds with RESTRICT=mirror.

> 
> > > Same question for unpack context when using directly the source
> > > repository with vcs functions.
> > VCS ebuilds generally suck, for multiple reasons.  We allow users to use
> > them but with minimal support.  However, e.g. git-r3 supports local
> > mirrors to resolve some problems.
> 
> So, using local mirrors means that is the responsibility of the end user
> to review the ebuilds and create, for example, the local git mirror
> repository and then define EGIT_MIRROR_URI in make.conf to override for
> all ebuilds?
> 

Yes.  The mirrors use the same format as git-r3.eclass distdir, so it's
mostly useful to clone repositories from your other Gentoo system.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Samuel Bernardo
Hi Michał,

On 3/27/20 11:33 AM, Michał Górny wrote:
> SRC_URI is well-defined, and that makes it possible for us and users to
> develop consistent solutions.  We have Gentoo mirror network to increase
> reliability when upstream servers fail.  Users can deploy local mirrors
> to increase reliability further, improve throughput and make things work
> in semi-isolated networks.

This is news for me. So to see if I understand the Gentoo mirror
network, everything I place in SRC_URI is already mirrored when using my
personal overlay in git.gentoo.org?

>> Same question for unpack context when using directly the source
>> repository with vcs functions.
> VCS ebuilds generally suck, for multiple reasons.  We allow users to use
> them but with minimal support.  However, e.g. git-r3 supports local
> mirrors to resolve some problems.

So, using local mirrors means that is the responsibility of the end user
to review the ebuilds and create, for example, the local git mirror
repository and then define EGIT_MIRROR_URI in make.conf to override for
all ebuilds?

Thanks,

Samuel



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Michał Górny
On Fri, 2020-03-27 at 11:29 +, Samuel Bernardo wrote:
> Hi Michał,
> 
> On 3/27/20 5:59 AM, Michał Górny wrote:
> > Stop here.  If you think that you need to 'break network sandbox', you
> > already have the wrong attitude and shouldn't continue.  Network sandbox
> > is not your enemy.  Using network is.
> > 
> > Network sandbox protects users from paying extra because you've written
> > a bad ebuild that unexpectedly downloads lot of data on their mobile
> > connection.  Network sandbox makes sure that we don't end up delivering
> > stuff that doesn't work to people who are on isolated networks or simply
> > have non-permanent connections.  Network sandbox makes sure that these
> > ebuilds will work three months from now when upstream randomly decides
> > to remove old files or shuffle servers, or just get hits by a temporary
> > issue.
> > 
> > There's no 'breaking the network sandbox'.  You must fix the ebuild not
> > to require Internet.
> 
> That is an awesome concept for producing ebuilds, since I could be using
> dist-cc and compiling multiple profiles using dedicated computing
> cluster leveraging available resources within a sandbox with very
> restricted access. This is a very nice pattern on resource management.
> This is another reason why I like Gentoo very much, with the SQA
> assurance of the high quality rules, and persuade me to invest my time
> using this wonderful distro.
> 
> I understand that network sandbox only restricts the build environment,
> but wouldn't the urls in SRC_URI be a problem when referencing sites
> that are not reliable? Shouldn't be relevant to define those sites that
> give better assurance for syncing the required binaries?

SRC_URI is well-defined, and that makes it possible for us and users to
develop consistent solutions.  We have Gentoo mirror network to increase
reliability when upstream servers fail.  Users can deploy local mirrors
to increase reliability further, improve throughput and make things work
in semi-isolated networks.

> Same question for unpack context when using directly the source
> repository with vcs functions.

VCS ebuilds generally suck, for multiple reasons.  We allow users to use
them but with minimal support.  However, e.g. git-r3 supports local
mirrors to resolve some problems.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Samuel Bernardo
Hi Michał,

On 3/27/20 5:59 AM, Michał Górny wrote:
> Stop here.  If you think that you need to 'break network sandbox', you
> already have the wrong attitude and shouldn't continue.  Network sandbox
> is not your enemy.  Using network is.
>
> Network sandbox protects users from paying extra because you've written
> a bad ebuild that unexpectedly downloads lot of data on their mobile
> connection.  Network sandbox makes sure that we don't end up delivering
> stuff that doesn't work to people who are on isolated networks or simply
> have non-permanent connections.  Network sandbox makes sure that these
> ebuilds will work three months from now when upstream randomly decides
> to remove old files or shuffle servers, or just get hits by a temporary
> issue.
>
> There's no 'breaking the network sandbox'.  You must fix the ebuild not
> to require Internet.

That is an awesome concept for producing ebuilds, since I could be using
dist-cc and compiling multiple profiles using dedicated computing
cluster leveraging available resources within a sandbox with very
restricted access. This is a very nice pattern on resource management.
This is another reason why I like Gentoo very much, with the SQA
assurance of the high quality rules, and persuade me to invest my time
using this wonderful distro.

I understand that network sandbox only restricts the build environment,
but wouldn't the urls in SRC_URI be a problem when referencing sites
that are not reliable? Shouldn't be relevant to define those sites that
give better assurance for syncing the required binaries?
Same question for unpack context when using directly the source
repository with vcs functions.

Best,
Samuel




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Samuel Bernardo
Hi Robin,

On 3/27/20 3:03 AM, Robin H. Johnson wrote:
> Have you looked at the EGO_SUM in go-module? This already covers ANY go
> package that uses go.mod + go.sum, in a fully reproducible way that does
> not break network sandbox.

I didn't understand EGO_SUM right.

Thank you for mentioned it.

Best,

Samuel




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Samuel Bernardo
Hi Haelwenn,
On 3/27/20 1:50 AM, Haelwenn (lanodan) Monnier wrote:
> Couldn't the snapd_${PV}.vendor.tar.xz available in 
> https://github.com/snapcore/snapd/releases 
> work in your case to avoid downloading tarballs?
> And probably consider using go-modules.eclass, which can also allow
> packaging when there is no vendoring done by the upstream by just
> cut(1)'ing the content of go.sum
I'm using the archive tarball... You're right I will try it instead and
thanks for the heads-up about controlling the content of go.sum using
go-modules.eclass.
> And I'm not so sure why you want to apparently host a tarball?
> Maybe you're not aware that SRC_URI accepts multiple tarballs? And 
> btw you strongly should only use upstream URLs in it, they don't
> need to be mirrored in distfiles.gentoo.org for the ebuild to work.

The reason to host the tarball was regarded to my understanding of
requirements pointed out in src_test[1] function notes about network
sandbox. Not related to the build process, but thinking on an
environment with restricted proxy access to only trusted locations there
would be probably a limitation to access any url. So for distributing
additional sources behind well known places such as gentoo mirrors,
github or gitlab could be an issue.

What do you think about this?

Thanks

[1]
https://devmanual.gentoo.org/ebuild-writing/functions/src_test/index.html




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt

2020-03-27 Thread Andreas K. Huettel
>
> Andreas, perhaps this should be added to the mask comment?  Happy to
> push a PR or simply add this information to the bug report, at the very
> least I thing the bug report should be closed with WONTFIX, may I
> proceed with that?  I'll same comments there if in order.

Sure, adding the info to the bug is easiest, feel free! -A 


> 
> Kind Regards,
> Jaco


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt

2020-03-27 Thread Jaco Kroon
Hi,

On 2020/03/26 23:48, Jaco Kroon wrote:

> Hi,
>
> On 2020/03/26 23:34, Andreas K. Huettel wrote:
>
>> # Andreas K. Hüttel  (2020-03-26)
>> # Fail to build with glibc-2.30; no maintainer. Removal in 30days.
>> # Bugs 691756, 691710
>> x11-terms/aterm
> I'll take this via proxy-maint.

After using aterm for nearly two decades this has now finally convinced
me to move on.  So sorry if there are other users of aterm, but I'm
going to go back on the above.

Additional information from http://www.afterstep.org/aterm.php

aterm is deprecated and in a maintenance mode only; there will be no
further updates. Use rxvt-unicode
 instead.

It took minor changes to my .Xresources file and that seems to work just
as well as aterm, so my out of hand recommendation is to use that.

Andreas, perhaps this should be added to the mask comment?  Happy to
push a PR or simply add this information to the bug report, at the very
least I thing the bug report should be closed with WONTFIX, may I
proceed with that?  I'll same comments there if in order.

Kind Regards,
Jaco



Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Michał Górny
On Fri, 2020-03-27 at 01:16 +, Samuel Bernardo wrote:
> Dear all,
> 
> Fulfilling the linting of ebuild code style design for software projects
> that loads their dependencies during build, such as go based projects or
> npm as an example, could be very nasty.
> 
> Looking into source code of snapd or opennebula as two examples, I need
> to break network sandbox to get all dependencies for snapd go modules or
> opennebula sunstone npm code.
> 

Stop here.  If you think that you need to 'break network sandbox', you
already have the wrong attitude and shouldn't continue.  Network sandbox
is not your enemy.  Using network is.

Network sandbox protects users from paying extra because you've written
a bad ebuild that unexpectedly downloads lot of data on their mobile
connection.  Network sandbox makes sure that we don't end up delivering
stuff that doesn't work to people who are on isolated networks or simply
have non-permanent connections.  Network sandbox makes sure that these
ebuilds will work three months from now when upstream randomly decides
to remove old files or shuffle servers, or just get hits by a temporary
issue.

There's no 'breaking the network sandbox'.  You must fix the ebuild not
to require Internet.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part