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

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,

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,

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

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

[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

[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

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

[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

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},

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},

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:

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 |

[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 |

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 > t

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

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

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

[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 --

[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

[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

[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

[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

[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

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: > >

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

[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

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=hppa > > I did some testing, and I think it fails because of timing issues. > Attached trivial

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

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

Cockpit 221 released

9c0127be8c 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 sen

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

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

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 |

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 | ERROR

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

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

[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

[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=219-1=all > > The relevant part from the build log >

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=219-1=all > > The relevant part from the build log >

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=219-1=all > > The relevant part from the build log >

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

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

Re: Suggestion for changing cockpit default session timeout

Hello all, Martin Pitt [2020-04-02 13:06 +0200]: > I'm actually mildly in favor of keeping the locking by default, but if there > is > good arguments to *not* lock by default, I can certainly be convinced. As I > said, I'd first like to circle back with Steve whether not lockin

Cockpit 218 and cockpit-podman 16 released

in Fedora 31 and 32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-118ad70fc7 https://bodhi.fedoraproject.org/updates/FEDORA-2020-472a8d70ba Or download the tarball here: https://github.com/cockpit-project/cockpit-podman/releases/tag/16 Take care, Martin Pitt signature.asc

[Bug 1875028] Re: Package cockpit-docker cannot be found

Right, this is intended, we stopped supporting cockpit-docker upstream: https://cockpit-project.org/blog/cockpit-215.html The older package still works for the time being, if you install it manually. ** Changed in: cockpit (Ubuntu) Status: New => Won't Fix -- You received this bug

Bug#956550: src:umockdev: fails to migrate to testing for too long

Hello Paul, Paul Gevers [2020-04-12 20:35 +0200]: > As recently announced [1], the Release Team now considers packages that > are out-of-sync between testing and unstable for more than 60 days as > having a Release Critical bug in testing. Your package src:umockdev in > its current version in

Bug#956550: src:umockdev: fails to migrate to testing for too long

Hello Paul, Paul Gevers [2020-04-12 20:35 +0200]: > As recently announced [1], the Release Team now considers packages that > are out-of-sync between testing and unstable for more than 60 days as > having a Release Critical bug in testing. Your package src:umockdev in > its current version in

Re: Cockpit 215

Hello Paul, Paul Bovbel [2020-04-06 13:37 -0400]: > Is libpod and cockpit-podman going to be available in Ubuntu 20.04? It > would be a shame to have neither cockpit-docker nor cockpit-podman > available in an LTS release. They are not available right now, there's an effort to package it for

Re: Cockpit on windows

Hello Jonathan, Jonathan Aquilina [2020-04-07 5:25 +]: > There is a bit of a misunderstanding. Is it possible to run cockpit on a > windows machine on IIS to admin linux machines? Theoretically, it may be possible to reengineer the build system to build *just* cockpit-ws (the web server

Re: Cockpit on windows

Hello Jonathan, Jonathan Aquilina [2020-04-07 4:54 +]: > Is cockpit going to be brought to windows? If not are there plans to release > it to be run for windows? Cockpit is strictly a tool to administer a *Linux* server. It is absolutely not portable to run on or administer a Windows

Re: Suggestion for changing cockpit default session timeout

Hello all, Stef Walter [2020-04-02 12:54 +0200]: > > It doesn't, and we can certainly discuss whether to enable it by default. I > > will circle back to Steve and check that requirement. > > Hmmm. I don't understand why we would do that. > > The security exectation is that any UI (such as GNOME

Re: Suggestion for changing cockpit default session timeout

Hello Yedidyah, Yedidyah Bar David [2020-04-01 10:22 +0300]: > I think that the gdm case is different. There, you lock the session, > not logout. Right? If so, after re-entering the password, the admin > has everything back there. Correct. That should also be the case for cockpit, as pages

Re: Q to all candidates: NEW queue

Lucas Nussbaum [2020-03-26 14:58 +0100]: > - package is uploaded > - package gets accepted in unstable > - package gets reviewed, a bug is filed > - bug gets fixed > > Except that with (B), we avoid the wait in NEW. > > One important question is: how often does the FTP team run into a > package

Re: Development configuration for Cockpit Plugin

Hello Gal, Gal Zaidman [2020-03-18 17:38 +0200]: > I think that you have miss understood my intention, I aim to create a > separate development environment which will use webpack-dev-server. > I don't want to login with cockpit UI, > I want the that the js will be served by webpack-dev-server and

Re: Development configuration for Cockpit Plugin

Hello Gal, Gal Zaidman [2020-03-17 13:43 +0200]: > On my local env I installed cockpit and cloned the starter-kit, created > a link to base1 directory What do you mean by that? You don't need to create any links for base1 yourself. Cockpit's web server (cockpit-ws) knows how to find base1. > My

cockpit 214, cockpit-composer 13, cockpit-podman 14, cockpit-ostree 181 released

-composer/releases/tag/13 Fedora 31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9af64ea53a Fedora 32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8dc7c99f00 Take care, Martin Pitt signature.asc Description: PGP signature

[Bug 1802005] Re: socket is inaccessible for libvirt-dbus

@Christian: Wontfix WFM, I'm glad that the default works in focal (the next LTS). For the non-LTS ones it can be worked around (write a systemd unit drop-in or so), but apparently it's not such a big issue. Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs,

[Bug 1802005] Re: socket is inaccessible for libvirt-dbus

Nice, thanks Christian! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1802005 Title: socket is inaccessible for libvirt-dbus To manage notifications about this bug go to:

[Bug 1802005] Re: D-Bus socket is inaccessible

The socket is actually owned by libvirt ** Package changed: libvirt-dbus (Ubuntu) => libvirt (Ubuntu) ** Summary changed: - D-Bus socket is inaccessible + socket is inaccessible for libvirt-dbus -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed

Bug#951477: xtables-nft-multi crashes in nftnl_rule_lookup_byindex()

Package: iptables Version: 1.8.4-3 In our cockpit CI tests on debian-testing I noticed an awful lot of tests that fail due to an iptables crash. (The tests themselves are fine, but we fail tests on unexpected journal messages, such as this one). coredumpctl shows the following meta-info:

Re: PSA: New server for test log files

Hello again, Martin Pitt [2020-02-14 12:19 +0100]: > So I set up an instance in AWS instead, which is now our new log sink: > <https://54.89.13.31/>. The first time you open a log, you will get a cert > validation error. Unfortunately AWS doesn't support setting up DNS names (o

PSA: New server for test log files

Hello all, until today, most of our test logs went to , an OpenStack instance in fedorainfracloud.org. However this cloud will shut down at the end of the month, so I set up an alternative. Initially, I thought that we could just log everything to , but unfortunately

Bug#951114: umockdev fails autopkg test with stderr output

Control: tag -1 fixed-upstream pending Hello Matthias, Matthias Klose [2020-02-11 11:45 +0100]: > autopkgtest [17:12:07]: test upstream: ---] > autopkgtest [17:12:07]: test upstream: - - - - - - - - - - results - - - - - > - > - - - - > upstream FAIL stderr: >

Bug#951114: umockdev fails autopkg test with stderr output

Control: tag -1 fixed-upstream pending Hello Matthias, Matthias Klose [2020-02-11 11:45 +0100]: > autopkgtest [17:12:07]: test upstream: ---] > autopkgtest [17:12:07]: test upstream: - - - - - - - - - - results - - - - - > - > - - - - > upstream FAIL stderr: >

[Pkg-utopia-maintainers] Bug#949595: cockpit: Please include patch to fix build on sparc64

Control: tag -1 fixed-upstream pending Hello Adrian, John Paul Adrian Glaubitz [2020-01-22 16:40 +0100]: > cockpit FTBFS on sparc64 due to unaligned access. The attached package fixes > it. I have also forwarded the issue upstream [1]. Thanks a lot Adrian for tracking this down! The fix landed

Bug#949595: cockpit: Please include patch to fix build on sparc64

Control: tag -1 fixed-upstream pending Hello Adrian, John Paul Adrian Glaubitz [2020-01-22 16:40 +0100]: > cockpit FTBFS on sparc64 due to unaligned access. The attached package fixes > it. I have also forwarded the issue upstream [1]. Thanks a lot Adrian for tracking this down! The fix landed

Accepted cockpit 211-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 22 Jan 2020 21:45:31 + Source: cockpit Architecture: source Version: 211-1 Distribution: unstable Urgency: medium Maintainer: Utopia Maintenance Team Changed-By: Martin Pitt Changes: cockpit (211-1) unstable; urgency

Accepted python-dbusmock 0.19-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 Jan 2020 20:36:10 + Source: python-dbusmock Architecture: source Version: 0.19-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Martin Pitt Closes: 946098 947712 Changes

Accepted cockpit 210-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Jan 2020 22:30:01 + Source: cockpit Architecture: source Version: 210-1 Distribution: unstable Urgency: medium Maintainer: Utopia Maintenance Team Changed-By: Martin Pitt Changes: cockpit (210-1) unstable; urgency

Bug#947712: autopkgtest regressions in python-dbusmock with newer network-manager 1.22.2-1

Hello Michael and Thomas, Michael Biebl [2020-01-08 19:42 +0100]: > > The latest update of network-manager causes an autopkgtest regression in > > python-dbusmock. > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/3793816/log.gz > > > >

[Python-modules-team] Bug#947712: autopkgtest regressions in python-dbusmock with newer network-manager 1.22.2-1

Hello Michael and Thomas, Michael Biebl [2020-01-08 19:42 +0100]: > > The latest update of network-manager causes an autopkgtest regression in > > python-dbusmock. > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/3793816/log.gz > > > >

[Pkg-utopia-maintainers] Bug#947712: autopkgtest regressions in python-dbusmock with newer network-manager 1.22.2-1

Hello Michael and Thomas, Michael Biebl [2020-01-08 19:42 +0100]: > > The latest update of network-manager causes an autopkgtest regression in > > python-dbusmock. > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/3793816/log.gz > > > >

Bug#947712: autopkgtest regressions in python-dbusmock with newer network-manager 1.22.2-1

Hello Michael and Thomas, Michael Biebl [2020-01-08 19:42 +0100]: > > The latest update of network-manager causes an autopkgtest regression in > > python-dbusmock. > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/3793816/log.gz > > > >

Accepted pcp 5.0.2-1.1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 04 Jan 2020 09:58:40 + Source: pcp Architecture: source Version: 5.0.2-1.1 Distribution: unstable Urgency: medium Maintainer: PCP Development Team Changed-By: Martin Pitt Closes: 947916 Changes: pcp (5.0.2-1.1) unstable

Bug#947916: [pcp] Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

Hello Nathan, Nathan Scott [2020-01-07 11:18 +1100]: > Thanks for looking into this issue while we were all off, Martin and Sunil! > > To summarise where I understand things are at now: Martin's uploaded > a pcp package for rebuild which drops the python2 build steps. I think > this is fine and

Bug#947916: [pcp] Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

Hello Nathan, Nathan Scott [2020-01-07 11:18 +1100]: > Thanks for looking into this issue while we were all off, Martin and Sunil! > > To summarise where I understand things are at now: Martin's uploaded > a pcp package for rebuild which drops the python2 build steps. I think > this is fine and

Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

Control: tag -1 pending Hello again, Martin Pitt [2020-01-05 10:54 +0100]: > > I ran into similar issue when attempting to build with multiple parallel > > tasks with DEB_BUILD_OPTIONS=parallel=8 or with -j8. If you have this > > turned on, please try disabling it. > >

Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

Control: tag -1 pending Hello again, Martin Pitt [2020-01-05 10:54 +0100]: > > I ran into similar issue when attempting to build with multiple parallel > > tasks with DEB_BUILD_OPTIONS=parallel=8 or with -j8. If you have this > > turned on, please try disabling it. > >

Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

Hello Sunil, Sunil Mohan Adapa [2020-01-04 12:15 -0800]: > > This file doesn't exist anywhere -- apparently src/include/builddefs.install > > builds it, but at this point this is pretty deeply woven into the build > > system. > > Curiously, resuming the build with "make" and "dpkg-buildpackage

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