Re: [gentoo-dev] Last rites: leechcraft
On 01/31/2017 09:08 AM, David Seifert wrote: > On Tue, 2017-01-31 at 17:34 +0100, Kristian Fiskerstrand wrote: >> On 01/31/2017 03:50 PM, Georg Rudoy wrote: >>> I'll make a new release of leechcraft itself and bump the version >>> to >>> that new one, so they'll naturally be dropped to unstable, 0.6.70 >>> and >>> earlier (if any) indeed could be removed. Most of the bugs, as I >>> saw >>> them, are due to the current last released version being 2.5 years >>> old >>> and obviously bitrotten somewhat since then. >> >> I'd still recommend spending a bit of time to consider whether this >> doesn't fit better in an overlay, which would also make it easier to >> maintain without overburdening proxy maint given the number of >> packages >> involved. >> > > I really second this - we can ask infra to get you an overlay. Should > it turn out that you are truly maintaining stuff, we can then merge it > into the tree. > I'd like to third it. Overlays are a great way for people (users and devs alike) to try their hand maintaining their own Portage tree. It's great practice and it gives you a single place to reference for people who are using your ebuilds. If it gets formally into layman, I believe our bugzy will cover you, too, in case you don't want to use github. I'd ask infra just to be sure. Overlays for Gentoo are comparable to Debian's and Ubuntu's PPAs and are similarly simple to install/use/delete. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
. Their was a GSoC project > last summer to work on organizing gentooish kernel builds, but that is a > very big topic. Perhaps the profiles will have to be proposed but not > formalized until folks go out and do some kernel builds and testing > associated with a proposed profile organization? afaik building the kernel is completely outside of Portage's reach. It merely installs the source files needed to build it. Everything else is up to you and/or genkernel. A special kernel fork designed for embedded sounds good, though. I'm sure we've got something like that in the tree (or an overlay) somewhere. > > >> In the same way, we shouldn't be too quick to deviate from upstream >> defaults ourselves (#4 in your example), beyond actual integration >> work. > >> I'll admit the current state is a bit of a compromise, but I don't >> think we should change it unless we're changing it to something >> significantly better. This is a pretty big-impact change. > > > Just formalize some new parts of the profile tree to not be required to > be upstream compliant. Isn't that part of being a 'meta-distribution'? Don't we already do that? KDE, GNOME, and XFCE aren't "upstream" compliant because there *isn't* a single, default upstream DE, so we have profiles for that. If you or others would like to create or improve existing profiles, then that's awesome and you should try to put together some patches or a pull request so we can take a look. > > In my future (and the future of many others) there will be minimalistic > builds on clusters where any number to constructs including > compatibility which will all be solved, at the framework level, not the > base distro level, to the extent possible. Folks are now running a > myriad of windows OS versions on linux (&clusters), so I have just read > about a few days ago. So I'm proposing and working on gentoo > heterogeneous cluster where one can partition part to be for systemd > stuffage, part to be HPC, part to be extraordinarily secure, part to be > aligned with a particularly commercial linux distro, and many other > differing needs based frameworks. > > > The minimal (lowest level) should be clear of all of those distro > encumbrances. CoreOS is taking this approach, as their bare metal > bootstrapping occurs completely and well before systemd or any other > PID1 schema is invoked or becomes a defacto requirement. Gentoo is all > about freedom, right? If we need a new profile, then certainly those who are going to use it should be best equipped to know what needs to be in it, right? This is a great case for building what you need and then sharing it so everyone can benefit. I don't do embedded (though I might tinker with it some day), so I'm definitely not able to know what needs to be in such a profile. We need people who actually work in that sort of stuff to do the work, because if someone like me does it, then it may have too many packages in it, or it won't account for X or Y use case that's super common in embedded, etc. Embedded is an itch, and non-embedded Gentoo people can't scratch it for you because we aren't qualified. If you or others ever manage to make that profile, please share it so others can benefit too. :) > > > hth, > James > Thanks for reading, zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/04/2017 01:05 PM, William L. Thomson Jr. wrote: >[snip] >> Maintainers of individual packages have the most knowledge about how to >> best deliver that specific package, but maintainers of profiles have >> the best understanding of what people want to see. > > Yes has to be a balance. I do not believe package maintainers will always > share the vision of the profiles. > > Said another way, if defaults were sane enough, would profiles be necessary? > > Profiles are kind of an extra added benefit to the end user, and those making > the profiles. Mostly a benefit for the end user. There isn't much benefit to > the > package maintainer. I could not really see anything that would give them > reason to spend their time on something that would not benefit them. > I can't speak for other maintainers but generally if there's an issue in an ebuild I maintain, I try to figure out a) the specific problem, and b) the simplest and most-effective solution. If an ebuild I maintain is broken on arm64, for example, it's still my responsibility to figure out how to get it working, assuming the software was written in a way to allow for that build anyway. Since I don't run anything other than amd64 right now, I have to depend on others to find issues for other arches. Generally I'll accept any change as long as it meets our ebuild standards and doesn't exchange one problem for another. One could argue "of course it benefits you", but I don't do it because it benefits me. I do it because a) it fixes a problem I probably didn't know about and b) it's how we make Gentoo better. I don't have an opinion on profiles. I like the idea of them and respect the work that goes into them. If maintainers need to make small changes here or there so their packages work on specific profiles, I don't see the problem. We do commit+push over typos; a profile is more important than that, so naturally we should have little issue ironing out support when the errant wrinkle comes up. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 02:09 PM, William L. Thomson Jr. wrote: > On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote: >> On 02/03/2017 01:33 PM, Patrick McLean wrote: >>> We might as well go back to before IUSE defaults then. Part of the >>> advantage of IUSE defaults is maintainers don't all have to fiddle with >>> the profiles, everything can be self-contained in the ebuild. This >>> drastically complicates maintenance, having two locations to track and >>> change rather than just one. >> >> You still retain the benefit for IUSE defaults that actually belong in >> the base profile, just not for upstream defaults or the ones that you >> personally prefer. > > That is a side effect, as it is more about the package maintainer choosing > the > defaults. They are not messing with profiles. That base ends up with it is > indirect. Otherwise IUSE default flags would have to be per profile rather > than > in the package. Which would create more work for package maintainers. > >>> I suspect that there is a small subset >>> of people interested in this, and perhaps those people could maintain a >>> "minimal" profile that unsets IUSE defaults. >> >> Then every IUSE default gets recorded twice: once when the maintainer >> puts it in the ebuild, and once when I add it (negated) to the minimal >> profile. That's a bad design even if we pretend that I can solve the >> problem of tracking every IUSE change in the tree. > > Sorry if its been suggested, I haven't followed every comment. What about > some > global env variable that could override all default IUSE. That can set in > base, and set what ever minimal IUSE flags that are needed. > I support the idea of a profile-set variable that determines whether or not IUSE is respected. Minimalists get their systems faster, we get something that adds to Gentoo's versatility and an additional profile. Of course, we should be asking the anti-IUSE people if that would be good enough to make the profiles/systems they want possible. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/09/2017 12:25 PM, Ben Kohler wrote: > > > On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell <mailto:z...@gentoo.org>> wrote: > > I support the idea of a profile-set variable that determines whether or > not IUSE is respected. Minimalists get their systems faster, we get > something that adds to Gentoo's versatility and an additional profile. > Of course, we should be asking the anti-IUSE people if that would be > good enough to make the profiles/systems they want possible. > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net <http://keys.gnupg.net> > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 > > Can't this already be accomplished by modifying the USE_ORDER variable? > > -Ben That's a great question. Based on a cursory look at make.conf's manpage, USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended. So if we change that from what I assume to be the default (found in the manpage), a minimalist profile (or system) should be using: USE_ORDER = "env:pkg:conf:defaults:repo:env.d" If that gets combined with a profile meant explicitly for this bare-bones use case, then I don't see why we can't make that happen. It just requires someone who knows the use case to build the profile. Thanks for pointing this out! -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/09/2017 12:59 PM, Michael Orlitzky wrote: > On 02/09/2017 03:41 PM, Daniel Campbell wrote: >> That's a great question. Based on a cursory look at make.conf's manpage, >> USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended. >> > > This has already been suggested like five times =P > > So long as people insist on using IUSE defaults for flags that are > critical to the package and to satisfy REQUIRED_USE (sprinkled liberally > throughout the tree), this won't work. You'll turn off the defaults that > are critical, too, and throw a wrench into dependency resolution. > > (Just noticed that after I finished reading the thread; d'oh) Hm, good point. A good number of us are against REQUIRED_USE (I don't feel strongly either way), and I'm really not sure why we have packages that won't work at all without specific USE flags. Now that I've read the entire thread I see someone mentioned different arches may need different USE flags, but that seems like something that belongs in the profile, *if* it's a profile problem. I'd be happy if REQUIRED_USE conflicts were handled in one of two ways: 1. emerge throws it up in your face and suggests a change (defaulting to whichever IUSE has a +), which can then be handled with etc-update or 2. emerge prompts you to choose a flag from the ones listed in REQUIRED_USE, obeys it, then does #1 so you can etc-update after merging. The downside to this is it's yet another function to add to emerge. I'm not sure how else we can make use of REQUIRED_USE while simultaneously allowing people the choice to not care. Could an eclass do this reliably? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs: x11-misc/ktsuss
On 01/25/2017 01:17 PM, Gokturk Yuksek wrote: > The following package is up for grabs: > > x11-misc/ktsuss > I can take this; I use it with SpaceFM to do things as root. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ABI Navigator — a project to search for binary symbols
On 02/23/2017 06:36 PM, Andrey Ponomarenko wrote: > Hello, > > I'd like to present a new project called "ABI Navigator" for searching binary > symbols (functions, methods, global data, etc.) in open-source libraries: > https://abi-laboratory.pro/index.php?view=navigator > > The project allows to find out in which versions of libraries some symbol is > defined, added, removed or changed. The data is taken from the ABI Tracker > project (238 libraries and 0.9 million symbols currently): > https://abi-laboratory.pro/tracker/ > > Example for symbol dwelf_strtab_add from libdw.so (elfutils): > https://abi-laboratory.pro/index.php?view=navigator&selected=dwelf_strtab_add%40%40ELFUTILS_0.167#result > > The project aims to help Linux developers and maintainers to resolve issues > with missed symbols and navigate through the reports in the ABI Tracker. > > Have you ever encountered the "undefined reference" error or want to know > whether the symbol is _stable_ enough to use in your code? Try to find it in > the ABI Navigator! > > Enjoy! > This tool didn't return anything on a quick test (TOX_CONFERENCE_TYPE, part of net-libs/tox, TokTok/toxcore on GitHub), but it did it quickly and it has a clean interface. I'll definitely try using this when I find myself stumped on something. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Suggested sync method/Portage config for devs on ~arch?
Ever since we switched to Git, I've tried to use gentoo.git (or a mirror) to sync from. I later found a configuration that hasufell used at the time. [1] It works well so far, but I wanted to ask the greater developer community what method(s) they employ to sync from our repositories and why it's a good fit for them. I'm hoping that this discussion may lead to suggestions we can put in the devmanual or other documentation to make the "transition" to a developer smoother for new staff, or simply make it easier for our users to be close to the bleeding edge, if that's what they desire. So, for a developer/user using ~arch, what do you use and/or recommend for Portage configuration? Thanks for reading. [1]: https://github.com/hasufell/portage-gentoo-git-config -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] app-portage/eclass-manpages: Add @SUPPORTED_EAPIS tag for eclass
On 04/28/2017 07:06 AM, Michał Górny wrote:
> Add a @SUPPORTED_EAPIS tag that can be used to explicitly provide a list
> of EAPIs that are supported by the eclass. The main goal is to make it
> possible to extract this list with relative ease, for scripting
> purposes. It is not included explicitly in the manpages at the moment.
>
> The first use case is to make it possible to explicitly distinguish
> eclasses that do not support a specific EAPI from eclasses that are not
> used by any ebuilds using a specific EAPI. Therefore, it will make it
> possible to easily detect when we can deprecate old EAPIs from eclasses.
> ---
> app-portage/eclass-manpages/files/eclass-to-manpage.awk | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> b/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> index 0b65162c04ec..fe7e9c12d8f5 100644
> --- a/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> +++ b/app-portage/eclass-manpages/files/eclass-to-manpage.awk
> @@ -18,6 +18,7 @@
> # # default: tell people to use bugs.gentoo.org>
> # @VCSURL: https://gitweb.gentoo.org/repo/gentoo.git/log/eclass/@ECLASS@>
> +# @SUPPORTED_EAPIS:
> # @BLURB:
> # @DESCRIPTION:
> #
> @@ -147,6 +148,7 @@ function handle_eclass() {
> eclass = $3
> eclass_maintainer = ""
> eclass_author = ""
> + supported_eapis = ""
> blurb = ""
> desc = ""
> example = ""
> @@ -176,6 +178,8 @@ function handle_eclass() {
> reporting_bugs = eat_paragraph()
> if ($2 == "@VCSURL:")
> vcs_url = eat_line()
> + if ($2 == "@SUPPORTED_EAPIS:")
> + supported_eapis = eat_line()
> if ($2 == "@BLURB:")
> blurb = eat_line()
> if ($2 == "@DESCRIPTION:")
>
Looks like something eclass developers could really use. I say go for
it! I'm not sure what you're talking about regarding _ vs. -; do you
mean the variable name? I think _ makes a bit more sense there since we
use INSTALL_MASK, PYTHON_SINGLE_TARGET, or other variable names with
underscores. Using a hyphen would make it stick out from other similarly
structured variable names.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Removal of rxvt
On 05/11/2017 08:57 AM, Jason A. Donenfeld wrote: > Hi folks, > > Rxvt is ancient. It's been replace by rxvt-unicode. Rxvt hasn't seen > updates in years. Recently it's been the subject of a security > vulnerability, and I suspect it's filled with other potential > vulnerabilities. Rxvt has no upstream. I tried reaching out to the > former upstream, and it's evident everybody has moved on and has no > interest in further maintenance. It doesn't even have a Gentoo > maintainer! > > Given this, I'd like to remove rxvt from Gentoo, with the usual > mask-for-30-days process. > > Does anybody have any objections to me doing this? (I'll wait a week > from now before taking any actions.) > > Regards, > Jason > Sounds sane to me. It might be helpful to ask if anyone in gentoo-user is interested in proxying, but as far as I know anyone who used rxvt migrated to rxvt-unicode once it was stable. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On 05/11/2017 12:51 AM, Michał Górny wrote: > In fact, I'm personally leaning towards not building docs at all > in ebuilds. It's practically a wasted effort since most of the time > users read docs online anyway. I believe that's a little myopic; a user (or even developer) may not have Internet access all the time, or may not have it in their primary development environment. Having a copy of the docs locally (the entire point of USE="doc") is super valuable to have when you're away from the network. I'm sure I'm not alone as one of the people who uses the flag and appreciates the work that goes into making sure said flag works. Sure, we could yank out every single USE="doc", but then we lose a nice feature of the tree and users are back to either (a) trawling the Web to find the project site, then hope they have docs in a separate download, or (b) we end up with foo+1 packages, one extra for any package that has documentation. Neither are particularly good solutions; Debian has done the latter and it results in a huge number of packages for little gain. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote: > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote: > > On 05/11/2017 12:51 AM, Michał Górny wrote: > > > In fact, I'm personally leaning towards not building docs at all > > > in ebuilds. It's practically a wasted effort since most of the time > > > users read docs online anyway. > > > > I believe that's a little myopic; a user (or even developer) may not > > have Internet access all the time, or may not have it in their primary > > development environment. Having a copy of the docs locally (the entire > > point of USE="doc") is super valuable to have when you're away from the > > network. I'm sure I'm not alone as one of the people who uses the flag > > and appreciates the work that goes into making sure said flag works. > > > > Sure, we could yank out every single USE="doc", but then we lose a nice > > feature of the tree and users are back to either (a) trawling the Web to > > find the project site, then hope they have docs in a separate download, > > or (b) we end up with foo+1 packages, one extra for any package that has > > documentation. Neither are particularly good solutions; Debian has done > > the latter and it results in a huge number of packages for little gain. > > The Python team mostly focuses on providing packages for dependencies of > other Gentoo packages, not direct Python development. We do not have > the manpower to go above that. > > -- > Best regards, > Michał Górny Ah, well that at least explains why you're not interested in it. Dependency management alone can be tough; I've not noticed any Python issues, so it seems like you guys do well. :) If you don't mind me asking, what would it take to solve the USE="doc" issue to the Python team's standard? I have some personal interest in Python and wouldn't mind adding 'doc' support for Python packages that users request docs for. Maybe others are willing to join me on this. Is that something we can make happen without getting in anyone's hair? ~zlg signature.asc Description: Digital signature
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On Fri, May 12, 2017 at 08:32:53PM +0200, Michał Górny wrote:
> On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote:
> > DEPEND=( doc?
> > || (
> > (
> > dev-python/sphinx[python_targets_python2_7]
> > # NOTE This packages provide extensions for Sphinx
> > dev-python/rst-linker[python_targets_python2_7]
> > dev-python/jaraco-packaging[python_targets_python2_7]
> > )
> > (
> > dev-python/sphinx[python_targets_python3_5]
> > dev-python/rst-linker[python_targets_python3_5]
> > dev-python/jaraco-packaging[python_targets_python3_5]
> > )
> > (
> > dev-python/sphinx[python_targets_python3_6]
> > dev-python/rst-linker[python_targets_python3_6]
> > dev-python/jaraco-packaging[python_targets_python3_6]
> > )
> > )
> > )
> >
>
> One more thing I've missed in my initial mail. The other problem with
> this solution (alone) is that it doesn't enforce the implementation that
> satisfied the dependency.
>
> Let's take a simple example. You've built sphinx for 2.7+3.5 but rst-
> linker and jaraco-packaging for 3.5 only. The dependency is satisfied
> because the 3.5 branch matches. However, you have no rule to enforce
> 3.5, so sphinx could be actually called with 2.7 and fail.
>
> This is a generic problem that was pretty much solved by python-any-r1.
> I think we should be able to copy the most important pieces of the API
> to python-r1 to achieve something similar, i.e. add python_gen_any_dep
> to generate the depstrings and make python_setup aware of
> python_check_deps(). Then the above would be written alike:
>
> DEPEND="doc? ( $(python_gen_any_dep '
> dev-python/sphinx[${PYTHON_USEDEP}]
> dev-python/rst-linker[${PYTHON_USEDEP}]
> dev-python/jaraco-packaging[${PYTHON_USEDEP}]
> ') )"
>
> python_check_deps() {
> has_version "dev-python/sphinx[${PYTHON_USEDEP}]" &&
> has_version "dev-python/rst-linker[${PYTHON_USEDEP}]" &&
> has_version "dev-python/jaraco-packaging[${PYTHON_USEDEP}]"
> }
>
> python_setup would verify which implementation has the dependencies
> satisfied, and set it for the common code building docs.
>
> However:
>
> 1. I think it would work. However, I can't be sure until I implement it,
> and even then I might miss something.
>
> 2. It's a significant extension to the API, and kinda goes against
> the goal of making the eclass simpler. However, it mostly fits what is
> in python-any-r1 already, so at least it doesn't introduce a new API.
>
> So I'd like others to chime in and let me know whether they consider
> this a worthwhile addition before I start working on it.
>
> --
> Best regards,
> Michał Górny
Would this bloat python-r1 too much? I understand the need to keep
eclasses small and efficient. This looks like it might work, and I'm
willing to test it, though I'd need some time to learn how to properly
test Python packages. Is #gentoo-python a good place to seek guidance,
after looking through docs?
Is this a unique-enough case to justify a python-doc eclass? It looks
like it would depend on python-any* or python-r* anyway, so maybe it's a
bit redundant. It's an option, though.
I hadn't considered the dependency <-> implementation relationship; nice
catch! If what you wrote above is as clean as we can get it, I'm
willing to help you on it. I'm just not sure how I'd be most helpful
since I've never written an eclass.
signature.asc
Description: Digital signature
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On 05/18/2017 03:30 PM, Michał Górny wrote:
> On czw, 2017-05-18 at 15:07 -0700, Daniel Campbell wrote:
>> On Fri, May 12, 2017 at 08:32:53PM +0200, Michał Górny wrote:
>>> On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote:
>>>> DEPEND=( doc?
>>>> || (
>>>> (
>>>> dev-python/sphinx[python_targets_python2_7]
>>>> # NOTE This packages provide extensions for Sphinx
>>>> dev-python/rst-linker[python_targets_python2_7]
>>>> dev-python/jaraco-packaging[python_targets_python2_7]
>>>> )
>>>> (
>>>> dev-python/sphinx[python_targets_python3_5]
>>>> dev-python/rst-linker[python_targets_python3_5]
>>>> dev-python/jaraco-packaging[python_targets_python3_5]
>>>> )
>>>> (
>>>> dev-python/sphinx[python_targets_python3_6]
>>>> dev-python/rst-linker[python_targets_python3_6]
>>>> dev-python/jaraco-packaging[python_targets_python3_6]
>>>> )
>>>> )
>>>> )
>>>>
>>>
>>> One more thing I've missed in my initial mail. The other problem with
>>> this solution (alone) is that it doesn't enforce the implementation that
>>> satisfied the dependency.
>>>
>>> Let's take a simple example. You've built sphinx for 2.7+3.5 but rst-
>>> linker and jaraco-packaging for 3.5 only. The dependency is satisfied
>>> because the 3.5 branch matches. However, you have no rule to enforce
>>> 3.5, so sphinx could be actually called with 2.7 and fail.
>>>
>>> This is a generic problem that was pretty much solved by python-any-r1.
>>> I think we should be able to copy the most important pieces of the API
>>> to python-r1 to achieve something similar, i.e. add python_gen_any_dep
>>> to generate the depstrings and make python_setup aware of
>>> python_check_deps(). Then the above would be written alike:
>>>
>>> DEPEND="doc? ( $(python_gen_any_dep '
>>> dev-python/sphinx[${PYTHON_USEDEP}]
>>> dev-python/rst-linker[${PYTHON_USEDEP}]
>>> dev-python/jaraco-packaging[${PYTHON_USEDEP}]
>>> ') )"
>>>
>>> python_check_deps() {
>>> has_version "dev-python/sphinx[${PYTHON_USEDEP}]" &&
>>> has_version "dev-python/rst-linker[${PYTHON_USEDEP}]" &&
>>> has_version "dev-python/jaraco-packaging[${PYTHON_USEDEP}]"
>>> }
>>>
>>> python_setup would verify which implementation has the dependencies
>>> satisfied, and set it for the common code building docs.
>>>
>>> However:
>>>
>>> 1. I think it would work. However, I can't be sure until I implement it,
>>> and even then I might miss something.
>>>
>>> 2. It's a significant extension to the API, and kinda goes against
>>> the goal of making the eclass simpler. However, it mostly fits what is
>>> in python-any-r1 already, so at least it doesn't introduce a new API.
>>>
>>> So I'd like others to chime in and let me know whether they consider
>>> this a worthwhile addition before I start working on it.
>>>
>>> --
>>> Best regards,
>>> Michał Górny
>>
>> Would this bloat python-r1 too much? I understand the need to keep
>> eclasses small and efficient. This looks like it might work, and I'm
>> willing to test it, though I'd need some time to learn how to properly
>> test Python packages. Is #gentoo-python a good place to seek guidance,
>> after looking through docs?
>
> That's the problem I'm most worried of. On the other hand, it's pretty
> much what we have in python-any-r1 already, so expect for physical code
> increase, we're mostly just extending an existing API into additional
> eclass.
>
>> Is this a unique-enough case to justify a python-doc eclass? It looks
>> like it would depend on python-any* or python-r* anyway, so maybe it's a
>> bit redundant. It's an option, though.
>
> I don't think so. It's a complex problem with many different
> implementation details. Even if we wrote an eclass, it would either do
> confusingly little, or have more conditionals than code.
>
>>
>> I hadn't considered the dependency <-> implementation relationship; nice
>> catch! If what you wrote above is as clean as we can get it, I'm
>> willing to help you on it. I'm just not sure how I'd be most helpful
>> since I've never written an eclass.
>
> No need to do that. As I said, it's mostly copy-paste from python-any-r1
> with little changes. I'll get to that soon enough.
>
>
Sounds great; given its simplicity I'm sure we can wait a little while.
Thanks for reconsidering. If there's anything I can do to help, please
let me know.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list
On 05/23/2017 12:31 PM, Michał Górny wrote: > [snip] > Your comments? > Since it's adding a list instead of warping an existing one, I say go ahead on the condition that everything important finds its way to a more open list. I'm subscribed to enough as it is. I am skeptical that it will lead to an improved social experience among Gentoo developers, but also willing to be proven wrong. Personally, there's nothing that attracts me to the idea. I don't really like the concept of curating a mailing list. But seeing as the point of the list is to lessen the volume of messages, it will likely succeed. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCHES] python-r1.eclass: any-of dep API support
On 05/20/2017 06:30 AM, Michał Górny wrote: > > > Please review. > > -- > Best regards, > Michał Górny > > It looks much as you mentioned it'd be: moving code around and cutting down duplication. Looks good to me. I really appreciate the example in patch 7, which makes it a little more clear how to use it. Thanks for putting all of this together. I'm not sure how to express this because I don't know which question to ask. Is there anything I can help with once this gets committed? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] NeoVim and vim-syntax
On 05/31/2017 03:54 PM, Ciaran McCreesh wrote: > On Thu, 01 Jun 2017 02:32:24 +0700 > "Vadim A. Misbakh-Soloviov" wrote: >> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all >> the installed files >> >> - patching NeoVim source to include Vim's runtimedirs (incl. "after" >> dir), // NeoVim upstream highly disagree with such way, if any >> >> - patching VIMRUNTIME environment variable, >> >> - making a wrapper, >> >> - rewrite all the existing ebuilds to take nvim into account and >> force all newcomers to also take it, >> >> - symlinking a directory, >> // mostly bad way, since opposite plugin compatibility is not >> garanteed and users can install nvim-only plugins in the future >> >> - making postinst hook to regenerate content of NeoVim's >> site-directory (maybe, by symlinking installed vim modules there) >> >> or even: >> >> - making eselect module for user to rule that. > > - Have a separate anyvimishthing directory, and make both vim and > neovim look there, and only make plugins that have been tested to work > with both install to that directory. > +1, though it's still important to keep nvim- and vim-specific dirs. A third, common dir cuts down on the work that other solutions would need. It would also give users a way to check which plugins will work with 'the other one' too and can use that to decide whether they want to make the switch. This information can probably be gleaned on their own with some detective work on the Web, but choosing this path gives the accidental feature for free. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml
On 06/01/2017 06:09 PM, Kent Fredric wrote: > On Thu, 1 Jun 2017 23:18:22 +0200 > Jonas Stein wrote: > >> A space separated list of the corresponding debian packages should be >> written in the field >> > > Why space separated? > > Its already legal to specify the field multiple times, and it should > work better that way for consistency with things that can already parse > XML. > > That way there's no need to put an additional parser inside our XML > extraction. > > libfoo > libfoo-debug > > No? > > It also means general purpose XML formatting tools can keep it tidy, > _and_ sorted, without having to reinvent new tools. > +1. Otherwise sounds good. But if we do this for Debian, will there be movement to add in package names for rpm-based distros? Arch? BSD? Slackware? Where do we draw the line? Will developers be expected to treat this like a mandated element? If not, which team will have authority to touch package metadata to make this change? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml
On 06/01/2017 11:59 PM, Kent Fredric wrote: > On Thu, 1 Jun 2017 18:36:24 -0700 > Daniel Campbell wrote: > >> +1. Otherwise sounds good. But if we do this for Debian, will there be >> movement to add in package names for rpm-based distros? Arch? BSD? >> Slackware? Where do we draw the line? > > I'd say "as need be". Here we have a few extra benefits from using a > debian identifier that aren't strictly related to "package mapping". > > Its also easier for third party services to use our use of debian > identifiers to produce the other mappings for us where known ( that is, > non-gentoo entities can maintain a mapping of debian-to-foo, and we can > trivially hook into that by using the debian-id as the identifer ) > >> Will developers be expected to treat this like a mandated element? > > I'd imagine not, given not everything in debian exists in gentoo, or > vice versa. > > Similarly, I don't think there are any mandates that the other values > of remote-id be populated, only that its *encouraged* because that data > provides utility to an end user. > >> If >> not, which team will have authority to touch package metadata to make >> this change? > > I'd suggest it should stay within the controls of the package > maintainer for starters, where individual maintainers can provision it > as they feel fit, and we can review our stance on this later if we want > to make it a tree wide consistent thing. > > Partly because individual maintainers are more likely to understand > correctly how equivalent their dists are to the referenced debian one, > and be more equipped to decide whether to include/exclude a given ref. > That sounds very reasonable to me. Thanks for clarifying. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] fdo-mime.eclass: Mark the eclass as deprecated
On 06/19/2017 06:20 AM, Michał Górny wrote: > The GNOME team has committed the xdg-utils.eclass serving exactly > the same purpose as fdo-mime.eclass, supposedly with the goal of > replacing it. However, it seems that they have never bothered to > actually hint the deprecation in the fdo-mime.eclass in any way. > As a result, developers are still adding references to this eclass > instead of using xdg-utils or xdg, and/or not working towards replacing > them. > > Add an explicit deprecation notice to the fdo-mime.eclass to make it > clear that the eclass should not be used in new packages, and what > the replacement eclasses are. > --- > eclass/fdo-mime.eclass | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/eclass/fdo-mime.eclass b/eclass/fdo-mime.eclass > index b3b096d154e7..8e51d8a69df1 100644 > --- a/eclass/fdo-mime.eclass > +++ b/eclass/fdo-mime.eclass > @@ -1,4 +1,4 @@ > -# Copyright 1999-2011 Gentoo Foundation > +# Copyright 1999-2017 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > > # @ECLASS: fdo-mime.eclass > @@ -7,6 +7,8 @@ > # @AUTHOR: > # Original author: foser > # @BLURB: Utility eclass to update the desktop mime info as laid out in the > freedesktop specs & implementations > +# @DESCRIPTION: > +# This eclass is DEPRECATED. Please use xdg-utils or xdg instead. > > # @FUNCTION: fdo-mime_desktop_database_update > # @DESCRIPTION: > Looks good to me. Thanks for looking out for stuff like this. That aside, isn't this supposed to be standard operating procedure if a developer is deprecating an eclass? And similarly with the removal of an eclass, all ebuilds getting updated by the developer or team that prompted the removal of the eclass? My apologies if this is answered elsewhere. I want to be sure what's expected, just in case I need to touch an eclass. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 06/20/2017 05:53 AM, Pacho Ramos wrote: > This packages are now up for grabs: > dev-ml/fort > media-libs/embree > x11-wm/i3 > > I use i3-gaps these days, but if no-one else is willing, I'll take up i3 since it's close enough to i3-gaps to be considered mostly the same. Dual maintainership is preferred. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream
On 06/23/2017 09:28 AM, Anthony G. Basile wrote: > Hi everyone, > > Since late April, grsecurity upstream has stop making their patches > available publicly. Without going into details, the reason for their > decision revolves around disputes about how their patches were being > (ab)used. > > Since the grsecurity patch formed the main core of our hardened-sources > kernel, their decision has serious repercussions for the Hardened Gentoo > project. I will no longer be able to support hardened-sources and will > have to eventually mask and remove it from the tree. > > Hardened Gentoo has two sides to it, kernel hardening (done via > hardened-sources) and toolchain/executable hardening. The two are > interrelated but independent enough that toolchain hardening can > continue on its own. The hardened kernel, however, provided PaX > protection for executables and this will be lost. We did a lot of work > to properly maintain PaX markings in our package management system and > there was no part of Gentoo that wasn't touched by issues stemming from > PaX support. > > I waited two months before saying anything because the reasons were more > of a political nature than some technical issue. At this point, I think > its time to let the community know about the state of affairs with > hardened-sources. > > I can no longer get into the #grsecurity/OFTC channel (nothing personal, > they kicked everyone), and so I have not spoken to spengler or pipacs. > I don't know if they will ever release grsecurity patches again. > > My plan then is as follows. I'll wait one more month and then send out > a news item and later mask hardened-sources for removal. I don't > recommend we remove any of the machinery from Gentoo that deals with PaX > markings. > > I welcome feedback. > Thanks for taking the time to let the greater Gentoo community know. It's a shame things took this turn... Is there any hope of a fork emerging from the drama? Why would a security-conscious group take their toys and go home? Regardless, this is a loss for Linux as a whole. I hope something springs up in its place. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints
On 07/08/2017 02:43 AM, Michał Górny wrote: > Hi, everyone. > > I think the affairs have settled enough and I've finished filling > in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all > the algorithms, rationale and separated reference implementation. > > If there are no major concerns raised, I will soon start working > on writing an optimized implementation for pkgcore/pkgcheck > and integrating the verification algos with the CI. > > The pre-GLEP for review is here: > > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse > > TIA. > This has grown quite a bit since first recommended! Great job so far. Forgive me if I missed something, but wouldn't it be helpful to the user to let them know when automatically choosing for them? A single line in a logfile, einfo output, whatever, would be useful for people wondering how certain packages got pulled in. Users will continue to get errors if the constraints aren't met (or are wrong), but where will information go that indicates the automatic solver's choice? You and I can read an ebuild and guess from the dep spec, but what will a user look at? I searched the GLEP page for "log", "einfo", and "output" with no results. If I've missed something please let me know. Thanks for the work that's been put into this so far. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints
On 07/08/2017 03:29 PM, Michał Górny wrote: > On sob, 2017-07-08 at 15:21 -0700, Daniel Campbell wrote: >> On 07/08/2017 02:43 AM, Michał Górny wrote: >>> Hi, everyone. >>> >>> I think the affairs have settled enough and I've finished filling >>> in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all >>> the algorithms, rationale and separated reference implementation. >>> >>> If there are no major concerns raised, I will soon start working >>> on writing an optimized implementation for pkgcore/pkgcheck >>> and integrating the verification algos with the CI. >>> >>> The pre-GLEP for review is here: >>> >>> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse >>> >>> TIA. >>> >> >> This has grown quite a bit since first recommended! Great job so far. >> Forgive me if I missed something, but wouldn't it be helpful to the user >> to let them know when automatically choosing for them? A single line in >> a logfile, einfo output, whatever, would be useful for people wondering >> how certain packages got pulled in. Users will continue to get errors if >> the constraints aren't met (or are wrong), but where will information go >> that indicates the automatic solver's choice? You and I can read an >> ebuild and guess from the dep spec, but what will a user look at? >> >> I searched the GLEP page for "log", "einfo", and "output" with no >> results. If I've missed something please let me know. >> >> Thanks for the work that's been put into this so far. >> > > Indeed I have entirely skipped the user output problem, and left it > purely for package manager's design choice. Do you really feel like we > need to explicitly specify it? I think it's best if package manager > authors decide how to best fit it into whatever output the PMs already > have. > > I just considered it helpful, that's all. I hadn't considered the PMS vs. PM devs perspective. Do we plan to support some way for users to get such output from Portage? Thanks for clarifying. It does make more sense to leave it to PM devs. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Sets vs Meta ebuilds
On 07/08/2017 06:23 PM, William L. Thomson Jr. wrote: > On Sun, 9 Jul 2017 01:10:11 +0100 > Ciaran McCreesh wrote: > >> On Sat, 8 Jul 2017 19:58:13 -0400 >> "William L. Thomson Jr." wrote: >>> On Sun, 9 Jul 2017 00:49:57 +0100 >>> Ciaran McCreesh wrote: >>>> On Sat, 8 Jul 2017 19:39:33 -0400 >>>> "William L. Thomson Jr." wrote: >>>>> The two ways are not the same, and there is a reason sets exist >>>>> in the first place. People seem to be over looking that fact. I >>>>> did not add sets. They are not new. I am simply trying to >>>>> expand their use. >>>> >>>> Sets exist because people keep saying "let's have sets!" without >>>> agreeing on what sets actually are or how they are to be used. >>> >>> Do they need to agree? Isn't Gentoo about choice? Maybe your use of >>> sets is different from mine. Is that not acceptable to have >>> choice? >> >> Well yes, they do need to agree, because otherwise when two different >> developers put sets in a profile expecting different effects, then at >> least two developers are going to end up confused, disappointed, and >> quite probably breaking user systems. > > Valid points, so basically need a set of guidelines or rules for sets > used in profiles. Which should not be that complex, as usage is minimal. > Offhand, likely could be more; > > - Sets used in profiles are "lists of packages" for users to > emerge/re-emerge, and as such should be minimal list only. Similar to > the contents of a profile/packages, less the * symbol. > > - Sets used in profiles cannot have use expansion, versions or anything >beyond cat/pkg. This would break some set behavior, at least in Portage. Specifying a single version (or better, a slot) in a set is less work than adding lines to p.mask *and* the set file(s), and p.mask doesn't appear to support "!=cat/pkg-1.0" syntax to mimic the same functionality achieved by a versioned atom in a set. It also makes sense to put packages you want in a set instead of a mask. ">=" or "<=" may be adequate if you only want one slot or version installed, but the entire point of slots is to allow multiple versions to be installed simultaneously. Versioned package names in sets achieve this. > > - Sets should not have the same file listed, in that case inherit the > other set if using overlapping packages or split into smaller > -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Sets vs Meta ebuilds
On 07/09/2017 06:53 AM, William L. Thomson Jr. wrote: > On Sun, 9 Jul 2017 00:42:46 -0700 > Daniel Campbell wrote: > >>> - Sets used in profiles cannot have use expansion, versions or >>> anything beyond cat/pkg. >> This would break some set behavior, at least in Portage. Specifying a >> single version (or better, a slot) in a set is less work than adding >> lines to p.mask *and* the set file(s), and p.mask doesn't appear to >> support "!=cat/pkg-1.0" syntax to mimic the same functionality >> achieved by a versioned atom in a set. It also makes sense to put >> packages you want in a set instead of a mask. ">=" or "<=" may be >> adequate if you only want one slot or version installed, but the >> entire point of slots is to allow multiple versions to be installed >> simultaneously. Versioned package names in sets achieve this. > > Valid point, and along those lines to make the rules for sets in > profiles easier. > > - Sets in profiles can contain anything that is valid in a > profile/packages file, less the * symbol. > > I think that addresses both versions and slots. The rest, like use > expansion I believe is handled via package.use in profiles and not in > packages. > Yeah, that could work. As convenient as it is to mix USE flags with sets, there's a better place to put it and I'm unsure of any situation that would require more than two lines (one in the set, one in p.use) to achieve a given USE constraint. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] taking a break from arches stabilization
On 07/10/2017 10:22 AM, Agostino Sarubbo wrote: > Hi all. > > every time that I attach my tmux session to see what happens on irc, I always > see the same discussion about the 'minor' arches status. > Since I joined gentoo(2011) I worked on all arches except hppa, I put more > effort in amd64 and less where I saw other people work on it (arm,alpha) > But every time the magic phrase is that those arches are unmaintained. > > Now, since I work on these arches just to help, i.e. I don't have any > business > and I do non have any installation of those arches and the work I'm doing is > not appreciated at all I decided to stop for now. > If your dream is to put sparc and ia64 to ~arch, go ahead, I have no > objections. > I will take a break also from amd64 and x86...let's see how things will > change. > Thanks for your efforts in stabilization. I try to make it a point to thank people like you and Toralf since stabilization and arch testing are both time-consuming, and probably frustrating to get the tooling correct. Take some time off! I'm sure Gentoo won't implode. :) -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote: > On Mon, 10 Jul 2017 19:22:47 -0400 > "William L. Thomson Jr." wrote: >> >> That part does not require it to resolve deps. Just check world file, >> assuming its correct. Though could be thrown off if say gcc, or >> another was in the world file. I think the profile or set would catch >> that as it does now and generate a warning, regardless. > > Speaking of gcc in the world file. I think portage should STOP adding > packages that are in the profile or a dep to world. If you merge a > package as part of a set, I am pretty sure it does not get recorded to > world, need to confirm, could be wrong. > > A rule for portage could be; > > - If the package is not in world and already installed. Do not add the >package to world. If you are re-emerging a package already >installed. You do not have to use the -1 option. > > I have polluted so many world files with system packages and/or > dependencies I re-emerged directly without -1. Those IMHO should never > have been recorded to that file. They were brought in by other things. > Only things in my world should be packages merged directly, not from > profile, set, or a dep. > > I will file a bug on that as well. > Whether Portage adds a package to a set or world file is dependent on how you invoke emerge. Some people (like me) include sets as part of their world, via /var/lib/portage/world_sets . At that point, sets added to that file are basically treated as the world package list. If gcc or other @system packages end up in your world, it's not Portage's fault. If you don't want a package added to a set or world, you'll need to use the -1 (--oneshot) option. I added it to my default emerge options in make.conf for exactly that reason (clean world); though, I have to be careful and make sure packages I care about are in a set somewhere or --depclean will wipe'em out. In short, Portage won't stop you from shooting yourself in the foot. If you decide you want to add a package to world without re-merging it, -n (--noreplace) will do the job. I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will catch a @system atom inside a set/world file, but that's where I'd expect such a notification to come from. The tool can help clean up unneeded entries in /etc/portage files, and would be a good fit for this particular issue. That said, having helpful messages is a good addition, but needs to be done in a way that is unambiguous and gives the user a clear solution. Hope this helps, zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 07/11/2017 01:27 PM, Daniel Campbell wrote: > On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote: >> On Mon, 10 Jul 2017 19:22:47 -0400 >> "William L. Thomson Jr." wrote: >>> >>> That part does not require it to resolve deps. Just check world file, >>> assuming its correct. Though could be thrown off if say gcc, or >>> another was in the world file. I think the profile or set would catch >>> that as it does now and generate a warning, regardless. >> >> Speaking of gcc in the world file. I think portage should STOP adding >> packages that are in the profile or a dep to world. If you merge a >> package as part of a set, I am pretty sure it does not get recorded to >> world, need to confirm, could be wrong. >> >> A rule for portage could be; >> >> - If the package is not in world and already installed. Do not add the >>package to world. If you are re-emerging a package already >>installed. You do not have to use the -1 option. >> >> I have polluted so many world files with system packages and/or >> dependencies I re-emerged directly without -1. Those IMHO should never >> have been recorded to that file. They were brought in by other things. >> Only things in my world should be packages merged directly, not from >> profile, set, or a dep. >> >> I will file a bug on that as well. >> > Whether Portage adds a package to a set or world file is dependent on > how you invoke emerge. Some people (like me) include sets as part of > their world, via /var/lib/portage/world_sets . At that point, sets added > to that file are basically treated as the world package list. > > If gcc or other @system packages end up in your world, it's not > Portage's fault. If you don't want a package added to a set or world, > you'll need to use the -1 (--oneshot) option. I added it to my default > emerge options in make.conf for exactly that reason (clean world); > though, I have to be careful and make sure packages I care about are in > a set somewhere or --depclean will wipe'em out. In short, Portage won't > stop you from shooting yourself in the foot. > > If you decide you want to add a package to world without re-merging it, > -n (--noreplace) will do the job. > > I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will > catch a @system atom inside a set/world file, but that's where I'd > expect such a notification to come from. The tool can help clean up > unneeded entries in /etc/portage files, and would be a good fit for this > particular issue. > > That said, having helpful messages is a good addition, but needs to be > done in a way that is unambiguous and gives the user a clear solution. > > Hope this helps, > > zlg > Whoops. s/gentoolkit/eix/ Sorry for the spam. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 07/11/2017 01:57 PM, William L. Thomson Jr. wrote: > On Tue, 11 Jul 2017 13:27:57 -0700 > Daniel Campbell wrote: > >> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote: >>> On Mon, 10 Jul 2017 19:22:47 -0400 >> >>> A rule for portage could be; >>> >>> - If the package is not in world and already installed. Do not add >>> the package to world. If you are re-emerging a package already >>>installed. You do not have to use the -1 option. >>> >>> I have polluted so many world files with system packages and/or >>> dependencies I re-emerged directly without -1. Those IMHO should >>> never have been recorded to that file. They were brought in by >>> other things. Only things in my world should be packages merged >>> directly, not from profile, set, or a dep. > >> Portage's fault. If you don't want a package added to a set or world, >> you'll need to use the -1 (--oneshot) option. > > Did you even read above? I clearly state WITHOUT -1 option > >> I added it to my default >> emerge options in make.conf for exactly that reason (clean world); > > The point is people should not have to do such. Or remember to always > use -1 when re-emerging a dep, system, world, or set package. > >> though, I have to be careful and make sure packages I care about are >> in a set somewhere or --depclean will wipe'em out. In short, Portage >> won't stop you from shooting yourself in the foot. > > If those package are in your world file portage will not remove on > depclean. > >> If you decide you want to add a package to world without re-merging >> it, -n (--noreplace) will do the job. > > Or you can add it to the world file, or your profile/packages > in /etc/portage, etc. There are other places, one does not have to > emerge every package then want in world. Just the same it should not > add stuff just the same from system, world, sets, or deps of any of > those 3. > >> That said, having helpful messages is a good addition, but needs to be >> done in a way that is unambiguous and gives the user a clear solution. > > So now it must be clear to the user? That is the entire point I am > making. The output now is not clear... But in improving such now there > is concern over something no one cares about now Funny stuff!!! > I understand where you're coming from, I just thought to give a few tips to make life a bit easier for you since it works out pretty well for myself. I think your idea has merit, just unsure of where the functionality goes, since I'm not a Portage developer. I think the hard part of implementing this will be detecting whether a command-line-given package is (a) in a set/profile/world and (b) part of a dependency tree (i.e. shouldn't be removed). -c already traverses the dependency tree. This one message may mean iterating through the list of candidate packages and comparing them against a set/profile/world *per package*, unless the vdb/cache makes this lookup cheap in terms of cycles. The message would be helpful, though again, eix-test-obsolete might be the right tool to build that feature into. I'd be interested in following the bug discussion, if you've already filed it. If you're really interested in the message from -C, it could be done by checking the argument list for packages in sets or profiles. But it's going to incur similar overhead that -c has because it necessarily has to check some sort of list before producing the message. I do not think this message belongs in -C output, however; -C is intentionally meant for operations where you don't care what happens to the dependency tree. Sometimes that's good (resolving a blocker the hard way), sometimes it's bad (removing gcc on a whim). Warnings won't stop a user doing that, because --unmerge is already documented with the caveat. There must be a certain point where we as developers have to say "You're on your own," or there will be so many rails and training wheels that it loses value for the more experienced users, or a bunch of bugs filed over failing to heed documentation, i.e. PEBKAC. I think -C is a great place to draw that line. The best way to get the ball rolling is file a feature request against Portage and see what 'upstream' has to say. In the meantime, maybe try your hand at hacking it. I've found people are a lot more receptive to suggestions when you've already attempted to provide it. Even if the solution is crap, people seem willing to help those who have the gumption to help themselves. Please don't interpret this e-mail as aggressive or dismissive. I'm simply trying to offer explanation and guidance to help you make this happen. It's clear that you care about it, so I'm sure there's a way for this to go forward. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] vim-syntax USE flag
On 07/22/2017 01:27 PM, Mike Gilbert wrote: > Packages currently handle installation of vim syntax support files > inconsistently. Some builds install the files if the "vim-syntax" USE > flag is enabled, while others install them unconditionally. > > Do these files fall into the "small text files" category for > unconditional installation? If so, we should probably phase out the > vim-syntax USE flag. > > If we want to keep the USE flag, I would suggest documenting a global > policy regarding its use. Should that live in the devmanual? Or maybe > the Vim project page? > I agree, a global policy should be established; whether it's "install unconditionally" like we do with systemd units, openrc daemons, etc, or a global USE. I'm unaware of any way to misinterpret what "vim-syntax" means, and Vim itself already has a place it expects such files to go. Installing a package without this USE flag requires a rebuild to get the syntax file(s), so that's another reason to go unconditional. I have the USE flag set globally and it hasn't created any blockers, so maybe it's safe. As for where documentation goes, I would expect a brief paragraph in the devmanual mentioning the USE flag and linking to the Vim project page that better explains usage and expectations. That way, changes in the Vim project's way of development wouldn't require big rewrites in the devmanual. If we're shipping syntax for other editors as well, perhaps it's deserving of its own devmanual page. Do we have a problem with developers not shipping syntax files? (vim or otherwise) --semi-offtopic-- When I first began using Gentoo in 2012, I was annoyed that Vim remembered my cursor position for every file I opened. It took some hunting to locate where this was set (/etc/vim/vimrc, owned by app-editors/vim-core for the curious) and correct it with g:leave_my_cursor_position_alone = 1 in my vimrc. If we could document Gentoo-added Vim features like that, it'd be less trouble for our newer users to configure Vim to their tastes. I understand we're not a newbie distro, but unexpected behavior can be a PITA to track down without documentation or trawling through `:script` output. Searching the Web, our wiki, and even our GitHub account turned up zero helpful results for this particular thing. If the Vim team needs the help, I'd be glad to lend a hand where needed. (also cc'ing vim@ to get an official opinion) -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On 07/25/2017 06:22 AM, Rich Freeman wrote: > On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka > wrote: >> >> The 30 day waiting period is useful for smoking out major upstream bugs, >> but can't replace stabilisation integration testing. For example, >> package foobar may build fine in ~arch but fails in stable because it >> needs a newer libbaz. >> > > I think this is a good reason why everything should be at least > build-tested on a stable tree before getting stabilized. Now, that > might not be on each arch if it is truly arch-independent (and if > arches keep the dependencies reasonably in sync). > > This might be a situation where a compromise could exist. Have some > kind of flag (in metadata, or maybe the ebuild) that indicates that > the maintainer believes the package is low-risk to stabilize purely on > a build test. Then after 30 days in testing a tinderbox could > build-test the package and stabilize it automatically. > > If the package is considered at-risk then it goes through manual > testing, either by the maintainer or an arch team. > > This will also encourage the teams doing testing to actually do more > testing on the packages that would benefit from it. > > We wouldn't set hard criteria but leave it up to maintainer > discretion, with a guideline being that past performance is probably a > good predictor of future results. > This reads like a practical use of both developer time and machine time. Build testing at a minimum, imo, is necessary if the word "stable" is going to mean anything for us. So +1. Since there are bound to be fewer manually tested packages than automatic "it builds, ship it" packages, I think it would make a bit more sense to add a "manually test this please" tag to metadata.xml, rather than expect auto-stabilizers to have additional tags, which will outnumber the manual packages and inflate the size of the tree (albeit slightly). Since maintainers also manage their packages in various ways, could we extend this to a general element? Maintainers can specify how they'd prefer bugs or commits to be done, and an additional element to indicate hand-testing. This would solve two problems instead of just one: indicate a package is ready for auto-stabilization, and give a single, canonical location for a maintainer to put maintenance policy. Just my 2¢, ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
On 07/26/2017 10:05 AM, Kristian Fiskerstrand wrote: > On 07/25/2017 02:28 PM, Michael Palimaka wrote: >> Does a bug # really need to always be in the summary line? It can eat >> valuable characters and tags which are pretty popular are equally valid IMO. > > I would prefer the summary to be informative without having bug ID at > all. Summary should describe the change ,not only "fixes XXX", the bug > reference belongs in body (tags) > +1. I tend to add bug numbers in my summary, but it makes it very challenging to put something meaningful into the remaining characters. We already put 'category/pkg:' or 'dir/file:' for a prefix. Adding 6 or 7 characters to that already considerable deficit cuts ~15% of git's recommended 50 characters, or 10% of our proposed 70. Pushing this out to a tag -- and standardizing it -- will only improve maintenance and speed up our onboarding process. "Bug: xx" isn't my favorite since it requires tooling to actually visit said bug (and doesn't clarify which bug platform to reference), but a URL uses more bytes and infra may change. It's a tough choice, but if we can find something that fits enough use cases, tooling shouldn't be too difficult to write to make up for it. I already use a `bgo` keyworded shortcut in Pale Moon to make bug searching faster; adding another to navigate straight to a bug wouldn't be much trouble. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On 07/28/2017 12:44 PM, Alec Warner wrote: > > > On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel > mailto:dilfri...@gentoo.org>> wrote: > > Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge: > > > > I hold a perhaps radical view: I would like to simply remove stable. > > > > I continue to feel that maintaining two worlds (stable+unstable) > > carries with it an unneccessary cost. > > > > That's not feasible. It would kill off any semi-professional or > professional > Gentoo use, where a minimum of stability is required. > > > So my argument (for years) has been that this is the right thing all along. > > If people want a stable Gentoo, fork it and maintain it downstream of > the rambunctious rolling distro. > > > > (Try keeping ~10 machines on stable running without automation. > That's already > quite some work. Now try the same with ~arch. Now imagine you're > talking about > 100 or 1000 machines.) > > -- > Andreas K. Hüttel > dilfri...@gentoo.org <mailto:dilfri...@gentoo.org> > Gentoo Linux developer (council, perl, libreoffice) > > Why would we replicate that when Arch has been in that cavalier role for over a decade? Stability is important to all users; some simply have a lower tolerance for faults. It also gives us a reliable "product" for others to rely on or even dogfood. I personally run on ~arch, but if I were to put a friend on Gentoo, I'd want something that will be pretty easy-going until they learn the skills to take on ~arch, bug reports, etc. For many -- especially developers -- stable is only a letter away from "stale", and that's fine. Some run mixed keywords, or go full ~arch. One of the core values of Gentoo is choice; why take away the stable choice? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs
On 07/23/2017 07:13 AM, Manuel Rüger wrote: > The following packages are up for grabs: > > app-admin/gixy > app-admin/mei-amt-check > app-admin/ngxtop > app-admin/passwordsafe > app-arch/lz5 > app-crypt/acme > app-crypt/certbot > app-crypt/certbot-apache > app-crypt/certbot-nginx > app-crypt/easy-rsa > app-crypt/libmd > app-crypt/manuale > app-crypt/pgpdump > app-emulation/docker-gc > app-misc/jira-cli > app-misc/pdfpc > app-text/blahtexml > app-text/itex2mml > app-text/mathtex > dev-go/cli > dev-go/delve > dev-go/go-gitlab-client > dev-go/glide > dev-go/toml > dev-python/parsley > dev-python/safety > dev-python/txsocksx > dev-python/vcversioner > dev-libs/libgit2 > dev-lua/luadbi > dev-lua/luasocket > dev-lua/lua-zlib > dev-util/bloaty > dev-util/cookiecutter > net-analyzer/linkchecker > net-libs/libssh2 > net-misc/kafkacat > x11-misc/flow-pomodoro > x11-plugins/pidgin-opensteamworks > x11-plugins/pidgin-xmpp-receipts > > There is another set of packages, which have a backup project > maintaining it. Please talk to the respective project if you're > interested in maintaining those: > > app-office/texstudio > dev-python/cookies > dev-python/freezegun > dev-python/future > dev-python/hiro > dev-python/hvac > dev-python/parsedatetime > dev-python/parsley > dev-python/pyhcl > dev-python/pykka > dev-python/pyrfc3339 > dev-python/pytest-capturelog > dev-python/pytest-localserver > dev-python/responses > dev-python/vcrpy > dev-python/zope-component > dev-python/zope-event > net-firewall/nftables > net-libs/libnftnl > > Best regards, > Manuel Rüger > > I have a machine using certbot (Rpi 3 Model B) now that I might be switching to Gentoo in the future. I'd be willing to co-maintain app-crypt/certbot with other interested developers. The catch is I don't use Apache or nginx; others would need to maintain certbot-apache and certbot-nginx. Anyone interested? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs
On 07/19/2017 02:33 AM, Amy Liffey wrote: > The following package is up for grabs: > > dev-lang/gforth > > Best regards, > Amy Liffey > I can take this one; I'd hate to see Forth support go missing on Gentoo. I'm open to co-maintainers as well. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs
On 08/06/2017 02:27 AM, tom...@gentoo.org wrote: > Quoting Daniel Campbell (2017-07-31 04:16:30) >> On 07/19/2017 02:33 AM, Amy Liffey wrote: >>> The following package is up for grabs: >>> >>> dev-lang/gforth >>> >>> Best regards, >>> Amy Liffey >>> >> I can take this one; I'd hate to see Forth support go missing on Gentoo. >> I'm open to co-maintainers as well. >> > Ok, as I have done some quite Forth programming in the past, let me step in. > > Thomas > >> ~zlg >> >> -- >> Daniel Campbell - Gentoo Developer >> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net >> fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 >> > > Sounds great. Would you like me to do the honors of updating metadata.xml later tonight? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Revisions for USE flag changes
On 08/13/2017 03:11 AM, Michael Orlitzky wrote: > On 08/12/2017 10:52 PM, Duncan wrote: >> >> How so? Are you arguing that deciding to system-wide switch to/from >> pulseaudio, systemd, or gstreamer is nonsense? >> > > The meaning of any one USE flag varies widely across packages. I could > never say "I want to enable USE=gstreamer" for every package in the > tree, because I have no idea what it does for most of them. Setting > USE=whatever globally essentially means "make random changes to my > system" -- hence my wording. > > The meaning of a USE flag is per-package, so per-package is the only > meaningful way to set them. > There are USE flag situations that are relevant at the global level. systemd, pulseaudio, alsa, gstreamer, openssl/libressl, libav/ffmpeg, vim-syntax, and so on. Then there's USE_EXPAND variables, which might mean different things in different packages and yet I see nothing in your argument covering them. These flags make perfect sense at the global level, because users generally want support for the choices they make, and they make choices on that *general* level first, before diving into package-specific USE flags. It's a monumental waste of developer and user time to manually set major USE flags in every relevant package. Some people are picky and will still do that, but global USE ensures that certain assumptions are made about your system. If you don't want assumptions, don't use global USE. There's no reason to deprive others of functionality you don't personally agree with or use. Granted, some flags don't belong in make.conf. But part of Gentoo's beauty is that we *do* let users proverbially saw their leg off, if that's what they really want. There are lots of use cases that would be made ridiculous in scope if we got rid of global USE. Is your only answer a megabyte-long p.use file? That said, I like your idea of clearing up revbump decisions and the angle of reducing development burden. This particular idea comes at too high a cost for my taste, as we stand to lose functionality rather than improve or gain it. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing PMS to Portage Manager Specification
On 08/14/2017 03:39 PM, William L. Thomson Jr. wrote: > On Mon, 14 Aug 2017 15:20:26 -0700 > Rich Freeman wrote: > >> On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr. >> wrote: >>> >>> Portage supports sets, but the PMS has no mention. Then there is >>> debate on what they are. Creating so much noise it drowns the bug >>> request and makes it invalid. Despite the need still existing, and >>> PMS lacking anything on sets. >>> https://bugs.gentoo.org/show_bug.cgi?id=624300 >>> >>> Just the needs I have with portage are stalled, marked as invalid. >>> No discussion for inclusion in PMS. Like documenting sets. >> >> Ah, well, that's the main mystery of this thread solved. Thanks. > > That is the tip of the iceberg, not the main problem itself. I have > never been a fan of EAPI, or the resulting PMS, etc. Having been around > before such existed, I do not believe it has helped Gentoo and in fact > maybe the opposite. Why EAPI 0 stuff is in tree, or very old EAPIs. > > Now becoming more real issues rather than just a dislike of EAPI. > I'm unaware of any other way to introduce progressive changes to an API without literally rewriting every ebuild. Versioned APIs are good APIs, and give developers (both inside and outside Gentoo) something they can depend on and, most importantly, predict. If there was just one EAPI, you'd need to consult git log or some other construct to figure out the API version an ebuild was written against. The fact we still have older EAPI ebuilds is one of manpower and (dis)interest. I don't see anyone trying to prevent (or encourage) EAPI upgrading across the tree. Generally, we wait until a package needs a revbump/version bump and/or has serious breakage (and thus needing a rewrite) before bumping EAPI. Some jumps in EAPI, for simple packages, are painless. Others are a nightmare. I see no other way to support the 1m+ ebuilds that have been written since Gentoo's inception in an unambiguous, reference-able way. In fact, I'd argue if you don't version your APIs, you're not designing them correctly. APIs *will* change; building a version number into the API ensures the consumers of said API are aware of changes. That said, yes, it'd be nice if every ebuild was EAPI 6, but that is a hge amount of work that nobody seems interested in, for questionable gain. The work would just be repeated when the next EAPI is approved. The way it works now is more organic and better representative of the state of Gentoo development, for better or worse. It's good to see you taking part in constructive discussions! That's not intended as sarcasm. I mean it. Thanks for taking part. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New package neomutt
On 08/10/2017 01:10 AM, Michał Górny wrote: > On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote: >> On 10-08-2017 09:40:30 +0200, Michał Górny wrote: >>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote: >>>> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote: >>>>> Hi, >>>>> >>>>> I would like to add neomutt to the tree. This new package is meant as >>>>> an alternative and not a replacement of the existing mutt package. >>>> >>>> Thanks for all of the great suggestions and feedback! >>>> >>>> This is round two. I have update the ebuild with all your >>>> suggestions. I have also added support for eselecting between mutt >>>> and neomutt. Before the eselect ebuild can land though, we need to >>>> rename the mutt binary so that the managed link can be called >>>> mutt. >>> >>> What for? How many people are exactly in the dire need of having both >>> installed simultaneously and switching between them? If you really can't >>> learn to type the new command, add IUSE=symlink blocking original mutt >>> and be done with it. Don't add more unowned files to /usr by another >>> poorly written eselect module. >> >> Be nice! No need to be bitchy here (and in the rest of your review). >> Nicolas is just trying. >> >> Me, as maintainer of Mutt, thought it was a good idea, because it allows >> people to easily have both installed at the same time, which in this >> interesting time for both projects is not a weird thing to have. > > I don't see how eselect helps that. People can just run neomutt by > typing... neomutt, right? It works without the symlink, right? > >> If there is a policy/move to get rid of eselect, then sorry, I am not >> aware of that. I can live with a symlink USE-flag. It doesn't seem >> very elegant to me, but it would work for this scenario. >> > > The move is against orphaned files in /usr that are randomly changed by > runtime tools rather than the package manager. > Then how do we explain the reasoning for the other 50 or so eselect modules? No doubt at least a handful of them modify symlinks in /usr, and have similarly few options to choose from, such as eselect-vi. Should we remove those as well? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New package neomutt
On 08/17/2017 12:48 AM, Michał Górny wrote: > W dniu śro, 16.08.2017 o godzinie 22∶07 -0700, użytkownik Daniel > Campbell napisał: >> On 08/10/2017 01:10 AM, Michał Górny wrote: >>> On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote: >>>> On 10-08-2017 09:40:30 +0200, Michał Górny wrote: >>>>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote: >>>>>> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I would like to add neomutt to the tree. This new package is meant as >>>>>>> an alternative and not a replacement of the existing mutt package. >>>>>> >>>>>> Thanks for all of the great suggestions and feedback! >>>>>> >>>>>> This is round two. I have update the ebuild with all your >>>>>> suggestions. I have also added support for eselecting between mutt >>>>>> and neomutt. Before the eselect ebuild can land though, we need to >>>>>> rename the mutt binary so that the managed link can be called >>>>>> mutt. >>>>> >>>>> What for? How many people are exactly in the dire need of having both >>>>> installed simultaneously and switching between them? If you really can't >>>>> learn to type the new command, add IUSE=symlink blocking original mutt >>>>> and be done with it. Don't add more unowned files to /usr by another >>>>> poorly written eselect module. >>>> >>>> Be nice! No need to be bitchy here (and in the rest of your review). >>>> Nicolas is just trying. >>>> >>>> Me, as maintainer of Mutt, thought it was a good idea, because it allows >>>> people to easily have both installed at the same time, which in this >>>> interesting time for both projects is not a weird thing to have. >>> >>> I don't see how eselect helps that. People can just run neomutt by >>> typing... neomutt, right? It works without the symlink, right? >>> >>>> If there is a policy/move to get rid of eselect, then sorry, I am not >>>> aware of that. I can live with a symlink USE-flag. It doesn't seem >>>> very elegant to me, but it would work for this scenario. >>>> >>> >>> The move is against orphaned files in /usr that are randomly changed by >>> runtime tools rather than the package manager. >>> >> >> Then how do we explain the reasoning for the other 50 or so eselect >> modules? No doubt at least a handful of them modify symlinks in /usr, >> and have similarly few options to choose from, such as eselect-vi. >> Should we remove those as well? >> > > Mistakes of the past are no excuse to commit more mistakes. You should > know that because I had to repeat this many times. Some of the eselect > modules have been fixed since then giving major improvements (see: > eselect-opengl). > I can agree with that, but you seemed opposed to the entire idea of an eselect module for upstreams that own the same file; e.g. neomutt being a drop-in replacement for mutt. Are you instead opposing a cobbled-together eselect module? What would it take to ensure the RO /usr use-case could be supported while simultaneously allowing easy switching? Does eselect-opengl support RO /usr? If not, then it's a little unreasonable to expect other modules to do it since you pointed to it as a good example. What is your true opinion? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 09/09/2017 12:47 AM, Michał Górny wrote:
> W dniu pią, 08.09.2017 o godzinie 17∶19 -0400, użytkownik Rich Freeman
> napisał:
>> On Tue, Jul 25, 2017 at 4:05 AM, Michał Górny wrote:
>>>
>>> What do you think about it? Is there anything else that needs being
>>> covered?
>>>
>>
>> FYI - if anybody does want to make any comments on the proposed
>> devmanual changes to implement the new tags please comment at:
>>
>> https://github.com/gentoo/devmanual.gentoo.org/pull/72
>>
>> For that matter, if you want to even know what the proposed changes
>> are you should also visit the link.
>>
>> List replies seem to be discouraged.
>>
>> I realize that some prefer to limit comments to media that are purely
>> open source. I guess the FOSS Linux kernel provided /dev/null still
>> exists as an alternative. Honestly, I'm not sure which of the options
>> are more likely to get read.
>>
>
> TL;DR: Rich, I would really appreciate if you stopped the flamebaits.
> I understand that you think you're doing Gentoo a favor but you're not.
>
> The footers were discussed to death in this very thread. I've heard your
> opinions. However, as far as I'm concerned (and as I've pointed out) you
> did literally *nothing* to push your ideas forward for 2+ years.
>
> Since I've done all the work, I've did it my way and for the reasons
> I've explained multiple times. If you disagree, them I'm sorry but
> in life you don't get to have everything your way. Especially if all you
> do is complain and expect others to do the work for you.
>
> I understand that you're unhappy and since you have no valid arguments,
> all you can do is try to get more people to support you and shout.
> Revive the bikeshed as many times as possible, try to make a lot of
> noise and block changes. Worst case, you've blocked something you didn't
> like. Best case, you're finally get others so discouraged that they'll
> do things your way just so that you stop.
>
> Rich, this is not a kindergarten. It's time you learn to lose,
> and accept the consequences. If you can't do that, the door out is open,
> and you're free to leave anytime you want.
>
This behavior is not befitting Gentoo leadership. Limiting commentary to
a walled garden outside Gentoo control violates one of our goals
(independence), and the incendiary retorts are no more mature than the
behavior you're criticizing. Nothing will change in the way people
respond to you until you learn how to treat others.
By all means, I'm glad we're seeing some action on which tags to settle
with. It's been a mess of confusion ("which tags do I use? Will this
tick someone off?", etc), and will be easier to build on once we figure
out the tags that'll work best. It'll be awesome to get automatic bug
closing from a commit, and I suspect it'll bring a lot of good. Settling
on tags allows us to automate more. However, as a Council member, the
Gentoo community looks to you and your behavior as an example. Is this
the example you want to set for our community?
On the GitHub Issue, you called this mailing list "completely useless"
[1], and then you sent your message above a little later. Would you want
to work with someone who talks to you the way you treated Rich?
None of this bickering is motivating or inspiring to those who read it,
and leadership should know better than to stoop to this level publicly.
You will not get more developer activity, agreement, cooperation, or
contribution by berating your fellow developers. In fact, Gentoo is
known for its bickering developer community. You are in a position to
change that. You asserted in #gentoo-trustees that the Council *is*
Gentoo's leadership.
Is this your brand of leadership?
~zlg
[1] https://dev.gentoo.org/~zlg/useless.png
(screenshotted since GitHub conversations can be curated.)
--
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 09/10/2017 02:34 AM, Michał Górny wrote:
> W dniu nie, 10.09.2017 o godzinie 00∶39 -0700, użytkownik Daniel
> Campbell napisał:
>> On 09/09/2017 12:47 AM, Michał Górny wrote:
>>> W dniu pią, 08.09.2017 o godzinie 17∶19 -0400, użytkownik Rich Freeman
>>> napisał:
>>>> On Tue, Jul 25, 2017 at 4:05 AM, Michał Górny wrote:
>>>>>
>>>>> What do you think about it? Is there anything else that needs being
>>>>> covered?
>>>>>
>>>>
>>>> FYI - if anybody does want to make any comments on the proposed
>>>> devmanual changes to implement the new tags please comment at:
>>>>
>>>> https://github.com/gentoo/devmanual.gentoo.org/pull/72
>>>>
>>>> For that matter, if you want to even know what the proposed changes
>>>> are you should also visit the link.
>>>>
>>>> List replies seem to be discouraged.
>>>>
>>>> I realize that some prefer to limit comments to media that are purely
>>>> open source. I guess the FOSS Linux kernel provided /dev/null still
>>>> exists as an alternative. Honestly, I'm not sure which of the options
>>>> are more likely to get read.
>>>>
>>>
>>> TL;DR: Rich, I would really appreciate if you stopped the flamebaits.
>>> I understand that you think you're doing Gentoo a favor but you're not.
>>>
>>> The footers were discussed to death in this very thread. I've heard your
>>> opinions. However, as far as I'm concerned (and as I've pointed out) you
>>> did literally *nothing* to push your ideas forward for 2+ years.
>>>
>>> Since I've done all the work, I've did it my way and for the reasons
>>> I've explained multiple times. If you disagree, them I'm sorry but
>>> in life you don't get to have everything your way. Especially if all you
>>> do is complain and expect others to do the work for you.
>>>
>>> I understand that you're unhappy and since you have no valid arguments,
>>> all you can do is try to get more people to support you and shout.
>>> Revive the bikeshed as many times as possible, try to make a lot of
>>> noise and block changes. Worst case, you've blocked something you didn't
>>> like. Best case, you're finally get others so discouraged that they'll
>>> do things your way just so that you stop.
>>>
>>> Rich, this is not a kindergarten. It's time you learn to lose,
>>> and accept the consequences. If you can't do that, the door out is open,
>>> and you're free to leave anytime you want.
>>>
>>
>> This behavior is not befitting Gentoo leadership. Limiting commentary to
>> a walled garden outside Gentoo control violates one of our goals
>> (independence), and the incendiary retorts are no more mature than the
>> behavior you're criticizing. Nothing will change in the way people
>> respond to you until you learn how to treat others.
>>
>> By all means, I'm glad we're seeing some action on which tags to settle
>> with. It's been a mess of confusion ("which tags do I use? Will this
>> tick someone off?", etc), and will be easier to build on once we figure
>> out the tags that'll work best. It'll be awesome to get automatic bug
>> closing from a commit, and I suspect it'll bring a lot of good. Settling
>> on tags allows us to automate more. However, as a Council member, the
>> Gentoo community looks to you and your behavior as an example. Is this
>> the example you want to set for our community?
>>
>> On the GitHub Issue, you called this mailing list "completely useless"
>> [1], and then you sent your message above a little later. Would you want
>> to work with someone who talks to you the way you treated Rich?
>
> Yes, I did call it useless *multiple times*, and I've pointed out
> the problems. Considering they were ignored and the quality of
> the mailing list hasn't improved, this statement still stands.
>
> Rich should have talked to me if he had problems with understanding my
> comment or missed the context to it. What he did instead is beginning
> a public stone throwing session. This is not a kind of behavior I am
> going to accept, or respond kindly to.
>
> It's elementary. If you have a problem with me, talk to me first. Not go
> pointing fingers and shouting 'this person is bad'.
That's a good policy, one most of us can agree with I think. Sarcasm
Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan
On 09/11/2017 01:56 PM, Michał Górny wrote: > W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael > Orlitzky napisał: >> On 09/11/2017 01:08 PM, Michał Górny wrote: >>> Hi, >>> >>> TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather >>> than Wiki, put in a nice git repo. >>> >> >> I generally agree with you that wiki markup is terrible and that a text >> editor and a git repo is The Right Way to do things (with Jekyll or >> whatever to push it to the web). But in my experience, crappy and easy >> is a better way to get people to contribute. When I've taken wiki >> documents and moved them into git repos, more often than not I become >> the sole contributor, and otherwise-technical people just start emailing >> me their contributions (which decrease greatly in frequency). > > Rich already answered this in detail, so I'll skip it. > >> Will it be possible to build the GLEP rst files locally, and view the >> output exactly as it would appear on the website? I ask because, so long >> as you don't want to be able to preview the result, you can already >> write MediaWiki markup into a text file locally. The offline "live >> preview" ability is the killer feature of RST as I see it. > > Of course yes. However, the exactness of result depends on how much > effort you put into it. > > The 'easy way' is rst2html.py (dev-python/docutils). It will give you > a rough rendering with a standard style, i.e. kinda ugly but enough to > see if everything works as expected. You'll also see the preamble as big > mumbo-jumbo on top. > > Then, there's glep.py (dev-python/docutils-glep) which adds preamble > parsing, table of contents and some styling. AFAICS it needs a bit > handiwork (copying a stylesheet to a relative directory) but it gives > nice old-school rendering. > > Then, you can just take www.gentoo.org and run it locally. It takes > a little more effort but jekyll is really trivial to set up and run > locally. Then you see it exactly how it's gonna look on g.o. > > As a side note, we may also rename GLEPs to .rst. Then, GitHub will also > provide out-of-the-box rendering of them. > To preface, I really like the idea to do this in Git. Much as I appreciate what the wiki team has done, collaboration isn't quite as smooth on it and as another person mentioned, it's hard to get reviews, so you get to choose to leave something in your userspace (I liked your Drafts namespace idea, fwiw) or edit a page anyway and hope for the best. That said... Is it wise to rely on Ruby (via Jekyll) for critical reference documents, given how often minor version bumps in Ruby disrupt its ecosystem? Do we really need the entire www.gentoo.org repository in order to view and hack on GLEPs? I see little reason for GLEPs to not be in their own repository, depending on something more stable than Jekyll and Ruby. Given that the doc tools themselves are written in Python, it makes more sense (imo) to leverage Gentoo's existing technical investment in Python and use something like app-text/pelican, which is equally, if not more capable than Jekyll and will not require pulling in Ruby just to hack on and preview some text. Every Gentoo system comes with Python unless you go off the beaten path and know what you're doing, so that's a bonus, too. Of course, this changes if we need some extremely advanced behavior. I'm not sure how easy it is to build a Pelican plugin, but there's an entire repo full of them. [1] Pelican also uses a Makefile you can hack on (even multiple publishing targets), and supports GNU gettext for translations. Or is Jekyll chosen purely because the current website is built with it? In that case, it at least makes sense despite the heavyweight dependencies. If anyone's interested in seeing a mockup of a few GLEPs in Pelican, I can get that started. Whether or not the structure works on GitHub is orthogonal to the decision. Still, put me down in favor of switching to Git. Thanks for putting together the proposal. [1]: https://github.com/getpelican/pelican-plugins -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On 09/29/2017 04:53 AM, Rich Freeman wrote: > On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller wrote: >>>>>>> On Thu, 28 Sep 2017, Austin English wrote: >> >>> Talking with Whubbs about it, I found that our service script only >>> supports OpenRC, via rc-service. I looked around, and from what I >>> can tell, most distros ship a service tool for all supported init >>> systems. I.e., Debian/Ubuntu: supports sysvinit and systemd via >>> init-system-helpers CentOS/Fedora: provides support for systemd via >>> initscripts OpenSUSE: has a working service binary for systemd >>> (according to #suse) >> >> There is "eselect rc" which could be easily extended to support >> systemd. Patches are welcome. :) >> > > ++ > > Honestly, I could see the argument for having a generic "service" > command because that is what everybody else does, but there is little > point in arguing about the name of the file when nobody has bothered > to write it yet. > > If somebody writes such a tool and it proves useful, we can always > have the discussion about refactoring. > > To minimize list replies I'll tackle one of Duncan's points - he was > debating whether you really need this vs just using systemctl. The > obvious use case is scripts that are intended to support multiple init > systems - it makes far more sense to put the logic to figure out which > one to run in one place than many. If the runit users want to add > their own logic they could. IMO it would be potentially useful, even > if you and I don't personally have much use for it. > > That said, the sorts of people most likely to benefit probably don't > use Gentoo in the first place. > > In any case, arguing over whether it is useful is putting the cart > before the horse. It doesn't matter if it is useful if nobody bothers > to build it. If nobody has that much of an itch to scratch then how > useful could it be? > Great points. It'll be much easier to decide on something when/if there is something concrete to work with. There isn't much stopping a package from making it into Gentoo. If there is demand, it'll be written. -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update
nel
> from a trusted source for comparison.
"a more complete protection"; should probably drop the "a".
>
> Strictly speaking, this information is already provided by the various
> ``metadata/timestamp*`` files that are already present. However,
> including the value in the Manifest itself has a little cost
> and provides the ability to perform the verification stand-alone.
>
> Furthermore, some of the timestamp files are added very late
> in the distribution process, past the Manifest generation phase. Those
> files will most likely receive ``IGNORE`` entries and therefore
> be not suitable to safe use.
Looks like a few extra words in the last sentence. Here's my attempt:
"These files will likely receive ``IGNORE`` entries and therefore be
unsafe to use."
("unsuitable" may replace "unsafe", up to you)
>
> The specification permits additional timestamps in sub-Manifest files
> for local use. A generic testing tool should ignore them.
>
>
> New vs deprecated tags
> --
>
> Out of the four types defined by Manifest2, only one is reused
> and the remaining three is replaced by a single, universal ``DATA``
> type.
"the remaining three is" -> "the remaining three are"
> [snip]
> Injecting ChangeLogs into the checkout
> --
>
> One of the problems considered in the new Manifest format was that
> of injecting historical and autogenerated ChangeLog into the repository.
> Normally we are not including those files to reduce the checkout size.
> However, some users have shown interest in them and Infra is working
> on providing them via an additional rsync module.
"that of" is extraneous here.
The second sentence should read something like "We normally don't
include these files, to reduce checkout size."
>
> [snip]
> Hash algorithms
> ---
>
> While maintaining a consistent supported hash set is important
> for interoperability, it is no good fit for the generic layout of this
> GLEP. Furthermore, it would require updating the GLEP in the future
> every time the used algorithms change.
"it is no good fit" -> "it is not a good fit"
>
> [snip]
> The compression of top-level Manifest file has been prohibited
> as the specification currently does not provide any means of verifying
> the file prior to decompression. This would make it possibly for
> a malicious third party to provide a compressed Manifest exposing
> decompressor vulnerabilities, or being a zip bomb, and the tooling
> would have to unpack it before being able to verify the contents.
The latter half of the paragraph is a little scattered. Here's my
attempt, after the first sentence:
"If the top-level Manifest is compressed, tooling will have to unpack
the file before being able to verify the contents. This makes it
possible for a malicious third party to attack a system by providing a
compressed Manifest that exposes decompressor vulnerabilities, or a zip
bomb."
(Maybe 'zip bomb' should be a link or a footnote, describing what it
is.)
> [snip]
>
> The existence of additional entries for uncompressed Manifest checksums
> was debated. However, plain entries for the uncompressed file would
> be confusing if only compressed file existed, and conflicting if both
"only compressed" -> "only the compressed"
> uncompressed and compressed variants existed. Furthermore, it has been
> pointed out that ``DIST`` entries do not have uncompressed variant
"uncompressed variant" -> "an uncompressed variant"
> either.
>
>
> Performance considerations
> --
>
> Performing a full-tree verification on every sync raises some
> performance concerns for end-user systems. The initial testing has shown
> that a cold-cache verification on a btrfs file system can take up around
> 4 minutes, with the process being mostly I/O bound. On the other hand,
> it can be expected that the verification will be performed directly
> after syncing, taking advantage of warm filesystem cache.
"warm" -> "a warm"
>
> [snip]
> Thanks to all the people whose contributions were invaluable
> to the creation of this GLEP. This includes but is not limited to:
>
> - Robin Hugh Johnson,
> - Ulrich Müller.
>
> Additionally, thanks to Robin Hugh Johnson for the original
> MataManifest GLEP series which served both as inspiration and source
"MataManifest" -> "MetaManifest"
>
> [snip]
>
Aside from the few nitpicks this looks good. Hope this helps.
--
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: Digital signature
Re: [gentoo-dev] [PATCH] fdo-mime.eclass: Mark the eclass as deprecated
On Mon, Nov 13, 2017 at 03:30:11AM +0100, Jonas Stein wrote: > On 19/06/17 15:20, Michał Górny wrote: > > The GNOME team has committed the xdg-utils.eclass serving exactly > > the same purpose as fdo-mime.eclass, supposedly with the goal of > > replacing it. However, it seems that they have never bothered to > > actually hint the deprecation in the fdo-mime.eclass in any way. > > As a result, developers are still adding references to this eclass > > instead of using xdg-utils or xdg, and/or not working towards replacing > > them. > > > > Add an explicit deprecation notice to the fdo-mime.eclass to make it > > clear that the eclass should not be used in new packages, and what > > the replacement eclasses are. > > Packages and Ebuilds which are still using the fdo-mime are listed here: > > Packages: > https://qa-reports.gentoo.org/output/eclass-usage/fdo-mime.txt > > Ebuilds sorted by Maintainer or Package > http://gentoo.levelnine.at/simplechecks/fdo-mime-check/ > > If you see your name in the list, you find a list of your packages with > inherit fdo-mime. > > Thanks to Michael. For his script. > > -- > Best, > Jonas > Great tool! Super easy for maintainers to check their packages. I have fixes ready for x11-misc/spacefm, but I could not find a bug number to reference. Are we tracking this on bugzy or just pushing everyone to go ahead and update their ebuilds? I searched bugzy for 'fdo-mime' and the only relevant bug is 621914 [1], which I assume was the original discussion to get us onto xdg-utils since it's newer. If there's no tracker bug I need to reference, that's fine. Just wanted to be sure I'm not missing anything before pushing. [1]: https://bugs.gentoo.org/621914 -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] NEWS item for games destabling
On Mon, Nov 20, 2017 at 11:36:33AM +0100, Róbert Čerňanský wrote: > On Mon, 20 Nov 2017 10:26:29 +0100 > David Seifert wrote: > > > Round 2 (with correct whitespace this time): > > > > Title: No stable KEYWORDS for Gentoo Games > > Author: David Seifert > > Content-Type: text/plain > > Posted: 2017-11-20 > > Revision: 1 > > News-Item-Format: 1.0 > > Display-If-Keyword: amd64 x86 > > > > As the Games team does not have enough manpower to keep tabs on all > > games packages, we have dropped all ebuilds maintained by the games > > project to unstable KEYWORDS (without those required by other stable > > packages). If you have any of these stable games packages installed, > > you will have to add them to /etc/portage/package.accept_keywords/ > > manually. Failures related to missing stable KEYWORDS will show up as > > > > The following keyword changes are necessary to proceed: > >(see "package.accept_keywords" in the portage(5) man page for more > > details) > > # required by @selected > > # required by @world (argument) > > =games-action/0verkill-0.16-r4 ~amd64 > > > > While we accept that this will cause some irritation for the > > community, pretending we have a well supported games collection by > > having a wealth of stable games packages is misleading at best. We > > welcome contributions from outsiders willing to polish up the games > > landscape in Gentoo via the Proxy Maintainers. > > What does it mean for the future? Should not users bother to test & > write stabilization request bugs for games anymore? Or stabi > requests will still be accepted? > > Robert > > > -- > Róbert Čerňanský > E-mail: ope...@tightmail.com > Jabber: h...@jabber.sk > If I may take a stab at this (correct me if I'm wrong, soap): It only means games are being dropped to ~arch (testing) until other maintainers (proxy or otherwise) step up to make sure the games really are stable. Packages that rarely get attention but are still marked "stable" dilutes the meaning of "stable", especially if you get installation or runtime problems that a proper testing of the package would have caught. This results in bugs that should've been caught in the testing phase, confuses users (and developers), and redundant or obvious bugs being reported. This reads like a "fresh slate" for games, allowing them to start from ~arch and ensure that stabilization procedures are correctly followed by those who step up. While this will create more stabilization bugs, it should, in theory, result in better ebuilds (which makes Gentoo maintenance better/easier) and games that have *actually* been tested. I hope this explanation is both accurate and helpful. ~zlg -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
However, Infrastructure has replied already that we > can't deploy effective moderation with the current mailing list software > and I'm not aware of anyone willing to undergo all the necessary work to > change that. > > Even if we were able to overcome that and be able to find a good > moderation team that can effectively and fairly moderate e-mails without > causing huge delays, moderation has a number of own problems: > > α) the delays will make discussions more cumbersome, and render posting > confusing to users, > > β) they will implicitly cause some overlap of replies (e.g. when N > different people answer the same question because they don't see earlier > replies until they're past moderation), > > γ) the problem will be solved only partially -- what if a reply contains > both valuable info and personal attack? > > > Seeing that no other effort so far has succeeded in solving the problem, > splitting the mailing lists seems the best solution so far. Most > notably: > > а. Developer mailing lists are restored to their original purpose. > > б. It is 'fair'. Unlike with disciplinary actions, there is no judgment > problem, just a clear split between 'developers' and 'non-developers'. > > в. 'Expert users' are still provided with a mailing list where they can > discuss Gentoo without being pushed down into 'user support' channels. > > г. Active contributors (in particular recruits) can still obtain posting > access to the mailing lists, much like they do obtain it to #gentoo-dev > right now. However, if they start misbehaving we can just remove that > without the risk of evasion. > > -- > Best regards, > Michał Górny > > I don't think this plan will have the effect you're going for, but let's be honest here: the "RFC" is just a formality; the decision's already been made. If the "real leaders" of Gentoo want to divide and fragment the community, it's their prerogative. As we tell users who do something they're not supposed to: You get to keep the pieces. ~zlg -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On Tue, Dec 05, 2017 at 08:59:40AM +, Peter Stuge wrote: > Daniel Campbell wrote: > > On Sun, Dec 03, 2017 at 12:18:04AM +0100, Michał Górny wrote: > > > I'd like to establish the following changes to the mailing lists: > > > > > > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be > > > initially restricted to active Gentoo developers. > > > > I don't think this plan will have the effect you're going for, > > I agree, and I'll double down on my previous comment on this proposal: > > I consider the proposal to be the wrong solution. > > > > but let's be honest here: the "RFC" is just a formality; the decision's > > already been made. > > I hope that a mere proposal doesn't automatically mean policy change. > If proposals come from a select couple of people, there are high odds that it's been discussed privately and the relevant people've been convinced or otherwise pushed to implement the change. By the time it hits the list, any cricitism is met with "too bad, we're doing it anyway". I'm not sure how new you are to Gentoo, but it's been this way since at least 2012. > > > If the "real leaders" of Gentoo want to divide and fragment the > > community, it's their prerogative. > > When there is a request for comments, there should also be comments. :) > > Far too many fall into the simple trap that is tribalism, and I'd like > to encourage everyone on this list to not be that kind of person, > because there really is no "us and them", there is only "us". > I think the plan to split mailing lists serves as a way to insulate developers from the effects of their decisions. Anyone with an incongenial tone will have their voice bit revoked and their mail will be dropped or rejected. It will likely be a silent rejection, so the fallout is minimal. The plan itself is a manifestation of tribalism. The "us" is a select group of people who've been blessed by mgorny and friends. Everyone else is deemed a "do nothing" or some other insult, regardless of their history or efforts with the distribution. Yes, talking about that is ugly, but it's the truth. I've been on the receiving end of it multiple times and have been witness to it many others. It shows up in just about every corner of Gentoo. Creating a technical schism won't fix it. > > > As we tell users who do something they're not supposed to: You get > > to keep the pieces. > > Well, let's see what happens, now that both developers and > non-developers have clearly spoken out *against* this proposal. > I'm not holding my breath on any positive change, but we'll see. It's not like we have a choice in the matter. I guess we'll have to subscribe to yet another mailing list if we want to stay informed. Maybe in a year's time, we'll have gentoo-dev-expert as well, so the Chosen Ones don't have to deal with developers they don't like. This is my last mail in this thread. I've made my points and know they will fall on deaf ears. You're not wrong in your approach; I don't share that faith, is all. So I hope you don't interpret this as me yelling at you. > > Kind regards > > //Peter > -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On Fri, Dec 08, 2017 at 09:22:32PM +0100, Andreas K. Huettel wrote: > Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson Jr.: > > > > The day everyone wanted has come, after this message. I will > > unsubscribe not to return. You all won in 2008, and again in 2017. > > Though this time I will not be back. I tried more than most anyone else > > would for a very long time. Gentoo wins I lose, I am fine with that. > > > > Please do not contact me off list in IRC or at all. I am done with the > > Gentoo community! > > > Independent of whether William now unsubscribed or not, he's now enjoying a > lengthy (1 year until review) vacation from all Gentoo communication channels. > > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer (council, perl, libreoffice) So, mgorny threatened to leave if something wasn't done, right? I saw the IRC conversation about unsubscribing from gentoo-dev, as well. IRC is not private, for the record. Other developers are required to subscribe to -dev, and are expected to follow it so they stay informed. If they missed something covered on the list, they are directed to the archives and (usually) laughed at. I see no reason for this expectation to be waived for any single developer. Do I get a free pass if I don't like what someone says? It's not enough to let wltjr leave on his own; you had to create a ban and add a smug, tongue-in-cheek mail to it to maintain the image of doing something. Quite hypocritical of comrel's attitude of secrecy to suddenly announce a ban. It seems to me that secrecy is only adopted when it suits those who stand to benefit from it. Great things coming from Gentoo "leadership" here. What will you do when mgorny starts targeting developers and pitching tantrums over them, too? Are we going to stratify developership further, too? It seems rather clear to me that a few individuals see themselves as the owners of this distro and bend it to suit their whims, using bureacracy to obscure their actions and motivations, segment the community, and block those less experienced. This is precisely why we have unmotivated developers and a bevy of unmaintained packages; nobody wants to contribute to a distro that treats its users (and developers) so poorly. A distro should never bend its entire social structure to protect the feelings of one surly developer (or his/her entourage), but naturally since every council member is friends with mgorny and comrel is afraid to take any action against him, they'll make exceptions to established procedures and ignore any complaints about the way he treats others. Software cannot fix wetware. Plenty of developers get to deal with mgorny's aggressive and insulting tone, yet nothing happens. Gee... I wonder why. Maybe because the upper parts of Gentoo are riddled with cronyism. "Rules for thee, not for me." It's clear to anyone with eyeballs that there is preferential treatment and inconsistent enforcement of rules in this community, and the people in a position to fix it, won't, because they in fact benefit from this. Unfortunately, GLEP 39 does not have a section on recalling or impeachment... This whole situation highlights why the Council has no business sticking its head into non-technical matters. It's clearly not up to the task. It's no surprise, since technical skill does not guarantee or even imply social skill. (or vice-versa) I'm tired of people beating around the bush and the facile attempts of tact: why do you give special treatment to certain members of this community? Would you have done anything different if it were me or some other developer who was proposing this change? It wouldn't have made it to the Council agenda if he didn't write it, period. Everyone else would've been told to suck it up and deal with it. And knowing how the Council is, in a few days we'll all get to deal with the churn of mailing lists to protect one person's ego. Sad. ~zlg -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On Sat, Dec 09, 2017 at 08:13:18PM -0500, Rich Freeman wrote: > On Sat, Dec 9, 2017 at 7:29 PM, Daniel Campbell wrote: > > > > Other developers are required to subscribe to -dev, and are > > expected to follow it so they stay informed. > > Developers are not required to subscribe to -dev. > > > If they missed something covered on the list, they are directed to the > > archives and (usually) laughed at. > > Correct. While nobody is required to follow the lists, acting out of > ignorance usually doesn't impress others. Devs are expected to be > adults and figure out what they need to follow based on what they > intend to contribute to. -core and -dev-announce are the only > required subscriptions. > > > > > Great things coming from Gentoo "leadership" here. What will you do when > > mgorny starts targeting developers and pitching tantrums over them, too? > > You act as if this was the only reason that comrel took action. In > the cases of appeals I've seen I've yet to see a case where there > wasn't something else going on behind the scene that wasn't reasonably > severe when they've taken action. I can't vouch for their reasons in > this case as I'm not privy to them, and I imagine they're not going to > be made public. Well, let's consider the order of events here: 1. wltjr and others appear on the ML 2. Drama 3. mgorny suggests some change in structure to avoid dealing with said people. 4. more drama 5. mgorny publicly insults comrel, accusing them of doing nothing 6. mgorny publishes formal plan to reform our mailing lists 7. more drama 8. comrel bans wltjr 9. mgorny's plan is put on Council agenda 10. comrel *mails to let everyone know wltjr was banned*, despite prior claims of valuing privacy and secrecy 11. you are here This looks awfully clear to me. I'm pointing out behavior that looks a lot like one person twisting the social structure to suit their desires. This concerns me because our community will be damaged by his plan, and it is only the first step. In the second step, he will turn against developers as well. But not you and his other buddies. Just the ones *he* thinks are a problem. > > > This is precisely why we have unmotivated developers > > and a bevy of unmaintained packages; nobody wants to contribute to a > > distro that treats its users (and developers) so poorly. > > Go ahead and cite the list of people who have been banned in the last > decade. You won't run out of fingers on one hand. Some might cry > about it for months, but good luck finding another distro that hasn't > banned twice as many in the same span of years. > > And keep in mind that failing to take action isn't without > consequences. When somebody is harassing somebody else (and sometimes > more than one other) you don't really get a choice about whether > somebody is going to end up leaving, whether of their own accord or > not. That is a situation I've seen happen more than once around here > behind the scenes. Again, I have no specific knowledge about this > particular comrel action - I'm talking about situations I've seen in > the past. I'm not focused on the ban, or whether it was deserved. That's a separate subject. I'm pointing out behaviors that damage our image, our credibility, and morale. I'm calling out unequal enforcement and favoritism; these are things that you won't find in any records, because the existence of such records would damn those culpable. The fact that comrel has never acted against mgorny strongly indicates that they do not care about the way he treats others. He is kept because of his technical skill. Others do not get this convenience; we are accountable for the code *and* the words that we write. You're blind if you don't see this. > > > A distro should never bend its entire social structure to protect the > > feelings of one surly developer (or his/her entourage), > > Certainly, and that works both ways. > > > but naturally > > since every council member is friends with mgorny and comrel is afraid > > to take any action against him, they'll make exceptions to established > > procedures and ignore any complaints about the way he treats others. > > Considering that he won a significantly contested election to Council, > I suspect that more people around here approve of mgorny than just the > members of the council. And I can certainly vouch that not all > council members are necessarily fans of some of his actions, though I > suspect that his technical contributions are praised by just about all > (rightly, IMO). > > I've yet to see a discussion between Council me
[gentoo-dev] Packages up for grabs
The following packages are in need of a maintainer: dev-util/astyle net-im/toxic x11-misc/alock x11-misc/ktsuss x11-misc/spacefm -- Daniel Campbell OpenPGP Fingerprint: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 Found on hkp://keys.gnupg.net and other keyservers signature.asc Description: Digital signature
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/23/2016 12:52 AM, Ian Delaney wrote: > On Thu, 21 Jan 2016 16:30:14 -0800 Daniel Campbell > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > >> On 01/21/2016 02:41 PM, waltd...@waltdnes.org wrote: >>> On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote >>> >> [...] [...] [...] >>> >>> I think you misunderstood Roy. He was speaking about >>> "unmaintained but perfectly functional software". You're >>> talking about "a package that clearly doesn't build or >>> otherwise simply doesn't work, could not have worked for past 3 >>> years". Between those 2 extremes will be many cases of >>> doesn't-work-for-me/works-for-me. Who'll be the final >>> arbiter? >>> >>> Maybe we should start a "gentoo-ebuilds" mailing list to help >>> regular users learn the ins and outs of making ebuilds. Once >>> regular users run a lot of their own ebuilds from their local >>> overlays, then it would be possible to do draconian pruning of >>> the "official portage tree", without so adversely affecting >>> regular users. This would fit in with the mantra of Gentoo >>> being about freedom of choice. >>> >>> E.g. I use Pale Moon, a fork of Firefox. Currently, I have to >>> build as regular user, su, and copy the binary to /usr/local. >>> You can see "Walter's excellent adventure" as I learn the >>> build process at... >>> https://forum.palemoon.org/viewtopic.php?f=37&t=10002 >>> >>> I'd like to have Portage manage the process. The ebuild from >>> Firefox should serve as a template, because they both use the >>> same weird Mozilla build setup. The main change should be >>> where the source is pulled from. >>> > >> The idea sounds nice, but there's already the devmanual to cover >> ebuild development, and now that the gentoo repo is in git, any >> ebuilds that get treecleaned can be fetched again through >> history, and users can then add those to their personal >> overlay(s) and keep the piece if they break. > >> I like the idea of encouraging people to learn good ebuild >> writing, but who really has the time and skill to teach it? > > > me. Been doing it for months. You had not noticed? via > #gentoo-proxy-maint, which I made from scratch, despite the notion > initially being discounted by one mrueg. He now is a colleague in > the channel. > I didn't, actually. I guess the only thing I've seen as a result of your work is possibly more new devs. That's pretty awesome, though; I had no idea. I can't speak for other devs but I respect people who have the patience and gift to teach people. You helped me a little when I was becoming a developer and I appreciate it. >> - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ >> hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A >> 9091 1EA0 55D6 >> > - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWpWdoAAoJEAEkDpRQOeFwnkgP/iRHumL4sYupyh5jxe8g97Bo //TEU/k4osiz4Ofl79fTVfabYZiMTacMaRj++swccGw0NorjBRf4TUc2bc08++NH iUOjBwC5nAhPlx6UFM1IKAyOLvc4MZIpfR3m688EkTKnYH2865WhLjClfAwT7AFC 0Ux4/Knb7j4XtDBjM1tumA28VR27CTaIOsuPFMKIQ3gm0UnpZbPEOyiXNkszfq5g IMkJynUtIgGegscdz9i+uGHVToqQXZnCxs/4fG+d6xr0ENMgwr+sOS8GnwR3wNtv /wZ6qwUJuwGuh9Y0BDXibnoEE5vr+srZRPPZigLvbps24dCYbFE7dmpeEU11o5lB fV5pI78QV81xI9NUYQsyPj3PbZn9qzgUtjw59lQvTN1rBtqSlezeRJ8JD+U1nBym I2cL8Auy3Uu0W3q8G31iRmVW+LCe9njw6GZkj24QOzlsqkW3cjn+VyQHSNz2QNI9 384cY6NDngKvTugi5ccbkPicGO5pAxZ0UA44JwURLiGr0W9bbiaBOLBG6xQYkTQZ j7F9P3RjGIbIGgxQQTQatyEQpqFnRBR22J8VH688OCHEjZprEc/F/xA4R1TLCRxx 3S3OMbuw99fsEXbqYhFhqWUsmOwaCCd7ofgrjXiefrf2NtRkl0V6loRoKlHz9ycY wkPbzmPJ7zvNR+PcDud1 =JQSf -END PGP SIGNATURE-
Re: [gentoo-dev] New packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/24/2016 03:32 PM, Michał Górny wrote: > Hello, everyone. > > As a result of disbanding a few herds, we some new > maintainer-needed packages. > > Here's the complete list: > > app-cdr/bashburn dev-util/astyle > I'll take those two. I use astyle to format code and rarely use bashburn. Looks like it's not had an update in almost 5 years; should be easy to maintain. Thanks for producing the list. Quite a handful of packages that are worth holding onto, but I don't use them anymore so I wouldn't be doing them a good service by taking them. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWppDoAAoJEAEkDpRQOeFwidwQALb1qyP5KzKej3PTGJI+hPTJ T3YfzKQOk7BvLxA/CIx9YKdctVvDNyKO3gXIRILuqSr9F69YsQ21Zr31WC9vELTD nhXbgYfTuXM1hpZ8gvEKAI3aLMWy9XHEmS13Su4FznsGOpltK/CeNKZzSC9pXtIM Q3n/jD/Unh8M3TRCESEnW6zRDDfh4TAbaHGSYfUP0LJnqP4ujHIMhrI2/ujP071r ZW5lrxGrXxE/I3k2CruUUlJA6MWGgsExkZzdJnzUYkD2gZz0d5qgqDN/iRqAMp9O 2n9FOGQ0r4qBMVUmJ0OzT0pELU4iKuQiM72yTPq6c96SKjDV8jSo3962GrmqXk8S ame1jrWBIved24A4reMr9491kjLBEbemgWnMSyKw4FlrwqH9rrkzuQnmhWvCgP23 jgr99Uo5Z0/Olu77eDA7Sn1Q/j89GLrPYK5riuJhnhbUwqLhA77ZKt249QDNp0Ew OvmlMkuXp4pIZuBwNrZj9fZCUO5drlejEFrgURWcWcMpEfXZu19GCqy4w6eS3zNm wKFpa0NaSQRJivyn1HwIjyXUyYOT90YVCh4p2UVogVYl7hiYtS/+kg+8ja3uuPov sAg1Q4eoMXvxNECMYaIcnB5KOOHwS4ilZnCEsdHx6cFv9VElvei1QykUmTwLOe/4 ZVHTCSRQPg+OHJ5J67oE =PF1m -END PGP SIGNATURE-
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-01-31 23:59 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/31/2016 04:05 PM, Robin H. Johnson wrote: > The attached list notes all of the packages that were added or > removed from the tree, for the week ending 2016-01-31 23:59 UTC. > > Removals: [snip] > x11-apps/ardesia 20160129-11:18 pinkbyte > c42fbbf x11-apps/ccsm20160128-08:10 > pinkbyte 0f35eae x11-apps/simple-ccsm > 20160128-08:10 pinkbyte 0f35eae > > Additions: [snip] > x11-misc/ardesia 20160129-11:18 pinkbyte > c42fbbf x11-misc/ccsm20160128-08:10 > pinkbyte 0f35eae x11-misc/simple-ccsm > 20160128-08:10 pinkbyte 0f35eae > > [snip] Am I reading this right? Does that mean they were added and removed at the exact same time? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWrseYAAoJEAEkDpRQOeFw0cMP/1Qh905ISrnQ+z2SHNmc9wne njka39oOJrJNqWSsEksa8NvK27og3zbST/lXtuX8spkSNIs6aMLuhaiDYvjDqtnp O3INFPCGoRvXul9arHfJeUiqqvIiZxQQUH4Yjp/qR9V9MGF0BCOiIhQa0/NAQTTb AAhBuOaLT5wQmb7zm6+5CNLb6H7DnLHqzmW3XcvUndV3JeDHbwmn2Ai5SgwBFs0p TiuTvnvu5EPzcSMBxT3hqe10pjTbBhwxx8ycvJ3zUaNgv0qiZ3AilIq1jk3rpzJi p0UAWbFI599mvEf6358lpL6/MpEVWpjaBkjN6h5FGpu1S8MyYhkQ/5HbXKmg2j8X fPh7gOOSJy8cFWW/RZ2q1CmFrC0WrSwBL0GiTFwuee2lgZkrot7vfL3s9bEOaFle fy82W/BfoHCXrnWB2yOpJwX3Q6TFoStKR65+9Jhvwp/4zN35f4mjYwMsCWuWcbfn W89bqo8f2oJFQvhpzwCoWyUw7N0eH7QpjIAig3iWr5/e4mTaKDCFIh11407fWXna uC4aD6VrQy9f3Pm3RxK2IEjfzQiUAWXI1nJRLB/65GvEjF3Q3rSHSlPYIYoKceCE 7LyJCJAanaV2DyD/oN91+1fBmiT4V+WJv+EGRAtlhB60IzRCP+MxKh/iHoI4WM9t p4XkDCopcHCUfRKj9sOH =uZ0i -END PGP SIGNATURE-
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-01-31 23:59 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/31/2016 08:37 PM, Tim Harder wrote: > On 2016-01-31 21:48, Daniel Campbell wrote: >> On 01/31/2016 04:05 PM, Robin H. Johnson wrote: >>> The attached list notes all of the packages that were added or >>> removed from the tree, for the week ending 2016-01-31 23:59 >>> UTC. >>> >>> Removals: >> [snip] >>> x11-apps/ardesia 20160129-11:18 pinkbyte >>> c42fbbf x11-apps/ccsm20160128-08:10 >>> pinkbyte 0f35eae x11-apps/simple-ccsm 20160128-08:10 >>> pinkbyte 0f35eae >>> >>> Additions: >> [snip] >>> x11-misc/ardesia 20160129-11:18 pinkbyte >>> c42fbbf x11-misc/ccsm20160128-08:10 >>> pinkbyte 0f35eae x11-misc/simple-ccsm 20160128-08:10 >>> pinkbyte 0f35eae >>> >>> [snip] >> >> Am I reading this right? Does that mean they were added and >> removed at the exact same time? > > That's how package moves show up (0f35eae) with the current > adds/removes script. > > Tim Ah, okay. I didn't noticed the category switch. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWru+eAAoJEAEkDpRQOeFwTQ8QAIo0UNZfjiJUqX6FfPevqiAt UA5ZVzc7grty3BE02G9gwKYONvDxJ44ku0YURActfKMLce8TT8s8x4ZKuGzAM8WD 65wiyHxffA2U7JL5a/5XftNlhcN9Ex0TB6Y++rOoAlxBpUYydzkgG/XEflIrBlrk IWUsb26aHh+dfPj6J3jF8ukceKG+cnSXu2ezQTV/HRVKFFj8yfz8G4Tv7e/ddRdS pJ0Ezd6hggd/UiDo4l/AipEUx6Ra4rA/TjUvb5zx7rYcflyWJGky1hNYavDSlXyL WbHMCdgVApsFYORiAzKB+0W8a3mkPAQXUIAGUMIazu4d0Dzjeonc92npNkySuhOf 2FBzQGk1CDu7/r+3rfapwZQnHru0qwNh6z0HBbiGoddWdAVHWfa83AM14ND2T/bL 5+FnbDcd2IVgR+fjR9xD9/YmxgoxsgRT2mPVDjWhSMzWKvTSi2hNpaQFYlgZdJPr jOoIGKA26hsdsfbGzpEct0vx5+smb9l/d0frYqHcrYphWfC3J8BDMpmBiqPNwsqx uAyfXMShN7HP+w4bRHmCmxt2yQr/BZ3oKnKZaVwzVBJJFbC3A2NXfsJHR8k7+tWB cLBnKUR9BAB+EIFpFXntq5RP6X6bURv6ExFZ4DyV63aWFK8xhpLHIZ3fMbXMk4zX PwKEhQoi02+PcmI8+agL =oiiU -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [PATCH 0/5] RFC: Patches for wxwidgets.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/02/2016 02:36 PM, Ryan Hill wrote: > On Mon, 1 Feb 2016 12:08:28 +0100 Justin Lecher > wrote: > >> while tracking down the following error when running "egencache" >> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command >> not found GENTOO.GIT//eclass/wxwidgets.eclass: line 84: >> get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command >> not found GENTOO.GIT//eclass/wxwidgets.eclass: line 84: >> get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command >> not found GENTOO.GIT//eclass/wxwidgets.eclass: line 84: >> get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command >> not found GENTOO.GIT//eclass/wxwidgets.eclass: line 84: >> get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command >> not found >> >> I found that the global scope get_libdir() usage of the >> wxwidgets.eclass doens't work on EAPI=6. The following patches >> correct some minor things and block EAPI=6 for now until the >> eclass is ready. >> >> Justin Lecher (5): wxwidgets.eclass: Update Copyright year >> wxwidgets.eclass: Fix whitespaces wxwidgets.eclass: unset >> unneeded variables in global scope after usage wxwidgets.eclass: >> Only inherit eclass ones wxwidgets.eclass: Add EAPI support >> >> eclass/wxwidgets.eclass | 33 - 1 >> file changed, 24 insertions(+), 9 deletions(-) >> > > 1. I don't think most of this is necessary but go ahead I guess. 2. > When did we start posting every @&#$! eclass change to g-dev? File > a bug like a normal person. (There's already one open you could > have used) > > I see nothing wrong with discussing changes to parts of the tree that will affect other developers. Bugzilla is nice and all, but imo it's more of an AND thing instead of an OR thing. If the bug is already present, I see no real reason not to have a thread about it on g-dev. It keeps unrelated developers in the loop, as well, in the event that they come across weird eclass behavior or take on a project using a given eclass. I guess if eclass discussion is a problem, one could always add a rule to whatever they use to filter their mail. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWsqRfAAoJEAEkDpRQOeFwMNEQAJTu8qR9PRV0yWOJpiUdNYXM bdshcE17w41+xXSdDK+rhWxdQeZwG5fzxzqwtvzNr8lYtKPuTOaKRNV/KxjhBMH8 tiwIfggw0RfnKnlysQPXMB6YDrbkYAYZmRIObZBF9ZBhLqkod+HW2Ek0gLUfC1jP 3HIU6ymexHc+AGehw/L6FzQPGnv7SSDcTFqU8XI5HZZjT4M4xGdU9S3hM3kHFqOL f8Ua/ygYnWgAe7XeR7pxC9N1wRZHUbBXEc+I8hQa0i3a0vM0j62c2xQZ/tF7/wwy 1ie/7ogU2+4CCAqXUU783I9HtZC+kGeNGPtuBMgQUlwJ96NavK7fxCvLRRejs+Pc 9AhPYSQcGF/abeqVxSib2QBnXUumWXWKKPNSqpVvKWgTjGhtE0HNjHHq+y5tv3pi l7IlyK3eR4jGbDxxswUkFo0be1OU/LKP9jKM0nNB+GT3OT5Xu6qV2lDQIpAe3r/i E1yGZXTe+WlfhVbtaz6KQKqa4wf9nF85JMu3lfwigAucxIbfrcMkXKEnrROq9qpw 5ouNyUTrbPgnap5v8JUMNmKp2PgR87v9ZUwtwum2w7FH5+qzGGGC+5dGnwC9JiUj 9G0ETBaUnMkqcTRAUyz9q+BHdgD9+ZWIfw3U4Db23YtDEtwwHcZgZDg2TA7Ch6jm EY+h/UWs3jYNjT4ZTulx =V736 -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH v3 00/21] devmanual: update the docs for post git-migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2016 04:57 PM, gokt...@binghamton.edu wrote: > From: Gokturk Yuksek > > Hi, > > This is the third iteration of the patch series that attempts to > update the devmanual for the git migration. > > The updates included in the third revision are: - Added a new > subsection called "Git Commit Message Format" based on the commit > message format included in the Gentoo Git Workflow wiki and the > feedback provided on this mailing list. - Based on the discussion > wrt how well git deals with compressed patches, I've decided to > remove "because git does not play well with binary files". It's a > policy we have been following for years irrespective of how git > deals with them. - Rewrote the subsection on "Removing a package" > so it does not use 'git commit -m'. Rewrote the example and added > the corresponding commit message as an example. - The subsection > "User-submitted Ebuilds" is modified to mention the use of git > style tags in commit messages and a reference to the commit message > format policy section has been added. > > You can review the changes on Github for your own convenience: > https://github.com/gktrk/devmanual.gentoo.org/compare/master...gktrk:devmanual-git-migration-v3 > > If you want to see the diff between v2 and v3, you can clone the > Github repo and check the diff between the branches > "devmanual-git-migration-v2" and "devmanual-git-migration-v3". > > The HTML version of the devmanual with the proposed changes can be > found at: http://devmanual.qui-gon.org/ > > Gokturk Yuksek (19): general-concepts/manifest: drop the use of > "CVS keyword expansion" #558642 general-concepts/mirrors: > substitute "CVS" with "the git tree" #558642 general-concepts/tree: > substitute "CVS" with "git" #558642 general-concepts/tree: replace > the mention of ChangeLog #558642 ebuild-writing/misc-files: replace > the code for cvs commit with git #558642 > ebuild-writing/user-submitted: do not put user information in > ChangeLog #558642 appendices/editor-configuration/emacs: remove the > CVS related setting #558642 ebuild-maintenance: rewrite the text on > adding binary files to the tree #558642 ebuild-maintenance: rewrite > the subsection on commit policy for git #558642 ebuild-maintenance: > rewrite the subsection on upgrading ebuilds for git #558642 > ebuild-maintenance: rewrite the subsection on moving ebuilds for > git #558642 ebuild-maintenance: rewrite the subsection on removing > ebuilds for git #558642 ebuild-maintenance: rewrite the subsection > on removing packages for git #558642 ebuild-maintenance: replace > "cvs commit" with "git commit" #558642 > general-concepts/git-to-rsync/diagram: update the description for > git #558642 general-concepts/git-to-rsync/diagram: update the > description for git #558642 general-concepts/tree: remove the > reference to the ChangeLog #485314 ebuid-maintenance: add a new > section called "Git Commit Message Format" #558642 > ebuild-writing/user-submitted: mention git style tags in commit > messages #558642 > > Michael Orlitzky (2): ebuild-writing/misc-files: remove ChangeLog > section #485314 tools-reference: remove the echangelog page > #485314 > > appendices/editor-configuration/emacs/text.xml | 4 +- > ebuild-maintenance/text.xml| 281 > +++-- ebuild-writing/common-mistakes/text.xml > | 2 +- ebuild-writing/misc-files/changelog/text.xml | 111 > -- ebuild-writing/misc-files/metadata/text.xml| 16 +- > ebuild-writing/misc-files/text.xml | 1 - > ebuild-writing/user-submitted/text.xml | 14 +- > general-concepts/git-to-rsync/diagram.svg | 2 +- > general-concepts/manifest/text.xml | 4 +- > general-concepts/mirrors/diagram.svg | 2 +- > general-concepts/mirrors/text.xml | 2 +- > general-concepts/tree/text.xml | 5 +- > tools-reference/echangelog/text.xml| 32 --- > tools-reference/text.xml | 1 - 14 files > changed, 247 insertions(+), 230 deletions(-) delete mode 100644 > ebuild-writing/misc-files/changelog/text.xml delete mode 100644 > tools-reference/echangelog/text.xml > This isn't related to what you're doing but I felt it was a good place to ask: How are you and other developers creating these series of e-mails? It seems really handy and I'd like to know what it is, in the event that I need to do the same. - -- Daniel Campbell - Gentoo Developer Op
Re: [gentoo-dev] [PATCH v3 00/21] devmanual: update the docs for post git-migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2016 05:15 PM, NP-Hardass wrote: > On 02/03/2016 08:10 PM, Daniel Campbell wrote: >> On 02/03/2016 04:57 PM, gokt...@binghamton.edu wrote: >>> From: Gokturk Yuksek > >>> Hi, > >>> This is the third iteration of the patch series that attempts >>> to update the devmanual for the git migration. > >>> The updates included in the third revision are: - Added a new >>> subsection called "Git Commit Message Format" based on the >>> commit message format included in the Gentoo Git Workflow wiki >>> and the feedback provided on this mailing list. - Based on the >>> discussion wrt how well git deals with compressed patches, >>> I've decided to remove "because git does not play well with >>> binary files". It's a policy we have been following for years >>> irrespective of how git deals with them. - Rewrote the >>> subsection on "Removing a package" so it does not use 'git >>> commit -m'. Rewrote the example and added the corresponding >>> commit message as an example. - The subsection "User-submitted >>> Ebuilds" is modified to mention the use of git style tags in >>> commit messages and a reference to the commit message format >>> policy section has been added. > >>> You can review the changes on Github for your own convenience: >>> >>> https://github.com/gktrk/devmanual.gentoo.org/compare/master...gktrk: > >>> devmanual-git-migration-v3 > >>> If you want to see the diff between v2 and v3, you can clone >>> the Github repo and check the diff between the branches >>> "devmanual-git-migration-v2" and "devmanual-git-migration-v3". > >>> The HTML version of the devmanual with the proposed changes >>> can be found at: http://devmanual.qui-gon.org/ > >>> Gokturk Yuksek (19): general-concepts/manifest: drop the use of >>> "CVS keyword expansion" #558642 general-concepts/mirrors: >>> substitute "CVS" with "the git tree" #558642 >>> general-concepts/tree: substitute "CVS" with "git" #558642 >>> general-concepts/tree: replace the mention of ChangeLog >>> #558642 ebuild-writing/misc-files: replace the code for cvs >>> commit with git #558642 ebuild-writing/user-submitted: do not >>> put user information in ChangeLog #558642 >>> appendices/editor-configuration/emacs: remove the CVS related >>> setting #558642 ebuild-maintenance: rewrite the text on adding >>> binary files to the tree #558642 ebuild-maintenance: rewrite >>> the subsection on commit policy for git #558642 >>> ebuild-maintenance: rewrite the subsection on upgrading ebuilds >>> for git #558642 ebuild-maintenance: rewrite the subsection on >>> moving ebuilds for git #558642 ebuild-maintenance: rewrite the >>> subsection on removing ebuilds for git #558642 >>> ebuild-maintenance: rewrite the subsection on removing packages >>> for git #558642 ebuild-maintenance: replace "cvs commit" with >>> "git commit" #558642 general-concepts/git-to-rsync/diagram: >>> update the description for git #558642 >>> general-concepts/git-to-rsync/diagram: update the description >>> for git #558642 general-concepts/tree: remove the reference to >>> the ChangeLog #485314 ebuid-maintenance: add a new section >>> called "Git Commit Message Format" #558642 >>> ebuild-writing/user-submitted: mention git style tags in commit >>> messages #558642 > >>> Michael Orlitzky (2): ebuild-writing/misc-files: remove >>> ChangeLog section #485314 tools-reference: remove the >>> echangelog page #485314 > >>> appendices/editor-configuration/emacs/text.xml | 4 +- >>> ebuild-maintenance/text.xml| 281 >>> +++-- >>> ebuild-writing/common-mistakes/text.xml | 2 +- >>> ebuild-writing/misc-files/changelog/text.xml | 111 >>> -- ebuild-writing/misc-files/metadata/text.xml| 16 >>> +- ebuild-writing/misc-files/text.xml | 1 - >>> ebuild-writing/user-submitted/text.xml | 14 +- >>> general-concepts/git-to-rsync/diagram.svg | 2 +- >>> general-concepts/manifest/text.xml | 4 +- >>> general-concepts/mirrors/diagram.svg | 2 +- >>> general-concepts/mirrors/text.xml | 2 +- >>> general-concepts
Re: [gentoo-dev] [PATCH v3 00/21] devmanual: update the docs for post git-migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2016 05:49 PM, Göktürk Yüksek wrote: > Daniel Campbell: >> On 02/03/2016 04:57 PM, gokt...@binghamton.edu wrote: >>> From: Gokturk Yuksek > >>> Hi, > >> [...] > >> This isn't related to what you're doing but I felt it was a good >> place to ask: > >> How are you and other developers creating these series of >> e-mails? It seems really handy and I'd like to know what it is, >> in the event that I need to do the same. > > > > Here's how I do it: Make your commits on a separate branch as if > you'd push them directly to the repo. Use 'git format-patch' to > generate patch files and use 'git send-email' to send them. You can > skip format-patch and just use send-email but for a changeset of 21 > commits I'd like to take another look. > > git format-patch --stat --summary -o bug558642_v3/ -n -v3 > --cover-letter master..devmanual-git-migration-v3 > > Creates the patches. '--cover-letter' creates a special patch file > that requires editing which becomes the first email in the series, > which is the one you replied to. > > Once satisfied, I sent it with: > > git send-email * > > Keep in mind that git will CC authors of the patches and yourself > to the email. So you may have to adjust those. > > Don't forget to edit your .gitconfig and set proper SMTP options > in the [sendemail] section. > > Awesome; between the manpage and your example this is a great primer! Thanks a lot for explaining your workflow. I'm sure it's useful to more than just myself. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWsq8HAAoJEAEkDpRQOeFw+HUP/2QEbZNPNmrZGM2DGVzAIY+/ wQvGpIq8IO6SQ6pQH8FLFeTb17Y2x+SB04rYqv3bpbOV/GjSPwAomObLBa4GUU74 QTnZ7p4ZfMxisiZd5IfFPNMuY2YTpT2TfRez1TPxdty+4w9aE/MjYNvk/pTqhc4D fVI8NdMixP8obDozXqvqKSV2uh0smE82aFleAN7yQ9pEplV/282UqdcFRIQs6iXX 7gCxZvTbaXTuvukda8D8uABrZSvZhORjZ4TmnZfEHQcih9byF9smk/Ao1uNbTXG2 iJRkvDld0wfkar6o8zoX9tEjwwpVXfSSjnDcEZSYYO90Q3aY3HNWttcgRilD4HXA wd57r5eDZUM82IY70oGhHPDEeW+lXoKgp3B8LYQCdGOJRLgSPC6F9WGvAvf/qK8h ULg1WPbjMudWU1gnzNxaX2f3WT6+RoyZccpUMKNg/Ku2glG/6ZVPbkpm8Z4Uo/yd iuhpCcs3HVHWvZS7ggJk7FysxlBwH5Zd4+88USo/HujUfjkdvJgZ7COAV8DTikAg 3n2U+MFIUDwjfp014MgKKTdTt0Cj2n87LPCeQN+hEeGPOfz6jAr2TBrRGdyCEHBi aYHbny9tFs3na4HJhBquE5Esm159T+RY7Ff7br1zzIu8hhNNIlCsN8xxRku9jCsx wT5s3gCj/o4ElV+EumhX =BZ+P -END PGP SIGNATURE-
Re: [gentoo-dev] games.eclass policy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/07/2016 03:09 AM, Michał Górny wrote:
> On Sun, 7 Feb 2016 11:38:27 +0100 "M.B." wrote:
>
>> Hello folks.
>>
>> While hacking away on a new ebuild I came across the issue that
>> games.eclass apparently got banned from future use. The only
>> references I was able to dig up (apart from helpful people on
>> IRC), were https://bugs.gentoo.org/show_bug.cgi?id=566498
>> (games.eclass: use of games group needs to be removed wrt
>> 20151011 Council meeting) and
>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summar
ies#Games_team_policies_issue
>>
>>
(A mere deprecation notice).
>>
>> In contrast, a simple "grep deprec /usr/portage/eclass/" gives
>> numerous deprecation warnings; just games.eclass is not among
>> them.
>>
>> Please provide some guidance how (community-)developers are
>> supposed to handle games (in particular wrt games.eclass) in the
>> future. This also includes usage of /usr/games/{bin/lib/share}
>> etc.
>
> For reference, this is the reference decision:
>
> https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
>
> I'm going to open a bug asking games team how they're going to
> proceed.
>
Please let us know when you do; there are a few Humble Bundle games
I'd like to bring to the tree and I, too, don't have much to go on as
far as guidelines beyond our usual.
- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJWtzTvAAoJEAEkDpRQOeFwoOkP/j9cMGWfs3V3yPcc99G9ihqK
H1fdB6RphKNirQ4gEg7ERVoxy4OygTmml2IJwFkHasXqRaau8gwqFpOlPGKqLlga
MeDXTjDl788td0Z8JJJcronqHyEGx3Sw+vv3QKHsgaFuSUuVlnTOrpoXvwO8u7o3
CajRylurE4IhM3SxFnBL5jnBlwnkArixjLdD7jghMqEKzEr8zqGilssgLOSZIIAu
pZf3zoV1/XIYKJC8CeRiNiTYbZ82FnxljW4+QuJx4LA1YAj3bOr2IaTh44Cgcaj5
/pLGB1ZNQyoglUm0dKn4RD7DfZmBLqNTwpzvTJRkPemmVskYHvrbrZ4Q2ADgEwy/
jC/GbhprMsWnsVQ79kUVrbDbd4zEtueyPQWCVSHlq89FpZ5vWTykndxtSZKQKqY7
AFDAllsbg0nh2kbEtN7MFZufY/20I9qO4J6RAm3QRK3ULGiObp5oHEuuExY1ky6g
2vFbjtxdjj1HSk7asTVW2j7VK3p1MllBpJ7zIMfGLIE0BQ/szNsXoNILKC001W0/
ztXx2/XRmbZy/Pk/BTWKrYM95gYh+EzdSQpvNdcUerFiH0nyxfhxvPlWuPTJdZJP
Xxw6fKJGDB599sciv2aOL+T++KNlI+tzHWtfYxosisNblD0i2pMOflzYv6+eYY3q
nXhqwO/kUl451VrvAwb0
=ek/8
-END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/08/2016 01:08 AM, Patrick Lauer wrote: > Ohey, > > I've opened a bug at: > https://bugs.gentoo.org/show_bug.cgi?id=573922 > > The idea here is to change the order of the providers of > virtual/udev. For existing installs this has zero impact. For > stage3 this would mean that eudev is pulled in instead of udev. > > The rationale behind this is: > > * eudev is an in-house fork, and there's more than a dozen distros > already using it by default that are not us. Which is a little bit > weird ... > > * Both udev and eudev have pretty much feature parity, so there > won't be any user-visible changes > > * udev upstream strongly discourages standalone udev (without > systemd) since at least 2012 > > (see for example: > https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516. html > > https://lkml.org/lkml/2012/10/3/618 > ) > > So it'd be (1) following upstreams recommendations and (2) > dogfooding our own tools. I don't see any downsides to this :) > No complaints here. I've used eudev ever since I started using Gentoo back in 2012, to escape systemd. I'm completely okay with us defaulting to eudev. In fact, I wonder why it hasn't already happened. Upstream is actively against Gentoo, after all [1]. Out of curiosity, which distros are shipping with eudev by default? [1]: https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.htm l - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWuIpDAAoJEAEkDpRQOeFwF0AP/3sRQzMUcdLLFyxYSBzjQW4e mzV2xMXknqkkjnNHe/tygAMlB91usZ9m2HJtRMYjqIYj6OlGBOHHdNw01FKpYeSu Ogg7avAge1/cXsFS/ZmxenImG2z6k8Nt+74S5d9QzvC/AyQ8BCBaUI4HVxxb3ULn au7GDRaJ1+sX0A8EsQtKb6UxAO9juueabWu3CeddjLlMnR0FdtyOjAEN7SkPgLy9 oXTwn3eLjvBeY6t1unk3kJD4aOBfZzTupX19hiDr6W6K8mo/q9XwLOcltslerDBO OTsq3HcW+IDgp91bnSEQJnUMUec2Awce1qlDX8Khsybu9qwcfbyICOY4l3uCYCN9 bc5Z5luWwrV5OA64apjdjCxUgJCVv0b92JcNcIJ9F9cMIn2Lxp5xXRNCNCL6PkSW +kVt8w1HeQk1XQXedilThgDzSHBZVjPKJMqjpF6deVXrALR1ZoZ3i17TYkkj7mGx +NHQq3PENUDho7VeujdVyroybaWlBO/B3/GgxCBiybI8R+0YyN14H1W86LlHn4ol jgdPxs07/F/XaV64UEsKsD+2vBKJeRVsYCpinjgfTUciEUyxW2cETobUTd2LoJeq b3SP+DEuAOD8qJwpk/isq6yYnQD9+JPbYGedz1D0vdpj5S82pHO4wZ+iuxnmHIHS dMKUlMc5eb+ykgRLfQmy =c1uf -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/08/2016 04:32 AM, Patrick Lauer wrote: > On 02/08/2016 01:30 PM, Daniel Campbell wrote: >> >> Out of curiosity, which distros are shipping with eudev by >> default? >> > From [1]: > > """ 1. AUSTRUMI switched to eudev in March 2013 (see package list > for the 2.6.8 release). > > 2. Parted Magic switched to eudev in August 2013. > > 3. Quirky (experimental version of Puppy Linux) switched to eudev > in December 2013. > > 4. 0linux switched to eudev in February 2014 (see base packages for > the eta release). > > 5. Linux From Scratch (standard version) switched to eudev in March > 2014 (see this commit). > > 6. Vine Linux switched to eudev in June 2014. > > 7. Funtoo Linux switched to eudev in June 2014. > > 8. CRUX switched to eudev in July 2014. > > 9. Void Linux switched to eudev in July 2014 (see this commit). > > 10. Guix System Distribution switched to eudev in September 2014. > > 11. NuTyX switched to eudev in October 2014 (see system packages > for the Saravane release). > > 12. Puppy Linux (standard version) switched to eudev in October > 2014 (see package list for the 6.0 tahrpup release). > > 13. Manjaro Linux (OpenRC edition) has used eudev since the > initial release in December 2014. > > 14. Calculate Linux switched to eudev in April 2015. > > 15. Alpine Linux (desktop edition) switched to eudev in July 2015. > """ > > [1] https://forums.gentoo.org/viewtopic-t-1003230.html > > > Wow, that's actually pretty great news. That's enough 'momentum' to maybe maintain a smaller ecosystem free of any particular init-system preference! Thanks for sharing! While I was going over some previous stuff I'd written, I noticed you were actually part of some Debian mailing list discussions from a few years ago. Kinda funny how things work out, huh? :) - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWuIwHAAoJEAEkDpRQOeFwDM8P/3jy7+sTp7iElztIcmpmNbE9 GkPNmhk1/tQh6gRn1Ho7lJl8FxF5DiY1o2HxjtITztGb0O4nm1ENbiBKx8JF/X0u 02KBD2WakTTK/sVOmTeN5EqnRFlQJ4PQfSAGsgzLbi/9Ky7IoNHalef2FM+ZSi6A GrTHSgK8Elhnzblplz1SyAJ+iqE+AR9oNdwS6/7uraRi2t6gIGLBaWfhUwK3HVxn h+mybPrbEuVxAC/Xen8iy4F1w75S1JI9I5FRwgh6farhDqMMjd920BbxePzA7j/h VTnDSnjVQKE28un6RvdhWqWsxfVdmemSOpsQuuUOh3Mn3qjtYvK+wYQxxclmct4T L7qjv6KwidGIA/EV1O7DmRf81xgpV0pTqdfMT7WONItgV+ltl9hz+eoHHx2aFekD T4zCY0kEjt8hXK+4S04eVL6clspmHXp45MaA1JIaY/qxrRKJYu88+FalgQiDcm/X 38oyu3gJq0FZ9B3jLa/qEVn+Df6BA7cSbPufJOcr35DjaDBZnJbo+qLNb4GPo74P SQ0iUBBfxIXOOMA14f2iByfXhtnCZaZVq3+CkC9FjQwXwkwKSxuLwi+hqf48EIPb 71ITD4N/Kjt50ajzgbfI0A09PDv//j3tWorU83ep0gIM02sGpjsxoGxPL+cWKOh4 +KhWxuCbPEXbpIq935hQ =5rjF -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/08/2016 04:46 AM, Michał Górny wrote: > On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer > wrote: > >> Ohey, >> >> I've opened a bug at: >> https://bugs.gentoo.org/show_bug.cgi?id=573922 >> >> The idea here is to change the order of the providers of >> virtual/udev. For existing installs this has zero impact. For >> stage3 this would mean that eudev is pulled in instead of udev. >> >> The rationale behind this is: >> >> * eudev is an in-house fork, and there's more than a dozen >> distros already using it by default that are not us. Which is a >> little bit weird ... > > That's not an argument. I can also fork random system components. > Would you consider that a reason to replace the defaults with our > 'in-house' forks? > >> * Both udev and eudev have pretty much feature parity, so there >> won't be any user-visible changes >> >> * udev upstream strongly discourages standalone udev (without >> systemd) since at least 2012 >> >> (see for example: >> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516 .html >> >> https://lkml.org/lkml/2012/10/3/618 >> ) >> >> So it'd be (1) following upstreams recommendations and (2) >> dogfooding our own tools. I don't see any downsides to this :) > > I'm strongly against this, because: > > 1. It is a conflict-induced fork. As such, it will never be merged > upstream and it will never be supported upstream. In fact, it is > continually forces to follow upstream changes and adapt to them. > eudev is more likely to break because of the Gentoo developer(s) > working hard to merge upstream changes to their incompatible code. > > 2. Many of Gentoo users are programmers who appreciate the > 'vanilla' API experience Gentoo often provides. Switching the > defaults to a fork that is known to intentionally diverge from > upstream goes against that principle. Programs written against > eudev may not work correctly with upstream udev. > > 3. eudev has fallen behind systemd/udev more than once in the > past, and caused visible breakage to users this way. > > 4. eudev is underdocumented, and the maintainer admits that 'he > sucks at documenting'. In fact, did anyone even bother to note how > far eudev diverges from upstream udev to this point? > May I ask which meaningful effects this has on systems that don't already run systemd? As it stands, upstream udev is one step (kdbus) away from full reliance on specific kernel and systemd versions. Which features of eudev have fallen behind enough to create breakage for users that use non-systemd init systems? Given that eudev's purpose is to be init-agnostic, I would argue it's more in line with Gentoo's general goals and upstream is hostile enough to Gentoo's efforts to deliberately structure their software in a fashion that makes life harder for us. There's certainly no harm in considering them upstream and perhaps modeling eudev's updates/patches after theirs, but given upstream's goals to coerce everyone into using their init system, what workable long-term solution is there? A fork was really the only pragmatic approach here. This reminds me of the ffmpeg/libav issue. Thankfully since we've gotten past that, eudev/udev should be a simpler matter because we have prior experience to go off of. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWuJB9AAoJEAEkDpRQOeFwR74QAJ0a+uFI7E4Gmf6QGWe4t+lH hWrmflClGOcDOiP6imVTU+yrtL/f/aHAQUG4whfDRzc3zR4uBtpjhIKgPEdAsyFh aSvuOVjon6hEEvE2UA3SAOJErAD8bhGKDNArtLpLuWP9Ekjv7InL8EVFKfMbR/j2 tQMInjCip5BV9jf++9D/Nia46ilc/65eQz9k4jpqedVlZjGn/RIxpJXcKQAtdMPn JZ3w2n2przirn9hVQn7MZc4tBIPARnC1G/s7BC2pvGvbVwHTKZrkKhdS8kTWHJzk ME93G1HGRYJrSsHU0U0GSmbh+tC/1xAJFjcXG8+fi/dBjtYEyveMIQB66fVHkcvH pYuHeZ+uiuCvhRkOETYC6A92FFSQe41ofHf0JQx1OW0Br/mric74z5rg5BDA4bx7 22TrnN2M+cP2CC5jQi61rQ22Xh6jZ3x6EHuMN55iebuR7TuUBYBmT/qX1hvyubHl TPAKoxFnkhxcC9Ioe2lEpQxYdugQ0wxhUwQOvGsb/O1wU3WhX6ADWOavElhL7qHO 5vTiC6uq5ACz/qiwQ6QJU4ocSaJ1/qBTPFpp+WxeDryAEzmnjmiic/Uv0HGYWRaE 4GR0Kjv2AWuz4xEIbGKFadivUjTMVJHgW1CR2b8LId11UloEbjBBz48ar/fMS1xP ve4SvOASasKCk1Cc3uxV =LzE5 -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/08/2016 08:18 AM, Rich Freeman wrote: > On 2/8/16, Patrick Lauer wrote: >> The idea here is to change the order of the providers of >> virtual/udev. For existing installs this has zero impact. For >> stage3 this would mean that eudev is pulled in instead of udev. > > Might I suggest a slightly different approach. I don't really have > a strong preference on the order of providers in this virtual, > though I don't really care for a direction of promoting in-house > tools over standardized ones (genkernel is another one that comes > to mind). Gentoo's distinctiveness should come from being > source-based and offering choices, not from a large collection of > internal forks (I have nothing against people working on them, but > they shouldn't be the default experience). > > However, I think we're actually missing the bigger issue here. Why > is this virtual even in @system to begin with? When I set up a > chroot or some kinds of containers I don't need udev, or sysvinit > (or openssh - but let's set that one aside for now). > > We don't stick grub or genkernel or even gentoo-sources in our > stage3s. Why stick (e)udev in there? > > It seems like this should just be another step in the handbook - > pick your desired device manager. > > Obviously if we produce a boot CD it will need a device manager > (and kernel and bootloader and network manager), and I don't care > which one it is. > > This just seems more like the Gentoo way, and it completely > sidesteps all the controversy over defaults. We're already working > on fixing the few remaining functions.sh references so that openrc > can be removed from the system set as well. > ++ from me. I hadn't considered just considering it another option. [e]udev isn't the only device manager out there, and currently Gentooers must explore that *after* installation. If someone comes to Gentoo knowing they want mdev and runit, for example, maybe we should at least briefly mention them in the Handbook and point to their wiki pages for more information. Defaults don't have to be blessed. I'm also in favor of keeping @system small. If that means migration to stage4s for the average user and stage3s remain a thing, I'm okay with that. We just need solid means to maintain choice and be honest about the options available when building a system, imo. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWuTbWAAoJEAEkDpRQOeFw9FYQAKz8BfptTmFwH6/fGJDZYuuI xQIh9uLWnd5CpRt4KgXhJWzN3DQvAA5/9iupiEfqZOMP/Iissjdc02ZQ/EmDceB3 sze+sqKMKrvEm0IaMkTK7J451NkLLODBkw1zQdZmruhkzx46C+4B8lnnyN5eewKd cHP77EuDtGpFkq62ZfTwnk7iz4omiRqHUEJLq3nagEtKby109VM5FhSUpdbCgXOl tRRrElgxroDeoV/nRjCLpXetMP7IMyKKyyS/6IH5FVLV31oWwyfhG9TE3MKmCVFo xQeH0rALr7RrPKaGCbD32rFLl1dTedHI0x1hROl4jtPxRNoWcVQ2096l2wVdCzo5 42fkRvwuhro/v+ABcCj4ysdkfLLeEAS0S89vc+w7QGviKDHjXDjKwIxpeDnACUeT qvHucT8glTVbCZPseD9z5iRTtnS8JIi2T8qVtYT3ULo5YH8Xcfy0M2htfusAMONS 07UOhIrZzhLOI6mEwYOHHkOiWzWpBy6JtpVVHzmw38eB1szmGSFBHl5pV2mmaqw7 0kYQ9/OX74QcFwxUnyEbl7gAJRnu15J6Zzk2wl+uVrMMgoL8uZ7B4JLGLx4772AH HFxwlzdCuXtBQxOc7dL1OfW/DZkFg8JnDLxBKeTH8F0L1gX/Fe/vnekPUlKRj+y9 xtg0rCeg3gel+wbN/fWk =iWI6 -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/08/2016 11:43 PM, waltd...@waltdnes.org wrote: > How difficult would it be to make it an install-time choice, like > the bootloader? Not very. It would need proper documentation, however, and at least indications on limitations or consequences of choices. If we were to add a device manager step to the handbook, it would be poor form to focus on just systemd-udev vs eudev. There's mdev and a few other alternatives out there as well, and they deserve at least a mention-in-passing, so people know what all is available in the tree. Otherwise, I agree that when considering eudev, blueness is basically our upstream. Him being a Gentoo dev is coincidental and just allows him to support Gentoo better. As he mentioned, he's upstream to multiple distros, so I see no reason why Gentoo can't be considered downstream while he's working on eudev. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWudk9AAoJEAEkDpRQOeFwT4QP/iOlBrMlGzlr9PBhpqtqk/RK DqOfeDs5Oxw5rhKt3WY1CuIZeoIzyXa7ribdfHdpTJ6nuEWYATcwFBLonsmPpo0v 9QvSIXaBOA4QKkVtt9dM3SL2X3JiEKIoPMKdDMfmH4kGYLDtzMLRQWwePx7ii8Gv vTA7ooTaYTkNtPxYaCn5RUymVQM0mOPpK7CF+BmxiOKFo6RezkHSo2lwN3YPUOBb xutm2JtQlKfr7efgWdJ1tb8XHbm1Q0UYP8myoFd3Fu20MBSk1F6KmAVlkniCbAZJ DO9qrvv9Sgcp6XCB+Uy4Zx4OOUz5noZSC3COQ3XOwxw+bSHtjik9NBZU3k2fs5cI Os2QJVNPNBpZHnNFvw4IA6iyLa2FFDIf/2FsqZyrNtt3GipqeR6YQqBHYD8KOXnf 55kQFphOlm5L2KkNe15TPwsNolMJq59RwSdJ0u+5qKX3TgABGvFMWYZZrdQYIZPH /zK1s3wpeBudUPjgXQnok2Q6FD4mT5WHsgBnYxAYmYwd5WMjDz6uDYRVmgFV8RHi qB2H2wjQ1fg/d9W0rFlII/Ml1n/sXjqjc53EGA5Ik3s2uy9WWMHSTxV59pAuplL2 pHIIUu96hJJ9BtkPzQFWSL2+/y6hT+VdZpPAbKJBai/vezax4mq1xJdEbGpeALlt 4emEaPNpHav1iAN/3Wwv =X02j -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 01:03 AM, Kent Fredric wrote: > On 9 February 2016 at 18:27, Anthony G. Basile > wrote: >> all the vitriolic attacks i get about eudev come from the gentoo >> community. outside of this community i get praise. > > > In case my earlier messages stating a desire to exercise much > caution gave the wrong impression, I just want to state for the > record I think its awesome eudev exists, and I think its awesome > other distro's are using it. > > Just when it comes to "Change the defaults", I want to be certain > about the path we're setting ourselves up for on this very > important component, because here, a change of defaults paves a > broader path for eudev to be a potential leading competition to > systemd. > > Because if we do that, I feel we must be so sure of ourselves that > eudev can be a profitable choice for at least a moderately long > term, even in the event we get no more support from the systemd > codebase. > > Having it in tree and having users who know what they're doing > being able to choose their own risk factors and say "yeah, eudev is > the right choice for what I'm doing" is one thing. > > But stating implicitly that "Hey, this is the default", this needs > to be the *best* recommendation we can make based on all the other > factors and other defaults Gentoo uses. > > Because new users *will* be inclined to pick the default, and > *existing* users of the *current* default are likely to see the > default change, and reason "well, the default has changed, so the > new default is the new best thing", and will be inclined to > switch. > > And the worst thing we could have is a combination of bad defaults > that leads new users to have a poor first experience because they > used all the default recommendations, and their system made magic > smoke instead of booting. > > In short, to change *this* default, it seems pertinent that we > *know* that the change we're making *is* better and a more reliable > long-term choice than the *current* default, and if there is *any > reasonable doubt*, we should delay changing until that reasonable > doubt is expunged. > I can understand your concerns wrt defaults, but I don't know very many Gentoo users that stick to defaults. Part of what draws people to Gentoo is the very fact that you can customize every layer of the stack, from kernel to user-facing GUI applications. The default service manager is OpenRC, and it works great with eudev. I've not had a single issue with eudev since I started using it. It accepted any of the rules I had written for older udev before systemd swallowed it, and I just don't have any issues. I can't think of any reason eudev can't be a drop-in replacement, at least at the current tim e. sys-fs/udev is only for systems that aren't already running systemd, as "!sys-apps/systemd" is in sys-fs/udev's ebuild. Given that systemd+eudev is the only possible combination I can think of that may cause problems, I don't think changing the default from sys-fs/udev to sys-fs/eudev is a problem, at all. The default is currently systemd-udev, and udev's been mostly unchanged since systemd swallowed it, aside from the push for kdbus that the systemd team is pushing the kernel guys to implement. Once *that* happens, eudev will need to either use that interface to maintain "full" feature parity, or fork off on its own. Given that the push for kdbus is more a political API move than anything, I can see eudev sticking to the current interface and working just fine. The kdbus switch is completely internal and people actually using udev won't notice much of anything except the necessity for a new kernel version. If current users of udev end up being required to switch to systemd in order to retain udev, then there will most certainly be more interest in eudev and its development. I see only positives for this. I've used OpenRC and eudev since I started using Gentoo in 2012. I don't predict switching from udev to eudev being difficult for anyone running something like, say, runit, since it's really a drop-in replacement. *after* kdbus is implemented in udev, *maybe*, but unlikely since it's something really low level and there's no way the systemd team would require big changes on the user/admin facing side of things unless you aren't already running systemd. Their goal is to make it so easy that people don't have to inspect the internals, which gives them free reign to start conflicts with other distros and forks. Have there been any real cases of issues switching between the two? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp
Re: [gentoo-dev] Changing order of default virtual/udev provider
that may also be not so much "preference". >> > > And hence my suggestion that we simply get this stuff out of the > stage3s in the first place. Then everybody can just pick the > implementation that best suits their requirements. I can get behind that. This dodges all sorts of arguments regarding initial installations. There's still the issue of the virtual, however; would we add sys-fs/udev to p.mask in non-systemd profiles to clarify the decision, or make eudev the default choice in the virtual? I think we can all agree on making it an additional step in the handbook, but the default is still at hand. > > If you want to talk about default providers, the most > straightforward one to use is systemd. It is what people are going > to be used to coming from other distros, it is what every upstream > package expects to be running anyway, and it is the simpler tool > that does everything that most people want. > > For people who want a more exotic configuration, there are > alternatives, and Gentoo should certainly support using them as > long as people care to maintain them. This is the same argument other distros used before they switched completely to systemd. When has Gentoo ever been about marching to the beat of other distros? Are you advocating for following what others do simply because it's popular? We have nothing to gain by making systemd the default init system, and it would tick off a considerable portion of our userbase, even with it being changeable. It's one thing to put it on the live media, or even as part of (a flavor of) a stage4, but to push for it being a default across the board on a standard install is a bit much. The e-mails I've seen from you in this thread seem out of the ordinary. Has the systemd team been talking with you, or people from other distributions urging for Gentoo to switch? To clarify, there's nothing wrong with systemd as a choice. It's special enough that it has its own set of profiles. I think that's enough, and creates a workable path for both. For this thread, it seems that we need to do something similar with eudev. sys-fs/udev already comes with the systemd profile, and eudev fulfills all the same needs. Maybe we should speak with our users and find out just how many people are using systemd-udev intentionally rather than going along with it as a default, and their reasoning for doing so. The same could go for eudev. Not so much for numbers (because unlike Debian, we have nothing comparable to popcon), but to see where people are standing on it. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWueRSAAoJEAEkDpRQOeFw7DYP/i4hqRWuhSVUZsAXE8DX9GAa vapYjX43fb5S5BzgqS5KVbRWUdDUQNAghyy9kywPUFjjQRArzTF+xX3EmBhj5rUG Agar+BB3fGh19NbvMtwoJ3C+eHBw7aNGkmlj65vpMOmOnZ/7lDZNU0PbZ4GtDdmp FoQ2ooR5+TAV7xZaMRf5liwcptMcIPrOhksvUWtzRPhFjGyJLRtg60xO6hxC5Zc0 yF+hrO8/QNnqIvKn5u1sXAx3GyRE2UZtPX+Fad6Z376gH+8T7CtbqjLT1rxIZedd CYLusg/AdENLsS6EVy6KN5exIH1oAeAqWwtiUS88VURzP7QY7TA3RbCPVVgCFe0M kM2J5JZqlrdCxG935zEk3kiO9dtW4wBQNbjyLD7G3PCkWWnv2eZsP+lk+pFQlIvw +Sfbb4nrtusSu8MYkeLnAQJ3oyt8qYUQN0Ip07Y/5h+3pKizMi/A2NVjLdoH35tx KXnpy5LPYn7Hk7UrVGPdgNQC/GckRcIAgwjH90fvO2cOAV6pdcPAR/VYxaodQeWZ AUZdT6ksmuZuhfBgZBEU2X2ilEVZsDI22egjz5/+FCDZjr2c56cURCP6+GXcW4ao LaM/OoTmHkEQSG4PVTSNE6wXN9lrVx5v/TvH9vDjdViugdzOUHyt58gXiC+Bk8wA XD8LH56ilZGFcoJWdmSR =Ggkl -END PGP SIGNATURE-
Re: [gentoo-dev] "Lazy" use flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 04:27 AM, Kent Fredric wrote: > There's a frequent irritation I experience with the revolving door > of REQUIRED_USE -> auto-unmask: > > There's no mechanism in place to automatically stop using a > "REQUIRED" use flag when it ceases to be necessary. > > So you find yourself doing things like: > > - I want X - X only supports python 2.7 - X thus requires a > dependency that supports both 2.7 and 3.5 to set USE= for python > 2.7 - So you add a USE in your package.use for that dependency. - > This creates a cascade of requiring python 2.7, sometimes > extending to pull extra dependencies for back-ports. > > Later, X adds Python 3.5 support. > > And now you have redundant USE flags in place, and those USE flags > pull in dependencies you no longer need in order to support a > python 2.7 featureset. > > Now, this is not about "python", this is just the general pattern > of ebuilds saying "I need this", and then requiring me to manually > acknowledge "I need this" when I don't actually want this myself, > similar to how packages "I need" go in the world file and don't > get depcleaned, and packages I "don't need" are handled by portage > automatically satisfying dependencies. > > And you have to invest a respectable amount of effort to prune > these un-needed dependencies and features which portage now thinks > "you want", even long after the reason for that is gone. > > What I'd like is a middle ground, a USE specification that can be > stated in package.use that portage interprets as a "permission to > enable" flag, a USE flag that is treated as "ON" if any dependency > states it needs it on, and that is treated as "OFF" as soon as > there are no dependencies in the graph that need it on. > > Or vice versa. > > Naturally, this needn't be part of PMS, because this pertains to > nothing about the package dependency specification itself, only a > feature for user convenience in the portage interface. > > I would love to be able to stop maintaining my reasonably large set > of package.env tricks which I have to regularly update so that > things I don't need will get expunged when I cease to need them, > and I'd love to be able to say something like > > PYTHON_TARGETS="python3_5 python2_7?" and have portage treat the > former as "always on" and the latter as "On if a dependency or > REQUIRED_USE constraint indicated it was needed". > > Though it may not be so straight forward to implement, and is > likely to complicate backtracking though in theory it could > make things simpler. > > So I table this query to the dev ml in the event somebody else > sees merit in the idea. > This is an interesting request, and if it was implemented correctly, could reduce the number of blockers we see. It's almost like automatic USE flag resolution. The problem I see is syntax. I'm not 100% familiar with portage's internals, so I don't know what sort of effects this would have across an entire depgraph or resolution, etc. But it could be very useful. Another concern, though, is it'd result in something similar. Instead of "cat/foo bar baz" and later removing 'baz', you'd have "cat/foo bar ~baz" (with '~baz' as 'enable this if you need to'). You'd still have cruft left in your p.use file, and it would achieve the same result as a well-commented file. I've personally taken to creating little "blocks" of USE flags, even if redundant, and adding a comment just above them explaining why I add them. It's not perfect, but if I get curious and check back on it, I'll always know why I added it. A possible solution to the file issue is some way of letting the user know prior to merging that a "lazy" USE flag was specified that's no longer needed. That could be somewhat easy to implement, as it would merely check REQUIRED_USE and compare it against any lazy flags. If they match, show the message. Regardless, I think it's a neat idea. I'm just not sure if it'd be something easily implementable in portage/emerge. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWueZFAAoJEAEkDpRQOeFwDxcP/AhRuCsjXm9jjEhT1vfagj9t 7imcFj6czggxBno9Bg5lZFkkU80lPG56wTq6MHAMF7DSwj3HxW1dwLbQSSqQHCLJ 5VzqXM74h5v4TBK24Fq5ht+sN6U3uO5JmaCv2qXg3xiWu34AapdVsCHq+JO2ew/y quIF18TmpdGbRpnzyXCkdySvqI8GfJYVrFXJsvNN/2H0qgTmS5LQsnqxP6hGhHkc
Re: [gentoo-dev] "Lazy" use flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 05:19 AM, Kent Fredric wrote: > On 10 February 2016 at 02:14, Daniel Campbell > wrote: >> Another concern, though, is it'd result in something similar. >> Instead of "cat/foo bar baz" and later removing 'baz', you'd have >> "cat/foo bar ~baz" (with '~baz' as 'enable this if you need to'). >> You'd still have cruft left in your p.use file, and it would >> achieve the same result as a well-commented file. > > > Granted you'd still have the cruft in your config files, but it > would become mostly-harmless cruft, not cruft that caused needless > dependencies to get pulled into the dependency tree as a > side-effect. > > And because it would be "only as needed", you could afford to use > some of those "only if needed" useflags in a more global manner. > > For instance, I really don't want to globally define PYTHON_TARGETS > to include python2_7, because it will simply install a lot of > extra things I know I don't need. > > But if I could globally define something to the effect of > "anything that wants python2.7 support can have it", then that's > acceptable globally, because the effect would still turn things on > automatically on a per-page level, not at a global level. > > So you could achieve the same results with much less syntax and > much less effort. > I can certainly see the benefit here, but wouldn't that still result in (arguably) unnecessary (re)builds? If implemented well it'd also result in depcleaning them when they're later unneeded, too, so I guess it's a wash in that sense. Again, I'm not against it. In fact I'd probably use it, because some packages are really picky. I just don't know how well it would fit into the existing design at the code level. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWuegpAAoJEAEkDpRQOeFwoYIQALeAXnPOXzrC10AWplSt0K9D O3Mp8KpiMMUfIi1neM2LQAfW6Kp3lA9CaA547TdJ2ZXBJdTSfwPMe5rsWY2wqavD UvASgl4Ja4molsM3mQX3rYWbbzjZN38mZmYby26mPwyo8kAeXeqqIFDpPyG3F11M 0uT0lCg8W6q6qs00l02SZHmQKGQwCL4JLXNe9mj8WLcoaeMZjXwDCS3lhLz2L7at bveIm/yk5JaPSc3i8zcwmjDyoJ2fQg+1u2ujl+MzgVcxY8pfSnJN0q4CV06rC4xt 7F65OU8DhzaNr80UUfKCNdfVXwIlDNIEK1mz/tRe3Ad4bW1NW5DJFpm9xjpSPSlD Cse2GNBTxKYDi/mxlLBenCyqHta05TyzdqDODiOJRMzIXRf2jcPtOkg58tdUMl8D xw/qIFwcUeC44RfX9Kb9NkQcxuhyuLSPBcnGGdxeaUtJf92wpw4AINfSLj2B8nwv XyPan9bGku6gsG6C5oQ0JUsGdNu/qmukUieppE4yKbFgjzoIZcuOb18jKyDaxVKh QiQ9uI2xGvQYqAHVAraykAoBEl7EHISRRLn508VB8WZUxV39q5BwYtpYrxAJtSEY 60NuTTKmU7CXK4czHukrKPpkwkqNGIBgK1/m7dVpXjxcXfk/cdcwilv3EmO7f6fb XKundbhCB5ek42OGqTuG =+Yx3 -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 05:44 AM, Rich Freeman wrote: > On Tue, Feb 9, 2016 at 8:06 AM, Daniel Campbell > wrote: >> >> Perhaps that's because each of those things should not actually >> be considered the same object type. That sort of design may be >> convenient to users, but is more akin to treating everything like >> a nail when you have a hammer. >> >> Also note that in the 'alternate' model, each of the above is >> handled by a different tool. It's obvious that using a >> combination of different tools will result in different >> conceptualizations of each of those parts in a system. I see >> little benefit in a single project pretending to understand >> everything about each of them. > > I thought the whole beauty of unix was the everything-is-a-file > design? Isn't there a bit more to it than that? We can take any design idea, apply it to an extreme, and see where it won't work. Plan9 is a 'more proper UNIX' and somehow does a bunch of things exclusively through the filesystem. I think that design can be great for some things. For a lot of the above, even the disparate set of tools interfaces with files. `crontab -e` edits a file, device nodes have been in the filesystem for forever, mounts have historically been managed by fstab and need a place in the filesystem to mount, etc. The primary difference here is systemd throws it into one directory tree instead of multiple. Systemd is great if you agree with the design decisions made. That's the problem/benefit with both approaches. If you go with systemd, you have to like or agree with every change they make or every design decision on everything. With multiple tools, you can pick and choose. If I don't like my cron implementation, I can swap it out with another one. If I was with systemd and didn't like it, I'd have to recompile systemd to remove the feature (assuming it's not required like logind), and replace it with a standalone cron service, managing it with systemd. I could be lazy and leave systemd running and just add the cron service, but that would needlessly complicate things and may end up doubling cronjobs. Politics aside, the dichotomy caused by systemd comes down between groups of people that either don't care about their lower level system (or agree with its design) and people who either disagree with systemd's design and/or want to be able to swap things out when they get pissed at the way one component is acting. Systemd is an all-or-nothing choice, and among a population that fiercely values choices, that can understandably make them concerned. That said, systemd still deserves to be treated as a choice. > >> >> If I didn't know any better I'd say this reads like shilling. >> Firstly, there's a real problem if you're depending on a daemon >> restarting itself. Why is it stopping in the first place? If it's >> stopping, something wrong is happening and restarting it *isn't* >> going to fix it. > > Sure, but then why does the linux kernel have an option to > auto-reboot after a panic? Surely it is better if there is a > kernel panic to just leave the server down for a few days until an > admin shows up to debug the kernel? I see where you're coming from, but there are situations where you really *do* want that server to stay down. What sort of data is on that server? What purpose is it fulfilling? If it's a webserver, its failure will be obvious, immediately apparent, and odds are someone is on-call to manage it. If you're holding important data like a government agency, you likely have someone on-call as well, but do you want a compromised server rebooting continuously as a cracker or some other entity is trying to take advantage of a kernel bug? The correct course of action there is to let it fail, get your staff to the machine, isolate it from the network, and start triaging. There are still cases where I suppose you'd want auto-reboot, but I can't imagine they'd be the correct answer for the problem at hand. > >> >> Existing permission systems handle a lot of cases. *kit (logind, >> is more like it) has some extra things to make it a bit more >> granular. It's mostly unneeded complexity. The biggest benefit >> logind brings to a system is multi-seat capability. > > Emphasis on "existing permission systemS" - again you're comparing > a patchwork of different solutions to a problem vs a harmonized > solution. It's more like "which would you like to use?" Using them in tandem is asking for issues, but generally the sudoers file itself and a few groups can handle that for you, or acls, or (maybe?) LDAP. There's many ways t
Re: [gentoo-dev] Hardware database
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 05:55 AM, Urbain YANG wrote: > Thank you very much! > > And wish it will be merged into Portage soon. > > > Urbain YANG urbain.y...@qq.com <mailto:urbain.y...@qq.com> > > > > >> 在 2016年2月9日，下午9:33，Ponomarenko Andrey >> > <mailto:andrewponomare...@yandex.ru>> 写道： >> >> Hello, >> >> I have released a new version of the hardware probe tool — HW >> Probe 1.0, that supports Gentoo and some other popular Linux >> distributions. The "probe" is a snapshot of the hardware state >> including a list of devices on board and system logs. The primary >> purpose of the tool is to share the probe of the computer with >> developers or other users for the collaborative debugging of >> hardware problems on it. >> >> All probes are uploaded to the central database at >> http://linux-hardware.org/ that holds probed information in a >> structured form. You can find, for example, in which computer >> models is presented some device, what driver was used and how it >> was configured. You can check for failures in logs related to a >> problem device and so on. >> >> The source code of the tool is available here: >> https://github.com/linuxhw/hw-probe >> >> Thank you. >> > If nobody's already started doing the work, one could file a bug on our tracker and request an ebuild to be written. Or one could read the devmanual and put one together. If someone is interested in maintaining that ebuild, one of our proxy-maintainers may be interested in helping. Check it out some time. :) https://bugs.gentoo.org https://devmanual.gentoo.org - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWufvpAAoJEAEkDpRQOeFwrJcP/2Z1bM05sK9DHsfwP5JgDVK9 CwRjiduTPw7VEx60tRliI3xZIgecuVlUy70qEnnxzeVp38ART481S/naVu4K7txe bsoUX6ufM9Vnh4bk2mhVzZZtC5fp9rO05PleX3pCyAslF3613pyDTm6qYqZS6Plu oVR0KrQEnGnPEqwj1oeQ9ZgYL01nIj0nkYhoTAnz2IpZKA8PE57QzIRVqDMjvVY0 uOOWoZ+8jV2wRTxkJviijWz9DW84qUqLDCPRw7jt7CUh2R/NA2HrAJf+virb1k63 DmDYlYLBAN0uf7P6Kq8a+No/t4B2MquPRA076cAZQ3Fnm8qFbABZvyc4F7cWDzJ1 +AZBCbAMClVzKKEjDwiVsN1TtclkOHhuu+OrX6oCvV8Aq5Nwj3YrYJAaCGYjuhD9 /5RP4FMwo3Hk9tu8X8GOfEk3Ur/RuDbmlS2kozG56lk4a2Q0kj5RB+McV8L86fvO 5pJkzO/lffynYm3AlgVmT70gKkjQibbW5848oiICo8B5SZ0D1sGEFAEGlH5N2Fdd xJILe8sDeGHUW5YgtN2icqBgJNzVWbTfrwsrJfQGDFQMoCSrCsGtqPi8WZjJUCpp 9ulBU2nw48lU5uEZI8nu3qLuaKtOyN3WqLZGEUY+lYyXbJtXRQypvWj1T3ZzhSjG J00wVwHVKsgTBDtS/UIL =VUz2 -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
e everything else. To my knowledge we don't even mention runit, minit, or other options in the handbook. I think the only people who can rightfully complain about lack of attention or coverage are those who are using these lesser-known or lesser-used systems. Maybe we can get some users to step up to the plate and contribute to the documentation. > > And that is the frustration that caused me to lash out a bit on > this topic. However, this really isn't appropriate. This isn't > holding back systemd, and doesn't really have anything to do with > systemd at all. This is about making Gentoo better for people who > have made the choice not to use systemd, and that isn't something > any of us should be holding back. If I want to make things better > for systemd users there are plenty of areas that I could better > invest this energy. > > So, thanks for bearing with me. > Good points, I agree. Thanks for being willing to see the other side, and dealing with my offhanded remarks. It seems we've reached a pretty good understanding. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWunqRAAoJEAEkDpRQOeFwNtoQAMYBLO1l3DiXmemuWvQ6m04S nHHMYiQNyW3o/Y421ScixKJKLaXrrLcE0OmRqC7jU2iOcm9JC1zcGQNNxdFPGI8o nRl4be4qMEHxyU78NsQ9JWErf2RI1EezpT5gq5Gi2wA1go1rIa6fiI6UKc3WtYbL RzwZK9ku9VJesXIPUBo7kTTQaciv8J6VLMMDpvunUORvfnHM2MlwW0/GRkfK9Iyl nPso1Qj2X8kt3+PiBAoW3wkV9eFtEDlXAht51T18/1jSOuTmRBAGAZ9/XEHM7keY 6vLUSUUSVMrbE189WvSDX5Y1HMHeiYo7t5+ffL+gSDpqLu3eLKm0AUM2yYP3XuCn EKENCUkzx9sa0lWSPYOi2CXPE79XPTqQguUzt+4Lyx+9Lurmuhvq+QswlRRtA41q /hf6vZgC8VYas7e3Oky8tP0XWoYRIm3QeIAMsL7F00V/bNONh3rpQt9707FFmqeJ tAGn4moufWID/SaWSh6w94mAO0wnVCUyB/Spnl1gchrt8kAKzvfISabVf7z8XCHi az5rVl/JOubYZd1LS9iEjvjQTdwlO9YTkvZ3RfRIIjtNG4WCJ5fYto1v9dMRK1rC qnGmm+gsuTG8phwmoChA7myMyC2fwYdKc9J293B+YXnDwK4e5FQzTS0uHsb3J9QX BtUPq58Zw0BjOICrsIs8 =FYyN -END PGP SIGNATURE-
Re: [gentoo-dev] "Lazy" use flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/09/2016 07:08 PM, Gordon Pettey wrote: > > On Tue, Feb 9, 2016 at 7:19 AM, Kent Fredric > mailto:kentfred...@gmail.com>> wrote: > > On 10 February 2016 at 02:14, Daniel Campbell <mailto:z...@gentoo.org>> wrote: >> Another concern, though, is it'd result in something similar. >> Instead of "cat/foo bar baz" and later removing 'baz', you'd have >> "cat/foo bar ~baz" (with '~baz' as 'enable this if you need to'). >> You'd still have cruft left in your p.use file, and it would >> achieve the same result as a well-commented file. > > > Granted you'd still have the cruft in your config files, but it > would become mostly-harmless cruft, not cruft that caused needless > dependencies to get pulled into the dependency tree as a > side-effect. > > And because it would be "only as needed", you could afford to use > some of those "only if needed" useflags in a more global manner. > > For instance, I really don't want to globally define PYTHON_TARGETS > to include python2_7, because it will simply install a lot of > extra things I know I don't need. > > But if I could globally define something to the effect of > "anything that wants python2.7 support can have it", then that's > acceptable globally, because the effect would still turn things on > automatically on a per-page level, not at a global level. > > So you could achieve the same results with much less syntax and > much less effort. > > > A distinct behavior for +USE (as opposed to -USE and USE) would > fit better than "~USE" IMHO, where the plus means "add if (and only > if) required" and would cascade through dependencies, so if I merge > e.g. app-portage/pfl with USE="+PYTHON_TARGETS_PYTHON2_7" it would > apply that to dependencies as required. ~USE might fit for > something like "~PYTHON_TARGETS_PYTHON3", where it would select the > greatest flag matching that prefix, and would therefore > automatically keep packages that have 3_2, 3_3, 3_4, 3_5 using > whatever is the latest unmasked flag. Could potentially combine the > prefixes, e.g. "~+PYTHON_TARGETS_PYTHON3" to both select the > greatest python version AND cascade to dependencies. The ~ was just a spitballed idea. It's really not important *what* the symbol is, it's just that one would be required. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWuq6mAAoJEAEkDpRQOeFwiGsQANMRonEdPVxs5wgG2XFB3bMf +jTirnBZX0fH4wwaWy7eN5n1oaivepcup7XjUkiXuoqdyZmvZrb1ttwU/vrjaDZn 82rpP+7s9gNqSphifhGcf/EHTZo49VMZUEOBNElj0YtbEa3bcjG/vCpCgxnPuhVr 7LxuTtT0pDZd1mqMBLi+g5XYmDSfls2T2PWO3formcPYs5B3Xf4Dkc2jWEl7mEsB neDtxkQoXkkuHX3y3uCwXb0KbGKEMenIA+1XiPP9P7nDSaagW+V0DXUWP5aCjTxB csgiOrOdLEO1305eOkk7kxxoZIRoEgvtlSIA5G0R38+23A0Nwo/F0KV3hMjyBcbi S6QuMrvwCgWiUIjgzd0zbI1+81EaHErn5zb6asdj78SaC5nzIbmRdw/zI+s4RIm0 8rw6RBsnDsP4Iah/kJHqMBdtDA7my7ImWKkKuWtAfeJfrYheDMb/NwMfl2L7/hIY jKa0YuZ8P0TnU5xROFlIyXUILXMK/be5KA7RSQe16UMNGLsJLJ/5KBv2KQbJ2fqX DBQG/780jZBNRAVFRimJ4v1S6g/+BJixN6ajZBe2tBjCV70ina7uL5H1K7cenvE5 0U2M0yl/K9QmEOJQoaR2iwTQL4fbRyr1ntbvlHWwE82rMKdQO2FwJxBj2yhEWELh CAlwuL8k7LaFGVoQhQhb =mkla -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/10/2016 05:15 PM, Ian Stakenvicius wrote: > On 10/02/16 12:09 PM, Brian Dolbec wrote: >> On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs >> wrote: > > >>>> Often the decision to procrastinate is a decision that is >>>> rewarded. That should be considered carefully. >>> >>> + 1. >>> >>> I also saw another issue that made me shudder. If we change the >>> default to eudev, people who are running separate /usr are >>> going to think they can kill their initramfs's, because people >>> in gentoo conflated the separate /usr and initramfs issue with >>> udev [1]. >>> >>> William >>> >>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4 > >> That isn't a worthwhile reason to procrastinate. IMO we're going >> to get those _ANYWAY_ no matter how long we wait, within reason >> of course. > >> There will always be users that can't read/type/whatever and >> fail and file bugs. > >> So if we have to wait for one (or more) users to forget about the >> initramfs crud & confusion, we'll be waiting 20 years. By then >> even systemd will have been replaced by something else... > > > > Yeah I second this -- it was decided officially by council (what, > 2 years ago now?) that separate-/usr-without-initramfs doesn't need > to be officially supported anymore, and so if things break that it > is up to end-users to ensure they pick up the pieces. > > Although it is likely that eudev *will* keep installation onto / > and out of /usr to help with this not-officially-supported > situation in Gentoo, that doesn't mean the other projects have to > stay out of /usr, and "it worked before the upgrade but doesn't > now" certainly doesn't mean it's a valid bug. If a user or > sysadmin drops their initramfs when they have a separate-/usr > system, any resulting breakage is on them. > +1 - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWu+NnAAoJEAEkDpRQOeFw/YsQAMFID91JxR9xNYhZ3o6yDb3B nha3mIgYbkFuQ4LtBQGFZo5r4NzW7tlre6Jc+Rw3nErej59HmasuQQrpZI0alBYA SMhtlTlfz5B3fWZ2lWTBAQZcPp3mBUVHRFGOAqWNxYIHbRkqiBjLhR98xzrsJLOb JOfDuHRWaXi8XELebEVhH99UgAezQOtwMQyKi79jkTSkVlSdw+rLfJn4e56QzVdU UTRgbVmxTgVlHw2y0GLgSCWGS7UxXaXGp5Bds8sM1nDq/YtEZBnd5M8ApMRPneLo CjIdtwueTgDkZsVH/KBNJMXz0u6383nN7I96Hsp19046M9AEHpvvitQH7Sxv7Dye agr1YMqSar/uYQltW94qjKG9bR6HzN9YEBtwUxpbUM4FcibcgXlfdW8eBAhwAXaX xVC3KD4XJzZbRa65kouiYLBNDm6uY7af8ehF7r0ZEn2iZTzDi2UH4GAbczM+y1om jDWq7q5H4Mfiq17bz/n8f3Q7qW+SBY4WY1fTQefYYTLNoK2OPTABNYxg6Oko+M8/ dUJNWSV3+henEsaeRUo/sM6G+zw6pQSJubbwPc65756U6r2nYtDjEO6ebPknD504 qhywzdVLMNZh6C14gxQjgI8SkDY5Rl5eexbUDDzOjZI5eM1CxNO3gSTic6+LjiOi SmUwjZD6f618Xg2MQjPR =d5dN -END PGP SIGNATURE-
Re: [gentoo-dev] "Lazy" use flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/10/2016 06:51 PM, Rich Freeman wrote: > On Wed, Feb 10, 2016 at 9:18 PM, Kent Fredric > wrote: >> >> Hence, this requires me to lie to portage about what my >> preferences are to get it to play ball, constantly going "Hey >> portage, I actually want python 2.7 shit, please install it". >> > > In this case you just wouldn't enable python 2.7 support, but you > wouldn't disable it either. Portage would just pull it in where it > is needed. > > Ditto for stuff like 32-bit support for half the libraries on your > system when you're using something like wine. Just don't set the > flag except explicitly if you actually need it somewhere, and it > will get pulled in where it is needed, and go away when it is no > longer needed. > > The idea is that USE flags would behave the same way as > package-versions. If portage needs it then it gets installed, and > when it isn't needed it gets depcleaned. > re multilib, under what configuration does abi_x86_32 get set on its own? With a blank ABI_X86 variable in make.conf? Every 32-bit package I've ever pulled in has needed that flag set, and I've had to manually set it until blockers are resolved. I've not set -abi_x86_32 globally or anything like that. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWvAQBAAoJEAEkDpRQOeFw+xsP/2SZXSXgFFecQ4NTyrKzb6kf Xh70j6zTjnp3D/AMJi8+s4VU7q78KGWEWxofg6kEqENe2bPlMLapeVkzvrI42VZ4 KdIdumh/sbu4ZwA3xEQHoCHRRfE0FQZPwlK16qt0LeiLsIbprlETzRE31d/D5ui3 Atgg9s6ZUWLpZYGkf3afjZpqLJyLijBEu+cUun7hd/zpNu6aKEDd4I5bKjrps/26 2rwW5zRy2qPr1U0nBS8xgQA4QwGmmg3Jtbtk5KeWjOJ3dEvazSjxHOYNv95bbNBj N4leSXdKh33qr3uAWmDfKvQGwS4aNcN/8+7nQ0GwlJda4tT94YO4VvlhO1qe0ip7 dW9NNRlOZ420vFWR7S2dxyeSnyg9+zpSbx4Z3UNYN30Cd/AG17+ON8uRWJmbpRdZ UfU86CdKW8eFHeDn96kGPlJg6Hm/BrnFB+PZCws4v+/nF7POJ4OptQQQ6gFmhf6D M9YciobV4i0bfDuwg7SAQpiyJ1hShe0z4qLmwGpcF/D8IFpv7EjcOxW0syMvlZzq 4PQzlKshnl0YCDhMfCNRsg9ru6FTrWyRlBqaJMeXYez38r91CgRRjKoY3hoqiOxM bkKtWn/eVzE2W+qjz5sP3cSaJzPwJmj3ldiiyVCbYqYFmW6jgIPnWJt6a0Tvr4TN DPnup09W3Kx5W9qmSz+n =GNMb -END PGP SIGNATURE-
Re: [gentoo-dev] "Lazy" use flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/11/2016 04:59 AM, Rich Freeman wrote: > On Wed, Feb 10, 2016 at 10:46 PM, Daniel Campbell > wrote: >> >> On 02/10/2016 06:51 PM, Rich Freeman wrote: >>> >>> Ditto for stuff like 32-bit support for half the libraries on >>> your system when you're using something like wine. Just don't >>> set the flag except explicitly if you actually need it >>> somewhere, and it will get pulled in where it is needed, and >>> go away when it is no longer needed. >>> >> >> re multilib, under what configuration does abi_x86_32 get set on >> its own? With a blank ABI_X86 variable in make.conf? Every >> 32-bit package I've ever pulled in has needed that flag set, and >> I've had to manually set it until blockers are resolved. I've not >> set -abi_x86_32 globally or anything like that. > > We're talking about a proposed portage feature which hasn't been > written yet. None of the behavior described in this thread happens > today. Right now all those abi_x86_32 flags are set explicitly, > which is why my package.use file is about 10x larger than it used > to be. I'm contemplating splitting out the 32-bit stuff into a > separate file and just nuking it every 6-months and allowing > portage to re-create it to try to keep it somewhat manageable. > > And that is the inspiration for this. The current design mixes > true user preferences with stuff added by auto-unmask needed just > to fulfill dependencies. Users should be easily able to > prioritize the one above the other. Indeed, maybe I have a few > 32-bit library preferences which are explicit and now if I go to > nuke then every six months I have to keep track of which ones are > which. > > With the proposed lazy use flags then for the most part 32-bit > support would be automagic for most users. > Okay, I wasn't sure if you were talking what's already here or the main topic. Thanks for clarifying. I think lazy USE would be a big plus for multilib users. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWvR5kAAoJEAEkDpRQOeFwfCoP/2bdwfRQOSG/OZ0HtcTZCGzV UKM8i3Z1kPL7QVgDA24kDDvPwyPDsGIm9x0/fe/UeDlQ3tkSqhQvbBukNXEW0gaJ qMNQBPmnGfGOhr0o0VylvMGZCq4IKGW8hQdBtjA/QTCSKiASAM1j+IjlvBSk1n6V G+eqoGdY50xF8C8tix1ozmA1ZHP49sU1nE1Dnzg+AA3AESgfrxJ2ys9ccB7vwIny dWD5HXzTNjhc4OkiqWSBfO9CESEPe/vKbk5la7HxdVB/auKm52A/O81Bs+8YXHlL IB3k81lpEY08O7lfVzfJqj0uN+7yF6v6pRVwDdnDGbJQCbun5hfmQBlmGYHEEDMf z2SI6eIPkYWlonEgmBOkvu1fZP7gdXs9gPHnsGd3QxdjBiqOyb3AckqcxQDiczKf 1xDs8isXenEtSV4MTjO/JwyJT1sgORn3y+iFvUMDdOtjWFAs4xHMZRiqcgQ9hn+3 Q7PgB1VLw85THQBFtE2s4FtM9H2I9oRPVDM10OEXFiIVtH2Kkh9LWHr/CdkpGt9I MEDt0HH9m6so2JW407BX8nhT6eL8QZCOEzm7zjfMeFNFbbctRtIEhj3DiSPvYIq+ OyRJ7f3zqygwV+wH09y9fmCJ/bJzrIsRARsAw9V/lW4MLLRQ3IfqWfsQG/BSYFWL CLLROLSNbTQR16QxUiJq =/IrH -END PGP SIGNATURE-
Re: [gentoo-dev] "Lazy" use flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/11/2016 04:01 PM, William Hubbs wrote: > I'm just picking a random message in the thread to reply to. > > In the past, we had a feature, I think it was called "auto use", > that would automatically turn on a use flag if the package that was > needed to support it was installed. > > As an example, if we still had this, python_targets_2_7 would be > automatically turned on if dev-lang/python-2.7 was installed. > > Is this along the lines of what we are talking about? > > William > No, lazy USE in this discussion is akin to installing, say, Steam. That requires a lot of packages that must be rebuilt with abi_x86_32. In such a situation, if there was something like USE="~abi_x86_32" (the ~ is just a symbol, it wouldn't have to be that exact symbol), then packages that need that USE flag would automatically use it, and those that don't need it wouldn't be built with it. It's kind of a "I'll allow this USE flag, but only if you need it" instead of what we currently have, which is a hard YES or NO. The in-between case (not clarifying USE flags at all) works fine for packages but not necessarily for USE flags. Installing something like Steam, wine, or Skype requires a huge swath of abi_x86_32 flags. I and others get around this by partitioning these flags to files, but should something in dependencies change, we'll still be building those packages in 32-bit unnecessarily. So it's closer to what we do for dependency resolution on packages, just applied to USE flags. (hopefully I explained well enough) - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWvSNnAAoJEAEkDpRQOeFwVd4P/2h2D31S2jOiafs9PM0In8VD PasOphNcKIQp+SNmN5BRQNieKXKRpSzkQSvb1Sk3UUOsR+36jN23GtvLeYvpEJsg fsjsrZrBs9Wvv/eMK2+OAU1VCXDx4Mbc5uSCc0JM+nNhx2IR9jvfGefto3WD0pC5 Bjg5mP+yB/MZ+IXUaHKVmTtiGo0PM3NRPUOlaOi0icMw5OUFlvY9eQo2z0dEaNrq SDTsm19adaxsygZPiog101KHGZ1NgoYWZcA+sIR97ZU0tIQPBd9RKVcUe7Q/4YOu DH5mSWDyBwsdGY6wVfoNkrWhpL7ZvRqux5C3bicOtep+dvbog5cBAljQOxB39to4 3g/ufouooBk1GIzMFdo3JI3i9DB0rwCY2PLJsMGRQxYdQZo3K75LQDwG78gHOEMD +YOiC/T0zOx6NZ3L4Nfw0ntD0/T0NxiM9IOg2E1hK01W8ehpwCvhriVKR9SyReW4 6pkzMzgJNBUG6T35+hwUbgb1AsM/Pk7Ye21+DWO4ed/7EFj8QlXe0Yk9At9RMTe1 8mdV7oQSvE3BaYhFmsUOgiiiMFqx7IyVmiBUvBVpnmDSxk7NRPSSVl5sP900yDlx eHdy9uazaWgnWYyZU1zKpIAD3wn5Qo3BbdDMj4VC+IsLAvvovSnkOFwEIAGgmrN7 vCz3wmcDozbSh0vXuUWk =X+4h -END PGP SIGNATURE-
Re: [gentoo-dev] "Lazy" use flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/11/2016 05:23 PM, Rich Freeman wrote: > On Thu, Feb 11, 2016 at 7:12 PM, Daniel Campbell > wrote: >> >> No, lazy USE in this discussion is akin to installing, say, >> Steam. That requires a lot of packages that must be rebuilt with >> abi_x86_32. In such a situation, if there was something like >> USE="~abi_x86_32" (the ~ is just a symbol, it wouldn't have to be >> that exact symbol), then packages that need that USE flag would >> automatically use it, and those that don't need it wouldn't be >> built with it. > > Actually, I was proposing that you'd only need USE="~abi_x86_32" > if you set USE="-abi_x86_32" someplace else. Adding a ~ would > just remove any previous settings - it wouldn't cause a use flag to > be turned on or off. You could have a flag like that even without > lazy use flag support - it could be used to cause a single package > to revert to its default use flags. I'm not really sure if it is > a terribly useful feature at all. > > In my proposal you wouldn't need to do anything at all on a > default profile to have USE="abi_x86_32" enabled for packages that > had that use dependency in some other package. Just running emerge > steam would cause rebuilds on anything that didn't already have > 32-bit support which required it. You'd only need to mess with > your flags if you had explicitly set USE="-abi_x86_32" - which > makes sense since you've now given portage two contradicting > directives. > > Just as you don't need to do anything special to have "emerge > chromium" pull in libX11, you wouldn't need to do anything special > to have "emerge chromium" cause hwids to rebuild with USE=usb if it > isn't already built that way, unless you had explicitly set > USE=-usb. > > And of course this should be something that can be turned off, and > users can always run -pv to see what portage is going to do. > Ah, I think I see what you mean now. That's actually a bit more predictable and requires less action on behalf of the user. I'd like to add that, if we do this, could Portage output which USE flags were being automatically added? We already have USE changes indicated with the % suffix, would that be enough in your opinion? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWvTS0AAoJEAEkDpRQOeFwA0UP/14lZ46QTAk3LpZG3hVCaMZa P5xvGECGpInvvgT/A3frHLrAsJ65Aem9vjLpCb43Q7SX3PRSEtVoxJu1ay7EFiwk aLqk9VX/871XTyvpaM8ArLYjzi0Q6KZFSHyxlysoAZPFUImmjIYPzrzd5lVo6tg0 zPyBUvWmyqK2u8gYZtst+3FL2yqBLqzgPg29Xf7+gX9ROtyGbynHWvh1lIgvH0GI 0vI4GqmKVy7UD3yskNEuM5Ra6iGoYwlg7n+BHCiQ7g1dZ7JwH+nP2KOEUsrlLa40 pQS0T03RnfvZZVjhM3DP0lUqZltKcGiZtrLEOe3Nw99hc8w0IDlZOGTG1sqMvkpn JtSih7d+sjk12JI4TR9Kv0UYcaHwKI4AoWpMGkr7zzjJFgPDcalsEooG9ti32y4w VioH4DJ6E76+TgakIWbXEtunPOf1IxqPPEql42Z/Ubq+vB27Cwga23bzZ0ziBh9k BxszTLMTJHvlVOe4gPHdl2DYnmgkDQXevdNgMvj+xmEh7+Jl4w9xexJJWMNQ/Ffo 9gGI9GUBUgEprzjC8tkQxrMaUcrvKRy0Khybd8wv2vpwK9wfrJ4nhXS0Pohbq+m1 Oib2B4K51MC7C+fuUWn8JES88/3zuqUIgNsNRbcUMuBrDot6rwi8GSUmvuur3oGm WRSUDmm6heJADifDBwep =UG0E -END PGP SIGNATURE-
Re: [gentoo-dev] Uncoordinated changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/14/2016 10:53 AM, Patrick Lauer wrote: > On 02/14/2016 07:44 PM, Andreas K. Hüttel wrote: >> On Sunday 14 February 2016 13:18:30 Rich Freeman wrote: >>> Feel free to peruse the various list discussions and council >>> logs. Most of what you're bringing up has come up before. >> Thanks rich0, you seem to be reading my mind. >> >> This is turning into a severe case of "I didn't bother to speak >> up earlier or volunteer to improve something, and now I'm unhappy >> with what was decided and implemented." >> > Silly me for assuming that changes to metadata would not affect > me. Or that tools would be adapted to the changes. > > Or that the changes would make sense. > > I don't have time to follow every little change, so it's quite > annoying to reverse-engineer this change that apparently is a > compromise that no one actually wanted, and hasn't really been > finished yet. Sigh. > To be fair, if you're working on a piece of software that depends on parsing metadata from ebuild directories, it's reasonable to assume that one would want to keep tabs on metadata.xml or any other topic dealing with the problem space. A simple, "My project depends on metadata.xml and I use it in X way; will I be affected?" may have added to the discussion. As it stands, I believe we're moving to maintainer types. So selecting via `type="project"` should be able to fetch the project that an ebuild belongs to. We (i.e. Gentoo) are in the middle of deciding whether to keep going with DTD or switch to another method (from what I gather, to support this very case), so since you actually depend on these files, why not educate yourself on the conversation and see if you can contribute? It does nobody any good to sit and sulk while the world changes around you. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWwUTMAAoJEAEkDpRQOeFwIFsP/1AZH4QcJp0hW7gv4CmO55wd yzuuwW4iDzswX8cUfmkJdkar/OVapUo0I0xuh/7dniUF9Yoj9vuN1m7f4z9VTQeh YrzbxKe/YVt8wO+2e2YxohIsybQTycG/0yKdcJN9NjNreo04fA80WUu9NYXEavk5 frfGqVaThhPXjIqQRJAq9V0UraqjU/SNy9xQAHMUtjnW5q4svPs3QTRP93+hqYg6 7Kzr8ssRGhq1N8A9lnZrkXfVkBmHOQ/Pol1d/ci+xRryYerVDlM7pGFW2mEdbtp2 jobryJMUjoUtdp8bxWgt+55X9fu4STPtyvq27n/ac4dXl2hs039iDLIdgyioR+id X7pa6qmqeDVVT4vKNaFXa6PLF6K/OgNyp5l8M8Yctv9TJ0ppOX4WJ9bosivyAtBX 93w5Gu7G8arkZaJfpZDwf551Zn7qNaeR+ipArfy+kzn81zWogrrvBFPJ4JYP9qdL iFEPVSH14seh7mRZOKhMzzMvfLAarQF5paZmwqCceCzEzIauMlGVT0xDEjansAUK qewS2pWJ8yELL2kohq8yuP/3/qplgW2gVUK58b5+PpdOB/i5fdNVX5FwaNg3TBt/ 4LALTeNdtgFDXL/5y8YdJu+yn6QlBEgxP2uo8me8CPFexsZRe8XRHO15WNnAhFIL 48rujyhN02LbnsD+0LV1 =onzY -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/15/2016 01:29 AM, Alexis Ballier wrote: > On Sun, 14 Feb 2016 19:34:52 -0600 William Hubbs > wrote: > >> On Sun, Feb 14, 2016 at 03:50:38PM -0500, Mike Frysinger wrote: >>> On 14 Feb 2016 15:47, Anthony G. Basile wrote: >>>> On 2/14/16 3:34 PM, Mike Frysinger wrote: >>>>> the bring up of the daemon itself is not nearly as >>>>> important as the runtime interaction of people using >>>>> libudev or rules being executed. >>>> >>>> correct and i've been careful with libudev. >>>> >>>> anyhow, can we divert this away from udev/eudev. mike what >>>> do you recommend as the future of openrc once systemd-udev >>>> can no longer be extracted. >>> >>> if/when systemd-udev can't be extract anymore, then sys-fs/udev >>> is dead, and this whole thread is fairly moot. -mike >> >> +1. >> >> And, as for right now, udev-229 is in the tree, so udev can still >> be extracted and run standalone from systemd. > > and even with that, I don't think there is anything preventing > using systemd-udev from an openrc boot, is it ? (ie, have systemd > installed but booting with openrc) > systemd blocks both udev and eudev, since it includes systemd-udev. I don't know enough to tell you if the udev that ships with systemd is separated enough to act as a daemon with OpenRC, but package-wise it's a blocker. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWwaIEAAoJEAEkDpRQOeFwDskP/0nwCQh71phL6Nc6F3EkTnzU JLIP3QOpqKXdtDYXJ/jG9+w746CKC3K/lR7IHuqvrWMVETXblwERbF9XGwUWMvmO nzFZ/K9pbNSQ+CiCqBGbs0HrXcXXjeosCf/sgl3FX3JIBgFordCS4t/WQMtmUbwF i2unx4BzAp+H0lJ8CuhmQj4cqTu3jaZkM+eRoXxniBM1ELZ3TZIYWu4T4OdjrCyb f77CNdm9sQTHFFhkYHf4unIdfwcfcin+x6vWYLmuQrBbuoqh9On4qAuQLjoZjjDk JlhUhHgVX5OzGCd8vW6aD7FJNmMLLONKmhpv8aZZrhUda3QPzMuzjZFtYFwxrn1N 81YOROGyWL5TK/cVzpUjU7qmYIkGv/NXMrv42zOxmUINQnX7h0ny2SWnJ1jboJZb isq2INnolrTTEV158eI1ij4usrxdLiDjKwCRoAVZP6eHWlKb/g2bFX5TjKrwiLfI exS8r+aWLVj2ytEZIm6Uf0UNdGjTC5MQSHCxz5d0zx0/KHsz6COIiPZHdcvXfPME dXuYVsmkdE/+4nFSvUPZ7w+eV0jFZB2C1X+at3l4I6a4itLxK/Sp/ydDXmAvlItQ zTdQORHbu3BW+dvbuTwafZVCVsiZQKUtWZexGGkgeyKjxm3svGyT4UVPE5euk5M4 yUH3T+1z6Z3LYGM/We4M =EuL7 -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/16/2016 10:05 AM, William Hubbs wrote: > All, > > I have a bug that points out a significant issue with > /etc/init.d/mount-ro in OpenRC. > > Apparently, there are issues that cause it to not work properly for > file systems which happen to be pre-mounted from an initramfs [1]. > > This service only exists in the Linux world; there is no equivalent > in OpenRC for any other operating systems we support. > > The reason it exists is very vague to me; I think it has something > to do with claims of data loss in the past. > > I'm asking for more specific information, and if there is none, due > to the bug I lincluded in this message, I am considering removing > this service in 0.21 since I can't find an equivalent anywhere > else. > > Thanks, > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=573760 > I have a LUKS-encrypted / with LVM volumes within it, and they (apparently?) need to be remounted read-only upon shutdown. I've not found an easy way to take a picture of the process so I can indicate *why*, but I've seen it scroll by. I use an initramfs to decrypt the LUKS partition and discover the LVM volumes. I can only assume it goes read-only before shutdown/reboot because it needs to. Just my two cents. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWw4CkAAoJEAEkDpRQOeFwrUoP+wR1Poxssa29MNQOGo0INPKW 7lKTDIDYuLFHqsKbgwBClaDQSNMEDyeZxmcpw7WXYxykftJ7IXlOYP55WDK/65kQ QvcF+p7WhsG41kmcmKWrZpaL6Qo8wI58Bo/y3i62/lsecQiuuX8bPlTwTCLBvBxW iDlMPPMRkHoTheTZK6BPJ4F7jkHKD6LjWKSH1cTigKOtX1Sl+ZYWw6RPgAvS3TPW 9rP6v6QBxYaeM9qiEr4OPyKwiDtm0QOfLswWSxwCmRvZriED8to1n2/CQsSee29L C04j9nfj5Ez+O8q0hDaiuTZxVZ5AJm3obGQtKpcTDdtHxAQvKvG71AY6wuOfSDh1 kWHfUSSCGv8dB+bglb1beFGyUdZYNt3baVYhmiRqtAUGCXCSOm1Vpj8XCPOGcyPc FOZaj6iqBfSwZGn5Ah3PwTMiwH+qgPOsYzuhb1okts99DVtNQZ28IGHvOzhYpqvZ D/loe++/Y05HTmY9S+BhaePe0yU1BKjfO4BtMSsBHcm9cOPjni6KZRa6mGRN4fZS X7XThXuv9WoD14FLvTMf2DbLJuNivvoyHBZ5qVuSfSachDII6LxaM4Mdvm3bbT67 Bt3jPua39eRBYm0EBNKrM7wOpE2NfLtjZ7bwoaX67EvvG1TuiYYLkXHrB9arFm09 rKNCGZvRDqwDx/PgJkFd =wWjL -END PGP SIGNATURE-
Re: [gentoo-dev] games.eclass policy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/08/2016 01:49 PM, Michał Górny wrote:
> On Sun, 7 Feb 2016 04:13:38 -0800 Daniel Campbell
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 02/07/2016 03:09 AM, Michał Górny wrote:
>>> On Sun, 7 Feb 2016 11:38:27 +0100 "M.B."
>>> wrote:
>>>
>>>> Hello folks.
>>>>
>>>> While hacking away on a new ebuild I came across the issue
>>>> that games.eclass apparently got banned from future use. The
>>>> only references I was able to dig up (apart from helpful
>>>> people on IRC), were
>>>> https://bugs.gentoo.org/show_bug.cgi?id=566498 (games.eclass:
>>>> use of games group needs to be removed wrt 20151011 Council
>>>> meeting) and
>>>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summ
ar
>>>>
>> ies#Games_team_policies_issue
>>>>
>>>>
>> (A mere deprecation notice).
>>>>
>>>> In contrast, a simple "grep deprec /usr/portage/eclass/"
>>>> gives numerous deprecation warnings; just games.eclass is not
>>>> among them.
>>>>
>>>> Please provide some guidance how (community-)developers are
>>>> supposed to handle games (in particular wrt games.eclass) in
>>>> the future. This also includes usage of
>>>> /usr/games/{bin/lib/share} etc.
>>>
>>> For reference, this is the reference decision:
>>>
>>> https://projects.gentoo.org/council/meeting-logs/20151213-summary.tx
t
>>>
>>>
>>>
I'm going to open a bug asking games team how they're going to
>>> proceed.
>>>
>> Please let us know when you do; there are a few Humble Bundle
>> games I'd like to bring to the tree and I, too, don't have much
>> to go on as far as guidelines beyond our usual.
>
> I'm sorry for replying this late. The relevant bugs are:
>
> https://bugs.gentoo.org/show_bug.cgi?id=566498 for games group
> https://bugs.gentoo.org/show_bug.cgi?id=574080 for paths
> https://bugs.gentoo.org/show_bug.cgi?id=574082 as tracker for both
>
Thanks for the links. I understand games have been the subject of a
lot of 'discussion' on the ML over the past few years. What do you
believe to be some of the main blockers to getting more dev
participation? From what I gather, a decent portion of us play games
on our systems, so it seems reasonable to get more maintainership
spread out. There's a lot of user interest too, as Ian pointed out.
- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJWw9ZJAAoJEAEkDpRQOeFwoDcP/2rHwIb1ztpkBOzt0UWh4IYr
fbKHCi+NJ9p5j7alLQyjIarZgYMY5yLvRWaP+pR9PPyjIhAmEGEI1SoGLQC8MhJ2
fqOUKr+EH2mt8I4U3EGzsLAMA4JXm1yaKmDcFV3RQett4uUD9MWECQUxrLBQ/cME
F0kPaBziIAZM30+jBoplTISNW7n4L4a/S6smcUV0XR7vGL3P67UQiD1zQ2LvF2Ny
Yj4NMk3Z79rYzog0mqNKaSPVR45rEpTPz+BSoxqwt2t117GQP01n3WlKdyOecKuH
KRyJ90pOnmJVRmH3pLYubJwq0mjvv4YYD1HVVWzK5r30kmVbd5rWrwt/RVGnpkGk
EI8CdKuiQwXeWjb+X1Jo0kEhs2e5dKRmPM4z2xHv7YCkkshO/aOC51iP75yLnnZS
8pxp/D61Xdbfbjm8l+0oHJdIJ9qm6Oc5UGohcWU4pk/mTHNutWjKaOAT3D+Rtu7/
ILCajj5QapXgJUqEZ8YleWD0e/7Ft2AvWaNNgalz4717daIHhk/JBE0WDDv1M3Pe
+KT4pC9zToAZelwOnQGLZLyccbyLpgqrwsYArgsqBV3uTwgYRCTqEbBDZAx2m994
0RyxIgF201hsGKp6yIS9X2nQEgZwFrM3XWDckydiQhpFi6ZMxbWsdKZJxVOUVOEf
JAF0lamHDp2Em+rjKLU7
=/tsU
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: supervise-daemon -- a lightweight openrc daemon supervisor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/16/2016 07:49 PM, Duncan wrote: > James Le Cuirot posted on Tue, 16 Feb 2016 22:19:44 + as > excerpted: > >> Oh, that's cool! Now I come to think of it, I believe it was this >> effort that made me aware of s6 in the first place but I'd >> forgotten about it since. Now I feel dumb. > > Umm... I think there was supposed to be a break, here... > >> As you were then. You're doing great work and we're clearly >> spoilt for choice. :) > > ... because as it was written, it appeared to be... > > "Now I feel dumb. As you were [dumb] then." > > Which is how I originally read it, but it'd didn't seem to make any > sense at all given the context, so I had to go back and figure out > where my parsing went wrong, and decided it was a missing break. > > Just in case anyone else reads that wrong, as I did initially. > Unfortunately, I write things that end up reading totally not the > way I intended too, from time to time. I /hate/ it when that > happens! =:^( > > ... Unless of course a sneaky insult was actually intended! ;^) > IMO you're over-thinking it. I read it as "As you were, then", which is a common saying in the (American, at least) military advising one to keep doing what they're doing, or return to a resting position. :) - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWxBOUAAoJEAEkDpRQOeFwNDAP/3GTnfW0NJBBICGu1Pvs+VjY InWnxC+qvfkZQ7B1VXCdoUs/9WxdoCC7h+jFxkinVPkYDRntDq0DB2VxoEfiFLwl EAOCiSEu7IH3QLW95sWuWRkOQkuIiiE5nHjHj/DYNlTxpG/BceKPrgGRNRoNczhV tG+UGC/BfzILMdqv58H06eQzAC7ym1zyRvwoMOMfTucOa52zYvTXIhg8/P5fJn2Z o5VqM60N2Ri+06q3ttc9cC3v6KdWzYUdXPU9tZLr/vQrKwZMeIARG2zRoM9CCy61 BtaL06cALkZy9ROifj7VvdkFSAcMkGb+SgqyLVsJ9ejOxUf4xzA75QjBF4j6x4TP A0vIHxDHgJJLDzYJcbkJu/IJ4S1VPv1Rga9fw3Ji9FIKv5SPIxpNkM9WvOr6zsCu VelKC5hDFPQ1tTKOLT7k+Q72pPoFEJv3xABsokWUdgQp81zk7b1Bhgv0YsZ6e1Py Q0lNS6eOmt0Z4HccSRU3hm00qcJmwZ96kx+q+ix/lfBawpgqj2xGcn96nOdfsqUu tQNo5i3GJt0InSGWXRr2gTjeY9j4A+PSDpfqtbtaaDos8WyqduHmh/YWKZ6tUFVW 1qvD5qDwC7NokQNBVHYE8cQnKAkB5VlE9un+6xYKE0B3p8Zo5RPjdEgGit5QKqqn h8tP7v5KUpKICIPnZ95/ =O3dl -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/17/2016 09:30 AM, James Le Cuirot wrote: > On Wed, 17 Feb 2016 12:19:52 -0500 Rich Freeman > wrote: > >> Is dracut still not widely used? I know that it was all the >> fashion for a decade or two for every distro to build their own >> initramfs, but I don't get why anybody wouldn't just make the >> switch - it is far more capable and configurable. > > Does anyone know what most Gentoo users are doing these days? I > don't recall the handbook mentioning initramfs at all back in 2002 > because it wasn't really needed back then. I did without for years > until I finally put / on LVM. I used lvm2create_initrd for a while > but that was still quite a manual process and I couldn't imagine > going back to it now. I've switched to Dracut and it's great but I > don't get the impression that Gentoo really endorses that option > over the more laborious ones. Maybe it should? > > https://wiki.gentoo.org/wiki/Initramfs > I went without an initrd until I encrypted my / and put LVM inside it. I used genkernel's initrd functions for that with a manually-configured kernel. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWxOssAAoJEAEkDpRQOeFwtDUQANLipE7ZGNjf8lrstbl6/6GJ bEwrQX+xFST5c7U9OJgU1HrGmL7vrYLurg82Sqf2zqzlsXdSPAxQtvAPETvPW8Gy lbWdV1UaaCda5W53lX2XrKVf9xQgT8wANlgWQmFlsOnbCUbaLYYdQQWN/yuW+NQL xV2V57EUOLCmQ4LNNG/zuoo7JrrfVikNavlk70Emq0DNpt+dPhHK9hc6N6zAeUc2 6oEFDB6ILf63ZE0v1dLOc+HxnIeAZ06GwLnx+1ta6o2hfoqPDBqym2V6lplRk1KF xQeWllMNcl5ez3d+T8BP6sm0gkv0WPpVAMBm58IdxhX0ITqIVDo/A8zR+tp7x5U+ Ih5+2vjhoFmpr+8NVo2HHDHCddokzcqgd6ZL4ZA5RYYLF4JC755QntTGTKuGdU1e nVYySqTnmzxXIzEaplixesgKiG70KBDfStmLGjIbxl+E8fyZkx6fNg1dP7/QMZUY GF/HiO5dpEynDvsO1VgJY6cbFbHW0Ee1AWhZmvpT5eOZTUtCiipaHwGrS6Tds3N2 R4odNpPBvnV9G6EvGrQ6rtAcdH+j2XsVcFsaJZT+YOcvIZBT6UEg3YcucTNJELRE OSJzROeVau4p82o5YJTqwPAqvu9TI39kJ13ps8pTqJuNrj+A33ag3jiPh8Azpfbo APYj1uIIrl6OcOinlHt8 =0SBA -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/17/2016 04:43 AM, Michał Górny wrote: > > [snip] > > If Lennart's single statement from 2014 is a reason to use eudev > instead of systemd-udevd, my statement from today is a more > important reason not to use eudev. > That's kind of a false equivalence. Unlike Lennart, you are not the primary developer or maintainer of what your (sarcastic) claim indicates. Lennart's "single statement" has been backed up with every large change made to systemd or udev. With each change, it becomes more strongly coupled and that much harder to separate. Regardless of my or others' feelings on Lennart, he *has* acted on things he's said in that regard, and it's foolish to assume udev without systemd will remain an option. If Anthony had said that instead, I and many others would have reason for concern and likely respond by migrating, again, to something else. While you and I are part of Gentoo and thus somewhat 'upstream' to eudev users, we aren't active on the project (to my knowledge; from what I gather you're a systemd user and have no interest in eudev; I have interest but no relevant experience/skill). I hope I was able to explain the difference. Rich made a good point that maybe we shouldn't act until udev simply stops working. I'd prefer a more proactive approach, but I see the merit in waiting. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWxQ4cAAoJEAEkDpRQOeFwGwIP/Rdw0Y6E+94bZNMCw+CfIveX bb32aqkIDiXIsJjYAdYnglwhWff4DpUy8hW6VJchV6O1avU3m7FL3FZ1y3Z0GQOy lkMprvahBqTwpcjCObtyWjAizJsdRyB4YcU1rUli4x30WG9exmQI2xTY2c2hz1fW BKfjq7HGn/gPT8FPlHEhRVwB52HQDC0u5dHM7PKr1mrwBTMwc+1we16i0G+zNT4e E/HcPjo7z6MbGHQNJ596GEm9PUXM/WDK85xYAeH1T3ILT1df+bBaq11v8c37Su5f QkUqFsmCQuPNKbY99IwHEreiq0UeqwBoJmjIsVcn+sIs9ZhjXy71+3drUVC7iE5u 4lgPyaDLBWNP3+4stj4bsqwGGU7i2mei21Sk3kK19PcOyaCPsj2Oo/ohr6+yTN6C yESh0vkQMZf5+5PSABDiczRIRtD8U0e5HrfBDs1gLxXblUTPk9PnOhlwDUipdN0y pBcQ++BrOcQjDosnyQP4jRJjqodKuPZow+oqgW+SaQ5RVAlTz8K16Dm17KNfIc6k Dm8dbmtaCNO6cZZUPuTHT8jSihlB2gclFR1ALZvfDjb3ghYmwy8uGxiec4x5abvj 0gVlXCP41jblNSXM+Q9EWCj+ICTVc0DbGPshPZ96p7XtetttKk6gdf+PcQ1UDzaa UJFt2emel44zfnlQKY+f =D8/l -END PGP SIGNATURE-
Re: [gentoo-dev] bidi / fribidi useflag harmonization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/22/2016 02:09 AM, Patrick Lauer wrote: > We have two useflags expressing the same thing: bidi and fribidi. > > I suggest collapsing it into one useflag, and to make it a global > useflag. > > Affected packages: > > dev-libs/efl/metadata.xml: Enable > bidirectional text support > games-action/supertuxkart/metadata.xml: name="fribidi">Support for right-to-left languages > games-strategy/megaglest/metadata.xml: name="fribidi">Enable FriBIDi support > games-strategy/wesnoth/metadata.xml: name="fribidi">Support for right-to-left languages > media-libs/avidemux-plugins/metadata.xml: name="fribidi">Enable unicode bidirectional algorithm support via > dev-libs/fribidi. > media-video/ffmpeg/metadata.xml: name="fribidi">Enables fribidi support in the drawtext > filter. media-video/vdr/metadata.xml:name="bidi">fribidi support, for languages, written from right to > left x11-wm/fluxbox/metadata.xml: name="bidi"> > > Is there more than one implementation of bidirectional text? If not, I'm maintainer of x11-wm/fluxbox and would be willing to switch the flag with the next release (or perhaps a revbump?) Any suggestions? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWzQGJAAoJEAEkDpRQOeFwAU4QAKgk8ncqoTN7H0e+e+IynGSi mM8nIPoxDOdqTvXnuZWA/T6JqVyfzqLfZDD0zp6X5sktAsD/5yzNjaaUF1EcSdFs u5J9SUY8E24hmm9ZXbmFhaYlRR8Xhh19G1nMS44zKUrHpcHraTGV4lZavAG8bHpi jKHPIV5eaG2x2qdNkMRpWoqls0AONBXC+iOKKtevBPhIH+0a4HD6f4m4RMt2lxGZ xzQ/5fAWtboTkmQa6QJptHCTdiUMalJL3AvGJ6oNeXlzBlEUP+ExPZNZNn3oJZ1d XYUcvdBpQcQHClN1nA0SN5XyTje/cCpnXMY93528bh29oYXapLPbRXhvuRYvgkF0 e0RPveOLngM2DPZqBRC0BNIWIt0DgbQDi7shnD0aGefHkuKOn8ssM8eTZHOG1Yxa 2NTMqRVUt+MT09lPwC7HJwKqV2qkmVT3exXP4BYkGVMOtMhsfX71WG9ocE0QxdzS vJEXoO/s1bVbD09noRO+rsjWKbIMdGfL/VpMcRG/stkU6kKK5EnpSM/g0iKmz+0j fM3eTwwKboGnegLf+YfU+JzrSswcSnrEa5ohuJ8yRJ9EMABfXZWJCHvM5NkLm/er lbBog8P03kdnoNXt6so11zrHe+YsSQlfS56UfAF3VOgnshY6RES81gpVTH/yUaFz zzzgMrxnvHoPOGmOLbOM =LqG2 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/24/2016 12:16 PM, Luis Ressel wrote: > On Wed, 24 Feb 2016 11:18:55 -0800 Raymond Jennings > wrote: > >> As far as changelog generation, what about causing the changelogs >> to be autogenerated by the end user's computer? Divide and >> conquer. > > That would require a local git clone. And that's exactly what those > who still want Changelogs are trying to avoid. > What are some arguments/reasonings for that? Whether it's a dependency on rsync or a dependency on git, a new Gentoo machine will need one of them in order to sync. I can understand mirrors may not want to run git cloning on their infra, that's a fair point as it requires additional setup (afaict). And syncing is technically a separate concern than version control, but if the entire point is to retain a changelog, and we're generating changelogs from git commits, then it seems to me that version control is the correct tool for the job. I'm not advocating for rsync to be done away with, as it has its benefits, but changelogs are logically related to version control. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWzh2HAAoJEAEkDpRQOeFwL0QP/jf6pL3ZzKwtYYZBVIhe74eE 09R9zeTdnzSi5yyVUi2nVXDogBe6+bafwLDA/dzS9iskhzrznzKAnaUroOtnx6rN 8QVe3ojy9DxhvmnQSPUGEEjMe70kIyGM3Z+enOg59k6VGl97x+f53xvQkj3oZAId W6aGYCi7m0ApsqdLrYoNhcE6toNHrpd/YhzS7bJTnhaNezx523EWzYsk5ej/Vyyt GpjEJMEpiiU3KkjoiVS+sb3SYJ+VneIq7n3mszmw+O/pFbGX76lxoywCVx+P1Z8K 1aGoG9ZcYPij4jQWXdIdB8Rhw+DQF6FIYW3A1aw3hmnQsQFM31tt6V6wJKzWEjO8 xDZ69iIYqQevUHSUanXm/p5BGumF6HOq+DS0A0+gpFz/+FlxULj97eKMotaO0R1v BPIbGXGNASXz62kYG8SJmA6KU8mc622JnZ9dY1XMLzY6vcTM89vbkudZXBq2Wyyc CnbEuC9+1eBrOXOIWTPZ0+8XVaScz9kiBvgeQXYOd8VbgKS+GuFGOjyh1JWZdPyY LAyarpAVmhUpRwBWw3oXeKUm50h2WXiBQWJnELYBWO9sNG7Z4g1u3QAY5zzYuYJr VdphdxUzRtsMLI86oP/Lr7Hw5v3wMhebwsPeuvHtebU63A4noGpWyeokuZ9tfrjS ecd156K/a1QezkWwAY0D =Bw// -END PGP SIGNATURE-
Re: [gentoo-dev] CVS headers in ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/03/2016 02:57 PM, William Hubbs wrote: > On Mon, Apr 04, 2016 at 09:03:59AM +1200, Kent Fredric wrote: >> On 4 April 2016 at 08:57, Ulrich Mueller wrote: >>> Does anyone still use the CVS $Id$ keywords that are in all >>> ebuilds' headers, or are they being expanded anywhere? Or is >>> there any other reason why they should be kept? >> >> >> Last time this came up, a sole example case was mentioned, but >> it might have been buried. >> >> https://bugs.gentoo.org/show_bug.cgi?id=557386 > > Tracking this type of value to "track upstream" doesn't seem to > make much sense, and I think if infra was going to be able to fix > it, it would have happened by now. > > My vote is to nuke it and be done with it. > > William > +1 - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXAZaPAAoJEAEkDpRQOeFwnP0P/Al+A36ls1DMQjEPu5U11vYn L9aQPtckfeztfBYq4EB94Xazrno+yZI9kPg+vhUXA577H7h+OxM06wGd+DH4Q8ZJ tChD+HrJleKZVV4lcT0e11FRKjzMm4ImKXXcEXFoy8asV76nT+U/Qd2cc+I10EnF rgapKsIPpzUjOmmESmEX2ZxMcT5sDbUY2/4qE6veaS9HJbkjyoUChfv13SwiFydf 5jB2LQmru+A8Eq9u1ju21dQGTmkhLQCGcSBTmPvscpzrDmmqofpCeWo2rrn8Jz+l 4uWOcsBmnWOnJ6GzlZ+oY7iQ/2p+5Suzom61egKe2moNQyP2Fxgj58KhRZPRYvZ3 GJrkN/CGJOpc+usQVNk0ggSaewR8PRVBITT7LeRxyz/PukNaH6leP75+TtiBSnIJ 6UDKsRh/aMaZixKq8hcLUlhITaVQOI/zbYZmXGWcbxFQ8348kFGCdXXDFJf8g3CA Bq1Z50fBaCDDEQ/3dVV479nuT3su/XCoI2VL3E5BwWVhra5nFh56jf3uSZ9ihGgd IQFNWRIZ7ZEep2rciSl8ohFvEFgyP9lc6uod6Iukef3QPDPWK0YIVSyBgQGKzju/ qZqnHXUYv6vBvJxKtIVWNFWUzEnPLH6WrW+ec4m+bhCekHnJOpLxMLhCn0TySVtD OQNW+DngQ8gI3q8pYngk =GkAE -END PGP SIGNATURE-
Re: [gentoo-dev] GitHub GPG Signature Verification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/06/2016 10:52 AM, NP-Hardass wrote: > Greetings all, > > As of yesterday, GitHub now supports GPG signature verification > [1]. As a result, when viewed through the GitHub mirror, all > commits now have a widget that displays whether the GPG signature > has been verified (via GitHub). To help facilitate this, it is > highly recommend that all developers who use GitHub update their > accounts to include their GPG public key [2] so that their commits > can register as verified, where applicable. > > Just a disclaimer, I'm not endorsing the use of GitHub, nor > advocating for it, simply indicating a new feature which it would > be nice to see Gentoo developers on GitHub taking advantage of. > > I noticed this as well and put my GPG key up yesterday. So my commits should show up correctly. I'll have to check the mirror to see if things are working on their end. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXBXe+AAoJEAEkDpRQOeFw7uoP/i3r47g8P1TQWmN9VBCLs0RT CO/z4XA+TN71+iKwvtEVZBkrarLAHFJ0vZ2jvcjymCra9BAUNTYoDJIMeRnL0mIu v0G3mpKU3/PZb4pOYYZYKSS48oN9cyqaEO2ufcCKRwX2+5SBCy5vV2c46UBljh9S pFqKAu1erd8QF7a4W8c0mYHGkoxmRiTfyE4ZlH1D1Uagy9B5NjTvLBAsJR93vI4D KtDp8E/f9aVILL6o/nwYT72kflNUhcqNG7iM9X0kn/cdGBv0EQoCWR+DQOrKnkYP nlb+k9nxXbXhq4Nt99bgnX0vXWoDQPHkPrsQG+XgtiCOY/x4iDp6Xw8tPZL2BHB3 4Vltz3SgB6hN2lUTXRsdfks95b10f1Zb2Klkm9E6Qm/7dk/BYzbyVJ7qXyF28YZ9 CONO6FYXyOeCuuXhFJwm5PIwXKBRjgavPROLVR2sSO8E49k+r4n7FPCqBKV5wCI6 EWAam/X/GrGsVBA+jBjjAzUh347N2h0J8Bx4nbR5c4VA0PUwC6czRsjJEP1CZ6KK Pn20qPWH0qFQcBsfl6IvUwxZmj7Bbsg7GIxZCnyrl+Gzrpfvhbsv72ujhJdRV4g8 nIZURVguhRiPDlnuLmeI52LQ4v8nZa9lw9XK74rLZGGcfC3m5Fisduxw4I+/f/lH 3Eiw+ZldhgX3WPRGBgNi =QkGH -END PGP SIGNATURE-
Re: [gentoo-dev] usr merge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/08/2016 04:31 AM, Anthony G. Basile wrote:
> On 4/8/16 6:14 AM, Rich Freeman wrote:
>> On Thu, Apr 7, 2016 at 9:42 PM, William Hubbs
>> wrote:
>>>
>>> There was a bypo here. "the ebuild" should be upstream. The
>>> default installation location of all coreutils binaries is
>>> /usr/bin, then we move everything around in the ebuild. We are
>>> deviating from upstream in this example.
>>>
>>
>> Keep in mind that following upstream and the /usr merge are
>> somewhat orthogonal. You can just install those binaries in /usr
>> without merging everything over.
>>
>> The only issue is that without the merge anybody embedding a path
>> to these binaries would have to fix their packages. Presumably
>> to aid the transition a symlink (at the file level) would be
>> needed for some period of time.
>>
>
>
> @anyone, can you list the reasons we're doing this (I'm sure
> there's more than one). If systemd if one of them, then I'm
> confused because debian has switched to systemd and yet has not
> merged usr.
>
Based on what I've read here in the thread, merging /bin and /sbin
into /usr/{sbin,bin} is a matter of convenience by putting most of the
static parts of a running system into a single path. As mentioned by
some people, however, that's not enough to make deployment across
multiple machines super simple. The distros that focus on that aren't
rolling release like we are, and thus don't face the same difficulties
that we do. In addition, Gentoo supports a broad number of choices for
users and some are advocating for an option.
At a higher level, I'm not really sure why we're discussing it.
Perhaps I missed it, but I didn't see an actual problem that someone
was having mentioned anywhere. The /usr merge seems to me as a partial
"solution" for a different type of environment; one that, arguably, is
better suited for a distro that's designed for such deployments.
I personally think sharing /usr over a network and deploying it to
multiple machines could be a recipe for disaster. It seems like a
business case scenario that would involve multiple other system
changes. It sounds like a great case for adding another profile or
something rather than changing things tree-wide. Maybe it's a case for
making profiles more powerful and flexible. Regardless, I'd hate to
see choice diminished here for the sake of a single set of rather
narrow use-cases.
Just my 2¢.
- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJXCC6jAAoJEAEkDpRQOeFwD+kP/j1EYtnbgh/s4i4lTn14vuoY
Fj57eCsCBLNbHlEEGesLEU3EEExtJgVeSC9emuI80/nynOM8dhqUUKjtoZwwBW5R
9P5QmMQdT+ScJHPQ6CL5IKh9UeAF4IgDbrJI9rdHnrRLtlE40xWDRp8NcB5fPAc2
EfLMFRZs3HpJpVMirIVIMTHEckDlMRmYzO9aqKCnmSCx3M/nKR/SWSSQ94Acet9C
DPN6nLH42vosJv1+syNUHGqf4DLn6xTREx7DEP8fBUJuQi/wDpHbbRn8PON3WkCo
FkDqjxd3AhahUpa2LaD4t/sRmvs+tjIXfgFJ8iYzJwjRQKKZvSHRlQzUwQNnI6mS
fkunumIhcJdeWCBXegaSxouAtaua7pk+AXDLx+2ZjhxDmv/BbmC6RSPWkHo3wsMl
TVbZSB4IrDrp8l3kYd+baBEtZicNgoma4jak1MFn1COFWR2/ZqtGaOVDErW92aX2
jVQkTGTUGrFNx24ZPcvPB0OVNleoOfhh97O3EFjeOl0TnbAziGX9Z75HPegLFlLR
5dXewskG6iACR2FATlhhOgscfIVwE2LxEWw/N6lm0NbZHKTOObzP39fdu0CisAck
pXtd1WBYX349Z0ympl9PCdLd68SobBROsFHKE6rwkSLkCBadzOCxgjpEGIQOPKHu
qpXF8Z8y/Hssr4SAsxb0
=4UKO
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New eclass: mate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/10/2016 10:09 PM, NP-Hardass wrote: > Greetings all, > > As all potential new eclasses are supposed to be discussed here, I > thought I'd file a message and see if anyone had anything to > contribute on the matter. > > I'm in the midst of a major version bump for the entirety of the > MATE desktop environment, consisting of 40-50 packages. There is a > huge amount of repetition in my ebuilds, and a lot of things are > formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare, > etc). As such, I think that moving all of that to an eclass would > greatly simplify my life and my ebuilds, so I thought I'd look into > creating an eclass. > > Any opinions either way? Thanks in advance. > > > Sounds like a prime use case for an eclass. If I were in your position I'd be sure to get reviews from more experienced eclass writers along the way to make sure you're not setting yourself up for bad API design. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXC07lAAoJEAEkDpRQOeFwqA4P/0GRudtO39UawnAQRW+N3/Un JyyFN5Oej9bIJpMYyE7tz77N1SdUjla6yW/2WaL/HtzTeeETjp/ThlOXvweYE367 mCz7OJ/q9Fo20TGfPaBI0xIvlcmv+BDdTpjJc1czRlC+1j+mLa9RDG+byMiwnQIa QVK3sUYAvypQqGIOZSlM4nCRwVT1CSBnSDlaJqlUIUJNciY9iqXyKwzCX0xUJCpo pQHH2S05Bhx8c0rpK0x/MkqfhTAaLBPQDd/7Szozuy/MTb3Zx3aIV4bE0Z5D5uYq B5ReTw0D0/cZqi9dA5HeEqMwEJJm6DRvs/km9bX07LDsIm0otvMCho3LzUY76SyS 4wtbNrHVBdQmM1XF9RdJ8Nd6HA3oozBwgs7tNRj0mLNG0irpc4q3CdC0ZYjklYVZ KzTS2f7j1nnBvMynVYehlhNLUzpKwnUNIo1SFLrc5W/3ZQb9RtuwUYerP6sSoL8E och22zjtD8PesT5exTXf5M3DRB5xO6kDcdCdzASdEpdjcLrCt3aDZTejhFrIAiJq 0LpdiZMyeC/z8bLKVGpMuBcZkD+eI9YzzdGC4FDU8AnEV17lGZfptqbUcGYL82wC 9FdlXieeTUuFWwIq0uM1gm4Sr1RMZ0/+Y/dqQBAKM+gFbZ8V+th5c8nKbdDt+I4o 4WOoBEg3fMnwPxga7DGT =ks2J -END PGP SIGNATURE-
Re: [gentoo-dev] Reminder: ALLARCHES
On 04/30/2016 02:16 PM, Andreas K. Huettel wrote: > > Hi all, > > just as a small reminder, to ease the load on all arch teams: > > If a stablerequest has the keyword ALLARCHES set, then > * the first arch that tests successfully and stabilizes > * can and *should* immediately stabilize for all requested arches! > > Whether this keyword is set on a bug is decision of the package maintainer. > > For example, Perl team sets ALLARCHES normall for all pure-perl packages > (i.e., no compilation / gcc involved). > > Here's an example how this was used: > https://bugs.gentoo.org/show_bug.cgi?id=578408 > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee3709cb5a784b213511fa > > Cheers, Andreas > > A package working on one arch won't necessarily guarantee that it works correctly on all other arches. Shouldn't we at least make sure we're testing on the relevant arch? For example, I don't have any hppa hardware. If I stabilized for amd64, why should I stabilize for hppa? I can't in good faith claim that it'll work fine for hppa because I've not tested it. As you said, however, it's a choice of the maintainer. Things like Perl and Python may be less prone to this issue since they're meant to be portable. My apologies if my concern is misplaced. ~zlg -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reminder: ALLARCHES
On 04/30/2016 07:26 PM, Rich Freeman wrote: > On Sat, Apr 30, 2016 at 8:53 PM, Daniel Campbell wrote: >> >> As you said, however, it's a choice of the maintainer. Things like Perl >> and Python may be less prone to this issue since they're meant to be >> portable. >> > > The concept is that the maintainer will only use this when this is the > case. The goal is to cut down on stabilization burden esp for minor > arches on stuff that should be arch independent. I don't think we > formalized a ton of rules - maintainers should know when it is safe to > use. > Okay, sounds great then. Sorry if I misunderstood. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reminder: ALLARCHES
On 05/01/2016 07:03 AM, Andreas K. Huettel wrote: > Am Sonntag, 1. Mai 2016, 15:32:27 schrieb Jeroen Roovers: >> On Sat, 30 Apr 2016 23:16:42 +0200 > > (For the record, hppa is definitely NOT the problem.) > Forgive me, I just pulled hppa out of the air as an example of a secondary, different arch. afaict nobody's really picking on a specific arch. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dev retirement - Farewell message
On 05/01/2016 07:57 AM, José Fournier wrote: > Hi everybody, > > I have been a bit far from Gentoo for a rather long time now. I joined > Gentoo in 2013 and I used to be a translator for the French language. At > this time, I had to become a developer in order to be able to submit my > work in the previous documentation system – but in reality I am not a > developer at all. Nowadays, with the new wiki – which I can see grow > and improve day after day – it is no longer necessary for people like me > become a developer. > > At the beginning I could get a friendly and patient help from Sven > Vermeulen who introduced me and was my mentor for a while. I am very > grateful to him because it is not something obvious for someone who is > not a computer scientist to enter a world like the Gentoo Community and > Sven contributed a lot to make me feel at home. > > Recently, I decided to join the Fedora community to help as a translator > again. It a very different distribution and community but my previous > experience at Gentoo is very valuable. Arriving in this new home, I told > them all the good I think of the Gentoo distribution and of its people. > If there is one distribution which made me progress substantially in my > understanding of the Linux system, it is Gentoo, with no doubt. > > Before leaving your community, I want to wish you all the best and thank > you very much for your constant effort to make free and open source > software available to everyone. > > With kind regards > > José > > I never spoke with you, but totally agree that Gentoo's a great place to learn more about GNU/Linux as a whole. I'm sure many French users appreciated your work on the documentation, and I'm sure the people at Fedora will feel the same. Good luck out there! -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On 05/04/2016 04:12 PM, William Hubbs wrote:
> On Wed, May 04, 2016 at 07:41:39PM +1000, Sam Jorna wrote:
>> On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote:
>>> On 05/04/2016 10:52 AM, Sam Jorna wrote:
>>>> On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
>>>>>>>>>> On Wed, 4 May 2016, Austin English wrote:
>>>>>
>>>>>>> Your list of affected packages obtained with "git grep" in the
>>>>>>> Portage tree will not be complete, since the command won't catch
>>>>>>> any init scripts installed from elsewhere. You should look for the
>>>>>>> set of installed files instead.
>>>>>
>>>>>> How is that relevant here at all? I'm cleaning up portage installed
>>>>>> init scripts, [...]
>>>>>
>>>>> You are cleaning up only those init scripts that are installed from
>>>>> FILESDIR, but you will miss the ones that are installed from a file
>>>>> in SRC_URI.
>>>>
>>>> Perhaps an alternate way to do it would be to have a QA check look at
>>>> any files installed to ${D}etc/init.d/ and throw a warning if their
>>>> shebang is "#!/sbin/runscript"
>>>>
>>>
>>> A repoman check is a much saner approach, I'm not convinced there is
>>> sufficient need for this change to begin with, in particular to start
>>> touching a wide range of packages. Breaking backwards compatibility in
>>> any way should have a darn good reason, and I haven't seen one yet
>>
>> I'm not arguing for or against it in general, just in terms of technical
>> implementation.
>>
>> That being said, a repoman check would only catch those distributed in
>> ${FILESDIR} as well. My thinking with the above was to also identify
>> those installed from distfiles to be handled accordingly.
>
> Actually, you won't need to worry about any qa checks in portage,
> because I am going to put a deprecation warning in OpenRC upstream which
> will be displayed when a service script invokes runscript instructing
> you to convert to openrc-run.
>
> OpenRC will keep runscript, with this warning, for a while.
>
> William
>
This sounds like the most sane approach to me, in conjunction with a
repoman warning or error once OpenRC announces deprecation 'upstream'.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] On banning merge commits
On 05/08/2016 01:21 AM, Greg KH wrote: > On Sun, May 08, 2016 at 01:44:43PM +0800, cbergst...@pathscale.com wrote: >> Don't be crazy - I know many developer groups which dislike merge >> commits. That nonlinear work flow is just a mess long term. > > Really? What "mess" does it cause? > > Are things harder to bisect? Harder to determine what came before what? > Harder to do future development? Harder because it is unfamiliar > compared to the cvs workflow? > > Or just "messier" when you look at the graph of the tree? > > What is the _real_ reason that you don't like merges? > > thanks, > > greg k-h > I don't have a strong -- or even clear -- opinion on the matter, but I could imagine it being a bother to see a bunch of "merge commit" commit messages in `git log` and not really have much to go on as far as "who submitted this, who approved it, what does it fix, etc". As far as I know, there's only the committer information and any GPG-signing that may have accompanied it, as we do in Gentoo. If I have any details wrong, please clarify. I've heard about a way to "redo" history in a git repository as well, especially before pushing. Could that be a way to mitigate merge commits, so they are more informative and conform to our commit message convention? Sincerely, a neutral party -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
