On 8/17/19 12:29 AM, Haelwenn (lanodan) Monnier wrote:
>
> Any reason why sharing home directories isn't simply forbidden?
> This is sure to blow on us at some point if there is shared home directories.
>
> ...
>
> Shouldn't this be owned instead of writable? I'm pretty sure we can
> have
On 8/17/19 2:36 AM, Eray Aslan wrote:
>
> For the record, it wasnt me who wrote those acct-user ebuilds.
Apologies, I checked the metadata and assumed that I missed these as
part of your patch series. In any case, I'm not trying to throw blame
around -- this is all new and we're still figuring
On 8/17/19 4:54 AM, Michał Górny wrote:
> On Sat, 2019-08-17 at 10:52 +0200, Ulrich Mueller wrote:
>>
>> Shouldn't there be a blocker against dev-vcs/gitolite{,-gentoo}
>> (and vice versa)? These packages cannot be installed at the same time,
>> and I guess that a direct blocker would result in a
Pending https://github.com/gentoo/devmanual.gentoo.org/pull/99, I'd like
to get something like this written down.
Please give it a quick read and see if it makes sense, or if I've
overlooked anything. Most of these would just be suggestions, to be
implemented as post-install QA checks or repoman
> On 8/3/19 7:49 PM, Michael Orlitzky wrote:
>>
>> That makes me think that we should set
>>
>> ACCT_USER_HOME=/var/lib/amavis
>
> We'll do this during the next version/revision bump, keeping everything
> else the same.
>
The recent homedir problem
On 8/15/19 11:43 AM, Mike Gilbert wrote:
>
> + # Path might be missing due to INSTALL_MASK, etc.
> + # https://bugs.gentoo.org/691478
> + if [[ ! -e "${ED}/${ACCT_USER_HOME#/}" ]]; then
> + eerror "Home directory is missing from the
On 8/7/19 5:24 AM, Eray Aslan wrote:
> I would like to reserve UID/GID 76 for dovecot (net-mail/dovecot)
>
> This id differs from what we have provided historically (97) but gid/97
> is used by acct-group/input. So use 76 instead.
>
> This id is the same in Arch (76) but differs from Redhat
On 8/15/19 3:19 AM, Ulrich Mueller wrote:
>
> I don't think that's a sane situation, so maybe the eclass should just
> die here? (Basically, there are two possibilities: Either, things will
> break if the dir is missing, then dying might be the best option.
> Or, everything works without the dir,
On 8/14/19 5:41 PM, Mike Gilbert wrote:
>
> (If the "man" user really reads things from e.g. $HOME/man5/ebuild.5,
> I'll eat my foot.)
>
>
> Agreed. Please file a bug about this.
>
We already have bug 691478 for this issue? Only it should have been
assigned to the failing package's
On 8/14/19 5:14 PM, Mike Gilbert wrote:
> Closes: https://bugs.gentoo.org/691478
> Signed-off-by: Mike Gilbert
> ---
> eclass/acct-user.eclass | 5 +
This is a symptom of another problem. The man user claims /usr/share/man
as its home directory, and insists on changing its permissions to
On 8/13/19 10:30 AM, Pierre-Olivier Mercier wrote:
>
> Pending PR: https://github.com/gentoo/gentoo/pull/12481
>
>
> DESCRIPTION="User for knot DNS server"
> ACCT_USER_ID=53
> ACCT_USER_HOME=/var/lib/knot
> ACCT_USER_HOME_OWNER=knot:knot
> ACCT_USER_GROUPS=( knot )
> ACCT_USER_SHELL=/bin/false
On 8/13/19 3:15 PM, Lars Wendler wrote:
>
> I'm not really sure what the impact might be. I have only one single
> apache installation and that is a productive one. I do not want to mess
> with that installation.
>
I'm not trying to hassle you, but now's the time to get it right. The
old
On 8/13/19 2:30 PM, Lars Wendler wrote:
>
> If we leave ACCT_USER_HOME empty HOME will be set to
> /dev/null for apache user. I don't know if this is what we want.
I'm not 100% sure either, but it's pretty likely that if an unwritable
root-owned home directory would work, then so would /dev/null.
On 8/13/19 1:53 PM, Lars Wendler wrote:
>
> thanks for the review. I've force-pushed the acct-user/apache commit
> with ACCT_USER_HOME_OWNER being set to root:root.
>
Is there any benefit to
ACCT_USER_HOME=/var/www
ACCT_USER_HOME_OWNER=root:root
versus
keepdir /var/www
in the eclass?
On 8/13/19 1:14 PM, Lars Wendler wrote:
> I would like to reserve UID/GID 81 for apache (www-servers/apache).
>
> This is the historical UID/GID for apache user in Gentoo.
> Fedora and RedHat use UID/GID 48. Arch Linux has no
> "apache" user but a "http" user with UID/GID 33 (which is already
>
On 8/12/19 6:28 PM, Ulrich Mueller wrote:
>
> I didn't understand that argument in 2011, and I understand it even
> less in 2019. Why would we add xz but not bzip2 and tar as dependencies?
>
> The devmanual is clear on this:
>
On 8/9/19 3:26 PM, Rolf Eike Beer wrote:
>
> + use ssl && epatch "${FILESDIR}"/qmail-smtputf8.patch
EAI doesn't require SSL as far as I know. Is this conditional on the USE
flag only because the patch won't apply otherwise? (If so, it may be
worth a comment to that effect.)
On 8/10/19 4:27 AM, Alexey I. Korepanov wrote:
> The process runs as i2pd:i2pd. The group is not used for anything specific.
I think I confused myself. The user does need a primary group, in any
case. Everything's fine, carry on.
On 8/9/19 6:42 PM, Alexey I. Korepanov wrote:
> I wanted also to remove write access for i2pd group for config files in
> /etc, thus extra removal. I wrote about it in the pr.
>
Ah, sorry, I only read the commit and not the PR conversation. Is the
group still used for anything?
On 8/9/19 5:59 PM, Alexey I. Korepanov wrote:
> Hi!
>
> I need a UID/GID for i2pd. I used 170 in
> https://github.com/gentoo/gentoo/pull/12509
> I did not find any conflict.
>
>
You deleted your entire pkg_preinst phase, but you probably only wanted
to delete the enewuser and enewgroup calls.
On 8/8/19 3:37 AM, Tomas Mozes wrote:
>
> Pending PR:
> https://github.com/gentoo/gentoo/pull/12375
>
Is the group-writability really needed here?
> ACCT_USER_HOME_PERMS=0770
I don't think the existing ebuilds change the permissions on that
directory. In any case,
> keepdir
On 8/7/19 1:10 PM, Michał Górny wrote:
>
> Using '999' was also suggested (as the first dynamic
> UID/GID) but it would cause issues for people enabling
> ACCT_*_ENFORCE_ID. To avoid this, '-1' does not trigger collision
> checks.
>
Feel free to proceed with this, I'm just curious: what's the
On 8/7/19 11:30 AM, Hasan ÇALIŞIR wrote:
> +ACCT_USER_ID=495
> +ACCT_USER_HOME=/var/lib/gvm
> +ACCT_USER_HOME_OWNER=gvm:gvm
> +ACCT_USER_GROUPS=( gvm )
The HOME_OWNER is redundant, that's the eclass default.
On 8/3/19 7:49 PM, Michael Orlitzky wrote:
>
> That makes me think that we should set
>
> ACCT_USER_HOME=/var/lib/amavis
>
We'll do this during the next version/revision bump, keeping everything
else the same.
On 8/4/19 2:02 PM, Conrad Kostecki wrote:
> +
> +ACCT_USER_GROUPS=( "fhem" )
> +ACCT_USER_HOME="/opt/fhem"
> +ACCT_USER_HOME_OWNER="fhem:fhem"
Same comment for the rest of these.
On 8/4/19 2:07 PM, Conrad Kostecki wrote:
> +
> +ACCT_USER_GROUPS=( "minecraft" )
> +ACCT_USER_HOME="/var/lib/minecraft-server"
> +ACCT_USER_HOME_OWNER="minecraft:minecraft"
You don't have to set ACCT_USER_HOME_OWNER here. That ownership is the
common case, so the eclass will do the right thing
On 8/3/19 2:43 PM, Ralph Seichter wrote:
> +
> +EAPI=7
> +
> +inherit acct-user
> +
> +ACCT_USER_ID=333
> +ACCT_USER_GROUPS=( amavis )
> +DESCRIPTION="User for mail-filter/amavisd-new"
> +
> +acct-user_add_deps
The existing user created by the amavisd-new ebuilds has a home
directory of
On 8/2/19 11:58 AM, Michał Górny wrote:
>
> Given that overlays won't do proper assignment, the numbers they choose
> may collide with numbers used in ::gentoo. Forcing explicit assignment
> from dynamic range is cleaner in that regard.
>
I think it would be cleanest to leave the hacks in the
On 8/2/19 5:53 AM, Michał Górny wrote:
>
> Sure. Please preferably address two of them separately, so we can
> commit the 0 patch first, and -1 when CI is ready.
>
Maybe I'm just feeling cynical, but what do we gain by adding support
for something that no real package should do? Is it just to
On 7/25/19 4:29 PM, Michał Górny wrote:
>>
>> * In the md5-cache entry, maybe use a common prefix like EXT_ for the
>> extra keys in order to distinguish them from normal keys.
>
> Yeah, I was thinking of something like '__ext_foo', or '__ext[foo]'.
>
What are the pros/cons of this? The names
On 7/15/19 11:37 AM, William Hubbs wrote:
>
> https://www.osnews.com/story/25556/understanding-the-bin-sbin-usrbin-usrsbin-split/
>
> In particular, note Rob Landley's response linked in that story.
>
> So, this has nothing to do with systemd at all, please stop conflating
> it.
>
That wiki
On 7/15/19 11:22 AM, Mike Gilbert wrote:
>
> The "split-usr" flag is already being used by a few packages, so I
> would like to keep it.
The merits of the usr-merge notwithstanding, this does make more sense
if the plan is to eventually drop the flag entirely.
>> (This will be especially bad
On 7/15/19 10:45 AM, Jaco Kroon wrote:
> I have no idea who wrote this:
>
> "The historical justification for a /bin, /sbin and /lib separate from
> /usr no longer applies today." but I strongly disagree.
All of that stuff is written from the perspective of "I feel like doing
it this way in
On 7/14/19 9:56 PM, William Hubbs wrote:
>
> The ultimate goal is to turn this flag off in the 19.0 profiles, we are
> just preserving the current status in the earlier ones.
>
So, to be clear: the plan is to force a /usr merge after all?
On 7/14/19 10:02 PM, Andreas K. Huettel wrote:
> Am Montag, 15. Juli 2019, 03:49:00 CEST schrieb Michael Orlitzky:
>> (This will be especially bad for the people who start
>> with USE="-*")
>
> Not recommended, not supported. Garbage in, garbage out.
>
Nothing In, Garbage Out.
On 7/14/19 7:50 PM, Mike Gilbert wrote:
>
> +# Mike Gilbert (2019-07-14)
> +# Enable split-usr by default to keep systems working.
> +USE="${USE} split-usr"
A mandatory USE="keep-working" raises some philosophical red flags for
me. Wouldn't it be better to name the flag "merge-usr" and leave
On 7/11/19 11:43 AM, William Hubbs wrote:
>>
>> then by default, OpenRC will pull in sys-apps/sysvinit, and use its
>> implementations of init/shutdown. Then later if someone wants to get rid
>> of sys-apps/sysvinit, he has the option to uninstall sys-apps/sysvinit
>> and then re-emerge OpenRC
On 7/10/19 11:14 PM, William Hubbs wrote:
>
> I don't want to remove sysvinit by default. If you want to remove it,
> you can, but I don't want to force that issue. That's why I don't want
> to turn the use flag on by default like systemd does.
>
After re-reading the bug report and sleeping on
On 7/10/19 8:03 PM, William Hubbs wrote:
>>
>> This logic, or maybe the name of the flag, sounds backwards to me. I
>> only get sysvinit when USE=sysvinit is NOT set?
>
> If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init
> and /sbin/shutdown as they are now, from
On 7/10/19 7:16 PM, William Hubbs wrote:
> 3. add a sysvinit use flag to openrc, which will be off by default. When
> it is on, openrc will block sysvinit since it will provide /sbin/init
> and /sbin/shutdown.
>
This logic, or maybe the name of the flag, sounds backwards to me. I
only get
On 6/26/19 6:35 AM, Marek Szuba wrote:
> Here is the RFC for acct-* packages corresponding to users and groups
> created by packages I currently maintain. This is also a request to
> reserve the respective UIDs/GIDs, namely:
>
> Groups:
> - burp - 501
> - rtkit - 133
And syncthing GID 502.
On 6/20/19 9:53 AM, Brian Evans wrote:
>> +
>> +Following the acceptance of this GLEP, all new users and groups must
>> +be created via user/group packages as defined in this GLEP. The old
>> +method may still be used for existing users/groups, in existing
>> +packages.
>> +
>> +All new users and
On 6/13/19 1:33 AM, Michał Górny wrote:
>>
>>> + eshell=$(user_get_nologin)
>>
>> Then this would have to become
>>
>> eshell=$(userland_get_nologin "${USERLAND}")
>
> Do you have any real use for that?
>
No. It's a better design IMO since you can e.g. test the function by
passing
On 6/13/19 4:54 AM, Alexey Shvetsov wrote:
> Hi!
>
> Its a good thing that you're reviewing user class. I write some thought
> previosly about it.
>
> Why not create some set for standart uid:gid for services so they will
> be identicall in all installations?
>
> like slurm has uid:gid
On 6/9/19 7:39 AM, Michał Górny wrote:
>
> +
> +All new users and groups must have unique UIDs/GIDs assigned
> +by developers. The developer adding them is responsible for checking
> +for collisions.
>
> ...
>
> +All user and group packages must define preferred fixed UIDs/GIDs,
> +and they
On 6/11/19 12:23 PM, Michał Górny wrote:
> +++ b/net-ftp/ftpbase/ftpbase-0.01-r3.ebuild
> @@ -0,0 +1,39 @@
> +# Copyright 1999-2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit eutils pam user
> +
user.eclass can go, and I'm
On 6/11/19 12:23 PM, Michał Górny wrote:
>
> +# @FUNCTION: user_get_nologin
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Find an appropriate 'nologin' shell for the platform, and output
> +# its path.
> +user_get_nologin() {
This isn't a great name for this function, because it doesn't have
anything
On 6/6/19 1:06 AM, Andreas K. Huettel wrote:
> Hi all,
>
> for the package maintainers among you, here's the list of remaining EAPI=2
> packages. Please help getting the number down to zero soon!!!
>
> ...
> net-analyzer/nagtrap-0.1.3
Last release in 2008, no maintainer, dead homepage, dead
On 6/9/19 7:28 AM, Michał Górny wrote:
>
> +# @FUNCTION: egetusername
> +# @USAGE:
> +# @DESCRIPTION:
> +# Gets the username for given UID.
> +egetusername() {
> + local pos
> +
> + [[ $# -eq 1 ]] || die "usage: egetusername "
> +
> + egetent passwd "$1" | cut -d: -f1
> +}
Unused
On 6/9/19 7:28 AM, Michał Górny wrote:
> _assert_pkg_ebuild_phase() {
> case ${EBUILD_PHASE} in
> - setup|preinst|postinst) ;;
> + setup|preinst|postinst|prerm|postrm) ;;
> *)
> eerror "'$1()' called from '${EBUILD_PHASE}' phase which is not
> OK:"
>
On 6/5/19 5:12 AM, Michał Górny wrote:
> +
> + # check for ACCT_USER_ID collisions early
> + if [[ -n ${ACCT_USER_ENFORCE_ID} ]]; then
> + local pwd=$(egetent passwd "${ACCT_USER_ID}")
> + if [[ -n ${pwd} ]]; then
> + eerror "The required UID is
Should we require a mailing list review for new user/group packages?
It's difficult to modify a user once you've settled on a UID, home
directory, and shell; so it pays to get things right the first time.
The need is more apparent with fixed UIDs: if a popular package "steals"
a UID that some
On 5/29/19 3:28 AM, Michał Górny wrote:
>
> Home directory ownership
>
>
> If the user in question uses a regular home directory (i.e. not
> ``/dev/null``), the user package should maintain the directory
> via ``keepdir`` command. This allows for clean removal of the
On 5/29/19 5:50 AM, Jaco Kroon wrote:
>>
>> This GLEP follows the best practice of leaving obsolete user/groups
>> accounts intact. This guarantees that no files with stale ownership are
>> left (e.g. on unmounted filesystems) and that the same UID/GID is not
>> reused for another user/group.
>
On 5/29/19 4:01 AM, Ulrich Mueller wrote:
>
> I wonder why that would be needed. It won't catch collisions with users
> created by the system administrator.
The reference implementation did its best not to annoy you here.
Ultimately, no, it can't prevent the system administrator from
clobbering
On 4/26/19 10:54 AM, Michał Górny wrote:
In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a
better solution, because (a) the end result is exactly the same, (b) it
keeps the dependency out of the eclass, and (c) it localizes the
dependency to the place that needs it, namely
On 4/26/19 9:32 AM, Michał Górny wrote:
>
> Whether it can be deleted is up to system's configuration. The current
> solution works for majority of cases, including a. people who use
> systemd or OpenRC, and set their systems to clean it up, and b. people
> who don't use either but don't clean
On 4/26/19 9:07 AM, Michał Górny wrote:
>
>> I don't think so -- not if it needs that tmpfiles
>> entry to be processed every reboot. Thus it should have its own RDEPEND
>> on virtual/tmpfiles, making the one in the eclass redundant.
>
> It doesn't need to be processed every reboot. It needs
On 4/26/19 12:53 AM, Michał Górny wrote:
>
> No. tmpfiles is also used for programs started directly by user, such
> as eix.
>
This configuration is buggy to begin with: if I run eix-update as my
user, then the permissions on the files it creates under /var/cache/eix
are wrong (mjo:mjo, mode
On 4/26/19 7:07 AM, Michael Orlitzky wrote:
> Thus it should have its own RDEPEND on virtual/tmpfiles, making the
> one in the eclass redundant.
Correction, it should RDEPEND on either systemd or OpenRC. Having the
"tmpfiles" binary installed is not enough; it needs to be
On 4/26/19 12:53 AM, Michał Górny wrote:
>>
>> And the only reason we would need a transient directory created and/or
>> cleaned-up is because one of those service managers is going to start a
>> program that needs it. Two of them can use the tmpfiles mechanism, but
>> the others must handle it on
On 4/25/19 5:23 PM, Michał Górny wrote:
>>
>> What's wrong? You only need the effect of tmpfiles_process() if you're
>> running systemd or OpenRC. If the user is running SysV-init and if the
>> package also installs a SysV-init script, then that init script is going
>> to have to create any
On 4/25/19 4:20 PM, Michał Górny wrote:
>
> Wrong. tmpfiles_process() requires virtual/tmpfiles on any system,
> including daemontools, bare minimal init and whatever. Keeping it
> installed afterwards is a minor side effect, and technical limitation of
> our dependency types (lack of
On 4/24/19 8:53 AM, Michał Górny wrote:
>
> systemd.eclass has more than one purpose, and therefore such dep didn't
> belong there (ebuilds should take care of the dependencies when using
> tmpfiles logic from it). tmpfiles.eclass on the other hand has a single
> purpose, so we've solved the
On 4/24/19 8:24 AM, Michał Górny wrote:
>>
>> which will still work (albeit with a warning) if you somehow manage not
>> to have virtual/tmpfiles installed. So, if it's important, I think we
>> could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass.
>
> Programs depend on tmpfiles being
On 4/23/19 6:25 PM, Zac Medico wrote:
>
> Note that systemd.eclass is lighter on dependencies, which is why I
> chose it for the solution to bug 490676 [1] and bug 643386 [2] in the
> sys-apps/portage ebuilds.
>
> [1] https://bugs.gentoo.org/490676
> [2] https://bugs.gentoo.org/643386
>
I
We have two eclasses with almost-identical functions for handling
tmpfiles.d entries:
1. systemd.eclass
a. systemd_dotmpfilesd
b. systemd_newtmpfilesd
c. systemd_tmpfiles_create
2. tmpfiles.eclass
a. dotmpfiles
b. newtmpfiles
c. tmpfiles_process
The do/new
On 3/27/19 3:19 PM, Matt Turner wrote:
>>
>> You got it: I just pushed 17 commits, addressing ~5 open bugs. I've
>> added you, klondike, proxy-maint, and myself as maintainers.
>
> Nice. I'm curious: what were you waiting on before?
>
It was pretend-maintained by net-mail, and I wasn't a member
On 3/26/19 5:09 PM, Ralph Seichter wrote:
> * Michael Orlitzky:
>
>> I'd be happy to work on all of that stuff either before or after you
>> guys take over and get settled in.
>
> I'd appreciate you adding all improvements you already have in store.
> It would be a
On 3/26/19 4:32 PM, Aaron Bauman wrote:
> On Tue, Mar 26, 2019 at 09:10:28PM +0100, Ralph Seichter wrote:
>> * Michał Górny:
>>
>>> mail-filter/opendkim
>>
>> I can take OpenDKIM if no former team member wants to.
>>
>
> Please have a look at bug #629914 as well. Let me know if you submit a
>
On 3/26/19 3:43 PM, Michał Górny wrote:
> On Tue, 2019-03-26 at 19:33 +, Aaron Bauman wrote:
>> commit: 2e32186bbee30a4a2e1c4f37c79c61897e53d8df
>> Author: Michael Mair-Keimberger gmail com>
>> AuthorDate: Tue Mar 26 19:28:48 2019 +
>> Commit: Aaron Bauman gentoo org>
>>
On 3/2/19 9:01 PM, Rich Freeman wrote:
>
> So, the problem with cron.d is that you're now using crontab syntax,
> and for compatibility you have to use the lowest common denominator
> which is vixie.
>
> That means your jobs are STILL running as root, so the only problem
> you had with run-parts
On 3/2/19 7:44 PM, Rich Freeman wrote:
>>
>> Totally. We should replace run-parts with something much simpler and
>> more predictable. Then, if that doesn't work for you, all modern crons
>> can do the things that run-parts tries to do, but better.
>>
>
> I'm not sure I see the connection here.
On 3/2/19 7:05 PM, William Hubbs wrote:
>
> Is there a reason we still use run-parts and the
> /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?
>
> From what I read in the chat earlier, it sounds like the modern crons
> might be able to handle this without that
On 2/21/19 1:09 AM, Matt Turner wrote:
>
> 2)Suggestions welcome for solving https://bugs.gentoo.org/637898
> I have no ideas...
>
The eclass documentation script wants a fixed default value for
variables that are optional.
For XORG_MODULE, instead of a case statement,
if [[ -z
On 2/19/19 11:21 PM, Matthew Thode wrote:
>>
>> What problem would this solve? (Is adding gentoo-keys to @system the
>> least bad way to solve it?)
>>
>
> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> portage tarballs. This is useful for the initial sync (as called out in
>
On 2/19/19 10:23 PM, Matthew Thode wrote:
> As the title says, I think this should be done.
>
> First sync is impossible to verify without keys (webrsync)
> app-crypt/gentoo-keys has no dependencies, which help avoid some bloat
> in the base install.
>
> Let the bikeshedding begin.
>
I don't
On 12/8/18 1:27 PM, Ralph Seichter wrote:
I am trying to add NodeJS support to www-servers/nginx-unit, but the
upstream build relies on a working network connection to download
dependencies and execute "npm install ..." during the build process.
How can this scenario be handled properly in an
On 11/13/2018 01:21 AM, Zac Medico wrote:
>
> What's inherently wrong about nix having a file store under /nix? Is
> this purely about FHS?
>
It goes against not only the FHS, but against our existing policies and
common sense. There's no reason to expect that path to even be writable.
And nix
On 11/12/2018 06:47 PM, Zac Medico wrote:
>>
>> The idea being, to put it in the right place by default, and let people
>> override it with EXTRA_ECONF if they really want to download random
>> binaries from strangers and run them.
>
> I recommend to add /nix to the whitelist because this is the
On 11/12/2018 04:06 PM, Zac Medico wrote:
> On 11/12/18 12:57 PM, Michael Orlitzky wrote:
>> On 11/12/2018 03:33 PM, Zac Medico wrote:
>>>
>>> QA_INSTALL_PATHS=( /nix )
>>
>> That really, really, really doesn't belong there.
>
> I'm open to suggesti
On 11/12/2018 03:33 PM, Zac Medico wrote:
>
> QA_INSTALL_PATHS=( /nix )
>
That really, really, really doesn't belong there.
On 11/08/2018 03:36 PM, Ralph Seichter wrote:
> * Michael Orlitzky:
>
>> It's an open secret that packages maintained by
>> category-n...@gentoo.org are in reality unmaintained; or are
>> maintained by one guy (who may or may not be on the alias).
>
> As somebody
On 11/08/2018 09:44 AM, Ralph Seichter wrote:
> Three weeks ago I sent the message shown below to the Gentoo Net-Mail
> team. Since I did not receive a reply, I am now asking on this mailing
> list: What can I do to have the pull request, which I opened six weeks
> ago, taken care of?
It's an
On 11/01/2018 06:27 PM, Andrew Savchenko wrote:
>
> This eclass is small, so no harm here. But for larger eclasses
> (hello java-*.eclass) this will hinder updates considerably. I
> prefer to fix something rather than to fix nothing while
> frustrating in attempt to fix everything at once.
>
>
On 10/26/2018 04:40 AM, Michal Prívozník wrote:
>
> So the desired way is to use github pull requests? That is rather
> unfortunate.
In this case there's no "project" associated with libvirt-snmp; but if
there were, it would have a @gentoo.org alias that you
could send patches to. Bugzilla is
On 10/20/2018 04:05 AM, Mikle Kolyada wrote:
>
> ...
>
Ok, thanks for clarifying. I wanted to be sure that I wasn't getting
anyone into trouble by suggesting that they look into the quizzes (if
they are really willing to put in the effort).
On 10/13/2018 02:32 PM, Mikle Kolyada wrote:
>
> Quizzes are irrelevant, a person does the quizzes when he/she is
> ready to be the dev, doing quizzes for quizzes or quizzes to become a
> developer is the best way to get rejected by the recruiters team.
I thought this was kind of a strange thing
Pushed.
On 10/03/2018 12:38 PM, Zac Medico wrote:
>
> Until this QA check has adjustable whitelist support, we can consider it
> an unstable work in progress.
Has anyone said why these things need to be in ${PN}-${PV} rather than
${PF}?
If they don't need to be in ${PN}-${PV} in the first place, then
On 10/01/2018 11:19 AM, Zac Medico wrote:
>
> The first bug report [2] is for qt-core, which installs documentation
> into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF}
It would be helpful to know why qtcore installs into the wrong directory
in the first place.
If ${PF} really
/open-mx
but their maintainers haven't responsed to the bug, email, or IRC. So
for lack of a better option, I'd like to offer this up as-is again.
v2 is simply a rebase onto ::gentoo master, and adds my signoff.
Michael Orlitzky (1):
profiles: unset USE=modules by default.
profiles/base
ps://bugs.gentoo.org/635720
Signed-off-by: Michael Orlitzky
---
profiles/base/make.defaults | 5 -
profiles/default/linux/make.defaults | 5 -
profiles/features/hardened/make.defaults | 1 -
3 files changed, 11 deletions(-)
diff --git a/profiles/base/make.defaults b/profile
On 09/16/2018 02:59 AM, Michał Górny wrote:
> Hi, everyone.
>
> Just FYI: the Trustees have approved GLEP 76 aka our new copyright
> policy [1]. While the exact implementation details are to be determined
> yet, please note that *Signed-off-by* line will mean you are certifying
> our GCO [2].
>
On 09/17/2018 02:52 AM, Michał Górny wrote:
>
> --- a/bin/ebuild-helpers/fowners
> +++ b/bin/ebuild-helpers/fowners
> ...
> + eqawarn "This is unsupported. Please use 'chmod' when you need
> to work on files"
This one should be 'chown' instead of 'chmod'.
(Calling chown on the live
On 09/14/2018 03:58 PM, Richard Yao wrote:
>>
>> No one has answered the question: what do you do when a stable package
>> breaks because of a new warning?
>>
>> ...>
> Wouldn’t this be largely covered as part of GCC stabilization? We could
> reserve the right to kill -Werror in a package where
On 09/14/2018 01:52 PM, Rich Freeman wrote:
>
> Wouldn't the flip side of this be demonstrating that this has actually
> caused issues? If following upstream discovers no bugs and also
> causes no issues, why not leave it to maintainer discretion?
>
We know it causes issues, there are hundreds
On 09/09/2018 07:32 AM, Andrew Savchenko wrote:
> Hi!
>
> Our current -Werror policy demands unconditional removal:
> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed
>
> I think this is wrong, see bugs 665464, 665538 for a recent
>
On 09/04/2018 01:53 PM, Michał Górny wrote:
> + # TODO: do we need it? gconf installs empty dir there but that's
> + # all
> + root
FWIW, we should not allow this.
On 08/12/2018 03:22 AM, Michał Górny wrote:
> Hi, everyone.
>
> Here's a long batch of patches adding @SUPPORTED_EAPIS to eclasses.
We should add this to https://devmanual.gentoo.org/eclass-writing, too.
I see you already got app-portage/eclass-manpages.
301 - 400 of 942 matches
Mail list logo
