Bug#989459: RFP: docker-credential-helpers -- A suite of programs to use native stores to keep Docker credentials safe

2021-06-04 Thread Aidan Gauland 

Package: wnpp
Severity: wishlist

* Package name    : docker-credential-helpers
  Version : 0.6.3
  Upstream Author : Docker 
* URL : http://www.example.org/
* License : MIT
  Programming Lang: Go
  Description : A suite of programs to use native stores to keep Docker
credentials safe.

This package provides helper programs for docker to store credentials.  Only
two would be applicable to Debian: docker-credential-secretservice, for the
D-Bus secret service as credentials store; and docker-credential-pass, 
for the
program 'pass'.  I have been uisng the 'pass' helper successfully on my 
buster

system, with Docker from Debian.

Bug#971788: libnvidia-rtcore: Broken dependnecies: dependant libgcc-s1 version is unavailable

2020-10-07 Thread Aidan Gauland 
Package: libnvidia-rtcore
Version: 450.66-1~bpo10+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The current buster-backports version of libnvidia-rtcore depends upon
libgcc-s1 >= 4.2 which is unavailable in buster or buster-backports,
making this package impossible to install.

It looks like either gcc-10 needs to be backported to buster, or
libnvidia-rtcore needs to be ported to a version of gcc available in buster.

Regards,
Aidan Gauland



-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libnvidia-rtcore depends on:
ii  libc6  2.28-10
pn  libgcc-s1  
ii  libgcc1    1:8.3.0-6

libnvidia-rtcore recommends no packages.

libnvidia-rtcore suggests no packages.

Bug#971694: linux-image-5.7.0-0.bpo.2-amd64: Front audio ports do not work on Gigabyte X570 GAMING X motherboard

2020-10-05 Thread Aidan Gauland 
Package: src:linux
Version: 5.7.10-1~bpo10+1
Severity: normal

Dear Maintainer,

I just finished setting up my desktop with a Gigabyte X570 GAMING X
motherboard
and the rear audio ports work fine, but I cannot get audio out of the front
headphone jack or use a microphone with the front microphong jack.  In
pavucontrol, I can explicitly set the output and input ports to the front
ports, but that does not make them work.  I have also tried stopping
pulseaudio
to see whether they would work just bare ALSA, but that made no difference.

Regards,
Aidan Gauland



-- Package-specific info:
** Version:
Linux version 5.7.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-6), GNU ld (GNU Binutils for Debian) 2.31.1)
#1 SMP Debian 5.7.10-1~bpo10+1 (2020-07-30)

** Command line:
BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.7.0-0.bpo.2-amd64
root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[  142.753266] EDAC amd64: Node 0: DRAM ECC disabled.
[  142.770707] [drm] [nvidia-drm] [GPU ID 0x0900] Loading driver
[  142.770710] [drm] Initialized nvidia-drm 0.0.0 20160202 for
:09:00.0 on minor 0
[  142.869194] EDAC amd64: F17h_M70h detected (node 0).
[  142.869245] EDAC amd64: Node 0: DRAM ECC disabled.
[  142.869811] kvm: disabled by bios
[  142.953921] kvm: disabled by bios
[  142.953948] EDAC amd64: F17h_M70h detected (node 0).
[  142.954002] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.045483] EDAC amd64: F17h_M70h detected (node 0).
[  143.045533] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.046122] kvm: disabled by bios
[  143.117735] kvm: disabled by bios
[  143.117750] EDAC amd64: F17h_M70h detected (node 0).
[  143.117805] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.190554] kvm: disabled by bios
[  143.190594] EDAC amd64: F17h_M70h detected (node 0).
[  143.190647] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.269475] EDAC amd64: F17h_M70h detected (node 0).
[  143.269530] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.269972] kvm: disabled by bios
[  143.358168] EDAC amd64: F17h_M70h detected (node 0).
[  143.358221] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.359251] kvm: disabled by bios
[  143.442798] kvm: disabled by bios
[  143.442826] EDAC amd64: F17h_M70h detected (node 0).
[  143.442880] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.522181] EDAC amd64: F17h_M70h detected (node 0).
[  143.522234] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.598761] EDAC amd64: F17h_M70h detected (node 0).
[  143.598815] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.689790] EDAC amd64: F17h_M70h detected (node 0).
[  143.689843] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.774621] EDAC amd64: F17h_M70h detected (node 0).
[  143.774676] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.854057] EDAC amd64: F17h_M70h detected (node 0).
[  143.854113] EDAC amd64: Node 0: DRAM ECC disabled.
[  143.945115] EDAC amd64: F17h_M70h detected (node 0).
[  143.945167] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.038023] EDAC amd64: F17h_M70h detected (node 0).
[  144.038076] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.122786] EDAC amd64: F17h_M70h detected (node 0).
[  144.122839] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.213836] EDAC amd64: F17h_M70h detected (node 0).
[  144.213891] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.298003] EDAC amd64: F17h_M70h detected (node 0).
[  144.298058] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.402675] EDAC amd64: F17h_M70h detected (node 0).
[  144.402728] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.481727] EDAC amd64: F17h_M70h detected (node 0).
[  144.481783] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.594660] EDAC amd64: F17h_M70h detected (node 0).
[  144.594714] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.682039] EDAC amd64: F17h_M70h detected (node 0).
[  144.682092] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.758607] EDAC amd64: F17h_M70h detected (node 0).
[  144.758660] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.846895] EDAC amd64: F17h_M70h detected (node 0).
[  144.846948] EDAC amd64: Node 0: DRAM ECC disabled.
[  144.918680] EDAC amd64: F17h_M70h detected (node 0).
[  144.918733] EDAC amd64: Node 0: DRAM ECC disabled.
[  145.002712] EDAC amd64: F17h_M70h detected (node 0).
[  145.002764] EDAC amd64: Node 0: DRAM ECC disabled.
[  145.085864] EDAC amd64: F17h_M70h detected (node 0).
[  145.085916] EDAC amd64: Node 0: DRAM ECC disabled.
[  145.166699] EDAC amd64: F17h_M70h detected (node 0).
[  145.166752] EDAC amd64: Node 0: DRAM ECC disabled.
[  145.245401] EDAC amd64: F17h_M70h detected (node 0).
[  145.245454] EDAC amd64: Node 0: DRAM ECC disabled.
[  145.314623] EDAC amd64: F17h_M70h detected (node 0).
[  145.314675] EDAC amd64: Node 0: DRAM ECC disabled.
[  145.390837] EDAC amd64: F17h_M70h detected (node 0).
[  145.390890] EDAC amd64: Node 0: DRAM EC

Bug#916605: torbrowser-launcher: I can't start torbrowser-launcher

2020-09-22 Thread Aidan Gauland 
Package: torbrowser-launcher
Version: 0.3.2-13~bpo10+1
Followup-For: Bug #916605

Dear Maintainer,

I get similar behaviour even after deleting the following directories:
  ~/.local/share/torbrowser/
  ~/.config/torbrowser/
  ~/.cache/torbrowser/

The launcher opens the download progress modal, then while the same
modal shows "Installing", another modal comes up saying:

"The version of Tor Browser you have installed is earlier than it should
be, which could be a sign of an attack!"

with only an OK button.  When I dismiss that, the "Installing" modal
stays up
indefinitely.  If I dismiss that and rerun torbrowser-launcher, I get
this on
stdout

Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.3.2
https://github.com/micahflee/torbrowser-launcher
qt5ct: using qt5ct plugin
Your version of Tor Browser is out-of-date. Downloading the newest version.
Downloading
https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US

and exits immediately.

Regards,
Aidan Gauland



-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
LANGUAGE=en_NZ:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20200601~deb10u1
ii  gnupg 2.2.12-1+deb10u1
ii  libdbus-glib-1-2  0.110-4
ii  python3   3.7.3-1
ii  python3-gpg   1.12.0-6
ii  python3-pyqt5 5.11.3+dfsg-1+b3
ii  python3-requests  2.21.0-1
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.5.10-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.2-10

-- Configuration Files:
/etc/apparmor.d/local/torbrowser.Browser.firefox changed:
owner /{dev,run}/shm/org.mozilla.*.* rw,


-- no debconf information

Bug#968493: zfs-auto-snapshot: systemd-cron does not satisfy cron dependency

2020-08-16 Thread Aidan Gauland 
Package: zfs-auto-snapshot
Version: 1.2.4-2
Severity: normal

Dear Maintainer,

Unless the cron jobs provided by zfs-auto-snapshot are incompatible
with systemd-cron, this package's dependency upon cron should be
satisfied by either cron or systemd-cron.  If it is incompatible with
systemd-cron, a note in the package description would be nice.

Kind regards,
Aidan Gauland

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zfs-auto-snapshot depends on:
pn  cron    
ii  zfsutils-linux  0.8.4-2~bpo10+1

zfs-auto-snapshot recommends no packages.

zfs-auto-snapshot suggests no packages.

Bug#966477: WARNING: at net/ipv4/tcp_input.c:2799 tcp_fastretrans_alert

2020-07-28 Thread Aidan Gauland 
Package: src:linux
Version: 4.19.118-2+deb10u1
Severity: normal

Dear Maintainer,

During my semi-regular auditing of the system log, I noticed the below
warning
and stack trace.  I have no idea what may have caused it, and the system has
been operating normally for weeks (continuous uptime) and appears to
still be
operating normally.

Regards,
Aidan Gauland

Note: Some sensitive apparmor audit lines have been removed from the
kernel log here.

-- Package-specific info:
** Version:
Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1
(2020-06-07)

** Command line:
BOOT_IMAGE=/BOOT/debian@/vmlinuz-4.19.0-9-amd64 root=ZFS=/ROOT/debian ro
root=ZFS=rpool/ROOT/debian quiet

** Tainted: PWOE (12801)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[2513851.122581] kauditd_printk_skb: 10 callbacks suppressed
[2693086.705995] [ cut here ]
[2693086.706047] WARNING: CPU: 3 PID: 0 at net/ipv4/tcp_input.c:2799
tcp_fastretrans_alert.cold.86+0x19/0x74
[2693086.706049] Modules linked in: nft_reject_inet nft_reject nft_log
nft_ct rpcsec_gss_krb5 nf_tables_set nf_log_ipv6 ip6_tables ip6t_REJECT
nf_reject_ipv6 nf_log_ipv4 nf_log_common nft_limit nft_counter xt_LOG
xt_limit xt_comment xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c crc32c_generic
nft_compat nf_tables nfnetlink nls_ascii nls_cp437 vfat fat intel_rapl
sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
ipmi_ssif kvm ast ttm irqbypass drm_kms_helper crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel intel_cstate mxm_wmi drm sg evdev
joydev intel_uncore mei_me efi_pstore ipmi_si mei intel_rapl_perf pcspkr
efivars pcc_cpufreq iTCO_wdt ipmi_devintf iTCO_vendor_support
intel_pch_thermal ioatdma ipmi_msghandler wmi button acpi_pad
[2693086.706102]  nfsd auth_rpcgss nfs_acl lockd grace sunrpc efivarfs
ip_tables x_tables autofs4 zfs(POE) zunicode(POE) zlua(POE) zavl(POE)
icp(POE) zcommon(POE) znvpair(POE) spl(OE) hid_generic usbhid hid sd_mod
crc32c_intel ahci xhci_pci libahci ehci_pci xhci_hcd ehci_hcd libata
ixgbe aesni_intel scsi_mod igb usbcore aes_x86_64 crypto_simd cryptd
glue_helper lpc_ich i2c_i801 i2c_algo_bit mfd_core dca usb_common mdio
[2693086.706142] CPU: 3 PID: 0 Comm: swapper/3 Tainted: P    W 
OE 4.19.0-9-amd64 #1 Debian 4.19.118-2+deb10u1
[2693086.706144] Hardware name: Supermicro Super
Server/X10SDV-4C+-TLN4F, BIOS 2.1 11/22/2019
[2693086.706150] RIP: 0010:tcp_fastretrans_alert.cold.86+0x19/0x74
[2693086.706154] Code: c7 48 f0 c3 96 e8 5a a8 a8 ff 0f 0b e9 ea ad ff
ff 48 c7 c7 48 f0 c3 96 48 89 4c 24 10 44 89 4c 24 08 89 14 24 e8 3a a8
a8 ff <0f> 0b 8b 14 24 44 8b 4c 24 08 48 8b 4c 24 10 e9 a9 b2 ff ff 48 c7
[2693086.706157] RSP: 0018:93d39fac3b10 EFLAGS: 00010246
[2693086.706160] RAX: 0024 RBX: 93d374724400 RCX:

[2693086.706163] RDX:  RSI: 00f6 RDI:
0300
[2693086.706165] RBP:  R08: 0011c6ad R09:
0004
[2693086.706166] R10:  R11: 0001 R12:
0001
[2693086.706168] R13: 93d39fac3ba8 R14:  R15:
0001
[2693086.706172] FS:  () GS:93d39fac()
knlGS:
[2693086.706174] CS:  0010 DS:  ES:  CR0: 80050033
[2693086.706176] CR2: 7f014aa2b000 CR3: 0007e840a001 CR4:
003606e0
[2693086.706179] DR0:  DR1:  DR2:

[2693086.706181] DR3:  DR6: fffe0ff0 DR7:
0400
[2693086.706182] Call Trace:
[2693086.706186]  
[2693086.706194]  tcp_ack+0x95d/0x1120
[2693086.706202]  ? sched_clock+0x5/0x10
[2693086.706208]  ? tcp_write_xmit+0x3cf/0x1000
[2693086.706214]  tcp_rcv_established+0x327/0x650
[2693086.706219]  tcp_v4_do_rcv+0x12a/0x1e0
[2693086.706223]  tcp_v4_rcv+0xb1a/0xc20
[2693086.706240]  ? nft_do_chain_inet+0x8a/0x100 [nf_tables]
[2693086.706248]  ip_local_deliver_finish+0x63/0x1e0
[2693086.706253]  ip_local_deliver+0xe0/0xf0
[2693086.706258]  ? ip_sublist_rcv_finish+0x80/0x80
[2693086.706263]  ip_rcv+0xbc/0xd0
[2693086.706268]  ? ip_rcv_finish_core.isra.18+0x360/0x360
[2693086.706275]  __netif_receive_skb_one_core+0x52/0x70
[2693086.706280]  netif_receive_skb_internal+0x2f/0xa0
[2693086.706285]  napi_gro_receive+0xba/0xe0
[2693086.706303]  igb_poll+0x481/0xeb0 [igb]
[2693086.706310]  net_rx_action+0x149/0x3b0
[2693086.706318]  __do_softirq+0xde/0x2d8
[2693086.706325]  irq_exit+0xba/0xc0
[2693086.706330]  do_IRQ+0x7f/0xe0
[2693086.706335]  common_interrupt+0xf/0xf
[2693086.706337]  
[2693086.706342] RIP: 0010:cpuidle_enter_state+0xb9/0x320
[2693086.706345] Code: e8 dc c0 b0 ff 80 7c 24 0b 00 74 17 9c 58 0f 1f
44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 ae

Bug#609352: Successor to ZDoom available as free software

2020-05-16 Thread Aidan Gauland 
On Thu, 18 May 2017 13:07:52 +0200 Steven De Herdt 
 wrote:

> Some news regarding ZDoom:
> Official development on this port has stopped, but GZDoom which can be
> regarded as its successor is now released under the GPLv3:
> https://forum.zdoom.org/viewtopic.php?t=56132
>
> Kind regards
> -Steven

I have just built the latest release of GZDoom (4.3.3 at time of 
writing) against OpenAL instead of FMOD, and sound seems to work 
perfectly, so all of this software's dependencies are already packaged 
in Debian.

Bug#941203: emacs-gtk: package-autoremove tries to remove Debian elisp packages

2019-09-26 Thread Aidan Gauland 

Package: emacs-gtk
Version: 1:26.1+1-3.2+deb10u1
Severity: normal

Dear Maintainer,

I have the emacs-el package installed on my system, which shows up in the
*Packages* list as "debian-el".  When I run the Emacs command `package-
autoremove', it wants to remove this package.  When this command fails to
remove a package, it stops, leaving any remaining packages to be uninstalled,
installed.  So I see two problems here:

1) The debian-el package is being considered autoremovable, even though it is
listed as "external", and
2) The command `package-autoremove' will not carry on removing packages if one
of the remove operations fails.

Regards,
Aidan Gauland



-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common   1:26.1+1-3.2+deb10u1
ii  emacs-common   1:26.1+1-3.2+deb10u1
ii  libacl12.2.53-4
ii  libasound2 1.1.8-1
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libdbus-1-31.12.16-1
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libgif75.1.4-3
ii  libglib2.0-0   2.58.3-2+deb10u1
ii  libgnutls303.6.7-4
ii  libgomp1   8.3.0-6
ii  libgpm21.20.7-5
ii  libgtk-3-0 3.24.5-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblcms2-2 2.9-3
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.10.23+dfsg-2.1
ii  libmagickwand-6.q16-6  8:6.9.10.23+dfsg-2.1
ii  libotf00.9.13-4
ii  libpango-1.0-0 1.42.4-7~deb10u1
ii  libpangocairo-1.0-01.42.4-7~deb10u1
ii  libpng16-161.6.36-6
ii  librsvg2-2 2.44.10-2.1
ii  libselinux12.8-1+b1
ii  libsm6 2:1.2.3-1
ii  libsystemd0241-7~deb10u1
ii  libtiff5   4.0.10-4
ii  libtinfo6  6.1+20181013-2+deb10u1
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb11.13.1-2
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-2
ii  libxinerama1   2:1.1.4-2
ii  libxml22.9.4+dfsg1-7+b3
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-1

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:26.1+1-1

-- no debconf information

Bug#866100: libcrypto++-dev: Missing keccak.h

2017-06-27 Thread Aidan Gauland 
Package: libcrypto++-dev
Version: 5.6.4-7
Severity: important
Tags: patch

Dear Maintainer,

When building a third-party program that uses libcrypto++ for Keccak
functions,
I discovered that the keccak.h header was missing from my system.  This
appears
to be an oversight in the Makefile.am file in the source package, for
which I
am including a patch.

Regards,
Aidan Gauland



-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
LANGUAGE=en_NZ:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcrypto++-dev depends on:
ii  libcrypto++6  5.6.4-7

libcrypto++-dev recommends no packages.

libcrypto++-dev suggests no packages.

-- no debconf information

Bug#865519: unattended-upgrades: Readme incorrect about default state

2017-06-22 Thread Aidan Gauland 
Package: unattended-upgrades
Version: 0.93.1+nmu1
Severity: minor

Dear Maintainer,

The readme /usr/share/doc/unattended-upgrades/README.md.gz states that
unattended-upgrades is "is not enabled by default[,]" but as of the
stable release of stretch, it is enabled by default.  (The debconf
information below are the default values, and the files listed in the
README that the user needs to create are present and populated as
described in the README.)

Kind regards,
Aidan Gauland


-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unattended-upgrades depends on:
ii  apt1.4.6
ii  apt-utils  1.4.6
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  lsb-base   9.20161125
ii  lsb-release9.20161125
ii  python33.5.3-1
ii  python3-apt1.4.0~beta3
ii  ucf3.0036
ii  xz-utils   5.2.2-1.2+b1

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-128+b1

Versions of packages unattended-upgrades suggests:
pn  bsd-mailx 
pn  mail-transport-agent  
pn  needrestart   

-- debconf information:
  unattended-upgrades/origins_pattern:
"origin=Debian,codename=${distro_codename},label=Debian-Security";
  unattended-upgrades/enable_auto_updates: true

Bug#841760: firejail: Network namespace disconnect

2016-11-05 Thread Aidan Gauland 
On 05/11/16 23:10, Reiner Herrmann wrote:
> Okay, so the problem seems to be that some time after boot your
> resolv.conf is overwritten by rdnssd with only an IPv6 nameserver
> (which is not reachable in the sandbox, because of the device).
> 
> I would guess that directly after boot you still have an IPv4
> nameserver configured by your DHCP client. But shortly after, rdnssd
> auto-discovers an IPv6 nameserver and rewrites the file (did perhaps
> something on your router change, so that it know also provides DNS over
> IPv6?).

I think I know why this started happening suddenly: I used to have very
restrictive iptables rules set up (on this host, not the router) that
would have been blocking rdnssd.  The removal of netfilter-persistent
only coincided with unblocking rdnssd.

(For the record, I have attached /etc/resolv.conf *before* it is
overwritten by rdnssd.)

> If you are certain that you don't want to use auto-discovered IPv6
> nameservers you could remove rdnssd.
> Or it could also help to install the resolvconf package. rdnssd calls a
> script (/etc/rdnssd/merge-hook) when it finds IPv6 nameservers, and this
> hook either overwrites the resolv.conf file, or lets resolvconf handle
> it properly when it is installed.
> 
> You can also try firejail's --dns option to set fixed nameservers
> inside the sandbox.

So it seems I have a few options for solving the issue of DNS being
misconfigured within firejails, and which one I use depends upon how I
want to configure my LAN, which is beyond the scope of this "bug", so I
will end my investigation here.

Would this be worth forwarding to upstream to be recorded as a known
problem? <https://firejail.wordpress.com/support/known-problems/>

Thank you very much for your assistance in troubleshooting this problem.
Best regards,
Aidan Gauland
domain lan
search lan
nameserver 192.168.1.1


signature.asc
Description: OpenPGP digital signature

Bug#841760: firejail: Network namespace disconnect

2016-11-04 Thread Aidan Gauland 
On 05/11/16 11:18, Reiner Herrmann wrote:
> On Sat, Nov 05, 2016 at 11:09:31AM +1300, Aidan Gauland wrote:
>> I can successfully ping 8.8.8.8, and the contents of /etc/resolv.conf
>> both in and out of the sandbox is the single line,
>>
>> nameserver fe80::c6e9:84ff:fe9f:7bb2%eth0
> 
> Are you able to reach (ping6) this address?
> If yes, are you able to use it for dns lookups
> (nslookup debian.org fe80::c6e9:84ff:fe9f:7bb2%eth0)?

Only outside the sandbox; inside the sandbox, it gives me "unknown
host", but if I change "%eth0" to "%eth0-11278", I can ping it, and I
can use it for DNS lookups.

> Do you also have the package resolvconf installed?

No, and I don't think I ever have on this system.


So now that we have narrowed down the cause of the lookup failures, how
do I fix this?  And why on Earth does this happen only after the system
has been up for a few minutes, and not all the time?  rdnssd has been on
my system for a long time, but it's possible that I have unwittingly
changed some system configuration that affecting /etc/resolv.conf



signature.asc
Description: OpenPGP digital signature

Bug#841760: firejail: Network namespace disconnect

2016-11-04 Thread Aidan Gauland 
On 05/11/16 10:40, Reiner Herrmann wrote:
> On Sat, Nov 05, 2016 at 10:32:21AM +1300, Aidan Gauland wrote:
>>>> $ w3m google.com
>>>> w3m: Can't load google.com.
>>>
>>> The same error occurs when only DNS is not working.
>>> Can you please try pinging your default gateway?
>>
>> Yes, pinging the default gateway works just fine with 0% packet loss
>> (tested with 20 packets).
> 
> Interesting, then I assume pinging an external IP address also works
> (like 8.8.8.8)?  Can you check /etc/resolv.conf if a valid nameserver
> is configured?

I can successfully ping 8.8.8.8, and the contents of /etc/resolv.conf
both in and out of the sandbox is the single line,

nameserver fe80::c6e9:84ff:fe9f:7bb2%eth0

> I saw that you are running rdnssd, which might overwrite
> /etc/resolv.conf.

I think rdnssd was part of the base Debian installation, so that
shouldn't suddenly be causing problems now.  Could it?



signature.asc
Description: OpenPGP digital signature

Bug#841760: firejail: Network namespace disconnect

2016-11-04 Thread Aidan Gauland 
On 05/11/16 06:05, Reiner Herrmann wrote:
> 
> Unfortunately I was not yet able to reproduce this behavior.
> 
>> $ w3m google.com
>> w3m: Can't load google.com.
> 
> The same error occurs when only DNS is not working.
> Can you please try pinging your default gateway?

Yes, pinging the default gateway works just fine with 0% packet loss
(tested with 20 packets).

>> The only possibly relevant changes to my system that I can think of
>> (even after
>> consulting system logs) is that this occurred after I removed the package
>> iptables-persistent, but reinstalling this did not resolve the problem.
> 
> iptables is only necessary if you use --netfilter.

I still have iptables installed, but my thinking here was that changes
to the host's netfilter may interfere with the sandboxes.

> Are you using any network managers? Could you please list the processes
> running on the host?

I am 99% sure I am not running a network manager, but of course
(`ps -ef` output attached).

Regards,
Aidan
UIDPID  PPID  C STIME TTY  TIME CMD
root 1 0  0 Nov03 ?00:00:00 /sbin/init
root 2 0  0 Nov03 ?00:00:00 [kthreadd]
root 3 2  0 Nov03 ?00:00:00 [ksoftirqd/0]
root 4 2  0 Nov03 ?00:00:00 [kworker/0:0]
root 5 2  0 Nov03 ?00:00:00 [kworker/0:0H]
root 7 2  0 Nov03 ?00:00:00 [rcu_sched]
root 8 2  0 Nov03 ?00:00:00 [rcu_bh]
root 9 2  0 Nov03 ?00:00:00 [migration/0]
root10 2  0 Nov03 ?00:00:00 [lru-add-drain]
root11 2  0 Nov03 ?00:00:00 [watchdog/0]
root12 2  0 Nov03 ?00:00:00 [cpuhp/0]
root13 2  0 Nov03 ?00:00:00 [cpuhp/1]
root14 2  0 Nov03 ?00:00:00 [watchdog/1]
root15 2  0 Nov03 ?00:00:00 [migration/1]
root16 2  0 Nov03 ?00:00:00 [ksoftirqd/1]
root18 2  0 Nov03 ?00:00:00 [kworker/1:0H]
root19 2  0 Nov03 ?00:00:00 [cpuhp/2]
root20 2  0 Nov03 ?00:00:00 [watchdog/2]
root21 2  0 Nov03 ?00:00:00 [migration/2]
root22 2  0 Nov03 ?00:00:00 [ksoftirqd/2]
root24 2  0 Nov03 ?00:00:00 [kworker/2:0H]
root25 2  0 Nov03 ?00:00:00 [cpuhp/3]
root26 2  0 Nov03 ?00:00:00 [watchdog/3]
root27 2  0 Nov03 ?00:00:00 [migration/3]
root28 2  0 Nov03 ?00:00:00 [ksoftirqd/3]
root30 2  0 Nov03 ?00:00:00 [kworker/3:0H]
root31 2  0 Nov03 ?00:00:00 [kdevtmpfs]
root32 2  0 Nov03 ?00:00:00 [netns]
root33 2  0 Nov03 ?00:00:00 [khungtaskd]
root34 2  0 Nov03 ?00:00:00 [oom_reaper]
root35 2  0 Nov03 ?00:00:00 [writeback]
root36 2  0 Nov03 ?00:00:00 [kcompactd0]
root38 2  0 Nov03 ?00:00:00 [ksmd]
root39 2  0 Nov03 ?00:00:00 [khugepaged]
root40 2  0 Nov03 ?00:00:00 [crypto]
root41 2  0 Nov03 ?00:00:00 [kintegrityd]
root42 2  0 Nov03 ?00:00:00 [bioset]
root43 2  0 Nov03 ?00:00:00 [kblockd]
root44 2  0 Nov03 ?00:00:00 [devfreq_wq]
root45 2  0 Nov03 ?00:00:00 [watchdogd]
root48 2  0 Nov03 ?00:00:00 [kswapd0]
root49 2  0 Nov03 ?00:00:00 [vmstat]
root63 2  0 Nov03 ?00:00:00 [kthrotld]
root64 2  0 Nov03 ?00:00:00 [ipv6_addrconf]
root70 2  0 Nov03 ?00:00:00 [deferwq]
root   113 2  0 Nov03 ?00:00:00 [acpi_thermal_pm]
root   114 2  0 Nov03 ?00:00:00 [ata_sff]
root   115 2  0 Nov03 ?00:00:00 [kpsmoused]
root   177 2  0 Nov03 ?00:00:00 [scsi_eh_0]
root   178 2  0 Nov03 ?00:00:00 [scsi_tmf_0]
root   179 2  0 Nov03 ?00:00:00 [scsi_eh_1]
root   180 2  0 Nov03 ?00:00:00 [scsi_tmf_1]
root   181 2  0 Nov03 ?00:00:00 [scsi_eh_2]
root   182 2  0 Nov03 ?00:00:00 [scsi_tmf_2]
root   183 2  0 Nov03 ?00:00:00 [scsi_eh_3]
root   184 2  0 Nov03 ?00:00:00 [scsi_tmf_3]
root   185 2  0 Nov03 ?00:00:00 [scsi_eh_4]
root   186 2  0 Nov03 ?00:00:00 [scsi_tmf_4]
root   187 2  0 Nov03 ?00:00:00 [scsi_eh_5]
root   188 2  0 Nov03 ?00:00:00 [scsi_tmf_5]
root   195 2  0 Nov03 ?00:00:00 [bioset]
root   196 2  0 Nov03 ?00:00:00 [bioset]
root   197 2  0 Nov03 ?00:00:00 [bioset]
root   201 2  0 Nov03 ?00:00:00 [kworker/0:1H]
root   216 2  0 Nov03 ?00:00:00 [md]
root   233 2  0 Nov03 ?

Bug#841760: firejail: Network namespace disconnect

2016-10-23 Thread Aidan Gauland 
Adding the output of `ip link` and `ip route list` outside and inside
the sandbox.

$ ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
mode DEFAULT group default qlen 1000
link/ether 74:d4:35:1e:1a:c3 brd ff:ff:ff:ff:ff:ff
$ ip route list
default via 192.168.1.1 dev eth0 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.233 
$ firejail --noprofile --net=eth0
Parent pid 30984, child pid 30985

InterfaceMACIP   Mask Status
lo  127.0.0.1255.0.0.0UP
eth0-30984   f2:9b:1d:21:6f:b9  192.168.1.69 255.255.255.0UP
Default gateway 192.168.1.1

Child process initialized
$ ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0-30984:  mtu 1500 qdisc noqueue state 
UP mode DEFAULT group default qlen 1000
link/ether f2:9b:1d:21:6f:b9 brd ff:ff:ff:ff:ff:ff
$ ip route list
default via 192.168.1.1 dev eth0-30984 
192.168.1.0/24 dev eth0-30984  proto kernel  scope link  src 192.168.1.69

Bug#841760: firejail: Network namespace disconnect

2016-10-23 Thread Aidan Gauland 
Package: firejail
Version: 0.9.42-1~bpo8+1
Severity: important

Dear Maintainer,

On my system, as of yesterday, firejails with a separate network
namespace are unable to reach any external hosts.  For example,

$ /sbin/ifconfig
eth0  Link encap:Ethernet  HWaddr 74:d4:35:1e:1a:c3
  inet addr:192.168.1.233  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fe80::76d4:35ff:fe1e:1ac3/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:96483 errors:0 dropped:0 overruns:0 frame:0
  TX packets:53337 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:139321079 (132.8 MiB)  TX bytes:4408696 (4.2 MiB)
  Interrupt:20 Memory:f710-f712

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:396 errors:0 dropped:0 overruns:0 frame:0
  TX packets:396 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1
  RX bytes:385244 (376.2 KiB)  TX bytes:385244 (376.2 KiB)

$ firejail --noprofile --net=eth0
Parent pid 9079, child pid 9080

InterfaceMACIP   Mask Status
lo  127.0.0.1255.0.0.0UP
eth0-907996:6d:22:aa:e6:39  192.168.1.135255.255.255.0UP
Default gateway 192.168.1.1

Child process initialized
Cleanliness becomes more important when godliness is unlikely.
-- P. J. O'Rourke
$ w3m google.com
w3m: Can't load google.com.
$ /sbin/ifconfig
eth0-9079 Link encap:Ethernet  HWaddr 96:6d:22:aa:e6:39
  inet addr:192.168.1.135  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fe80::946d:22ff:feaa:e639/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:228 (228.0 B)  TX bytes:636 (636.0 B)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


The only possibly relevant changes to my system that I can think of
(even after
consulting system logs) is that this occurred after I removed the package
iptables-persistent, but reinstalling this did not resolve the problem.
firejail with network namespaces work as expected for several minutes
immediately after a cold boot, but then even *already running* firejails
lose the ability to reach the outside world.

As shown below, I am running the jessie-backports kernel, but this
happens on the jessie kernel as well.

I realise it is likely this is not a firejail bug, but this is the only
tool I know how to use for setting up network namespaces.

Kind regards,
Aidan Gauland



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firejail depends on:
ii  libapparmor1  2.9.0-3
ii  libc6 2.19-18+deb8u6

Versions of packages firejail recommends:
ii  xpra  0.14.10+dfsg-1

firejail suggests no packages.

-- no debconf information

Bug#840822: RFP: ruby-middleman -- Build static websites with an easy-to-use framework

2016-10-15 Thread Aidan Gauland 
Package: wnpp
Severity: wishlist

* Package name: ruby-middleman
  Version : 4.1.10
  Upstream Author : Thomas Reynolds 
* URL : https://middlemanapp.com/
* License : MIT
  Programming Lang: Ruby
  Description : Build static websites with an easy-to-use framework

Middleman is a Ruby framework for building static websites with HTML-templating
languages, compiled-to-CSS languages such as Sass, and compiled-to-JavaScript
languages such as CoffeeScript.  It is somewhat similar to the Python framework
Jekyll.

I think this would be useful to have packaged for Debian for greater stability
over installing via rubygems.org (which in my experience with fraught with
peril).  Packaging this for Debian will require packaging some other Ruby
"gems", as it built on top of Padrino , which is not
already in Debian.

It is a widely-used framework
, and has at least
one Debian user (myself).

Bug#823490: stow prints Perl warning

2016-05-05 Thread Aidan Gauland 
OK, great, so this should be fixed in squeeze, since that has stow
2.2.2, which has that fix.  Thanks for finding that.

On 05/05/16 22:02, Adam Spiers wrote:
> This was fixed almost 2 years ago:
> 
> https://github.com/aspiers/stow/commit/d788ce0c1c59b3158270143659f7a4363da73056
> 
> On 5 May 2016 at 10:12, Aidan Gauland <aidal...@fastmail.net> wrote:
>> Package: stow
>> Version: 2.2.0-2
>> Severity: minor
>>
>> Dear Maintainer,
>>
>> stow always prints the following line, regardless of how it is invoked.
>>  This does not prevent it from returning a zero exit status, so this is
>> only a minor annoyance.
>>
>> Possible precedence issue with control flow operator at
>> /usr/share/perl5/Stow.pm line 1736.
>>
>> Regards,
>> Aidan Gauland
>>
>>
>>
>> -- System Information:
>> Debian Release: 8.4
>>   APT prefers stable-updates
>>   APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386, armhf
>>
>> Kernel: Linux 4.5.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages stow depends on:
>> ii  dpkg  1.17.26
>> ii  install-info  5.2.0.dfsg.1-6
>> ii  perl  5.20.2-3+deb8u4
>>
>> stow recommends no packages.
>>
>> Versions of packages stow suggests:
>> pn  doc-base  
>>
>> No debconf-show output
>>

Bug#823490: stow prints Perl warning

2016-05-05 Thread Aidan Gauland 
Package: stow
Version: 2.2.0-2
Severity: minor

Dear Maintainer,

stow always prints the following line, regardless of how it is invoked.
 This does not prevent it from returning a zero exit status, so this is
only a minor annoyance.

Possible precedence issue with control flow operator at
/usr/share/perl5/Stow.pm line 1736.

Regards,
Aidan Gauland



-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.5.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages stow depends on:
ii  dpkg  1.17.26
ii  install-info  5.2.0.dfsg.1-6
ii  perl  5.20.2-3+deb8u4

stow recommends no packages.

Versions of packages stow suggests:
pn  doc-base  

No debconf-show output

Bug#774008: auctex: Depends on unavailable version of emacsen-common

2014-12-27 Thread Aidan Gauland 
Package: auctex
Version: 11.87-2~bpo70+1
Severity: important

Dear Maintainer,

The version in wheezy-backports (listed above) of auctex depends upon
emacsen-common 2.0.8, but only 2.0.5 is available in wheezy and no
version is available in wheezy-backports.

I can build the wheezy-backports source-package locally if I change the
minimum required version of emacsen-common to 2.0.5, and it works fine.
 Looking at the changelog, this appears to have been changed in version
11.87-2 of the package, but not addressed by the backport.  The
changelog message says Update Debian Emacs policy support to
emacsen-common 2.0.8.

Regards,
Aidan Gauland

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706371: geiser: emacs24 does not satisfy emacs dependency

2013-04-28 Thread Aidan Gauland 
Package: geiser
Version: 0.3-1
Severity: minor

emacs24 is in sid, but geiser depends on emacs23, rather than emacs23 OR 
emacs24.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#641145: [Pkg-xfce-devel] Bug#641145: xfce4-power-manager: Doesn't lock screen on suspend

2011-09-15 Thread Aidan Gauland 
On 15/09/11 22:46, Yves-Alexis Perez wrote:
 On jeu., 2011-09-15 at 22:00 +1200, Aidan Gauland wrote:
 This appears to be a known bug:
 https://bugzilla.xfce.org/show_bug.cgi?id=6019
 
 This bug is against xfce4-power-manager, not xfce4-session. So what
 exactly are you using to suspend/hibernate? Could you precise what you
 use?

To suspend and hibernate my system, I am using the Log Out Dialog.

When I reported this bug, I was not certain which package to report it
against; I thought it was a problem with xfce4-power-manager, but it now
appears to be in xfce4-session.

Regards,
Aidan Gauland



signature.asc
Description: OpenPGP digital signature

Bug#641145: [Pkg-xfce-devel] Bug#641145: xfce4-power-manager: Doesn't lock screen on suspend

2011-09-13 Thread Aidan Gauland 
On 12/09/11 23:04, Yves-Alexis Perez wrote:
 Can you look at .xsession-errors or run xfce4-power-manager from command
 line and report back any error there?

The only thing that appears in .xsession-errors after bringing my
computer back from suspend is...

** Message: xfsm-shutdown-helper.c:1411: Using org.freedesktop.UPower to
Suspend

 Can you manually try xflock4?

xflock4 sucessfully locks the screen, printing the following...

xscreensaver-command: activating and locking.

Regards,
Aidan Gauland



signature.asc
Description: OpenPGP digital signature

Bug#641145: xfce4-power-manager: Doesn't lock screen on suspend

2011-09-10 Thread Aidan Gauland 
Package: xfce4-power-manager
Version: 1.0.10-4+b1
Severity: important

Dear Maintainer,

In the Xfce Power Manager settings, I have ticked the box labelled Lock
screen when going for suspend/hibernate, but when I sleep or hibernate
my system, it does not come back with the screen locked.  The
xscreensaver daemon is definitely running and can be locked manually.

Kind regards,
Aidan Gauland

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.13-18
ii  libcairo2 1.10.2-6.1
ii  libdbus-1-3   1.4.14-1
ii  libdbus-glib-1-2  0.94-4
ii  libgdk-pixbuf2.0-02.23.5-3
ii  libglib2.0-0  2.28.6-1
ii  libgtk2.0-0   2.24.4-3
ii  libnotify40.7.3-2
ii  libx11-6  2:1.4.4-1
ii  libxext6  2:1.3.0-3
ii  libxfce4ui-1-04.8.0-3
ii  libxfce4util4 4.8.1-3
ii  libxfconf-0-2 4.8.0-3
ii  libxrandr22:1.3.2-2
ii  upower0.9.12-1+b1
ii  xfce4-power-manager-data  1.0.10-4

Versions of packages xfce4-power-manager recommends:
ii  consolekit  0.4.5-1

Versions of packages xfce4-power-manager suggests:
pn  udisks   1.0.4-1
pn  xfce4-power-manager-plugins  none

-- no debconf information



signature.asc
Description: OpenPGP digital signature