Sync php.ini with upstream php.ini as of PHP 8.2

Drop PHP 7.3 and 7.4

Sync php.ini with upstream php.ini as of PHP 8.2

Sync base config with upstream config

Merge branch 'main' into v8.2

Sync base config with upstream config

Merge branch 'main' into v8.0

Sync php.ini with upstream php.ini as of PHP 8.2

Sync base config with upstream config

Merge branch 'main' into v8.1

Sync php.ini with upstream php.ini as of PHP 8.2

Sync base config with upstream config

Merge branch 'main' into v8.0

@PhrozenByte do you plan to do the job here? Anybody else interested? Otherwise I can give it a try within a couple of weeks, but I can't guarantee at the moment.

I'm afraid I'm not going to have enough time to look into how to add new packages to FCOS, never did that before. Would be great if someone more experienced picks this up :+1:

See https://picocms.org/docs/#url-rewriting

So that will make them capitalisation-insensitive (and whatever other rules apply to the theme's meta)?

Registered meta headers don't really make headers case insensitive, but rather rename them. So Tags: tags basically takes the original "Tags" header and renames it to "tags". Tags: foobar would rename the original "Tags" header to "foobar".

Will it become fully case-sensitive then, all lowercase recommended?

No final decisions were made, but I guess that we'll simply remove the header registering altogether, therefore you must make sure to match casing (i.e. if you choose "Tags" in your theme, you must use "Tags" in your Markdown files, and vice-versa). Trying to make headers case-insensitive yields the same inconsistencies for arrays, so it's probably best to just leave it as-is. But again, no decisions were made. Whether you want to use "Tags" or "tags" is a matter of personal preference.

For plugins you can register custom headers using the onMetaHeaders event, see DummyPlugin for reference. We're aware that this is causing confusion, it's this way for historic reasons, we'll likely remove this whole case conversion thing at some point.

Set error_reporting in your php.ini to a value recommended for production servers, e.g. error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT.

Good idea @dustymabe, will join the meeting.

If podman uses pasta by default if it's there, then it should require/recommend it in the RPM package and we would include it directly.

Thus why I'm asking why is podman not yet requiring the pasta package.

Just for the record: Thanks for the clarification, I get your point now :+1: It does, just not for Fedora 37, but Fedora 38+, see https://src.fedoraproject.org/rpms/containers-common/blob/f38/f/containers-common.spec#_75

Why is this not the default yet for podman? Why should we ship something that is not the default in podman?

Honestly, I'm not sure what the question is?

Pasta is a new network mode for rootless Podman that was introduced with Podman 4.4. Podman supports it "by default", but requires the external passt binary. That's a common approach for Podman: Podman's slirp4netns support requires the slirp4netns binary, Podman's FUSE-based overlayfs support requires the fuse-overlayfs binary. If these binaries aren't present Podman simply throws an error when attempting to use them.

I don't think that whether pasta is the default network mode for rootless containers matters. Pasta is rather new; it's considered stable, but surely hasn't seen enough users yet to make it the default. Just like Podman didn't switch from CNI to Netavark/Aardvark at day one, that would have been crazy. Yet FCOS supported Netavark/Aardvark before Podman 4.0...

@sbrivio-rh WDYT?

Podman uses pasta, which is a component of passt (it's a single binary). Simply put, passt is for virtual machines, pasta is for containers. So, in general one can use passt without Podman (that's probably the reason why it's packaged separately in Fedora), but for FCOS its use is indeed practically limited to Podman, so it could also be made a direct dependency of Podman, yes.

apache-builder create-unit: Soften validation of pre-existing Systemd units

Various small improvements

Run apache-builder as container root

This fixes an issue with buildah unshare failing to use newuidmap, newgidmap, and chroot. Don't use the 'vfs' storage driver, but native overlayfs; '/var/lib/containers' needs to be a (temporary and anonymous) volume now. Also remove the apache-builder user requiring further workarounds otherwise - since the container is running unprivileged anyway, we don't need any of this hassle...

What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc)

None

# rpm-ostree install --dry-run passt
Checking out tree d34ff10... done
Enabled rpm-md repositories: fedora-cisco-openh264 fedora-modular updates-modular updates fedora updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'fedora-modular'... done
Updating metadata for 'updates-modular'... done
Updating metadata for 'updates'... done
Updating metadata for 'fedora'... done
Updating metadata for 'updates-archive'... done
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264'; generated: 2022-10-06T11:01:40Z solvables: 4
rpm-md repo 'fedora-modular'; generated: 2022-11-05T07:58:03Z solvables: 1454
rpm-md repo 'updates-modular'; generated: 2023-02-22T11:28:37Z solvables: 1464
rpm-md repo 'updates'; generated: 2023-03-07T01:25:09Z solvables: 26563
rpm-md repo 'fedora'; generated: 2022-11-05T08:04:38Z solvables: 66822
rpm-md repo 'updates-archive'; generated: 2023-03-08T02:27:27Z solvables: 29547
Resolving dependencies... done
Installing 1 packages:
  passt-0^20230222.g4ddbcb9-1.fc37.x86_64 (updates)
Exiting because of '--dry-run' option
``

### What is the size of the package and its dependencies?

About 429 kB

rpm -qi passt

Name : passt Version : 0^20230222.g4ddbcb9 Release : 1.fc37 Architecture: x86_64 Install Date: Wed Mar 8 10:15:20 2023 Group : System Environment/Daemons Size : 428906 License : AGPLv3+ and BSD Signature : RSA/SHA256, Wed Feb 22 12:55:10 2023, Key ID f55ad3fb5323552a Source RPM : passt-0^20230222.g4ddbcb9-1.fc37.src.rpm Build Date : Wed Feb 22 12:42:51 2023 Build Host : buildvm-x86-24.iad2.fedoraproject.org Packager : Fedora Project Vendor : Fedora Project URL : https://passt.top/ Bug URL : https://bugz.fedoraproject.org/passt Summary : User-mode networking daemons for virtual machines and namespaces Description : passt implements a translation layer between a Layer-2 network interface and native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't require any capabilities or privileges, and it can be used as a simple replacement for Slirp.

pasta (same binary as passt, different command) offers equivalent functionality, for network namespaces: traffic is forwarded using a tap interface inside the namespace, without the need to create further interfaces on the host, hence not requiring any capabilities or privileges.

### What problem are you trying to solve with this package? Or what functionality does the package provide?

`passt` provides user-mode networking daemons for virtual machines and namespaces

> passt implements a translation layer between a Layer-2 network interface and
> native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't
> require any capabilities or privileges, and it can be used as a simple
> replacement for Slirp.
> 
> pasta (same binary as passt, different command) offers equivalent functionality,
> for network namespaces: traffic is forwarded using a tap interface inside the
> namespace, without the need to create further interfaces on the host, hence not
> requiring any capabilities or privileges.

This enables support for Podman's new rootless network mode `pasta` (Podman 4.4 and later). See man(1) of `podman-run --network=pasta`. Also see https://passt.top/passt/about/

### Can the software provided by the package be run from a container?  Explain why or why not.

No, it provides additional functionality for Podman.

### Can the tool(s) provided by the package be helpful in debugging container runtime issues?

n/a

### Can the tool(s) provided by the package be helpful in debugging networking issues?

n/a

### Is it possible to layer the package onto the base OS as a day 2 operation?  Explain why or why not.

Yes.

### In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries?

The package provides binaries only, see https://packages.fedoraproject.org/pkgs/passt/passt/fedora-38.html#files

### Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS?

Don't think so.

### Does the software provided by the package have a history of CVEs?

AFAIK no.
                                    

Initial code commit

Add GitHub workflow to build & publish container to ghcr.io

Add GitHub workflow to auto update (rebuild & publish) containers

Add GitHub workflow to auto update (rebuild & publish) containers

Add 'con_build' build helper

Add 'chkupd_image_version' build helper

Add undocumented Autodiscover v2 for Office 2019, Office 365 and mobile

This is undocumented Microsoft bullcrap that simply isn't working. No autodiscovery for Office 2019, Office 365 and mobile, please send Microsoft your regards. Fuck you for breaking previously working Office with 3rd party mailservers Microsoft :middle_finger: