Podman on Debian 9 publishing port doesn't work

kind bug
Description
Webserver in container isn't reachable in the host terminal or via browser. The webserver is reachable inside the container.
Steps to reproduce the issue:

Use Debian 9 image

lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.6 (stretch)
Release:	9.6
Codename:	stretch

Make sure you have Debian Backports enabled.

Run commands as root

apt install -t stretch-backports systemd linux-image-amd64
echo -e "[Match] \n\
Name=eth0 \n\
\n\
[Network] \n\
DHCP=yes" > /etc/systemd/network/eth0.network
systemctl disable networking && systemctl enable systemd-networkd
reboot

Wait till server has rebooted

Run more commands as root

apt-key adv --keyserver ha.pool.sks-keyservers.net --recv-keys 0x018BA5AD9DF57A4448F0E6CF8BECF1637AD8C79D
echo "deb http://ppa.launchpad.net/projectatomic/ppa/ubuntu bionic main" > /etc/apt/sources.list.d/container.list
apt update && apt install -y podman skopeo buildah uidmap debootstrap

Add /etc/containers/registries.conf file (because the containers-common ppa package does not deliver a default registries.conf file like the corresponding containers-common in Fedora)

# This is a system-wide configuration file used to
# keep track of registries for various container backends.
# It adheres to TOML format and does not support recursive
# lists of registries.

# The default location for this configuration file is /etc/containers/registries.conf.

# The only valid categories are: 'registries.search', 'registries.insecure',
# and 'registries.block'.

[registries.search]
registries = []

# If you need to access insecure registries, add the registry's fully-qualified name.
# An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
[registries.insecure]
registries = []

# If you need to block pull access from a registry, uncomment the section below
# and add the registries fully-qualified name.
#
# Docker only
[registries.block]
registries = []

Start the container

podman container run -p 80:80 docker.io/httpd

Describe the results you received:

Open second terminal

curl localhost
.. (does not answer)

Open in browser
(does not answer)

Run curl inside the container

podman run -it (containerid) bash
apt update && apt install -y curl
curl localhost
output:

It works!

Describe the results you expected:
Apache is reachable from local terminal via curl and outside via browser.

Start container without network namespacing (--net=host)
Container is reachable though terminal and browser

Additional information you deem important (e.g. issue happens only occasionally):
Versions of installed packages
cri-o-runc amd64 1.0.0-rc6-1~dev~ubuntu18.04~ppa19
containers-common amd64 0.1.33-1~dev~ubuntu18.04~ppa7
buildah amd64 1.6-1~dev~ubuntu18.04~ppa2
cri-o-1.12 amd64 1.12.4-1~dev~ubuntu18.04~ppa1
containernetworking-plugins amd64 0.7.3-1~ubuntu18.04~ppa2
podman amd64 0.12.2-2~dev~ubuntu18.04~ppa2
skopeo amd64 0.1.33-1~dev~ubuntu18.04~ppa7

Additional information when httpd container is started with -p 80:80
root@test:~# networkctl
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           carrier     unmanaged
  2 eth0             ether              routable    configured
  3 cni0             bridge             routable    unmanaged
  4 veth85114cdb     ether              degraded    unmanaged

4 links listed.

root@test:~# networkctl status cni0
● 3: cni0
       Link File: /lib/systemd/network/99-default.link
    Network File: n/a
            Type: bridge
           State: routable (unmanaged)
          Driver: bridge
      HW Address: d6:88:4c:dc:8f:f0
         Address: <IP_ADDRESS>
                  fe80::d488:4cff:fedc:8ff0

root@test:~# networkctl status veth85114cdb
● 4: veth85114cdb
       Link File: /lib/systemd/network/99-default.link
    Network File: n/a
            Type: ether
           State: degraded (unmanaged)
          Driver: veth
      HW Address: 7a:65:6f:cd:d2:af
         Address: fe80::7865:6fff:fecd:d2af

root@test:~# ss -tulpn
... other data
tcp   LISTEN     1      128                                                                         *:80                                                                                *:*                   users:(("conmon",pid=2860,fd=5),("podman",pid=2772,fd=22),("podman",pid=2772,fd=21))

Additional information when httpd container is started with --net=host
root@test:~# networkctl
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           carrier     unmanaged
  2 eth0             ether              routable    configured
  3 cni0             bridge             no-carrier  unmanaged

3 links listed.

root@test:~# networkctl status cni0
● 3: cni0
       Link File: /lib/systemd/network/99-default.link
    Network File: n/a
            Type: bridge
           State: no-carrier (unmanaged)
          Driver: bridge
      HW Address: d6:88:4c:dc:8f:f0
         Address: <IP_ADDRESS>
                  fe80::d488:4cff:fedc:8ff0

root@test:~# ss -tulpn
... other data
tcp   LISTEN     0      128                                                                        :::80                                                                                :::*                   users:(("httpd",pid=2654,fd=4),("httpd",pid=2653,fd=4),("httpd",pid=2652,fd=4),("httpd",pid=2637,fd=4))

Output of podman version:
Version:       0.12.2-dev
Go Version:    go1.10.4
OS/Arch:       linux/amd64

Output of podman info:
host:
  BuildahVersion: 1.6-dev
  Conmon:
    package: 'cri-o-1.12: /usr/lib/crio/bin/conmon'
    path: /usr/lib/crio/bin/conmon
    version: 'conmon version 1.12.4-dev, commit: '
  Distribution:
    distribution: debian
    version: "9"
  MemFree:<PHONE_NUMBER>
  MemTotal:<PHONE_NUMBER>
  OCIRuntime:
    package: 'cri-o-runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: 'runc version spec: 1.0.1-dev'
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 1
  hostname: test
  kernel: 4.18.0-0.bpo.1-amd64
  os: linux
  rootless: false
  uptime: 21m 47.72s
insecure registries:
  registries: []
registries:
  registries: []
store:
  ContainerStore:
    number: 5
  GraphDriverName: overlay
  GraphOptions: null
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
  ImageStore:
    number: 1
  RunRoot: /var/run/containers/storage

Additional environment details (AWS, VirtualBox, physical, etc.):
KVM VPS

are you running as root?  and also, can you provide the run command with pod --log-level=debug ?

Yes, I am running the commands as root.
Command with log level debug:
root@test:~# podman --log-level=debug  container run -p 80:80 docker.io/httpd
DEBU[0000] Initializing boltdb state at /var/lib/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver
DEBU[0000] Using graph root
DEBU[0000] Using run root
DEBU[0000] Using static dir /var/lib/containers/storage/libpod
DEBU[0000] Using tmp dir /var/run/libpod
DEBU[0000] Set libpod namespace to ""
DEBU[0000] [graphdriver] trying provided driver "overlay"
DEBU[0000] overlay: override_kernelcheck=true
DEBU[0000] overlay test mount with multiple lowers succeeded
DEBU[0000] backingFs=extfs, projectQuotaSupported=false, useNativeDiff=true
INFO[0000] Found CNI network crio-bridge (type=bridge) at /etc/cni/net.d/100-crio-bridge.conf
INFO[0000] Found CNI network 200-loopback.conf (type=loopback) at /etc/cni/net.d/200-loopback.conf
INFO[0000] Found CNI network podman (type=bridge) at /etc/cni/net.d/87-podman-bridge.conflist
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/httpd:latest"
DEBU[0000] reference "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/httpd:latest" does not resolve to an image ID
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/httpd:latest"
DEBU[0000] reference "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/httpd:latest" does not resolve to an image ID
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/httpd:latest"
Trying to pull docker.io/httpd...DEBU[0000] Using registries.d directory /etc/containers/registries.d for sigstore configuration
DEBU[0000]  Using "default-docker" configuration
DEBU[0000]  No signature storage configuration found for docker.io/library/httpd:latest
DEBU[0000] Looking for TLS certificates and private keys in /etc/docker/certs.d/docker.io
DEBU[0000] Using blob info cache at /var/lib/containers/cache/blob-info-cache-v1.boltdb
DEBU[0000] GET https://registry-1.docker.io/v2/
DEBU[0000] Ping https://registry-1.docker.io/v2/ status 401
DEBU[0000] GET https://auth.docker.io/token?scope=repository%3Alibrary%2Fhttpd%3Apull&service=registry.docker.io
DEBU[0001] GET https://registry-1.docker.io/v2/library/httpd/manifests/latest
DEBU[0001] Source is a manifest list; copying (only) instance sha256:63dba1dad8fe8a920226a631f8189d736b4a5129c2d2edc046a46f36ffc0091c
DEBU[0001] GET https://registry-1.docker.io/v2/library/httpd/manifests/sha256:63dba1dad8fe8a920226a631f8189d736b4a5129c2d2edc046a46f36ffc0091c
DEBU[0002] IsRunningImageAllowed for image docker:docker.io/library/httpd:latest
DEBU[0002]  Using default policy section
DEBU[0002]  Requirement 0: allowed
DEBU[0002] Overall: allowed
DEBU[0002] Downloading /v2/library/httpd/blobs/sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30
DEBU[0002] GET https://registry-1.docker.io/v2/library/httpd/blobs/sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30
Getting image source signatures
DEBU[0002] Manifest has MIME type application/vnd.docker.distribution.manifest.v2+json, ordered candidate list [application/vnd.docker.distribution.manifest.v2+json, application/vnd.docker.distribution.manifest.v1+prettyjws, application/vnd.oci.image.manifest.v1+json, application/vnd.docker.distribution.manifest.v1+json]
DEBU[0002] ... will first try using the original manifest unmodified
Copying blob sha256:a5a6f2f73cd8abbdc55d0df0d8834f7262713e87d6c8800ea3851f103025e0f0
DEBU[0002] Downloading /v2/library/httpd/blobs/sha256:a5a6f2f73cd8abbdc55d0df0d8834f7262713e87d6c8800ea3851f103025e0f0
DEBU[0002] GET https://registry-1.docker.io/v2/library/httpd/blobs/sha256:a5a6f2f73cd8abbdc55d0df0d8834f7262713e87d6c8800ea3851f103025e0f0
DEBU[0003] Detected compression format gzip
 0 B / 21.44 MB [--------------------------------------------------------------]DEBU[0003] Using original blob without modification
 21.44 MB / 21.44 MB [======================================================] 0s
Copying blob sha256:ac13924397e3456b2a26d56bef26d5792cdbd978f72ef9cc1fb15a027e58c71d
DEBU[0004] Downloading /v2/library/httpd/blobs/sha256:ac13924397e3456b2a26d56bef26d5792cdbd978f72ef9cc1fb15a027e58c71d
DEBU[0004] GET https://registry-1.docker.io/v2/library/httpd/blobs/sha256:ac13924397e3456b2a26d56bef26d5792cdbd978f72ef9cc1fb15a027e58c71d
DEBU[0004] Detected compression format gzip
 0 B / 154 B [-----------------------------------------------------------------]DEBU[0004] Using original blob without modification
 154 B / 154 B [============================================================] 0s
Copying blob sha256:91b81769f14a044f1deebeb7fdf5c0e743b6aef65ec2dfe1c8beb8d36a5dd875
DEBU[0004] Downloading /v2/library/httpd/blobs/sha256:91b81769f14a044f1deebeb7fdf5c0e743b6aef65ec2dfe1c8beb8d36a5dd875
DEBU[0004] GET https://registry-1.docker.io/v2/library/httpd/blobs/sha256:91b81769f14a044f1deebeb7fdf5c0e743b6aef65ec2dfe1c8beb8d36a5dd875
DEBU[0005] Detected compression format gzip
 0 B / 9.84 MB [---------------------------------------------------------------]DEBU[0005] Using original blob without modification
 9.84 MB / 9.84 MB [========================================================] 0s
Copying blob sha256:fec7170426de5702cb93cc68c52509c9447b6ee881549abb4bcc5bccaa1b77c8
DEBU[0005] Downloading /v2/library/httpd/blobs/sha256:fec7170426de5702cb93cc68c52509c9447b6ee881549abb4bcc5bccaa1b77c8
DEBU[0005] GET https://registry-1.docker.io/v2/library/httpd/blobs/sha256:fec7170426de5702cb93cc68c52509c9447b6ee881549abb4bcc5bccaa1b77c8
DEBU[0006] Detected compression format gzip
 0 B / 15.78 MB [--------------------------------------------------------------]DEBU[0006] Using original blob without modification
 15.78 MB / 15.78 MB [======================================================] 0s
Copying blob sha256:992c7790d5f3a52fa534a56f857b11ebc49011ef1d23e5ae3ec6116105a011db
DEBU[0007] Downloading /v2/library/httpd/blobs/sha256:992c7790d5f3a52fa534a56f857b11ebc49011ef1d23e5ae3ec6116105a011db
DEBU[0007] GET https://registry-1.docker.io/v2/library/httpd/blobs/sha256:992c7790d5f3a52fa534a56f857b11ebc49011ef1d23e5ae3ec6116105a011db
DEBU[0007] Detected compression format gzip
 0 B / 298 B [-----------------------------------------------------------------]DEBU[0007] Using original blob without modification
 298 B / 298 B [============================================================] 0s
Copying config sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30
DEBU[0007] No compression detected
 0 B / 7.07 KB [---------------------------------------------------------------]DEBU[0007] Using original blob without modification
 7.07 KB / 7.07 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
DEBU[0007] Applying tar in /var/lib/containers/storage/overlay/ef68f6734aa485edf13a8509fe60e4272428deaf63f446a441b79d47fc5d17d3/diff
DEBU[0008] Applying tar in /var/lib/containers/storage/overlay/65b5e6081074eba521e8e8adf5c50e9548daa658ec3f417f6c99d091e8d0d22d/diff
DEBU[0008] Applying tar in /var/lib/containers/storage/overlay/6cd4a9bba27bee4e6396129dc424dbaacdd0f4004024f86be0daff6af24fef63/diff
DEBU[0009] Applying tar in /var/lib/containers/storage/overlay/d809397211072934436e20cd98bac0763e377f4a0164267d7ccea1b9c3582c08/diff
DEBU[0010] Applying tar in /var/lib/containers/storage/overlay/8622c3348556bdeb0af78dcf010f3947cb8a15aa2662ac90cf596c3555a32f11/diff
DEBU[0010] setting image creation date to 2018-11-15 23:54:07.293451834 +0000 UTC
DEBU[0010] created new image ID "2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] set names of image "2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30" to [docker.io/library/httpd:latest]
DEBU[0010] saved image metadata "{}"
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/httpd:latest"
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] Using bridge netmode
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] created container "2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a"
DEBU[0010] container "2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a" has work directory "/var/lib/containers/storage/overlay-containers/2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a/userdata"
DEBU[0010] container "2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a" has run directory "/var/run/containers/storage/overlay-containers/2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a/userdata"
DEBU[0010] New container created "2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a"
DEBU[0010] container "2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a" has CgroupParent "machine.slice/libpod-2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a.scope"
DEBU[0010] Not attaching to stdin
DEBU[0010] mounted container "2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a" at "/var/lib/containers/storage/overlay/ab83e28a3f25003ec97d6aceca1a423c69c00f091a745f874cf180b7a4fc44bf/merged"
DEBU[0010] Created root filesystem for container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a at /var/lib/containers/storage/overlay/ab83e28a3f25003ec97d6aceca1a423c69c00f091a745f874cf180b7a4fc44bf/merged
DEBU[0010] Made network namespace at /var/run/netns/cni-2e20ceac-fdc1-fe25-294e-1ad45dc7ecaf for container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a
INFO[0010] Got pod network &{Name:condescending_wiles Namespace:condescending_wiles ID:2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a NetNS:/var/run/netns/cni-2e20ceac-fdc1-fe25-294e-1ad45dc7ecaf PortMappings:[{HostPort:80 ContainerPort:80 Protocol:tcp HostIP:}] Networks:[] NetworkConfig:map[]}
INFO[0010] About to add CNI network cni-loopback (type=loopback)
INFO[0010] Got pod network &{Name:condescending_wiles Namespace:condescending_wiles ID:2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a NetNS:/var/run/netns/cni-2e20ceac-fdc1-fe25-294e-1ad45dc7ecaf PortMappings:[{HostPort:80 ContainerPort:80 Protocol:tcp HostIP:}] Networks:[] NetworkConfig:map[]}
INFO[0010] About to add CNI network crio-bridge (type=bridge)
DEBU[0010] [0] CNI result: Interfaces:[{Name:cni0 Mac:12:82:69:df:e7:1c Sandbox:} {Name:vethd50ac574 Mac:52:ad:51:83:5d:14 Sandbox:} {Name:eth0 Mac:16:c3:37:83:19:29 Sandbox:/var/run/netns/cni-2e20ceac-fdc1-fe25-294e-1ad45dc7ecaf}], IP:[{Version:4 Interface:0xc420644ca8 Address:{IP:<IP_ADDRESS> Mask:ffff0000} Gateway:<IP_ADDRESS>}], Routes:[{Dst:{IP:<IP_ADDRESS> Mask:00000000} GW:<nil>}], DNS:{Nameservers:[] Domain: Search:[] Options:[]}
DEBU[0010] /etc/system-fips does not exist on host, not mounting FIPS mode secret
DEBU[0010] reading hooks from /usr/share/containers/oci/hooks.d
DEBU[0010] reading hooks from /etc/containers/oci/hooks.d
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0010] Setting CGroups for container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a to machine.slice:libpod:2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a
DEBU[0010] Created OCI spec for container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a at /var/lib/containers/storage/overlay-containers/2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a/userdata/config.json
DEBU[0010] /usr/lib/crio/bin/conmon messages will be logged to syslog
DEBU[0010] running conmon: /usr/lib/crio/bin/conmon      args=[-s -c 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a -u 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a -r /usr/sbin/runc -b /var/lib/containers/storage/overlay-containers/2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a/userdata -p /var/run/containers/storage/overlay-containers/2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket --log-level debug --syslog]
INFO[0010] Running conmon under slice machine.slice and unitName libpod-conmon-2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a.scope
DEBU[0011] Received container pid: 2022
DEBU[0011] Created container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a in OCI runtime
DEBU[0011] Enabling signal proxying
DEBU[0011] Attaching to container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a
DEBU[0011] connecting to socket /var/run/libpod/socket/2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a/attach
DEBU[0011] Started container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using <IP_ADDRESS>. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using <IP_ADDRESS>. Set the 'ServerName' directive globally to suppress this message
[Fri Dec 14 15:00:19.577793 2018] [mpm_event:notice] [pid 1:tid<PHONE_NUMBER>09440] AH00489: Apache/2.4.37 (Unix) configured -- resuming normal operations
[Fri Dec 14 15:00:19.578002 2018] [core:notice] [pid 1:tid<PHONE_NUMBER>09440] AH00094: Command line: 'httpd -D FOREGROUND'
DEBU[0016] Sending signal 28 to container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a
[Fri Dec 14 15:00:25.442590 2018] [mpm_event:notice] [pid 1:tid<PHONE_NUMBER>09440] AH00492: caught SIGWINCH, shutting down gracefully
DEBU[0017] Checking container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a status...
DEBU[0017] Cleaning up container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a
DEBU[0017] Tearing down network namespace at /var/run/netns/cni-2e20ceac-fdc1-fe25-294e-1ad45dc7ecaf for container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a
INFO[0017] Got pod network &{Name:condescending_wiles Namespace:condescending_wiles ID:2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a NetNS:/var/run/netns/cni-2e20ceac-fdc1-fe25-294e-1ad45dc7ecaf PortMappings:[{HostPort:80 ContainerPort:80 Protocol:tcp HostIP:}] Networks:[] NetworkConfig:map[]}
INFO[0017] About to del CNI network crio-bridge (type=bridge)
DEBU[0018] unmounted container "2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a"
DEBU[0018] Successfully cleaned up container 2fb3e3025a04db8366c5e746be05c6e42cb949fe969bf70a07731600ac877e6a
root@test:~# podman --log-level=debug  container run -p 80:80 docker.io/httpd
DEBU[0000] Initializing boltdb state at /var/lib/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /var/lib/containers/storage
DEBU[0000] Using run root /var/run/containers/storage
DEBU[0000] Using static dir /var/lib/containers/storage/libpod
DEBU[0000] Using tmp dir /var/run/libpod
DEBU[0000] Set libpod namespace to ""
DEBU[0000] [graphdriver] trying provided driver "overlay"
DEBU[0000] overlay test mount with multiple lowers succeeded
DEBU[0000] backingFs=extfs, projectQuotaSupported=false, useNativeDiff=true
INFO[0000] Found CNI network crio-bridge (type=bridge) at /etc/cni/net.d/100-crio-bridge.conf
INFO[0000] Found CNI network 200-loopback.conf (type=loopback) at /etc/cni/net.d/200-loopback.conf
INFO[0000] Found CNI network podman (type=bridge) at /etc/cni/net.d/87-podman-bridge.conflist
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]docker.io/library/httpd:latest"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] Using bridge netmode
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] created container "6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d"
DEBU[0000] container "6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d" has work directory "/var/lib/containers/storage/overlay-containers/6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d/userdata"
DEBU[0000] container "6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d" has run directory "/var/run/containers/storage/overlay-containers/6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d/userdata"
DEBU[0000] New container created "6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d"
DEBU[0000] container "6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d" has CgroupParent "machine.slice/libpod-6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d.scope"
DEBU[0000] Not attaching to stdin
DEBU[0000] Made network namespace at /var/run/netns/cni-6943d51d-bb00-6b7d-db51-88e3493f0896 for container 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d
INFO[0000] Got pod network &{Name:objective_neumann Namespace:objective_neumann ID:6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d NetNS:/var/run/netns/cni-6943d51d-bb00-6b7d-db51-88e3493f0896 PortMappings:[{HostPort:80 ContainerPort:80 Protocol:tcp HostIP:}] Networks:[] NetworkConfig:map[]}
INFO[0000] About to add CNI network cni-loopback (type=loopback)
INFO[0000] Got pod network &{Name:objective_neumann Namespace:objective_neumann ID:6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d NetNS:/var/run/netns/cni-6943d51d-bb00-6b7d-db51-88e3493f0896 PortMappings:[{HostPort:80 ContainerPort:80 Protocol:tcp HostIP:}] Networks:[] NetworkConfig:map[]}
INFO[0000] About to add CNI network crio-bridge (type=bridge)
DEBU[0000] mounted container "6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d" at "/var/lib/containers/storage/overlay/b148815fb18ec2b3bcaa455fd9c422149e9f2c955f3fe17d8437ec069e451b4d/merged"
DEBU[0000] Created root filesystem for container 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d at /var/lib/containers/storage/overlay/b148815fb18ec2b3bcaa455fd9c422149e9f2c955f3fe17d8437ec069e451b4d/merged
DEBU[0000] [0] CNI result: Interfaces:[{Name:cni0 Mac:12:82:69:df:e7:1c Sandbox:} {Name:veth2370831d Mac:0e:81:88:88:4e:cd Sandbox:} {Name:eth0 Mac:2e:73:2a:a7:b9:e8 Sandbox:/var/run/netns/cni-6943d51d-bb00-6b7d-db51-88e3493f0896}], IP:[{Version:4 Interface:0xc42024b060 Address:{IP:<IP_ADDRESS> Mask:ffff0000} Gateway:<IP_ADDRESS>}], Routes:[{Dst:{IP:<IP_ADDRESS> Mask:00000000} GW:<nil>}], DNS:{Nameservers:[] Domain: Search:[] Options:[]}
DEBU[0000] /etc/system-fips does not exist on host, not mounting FIPS mode secret
DEBU[0000] reading hooks from /usr/share/containers/oci/hooks.d
DEBU[0000] reading hooks from /etc/containers/oci/hooks.d
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] Setting CGroups for container 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d to machine.slice:libpod:6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d
DEBU[0000] Created OCI spec for container 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d at /var/lib/containers/storage/overlay-containers/6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d/userdata/config.json
DEBU[0000] /usr/lib/crio/bin/conmon messages will be logged to syslog
DEBU[0000] running conmon: /usr/lib/crio/bin/conmon      args=[-s -c 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d -u 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d -r /usr/sbin/runc -b /var/lib/containers/storage/overlay-containers/6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d/userdata -p /var/run/containers/storage/overlay-containers/6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket --log-level debug --syslog]
INFO[0000] Running conmon under slice machine.slice and unitName libpod-conmon-6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d.scope
DEBU[0000] Received container pid: 2221
DEBU[0000] Created container 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d in OCI runtime
DEBU[0000] Enabling signal proxying
DEBU[0000] Attaching to container 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d
DEBU[0000] connecting to socket /var/run/libpod/socket/6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d/attach
DEBU[0000] Started container 6aea438cf7967f4feaaa09559e437a494dfc8ad85104895ce52b6ab6c6062c0d
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using <IP_ADDRESS>. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using <IP_ADDRESS>. Set the 'ServerName' directive globally to suppress this message
[Fri Dec 14 15:00:51.389269 2018] [mpm_event:notice] [pid 1:tid<PHONE_NUMBER>01248] AH00489: Apache/2.4.37 (Unix) configured -- resuming normal operations
[Fri Dec 14 15:00:51.389456 2018] [core:notice] [pid 1:tid<PHONE_NUMBER>01248] AH00094: Command line: 'httpd -D FOREGROUND'

is the network connection between the container and host healthy? meaning, they can ping each other?

INFO[0000] About to add CNI network crio-bridge (type=bridge)
There's the problem - it's preferring the CRI-O CNI network over the Podman one

@Ghostium Do you have an /etc/containers/libpod.conf and if so does it contain the line cni_default_network = "podman"?

I am sorry, but I've never dealt with container networking before.
If I interpret this correctly the default route/gateway is reachable inside the container as is the public IPv4 address. The container ip adress is reachable from the host.
Is this correct?
root@test:~# podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED        STATUS            PORTS               NAMES
4a934f772b64  docker.io/library/httpd:latest  httpd-foreground  5 seconds ago  Up 5 seconds ago  <IP_ADDRESS>:80->80/tcp  happy_murdock
root@test:~# podman inspect 4a
[
    {
        "ID": "4a934f772b648a267bd15fa7053cad71a2944b8fbdb9dc278af5693c2c1cd11e",
        "Created": "2018-12-14T16:48:05.752979757+01:00",
        "Path": "httpd-foreground",
        "Args": [
            "httpd-foreground"
        ],
        "State": {
            "OciVersion": "1.0.1-dev",
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 2473,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2018-12-14T16:48:05.964303006+01:00",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
        "Image": "2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30",
        "ImageName": "docker.io/library/httpd:latest",
        "Rootfs": "",
        "ResolvConfPath": "/var/run/containers/storage/overlay-containers/4a934f772b648a267bd15fa7053cad71a2944b8fbdb9dc278af5693c2c1cd11e/userdata/resolv.conf",
        "HostnamePath": "/var/run/containers/storage/overlay-containers/4a934f772b648a267bd15fa7053cad71a2944b8fbdb9dc278af5693c2c1cd11e/userdata/hostname",
        "HostsPath": "/var/run/containers/storage/overlay-containers/4a934f772b648a267bd15fa7053cad71a2944b8fbdb9dc278af5693c2c1cd11e/userdata/hosts",
        "StaticDir": "/var/lib/containers/storage/overlay-containers/4a934f772b648a267bd15fa7053cad71a2944b8fbdb9dc278af5693c2c1cd11e/userdata",
        "LogPath": "/var/lib/containers/storage/overlay-containers/4a934f772b648a267bd15fa7053cad71a2944b8fbdb9dc278af5693c2c1cd11e/userdata/ctr.log",
        "Name": "happy_murdock",
        "RestartCount": 0,
        "Driver": "overlay",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "",
        "EffectiveCaps": [
            "CAP_CHOWN",
            "CAP_DAC_OVERRIDE",
            "CAP_FSETID",
            "CAP_FOWNER",
            "CAP_MKNOD",
            "CAP_NET_RAW",
            "CAP_SETGID",
            "CAP_SETUID",
            "CAP_SETFCAP",
            "CAP_SETPCAP",
            "CAP_NET_BIND_SERVICE",
            "CAP_SYS_CHROOT",
            "CAP_KILL",
            "CAP_AUDIT_WRITE"
        ],
        "BoundingCaps": [
            "CAP_CHOWN",
            "CAP_DAC_OVERRIDE",
            "CAP_FSETID",
            "CAP_FOWNER",
            "CAP_MKNOD",
            "CAP_NET_RAW",
            "CAP_SETGID",
            "CAP_SETUID",
            "CAP_SETFCAP",
            "CAP_SETPCAP",
            "CAP_NET_BIND_SERVICE",
            "CAP_SYS_CHROOT",
            "CAP_KILL",
            "CAP_AUDIT_WRITE"
        ],
        "ExecIDs": [],
        "GraphDriver": {
            "Name": "overlay",
            "Data": {
                "LowerDir": "/var/lib/containers/storage/overlay/8622c3348556bdeb0af78dcf010f3947cb8a15aa2662ac90cf596c3555a32f11/diff:/var/lib/containers/storage/overlay/d809397211072934436e20cd98bac0763e377f4a0164267d7ccea1b9c3582c08/diff:/var/lib/containers/storage/overlay/6cd4a9bba27bee4e6396129dc424dbaacdd0f4004024f86be0daff6af24fef63/diff:/var/lib/containers/storage/overlay/65b5e6081074eba521e8e8adf5c50e9548daa658ec3f417f6c99d091e8d0d22d/diff:/var/lib/containers/storage/overlay/ef68f6734aa485edf13a8509fe60e4272428deaf63f446a441b79d47fc5d17d3/diff",
                "MergedDir": "/var/lib/containers/storage/overlay/3890b8f73416ca28ea683cbce64eb1a9b92c7c6f71d04ebbba5f31c3690c4a12/merged",
                "UpperDir": "/var/lib/containers/storage/overlay/3890b8f73416ca28ea683cbce64eb1a9b92c7c6f71d04ebbba5f31c3690c4a12/diff",
                "WorkDir": "/var/lib/containers/storage/overlay/3890b8f73416ca28ea683cbce64eb1a9b92c7c6f71d04ebbba5f31c3690c4a12/work"
            }
        },
        "Mounts": [
            {
                "destination": "/proc",
                "type": "proc",
                "source": "proc",
                "options": [
                    "nosuid",
                    "noexec",
                    "nodev"
                ]
            },
            {
                "destination": "/dev",
                "type": "tmpfs",
                "source": "tmpfs",
                "options": [
                    "nosuid",
                    "strictatime",
                    "mode=755",
                    "size=65536k"
                ]
            },
            {
                "destination": "/dev/pts",
                "type": "devpts",
                "source": "devpts",
                "options": [
                    "nosuid",
                    "noexec",
                    "newinstance",
                    "ptmxmode=0666",
                    "mode=0620",
                    "gid=5"
                ]
            },
            {
                "destination": "/dev/shm",
                "type": "tmpfs",
                "source": "shm",
                "options": [
                    "nosuid",
                    "noexec",
                    "nodev",
                    "mode=1777",
                    "size=65536k"
                ]
            },
            {
                "destination": "/dev/mqueue",
                "type": "mqueue",
                "source": "mqueue",
                "options": [
                    "nosuid",
                    "noexec",
                    "nodev"
                ]
            },
            {
                "destination": "/sys",
                "type": "sysfs",
                "source": "sysfs",
                "options": [
                    "nosuid",
                    "noexec",
                    "nodev",
                    "ro"
                ]
            },
            {
                "destination": "/sys/fs/cgroup",
                "type": "cgroup",
                "source": "cgroup",
                "options": [
                    "rprivate",
                    "nosuid",
                    "noexec",
                    "nodev",
                    "relatime",
                    "ro"
                ]
            }
        ],
        "Dependencies": [],
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": [
                {
                    "hostPort": 80,
                    "containerPort": 80,
                    "protocol": "tcp",
                    "hostIP": ""
                }
            ],
            "SandboxKey": "/var/run/netns/cni-7158f31e-7e27-5309-0ec0-60611dc146de",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "",
            "Gateway": "<IP_ADDRESS>",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "<IP_ADDRESS>",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "MacAddress": "3a:6c:a7:85:09:fc"
        },
        "ExitCommand": null,
        "Namespace": "",
        "IsInfra": false,
        "HostConfig": {
            "ContainerIDFile": "",
            "LogConfig": null,
            "NetworkMode": "bridge",
            "PortBindings": null,
            "AutoRemove": false,
            "CapAdd": [],
            "CapDrop": [],
            "DNS": [],
            "DNSOptions": [],
            "DNSSearch": [],
            "ExtraHosts": null,
            "GroupAdd": null,
            "IpcMode": "",
            "Cgroup": "host",
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": [],
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 65536000,
            "Runtime": "runc",
            "ConsoleSize": null,
            "CpuShares": null,
            "Memory": 0,
            "NanoCpus": 0,
            "CgroupParent": "",
            "BlkioWeight": null,
            "BlkioWeightDevice": null,
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": null,
            "CpuQuota": null,
            "CpuRealtimePeriod": null,
            "CpuRealtimeRuntime": null,
            "CpuSetCpus": "",
            "CpuSetMems": "",
            "Devices": null,
            "DiskQuota": 0,
            "KernelMemory": null,
            "MemoryReservation": null,
            "MemorySwap": null,
            "MemorySwappiness": null,
            "OomKillDisable": false,
            "PidsLimit": null,
            "Ulimits": [],
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0,
            "Tmpfs": []
        },
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": {
                "uid": 0,
                "gid": 0
            },
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/apache2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "TERM=xterm",
                "HOSTNAME=",
                "container=podman",
                "HTTPD_PREFIX=/usr/local/apache2",
                "HTTPD_VERSION=2.4.37",
                "HTTPD_SHA256=3498dc5c6772fac2eb7307dc7963122ffe243b5e806e0be4fb51974ff759d726",
                "HTTPD_PATCHES=",
                "APACHE_DIST_URLS=https://www.apache.org/dyn/closer.cgi?action=download&filename= \thttps://www-us.apache.org/dist/ \thttps://www.apache.org/dist/ \thttps://archive.apache.org/dist/"
            ],
            "Cmd": [
                "httpd-foreground"
            ],
            "Image": "docker.io/library/httpd:latest",
            "Volumes": null,
            "WorkingDir": "/usr/local/apache2",
            "Entrypoint": "",
            "Labels": null,
            "Annotations": {
                "io.kubernetes.cri-o.ContainerType": "sandbox",
                "io.kubernetes.cri-o.TTY": "false"
            },
            "StopSignal": 15
        }
    }
]

root@test:~# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.110 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.077 ms
^C
--- <IP_ADDRESS> ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.077/0.093/0.110/0.019 ms

Inside
root@4a934f772b64:/usr/local/apache2# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: icmp_seq=0 ttl=64 time=0.087 ms
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.119 ms
^C--- <IP_ADDRESS> ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.087/0.103/0.119/0.000 ms
root@4a934f772b64:/usr/local/apache2# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: icmp_seq=0 ttl=64 time=0.339 ms
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.109 ms
^C--- <IP_ADDRESS> ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.109/0.224/0.339/0.115 ms
root@4a934f772b64:/usr/local/apache2#

@mheon There is no libpod.conf file under /etc/containers/libpod.conf.
root@test:~# ls /etc/containers/ -la
total 24
drwxr-xr-x  3 root root 4096 Dez 14 15:56 .
drwxr-xr-x 72 root root 4096 Dez 14 15:56 ..
-rw-r--r--  1 root root  256 Dez  7 20:54 policy.json
-rw-r--r--  1 root root  818 Dez 14 15:56 registries.conf
drwxr-xr-x  2 root root 4096 Dez 14 15:56 registries.d
-rw-r--r--  1 root root  891 Dez  7 20:54 storage.conf

@Ghostium Would you mind creating libpod.conf and retesting once it's present, using the contents of https://github.com/containers/libpod/blob/master/libpod.conf

@mheon Thanks that fixed it.
The webserver is now reachable from the outside and in the terminal.
Maybe default registries.conf and libpod.conf files could be added to the according packages in the ppa repo? That podman works out of the box.
The new output is:
root@test:~# podman --log-level=debug  container run -it  -p 80:80 docker.io/httpd
DEBU[0000] Initializing boltdb state at /var/lib/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /var/lib/containers/storage
DEBU[0000] Using run root /var/run/containers/storage
DEBU[0000] Using static dir /var/lib/containers/storage/libpod
DEBU[0000] Using tmp dir /var/run/libpod
DEBU[0000] Set libpod namespace to ""
DEBU[0000] [graphdriver] trying provided driver "overlay"
DEBU[0000] overlay test mount with multiple lowers succeeded
DEBU[0000] backingFs=extfs, projectQuotaSupported=false, useNativeDiff=true
INFO[0000] Found CNI network crio-bridge (type=bridge) at /etc/cni/net.d/100-crio-bridge.conf
INFO[0000] Found CNI network 200-loopback.conf (type=loopback) at /etc/cni/net.d/200-loopback.conf
INFO[0000] Found CNI network podman (type=bridge) at /etc/cni/net.d/87-podman-bridge.conflist
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]docker.io/library/httpd:latest"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] Using bridge netmode
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] created container "d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62"
DEBU[0000] container "d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62" has work directory "/var/lib/containers/storage/overlay-containers/d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62/userdata"
DEBU[0000] container "d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62" has run directory "/var/run/containers/storage/overlay-containers/d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62/userdata"
DEBU[0000] New container created "d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62"
DEBU[0000] container "d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62" has CgroupParent "machine.slice/libpod-d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62.scope"
DEBU[0000] Handling terminal attach
DEBU[0000] Made network namespace at /var/run/netns/cni-e8eb869f-ee62-a4e2-3a6e-a20cc3c5ca84 for container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62
INFO[0000] Got pod network &{Name:determined_hypatia Namespace:determined_hypatia ID:d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 NetNS:/var/run/netns/cni-e8eb869f-ee62-a4e2-3a6e-a20cc3c5ca84 PortMappings:[{HostPort:80 ContainerPort:80 Protocol:tcp HostIP:}] Networks:[] NetworkConfig:map[]}
INFO[0000] About to add CNI network cni-loopback (type=loopback)
INFO[0000] Got pod network &{Name:determined_hypatia Namespace:determined_hypatia ID:d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 NetNS:/var/run/netns/cni-e8eb869f-ee62-a4e2-3a6e-a20cc3c5ca84 PortMappings:[{HostPort:80 ContainerPort:80 Protocol:tcp HostIP:}] Networks:[] NetworkConfig:map[]}
INFO[0000] About to add CNI network podman (type=bridge)
DEBU[0000] mounted container "d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62" at "/var/lib/containers/storage/overlay/6eb4445c47e3d0ed23f799a01a9764f0cd40a91d9be2c659a8245cf39af7298b/merged"
DEBU[0000] Created root filesystem for container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 at /var/lib/containers/storage/overlay/6eb4445c47e3d0ed23f799a01a9764f0cd40a91d9be2c659a8245cf39af7298b/merged
DEBU[0000] [0] CNI result: Interfaces:[{Name:cni0 Mac:12:82:69:df:e7:1c Sandbox:} {Name:veth70bedefb Mac:f6:66:fb:f4:e7:02 Sandbox:} {Name:eth0 Mac:3a:0a:df:61:42:0f Sandbox:/var/run/netns/cni-e8eb869f-ee62-a4e2-3a6e-a20cc3c5ca84}], IP:[{Version:4 Interface:0xc420567478 Address:{IP:<IP_ADDRESS> Mask:ffff0000} Gateway:<IP_ADDRESS>}], Routes:[{Dst:{IP:<IP_ADDRESS> Mask:00000000} GW:<nil>}], DNS:{Nameservers:[] Domain: Search:[] Options:[]}
DEBU[0000] /etc/system-fips does not exist on host, not mounting FIPS mode secret
DEBU[0000] reading hooks from /usr/share/containers/oci/hooks.d
DEBU[0000] reading hooks from /etc/containers/oci/hooks.d
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] exporting opaque data as blob "sha256:2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage]@2a51bb06dc8baa17b4d78b7ca0d87f5aadbd98d711817dbbf2cfe49211556c30"
DEBU[0000] Setting CGroups for container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 to machine.slice:libpod:d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62
DEBU[0000] Created OCI spec for container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 at /var/lib/containers/storage/overlay-containers/d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62/userdata/config.json
DEBU[0000] /usr/lib/crio/bin/conmon messages will be logged to syslog
DEBU[0000] running conmon: /usr/lib/crio/bin/conmon      args=[-s -c d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 -u d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 -r /usr/sbin/runc -b /var/lib/containers/storage/overlay-containers/d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62/userdata -p /var/run/containers/storage/overlay-containers/d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket -t --log-level debug --syslog]
INFO[0000] Running conmon under slice machine.slice and unitName libpod-conmon-d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62.scope
DEBU[0000] Received container pid: 4207
DEBU[0000] Created container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 in OCI runtime
DEBU[0000] Enabling signal proxying
DEBU[0000] Attaching to container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62
DEBU[0000] connecting to socket /var/run/libpod/socket/d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62/attach
DEBU[0000] Received a resize event: {Width:80 Height:24}
DEBU[0000] Started container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using <IP_ADDRESS>. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using <IP_ADDRESS>. Set the 'ServerName' directive globally to suppress this message
[Fri Dec 14 16:09:16.014428 2018] [mpm_event:notice] [pid 1:tid<PHONE_NUMBER>33856] AH00489: Apache/2.4.37 (Unix) configured -- resuming normal operations
[Fri Dec 14 16:09:16.014685 2018] [core:notice] [pid 1:tid<PHONE_NUMBER>33856] AH00094: Command line: 'httpd -D FOREGROUND'
95.90.200.x - - [14/Dec/2018:16:09:23 +0000] "GET / HTTP/1.1" 200 45
95.90.200.x - - [14/Dec/2018:16:09:39 +0000] "GET / HTTP/1.1" 304 -
^C[Fri Dec 14 16:09:43.940486 2018] [mpm_event:notice] [pid 1:tid<PHONE_NUMBER>33856] AH00491: caught SIGTERM, shutting down
DEBU[0028] Checking container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 status...
DEBU[0028] Cleaning up container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62
DEBU[0028] Tearing down network namespace at /var/run/netns/cni-e8eb869f-ee62-a4e2-3a6e-a20cc3c5ca84 for container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62
INFO[0028] Got pod network &{Name:determined_hypatia Namespace:determined_hypatia ID:d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62 NetNS:/var/run/netns/cni-e8eb869f-ee62-a4e2-3a6e-a20cc3c5ca84 PortMappings:[{HostPort:80 ContainerPort:80 Protocol:tcp HostIP:}] Networks:[] NetworkConfig:map[]}
INFO[0028] About to del CNI network podman (type=bridge)
DEBU[0028] unmounted container "d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62"
DEBU[0028] Successfully cleaned up container d49002a4c327e6861b8bc31d3d2bbac2de83c0343a6a5d8df21df53439203c62

@lsm5 @baude We should definitely be including those configs in the PPA

someone is working on the packaging for debian ... given that this issue is resolved I am going to close it. if the packaging is not correct for debian when that work is done, bugs should be lodged against debian.


Lock in ruby version

rspec fails when using
rvm use 3.0.3
but passes when using 3.3.0.
.ruby-version will change rvm ruby version correctly each time developer changes into the folder

Nice catch merged!


Fixed #681 and #682 Catch up View.updateIndexes for SQLite View Storage

Implemented group view index, views whose name has the same prefix before slash will bet indexed together #681.

_conflict map function is implmeneted #682.

@hideki I fixed per your code review and couple issues in emit block. Please re-review. Thanks!


Incorrect inter-ontology link

GO:0008253 5'-nucleotidase activity should not be linked to
GO:0006470	protein dephosphorylation
It could be linked directly to dephosphorylation (GO:0016311)
Thanks, Pascale

https://github.com/geneontology/go-ontology/issues/12005
Thanks
On 7 Aug 2015, at 5:41, pgaudet wrote:

GO:0008253 5'-nucleotidase activity should not be linked to
GO:0006470	protein dephosphorylation
It could be linked directly to dephosphorylation (GO:0016311)
Thanks, Pascale

Reply to this email directly or view it on GitHub:
https://github.com/geneontology/go-ontology/issues/12003

Committed the following edits:
phosphatase activity part_of dephosphorylation
phosphoprotein phosphatase activity part_of protein dephosphorylation
Last thing I could do is add the reciprocal link
protein dephosphorylation has_part phosphoprotein phosphatase activity


Separate method open() and constructor, enhance consistency between connectors.

Description
This is the first merge request to achieve some goals set  at #554 where you can find more details:

[x] Decouple object creation and connection, keeping some backwards compatibility.
[x] Enhance consistency between connectors.

This will close #445
Tested with
ESC/POS Printer Simulator

Is it necessary to add the hacktoberfest-accepted label to the PR in order to make it count towards Hacktoberfest?

Only if the project does not have a general label. If you check your progress, you should see it on the Hacktoberfest page as waiting now.


security problem when editing a subresource

Let's say we have two resources users and posts, and posts as a subresource of users.
/users/alice/posts will return the list of posts written by alice
/users/alice/posts/post_id will return something only if post_id exists AND alice owns that post, in the sense of the relation described with Bind
POST /users/alice/posts/ body="my new post" will create a new post, and automatically set the post's user to alice, which is really neat ! but then ...
POST /users/alice/posts/ user="bob" body="impersonating bob" will allow alice to create a post attributed to bob. the user gathered from the url (alice) will be discarded and replaced by the user gathered from the body of the request (bob).
I think this last behaviour is inconsistent with the previous examples, and a security issue. Here the variable gathered from the url should take precedence over the one passed as argument. or maybe, having both with different values should raise an error.

Try to define the user Field on posts with ReadOnly: true. Path fields will ignore the Read-Only property, while your own fields will not.

thanks @smyrman nice, you have solved my problem! Two remarks, though:

I still think the described behaviour is inconsistent, and I don't see a use case where that kind of impersonation is legit
There might be a use case where you want to be able to create a new post and define its user field - for example an admin creating a post under the name of another user. In that case you would bind the post schema to another endpoint, say /posts - but you wouldn't be able to set the user field because it is declared as readonly.

1 - Consider PATCH users/alice/posts/ user="bob". For posts it may be a bit werid, but if it was PATCH users/alice/projects/ owner="bob" then the transfer of ownership sounds like a legal operation to me.

I don't see a use case where that kind of impersonation is legit

In real-life cases, when creating a user post, I would have an onInsert hook that set the value from an user object in the (request) context, and still leave it as Read-Only.
For 2, I personally would not recommend rebinding the same resource against several end-points, as I feel it leaves a confusing API, but if you do, you need to choose a way to handle the edge-cases. Could be generating the schema with a helper function with fields set to ReadOnly based on function parameters, or could be something entirely different.

Fair enough, thanks for your insight !

I will close this issue now, but please feel free to report more issues as you find them. PRs for updating/improving the docs are also welcome.


[Bug]: failed to mask sensitive columns for ResultSetExport task

ODC version
4.2.0
OB version

What happened?
When a sensitive column was set, the data will be masked while querying. But it won't be effective for result-set-export task. Origin data will be exported !
What did you expect to happen?
The data of sensitive column can be masked.
How can we reproduce it (as minimally and precisely as possible)?
Exporting any sensitive column will reproduce this.
Anything else we need to know?
No response
Cloud
No response

Fixed.

PASS


Setting struct c-array element with struct instance?

Hey, when I have a c-array with a struct element-type, and try to setf an element to a struct:
(defstruct-g vert (pos :vec2 :accessor pos))
(setf (aref my-array 0) (make-vert :pos (vec2 0 0))

I'm getting can only populate a struct of type VERT with a list or an array
This works:
(defstruct-g vert (pos :vec2 :accessor pos))
(setf (aref my-array 0) (vector (vec2 0 0))

Setting a struct instance is important, however, for copying between c-arrays. This, for example, doesn't work, with :element-type 'vert:
(setf (aref my-array 0) (aref my-other-array 0))

What's the solution here? Is there a copy method I could use?

There is push-g and copy-g, but it doesn't work with c-array <-> c-array or gpu-array <-> gpu-array (only with c-array <-> gpu-array and lisp data <-> gpu/c-array).
I have a similar problem/use case with SSBO's (which are 1-element arrays of the struct of the arrays in the SSBO under CEPL): you can't actually fill the SSBO at make-gpu-array time because of the same conversion issues as above (wrt :element-type 'vert in your example), so you have to first with-gpu-array-as-c-array and then push-g, but since push-g doesn't accept c-array <-> c-array you have to have the data as lisp data, or put it on gpu just so I can bring it back to cpu space so that it can be put back on gpu.

Hmm, i had a look around cepl & couldn't find a fix after a couple hours - is cepl unmaintained currently? looks to be the case

Baggers is busy working on TaleSpire for now so he has had little time to look into CEPL issues, which is a huge shame given how awesome CEPL is: would be great if there could be a few more maintainers. He still checks in sometimes though.
There might be a way to drop down to the cl-opengl level to copy the raw data across gpu-array's as a workaround. For c-arrays, the same could be achieved by dropping down to the cffi level.

My current workaround/solution is to use something like the following:
(defstruct-g struct-name
(a (:vec3 10) :accessor a)
(b (:vec3 10) :accessor b)
(c (:vec3 10) :accessor c))

   (let ((cpu-struct (make-struct-name))
          (gpu-struct (make-gpu-array nil :dimensions '(1) :element-type 'struct-name)))
      (push-g *lisp-data-a*
	      (a cpu-struct))
      (push-g *lisp-data-b*
	      (b cpu-struct))
      (push-g *lisp-data-c*
	      (c cpu-struct)))
      (buffer-data-raw (struct-name-pointer cpu-struct)
		       (+ (c-array-byte-size (a cpu-struct))
			  (c-array-byte-size (b cpu-struct))
			  (c-array-byte-size (c cpu-struct)))
		       (gpu-array-buffer gpu-struct))
           (free cpu-struct))

(apologies for the potentially missing parens and the alignment).
Hopefully this should be easy enough to adapt for your use as well until this part of the CEPL api is cleaned up.


Remove hard-coding of the CUDA platform in rjmc.geometry.py

At the moment it's hard coded with CUDA double, falling back to the slower Reference for testing the endstate energy validations.
It would be better to use OpenCL than reference if double is supported, however there is not a clean way to currently test this. I've opened an openmm issue here: https://github.com/openmm/openmm/issues/2635
to see if that may be possible

Check if this can be closed with the changes in https://github.com/choderalab/perses/pull/1092

Closed via #1092 . geometry.py doesn't have the platform hardcoded now.


Propagate the hosting HWND to the new IFileDialogs

This is required to maintain the modality of the dialogs, which we lost
when we moved from Pickers to IFileDialog. The HWND hosting Window API
we dreamed up is incompatible with IModalDialog, because IModalDialog
requires the HWND immediately upon Show. We're smuggling it in a
uint64, as is tradition.
@zadjii-msft noticed this in #9760.

@msftbot merge this in 2 minutes


Cannot read properties of undefined (reading 'replace') on Git Commit

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.75.0
OS Version: Windows 10

Steps to Reproduce:

Use an SSH key with a passphrase
Do a commit

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.75.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

I get the error when VSCode is set up to do signed commits with an SSH key.
The command to git is:
git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file - -S
The empty file argument seems to be the issue to me.

This also happens on 1.75.1

I'm also getting this error, including with all extensions disabled, and with commit signing both enabled and disabled in settings
Explicitly, I'm getting the same error when the generated git command is both of the following:

with signing: git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file - -S
without signing: git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file -

Version: 1.75.1 (Universal)
Commit: 441438abd1ac652551dbe4d408dfcec8a499b8bf
Date: 2023-02-08T21:34:59.000Z
Electron: 19.1.9
Chromium: 102.0.5005.194
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 22.3.0
Sandboxed: No

I am also experiencing the same issue.

Possibly related to --> https://github.com/microsoft/vscode/issues/159584
Adding my private key to my ssh agent worked for me:
ssh-add <path_to_private_key>
# ssh-add ~/.ssh/personal-github-signing-key ## example, it will ask your passphrase. ##
ssh-add -l ## verify if it is added.

https://github.com/microsoft/vscode/issues/159584#issuecomment-1436614392

^ this just worked for me too!

restart
re-add to ssh agent via ssh-add ... command above

Using ssh-add got rid of the error for me but did not sign the commit.
I didn't previously have any keys added so I just ran the command from the terminal in VSCode and I stopped getting the error without restarting the machine or even VSCode.
However, it did not seem to actually sign the commit.

Closing this as duplicate of https://github.com/microsoft/vscode/issues/179517


Const & enum deep comparison is not strictly typed

The const implementation from #507, and the existing enum implementation, does not properly compare objects. Objects are compared in a loosely-typed manner (==), which also results in a loosely-typed comparison of all members.
This behavior is incorrect, and results in spec violations. For example, "string" == true returns true, despite being clearly invalid - both the type and content are completely different.

Would you like me to take a crack at this? I feel like you need some video game time...

Please! I'm flat out right now...

Righto, then. I have some time on Sunday.


Fixed checking for WebNN support

@ibelem, PTAL, thanks!

LGTM, thanks @Honry !

LGTM, thanks @Honry !


Open/close test

This PR improves the open/close ClientAgentInteraction tests.
Before merge:

[ ] Review https://github.com/eProsima/Micro-XRCE-DDS-Agent/pull/149
[ ] Change Agent branch to develop.

Build status:

Linux
Windows

Build status:

Linux
Windows

Build status:

Linux
Windows

Build status:

Linux
Windows


Improve copyAndClose implementation for https connections

Use half-close methods during copy
Wait for the copy to be finished by waiting on a channel

I had a lot of Error copying errors on our servers for the https connections, in some cases client applications were failing with timeouts. At the moment second copy operation is failing because required half of the connection is closed by the first copy. It also worth waiting for the both copy operations to finish. Similar issue was recently fixed in go-socks5, in this commit.

Looks like a good idea, but why wait on the error channel?
Logging is synchronized anyway, and we don't care which thread would it
happen at.
On Tue, May 17, 2016 at 3:17 AM, Arthur Evstifeev<EMAIL_ADDRESS>wrote:

Use half-close methods during copy
Wait for the copy to be finished by waiting on a channel

I had a lot of Error copying errors on our servers for the https
connections, in some cases client applications were failing with timeouts.
At the moment second copy operation is failing because required half of the
connection is closed by the first copy. It also worth waiting for the both
copy operations to finish. Similar issue was recently fixed in go-socks5,
in this
https://github.com/armon/go-socks5/commit/66ca0497dfb58c4daaf663f53fc8bef7ded309be#diff-d9c546c27e20f6a2acfc4ac7b74c1a26
commit.
You can view, comment on, or merge this pull request online at:
https://github.com/elazarl/goproxy/pull/161
Commit Summary

Improve copyAndClose implementation for https connections

File Changes

M https.go
https://github.com/elazarl/goproxy/pull/161/files#diff-0 (30)

Patch Links:

https://github.com/elazarl/goproxy/pull/161.patch
https://github.com/elazarl/goproxy/pull/161.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/elazarl/goproxy/pull/161

Sorry it wasn't clear from my description. I added waiting not for the logging purposes, but to make code of handleHttps more deterministic and also unify behavior across switch shoulders. I think it will be easier to reason about this method if connections will be always fully handled when it returned, rather than still being processed in one of the goroutines. I don't have a strong feelings about that part, I can remove it if you feel it's unnecessary.

@ap4y another thing if possible. I think it's better to have copyAndClose accept a TCP connection, since it makes little sense otherwise, you need WriteClose in order for the logic to work anyhow. It was a mistake I didn't do it from the beginning.
I don't see debugging value with having another goroutine wait and does nothing. Can you describe a specific case where it would be useful? You can pass the goproxy.Ctx to the CopyAndClose so that you'll know from goroutine dump which request context is it. Having channel makes the code slower and longer with no real benefit IMHO.
Does my two changes sound reasonable? I'll be happy to merge it then.

I changed my commit, but I still see some benefits of having a wait:

It protects code against situation when socket will be improperly managed. Imagine that handleHttps returned and server crashes while goroutines are still processing. Ideally I think this type of errors should be gracefully handled but having wait will be a good start
Code has a different routes in handleHttp (via switch) and only ConnectAccept shoulder returns without finishing operation. Not a biggie, but I think it might be nice to have more uniform behaviour here

I understand that waiting will eat some time, but having more determenistic logic might be worth it.


Python Multiprocessing for computing descriptors

I'm trying to compute all the molecular descriptors from Chem.Descriptors.descList for a large number of compounds. For this reason, I'm trying to using Multiprocessing (more precisely, the map function from pathos.pools.ProcessPool().
At the moment, I wrote the following:
...
mol_descriptors = [desc[1] for desc in Descriptors.descList]

with pathos.pools.ProcessPool() as pool:
    result_pool = pool.map(self.generate_mol_descriptor, smiles, mol_descriptors)
...

where smiles is a list of SMILES codes, and self.generate_mol_descriptor simply computes one descriptor for all the SMILES codes.
Unfortunately, I keep getting the following error: TypeError: can't pickle Boost.Python.function objects. I never used Multiprocessing with RDKit, so I'm not really sure what that means. Is it because I'm trying to pickle C++ functions?

I can’t speak for the pathos library ( it appears to use dill instead of pickle ) however, I have had great success with python multiprocess.
https://github.com/bp-kelley/descriptastorus
(Note the code below hasn’t been tested)
from descriptastorus.descriptors.DescriptorGenerator import MakeGenerator
import multiprocessing
generator = MakeGenerator(("RDKit2D", "Morgan3Counts"))
jobs = ["c1ccccc1" ]
pool = multiprocessing.Pool()
results = pool.map(generator.process, jobs)

Brian Kelley

On Jul 5, 2019, at 5:59 AM, Lorenzo Fabbri<EMAIL_ADDRESS>wrote:
I'm trying to compute all the molecular descriptors from Chem.Descriptors.descList for a large number of compounds. For this reason, I'm trying to using Multiprocessing (more precisely, the map function from pathos.pools.ProcessPool().
At the moment, I wrote the following:
...
mol_descriptors = [desc[1] for desc in Descriptors.descList]
with pathos.pools.ProcessPool() as pool:
result_pool = pool.map(self.generate_mol_descriptor, smiles, mol_descriptors)
...
where smiles is a list of SMILES codes, and self.generate_mol_descriptor simply computes one descriptor for all the SMILES codes.
Unfortunately, I keep getting the following error: TypeError: can't pickle Boost.Python.function objects. I never used Multiprocessing with RDKit, so I'm not really sure what that means. Is it because I'm trying to pickle C++ functions?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@bp-kelley is faster than me... but that's because I actually tested my code. ;-)
I would also suggest rethinking how you are doing this. It looks like your proposed solution is going to reconstruct every molecule for every descriptor. That is incredibly inefficient.
This snippet uses multiprocessing and generates all the descriptors for each molecule in parallel:
from rdkit import Chem
from rdkit.Chem import Descriptors

def calc_descrs_for_smiles(smi,descList):
    m = Chem.MolFromSmiles(smi)
    if m is None:
        return dict(zip(descList,[None]*(len(descList))))
    fns = [(x,y) for x,y in Descriptors.descList if x in descList]
    res = {}
    for x,y in fns:
        res[x] = y(m)
    return res

if __name__=='__main__':
    descList = [desc[0] for desc in Descriptors.descList]

    smis = [x.split()[0] for x in r'''Br\C=C\1/CCC(C(=O)O1)c2cccc3ccccc23	23
COc1cc2nc(nc(N)c2cc1OC)N3CCN(CC3)C(=O)c4occc4	97
CN1CCC[C@H]1c2cccnc2	115
CC1COc2c(N3CCN(C)CC3)c(F)cc4C(=O)C(=CN1c24)C(=O)O	146
CCN1C=C(C(=O)O)C(=O)c2ccc(C)nc12	147
Oc1cc2C(=O)Oc3c(O)c(O)cc4C(=O)Oc(c1O)c2c34	148
COc1ccc2c(c1)c(CC(=O)O)c(C)n2C(=O)c3ccc(Cl)cc3	173
CC1(C)[C@@H](N2[C@@H](CC2=O)S1(=O)=O)C(=O)O	194
Cn1cc(C2=C(C(=O)NC2=O)c3cn(CCCSC(=N)N)c4ccccc34)c5ccccc15	213
CN1CCN(CC1)c2cc3N(C=C(C(=O)O)C(=O)c3cc2F)c4ccc(F)cc4	205
C[C@]1(Cn2ccnn2)[C@@H](N3[C@@H](CC3=O)S1(=O)=O)C(=O)O	207
CN1CCN(CC1)c2c(F)cc3C(=O)C(=CN(CCF)c3c2F)C(=O)O	210
CCc1cc2c(Sc3nnc(N)s3)ncnc2s1	236'''.split('\n')]

    for i in range(8):
        smis += smis
    from multiprocessing import Pool
    def func(x):
        return calc_descrs_for_smiles(x,descList)
    with Pool(processes=4) as pool:
        res = pool.map(func,smis)
    print(len(res))

Thank you both, @bp-kelley and @greglandrum ! I'll test both solutions before closing the issue.

I'm getting the same error but with GetAdjacencyMatrix and joblib. Commenting out my GetAdjacencyMatrix line works (albeit the function fails because it depends on the adjacency matrix). Multiprocessing also doesn't work as the function is not pickleable. Do you have any suggestions?

Python can't pickle boost related functions for a similar reason that it
can't pickle lambda functions.
However, it CAN pickle functions that call boost functions:
import multiprocessing
from rdkit import Chem
def foo(x):
return Chem.GetAdjacencyMatrix(x)
if name == "main":
with multiprocessing.Pool() as pool:
print(pool.map(foo, [Chem.MolFromSmiles("c1ccccc1")]))
I will point out that if you can all of the molecule creation in the
process it can be quite a bit faster.  The above example reads and creates
the molecule, serializes the molecule via pickle and then the process has
to unpickle it.
Compare this against the alternative which should consume less memory and
get faster as the number of molecules increases.
import multiprocessing
from rdkit import Chem
def foo(smiles):
m = Chem.MolFromSmiles(smiles)
if m:
return Chem.GetAdjacencyMatrix(m)
return None
if name == "main":
with multiprocessing.Pool(4) as pool:
pool.map(foo, ["c1ccccc1"])
Cheers,
Brian
On Mon, Jul 8, 2019 at 10:57 AM Eric<EMAIL_ADDRESS>wrote:

I'm getting the same error but with GetAdjacencyMatrix and joblib.
Commenting out my GetAdjacencyMatrix line works (albeit the function fails
because it depends on the adjacency matrix). Multiprocessing also doesn't
work as the function is not pickleable. Do you have any suggestions?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rdkit/rdkit/issues/2529?email_source=notifications&email_token=ACLOFIA6DGS22VKVW26A3B3P6NIUPA5CNFSM4H6J2WN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZNLIRI#issuecomment-509260869,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACLOFICJSAKJCBZVBCR5KOTP6NIUPANCNFSM4H6J2WNQ
.

Wrapping the function and using joblib does not work for me, and throws the same error.
from rdkit.Chem import MolFromSmiles, AddHs
...
    def molify(self, smiles_string):
        """
        Wrapper function to return rdkit mol from smiles string
        """
        m = MolFromSmiles(smiles_string)
        m = AddHs(m)
        return m

...
        with Parallel(n_jobs=-1) as pool:
        # data['mols'] = [AddHs(MolFromSmiles(s)) for s in data['smiles']]
            data['mols'] = pool(delayed(self.molify)(i) for i in data['smiles'])

Why doesn't this work?


thread safety in openblas 0.2.20

In one of my simulation codes written in FORTRAN2008, there is a loop over a number of signal frequencies and for each of these frequencies, a system of linear equations is solved using calls to ZGBTRF or ZGBTRS in the loop body. Since there is some effort required to generate the system matrix and rhs vector for each frequency, I decided to parallelize the loop using OpenMP meaning that only a single thread would be used to solve the system of linear equations at a given signal frequency. This used to work fine with openblas 0.2.19 and the Intel Math Kernel Library.
After compiling openblas 0.2.20 using gcc and gfortran versions 6.3 or 7.2 on Ubuntu 17.10 using make TARGET=HASWELL USE_OPENMP=1 BINARY=64 FC=gfortran, I have trouble obtaining correct matrix inversion results in the parallelized loop issuing calls to ZGBTRF or ZGBTRS in the loop body, when I increase the number of threads to work on the parallelized loop to be larger than one using the OMP_NUM_THREADS variable. It seems that this is a problem with thread safety in openblas 0.2.20. A workaround I tested is to set the OPENBLAS_NUM_THREADS variable to 1 just before the start of the loop using "call openblas_set_num_threads(1)" in the fortran source code. However, this sets OMP_NUM_THREADS to 1, too. So, even though the results of the workaround are correct, this is not satisfactory, because the loop is executed in sequential order. From the description given in the current README.md file, this behaviour is somewhat unexpected.
I hope that this description helps you to localise the problem. I would be more than happy to assist checking updates using my code.
By the way, do you have any plans to write parallelised versions of the Cholesky decomposition (DPPTRF and DPPTRS)?
Keep up the good work!

Hi,
I recompiled (after issuing make clean) using USE_SIMPLE_THREADED_LEVEL3=1, but this did not fix the problem. Following the hash history is definitely an option. Would you mind to get me started on this and help me with the hash numbers of versions 0.2.19 and 0.2.20?

0.2.20 is  5dde4e6 , 0.2.19 is 85636ff (you can find this information when you click on the "(35) releases" tab at the top of the "Code" view)

Trivial tests with odd inputs did not yield results:
http://www.netlib.org/lapack/explore-html/d3/d01/group__complex16_g_ecomputational_ga5b625680e6251feb29e386193914981c.html

Hi,
sorry for the long delay!
I followed the advice on bisecting and a complete recompilation (including make clean) and a new test run with my example in each step. This lead to the following output from git:
1153e3ac3933c8f4727c97b864b26d9b729bed42 is the first bad commit
commit 1153e3ac3933c8f4727c97b864b26d9b729bed42
Author: Werner Saar<EMAIL_ADDRESS>Date:   Sat Jan 7 08:41:42 2017 +0100
filtered out -fopenmp and fix for mingw

:040000 040000 f95854d7e6259ea7f4f0a379816254750fb34bef 9ad1e3dec1776d590f5bb07639ecfc27ea333405 M	lapack-netlib
I hope this will help you in finding the problem. Let me know, if I can do further tests.

Thank you. The only functional change from that commit appears to be the unconditional removal of the -fopenmp compiler flag when building LAPACK. According to comments in Makefile.system (and the corresponding cmake file derived from it) this is/was somehow necessary for building with gcc on Windows, but I do not see why it should suddenly become universally required. Possibly this was a peculiarity of wernsaar's mingw installation at that time (not getting detected as OS_WINDOWS and
failing to build with the flag still set). Could you make sure that your code runs correctly when you drop that single change from lapack-netlib/SRC/Makefile ? (Easiest would be to just change the two
occurrences of "$(OPTS1)" at the very end of the Makefile back to "$(OPTS)" )

Hmm. Seems I had stumbled on this oddity in #1269 already, but unfortunately without realizing its significance.

Even more deja vu - I was bitten by (an earlier version of) this myself in #329, and the only rationale for disabling OpenMP on Windows seems to have been a LAPACK test failure when compiling 0.2.8 with the then-current version of TDM-GCC (#286) - and haven't we had seen oddities with this particular port of gcc since then ?

I think it is worth mentioning somewhere in FAQ that one cross-builds on mingw for Win32 host like from linux to Win32 . I find later option easier. Ermm.. what it just changing /quickbuild.win scripts to instruct cross-builds?

The drawback is that it would require one to have a Linux system available, or be capable and willing to set one up for this purpose. It could be mentioned on the wiki page I guess, but my feeling is that it has become confusing enough with the recent addition of experimental cmake/flang builds.
Removing that easter egg from the LAPACK Makefile induces a minimum requirement of gcc 4.9, but that appears to be due to OMP4.0 directives (TASK DEPEND) in a few files that were new in 3.7.0. (Wonder if those may have prompted the controversial change?)

In this case I share doubt if mingw cross-compiler (essentially renamed gcc.exe) would help.

I followed the instructions to modify the Makefile and, indeed, this has resolved the problem with openblas thread safety. I have tested this on the platforms for which I originally reported the problem (i7-4770 and i5-4210M, gcc and gfortran v. 7.2) and additionally on an AMD TR 1950X that I got only last week. For both v. 0.2.20 and the current development version, the modification of the Makefile solves the problem.
In my original post, there was another problem (very unclearly described though) regarding the performance of the Cholesky decomposition. I had entirely forgotten to mention that I used DPPSV for packed format, which did not at all perform well using openblas (seemingly no parallelisation) but is a factor of 9 or so faster using sequential MKL and also scales well with the number of cores using MKL. Replacing the call to DPPSV by a call to DTPTTR (conversion to regular format), followed by a call to DPOSV (Choleski decomposition) solved this problem. Using openblas and just a single thread, the sequence of DTPTTR and DPOSV is 8-10 faster than DPPSV and increasing the number of threads the sequence of DTPTTR and DPOSV seems to scale very well. Using this modification, my code (which calls various BLAS and LAPACK routines) linked to openblas is almost on par to when it is linked to mkl (roughly 10% slower, depending on problem size). I think this is very good. Many thanks for the work you put into openblas!
There are two points that, depending on your response, I may want to formulate as suggestions for future development:

After plenty of initial tests with the AMD TR 1950X processor, it seems that openblas (tested 0.2.19, 0.2.20 and the development version on Ubuntu 17.10 with kernel 4.13, gcc and gfortran v. 7.2) operates roughly 20% slower on the TR1950X than on an i7-4770 (4 cores) when using 1, 2 and 4 threads. This is somewhat surprising given that both CPUs use at most AVX2 and thus should be comparable in terms of vectorisation potential. I have already adjusted the OpenMP thread affinity to exclude that the (hidden) NUMA architecture of the TR1950X causes its lower performance. Other measures I took were 1) BIOS upgrade, 2) Linux kernel upgrade to 4.15, 3) increased DIMM frequency from 2133 to 2666 MHz. Except for the latter, which gave a speedup of roughly 3%, these measures did not have any effect on execution speed. Do you have any idea where the degraded performance on the TR1950X comes from? Is this related to a current lack of optimization in openblas or do we just have to wait for the next major release of gcc/gfortran to fix the problem? Of course, I would be willing to run tests, if this was of help in developing openblas.
As the 1st response to my original post, brada4 commented that I was oversubscribing cores by calling parallel openblas routines inside an OpenMP parallelised loop. This is of course correct. Until very recently I had used mostly MKL, which - to my knowledge - automatically switches to sequential BLAS and LAPACK routines when these are called from within OpenMP parallelised loop. Would such a mechanism of automatically switching between sequential and threaded subroutine versions be possible to implement in openblas?

AMD has slightly slower AVX and AVX2 units per CPU, by no means slow in general, it still has heap of cores spare. Sometimes optimal AVX2 saturation means turning whole CPU cartridge to base, i.e non-turpo frequency.
Desirable , but this is not yet in OpenBLAS. Ideally you should be able to set OMP_NUM_THREADS=4,1 or 2,2,,,, etc - size threading at all levels for optimal result.

@tkswe88  you could try the blis framework https://developer.amd.com/amd-cpu-libraries/blas-library/ which has optimized kernels for the Zen architecture. But indeed, optimzation for the new processors could be a goal for future OpenBLAS releases.

Could also be that getarch is mis-detecting the cache sizes on TR, or the various hardcoded block sizes from param.h for loop unrolling are "more wrong" on TR than they were on the smaller Ryzen. Overall support for the Ryzen architecture is currently limited to treating it like Haswell, see #1133,1147. There may be other assembly instructions besides AVX2 that are slower on Ryzen (#1147 mentions movntp*).
On the topic of DPPSV vs. DPOSV, the latter is basically POTRF for which the netlib LAPACK implementation is overloaded by an optimized and  parallelized implementation in lapack/potrf.

@brada4: Many thanks for the clarification regarding the frequencies employed in AVX and AVX2 in the TR1950X. I will follow your advice setting the OMP_NUM_THREADS variable.
@MigMuc: I tried the blis and flame libraries provided by AMD in binary form, but AMD seem to have forgotten to include the lapack interface lapack2flame. So, in the linking phase of compiling my code, there are errors saying that not a single lapack routine is found. I tried recompilation from the blis and flame source which ended up in segmentation faults when running my code. Also, while blis seems to be actively developed (it has a zen target), there seems to be very little development activity for flame on github (the manual is 4 years old!).
@martin-frbg: Are there any tests I could do to find out about cache size detection errors or more appropriate settings for loop unroling?

It will not work, OpenBLAS will always spin up full number of top hierarchy threads, no matter it is called at later level. NN.... oversubscription.
What you asked to martin - copied parameters may need doubled or halved at least here: https://github.com/xianyi/OpenBLAS/pull/1133/files#diff-7a3ef0fabb9c6c40aac5ae459c3565f0

You could check the information in config.h against the specification. (As far as I can determine, L3 size seems to be ignored as a parameter). The benchmark directory contains a few tests that can be used for timing individual functions.

At least one of our travis checks appears to still use gcc 4.6, so it falls over the OMP TASK DEPEND.
Anybody experienced with OpenMP to tell (what may be a silly question) if replacing the "OMP TASK DEPEND" with a simple OpenMP 3.0 "OMP TASK" would still be safe (if less efficient) in code fragments like
  !$OMP TASK DEPEND(in:WORK(MYID+SHIFT-1))
  !$OMP$     DEPEND(in:WORK(MYID-1))
  !$OMP$     DEPEND(out:WORK(MYID))

(from https://github.com/xianyi/OpenBLAS/blob/develop/lapack-netlib/SRC/chetrd_hb2st.F#L517)
or what else would be available in OpenMP 3.0 to achieve the desired effect ? Should this be
"OMP SERIALIZE" for _OPENMP < 201307 ?

Regarding thread-safety of fortran programs, there is a variable in Makefile.rule which has to be set according to the explanation:
# gfortran option for LAPACK
# enable this flag only on 64bit Linux and if you need a thread safe lapack library
# Flags for POWER8 are defined in Makefile.power. Don't modify FCOMMON_OPT
# FCOMMON_OPT = -frecursive

I found some further explanations in:
http://wwwf.imperial.ac.uk/~mab201/20120814.html


CUDA out of memory

RuntimeError: CUDA out of memory. Tried to allocate 32.00 MiB (GPU 0; 23.99 GiB total capacity; 37.27 GiB already allocated; 0 bytes free; 37.33 GiB reserved in total by PyTorch)

I run this code on 24G GPU, this error always happened after epoch 2 whatever batch_size I set, is there anything wrong with my environment?

which python script do you use? I think it has nothing to do with the environment. Maybe more detailed information you can provide

I take python3.10.12 as my interpreter. should I change the python version?

use this， https://github.com/archersama/IntTower/blob/main/requirements.txt，and try python3.7


support --docker-network arg for dev cli

This adds support to the dev CLI for passing in a custom docker network during development.
Usage:
npx jamsocket dev --docker-network foobar

Note: this network must exist before spawning backends, otherwise they will fail to start.

Would it be hard to check if the network exists when the dev CLI starts? It wouldn't catch the case where the network is deleted, but we could catch most cases.


Cannot run ipctool in my stock firmware

Hi there, I was able to transfer ipctool to my stock firmware using tftp, but when trying to run it, it fails with:
[root@rhea_10:tmp]# ./ipctool --help
./ipctool: line 1: syntax error: unexpected word (expecting ")")

Never mind. I was using the wrong one, I should have used mips32 one instead.


New Death animation and attached blades to melee grunt

The new prefab for the melee grunt enemy is named as MeleeGruntWeaponized. The new model includes blade attached to the arms and a new death animation. Now the enemy can die in two different ways, and it is randomized the way it dies.
I added a scene named TestAnimationsMeleeGrunt that can be used for testing.

Task linked: CU-n975pf Update Melee Grunt Animations

I updated the model with the stunned animations and created the material for the weapons and added it to the prefab


fix menu disappear after resizing window

Solution
Add menu-close class to the left menu that will have effect only on 900px breakpoint
BEFORE
 Baat Cheet Sidebar bug
AFTER
 Baat Cheet Sidebar bug fix

Merged :rocket: Good job @Everkers.