Bug#1063468: linux-image-6.1.0-17-amd64: Loud squeals/crackles from Steelseries 2 Channel HD Audio chipset after restarting from Windows 11

[Luke Feetham]

Package: src:linux
Version: 6.1.69-1
Severity: important
X-Debbugs-Cc: l.feet...@live.co.uk

Dear Maintainer,


I have a Recoil 16 Laptop (less than 6 months old) from PC Specialist 
(https://www.pcspecialist.co.uk/notebooks/recoil-16) that has a
Nahimic Steelseries 2 Channel HD Audio chipset (full laptop specs provided 
below). I have installed Debian 12 Bookworm with KDE Plasma
under a dual-boot setup with Windows 11. When thelaptop is off and I power it 
up and boot straight into Deebian, everything seems to
be fine, but when the laptop is powered-up and running Windows, if I then click 
restart and then boot into Debian (without powering 
down) I experience some significant audio issues, consisting of loud 
high-pitched squeals, crackling and pops that cannot be stopped
(volume controls and muting does nothing). An example of this behaviour can be 
seen here:

https://youtu.be/6w9foiCE6ek

This problem has been discussed on the Debian User Forum 
(https://forums.debian.net/viewtopic.php?t=158192), where it was suggested
that it may be that Windows' settings might be persisting within the sound card 
after the restart and causing issues within Debian.
It seems like this could be a plausible explanation since the problem only 
seems to happen when switching from Windows to Debian, 
and the only way to avoid the problem is to do a full shutdown, wait for some 
amount of time, and then power back up and boot into
Debian. While this approach works, and I can kind-of live with it for now, it 
is far from convenient (especially when I keep 
forgetting to clilck shut down instad of restart) and so is not really an 
acceptable solution in the long term.

While I have not been able to exhaustively test it, I can confirm that this 
problem is present on newer version of the linux kernel.
I have tested this problem within live environments of both Kubuntu 23.10 
(kernel 6.5.0-9-generic) and Fedora 39 (kernel 
6.5.6-300.fc39.x86_64). Again, this is whenever I restart from Windows 11.

Please let me know if you need further information.
 
Best regards

Luke


Laptop Specs:

Chassis & Display   Recoil Series: 16" Matte QHD 240Hz sRGB 100% LED 
Widescreen (2560x1600)
Processor (CPU) Intel® Core™ i9 24 Core Processor 13900HX (5.4GHz Turbo)
Memory (RAM)64GB Corsair 4800MHz SODIMM DDR5 (2 x 32GB)
Graphics Card   NVIDIA® GeForce® RTX 4090 - 16.0GB GDDR6 Video RAM - 
DirectX® 12.1
Laptop Cooling  PCS Liquid Series® Laptop Cooler
1st M.2 SSD Drive   4TB CORSAIR MP600 PRO NVMe PCIe M.2 SSD (up to 7000 
MB/R, 6850 MB/W)
2nd M.2 SSD Drive   4TB CORSAIR MP600 PRO NVMe PCIe M.2 SSD (up to 7000 
MB/R, 6850 MB/W)
Memory Card Reader  Integrated SD Memory Card Reader
Sound Card  Nahimic by SteelSeries 2 Channel HD Audio
Bluetooth & WirelessGIGABIT LAN & WIRELESS INTEL® Wi-Fi 6E AX211 (2.4 Gbps) 
+ BT 5.3
USB/Thunderbolt 1 x THUNDERBOLT 4 PORT + 3 x USB 3.2 PORTS
Keyboard Language   RECOIL 16 SERIES RGB BACKLIT UK KEYBOARD
Operating SystemWindows 11 Professional 64 Bit - inc. Single Licence
Notebook Mouse  LOGITECH WIRELESS MOUSE M510
Webcam  INTEGRATED 1MP HD WEBCAM




-- Package-specific info:
** Version:
Linux version 6.1.0-17-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-17-amd64 
root=UUID=b2a6dfe8-a825-4f45-bc0f-d6768d6f5db2 ro quiet

** Not tainted

** Kernel log:
[6.218497] iwlwifi :00:14.3 wlo1: renamed from wlan0
[6.414427] usb 1-14: new full-speed USB device number 9 using xhci_hcd
[6.427507] EXT4-fs (nvme1n1p1): mounted filesystem with ordered data mode. 
Quota mode: none.
[6.443558] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input31
[6.443615] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input32
[6.443792] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input33
[6.443938] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input34
[6.445172] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input35
[6.445564] input: HDA Intel PCH HDMI/DP,pcm=9 as 
/devices/pci:00/:00:1f.3/sound/card0/input36
[6.451101] EXT4-fs (nvme1n1p4): mounted filesystem with ordered data mode. 
Quota mode: none.
[6.506822] audit: type=1400 audit(1707398432.452:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=975 comm="apparmor_parser"
[6.506901] audit: type=1400 audit(1707398432.452:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=973 c

Bug#1055246: kde-config-plymouth: Does not appear in system settings

[Luke W Faraone]

Package: kde-config-plymouth
Version: 5.27.8-1
Severity: normal
X-Debbugs-Cc: lfara...@debian.org

Despite having Plymouth installed, no "Boot Splash Settings" panel appears in
KCM, contrary to what is shown in https://screenshots.debian.net/package/kde-
config-plymouth


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

Kernel: Linux 6.5.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-config-plymouth depends on:
ii  kio  5.107.0-1
ii  libc62.37-12
ii  libkf5archive5   5.107.0-1
ii  libkf5authcore5  5.107.0-1
ii  libkf5configcore55.107.0-1
ii  libkf5coreaddons55.107.0-1
ii  libkf5i18n5  5.107.0-1+b1
ii  libkf5kiocore5   5.107.0-1
ii  libkf5newstuffcore5  5.107.0-1
ii  libkf5quickaddons5   5.107.0-1
ii  libqt5core5a 5.15.10+dfsg-4
ii  libqt5gui5   5.15.10+dfsg-4
ii  libqt5qml5   5.15.10+dfsg-2
ii  libstdc++6   13.2.0-5
ii  plasma-framework 5.107.0-1
ii  qml-module-org-kde-kquickcontrolsaddons  5.107.0-1
ii  systemsettings   4:5.27.8-1

kde-config-plymouth recommends no packages.

kde-config-plymouth suggests no packages.

-- no debconf information

Bug#1054875: /usr/bin/add-apt-repository: python3-launchpadlib required for apt-add-repository

[Luke W Faraone]

Package: software-properties-common
Version: 0.99.30-4
Severity: normal
File: /usr/bin/add-apt-repository
X-Debbugs-Cc: lfara...@debian.org

Using the apt-add-repository command with a Launchpad PPA produces this
unhelpful error:

$ sudo add-apt-repository ppa:yuezk/globalprotect-openconnect
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 362, in 
sys.exit(0 if addaptrepo.main() else 1)
  ^
  File "/usr/bin/add-apt-repository", line 345, in main
shortcut = handler(source, **shortcut_params)
   ^^
  File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line
40, in shortcut_handler
return handler(shortcut, **kwargs)
   ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 86, in
__init__
if self.lpppa.publish_debug_symbols:
   ^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 126, in
lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
  ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 113, in
lpteam
self._lpteam = self.lp.people(self.teamname)
   ^^
AttributeError: 'NoneType' object has no attribute 'people'

I understand that adding a PPA is not a "supported" operation in Debian, but at
the very least a hint for the needed package should be displayed.


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

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages software-properties-common depends on:
ii  ca-certificates  20230311
ii  gir1.2-glib-2.0  1.78.1-1
ii  gir1.2-packagekitglib-1.01.2.7-1
ii  packagekit   1.2.7-1
ii  python-apt-common2.6.0
ii  python3  3.11.4-5+b1
ii  python3-dbus 1.3.2-5
ii  python3-gi   3.46.0-1
ii  python3-software-properties  0.99.30-4

software-properties-common recommends no packages.

software-properties-common suggests no packages.

-- no debconf information

Bug#1036796: gwenview: Gwenview fails to show any app icons or thumbnails on fresh install

[Luke Reeves]

Package: gwenview
Version: 4:22.12.3-1
Severity: important
X-Debbugs-Cc: luke.ree...@gmail.com

On a fresh bookworm install gwenview (with no existing configuration)
fails to render any of the in-app icons or thumbnails for directories or
images. This is reproducable across the i3 and xfce4 windowing
environments as well as the app itself forwarded on an X-over-SSH
connection.

This could be from not having the full KDE environment being installed
but I assumed the app would still install requirements.

gwenview is still usable to an extent but much slower to navigate with
all the missing UI and images.

Note I have the nvidia drivers for CUDA stuff but the primary GPU is an
Intel iGPU (and as mentioned this is reproducable over remote X
connections where the GPU is not involved).

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gwenview depends on:
ii  kinit  5.103.0-1
ii  kio5.103.0-1
ii  libc6  2.36-9
ii  libcfitsio10   4.2.0-3
ii  libexiv2-270.27.6-1
ii  libgcc-s1  12.2.0-14
ii  libjpeg62-turbo1:2.1.5-2
ii  libkf5activities5  5.103.0-1
ii  libkf5baloo5   5.103.0-2
ii  libkf5completion5  5.103.0-1
ii  libkf5configcore5  5.103.0-2
ii  libkf5configgui5   5.103.0-2
ii  libkf5configwidgets5   5.103.0-1
ii  libkf5coreaddons5  5.103.0-1
ii  libkf5filemetadata35.103.0-1
ii  libkf5guiaddons5   5.103.0-1
ii  libkf5i18n55.103.0-1
ii  libkf5iconthemes5  5.103.0-1
ii  libkf5itemmodels5  5.103.0-1
ii  libkf5itemviews5   5.103.0-1
ii  libkf5jobwidgets5  5.103.0-1
ii  libkf5kdcraw5  22.12.3-1
ii  libkf5kiocore5 5.103.0-1
ii  libkf5kiofilewidgets5  5.103.0-1
ii  libkf5kiogui5  5.103.0-1
ii  libkf5kiowidgets5  5.103.0-1
ii  libkf5notifications5   5.103.0-1
ii  libkf5parts5   5.103.0-1
ii  libkf5purpose-bin  5.103.0-1
ii  libkf5purpose5 5.103.0-1
ii  libkf5service-bin  5.103.0-1
ii  libkf5service5 5.103.0-1
ii  libkf5solid5   5.103.0-1
ii  libkf5widgetsaddons5   5.103.0-1
ii  libkf5xmlgui5  5.103.0-1
ii  libkimageannotator00.6.0-1
ii  liblcms2-2 2.14-2
ii  libphonon4qt5-44:4.11.1-4
ii  libpng16-161.6.39-2
ii  libqt5core5a   5.15.8+dfsg-10
ii  libqt5dbus55.15.8+dfsg-10
ii  libqt5gui5 5.15.8+dfsg-10
ii  libqt5printsupport55.15.8+dfsg-10
ii  libqt5svg5 5.15.8-3
ii  libqt5widgets5 5.15.8+dfsg-10
ii  libqt5x11extras5   5.15.8-2
ii  libstdc++6 12.2.0-14
ii  libtiff6   4.5.0-6
ii  libx11-6   2:1.8.4-2
ii  perl   5.36.0-7
ii  phonon4qt5 4:4.11.1-4

Versions of packages gwenview recommends:
ii  kamera 4:22.12.3-1
ii  kio-extras 4:22.12.3-1
ii  qt5-image-formats-plugins  5.15.8-2

gwenview suggests no packages.

-- no debconf information

Bug#1030043: hplip-gui: traceback when launching hp-toolbox

[Luke Diamand]

On Tue, 7 Feb 2023 21:52:11 -0600 Ryan Thoryk  wrote:

Changing line 119 in /usr/share/hplip/base/password.py
from:
get_distro_std_name(os_name)
to:
get_distro_name()

appears to fix the issue.


With this change I see a different error when running hp-check:

-Traceback (most recent call last):
  File "/usr/bin/hp-check", line 861, in 
dep.core.init()
  File "/usr/share/hplip/installer/core_install.py", line 523, in init
self.get_distro()
  File "/usr/share/hplip/installer/core_install.py", line 661, in 
get_distro

if 'MX' in distro_release_name:
   ^^^
NameError: name 'distro_release_name' is not defined

Looking at the code, distro_release_name really just is not present in 
that file anywhere that I can see.







--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: closed by Sylvestre Ledru (Re: Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

[Luke Kenneth Casson Leighton]

ah!

some fascinating news (from another discussion) pulled up the fact
that ADA converted to a Certification Mark, back in 1987

http://archive.adaic.com/pol-hist/policy/trademrk.txt

In order to be a validated Ada compiler, a compiler must pass an extensive
suite of programs called the Ada Compiler Validation Capability (ACVC).  The
AJPO has adopted a certification mark to show that a compiler has passed the
ACVC and is a validated compiler or a compiler derived from a validated base
compiler as defined in the Ada Compiler Validations Procedures and Guidelines
(version 1.1 of which was issued in January 1987).  The certification mark may
also be used on certain literature accompanying or documenting a validated
compiler.  Information concerning the proper use of the certification mark was
distributed to interested parties during the summer of 1987.

*that* is what the Rust Foundation *should* be doing.
messing about prohibiting patching is going to end in tears.

if they instead state, "You must run the Test Suite (unmodified, as provided by
us), and it the results are a 100% pass then you're free and clear to distribute
without limitation [and use the word "rust"] in the distributed package"

then *that* would solve all of the problems.

unfortunately, as i said in comment #40
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#40

if the Rust Foundation tries right now to convert the Trademark into a
Certification Mark it will be DENIED because they are selling product
(hats, T-shirts) and a Certification Mark Holder cannot compete with
its Licensees.

if they stop selling T-shirts and Merchandise and give assurances to
the Trademark Office that they will not do so then they should be ok
to convert to a Certification Mark.

l.

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: closed by Sylvestre Ledru (Re: Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

[Luke Kenneth Casson Leighton]

On Mon, Jul 18, 2022 at 11:06 AM Sylvestre Ledru  wrote:
>
> This bug is fixed.

i can see that you believe that to be true, otherwise you would
not have closed it.

what i am upset by is that you did not consider my opinion or
insight to be worth consulting.

i am deeply offended by that.

l.

Bug#1013920: closed by Sylvestre Ledru (Re: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

[Luke Kenneth Casson Leighton]

reopen 1013920

sorry, Sylvestre, if you could possibly wait, on something this serious,
for a response as to whether the fix is valid, that will avoid me having
to spend my time reopening the issue or creating a second bugreport.

On Mon, Jul 18, 2022 at 10:21 AM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the rust-all package:
>
> #1013920: rust-all: Debian violating Rust Trademark (as serious a situation 
> as "iceweasel")
>
> It has been closed by Sylvestre Ledru .

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Jul 18, 2022 at 10:16 AM Sylvestre Ledru  wrote:
>
> Thanks for bringing it to our attention, I have consulted with the Rust
> foundation, we have agreed a change, we think this change solves it.

ah! we may have just had some cross-over.

> See
> https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/
> for the updated policy.

did you mean the sections "fixing local paths" (etc)?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#60

no, that would not be sufficient.  it still violates DFSG (most of it).

there is also the issue that even placing a public copy of source
code on a git repository also constitutes "Distribution".

i gave some suggestions which would be much more reasonable
(and general) already, they may have been missed:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#40

those much more general statements basically say

"we trust you not to do any damage under our name"

the new additions basically say:

"you're clearly too stupid to be trusted so we're going to
 lock out your rights"

it should therefore come as no surprise that trying to go in
that direction would directly conflict with everything that DFSG
strives towards.

l.

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[Luke Kenneth Casson Leighton]

i've opened up a second bug for gcc because it is also about to
become affected, not in the same way, but in a worse way.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015242

whilst 50% of DFSG 2 is violated by the Rust Trademark
(as it stands, with the new clauses), gcc is in an even worse
situation because the Rust Trademark conficts directly with
the GPL as well.

this is a complex multi-faceted issue: please do not close the
bugreport until all facets of the conflict brought to your attention
have been resolved.

or... you can... but that will force me into the position of re-raising
another report, and i am too busy to do that, and you risk me
giving up and not caring.

l.

Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[Luke Kenneth Casson Leighton]

https://developers.slashdot.org/story/22/07/17/0110250/gcc-rust-approved-by-steering-committee-beta-likely-next-april

and now it becomes Unlawful for Debian to distribute gcc with patches,
as well [without the explicit consent of the Mozilla Foundation, an action
which is in direct violation of DFSG]

l.

Bug#1003824: Difference in current filename packaging conventions leads to downloads being ignored by apt

[Luke Ross]

I also experience this problem; after running debdelta-upgrade I use
this snippet (all on one line; not elegant) to fix up the files so that
apt can find them:

for i in /var/cache/apt/archives/*%*; do sudo mv -n "$i" `perl -e
'$ARGV[0] =~ s/%(2b|7e)/chr(hex($1))/ge; print $ARGV[0]' "$i"`; done

The affected characters, for me, are %2b (+) and %7e (~).

Bug#993957: closed by Christoph Biedl (Re: Bug#993957: (no subject))

[Luke Kenneth Casson Leighton]

On Sun, May 29, 2022 at 12:16 PM Debian Bug Tracking System
 wrote:

> #993957: schroot: fails with non-existent subdirectory
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Christoph Biedl 
>  by
> replying to this email.

christoph has misunderstood that i have provided the repro circumstances:
sysvinit is required to be installed and utilised before this bug will occur.

with sysvinit being a supported debian boot mechanism the closure
of this bugreport is not the correct action to take.

this bug is not unreproducible: the declaration that it is unreproducible
is invalid.

l.

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[Luke Kenneth Casson Leighton]

well, i just checked after upgrading to 3.6.11-2 and the repository
in question has now *entirely disappeared* from the config!

i've had to downgrade to 3.6.6-1 to get things functional
(it's a live-running server)

this does actually work, so during scheduled downtime
moments i can switch to the broken version (3.6.11-2)
and find out what the heck is going on.

l.

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[Luke Kenneth Casson Leighton]

i've created a test account, stupidly upgraded first so i cannot check
the "broken" case.

i will therefore use the original account with the underscore, however
i need to ask a 3rd  party to run the ssh command.

the setup i have is quite comprehensive, 30 ssh keys 25 projects, it
may be an interaction between them.

l.

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[Luke Kenneth Casson Leighton]

Package: gitolite3
Version: 3.6.6-1
Severity: important
Tags: upstream

Dear Maintainer,

i have used gitolite3 for many years, this is the first time i have ever
had a major bug, and it involved a username with an underscore in it.
ssh to the server reported "hello user" not "hello user_", and
COMPLETELY the wrong repository was granted write access.

this is an extremely serious security issue.


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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gitolite3 depends on:
ii  adduser  3.115
ii  debconf [debconf-2.0]1.5.61
ii  git [git-core]   1:2.29.2-1~bpo10+1
ii  libjson-perl 2.90-1
ii  openssh-client   1:7.4p1-11.0nosystemd1
ii  openssh-server [ssh-server]  1:7.4p1-11.0nosystemd1
ii  perl 5.28.1-6

gitolite3 recommends no packages.

Versions of packages gitolite3 suggests:
pn  git-daemon-sysvinit  
ii  gitweb   1:2.29.2-1~bpo10+1

-- debconf information excluded

Bug#986887: linux-image-5.10.0-5-amd64: mpt3sas driver fails to initialize drives on LSI SAS2116 chipset without a queue depth workaround

[Luke Reeves]

Package: src:linux
Version: 5.10.26-1
Severity: important
Tags: upstream
X-Debbugs-Cc: luke.ree...@gmail.com

Dear Maintainer,

I've upgraded from Buster to Bullseye and my external drive array using an LSI 
SAS2116 chipset (and the mpt3sas driver) stopped detecting all drives. There 
were no error messages discernable but in the output of lspci -vv there was now 
a missing line about "driver in use". After a bunch of digging I found other 
people had mitigated this issue by clamping down the maximum queue depth 
configured for the card. Adding the kernel parameter 
"mpt3sas.max_queue_depth=1" made all the drives appear again after a reboot.

Note that this report is tained with ZFS but I also tested with a clean boot 
and no dkms-built modules loaded to verify the issue.

-- Package-specific info:
** Version:
Linux version 5.10.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.26-1 (2021-03-27)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-5-amd64 
root=UUID=4a6cca79-4f72-4c12-b6e4-3e3aa93f8562 ro mpt3sas.max_queue_depth=1 
i915.force_probe=4c8b

** Tainted: PUOE (12353)
 * proprietary module was loaded
 * taint requested by userspace application
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends International, LLC.
bios_version: P1.70
board_vendor: ASRock
board_name: B560M Pro4
board_version:

** Loaded modules:
xt_nat
xt_tcpudp
veth
btrfs
blake2b_generic
ufs
qnx4
hfsplus
hfs
cdrom
minix
msdos
jfs
xfs
dm_mod
xt_conntrack
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack_netlink
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
xfrm_user
xfrm_algo
nft_counter
xt_addrtype
nft_compat
nf_tables
br_netfilter
nfnetlink
overlay
rfkill
bridge
stp
llc
binfmt_misc
intel_rapl_msr
intel_rapl_common
x86_pkg_temp_thermal
intel_powerclamp
kvm_intel
iTCO_wdt
kvm
intel_pmc_bxt
iTCO_vendor_support
intel_wmi_thunderbolt
wmi_bmof
efi_pstore
pcspkr
watchdog
ee1004
nls_ascii
nls_cp437
vfat
fat
zfs(POE)
zunicode(POE)
zzstd(OE)
zlua(OE)
zavl(POE)
icp(POE)
zcommon(POE)
znvpair(POE)
spl(OE)
joydev
mei_me
mei
sg
evdev
intel_pmc_core
acpi_pad
acpi_tad
hwmon_vid
coretemp
msr
fuse
configfs
sunrpc
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
vfio_pci
vfio_virqfd
vfio_iommu_type1
vfio
irqbypass
sd_mod
ses
t10_pi
enclosure
crc_t10dif
crct10dif_generic
hid_logitech_hidpp
hid_logitech_dj
hid_generic
usbhid
hid
i915
crct10dif_pclmul
crct10dif_common
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
i2c_algo_bit
ahci
drm_kms_helper
libahci
xhci_pci
aesni_intel
xhci_hcd
cec
libaes
mpt3sas
libata
drm
e1000e
crypto_simd
raid_class
scsi_transport_sas
usbcore
scsi_mod
ptp
cryptd
glue_helper
i2c_i801
pps_core
i2c_smbus
usb_common
wmi
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4c53] (rev 01)
Subsystem: ASRock Incorporation Device [1849:4c53]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  (32-bit, non-prefetchable)
Expansion ROM at 

00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:4c01] (rev 01) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:4c8b] 
(rev 04) (prog-if 00 [VGA controller])
Subsystem: ASRock Incorporation Device [1849:4c8b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:08.0 System peripheral [0880]: Intel Corporation Device [8086:4c11] (rev 01)
Subsystem: ASRock Incorporation Device [1849:4c11]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:14.0 USB controller [0c03]: Intel Corporation Device [8086:43ed] (rev 11) 
(prog-if 30 [XHCI])
Subsystem: ASRock 

Bug#718272: Processed: reopening 718272

[Luke Dashjr]

FWIW, I brought this up at our weekly developer meeting, and there was also 
another concern about apt upgrades across softforks: It could be problematic 
to not deploy a softfork, and problematic to deploy one without the user's 
consent.

I think I recall Debian has a way for packages to interactively prompt the 
user during upgrade. Maybe if softforks were turned into a runtime option, 
that could resolve that issue. What do you think?

For reference, the meeting log:

https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-01-07-19.00.moin.txt

Luke


On Thursday 07 January 2021 18:24:39 Jonas Smedegaard wrote:
> Quoting Luke Dashjr (2021-01-07 18:26:43)
>
> > We (upstream) already elaborated many years ago, copied here:
> >
> > http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and
> >-bitcoin.md.asc
> >
> > At a minimum, to be safe, Debian would need to:
> >
> > 1) Either:
> > 1a) Build with the bundled LevelDB statically linked.
> > 1b) Guarantee LevelDB package remains consensus-compatible, including NOT
> > fixing any bugs without a proper consensus-compatibility audit.
> > 2) Backport (at least) security fixes for Debian's security support
> > period. Upstream, we generally only maintain releases for a year or so at
> > most.
>
> Thanks for your input on upstream position on this matter, Luke, and in
> particular this condensed summary.  It is helpful for Debian to make its
> decision.
>
>
>  - Jonas

Bug#718272: Processed: reopening 718272

[Luke Dashjr]

We (upstream) already elaborated many years ago, copied here:

http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md.asc

At a minimum, to be safe, Debian would need to:

1) Either:
1a) Build with the bundled LevelDB statically linked.
1b) Guarantee LevelDB package remains consensus-compatible, including NOT
fixing any bugs without a proper consensus-compatibility audit.
2) Backport (at least) security fixes for Debian's security support period.
   Upstream, we generally only maintain releases for a year or so at most.

Luke


On Thursday 07 January 2021 13:51:50 Jonas Smedegaard wrote:
> Quoting Debian Bug Tracking System (2020-12-27 19:33:02)
>
> > Processing commands for cont...@bugs.debian.org:
> > > reopen 718272
> >
> > Bug #718272 {Done: Jonas Smedegaard } [src:bitcoin]
> > upstream does not support stable releases (block migration to testing)
> > Bug reopened
> > Ignoring request to alter fixed versions of bug #718272 to the same
> > values previously set
> >
> > > thanks
> >
> > Stopping processing here.
> >
> > Please contact me if you need assistance.
>
> I consider Bitcoin suitable for release with stable Debian.
>
> If seciurity team or others disagree with that, then please elaborate on
> your concerns.
>
>
>  - Jonas

Bug#974563: corosync unable to communicate with pacemaker 1.1.16-1+deb9u1 which contains the fix for CVE-2020-25654

[Luke Hall]

On Sat, 14 Nov 2020 04:02:40 +0100 Markus Koschany  wrote:

Am Freitag, den 13.11.2020, 23:13 -0300 schrieb Alejandro Taboada:
> Hello Markus,
> 
> It doesn’t work. The output log is quite different. I throws a timeout and

> just at the end the “unprivileged client crmd”.
> See attached log.

I'm sorry but I uploaded an older version that missed a do_reply line. That's
why are you seeing timeouts now. Now I have uploaded the correct version from
my test server to https://people.debian.org/~apo/lts/pacemaker/


This update to buster went out over-night and didn't cause the same issues.

Start-Date: 2020-11-14  06:02:48
Commandline: /usr/bin/unattended-upgrade
Upgrade: pacemaker:amd64 (2.0.1-5, 2.0.1-5+deb10u1)
End-Date: 2020-11-14  06:03:13


OpenPGP_0xE92032F399E1C6EC.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#968666: electrum: exception which prevents startup "Non keyword-only attributes not allowed after..."

[Luke Kenneth Casson Leighton]

On Wed, Aug 19, 2020 at 3:29 PM Tristan Seligmann
 wrote:
>
> Control: tags -1 - upstream
> Control: forcemerge 968563 -1
>
> On Wed, 19 Aug 2020 at 14:48, lkcl  wrote:
> >
> > ValueError: Non keyword-only attributes are not allowed after a 
> > keyword-only attribute.  Attribute in question: Attribute(name='invoice', 
> > default=NOTHING, validator=None, repr=True, cmp=True, hash=None, init=True, 
> > metadata=mappingproxy({}), type=, converter=None, 
> > kw_only=False)
>
> This is a consequence of #968563; upgrading python3-attr should fix it.

the normal approach to this would be to release a version of the
electrum packaging that specifically depends on that specific version
of python3-attr or above. the following to go into debian/control:

Depends: python3-attr >= 19.3.0-5

l.

Bug#968666: electrum: exception which prevents startup "Non keyword-only attributes not allowed after..."

[Luke Kenneth Casson Leighton]

On Wed, Aug 19, 2020 at 6:34 PM Tristan Seligmann
 wrote:

> > the normal approach to this would be to release a version of the
> > electrum packaging that specifically depends on that specific version
> > of python3-attr or above. the following to go into debian/control:
>
> Yes, the next upload will fix this as well as some other dependency issues.

fantastic, thanks tristan.

l.

Bug#962501: Unable to Reproduce

[Luke Mezera]

I have reinstalled my system, and I no longer can reproduce this issue.


-- 
Luke Mezera

Bug#962501: gnome-terminal: Closing a terminal window at a root promt will crash the Gnome session.

[Luke Mezera]

Package: gnome-terminal
Version: 3.30.2-2
Severity: normal

Closing a terminal window at a root prompt will crash the Gnome session.
   * What led up to the situation?
 Open a Gnome-Terminal window
 sudo su -
 close window
 Click "Close Terminal" on the "Close this terminal?" dialog box


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 If you remember to exit to your user prompt it will not crash.


   * What was the outcome of this action?
 I think it crashes the gnome-session.

 On wayland it will crash everything and locks up the computer.
 You can't even cntl+alt+fn key to another console

 On X it seems to restart the session. The screen freezes for
 a couple of seconds and comeback.



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

Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.1-2
ii  gnome-terminal-data   3.30.2-2
ii  gsettings-desktop-schemas 3.28.1-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libdconf1 0.30.1-2
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libuuid1  2.33.1-0.1
ii  libvte-2.91-0 0.54.2-2
ii  libx11-6  2:1.6.7-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.38.1-5
ii  nautilus-extension-gnome-terminal  3.30.2-2
ii  yelp   3.31.90-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#958723: ninja-build: ninja -t browse broken due to upstream bug; patch available

[luke]

Package: ninja-build
Version: 1.10.0-1
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

   `ninja -t browse` fails with a python backtrace due to a python2/3 bug
   upstream whereby `cgi.quote` was removed from python3.8 and causes
   downstreams using 3.8 to crash.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 I rebuilt ninja from source after applying the recent upstream fix, and
 ninja now appears to work correctly.

I suspect that backporting the upstream patch in 4d744de should be sufficient
without needing to wait for the upstream stable release which includes it.

All the Best

Luke


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ninja-build depends on:
ii  libc6   2.30-4
ii  libstdc++6  10-20200418-1

ninja-build recommends no packages.

Versions of packages ninja-build suggests:
ii  python3  3.8.2-3

-- no debconf information

Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)

[Luke Kenneth Casson Leighton]

On Sun, Apr 19, 2020 at 1:36 PM Debian Bug Tracking System
 wrote:

> #958166: python3-all: python3 can't import gmpy2
> Python3.7 is no longer supported in Debian Unstable and Testing and will be 
> removed shortly.

if you were talking about python 3.6, there would be absolutely no
problem, because python 3.6 is not the default version of python3
that's installed in the current LTS stable release (debian 10).

the fact that python 3.7 is the default LTS stable *and is being
removed* leaves an extremely serious situation for anyone that
attempts to dist-upgrade from debian 10 to debian 11.

that was the lesson learned - the mistake made - by the ubuntu team,
made all the more serious that the entire apt packaging system was
critically dependent on a version of python that was *being removed*
(!!)

forget for one moment that i'm using debian/testing (which you should
not in any way find it "acceptable" to callously dismiss people in the
position that i am in such an unthinking fashion) - people doing
*stable* dist-upgrades will end up with broken systems.

and it's part of debian that stable-to-stable dist-upgrades must
*always work*, ok?  you should know this.

and *that* is why i raised this as a critical bugreport, ok?

*please think* before arbitrarily closing critical bugreports, ok?

l.

Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)

[Luke Kenneth Casson Leighton]

here is a package that contains a build system that, unlike the
python3-numpy team, relies exclusively on python3-all.  like
python3-gmpy2, note that it does not contain enumeration of the minor
versions of python.  its control file does not list multiple versions
of python3, either, choosing instead to rely on the macros.

thus this particular package is critically subject to your arbitrary
and unthinking "whims", where python3-numpy is not.

i strongly suggest that you investigate precisely and exactly what
happened, historically, when ubuntu tried to do what you are forcing
onto people in an unthinking and inconsiderate way.

l.


rules-pythonmagick
Description: Binary data

Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)

[Luke Kenneth Casson Leighton]

you do realise, scott, that python3-numpy has been forced into a
position of bypassing the careless unthinking decision that you've
made, by including the capability to manually enumerate and compile up
multiple versions for different versions of python3?

instead of closing the bugreport and making a callous "declaration",
you could instead have said,

"um, that's really strange, because we have done this several times in
the past.  what do *you* think makes this situation different, which
warrants a critical bugreport status?"

and we could have worked TOGETHER to find the answer.

people don't raise critical bugreports without good justification,
scott.  it's the first time i've ever considered it, in over 16 years
of continuously using debian.

would you like to reconsider, or do i have to escalate this further?

l.


On Sun, Apr 19, 2020 at 1:36 PM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the python3-all package:
>
> #958166: python3-all: python3 can't import gmpy2
>
> It has been closed by Scott Kitterman .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Scott Kitterman 
>  by
> replying to this email.
>
>
> --
> 958166: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958166
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Scott Kitterman 
> To: 958166-d...@bugs.debian.org
> Cc: 958...@bugs.debian.org
> Bcc:
> Date: Sun, 19 Apr 2020 12:32:31 +
> Subject: Re: [Python-modules-team] [critical] #958166 - python3-all has had 
> python3.7 removed
> Alternately, you could just update python3-gmpy2 to the latest version of the 
> package, which is built to support python3.8:
>
> https://packages.debian.org/sid/amd64/python3-gmpy2/filelist
>
> Python3.7 is no longer supported in Debian Unstable and Testing and will be 
> removed shortly.
>
> What you are observing is a perfectly normal transition to a newer version of 
> python3.  If such things bother you this much, you should probably stick to a 
> Debian Stable release.
>
> This is the 7th time we've done this for Python3.  It happens once or twice a 
> release cycle.  There's no bug at all here.
>
> Scott K
>
>
> -- Forwarded message --
> From: lkcl 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 19 Apr 2020 09:28:54 +0100
> Subject: python3-all: python3 can't import gmpy2
> Package: python3-all
> Version: 3.8.2-2
> Severity: important
>
> see #958043
>
> it has now become impossible to install python3-gmpy2.  however that
> is just one symptom of this serious issue.
>
> with python3-all no longer dependent on both python3.7 and python3.8,
> transitioning from python3.7 to python3.8 has just become a nightmare.
>
> with some packages being built that are dependent on 3.7 and some on 3.8,
> any packages which have dependencies that import from both sets during
> the transition will cause a serious install failure
>
>
>
> -- System Information:
> Debian Release: 8.1
>   APT prefers oldoldstable
>   APT policy: (500, 'oldoldstable'), (500, 'testing'), (500, 'stable'), (500, 
> 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages python3-all depends on:
> ii  python33.8.2-2
> ii  python3-distutils  3.8.2-2
> ii  python3.7  3.7.2-1
> ii  python3.8  3.8.2-1+b1
>
> python3-all recommends no packages.
>
> python3-all suggests no packages.
>
> -- no debconf information


rules
Description: Binary data

Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)

[Luke Kenneth Casson Leighton]

On Sun, Apr 19, 2020 at 1:36 PM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the python3-all package:
>
> #958166: python3-all: python3 can't import gmpy2
>
> It has been closed by Scott Kitterman .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Scott Kitterman 
>  by
> replying to this email.
>
>
> --
> 958166: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958166
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Scott Kitterman 
> To: 958166-d...@bugs.debian.org
> Cc: 958...@bugs.debian.org
> Bcc:
> Date: Sun, 19 Apr 2020 12:32:31 +
> Subject: Re: [Python-modules-team] [critical] #958166 - python3-all has had 
> python3.7 removed
> Alternately, you could just update python3-gmpy2 to the latest version of the 
> package, which is built to support python3.8:
>
> https://packages.debian.org/sid/amd64/python3-gmpy2/filelist
>
> Python3.7 is no longer supported in Debian Unstable and Testing and will be 
> removed shortly.

this is a serious mistake.  did you not read what i wrote?  did you
not learn from the lesson of ubuntu when it made the same mistake,
with apt depending on the version that was removed, at the time?

> What you are observing is a perfectly normal transition to a newer version of 
> python3.  If such things bother you this much, you should probably stick to a 
> Debian Stable release.

that's absolutely impossible.  i cannot believe that you are seriously
asking that people quotes stick to debian stable quotes as a quotes
solution quotes.

did you not read that i have over 5 million source code files on this
system?  did you imagine that as a software developer i would be
*able* to quotes use debian stable quotes?

software developers *need* to be able to use debian/testing, if
debian/stable does not do what they need.  expecting them to compile
up packages and custom-maintain vast swathes of packages from source
in /usr/local is hopelessly unrealistic and is precisely why distros
exist in the first place.

do you not understand how seriously cavalier and unthinking your response is?


> This is the 7th time we've done this for Python3.

that would explain why i have encountered problems like this in the past.

question.  was a version removed that happened to also be the "stable" version?

did you not read what i wrote?

> It happens once or twice a release cycle.

> There's no bug at all here.

that is false: what it means is that you do not understand the serious
consequences of the decision that's being made.

you have completely failed to acknowledge what i wrote, choosing
instead to selectively quote your own past experience.

not only that, you've closed this critical bugreport without a wider
consultation.

why did you do that?

l.

Bug#958166: severity 958166 critical

[Luke Kenneth Casson Leighton]

after some consideration, i realised that the removal of python3.7 as
a dependency from python3-all results in "unrelated software on the
whole system break", and that this is reminiscent of the critical
error made by ubuntu, over 10 years ago.

1 criticalmakes unrelated software on the system (or the whole system)
  break, or causes serious data loss, or introduces a security
  hole on systems where you install the package.

the steps to reproduce this are:

1. install debian 10 (which has python 3.7 as a dependency)
  https://packages.debian.org/buster/python3

2. install (for example) python3-gmpy2 which is dependent on version 3.7
  https://packages.debian.org/buster/python3-gmpy2

3. install N.E.Other python package which also specifically depends on
version 3.7
  but which has *NOT* yet been recompiled / upgraded in debian/testing for
  version 3.8

4. install a python package (named python-dualdep) which:
  (A) depends on python3-gmpy2
  (B) depends on python3-NEOther package from step 3

5. add debian/testing to /etc/apt/sources.list

6. apt-get install python3-gmpy2 to bring in the *NEW* version of
python3-gmpy2 which SPECIFICALLY now ONLY depends on python3.8
   https://packages.debian.org/testing/python3-gmpy2

7. the result is a completely broken system.

this is basically a repeat of the nightmare scenario / mistake that
ubuntu made 10+ years ago in the transition from python 2.5 to python
2.6.

upgrades from ubuntu *STABLE* resulted in the *REMOVAL* of python 2.5
(and all python packages)... actually during the upgrade process
(leaving no version of python with which to *continue* the upgrade
process), because due to the polarisation caused by some packages
being built for python 2.5 and some for python 2.6, it was impossible
to satisfy both at the same time.

the only "solution" for apt: REMOVE either the packages that depend on
python 3.7 OR remove the packages that depend on python 3.8
(in some cases this becomes impossible to do, resulting in a broken
system).

this is extremely serious and needs to be fixed as fast as possible,
before more packages get compiled up only depending on python 3.8.

in particular, if python3-numpy hits the debian repository whilst only
depending on python 3.8, having zero packages which support python 3.7
simultaneously whilst transitioning to python 3.8, i guarantee that
all hell will break loose, due to the sheer number of packages that
depend on it:

$ apt-cache rdepends python3-numpy | sort | uniq | wc
439

that's 439 ongoing dependencies, which would cause absolute chaos for
the entire scientific community, as their packages would fail to
properly transition over during a stable (debian 10) to stable (debian
11) upgrade.

at present (thank god) it is still depending on python3.7 and python 3.8
https://packages.debian.org/testing/python3-numpy

l.

Bug#958166: Processed: severity 958166 critical

[Luke Kenneth Casson Leighton]

https://alioth-lists.debian.net/pipermail/python-modules-team/2020-April/066373.html

we're starting to see additional evidence of the seriousness of this
one.  an attempt to (auto-) build python3-pythonmagick failed due to
libboost-python however i just attempted it myself, and:

* apt-get build-dep pulled in replacements for python3-all and
python3-dev (which no longer contain python3.7 or python3.6)
* the linker phase failed with "/usr/bin/ld: cannot find -l-lboost_python-py36"

this is supposed to be linking against *python3.8* (and *only* against
python 3.8).

even if i were to install libboost-python 3.7 (which i am certainly
not going to attempt because boost causes such massive problems) it
would still fail.

even if this build problem were to be "fixed" by the maintainers of
pythonmagick, the result would be the creation ONLY of a version of
python3-pythonmagick that could be installed for python 3.8.

a corresponding version that was safe for installation and use with
python 3.7 would *NOT BE BUILT*.

i cannot emphasise enough how much damage this is going to do to the
python eco-system - first for people using rolling debian/testing
systems and ultimately for people trying debian/10 to debian/11
apt-get dist-upgrades, if not fixed as fast as possible.

l.

Bug#958043: [critical] #958166 - python3-all has had python3.7 removed

[Luke Kenneth Casson Leighton]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958166

this is serious enough to bring to a wider audience's attention,
immediately.  just as happened over 10 years ago, a mistake made by
the ubuntu team making python-all depend on only a single version of
python has just been repeated, in debian.

the consequences are not immediately obvious however are beginning to
bleed through already.  the issue is *not* if a "fresh install" (in
this case of debian/testing) is carried out, it's if someone tries to
do a rolling-update.  i managed to catch this because i never do
apt-get dist-upgrade (or full reinstalls - never going to happen with
5 million source code files accumulated over 8 years).  instead i add
debian/testing and "on-demand" perform periodic apt-get installs which
will pull in required dependencies.

this allows me early detection the scenarios that would cause
stable-to-stable upgrades to FAIL, 100%, just as they did for the
ubuntu team when transitioning from python 2.5 to python 2.6.

with python3-all having had python 3.7 removed, c-based python3
packages are now being built that can NEVER be simultaneously
installed whilst python 3.8 is also installed on the same system.

likewise, if python 3.8 is ever also installed on the same system and
packages which *do* depend solely and exclusively on python 3.8 get
installed, if there are any dependencies further up the chain, one of
which depends on one c-module-based package compiled exclusively for
python 3.7 AND ONE WHICH DEPENDS ON 3.8, all hell will break loose.

i cannot emphasise enough how serious this will become if
python3-numpy gets recompiled and uploaded as only depending on python
3.8
https://packages.debian.org/testing/python3-numpy

right now - thank goodness - the current version in sid is dependent
on both 3.7 and 3.8:
https://packages.debian.org/sid/python3-numpy

martin points out that python3-all is critical in determining how
multi-python c-based module compilation works:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958043

thus, when python3-numpy is next recompiled, it's going to be for a
single version of python3.  with apt-cache rdepends showing 439
packages depending on python3-numpy, that's going to create absolute
havoc.

the versions of python3 that are in python3-all *must* cover at least
the current stable LTSes *right* the way through to the current
version of python.  with debian 10 being dependent on python 3.7, that
means it *must* stay in python3-all at least until debian 11 is
released.

if python 3.9 is ever included in debian/testing, then that means that
python3-all *must* depend on python 3.7, 3.8 *and* python 3.9.  the
last time this happened was (i think) debian 8, where python 2.4, 2.5
*and* 2.6 had to be included for a while.

i cannot emphasise enough how critical this is to rectify as fast as
possible before any further python3 c-based packages are compiled up,
mistakenly, for only the one version of python3.  the more that get
uploaded, the more reports will come in of package conflicts during
upgrades.

l.

Bug#958043: Acknowledgement (python3-gmpy2: import gmpy2 fails)

[Luke Kenneth Casson Leighton]

unfortunately, because of the way that python3-gmpy2 has been
compiled, attempting to install an older version FORCE removes (or
conflicts with) an existing installation of python 3.8.

therefore if, as many people will have, they are transitioning from
python 3.5 to 3.6, 3.6 to 3.7, 3.7 to 3.8, the way that python3-gmpy2
has been installed will cause serious problems, particularly if there
are other dependencies... which there are:

$ apt-cache rdepends python3-gmpy2
python3-gmpy2
Reverse Depends:
  python-gmpy2-doc
  python-gmpy2-common
  pyecm
  python3-ppl
  python3-mpmath
  python-gmpy2-common
  python3-mpmath
  python-gmpy2-common
  python3-mpmath
  python3-mpmath
  python-gmpy2-doc
  python-gmpy2-common

i'd therefore recommend upgrading the severity of this bugreport.

martin, can i suggest taking a look at this:
http://deb.debian.org/debian/pool/main/n/numpy/numpy_1.17.4-5.debian.tar.xz

and look at the debian/rules file.  it deliberately depends on *both*
python3.7 and python3.7, followed by auto-detecting the versions
installed.  it has heavy dependence on c compilation so should work
absolutely fine



# apt-get install python3-gmpy2=2.1.0~a4-1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-gmpy2 : Depends: python3 (< 3.8) but 3.8.2-3 is to be installed
E: Unable to correct problems, you have held broken packages.


rules
Description: Binary data

Bug#955022: i915: Frequent graphics lockups; GPU HANG: ecode 9:1:0x00000000, hang on rcs0

[Luke Faraone]

Package: src:linux
Version: 5.4.19-1
Severity: important

Multiple times a day, my graphical session will freeze. If I'm in a video call,
sometimes the audio continues, other times it breaks into a loop. Sometimes
recoverable with SAK, so I can continue without rebooting after waiting a bit. 

I don't have a definite reproduction case; sometimes it will be fine for a day
or so, or today, where it happened twice, most recently <45m after boot.
Appears to be more likely when switching virtual workspaces in SwayWM
(Wayland), and always appears to be mid-render of a graphics effect from a
video or an image transition.

I believe this started with 5.4.0-4-amd64[1], I don't recall it happening
before I updated from 5.4.0-3-amd64 earlier this month.

I suspect this is the same issue as this upstream bug[3], which indicates it's
fixed in 5.5, and it looks like Ubuntu backported this to 5.4[4].

Attached are ``/sys/class/drm/card0/error`` for the last two crashes. 

[1]: 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200203 
(Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)
[2]: 5.4.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200117 
(Debian 9.2.1-24)) #1 SMP Debian 5.4.13-1 (2020-01-19)
[3]: https://gitlab.freedesktop.org/drm/intel/issues/673
[4]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861395

Please let me know if there's any additional information I can provide.

Cheers,
Luke Faraone

-- Package-specific info:
** Version:
Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)

** Command line:
BOOT_IMAGE=/vmlinuz-5.4.0-4-amd64 root=/dev/mapper/debvg-root ro quiet 
cgroup_enable=memory

** Not tainted

** Kernel log:
[ 1647.162227] hid-generic 0003:1050:0116.0013: input,hidraw4: USB HID v1.10 
Keyboard [Yubico Yubikey NEO OTP+U2F+CCID] on usb-:00:14.0-8.1/input0
[ 1647.163235] hid-generic 0003:1050:0116.0014: hiddev1,hidraw5: USB HID v1.10 
Device [Yubico Yubikey NEO OTP+U2F+CCID] on usb-:00:14.0-8.1/input1
[ 1652.879527] usb 1-8.1: USB disconnect, device number 13
[ 2548.286765] usb 1-8.1: new full-speed USB device number 14 using xhci_hcd
[ 2548.397134] usb 1-8.1: New USB device found, idVendor=1050, idProduct=0116, 
bcdDevice= 3.42
[ 2548.397136] usb 1-8.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[ 2548.397137] usb 1-8.1: Product: Yubikey NEO OTP+U2F+CCID
[ 2548.397138] usb 1-8.1: Manufacturer: Yubico
[ 2548.414445] input: Yubico Yubikey NEO OTP+U2F+CCID as 
/devices/pci:00/:00:14.0/usb1/1-8/1-8.1/1-8.1:1.0/0003:1050:0116.0015/input/input31
[ 2548.471349] hid-generic 0003:1050:0116.0015: input,hidraw4: USB HID v1.10 
Keyboard [Yubico Yubikey NEO OTP+U2F+CCID] on usb-:00:14.0-8.1/input0
[ 2548.472439] hid-generic 0003:1050:0116.0016: hiddev1,hidraw5: USB HID v1.10 
Device [Yubico Yubikey NEO OTP+U2F+CCID] on usb-:00:14.0-8.1/input1
[ 2558.098065] usb 1-8.1: USB disconnect, device number 14
[ 2564.230766] usb 1-2: new full-speed USB device number 15 using xhci_hcd
[ 2564.380688] usb 1-2: New USB device found, idVendor=1050, idProduct=0407, 
bcdDevice= 4.37
[ 2564.380694] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2564.380697] usb 1-2: Product: Yubikey 4 OTP+U2F+CCID
[ 2564.380700] usb 1-2: Manufacturer: Yubico
[ 2564.386624] input: Yubico Yubikey 4 OTP+U2F+CCID as 
/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:1050:0407.0017/input/input32
[ 2564.443522] hid-generic 0003:1050:0407.0017: input,hidraw4: USB HID v1.10 
Keyboard [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-2/input0
[ 2564.444788] hid-generic 0003:1050:0407.0018: hiddev1,hidraw5: USB HID v1.10 
Device [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-2/input1
[ 2576.846425] usb 1-2: USB disconnect, device number 15
[ 2782.143185] i915 :00:02.0: GPU HANG: ecode 9:1:0x, hang on rcs0
[ 2782.144195] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2782.144965] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset request timed 
out: {request: 0001, RESET_CTL: 0001}
[ 2782.145079] i915 :00:02.0: Resetting chip for hang on rcs0
[ 2782.146848] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset request timed 
out: {request: 0001, RESET_CTL: 0001}
[ 2782.147606] [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset request timed 
out: {request: 0001, RESET_CTL: 0001}
[ 2790.143136] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2798.147163] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2800.127153] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2802.143165] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2804.127179] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2806.143162] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2808.127173] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[ 2810.143192] i915 :00:02.0: Resetting rcs0 for hang on r

Bug#949747: closed by Simon McVittie (Re: Bug#949747: gimp: dependency versions missing)

[Luke Kenneth Casson Leighton]

thank you simon, i've passed that on to christian.
l.

Bug#864997: DEP-5 copyright checker

[Luke Kenneth Casson Leighton]

[apologies i can't reply inline, very limited HTML mailer due to
seriously bandwidth/reliability-compromised internet connection]

hi felix,

violates my copyright by not containing my authorship assertion.  in
combination with no license file they should have contacted me for
permission to distribute.  whoops.  they *assumed* that because it was
in some other work that *was* licensed that it was "okay".

ironic, huh?

yes it's my work (entirely), yes, confirmed, GPLv2+ licensed.
("public domain" statements are *ineffective* due to the very annoying
Berne Convention).  the only modifications that people have made in
the copies that you can find online are to default paths (something
like that, it's been a while).

there is *one* annoying buglet in copyright_check.py: the search
mechanism i couldn't find a way to get it to go from the "root" level
using wildcards.  consequently, you have to use a copyright file that
specifies matches against files and subdirectories, *even if those are
wildcards*.

this is the primary reason why copyright_check.py doesn't "detect"
anything on lintian itself... because lintian's *own* copyright file
is a one-liner-wildcard-match.

a way to get round that would be to take one-liner-wildcard-match
files, do a sweep of the top-level root directory, and apply the
one-liner-wildcard-match to every single entry... *then* pass that
through to the algorithm.

no, god no, i'll never rewrite it in perl: perl is a "WORN" language -
write-once, read-never :)  i'm dead serious.  the readability is so
bad in perl, and the algorithm itself in copyright_check.py
sufficiently obtuse that it would be a... "inadviseable" combination
:)

those false positives look... err fun.  welcome to
arbitrary-pattern-matching against random human-written text: i used
qgrams to help with that, however, just as with when i was working for
Internet Security Systems and we were doing packet-pattern-recognition
it is *guaranteed* to be a losing battle that will *never* be
"complete" or "successful", please do bear that in mind, ok?

with many apologies, i have so much else going on: if you ping me
regularly and keep me interested in a conversation i will respond with
insights and so on (because i like copyright_check.py and the time it
saves), however i simply don't have time to take "initiative" if you
know what i mean, there.

thanks felix.

l.

On 12/14/19, Felix Lechner  wrote:
> Hi Luke,
>
>> so i wrote a program called copyright_check.py which covers every single
>> possibility of what is correctly matched, what is incorrectly matched,
>> and what is missing.
>
> That's great! I have been looking for such a tool.
>
>> copies of the original program are being made and distributed
>> arbitrarily.
>> one such copy (which ironically violates copyright) is here:
>> https://fossies.org/dox/drizzle-7.2.4-alpha/copyright__check_8py_source.html
>>
>> one version may also be found here:
>> https://github.com/jaredly/pyjamas/blob/master/contrib/copyright_check.py
>
> Does it violate your copyright or someone else's? I see an assertion
> of your authorship only in the second file. Neither file shows license
> terms.
>
> For Debian's benefit, would you please reply with a statement that the
> program is solely your work? Please also attach a copy (not a link) or
> alternatively, a pointer to a repository under your control. The copy
> you send must further include the terms of your DFSG-compliant license
> (preferably GPL-2+, which would be like Lintian) or a statement
> placing your work in the public domain. Thank you!
>
> Two more things: First, Lintian runs on Perl. Did you ever port your
> program to any other languages? Second, I plan to rework the copyright
> check, which has many open bugs. Please let me know if are interested
> in helping:
>
>
> https://salsa.debian.org/lintian/lintian/blob/master/checks/debian/copyright.pm
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=lintian
>
> Kind regards
> Felix Lechner
>

Bug#940701: nautilus-dropbox: diff for NMU version 2019.02.14-0.1

[Luke Faraone]

On Thu, 19 Sep 2019 at 08:24, Laurent Bigonville  wrote:
> I've prepared an NMU for nautilus-dropbox (versioned as 2019.02.14-0.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

Hi,

Please cancel this NMU. I'm unable to upload because this includes a
new orig.tar.bz. Note that I was engaging with Unit 193 on Mentors,
please check that before NMUing next time.

Cheers,
Luke Faraone

Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time

[Luke Faraone]

On 25/07/2019 15:45, Paul Gevers wrote:
>> Can you elaborate? I'm a little distracted by DebConf stuff but I
>> can't seem to grok what you mean here specifically.
> 
> https://qa.debian.org/excuses.php?package=python-django says this
upload
> will fix bug #931316 in testing. That bug is about CVE-2019-12781.
> Testing has not seen the fix yet, and due to the dropping of Python 2,
> it will take time before it does, as python-django can not migrate
> before reverse dependencies are fixed or removed.

That is just the excuses script's auto-generated output, I think you
might be reading too much into it. It is a true statement that when the
package makes it into testing, that bug will be fixed, unless I am
misunderstanding something.

The migration happened in a previous upload[1]:
 python-django (2:2.2.3-2) unstable; urgency=medium
* Upload (Python 3.x-only) branch to unstable after the release of
 Debian "buster".
   * Update debian/gbp.conf to refer to debian/sid after merge.

… so we did not drop Python3 just for a security update, despite this
bug's title.

> The latter isn't very
> nice for your reverse dependencies if you didn't give them proper
> heads-up. The former isn't nice for the python-django users of testing.

I do recall the discussion Chris mentioned, although I admit I can't
find the thread at the moment. (I'm also a bit busy with DebConf)

Note that testing is explicitly not recommended for those that care
about security support[2][3].

[1]:
https://tracker.debian.org/news/1042323/accepted-python-django-2223-2-source-all-into-unstable/
[2]: https://www.debian.org/security/faq#testing
[3]: https://wiki.debian.org/DebianTesting#Considerations

Cheers,
Luke Faraone



signature.asc
Description: OpenPGP digital signature

Bug#931710: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on askpass

[Luke Flinders]

Hi Guilhem,

This is the package;
https://gitlab.com/kalilinux/packages/cryptsetup-nuke-keys

seen as this is not a Debian related package causing the issue, I am happy if 
you want to close.

Kind regards,

Luke Flinders

-Original Message-
From: Guilhem Moulin  
Sent: 13 July 2019 03:46
To: Luke Flinders 
Cc: 931...@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on 
askpass

Hi,

On Wed, 10 Jul 2019 at 09:24:16 +, Luke Flinders wrote:
> So have done some more testing and it seems that the removal of 
> cryptsetup-nuke-password resolves the issue.

What is that?  There is no such package in Debian.

> I had however tested this before and had it all functioning.
> Hopefully this helps direct debugging a little better.

For what it's worth, since I wrote it I'm using `cryptroot-unlock` on a regular 
basis with src:cryptsetup from Stretch and Buster (and sid), and I never saw 
the issue you encounter.

--
Guilhem.

Bug#931710: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on askpass

[Luke Flinders]

Hi Guilhem,

So have done some more testing and it seems that the removal of 
cryptsetup-nuke-password resolves the issue.
I had however tested this before and had it all functioning.
Hopefully this helps direct debugging a little better.

Kind regards,

Luke Flinders

-Original Message-
From: Guilhem Moulin  
Sent: 09 July 2019 16:19
To: Luke Flinders 
Cc: 931...@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on 
askpass

On Tue, 09 Jul 2019 at 14:47:04 +, Luke Flinders wrote:
> cat /etc/crypttab
> sda5_crypt UUID=ec7880bc-c758-4681-8e94-b21f13752b48 none luks,discard

Is there an entry for ‘sda5_crypt’ in the initramfs' ‘/cryptroot/crypttab’?
And, is ‘/scripts/local-top/cryptroot’ running by the time you start 
`cryptroot-unlock`?

I don't see anything relevant in our diff between 2:2.0.6-1 and 2:2.1.0-5.  
Could you please start the script with `sh -x cryptroot-unlock` (also in the 
initramfs shell) and share the trace?

--
Guilhem.

Bug#931710: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on askpass

[Luke Flinders]

Hi Guilhem,

Yes it is being run from an initramfs shell, sorry for leaving that out.
Requested information is as follows;

cat /etc/crypttab
sda5_crypt UUID=ec7880bc-c758-4681-8e94-b21f13752b48 none luks,discard

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/kali--vg-root /   ext4errors=remount-ro 0   1
# /boot was on /dev/sda1 during installation
UUID=5264b2eb-3b0c-4b82-896b-c44b1dd5bae6 /boot   ext2defaults  
  0   2
/dev/mapper/kali--vg-swap_1 noneswapsw  0   0


Kind regards,

Luke Flinders

-Original Message-
From: Guilhem Moulin  
Sent: 09 July 2019 15:39
To: Luke Flinders ; 931...@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on 
askpass

Control: reassign -1 cryptsetup-initramfs 2:2.1.0
Control: tag -1 moreinfo

Hi,

On Tue, 09 Jul 2019 at 13:00:52 +, Luke Flinders wrote:
> Error message is;
> Error: Timeout reached while waiting for askpass
> 
> Command run is;
> cryptroot-unlock

Are you running `cryptroot-unlock` from an initramfs shell?  Could you please 
share your partitioning information (/etc/crypttab and /etc/fstab)?
The message suggests that there is no cryptsetup (askpass) prompt running at 
this time, so I'd like to see how the device stack unfolds at initramfs stage.

> The contents of this email message and any attachments are intended 
> solely for the addressee(s) and may contain confidential and/or 
> privileged information and may be legally protected from disclosure.

Just for the record, this bug tracker is public :-)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931710
https://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/2019-July/008324.html

Cheers,
--
Guilhem.

Bug#931710: Cryptroot-unlock Timeout on askpass

[Luke Flinders]

Package: cryptsetup
Version:2:2.1.0

Error message is;
Error: Timeout reached while waiting for askpass

Command run is;
cryptroot-unlock

kernel is;
4.19.37-5

C version;
2.28-10

I am pretty sure that the upgrade from cryptsetup 2:2.0.6 to the version above 
caused this issue.

Kind regards,

Luke Flinders
Security and Network Engineer
IP Performance Ltd
1-3 Merietts Court, Long Ashton Business Park,
Long Ashton, Bristol, BS41 9LW
Office: +44 1275 393382
24/7 Support: +44 8708 409100
Email : lflind...@ip-performance.co.uk<mailto:lflind...@ip-performance.co.uk>

[IPP Iogo newsmaller]

CONFIDENTIALITY NOTICE:
The contents of this email message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or privileged information and 
may be legally protected from disclosure. If you are not the intended recipient 
of this message or their agent, or if this message has been addressed to you in 
error, please immediately alert the sender by reply email and then delete this 
message and any attachments. If you are not the intended recipient, you are 
hereby notified that any use, dissemination, copying, or storage of this 
message or its attachments is strictly prohibited.

Bug#929927: python-django: CVE-2019-12308: AdminURLFieldWidget XSS

[Luke Faraone]

Yep, planning on tackling this evening. (PDT)

Per discussion with Security Team a DSA isn't warranted for this issue.

On Tue, 4 Jun 2019 at 10:11, Chris Lamb  wrote:

> [Adding lfara...@debian.org to CC]
>
> Salvatore Bonaccorso wrote
>
> > CVE-2019-12308[0]:
> > AdminURLFieldWidget XSS
> >
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> >
> > For further information see:
> >
> > [0] https://security-tracker.debian.org/tracker/CVE-2019-12308
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12308
> > [1] https://www.djangoproject.com/weblog/2019/jun/03/security-releases/
>
> Luke, do you still plan to take this as discussed during the embargo? I
> might have some bandwidth the next day or so if not, but let me know.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org  chris-lamb.co.uk
>`-
>


-- 

Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs; MIT SIPB
lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello
PGP fprint: 8C82 3DED 10AA 8041 639E  1210 5ACE 8D6E 0C14 A470

Bug#929709: libgdbm6: file exists in libgdbm-dev as well as gdbm

[Luke Kenneth Casson Leighton]

On Fri, May 31, 2019 at 5:09 AM Dmitry Bogatov  wrote:

> > Unpacking libgdbm-dev:amd64 (1.18.1-4) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb (--unpack):
> >  trying to overwrite '/usr/share/info/gdbm.info.gz', which is also in 
> > package libgdbm3:amd64 1.8.3-11
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb
>
> Issue, yes. But you are upgrading from rather old version of libgdbm3.
> According to https://tracker.debian.org/gdbm, it predates even
> old-stable.

 ah ok, not a problem then - i thought the existing version was more
recent than that, missed that it was 1.8 rather than 1.18.

l.

Bug#928190: /usr/bin/pip ImportError

[Luke Francis]

Package: python-pip
Version: 9.0.1-2+deb9u1

When I invoke `usr/bin/pip` i receive an error.

$ /usr/bin/pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in 
from pip import main
ImportError: cannot import name main

Changing `from pip import main` to `from pip._internal import main as main`
within `/usr/bin/pip` resolves the issue:

Started seeing this issue after updating
https://tracker.debian.org/news/1038095/accepted-python-pip-901-2deb9u1-source-all-into-proposed-updates-stable-new-proposed-updates/

I am using Debian stretch 9.9

Bug#915675: libasound2-data: Kernel 4.18 change breaks WD15 dock usb audio

[Luke W Faraone]

On Thu, 6 Dec 2018 08:36:30 +0100 Elimar Riesebieter wrote:
> * Angus Lees [2018-12-06 09:29 +1100]:
>
> [...]
> >
> > After *much* debugging, I stumbled across
> >
https://github.com/edrose/dell-dock-audio-fix/issues/2#issuecomment-440420105
> >
> > Apparently the device was renamed in the kernel, and
> > /usr/share/alsa/ucm/Dell-WD15-Dock/HiFi.conf needs to be updated
> > accordingly (s/WD15Dock/Dock/). I can confirm this change (followed
> > by pulseaudio restart) fixed things immediately for me.
>
> There is a patch in upstreams git. But we have to find a solution
> where kernels < 4.18 are working as well. Thats not that easy,
> though.

Since we're going with 4.19+ in Buster, if we can't find a config  that
work in both >/<4.18, would it make sense to ship the config that'll
work in the shipped kernel?

Cheers,

Luke Faraone



signature.asc
Description: OpenPGP digital signature

Bug#852199: Nix and non-standard-toplevel-dir

[Luke Faraone]

On Wed, 2 Jan 2019 at 20:28, Russ Allbery  wrote:
> If anything, they probably already know
> how Nix works and are expecting it to use those paths.  There doesn't seem
> to be much drawback in this carefully-chosen lack of compliance with the
> FHS.
>
> I don't think it's worth writing an explicit Policy exception for this,
> since it's a single edge case.  Instead, I think it's a good use of a
> Lintian override documenting what's going on.  Obviously, if Nix becomes
> really popular in the long run, we can then go back and write this into
> Policy.

This also is the case with snapd, which uses `/snap` in all other
distributions. We currently override it, but the issue was brought up
in a bug report.[1] I think the same arguments apply to both Nix and
snapd; but perhaps two is not yet numerous enough to warrant
documenting in policy.

[1]: http://bugs.debian.org/852199

Cheers,
Luke Faraone

Bug#911198: Browser console empty, all settings deactivated

[Luke Faraone]

On Thu, 1 Nov 2018 at 10:46, Carsten Schoenert  wrote:
> Am 17.10.18 um 12:59 schrieb Luke W Faraone:
> > Invoking with ``thunderbird --start-debugger-server`` and using the
> > Firefox WebIDE's remote debugger
>
> could you please give a small step by step how to reproduce your output.
> I'm not that familiar with using these tools. I even can't see any
> missing react stuff with 60.2.1 on the command line.

1. Start Thunderbird via ``thunderbird --start-debugger-server``
2. In Firefox, Menu -> Web Developer -> WebIDE
3. In the right column, under "Other" select "Remote Runtime"
4. Use default of ``localhost:6000``
5. In Thunderbird, click "OK" on the prompt "An incoming request to
permit remote debugging connection was detected. A remote client can
take complete control over your browser!"
6. In Firefox's WebIDE, click on "Main Process"
7. Click on "Console" in the web debugger below.
8. In Thunderbird, Menu -> Tools -> Developer Tools -> Error Console
9. See a blank EC.
10. Go back to Firefox's WebIDE, see error messages in the console.

I'll take a look at other possible causes as well in the next few days.
Cheers,
Luke Faraone

Bug#911198: Browser console empty, all settings deactivated

[Luke W Faraone]

found 909046 60.2.1-1
merge 909046 911198
thanks

On Wed, 17 Oct 2018 14:36:03 +1300 martin f krafft 
wrote:
> Package: thunderbird
> Version: 1:60.2.1-1
> Severity: normal
> 
> The "Browser Console" is empty, and all the checkboxes next to e.g.
> Logging (but also all the other menus) are unchecked. Clicking them
> has no effect. As a result, no messages appear whatsoever, and there
> seems to be nothing I can do about it.

Invoking with ``thunderbird --start-debugger-server`` and using the
Firefox WebIDE's remote debugger, I see the following in the error
console when opening up Thunderbird's error console:

Error: Module
`resource://devtools/client/shared/vendor/react-dom.js` is not found at
resource://devtools/client/shared/vendor/react-dom.js


It appears that #909046 was not in fact fixed. Some instances of the
removal were commented out, but others remain:

./source.filter:devtools/client/inspector/markup/test/lib_react_dom_15.4.1.js
./source.filter:devtools/client/inspector/markup/test/lib_react_with_addons_15.4.1.js
./source.filter:devtools/client/shared/vendor/react-dom-dev.js
./source.filter:devtools/client/shared/vendor/react-dom-server-dev.js
./source.filter:#devtools/client/shared/vendor/react-dom-server.js
./source.filter:#devtools/client/shared/vendor/react-dom.js
./source.filter:devtools/client/shared/vendor/react-prop-types-dev.js
./source.filter:devtools/client/shared/vendor/react-prop-types.js
./source.filter:#devtools/client/shared/vendor/react-redux.js
./source.filter:devtools/client/shared/vendor/react-test-renderer-shallow.js

Cheers,
Luke Faraone



signature.asc
Description: OpenPGP digital signature

Bug#909630: gitlab: no sysvinit scripts installed or available

[Luke Kenneth Casson Leighton]

On Wed, Sep 26, 2018 at 10:30 AM, Dmitry Smirnov  wrote:
> On Wednesday, 26 September 2018 3:05:32 PM AEST Luke Kenneth Casson Leighton
> wrote:
>> appreciated, dmitry: apologies, it catches me off-guard when things
>> don't work.
>
> No worries. It would be nice to introduce init scripts to GitLab.
> With your motivation it looks like it might actually happen. :)

 :)

>> it was just that the decision to rail-road systemd in
>
> Hold on here please. Using systemd as a default init system was well
> balanced, collective decision, thoroughly discussed with all pros and cons
> carefully considered.

 somewhere i have the post-analysis from the voting: i can't remember
off the top of my head, however if you look it up the records of the
votes clearly show that systemd was absolute dead-last in all respects
on all questions asked in the vote.

> You have to respect that.

 if the people who made the decision had respected the actual wishes
of the debian developers who voted, i would be tempted to agree...
however as a *user* i was not consulted about the consequences of the
decision... so i *genuinely* can't agree.

 i can *understand* why the decision was made...

> There is nothing unethical in choosing technically superior init system that
> suits most GNU/Linux distributions. We have made a choice and moved on -
> what's done is done and there is no point complaining about it.
>
>
>> (which is software that itself is being developed incredibly
>> unethically)
>
> I do not understand what do you mean.

 it's a long, long story, that takes quite a lot of time to explain
(and that's one of the problems: most people simply don't have time to
go over this, comprehensively).  perhaps it might be best to take this
offline from this bugreport, if you're interested to do so?

l.

Bug#909630: initscript found

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Sep 26, 2018 at 6:03 AM, Dmitry Smirnov  wrote:
> On Wednesday, 26 September 2018 2:10:09 PM AEST Luke Kenneth Casson Leighton 
> wrote:
>> https://gitlab.com/gitlab-org/gitlab-ce/raw/master/lib/support/init.d/gitlab
>
> Thanks, Luke. It could be a good starting point but IMHO this script can not
> be used as-is and it needs a lot of work...

 yeah i agree: it does however get things up and running (where there
was no service *at all* for about half an hour).

it definitely needs splitting down into separate services: i'll take a
look over the next few days.

> Instead of using sloppy init script you might find it useful to try
>
>   https://github.com/gdraheim/docker-systemctl-replacement

 the majority of services that i've deployed over the past 20+ years
typically have always had an initscript: it's quite rare not to find
any (at all).

 i know you didn't suggest it, i wouldn't recommend including (or
depending on) that package for this task: it may however prove useful
to submit as a WNPP/ITP.

 for solving the issue here of gitlab needing to start when systemd
isn't around (and sysvinit is), i'll help sort that by creating 4
initscripts, i think that's the best solution for gitlab.

l.

Bug#909630: gitlab: no sysvinit scripts installed or available

[Luke Kenneth Casson Leighton]

appreciated, dmitry: apologies, it catches me off-guard when things
don't work.  it was just that the decision to rail-road systemd in
(which is software that itself is being developed incredibly
unethically) - was itself made unethically (not thinking of the harm
that could result, and without wider consultation, and the
consultation that *was* done was completely ignored!).  *some* of the
damage has been undone by allowing sysvinit to be used.

i've sent in what i could find: it's nothing like the postinst script
expects, which is a series of 4 separate initscripts (that's very
strange, btw, that there's some code in the postinst that *expects*
the 4 /etc/init.d/gitlab- init scripts to be there), however i can
confirm that what i found actually works.

gitlab is very very resource-heavy, so if i make the decision to keep
it, i will definitely (need to) create separate initscripts, and will
send them in, ok?

good luck, and apologies for getting annoyed, i was really caught off-guard.

l.


---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Sep 26, 2018 at 4:51 AM, Dmitry Smirnov  wrote:
> On Wednesday, 26 September 2018 11:45:02 AM AEST lkcl wrote:
>> it would be really helpful if people could stop assuming that everyone
>> forcibly fucking wants systemd shoved at them.  and no, ordering people
>> to go use freebsd or devuan is not acceptable.
>>
>> for goodness sake please be a little more careful and considerate.
>> i'll try to track down some sysvinit scripts in a followup and post
>> them later.
>
> It would be polite not to assume that lack of SysV scripts is deliberate.
> There are not enough people involved into maintenance of such a complex
> package as GitLab and writing init scripts from scratch and maintaining them
> is not an easy task.
> Yes, your help would be appreciated if you care enough for init scripts to
> contribute them or to fund/sponsor someone who could write them.
>
> Until then systemd remains a viable option for those who have no systemd-
> fobia and wishes to run GitLab...
>
> --
> Cheers,
>  Dmitry Smirnov.
>
> ---
>
> It is impossible to imagine Goethe or Beethoven being good at billiards
> or golf.
> -- H. L. Mencken

Bug#909630: initscript found

[Luke Kenneth Casson Leighton]

https://gitlab.com/gitlab-org/gitlab-ce/raw/master/lib/support/init.d/gitlab

this is semi-suitable: at least it has been possible to get things up
and running, by removing the section starting "Script variable names"
and relying on the entries in /etc/default/gitlab that are absolutely
fine in the debian package

please for goodness sake do not assume that absolutely everyone is
happy to be forced to use systemd, it's incredibly unethical.

plus, sysvinit is still a legitimately-installed and supported *and
commonly-used" debian package.

l.

Bug#906027: shellcheck: unable to decommit memory: Invalid argument

[Luke Goodsell]

Package: shellcheck
Version: 0.4.4-4

In Debian 9, running shellcheck against a moderate-size file results in the 
error message

shellcheck: unable to decommit memory: Invalid argument

I can reproduce this with these commands:

docker run -it debian:9
apt-get -y update
apt-get -y install shellcheck
echo '#!/bin/bash' > test.sh; for i in $(seq 1000); do echo 'echo "hi"' >> 
test.sh; done
shellcheck test.sh
# shellcheck: unable to decommit memory: Invalid argument
# shellcheck: unable to decommit memory: Invalid argument
# shellcheck: unable to decommit memory: Invalid argument

Since shellcheck is used in CI tests and produces no output on success, these 
error messages shouldn't be present.

Uname: Linux 0b9a6fddbfc7 3.10.0-862.3.3.el7.x86_64 #1 SMP Fri Jun 15 04:15:27 
UTC 2018 x86_64 GNU/Linux
Libc6: Version: 2.24-11+deb9u3

Thanks in advance for your help.

This e-mail message contains confidential information intended only for the use 
of the individual or entity to which it is addressed. If you are not the 
intended recipient, please do not disseminate, distribute or copy this 
communication, by e-mail or otherwise. Instead, please notify us immediately by 
return e-mail and then delete and discard all copies of the e-mail. We have 
taken all reasonable precautions to check this e-mail and any attachments for 
viruses, but we cannot accept any liability for any damage sustained as a 
result of any virus, worm or other malicious software. Achilles Therapeutics 
Limited (10167668) is registered in England and Wales. The registered office is 
at Stevenage Bioscience Catalyst, Gunnels Wood Road, Stevenage SG1 2FX, UK.

Bug#905407: ssh-keygen: Use new OpenSSH key format by default

[Luke W Faraone]

Package: openssh-client
Version: 1:7.7p1-3
Severity: wishlist
File: /usr/bin/ssh-keygen

The bcrypt KDF key format was released as part of OpenSSH 6.5 in 2014.
It provides greater resistance against brute-force attacks on encrypted
private keys, and is now widely compatible.

We should use it by default. I'm happy to work on a patch if it would be
accepted.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 openssh-client depends on:
ii  adduser   3.117
ii  dpkg  1.19.0.5+b1
ii  libc6 2.27-5
ii  libedit2  3.1-20180525-1
ii  libgssapi-krb5-2  1.16-2
ii  libselinux1   2.8-1+b1
ii  libssl1.0.2   1.0.2o-1
ii  passwd1:4.5-1.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
ii  monkeysphere  0.41-1
ii  ssh-askpass-fullscreen [ssh-askpass]  0.3-3.1+b2

-- no debconf information

Bug#901006: closed by Ben Hutchings (Re: Bug#901006: linux-image-4.16.0-2-amd64: "core has locked up" kernel messagee)

[Luke Kenneth Casson Leighton]

On Fri, Jun 8, 2018 at 2:27 AM, Debian Bug Tracking System
 wrote:
> -- Forwarded message --
> From: Ben Hutchings 
> To: 901006-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 08 Jun 2018 02:24:57 +0100
> Subject: Re: Bug#901006: linux-image-4.16.0-2-amd64: "core has locked up" 
> kernel messagee
> Sorry, we can't do anything with this.

 that's ok, ben: the report was more fyi, as it's so unusual (never
seen anything like it before, didn't even know it was *possible* for
one single core on an SMP system to end up "frozen"), however it's
pretty highly indicative that whatever changes have gone into 4.16 are
clearly *completely* unsuited to being propagated for advancement to
debian/stable status.

l.

Bug#900930: CVE-2018-10057 CVE-2018-10058

[Luke Dashjr]

The severity is wrong on this. The first one is a very minor issue (only the 
admin can trigger it), and the second one is not a bug at all.

On Wednesday 06 June 2018 21:01:42 Moritz Muehlenhoff wrote:
> Package: bfgminer
> Severity: grave
> Tags: security
>
> http://www.openwall.com/lists/oss-security/2018/06/03/1

Bug#900377: git: Debian git package can now include git-p4 Perforce proxy

[Luke Diamand]

>>
>> Cool!  Is there a bug open to package p4 in Debian?
>
> Not as far as I know. I could start the ball rolling with a bug
> report. I guess the question is how many people would actually use it.

I've sent a support request to Perforce to see what they think of this.

The BSD license means they can't directly object, and they might want
to help out.

Bug#827844: git: man git: dead link

[Luke Diamand]

Bug 827844 seems to have been fixed upstream.

The link now in the man-page is:

https://git.github.io/htmldocs/git.html

Using git version 1:2.17.1-1.

It looks like it was fixed by Jonathan:

commit f79358279c4b447b1318a922e15705d2a00fc5a2 (origin/jn/preformatted-doc-url)
Author: Jonathan Nieder 
Date:   Wed Jun 22 10:38:25 2016 -0700

doc: git-htmldocs.googlecode.com is no more

Bug#900377: git: Debian git package can now include git-p4 Perforce proxy

[Luke Diamand]

On 29 May 2018 at 22:21, Jonathan Nieder  wrote:
> forcemerge 715534 900377
> quit
>
> Hi,
>
> Luke Diamand wrote:
>
>> Originally the Debian git package included this tool, but it was removed
>> in 2014 because - at the time - the Perforce command-line tool was non-free:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715534#10
>
> To be clear, what the Debian git package included before was a script
> of a few lines that said that git was built without support for
> Python.
>
> I don't believe the Debian git package ever included git-p4.
>
>> However, later that year, Perforce actually open-sourced a good deal of
>> their software, including the p4 command-line client which git-p4 relies
>> on:
>>
>> https://www.perforce.com/press-releases/perforce-open-sources-popular-version-control-tools
>>
>> The source can currently be found here:
>>
>> https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/
>>
>> and the license (as of the 2018-1 branch) is here:
>>
>> https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/2018-1/LICENSE
>>
>> That appears to be a standard BSD license (2-part).
>
> Cool!  Is there a bug open to package p4 in Debian?

Not as far as I know. I could start the ball rolling with a bug
report. I guess the question is how many people would actually use it.

>
>> I found that I could build the code on a recent Debian install with a
>> few small hacks (I think it assumes an older version of openssl than
>> that shipped with current Debian).
>>
>> Given this, I think git could once again include the git-p4 package.
>> That would be very useful for people in organizations where Perforce is
>> in use for version control, but who would prefer to use the standard git
>> frontend (and for whatever reason can't use Perforce's own git-fusion
>> tool).
>
> Thanks for the update.  Given this context, it certainly seems worth
> adding git-p4 to contrib for now, and to the main Debian repository
> once the perforce client is in Debian.  It's too bad the server isn't
> also open source, but as long as the protocol spec is open and
> implementable, that's not a reason not to include the client in
> Debian.

Thanks!

I think the git-p4 client is the thing that's really useful (at least
to people like me) but I've only very recently learned that the p4
client had been open-sourced.

Luke

Bug#884038: 884038: 2.15.x fails to fetch remote repository - introduced in d0c39a49ccb5dfe7feba4325c3374d99ab123c59?

[Luke Diamand]

I think this bug report may be about the same issue that I came across
a while back here:

https://www.spinics.net/lists/git/msg316628.html

I found that the problem was "introduced" in
d0c39a49ccb5dfe7feba4325c3374d99ab123c59, first released in 2.15.0 (as
also noted in the bug).

>revision.c: --all adds HEAD from all worktrees
>
>Unless single_worktree is set, --all now adds HEAD from all worktrees.

The problem shows up if you have a git worktree where the HEAD
revision ends up being expired (which happens automatically).

My understanding is that the problem is that git prior to 2.15 could
corrupt your repo by pruning a still-accessible worktree; this no
longer happens.

I haven't actually verified this myself, but since I sorted out my
original broken tree, and moved to 2.15, I haven't seen the problem
again.

I think you could verify this theory by creating a worktree, expiring
it and then doing fsck, with a 2.14 git and a 2.15+ git, but I haven't
done that myself.

Bug#900377: git: Debian git package can now include git-p4 Perforce proxy

[Luke Diamand]

Source: git
Severity: wishlist

Dear Maintainer,

There is a standard git tool, git-p4, which proxies between git and
Perforce (c.f. git-svn for example).

Originally the Debian git package included this tool, but it was removed
in 2014 because - at the time - the Perforce command-line tool was non-free:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715534#10

However, later that year, Perforce actually open-sourced a good deal of
their software, including the p4 command-line client which git-p4 relies
on:

https://www.perforce.com/press-releases/perforce-open-sources-popular-version-control-tools

The source can currently be found here:

https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/

and the license (as of the 2018-1 branch) is here:

https://swarm.workshop.perforce.com/files/guest/perforce_software/p4/2018-1/LICENSE

That appears to be a standard BSD license (2-part).

I found that I could build the code on a recent Debian install with a
few small hacks (I think it assumes an older version of openssl than
that shipped with current Debian).

Given this, I think git could once again include the git-p4 package.
That would be very useful for people in organizations where Perforce is
in use for version control, but who would prefer to use the standard git
frontend (and for whatever reason can't use Perforce's own git-fusion
tool).

Thanks
Luke


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

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

Bug#899372: procps update breaks firewall routing.

[Luke Hall]

Package: procps
Version: 2:3.3.9-9+deb8u1

Earlier today this security update to procps (and libprocps3) affected
traffic handling on several of our 'jessie' firewalls. This was then
resolved when we issued a 'shorewall restart'.

On an affected firewall, tcpdump shows incoming packets hitting the
external interface then not being handed over to the relevant internal
interface so consequentially not reaching the destination address inside
the LAN. As stated, a 'shorewall restart' then resolves the issue.

kernel 3.16.0-5-amd64
shorewall  4.6.4.3-2
systemd215-17+deb8u7



signature.asc
Description: OpenPGP digital signature

Bug#899220: Generating PNG graphs raises NotImplementedError

[Luke W Faraone]

Package: wotsap
Version: 0.7-5
Severity: normal


```
$ wget https://pgp.cs.uu.nl/archive/wot-0.2/latest.wot -O .wotsapdb
$ wotsap -o foo.png 0C14A470 D4311E58
[… normal trust path output omitted…]


Traceback (most recent call last):
  File "/usr/bin/wotsap", line 1903, in 
wotsapmain(sys.argv)
  File "/usr/bin/wotsap", line 1852, in wotsapmain
wot.initfont(fontfile, ttffile, ttfsize)
  File "/usr/bin/wotsap", line 1488, in initfont
init_pil_get_logo()
  File "/usr/bin/wotsap", line 232, in init_pil_get_logo
Image.fromstring('P', (175,15), string.join(logostr, ""))
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2342, in fromstring
"Please call frombytes() instead.")
NotImplementedError: fromstring() has been removed. Please call frombytes() 
instead.
```

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 wotsap depends on:
ii  fonts-freefont-ttf  20120503-7
ii  python  2.7.15~rc1-1
ii  python-pil  5.1.0-1

wotsap recommends no packages.

Versions of packages wotsap suggests:
ii  gnupg  2.2.5-1
ii  wget   1.19.5-1

-- no debconf information

Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)

[Luke Faraone]

On Sun, Apr 15, 2018 at 7:39 PM, Ludovic Rousseau
<ludovic.rouss...@free.fr> wrote:
> The problem is with the call to
> udev_device_get_parent_with_subsystem_devtype()
> https://salsa.debian.org/rousseau/PCSC/blob/master/src/hotplug_libudev.c#L338
>
> Maybe USB-C ports are different than "normal" USB.

Yeah, attaching USB-C devices always generates xhci / pcieport spew in
dmesg. (enclosed for curiosity)

> Also please generate a "udevadm monitor" log.
> Start "udevadm monitor --property" (no need to be root)
> Plug the reader
> Unplug the reader
> and send me the output.

Attached.

-- 
Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs; MIT SIPB
lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello
PGP fprint: 8C82 3DED 10AA 8041 639E  1210 5ACE 8D6E 0C14 A470
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[437890.494912] add  /devices/pci:00/:00:1c.0/:01:00.0 (pci)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0
MODALIAS=pci:v8086d1576svsdbc06sc04i00
PCI_CLASS=60400
PCI_ID=8086:1576
PCI_SLOT_NAME=:01:00.0
PCI_SUBSYS_ID=:
SEQNUM=23065
SUBSYSTEM=pci

KERNEL[437890.495168] add  /devices/pci:00/:00:1c.0/:01:00.0/pci_bus/:02 (pci_bus)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/pci_bus/:02
SEQNUM=23066
SUBSYSTEM=pci_bus

KERNEL[437890.496171] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:00.0 (pci)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:00.0
MODALIAS=pci:v8086d1576svsdbc06sc04i00
PCI_CLASS=60400
PCI_ID=8086:1576
PCI_SLOT_NAME=:02:00.0
PCI_SUBSYS_ID=:
SEQNUM=23067
SUBSYSTEM=pci

KERNEL[437890.497045] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:01.0 (pci)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:01.0
MODALIAS=pci:v8086d1576svsdbc06sc04i00
PCI_CLASS=60400
PCI_ID=8086:1576
PCI_SLOT_NAME=:02:01.0
PCI_SUBSYS_ID=:
SEQNUM=23068
SUBSYSTEM=pci

KERNEL[437890.498056] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:02.0 (pci)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:02.0
MODALIAS=pci:v8086d1576svsdbc06sc04i00
PCI_CLASS=60400
PCI_ID=8086:1576
PCI_SLOT_NAME=:02:02.0
PCI_SUBSYS_ID=:
SEQNUM=23069
SUBSYSTEM=pci

KERNEL[437890.498216] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:00.0/pci_bus/:03 (pci_bus)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:00.0/pci_bus/:03
SEQNUM=23070
SUBSYSTEM=pci_bus

KERNEL[437890.498621] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:01.0/pci_bus/:04 (pci_bus)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:01.0/pci_bus/:04
SEQNUM=23071
SUBSYSTEM=pci_bus

KERNEL[437890.498732] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:02.0/pci_bus/:39 (pci_bus)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:02.0/pci_bus/:39
SEQNUM=23072
SUBSYSTEM=pci_bus

KERNEL[437890.499798] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:02.0/:39:00.0 (pci)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:02.0/:39:00.0
MODALIAS=pci:v8086d15B5svsdbc0Csc03i30
PCI_CLASS=C0330
PCI_ID=8086:15B5
PCI_SLOT_NAME=:39:00.0
PCI_SUBSYS_ID=:
SEQNUM=23073
SUBSYSTEM=pci

KERNEL[437890.501759] add  /devices/pci:00/:00:1c.0/:01:00.0/:01:00.0:pcie102 (pci_express)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:01:00.0:pcie102
SEQNUM=23074
SUBSYSTEM=pci_express

KERNEL[437890.501865] add  /devices/pci:00/:00:1c.0/:01:00.0/:01:00.0:pcie108 (pci_express)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:01:00.0:pcie108
SEQNUM=23075
SUBSYSTEM=pci_express

KERNEL[437890.505399] bind /devices/pci:00/:00:1c.0/:01:00.0 (pci)
ACTION=bind
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0
DRIVER=pcieport
MODALIAS=pci:v8086d1576svsdbc06sc04i00
PCI_CLASS=60400
PCI_ID=8086:1576
PCI_SLOT_NAME=:01:00.0
PCI_SUBSYS_ID=:
SEQNUM=23076
SUBSYSTEM=pci

KERNEL[437890.508115] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:00.0/:02:00.0:pcie202 (pci_express)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:00.0/:02:00.0:pcie202
SEQNUM=23077
SUBSYSTEM=pci_express

KERNEL[437890.511254] add  /devices/pci:00/:00:1c.0/:01:00.0/:02:00.0/:02:00.0:pcie208 (pci_express)
ACTION=add
DEVPATH=/devices/pci:00/:00:1c.0/:01:00.0/:02:00.0/:02:00.0:pcie208
SEQNUM=23078
SUBSYSTEM=pci_express

Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)

[Luke Faraone]

On Sun, Apr 15, 2018 at 6:01 PM, Ludovic Rousseau
<ludovic.rouss...@free.fr> wrote:
> Exact.
>
> Try with this new patch.
> You will have to remove the previous patch, or start from the clean sources
> first.

Aha, now we have something.

-- 
Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs; MIT SIPB
lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello
PGP fprint: 8C82 3DED 10AA 8041 639E  1210 5ACE 8D6E 0C14 A470
 debuglog.c:289:DebugLogSetLevel() debug level=debug
0021 pcscdaemon.c:352:main() Force colored logs
0680 configfile.l:285:DBGetReaderListDir() Parsing conf directory: 
/etc/reader.conf.d
0022 configfile.l:322:DBGetReaderListDir() Skipping non regular 
file: .
0004 configfile.l:361:DBGetReaderList() Parsing conf file: 
/etc/reader.conf.d/libccidtwin
0030 configfile.l:322:DBGetReaderListDir() Skipping non regular 
file: ..
0005 pcscdaemon.c:662:main() pcsc-lite 1.8.23 daemon 
ready.
0771 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ACS ACR 38U-CCID
0005 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ActivIdentity USB Reader V3
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ActivIdentity Activkey_Sim
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Alcor Micro AU9520
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Alcor Micro AU9560
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Athena ASE IIIe
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Athena ASEDrive IIIe KB
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: BLUTRONICS BLUDRIVE II CCID
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: C3PO LTC31 v2
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartBoard XX33
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartBoard XX44
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartTerminal XX44
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartTerminal ST-2xxx
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: COVADIS ALYA
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Dell keyboard SK-3106
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Dell Dell Smart Card Reader Keyboard
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron CryptoIdentity CCID
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron CryptoIdentity CCID
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Digipass 860
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Card Reader
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Smart Pocket
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto PDT
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto PC Twin Reader
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto USB Shell Token V2
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto USB GemPCPinpad SmartCard Reader
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto GemCore SIM Pro Smart Card Reader
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Ezio Shield
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto EZIO CB+
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Gemplus USB SmartCard Reader 433-Swap
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Prox Dual USB PC Link Reader
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Prox SU USB PC LinkReader
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Smart Enterprise Guardian Secure USB Device
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto IDBridge K3000
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Giesecke & Devrient GmbH StarSign Crypto US

Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)

[Luke Faraone]

Enclosed. Doesn't appear to have changed the output.

On Sun, Apr 15, 2018 at 3:49 PM, Ludovic Rousseau
<ludovic.rouss...@free.fr> wrote:
> Le 15/04/2018 à 17:07, Luke W Faraone a écrit :
>>
>> On 15/04/18 12:05, Ludovic Rousseau wrote:
>>>
>>> - kill any already running pcscd process
>>> - run the newly compiler pcscd
>>> $ sudo src/pcscd --foreground --debug --color | tee log.txt
>>>
>>> - connect the Yubikey 4 (USB-C)
>>> - disconnect the device
>>> - stop pcscd by Ctrl-C after the problem occurred
>>>
>>> Send me the generated log.txt file.
>>
>>
>> Attached, thanks!
>>
>
> Please apply the attached patch to pcsc-lite and generate a new log.
>
> Thanks
>
> --
>  Dr. Ludovic Rousseau



-- 
Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs; MIT SIPB
lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello
PGP fprint: 8C82 3DED 10AA 8041 639E  1210 5ACE 8D6E 0C14 A470
 debuglog.c:289:DebugLogSetLevel() debug level=debug
0015 pcscdaemon.c:352:main() Force colored logs
0093 configfile.l:285:DBGetReaderListDir() Parsing conf directory: 
/etc/reader.conf.d
0016 configfile.l:322:DBGetReaderListDir() Skipping non regular 
file: .
0003 configfile.l:361:DBGetReaderList() Parsing conf file: 
/etc/reader.conf.d/libccidtwin
0033 configfile.l:322:DBGetReaderListDir() Skipping non regular 
file: ..
0006 pcscdaemon.c:662:main() pcsc-lite 1.8.23 daemon 
ready.
0613 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ACS ACR 38U-CCID
0005 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ActivIdentity USB Reader V3
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ActivIdentity Activkey_Sim
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Alcor Micro AU9520
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Alcor Micro AU9560
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Athena ASE IIIe
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Athena ASEDrive IIIe KB
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: BLUTRONICS BLUDRIVE II CCID
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: C3PO LTC31 v2
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartBoard XX33
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartBoard XX44
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartTerminal XX44
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartTerminal ST-2xxx
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: COVADIS ALYA
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Dell keyboard SK-3106
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Dell Dell Smart Card Reader Keyboard
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron CryptoIdentity CCID
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron CryptoIdentity CCID
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Digipass 860
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Card Reader
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Smart Pocket
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto PDT
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto PC Twin Reader
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto USB Shell Token V2
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto USB GemPCPinpad SmartCard Reader
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto GemCore SIM Pro Smart Card Reader
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Ezio Shield
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto EZIO CB+
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Gemplus USB SmartCard Reader 433-Swap
0002 hotplug_libudev.c:218

Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)

[Luke W Faraone]

On 15/04/18 12:05, Ludovic Rousseau wrote:
> - kill any already running pcscd process
> - run the newly compiler pcscd
> $ sudo src/pcscd --foreground --debug --color | tee log.txt
> 
> - connect the Yubikey 4 (USB-C)
> - disconnect the device
> - stop pcscd by Ctrl-C after the problem occurred
> 
> Send me the generated log.txt file.

Attached, thanks!
 debuglog.c:289:DebugLogSetLevel() debug level=debug
0008 pcscdaemon.c:352:main() Force colored logs
0054 configfile.l:285:DBGetReaderListDir() Parsing conf directory: 
/etc/reader.conf.d
0011 configfile.l:322:DBGetReaderListDir() Skipping non regular 
file: .
0002 configfile.l:361:DBGetReaderList() Parsing conf file: 
/etc/reader.conf.d/libccidtwin
0021 configfile.l:322:DBGetReaderListDir() Skipping non regular 
file: ..
0005 pcscdaemon.c:662:main() pcsc-lite 1.8.23 daemon 
ready.
0421 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ACS ACR 38U-CCID
0003 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ActivIdentity USB Reader V3
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: ActivIdentity Activkey_Sim
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Alcor Micro AU9520
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Alcor Micro AU9560
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Athena ASE IIIe
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Athena ASEDrive IIIe KB
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: BLUTRONICS BLUDRIVE II CCID
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: C3PO LTC31 v2
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartBoard XX33
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartBoard XX44
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartTerminal XX44
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Cherry GmbH SmartTerminal ST-2xxx
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: COVADIS ALYA
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Dell keyboard SK-3106
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Dell Dell Smart Card Reader Keyboard
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron CryptoIdentity CCID
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron CryptoIdentity CCID
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Digipass 860
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Card Reader
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Eutron Smart Pocket
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto PDT
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto PC Twin Reader
0002 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto USB Shell Token V2
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto USB GemPCPinpad SmartCard Reader
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto GemCore SIM Pro Smart Card Reader
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Ezio Shield
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto EZIO CB+
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Gemplus USB SmartCard Reader 433-Swap
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Prox Dual USB PC Link Reader
0005 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Prox SU USB PC LinkReader
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto Smart Enterprise Guardian Secure USB Device
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Gemalto IDBridge K3000
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Giesecke & Devrient GmbH StarSign Crypto USB Token
0001 hotplug_libudev.c:218:HPReadBundleValues() Found driver 
for: Giesecke & 

Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)

[Luke W Faraone]

Package: pcscd
Version: 1.8.23-2
Severity: normal

Dear maintainer,

This appears to be similar symptoms to bug #459827, but reporting
separately, as this has nothing to do with PCMCIA.

After removing a Yubikey 4 (USB-C) from my XPS 13 9360, syslog is filled
with errors like this about once a second:

```
Apr 04 11:04:56 zinc pcscd[4147]:  ccid_usb.c:849:WriteUSB() write 
failed (3/2): -4 LIBUSB_ERROR_NO_DEVICE
Apr 04 11:04:56 zinc pcscd[4147]: 0056 ifdwrapper.c:364:IFDStatusICC() Card 
not transacted: 617
Apr 04 11:04:57 zinc pcscd[4147]: 01000882 
eventhandler.c:334:EHStatusHandlerThread() Error communicating to: Yubico 
Yubikey 4 OTP+U2F+CCID 00 00
Apr 04 11:04:57 zinc pcscd[4147]: 0029 ccid_usb.c:1312:InterruptRead() 
libusb_submit_transfer failed: LIBUSB_ERROR_NO_DEVICE
Apr 04 11:04:57 zinc pcscd[4147]: 00400296 ccid_usb.c:849:WriteUSB() write 
failed (3/2): -4 LIBUSB_ERROR_NO_DEVICE
Apr 04 11:04:57 zinc pcscd[4147]: 0017 ifdwrapper.c:364:IFDStatusICC() Card 
not transacted: 617
```

This specific issue happened after a resume-from-suspend when the device
was removed between suspend and resume, but in general it happens any
time I remove the USB-C device.

This does not occur with a Yubikey Neo (USB 2.0).

I was also able to replicate it on a fellow developer's XPS 13 9350.
Please let me know if there is any other debugging information I can
provide.

Cheers,
Luke Faraone

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 pcscd depends on:
ii  libc6   2.27-3
ii  libccid [pcsc-ifd-handler]  1.4.29-2
ii  libpcsclite11.8.23-2
ii  libsystemd0 238-4
ii  libudev1238-4
ii  lsb-base9.20170808

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  238-4

-- no debconf information

Bug#892504: [PATCH] nspr: Please add support for the RISC-V architecture

[Luke Kenneth Casson Leighton]

On Fri, Mar 9, 2018 at 8:31 PM, Karsten Merker  wrote:

> There is one thing that I am a bit unsure about, though, and that
> is Mozilla's use of WORD and DWORD in their size definitions as I
> haven't found any documentation about that.

hiya karsten,

ok so someone from mozilla is really going to have to double-check
this, or perhaps todd from activestate would know, or brendan eitch
may know (i don't have an active email address for him).

my understanding is that the mozilla team copied microsoft's DCE/RPC
implementation (which microsoft called MSRPC) and also wrote something
that was "inspired" by COM, called XPCOM: they screwed it up royally
by leaving out the absolutely critical critical part, which is
co-classes (a run-time version of c++ multiple inheritance:
unnnbelievably important, and because they didn't implement it, the
problems kept compounding, and eventually they ripped XPCOM out).

now, because the decision and "inspiration" was such a long time ago,
they cut over the *win32* code, and hence some of the win32
code-conventions.  WORD in win32 is *specifically* defined as 16-bit,
and DWORD *specifically* as 32-bit.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx?f=255=-2147217396

now, what i don't know is: did they keep those conventions during the
f***-up known as "ripping out XPCOM"?  the purpose of XPCOM was to
provide a stable standard / API for their own developers  and for 3rd
party developers.  they failed on both counts... so may no longer care
and may have changed the definition of WORD and DWORD... but this is a
bit of a stretch.

honestly, this is something that really needs an answer and
clarification from mozilla, or someone like todd (hi todd) who knows
more about it.

l.

Bug#891411: Acknowledgement (mailman critically (and unnecessarily) linked to apache2 (and not nginx))

[Luke Kenneth Casson Leighton]

On Mon, Feb 26, 2018 at 7:51 AM, Thijs Kinkhorst <th...@debian.org> wrote:
> On Sun, February 25, 2018 12:13, Luke Kenneth Casson Leighton wrote:
>> apologies, after downloading the source i noted that the debian/rules
>> debian package.  i've installed lighthttpd, disabled it, and thus
>> "worked around" the "problem".
>
> Maybe for a next time, you can use the "equivs" package if you want to
> simulate that something is installed.

 thanks thijs i'll remember that, really appreciated.

l.

Bug#882149: python3-sqlalchemy-utils depends on python-arrow (and so python2)

[Luke Ross]

Package: python3-sqlalchemy-utils
Version: 0.32.14-2

Package python3-sqlalchemy-utils depends on python-arrow, the python2
package, and so can't be installed on a python3-only system. Should it
depend on python3-arrow instead?

Thanks!

Bug#718272: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

[Luke Dashjr]

On Friday 03 November 2017 1:27:24 PM Jonas Smedegaard wrote:
> Quoting Luke Dashjr (2017-11-03 11:25:23)
> 
> > On Friday 03 November 2017 9:10:37 AM you wrote:
> >> I believe Bitcoin is now stable enough for stable release.
> > 
> > Things have only gotten less stable upstream since 2013...
> 
> Please provide references supporting that.

Back in 2013 (0.8.0 release), I was still supporting stable versions 0.4.x 
(originally released in 2011), 0.5.x (OR 2011), 0.6.x (OR 2012), and
0.7.x (OR 2012). No such long-term support is provided anymore - we only 
maintain the most recent 2 versions (with a 6 month release schedule), which 
gives approximately 1 year of support to any particular release.

Furthermore, with increasing miner hostilities to Bitcoin in the last few 
years, the importance of timely deployment of softforks is even more crucial 
to security than previously. This past August, there was a fear that miners 
would violate the new softfork rules, causing a chainsplit. If that had 
occurred, obsolete nodes would have been vulnerable.

> > What is the plan for getting security and protocol change updates
> > backported to Debian stable?
> 
> Debian standard procedures for updating stable packages.

In my experience, that has been "never update, even when fixes are available" 
except for highly-visible security issues. :(

Luke

Bug#718272: Bitcoin still not ready for stable release in Debian

[Luke Dashjr]

On Friday 03 November 2017 9:10:37 AM you wrote:
> I believe Bitcoin is now stable enough for stable release.

Things have only gotten less stable upstream since 2013...

What is the plan for getting security and protocol change updates backported 
to Debian stable?

Luke

Bug#880039: beara fails without en_US.UTF-8 locale

[luke]

Package: bear
Version: 2.3.7-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,


   A recent update to bear has caused execution of any subprocess to
   fail on my system:

> bear sh -c /bin/echo
bear: newlocale: No such file or directory

It seems this is caused by an inability to load the "en_US.UTF-8"
locale which is not installed on my system (see libear/ear.c:434).

It looks like this has been already been reported, and fixed
upstream in [this

commit](https://github.com/rizsotto/Bear/commit/b5d831ea158a8eff0b5dcb3d863e0046528189e6)

Without this commit it seems like any user of `bear` will have to have
en_US.UTF-8 installed.

Is there any possibilty debian can backport this fix, or do a
version bump?

All the Best

Luke


-- System Information:
Debian Release: buster/sid
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bear depends on:
ii  libear   2.3.7-1
ii  python3  3.6.3-2

bear recommends no packages.

bear suggests no packages.

-- no debconf information

Bug#879652: rpl has a python3 shebang but fails with NameError raw_input

[luke]

Package: rpl
Version: 1.5.7-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

using rpl with the `--prompt` option causes rpl to fail with the
following backtrace:

$ rpl --prompt foo bar test_file
Replacing "foo" with "bar" (case sensitive) (partial words matched)
.
Save 'test_file' ? ([Y]/N) Traceback (most recent call last):
  File "/usr/bin/rpl", line 314, in 
main()
  File "/usr/bin/rpl", line 269, in main
line = raw_input()
NameError: name 'raw_input' is not defined

It appears that Debian is using a hardcoded `/usr/bin/python3` shebang, whereas
the script is using python2 features (`raw_input`). Patching to use the
python3-equivalent `input` function where necessary ` appears to fix the issue:

diff --git rpl usr/bin/rpl
index 14754c3..fe2ff7c 100755
--- rpl
+++ usr/bin/rpl
@@ -5,12 +5,6 @@ try: import readline
 except ImportError: pass
 from stat import *
 
-try:
-raw_input
-except NameError:
-raw_input = input
-
-
 def show_license(*eat):
 print ("""rpl - replace strings in files
 Copyright (C) 2004-2005 Goran Weinholt <weinh...@debian.org>


Thanks

Luke

-- System Information:
Debian Release: buster/sid
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages rpl depends on:
ii  python3  3.6.3-1

rpl recommends no packages.

rpl suggests no packages.

-- no debconf information

*** rpl.patch
diff --git rpl usr/bin/rpl
index 14754c3..fe2ff7c 100755
--- rpl
+++ usr/bin/rpl
@@ -5,12 +5,6 @@ try: import readline
 except ImportError: pass
 from stat import *
 
-try:
-raw_input
-except NameError:
-raw_input = input
-
-
 def show_license(*eat):
 print ("""rpl - replace strings in files
 Copyright (C) 2004-2005 Goran Weinholt <weinh...@debian.org>

Bug#877370: Doesn't allow saying "do not print answers"

[Luke Faraone]

Package: purity-ng
Version: 0.2.0-2.1
Severity: important

purity-ng incorrectly checks the user's answer to the "should answers be
printed" text, v.s. accepting "n" as an answer. 

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

Kernel: Linux 4.13.3-1-ARCH (SMP w/12 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages purity-ng depends on:
ii  python  2.7.13-2

Versions of packages purity-ng recommends:
ii  purity  1-19

purity-ng suggests no packages.

-- no debconf information

Bug#876065: Invalid upstream-signing-key

[Luke W Faraone]

Package: yubico-piv-tool
Version: 1.4.2-2
Severity: normal

The file is in ASCII-armoured format, which is incorrect for
`debian/upstream-signing-key.pgp`. The file should should instead be
renamed to `debian/upstream/signing-key.asc`.

$ uscan
uscan: Newest version of yubico-piv-tool on remote site is 1.4.3, local version 
is 1.4.2
uscan:=> Newer package available from
  
https://developers.yubico.com/yubico-piv-tool/Releases/yubico-piv-tool-1.4.3.tar.gz
gpgv: Signature made Tue 18 Apr 2017 11:11:00 UTC using RSA key ID B2168C0A
gpgv: [don't know]: invalid packet (ctb=2d)
gpgv: keydb_search failed: invalid packet
gpgv: Can't check signature: public key not found
uscan warn: OpenPGP signature did not verify.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages yubico-piv-tool depends on:
ii  libc6 2.24-17
ii  libpcsclite1  1.8.22-1
ii  libssl1.0.2   1.0.2l-2
ii  libykpiv1 1.4.2-2

yubico-piv-tool recommends no packages.

yubico-piv-tool suggests no packages.

-- no debconf information

Bug#875719: Cannot install, depends on non-existant yubico-piv-tool >=1.4.3

[Luke Faraone]

Package: yubikey-piv-manager
Version: 1.4.2-2
Severity: grave

yubikey-piv-manager depends on yubico-piv-tool (>=1.4.3), but that package is 
not in the archive.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages yubikey-piv-manager depends on:
ii  python   2.7.13-2
ii  python-pkg-resources 36.2.7-2
ii  python-pyside.qtgui  1.2.2+source1-1
ii  python-pyside.qtnetwork  1.2.2+source1-1
ii  yubico-piv-tool  1.4.2-2

Versions of packages yubikey-piv-manager recommends:
ii  pcscd  1.8.22-1

yubikey-piv-manager suggests no packages.

Bug#872036: Acknowledgement (AH00060: seg fault or similar nasty error detected in the parent process)

[Luke Kenneth Casson Leighton]

ok so a little more info here: the segfault occurs *directly* after a
logrotate-inspired signal is received.

[Sat Aug 19 06:25:37.746265 2017] [mpm_event:notice] [pid 21345:tid
3074504512] AH00493: SIGUSR1 received.  Doing graceful restart
[Sat Aug 19 06:25:39.647852 2017] [core:notice] [pid 21345] AH00060:
seg fault or similar nasty error detected in the parent process

an attempt to get more information by using mod_pagespeed's crash
handler *failed*.  one of the developers mentioned that there's an
option to get stack trace output put into the error logs, but
bizarrely (no explanation yet) we got absolutely no output when
the segfault occurred: just the standard apache2 AH00060 notice.

this is all very strange and i can't keep risking a live-running
client's system by using unstable software.  so, apologies, i'm going
to have to return to using mpm_prefork (i.e. can't risk doing further
tests with mpm_event on the live system).  performance was
*significantly* degraded around the time of the segfault.

Bug#870211: Dead link: "Wiki help"

[Luke W Faraone]

Package: nm.debian.org
Severity: normal

There's a link from /process/:id to the [wiki][1], but unfortunately
it appears to be dead.

I looked around and wasn't able to find the correct link target.

[1]: https://wiki.debian.org/nm.debian.org/Process

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files

[Luke Christopher Clarke]

Thank you Jason,

I have done the hard reset of the tracker database. I can now easily right
hand click and see the properties of the files. I do get the error
"GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: Error opening
database" but I am assuming that this is because I have done the hard reset
and it will resolve itself if I leave my computer on for long enough.

Thank you very much for your help. I am happy to have this bug now resolved.

Regards
Luke

On Sat, Jun 17, 2017 at 6:21 AM, Jason Crain <ja...@inspiresomeone.us>
wrote:

> I forwarded this upstream and according to a tracker developer, the
> nautilus tracker plugin will be going away soon, to be replaced a
> feature directly in nautilus.
>
> For a more immediate solution there are a few things you can try:
>
> * Waiting for tracker-store to complete it's integrity check.  This
>   could be several hours for a large database, possibly longer.
>
> * Or, soft reset the tracker database with "tracker-control -e".  The
>   tracker database will be deleted and restored from backup.
>
> * Or, hard reset the tracker database with "tracker-control -r".  The
>   tracker database will be deleted and recreated.
>

Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files

[Luke Christopher Clarke]

Hello Jason,

Sorry for lack of reply. Been away from my computer.

I can confirm that I do have a lot of photos in RAW format about 25Mb each.
However once I have finished with the images I then move them to a external
hard drive.

I will hopefully run the commands tonight.

Regards
Luke

On Fri, Jun 16, 2017 at 6:31 AM, Jason Crain <ja...@inspiresomeone.us>
wrote:

> Control: reassign -1 tracker-gui 1.2.4-2
> Control: tags -1 - moreinfo
> Control: found -1 1.10.5-1
>
> On Sun, Jun 11, 2017 at 02:31:33PM -0500, Jason Crain wrote:
> > How large is your tracker database ~/.cache/tracker/meta.db?  Do you
> > have gigabytes of documents being indexed that would inflate the
> > database?
>
> I'm going to assume the answer to this is yes, you have gigabytes of
> PDFs and PowerPoint presentations causing a large tracker database.
>

Bug#864829: screen reader stops speaking

[Luke Yelavich]

On Thu, Jun 15, 2017 at 11:39:35PM AEST, Mika Hanhijärvi wrote:
> I am using the Gnome desktop.
> I have espeakup and Orca installed. I would like to use espeakup on console 
> and
> Orca on desktop. I also would like to be able to switch between text mode
> console and graphical nome desktop without logging out from the desktop.

ESpeakup is running as root, and everything is running as a user. I think the 
easiest solution here is to configure Pulse to run system-wide. I know there 
is an option in one of the Pulse configuration files to enable this, but I 
don't think Debian ships a startup script or systemd service file to use 
PulseAudio in system mode. Happy to be corrected.
-- 
Please check out my Patreon campaign and spread the word.
https://patreon.com/lukefoss

Bug#864801: 'winetricks dotnet35' fails to download dotnetfx3.exe

[Luke W Faraone]

Package: winetricks
Version: 0.0+20170101-1
Severity: normal
Tags: upstream

Running `winetricks dotnet35` fails to download dotnetfx3.exe from the Internet 
Archive.

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

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

Versions of packages winetricks depends on:
ii  binutils2.28-5
ii  cabextract  1.6-1+b1
ii  p7zip   16.02+dfsg-3
ii  unzip   6.0-21
ii  wget1.19.1-3
ii  wine1.8.7-2
ii  zip 3.0-11+b1

Versions of packages winetricks recommends:
ii  sudo   1.8.20p2-1
ii  xdg-utils  1.1.1-1
ii  zenity 3.22.0-1+b1

Versions of packages winetricks suggests:
pn  aria2  
pn  tor

-- debconf-show failed

*** winetricks-log.txt
--
You are using a 64-bit WINEPREFIX. If you encounter problems, please retest in 
a clean 32-bit WINEPREFIX before reporting a bug.
--
Using winetricks 20170101 - sha1sum: c844fda0cca25ac9ed0ed1b55cd138cab6a4af16 
with wine-1.8.7 (Debian 1.8.7-2) and WINEARCH=win64
Executing w_do_call dotnet35
Executing load_dotnet35 
--
dotnet35 does not yet fully work or install on wine.  Caveat emptor.
--
Executing w_do_call remove_mono
Executing load_remove_mono 
--
Mono does not appear to be installed.
--
Executing w_do_call dotnet30sp1
Executing load_dotnet30sp1 
Executing w_do_call remove_mono
Executing load_remove_mono 
--
Mono does not appear to be installed.
--
Executing w_do_call dotnet30
Executing load_dotnet30 
Executing cd /home/lfaraone/.cache/winetricks/dotnet30
Downloading 
http://download.microsoft.com/download/3/F/0/3F0A922C-F239-4B9B-9CB0-DF53621C57D9/dotnetfx3.exe
 to /home/lfaraone/.cache/winetricks/dotnet30
--2017-06-15 03:57:45--  
http://download.microsoft.com/download/3/F/0/3F0A922C-F239-4B9B-9CB0-DF53621C57D9/dotnetfx3.exe
Resolving download.microsoft.com (download.microsoft.com)... 
2600:1406:3:391::e59, 2600:1406:3:39b::e59, 2600:1406:3:38b::e59, ...
Connecting to download.microsoft.com 
(download.microsoft.com)|2600:1406:3:391::e59|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-06-15 03:57:45 ERROR 404: Not Found.

Executing cd /home/lfaraone/.cache/winetricks/dotnet30
Downloading 
https://web.archive.org/web/http://download.microsoft.com/download/3/F/0/3F0A922C-F239-4B9B-9CB0-DF53621C57D9/dotnetfx3.exe
 to /home/lfaraone/.cache/winetricks/dotnet30
--2017-06-15 03:57:45--  
https://web.archive.org/web/http://download.microsoft.com/download/3/F/0/3F0A922C-F239-4B9B-9CB0-DF53621C57D9/dotnetfx3.exe
Resolving web.archive.org (web.archive.org)... 207.241.225.186
Connecting to web.archive.org (web.archive.org)|207.241.225.186|:443... 
connected.
HTTP request sent, awaiting response... 302 FOUND
Location: 
https://web.archive.org/web/20170118155823/http://download.microsoft.com/download/3/F/0/3F0A922C-F239-4B9B-9CB0-DF53621C57D9/dotnetfx3.exe
 [following]
--2017-06-15 03:57:45--  
https://web.archive.org/web/20170118155823/http://download.microsoft.com/download/3/F/0/3F0A922C-F239-4B9B-9CB0-DF53621C57D9/dotnetfx3.exe
Reusing existing connection to web.archive.org:443.
HTTP request sent, awaiting response... 404 Not Found
2017-06-15 03:57:45 ERROR 404: Not Found.

--
Downloading 
https://web.archive.org/web/http://download.microsoft.com/download/3/F/0/3F0A922C-F239-4B9B-9CB0-DF53621C57D9/dotnetfx3.exe
 failed
--

Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files

[Luke Christopher Clarke]

Hello Jason,

Sorry for the late reply - been under the pump. I have re-run the command.

-- TERMINAL COMMANDS 001 --
luke@luk-main:~$ pkill nautilus
luke@luk-main:~$ tracker-control -S
Store:

(tracker-control:1853): Tracker-CRITICAL **: Could not retrieve
tracker-store status, GDBus.Error:org.freedesktop.DBus.Error.NoReply:
Message did not receive a reply (timeout by message bus)

Miners:
07 Jun 2017, 20:00:28:  ✗ File System   - Not running or is a
disabled plugin
07 Jun 2017, 20:00:28:  ✗ Userguides- Not running or is a
disabled plugin
07 Jun 2017, 20:00:28:  ✗ Applications  - Not running or is a
disabled plugin
07 Jun 2017, 20:00:28:  ✗ Extractor - Not running or is a
disabled plugin

luke@luk-main:~$
-- END TERMINAL COMMANDS 001 --

I then reran the command I got wrong last time

-- TERMINAL COMMANDS 002 --
luke@luk-main:~$ tracker-control -k store; TRACKER_VERBOSITY=3 G_DEBUG=all
G_MESSAGES_DEBUG=all /usr/lib/tracker/tracker-store
Found 197 PIDs…
Tracker-Message: Starting tracker-store 1.2.4
Tracker-Message: General options:
Tracker-Message:   Verbosity    0
Tracker-Message: Store options:
Tracker-Message:   Readonly mode    no
Tracker-Message:   GraphUpdated Delay   1000
Tracker-Message: Log verbosity is set to 0, disabling D-Bus client lookup
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Status'
Tracker-Message:   Type:'TrackerStatus'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Statistics'
Tracker-Message:   Type:'TrackerStatistics'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Resources'
Tracker-Message:   Type:'TrackerResources'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Steroids'
Tracker-Message:   Type:'TrackerSteroids'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Backup'
Tracker-Message:   Type:'TrackerBackup'
Tracker-Message: Registering D-Bus service...
  Name:'org.freedesktop.Tracker1'
(tracker-store:2134): Tracker-DEBUG: Locale 'TRACKER_LOCALE_LANGUAGE' was
set to 'en_AU.utf8'
(tracker-store:2134): Tracker-DEBUG: Locale 'TRACKER_LOCALE_TIME' was set
to 'en_AU.utf8'
(tracker-store:2134): Tracker-DEBUG: Locale 'TRACKER_LOCALE_COLLATE' was
set to 'en_AU.utf8'
(tracker-store:2134): Tracker-DEBUG: Locale 'TRACKER_LOCALE_NUMERIC' was
set to 'en_AU.utf8'
(tracker-store:2134): Tracker-DEBUG: Locale 'TRACKER_LOCALE_MONETARY' was
set to 'en_AU.utf8'
Tracker-Message: Setting database locations
Tracker-Message: Checking database directories exist
Tracker-Message: Checking database version
Tracker-Message: Checking database files exist
Tracker-Message: Loading databases files...
Tracker-Message: Didn't shut down cleanly last time, doing integrity checks
Tracker-Message: Loading database... '/home/luke/.cache/tracker/meta.db'
(metadata)
Tracker-Message: Opened sqlite3 database:'/home/luke/.cache/tracker/meta.db'
(tracker-store:2134): Tracker-DEBUG: Resetting collator in db interface
0x16b58d0
(tracker-store:2134): Tracker-DEBUG: [libunistring collation] Initializing
collator for locale 'en_AU.utf8'
(tracker-store:2134): Tracker-DEBUG: Preparing query: 'PRAGMA journal_mode
= WAL;'
Tracker-Message:   Setting page size to 8192
Tracker-Message:   Setting cache size to 250
(tracker-store:2134): Tracker-DEBUG: Preparing query: 'PRAGMA
integrity_check(1)'
^C
luke@luk-main:~$

-- END TERMINAL COMMANDS 002 --


I let this run for over 15 minutes

Thank you

Regards
Luke



On Sun, May 28, 2017 at 11:14 AM, Jason Crain <ja...@inspiresomeone.us>
wrote:

> On Sun, May 28, 2017 at 10:44:41AM +1000, Luke Christopher Clarke wrote:
> > I ran both commands as non-sudo and sudo respectively.
>
> You should run these as your regular user, not root.
>
> > -- START tracker-control -S --
> > luke@luk-main:~$ tracker-control -S
> > Store:
> > ^C
>
> It is odd that tracker-control freezes too.  I was expecting a message
> about how the tracker store is initializing or reindexing.
>
> > -- tracker-control -k store; TRACKER_VERBOSITY=3 G_DEBUG=all --
> > G_MESSAGES_DEBUG=all /usr/lib/tracker/tracker-store
> > luke@luk-main:~$ tracker-control store; TRACKER_VERBOSITY=3 G_DEBUG=all
>^
>
> This is supposed to be "tracker-control -k store".  The point is to kill
> (-k) the existing tracker-store process before running tracker-store
> with debug messages enabled, because otherwise it will just complain
> that there is already a process running.
>
> > G_MESSAGES_DEBUG=all /usr/lib/tracker/tracker-store
> > Unrecognized options: 'store'
> > Tracker-Message: Starting tracker-store 1.2.4
> 

Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files

[Luke Christopher Clarke]

Hello Jason,

I ran both commands as non-sudo and sudo respectively.

-- START tracker-control -S --
luke@luk-main:~$ tracker-control -S
Store:
^C
luke@luk-main:~$ sudo tracker-control -S
[sudo] password for luke:
Store:
28 May 2017, 10:27:07:  ✗ Store - Unavailable

Miners:
28 May 2017, 10:27:07:  ✗ File System   - Not running or is a
disabled plugin
28 May 2017, 10:27:07:  ✗ Userguides- Not running or is a
disabled plugin
28 May 2017, 10:27:07:  ✗ Applications  - Not running or is a
disabled plugin
28 May 2017, 10:27:07:  ✗ Extractor - Not running or is a
disabled plugin

luke@luk-main:~$

-- END tracker-control -S --


-- tracker-control -k store; TRACKER_VERBOSITY=3 G_DEBUG=all --
G_MESSAGES_DEBUG=all /usr/lib/tracker/tracker-store
luke@luk-main:~$ tracker-control store; TRACKER_VERBOSITY=3 G_DEBUG=all
G_MESSAGES_DEBUG=all /usr/lib/tracker/tracker-store
Unrecognized options: 'store'
Tracker-Message: Starting tracker-store 1.2.4
Tracker-Message: General options:
Tracker-Message:   Verbosity    0
Tracker-Message: Store options:
Tracker-Message:   Readonly mode    no
Tracker-Message:   GraphUpdated Delay   1000
Tracker-Message: Log verbosity is set to 0, disabling D-Bus client lookup
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Status'
Tracker-Message:   Type:'TrackerStatus'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Statistics'
Tracker-Message:   Type:'TrackerStatistics'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Resources'
Tracker-Message:   Type:'TrackerResources'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Steroids'
Tracker-Message:   Type:'TrackerSteroids'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Backup'
Tracker-Message:   Type:'TrackerBackup'
Tracker-Message: Registering D-Bus service...
  Name:'org.freedesktop.Tracker1'

(tracker-store:12568): Tracker-CRITICAL **: D-Bus service
name:'org.freedesktop.Tracker1' is already taken, perhaps the daemon is
already running?
Trace/breakpoint trap
luke@luk-main:~$ ^C


luke@luk-main:~$ sudo tracker-control store; TRACKER_VERBOSITY=3
G_DEBUG=all G_MESSAGES_DEBUG=all /usr/lib/tracker/tracker-store
[sudo] password for luke:
Unrecognized options: 'store'
Tracker-Message: Starting tracker-store 1.2.4
Tracker-Message: General options:
Tracker-Message:   Verbosity    0
Tracker-Message: Store options:
Tracker-Message:   Readonly mode    no
Tracker-Message:   GraphUpdated Delay   1000
Tracker-Message: Log verbosity is set to 0, disabling D-Bus client lookup
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Status'
Tracker-Message:   Type:'TrackerStatus'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Statistics'
Tracker-Message:   Type:'TrackerStatistics'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Resources'
Tracker-Message:   Type:'TrackerResources'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Steroids'
Tracker-Message:   Type:'TrackerSteroids'
Tracker-Message: Registering D-Bus object...
Tracker-Message:   Path:'/org/freedesktop/Tracker1/Backup'
Tracker-Message:   Type:'TrackerBackup'
Tracker-Message: Registering D-Bus service...
  Name:'org.freedesktop.Tracker1'

(tracker-store:12587): Tracker-CRITICAL **: D-Bus service
name:'org.freedesktop.Tracker1' is already taken, perhaps the daemon is
already running?
Trace/breakpoint trap

-- END tracker-control -k store; TRACKER_VERBOSITY=3 G_DEBUG=all --



On Sun, May 28, 2017 at 7:56 AM, Jason Crain <ja...@inspiresomeone.us>
wrote:

> On Fri, May 26, 2017 at 08:03:26PM +1000, Luke Christopher Clarke wrote:
> > I have not gone out of my way to install any extra nautilus extensions to
> > my knowledge. Is there a way I can find that out?
> >
> > Also the following is the output from your command. I also went ahead and
> > replicated the bug.
> >
> ...
> > (nautilus:1733): Tracker-DEBUG: New TrackerTagsView with 1 files
> > (nautilus:1733): Tracker-DEBUG: tracker-backend.vala:37: Waiting for
> > service to become available...
> >
> > -- END TERMINAL OUTPUT --
>
> It looks like it's frozen because tracker is stuck.  What's the output
> of "tracker-control -S"?  And what is the output of running
> "tracker-control -k store; TRACKER_VERBOSITY=3 G_DEBUG=all
> G_MESSAGES_DEBUG=all /usr/lib/tracker/tracker-store" ?
>

Bug#862524: License Issue about Distributing NVIDIA's cuDNN library via Debian

[Luke Yeager]

Adding Maitreyi, who is the Product Manager for cuDNN.

-Original Message-
From: lumin [mailto:cdlumin...@gmail.com] 
Sent: Tuesday, May 23, 2017 11:43 PM
To: debian-le...@lists.debian.org
Cc: pkg-nvidia-de...@lists.alioth.debian.org; Daniel Stender; Luke Yeager; 
862...@bugs.debian.org
Subject: License Issue about Distributing NVIDIA's cuDNN library via Debian

Hi Debian Legal Team,

I intend to package[1] a proprietary deep learning library named "cuDNN"[2], 
which is definitely useful to deep learning researchers.

@lyeager kindly provided some help[3] on this but I'm not really good at these 
legal terms.

Generally, to download the cudnn library, one needs to fist register or login 
at nvidia's website. Next, the user is required to click "I agree ..."[4] to 
continue.
Now the secured library download link is exposed to the user.[5]

Initially I don't think such a well-protected proprietary can be distributed by 
Debian, untill I find this package in Archlinux's community repo[6].

I don't know how the Arch guys achieved this but in their PKGBUILD file (arch 
packaging script) there is a anonymously downloadable link to the cudnn 
library[7]. What is notable is the "redist" keyword in the URL. I can't find 
this "redist"
URL in nvidia's website.

I'm confused.

What makes me more confused is nvidia legal guy's word conveyed by @lyeager 
[8]. Once a package is uploaded to the Archive, isn't the distributor (legally) 
the Debian Organization? It's so weird for an individual to take the role of 
distributor for a package in Archive and I think it's impossible.

Anyway I'm not good at the legal field. I need help.

Thank you in advance :-)

P.S. "cuDNN", i.e. "CUDA Deep Neural Network", is a library built upon nvidia's 
proprietary CUDA toolkit, which was available in our archive for years[9].

[1] https://bugs.debian.org/862524
[2] https://developer.nvidia.com/cudnn
[3] https://github.com/CDLuminate/nvidia-cudnn/issues/1
[4] Unluckily this licence file is secured, only available after login:
http://developer2.download.nvidia.com/compute/machine-
learning/cudnn/secure/v6/prod/Doc/NVIDIA_SLA%2BcuDNN_Supp_Feb2017_relea
se.pdf
[5] https://developer.nvidia.com/compute/machine-learning/cudnn/secure/
v6/prod/8.0_20170427/cudnn-8.0-linux-x64-v6.0-tgz
[6] https://www.archlinux.org/packages/community/x86_64/cudnn/
[7] http://developer.download.nvidia.com/compute/redist/cudnn/v6.0/cudn
n-8.0-linux-x64-v6.0.tgz
[8] https://github.com/CDLuminate/nvidia-cudnn/issues/1#issuecomment-30
1827809
[9] https://tracker.debian.org/pkg/nvidia-cuda-toolkit

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---

Bug#847493: yubikey-piv-manager: diff for NMU version 1.3.0-1.1

[Luke W Faraone]

Control: tags 847493 + patch
Control: tags 847493 + pending

Dear maintainer,

I've prepared an NMU for yubikey-piv-manager (versioned as 1.3.0-1.1)
and uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru yubikey-piv-manager-1.3.0/debian/changelog 
yubikey-piv-manager-1.3.0/debian/changelog
--- yubikey-piv-manager-1.3.0/debian/changelog  2016-08-23 00:37:18.0 
-0700
+++ yubikey-piv-manager-1.3.0/debian/changelog  2017-05-16 19:08:22.0 
-0700
@@ -1,3 +1,11 @@
+yubikey-piv-manager (1.3.0-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Re-add PySide patch.
+  * Remove requires.txt requiring PySide (Closes: #847493)
+
+ -- Luke W Faraone <lfara...@debian.org>  Wed, 17 May 2017 02:08:22 +
+
 yubikey-piv-manager (1.3.0-1) unstable; urgency=low
 
   [ Simon Josefsson ]
diff -Nru yubikey-piv-manager-1.3.0/debian/patches/fix-pyside.diff 
yubikey-piv-manager-1.3.0/debian/patches/fix-pyside.diff
--- yubikey-piv-manager-1.3.0/debian/patches/fix-pyside.diff1969-12-31 
16:00:00.0 -0800
+++ yubikey-piv-manager-1.3.0/debian/patches/fix-pyside.diff2017-05-16 
18:43:02.0 -0700
@@ -0,0 +1,13 @@
+--- a/setup.py
 b/setup.py
+@@ -42,8 +42,8 @@
+ entry_points={
+ 'gui_scripts': ['pivman=pivman.__main__:main']
+ },
+-install_requires=['PySide'],
+-yc_requires=['ctypes', 'qt'],
++yc_requires=['ctypes'],
++packages=['pivman', 'pivman.view', 'pivman.yubicommon', 
'pivman.yubicommon.setup', 'pivman.yubicommon.ctypes', 'pivman.yubicommon.qt'],
+ test_suite='test',
+ tests_require=[''],
+ cmdclass={'executable': executable, 'qt_resources': 
qt_resources('pivman')},
diff -Nru yubikey-piv-manager-1.3.0/debian/patches/series 
yubikey-piv-manager-1.3.0/debian/patches/series
--- yubikey-piv-manager-1.3.0/debian/patches/series 1969-12-31 
16:00:00.0 -0800
+++ yubikey-piv-manager-1.3.0/debian/patches/series 2017-05-16 
18:43:02.0 -0700
@@ -0,0 +1 @@
+fix-pyside.diff
diff -Nru yubikey-piv-manager-1.3.0/debian/rules 
yubikey-piv-manager-1.3.0/debian/rules
--- yubikey-piv-manager-1.3.0/debian/rules  2016-08-23 00:36:56.0 
-0700
+++ yubikey-piv-manager-1.3.0/debian/rules  2017-05-16 19:08:22.0 
-0700
@@ -2,3 +2,7 @@
 
 %:
dh $@ --with python2 --buildsystem=python_distutils
+
+override_dh_auto_clean:
+   dh_clean
+   rm -f yubikey_piv_manager.egg-info/requires.txt


signature.asc
Description: OpenPGP digital signature

Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files

[Luke Christopher Clarke]

Hello,

The issue will occur on any particular type of file. I have created a video
recording me replicating the bug using just a JPG.
https://youtu.be/eUI2tVpZ6nY

Regards
Luke

On Fri, May 12, 2017 at 5:36 AM, Jason Crain <ja...@inspiresomeone.us>
wrote:

> Control: tags -1 + moreinfo
>
> On Sun, May 07, 2017 at 12:41:46PM +1000, Luke wrote:
> > Method
> > ~~
> > 1.) Open up Nautilus
> > 2.) Navigate to a folder where you want to find the file size of contents
> > 3.) Select the file(s)/folder(s), right hand click
> > 4.) Click on the option "Properties" in the menu
> >
> > Expected Results
> > 
> > Properties dialog will appear
> >
> >
> > Actual Results
> > ~~
> > Nautilus will lock up, will not be able to use it even if I have multiple
> > windows opened. Eventually Gnome will inform me that Nautilus has
> potentially
> > crashed.
> > Other times, it has taken over a minute to load the properties dialog.
> >
> > Notes
> > ~
> > Does not happen all the time, about 50% for me. When it does occur
> Nautilus
> > will not open unless I either;
> > - Open using root permissions
> > - Use command 'pkill nautilus'
> >
> > I can replicate this issue on two separate computers running Debian 8.7
>
> I don't see this happening on either jessie or sid.  Does this only
> happen under some particular circumstance, like a particular file, a
> large directory, a network filesytem, etc?
>

Bug#846548: patch for #846548

[Luke Faraone]

On Thu, 11 May 2017 20:33:41 -0700 Luke W Faraone <lfara...@debian.org> wrote:
> On Thu, 11 May 2017 19:45:51 -0700 Luke W Faraone <lfara...@debian.org>
> wrote:
> > Attached is a patch to fix the path to the engine directory, and moves
> > this library back to libssl-dev. (it isn't clear to me from changelog or
> > git log why the move to 1.1 was originally reverted)
> 
> And of course, that patch was bogus. Attached is a orrected patch. I
> intend to upload this to DELAYED/5 once I have a chance to test on real
> hardware. 

Tested (attached) and uploaded accordingly.

  -- Luke$ openssl req -engine pkcs11 -keyform engine -new -key "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=[…];token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;type=private" -out req.pem -text -x509 -subj '/CN=Luke Faraone'
engine "pkcs11" set.
No private keys found.
PKCS#11 token PIN: 
cobalt:/tmp/tmp.1Pc1kTLqDp$ cat req.pem 
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a7:78:4e:07:98:95:7d:95
    Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = Luke Faraone
Validity
Not Before: May 13 20:07:39 2017 GMT
    Not After : Jun 12 20:07:39 2017 GMT
Subject: CN = Luke Faraone
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
	[…]
-BEGIN CERTIFICATE-
[…]
-END CERTIFICATE-



signature.asc
Description: This is a digitally signed message part

Bug#846548: patch for #846548

[Luke W Faraone]

On Thu, 11 May 2017 19:45:51 -0700 Luke W Faraone <lfara...@debian.org>
wrote:
> Attached is a patch to fix the path to the engine directory, and moves
> this library back to libssl-dev. (it isn't clear to me from changelog or
> git log why the move to 1.1 was originally reverted)

And of course, that patch was bogus. Attached is a orrected patch. I
intend to upload this to DELAYED/5 once I have a chance to test on real
hardware. Below from a VM:

# dpkg -L libssl1.1 | grep engine | head -n 1
/usr/lib/x86_64-linux-gnu/engines-1.1
# dpkg -L libengine-pkcs11-openssl | grep /pkcs11.so
/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so

# openssl engine pkcs11 -t
(pkcs11) pkcs11 engine
 [ available ]


>   -- Luke

diff -Nru libp11-0.4.4/debian/changelog libp11-0.4.4/debian/changelog
--- libp11-0.4.4/debian/changelog   2017-01-28 08:13:56.0 +
+++ libp11-0.4.4/debian/changelog   2017-05-12 02:20:40.0 +
@@ -1,3 +1,11 @@
+libp11 (0.4.4-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Link against libssl 1.1, since `openssl` is built against it.
+  * debian/rules: Fix path to OpenSSL engine directory. (Closes: #846548)
+
+ -- Luke Faraone <lfara...@debian.org>  Thu, 11 May 2017 19:20:40 -0700
+
 libp11 (0.4.4-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libp11-0.4.4/debian/control libp11-0.4.4/debian/control
--- libp11-0.4.4/debian/control 2017-01-28 08:13:56.0 +
+++ libp11-0.4.4/debian/control 2017-05-12 02:20:40.0 +
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 10),
libltdl3-dev,
libp11-kit-dev,
-   libssl1.0-dev,
+   libssl-dev,
pkg-config
 Standards-Version: 3.9.8
 Homepage: https://github.com/OpenSC/libp11
@@ -16,7 +16,7 @@
 Package: libp11-dev
 Architecture: any
 Depends: libp11-2 (= ${binary:Version}),
- libssl1.0-dev,
+ libssl-dev,
  pkg-config,
  ${misc:Depends}
 Description: pkcs#11 convenience library - development files
diff -Nru libp11-0.4.4/debian/libengine-pkcs11-openssl.install 
libp11-0.4.4/debian/libengine-pkcs11-openssl.install
--- libp11-0.4.4/debian/libengine-pkcs11-openssl.install2017-01-28 
08:13:56.0 +
+++ libp11-0.4.4/debian/libengine-pkcs11-openssl.install2017-05-12 
02:20:40.0 +
@@ -1 +1 @@
-usr/lib/*/openssl-*/engines/*
+usr/lib/*/engines-*/*
diff -Nru libp11-0.4.4/debian/rules libp11-0.4.4/debian/rules
--- libp11-0.4.4/debian/rules   2017-01-28 08:13:56.0 +
+++ libp11-0.4.4/debian/rules   2017-05-12 02:20:40.0 +
@@ -2,8 +2,8 @@
 
 include /usr/share/dpkg/architecture.mk
 
-OPENSSL_VERSION := $(shell pkg-config --modversion openssl | sed "s/[a-z]$$//")
-ENGINES_DIR := /usr/lib/$(DEB_HOST_GNU_TYPE)/openssl-$(OPENSSL_VERSION)/engines
+OPENSSL_VERSION := $(shell pkg-config --modversion openssl | sed "s/[a-z]$$//" 
| cut -d . -f -2)
+ENGINES_DIR := /usr/lib/$(DEB_HOST_GNU_TYPE)/engines-$(OPENSSL_VERSION)/
 
 %:
dh $@


signature.asc
Description: OpenPGP digital signature

Bug#846548: patch for #846548

[Luke W Faraone]

control: tag 846548 + patch

On Sat, 6 May 2017 19:07:50 +0200 Enrico Zini <enr...@enricozini.org> wrote:
> Hello,
> 
> I'm raising severity to serious since as far as I can see the package is
> currently unusable in testing without a rebuild.

Sadly not even a rebuild will fix it. The issue is that debian/rules
specifies:

  OPENSSL_VERSION := $(shell pkg-config --modversion openssl | sed
"s/[a-z]$$//")

Which, in current unstable, resolves to:
  # pkg-config --modversion openssl | sed "s/[a-z]$//"
  1.1.0

Yet, ``openssl`` tries to find engines in
``/usr/lib/x86_64-linux-gnu/engines-1.1/``:

  # openssl engine foo
  139873873437888:error:25066067:DSO support routines:dlfcn_load:could
not load the shared
library:../crypto/dso/dso_dlfcn.c:113:filename(/usr/lib/x86_64-linux-gnu/engines-1.1/foo.so):
/usr/lib/x86_64-linux-gnu/engines-1.1/foo.so: cannot open shared object
file: No such file or directory
  139873873437888:error:25070067:DSO support routines:DSO_load:could not
load the shared library:../crypto/dso/dso_lib.c:161:
  139873873437888:error:260B6084:engine routines:dynamic_load:dso not
found:../crypto/engine/eng_dyn.c:414:
  139873873437888:error:2606A074:engine routines:ENGINE_by_id:no such
engine:../crypto/engine/eng_list.c:339:id=foo

This is a change from jessie, where it looks in
``/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/``.

Attached is a patch to fix the path to the engine directory, and moves
this library back to libssl-dev. (it isn't clear to me from changelog or
git log why the move to 1.1 was originally reverted)

  -- Luke
diff -Nru libp11-0.4.4/debian/changelog libp11-0.4.4/debian/changelog
--- libp11-0.4.4/debian/changelog   2017-01-28 08:13:56.0 +
+++ libp11-0.4.4/debian/changelog   2017-05-12 02:20:40.0 +
@@ -1,3 +1,11 @@
+libp11 (0.4.4-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Link against libssl 1.1, since `openssl` is built against it.
+  * debian/rules: Fix path to OpenSSL engine directory. (Closes: #846548)
+
+ -- Luke Faraone <lfara...@debian.org>  Thu, 11 May 2017 19:20:40 -0700
+
 libp11 (0.4.4-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libp11-0.4.4/debian/control libp11-0.4.4/debian/control
--- libp11-0.4.4/debian/control 2017-01-28 08:13:56.0 +
+++ libp11-0.4.4/debian/control 2017-05-12 02:20:40.0 +
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 10),
libltdl3-dev,
libp11-kit-dev,
-   libssl1.0-dev,
+   libssl-dev,
pkg-config
 Standards-Version: 3.9.8
 Homepage: https://github.com/OpenSC/libp11
@@ -16,7 +16,7 @@
 Package: libp11-dev
 Architecture: any
 Depends: libp11-2 (= ${binary:Version}),
- libssl1.0-dev,
+ libssl-dev,
  pkg-config,
  ${misc:Depends}
 Description: pkcs#11 convenience library - development files
diff -Nru libp11-0.4.4/debian/rules libp11-0.4.4/debian/rules
--- libp11-0.4.4/debian/rules   2017-01-28 08:13:56.0 +
+++ libp11-0.4.4/debian/rules   2017-05-12 02:20:05.0 +
@@ -2,7 +2,7 @@
 
 include /usr/share/dpkg/architecture.mk
 
-OPENSSL_VERSION := $(shell pkg-config --modversion openssl | sed "s/[a-z]$$//")
+OPENSSL_VERSION := $(shell pkg-config --modversion openssl | sed "s/[a-z]$$//" 
| cut -d . -f -2)
 ENGINES_DIR := /usr/lib/$(DEB_HOST_GNU_TYPE)/openssl-$(OPENSSL_VERSION)/engines
 
 %:


signature.asc
Description: OpenPGP digital signature

Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files

[Luke]

Package: nautilus
Version: 3.14.1-2
Severity: important

Dear Maintainer,

Method
~~
1.) Open up Nautilus
2.) Navigate to a folder where you want to find the file size of contents
3.) Select the file(s)/folder(s), right hand click
4.) Click on the option "Properties" in the menu

Expected Results

Properties dialog will appear


Actual Results
~~
Nautilus will lock up, will not be able to use it even if I have multiple
windows opened. Eventually Gnome will inform me that Nautilus has potentially
crashed.
Other times, it has taken over a minute to load the properties dialog.

Notes
~
Does not happen all the time, about 50% for me. When it does occur Nautilus
will not open unless I either;
- Open using root permissions
- Use command 'pkill nautilus'

I can replicate this issue on two separate computers running Debian 8.7



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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.22-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  gvfs   1.22.2-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u7
ii  libcairo-gobject2  1.14.0-2.1+deb8u2
ii  libcairo2  1.14.0-2.1+deb8u2
ii  libexempi3 2.2.1-2
ii  libexif12  0.6.21-2
ii  libgail-3-03.14.5-1+deb8u1
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u5
ii  libglib2.0-0   2.42.1-1+b1
ii  libglib2.0-data2.42.1-1
ii  libgnome-desktop-3-10  3.14.1-1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libnautilus-extension1a3.14.1-2
ii  libnotify4 0.7.6-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libselinux12.3-2
ii  libtracker-sparql-1.0-01.2.4-2
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-5+deb8u4
ii  nautilus-data  3.14.1-2
ii  shared-mime-info   1.3-1

Versions of packages nautilus recommends:
ii  eject  2.1.5+deb1+cvs20081104-13.1+deb8u1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gnome-sushi3.12.0-2+b1
ii  gvfs-backends  1.22.2-1
ii  librsvg2-common2.40.5-1+deb8u2

Versions of packages nautilus suggests:
ii  brasero3.11.4-1.1
ii  eog3.14.1-1
ii  evince [pdf-viewer]3.14.1-2+deb8u1
ii  totem  3.14.0-2
ii  tracker1.2.4-2
ii  vlc [mp3-decoder]  2.2.4-1~deb8u1
ii  vlc-nox [mp3-decoder]  2.2.4-1~deb8u1
ii  xdg-user-dirs  0.15-2

-- no debconf information

Bug#858377: libblkmaker outdated in Debian

[Luke Dashjr]

BFGMiner should work just fine with the git version of libblkmaker, and 
doesn't require libblkmaker to work correctly in many common cases.

The simplest solution would be to simply bump libblkmaker.

Bug#860898: [Tts-project] Bug#860898: (no subject)

[Luke Yelavich]

On Sun, Apr 30, 2017 at 12:25:39AM AEST, Samuel Thibault wrote:
> Well, AIUI this has been broken for a long time without being reported.
> And thus AIUI people just configure speech-dispatcher with the config
> files and don't use spd-conf. Again, this is just my understanding, I'm
> not a user of speech-dispatcher, so users should say so if it's really a
> problem.

Speech Dispatcher should also just work with the default config. If it 
doesn't, then we should tweak the defaults so that it does. I think people 
are just used to using spd-conf from when it may have been more of a hard 
requirement in the past.

Luke

Bug#860789: Acknowledgement (freecad: import of openscad file turns "differences" into "unions")

[Luke Kenneth Casson Leighton]

ah: i hadn't spotted this: it would appear that a legitimate scad file
is considered to be a syntax error by freecad's parser.

Parser Loaded
Start Parser
Vector
Vector
Vector
Vector
Vector
Matrix
Syntax error in input!
LexToken(SEMICOL,';',23,603)
Vector
Vector
Vector
Vector
Matrix
('$fn', '100')
('$fa', '12')
('$fs', '2')
('h', '19')
('r1', '2.5')
('r2', '2.5')
('center', 'true')
Cylinder
{'r1': '2.5', 'r2': '2.5', 'h': '19', '$fs': '2', '$fn': '100', '$fa':
'12', 'center': 'true'}
Make Cylinder
Center = true
End Cylinder
Block List
[]
End Block List
MultMatrix
Multmatrix
[['1', '0', '0', '2.5'], ['0', '1', '0', '2.5'], ['0', '0', '1',
'9.5'], ['0', '0', '0', '1']]
Matrix ((1,0,0,2.5),(0,1,0,2.5),(0,0,1,9.5),(0,0,0,1))
Apply Multmatrix
special orthogonal
rotation rounded
Multmatrix applied
Block List
[]
End Block List
Syntax error in input!
LexToken(EBRACE,'}',27,855)
Vector
Vector
Vector
Vector

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Apr 18, 2017 at 4:08 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 18/04/17 11:55 AM, Luke Kenneth Casson Leighton wrote:
>> On Tue, Apr 18, 2017 at 3:27 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>>
>>>> far from being 100% reproducible when resizing glxgears under fvwm2
>>>> with DRI2, glxgears freezing is now 100% *un*reproducible.
>>>
>>> Please attach the Xorg log file.
>
> [...]
>
>> [   274.721] xorg-server 2:1.19.0-2.0nosystemd1 
>> (https://www.debian.org/support)
>
> The "nosystemd1" suggests that your xserver-xorg-core package isn't from
> Debian.

 it is... it's a modified recompiled version that is exactly identical
to debian, with the sole exception being that its compile-time options
are modified to include "--without-systemd" in the configure phase.

> Please report wherever you got it from that this support URL is
> misleading.
>
> The symptoms you're describing match a known bug in Xorg 1.19.0.

  ah ha!  at last!  dang was that hard to find someone who knows what
the underlying issue is.

> Please
> upgrade to 1.19.1 or newer.

 will do.

 l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Apr 18, 2017 at 3:27 AM, Michel Dänzer  wrote:

>> far from being 100% reproducible when resizing glxgears under fvwm2
>> with DRI2, glxgears freezing is now 100% *un*reproducible.
>
> Please attach the Xorg log file.

 not too much to see, here, michel (yes it really is only 58 lines
long).  also including cat /proc/version and relevant section from
xorg.conf


lkcl@fizzy:/etc/X11$ cat /proc/version
Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc
version 6.3.0 20170124 (Debian 6.3.0-5) ) #1 SMP Debian 4.9.6-3
(2017-01-28)


Section "Device"
Identifier  "Intel Graphics"
Driver  "intel"
BusID   "PCI:0:2:0"
#Driver  "nvidia"
#BusID   "PCI:1:0:0"
#Option "SwapBuffersWait"   "false"
Option "AccelMethod""sna"
Option "TearFree"   "true"
Option  "DRI"   "3"
EndSection
[   274.305] 
X.Org X Server 1.19.0
Release Date: 2016-11-15
[   274.383] X Protocol Version 11, Revision 0
[   274.428] Build Operating System: Linux 4.8.10+ x86_64 Debian
[   274.483] Current Operating System: Linux fizzy 4.7.8lkcl #1 SMP Sun Dec 11 00:13:10 GMT 2016 x86_64
[   274.534] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.7.8lkcl root=/dev/mapper/pc-root ro quiet rcutree.rcu_idle_gp_delay=1
[   274.676] Build Date: 25 November 2016  03:55:18AM
[   274.721] xorg-server 2:1.19.0-2.0nosystemd1 (https://www.debian.org/support) 
[   274.765] Current version of pixman: 0.33.6
[   274.815] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[   274.855] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   275.250] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 12 00:03:16 2016
[   275.600] (==) Using config file: "/etc/X11/xorg.conf"
[   275.644] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   275.982] (==) ServerLayout "X.org Configured"
[   276.013] (**) |-->Screen "Screen0" (0)
[   276.043] (**) |   |-->Monitor "Monitor0"
[   276.074] (**) |   |-->Device "Intel Graphics"
[   276.103] (**) |-->Input Device "Mouse0"
[   276.134] (==) Automatically adding devices
[   276.164] (==) Automatically enabling devices
[   276.194] (==) Automatically adding GPU devices
[   276.225] (==) Max clients allowed: 256, resource mask: 0x1f
[   276.286] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   276.318] 	Entry deleted from font path.
[   276.481] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   276.511] 	Entry deleted from font path.
[   276.645] (**) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins,
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[   276.674] (**) ModulePath set to "/usr/lib/xorg/modules"
[   276.705] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[   276.734] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   276.765] (WW) Disabling Mouse0
[   276.795] (II) Loader magic: 0x55f4e523cd40
[   276.826] (II) Module ABI versions:
[   276.856] 	X.Org ANSI C Emulation: 0.4
[   276.887] 	X.Org Video Driver: 23.0
[   276.917] 	X.Org XInput driver : 24.1
[   276.947] 	X.Org Server Extension : 10.0
[   277.386] (II) xfree86: Adding drm device (/dev/dri/card0)

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ok so i ended up with an unancipated reboot, which meant i had an
opportunity to test DRI3 and since setting Option DRI "3" in
xorg.conf i have *not* encountered a *single* lock-up, not with
chromium, nor glxgears, nor openscad.

far from being 100% reproducible when resizing glxgears under fvwm2
with DRI2, glxgears freezing is now 100% *un*reproducible.

so there is definitely a case to be said that this is a mesa / x11
bug, *not* an application-specific bug.

does anyone know how to move bugs to a different package?

l.