You are not logged in.
I just filed a "bug" report about the php packages from deb.sury.org breaking my system. The exchange can be seen here:
But the end result is this:
Yes, the package rely on systemd-tmpfiles.
So, if you are using this repository, you may want to remove it from your sources.list because it will break what you have got.
Hope this helps someone.
Last edited by nixer (2020-02-21 11:38:17)
Offline
Thx, this is a really bad news :-(
Offline
sury is also the DD for php in Debian, so let's hope he won't enforce it on official debian repos too (= devuan). that would be a big fail for all debian web server ecosystem.
Offline
For what it is worth, I will add his (sury - debian packager) last comment in the bug report linked to above:
It's more than enough to have support for Distributions 4 years old. I am not going to complicate code purely on ideological reasons. Devuan needs to supply shims for the non-init parts like systemd-tmpfiles. When (and if) Debian splits systemd-tmpfiles into a separate package and add opentmpfiles, I will happily adapt the packages to use it. Until the time it is what it is.
It wasn't hard, nor did it take too long to remove deb.sury.org packages from my webserver and replace it with debian's packages.
Remove deb.sury packages:
apt remove php* --purge
Alter sources.list file to remove sury's repo line. Then,
apt update
Install php7.3:
apt install php7.3-fpm libapache2-mod-php
So for now, php7.3-fpm is working. I will miss using sury's packages and its capability to easily use different php versions on the same server.
I have not used debian's packages in a few years. I will have to search if they will allow for multiple php versions. Time to start searching.
Last edited by nixer (2020-02-21 12:13:43)
Offline
I guess now we have to try to compile the packages ourselves :-(
Offline
szutt,
I just checked my email and I found a message from sury and I think it was meant for you and not me. With regards to the snippet you mentioned below,
ifeq (devuan,$(DPKG_VENDOR))
ENABLE_SYSTEMD = no
endif
sury replied:
the snippet you supplied won't work because it needs to be applied at compile time.
You can use equivs package and symlink to opentmpfiles-tmpfiles from opentmpfiles package to workaround the dependency.
Can anyone instruct, or elaborate on how to do this? I have never used the equivs package, or opentmpfiles package so right now I am lost. But I will be glad to try any suggestions. I do not see how this will work around the dependency of needing, and thus avoiding, the installation of systemd. But then, I am asking for clarification.
Last edited by nixer (2020-02-21 18:44:44)
Offline
I guess now we have to try to compile the packages ourselves :-(
Ditto, im gonna gave to try to make a dev/builder system and see if I can revert Sury's recent changes and buid something workable.
I'm stuck way back on on kernel 2.6, since I use drbd/openvz6 for container hosting. Last time i checked though, various things in d9/ascii were complaining with such an old kernel, so until I find an alternative (bsd or maybe even lxc) it's jessie.
It looks like the relevant git repo is here:
https://salsa.debian.org/php-team/php
And at a first glance the change to try reverting, that, makes sury packages require systemd is:
https://salsa.debian.org/php-team/php/c … 1ab9285adb
and maybe also we don't need this:
https://salsa.debian.org/php-team/php/c … 00619ef550
Sury dosen't officially support devuan and seems to be drinking the debian/systemd cool-aid. I guess we've been lucky so far... His choice, it sucks.. but now that he's made the packaging incompatible that repo will need to be forked and maintianed separately for devuan.
Last edited by JXX77 (2020-02-21 21:09:06)
Offline
sury replied:
the snippet you supplied won't work because it needs to be applied at compile time.
You can use equivs package and symlink to opentmpfiles-tmpfiles from opentmpfiles package to workaround the dependency.Can anyone instruct, or elaborate on how to do this?
General instructions here: https://debian-handbook.info/browse/sta … ckage.html
Here's my attempt:
Section: misc
Priority: optional
Standards-Version: 3.9.2
Package: systemd
Version: 241-7~deb10u3
Maintainer: Head_on_a_Stick
Depends: opentmpfiles
Architecture: any
Links: /usr/bin/opentmpfiles /bin/systemd-tmpfiles
Description: Fake systemd package
Provides /bin/systemd-tmpfiles by symlinking from opentmpfiles.
^ That installs a symlink at /bin/systemd-tmpfiles that points to /usr/bin/opentmpfiles, the package is called "systemd" and so should satisfy the PHP dependency requirement.
I've no idea if it will actually work though (I have systemd installed in my box and I don't use PHP) and this is the first time I've tried to use equivs. Somebody else will probably be able to do better.
Brianna Ghey — Rest In Power
Offline
I'm fairly confident, that this won't work. One of the things I tried, was an empty package, called 'systemd' -- and then i manually reverted the change to the php-fpm init file post install.
In this way, it used a function for tmpfiles in the init file once more. And didn't then depend on systemd-tmpfiles.
It seems that with the new php packaging, fpm is now configured and built with the option --with-fpm-systemd. This enables HAVE_SYSTEMD at compile time and makes php-fpm itself depend on systemd functionality. Once we get past the tmpfiles init thing, fpm itself then fails since it expects to be able to use systemd api's as part of fpm's normal operation.
FPM starts logging this kind of thing to syslog:
[21-Feb-2020 16:22:59] NOTICE: systemd monitor interval set to 10000ms
... so what we need is the package is compiled differently, with the option --without-fpm-systemd
essentially the debian jessie package is now not compatible with devuan jessie.. So I think we're back to needing a specific dist/build that specifically disables systemd.
Hopefully that --without-fpm-systemd option is still available in the upstream php sources.
Last edited by JXX77 (2020-02-22 01:28:54)
Offline
HOAS,
As usual, you gave of your time to help someone out and it is appreciated. I thank you for this. I will let you know what happened when I gave this a try.
I installed equivs which brought in over 40mb of packages even with the --no-install-recommends command.
opentmpfiles package only exists in the debian bullseye/devuan chimaera repository, so I had to install this with the 'apt -t chimaera install opentmpfiles' command but it installed and brought in no dependencies.
The actual commands of 'equivs-control systemd' and 'equivs-build systemd' worked fine and I had the .deb file ready to install.
I have spent the last 5 years trying to keep systemd off of my machine. Believe me, I got a heart tremor when I ran the command
dpkg -i systemd*.deb
It was then I got these error responses:
root@localhost:/home/craig/temp# dpkg -i systemd*.deb
Selecting previously unselected package systemd.
dpkg: regarding systemd_241-7~deb10u3_amd64.deb containing systemd:
elogind conflicts with systemd
systemd (version 241-7~deb10u3) is to be installed.dpkg: error processing archive systemd_241-7~deb10u3_amd64.deb (--install):
conflicting packages - not installing systemd
Errors were encountered while processing:
systemd_241-7~deb10u3_amd64.deb
So, I removed elogind and it installed the libpolkits* and such. Next command:
root@localhost:/home/craig/temp# dpkg -i systemd*.deb
(Reading database ... 76748 files and directories currently installed.)
Preparing to unpack systemd_241-7~deb10u3_amd64.deb ...
Unpacking systemd (241-7~deb10u3) ...
dpkg: dependency problems prevent configuration of systemd:
eudev (3.2.7-6) breaks systemd (>> 220) and is installed.
Version of systemd to be configured is 241-7~deb10u3.dpkg: error processing package systemd (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
systemd
I don't think that anything named "systemd" (even dummy packages) wants to go on this system! It is times like this I wish I were knew how to build packages in devuan linux!
JXX77,
I'm fairly confident, that this won't work.
It didn't but I wanted to try.
Offline
elogind conflicts with systemd
D'oh!
Well you could try naming the fake package systemd-fake instead then grab the PHP source from packages.sury.org, edit debian/control and change the Depends section for systemd to
systemd | systemd-fake,
Then bump the version, build the custom package and install that.
If it works then you could open a new request upstream and ask that the Depends be changed there so that the equivs suggestion actually works for Devuan.
It would even be possible for the Devuan devs to offer an official systemd-fake package to work around issues like this and they could liaise with the Debian devs to make the alternative dependency universal for all the packages that need it. The recent vote about systemd in Debian did result in a commitment to work with downstream distributions to provide solutions like this.
Audacious and unlikely, perhaps. But worth a shot :-)
Brianna Ghey — Rest In Power
Offline
If I try to rebuild the packages myself, should I take the opportunity to separate according to the init system? For example:
php7.3-fpm
Depends: php7.3-fpm-upstart | php7.3-fpm-sysv | php7.3-fpm-systemd
Last edited by szutt (2020-02-23 07:46:48)
Offline
I've got an apparently working but as-yet untested build, using sury's debian sources for the main - but reverting just the changes made to remove support for non-systemd builds. And a small change to debian/rules to always consider systemd as disabled.
This seems to work for all php versions currently on devuan Jessie, just apt-get the source from the sury repo and make the below changes, and rebuild. (dpkg-buildpackage -rfakeroot )
Before these php builds can be installed, there are a couple of other packages needed from the sury repo - namely apt-get source libsodium, php-defaults, and pkg-php-tools.
However unless anyone is offering to maintain the php repo for devuan - I cetainly can't.. php and particularly this packaging, are very complex animals. i don't think any major reworking/changes other than what is strictly necessary should be done.
#diff -ruN a/debian/changelog b/debian/changelog
--- a/debian/changelog 2020-02-22 20:56:57.583439580 +0000
+++ b/debian/changelog 2020-02-22 21:54:20.175382451 +0000
@@ -1,3 +1,10 @@
+php7.2 (7.2.28-1+0~20200220.36+devuan1~1.gbpcf4a75) unstable; urgency=medium
+
+ * Make it work (Devuan Jessie)
+ * Revert the removal of systemd/upstart functions
+ * Always disable systemd options when building
+
+ -- JXX77 <jxx77@dev1galaxy> Sat, 22 Feb 2020 20:58:55 +0100
+
php7.2 (7.2.28-1+0~20200220.36+debian8~1.gbpcf4a75) unstable; urgency=medium
** SNAPSHOT build @cf4a75fa49ec4131a9ec9b1774402ea59c6993da **
diff -ruN a/debian/control b/debian/control
--- a/debian/control 2020-02-22 20:56:57.583439580 +0000
+++ b/debian/control 2020-02-22 21:54:20.171382451 +0000
@@ -10,10 +10,10 @@
bison,
chrpath,
debhelper (>= 9.20150101),
- default-libmysqlclient-dev | libmysqlclient-dev,
+ default-libmysqlclient-dev | libmysqlclient-dev | libmariadb-dev,
default-mysql-server <!nocheck> | mysql-server <!nocheck> | virtual-mysql-server <!nocheck>,
dh-apache2,
- dh-systemd (>= 1.3) [linux-any],
+ base-files [linux-any],
dpkg-dev (>= 1.16.1~),
firebird-dev [!hurd-any !m68k !hppa !ppc64] | firebird2.5-dev [!hurd-any !m68k !hppa !ppc64] | firebird2.1-dev [!hurd-any !m68k !hppa !ppc64],
flex,
@@ -55,8 +55,8 @@
libsodium-dev,
libsqlite3-dev,
libssl-dev,
- libsystemd-dev [linux-any],
- libtidy-dev (>= 1:5.2.0),
+ base-files [linux-any],
+ libtidy-dev,
libtool (>= 2.2),
libwebp-dev,
libwrap0-dev,
@@ -64,7 +64,7 @@
libxmlrpc-epi-dev,
libxmltok1-dev,
libxslt1-dev (>= 1.0.18),
- libzip-dev (>= 1.0.0),
+ libzip-dev,
locales-all | language-pack-de,
netbase,
netcat-traditional,
@@ -242,7 +242,6 @@
php7.2-common (= ${binary:Version}),
php7.2-json,
php7.2-opcache,
- systemd,
tzdata,
ucf,
${misc:Depends},
diff -ruN a/debian/php-fpm.init b/debian/php-fpm.init
--- a/debian/php-fpm.init 2020-02-22 20:56:57.583439580 +0000
+++ b/debian/php-fpm.init 2020-02-22 21:54:20.171382451 +0000
@@ -93,10 +93,31 @@
return 0
}
+do_tmpfiles() {
+ local type path mode user group
+
+ [ "$1" != no ] && V=-v
+
+ TMPFILES=/usr/lib/tmpfiles.d/php@PHP_VERSION@-fpm.conf
+
+ if [ -r "$TMPFILES" ]; then
+ while read type path mode user group age argument; do
+ if [ "$type" = "d" ]; then
+ mkdir $V -p "$path"
+ chmod $V "$mode" "$path"
+ chown $V "$user:$group" "$path"
+ fi
+ done < "$TMPFILES"
+ fi
+}
+
case "$1" in
start)
+ if init_is_upstart; then
+ exit 1
+ fi
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
- systemd-tmpfiles --remove --create /usr/lib/tmpfiles.d/php@PHP_VERSION@-fpm.conf
+ do_tmpfiles $VERBOSE
case "$?" in
0)
do_start
@@ -109,6 +130,9 @@
esac
;;
stop)
+ if init_is_upstart; then
+ exit 0
+ fi
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
@@ -120,6 +144,9 @@
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
reload|force-reload)
+ if init_is_upstart; then
+ exit 1
+ fi
log_daemon_msg "Reloading $DESC" "$NAME"
do_reload
log_end_msg $?
diff -ruN a/debian/php-fpm.maintscript b/debian/php-fpm.maintscript
--- a/debian/php-fpm.maintscript 2020-02-22 20:56:57.583439580 +0000
+++ b/debian/php-fpm.maintscript 1970-01-01 01:00:00.000000000 +0100
@@ -1 +0,0 @@
-rm_conffile /etc/init/php@PHP_VERSION@.conf 7.4.2-8~ php@PHP_VERSION@-fpm
diff -ruN a/debian/php-fpm.upstart b/debian/php-fpm.upstart
--- a/debian/php-fpm.upstart 1970-01-01 01:00:00.000000000 +0100
+++ b/debian/php-fpm.upstart 2020-02-22 21:54:20.175382451 +0000
@@ -0,0 +1,19 @@
+# php@PHP_VERSION@-fpm - The PHP FastCGI Process Manager
+
+description "The PHP @PHP_VERSION@ FastCGI Process Manager"
+author "Ondřej Surý <ondrej@debian.org>"
+
+start on runlevel [2345]
+stop on runlevel [016]
+
+# you can uncomment this with recent upstart
+# reload signal USR2
+
+pre-start script
+mkdir -p /run/php
+chmod 0755 /run/php
+chown www-data:www-data /run/php
+end script
+
+respawn
+exec /usr/sbin/php-fpm@PHP_VERSION@ --nodaemonize --fpm-config /etc/php/@PHP_VERSION@/fpm/php-fpm.conf
diff -ruN a/debian/rules b/debian/rules
--- a/debian/rules 2020-02-22 20:56:57.583439580 +0000
+++ b/debian/rules 2020-02-22 21:54:20.171382451 +0000
@@ -115,6 +115,10 @@
MYSQL_SOCKET := $(MYSQL_DATA_DIR)/mysql.sock
endif
+# Always Disable Systemd
+ CONFIGURE_SYSTEMD := --without-fpm-systemd
+ DH_SYSTEMD :=
+
ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH),amd64 armel armhf i386 ia64 powerpc))
CONFIGURE_DTRACE_ARGS := --enable-dtrace
else
@@ -229,7 +233,7 @@
--with-config-file-scan-dir=/etc/php/$(PHP_NAME_VERSION)/fpm/conf.d \
$(COMMON_CONFIG) \
--with-libevent-dir=/usr \
- --with-fpm-systemd
+ $(CONFIGURE_SYSTEMD)
export phpdbg_config = \
--prefix=/usr --enable-phpdbg --enable-cli --disable-cgi \
@@ -257,7 +261,7 @@
#$(info Enabled config $(ext_config))
%:
- dh $@ --with systemd --with apache2 --without autoreconf $(PARALLEL)
+ dh $@ $(DH_SYSTEMD) --with apache2 --without autoreconf $(PARALLEL)
PREPARE_FILES := $(addprefix debian/,$(shell cat debian/prepare-files))
Looks like the php7.3 and newer builds to work, you need to have build pcre2, from here;
( the stock pcre3-dev package is actually an older build - pcre2 is the where the current new builds are happening)
https://packages.debian.org/source/stable/pcre2
http://deb.debian.org/debian/pool/main/ … 0.32-5.dsc
http://deb.debian.org/debian/pool/main/ … rig.tar.gz
http://deb.debian.org/debian/pool/main/ … -5.diff.gz
Last edited by JXX77 (2020-02-23 18:55:54)
Offline
@JXX77 You're right, maintaining the php repo for devuan is a big piece of work. So, the workflow should be sury's repo (systemd only) -> devuan's repo.
I just rebuild successfully php7.3 under jessie and ascii with sury's sources. Like you I thought to revert the changes but I haven't tried it yet.
Yes, this would actually be easier to maintain.
Offline
Ok folks,
Here's where I've got to.. I think, I might just have everything rebuilt on devuan1/jessie . -- That's php5.6 thru to 7.4.3.
Deb Sources and amd64 binary/debs are linked below.
Offline
That's great! Thanks a lot. Now we must figure out how to maintain that ^^
Offline
Hi All,
This is a small update, I've now installed the packages locally and they seem to work for my Devuan.
I've rebuilt them with the tag devuan1~2, and reverted one more patch, which moved some pre/postrm commands into the systemd unit file.
It's a make-it-work build.. ie, whatever it takes to make it build on Jessie. It appears to work, but hasn't been properly or thoroughly tested.
* Make it work (Devuan Jessie)
* Always disable systemd when building
* Revert, Remove upstart support, use systemd-tmpfiles (cbd5f429)
* Revert, Move update-alternatives call to systemd start script (718539bc)
updated amd64-debs (for jessie) and dpkg sources are here:
https://mega.nz/#!ohAh1IhK!uuyHxOKzhaol … ggQF0u_tN4
Regards,
JXX77
Offline
### PHP Rebuilds for Devuan Jessie
deb https://pkgs.tdrnetworks.com/apt/devuan jessie main
Offline
### PHP Rebuilds for Devuan Jessie
Would these work for ascii and/or beowulf, or will they need to be rebuild for each release? I guess I could go ahead and try, but I thought I would ask first to save some time now and possible some breakage down the road.
Edit: Curiosity got the best of me so I had to give it a try. I had previously removed the sury packages and replaced with debian php7.3-fpm and had everything working correctly. So I then purged the debian php7.3* packages and then tried to install these packages in a beowulf (mini.iso dated 2-14-20) install which:
root@localhost:/home/craig# apt install php7.3-fpm
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:The following packages have unmet dependencies:
php7.3-fpm : Depends: php7.3-cli but it is not going to be installed
Depends: php7.3-common (= 7.3.15-1+0~20200220.53+devuan1~2.gbp931d08) but it is not going to be installed
Depends: php7.3-json but it is not going to be installed
Depends: php7.3-opcache but it is not going to be installed
Depends: libssl1.0.0 (>= 1.0.1) but it is not installable
E: Unable to correct problems, you have held broken packages.root@localhost:/home/craig# apt policy openssl
openssl:
Installed: 1.1.1d-1+0~20191009.15+debian10~1.gbpd6badf
Candidate: 1.1.1d-1+0~20191009.15+debian10~1.gbpd6badf
Version table:
*** 1.1.1d-1+0~20191009.15+debian10~1.gbpd6badf 100
100 /var/lib/dpkg/status
1.1.1d-0+deb10u2 500
500 http://deb.devuan.org/merged beowulf/main amd64 Packages
500 http://deb.devuan.org/merged beowulf-security/main amd64 Packages
An uninstall and reinstall of openssl using apt did not help this issue, so I will leave it as it is here. I just thought I would let someone else know if they were as curious as I am about this working. If I did something wrong, feel free to let me know.
Last edited by nixer (2020-03-01 21:00:59)
Offline
Havent tried, you'd probably need to grab the dpg source from the repo, and try rebuild them on the newer release. These binaries were built on deb8, specifically Devuan Jessie.
If I get a chance next week, I'll try to run a rebuild on devuan Ascii (~ deb9) , see if i hit any roadblocks. For the moment, all I can say is they seem to work on Jessie.
I see there's some new discussion back on sury's github about putting in an equivs package, linking systemd-tmpfiles to opentmpfiles. That might help if the backported code stops working but it's not a complete fix IMO -- since his PHP-FPM is now built, with a specific compile time option enabling systemd integration;; so it's not just about tmp files call in the init script - his php-fpm builds now look towards systemd api's for general process management. Something that now needs to be undone by building php differently..
Bow to the new systemd gods, so enforced on us by the debian peeps -- or try to maintain a separate set of builds without these recent changes to the packaging/build process. What I've put out there could be a start I guess; but there's still a question of who can maintain it goign forward, or even how it gets supported.
Offline
Yes, Devuan needs long-term commitment from its users if it is going to survive. That's not someone else's job. Every user should do their part.
Online
Just noticed this today. We currently use Jessie with the PHP 7.2 from sury.org but luckily we don't use php fpm at all and everything appears to be OK.
Note however that we've been leaving the sury.org repo commented out of /etc/apt/sources.list.d/php.list, and uncommenting only to update php. That is a) uncomment the sury repo, b) apt-update, and c) apt-get install --only-upgrade "php7*", d) comment out the repo, and e) apt-update.
The original reason for that was the fact that sury.org wanted to pull in a different version of openssl. I have no idea why, but we wanted to avoid that. As far as we can tell it wasn't necessary, so we went with the above for php only.
Tom
Offline
Hi Folks,
We have a set of sources and PHP rebuilds up now, for Devuan Ascii.
You can choose from either of the below, as appropriate.
### PHP Rebuilds for Devuan Jessie
deb https://pkgs.tdrnetworks.com/apt/devuan jessie main
deb-src https://pkgs.tdrnetworks.com/apt/devuan jessie main
### PHP Rebuilds for Devuan Ascii
deb https://pkgs.tdrnetworks.com/apt/devuan ascii main
deb-src https://pkgs.tdrnetworks.com/apt/devuan ascii main
Offline
Hi Folks,
I'm running Debian Sid (without systemd), just want to give few info in the hope that are usefull:
I don't think you need to rebuild this package (althougth you are free to do so if you prefer).
I filed a bug for this with a patch
https://bugs.debian.org/cgi-bin/bugrepo … bug=952895
which was rejected because the maintainer wants opentmpfiles to be a drop in replacement to systemd-tmpfiles
https://bugs.debian.org/cgi-bin/bugrepo … bug=952897
wich will not happen before the tech commettee rules about this bug
https://lists.debian.org/debian-ctte/20 … 00003.html
Yeah...
But I mailed the php-fpm maintainer in private explaining that installing systemd will remove my desktop (because of elogind), so he added this commit
https://salsa.debian.org/php-team/php/- … e35adf50d4
In short, for now create a package that provides systemd-tmpfiles, depends on opentmpfiles and ships a symlink systemd-tmpfiles --> opentmpfiles-tmpfiles, wait for the next debian release of php7.x-fpm and it should work.
FPM starts logging this kind of thing to syslog:
[21-Feb-2020 16:22:59] NOTICE: systemd monitor interval set to 10000ms
I have this too but it looks it's working even if don't have systemd installed: it's not working for you?
Lorenzo
Offline
I'm kind of disillusioned by Sury's response to this. His cavalier response that - well, devuan wasn't ever supported anyway just isn't helpful.
I'll guess I'll try to continue rebuiding new releases -- without systemd baked in -- as time allows, we'll have to see how that goes. it may become more difficult over time as sury/debian change/tweak their packages to further rely on systemd quirks, api's and functions.
I don't necessarily see a problem with moving the responsibility for tmp files management over to opentmpfiles, provided that is then made available as a package/depencency. But it shouldn't require a systemd equivs package, that seems hacky and not a sensible longterm solution. His code, if we're going to use it should check to see which command is available, and then use it.
I haven't looked at exactly what the PHP-FPM code is doing when it reports the "systemd monitor" stuff to syslog, I don't know if it's trying to negotiate with systemd on some level, or if it's just making information available. Regardless, it's writing unnecessary log lines and executing un-necesary code, so it seems better to me to build a package --without-fpm-systemd. So that the code isn't there and isn't running.
Offline