Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On 27/10/19 00:55, William Hubbs wrote: > On Sun, Oct 27, 2019 at 12:14:59AM +0100, Michael Everitt wrote: >> On 26/10/19 23:35, William Hubbs wrote: >>> On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: > On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > >> On Fri, 25 Oct 2019 15:03:39 -0700 >> Georgy Yakovlev wrote: >> >>> not used anymore >>> >>> Closes: https://bugs.gentoo.org/695698 >>> Signed-off-by: Georgy Yakovlev >> Its likely this removal will cause the same kinds of problems faced by >> the recent virtual/pam removal, just its more insidious, as the >> dependency on the virtual is hidden away inside an eclass. >> >> But this still means that anything users have already installed will >> still depend on this, and without --changed-deps=y, it will break >> portage's resolution of anything currently installed using this crate. >> >> You can work-around this by -r1 bumping everything that used this >> eclass but this just goes to show why there's policy against >> eclasses changing the dependencies of their consumers without any >> consumer involvement. >> > In most if not all cases, this is just a build-time dependency. Do we > really have all these problems for build-time only dependencies? > Yes. Because of --with-bdeps. >>> I disagree, build-time dependencies can change in place because they >>> only affect the build. The problem with virtual/pam was that it was a >>> runtime dependency as well. >>> >>> William >> The problem is that portage defaults to --with-bdeps=y, so any emerging of >> packages now triggers anything that has a build-dep change, unless, as >> previously stated, you exclude that case or change the defaults. > Sure, but rebuild changes are exactly what you would want. that's how > software written in go gets rebuilt for example, which is exactly what > you want when go is upgraded. > > I agree that some rebuilds might be unnecessary, but if you don't like > compiling/building software Gentoo isn't for you. > > William > There's a subtle difference between compiling for compiling's sake, and compiling with good reason .. especially for those who don't have copious quantities of free cpu resources at their disposal 24/7/365 ... just sayin' ... And not everyone is using rust, go, java and systemd as their prime movers, even if you are .. *shudders* signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sun, Oct 27, 2019 at 12:14:59AM +0100, Michael Everitt wrote: > On 26/10/19 23:35, William Hubbs wrote: > > On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: > >> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: > >>> On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > >>> > On Fri, 25 Oct 2019 15:03:39 -0700 > Georgy Yakovlev wrote: > > > not used anymore > > > > Closes: https://bugs.gentoo.org/695698 > > Signed-off-by: Georgy Yakovlev > Its likely this removal will cause the same kinds of problems faced by > the recent virtual/pam removal, just its more insidious, as the > dependency on the virtual is hidden away inside an eclass. > > But this still means that anything users have already installed will > still depend on this, and without --changed-deps=y, it will break > portage's resolution of anything currently installed using this crate. > > You can work-around this by -r1 bumping everything that used this > eclass but this just goes to show why there's policy against > eclasses changing the dependencies of their consumers without any > consumer involvement. > > >>> In most if not all cases, this is just a build-time dependency. Do we > >>> really have all these problems for build-time only dependencies? > >>> > >> Yes. Because of --with-bdeps. > > I disagree, build-time dependencies can change in place because they > > only affect the build. The problem with virtual/pam was that it was a > > runtime dependency as well. > > > > William > The problem is that portage defaults to --with-bdeps=y, so any emerging of > packages now triggers anything that has a build-dep change, unless, as > previously stated, you exclude that case or change the defaults. Sure, but rebuild changes are exactly what you would want. that's how software written in go gets rebuilt for example, which is exactly what you want when go is upgraded. I agree that some rebuilds might be unnecessary, but if you don't like compiling/building software Gentoo isn't for you. William signature.asc Description: Digital signature
[gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On 26/10/19 23:35, William Hubbs wrote: > On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: >> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: >>> On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: >>> On Fri, 25 Oct 2019 15:03:39 -0700 Georgy Yakovlev wrote: > not used anymore > > Closes: https://bugs.gentoo.org/695698 > Signed-off-by: Georgy Yakovlev Its likely this removal will cause the same kinds of problems faced by the recent virtual/pam removal, just its more insidious, as the dependency on the virtual is hidden away inside an eclass. But this still means that anything users have already installed will still depend on this, and without --changed-deps=y, it will break portage's resolution of anything currently installed using this crate. You can work-around this by -r1 bumping everything that used this eclass but this just goes to show why there's policy against eclasses changing the dependencies of their consumers without any consumer involvement. >>> In most if not all cases, this is just a build-time dependency. Do we >>> really have all these problems for build-time only dependencies? >>> >> Yes. Because of --with-bdeps. > I disagree, build-time dependencies can change in place because they > only affect the build. The problem with virtual/pam was that it was a > runtime dependency as well. > > William The problem is that portage defaults to --with-bdeps=y, so any emerging of packages now triggers anything that has a build-dep change, unless, as previously stated, you exclude that case or change the defaults. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: > On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: > > On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > > > > > On Fri, 25 Oct 2019 15:03:39 -0700 > > > Georgy Yakovlev wrote: > > > > > > > not used anymore > > > > > > > > Closes: https://bugs.gentoo.org/695698 > > > > Signed-off-by: Georgy Yakovlev > > > > > > Its likely this removal will cause the same kinds of problems faced by > > > the recent virtual/pam removal, just its more insidious, as the > > > dependency on the virtual is hidden away inside an eclass. > > > > > > But this still means that anything users have already installed will > > > still depend on this, and without --changed-deps=y, it will break > > > portage's resolution of anything currently installed using this crate. > > > > > > You can work-around this by -r1 bumping everything that used this > > > eclass but this just goes to show why there's policy against > > > eclasses changing the dependencies of their consumers without any > > > consumer involvement. > > > > > > > In most if not all cases, this is just a build-time dependency. Do we > > really have all these problems for build-time only dependencies? > > > > Yes. Because of --with-bdeps. I disagree, build-time dependencies can change in place because they only affect the build. The problem with virtual/pam was that it was a runtime dependency as well. William signature.asc Description: Digital signature
[gentoo-dev] Re: [RFC] News Item v2: sys-fs/cryfs-0.10.2 update
Title: sys-fs/cryfs-0.10.2 update Author: Andreas Sturmlechner Content-Type: text/plain Posted: 2019-10-26 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: https://bugs.gentoo.org/690324 [2] https://github.com/cryfs/cryfs/releases/tag/0.10.1 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Should the bot add PRs directly to TRACKER tickets?
Hi, I don't understand your mail or call to action, sorry :) The bot looks for GLEP 66 tags using simple regex. The only purpose of the bot is to link found contribution (in this case a pull request) to bugs on b.g.o to inform assignee about contribution which happened somewhere else in case assignee isn't using/following GitHub for example. That's all. Bot doesn't understand bug type and it would be overkill to make bot understand bugs. In the example bug, https://bugs.gentoo.org/683184, the problem was that no individual bug per package was created. So people changing packages to address the issue raised in tracker bug used that bug as reference. In other words: The initial failure was that no individual bugs per affected package was created... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] News Item: sys-fs/cryfs-0.10.2 update
Title: sys-fs/cryfs-0.10.2 update Author: Andreas Sturmlechner Content-Type: text/plain Posted: 2019-10-26 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =dev-libs/boost-1.65.1 Which means this update is going to be part of a bigger system update as typically many boost consumers need to be rebuilt. [1] https://github.com/cryfs/cryfs/releases/tag/0.10.1 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: media-video/minitube
# Andreas Sturmlechner (2019-10-26) # Version in Gentoo is years old, does not work, no one stepped up # to maintain it. Package needs Google API key to actually work. # Removal in 30 days. Bug #608334 media-video/minitube
[gentoo-dev] Last rites: kde-misc/systemd-kcm
# Andreas Sturmlechner (2019-10-24) # Collides with kde-apps/systemsettings, unmaintained upstream. # Use app-admin/systemdgenie instead. Removal in 30 days. Bug #698448 kde-misc/systemd-kcm
[gentoo-dev] Last rites: app-office/ooextras
# Andreas Sturmlechner (2019-10-20) # Full of ancient StarOffice era templates, last updated in 2006. # Removal in 30 days. Bug #697400 app-office/ooextras
Re: [gentoo-dev] RFC: Should the bot add PRs directly to TRACKER tickets?
On Sat, 26 Oct 2019 14:24:22 +0200 Jonas Stein wrote: > Here is an example: > https://bugs.gentoo.org/683184 > In this case it is still quite tidy, but other TRACKERS will become > unreadable by that. I think in that case the PR bot should tell people: - Find / Open the relevant bug - Link to that instead - Perform the dance required for the PR bot to recheck things. And otherwise reject citing a tracker as a close/bug source in a PR. pgpPbRs6V4aqo.pgp Description: OpenPGP digital signature
[gentoo-dev] RFC: Should the bot add PRs directly to TRACKER tickets?
Hi, sometimes there are PRs assigned to a TRACKER. On the one hand it makes sense to reduce the work of creating a separate ticket per package. But on the other hand the TRACKER ticket will get chaotic and noisy. It will also happen some day that someone adds Closes: $TRACKER_TICKET We would not add patches for a specific package to a TRACKER too, but to a separate ticket, which is linked to the TRACKER. Any good ideas? Here is an example: https://bugs.gentoo.org/683184 In this case it is still quite tidy, but other TRACKERS will become unreadable by that. -- Best, Jonas
[gentoo-dev] Last rites: media-fonts/vc-fonts
# Michał Górny (2019-10-26) # Incorrect LICENSE entry, and no clear license information to be found. # Homepage gone, and source of some of the files unknown. # Removal in 30 days. Bug #698050. media-fonts/vc-fonts -- 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 Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: > On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > > > On Fri, 25 Oct 2019 15:03:39 -0700 > > Georgy Yakovlev wrote: > > > > > not used anymore > > > > > > Closes: https://bugs.gentoo.org/695698 > > > Signed-off-by: Georgy Yakovlev > > > > Its likely this removal will cause the same kinds of problems faced by > > the recent virtual/pam removal, just its more insidious, as the > > dependency on the virtual is hidden away inside an eclass. > > > > But this still means that anything users have already installed will > > still depend on this, and without --changed-deps=y, it will break > > portage's resolution of anything currently installed using this crate. > > > > You can work-around this by -r1 bumping everything that used this > > eclass but this just goes to show why there's policy against > > eclasses changing the dependencies of their consumers without any > > consumer involvement. > > > > In most if not all cases, this is just a build-time dependency. Do we > really have all these problems for build-time only dependencies? > Yes. Because of --with-bdeps. -- 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 Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: > On Fri, 25 Oct 2019 15:03:39 -0700 > Georgy Yakovlev wrote: > > > not used anymore > > > > Closes: https://bugs.gentoo.org/695698 > > Signed-off-by: Georgy Yakovlev > > > Its likely this removal will cause the same kinds of problems faced by > the recent virtual/pam removal, just its more insidious, as the > dependency on the virtual is hidden away inside an eclass. > > But this still means that anything users have already installed will > still depend on this, and without --changed-deps=y, it will break > portage's resolution of anything currently installed using this crate. > > You can work-around this by -r1 bumping everything that used this > eclass but this just goes to show why there's policy against > eclasses changing the dependencies of their consumers without any > consumer involvement. > In most if not all cases, this is just a build-time dependency. Do we really have all these problems for build-time only dependencies? >
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sat, 26 Oct 2019 08:34:50 +0200 Francesco Riosa wrote: > So basically the eclass should be bumped, with the old one deprecated? I don't think rev-bumping the eclass is a useful way to fix this either. It could work, but I suspect it just expands the problem slightly. pgp4WzprN2xLh.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
Il giorno sab 26 ott 2019 alle ore 06:24 Michael Everitt ha scritto: > On 26/10/19 04:59, Kent Fredric wrote: > > On Fri, 25 Oct 2019 15:03:39 -0700 > > Georgy Yakovlev wrote: > > > >> not used anymore > >> > >> Closes: https://bugs.gentoo.org/695698 > >> Signed-off-by: Georgy Yakovlev > > > > Its likely this removal will cause the same kinds of problems faced by > > the recent virtual/pam removal, just its more insidious, as the > > dependency on the virtual is hidden away inside an eclass. > > > > But this still means that anything users have already installed will > > still depend on this, and without --changed-deps=y, it will break > > portage's resolution of anything currently installed using this crate. > > > > You can work-around this by -r1 bumping everything that used this > > eclass but this just goes to show why there's policy against > > eclasses changing the dependencies of their consumers without any > > consumer involvement. > tl;dr - play with fire .. you're gonna get burned .. :] > > Good luck with the core aim .. there is probably a slow-and-steady approach > that will win through .. > > So basically the eclass should be bumped, with the old one deprecated?
