Re: netbsd 9 upgrade experience
On Sat, Jun 20, 2020 at 08:13:42PM -0400, Greg Troxel wrote: > This is the easy one. postinstall expects sources. You can use the -s > option. I unpack etc.tgz and xetc.tgz to /usr/netbsd-etc and pass that. > Amazingly, this is even in the manual, but it doesn't really say that > you need a plan for -s. Back in the days when sysinst started running postinstall after updates there were no cases when postinstall needed manual intervention. We need to deal with this in sysinst somehow(tm). The black xdm fields will go away once postinstall fixed "x11" properly (it is caused by missing resource entries in the xdm config files). Martin
Re: CDN readme out of date
On Sat, 20 Jun 2020, Greg Troxel wrote: Perhaps it should say they are updated t.i.w. Troublemaker. -- "No matter how big the problem is, you can always run away from it." Dom Irrera
Re: netbsd 9 upgrade experience
r0ller writes: > 1) After system upgrade done via usb installer I got the message that > postinstall fixes failed for: fontconfig gid x11. When I tried to > execute postinstall afterwards, I got the error message that /usr/src > is not a directory. This is the easy one. postinstall expects sources. You can use the -s option. I unpack etc.tgz and xetc.tgz to /usr/netbsd-etc and pass that. Amazingly, this is even in the manual, but it doesn't really say that you need a plan for -s.
Re: Checking out src with Mercurial
On June 20, 2020 6:06:33 PM Johnny Billquist wrote: > On 2020-06-20 18:52, Dave McGuire wrote: >> On 6/20/20 5:01 AM, Holm Tiffe wrote: >>> Great. ..and how many VAXen do have 128Mbytes of RAM? >> >>We have several VAXen at LSSM that have 128MB of RAM or more. One of >> them, a VAX-7000, has 1.5GB. :) > > So do we at Update. But let's face it. It's a very small minority of > machines (VAXen) that can have that much memory. And I don't think > anything desk sized ever could. We'll I certainly didn't suggest that it was the norm. ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Re: Pre-seeded Mercurial-Clone available?
Hello Greg, Am 20.06.2020 um 21:10 schrieb Greg A. Woods: Did you actually try doing what I said worked for me in the other thread? First fetch the initial "bundle", then unbundle it into your local filesystem, then do a checkout, then set up the upstream pointer, and finally do a pull to update from there. The bundle _is_ the initial seed for a repository, and disconnecting the fetching of the bundle from the unbundling prevents the upstream server from disconnecting at _any_ inopportune time. I have now made up for it and will try it now. Thanks for the tip and the explainations - this reads exactly what I was looking for. Best wishes Matthias
Re: Checking out src with Mercurial
On 2020-06-20 18:52, Dave McGuire wrote: On 6/20/20 5:01 AM, Holm Tiffe wrote: Great. ..and how many VAXen do have 128Mbytes of RAM? We have several VAXen at LSSM that have 128MB of RAM or more. One of them, a VAX-7000, has 1.5GB. :) So do we at Update. But let's face it. It's a very small minority of machines (VAXen) that can have that much memory. And I don't think anything desk sized ever could. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: cvs better than git?
On Sat, Jun 20, 2020 at 2:09 PM Gua Chung Lim wrote: > > * Riccardo Mottola wrote: > > Mercurial? no go: python, please not. Just for this reason, maybe it would > > be perfect if written in equivalent C/C++! And please, don't cite me > > "rust"... even worse. Core things should be written with core tools. > > > > Maybe some sort of "anonymous checkout" of mercurial exists written in C? > I will emphasize on the language being used. > I agree with you with exception of C++. > Cores of all Unix-liked systems should be coded in only C and nothing else. > Previously I used FreeBSD with inclusion of cvsup out of the box. > IIRC, cvsup was coded in Modular-3, which was acceptable for historical > reason. > FreeBSD then offerred the alternative named csup, > which was cvsup-equivalent in C version. I was very glad. > But csup had too short life. FreeBSD then switched to svn a year later. > Whether or not svn is good, csup developers' hearts were already broken. > But svn is still coded in C. It is still acceptable. > Git was born outside BSD land. But it is still coded in C. > Linux is also considered a Unix-liked operating system. > cvs in NetBSD is also coded in C. (But it is much criticized.) > I don't see any good reasons to implement Hg in rust or python. > Please do not say C is hard to implement and maintain the code. > Kernels for nearly all operating systems in the world were coded in C. > How can all developers implement or maintain the code? > C is very well mature, It has been around here for many decades. > And it is much more portable than any other languages including C++, > which has too many standards. > And C++ committee doesn't even care backward compatability. > So please adhere with only C, like what POSIX does. C++ has become a mess. It no longer feels like a superset of C. I'd settle for something like embedded C++ 03 with exceptions. That is mostly C with objects, and you get the automatic cleanup. I'd like to have lambda's and auto, but then we start getting the extra baggage and bloat of C++ 11 and above. Embedded C++ is usually a good choice. Consider, the Mars rovers are powered by PowerPC chips and the OS and system software is written in embedded C++. Jeff
Re: cvs better than git?
* Riccardo Mottola wrote: > Mercurial? no go: python, please not. Just for this reason, maybe it would > be perfect if written in equivalent C/C++! And please, don't cite me > "rust"... even worse. Core things should be written with core tools. > > Maybe some sort of "anonymous checkout" of mercurial exists written in C? I will emphasize on the language being used. I agree with you with exception of C++. Cores of all Unix-liked systems should be coded in only C and nothing else. Previously I used FreeBSD with inclusion of cvsup out of the box. IIRC, cvsup was coded in Modular-3, which was acceptable for historical reason. FreeBSD then offerred the alternative named csup, which was cvsup-equivalent in C version. I was very glad. But csup had too short life. FreeBSD then switched to svn a year later. Whether or not svn is good, csup developers' hearts were already broken. But svn is still coded in C. It is still acceptable. Git was born outside BSD land. But it is still coded in C. Linux is also considered a Unix-liked operating system. cvs in NetBSD is also coded in C. (But it is much criticized.) I don't see any good reasons to implement Hg in rust or python. Please do not say C is hard to implement and maintain the code. Kernels for nearly all operating systems in the world were coded in C. How can all developers implement or maintain the code? C is very well mature, It has been around here for many decades. And it is much more portable than any other languages including C++, which has too many standards. And C++ committee doesn't even care backward compatability. So please adhere with only C, like what POSIX does. -- Gua Chung Lim Life is a pleasant lie and death is a painful truth.
Re: CDN readme out of date
"J. Lewis Muir" writes: > To whoever can fix the CDN readme: > > The CDN readme > > https://cdn.netbsd.org/pub/NetBSD/README I have updated /pub/NetBSD/README on ftp.netbsd.org I'm not really sure about these things updated every three weeks :-) Perhaps it should say they are updated t.i.w.
Re: Checking out src with Mercurial
On 6/20/20 1:08 PM, emu wrote: >> We have several VAXen at LSSM that have 128MB of RAM or more. One of >> them, a VAX-7000, has 1.5GB. :) > > I wouldn't call that a "standard" collection, by any means ;-) Perhaps not, but honestly most of the VAXen at the LSSM were a part of my personal collection before I opened the museum ~4.5 years ago. And my collection certainly isn't the largest around. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Re: Checking out src with Mercurial
On 6/20/20 5:01 AM, Holm Tiffe wrote: > Great. ..and how many VAXen do have 128Mbytes of RAM? We have several VAXen at LSSM that have 128MB of RAM or more. One of them, a VAX-7000, has 1.5GB. :) -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Re: cvs better than git?
On Sat, 20 Jun 2020 17:06:26 +0200 Andreas Krey wrote: > > However, a local repo has a big advantage: the possibility to > > quickly determine the status. > > ...or do logs, diffs, commits, checkouts, merges... Microsoft developed "VFS for Git" in order to scale it for large repos. Because let's face it, breaking up codebase into gazillions of smaller repos is daft and not very user friendly. The way I understand VFS - data is downloaded on demand, when you try to access some file. Doesn't this completely negate the idea of having all history stored locally? Git local repos seem cool up to a certain size, beyond that you need hacks like VFS and it's back to the traditional model of central VCS repos.
Re: cvs better than git?
Hi, On 6/17/20 10:48 PM, Sad Clouds wrote: Over the years, I worked on different projects and even though I work for the same company, we keep switching from one VCS to another. First we used Subversion, which was OK. it is not perfect, it has bugs, but it is "ok", exactly... git has some added power, but it is overly complicated, but has some nice things too. It would be nice to have a new tool, with the simplcity of CVS/SVN but some of the speed and features of GIT (not the other way around, were you try to wrap GIT with some glitter). Also, both SVN and GIT improved over time, SVN is not the one of 15 years ago, luckily, but some things were grafted on, of course. "git switch" for example, is a nice addition, incredible it took so many years to arrive. Riccardo
Re: cvs better than git?
On Sat, 20 Jun 2020 16:18:17 +, Riccardo Mottola wrote: ... > Local repositories are a mess.. Don't you hate that if you have a set of > local changes you cannot just "git pulL" without doing a commit for a > merge? 'git stash; git pull; git stash pop' (with a usabiliby quirk when there are conflicts). > However, a local repo has a big advantage: the possibility to quickly > determine the status. ...or do logs, diffs, commits, checkouts, merges... ... > remember SourceForge issues? or other sites? GIThub has its merits, but > one thing I hate: before MS era its interface was very compatible, so > you could use it with may browsers. If you use github like a plain cvs or svn server, you hardly ever interact with it with a browser. Moreover, even if github should spontaneously vanish, you and your collaborators can just point their remotes to a different hoster, push, and continue as if nothing happened. (Not so easily if you also use the pullreq and social features of github.) - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Recommended web browser?
Also, you can use Seamonkey. It is perfectly stable and works on stable and current very well on Net 8.2 and Net 9.0. cheers Petr Dne 20. 06. 20 v 12:59 nia napsal(a): On Fri, Jun 19, 2020 at 10:39:27PM -0700, Salil Wadnerkar wrote: SeaMonkey works fine. If you are on NetBSD current, you can use newer (based on Rust) versions of Firefox. Huh? Recent firefox is fine on 9.0, on amd64 and aarch64. armv7 does not have enough address space to build a rust compiler, so that's a problem... https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/aarch64/9.0/All/firefox-71.0.tgz https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0/All/firefox-74.0.tgz https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0/All/firefox-esr-68.tgz https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0/All/firefox68-68.9.0.tgz You're probably better off using firefox-esr if you're using a stable branch of pkgsrc, because I request security pullups for the ESR branch. It's harder for unstable releases.
Re: cvs better than git?
Hi! On 6/17/20 1:27 PM, Johnny Billquist wrote: I know I'm in a very small minority here, but personally I hate git. I sortof suspect I will not like hg either, and when the switch happens, it might just mean I'll stop using NetBSD. The whole idea of local repositories and then trying to sync with a central one is just an added layer of problems, in my experience, with no added value. I don't know how many times I've seen local git getting so messed up the easy solution was just to wipe it all and start over again. A very windows-like mentality, which I'm sure more people today are perfectly fine with, but I'm not. True. I understand you and I feel your pain. I use git more and more, also with extremely big repositories and it is a pain, it can break or do strange things even when doing "simple" things. Local repositories are a mess.. Don't you hate that if you have a set of local changes you cannot just "git pulL" without doing a commit for a merge? However, a local repo has a big advantage: the possibility to quickly determine the status. "git status" works well also for repositories with many files: a couple of minutes and you are set, the same on CVS or SVN is slow, because it walks the whole repository online. On the other hand, you can in CVS easily query a single file quickly, on GIT no. However, I'm certainly not going to try to convince people to not move towards it. I just felt like ranting over a tool that is so broken in my view, but which it seems the whole world have gone crazy about. :-) After using it for years, I admit it has some merits, but it is also so convoluted and breaks so easily that it is bad. What worries me are the dependencies and the long-run availability. CVS can be included in base, it is self-contained, fast and written in C! If you need ssh, it is an "add on", easily done. SVN is not so self-contained, but without https, it is acceptable. Mercurial? no go: python, please not. Just for this reason, maybe it would be perfect if written in equivalent C/C++! And please, don't cite me "rust"... even worse. Core things should be written with core tools. Maybe some sort of "anonymous checkout" of mercurial exists written in C? GIT here is not bad: it is relatively portable. Which previous, initially free and open revision control repository was it which then ended up changing their terms and conditions so that everyone more or less had to move away immediately? I do remember that it did happen once already... remember SourceForge issues? or other sites? GIThub has its merits, but one thing I hate: before MS era its interface was very compatible, so you could use it with may browsers. Now, since MS and being "very commercial" it is "only latest Firefox" ... try to use with one of the many lighter FireFox ports? no lugk, not even 52-ESR derivatives like clasic SeaMonkey... nor Midori and others. It is inconvenient and is clearly a "change in politics" of GitHub. Who knows what happens behind the curtains ? Riccardo
Re: Checking out src with Mercurial
matthew sporleder wrote: > > git clone with --depth 1, over http (instead of ssh), and with a few > simple settings changes will make it work inside of 128M. > > I did it a few years ago. Great. ..and how many VAXen do have 128Mbytes of RAM? What exactly is a "real VAX"? Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 i...@tsht.de Fax +49 3731 74200 Tel +49 3731 74222 Mobil: 0172 8790 741
Re: Recommended web browser?
On Fri, Jun 19, 2020 at 10:39:27PM -0700, Salil Wadnerkar wrote: > SeaMonkey works fine. > If you are on NetBSD current, you can use newer (based on Rust) versions of > Firefox. Huh? Recent firefox is fine on 9.0, on amd64 and aarch64. armv7 does not have enough address space to build a rust compiler, so that's a problem... https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/aarch64/9.0/All/firefox-71.0.tgz https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0/All/firefox-74.0.tgz https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0/All/firefox-esr-68.tgz https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0/All/firefox68-68.9.0.tgz You're probably better off using firefox-esr if you're using a stable branch of pkgsrc, because I request security pullups for the ESR branch. It's harder for unstable releases.
Pre-seeded Mercurial-Clone available? (was: Checking out src with Mercurial)
Hello everybody, while I was able to successfully clone the pkgsrc and xsrc via anonhg, I still bite my teeth at src. As already described in one of my previous e-mails, I tried to limit the number of changesets called up at the same time with --rev, so that I don't lose everything in the event of a fault. Now the message "transaction canceled" came. Afterwards "Roll back failed, please run hg recover". Unfortunately, "hg recover" also reports an abort because an automatic repair is obviously not possible. So now I'm starting again ... ... and I wondered whether it is possible or already considered to offer a finished clone as tar.gz for download from time to time - as a seed for the continuation of your own local clone? Or maybe it already exists and I just haven't found it yet? I can remember that there is something like that on FreeBSD for the SVN - download tar.gz, unpack it and then only use svnsync to catch up for the last six months. Many Greetings Matthias
Re: Checking out src with Mercurial
On 20/06/2020 07:16, Dave McGuire wrote: On June 20, 2020 12:01:40 AM Roy Marples wrote: On 19/06/2020 23:08, Dave McGuire wrote: On 6/19/20 5:09 PM, matthew sporleder wrote: I personally think running such an old and inefficient computer is, literally, immoral when a modern $30 machine can emulate it perfectly using as much electricity as a small CFL light bulb and leave over 700mb of memory to spare. Sure, but it's, to put it simply, NOT THE REAL THING. If you don't get it, that's fine. Don't run one. But there's a massive difference between compiling and running. Cross compiles in NetBSD is what the base OS excells at. NetBSD used to run great directly on VAXen. On real hardware. That's literally what I just said! Do I run NetBSD on my ERLITE? YES! Do I compile on my ERLITE? NO! It's also not memory that's the concern. It's just too slow and more efficient to offload that task to a more capable machine. My ERLITE is in constant use 24 hrs a day and is super rock solid, thanks to NetBSD. Roy
Re: Checking out src with Mercurial
On June 20, 2020 12:01:40 AM Roy Marples wrote: > On 19/06/2020 23:08, Dave McGuire wrote: >> On 6/19/20 5:09 PM, matthew sporleder wrote: >>> I personally think running such an old and inefficient computer is, >>> literally, immoral when a modern $30 machine can emulate it perfectly using >>> as much electricity as a small CFL light bulb and leave over 700mb of >>> memory to spare. >> >>Sure, but it's, to put it simply, NOT THE REAL THING. >> >>If you don't get it, that's fine. Don't run one. > > But there's a massive difference between compiling and running. > Cross compiles in NetBSD is what the base OS excells at. NetBSD used to run great directly on VAXen. On real hardware. 'Nuff said. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Re: Checking out src with Mercurial
On Fri, Jun 19, 2020 at 10:01:35PM -0700, Greg A. Woods wrote: > (c) modern change tracking tools try to track changes to whole sets of > files at once, so if you have lots of files, and lots of history, > this combinatorial problem can sometimes bite at a bad time for the > user of a tool trying to manage it all. In one of the talks by Linus on git I heard him recommending breaking very large repositories into some smaller units to get better performance. Would it be something feasible in NetBSD? A single user requires approximately what % of code from what he or she checks out to be actually compiled and can there be 1 core and several optional repositories that would increase this percentage. Mayuresh
