Bug#748120: Improper device checking with virt-clone on LVM
Package: virtinst
Version: 0.600.1-3+deb7u1
Severity: normal
Tags: patch
Cloning into existing storage volumes is supposedly not supported.
#706196 marks this as a regression and #745873 as a wishlist item. In
old-stable it worked, so I feel that calling it a regression is correct.
When looking at what spit out this error, it seemed to me that the check
is too simplistic and I can actually clone into existing storage
volumes, if referenced differently:
virsh pool-dumpxml vg01
vg01
2ae3ae6c-7aa0-f7db-f771-183406d653ee
560598089728
157655498752
402942590976
vg01
/dev/vg01
0700
4294967295
4294967295
root@cheetah:/tmp/tmp.oCzq69YIdx# virt-clone -o leap-baseimage -f
/dev/vg01/review-root -n test
ERRORClone onto existing storage volume is not supported:
'/dev/vg01/review-root'
root@cheetah:/tmp/tmp.oCzq69YIdx# virt-clone -o leap-baseimage -f
/dev/mapper/vg01-review--root -n test
Cloning vg01-leap--baseimage
| 10 GB 00:05
Clone 'test' created successfully.
I liked that success, but in both cases it was actually writing to the
same place:
root@cheetah:/usr/share/pyshared/virtinst# readlink
/dev/mapper/vg01-review--root
../dm-0
root@cheetah:/usr/share/pyshared/virtinst# readlink /dev/vg01/review-root
../dm-0
Why this happens? The answer is in CloneManager.py:
474 if clone_disk.vol_object:
475 # XXX We could do this with vol upload I think
476 raise RuntimeError(
477 _("Clone onto existing storage volume is not "
478 "supported: '%s'") % clone_disk.path)
For both me and #706196 this is sort of fixed upstream when it are local
storage pools:
https://git.fedorahosted.org/cgit/virt-manager.git/tree/virtinst/CloneManager.py?id=v0.10.0
Virt-inst is now merged in virt-manager. With attached patch (which
comes from upstream) I'm happy. I don't know if this patch should get
into backports or the other 2 bugs can be closed because of this and/or
upstream changes, an explanation of bug-flow would be welcome.
-- System Information:
Debian Release: 7.5
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages virtinst depends on:
ii python 2.7.3-4+deb7u1
ii python-libvirt 0.9.12.3-1
ii python-libxml2 2.8.0+dfsg1-7+nmu3
ii python-support 1.0.15
ii python-urlgrabber 3.9.1-4
Versions of packages virtinst recommends:
ii qemu 1.1.2+dfsg-6a+deb7u2
ii virt-viewer 0.5.3-1
virtinst suggests no packages.
-- no debconf information
474,475c474,487
< if clone_disk.vol_object:
< # XXX We could do this with vol upload I think
---
> if clone_disk.vol_object:
> # XXX We could always do this with vol upload?
>
> # Special case: non remote cloning of a guest using
> # managed block devices: fall back to local cloning if
> # we have permissions to do so. This validation check
> # caused a few bug reports in a short period of time,
> # so must be a common case.
> if (clone_disk.is_remote() or
> clone_disk.type != clone_disk.TYPE_BLOCK or
> not orig_disk.path or
> not os.access(orig_disk.path, os.R_OK) or
> not clone_disk.path or
> not os.access(clone_disk.path, os.W_OK)):
478c490
< "supported: '%s'") % clone_disk.path)
---
> "currently supported: '%s'") % clone_disk.path)
Bug#698783: Trust checking always happens even for --(hidden-)encrypt-to
Package: gnupg Version: 1.4.12-7 Severity: normal The manpage describes for both --hidden-encrypt-to and --encrypt-to 'No trust checking is performed for these user ids and even disabled keys can be used.' I tried to use this functionality with both an expired and a revoked key and with both this doesn't seem to be possible, using the --expert option for doing 'certain nonsensical or "silly" things' doesn't make any difference, get the following output: gpg: keyid: skipped: unusable public key gpg: foo.txt: encryption failed: unusable public key I see a couple of possibilities here: I'm misunderstanding what trust checking entails, the manpage isn't explicit enough that the only thing it won't check is the trustdb, or the tool is following the relevant RFCs more strict as the manpage. I think -but am unsure- that the manpage should be more explicit and add a phrase like: Expired and revoked keys can't be used. Another possibility would be aligning the software to the manpage, something which I'd prefer but can't help with. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnupg depends on: ii dpkg 1.16.9 ii gpgv 1.4.12-7 ii install-info 4.13a.dfsg.1-10 ii libbz2-1.01.0.6-4 ii libc6 2.13-37 ii libreadline6 6.2-8 ii libusb-0.1-4 2:0.1.12-20+nmu1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages gnupg recommends: ii gnupg-curl 1.4.12-7 ii libldap-2.4-2 2.4.31-1 Versions of packages gnupg suggests: ii eog 3.4.2-1+build1 pn gnupg-doc ii imagemagick 8:6.7.7.10-5 ii libpcsclite1 1.8.4-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697864: virtinst: Locale shouldn't be blocking virt-clone
Package: virtinst Version: 0.500.3-2 Severity: normal Virt-clone fails if not every single locale environment variable present is supported. A fairly normal use case is someone logging in remotely and having her local environment variables in use remotely as well. Setting something like LC_TELEPHONE=hy_AM UTF-8 should be treated as irrelevant for virt-clone. The generated traceback could probably be a warning and/or made more useful. Traceback (most recent call last): File "/usr/bin/virt-clone", line 33, in cli.setupGettext() File "/usr/lib/pymodules/python2.6/virtinst/cli.py", line 133, in setupGettext locale.setlocale(locale.LC_ALL, '') File "/usr/lib/python2.6/locale.py", line 513, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable'), (2, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages virtinst depends on: ii python 2.6.6-3+squeeze7 interactive high-level object-orie ii python-libvirt 0.8.3-5+squeeze2 libvirt Python bindings ii python-libxml2 2.7.8.dfsg-2+squeeze6 Python bindings for the GNOME XML ii python-support 1.0.10automated rebuilding support for P ii python-urlgrabber 3.9.1-4 A high-level cross-protocol url-gr Versions of packages virtinst recommends: pn qemu (no description available) ii virt-viewer 0.2.1-1Displaying the graphical console o virtinst suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702563: (no subject)
tags: wheezy, fixed-in-experimental Hello, In #702933 intrigeri asked me to test/confirm if 0.6.20-3 fixes #702563. So I went ahead and installed the package from Sid on a Wheezy box and it worked fine (apt-get install duplicity/sid). However a little upgrade note that --ssh-options *only* accepts an IdentityFile is probably still necesary. Something like this won't work (presuming the different port there and no ~/.ssh/config being present): Debug: duplicity --no-print-statistics --ssh-options '-o Port=4422 -o=IdentityFile=/root/.ssh/id_rsa' --encrypt-key... If you specify the port in your ~/.ssh/config it will work as expected. Other notes on that pacakage: * it removes the requirement of python-gnupginterface * it requires following extra pacakges: python-httplib2 python-oauth Intrigeri and/or maintainer(s): not sure about tags and bugs. Feel free to educate and correct me. Ciao, kwadronaut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699377: Wheezy version generates needless gio warnings
Package: duplicity Version: 0.6.18-3 Severity: normal Dear maintainers, The version currently in Wheezy contains needless warnings that were fixed before the freeze. If you don't use (and haven't installed) the gio backend you get useless cruft in log messages and whenever you use duplicity: "Import of duplicity.backends.giobackend Failed: No module named gio" This was introduced in 0.6.18 (Wheezy version) and resolved in 0.6.19. Current stable (Squeeze) and Sid don't have this bug. Ideally I'd like to get 0.6.21 (because of more fix galore) from upstream in Sid and Squeeze but understand that we're in a deep freeze. I'm curious how to deal with this. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages duplicity depends on: ii libc6 2.13-37 ii librsync1 0.9.7-9 ii python 2.7.3~rc2-1 ii python-gnupginterface 0.3.2-9.1 Versions of packages duplicity recommends: ii python-paramiko 1.7.7.1-3.1 ii rsync3.0.9-4 Versions of packages duplicity suggests: pn lftp pn ncftp ii python-boto2.3.0-1 pn python-cloudfiles pn python-gdata pn python-pexpect pn tahoe-lafs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702382: Debian can't, handle default nobootwait, missing default template values
Package: cloud-init Version: 0.7.1-3 File: /usr/lib/python2.7/dist-packages/cloudinit/config/cc_mounts.py Severity: normal Dear Maintainer, Given the default of nobootwait in fstab, caused by the upstream cc_mounts.py, this should be overridden in the default Debian template in /etc/cloud.cfg with a setting like: mount_default_fields: [ None, None, "auto", "defaults,nofail", "0", "2" ] If you think that this bug is inapropriate or incorrect, I'd love to be pointed to a manpage where I can read up on this. (Mind the MUA that thinks that lines shouldn't be longer as 80 characters wide) -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cloud-init depends on: ii debconf [debconf-2.0] 1.5.49 ii ifupdown 0.7.5 ii lsb-base 4.1+Debian8 ii procps 1:3.3.3-2 ii python 2.7.3-4 ii python-boto 2.3.0-1 ii python-cheetah 2.4.4-3 ii python-configobj 4.7.2+ds-4 ii python-oauth 1.0.1-3 ii python-prettytable 0.6.1-1 ii python-software-properties 0.82.7.1debian1 ii python-yaml 3.10-4 ii python2.7 [python-argparse] 2.7.3-6 cloud-init recommends no packages. cloud-init suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714200: openssh-server: dpkg-reconfigure openssh-server doesn't create ecdsa host
Package: openssh-server Version: 1:6.0p1-4 Severity: normal Dear Maintainer, When (re-)creating host keys for a system by using dpkg-reconfigure openssh-server, the ECDSA host keys are not created. How to reproduce: * install a system with openssh-server $ rm /etc/ssh/ssh_host_* $ dpkg-reconfigre openssh-server Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... Restarting OpenBSD Secure Shell server: sshd. root@wallaby:/etc/ssh# Expected behavior: $ dpkg-reconfigre openssh-server Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... Creating SSH2 ECDSA key; this won't take as much time … -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openssh-server depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.10 ii libc6 2.13-38 ii libcomerr2 1.42.5-1.1 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u1 ii libkrb5-3 1.10.1+dfsg-5+deb7u1 ii libpam-modules 1.1.3-7.1 ii libpam-runtime 1.1.3-7.1 ii libpam0g 1.1.3-7.1 ii libselinux12.1.9-5 ii libssl1.0.01.0.1e-2 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian8+deb7u1 ii openssh-client 1:6.0p1-4 ii procps 1:3.3.3-3 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages openssh-server recommends: ii ncurses-term 5.9-10 ii openssh-blacklist0.4.1+nmu1 ii openssh-blacklist-extra 0.4.1+nmu1 ii xauth1:1.0.7-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- debconf information: * ssh/use_old_init_script: true ssh/vulnerable_host_keys: ssh/encrypted_host_key_but_no_keygen: ssh/disable_cr_auth: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668208: lynx: Support for TLS server name indication (http, ftp)
Package: lynx Version: 2.8.8dev.5-1 Severity: important I'd very much appreciate support in lynx to use TLS extension for Server Name Indication. Most graphical browsers I use support it. Have a look at https://sni.velox.ch : lynx apparently doesn't send the server name when saying ClientHello. See RFC 4366. -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages lynx depends on: ii lynx-cur2.8.8dev.5-1 Text-mode WWW Browser with NLS sup lynx recommends no packages. lynx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#862829: ganeti: Broken homepage url on packages
Source: ganeti Severity: normal Dear Maintainers, The link to the 'homepage' of ganeti has moved. Both https://packages.qa.debian.org/g/ganeti.html and https://tracker.debian.org/pkg/ganeti point to https://code.google.com/p/ganeti/ but should point to http://www.ganeti.org/ or alternatively https://github.com/ganeti/ganeti Thanks,
Bug#760140: Can only sign all uids and not single ones
On 26/11/14 06:02, Antoine Beaupré wrote: > On 2014-08-31 05:38:51, kwadronaut wrote: >> Package: monkeysign >> Version: 1.1~bpo70+1 >> Severity: important >> >> Can only sign all uids of a key and not single ones. I'm using >> monkeysign from backports on Debian Stable. >> >> $ monkeysign -dv -u BD68C7AA997FA77F -v --local myfriendskeyAABBCC > > please try the latest version again from sid, or the one from git. I've gotten the 2.x branch from git, ran the setup. > > notice how #771034 may be related. there seems to be an off by one error > in the selection code and a one-line patch fix. > > the git repository has the fix and you can run monkeysign straight from > the git repository (even with monkeysign installed system-wide). It is fixed indeed, worked flawless. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#809249: debian-security-support: Missing help
Package: debian-security-support Version: 2015.04.04 Severity: wishlist Dear Maintainer, the release notes suggest to track security support status of installed packages with debian-security-support [1]. It's not obvious after installation on how to re-run it or what can be expected from this package. I suggest to: * include a --help switch * a reference to the package name inside the manpage of check-support-status so when searching (man -k debian-security-support) one can find some more information Thanks, kwadronaut [1] https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#limited-security-support s -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debian-security-support depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii gettext-base 0.19.3-2 debian-security-support recommends no packages. debian-security-support suggests no packages. -- debconf information excluded
Bug#864661: polipo: Discontinued request for removal
Source: polipo Severity: high Tags: upstream Dear Maintainer, This project has been discontinued, mostly because more and more web traffic is encrypted. I think it's inappropriate to keep it within Debian when upstream has declared the project dead and no-one takes it over. Besides, good reasons to abandon it. see: https://www.irif.fr/~jch/software/polipo/ https://sourceforge.net/p/polipo/mailman/message/35473110/ Regards, kwadronaut
Bug#861722: ruby-net-ssh: Please update ruby-net-ssh
Package: ruby-net-ssh Followup-For: Bug #861722 Dear Maintainer, actually upgrading to 4.1 from upstream would be most welcome, that includes support for ed25519 keys. Unstable is still at 1:3.2.0-1. Thanks, kwadronaut
Bug#849109: apg: Warn users, fips181 retracted
Package: apg Version: 2.2.3.dfsg.1-4 Severity: important Dear Maintainer, This password generator, build upon a NIST-document from 1993 (which itself is based upon an older offline paper), should probably be reevaluated or contain a big fat warning, since the documents on which it's based are retracted by NIST because "are obsolete and are being withdrawn because they have not been updated to reference current or revised voluntary industry standards, federal specifications, or federal data standards." I don't know if there's anything wrong with the document or this algorithm within the password generator itself or if it's simply a fact of people not having paid a close look in recent years. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apg depends on: ii libc6 2.24-8 apg recommends no packages. apg suggests no packages. -- no debconf information
Bug#845168: bnd: Website url 404
Package: bnd Version: 2.4.1-6 Severity: normal Dear Maintainer, packages can have a website url defined, in this case it has, pointing to "Homepage: http://www.aQute.biz/Bnd"; However, trying to visit that page will result in a 404. Don't know if the package is abandoned or simple bitrot. Any updated website page around? Ciao, kwadronaut -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bnd depends on: ii default-jre-headless [java6-runtime-headless]2:1.8-57 ii java-wrappers0.1.28 ii libosgi-compendium-java 5.0.0-5 ii libosgi-core-java6.0.0-1 ii openjdk-8-jre-headless [java6-runtime-headless] 8u111-b14-3 Versions of packages bnd recommends: ii libbindex-java 2.2+svn101-3 Versions of packages bnd suggests: pn eclipse-jdt pn eclipse-rcp -- no debconf information
Bug#614987: location of the documentation error
I forgot to mention that the problem is located in the file /usr/share/doc/nginx-doc/fcgiwrap -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#888410: gnupg-pkcs11: Sync with upstream
Package: gnupg-pkcs11 Severity: important Dear Maintainer, PKCS#11 smart card library in unstable/testing/stable is from 2011 (0.7.3-4). The current upstream version (0.9.0) incorporates a lot of changes and fixes necessary to inter-operate with gnupg >=2.1.19. Would it be possible to get an update? According to the changelog, there are some steps to pay attention to, serial card number will change. See http://gnupg-pkcs11.sourceforge.net/changelog.html for details. Feel free to correct things like severity or add extra tags, apologies if I didn't do a proper job there. Thanks a lot, kwadronaut
Bug#877731: apt-secure: apt-secure doesn't know how to handle armored keyfiles
Package: apt Version: 1.4.7 Severity: normal Dear Maintainer, when adding an old-style armored key, apt fails to use this. If you dump such a keyfile inside etc/apt/trusted.gpg.d/ (or /usr/share/keyrings/name.gpg, with accompanying sources file) apt-update will choke because it thinks the public key isn't available. gpg --export -a --export-options export-minimal 1646B01B86E50310 >/usr/share/keyrings/yarn-keyring.gpg apt update W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E074D16EB6FF4DE3 W: Failed to fetch https://dl.yarnpkg.com/debian/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E074D16EB6FF4DE3 W: Some index files failed to download. They have been ignored, or old ones used instead. I think this should at least be more obvious in the manpage that a simple armored keyfile will not be taken into account and only keyrings matter. This works: gpg --export --export-options export-minimal 1646B01B86E50310 >/usr/share/keyrings/yarn-keyring.gpg -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (no /etc/apt/preferences.d/* present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- /etc/apt/sources.list.d/yarn.list -- deb [signed-by=/usr/share/keyrings/yarn-keyring.gpg] https://dl.yarnpkg.com/debian/ stable main -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages apt depends on: ii adduser 3.115 ii debian-archive-keyring 2017.5 ii gpgv2.1.18-6 ii init-system-helpers 1.48 ii libapt-pkg5.0 1.4.7 ii libc6 2.24-11+deb9u1 ii libgcc1 1:6.3.0-18 ii libstdc++6 6.3.0-18 Versions of packages apt recommends: ii gnupg 2.1.18-6 Versions of packages apt suggests: pn apt-doc pn aptitude | synaptic | wajig ii dpkg-dev 1.18.24 pn powermgmt-base pn python-apt -- no debconf information
Bug#833863: (no subject)
Behavior is identical in 10.1. What you could do, without rebooting: open another shell (ctrl-alt f2), luksClose the crypted volume, pgremove the physical volume group, then comes the scary part: add some amnesia to partman. I did a # mv /var/lib/partman/devices/=dev\=nvme0n1 /tmp/, went back to the installer and could re-do whatever I wanted to do.
Bug#944356: udev: fn keys for dim/brightness on ProBook g6 not recognised
Package: udev Version: 241-7~deb10u1 Severity: normal Dear Maintainer, typical laptop 'extra' keys aren't properly working, both dim and brighter buttons get registered identical as mic on/off. I've checked upstream's git changes: https://github.com/systemd/systemd/commits/master/hwdb/60-keyboard.hwdb (and they moved the file last month, checked there too). Latest Bios, using default Wayland/Gnome. sudo showkey -s kb mode was ?UNKNOWN? [ if you are trying this under X, it might not work since the X server is also reading /dev/console ] press any key (program terminates 10s after last keypress)... 0x9c 0x5a 0xda 0x5a 0xda 0x5a 0xda When doing this, nothing gets output, but gnome shows the mic on/off: sudo evtest /dev/input/event5 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0 Input device name: "HP WMI hotkeys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 138 (KEY_HELP) Event code 141 (KEY_SETUP) Event code 148 (KEY_PROG1) Event code 153 (KEY_DIRECTION) Event code 224 (KEY_BRIGHTNESSDOWN) Event code 225 (KEY_BRIGHTNESSUP) Event code 226 (KEY_MEDIA) Event code 240 (KEY_UNKNOWN) Event code 358 (KEY_INFO) Event type 4 (EV_MSC) Event code 4 (MSC_SCAN) Event type 5 (EV_SW) Properties: Testing ... (interrupt to exit) I've given it a try with Qubes on X instead of Wayland, tried without an X-server: all the same, not sure how to debug further. -- Package-specific info: -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages udev depends on: ii adduser 3.118 ii dpkg 1.19.7 ii libacl1 2.2.53-4 ii libblkid1 2.33.1-0.1 ii libc6 2.28-10 ii libkmod2 26-1 ii libselinux1 2.8-1+b1 ii libudev1 241-7~deb10u1 ii lsb-base 10.2019051400 ii systemd-sysv 241-7~deb10u1 ii util-linux2.33.1-0.1 udev recommends no packages. udev suggests no packages. Versions of packages udev is related to: ii systemd 241-7~deb10u1 -- no debconf information --===1917901444673350041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="udev-database.txt" I feel a bit violated that reportbug wants to add over 7000 lines of identifiable hardware. I'm happy to dig up and share *relevant* parts, please tell me. --===1917901444673350041==--
Bug#944356: (no subject)
Nothing in dmesg, /var/log/syslog, also not with journalctl -f. I already gave the (empty) output of evtest, here's when using the event0: I hit dim, brighter, mic off buttons, located at f3, f4 and f8. sudo evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: AT Translated Set 2 keyboard /dev/input/event1: Sleep Button /dev/input/event2: Lid Switch /dev/input/event3: Power Button /dev/input/event4: Video Bus /dev/input/event5: SynPS/2 Synaptics TouchPad /dev/input/event6: PC Speaker /dev/input/event7: HP WMI hotkeys /dev/input/event8: HP HD Camera: HP HD Camera /dev/input/event9: HDA Intel PCH Mic /dev/input/event10: HDA Intel PCH Headphone /dev/input/event11: HDA Intel PCH HDMI/DP,pcm=3 /dev/input/event12: HDA Intel PCH HDMI/DP,pcm=7 /dev/input/event13: HDA Intel PCH HDMI/DP,pcm=8 /dev/input/event14: HDA Intel PCH HDMI/DP,pcm=9 /dev/input/event15: HDA Intel PCH HDMI/DP,pcm=10 /dev/input/event16: ST LIS3LV02DL Accelerometer Select the device event number [0-16]: 0 Input driver version is 1.0.1 Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab41 Input device name: "AT Translated Set 2 keyboard" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 1 (KEY_ESC) Event code 2 (KEY_1) Event code 3 (KEY_2) Event code 4 (KEY_3) Event code 5 (KEY_4) Event code 6 (KEY_5) Event code 7 (KEY_6) Event code 8 (KEY_7) Event code 9 (KEY_8) Event code 10 (KEY_9) Event code 11 (KEY_0) Event code 12 (KEY_MINUS) Event code 13 (KEY_EQUAL) Event code 14 (KEY_BACKSPACE) Event code 15 (KEY_TAB) Event code 16 (KEY_Q) Event code 17 (KEY_W) Event code 18 (KEY_E) Event code 19 (KEY_R) Event code 20 (KEY_T) Event code 21 (KEY_Y) Event code 22 (KEY_U) Event code 23 (KEY_I) Event code 24 (KEY_O) Event code 25 (KEY_P) Event code 26 (KEY_LEFTBRACE) Event code 27 (KEY_RIGHTBRACE) Event code 28 (KEY_ENTER) Event code 29 (KEY_LEFTCTRL) Event code 30 (KEY_A) Event code 31 (KEY_S) Event code 32 (KEY_D) Event code 33 (KEY_F) Event code 34 (KEY_G) Event code 35 (KEY_H) Event code 36 (KEY_J) Event code 37 (KEY_K) Event code 38 (KEY_L) Event code 39 (KEY_SEMICOLON) Event code 40 (KEY_APOSTROPHE) Event code 41 (KEY_GRAVE) Event code 42 (KEY_LEFTSHIFT) Event code 43 (KEY_BACKSLASH) Event code 44 (KEY_Z) Event code 45 (KEY_X) Event code 46 (KEY_C) Event code 47 (KEY_V) Event code 48 (KEY_B) Event code 49 (KEY_N) Event code 50 (KEY_M) Event code 51 (KEY_COMMA) Event code 52 (KEY_DOT) Event code 53 (KEY_SLASH) Event code 54 (KEY_RIGHTSHIFT) Event code 55 (KEY_KPASTERISK) Event code 56 (KEY_LEFTALT) Event code 57 (KEY_SPACE) Event code 58 (KEY_CAPSLOCK) Event code 59 (KEY_F1) Event code 60 (KEY_F2) Event code 61 (KEY_F3) Event code 62 (KEY_F4) Event code 63 (KEY_F5) Event code 64 (KEY_F6) Event code 65 (KEY_F7) Event code 66 (KEY_F8) Event code 67 (KEY_F9) Event code 68 (KEY_F10) Event code 69 (KEY_NUMLOCK) Event code 70 (KEY_SCROLLLOCK) Event code 71 (KEY_KP7) Event code 72 (KEY_KP8) Event code 73 (KEY_KP9) Event code 74 (KEY_KPMINUS) Event code 75 (KEY_KP4) Event code 76 (KEY_KP5) Event code 77 (KEY_KP6) Event code 78 (KEY_KPPLUS) Event code 79 (KEY_KP1) Event code 80 (KEY_KP2) Event code 81 (KEY_KP3) Event code 82 (KEY_KP0) Event code 83 (KEY_KPDOT) Event code 85 (KEY_ZENKAKUHANKAKU) Event code 86 (KEY_102ND) Event code 87 (KEY_F11) Event code 88 (KEY_F12) Event code 89 (KEY_RO) Event code 90 (KEY_KATAKANA) Event code 91 (KEY_HIRAGANA) Event code 92 (KEY_HENKAN) Event code 93 (KEY_KATAKANAHIRAGANA) Event code 94 (KEY_MUHENKAN) Event code 95 (KEY_KPJPCOMMA) Event code 96 (KEY_KPENTER) Event code 97 (KEY_RIGHTCTRL) Event code 98 (KEY_KPSLASH) Event code 99 (KEY_SYSRQ) Event code 100 (KEY_RIGHTALT) Event code 102 (KEY_HOME) Event code 103 (KEY_UP) Event code 104 (KEY_PAGEUP) Event code 105 (KEY_LEFT) Event code 106 (KEY_RIGHT) Event code 107 (KEY_END) Event code 108 (KEY_DOWN) Event code 109 (KEY_PAGEDOWN) Event code 110 (KEY_INSERT) Event code 111 (KEY_DELETE) Event code 112 (KEY_MACRO) Event code 113 (KEY_MUTE) Event code 114 (KEY_VOLUMEDOWN) Event code 115 (KEY_VOLUMEUP) Event code 116 (KEY_POWER) Event code 117 (KEY_KPEQUAL) Event code 118 (KEY_KPPLUSMINUS) Event code 119 (KEY_PAUSE) Event code 121 (KEY_KPCOMMA) Event code 122 (KEY_HANGUEL) Event code 123 (KEY_HANJA) Event code 124 (KEY_YEN) Event code 125 (KEY_LEFTMETA) Event code 126 (KEY_RIGHTMETA) Event code 127 (KEY_COMPOSE) Event code 128
Bug#944356: (no subject)
> > I hit dim, brighter, mic off buttons, located at f3, f4 and f8. > Assuming KEY_F20 is your brightness up or down key, you should try to > remap this to brightnessup or brightnessdown I hit 3 different keys, but they all gave identical evtest/keyscan outputs. So remapping will give me the bug 'only brightness up' or 'only brightness down.'
Bug#944356: (no subject)
control: thanks A newer bios was released which fixed this issue. Thanks for helping me debug this issue!
Bug#884760: dirmngr: With missing .gnupg directory, dirmngr fails to start as daemon
Package: dirmngr Version: 2.1.18-8~deb9u1 Severity: important Dear Maintainer, I wanted to test some signatures, thus had to fetch keys. In Debian Stretch, dirmngr is kind of expected to be around to use gpg --recv-keys. Starting dirmngr is easy, either foreground or as daemon. "dirmngr" will start in foreground, create missing directories. "dirmngr --daemon" should start in the background, but it doesn't create missing directories (~/.gnupg): dirmngr[988]: error opening '/root/.gnupg/dirmngr_ldapservers.conf': No such file or directory dirmngr[988]: error binding socket to '/root/.gnupg/S.dirmngr': No such file or directory Exited with code 1 ~/repo# dirmngr dirmngr[1574]: error opening '/root/.gnupg/dirmngr_ldapservers.conf': No such file or directory dirmngr[1574.0]: permanently loaded certificates: 0 dirmngr[1574.0]: runtime cached certificates: 0 dirmngr[1574.0]: failed to open cache dir file '/root/.gnupg/crls.d/DIR.txt': No such file or directory dirmngr[1574.0]: creating directory '/root/.gnupg' dirmngr[1574.0]: creating directory '/root/.gnupg/crls.d' dirmngr[1574.0]: new cache dir file '/root/.gnupg/crls.d/DIR.txt' created # Home: /root/.gnupg # Config: [none] OK Dirmngr 2.1.18 at your service If I create a directory, or start in foreground, stop and start in background things *do* work as expected. Would it be possible to let the --daemon behave similar and thus create the missing ~/.gnupg/? -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-103-generic (SMP w/32 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages dirmngr depends on: ii adduser3.115 ii libassuan0 2.4.3-2 ii libc6 2.24-11+deb9u1 ii libgcrypt201.7.6-2+deb9u2 ii libgnutls303.5.8-5+deb9u3 ii libgpg-error0 1.26-2 ii libksba8 1.3.5-2 ii libldap-2.4-2 2.4.44+dfsg-5+deb9u1 ii libnpth0 1.3-1 ii lsb-base 9.20161125 Versions of packages dirmngr recommends: ii gnupg 2.1.18-8~deb9u1 Versions of packages dirmngr suggests: pn dbus-user-session pn libpam-systemd pn pinentry-gnome3 pn tor -- no debconf information
Bug#902253: (no subject)
Hi, Enigmail localization happens on Transifex. When I looked for that string it seems that it's restored to it's correct meaning: https://www.transifex.com/otf/enigmail-localization/viewstrings/#pl/enigmailproperties/116424802?q=text%3A'sign+message' https://gitlab.com/enigmail/enigmail/tree/master/lang/pl tells me that it's now correct upstream, since August 3th, last release was August 4th, so I expect this to be fixed in the next release. cześć, kwadronaut
