On 16/01/19 12:59, Joakim Tjernlund wrote:
> On Wed, 2019-01-16 at 12:20 +0000, M. J. Everitt wrote:
>> On 16/01/19 11:58, Joakim Tjernlund wrote:
>>> How come portage isn't in shadow, only in passwd ?
>>> Seems wrong to me.
>>>
>>> Jocke
>>
On 16/01/19 11:58, Joakim Tjernlund wrote:
> How come portage isn't in shadow, only in passwd ?
> Seems wrong to me.
>
> Jocke
Because the portage user never logs on .. hence has no password. That said,
it does seem an odd situation, since even users with no password do tend to
appear in /etc/shad
On 08/01/19 19:15, Zac Medico wrote:
> On 1/8/19 5:42 AM, Fabian Groffen wrote:
>> The reporting of files remaining can look somewhat odd since the report
>> interval is hardcoded to be per 1000 objects. Adjust this interval to
>> be time based. This means that modern (fast) machines likely will
On 30/12/18 19:58, Pratyush Das wrote:
> Hi,
>
> In reference to this forum post
> - https://forums.gentoo.org/viewtopic-t-1091144-highlight-.html , I was
> told that several users found wrong information in the portage error logs
> pointing them to the wrong directory for distfiles to be downloade
On 17/12/18 15:51, Michał Górny wrote:
> On Mon, 2018-12-17 at 15:44 +0000, M. J. Everitt wrote:
>> On 17/12/18 12:54, Michał Górny wrote:
>>>> Not only this, but as noted, unless you know the man pages for portage and
>>>> make.conf in order to recite them in y
On 17/12/18 15:44, M. J. Everitt wrote:
> On 17/12/18 12:54, Michał Górny wrote:
>>> Not only this, but as noted, unless you know the man pages for portage and
>>> make.conf in order to recite them in your sleep, they are confusing for
>>> users, as they do not
On 17/12/18 12:54, Michał Górny wrote:
>> Not only this, but as noted, unless you know the man pages for portage and
>> make.conf in order to recite them in your sleep, they are confusing for
>> users, as they do not necessarily follow an obvious pattern, and it wasn't
>> until I was attempting to
On 15/12/18 08:55, Michał Górny wrote:
> On Sat, 2018-12-15 at 02:25 +0000, M. J. Everitt wrote:
>> This patchset aims to fix potential ambiguity and confusion between older
>> PORT_LOG* variables,
>> and more recent PORTAGE_* variables - often leading to mysteriously lacki
Suggested-by: Michael Everitt
Bug: https://bugs.gentoo.org/668538
---
NEWS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/NEWS b/NEWS
index b430f273f..e65205c42 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,11 @@
News (mainly features/major bug fixes)
+portage-next
+--
+* Rena
Suggested-by: Michael Everitt
Bug: https://bugs.gentoo.org/668538
---
man/make.conf.5 | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/man/make.conf.5 b/man/make.conf.5
index a0faf51bf..a8f5b639f 100644
--- a/man/make.conf.5
+++ b/man/make.conf.5
To match similar existing PORTAGE_* variables
Suggested-by: Zac Medico
Acked-by: Michael Everitt
Bug: https://bugs.gentoo.org/668538
---
NEWS | 2 +-
cnf/make.conf.example | 12 +-
cnf/make.globals
Suggested-by: Zac Medico
Acked-by: Michael Everitt
Bug: https://bugs.gentoo.org/668538
---
lib/portage/package/ebuild/config.py | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/portage/package/ebuild/config.py
b/lib/portage/package/ebuild/config.py
index a68df5807..5c1404389
!
M. J. Everitt (4):
Renamed PORT_LOGDIR[_CLEAN] to PORTAGE_LOGDIR[_CLEAN]
Provide compatibility support for old PORT_LOGDIR* variable names
Update documentation for PORT_LOGDIR* changes
Add note to NEWS/ChangeLog for PORT_LOGDIR* changes
NEWS
On 18/11/18 09:18, Michał Górny wrote:
> On Sun, 2018-11-18 at 09:04 +0000, M. J. Everitt wrote:
>> On 18/11/18 08:53, Michał Górny wrote:
>>> Signed-off-by: Michał Górny
>>> ---
>>> bin/pid-ns-init| 25 +
>>> lib/por
On 18/11/18 08:53, Michał Górny wrote:
> Signed-off-by: Michał Górny
> ---
> bin/pid-ns-init| 25 +
> lib/portage/process.py | 11 ++-
> 2 files changed, 31 insertions(+), 5 deletions(-)
> create mode 100644 bin/pid-ns-init
>
> diff --git a/bin/pid-ns-init
On 11/11/18 19:20, Rich Freeman wrote:
> On Sun, Nov 11, 2018 at 1:02 PM M. J. Everitt wrote:
>> If you can really present a decent argument for replicating the
>> functionality of other distros like Debian, Arch, Ubuntu etc then let's
>> here it. For now, the strength
On 11/11/18 18:41, Rich Freeman wrote:
> On Sun, Nov 11, 2018 at 12:31 PM M. J. Everitt wrote:
>> Binpkgs are also a popular component of a few downstream distro's based on
>> Gentoo (thinking pentoo right now as an easy example).
>>
>> So we don't want t
On 11/11/18 18:15, Duncan wrote [excerpted]:
> Is there any interest at all in binpkgs, perhaps when improved, from the
> other PMs? Or are they effectively dead now or not interested in binpkgs
> even if the format were to be improved, or simply too hard to work with?
> Because "it'd be nice"
On 10/08/18 00:17, M. J. Everitt wrote:
> On 10/08/18 00:04, Zac Medico wrote:
>> For USERLAND=BSD, set XARGS="gxargs -r" if gxargs is available,
>> so the code from bug 630292 works for USERLAND=BSD.
>>
>> Fixes: 50283f1abb77 (install-qa-check.d/60png
On 10/08/18 00:04, Zac Medico wrote:
> For USERLAND=BSD, set XARGS="gxargs -r" if gxargs is available,
> so the code from bug 630292 works for USERLAND=BSD.
>
> Fixes: 50283f1abb77 (install-qa-check.d/60pngfix: parallel support (bug
> 630292))
> Reported-by: Michał Górny
> Bug: https://bugs.gento
On 07/08/18 17:46, Michael Orlitzky wrote:
> Changes in v3:
>
> * Undo the setguid exception from v2, and add a comment explaining why.
> * Add line breaks for readability in two comments.
> * Try to put back the leading "/" in the output list.
> * Remove a superfluous comment mentioning th
On 06/08/18 19:35, Zac Medico wrote:
> On 08/06/2018 12:30 AM, Brian Dolbec wrote:
>> All these changes as well as the catlayst changes need to be
>> co-ordinated so that snapshots and portage and stages don't precede the
>> docs changes.
> I suppose all of the docs changes can be made in advance,
On 04/05/18 06:22, Zac Medico wrote:
> When autounmask USE changes violate REQUIRED_USE, rather than
> recalculate with autounmask disabled, display the autounmask USE
> changes along with the REQUIRED_USE violation. Adjust unit tests
> to allow for the autounmask USE changes that were previously
>
On 21/03/18 23:26, M. J. Everitt wrote:
> n 20/03/18 04:49, Manuel Rüger wrote:
>> Hi Zac,
>>
>> alternatively could --exclude be extended to support sets?
>> So users could --exclude @world or @profile.
>>
>> Cheers,
>> Manuel
>>
> The id
n 20/03/18 04:49, Manuel Rüger wrote:
> Hi Zac,
>
> alternatively could --exclude be extended to support sets?
> So users could --exclude @world or @profile.
>
> Cheers,
> Manuel
>
The idea is sound enough, but I fear the syntax would be too confusing.
Reading a potential command-line as "emerge
On 18/02/18 21:27, Zac Medico wrote:
> Since search strings containing a slash do no work unless category
> match mode is enabled, use slash to auto-detect category match mode,
> so that users do not have to prefix the search string with the special
> @ symbol.
>
> Bug: https://bugs.gentoo.org/6479
On 18/02/18 16:28, Brian Dolbec wrote:
> On Sat, 17 Feb 2018 13:18:03 +
> "M. J. Everitt" wrote:
>
>> Might I suggest breaking out checks into a separate module? I think
>> that hard-coding it all is likely to become a pain as time goes on,
>> more ch
On 17/02/18 12:56, Michał Górny wrote:
> Add a check for common mistakes in commit messages. For now, it is
> pretty rough and works only for -m/-F. It will be extended to work
> in the interactive mode in the future.
> ---
> repoman/pym/repoman/actions.py | 74
>
On 02/02/18 20:42, Michał Górny wrote[excerpted]:
> index 27a2548c0..cb80f6d66 100644
> --- a/pym/portage/sync/modules/rsync/__init__.py
> +++ b/pym/portage/sync/modules/rsync/__init__.py
> @@ -109,6 +110,20 @@ class RsyncSync(NewBase):
> writemsg_level("!!! sync-rsync
On 14/08/17 08:39, Zac Medico wrote:
> From: Hidehiko Abe
>
> doins is written in bash. However, specifically in case that
> too many files are installed, it is very slow.
> This CL rewrites the script in python for performance.
>
> BUG=chromium:712659
> TEST=time (./setup_board --forace && \
>
On 14/08/17 02:55, Duncan wrote:
> M. J. Everitt posted on Mon, 14 Aug 2017 00:37:45 +0100 as excerpted:
>
>> My use-case consists of the scenario where I do not *ever* wish Portage
>> to modify my /etc/portage/package. files, preferring to do
>> this myself manually with
On 14/08/17 01:19, Zac Medico wrote [excerpted]:
> You'll get the same result as --autounmask-use-only if you use
> --autounmask-keep-keywords together with --autounmask-keep-masks.
>
> This way, we can also add --autounmask-keep-license and
> --autounmask-keep-use options if we want, and the meani
On 12/08/17 19:08, Zac Medico wrote:
> The option prevents --autounmask from making changes to
> package.accept_keywords. This option does not imply
> --autounmask-keep-masks, so --autounmask is still allowed
> to create package.unmask changes unless the
> --autounmask-keep-masks is also specified.
33 matches
Mail list logo
