[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user -- missing CacheDirectory=

I now did exactly the same steps as above on an Ubuntu 20.04 VM, with exactly the same results. This verifies 4.33-3ubuntu1.20.04.1. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, wh

[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user -- missing CacheDirectory=

Verification for groovy: I took a 20.10 VM with current pollinate 4.33-3ubuntu1, and after booting, pollinate.service is in state failed as per the bug description. I then updated to 4.33-3ubuntu1.20.10.1. The package update auto- restarted pollinate.service, and it looked successful: # systemct

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

Control: reassign -1 network-manager 1.29.90-1 Control: tag -1 upstream fixed-upstream Control: forwarded -1 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/662 This eventually *did* turn out to be a bug in NetworkManager itself, and only became visible now because of the be

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

Control: reassign -1 network-manager 1.29.90-1 Control: tag -1 upstream fixed-upstream Control: forwarded -1 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/662 This eventually *did* turn out to be a bug in NetworkManager itself, and only became visible now because of the be

[Pkg-utopia-maintainers] Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

Control: reassign -1 network-manager 1.29.90-1 Control: tag -1 upstream fixed-upstream Control: forwarded -1 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/662 This eventually *did* turn out to be a bug in NetworkManager itself, and only became visible now because of the be

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

Martin Pitt [2021-02-14 11:41 +0100]: > So this is some weird NM build system issue that breaks something for any tag > (i.e. minor/micro version in configure.ac) >= 1.28.0. Note that the 1.28-rc* > tags > have version 1.27.x. I checked out tag 1.30-rc1 (aka version 1.29.

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

Martin Pitt [2021-02-14 11:41 +0100]: > So this is some weird NM build system issue that breaks something for any tag > (i.e. minor/micro version in configure.ac) >= 1.28.0. Note that the 1.28-rc* > tags > have version 1.27.x. I checked out tag 1.30-rc1 (aka version 1.29.

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

Hello all, CC'ing Thomas, maybe he has some idea about this. Thomas, please see [0] for the python-dbusmock failure that triggered this bug report. Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_a

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

Hello all, CC'ing Thomas, maybe he has some idea about this. Thomas, please see [0] for the python-dbusmock failure that triggered this bug report. Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_a

Bug#982613: Debian Python Team

Control: reassign -1 0.22.0-1 Control: affects -1 network-manager Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... ** > libnm:ERROR:libnm/nm-client.c:28

Bug#982613: Debian Python Team

Control: reassign -1 0.22.0-1 Control: affects -1 network-manager Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... ** > libnm:ERROR:libnm/nm-client.c:28

[Pkg-utopia-maintainers] Bug#982613: Debian Python Team

Control: reassign -1 0.22.0-1 Control: affects -1 network-manager Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... ** > libnm:ERROR:libnm/nm-client.c:28

[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user -- missing CacheDirectory=

@Christian: Debian still needs/wants to support sysvinit. Of course init.d scripts ought to create cache directories too (like munin, mopidy, and others already do, but probably not all of them), but that will be a bit more work. FHS applies to SysV init as well, so the same reasoning still holds.

[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user -- missing CacheDirectory=

** Changed in: pollinate (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1848923 Title: pollinate.service fails to start: ERROR: should execute as the

[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user -- missing CacheDirectory=

> Where could we download one of them to check the state of that path in there? See comment #7: git clone https://github.com/cockpit-project/bots/ bots/vm-run ubuntu-stable But I suppose that's moot now :) -- You received this bug notification because you are a member of Ubuntu Bugs, which

[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user -- missing CacheDirectory=

Indeed all our images clear up /var/cache [1]. Sorry, I forgot about this bit before! An admin should always be able to rm -rf /var/cache, reboot, and get a fully working system [2]. So if the pollinate data is in any way precious, it should better be in /var/lib/pollinate then (similar to /var/lib

[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user

Thanks Christian! Interesting, the "ERROR: should execute as the [pollinate] user" looks quite unrelated to any networking setup and smelled like a package postinst/systemd unit bug. I started trying to reproduce this outside of the Ubuntu CI, with a most naïve curl -O https://cloud-images.ubu

Re: How to store user-input data?

Hello Tobias, Matej Marusak [2021-02-04 17:59 +0100]: > I assume this "list of remote hosts" is not the same list of hosts on which > you use cockpit. When you need to store some database on the server just > pick a well defined location and use that. (like > /usr/share/myapp/database.db) Please

[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user

I just tested on current 20.04 and 20.10 cloud images, still the same bug. There was exactly one upload since then [1] which was trivial (just updating the watch file). [1] https://launchpad.net/ubuntu/+source/pollinate/+changelog ** Changed in: pollinate (Ubuntu) Status: Incomplete => Tri

[Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user

One more thing: That package hasn't worked in literally years, and is also obsolete. QEMU has had `-device virtio-rng-pci` for a long time now, libvirt uses it by default, and apparently most cloud providers use that, too. So I suggest to remove the package from Ubuntu, but *at least* from the defa

Bug#981813: Acknowledgement (API regression: Could not get either XDG_CONFIG_HOME or HOME)

Control: notfound -1 2.1.1+dfsg1-4 Control: found -1 2.1.1+dfsg1-5 Control: found -1 2.2.1+dfsg1-1 Control: notfound 3.0.0~rc2+dfsg1-2 Control: tag -1 pending Capturing the affected versions as per the initial report.

[pkg-go] Bug#981813: Acknowledgement (API regression: Could not get either XDG_CONFIG_HOME or HOME)

Control: notfound -1 2.1.1+dfsg1-4 Control: found -1 2.1.1+dfsg1-5 Control: found -1 2.2.1+dfsg1-1 Control: notfound 3.0.0~rc2+dfsg1-2 Control: tag -1 pending Capturing the affected versions as per the initial report. ___ Pkg-go-maintainers mailing list

Bug#981813: API regression: Could not get either XDG_CONFIG_HOME or HOME

Package: podman Version: 2.1.1+dfsg1-5 A few days ago, our cockpit-podman tests started to fail on Debian testing [1] (screenshot [2]) for committing images. This coincides with the testing update of 2.1.1+dfsg1-4 (last known good version) to 2.1.1+dfsg1-6. CLI reproducer (as root): # start from

[pkg-go] Bug#981813: API regression: Could not get either XDG_CONFIG_HOME or HOME

Package: podman Version: 2.1.1+dfsg1-5 A few days ago, our cockpit-podman tests started to fail on Debian testing [1] (screenshot [2]) for committing images. This coincides with the testing update of 2.1.1+dfsg1-4 (last known good version) to 2.1.1+dfsg1-6. CLI reproducer (as root): # start from

Re: Help about using cockpit with docker

Hello Elhamsadat, Elhamsadat Azarian [2021-01-27 14:10 +0330]: > i installed cockpit on a virtual machine and it work with other vm. > i want to know if it could work with containers on docker host too? > does cockpit server monitor containers on docker too? Older releases such as RHEL/CentOS 7,

Bug#981127: cockpit: FTBFS on hppa - test timeout is way too small

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15223 Control: tag -1 upstream pending Hello John, Ugh, is HPPA know to have such a poor threading performance in general? Thanks for doing the manual build! > We either need to skip the test-tls-certfile on hppa or greatly ex

[Pkg-utopia-maintainers] Bug#981127: cockpit: FTBFS on hppa - test timeout is way too small

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15223 Control: tag -1 upstream pending Hello John, Ugh, is HPPA know to have such a poor threading performance in general? Thanks for doing the manual build! > We either need to skip the test-tls-certfile on hppa or greatly ex

Cockpit 236 released

/236 Take care, Martin Pitt ___ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of

Cockpit 235 released

-project/cockpit/releases/tag/235 Take care, Martin Pitt ___ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https

Bug#943500: my NMU made it FTBFS

Hello Helmut, Helmut Grohne [2020-12-30 8:44 +0100]: > unfortunately, my NMU made cracklib2 FTBFS on various architectures. It > turns out that the py_builddir_sh also needs the _PYTHON_* variables or > it will disagree with them. I've immediately uploaded another to fix it. > It further simplifi

Bug#978135: cockpit: should recommend sudo

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15074 Hello Cesare, Cesare Leonardi [2020-12-26 16:16 +0100]: > For this reason I believe that cockpit package should at least > recommend "sudo". Thanks for your report! I sent a PR upstream to adjust the dependencies accordi

[Pkg-utopia-maintainers] Bug#978135: cockpit: should recommend sudo

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15074 Hello Cesare, Cesare Leonardi [2020-12-26 16:16 +0100]: > For this reason I believe that cockpit package should at least > recommend "sudo". Thanks for your report! I sent a PR upstream to adjust the dependencies accordi

Bug#978310: umockdev: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1

Control: tag -1 fixed-upstream pending Control: forwarded -1 https://github.com/martinpitt/umockdev/issues/115 Hello Lucas, Lucas Nussbaum [2020-12-26 22:57 +0100]: > > Bail out! ERROR:../tests/test-umockdev.c:1135:t_testbed_usb_lsusb: > > assertion failed (exit_status == 0): (256 == 0) I notic

Bug#978310: umockdev: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1

Control: tag -1 fixed-upstream pending Control: forwarded -1 https://github.com/martinpitt/umockdev/issues/115 Hello Lucas, Lucas Nussbaum [2020-12-26 22:57 +0100]: > > Bail out! ERROR:../tests/test-umockdev.c:1135:t_testbed_usb_lsusb: > > assertion failed (exit_status == 0): (256 == 0) I notic

Bug#928436: cracklib2 NMU with delay 10

Hello Helmut, Helmut Grohne [2020-12-26 17:39 +0100]: > given the prolonged silence on these bugs, I've uploaded a NMU with > delay 10 fixing both and adding a Multi-Arch stanza. All of the changes > seem quite safe to me. I've performed local test builds for various > configurations (nocheck, nop

Bug#900381: Fails to boot cirros QEMU image with tuned running

Hello Evgeni, as this bug report is quite old, I first re-checked this with the versions in testing from a few days ago: qemu-system-x86 1:5.1+dfsg-4+b2 tuned2.10.0-1 linux-image-5.9.0-4-cloud-amd64 5.9.11-1 Without tuned, cirros boots, a

Bug#968400: cockpit-ws: Warning on upgrades

Control: tag -1 patch pending Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15065 Hello Cesare, thanks for your report! I sent an upstream PR to fix that. Martin

[Pkg-utopia-maintainers] Bug#968400: cockpit-ws: Warning on upgrades

Control: tag -1 patch pending Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15065 Hello Cesare, thanks for your report! I sent an upstream PR to fix that. Martin ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@al

Re: Problems with starter-kit

Hello Andreas, Andreas Schockenhoff [2020-12-14 17:00 +0100]: > Am 14.12.2020 um 06:37 schrieb Martin Pitt: > > > I have problems after I clone with git and start make. > > > > > > https://github.com/asc4asc/starter-kit/blob/master/2020-12-12T10_56_30_277Z-de

Re: Problems with starter-kit

Hallo Andreas, Andreas Schockenhoff [2020-12-13 10:22 +0100]: > is this the right mailing list to report this issues? https://github.com/cockpit-project/starter-kit/issues is a better place, but it's also on topic here. > I have problems after I clone with git and start make. > > https://github

[Bug 1906320] Re: fake-device-wrapper should bind-mount efivars

FTR, I would strongly advise against that, see https://github.com/martinpitt/umockdev/issues/110#issuecomment-736224503 . You want the tests to work independently on the hardware it's running on, so that you can run it on e.g. standard autopkgtest infra. You could create /sys/firmware/efi/efivars/

[Desktop-packages] [Bug 1906320] Re: fake-device-wrapper should bind-mount efivars

FTR, I would strongly advise against that, see https://github.com/martinpitt/umockdev/issues/110#issuecomment-736224503 . You want the tests to work independently on the hardware it's running on, so that you can run it on e.g. standard autopkgtest infra. You could create /sys/firmware/efi/efivars/

Bug#973287: systemd autopkgtest-virt-lxc failure on arm64

Hello Michael, Michael Biebl [2020-11-27 9:23 +0100]: > > By the way, systemd autopkgtest-virt-qemu works fine if packages with > > "Priority: important" are included in VM. > > But packages "Priority: required" is only included, the systemd test > > script fails. > > Is it considered as a bug??

Re: Bug#973287: systemd autopkgtest-virt-lxc failure on arm64

Hello Michael, Michael Biebl [2020-11-27 9:23 +0100]: > > By the way, systemd autopkgtest-virt-qemu works fine if packages with > > "Priority: important" are included in VM. > > But packages "Priority: required" is only included, the systemd test > > script fails. > > Is it considered as a bug??

[Bug 1905212] Re: On 20.04 arm64 (raspberry) can't install cockpit from focal-backports

Sorry, it wasn't built on armhf/arm64 yet: https://launchpad.net/ubuntu/+source/cockpit/231-1~ubuntu20.04.1 There's currently some hw maintenance going on: https://lists.ubuntu.com/archives/launchpad- announce/2020-November/000107.html -- You received this bug notification because you are a memb

[Bug 1905212] Re: On 20.04 arm64 (raspberry) can't install cockpit from focal-backports

This is the wrong way to invoke apt, as the package/release syntax will install *only* that package from backports, but resolve all dependencies from main. Please try this: sudo apt install -t focal-backports cockpit ** Changed in: cockpit (Ubuntu) Status: New => Invalid -- You rec

Bug#973010: pcp is uninstallable on many architectures due to new bpftrace dependency

Package: pcp Version: 5.2.1-1 Severity: serious Tags: patch The recent 5.2.1-1 upload made a dependency change to pcp: Package: pcp -Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl, python3-pcp, python3, libpcp-web1 +Depends: ${shlibs:Depends}, ${misc:Depends}, gawk

Bug#973010: pcp is uninstallable on many architectures due to new bpftrace dependency

Package: pcp Version: 5.2.1-1 Severity: serious Tags: patch The recent 5.2.1-1 upload made a dependency change to pcp: Package: pcp -Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl, python3-pcp, python3, libpcp-web1 +Depends: ${shlibs:Depends}, ${misc:Depends}, gawk

Re: Tests failing in testlib login_and_go

Hello Justin, Justin Stephenson [2020-10-02 15:13 -0400]: > Browsing to http://127.0.0.2:9091/ shows me the expected cockpit login > screen, but browsing to http://127.0.0.2:9091/cockpit/login I just see > 'Authentication failed' > > The resulting js.log has the following line: > > cdp: {'so

Re: Building cockpit fully from source offline

Hello Ludwig, Ludwig Nussel [2020-09-25 19:49 +0200]: > Also, some products that could be candidates to have cockpit > included may still be in use when our names are long engraved on > tombstones already. So while using an additional, external CI system > to feed the actual distro build system wo

Bug#971253: podman: Error: default OCI runtime "runc" not found: invalid argument

Package: podman Version: 2.0.6+dfsg1-1 This is the inverse of https://bugs.debian.org/961016 . On a pristine debian-testing, installing podman now pulls in crun by default: | # apt install podman | Reading package lists... Done | Building dependency tree | Reading state information... Done | The

[pkg-go] Bug#971253: podman: Error: default OCI runtime "runc" not found: invalid argument

Package: podman Version: 2.0.6+dfsg1-1 This is the inverse of https://bugs.debian.org/961016 . On a pristine debian-testing, installing podman now pulls in crun by default: | # apt install podman | Reading package lists... Done | Building dependency tree | Reading state information... Done | The

Re: Building cockpit fully from source offline

Martin Pitt [2020-09-28 8:50 +0200]: > Of course the difference is that gcc or binutils are properly packaged in > distros and themselves are built from source, which isn't true for e.g. sass. > So if your efforts are about properly packaging compiled devDependencies, then &

Re: Building cockpit fully from source offline

Hello Ludwig, Ludwig Nussel [2020-09-25 13:25 +0200]: > So far the cockpit packages we have for openSUSE Tumbleweed use the > upstream release tarball. That means all web assets are prebuilt. Right, that's how we use them as well. > Therefore cannot be patched, it's almost like bundling binaries

Re: Cockpit 227 released

Hello Adam, Adam Williamson [2020-09-03 11:41 -0700]: > Ahh, sorry, I was misinterpreting the test failure - I forgot a little > wrinkle about what it does at the point where it failed. What's changed > is actually just that the "Requires" text looks a bit different now > than it used to. What I f

Cockpit 227 released

://github.com/cockpit-project/cockpit/releases/tag/227 Take care, Martin Pitt signature.asc Description: PGP signature ___ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-le

[Bug 1892756] Re: System libvirt-dbus broken after changing libvirtd.socket SocketMode to 0660

ISTM that adding the libvirt-dbus user into the libvirt group is the right fix here. According to /usr/share/dbus-1/system.d/org.libvirt.conf only root and libvirt group users can call its interface. So that useradd seems correct to me, and it should be put into the Debian package. Unfortunately l

[Bug 1885188] Re: fatrace autopkgtest failure due to rename test

https://github.com/martinpitt/fatrace/releases/tag/0.16 I uploaded this to Debian as well, from where it should get auto- imported into groovy. ** Changed in: fatrace Status: Fix Committed => Fix Released ** Changed in: fatrace (Ubuntu) Status: In Progress => Fix Committed -- You

[Kernel-packages] [Bug 1861053] Re: no fatrace output in focal

FTR, I just ran fatrace a lot in a current Ubuntu 20.04 VM to debug #1885188, and it seems fine. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1861053 Title: no fatrace output in focal

[Bug 1861053] Re: no fatrace output in focal

FTR, I just ran fatrace a lot in a current Ubuntu 20.04 VM to debug #1885188, and it seems fine. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1861053 Title: no fatrace output in focal To manage no

[Bug 1885188] Re: fatrace autopkgtest failure due to rename test

anged in: fatrace (Ubuntu) Assignee: (unassigned) => Martin Pitt (pitti) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885188 Title: fatrace autopkgtest failure due to rename test To manag

[Bug 1885188] Re: fatrace autopkgtest failure due to rename test

** Changed in: fatrace Assignee: (unassigned) => Martin Pitt (pitti) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885188 Title: fatrace autopkgtest failure due to rename test To man

[Bug 1885188] Re: fatrace autopkgtest failure due to rename test

Thanks Christian for your initial investigations! I'm back from vacation, looking into this now. Observations: * The 0.13 tests still work fine , so this is indeed a problem with the "new" FAN_REPORT_FID mode. * I finally moved the

[Bug 1890786] [NEW] ipa-client-install fails on restarting non-existing chronyd.service

Public bug reported: DistroRelease: Ubuntu 20.10 Package: freeipa-client 4.8.6-1ubuntu2 Client install fails: * LANG=C /usr/sbin/ipa-client-install --domain cockpit.lan --realm COCKPIT.LAN --mkhomedir --enable-dns-updates --unattended --force-join --principal admin -W --force-ntpd Option --fo

[Freeipa] [Bug 1890786] [NEW] ipa-client-install fails on restarting non-existing chronyd.service

Public bug reported: DistroRelease: Ubuntu 20.10 Package: freeipa-client 4.8.6-1ubuntu2 Client install fails: * LANG=C /usr/sbin/ipa-client-install --domain cockpit.lan --realm COCKPIT.LAN --mkhomedir --enable-dns-updates --unattended --force-join --principal admin -W --force-ntpd Option --fo

[Bug 1799095] Re: Firewalld nftables backend breaks networking of libvirt

This somehow does not affect Ubuntu 20.04 LTS, but it does affect the current "groovy" release again: # virsh net-start default error: Failed to start network default error: internal error: firewalld is set to use the nftables backend, but the required firewalld 'libvirt' zone is missing. Either

Bug#967030: ITP: cockpit-podman -- Cockpit component for Podman containers

Control: tag -1 pending I did the initial upload now, and created a VCS at the usual place: https://salsa.debian.org/debian/cockpit-podman Note that I did *not* push the release commit and tag yet, as there may still be changes during NEW review. Martin

Bug#967030: ITP: cockpit-podman -- Cockpit component for Podman containers

Control: tag -1 pending I did the initial upload now, and created a VCS at the usual place: https://salsa.debian.org/debian/cockpit-podman Note that I did *not* push the release commit and tag yet, as there may still be changes during NEW review. Martin

Bug#964858: Uploaded to unstable

Hello Reinhard, Reinhard Tartler [2020-08-03 13:04 -0400]: > I've uploaded 2.0.18 that I slated for experimental to unstable after some > light testing with the 2.0.4 common package, and it seems to work fine. Thanks, appreciated! Indeed I gave conmon 2.0.18 + podman 2.0.4 a thorough testing toda

Bug#967030: ITP: cockpit-podman -- Cockpit component for Podman containers

Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: cockpit-podman Version : 20 Upstream Author : Cockpit development team * URL : https://github.com/cockpit-project/cockpit-podman/ * License : LGPL-2.1+ Description : The Cockpit Web

Bug#967030: ITP: cockpit-podman -- Cockpit component for Podman containers

Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: cockpit-podman Version : 20 Upstream Author : Cockpit development team * URL : https://github.com/cockpit-project/cockpit-podman/ * License : LGPL-2.1+ Description : The Cockpit Web

Bug#964858: conmon: Please update to version 2.0.18

Hello all, Reinhard Tartler [2020-07-11 7:15 -0400]: > In the context of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964378, I took the > liberty of updating conmon to version 2.0.18 in salsa. The branch can be > found at: > > https://salsa.debian.org/podman-team/conmon/-/tree/experiment

Bug#966501: 2.0.3 REST API regression: Failed to parse parameters for /v1.12/libpod/events: unexpected end of JSON input

Hallo Reinhard, Reinhard Tartler [2020-07-31 6:42 -0400]: > Thank you for your bugreport. I looked into backporting the change and > checked in with my contact upstream. It turns out that this is not the only > issue with the REST interface, and neither of them are easy to backport to > 2.0.3. A

[Touch-packages] [Bug 1831467] Re: test-umockdev tests flaky on armhf (and sometimes other archs)

https://salsa.debian.org/debian/umockdev/-/commit/87b476aee2 should hopefully help. I uploaded 0.14.2 to Debian unstable now, it should auto-sync into Groovy soon. Thanks Dan for tackling this! ** Changed in: umockdev (Ubuntu Groovy) Status: In Progress => Fix Committed -- You received t

[Bug 1831467] Re: test-umockdev tests flaky on armhf (and sometimes other archs)

https://salsa.debian.org/debian/umockdev/-/commit/87b476aee2 should hopefully help. I uploaded 0.14.2 to Debian unstable now, it should auto-sync into Groovy soon. Thanks Dan for tackling this! ** Changed in: umockdev (Ubuntu Groovy) Status: In Progress => Fix Committed -- You received t

Bug#914840: umockdev FTBFS on hppa architecture

Version: 0.13-1 Helge Deller [2018-11-27 21:40 +0100]: > umockdev fails to build quite often on the hppa architecture, as can be seen > here: > https://buildd.debian.org/status/logs.php?pkg=umockdev&arch=hppa > > I did some testing, and I think it fails because of timing issues. > Attached trivi

Bug#966501: 2.0.3 REST API regression: Failed to parse parameters for /v1.12/libpod/events: unexpected end of JSON input

Package: podman Version: 2.0.3+dfsg1-1 Severity: serious Tags: upsteam fixed-upstream Version 2.0.3 breaks the REST API really hard, which breaks cockpit-podman and any other API user. This is tracked here: https://github.com/containers/podman/issues/7078 This has been fixed upstream and will

Bug#966501: 2.0.3 REST API regression: Failed to parse parameters for /v1.12/libpod/events: unexpected end of JSON input

Package: podman Version: 2.0.3+dfsg1-1 Severity: serious Tags: upsteam fixed-upstream Version 2.0.3 breaks the REST API really hard, which breaks cockpit-podman and any other API user. This is tracked here: https://github.com/containers/podman/issues/7078 This has been fixed upstream and will

Re: Inaccessible buster cloud images

Hello Noah, Noah Meyerhans [2020-07-27 9:05 -0700]: > Future images should be generated with correct permissions. Confirmed, today's image works again. Many thanks! 👍 Martin

Inaccessible buster cloud images

Hello all, Recent directories in https://cloud.debian.org/images/cloud/buster/daily/ became inaccessible. E.g. https://cloud.debian.org/images/cloud/buster/daily/20200717-330/ still works, but https://cloud.debian.org/images/cloud/buster/daily/20200718-331/ and all subsequent ones give a 403.

Bug#966118: Package is missing REST systemd units

Package: podman Version: 2.0.2+dfsg1-3 Hello, first of all, many thanks for packaging podman in Debian! I was looking forward to this. I'm currently trying to make cockpit-podman work on Debian, and noticed a packaging bug. podman 2.0 still ships the /lib/systemd/system/io.podman.{socket,service

How to launch and re-attach to a long running process in Cockpit [was: Re: Suggestion for changing cockpit default session timeout]

Hello all, Yedidyah Bar David [2020-04-01 10:22 +0300]: > > The suggested 2h is just too much. The engine-setup process > > should not depend on cockpit session being around. It needs to run > > even when you log out of Cockpit and the user should be able to see > > the running process output when

Importing base1/patternfly.css is deprecated

Hello Cockpit developers, for many years, Cockpit related projects used to do this in their top-level HTML: This was also an officially documented API, formerly at [1]. The intention (most probably) was that CSS tweaks applied to Cockpit itself would also directly apply to all projects that

Cockpit 222 released

here: https://github.com/cockpit-project/cockpit/releases/tag/222 Take care, Martin Pitt ___ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org Fedora Code of

Cockpit 221 released

27be8c Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/221 Take care, Martin Pitt signature.asc Description: PGP signature ___ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send a

Re: Questions regarding addition of our own Cockpit module

Hello Dinesh, Dinesh Prasanth Moluguwan Krishnamoorthy [2020-06-03 20:17 -0400]: > I’m part of Dogtag PKI open-source project [1]. Our team strives to provide > enterprise-class open-source Public Key Infrastructure (PKI) [2]. FTR, Simon Kobyda (CCed) is working on a Cockpit page for managing cer

Impending change for developers: $TEST_DATA is going away, better default image caching

Hello fellow Cockpit developers, Cockpit's test machinery currently supports an environment variable `$TEST_DATA` which on the developer side is commonly used to put downloaded VM images into a specific path. If you don't specify it (nor the cockpit.bots.images-data-dir git config variable), then

Bug#961574: QEMU 5.0 x86_64 regression: Could not allocate dynamic translator buffer

moreinfo unreproducible > > > > 26.05.2020 11:27, Martin Pitt wrote: > >> But with 5.0, not any more: > >> > >> | $ admin@debian:~$ qemu-system-x86_64 -nographic > >> | Could not allocate dynamic translator buffer > > > > This is something..

Bug#961574: QEMU 5.0 x86_64 regression: Could not allocate dynamic translator buffer

Hello Michael, Michael Tokarev [2020-05-26 12:10 +0300]: > > | $ admin@debian:~$ qemu-system-x86_64 -nographic > > | Could not allocate dynamic translator buffer > > This is something.. wrong. Heh, yes -- it also doesn't have much Google juice; there are some existing bugzilla.redhat.com reports

Bug#961574: QEMU 5.0 x86_64 regression: Could not allocate dynamic translator buffer

Martin Pitt [2020-05-26 10:27 +0200]: > libvirt version did not change (6.0.0-6), but QEMU updated from 4.2 to 5.0. > I'll send a bug against libvirt Sent as https://bugs.debian.org/961575

Bug#961575: Regression with QEMU 5.0: Host does not support any virtualization options

Package: libvirt-daemon-driver-qemu Version: 6.0.0-6 In our latest Cockpit CI image refresh of debian-testing [1], all libvirt/QEMU tests are broken: | > warning: error: failed to get emulator capabilities | error: invalid argument: unable to find any emulator to serve 'x86_64' architecture | ER

Bug#961574: QEMU 5.0 x86_64 regression: Could not allocate dynamic translator buffer

Package: qemu-system-x86 Version: 1:5.0-5 In our latest Cockpit CI image refresh of debian-testing [1], all libvirt/QEMU tests are broken: | > warning: error: failed to get emulator capabilities | error: invalid argument: unable to find any emulator to serve 'x86_64' architecture | ERRORHost

Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"

Control: retitle -1 FTBFS on IPv6-only hosts Control: found -1 188-1 Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/14098 Control: tag -1 patch upstream Hello Aurelien, Aurelien Jarno [2020-05-16 19:27 +0200]: > This is an IPv6 host only, Ah! This explains the issue indeed

Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"

Control: retitle -1 FTBFS on IPv6-only hosts Control: found -1 188-1 Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/14098 Control: tag -1 patch upstream Hello Aurelien, Aurelien Jarno [2020-05-16 19:27 +0200]: > This is an IPv6 host only, Ah! This explains the issue indeed

[Pkg-utopia-maintainers] Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"

Control: retitle -1 FTBFS on IPv6-only hosts Control: found -1 188-1 Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/14098 Control: tag -1 patch upstream Hello Aurelien, Aurelien Jarno [2020-05-16 19:27 +0200]: > This is an IPv6 host only, Ah! This explains the issue indeed

Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"

Michael Biebl [2020-05-16 12:39 +0200]: > Source: cockpit > Version: 219-1 > Severity: serious > > Hi Martin, > > looks like the latest release reliably triggers a FTBFS on arch-all: > > https://buildd.debian.org/status/logs.php?pkg=cockpit&ver=219-1&arch=all > > The relevant part from the buil

[Pkg-utopia-maintainers] Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"

Michael Biebl [2020-05-16 12:39 +0200]: > Source: cockpit > Version: 219-1 > Severity: serious > > Hi Martin, > > looks like the latest release reliably triggers a FTBFS on arch-all: > > https://buildd.debian.org/status/logs.php?pkg=cockpit&ver=219-1&arch=all > > The relevant part from the buil

Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"

Michael Biebl [2020-05-16 12:39 +0200]: > Source: cockpit > Version: 219-1 > Severity: serious > > Hi Martin, > > looks like the latest release reliably triggers a FTBFS on arch-all: > > https://buildd.debian.org/status/logs.php?pkg=cockpit&ver=219-1&arch=all > > The relevant part from the buil

Re: Cockpit on smaller sysems (OpenWRT, QNAP, and other embedded Linux systems)

Hello Bernd, Bernd Wechner [2020-05-14 7:34 -]: > That set does include an OpenWRT router and a QNAP NAS, both of which are > smaller stripped down embedded Linux systems if you will which use the opkg > package manager: > > https://en.wikipedia.org/wiki/Opkg There are no cockpit opkgs av

Re: Installing the latest version

Hello Bernd, Bernd Wechner [2020-05-14 7:25 -]: > I just installed an Ubuntu 20.04 server. Then cockipt. And it looked way > different to what I have elsewhere. So I checked versions. And sure enough on > Ubuntu 20.04 we ghave: > > Version: 215-1 Right, that's the version from Ubuntu 20.0

<    1   2   3   4   5   6   7   8   9   10   >