Bug#1071377: chkrootkit: File name including a quote mark throws script off

[Shai Berger]

Package: chkrootkit
Version: 0.58b-1+b3
Severity: normal

Dear Maintainer,

In Hebrew, the double quote mark can sometimes be used
to mark an acronym. In this role, it can make its way
into file names.

This morning, when chkrootkit made its daily run, I had
in /tmp a file named: 'חברת חשמל לישראל בע"מ - חשבון דו חודשי.pdf'
(the single quote marks on the edges are not part of the name, but
the double quote mark in the middle is)

This caused this output from the script:

"""
Searching for suspect PHP files...  /usr/bin/head: 
cannot open '/tmp/חברת חשמל לישראל בעמ' for reading: No such file or directory
/usr/bin/head: cannot open 'חשבון' for reading: No such file or directory
/usr/bin/head: cannot open 'דו' for reading: No such file or directory
/usr/bin/head: cannot open 'חודשי.pdf 2>/dev/null | /usr/bin/grep -q ^#!.*php 
&& echo /tmp/חברת' for reading: No such file or directory
/usr/bin/head: cannot open 'חשמל' for reading: No such file or directory
/usr/bin/head: cannot open 'לישראל' for reading: No such file or directory
/usr/bin/head: cannot open 'בעמ - חשבון דו חודשי.pdf' for reading: No such file 
or directory
WARNING

WARNING: The following suspicious PHP files were found:
==> standard input <==  
"""

Thanks,
Shai.

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

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

Versions of packages chkrootkit depends on:
ii  libc6  2.38-10

Versions of packages chkrootkit recommends:
ii  anacron2.3-40
ii  binutils   2.42-4
ii  cron [cron-daemon] 3.0pl1-189
ii  exim4-daemon-light [mail-transport-agent]  4.97-8
ii  iproute2   6.8.0-1
ii  mailutils [mailx]  1:3.17-1.1+b2
ii  procps 2:4.0.4-4
ii  systemd-sysv   255.5-1

chkrootkit suggests no packages.

-- Configuration Files:
/etc/chkrootkit/chkrootkit.ignore changed:
/usr/lib/ruby/vendor_ruby/rubygems/tsort/.document
/usr/lib/ruby/vendor_ruby/rubygems/optparse/.document
/usr/lib/ruby/vendor_ruby/rubygems/ssl_certs/.document
/usr/lib/ruby/gems/3.1.0/gems/typeprof-0.21.2/vscode/.vscode
/usr/lib/ruby/gems/3.1.0/gems/typeprof-0.21.2/vscode/.gitignore
/usr/lib/ruby/gems/3.1.0/gems/typeprof-0.21.2/vscode/.vscodeignore
/usr/lib/jvm/.java-1.17.0-openjdk-amd64.jinfo
/usr/lib/libreoffice/share/.registry
/usr/lib/python3/dist-packages/matplotlib/backends/web_backend/.eslintrc.js
/usr/lib/python3/dist-packages/matplotlib/backends/web_backend/.prettierignore
/usr/lib/python3/dist-packages/matplotlib/backends/web_backend/.prettierrc
/usr/lib/python3/dist-packages/matplotlib/tests/tinypages/.gitignore
/usr/lib/python3/dist-packages/matplotlib/tests/tinypages/_static/.gitignore
/usr/lib/python3/dist-packages/matplotlib/tests/baseline_images/.keep
/usr/lib/python3/dist-packages/numpy/f2py/tests/src/assumed_shape/.f2py_f2cmap
/usr/lib/python3/dist-packages/numpy/f2py/tests/src/f2cmap/.f2py_f2cmap
/usr/lib/python3/dist-packages/numpy/core/include/numpy/.doxyfile


-- no debconf information

Bug#1050656: libqt5gui5: This was local to my system only

[Shai Berger]

Package: libqt5gui5
Followup-For: Bug #1050656

Dear Maintainer,

Looking again at some tracebacks and coredumps, I realized the
problem was really with libjpeg62-turbo -- but that didn't make
sense to me, as that library hasn't changed in a long time.

Except, apparently, on my system, it has.

Reinstalling it solved the problem.

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

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

Versions of packages libqt5gui5 depends on:
ii  fontconfig 2.14.2-6
ii  libc6  2.37-12
ii  libdrm22.4.117-1
ii  libegl11.7.0-1
ii  libfontconfig1 2.14.2-6
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.2.1-1
ii  libgcc-s1  13.2.0-5
ii  libgl1 1.7.0-1
ii  libglib2.0-0   2.78.1-2
ii  libharfbuzz0b  8.0.1-1
ii  libice62:1.0.10-1
ii  libinput10 1.23.0-2
ii  libjpeg62-turbo1:2.1.5-2
ii  libmd4c0   0.4.8-1
ii  libmtdev1  1.1.6-1
ii  libpng16-161.6.40-2
ii  libqt5core5a [qtbase-abi-5-15-10]  5.15.10+dfsg-4
ii  libqt5dbus55.15.10+dfsg-4
ii  libqt5network5 5.15.10+dfsg-4
ii  libsm6 2:1.2.3-1
ii  libstdc++6 13.2.0-5
ii  libudev1   254.5-1
ii  libx11-6   2:1.8.7-1
ii  libx11-xcb12:1.8.7-1
ii  libxcb-glx01.15-1
ii  libxcb-icccm4  0.4.1-1.1
ii  libxcb-image0  0.4.0-2
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.15-1
ii  libxcb-render-util00.3.9-1+b1
ii  libxcb-render0 1.15-1
ii  libxcb-shape0  1.15-1
ii  libxcb-shm01.15-1
ii  libxcb-sync1   1.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb-xinerama0   1.15-1
ii  libxcb-xinput0 1.15-1
ii  libxcb-xkb11.15-1
ii  libxcb11.15-1
ii  libxkbcommon-x11-0 1.6.0-1
ii  libxkbcommon0  1.6.0-1
ii  libxrender11:0.9.10-1.1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages libqt5gui5 recommends:
ii  libqt5svg5 5.15.10-2
ii  qt5-gtk-platformtheme  5.15.10+dfsg-4
ii  qtwayland5 5.15.10-2

Versions of packages libqt5gui5 suggests:
pn  qgnomeplatform-qt5 
ii  qt5-image-formats-plugins  5.15.10-2

-- no debconf information

Bug#1050656: libqt5gui5: This was local to my system only

[Shai Berger]

Package: libqt5gui5
Followup-For: Bug #1050656

Dear Maintainer,

Looking again at some tracebacks and coredumps, I realized the
problem was really with libjpeg62-turbo -- but that didn't make
sense to me, as that library hasn't changed in a long time.

Except, apparently, on my system, it has.

Reinstalling it solved the problem.

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

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

Versions of packages libqt5gui5 depends on:
ii  fontconfig 2.14.2-6
ii  libc6  2.37-12
ii  libdrm22.4.117-1
ii  libegl11.7.0-1
ii  libfontconfig1 2.14.2-6
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.2.1-1
ii  libgcc-s1  13.2.0-5
ii  libgl1 1.7.0-1
ii  libglib2.0-0   2.78.1-2
ii  libharfbuzz0b  8.0.1-1
ii  libice62:1.0.10-1
ii  libinput10 1.23.0-2
ii  libjpeg62-turbo1:2.1.5-2
ii  libmd4c0   0.4.8-1
ii  libmtdev1  1.1.6-1
ii  libpng16-161.6.40-2
ii  libqt5core5a [qtbase-abi-5-15-10]  5.15.10+dfsg-4
ii  libqt5dbus55.15.10+dfsg-4
ii  libqt5network5 5.15.10+dfsg-4
ii  libsm6 2:1.2.3-1
ii  libstdc++6 13.2.0-5
ii  libudev1   254.5-1
ii  libx11-6   2:1.8.7-1
ii  libx11-xcb12:1.8.7-1
ii  libxcb-glx01.15-1
ii  libxcb-icccm4  0.4.1-1.1
ii  libxcb-image0  0.4.0-2
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.15-1
ii  libxcb-render-util00.3.9-1+b1
ii  libxcb-render0 1.15-1
ii  libxcb-shape0  1.15-1
ii  libxcb-shm01.15-1
ii  libxcb-sync1   1.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb-xinerama0   1.15-1
ii  libxcb-xinput0 1.15-1
ii  libxcb-xkb11.15-1
ii  libxcb11.15-1
ii  libxkbcommon-x11-0 1.6.0-1
ii  libxkbcommon0  1.6.0-1
ii  libxrender11:0.9.10-1.1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages libqt5gui5 recommends:
ii  libqt5svg5 5.15.10-2
ii  qt5-gtk-platformtheme  5.15.10+dfsg-4
ii  qtwayland5 5.15.10-2

Versions of packages libqt5gui5 suggests:
pn  qgnomeplatform-qt5 
ii  qt5-image-formats-plugins  5.15.10-2

-- no debconf information

Bug#1050656: telegram-desktop: Problem is actually in Qt

[Shai Berger]

Package: telegram-desktop
Version: 4.10.3+ds-1+b1
Followup-For: Bug #1050656
Control: reassign -1 libqt5gui5 5.15.10+dfsg-4
Control: retitle -1 Bus error when trying to write jpeg images images

Dear Maintainer,

I've run into similar crashes with similar tracebacks in
KDE applications not related to Telegram, whenever one
tries to write a JPEG image to disk. Therefore, I don't
believe the issue to be with Telegram.

The problem was detected in testing, with
libqt5gui5=5.15.10+dfsg-3 and probably previous
versions; I installed the latest in unstable to see
if it fixes it. It doesn't.

-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libabsl20220623  20220623.1-3
ii  libavcodec-extra60 [libavcodec60]7:6.0-7+b1
ii  libavfilter-extra9 [libavfilter9]7:6.0-7+b1
ii  libavformat-extra60 [libavformat60]  7:6.0-7+b1
ii  libavutil58  7:6.0-7+b1
ii  libc62.37-12
ii  libgcc-s113.2.0-5
ii  libglib2.0-0 2.78.0-2
ii  libglibmm-2.68-1 2.78.0-1
ii  libhunspell-1.7-01.7.2+really1.7.2-10
ii  libjpeg62-turbo  1:2.1.5-2
ii  libkf5coreaddons55.107.0-1
ii  liblz4-1 1.9.4-1
ii  libminizip1  1:1.2.13.dfsg-3
ii  libopenal1   1:1.23.1-4
ii  libopus0 1.4-1
ii  libqrcodegencpp1 1.8.0-1.2
ii  libqt5core5a [qtbase-abi-5-15-10]5.15.10+dfsg-3
ii  libqt5gui5   5.15.10+dfsg-4
ii  libqt5network5   5.15.10+dfsg-3
ii  libqt5qml5   5.15.10+dfsg-2
ii  libqt5quick5 5.15.10+dfsg-2
ii  libqt5quickwidgets5  5.15.10+dfsg-2
ii  libqt5svg5   5.15.10-2
ii  libqt5waylandcompositor5 5.15.10-2
ii  libqt5widgets5   5.15.10+dfsg-3
ii  librlottie0-10.1+dfsg-4
ii  libsigc++-3.0-0  3.4.0-7
ii  libsrtp2-1   2.5.0-3
ii  libssl3  3.0.11-1
ii  libstdc++6   13.2.0-5
ii  libswresample4   7:6.0-7+b1
ii  libswscale7  7:6.0-7+b1
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb-record0   1.15-1
ii  libxcb-screensaver0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  libxxhash0   0.8.2-2
ii  libyuv0  0.0~git20230907.cbfb661-1
ii  qt5-image-formats-plugins5.15.10-2
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans   1.11-2
ii  libwebkit2gtk-4.0-37  2.42.1-2+b1
ii  libwebkit2gtk-4.1-0   2.42.1-2+b1

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal   1.18.0-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]  5.27.8-1

-- no debconf information
[2023.10.29 17:56:46] Launched version: 4010003, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2023.10.29 17:56:46] Executable dir: /usr/bin/, name: telegram-desktop
[2023.10.29 17:56:46] Initial working dir: /home/shai/
[2023.10.29 17:56:46] Working dir: /home/shai/.local/share/TelegramDesktop/
[2023.10.29 17:56:46] Command line: /usr/bin/telegram-desktop --
[2023.10.29 17:56:46] Executable path before check: /usr/bin/telegram-desktop
[2023.10.29 17:56:46] Logs started
[2023.10.29 17:56:46] Launcher filename: org.telegram.desktop.desktop
[2023.10.29 17:56:46] We use allocator from /lib/x86_64-linux-gnu/libc.so.6
[2023.10.29 17:56:46] Connecting local socket to 
/tmp/735a4fdec5600e9bc6df96b79a9689ee-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2023.10.29 17:56:46] Socket connect error 0, starting server and app...
[2023.10.29 17:56:46] Moved logging from 

Bug#1050656: telegram-desktop: Bus Error whenever a channel has a video

[Shai Berger]

Package: telegram-desktop
Version: 4.9.7+ds-1
Followup-For: Bug #1050656

Dear Maintainer,

I suspected this bug was caused by having on my system some mixed
versions (I have some packages from unstable).

So I checked for any relevant packages which are not from testing:

$ aptitude versions --group-by=none ~Rtelegram-desktop | grep ^i | grep -v 
testing

I found packages which needed updating, and packages which needed
removing, but after all of that -- the output of the above command
is now empty -- and a reboot, the problem remains.

-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libabsl20220623  20220623.1-3
ii  libavcodec-extra60 [libavcodec60]7:6.0-7
ii  libavfilter-extra9 [libavfilter9]7:6.0-7
ii  libavformat-extra60 [libavformat60]  7:6.0-7
ii  libavutil58  7:6.0-7
ii  libc62.37-12
ii  libgcc-s113.2.0-4
ii  libglib2.0-0 2.78.0-2
ii  libglibmm-2.68-1 2.78.0-1
ii  libhunspell-1.7-01.7.2+really1.7.2-10
ii  libjpeg62-turbo  1:2.1.5-2
ii  libkf5coreaddons55.107.0-1
ii  liblz4-1 1.9.4-1
ii  libminizip1  1:1.2.13.dfsg-3
ii  libopenal1   1:1.23.1-4
ii  libopus0 1.4-1
ii  libqrcodegencpp1 1.8.0-1.2
ii  libqt5core5a [qtbase-abi-5-15-10]5.15.10+dfsg-3
ii  libqt5gui5   5.15.10+dfsg-3
ii  libqt5network5   5.15.10+dfsg-3
ii  libqt5svg5   5.15.10-2
ii  libqt5widgets5   5.15.10+dfsg-3
ii  librlottie0-10.1+dfsg-4
ii  libsigc++-3.0-0  3.4.0-7
ii  libsrtp2-1   2.5.0-3
ii  libssl3  3.0.11-1
ii  libstdc++6   13.2.0-4
ii  libswresample4   7:6.0-7
ii  libswscale7  7:6.0-7
ii  libvpx7  1.12.0-1.2
ii  libx11-6 2:1.8.6-1
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb-record0   1.15-1
ii  libxcb-screensaver0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  libxxhash0   0.8.2-2
ii  libyuv0  0.0~git20230907.cbfb661-1
ii  qt5-image-formats-plugins5.15.10-2
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans   1.11-2
ii  libwebkit2gtk-4.0-37  2.42.1-1
ii  libwebkit2gtk-4.1-0   2.42.1-1

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal   1.18.0-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]  5.27.8-1

-- no debconf information
[2023.10.10 09:50:50] Launched version: 4009007, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2023.10.10 09:50:50] Executable dir: /usr/bin/, name: telegram-desktop
[2023.10.10 09:50:50] Initial working dir: /home/shai/
[2023.10.10 09:50:50] Working dir: /home/shai/.local/share/TelegramDesktop/
[2023.10.10 09:50:50] Command line: /usr/bin/telegram-desktop --
[2023.10.10 09:50:50] Executable path before check: /usr/bin/telegram-desktop
[2023.10.10 09:50:50] Logs started
[2023.10.10 09:50:50] Launcher filename: org.telegram.desktop.desktop
[2023.10.10 09:50:50] We use allocator from /lib/x86_64-linux-gnu/libc.so.6
[2023.10.10 09:50:50] Connecting local socket to 
/tmp/735a4fdec5600e9bc6df96b79a9689ee-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2023.10.10 09:50:50] Socket connect error 0, starting server and app...
[2023.10.10 09:50:50] Moved logging from 
'/home/shai/.local/share/TelegramDesktop/log_start0.txt' to 
'/home/shai/.local/share/TelegramDesktop/log.txt'!
[2023.10.10 09:50:50] Global devicePixelRatio: 1
[2023.10.10 09:50:50] QT_AUTO_SCREEN_SCALE_FACTOR: 0
[2023.10.10 09:50:50] QT_DPI_ADJUSTMENT_POLICY: AdjustDpi
[2023.10.10 

Bug#1029710: emacs-gtk: Default font odd after disabling rashi

[Shai Berger]

Package: emacs-gtk
Version: 1:29.1+1-5
Followup-For: Bug #1029710

Dear Maintainer,

After disabling the Rashi font as noted above, for some time,
the Hebrew font was sensible. But recently it changed again,
this time to Dorian.

By invoking the menu option:
"Options->Multilingual Environment->Show all multilingual settings"
I was able to see the list of fonts for the Hebrew block:

(#x590 .. #x5FF)
-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1
[-PfEd-Dorian CLM-regular-normal-normal-*-15-*-*-*-*-0-iso10646-1]
[-PfEd-Simple CLM-regular-normal-normal-*-15-*-*-*-*-0-iso10646-1]
[-PfEd-DejaVu Sans-bold-normal-normal-*-15-*-*-*-*-0-iso10646-1]
[-PfEd-David CLM-bold-italic-normal-*-15-*-*-*-*-0-iso10646-1]
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-8

Dorian is a cursive, "fancy" font (in fact it comes from the package
culmus-fancy, not from the core culmus package). It is not as bas as
Rashi, but still unsuitable as a default font for text editing in Hebrew.

What controls the order of fonts?

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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common 1:29.1+1-5
ii  emacs-common 1:29.1+1-5
ii  libacl1  2.3.1-3
ii  libasound2   1.2.9-2
ii  libc62.37-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.10-1
ii  libfontconfig1   2.14.2-4
ii  libfreetype6 2.13.2+dfsg-1
ii  libgccjit0   13.2.0-2
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgif7  5.2.1-2.5
ii  libglib2.0-0 2.77.2-1
ii  libgmp10 2:6.3.0+dfsg-2
ii  libgnutls30  3.8.1-4
ii  libgpm2  1.20.7-10+b1
ii  libgtk-3-0   3.24.38-4
ii  libharfbuzz0b8.0.1-1
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  libm17n-01.8.4-1
ii  libotf1  0.9.16-4
ii  libpango-1.0-0   1.51.0+ds-2
ii  libpng16-16  1.6.40-1
ii  librsvg2-2   2.54.7+dfsg-2
ii  libselinux1  3.5-1
ii  libsm6   2:1.2.3-1
ii  libsqlite3-0 3.42.0-1
ii  libsystemd0  254.1-2
ii  libtiff6 4.5.1+git230720-1
ii  libtinfo66.4+20230625-2
ii  libtree-sitter0  0.20.8-2
ii  libwebp7 1.2.4-0.2
ii  libwebpdemux21.2.4-0.2
ii  libx11-6 2:1.8.6-1
ii  libxcomposite1   1:0.4.5-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1.3
ii  libxrandr2   2:1.5.2-2+b1
ii  libxrender1  1:0.9.10-1.1
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages emacs-gtk recommends:
ii  fonts-noto-color-emoji  2.038-1

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

-- no debconf information

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Shai Berger]

Package: docker.io
Followup-For: Bug #865975

Dear Maintainer,

I come here with a different use-case. I use Debian on a desktop, in a
room where the home wifi is weak. The desktop is connected by wire,
but also has a wireless network adapter, so I set up a hotspot for my
phone -- using tools from KDE (plasma-nm). I never touched the kernel
configuration or firewall rules, as (like Jonathan above) I never
needed to.

Recently I installed Docker in order to play with something, and it
took me quite a while to find out why, suddenly, when my phone
connects to the hotspot, it gets no access to the internet.

Docker's "solution" of only blocking forwarding if it set
ip_forwarding=1 itself is not helpful in my case -- the hotspot was
defined in my desktop, but the docker daemon starts at boot, typically
before I can log in.

When the access point is active, the following nft rules are set:

table ip nm-shared-wlan0 {
chain nat_postrouting {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 10.42.0.0/24 ip daddr != 10.42.0.0/24 masquerade
}

chain filter_forward {
type filter hook forward priority filter; policy accept;
ip daddr 10.42.0.0/24 oifname "wlan0" ct state { established, 
related } accept
ip saddr 10.42.0.0/24 iifname "wlan0" accept
iifname "wlan0" oifname "wlan0" accept
iifname "wlan0" reject
oifname "wlan0" reject
}
}

This makes sense to me; when the UI opens up forwarding, it sets up
firewall rules to protect its own interfaces. Not everyone
else's. This is in the spirit of what Marvin suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#53 -- and it
makes me disagree with the statement in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#91, that
Docker is "doing nothing wrong".

I should point also that in the original issue, the main motivation
behind seeing this as a security issue is to protect the containers
(see
e.g. https://github.com/moby/moby/issues/14041#issuecomment-113554682).

I realize that opening up forwarding can affect the security of a
system.  I think that Debian should ship a docker package which
doesn't do this (this seems to be controllable by configutation), but
instead, makes the proper changes to the system upon installation (and
lets the user know).

(the option to just error out from Docker if forwarding is not set up
was also mentioned on the ticket).

Also, since I'm not convinced by the argument in message #91, and
since I've had docker break unrelated functionality, I also disagree
with the downgrade in message #98. This behavior, as has not been
contested, "makes unrelated software on the system break". I agree
that before the behavior's introduction, it "introduce[d] a security
hole on systems where you install[ed] the package", which is also
critical, but that should not make it acceptable to break unrelated
software.

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

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

Versions of packages docker.io depends on:
ii  adduser3.137
pn  containerd 
ii  init-system-helpers1.65.2
ii  iptables   1.8.9-2
ii  libc6  2.37-7
ii  libdevmapper1.02.1 2:1.02.185-2
ii  libsystemd0254.1-2
ii  lsb-base   11.6
pn  runc   
ii  sysvinit-utils [lsb-base]  3.07-1
pn  tini   

Versions of packages docker.io recommends:
ii  apparmor 3.0.12-1
ii  ca-certificates  20230311
pn  cgroupfs-mount   
ii  git  1:2.40.1-1
ii  needrestart  3.6-5
ii  xz-utils 5.4.4-0.1

Versions of packages docker.io suggests:
pn  aufs-tools 
pn  btrfs-progs
pn  debootstrap
pn  docker-doc 
ii  e2fsprogs  1.47.0-2
pn  rinse  
pn  rootlesskit
pn  xfsprogs   
pn  zfs-fuse | zfsutils-linux  

Bug#1050656: telegram-desktop: Bus Error whenever a channel has a video

[Shai Berger]

Package: telegram-desktop
Version: 4.8.1+ds-2+b2
Severity: important

Dear Maintainer,

Since the last update of telegram-desktop, every time I get to a video
in a channel or group, the program crashes.

I have run the program under gdb, and am attaching the traceback.
I hope it is useful.

-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libabsl20220623  20220623.1-3
ii  libavcodec-extra60 [libavcodec60]7:6.0-5
ii  libavfilter-extra9 [libavfilter9]7:6.0-5
ii  libavformat-extra60 [libavformat60]  7:6.0-5
ii  libavutil58  7:6.0-5
ii  libc62.37-7
ii  libgcc-s113.2.0-2
ii  libglib2.0-0 2.77.2-1
ii  libglibmm-2.68-1 2.77.0-1
ii  libhunspell-1.7-01.7.2+really1.7.2-10
ii  libjpeg62-turbo  1:2.1.5-2
ii  libkf5coreaddons55.107.0-1
ii  liblz4-1 1.9.4-1
ii  libminizip1  1:1.2.13.dfsg-3
ii  libopenal1   1:1.23.1-3
ii  libopus0 1.4-1
ii  libqrcodegencpp1 1.8.0-1.1
ii  libqt5core5a [qtbase-abi-5-15-10]5.15.10+dfsg-3
ii  libqt5gui5   5.15.10+dfsg-3
ii  libqt5network5   5.15.10+dfsg-3
ii  libqt5qml5   5.15.10+dfsg-2
ii  libqt5quickwidgets5  5.15.10+dfsg-2
ii  libqt5svg5   5.15.10-2
ii  libqt5waylandcompositor5 5.15.10-2
ii  libqt5widgets5   5.15.10+dfsg-3
ii  librlottie0-10.1+dfsg-4
ii  libsigc++-3.0-0  3.4.0-7
ii  libsrtp2-1   2.5.0-3
ii  libssl3  3.0.10-1
ii  libstdc++6   13.2.0-2
ii  libswresample4   7:6.0-5
ii  libswscale7  7:6.0-5
ii  libvpx7  1.12.0-1
ii  libwayland-client0   1.22.0-2
ii  libx11-6 2:1.8.6-1
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb-record0   1.15-1
ii  libxcb-screensaver0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  libxxhash0   0.8.1-1
ii  libyuv0  0.0~git20230616.a366ad7-1
ii  qt5-image-formats-plugins5.15.10-2
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans   1.11-2
ii  libwebkit2gtk-4.0-37  2.40.5-1
ii  libwebkit2gtk-4.1-0   2.40.5-1

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal   1.16.0-3
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]  5.27.7-1

-- no debconf information
[2023.08.27 14:12:03] Launched version: 4008001, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2023.08.27 14:12:03] Executable dir: /usr/bin/, name: telegram-desktop
[2023.08.27 14:12:03] Initial working dir: /home/shai/Documents/
[2023.08.27 14:12:03] Working dir: /home/shai/.local/share/TelegramDesktop/
[2023.08.27 14:12:03] Command line: /usr/bin/telegram-desktop
[2023.08.27 14:12:03] Executable path before check: /usr/bin/telegram-desktop
[2023.08.27 14:12:03] Logs started
[2023.08.27 14:12:03] Launcher filename: org.telegram.desktop.desktop
[2023.08.27 14:12:03] We use allocator from /lib/x86_64-linux-gnu/libc.so.6
[2023.08.27 14:12:06] Connecting local socket to 
/tmp/735a4fdec5600e9bc6df96b79a9689ee-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2023.08.27 14:12:06] Socket connect error 0, starting server and app...
[2023.08.27 14:12:06] Moved logging from 
'/home/shai/.local/share/TelegramDesktop/log_start0.txt' to 
'/home/shai/.local/share/TelegramDesktop/log.txt'!
[2023.08.27 14:12:06] Global devicePixelRatio: 1
[2023.08.27 14:12:06] QT_AUTO_SCREEN_SCALE_FACTOR: 0
[2023.08.27 14:12:06] QT_DPI_ADJUSTMENT_POLICY: AdjustDpi
[2023.08.27 14:12:06] Primary screen DPI: 96.1263, 

Bug#1042404: redis-server postinst script gets stuck when disk is low

[Shai Berger]

Hi Chris,

On Fri, 28 Jul 2023 10:17:49 +0100
"Chris Lamb"  wrote:

> 
> Hm. Do you know what part of the postinst script is sticking? You may
> be able to find out by looking at your process table eg. via top or
> htop.
> 
> (My initial guess is that redis process itself gets wedged when it has
> no diskspace, and then—even after freeing some space—the postinst is
> waiting for it to restart?)
> 

I think I saw something like that, indeed, one of my probes into the
system showed that a "systemctl stop redis" or something very similar
was still running.

This seems quite odd to me -- I thought Redis, at least in its default
configuration (which is what I use), was an in-memory database. Why
would it get stuck over low disk space? And, if it does get stuck --
why wouldn't we just kill it? And how come the postinst script is
SIGINT-resistant?

Bug#1042404: redis-server postinst script gets stuck when disk is low

[Shai Berger]

Package: redis-server
Version: 5:7.0.11-1
Severity: normal

Dear Maintainer,

My system was set up years ago, with a root partition that
is not really big enough anymore. Repeatedly, when I run
updates, I get in trouble because space on the root partition
runs out.

However, with most packages, this just means that setup fails,
and after I make some room, a "dpkg --configure -a" sets things
straight.

redis-server, not so. The script gets stuck, not erroring out and
not finishing. Even after it is killed and room becomes available,
it's still a hard fight to get it to complete; sometimes an
uninstall+install is enough, today, not even that seems to work.

BTW, when I say "killed", I do mean killed: Ctrl-C does nothing to
the dpkg or aptitude process. It needs to be stopped with ctrl-Z,
and then killed.

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

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

Versions of packages redis-server depends on:
ii  init-system-helpers1.65.2
ii  lsb-base   11.6
ii  redis-tools5:7.0.11-1
ii  sysvinit-utils [lsb-base]  3.07-1

redis-server recommends no packages.

redis-server suggests no packages.

-- Configuration Files:
/etc/redis/redis.conf [Errno 13] Permission denied: '/etc/redis/redis.conf'

-- no debconf information

Bug#1041773: wpasupplicant: probably wrong "handshake" for hotspot with WPA2-Personal

[Shai Berger]

Package: wpasupplicant
Version: 2:2.10-12
Severity: normal

Dear Maintainer,

I have been using wpasupplucant with NetworkManager under KDE for
several years, in order to make an access point in my study (where
the home wifi signal is too weak). I've been using a Samsung S9
phone, and all was well.

Lately, I bought a newer phone -- a Samsung S20 -- and with that
phone, I could not connect to the access point. I searched high and low,
until I found this
https://www.reddit.com/r/kde/comments/soqzo4/unable_to_connect_to_hotspot_made_with/
with the recommendation to use iwd instead of wpasupplicant.

And just like for that responder, iwd "just worked".

In addition to the S20 refusing to connect, I also have a laptop
running Ubuntu 20.04. When that laptop was scanning the relevant
network (with wpasupplicant), the access point showed up with
"unknown encryption scheme". With iwd, it says "WPA2-PSK".
(just to make perfectly clear: the computer where the backend
was switched is a Debian desktop. The laptop uses whatever is
default in Ubuntu, and nothing in it was changed).

BTW the Reddit page leads to a KDE bug
https://bugs.kde.org/show_bug.cgi?id=449265
but my guess would be that the bug is not in KDE, but
somewhere between wpasupplicant and NetworkManager.


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

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

Versions of packages wpasupplicant depends on:
ii  adduser3.137
ii  libc6  2.37-6
ii  libdbus-1-31.14.8-2
ii  libnl-3-2003.7.0-0.2+b1
ii  libnl-genl-3-200   3.7.0-0.2+b1
ii  libnl-route-3-200  3.7.0-0.2+b1
ii  libpcsclite1   2.0.0-1
ii  libreadline8   8.2-1.3
ii  libssl33.0.9-1

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

Re: Feature request: making gettext more robust

[Shai Berger]

Hi Gergely,

On Fri, 16 Jun 2023 16:46:31 +0200
Gergely Kalmár  wrote:

> 
> I'm still thinking that it should be possible for Django to wrap
> gettext in a way that allows us to raise exceptions. It seems silly
> to me that we could not control this core aspect of the process.
> 

I think indeed it is possible. Take a look at the code in
django/utils/translation/trans_real.py and in particular, the
TranslationCatalog class; I _think_ you should be able to insert a
"fallback" catalog which raises some non-KeyError exception in its
`__getitem__()`, and that should give you what you want.

Note that it may be a little complex -- the mechanism there is built to
handle not only fallback languages (i.e. "en-US => en"), but a set of
catalogs for each language (i.e. collecting the translations into one
language from different apps), and further, the translations in each
language need to be kept separate because each may have its own
pluralization formula (in English, last I checked, there is only
one rule -- if the number is not 1, it's plural -- but if you specify
this rule in the .po file, the formula you get is technically distinct
from the default. Other languages sometimes have actually different
rules in different files, mostly for historical reasons).

I'm explicitly not expressing an opinion about whether this is
desirable :).

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20230617170050.562f0d01.shai%40platonix.com.

Bug#1033681: ffmpeg: All executables fail to start with "Bus Error"

[Shai Berger]

Package: ffmpeg
Version: 7:5.1.2-3
Severity: important

Dear Maintainer,

I have not used ffmpeg in a while, so I cannot say how new this is,
but, as the title says, today, if I try to run ffmpgeg, ffprobe or
ffplay, even with just the '-version' flag, I get the same response:

$ ffmpeg -version
Bus error

This happens only on this one system. I have another system which
is also a Debian Testing, and there things do work.

I have tried to debug this, but to no avail:

$ gdb /usr/bin/ffmpeg 
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
[...]
This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from 
/home/shai/.cache/debuginfod_client/7215fbfbcdbd6cfa01fc6d11f68e6cd32e232637/debuginfo...

 
(gdb) r -version

   
Starting program: /usr/bin/ffmpeg -version
Downloading separate debug info for /lib64/ld-linux-x86-64.so.2
Downloading separate debug info for system-supplied DSO at 0x77fc9000   

   


   
Program received signal SIGBUS, Bus error.
0x77fd93c8 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) where
#0  0x77fd93c8 in ?? () from /lib64/ld-linux-x86-64.so.2
#1  0x77fe8c09 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x77fe519f in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x77fe6b1c in ?? () from /lib64/ld-linux-x86-64.so.2
#4  0x77fe59c8 in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x0002 in ?? ()
#6  0x7fffe16d in ?? ()
#7  0x7fffe17d in ?? ()
#8  0x in ?? ()
(gdb) 


I've also tried running the same with a user which never used
ffmpeg before, to account for some settings if relevant. Same.

I am at a loss on how to debug this further.

Thanks in advance for your attention and help,

   Shai.
   

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages ffmpeg depends on:
ii  libavcodec597:5.1.2-3
ii  libavdevice59   7:5.1.2-3
ii  libavfilter87:5.1.2-3
ii  libavformat59   7:5.1.2-3
ii  libavutil57 7:5.1.2-3
ii  libc6   2.36-8
ii  libpostproc56   7:5.1.2-3
ii  libsdl2-2.0-0   2.26.4+dfsg-1
ii  libswresample4  7:5.1.2-3
ii  libswscale6 7:5.1.2-3

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#1033681: ffmpeg: All executables fail to start with "Bus Error"

[Shai Berger]

Package: ffmpeg
Version: 7:5.1.2-3
Severity: important

Dear Maintainer,

I have not used ffmpeg in a while, so I cannot say how new this is,
but, as the title says, today, if I try to run ffmpgeg, ffprobe or
ffplay, even with just the '-version' flag, I get the same response:

$ ffmpeg -version
Bus error

This happens only on this one system. I have another system which
is also a Debian Testing, and there things do work.

I have tried to debug this, but to no avail:

$ gdb /usr/bin/ffmpeg 
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
[...]
This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from 
/home/shai/.cache/debuginfod_client/7215fbfbcdbd6cfa01fc6d11f68e6cd32e232637/debuginfo...

 
(gdb) r -version

   
Starting program: /usr/bin/ffmpeg -version
Downloading separate debug info for /lib64/ld-linux-x86-64.so.2
Downloading separate debug info for system-supplied DSO at 0x77fc9000   

   


   
Program received signal SIGBUS, Bus error.
0x77fd93c8 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) where
#0  0x77fd93c8 in ?? () from /lib64/ld-linux-x86-64.so.2
#1  0x77fe8c09 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x77fe519f in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x77fe6b1c in ?? () from /lib64/ld-linux-x86-64.so.2
#4  0x77fe59c8 in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x0002 in ?? ()
#6  0x7fffe16d in ?? ()
#7  0x7fffe17d in ?? ()
#8  0x in ?? ()
(gdb) 


I've also tried running the same with a user which never used
ffmpeg before, to account for some settings if relevant. Same.

I am at a loss on how to debug this further.

Thanks in advance for your attention and help,

   Shai.
   

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages ffmpeg depends on:
ii  libavcodec597:5.1.2-3
ii  libavdevice59   7:5.1.2-3
ii  libavfilter87:5.1.2-3
ii  libavformat59   7:5.1.2-3
ii  libavutil57 7:5.1.2-3
ii  libc6   2.36-8
ii  libpostproc56   7:5.1.2-3
ii  libsdl2-2.0-0   2.26.4+dfsg-1
ii  libswresample4  7:5.1.2-3
ii  libswscale6 7:5.1.2-3

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#1029710: Confirmation

[Shai Berger]

Dear Maintainer,

It's not just Tzafrir...

As a workaround, I added this in my .emacs:

(add-to-list 'face-ignored-fonts "Noto Rashi Hebrew")

Thanks,
Shai.

Re: Request for Guidance

[Shai Berger]

Hello,

On Wed, 18 Jan 2023 21:55:11 +0530
"'12_Gairick Dam' via Django developers  (Contributions to Django
itself)"  wrote:

> Hello please suggest me some easy good first issues to contribute
> 

The Django issue tracker has tickets marked as "Easy pickings".

You can see the search for them here:
https://code.djangoproject.com/query?status=assigned=new=1=1=id

For further guidance and advice, I think you may find the Django Forum
(at https://forum.djangoproject.com/ ) more helpful.

Welcome aboard, and have fun,

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20230118211647.683ffd04.shai%40platonix.com.

Re: kded5 crashes

[Shai Berger]

On Thu, 5 Jan 2023 20:11:48 +0100
"Miguel A. Vallejo"  wrote:

> I'm still experiencing constant kded5 crashes, but after a few days of
> googling I didn't find anything relevant... Is it a Debian Unstable
> only issue?
> 

I saw it on testing, but removing apper (as mentioned earlier in the
thread) seems to have improved things.

Re: get_manager short ut function proposal

[Shai Berger]

On Sun, 1 Jan 2023 16:33:45 +0200
Ramez Ashraf  wrote:

> 
> Interested or do you think the function can be enhanced it to make
> more useable for your everyday other cases ?
> 

This is half-baked, just a thought, but maybe you can take it some
place interesting:

Imagine a class that "collects" calls for later execution. Something
like (this exactly won't work, details below):

from functools import partialmethod
from django.db.models import QuerySet as QSet

class QS:
def __init__(self):
self._calls = []
def filter(self, *args, **kw):
self._calls.append(
partialmethod(QSet.filter, *args, **kw)
) 
return self
def annotate(*args, **kw):
# ... (same idea)
# ... other relevant methods, 
def __call__(self, qset):
for call in self._calls:
qset = apply(call, qset)
return qset

This won't work, I think, because partialmethod isn't supposed to work
quite this way, and the "apply" in the last line isn't defined. But
with this (fixed) already you could, I think, do something like

def qset_manager(qs: QS) -> Manager
class CustomManager(models.Manager):
def get_queryset(self):
orig = super().get_queryset()
return qs(orig)
return CustomManager()

And then, in your model, 

class Person(models.Model):
...
authors = qset_manager(QS().filter(role="A"))

and now the "make a manager with a modified queryset" pattern is
shortened in a general way.

As I said, just a half-baked thought. There's problems here to solve,
and many improvements to make.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20230101190053.671e8303.shai%40platonix.com.

Re: Backport for ticket 34063?

[Shai Berger]

Hi,

I think at this point it would help to move the discussion forward, if
we tried to step beyond the specific issue and phrase the revision in
the backporting policy. This will let us, I hope, have a more
principle-based discussion.

If I get it right -- please correct me, James -- it would be something
like this addition:

"In a new domain of functionality, which is considered major and
central, bugs which would have been release blockers if found in time
will be considered as candidates for backporting if found within the
next two LTS versions" -- or even "... if found before use of the new
domain of functionality becomes mainstream" -- or something similar.

I think looking at it from that angle will be more fruitful. I will say
that looking at this principle, thinking about the vicious cycle
mentioned by James, I tend towards accepting his arguments.

We may want to phrase it a different way: Think of such major domains
as "experimental". We did that in the Python3 transition -- we had
"experimental support" from 1.5, and IIRC that "experimental" label
wasn't dropped until 1.8. I doubt we can retroactively declare async
views as still experimental, but we can modify the backporting policy
to say "release-blocker-level bugs in experimental features will be
candidates for backporting as long as the feature is experimental";
and we can set an exception that says "async is still experimental for
backporting considerations", in view of the little use we've seen so
far.

(I can see the argument against the last proposition, that says
"experimental means potentially broken, so it should be less worthy of
backports rather than more"; I disagree, because (a) we do want to
encourage such experimentation, and (b) no, it doesn't really mean
potentially broken, it means the API is not yet covered by the
stability guarantees; we're at more liberty to change things when we
fix)

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20230101172133.29c41f34.shai%40platonix.com.

Re: Careful with dist-upgrade in unstable at the moment

[Shai Berger]

On Wed, 21 Dec 2022 21:37:45 +0100
Marc Haber  wrote:
> 
> P.S. dist-upgrade is as deprecated as it could be, it's not even in
> the man page any more
> 

It's called "full-upgrade" in apt and aptitude, but it's still called
"dist-upgrade" in apt-get, which still gets installed with the apt
package.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Shai Berger]

Hi,

Adding to the above, I have two migration-related ideas.

The first is quite down-to-earth: Support for moving models between
apps. This is a long-standing problem, esp. in enterprise-y or just
long-running projects. I have expressed my dissatisfaction with the
current state of things a couple of years ago[1], and maybe it's time
to change that.

The second is a bit of a pie-in-the-sky: Allow auto-detection of custom
migration operations. The auto-detector has its change-detection mostly
hard-coded into it[2], and it doesn't seem easy or even possible to
allow third-party code to intervene. But I dream...

Note: These two are quite independent. Auto-detection of the fact that
a model has moved between apps is not required, supporting such moves
with flags to makemigrations or even a dedicated management-command
would be completely satisfactory as far as I'm concerned.

Thanks,
Shai.


[1] https://forum.djangoproject.com/t/why-do-we-need-apps/827/20
[2] 
https://github.com/django/django/blob/main/django/db/migrations/autodetector.py#L104

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20221126180231.372b01a2.shai%40platonix.com.

Bug#1003108: python3-poetry: Still an issue

[Shai Berger]

Package: python3-poetry
Version: 1.1.14+dfsg-1
Followup-For: Bug #1003108

Dear Maintainer,

Just installed poetry, ran into the missing cachecontrol,
installed cachecontrol manually, all seems fine.

The default for poetry in Debian, though, is just not to work,
as long as this is not handled.

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python3-poetry depends on:
ii  python3 3.10.5-3
ii  python3-cachecontrol0.12.12-2
ii  python3-cachy   0.3.0-4
ii  python3-cleo0.8.1-4
ii  python3-clikit  0.6.2-3
ii  python3-html5lib1.1-3
ii  python3-importlib-metadata  4.12.0-1
ii  python3-lockfile1:0.12.2-2.2
ii  python3-packaging   21.3-1.1
ii  python3-pexpect 4.8.0-3
ii  python3-pkginfo 1.8.2-1
ii  python3-poetry-core 1.0.8-2
ii  python3-requests2.27.1+dfsg-1
ii  python3-requests-toolbelt   0.9.1-2
ii  python3-shellingham 1.5.0-1
ii  python3-tomlkit 0.11.6-1
ii  python3-virtualenv  20.16.6+ds-1

python3-poetry recommends no packages.

python3-poetry suggests no packages.

-- no debconf information

Bug#967010: apache2: Did not reporoduce

[Shai Berger]

Hi,

On Tue, 08 Nov 2022 18:05:23 +0100
"Yadd"  wrote:

> 
> Hi, it's a Buster-only bug, not a Bullseye's one
> 

It was flagged by apt-listbugs on my bookworm/sid system.

Bug#967010: apache2: Did not reporoduce

[Shai Berger]

Hi,

On Tue, 08 Nov 2022 18:05:23 +0100
"Yadd"  wrote:

> 
> Hi, it's a Buster-only bug, not a Bullseye's one
> 

It was flagged by apt-listbugs on my bookworm/sid system.

Bug#967010: apache2: Did not reporoduce

[Shai Berger]

Hi,

On Tue, 08 Nov 2022 18:05:23 +0100
"Yadd"  wrote:

> 
> Hi, it's a Buster-only bug, not a Bullseye's one
> 

It was flagged by apt-listbugs on my bookworm/sid system.

Bug#967010: apache2: Did not reporoduce

[Shai Berger]

Package: apache2
Followup-For: Bug #967010

Dear Maintainer,

I just installed Apache2 and did not encounter the problem
as reported in this bug.

It is an old bug, and for some reason full of spam.

Please close and/or delete it.

Thanks.

-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages apache2 depends on:
ii  apache2-bin2.4.54-3
ii  apache2-data   2.4.54-3
ii  apache2-utils  2.4.54-3
ii  init-system-helpers1.65.2
ii  lsb-base   11.4
ii  mime-support   3.66
ii  perl   5.36.0-4
ii  procps 2:3.3.17-7.1
ii  sysvinit-utils [lsb-base]  3.05-6

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.2

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   107.0.5304.87-1
ii  dillo [www-browser]  3.0.5-7+b1
ii  firefox-esr [www-browser]102.4.0esr-1
ii  konqueror [www-browser]  4:21.12.3-1
ii  lynx [www-browser]   2.9.0dev.10-1+b1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-8
ii  libaprutil1  1.6.1-5+b2
ii  libaprutil1-dbd-sqlite3  1.6.1-5+b2
ii  libaprutil1-ldap 1.6.1-5+b2
ii  libbrotli1   1.0.9-2+b4
ii  libc62.35-4
ii  libcrypt11:4.4.28-2
ii  libcurl4 7.85.0-1
ii  libjansson4  2.14-2
ii  libldap-2.5-02.5.13+dfsg-2+b1
ii  liblua5.3-0  5.3.6-1+b1
ii  libnghttp2-141.50.0-1+b1
ii  libpcre2-8-0 10.40-2
ii  libssl3  3.0.7-1
ii  libxml2  2.9.14+dfsg-1+b1
ii  perl 5.36.0-4
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   107.0.5304.87-1
ii  dillo [www-browser]  3.0.5-7+b1
ii  firefox-esr [www-browser]102.4.0esr-1
ii  konqueror [www-browser]  4:21.12.3-1
ii  lynx [www-browser]   2.9.0dev.10-1+b1

Versions of packages apache2 is related to:
ii  apache2  2.4.54-3
ii  apache2-bin  2.4.54-3

-- no debconf information

Bug#967010: apache2: Did not reporoduce

[Shai Berger]

Package: apache2
Followup-For: Bug #967010

Dear Maintainer,

I just installed Apache2 and did not encounter the problem
as reported in this bug.

It is an old bug, and for some reason full of spam.

Please close and/or delete it.

Thanks.

-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages apache2 depends on:
ii  apache2-bin2.4.54-3
ii  apache2-data   2.4.54-3
ii  apache2-utils  2.4.54-3
ii  init-system-helpers1.65.2
ii  lsb-base   11.4
ii  mime-support   3.66
ii  perl   5.36.0-4
ii  procps 2:3.3.17-7.1
ii  sysvinit-utils [lsb-base]  3.05-6

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.2

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   107.0.5304.87-1
ii  dillo [www-browser]  3.0.5-7+b1
ii  firefox-esr [www-browser]102.4.0esr-1
ii  konqueror [www-browser]  4:21.12.3-1
ii  lynx [www-browser]   2.9.0dev.10-1+b1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-8
ii  libaprutil1  1.6.1-5+b2
ii  libaprutil1-dbd-sqlite3  1.6.1-5+b2
ii  libaprutil1-ldap 1.6.1-5+b2
ii  libbrotli1   1.0.9-2+b4
ii  libc62.35-4
ii  libcrypt11:4.4.28-2
ii  libcurl4 7.85.0-1
ii  libjansson4  2.14-2
ii  libldap-2.5-02.5.13+dfsg-2+b1
ii  liblua5.3-0  5.3.6-1+b1
ii  libnghttp2-141.50.0-1+b1
ii  libpcre2-8-0 10.40-2
ii  libssl3  3.0.7-1
ii  libxml2  2.9.14+dfsg-1+b1
ii  perl 5.36.0-4
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   107.0.5304.87-1
ii  dillo [www-browser]  3.0.5-7+b1
ii  firefox-esr [www-browser]102.4.0esr-1
ii  konqueror [www-browser]  4:21.12.3-1
ii  lynx [www-browser]   2.9.0dev.10-1+b1

Versions of packages apache2 is related to:
ii  apache2  2.4.54-3
ii  apache2-bin  2.4.54-3

-- no debconf information

Bug#967010: apache2: Did not reporoduce

[Shai Berger]

Package: apache2
Followup-For: Bug #967010

Dear Maintainer,

I just installed Apache2 and did not encounter the problem
as reported in this bug.

It is an old bug, and for some reason full of spam.

Please close and/or delete it.

Thanks.

-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages apache2 depends on:
ii  apache2-bin2.4.54-3
ii  apache2-data   2.4.54-3
ii  apache2-utils  2.4.54-3
ii  init-system-helpers1.65.2
ii  lsb-base   11.4
ii  mime-support   3.66
ii  perl   5.36.0-4
ii  procps 2:3.3.17-7.1
ii  sysvinit-utils [lsb-base]  3.05-6

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.2

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   107.0.5304.87-1
ii  dillo [www-browser]  3.0.5-7+b1
ii  firefox-esr [www-browser]102.4.0esr-1
ii  konqueror [www-browser]  4:21.12.3-1
ii  lynx [www-browser]   2.9.0dev.10-1+b1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-8
ii  libaprutil1  1.6.1-5+b2
ii  libaprutil1-dbd-sqlite3  1.6.1-5+b2
ii  libaprutil1-ldap 1.6.1-5+b2
ii  libbrotli1   1.0.9-2+b4
ii  libc62.35-4
ii  libcrypt11:4.4.28-2
ii  libcurl4 7.85.0-1
ii  libjansson4  2.14-2
ii  libldap-2.5-02.5.13+dfsg-2+b1
ii  liblua5.3-0  5.3.6-1+b1
ii  libnghttp2-141.50.0-1+b1
ii  libpcre2-8-0 10.40-2
ii  libssl3  3.0.7-1
ii  libxml2  2.9.14+dfsg-1+b1
ii  perl 5.36.0-4
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   107.0.5304.87-1
ii  dillo [www-browser]  3.0.5-7+b1
ii  firefox-esr [www-browser]102.4.0esr-1
ii  konqueror [www-browser]  4:21.12.3-1
ii  lynx [www-browser]   2.9.0dev.10-1+b1

Versions of packages apache2 is related to:
ii  apache2  2.4.54-3
ii  apache2-bin  2.4.54-3

-- no debconf information

Change in windows' behavior with two screens

[Shai Berger]

Hello,

Like many other users, I have a laptop which I routinely connect to a
larger, external screen. I often start a session with no screen
attached, and then attach an external screen and designate it as the
primary screen.

What I would like to happen, when I do this, is for all the application
windows to jump to the new primary screen, but this has never happenned.
Only the task bar jumps.

However, I had an easy way to make them jump: Just close the lid, and
all open windows move to the external (now, only avaliable) screen. And
this still works.

But up with kwin<=5.25.5, I could then re-open the laptop, and all
would be well -- the windows would stay on the primary screen, and I
could use the laptop screen for special things only, as I like. Since
5.26.0, when I re-open the lid, the windows jump back to the laptop
screen.

I've looked for a setting to control this, and could find none. Is
there a setting I'm missing? Is there a control saying "windows should
not remember where they came from" that escaped me?

Thanks,
Shai.

Re: Model-level validation

[Shai Berger]

I see two separate concerns here:

1) Should Django present to users the option to do validate-on-save by
default? That is, should that option be visible -- in the form of a
documented setting or an optional argument to save()?

I tend to accept James'  (and others) views and reasoning against that.

2) Can a user activate validation-on-save-by-default without resorting
to monkeypatching? Should it be possible?

I think applying such validation should be possible -- because, in many
places, you see less-than-disciplined teams creating large projects
containing heaps of code that is not of the finest quality. And I think
we should help these projects improve incrementally -- that is,
introduce means to improve their situation; promoting notions like

data mutation should occur only in well-defined, controlled ways

without making them prerequisite.

This notion is a nice ideal, but installing it on a project
after-the-fact is hard; in many places it is not realistically
attainable -- at least in the boundaries of the team's resources,
delivery requirements, and a reasonable timeframe.

Note that for such general validation, a project-wide-base-model as
suggested e.g. by Uri is, in general, not sufficient, because it may
not apply to models from 3rd-party apps, or even from django.contrib
apps. Most models in such apps are not swappable.

But there is a way, I think, using a pre_save signal. One can write a
small app to install pre-save validation on all models in the project,
merely by including it in INSTALLED_APPS.

Basically, 

from django.db.models import signals
...
class WhateverConfig(AppConfig):
...

def ready()

def validate(sender, instance, raw, **kwargs):
if not raw:
instance.full_clean()

signals.pre_save.connect(validate, weak=False)

This, of course, is just a POC -- it doesn't include things like
allowing a model to opt out, for example. Or one might want to apply it
only where settings.DEBUG is set. Or only log warnings. Or a few other
variations that don't jump to my mind immediately.

But it is a way for those of us involved with large teams and projects
to add this feature, without affecting the experience of newcomers or
the layer-separation sensibilities of the framework.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20221010163935.4ba0fcb6.shai%40platonix.com.

Suggestion: Limit activated languages to settings.LANGUAGES

[Shai Berger]

Hello Djangonauts,

This suggestion is following from discussions of the security issue
which was resolved in today's release. In essence, the issue is that
language codes are optionally used as prefixes in URLs, and for this
use they also become part of regular expressions used by the URL
resolution mechanisms. So, if an attacker manages to convince the
server to use a "language code" which encodes a pathologically complex
regex, the server can be DOS'd. The solution was to modify the
regex-inclusion part to regex-escape the language code -- ensuring
that language codes are never interpreted, in this role, as anything
other than a simple chain of single characters. This is the proper
security fix: Prevents the problem where it could manifest, with
minimal effects elsewhere. 

But looking forward, I think we should reconsider the fact that
django.utils.translation.activate() will just activate whatever
language code it is given. We do have a setting, LANGUAGES, which
defines a list of the languages (and codes) supported by our site. Why
should activate() accept anything that is not in this list?

Two points have been raised in support of the current behavior: The
existence of custom languages, and of fallback language codes (that is,
e.g where the user asks for zh-hk and gets, instead, zh-hant). But in
my opinion, they do not justify it:

- A custom language should be included in settings.LANGUAGES if it is
  to be supported; otherwise, e.g. makemessages will not even handle
  its translation file.

- When a language with a fallback is requested, the site should really
  activate the fallback language, not pretend to activate the requested
  one while actually using the fallback. As an example, if "en-us" is
  used as a fallback for "en-gb", and the URL has "en-gb" in it, then a
  British user would rightly be offended by all the American spelling
  they would see. The site should be honest enough to say "yes, you
  asked for en-gb, but we fell back to en-us; sorry, that's the best we
  have for you".

Note that there are all sorts of functions that check if a language
code is valid. For example, django.views.i18n.set_language() checks if
a translation for the languages exists in the project or its apps (but
not, AFAICT, the setting). d.u.translation.get_language_from_request()
and get_language_from_path() do check the LANGUAGES setting. It is
likely that including the check in activate() will do some double work.
And yet, we found ourselves introducing the security fix.

(I should note that this suggestion was also, independently, raised by
Benjamin who reported the vulnerability)

Opinions, suggestions, and explanations of the value I miss in allowing
activate() to take random language codes welcome.

Thanks,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20221004170511.4342ebc7.shai%40platonix.com.

[Pkg-kde-extras] Bug#994928: kde-style-qtcurve-qt5 should Provide: kde-style-qtcurve

[Shai Berger]

Package: kde-style-qtcurve-qt5
Version: 1.9-7+b3
Followup-For: Bug #994928

Dear Maintainer,

Just found the same. Still a problem.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages kde-style-qtcurve-qt5 depends on:
ii  kio   5.98.0-1
ii  libc6 2.34-8
ii  libkf5archive55.98.0-1
ii  libkf5completion5 5.98.0-1
ii  libkf5configcore5 5.98.0-1
ii  libkf5configwidgets5  5.98.0-1
ii  libkf5coreaddons5 5.98.0-1
ii  libkf5guiaddons5  5.98.0-1
ii  libkf5i18n5   5.98.0-1
ii  libkf5iconthemes5 5.98.0-2
ii  libkf5kdelibs4support55.98.0-1
ii  libkf5kiowidgets5 5.98.0-1
ii  libkf5style5  5.98.0-1
ii  libkf5widgetsaddons5  5.98.0-1
ii  libkf5windowsystem5   5.98.0-1
ii  libkf5xmlgui5 5.98.0-1
ii  libqt5core5a [qtbase-abi-5-15-4]  5.15.4+dfsg-5
ii  libqt5dbus5   5.15.4+dfsg-5
ii  libqt5gui55.15.4+dfsg-5
ii  libqt5printsupport5   5.15.4+dfsg-5
ii  libqt5svg55.15.4-2
ii  libqt5widgets55.15.4+dfsg-5
ii  libqt5x11extras5  5.15.4-2
ii  libqtcurve-utils2 1.9-7+b3
ii  libstdc++612.2.0-3

kde-style-qtcurve-qt5 recommends no packages.

Versions of packages kde-style-qtcurve-qt5 suggests:
pn  gtk2-engines-qtcurve  

-- no debconf information

___
pkg-kde-extras mailing list
pkg-kde-extras@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-kde-extras

Bug#994928: kde-style-qtcurve-qt5 should Provide: kde-style-qtcurve

[Shai Berger]

Package: kde-style-qtcurve-qt5
Version: 1.9-7+b3
Followup-For: Bug #994928

Dear Maintainer,

Just found the same. Still a problem.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages kde-style-qtcurve-qt5 depends on:
ii  kio   5.98.0-1
ii  libc6 2.34-8
ii  libkf5archive55.98.0-1
ii  libkf5completion5 5.98.0-1
ii  libkf5configcore5 5.98.0-1
ii  libkf5configwidgets5  5.98.0-1
ii  libkf5coreaddons5 5.98.0-1
ii  libkf5guiaddons5  5.98.0-1
ii  libkf5i18n5   5.98.0-1
ii  libkf5iconthemes5 5.98.0-2
ii  libkf5kdelibs4support55.98.0-1
ii  libkf5kiowidgets5 5.98.0-1
ii  libkf5style5  5.98.0-1
ii  libkf5widgetsaddons5  5.98.0-1
ii  libkf5windowsystem5   5.98.0-1
ii  libkf5xmlgui5 5.98.0-1
ii  libqt5core5a [qtbase-abi-5-15-4]  5.15.4+dfsg-5
ii  libqt5dbus5   5.15.4+dfsg-5
ii  libqt5gui55.15.4+dfsg-5
ii  libqt5printsupport5   5.15.4+dfsg-5
ii  libqt5svg55.15.4-2
ii  libqt5widgets55.15.4+dfsg-5
ii  libqt5x11extras5  5.15.4-2
ii  libqtcurve-utils2 1.9-7+b3
ii  libstdc++612.2.0-3

kde-style-qtcurve-qt5 recommends no packages.

Versions of packages kde-style-qtcurve-qt5 suggests:
pn  gtk2-engines-qtcurve  

-- no debconf information

Re: State of KDE in testing?

[Shai Berger]

Hi,

I've been using KDE/X from testing for a few years, which implies I'm
generally pleased enough. As others pointed out, there are problems;
the one I've experienced most, in the last few weeks, is kwin crashing
(it restarts automatically and windows seem to all stay where they
were, so it's not terrible). I should point out that I'm not a very
sophisticated user, my common mode of operation is one window maximized
on one screen, while ignoring the other screen; but I do mix windows
from different users in one X-session. In fact, the thing that's been
broken for me so long that I've learned how to deal with it, is sound
only being available to one user at a time.

Your mileage may vary,
Shai.

Re: Digital clock widget and 24-hour format

[Shai Berger]

On Wed, 30 Mar 2022 00:54:21 +0200 (CEST)
local10  wrote:

> 
> How did you set LC_ALL to "C.UTF-8"? I tried adding LC_ALL="C.UTF-8"
> to ~/.bash_profile but that seems to have no effect.
> 

You need to export it. When you define an environment variable and do
not export it, it is not passed to sub-processes (like the one
executing the 'locale' command).

$ LC_ALL=C.UTF-8
$ locale
LANG=en_IL.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_IL.UTF-8"
LC_NUMERIC="en_IL.UTF-8"
LC_TIME="en_IL.UTF-8"
LC_COLLATE="en_IL.UTF-8"
LC_MONETARY="en_IL.UTF-8"
LC_MESSAGES="en_IL.UTF-8"
LC_PAPER="en_IL.UTF-8"
LC_NAME="en_IL.UTF-8"
LC_ADDRESS="en_IL.UTF-8"
LC_TELEPHONE="en_IL.UTF-8"
LC_MEASUREMENT="en_IL.UTF-8"
LC_IDENTIFICATION="en_IL.UTF-8"
LC_ALL=

$ export LC_ALL=C.UTF-8
$ locale
LANG=en_IL.UTF-8
LANGUAGE=en_US
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=C.UTF-8

HTH,
Shai.

Re: Mail-Server response: A000002 NO Authentication failed

[Shai Berger]

On Wed, 23 Mar 2022 21:17:09 +0100
Herbert-Schwarzer  wrote:

> Hello hefee,
> 
> Yes, 'siduction' produces the same pop up window, same behaviour as
> in my main Debian 11.2 installation.
> So I changed VM-installation siduction -> KDE Neon unstable. Sadly,
> but the the same error TOO.
> It leaves me somewhat perplexed.
> It is a pity - as a normal end-user - but very interested in Debian
> since serveral years - I would like to know & explore such behaviour
> (in our mails I have learned serveral things :) )
> 

One direction you might want to follow is to look for the specific
process which pops up the message -- see
https://kb.froglogic.com/misc/find-process-for-window/

HTH,
Shai.

Bug#1007259: closed by Debian FTP Masters (reply to Ricardo Mones ) (Bug#1007259: fixed in claws-mail 4.0.0-3)

[Shai Berger]

Yay! Thanks a bunch!

Re: Digital clock wizard and 24-hour format

[Shai Berger]

FWIW, my digital clock's "Time display" is set to "Use Region
Defaults", not "24 hours", and I do get a 24 hour clock (which is what
my region defines).

Bug#1007259: claws-mail-extra-plugins: Please re-package Fancy plugin

[Shai Berger]

Package: claws-mail-extra-plugins
Version: 4.0.0-2
Severity: wishlist

Dear Maintainer,

With claws-mail 3.X, based on Gtk2, the fancy plugin needed
an abandoned branch of libwebkitgtk, and basically required
the package libwebkitgtk-1.0.0 which had been removed from
Debian. But now that 4.0.0 is based on Gtk3, Fancy can be built
against libwebkit2gtk-4.0-37 which is very much alive.

Can we bring claws-mail-fancy-plugin back?

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages claws-mail-extra-plugins depends on:
ii  claws-mail-acpi-notifier 4.0.0-2+b1
ii  claws-mail-address-keeper4.0.0-2+b1
ii  claws-mail-archiver-plugin   4.0.0-2+b1
ii  claws-mail-attach-remover4.0.0-2+b1
ii  claws-mail-attach-warner 4.0.0-2+b1
ii  claws-mail-bsfilter-plugin   4.0.0-2+b1
ii  claws-mail-clamd-plugin  4.0.0-2+b1
ii  claws-mail-dillo-viewer  4.0.0-2+b1
ii  claws-mail-feeds-reader  4.0.0-2+b1
ii  claws-mail-fetchinfo-plugin  4.0.0-2+b1
ii  claws-mail-gdata-plugin  4.0.0-2+b1
ii  claws-mail-libravatar4.0.0-2+b1
ii  claws-mail-litehtml-viewer   4.0.0-2+b1
ii  claws-mail-mailmbox-plugin   4.0.0-2+b1
ii  claws-mail-managesieve   4.0.0-2+b1
ii  claws-mail-multi-notifier4.0.0-2+b1
ii  claws-mail-newmail-plugin4.0.0-2+b1
ii  claws-mail-pdf-viewer4.0.0-2+b1
ii  claws-mail-perl-filter   4.0.0-2+b1
ii  claws-mail-spam-report   4.0.0-2+b1
ii  claws-mail-tnef-parser   4.0.0-2+b1
ii  claws-mail-vcalendar-plugin  4.0.0-2+b1

claws-mail-extra-plugins recommends no packages.

claws-mail-extra-plugins suggests no packages.

-- no debconf information

Bug#943671: claws-mail 4.0.0 is based on GTK3

[Shai Berger]

Package: claws-mail
Followup-For: Bug #943671

Dear Maintainer,

With claws-mail 4.0.0 based on GTK3 in testing, I believe this bug can be 
closed.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages claws-mail depends on:
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libcompfaceg11:1.5.2-5.1
ii  libdbus-glib-1-2 0.112-2
ii  libenchant-2-2   2.3.2-1
ii  libetpan20   1.9.4-3
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.4-1
ii  libgnutls30  3.7.3-4+b1
ii  libgtk-3-0   3.24.33-1
ii  libice6  2:1.0.10-1
ii  libldap-2.4-22.4.59+dfsg-1+b1
ii  libnettle8   3.7.3-1
ii  libpango-1.0-0   1.50.4+ds-1
ii  libpangocairo-1.0-0  1.50.4+ds-1
ii  librsvg2-2   2.52.5+dfsg-3+b1
ii  libsm6   2:1.2.3-1
ii  xdg-utils1.1.3-4.1

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  claws-mail-i18n4.0.0-2
ii  xfonts-100dpi  1:1.0.4+nmu1.1
ii  xfonts-75dpi   1:1.0.4+nmu1.1

Versions of packages claws-mail suggests:
ii  chromium [www-browser] 98.0.4758.102-1
ii  claws-mail-doc 4.0.0-2
pn  claws-mail-tools   
ii  dillo [www-browser]3.0.5-7
ii  firefox-esr [www-browser]  91.7.0esr-1
ii  gedit  41.0-3
ii  konqueror [www-browser]4:21.12.3-1
ii  kwrite 4:21.12.3-1
ii  lynx [www-browser] 2.9.0dev.10-1
ii  mousepad   0.5.8-1+b1

-- no debconf information

Re: mysqld not stopped on logout

[Shai Berger]

I don't use Akonadi so I haven't seen this specific one, but I do
regularly see some services -- mostly Gnome-related, like gvfsd -- stay
up after logout, and recently, they, too, require kill -9 to stop.

Re: [SPAM] Disabling/enabling touch pad on keyboard

[Shai Berger]

On Thu, 20 Jan 2022 21:13:04 +0100
Erwan David  wrote:

> Hi,
> 
> I use debian testing. Sometime, by walking on the keyboard my cat 
> disables the touchpad of my Lenovo T590. I used to be able to get it 
> back by disabling and reenabling it in the system settings (or with
> the systrau "touchpad" icon), but it does not do anything anymore .
> 
> Do someone have a solution to reenabe it without logging out ?
> 
> Thanks
> 

I have a setting that disables the touchpad when a mouse is connected.
Maybe this setting is on for you, and maybe, for some reason, your
system decided that the Lenovo red controller (not sure what it's
called) is a mouse, so that's where I'd look.

Far fetched, but since there appear to be no better ideas...

HTH,
Shai.

Re: Dolphin stopped displaying hidden folders in the Folders pane

[Shai Berger]

Hi Gary,

On Thu, 20 Jan 2022 13:29:35 -0500
Gary Dale  wrote:

> I'm running Debian/Bookworm on an AMD64 machine.
> 
> For a few weeks now, Dolphin hasn't been showing hidden folders in
> the Folders pane. I've set the view to show hidden files and have
> been seeing hidden folders in the Folders pane since Dolphin was
> first introduced.
> 

I use Bookworm as well, and my folders panel does show hidden folders.
I'd consider trying with a different user, to see if the problem is
somehow caused by your profile or settings.

HTH,
Shai.

Bug#1001947: firefox-esr: Update from Firefox 78 to 91 reset browser.ctrlTab.sortByRecentlyUsed

[Shai Berger]

On Mon, 20 Dec 2021 05:36:42 +0900
Mike Hommey  wrote:

> 
> Filed upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1746804
> but at this point, this is probably unfixable... 
> 

Thanks. My apologies for thinking this was more likely to be a
packaging bug than an upstream one; though, by the description, one
needs to be more knowledgable than me to figure out what the problem
was...

Given the above, I won't object to the bug being closed and marked
wontfix, if you find that more useful.

> Note the pref is in Settings, under General > Tabs.
> 

Thanks, that helps! I have several Firefox profiles, some are still not
fixed.

Cheers,
Shai.

Bug#1001947: firefox-esr: Update from Firefox 78 to 91 reset browser.ctrlTab.sortByRecentlyUsed

[Shai Berger]

Package: firefox-esr
Version: 91.4.0esr-1
Severity: normal

Dear Maintainer,

I have been using Firefox for years; an important part
of the experience is having ctrl-tab go through tabs in
the order of recent use, rather than cycling through them
from left to right. This is not the default, but enabled
by an about:config flag named 'browser.ctrlTab.sortByRecentlyUsed'

Following the very welcome upgrade from 78 to 91, I
found that the browser reverted this flag to its default,
and I had to set it on again manually (after finding again
what it was named...)

Thanks for all your great efforts,

Shai.


-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firebug
Location: ${PROFILE_EXTENSIONS}/fire...@software.joehewitt.com.xpi
Status: app-disabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
Status: enabled

Name: Hebrew (IL) Language Pack locale
Location: 
/usr/lib/firefox-esr/browser/extensions/langpack...@firefox-esr.mozilla.org.xpi
Package: firefox-esr-l10n-he
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Proxy Failover
Location: /usr/lib/firefox-esr/browser/features/proxy-failo...@mozilla.com.xpi
Package: firefox-esr
Status: enabled

Name: System theme theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr 91.4.0esr-1  amd64Mozilla Firefox web browser - 
Extended Support Release (ESR)
ii  firefox-esr-l10n-he 91.4.0esr-1  all  Hebrew language package for 
Firefox ESR

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-3
ii  libc62.33-1
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-3
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.11.0+dfsg-1
ii  libgcc-s111.2.0-12
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.2-1
ii  libgtk-3-0   3.24.30-4
ii  libnspr4 2:4.32-3
ii  libnss3  2:3.73-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-12
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.4.1-2+b1

Versions of packages firefox-esr 

Bug#999339: plasma-workspace: Maximized windows do not move to primary display when connected

[Shai Berger]

Hi Norbert, thanks for your very prompt reply, and my apologies for
failing to reply in kind.

On Wed, 10 Nov 2021 15:41:25 +0900
Norbert Preining  wrote:

> 
> Can you please test 5.23.3 which I have uploaded just today. It has
> several fixes included concerning exactly this problem, as far as I
> read it.
> 

I use "testing", and AFAICT 5.23.3 hasn't yet migrated there.

I added sid to the sources-list, and upgraded kde-plasma-desktop, which
did the following:

[UPGRADE] kde-plasma-desktop:amd64 5:114 -> 5:115
[UPGRADE] kwin-common:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] kwin-data:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] kwin-x11:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libcolorcorrect5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkfontinst5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkfontinstui5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkwin4-effect-builtins1:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkwineffects13:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkwinglutils13:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkwinxrenderutils13:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkworkspace5-5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libnotificationmanager1:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libplasma-geolocation-interface5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libtaskmanager6abi1:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libweather-ion7:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] plasma-desktop:amd64 4:5.23.2.1-1 -> 4:5.23.3-1
[UPGRADE] plasma-desktop-data:amd64 4:5.23.2.1-1 -> 4:5.23.3-1
[UPGRADE] plasma-workspace:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] plasma-workspace-data:amd64 4:5.23.2-1 -> 4:5.23.3-1

With these in place, the problem did not improve.

Thanks,
Shai.

Bug#999339: plasma-workspace: Maximized windows do not move to primary display when connected

[Shai Berger]

Hi Norbert, thanks for your very prompt reply, and my apologies for
failing to reply in kind.

On Wed, 10 Nov 2021 15:41:25 +0900
Norbert Preining  wrote:

> 
> Can you please test 5.23.3 which I have uploaded just today. It has
> several fixes included concerning exactly this problem, as far as I
> read it.
> 

I use "testing", and AFAICT 5.23.3 hasn't yet migrated there.

I added sid to the sources-list, and upgraded kde-plasma-desktop, which
did the following:

[UPGRADE] kde-plasma-desktop:amd64 5:114 -> 5:115
[UPGRADE] kwin-common:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] kwin-data:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] kwin-x11:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libcolorcorrect5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkfontinst5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkfontinstui5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkwin4-effect-builtins1:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkwineffects13:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkwinglutils13:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkwinxrenderutils13:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libkworkspace5-5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libnotificationmanager1:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libplasma-geolocation-interface5:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libtaskmanager6abi1:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] libweather-ion7:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] plasma-desktop:amd64 4:5.23.2.1-1 -> 4:5.23.3-1
[UPGRADE] plasma-desktop-data:amd64 4:5.23.2.1-1 -> 4:5.23.3-1
[UPGRADE] plasma-workspace:amd64 4:5.23.2-1 -> 4:5.23.3-1
[UPGRADE] plasma-workspace-data:amd64 4:5.23.2-1 -> 4:5.23.3-1

With these in place, the problem did not improve.

Thanks,
Shai.

Bug#999339: plasma-workspace: Maximized windows do not move to primary display when connected

[Shai Berger]

Package: plasma-workspace
Version: 4:5.23.2-1
Severity: normal

Dear Maintainer,

I use a laptop in different locations, with external screens.
Since the external screens are larger, I usually set them as 
the primary display, and use most of my applications there.

Until (and including) 5.21, when I had windows on the external
screen, disconnected it and reconnected an external screen, the
windows would hop back to the external (primary) display.

Since 5.23, I've noted that this doesn't quite work. With the
current version I've noticed further that it's the maximized
windows, specifically, which stay on the laptop screen (which,
when an external is connected, is the secondary display); 
normal-sized windows behave as expected.

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]1.12.20-3
ii  drkonqi 5.23.2-1
ii  frameworkintegration5.86.0-1
ii  gdb-minimal [gdb]   10.1-2
ii  init-system-helpers 1.60
ii  iso-codes   4.7.0-1
ii  kactivitymanagerd   5.23.2-1
ii  kded5   5.86.0-1
ii  kinit   5.86.0-1
ii  kio 5.86.0-1
ii  kpackagetool5   5.86.0-1
ii  kwin-common 4:5.23.2-1
ii  libappstreamqt2 0.14.6-1
ii  libc6   2.32-4
ii  libcolorcorrect54:5.23.2-1
ii  libegl1 1.3.4-2+b1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.11.0+dfsg-1
ii  libgcc-s1   11.2.0-10
ii  libgl1  1.3.4-2+b1
ii  libgps283.22-4
ii  libice6 2:1.0.10-1
ii  libkf5activities5   5.86.0-1
ii  libkf5activitiesstats1  5.86.0-1
ii  libkf5archive5  5.86.0-1
ii  libkf5authcore5 5.86.0-1
ii  libkf5baloo55.86.0-1
ii  libkf5bookmarks55.86.0-1
ii  libkf5calendarevents5   5.86.0-1
ii  libkf5completion5   5.86.0-1
ii  libkf5config-bin5.86.0-1
ii  libkf5configcore5   5.86.0-1
ii  libkf5configgui55.86.0-1
ii  libkf5configwidgets55.86.0-1
ii  libkf5coreaddons5   5.86.0-1
ii  libkf5crash55.86.0-1
ii  libkf5dbusaddons5   5.86.0-1
ii  libkf5declarative5  5.86.0-1
ii  libkf5globalaccel-bin   5.86.0-1
ii  libkf5globalaccel5  5.86.0-1
ii  libkf5guiaddons55.86.0-1
ii  libkf5holidays5 1:5.86.0-1
ii  libkf5i18n5 5.86.0-1
ii  libkf5iconthemes5   5.86.0-1
ii  libkf5idletime5 5.86.0-1
ii  libkf5itemmodels5   5.86.0-1
ii  libkf5jobwidgets5   5.86.0-1
ii  libkf5kcmutils5 5.86.0-1
ii  libkf5kiocore5  5.86.0-1
ii  libkf5kiofilewidgets5   5.86.0-1
ii  libkf5kiogui5   5.86.0-1
ii  libkf5kiowidgets5   5.86.0-1
ii  libkf5networkmanagerqt6 5.86.0-1
ii  libkf5newstuff5 5.86.0-3
ii  libkf5newstuffcore5 5.86.0-3
ii  libkf5notifications55.86.0-1
ii  libkf5notifyconfig5 5.86.0-1
ii  libkf5package5

Bug#999339: plasma-workspace: Maximized windows do not move to primary display when connected

[Shai Berger]

Package: plasma-workspace
Version: 4:5.23.2-1
Severity: normal

Dear Maintainer,

I use a laptop in different locations, with external screens.
Since the external screens are larger, I usually set them as 
the primary display, and use most of my applications there.

Until (and including) 5.21, when I had windows on the external
screen, disconnected it and reconnected an external screen, the
windows would hop back to the external (primary) display.

Since 5.23, I've noted that this doesn't quite work. With the
current version I've noticed further that it's the maximized
windows, specifically, which stay on the laptop screen (which,
when an external is connected, is the secondary display); 
normal-sized windows behave as expected.

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]1.12.20-3
ii  drkonqi 5.23.2-1
ii  frameworkintegration5.86.0-1
ii  gdb-minimal [gdb]   10.1-2
ii  init-system-helpers 1.60
ii  iso-codes   4.7.0-1
ii  kactivitymanagerd   5.23.2-1
ii  kded5   5.86.0-1
ii  kinit   5.86.0-1
ii  kio 5.86.0-1
ii  kpackagetool5   5.86.0-1
ii  kwin-common 4:5.23.2-1
ii  libappstreamqt2 0.14.6-1
ii  libc6   2.32-4
ii  libcolorcorrect54:5.23.2-1
ii  libegl1 1.3.4-2+b1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.11.0+dfsg-1
ii  libgcc-s1   11.2.0-10
ii  libgl1  1.3.4-2+b1
ii  libgps283.22-4
ii  libice6 2:1.0.10-1
ii  libkf5activities5   5.86.0-1
ii  libkf5activitiesstats1  5.86.0-1
ii  libkf5archive5  5.86.0-1
ii  libkf5authcore5 5.86.0-1
ii  libkf5baloo55.86.0-1
ii  libkf5bookmarks55.86.0-1
ii  libkf5calendarevents5   5.86.0-1
ii  libkf5completion5   5.86.0-1
ii  libkf5config-bin5.86.0-1
ii  libkf5configcore5   5.86.0-1
ii  libkf5configgui55.86.0-1
ii  libkf5configwidgets55.86.0-1
ii  libkf5coreaddons5   5.86.0-1
ii  libkf5crash55.86.0-1
ii  libkf5dbusaddons5   5.86.0-1
ii  libkf5declarative5  5.86.0-1
ii  libkf5globalaccel-bin   5.86.0-1
ii  libkf5globalaccel5  5.86.0-1
ii  libkf5guiaddons55.86.0-1
ii  libkf5holidays5 1:5.86.0-1
ii  libkf5i18n5 5.86.0-1
ii  libkf5iconthemes5   5.86.0-1
ii  libkf5idletime5 5.86.0-1
ii  libkf5itemmodels5   5.86.0-1
ii  libkf5jobwidgets5   5.86.0-1
ii  libkf5kcmutils5 5.86.0-1
ii  libkf5kiocore5  5.86.0-1
ii  libkf5kiofilewidgets5   5.86.0-1
ii  libkf5kiogui5   5.86.0-1
ii  libkf5kiowidgets5   5.86.0-1
ii  libkf5networkmanagerqt6 5.86.0-1
ii  libkf5newstuff5 5.86.0-3
ii  libkf5newstuffcore5 5.86.0-3
ii  libkf5notifications55.86.0-1
ii  libkf5notifyconfig5 5.86.0-1
ii  libkf5package5

Re: 5.23 starting move to testing

[Shai Berger]

On Tue, 19 Oct 2021 16:37:14 +0200 (CEST)
Borden  wrote:

> 17 Oct 2021, 07:16 by b...@fineby.me.uk:
> > Taking note of the thread regarding updating to 5.23 in Sid, I'll be
> > holding off for a few days until migration to testing is complete.
> >  
> I'm sure this has been answered before, but this seems to be a
> perennial issue wherever there's a major upgrade. Since Testing is
> supposed to be free of known system-breaking errors, why can't the
> packages be held back until the it's all ready?
> 

This not only has been answered before in general -- it has been
effectively discussed on this very list, only last week.

As a user, you can use "apt upgrade" or "aptitude safe-upgrade". With
either of these, you will not get half-system updates. If the whole
upgrade is ready, you'll get it; if it isn't, you will get suggestions
to either keep older versions of packages with updates, or drop the
not-yet-updated packages. Then, you should choose what to do according
to your taste and the selection of not-yet-updated packages.

Asking for any non-stable flavor to act like stable is making the
packagers' work harder, and IMO as a grateful user who is not involved
in packaging, that is completely uncalled for.

Hope this helps,
Shai.

Re: Proposal for a transaction.on_before_commit

[Shai Berger]

Hi Raphael,

On Tue, 12 Oct 2021 11:28:20 +0200
Raphael Michel  wrote:
> In our case, "not using savepoint rollbacks any more" would be a
> trade-off that we'd happily make (there are enough other problems
> with savepoints to begin with)

You seem to imply that savepoint rollbacks are a very easy feature to
avoid, but I think this is not the case -- in a big part, because some
of them are hidden away from user code.

Any example within a transaction of

try:
with transaction.atomic():
my_model.save()
except SomeException:
handle_error()
 do_something_else_touching_db()

is, explicitly, a savepoint-rollback in the error case, and one you may
need because of side-effects of save() (e.g. in signal handlers). But
even an innocuous

my_model.save()

can induce a savepoint rollback, in case you're using MTI.

You can, maybe, achieve something using database instrumentation --
identify when a "COMMIT" is sent to the database at the SQL level, and
do something before that. But that, also, sounds dangerous.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20211013190547.279f7315.shai%40platonix.com.

Re: Proposal for a transaction.on_before_commit

[Shai Berger]

Just to clarify the use-case:

Why is a before-commit signal preferable to a vanilla Python
context-manager around the code? Or, if it is in the context of
requests, a middleware?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20211010183855.02017a38.shai%40platonix.com.

Re: Do people actually squash migrations?

[Shai Berger]

On Wed, 12 May 2021 09:37:53 -0700 (PDT)
"'Mike Lissner' via Django developers  (Contributions to Django
itself)"  wrote:

> 
> I haven't done the manual approach but I imagine it's something like:
> 
> 1. Check your migrations across all apps with interdependencies for 
> RunPython or RunSQL code.
> 2. If found, make a decision about keeping or deleting that code.
> 3. Delete all migrations across all apps that have interdependencies.
> 4. Run the makemigrations command
> 5. Add your custom RunPython or RunSQL code back
> 

I've tried it. In my experience, it isn't as easy as described either.

When you have circular dependencies between the migration of apps, in
many (most?) cases it means you also have circular dependencies between
the models (FKs etc going in both directions). When that happens,
makemigrations from scratch doesn't do the right thing either --
basically, you need to recreate the interdependencies by having each
app's models created in two steps: One for the "core" of  the models,
so they all exist, and one for the relations, which can only be added
once all the referenced models are present.

The makemigrations command will only add one migration per app, and so
it cannot do this. I haven't tried this in a while, so I don't remember
if the command actually fails, or just produces non-working migrations
which you then need to edit by hand.

This all ties in to a discussion we had on the forum, about the
separation to apps in large projects (linking to my own post there, but
the whole discussion is worth a read if you haven't):
https://forum.djangoproject.com/t/why-do-we-need-apps/827/20

Have fun,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20210813095124.33be923d.shai%40platonix.com.

Re: Transaction APIs do not consult the DB router to choose DB connection

[Shai Berger]

Hi Aditya,

I think the basic issue is that the DB Routers framework is not the
right tool for the task you have in mind. You are trying to redirect
all database activity according to request parameters. The routers are
built for specific uses, and -- by design -- they don't cover all
cases; it's not just transactions. Off the top of my head, it's also raw
sql queries that you'd want to redirect in a similar way. So generally,
Aymeric's suggestion of changing the settings -- although I agree with
your criticism about its sensitivity to any form parallelism -- seems
closer to the right track than the idea of extending the routers.

I _think_ -- haven't looked in the details, so this may be a complete
blunder -- that you can achieve what you want using the Database
Instrumentation framework; it is built to allow you to intervene in the
execution of any SQL operation, at a lower level.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20210602125405.04071a33.shai%40platonix.com.

Re: GSOC Proposal : A new AUTH library.

[Shai Berger]

Hi Nikhil,

I am not calling the shots here, just a member of the community.
However, if you are suggesting this as a work on a 3rd-party library, I
think your suggestion should be either for something completely new, or 
a significant improvement over existing 3rd-party libraries. Libraries
which support registration, OAuth, and 2FA, all exist -- in fact, more
than one for each of the above. I suggest that you research them a
little, and reformulate your suggestion to show how you'd make a
significant contribution beyond what they already offer.

Cheers,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20210415213200.72371c9f.shai%40platonix.com.

Re: Issue with multiple database backends

[Shai Berger]

Hi,

On Wed, 14 Apr 2021 12:10:56 +0100
"'Adam Johnson' via Django developers  (Contributions to Django
itself)"  wrote:

> Hi
> 
> This seems like a genuine bug, Django should not assume that all
> backends have the same max table name length. Please file a ticket.
> 

Right, but it may be a simpler bug than the one you have in mind.

> >
> > Issue i've found is that if i try and call the model
> > `ThisIsAReallyLongModelNameThatIsAlsoVeryOld.objects.using('old').count()`
> > i get an error saying that the table
> > `APP_THISISAREALLYLONGMODEL5300` does not exist, when it should be
> > using `APP_THISISAREALLYLONGMODEL5BD6` instead.

So, you get two different name truncations -- one if the model is
instantiated with Oracle as the default connection (presumably that's
the 5BD6 one), and another if it is instantiated with Postgres and
later used via Oracle. I'd venture as far as guessing that the
difference is that only in one of the cases, the name is turned to
uppercase before shortening; this is how it was in a similar old case,
solved years ago (there, the names of auto-generated through-tables for
ManyToManyField were shortened in a different way than
explicitly-created models, and hilarious breakage ensued when anyone
wanted to add a field to a through table).

I suspect the only fix needed is to make the two ways match
(in favor of the "instantiated on Oracle" way). I doubt it would even
require a deprecation.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20210414143506.627f53ce.shai%40platonix.com.

Bug#985647: telegram-desktop: Actively works against KDE Window rules

[Shai Berger]

Hi Nicholas,

On Sun, 21 Mar 2021 16:38:20 +0300
Nicholas Guriev  wrote:

> If you prefer to see KDE's titlebar on Telegram Desktop, set the
> System window frame checkbox in advanced settings inside the app.
> 

Thanks for the tip. In case anyone else sees this -- initially, when
you set the checkbox, Telegram's own titlebar disappears and the KDE one
does not appear, leaving the window with no titlebar at all. Only after
closing and reopening the window (e.g. by clicking the Telegram tray
icon), the KDE titlebar shows up.

I should note that even with this, the rule
Virtual Desktop: Apply Initially / All Desktops
Does not achieve anything. And it used to. 

Bug#985647: telegram-desktop: Actively works against KDE Window rules

[Shai Berger]

Package: telegram-desktop
Version: 2.6.1+ds-1
Severity: normal

Dear Maintainer,

Not sure how long this has been going on -- I normally have two virtual
desktops, and I like to have telegram-desktop present on both of them.

So I've set up KDE window rules to make it so. And they worked fine.

Recently I've noticed that Telegram was only on one desktop. I looked
for the titlebar in order to pin it, and then realized there's no
titlebar.

So I set a Window Rule to "Apply Initially" that the titlebar be present,
in addition to the initially-applied "Virtual Desktop: All Desktops".

Open opening Telegram, it just ignored these.

I could change them to "Force", I guess...


-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libavcodec58  7:4.3.2-0+deb11u1
ii  libavformat58 7:4.3.2-0+deb11u1
ii  libavutil56   7:4.3.2-0+deb11u1
ii  libc6 2.31-9
ii  libdbusmenu-qt5-2 0.9.3+16.04.20160218-2+b1
ii  libgcc-s1 10.2.1-6
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.7-2
ii  libgtk-3-03.24.24-3
ii  libhunspell-1.7-0 1.7.0-3
ii  libjpeg62-turbo   1:2.0.6-4
ii  libkf5waylandclient5  4:5.78.0-2
ii  liblz4-1  1.9.3-1
ii  liblzma5  5.2.5-1.0
ii  libminizip1   1.1-8+b1
ii  libopenal11:1.19.1-2
ii  libopus0  1.3.1-0.1
ii  libqrcodegencpp1  1.6.0-1
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-5
ii  libqt5dbus5   5.15.2+dfsg-5
ii  libqt5gui55.15.2+dfsg-5
ii  libqt5network55.15.2+dfsg-5
ii  libqt5waylandclient5 [qtwayland-client-abi-5-15-  5.15.2-2
ii  libqt5widgets55.15.2+dfsg-5
ii  librlottie0-1 0.1+dfsg-1
ii  libssl1.1 1.1.1j-1
ii  libstdc++610.2.1-6
ii  libswresample37:4.3.2-0+deb11u1
ii  libswscale5   7:4.3.2-0+deb11u1
ii  libx11-6  2:1.7.0-2
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-record01.14-3
ii  libxcb-screensaver0   1.14-3
ii  libxcb1   1.14-3
ii  libxxhash00.8.0-2
ii  qt5-image-formats-plugins 5.15.2-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans  1.11-1.1

telegram-desktop suggests no packages.

-- no debconf information
[2021.03.14 08:56:06] Launched version: 2006001, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2021.03.14 08:56:06] Executable dir: /usr/bin/, name: telegram-desktop
[2021.03.14 08:56:06] Initial working dir: /home/shai/
[2021.03.14 08:56:06] Working dir: /home/shai/.local/share/TelegramDesktop/
[2021.03.14 08:56:06] Command line: /usr/bin/telegram-desktop --
[2021.03.14 08:56:05] Executable path before check: /usr/bin/telegram-desktop
[2021.03.14 08:56:06] Logs started
[2021.03.14 08:56:06] Launcher filename: telegramdesktop.desktop
[2021.03.14 08:56:06] Connecting local socket to 
/run/user/1000/735a4fdec5600e9bc6df96b79a9689ee-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2021.03.14 08:56:06] This is the only instance of Telegram, starting server 
and app...
[2021.03.14 08:56:06] Moved logging from 
'/home/shai/.local/share/TelegramDesktop/log_start0.txt' to 
'/home/shai/.local/share/TelegramDesktop/log.txt'!
[2021.03.14 08:56:06] Primary screen DPI: 96.1263
[2021.03.14 08:56:07] App Info: reading settings...
[2021.03.14 08:56:07] App Info: reading encrypted settings...
[2021.03.14 08:56:08] Lang Info: Loaded cached, keys: 3079
[2021.03.14 08:56:12] OpenAL Logging Level: (not set)
[2021.03.14 08:56:14] 

Bug#979819: python3-distutils version 3.9.x breaks python3.8-stdlib with no version limit

[Shai Berger]

Thanks again.

Bug#979819: python3-distutils version 3.9.x breaks python3.8-stdlib with no version limit

[Shai Berger]

On Tue, 26 Jan 2021 12:46:39 +0100
Matthias Klose  wrote:

> On 1/11/21 5:34 PM, Shai Berger wrote:
> > Package: python3-distutils
> > Version: 3.9.1-2
> > Severity: normal
> > 
> > 
> > While this packages lists, among other things,
> > Breaks: ..., libpython3.8-stdlib (< 3.8.0~b2-5)
> > 
> > In fact, [it breaks all versions of] libpython3.8-stdlib.
> > 
> > I see two, non-exclusionary paths to solve this:
> > - Just mark the breakage correctly
> 
> Closing this issue as won't fix.

Please just fix the Breaks info. Mark libpython3.8-stdlib as
uncoditionally broken by current versions of python3-distutils.

Further,

> 
> The python3-tk, python3-gdbm and python3-distutils packages are real
> packages, not virtual packages, which support both the old 3.8 and
> the new 3.9 Python versions during the time Debian is doing the
> transition to a new Python3 version. After the transition we remove
> 3.8, so we only build those using 3.9.
> 

In my suggestion:

> > - Provide real, rather than virtual, python3.x-distutils packages  

I wasn't referring to python3-distutils, but to python3.8-distutils or
python3.9-distutils, which are virtual (provided by python3-distutils).
I fully understand and support a decision not to make them real
packages; I appreciate that this would be more work for busy volunteer
maintainers, for a less-than-mainstream use-case.

Thanks for all your efforts,
Shai.

Bug#979819: python3-distutils version 3.9.x breaks python3.8-stdlib with no version limit

[Shai Berger]

Package: python3-distutils
Version: 3.9.1-2
Severity: normal

Dear Maintainer,

For years I've known that installing a newer version of Python
on my Debian system breaks existing virtualenvs set up for the
old Python version. Today I investigated a little and found out
why:

While this packages lists, among other things,
Breaks: ..., libpython3.8-stdlib (< 3.8.0~b2-5)

In fact, installing it at this version removes most files from
/usr/lib/python3.8/distutils/ and thereby breaks any use of 
distutils or setuptools under python 3.8, and that most certainly
includes libpython3.8-stdlib=3.8.7-1 which I currently have
installed, as well as, I believe, any other version of libpython3.8-stdlib.

I see two, non-exclusionary paths to solve this:
- Just mark the breakage correctly
- Provide real, rather than virtual, python3.x-distutils packages

Thanks,
Shai.

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-distutils depends on:
ii  python3  3.9.1-1
ii  python3-lib2to3  3.9.1-2

python3-distutils recommends no packages.

python3-distutils suggests no packages.

-- no debconf information

Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow

[Shai Berger]

Package: cups-filters-core-drivers
Version: 1.28.6-1
Severity: normal

Dear Maintainer,

I've seen some misbehavior from my printer, and tried to remove and add it
back again. This failed, with the symptoms described in
https://unix.stackexchange.com/questions/276736/cups-adding-printer-fails-with-unable-to-get-list-of-printer-drivers-success
that is, no matter what interface I use -- KDE, Gnome or the web
via localhost:631 -- I get the same error when trying to find
drivers for the printer:

Unable to get list of printer drivers:
Success

Following the advice on that page, I tried to see if removal of
one of the files in /usr/lib/cups/driver can help me get faster
results, and I found that the guilty script was
/usr/lib/cups/driver/driverless

I then tried to run this script in isolation, and got:

$ time /usr/lib/cups/driver/disabl/driverless list
DEBUG: Started ippfind (PID 19070)
Failed to get info about driverless support.
"driverless:ipp://HP%20OfficeJet%206950%20%5B00A23E%5D%20(USB)._ipp._tcp.local/"
 en "HP" "HP OfficeJet 6950, driverless - cannot check driverless status, 
cups-filters 1.28.6" "MFG:HP;MDL:OfficeJet 
6950;CMD:PCLM,PCL,PWGRaster,AppleRaster,JPEG,URF,PWG;"
"driverless-fax:ipp://HP%20OfficeJet%206950%20%5B00A23E%5D%20(USB)._ipp._tcp.local/"
 en "HP" "HP OfficeJet 6950, Fax, driverless - cannot check driverless status, 
cups-filters 1.28.6" "MFG:HP;MDL:OfficeJet 
6950;CMD:PCLM,PCL,PWGRaster,AppleRaster,JPEG,URF,PWG;"
DEBUG: ippfind (PID 19070) exited with no errors.

real3m1.817s
user0m0.005s
sys 0m0.015s

Noticing my specific printer named in the output -- could it be
that the script tries to communicate with it, but fails to do it
in a robust way?

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups-filters-core-drivers depends on:
ii  bc 1.07.1-2+b2
ii  cups-ipp-utils 2.3.3op1-3
ii  libc6  2.31-6
ii  libcups2   2.3.3op1-3
ii  libcupsfilters11.28.6-1
ii  libgcc-s1  10.2.1-3
ii  liblcms2-2 2.9-4+b1
ii  libpoppler-cpp0v5  20.09.0-3
ii  libqpdf28  10.0.4-1
ii  libstdc++6 10.2.1-3
ii  poppler-utils  20.09.0-3
ii  zlib1g 1:1.2.11.dfsg-2

cups-filters-core-drivers recommends no packages.

cups-filters-core-drivers suggests no packages.

-- no debconf information

Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow

[Shai Berger]

Package: cups-filters-core-drivers
Version: 1.28.6-1
Severity: normal

Dear Maintainer,

I've seen some misbehavior from my printer, and tried to remove and add it
back again. This failed, with the symptoms described in
https://unix.stackexchange.com/questions/276736/cups-adding-printer-fails-with-unable-to-get-list-of-printer-drivers-success
that is, no matter what interface I use -- KDE, Gnome or the web
via localhost:631 -- I get the same error when trying to find
drivers for the printer:

Unable to get list of printer drivers:
Success

Following the advice on that page, I tried to see if removal of
one of the files in /usr/lib/cups/driver can help me get faster
results, and I found that the guilty script was
/usr/lib/cups/driver/driverless

I then tried to run this script in isolation, and got:

$ time /usr/lib/cups/driver/disabl/driverless list
DEBUG: Started ippfind (PID 19070)
Failed to get info about driverless support.
"driverless:ipp://HP%20OfficeJet%206950%20%5B00A23E%5D%20(USB)._ipp._tcp.local/"
 en "HP" "HP OfficeJet 6950, driverless - cannot check driverless status, 
cups-filters 1.28.6" "MFG:HP;MDL:OfficeJet 
6950;CMD:PCLM,PCL,PWGRaster,AppleRaster,JPEG,URF,PWG;"
"driverless-fax:ipp://HP%20OfficeJet%206950%20%5B00A23E%5D%20(USB)._ipp._tcp.local/"
 en "HP" "HP OfficeJet 6950, Fax, driverless - cannot check driverless status, 
cups-filters 1.28.6" "MFG:HP;MDL:OfficeJet 
6950;CMD:PCLM,PCL,PWGRaster,AppleRaster,JPEG,URF,PWG;"
DEBUG: ippfind (PID 19070) exited with no errors.

real3m1.817s
user0m0.005s
sys 0m0.015s

Noticing my specific printer named in the output -- could it be
that the script tries to communicate with it, but fails to do it
in a robust way?

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups-filters-core-drivers depends on:
ii  bc 1.07.1-2+b2
ii  cups-ipp-utils 2.3.3op1-3
ii  libc6  2.31-6
ii  libcups2   2.3.3op1-3
ii  libcupsfilters11.28.6-1
ii  libgcc-s1  10.2.1-3
ii  liblcms2-2 2.9-4+b1
ii  libpoppler-cpp0v5  20.09.0-3
ii  libqpdf28  10.0.4-1
ii  libstdc++6 10.2.1-3
ii  poppler-utils  20.09.0-3
ii  zlib1g 1:1.2.11.dfsg-2

cups-filters-core-drivers recommends no packages.

cups-filters-core-drivers suggests no packages.

-- no debconf information

[Python-ideas] Re: Conditional function/method/dict arguments assignments

[Shai Berger]

I've been toying with a similar idea myself. I've felt the pain
described by Brian, and I share Marco's dislike for the suggested
syntax. Moreover, I dislike the idea that the conditional should
somehow refer to the function's default arguments.

My half-baked idea is along the lines of

f(val1, val2, if cond3: val3, if cond4: arg4=val4)

with the sense that if a condition is not met, the argument is just not
passed; this would be equivalent to

f(
val1, val2,
*[_ for _ in [val3] if cond3],
**{'arg4': _ for _ in [val4] if cond4}
)

As presented, this would work for list and set literals as well, but
the syntax is not good for dict literals; "{if cond: key: value}" feels
completely wrong. Alternative "{key if cond: value}" looks palatable at
first glance, but doesn't feel quite "in line" with the rest of the
proposal, and for my taste, looks too similar to the already valid
"{key1 if cond else key2: value}".

That last similarity is also why I don't like the syntax

f(arg1, arg2, arg3 if cond3, arg4=cond4 if cond4)

I've been thinking about alternatives such as

f(arg1, if (cond2) arg2)
f(arg1, (if cond2) arg2)

or just marking the if as a "special if", e.g.

f(arg1, arg2 if* cond2)

But I'm not really pleased with any of them.

Have fun,
Shai.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZRDK3Z55MMTVZOLMYSKC32WE7DTZYNFS/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: Extending the checks for related-name clashes

[Shai Berger]

On Sun, 6 Sep 2020 12:01:34 +0100
Adam Johnson  wrote:

> I think it would be acceptable to make related name clashes a check
> Error. I'm guessing you couldn't find any justification for why the
> check doesn't currently do this?
> 

I didn't find any, though I didn't look too hard.

On the other hand, I found that the behavior changes depending on the
target model being a proxy model (or rather, on the model defining the
property being a proxy model).

That is, with

class A(models.Model):
@property
def related(self):
return 15


class B(models.Model):
a = models.ForeignKey(A, related_name='related',
  on_delete=models.CASCADE)


class C(A):
class Meta:
proxy = True

@property
def pro_related(self):
return 17


class D(models.Model):
c = models.ForeignKey(C, related_name='pro_related',
  on_delete=models.CASCADE)


For instances a and c of A and C respectively,
a.related is a RelatedManager
c.pro_related is 17

This happens because reverse-accessors are promoted to the concrete
model -- the accessor attribute is set on A, which means it overrides
whatever was defined on A, but can be overridden by A's subclasses.

I believe the technical term of this is "a mess".

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200906155425.17c1d7f8.shai%40platonix.com.

Extending the checks for related-name clashes

[Shai Berger]

Hi all,

When you define a related field on a model -- a ForeignKey etc -- it
usually adds its related-name as a backwards-accessor on the related
model. These related names are checked for clashes against other fields
and other related-names. But they are not checked for clashes against
other attributes of the remote model, like methods and properties.

A clash with another field (or accessor) is considered an error. I
think a clash with a property should be at least a warning. Currently
it is accepted silently (and AFAICT, the related-name takes
precedence, that is, the property is effectively deleted).

Does anybody think this is the desired behavior?

Thanks,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200906133146.4449641c.shai%40platonix.com.

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

[Shai Berger]

Hi Uri and all,

On Thu, 3 Sep 2020 08:37:42 +0100
Adam Johnson  wrote:

> I agree with Florian.
> 

Me too.

> The occasional forced logout is probably fine. If you care about this
> enough Uri, you could write a blog post documenting your patch and
> how to use it when upgrading Django.
> 

But:

> On Thu, 3 Sep 2020 at 08:29, Florian Apolloner 
> wrote:
> > On Thursday, September 3, 2020 at 4:56:13 AM UTC+2 Uri wrote:
> >>
> >> I found out that this can be avoided by changing *def
> >> must_update*, for example if you change it to something like:
> >>
> >> def must_update(self, encoded):
> >> # Update the stored password only if the iterations diff is at least 
> >> 250,000.
> >> algorithm, iterations, salt, hash = encoded.split('$', 3)
> >> iterations_diff = abs(self.iterations - int(iterations))
> >> return ((int(iterations) != self.iterations) and (iterations_diff >= 
> >> 25))
> >>
> >> Or even simply:
> >>
> >> def must_update(self, encoded):
> >> return False
> >>

Please be aware that this is a security issue. The passwords are
encrypted as protection for the case that they fall into the hands of
an attacker, but for this protection to be effective, it must stay hard
and costly to brute-force them. The number of iterations is enlarged in
order to keep this cost up with the improvements of available hardware.
If you intend to keep a user's password un-updated for many years, it's
almost as bad as keeping it in plaintext -- in 10-15 years, we'd expect
the number of iterations in current Django to be grossly insufficient.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200903112219.6be68094.shai%40platonix.com.

Re: The cotent types framework unreasonably limits model name length.

[Shai Berger]

On Tue, 11 Aug 2020 10:51:58 -0700 (PDT)
charettes  wrote:

> > Suffix-hashing long names like Simon suggests may not be   
> backwards-compatible. 
> 
> Could you elaborate on that?
> 
> Assuming model names > 100 characters never worked wouldn't only 
> suffix-hashing model names > 100 characters be backward compatible?
> 
You're right, I was thinking about suffix-hashing table names longer
than 63 on Postgres, the way it has always been done on Oracle.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200814174823.0fd8d371.shai%40platonix.com.

Re: Problem switching users from plasma under lightdm

[Shai Berger]

Hi,

On Wed, 12 Aug 2020 13:47:16 -0300
Lisandro Damián Nicanor Pérez Meyer  wrote:

> I am currently using
> 
> qdbus --system org.freedesktop.DisplayManager 
> /org/freedesktop/DisplayManager/Seat0 
> org.freedesktop.DisplayManager.Seat.SwitchToGreeter
> 
> to open new users' sessions.

I can confirm that this works.

Thanks,
Shai.

Re: The cotent types framework unreasonably limits model name length.

[Shai Berger]

AFAIK Postgres, in these cases, simply truncates the name. This means:

1) Generating models with names longer than 63 characters on postgres
is fragile. You may find yourself with more than one model trying to
use the same table name.

2) Suffix-hashing long names like Simon suggests may not be
backwards-compatible.

My 2 cents,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200811190519.482b0799.shai%40platonix.com.

Problem switching users from plasma under lightdm

[Shai Berger]

Hello,

I've been using lightdm as the display manager on my Debian Testing for
a very long time, and have been quite pleased with it. But lately -- not
sure since when, I think in the last two weeks -- something broke in
the communication between Plasma and lightdm. The screen locker doesn't
show "switch user" anymore, and neither does the "Leave" part of the
launcher menu. I have the Lock/Logout plasmoid in the systray, which
always shows a "switch user" icon, and that works, but is currently the
only graphical way to switch user.

I've tried running an XFCE session and its logout window had a working
"switch user" button, so I'm guessing Plasma is the prime suspect.

Has anyone else encountered anything similar?

Thanks,
Shai.

Re: queryset.values() / GROUP BY

[Shai Berger]

Hi René,

On Tue, 21 Jul 2020 18:46:12 +0200
René Fleschenberg  wrote:

> https://github.com/kako-nawao/django-group-by
> 

It doesn't actually aggregate, so the name "group-by" seems
unwarranted. What it does, as the README explains, is replace "values"
by something which does two things:

- Sets the seclected fields as attributes on the object returned,
  rather than as dict values
- Where the selected field is a FK, follows the relationship to get the
  object

> Is there a deeper reason why this functionality is not available in 
> Django core?

If I'm not mistaken, only() provides this functionality, with the
difference that if you then try to access an unselected attribute on the
object, with only() it is fetched, while with this "group_by()" you get
an AttributeError.

(django-group-by has other limitations -- e.g. it is designed to
handle "rel__field" but not "rel1__rel2__field")

Did I miss anything important?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200721215215.5c325bd8.shai%40platonix.com.

Re: f-strings again.

[Shai Berger]

Hi Dave and all,

On Tue, 21 Jul 2020 13:56:53 +0100
Dave Vernon  wrote:

> More generally:
> 
> I understand the value of *not* doing a bulk change in a PR, but I was
> wondering if it's OK to do a PR based purely on improved performance
> for a specific element? (I don't have one in mind, the question is
> purely 'in principle')

We are still in discussions here, but if I understand the forming
concensus correctly, it will be ok to replace older-style formatting
with f-strings if you're making changes in the code in question, and
performance-improving changes are, in principal, welcome.

However, whether the performance improvement afforded by such a change
would, on its own, justify the change -- will need to be judged on a
case-by-case basis, and my guess is that justifiable cases will be few
and far between. I believe that in most cases, string formatting is not
a major performance bottleneck.

My non-shot-calling 2-cents' worth,

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200721165300.70bd9631.shai%40platonix.com.

Re: f-strings again.

[Shai Berger]

On Tue, 21 Jul 2020 01:28:31 -0700 (PDT)
Carlton Gibson  wrote:
> 
> Certainly 99% of cases can be handled as cleanly (or more so, because
> I guess we fell `format()` is a little verbose) with %-formatting or
> an f-string. 
> But if we say format() is not allowed, don't we then guarantee we hit
> the one case in X where "Actually, this version with format() is much
> cleaner"? 
> 
FWIW, it seems to me one case where this happens is when you want to
use one argument multiple times, without naming:

'<{0} id="{1}"> {2} '.format(tag, id, content)

Arguably, this specific example would look better with named references,
but, IMO, not with % formatting:

'<%(tag)s id="%(id)s"> %(content)s ' % dict(
tag=tag,id=id, content=content
)

and as noted, f-strings have their limitations.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200721140822.47376bd8.shai%40platonix.com.

[Python-ideas] Allowing -b (BytesWarning) to be activated in other ways

[Shai Berger]

Hi Pythonistas,

The -b flag, which turns on checks which emit BytesWarnings on
operations mixing bytes and str objects, is very useful.

However, the only way to set this flag is via the Python invocation.
This limits its usability in contexts where the user's control of the
Python invocation is limited, e.g when using Python embedded in another
executable (such as uwsgi). There appears to be no function which can
set the flag, and no environment variable which controls it.

Up to Python 3.7, the extension module provided by the bytes-warning
package[1] works around this (it exposes a function which allows
setting the flag from within Python). But with 3.8 (and I suspect,
because of PEP-587[2] related changes), this fails silently and the sys
flag bytes_warning remains unaffected.

Can we have a non-invocation way to control this flag?

Thanks,
Shai.

[1] https://pypi.org/project/bytes-warning/
[2] https://www.python.org/dev/peps/pep-0587/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FV37A5SIQGY4VJ6ESUNAMVXHUXUHUVGO/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: Welcome email

[Shai Berger]

Sorry for the bike-shedding, but I think the text should drop the
"using Django" language. The people who come here with these questions
clearly think of themselves as developers, not users.

IMO It should go something like,

Welcome to django-developers, the mailing list for discussion
of the development of Django itself.

This mailing list is not for support developing apps and
websites with Django. For support, please follow the "Getting
Help" page: https://docs.djangoproject.com/en/3.0/faq/help/ .
This page will direct you to the django-users mailing list or
other resources, so you can find people who are willing to
support you, and to ask your question in a way that makes it
easy for them to answer.

Thanks,

The Django Community



On Wed, 8 Jul 2020 11:50:16 +0100
Adam Johnson  wrote:

> Okay I'm in favour. That said, there's already a banner on the groups
> page:
> 
> This group is for the discussion of the development of Django itself.
> If
> > you want to ask questions about using Django, please post on
> > django-users.
> >
> 
> Suggested wording, adapted from my templated reply:
> 
> Welcome to django-developers, the mailing list for discussion of the
> > development of Django itself.
> >
> > This mailing list is not for support using Django. For support,
> > please follow the "Getting Help" page:
> > https://docs.djangoproject.com/en/3.0/faq/help/ . This page will
> > direct you to the django-users mailing list or other resources, so
> > you can find people who are willing to support you, and to ask your
> > question in a way that makes it easy for them to answer.
> >
> > Thanks,
> >
> > The Django Community
> >
> 
> Who has access to add this? Someone from the DSF board, the ops team,
> or the fellows?
> 
> On Mon, 6 Jul 2020 at 00:02, Ahmad A. Hussein
>  wrote:
> 
> > +1 on this. Here's the relevant feature
> >  I found.
> >
> >
> > Ahmad
> >
> > On Sun, Jul 5, 2020 at 7:58 PM Adam Johnson  wrote:
> >
> >> I can't find a google groups feature that would allow this. Do you
> >> know of one? It might otherwise require a custom bot.
> >>
> >> On Sun, 5 Jul 2020 at 16:14, Arvind Nedumaran
> >>  wrote:
> >>
> >>> Oh I understand. I meant we could include the distinction in the
> >>> welcome email and possibly a link to the other list.
> >>>
> >>> That may reduce the number of people who may be looking for help
> >>> but end up here mistakenly?
> >>>
> >>> Get Outlook for Android 
> >>>
> >>> --
> >>> *From:* django-developers@googlegroups.com <
> >>> django-developers@googlegroups.com> on behalf of אורי
> >>>  *Sent:* Sunday, July 5, 2020 8:39:22 PM
> >>> *To:* Django developers (Contributions to Django itself) <
> >>> django-developers@googlegroups.com>
> >>> *Subject:* Re: Welcome email
> >>>
> >>> I think because this list is called Django developers and what we
> >>> call "Django users" are also developers who use Django. But they
> >>> are developers.
> >>>
> >>> אורי
> >>> u...@speedy.net
> >>>
> >>>
> >>> On Sun, Jul 5, 2020 at 5:59 PM Arvind Nedumaran
> >>>  wrote:
> >>>
> >>> Hey everyone,
> >>>
> >>> I notice that people who try to find support on using Django
> >>> mistakenly post in this list and sometime usually has to write an
> >>> explanation about how this is the wrong place.
> >>>
> >>> Could we possibly as a welcome email whenever someone joins the
> >>> group?
> >>>
> >>> Just a suggestion.
> >>>
> >>> Best,
> >>> Arvind
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Django developers (Contributions to Django itself)" group.
> >>> To unsubscribe from this group and stop receiving emails from it,
> >>> send an email to django-developers+unsubscr...@googlegroups.com.
> >>> To view this discussion on the web visit
> >>> https://groups.google.com/d/msgid/django-developers/BYAPR14MB29181EBF50C845052F69E5E1A3680%40BYAPR14MB2918.namprd14.prod.outlook.com
> >>> 
> >>> .
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Django developers (Contributions to Django itself)" group.
> >>> To unsubscribe from this group and stop receiving emails from it,
> >>> send an email to django-developers+unsubscr...@googlegroups.com.
> >>> To view this discussion on the web visit
> >>> https://groups.google.com/d/msgid/django-developers/CABD5YeH0WySFuBnzyXENnMt-5bN5hawS4HYoNUVeGFG8TLG0qw%40mail.gmail.com
> >>> 
> >>> .
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> 

Re: Making startproject's settings more 12-factor-y

[Shai Berger]

Hello,

On Fri, 26 Jun 2020 00:46:02 -0700 (PDT)
Florian Apolloner  wrote:

> On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com
> wrote:
> 
> > Personally, I think that *at minimum* providing Django-builtin "get
> > from env"  helpers would be great; beyond that, I'd love to have
> > them be included around `DEBUG` and `SECRET_KEY` with the current
> > values as defaults, so they're optional. Once we see how this gets
> > used, we can see about passing it a file instead of `os.environ`,
> > or borrowing other ideas from any of the various supporting
> > projects that have been suggested. 
> 
> I am all for minimal variants, but I do not think this would could
> it. [...]

> And there are plenty more things to consider; for instance I do not
> agree that it makes sense to have "SECRET_KEY" default to a value
> when missing in the env. It is way to easy to type "SECRT_KEY" and
> never realize that. So if "SECRET_KEY" is taken from the environment
> it should fail loudly if it is not present.
> 
> [...] please note that the bar to add
> this to Django is very high since it can (at least for things like
> django-environ) easily live outside of Django with no realy downside.
> 

Before this, when explaining the motivation for this, Kit said:

> My hope is to make the smallest possible change to just start us
> moving towards more clearly flagging, especially for newer devs,
> "these are things that will need additional configuration in order to
> move from 'works on my machine' to 'deployed'."

We already have a tool designed for this: the "check --deploy"
management command[1]. We can improve it a little by helping it detect
that the SECRET_KEY is carelessly kept hard-coded from the initial
project creation, e.g. by including somewhere a marker class:

class HardCoded(str): pass

and then in the default template

SECRET_KEY = HardCoded('generated_value_like_today')

Then the check could easily detect it and tell the user they need to
change it.

I think that a settings-only solution cannot be appropriate here, for
the reasons Florian noted -- Kit is basically asking the default
template to educate the user about deployment, but there is a tension
between this and having things Just Work, which is important for
beginners, and Just Work Securely (which is why the default SECRET_KEY
needs to be a generated, random secret). To resolve this tension, we
need a tool which is aware of context -- a tool which differentiates
between the beginner on their laptop, and the novice doing their first
deployment. The settings, in general, cannot make this distinction; a
management command can.

We have a whole bunch of documents about deployment[2] - maybe a little
too much, and this probably encourages shorter "just do this" type
deployment tutorials. Maybe we should make the checklist[3] more
prominent, maybe we should make "check --deploy" even more prominent.
But I don't think a single settings file can be all things for all
users.

My 2 cents,
Shai.


[1] 
https://docs.djangoproject.com/en/3.0/ref/django-admin/#cmdoption-check-deploy
[2] https://docs.djangoproject.com/en/3.0/howto/deployment/
[3] https://docs.djangoproject.com/en/3.0/howto/deployment/checklist/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200626131942.553c2b54.shai%40platonix.com.

Re: Implement QuerySet.__contains__?

[Shai Berger]

On Fri, 5 Jun 2020 13:58:47 +0200
Johan Schiff  wrote:

> I still think the wrong call was made here [...]
> *(Assuming queryset should be evaluated is probably correct in
> most cases, but sometimes adds a big performance hit when the code
> goes into production and the dataset grows - code that looks
> reasonable and works like a charm in dev will cause trouble in
> production. Assuming the opposite would have added a tiny performance
> hit in most cases, but avoided the big one.)*
> 

FWIW, when that call was made, the default behavior was to fetch only
100 records at a time, so the performance hit for the cases you
describe was quite limited. This was changed later, as Tim mentioned in
this thread:

> Django 1.6 when chunked reads were removed from QuerySet iteration: 
> 
> https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200605224258.783815ec.shai%40platonix.com.

Re: Implement QuerySet.__contains__?

[Shai Berger]

On Tue, 2 Jun 2020 20:57:54 +0200
Aymeric Augustin  wrote:

> 
> We're talking about a trade-off between preserving optimisations in
> existing code bases and expertise of advanced users versus doing the
> right thing by default for less experienced users.

I disagree. 

The suggestion is to make 

if obj in qs:
# do things which don't fetch qs

more performant, at the expense of

if obj in qs:
# do things that fetch qs

As well as

for obj in container:
if obj in qs:
# whatever

So, it is not a net optimization even in terms of its own.

Also, changing the performance characteristics of thousands, if not
millions of existing lines of code, and making a decade of online
comments and advice wrong (not just obsolete "there's better ways now"
but wrong "this points you away from truth and good"), is IMO a
non-starter.

Strong -1 on Aymeric's option 1. Strong +1 on adding ".contains()".

My 2 cents,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200605090349.559f3872.shai%40platonix.com.

Re: Removing url() ?

[Shai Berger]

On Tue, 5 May 2020 14:18:09 -0700
James Bennett  wrote:

> On Tue, May 5, 2020 at 2:04 PM Shai Berger  wrote:
> > Why? Why is 10 years ok where 7 are not? James' points on this are
> > spot on.
> >
> > Be that as it may, I can see sense in the request for a longer
> > warned-deprecation period, which the current path does not offer. I
> > would be ok with introducing now the RemovedInDjango41 or even
> > RemovedInDjango50 warning, and waiting a couple more releases (for
> > comparison, Python usually deprecates and removes in two versions,
> > not three like Django).  
> 
> Not to be contrarian, but I can come right back here with "why is
> removal in 5.0 OK but removal in 4.0 isn't".
> 

First, to clarify my position: I think removal in 4.0 is fine. I also
think removal later is fine, as long as we don't allow it to be delayed
forever.

> Under the current removed-in-4.0 plan, people will get *six* Django
> feature releases from the time re_path was introduced to the time
> url() goes away. Any argument for extending it to nine is also an
> argument for extending it to twelve, fifteen, eighteen, and so on.

The thing I see sense in extending is not the number of releases since
re_path was introduced, but the number of releases where the use of
url() generates warnings (the number of releases since re_path's
introduction will grow too, of course, but that I consider a tolerable
side-effect, no more).

The reason for this is that people are still writing new code which
uses url() -- because they get very strong hints to do so from existing
code, and virtually no hints to avoid doing so.

My argument is, basically, that because the deprecation so far was in
documentation only, the delay in introducing it was partly "wasted",
and because of that, the argument that justified not deprecating url()
at the moment that re_path() was introduced, still (partly) holds.

But I won't cry too many tears if this position is rejected.

My 2 cents,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200506015037.44a7bf10.shai%40platonix.com.

Re: Removing url() ?

[Shai Berger]

I generally sympathize with Collin's position here, but I don't think
deprecation-without-intention-to-remove is a viable option. I think this
discussion is analogous to the Python discussion about the removal of
the ABCs from collections -- they were moved to collections.abc
in 3.3, but a shim was kept; it was slated to be dropped in 3.9 (up to
3.8 there was reason to keep the shim for compatibility with 2.7), but
the intention to execute was met with protests a lot like Collin's. The
deprecation warnings have been loud since 3.7, but the uproar, AFAICT,
only came with the code change in master towards 3.9. 

The decision there was to delay the removal to 3.10. 

On Tue, 5 May 2020 13:05:52 -0700 (PDT)
Collin Anderson  wrote:

> If it were 10 years from the proposal being accepted (2017 to 2027),
> I think that would be fine for removal then.

Why? Why is 10 years ok where 7 are not? James' points on this are spot
on.

Be that as it may, I can see sense in the request for a longer
warned-deprecation period, which the current path does not offer. I
would be ok with introducing now the RemovedInDjango41 or even
RemovedInDjango50 warning, and waiting a couple more releases (for
comparison, Python usually deprecates and removes in two versions, not
three like Django).

My 2 cents,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200506000441.1e6adc8d.shai%40platonix.com.

Re: GSoC Mentors

[Shai Berger]

Hi Carlton and all,

I'm not much of a manager, but will be happy to help as much as I can
with technical input.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200328151859.0024923d.shai%40platonix.com.

Re: Request to reconsider #30311 -- allow overriding site-wide admin actions

[Shai Berger]

On Wed, 18 Mar 2020 10:34:30 -0700 (PDT)
charettes  wrote:

> I think deleted_selected is *special* since it's the only default
> action provided.
> 

I agree, but...

> I guess we could document that a method name string reference should
> be passed to AdminSite.add_action if it's meant to be overridden.
> 

For that to be viable, the project need to have an admin class which
all others inherit, and that's not a trivial requirement -- unless we
can pass a method-name-string-reference *and* a default function.

My 2 cents,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200318213239.43bc6885.shai%40platonix.com.

Re: Request to reconsider #30311 -- allow overriding site-wide admin actions

[Shai Berger]

(sorry about the previous empty mail, UI glitch)

On Wed, 18 Mar 2020 09:29:17 -0700 (PDT)
charettes  wrote:

> Just to make the above clear, here's what I had in mind
> 
> https://gist.github.com/charettes/a0cb94242ac9c198625b23f4f55fab45
> 

Yes, that would do what I want and seems better than my suggestion.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200318185306.22c9a798.shai%40platonix.com.

Re: Request to reconsider #30311 -- allow overriding site-wide admin actions

[Shai Berger]

On Wed, 18 Mar 2020 09:29:17 -0700 (PDT)
charettes  wrote:

> Just to make the above clear, here's what I had in mind
> 
> https://gist.github.com/charettes/a0cb94242ac9c198625b23f4f55fab45
> 
> Le mercredi 18 mars 2020 12:20:54 UTC-4, charettes a écrit :
> >
> > Given the common need to override delete_selected I wonder if we
> > could define it as ModelAdmin method and use a .actions string
> > reference to it in the AdminSite instead[0].
> >
> > That would allow admin classes to simply override the
> > delete_selected method on their admin classes without having to
> > resort to redefining .actions which seems to trigger the issue here.
> >
> > Cheers,
> > Simon
> >
> > [0] 
> > https://github.com/django/django/blob/d4df5e1b0b1c643fe0fc521add0236764ec8e92a/django/contrib/admin/sites.py#L66
> >
> > Le mercredi 18 mars 2020 12:01:15 UTC-4, Shai Berger a écrit :  
> >>
> >> Hello fellow Djangonauts, 
> >>
> >> While working on upgrading a project to 2.2, I ran into multiple 
> >> instances of 
> >>
> >> : (admin.E130) __name__ attributes of
> >> actions defined in  must be unique. 
> >>
> >> caused by the fact that, out of a large set of Admin classes,
> >> about a dozen have defined their own version of the
> >> 'delete_selected' action. 
> >>
> >> When looking into it, I came across ticket #30311[1] which
> >> basically complained about the very same thing; but was closed as
> >> invalid, under the claim that the user is in full control of both
> >> the site-wide actions and the admin-specific actions, and so can
> >> do whatever they like. 
> >>
> >> While that claim is certainly correct, I would like to suggest
> >> that it creates an odd situation for the app which wants to define
> >> its own version of delete_selected (or any other
> >> site-wide-availabe action) for one of its models. In fact, it now
> >> cannot be done at the app level -- it requires that the default
> >> action be disabled at the site level. 
> >>
> >> If (as is probably the case with delete_selected) it is still
> >> desired as a site-wide-available action, then the default needs to
> >> be replaced with a custom action which first looks for an override
> >> on the specific admin, and if not found invokes the original. And
> >> that seems to me like a hoop we shouldn't force people to jump
> >> through. 
> >>
> >> Opinions? 
> >>
> >> [1] https://code.djangoproject.com/ticket/30311 
> >>  
> >  
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200318185115.680d4e22.shai%40platonix.com.

Re: Request to reconsider #30311 -- allow overriding site-wide admin actions

[Shai Berger]

Hi Carlton,

On Wed, 18 Mar 2020 17:11:49 +0100
Carlton Gibson  wrote:

> I triaged that, and was involved in the change in #29917 that led to
> your issue.
> 
> https://code.djangoproject.com/ticket/29917
> https://groups.google.com/d/topic/django-developers/-OWoYL_zryM/discussion
> 

Yes, I've seen these too.

> 
> I’ll have another review of it, but is there an **exact** change you
> have in mind that satisfies all the competing Wants? (It was all quite
> interconnected IIRC)
> 
I think they're not all that interconnected. The change in #29917 was
about duplication caused by inheritance; #30311 is about duplication
between an admin's specific actions and the site-wide actions. I fully
endorse and support the inheritance change.

The change I'd like to see is a rewrite of _get_base_actions(), so that
instead of blindly adding the site-wide actions, it only adds those not
defined by the specific admin. There's lines there[1] that say:

for (name, func) in self.admin_site.actions:
description = getattr(func, 'short_description', name.replace('_', 
' '))
actions.append((func, name, description))

[1] 
https://github.com/django/django/blob/master/django/contrib/admin/options.py#L855

and I'd like to see added something along the lines of:

for (name, func) in self.admin_site.actions:
if name in (self.actions or []): 
continue   
description = getattr(func, 'short_description', name.replace('_', 
' '))
actions.append((func, name, description))

(that's too simplistic, actions can given by more than name, but
that's the general idea)

This way, if an admin wants to override, they just do.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200318184443.2e47f79c.shai%40platonix.com.

[Python-ideas] Re: `raise as` to raise with current exception as cause

[Shai Berger]

On Fri, 7 Feb 2020 20:08:35 -0800
Andrew Barnert  wrote:

> > On Feb 7, 2020, at 16:11, Steven D'Aprano 
> > wrote:
> > 
> > Shai Berger wants to set it implicily, based on where the raise is.
> > If it is "directly" under the except line, implicitly set the cause.
> > 
> 
> I interpreted “directly under” as meaning “directly lexically
> contained by”, not “on the next physical line”. And even if that
> isn’t what Shai meant, it’s what I meant. :)
> 

Just for the record, that *is* what I meant.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5FQU43FM5A54RFXG6HE44QAJ6BLITTRP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: `raise as` to raise with current exception as cause

[Shai Berger]

Hi,

In the Django thread, I suggested that an implicit "raise from" should
be the behavior whenever an exception is raised directly in
exception-handling code (that is, within an except: or finally:
clause). Ram claimed there were problems with that, but gave no
details; I would be happy to know what these problems are.

The main problem I see with "raise from None" is that it removes the
inner part of the traceback. It expresses the idea that everything that
happened in lower levels is not really interesting -- you should have
all the information for handling or debugging the problem by
considering the flow from here up. I think in most cases where you'd
want to change the type and/or value of an excpetion, this is
unrealistic.

With respect to Ram's current suggestion, I think that for it to really
make a difference, the "raise as" should not be thought of as a
shorthand/variant of "raise ... from", but rather as a variant of bare
raise; that is, it should not create a chained exception, but an effect
of re-raising while changing the exception value (and potentially
type). This, I think, would address Ethan's claim that "this should
really be raise from None", without the cons described earlier; it is a
better expression of the idea "I just want to change the exception being
raised".

To summarize, I am suggesting that

except ExceptionType:
raise as OtherException(...)

Have, more-or-less, the semantics of Python 2's:

except ExceptionType:
traceback = sys.exc_info()[2]
raise OtherException, OtherException(...), traceback

Thanks for your consideration,

Shai.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KIELJDFFDWTM3IBX7KYOSZVRATGXDLLS/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: Use "raise from" where appropriate, all over the codebase

[Shai Berger]

On Thu, 6 Feb 2020 20:08:28 +0200
Ram Rachum  wrote:

> 
> If I understand correctly, you both agree that using "raise from" in
> this context is better than using plain raise, just that the benefits
> are not worth the price of a bulk update to Django. In other words,
> "raise from" is the inevitable future, it's just that we're not in a
> rush to get there.

As Aymeric pointed out, that's inaccurate; If I understood correctly,
Carlton's argument amounted to "it would be better to have the string
produced by `raise from` in the output, but it's not worth the extra
verbosity in exception handling code" -- besides the price of the bulk
update.

> Keep in mind that the thing I care about is not just usage of "raise
> from" in Django, but in any Python package which is relevant.

... and Carlton's argument applies to them all; when also considering:

> On Sat, 18 Jan 2020 17:18:41 +0200
> Ram Rachum  wrote:
> 
> > 
> > it's very rare to have a legitimate exception
> > without a "raise from" inside an except clause. In almost any
> > context in which "during handling of..." is correct, the raising is
> > done deeper in the stack.
> > 

I think the conclusion should be to ask for a change in Python, not
Django. The rule "if an exception is raised explicitly from an except
clause then it is considered raised-from" seems simple enough to me.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200207024841.368287f6.shai%40platonix.com.

Re: Use "raise from" where appropriate, all over the codebase

[Shai Berger]

On Sat, 18 Jan 2020 17:18:41 +0200
Ram Rachum  wrote:

> On Sat, Jan 18, 2020 at 5:05 PM Shai Berger  wrote:
> 
> > > Regarding automatically enforcing this format going forward: I
> > > looked at the list of Flake8 rules <https://www.flake8rules.com/>
> > > and couldn't find anything about it.
> > >  
> >
> > Indeed, I don't think there can be -- it cannot be a style
> > violation to run into an error while handling another error...
> >  
> 
> I think it can be, as it's very rare to have a legitimate exception
> without a "raise from" inside an except clause. In almost any context
> in which "during handling of..." is correct, the raising is done
> deeper in the stack.
> 
> I think it's rare enough that personally, I would have liked to have a
> Flake8 / PyLint rule like that enforces it, and allow ignoring it
> with a comment. (As much as I hate Lint ignore comments.)

That makes sense. And you know, flake8 supports plugins... a couple of
web searches and "pip search flake8 | grep {raise,from,chain}" didn't
pull anything which seems relevant, but if so, it can be written.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200118174903.5d9b2247.shai%40platonix.com.

Re: Use "raise from" where appropriate, all over the codebase

[Shai Berger]

Hi all,

On Sat, 18 Jan 2020 14:27:23 +0200
Ram Rachum  wrote:

> [...] In any case, the
> way Python chains exceptions when showing them is orthogonal to this
> proposed change. Python already displays the exceptions chained even
> if we don't use "raise from", the only thing that "raise from"
> changes is the text that Python puts between the 2 chained exceptions.
> 

Indeed. Well, almost: there is one more thing that addnig the `from`
changes, and that is the attributes on the exception (actually, it's
these attributes which really control the display): Without `from`, the
original exception is placed in a `__context__` attribute; with `from`,
it is placed in a `__cause__` attribute.

At first I thought this was a reason to object to this change -- I
thought code which catches exceptions and looks into their `__context__`
might break because of it. But as it turns out, `from` puts the
original exception on the `__cause__` in *addition* to `__context__`:

In [8]: try:
   ...: try:
   ...: 1/0
   ...: except ZeroDivisionError as e:
   ...: raise Exception("hi") from e
   ...: except Exception as ex:
   ...: exc = ex
   ...: 

In [10]: exc
Out[10]: Exception('hi')

In [13]: exc.__cause__ is exc.__context__
Out[13]: True

So that is not a concern.

> Regarding automatically enforcing this format going forward: I looked
> at the list of Flake8 rules  and
> couldn't find anything about it.
> 

Indeed, I don't think there can be -- it cannot be a style violation to
run into an error while handling another error...

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200118170519.55c8f2e9.shai%40platonix.com.

Processes stay alive after logout

[Shai Berger]

Hi Debian-KDE,

Does anyone else see processes staying alive after user logout, like I
just reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946976 ?

BTW I started noticing this after installing the `needrestart` package,
which notifies of processes running with obsolete libraries after
upgrades. It showed me processes for users whose sessions were long
gone.

Thanks,
Shai.

Bug#946976: plasma-desktop: Processes stay alive after logoff

[Shai Berger]

Package: plasma-desktop
Version: 4:5.14.5.1-4
Severity: normal

Dear Maintainer,

I have discovered that users on this system who log off their plasma
sessions, leave running processes behind them. These are usually
non-KDE processes.

As an example, some processes left from a user session (all belong
to the said user, all date from their last session, user has no
crontab; some details deleted for privacy reasons)

/lib/systemd/systemd --user
(sd-pam)
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile 
--systemd-activation --syslog-only
/usr/lib/dconf/dconf-service
/usr/lib/at-spi2-core/at-spi-bus-launcher --launch-immediately
/usr/libexec/geoclue-2.0/demos/agent
/usr/bin/dbus-daemon 
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
--print-address 3
/usr/bin/zeitgeist-datahub
/usr/bin/python3 /usr/bin/hp-systray -x
/usr/bin/python3 /usr/bin/hp-systray -x
/usr/lib/tracker/tracker-miner-apps
/usr/lib/tracker/tracker-miner-fs
/usr/lib/gvfs/gvfsd
/usr/lib/gvfs/gvfsd-fuse /run/user/1005/gvfs -f
/usr/lib/tracker/tracker-store
/usr/lib/gvfs/gvfs-udisks2-volume-monitor
/usr/lib/gvfs/gvfs-mtp-volume-monitor
/usr/lib/gvfs/gvfs-goa-volume-monitor
/usr/lib/gnome-online-accounts/goa-daemon
/usr/bin/zeitgeist-daemon
/usr/lib/zeitgeist/zeitgeist-fts
/usr/lib/gnome-online-accounts/goa-identity-service
/usr/lib/gvfs/gvfs-afc-volume-monitor
/usr/lib/gvfs/gvfs-gphoto2-volume-monitor
/usr/lib/bluetooth/obexd

User's session is Plasma. Cinnamon and XFCE are also installed
on the system, but seldom used.

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.14.5-2+b1
ii  kactivitymanagerd5.14.5-1+b1
ii  kde-cli-tools4:5.14.5-2+b1
ii  kded55.62.0-1+b1
ii  kio  5.62.1-2+b1
ii  kpackagetool55.62.0-1
ii  libappstreamqt2  0.12.9-1
ii  libc62.29-3
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc1  1:9.2.1-21
ii  libkf5activities55.62.0-1+b1
ii  libkf5activitiesstats1   5.62.0-1
ii  libkf5archive5   5.62.0-1
ii  libkf5authcore5  5.62.0-1+b1
ii  libkf5baloo5 5.62.0-2+b1
ii  libkf5codecs55.62.0-1
ii  libkf5completion55.62.0-1+b1
ii  libkf5configcore55.62.0-1+b1
ii  libkf5configgui5 5.62.0-1+b1
ii  libkf5configwidgets5 5.62.0-1+b1
ii  libkf5coreaddons55.62.0-1
ii  libkf5dbusaddons55.62.0-1
ii  libkf5declarative5   5.62.0-1+b1
ii  libkf5emoticons-bin  5.62.0-1+b1
ii  libkf5emoticons5 5.62.0-1+b1
ii  libkf5globalaccel-bin5.62.0-1+b1
ii  libkf5globalaccel5   5.62.0-1+b1
ii  libkf5guiaddons5 5.62.0-2
ii  libkf5i18n5  5.62.0-1
ii  libkf5iconthemes55.62.0-1+b1
ii  libkf5itemmodels55.62.0-1
ii  libkf5itemviews5 5.62.0-1+b1
ii  libkf5jobwidgets55.62.0-1+b1
ii  libkf5kcmutils5  5.62.0-1+b1
ii  libkf5kdelibs4support5   5.62.0-2
ii  libkf5kiocore5   5.62.1-2+b1
ii  libkf5kiofilewidgets55.62.1-2+b1
ii  libkf5kiowidgets55.62.1-2+b1
ii  libkf5newstuff5  5.62.0-1+b1
ii  libkf5notifications5 5.62.0-1+b1
ii  libkf5notifyconfig5  5.62.0-1+b1
ii  libkf5package5   5.62.0-1
ii  libkf5parts5 5.62.0-1+b1
ii  libkf5people55.62.0-1+b1
ii  libkf5peoplewidgets5 5.62.0-1+b1
ii  libkf5plasma55.62.0-1+b1
ii  libkf5plasmaquick5   5.62.0-1+b1
ii  libkf5quickaddons5   5.62.0-1+b1
ii  libkf5runner55.62.0-1+b1
ii  libkf5service-bin5.62.0-1
ii  libkf5service5   5.62.0-1
ii  libkf5solid5

Bug#946976: plasma-desktop: Processes stay alive after logoff

[Shai Berger]

Package: plasma-desktop
Version: 4:5.14.5.1-4
Severity: normal

Dear Maintainer,

I have discovered that users on this system who log off their plasma
sessions, leave running processes behind them. These are usually
non-KDE processes.

As an example, some processes left from a user session (all belong
to the said user, all date from their last session, user has no
crontab; some details deleted for privacy reasons)

/lib/systemd/systemd --user
(sd-pam)
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile 
--systemd-activation --syslog-only
/usr/lib/dconf/dconf-service
/usr/lib/at-spi2-core/at-spi-bus-launcher --launch-immediately
/usr/libexec/geoclue-2.0/demos/agent
/usr/bin/dbus-daemon 
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
--print-address 3
/usr/bin/zeitgeist-datahub
/usr/bin/python3 /usr/bin/hp-systray -x
/usr/bin/python3 /usr/bin/hp-systray -x
/usr/lib/tracker/tracker-miner-apps
/usr/lib/tracker/tracker-miner-fs
/usr/lib/gvfs/gvfsd
/usr/lib/gvfs/gvfsd-fuse /run/user/1005/gvfs -f
/usr/lib/tracker/tracker-store
/usr/lib/gvfs/gvfs-udisks2-volume-monitor
/usr/lib/gvfs/gvfs-mtp-volume-monitor
/usr/lib/gvfs/gvfs-goa-volume-monitor
/usr/lib/gnome-online-accounts/goa-daemon
/usr/bin/zeitgeist-daemon
/usr/lib/zeitgeist/zeitgeist-fts
/usr/lib/gnome-online-accounts/goa-identity-service
/usr/lib/gvfs/gvfs-afc-volume-monitor
/usr/lib/gvfs/gvfs-gphoto2-volume-monitor
/usr/lib/bluetooth/obexd

User's session is Plasma. Cinnamon and XFCE are also installed
on the system, but seldom used.

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.14.5-2+b1
ii  kactivitymanagerd5.14.5-1+b1
ii  kde-cli-tools4:5.14.5-2+b1
ii  kded55.62.0-1+b1
ii  kio  5.62.1-2+b1
ii  kpackagetool55.62.0-1
ii  libappstreamqt2  0.12.9-1
ii  libc62.29-3
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc1  1:9.2.1-21
ii  libkf5activities55.62.0-1+b1
ii  libkf5activitiesstats1   5.62.0-1
ii  libkf5archive5   5.62.0-1
ii  libkf5authcore5  5.62.0-1+b1
ii  libkf5baloo5 5.62.0-2+b1
ii  libkf5codecs55.62.0-1
ii  libkf5completion55.62.0-1+b1
ii  libkf5configcore55.62.0-1+b1
ii  libkf5configgui5 5.62.0-1+b1
ii  libkf5configwidgets5 5.62.0-1+b1
ii  libkf5coreaddons55.62.0-1
ii  libkf5dbusaddons55.62.0-1
ii  libkf5declarative5   5.62.0-1+b1
ii  libkf5emoticons-bin  5.62.0-1+b1
ii  libkf5emoticons5 5.62.0-1+b1
ii  libkf5globalaccel-bin5.62.0-1+b1
ii  libkf5globalaccel5   5.62.0-1+b1
ii  libkf5guiaddons5 5.62.0-2
ii  libkf5i18n5  5.62.0-1
ii  libkf5iconthemes55.62.0-1+b1
ii  libkf5itemmodels55.62.0-1
ii  libkf5itemviews5 5.62.0-1+b1
ii  libkf5jobwidgets55.62.0-1+b1
ii  libkf5kcmutils5  5.62.0-1+b1
ii  libkf5kdelibs4support5   5.62.0-2
ii  libkf5kiocore5   5.62.1-2+b1
ii  libkf5kiofilewidgets55.62.1-2+b1
ii  libkf5kiowidgets55.62.1-2+b1
ii  libkf5newstuff5  5.62.0-1+b1
ii  libkf5notifications5 5.62.0-1+b1
ii  libkf5notifyconfig5  5.62.0-1+b1
ii  libkf5package5   5.62.0-1
ii  libkf5parts5 5.62.0-1+b1
ii  libkf5people55.62.0-1+b1
ii  libkf5peoplewidgets5 5.62.0-1+b1
ii  libkf5plasma55.62.0-1+b1
ii  libkf5plasmaquick5   5.62.0-1+b1
ii  libkf5quickaddons5   5.62.0-1+b1
ii  libkf5runner55.62.0-1+b1
ii  libkf5service-bin5.62.0-1
ii  libkf5service5   5.62.0-1
ii  libkf5solid5

Re: Capslock / Numlock indicator not work in KDE (& sddm)

[Shai Berger]

On Mon, 2 Dec 2019 07:54:21 +0100
"luca.pedrielli"  wrote:

> Il 01/12/19 19:18, Lisandro Damián Nicanor Pérez Meyer ha scritto:
> >
> > On Thu, 28 Nov 2019 at 07:06, luca.pedrielli 
> > wrote:  
> >> Il 27/11/19 15:14, Franklin Weng ha scritto:
> > >> Thanks.  With your survey I found a bug report for
> > >> plasma-workspace:
> > >>
> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942429
> > >>
> > >> I've replied it.
> >> pkg problem?  
> > Indeed it was! Thanks **a lot** fro the triaging and the bug report!
> >
> > I have just uploaded the fix, so I guess it will be available in the
> > next mirror push.
> >  
> Installed and working in sid.
> 

Thanks a lot, Franklin, Luca and Lisandro!

Re: Capslock / Numlock indicator not work in KDE (& sddm)

[Shai Berger]

For some reason, both Jimmy and Luca insist on connecting this to the
wrong problem:

On Tue, 26 Nov 2019 01:30:01 -0800
Jimmy Johnson  wrote:

> On 11/25/19 7:10 AM, Franklin Weng wrote:
> > luca.pedrielli  於 2019年11月25日 週一 22:44
> >>
> >> Numlock problems had already been reported
> >>
> >> https://lists.debian.org/debian-kde/2019/09/msg00033.html
> >>
> >>  
> > Not sure, but it looks like not the same problem.  My problem is
> > about the indicator not the status itself.  The NumLock/Capslock
> > status is correct according to the xset -q.  
> 
> 
> The settings for numlock have changed in testing kde5.
> I think the systemsettings, input device module is suppose to be 
> handling numlock on/off at sddm start.
> 

And Luca, later:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941505
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940872

Everything Luca and Jimmy are mentioning is about the state of
numlock when sddm or plasma start.

This is *not* what Franklin or I are talking about. We are talking
about Caps/Num Lock being at the state they should be, as set by
pressing the relevant keys. It is only the visual indicators which are
not working -- the systray icons in plasma, and the caps-is-on warning
in the lock or login screen.

Thanks,
Shai.

Re: ngettext_lazy and ngettext

[Shai Berger]

On Tue, 26 Nov 2019 12:28:45 +0100
Maciek Olko  wrote:

> It looks like Transifex uses [1] Unicode Language Plural Rules [2].
> If they are incorrect for Hebrew, maybe they should be fixed on
> Unicode side?
> 

Just for the record, they are indeed wrong -- not in the sense that has
sparked this thread (there are indeed 4 forms) but in the rules (the
"many" rule should say "2 < n <= 10", not "n % 10 = 0"). I'm looking
into fixing it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20191126195144.066b511b.shai%40platonix.com.

Re: Capslock / Numlock indicator not work in KDE (& sddm)

[Shai Berger]

On Mon, 25 Nov 2019 23:10:57 +0800
Franklin Weng  wrote:

> luca.pedrielli  於 2019年11月25日 週一 22:44 寫道：
> 
> > Il 24/11/19 02:26, Franklin Weng ha scritto:
> >
> > > It looks like no problem in X window level, but the status does
> > > not pass to sddm/plasma correctly.
> >
> >
> > No suggestion, but I can confirm this behaviour.
> >
> > Numlock problems had already been reported
> >
> > https://lists.debian.org/debian-kde/2019/09/msg00033.html
> >  
> Not sure, but it looks like not the same problem.  My problem is
> about the indicator not the status itself.  The NumLock/Capslock
> status is correct according to the xset -q.
> 

I can also confirm this. My situation is exactly what Franklin
described, with one exception: I use lightdm rather than sddm, and
there the "Caps On" warning is always off (even when caps is pressed),
not always on.

Shai

Re: GitHub Actions

[Shai Berger]

On Tue, 5 Nov 2019 13:35:24 -0800 (PST)
Florian Apolloner  wrote:

> 
> Ui, seems like we can start using our own runners: 
> https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/
>  
> -- seems like github actions is becoming more and more a jenkins 
> replacement :D 
> 

Is there benefit enough in GitHub Actions (over Jenkins) to justify a
move from an open-source based solution?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20191106094256.23e027f4.shai%40platonix.com.

Re: Debian/Bullseye plasma screen doesn't lock

[Shai Berger]

On Fri, 25 Oct 2019 08:29:15 -0400
Gary Dale  wrote:

> Since mid-August, my screen doesn't lock automatically after 10
> minutes 
> 
> Any suggestions on how to fix this?
> 
I think this may have to do with the display manager. I've been happily
using lightm with no issues, because sddm was giving me issues (so long
ago that I don't even remember what they were). If you're on a
different display manager, maybe consider switching.