Re: [gentoo-dev] [RFC] News Item: Desktop profile switching USE default to elogind
On 10/29/19 19:08, Patrick McLean wrote: > On Tue, 29 Oct 2019 23:03:15 + > James Le Cuirot wrote: > >> On Tue, 29 Oct 2019 11:23:20 -0700 >> Patrick McLean wrote: >> >>> On Tue, 29 Oct 2019 16:10:37 +0100 >>> Andreas Sturmlechner wrote: >>> Anyone else who thinks this should not be restricted to just desktop profiles? >>> >>> I am not aware of any use cases for elogind/consolekit on servers, >>> it's really for machines where you have to distinguish between >>> someone connecting remotely and someone physically using a >>> keyboard/mouse connected to the machine. >> >> I switched from consolekit to elogind on my normally headless ARM box. >> It runs XMMS2 and outputs through PulseAudio. Under consolekit, my >> user's /var/run directory would disappear after a while, taking the >> pulse socket with it. Under elogind, I was able to set my user to >> "linger", which fixed the issue. It's not a typical use case but yeah, >> they do have uses outside of desktop. > > Which sounds like perfect for a local setup, probably not something > that should be in a generic profile. > > > The bulk of the proposed news item is apropos packages and the reason that the profiles are changing, not actually profile specific considerations; and running a desktop environment hardly requires running a desktop profile. Given that the news is largely in regards to specific packages it seems logical that it would more fully reach the user base affected by the causal changes were it simply directed to those with the package being deprecated installed (as indicated in the proposed news item) without regard for what profile they are using. Beyond that, I'm not aware of any advantages to limiting it to desktop profiles despite the direct cause of the news item being a transition in the profiles; while targeting it more generally does provide the benefit of reminding users who are not using a desktop profile to at least consider following suit prior to last rites on a package that they have installed thereby providing a better user experience on the whole.
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Wed, 30 Oct 2019 10:52:35 -0500 William Hubbs wrote: > If not, I would rather see you pick one of the two options above. -r1 bump all existing consumers of that eclass first? :) pgpOohqnJQZK6.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Thu, Oct 31, 2019 at 03:49:32AM +1300, Kent Fredric wrote: > On Wed, 30 Oct 2019 09:26:09 -0500 > William Hubbs wrote: > > > I don't know portage internals, so I have no idea what the deal with > > this is or how to fix it. > > > > Did you report it to the portage team? > > Report what? > > 1. Didn't have access to the box > 2. No way to even conceive of producing enough information to replicate > it reliably enough that somebody could anticipate digging into the why. > > > > > I've noticed it gets messy very quickly if you wait a while to upgrade > > your system also, so I would be curious how long the user waited to do > > an upgrade? > > And yeah, it was one of those cases of "bad sync length", the user in > question inherited the box from somebody else, and they were left to > pick up the pieces where the other person left off. > > And one of the common things I see that frustrates me, is generally, > when you see these mountains of mess, somebody tries to argue its the > *users* fault for not updating more frequently. > > But IMO, that's a rather distasteful buck-pass. > > The duty of a linux vendor/linux vendor maintainer is to isolate users > from these kinds of problems, and we're clearly failing in this way. > > > > Python is also more complex than most things because we allow multiple > > versions. > > > > There's no way to know whether removing virtual/rust will cause these > > kinds of issues, so I'm still not convinced that we shouldn't remove > > it. > > In light of the aforementioned axiom of "protect the user from messes", > I think it makes sense to approach this from the perspective of: > > If we imagine it could possibly cause a problem, until we prove it > doesn't and can't, we must assume it _will_ There are no ebuilds in the entire tree that directly depend on virtual/cargo; only cargo.eclass lists it directly. Because of that, There are two ways to get rid of virtual/cargo. 1. Apply the patches in this thread. 2. Create cargo-r1.eclass with the patches applied then move all consumers in the tree to it and remove cargo.eclass. The second option seems like overkill and would require a lot more work than the first, but it could be done. You are voicing concerns about either option, so is there a third option other than removing the dependencies from cargo.eclass and requiring the ebuilds to set their own dependencies? If not, I would rather see you pick one of the two options above. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Wed, 30 Oct 2019 09:26:09 -0500 William Hubbs wrote: > I don't know portage internals, so I have no idea what the deal with > this is or how to fix it. > > Did you report it to the portage team? Report what? 1. Didn't have access to the box 2. No way to even conceive of producing enough information to replicate it reliably enough that somebody could anticipate digging into the why. > > I've noticed it gets messy very quickly if you wait a while to upgrade > your system also, so I would be curious how long the user waited to do > an upgrade? And yeah, it was one of those cases of "bad sync length", the user in question inherited the box from somebody else, and they were left to pick up the pieces where the other person left off. And one of the common things I see that frustrates me, is generally, when you see these mountains of mess, somebody tries to argue its the *users* fault for not updating more frequently. But IMO, that's a rather distasteful buck-pass. The duty of a linux vendor/linux vendor maintainer is to isolate users from these kinds of problems, and we're clearly failing in this way. > > Python is also more complex than most things because we allow multiple > versions. > > There's no way to know whether removing virtual/rust will cause these > kinds of issues, so I'm still not convinced that we shouldn't remove > it. In light of the aforementioned axiom of "protect the user from messes", I think it makes sense to approach this from the perspective of: If we imagine it could possibly cause a problem, until we prove it doesn't and can't, we must assume it _will_ pgpsbFwzk5dUG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Wed, Oct 30, 2019 at 09:26:09AM -0500, William Hubbs wrote: > There's no way to know whether removing virtual/rust will cause these > kinds of issues, so I'm still not convinced that we shouldn't remove it. Sorry, I meant virtual/cargo here. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Wed, Oct 30, 2019 at 09:19:14PM +1300, Kent Fredric wrote: > On Tue, 29 Oct 2019 12:27:49 -0500 > William Hubbs wrote: > > > No, I'm just saying this: > > > > We don't know that there is a portage bug from what I'm reading in this > > thread. We are talking about possible bugs, but a possible bug isn't a bug. > > If there is an issue cite it otherwise move on. > > > > --with-bdeps=y is the default for a good reason as far as I am aware. > > > > William > > It only took a 3 days, but today, I'm helping a user who has a massive > upgrade problem. > > Among it, is this gem of a "conflict" > > > dev-python/setuptools:0 > > (dev-python/setuptools-41.1.0:0/0::gentoo, ebuild scheduled for merge) > pulled in by > > dev-python/setuptools[python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required by (dev-util/meson-0.51.2:0/0::gentoo, ebuild scheduled for merge) > > > > > > dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] > required by (dev-python/certifi-2019.6.16:0/0::gentoo, ebuild scheduled for > merge) > > > > > > > > > (dev-python/setuptools-20.6.7:0/0::gentoo, installed) pulled in by > > dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] > required by (net-misc/youtube-dl-2016.09.19:0/0::gentoo, installed) > > > > > > dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] > required by (dev-python/jinja-2.8:0/0::gentoo, installed) > > > > > > > dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] > required by (dev-python/numpy-1.10.4:0/0::gentoo, installed) > > > > > > dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] > required by (dev-python/certifi-2015.11.20:0/0::gentoo, installed) > > > >
[gentoo-dev] Package up for grabs due to the retirement of anarchy@
Hi, The following package is now looking for a new home: app-text/openlp It has no bugs reported, and is at the newest version available upstream. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Tue, 29 Oct 2019 12:27:49 -0500 William Hubbs wrote: > No, I'm just saying this: > > We don't know that there is a portage bug from what I'm reading in this > thread. We are talking about possible bugs, but a possible bug isn't a bug. > If there is an issue cite it otherwise move on. > > --with-bdeps=y is the default for a good reason as far as I am aware. > > William It only took a 3 days, but today, I'm helping a user who has a massive upgrade problem. Among it, is this gem of a "conflict" dev-python/setuptools:0 (dev-python/setuptools-41.1.0:0/0::gentoo, ebuild scheduled for merge) pulled in by dev-python/setuptools[python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-util/meson-0.51.2:0/0::gentoo, ebuild scheduled for merge) dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/certifi-2019.6.16:0/0::gentoo, ebuild scheduled for merge) (dev-python/setuptools-20.6.7:0/0::gentoo, installed) pulled in by dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (net-misc/youtube-dl-2016.09.19:0/0::gentoo, installed) dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/jinja-2.8:0/0::gentoo, installed) dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/numpy-1.10.4:0/0::gentoo, installed) dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/certifi-2015.11.20:0/0::gentoo, installed)
