Re: nosh version 1.37
Guillermo: Did someone else help with that? No. I am reliant upon you and anyone else who pipes up. Guillermo: if you are going to go this route: Yes. I thought about it and it seemed that doing otherwise places the burden on the wrong person. The other approach is to defer running the *.do files until the end-user runs the import subsystem in xyr $HOME/.config/service-bundles/convert/ directory. That's placing the burden of working out how GNOME confd, dbus-daemon, and others are built for any given operating system, on every single end-user. The burden of that should be just on the shoulders of the person doing the porting to the operating system in question and making the relevant operating system packaging. There's one more to go. Have a look at the Packages and Ports chapter on the copy of the nosh Guide on the WWW site. (I might move this doco.)
Re: nosh version 1.37
2018-02-20 16:13 GMT-03:00 Jonathan de Boyne Pollard: > > Guillermo: >> >> 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. > > A snapshot of the 1.38 development is in the usual place. See how far that > gets you. Farther, but not to the end: redo-ifchange[2]: ERROR: services/dbus-broker.service: Not done. redo-ifchange[2]: INFO: services/dbus-daemon.service: Redone. redo-ifchange[2]: ERROR: systemd/service-manager.socket: Not done. redo-ifchange[2]: ERROR: services/system-wide.conf: Not done. redo-ifchange[2]: INFO: convert/per-user/at-spi-dbus-bus.service: Redone. redo-ifchange[2]: INFO: convert/per-user/gconfd.service: Redone. redo-ifchange[2]: INFO: convert/per-user/per-user.conf: Redone. redo[1]: ERROR: all: Not done. Oh, look! $ grep gentoo source/services/*do source/convert/per-user/*do source/services/dbus-daemon.service.do: gentoo:*) ext=debian-linux ;; source/convert/per-user/at-spi-dbus-bus.service.do: gentoo:*) ext=redhat-linux ;; source/convert/per-user/gconfd.service.do: gentoo:*) ext=redhat-linux ;; source/convert/per-user/per-user.conf.do: gentoo:*) ext=linux ;; I could not spend much time looking into that myself once the weekend was over, but these look like the correct choices. Did someone else help with that? Well, I don't actually have the gconf and at-spi2-core packages installed at the moment, but looking at their ebuilds and the gnome2 eclass, it does look like Gentoo goes with upstream's defaults, so gconfd-2 and at-spi-bus-launcher would be indeed in /usr/libexec, like for RHEL / CentOS apparently. As for the missing .do scripts, if you are going to go this route: services/dbus-broker.service.do should symlink dbus-broker.service to dbus-broker.service.debian-linux systemd/service-manager.socket.do should symlink service-manager.socket to service-manager.socket.debian-linux services/system-wide.conf.do should symlink system-wide.conf to system-wide.conf.linux G.
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.
nosh version 1.37
The nosh package is now up to version 1.37 . * http://jdebp.eu./Softwares/nosh/ * https://www.freebsd.org/news/status/report-2017-07-2017-09.html#The-nosh-Project * http://jdebp.info./Softwares/nosh/ Some of the changes in this release are works in progress, that you will see fully realized in version 1.38 or later. Changes include: * There is a new chapter in the /nosh Guide/ for those wishing to make packages and ports of other softwares, or add service bundle support to existing packages and ports. * The external formats configuration import subsystem has been reorganized a bit. o Nothing uses the |JAVA_HOME| import system any more, where service bundles explicitly have their |JAVA_||HOME| variables set by configuration import, although it is retained. All service bundles instead use the |find-matching-jvm| mechanism to auto-detect a JVM matching their chosen criteria at start time. o The per-user services import is now in two parts. System-wide import sets up a |$HOME/.config/service-bundles/convert/| subdirectory for each (real user) user account; and each user can then use that, which contains a subordinate per-user configuration import mechanism, to set up imported per-user service bundles for things. o Per-user service source files for Desktop Bus and other services are now in their own subdirectory, as are converted keyboard maps for the userspace virtual terminals. * |static-networking| external format configuration import has been enhanced to set up |snort@/interface/| services and to handle |ipv6_cpe_wanif| and |ipv6_activate_all_interfaces| from |/etc/rc.conf|. * There is a new |make-read-only-fs| chain loading tool that is a placeholder for now. It is used in some service bundles generated by the |convert-systemd-units| tool, which now recognizes and converts |CPUAffinity|, |ProtectHome|, |ProtectSystem|, |ReadWriteDirectories|, |ReadOnlyPaths|, and |InaccessiblePaths| settings. * 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|. * There are some more service bundles in the collection that comes with the toolset: clickhouse-server, hue, udhcpc-log, minissdpd, rtkit-daemon, accounts-daemon, gdm3, speech-dispatcher, gdomap, blueman-mechanism, and sysvipc. * The per-user configuration import now recognizes and sets up per-user service bundles for a whole lot more per-user services. * On FreeBSD/TrueOS systems |setup-machine-id| now writes |/usr/local/etc/machine-id|. * The userspace virtual terminal services, the multiplexor and the terminal emulators, no longer run under the aegis of the |daemon| system account. Rather, they now have their own dedicated accounts under whose aegides they run. To go with that, there is now a |user-vt-realizer| group to which users can be added to grant them realizer (i.e. front-end I/O) access to the system-wide userspace virtual terminals. * A common build problem across several toolsets that occurs if one has set a |CDPATH|, has been fixed. Various tweaks have also been made to make life easier for Archnosh and ports to other operating systems.
