Re: [gentoo-dev] [RFC] Gentoo Asahi Project
On Fri, 2023-12-29 at 21:44 +, Alexey Sokolov wrote: > 28.12.2023 18:49, Mart Raudsepp пишет: > > Hello! > > > > I have created the Gentoo Asahi Project to organize the enablement > > of > > Apple Silicon Mac machines in Gentoo via the main ::gentoo tree as > > much > > as possible. > > New approaches for the install process are also going to be a > > topic. > > > > Wiki page: https://wiki.gentoo.org/wiki/Project:Asahi > > > > > > > > Mart > > > Hi! > > Gentoo already can be installed there using Prefix. Does this project > instead replace macOS on the machine completely? Yes. This is for running Linux natively on them, but you are generally advised to keep macOS as well (in a dual-boot kind of setup) for future non-distributable firmware upgrade purposes. https://asahilinux.org/ is the upstream project and there is already https://github.com/chadmed/asahi-overlay and https://github.com/AsahiLinux/docs/wiki/Installing-Gentoo-with-LiveCD This official projects first goals are to review and bring much of the overlays content to the main ::gentoo tree, keep maintaining it (together with asahi-overlay contributors) and work towards new easier installation approaches. Personally I use Gentoo Linux (with the asahi-sources kernel) on my M2 Mac Studio as my main machine with fully HW accelerated GNOME, only booting to macOS for occasional iOS work or HDR support use. My macOS visits are painful though, and I might end up looking at Gentoo prefix to make it less painful, albeit I suspect the iOS work will be over and HDR working in linux for me sooner than I can get to looking into that. My main motivation was a completely silent machine which is more powerful than my Ryzen 3700X - big package compilation times are now 2.5 times faster, mostly from core count. But it's also for (non- gentoo) development in rust. Mart
[gentoo-dev] [RFC] Gentoo Asahi Project
Hello! I have created the Gentoo Asahi Project to organize the enablement of Apple Silicon Mac machines in Gentoo via the main ::gentoo tree as much as possible. New approaches for the install process are also going to be a topic. Wiki page: https://wiki.gentoo.org/wiki/Project:Asahi Mart
Re: [gentoo-dev] [PATCH 7/8] profiles/use.desc: Make USE=egl global
On Tue, 2023-12-19 at 12:50 +0100, Michał Górny wrote: > > > --- a/media-plugins/gst-plugins-gtk/metadata.xml > > > +++ b/media-plugins/gst-plugins-gtk/metadata.xml > > > @@ -6,7 +6,6 @@ > > > GStreamer package maintainers > > > > > > > > > - Enable EGL platform usage > > > Enable gtkglsink OpenGL sink based on > > > GLESv2 API > > > Enable gtkglsink OpenGL sink based on > > > desktop OpenGL API > > > > > > > Please do not lose extra information provided in local descriptions > > in this and many other cases where you remove the local description > > (in other proposed global USE flag cases as well). Just don't > > remove the local description then. Thanks. > > > > I've used my best judgment to figure out whether the local > description actually provides any "extra information". I didn't > touch the gtkglsink-related flags since they provided some > information. I fail to see how "platform usage" adds any information. With the tabs in the raw patch indent rendered as 8 spaces, my eyes shifted (no less than on 3 looking occurrences while also trying to get only this chunk into the reply) and I thought you are removing precisely that gtkglsink comment, sorry! > If you have "other proposed global USE flag cases" that are removing > information, please be more specific. I don't think any of these are very important, but if I were to nitpick: * x11-apps/mesa-progs local gles2 USE desc looked vaguely more useful than the new global; might be even more useful if it named the utilities by name (main one of interest is es2_info). * "asm - Enable using assembly for optimization" reads a bit weird - ultimately C, rust, etc end up using assembly in a way too. I would have went with something more of the "Enable use of hand optimized assembly routines" theme for the global desc. * gnustep-base/gnustep-gui USE=speech seems to have told something completely different than the global USE flag; maybe was looked into and determined it's actually indeed text-to-speech* Some specify what dep is used, but in many cases it's the obvious candidate. Maybe games- engine/scummvm isn't that obvious. But users will see from the deptree. * kde-apps/konqueror and net-misc/eventd specifies USE=speech installs a plugin, which might be useful information IF that's something that might need to be enabled by user on top to load the plugin. Not important. Mart
Re: [gentoo-dev] [PATCH 7/8] profiles/use.desc: Make USE=egl global
Ühel kenal päeval, P, 17.12.2023 kell 17:05, kirjutas Michał Górny: > Add a global USE=egl flag. It is used semi-consistently in 13 > packages, > though some use it as "EGL only" flag (there is also one using > USE=egl-only). > > Signed-off-by: Michał Górny > --- > dev-games/openscenegraph-openmw/metadata.xml | 1 - > dev-games/openscenegraph/metadata.xml | 1 - > dev-qt/qtgui/metadata.xml | 1 - > media-libs/clutter/metadata.xml | 1 - > media-libs/gst-plugins-bad/metadata.xml | 1 - > media-libs/gst-plugins-base/metadata.xml | 1 - > media-libs/libepoxy/metadata.xml | 3 --- > media-libs/libva-compat/metadata.xml | 1 - > media-plugins/gst-plugins-gtk/metadata.xml | 1 - > media-plugins/gst-plugins-vaapi/metadata.xml | 1 - > profiles/use.desc | 1 + > 11 files changed, 1 insertion(+), 12 deletions(-) > > diff --git a/media-plugins/gst-plugins-gtk/metadata.xml b/media- > plugins/gst-plugins-gtk/metadata.xml > index 7235f1bab7ba..f3b18c11bcfc 100644 > --- a/media-plugins/gst-plugins-gtk/metadata.xml > +++ b/media-plugins/gst-plugins-gtk/metadata.xml > @@ -6,7 +6,6 @@ > GStreamer package maintainers > > > - Enable EGL platform usage > Enable gtkglsink OpenGL sink based on > GLESv2 API > Enable gtkglsink OpenGL sink based on > desktop OpenGL API > Please do not lose extra information provided in local descriptions in this and many other cases where you remove the local description (in other proposed global USE flag cases as well). Just don't remove the local description then. Thanks. Mart
[gentoo-dev] Last rites: media-plugins/gst-transcoder
# Mart Raudsepp (2023-11-04) # gst-transcoder was merged into gst-plugins-bad and can be installed via # media-libs/gst-plugins-bad instead. Removal on 2023-12-04. Bug #916871. media-plugins/gst-transcoder
[gentoo-dev] Last rites: media-libs/gnonlin
# Mart Raudsepp (2023-11-04) # Legacy GStreamer non-linear multimedia editing elements, superseded by # media-libs/gstreamer-editing-services long ago. # Removal on 2023-12-04. Bug #916870. media-libs/gnonlin
[gentoo-dev] Last rites: media-libs/libofa
# Mart Raudsepp (2023-10-14) # The database used by this music fingerprint library has been defunct for # a while. Removal on 2023-11-13. Bug #915190. media-libs/libofa
[gentoo-dev] Last rites: media-plugins/gst-plugins-libmms
# Mart Raudsepp (2023-10-14) # GStreamer plugin removed upstream. MMS was deprecated in 2003 and no # streams using MMS are known to exist. Removal on 2023-11-13. Bug #915771. media-plugins/gst-plugins-libmms The upstream code for gst-plugins-libmms was deleted 2 years ago before GStreamer 1.20 release. MMS was deprecated in 2003 (in favour of RTSP) and support for it was dropped with MS Media Services 2008.
[gentoo-dev] Last rites: media-plugins/gst-plugins-ofa
# Mart Raudsepp (2023-10-04) # GStreamer plugin removed upstream. The database used by this music fingerprint # plugin has been defunct for a while. Removal on 2023-11-04. Bug #915189. media-plugins/gst-plugins-ofa The upstream code for gst-plugins-ofa was deleted before GStreamer 1.20 release, but we still had split package version ebuilds even though the plugin is gone upstream and simply fails at configure time for us ever since from blind bumps.
Re: [gentoo-dev] Possible merge of myspell/hunspell dictionaries
Ühel kenal päeval, P, 09.07.2023 kell 10:10, kirjutas Sam James: > > zurabid2...@gmail.com writes: > > > Hello everyone, > > > > I am new here, so I'm sorry in advance for any stupid thing I may > > say. I want to adopt hunspell for various reasons and what I've > > noticed is a plethora of app-dicts/myspell-* packages (for each > > language there's one). > > > > I suggest merging them into one big myspell-dicts package, which > > will certainly reduce maintenance burden (the similar thing is done > > with libreoffice-l10n, I think). > > > > My only real question is why they're split in the first place and > if there's some good reason for that. I've no idea. I would guess that they are different packages because they all have a different SRC_URI. Many to some libreoffice assets download location, but not all. Maybe they could all come from the same source in an updated packaging though, I don't know the background. Mart
[gentoo-dev] Packages up for grabs: app-office/gtg, media-video/celluloid, dev-python/liblarch
Hello, The following packages are up for grabs or currently more active co- maintainers: * app-office/gtg and its accompanying support library * dev-python/liblarch They currently need py3.11 support and some looking at open bugs about tests. It's a Getting Things Done app. * media-video/celluloid celluloid has had some proxy maintainers interest, but no-one concrete taking action seems to have surfaced until now. It needs a version bump and is generally low effort gtk4 GUI for mpv. There's a PR open for a version bump, but I believe there is now a newer version out there than that. In all of these cases I'm happy to stay on as a backup maintainer if the package adopter wishes, but can't currently actively give them the attention they deserve. Mart
Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
Ühel kenal päeval, K, 31.05.2023 kell 11:43, kirjutas Andrey Grozin: > Hello *, > > wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on > wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the > tree. Probably, in a vast majority of cases 3.0 can be simply > replaced by > 3.2 without any negative consequences. What could be a reasonable way > to > organize the transition 3.0 -> 3.2 in the tree? File a zillion bugs? > > The fact that this dependence is written in a special syntax > WX_GTK_VER="3.0-gtk3" > makes such a transition more difficult. Unlike the normal dependency > syntax, it is not possible to write something like > x11-libs/wxGTK:*= > This is unfortunate. The 3.0 -> 3.2 transition absolutely requires to > edit > ebuild texts, unlike :*= where the same ebuild can work with > different > slots (just a recompilation is sufficient for transition). This fact > makes it impossible for an ebuild to work with both slots. In a > majority > of cases, I suppose, it would be desirable to allow an ebuild to work > with > any of these 2 slots, without a necessity to edit it. But, alas, this > is > not possible. I'm not aware what :*= is supposed to do, or if it's even valid syntax, compared to := and :* While yes, wxGTK does have implicit subslots from the subslot not being specified (then the subslot is the same as the slot iirc), this isn't a case of perl or similar. This is a case of python, ruby and similar, as these are parallel-installable slots, where you would need to define which they are OK with and lock to that then to avoid issues with other deps using different wxGTK versions (for example imagine filezilla and libfilezilla in a scenario where libfilezilla might grow a dependency on wxCore at some point). But with new slot versions happening every half or full decade, it simply isn't worth adding such complexity. Instead everything should try to switch to the newer version and stop using 3.0 ASAP. Optimizing for users to be able to opt into using older buggier 3.0-gtk3 slot instead of 3.2-gtk3 in order to not have to have multiple slots installed isn't something that we should really worry about. That said, we should indeed work towards updating consumers to 3.2-gtk3 now where possible, which should allow many users to go back to only a single slot, or even from three slots to a single installed slot when they had 3.0 and 3.0-gtk3 before. I think you might have volunteered yourself for that, so you can proceed ;) Once the majority is in 3.0-gtk3, we can as a future step perhaps also add 3.0 ones to package.deprecated. Mart
Re: [gentoo-dev] [PATCH] gnome.org.eclass: Handle GNOME's .alpha/.beta/.rc versioning
Ühel kenal päeval, T, 14.03.2023 kell 05:36, kirjutas Ulrich Mueller:
> > > > > > On Tue, 14 Mar 2023, Matt Turner wrote:
>
> > -
> > SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_PVP}
> > /${GNOME_ORG_MODULE}-${PV}.tar.${GNOME_TARBALL_SUFFIX}"
> > +SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_PV
> > P}/${GNOME_ORG_MODULE}-${PV/_/.}.tar.${GNOME_TARBALL_SUFFIX}"
> >
> > -S="${WORKDIR}/${GNOME_ORG_MODULE}-${PV}"
> > +S="${WORKDIR}/${GNOME_ORG_MODULE}-${PV/_/.}"
>
> I suppose there can be only a single suffix? Still, using ${PV//_/.}
> to replace all "_" won't harm and might be slightly more systematic.
GNOME alpha/beta/rc versions could also be like this:
44.beta
44.beta.1
44.beta.2
44.rc
44.rc.1
So might want to consider handling that too to work with the same
metadata cache update, but the extra releases don't happen that often,
so might not be too much of a burden to handle manually in those
occasions for now.
Mart
Re: [gentoo-dev] [RFC] A new GLSA schema
Ühel kenal päeval, N, 10.11.2022 kell 22:07, kirjutas Jaco Kroon: > > Like glsa-check? > We currently use that, but it really just says which GLSAs are > applicable to the system, it doesn't tell me net-misc/asterisk- > 16.0.1:16 > - we've got ways of working from the glsa-check output to that. Of > particular annoyance if a GLSA lists multiple packages, of which you > have one installed, and one not. Given net-misc/asterisk-16.0.1:16 I > can > quite quickly determine that emerge -1av net-misc/asterisk:16 will > resolve the problem with the lowest possible risk of breakage to > other > components on the system, and without having to perform a full > update. emerge -vpO @security but to get something like it to only showing which installed asterisk SLOT is vulnerable would be some extra coding with portage API I think.
Re: [gentoo-dev] [PATCH 3/5] profiles: add USE=convert-sfnt
Ühel kenal päeval, L, 15.10.2022 kell 11:01, kirjutas Ulrich Mueller: > > > > > > On Sat, 15 Oct 2022, Sam James wrote: > > > +convert-sfnt - Convert BDF and PCF bitmap fonts to OTB wrapper > > format > > Sorry for the bikeshedding, but could we have a name that indicates > what > this global flag is about? Maybe something starting with "font" which > would at least point to the general area. Also I don't think it actually converts it in the sense that I would think when looking at the USE flag, but rather has the package ship it in an OpenType container AS WELL for pango to work with it? Mart
Re: [gentoo-dev] net-vpn/networkmanager-{openconnect,openvpn,pptp,vpnc} up for grabs
Ühel kenal päeval, P, 03.04.2022 kell 21:22, kirjutas Matt Turner: > These are all assigned to gnome@, but I don't use any of these, so I > can't > really test them. Please take them if you use them. > > They all need minor version bumps, and some have outstanding bugs and > GitHub > pull requests. > > acct-group/nm-openconnect > acct-group/nm-openvpn > acct-user/nm-openconnect > acct-user/nm-openvpn > net-vpn/networkmanager-openconnect > net-vpn/networkmanager-openvpn > net-vpn/networkmanager-pptp > net-vpn/networkmanager-vpnc I would appreciate if all of these had a different primary maintainer, but gnome@ stay as a secondary to do blind version bumps to, as we maintain networkmanager itself and there have been times we need to deal with their bumps to progress with main networkmanager packages. Personally I use networkmanager-openvpn occasionally, but can't test any of the others at runtime. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Deprecating repoman
Ühel kenal päeval, R, 11.03.2022 kell 21:53, kirjutas Joshua Kinard: > the extra checks that pkgcheck runs haven't really applied to me. Looks to be mostly true, as you maintain only a few packages, but you might find these links useful to filter the CI output per maintainer regardless: https://qa-reports.gentoo.org/output/gentoo-ci/output.html;maintainer=kumba https://qa-reports.gentoo.org/output/gentoo-ci/output.html;maintainer=kumba;include-projects Or some of these: https://packages.gentoo.org/maintainer/ku...@gentoo.org/stabilization https://packages.gentoo.org/maintainer/ku...@gentoo.org/outdated Mart
Re: [gentoo-dev] Deprecating repoman
Ühel kenal päeval, N, 10.03.2022 kell 18:18, kirjutas Joshua Kinard: > I stick to the officially-published method of checking and committing > changes: > https://devmanual.gentoo.org/ebuild-maintenance/git/index.html > > The two tools highlighted there for the bulk of the work is repoman > and pkgdev. repoman is cited twelve times, pkgdev is cited six > times. pkgcheck is mentioned once. pkgcommit has no mentions. > > From that, one should not be faulted for assuming that repoman is the > more important tool, if not preferred tool, with pkgdev coming in > second place. > pkgcheck comes across as entirely optional and even seems equivalent > to 'repoman full', and how would one know that pkgcommit even exists? I believe the very purpose of this thread is to have a consensus/pre- announcement before actually editing the official documentation as part of the process of deprecating repoman. > That all said, most of my checks are done pre-commit, not pre-push. > It's annoying trying to unwind a commit with a mistake in git, so I > aim to not have any in the commit itself. By the time I get to the > push stage, everything MUST be perfect before I hit 'git push'. > Cause once something is public, there's no going back. In a handful > of cases, I've gone as far as nuking my local copy of the tree, re- > cloning it, and re-doing everything again just to fix a mistake that > I should have caught pre-commit. git commit --amend, interactive rebase, etc (all before push). I suggest to learn them and embrace them. Re-cloning is not fun, just for something that a quick interactive rebase or even a git reset -- hard destructive operation instead of re-clone would solve. Also the benefit of using pkgcheck is to actually be able to make the same checks that CI would do before you push, so you can amend your commits to fix issues before they hit the server and CI and break the tree. pkgcheck is so fast that it can do full tree checks in a reasonable time (repoman would take days on a radiator mips when you go outside single package), and I believe has features to have it check all your commits that haven't been pushed yet at once, checking only what it can to not be too slow to not use (so you don't need to run the check with each commit but for all of them once you commit - and if issues, again, git interactive rebase). repoman does not catch many many QA issues that pkgcheck (and therefore CI) does. > How about making an edit to repoman to have it throw a deprecation > warning for itself and to install whatever we all agree should > replace it? I would think that's a natural next step after this thread, and why this thread exists. > > Mart
Re: [gentoo-dev] [PATCH] vala.eclass: Support EAPI 8
Ühel kenal päeval, K, 16.02.2022 kell 19:39, kirjutas Ulrich Müller: > Function vala_src_prepare did not call eapply_user, so it could not > be > used as a stand-alone phase function but must be called explicitly. > Rename it to vala_setup, which can be called either from pkg_setup or > from src_prepare. Just to clarify the reasons to drop the EXPORT - it's really about the fact that you can actually never use it automatically. Absolutely all packages that use vala.eclass need to define their own src_prepare in the ebuild anyways, in order to also call gnome_src_prepare, cmake_src_prepare, or xdg_src_prepare. So the exported phase had no value, as an ebuild author always needs to declare their own, so it's just confusing with the vala_src_prepare function naming from before. There may be some value in trying to do these steps in an exported pkg_setup instead, similar to the python eclasses (and what vala.eclass does is very similar to what the python eclasses do). But I fear it would just clash with python_pkg_setup then instead in many cases, as we get a lot of python-any-r1.eclass inheriting lately in meson + vala packages due to the python-exec[-native-symlinks] tinderbox runs. Though things are slowly moving away from needing this (meson added a gnome postinstall step that takes care of it natively, instead of needing custom python postinst scripts), so it'll probably get rarer to need python-any-r1 + vala together and a vala_pkg_setup might be of good value. Anyhow, enough of my rambling here. If someone would like to explore this option, great. If not, I think we should just get it to EAPI-8 with these changes and revisit with EAPI-9. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Ühel kenal päeval, N, 20.01.2022 kell 16:32, kirjutas Brian Evans: > On 1/17/2022 6:24 PM, Georgy Yakovlev wrote: > > Hi, > > > > I've been approached multiple times with that request, and a lot of > > time I see new users completely destroyed by rust build time and > > disk > > space requirements. > > > > I bet that the pending polkit merge request[1] (which is just about > ready and blessed but not merged by devs) would seriously drop many > people's concerns over rust. > > Using duktape on most systems will suffice for polkit once included. > > GNOME and Mozilla products still pull in spidermonkey but other users > will have a much reduced requirement for rust. librsvg, dev-python/cryptography (masked so far but eventually needs to move forard, albeit it looks like it won't have as big an impact as it once would have), probably rather more to come. Ühel kenal päeval, N, 20.01.2022 kell 20:01, kirjutas Michael Orlitzky: > Avoiding librsvg used to be difficult because it's required by our > GTK > icon packages to render PNGs from SVGs. Luckily dilfridge's binrepo > now makes it easy to download pre-rendered icons, and there's no > security/performance/legal concerns with pre-rendered PNGs, so using > them shouldn't present any moral dilemmata. You mainly just have to > replace Firefox, Thunderbird, and GIMP. And it is required on GTK itself to actually be able to render any SVG icons. I can not suggest avoiding librsvg with GTK, nor let such suggestions of such be uncountered. rust is a toolchain, just like GCC, and if you are running a source- based distribution, you get to have the toolchains required to compile from source. Anyhow, my vote is to default to rust-bin - people can easily be told to move to dev-lang/rust at their convenience and then explicitly depclean rust-bin. They can even use system-bootstrap on dev-lang/rust with rust-bin to do so, in some situations (~arch-only apparently). Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
Ühel kenal päeval, P, 26.12.2021 kell 10:50, kirjutas Michał Górny: > On Sun, 2021-12-26 at 09:44 +, Marek Szuba wrote: > > > > On 13 December 2021 17:24:18 UTC, Mart Raudsepp > > wrote: > > > > > Actually I kind of preferred a static name over straight mktemp, > > > because emktemp supported other cases than a pure mktemp usage > > > does. > > > But I don't know if it could ever clash things in some weird > > > situations. > > > > That last part is the message I tried to convey in my e-mail, sorry > > if I wasn't clear enough. > > > > Anyway, could anyone with more Postage/PMS experience weigh in on > > this? If it is indeed safe then the eclass could be modified > > further, e.g. to use static names with EAPI-8+ but stick with > > mktemp for older EAPIs just to be safe. > > I suppose it's not specified strictly but T should be safe for all > sane > uses. If it weren't, we'd already be in deep trouble and gnome2- > utils > would be the least of our concerns. > > That said, making this EAPI-conditional is just an unnecessary > complexity. It's already hardcoded to $T via using mktemp instead of emktemp (which supported lack of $T or mktemp utility, unlike the replacement that was merged) - so if $T and mktemp is guaranteed, we are good there. It was introduced with mktemp in the first place and then vapier changed it to emktemp without any reason given beyond probably just doing it for everything to support lack of mktemp on the system or some such. Now the question was, can we hardcode the name instead - is it possible for it to be running things in parallel and clash on the name, e.g.: * postinst and postrm ran at the same time on replacement: is it doing ._unmerge dir in portage an implementation detail that we shouldn't rely on it? * postinst and/or postrm ran with multilib support: could they be running in parallel in the future for the different ABIs -- should we include the ABI in the static filename at least to avoid clashes there? Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
Ühel kenal päeval, E, 13.12.2021 kell 10:19, kirjutas Marek Szuba: > On 2021-12-09 15:04, Michał Górny wrote: > > > Why do you need to use random name in the first place? We have > > full > > control over T, so why not just hardcode a good name? > > Having discussed the matter with eclass maintainers on IRC, they are > not > entirely sure whether using a static name in this context is entirely > safe. There were also concerns about making this change too > aggressive > given it affects all supported EAPIs. Therefore, we have decided to > play > it safe and stick as closely to old behaviour as possible, at least > for now. > > Anyway, merged a moment ago. Actually I kind of preferred a static name over straight mktemp, because emktemp supported other cases than a pure mktemp usage does. But I don't know if it could ever clash things in some weird situations. I think they won't, but I don't know if PMS guarantees that or just happens how portage works right now (e.g. the postrm currently happening in a separate ._unmerge directory path for $T; multilib postinst happening sequentially, etc). Thinking it through again a bit, straight mktemp can't be worse than a static name anyways (provided mktemp exists, which emktemp handled..), so we're good there, but provided you or someone thinks through the corner-cases, I'm in favor of a static name if it doesn't have any trouble. Mart signature.asc Description: This is a digitally signed message part
[gentoo-dev] XDG_DATA_DIRS handling under packages
Hello, Unlike most other XDG base directories[1], we do not do anything with XDG_DATA_DIRS - not in xdg_environment_reset, nor in ENV_UNSET. This is now causing some issues. Historically there was an issue[2] where a package added XDG_DATA_DIRS via env.d, which meant that if the base package (x11-misc/xdg-utils) wasn't yet installed, XDG_DATA_DIRS was set, but did not include the default paths, which broke some things as demonstrated there. Now there is an issue[3] where another package prepends other paths, which are not accessible when sandboxed and some tests are trying to access them. In my case, I'm now hitting this with flatpak, which prepends these paths via profile.d instead (and does have correct handling of the default dirs if XDG_DATA_DIRS was previously unset). This is a fundamental thing, so just unsetting it only in that package feels rather incomplete. I would think that the correct fix would be add XDG_DATA_DIRS to ENV_UNSET and also unsetting it in xdg_environment_reset (for the benefit of older EAPIs), but I fear that in some cases we specifically do need it to see what variables are in there. Perhaps prefix. If that's the case, per-ebuild unsetting could be problematic for those cases as well. Or is there some way to avoid such use cases of XDG_DATA_DIRS additions to not reach the portage environment in the first place? Thoughts? Mart 1. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html 2. https://bugs.gentoo.org/635040 3. https://bugs.gentoo.org/701978 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2] xdg.eclass: add EAPI 8 support
Ühel kenal päeval, K, 21.07.2021 kell 17:08, kirjutas Florian Schmaus: > Note that this removes the export of src_prepare in EPAI 8 as > requested by ionen: > > 1. remove src_prepare export in EAPI-8 > > While "some" packages need xdg_environment_reset, most don't > because > the eclass is often only inherited to handle icons/.desktop and > this > just needlessly overwrite the src_prepare of other eclasses > requiring > more careful inherit ordering (e.g. inherit xdg cmake). > > I'd prefer it was clear when a package need this by calling > xdg_environment_reset directly. Unless there is a non-trivial > amount > of packages that need it (e.g. for tests) that I'm not aware of. asturm asked me to reply here if I think the changes are in the spirit of xdg.eclass, so.. I'm not sure about the spirit, but I personally am fine with the changes, after the technical nitpicks are figured out in the thread here. I do not like at all that we'll need to remember about calling xdg_environment_reset sometimes, but the status quo of clashing with other eclasses src_prepare export is probably worse. And you needing this reset call or not is not at all immediately obvious - it causing trouble may only happen during test suite run, for example, when XDG_RUNTIME_DIR is written to, or something else ends up causing writes to it. Basically ENV_UNSET was a great start, but does not completely address our XDG env reset needs and it'd be great if someone championed a full solution for EAPI-9 or something. I'm starting to think the easiest is to just make the xdg_environment_reset call unconditionally in meson.eclass src_configure like cmake.eclass does, and forget all about this for almost all possible cases. That rant aside, I'm happy in spirit with the changes as proposed here. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About the 'eapi' file in profile directories
Ühel kenal päeval, P, 01.08.2021 kell 00:58, kirjutas Joshua Kinard: > numeric value of the supported EAPI EAPI isn't a numeric value, it is a string (section 3.1.8) - it just happens that Gentoo official ones are logically numeric. PMS even quotes the EAPIs in "2.2 Defined EAPIs" section to signify that, it seems. So s/numeric value/name/ as per PMS section 5.2.2? Mart
Re: [gentoo-dev] [PATCH] xdg.eclass: add EAPI 8 support
Ühel kenal päeval, N, 15.07.2021 kell 14:03, kirjutas Ulrich Mueller:
> > > > > > On Thu, 15 Jul 2021, Florian Schmaus wrote:
>
> > -DEPEND="
> > +_XDG_DEPEND="
> > dev-util/desktop-file-utils
> > x11-misc/shared-mime-info
> > "
> > +
> > +case "${EAPI:-0}" in
> > + 4|5|6|7)
> > + DEPEND="${_XDG_DEPEND}"
> > + ;;
> > + *)
> > + IDEPEND="${_XDG_DEPEND}"
> > + ;;
> > +esac
>
> If it is IDEPEND in EAPI 8 (i.e. an install-time dependency which
> applies to pkg_postinst etc.), then presumably the best approximation
> in other EAPIs would be RDEPEND:
> https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-720008.1
>
> Think about installion of a binpkg where DEPEND won't be pulled in.
Changing where it is for old EAPIs is presumably not the subject of
this patchset. DEPEND is where it was before, and DEPEND is where it
should remain after. I'm aware of the incorrectness, but RDEPEND has
its other problems for these deps - this is why IDEPEND exists now.
As this is not the purpose of this patch, we shouldn't dwelve into this
subject further - EAPI-8 is here now to fix this.
Mart
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/2] python-utils-r1.eclass: Enable hardlinking of identical pyc files for py3.9+
Ühel kenal päeval, K, 23.06.2021 kell 11:56, kirjutas Michał Górny: > > - python*|pypy3) > > + python3.[5678]|pypy3) > > We don't really support < 3.8 anymore but I can update that while > merging, I guess. Yeah, this is originating from the previous block having python3.[34], so the changeset is making sure the 3.9 and 3.10 cases end up using the added path, not about 3.5/3.6, for which the code path is kept the same with this. I don't foresee myself working on making distutils cases work with this anytime soon. Maybe we should file a bug on that. It's a bit surprising this wasn't done there too upstream, I guess those who made this change only cared about it for python itself and they are running compileall manually over all the caches. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: Enable parallel bytecompile compilation
Ühel kenal päeval, K, 23.06.2021 kell 11:43, kirjutas Agostino Sarubbo: > On mercoledì 23 giugno 2021 11:36:33 CEST Mart Raudsepp wrote: > > + jobs=$(( nproc + 1 )) > > I don't know who historically started the nproc+1 story (it looks to > be in the > handbook too), but it has been demonstrated that nproc+1 is slower > than nproc. This is a copy of what distutils-r1.eclass is doing. Mart signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: Enable parallel bytecompile compilation
Python 3.5 added support for compileall to run parallel workers for
performing bytecode compilation. Make use of it to the extent
possible without refactoring the code too much to get different
paths into the same call for best possible parallelization.
---
eclass/python-utils-r1.eclass | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index e2f05606993..f7a38f8c4e0 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -34,7 +34,7 @@ fi
if [[ ! ${_PYTHON_UTILS_R1} ]]; then
-inherit toolchain-funcs
+inherit multiprocessing toolchain-funcs
# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
# @INTERNAL
@@ -615,6 +615,12 @@ python_optimize() {
debug-print "${FUNCNAME}: using sys.path: ${*/%/;}"
fi
+ local jobs=$(makeopts_jobs "${MAKEOPTS}" INF)
+ if [[ ${jobs} == INF ]]; then
+ local nproc=$(get_nproc)
+ jobs=$(( nproc + 1 ))
+ fi
+
local d
for d; do
# make sure to get a nice path without //
@@ -628,12 +634,12 @@ python_optimize() {
;;
python3.[5678]|pypy3)
# both levels of optimization are separate
since 3.5
- "${PYTHON}" -m compileall -q -f -d
"${instpath}" "${d}"
- "${PYTHON}" -O -m compileall -q -f -d
"${instpath}" "${d}"
- "${PYTHON}" -OO -m compileall -q -f -d
"${instpath}" "${d}"
+ "${PYTHON}" -m compileall -j "${jobs}" -q -f -d
"${instpath}" "${d}"
+ "${PYTHON}" -O -m compileall -j "${jobs}" -q -f
-d "${instpath}" "${d}"
+ "${PYTHON}" -OO -m compileall -j "${jobs}" -q
-f -d "${instpath}" "${d}"
;;
python*)
- "${PYTHON}" -m compileall -o 0 -o 1 -o 2
--hardlink-dupes -q -f -d "${instpath}" "${d}"
+ "${PYTHON}" -m compileall -j "${jobs}" -o 0 -o
1 -o 2 --hardlink-dupes -q -f -d "${instpath}" "${d}"
;;
*)
"${PYTHON}" -m compileall -q -f -d
"${instpath}" "${d}"
[gentoo-dev] [PATCH 1/2] python-utils-r1.eclass: Enable hardlinking of identical pyc files for py3.9+
Python 3.9 includes a new feature for compileall to automatically hardlink
different optimization level cache files if they are identical. Make use of it
for python_optimize for some space savings.
This however does not cover distutils use cases and python itself.
---
eclass/python-utils-r1.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Note that I haven't actually tested this on py3.9, as I'm skipping that version.
It appears to do what it's meant to with py3.10
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 3dbf221eac5..e2f05606993 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -626,12 +626,15 @@ python_optimize() {
"${PYTHON}" -m compileall -q -f -d
"${instpath}" "${d}"
"${PYTHON}" -OO -m compileall -q -f -d
"${instpath}" "${d}"
;;
- python*|pypy3)
+ python3.[5678]|pypy3)
# both levels of optimization are separate
since 3.5
"${PYTHON}" -m compileall -q -f -d
"${instpath}" "${d}"
"${PYTHON}" -O -m compileall -q -f -d
"${instpath}" "${d}"
"${PYTHON}" -OO -m compileall -q -f -d
"${instpath}" "${d}"
;;
+ python*)
+ "${PYTHON}" -m compileall -o 0 -o 1 -o 2
--hardlink-dupes -q -f -d "${instpath}" "${d}"
+ ;;
*)
"${PYTHON}" -m compileall -q -f -d
"${instpath}" "${d}"
;;
Re: [gentoo-dev] [PATCH] gstreamer-meson.eclass: New eclass required for gstreamer-1.18.0+
Ü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+
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]
Ü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
Ü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
Ü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@
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
Ü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
Ü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
Ü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
# 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
Ü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
Ü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
Ü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
Ü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
Ü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
Ü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
Ü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
Ü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
> @@ -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
# 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
Ü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
Ü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
Ü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]
See also this related old thread: https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09211
[gentoo-dev] Last rites: dev-libs/btparser
# 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
Ü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
# 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?
Ü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
Ü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
Ü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
Ü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
Ü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
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
Ü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
# 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
Ü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
# 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
Ü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
Ü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
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?
Ü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
Ü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
Ü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
# 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
Ü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
Ü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
Ü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
Ü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
# 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
# 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?
Ü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
Ü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
Ü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]
Ü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]
Ü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
Ü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
Ü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
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
Ü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
Ü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
Ü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
Ü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
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
Ü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
Ü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
Ü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
Ü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
Ü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,...
Ü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
# 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
