sandra ~ # emerge -avDuNt world These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild R ~] net-misc/chrome-remote-desktop-77.0.3865.32::gentoo USE="-xrandr" PYTHON_SINGLE_TARGET="python2_7%*" PYTHON_TARGETS="python2_7" 34,888 KiB Total: 1 package (1 reinstall), Size of downloads: 34,888 KiB Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-misc/chrome-remote-desktop-77.0.3865.32::gentoo >>> Downloading 'https://dl.google.com/linux/chrome-remote-desktop/deb/pool/main/c/chrome-remote-desktop/chrome-remote-desktop_77.0.3865.32_amd64.deb' --2020-01-04 13:25:22-- https://dl.google.com/linux/chrome-remote-desktop/deb/pool/main/c/chrome-remote-desktop/chrome-remote-desktop_77.0.3865.32_amd64.deb Resolving dl.google.com... 172.217.10.78, 2607:f8b0:4006:803::200e Connecting to dl.google.com|172.217.10.78|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-01-04 13:25:22 ERROR 404: Not Found. !!! Couldn't download 'chrome-remote-desktop_77.0.3865.32_amd64.deb'. Aborting. * Fetch failed for 'net-misc/chrome-remote-desktop-77.0.3865.32', Log file: * '/var/tmp/portage/net-misc/chrome-remote-desktop-77.0.3865.32/temp/build.log' >>> Failed to emerge net-misc/chrome-remote-desktop-77.0.3865.32, Log file: >>> '/var/tmp/portage/net-misc/chrome-remote-desktop-77.0.3865.32/temp/build.log' * Messages for package net-misc/chrome-remote-desktop-77.0.3865.32: * Fetch failed for 'net-misc/chrome-remote-desktop-77.0.3865.32', Log file: * '/var/tmp/portage/net-misc/chrome-remote-desktop-77.0.3865.32/temp/build.log' sandra ~ #
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03d2db466276280ee24edd420147921c496dd493 commit 03d2db466276280ee24edd420147921c496dd493 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-01-04 18:42:15 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-01-04 18:45:29 +0000 profiles: mask net-misc/chrome-remote-desktop for removal Bug: https://bugs.gentoo.org/704782 Signed-off-by: Mike Gilbert <floppym@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+)
I'm not against removing Google binaries from portage, but would like to inform that https://dl.google.com/linux/chrome-remote-desktop/deb/pool/main/c/chrome-remote-desktop/chrome-remote-desktop_79.0.3945.10_amd64.deb works. That means that renaming the ebuild to chrome-remote-desktop-79.0.3945.10.ebuild also works. In addition, https://dl.google.com/linux/direct/chrome-remote-desktop_current_amd64.deb seems to point to latest current.
The package needs a maintainer, even that only amounts to renaming the ebuild once a month or so.
can the package simply be the latest version (9999-style ebuild) to avoid constant version bumping?
The product is discontinued on google store There a download attempt retransfers to: https://remotedesktop.google.com/ A web based version of it. It requires a chrome account to use.
It asks you to download a .deb to install.
the crd client is all web now, but to actually be the server (the machine that is being remoted into), this package should be supported.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8bb01fb1de3bf1e528158e3cb9deacb083c3d55d commit 8bb01fb1de3bf1e528158e3cb9deacb083c3d55d Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2020-02-01 04:16:19 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2020-02-01 04:17:16 +0000 net-misc/chrome-remote-desktop: version bump to 80.0.3987.18 Closes: https://bugs.gentoo.org/704782 Signed-off-by: Mike Frysinger <vapier@gentoo.org> net-misc/chrome-remote-desktop/Manifest | 1 + .../chrome-remote-desktop-80.0.3987.18.ebuild | 137 +++++++++++++++++++++ 2 files changed, 138 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e38ce06eabfb6f137af90945919a7b9fc4dcb415 commit e38ce06eabfb6f137af90945919a7b9fc4dcb415 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2020-02-01 01:20:34 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2020-02-01 04:17:15 +0000 package.mask: unmask chrome-remote-desktop Closes: https://bugs.gentoo.org/704782 Signed-off-by: Mike Frysinger <vapier@gentoo.org> profiles/package.mask | 6 ------ 1 file changed, 6 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c02aee64627c7a0d17b7f1b06035886021f711db commit c02aee64627c7a0d17b7f1b06035886021f711db Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2020-02-01 01:20:34 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2020-02-03 15:24:45 +0000 package.mask: unmask chrome-remote-desktop Package has no known bugs. Closes: https://bugs.gentoo.org/704782 Signed-off-by: Mike Frysinger <vapier@gentoo.org> profiles/package.mask | 6 ------ 1 file changed, 6 deletions(-)
hey... floppym ended up deleting it: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c5c9e0d4dc94f19ba7b00b918a3c65818c23e0e4 Mike Frysinger <vapier@gentoo.org> did the version bump? shouldn't this package stay?
*** Bug 708598 has been marked as a duplicate of this bug. ***
(In reply to razamatan from comment #10) > hey... floppym ended up deleting it: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=c5c9e0d4dc94f19ba7b00b918a3c65818c23e0e4 > > Mike Frysinger <vapier@gentoo.org> did the version bump? shouldn't this > package stay? https://projects.gentoo.org/qa/policy-guide/maintainer.html#new-packages-without-a-maintainer Without a dedicated maintainer, the problem why it was removed in the first place just repeats.
...and the removal is why I no longer run Gentoo. If the default action for a package that I use (and filed the bug on) but don't have time to maintain is for it to be dropped by the distro... then I have to evaluate my time using the distro. I don't have time for this mess... or even Gentoo anymore. I've jumped distros to Xubuntu. I'll keep an eye on the bug, but this is a sorry state of affairs. Were I still running Gentoo, I would say "REOPENED UNRESOLVED".
You stumbled into a weird situation with a package that had a barely active and likely disgruntled maintainer. It’s not the “default action” in the general case.
(In reply to Joonas Niilola from comment #12) > (In reply to razamatan from comment #10) > Without a dedicated maintainer, the problem why it was removed in the first > place just repeats. If you can make that decision, you can bump the package. Instead, now you've made it a problem for everyone forever. That's better? (In reply to Mike Gilbert from comment #14) > You stumbled into a weird situation with a package that had a barely active > and likely disgruntled maintainer. It’s not the “default action” in the > general case. Then maintain it. You're a developer. This "proxy maintainers" nonsense doesn't work. If Gentoo developers keep requiring less experienced users to dedicate themselves to package maintainership indefinitely in order to submit a simple bugfix and see it accepted, then you're going to drive those users away. If you're a badged member of the Gentoo project, you're the maintainer. Take what you're given and bump the package. You know what the solution is. It was trivial. It was given to you. It was implemented. Then you *removed* it. That is an example of bad policy destroying its own objectives. The previous commenter is quite right. Dropping packages instead of fixing them has been Gentoo's response to bug reports increasingly often in recent years; it's pointlessly bureaucratic, damaging to the distribution, disrespectful of the time your users spend qualifying and reporting bugs, and ultimately ineffective at helping anyone. I'm going to take the ebuild you were given, put it in my local overlay, maintain it for myself, and not give it back to the project. This is what you get.
(In reply to Matthew "Archer" Vaughn from comment #15) As far as I know, no active Gentoo developers actually want to maintain this. The package needs an active maintainer or this problem will recur roughly every 6 weeks as Google publishes new versions. It's not a matter of accepting a one-time bug fix. Maintaining this in an overlay is a reasonable solution here. You might even publish said overlay if you want other people to benefit from it.
