Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-26 Thread Haelwenn (lanodan) Monnier
[2020-05-25 23:41:23+0200] Piotr Karbowski:
> There are 3 common ways the xorg-server is started:
> - via XDM of some sort, usually forked as root, does not require suid,
> systemd or elogind.

Launching X as root and having it be suid is quite the same thing…

> - via better XDM that can into logind interface, started as regular user
> thanks to logind interface provided by either systemd or elogind.
> - via `startx`, if systemd or elogind are present, can work without
> suid, without them, suid is required.

btw I tried startx without suid a while ago, you can start it with your user 
in the right groups (input, video), which means that now every program that 
you run can snoop input devices and mess with your video outputs.
And X couldn't properly manage DRM master control because you could set 
the DRM master but not drop it (kernel bug but "linux maintains bugs" and 
there is no capabilities to fix it, which could allow to avoid extra groups).

I don't have something like elogind and likely will not as last time I looked 
at how it worked, it felt like reading about an unstable backdoor more than 
anything else.  I'd rather have proper permissions in the kernel.

> Flipping current '+suid (-)elogind' as *default* USE flags on ebuild
> level into '+elogind (-)suid' will not affect first two use cases, and
> affect only 3rd one if neither systemd is used, or elogind is enabled.
> What I'd like to go with is to enable elogind and disable suid on ebuild
> level. The systemd profiles have use.mask for elogind, meaning it's not
> a problem for them. and those who do not want to use any logind provider
> can still opt-out out of it and go back to use suid. It shouldn't really
> affect most of the users in any negative way, if anything, it will make
> more users to not run Xorg as root, which is a positive aspect.
> The alternative way would be to enable elogind on default profile,
> however it would also affect those who run headless Gentoo, of which a
> lot refuse to use any login manager.
> So, dear people of Gentoo, what do you think about turning the current
> possible opt-out of Xorg as root into possible opt-in for running Xorg
> as root? People still will have a choice, just the defaults will be more
> sane.

I think you could have `xorg-server -suid` in the desktop profile, as you 
have elogingd there but on the ebuild level I'm not so sure.  
I'm not particularly against it but then should definitely come with a warning 
and it'll require users to notice the change and warning so they don't end 
up with a broken gentoo after an update.

Re: [gentoo-dev] Package up for grabs: net-im/prosody

2020-05-11 Thread Haelwenn (lanodan) Monnier
[2020-05-11 12:39:05+0200] Tobias Klausmann:
> Hi! 
> As per subject. I am not running any Jabber infrastructure
> anymore.
> Package is in decent shape. Lua 5.2 compatibility is not there,
> but I don't see 5.2 happening soon anyway. The rest of the bugs
> are nice-to-haves and cosmetic stuff.
> I'll keep myself in the maintainers file for another month or so.
> If you want to take over, feel free to drop in and remove me.
> Best,
> Tobias


I already have app-editors/vis with a dependency on lua 5.2+ so I can 
take it if no one else takes it over in let's say two weeks. (I'm open 
for co-maintainance btw)

Only thing is that right now my prosody setup isn't using the ebuild 
(it's an old setup from before I used gentoo, it builds from the hg 
tip/trunk). At least it's likely that I'll just keep using prosody
so a serious while.

Best regards,

Re: [gentoo-dev] Fwd: New eclass suggestion: docs.eclass

2020-04-27 Thread Haelwenn (lanodan) Monnier
[2020-04-27 18:10:43+0200] Andrew Ammerlaan:
> # Copyright 1999-2020 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
> # @ECLASS: docs.eclass
> # Andrew Ammerlaan 
> # @AUTHOR:
> # Author: Andrew Ammerlaan 
> # Based on the work of: Michał Górny 
> # @BLURB: A simple eclass to build documentation.
> # A simple eclass providing functions to build documentation.
> #
> # Please note that docs sets RDEPEND and DEPEND unconditionally
> # for you.
> #
> # This eclass also appends "doc" to IUSE, and sets HTML_DOCS
> # to the location of the compiled documentation
> #
> # The aim of this eclass is to make it easy to add additional
> # doc builders. To do this, add a -setup and
> # -build function for your doc builder.
> # For python based doc builders you can use the 
> # python_append_deps function to append [${PYTHON_USEDEP}]
> # automatically to additional dependencies
> #
> # For more information, please see the Python Guide:
> #

Should change this part to not be about python docs, right?

> case "${EAPI:-0}" in
>   0|1|2|3|4)
>   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
>   ;;
>   5|6|7)
>   ;;
>   *)
>   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
>   ;;
> esac
> # Sets the doc builder to use, currently supports
> # sphinx and mkdocs
> # Sets the location of the doc builder config file.

Path containing the doc builder config file(s).

Re: [gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps

2020-04-19 Thread Haelwenn (lanodan) Monnier
[2020-04-18 21:10:45-0700] Georgy Yakovlev:
> # Georgy Yakovlev  (2020-04-18)
> # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles
> # requires agreement to restrictive license
> # Revdeps that still depend on oracle variants require javafx
> # Please use icedtea or openjdk instead.
> # Removal in 30 days.
> #
> dev-java/oracle-jdk-bin
> dev-java/oracle-jre-bin
> app-forensics/sleuthkit
> app-text/jabref-bin
> dev-java/netbeans-platform
> dev-java/netbeans-harness
> games-util/pogo-manager-bin
> net-p2p/bisq
> sci-mathematics/geogebra

The mask on app-forensics/sleuthkit seems to be faulty/overkill: 
optionally depends on java, only uses oracle-jdk on 4.7.0.

Re: [gentoo-dev] Packages up for grabs

2020-04-14 Thread Haelwenn (lanodan) Monnier
[2020-04-14 11:36:54+0300] Joonas Niilola:
> here's a list of packages recently dropped to maintainer-needed due to
> retirement of multiple inactive proxied maintainers.
> (b) = open bugs,
> (v) = new version is available.
> --
> net-nntp/suck (b,v)
> --

I'll this one, I got it version-bumped in my overlay.

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

2020-03-27 Thread Haelwenn (lanodan) Monnier

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

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

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

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

Re: [gentoo-dev] network sandbox challenge

2020-03-26 Thread Haelwenn (lanodan) Monnier
[2020-03-27 01:16:43+] Samuel Bernardo:
> 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.

Couldn't the snapd_${PV}.vendor.tar.xz available in 
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

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 for the ebuild to work.

Re: [gentoo-dev] autotools

2020-03-26 Thread Haelwenn (lanodan) Monnier
[2020-03-26 17:47:35+] Samuel Bernardo:
> 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:

Not sure if this would work out-of-the-box but this is how it is usually done:

src_prepare() {

src_configure() {
econf \
--with-snap-mount-dir=/var/lib/snapd/snap \
--enable-nvidia-biarch \
--enable-merged-usr \
$(use_enable apparmor)

But as AUR has basically no quality requirement also consider that maybe it 
doesn't need eautoreconf at all, which can be nice to avoid.

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

2020-03-23 Thread Haelwenn (lanodan) Monnier
[2020-03-23 20:27:51+0200] Joonas Niilola:
> On 3/23/20 8:23 PM, William Hubbs wrote:
> > but we need to
> > find a way to notify them when a breaking change is going into a widely
> > used eclass and give them time to adjust their ebuilds.
> >
> >
> > Thoughts?
> >
> Subscribe to this mailing list.
> AFAIK all major changes have been posted here and pushed with some delay.

If this one would be taken it would be nice to have breaking changes 
be noted as so in the Subject.

I probably should but for packages in my overlay, I have no idea what 
eclasses are used and doesn't have much quality needs if any that 
I would read eclass changed to potentially improve the ebuilds in it.

(I do read them for the eclasses that I use in the gentoo & guru repos)

Re: [gentoo-dev] reduce load of tinderox' bug reprots to

2020-03-22 Thread Haelwenn (lanodan) Monnier
[2020-03-22 14:50:25+0100] Toralf Förster:
> I was asked about possible changes of the way how tinderbox detected bugs 
> shall be filed, eg. to reduce the amount of attached files. There were ideas 
> to store eg. logs et al at AWS s3 and use b.g.o. only for the bug report 
> itself.
> I started with the tinderbox being a 1-liner serving my purpose. It grewed up 
> by the needs of other devs. So maybe it is time for changes?
> I do use pybugz to create bugs. Before I do manually check whether it is 
> aalredy reported (yes, this is error prone). Reporting a bug once is my 
> preferred solution. Bercause it is a little bit uncomfortable for me to 
> attach files later manually at individual request.
> I'm open for any opinions / ideas.

I think it might be better to fix bugzilla to be able to send multiple 
attachments at once. AWS S3 might be okay for the long term but I've often seen 
paste services being used and most of them expire in a week/month, so you can 
easily loose the content before it can be read or fixed and absolutely no hope 
to have it be readable if it's an old bug that might have appeared again.

Re: [gentoo-dev] [PATCH] dev-python/metadata.xml: Clarify description

2020-03-10 Thread Haelwenn (lanodan) Monnier
Not sure if I can submit translations, but I'll try:

[2020-03-08 09:51:27+0100] Michał Górny:
> Rewrite the description for dev-python category in order to clarify
> its purpose.  It has been pointed out that the previous description may
> have suggested that it is the category for *all* things written
> in Python.
> Signed-off-by: Michał Górny 
> ---
>  dev-python/metadata.xml | 44 +++--
>  1 file changed, 12 insertions(+), 32 deletions(-)
> // If you can supply translations for the remaining languages, please
> // send them my way and I'll update the patch.
> diff --git a/dev-python/metadata.xml b/dev-python/metadata.xml
> index ed6a813dd009..b90b8f66f45a 100644
> --- a/dev-python/metadata.xml
> +++ b/dev-python/metadata.xml
> @@ -2,41 +2,21 @@
> - The dev-python category contains libraries, utilities or
> - bindings written in or for the Python programming language. 
> + The dev-python category contains packages whose primary purpose
> + is to provide Python modules, extensions and bindings, as well
> + as tools and utilities useful for development in the Python
> + programming language.

La catégorie dev-python contient principalement des paquets pour les 
modules Python, des extensions et des bindings, ainsi que des outils et 
utilitaires utiles dans le language de programmation Python.

Best regards,

Re: [gentoo-dev] [RFC] The right approach to python-r2 (-r3?)

2020-03-04 Thread Haelwenn (lanodan) Monnier
[2020-03-04 13:07:40+0100] Michał Górny:
> Summary
> ===
> So to summarize, of the three proposed approaches:
> 1. A & C provide for fast cleanup of old API with mostly-automated
> conversion.
> 2. B & C provide for gradual cleanup of warnings and old EAPIs, i.e.
> stuff requiring runtime testing.
> 3. A & C makes it possible to get rid of -r1 shortly and reduce
> maintenance effort.
> What do you think?

It looks like you get everything nicely with option C, only drawback 
I can think of is more code but you put it with 3. as maintainance 
reducing so I guess it is the way to go.

But I'm wondering if there is some monster not shown by your email but
maybe it's because I might not have dug deep enough into python on 
gentoo (probably because it has been going nicely so thanks btw).

Re: [gentoo-dev] [RFC v2] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Haelwenn (lanodan) Monnier
[2020-02-19 13:32:01-0800] Patrick McLean:
> Title: OpenSSH 8.2_p1 running sshd breakage
> Author: Patrick McLean 
> Posted: 2020-02-21
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed:  
> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
> Before restarting sshd, it is *strongly* recommended that you test your
> configuraton with the following command (as root):
> sshd -t

Typo: s/configuraton/configuration/

> If your system is booted with openrc, use this command  (as root) 
> to restart sshd:
> rc-service sshd --nodeps restart
> If your system is booted with systemd, use this command (as root)
> to restart sshd:
> systemctl restart sshd
> If you are using systemd socket activation for sshd, then no action is
> required.
> WARNING: On systemd booted machines with PAM disabled, this command
>  will terminate all currently open ssh connections. It is *strongly*
>  recommended that you validate your configuration before restarting
>  sshd.

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-02-11 Thread Haelwenn (lanodan) Monnier
[2020-02-11 10:52:57-0500] Rich Freeman:
> On Tue, Feb 11, 2020 at 10:05 AM Haelwenn (lanodan) Monnier
>  wrote:
> >
> > Maybe it could for now be a simple agreement on putting your code to
> > the Gentoo Foundation under the GPL-2+ but it would be published under
> > the GPL-{2,3,…}?
> >
> Well, if we were going to get people to start signing things I suggest
> just sticking to the FLA since it actually was written by lawyers.

Absolutely, I misunderstood that the FLA wasn't ready at all, it's 
much better to have it instead.

> I attached a copy, but along these lines the key section is:
> We agree to (sub)license the Contribution or any Materials containing,
> based on or derived from your Contribution under the terms of any
> licenses the Free Software Foundation classifies as Free Software
> License and which are approved by the Open Source Initiative as Open
> Source licenses.
> That is, Gentoo would control the licenses, but they would have to be
> FSF/OSI approved.  That doesn't mean that anybody could choose any
> FSF-approved license - Gentoo would still have to do the licensing.
> This is just a limitation on the grant of power from the original
> author to Gentoo on WHAT licenses GENTOO can choose.
> There is also a variant of the FLA that can further narrow down the
> licenses that Gentoo gets to choose from, but IMO if you're going to
> go down this path it makes sense to keep things flexible.  We could of
> course just limit Gentoo to GPL v2+, and initially Gentoo does v2/3
> and later Gentoo could revise to any later version of the GPL.  But if
> for whatever reason the GPL falls out of favor then we can't adapt
> futher.
> Ultimately though anything like this involves giving up control.

Which happens a lot when you have do to anything with others, and is
quite how using the internet and free software sounds like to me.

Anyway, this FLA document generator looks really good to me, much better 
than a weird "or later" on a license.
FSF/OSI sounds a bit too much flexible but personally I think I can 
trust gentoo enough to pick a similar license and otherwise it seems to 
restricts flexibility a bit too much. At least the option of GPL-2+ but 
with the change control put to gentoo would be possible.

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-02-11 Thread Haelwenn (lanodan) Monnier
[2020-01-30 08:19:08-0500] Rich Freeman:
> On Thu, Jan 30, 2020 at 6:20 AM Haelwenn (lanodan) Monnier
>  wrote:
> > [2020-01-27 12:41:26+0100] Ulrich Mueller:
> > > So, the question is, should we allow ebuilds
> > > # Distributed under the terms of the GNU General Public License, v2 or 
> > > later
> > > in the repository, or should we even encourage it for new ebuilds?
> > >
> > > I have somewhat mixed feelings about this. One the one hand, I think
> > > that GPL-2+ should generally be preferred because it offers better
> > > compatibility. For example, the compatibility clause in CC-BY-SA-4.0
> > > won't work with GPL-2.
> >
> > Is there another reason for GPL-2+ than just compatibility?
> > Because I quite find the "or later" thing to be quite a scary one as
> > whatever will come up next as a GPL will become applicable and it feels
> > quite weird to me to have a license that can evolve to whatever
> > license over time.

> Really the main threat (IMO) is that the code could be de-copylefted.
> They could make GPL v4 a copy of the BSD license, and now anything
> that was v2+ is effectively BSD and can be used in non-FOSS software
> without issue.  I guess that isn't any worse than the previous case of
> it instead being merged into some other v4 variant that you can access
> the source for but prefer to avoid because of something else in the
> license, except now you might not see the code at all.

Yeah, I quite share this opinion/view, with also the scary wonder of
who can author a GPL-4 license as there doesn't seems to be any
restriction for this in the license, just a "or later".

> Another solution to this problem is the FLA - which is something we've
> talked about but shelved until we've sorted out some of our other
> copyright issues which were thorny enough.  Perhaps we could consider
> taking that up again.  Without getting into the details it is a bit
> like a copyleft-style copyright assignment, which isn't actually an
> assignment.  We envisoned it being voluntary and would allow any
> contributor to give the Foundation the authority to relicense their
> contributions, with a number of restrictions, like the new license
> being FOSS.  I'd have to dig up the latest version and take a look at
> it again.  Basically instead of trusting the FSF you'd be trusting the
> Foundation instead, but there are some limitations on what they'd be
> allowed to do, and if they violate those limitations the agreement
> would be canceled and the rights would revert back to whatever was on
> the original contribution, which would probably be whatever the author
> originally wanted.  That said, I'm not sure it really provides a whole
> lot more protection over what happens except for the fact that
> Foundation members have more say in how the Foundation operations than
> the FSF, if only because the number of people allowed to vote are
> limited to a relatively small pool Gentoo contributors, at least
> compared to the entire FOSS community.

I guess the FLA would be really interesting to have to get the quite 
useful flexibility of relicensing but keeping it to Gentoo Foundation 
to avoid giving this flexibility to everyone.

Maybe it could for now be a simple agreement on putting your code to 
the Gentoo Foundation under the GPL-2+ but it would be published under 
the GPL-{2,3,…}?

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-01-30 Thread Haelwenn (lanodan) Monnier
[2020-01-27 12:41:26+0100] Ulrich Mueller:
> So, the question is, should we allow ebuilds
> # Distributed under the terms of the GNU General Public License, v2 or later
> in the repository, or should we even encourage it for new ebuilds?
> I have somewhat mixed feelings about this. One the one hand, I think
> that GPL-2+ should generally be preferred because it offers better
> compatibility. For example, the compatibility clause in CC-BY-SA-4.0
> won't work with GPL-2.

Is there another reason for GPL-2+ than just compatibility?
Because I quite find the "or later" thing to be quite a scary one as 
whatever will come up next as a GPL will become applicable and it feels 
quite weird to me to have a license that can evolve to whatever 
license over time.

I think I would personally slightly prefer to have it be properly
dual-licensed GPL-{2,3} or GPL-2 & CC-BY-SA-4.0 instead.

Re: [gentoo-dev] Last rites: dev-python/epydoc

2020-01-29 Thread Haelwenn (lanodan) Monnier
[2020-01-30 06:18:21+0100] David Haller:
> BTW: has it been taken note of that (at least ESR) Mozillen like
> firefox still use python2.7 for quite a bit in the build process?

Yup, filled in:

Also, they litterally bundled python 2.7.9 in Firefox 68.3.0, haven't 
checked the other versions since but wouldn't be surprised that it 
would be the same.

Path is ${S}/obj-x86_64-pc-linux-gnu/_virtualenvs/init/bin/python2.7

Re: [gentoo-dev] New QA Policy Guide

2020-01-19 Thread Haelwenn (lanodan) Monnier
Thanks a lot for this policy guide, finally there is a good documentation 
on them. 

I found one issue with it though, on pages like other-metadata.html and 
keywords.html the links are too large and squish the dt elements, one way 
I found to fix it is by adding `word-break: break-all` to a.reference but 
maybe it should use a selector closer to the root.

[gentoo-dev] Packages up for grabs: www-plugins/passff{,-host}

2019-12-18 Thread Haelwenn (lanodan) Monnier

I'll be removing myself from (proxy-)maintainer of www-plugins/passff 
and www-plugins/passff-host as firefox as been more and more of a pain
to deal with.

For example today I ended up discovering that firefox-68.3.0 bundles 
Python 2.7.9 at ${S}/obj-x86_64-pc-linux-gnu/_virtualenvs/init/bin/python2.7 
which triggered my blob remover that I use to make sure it is actually
built from sources. (not sure if I should file a gentoo bug on this one btw)

They have few bugs, one being solvable by a version bump which should 
fix it. Feel free to ping me on IRC (nick: lanodan) or email for 
questions about the packaging.
Should also be noted that www-plugins/passff could simply go away as
Mozilla plans to remove sideloaded extensions for Firefox 73.0[1].


Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations

2019-12-07 Thread Haelwenn (lanodan) Monnier
[2019-12-06 16:16:32-0800] Georgy Yakovlev:
> On Friday, December 6, 2019 3:44:38 PM PST Sergei Trofimovich wrote:
> > On Fri,  6 Dec 2019 12:09:31 -0800
> > Georgy Yakovlev  wrote:
> > > Default output just prints crate name.
> > > With -vv we can see all cargo options and rustc args.
> > > 
> > > Signed-off-by: Georgy Yakovlev 
> > > ---
> > 
> > While at it I also suggest adding equivalent of
> > econf's/emake's ${EXTRA_ECONF} and ${EXTRA_EMAKE}
> > to allow users to inject arbitrary stuff. For example
> > to sneak in '-Z' options globally.
> > 
> > 
> Yeah, it's on my to-do list for this eclass.
> 1 question tho, should it come after "$@" or before? Do you use it?
> I know cargo can be picky about order and some ebuilds rely on passing params 
> in phase funcs.

I think it should go after `cargo {build,install,test}` and before any 
non-option argument, similar to how POSIX getopt(3) behaves (but that GNU 
breaks without setting POSIXLY_CORRECT=1).

Re: [gentoo-dev] Migrate away from python-2 or not

2019-11-29 Thread Haelwenn (lanodan) Monnier
[2019-11-29 14:49:12+0100] Mathy Vanvoorden:
> > I tried removing python2 on a handful of test systems over the last week
> > ... it's back everywhere.
> >
> >
> I attempted the same over the last couple of days as I was thinking "It's
> going anyway, why not get a head start?". I had to do the following:
> * Remove metagen
> * Remove rr
> * Update kodi and related packages to  (I know they are working on
> getting their 19.0 package out asap because of the 2.7 EOL)
> * Update clang and related packages to 9.0.0
> * Remove python dependency in libdbusmenu (it's not needed, PR here:
> * Port gnome-doc-utils to python3 (
> * Remove qt-creator as it depends on clang 8, changing USE to -clang would
> also work but not really using it anyway atm
> * Remove gconf dep from discord-bin (
> * Remove gconf dep from spotify (
> )
> * Update gcr to 3.34.0 (
> * Unmask a number of other packages that luckily did have updated versions
> available: samba, talloc, javatoolkit, tdb, tevent, ldb, itstool,
> dropbox-cli, nodejs
> * Unmerge typing (now provided by python package)
> * Reinstall m2crypto, python-typing, scons
> * Reinstall crda with patch in
> * Manually fix some packages that were not being selected for emerge by -N:
> m2crypto, virtual/python-typing, typing, scons
> Unfortunately I was not able to completely purge python2.7 from my system.
> The base package is still installed as it is required to build qtwebkit,
> qtwebengine, zziplib, firefox and spidermonkey. At least however I am now
> running with -python_targets_python2_7 so there's that.

Been running my server without python2 since… 2019-11-16 I thought it 
was more than that but still quite a lot considering that I kept clang-8 
for a while before switching to clang-9 on it. (I use clang as main 
compiler, I'm also deprecating gcc so prefer to play it safe)

I still have a bunch of stuff on my desktop requiring python2,
like nodejs or renpy but it's getting quite better in the last months,
one I'm trully fearing about how it will go is dev-util/scons, I guess
a lot of patches will be required on the releases.

I think this kind of discussion might be better on the forums or
a user list btw.

[gentoo-dev] Addressing split usage of USE=gles[123]

2019-11-20 Thread Haelwenn (lanodan) Monnier
Hello gentoo-dev,

First proposition on this list so hopefully not missing some kind of

I noticed for some time that there seems to be two use cases for the 
gles[123] family of USE flags in gentoo repo:
1. enabling support of OpenGL ES, which seems interesting to have for 
more runtime choices, probably better usage of the drivers and better 
binary-compat support.
2. switching from OpenGL (so the full API) to Open GL ES (reduced API), 
which is an entirely different kind of action as that reduces it quite 
significantly but might be useful for machines where the drivers do not 
provide (good) OpenGL.

To reflect this I think the "gles[123]" USE flags should be renamed,
first kind to "gles[123]support" and second kind to "gles[123]only".
Might also be the time to globalize them? I'm not sure but I think that 
would help in signalling which USE flags are to be used in packages.
(and I'm probably not the only one which tends to only put global USE 
flags in make.conf, this kind of USE flags being the reason)

Here is splitting use.local.desc in groups so you get a view of the 
more-or-less current state:

## First kind, enable support (19 packages)
dev-games/ogre:gles2 - Build OpenGL ES 2.x RenderSystem
dev-games/ogre:gles3 - Enable OpenGL ES 3.x Features
dev-libs/efl:gles2 - Enable the OpenGL ES GL implementation
kde-plasma/kinfocenter:gles2 - Show OpenGL ES information in kinfocenter
media-libs/cogl:gles2 - Enable OpenGL ES 2.0 support
media-libs/gst-plugins-bad:gles2 - Enable GLES2 support
media-libs/gst-plugins-base:gles2 - Enable OpenGL library and plugin via GLESv2 
API (requires egl)
media-libs/libprojectm:gles2 - Provide support for OpenGL ES 2 and 3
media-libs/libsdl2:gles - include OpenGL ES support
media-libs/mesa:gles1 - Enable GLESv1 support.
media-libs/mesa:gles2 - Enable GLESv2 support.
media-plugins/gst-plugins-gtk:gles2 - Enable gtkglsink OpenGL sink based on 
media-plugins/gst-plugins-vaapi:gles2 - Enable GLESv2 and GLESv3 support
media-tv/kodi:gles - Enable support for GLES
net-libs/webkit-gtk:gles2 - Enable GLESv2 support
sys-apps/kmscon:gles2 - Enable GLES2 for backend
x11-apps/mesa-progs:gles2 - Build OpenGL ES 2 utilities
x11-libs/cairo:gles2 - Build the OpenGL ES 2 backend
x11-wm/mutter:gles2 - Enable OpenGL ES 2.0 support

## Second kind, switch from OpenGL to OpenGL ES (20 packages)
dev-libs/weston:gles2 - Use GLESv2 cairo instead of full GL
dev-python/PyQt5:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qt3d:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qtdatavis3d:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qtdeclarative:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qtgui:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qtmultimedia:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qtopengl:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qtprintsupport:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qtwebkit:gles2 - Use GLES 2.0 or later instead of full OpenGL
dev-qt/qtwidgets:gles2 - Use GLES 2.0 or later instead of full OpenGL
games-emulation/mupen64plus-core:gles2 - Use GLES2 instead of OpenGL
games-emulation/mupen64plus-video-glide64mk2:gles2 - Use GLES2 instead of OpenGL
games-emulation/mupen64plus-video-rice:gles2 - Use GLES2 instead of OpenGL
kde-apps/kdenlive:gles2 - Use GLES 2.0 or later instead of full OpenGL
kde-frameworks/plasma:gles2 - Use GLES 2.0 or later instead of full OpenGL
kde-plasma/kwin:gles2 - Use OpenGL ES 2 instead of full GL
sci-libs/opencascade:gles2 - Use OpenGL ES 2.0
www-plugins/freshplayerplugin:gles2 - Use system GLESv2 libraries instead of 
ANGLE for shader translation
www-plugins/lightspark:gles - Replace default OpenGL renderer with GLESv2

Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode

2019-11-16 Thread Haelwenn (lanodan) Monnier
[2019-11-16 11:05:54+0200] Jaco Kroon:
> On 2019/11/15 21:35, Matt Turner wrote:
> > On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller  wrote:
> >> The package is somewhat redundant, because sys-kernel/linux-firmware
> >> installs the same files. (Same for all other sys-firmware/iwl*-ucode
> >> packages.)
> > Should last-rite all of them, IMO.
> >
> I both agree and disagree with this.  It's the simpler solution and
> therefore I agree.
> I disagree because in some cases I really only want specific firmware
> for specific sets of hardware (especially where space constraints are an
> issue, read: embedded type systems).
> The current linux-firmware package is getting quite big in terms of install.

Well there is savedconfig on linux-firmware for a reason.

Re: [gentoo-dev] RFC: Create ejabberd project

2019-10-28 Thread Haelwenn (lanodan) Monnier
[2019-10-28 11:12:49+0100] Hanno Böck:
> There are a bunch of dev-erlang/* packages whose primary reason for
> packagin is that they're dependencies of ejabberd (and they're becoming
> more), most of them currently in maintainer-needed status.
> I'd like to group those together as maintained by an ejabberd project
> and a corresponding mail alias. (And hopefully in the long term won't be
> the only person being in that Project.)

Wouldn't a Erlang project be better, specially as there is the Perl and 
Python projects which are there for probably the same reasons?

Also saying this from a Elixir (language which borrows a lot from Erlang, 
like it's VM, librairies and fault-tolerance) developer point of view 
which tried to package pleroma few months ago in my overlay, there is a 
bunch of shared dependencies and I'm pretty sure there will be more 
Elixir applications in the wild.

Re: [gentoo-dev] Underscores in USE flags

2019-09-20 Thread Haelwenn (lanodan) Monnier
[2019-09-20 13:24:45-0400] Mike Gilbert:
> On Fri, Sep 20, 2019 at 12:55 PM Michał Górny  wrote:
> > On Fri, 2019-09-20 at 12:41 -0400, Mike Gilbert wrote:
> > > On Fri, Sep 20, 2019 at 12:11 PM Michał Górny  wrote:
> > > > On Fri, 2019-09-20 at 11:46 -0400, Mike Gilbert wrote:
> > > > > Recently, a large number of bugs were filed against packages that have
> > > > > USE flag names which contain underscores. Apparently PMS prohibits
> > > > > this except when the USE flag is part of a USE_EXPAND variable.
> > > > >
> > > > >
> > > > >
> > > > > I'm not certain when this text was added to PMS, or how many of the
> > > > > affected USE flags pre-date this policy.
> > > > >
> > > > > Portage seems to have no issue dealing with underscores, so this
> > > > > doesn't seem to be solving any technical problem.
> > > > >
> > > > > I am pretty sure that renaming a bunch of USE flags will cause some
> > > > > amount of end-user confusion, for very little benefit. Is enforcing
> > > > > this part of PMS really worth it?
> > > >
> > > > And having packages with pretended-USE_EXPAND-that-does-not-work-as-
> > > > USE_EXPAND is less confusing to the users?
> > >
> > > I doubt users immediately think "USE_EXPAND" when they see an underscore.
> > >
> > > Portage's seems fairly unambiguous to me. For example:
> > >
> > > % emerge -pv1O app-misc/foo
> > >
> > > These are the packages that would be merged, in order:
> > >
> > > [ebuild  N ] app-misc/foo-0::local  USE="-modern_kernel"
> > > PYTHON_TARGETS="python3_7" VIDEO_CARDS="radeon" 0 KiB
> > >
> > > Total: 1 package (1 new), Size of downloads: 0 KiB
> > >
> > > I don't think anyone would mistake "modern_kernel" for a USE_EXPAND
> > > value  given the above.
> >
> > Look at the humongous list of flags on dev-libs/aws-sdk-cpp.  They all
> > start with 'aws_targets' which is a clear attempt to emulate USE_EXPAND.
> > Expect that they won't work as USE_EXPAND, user typing:
> >
> >   AWS_TARGETS="foo bar baz"
> >
> > will just wildly confused, and in the end this prefixing is just silly
> > and causes the flag names to become awfully long.
> Ok, so you chery-picked one particularly horrible example. The Portage
> output still puts them in USE="" section, though the user probably
> won't see that given the massive USE flag list.
> My point still stands for many of the other packages in the repo that
> don't have several dozen flags.

While that's true for portage, it is false for gentoolkit with the 
`equery u ` command.

Following your original example it would be something like:

% equery y app-misc/foo
[ Legend : U - final flag setting for installation]
[: I - package is installed with flag ]
[ Colors : set, unset ]
 * Found these USE flags for app-misc/foo-0::local
 U I
 - - modern_kernel: Install init scripts for 3.18 or higher kernels 
with atomic rule updates
 + + python_targets_python3_7 : Build with Python 3.7
 - - video_cards_radeon   : VIDEO_CARDS setting to build driver for ATI 
radeon video cards

And with a bunch more of USE flags (not with having to go to extremes like 
dev-libs/aws-sdk-cpp) it is very confusing a lot of time on machines where 
app-portage/eix would be overkill I had to check on another machine.

Re: [gentoo-dev] RFC: GLEP81 home directory guidelines

2019-08-16 Thread Haelwenn (lanodan) Monnier
[2019-08-16 18:40:32-0400] Michael Orlitzky:
> GLEP81 changed two aspects of user management:
>   1 Creating a user can now modify the permissions on an existing
> directory. Should the need arise, this is necessary for a new
> version of an acct-user package to be able to fix the ownership
> and permissions of its home directory
>   2 All user data aside from the username became non-local to ebuilds
> that depend on that user. This is merely a side-effect of moving
> the user creation out of the client package, and into a separate
> acct-user package.
> The first item means that you should be conservative when choosing a
> home directory. If at all possible, avoid choosing a home directory
> that is used by another package. In particular, no two acct-user
> packages should use the same home directory. 

Any reason why sharing home directories isn't simply forbidden?
This is sure to blow on us at some point if there is shared home directories.

>   1 Avoid using an ACCT_USER_HOME that belongs to another package.
>   2 No two acct-user packages should define the same ACCT_USER_HOME.

I feel like this is redundant, even if you would want to also cover
pre-acct-user packages.

>   3 If your package's configuration needs  to be able to
> write to e.g. /var/lib/, then your package's ebuild should
> create that directory and set its ownership and permissions. Barring
> any other considerations, the corresponding acct-user package should
> leave ACCT_USER_HOME at its default (empty) value; setting
> ACCT_USER_HOME=/var/lib/ would violate item (1).
>   4 Each user's home directory should be writable by that user. If it
> is not, that indicates that a shared and potentially sensitive
> location was chosen; and the fact that the home directory is not
> writable suggests that the default (empty) ACCT_USER_HOME would
> suffice instead.

Shouldn't this be owned instead of writable? I'm pretty sure we can 
have cases where no having write permissions is prefered for security.

>   5 As a corollary of the previous item, it is highly suspicious for
> an acct-user package to set ACCT_USER_HOME_OWNER="root:root".

Is there cases where this would be used? It makes no sense to me for a 
home to belong to root.

Re: [gentoo-dev] [PATCH] use.desc: Introduce global USE=magic

2019-08-11 Thread Haelwenn (lanodan) Monnier
[2019-08-11 14:53:34+0200] Michał Górny:
> On Sun, 2019-08-11 at 14:46 +0300, Mart Raudsepp wrote:
> > The USE flag naming feels a bit to be desired by me.
> > That's because I don't believe in USE flags having to be named by the
> > external dep they introduce, but by functionality. USE=magic sounds
> > like a USE flag that adds some wizards into your application, automagic
> > behavior or who knows (until you read the description).
> > Not that I have a much better suggestion. USE=auto-mimetypes?
> > 
> The use of term 'magic' for file type recognition by magic bytes is well
> established.

Yes, but `magic` doesn't really gives much of an idea on the feature 
and could get a bit of confusion, I think `libmagic` is better on this 
regard as it's closer to what would be used without much context and 
it's clear that it's about a dependency on sys-apps/file and not some 
kind of magic feature (which is a quite overloaded word in computing).

(auto-mimetype doesn't works at all btw, file/libmagic is much more 
precise than mimetypes)

Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-23 Thread Haelwenn (lanodan) Monnier
[2019-07-21 08:36:41-0700] Christopher Head:
> On July 20, 2019 1:22:39 PM PDT, "Michał Górny"  wrote:
> >Yes, I get it.  User experience is not important if it would mean
> >developers would actually do anything but the bare minimum to get
> >from one paycheck to another.  The usual Gentoo attitude.
> Is my experience as a user really improved if a package I use is dropped 
> because its maintainer no longer has time to maintain it because they now 
> have to spend their N available hours per month building man pages for one 
> package rather than maintaining two?

Well I guess this is quality versus quantity, which depends if gentoo is tight 
on some of theses packages missing manpages or not… something which I'm not 
aware of as a proxy-maint contributor but I can imagine other devs with this 
issue as well.

Re: [gentoo-dev] tracker for usr merge fixes

2019-07-20 Thread Haelwenn (lanodan) Monnier
[2019-07-20 10:27:53-0500] William Hubbs:
> I saw that someone in another thread asked about a tracker for usr merge
> related fixes.
> There wasn't one, so I opened one.

Looks like there is yet another bugzilla's bug or weird behaviour as
it returns a 404 even when logged in.

Works with

Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-17 Thread Haelwenn (lanodan) Monnier
[2019-07-17 15:25:10+0200] Michał Górny:
> The QA team would like to introduce the following policy:
> """
> Packages must not disable installing manpages via USE flags (e.g.
> USE=man or USE=doc).  If upstream does not ship prebuilt manpages
> and building them requires additional dependencies, the maintainer
> should build them and ship along with the package.
> """

Should this be for any dependency? For example wlroots, sway, … are
using scdoc to transform a form of markdown to manpages, and the
resulting program is very small.

$ qsize scdoc
app-text/scdoc-1.9.3-r1: 5 files, 12 non-files, 59.9K

So in my opinion if the dependency is probably smaller than bundling
the files the dependency should be used.

> Rationale:
> Manpages are the basic form of user documentation on Gentoo Linux.  Not
> installing them is harmful to our users.  On the other hand, requiring
> additional dependencies is inconvenient.  Therefore, packaging prebuilt
> manpages (whenever upstream doesn't do that already) is a good
> compromise that provides user with documentation without additional
> dependencies.

I would fully support that as in my opinion all ebuilds should provide
at least usage documentation though manpages and/or via the 
non-standard -h / --help.

Re: [gentoo-dev] [PATCH 2/4] llvm.eclass: Update examples for newer LLVM versions

2019-04-30 Thread Haelwenn (lanodan) Monnier
[2019-04-30 07:38:56+0200] Michał Górny:
> Signed-off-by: Michał Górny 
> ---
>  eclass/llvm.eclass | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
> index 618a924bbb87..e4052a6400c0 100644
> --- a/eclass/llvm.eclass
> +++ b/eclass/llvm.eclass
> @@ -17,18 +17,19 @@
>  # a proper dependency string yourself to guarantee that appropriate
>  # version of LLVM is installed.
>  #
> -# Example use for a package supporting LLVM 3.8 to 5:
> +# Example use for a package supporting LLVM 5 to 7:
>  # @CODE
>  # inherit cmake-utils llvm
>  #
>  # RDEPEND="
> -# +#  #|| (
> +#sys-devel/llvm:7
> +#sys-devel/llvm:6
>  #sys-devel/llvm:5
> -#sys-devel/llvm:4
> -#>=sys-devel/llvm-3.8:0
>  #)
>  # "
>  #

Shouldn’t LLVM_MAX_SLOT be set to 7 as well?

>  #
> @@ -46,8 +47,9 @@
>  # # note: do not use := on both clang and llvm, it can match different
>  # # slots then. clang pulls llvm in, so we can skip the latter.
>  # RDEPEND="
> -#>=sys-devel/clang-4:=[llvm_targets_AMDGPU(+)]
> +#>=sys-devel/clang-6:=[llvm_targets_AMDGPU(+)]
>  # "
>  #
>  # llvm_check_deps() {
>  #has_version "sys-devel/clang:${LLVM_SLOT}[llvm_targets_AMDGPU(+)]"
> -- 
> 2.21.0

Re: [gentoo-dev] Packages up for grabs from xmw@g.o

2018-11-25 Thread haelwenn (lanodan) Monnier
[2018-11-25 11:04:57] Michał Górny:
> Hello, everyone.
> Due to long-time inactivity, the following packages are now up for
> grabs.  Given the length of the list, please forgive me for any
> mistakes.

Can I take theses as a proxy-maintainer? Thanks.
> app-misc/golly
> app-misc/hexcompare
> app-misc/toilet

Theses last three seems quite important so I encourage a developer to
take them but I can too as I use them.
> dev-util/waf
> net-dns/dnssec-root
> net-libs/nacl

Description: Digital signature