The ebuild uses https://the.earth.li/~sgtatham/${PN}/latest/${P}.tar.gz in SRC_URI. This is correct, a long as latest=${PV} i.e. as long as the 'program version' of the ebuild is also the latest one. I wanted to merge the 0.70 version (a version which was 'latest' once, but not anymore) and got: >>> Downloading 'https://the.earth.li/~sgtatham/putty/latest/putty-0.70.tar.gz' --2020-01-12 14:29:09-- https://the.earth.li/~sgtatham/putty/latest/putty-0.70.tar.gz Resolving the.earth.li... 46.43.34.31 Connecting to the.earth.li|46.43.34.31|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://the.earth.li/~sgtatham/putty/0.73/putty-0.70.tar.gz [following] --2020-01-12 14:29:09-- https://the.earth.li/~sgtatham/putty/0.73/putty-0.70.tar.gz Reusing existing connection to the.earth.li:443. HTTP request sent, awaiting response... 404 Not Found 2020-01-12 14:29:09 ERROR 404: Not Found. !!! Couldn't download 'putty-0.70.tar.gz'. Aborting. Of course, because it tried to download https://the.earth.li/~sgtatham/putty/0.73/putty-0.70.tar.gz instead of https://the.earth.li/~sgtatham/putty/0.70/putty-0.70.tar.gz This is true for both 0.70 and the (current) 0.73 version. Reproducible: Always Steps to Reproduce: 1. Try to merge putty a second after a new version has been published upstream. 2. 3. Actual Results: The download of the package fails. Expected Results: The ebuild should not fail to download the package if its version is not currently the latest one.
(In reply to segmentation fault from comment #0) > >>> Downloading 'https://the.earth.li/~sgtatham/putty/latest/putty-0.70.tar.gz' Not sure how or why you held on to that ebuild for almost a year. commit f0cfcc44b3652f2095835be7b81020997bc03f0c Author: Jeroen Roovers <jer@gentoo.org> Date: Mon Mar 18 00:57:32 2019 +0100 net-misc/putty: Old Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Jeroen Roovers <jer@gentoo.org>
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b51f1a159226f9af3896e91a393cdd5adf1d2584 commit b51f1a159226f9af3896e91a393cdd5adf1d2584 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-01-13 03:09:03 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-01-13 03:09:48 +0000 net-misc/putty: Fix SRC_URI Package-Manager: Portage-2.3.84, Repoman-2.3.20 Closes: https://bugs.gentoo.org/705284 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-misc/putty/putty-0.73.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
(In reply to Jeroen Roovers from comment #1) > Not sure how or why you held on to that ebuild for almost a year. > :-) I decided to install putty 'just for the fun of it' one moment before I would start a complete update of my system. So the question should be rephrased as: "why you held on to that system for '1 year and 30 days' (as emerge kept on reminding me)?" - and the short answer is: Because each time I upgrade, I experience it as a *major* PITA. I have the feeling that, if I would upgrade more often, I would *never* come to do real work on my system - I actually wonder what kind of work other people do, but I take pride in saying that I *use* my system, instead of just administering it. :-) The long answer: Besides upgrades being a PITA, I set up this baby on 64 bit not by re-installing, which is the usual advice (and for a good reason), but by cross-compiling my old X86 32-bit Gentoo into AMD64. That 32-bit system, on the other side, had grown up from the old days - back in 2006... Thus, a lot of configurations had to 'stabilize'. For example, it took me time to realize that I would like to have 3D acceleration in my virtual Windows 10 inside virtualbox. But this will NOT work with nvidia-drivers, unless a) you stick to the 5.x version (the developers said that it was not a priority for VB 6.x) AND b) add CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0 to /etc/env.d/90virtualbox and then env-update && source /etc/profile before you restart virtualbox. I just found out (by deep-digging, took me a week...) a few months ago about this. Had I updated my system in-between, I would now have virtualbox 6.x - and would still be struggling with the 3D issue. That's what I mean when I say that a configuration has to 'stabilize' - you have to arrive at a set of settings that fits *your* purposes *before* you upgrade again, otherwise this becomes a 'moving target', which I try to avoid at all costs. Add to this 'user experiences' like that of GLIBC segfaulting and bringing chaos (back in the past, e.g. version 2.19-r1) and you will find comments like # DON'T EVER - EVER! - UPGRADE TO GLIBC > 2.16 - unless # you are *sure* that your system won't crash! # For example, 2.19-r1 is known to segfault! along with a line that masks all GLIBC versions higher than 2.16 in my package.mask. Now, these times (and that line) are *long* gone (resp. commented) and glibc (or other packages) have become *much* better - but the wounds have left their scars, so when I finally get a 'running system' I say to myself: DON'T TOUCH IT! WORK WITH IT! LET ITS CONFIGURATION STABILIZE! I wish things would have been better and I could give you a more positive answer - but that's not the case. So that's why I upgrade once a year or so. As a by-product, we get to identify and fix details like this one. :-) KUTGW
Here's an example why I say each Gentoo upgrade is a PITA: https://forums.gentoo.org/viewtopic-p-8409974.html#8409974
