[gentoo-dev] USE flags in base profiles

The following USE flags are enabled by default in our base/linux profiles. I think they can be disabled, possibly turning them on in package.use (or in the ebuilds) if they are important. Yes, no? 1. USE=cracklib (base/make.defaults) This might belong in the hardened profile, but it doesn't

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

On 10/19/2017 06:32 PM, Hanno Böck wrote: > > Counterproposal: Just use SHA512. > > There isn't any evidence that any SHA2-based hash algorithm is going to > be broken any time soon. If that changes there will very likely be > decades of warning before a break becomes practical. > Every WiFi

Re: [gentoo-dev] pkg_rm_pretend?

On 10/11/2017 12:20 PM, Kent Fredric wrote: > TL;DR: It would be very nice if when I did: > > emerge --depclean -va > > That important packages like say, Postgres could go "hey, that's ... > probably gonna break things, you haven't migrated, are you sure?" > This might also scratch the itch

Re: [gentoo-dev] Reviving the Sandbox project

On 09/22/2017 05:51 PM, R0b0t1 wrote: > On Thu, Sep 21, 2017 at 2:56 PM, Michał Górny wrote: >> [1]:https://wiki.gentoo.org/wiki/Project:Sandbox >> > > I think I understand, in principle, why a sandbox could be useful, but > would it not be more productive to follow up with

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

On 09/12/2017 09:50 AM, Michał Górny wrote: > > If you consider doing 'rst2html.py glep-0001.rst > glep-0001.html' hard, > then I'm afraid I won't be able to ever satisfy you. > Does that command produce something that looks as good as this?

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

On 09/11/2017 05:06 PM, Michał Górny wrote: > > Example of GitHub rendering: > https://github.com/mgorny/glep-draft/blob/preamble-test/glep-0001.rst > > IMO this beats the preview/editing capabilities MediaWiki gave us. > If that's how we get an offline preview, I'm not sold =P I can run

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

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

Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed

On 09/06/2017 02:39 PM, Chris Mayo wrote: > > I believe @EXAMPLE is only for the first documentation block introducing the > eclass. > > At least where it is used for functions the text doesn't show up in the man > page. > e.g. prefix.eclass hprefixify() and prefixify_ro() > Looks like

Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed

On 09/03/2017 11:56 AM, Chris Mayo wrote: > # > # The following snippet would suggest app-misc/foo for optional foo support, > # app-misc/bar or app-misc/baz[bar] for optional bar support > Would the @EXAMPLE tag[0] make sense here? [0] https://devmanual.gentoo.org/eclass-writing/index.html

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 10:24 AM, Michael Orlitzky wrote: > On 08/30/2017 10:10 AM, Ian Stakenvicius wrote: >> >> I wonder though, per the original idea, wouldn't it make more sense to >> allow uninstallation to continue and just very verbosely >> warn/log/document what the pa

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 10:10 AM, Ian Stakenvicius wrote: > > I wonder though, per the original idea, wouldn't it make more sense to > allow uninstallation to continue and just very verbosely > warn/log/document what the package removal didn't do, so that it can > be done later by hand as needed? > My

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 09:46 AM, Ian Stakenvicius wrote: > > For adding this to FEATURES and RESTRICT, are we moving into PMS > modification territory? And if so, is this something we want to do > just for this? > The new RESTRICT value would need a PMS update, but the "just for this" part is where it

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 09:26 AM, Ulrich Mueller wrote: > >> 1a. If you try to uninstall a user package, it should die(), because >> calling userdel can be a security risk if the user still owns >> files. > > This rather sounds like a case for package manager support with > some property

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 05:25 AM, Michał Górny wrote: > > This package does not belong in Gentoo. We do packaging, not some ugly > malware that prevents users from uninstalling itself. Every package must > be uninstallable. Even if it destroys my system, developers have no > right to prevent valid

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 04:04 AM, Alexis Ballier wrote: > > Is there any point in dying in any phase after (or during) > pkg_postinst ? > files are already live by then; what would this achieve ? > I was hoping that die() called in pkg_prerm would have a similar effect as pressing Ctrl-C when portage is

[gentoo-dev] Of death and prerm

What should happen if an ebuild calls "die" in pkg_prerm? The issue arose while trying to create a package that could not be uninstalled except as part of an upgrade. The first thing that came to mind was to have it die in pkg_prerm. What portage does is *appear* to crash, but then continue

Re: [gentoo-dev] Guidelines for dangerous USE flags

On 08/22/2017 02:44 PM, Robin H. Johnson wrote: > From a Gentoo Infrastructure team perspective, we'd strongly prefer USE > flags, because that fits better into existing configuration management > tools, almost none of which have handling for EXTRA_ECONF or rebuilding > after EXTRA_ECONF changes

[gentoo-dev] Guidelines for dangerous USE flags

The net-analyzer/nrpe package has a ./configure flag: --enable-command-args allows clients to specify command arguments. *** THIS IS A SECURITY RISK! *** Read the SECURITY file before using this option! Back in nrpe-2.x, it was available via

Re: [gentoo-dev] Re: Revisions for USE flag changes

On 08/14/2017 08:01 AM, Jason Zaman wrote: > > I'll give an example where revbumps are significantly inferior to > --changed-use. > > ... With --changed-use, only the people who need it (ie selinux > users) will rebuild and everyone is happy (selinux users because the > program now works and

Re: [gentoo-dev] Revisions for USE flag changes

On 08/13/2017 12:06 PM, William Hubbs wrote: > > There is a down side you didn't talk about -- more work for the arch > teams and for us in terms of stabilizations. > > When we revbump, a new revision automatically gets ~ keywords on all arches > unless we make an exception. If a revision

Re: [gentoo-dev] Revisions for USE flag changes

On 08/13/2017 01:01 AM, Hans de Graaff wrote: > On Sat, 2017-08-12 at 05:58 -0400, Michael Orlitzky wrote: >> >> I simply overlooked the global USE change in make.conf because IMO >> it's a nonsense operation. > > This also happens routinely as new python and ruby v

Re: [gentoo-dev] Re: Revisions for USE flag changes

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

Re: [gentoo-dev] Re: Revisions for USE flag changes

On 08/12/2017 10:32 PM, Duncan wrote: >> >> What if you fix a runtime issue by dropping a flag? It's more confusing >> than it has to be: the USE flag exception interacts weirdly with all the >> other rules. > > Bad example as it's a security vuln, which requires masking/removing > vulnerable

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 06:29 AM, Rich Freeman wrote: > > My gut feeling is that the change you want is probably a good thing, > but it will never happen if you can't provide a single example of > something bad happening due to the lack of a revbump. There's an unfixed security vulnerability with USE=foo,

Re: [gentoo-dev] Re: Revisions for USE flag changes

On 08/12/2017 12:22 AM, Michael Palimaka wrote: > >> Q. But what if I maintain firefox, and I need to change IUSE? >> >> If the IUSE change isn't important, just make the new revision in a >> branch and wait to commit it later when there are more changes >> piled up. If it is important

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 04:39 AM, Paweł Hajdan, Jr. wrote: >> >> The option is the same as --newuse except it ignores functionality that >> you suggest to remove. You could certainly deprecate one option or the >> other if they became the same. But the core functionality of >> system-wide USE changes (by

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 03:03 AM, Michał Górny wrote: > > Please provide some examples of recent in-place USE changes that benefit > from revbumps. > There is no single example. Things only get simpler if *all* USE changes come with a new revision.

Re: [gentoo-dev] Revisions for USE flag changes

On 08/11/2017 08:59 PM, Michael Orlitzky wrote: > > Does --changed-use help there? I can see the argument for --newuse, but > I thought --changed-use only applied to flags that were added or removed > to installed packages (which becomes impossible, if we require new

Re: [gentoo-dev] Revisions for USE flag changes

On 08/11/2017 08:45 PM, Brian Evans wrote: > > I disagree about removing --newuse and --changed-use from portage. > This is not their only use. > > If you happen to change the effective use system wide, USE= in make.conf > for portage, these options scan the entire system for such changes. >

[gentoo-dev] Revisions for USE flag changes

We have a pull request for the devmanual that will update the revision documentation; namely, when to create a new one: https://github.com/gentoo/devmanual.gentoo.org/pull/67 The comments bring up an issue that I think can benefit from some hindsight. Specifically, the PR says that it's OK to

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/04/2017 02:50 AM, Michał Górny wrote: > > Why is it fine for you to handicap everyone else for your personal > laziness? As it's been told more than once, you write ebuild *once*, > people read it *multiple times*. Look, I'm sorry if I've been overly confrontational. I emailed angry and I

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/03/2017 06:33 PM, Ulrich Mueller wrote: >>>>>> On Thu, 3 Aug 2017, Michael Orlitzky wrote: > >> The developer handbook that I just said didn't mention variables in >> HOMEPAGE at all. > > It did, even back in 2004: > https://sources.gentoo.org/cg

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/03/2017 03:39 PM, Mike Gilbert wrote: >> >> (The old handbook never mentioned variables, from what I can see.) >> > > The developer handbook was also a "policy" manual of sorts when it existed. The developer handbook that I just said didn't mention variables in HOMEPAGE at all.

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/03/2017 02:57 PM, Mike Gilbert wrote: > > It's in the devmanual, which imposes gentoo-specific policy on top of PMS. > It would be nice if that were true, but there's a lot of junk and/or personal preference documented in the devmanual, and a lot of actual-policy that's still missing

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/03/2017 11:33 AM, Mike Gilbert wrote: > I would like to remove the ban on variable references in the HOMEPAGE > variable in ebuilds. > What ban are you referring to? The Portage Manager Specification doesn't say anything of the sort. Seriously though, whatever sort of tricks your

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 04:29 PM, Mike Gilbert wrote: > > I don't feel I should be obligated by policy to support this use case. > One revbump per push seems sufficiently safe for 99.9% of users. > > If you want to do more revbumps, you are free to do so. > Can I also delete packages and break the tree

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 09:23 AM, Michał Górny wrote: > > How is that relevant? Revision bumps are merely a tool to encourage > 'automatic' rebuilds of packages during @world upgrade. I can't think of > a single use case where somebody would actually think it sane to > checkout one commit after another,

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 07:52 AM, Michał Górny wrote: > > I have no clue what you mean. I'm just saying that if you push 10 > changes in 10 commits, you don't have to go straight to -r10 in a > single push. > Exactly. Do that instead of hoping that no one checks out your intermediate commits. There's no

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 04:05 AM, Michał Górny wrote: > > Here's the current draft: > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git > It's mostly fine, but there are two changes I disagree with: > When doing one or more changes that require a revision bump, bump the > revision in the commit

Re: [gentoo-dev] Lastrites: dev-libs/radlib, net-voip/gnugk, sci-electronics/ghdl...

On 06/14/2017 10:21 AM, Pacho Ramos wrote: > > # Pacho Ramos (14 Jun 2017) > # All consumers of this newer versions never got ported, if finally we need > # to readd a even newer version of this packages with an hypothetical newer > # Ekiga, we will need to work on new ebuilds

Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

On 06/05/2017 07:06 AM, Kent Fredric wrote: > On Mon, 05 Jun 2017 09:11:27 +0200 > Hans de Graaff wrote: > >> # Hans de Graaff (05 Jun 2017) >> # Bundles obsolete and vulnerable webkit version. >> # Upstream has stopped development and recommends using >> #

Re: [gentoo-dev] Lastrites: x11-misc/rednotebook

On 06/02/2017 04:38 AM, Pacho Ramos wrote: > # Pacho Ramos (02 Jun 2017) > # Relies on obsolete and vulnerable webkit-gtk version and bundles some libs > # (#597532). Removal in a month. > x11-misc/rednotebook > The bundled libs wouldn't be too hard to eliminate, but we didn't

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

On 05/09/2017 09:36 AM, Anthony G. Basile wrote: > > Perhaps I'm missing the issue, but can you just follow the dependencies > and drop keywords accordingly so the tree remains consistent. > If we can make it policy that I'm allowed to edit a bunch of other peoples' packages and de-keyword

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

On 05/09/2017 04:12 AM, Rich Freeman wrote: > On Tue, May 9, 2017 at 12:23 AM, Yury German wrote: >> >> we can not call for cleanup or release the GLSA, >> waiting for a stabilization of a non-core package, while the actual >> package has been in a tree in ~arch status for

Re: [gentoo-dev] [PATCH 1/2] app-portage/eclass-manpages: Introduce additional variable classes

On 04/28/2017 10:59 AM, Michał Górny wrote: > Add a few additional variable classes to better emphasize the specifics > of different kinds of variables set for eclasses, and by eclasses. > > The change applied, each eclass variable can belong to one of > the following five eclasses: We did some

Re: [gentoo-dev] Reverse use of Python/Ruby versions

On 04/09/2017 08:58 PM, William L. Thomson Jr. wrote: I am NOT talking about stabilization at all. Simple reducing the burden of adding targets to ebuild, and users having to fiddle with targets as they come and go. You are: when you find out that a stable package doesn't work with the next

Re: [gentoo-dev] Reverse use of Python/Ruby versions

On 04/09/2017 07:15 PM, William L. Thomson Jr. wrote: If the package failed, all that would need to be done kinda like now is a given variable modified in the ebuild. Just marking what ever it did not work with. As mentioned that could be done via my ebuild-batcher[1], though same functionality

Re: [gentoo-dev] Reverse use of Python/Ruby versions

On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote: Not sure if this is practical, it may be less work if the use of Python and Ruby versions ( maybe others ) is reversed. Rather than adding all the versions that the ebuild supports. What if it only included versions it did not support? Even

Re: [gentoo-dev] Review: xemacs-packages-r1.eclass

On 04/02/2017 05:05 AM, David Seifert wrote: [[ ${XEMACS_PKG_CAT} ]] || die "XEMACS_PKG_CAT was not defined before inheriting xemacs-packages-r1.eclass" case ${XEMACS_PKG_CAT} in standard|mule|contrib) ;; *) die "Unsupported package category in

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

On 03/23/2017 04:22 PM, Alexis Ballier wrote: Indeed, according to pms.git commit log, the rule was laxed because it was clearly an oversight in EAPI6 [1] and was the standard behavior in previous EAPIs. But in the same commit, an "harmless note" was added that "Ebuilds must not access the

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

On 03/23/2017 09:36 AM, Alexis Ballier wrote: No, the argument is about "we want to clean up the tree from abusive hacks". This is yours. Mike's answer is merely asking for proper justification and doesn't seem to have had an answer yet. The PMS[0] says Ebuilds must not access

Re: [gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils

On 03/11/2017 08:51 AM, Michał Górny wrote: > > However, the inherit will be removed in EAPI 7 > > ... > > -inherit estack multilib toolchain-funcs > +inherit epatch estack multilib toolchain-funcs > Would it hurt to do that now, so that we don't forget when EAPI 7 comes? For EAPI=0 to 6,

Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies

On 03/09/2017 06:16 PM, William L. Thomson Jr. wrote: > > Case in point dev-db/firebird use to have a line like > > rm -rf "${S}"/extern/{btyacc,editline,icu} || die > > But if you look at current ebuild it is now > > rm -r "${S}"/extern/{btyacc,editline,icu} || die > > The force

Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies

On 03/09/2017 02:00 PM, William L. Thomson Jr. wrote: > > Under what circumstances? > > ... > > Seems like it is not possible to generate the above permission issue. > I can make them up all day... * VENDOR_PATH=VENDORPN="" and we try to "rm -rf /" * A hard drive error occurs. *

Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies

On 03/09/2017 01:21 PM, William L. Thomson Jr. wrote: > Pretty sure no need for the ||die, rm -fr should never fail. > > rm -fr "${VENDOR_PATH}/${VENDORPN}" || die > $ rm -rf /bin/cp || echo "it failed" rm: cannot remove '/bin/cp': Permission denied it failed

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/09/2017 10:36 AM, William Hubbs wrote: > On Wed, Mar 08, 2017 at 07:49:08PM -0500, Michael Orlitzky wrote: >> On 03/08/2017 02:20 PM, William Hubbs wrote: >>> >>> Another option is to not force this and rely on everyone to use >>> --wit

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/08/2017 02:20 PM, William Hubbs wrote: > > Another option is to not force this and rely on everyone to use > --with-bdeps=y to make the rebuild happen. > That feature is portage-only. Slot operator deps in DEPEND are meaningless.

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/08/2017 01:27 AM, Zac Medico wrote: > On Tue, Mar 7, 2017 at 4:38 PM, William Hubbs <willi...@gentoo.org> wrote: >> On Tue, Mar 07, 2017 at 07:13:38PM -0500, Michael Orlitzky wrote: >>> If all dev-go libraries wind up in RDEPEND solely to force rebuilds on >>&

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/07/2017 07:02 PM, Patrick McLean wrote: > > You also need to recompile to get security bugs fixed. With go it's not > just compiler options, it's also the standard library updates that need > a recompile to get. > If that's the reasoning, then don't you have the same problem with every

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/07/2017 05:40 PM, William Hubbs wrote: > Hi all, > > I was attending SCALE, but now I'm back to answer this. > > On Thu, Mar 02, 2017 at 04:46:22PM -0500, Michael Orlitzky wrote: >> What kind of dependency do we need, anyway? William, are you saying that >&g

Re: [gentoo-portage-dev] [PATCH v2] emerge: auto-enable --with-bdeps if --usepkg is not enabled (bug 598444)

On 03/05/2017 02:12 PM, Zac Medico wrote: > > Incorrect. > > ... > > Incorrect. > I see my mistakes, but maintain that this is confusing =) > > The --with-bdeps-auto option results in desirable behavior by default, > and it's also backward compatible with existing --with-bdeps and >

Re: [gentoo-portage-dev] [PATCH v2] emerge: auto-enable --with-bdeps if --usepkg is not enabled (bug 598444)

On 03/05/2017 03:40 AM, Zac Medico wrote: > > A new --with-bdeps-auto= option is provided, making it possible to > enable or disable the program logic that causes --with-bdeps to be > automatically enabled. Use --with-bdeps-auto=n to prevent --with-bdeps > from being automatically enabled

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/02/2017 04:53 PM, Alexis Ballier wrote: >> >> Back on topic: >> >> What kind of dependency do we need, anyway? William, are you saying >> that if I upgrade dev-lang/go, then things will break, but if I delete >> dev-lang/go, everything is fine? > > It's likely like ocaml: you link your

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/02/2017 04:30 PM, Ciaran McCreesh wrote: > > The point is to specify dependencies declaratively. A dependency > expresses a dependency, not an action. If you can't express the kind of > dependency you need, then we need either labels or another *DEPEND > variable to take care of it, not a

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/02/2017 04:06 PM, Zac Medico wrote: >> >> I agree with this ^ but I don't think portage should rebuild for DEPEND >> at all. It creates one more dangerous "it works in portage!" situation >> that will plague users of other package managers. >> >> (I'm not saying it couldn't be useful, but it

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/02/2017 02:05 PM, Zac Medico wrote: >> >> This is why we can't have nice things. > > For those that are interested, I'm planning to to make --with-bdeps > automatically enabled when possible: > I agree with this ^ but I don't think portage should rebuild for DEPEND at all. It creates one

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/02/2017 09:24 AM, Mike Gilbert wrote: >> >> In other words, the ":=" only does something special in RDEPEND. That >> makes sense when you think of it as meaning "the thing will break" >> rather than "I want to do a rebuild." The only reason it's not an error >> to put them in DEPEND is

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/02/2017 04:58 AM, Alexis Ballier wrote: > > Is it really abusing ? > := deps in DEPEND only would also make sense for e.g. code generators > Slot operator dependencies are ignored in DEPEND: Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates

Re: [gentoo-dev] Guidelines for IUSE defaults

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

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/07/2017 02:52 AM, Ulrich Mueller wrote: > > I see no point in discouraging IUSE defaults, given that they are > purely advisory for the package manager: > > "[...] any use flag name in IUSE may be prefixed by at most one of a > plus or a minus sign. If such a prefix is present, the package

Re: [gentoo-dev] Re: Requirements for UID/GID management

On 02/04/2017 03:50 AM, Christopher Head wrote: >> >> Not a bad idea... we chould ship that safe-chown utility, and then >> tell users how to use it to fix their UIDs. The draft that I wrote up >> was for the "fixed UID with random fallback" model, but said utility >> could still be useful for

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/03/2017 08:07 PM, Patrick McLean wrote: > > I think the current policy of "maintainer's discretion" is probably the > only reasonable way to approach IUSE defaults... > > Leaving the IUSE defaults up to the maintainer allows said maintainer > to select what they consider reasonable

Re: [gentoo-dev] Guidelines for IUSE defaults

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

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/03/2017 10:30 AM, Ian Stakenvicius wrote: > > ok you lost me. Could you provide an explicit example of what you > would want to see enabled in the profile (while everything else is > disabled) that you don't get when USE="-*" is set? USE="hardened pax_kernel ..." > > It's sounding more

Re: [gentoo-dev] Re: Requirements for UID/GID management

On 02/03/2017 09:51 AM, Martin Vaeth wrote: > Michael Orlitzky <m...@gentoo.org> wrote: >> >> The fact that all permission and ownership information is shared is >> precisely the problem. When you change ownership of the hardlink (which >> you'll never know is

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/03/2017 08:21 AM, Ian Stakenvicius wrote: >> >> How about rather changing our defaults to satisfy the minimalists who >> don't mind drastically reduced functionality and usability in pursuit >> of "minimalism" we just strive to make USE="-*" mostly usable, so the >> minimalists can get what

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 10:16 PM, Patrick McLean wrote: > > There are people who run servers on Gentoo, and don't particularly want > minimalism, then want a normal Linux system level of functionality (ie > upstream and/or sane defaults) without having to add dozens of USE > flags to random packages

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 09:31 PM, Rich Freeman wrote: > > The desktop profile is going to do things like enable X11 support by > default. It isn't going to do things like enable bzip support in > ffmpeg (but not the new experimental codec that causes it to crash 25% > of the time, but which apparently

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 09:22 PM, Sam Jorna wrote: > > Also, how would this work with local USE flags as opposed to global > flags? Would they be acceptable to have IUSE defaults? > Exactly the same way as global flags: drop an entry in the desktop profile's package.use.

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 09:00 PM, Sam Jorna wrote: > > Consider: a new user, coming from Ubuntu or Fedora or Windows, starts > building their system. They start installing packages they want, only to > find that half of the package isn't there because no USE flags were > enabled. They have to enable

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 01:01 PM, Rich Freeman wrote: > On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <m...@gentoo.org> wrote: >> >> If (base == minimal), then all of the upstream defaults need to be added >> to package.use for the upstream-defaults profile. That's bad, &

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 06:41 PM, Ian Stakenvicius wrote: > Responding here instead of the first time it was posted, just 'cause. > > On 02/02/17 06:35 PM, james wrote: >> " >> I'm not saying that we should have a minimal experience out-of-the-box, >> only that the base profile should result in an

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 12:23 PM, Walter Dnes wrote: > On Thu, Feb 02, 2017 at 09:11:26AM -0500, Michael Orlitzky wrote > >> 2 To avoid an unsatisfied REQUIRED_USE by default. >> >> * Example: having a non-empty RUBY_TARGETS by default. > > What's wrong with having em

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

On 02/02/2017 12:06 PM, William L. Thomson Jr. wrote: > >> But more importantly, icedtea-bin was just one example that I had in >> mind. There are hundreds of others in the tree. > > Sure, but some packages themselves go against a minimalist approach due to > their own build requirements. You

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

On 02/02/2017 11:18 AM, William L. Thomson Jr. wrote: > > If you look at dev-java/icedtea ebuild you will see > > # Gtk+ will move to COMMON_DEP in time; PR1982 > > I cannot find PR1982 referenced to link. But shows that it is needed and > causes > issues without being set. > I don't really

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 11:08 AM, Rich Freeman wrote: > > Which is simpler, a minimal profile that sets USE=-* and then lists a > few exceptions where that breaks in package.use, or an upstream > defaults profile (which becomes the basis for all the other profiles) > that has a 5000 line package.use file

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

On 02/02/2017 11:09 AM, James Le Cuirot wrote: > > Actually he's right. Java can obviously be used without GTK and that's > something we support but upstream hasn't taken the time to make it > possible to build without it. Apparently that isn't a trivial thing to > do. > > In my earlier mail, I

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

On 02/02/2017 10:51 AM, William L. Thomson Jr. wrote: > On Thursday, February 2, 2017 10:36:51 AM EST Michael Orlitzky wrote: >> Why does dev-java/icedtea try to pull in GTK (and thus X) >> on a headless server? That stuff belongs in a desktop profile, not in >> the base one.

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 10:52 AM, Rich Freeman wrote: > On Thu, Feb 2, 2017 at 10:36 AM, Michael Orlitzky <m...@gentoo.org> wrote: >> >> Why does dev-java/icedtea try to pull in GTK (and thus X) >> on a headless server? That stuff belongs in a desktop profile, not in >> th

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 09:56 AM, Ian Stakenvicius wrote: > >> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky <m...@gentoo.org> >> wrote: >> >> IUSE defaults are used in a few different ways: >> >> 1 To ensure that critical functionality is enabled. >>

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 10:06 AM, Kristian Fiskerstrand wrote: > On 02/02/2017 03:11 PM, Michael Orlitzky wrote: >> Can we discourage IUSE defaults except for #1 and #2? I'm equally guilty >> of #3 and #4, but I now regret them. I would also like to see >> explanations in metad

[gentoo-dev] Guidelines for IUSE defaults

IUSE defaults are used in a few different ways: 1 To ensure that critical functionality is enabled. * Example: force the "unix" module for apache. 2 To avoid an unsatisfied REQUIRED_USE by default. * Example: having a non-empty RUBY_TARGETS by default. 3 To make Gentoo defaults

Re: [gentoo-portage-dev] [PATCH] sys-apps/portage: add native-extensions USE flag (bug 571444)

On 02/01/2017 04:03 PM, Michał Górny wrote: >> SLOT="0" >> -IUSE="build doc epydoc +ipc linguas_ru selinux xattr" >> +IUSE="build doc epydoc +ipc linguas_ru native-extensions selinux >> xattr" > > Wouldn't it be better to enable it by default? > Please don't enshrine personal preferences into

Re: [gentoo-dev] Requirements for UID/GID management

On 01/30/2017 01:05 PM, Patrick McLean wrote: > > No, that is also enabled by default on vanilla kernels, I just verified > on my machine running a vanilla kernel. It doesn't matter anyway, since > the permissions and ownership information is stored in the inode, not > the dentry so all hardlinks

Re: [gentoo-dev] Requirements for UID/GID management

On 01/30/2017 09:25 AM, Alan McKinnon wrote: >> >> Any user can create a hard link in its home directory to /etc/shadow, so >> long as (a) they live on the same filesystem, and (b) there are no >> special kernel protections in place to prevent it. If you call chown on >> that hard link, it will

Re: [gentoo-dev] Requirements for UID/GID management

On 01/29/2017 06:34 PM, Ulrich Mueller wrote: > > Our syntax for package names is more restrictive than what POSIX > allows for a portable user name. Therefore, there could be user names > that are not representable. Have you checked if all user and group > names currently in use (at least in the

Re: [gentoo-dev] Requirements for UID/GID management

On 01/29/2017 05:30 PM, Alan McKinnon wrote: > > Good catch with symlinks. > I don't see the point about hardlinks, they are just files with 2 > dentries. When find gets to the second one it's already changed, so no > problem. > Any user can create a hard link in its home directory to

Re: [gentoo-dev] Requirements for UID/GID management

On 01/29/2017 05:07 PM, Alan McKinnon wrote: > > Sure it can be done, just don't chown -R ~user. DO it the VERY > long way round, file by file. Say you changed user "awesome" uid 300 to 400: > > find / -uid 300 -exec chown awesome {} \+ > That will find symlinks created by UID 300, and chown

Re: [gentoo-dev] Requirements for UID/GID management

On 01/27/2017 12:54 PM, Michael Orlitzky wrote: > We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but > never implemented it. I'm wondering what are the explicit requirements > that we have for user and group management? > > What I'm really wondering is, instead

Re: [gentoo-dev] Requirements for UID/GID management

On 01/29/2017 05:03 AM, Ulrich Mueller wrote: >>>>>> On Sat, 28 Jan 2017, Michael Orlitzky wrote: > >> [...] sys-user/echo [...] > > [Replying to a random message in this thread, as I have some backlog.] > > Users and groups aren't packages, so IMHO pac

<    1   2   3   4   5   6   7   8   9   10   >