> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
> install-qa-check.d: allow acct-user home directories under /home.
Nope. As you've been told, /home is site specific and can be setup in
multiple ways that are incompatible with the package manager installing
things there (the only exception
On Sun, 2020-01-19 at 22:43 -0500, Michael Orlitzky wrote:
> In rare cases, a system user will need a real home directory to store
> per-user configuration data and/or be accessed interactively by a
> human being. In those cases, /home/${username} is an appropriate place
> for the user's home
On Sun, 2020-01-19 at 22:43 -0500, Michael Orlitzky wrote:
> These exceptions were made for the sys-apps/nix and sys-apps/guix
> packages that are no longer in the tree.
> ---
> metadata/install-qa-check.d/08gentoo-paths | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
On 1/19/20 10:40 PM, Rich Freeman wrote:
> On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote:
>>
>> This is retarded, stop wasting my time.
>>
>
> There is nothing retarded about shared /home directories. They're
> pretty common in the real world.
>
What's retarded is copy/pasting words
These exceptions were made for the sys-apps/nix and sys-apps/guix
packages that are no longer in the tree.
---
metadata/install-qa-check.d/08gentoo-paths | 2 --
1 file changed, 2 deletions(-)
diff --git a/metadata/install-qa-check.d/08gentoo-paths
b/metadata/install-qa-check.d/08gentoo-paths
In rare cases, a system user will need a real home directory to store
per-user configuration data and/or be accessed interactively by a
human being. In those cases, /home/${username} is an appropriate place
for the user's home directory. Using /home is allowed and encouraged
by the FHS, and there
It's late and I'm sure this is buggy, but just complaining about it
isn't getting me anywhere.
Michael Orlitzky (2):
install-qa-check.d: disallow "nix" and "gnu" as top-level paths.
install-qa-check.d: allow acct-user home directories under /home.
metadata/install-qa-check.d/08gentoo-paths
On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote:
>
> This is retarded, stop wasting my time.
>
There is nothing retarded about shared /home directories. They're
pretty common in the real world.
> >> I've already got responses from two QA members. This thread is pretty
> >> hard to
On 1/19/20 9:52 PM, Rich Freeman wrote:
>>
>> Fantasy scenarios again. I'm not going to debunk a system that you just
>> thought up and that has never existed. Why don't you find one person who
>> actually does this, and see if it bothers him if we create a home
>> directory under /home where it
On Sun, Jan 19, 2020 at 8:51 PM Michael Orlitzky wrote:
>
> On 1/19/20 8:20 PM, Rich Freeman wrote:
> > It would be far simpler for the sysadmin to simply ensure that no
> > unsynced user owns a file or appears in an ACL. That would be pretty
> > trivial to achieve. Whatever is hosting /home
On 1/19/20 8:20 PM, Rich Freeman wrote:
> It would be far simpler for the sysadmin to simply ensure that no
> unsynced user owns a file or appears in an ACL. That would be pretty
> trivial to achieve. Whatever is hosting /home could be designed to
> block such changes, or you could just scan for
On Sun, Jan 19, 2020 at 4:00 PM Michael Orlitzky wrote:
>
> On 1/19/20 2:47 PM, Rich Freeman wrote:
> >
> > Obviously the UIDs associated with the shared /home need to be
> > identical. Simplest solution is to sync anything > 1000 in
> > /etc/passwd, and then not allow UIDs below 1000 in /home.
20200117-05:43 mgorny
810e8db30e0
dev-libs/boxfort 20200110-11:15 juippis
a72bee57426
dev-libs/kpeoplevcard 20200119-16:40 asturm
fdfc1b0dff2
dev-python/casttube
> What is happening?
gcc-10 is coming soon. It will be more disruptive than gcc-9.
One of the major changes is the switch from C{,XX}FLAGS=-fcommon
to C{,XX}FLAGS=-fno-common by default: https://gcc.gnu.org/PR85678
It's a planned change and not a gcc regression. It will expose some
warts on old
# Andreas Sturmlechner (2020-01-19)
# Ancient, last release in 2006, blocks x11-libs/gtkglext cleanup
# Masked for removal in 30 days.
media-sound/glmix
signature.asc
Description: This is a digitally signed message part.
On 1/19/20 4:00 PM, Michael Orlitzky wrote:
>
> If I was willing to introduce a QA warning, this thread would have been
> a lot shorter =P
>
Just kidding, the eclass is rigged to die in src_install if you delete
the home directory, and if you wait until pkg_preinst, the warning gets
shown
On Sun, Jan 19, 2020 at 12:31:52PM +0100, Michał Górny wrote:
> Hello,
>
> In the light of the recent misunderstandings, I have started working
> on an official Policy Guide [1]. The Guide is meant to provide
> a focused list of officially approved QA policies, along with their
> rationale and
On 1/19/20 2:47 PM, Rich Freeman wrote:
>
> Obviously the UIDs associated with the shared /home need to be
> identical. Simplest solution is to sync anything > 1000 in
> /etc/passwd, and then not allow UIDs below 1000 in /home. A cron job
> could easily handle both, and of course regular users
On 1/19/20 2:32 PM, Alec Warner wrote:
>
> Earlier you wrote:
>
> * The daemon DOES NOT need a home directory for its user.
> * I DO NOT want to install anything to anyone's home directory.
> * With respect to user.eclass, I'm proposing that /home be treated
> EXACTLY THE SAME as it
onal preference would be the ID variant, after seeing Rubocop
> have to rename identifying slugs slowly & painfully over many years;
> however the slug variant is MUCH better for usability
>
> 2. Usability/viewing:
> 2.1. DT-squashed:
> Please fix the CSS rendering of the . My ch
On Sun, 2020-01-19 at 19:44 +0100, Haelwenn (lanodan) Monnier wrote:
> Thanks a lot for this policy guide, finally there is a good documentation
> on them.
>
> I found one issue with it though, on pages like other-metadata.html and
> keywords.html the links are too large and squish the dt
On Sun, Jan 19, 2020 at 2:27 PM Michael Orlitzky wrote:
>
> On 1/19/20 2:02 PM, Rich Freeman wrote:
> >
> >> If you're sharing /home, you also have to be sharing user accounts,
> >> unless you want everyone to be assigned a random set of files.
> >
> > I imagine that most people setting up
On Sun, Jan 19, 2020 at 2:32 PM Kent Fredric wrote:
>
> Having a discussion at a bar, and you making a commit as a result is
> one thing, but if I discovered a bug, and then only told you about it
> at the bar, that would be possibly bad, because there's no guarantee
> that the bug is
On 1/19/20 11:33 AM, Ulrich Mueller wrote:
>> On Sun, 19 Jan 2020, Zac Medico wrote:
>
>> --- a/bin/ebuild-helpers/dosym
>> +++ b/bin/ebuild-helpers/dosym
>> @@ -21,14 +21,6 @@ fi
>> destdir=${2%/*}
>> [[ ! -d ${ED%/}/${destdir#/} ]] && dodir "${destdir}"
>> target="${1}"
>> -# DEPRECATED
n anchor, and it makes them immediately
useful for seeing the policy in question without having to resort to
searching.
> 2. Usability/viewing:
> 2.1. DT-squashed:
> Please fix the CSS rendering of the . My chrome window is 1198 x
> 1870 (screen is portrait version 1920x1200).
> Scre
On Sun, Jan 19, 2020 at 10:49:10AM -0500, Michael Orlitzky wrote:
> > That bug appears to be restricted. Perhaps it is embargoed? If not,
> > then it probably shouldn't be restricted, especially if already fixed
> > and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that
> > this has
Usability/viewing:
2.1. DT-squashed:
Please fix the CSS rendering of the . My chrome window is 1198 x
1870 (screen is portrait version 1920x1200).
Screenshot:
https://dev.gentoo.org/~robbat2/.private/20200119-policy-guide-render-window.png
2.2. Whitespace:
The left column has a LOT of wasted white
> On Sun, 19 Jan 2020, Zac Medico wrote:
> --- a/bin/ebuild-helpers/dosym
> +++ b/bin/ebuild-helpers/dosym
> @@ -21,14 +21,6 @@ fi
> destdir=${2%/*}
> [[ ! -d ${ED%/}/${destdir#/} ]] && dodir "${destdir}"
> target="${1}"
> -# DEPRECATED HACK: when absolute, prefix with offset for Gentoo
On Sun, Jan 19, 2020 at 11:28 AM Michael Orlitzky wrote:
> On 1/19/20 2:19 PM, Alec Warner wrote:
> >
> > All I want to do is *set* a user's home directory to /home/foo.
> >
> > Why wouldn't you set the homedirectory to /dev/null then?
> >
>
> Because /dev/null is not /home/foo? Is this a
On Sun, 19 Jan 2020 13:54:33 -0500
Rich Freeman wrote:
> Nothing of importance should be stored on github.
>
> If you and I have a conversation at a bar, and as a result you decide
> to make a commit without any useful comments, and then we both retire
> from the project, just as much
On 1/19/20 2:19 PM, Alec Warner wrote:
>
> All I want to do is *set* a user's home directory to /home/foo.
>
> Why wouldn't you set the homedirectory to /dev/null then?
>
Because /dev/null is not /home/foo? Is this a trick question? =)
On 1/19/20 2:02 PM, Rich Freeman wrote:
>
>> If you're sharing /home, you also have to be sharing user accounts,
>> unless you want everyone to be assigned a random set of files.
>
> I imagine that most people setting up something like this would only
> be sharing high-value UIDs (>1000 in our
On Sun, 2020-01-19 at 19:44 +0100, Haelwenn (lanodan) Monnier wrote:
> Thanks a lot for this policy guide, finally there is a good documentation
> on them.
>
> I found one issue with it though, on pages like other-metadata.html and
> keywords.html the links are too large and squish the dt
On Sat, Jan 18, 2020 at 6:50 PM Michael Orlitzky wrote:
> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote:
> >>
> >> But now users have to follow one more step (create /home/amavis) when
> >> setting up amavisd-new. Is the QA check really
On Sun, Jan 19, 2020 at 1:37 PM Michael Orlitzky wrote:
>
> On 1/19/20 12:42 PM, Rich Freeman wrote:
> >
> > Typically you wouldn't share service accounts across multiple hosts.
> > I'd think that something like amavisd is going to go on a mail server.
> > You're not going to be logging into that
On Sun, Jan 19, 2020 at 1:45 PM Kent Fredric wrote:
>
> On Sun, 19 Jan 2020 07:08:30 -0500
> Rich Freeman wrote:
>
> > The official sources aren't in github. A bugzilla component is
> > available, so if github goes away there is no problem and we aren't
> > relying on it.
>
> If github goes
According to PMS, dosym callers need to explicitly prefix the first
argument with ${EPREFIX} if that's desired.
https://bugs.gentoo.org/615594
Signed-off-by: Zac Medico
---
bin/ebuild-helpers/dosym | 8
1 file changed, 8 deletions(-)
diff --git a/bin/ebuild-helpers/dosym
On Sun, 19 Jan 2020 12:31:52 +0100
Michał Górny wrote:
> Enjoy!
Many thanks for making this happen.
pgpkU6bOR1NU6.pgp
Description: OpenPGP digital signature
On Sun, 19 Jan 2020 07:08:30 -0500
Rich Freeman wrote:
> The official sources aren't in github. A bugzilla component is
> available, so if github goes away there is no problem and we aren't
> relying on it.
If github goes away after bugs and PR's are filed on github, then that
historical
Thanks a lot for this policy guide, finally there is a good documentation
on them.
I found one issue with it though, on pages like other-metadata.html and
keywords.html the links are too large and squish the dt elements, one way
I found to fix it is by adding `word-break: break-all` to
On 1/19/20 12:42 PM, Rich Freeman wrote:
>
> Typically you wouldn't share service accounts across multiple hosts.
> I'd think that something like amavisd is going to go on a mail server.
> You're not going to be logging into that account to do typical
> desktop-oriented functions.
>
> If you had
On Sun, 2020-01-19 at 18:50 +0100, Thomas Deutschmann wrote:
> On 2020-01-19 12:46, Ulrich Mueller wrote:
> > > > > > > On Sun, 19 Jan 2020, Michał Górny wrote:
> > > The sources are stored in proj/policy-guide.git [3]. If you wish to
> > > submit your own changes, you can either use the 'Policy
On 2020-01-19 12:46, Ulrich Mueller wrote:
>> On Sun, 19 Jan 2020, Michał Górny wrote:
>
>> The sources are stored in proj/policy-guide.git [3]. If you wish to
>> submit your own changes, you can either use the 'Policy Guide' bugzilla
>> component [4] and/or GitHub mirror [5].
>
> Please,
On Sun, Jan 19, 2020 at 10:49 AM Michael Orlitzky wrote:
>
> On 1/19/20 6:29 AM, Rich Freeman wrote:
> >
> > Daemons are local users. There is no guarantee that /home is a local
> > filesystem. Heck, there is no guarantee that /home is even mounted
> > when portage is running. Portage
On 1/19/20 6:29 AM, Rich Freeman wrote:
>
> Daemons are local users. There is no guarantee that /home is a local
> filesystem. Heck, there is no guarantee that /home is even mounted
> when portage is running. Portage shouldn't be touching /home at all.
> With stuff like automounted or
On Sun, Jan 19, 2020 at 6:46 AM Ulrich Mueller wrote:
>
> > On Sun, 19 Jan 2020, Michał Górny wrote:
>
> > The sources are stored in proj/policy-guide.git [3]. If you wish to
> > submit your own changes, you can either use the 'Policy Guide' bugzilla
> > component [4] and/or GitHub mirror
> On Sun, 19 Jan 2020, Michał Górny wrote:
> The sources are stored in proj/policy-guide.git [3]. If you wish to
> submit your own changes, you can either use the 'Policy Guide' bugzilla
> component [4] and/or GitHub mirror [5].
Please, no github for official policies. We should have a
Hello,
In the light of the recent misunderstandings, I have started working
on an official Policy Guide [1]. The Guide is meant to provide
a focused list of officially approved QA policies, along with their
rationale and any other useful information.
This should supplement devmanual [2] with
On Sat, Jan 18, 2020 at 9:50 PM Michael Orlitzky wrote:
>
> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote:
> >>
> >> But now users have to follow one more step (create /home/amavis) when
> >> setting up amavisd-new. Is the QA check really
49 matches
Mail list logo
