Bug#874526: Keyboard grab doesn't work under Wayland
On Mon, Jul 02, 2018 at 06:36:54PM +0100, Simon McVittie wrote: > On Wed, 06 Sep 2017 at 14:58:37 -0700, Josh Triplett wrote: > > (It might also help to add Ctrl-Alt-Delete to the list of shortcuts > > provided in the gnome-boxes keyboard menu, alongside Ctrl-Alt-Backspace > > and similar.) > > This is now provided in the keyboard menu for both gnome-boxes and > virt-manager. I appreciate that, thank you. That will help heavily as a workaround.
Bug#907518: wpa: problems with openssl 1.1.1
On Sun, Oct 07, 2018 at 11:00:48AM +0200, Andrej Shadura wrote: > I’m unsure what can be done to help resolve this issue from the wpa side. For debugging purposes, I'd still be interested to know this: > On Wed, 5 Sep 2018 14:57:59 -0700 Josh Triplett > wrote: > > Is there a way I can easily get wpa_supplicant to log the full client > > and server certificate chain, and flag which *specific* certificate in > > that chain it has an issue with? I'm trying to present appropriate > > information to get the wireless network infrastructure improved, and > > unlike https I can't just use `openssl s_client` to get the details I > > need.
Bug#913116: Fails to start without chromium-sandbox installed
Package: chromium Version: 70.0.3538.67-3 Severity: grave Without chromium-sandbox installed: ~$ chromium [10607:10607:1106/214902.149402:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii chromium-common 70.0.3538.67-3 ii libasound2 1.1.7-1 ii libatk-bridge2.0-0 2.30.0-2 ii libatk1.0-0 2.30.0-1 ii libatomic1 8.2.0-9 ii libavcodec58 7:4.0.3-1 ii libavformat587:4.0.3-1 ii libavutil56 7:4.0.3-1 ii libc62.27-8 ii libcairo-gobject21.16.0-1 ii libcairo21.16.0-1 ii libcups2 2.2.8-5 ii libdbus-1-3 1.12.10-1 ii libdrm2 2.4.95-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.8.1-2 ii libgcc1 1:8.2.0-9 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-0 2.58.1-2 ii libgtk-3-0 3.24.1-2 ii libharfbuzz0b1.9.0-1 ii libicu60 60.2-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.39-1 ii libopenjp2-7 2.3.0-1 ii libopus0 1.3~beta+20180518-1 ii libpango-1.0-0 1.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii libpci3 1:3.5.2-1 ii libpng16-16 1.6.34-2 ii libpulse012.2-2 ii libre2-4 20180901+dfsg-1 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.2.0-9 ii libvpx5 1.7.0-3 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-1 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b1 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 chromium recommends no packages. Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell -- no debconf information
Bug#913116: chromium
On Wed, Nov 14, 2018 at 03:35:24PM +0100, Salvo Tomaselli wrote: > If it can't start without it, it really should depend on it I get the impression that chromium is *supposed* to work without the setuid sandbox, if it has the necessary support from the underlying system to do unprivileged sandboxing.
Bug#909804: Excessive CPU usage at system startup
Package: gnome-software Version: 3.28.2-1 Severity: grave I don't know whether the bug here lies in gnome-software, packagekit, or some combination of the two. Every time I start my system, I see packagekit burning a huge amount of CPU for a minute, and this affects the performance of the system until it stops. Corresponding to this, I see a large number of log messages like this: Sep 28 12:24:38 s PackageKit[717]: search-file transaction /18520_ddabdebb from uid 1000 finished with success after 643ms Sep 28 12:24:39 s PackageKit[717]: search-file transaction /18521_bbebdedd from uid 1000 finished with success after 301ms On my most recent system boot, I see 167 such messages, spanning nearly a minute worth of 100% CPU. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-software depends on: ii appstream0.12.2-2 ii apt-config-icons 0.12.2-2 ii dconf-gsettings-backend [gsettings-backend] 0.30.0-1 ii gnome-software-common3.28.2-1 ii gsettings-desktop-schemas3.28.1-1 ii libappstream-glib8 0.7.12-1 ii libatk1.0-0 2.30.0-1 ii libc62.27-6 ii libcairo21.15.12-1 ii libfwupd21.1.2-1 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-0 2.58.1-2 ii libgnome-desktop-3-173.30.1-1 ii libgspell-1-11.6.1-1 ii libgtk-3-0 3.24.0-3 ii libgtk3-perl 0.034-2 ii libgudev-1.0-0 232-2 ii libjson-glib-1.0-0 1.4.2-4 ii libpackagekit-glib2-18 1.1.10-1 ii libpolkit-gobject-1-00.105-21 ii libsecret-1-00.18.6-3 ii libsoup2.4-1 2.64.1-1 ii packagekit 1.1.10-1 ii software-properties-gtk 0.96.20.2-1 gnome-software recommends no packages. Versions of packages gnome-software suggests: pn apt-config-icons-hidpi pn fwupd pn gnome-software-plugin-flatpak pn gnome-software-plugin-limba pn gnome-software-plugin-snap -- no debconf information
Bug#909559: Ships empty zipfile /usr/psychojs.zip
Package: psychopy Version: 1.85.3.dfsg-1 Severity: serious psychopy ships a file in the inappropriate location /usr/psychojs.zip . This file appears to be an *empty* zipfile. (There's another copy of the same empty file in ./usr/lib/python2.7/dist-packages/psychopy/psychojs.zip .)
Bug#919914: gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue)
Package: gnome-tweaks Version: 3.30.2-1 Severity: grave Tags: security Recently, disabling the setting "Suspend when laptop lid is closed" seems to have started preventing *any* action on lid close, including locking the screen; disabling that setting adds a startup file to run /usr/lib/gnome-tweak-tool/gnome-tweak-tool-lid-inhibitor, which inhibits *any* action on the lid switch. This is a security issue. I disable suspend on lid close, but I *always* need the screen to lock when I close the lid. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-tweaks depends on: ii gir1.2-glib-2.01.58.3-2 ii gir1.2-gnomedesktop-3.03.30.2-4 ii gir1.2-gtk-3.0 3.24.3-1 ii gir1.2-notify-0.7 0.7.7-4 ii gir1.2-pango-1.0 1.42.4-6 ii gir1.2-soup-2.42.64.2-2 ii gnome-settings-daemon 3.30.2-1 ii gnome-shell-common 3.30.2-1 ii gsettings-desktop-schemas 3.28.1-1 ii mutter-common 3.30.2-4 ii python33.7.2-1 ii python3-gi 3.30.4-1 gnome-tweaks recommends no packages. gnome-tweaks suggests no packages. -- no debconf information
Bug#913116: Needs to depend on chromium-sandbox
On Fri, 16 Nov 2018 10:20:07 +0100 Bastian Blank wrote: > Debian does not support unprivileged user namespaces, so chromium needs > to depend on -sandbox to get a working package. Should we, perhaps, support unprivileged user namespaces? Or, at least, a means of granting targeted permission to use such namespaces without being full root?
Bug#913116: Needs to depend on chromium-sandbox
On Sat, Nov 17, 2018 at 11:15:28AM +, Simon McVittie wrote: > On Fri, 16 Nov 2018 at 14:19:16 -0800, Josh Triplett wrote: > > On Fri, 16 Nov 2018 10:20:07 +0100 Bastian Blank wrote: > > > Debian does not support unprivileged user namespaces, so chromium needs > > > to depend on -sandbox to get a working package. > > > > Should we, perhaps, support unprivileged user namespaces? Or, at least, > > a means of granting targeted permission to use such namespaces without > > being full root? > > We have this mode available. Sysadmins can select it with: > > sysctl -w kernel.unprivileged_userns_clone=1 > > which leads to the same behaviour as upstream kernels, Fedora, and > recent Ubuntu releases. (Or use /etc/sysctl.d to change this in a > persistent way.) > > However, Debian's kernel maintainer has indicated that he doesn't consider > this mechanism to be completely safe (I'm not sure to what extent this is > still true), hence the current default. Setting up a user namespace gives > you all capabilities in the namespace (including CAP_SYS_ADMIN, which is > required if you want to protect part or all of the host system directory > tree from the namespaced process by playing with mount namespaces and > bind-mounts, like Flatpak does), so if you suspect the kernel still has > flaws in which capabilities in non-init user namespaces can be abused > to get privileged access to the overall system, you can't allow it. I'm aware of this. And I'm not *necessarily* advocating a change to the kernel to allow this by default. But perhaps chromium-sandbox could have some lesser privilege (not full setuid root) that allows it to create an unprivileged user namespace? bubblewrap and others could do the same. > Sysadmins who have set kernel.unprivileged_userns_clone=1 can use > dpkg-statoverride to make bwrap non-setuid, as it is on recent Ubuntu > systems (the same compiled binary can work either way, since it detects > which mode to work in at runtime). We *might* also consider having a configuration package that drops a unprivileged_userns_clone.conf file into /usr/lib/sysctl.d/ , and letting packages like chromium depend on unprivileged-userns-clone | chromium-sandbox.
Bug#918854: segfault updating crates.io index
Package: cargo Version: 0.31.1-1 Severity: grave Any time I try to update the crates.io index with the currently packaged version of cargo, I get a segfault: $ cargo update Updating crates.io index Segmentation fault I can reproduce this in a brand new project (`cargo new foo`) by adding any dependency to `Cargo.toml` (e.g. `strsim = "*"`) and then running `cargo update`. libgit2 was just updated recently; that might potentially be related. -- 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.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cargo depends on: ii binutils2.31.1-11 ii gcc 4:8.2.0-2 ii gcc-7 [c-compiler] 7.4.0-2 ii gcc-8 [c-compiler] 8.2.0-14 ii libc6 2.28-4 ii libcurl3-gnutls 7.62.0-1 ii libgcc1 1:8.2.0-14 ii libgit2-27 0.27.7+dfsg.1-0.1 ii libssh2-1 1.8.0-2 ii libssl1.1 1.1.1a-1 ii rustc 1.31.0+dfsg1-2 ii zlib1g 1:1.2.11.dfsg-1 cargo recommends no packages. Versions of packages cargo suggests: pn cargo-doc ii python33.7.1-3 -- no debconf information
Bug#945047: Needs dependency for Crypt/Digest/SHA256.pm
Package: extrepo Version: 0.2 Severity: serious Attempting to run extrepo produces: Can't locate Crypt/Digest/SHA256.pm in @INC (you may need to install the Crypt::Digest::SHA256 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debian/ExtRepo/Commands/Enable.pm line 9. BEGIN failed--compilation aborted at /usr/share/perl5/Debian/ExtRepo/Commands/Enable.pm line 9. Compilation failed in require at /usr/share/perl5/Debian/ExtRepo/Commands/Update.pm line 3. BEGIN failed--compilation aborted at /usr/share/perl5/Debian/ExtRepo/Commands/Update.pm line 3. Compilation failed in require at /usr/bin/extrepo line 7. BEGIN failed--compilation aborted at /usr/bin/extrepo line 7. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages extrepo depends on: ii gpgv 2.2.17-3 ii libwww-perl 6.41-1 ii libyaml-perl 1.29-1 ii perl 5.30.0-9 extrepo recommends no packages. extrepo suggests no packages. -- no debconf information
Bug#874176: wrk: Fails to run with 'PANIC: unprotected error in call to Lua API'
Package: wrk Version: 4.0.2-2 Followup-For: Bug #874176 I can confirm that this occurs for me as well; any attempt to run wrk produces: PANIC: unprotected error in call to Lua API (attempt to index a nil value) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wrk depends on: ii libc62.30-7 ii libluajit-5.1-2 2.1.0~beta3+dfsg-5.1 ii libssl1.11.1.1g-1 wrk recommends no packages. wrk suggests no packages. -- no debconf information
Bug#963177: calendar: trying to overwrite '/etc/calendar/default', which is also in package bsdmainutils 12.1.1
On Sun, 21 Jun 2020 04:05:43 +0200 Chris Hofstaedtler wrote: > Hi Josh, > > I figured you might be interested in this, too, as IIRC the original > patch was from you: > > * Thorsten Glaser [200621 02:04]: > > Selecting previously unselected package calendar. > > (Reading database ... 406194 files and directories currently installed.) > > Preparing to unpack .../calendar_12.1.1_x32.deb ... > > Unpacking calendar (12.1.1) ... > > dpkg: error processing archive > > /var/cache/apt/archives/calendar_12.1.1_x32.deb (--unpack): > > trying to overwrite '/etc/calendar/default', which is also in package > > bsdmainutils 12.1.1 > > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > > Errors were encountered while processing: > > /var/cache/apt/archives/calendar_12.1.1_x32.deb > > E: Sub-process /usr/bin/dpkg returned an error code (1) Ah. When I originally sent the patch, I believe I included appropriate Breaks/Replaces headers to make sure this wouldn't happen, but it looks like the version that incorporated the patch had advanced past the version numbers in the Breaks/Replaces. The version numbers in the Breaks/Replaces need updating.
Bug#943037: Status of this bug?
What's the current status of this bug? I'd love to have a version of git-hub that doesn't depend on Python 2; it's the last thing on my system that still wants Python 2.
Bug#943037: Status of this bug?
I'm aware of the upstream update (and appreciate it); I'm asking about the status of the Debian package for the new version. On Sun, Nov 15, 2020 at 12:08:42AM +0100, Leandro Lucarella wrote: > Hi Josh, Version 2.0.0, released recently, supports python3. The Debian > package just needs to be updated. You can download a .deb built from the > source from here if you can't wait: > https://bintray.com/sociomantic-tsunami/tools/git-hub > > On 14 November 2020 22:41:02 GMT+01:00, Josh Triplett > wrote: > >What's the current status of this bug? I'd love to have a version of > >git-hub that doesn't depend on Python 2; it's the last thing on my > >system that still wants Python 2. > > -- > Leandro Lucarella (luca) > Sent from my phone. Please excuse my brevity and any typos.
Bug#986268: Should be in non-free, not main; no source code
Package: firmware-ast Version: 20140808-1 Severity: serious X-Debbugs-Cc: j...@joshtriplett.org firmware-ast is binary-only firmware. The "source code" appears to consist of a C header file containing a hex dump of a binary, and a makefile transforming the hex dump into binary. The previous package, xserver-xorg-video-ast, had a similar bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941077 .
Bug#1002827: Should be in contrib; expects an installation of Steam
Package: proton-caller Severity: serious X-Debbugs-Cc: j...@joshtriplett.org While portions of Proton are Open Source (being based on the LGPLed Wine), proton-caller appears to specifically expect an installation of Steam. The description says "Simply configure your Steam and common directories", and the upstream documentation similarly talks about configuring the path to a Steam installation. - Josh -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages proton-caller depends on: ii libc6 2.33-1 ii libgcc-s1 11.2.0-13 proton-caller recommends no packages. proton-caller suggests no packages.
Bug#998108: reopening 998108
reopen 998108 94.0-2 thanks I'm still experiencing this bug regularly, with complete browser UI freezes that require killing and restarting Firefox. WebGL or video seems to trigger it more often, as does opening a new tab. Browsing on an existing tab doesn't tend to trigger it.
Bug#998108: firefox freezes shortly after start
On Sat, 30 Oct 2021 15:04:01 +0200 Christoph Anton Mitterer wrote: > Since about yesterday (possibly since the rebuilt package came in) > firefox freezes shortly after being started. > There is no high CPU activity then, it just takes no input anymore > (no keyboard, no mouse clicks). > This also happens in --safe-mode. I'm encountering this as well. It happens slower if I just browse, and much much faster if I use something like WebGL.
Bug#998108: Additional information: tab freezes first, then browser
Some additional information that might help track this down: several times, I've observed one tab freezing, but the browser itself is still responsive for a *short* time. I can open a new tab, and close it again, and the previous tab then renders as a busy symbol. I'm wondering if one of the tab processes or helper processes dies, and then that grinds the browser to a halt but not instantly.
Bug#1014901: Home directories should not be setgid by default
On Thu, Jul 14, 2022 at 04:20:18PM -0400, Matt Barry wrote: > On Thu, 2022-07-14 at 13:05 -0700, Josh Triplett wrote: > > The use case below, and any other tools that create files and know to > > set their permissions appropriately but don't expect unusual > > ownership > > by default: > > > > In particular, it is common to build various kinds of filesystem, > > > > container, or disk images, and to do so within your home > > > > directory. > > > > Users writing tools and scripts to build such images need to make > > > > sure > > > > to create files with an appropriate mode, but such scripts often > > > > assume > > > > (reasonably) that if they're running as root:root and they create > > > > a > > > > file, that file will be owned by root:root. Attempting to build > > > > filesystems, containers, disk images, or similar in an > > > > unexpectedly > > > > setgid directory will produce unexpected results (leaving aside > > > > that the > > > > directory mode itself will be surprising). > > Could you be just slightly more specific about a use case that fails? > Given how many times this has come up over the years, I'm trying to get > a sense of what the *actual* issues are (as opposed to what they used > to be). > > Enough instruction that I can reproduce a specific problem(s) would be > great. Sure. Here's a sample of the kind of script I regularly encounter, producing incorrect results in a setgid directory. The script expects to produce files owned by root:root, but the files and directories get the wrong group, and the setgid bit gets propagated to the constructed filesystem image. /tmp/testdir$ ls -ld drwxr-sr-x 2 josh josh 4096 Jul 16 13:40 . /tmp/testdir$ ls -l total 4 -rwxr-xr-x 1 josh josh 354 Jul 16 13:40 make-filesystem.sh /tmp/testdir$ cat make-filesystem.sh #!/bin/bash if [ "$(id -u)" -ne 0 ]; then echo Run as root >&2 exit 1 fi umask 022 mkdir fsroot fsroot/bin fsroot/etc fsroot/srv mkdir -m 0700 fsroot/srv/workdir echo 'nameserver 169.254.169.253' > fsroot/etc/resolv.conf printf '#!/bin/sh\necho example binary\n' > fsroot/bin/example chmod a+x fsroot/bin/example mke2fs -d fsroot root.img 16M /tmp/testdir$ sudo ./make-filesystem.sh mke2fs 1.46.5 (30-Dec-2021) Creating regular file root.img Creating filesystem with 16384 1k blocks and 4096 inodes Filesystem UUID: ec2c8666-96d9-4bce-b964-4c32ed098638 Superblock backups stored on blocks: 8193 Allocating group tables: done Writing inode tables: done Copying files into the device: done Writing superblocks and filesystem accounting information: done /tmp/testdir$ ls -l total 1196 drwxr-sr-x 5 root josh 4096 Jul 16 13:41 fsroot -rwxr-xr-x 1 josh josh 354 Jul 16 13:40 make-filesystem.sh -rw-r--r-- 1 root josh 16777216 Jul 16 13:41 root.img /tmp/testdir$ mkdir /tmp/testmount /tmp/testdir$ sudo mount -o loop root.img /tmp/testmount /tmp/testdir$ sudo ls -lR /tmp/testmount/ /tmp/testmount/: total 15 drwxr-sr-x 2 root josh 1024 Jul 16 13:41 bin drwxr-sr-x 2 root josh 1024 Jul 16 13:41 etc drwx-- 2 root root 12288 Jul 16 13:41 lost+found drwxr-sr-x 3 root josh 1024 Jul 16 13:41 srv /tmp/testmount/bin: total 1 -rwxr-xr-x 1 root josh 30 Jul 16 13:41 example /tmp/testmount/etc: total 1 -rw-r--r-- 1 root josh 27 Jul 16 13:41 resolv.conf /tmp/testmount/lost+found: total 0 /tmp/testmount/srv: total 1 drwx--S--- 2 root josh 1024 Jul 16 13:41 workdir /tmp/testmount/srv/workdir: total 0
Bug#1029661: Cannot authenticate with Google
Package: gcalcli Version: 4.3.0-1 Severity: grave Tags: upstream X-Debbugs-Cc: j...@joshtriplett.org Google no longer allows gcalcli to authenticate. Upstream recommends manually creating a developer account and registering gcalcli as your own app. This is a *much* more cumbersome setup process, and the simple oauth2 workflow that gcalcli uses by default doesn't work with no indication of why. At a minimum, this should be documented and the flow for not having authenticated yet should give better guidance to the user and not try an authentication that won't work. https://github.com/insanum/gcalcli/issues/580 -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcalcli depends on: ii python33.11.1-1 ii python3-dateutil 2.8.2-1 ii python3-googleapi 1.7.12-1 ii python3-httplib2 0.20.4-3 ii python3-oauth2client 4.1.3-3 ii python3-parsedatetime 2.6-3 ii python3-six1.16.0-4 Versions of packages gcalcli recommends: pn python3-vobject gcalcli suggests no packages. -- no debconf information
Bug#1041559: Recommends non-existent package linux-musl-dev
Package: musl-dev Version: 1.2.3-1 Severity: serious X-Debbugs-Cc: j...@joshtriplett.org musl-dev Recommends linux-musl-dev, which does not appear to exist in the archive. Policy 2.2.1 "The main archive area": > package must not declare a "Pre-Depends", "Depends", "Recommends", > "Build-Depends", "Build-Depends-Indep", or "Build-Depends-Arch" > relationship on a non-*main* package unless that package is only > listed as a non-default alternative for a package in *main* -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages musl-dev depends on: ii gcc [gcc-x86-64-linux-gnu] 4:13.1.0-4 ii musl1.2.3-1 Versions of packages musl-dev recommends: pn linux-musl-dev musl-dev suggests no packages. -- no debconf information
