Bug#1065032: closed by Salvo Tomaselli ()
Well you can replace with this one fortune $(dpkg --listfiles fortunes-it | grep /usr/share/games/fortunes/ | egrep -v .dat\|.u8 | shuf -n1) Il giorno mar 16 apr 2024 alle ore 17:36 Anthony Foglia ha scritto: > > Sorry, I hadn't seen your initial response > > I was using the fortune program to show me random Italian quotes to work on > learning the language. Before I could just point fortune at the folder with > all the Italian fortunes. That's no longer easy without them in a separate > folder. > > So in my .bashrc I have > > if [[ -x /usr/games/fortune ]]; then > if [[ -d /usr/share/games/fortunes/it ]]; then > /usr/games/fortune /usr/share/games/fortunes/it > elif type dpkg > /dev/null; then > # As of v2, debian's fortunes-it package no longer puts the > # fortunes in a separate directory. > dpkg -L fortunes-it | grep "/usr/share/games/fortunes/" | grep -v \\. | xargs > -r /usr/games/fortune > fi > fi > > The call to dpkg is an obvious kludge. I'm surprised all the debian fortune > maintainers don't have a convention/best practice around this. > > I'm just end-user, so take my opinion/usage with a grain of salt. (To be > fair, I could just uninstall the other fortune-providing packages.) > > Sent with Shortwave > > On Mon Apr 15, 2024, 04:51 PM GMT, Debian Bug Tracking System wrote: > > This is an automatic notification regarding your Bug report > which was filed against the fortunes-it package: > > #1065032: fortunes-it: fortunes/it directory no longer used > > It has been closed by Salvo Tomaselli . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Salvo Tomaselli > by > replying to this email. > > > -- > 1065032: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065032 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io
Bug#1067184: ITP: krecorder -- recorder application
Package: wnpp Severity: wishlist Owner: Salvo Tomaselli X-Debbugs-Cc: debian-de...@lists.debian.org, ltw...@debian.org * Package name: krecorder Version : 24.02.0 Upstream Contact: Devin Lin * URL : https://apps.kde.org/it/krecorder/ * License : GPL Programming Lang: C++ Description : recorder application kirigami based audio recorder for plasma. It can be used on small touchscreens or on desktop
Bug#1067183: ITP: skladnik -- formerly known as ksokoban, a sokoban game
Package: wnpp Severity: wishlist Owner: Salvo Tomaselli X-Debbugs-Cc: debian-de...@lists.debian.org, ltw...@debian.org * Package name: skladnik Version : 0.5.2 Upstream Contact: Łukasz Kalamłacki * URL : https://apps.kde.org/it/skladnik/ * License : GPL Programming Lang: C++ Description : formerly known as ksokoban, a sokoban game The usual sokoban game, about pushing things on a destination inside a maze.
Bug#1067050: ITP: ultimateultimateguitar -- CLI for the ultimateguitar website
Package: wnpp Severity: wishlist Owner: Salvo Tomaselli X-Debbugs-Cc: debian-de...@lists.debian.org, ltw...@debian.org * Package name: ultimateultimateguitar Version : 1.4 Upstream Contact: Salvo Tomaselli * URL : https://codeberg.org/ltworf/ultimateultimateguitar * License : AGPL Programming Lang: Python Description : CLI for the ultimateguitar website It is a CLI to search songs on ultimateuguitar website, parse their format and output the text and chords on the terminal. It has support for transpose. It can be useful to hobby musicians such as myself to avoid all the spam that the website contains when accessed from a browser. I plan to maintain it alone, on the same repository where the project is hosted. I'm happy to add people to the project if they want to help out.
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
> This is also being used in src:explosive-c4 now and the approach breaks > cross compilation. Please stop doing this, we'll have to touch all of > these. > > Still the use case is real and we need a better way to build packages > with qmake6. I was talking with Sune and Lisandro on IRC and their > consensus seems to have been that qtchooser and QT_SELECT are dead and > should not be used for Qt6. They suggested that we add add a new > --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not > have qmake6? While changing QT_SELECT from qt5 to qt6 would be > convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough, > no? The qmake6 build system can reuse qmake just like qmake_qt4 and > doing it that way immediately makes cross compilation just work (since > we already have -qmake6). Lisandro requested naming it qmake6 > rather than qmake_qt6. Even though this breaks consistency with earlier > use in debhelper, the similarity to how upstream calls it more > important. > > Salvo and Alexandre, do you second this? It would be fine by me, I hope it should be cleaner than how it was to go from 4 to 5. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.codeberg.page/ signature.asc Description: This is a digitally signed message part.
Bug#1058361: ITP: python-pyasyncore -- asyncore for Python 3.12 onwards
Thank you so much, I really didn't feel like rewriting my code to manage my electrical relais at home! -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.codeberg.page/
Bug#1054417: cve number
Tracked in CVE-2023-46586
Bug#1052683: ITP: railway -- GUI application for searching train journeys
Does it work outside of Germany? Perhaps its area should be in the description. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io signature.asc Description: This is a digitally signed message part.
Bug#1052028: please update to pydantic 2.x
Wouldn't it be better to package it as python3-pydantic2 directly? To avoid breaking every software that uses it. In that way they could just coexist and packages depending on the old one wouldn't all suddenly break. Best -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/ signature.asc Description: This is a digitally signed message part.
Bug#1007698: ITP: kasts -- kasts is a podcast client for desktop and mobile
I have a preliminary dsc file here https://tomaselli.page/pub/debian/kasts_23.07.90-1.dsc but the copyright file needs to be updated, I think I had written it for an older version Il giorno mar 5 set 2023 alle ore 22:29 Marco Mattiolo ha scritto: > > Hi Salvo, > > that's great news that you're back working on this package! > > You've probably already found out by yourself the complete list of > Build-Deps and runtime dependencies for Kasts: to stay on the safe side, > please check this discussion with upstream developer [1]. > > TL,DR: > > - VLC backend should be preferred, which needs libvlccore-dev as Build-Dep > > - vlc-plugin-base and qml-module-qt-labs-settings are needed as runtime > dependencies > > - Kirigami is needed to be at least 5.105.0 (Debian testing/sid are > already fine with that) > > Kind regards > > Marco > > [1] https://bugs.kde.org/show_bug.cgi?id=473648 > > Il 12/08/23 00:38, Salvo Tomaselli ha scritto: > > I started again to work on this, on the latest version of kasts > > > > Il giorno sab 22 lug 2023 alle ore 14:17 Salvo Tomaselli > > ha scritto: > >> Hello, > >> > >> I was planning to do it in the summer, but my hard drive is broken, > >> I'm waiting for lenovo to do something about it. > >> > >> Il giorno sab 1 lug 2023 alle ore 15:57 Marco Mattiolo > >> ha scritto: > >>> Hi Tzafrir, > >>> > >>> no news on my side for the packaging. There's an ITP bug submitted by > >>> Salvo, I will leave that answer to him. > >>> > >>> Thank you for the MR on 23.04.2! > >>> > >>> My 2 cents on the icons issue: I faced the same when installing kasts in > >>> a non-Plasma environment (Phosh on pmOS), I solved it by installing > >>> Breeze icon theme and then creating a custom launcher. > >>> > >>> cp /usr/share/applications/org.kde.kasts.desktop > >>> ~/.local/share/applications/ > >>> > >>> Then, modify the 'Exec' line in the launcher with the following: > >>> > >>> Exec=env QT_STYLE_OVERRIDE=Breeze kasts > >>> > >>> I'm recalling that by memory because I've re-flashed the phone in the > >>> meanwhile, you could be required to tweak something. My source was [1] > >>> btw. > >>> > >>> Kind regards > >>> > >>> Marco > >>> > >>> [1] > >>> https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications > >>> > >>> > >>> Il 28/06/23 23:16, Tzafrir Cohen ha scritto: > >>> > >>> Any news? > >>> > >>> I tried this package again. I updated the packaging for upstream 23.04.2 > >>> (See a simple MR[1]). Right now it runs, but there are missing > >>> images on buttons, both on my desktop (sway) and on my mobian phone > >>> (where the flatpak runs OK). > >>> > >>> CMake also notes that the optional VNC playback backend is missing. How > >>> important is this? > >>> > >>> On my phone I had to install the following two packages (that I > >>> guessed from error messages) > >>> > >>> qml-module-org-kde-kirigami-addons-labs-components > >>> qml-module-qt-labs-qmlmodels > >>> > >>> And still I get the following output in my terminal: > >>> Database version 6 > >>> kf.kirigami: Failed to find a Kirigami platform plugin > >>> qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for > >>> property "implicitHeight" > >>> qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for > >>> property "implicitHeight" > >>> qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected > >>> for property "implicitHeight" > >>> qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected > >>> for property "implicitHeight" > >>> file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9: > >>> QML MouseArea: Binding loop detected for property "width" > >>> file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9: > >>> QML ListView: Binding loop detected for property "topMargin" > >>> file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9: > >>> QML ListView: Binding loop detected for property "topMargin" > >>> > >>> > >>> [1] https://salsa.debian.org/ltworf-guest/kasts/-/merge_requests/2 > >>> > >> > >> -- > >> Salvo Tomaselli > >> > >> "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di > >> senso, ragione ed intelletto intendesse che noi ne facessimo a meno." > >> -- Galileo Galilei > >> > >> http://ltworf.github.io/ltworf/ > > > > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1050903: segmentation fault
One of my contacts has published a story and telegram just crashes immediately after I login. I downgraded to the version in testing. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1007698: ITP: kasts -- kasts is a podcast client for desktop and mobile
I started again to work on this, on the latest version of kasts Il giorno sab 22 lug 2023 alle ore 14:17 Salvo Tomaselli ha scritto: > > Hello, > > I was planning to do it in the summer, but my hard drive is broken, > I'm waiting for lenovo to do something about it. > > Il giorno sab 1 lug 2023 alle ore 15:57 Marco Mattiolo > ha scritto: > > > > Hi Tzafrir, > > > > no news on my side for the packaging. There's an ITP bug submitted by > > Salvo, I will leave that answer to him. > > > > Thank you for the MR on 23.04.2! > > > > My 2 cents on the icons issue: I faced the same when installing kasts in a > > non-Plasma environment (Phosh on pmOS), I solved it by installing Breeze > > icon theme and then creating a custom launcher. > > > > cp /usr/share/applications/org.kde.kasts.desktop > > ~/.local/share/applications/ > > > > Then, modify the 'Exec' line in the launcher with the following: > > > > Exec=env QT_STYLE_OVERRIDE=Breeze kasts > > > > I'm recalling that by memory because I've re-flashed the phone in the > > meanwhile, you could be required to tweak something. My source was [1] btw. > > > > Kind regards > > > > Marco > > > > [1] > > https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications > > > > > > Il 28/06/23 23:16, Tzafrir Cohen ha scritto: > > > > Any news? > > > > I tried this package again. I updated the packaging for upstream 23.04.2 > > (See a simple MR[1]). Right now it runs, but there are missing > > images on buttons, both on my desktop (sway) and on my mobian phone > > (where the flatpak runs OK). > > > > CMake also notes that the optional VNC playback backend is missing. How > > important is this? > > > > On my phone I had to install the following two packages (that I > > guessed from error messages) > > > > qml-module-org-kde-kirigami-addons-labs-components > > qml-module-qt-labs-qmlmodels > > > > And still I get the following output in my terminal: > > Database version 6 > > kf.kirigami: Failed to find a Kirigami platform plugin > > qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for > > property "implicitHeight" > > qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for > > property "implicitHeight" > > qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected for > > property "implicitHeight" > > qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected for > > property "implicitHeight" > > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9: > > QML MouseArea: Binding loop detected for property "width" > > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9: > > QML ListView: Binding loop detected for property "topMargin" > > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9: > > QML ListView: Binding loop detected for property "topMargin" > > > > > > [1] https://salsa.debian.org/ltworf-guest/kasts/-/merge_requests/2 > > > > > -- > Salvo Tomaselli > > "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di > senso, ragione ed intelletto intendesse che noi ne facessimo a meno." > -- Galileo Galilei > > http://ltworf.github.io/ltworf/ -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1007698: ITP: kasts -- kasts is a podcast client for desktop and mobile
Hello, I was planning to do it in the summer, but my hard drive is broken, I'm waiting for lenovo to do something about it. Il giorno sab 1 lug 2023 alle ore 15:57 Marco Mattiolo ha scritto: > > Hi Tzafrir, > > no news on my side for the packaging. There's an ITP bug submitted by Salvo, > I will leave that answer to him. > > Thank you for the MR on 23.04.2! > > My 2 cents on the icons issue: I faced the same when installing kasts in a > non-Plasma environment (Phosh on pmOS), I solved it by installing Breeze icon > theme and then creating a custom launcher. > > cp /usr/share/applications/org.kde.kasts.desktop ~/.local/share/applications/ > > Then, modify the 'Exec' line in the launcher with the following: > > Exec=env QT_STYLE_OVERRIDE=Breeze kasts > > I'm recalling that by memory because I've re-flashed the phone in the > meanwhile, you could be required to tweak something. My source was [1] btw. > > Kind regards > > Marco > > [1] https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications > > > Il 28/06/23 23:16, Tzafrir Cohen ha scritto: > > Any news? > > I tried this package again. I updated the packaging for upstream 23.04.2 > (See a simple MR[1]). Right now it runs, but there are missing > images on buttons, both on my desktop (sway) and on my mobian phone > (where the flatpak runs OK). > > CMake also notes that the optional VNC playback backend is missing. How > important is this? > > On my phone I had to install the following two packages (that I > guessed from error messages) > > qml-module-org-kde-kirigami-addons-labs-components > qml-module-qt-labs-qmlmodels > > And still I get the following output in my terminal: > Database version 6 > kf.kirigami: Failed to find a Kirigami platform plugin > qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for property > "implicitHeight" > qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for property > "implicitHeight" > qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected for > property "implicitHeight" > qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected for > property "implicitHeight" > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9: > QML MouseArea: Binding loop detected for property "width" > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9: > QML ListView: Binding loop detected for property "topMargin" > file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9: > QML ListView: Binding loop detected for property "topMargin" > > > [1] https://salsa.debian.org/ltworf-guest/kasts/-/merge_requests/2 > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1040601: python3-typedload-doc: broken symlink: /usr/share/doc/python3-typedload/docs/README.md -> ../README.md
Thank you for your report. The fix will be included in the next version. Il giorno ven 7 lug 2023 alle ore 21:23 Andreas Beckmann ha scritto: > > Package: python3-typedload-doc > Version: 2.24-1 > Severity: normal > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships (or creates) > a broken symlink: > > 0m32.5s ERROR: FAIL: Broken symlinks: > /usr/share/doc/python3-typedload/docs/README.md -> ../README.md > (python3-typedload-doc) > > > cheers, > > Andreas -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1005369: xserver-xorg-core: Breaks middle button trackpoint scrolling
Yes it has some options. Not as many as the alternatives. Some of those options happen to be ones that I change. Il giorno mer 5 apr 2023 alle ore 02:22 Alban Browaeys ha scritto: > > I am on a thinkapd (the Yoga S1) and xorg libinput driver works fine (I > configure it through gnome-control-center). > > I really do not know what you mean by "avoid libinput's opinions on how > my input should work". Could you give example? > > https://www.mankier.com/4/libinput > these do not count as configuration options? > > Cheers, > > Alban > > > Le mardi 04 avril 2023 à 21:21 +0200, Salvo Tomaselli a écrit : > > No the libinput one is bad. > > > > libinput's author doesn't want options, so there is no way to have > > usable input that feels good on thinkpads. > > > > I'm using the xserver-xorg-input-evdev one. I guess when Xorg will be > > kicked out of debian, I will need to move to devuan or something like > > that, just to avoid libinput's opinions on how my input should work. > > > > Il giorno mar 4 apr 2023 alle ore 18:45 Alban Browaeys > > ha scritto: > > > > > > Try removing > > > xserver-xorg-input-synaptics > > > then restart xorg. > > > > > > xserver-xorg-input-synaptics i sno longer supported by GNOME as far > > > as > > > know. > > > xserver-xorg-input-libinput is the replacment. > > > > > > Cheers, > > > Alban > > > > > > On Sat, 12 Feb 2022 09:53:16 +0100 "Salvo \"LtWorf\" Tomaselli" > > > wrote: > > > > Package: xserver-xorg-core > > > > Version: 2:21.1.3-2 > > > > Severity: critical > > > > Tags: upstream > > > > Justification: breaks unrelated software > > > > X-Debbugs-Cc: tipos...@tiscali.it > > > > > > > > Dear Maintainer, > > > > > > > > on thinkpads it is common to scroll by holding down the middle > > > > button > > > and > > > > pushing the trackpoint up or down. > > > > > > > > After upgrading, this feature is broken. > > > > > > > > Reverting to the version found in testing makes it work again. > > > > > > > > In a wayland session it works (but my keyboard layout doesn't > > > > exist > > > in wayland > > > > so using it permanently is not a viable solution). > > > > > > > > It is strange because the input drivers have not received an > > > > update, > > > so I'm not > > > > really sure of what the interaction is here. > > > > > > > > Anyway, I'm creating this issue with a high priority in order to > > > > stop > > > the package > > > > from migrating and make scrolling suddenly unavailable to other > > > people as well. > > > > > > > > -- Package-specific info: > > > > /etc/X11/X does not exist. > > > > /etc/X11/X is not a symlink. > > > > /etc/X11/X is not executable. > > > > > > > > VGA-compatible devices on PCI bus: > > > > -- > > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation > > > TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) > > > > > > > > /etc/X11/xorg.conf does not exist. > > > > > > > > Contents of /etc/X11/xorg.conf.d: > > > > - > > > > total 0 > > > > > > > > /etc/modprobe.d contains no KMS configuration files. > > > > > > > > Kernel version (/proc/version): > > > > --- > > > > Linux version 5.16.0-1-amd64 (debian-ker...@lists.debian.org) > > > > (gcc-11 > > > (Debian 11.2.0-16) 11.2.0, GNU ld (GNU Binutils for Debian) > > > 2.37.90.20220130) #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) > > > > > > > > Xorg X server log files on system: > > > > -- > > > > -rw-r--r-- 1 root root 50312 Feb 12 09:43 /var/log/Xorg.0.log > > > > > > > > Contents of most recent Xorg X server log file > > > > (/var/log/Xorg.0.log): > > > > - > > > > > > > > [ 2.949] (--) Log file renamed from "/var/log/Xorg.pid- > > > > 579.log" > > > to "/var/log/Xorg.0.log" > > > > [ 2.951] > > > > X.Org X Server 1.21.1.3 > > > > X Protocol Version 11, Revision 0 > > > > [ 2.951] Current Operating System: Linux galatea 5.16.0-1- > > > > amd64 > > > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64 > > > > [ 2.951] Kernel command line: BOOT_IMAGE=/boot/vmlinuz- > > > > 5.16.0-1- > > > amd64 root=UUID=2e600d3e-5bd5-43cd-b826-9213b7bafb99 ro quiet > > > > [ 2.951] xorg-server 2:21.1.3-2 > > > > (https://www.debian.org/support) > > > > [ 2.951] Current version of pixman: 0.40.0 > > > > > > > > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1005369: xserver-xorg-core: Breaks middle button trackpoint scrolling
No the libinput one is bad. libinput's author doesn't want options, so there is no way to have usable input that feels good on thinkpads. I'm using the xserver-xorg-input-evdev one. I guess when Xorg will be kicked out of debian, I will need to move to devuan or something like that, just to avoid libinput's opinions on how my input should work. Il giorno mar 4 apr 2023 alle ore 18:45 Alban Browaeys ha scritto: > > Try removing > xserver-xorg-input-synaptics > then restart xorg. > > xserver-xorg-input-synaptics i sno longer supported by GNOME as far as > know. > xserver-xorg-input-libinput is the replacment. > > Cheers, > Alban > > On Sat, 12 Feb 2022 09:53:16 +0100 "Salvo \"LtWorf\" Tomaselli" > wrote: > > Package: xserver-xorg-core > > Version: 2:21.1.3-2 > > Severity: critical > > Tags: upstream > > Justification: breaks unrelated software > > X-Debbugs-Cc: tipos...@tiscali.it > > > > Dear Maintainer, > > > > on thinkpads it is common to scroll by holding down the middle button > and > > pushing the trackpoint up or down. > > > > After upgrading, this feature is broken. > > > > Reverting to the version found in testing makes it work again. > > > > In a wayland session it works (but my keyboard layout doesn't exist > in wayland > > so using it permanently is not a viable solution). > > > > It is strange because the input drivers have not received an update, > so I'm not > > really sure of what the interaction is here. > > > > Anyway, I'm creating this issue with a high priority in order to stop > the package > > from migrating and make scrolling suddenly unavailable to other > people as well. > > > > -- Package-specific info: > > /etc/X11/X does not exist. > > /etc/X11/X is not a symlink. > > /etc/X11/X is not executable. > > > > VGA-compatible devices on PCI bus: > > -- > > 00:02.0 VGA compatible controller [0300]: Intel Corporation > TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) > > > > /etc/X11/xorg.conf does not exist. > > > > Contents of /etc/X11/xorg.conf.d: > > - > > total 0 > > > > /etc/modprobe.d contains no KMS configuration files. > > > > Kernel version (/proc/version): > > --- > > Linux version 5.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 > (Debian 11.2.0-16) 11.2.0, GNU ld (GNU Binutils for Debian) > 2.37.90.20220130) #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) > > > > Xorg X server log files on system: > > -- > > -rw-r--r-- 1 root root 50312 Feb 12 09:43 /var/log/Xorg.0.log > > > > Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): > > - > > [ 2.949] (--) Log file renamed from "/var/log/Xorg.pid-579.log" > to "/var/log/Xorg.0.log" > > [ 2.951] > > X.Org X Server 1.21.1.3 > > X Protocol Version 11, Revision 0 > > [ 2.951] Current Operating System: Linux galatea 5.16.0-1-amd64 > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64 > > [ 2.951] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.16.0-1- > amd64 root=UUID=2e600d3e-5bd5-43cd-b826-9213b7bafb99 ro quiet > > [ 2.951] xorg-server 2:21.1.3-2 (https://www.debian.org/support) > > [ 2.951] Current version of pixman: 0.40.0 > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1023124: How i fixed my system
For anyone finding this after the fact. I had to remove dpkg-fsys-usrunmess. Use aptitude because apt's crap resolver won't do it. aptitude --allow-remove-essential install usrmerge aptitude remove dpkg-fsys-usrunmess Then I manually (with a script) had to delete a bunch of duplicated files, because I had older files in /lib and newer ones in /usr/lib. This is the script, don't run it blindly while /usr/lib/usrmerge/convert-usrmerge 2>&1 | grep Both | cut -d\ -fusrmerge; do /usr/lib/usrmerge/convert-usrmerge 2>&1 | grep Both | cut -d\ -f 4 rm $(/usr/lib/usrmerge /convert-usrmerge 2>&1 | grep Both | cut -d\ -f 4) done After this, I could run again aptitude install usrmerge After this, the system seems in an upgradable state again. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.github.io/
Bug#1023124: libsystemd-shared-251.so: cannot open shared object file
systemd-machine-id-setup: /usr/bin/systemd-machine-id-setup /bin/systemd-machine-id-setup /usr/share/man/man1/systemd-machine-id-setup.1.gz stat /usr/bin/systemd-machine-id-setup /bin/systemd-machine-id-setup File: /usr/bin/systemd-machine-id-setup Size: 18928 Blocks: 40 IO Block: 4096 regular file Device: 259,5 Inode: 4201937 Links: 1 Access: (0755/-rwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2022-10-30 13:34:13.098418093 +0100 Modify: 2022-08-14 20:06:18.0 +0200 Change: 2022-08-22 15:25:56.730012624 +0200 Birth: 2022-08-22 15:25:56.610011671 +0200 File: /bin/systemd-machine-id-setup Size: 18928 Blocks: 40 IO Block: 4096 regular file Device: 259,5 Inode: 8650854 Links: 1 Access: (0755/-rwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2022-10-30 13:38:20.0 +0100 Modify: 2022-10-14 16:34:00.0 +0200 Change: 2022-10-30 13:38:20.944385494 +0100 Birth: 2022-10-30 13:38:20.816384357 +0100 It seems my system is in a weird status from some previous issues… Maybe originating when apt told me to split /usr, then I had some issues and had to manually install a bunch of packages. Il giorno dom 30 ott 2022 alle ore 13:52 Ansgar ha scritto: > > On Sun, 2022-10-30 at 13:34 +0100, Salvo "LtWorf" Tomaselli wrote: > > Preconfiguring packages ... > > Setting up systemd (252~rc3-2) ... > > systemd-machine-id-setup: error while loading shared libraries: > > libsystemd-shared-251.so: cannot open shared object file: No such file or > > directory > > dpkg: error processing package systemd (--configure): > > installed systemd package post-installation script subprocess returned > > error exit status 127 > > Errors were encountered while processing: > > systemd > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > The /bin/systemd-machine-id-setup shipped in the systemd 252~rc3-2 > package is linked against libsystemd-shared-252.so, not libsystemd- > shared-251.so. > > Please check all paths given in the PATH used when calling dpkg/apt for > systemd-machine-id-setup (e.g., by using `which -a systemd-machine-id- > setup` with the correct PATH) and report their location and sha1 hash > (sha1sum /bin/systemd-machine-id-setup ...). > > Please also report the output of `ls -ld /bin /usr/bin` and whether the > system is merged-/usr already or not. > > Ansgar > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1022941: Confirm
I can confirm. The update breaks systemd. 200 pacchetti aggiornati, 0 installati, 0 da rimuovere e 4 non aggiornati. È necessario prelevare 0 B/374 MB di archivi. Dopo l'estrazione, verranno occupati 21,1 MB. Continuare? [Y/n/?] Lettura dei changelog... Fatto Estrazione dei template dai pacchetti: 100% Preconfigurazione dei pacchetti in corso Configurazione di systemd (252~rc3-2)... systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-251.so: cannot open shared object file: No such file or directory dpkg: errore nell'elaborare il pacchetto systemd (--configure): il sottoprocesso installato pacchetto systemd script post-installation ha restituito lo stato di errore 127 Si sono verificati degli errori nell'elaborazione: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) Configurazione di systemd (252~rc3-2)... systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-251.so: cannot open shared object file: No such file or directory dpkg: errore nell'elaborare il pacchetto systemd (--configure): il sottoprocesso installato pacchetto systemd script post-installation ha restituito lo stato di errore 127 dpkg: problemi con le dipendenze impediscono la configurazione di libpam-systemd:amd64: libpam-systemd:amd64 dipende da systemd (= 252~rc3-2); tuttavia: Il pacchetto systemd non è ancora configurato. dpkg: errore nell'elaborare il pacchetto libpam-systemd:amd64 (--configure): problemi con le dipendenze - lasciato non configurato dpkg: problemi con le dipendenze impediscono la configurazione di systemd-resolved: systemd-resolved dipende da systemd (= 252~rc3-2); tuttavia: Il pacchetto systemd non è ancora configurato. dpkg: errore nell'elaborare il pacchetto systemd-resolved (--configure): problemi con le dipendenze - lasciato non configurato dpkg: problemi con le dipendenze impediscono la configurazione di libnss-systemd:amd64: libnss-systemd:amd64 dipende da systemd (= 252~rc3-2); tuttavia: Il pacchetto systemd non è ancora configurato. dpkg: errore nell'elaborare il pacchetto libnss-systemd:amd64 (--configure): problemi con le dipendenze - lasciato non configurato dpkg: problemi con le dipendenze impediscono la configurazione di libnss-resolve:amd64: libnss-resolve:amd64 dipende da systemd-resolved (= 252~rc3-2); tuttavia: Il pacchetto systemd-resolved non è ancora configurato. dpkg: errore nell'elaborare il pacchetto libnss-resolve:amd64 (--configure): problemi con le dipendenze - lasciato non configurato Si sono verificati degli errori nell'elaborazione: systemd libpam-systemd:amd64 systemd-resolved libnss-systemd:amd64 libnss-resolve:amd64 -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#712119: Closing this bug (BTS maintenance for src:linux bugs)
Feel free to close, The issue I had on the newer machine was an hardware issue that got solved by replacing the keyboard. Something was wrong with the electronic there and I think it was confusing the whole bus so also the touchpad, despite being a different device was affected. Sorry, I had forgotten about this. Il giorno mar 31 mag 2022 alle ore 18:03 Diederik de Haas ha scritto: > > On 24 Apr 2021 20:04:52 +0200 Salvo Tomaselli wrote: > > I have another machine but the issue is still there by the way :d > > Which kernel version does that other machine run? > With that info we can update the metadata (and title), so it doesn't come > across (at least to me) as obsolete :-) -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#824520: RFP: subsurface -- scuba diving logbook
Yes of course for the users of Debian it's best to have it rather than not have it. Best of luck! Il giorno mer 25 mag 2022 alle ore 03:49 Philippe Cerfon ha scritto: > > On Sun, May 22, 2022 at 10:45 PM Salvo Tomaselli wrote: > > My advice is to forget this. Upstream is really uncooperative and > > Torvalds went to conferences to talk about this (conveniently > > forgetting to mention he was depending an unstable library whose > > author said "Don't use this yet") > > Well also had some interactions with upstream in the past and it felt > indeed a bit "difficult". So I can kinda understand your frustration. > > Nevertheless, that upstream may be a bit distribution-unfriendly > doesn't make subsurface itself less usable. I'd say it's still among > the "best" software for diving in the FLOSS world - and that "market" > isn't so big, so people cannot just easily choose any other random > software (none if which would be packaged for Debian either). > > In the end, divers will just resort to some unofficial packages > (security issues) or IMO questionable systems like snap. So I think > there would be some value to get that officially packaged. > > Thanks, > Philippe -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#824520: RFP: subsurface -- scuba diving logbook
My advice is to forget this. Upstream is really uncooperative and Torvalds went to conferences to talk about this (conveniently forgetting to mention he was depending an unstable library whose author said "Don't use this yet") The video of that conference that happened ages ago is still shared today to "prove" how the distribution model is bad, distro maintainers are mean, and so on. Just my advice. Il giorno dom 22 mag 2022 alle ore 13:58 David Bremner ha scritto: > > Philippe Cerfon writes: > > > btw... I've just seen there's: > > http://ppa.launchpad.net/subsurface/subsurface/ubuntu > > (including packaging for all the deps) > > > > So maybe, it could be much simpler to get this back into Debian, by > > simply basing the Debian packaging on Ubuntu's. > > To be honest, I doubt that helps, since the hard part is not just making > packages (my repo on salsa already does that), but making them in a way > acceptable to debian policy, which is unlikely to be a priority for a > PPA. > > d -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1008598: Patch with the fix
tags 1008598 + patch
thanks
I attach a patch to fix the issue.
I tested locally and it seems to be working fine for me.
Best.
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei
http://ltworf.github.io/ltworf/
Description: This passes the loop parameter only on the supported versions
The loop parameter has been deprecated for years.
.
This library is buggy, and on the versions where the parameter is deprecated
it passes a None.
.
This actually broke when the parameter was removed for real, since the
parameter should not be passed at all instead.
Bug-Debian: #1008598
From: Salvo 'LtWorf' Tomaselli
--- python-websockets-9.1.orig/src/websockets/legacy/protocol.py
+++ python-websockets-9.1/src/websockets/legacy/protocol.py
@@ -151,8 +151,11 @@ class WebSocketCommonProtocol(asyncio.Pr
self._paused = False
self._drain_waiter: Optional[asyncio.Future[None]] = None
+kwloop = {}
+if sys.version_info[:2] < (3, 8):
+kwloop['loop'] = self.loop
self._drain_lock = asyncio.Lock(
-loop=loop if sys.version_info[:2] < (3, 8) else None
+**kwloop
)
# This class implements the data transfer and closing handshake, which
@@ -225,6 +228,9 @@ class WebSocketCommonProtocol(asyncio.Pr
raise exc
if self.transport is not None:
if self.transport.is_closing():
+kwloop = {}
+if sys.version_info[:2] < (3, 8):
+kwloop['loop'] = self.loop
# Yield to the event loop so connection_lost() may be
# called. Without this, _drain_helper() would return
# immediately, and code that calls
@@ -232,7 +238,7 @@ class WebSocketCommonProtocol(asyncio.Pr
# in a loop would never call connection_lost(), so it
# would not see an error when the socket is closed.
await asyncio.sleep(
-0, loop=self.loop if sys.version_info[:2] < (3, 8) else None
+0, **kwloop
)
await self._drain_helper()
@@ -399,12 +405,15 @@ class WebSocketCommonProtocol(asyncio.Pr
pop_message_waiter: asyncio.Future[None] = self.loop.create_future()
self._pop_message_waiter = pop_message_waiter
try:
+kwloop = {}
+if sys.version_info[:2] < (3, 8):
+kwloop['loop'] = self.loop
# If asyncio.wait() is canceled, it doesn't cancel
# pop_message_waiter and self.transfer_data_task.
await asyncio.wait(
[pop_message_waiter, self.transfer_data_task],
-loop=self.loop if sys.version_info[:2] < (3, 8) else None,
return_when=asyncio.FIRST_COMPLETED,
+**kwloop,
)
finally:
self._pop_message_waiter = None
@@ -596,10 +605,13 @@ class WebSocketCommonProtocol(asyncio.Pr
"""
try:
+kwloop = {}
+if sys.version_info[:2] < (3, 8):
+kwloop['loop'] = self.loop
await asyncio.wait_for(
self.write_close_frame(serialize_close(code, reason)),
self.close_timeout,
-loop=self.loop if sys.version_info[:2] < (3, 8) else None,
+**kwloop,
)
except asyncio.TimeoutError:
# If the close frame cannot be sent because the send buffers
@@ -615,12 +627,15 @@ class WebSocketCommonProtocol(asyncio.Pr
# Other calls will receive a CancelledError here.
try:
+kwloop = {}
+if sys.version_info[:2] < (3, 8):
+kwloop['loop'] = self.loop
# If close() is canceled during the wait, self.transfer_data_task
# is canceled before the timeout elapses.
await asyncio.wait_for(
self.transfer_data_task,
self.close_timeout,
-loop=self.loop if sys.version_info[:2] < (3, 8) else None,
+**kwloop,
)
except (asyncio.TimeoutError, asyncio.CancelledError):
pass
@@ -1039,10 +1054,13 @@ class WebSocketCommonProtocol(asyncio.Pr
return
try:
+kwloop = {}
+if sys.version_info[:2] < (3, 8):
+kwloop['loop'] = self.loop
while True:
await asyncio.sleep(
self.ping_interval,
-loop=self.loop if sys.version_info[:2] < (3, 8) else None,
+**kwloop,
)
# ping() raises CancelledErr
Bug#932925: Any news on this?
Hello, Any news on this? I might be interested in actually doing it… -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1007157: gnome-sudoku menu entry is not shown on my pinephone
I created a patch for upstream https://gitlab.gnome.org/GNOME/gnome-sudoku/-/merge_requests/40 Il giorno sab 12 mar 2022 alle ore 12:41 Jeremy Bicha ha scritto: > > On Sat, Mar 12, 2022 at 6:27 AM Salvo 'LtWorf' Tomaselli > wrote: > > I use mobian on a pinephone and gnome-sudoku is not shown among the apps by > > default. > > > > That's because the .desktop file lacks an entry to mark it as "phone > > friendly". > > Thank you for taking the time to report this bug. > > Please report these issues upstream to GNOME first. > https://gitlab.gnome.org/GNOME/gnome-sudoku/-/issues > > I don't have a phone running mobile GNOME so I'm not sure how to test, > but I guess Iagno & GNOME Sudoku scale down well enough. > > Thanks, > Jeremy Bicha -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1007156: iagno menu entry is not shown on my pinephone
Upstream master already has it https://gitlab.gnome.org/GNOME/iagno/-/commit/66cbfee802228657f5feb83a14fea869c41cbe56 Il giorno sab 12 mar 2022 alle ore 12:15 Salvo 'LtWorf' Tomaselli ha scritto: > > Package: iagno > Version: 1:3.38.1-2 > Severity: normal > Tags: patch upstream > X-Debbugs-Cc: tipos...@tiscali.it > > Dear Maintainer, > > I use mobian on a pinephone and iagno is not shown among the apps by default. > > That's because the .desktop file lacks an entry to mark it as "phone > friendly". > > I attach a 1 line patch to correct the .desktop file. > > Best > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages iagno depends on: > ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 > ii libc62.33-7 > ii libcairo21.16.0-5 > ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 > ii libglib2.0-0 2.70.4-1 > ii libgsound0 1.0.3-2 > ii libgtk-3-0 3.24.31-1 > ii librsvg2-2 2.52.5+dfsg-3+b1 > > Versions of packages iagno recommends: > pn yelp > > iagno suggests no packages. > > -- no debconf information -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#998767: the debhelper works
The debhelper works, I'm getting ready to use it in my typedload package, to install a -doc package as well. Some lintian warnings are generated about the over abundance of sitemap files. Anyway my bug was more because I'd like the generated (and then uploaded) website to not link externally to begin with, but be self contained. That's an upstream issue. But I guess as a workaround I can upload the content of the -doc package instead, to make sure that nothing is loaded from other domains. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#1000576: xserver-xorg-input-all: Please include other input drivers in dependencies
To add more details, the kde touchpad config for libinput doesn't allow me to use 2 and 3 fingers touch for middle and right click. And the speed and acceleration of trackpoint can't be set as the same. Best Il gio 25 nov 2021, 11:06 Salvo "LtWorf" Tomaselli ha scritto: > Package: xserver-xorg-input-all > Version: 1:7.7+23 > Severity: critical > Justification: breaks unrelated software > X-Debbugs-Cc: tipos...@tiscali.it > > Dear Maintainer, > > because of libinput not behaving properly with my trackpoint, and the > maintainer > refusing to add the necessary configuration options to make it behave like > I > think it should behave, I never use the libinput driver and just remove it > in > favour of synaptics. > > However since xserver-xorg-input-all depends only on the libinput driver, > what > happens is that the entire desktop task gets uninstalled when doing this > operation, > which means that a lot of stuff that is completely unrelated and that I > need > gets removed as well. > > Please consider adding "| xserver-xorg-input-synaptics" in the dependency > field, > so that my desktop environment doesn't get removed when I try to use the > input > driver that works better for me. > > Best > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads) > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages xserver-xorg-input-all depends on: > ii xserver-xorg-input-libinput 1.2.0-1 > > Versions of packages xserver-xorg-input-all recommends: > ii xserver-xorg-input-wacom 0.34.99.1-1+b1 > > xserver-xorg-input-all suggests no packages. > > -- no debconf information >
Bug#998013: localslackirc: autopkgtest failure: Cannot find implementation or library stub for module named "typedload"
AFAIK they always run in the source directory, otherwise the error would be that make can't find a Makefile, rather than an issue with missing dependencies. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#989346: python3-setuptools: .exe files in .deb file
Package: python3-setuptools Version: 52.0.0-3 Severity: serious Justification: Policy 4.16 Tags: upstream Dear Maintainer, python3-setuptools is installing some weird .exe files. find /usr/ -name '*exe' /usr/lib/python3/dist-packages/setuptools/gui-64.exe /usr/lib/python3/dist-packages/setuptools/gui.exe /usr/lib/python3/dist-packages/setuptools/gui-32.exe /usr/lib/python3/dist-packages/setuptools/cli-64.exe /usr/lib/python3/dist-packages/setuptools/cli.exe /usr/lib/python3/dist-packages/setuptools/cli-32.exe You have a lintian override to silence the warning: # Source is included for these files, they can be built in Debian with the # mingw toolchain, and the are not shipped in the binary, so this is OK for # Debian. It is not worth repacking the tarball just for this. The lintian override suggests that the files are not included in the binary, which is false, so I guess you are not aware of their presence. I think easy fix to remove them from the binary. Best -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-setuptools depends on: ii python33.9.2-3 ii python3-distutils 3.9.2-1 ii python3-pkg-resources 52.0.0-3 python3-setuptools recommends no packages. Versions of packages python3-setuptools suggests: pn python-setuptools-doc -- no debconf information
Bug#978586: python3-pyqt5: There needs to be a py.typed file for pyi stubs to work
Package: python3-pyqt5 Version: 5.15.2+dfsg-1+b1 Severity: normal Tags: upstream Dear Maintainer, as it is, the pyi stubs shipped by the package are useless because a typed.py file needs to be present for mypy to take them into consideration. This is already done by upstream in several other python packages. So, this is an upstream bug, but since the fix is simply: touch /usr/lib/python3/dist-packages/PyQt5/py.typed it could be easy to make a temporary debian specific fix. Best -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pyqt5 depends on: ii libc6 2.31-6 ii libgcc-s1 10.2.1-1 ii libpython3.9 3.9.1-1 ii libqt5core5a [qtbase-abi-5-15-2] 5.15.2+dfsg-2 ii libqt5dbus5 5.15.2+dfsg-2 ii libqt5designer5 5.15.2-3 ii libqt5gui55.15.2+dfsg-2 ii libqt5help5 5.15.2-3 ii libqt5network55.15.2+dfsg-2 ii libqt5printsupport5 5.15.2+dfsg-2 ii libqt5test5 5.15.2+dfsg-2 ii libqt5widgets55.15.2+dfsg-2 ii libqt5xml55.15.2+dfsg-2 ii libstdc++610.2.1-1 ii python3 3.9.0-4 ii python3-pyqt5.sip 12.8.1-1+b2 python3-pyqt5 recommends no packages. Versions of packages python3-pyqt5 suggests: pn python3-pyqt5-dbg
Bug#885140: [pkg-wicd-maint] Bug#885140: Bug#885140: wicd: Depends on unmaintained pygtk
The one in experimental absolutely doesn't work for me. It doesn't list all of the networks for some reason, and can't connect. I'm using wpa_supplicant -Dwext and such at the moment. Il giorno gio 24 set 2020 alle ore 14:01 Joerg Dorchain ha scritto: > > Hello all, > > > On Sat, 28 Dec 2019 15:43:05 + Simon McVittie wrote: > > > The python-gtk dependency went away, so it's certainly true to say that > > the version in experimental no longer depends on the unmaintained package, > > which is what the submitter of #885140 wanted :-) > > > > just wondering, the version in experimental is more than a year old. Is > there a change to upload a more recent version of wicd? > > Bye, > > Joerg > > ___ > pkg-wicd-maint mailing list > pkg-wicd-ma...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-wicd-maint -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#908694: album-data: please remove dependency on libjs-swfobject, which is going away
You are very welcome to take over this. Il giorno mer 1 lug 2020 alle ore 20:59 David Ljung Madison ha scritto: > > I am the author of album / album-data > > > Is this being maintained anymore? If not, how can I take over the > maintenance of this package and/or find a Debian Maintainer who can? > > Because this dependency has not been removed, the package has > now been dropped. > > Dave > > --- > Dave Madison Stellarhttp://GetDave.com/415.341. > ------- -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#962646: cligh: Abandoned from upstream
Package: cligh Version: 0.3-3 Severity: important Dear Maintainer, cligh is an abandoned project by upstream. https://github.com/CMB/cligh/issues/16 Also, it is non functional in the case when one (like me) is using two factor authentication. https://github.com/CMB/cligh/issues/17 I would consider its removal from the archive. It has a low popcon so it should not be much of an issue. Best -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cligh depends on: ii python3 3.8.2-3 ii python3-github 1.43.7-1 ii python3-xdg 0.26-3 cligh recommends no packages. cligh suggests no packages. -- no debconf information
Bug#952068: Just fixed
fixed #952068 1.6-1 thanks I forgot to cite the bug in the changelog, so closing manually :( -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#951810: telegram-desktop: No more tray icon in Plasma
Package: telegram-desktop Version: 1.9.14+ds-1 Severity: important Dear Maintainer, Since this release in Plasma there is no longer a tray icon for telegram, so I can't know if there are pending messages or not just by seeing how the icon looks like. I suspect it is a debian issue, having seen the changelog, but I don't know enough to be sure. Best -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages telegram-desktop depends on: ii libavcodec58 7:4.2.2-1+b1 ii libavformat58 7:4.2.2-1+b1 ii libavutil56 7:4.2.2-1+b1 ii libc6 2.29-10 ii libdbusmenu-qt5-2 0.9.3+16.04.20160218-2+b1 ii libgcc-s1 10-20200211-1 ii liblz4-1 1.9.2-2 ii liblzma5 5.2.4-1+b1 ii libminizip1 1.1-8+b1 ii libopenal11:1.19.1-1+b1 ii libopus0 1.3-1+b1 ii libqrcodegencpp1 1.5.0-2 ii libqt5core5a [qtbase-abi-5-12-5] 5.12.5+dfsg-8 ii libqt5dbus5 5.12.5+dfsg-8 ii libqt5gui55.12.5+dfsg-8 ii libqt5network55.12.5+dfsg-8 ii libqt5widgets55.12.5+dfsg-8 ii librlottie0-1 0~git20190721.24346d0+dfsg-2+b1 ii libssl1.1 1.1.1d-2 ii libstdc++610-20200211-1 ii libswresample37:4.2.2-1+b1 ii libswscale5 7:4.2.2-1+b1 ii libx11-6 2:1.6.8-1 ii libxxhash00.7.2-1 ii qt5-image-formats-plugins 5.12.5-1 ii zlib1g1:1.2.11.dfsg-1.2 Versions of packages telegram-desktop recommends: ii fonts-open-sans 1.11-1 telegram-desktop suggests no packages. -- no debconf information
Bug#938281: python-xtermcolor: diff for NMU version 1.2.1-2.1
Thanks! I was planning to get around and do it before the next debian release :D Ciao Il giorno dom 6 ott 2019 alle ore 04:55 Sandro Tosi ha scritto: > > Control: tags 938281 + patch > Control: tags 938281 + pending > > > Dear maintainer, > > I've prepared an NMU for python-xtermcolor (versioned as 1.2.1-2.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. > > Regards. > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#941133: RM: speedpad -- ROM; python2 only, project abandoned
Package: ftp.debian.org Severity: normal
Bug#939510: upower.service: Failed to set up user namespacing: Invalid argument
Package: upower Version: 0.99.11-1 Severity: important Tags: patch Dear Maintainer, upon reboot I could not access my graphical session because upowerd was failing to be started by systemd. And apparently without it running sddm only shows garbage on screen. set 05 19:04:52 serenity systemd[1]: Stopped Daemon for power management. set 05 19:04:52 serenity systemd[1]: Starting Daemon for power management... set 05 19:04:52 serenity systemd[950]: upower.service: Failed to set up user namespacing: Invalid argument set 05 19:04:52 serenity systemd[950]: upower.service: Failed at step USER spawning /usr/lib/upower/upowerd: Invalid argument set 05 19:04:52 serenity systemd[1]: upower.service: Main process exited, code=exited, status=217/USER set 05 19:04:52 serenity systemd[1]: upower.service: Failed with result 'exit-code'. set 05 19:04:52 serenity systemd[1]: Failed to start Daemon for power management. set 05 19:04:53 serenity systemd[1]: upower.service: Service RestartSec=100ms expired, scheduling restart. set 05 19:04:53 serenity systemd[1]: upower.service: Scheduled restart job, restart counter is at 2. I have a long list of those. Commenting the user namespace directive solves the issue for me. Best -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages upower depends on: ii dbus 1.12.16-1 ii libc6 2.28-10 ii libglib2.0-0 2.60.6-2 ii libgudev-1.0-0 232-2 ii libimobiledevice6 1.2.1~git20181030.92c5462-1 ii libplist3 2.0.1~git20190104.3f96731-1 ii libupower-glib30.99.11-1 ii libusb-1.0-0 2:1.0.23-1 ii udev 242-7 Versions of packages upower recommends: ii policykit-1 0.105-26 upower suggests no packages. -- no debconf information 48c48 < PrivateUsers=yes --- > #PrivateUsers=yes
Bug#932042: [pkg-wicd-maint] Bug#932042: wicd-daemon: does not automatically reconnect on network connection loss when this is enabled
t; ii wicd-gtk [wicd-client] 1.7.4+tb2-6 > > Versions of packages wicd-daemon suggests: > pn pm-utils > > Versions of packages wicd depends on: > ii wicd-curses [wicd-client] 1.7.4+tb2-6 > ii wicd-gtk [wicd-client] 1.7.4+tb2-6 > > Versions of packages wicd-gtk depends on: > ii python 2.7.16-1 > ii python-glade2 2.24.0-6 > ii python-gtk22.24.0-6 > > Versions of packages wicd-gtk recommends: > ii menu 2.1.47+b1 > ii policykit-10.105-25 > ii python-notify 0.1.1-4 > > Versions of packages wicd-curses depends on: > ii python2.7.16-1 > ii python-urwid 2.0.1-2+b1 > > Versions of packages wicd-curses recommends: > ii sudo 1.8.27-1 > > Versions of packages python-wicd depends on: > ii net-tools 1.60+git20180626.aebd88e-1 > ii python 2.7.16-1 > > Versions of packages python-wicd suggests: > ii ethtool 1:4.19-1 > ii iproute2 5.2.0-1 > > -- Configuration Files: > /etc/wicd/encryption/templates/active changed: > wpa > wpa-peap > wpa-peap-wo-domain > wpa-psk > wpa-psk-hex > wpa2-leap > wpa2-peap > wpa2-peap-wo-domain > wep-hex > wep-passphrase > wep-shared > leap > ttls > eap > peap > peap-eduroam > peap-tkip > eap-tls > psu > > > -- debconf information: > * wicd/users: > > ___ > pkg-wicd-maint mailing list > pkg-wicd-ma...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-wicd-maint -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#930928: mypy: New upstream release
Oh I had no idea the new version is much different in the way it works. Yeah I guess experimental would work. Il giorno dom 23 giu 2019 alle ore 08:47 Michael Crusoe ha scritto: > > How about we start on the latest version via an upload to experimentsl? > > I must admit that I don't have a plan for the new compiled versions of mypy > yet. > > -- > Michael R. Crusoe > > On Sun, Jun 23, 2019, 01:21 Salvo Tomaselli wrote: >> >> Hello, >> >> I understand, but at this stage, with release almost there, uploading >> to unstable would not be so bad I guess. >> >> Anyway my problem is that localslackirc uses github and there it pulls >> mypy from pip (so latest version) but in debian of course it builds >> with the package, so having the mismatch is making development a bit >> difficult for me, because the build fails on github but works on my >> local machine, so adding a "ignore" comment would make it fail on my >> machine and pass on github :D >> >> Anyway, I guess I can wait some more weeks. >> >> Best >> >> Il giorno sab 22 giu 2019 alle ore 20:33 Michael Crusoe >> ha scritto: >> > >> > Hello, >> > >> > During a freeze I don't upload new versions to unstable. >> > >> > On Sat, Jun 22, 2019 at 6:51 PM Salvo Tomaselli >> > wrote: >> >> >> >> Package: mypy >> >> Version: 0.670-2 >> >> Severity: normal >> >> >> >> Dear Maintainer, >> >> >> >> there is a new upstream release for this. >> >> >> >> Could you upgrade? >> >> >> >> If needed, I can help. >> >> >> >> Best >> >> >> >> -- System Information: >> >> Debian Release: 10.0 >> >> APT prefers unstable >> >> APT policy: (500, 'unstable'), (500, 'testing') >> >> Architecture: amd64 (x86_64) >> >> Foreign Architectures: i386 >> >> >> >> Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT) >> >> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= >> >> (charmap=UTF-8) >> >> Shell: /bin/sh linked to /bin/dash >> >> Init: systemd (via /run/systemd/system) >> >> >> >> Versions of packages mypy depends on: >> >> ii python3 3.7.3-1 >> >> ii python3-mypy 0.670-2 >> >> >> >> mypy recommends no packages. >> >> >> >> Versions of packages mypy suggests: >> >> pn mypy-doc >> >> >> >> -- no debconf information >> >> >> > >> > >> > -- >> > Michael R. Crusoe >> > Co-founder & Lead, Common Workflow Language project >> > https://orcid.org/-0002-2961-9670 >> > m...@commonwl.org >> > +1 480 627 9108 >> >> >> >> -- >> Salvo Tomaselli >> >> "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di >> senso, ragione ed intelletto intendesse che noi ne facessimo a meno." >> -- Galileo Galilei >> >> http://ltworf.github.io/ltworf/ -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#930950: dh-python: Documentation unclear about requires.txt
Package: dh-python Version: 3.20190308 Severity: normal Dear Maintainer, from conversations on IRC it appears that the requires.txt which gets parsed must be located inside the egg. However the manpage does not mention this fact leading to the assumption that the simple file in the source package is enough. Can the documentation be edited to reflect this? Thanks -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dh-python depends on: ii python33.7.3-1 ii python3-distutils 3.7.3-1 dh-python recommends no packages. Versions of packages dh-python suggests: ii dpkg-dev 1.19.7 ii libdpkg-perl 1.19.7 -- no debconf information
Bug#930949: firefox: Firefox .desktop file should not be absolute
Package: firefox Version: 67.0.4-1 Severity: normal Dear Maintainer, I use firejail. Because firefox.desktop points directly to the binary, rather than just calling firefox from the path, I can't symlink firefox to firejail in /usr/local/bin like I do for everything else, because it won't work if I open it from a menu. It would be nice to fix the .desktop file to just execute "firefox %u" instead so that people who use firejail can use it without having to fix the .desktop file after every upgrade. Best -- Package-specific info: -- Addons package information -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox depends on: ii debianutils 4.8.6.1 ii fontconfig2.13.1-2 ii libasound21.1.8-1 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-1 ii libdbus-glib-1-2 0.110-4 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-9 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-7 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgtk-3-03.24.5-1 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.21-1 ii libnss3 2:3.44+really3.42.1-2 ii libpango-1.0-01.42.4-6 ii libsqlite3-0 3.27.2-3 ii libstartup-notification0 0.12-6 ii libstdc++68.3.0-7 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-shm0 1.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii procps2:3.3.15-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox recommends: ii libavcodec58 7:4.1.3-1 Versions of packages firefox suggests: ii fonts-lmodern 2.004.5-6 pn fonts-stix | otf-stix ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.17-3 ii libgtk2.0-02.24.32-3 pn pulseaudio -- no debconf information
Bug#930928: mypy: New upstream release
Hello, I understand, but at this stage, with release almost there, uploading to unstable would not be so bad I guess. Anyway my problem is that localslackirc uses github and there it pulls mypy from pip (so latest version) but in debian of course it builds with the package, so having the mismatch is making development a bit difficult for me, because the build fails on github but works on my local machine, so adding a "ignore" comment would make it fail on my machine and pass on github :D Anyway, I guess I can wait some more weeks. Best Il giorno sab 22 giu 2019 alle ore 20:33 Michael Crusoe ha scritto: > > Hello, > > During a freeze I don't upload new versions to unstable. > > On Sat, Jun 22, 2019 at 6:51 PM Salvo Tomaselli wrote: >> >> Package: mypy >> Version: 0.670-2 >> Severity: normal >> >> Dear Maintainer, >> >> there is a new upstream release for this. >> >> Could you upgrade? >> >> If needed, I can help. >> >> Best >> >> -- System Information: >> Debian Release: 10.0 >> APT prefers unstable >> APT policy: (500, 'unstable'), (500, 'testing') >> Architecture: amd64 (x86_64) >> Foreign Architectures: i386 >> >> Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT) >> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= >> (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> >> Versions of packages mypy depends on: >> ii python3 3.7.3-1 >> ii python3-mypy 0.670-2 >> >> mypy recommends no packages. >> >> Versions of packages mypy suggests: >> pn mypy-doc >> >> -- no debconf information >> > > > -- > Michael R. Crusoe > Co-founder & Lead, Common Workflow Language project > https://orcid.org/-0002-2961-9670 > m...@commonwl.org > +1 480 627 9108 -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#930928: mypy: New upstream release
Package: mypy Version: 0.670-2 Severity: normal Dear Maintainer, there is a new upstream release for this. Could you upgrade? If needed, I can help. Best -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mypy depends on: ii python3 3.7.3-1 ii python3-mypy 0.670-2 mypy recommends no packages. Versions of packages mypy suggests: pn mypy-doc -- no debconf information
Bug#930473: bsdgames: New wtf acronym makes no sense
I'd go for fsck or f*ck
Best
Il giorno gio 13 giu 2019 alle ore 13:30 Fabian Greffrath
ha scritto:
>
> Salvo Tomaselli wrote:
> > -WTF{what,where,who,why} the fuck
> > +WTFwhere's the food
>
> It's understandable that this was introduced to avoid using the f-word.
> How about replacing it with "frick" or "fsck" instead?
>
> - Fabian
>
>
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei
http://ltworf.github.io/ltworf/
Bug#930473: bsdgames: New wtf acronym makes no sense
Package: bsdgames
Version: 2.17-28
Severity: normal
Dear Maintainer,
The new acronym for wtf makes 0 sense.
It's introduced with this patch.
-WTF{what,where,who,why} the fuck
+WTFwhere's the food
Let's expand this:
wtf is lol → where is the food is lol.
Does it make sense? No.
Best
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to
it_IT.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bsdgames depends on:
ii libc6 2.28-10
ii libfl22.6.4-6.2
ii libgcc1 1:8.3.0-6
ii libncurses6 6.1+20181013-2
ii libstdc++68.3.0-6
ii libtinfo6 6.1+20181013-2
ii wamerican [wordlist] 2018.04.16-1
ii witalian [wordlist] 1.10
bsdgames recommends no packages.
bsdgames suggests no packages.
-- no debconf information
Bug#929315: docker.io: Please configure docker0 ip address and netmask at install time
Package: docker.io Version: 18.09.1+dfsg1-7~deb10u1 Severity: important Dear Maintainer, as it is, docker.io will automatically start and create a docker0 network interface with some hard-coded IP address, and there is no file in /etc that can be edited to change said IP address. One must look into the documentation, find out that a file called /etc/docker.daemon.json needs to be created, with a field called "bip", and have as value an ip/netmask. It is important because for some people (for example me) having an interface pop up with an hard coded address can cause collisions with existing routes and local network configuration. So ideally, this shouldbe configured at install time, like postfix-style, but at the very least, a configuration file that one can just edit should be in place. Of course the .json files do not allow for commments, so one should understand that "bip" stands for "bridge ip", but better than the current situation. Best -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages docker.io depends on: ii adduser 3.118 ii iptables1.8.2-4 ii libc6 2.28-10 ii libdevmapper1.02.1 2:1.02.155-2 ii libltdl72.4.6-9 ii libnspr42:4.20-1 ii libnss3 2:3.42.1-1 ii libseccomp2 2.3.3-4 ii libsystemd0 241-3 ii lsb-base10.2019031300 ii runc1.0.0~rc6+dfsg1-3 ii tini0.18.0-1 Versions of packages docker.io recommends: ii ca-certificates 20190110 ii cgroupfs-mount 1.4 ii git 1:2.20.1-2 ii needrestart 3.4-3 ii xz-utils 5.2.4-1 Versions of packages docker.io suggests: pn aufs-tools pn btrfs-progs ii debootstrap 1.0.114 pn docker-doc ii e2fsprogs1.44.5-1 pn rinse pn xfsprogs pn zfs-fuse | zfsutils -- no debconf information
Bug#928428: [pkg-wicd-maint] Bug#928428: unblock: [pre-approval] wicd/1.7.4+tb2-7
of
> DHCP,
> +-providing support for dhclient, dhcpcd, and pump. Wicd uses wpa_supplicant
> ++providing support for dhclient, dhcpcd5, and pump. Wicd uses wpa_supplicant
> + to handle all wireless encryption settings, and uses a template-based system
> + to create the configuration files used by wpa_supplicant. These templates
> + can be edited, and new templates can be created by the user and imported
> into
> +@@ -178,7 +178,7 @@
> + .BR mii-tool (8),
> + .BR ethtool (8),
> + .BR dhclient (8),
> +-.BR dhcpcd (8),
> ++.BR dhcpcd5 (8),
> + .BR pump (8).
> +
> +
> +--- a/wicd/wnettools.py
> b/wicd/wnettools.py
> +@@ -307,7 +307,7 @@
> + def get_client_name(cl):
> + """ Converts the integer value for a dhcp client to a string.
> """
> + if self.dhcpcd_cmd and cl in [misc.DHCPCD, misc.AUTO]:
> +-client = "dhcpcd"
> ++client = "dhcpcd5"
> + cmd = self.dhcpcd_cmd
> + elif self.pump_cmd and cl in [misc.PUMP, misc.AUTO]:
> + client = "pump"
> +@@ -344,7 +344,7 @@
> + 'release' : r"%(cmd)s -r -i %(iface)s",
> + 'id' : misc.PUMP,
> + },
> +-"dhcpcd" :
> ++"dhcpcd5" :
> + {'connect' : r"%(cmd)s --noipv4ll %(extra)s %(iface)s",
> + 'connect_with_hostname' : r"%(cmd)s -h %(hostname)s
> --noipv4ll %(extra)s %(iface)s ",
> + 'release' : r"%(cmd)s -k %(iface)s",
> +@@ -364,7 +364,7 @@
> + if client_name == "dhclient" and flavor:
> + if hostname:
> + print 'attempting to set hostname with dhclient'
> +-print 'using dhcpcd or another supported client may work
> better'
> ++print 'using dhcpcd5 or another supported client may work
> better'
> +
> + dhclient_template = \
> + open(os.path.join(wpath.etc, 'dhclient.conf.template'),
> 'r')
> +@@ -392,7 +392,7 @@
> + # set up (optional) extra arguments to the dhcp client,
> + # used for disabling the resolv.conf update of dhcpd
> + extra_args = ""
> +-if staticdns and client_name == "dhcpcd":
> ++if staticdns and client_name == "dhcpcd5":
> + extra_args = "--nohook resolv.conf"
> +
> + if hostname:
> +@@ -455,7 +455,7 @@
> + self.dhclient_needs_verbose = True
> + else:
> + self.dhclient_needs_verbose = False
> +-self.dhcpcd_cmd = self._find_program_path("dhcpcd")
> ++self.dhcpcd_cmd = self._find_program_path("dhcpcd5")
> + self.pump_cmd = self._find_program_path("pump")
> + self.udhcpc_cmd = self._find_program_path("udhcpc")
> +
> +@@ -599,10 +599,10 @@
> + return self._check_dhcp_result(pump_success)
> +
> + def _parse_dhcpcd(self, pipe):
> +-""" Determines if obtaining an IP using dhcpcd succeeded.
> ++""" Determines if obtaining an IP using dhcpcd5 succeeded.
> +
> + Keyword arguments:
> +-pipe -- stdout pipe to the dhcpcd process.
> ++pipe -- stdout pipe to the dhcpcd5 process.
> +
> + Returns:
> + 'success' if succesful, an error code string otherwise.
> +@@ -626,7 +626,7 @@
> + """ Determines if obtaining an IP using udhcpc succeeded.
> +
> + Keyword arguments:
> +-pipe -- stdout pipe to the dhcpcd process.
> ++pipe -- stdout pipe to the dhcpcd5 process.
> +
> + Returns:
> + 'success' if successful, an error code string otherwise.
> diff --git a/debian/patches/series b/debian/patches/series
> index 81a29b0..f82f16d 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -12,3 +12,4 @@
> 43-fix-wrong-Galician-translation.patch
> 44-fix_wicd-curses_AttributeError_in_keypress-function.patch
> 45-update_systemd_service_file.patch
> +46-dhcpcd_is_now_dhcpcd5.patch
>
> Regards, Axel
> --
> ,''`. | Axel Beckert , https://people.debian.org/~abe/
> : :' : | Debian Developer, ftp.ch.debian.org Admin
> `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
> `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
>
> ___
> pkg-wicd-maint mailing list
> pkg-wicd-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-wicd-maint
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei
http://ltworf.github.io/ltworf/
Bug#927983: chromium: "Open all" no longer works
Package: chromium Version: 74.0.3729.108-1 Severity: normal Dear Maintainer, middle clicking on a bookmark directory used to open all of the items in tabs. This no longer works. Also, right clicking and selecting "Open all" used to do the same. The menu is still there, but it does nothing. Best -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii chromium-common 74.0.3729.108-1 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatomic1 8.3.0-6 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.1.1-1 ii libavformat587:4.1.1-1 ii libavutil56 7:4.1.1-1 ii libc62.28-8 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.2.10-6 ii libdbus-1-3 1.12.12-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-1 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1 ii libopenjp2-7 2.3.0-2 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpci3 1:3.5.2-5 ii libpng16-16 1.6.36-6 ii libpulse012.2-4 ii libre2-5 20190101+dfsg-2 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-6 ii libva2 2.4.0-1 ii libvpx5 1.7.0-3 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 74.0.3729.108-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: ii chromium-sandbox74.0.3729.108-1 ii fonts-liberation1:1.07.4-9 ii libgl1-mesa-dri 18.3.6-1 pn libu2f-udev ii plasma-workspace [notification-daemon] 4:5.14.5.1-1 ii upower 0.99.10-1 Versions of packages chromium-sandbox depends on: ii libatomic1 8.3.0-6 ii libc6 2.28-8 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 -- no debconf information
Bug#743924: Should be more than minor
I just spent 1 hour trying to figure out why my printer was not working… because it uses an address that is on the same subnet as the docker0 interface… This automatic configuration breaks more than it fixes. I also get DNS resolution issues after installing docker, if I'm using dnsmasq. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#921990: mypy should depend on the precise version of python3-mypy
Package: mypy
Version: 0.670-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I upgraded mypy, python3-mypy did not get pulled in as dependency so it remained
as the old version.
This is what happens when I ran it.
$ mypy
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 581, in
_build_master
ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 898, in
require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 789, in
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (mypy 0.660 (/usr/lib/python3/dist-packages),
Requirement.parse('mypy==0.670'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/mypy", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3126,
in
@_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3110,
in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3139,
in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in
_build_master
return cls._build_from_requirements(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 596, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 784, in
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'mypy==0.670' distribution was not
found and is required by the application
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mypy depends on:
ii python3 3.7.2-1
ii python3-mypy 0.660-5
mypy recommends no packages.
Versions of packages mypy suggests:
pn mypy-doc
-- no debconf information
Bug#876556: link
Forgot the link https://bugzilla.redhat.com/show_bug.cgi?id=1509017 The upstream developer doesn't seem to care about reverting the change that broke it. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#876556: link to fedora, more info and raise prio
severity grave 876556 thanks Fedora closed this issue without resolving it. Raising this issue since the release is getting close and all thinkpads are unusable by default, and this seems to be getting ignored. The current fix is to remove xserver-xorg-input-libinput and install synaptic instead. I installed buster yesterday, the issue is still present: the mouse moves erratically and it's unusable. Best -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#919860: qtcreator: Probably missing clang dependency
But I changed a number of keybindings! Il giorno lun 21 gen 2019 alle ore 17:50 Lisandro Damián Nicanor Pérez Meyer ha scritto: > > tag 919860 unreproducible moreinfo > thanks > > Hi Salvo! > > El domingo, 20 de enero de 2019 05:52:47 -03 Salvo Tomaselli escribió: > > Package: qtcreator > > Version: 4.8.1-1 > > Severity: important > > > > Dear Maintainer, > > > > I tried the newly packaged version. > > > > The code warnings in the editor kept appearing and disappearing, CPU usage > > went at 100% > > > > In the General messages tab, this was printed, over and over > > > > 2019-01-20T09:48:39 Clang Code Model: Error: The clangbackend process has > > finished unexpectedly and was restarted. 2019-01-20T09:48:40 Clang Code > > Model: Error: The clangbackend process has finished unexpectedly and was > > restarted. > [snip] > > That's definitely interesting. I could not reproduce this behavior but I do > have some ideas of what could be wrong. > > I don't think anything clang/llvm is missing as a dependency, but in the > latest upload I disabled some experimental plugins that I should not have > enabled in the first place. If you enabled them maybe that could be causing > the crash. > > Please try either: > > - Trying with a new user. > - Moving creator's config away from ~/.config. This is more involved, as it's > not just one file: > > ~/.config/QtCreatorrc > ~/.config/QtProject/* > > Of course this needs to be done without Qt creator running. > > In both cases do not enable any clang plugin not already enabled by default. > > > Thanks, Lisandro. > > -- > Hacer algo siempre te llevará más tiempo del que esperabas, incluso si > tienes en cuenta la ley de Hofstadter. > Douglas Hofstadter > http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/ > > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#919860: qtcreator: Probably missing clang dependency
Package: qtcreator Version: 4.8.1-1 Severity: important Dear Maintainer, I tried the newly packaged version. The code warnings in the editor kept appearing and disappearing, CPU usage went at 100% In the General messages tab, this was printed, over and over 2019-01-20T09:48:39 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:40 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:41 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:41 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:42 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:43 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:44 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:46 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:47 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:48 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:49 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. 2019-01-20T09:48:50 Clang Code Model: Error: The clangbackend process has finished unexpectedly and was restarted. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qtcreator depends on: ii libbotan-2-9 2.9.0-2 ii libc6 2.28-5 ii libclang1-71:7.0.1-4 ii libgcc11:8.2.0-14 ii libgl1 1.1.0-1 ii libllvm7 1:7.0.1-4 ii libqbscore1.12 1.12.2+dfsg-2 ii libqbsqtprofilesetup1.12 1.12.2+dfsg-2 ii libqt5concurrent5 5.11.3+dfsg-2 ii libqt5core5a [qtbase-abi-5-11-3] 5.11.3+dfsg-2 ii libqt5designer55.11.3-4 ii libqt5designercomponents5 5.11.3-4 ii libqt5gui5 5.11.3+dfsg-2 ii libqt5help55.11.3-4 ii libqt5network5 5.11.3+dfsg-2 ii libqt5printsupport55.11.3+dfsg-2 ii libqt5qml5 [qtdeclarative-abi-5-11-2] 5.11.3-2 ii libqt5quick5 5.11.3-2 ii libqt5quickwidgets55.11.3-2 ii libqt5script5 5.11.3+dfsg-2 ii libqt5serialport5 5.11.3-2 ii libqt5sql5 5.11.3+dfsg-2 ii libqt5sql5-sqlite 5.11.3+dfsg-2 ii libqt5widgets5 5.11.3+dfsg-2 ii libqt5xml5 5.11.3+dfsg-2 ii libstdc++6 8.2.0-14 ii qml-module-qtqml-models2 5.11.3-2 ii qml-module-qtquick-controls5.11.3-2 ii qml-module-qtquick25.11.3-2 ii qtchooser 66-1 ii qtcreator-data 4.8.1-1 Versions of packages qtcreator recommends: pn clang ii gdb-minimal [gdb] 8.2-1 ii konsole [x-terminal-emulator] 4:18.04.0-1 ii make 4.2.1-1.2 ii qmlscene 5.11.3-2 pn qt5-doc ii qt5-qmltooling-plugins 5.11.3-2 ii qtbase5-dev-tools 5.11.3+dfsg-2 pn qtcreator-doc ii qtdeclarative5-dev-tools 5.11.3-2 ii qttools5-dev-tools 5.11.3-4 pn qttranslations5-l10n pn qtxmlpatterns5-dev-tools ii xterm [x-terminal-emulator]343-1 Versions of packages qtcreator suggests: pn clazy ii cmake 3.13.2-1 ii g++ 4:8.2.0-2 ii git 1:2.20.1-1 pn kate-data pn subversion ii valgrind1:3.14.0-2 -- no debconf information
Bug#917120: lintian: Lintianrc should contain valid configuration
# Also note, that this file uses a special syntax: # Empty lines are allowed, comments are introduced by a hash sign (#). # All other lines must have the format #VAR=text # or #VAR="text" # It is allowed to use `~' and `$HOME' in the variables, but not other # shell/environment variables. # Enable info tags by default (--display info) #display-info = yes # Limit the number of parallel unpacking jobs to X (--jobs) #jobs = 8 # Enable pedantic tags by default (--pedantic) #pedantic = yes In the example syntax, spaces do not seem to be allowed. Il giorno dom 23 dic 2018 alle ore 01:00 Chris Lamb ha scritto: > > Hi Salvo, > > > No error message, just that the comment at the top of the file states > > that var assignments should have no spaces, and then all the example > > assignments have spaces. > > I don't see any reference to spaces being illegal in this file. Please > could you copy-paste what you are seeing? I'm struggling to see what > the bug is here and we appear to be making a number of unnecessary > round-trips. :) > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#917120: lintian: Lintianrc should contain valid configuration
No error message, just that the comment at the top of the file states that var assignments should have no spaces, and then all the example assignments have spaces. Unless I am misinterpreting the meaning of the comment, but the example syntax there has no spaces. Il giorno dom 23 dic 2018 alle ore 00:24 Chris Lamb ha scritto: > > tags 917120 + moreinfo > thanks > > Hi Salvo, > > > According to the comments at the beginning of the file, /etc/lintianrc uses > > shell syntax (it gets sourced I presume). > > Hm? It's not shell, it's parsed with: > > > https://salsa.debian.org/lintian/lintian/blob/master/commands/lintian.pm#L1240 > > > It would be better if people could just uncomment, rather than needing to > > fix > > the syntax as well. > > What error message(s) are you seeing, specifically? > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#917120: lintian: Lintianrc should contain valid configuration
Package: lintian Version: 2.5.117 Severity: wishlist Dear Maintainer, According to the comments at the beginning of the file, /etc/lintianrc uses shell syntax (it gets sourced I presume). However all the later commented example options do not use said valid syntax. It would be better if people could just uncomment, rather than needing to fix the syntax as well. Best -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.16 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.31.1-11 ii bzip2 1.0.6-9 ii diffstat 1.62-1 ii dpkg 1.19.2 ii dpkg-dev 1.19.2 ii file 1:5.34-2 ii gettext0.19.8.1-9 ii gpg2.2.12-1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 pn libdigest-sha-perl ii libdpkg-perl 1.19.2 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.75+repack-1 ii man-db 2.8.4-3 ii patchutils 0.3.4-2 ii perl 5.28.1-3 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 pn libtext-template-perl -- no debconf information
Bug#916404: steam: Depend or at least suggest vulkan
Package: steam Version: 1.0.0.56-1 Severity: important Dear Maintainer, I could not play "Artifact" on linux… because I was lacking the vulkan drivers for intel. mesa-vulkan-drivers I think steam should depend on it since they are pushing games to use vulkan rather than opengl. Or at least recommend it. Best -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages steam depends on: ii debconf [debconf-2.0]1.5.69 ii libc62.28-2 ii libgl1-mesa-dri 18.2.6-1 ii libgl1-mesa-glx 18.2.6-1 ii libgpg-error01.32-3 ii libstdc++6 8.2.0-12 ii libtxc-dxtn-s2tc [libtxc-dxtn0] 1.0+git20151227-2 ii libudev1 239-15 ii libx11-6 2:1.6.7-1 ii libxinerama1 2:1.1.4-1 ii xz-utils 5.2.2-1.3 Versions of packages steam recommends: ii ca-certificates20180409 ii fontconfig 2.13.1-2 ii fonts-liberation 1:1.07.4-9 ii konsole [x-terminal-emulator] 4:18.04.0-1 ii libxss11:1.2.3-1 pn nvidia-driver-libs-i386 Versions of packages steam suggests: pn steam-devices -- debconf information excluded
Bug#916280: typedload: build dependency on mypy is too strict
You are right that it's not ideal. However it is because every single new version of mypy changes something, so they fix a false positive and fail because I had a "# type: ignore" tag or they introduce some new false positive. So in practice it never happens that the build works when changing mypy version, since it runs tests during the build. Il giorno mer 12 dic 2018 alle ore 16:06 Adrian Bunk ha scritto: > > Source: typedload > Version: 1.10-2 > Severity: serious > > Build-Depends: ..., mypy (= 0.641-1) > > If there is some tight interdependency between typedload and mypy, > then this should be expressed properly with a set of >= and <= > dependencies. > > In any case a build dependency on the exact Debian revision > of another package seems far too strict. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#915090: plasma-wallpapers-addons: No providers for picture of the day
Package: plasma-wallpapers-addons Version: 4:5.13.5-1 Severity: normal Dear Maintainer, There are no providers defined for the picture of the day, so it's impossible to use it, and that's more or less the only thing that this package provies, so it is kinda useless at the moment. Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-wallpapers-addons depends on: ii kdeplasma-addons-data 4:5.13.5-1 ii plasma-framework 5.49.0-1 plasma-wallpapers-addons recommends no packages. plasma-wallpapers-addons suggests no packages. -- no debconf information
Bug#913116: chromium
If it can't start without it, it really should depend on it -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#913192: qtwebengine5-examples: Instructions on how to compile the examples must be provided
Package: qtwebengine5-examples Severity: grave Justification: renders package unusable Dear Maintainer, this packages provides source examples, and a binary that supposedly is compiled from them. However, there is no README, the usual qmake . && make won't work. So a package with examples that I can't compile is not useful. Can you provide a README to explain what the necessary steps are? Since the standard steps do not work. Best -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.16 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qtwebengine5-examples depends on: ii libc62.27-7 ii libjs-jquery 3.2.1-1 pn libjs-marked ii libqt5core5a 5.11.2+dfsg-4 ii libqt5gui5 5.11.2+dfsg-4 ii libqt5network5 5.11.2+dfsg-4 ii libqt5qml5 5.11.2-2 ii libqt5quickcontrols2-5 5.11.2-2 ii libqt5webchannel55.11.2-2 pn libqt5webengine5 ii libqt5webenginecore5 5.11.2+dfsg-2 ii libqt5webenginewidgets5 5.11.2+dfsg-2 ii libqt5widgets5 5.11.2+dfsg-4 ii libstdc++6 8.2.0-9 ii qml-module-qt-labs-settings 5.11.2-2 ii qml-module-qtquick-controls 5.11.2-2 ii qml-module-qtquick-layouts 5.11.2-2 ii qml-module-qtquick-window2 5.11.2-2 pn qml-module-qtwebengine pn qtwebengine5-dev-tools qtwebengine5-examples recommends no packages. qtwebengine5-examples suggests no packages.
Bug#912587: apparmor makes dmesg useless
Normally, this 1424:salvo::/usr/bin/firejail /usr/bin/telegram-desktop -- 2205:salvo::/usr/bin/firejail /usr/bin/chromium 5684:salvo::/usr/bin/firejail /usr/games/steam -tcp I am however questioning the design decision of having those audit logs in the kernel logs, since they push out the interesting logs, and every failure seems to be logged. If they are so important, why log them in a place where having so many of them will delete the older ones? How do i reload after changing an apparmor profile? Il giorno gio 1 nov 2018 alle ore 18:22 Reiner Herrmann ha scritto: > > On Thu, Nov 01, 2018 at 06:13:02PM +0100, Reiner Herrmann wrote: > > Do you see anything in the profile that looks wrong and could be causing > > those logs when it is loaded by firejail? > > I just saw that the firejail-default AppArmor profile contains the > following: > > > ## > > # With ptrace it is possible to inspect and hijack running programs. > > # Usually this > > # is needed only for debugging. To allow ptrace, uncomment the following > > # line. > > ## > > #ptrace, > > @Salvo, do you still see the logs, when you uncomment ptrace here and > reload it? > > Regards, > Reiner -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#912587: apparmor makes dmesg useless
Source: apparmor Severity: important Dear Maintainer, when apparmor is installed, it emits an incredible amount of logs on dmesg, causing actual important stuff from the kernel to be missed. By incredible amount I mean that it fills completely the ring buffer with crap. Should it even be logging on dmesg? Imagine dmesg, only filled of this: [299560.719237] audit: type=1400 audit(1541071734.314:10526): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="read" denied_mask="read" peer="firejail-default" [299560.719241] audit: type=1400 audit(1541071734.314:10527): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="readby" denied_mask="readby" peer="firejail-default" [299560.921678] audit: type=1400 audit(1541071734.518:10528): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=13691 comm="TaskSchedulerSi" requested_mask="read" denied_mask="read" peer="firejail-default" For now my solution is to remove apparmor, but it gets sometimes pulled in again by other things. Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#911287: polipo: Dependency on dnsmasq
Package: polipo Version: 1.1.1-10 Severity: normal Dear Maintainer, I suppose that what you actually want is the dnsmasq binary, not the installed service, in this case you should depend on dnsmasq-base. If I'm wrong, feel free to close this. Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages polipo depends on: ii libc6 2.27-6 ii lsb-base 9.20170808 Versions of packages polipo recommends: pn dnsmasq | pdnsd | unbound ii python 2.7.15-3 polipo suggests no packages.
Bug#901013: Is this abandoned
Is this package unmaintained/abandoned? I could take it… -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#910343: cowsay-off: What's the point of cowsay-off if you remove offensive ones?
Package: cowsay-off Version: 3.03+dfsg2-5 Severity: grave Justification: renders package unusable Dear Maintainer, what is even the point of this package existing if the offensive ascii arts are removed? Please just drop this. Best -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cowsay-off depends on: ii cowsay 3.03+dfsg2-5 cowsay-off recommends no packages. cowsay-off suggests no packages. -- no debconf information
Bug#910003: localslackirc: wtf debian!
Package: localslackirc Version: 1.2-1 Severity: normal Dear Maintainer, Got this email: localslackirc 1.1-1 is marked for autoremoval from testing on 2018-10-31 It (build-)depends on packages with these RC bugs: 869896: backports.ssl-match-hostname: backports.ssl-match-hostname should be removed for buster 909973: websocket-client: remove unneeded dependency on backports.ssl-match-hostname -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages localslackirc depends on: ii python33.6.6-1 ii python3-requests 2.18.4-2 ii python3-typedload 1.10-1 ii python3-websocket 0.48.0-1 localslackirc recommends no packages. localslackirc suggests no packages. -- no debconf information
Bug#909068: mypy: Crash
Package: mypy
Version: 0.630-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
$ mypy
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 578, in
_build_master
ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 895, in
require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (mypy-extensions 0.5.0.dev0
(/usr/lib/python3/dist-packages),
Requirement.parse('mypy_extensions<0.5.0,>=0.4.0'), {'mypy'})
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/mypy", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3105,
in
@_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3089,
in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3118,
in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 580, in
_build_master
return cls._build_from_requirements(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 593, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 781, in
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'mypy_extensions<0.5.0,>=0.4.0'
distribution was not found and is required by mypy
Best
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mypy depends on:
ii python3 3.6.6-1
ii python3-mypy 0.630-1
mypy recommends no packages.
Versions of packages mypy suggests:
pn mypy-doc
-- no debconf information
Bug#908051: sysstat: Redirect output for all commands
Package: sysstat Version: 12.0.1-1 Severity: normal Dear Maintainer, in the crontab file, only half of the commands are redirected, while the others aren't. When running cron without an MTA, that makes those commands fail. Perhaps running them all with a redirection would be a good idea. Otherwise, the package must depend on an MTA. Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sysstat depends on: ii debconf [debconf-2.0] 1.5.69 ii libc6 2.27-5 ii libsensors41:3.4.0-4 ii lsb-base 9.20170808 ii ucf3.0038 ii xz-utils 5.2.2-1.3 Versions of packages sysstat recommends: ii cron [cron-daemon] 3.0pl1-130 Versions of packages sysstat suggests: pn isag -- debconf information: sysstat/remove_files: true sysstat/enable: false
Bug#906626: mypy failure
Hello, thanks for your report. It is indeed failing to build, due to a newer version of mypy that fails. I suspect this is actually an issue with mypy, See this example NONETYPE = type(None) def f(a) -> None: if type(a) == NONETYPE: pass I will contact the mypy upstream about this. But I intend to make a typedload update to workaround this. Best -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#905021: ITP: localslackirc -- IRC gateway for slack
Package: wnpp Severity: wishlist Owner: Salvo Tomaselli * Package name: localslackirc Version : 1.0-1 Upstream Author : Salvo 'LtWorf' Tomaselli * URL : https://github.com/ltworf/localslackirc/ * License : GPL Programming Lang: Python Description : IRC gateway for slack, running on localhost for one user . This project is a replacement for slack's IRC gateway that they dropped. . One instance of localslackirc connects to one slack account and one IRC client, passing the messages between the two. #localslackirc on oftc I develop this package, and I am aware of a few people using it (though I don't know how many of them use Debian or a derivative).
Bug#904135: ITP: pysttrafik -- Public transport client, for the Västra Götaland county
Package: wnpp Severity: wishlist Owner: Salvo Tomaselli * Package name: pysttrafik Version : 1.0 Upstream Author : Salvo 'LtWorf' Tomaselli Name * URL : https://github.com/ltworf/pysttrafik * License : GPL Programming Lang: Python3 Description : Public transport client, for the Västra Götaland county Västtrafik is the agency for public transport in Västra Götaland (Sweden). . This package provies a CLI to access their API and plan trips or see the incoming vehicles at a given stop. The package is nice to use, since the web client is very heavy and slow. I made it, I use it, I saw some activity on github but since it required getting your own API key, it never became mainstream. Now they changed how API keys are managed, so one user can get more keys, per application, so I can publish the key and the software no longer requires creating an account. It is only useful in the specific area where västtrafik operates, but after a discussion on the mentors IRC channels, it seems that it might be good to include this in Debian.
Bug#900533: Bug still exists
Chromium works for me, both testing and unstable.
Il 06 Lug 2018 09:42, "Marco Fleckinger" ha
scritto:
> As mentioned the bug still exists in chromium 67.0.3396.87 from the Debian
> Repo. I setup a totally fresh VM for this purpose running stretch.
>
> There I downloaded the source and compiled following the instructions at
> [1]. Upstream Chromium 69 worked fine so I tried to compile the exact same
> version as installed by APT on my notebook 67.0.3396.87 including [2] into
> my workflow.
>
> The 67.0.3396.87 version from upstream didn't have the issue. For testing
> I used a plain mp3 served by python's SimpleHTTPServer:
>
> python -m SimpleHTTPServer
>
> First I always had the sandbox issue, I could start the upstream-versions
> only with --no-sandbox. Afterwards I tried to also compile the sandbox and
> start chromium using the wrapper. But this should not be relevant here
>
> Then I found out that the error also occurs when I used the Debian Package
> on my dedicated VM. After runnig it via CLI I also got this Error Message:
>
> [2693:2708:0705/212253.877035:ERROR:render_media_log.cc(30)] MediaEvent:
> MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: open context failed"}
> [2693:2693:0705/212253.877203:ERROR:render_media_log.cc(30)] MediaEvent:
> PIPELINE_ERROR DEMUXER_ERROR_COULD_NOT_OPEN
>
> [1] https://github.com/chromium/chromium/blob/master/docs/README.md
> [2] https://www.chromium.org/developers/how-tos/get-the-code/
> working-with-release-branches
> [3] https://unix.stackexchange.com/questions/68832/what-does-the
> -chromium-option-no-sandbox-mean#answer-105126
>
> Marco
>
> --
> To unsubscribe, send mail to 900533-unsubscr...@bugs.debian.org.
>
Bug#900533: Bug still exists
Chromium works for me, both testing and unstable.
Il 06 Lug 2018 09:42, "Marco Fleckinger" ha
scritto:
> As mentioned the bug still exists in chromium 67.0.3396.87 from the Debian
> Repo. I setup a totally fresh VM for this purpose running stretch.
>
> There I downloaded the source and compiled following the instructions at
> [1]. Upstream Chromium 69 worked fine so I tried to compile the exact same
> version as installed by APT on my notebook 67.0.3396.87 including [2] into
> my workflow.
>
> The 67.0.3396.87 version from upstream didn't have the issue. For testing
> I used a plain mp3 served by python's SimpleHTTPServer:
>
> python -m SimpleHTTPServer
>
> First I always had the sandbox issue, I could start the upstream-versions
> only with --no-sandbox. Afterwards I tried to also compile the sandbox and
> start chromium using the wrapper. But this should not be relevant here
>
> Then I found out that the error also occurs when I used the Debian Package
> on my dedicated VM. After runnig it via CLI I also got this Error Message:
>
> [2693:2708:0705/212253.877035:ERROR:render_media_log.cc(30)] MediaEvent:
> MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: open context failed"}
> [2693:2693:0705/212253.877203:ERROR:render_media_log.cc(30)] MediaEvent:
> PIPELINE_ERROR DEMUXER_ERROR_COULD_NOT_OPEN
>
> [1] https://github.com/chromium/chromium/blob/master/docs/README.md
> [2] https://www.chromium.org/developers/how-tos/get-the-code/
> working-with-release-branches
> [3] https://unix.stackexchange.com/questions/68832/what-does-the
> -chromium-option-no-sandbox-mean#answer-105126
>
> Marco
>
> --
> To unsubscribe, send mail to 900533-unsubscr...@bugs.debian.org.
>
Bug#737395: not possible to fix this
After some investigation, it seems that it is not possible to fix this in a proper way. The only solution I see is to do something illegal and just re-assign the copyright, in hope that no original author will ever do anything about that. But the original authors all seem to be impossible to contact. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#901601: python3-venv: Please remove python3-venv from archive
Package: python3-venv Version: 3.6.5-3 Severity: grave Justification: renders package unusable Dear Maintainer, the manpage for the module states: > pyvenv-3.3 - create virtual python environments However, currently, it can't do that because of this: > The virtual environment was not created successfully because ensurepip is not > available. On Debian/Ubuntu systems, you need to install the python3-venv > package using the following command. > > apt-get install python3-venv > > You may need to use sudo with that command. After installing the python3-venv > package, recreate your virtual environment. But the issue is tagged as wontfix here: #816740 This means that the package is and will forever be totally useless, since it is meant to create virtual environments and it cannot do so. So please just drop it from archive, because there is no point in it existing. Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-venv depends on: ii python33.6.5-3 ii python3-distutils 3.6.5-4 ii python3.6-venv 3.6.6~rc1-1 python3-venv recommends no packages. python3-venv suggests no packages. -- no debconf information
Bug#248496: raise priority
It does something bad with the X11 protocol, but I don't know anything
about it so I can't debug it.
I just see from strace a bunch of recvmsg(3, {msg_namelen=0}, 0)
= -1 EAGAIN (Resource temporarily unavailable) soon after the
socket to Xorg is opened.
Il giorno dom 3 giu 2018 alle ore 14:03 Markus Koschany
ha scritto:
>
> Am 03.06.2018 um 13:57 schrieb Salvo Tomaselli:
> > Well it had been open for over 10 years with 0 activity nor request
> > for more details, you only woke up because I raised priority, but are
> > not willing to take the package, a package that for me should be
> > removed.
>
> It has been working for the majority of users for the past ten years,
> that's why nobody raised the severity in the past. As long as you don't
> provide proper information to debug this issue nobody will be able to
> help you. Just removing a package is an extremely poor solution.
>
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei
http://ltworf.github.io/ltworf/
Bug#248496: raise priority
Well it had been open for over 10 years with 0 activity nor request for more details, you only woke up because I raised priority, but are not willing to take the package, a package that for me should be removed. Il giorno dom 3 giu 2018 alle ore 13:34 Markus Koschany ha scritto: > > Am 03.06.2018 um 13:33 schrieb Salvo Tomaselli: > > Debian sid, x86_64 up to date. Intel video card, not that it matters. > > It does matter. But with such poor bug reports this issue will never be > fixed for you. > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#248496: raise priority
Debian sid, x86_64 up to date. Intel video card, not that it matters. Il 03 Giu 2018 12:14, "Markus Koschany" ha scritto: > Am 03.06.2018 um 09:15 schrieb Salvo Tomaselli: > > It does not work for me, same thing as what the bugreport has, since > > over 10 years… > > We need more information if we want to tackle the problem. > > What Debian are you running? What architecture, desktop environment, X > server and graphics driver do you use? Add everything that might be > interesting to this bug report. Without those information it is very > hard to debug the problem. > > Markus > >
Bug#248496: raise priority
It does not work for me, same thing as what the bugreport has, since over 10 years… Il giorno sab 2 giu 2018 alle ore 15:17 Markus Koschany ha scritto: > > Control: severity -1 normal > Control: tags -1 moreinfo > > On Sat, 2 Jun 2018 12:18:22 +0200 Salvo Tomaselli > wrote: > > severity 248496 grave > > thanks > > > > Raising priority, since the game does not run at all and the package > > seems completely abandoned. > > > > If I'm right, the package will eventually just be dropped. > > Hello, > > the game works for me on amd64 and i386 in Sid. I cannot confirm that > the game is unusable for the majority of users hence I think severity > grave is not justified in this case. > > Please note that the package has been orphaned. It simply needs a new > maintainer. > > https://bugs.debian.org/869291 > > Regards, > > Markus > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#248496: raise priority
severity 248496 grave thanks Raising priority, since the game does not run at all and the package seems completely abandoned. If I'm right, the package will eventually just be dropped. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#895158: ITP: typedload -- Python3 module to load and dump data into typed structures
Package: wnpp Owner: Salvo Tomaselli <tipos...@tiscali.it> Severity: wishlist * Package name: typedload Version : 0.9 Upstream Author : Salvo 'LtWorf' Tomaselli <tipos...@tiscali.it> * URL : https://github.com/ltworf/typedload#typedload * License : GPL Programming Lang: Python Description : Python3 module to load and dump data into typed structures This module provides an API to load dictionaries and list (usually loaded from json) into Python's NamedTuples, sets, enums, and various other typed data structures. . It also allows one to dump them from typed data structures to json-like dictionaries and lists. . This allows all the code that uses external data to have the advantages of using types, and causes all errors with the data to be noticed when it is loaded, rather than when it is used. - why is this package useful/relevant? I found some people on stack overflow and similar, trying to obtain this, and implementing hacky solutions that only support very very simple types. This library supports quite a few combinations of types. - is it a dependency for another package? Not for now, it's quite new - do you use it? yes - if there are other packages providing similar functionality, how does it compare? Not that I know of. - how do you plan to maintain it? Github, for both packaging and upstream code. Anyone interested in co-maintaining can ask me to give write rights (after sending some good patches, normally) -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#895024: Error: bad hour; while reading /etc/crontab makes the cron do nothing
Package: cron Version: 3.0pl1-130 Severity: normal Tags: upstream Dear Maintainer, I had made a mistake while writing crontab, and had reversed hours and minutes. This happened: Error: bad hour; while reading /etc/crontab Hoewver, cron then doesn't run any job at all. In this case it should just terminate with error, so I would see that the service is not running at all. Keeping running but being in an error state and doing nothing is not very ideal, just makes it harder to find what is happening. -- Package-specific info: --- EDITOR: --- /usr/bin/editor: /usr/bin/vim.basic --- /usr/bin/crontab: -rwxr-sr-x 1 root crontab 39352 Mar 12 22:00 /usr/bin/crontab --- /var/spool/cron: drwxr-xr-x 5 root root 4096 Oct 24 09:56 /var/spool/cron --- /var/spool/cron/crontabs: drwx-wx--T 2 root crontab 4096 May 3 2015 /var/spool/cron/crontabs --- /etc/cron.d: drwxr-xr-x 2 root root 4096 Mar 19 10:32 /etc/cron.d --- /etc/cron.daily: drwxr-xr-x 2 root root 4096 Mar 27 09:50 /etc/cron.daily --- /etc/cron.hourly: drwxr-xr-x 2 root root 4096 Mar 19 10:32 /etc/cron.hourly --- /etc/cron.monthly: drwxr-xr-x 2 root root 4096 Mar 19 10:32 /etc/cron.monthly --- /etc/cron.weekly: drwxr-xr-x 2 root root 4096 Mar 19 10:32 /etc/cron.weekly -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cron depends on: ii adduser 3.117 ii debianutils 4.8.4 ii dpkg1.19.0.5 ii libc6 2.27-3 ii libpam-runtime 1.1.8-3.7 ii libpam0g1.1.8-3.7 ii libselinux1 2.7-2+b2 ii lsb-base9.20170808 Versions of packages cron recommends: ii postfix [mail-transport-agent] 3.3.0-1 Versions of packages cron suggests: pn anacron pn checksecurity ii logrotate 3.11.0-0.1 Versions of packages cron is related to: pn libnss-ldap pn libnss-ldapd pn libpam-ldap pn libpam-mount pn nis pn nscd -- Configuration Files: /etc/crontab changed [not included] -- no debconf information
Bug#894792: man-db: Permission denied running man as root
Here it is 2018-04-04 13:06 GMT+02:00 Colin Watson <cjwat...@debian.org>: > On Wed, Apr 04, 2018 at 12:27:29PM +0200, Salvo Tomaselli wrote: >> running man as root, while current working directory is inside the >> home of a different user, this happens: >> >> root@mongibello /home/salvo # man man >> man: can't change directory to '/home/salvo': Permesso negato >> man: comando terminato con stato d'uscita 159: /usr/lib/man-db/zsoelim | >> /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e >> UTF-8 | tbl | nroff -mandoc -rLL=178n -rLT=178n -c -Tutf8 > > I believe I have a fix for this. However, I can't reproduce the > problem, so I'd like to collect more information in order to make sure > that I've really fixed it. Could you please run "strace -f -o > /root/man.trace -s 1024 man man" in the same environment, and attach the > resulting /root/man.trace file? > > Thanks, > > -- > Colin Watson [cjwat...@debian.org] -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/ man.trace.bz2 Description: application/bzip
Bug#894792: man-db: Permission denied running man as root
Package: man-db Version: 2.8.2-1 Severity: normal Dear Maintainer, running man as root, while current working directory is inside the home of a different user, this happens: root@mongibello /home/salvo # man man man: can't change directory to '/home/salvo': Permesso negato man: comando terminato con stato d'uscita 159: /usr/lib/man-db/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | nroff -mandoc -rLL=178n -rLT=178n -c -Tutf8 Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages man-db depends on: ii bsdmainutils 11.1.2 ii debconf [debconf-2.0] 1.5.66 ii dpkg 1.19.0.5 ii groff-base 1.22.3-10 ii libc6 2.27-3 ii libgdbm5 1.14.1-6 ii libpipeline1 1.5.0-1 ii libseccomp22.3.1-2.1 ii zlib1g 1:1.2.8.dfsg-5 man-db recommends no packages. Versions of packages man-db suggests: ii apparmor2.12-4 ii chromium [www-browser] 63.0.3239.84-1~deb9u1 pn groff ii less487-0.1 -- debconf information: man-db/auto-update: true man-db/install-setuid: false
Bug#894075: mypy: Missing dependencies
Package: mypy
Version: 0.570-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
presently, mypy doesn't work at all.
$ mypy
Traceback (most recent call last):
File "/usr/bin/mypy", line 11, in
load_entry_point('mypy==0.570', 'console_scripts', 'mypy')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
587, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2800, in load_entry_point
return ep.load()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2431, in load
return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
2437, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python3/dist-packages/mypy/__main__.py", line 3, in
from mypy.main import main
File "/usr/lib/python3/dist-packages/mypy/main.py", line 13, in
from mypy import build
File "/usr/lib/python3/dist-packages/mypy/build.py", line 16, in
from distutils.sysconfig import get_python_lib
ModuleNotFoundError: No module named 'distutils.sysconfig'
salvo@serenity ~ $
Opening this as grave, since the program doesn't even start.
Best.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to
it_IT.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mypy depends on:
ii python3 3.6.4-1
ii python3-mypy 0.570-1
mypy recommends no packages.
Versions of packages mypy suggests:
pn mypy-doc
-- no debconf information
Bug#269990: fixed upstream
This is fixed upstream, will be fixed in the next release. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#892162: python3-motor: Fails to import
Package: python3-motor Version: 1.2.1-1 Severity: grave Justification: renders package unusable Dear Maintainer, I had just started the tutorial for this module http://motor.readthedocs.io/en/stable/tutorial-asyncio.html and started with the initial import: import motor.motor_asyncio which fails. In [2]: import motor.motor_asyncio --- ModuleNotFoundError Traceback (most recent call last) in () > 1 import motor.motor_asyncio /usr/lib/python3/dist-packages/motor/motor_asyncio.py in () 15 """Asyncio support for Motor, an asynchronous driver for MongoDB.""" 16 ---> 17 from . import core, motor_gridfs 18 from .frameworks import asyncio as asyncio_framework 19 from .metaprogramming import create_class_with_framework /usr/lib/python3/dist-packages/motor/core.py in () 32 from pymongo.bulk import BulkOperationBuilder 33 from pymongo.database import Database ---> 34 from pymongo.change_stream import ChangeStream 35 from pymongo.collection import Collection 36 from pymongo.cursor import Cursor, _QUERY_OPTIONS ModuleNotFoundError: No module named 'pymongo.change_stream' So as it is, this module is completely useless. I suppose it depends on a different version of pymongo than what is currently in the archive… Best. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-motor depends on: ii python3 3.6.4-1 ii python3-gridfs 3.5.1+dfsg1-1 ii python3-pymongo 3.5.1+dfsg1-1 python3-motor recommends no packages. Versions of packages python3-motor suggests: ii python3-aiohttp 3.0.1-1 pn python3-tornado -- no debconf information
Bug#892086: lintian: Check for unknown fields in dep5 debian/copyright
At the top. Is it allowed? I didn't see it in the dep5 spec. 2018-03-05 18:24 GMT+01:00 Chris Lamb <la...@debian.org>: > tags 892086 + moreinfo > thanks > > Hi Salvo, > >> by mistake I had used an "Author" field in a dep5 copyright file, >> and lintian doesn't complain about unknown fields. > > At the top of the file or in one of the paragraphs? > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#892086: lintian: Check for unknown fields in dep5 debian/copyright
Package: lintian Version: 2.5.76 Severity: wishlist Dear Maintainer, by mistake I had used an "Author" field in a dep5 copyright file, and lintian doesn't complain about unknown fields. It would be nice to have a warning about this, since it's normally a mistake. Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.30-5 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5 ii file 1:5.32-2 ii gettext 0.19.8.1-4 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.33 ii libarchive-zip-perl 1.60-1 ii libclass-accessor-perl0.51-1 ii libclone-perl 0.39-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.96-1 ii liblist-moreutils-perl0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.26 [libdigest-sha-perl] 5.26.1-5 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.73-1 ii libxml-simple-perl2.24-1 ii libyaml-libyaml-perl 0.69+repack-1 ii man-db2.8.1-1 ii patchutils0.3.4-2 ii perl 5.26.1-5 ii t1utils 1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl3.72-3+b2 pn libtext-template-perl -- no debconf information
Bug#888493: Ping?
This is what i was already doing, but: kwin-common : Dipende: libinput10 (>= 1.9.2) ma la versione 1.6.3-1 sta per essere installata Can't use an old snapshot. evdev works much better, but my muscle memory is used to "properly functioning libinput" at this point, it would suck to switch, but the latest libinput is completely useless for moving the cursor around. 2018-02-15 18:47 GMT+01:00 Emilio Pozuelo Monfort <po...@debian.org>: > On 15/02/18 11:17, Salvo Tomaselli wrote: >> Things are starting to depend on the new version of this package, >> which is still completely unusable to me, and there seems to be 0 >> activity on this issue. >> >> Is debian planning to drop support for running on thinkpads? > > No. You can still switch to xserver-xorg-input-evdev for it. FWIW, the > trackpoint works just fine here on my Thinkpad X230. > > One thing you could do is downgrade to a previous version, 1.8.x I suppose, > which you can grab from snapshot.debian.org. Unfortunately there's not much > more > that we can do, but you should feel free to send patches upstream (see comment > 38 in that bug you linked). > > Emilio -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#888493: Ping?
Things are starting to depend on the new version of this package, which is still completely unusable to me, and there seems to be 0 activity on this issue. Is debian planning to drop support for running on thinkpads? -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#890398: python3-yarl: API has breaking changes
Package: python3-yarl Version: 1.1.0-1 Severity: important Dear Maintainer, this package introduces breaking API changes, causing python3-aiohttp to stop working. In [6]: from aiohttp import web, web_request ...: --- ImportError Traceback (most recent call last) in () > 1 from aiohttp import web, web_request /usr/lib/python3/dist-packages/aiohttp/web.py in () 13 from yarl import URL 14 ---> 15 from . import (hdrs, web_exceptions, web_fileresponse, web_middlewares, 16web_protocol, web_request, web_response, web_server, 17web_urldispatcher, web_ws) /usr/lib/python3/dist-packages/aiohttp/web_middlewares.py in () 3 4 from aiohttp.web_exceptions import HTTPMovedPermanently > 5 from aiohttp.web_urldispatcher import SystemRoute 6 7 /usr/lib/python3/dist-packages/aiohttp/web_urldispatcher.py in () 19 # use `URL(path).raw_path` instead of `quote(path)` 20 # Escaping of the URLs need to be consitent with the escaping done by yarl ---> 21 from yarl import URL, unquote 22 23 from . import hdrs, helpers ImportError: cannot import name 'unquote' -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-yarl depends on: ii libc6 2.26-6 ii python33.6.4-1 ii python3-idna 2.6-1 ii python3-multidict 4.1.0-1 python3-yarl recommends no packages. python3-yarl suggests no packages. -- no debconf information
Bug#890397: python3-aiohttp: Can't use new yarl version
Package: python3-aiohttp Version: 2.3.6-1 Severity: grave Justification: renders package unusable Dear Maintainer, The new version of python3-yarl present in the archive makes this package completely unusable. I have opened a bug against yarl as well, but probably the most effective fix is to patch it here. Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-aiohttp depends on: ii libc6 2.26-6 ii python33.6.4-1 ii python3-async-timeout 2.0.0-1 ii python3-chardet3.0.4-1 ii python3-multidict 4.1.0-1 ii python3-yarl 1.1.0-1 python3-aiohttp recommends no packages. python3-aiohttp suggests no packages. -- no debconf information
Bug#888493: fedora bug
This fedora bug seems to be the same issue. https://bugzilla.redhat.com/show_bug.cgi?id=1509017 -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#888493: xserver-xorg-input-libinput: Thinkpad T560 trackpoint completely unusable
Source: xserver-xorg-input-libinput Version: 0.26.0-1 Severity: important Dear Maintainer, Switching from stable to testing, libinput became the default. Unfortunately the trackpoint is basically unusable. It is incredibly sensitive, but this value seems to change at random, so applying a constant pressure on the device results in the cursor jumping around at various speeds. For now my solution was to remove the package and keep using the normal xorg input method. It seems that the library is completely untested on trackpoints. Best -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#876095: Still active?
Ah I see! Good to know it is getting some love. If you haven't done so yet, you can try joining #debian-mentors on IRC (irc.oftc.net) and ask there. I don't regularly follow that channel, but the ones I do follow tend to be rather active. If you are new to IRC, the idea is that you enter and write, and then it can take even hours to get a reply from people. Best. 2018-01-23 20:27 GMT+01:00 Gabriel F. T. Gomes <gabr...@inconstante.eti.br>: > On Tue, 23 Jan 2018, Salvo Tomaselli wrote: > >>It has been a few months since this ITA, but the package hasn't seen >>any updates and it is still owned by David Paleino. > > I have opened an RFS [1], which received most (if not all) of the more > recent emails/activity. I also marked that RFS as a blocker of this ITA, > however, this kind of information is somewhat hard to see [2]. > > [1] https://bugs.debian.org/877450 > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876095#30 > >>Are you still serious about adopting it? > > Yes, definitely. I'm currently waiting for a sponsor. Maybe it's time to > ping again. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
