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/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 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 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 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 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/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 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 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 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 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 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 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 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 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/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
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/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
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/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/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 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 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 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 ver
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 i
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 r
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 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 no
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 USE=c
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 (r
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 along
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 d
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 uninstall
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 like
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 g
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 gut
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 t
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
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 you're
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 Je
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 Media
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?
https://wiki.gentoo.org/wiki/User:Mjo/GLEP:User_pac
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 projects which do
> un
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
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 ne
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 do
On 10/17/2017 02:12 PM, Michał Górny wrote:
>
> Abstract
>
>
> ...
> The QA checks can inspect the installation image or live system respectively,
Respective to what?
> output and store both user- and machine-oriented QA warning logs, manipulate
> the files and abort the install, as n
On 10/25/2017 03:18 AM, Michał Górny wrote:
>>> ...
>>> The QA checks can inspect the installation image or live system
>>> respectively,
>>
>> Respective to what?
>
> To the type of check, as explained later? If you want to help, then
> please be specific instead of asking questions and expectin
On 11/09/2017 11:08 PM, Damo Brisbane wrote:
> I've run up a couple of golang based ebuilds - for the fabio load
> balancer. My first run at it, not completely sure of any follow up
> process, mentor? other posting, overlap with existing work? Anyway,
> would appreciate the feedback.
Your $VERSION
On 11/10/2017 04:36 PM, Damo Brisbane wrote:
>
> Re for...keepdir, I found removing it then the /var/log/fabio folders
> were not getting created, so keeping it in there.
You need to tell the ebuild to create that directory one way or another.
The "dodir" function will create the directory, but w
On 11/11/2017 02:58 AM, Michał Górny wrote:
>>
>> Certainly "keepdir" will make the directory non-empty, but with the
>> additional (unwanted) side-effect that the directory won't be removed
>> when the package is uninstalled.
>
> Wrong. It creates a dotfile inside it, and removes it along with it
On 11/11/2017 02:26 PM, Michał Górny wrote:
>>
>> As far as the actual implementation goes, I'm not sure that
>> automatically-generated ".keep" files are better than having the package
>> manager maintain its own database. The latter would be more complex, but
>> would avoid littering everyone's f
On 11/12/2017 08:43 AM, Michał Górny wrote:
>
> I'm not convinced a QA warning is valid, given that not every empty
> directory is meaningful. You're going to either cause people to create
> unnecessary 'keepdir's, or to be swamped by false positives.
The warning would essentially be saying, "you
On 11/12/2017 10:21 AM, Ulrich Mueller wrote:
>
>> * Change the PMS to remove "undefined behavior" and replace it with
>> "empty directories must be tracked, and may only be removed once no
>> installed package is using them," or something along those lines.
>> That leaves the implem
On 11/19/2017 01:00 PM, William L. Thomson Jr. wrote:
>>
>> This is broken: Static metadata like DEPEND must not depend
>> on dynamic data like environment variables which are supposed
>> to change at emerge time.
>
> I wondered about that. I guess adding to DEPEND via eclass is bad then.
>
So l
On 11/27/2017 03:37 PM, Arve Barsnes wrote:
>
> Sounds kind of weird? If he has keyworded the game package, shouldn't it
> just never install that version if it depends on an unstable package?
That's right, but if there are two available ~arch versions, one of
which has all stable dependencies an
On 12/02/2017 03:43 PM, Alon Bar-Lev wrote:
> Hi,
> Any reason we do not publish hardened/no-multilib?
> I see we have[1] in place and is working if explicitly added.
> Thanks,
> Alon
>
> [1] profiles/features/hardened/amd64/no-multilib
>
I'm not sure if anything is using that particular profile
On 12/09/2017 04:00 PM, Michał Górny wrote:
>
> rm -r /lib.{old,new} /usr/lib.{old,new}
>
It probably won't hurt anything, but that should be run in BASH.
On 12/12/2017 01:24 PM, Rich Freeman wrote:
>
> As far as I'm aware the standing policy already exists that
> maintainers can stabilize their own packages on amd64.
https://bugs.gentoo.org/510198
is this thing on
The "justify" USE flag is local to only app-editors/nano, but it was
enabled by default in two hardened profiles,
* hardened/linux/amd64/make.defaults
* features/hardened/amd64/make.defaults
The reasoning for that is lost to time, but probably dates back to
when nano was part of the @system s
On 11/27/2017 10:16 AM, Mike Gilbert wrote:
> On Mon, Nov 27, 2017 at 6:46 AM, Aaron W. Swenson
> wrote:
>>
>> You should now be able to do compilation and tests without having the
>> user/group created. For example, dev-db/postgresql doesn’t need the
>> postgres system user and group in order to
On 12/20/2017 02:41 PM, Virgil Dupras wrote:
>
> Maybe some kind of official overlay for packages needing love? We
> could send outdated packages there to die or to be born again if the
> right person picks it up.
>
> The overlay could have more relaxed rules (not malicious and looking
> good? no
On 12/20/2017 06:58 PM, William Hubbs wrote:
>
> There already is an overlay for dying packages, it is called graveyard,
> but no one is putting things there.
>
> This email conflates old dying packages with new versions, which are a
> completely separate issue.
>
Lack of new versions *is* dyin
The "cracklib" USE flag has long (since 2007ish) been enabled by
default for all profiles. But, the features that it provides are not
critical for any of the packages that use it: typically, the library
is used to evaluate a candidate password and to prevent the user from
choosing a weak one.
Sinc
On 12/21/2017 02:27 PM, Jeroen Roovers wrote:
> On Thu, 21 Dec 2017 10:10:30 -0500
> Michael Orlitzky wrote:
>
>> The "cracklib" USE flag ... this commit removes it from base/make.defaults.
>>
>> Closes: https://bugs.gentoo.org/635698
>
> As there:
The "session" USE flag has been enabled by default for all linux
profiles in default/linux/make.defaults since 2010. According to the
comment in that file, the flag was added for dev-lang/php where
session support is near-critical. But, now that we have an IUSE
default, the global setting is redund
On 12/27/2017 05:49 AM, Jeroen Roovers wrote:
> OK, let me explain again.
>
> In #gentoo we give a lot of attention and support to people who want to
> set up full disk encryption, tor, VPNs, and other security mechanisms,
> and this tells me that they actually want security. By saying that "some
On 12/27/2017 10:42 AM, Mart Raudsepp wrote:
> If you want to make such a base profile change, then I believe you
> should contact the maintainers and see which one wants it default
> disabled, and which default enabled; do the default enabled changes
> and only afterwards you can touch a base defa
We now have IUSE="+cracklib" in sys-apps/shadow, sys-auth/pambase, and
sys-libs/pam (thanks robbat2).
Does that address everyone's concerns?
Enough so that I can revert the revert without anyone reverting the
revert revert?
On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
> use_if_iuse !nopie && return 0
Does this work? The "use" function supports negation (undocumented, but
it's in the PMS), but I don't think use_if_iuse does.
On 12/26/2017 07:35 PM, Michael Orlitzky wrote:
> The "session" USE flag has been enabled by default for all linux
> profiles in default/linux/make.defaults since 2010...
I haven't received any feedback at all on this, and no one is claiming
that the flag is important, so
On 01/09/2018 07:07 PM, William Hubbs wrote
>
> However, I'm not sure how to deal with the hard link issue in a way that
> will not break service scripts.
>
Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by
default, but they have the liberty of requiring a relatively new Li
On 01/09/2018 07:37 PM, Philip Webb wrote:
>
> I'm very sorry that Council approved this proposal
> & hope that it will soon see sense & rescind it.
In an effort to reduce noise on the gentoo-dev mailing list, Gentoo will
now require every user to send an email to the gentoo-dev mailing list
aski
On 01/10/2018 01:04 PM, William Hubbs wrote:
> On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote:
>
>> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory
>> that is not writable only by yourself and root.
>
> Let me try to phrase
On 01/10/2018 05:18 PM, James Le Cuirot wrote:
>
> The init script used to call chown/chmod -R, which is
> obviously bad. I've compromised by only calling these on the
> directories themselves (ignoring symlinks). I believe this is safe
> because it's not possible to create hard linked directories
On 01/10/2018 01:17 PM, Kristian Fiskerstrand wrote:
>>
>> (I didn't realize at the time that the OpenRC fix still contained a race
>> condition.)
>
> This was mentioned already in https://bugs.gentoo.org/540006#c15
>
So it is =)
I took the RESOLVED FIXED for granted when I reported the tmpfile
On 01/10/2018 04:54 PM, William Hubbs wrote:
>
> What are we saying newpath should do differently than checkpath if I
> go this route?
I think this covers everything that we've talked about:
1. It should refuse to modify existing paths.
1.a. If newpath is called on an existing path, and if
The "modules" USE flag was originally enabled by default in the base
profile so that any ebuild inheriting linux-mod.eclass would have its
kernel modules built by default. However, the name of that USE flag is
now controlled by the MODULES_OPTIONAL_USE variable, set in the ebuild
itself. The best p
On 01/14/2018 06:53 PM, Robin H. Johnson wrote:
> +# @ECLASS-VARIABLE: MODULES_OPTIONAL_USE_IUSE_DEFAULT
> +# @DESCRIPTION:
> +# A boolean to control the IUSE default state for the MODULES_OPTIONAL_USE
> USE
> +# flag. Default value is unset (false). True represented by 1 or 'on', other
> +# value
On 01/17/2018 10:21 AM, William Hubbs wrote:
>
> For both A and B above I think you mean owner/group/permissions right?
Yep.
>> 2. It should have a flag (say, --as=[:group]) to make it run as
>> an unprivileged user. Basically a portable "su -c".
>
> I'm not following why I need this.
>
On 01/17/2018 12:14 PM, William Hubbs wrote:
>>
>> 1. I could create /run/foo with owner "foo", and then create
>>/run/foo/bar with owner "foo". That can be done without modifying
>>existing permissions, but it's not safe, because you wind up working
>>as root in the directory /run/foo
On 01/19/2018 07:16 PM, William Hubbs wrote:
>
> It looks like we can't use your --as suggestion if we want to be
> able to create paths in /var/lib and /var/spool that are owned by
> non-privileged users because of the permissions on those paths. It is
> possible that service scripts are doing th
On 01/19/2018 08:14 PM, William Hubbs wrote:
>>
>> Why not? Since /var/lib is root:root and mode 755, we can create
>> /var/lib/foo while running --as=root (the default). Then afterwards,
>> anything beneath /var/lib/foo would need to be created "--as" the owner
>> of that directory.
>
> That woul
On 01/21/2018 11:24 PM, Zac Medico wrote:
>
> Some eclasses like autotools.eclass and vala.eclass generate
> version/slot locked dependencies that cause the dependencies of
> inheriting ebuilds to change when the versions in the eclasses are
> updated. If possible, it would be nice to avoid this v
On 01/22/2018 05:10 AM, Duncan wrote:
>>>
>>> If the dependencies are to remain in the eclasses, then the eclasses
>>> should get a new revision when those dependencies change. Afterwards,
>>> the consumers can be revbumped and stabilized normally to utilize the
>>> new eclass.
>>
>> Sounds good!
>
On 01/22/2018 11:37 AM, Mike Gilbert wrote:
>>
>> If the dependencies are to remain in the eclasses, then the eclasses
>> should get a new revision when those dependencies change. Afterwards,
>> the consumers can be revbumped and stabilized normally to utilize the
>> new eclass.
>
> While that sou
On 01/23/2018 07:40 AM, Michael Palimaka wrote:
>>
>> Did you come up with a solution how to handle eclass-generated dependency
>> changes then?
>
> No.
>
> Bug #641346 was filed for clarification about this, but it just got
> closed without answering the question or consulting anyone.
>
> Now,
On 01/26/2018 06:24 PM, Michał Górny wrote:
>
> The alternate option of using file hash has the advantage of having
> a more balanced split. Furthermore, since hashes are stored
> in Manifests using them is zero-cost. However, this solution has two
> significant disadvantages:
>
> 1. The hash v
On 01/27/2018 11:09 AM, Sebastian Pipping wrote:
> Hi!
>
>
> I noticed that we have 7 packages on Fedora wallpapers with names that
> only explain themselves to Fedora insiders:
>
> ...
>
> I was thinking that we could merge these packages into a new package
> "x11-themes/fedora-backgrounds" or
On 01/27/2018 03:30 AM, Michał Górny wrote:
>>
>> What are we worried about in using a temporary directory? Copying across
>> filesystem boundaries? Except in rare cases, $DISTDIR itself will be
>> usable a temporary location (on the same filesystem), won't it?
>
> Why add the extra complexity whe
On 01/27/2018 11:42 AM, Gordon Pettey wrote:
> Why not use a hash of the file name instead of its contents? That
> seems like it would be much simpler, and that's not going to reduce
> the output space for balance...
That's the proposal =P
On 01/27/2018 01:14 PM, Michał Górny wrote:
>>
>> If we have a tool like edistadd, then I see the problem. But if we were
>> going to use file-data based hashes, then there would be no need for a
>> tool in most cases. As a developer, "repoman manifest" would handle it.
>> As a user, I'm going to s
On 01/27/2018 02:01 PM, Gordon Pettey wrote:
> On Sat, Jan 27, 2018 at 10:48 AM, Michael Orlitzky wrote:
>> On 01/27/2018 11:42 AM, Gordon Pettey wrote:
>>> Why not use a hash of the file name instead of its contents?...
>>
>> That's the proposal =P
>
>
On 01/27/2018 02:47 PM, Michał Górny wrote:
>> *
>> * Please download fileN from
>> * wherever fileN can be found
>> * and move it to $DISTDIR/subdirN
>
> Do you really believe this to be more friendly than a helper that places
> all the files in correct directories?
Well, it's no worse than
On 02/08/2018 05:13 PM, William Hubbs wrote:
>
> There are no reasons to remove the *sbin directories from PATH; I know
> of no other distros that do this.
The first reason that comes to mind is that when I type something like
p to remind me of a command name, I don't need to see 50 programs
that
On 02/08/2018 05:33 PM, Rich Freeman wrote:
>
> There are actually quite a few binaries in /sbin and /usr/sbin which
> can be useful for non-root users. Sure, we could go through there
> carefully and move stuff to /bin but honestly doing what everybody
> else does and just sticking /sbin in the
On 02/08/2018 06:12 PM, William Hubbs wrote:
>
> There is no bug here. The problem, as I said before in this thread, is
> that what goes in *sbin is arbitrary, and as Rich said, if you are
> relying on the path to prevent a non-root user from running something
> that only root should run, you are
On 02/09/2018 05:47 PM, Matt Turner wrote:
>
> Wait, since it was just in DEPEND, I don't understand the problem.
>
> If it were in RDEPEND, I could understand. But in DEPEND, it'll get
> depcleaned without any problem as far as I can tell.
>
After being subjected to a totally incomprehensible
On 02/16/2018 03:46 AM, Ulrich Mueller wrote:
>
> Should we take this as an opportunity to split off these three
> functions into their own eclass, e.g. vcs-clean.eclass?
I think this is a good direction to go in. Changing a popular eclass is
always scary, and the more unrelated stuff it contains,
On 03/06/2018 12:25 PM, Michał Górny wrote:
> ---
> eclass/eapi7-ver.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/eapi7-ver.eclass b/eclass/eapi7-ver.eclass
> index 7eb070c68171..6117124a90a5 100644
> --- a/eclass/eapi7-ver.eclass
> +++ b/eclass/eapi7-ver
101 - 200 of 919 matches
Mail list logo
