Re: [gentoo-dev] [PATCH] gstreamer-meson.eclass: New eclass required for gstreamer-1.18.0+

2021-03-17 Thread Mart Raudsepp
Ühel kenal päeval, K, 17.03.2021 kell 10:29, kirjutas Haelwenn
(lanodan) Monnier:
> > My main initial question on this version is:
> > How does it behave with helper libraries from the same tarball?
> 
> It has been in my overlay for a while (haven't included all the
> splitted plugins though).
> 
> ie. 
> https://hacktivis.me/git/overlay/file/media-plugins/gst-plugins-hls/gst-plugins-hls-1.18.4.ebuild.html
> 
> > Basically what gstreamer_system_link function solved in the
> > autotools
> > eclass.
> > E.g., if you build gst-plugins-libvisual, is it building gstreamer-
> > audio, gstreamer-video and gstreamer-pbutils as well again
> > (automatically due to generated ninja dependencies), or picks them
> > up
> > from gst-plugins-base?
> 
> I think this particular one isn't solved yet. Mainly because it
> doesn't
> seems to have caused me issues yet.

I think it would be building it again, and then link it against that
new build, instead of the system version that it'll actually use at
runtime. That sounds like a recipe for hard to track issues down the
line.
But maybe if it works out fine right now, it's worth ignoring it at
first, and solving it later on.

> 
> > * Don't make nls optional
> 
> What's the reason for this? It's the case with gstreamer::gentoo.

OK, I guess we could keep it too - maybe someone needs for very
embedded builds.




Re: [gentoo-dev] [PATCH] gstreamer-meson.eclass: New eclass required for gstreamer-1.18.0+

2021-03-17 Thread Mart Raudsepp
Thanks for working on this, some very initial comments below

Ühel kenal päeval, K, 17.03.2021 kell 01:57, kirjutas Sam James:
> > +# @FUNCTION: gstreamer_multilib_src_install_all
> > +# @DESCRIPTION:
> > +# Installs documentation for requested gstreamer plugin, and
> > removes
> .la
> > +# files.
> > +gstreamer_multilib_src_install_all() {
> > +   local plugin_dir
> > +
> > +   for plugin_dir in ${GST_PLUGINS_BUILD_DIR} ; do
> > +   local dir=$(gstreamer_get_plugin_dir
> > ${plugin_dir})
> > +   [[ -e ${dir}/README ]] && dodoc "${dir}"/README
> > +   done
> > +
> > +   prune_libtool_files --modules
> 
> Deprecated in newer EAPIs, let’s do it manually.

I don't think that ought to be necessary at all, as a meson build
wouldn't be generating libtool files.


My main initial question on this version is:
How does it behave with helper libraries from the same tarball?

Basically what gstreamer_system_link function solved in the autotools
eclass.
E.g., if you build gst-plugins-libvisual, is it building gstreamer-
audio, gstreamer-video and gstreamer-pbutils as well again
(automatically due to generated ninja dependencies), or picks them up
from gst-plugins-base?

Some other quick notes:

* I would prefer this being EAPI-7 only
* Don't make nls optional
* It would be neat if we had a QA warning when a split plugin uses orc,
but doesn't have in IUSE for it (or vice-versa); maybe that's doable by
checking if the plugin meson.build uses orc_dep?


Mart




Re: [gentoo-dev] [TINDERBOX] A round with dev-lang/python-exec[-native-symlinks]

2021-01-31 Thread Mart Raudsepp
Ühel kenal päeval, T, 29.12.2020 kell 13:33, kirjutas Agostino Sarubbo:
> On martedì 29 dicembre 2020 13:03:07 CET Michał Górny wrote:
> > @ago, could you make sure that the tinderbox tells people to read
> > up
> > on the tracker?
> 
> I added the note.
> 
> However the first thing I would to do in reports like this is at
> least click 
> on the tracker bug

It seems like right now I will get a bug about this every time I make
some sort of a version bump, as that triggers it on the tinderbox.

That's because most of the packages I touch use meson and have the
post-install hook written in python with a python3 shebang, while the
ebuild usually doesn't even inherit any python eclasses, as this is all
considered handled by meson, and having to go and add python-any-r1
inherits and python_fix_shebang all over the place would be rather
awful.


Mart


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


Re: [gentoo-dev] [PATCH] vala.eclass: make has_version aware of ROOT for EAPI 7

2021-01-07 Thread Mart Raudsepp
Ühel kenal päeval, K, 06.01.2021 kell 19:27, kirjutas Matt Turner:
> From: David Michael 
> 
> The vala dependencies are declared in BDEPEND since EAPI 7 so that
> the valac command is natively executable.  With no arguments, the
> has_version function would look for a cross-compiled vala package
> in the target ROOT and always fail.

I'm not exactly convinced that vapi stuff is arch independent and
belongs in BDEPEND over DEPEND. Vala ships a lot of .vapi files along
with valac that get used on compilation. Though the difference might be
only when different endianness or size_of int


Mart

> Signed-off-by: David Michael 
> Signed-off-by: Matt Turner 
> ---
>  eclass/vala.eclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/vala.eclass b/eclass/vala.eclass
> index 52899f163dc..88c5231286a 100644
> --- a/eclass/vala.eclass
> +++ b/eclass/vala.eclass
> @@ -102,7 +102,7 @@ vala_best_api_version() {
> u=$(_vala_use_depend)
>  
> for v in $(vala_api_versions); do
> -   has_version "dev-lang/vala:${v}${u}" && echo "${v}"
> && return
> +   has_version $([[ $EAPI == [1-6] ]] || echo -b) "dev-
> lang/vala:${v}${u}" && echo "${v}" && return
> done
>  }
>  
> @@ -136,7 +136,7 @@ vala_src_prepare() {
> fi
>  
> if [[ ${version} ]]; then
> -   has_version "dev-lang/vala:${version}" || die "No
> installed vala:${version}"
> +   has_version $([[ $EAPI == [1-6] ]] || echo -b) "dev-
> lang/vala:${version}" || die "No installed vala:${version}"
> else
> version=$(vala_best_api_version)
> [[ ${version} ]] || die "No installed vala in
> $(vala_depend)"



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


Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Mart Raudsepp
Ühel kenal päeval, K, 23.12.2020 kell 07:49, kirjutas Michael Orlitzky:
>    AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"])
> 
> How do I pass the name "lua5.2" to that, without hacking configure.ac
> and running autoreconf? The only option that comes to mind is to
> build 
> the entire project with LIBS="-llua5.2", but that's not right if only
> some of the executables are supposed to be linked with lua.

You either fix upstream to use pkg-config, or you set up the cache
variable for your configure call to tell configure what the answer is,
without making it do the work wrong.
Should be ac_cv_search_whatever=something in this case. sys-apps/grep
ebuild has an example.

I'm not sure what package this is to look or test closer. It doesn't
appear to be OpenDKIM which is discussed in this thread elsewhere.

Mart



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


[gentoo-dev] Packages up for grabs from gnome@

2020-12-05 Thread Mart Raudsepp
Hello,

The GNOME team is happy to hand over the following packages to a
dedicated maintainer. For packages without any takers, we'll remain the
maintainer for the time being. For packages that are taken, feel free
to remove us or keep as backup if you want us doing the occasional
version bump based on release announcement notices or such.

app-accessibility/caribou
app-office/dia
app-office/dia2code
app-office/glabels
app-office/pinpoint
app-text/wv
dev-libs/libcroco - security vulnerabilities, dep of non-rust librsvg
gnome-extra/eiciel
gnome-extra/office-runner
media-gfx/colorhug-client
media-gfx/gtkam
media-libs/libart_lgpl
net-dialup/moserial
net-misc/grdesktop
sci-calculators/galculator
x11-misc/gcolor2
x11-themes/arc-icon-theme
x11-themes/experience
x11-themes/geramik
x11-themes/gtk-chtheme
x11-themes/gtk-engines-experience
x11-themes/gtk-engines-flat
x11-themes/gtk-engines-qtpixmap
x11-themes/gtk-engines-unico
x11-themes/vertex-icon-theme
x11-themes/vertex-theme

The following are definite last-rite candidates if no-one has any
interest in these:

dev-libs/gtx
dev-util/fix-la-relink-command

Additionally libxml2 and libxslt as a pair can be handed over; I
believe currently base-system and sam_ are considering taking them.


Mart


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


Re: [gentoo-dev] Packages up for grabs: x11-libs/gdk-pixbuf-loader-webp

2020-09-10 Thread Mart Raudsepp
Ühel kenal päeval, R, 11.09.2020 kell 00:08, kirjutas Jonas Stein:
> Dear all
> 
> the following packages are up for grabs after retirement
> of the proxied maintainer:
> 
> https://packages.gentoo.org/packages/x11-libs/gdk-pixbuf-loader-webp
> 
> The package has open bugs
> https://bugs.gentoo.org/693062
> https://bugs.gentoo.org/703864

gnome@ can take this as gdk-pixbuf maintainer and WebP being an
important image format, but I can't action the bugs and reassignment
personally before 8+ days.


Mart


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


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

2020-08-11 Thread Mart Raudsepp
Ühel kenal päeval, T, 11.08.2020 kell 07:44, kirjutas Michał Górny:
> > Examples?
> 
> I suppose nobody remembers the time (the previous year) where eudev
> broke reverse dependencies because of wrong version number, and it
> took
> around 3 months to get a fix (read: changing the version number) into
> ~arch.

Having forgotten about that (even when being directly involved in it),
it doesn't look all that bad in this example on hindsight.

Upstream issue tracker got a notification of it (being unusable for
mutter) in https://github.com/gentoo/eudev/issues/173 on 2019-05-12.
It was fixed upstream eudev on 2019-05-19, and the fix was released
into eudev-3.2.8, released on 2019-05-20.

But Gentoo virtual/libudev-232 still claimed >=eudev-1.3 is fine for
it, while mutter had to depend on >=virtual/libudev-228.
So eudev-3.2.8 already available in main tree was fine for mutter, but
there was no virtual/libudev-228, which would ensure >=eudev-3.2.8 and
that eudev version wasn't stable. So a quick fix would have been to add
a virtual/libudev-228 too in ~arch, which would have given a way to
ensure 228 by eudev-3.2.8, but this seems to have been overlooked,
thinking that a new eudev release is needed. This was compounded by no
(rather) quick replies from eudev maintainers to advise what to do with
the virtual. Eventually eudev-3.2.9 ended up being what is required, as
it provides claimed compatibility with libudev-243, which is new enough
for virtual/libudev-232.
So after initial Gentoo problem report[1] on 2019-09-11, and the
virtual/libudev bug report[2] on 2019-10-12, it all got solved by
stabilization request[3] of eudev-3.2.9 (and virtual/libudev restoring
eudev as provider) on 2019-10-28 with main arches dealing with it the
same day. ~arch was fixed on 2019-10-26, 1.5 months after initial bug
report, which per the above actually turns out actually not been an
~arch problem, but ~arch mutter mixed with stable eudev. Affected
mutter version was only stabilized in 2019-12-08.

So virtual/libudev dropping eudev as provider for this forced stable
tree to be fixed to be technically correct.
I think the main takeaway point is that on virtual/libudev version
bumps, the eudev claimed versions need to be checked as well, and the
matching >= dep for eudev figured out from the start. What each eudev
version claims as the libudev version can be seen in the UDEV_VERSION
variable set at top of configure.ac.

Personally I believe the first choice for virtual/udev should be
sys-fs/udev instead of sys-fs/eudev for our users, as it's more
maintained upstream, but don't have any personal stake in it as my udev
provider is systemd.

Various changes in udev upstream that wouldn't be in eudev (yet) would
be dealing with rule changes and bug fixes, which aren't relevant to
those people that aren't affected by these bugs, but very relevant if
you are affected by them.

I don't think it would be impossible to have musl-supporting out of the
box udev out of systemd tarball, if there was someone actually working
with upstream systemd on it in a constructive manner, effectively being
the musl support maintainer as part of upstream community.


Mart


References:
1. https://bugs.gentoo.org/694014
2. https://bugs.gentoo.org/697550
3. https://bugs.gentoo.org/698698


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


Re: [gentoo-dev] [PATCH] mate.eclass: drop static-libs whenever possible

2020-08-02 Thread Mart Raudsepp
Ühel kenal päeval, L, 01.08.2020 kell 14:32, kirjutas Adam Feldman:
> +   gnome2_src_configure ${mateconf[@]} "$@"

This might be something we may want to consider adding to gnome2.eclass
instead?
But I guess that's something to consider for any EAPI-7 port instead,
should one eventually happen (instead of everything moving to meson
instead).
So no objections adding it to mate.eclass for the time being.
gnome2.eclass would need too much checking that it's fine to bother at
this point without the EAPI bump. But remind about it, should a EAPI-7
gnome2 ever go up for review here :)


Mart


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


[gentoo-dev] Last rites: media-sound/guimup

2020-06-27 Thread Mart Raudsepp
# Mart Raudsepp  (2020-06-27)
# Disappeared upstream
and download locations. Potential replacements:
# media-sound/quimup,
xfce-extra/xfce4-mpc-plugin, media-sound/xfmpc
# Bug 729822. Removal in
30 days.
media-sound/guimup


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


Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-26 Thread Mart Raudsepp
Ühel kenal päeval, N, 25.06.2020 kell 23:47, kirjutas Aaron Bauman:
> Yes, there are successors in Gentoo.

Traditionally p.mask entries point these out.


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


Re: [gentoo-dev] Last rites: app-cdr/sync2d

2020-06-06 Thread Mart Raudsepp
Ühel kenal päeval, L, 06.06.2020 kell 03:59, kirjutas Ralph Seichter:
> * Christopher Head:
> 
> > Not that I care about this specific case, but isn’t the 30-day time
> > period also meant as a nice long warning time for people [...]
> 
> Rules and exceptions. I think that shortening the typical 30-day
> period
> is acceptable in specific cases, and sync2d is one of them. According
> to
> Git history, the ebuild for release 1.3 (released 2007) was imported
> in
> August 2015 and no functional changes have been made since then.
> There
> were only meta data updates and stabilisations, and it all ended in
> 2017.
> 
> sync2d is unmaintained in Gentoo and based on Python 2, which, as we
> know, was marked for "end of support 2015" which later was extended
> to
> January 2020. Upstream had oodles of time to migrate to Python 3 if
> they
> wanted to. If (!) any Gentoo users are still using sync2d today, they
> also had ample time to choose an alternative. From all appearances,
> sync2d has gone the way of the dodo.
> 
> Masking will not uninstall the package, and the sooner people can no
> longer install sync2d without thought, the better, as far as I am
> concerned.

Portage does not provide a good mechanism of warning users that some
package is going or already went away, other than the package.mask
entry triggering such a warning. So if it's removed quickly and p.mask
removed with that, users of said package will not be notified for a
reasonable amount of time to even notice that they have something
unmaintained installed.
Until that is working better, I find it good to have a package.mask
entry for 30 days or even longer. That does not mean the specific
package itself can't go away in 15 days - the package.mask entry could
be reworded and kept for a bit longer.


Mart


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


Re: [gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag

2020-04-19 Thread Mart Raudsepp
Ühel kenal päeval, P, 19.04.2020 kell 20:20, kirjutas Mart Raudsepp:
> > Personally I would opt for global "appindicator" as it seems to be
> > more widely
> > used and I think it is a bit more self-explanatory :/
> 
> So I assume we can

have*

> consensus here, so I'll start off with renaming it
> in nm-applet as part of other changes, and assume this ends up as a
> global USE flag eventually.

Note that ayatana already is a global USE flag, but I agree with
migrating that over to appindicator instead, just a global USE flag to
remove then later as well.


Mart


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


Re: [gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag

2020-04-19 Thread Mart Raudsepp
Ühel kenal päeval, E, 06.04.2020 kell 15:23, kirjutas Pacho Ramos:
> El jue, 02-04-2020 a las 16:28 +0200, Pacho Ramos escribió:
> > Hello,
> > 
> > I was reviewing about how to enable globally on my system the usage
> > of
> > libappindicator and I realized that we have multiple names for that
> > in the
> > tree.
> > "ayatana" is the only global one, while other packages are using
> > "indicator",
> > "libindicate", "appindicator"...
> > 
> > Personally I would merge all them in only one, and I wonder if
> > maybe
> > "indicator"
> > or "appindicator" would be more meaningful for most users than
> > "ayatana", what
> > do you think?
> > 
> > Thanks
> 
> Personally I would opt for global "appindicator" as it seems to be
> more widely
> used and I think it is a bit more self-explanatory :/

So I assume we can consensus here, so I'll start off with renaming it
in nm-applet as part of other changes, and assume this ends up as a
global USE flag eventually.


Mart


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


Re: [gentoo-dev] Packages up for grabs

2020-04-14 Thread Mart Raudsepp
Ühel kenal päeval, T, 14.04.2020 kell 11:36, kirjutas Joonas Niilola:
> gexiv2

gnome@ can take this


Mart


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


Re: [gentoo-dev] stabilization requests not making progress

2020-03-28 Thread Mart Raudsepp
Ühel kenal päeval, L, 28.03.2020 kell 17:24, kirjutas Jaco Kroon:
> Hi All,
> https://bugs.gentoo.org/705754
> Not sure if this is the only one.  This is becoming problematic. 
> This specific one is blocking a security issue.  x86 and amd64 both
> needs an updated stable.  I'd prefer 13.32.0 but it's not been in
> tree for a month yet.  But we can do 13.31.0 by now ...

You should stabilize on the security bug, not an extra one that blocks
the security bug.
Security bugs typically gets more immediate attention by arch teams,
but often not those that are blocked by a dependent non-security bug,
as it doesn't show up in the tooling then as such.


Mart


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


Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

2020-03-21 Thread Mart Raudsepp
Ühel kenal päeval, L, 21.03.2020 kell 11:16, kirjutas Pacho Ramos:
> I agree, I see that also Debian is applying it unconditionally even
> when running
> systemd

But I assume it would be a problem with USE=systemd + USE=-user-session 
dbus, so how about instead of this profile business, we then just go
with:

* Revbump bluez to drop IUSE=user-session, unconditionally apply the
patch and change the dbus dep in systemd conditional to
>=sys-apps/dbus-1.6:=[user-session(+)]
* Fix bluez USE=systemd handling in above revbump as well: --enable-
systemd should always be passed, not controlled by a USE=systemd,
because all it appears to do is decide whether to install systemd
service files, and that should be always done per the small files
policy.
* Revbump dbus, dropping user-session IUSE and unconditionally passing
--enable-user-session

* After some time (dbus revision with IUSE=user-session has been gone
for a while), remove all of the IUSE=systemd handling from bluez, as
the user-session matching enforcement isn't needed anymore (and the
configure systemd conditional has been nuked per above)
* At that point the package.use entries can be removed altogether as
well, instead of migrating to systemd target profile.


Mart


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


Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

2020-03-19 Thread Mart Raudsepp
Ühel kenal päeval, K, 18.03.2020 kell 16:43, kirjutas Mike Gilbert:
> Seems good to me in principle, but I'm not sure it is something we
> > should do until we haven't promoted this into a global USE flag.
> 
> An alternative would be to add entries in package.use.

Yeah, that'd be what it is now, just done in systemd profile, not most
of the separate systemd profiles.

> > With the disclaimer of not knowing anything about dbus[user-
> > session] on
> > a non-systemd system - maybe it's just time to make user-session
> > unconditionally enabled on dbus (and then bluez) instead?
> > All it seems to do (on a very quick look) is install some extra
> > systemd
> > files - can't they just be always installed (by always passing --
> > enable-user-session) and call it a day?
> 
> It looks like user-session has no effect if systemd is not in use.
> 
> On systems running systemd, having the units installed automatically
> enables the systemd user bus, and the only way to disable it is to
> mask the units. Having the user bus enabled generally prevents
> display
> managers and startx from starting individual session buses, since
> they
> will use the user bus instead. That's probably fine, but I wanted to
> note it.

So how about we try to just always enable this instead in dbus and
bluez? Anyone got any objections, provided the below can be handled?

I peeked at bluez, and there USE=user-session exists to apply a patch
to unbreak things when user-session is disabled. Unfortunately it seems
to be needed there for non-systemd systems as well. I think we should
be able to figure things out to work in all situations there, or make
it be applied for USE=-systemd only (that's already the case there,
just it is not applied for USE="systemd -user-session" right now).


Mart



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


[gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

2020-03-18 Thread Mart Raudsepp
> @@ -1,6 +1,6 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2020 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
> -USE="systemd udev"
> +USE="systemd udev user-session"
>  
>  BOOTSTRAP_USE="${BOOTSTRAP_USE} systemd udev"

Seems good to me in principle, but I'm not sure it is something we
should do until we haven't promoted this into a global USE flag.

With the disclaimer of not knowing anything about dbus[user-session] on
a non-systemd system - maybe it's just time to make user-session
unconditionally enabled on dbus (and then bluez) instead?
All it seems to do (on a very quick look) is install some extra systemd
files - can't they just be always installed (by always passing --
enable-user-session) and call it a day? Will bluez go wrong if it's
installed as USE=user-session does now and ran on a non-systemd system
like that?


Mart


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


[gentoo-dev] Last rites: net-libs/gupnp-ui

2020-02-21 Thread Mart Raudsepp
# Mart Raudsepp  (2020-02-21)
# Does not compile against new gupnp-1.2 API. No consumers, dead
project.
# Removal in 30 days. Bug #710436.
net-libs/gupnp-ui


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


Re: [gentoo-dev] Last-rites: net-misc/wicd

2020-02-11 Thread Mart Raudsepp
Ühel kenal päeval, E, 10.02.2020 kell 00:43, kirjutas Stefan Strogin:
> Upd.
> The port to Python 3 is not finished in the upstream.
> Particularly it is still using pygtk, it seems no work in porting to
> gtk+3 has been done yet.

Just to be clear of misunderstanding here:

A port away from py2-only pygtk does not necessarily have to mean a
port to gtk+:3 at the same time - pygobject:3 (the
`from gi.repository import ...` stuff) works just fine with
gtk+:2[introspection] as well.

Of course ideally it would be ported to gtk3 as well (and starting with
later this year to gtk4).


Mart


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


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-06 Thread Mart Raudsepp
Ühel kenal päeval, R, 06.12.2019 kell 14:06, kirjutas Thomas
Deutschmann:
> Since when is it acceptable for anyone to remove packages (the
> package.mask entry clearly says that this package is scheduled for
> removal and suspecting that any *user* will step and contact p-m for
> example is naive) without any need?

I assume the p.mask entry text wasn't optimal then.
For this specific case, sabnzbd had been in maintainer-needed for 3
months already. Unfortunately no "package up for grabs" had been sent
for this one when it was dropped to that (previous maintainer dropped
maintenance himself).

I don't see anything wrong with the idea of p.masking it in case it
could be causing problems for others (such as py2). Of course the
p.mask entry could apparently have been better, it's sad that no
"package up for grabs" happened back then months ago, and it's not nice
it was all in a big lump of maintainer-needed packages, python@
packages and packages maintained by completely unaware maintainers with
no notification period.


Mart


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


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-06 Thread Mart Raudsepp
Ühel kenal päeval, N, 05.12.2019 kell 23:23, kirjutas David Seifert:
> When we started removing Qt4, tons of code still used it. To put
> things
> in perspective:
> 
> grep -rl 'IUSE.*python_targets_python2_7' /usr/portage/metadata/md5-
> cache/ | wc -l
> 
> gives me 7070 ebuilds currently. 7070 is easily more than one and
> closer to two orders of magnitude more ebuilds using python 2 than
> Qt4
> back in the days.

You are dramatizing things too much on purpose here. That gives you a
list of almost all PYTHON_COMPAT packages, the majority of which
support python3 already, and will happily continue working after the
user drops python2_7 from PYTHON_TARGETS or it gets dropped from the
_PYTHON_ALL_IMPLS list in python-utils-r1.eclass.

> Removing maintainer-needed and other semi-dead
> packages is part of a proactive strategy in continuously removing and
> treecleaning stale stuff from the tree.

That's the problem right here. The mask included packages that are not
maintainer-needed, nor maintained by python@ or other projects you or
Aaron are active members of. And it was a careless mask, masking even
some things that aren't even affected, merely had python2 mentioned in
some commented out stuff, afaiu.

I don't think there would be such a huge outcry if this was done right
- involving the actual maintainers of these packages, not just going
ahead and package.masking them from under them 150+ days ahead of time
of actual upstream python2 last release. Presumably most of these
maintainers would already know whether the package is in the progress
of being ported upstream (and just needs probably less than 120 days to
complete that work and make a release), or know that it's dead and go
away. Or they don't respond, and you can p.mask them on a maintainer
honoring timeout.

As this was done is completely unacceptable. Honor your fellow
maintainers and don't trample over them like this. We already are in a
lack of manpower, don't chase more away by trying to take the easy
route and doing stuff like this without involving them via a tracker
bug or other proper ways.
If you don't maintain a package, you get to work with the maintainer,
not do as you please without involving them at all. I am not aware of
QA having such blanket authority either for such a case.


I don't think anyone can have a valid problem with package.mask of some
of the things mentioned (sabnzbd, abcde, etc), because they were indeed
maintainer-needed or sound@ (which David is part of, and is known
crickets territory) or whatnot. It seems to have found interested
maintainers, as is normal with last-rite type of package.masks.
But by including things that are actually maintained, without any
apparent involvement of those maintainers, you allow for such outcry
even for things that shouldn't be a problem, because you display ill
intent and dishonoring towards your fellow maintainers.

Honor your fellow Gentoo maintainers. Period.


Mart


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


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

2019-11-21 Thread Mart Raudsepp
See also this related old thread:
https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09211





[gentoo-dev] Last rites: dev-libs/btparser

2019-11-17 Thread Mart Raudsepp
# Mart Raudsepp  (2019-11-17)
# Obsolete library with
no remaining consumers.
# Only older dev-libs/libreport versions used
it.
# Removal in 30 days.  Bug #700380.
dev-libs/btparser

Old EAPI-5 package that had its only consumer (old dev-libs/libreport
version) removed.


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


Re: [gentoo-dev] Last rites: app-misc/toilet

2019-11-17 Thread Mart Raudsepp
Ühel kenal päeval, L, 16.11.2019 kell 21:07, kirjutas Aaron Bauman:
> On Sat, Nov 16, 2019 at 08:29:58PM -0500, Aaron Bauman wrote:
> > # Aaron Bauman  (2019-11-16)
> > # EAPI=4. --filter=gay Really?!
> > # Removal in 15 days
> > app-misc/toilet
> > 
> > -- 
> > Cheers,
> > Aaron
> 
> Add the following as it is an rdep
> 
> net-irc/rbot

Why are you last-riting packages that some team does maintain without
any apparent talk with them (unless I simply fail to find an ack),
purely because it happens to have a local USE flag to very much
optionally depend on that app-misc/toilet as an alternative to figlet?
So even with this gone, it would retain such optional feature
functionality via USE=figlet.

There's also no bug reference for people to give feedback or updates
on, as is customary (or even required, can't remember) for last rites.

Also would appreciate better worded last-rite reasoning..


Mart


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


[gentoo-dev] Last rites: dev-libs/qof

2019-11-17 Thread Mart Raudsepp
# Mart Raudsepp  (2019-11-17)
# Obsolete library with
no consumers.
# Removal in 30 days.  Bug #700332.
dev-libs/qof

dev-libs/qof has no consumers left, is at EAPI-5 with dead homepage and
test failures. It was used by app-office/gnotime, which was last rited
and removed in June 2012.


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


Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Mart Raudsepp
Ühel kenal päeval, R, 15.11.2019 kell 13:20, kirjutas Alexey 'Alexxy'
Shvetsov:
> В письме от пятница, 15 ноября 2019 г. 11:45:32 MSK пользователь
> Michał Górny 
> написал:
> > On Fri, 2019-11-15 at 11:41 +0300, Alexey 'Alexxy' Shvetsov wrote:
> > > I think problem is more global:
> > > * many python3_6 packages dont have python3_7 keywords, because
> > > its
> > > maintainers dont bother about it. So if you want to switch to
> > > python3_7
> > > you
> > > still need manualy add python3_7 use for  many packages (that
> > > actualy work
> > > without problems
> > > * we need policy for python packages that force enablement of new
> > > python
> > > version on existing packages.
> > 
> > Policy makes little sense if there's no way to enforce it.
> > 
> > If you tested some package on py3.7 and depgraph, just add it
> > there.
> 
> Some people dont like it =D And some arches (doesnt matter if i have
> such hw 
> and tested on it)

People mostly don't like it when you throw unrelated changes on top of
that, under the guise of just python target addition, especially when
they are also broken changes and involve a revbump without maintainers
involvement (just PYTHON_TARGETS addition doesn't). Or if it actually
doesn't work with the added python targets.


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


Re: [gentoo-dev] [PATCH 03/16] gnome2-utils.eclass: remove redundant @USAGE lines

2019-10-09 Thread Mart Raudsepp
Ühel kenal päeval, K, 09.10.2019 kell 22:12, kirjutas Gilles
Dartiguelongue:
> Looks good.

I'm waiting on a patch or patchset for EAPI-7 fixes to appear to
gentoo-dev for review, and then to merge all of that in the same push
(together with a trivial third change waiting in bugzilla). That
patchset has yet to appear here iirc, but was a topic of discussion
earlier today and I believe it should appear soon by author. Once we
are happy, I can merge them all at once.


Mart

> Le vendredi 06 septembre 2019 à 13:40 -0500, bkoh...@gentoo.org a
> écrit :
> > From: Ben Kohler 
> > 
> > Signed-off-by: Ben Kohler 
> > ---
> >  eclass/gnome2-utils.eclass | 5 -
> >  1 file changed, 5 deletions(-)
> > 
> > diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-
> > utils.eclass
> > index 06683a7467f..c9765f6fd91 100644
> > --- a/eclass/gnome2-utils.eclass
> > +++ b/eclass/gnome2-utils.eclass
> > @@ -297,7 +297,6 @@ gnome2_schemas_savelist() {
> >  }
> >  
> >  # @FUNCTION: gnome2_schemas_update
> > -# @USAGE: gnome2_schemas_update
> >  # @DESCRIPTION:
> >  # Updates GSettings schemas.
> >  # This function should be called from pkg_postinst and pkg_postrm.
> > @@ -328,7 +327,6 @@ gnome2_gdk_pixbuf_savelist() {
> >  }
> >  
> >  # @FUNCTION: gnome2_gdk_pixbuf_update
> > -# @USAGE: gnome2_gdk_pixbuf_update
> >  # @DESCRIPTION:
> >  # Updates gdk-pixbuf loader cache if
> > GNOME2_ECLASS_GDK_PIXBUF_LOADERS has some.
> >  # This function should be called from pkg_postinst and pkg_postrm.
> > @@ -360,7 +358,6 @@ gnome2_gdk_pixbuf_update() {
> >  }
> >  
> >  # @FUNCTION: gnome2_query_immodules_gtk2
> > -# @USAGE: gnome2_query_immodules_gtk2
> >  # @DESCRIPTION:
> >  # Updates gtk2 immodules/gdk-pixbuf loaders listing.
> >  gnome2_query_immodules_gtk2() {
> > @@ -374,7 +371,6 @@ gnome2_query_immodules_gtk2() {
> >  }
> >  
> >  # @FUNCTION: gnome2_query_immodules_gtk3
> > -# @USAGE: gnome2_query_immodules_gtk3
> >  # @DESCRIPTION:
> >  # Updates gtk3 immodules/gdk-pixbuf loaders listing.
> >  gnome2_query_immodules_gtk3() {
> > @@ -388,7 +384,6 @@ gnome2_query_immodules_gtk3() {
> >  }
> >  
> >  # @FUNCTION: gnome2_giomodule_cache_update
> > -# @USAGE: gnome2_giomodule_cache_update
> >  # @DESCRIPTION:
> >  # Updates glib's gio modules cache.
> >  # This function should be called from pkg_postinst and pkg_postrm.


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


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Mart Raudsepp
Ühel kenal päeval, L, 31.08.2019 kell 10:03, kirjutas Michał Górny:
> x11-drivers/xf86-video-geode

This one is a required driver for Geode LX hardware, which is 32bit.


Mart


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


Re: [gentoo-dev] [RFC] package.deprecated to mark packages deprecated and report dependencies

2019-08-17 Thread Mart Raudsepp
Ühel kenal päeval, R, 16.08.2019 kell 19:58, kirjutas Thomas
Deutschmann:
> Hi,
> 
> I like the idea. This will allow the following change in workflow:
> 
> When you now want to last-rite app-misc/foo for example, you would
> schedule a CI run. I.e. create a pull request against Gentoo
> repository
> at GitHub containing your package.mask entry. When the results will
> be
> available, you will start filling bugs against packages depending on
> the
> package you want to get rid off. Once all depending packages are
> gone,
> you will commit the mask. However, this process can take some time
> and
> in theory someone could add a new dependency on your package in the
> meanwhile...
> 
> Thanks to the new package.deprecated file we would have a check in
> real
> time against current repository. And once all CI warnings are gone
> you
> can commit the mask.

I imagined it more in terms of replacing that PR CI run to get the
initial list and start signaling that we want it to go away. However
packages shouldn't be put in there that are really still used a lot
(say, x11-libs/gtk+:2).
I don't think it should nag maintainers using repoman (or pkgcheck in
the future) by default (at least for pre-existing cases), but included
in a CI run as lower prio warning to be able to quickly search through
the list to see what the state of things is, if it's realistic to
really get rid of it by filing the bugs, etc. And it should warn for
completely new packages, if they add a dep on it. Bonus points if the
CI check can signal that a deprecated use isn't the case anymore in a
newer revision already - to signal that it's a matter of clean-up work
there.
But that's just my thoughts, and what you propose is also an
improvement. Though with that kind of approach I would instead mark it
up and push that to main tree, and then do the bugs from the refreshed
report with the low prio warnings instead though; or remove the entry
if it's still too much and unrealistic.


Mart


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


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

2019-08-11 Thread Mart Raudsepp
Ühel kenal päeval, P, 11.08.2019 kell 14:53, kirjutas 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.

Fair enough.

> Standing on your head and trying to invent an
> alternative
> is not going to help anyone, and only confuse people.

Completely uncalled for unfriendly hostile additional sentence.


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


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

2019-08-11 Thread Mart Raudsepp
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?

Mart


Ühel kenal päeval, P, 11.08.2019 kell 13:21, kirjutas Michał Górny:
> USE=magic is currently used consistently by 12 packages:
> 
> app-arch/engrampa[magic] Enable filetype auto-detection via
>   sys-apps/file
> app-editors/nano[magic] Add magic file support (sys-apps/file) to
>   automatically detect appropriate syntax highlighting
> app-misc/vifm[magic] Use libmagic to determine mimetypes
> app-misc/worker[magic] Add magic file support from sys-apps/file to
>   automatically detect file types
> app-text/zathura[magic] Use libmagic to determine mimetypes
> media-gfx/qiv[magic] Use libmagic to determine mimetypes
> media-libs/libextractor[magic] Enable magic support using sys-
> apps/file
> media-sound/moc[magic] Use libmagic to determine mimetypes
> net-misc/gerbera[magic] Use libmagic to determine file types
> net-p2p/mldonkey[magic] enable use of libmagic
> sci-geosciences/viking[magic] Use libmagic to determine mimetypes
> www-servers/pshs[magic] Enable automatic detection of Content-Type
> using
>   libmagic (sys-apps/file)
> 
> Signed-off-by: Michał Górny 
> ---
>  profiles/use.desc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/profiles/use.desc b/profiles/use.desc
> index 13baef969315..09940dd81822 100644
> --- a/profiles/use.desc
> +++ b/profiles/use.desc
> @@ -181,6 +181,7 @@ lzma - Support for LZMA (de)compression algorithm
>  lzo - Enable support for lzo compression
>  m17n-lib - Enable m17n-lib support
>  mad - Add support for mad (high-quality mp3 decoder library and cli
> frontend)
> +magic - Add support for file type detection via magic bytes (usually
> via libmagic from sys-apps/file)
>  maildir - Add support for maildir (~/.maildir) style mail spools
>  matroska - Add support for the matroska container format (extensions
> .mkv, .mka and .mks)
>  mbox - Add support for mbox (/var/spool/mail) style mail spools


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


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

2019-07-17 Thread Mart Raudsepp
Ühel kenal päeval, K, 17.07.2019 kell 18:05, kirjutas Robin H. Johnson:
> - significantly increases the version bump requirements (can't simply
>   copy & local-build & quick-test & commit)

Unrelated to the topic at hand, but I seriously hope this isn't the
standard we aim for in our version bumping. At the very least, the
build system should get checked for dependency changes (minimum deps
and otherwise)...


Mart


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


[gentoo-dev] Last rites: x11-libs/gtef

2019-05-18 Thread Mart Raudsepp
# Mart Raudsepp  (18 May 2019)
# Old name and SLOT for gui-libs/tepl, which is now used instead.
# Masked for removal in 15 days. Bug #686222
x11-libs/gtef

x11-libs/gtef is essentially an old SLOT of gui-libs/tepl, which wasn't
pkgmoved due to it being a separate SLOT with only one consumer anyhow.
Now that consumer (gnome-latex) use the new SLOT from tepl, with older
versions using gtef removed, and we can remove gtef.



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


Re: [gentoo-dev] Gentoo on Discord

2019-04-30 Thread Mart Raudsepp
Ühel kenal päeval, T, 30.04.2019 kell 18:17, kirjutas Kristian
Fiskerstrand:
> On 4/30/19 6:04 PM, Kristian Fiskerstrand wrote:
> > On 4/30/19 9:05 AM, Cynede wrote:
> > > Right, alike reddit, twitter, facebook and other PR channels.
> > > It's
> > > "official" because it's controlled by PR Gentoo team,
> > 
> > No, that does not make anything official. Official would mean a
> > place we
> > would place an announcement ourselves and mostly comes down to our
> > website and the announce mailing list.
> > 
> > Basically; What is considered an official communication channel
> > should
> > be analogous to SEC Regulation Fair Disclosure (FD).
> > 
> > Now, that Gentoo developers in some way have anything to do with
> > other
> > channels is a good thing, but its not an official communication
> > channel
> > for Gentoo.
> > 
> 
> Ok, the above was a bit too compromised. The official communication
> channels within the project of course also includes the ways the
> developers are expected to work together; i.e also bugzilla and the
> various required mailing lists.


And who, besides a wrongly informed or at least suboptimal terminology
using Gentoo unrelated website, has claimed that Discord is an official
communication channel?
I seriously doubt some of the other listed distributions over there use
Discord in any seriously official capacity either.
PR page lists it as an official social media account, whatever that
means. Probably what it is - social media under PR admin. Do you
consider facebook as official communication medium too?

> Whether IRC is official communication channel is more of an
> interesting
> discussion; as it is not a required medium for developers, but it is
> definitely close due to the amount of work that is being done over
> it.
> 
> but from a PR perspective the official communication channels are the
> website and mailing list announcements (that for us acts as press
> releases)



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


[gentoo-dev] Last rites: media-libs/gstreamer:0.10 and co old slots

2019-04-27 Thread Mart Raudsepp
# Mart Raudsepp  (27 Apr 2019)
# Old gstreamer 0.10 versions. Use gstreamer:1.0 and co instead.
# Masked for removal in 30 days. Bug #550648
media-libs/gstreamer:0.10
media-libs/gst-plugins-base:0.10
media-libs/gst-plugins-good:0.10
media-libs/gst-plugins-ugly:0.10
media-libs/gst-plugins-bad:0.10
media-libs/gst-rtsp-server:0.10
media-plugins/gst-plugins-a52dec:0.10
media-plugins/gst-plugins-alsa:0.10
media-plugins/gst-plugins-amr:0.10
media-plugins/gst-plugins-annodex:0.10
media-plugins/gst-plugins-assrender:0.10
media-plugins/gst-plugins-cdio:0.10
media-plugins/gst-plugins-cdparanoia:0.10
media-plugins/gst-plugins-dts:0.10
media-plugins/gst-plugins-dv:0.10
media-plugins/gst-plugins-dvb:0.10
media-plugins/gst-plugins-dvdread:0.10
media-plugins/gst-plugins-faac:0.10
media-plugins/gst-plugins-faad:0.10
media-plugins/gst-plugins-flac:0.10
media-plugins/gst-plugins-gconf:0.10
media-plugins/gst-plugins-gdkpixbuf:0.10
media-plugins/gst-plugins-gio:0.10
media-plugins/gst-plugins-gl
media-plugins/gst-plugins-gnomevfs:0.10
media-plugins/gst-plugins-gsm:0.10
media-plugins/gst-plugins-ivorbis:0.10
media-plugins/gst-plugins-jack:0.10
media-plugins/gst-plugins-jpeg:0.10
media-plugins/gst-plugins-ladspa:0.10
media-plugins/gst-plugins-lame:0.10
media-plugins/gst-plugins-libmms:0.10
media-plugins/gst-plugins-libnice:0.10
media-plugins/gst-plugins-libpng:0.10
media-plugins/gst-plugins-libvisual:0.10
media-plugins/gst-plugins-mad:0.10
media-plugins/gst-plugins-meta:0.10
media-plugins/gst-plugins-modplug:0.10
media-plugins/gst-plugins-mpeg2dec:0.10
media-plugins/gst-plugins-mpeg2enc:0.10
media-plugins/gst-plugins-mplex:0.10
media-plugins/gst-plugins-musepack:0.10
media-plugins/gst-plugins-neon:0.10
media-plugins/gst-plugins-ofa:0.10
media-plugins/gst-plugins-ogg:0.10
media-plugins/gst-plugins-opus:0.10
media-plugins/gst-plugins-oss:0.10
media-plugins/gst-plugins-pango:0.10
media-plugins/gst-plugins-pulse:0.10
media-plugins/gst-plugins-raw1394:0.10
media-plugins/gst-plugins-resindvd:0.10
media-plugins/gst-plugins-rtmp:0.10
media-plugins/gst-plugins-schroedinger:0.10
media-plugins/gst-plugins-shout2:0.10
media-plugins/gst-plugins-sidplay:0.10
media-plugins/gst-plugins-soundtouch:0.10
media-plugins/gst-plugins-soup:0.10
media-plugins/gst-plugins-speex:0.10
media-plugins/gst-plugins-taglib:0.10
media-plugins/gst-plugins-theora:0.10
media-plugins/gst-plugins-twolame:0.10
media-plugins/gst-plugins-v4l2:0.10
media-plugins/gst-plugins-wavpack:0.10
media-plugins/gst-plugins-vorbis:0.10
media-plugins/gst-plugins-vp8:0.10
media-plugins/gst-plugins-x:0.10
media-plugins/gst-plugins-x264:0.10
media-plugins/gst-plugins-ximagesrc:0.10
media-plugins/gst-plugins-xvid:0.10
media-plugins/gst-plugins-xvideo:0.10
dev-cpp/gstreamermm:0.10
dev-python/gst-python:0.10
media-libs/gnonlin:0.10
net-libs/farstream:0.1



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


Re: [gentoo-dev] Killing herds, again

2019-04-14 Thread Mart Raudsepp
Ühel kenal päeval, K, 03.04.2019 kell 19:35, kirjutas Michał Górny:
> My goal here is to make sure that we have clear and correct
> information
> about package maintainers.  Most notable, if a package has no active
> maintainer, we really need to have 'up for grabs' issued and package
> marked as maintainer-needed, rather than hidden behind some project
> whose members may not even be aware of the fact that they're its
> maintainers.
> 
> 
> What do you think?

I agree with most of what was written in the original post, but
regarding this point I'd hate to see packages maintained by a project
that makes sense to be thrown into a generic maintainer-needed.
We need a maintainer-needed project status, and just improve the
tooling to notify this. So similar to what Alec said, but I think it's
fine to throw them into the generic bucket when the maintaining project
was indeed just herd-like.
But I don't think we should do that for projects where it makes sense
to have the packages grouped under a project. A recent example was/is
MATE; an older example is maybe enlightenment.
We could mark projects as maintainer-needed and have a script even add
 comments in metadata.xml (and a matching
script to remove those, once the project status changes); have any
maintainer-needed list generation consider with packages marked as
maintained by such a maintainer-needed project (with some potential
grouping of them together in the list), etc.
This could then also be used to signify huge staffing-needs, even if
someone is sort-of trying to take care of them within that project.

But, as said, I agree with almost everything else mentioned in the
thread starter.


Mart


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


Re: [gentoo-dev] Packages up for grabs due to tetromino's retirement

2019-03-10 Thread Mart Raudsepp
Ühel kenal päeval, P, 10.03.2019 kell 10:52, kirjutas Michał Górny:
> The following packages have no listed maintainer anymore:
> 
> dev-python/nautilus-python

gnome@ will take this

> dev-lang/sassc
> dev-libs/libsass

We need these now in GNOME, but it would be good if it had a dedicated
maintainer. I believe Plasma needs them too?


Mart


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


[gentoo-dev] [PATCH] meson.eclass: add meson_feature function

2019-03-04 Thread Mart Raudsepp
This can be used to simplify controlling meson_options.txt entries
of type 'feature'.

Signed-off-by: Mart Raudsepp 
---
 eclass/meson.eclass | 13 +
 1 file changed, 13 insertions(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 75291d7bdd1..65b09932a7a 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -188,6 +188,19 @@ meson_use() {
usex "$1" "-D${2-$1}=true" "-D${2-$1}=false"
 }
 
+# @FUNCTION: meson_feature
+# @USAGE:  [option name]
+# @DESCRIPTION:
+# Given a USE flag and meson project option, outputs a string like:
+#
+#   -Doption=enabled
+#   -Doption=disabled
+#
+# If the project option is unspecified, it defaults to the USE flag.
+meson_feature() {
+   usex "$1" "-D${2-$1}=enabled" "-D${2-$1}=disabled"
+}
+
 # @FUNCTION: meson_src_configure
 # @USAGE: [extra meson arguments]
 # @DESCRIPTION:




Re: [gentoo-dev] util-linux build time increase?

2019-03-01 Thread Mart Raudsepp
Ühel kenal päeval, N, 28.02.2019 kell 04:13, kirjutas Joshua Kinard:
> On 2/25/2019 05:18, Alexander Tsoy wrote:
> > В Пн, 25/02/2019 в 13:07 +0300, Alexander Tsoy пишет:
> > > В Чт, 21/02/2019 в 04:36 -0500, Joshua Kinard пишет:
> > > > Does anyone have an idea why util-linux's build time would go
> > > > up
> > > > significantly from 2.32.x to 2.33.x?  It may be a MIPS thing,
> > > > as my
> > > > x86_64
> > > > box shows no discernible change in build times between the same
> > > > versions.
> > > > Can any other archs check w/ genlop to see if they see a large
> > > > jump
> > > > in build
> > > > time?
> > > > 
> > > > 'genlop -t util-linux' output on my SGI system (some entries
> > > > removed
> > > > for
> > > > brevity):
> > > > 
> > > >  Thu Feb  1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1
> > > >merge time: 27 minutes and 48 seconds.
> > > > 
> > > >  Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32
> > > >merge time: 28 minutes and 44 seconds.
> > > > 
> > > >  Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1
> > > >merge time: 32 minutes and 58 seconds.
> > > > 
> > > >  Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33
> > > >merge time: 1 hour, 19 minutes and 49 seconds.
> > > > 
> > > >  Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1
> > > >merge time: 1 hour, 23 minutes and 37 seconds.
> > > > 
> > > >  Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1
> > > >merge time: 1 hour, 25 minutes and 15 seconds.
> > > > 
> > > 
> > > 2.33 was changed to use python-r1 eclass instead of python-
> > > single-r1
> > > eclass. And the increase of build time seems caused by an out-of-
> > > source 
> > > build for each python implementation. Some libraries are built
> > > several
> > > times (for native abi + for each python implementation).
> > 
> > And there is additional configure run for each python
> > implementation.
> 
> Hmm, this might explain things, somewhat.  I think there's possibly
> some
> truth to the getcwd bit discussed earlier, but that may be limited to
> glibc
> only.

Right, util-linux doesn't conduct that test. coreutils and tar do,
maybe some more.
That doesn't mean running with sandbox doesn't have a slowdown effect -
it most certainly does, just hopefully not so drastic as that
particular case - it involves glibc own generic getcwd being slow with
long paths, and sandbox calling it three times for its access checks
even for mkdir call, just to error with ENAMETOOLONG, in addition to
many getcwd calls the configure check itself does. So it's slow even
without sandbox, but with sandbox that slowness is doubled or more.
That has made me wonder if maybe by having some more ENAMETOOLONGs
earlier, the test would finish earlier, instead of slowly spinning
through paths that are in length between PATH_MAX and PATH_MAX*2, when
it's slow..
But not sure why these m4 macros seems to be calling getcwd after each
mkdir+chdirm etc just to get a boolean configure check result. Didn't
look into the specific case, I only debugged the test case that just
loops mkdir+chdir.
Someone should maybe convert these project to meson and do that check
smarter :D

> util-linux-2.33.1 on my uclibc-ng chroot took about ~25mins.  Have to
> re-time the glibc build to see if it's something w/ the libc
> implementation.
> 
> Temp workaround I guess is to cut down on the PYTHON_TARGETS before
> my next
> catalyst attempt.  2.7 + 3.7 should be enough...

Personally I seem to get by with just USE=-python on util-linux (it's
actually not globally enabled on my systems, it seems). Otherwise,
sure, if the slowness is in configure.


Mart


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


Re: [gentoo-dev] wayland category

2019-02-22 Thread Mart Raudsepp
Ühel kenal päeval, R, 22.02.2019 kell 13:55, kirjutas Matthew Thode:
> On 19-02-16 18:12:26, Aaron Bauman wrote:
> > On Sat, Feb 16, 2019 at 06:04:54PM -0500, Aaron Bauman wrote:
> > > On Sun, Feb 17, 2019 at 12:56:52AM +0200, Mart Raudsepp wrote:
> > > > Wildcards aren't allowed in category names. Do you mean gui-
> > > > misc, gui-
> > > > apps, gui-wm, gui-libs, or what?
> > > > 
> > > > 
> > > > Mart
> > > 
> > > Correct, examples would be:
> > > 
> > > gui-libs/wlroots
> > > gui-wm/sway
> > > gui-apps/swaylock
> > > gui-apps/sway
> > > 
> > 
> > The last example should read gui-apps/swayidle
> > 
> 
> These all seem good to me, I'll commit it sometime over the weekend
> if
> no one objects (and pkg move it in updates/1Q-2019)

I believe Aaron mentioned one of these isn't really an "app"; I think
swayidle and/or swaylock.

Otherwise thumbs up for adding gui-libs, gui-wm and gui-apps
categories. I'm not sure if we can find a better place than a gui-misc/ 
for these non-apps (gui-plugins or something?)


Mart


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


Re: [gentoo-dev] wayland category

2019-02-16 Thread Mart Raudsepp
Ühel kenal päeval, L, 16.02.2019 kell 17:40, kirjutas Aaron Bauman:
> On Sat, Feb 09, 2019 at 01:29:40PM -0800, Matt Turner wrote:
> > On Sat, Feb 9, 2019 at 2:26 AM Mart Raudsepp 
> > wrote:
> > > 
> > > Ühel kenal päeval, R, 08.02.2019 kell 16:44, kirjutas Matthew
> > > Thode:
> > > > wayland, weston, sway{,lock,idle}, wl-clipboard, etc would be
> > > > the
> > > > start,
> > > > I'm sure there are a ton I'm missing but I don't know where to
> > > > put
> > > > things like wl-clipboard, dev-libs doesn't seem right.
> > > 
> > > 
> > > Another problem are many of the toolkits and GUI libraries; many
> > > either
> > > support wayland and X11 and more, or are really agnostic to it
> > > (but
> > > deal with GUI stuff on top of GTK or other stuff), but
> > > historically we
> > > have them in x11-libs/. As-is, they'd be better off in dev-libs/, 
> > > but
> > > really a new gui-libs/ seems better to me.
> > > Maybe the pure-wayland stuff could be in some sort of gui-*
> > > category
> > > too.
> > 
> > Agreed. gui-*/ seems like the best plan.
> > 
> 
> prometheanfire has suggested gui-*/ as well.  If there are no other
> comments we will proceed with the creation of this.

Wildcards aren't allowed in category names. Do you mean gui-misc, gui-
apps, gui-wm, gui-libs, or what?


Mart

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


[gentoo-dev] Last rites: gnome-extra/nautilus-tracker-tags

2019-02-12 Thread Mart Raudsepp
# Mart Raudsepp  (12 Feb 2019)
# Was not well
maintained upstream, dropped with tracker-2
# Removal in 30 days. Bug
677798
gnome-extra/nautilus-tracker-tags

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


Re: [gentoo-dev] wayland category

2019-02-09 Thread Mart Raudsepp
Ühel kenal päeval, R, 08.02.2019 kell 16:44, kirjutas Matthew Thode:
> wayland, weston, sway{,lock,idle}, wl-clipboard, etc would be the
> start,
> I'm sure there are a ton I'm missing but I don't know where to put
> things like wl-clipboard, dev-libs doesn't seem right.


Another problem are many of the toolkits and GUI libraries; many either
support wayland and X11 and more, or are really agnostic to it (but
deal with GUI stuff on top of GTK or other stuff), but historically we
have them in x11-libs/. As-is, they'd be better off in dev-libs/, but
really a new gui-libs/ seems better to me.
Maybe the pure-wayland stuff could be in some sort of gui-* category
too.

Mart

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


Re: [gentoo-dev] [RFC] Replacing binary-only SLOTs with separate packages

2019-01-19 Thread Mart Raudsepp
Ühel kenal päeval, R, 18.01.2019 kell 21:13, kirjutas Michał Górny:
> Hello,
> 
> Since I've been working on the early gx86-multilib, we've been using
> 'binary-only SLOTs' to support providing old versions of libraries
> for
> prebuilt software.  I think this was a bad idea, and I'd like to
> suggest
> replacing it with something cleaner, for the reasons outlined below.
> 
> 
> Current state
> =
> 
> Let's take dev-libs/openssl as an example.  This package has three
> SLOTs
> right now:
> 
>   0.9.8: 0.9.8z_p8-r1
>   1.0.0: 1.0.2q-r200
>   0: 1.0.2q 1.1.0j 1.1.1a 1.1.1a-r1
> 
> The real package is provided as slot :0, that includes all libraries,
> headers and executables.  Slots 0.9.8 and 1.0.0 only install .so.N*
> libraries that can be used to satisfy dependencies of prebuilt
> packages.
> 
> 
> Problems with the current state
> ===
> 
> Firstly, it is confusing to developers.  Let's analyze the
> dependencies
> on dev-libs/openssl.  A quick grep reveals seven patterns.  They are
> listed below, along with occurrence counts and percentages:
> 
>   dev-libs/openssl  2787.8%  }
>   dev-libs/openssl:* 491.4%  } 14.2%
>   dev-libs/openssl:=1785.0%  }
>   dev-libs/openssl:0660   18.6%
>   dev-libs/openssl:0=  2381   67.0%
>   dev-libs/openssl:0/040.1%
>   dev-libs/openssl:0/1.1  20.1%
> 
> (note that those are rough measures, not guaranteed to be precise)
> 
> So apparently 14.2% of dependencies allow any slot of OpenSSL which
> is
> most likely wrong, and 1.4% explicitly claim that's what the package
> wants.  This could be valid only if e.g. the package supported
> multiple
> ABIs of OpenSSL libraries and used dlopen() with a few possible
> SONAMEs
> which I honestly doubt any of those packages is doing.
> 
> In other words, 14.2% of dependencies on OpenSSL are plain wrong,
> and 6.4% are wrong in a way that isn't going to be reported by
> repoman. 
> 1.4% of cases are using ':*' which probably indicates the developer
> decided to silence repoman without understanding how slot operators
> work
> which is a horrible thing from QA perspective.
> 
> We also have a few cases that require specific OpenSSL subslot (e.g.
> forcing old version into :0 slot) but *none* actually using the
> binary
> compatibility slots.
> 
> 
> Secondly, it is confusing to users.  If we remove old versions and
> only
> keep binary compatibility slots, users can be easily tricked into
> installing them and being surprised it's not a complete package.  If
> we
> keep old versions, we end up having different revisions of the same
> version in different slots which is also easily confused.
> 
> 
> Thirdly, it is cumbersome to introduce.  If we are to introduce a
> binary
> compatibility slot for a package that didn't have it, we need to
> update
> all reverse dependencies.  This usually means researching whether we
> should use ':0' or ':0=', and if we get this wrong, we just silence
> repoman warning about missing slot-op.
> 
> 
> All of this considered, I can't think of a single real benefit of
> using
> slots for this purpose.  They work but there's nothing really special
> about them.
> 
> 
> Suggested replacement
> =
> 
> My suggestion is to move binary compatibility slots into separate
> packages.  For example, dev-libs/openssl would be split into:
> 
>   dev-libs/openssl  -- containing the actual package
> 
>   dev-libs/openssl-bin-compat  -- containing binary compatibility
> slots
> 
> In this case, all dependencies on dev-libs/openssl would become
> correct
> (or semi-correct, wrt missing := dep) again.  Since packages are co-
> installable the same way slots are, there is no loss there.  Since
> nothing depends on binary compatibility slots, we do not even need to
> update anything (but if we had, the update cost would be minimal both
> to
> developers and to users).
> 
> 
> What do you think?

I can only find bikeshed painting for the naming of the legacy
packages, so I guess sounds good. Though that historical digging about
why we moved away from it may be useful, if just to find that it was
just a "SLOTs are cool, lets use them" case, to strengthen the argument
to move back to separate package again.


Mart

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


Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

2018-12-16 Thread Mart Raudsepp
Ühel kenal päeval, P, 16.12.2018 kell 14:45, kirjutas Matt Turner:
> > > It still requires xorg-server-1.19 which I'd like to drop due to
> > > a
> > > security vulnerability. After the listed versions are gone, -304
> > > will
> > > be the only thing keeping 1.19 in tree.
> 
> It's bug https://bugs.gentoo.org/669588

That bug should have remained open until cleanup is concluded, afaik.
Could also change whiteboard to s/stable/cleanup/  (I was about to
reopen and do that, but bugzilla suddenly had me logged out and don't
have pw handy).

While already replying here, this last rites should have been posted to
gentoo-dev-announce@ as well.

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


Re: [gentoo-dev] Unmasking >=media-video/ffmpeg-4.0

2018-11-06 Thread Mart Raudsepp
Ühel kenal päeval, T, 06.11.2018 kell 12:00, kirjutas Alexis Ballier:
> On Mon, 05 Nov 2018 20:38:58 -0500
> Craig Andrews  wrote:
> 
> > I think it's time to remove the mask on >=media-video/ffmpeg-4.0
> > 
> > ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD.
> > Upstreams are starting to require it, too. For example, Kodi 18
> > and 
> > media-plugins/gst-plugins-libav-16 will require it.
> > 
> > The blocker issue https://bugs.gentoo.org/653678 has only 5
> > blockers 
> > against it right now:
> > * 654628 has a pull request out to fix it: 
> > https://github.com/gentoo/gentoo/pull/10341
> > * 655170 is for a package that (IMHO) should be last-rited: 
> > media-libs/mediastreamer
> > * 666166 is for a package that (IMHO) should be last-rited: 
> > media-plugins/vdr-image
> > * 655442 and 658128 are for media-video/mplayer and fixed
> > upstream, 
> > requiring a new snapshot release
> > 
> > What do we say? Can we set a date when the hard mask will be
> > removed?
> 
> 
> I think 6 months qualifies for ETIMEOUT, so go ahead and unmask it :)
> 
> merge the github PR; I'll take care of mplayer

I'm sorry, but what?
PR was filed yesterday, what 6 months are you talking about here?
Please respect your fellow developers. We have other commitments and
priorities and can't zero-day review a PR.

It is not GStreamer fault that ffmpeg breaks API and ABI without
parallel installability, much less so the distro maintainers of it.
If you/upstream don't make it parallel installable, then this is what
you get.


Mart

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


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

2018-11-02 Thread Mart Raudsepp
# Mart Raudsepp  (02 Nov 2018)
# Old x11-libs/goocanvas:0 SLOT python bindings, not used by anything.
# New x11-libs/goocanvas:2.0 with introspection should be used instead.
# Removal in a month. Bug #670142
dev-python/pygoocanvas


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


[gentoo-dev] Last rites: net-analyzer/mate-netspeed

2018-10-06 Thread Mart Raudsepp
# Mart Raudsepp  (06 Oct 2018)
# Netspeed applet moved
into mate-base/mate-applets since v1.14,
# use that instead. Bug #667910
net-analyzer/mate-netspeed


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


Re: [gentoo-dev] Re: What means bup?

2018-09-24 Thread Mart Raudsepp
Ühel kenal päeval, P, 23.09.2018 kell 21:39, kirjutas Alec Warner:
> I don't see a problem with 'version bump' as a description. Sometimes
> you bump an ebuild because upstream released a new version and you
> want to track. I'm fairly against changes describing what was changed
> (typically the reader can git show and observe the changes.) The
> useful information is *why* the change was made. Sometimes its
> because "upstream released a new version."
> 
> Like Matt I'm curious what others expect to see in the description.

I expect to see the version number being bumped to. At least something
like
"cat/pkg: bump to 1.2.3"
This help tremendously for git shortlog, and just "bump" is something
you do all the time, so not a good summary. But bump to a specific
version is a good summary, as it says it exactly enough and in summary.

However Matthew does that already, in the form of
"cat/pkg: 1.2.3 bump".

I don't agree with "bup", but it indeed mostly has been "bump" now, and
my only problem there is that I'm not used to that order (vs "bump to
1.2.3").


Mart

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


Re: [gentoo-dev] Changing policy about -Werror

2018-09-10 Thread Mart Raudsepp
Ühel kenal päeval, E, 10.09.2018 kell 22:56, kirjutas Kristian
Fiskerstrand:
> On 9/10/18 10:51 PM, Matt Turner wrote:
> > Consider again the bug that started this. The maintainer had not
> > built
> > this configuration. None of the arch teams had built this
> > configuration until I did for the last architecture Cc'd. The patch
> > committed doesn't change anything installed on the system, if not
> > for
> > Werror preventing the code from building.
> 
> one way to look at it though, is that it is a valuable upstream
> contribution that this configuration produces the error, so Gentoo is
> contributing to upstream development because of it.

And losing users and thus relevance in the process. Not everyone goes
to bugzilla always and then waits for a fix, or fixes it themselves.
Normal people wipe that stuff away and install an operating
system/distribution that doesn't cause them grief in its place.

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


Re: [gentoo-dev] [RFC] New global USE flag: gtk-doc

2018-08-30 Thread Mart Raudsepp
Ühel kenal päeval, R, 24.08.2018 kell 23:06, kirjutas Mart Raudsepp:
> Longer version idea:
> Build and install gtk-doc based developer documentation for dev-
> util/devhelp, IDE and offline use

This has been pushed now with initial consumers (fresh meson based
packages or converts from autotools).

I have a candidate list of packages that could use a IUSE flag usage
change accordingly. It's a short list because I didn't consider
autotools packages, as for them it often means to rebuild it for
questionable benefits, thus I don't actually want those cases to add
unnecessary rebuild time cost with a global USE=gtk-doc - they are
already there without current USE=doc and accessible in devhelp and
some IDEs. This means autotools builds that don't use a properly disted
tarball won't get a bug filed from me right now (but why are they using
a bad tarball?).
I'll try to get those from my candidate list checked through and
converted to bug reports soon for applicable ones. If more than lets
say 3, then probably a tracker bug too.


Mart

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


Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

2018-08-26 Thread Mart Raudsepp
Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
> One thing where this would fail would be e.g.:
> 
>   LICENSE="GPL-2+
> bar? ( GPL-2 )
> foo? ( GPL-3+ )" ^ you can't put a comment on the right line

LICENSE="GPL-2+ "
LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
LICENSE+="foo? ( GPL-3+ )"


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


Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

2018-08-26 Thread Mart Raudsepp
Ühel kenal päeval, P, 26.08.2018 kell 12:39, kirjutas Michał Górny:
> Hi,
> 
> It seems that we suffer a major problem of developers wrongly
> attributing *GPL-[23] licenses to ebuilds, when the correct variant
> is
> *GPL-[23]+.  In proxy-maint, every second new package with
> LICENSE=GPL-
> [23] is plain wrong.  I suspect part of the problem is that GitHub
> has
> poor man's license recognition that does not distinguish between 'vN
> only' and 'vN or newer' license variants, and similarly that a number
> of
> contributors don't bother checking the license beyond COPYING/README.
> 
> Another part of the problem is that we don't have a really good way
> of
> distinguishing verified correct uses of *GPL-[23].  So in the end, I
> end
> up verifying the same packages over and over again unless I remember
> that I've verified them.
> 
> Therefore, I would like to suggest the following:
> 
> 1. introducing additional *-only licenses that explicitly indicate
> that
> a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
> 
> 2. annotating the unsuffixed licenses with a warning that they may
> mean
> either x-only or x+ due to frequent mistake.
> 
> 3. make repoman warn whenever non-specific variant is used, telling
> developers to verify whether it's x-only or x+.
> 
> 4. start migrating packages to x-only or x+ appropriately.
> 
> 5. eventually, remove the non-specific licenses and make repoman
> error
> out with clear explanation.
> 
> What do you think?

The common issue here is that upstream COPYING files really do only
talk about one of the versions. And then you get to validate or source
files to be sure that they do have a "or later" clause in them. And
then on each bump you ideally should validate it again, etc, that no
sources without "or later" allowance are in there...
In many cases you can trust upstreams that do make it explicit
somewhere though (toplevel meson.build, README.md, CONTRIBUTING.md,
etc).
Otherwise good idea, but I'm not sure how we are supposed to keep up
with monitoring non-"or later" sources creeping in in new upstream
versions.

There are plenty of wrong LICENSE tags in this regard under my co-
maintenance too, and it's a pain to validate all the source files, and
it's just a best effort of "hopefully my grep magic covered it and they
haven't used a non-standard file copyright header".


Mart

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


Re: [gentoo-dev] [RFC] New global USE flag: gtk-doc

2018-08-26 Thread Mart Raudsepp
Ühel kenal päeval, P, 26.08.2018 kell 01:08, kirjutas David Haller:
> Hello,
> 
> On Fri, 24 Aug 2018, Mart Raudsepp wrote:
> [..]
> > Suggested description for global gtk-doc USE:
> > Build and install gtk-doc based developer documentation
> 
> Mentioning gtk-doc, what about:
> https://bugs.gentoo.org/646850
> 
> Ready-made patch since 2018-02-07, and then what?

This is not relevant to this thread. I was not able to track all
bugzilla things at that time, and this looks to be a problem with local
usage of gtk-doc, not for out of the box packages without EXTRA_ECONF
(I'm not aware of packages using gtkdoc-mkpdf for PDFs - they are all
doing just HTML, as the default configure argument for PDF docs is to
disable them). I suspect this particular case just could use a gtk-doc
package bump for upstream, but that involves an upstream rewrite
towards python iirc, and I haven't exactly rushed with bumping that,
because the old version works and there are more important bumps to
work on (nothing has required the newer gtk-doc).

I'm sorry that some bugs fall through the cracks, but I don't mind
pings on bugs (especially those that have concrete fixes waiting), or
pings on IRC or private mail about them. Not this particular thread
though.
There are many other bugs to catch up on, but currently my focus has
been to bring GNOME 3.26 and 3.28 to our users finally. This thread is
a side-product of that.


Mart

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


Re: [gentoo-dev] [RFC] New global USE flag: gtk-doc

2018-08-26 Thread Mart Raudsepp
Ühel kenal päeval, P, 26.08.2018 kell 05:19, kirjutas Andrew Savchenko:
> On Fri, 24 Aug 2018 23:06:46 +0300 Mart Raudsepp wrote:
> > USE=doc has a very overloaded meaning.
> > Meson doesn't ship pre-generated gtk-docs like autotools did, thus
> > developers writing GLib/GTK+ apps may want to keep them around, as
> > libraries move from autotools to meson. gtk-doc is integrated into
> > various IDEs and standalone devhelp viewer, giving a concrete case
> > when
> > one might want to globally enable this (if using those IDEs until
> > they
> > don't have online gtk-doc support that's still in the works,
> > offline
> > developer docs, or matching system versions docs on purpose).
> > Per-package USE=doc is rather inconvenient to manage.
> > 
> > Suggested description for global gtk-doc USE:
> > Build and install gtk-doc based developer documentation
> > 
> > Longer version idea:
> > Build and install gtk-doc based developer documentation for dev-
> > util/devhelp, IDE and offline use
> > 
> > 
> > As the "Build" in the description suggests, this is only for when a
> > generation is needed. In practice this means that it shouldn't be
> > used
> > for autotools based builds from tarballs, where the gtk-doc is
> > already
> > shipped - for those you just want a dev-util/gtk-doc-am build dep,
> > which will make gtkdoc-rebase available that the standard gtk-doc
> > autotools rules call to make the pre-generated docs pretty much
> > equal
> > to what you'd get from regenerating (mainly local offline links).
> > In
> > those aforementioned autotools cases, it's often questionable to
> > have a
> > USE flag (doc) at all for this when using proper tarballs.
> > 
> > Most GNOME libraries have converted to using meson, thus building
> > them
> > is necessary to keep local developer docs available and thus keep
> > IDE
> > integration useful. Just always building gtk-doc would be
> > distasteful
> > to some, hence this global USE flag proposal. There will be dozens
> > of
> > consumers as I bump libraries for GNOME 3.26 and even more so 3.28
> > and
> > 3.30 soon enough afterwards. Some are already there (including some
> > not
> > from GNOME), which currently use USE=doc for this.
> > Instead of supporting disted tarballs with meson, they plan to do
> > aforementioned online docs support for the API docs integrations,
> > but
> > I haven't heard about any progress on that, plus offline use use
> > case
> > will remain anyways.
> 
> Looks like we have a larger issue here. USE=doc covers all types of
> documentation outside of man, info pages and maybe some small text
> files. Such additional documentation often includes API reference
> manual and people may want to have it if they are using it during
> development or may want to disable it, but keep user-level
> documentation, because API docs often take quite some time to
> build. Such cases cover html docs, doxygen docs, gtk-doc and so on.
> 
> So what about some new flag for API reference and other huge
> development documentation? E.g. USE="apidoc"?

According to global description examples (API, Javadoc, etc), that's
already sort of the case, but is used more broadly. So sure, it can be
an option to more clearly and easily differentiate programmer docs from
other docs, but that doesn't cover the use case I'm after.
These other USE="apidoc" won't be usable by gtk-doc and still the
inability to easily enable only gtk-docs - which will be usable in my
IDE, unlike the rest.

Basically I'm after a concrete purpose flag here, like e.g.
USE=handbook is, so it's not that there isn't already prior art of
differing from USE=doc and having a separate flag.


Mart

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


[gentoo-dev] [RFC] New global USE flag: gtk-doc

2018-08-24 Thread Mart Raudsepp
USE=doc has a very overloaded meaning.
Meson doesn't ship pre-generated gtk-docs like autotools did, thus
developers writing GLib/GTK+ apps may want to keep them around, as
libraries move from autotools to meson. gtk-doc is integrated into
various IDEs and standalone devhelp viewer, giving a concrete case when
one might want to globally enable this (if using those IDEs until they
don't have online gtk-doc support that's still in the works, offline
developer docs, or matching system versions docs on purpose).
Per-package USE=doc is rather inconvenient to manage.

Suggested description for global gtk-doc USE:
Build and install gtk-doc based developer documentation

Longer version idea:
Build and install gtk-doc based developer documentation for dev-
util/devhelp, IDE and offline use


As the "Build" in the description suggests, this is only for when a
generation is needed. In practice this means that it shouldn't be used
for autotools based builds from tarballs, where the gtk-doc is already
shipped - for those you just want a dev-util/gtk-doc-am build dep,
which will make gtkdoc-rebase available that the standard gtk-doc
autotools rules call to make the pre-generated docs pretty much equal
to what you'd get from regenerating (mainly local offline links). In
those aforementioned autotools cases, it's often questionable to have a
USE flag (doc) at all for this when using proper tarballs.

Most GNOME libraries have converted to using meson, thus building them
is necessary to keep local developer docs available and thus keep IDE
integration useful. Just always building gtk-doc would be distasteful
to some, hence this global USE flag proposal. There will be dozens of
consumers as I bump libraries for GNOME 3.26 and even more so 3.28 and
3.30 soon enough afterwards. Some are already there (including some not
from GNOME), which currently use USE=doc for this.
Instead of supporting disted tarballs with meson, they plan to do
aforementioned online docs support for the API docs integrations, but
I haven't heard about any progress on that, plus offline use use case
will remain anyways.


Mart

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


Re: [gentoo-dev] [PATCH] eclass: db-use - Update to eapi7-ver

2018-08-24 Thread Mart Raudsepp
Ühel kenal päeval, R, 24.08.2018 kell 13:28, kirjutas Brian Evans:
> This is a very simple eclass which only calls these functions from
> eclasses:
> ver_cut (EAPI 0-6)
> get_libdir (EAPI 0-5)
> get_libname (ALL EAPI)
> 
> I see no little reason to place die statements for unknown EAPIs.
> Just changing the eclasses to better suit the latest EAPI should be
> OK.

I'm unsure about not dying on unknown EAPI, but the rest looks good, as
at least in main tree everything inheriting db-use and using
versionator functions themselves, do properly inherit from versionator
themselves, instead of relying on it via db-use.eclass indirectly.

Not dying on unknown EAPI is not a change in status quo, so I don't
mind it here and for future EAPI-8 I hope we look through the non-
limited eclasses before its introduction.

Mart

> Signed-off-by: Brian Evans 
> ---
>  eclass/db-use.eclass | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
> index 35f11df034a..83ae94799ca 100644
> --- a/eclass/db-use.eclass
> +++ b/eclass/db-use.eclass
> @@ -1,10 +1,14 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2018 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  # This is a common location for functions that aid the use of sys-
> libs/db
>  #
>  # Bugs: maintainer-nee...@gentoo.org
>  
> -inherit versionator multilib
> +# multilib is used for get_libname in all EAPI
> +case "${EAPI:-0}" in
> + 0|1|2|3|4|5|6) inherit eapi7-ver multilib ;;
> + *) inherit multilib ;;
> +esac
>  
>  #Convert a version to a db slot
>  db_ver_to_slot() {
> @@ -38,7 +42,7 @@ db_findver() {
>   fi
>  
>   PKG="$(best_version $1)"
> - VER="$(get_version_component_range 1-2 "${PKG/*db-/}")"
> + VER="$(ver_cut 1-2 "${PKG/*db-/}")"
>   if [ -d "${EPREFIX}"/usr/include/db$(db_ver_to_slot "$VER")
> ]; then
>   #einfo "Found db version ${VER}" >&2
>   echo -n "$VER"

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


Re: [gentoo-dev] Gentoo i486 support

2018-08-22 Thread Mart Raudsepp
Ühel kenal päeval, K, 22.08.2018 kell 09:08, kirjutas Rich Freeman:
> On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler 
> wrote:
> > 
> > 1) Adjust x86 profile defaults to drop the problematic -march=i686.
> > This would be more in line with amd64 profiles (et al), which set
> > no
> > -march value so it can run on any hardware for this arch.
> > 
> 
> My knee-jerk reaction was that this is a bad idea, but after a bit of
> thought there are some arguments in favor of this:
> 
> First, the argument against: i386 is VERY old.

The topic is i486, not i386.
i486 stages allows to more easily start up gentoo on i486 and i586
hardware, possibly also for some i686.
E.g. if I'd ever get around to working on Geode graphics again, I would
want a i486 or i586 stage to start with, as CMOV on the Geode is a
performance penalty, not benefit, plus glibc i486 or i586 glibc
intrinsics were faster than i686 ones as well. This includes a million
or so OLPC XO-1's out there, not that they'd ever install Gentoo
though, but just an example. I think some old VIAs are another?
i686 builds sometimes wrongly make use of NOPL instruction as well,
though hopefully that was fixed for good in binutils.

Anyways, my point is that we are talking about being able to boot i486
and i586 here, not i386.
Personally I can manage my potential own future needs without weekly
stages.


Mart

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


Re: [gentoo-dev] autotools.eclass and EAPI 7

2018-08-17 Thread Mart Raudsepp
Ühel kenal päeval, R, 17.08.2018 kell 15:15, kirjutas Alexis Ballier:
> On Thu, 16 Aug 2018 21:36:56 +0300
> Mart Raudsepp  wrote:
> 
> > Ühel kenal päeval, N, 16.08.2018 kell 14:27, kirjutas Brian Evans:
> > > There are currently a handful of ebuilds using EAPI 7 and the
> > > autotools
> > > eclass.
> > > 
> > > I believe that this eclass should be reviewed for adding BDEPEND
> > > or
> > > having BDEPEND replace the DEPEND statement as the default action
> > > of
> > > the
> > > eclass.
> > > 
> > > Other items might be needed, but that's doubtful.
> > > 
> > > Someone please advise the best course of action and either do it
> > > or
> > > I will propose a patch based on the discussion.
> > >   
> > 
> > Could or did someone also check through all the other eclasses that
> > don't have any global EAPI compatibility checks?
> > For the future, maybe it's better to add such a check - just
> > accepting
> > 0-7 or so, but unsure about all these custom EAPIs out there, might
> > force more eclass copying to some overlays.
> 
> I don't really like that kind of checks: untested after usually small
> changes != broken.
> 
> IMHO a better solution could be to have council members review all
> eclasses prior to approving an eapi and either adding a comment why +
> a
> die when used with the not-yet-approved-eapi if the eclass requires
> changes or do nothing about it if it's fine. This has the double
> advantage to give council members first hands experience with an eapi
> before approving/voting it and ensures better migration when eapi is
> approved.

I think that's a good idea, in some form, but that ship has sailed with
EAPI-7 now and the request remains. I'll try to remember this for a
future EAPI-8 in the future.
I'd be glad to review things now, if I had time, but frankly I have
much more important things on my plate right now (like getting other
things to the point I can review and merge EAPI-7 support to some of
the eclasses I maintain and unblock progress for more usage of it).


Mart

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


Re: [gentoo-dev] autotools.eclass and EAPI 7

2018-08-16 Thread Mart Raudsepp
Ühel kenal päeval, N, 16.08.2018 kell 14:27, kirjutas Brian Evans:
> There are currently a handful of ebuilds using EAPI 7 and the
> autotools
> eclass.
> 
> I believe that this eclass should be reviewed for adding BDEPEND or
> having BDEPEND replace the DEPEND statement as the default action of
> the
> eclass.
> 
> Other items might be needed, but that's doubtful.
> 
> Someone please advise the best course of action and either do it or I
> will propose a patch based on the discussion.
> 

Could or did someone also check through all the other eclasses that
don't have any global EAPI compatibility checks?
For the future, maybe it's better to add such a check - just accepting
0-7 or so, but unsure about all these custom EAPIs out there, might
force more eclass copying to some overlays.


Mart

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


[gentoo-dev] RFC: gles global USE flag, USE=opengl clarifying

2018-07-23 Thread Mart Raudsepp
Hello,

Currently we have rather a mess in terms of OpenGL API handling.
I think much of it comes from USE=opengl being rather vague - is it
supposed to mean "Use desktop GL", "Use GLX", or "Enable OpenGL
support". All of these mean quite different things:
* desktop GL means full OpenGL API, which in turn can be either used
via GLX platform (X11 only) or EGL platform.
* GLX means GLX platform - usable only on X11; all good and same as
desktop GL in the past, but we have people wanting wayland-only now
(and YES, desktop GL via EGL platform _is_ a thing), and GLX obviously
isn't something that works in native wayland.
* GL support could mean 3D via OpenGL in general; be it OpenGL, GLESv2,
GLESv3...

To make things easier to follow, there are basically three different
concepts and potential choices to make:

* API
* Platform
* Windowing system

API is either "full desktop" OpenGL (think e.g. OpenGL 4.5), or GLES;
GLES has multiple versions, but in practice it's GLESv2 with optional
support for GLESv3 - however afaik latest mesa supports GLESv3 too
whenever GLESv2 is built.

Platform is either GLX or EGL. GLX only works in combination with "full
desktop" OpenGL; EGL can work with either.
For non-Linux there's also CGL (OSX), WGL (Windows), EAGL (iOS) and
more. Can be interesting for Gentoo Prefix.

"EGL is an interface between Khronos rendering APIs such as OpenGL ES
or OpenVG and the underlying native platform window system." - thus the
third choice with EGL platform - windowing system. This then is about
supporting a certain graphics environment with EGL (with GLX that can
be taken as just always X).
This can be for example x11, wayland, GBM (think rendering 3D directly
on top of a KMS terminal), win32, cocoa, android, vivante framebuffer
(with proprietary vivante 3D stack; not applicable to open source
etnaviv), DispmanX (RPi), etc.
This can be a choice especially for certain kind of OpenGL libraries;
one big example I know of is GStreamer GL libraries.



Anyhow, here's an initial proposal to try to sort it out via a USE=gles
global USE flag and a set of guidelines how to use it together with a
USE=opengl and other related USE flags in ebuilds:


use.desc:
opengl - Add support for desktop OpenGL (3D graphics)
gles - Add support for OpenGL ES, or prefer it over desktop OpenGL. This should 
usually only be enabled globally on embedded systems that do not support full 
desktop GL.

[How is it correct to refer to "full desktop" GL without it being
confusing with OpenGL in general?]


Guidelines:

* If package has optional GL support in general (can work with either
desktop GL or GLES when OpenGL is enabled; doesn't care which one is
there), use both opengl and gles in IUSE and enable GL support and
ebuild logic when either is enabled

* If package is fully about OpenGL (GL itself isn't optional) and
supports either desktop GL or GLES, but not both at once: IUSE="gles"
and use GLES if that is set, "full desktop" GL otherwise.

* If package is fully about OpenGL (GL itself isn't optional) and
supports either desktop GL or GLES, including both at once: IUSE="gles
+opengl" and use whichever is enabled. As GL isn't optional as a whole,
require at least one of them: REQUIRED_USE="|| ( gles opengl )".

* If package has optional OpenGL support and needs specific logic for
the chosen API: IUSE="gles opengl" or IUSE="gles +opengl", depending if
GL should be default enabled (albeit we might want to revise this via
profile level defaults flag instead?) - don't default enable gles, as
it's not a common use case and such embedded system users will have it
globally enabled anyways.
** Enable any of the GL logic only if either gles or opengl is enabled.
** If both are supported at the same time, enable whichever is chosen
by user (this could often mean also passing a generic --enable-gl
passing if either USE is set and then specifying the API to use with a
separate build flag).
** If both are not supported at the same time, set REQUIRED_USE="gles?
( !opengl )", use whichever is chosen (keeping in mind that both might
be disabled → no GL at all).

* If package needs to provide choices for the used GL platform or
windowing system, while GL itself is optional as a whole, don't forget
to keep the dependencies and other logic for the platform/WS
conditional to USE=gles and/or USE=opengl. This is usually easiest to
handle via GL_DEPS helper variable with dependencies applicable to
either and then putting it in as e.g. "opengl? ( $GL_DEPS ) gles? (
$GL_DEPS )" together with any specific ones; similar for certain needed
REQUIRED_USEs, with appropriate conditional blocks in src_configure().

* If package supports X11 via either GLX or EGL x11 windowing system,
just enable GLX via USE="opengl X" (or USE="-gles X" if no opengl in
IUSE) and EGL x11 via USE="egl X". Don't forget that "egl X" should
pull in EGL and X dependencies necessary for it only if GL as a whole
is enabled, if that is optional.

* It is OK to have certain 

Re: [gentoo-dev] [PATCH] meson.eclass: require at least meson-0.41.1

2018-07-23 Thread Mart Raudsepp
Ühel kenal päeval, P, 22.07.2018 kell 20:27, kirjutas Zac Medico:
> Require newer meson in order to avoid build failures triggered
> if >=meson-0.41.1 is not installed soon enough. For example,
> I experienced bug 649264 because I upgraded xorg-proto and
> libxshmfence packages before meson.
> 
> Fixes: https://bugs.gentoo.org/649264

Closes, not Fixes?

> ---
>  eclass/meson.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index f2202a04593..2523bec57ac 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -59,7 +59,7 @@ EXPORT_FUNCTIONS src_configure src_compile src_test
> src_install
>  if [[ -z ${_MESON_ECLASS} ]]; then
>  _MESON_ECLASS=1
>  
> -MESON_DEPEND=">=dev-util/meson-0.40.0
> +MESON_DEPEND=">=dev-util/meson-0.41.1

By my understanding this should be 0.44.1, not 0.41.1.
At least 0.43.0 is one of the broken versions.

0.44.1 is also the lowest available version in tree; raising
MESON_DEPEND to that would as a side-effect not require ebuilds to have
their own meson depend, when they need newer versions (>=0.41 was
common in gnome 3.26, might be >=0.44 in newer).

>   >=dev-util/ninja-1.7.2"
>  
>  # @ECLASS-VARIABLE: MESON_AUTO_DEPEND

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


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Mart Raudsepp
Ühel kenal päeval, R, 20.07.2018 kell 17:01, kirjutas Benda Xu:
> Hi Mart,
> 
> Mart Raudsepp  writes:
> 
> > That said, I would question such a choice. Does it technically not
> > work or what's the problem with it?
> 
> It works partially.  Most of the time they does not bulid. 

That sounds like a case for package.use.mask for the given packages in
prefix profiles?

> The host OS handles /dev for Gentoo Prefix, be it mdev or udev.

But in various cases it's about getting notified of plugged in devices.
But yes, then the question is if the prefix libudev can get these
notifications from host udev or some such.

> > But it's up the prefix project.
> 
> Yes, if the Linux profile enables it, we will have to disable it
> explicitly in the Linux Prefix profiles.
> 

But you are getting this already for various packages from their IUSE
defaults +udev usage as far as I can see.


Anyhow, I concede to the problems stemming from USE_ORDER described by
mjo and retract my strong preference of global USE=udev, pending proper
solution for those problems. However concrete examples as asked by Matt
would be nice.
Someone should work on that USE_ORDER issue... This IUSE default vs
profiles trouble keeps coming up every couple of months..


Mart

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


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Mart Raudsepp
Ühel kenal päeval, R, 20.07.2018 kell 01:58, kirjutas Michael Orlitzky:
> On 07/20/2018 01:06 AM, Mart Raudsepp wrote:
> > > 
> > >   * They can't be undone. It's next to impossible for me to undo
> > > USE=udev when set in a profile that is inherited by all
> > > others.
> > 
> > You set USE=-udev in your make.conf.
> 
> That doesn't work, for reasons already stated.
> 
> If I set USE="-udev" in my make.conf, I don't get the same behavior
> that
> I would if you left the default alone. Specifically, setting USE="-
> udev"
> in make.conf will disable udev support in all packages that have
> IUSE="+udev", whereas now they are built WITH udev support. This
> causes
> severe breakage in some cases, and there's no way for me (or anyone
> else) to regain the existing behavior once you turn the flag on by
> default.
> 
> 
> >  Or in a profile that really needs this disabled.
> 
> Yeah I'd love to except that you're proposing we add it to the
> "linux"
> profile, and it can't be overridden in a sub-profile for the same
> reason
> it can't be overridden in make.conf.

Ok, I can see that point of view for make.conf.
I can't agree with changes in other profiles though, as other profile
will fall under the same category in USE_ORDER (in fact, it's the same
thing, as the end USE from "defaults" comes from your selected profile
and it's "parent" cascade, not taken from linux profile). But maybe you
have it tested and know it's a problem. Have you?

For the IUSE defaults vs make.conf (and other per-system override
places) problem, we should really do something about it, it keeps
coming up as an issue.


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


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Mart Raudsepp
Ühel kenal päeval, R, 20.07.2018 kell 12:40, kirjutas Benda Xu:
> > Any objections to this idea?
> 
> To represent the Gentoo Prefix users, we would like to have USE=udev
> turned off or even hard masked on linux-prefix profiles.

Nothing stops you from doing that in prefix profiles, just like USE=acl
is handled right now.

That said, I would question such a choice. Does it technically not work
or what's the problem with it?
But it's up the prefix project.


Mart

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


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Mart Raudsepp
Ühel kenal päeval, R, 20.07.2018 kell 00:04, kirjutas Michael Orlitzky:
> On 07/19/2018 11:49 PM, Aaron Bauman wrote:
> > You are denying the majority default here. Granted, we don't have
> > statistics... Cuz Gentoo.
> 
> No I'm not. I'm saying add them per-package, because it's a better
> design. We have package.use in profiles now, not just IUSE defaults.
> 
> Global defaults have problems:
> 
>   * They can't be undone. It's next to impossible for me to undo
> USE=udev when set in a profile that is inherited by all others.

You set USE=-udev in your make.conf. Or in a profile that really needs
this disabled.
If as a package maintainer that's not appropriate for a package, then
that sounds like USE=udev is not appropriate for your package.
Got any concrete samples in that case?

>   * USE=udev means different things for different packages. You think
> it
> "makes udev work" or whatever, but nobody has any idea what it
> does
> for half of the packages that use it. The meaning is package-
> specific, so the default should be package-specific.

It makes hardware work without static configurations, including when
hotplugged. It should be enable by default for all Linux users.
People who make a conscious choice to deal with this by hand can easily
set USE=-udev in their make.conf and deal with this by hand afterwards.

The default shouldn't be "nothing works, until you make it work".

>   * They're easy to set, but hard do unset when you realize you were
> wrong a year from now.
> 
> If you really want to enable it globally after being told that it's
> bad
> engineering and downright annoying, go do it in a profile that I can
> avoid and not "linux".

Don't believe everything you're told.
If you still buy into all the trouble you are getting into by stopping
to rely on udev, you disable it in make.conf and use --changed-use for
emerge.


Mart

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


Re: [gentoo-dev] Packages up for grabs: net-news/rssguard,...

2018-07-19 Thread Mart Raudsepp
Ühel kenal päeval, K, 18.07.2018 kell 23:38, kirjutas Jonas Stein:
> net-misc/streamlink

I can take this, as I use it. Co-maintainers very welcome.


Mart

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


[gentoo-dev] Last rites: gnome-base/libgnomeprint gnome-base/libgnomeprintui

2018-07-16 Thread Mart Raudsepp
# Mart Raudsepp  (16 Jul 2018)
# Obsolete early GNOME 2 era print libraries. Applications
# use printing support found directly in x11-libs/gtk+ now.
# Removal in 30 days. Bug #352952
gnome-base/libgnomeprintui
gnome-base/libgnomeprint


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


[gentoo-dev] Last rites: x11-libs/wxGTK:2.8 dev-python/wxpython:2.8

2018-07-15 Thread Mart Raudsepp
# Mart Raudsepp  (16 Jul 2018)
# Parallel-installable old versions with no remaining consumers
# in main tree. Use applications ported to wxGTK:3.0 and
# wxpython:3.0 instead. Bug #661284
x11-libs/wxGTK:2.8
dev-python/wxpython:2.8


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


Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address

2018-07-09 Thread Mart Raudsepp
Ühel kenal päeval, E, 09.07.2018 kell 10:40, kirjutas Michał Górny:
> Hi,
> 
> We currently don't enforce any particular standard for e-mail
> addresses
> for developers committing to gentoo.git.  FWICS, the majority of
> developers is using their @gentoo.org e-mail addresses.  However, a
> few
> developers are using some other addresses.
> 
> Using n...@gentoo.org e-mail addresses generally causes problems
> in accounting for commits.  For example, our retirement scripts can't
> detect commits made using non-Gentoo e-mail address.  My dev-timeline
> scripts [1] account for all emails in LDAP (which doesn't cover all
> addresses developers use).  FWIK gkeys accounts for all addresses
> in the OpenPGP key UIDs.  In my opinion, that's a lot of hoops to
> jump
> through to workaround bad practice.
> 
> Therefore, I'd like to start enforcing (at the level of the hook
> verifying signatures) that all commits made to gentoo.git (and other
> repositories requiring dev signatures) are made using @gentoo.org e-
> mail 
> address (for committer field).
> 
> Is anyone opposed to that?  Does anyone know of a valid reason to use
> n...@gentoo.org address when committing?

As long as that doesn't imply authorship, which seems to be as planned
(for committer field only, as you said). Hopefully it's easy for people
to set it up so that it uses gentoo address for committer and something
else for author, albeit I don't see any config for it, but should be
able to at least go via a script that uses the appropriate env vars.

That's then for work computers where the Gentoo developer is doing work
necessary for his/her employer, on employers paid time. Appropriate
then to have their work e-mail as author, especially if employer
rightfully requests that to be used for authorship. But yeah, committer
field should be fine, they can do author with one address, committer
with Gentoo address.

The only issue I see is that of slight complications on handling the
different addresses for author and commit, that's all that comes to
mind.


Mart

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


Re: [gentoo-dev] [PATCH 1/2] gnome2-utils.eclass: make EAPI 7 ready

2018-06-18 Thread Mart Raudsepp
Ühel kenal päeval, E, 18.06.2018 kell 08:01, kirjutas Ulrich Mueller:
> > > > > > On Sun, 17 Jun 2018, Marty E Plummer wrote:
> > Signed-off-by: Marty E. Plummer 
> 
> Please don't yet use Signed-off-by. Our policy on this (GLEP 76) is
> still a draft and subject to change.
>  
> > -DEPEND=">=sys-apps/sed-4"
> > -
> > +# sed needs to be executable on the build system
> > +BDEPEND=">=sys-apps/sed-4"
> > +[[ ${EAPI:-0} == [0123456] ]] && DEPEND="${BDEPEND}"
> 
> These >=sed-4 dependencies are a relic from the time when there was a
> sed-3. It left the tree in 2003 though.
> 
> So I suggest to remove this build-time dependency altogether.

I prefer being explicit, but that's probably a lost "battle" for sed,
so, OK, we can remove it instead.

Otherwise as a generic question for EAPI-7 support in other eclasses:
Doesn't this case leak a BDEPEND variable to ebuilds for lower EAPIs,
as there's no "unset BDEPEND" for the lower EAPIs. And is that OK?


I have various changes still in my TODO queue to both these eclasses,
and I need to get to those soon. So I suggest to wait with any pushing
of these to be done together, so metadata is invalidated only once.
I also would welcome help making these changes, to reduce the time
delta where these EAPI-7 support wouldn't be pushed due to this. If it
becomes unreasonably delayed, so ebuilds want to start using EAPI-7 for
these cases, then I guess it can be pushed once fixed up. But yeah, I
need the other changes within 1-2 weeks to start moving GNOME 3.26 to
tree.
That's about putting icon cache stuff to xdg-utils and xdg instead of
gnome* (Qt uses it too), some magic to avoid double calls if possible,
and some other changes that come out of gnome overlay gnome-
meson.eclass review (with the goal of perhaps not needing it in most
cases when combining with "inherit meson xdg" instead)


Mart

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


Re: [gentoo-dev] Lastrites: games-arcade/xevil, x11-plugins/wmlaptop, dev-java/servletapi, dev-java/sun-jacc-api...

2018-06-17 Thread Mart Raudsepp
Ühel kenal päeval, P, 17.06.2018 kell 14:24, kirjutas Pacho Ramos:
> # Pacho Ramos  (17 Jun 2018)
> # Needs someone to maintain this package and bump it to newer
> versions
> # stopping to rely on dead gstreamer:0.10 (#438972). Removal in a
> month.
> media-video/aravis

lu_zero bumped this to 0.5.10 with gstreamer:1.0 usage 2 weeks ago..
I don't know why he didn't check and update bugs.


Mart

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


[gentoo-dev] Last rites: media-plugins/gst-plugins-schroedinger

2018-06-16 Thread Mart Raudsepp
# Mart Raudsepp  (16 Jun 2018)
# No upstream (website disappeared), no upstream plugin maintainer,
# and pretty much a fringe format anyway.
# Marked for removal in 30 days, bug #658194
media-plugins/gst-plugins-schroedinger


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


Re: [gentoo-dev] Developers, please start switching to 17.1 amd64 profiles

2018-05-27 Thread Mart Raudsepp
I'd welcome some help on https://bugs.gentoo.org/552500 for wxWidgets.
I'm not sure when I can get to it, I'm not much into bash and eselect
modules, I didn't author the module and I'm lacking time for wx which I
kind of just inherited back and don't use myself anymore :(

There's an ebuild based fix contributed, but I think we can do it in
the eselect module sources instead?


Mart

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


Re: [gentoo-dev] Planning for disabling CVS services: migration of remaining active users

2018-05-26 Thread Mart Raudsepp
Ühel kenal päeval, P, 20.05.2018 kell 22:25, kirjutas Robin H. Johnson:
> For size comparison, the gentoo-x86 CVS module was about 4G when we
> switched to Git, and that generated the 1.8GB
> repo/gentoo/historical.git
> repo (which included app-backup that got lost in earlier
> conversions).

Where is that non-earlier repo/gentoo/historical.git with included app-
backup?
https://gitweb.gentoo.org/repo/gentoo/historical.git/ does not have it.




[gentoo-dev] [RFC] arm64 stable profiles

2018-05-03 Thread Mart Raudsepp
Hello,

I intend to mark the following profiles stable within a week or so:

default/linux/arm64/17.0
default/linux/arm64/17.0/systemd

arm64 (AArch64) is becoming a rather major architecture in the computer
industry, from small single board computers to very beefy servers. It
is about time to grace it with stable Gentoo support.

Thanks to access to a 96 cores @ 2.0GHz arm64 server with 128GB RAM it
has been easy to finish up fixing our keywording issues and clear up
stabilization queue. This access has been kindly provided to Gentoo by
packet.net via the Works on Arm initiative.


Before proceeding I intend to get the following still done first:

* Clear up the stabilization queue (only about 3 actionable bugs still
to do at the moment, rest is caught up)
* Reduce things that are USE masked (from early keyword issue solving),
before higher care needs to be taken for that work with stable
profiles; in particular I want to concentrate on test dependencies and
some more widely used optional features and their external deps

Shortly afterwards:
* Spin a new stage3
* Look into moving the stages out of experimental status

Later plans:
* Support more server software
* Introduce ~arm64 GNOME3 support (and stabilize later on); (thanks Ben
Kohler, for donating me a DragonBoard 410c a while back, on which I'll
be able to test running it)
* Start actively taking and handling keywording and stable requests of
things people want to use on their Aarch64 hardware
* More automated stage tarballs
* Become Gentoo Security supported
* Overtake amd64 in supported maintained software?


The intention is also to follow up with the following profiles soon
enough, as we start tracking more desktops as well:
default/linux/arm64/17.0/desktop
default/linux/arm64/17.0/desktop/system
d
default/linux/arm64/17.0/developer

Still pondering about the default/linux/arm64/17.0/developer profile,
given its effect on repoman speed for all, compared to its value to
end-users and inflexibility to developers for whom this is meant for.

Once GNOME is supported, we'd also make new
default/linux/arm64/17.0/desktop/{,systemd} profiles into stable and
whatever other profiles that have their relevant packages properly
supported in the future (e.g. plasma).


Bikeshed now or forever hold your peace.


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


Re: [gentoo-dev] Current state of arm and arm64 architecture in Gentoo Linux

2018-04-30 Thread Mart Raudsepp
Ühel kenal päeval, E, 30.04.2018 kell 18:11, kirjutas Robin H. Johnson:
> On Mon, Apr 30, 2018 at 07:39:59PM +0800, Pengcheng Xu wrote:
> > Hi all,
> > 
> > I'm currently working on my Gentoo GSoC project (
> > https://summerofcode.withgoogle.com/projects/#5132157995974656 ),
> > and
> > I'm wondering what's the current work state of Gentoo Linux's arm
> > architecture. The last stage3 tarball update date was 20161127,
> > and,
> > as it's quite dated compared to popular architectures (e.g. amd64),
> > does that mean the architecture is no longer actively maintained
> > anymore?
> > 
> > And I've read about the arm64 architecture for Gentoo Linux. Is
> > that still considered experimental for now?
> 
> The date of the stage3 tarball is mostly a function of lack time in
> working on the host for the automated catalyst builds.
> 
> Specifically, spinning up stuff at Packet.net's ARM64 servers,
> bootstrapped in Gentoo from their Ubuntu/Debian offerings.
> 
> Packages are definitely being tested & keyworded for arm64.

2016 old official stages are for arm 32bit. arm64 stages are less than
2 months old. Been working on stabilization queue, so the next built
stage would actually have updates :)

Regarding arm (where things are too outdated): there are newer
unofficial stages out there from non-developers, but official builds
have stalled.

Using those servers for arm32 stage builds could be interesting though
to get something out properly when hand-built, but I make a point of
staying hands off of arm32 (there's only so many hours in a day), so I
don't even know if it'd be anything similarly easy like x86 on amd64 hw
is.
If it is, I might be able to do the necessary commands to get it done,
when someone helps handle the issues that come up.

More details from arm64 side in a couple days hopefully, if still
needed.


Mart

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


[gentoo-dev] Last rites: media-plugins/gst-plugins-mad:1.0

2018-03-30 Thread Mart Raudsepp
# Mart Raudsepp <l...@gentoo.org> (30 Mar 2018)
# GStreamer mp3 decoder plugin based on libmad is removed with gstreamer-1.12.
# media-plugins/gst-plugins-mpg123 is the suggested replacement.
# Masked for removal in 30 days. Bug 631128
media-plugins/gst-plugins-mad:1.0

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


Re: [gentoo-dev] Project:Lisp without members

2018-03-21 Thread Mart Raudsepp
Ühel kenal päeval, L, 10.03.2018 kell 13:26, kirjutas Pacho Ramos:
> From now Project:Lisp has no members... that doesn't seem an issue as
> it
> contains multiple subprojects that maintain relevant packages... but,
> for the
> case anyone wants to join the main project...
> https://wiki.gentoo.org/wiki/Project:Lisp

This is a valid setup of projects to my knowledge. Please correct me if
I'm wrong. Don't undertake parent projects if they have subprojects
with active members please. In other words, please don't undertake a
project if it has active subprojects, if that was your mails intention
here.
https://wiki.gentoo.org/wiki/Project:Lisp even lists subprojects and
their members as part of lisp project. Though it seems to have gotten a
direct member now too to prevent the implicit undertaking intention
(which I think is unnecessary).




[gentoo-dev] Last rites: net-libs/webkit-gtk:{2,3}

2018-02-22 Thread Mart Raudsepp
# Mart Raudsepp <l...@gentoo.org> (23 Feb 2018)
# Old net-libs/webkit-gtk SLOTs have hundreds of known security issues.
# Use the security safe net-libs webkit-gtk SLOT=4 instead via
# libraries and applications ported to gtk3 and webkit2gtk API.
# Masked for removal in 30 days. Bug #577068.
# Please keep this package.mask entry until at least 25th May 2018 for
# extra notification of the security vulnerabilities.
net-libs/webkit-gtk:2
net-libs/webkit-gtk:3



[gentoo-dev] Last rites: dev-libs/libgames-support

2018-02-22 Thread Mart Raudsepp
# Mart Raudsepp <l...@gentoo.org> (22 Feb 2018)
# This package was renamed to dev-libs/libgnome-games-support without
# a pkgmove; everything in tree uses it now instead of libgames-support.
# Masked for removal in 30 days. Bug #648468.
dev-libs/libgames-support



Re: [gentoo-dev] [PATCH] glep-0068: Add element to metadata.xml

2018-02-20 Thread Mart Raudsepp
On Tue, 2018-02-20 at 22:58 +0100, Michał Górny wrote:
> @@ -147,6 +147,11 @@ element can contain, in any order:
>    languages (at most one for each language), as detailed
>    in `Slot descriptions`_.
>  
> +- zero or more  elements, possibly
> restricted
> +  to specific package versions (at most one for each version) whose
> presence
> +  indicates that the appropriate ebuilds are suitable for ALLARCHES
> +  stabilization.
> +

ALLARCHES is a bugzilla keyword that happened to get referred to as
such for the action as well, in all its yelling glory.
I would prefer the action itself defined here, not refer to some
bugzilla keyword that lacks any reference citation and is known mainly
just from moderate maintainer experience or googling.




Re: [gentoo-dev] EAPI 7 in Portage needs YOU!

2018-02-19 Thread Mart Raudsepp
On Mon, 2018-02-19 at 18:34 +0100, Ulrich Mueller wrote:
> > > > > > On Mon, 19 Feb 2018, Michael Lienhardt wrote:
> > > 2. ||= (binding any-of) dep groups.
> > I don't understand what this group means, and the PMS-7 is unclear
> > as well:
> >   "binding-any-of A binding-any-of group, which has the same format
> >   as the any-of group, but begins with the string ||= instead."
> > Is it a "or", like the "any-of" group, but with a different
> > behavior
> > at compiling/linking time?
> 
> It is explained in section 8.2.4:
> https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-88.2.4

Maybe I missed this, but a real world use case example would be nice,
maybe someone feels a harder itch to scratch then :)




Re: [gentoo-dev] RFC: Moving gnome2_icon_cache_update functionality to xdg-utils.eclass

2018-02-16 Thread Mart Raudsepp
On Fri, 2018-02-16 at 06:38 +0100, Michał Górny wrote:
> W dniu pią, 16.02.2018 o godzinie 02∶17 +0200, użytkownik Mart
> Raudsepp
> napisał:
> > Hello,
> > 
> > Before writing the obvious patches, would anyone terribly object to
> > moving gnome2_icon_cache_update into xdg-utils.eclass instead and
> > hooking it up via savelist guard in xdg.eclass (only running in
> > postinst/postrm when really needed)?
> > 
> > The gtk icon cache format isn't used by gtk+ only - it's used by Qt
> > as
> > well these days; and either way if anything installs things per the
> > icon specs, the caches should be updated for gtk/qt to see it (even
> > if
> > the program itself is written in motif or something).
> 
> Maybe it'd be reasonable to rename it while at it, to gtk_icon_cache*
> or xdg_gtk_icon_cache*. It would really suck to have xdg* provide
> a function named gnome2*, especially when it's not specific to GNOME.

Yes, of course. That's an obvious thing to do, didn't even think to
mention it explicitly. Afterall, we'll need the old name still in
gnome2-utils for compatibility for a while too.
I'm unsure about the name though, I like gtk_update_icon_cache, but not
having it prefixed with xdg or xdg-utils sounds a bit wrong; though I
think it makes a good argument to make an exception here. The tool that
provides the helper is split into a gtk-update-icon-cache named packge
as well.
Do you have any opinions on my dilemmas?

> > 
> > Open dilemmas:
> > 
> > * To DEPEND on gtk-update-icon-cache, or to rely on the toolkits to
> > pull it in and only run the updates if the helper is present. We
> > have
> > it split out from gtk+ codebase, so it only has glib/gdk-pixbuf
> > deps
> > right now.
> > 
> > * If it's worth trying to avoid double calls in postint and postrm
> > for
> > ebuilds that inherit xdg and call gnome2_icon_cache_update manually
> > right now on top (due to xdg.eclass not doing it for them).
> > 
> > 
> > If these changes are agreeable, then they could also be batched
> > into a
> > single push with the documentation update patches pending from
> > mgorny
> > for a single metadata cache invalidation of gnome2-utils.eclass
> > using
> > ebuilds.
> > 
> > If this looks good, I can write patches soon, though there's always
> > other things to do too (like work on integrating a gnome-
> > meson.eclass
> > or meson-desktop.eclass on top of this), so help with patches
> > welcome
> > as well.
> > 
> > 
> > Mart
> > 
> 
> 



[gentoo-dev] RFC: Moving gnome2_icon_cache_update functionality to xdg-utils.eclass

2018-02-15 Thread Mart Raudsepp
Hello,

Before writing the obvious patches, would anyone terribly object to
moving gnome2_icon_cache_update into xdg-utils.eclass instead and
hooking it up via savelist guard in xdg.eclass (only running in
postinst/postrm when really needed)?

The gtk icon cache format isn't used by gtk+ only - it's used by Qt as
well these days; and either way if anything installs things per the
icon specs, the caches should be updated for gtk/qt to see it (even if
the program itself is written in motif or something).

Open dilemmas:

* To DEPEND on gtk-update-icon-cache, or to rely on the toolkits to
pull it in and only run the updates if the helper is present. We have
it split out from gtk+ codebase, so it only has glib/gdk-pixbuf deps
right now.

* If it's worth trying to avoid double calls in postint and postrm for
ebuilds that inherit xdg and call gnome2_icon_cache_update manually
right now on top (due to xdg.eclass not doing it for them).


If these changes are agreeable, then they could also be batched into a
single push with the documentation update patches pending from mgorny
for a single metadata cache invalidation of gnome2-utils.eclass using
ebuilds.

If this looks good, I can write patches soon, though there's always
other things to do too (like work on integrating a gnome-meson.eclass
or meson-desktop.eclass on top of this), so help with patches welcome
as well.


Mart



Re: [gentoo-dev] rfc: Remove inherit eutils from font.eclass for EAPI=6

2018-02-15 Thread Mart Raudsepp
On Thu, 2018-02-15 at 08:46 +0100, Guilherme Amadio wrote:
> Most of the above only use usex, and terminus-font uses einstalldocs
> as well.
> I think these should be pretty easy to fix to not use eutils, or
> simply
> add 'inherit eutils' for these ebuilds, then remove from the eclass.
> 
> I can help with testing by reading ebuilds more carefully and
> emerging
> them after the change in font.eclass.

einstalldocs is part of EAPI-6 and inherit eutils isn't needed for that
if it's EAPI-6. In fact, eutils doesn't define it for EAPI-6, only 0-5.

Same with usex, except that's builtin already in EAPI-5.


Mart



Re: [gentoo-dev] rfc: Remove inherit eutils from font.eclass for EAPI=6

2018-02-14 Thread Mart Raudsepp
On Wed, 2018-02-14 at 23:43 +0100, Jonas Stein wrote:
> Did I miss something?
> Who can help to check with (an automatic) testenvironment, if these
> packages will survive?

Don't check with test environments, read the ebuilds. Test environments
will find it hard to catch changes in the installed files. For example
the first issue in that list I found was relying on the inherit for a
make_desktop_entry call. In a test environment, it'll just not install
a desktop entry while outputting a function not found call or something
I suspect. You are lucky if that message is somehow parsed out, and
then there are other similar issues possible. (In this example,
inheriting desktop.eclass should be added to the ebuild before eclass
drops the eutils inherit)

If you want to do it, really should just read over all these ebuilds
manually. A test environment has a hard time to catch some sort of
conditional calls to eutils functions as well, when they don't enter
that conditional block for any reason.
I suspect most others than this xmind are rather simple ones that don't
even have anything beyond declaring the DEPEND and other variables.

Also start with the patch to bail out on unknown EAPI's that you were
planning to do. This can be separate commit done before this change,
once checks are done. Of course ideally pushed together (if the eutils
drop pans out) to minimize cache regenerations for developers.


Mart



Re: [gentoo-dev] [PATCH] gnome2-utils.eclass: Fix the documentation for cache update functions

2018-02-09 Thread Mart Raudsepp
On Fri, 2018-02-09 at 10:42 +0100, Michał Górny wrote:
> Fix the documentation for recently changed cache update functions
> that
> no longer rely on their _savelist() counterpart to indicate that.

Patch is good, but I'd prefer it linger for a while due to the metadata
cache rebuilds it would do for this.
I am also planning to write and push for review patches to move
icon_cache update to xdg-utils.eclass and xdg.eclass, which would
constitute to a cache update for all the same things again - help
welcome there to speed it up. That icon cache is used by Qt as well.

(the plan would be to move them there, think if there's any way to
avoid double cache generation for ebuilds that use xdg.eclass and call
gnome2_icon_cache_update on top of that, then start on a main tree
gnome-meson.eclass or so, that might not need to be gnome specific at
all then and be perhaps meson-desktop.eclass instead)

> ---
>  eclass/gnome2-utils.eclass | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
> index 9b4296c11fad..65076ae2d61e 100644
> --- a/eclass/gnome2-utils.eclass
> +++ b/eclass/gnome2-utils.eclass
> @@ -207,7 +207,9 @@ gnome2_gconf_uninstall() {
>  # @FUNCTION: gnome2_icon_savelist
>  # @DESCRIPTION:
>  # Find the icons that are about to be installed and save their
> location
> -# in the GNOME2_ECLASS_ICONS environment variable.
> +# in the GNOME2_ECLASS_ICONS environment variable. This is only
> +# necessary for eclass implementations that call
> +# gnome2_icon_cache_update conditionally.
>  # This function should be called from pkg_preinst.
>  gnome2_icon_savelist() {
>   has ${EAPI:-0} 0 1 2 && ! use prefix && ED="${D}"
> @@ -218,8 +220,7 @@ gnome2_icon_savelist() {
>  
>  # @FUNCTION: gnome2_icon_cache_update
>  # @DESCRIPTION:
> -# Updates Gtk+ icon cache files under /usr/share/icons if the
> current ebuild
> -# have installed anything under that location.
> +# Updates Gtk+ icon cache files under /usr/share/icons.
>  # This function should be called from pkg_postinst and pkg_postrm.
>  gnome2_icon_cache_update() {
>   has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"
> @@ -358,7 +359,8 @@ gnome2_scrollkeeper_update() {
>  # @FUNCTION: gnome2_schemas_savelist
>  # @DESCRIPTION:
>  # Find if there is any GSettings schema to install and save the list
> in
> -# GNOME2_ECLASS_GLIB_SCHEMAS variable.
> +# GNOME2_ECLASS_GLIB_SCHEMAS variable. This is only necessary for
> eclass
> +# implementations that call gnome2_schemas_update conditionally.
>  # This function should be called from pkg_preinst.
>  gnome2_schemas_savelist() {
>   has ${EAPI:-0} 0 1 2 && ! use prefix && ED="${D}"
> @@ -370,7 +372,7 @@ gnome2_schemas_savelist() {
>  # @FUNCTION: gnome2_schemas_update
>  # @USAGE: gnome2_schemas_update
>  # @DESCRIPTION:
> -# Updates GSettings schemas if GNOME2_ECLASS_GLIB_SCHEMAS has some.
> +# Updates GSettings schemas.
>  # This function should be called from pkg_postinst and pkg_postrm.
>  gnome2_schemas_update() {
>   has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"



Re: [gentoo-dev] Last Rites: Dead X11 packages

2018-02-08 Thread Mart Raudsepp
On Thu, 2018-02-08 at 14:57 +0100, Michael Lienhardt wrote:
> > >  From e590965cdeb0c921194740da0481c85afaa1ebae Mon Sep 17
> > > 00:00:00 2001
> > > From: Matt Turner 
> > > Date: Tue, 6 Feb 2018 14:02:59 -0800
> > > Subject: x11-base/xorg-server: Remove dead x11-
> > > proto/xf86rushproto dependency
> > > 
> > > rushproto hasn't been required since upstream commit 8ec79e05feac
> > > (in
> > > 2005!), and even then it wasn't actually needed!
> > > 
> > > Package-Manager: Portage-2.3.19, Repoman-2.3.6
> > > ---
> > >   x11-base/xorg-server/xorg-server-1.19.5.ebuild | 3 +--
> > >   x11-base/xorg-server/xorg-server-1.19.6.ebuild | 3 +--
> > >   x11-base/xorg-server/xorg-server-.ebuild   | 3 +--
> > >   3 files changed, 3 insertions(+), 6 deletions(-)
> > > 
> > 
> > Please don't edit dependencies in-line like this.
> > 
> > This warranted a revbump as users will be asking how to remove
> > x11-proto/xf86rushproto. It won't come up for depclean because of
> > xorg-server not being scheduled for rebuild automatically until the
> > next
> > time it is upgraded or --changed-deps option is used (uncommon).
> > 
> > Brian
> 
> Citing Kenneth Hoste at FOSDEM this year: modifying a package without
> changing its version is a bad idea.
> His presentation was very good (video included): https://fosdem.org/2
> 018/schedule/event/how_to_make_package_managers_cry/
> 

This isn't so clear cut simple. We build from source at user systems.
Think of the effect for something like webkit-gtk, chromium,
libreoffice, etc.

The problem here is the planned changing of --dynamic-deps to no as
default.




Re: [gentoo-dev] RFC: Bugzilla arch list reordering

2018-01-23 Thread Mart Raudsepp
On Tue, 2018-01-23 at 12:49 +0100, Dirkjan Ochtman wrote:
> On Tue, Jan 23, 2018 at 12:46 PM, Michał Górny 
> wrote:
> > Since neither of the proposals has received any specific reply, I'm
> > not
> > sure how to proceed from here. I suppose we can possibly have two
> > lists
> > in different order so that people could use whichever they prefer.
> 
> Not sure having two lists in Bugzilla would be an improvement. It
> would be nice if more people expressed a preference, though!

Whatever order eshowkw gives for each block, as that's the tool I use
to find out which arches to CC in the first place.




Re: [gentoo-dev] version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass

2018-01-23 Thread Mart Raudsepp
On Mon, 2018-01-22 at 12:07 -0800, Zac Medico wrote:
> On 01/22/2018 05:14 AM, Mart Raudsepp wrote:
> > On Sun, 2018-01-21 at 20:24 -0800, Zac Medico wrote:
> > > Hi,
> > > 
> > > In sys-app/portage-2.3.20, emerge now defaults to --dynamic-
> > > deps=n.
> > > This
> > > means that unless people explicitly set
> > > EMERGE_DEFAULT_OPTS="--dynamic-deps=y" they're going to have to
> > > rebuild
> > > packages any time that the runtime dependencies of those packages
> > > need
> > > to be updated. It's possible to trigger these rebuilds using the
> > > emerge
> > > --changed-deps=y option.
> > > 
> > > Some eclasses like autotools.eclass and vala.eclass generate
> > > version/slot locked dependencies that cause the dependencies of
> > > inheriting ebuilds to change when the versions in the eclasses
> > > are
> > > updated. If possible, it would be nice to avoid this version/slot
> > > locking. If not possible, then what should be do?
> > 
> > These are mostly build time only depends, why should the user now
> > all
> > of a sudden care before an unrelated rebuild or upgrade, which
> > would
> > actually matter only then, not before?
> 
> For various reasons, current versions of portage enable the
> --with-bdeps=y option by default [1]. Basically, failing to update
> installed packages and possibly leaving them with broken dependencies
> is
> not really a sane default behavior.
> 
> [1] https://bugs.gentoo.org/598444

Sure, and now in combination with --with-bdeps=y and --dynamic-deps=n,
thing are bad for these cases. I'm saying that users shouldn't have to
care about these cases.

That said, I'm not sure why the slot deps have to be there for the
cases $vala_depend is put into DEPEND; those might just be able to be
an unbounded dev-lang/vala. However where they are truly needed in
RDEPEND, they will need something here, just not sure := is going to
cut it. Maybe the interface is stable enough that anything will be fine
with the newest version by now, but not sure. Bottom-line is, we aren't
going to be revbumping all the vala.eclass users as a new GNOME version
with new vala appears. The idea is to get everyone to use the new
versions in stable ASAP, not rebuild all of them in stable first.
In any case, this will need investigation, and it is not a good time to
have such an investigation forced upon us with our current limited
manpower.




Re: [gentoo-dev] version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass

2018-01-22 Thread Mart Raudsepp
On Sun, 2018-01-21 at 20:24 -0800, Zac Medico wrote:
> Hi,
> 
> In sys-app/portage-2.3.20, emerge now defaults to --dynamic-deps=n.
> This
> means that unless people explicitly set
> EMERGE_DEFAULT_OPTS="--dynamic-deps=y" they're going to have to
> rebuild
> packages any time that the runtime dependencies of those packages
> need
> to be updated. It's possible to trigger these rebuilds using the
> emerge
> --changed-deps=y option.
> 
> Some eclasses like autotools.eclass and vala.eclass generate
> version/slot locked dependencies that cause the dependencies of
> inheriting ebuilds to change when the versions in the eclasses are
> updated. If possible, it would be nice to avoid this version/slot
> locking. If not possible, then what should be do?

These are mostly build time only depends, why should the user now all
of a sudden care before an unrelated rebuild or upgrade, which would
actually matter only then, not before?




Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp

2018-01-11 Thread Mart Raudsepp
On Thu, 2018-01-11 at 21:35 +0100, Michał Górny wrote:
> The point of dev is to bring staging warnings so that we can improve
> the depgraph. If you really insist, we can start with dev status for
> arm64 & mips. But it'd be more readable if we worked on only one arch
> simultaneously.

Keep 17.0 ones that were dev as dev then for arm64; 13.0 can all go to
exp. The latest arm64 stage3 is 17.0 already.

For all of those musl profiles should be fixed by their maintainer
(which isn't the arch team). It generates all that noise and it's the
main reason I had to do a separation of exp and dev for arm64 and mips,
so I can have any sort of readable repoman output whatsoever. Albeit
speed helps as well by only checking a subset of all arch profiles,
especially for mips.

mips we can move a couple back to dev once I revive the glibc on it and
can actually do work on it again, but it's lower priority.
Meanwhile mips "repoman -e y --include-arches mips" output is useless
with musl, unless doing some creative grep -v'ing...




Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp

2018-01-11 Thread Mart Raudsepp
On Thu, 2018-01-11 at 21:27 +0100, Michał Górny wrote:
> W dniu czw, 11.01.2018 o godzinie 22∶17 +0200, użytkownik Mart
> Raudsepp
> napisał:
> > On Thu, 2018-01-11 at 20:45 +0100, Michał Górny wrote:
> > >  # ARM64 Profiles
> > > -arm64   default/linux/arm64/13.0
> > > dev
> > > +arm64   default/linux/arm64/13.0
> > > exp
> > >  arm64   default/linux/arm64/13.0/desktop
> > > exp
> > > -arm64   default/linux/arm64/13.0/desktop/systemd
> > > dev
> > > +arm64   default/linux/arm64/13.0/desktop/systemd
> > > exp
> > >  arm64   default/linux/arm64/13.0/developer  
> > > exp
> > >  arm64   default/linux/arm64/13.0/systemd
> > > exp
> > > -arm64   default/linux/arm64/17.0
> > > dev
> > > +arm64   default/linux/arm64/17.0
> > > exp
> > >  arm64   default/linux/arm64/17.0/desktop
> > > exp
> > > -arm64   default/linux/arm64/17.0/desktop/systemd
> > > dev
> > > +arm64   default/linux/arm64/17.0/desktop/systemd
> > > exp
> > >  arm64   default/linux/arm64/17.0/developer  
> > > exp
> > >  arm64   default/linux/arm64/17.0/systemd
> > > exp
> > 
> > With this I'll need to run through all of these profiles with
> > repoman -e=y and wait a long time, instead of just the two (well,
> > with
> > 17.0 now 4) profiles that I actually care about and checks enough.
> > I
> > also will see a TON of issues from the musl profiles down below
> > that
> > main block (it doesn't inherit base or something).
> > 
> > This would make arm64 work completely impossible, so NAK from me.
> 
> repoman has --include-arches option for a reason. Profile statuses
> are
> not your private convenience.

That doesn't help whatsoever due to musl. Also not for running things
on a slower arch (mips in this case).

> > Additionally if depgraph wouldn't be broken anymore, we would be
> > moving
> > them to stable, not some separate "dev" step.
> > 
> > Same goes for the mips main block changes.
> 
> But it is broken, and it won't become less broken if we keep ignoring
> the fact and not reporting new breakages just because one developer
> can't fix his workflow.

Your patch simply removes dev completely, with no reason for it to
exist anymore then. If depgraph isn't broken, it'd be stable. There'd
be no reason for dev. Dev is dev BECAUSE it has a broken depgraph, but
is aspiring towards not.
My workflow is just fine.




Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp

2018-01-11 Thread Mart Raudsepp
On Thu, 2018-01-11 at 22:17 +0200, Mart Raudsepp wrote:
> On Thu, 2018-01-11 at 20:45 +0100, Michał Górny wrote:
> >  # ARM64 Profiles
> > -arm64   default/linux/arm64/13.0   
> > dev
> > +arm64   default/linux/arm64/13.0   
> > exp
> >  arm64   default/linux/arm64/13.0/desktop   
> > exp
> > -arm64   default/linux/arm64/13.0/desktop/systemd   
> > dev
> > +arm64   default/linux/arm64/13.0/desktop/systemd   
> > exp
> >  arm64   default/linux/arm64/13.0/developer 
> > exp
> >  arm64   default/linux/arm64/13.0/systemd   
> > exp
> > -arm64   default/linux/arm64/17.0   
> > dev
> > +arm64   default/linux/arm64/17.0   
> > exp
> >  arm64   default/linux/arm64/17.0/desktop   
> > exp
> > -arm64   default/linux/arm64/17.0/desktop/systemd   
> > dev
> > +arm64   default/linux/arm64/17.0/desktop/systemd   
> > exp
> >  arm64   default/linux/arm64/17.0/developer 
> > exp
> >  arm64   default/linux/arm64/17.0/systemd   
> > exp
> 
> With this I'll need to run through all of these profiles with
> repoman -e=y and wait a long time, instead of just the two (well,
> with
> 17.0 now 4) profiles that I actually care about and checks enough. I
> also will see a TON of issues from the musl profiles down below that
> main block (it doesn't inherit base or something).

To clarify, they don't inherit from profiles/arch/, so all the
package.use.stable.mask, package.use.mask, use.mask and other stuff is
broken, which I've fixed in main thing, so repoman -e y is still
impossibly noisy, even with --include-arches arm64, despite my fixes in
the proper place.

> This would make arm64 work completely impossible, so NAK from me.
> 
> Additionally if depgraph wouldn't be broken anymore, we would be
> moving
> them to stable, not some separate "dev" step.
> 
> Same goes for the mips main block changes.




Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp

2018-01-11 Thread Mart Raudsepp
On Thu, 2018-01-11 at 20:45 +0100, Michał Górny wrote:
>  # ARM64 Profiles
> -arm64   default/linux/arm64/13.0    dev
> +arm64   default/linux/arm64/13.0    exp
>  arm64   default/linux/arm64/13.0/desktop    exp
> -arm64   default/linux/arm64/13.0/desktop/systemd    dev
> +arm64   default/linux/arm64/13.0/desktop/systemd    exp
>  arm64   default/linux/arm64/13.0/developer  exp
>  arm64   default/linux/arm64/13.0/systemd    exp
> -arm64   default/linux/arm64/17.0    dev
> +arm64   default/linux/arm64/17.0    exp
>  arm64   default/linux/arm64/17.0/desktop    exp
> -arm64   default/linux/arm64/17.0/desktop/systemd    dev
> +arm64   default/linux/arm64/17.0/desktop/systemd    exp
>  arm64   default/linux/arm64/17.0/developer  exp
>  arm64   default/linux/arm64/17.0/systemd    exp

With this I'll need to run through all of these profiles with
repoman -e=y and wait a long time, instead of just the two (well, with
17.0 now 4) profiles that I actually care about and checks enough. I
also will see a TON of issues from the musl profiles down below that
main block (it doesn't inherit base or something).

This would make arm64 work completely impossible, so NAK from me.

Additionally if depgraph wouldn't be broken anymore, we would be moving
them to stable, not some separate "dev" step.

Same goes for the mips main block changes.


Mart



Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-11 Thread Mart Raudsepp
On Wed, 2018-01-10 at 20:00 -0500, Aaron W. Swenson wrote:
> On 2018-01-10 22:53, Ciaran McCreesh wrote:
> > On Wed, 10 Jan 2018 17:48:32 -0500
> > "Aaron W. Swenson"  wrote:
> > > Modified a bit. This should show for anyone who has GnuCash
> > > installed.
> > 
> > For anyone who has any version of GnuCash installed, either now or
> > at
> > any point in the future. (See the recent thread on expiring news
> > items...) Are you sure you don't just want to target this at people
> > who
> > have the old version installed, instead?
> 
> As mentioned, the concern is that someone will try to use a new
> version
> and old version simultaneously.
> 
> How about “ after
> quite some time. At least past the point that we'd be concerned
> about,
> I'm sure.

That sounds good to me. The background here is, that once 2.7 is
released as stable, it'll be released as version 3.0, so 4 is after
that.
And then if they keep doing 3.2, 3.4 and so on for a long time instead,
you can try to remember to tweak the news item to expire before, e.g to
a version that drops forward migration support from 2.6.

This is all on the premise, that it's a leaf package and only kept
shown to those that have it.


Mart



Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Mart Raudsepp
On Wed, 2018-01-10 at 22:38 +0300, Peter Volkov wrote:
> On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson  org> wrote:
> > Title: GnuCash 2.7+ Breaking Change
> 
> Aaron, but why do we need this news item? 2.7 version is a
> development version that is not supposed to be used by end users. As
> far as I understand this backup is a temporary measure until stable
> release will be out. It's much better to have this version package
> masked. Then in package mask comment we could note the need for
> backup.

2.6 is insecure by 400+ ancient webkit-gtk security vulnerabilities, we
can't responsibly wait anymore. 2.7.3 was tested by Aaron (who uses it
daily) to work quite nicely.
I want to last rite gnucash-2.6 used webkit-gtk before the month is
over, as the maintainer of webkit-gtk, and if 2.7 isn't there, 2.6 will
simply be fully masked as well along it.

Regarding the Display-If-Installed, it should indeed be shown before
upgrade, in my opinion; otherwise so easy to already get things
migrated to new format before any backups are made. Then again, as 2.6
will go away soon anyway, the usefulness of these backups is limited,
without some local overlay. I didn't quite understand Ciaran mail; if
the header actually means "display when an upgrade to 2.7 is possible",
then that's best.

Regarding elog vs news, please keep in mind that this is limited to
ONLY those that have gnucash installed, so this isn't one of these
"will be shown forever in 5 years for fresh stage3 install starts". We
should be able to use per-package news items much more freely for leaf
packages.


Mart



  1   2   3   4   >