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,
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 (lik
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 p
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.
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
> revisio
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.
>
Do
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 c
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 k
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.o
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.
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 becau
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 opponents
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 s
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, and
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 l
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 including
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 anyway, bug #474740
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
>> # headless mode in >=www-client/chromium
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 have
packages for
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 stabl
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 weeks or months.
>
> Wh
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 w
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
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
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
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 XE
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 direc
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 [FILESDIR]
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, in
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 option/argume
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.
* Ba
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
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
>>> --with-bdeps=y to mak
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.
On 03/08/2017 01:27 AM, Zac Medico wrote:
> On Tue, Mar 7, 2017 at 4:38 PM, William Hubbs 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
>>> upgrades, why not do
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
oth
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
>>
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 progr
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 bo
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
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
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 becaus
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
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
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
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 peop
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 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 maintenance,
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 a
On 02/03/2017 09:51 AM, Martin Vaeth wrote:
> Michael Orlitzky 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 a hardlink), you
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 t
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 through
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 work
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.
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 these
On 02/02/2017 01:01 PM, Rich Freeman wrote:
> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky 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,
>
> I&
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 effective
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 havi
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 ha
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
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 th
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 w
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.
On 02/02/2017 10:52 AM, Rich Freeman wrote:
> On Thu, Feb 2, 2017 at 10:36 AM, 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.
>
>
On 02/02/2017 09:56 AM, Ian Stakenvicius wrote:
>
>> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky
>> wrote:
>>
>> IUSE defaults are used in a few different ways:
>>
>> 1 To ensure that critical functionality is enabled.
>>
>> * Example: force
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 metadat
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 t
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
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 cha
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
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 /etc/shado
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 w
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
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 p
On 01/29/2017 03:26 AM, Alan McKinnon wrote:
>>
>> Can anyone think of an upgrade path for fixed UIDs? That issue aside, I
>> may have convinced myself that fixed UIDs are better.
>
> The general process I would recommend is that if the ebuild finds the user
> already exists, leave it, it's UID an
On 01/28/2017 10:23 PM, Gordon Pettey wrote:
>
> That's nonsense for reasons already mentioned by rich0. UIDs don't change
> except in the case of an admin doing it manually.
>
It shouldn't be common, but it can and will happen once you put users in
ebuilds. As an example, imagine an "echo" daem
On 01/28/2017 09:22 PM, Rich Freeman wrote:
>
> Honestly, I really will say "so what" here. :)
>
I forgot to mention a few of the advantages of having really-fixed UIDs.
First, it makes the code simpler. Yup, cool.
It also lets us play a nice trick and use the UID as a subslot, so that
if some
On 01/28/2017 09:22 PM, Rich Freeman wrote:
>>
>> Here's a problem I have no solution for. Suppose we tell everyone to
>> pick a fixed UID for their user packages. I have a randomly assigned
>> "tcpdump" user as UID 102 on my machine today. If we roll this out next
>> week and the tcpdump maintaine
On 01/27/2017 11:21 PM, Rich Freeman wrote:
>
> It isn't like inconsistent UIDs are the end of the world. However,
> IMO it still makes sense to at least try to standardize such things.
> Really, if you have a package always installing the same user simply
> sticking a default UID without any eff
On 01/27/2017 09:37 PM, Patrick McLean wrote:
>
> To make something to solve our problem (and I suspect everyone
> else who cares about this), it would be sufficient to have a mechanism
> to override the default random assignment with a fixed UID/GID.
What I had in mind for this is that a "normal
On 01/27/2017 04:15 PM, Michał Górny wrote:
>
>> * users-update: cleanup can be done with --depclean now.
>
> Err, cleanup is never easy. You shouldn't really remove a user if it
> owns any files. I guess you could abuse pkg_prerm() for that but
> depclean will be terribly slow then.
>
What ar
On 01/27/2017 02:53 PM, Rich Freeman wrote:
>
> I'm not saying we can't have random assignment for things where it
> doesn't matter, or fall back to random assignment, but it seems rather
> silly to go to all the trouble to have blockers when it would be just
> as easy to not have a conflict in th
On 01/27/2017 01:52 PM, Rich Freeman wrote:
>
> This doesn't really seem like a problem though. Just have a table
> somewhere (wiki?) to track who is using what UID/GID and encode those
> defaults into the ebuild that creates those users.
>
It should be possible to have two different users with
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 of the proposal in GLEP27, if we
couldn't simply handle users like any oth
Forked from the gdbm/berkdb thread, wall of text ensues...
On 01/27/2017 03:32 AM, Fabian Groffen wrote:
>
> You mention REQUIRED_USE should be used sparingly, I think I see your
> reasoning, but if so, then why did we add it in the first place?
There are a few conflicting interests at play. Bef
On 01/26/2017 10:33 PM, Mike Gilbert wrote:
>
> Is there any reason to have these USE flags enabled globally?
They are quite uncritical.
> These USE seem pretty package-specific in scope. On my system, they
> are used by around a dozen of 1000+ installed packages. I think it
> might make sense
On 01/24/2017 11:11 AM, Mart Raudsepp wrote:
>
> Currently this seems to be resulting in broken deptrees for arches that
> don't have a stable profile. arm64 in particular.
ALLARCHES should not include the unstable ones unless they are
specifically in CC, and of course you should be running repom
On 01/23/2017 02:30 PM, Alexis Ballier wrote:
>
> repoman will test n out of 2^n (or n!) possibilities the way you
> suggest, which is basically nothing when n is big
>
Corollary: big is basically nothing.
I like it.
On 01/10/2017 06:54 AM, Jan Stary wrote:
>
> These are workarounds. Let me get back to the original question:
> would you please consider having _uncompressed_ manpages as the default?
>
> On this particular system, the bzipped /usr/share/man/ is 67M.
> The uncompressed man/ is 108M. That's 40M s
The "frontbase" USE flag has no consumers that I can find:
gentoo.git $ grep -irl frontbase *
profiles/arch/x86/use.mask
profiles/use.desc
profiles/base/use.mask
If no one objects, I'll drop the flag and its masks.
On 12/25/2016 02:55 PM, Andrew Savchenko wrote:
>
> What is a recommended way to describe how runtime testing should be
> done? Some packages are quite complex and it is desired not only to
> run them, but to run with some args or do some actions.
>
> Some ideas:
>
> ...
The Emacs team came up
On 12/18/2016 08:19 PM, malc wrote:
> I git'ified the original CVS scripts... it would be trivial to extract
> the author-name (add %an in the format string for git-log), but we tried
> to keep the generated e-mail to 80-char lines - and that would blow it.
>
One option would be to tag each addit
On 12/18/2016 07:05 PM, Robin H. Johnson wrote:
>
> Additions:
> ...
> dev-php/ca-bundle 20161124-07:43 mjo 7597666
> dev-php/cli-prompt20161124-07:21 mjo d3bd351
> dev-php/composer 20161124-08:09 mjo d273046
> de
On 12/13/2016 06:11 AM, Mike Pagano wrote:
>
> You're absolutely right, Mike. It was the devmanual.
>
> I'm not a fan of having an empty usage. As the devmanual is written
> today, it is not optional.
>
The devmanual is once again based on the awk script, which vaguely
implies that USAGE is req
On 12/10/2016 01:12 AM, A. Wilcox wrote:
>
> So for one example, at Adélie we are focusing hard on the musl libc.
> At some point in the future, when we have things looking good, we can
> contribute that back to the official Gentoo musl overlay. Ideally,
> that would be the main Gentoo package tr
On 12/07/2016 03:59 PM, Andreas K. Huettel wrote:
>
> Hi Doug,
>
> I like it, actually more than my version- with one exception... if we do a
> step with EAPI, we should be able to get this done without the -r1 mess.
>
> I'll try to whip up something reasonably elegant based on your patch...
On 12/04/2016 10:13 PM, A. Wilcox wrote:
>
> If there are no other objections to this proposal, would a PR that
> implements this against the Gentoo tree be the best way forward? If
> so, I can start work on that now while giving more people the chance
> to read over it. (Would it be more desira
On 12/04/2016 06:18 PM, Andreas K. Huettel wrote:
> Starting with EAPI=6, the variables APACHE_BASEDIR and APACHE_MODULESDIR
> are not exported in global scope anymore.
Currently, we emit a warning when using depend.apache with EAPI=6. How
many packages are triggering that warning? If we stop expo
On 12/03/2016 09:25 AM, William L. Thomson Jr. wrote:
>>
>> This is generally considered infeasible:
>
> I would not think such, just need a wrapper to run around each package that
> would get its USE flags and re-emerge it a few times.
If a package has 10 USE flags, and if each can be set on/of
On 12/02/2016 10:14 AM, Andrew Savchenko wrote:
>
> If both policies are to be followed, users will see something like:
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> a separate commit with a revision bump).
>
> While such versioning change is technically correct, it is
>
501 - 600 of 914 matches
Mail list logo
