[gentoo-dev] Bug 822291: Thunderbird 78 EOL

[Samuel Bernardo]

Hi,

Sorry to bother you directly, but this seems very urgent and may be 
neglected in the middle of all the tasks you had:


https://bugs.gentoo.org/822291

Stabilization of thunderbird current stable version 91!

78 should be masked since is not supported anymore.

https://en.wikipedia.org/wiki/History_of_Mozilla_Thunderbird

Thank you,

Samuel



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] dev-python/rstcheck-3.3.1: Add rstcheck python package (#16399)

[Samuel Bernardo]

On 6/25/20 11:28 PM, Brian Dolbec wrote:
> yes, you do not need to add a Gentoo maintainer unless asked to.

Even without maintainer Gentoo CI fails the check for maintainer[1].

Maybe this could be not expected, and so I give you this feedback for
Gentoo infrastructure review.

[1]
https://qa-reports.gentoo.org/output/gentoo-ci/2ce9c57f0d/output.html#dev-python/rstcheck

--

Joonas Niilola:

Sorry that I miss understood the purpose of this mailing list and the
policy to accept contributions from community.

I will not send any other email to this list not directly related to the
context you mentioned. I interpret that as answering only to open topics.

Keep the good work!




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] dev-python/rstcheck-3.3.1: Add rstcheck python package (#16399)

[Samuel Bernardo]

Hi Brian

On 6/25/20 11:18 PM, Brian Dolbec wrote:
> You add yourself as primary maintainer.  The proxy maintainers will add
> themselves for the merge to the repo after all review is done.  This
> will mean that you will need to maintain the pkg, do the version bumps,
> etc..  The proxy team will help merge the changes to the ebuild tree.

That means that I can submit the ebuild metadata without maintainer?

Thanks




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] dev-python/rstcheck-3.3.1: Add rstcheck python package (#16399)

[Samuel Bernardo]

Hi,

I send this email to ask for your help on selecting the project
maintainer for a new ebuild.

I created a pull request for the ebuild in subject[1] and the QA reports
complaints about missing project maintainer[2]. What should I do?

Thanks

[1] https://github.com/gentoo/gentoo/pull/16399

[2]
https://qa-reports.gentoo.org/output/gentoo-ci/2e4d12bbfa/output.html#dev-python/rstcheck




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] glsa-check: missing CVE-2020-6509 for current stable chromium version

[Samuel Bernardo]

Hi,

Sorry if I miss any detail about glsa-check context, but I think that it
misses the CVE[1] id review I left in subject.

About chromium stability, what would you advice me, install latest
keyword masked version or wait for next stable version?

The current chromium stable version have also runtime errors using
ffmeg-4.3. [2][3]

Thanks for your enlightenment

[1] https://www.cybersecurity-help.cz/vdb/SB2020062308

[2] https://bugs.gentoo.org/729182

[3] https://bugs.gentoo.org/729310




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Add commit to pull request

[Samuel Bernardo]

Hi,

I need to add a commit to a gentoo pull request that I had opened before.

https://github.com/samuelbernardo/gentoo

Is it possible to add the commit to that pull request or I need to open
a new pull request?

I already try to get help in gentoo-dev channel but I haven't voice there...

Thanks




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel

[Samuel Bernardo]

On 5/22/20 9:08 PM, Michał Górny wrote:
> Hence my question: do you find 'do not remove kernels listed
> in bootloader config' feature useful?  Do you think it should remain
> the default?  Do you think it is worthwhile to continue supporting it?

In my Gentoo maintenance scripts I'm using

eclean-kernel -n 2

Bootloader config is generated afterwards.




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] nginx: slot mainline

[Samuel Bernardo]

Hi,

I realize today that nginx ebuild have a new slot mainline. The current
ebuild stable version 1.17 came from mainline. Anyone knows if this
means that is not the stable version of nginx?

After reading the following blog post I couldn't understand what they
are doing now:

https://www.nginx.com/blog/nginx-1-6-1-7-released/

Thanks,

Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Gentoo Identity Provider

[Samuel Bernardo]

On 5/19/20 7:47 AM, Michał Górny wrote:
> Do you have any specific solution in mind?
>
> [1] https://gitweb.gentoo.org/archive/proj/identity.gentoo.org.git/

I would suggest for SSO an implementation like the following with LDAP
provider:

https://github.com/Luzifer/nginx-sso/wiki/Auth-Provider-Configuration




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Samuel Bernardo]

Hi,

On 5/12/20 6:40 PM, Joonas Niilola wrote:
> On 5/12/20 8:36 PM, Samuel Bernardo wrote:
>> My concern was about the others, for instance go-overlay that I have
>> enabled.
>>
>> Should it be possible to run a QA check to create a bug request to
>> remember the update of those ebuilds in the overlays?
>>
>> This would reduce the bug management task when searching for related bugs.
>>
> Nothing stops you from doing that, and reporting any issues you find to
> overlay maintainers. This is probably doable with a single grep. We
> _cannot_ cater all the overlays. There has been enough time to react.
>
> -- juippis

Maybe I understand wrongly, but I had received in the past automatic bug
reports from Gentoo QA check related to my overlay. My suggestion is to
use the Gentoo QA to automatically report that, since with the new merge
with the removal of EGO_VENDOR that would be validated automatically in
future Gentoo QA check runs over the overlays at overlays.gentoo.org.

Anyway I can do as you suggests.

Thanks




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Samuel Bernardo]

Hi William,

On 5/12/20 4:38 PM, William Hubbs wrote:
>  Hi Samuel,
>
>  this change will apply to all users of the eclass.
>
>  Overlays are not considered blockers for in-tree eclass work.
>
> Also, keepin mind that there was a qa warning in place for this issue
> for 3 months, so overlay owners should have been able to see that and
> migrate their ebuilds to EGO_SUM.
Yes, I confirm that I'm aware of that. Thank you for your good work!
>  That being said, if any overlay owner would like my assistance with
>  migrating their ebuilds, I have no problem with showing them how.

No problem from my side, I have already do that.

My concern was about the others, for instance go-overlay that I have
enabled.

Should it be possible to run a QA check to create a bug request to
remember the update of those ebuilds in the overlays?

This would reduce the bug management task when searching for related bugs.

>  Thanks,
>
>  William

Thanks,

Samuel





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Samuel Bernardo]

Hi William,

How about overlays using the eclass, will this changes only apply to EAPI 8?

Thanks,

Samuel

On 5/10/20 10:16 PM, William Hubbs wrote:
> All,
>
> now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from
> go-module.eclass.
>
> This was kept when the EGO_SUM support was added on 4 Mar, with a qa
> warning advising people to migrate their ebuilds to EGO_SUM.
>
> This patch makes migrating mandatory by forcing ebuilds to die if they
> have EGO_VENDOR set and are using go-module.eclass.
>
> Thoughts?
>
> William Hubbs (1):
>   eclass/go-module.eclass: remove EGO_VENDOR support
>
>  eclass/go-module.eclass | 81 +++--
>  1 file changed, 6 insertions(+), 75 deletions(-)
>



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Opennebula ebuild

[Samuel Bernardo]

Hi,

I finally manage to get opennebula-5.10.4[1] hotfix version working,
compiling everything from source. This includes also the documentation.

If use flags docker or sunstone are selected, build will require
network-sandbox disabled. emerge will fail in pretend and setup phase if
network-sandbox was not authorized by the user.

I hope this ebuild to be useful and I'm glad to share it for Gentoo
community.

Best,

Samuel

[1] https://cgit.gentoo.org/repo/user/ssnb.git/tree/app-emulation/opennebula

On 5/4/20 2:00 PM, Samuel Bernardo wrote:
> Hi,
>
> I start to thanks all your advices from previous emails related to
> ebuild development.
>
> I send you this email to let off steam about the big mess to have latest
> OpenNebula version available in my Gentoo overlay[1]. This was the
> problems I had to deal with:
>
> - patch many source files with sed to change /usr/lib into /usr/lib64
> - pretend phase fails for use flag docker because requires
> -network-sandbox (I don't see value in the effort to use the
> docker-machine driver in opennebula, besides it was possible to get all
> required dependencies using EGO_SUM)
> - pretend phase fails for use flag sunstone in case of an hotfix release
> because it requires -network-sandbox (in this case is just impossible to
> manage npm and bower)
> - missing parser source files from official archive that I solved using
> archive from same github tag using ebuild files to add them
> - some files in /usr/lib64/one, /usr/share/one and /var/lib/one with
> executable permissions (I need to use cp -a to copy this directories to
> the image because the file permissions are set by their build tool, and
> there are so many that I haven't the time to review them in each release
> using the required Gentoo install functions)
>
> I send an email to upstream with all my complaints, asking them that all
> required dependencies for the source code must be present in the archive
> and not being downloaded during build.
>
> There are also compile problems for sunstone minified files using hotfix
> release, and that's the reason why I have those ebuilds hard masked.
>
> I also do a big improvement in ebuild code from the previous versions
> that I had removed since they are insecure.
>
> So in summary, is possible to install opennebula with network-sandbox
> but without docker-machine driver and only using stable releases without
> hotfixes. Anyway, the pretend phase tests for use flags docker and
> sunstone, and fails in case it requires -network-sandbox. So is an user
> decision in the end to allow -network-sandbox.
>
> Best,
>
> [1] https://cgit.gentoo.org/repo/user/ssnb.git/tree/app-emulation/opennebula
>



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: "emerge --sync" vs "emaint sync"

[Samuel Bernardo]

Well I use eix-sync...

As I can see in comment in the script beginning eix-sync uses emerge --sync:

> This script calls emerge --sync and shows the differences.
So that kind of transition to emaint sync would require a review from
the current tools.

On 5/6/20 11:11 PM, Zac Medico wrote:
> On 5/6/20 3:02 PM, William Hubbs wrote:
>> All,
>>
>> I know that most of our documentation tells people to use "emerge --sync";
>> however, today I heard about "emaint sync" for the first time.  ;-)
>>
>> Which one should we use? Will there be a phase-out for "emerge --sync" or
>> "emaint sync"? Are the plans to keep both available?
> I'm strongly against removal of emerge --sync, since I don't want to
> deal with inevitable backlash from trying to force users to change their
> habits for no apparent reason.
>
>> Thanks,
>>
>> William
>>
>



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Opennebula ebuild

[Samuel Bernardo]

Hi,

I start to thanks all your advices from previous emails related to
ebuild development.

I send you this email to let off steam about the big mess to have latest
OpenNebula version available in my Gentoo overlay[1]. This was the
problems I had to deal with:

- patch many source files with sed to change /usr/lib into /usr/lib64
- pretend phase fails for use flag docker because requires
-network-sandbox (I don't see value in the effort to use the
docker-machine driver in opennebula, besides it was possible to get all
required dependencies using EGO_SUM)
- pretend phase fails for use flag sunstone in case of an hotfix release
because it requires -network-sandbox (in this case is just impossible to
manage npm and bower)
- missing parser source files from official archive that I solved using
archive from same github tag using ebuild files to add them
- some files in /usr/lib64/one, /usr/share/one and /var/lib/one with
executable permissions (I need to use cp -a to copy this directories to
the image because the file permissions are set by their build tool, and
there are so many that I haven't the time to review them in each release
using the required Gentoo install functions)

I send an email to upstream with all my complaints, asking them that all
required dependencies for the source code must be present in the archive
and not being downloaded during build.

There are also compile problems for sunstone minified files using hotfix
release, and that's the reason why I have those ebuilds hard masked.

I also do a big improvement in ebuild code from the previous versions
that I had removed since they are insecure.

So in summary, is possible to install opennebula with network-sandbox
but without docker-machine driver and only using stable releases without
hotfixes. Anyway, the pretend phase tests for use flags docker and
sunstone, and fails in case it requires -network-sandbox. So is an user
decision in the end to allow -network-sandbox.

Best,

[1] https://cgit.gentoo.org/repo/user/ssnb.git/tree/app-emulation/opennebula



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

[Samuel Bernardo]

Hi everyone,

gentoostats is a novelty for me and I'm not aware of previous
discussions or implementations. But for what I could understand from the
comments and Michał Górny explanation, I would start to ask your
attention to octoverse[1] initiative.

Maybe collected statistics could be a possible from a platform to get
the additional metadata for the stats from user contribution. What I
mean is a way to have a broker to collect all statistics from an
organization internally and then to publish that in the end. With such
solution would allow to add value for enterprise statistics and also to
contribute in the end to Gentoo.

Each broker cloud use in the end git authentication to publish the
results with a merge request that would run the necessary hooks from
Gentoo side. We only need here a document specification for data parsing
in the end.

Sorry if my comment is completely out of context, but such an octoverse
for Gentoo would be very interesting in my perspective.

Best,

Samuel

[1] https://octoverse.github.com/

On 4/26/20 9:08 AM, Michał Górny wrote:
> Hi,
>
> The topic of rebooting gentoostats comes here from time to time.  Unless
> I'm mistaken, all the efforts so far were superficial, lacking a clear
> plan and unwilling to research the problems.  I'd like to start
> a serious discussion focused on the issues we need to solve, and propose
> some ideas how we could solve them.
>
> I can't promise I'll find time to implement it.  However, I'd like to
> get a clear plan on how it should be done if someone actually does it.
>
>
> The big questions
> =
> The way I see it, the primary goal of the project would be to gather
> statistics on popularity of packages, in order to help us prioritize our
> attention and make decisions on what to keep and what to remove.  Unlike
> Debian's popcon, I don't think we really want to try to investigate
> which files are actually used but focus on what's installed.
>
> There are a few important questions that need to be answered first:
>
> 1. Which data do we need to collect?
>
>a. list of installed packages?
>b. versions (or slots?) of installed packages?
>c. USE flags on installed packages?
>d. world and world_sets files
>e. system profile?
>f. enabled repositories? (possibly filtered to official list)
>g. distribution?
>
> I think d. is most important as it gives us information on what users
> really want.  a. alone is kinda redundant is we have d.  c. might have
> some value when deciding whether to mask a particular flag (and implies
> a.).
>
> e. would be valuable if we wanted to determine the future of particular
> profiles, as well as e.g. estimate the transition to new versions.
>
> f. would be valuable to determine which repositories are used but we
> need to filter private repos from the output for privacy reasons.
>
> g. could be valuable in correlation with other data but not sure if
> there's much direct value alone.
>
>
> 2. How to handle Gentoo derivatives?  Some of them could provide
> meaningful data but some could provide false data (e.g. when derivatives
> override Gentoo packages).  One possible option would be to filter a.-e. 
> to stuff coming from ::gentoo.
>
>
> 3. How to keep the data up-to-date?  After all, if we just stack a lot
> of old data, we will soon stop getting meaningful results.  I suppose
> we'll need to timestamp all data and remove old entries.
>
>
> 4. How to avoid duplication?  If some users submit their results more
> often than others, they would bias the results.  3. might be related.
>
>
> 5. How to handle clusters?  Things are simple if we can assume that
> people will submit data for a few distinct systems.  But what about
> companies that run 50 Gentoo machines with the same or similar setup? 
> What about clusters of 1000 almost identical containers?  Big entities
> could easily bias the results but we should also make it possible for
> them to participate somehow.
>
>
> 6. Security.  We don't want to expose information that could be
> correlated to specific systems, as it could disclose their
> vulnerabilities.
>
>
> 7. Privacy.  Besides the above, our sysadmins would appreciate if
> the data they submitted couldn't be easily correlated to them.  If we
> don't respect privacy of our users, we won't get them to submit data.
>
>
> 8. Spam protection.  Finally, the service needs to be resilient to being
> spammed with fake data.  Both to users who want to make their packages
> look more important, and to script kiddies that want to prove a point.
>
>
> My (partial) implementation idea
> 
> I think our approach should be oriented on privacy/security first,
> and attempt to make the best of the data we can get while respecting
> this principle.  This means no correlation and no tracking.
>
> Once the tool is installed, the user needs to opt-in to using it.  This
> involves accepting a privacy policy and setting up a cronjob.  The tool
> would 

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Samuel Bernardo]

On 4/21/20 6:50 AM, Michał Górny wrote:
> I realize Go is not isolated here.  It's just brought as one major
> example.  Rust is no better.  All these shiny 'write and forget'
> languages share the same problem.  Pay for some work hours, get
> a working product, deploy it and forget unless customers want more
> features.
>
> Today these languages are still young and the problems can be considered
> largely theoretical.  But some day -- well, unless all the cool kids
> manage to move on to next shiny new language before then -- this will be
> a major catastrophe.

Looking into an old language (25 years old): php

So many security problems...

Just a few essential ebuilds exists in ::gentoo and being very well
maintained by Gentoo.

I think the approach to the new languages have the same requirement.
Minimizing the ebuilds to the required ones would allow to minimize the
effort. Then we can use an overlay to deliver all other software that
would be useful.

So the goal in this cases would be to define the right sieve about those
libraries and tools that are required to all and that fits in package
maintenance procedures, so it could be merged into ::gentoo.

But don't forget the tooling available to the overlays development,
where another abstraction layer takes place, since it's focused on a
specific target and not all community in main ::gentoo. That's why I
consider go-module as a very cleaver solution since it gives a hybrid
solution connecting immutable delivery model into the mutable reality.

The PR present in this subject is related to missing eclass for JVM
languages, to define the common procedures to use those languages and
available builders.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Samuel Bernardo]

On 4/20/20 8:27 PM, Rich Freeman wrote:
> IMO it isn't really worth worrying about, because right now the main
> limitation seems to be a lack of people working on projects, not 25
> devs who each want to re-implement go their own way...

This is another reason I think is so important the overlays in Gentoo.

::gentoo overlay can be the most stricter one.

It is a fact that is more feasible to deliver software in overlays as
already happen (for example gitlab, science stuff, ...).

But should ::gentoo be confined to GNU, Linux and other OS base stuff?

Lets look into a specific case for a distro where everything should be
packaged and placed in an universal repository (crazy debian):

https://packages.debian.org/buster/snapd

There are very radical package pattern people there and looking into
snapd we can see that upstream just regarded the package integration,
bundling all necessary dependencies into it. So, even there, we can't
find all the required go dependencies packaged... Actually, the
dependencies are only those that undoubtedly could appear on ::gentoo.

IMHO, there are many software that doesn't need to be in a ebuild, but
the base pieces such as go, snapd, docker-ce, docker engine, are some
examples of go tools that we need to have available in ::gentoo. The
same happens for other platforms such as those mentioned in the subject
of this email.

In conclusion, I think that all the trouble about licenses and security
will be always a growing challenge and a distro should adapt their tools
to allow software being available in a better way than upstream
provided. I think that the point here is about:
- how to bring the software to an OS
- how to manage the software in a better way
- share knowledge and magnetize the community so Gentoo can grow and
show how is so useful helping to deliver better software

I'm very pleased for Gentoo!




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Samuel Bernardo]

Hi Michael,

On 4/19/20 9:09 PM, Michael Orlitzky wrote:
> You can do whatever you want in an overlay, but you can't introduce
> security vulnerabilities and license issues into thousands of peoples'
> homes and businesses through ::gentoo because it makes your life a tiny
> bit easier.
>
> The job description of distribution developer is, ultimately, to fix all
> the dumb things that upstream does before packaging the result so that
> your users get a consistent, usable, reliable, and secure product. But
> the first step isn't optional. Re-packaging garbage is easy -- that's a
> service nobody needs.
>
> Using ebuilds this way is also simply a waste of your time. If you're
> not going to package the dependencies, then you're better off using the
> upstream bundling tool. At least then you can update the hundreds of
> bundled dependencies afterwards. With an ebuild that's not possible.
I agree, I have the same concern and that's why I prefer to have an
ebuild instead of using the docker container or running blindly the
provided upstream bundling tool. Avoiding to package all unnecessary
dependencies and keeping away the garbage can only be possible as you
mentioned using the distribution tools. At least, with a Gentoo overlay,
I can have software better than upstream provided and continue my work.
> I don't mean to discourage you any more than necessary. I'm glad you
> want to help. But please quit looking to Go as an example of anything
> anyone should be doing.

Thanks for your advice, but I believe that we win more with the ebuild
for the development tools and base services, even if it will only be
available in the overlay. Is better to have the eyes of experienced
maintainers, Gentoo QA and sharing information, instead of keeping it
standalone, perpetuating the bad procedures and software usage.

I really feel like scoring when reviewing what I need to do for the
ebuild, also when it makes me spent some more time. The profit comes
afterwards!

Best,
Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Samuel Bernardo]

On 2020-04-19 16:37, Michael Orlitzky wrote:
> On 4/19/20 10:55 AM, Samuel Bernardo wrote:
>> Taking into account the network sandbox requirement, sbt.eclass needs to
>> download all dependencies with some approach like EGO_SUM implementation
>> in go-module.eclass[1].
>>
> EGO_SUM is not a legitimate approach to packaging. You have to create
> packages for each package. I know, it sounds crazy when you say it.
>
I understand what you mean, but deem this dependencies as internal
project dependencies where those libraries doesn't worth the effort to
package them all. I mean, most of these projects have an immutable
deployment approach that are not feasable to be packaged. The problem
starts from upstream...

Maybe that's the reason why docker is so popular in this cases... But to
install the base development tools and services I prefer to have ebuilds
rather than dockers.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Samuel Bernardo]

Hi Benda,

Thanks for the reference to Java Packing policy since I haven't read it
before.

I also forget to mention maven build system in last email, but for now
I'm only focused on scala and sbt.

On 4/19/20 5:31 AM, Benda Xu wrote:
> That's a good idea.  What's your plan to realize the eclasses?

Taking into account the network sandbox requirement, sbt.eclass needs to
download all dependencies with some approach like EGO_SUM implementation
in go-module.eclass[1].

Looking in more detail to scala ebuild[2] as a reference, as a quick
brainstorm, I think that could be defined:

sbt.eclass

- ESBTV = 

This would set the DEPEND for sbt and set the necessary steps to
java-pkg-2_pkg_setup, check-reqs_pkg_setup, check-reqs_pkg_pretend,
java-pkg_getjars and do the substitution of SBTV in build.properties if
required

- envset parameters (src_prepare): definition of parameters to set
necessary environment for sbt wrapper that use defined ESBTV

- ESBT_SUM = 

- esbt_compile, esbt_run, esbt_package functions: to run sbt using
envset wrapper in compile, test and install as necessary

scala.eclass

- ESCALAV = 

- ... to be defined as required

Best,

Samuel

[1]
https://devmanual.gentoo.org/eclass-reference/go-module.eclass/index.html

[2]
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/scala/scala-2.12.10.ebuild




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [gentoo-java][PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Samuel Bernardo]

Hi Benda,

I'm sorry, but maybe I miss something after reading the documentation...

I only check java and ant build system.

My point is about other JVM languages such as scala, groovy, kotlin,
clojure, ... And about builders such as gradle or sbt?

I think that eclasses for those would be very useful to develop ebuilds
and evolve with the right procedures.

Thanks,

Samuel

On 4/11/20 2:06 AM, Benda Xu wrote:
> Hi Samuel,
>
> Samuel Bernardo  writes:
>
>> I send this email to mention that it seems to be missing eclasses for
>> JVM builders such as those I mention in this email subject. Dependencies
>> and tasks management are hard tasks now that I think to have great scope
>> for improvement.
> Have you read the Java Developer Guide of Gentoo[1]?  If so, let's base
> our discussion on what we have.
>
>> [...]
> Benda
>
> 1. https://wiki.gentoo.org/wiki/Java_Developer_Guide



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] ebuild life cycle review

[Samuel Bernardo]

Hi,

On 4/11/20 2:13 AM, Jonas Stein wrote:
> AFAIK technically it can already scan overlays.
> You can ask the euscan team.

Anybody there who can help me to contact euscan team?

> http://euscan.gentooexperimental.org/
The updated team contact is missing in this page.

Is euscan still experimental?

Are anybody using it with overlays?

Thanks,

Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] ebuild life cycle review

[Samuel Bernardo]

Hi,

Thank you very much for your experience and information sharing. I
learnt very much with your answers.

---

The goal of my suggestions was related to ebuilds that become unattended
more than one year or being left behind even further. Anyway the right
timescale depends on each project and so each team could define the
right limit. This kind of policies would allow to take care of forgotten
or neglected ebuilds in portage.

But this policy implementation only deserves attention when updating new
profile releases. The policy action could just place a portage warning
with hard mask of those packages that will be removed in next profile
release. Because I like very much the idea of not loosing ebuilds (we
wants it!... we needs it must!... my precious), I suggested that in this
case could be relevant to have another profile stage such as ceased or
unattended.

So with this kind of action would allow to reduce work, keeping the
focus of maintenance where it is most needed.

---

I have to leave a very big thanks to all dedication and time that all
Gentoo developers, maintainers, teams, ... spent with this noble cause.

Cheers

On 2020-04-11 16:53, James Le Cuirot wrote:
> On Fri, 10 Apr 2020 18:21:00 +0200
> Jonas Stein  wrote:
>
>>> I would like to leave a suggestion for Gentoo portage ebuild review.
>>> Since there are some ebuilds in portage that become outdated for more
>>> than one year when there are new versions available, maybe could be
>>> possible to add a new step in Gentoo QA service to generate an alarm
>>> (send email to project and CI leaders) to request a human review.  
>> This service does already exist. Everybody can use repology [1], euscan
>> [2] and others.
>>
>> Bumping a package needs time - especially for testing. I work a lot on
>> our bug tracker and my impression is that automatic bugs for a bump
>> request are contra productive. We already have many important, but easy
>> to fix open bugs.
>> Automatic tickets for packages will flood bugzilla with tickets for
>> unused packages and bind additional manpower.
> Totally agree. I have already used euscan, and nowadays repology, and
> they're very useful for keeping on top of the stuff I directly
> maintain. I can also use them for the wider games team but there's a
> mountain of work to do there and that's not even counting the constant
> flood of largely automated bug reports we already get every day. I just
> do what I can.
>



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [gentoo-java][PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Samuel Bernardo]

Dear Java team,

I send this email to mention that it seems to be missing eclasses for
JVM builders such as those I mention in this email subject. Dependencies
and tasks management are hard tasks now that I think to have great scope
for improvement.

Looking into the developments made in go eclasses, there is a very
interesting solution in go-module.eclass with EGO_SUM to avoid the need
of additional tarballs to fulfill the network sandbox requirement. This
way, dependencies could be listed from files, optimizing the current
approach without requiring to distribute blinded dependency tarballs.

I also check java-ant-2.eclass to manage build tasks for ant. Would be
very useful to have eclass like this for the other builders.

Also review java-pkg-2.eclass and java-utils-2.eclass that are more
related to Java packages and ant builder. Seems more difficult than
usual to understand them and how to apply to other projects. Maybe to
turn this more friendly a java-common.eclass could be created for
example, collecting the common variables and functions such as
java-pkg_getjars and java-pkg_dojar, to reuse them with all JVM dialect
related projects.

Are you forging any solutions already to improve this kind of PR?

Thanks,

Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] ebuild life cycle review

[Samuel Bernardo]

Looking also to changes proposed in GLEP 72 maybe my previous suggestion
would bring another profile status as unattended or ceased.

This would allow the transition for those that need to use old or
archived profile versions.

On 2020-04-10 12:31, Samuel Bernardo wrote:
> Hi everyone,
>
> I would like to leave a suggestion for Gentoo portage ebuild review.
>
> Since there are some ebuilds in portage that become outdated for more
> than one year when there are new versions available, maybe could be
> possible to add a new step in Gentoo QA service to generate an alarm
> (send email to project and CI leaders) to request a human review.
>
> Two conditions could be verified:
>
> - if ebuild don't receive any review for more than a time period defined
> by project leader (threshold set by CI)
>
> - if there is more then X new versions in upstream, get from a release
> feed associated with ebuild (X value defined by project leader with
> threshold set by CI)
>
> Best,
>
> Samuel
>
>



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] ebuild life cycle review

[Samuel Bernardo]

Hi everyone,

I would like to leave a suggestion for Gentoo portage ebuild review.

Since there are some ebuilds in portage that become outdated for more
than one year when there are new versions available, maybe could be
possible to add a new step in Gentoo QA service to generate an alarm
(send email to project and CI leaders) to request a human review.

Two conditions could be verified:

- if ebuild don't receive any review for more than a time period defined
by project leader (threshold set by CI)

- if there is more then X new versions in upstream, get from a release
feed associated with ebuild (X value defined by project leader with
threshold set by CI)

Best,

Samuel




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] The importance of having an ebuild

[Samuel Bernardo]

Dear all,

I start to subscribe all the messages that have been exchanged2 and
would like to start to cite a very important sentence mentioned by Kent
in zoom thread, that concerns me:

On 4/7/20 7:23 AM, Kent Fredric wrote:
> But utlimately, this is not a technology problem: Its a staffing problem.

As my humble contribution, I wish to see Gentoo as the most used
distribution along with their child distributions. I always believe this
is possible with the right tools. The utopia would be to see one day
every company to follow Gentoo QA policies to win their clients, but
what do we need to do to get there?

Share the information to the users to change their critical view when
demanding the software.
Every time we neglect this we are becoming more lonely and some day open
source software will be a myth.

---

Gentoo, as the base reference, have good QA and provide the tools
reflected in is build system that is in constant improvement and
progression. Following this way, the distribution should be sturdy and
most possible complete, so it can adapt to the software market and their
evolution.

The common problem I think, is that software quality is lowering since
the hardware is very powerful, and the market is eager and blinded by
the hardware low cost. Optimizations are neglected and focused on UI, so
the delivery is faster then ever in the harshest market of all time for
the software majority.

So anytime I read about security is nowadays something so hard to do any
concern, but sharing all community knowledge we can have better trust
and allow to parse the bad software and practices. I know that this
can't be done easily, but let me call the opensource methodology to call
everyone who can help with that. So attracting new users would bring
more knowledge, allows also to spread the world enlarging the community,
that should result in greater trust for the defined QA.

This is why I think is so important to have the ebuilds, even if they
are in overlays. More ebuilds is better so we can collect the knowledge,
opposed to a standalone approach.
For those with more limited knowledge will let them to buy bad solutions
or do the wrong procedures.
The root problem will only be defeated by the end users and we need to
struggle the illiteracy about software in the community.

---

So, for me, any proposal of additional information is useful, even the
README.gentoo proposal by Ulrich in zoom thread.
Lets avoid the hide... Is better to know what have been done even if is
not possible to assure anything. This way someone could pick it and
continue the evaluation work. Clearly this will not be against the trust.

Then is so easy to create an ebuild with the provided tools that
everyone could do their contribution using overlays. Is awesome to know
that my personal overlay is being audited by Gentoo QA. I think you
could bet there the efforts!

Best,
Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

[Samuel Bernardo]

Hi Kent,

On 4/6/20 2:08 PM, Kent Fredric wrote:
> So no, nobody can actually make assurances of this software, we can
> only stipulate which cautions we know are warranted.

No assurance is also a level that takes place in the lower ranking
level. If someone needs to use zoom because they are demanded by their
boss I think that would be even more useful to know that it is possible
to install zoom in Gentoo and that is rated as the worst possible
software. Maybe this would allow others to join our zoom claim...

This is the kind of useful information that we could collect from the
QA, extending the greatness of the best distro ever made. The
availability of software from a distro is better than installing it
standalone, allowing to share knowledge about relevant information such
as security, maintenance, ...

Best,

Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

[Samuel Bernardo]

On 2020-04-04 15:57, Kent Fredric wrote:
> Depends how concerned you are about VM busting exploits contaminating
> the host.
>
> ( Maybe not Zoom in particular, but with regard to the general theme of
> "risky apps on a valued system" )

Sorry about my comment, but couldn't that be solved choosing the right
profile or opting for an official overlay, raking the assurance level of
those?

Moving away the goodwill of those maintainers that get software into
Gentoo I think is not the good way...

Giving my opinion, maybe it should be useful to have QA classification
in future Gentoo Build System, where each overlay and profile could get
their ranking (from the automatic classifiers along with optional human
review)... Just a thought




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi Robin,

On 4/1/20 11:07 PM, Robin H. Johnson wrote:
>>> # I am considering removing this and just hard coding mirror://goproxy
>>> # below, so please do not rely on it.
>>> : "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"|
>> So, go-module.eclass provides a good base to follow SRP pattern (single
>> responsibility principle). Looking into that effort I would copy
>> go-module.eclass to my overlay eclass directory and adapt it to use my
>> mirror type.
>>
>> I would like to use directly Gentoo maintained go-module.eclass, but for
>> that I would like to have access to set my own mirror type.
>>
>> I also ask you to update documentation since there is some details to
>> use EGO_SUM, such as you stated in comment[4].
> It's not clear why you need to modify the mirror behavior at all; maybe
> you covered that elsewhere in this overly long thread.

Remembering that I'm in overlay context, lets consider the use case with
a private repository with restricted access from where I need to get
some go module. I need to use an alternative mirror not listed in
default goproxy mirror type.

Ok, you can say that since is not public what is the point of creating
an ebuild? Well the ebuild (so easy to do) turns smooth the maintenance,
the installation into my environment, to reproduce it later to install
in real infrastructure and also provide me a tar.gz or rpm package using
the awesome power of Gentoo!

Btw, my workspace have two overlays for now:

- local private overlay
- public overlay  (where I share what can be shared)

Thanks for your advices,

Samuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi Michael,

On 4/1/20 6:01 PM, Michael Orlitzky wrote:
> On 4/1/20 11:49 AM, Alec Warner wrote:
>> Imagine a common dep (CommonFoo-x-y-z)
>> has a security problem, so we must upgrade to CommonFoo-y-z. In the
>> scenario where CommonFoo is a dynamically linked package we can
>> recompile it once[4] and new consumers will just use the new dynamic
>> shared object. In a bundling scenario, we will be forced to rebuild[5]
>> all consumers. 
> This is highly euphemistic. What actually happens is: someone discovers
> a security issue in a Go library. That library is not "in" Gentoo,
> because it only ever appears in a string inside of another ebuild that
> bundles everything. Thereafter, a whole lot of nothing happens. Users
> remain vulnerable "forever," until some other unrelated event causes
> both the ebuild and its dependency to be updated.

Couldn't security issue in a Go library be solved with keyword mask and
announce in portage?

The vulnerability care is not only related to the distro, but also to
the upstream. Gentoo already provides the option to downgrade to a
previous version (if that is an answer for the issue). Imagine Arch
distro where that is not an option or Debian Stable that is stuck in a
version?
I see so more troubles in other distros than Gentoo.

The choice is the responsibility of the end user and distro maintainers
don't have to provide every software. Providing the eclasses that allows
to produce the ebuild is a good option for those who need some software,
simplifying the development work. Overlaying is the solution, I think...

Best,

Samuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi Alec,

Really great reading about packaging and the current challenges. This
would be great to be posted in Gentoo blog!

---

To all community:

I would like to commend the know how of Gentoo community and their
principles.

I would like to evidence relatively to other distributions some points
that IMHO turns Gentoo the greatest (win in all points):
- QA
- freedom
- tooling
- know how
- velocity
- security
- slotting
- learning
- sharing
- straightforwardness
- objectivity
- mirroring
- package system
- **extensibility**

Overlays, ebuild and profile definitions in Gentoo extends the freedom
of the ingenious distro ever made. There are no barriers, so please
don't forget the overlays when developing Gentoo code base that would
help everyone to extend their needs and follow the good QA practices.

There is nothing like Gentoo!

Thank you all that contribute to Gentoo!


On 4/1/20 4:49 PM, Alec Warner wrote:
>
> On Wed, Apr 1, 2020 at 5:14 AM Samuel Bernardo
> mailto:samuelbernardo.m...@gmail.com>>
> wrote:
>
> Forgive my noobishness in this matter that let Alec to comment
> over my own statement.
>
> Alec pointed out some very important issues in go development that
> break copyright infringement and security vulnerabilities, but I'm
> sure that is not related to the good work done in go-module.eclass
> to surpass all go mess. npm is worst and I take from go-module as
> a good pattern to apply also into there.
>
> I am antarus, not mjo (but more on that below!) I don't believe
> bundling presents many challenges with regards to copyright
> infringement. As a package maintainer you should know the licenses
> used in your packages. You are required to reflect any licenses used
> in the LICENSE ebuild variable. Obviously this becomes more work if
> you are using a bundle due to the fact that bundling will include more
> code. In the golang ecosystem there is a tool to help maintainers do
> this (https://packages.gentoo.org/packages/dev-go/golicense). I get
> that with bundling we cannot share the work from previous packages
> because packages are not shared in a bundled environment but I expect
> the golicense tool to have good coverage in practice. If the tool does
> the work, sharing the work becomes moot.
>
> I think licensing can be more challenging in other bundling scenarios
> where tooling is not provided; but note that this is not significantly
> different from the unbundled scenario in terms of license discovery.
> If I am packaging a new program (A) and it depends on (B,C,D) I have
> two options. I can either package [A,B,C,D] (normal gentoo way) or I
> can package [A] (with B,C,D bundled). The intersection of the LICENSE
> variables is the same effort for both here. The benefit of the
> multiple packages is that future users of B,C,D can re-use the license
> discovery work and that isn't nothing.
>
> Going back to my overlay use case, will go-modules download all
> modules to distfiles directory? The naming convention will assure
> that there will be no modules repetition?
>
> What about eclean-dist, will it work as expected for those modules
> dependencies?
>
> I think some of this answers would worth mention in documentation.
>
> Sorry for anything I wrongly stated and thank you very much for
> your help,
>
> Samuel
>
> I've chosen this part to write my treatise on packaging, but rest
> assured it's mostly intended as a response to mgorny and mjo; not
> specifically in response to you.
>  
> The very long answer is that Gentoo was designed around a paradigm of
> programs written primarily in C. In C programs you have the ability to
> link to libraries which offer APIs and in the ideal case, each API is
> offered via a unique SONAME[0]. Upstream packages were written and
> built in this way (with dynamic linking). So in the case of package A,
> that uses libraries B, C, and D; the result in many distributions is 4
> packages (A,B,C,D) and users who want A will get B, C, and D
> installed. This in fact was a major selling point of package managers
> at the time because finding these dependencies by hand and building
> and merging them all was painful.
>
> Many applications break this trend; I don't think golang or nodejs are
> particularly new (python and ruby have had (pip, venv) and rubygems[1]
> for years, for example, which are similar bundling paradigms.) The
> struggle as packagers and distribution managers is when upstream
> decides "my software should be installed via a bundling solution
> (golang, node, pip, rubygems, and so on)" we are left to decide both
> whether to map this to the ebuild paradigm (no bundling of
> dependencies) or omit ebuilds entirely. In the former case we are
&g

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi Robin,

On 4/1/20 6:36 AM, Robin H. Johnson wrote:
>> Normally we don't bundle dependencies, avoiding that problem entirely.
>> The Go eclasses however are badly designed, committed against protest by
>> paid corporate interests, and serve only to facilitate large-scale
>> copyright infringement and security vulnerabilities. If you're looking
>> for a consistent explanation of how they're supposed to work with the
>> rest of Gentoo, you won't find one.
> mjo: Can you please substantiate your claims? 
>
> It would have been nice to have heard your concerns during February, any
> of one the three times that William and I posted the go-module.eclass
> EGO_SUM development work for review on this mailing list. I don't see a
> single email from you during that entire period.
>
> The EGO_SUM support explicitly ensured that upstream distfiles (for each
> dependency) remained absolutely as upstream provided them, without
> merging the distfiles together or altering their content in way (I admit
> that the exact naming of the distfiles changed, because it was terrible,
> v0.0.0-20190311183353-d8887717615a.zip for example).

Forgive my noobishness in this matter that let Alec to comment over my
own statement.

Alec pointed out some very important issues in go development that break
copyright infringement and security vulnerabilities, but I'm sure that
is not related to the good work done in go-module.eclass to surpass all
go mess. npm is worst and I take from go-module as a good pattern to
apply also into there.

Going back to my overlay use case, will go-modules download all modules
to distfiles directory? The naming convention will assure that there
will be no modules repetition?

What about eclean-dist, will it work as expected for those modules
dependencies?

I think some of this answers would worth mention in documentation.

Sorry for anything I wrongly stated and thank you very much for your help,

Samuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi Robin,

On 4/1/20 6:36 AM, Robin H. Johnson wrote:
> Samuel:
> I already proved that using go-module.eclass EGO_SUM it will NOT use Git
> repositories, and all of the fetching will happen long before
> src_unpack. Why do you persist with your statement to the contrary?

Sorry my misunderstanding, but I didn't get it right with what you
mentioned to me before:

> 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 looked into the eclass documentation and I only found EGO_VENDOR[1].
This seems so expensive since I need to parse all go.mod or go.sum files
that I concluded would be better to use a tar.gz with all dependencies
(remember that my use case is with my personal overlay).

Looking deeply into the source code I could find more details about
EGO_SUM that only needs to set the urls to go.mod or/and go.sum files
present in the repository. This is useful, but only to official gentoo
developers, since if I want to use my own mirror type, for instance
mirror://gooverlay, I wouldn't have that option[3]:

> |
> # I am considering removing this and just hard coding mirror://goproxy
> # below, so please do not rely on it.
> : "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"|
So, go-module.eclass provides a good base to follow SRP pattern (single
responsibility principle). Looking into that effort I would copy
go-module.eclass to my overlay eclass directory and adapt it to use my
mirror type.

I would like to use directly Gentoo maintained go-module.eclass, but for
that I would like to have access to set my own mirror type.

I also ask you to update documentation since there is some details to
use EGO_SUM, such as you stated in comment[4].

Thanks,

Samuel

[1]
https://devmanual.gentoo.org/eclass-reference/go-module.eclass/index.html

[2] https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/go-module.eclass

[3]
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/go-module.eclass#n164

[4]
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/go-module.eclass#n31



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi Michael,

Thank you for pointing that out.

My use case was about my personal overlay that is not mirrored by Gentoo
infrastructure.

My question started with the network sandbox issue when we need to load
external code dependencies. For example, a go project will download all
dependencies from git repositories that will happen after src_unpack. In
this case I need to add an additional tar.gz with that code along with
the software release tar.gz.
That additional tar.gz needs to be stored somewhere and as I understand
local mirror could be the right place.

Thanks,

Samuel

On 3/31/20 11:47 PM, Michael Orlitzky wrote:
> On 3/31/20 6:21 PM, Samuel Bernardo wrote:
>> But after your explanation, I understand now that mirror types provides
>> alias to use in ebuild SRC_URI, specially useful for the update task
>> (awesome).
>>
> Beware: thirdpartymirrors doesn't really do anything useful for normal
> ebuilds in ::gentoo. The gentoo infrastructure will automatically mirror
> anything in SRC_URI unless you set RESTRICT=mirror -- and that's where
> most people will download them from -- so (for example) adding a bunch
> of extra thirdpartymirrors entries to ensure that the distfiles are
> accessible is counter-productive: everyone will get the stuff from the
> gentoo mirrors anyway, and you wind up with a bunch of dead entries in
> the thirdpartymirrors file (at least half of the entries in there right
> now are dead, and no one is ever going to clean them up because no one
> uses them).
>



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi Alec,

Thank you very much for your explanation.

I'll keep it in my notes.

Best,

Samuel

On 3/31/20 11:41 PM, Alec Warner wrote:
> In general I'd avoid using the mirror system as URI simplification too
> much; a lot of the idea is to avoid hardcoding specific hosts. E.g.
> for the gentoo mirrors we want to avoid hardcoding a *specific* mirror
> in the SRC_URI, so mirror://gentoo lets us say "any gentoo mirror will
> do." Often other thirdpartymirror systems act similarly. You see this
> commonly where mirrors are divided by region.
>
> example.com/mirror  # "global / us"
> example.au/mirror  # "australia"
> example.co.uk/mirror  # "UK"
>
> From a layout perspective these are the same, but you would not want
> to hardcode "https://example.com/mirror" in the ebuild, because then
> australian users are routed to the US..which is wasteful. So we use a
> generic:
>
> "mirror://example"
>
> And we potentially pick the best mirror at fetch time.
>
> This is mostly spelled out
> in: https://devmanual.gentoo.org/ebuild-writing/variables/#third-party-mirrors
>
> If you have a bunch of packages that share a common domain and its not
> sharded (there is only 1 host serving it) then you should consider
> using an eclass to share data between your ebuilds and not use
> thirdpartymirrors just to share a hostname.
>
> -A


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi,

On 3/31/20 9:25 PM, Alec Warner wrote:
>
> From thirdpartymirrors file I can see more examples... The mirror type
> can be any label that I decide to use?
>
>
> man portage(5) says:
> Whenever portage encounters a mirror:// style URI it will look up the
> actual hosts here.  If the mirror set is not found here, it  will
>  check  the
> global  mirrors file at
> /var/db/repos/gentoo/profiles/thirdpartymirrors.  You may also set a
> special mirror type called "local".  This list of mirrors will be
> checked before GENTOO_MIRRORS and will be used even if the package has
> RESTRICT="mirror" or RESTRICT="fetch".
>
> We have a bunch of existing mirror types (as you noticed). This lets
> us do things like "mirror://github" and then globally change the uri
> for github easily without editing the entire set of ebuilds because we
> late-bind the URI matching.

Ok, so it works as an alias... The format definition led me to
misunderstand:

> - mirror type followed by a list of hosts

I interpreted mirror type as some internal definition not an alias.

>
> Is URI mirror:// style deprecated in ebuilds and should use
> restric="mirror" instead?
>
>
> I don't understand how you could arrive at this conclusion. What would
> this do?
>
> RESTRICT=mirror is for things we are not legally allowed to mirror.
> That's basically all its for; it has nothing to do with custom mirrors
> or anything.

Sorry for my dumb question, but my previous understanding of the context
was that, since mirror:// is always accessed before the SRC_URI, there
is no need to use mirror:// in ebuild SRC_URI, with the sources being
downloaded from any available mirror (also remembering the dev manuals
documentation related to  mirror://gentoo policy for auto mirroring the
sources).

But after your explanation, I understand now that mirror types provides
alias to use in ebuild SRC_URI, specially useful for the update task
(awesome).

Looking into overlay context, I think that I could add thirpartymirrors
file inside overlay profiles directory to use mirror:// in
SRC_URI to simplify ebuild URI management in the end. For example, to
all JetBrains software this will be awesome.

Thanks,

Samuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] mirror network for personal overlay

[Samuel Bernardo]

Dear all,

My goal is to integrate local rsyncd mirror in /etc/portage/mirrors with
a configuration like

local rsync://localnet-master/gentoo

where "gentoo" in rsyncd.conf contains every files in
/var/db/repos/gentoo including distfiles/, excluding only packages/
directory that is defined in "portage_binhost".

The /etc/portage/mirrors will be added into all other machines, except
the local rsync mirror.

Is this the expected configuration for a non-gentoo mirror network for
my personal overlay distfiles?

Thanks,

Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Hi Alec,

On 3/27/20 11:20 PM, Alec Warner wrote:
>
> 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.

Reading portage manpage about mirrors I didn't find the mirror type
possible values. As I could understand, there is type local as a special
mirror and then, from the example, sourceforge and gnu. Didn't
understand right how this works.

From thirdpartymirrors file I can see more examples... The mirror type
can be any label that I decide to use?

Is URI mirror:// style deprecated in ebuilds and should use
restric="mirror" instead?

I think that, in mirrors description for /etc/portage/, first paragraph
should be divided in two: the new one in  the phrase that starts with
"You may also set a special mirror type called local".

Thanks,

Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[Samuel Bernardo]

Thank you very much for you detailed answers Alec.

I will add them to my FAQ,

Best,

Samuel

On 3/27/20 11:20 PM, Alec Warner wrote:
>
> On Fri, Mar 27, 2020 at 3:59 PM Alec Warner  <mailto:anta...@gentoo.org>> wrote:
>
>
> On Fri, Mar 27, 2020 at 3:10 PM Samuel Bernardo
>  <mailto:samuelbernardo.m...@gmail.com>> wrote:
>
> So what happens when RESTRIC=mirror is used inside ebuild for
> an overlay
> in git.gentoo.org <http://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
> <http://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.
>
> 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
> <http://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
> <http://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.
>


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] network sandbox challenge

[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] Missing ebuild for Mirror and CI scripts

[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] Missing ebuild for Mirror and CI scripts

[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

Re: [gentoo-dev] network sandbox challenge

[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] network sandbox challenge

[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

[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

[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

[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

[gentoo-dev] network sandbox challenge

[Samuel Bernardo]

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.

1) For opennebula I can use the full releases that brings already
generated sunstone code, with the penalty to loose some patches or
updates in the middle.

2) For snapd I need to load previously the remote repositories
dependencies into a tar.gz that need to be stored in ebuild files. This
is ugly, I know, but there is no distfiles trusted repository
alternative where I can place them.
As a workaround, I could create gitlab or github repository and use git
lfs to upload the artifacts that need to be loaded (since I didn't know
any free Artifactory or NexusOSS repositories community supported). Then
use the provided url to download the files.

What do think about this two cases and what are your suggestions?

Thanks,

Samuel




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: autotools

[Samuel Bernardo]

Thank you Michal and Haelwenn for your advises.

I'm taking as reference the documentation about functions syntax in
devmanual[1] (very useful for a quickly review).

In the source code where autoreconf is being called I found a
configure.ac and Makefile.am.

Looking into autogen.sh[2] script prvided by the maintainer I confirm
that he runs the following commands:

- autoreconf -i -f

- for each supported distribution defines variable extra_opts

- "${SRC_DIR}/configure" --enable-maintainer-mode --prefix=/usr
$extra_opts "$@"

So it seems that the best approach would be the way you suggested in
your example Haelwenn.

[1] https://devmanual.gentoo.org/eclass-reference/ebuild/index.html

[2] https://github.com/snapcore/snapd/blob/master/cmd/autogen.sh




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] autotools

[Samuel Bernardo]

Dear all,

I send this email to ask you for your help for the better approach to
translate the following autoreconf command to an ebuild:

> |autoreconf -i -f ./configure \ --prefix=/usr \
> --libexecdir=/usr/lib/snapd \
> --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \
> --enable-nvidia-biarch \ --enable-merged-usr|
I realise that eautoreconf from autotools.eclass doesn't accept any
parameters, so how would you advise me to reproduce it inside an ebuild
using the available functions and eclasses?

My goal is to create an ebuild from latest snapd pkgbuild:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=snapd

Thank you,

Samuel



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] Re: EAPI 6

[Samuel Bernardo]

Thank you very much Zac for your answers.

I was wondering if I was missing any coding convention after reading
[1], since I always follow the pattern to define eclasses inside my
overlays as needed, sometimes overriding those provided from gentoo
portage. I was not sure if I was doing the development breaking the
expected QA rules.

With your explanation I know now that I'm doing it the right way.

[1]
https://devmanual.gentoo.org/appendices/common-problems/index.html#qa-noticeeclass-foo-inherited-illegally





signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] Re: EAPI 6

[Samuel Bernardo]

Hi again,

As a suggestion, I would propose for each overlay to override the eclass
functions for those necessary to EAPI 6 within their ebuilds.

For instance, go-overlay could use old eclasses that support EAPI 6
overriding the current ones. For some reason they updated their eclasses
to  EAPI 7 before updating the ebuilds.

This brings me to the main issue that is the portage cache and possible
conficts between those eclass defined in the overlay and those from
gentoo main stream. Maybe a name convention would be useful here for
future upgrades as a code styling guide for gentoo developers.

What do you think about this kind of issues?

Best,

Samuel

On 12/03/2020 10.42, Samuel Bernardo wrote:
> Hi,
>
> Is there any way to allow EAPI 6 for some overlays with current portage
> stable version (2.3.89-r1)?
>
> There are many previous functions that were updated strictly to EAPI 7.
> As an example here is the result when running "eix-sync -a":
>
>> ebuild failed with status
>> 1
>>  
>>  
>> 
>>  
>>  Reading category 127|190 ( 66):
>> net-misc...  
>>  
>>  
>>  
>>  
>> cannot properly execute
>> /var/lib/layman/go-overlay/net-misc/dbxcli/dbxcli-1.4.0.ebuild
>>  Reading category 127|190 ( 66): net-misc... * ERROR:
>> net-misc/gnatsd-0.9.4::go-overlay failed (depend
>> phase):     
>>  *   golang-common: EAPI=6 is not
>> supported
>>   
>>  
>>  *    
>>  * Call
>> stack:   
>> 
>>  
>>  *  ebuild.sh, line 609:  Called source
>> '/var/lib/layman/go-overlay/net-misc/gnatsd/gnatsd-0.9.4.ebuild'
>>  *    gnatsd-0.9.4.ebuild, line  10:  Called inherit
>> 'golang-single'  
>>    
>>  
>>  *  ebuild.sh, line 314:  Called __qa_source
>> '/var/lib/layman/go-overlay/eclass/golang-single.eclass'
>>  *  ebuild.sh, line 112:  Called source
>> '/var/lib/layman/go-overlay/eclass/golang-single.eclass' 
>> 
>>  
>>  *   golang-single.eclass, line  66:  Called inherit
>> 'golang-common'  
>>  *  ebuild.sh, line 314:  Called __qa_source
>> '/var/lib/layman/go-overlay/eclass/golang-common.eclass'
>>  *  ebuild.sh, line 112:  Called source
>> '/var/lib/layman/go-overlay/eclass/golang-common.eclass'     
>>  *   golang-common.eclass, line  37:  Called
>> die  
>>    
>>  
>>  * The specific snippet of
>> code:
>>  
>>  
>>  *  die "${ECLASS}: EAPI=${EAPI:-0} is not supported"
>> ;;     
>>  *   
>> 
>>  
>>  * If you need support, post the output of `emerge --info
>> '=net-misc/gnatsd-0.9.4::go-overlay'`, 
>>  
>>  * the complete build log and the output of `emerge -pqv
>> '=net-misc/gnatsd-0.9.4::go-overlay'`.  
>>  
>>  * Working directory:
>> '/usr/lib64/python3.6/site-packages' 
>>   
>>  
>>  * S: '/gnatsd-0.9.4'
> Thanks in advance for your help, comments and suggestions.
>
> Best,
>
> Samuel
>


signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] EAPI 6

[Samuel Bernardo]

Hi,

Is there any way to allow EAPI 6 for some overlays with current portage
stable version (2.3.89-r1)?

There are many previous functions that were updated strictly to EAPI 7.
As an example here is the result when running "eix-sync -a":

> ebuild failed with status
> 1 
>   
>   
>  
>  
>  Reading category 127|190 ( 66):
> net-misc...   
>   
> 
>  
> cannot properly execute
> /var/lib/layman/go-overlay/net-misc/dbxcli/dbxcli-1.4.0.ebuild
>  Reading category 127|190 ( 66): net-misc... * ERROR:
> net-misc/gnatsd-0.9.4::go-overlay failed (depend
> phase):     
>  *   golang-common: EAPI=6 is not
> supported 
>  
>  
>  *    
>  * Call
> stack:
>    
>  
>  *  ebuild.sh, line 609:  Called source
> '/var/lib/layman/go-overlay/net-misc/gnatsd/gnatsd-0.9.4.ebuild'
>  *    gnatsd-0.9.4.ebuild, line  10:  Called inherit
> 'golang-single'   
>   
>  
>  *  ebuild.sh, line 314:  Called __qa_source
> '/var/lib/layman/go-overlay/eclass/golang-single.eclass'
>  *  ebuild.sh, line 112:  Called source
> '/var/lib/layman/go-overlay/eclass/golang-single.eclass'  
>    
>  
>  *   golang-single.eclass, line  66:  Called inherit
> 'golang-common'  
>  *  ebuild.sh, line 314:  Called __qa_source
> '/var/lib/layman/go-overlay/eclass/golang-common.eclass'
>  *  ebuild.sh, line 112:  Called source
> '/var/lib/layman/go-overlay/eclass/golang-common.eclass'     
>  *   golang-common.eclass, line  37:  Called
> die   
>   
>  
>  * The specific snippet of
> code: 
> 
>  
>  *  die "${ECLASS}: EAPI=${EAPI:-0} is not supported"
> ;;     
>  *
>    
>  
>  * If you need support, post the output of `emerge --info
> '=net-misc/gnatsd-0.9.4::go-overlay'`, 
>  
>  * the complete build log and the output of `emerge -pqv
> '=net-misc/gnatsd-0.9.4::go-overlay'`.  
>  
>  * Working directory:
> '/usr/lib64/python3.6/site-packages'  
>  
>  
>  * S: '/gnatsd-0.9.4'
Thanks in advance for your help, comments and suggestions.

Best,

Samuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] reproducible builds

[Samuel Bernardo]

On 02/04/2018 06:14 PM, Canek Peláez Valdés wrote:
>
>
> What would this even mean in the context of a source-based distro?
>
>
> It would mean that we all could reproduce the exact same bugs given
> the CFLAGS/USE/etc. combination.
>
> Many groups are working on this from different fronts; if the results
> stabilize at some point, Gentoo could use that to at least give the
> users the option of enabling reproducible builds.
+1

That was exactly what I found interesting.
There is also some best practices that are pointed in the documentation
that seems to be useful for achieving the deterministic build:
https://reproducible-builds.org/docs/

Gentoo is a source based distro but the build environments and profiles
are many times the challenge that trigger most of bug reports in bugzilla.
With the reference reproducible build for some ebuild or profile would
allow to review the details of portage configuration that could be the
cause of the compile failures. This would be very useful for keyword
masked packages and for those that desire to be bleeding edge. Also for
overlays that would be qualiity assured by the reproducible builds over
EAPI verification.

I'm convinced that some of the ideas would be useful even for a souce
based distribution. In a source distribution I think that this would be
simple when comparing to binary distributions. All necessary information
would be collected directly from emerge and published as is.

Thanks to all for the feedback

[gentoo-dev] reproducible builds

[Samuel Bernardo]

Hi,

I send this email to know the opinion of gentoo developers about
registering gentoo profiles in the context of reproducible-builds.org

Cheers

[gentoo-dev] javaws always use icedtea

[Samuel Bernardo]

Hello,

I'm using oracle jdk as default jvm, but when I review java-config
result after setting oracle-jdk-bin as prefered jvm, javaws continues to
start icedtea version.

Analysing the script /usr/libexec/eselect-java/run-java-tool.bash I
realised that itweb-javaws is hardcoded:

> if [ "${tool}" = "javaws" ] && [ -x "/usr/bin/itweb-javaws" ]; then 
>         exec "/usr/bin/itweb-javaws" "${@}" 
> fi 

Shouldn't this also change when java-config defines new predefined jvm?

Thanks for any clarification about this implementation in the mentioned
script.
The ebuild that installs the script is app-eselect/eselect-java and I
would like to change this script to also set javaws when predefining jvm.

I also published this message in the gentoo forum:

https://forums.gentoo.org/viewtopic-t-1073738.html

Best,

Samuel

Re: [gentoo-dev] Open Build Service

[Samuel Bernardo]

Hi Peter,


On 11/14/2017 07:33 AM, Peter Volkov wrote:
> Samuel, probably I miss something but this should work out of box:
> https://wiki.gentoo.org/wiki/Binary_package_guide#Web_based_binary_package_host
>
> Or do you mean something else?
>  
Yes, you're right. I miss that when I read that page last time.
So emerge actually support https. Awesome!

Thanks

Re: [gentoo-dev] Open Build Service

[Samuel Bernardo]

Hi,


On 11/14/2017 03:04 PM, Ian Stakenvicius wrote:
> The biggest issue you will have with doing these types of builds,
> though, is dealing with the various use flag differences that various
> consumer systems may have.  From what little I've played with binary
> builds, if you want to offer binpkg's for an entire system set you
> pretty much have to synchronize all use flags across all systems.  So
> a realistic deployment will essentially require (a) adherence to a
> specific set of static profiles, or (b) a nearly-infinitely-growing
> number of build profiles that match each permutation of global and
> per-package use flag settings that your consumers would have.
Just like you described. There will be a profile for each system
environment and that would be integrated in CI/CD using OBS for my
proposed use case. Use flags will be optimized for each case only
possible with a powerful distribution like Gentoo :P

Obviously that creating a new profile would need a strong requirement
for that ;)

That's why I think the effort for maintaining profiles would be awesome
with the idea proposed by Michael Haubenwallner, with the "Social Linux
Distribution Network" sharing Gentoo user's profile
setups - with the cache for binary packages to be optional. So the OBS
reference in this context would be the profile and the binary repository
as optional.
The open-source development way of systems described by the schema
"profile" would be the next step. Containers or appliances cloud be
defined this way for complex deployments.

Thanks ;)

[gentoo-dev] Re: Open Build Service

[Samuel Bernardo]

Hi,


On 11/14/2017 10:04 AM, Michael Haubenwallner wrote:
> Well, Gentoo is a Meta Distribution, and it's binary instantiation usually
> does emerge on the users machine(s). So users actually do have their private
> binary distribution - either with or without caching the binary packages.
> (In my opinion, a binary distribution is little more than a cache for binary
> packages, to avoid the need for compilation resources on the target machine.)
>
> Of course there is chance that users do have identical profile setups (USE 
> flags,
> optimization flags, etc.), which is where OBS (or similar) indeed feels 
> useful.
>
> Rather than sharing binary packages, an idea is to share Gentoo user's profile
> setups - with the cache for binary packages to be optional (yet powered by 
> some
> open build service). Note that some USE flags disallow binary packaging at 
> all.
>
> Wouldn't we gain something like a "Social Linux Distribution Network" then?
>
> /haubi/

I think that proposal would be awesome to be achieved!
I like very much the idea. I'll review that.

Re: [gentoo-dev] Open Build Service

[Samuel Bernardo]

Hi Michał,

On 11/11/2017 08:09 AM, Michał Górny wrote:
> You've put a lot of theory in here but not really a single sentence
> on what needs to be done. I'm aware that some people used to be working
> on adding some OBS ebuilds to Gentoo but I've no clue about their goal.
>
> Long story short, if it requires changes to the ebuild format, then you
> have to list them and convince us. If it doesn't, then you are free to
> play with OBS any way you like.
I'll review what will need to be done for the integration.
The only feature that would be useful for now is emerge obtaining the
precompiled binary packages to install in containers/VMs from http
rather than nfs[1].
But I'll do a first code review for the integration and then I'll come
back to give the feedback supported by code snippets.

[1] https://wiki.gentoo.org/wiki/Binary_package_guide

[gentoo-dev] Open Build Service

[Samuel Bernardo]

Hi,

I send this email to know the devs opinion about Gentoo integration with
Open Build Service[1].

When creating specialized images and using an automated process for
testing before deployment, I think that Open Build Service would be
useful. It already support all major binary based distros and I think
that Gentoo could be in there also.

There is also a subforum with some interesting posts[2], where was
mentioned some references for Gentoo@OBS.

I reviewed catalyst scripts and Gentoo workflow when creating the
package repository, and I think that it could be integrated in OBS. The
advantage is about creating repositories of binary packages from Gentoo
that would be used to deploy containers or VMs. This way, updates could
be applied to the images. OBS will be responsible to compile all images
that would be associated with their own created binary repository.

To use the binary repository in Gentoo is suggested to use a nfs share
for portage/packages directory[3], but it would be a smoother
integration if emerge gets the packages directly from an url.

You can ask, but for that why not using a binary disto? Well they're not
Gentoo... What I mean with this is that all the Gentoo tools, portage
architecture and the ebuild format that allows for excellent source
package definition (EAPI), turn it unique. Also the freedom associated
with Gentoo distribution that, with less effort than the others, allows
for the creation of new distros. Cross compiling tools are also amazing.

So why shouldn't I wish to use Gentoo always?

Well it don't need to be OBS, but since this opensource project have
some nice ideas, why not starting from there?

Best,

Samuel

[1] http://openbuildservice.org/

[2] https://forums.gentoo.org/viewtopic-p-7829060.html

[3] https://wiki.gentoo.org/wiki/Binary_package_guide

Re: [gentoo-portage-dev] Portage patch now on gentoo-portage-dev ml

[Samuel Bernardo]

Hello Zac,

Thanks for your answer!

Sorry for my questions about mailing list activity, but it was my first
messages. I'm glad to know I can find portage team here.

Thank you very much for your time and work in the best distro ever made!

:)


On 09/19/2017 12:30 AM, Zac Medico wrote:
> On 09/18/2017 04:17 PM, Samuel Bernardo wrote:
>> Hello,
>>
>> Is this mailing list alive?
>>
>> Should I place questions about portage and ebuild development in another
>> mailing list?
> This is the correct list, we're just really busy.
>
>> Best,
>>
>> Samuel
>>
>>
>> On 09/12/2017 09:45 PM, Samuel Bernardo wrote:
>>> Hello again,
>>>
>>> About the ebuild code check, the only script that I need to patch is
>>> ebuild command right?
>>>
>>> A prefer not to install portage- and only apply a patch to the
>>> current stable version of the portage.
> You can create a /etc/portage/patches/sys-apps/portage directory any
> patches you place in that directory will be applied by the epatch_user
> call in distutils-r1.eclass.
>
>>> I also realized that portage releases are available from
>>> https://dev.gentoo.org/~dolsen/releases/portage/ and that releases on
>>> https://anongit.gentoo.org/git/proj/portage.git don't have the tags in
>>> accordance to the current release (2.3.6). I search the tags in git
>>> repository for v2.3.6 and I coudn't find it (v2.3.0_rc1).
> This is the tag for the portage-2.3.8 (latest) release:
>
> https://gitweb.gentoo.org/proj/portage.git/tag/?h=portage-2.3.8
>
>>> So is release cycle in the repository different from the releases
>>> available in dev.gentoo.org?
>>>
>>> How are you managing the releases delivery?
>>>
>>> I'm interested to follow the portage future updates and have the ebuild
>>> development updated for the next release.
> There's tarball available for the latest release here:
>
> https://dev.gentoo.org/~zmedico/portage/archives/portage-2.3.8.tar.bz2
>
>
>>> Cheers :)
>>>
>>>
>>> On 09/12/2017 09:18 PM, Samuel Bernardo wrote:
>>>> Hi Michał,
>>>>
>>>> On 09/12/2017 06:29 PM, Michał Górny wrote:
>>>>> W dniu wto, 12.09.2017 o godzinie 17∶33 +0100, użytkownik Samuel
>>>>> Bernardo napisał:
>>>>>> Hi,
>>>>>>
>>>>>> How can I test my overlay ebuilds using the new portage EAPI that is
>>>>>> only available on gentoo-portage-dev ml?
>>>>>>
>>>>>> I don't know where is gentoo-portage-dev... Is it a gentoo portage tree
>>>>>> available from git or some url for syncing?
>>>>>>
>>>>> I don't really understand what you're asking for. Is it about
>>>>> the failures with commands in global scope? If it's that, then it's
>>>>> already merged and available via =sys-apps/portage-.
>>>>>
>>>> Yes is that I was looking for...
>>>> But also didn't understand the meaning of "a patch in gentoo-portage-dev
>>>> ml"... What does this stand for?
>>>>
>>>> Thanks for your help
>>
>

Re: [gentoo-portage-dev] Portage patch now on gentoo-portage-dev ml

[Samuel Bernardo]

Hello,

Is this mailing list alive?

Should I place questions about portage and ebuild development in another
mailing list?

Best,

Samuel


On 09/12/2017 09:45 PM, Samuel Bernardo wrote:
> Hello again,
>
> About the ebuild code check, the only script that I need to patch is
> ebuild command right?
>
> A prefer not to install portage- and only apply a patch to the
> current stable version of the portage.
>
> I also realized that portage releases are available from
> https://dev.gentoo.org/~dolsen/releases/portage/ and that releases on
> https://anongit.gentoo.org/git/proj/portage.git don't have the tags in
> accordance to the current release (2.3.6). I search the tags in git
> repository for v2.3.6 and I coudn't find it (v2.3.0_rc1).
>
> So is release cycle in the repository different from the releases
> available in dev.gentoo.org?
>
> How are you managing the releases delivery?
>
> I'm interested to follow the portage future updates and have the ebuild
> development updated for the next release.
>
> Cheers :)
>
>
> On 09/12/2017 09:18 PM, Samuel Bernardo wrote:
>> Hi Michał,
>>
>> On 09/12/2017 06:29 PM, Michał Górny wrote:
>>> W dniu wto, 12.09.2017 o godzinie 17∶33 +0100, użytkownik Samuel
>>> Bernardo napisał:
>>>> Hi,
>>>>
>>>> How can I test my overlay ebuilds using the new portage EAPI that is
>>>> only available on gentoo-portage-dev ml?
>>>>
>>>> I don't know where is gentoo-portage-dev... Is it a gentoo portage tree
>>>> available from git or some url for syncing?
>>>>
>>> I don't really understand what you're asking for. Is it about
>>> the failures with commands in global scope? If it's that, then it's
>>> already merged and available via =sys-apps/portage-.
>>>
>> Yes is that I was looking for...
>> But also didn't understand the meaning of "a patch in gentoo-portage-dev
>> ml"... What does this stand for?
>>
>> Thanks for your help

Re: [gentoo-portage-dev] Portage patch now on gentoo-portage-dev ml

[Samuel Bernardo]

Hello again,

About the ebuild code check, the only script that I need to patch is
ebuild command right?

A prefer not to install portage- and only apply a patch to the
current stable version of the portage.

I also realized that portage releases are available from
https://dev.gentoo.org/~dolsen/releases/portage/ and that releases on
https://anongit.gentoo.org/git/proj/portage.git don't have the tags in
accordance to the current release (2.3.6). I search the tags in git
repository for v2.3.6 and I coudn't find it (v2.3.0_rc1).

So is release cycle in the repository different from the releases
available in dev.gentoo.org?

How are you managing the releases delivery?

I'm interested to follow the portage future updates and have the ebuild
development updated for the next release.

Cheers :)


On 09/12/2017 09:18 PM, Samuel Bernardo wrote:
> Hi Michał,
>
> On 09/12/2017 06:29 PM, Michał Górny wrote:
>> W dniu wto, 12.09.2017 o godzinie 17∶33 +0100, użytkownik Samuel
>> Bernardo napisał:
>>> Hi,
>>>
>>> How can I test my overlay ebuilds using the new portage EAPI that is
>>> only available on gentoo-portage-dev ml?
>>>
>>> I don't know where is gentoo-portage-dev... Is it a gentoo portage tree
>>> available from git or some url for syncing?
>>>
>> I don't really understand what you're asking for. Is it about
>> the failures with commands in global scope? If it's that, then it's
>> already merged and available via =sys-apps/portage-.
>>
> Yes is that I was looking for...
> But also didn't understand the meaning of "a patch in gentoo-portage-dev
> ml"... What does this stand for?
>
> Thanks for your help

Re: [gentoo-portage-dev] Portage patch now on gentoo-portage-dev ml

[Samuel Bernardo]

Hi Michał,

On 09/12/2017 06:29 PM, Michał Górny wrote:
> W dniu wto, 12.09.2017 o godzinie 17∶33 +0100, użytkownik Samuel
> Bernardo napisał:
>> Hi,
>>
>> How can I test my overlay ebuilds using the new portage EAPI that is
>> only available on gentoo-portage-dev ml?
>>
>> I don't know where is gentoo-portage-dev... Is it a gentoo portage tree
>> available from git or some url for syncing?
>>
> I don't really understand what you're asking for. Is it about
> the failures with commands in global scope? If it's that, then it's
> already merged and available via =sys-apps/portage-.
>
Yes is that I was looking for...
But also didn't understand the meaning of "a patch in gentoo-portage-dev
ml"... What does this stand for?

Thanks for your help

[gentoo-portage-dev] Portage patch now on gentoo-portage-dev ml

[Samuel Bernardo]

Hi,

How can I test my overlay ebuilds using the new portage EAPI that is
only available on gentoo-portage-dev ml?

I don't know where is gentoo-portage-dev... Is it a gentoo portage tree
available from git or some url for syncing?

Cheers,

Samuel