Bug#1063468: linux-image-6.1.0-17-amd64: Loud squeals/crackles from Steelseries 2 Channel HD Audio chipset after restarting from Windows 11
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=
Bug#1055246: kde-config-plymouth: Does not appear in system settings
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
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
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
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"))
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"))
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"))
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")
--- 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")
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")
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
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))
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
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
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
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
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 Inc
Bug#718272: Processed: reopening 718272
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
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
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..."
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..."
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
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.
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
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)
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)
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)
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)
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
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
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
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)
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
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: Res
Bug#949747: closed by Simon McVittie (Re: Bug#949747: gimp: dependency versions missing)
thank you simon, i've passed that on to christian. l.
Bug#864997: DEP-5 copyright checker
[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&src=lintian > > Kind regards > Felix Lechner >
Bug#940701: nautilus-dropbox: diff for NMU version 2019.02.14-0.1
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--- 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
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
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
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
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)
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
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
>> >> 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
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
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?
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
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.
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
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)
On Sun, Apr 15, 2018 at 7:39 PM, Ludovic Rousseau 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 KERNEL[437890.511743] bind
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
On Sun, Apr 15, 2018 at 6:01 PM, Ludovic Rousseau 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 [36m0021[0m [34mpcscdaemon.c:352:main() Force colored logs[0m [36m0680[0m configfile.l:285:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d [36m0022[0m configfile.l:322:DBGetReaderListDir() Skipping non regular file: . [36m0004[0m configfile.l:361:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/libccidtwin [36m0030[0m configfile.l:322:DBGetReaderListDir() Skipping non regular file: .. [36m0005[0m [34mpcscdaemon.c:662:main() pcsc-lite 1.8.23 daemon ready.[0m [36m0771[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ACS ACR 38U-CCID[0m [36m0005[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ActivIdentity USB Reader V3[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ActivIdentity Activkey_Sim[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Alcor Micro AU9520[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Alcor Micro AU9560[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Athena ASE IIIe[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Athena ASEDrive IIIe KB[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: BLUTRONICS BLUDRIVE II CCID[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: C3PO LTC31 v2[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartBoard XX33[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartBoard XX44[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartTerminal XX44[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartTerminal ST-2xxx[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: COVADIS ALYA[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Dell keyboard SK-3106[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Dell Dell Smart Card Reader Keyboard[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron CryptoIdentity CCID[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron CryptoIdentity CCID[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Digipass 860[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Card Reader[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Smart Pocket[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto PDT[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto PC Twin Reader[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto USB Shell Token V2[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto USB GemPCPinpad SmartCard Reader[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto GemCore SIM Pro Smart Card Reader[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Ezio Shield[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto EZIO CB+[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Gemplus USB SmartCard Reader 433-Swap[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Prox Dual USB PC Link Reader[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Prox SU USB PC LinkReader[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Smart Enterprise Guardian Secure USB Device[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto IDBridge K3000[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Giesecke & Devrient GmbH StarSign Crypto USB Token[0m [36m0002[0m [3
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
Enclosed. Doesn't appear to have changed the output. On Sun, Apr 15, 2018 at 3:49 PM, Ludovic Rousseau 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 [36m0015[0m [34mpcscdaemon.c:352:main() Force colored logs[0m [36m0093[0m configfile.l:285:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d [36m0016[0m configfile.l:322:DBGetReaderListDir() Skipping non regular file: . [36m0003[0m configfile.l:361:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/libccidtwin [36m0033[0m configfile.l:322:DBGetReaderListDir() Skipping non regular file: .. [36m0006[0m [34mpcscdaemon.c:662:main() pcsc-lite 1.8.23 daemon ready.[0m [36m0613[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ACS ACR 38U-CCID[0m [36m0005[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ActivIdentity USB Reader V3[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ActivIdentity Activkey_Sim[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Alcor Micro AU9520[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Alcor Micro AU9560[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Athena ASE IIIe[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Athena ASEDrive IIIe KB[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: BLUTRONICS BLUDRIVE II CCID[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: C3PO LTC31 v2[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartBoard XX33[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartBoard XX44[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartTerminal XX44[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartTerminal ST-2xxx[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: COVADIS ALYA[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Dell keyboard SK-3106[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Dell Dell Smart Card Reader Keyboard[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron CryptoIdentity CCID[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron CryptoIdentity CCID[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Digipass 860[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Card Reader[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Smart Pocket[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto PDT[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto PC Twin Reader[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto USB Shell Token V2[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto USB GemPCPinpad SmartCard Reader[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto GemCore SIM Pro Smart Card Reader[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Ezio Shield[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto EZIO CB+[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Gemplus USB SmartCard Reader 433-Swap[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found dr
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
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 [36m0008[0m [34mpcscdaemon.c:352:main() Force colored logs[0m [36m0054[0m configfile.l:285:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d [36m0011[0m configfile.l:322:DBGetReaderListDir() Skipping non regular file: . [36m0002[0m configfile.l:361:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/libccidtwin [36m0021[0m configfile.l:322:DBGetReaderListDir() Skipping non regular file: .. [36m0005[0m [34mpcscdaemon.c:662:main() pcsc-lite 1.8.23 daemon ready.[0m [36m0421[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ACS ACR 38U-CCID[0m [36m0003[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ActivIdentity USB Reader V3[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: ActivIdentity Activkey_Sim[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Alcor Micro AU9520[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Alcor Micro AU9560[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Athena ASE IIIe[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Athena ASEDrive IIIe KB[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: BLUTRONICS BLUDRIVE II CCID[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: C3PO LTC31 v2[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartBoard XX33[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartBoard XX44[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartTerminal XX44[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Cherry GmbH SmartTerminal ST-2xxx[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: COVADIS ALYA[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Dell keyboard SK-3106[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Dell Dell Smart Card Reader Keyboard[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron CryptoIdentity CCID[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron CryptoIdentity CCID[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Digipass 860[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Card Reader[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Eutron Smart Pocket[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto PDT[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto PC Twin Reader[0m [36m0002[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto USB Shell Token V2[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto USB GemPCPinpad SmartCard Reader[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto GemCore SIM Pro Smart Card Reader[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Ezio Shield[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto EZIO CB+[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Gemplus USB SmartCard Reader 433-Swap[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Prox Dual USB PC Link Reader[0m [36m0005[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Prox SU USB PC LinkReader[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto Smart Enterprise Guardian Secure USB Device[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Gemalto IDBridge K3000[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Giesecke & Devrient GmbH StarSign Crypto USB Token[0m [36m0001[0m [34mhotplug_libudev.c:218:HPReadBundleValues() Found driver for: Giesecke & Devrien
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
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
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&MSPPError=-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))
On Mon, Feb 26, 2018 at 7:51 AM, Thijs Kinkhorst 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)
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
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
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
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
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 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
Bug#877370: Doesn't allow saying "do not print answers"
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
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
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)
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"
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
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 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
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 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
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
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
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 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 w
Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files
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 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
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
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 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
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 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
On Thu, 11 May 2017 20:33:41 -0700 Luke W Faraone wrote: > On Thu, 11 May 2017 19:45:51 -0700 Luke W Faraone > 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
On Thu, 11 May 2017 19:45:51 -0700 Luke W Faraone 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 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
control: tag 846548 + patch On Sat, 6 May 2017 19:07:50 +0200 Enrico Zini 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 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
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
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)
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")
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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Apr 18, 2017 at 4:08 AM, Michel Dänzer 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 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
--- 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
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.