PHP 8.1 is available off the shelf in openSUSE Tumbleweed. I will shortly prepare a PHP 8.1 / tumbleweed version of the maintaina Horde containers. These will initially be broken due to some outdated language constructs. As PHP 7.4 will EOL by the end of this year, I decided not to bother with PHP 8.0 and ensure compatibility with PHP 8.1 right away, while staying compatible with PHP 7.4 until end of year. This is not fun. PHP 8.x provides several features which allow for more concise code. I will not be able to use them.
This also means that for the time being I will produce code which you may find more verbose than necessary. While Constructor promotion is mostly about being less verbose, Readonly Properties and Enums kill some of the pro-method arguments in the eternal discussion if getter methods or public properties are more appropriate interfaces. Union Types and Intersection Types allow a flexibility of method interfaces which PHP 7.4 can only emulate. You can get far by type hints for static analysis combined with boilerplate guard code inside a method and dropping type hints all along or using insufficient surrogate interfaces. But it is really not shiny. Maintaining software which shows its age has its tradeoffs.
Tag: OpenSUSE
bookmark_borderPHP 8 Horde (Maintaina)
Over the next few days, all Horde libraries and apps in the maintaina-com organization will be whitelisted for PHP 8x. in their FRAMEWORK_6_0 branch development versions. One next step will be a flavour of the OpenSUSE based containers and deployments which runs off PHP 8.0. While some few libraries have been enabled for PHP 8, it is almost certain that horde as a whole will not run correctly. Main culprits are the horde/rpc and horde/form packages and their user code, but there are some other ugly places that need attention.
Development Baseline at 7.4
Code in the maintaina-com repo will stay compatible with PHP 7.4 – at least for the time being. Decisions at Horde LLC may override that at some point or time may just march on. PHP 7.4 has been released two years ago, has ended active support 20 days ago and will be EOLed for upstream security support on November 28th 2022 – roughly 11 months to go. Linux distributions have a tradition to follow their own schedules and backport security fixes. OpenSUSE LEAP 15.3 ships with PHP 7.4 while openSUSE Tumbleweed has switched to PHP 8.0.13 – with PHP 8.1 versions becoming available from official repos soon.
This is a tough decision as PHP 8 and 8.1 have some really interesting features which would allow us to develop more elegant, more readable and more efficient code. For software that is not intended for this audience, I will immediately allow using 8.x-only features as soon as we are confident with Horde’s compatibility. This is going to be a major theme of January and possibly February.
No need to switch right now
If you are running Horde as of horde.org master branches or maintaina-com FRAMEWORK_6_0 branches off PHP 7.4, you should NOT switch right now. We will announce once we think any leftover issues are minor enough for an acceptable early adopter experience.
No particular love for 8.0.x
There is no guarantee our runtime will stay fixed at 8.0. PHP 8.1 offers a lot of new features and a considerable performance boost for some relevant scenarios. While making Maintaina Horde work with 8.x on a 7.4 feature baseline is the first step, the logical next step is upgrading feature baseline to 8.1 or higher. This will be much less of a problem if we get an official Horde 6 release in the meantime and users can choose between a properly conservative release version and a more adventurous Maintaina version. This is not something I have under control though. Horde LLC do as they find appropriate and sustainable and for many users, there is little reason to choose Maintaina over the official releases once we have a Horde 6 version that properly runs on recent PHP and supports Composer out of the box. I am perfectly fine with that and looking forward to it. I will always assist with a migration path as far as I can afford to.
Time is Money, Money buys Time
If you have an urgent commercial interest in a PHP 8-ready Horde version, you really do not want to rely on Maintaina’s timelines and priorities which may be subject to change. You will need to spend money. Approach somebody to do it for you, either Horde LLC or the company I work for, B1 Systems GmbH – both are formidable places to look for Horde-experienced development resources.
Update 2021-12-18 21:00 CET
I just ran the update to the metadata as a mass operation for everything which contains a .horde.yml file – the rest will have to wait until I stumble across it. I leveraged an edited version of horde/git-tools, some bash magic, some mass editing in vscode using their regex tool and some manual fixing.
- All packages now formally require “php”: “^7.4 || ^8”
- If horde-installer-plugin is required, I now go for “^2 || dev-FRAMEWORK_6_0” – however in maintaina-com/Core, I have a job that rebuilds composer.json on commit and this job showed me that the components tool needs an update in this aspect.
- SPDX license code warnings for LGPL and GPL versions have been remedied to LGPL-2.0-only, LGPL-3.0-only, GPL-3.0-only each
- Added the CI workflow where missing. Mostly it will fail until further editing. This is intentional.
- I did NOT unify all versions of CI workflow as some deviations are intentional. I did however unify PHP versions for the unit tests to “7.4”, “8.0” and “latest” and I did unify phpunit versions to “9.5” and “latest”.
- Unified/added the phpdoc workflow and the update-satis workflow as we had multiple versions for no good reason. I have settled for a version of the phpdoc job that will scan lib/, src/ and app/ if they exist
- Cleaned up a lot of metadata mess in the Kolab related packages.
- Removed some version: tags from composer.json files
- Removed the optional pear dependency of imp for the ASN1 implementation from phpseclib – need to look for a proper composer-ready and less outdated replacement.
While the mass changes themselves seem to have gone right, the resulting avalanche of CI jobs showed some issues:
- phpdoc job and update-satis job fail if they run in parallel and the satis repo content has changed since checkout. Either give the push commands in the loop a minute to wait each time or make the job smarter about handling these clashes. Still, failing is better than silently overwriting content
- Having so many versions of the CI job is not maintainable. Need to factor out the boilerplate into an action, make version requirements a config variable with a builtin default and have some mechanism for there rare cases where extra software is needed for meaningful QA, i.e. database and storage related items.
- After getting this migration done, upgrading the git-tools utility may be an interesting exercise in PHP 8 and PHPStan.
- I may have created unnecessary conflicts with some open pull requests. Sorry, contributors. I will improve.
bookmark_borderMaintaina Horde switches to openSUSE LEAP
Our Horde docker images have switched over from Tumbleweed to openSUSE LEAP once again.
Recently our container build CI job in github.com broke down unexpectedly. An investigation showed that Tumbleweed’s core libraries, especially libc, were too new for the CI’s build system, based on Ubuntu LTS.
This is the second time we abandoned the Tumbleweed basis for Horde docker containers. OpenSUSE Leap 15.3 uses a relatively old, but well-maintained, set of base libraries. Both Leap and Tumbleweed deliver PHP 7.4 as a basis for Horde. In both systems, we skip the packaged composer version for a static pick which we will update from time to time. We may switch over to packaged composer if we feel confident.
For users and administrators of the image, both Tumbleweed and Leap 15.3 should feel more or less the same. For end users of the delivered horde setup, there should not be any downsides. We will switch back to the Tumbleweed image in a while when we have picked a more recent version of Ubuntu.
bookmark_borderPEAR down – Taking Horde to Composer
Since Horde 4, the Horde ecosystem heavily relied on the PEAR infrastructure. Sadly, this infrastructure is in bad health. It’s time to add alternatives.
Everybody has noticed the recent PEAR break-in.
A security breach has been found on the http://pear.php.net webserver, with a tainted go-pear.phar discovered. The PEAR website itself has been disabled until a known clean site can be rebuilt. A more detailed announcement will be on the PEAR Blog once it’s back online. If you have downloaded this go-pear.phar in the past six months, you should get a new copy of the same release version from GitHub (pear/pearweb_phars) and compare file hashes. If different, you may have the infected file.
While I am writing these lines, pear.php.net is down. Retrieval links for individual pear packages are down. Installation of pear packages is still possible from private mirrors or linux software distribution packages (openSUSE, Debian, Ubuntu). Separate pear servers like pear.horde.org are not directly affected. However, a lot of pear software relies on one or many libraries from pear.php.net – it’s a tough situation. A lot of software projects have moved on to composer, an alternative solution to dependency distribution. However, some composer projects have dependency on PEAR channels.
I am currently submitting some changes to Horde upstream to make Horde libs (both released and from git) more usable from composer projects.
Short-term goal is making use of some highlight libraries easier in other contexts. For example, Horde_ActiveSync and Horde_Mail, Horde_Smtp, Horde_Imap_Client are really shiny. I use Horde_Date so much I even introduced it in some non-horde software – even though most functionality is also somewhere in php native classes.
The ultimate goal however is to enable horde groupware installations out of composer. This requires more work to be done. There are several issues.
- The db migration tool checks for some pear path settings during runtime https://github.com/horde/Core/pull/2 Most likely there are other code paths which need to be addressed.
- Horde Libraries should not be web readable but horde apps should be in a web accessible structure. Traditionally, they are installed below the base application (“horde dir”) but they can also be installed to separate dirs.
- Some libraries like Horde_Core contain files like javascript packages which need to be moved or linked to a location inside another package. Traditionally, this is handled either by the “git-tools” tool linking the code directory to a separate web directory or by pear placing various parts of the package to different root paths. Composer doesn’t have that out of the box.
Horde already has been generating composer manifest files for quite a while. Unfortunately, they were thin wrappers around the existing pear channel. The original generator even took all package information from the pear manifest file (package.xml) and converted it. Which means, it relied on a working pear installation. I wrote an alternative implementation which directly converts from .horde.yml to composer.json – Calling the packages by their composer-native names. As horde packages have not been released on packagist yet, the composer manifest also includes repository links to the relevant git repository. This should later be disabled for releases and only turned on in master/head scenarios. Releases should be pulled from packagist authority, which is much faster and less reliant on existing repository layouts. https://github.com/horde/components/pull/3
To address the open points, composer needs to be amended. I currently generate the manifests using package types “horde-library” and “horde-application” – I also added a package type “horde-theme” for which no precedent exists yet. Composer doesn’t understand these types unless one adds an installer plugin https://github.com/maintaina-com/installers. Once completed and accepted, this should be upstreamed into composer/installers. The plugin currently handles installing apps to appropriate places rather than /vendor/ – however, I think we should avoid having a super-special case “horde-base” and default to installing apps directly below the project dir. Horde base should also live on the same hierarchy. This needs some additional tools and autoconfiguration to make it convenient. Still much way to go.
That said, I don’t think pear support should be dropped anytime soon. It’s the most sensible way for distribution packaging php software. As long as we can bear the cost involved in keeping it up, we should try.
bookmark_borderCurrent (10/2018) Tumbleweed on Raspberry Pi 1
Hallo,
I just had a little struggle getting the current tumbleweed to run on the original Raspberry Pi (first generation, though the revision with larger RAM).
Just in case this helps anybody: I did not have any luck with a fresh openSUSE Tumbleweed image of one of the current arm6 builds. Don’t know why.
Here’s what I did:
– Download a pretty old known-good OpenSUSE 13.1 built by Bernhard Wiedemann
http://www.zq1.de/bernhard/linux/opensuse/raspberrypi-opensuse-latest.img.xz
Unzip, dump it to SD Card
xz -d raspberrypi-opensuse-latest.img.xz
dd if=raspberrypi-opensuse-latest.img of=/dev/mmcblk0 bs=8M
Boot up, change to text console (CTRL + ALT + F2)
Log In (root/linux)
Change Password (passwd)
nano /etc/zypp/repos.d/oss131.repo
Change baseurl line to
baseurl=http:/download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/
Save and get out (CTRL+X, Y)
#Resize partition and FS as this build won’t do:
# Adjust to more if your card is larger or to less if you need a more advanced partitioning scheme
parted resize 3 16G
resize2fs /dev/mmcblk0p3
zypper ref
zypper up gzip rpm
zypper dup –download in-advance
#(super conservative, get all needed packages first) – This is going to take quite a while
reboot, power cycle
Note that you will end up with a system booting into X11 login. You should probably change the default systemd target and maybe also get rid of some software. And you really don’t want a server with ssh password “linux”, so better don’t skip changing the PW
bookmark_borderI managed to bring large file uploads into PHP 5.6
A colleague of mine recently faced difficulties to upload large opensource DVD images (>4G) into ownCloud during a demonstration. After some analysis, it turned out that it wasn’t ownCloud’s fault at all: PHP itself simply could not cope with large file uploads due to an overflow in some key variables. Further research showed that this had been known since 2008 under the bug number #44522. There was even a half completed patch available. I decided to pick up the existing patch and comments from developers and critics and port it to recent PHP, also making some changes to data type definitions. After a discussion on the PHP list, it turned out that this patch cannot be shipped for any upstream PHP before the next release (PHP 5.6) due to backwards compatibility. SUSE Enterprise Linux and openSUSE ship a similar patch with their PHP packages though. Finally, Michael Wallner order kopen clomid 100mg met nederland verzending added tests and included the patch into the PHP master branch.
There only has been very basic testing for Windows and other non-linux PHP ports yet but there is still some time to do this before PHP 5.6 gets released.
cenforce 200 mg te koop
bookmark_borderNo Bullshit #1: Apache vhost config AllowOverride All does not activate mod_rewrite
This is beginner’s talk, but I have seen it too many times anyway.
A lot of tutorials on the web claim that you have to state “AllowOverride All” in an apache config and it magically activates mod_rewrite somehow.
This is all bullshit. Your mileage may vary, you may be lucky on debianish systems. It’s not very secure anyway.
Here’s what you do instead:best acquistare dianabol 25 mg online in italia
(suse)
yourserver:# /etc/apache2/conf.d # a2enmod rewrite
yourserver:# /etc/apache2/conf.d # vim /etc/apache2/vhosts.d/www.somesite.com.conf
<VirtualHost *>
DocumentRoot /srv/www/somesite.com/wordpress
ServerName www.somesite.com
ServerAdmin ralf.lang@somesite.com
<Directory /srv/www/somesite.com/wordpress>
Options +FollowSymlinks
RewriteEngine On
## put your rewriting-related .htaccess file content here, for example wordpress
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
## end put stuff here
## ... more vhost stuff to follow
## finally
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
yourserver:# rcapache2 reload
(debian)
yourserver:~# /etc/apache2/conf.d # a2enmod rewrite
yourserver:~# vim /etc/apache2/sites-available/www.somesite.com
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName www.somesite.com
DocumentRoot /var/www/somesite.com/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/somesite.com/>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule> Options Indexes +FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
## more debianish vhost stuff
## ...
## finally
</VirtualHost>
yourserver:/etc/apache2/conf.d # a2ensite www.somesite.com
yourserver:/etc/init.d/apache2 reload
Here’s the explanation why:
AllowOverride allows a special hidden file .htaccess in any directory of your vhost to override settings from your apache vhost configs, especially security-related stuff like URL rewriting and symlink behaviour. This is fine for your hacky development setup but you do not want this in production. First, it’s slow because every lookup has to check for a .htaccess file and parse it if present. Second, it’s a hassle to debug once something screws up. Something will screw up at some point. Usually you are better off configuring your vhost properly.
Why does it work on debian?
Debian systems often have mod_rewrite enabled (loaded) but not active (working) in the default config. Allowing .htaccess files to magically activate them will work in many cases and provide a confusing problem for the rest.
Why doesn’t it work on openSUSE 12 and SLES 11??
SLES is optimized for enterprise environments where security counts. If you don’t enable overriding, it’s usually turned off. If you don’t enable mod_rewrite globally or for the site, it won’t magically be loaded later on. This leads to more tedious work but also a more predictable environment for admins under fire.
Stop confusing people. Tell them how to do it right and make them understand why it works. It will spare you trouble.
Fondos de pantalla varón fisicoculturismo fitness entrenamiento músculos deporte descargar imagenes lo esencial winstrol ahorra en manualidades codigo promocional envio gratis: revisa los leggings deportivos top seller mujer push up leggings fitness patchwork y pantalones elásticos entrenamiento de culturismo pa.
bookmark_borderInstalling Horde 4 pear packages to a custom pear location (SUSE)
When installing horde to a custom pear location, you need to run the pear of your custom location, not the system pear with the custom location’s config.
So the steps would be:
1 mkdir /srv/horde 2 pear config-create /srv/horde/ /srv/horde/pear.conf 3 pear -c /srv/horde/pear.conf install PEAR
as the install docs say but then:
4 /srv/horde/pear/pear -c /srv/horde/pear.conf channel-discover pear.horde.org 5 /srv/horde/pear/pear -c /srv/horde/pear.conf run-scripts horde/Horde_Role 6 /srv/horde/pear/pear -c /srv/horde/pear.conf install --alldeps horde/groupware
Otherwise running the Horde_Role script will fail saying
config-set (horde_dir, /srv/horde/, user) failed, channel pear.php.net
This was experienced on SLES11SP1, SLES11SP2 and openSUSE Factory.
I did not test this for any debian based products yet.
bookmark_borderHorde 5 is coming / Horde 3 support ends
The spring 2012 release of the Horde Application Suite and Framework will probably be called Horde 5. In a recent discussion the majority of developers agreed on a new major revision for some changes that some view as minor backward compatibility break. Currently planned features include:
- New standard UI for “traditional view”
- Move of Ajax code from specific apps to a common framework
- Release of a small inventory management app (sesha)
- complete configuration via UI (likely)
- Webmail: Write support for smartphone view
- Calendar: Resource calendar support for ajax view
At the same time, Horde 3 will no longer receive any support. Horde 3 has been around since 2005 and really has reached its end of life.
Since the Horde 4 release, The Horde 3 family of applications has only received critical bugfixes and security updates, the last being released this february. You should really consider updating to Horde 4 – the transition from Horde 3 to Horde 4 has been tested and done by numerous people and the transition from Horde 4 to Horde 5 should run smoothly as both releases are PEAR based.
I have already removed all things horde3 from OpenSUSE-Factory. OpenSUSE 12.2 will not ship Horde 3 any longer. Depending on packaging progress, openSUSE 12.2 will very likely ship Horde 5 or the most recent Horde 4 release. Horde 4 maintainence will continue.
Horde 3 Packages in the server:php:applications repository (see here) will be available at least until openSUSE 12.1 runs out of maintainence. I won’t give these much attention though. Please also note Eleusis Password Manager will be dropped with currently no planned replacement.
bookmark_borderOpenSUSE Build Service rebranded
Today the openSUSE project announced that their packaging solution OpenSUSE Build Service will be re-branded to highlight the crossplatform nature of the product. The new name of the platform will be Open Build Service (OBS). Commercial support will also be available soon.
Ralph Dehner, CEO at B1 Systems GmbH noted:
“In the past B1 Systems has written build environments for the customers by itself. With the open Build Service now exists a “standard” which makes it easy to build packages for different distributions and architectures.
This will be also interesting for many other open source projects.”
Inicio – dieta y entrenamiento de culturismo femenino, culturismo femenino vs fisico – my blog comprar pildoras para la ereccion blog de musculacion blog de musculacion – blog de musculacion, rutinas de entrenamiento, noticias e imagenes de musculacion.