[gentoo-dev] Re: [gentoo-dev-announce] Last rites:

[Tomas Mozes]

On Monday, January 23, 2023, David Seifert  wrote:
> # David Seifert  (2023-01-23)
> # EOL branch, switch to mariadb-10.4/galera-26.4, removal on 2023-02-22.
>  
>

Mariadb 10.3 will be supported until May 2023, any reason to drop it now?

[gentoo-dev] Packages up for grabs (elastic)

[Tomas Mozes]

Seems like I won't be using these packages in version >7, while there is
version 8.1 out now:
- app-admin/filebeat
- app-admin/logstash-bin
- app-misc/elasticsearch
- www-apps/kibana-bin

Please consider adding yourself to maintainers if you use them.

Tomas

[gentoo-dev] Package up for grabs: app-admin/graylog

[Tomas Mozes]

Hello

the following package is up for grabs

app-admin/graylog
https://packages.gentoo.org/packages/app-admin/graylog

Tomas

Re: [gentoo-dev] Call for testing from toolchain team: glibc-2.34

[Tomas Mozes]

On Thu, Oct 28, 2021 at 1:39 AM Sam James  wrote:

> Hi,
>
> toolchain@ would appreciate if folks could keyword glibc-2.34 locally
> on non-production machines to help root out any bugs.
>
> The tracker bug is doing pretty well at this point with most remaining
> issues being in last-rited packages or being tracked upstream:
> https://bugs.gentoo.org/803482.
>
> There are no plans to keyword glibc-2.34 yet given there's
> a few large changes and we've not yet got over the libxcrypt
> hump (that's coming very shortly, stabilisation planned for
> 2021-11-01!). But you can't start planning too early ;)
>
> I would not recommend doing this on a machine
> with Chromium or anything Electron based for now
> as I haven't had a chance to check if the sandbox stuff
> has been updated. I _think_ Firefox is fine now (at least
> in the latest versions >= 91?).
>
> If you're able, please therefore keyword glibc-2.34 on
> systems where you're up for a bit of experimentation,
> and ideally rebuild (-ev @world) and report any bugs.
>
> If you feel generous, run FEATURES=test on some/all
> stuff too.
>
> Please drop into #gentoo-toolchain if you have any
> questions or issues we need to debug together.
>
> Cheers!
>
> Best,
> sam
>
>
I only had a hard time with elastic/filebeats. It crashed soon after
starting, luckily it got fixed upstream (
https://githubmemory.com/repo/elastic/apm-server/issues/6238). It's on PR
https://github.com/gentoo/gentoo/pull/22823/commits/0e8fe167b013b8cefad3c3da9d0beec9887ab15c


Tomas

Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

[Tomas Mozes]

On Fri, Jul 9, 2021 at 4:38 AM Georgy Yakovlev  wrote:

> Signed-off-by: Sam James 
> Signed-off-by: Georgy Yakovlev 
> ---
>  .../2021-07-07-systemd-tmpfiles.en.txt| 48 +++
>  1 file changed, 48 insertions(+)
>  create mode 100644
> 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
>
> diff --git
> a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> new file mode 100644
> index 000..0960663
> --- /dev/null
> +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> @@ -0,0 +1,48 @@
> +Title: systemd-tmpfiles replaces opentmpfiles due to security issues
> +Author: Georgy Yakovlev 
> +Author: Sam James 
> +Posted: 2021-07-07
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Installed: virtual/tmpfiles
> +
> +On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a
> +root privilege escalation vulnerability (CVE-2017-18925 [0],
> +bug #751415 [1], issue 4 [2] upstream).
> +
> +The use of opentmpfiles is discouraged by its maintainer due to the
> +unpatched vulnerability and other long-standing bugs [3].
> +
> +Users will start seeing their package manager trying to replace
> +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is
> +another provider of virtual/tmpfiles.
> +
> +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does
> +not use dbus, and is just a drop-in replacement for opentmpfiles. It is
> +a small binary built from systemd source code, but works separately,
> +similarly to eudev or elogind. It is known to work on both glibc and
> +musl systems.
> +
> +Note that systemd-tmpfiles is specifically for non-systemd systems. It
> +is intended to be used on an OpenRC system.
> +
> +If you wish to selectively test systemd-tmpfiles, follow those steps:
> +
> + 1. # emerge --oneshot sys-apps/systemd-tmpfiles
> + 2. # reboot
> +
> +No other steps required.
> +
> +If, after reviewing the linked bug reference for opentmpfiles, you feel
> +your system is not vulnerable/applicable to the attack described, you
> +can unmask[4] opentmpfiles at your own risk:
> +
> +1. In /etc/portage/package.unmask, add:
> +-sys-apps/opentmpfiles
> +2. # emerge --oneshot sys-apps/opentmpfiles
> +
> +[0] https://nvd.nist.gov/vuln/detail/CVE-2017-18925
> +[1] https://bugs.gentoo.org/751415
> +[2] https://github.com/OpenRC/opentmpfiles/issues/4
> +[3] https://bugs.gentoo.org/741216
> +[4] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package
> --
> 2.32.0
>
>
>
Plus maybe removing these dead symlinks:
/etc/runlevels/boot/opentmpfiles-setup
/etc/runlevels/sysinit/opentmpfiles-dev

[gentoo-dev] Packages up for grabs: dev-python/elasticsearch-curator and dev-python/elasticsearch-py

[Tomas Mozes]

Hello,
seems like elasticsearch-curator is lacking behind as it went from a
full-time job project to a hobby weekend project.

https://bugs.gentoo.org/714860

There is a new release, however it still depends on an older click version.
I've replaced it with a simple bash script.

Tomas

[gentoo-dev] Packages up for grabs: app-benchmarks/sysbench

[Tomas Mozes]

Hello,
dropping myself as maintainer on these packages:
app-benchmarks/sysbench (https://github.com/gentoo/gentoo/pull/18350)
dev-db/percona-xtrabackup (https://github.com/gentoo/gentoo/pull/18349)

sysbench is dropping to m-n.

Tomas

Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

[Tomas Mozes]

On Sat, Aug 8, 2020 at 8:51 PM William Hubbs  wrote:

> All,
>
> I would like to propose that we switch the default udev provider on new
> systems from eudev to udev.
>
> This is not a lastrites, and it will not affect current systems since
> they have to migrate manually. Also, this change can be overridden at
> the profile level if some profile needs eudev (the last time I checked,
> this applies to non-glibc configurations).
>
> What do people think?
>
> Thanks,
>
> William
>
>
I had the opposite problem, udev failed to work with newer
udev-init-scripts so all my systems were migrated to eudev. Looking at the
bug report (https://bugs.gentoo.org/681586), some of the others had the
same experience.

It was a drop-in replacement for me, personally I don't care if I have udev
or eudev installed (if it works).

Tomas

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

[Tomas Mozes]

On Friday, May 22, 2020, Michał Górny  wrote:
> Hi, everyone.
>
> I've finally found some time to revive eclean-kernel, and I'm having
> some doubts about the way bootloaders are used (in ek1).  I'd like to
> hear your opinion on whether the old behavior should be kept or removed
> in favor of more-like-ek2 behavior.
>
> Originally, ek1 assumed that we shouldn't normally remove kernels that
> are listed in the bootloader.  It made sense back in the day when I was
> using LILO, and it just took whatever was linked to /boot/vmlinuz{,.old}
> and ek removed the rest.  Today, it makes less sense with bootloaders
> like GRUB2 or systemd-boot that normally just use all installed kernels.
>
> Alternatively, ek1 had destructive mode (a misnomer probably) that just
> kept N newest kernels and removed older.  This is also the behavior
> exhibited by ek2 (since I've never gotten to implement bootloaders).
>
> The truth is, the bootloader support code in ek1 is ugly and needs
> a major refactoring.  However, I'm wondering whether it's worth
> the effort or if I should just remove it altogether.
>
> 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?
>
> --
> Best regards,
> Michał Górny
>
>

Hello,
My flow is like:
- install gentoo-sources
- build kernel and install to /boot
- eclean-kernel -d -n 2
- grub-config

Tomas

Re: [gentoo-dev] nginx: slot mainline

[Tomas Mozes]

On Friday, May 22, 2020, Samuel Bernardo 
wrote:
> 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
>
>
>

Features are added to the mainline branch, it can be broken from time to
time. After it's tested it's merged into the stable branch.

Mainline is like the dev branch and stable is like the master branch.

If you need higher stability pick the stable releases, if you need new
features pick the mainline releases.

Tomas

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Tomas Mozes]

On Thu, May 21, 2020 at 12:10 PM Michał Górny  wrote:

> On Thu, 2020-05-21 at 11:48 +0200, Tomas Mozes wrote:
> > On Thu, May 21, 2020 at 10:47 AM Michał Górny  wrote:
> >
> > > Hi,
> > >
> > > TL;DR: I'm looking for opinions on how to protect goose from spam,
> > > i.e. mass fake submissions.
> > >
> > >
> > > Problem
> > > ===
> > > Goose currently lacks proper limiting of submitted data.  The only
> > > limiter currently in place is based on unique submitter id that is
> > > randomly generated at setup time and in full control of the submitter.
> > > This only protects against accidental duplicates but it can't protect
> > > against deliberate action.
> > >
> > > An attacker could easily submit thousands (millions?) of fake entries
> by
> > > issuing a lot of requests with different ids.  Creating them is
> > > as trivial as using successive numbers.  The potential damage includes:
> > >
> > > - distorting the metrics to the point of it being useless (even though
> > > some people consider it useless by design).
> > >
> > > - submitting lots of arbitrary data to cause DoS via growing
> > > the database until no disk space is left.
> > >
> > > - blocking large range of valid user ids, causing collisions with
> > > legitimate users more likely.
> > >
> > > I don't think it worthwhile to discuss the motivation for doing so:
> > > whether it would be someone wishing harm to Gentoo, disagreeing with
> > > the project or merely wanting to try and see if it would work.  The
> case
> > > of SKS keyservers teaches us a lesson that you can't leave holes like
> > > this open a long time because someone eventually will abuse them.
> > >
> > >
> > > Option 1: IP-based limiting
> > > ===
> > > The original idea was to set a hard limit of submissions per week based
> > > on IP address of the submitter.  This has (at least as far as IPv4 is
> > > concerned) the advantages that:
> > >
> > > - submitted has limited control of his IP address (i.e. he can't just
> > > submit stuff using arbitrary data)
> > >
> > > - IP address range is naturally limited
> > >
> > > - IP addresses have non-zero cost
> > >
> > > This method could strongly reduce the number of fake submissions one
> > > attacker could devise.  However, it has a few problems too:
> > >
> > > - a low limit would harm legitimate submitters sharing IP address
> > > (i.e. behind NAT)
> > >
> > > - it actively favors people with access to large number of IP addresses
> > >
> > > - it doesn't map cleanly to IPv6 (where some people may have just one
> IP
> > > address, and others may have whole /64 or /48 ranges)
> > >
> > > - it may cause problems for anonymizing network users (and we want to
> > > encourage Tor usage for privacy)
> > >
> > > All this considered, IP address limiting can't be used the primary
> > > method of preventing fake submissions.  However, I suppose it could
> work
> > > as an additional DoS prevention, limiting the number of submissions
> from
> > > a single address over short periods of time.
> > >
> > > Example: if we limit to 10 requests an hour, then a single IP can be
> > > used ot manufacture at most 240 submissions a day.  This might be
> > > sufficient to render them unusable but should keep the database
> > > reasonably safe.
> > >
> > >
> > > Option 2: proof-of-work
> > > ===
> > > An alternative of using a proof-of-work algorithm was suggested to me
> > > yesterday.  The idea is that every submission has to be accompanied
> with
> > > the result of some cumbersome calculation that can't be trivially run
> > > in parallel or optimized out to dedicated hardware.
> > >
> > > On the plus side, it would rely more on actual physical hardware than
> IP
> > > addresses provided by ISPs.  While it would be a waste of CPU time
> > > and memory, doing it just once a week wouldn't be that much harm.
> > >
> > > On the minus side, it would penalize people with weak hardware.
> > >
> > > For example, 'time hashcash -m -b 28 -r test' gives:
> > >
> > > - 34 s (-s estimated 38 s) on Ryzen 5 3600
> > >
> > > - 3 minutes (estimated 92 s) on some old 32-bit Celeron M
&g

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Tomas Mozes]

On Thu, May 21, 2020 at 10:47 AM Michał Górny  wrote:

> Hi,
>
> TL;DR: I'm looking for opinions on how to protect goose from spam,
> i.e. mass fake submissions.
>
>
> Problem
> ===
> Goose currently lacks proper limiting of submitted data.  The only
> limiter currently in place is based on unique submitter id that is
> randomly generated at setup time and in full control of the submitter.
> This only protects against accidental duplicates but it can't protect
> against deliberate action.
>
> An attacker could easily submit thousands (millions?) of fake entries by
> issuing a lot of requests with different ids.  Creating them is
> as trivial as using successive numbers.  The potential damage includes:
>
> - distorting the metrics to the point of it being useless (even though
> some people consider it useless by design).
>
> - submitting lots of arbitrary data to cause DoS via growing
> the database until no disk space is left.
>
> - blocking large range of valid user ids, causing collisions with
> legitimate users more likely.
>
> I don't think it worthwhile to discuss the motivation for doing so:
> whether it would be someone wishing harm to Gentoo, disagreeing with
> the project or merely wanting to try and see if it would work.  The case
> of SKS keyservers teaches us a lesson that you can't leave holes like
> this open a long time because someone eventually will abuse them.
>
>
> Option 1: IP-based limiting
> ===
> The original idea was to set a hard limit of submissions per week based
> on IP address of the submitter.  This has (at least as far as IPv4 is
> concerned) the advantages that:
>
> - submitted has limited control of his IP address (i.e. he can't just
> submit stuff using arbitrary data)
>
> - IP address range is naturally limited
>
> - IP addresses have non-zero cost
>
> This method could strongly reduce the number of fake submissions one
> attacker could devise.  However, it has a few problems too:
>
> - a low limit would harm legitimate submitters sharing IP address
> (i.e. behind NAT)
>
> - it actively favors people with access to large number of IP addresses
>
> - it doesn't map cleanly to IPv6 (where some people may have just one IP
> address, and others may have whole /64 or /48 ranges)
>
> - it may cause problems for anonymizing network users (and we want to
> encourage Tor usage for privacy)
>
> All this considered, IP address limiting can't be used the primary
> method of preventing fake submissions.  However, I suppose it could work
> as an additional DoS prevention, limiting the number of submissions from
> a single address over short periods of time.
>
> Example: if we limit to 10 requests an hour, then a single IP can be
> used ot manufacture at most 240 submissions a day.  This might be
> sufficient to render them unusable but should keep the database
> reasonably safe.
>
>
> Option 2: proof-of-work
> ===
> An alternative of using a proof-of-work algorithm was suggested to me
> yesterday.  The idea is that every submission has to be accompanied with
> the result of some cumbersome calculation that can't be trivially run
> in parallel or optimized out to dedicated hardware.
>
> On the plus side, it would rely more on actual physical hardware than IP
> addresses provided by ISPs.  While it would be a waste of CPU time
> and memory, doing it just once a week wouldn't be that much harm.
>
> On the minus side, it would penalize people with weak hardware.
>
> For example, 'time hashcash -m -b 28 -r test' gives:
>
> - 34 s (-s estimated 38 s) on Ryzen 5 3600
>
> - 3 minutes (estimated 92 s) on some old 32-bit Celeron M
>
> At the same time, it would still permit a lot of fake submissions.  For
> example, randomx [1] claims to require 2G of memory in fast mode.  This
> would still allow me to use 7 threads.  If we adjusted the algorithm to
> take ~30 seconds, that means 7 submissions every 30 s, i.e. 20k
> submissions a day.
>
> So in the end, while this is interesting, it doesn't seem like
> a workable anti-spam measure.
>
>
> Option 3: explicit CAPTCHA
> ==
> A traditional way of dealing with spam -- require every new system
> identifier to be confirmed by solving a CAPTCHA (or a few identifiers
> for one CAPTCHA).
>
> The advantage of this method is that it requires a real human work to be
> performed, effectively limiting the ability to submit spam.
> The disadvantage is that it is cumbersome to users, so many of them will
> just resign from participating.
>
>
> Other ideas
> ===
> Do you have any other ideas on how we could resolve this?
>
>
> [1] https://github.com/tevador/RandomX
>
>
> --
> Best regards,
> Michał Górny
>



Sadly, the problem with IP addresses is (in this case), that there are
anonymous. One can easily start an attack with thousands of IPs (all around
the world).

One solution would be to introduce user accounts:
- one needs to register with an email
- you can rate limit based on 

Re: [gentoo-dev] Last rites: app-admin/ngxtop

[Tomas Mozes]

On Sun, Apr 19, 2020 at 2:04 PM Michał Górny  wrote:

> # Michał Górny  (2020-04-19)
> # Unmaintained.  Stuck on Python 3.6.  Last upstream activity in 2015.
> # Removal in 30 days.  Bug #718184.
> app-admin/ngxtop
>
> --
> Best regards,
> Michał Górny
>
>
I know it's old, but it works with python 3.8 (thanks to patches by jlec):
https://github.com/gentoo/gentoo/pull/15440

Seems like goaccess may be a good alternative too.

Tomas

Re: [gentoo-dev] automated build failure bugs

[Tomas Mozes]

On Mon, Feb 24, 2020 at 9:46 AM Jaco Kroon  wrote:

> Hi All,
>
> Example:  https://bugs.gentoo.org/710484
>
> Relates to the dropping of my_bool from mysql-connector-c.
>
> This has been addressed upstream and a ~ ebuild has been pushed.
>
> My question is simple:  Is that good enough to close the bug?  Do I need
> to remove 13.29.1 from the tree (via proxy maint PR).
>
> How do I chase stabilization process (https://bugs.gentoo.org/705754),
> which has been requested a while ago for 13.29.1 already, as part of a
> security issue (https://bugs.gentoo.org/689796)?
>
> Kind Regards,
> Jaco
>
>
Since mysql-connector-c is stable we should stabilize net-misc/asterisk
with the fix.

[gentoo-dev] RFC: UID/GID assignment for graylog (478)

[Tomas Mozes]

Hello,
I'd like to reserve gid/uid 478 for graylog. Haven't found in other
databases, this seems like the next free id.

https://github.com/gentoo/gentoo/pull/13727

Thanks,
Tomas

[gentoo-dev] RFC: UID/GID assignment for redis (75)

[Tomas Mozes]

Hello,
Redis allocated UID/GID 75 via the user eclass, converting to
acct-user/group in PR:
https://github.com/gentoo/gentoo/pull/13619

Tomas

Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-analyzer/zabbix

[Tomas Mozes]

On Thu, Nov 7, 2019 at 11:13 AM Vadim A. Misbakh-Soloviov 
wrote:

> I'm using zabbix, but I can't sign up as the single active maintainer,
> although, I'd be happy to co-maintain it with somebody else.
>
> BTW, @mgorny, as I see, Patrick already fixed the issue, so can we talk
> about
> unmasking and un-lastriting zabbix now?
>
>
> --
> Best regards,
> mva


It's not masked any more.

Re: [gentoo-dev] Last rites: net-mail/pflogsumm

[Tomas Mozes]

On Wed, Nov 6, 2019 at 11:22 AM Michał Górny  wrote:

> # Michał Górny  (2019-11-06)
> # Unmaintained.  EAPI 0.  Last revdep gone.
> # Removal in 30 days.  Bug #699438.
> net-mail/pflogsumm
>
> --
> Best regards,
> Michał Górny
>
>
I'll take it: https://github.com/gentoo/gentoo/pull/13567

Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

[Tomas Mozes]

On Mon, Nov 4, 2019 at 4:50 AM Joonas Niilola  wrote:

>
> On 11/4/19 1:37 AM, William Breathitt Gray wrote:
> > Hello,
> >
> > `games-action/minetest` creates a "minetest" user and group with random
> > respective IDs, used for running the Minetest server daemon. The latest
> > version bump PR (https://github.com/gentoo/gentoo/pull/13272) follows
> > GLEP 81 by creating acct-{group,user}/minetest with 481 assigned as
> > their respective IDs.
> >
> > Is this assignment all right?
> >
> > Thank you,
> >
> > William Breathitt Gray
> >
>
> Hey,
>
>
> 481 was already requested for mongodb.
>
>
> https://archives.gentoo.org/gentoo-dev/message/b981a29d9ade23d10663f0c0ae850044
>
>
> -- juippis
>
>
Sorry, I haven't seen this UID/GID in the ML so I used it, haven't checked
the PRs on github. Next time, please send a mail to the ML along with the
PR creation.

Thanks,
Tomas

[gentoo-dev] RFC: UID/GID assignment for mongodb (481)

[Tomas Mozes]

Hello,
I'd like to reserve UID/GID 481 for dev-db/mongodb. UID/GID from fedora is
already taken, so allocating the next free.

Pending PR:
https://github.com/gentoo/gentoo/pull/13529

Thanks,
Tomas

[gentoo-dev] RFC: UID/GID assignment for kibana (269)

[Tomas Mozes]

I would like to reserve UID/GID 269 for kibana (www-apps/kibana-bin). The
uid/gid used in Arch for kibana is taken by qmail in Gentoo.

Pending PR:
https://github.com/gentoo/gentoo/pull/12984

Thanks,
Tomas

[gentoo-dev] RFC: UID/GID assignment for elasticsearch (183)

[Tomas Mozes]

I would like to reserve UID/GID 183 for elasticsearch
(app-misc/elasticsearch). It's the same as in Fedora.

Pending PR:
https://github.com/gentoo/gentoo/pull/12983

Thanks,
Tomas

Re: [gentoo-dev] UID/GID assignment for kibana

[Tomas Mozes]

On Fri, Sep 20, 2019 at 6:36 PM Joonas Niilola  wrote:

> Hey,
>
>
> On 9/20/19 7:12 PM, Tomas Mozes wrote:
> > Hi there,
> > while trying to implement glep 81 for kibana I found out that Arch
> > Linux uses uid 183 for it, but it's taken by qmail.eclass. Should a
> > new uid/gid be taken or it's safe to assume no one will mix kibana
> > with qmail?
> >
> >
> I can't find this info anywhere. There's a pull request currently open
> for acct-*/qmail stuff, that seems to reserve 200+ for it (like shown in
> uid-gid.txt). Nothing seems to reserve 183 as far as I can tell?
>
>   - https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.txt
>
>   -
>
> https://github.com/gentoo/gentoo/pull/12898/files#diff-bb8c77449e92c212844f37fc9a56e12aL105
>
>
> -- juippis
>
>
>
Oh I'm sorry, I'm also working on elasticsearch which will have uid/gid
183. Kibana in Arch uses uid 206 and that conflicts with qmails.

Tomas

[gentoo-dev] UID/GID assignment for kibana

[Tomas Mozes]

Hi there,
while trying to implement glep 81 for kibana I found out that Arch Linux
uses uid 183 for it, but it's taken by qmail.eclass. Should a new uid/gid
be taken or it's safe to assume no one will mix kibana with qmail?

Thanks,
Tomas

Re: [gentoo-dev] RFC: UID/GID assignment for logstash (270)

[Tomas Mozes]

On Thu, Aug 8, 2019 at 3:31 PM Michael Orlitzky  wrote:

> On 8/8/19 3:37 AM, Tomas Mozes wrote:
> >
> > Pending PR:
> > https://github.com/gentoo/gentoo/pull/12375
> >
>
> Is the group-writability really needed here?
>
> >  ACCT_USER_HOME_PERMS=0770
>
> I don't think the existing ebuilds change the permissions on that
> directory. In any case,
>
> > keepdir "/var/lib/${MY_PN}"
>
> is no longer needed because the user package will keepdir it.
>


Yes, you are right, I'll update the PR, thanks for the review.

[gentoo-dev] RFC: UID/GID assignment for logstash (270)

[Tomas Mozes]

I would like to reserve UID/GID 270 for logstash (app-admin/logstash-bin).

I haven't found the ID in other databases.

Pending PR:
https://github.com/gentoo/gentoo/pull/12375

Thanks,
Tomas

Re: [gentoo-dev] Is there any way I can help with pull requests?

[Tomas Mozes]

You can review the PRs and try to remove common errors before the devs
check it. Then they don't have to correct the same mistakes again. I don't
mean you do the corrections, you just suggest them to the PR authors so
they probably won't repeat them again.

Common stuff like:
- using latest eapi (at least for new pkgs)?
- correct distfile name?
- proxy maint project in metadata?
- correct, sorted deps?
- slot operators for rebuilds?
- working tests if possible?
- patches from reliable sources?
- using || die after commands?
- reusing eclasseses instead of custom solutions?
- openrc/systemd done right?
- is it secure?
- you name it... :)

Maybe we could script some of these to help too.

[gentoo-dev] Package up for grabs: dev-util/yuicompressor

[Tomas Mozes]

The following package is up for grabs:

dev-util/yuicompressor

It's a js/css minifier written in Java

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Tomas Mozes]

On Fri, May 19, 2017 at 6:50 PM, Patrick Lauer  wrote:

> I tried removing proxy-maint from metadata after multiple discussions
> failed. Extra happiness towards monsieurp "but the GH PR is over 3 days
> old, I have to commit" and gokturk "Yes I understand. I commit anyway"
>
> This has been an uphill struggle since about October, around New Year I
> stopped actively caring, and since these two commits:
>
> 12c3eacda7c4d23686eaf10eab21d810cc95ea49
> f42d6679c038c3efcc257d38547267d01823aea9
>
> I see no way to fix this situation that doesn't involve a review board in
> front of all proxy-maint commits. Because we discussed this in IRC, and
> still ... "but is open bug"
>
> However, as far as I'm aware none of this happened. Note that I might
>> have missed the mail, or it might have been sent before I joined --
>> correct me if that is the case.
>>
>
> There were multiple discussions in IRC, which the involved people usually
> forgot within about 20 minutes and then resumed doing stuff.
>
> I tried removing proxy-maint from metadata, which was reverted (sooo how
> does one *not* have constant interference?)
>
> As Alec pointed out, it is a normal procedure in Gentoo to remove old
>> versions of software if there is no explicit indication that they need
>> to be kept. Therefore, I don't see anything wrong with the proxied
>> maintainer wishing to clean the old versions up and/or not requesting
>> your explicit permission for that. If you needed the old versions, you
>> should have made that clear.
>>
>
> One could ask, maybe. I guess I can (mis)understand this to mean that I
> can do with packages with you in metadata what I want because ... err...
> shiny!
>
> I should also point out that the steps you've taken (and listed in this
>> mail) are not really relevant. They make you look like a sloppy
>> maintainer, and a bad Gentoo developer at the best -- and I doubt anyone
>> would connect removing proxy-maint team with a necessity of keeping
>> an old version.
>>
>
> The cooperation that I had with ferki was pretty good (mostly because we
> sat next to each other in the office). The contributions from Tomas were on
> average pretty ok, just needed some minor cleanups here and there.
>
> The blind "but PR is open for 3 days" commits from proxy-maint made it
> extremely hard to review what changed in a timely manner, so that I
> basically didn't want to care for this pile of stupid for the last, ahem, 6
> months or so. Especially since whenever I wanted to review things some
> joker made some new changes which made me go "eh whut how you? banana
> banana!" so I pushed reviewing a week into the future and ...
>
> I have no idea how I could have fixed this without the QA+Comrel banhammer
> combo, which is a totally insane "fix" to a problem that shouldn't even
> exist. But I see no other options how to make people understand that "No
> means no".
>
> Is this the new normal?
>
>

Everybody makes mistakes, but let's look from another perspective.
Elasticsearch 5.0 got released - a new major version. You did the bump, but
it didn't work (it was clearly pushed to the repo untested as
openrc/systemd version both failed:
https://bugs.gentoo.org/show_bug.cgi?id=598732
https://bugs.gentoo.org/show_bug.cgi?id=597454
Why didn't you fix it yourself?

Same for logstash:
https://bugs.gentoo.org/show_bug.cgi?id=597452
https://bugs.gentoo.org/show_bug.cgi?id=598422
Why did you commit a broken ebuild to the repo and never fixed it after
yourself? These bugs were open for weeks and months, not days...

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Tomas Mozes]

On Fri, May 19, 2017 at 6:38 PM, Patrick Lauer  wrote:

>
> I "was" package maintainer and relied on these versions.
>
> If I as maintainer have no control over such things, why am I maintainer,
> and why do I need an overlay?
>
>
> ... that sounds exquisitely confused, I have no idea why this discussion
> even exists.
>
>
>
The elastic stack is moving pretty fast. As you might have noticed, several
security issues were fixed during the development, but still we kept really
old versions in portage. I'm fine with keeping older branches if they are
maintained, but we kept unmaintained branches (for example we had almost 20
versions of elasticseach).

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Tomas Mozes]

On Wed, May 17, 2017 at 6:38 PM, Patrick Lauer  wrote:

> For some strange reason I was listed there as maintainer, but since no one
> wanted to listen to my ideas I guess I wasn't. So now last person who
> touched it gets stuck with it.
>


For elasticsearch, you added yourself to the maintainers, so why are you
surprised to be there (e6175815b5792f09acd90627af5fe23f616ad245)?

You also added yourself to other packages, for example elasticsearch-cutor
(bd21ed1ef20cb2d27a87a4dadf780565236a72cd) without asking the maintainer
(me at that time).

And where exactly have you expressed your ideas?



>
> Since proxy-maint refuses to be removed from packages (especially since
> they were unconditionally added to all packages with a non-gentoo-dev
> maintainer in metadata) they are the de facto maintainers, and overrule
> everything else.
> I've tried multiple strategies including removing them from metadata, but
> ... see app-admin/elasticsearch, proxy-maint is like the toe fungus that
> always comes back (e.g. commit f0925c10834464e62ce7209f2afa7797b594d350 )
>


Why did you add me as the maintainer of elasticsearch without asking and
then removing proxy-maint so I cannot make any changes to elasticsearch at
all? If you want to make all the changes, then I don't need to be there and
I can just open regular bug reports and you merge them.



>
> Sometimes it's almost absurdly funny, especially when you commit
> RESTRICT="test" because tests fail reliably just to have that reverted.
> (See dev-python/elasticsearch-py )
>

Regarding RESTRICT="test", I was the one to revert your change because I
thought it's a mistake as the tests passed for me. As soon as we discussed
this via irc that it only happens in chroot, it got back. Now a few days
ago @mrueg accidentally removed the restriction but after mailing him he
reverted his change so it's as you made it.



>
> Bonus mention:
> bbdc5412061adf598ed935697441a7d6b05f7614
> app-admin/logstash-bin: drop old
>
> Signed-off-by: Andrew Savchenko 
>
> That removed the versions I was using, so I better maintain the versions I
> use in an overlay. Well ok then.
>
>
Logstash is yet another package where you made yourself a maintainer
without asking the maintainer (again, it was me). I don't remember you ever
wanting to keep the old version of logstash in the repo. Plus, you don't
need to update and you can mask the update. If you really want to use and
old version (we already had multiple version of 5.x in the tree by that
time), you can keep in your overlay.

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

[Tomas Mozes]

On Wed, Apr 19, 2017 at 8:25 PM, Walter Dnes  wrote:

> > It is stable. Even there are open bugs, arches started stabilizing it.
>
>   Is gcc-5.4.0 built "--with-default-libstdcxx-abi=gcc4-compatible"?
> On the Pale Moon linux sub-forum, there were crashing issues with the
> contributed Ubuntu build when Ubuntu switched to gcc 5.  The maintainer
> of the Ubuntu Pale Moon build had to drop back to gcc 4.9 to fix the
> crashes.
>
>   At home, for personal use, I build Pale Moon with a manually built
> version of gcc 5.4.0.  Pale Moon has been rock solid for me on Gentoo
> and on a refurbished Lenovo T400 running Puppy Linux.  The option
> "--with-default-libstdcxx-abi=gcc4-compatible" may be the reason it
> works for me.
>
>   This may be valid for other applications, too.  I think the problem is
> that you need the entire system to be one of...
>
> "--with-default-libstdcxx-abi=new" or
>
> "--with-default-libstdcxx-abi=gcc4-compatible"
>
>   Mixing together does not seem to work.
>
> --
> Walter Dnes 
> I don't run "desktop environments"; I run useful applications
>
>
The default is new:
https://www.gentoo.org/support/news-items/2015-10-22-gcc-5-new-c++11-abi.html

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

[Tomas Mozes]

On Wed, Apr 19, 2017 at 9:31 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Tomas Mozes wrote:
>
> > On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
> > joerg.schai...@bpm-inspire.com> wrote:
> >
> >> Hi,
> >>
> >> according the logs, gcc 4.5.0-r3 is stable for amd64:
> >> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
> >>
> >> However, after synching the tree, this version is still unstable for me.
> >> Looking at the packages overview, it becomes even more weird, because
> >> there seem to be two 4.5.0-r3 versions, one stable for amd64 and one
> >> unstable: https://packages.gentoo.org/packages/sys-devel/gcc
> >>
> >> Can someone shed some light on this?
> >>
> >> Cheers,
> >> Jörg
> >>
> >>
> >>
> > You did mean 5.4.0-r3, right?
>
> Right. And James found the reason why was not in the stable branch.
>
> Cheers,
> Jörg
>
>
>
It is stable. Even there are open bugs, arches started stabilizing it.

What do you get when you run:
# emerge -pv =sys-devel/gcc-5.4.0-r3

Re: [gentoo-dev] stable gcc 5.4.0 ??

[Tomas Mozes]

On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi,
>
> according the logs, gcc 4.5.0-r3 is stable for amd64:
> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
>
> However, after synching the tree, this version is still unstable for me.
> Looking at the packages overview, it becomes even more weird, because there
> seem to be two 4.5.0-r3 versions, one stable for amd64 and one unstable:
> https://packages.gentoo.org/packages/sys-devel/gcc
>
> Can someone shed some light on this?
>
> Cheers,
> Jörg
>
>
>
You did mean 5.4.0-r3, right?

Re: [gentoo-dev] Re: Re: stable gcc 5.4.0 ??

[Tomas Mozes]

On Tue, Apr 18, 2017 at 3:12 PM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Tomas Mozes wrote:
>
> [snip]
>
> > As mentioned by others, bugs on packages.gentoo.org will not affect your
> > portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing
> > your portage tree. Don't you have it in your package.mask?
>
> As said, I synced the tree twice this morning (4 hours ago) and the
> KEYWORDS
> in the ebuild do not declare amd64 as stable although it was committed to
> GIT already yesterday. And this is no wonder, because the stable branch of
> the GIT mirror is still not up-to-date:
> https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc
>
> gcc-4.5.0-r3 is declared unstable and is not masked.
>
> Cheers,
> Jörg
>
>
>
According to git
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e2be964b72fce0cdb7c16a378b4fa3fa1d37ee38
- the KEYWORDS have amd64 and x86. The github mirror shows the same
https://raw.githubusercontent.com/gentoo-mirror/gentoo/stable/sys-devel/gcc/gcc-5.4.0-r3.ebuild.
Syncing the tree shows the same.

And as such, on a stable system:

# emerge -p gcc
[ebuild  NS] sys-devel/gcc-5.4.0-r3:5.4.0::gentoo [4.9.4:4.9.4::gentoo]
USE="cxx fortran (multilib) nptl openmp sanitize vtv (-altivec) (-awt)
-cilk -debug -doc (-fixed-point) -gcj -go -graphite (-hardened) (-jit)
(-libssp) -mpx -nls -nopie -nossp -objc -objc++ -objc-gc -regression-test
-vanilla" 0 KiB

The git message says it's stable, the bug report also, the mirrors too, so
yes, it is stable now. Maybe check another rsync mirror.

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

[Tomas Mozes]

On Tue, Apr 18, 2017 at 11:16 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi Tomas,
>
> Tomas Mozes wrote:
>
> > On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
> > joerg.schai...@bpm-inspire.com> wrote:
> >
> >> Hi,
> >>
> >> according the logs, gcc 4.5.0-r3 is stable for amd64:
> >> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
> >>
> >> However, after synching the tree, this version is still unstable for me.
> >> Looking at the packages overview, it becomes even more weird, because
> >> there seem to be two 4.5.0-r3 versions, one stable for amd64 and one
> >> unstable: https://packages.gentoo.org/packages/sys-devel/gcc
> >>
> >> Can someone shed some light on this?
> >>
> >> Cheers,
> >> Jörg
> >>
> >>
> >>
> > On which platform do you have it unstable? The packages problem is
> > probably related to:
> > https://bugs.gentoo.org/show_bug.cgi?id=612178
>
> Amd64.
>
> Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my
> machine
> lists amd64 as unstable after synching the tree while the ebuild available
> over packages.gentoo.org has a stable version in KEYWORDS.
>
> Even if some GIT mirrors might be out of sync, it does not explain why
> https://packages.gentoo.org/packages/sys-devel/gcc lists the same version
> more than once.
>
> Cheers,
> Jörg
>
>
>
As mentioned by others, bugs on packages.gentoo.org will not affect your
portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing
your portage tree. Don't you have it in your package.mask?

Re: [gentoo-dev] stable gcc 5.4.0 ??

[Tomas Mozes]

On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi,
>
> according the logs, gcc 4.5.0-r3 is stable for amd64:
> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
>
> However, after synching the tree, this version is still unstable for me.
> Looking at the packages overview, it becomes even more weird, because there
> seem to be two 4.5.0-r3 versions, one stable for amd64 and one unstable:
> https://packages.gentoo.org/packages/sys-devel/gcc
>
> Can someone shed some light on this?
>
> Cheers,
> Jörg
>
>
>
On which platform do you have it unstable? The packages problem is probably
related to:
https://bugs.gentoo.org/show_bug.cgi?id=612178

[gentoo-dev] Packages up for grabs

[Tomas Mozes]

These packages are now up for grabs:

dev-python/httmock
dev-python/jenkins-autojobs
dev-python/jenkins-webapi
dev-python/jenkinsapi

Re: [gentoo-dev] Re: Last rites: www-apps/egroupware

[Tomas Mozes]

On Thu, Jul 7, 2016 at 8:50 AM, J. Roeleveld  wrote:

> On Thursday, July 07, 2016 06:37:09 AM Duncan wrote:
> > J. Roeleveld posted on Wed, 06 Jul 2016 20:22:57 +0200 as excerpted:
> > > On Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
> > >> # Aaron Bauman  (30 Jun 2016)
> > >> # Unpatched security vulnerability per bug #509920.
> > >> # Removal in 30 days www-apps/egroupware
> > >
> > > Why is this bug being used to treeclean egroupware?
> > >
> > > Why is bug  461212 not being used to actually resolve the issue?
> > > If I would actually be confident that it would actually be used, I
> would
> > > have no issue on trying to get my latest ebuild ( version 14.3.20160525
> > > ) converted to the latest standards.
> >
> > According to equery meta, egroupware has no individual developer
> > maintainer and no proxied maintainer, only the webapps project as
> > maintainer.  And apparently there, nobody has been specifically
> > interested in egroupware, so it has fallen thru the cracks to some
> > degree, tho newer versions /may/ be in the webapps-experimental overlay.
>
> I tried contacting the web-apps project directly, but never received a
> reply.
>
> > Here's the webapps project wiki page:
> >
> > https://wiki.gentoo.org/wiki/Project:Webapps
> >
> > That has this to say when discussing the overlay, quote:
> >
> 
> >
> > The overlay can be found here:
> > https://cgit.gentoo.org/proj/webapps-experimental.git/
>
> Last commit in 2011.
>
> > Warning
> > Please remember that the applications available through the overlay might
> > compromise the security of your server!
> >
> > The overlay is an ideal playground for new developers wishing to join our
> > team. Once we see that you are capable of writing ebuilds of reasonable
> > quality, we can provide you with commit rights to the overlay.
> >
> > End quote.
> >
> >
> > So it's possible newer versions are in the overlay, and they simply
> > decided it was too much of a load to keep a version in the tree as well.
> >
> > If there /aren't/ newer versions in the overlay, presumably it's because
> > nobody that has access has been interested in maintaining it in the
> > overlay either.
> >
> > Either way, given your obvious interest, I'd suggest contacting them
> > about overlay commit rights, and/or volunteering to be the proxied
> > maintainer for this particular package.
>
> Is there a way of finding out who are actually in the web-app project and
> which
> of them would be able and willing to work with me on this and other web
> applications that I actively use?
>
> From the lack of response to the email and lack of updates on the overlay,
> the
> project seems dead to me.
>
> --
> Joost
>
>
>

It's really sad to see a user wanting to keep up the ebuild and with no
response from the webapps team. I can understand being busy, but by
checking https://bugs.gentoo.org/show_bug.cgi?id=461212 it seems it's a
long-term issue. Joost, please try to contact the proxy maintainers team
and open a pull-request on github for the bump, that may be a way.

Good luck.

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Tomas Mozes]

On 2014-12-07 11:37, Michał Górny wrote:

Hello, developers and users.

As some of you know, the toolchain packages in Gentoo suffer from
lack-of-sanity issues and their maintainers are completely unwilling to
improve things. I have finally decided to start working on a fork of
the sys-devel/gcc ebuilds, and I have some bits ready for initial
testing in 'mgorny' repo, so I would like to know your opinion.


Before you start, the shortcomings are:

1. No cross-compilation support. If the project proves being a success
it will be readded at some point. However, I will likely fork glibc
first and work on a sane crossdev alternative.

2. No gcj support. Since the ebuild has been forked out of
toolchain.eclass, and the gcj support suffers a lot of issues there, I
decided there's no point in copying the code. Not sure if anybody
actually uses it, and if it is actually useful for anything but will
probably get reintroduced one day [above 'if' applies too].

3. No bootstrapping, fallbacks and possible some other random feature
support. The goal was pretty much to get gcc compiling first, and avoid
awful lot of effort if things prove to have no future.

4. Hardened is not tested. I think I have copied all the needed code
and fixed some stuff but I have no clue if it still works ;).


Now, the major changes are:

1. Most of the insanity removed. No more toolchain.eclass. The ebuild
has just the code for the current gcc version. You can read it and know
what it does, you don't have to parse a few dozen version conditionals,
runtime conditionals and random crap code that doesn't do anything in
some gcc versions. In fact, I think I removed most of the no-op code.
And now you can actually change something in the ebuild without caring
for gcc3.4, or without breaking stuff for stable ebuilds.

2. USE flags are supposed to work. I've replaced the cases when they
were silently ignored with REQUIRED_USE. I've also removed the silent
removals when they didn't work -- so if your current toolchain is
broken, things may actually fail instead of giving your different gcc
than you wanted. Probably deserves explanatory pkg_pretend() at some
point, with messages like 'disable USE=-foo because your toolchain is
broken'.

3. Things simplified where they could have been simplified. For
example, I removed the big gcc executable moving function and replaced
it with --enable-version-specific-runtime-libs. It was enabled in
toolchain.eclass with a comment 'If we enable it on non-Darwin we screw
up the behaviour this eclass relies on.' So yep, precious cargo cult --
why enable something that would require you to remove your useless
complex function?!

4. Added gx86-multilib love. Now you have abi_* flags to control
the compiler runtime. Of course, since gcc is a pile of random modules
not fit for one another it has different code for different targets. In
particular, on mips you can't do two ABIs -- either single one
(non-multilib) or all three of them (--enable-multilib).

5. Added multilib gcc wrappers. Long story short, multilib gcc now
shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it
doesn't screw up your system! Of course, the final implementation may
differ since it's an early idea but it works. Now distcc happily builds
stuff for your x86 clients.

6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen
rather than silently skipping doc build when it's not installed...

7. Disabled bootstrap by default (and in fact completely for now). It
is not *that* useful, and means time savings (and distcc support):

 Thu Nov  6 20:39:31 2014  sys-devel/gcc-4.9.2
   merge time: 1 hour, 56 minutes and 43 seconds.

 Sun Dec  7 10:46:08 2014  sys-devel/gcc-4.9.2-r100
   merge time: 34 minutes and 55 seconds.


If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
appreciate any bug reports, except for those covering things i've
already listed as missing :). Any further comments will be very helpful
in deciding on the way forward.

If there is a real interest in my fork, I will probably move it to gx86
as sys-devel/gcc-mgorny. I will also be happy to work on replacing
the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.


Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), 
tested to build some core stuff with it:

kernel 3.17, glibc, coreutils, openssl, ssh...

All seems to work fine. I'll try to recompile the whole machine with it.

After emerge, there are these notices:
 * QA Notice: command not found:
 *
 *  /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
3110: pax-mark: command not found
 *  /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
3111: pax-mark: command not found


# emerge -pvq gcc
[ebuild   R   ] sys-devel/gcc-4.9.2-r100  USE=cxx fortran nls nptl 
openmp pie sanitize (-altivec) -doc (-fixed-point) -go -graphite 
(-hardened) (-libssp) -objc -objc++