Re: nosh version 1.37
2018-02-18 20:05 GMT-03:00 Jonathan de Boyne Pollard: > > Guillermo: > >> This is going to happen for every [GNU/]Linux distribution that is not >> Debian, Arch, CentOS or RHEL. It does not... uh... look very portable :/ >> > > That is a reflection of reality. It isn't very portable. But you are > misidentifying what it is. > [...] > Guillermo: > >> Additionally, the convert/per-user/*.do scripts' 'read_os' function calls >> 'exec' via absolute path /bin/exec instead of relative path ../../exec, >> which is not going to work if nosh isn't already installed (chicken and >> egg). >> > > There's no chicken and egg problem. The external formats configuration > import requires (amongst others) the nosh-exec package. > [...] > Moreover that is not the relative path from your > $HOME/.config/service-bundles/convert/ directory to /bin. Not that there > of course *is* a stable single relative path for such a thing, given that > home directories can be anywhere from /export/home/guillermo to > /var/lib/mysql . Nor that, as mentioned, such a relative path is needed, > given that one installs the toolset before running the external > configuration import. But wait. You are talking here about run-time requirements / behaviour of the configuration import subsystem and the service bundles provided by nosh, after one installs (some equivalent of) the nosh-bundles or nosh-run-via-systemd packages for the target operating system. I accept that OS-specific patches might be required here and there to make them work for the reasons you mentioned. But the 7 .do scripts I talked about are executed (indirectly) by the package/compile script from the source package, and they just create symbolic links. To be precise, they are executed by the source/all.do script, because they are named in 'echo' commands that feed their output to the 'xargs -r redo-ifchange' invocation. As it is, on any [GNU/]Linux distribution that is not Debian, Arch, CentOS or RHEL, downloading the source package and building it slashpackage-style by executing package/compile will simply fail. There are warnings in the jdebp.eu webpage about package/stage, but my expectation was that package/compile would just work (even without a previous nosh installation), as it has for older versions, provided the required dependencies are installed (meaning redo, xmlto, ncurses, pax, etc.). I can work around this by just patching source/all.do so that it does not execute those .do scripts, or look at what they should do for Gentoo and patch them, or whatever, but I am sure quite a few people besides me are going to be surprised by package/compile failing for them. (You are right about relative path ../../exec being wrong, it should be relative to redo's working directory, i.e. ./exec) G.
Re: nosh version 1.37
Guillermo: This is going to happen for every [GNU/]Linux distribution that is not Debian, Arch, CentOS or RHEL. It does not... uh... look very portable :/ That is a reflection of reality. It isn't very portable. But you are misidentifying what it is. It is the location of these various off-PATH executables, which have at least four different possible locations; and the name of the user that runs the system-wide Desktop Bus broker. Yes, the people who have packaged these up don't agree on the same off-PATH locations; and their names are not very portable; and they don't agree on system account names. If you can work out which of the existing four Gentoo's packaging for things like at-spi-bus-launcher is most like, like M. Caravia did for Arch Linux, I'll put in some mappings for Gentoo. But do not blame the messenger for the news that GNOME confd is in four different places across Arch Linux, RedHat Linux, Debian/Ubuntu Linux, and FreeBSD/TrueOS. You might find that Gentoo mainly or wholly follows the pattern of one of the others. But from mine and M. Caravia's experience of operating systems not even being entirely *self* consistent in this area, with no overall pattern being followed even for Desktop Bus softwares on a single operating system, you probably shouldn't raise your hopes about that. (-: And yes, M. Caravia originally worked these out as a set of patches for Arch Linux, working out what should happen for arch:* . Guillermo: Additionally, the convert/per-user/*.do scripts' 'read_os' function calls 'exec' via absolute path /bin/exec instead of relative path ../../exec, which is not going to work if nosh isn't already installed (chicken and egg). There's no chicken and egg problem. The external formats configuration import requires (amongst others) the nosh-exec package. There is no requirement in the opposite direction, so simply install nosh-exec first. This happens automatically with the provided packaging for FreeBSD/TrueOS and Debian, and with M. Caravia's Archnosh packaging, because of nosh-bundles depending from nosh-exec. If one installs the former, the package managers will have made sure that the latter is installed too. Moreover that is not the relative path from your $HOME/.config/service-bundles/convert/ directory to /bin . Not that there of course *is* a stable single relative path for such a thing, given that home directories can be anywhere from /export/home/guillermo to /var/lib/mysql . Nor that, as mentioned, such a relative path is needed, given that one installs the toolset before running the external configuration import.
Re: nosh version 1.37
2018-02-18 3:49 GMT-03:00 Jonathan de Boyne Pollard: > > The nosh package is now up to version 1.37 . > [...] >Per-user management has been augmented, finally fixing the problem >of |system-control| locating the per-user manager by giving the >per-user manager an optional listening FIFO open file descriptor, >which it uses to listen for user-wide state change commands. >|system-control --user| |halt|/|normal|/|sysinit|/ now send >commands via this FIFO, and each user's |user-services@/username/| >service bundle now uses |fifo-listen| to set up the FIFO and creates >the |per-user-manager/| subdirectory in |/run/user|. \O/ \O/ \O/ On the other hand, all those new .do scripts that generate systemd unit files and configuration files using the read_os shell function fail on Gentoo :-P redo-ifchange[2]: ERROR: services/dbus-broker.service: Not done. redo-ifchange[2]: ERROR: services/dbus-daemon.service: Not done. redo-ifchange[2]: ERROR: services/system-wide.conf: Not done. redo-ifchange[2]: ERROR: systemd/service-manager.socket: Not done. redo-ifchange[2]: ERROR: convert/per-user/at-spi-dbus-bus.service: Not done. redo-ifchange[2]: ERROR: convert/per-user/gconfd.service: Not done. redo-ifchange[2]: ERROR: convert/per-user/per-user.conf: Not done. 'read_os ID' returns 'gentoo' for Gentoo's /etc/os-release, and 'read_os VERSION_ID' returns nothing (it is a rolling release distribution), so this always matches the *) ext=who ;; lines, making the redo-ifchange invocation fail with either "Don't know what to use to build this" or "Cannot find .do file to use". Or making it call convert/per-user/default.do and *then* failing. So what do I do, should I patch the .do scripts to include a 'gentoo:*)' line? This is going to happen for every [GNU/]Linux distribution that is not Debian, Arch, CentOS or RHEL. It does not... uh... look very portable :/ Additionally, the convert/per-user/*.do scripts' 'read_os' function calls 'exec' via absolute path /bin/exec instead of relative path ../../exec, which is not going to work if nosh isn't already installed (chicken and egg). On my computer that results in accidentally calling execline's exec program, which is even funnier. Thanks for your attention. G.
Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )
2018-01-16 13:09 GMT-03:00 Charlie Brady: > > Now seeing these many times: > > /usr/include/curses.h:843:31: error: initializing argument 1 of 'char* > tigetstr(char*)' [-fpermissive] > > service-status.cpp:148:21: error: invalid conversion from 'const char*' to > 'char*' [-fpermissive] >s = tigetstr(setaf); > [...] > This is on CentOS7 build platform. This should be fixed in nosh 1.37. So, unless there were other compiler errors (warnings are nonfatal), nosh binaries should now build on CentOS too. G.
