There is a new build for sci-mathematics/gimps-28.5. As usual upstream made a bugfix release without changing version numbers, so we have to regenerate digests. This version is a release candidate, so it would be useful to have it in tree ASAP. Bug fixes as follows: 1) Test/stop does not work properly in the "memory bandwidth timing" section of benchmarking. Fixed in 28.5 build 2. 2) Prime95 only reads the first 2048 characters of a worktodo line. "Fixed" in 28.5 build 2 -- buffer increased to 16384 characters. Tomka, please do your magic. Thanks in advance.
BTW, sorry for having added the herd. That's what you get for cloning a bug.
Hmm, please tell upstream that what they are doing is stupid. I followed the distfile+digest replacement procedure. It will take a few hours before everything is in a consistent state because we mirror the old distfiles on our infrastructure.
oops
(In reply to Thomas Kahle from comment #2) > Hmm, please tell upstream that what they are doing is stupid. I have no voice in their choices. They are mostly windows-centric. > I followed the distfile+digest replacement procedure. It will take a few > hours before everything is in a consistent state because we mirror the old > distfiles on our infrastructure. Is it normal that almost 18 hours have passed and nothing changed?
(In reply to Paolo Pedroni from comment #4) > (In reply to Thomas Kahle from comment #2) > > Hmm, please tell upstream that what they are doing is stupid. > > I have no voice in their choices. They are mostly windows-centric. Just keep mentioning it while you talk to people. If they take any pride in what they do they will get annoyed eventually :) > > I followed the distfile+digest replacement procedure. It will take a few > > hours before everything is in a consistent state because we mirror the old > > distfiles on our infrastructure. > > Is it normal that almost 18 hours have passed and nothing changed? No, it should be good by now. One problem is that everybody who has downloaded the old files at some point in the past (and still has them in their distfiles directory) now has a broken manifest after the latest emerge --sync. There is no way around this. Each of those users must delete their local distfiles and redownload. Have you done this? Can you send me the md5sum of a distfile you got from the mirrors? You see, this kind of stuff happens when we replace distfiles.
(In reply to Thomas Kahle from comment #5) > (In reply to Paolo Pedroni from comment #4) > > (In reply to Thomas Kahle from comment #2) > > > Hmm, please tell upstream that what they are doing is stupid. > > > > I have no voice in their choices. They are mostly windows-centric. > > Just keep mentioning it while you talk to people. If they take any pride in > what they do they will get annoyed eventually :) It's not that they don't have pride. It's just that they don't see the POV of distributions. They expect that their users just install and run the program on their own. > > > > > I followed the distfile+digest replacement procedure. It will take a few > > > hours before everything is in a consistent state because we mirror the old > > > distfiles on our infrastructure. > > > > Is it normal that almost 18 hours have passed and nothing changed? > > No, it should be good by now. One problem is that everybody who has > downloaded the old files at some point in the past (and still has them in > their distfiles directory) now has a broken manifest after the latest emerge > --sync. There is no way around this. Each of those users must delete their > local distfiles and redownload. This I now (maybe a revbump is in order), but I just re-synced and forced a package re-emerge, deleting the old file from /usr/portage/distfiles and I still got the old one. The mirror I used was tux.rainside.sk. I ended up copying the ebuild in my local overlay and regenerating the digest with the new file in /usr/portage/distfiles. BTW, the new linux 32-bit build has been named p95v285.linux32.tar.gz again, you should fix it in the ebuild while you're at it. > > Have you done this? Can you send me the md5sum of a distfile you got from > the mirrors? > > You see, this kind of stuff happens when we replace distfiles. The md5sum of the _new_ file is ec55d99f23e451220cff2977e496c908, the md5sum of the file I get from the mirrors is 47cb33d9bd23250246db23462d03a0ac. How do I reopen a bug? ;)
(In reply to Paolo Pedroni from comment #6) > > This I now (maybe a revbump is in order), but I just re-synced and forced a > package re-emerge, deleting the old file from /usr/portage/distfiles and I > still got the old one. The mirror I used was tux.rainside.sk. Yeah, this was my error. I uploaded the outdated files again. I tried again now, please see if it worked this time. > I ended up copying the ebuild in my local overlay and regenerating the > digest with the new file in /usr/portage/distfiles. > > BTW, the new linux 32-bit build has been named p95v285.linux32.tar.gz again, > you should fix it in the ebuild while you're at it. OK, I also fixed this. A revbump makes no sense if the ebuild of the -r1 version is exactly the same like that of the -r0 version. Now, it is not anymore in this case, but it would have been in principle... This is another reason why this kind of behaviour of upstream is bad. > > > > Have you done this? Can you send me the md5sum of a distfile you got from > > the mirrors? > > > > You see, this kind of stuff happens when we replace distfiles. > > The md5sum of the _new_ file is ec55d99f23e451220cff2977e496c908, the md5sum > of the file I get from the mirrors is 47cb33d9bd23250246db23462d03a0ac. Yeah, I uploaded the old file again, don't know how. > How do I reopen a bug? ;) Change the status back to "confirmed". Sorry for the mess.
(In reply to Thomas Kahle from comment #7) > Yeah, this was my error. I uploaded the outdated files again. I tried > again now, please see if it worked this time. That's now fine. > > > I ended up copying the ebuild in my local overlay and regenerating the > > digest with the new file in /usr/portage/distfiles. > > > > BTW, the new linux 32-bit build has been named p95v285.linux32.tar.gz again, > > you should fix it in the ebuild while you're at it. > > OK, I also fixed this. A revbump makes no sense if the ebuild of the -r1 > version is exactly the same like that of the -r0 version. Now, it is not > anymore in this case, but it would have been in principle... This is > another reason why this kind of behaviour of upstream is bad. I understand this, but I've seen it done for other packages if there was a real need to make people update. Maybe if the bug fixes in the new build were somewhat more substantial it could be done, couldn't it? > Sorry for the mess. Not a problem. We have a saying in Italy that can be roughly translated to: "Only those who do nothing never make any mistake".
