Re: HEADS-UP: /bin/sh memory management bug fixes committed
I just wanted to say a big thanks for looking after our shell; you're doing a good job! Best, Alistair On 17 June 2017 at 00:22, Robert Elz wrote: > I have just committed the (long awaited) bug fix set for /bin/sh -- > to fix some bugs I introduced recently - but also, several old, > devious, bugs that had remained hidden for years, but which became > more exposed with some of the recent changes - not so much the changes > themselves, but with the way the code changed to accommodate easier > debugging of the changes. > > So please watch for anything that looks like it could be shell misbehaviour, > and either let me know, or file a PR. > > You might also want to consider rebuilding anything that has been built from > a shell script (particularly a large one - like a configure script) in the > past couple of weeks. While it is very unlikely that a bug could have > caused the script to fail in a way that would not be immediately obvious, > with some of what has been fixed, almost anything is possible. Note it is > not so much the complexity of the script that matters, but the amount of > data processed (strings expanded, ...) which would trigger problems, so a > small script that collects, massages, then outputs, a lot of variable > length (but probably normally lengthy) data is far more likely to have been > affected than a huge set of functions that work on a relatively small data > set. > > While doing this, a couple of user visible changes just "snuck in" > while I wasn't looking... > > Posix requires that '~' expand to he value of $HOME when HOME is set. > We were doing that, except in the case where HOME="" where we left the ~ > in place instead of replacing it with the null string as required (the > same was true for the even less likely case of ~user being found in the > passwd file and having an empty home directory set there - we should be > returning a null string in that case as well, and weren't, but now do.) > > If HOME is unset, then it is unspecified in POSIX what happens - we used > to simply leave the ~, now I have made the shell return > getpwuid(getuid())->pw_home > (assuming that exists of course). This allows a script to compensate for > being run with "env -i" (or similar) if it desires, which was more difficult > before. While many other shells retain our past behaviour (just leaving > the '~') when HOME is unset, others do it the new way (this difference is > why POSIX does not specify what must happen.) > > If anyone finds that this change causes problems, let me know, this was > a trivial change, and would be easy to revert. > > There is also one additional fix to an obscure case of counting LINENO with > "here documents" when a bizarre (and not working in many shells) end delimiter > (containing newline characters) is used. Never seen it in real life, so I > doubt anyone will notice the difference (and this one was a bug fix.) > > kre >
Re: HEADS-UP: /bin/sh memory management bug fixes committed
Date:Sat, 17 Jun 2017 14:09:02 -0700 From:Alistair Crooks Message-ID: | I just wanted to say a big thanks for looking after our shell; Thanks for that, but generic appreciation isn't needed ... what is is more testing, and (perhaps, though it would be nice not!) bug reports. kre
Re: HEADS-UP: /bin/sh memory management bug fixes committed
On 18/06/2017 00:22, Robert Elz wrote: Date:Sat, 17 Jun 2017 14:09:02 -0700 From:Alistair Crooks Message-ID: | I just wanted to say a big thanks for looking after our shell; Thanks for that, but generic appreciation isn't needed Amazing. One of the main driving reasons I do what I do is because of the apprecation of the few that have taken the time to write me thanks. I treasure this more than a bug report or a patch, because someone out there believes I'm Doing The Right Thing. So let me add my thanks as well. Roy
Re: HEADS-UP: /bin/sh memory management bug fixes committed
from Robert Elz: > I have just committed the (long awaited) bug fix set for /bin/sh -- > to fix some bugs I introduced recently - but also, several old, > devious, bugs that had remained hidden for years, but which became > more exposed with some of the recent changes - not so much the changes > themselves, but with the way the code changed to accommodate easier > debugging of the changes. > So please watch for anything that looks like it could be shell misbehaviour, > and either let me know, or file a PR. > You might also want to consider rebuilding anything that has been built from > a shell script (particularly a large one - like a configure script) in the > past couple of weeks. While it is very unlikely that a bug could have > caused the script to fail in a way that would not be immediately obvious, > with some of what has been fixed, almost anything is possible. Note it is > not so much the complexity of the script that matters, but the amount of > data processed (strings expanded, ...) which would trigger problems, so a > small script that collects, massages, then outputs, a lot of variable > length (but probably normally lengthy) data is far more likely to have been > affected than a huge set of functions that work on a relatively small data > set. I guess bugs in sh could affect a run with pkg_rolling-replace and other updates using pkgsrc? I suppose strange things can happen? Am I advised to rebuild my system (i386 and amd64) using build.sh after "cvs up -dP -A"? I will still have the dubious /bin/sh from just this past week. Or should I rebuild twice, the second time being with the new /bin/sh, or is that overkill? Tom
Re: HEADS-UP: /bin/sh memory management bug fixes committed
Date:Sun, 18 Jun 2017 07:16:55 + From:"Thomas Mueller" Message-ID: | I guess bugs in sh could affect a run with pkg_rolling-replace | and other updates using pkgsrc? I've never used pkg_rolling_replace so I'm not sure exactly what it does - if it is one of the versions that fetches and installs binary packages that have been compiled elsewhere, then I think you can feel safe enough with that - it might be possible that sometimes it (that is p_r_r) will fail to operate correctly because of a shell bug, but if it does the result will be a package not installed, not a broken one installed. If it is a method to build packages from pkgsrc (and any other way of building locally from source) then the usual effect of the broken shell would be to stop the package building - very few packages install sh scripts (let alone ones generated on the fly) so the shell has very little influence on anything beyond configuring the package. But packages that failed to build (several were seen to have problems) were certainly possible. Anything that is just compiled C (or C++ or python, etc) code which built and installed correctly is not going to have a problem, the shell is an important program, but it isn't *that* important, the compilers, linkers, etc, all work just the same whatever the shell is doing. | I suppose strange things can happen? Yes. | Am I advised to rebuild my system (i386 and amd64) using build.sh | after "cvs up -dP -A"? If it built correctly, then no, that should not be needed (not that it should do any harm - several other updates have been done in the past wee, re-building would get you newer versions of other systems). But I would advise you to install (at least) a new /bin/sh The (or an) easy way to do that, is just to go to src/bin/sh (after that has been updated) cd .../usr/bin/sh mkdir /tmp/sh cp -rp . /tmp/sh cd /tmp/sh USETOOLS=no make (then after it succeeds, < 2 mins probably, as root) cp sh /bin/sh.new mv /bin/sh /bin/sh.save && mv /bin/sh.new /bin/sh (you could install the updated sh.1 if you want, but that is not important) (then back as a normal user) cd /tmp rm -fr sh (the copy to /tmp rigmarole is just to avoid messing up /usr/src, as this way of building puts .o files (etc) in the current directory.) Be careful with the two commands executed as root, leaving the system without a working (or mostly working) /bin/sh is not a good state to have. The rest you can do as many times as you need until it is all right. | I will still have the dubious /bin/sh from just this past week. Unless you have replaced it today, if you installed a version more recent than June 7 (I think it was, just under 2 weeks ago) then yes, it is likely broken (actually, any from any time in the past would be broken this same way - the changes made it more likely that the bug would manifest itself, they did not cause it.) The other bugs that I actually added 2 weeks ago were much more blatant, if you (or some script) did the thing that caused a problem, it would simply break badly, very little chance for any subtle errors with those ones. | Or should I rebuild twice, the second time being with the new /bin/sh, | or is that overkill? Overkill. If the system is working, there's no need to rebuild it, sh bugs might have prevented it building, but are very unlikely to cause it to appear to successfully build, and yet be corrupted. Note that the worst of the bugs was a very rare one, it took exactly the right set of circumstances to set it off - for most uses, the shell would work just fine. kre
Re: HEADS-UP: /bin/sh memory management bug fixes committed
Robert Elz writes: > Date:Sun, 18 Jun 2017 07:16:55 + > From:"Thomas Mueller" > Message-ID: > > | I guess bugs in sh could affect a run with pkg_rolling-replace > | and other updates using pkgsrc? > > I've never used pkg_rolling_replace so I'm not sure exactly what it > does - if it is one of the versions that fetches and installs binary > packages that have been compiled elsewhere, then I think you can feel > safe enough with that - it might be possible that sometimes it (that is p_r_r) > will fail to operate correctly because of a shell bug, but if it does the > result will be a package not installed, not a broken one installed. pkg_rolling-replace is written in sh. It's not super hairy, but it's not trivial. It is possible that not likely it will trigger a bug in sh, but it seems far more likely other usage will find the bug also/first. It's also possible, were there a bug in sh, that any particular package build will fail. So certainly, it makes sense for people to try things in various ways and track down issues. signature.asc Description: PGP signature
Re: HEADS-UP: /bin/sh memory management bug fixes committed
from Robert Elz: Date:Sun, 18 Jun 2017 07:16:55 + From:"Thomas Mueller" Message-ID: | I guess bugs in sh could affect a run with pkg_rolling-replace | and other updates using pkgsrc? > I've never used pkg_rolling_replace so I'm not sure exactly what it > does - if it is one of the versions that fetches and installs binary > packages that have been compiled elsewhere, then I think you can feel > safe enough with that - it might be possible that sometimes it (that is p_r_r) > will fail to operate correctly because of a shell bug, but if it does the > result will be a package not installed, not a broken one installed. > If it is a method to build packages from pkgsrc (and any other way > of building locally from source) then the usual effect of the broken > shell would be to stop the package building - very few packages install > sh scripts (let alone ones generated on the fly) so the shell has very > little influence on anything beyond configuring the package. > But packages that failed to build (several were seen to have problems) > were certainly possible. > Anything that is just compiled C (or C++ or python, etc) code which > built and installed correctly is not going to have a problem, the shell > is an important program, but it isn't *that* important, the compilers, > linkers, etc, all work just the same whatever the shell is doing. > | I suppose strange things can happen? > Yes. > | Am I advised to rebuild my system (i386 and amd64) using build.sh > | after "cvs up -dP -A"? > If it built correctly, then no, that should not be needed (not that it should > do any harm - several other updates have been done in the past wee, > re-building > would get you newer versions of other systems). > But I would advise you to install (at least) a new /bin/sh What do you use instead of pkg_rolling-replace, while waiting for portupgrade and portmaster to be imported from FreeBSD ports (wishful thinking)? What do you do when you want to update many packages? pkg_rolling-replace was stopped when an earlier version of a package was installed, failed to do "make update" or "make replace" which I thought pkg_rolling-replace was supposed to do automatically. Was graphics/graphite2 one of the packages seen to have problems? Trying to configure that segfaulted and dumped core, no informative log. My last system update dates were Jun 14 (i386) and Jun 11 (amd64), within the vulnerable time for /bin/sh bugs. After update, I could try pkg_rolling-replace again on somewhat messed-up system to see if there is any improvement. I have one installation, amd64, where no packages are yet installed, a strongly tempting target for John Marino's synth. Synth is written in Ada and compiled, not a shell script, but might still be safer with /bin/sh in working order. I wouldn't want to judge synth badly when the fault is with /bin/sh. Tom
Re: HEADS-UP: /bin/sh memory management bug fixes committed
Date:Sun, 18 Jun 2017 19:28:19 + From:"Thomas Mueller" Message-ID: <79.F6.01815.A54D6495@dnvrco-omsmta03> | What do you use instead of pkg_rolling-replace, while waiting for | portupgrade and portmaster to be imported from FreeBSD ports (wishful | thinking)? | | What do you do when you want to update many packages? I have my own scripts from before pkg_rolling-replace (or almost any of the various other tools) existed. They work out what I have installed that is out of date (well, lintpkgsrc does that), figure out the dependencies, sort them all into the correct build order, and build binary packages for all of the packages that need rebuilding. Once that's all done (which can take time, as not all packages always build properly all the time...) I just install a complete new set of packages into an empty /usr/pkg from the binary packages I have built. This step only takes a few minutes. If there's a problem, I just move the old /usr/pkg back, while I fix (or wait for someone else to fix) whatever went wrong. | Was graphics/graphite2 one of the packages seen to have problems? No - or more correctly, that isn't one that I knew of. | Trying to configure that segfaulted and dumped core, no informative log. That would be the kind of problem I expect the sh bug may have caused. That is, just flat out breakage (the bug was subtle, and rare, the effects anything but.) So for that, just try again with a new shell (and a rebuilt libtool I would suggest as well.) I will try building it on my test system, if it doesn't take too long (including whatever dependencies it needs that aren't already there from my other pkgsrc building tests.) | My last system update dates were Jun 14 (i386) and Jun 11 (amd64), | within the vulnerable time for /bin/sh bugs. Yes. kre
Re: HEADS-UP: /bin/sh memory management bug fixes committed
Date:Sun, 18 Jun 2017 19:28:19 + From:"Thomas Mueller" Message-ID: <79.F6.01815.A54D6495@dnvrco-omsmta03> | Was graphics/graphite2 one of the packages seen to have problems? Just finished build of that (using fixed shell, and all new, post sh fix) /usr/pkg, no issues. kre
Re: HEADS-UP: /bin/sh memory management bug fixes committed
On Jun 17, 2017 18:01, "Roy Marples" wrote: On 18/06/2017 00:22, Robert Elz wrote: > Date:Sat, 17 Jun 2017 14:09:02 -0700 > From:Alistair Crooks > Message-ID: jnodczeegrvs_n3cpgy...@mail.gmail.com> > >| I just wanted to say a big thanks for looking after our shell; > > Thanks for that, but generic appreciation isn't needed > Amazing. One of the main driving reasons I do what I do is because of the apprecation of the few that have taken the time to write me thanks. I treasure this more than a bug report or a patch, because someone out there believes I'm Doing The Right Thing. So let me add my thanks as well. +1 I'm grateful for this work, and indeed inspired (ditto Roy, Alistair). I've filed bug reports too, but also know it's "just appreciated", as well. Cheers, -bch Roy
Re: HEADS-UP: /bin/sh memory management bug fixes committed
from Robert Elz: > Date:Sun, 18 Jun 2017 19:28:19 + > From:"Thomas Mueller" > Message-ID: <79.F6.01815.A54D6495@dnvrco-omsmta03> > | What do you use instead of pkg_rolling-replace, while waiting for > | portupgrade and portmaster to be imported from FreeBSD ports (wishful > | thinking)? | > | What do you do when you want to update many packages? > I have my own scripts from before pkg_rolling-replace (or almost any of the > various other tools) existed. They work out what I have installed that > is out of date (well, lintpkgsrc does that), figure out the dependencies, > sort them all into the correct build order, and build binary packages for > all of the packages that need rebuilding. > Once that's all done (which can take time, as not all packages > always build properly all the time...) I just install a complete new set of > packages into an empty /usr/pkg from the binary packages I have built. > This step only takes a few minutes. If there's a problem, I just > move the old /usr/pkg back, while I fix (or wait for someone else to fix) > whatever went wrong. > | Was graphics/graphite2 one of the packages seen to have problems? > No - or more correctly, that isn't one that I knew of. > | Trying to configure that segfaulted and dumped core, no informative log. > That would be the kind of problem I expect the sh bug may have caused. > That is, just flat out breakage (the bug was subtle, and rare, the effects > anything but.) > So for that, just try again with a new shell (and a rebuilt libtool I > would suggest as well.) > I will try building it on my test system, if it doesn't take too long > (including whatever dependencies it needs that aren't already there from > my other pkgsrc building tests.) > | My last system update dates were Jun 14 (i386) and Jun 11 (amd64), > | within the vulnerable time for /bin/sh bugs. > Yes. I suspect sh bug might have been at fault at least in part for pkg_rolling-replace strange behavior, and "make update" compiling a bundle of unrelated stuff. Finally, mercifully, the mass compilation seemed to run out of memory, crashed and rebooted. I chose to boot back into the same NetBSD installation to replay log to disk and thereby fix root partition, and then I ran fsck_ffs on two partitions that were mounted, one active, at time of crash. I don't think I want to do anything serious before upgrading /bin/sh. Then I can rebuild libtool (make package), then, I think, "make deinstall install". This would be for both i386 and amd64. > | Was graphics/graphite2 one of the packages seen to have problems? > Just finished build of that (using fixed shell, and all new, > post sh fix) /usr/pkg, no issues. I guess I can try that again after seeing where it fits in the schedule of updating other packages. I have to consider the likelihood that many installed packages will no longer work after updating kernel and userland from 7.99.15 to 7.99.71 to 8.99.1 because shared libraries figure to be out of sync. This has stung me several times in FreeBSD, shared libraries being out of sync. Tom
Re: HEADS-UP: /bin/sh memory management bug fixes committed
Date:Mon, 19 Jun 2017 05:39:28 + From:"Thomas Mueller" Message-ID: <92.EA.01815.89367495@dnvrco-omsmta03> | I suspect sh bug might have been at fault at least in part for | pkg_rolling-replace strange behavior, That is possible. | "make deinstall install". I generally do pkg_delete rather than make deinstall (had no idea such an option existed). But otherwise, right. | I have to consider the likelihood that many installed packages will no | longer work after updating kernel and userland from 7.99.15 to 7.99.71 | to 8.99.1 because shared libraries figure to be out of sync. That should not be a problem, the only things that should need recompiling are things that depend upon osabi - usually I think that is far too strict, but in this case there's really no way it can know that nothing much has changed since (at least high) 7.99.nn versions and 8.99.1 There might be an isolated package that uses one of the rarer libraries which might have been updated (particularly since 7.99.15) which you can solve either by recompiling (it, and everything else it depends upon which also might use the changed library) or you can just copy the lib.so.N.M file from the old system to the new one (and perhaps the libxxx.so.N symlink which points at that one - I've never been sure exactly when that one is used). Just beware of mixing object files (which includes .so files) compiled and or linked using different versions of what is intended to be the same thing. That leads to havoc. Apart from that I regularly run ancient compiled packages on newer systems, NetBSD people generally work very hard to make sure that remains possible. In fact, I usually compile all my packages against the N.0 RELEASE version (for whichever NetBSD version (N) I am using at the time) - that way one set of binary packages are all that are needed for all systems (of the same architecture, naturally) whatever actual N.p.q version I actually install on them.) kre
Re: HEADS-UP: /bin/sh memory management bug fixes committed
from Robert Elz: >Date:Mon, 19 Jun 2017 05:39:28 + > From:"Thomas Mueller" > Message-ID: <92.EA.01815.89367495@dnvrco-omsmta03> > | I suspect sh bug might have been at fault at least in part for > | pkg_rolling-replace strange behavior, > That is possible. > | "make deinstall install". > I generally do pkg_delete rather than make deinstall (had no idea such > an option existed). But otherwise, right. > | I have to consider the likelihood that many installed packages will no > | longer work after updating kernel and userland from 7.99.15 to 7.99.71 > | to 8.99.1 because shared libraries figure to be out of sync. > That should not be a problem, the only things that should need > recompiling are things that depend upon osabi - usually I think that is > far too strict, but in this case there's really no way it can know that > nothing much has changed since (at least high) 7.99.nn versions and 8.99.1 > There might be an isolated package that uses one of the rarer libraries > which might have been updated (particularly since 7.99.15) which you can > solve either by recompiling (it, and everything else it depends upon > which also might use the changed library) or you can just copy the > lib.so.N.M file from the old system to the new one (and perhaps > the libxxx.so.N symlink which points at that one - I've never been sure > exactly when that one is used). > Just beware of mixing object files (which includes .so files) compiled > and or linked using different versions of what is intended to be the same > thing. That leads to havoc. > Apart from that I regularly run ancient compiled packages on newer > systems, NetBSD people generally work very hard to make sure that remains > possible. > In fact, I usually compile all my packages against the N.0 RELEASE version > (for whichever NetBSD version (N) I am using at the time) - that way one > set of binary packages are all that are needed for all systems (of the same > architecture, naturally) whatever actual N.p.q version I actually install on > them.) I updated NetBSD-current i386 successfully, but running pkg_rolling-replace failed miserably. One barrier was package security/sudo, whether run from pkg_rolling-replace or from security/sudo directory: ln -s sudo.8 /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/man/man8/sudoedit.8 /bin/sh ../mkinstalldirs /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo for f in ./pam.conf ./sudo.conf ./sudoers ./syslog.conf; do /bin/sh ../install-sh -c -m 0644 $f /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo; done /usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/doc/UPGRADE /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/doc/sudo /usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/plugins/sudoers/sudoers /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo/sudoers /usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/README /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/doc/sudo => Automatic manual page handling => Generating post-install file lists /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/group_file.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB) /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/sudo_noexec.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB) /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/sudoers.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB) /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/system_group.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB) => Checking file-check results for sudo-1.8.20p2 ERROR: ERROR: The following files are in /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg but not in the PLIST: ERROR: /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/hu/LC_MESSAGES/sudo.mo ERROR: /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/ko/LC_MESSAGES/sudo.mo ERROR: /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/ko/LC_MESSAGES/sudoers.mo ERROR: /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/nn/LC_MESSAGES/sudo.mo *** Error code 1 Stop. make[2]: stopped in /BETA1/pkgsrc/security/sudo *** Error code 1 Stop. make[1]: stopped in /BETA1/pkgsrc/security/sudo *** Error code 1 Stop. make: stopped in /BETA1/pkgsrc/security/sudo I don't know if this would do any better on amd64. I suppose I could try editing the PLIST and then "make install"? But then I guess th
Re: HEADS-UP: /bin/sh memory management bug fixes committed
Date:Tue, 20 Jun 2017 04:59:57 + From:"Thomas Mueller" Message-ID: | One barrier was package security/sudo, Works for me (well, builds for me) on amd64. However, I think the errors that you are seeing are the kind of thing that typically happens when you have specified one of the directories (particularly OBJDIR or its pkgsrc version, which I think is WRKOBJDIR) as a path that includes symbolic links. That is not permitted - or perhaps better stated - it simply does not work. cd -P to your pkgsrc OBJDIR (WRKOBJDIR) (top of the tree), run pwd (or /bin/pwd, though they should be the same if you are using the NetBSD shell as your login shell) and use whatever it tells you as the setting in /etc/mk.conf. The same might be needed for some of the other directories related to pkgsrc that are specified there, like DISTDIR and PACKAGES, perhaps even PKGSRCDIR and PKG_DBDIR,perhaps LOCALBASE as well or PREFIX) As a simply solution - make sure no directories specified in /etc/mk.conf contain any symbolic links, anywhere in their values, used the "real" pathnames instead. (Humans never need to see these things, you can still refer to them by the friendlier names in other places.) | I don't know if this would do any better on amd64. It works for me, but unless your config is different there, probably not for you. | I suppose I could try editing the PLIST and then "make install"? No, don't do that. | But then I guess this belongs on a new thread on pkgsrc-users. | I don't really think this is the fault of /bin/sh any more. No, nor do I. Though why not see if you can fix it first, and then if needed, ask there where people who know pkgsrc much better than I do (barely at all) will be able to help. kre
Re: HEADS-UP: /bin/sh memory management bug fixes committed
from Robert Elz: > Date:Tue, 20 Jun 2017 04:59:57 + > From:"Thomas Mueller" > Message-ID: > | One barrier was package security/sudo, > Works for me (well, builds for me) on amd64. > However, I think the errors that you are seeing are the kind of thing > that typically happens when you have specified one of the directories > (particularly OBJDIR or its pkgsrc version, which I think is WRKOBJDIR) > as a path that includes symbolic links. > That is not permitted - or perhaps better stated - it simply does not > work. No symbolic links in my case. I personally use symbolic links very sparsely and not in NetBSD pkgsrc and FreeBSD ports. I regard symbolic links as more annoyance than help. > cd -P to your pkgsrc OBJDIR (WRKOBJDIR) (top of the tree), run pwd > (or /bin/pwd, though they should be the same if you are using the NetBSD > shell as your login shell) and use whatever it tells you as > the setting in /etc/mk.conf. > The same might be needed for some of the other directories related to > pkgsrc that are specified there, like DISTDIR and PACKAGES, perhaps > even PKGSRCDIR and PKG_DBDIR,perhaps LOCALBASE as well or PREFIX) > As a simply solution - make sure no directories specified in /etc/mk.conf > contain any symbolic links, anywhere in their values, used the "real" > pathnames instead. (Humans never need to see these things, you can > still refer to them by the friendlier names in other places.) > | I don't know if this would do any better on amd64. > It works for me, but unless your config is different there, probably > not for you. > | I suppose I could try editing the PLIST and then "make install"? > No, don't do that. Too late to stop me, I did, and was surprised when it was successful: long before I saw your message. > | But then I guess this belongs on a new thread on pkgsrc-users. > | I don't really think this is the fault of /bin/sh any more. > No, nor do I. Though why not see if you can fix it first, and then > if needed, ask there where people who know pkgsrc much better than I > do (barely at all) will be able to help. On other issues regarding my upgrade to better /bin/sh, I updated NetBSD-current amd64 and FreeBSD 11 stable branch, now at 11.1-BETA2, also amd64. FreeBSD seems to be more prone than NetBSD to adverse effect of shared libraries being out of sync when kernel and userland are updated. Firefox, built around the time of NetBSD 7.99.15, ran on amd64 current, at least prior to last update, but didn't start on i386 current, short of memory, or maybe it was really some other fault. Tom
Re: HEADS-UP: /bin/sh memory management bug fixes committed
Date:Wed, 21 Jun 2017 05:52:23 + From:"Thomas Mueller" Message-ID: <84.EE.27444.2990A495@dnvrco-omsmta02> | No symbolic links in my case. I had assumed that /BETA1 might be a symlink on your system. | > | I suppose I could try editing the PLIST and then "make install"? | > No, don't do that. | Too late to stop me, I did, and was surprised when it was successful: It should not have been necessary - and I'm not sure what state the package will really be in after having done that, you'd have to ask someone pkgsrc knowledgable (that is, the binaries etc should run fine, but when you want to pkg_delete it, to upgrade, or any other reason, it's possible that will not happen correctly - or something like that.) At least nothing is going to be depending upon sudo, so you don't need to worry about it affecting other packages. But security/sudo did build fine for me without needing any special attention so there has to be something different about your environment. kre
