Mailing List Archive

On 08/07/2016 10:22 PM, Kent Fredric wrote:
> On Sun, 7 Aug 2016 16:49:01 -0500
> james <garftd@verizon.net> wrote:
>
>> After that feat is accomplished, then a similar deployment of a
>> gentoo cluster on a those just installed gentoo minimal images, via a
>> few keystrokes (I am flexible on the cluster codes that comprise the
>> cluster). Then (only after those 2 things are robustly accomplished)
>> I do intend to return to my java travails (search out bgo, as I have
>> a long love-hate relationship with java on gentoo).....
>
> I think its probably worth mentioning that there are likely problems
> Gentoo faces around Java that are of a legal manner, not merely
> technical.
>
> Like for instance, the fact you can't install the official Orcale/Sun
> JDK/JRE automatically is due to the fact:
>
> - They prohibit replication/mirroring
> - Their website requires a license agreement acceptance to download
>
> And the latter of these is /plausible/ to automate via curl and some
> "Set cookies" magic ( apparently arch do this ), but falls into a legal
> grey area.
>
>
> If this is a problem we have simply downloading and installing, I'd
> imagine there are other problems we face having it on ready-to-go media.
>

So the minimal default automated installs would not carry java code; OK.
Yep, traversing the install semantics, so it is paused for a licensed
download, as necessary, is not a show stopper. I'm pretty sure I used
maven, sbt, icedtea and curl for these cluster ebuilds in question;
Apache-Mesos and Apache-Spark. There are hacked ebuilds in BGO. I'm
pretty sure Mesos was reorganized so all the third party stuff are
modular in such a fashion that the issues you point out have legal
install solution. In fact Mesos is purported to almost all C++ code
now and the other languages issue are not part ot the core of Mesos,
or something to that effect I read somewhere.


I'm no java expert, so surely a dev with that sort of expertise could
take a look, and fix them or give me guidance. Mesos installs. My
Apache-spark ebuild needed some manual fiddling with sbt, during the
install to get it to install to Spark, so it is a bit broken.
Apache-Spark is a bit more complex, but it has progressed to version
2.0, since I hack an ebuild for 1.5. Tons of folks ((big opensource
projects) use them, so surely there is a way to solve these issues, for
devs with that sort of knowledge and meet gentoo standards?

BGO-510912 (Apache-Mesos) and BGO-523412 (Apache-Spark)


Thanks,
James

On Mon, 8 Aug 2016 16:33:15 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> > so it is paused for a licensed
> > download, as necessary, is not a show stopper
>
> The problem is that download requires a Browser with JavaScript
> support, because it requires JavaScript to set a cookie, and that
> cookie activates the download working.
>
> Which means if your installer is for instance, Curses based, you're
> pretty much out-of-luck.
>
> "Please open browser at this point, but we don't have a working
> desktop environment yet to do this" is a bit of a hard problem.
>
> "You need 2 computers to install this" is also a bit of a problem.
>
> So installing Java would have to be done /after/ the install.

Scratch this.

Just use iced-tea JDK by default. People who want oracle can do the
extra work.

interested in euscan
I'm using it in one of my server.
but I'm away untill 14 of this month.

2016/08/07 18:27 "Patrick Lauer" <patrick@gentoo.org>:

> On 08/07/2016 10:12 AM, Dirkjan Ochtman wrote:
> > On Sun, Aug 7, 2016 at 9:51 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> >> This packages are now up for grabs:
> >> app-portage/euscan
> >
> > Patrick,
> >
> > Are you still keeping euscan running?
> >
>
> Yes. It's not in the best shape, but for now it works well enough to
> keep it around.
>
>
>

On Fri, 25 Nov 2016 12:25:37 -0500
Mike Gilbert <floppym@gentoo.org> wrote:

> On Fri, Nov 25, 2016 at 10:06 AM, Thomas Kahle <tomka@gentoo.org> wrote:
> > Hi,
> >
> > I'd like to pass on maintainership of
> >
> > dev-cpp/gtest
> > dev-cpp/gmock
> >
> > I don't use them and I don't even remember how I came to maintain
> > them. These two are among the packages that have googlecode in
> > their SRC_URI, so this is a bit urgent. Upstream has moved to
> > github and merged the two packages:
> >
> > https://github.com/google/googletest
> >
> > The next and only thing on the agenda is to bump and unify the
> > two ebuilds to version 1.8.0 which was released in August.
> > Anyone?
>
> Whoever picks this up might want to consider switching to cmake, and
> installing static libs instead of shared libs.
>
> The current ebuild installs shared libs with libtools default soname
> version (0). The cmake build doesn't even bother with that and
> installs bare .so files.
>
> I don't think they are intended to be used as systemwide shared libraries.

AFAIK they are not intended to be installed as compiled code at all.
You are supposed to bundle them, or otherwise compile them from sources
along with your project.

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

>
> AFAIK they are not intended to be installed as compiled code at all.
> You are supposed to bundle them, or otherwise compile them from sources
> along with your project.
>
>
You are correct, apparently they changed their stance on this some time ago
as you can read here:

https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-is-it-not-recommended-to-install-a-pre-compiled-copy-of-google-test-for-example-into-usrlocal

They also no longer support the autotools scripts that are provided with
the source code as you can read in the README:

https://github.com/google/googletest/blob/master/googletest/README.md#legacy-build-scripts

There are quite some packages depending on them so they can't just be
last-rited. Maybe the best solution is to leave them in their current form
(perhaps update the SRC_URI) and not accepting package updates to 1.8,
instead asking upstream packages that depend on them to include them in
their source distribution.


br,
Mathy

On 25/11/2016 23:34, Mathy Vanvoorden wrote:
> AFAIK they are not intended to be installed as compiled code at all.
> You are supposed to bundle them, or otherwise compile them from sources
> along with your project.
>
>
> You are correct, apparently they changed their stance on this some time
> ago as you can read here:
>
> https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-is-it-not-recommended-to-install-a-pre-compiled-copy-of-google-test-for-example-into-usrlocal
>
> They also no longer support the autotools scripts that are provided with
> the source code as you can read in the README:
>
> https://github.com/google/googletest/blob/master/googletest/README.md#legacy-build-scripts
>
> There are quite some packages depending on them so they can't just be
> last-rited. Maybe the best solution is to leave them in their current
> form (perhaps update the SRC_URI) and not accepting package updates to
> 1.8, instead asking upstream packages that depend on them to include
> them in their source distribution.

I agree with that plan. The release files provided here
https://github.com/google/googletest/releases seem to have different
md5sums from the one that were shipped on googlecode. It is painful to
replace those files on the mirrors. So the best solution is probably to
host the <1.8 release files on a devspace (like mine).

If you want to work on this, maybe you could open bugs / contact the
maintainers of the packages that depend on gtest/gmock. As you say,
this is not really a package a distribution should ship.

Cheers,
Thomas

>
>
> br,
> Mathy

--
Thomas Kahle
http://dev.gentoo.org/~tomka/

On 2017-04-27 12:58, Dirkjan Ochtman wrote:

> The proxy maintainer for syncthing just resigned, anyone want to pick
> it up?
I'll take it.

--
MS

On Thu, 27 Apr 2017 12:58:23 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> I also want to drop the following:
>
> - dev-lang/erlang

It'd be great if whoever takes over maintainership of erlang could also
take care of dev-util/rebar. Dirkjan is currently proxying it for me,
but I don't use it anymore. (In fact, I'd totally forgotten I'm still
the maintainer; djc has handled the updates for the past few years.
Sorry about that, Dirkjan!)

Regards,
Luis

On Thu, Apr 27, 2017 at 12:58 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> I also want to drop the following:
>
> - dev-lang/erlang
> - dev-vcs/hgsubversion

I'll drop these to maintainer-needed by July 1st.

Cheers,

Dirkjan

> app-admin/syslog-ng

Hi, I will try to add this ebuild to my list as proxy maintainer.

G.

On Nov 20, 2017 5:18 PM, "Amy Liffey" <amynka@gentoo.org> wrote:

Hello all,
The following packages are up for grabs:

app-cdr/cdw
app-misc/figlet
app-text/tree
dev-lang/nasm
dev-lang/blassic
dev-lang/clojure
app-admin/syslog-ng
dev-libs/eventlog

Cheers,
Amy Liffey

Hi, I would like to pick up app-misc/figlet

On Mon, Nov 20, 2017 at 6:37 PM, Geaaru <geaaru@gmail.com> wrote:

> > app-admin/syslog-ng
>
> Hi, I will try to add this ebuild to my list as proxy maintainer.
>
> G.
>
> On Nov 20, 2017 5:18 PM, "Amy Liffey" <amynka@gentoo.org> wrote:
>
> Hello all,
> The following packages are up for grabs:
>
> app-cdr/cdw
> app-misc/figlet
> app-text/tree
> dev-lang/nasm
> dev-lang/blassic
> dev-lang/clojure
> app-admin/syslog-ng
> dev-libs/eventlog
>
> Cheers,
> Amy Liffey
>
>
>


--
Thank you,
Robert Kowalski.

MadGizmo.com
http://studio.madgizmo.com/ - Studio and portfolio.
http://rgk.madgizmo.com/ - Personal site with my resume.

Hi Thomas,

> I've been interested in getting more involved with Gentoo - would
> package maintenance be a good place to start?

You can fix bugs for many packages, but you should only assign your self
to a package, if you want to take care for bug reports in a long term.
I suggest to make small fixes and pull requests first and get familiar
with repoman + git first.


> I'd be interested in astyle and alock as these are tools I would use
> myself. Do I just start by reading
> https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers and try to get
> in touch with the right people?

That is a good start. There are many new informative links.
You can join us on IRC and tell us what you already can do, what your
interests are. We will have lists with things to do in all flavors and
difficulties. You may ping me on IRC, my nick is jstein.

--
Best,
Jonas

On 2018-05-05 04:49, Robin H. Johnson wrote:
> On Fri, May 04, 2018 at 10:52:11PM +0200, Patrice Clement wrote:
> > The following packages are up for grabs:
> ...
> > net-misc/s3cmd
> I'll take s3cmd, since my dayjob uses it heavily.

I know I’m listed on the metadata, but I’ve never done anything more
than compile it at some point in the past.

You’re welcome to be the sole maintainer.

On 07/13/2018 10:37 AM, Naohiro Aota wrote:
> - media-video/v4l2loopback

Definitely have a use for this. Looking into it now.

Hello.

I can take dev-lua/* packages.


??, 9 ???. 2020 ?., 22:08 Rafael Goncalves Martins <rafaelmartins@gentoo.org
>:

> app-emulation/qemu-init-scripts
> app-text/txt2tags
> dev-lua/luadoc
> dev-lua/luaexpat
> dev-lua/luafilesystem
> dev-lua/luarocks
> dev-lua/luasec
> dev-lua/toluapp
> dev-vcs/mercurial-server
> www-apps/trac-accountmanager
> www-apps/trac-mercurial
> www-apps/trac-tags
>
> --
> Rafael <http://rafaelmartins.eng.br/>
>

On Wed, 27 May 2020 11:38:39 +0200
Nils Freydank <holgersson@posteo.de> wrote:

> Zoltan, I prepared a branch with khard plus metadata.xml and would
> like to ask you to merge it into your PR as you took deps of khard:
>
> https://github.com/holgersson32644/gentoo/tree/bump-khard

Hi Nils,
I already had a PR[1] open for the version bump and Python 3.7 support.
I’m happy for you to take over if you like; mine is waiting for review.
Just thought you ought to know in case you get merge conflicts later
on, or want to take any bits of my changes.

[1] https://github.com/gentoo/gentoo/pull/15783
--
Christopher Head

Hi Christopher,

Am Mittwoch, den 27.05.2020 um 09:37:59 Uhr -0700 schrieb Christopher Head <chead@chead.ca>:
> ...
> I already had a PR[1] open for the version bump and Python 3.7 support.
> I’m happy for you to take over if you like; mine is waiting for review.
> Just thought you ought to know in case you get merge conflicts later
> on, or want to take any bits of my changes.
>
> [1] https://github.com/gentoo/gentoo/pull/15783

sorry for the delay - I really like to take over, and as your PR isn't merged
yet I opened a new one[1] with some further updates (vobject with python 3.9).

Please just close your old PR now.

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

Am 17.01.2021 um 10:26 schrieb Micha? Górny:
> [ v] sys-power/acpi_call

I will take this one.

mgorny:

> [bv] www-apps/radicale

I am actively using radicale on arm, arm64 and amd64 and thus
feel like I should contribute. :-)

As this was my debut to package maintainment, and I'd need at least
some initial pointers on how to start, what's the least bothering
way for everybody to ask for help and such.

BTW: There is 2.x in portage but 3.x out, so there is not just a
minor version bump to do.

Thanks

On 1/17/21 8:43 AM, m1027 wrote:
> mgorny:
>
>> [bv] www-apps/radicale
>
> I am actively using radicale on arm, arm64 and amd64 and thus
> feel like I should contribute. :-)
>
> As this was my debut to package maintainment, and I'd need at least
> some initial pointers on how to start, what's the least bothering
> way for everybody to ask for help and such.
>
> BTW: There is 2.x in portage but 3.x out, so there is not just a
> minor version bump to do.
>
> Thanks
>
>

Best way is to come ask for help on #gentoo-dev-help and
#gentoo-proxy-maint on freenode IRC.

Aisha

> On 17 Jan 2021, at 09:26, Micha? Górny <mgorny@gentoo.org> wrote:
>
> Hello,
>
> The following packages are in need of a new maintainer due to their
> current maintainer being MIA:
>
> […]
> [ ] app-admin/stow

Adopted the wonderful stow, but I’ll leave xstow for others.

> [Bv] app-admin/xstow

Thanks,
Sam

On 17/01/2021 09:26, Micha? Górny wrote:

> [bv] x11-plugins/vicious
> [B ] x11-wm/awesome

I'll take these two.

--
MS

On Sun, 2021-01-17 at 10:26 +0100, Micha? Górny wrote:
> Hello,
>
> The following packages are in need of a new maintainer due to their
> current maintainer being MIA:
>
> [b ] www-apache/mod_xsendfile

I think I can safely say that I've waited long enough for someone else
to pick this up. I've now taken this and fixed the minor open bug.

Hans

Hi,

I can take

> [Bv] net-misc/teamviewer

//madmartin

On Montag, 15. M?rz 2021 11:03:17 CET Martin Dummer wrote:
> I can take
>
> > [Bv] net-misc/teamviewer

Please make nagging upstream about https://bugs.gentoo.org/750899 a top
priority.

TIA