CVS (was: GCC 10 available for testing etc. in -current.)
At Mon, 19 Apr 2021 11:56:59 +0200, Reinoud Zandijk wrote: Subject: Re: GCC 10 available for testing etc. in -current. > > Same for me; I've never had trouble with CVS trees and they always just work > and update fine. > > Hg on the otherhand I had to delete and recheckout my hg tree *again*; i > had interrupted hg during a merge and oh boy; it was completely shot and > thought i had tons of local changes that all conflicted; a whopping 500+ files > or so, thus resorting to just nuking it and rechecking it out. This never > happened to my CVS tree. > > So, no, hg is not mature enough yet to switch over to and don't get me started > on git! I don't think all of those problems can be blamed on Hg (or Git). A very big part of the problem is what Joerg said: "when someone messes up history, that's a non-linear update." I.e. the conversion from CVS to Hg and/or Git sometimes has to rewrite history to undo a mess-up and clean-up in the CVS repo, and those are things that really mess up Git and Hg users. And NetBSD developers seem to have a penchant for messing up/in the repository on a regular basis. There were two such events in the past week or two alone. This very update to GCC 10 was involved in one of them. These same shenanigans also affect CVS, but usually in less ugly ways, In both cases it's often a matter of timing If you do your CVS update in between one of these "messes" being made and being cleaned then you'll encounter some problems, but if not then you're often none the wiser to what happened. For the same reason different people will have different experiences with the Hg and Git clones because they do their updates at different times. If you don't clone or fetch history that then has to be rewritten then you won't know that history was rewritten. The real solution of course is to stop and _prevent_ history from being rewritten, ever. It doesn't matter if this is in CVS, Git, Hg, Fossil, or something else. It's just easier to prevent in Git, and Hg, etc. Personally I've been using rsync to fetch the whole CVS repository daily for years now, and then I update local checkouts, some automatically and some by hand. It's very efficient, and it gives me a local copy of all the repository history. It's not quite as nice as a git clone, since I can't reliably and efficiently and easily keep my own local branches and do local commits (e.g. in the way you can do very easily and efficiently with Git), but it is still very much better than any other current alternative, including the current Hg and Git and Fossil conversions. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpPcTPIbcOuN.pgp Description: OpenPGP Digital Signature
Re: GCC 10 available for testing etc. in -current.
On Mon, Apr 19, 2021 at 04:39:45PM +1200, Lloyd Parkes wrote: > Someone moved the bookmark called "@" in a way that Mercurial wasn't willing > to blindly propagate into my local, central copy of the Mercurial src > repository. This could easily have been done by part of the CVS to Mercurial > tracking that is done rather than by a real person. It is always set to the head of the current "trunk" fork, but when someone messes up history, that's a non-linear update. In that case mercurial renames it. It normally only affects new clones/shares as it is otherwise unused. > Mercurial then left the original "@" bookmark in place in my central copy of > the src repository, created a bookmark called "@default" to track the > upstream "@", and finally issued me a warning about a "divergent bookmark". > I didn't know what that meant or that I was using the "@" bookmark. It turns > out that "@" is the default thing to checkout if such a bookmark exists. Correct. > The fix is for me to explicitly checkout the branch "trunk" when I don't > want a specific branch. And also to keep an eye on messages when I update my > local, central copy of the Mercurial src repository. Also reasonable. Joerg
Re: GCC 10 available for testing etc. in -current.
On Mon, Apr 19, 2021 at 04:41:32AM -, Michael van Elst wrote: > ll...@must-have-coffee.gen.nz (Lloyd Parkes) writes: > > >On 17/04/21 6:30 pm, Lloyd Parkes wrote: > >> I am using the Mercurial repository at https://anonhg.NetBSD.org/src > >> for fetching the source code because it's nice and quick > > >I've been running CVS for more than two hours now, and it has terminated > >with a broken connection 10 (make that 11) times so far. > > > The funny thing is that it works the opposite way for me. CVS checkout > works without problems and Mercurial checkouts almost always time out > or aren't succesful. > > Should tell you that the software is only a small part of the problem. Same for me; I've never had trouble with CVS trees and they always just work and update fine. Hg on the otherhand I had to delete and recheckout my hg tree *again*; i had interrupted hg during a merge and oh boy; it was completely shot and thought i had tons of local changes that all conflicted; a whopping 500+ files or so, thus resorting to just nuking it and rechecking it out. This never happened to my CVS tree. So, no, hg is not mature enough yet to switch over to and don't get me started on git! Reinoud signature.asc Description: PGP signature
Re: GCC 10 available for testing etc. in -current.
ll...@must-have-coffee.gen.nz (Lloyd Parkes) writes: >On 17/04/21 6:30 pm, Lloyd Parkes wrote: >> I am using the Mercurial repository at https://anonhg.NetBSD.org/src >> for fetching the source code because it's nice and quick >I've been running CVS for more than two hours now, and it has terminated >with a broken connection 10 (make that 11) times so far. The funny thing is that it works the opposite way for me. CVS checkout works without problems and Mercurial checkouts almost always time out or aren't succesful. Should tell you that the software is only a small part of the problem.
Re: GCC 10 available for testing etc. in -current.
On 19/04/21 10:21 am, Lloyd Parkes wrote: On 17/04/21 6:30 pm, Lloyd Parkes wrote: I am using the Mercurial repository at https://anonhg.NetBSD.org/src for fetching the source code because it's nice and quick So I'm now downloading the source code through CVS instead of Mercurial because nobody else seems to be having the same problems that I'm having building with GCC 10. I found the answer. Someone moved the bookmark called "@" in a way that Mercurial wasn't willing to blindly propagate into my local, central copy of the Mercurial src repository. This could easily have been done by part of the CVS to Mercurial tracking that is done rather than by a real person. Mercurial then left the original "@" bookmark in place in my central copy of the src repository, created a bookmark called "@default" to track the upstream "@", and finally issued me a warning about a "divergent bookmark". I didn't know what that meant or that I was using the "@" bookmark. It turns out that "@" is the default thing to checkout if such a bookmark exists. Of course, when cloning to a build box Mercurial just cloned my central repository without needing to warn me about divergent bookmarks (there was no divergence at this step) and I was unknowingly using an old version of the source tree with no possibility of it ever getting updated. The fix is for me to explicitly checkout the branch "trunk" when I don't want a specific branch. And also to keep an eye on messages when I update my local, central copy of the Mercurial src repository. Now I can get back to building things with GCC 10 and then wondering how to get all the hardware booted. Cheers, Lloyd
Re: GCC 10 available for testing etc. in -current.
> On 17/04/21 6:30 pm, Lloyd Parkes wrote: > > I am using the Mercurial repository at https://anonhg.NetBSD.org/src for > > fetching the source code because it's nice and quick > So I'm now downloading the source code through CVS instead of Mercurial > because nobody else seems to be having the same problems that I'm having > building with GCC 10. > > I've been running CVS for more than two hours now, and it has terminated with > a broken connection 10 (make that 11) times so far. I'm rerunning with "cvs > update", so I am making progress. Even so, CVS has only just got to paths > starting with the letter "d". > As someone who has used CVS for almost 30 years now, I'm happy to say that CVS > just needs to be retired. Have a flag day, check that the content in the HEADs > all match up and then make CVS read-only. I know many of us are old and > grumpy, but that model T isn't our every day drive any more. > > Cheers, > Lloyd > p.s. The code in Mercurial seems to match what I can browse on the FTP site, > so I really am at a loss as to why I can't build, so I am checking everything. I too would like to see CVS retired. There is a long wait for cvs update to start, and longer wait to return to command prompt after the update download is finished. Svn has lesser such delays; git is much faster. FreeBSD switched doc and src trees from svn to git, and more recently switched the ports tree to git. Tom
Re: GCC 10 available for testing etc. in -current.
On 17/04/21 6:30 pm, Lloyd Parkes wrote: I am using the Mercurial repository at https://anonhg.NetBSD.org/src for fetching the source code because it's nice and quick So I'm now downloading the source code through CVS instead of Mercurial because nobody else seems to be having the same problems that I'm having building with GCC 10. I've been running CVS for more than two hours now, and it has terminated with a broken connection 10 (make that 11) times so far. I'm rerunning with "cvs update", so I am making progress. Even so, CVS has only just got to paths starting with the letter "d". As someone who has used CVS for almost 30 years now, I'm happy to say that CVS just needs to be retired. Have a flag day, check that the content in the HEADs all match up and then make CVS read-only. I know many of us are old and grumpy, but that model T isn't our every day drive any more. Cheers, Lloyd p.s. The code in Mercurial seems to match what I can browse on the FTP site, so I really am at a loss as to why I can't build, so I am checking everything.
re: GCC 10 available for testing etc. in -current.
> > - build.sh with no -u (update), and set -V HAVE-GCC=10 as a > >option. this ensures that everything is actually rebuilt > >with the new compiler. > > I'm guessing that should be "-V HAVE_GCC=10", but even so I just can't yup! > get this to build. I always get the message "cc: error: CET_HOST_FLAGS@: > No such file or directory". I'm going to see if I can find where this > has come from. Does it ring any bells for anyone? this is from GDB: gdb/dist/libiberty/Makefile.in:116: @CET_HOST_FLAGS@ did you try clean'ing the gdb objdirs? (both tools and the build one.) i think i recall a while back this was a problem when GDB was updated. .mrg.
Re: GCC 10 available for testing etc. in -current.
On 15/04/21 2:19 pm, matthew green wrote: the steps are fairly simple: - update -currnet srcs - build.sh with no -u (update), and set -V HAVE-GCC=10 as a option. this ensures that everything is actually rebuilt with the new compiler. I'm guessing that should be "-V HAVE_GCC=10", but even so I just can't get this to build. I always get the message "cc: error: CET_HOST_FLAGS@: No such file or directory". I'm going to see if I can find where this has come from. Does it ring any bells for anyone? I am using the Mercurial repository at https://anonhg.NetBSD.org/srcfor fetching the source code because it's nice and quick and I'm building on a Linux Xeon I had lying around because it's also nice and quick. I'm trying to download the -current source tarballs now, but I'm getting 150KB/s and so I'm only up to external.tar.gz. I have also just deployed NetBSD current to another Xeon I have lying around and maybe the deployment will have actually worked. I'll speculate that something is using the native sed/awk instead of the the one from tools. Cheers, Lloyd
GCC 10 available for testing etc. in -current.
hi folks. (please reply privately to this spams-many-lists message, and i will keep src/external/gpl3/gcc/README.gcc10 updated with the latest status.) i've just commited the final parts that make most platforms build (and many run) with GCC 10 as the system compiler. i've tested these systems: - amd64 - sparc (qemu) - sparc64 - shark - evbarmv7hf (cubietruck) - i386 (has a signal delivery issue, but that seems to have been introduced last year, however, things seem to be equally as functional/broken.) - ia64 (ski boots as far as before) - mipsel (malta gxemul) - mips64 (either big or little endian) - sh3-el (landisk gxemul) - vax (simh) so i'm after testing for these targets: - alpha - hppa - powerpc - sh3-eb - arm32-eb - mipseb - m68k there are still issues for these targets: - arm64 -- 'LSE' extension issues, likely needs both fixes for libgcc and kernel work - sun2 ramdisk overflows, and it's already at the limit of what can boot without crashing from lack of space - x68k 'loadbsd' program appears to pull in TLS code from libc and does not link. the steps are fairly simple: - update -currnet srcs - build.sh with no -u (update), and set -V HAVE-GCC=10 as a option. this ensures that everything is actually rebuilt with the new compiler. - install new kernel/userland and perform testing. if you can run atf that would be great, but other tests are useful too. - reply to this message with results. thanks! .mrg.
