Re: [gentoo-dev] Last rites: net-im/silc-toolkit
On 19/01/20 06:23, Joonas Niilola wrote: > On 1/19/20 5:44 AM, David Seifert wrote: >> On Sat, 2020-01-18 at 23:48 +, Michael 'veremitz' Everitt wrote: >>> On 18/01/20 22:12, David Seifert wrote: # David Seifert (2020-01-18) # Leftover from silc* removal (#522916), unmaintained, no # upstream releases since 2014, no revdeps, EAPI-4. # Bug #705462. Removal in 14 days. net-im/silc-toolkit > After > >>> Looks like you missed: >>> https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62 > > I asked the maintainer if he was ok with > >> Looks like you missed: >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dfe1c280e312416b3856057ccd6c9f88bcaa1c88 > And he acked. I just didn't have time to make the PR so soap stepped in. > So all is good. Thanks. > > > -- juippis > > > WFM cheers. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: net-im/silc-toolkit
On 1/19/20 5:44 AM, David Seifert wrote: > On Sat, 2020-01-18 at 23:48 +, Michael 'veremitz' Everitt wrote: >> On 18/01/20 22:12, David Seifert wrote: >>> # David Seifert (2020-01-18) >>> # Leftover from silc* removal (#522916), unmaintained, no >>> # upstream releases since 2014, no revdeps, EAPI-4. >>> # Bug #705462. Removal in 14 days. >>> net-im/silc-toolkit >>> >>> After >> Looks like you missed: >> https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62 I asked the maintainer if he was ok with > Looks like you missed: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dfe1c280e312416b3856057ccd6c9f88bcaa1c88 And he acked. I just didn't have time to make the PR so soap stepped in. So all is good. Thanks. -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: net-im/silc-toolkit
On Sat, 2020-01-18 at 23:48 +, Michael 'veremitz' Everitt wrote: > On 18/01/20 22:12, David Seifert wrote: > > # David Seifert (2020-01-18) > > # Leftover from silc* removal (#522916), unmaintained, no > > # upstream releases since 2014, no revdeps, EAPI-4. > > # Bug #705462. Removal in 14 days. > > net-im/silc-toolkit > > > > > Looks like you missed: > https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62 > > Yw. > Looks like you missed: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dfe1c280e312416b3856057ccd6c9f88bcaa1c88 Yw.
Re: [gentoo-dev] GLEP81 and /home
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 assuring a quality user >> experience here? >> > > Lots of daemons need a home directory for their users, and usually > they manage to get by in /var/lib. It really seems like a bad > practice to start having packages creating stuff in /home. Certainly > I don't want random daemons sticking stuff in /home, which I manage > Let's restart: * 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 always has been. All I want to do is *set* a user's home directory to /home/foo. Some people want to configure amavis to launch a program like pyzor, which uses per-user configuration files. If you want to do that, you first log in as amavis, and run some command like $ pyzor discover which then finds some servers and creates configuration files for you in $HOME/.pyzor. This is user configuration, not daemon configuration. It doesn't belong in the daemon's working directory. In particular, you should not be dicking around in the daemon's working directory when you run "su amavis..." because what you're doing is irrelevant to the daemon. Spamassassin itself is a better example than amavis. We already set the spamd user's home directory to /home/spamd with user.eclass. We don't install anything there, and this works fine. If a human logs into that account and generates some configuration in ~/.spamassassin, then it's within the spirit of the FHS to have that data stored in /home. Now, with GLEP 81, we get a QA warning for that, because the eclass installs a keepdir file there. I would like things to remain exactly as they are, with no QA warning. Otherwise, we have to tell users to move /home/spamd to /var/lib/spamd-home or something stupid like that. I can think of no good reason to do so. > It seems like the straightforward solution is to stick everything in > /var/lib/amavis, and fix things so that everything has the right > permissions regardless of install order. Please stop telling people to do this. Calling chown on the live filesystem is rarely safe, and I already fixed one root exploit (bug 630836) in the amavisd-new ebuild from the last guy who tried to adjust wrong permissions after the fact. > Another option is to have /var/lib/amavis/home and /var/lib/amavis/work. This is better-looking than /var/lib/amavis-home, but it's still violating the spirit of the FHS to avoid triggering a warning on a dummy file.
Re: [gentoo-dev] GLEP81 and /home
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 assuring a quality user > experience here? > Lots of daemons need a home directory for their users, and usually they manage to get by in /var/lib. It really seems like a bad practice to start having packages creating stuff in /home. Certainly I don't want random daemons sticking stuff in /home, which I manage differently from the OS-owned directories. I'll just end up having to manually create stuff where it belongs in /var/lib and then symlink everything back from /home, and now I have distro cruft in /home and non-distro cruft in /var/lib, and neither is ideal. It seems like the straightforward solution is to stick everything in /var/lib/amavis, and fix things so that everything has the right permissions regardless of install order. If /var/lib/amavis is getting installed root-owned then it should be chowned when amavis is installed, especially for the first time. That seems sane. Another option is to have /var/lib/amavis/home and /var/lib/amavis/work. -- Rich
Re: [gentoo-dev] Last rites: net-im/silc-toolkit
On 18/01/20 22:12, David Seifert wrote: > # David Seifert (2020-01-18) > # Leftover from silc* removal (#522916), unmaintained, no > # upstream releases since 2014, no revdeps, EAPI-4. > # Bug #705462. Removal in 14 days. > net-im/silc-toolkit > > Looks like you missed: https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62 Yw. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP81 and /home
On 1/18/20 1:10 PM, Ulrich Mueller wrote: > >> Should option (3) be viable, or do I go back to the drawing board? > > Chances are that /home is site specific, e.g. with a special backup > policy, or shared between many hosts via NFS. So IMHO /home is off > limits for the package manager. > We don't actually install anything there except the keepdir file, which is why this used to work with user.eclass. If someone later logs in as "amavis" and creates some configuration in $HOME, then that stuff is subject to your backup/sharing policy just like any other user data. I could always just use /home/amavis as $HOME and un-keepdir that location. We don't really care if the directory exists, until/unless someone logs in and starts adding configuration, so that's semantically correct. No permissions problems and no QA warnings either. But now users have to follow one more step (create /home/amavis) when setting up amavisd-new. Is the QA check really assuring a quality user experience here?
[gentoo-dev] Last rites: net-im/silc-toolkit
# David Seifert (2020-01-18) # Leftover from silc* removal (#522916), unmaintained, no # upstream releases since 2014, no revdeps, EAPI-4. # Bug #705462. Removal in 14 days. net-im/silc-toolkit
[gentoo-dev] Last rites: dev-python/*; py2 no-revdep, pt. 1
# Michał Górny (2020-01-18) # The following Gentoo packages are Python 2-only and have no reverse # dependencies. # Removal in 30 days. Bug #705762. dev-python/aldryn-boilerplates dev-python/aldryn-common dev-python/aquarium dev-python/celementtree dev-python/collectd-rabbitmq dev-python/cosmolopy dev-python/django-annoying dev-python/django-endless-pagination dev-python/django-international dev-python/django-ldapdb dev-python/django-ldap-groups dev-python/django-oauth-plus dev-python/django-openid-auth dev-python/django-piston dev-python/django-registration dev-python/django-xslt dev-python/egg-python dev-python/Flask-KVSession dev-python/flask-openid dev-python/flask-xml-rpc dev-python/gdata dev-python/libwnck-python dev-python/lxc-python2 dev-python/mantissa dev-python/mkpythonproj dev-python/morbid dev-python/myghty dev-python/myghtyutils dev-python/openstack-nose-plugin dev-python/paisley dev-python/pkipplib dev-python/processing dev-python/pSQL dev-python/pudge dev-python/pyds dev-python/pygene dev-python/pygtkhelpers dev-python/pynotifier dev-python/pypgsql dev-python/pythong dev-python/python-musicbrainz dev-python/python-nss dev-python/python-recaptcha dev-python/python-scw dev-python/python-tvrage dev-python/python-yadis dev-python/qpid-python dev-python/robotframework-selenium2library dev-python/robotframework-sshlibrary dev-python/rtgraph dev-python/ruledispatch dev-python/runsnakerun dev-python/sqlite3dbm dev-python/sqlobject dev-python/steadymark dev-python/storm dev-python/timelib dev-python/turbocheetah dev-python/turbojson dev-python/turbokid dev-python/weakrefmethod dev-python/webut dev-python/wehjit dev-python/zfec -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP81 and /home
On 1/18/20 2:03 PM, Alec Warner wrote: > > I tend to agree that in theory keeping the working directory and home > directory the same is not ideal. However I'm not really aware of any > practical problems. Haven't we basically run in this configuration for > years? What kind of issues does it pose (outside of "well it sounds like > not the best idea?") There have been numerous bugs and mailing list discussions about the problems it causes, but it's kind of a moot point here. The best reason to avoid re-using /var/lib/amavis as the daemon's home directory is because it really is treated like a home directory by all of these packages, and we shouldn't dump a user's dotfiles into a daemon's working directory without a good reason. (We haven't been running this configuration for years, because we haven't had the GLEP81 eclasses that clobber your permissions for years.) > Agreeing with ulm here. I think the potential struggle for (3) is that > conceptually /home is not always system specific. If /home is shared, > you could end up with a bad time (e.g. I *don't* want /home/amavis > shared across all my hosts, how would I manage multiple versions? All of the upstream packages treat $HOME as user configuration. If you want to run two different daemons with two different configurations and if those configurations are sourced from $HOME, then you make two different users. There is no problem here. I'm willing to pick something like /var/lib/amavis-home, but that's clearly just second-guessing the administrator and putting a home directory somewhere it doesn't belong to avoid a QA warning. We have a similar situation with spamd in spamassassin itself, and I'd rather not maintain my own fake /home hierarchy as /var/lib/$user-home.
Re: [gentoo-dev] GLEP81 and /home
On 1/18/20 2:08 PM, Michał Górny wrote: > > Sounds like you've created an arbitrary rule that prevents the two > packages from using the same directory, and therefore you've created > this problem yourself. Why not just go back and reconsider using > the same directory instead of adding complexity for ideological reasons? > > Is it really that problematic to have the directory created by amavisd > user, and have all packages depend on it? > The user's home directory is conceptually and (usually) literally separate from the daemon's working directory. That's upstream, not in my head. So it's wrong to combine them in principle, especially given that it creates security timebombs when two packages "share" a directory.
Re: [gentoo-dev] GLEP81 and /home
On Sat, 2020-01-18 at 12:51 -0500, Michael Orlitzky wrote: > We forbid packages from installing to /home for good reason: for most of > history, users (and their home directories) were outside the purview of > the package manager. But with GLEP81, that's changed: the package > manager is now in charge of creating each system user's home directory > and of giving it the correct permissions and ownership. > > Is the policy against installing to /home still consistent? > > For example: the mail-filter/amavisd-new daemon needs a user, typically > called "amavis". The daemon also needs a working directory that it can > write to. The obvious choice for a working directory is /var/lib/amavis, > but there's a catch: spamassassin, razor, pyzor, et cetera (which are > all used by amavis) store their configuration in the current user's home > directory, and not in some daemon-specific location. So "amavis" needs a > home directory, because that's where much of the configuration for > amavisd goes. > > Where do we put amavis's home directory? > > 1 /var/lib/amavis is a bad idea, because it conflicts with the working > directory (we don't want the two packages to get out of sync, nor do > we want to keep them in-sync manually). > Sounds like you've created an arbitrary rule that prevents the two packages from using the same directory, and therefore you've created this problem yourself. Why not just go back and reconsider using the same directory instead of adding complexity for ideological reasons? Is it really that problematic to have the directory created by amavisd user, and have all packages depend on it? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP81 and /home
On Sat, Jan 18, 2020 at 9:52 AM Michael Orlitzky wrote: > We forbid packages from installing to /home for good reason: for most of > history, users (and their home directories) were outside the purview of > the package manager. But with GLEP81, that's changed: the package > manager is now in charge of creating each system user's home directory > and of giving it the correct permissions and ownership. > > Is the policy against installing to /home still consistent? > > For example: the mail-filter/amavisd-new daemon needs a user, typically > called "amavis". The daemon also needs a working directory that it can > write to. The obvious choice for a working directory is /var/lib/amavis, > but there's a catch: spamassassin, razor, pyzor, et cetera (which are > all used by amavis) store their configuration in the current user's home > directory, and not in some daemon-specific location. So "amavis" needs a > home directory, because that's where much of the configuration for > amavisd goes. > > Where do we put amavis's home directory? > > 1 /var/lib/amavis is a bad idea, because it conflicts with the working > directory (we don't want the two packages to get out of sync, nor do > we want to keep them in-sync manually). > > 2 /var/lib/amavis/home was my next choice, because logically it puts > the amavisd configuration in a subdirectory of the place where all > of the other amavis stuff goes, and because it doesn't have the > same issue that (1) does. > > But there's a problem: if we create /var/lib/amavis/home before > amavisd-new is installed (as happens when you emerge amavisd-new), > then /var/lib/amavis winds up root:root and the installation of > amavisd-new doesn't change that. So now amavisd-new doesn't work, > because it can't write to its working directory. > > This is a combination of an implementation detail and the fact that > the PMS doesn't cover directories; but ultimately, it just doesn't > work reliably. > > 3 /home/amavis also seems fine to me, except for the fact that it's a > QA violation to install there. > > Note that we could always set system users' home directories to > /home/whatever. It has only become a QA violation with GLEP81 because > the eclass calls keepdir on the user's home directory. > > Should option (3) be viable, or do I go back to the drawing board? > I tend to agree that in theory keeping the working directory and home directory the same is not ideal. However I'm not really aware of any practical problems. Haven't we basically run in this configuration for years? What kind of issues does it pose (outside of "well it sounds like not the best idea?") Agreeing with ulm here. I think the potential struggle for (3) is that conceptually /home is not always system specific. If /home is shared, you could end up with a bad time (e.g. I *don't* want /home/amavis shared across all my hosts, how would I manage multiple versions? Multiple configs?) Often all of /home is mounted and it becomes tricky to build workarounds. You could do things like "symlink /home/amavisd to some local path". At work we use /usr/local/google/home/$USER for this purpose; but it is basically a vestigial artifact from an earlier time than something we explicitly designed. Even the symlink solution is not ideal. NFS can present some exciting reliability issues and so having to touch NFS just to read the symlink (pointing locally) is probably not something I'd advise at scale; it would be simpler to change the users homedir to be elsewhere. Note that I'd expect large scale installs to do this anyway (I wouldn't rely on GLEP81 to manage users in an enterprise environment) but i'm not sure if the entire community shares that belief ;) -A
Re: [gentoo-dev] GLEP81 and /home
> On Sat, 18 Jan 2020, Michael Orlitzky wrote: > Where do we put amavis's home directory? > [...] > 3 /home/amavis also seems fine to me, except for the fact that it's a > QA violation to install there. > Note that we could always set system users' home directories to > /home/whatever. It has only become a QA violation with GLEP81 because > the eclass calls keepdir on the user's home directory. > Should option (3) be viable, or do I go back to the drawing board? Chances are that /home is site specific, e.g. with a special backup policy, or shared between many hosts via NFS. So IMHO /home is off limits for the package manager. Your original idea of placing it somewhere under /var/lib sounds just right. Ulrich
[gentoo-dev] Last rites: net-ftp/oftpd
# David Seifert (2020-01-18) # EAPI 4, last release in 2004, ebuild has QA and licensing issues. # Bug #426028, #454116. Removal in 30 days. net-ftp/oftpd
[gentoo-dev] Last rites: net-dns/validns
# David Seifert (2020-01-18) # EAPI 4, doesn't build against OpenSSL 1.1 API, last release in 2014, # lots of QA issues (calls cc directly, -Werror) # Bug #634442, #664766. Removal in 30 days. net-dns/validns
[gentoo-dev] GLEP81 and /home
We forbid packages from installing to /home for good reason: for most of history, users (and their home directories) were outside the purview of the package manager. But with GLEP81, that's changed: the package manager is now in charge of creating each system user's home directory and of giving it the correct permissions and ownership. Is the policy against installing to /home still consistent? For example: the mail-filter/amavisd-new daemon needs a user, typically called "amavis". The daemon also needs a working directory that it can write to. The obvious choice for a working directory is /var/lib/amavis, but there's a catch: spamassassin, razor, pyzor, et cetera (which are all used by amavis) store their configuration in the current user's home directory, and not in some daemon-specific location. So "amavis" needs a home directory, because that's where much of the configuration for amavisd goes. Where do we put amavis's home directory? 1 /var/lib/amavis is a bad idea, because it conflicts with the working directory (we don't want the two packages to get out of sync, nor do we want to keep them in-sync manually). 2 /var/lib/amavis/home was my next choice, because logically it puts the amavisd configuration in a subdirectory of the place where all of the other amavis stuff goes, and because it doesn't have the same issue that (1) does. But there's a problem: if we create /var/lib/amavis/home before amavisd-new is installed (as happens when you emerge amavisd-new), then /var/lib/amavis winds up root:root and the installation of amavisd-new doesn't change that. So now amavisd-new doesn't work, because it can't write to its working directory. This is a combination of an implementation detail and the fact that the PMS doesn't cover directories; but ultimately, it just doesn't work reliably. 3 /home/amavis also seems fine to me, except for the fact that it's a QA violation to install there. Note that we could always set system users' home directories to /home/whatever. It has only become a QA violation with GLEP81 because the eclass calls keepdir on the user's home directory. Should option (3) be viable, or do I go back to the drawing board?
[gentoo-portage-dev] [PATCH] file_copy: handle lseek SEEK_DATA EBADFD for GlusterFS (bug 705536)
GlusterFS can set the errno to EBADFD for lseek SEEK_DATA.
Tested-by: Tomáš Mózes
Bug: https://bugs.gentoo.org/705536
Signed-off-by: Zac Medico
---
src/portage_util_file_copy_reflink_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/portage_util_file_copy_reflink_linux.c
b/src/portage_util_file_copy_reflink_linux.c
index 352342c06..f3278aeb7 100644
--- a/src/portage_util_file_copy_reflink_linux.c
+++ b/src/portage_util_file_copy_reflink_linux.c
@@ -258,7 +258,7 @@ _reflink_linux_file_copy(PyObject *self, PyObject *args)
break;
} else if (len < 0) {
error = errno;
-if ((errno == EINVAL || errno == EOPNOTSUPP) &&
!offset_out) {
+if ((errno == EINVAL || errno == EOPNOTSUPP || errno ==
EBADFD) && !offset_out) {
lseek_works = 0;
}
break;
--
2.24.1
[gentoo-dev] Last rites: net-analyzer/pchar
# David Seifert (2020-01-18) # EAPI 4, doesn't build, last release in 2005. # Bug #384031, #638492, #663644. Removal in 30 days. net-analyzer/pchar
