Bug#1019588: jdupes: BTRFS deduplication broken by new update
Package: jdupes Version: 1.21.0-1 Severity: normal Dear Maintainer, When running jdupes -rB ./ in a folder on a BTRFS filesystem, I got errors for every file: eg, [SRC] ./.git/logs/HEAD -XX-> ./.git/logs/refs/heads/master error: Inappropriate ioctl for device (25) I have been running jdupes -B fairly regularly on various files on my device; the problems have only started now, after the most recent update of jdupes. I'm wondering if the kernel API for file deduplication changed, or strace says this is the called ioctl: ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x5e, 0x36, 0x18), 0x55732fa9b4e0) = -1 ENOTTY (Inappropriate ioctl for device) The bug is in upstream: in commit 0027bb2c8, the new static header incorrectly states the literal: it transforms BTRFS_IOCTL_MAGIC from the hexadecimal 0x94 (decimal 148) to the decimal 94 This is problematic: the patch is fairly trivial (add 0x to line 23 of linux-dedupe-static.h). I do wonder why the static header is used, rather than the proper kernel headers. I'll also put this bug upstream, filing it here because I started the report before I finished poking around it's cause. Thanks! Calum McConnell -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jdupes depends on: ii libc6 2.34-7 jdupes recommends no packages. jdupes suggests no packages. -- no debconf information
Bug#973831: gnome-shell: Login hangs after system suspend
The bug is NOT triggered if I wait a few seconds before entering my password. signature.asc Description: This is a digitally signed message part
Bug#974013: myrepos: mr list fails to actually list the repositories
retitle mr list fails if jobs is more than 1 On Mon, 2020-11-09 at 11:59 +0800, Paul Wise wrote: > On Sun, 2020-11-08 at 21:57 -0500, Calum McConnell wrote: > > > It works perfectly (though with a blank space between each entry for > > some > > reason). .mrconfig is exactly as you'd expect: I attached it as > > mrconfig- > > testuser > > So the issue sounds like it is caused by something that is in your user > home directory rather than something in mr. The issue arises regardless of where I execute mr from: be it inside a repository, inside GitGud/*, or in the home directory. > The blank line is expected, since the list option just runs `true` and > all mr actions get a blank line between them. > > Does the same thing happen if you run `mr list` in your user home > directory but outside your usual shell environment? For example in > GNOME you can use the run dialog to run this command and then check the > tmp-mr-list file afterwards: > >sh -c 'mr list > tmp-mr-list' Same output :( > Does your shell list any aliases related to mr? > >alias | grep mr It did, adding one to increase job count before I worked out the .mrconfig file, but even after I removed it and started a new shell session without the alias (I double-checked) the issue persisted > Does your shell have any functions related to mr? > >set | grep -C5 mr There is one match, in _cd_devices's compgen function. Other than that, clean. After all those dead-ends, I decided to do a more intensive test with the new user. I transferred all the repositories, and found that it ran normally. I then tried to modify the .mrconfig file, and found that the trigger was the 'jobs' specifier. I had tried commenting out jobs before, but it must not have applied, because I had earlier set the alias to always run some jobs in parallel. I don't know if the bug retitle will apply, but we shall see. signature.asc Description: This is a digitally signed message part
Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs
On Sun, 2020-10-25 at 11:24 -0400, calumlikesapple...@gmail.com wrote: > On Sun, 2020-10-25 at 11:04 +0100, Niels Thykier wrote: > > Hi again, > > > > Thanks for the data. Unfortunately, it did reveal a smoking gun, > > so > > I > > think we need /tmp/update.log generated from this command. > > > > apt -o Debug::pkgAcquire::Worker=1 \ > > -o Debug::pkgAcquire::Diffs=1 update \ > > 2>&1 | tee /tmp/update.log > > Attached. > > > Please attach the file rather than copy-paste in the output from > > it. > > Sure! I just wasn't sure if attaching was standard, or if you'd > gotten > my original attachment. I just realized that I forgot to mention something important: the issue doesn't happen every time I run apt update, and even sometimes when it needs to update other files, it doesn't wind up updating the contents. I'll log my manual updates for the next week (gnome-software sometimes runs it in the background), in case this log is useless. signature.asc Description: This is a digitally signed message part
Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs
On Sun, 2020-10-25 at 11:04 +0100, Niels Thykier wrote: > Hi again, > > Thanks for the data. Unfortunately, it did reveal a smoking gun, so > I > think we need /tmp/update.log generated from this command. > > apt -o Debug::pkgAcquire::Worker=1 \ > -o Debug::pkgAcquire::Diffs=1 update \ > 2>&1 | tee /tmp/update.log Attached. > Please attach the file rather than copy-paste in the output from it. Sure! I just wasn't sure if attaching was standard, or if you'd gotten my original attachment. WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Starting method '/usr/lib/apt/methods/http' <- http:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2 Configured access method http Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0 Starting method '/usr/lib/apt/methods/https' <- https:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2 Configured access method https Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0 Starting method '/usr/lib/apt/methods/http' <- http:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2 Configured access method http Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0 ->
Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs
> > Basically, on every call to apt-update that isn't completely > > trivial (ie, at least > > 1 package changed), my computer downloads the full 60 Mb of > > Contents files. This > > is irritating, for while I am often on a fast internet, I > > frequently find myself on > > a very slow connection. > > > > I know my config file enables pdiffs (and I attached it so you can > > know, too). > > The Readme talks a lot about pdiffs, and why I should enable them, > > but except for > > one sentence, it doesn't mention anything about apt update. (The > > sentence in > > question *could* be interpreted to mean that apt update will never > > download > > Pdiffs, but that is unlikely, given its context). > > > > I don't know what's the cause. If you need me to get a log file, I > > can, but > > Apt doesnt include these files in its final output: only while it > > is > > drawing progress bars. > > > > Thank you! > > Calum > > > > [...] > > > > > Hi Calum, > I am sorry to hear it does not work as expected. > All of the Contents downloading is outsourced to apt, so most likely > it is a configuration (or a bug in apt itself). Can you provide the > output/contents of? > $ apt-config dump Acquire::IndexTargets I'll paste the full output below > file:/etc/apt/apt-file.conf (if it exists) This file doesn't exist, though I attached what I think is it's equivalent in my initial message. > This will show the effective fetching configuration for apt and apt- > file. > Relatedly, just to confirm: The bug is on the system you are > reporting > from (i.e. running testing/sid) and you run "apt update" at least > once a week. Are these assumptions of mine correct? Yes, that's correct. apt-config dump Aquire::IndexTargets output: Acquire::IndexTargets ""; Acquire::IndexTargets::deb ""; Acquire::IndexTargets::deb::Packages ""; Acquire::IndexTargets::deb::Packages::MetaKey "$(COMPONENT)/binary- $(ARCHITECTURE)/Packages"; Acquire::IndexTargets::deb::Packages::flatMetaKey "Packages"; Acquire::IndexTargets::deb::Packages::ShortDescription "Packages"; Acquire::IndexTargets::deb::Packages::Description "$(RELEASE)/$(COMPONENT) $(ARCHITECTURE) Packages"; Acquire::IndexTargets::deb::Packages::flatDescription "$(RELEASE) Packages"; Acquire::IndexTargets::deb::Packages::Optional "0"; Acquire::IndexTargets::deb::Translations ""; Acquire::IndexTargets::deb::Translations::MetaKey "$(COMPONENT)/i18n/Translation-$(LANGUAGE)"; Acquire::IndexTargets::deb::Translations::flatMetaKey "$(LANGUAGE)"; Acquire::IndexTargets::deb::Translations::ShortDescription "Translation-$(LANGUAGE)"; Acquire::IndexTargets::deb::Translations::Description "$(RELEASE)/$(COMPONENT) Translation-$(LANGUAGE)"; Acquire::IndexTargets::deb::Translations::flatDescription "$(RELEASE) Translation-$(LANGUAGE)"; Acquire::IndexTargets::deb::DEP-11 ""; Acquire::IndexTargets::deb::DEP-11::MetaKey "$(COMPONENT)/dep11/Components-$(NATIVE_ARCHITECTURE).yml"; Acquire::IndexTargets::deb::DEP-11::ShortDescription "Components- $(NATIVE_ARCHITECTURE)"; Acquire::IndexTargets::deb::DEP-11::Description "$(RELEASE)/$(COMPONENT) $(NATIVE_ARCHITECTURE) DEP-11 Metadata"; Acquire::IndexTargets::deb::DEP-11::KeepCompressed "true"; Acquire::IndexTargets::deb::DEP-11::KeepCompressedAs "gz"; Acquire::IndexTargets::deb::DEP-11-icons-small ""; Acquire::IndexTargets::deb::DEP-11-icons-small::MetaKey "$(COMPONENT)/dep11/icons-48x48.tar"; Acquire::IndexTargets::deb::DEP-11-icons-small::ShortDescription "icons-48x48"; Acquire::IndexTargets::deb::DEP-11-icons-small::Description "$(RELEASE)/$(COMPONENT) DEP-11 48x48 Icons"; Acquire::IndexTargets::deb::DEP-11-icons-small::KeepCompressed "true"; Acquire::IndexTargets::deb::DEP-11-icons-small::KeepCompressedAs "gz"; Acquire::IndexTargets::deb::DEP-11-icons-small::DefaultEnabled "true"; Acquire::IndexTargets::deb::DEP-11-icons ""; Acquire::IndexTargets::deb::DEP-11-icons::MetaKey "$(COMPONENT)/dep11/icons-64x64.tar"; Acquire::IndexTargets::deb::DEP-11-icons::ShortDescription "icons- 64x64"; Acquire::IndexTargets::deb::DEP-11-icons::Description "$(RELEASE)/$(COMPONENT) DEP-11 64x64 Icons"; Acquire::IndexTargets::deb::DEP-11-icons::KeepCompressed "true"; Acquire::IndexTargets::deb::DEP-11-icons::KeepCompressedAs "gz"; Acquire::IndexTargets::deb::DEP-11-icons::DefaultEnabled "true"; Acquire::IndexTargets::deb::DEP-11-icons-hidpi ""; Acquire::IndexTargets::deb::DEP-11-icons-hidpi::MetaKey "$(COMPONENT) /dep11/icons-64...@2.tar"; Acquire::IndexTargets::deb::DEP-11-icons-hidpi::ShortDescription " icons-64x64@2"; Acquire::IndexTargets::deb::DEP-11-icons-hidpi::Description "$(RELEASE)/$(COMPONENT) DEP-11 64x64@2 Icons"; Acquire::IndexTargets::deb::DEP-11-icons-hidpi::KeepCompressed "true"; Acquire::IndexTargets::deb::DEP-11-icons-hidpi::KeepCompressedAs "gz"; Acquire::IndexTargets::deb::DEP-11-icons-hidpi::DefaultEnabled "false"; Acquire::IndexTargets::deb::DEP-11-icons-large ""; Acquire::IndexTargets::deb::DEP-11-icons-large::MetaKey
Bug#972605: jekyll: Please update to new 4.x branch
On Wed, 2020-10-21 at 15:12 +0200, Daniel Leidert wrote: > Am Dienstag, den 20.10.2020, 23:33 -0400 schrieb Calum McConnell: > > > Jekyll upstream has been concentrating on a new 4.x release branch > > for the > > past year. It provides a significant set of new features that I > > use, and it > > would be great if it could be included in debian. > > > > I assume you know all of that already, since 3.9 released after > > 4.0, but I > > was wondering what the rationale was for sticking with the 3.x > > branch. > > It is very stable and well tested. Also not all plugins had been > ported to > Jekyll 4 at the beginning of the year (not sure about the current > state). > Further it would make backporting to current stable a lot more > complicated. > I'm not aware of any ground-breaking changes. What features are you > referring to? Its not exactly ground-breaking (I might have exaggerated 'significant'), but the caching system is really handy. I like to iterate rapidly, and a cache is really, really helpful for that: it halves build times. Also, there a bunch of little changes, such as relative-url, that I appreciate. The sort of changes that a user might try to use, and then be confused as to why they don't work. The biggest reason, though, is that 3.9 is like Python 2.7: it's probably the last release of the series. According to rubygems, 3.9.0 has a third the downloads of 4.1.1, and a sixth of 4.0.0: its clear people are moving up to the next version, and will eventually need to do so if they want to keep getting support for plugins. I believe there are already some 4.0-only plugins. In short, we probably ought to have it in Bullseye before we release. > The 4.x series will be uploaded to experimental eventually. But I'm > hesitant to upload it to unstable just now. Okay: fair enough. But the 4.0 branch is about a year old, and I haven't really felt any major issues with it. I think most plugins have upgraded by now: Thanks for considering. Let's keep this bug open, so that you don't get another person reporting. signature.asc Description: This is a digitally signed message part
Bug#954824: chromium: Enable PipeWire support in WebRTC
severity: minor (I have no idea if that will work: I'm not a DD, nor the reporter. But this is definitely minor, if not normal) On Wed, 22 Apr 2020 11:43:48 +0200 Domenico Cufalo wrote: > Dear Maintainer, > > I would like to add my vote in favor of the request to enable > PipeWire support. As would I > Yes, I do know that this request, as it seems, has already been > rejected for security reasons (see bug #886358)*, Actually, though the bugs look related, they aren't. That bug is about installing Google-specific extensions to chromium by default. This one regards enabling a setting. To be clear, the change wouldn't enable it for everyone: it would only make it possible for it to be enabled by a savvy user. > but this lack > renders Chromium unusable for remote working and this is a problem in > a period like this, characterized by the lock-down for Covid-19. > > Due to this lack I was forced to install Google Chrome, but i would > by far prefer to be able to use Chromium, instead. I agree. I would rather not have to install Chrome manually, especially when such a minor change could make the difference. > Therefore, I would ask you to reconsider the question of whether to > enable that support, if possible. > > In the meantime, I thank you for all your efforts in maintaining this > excellent browser and I send you my best regards. I agree here, too. It looks like your trying to maintain packaging for one of the largest open-source projects on your own (at least, with only 1 other person helping). If you need a hand, just ask! signature.asc Description: This is a digitally signed message part
Bug#970639: Zswap Disabled By Default
I figured I should ping this, since I don't know that it was properly shown to the debian-kernel mailing list. > Interestingly it still contains the following note in documentation: > Zswap is a new feature as of v3.11 and interacts heavily with > memory reclaim. This interaction has not been fully explored on > the large set of potential configurations and workloads that > exist. For this reason, zswap is a work in progress and should be > considered experimental. > Unless this is not anymore to be considered valid, then > CONFIG_ZSWAP_DEFAULT_ON could be switched on (which should be > possible since 5.7-rc1). I saw that as well. However, zswap has gone through a lot of changes since then: it is enabled by default on Arch at least, and possibly more distributions (I couldn't find the kernel config file for RedHat). The feature is still maintained, and appears to be bug-free. I'm having a hard time seeing the disadvantage of enabling it. signature.asc Description: This is a digitally signed message part
Bug#956836: Update: Bitwarden is a dependency headache
I figure I ought to post an update here. It's not looking good. There is a very nifty tool for repackaging node.js packages for Debian (shockingly called npm2deb), however, it assumes upstream uploaded their package to the npm registry. The bitwarden upstream did not, as it is a GUI application, and so they didn't know they even could. They did not want to, however. I then patched npm2deb to handle packages that were only available as tarballs (which I was quite proud of). Though those changes have not yet been merged in, they worked just fine-which was when I ran into the showstopper. Bitwarden has a long chain of dependencies, as it is an application built on Angular.js and Electron.js. npm2deb gave a list of 28 separate packages. Although they are all node packages, and I am sure npm2deb is up to the task, I am not sure if I could, or should, add them all. I pasted the relevant section of npm2deb output bellow. If someone could aid me in packaging and maintaining the dependent packages, I'd be much more confident in continuing. But I don't want to wait for my 29th package to get one that I actually use. (Obviously, many of these may be prepackaged, and just not be known to npm2deb by their Debian name. But there is a mechanism that attempts to solve that (with a list that converts between them), and I assume it is somewhat up-to-date. Additionally, I did manually attempt to find them with apt, and failed.) [error] @angular/animations: dependency node-@angular/animations not in debian [error] @angular/cdk: dependency node-@angular/cdk not in debian [error] @angular/common: dependency node-@angular/common not in debian [error] @angular/compiler: dependency node-@angular/compiler not in debian [error] @angular/core: dependency node-@angular/core not in debian [error] @angular/forms: dependency node-@angular/forms not in debian [error] @angular/platform-browser: dependency node-@angular/platform -browser not in debian [error] @angular/platform-browser-dynamic: dependency node-@angular/ platform-browser-dynamic not in debian [error] @angular/router: dependency node-@angular/router not in debian [error] @angular/upgrade: dependency node-@angular/upgrade not in debian [error] @microsoft/signalr: dependency node-@microsoft/signalr not in debian [error] @microsoft/signalr-protocol-msgpack: dependency node-@microsoft/signalr-protocol-msgpack not in debian [error] @nodert-win10-rs4/windows.security.credentials.ui: dependency node-@nodert-win10-rs4/windows.security.credentials.ui not in debian [error] angular2-toaster: dependency node-angular2-toaster not in debian [error] angulartics2: dependency node-angulartics2 not in debian [error] big-integer: dependency node-big-integer not in debian [error] desktop-idle: dependency node-desktop-idle not in debian [error] duo_web_sdk: dependency node-duo_web_sdk not in debian [error] electron-log: dependency node-electron-log not in debian [error] electron-store: dependency node-electron-store not in debian [error] electron-updater: dependency node-electron-updater not in debian [error] keytar: dependency node-keytar not in debian [error] nord: dependency node-nord not in debian [error] papaparse: dependency node-papaparse not in debian [error] rxjs: dependency node-rxjs not in debian [error] sweetalert2: dependency node-sweetalert2 not in debian [error] zone.js: dependency node-zone.js not in debian [error] zxcvbn: dependency node-zxcvbn not in debian signature.asc Description: This is a digitally signed message part
Bug#963784: qxw: New upstream release
> > There has been a new upstream release of qxw, which adds a host of > > new features, > > including unicode support and hex grids. Please update the package > > to provide it! > > Hello Calum, thanks for the bug report. No problem! > As you will have seen, there is a Debian package for release 20190909 > available from my website. Unfortunately I was not able to find a > sponsor to upload it to Debian, and the sponsor for the previous > version is not replying to my e-mails. If you haven't already, try emailing debian-devel/debian-mentor: I bet in our current situation, there is some DD who is bored out of their mind and willing to do an update > If you know a DD who might be willing to act as a sponsor let me > know. > There is a new release imminent, just fixing a couple of bugs in > 20190909 that people have found since its release. When the new > release is ready - it takes a while as getting the Windows version > ready takes some to-ing and fro-ing with the chap who does the > port - I will reply to your message on the bug tracker. Did you intentionnaly PM me, rather than cc bugs.debian.org? I cc'ed it back on; hope you don't mind > Mark. Thanks Calum
