Bug#1065661: RM: libgisi/experimental -- ROM; dead upstream, no longer needed
Package: ftp.debian.org Severity: normal Control: affects -1 + src:libgisi User: ftp.debian@packages.debian.org Usertags: remove Hi, libgisi has been removed from unstable (and thus also testing) via 1065219, but still exists in experimental. It should also be removed from there. Thanks, -- Sebastian
Bug#1065219: RM: libgisi -- ROM; dead upstream, no longer needed
Package: ftp.debian.org Severity: normal Control: affects -1 + src:libgisi User: ftp.debian@packages.debian.org Usertags: remove Hi, libgisi was used by the freesmartphone.org software stack, which got removed many years ago. The library itself was taken from the ofono project and adapted for Vala (language used by the freesmartphone.org project). The original library still exists in Ofono, which can be seen as a replacement. Also dak found no issues: ssh mirror.ftp-master.debian.org "dak rm -Rn libgisi" Will remove the following packages from unstable: libgisi |0.1.0-2 | source libgisi | 0.1.0-2.1 | source libgisi-dev | 0.1.0-2+b1 | armel, armhf, mips64el, riscv64 libgisi-dev | 0.1.0-2.1 | amd64, arm64, i386, ppc64el, s390x libgisi0 | 0.1.0-2+b1 | armel, armhf, mips64el, riscv64 libgisi0t64 | 0.1.0-2.1 | amd64, arm64, i386, ppc64el, s390x libgisicomm-dev | 0.1.0-2+b1 | armel, armhf, mips64el, riscv64 libgisicomm-dev | 0.1.0-2.1 | amd64, arm64, i386, ppc64el, s390x libgisicomm0 | 0.1.0-2+b1 | armel, armhf, mips64el, riscv64 libgisicomm0t64 | 0.1.0-2.1 | amd64, arm64, i386, ppc64el, s390x Maintainer: Sebastian Reichel --- Reason --- -- Checking reverse dependencies... No dependency problem found. Greetings, -- Sebastian
Bug#1065014: RM: xf86-video-omap -- ROM; deprecated
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, xf86-video-omap provides a Xorg video driver for the OMAP platform. It is no longer maintained and effectively provides the same functionality as the generic modesetting driver, which is part of xserver-xorg-core itself and can be used instead. Thus let's drop the useless package. DAK did not find any issues: > dak rm -Rn xf86-video-omap > Will remove the following packages from unstable: > > xf86-video-omap | 0.4.5-1.1 | source > xserver-xorg-video-omap | 0.4.5-1.1+b1 | armel, armhf > > Maintainer: Sebastian Reichel > > --- Reason --- > > -- > > Checking reverse dependencies... > No dependency problem found. Thanks, -- Sebastian
Bug#1065012: RM: nescc -- ROM; unmaintained upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ne...@packages.debian.org Control: affects -1 + src:nescc User: ftp.debian@packages.debian.org Usertags: remove Hi, Please remove nescc from Debian. It has been packaged as part of the tinyos stack, which got removed from Debian quite some time ago (last release containing it was Debian 10). By now it's quite obvious, that the project is no longer being maintained upstream. DAK has not found any issues: > dak rm -Rn nescc > Will remove the following packages from unstable: > > nescc | 1.3.5-1.1 | source, amd64, arm64, armel, armhf, i386, mips64el, > ppc64el, s390x > nescc | 1.3.5-1.1+b1 | riscv64 > > Maintainer: Sebastian Reichel > > --- Reason --- > > -- > > Checking reverse dependencies... > No dependency problem found. Thanks, -- Sebastian
Bug#1064546: kicad: Please package 8.0.0
Package: kicad Version: 7.0.10+dfsg-1 Severity: wishlist Dear Maintainer, https://www.kicad.org/blog/2024/02/Version-8.0.0-Released/ Please update the package :) Thanks for your work, -- Sebastian
Bug#1063562: dt-schema: Please add version dependency for jsonschema
Hello Agathe, On Thu, Feb 22, 2024 at 04:32:11PM +0100, Agathe Porte wrote: > > This package completly breaks when using python3-jsonschema from > > experimental (4.19.2-1). I had a quick look and upstream is aware > > of the issue. The build script wants a version < 4.18: > > Note that the 4.19.2 version was uploaded to unstable [1]. I guess that means the Priority of this bug should be increased to grave (which should also result in an autoremove from testing). > Even if we add this new `Depends: python3-jsonschema (<< 4.18)` the > package will fail to build on unstable thus never migrate to testing. If you add that dependency for the _binary_ package it should not fail to build. It cannot migrate to testing, but IMHO that's good. Once jsonschema migrates to testing it will be broken anyways. > So I am delaying this for now until upstream decides what to do [2], > or until jsonschema is fixed [3]. > > [1] > https://tracker.debian.org/news/1504986/accepted-python-jsonschema-4192-2-source-into-unstable/ > [2] https://github.com/devicetree-org/dt-schema/issues/109 > [3] https://github.com/python-jsonschema/jsonschema/issues/1085 Greetings, -- Sebastian signature.asc Description: PGP signature
Bug#1063562: dt-schema: Please add version dependency for jsonschema
Package: dt-schema Version: 2023.11-3 Severity: normal Dear Maintainer, This package completly breaks when using python3-jsonschema from experimental (4.19.2-1). I had a quick look and upstream is aware of the issue. The build script wants a version < 4.18: https://github.com/devicetree-org/dt-schema/blob/main/pyproject.toml#L28 Also this commit message mentions not supporting recent versions of the jsonschema module: https://github.com/devicetree-org/dt-schema/commit/fb80ec43c2044d32cf576ef7c660eedf9c38f9ae Please add this version information to the "Depends: " section of the package (i.e. Depends: python3-jsonschema (<4.18)). Thanks, -- Sebastian
Bug#1063560: dt-schema: Package does not work properly for latest upstream kernel
Package: dt-schema Version: 2023.11-3 Severity: normal Tags: patch Dear Maintainer, I see a huge amount of warning being reported when running CHECK_DTBS in the kernel tree (latest master). After cherry-picking the following two upstream commits things are working properly: https://github.com/devicetree-org/dt-schema/commit/6774d386e3fb42c2a556d7217af63938d76737cb.patch https://github.com/devicetree-org/dt-schema/commit/fb80ec43c2044d32cf576ef7c660eedf9c38f9ae.patch Please add them to the Debian packaging. For reference most of the incorrectly reported issues look like this: Error in referenced schema matching $id: http://devicetree.org/schemas/types.yaml Thanks, -- Sebastian
Bug#1062255: libcmtspeechdata: NMU diff for 64-bit time_t transition
Hi,
On Wed, 31 Jan 2024 20:27:14 + Steve Langasek wrote:
> If you have any concerns about this patch, please reach out ASAP. Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
Enabling 64-bit time_t without any extra changes breaks this
library. The Kernel ABI is 32-bit, so the last field in
'struct cs_mmap_config_block' from kernel-headers/linux/cs-protocol.h
needs to be u32 seconds + u32 nanoseconds. I attached a patch,
which imports the latest kernel ABI (untested, since I currently
do not have enough time for it).
Note, that the kernel ABI has never been changed, since the unsigned
32 bit value only overflows in 2106 and then supporting the Nokia
N900/N950/N9 modem (which only supports GSM and UMTS) is no longer
expected to be relevant.
-- Sebastian
diff --git a/kernel-headers/linux/cs-protocol.h b/kernel-headers/linux/cs-protocol.h
index 9c23b7a..d01be14 100644
--- a/kernel-headers/linux/cs-protocol.h
+++ b/kernel-headers/linux/cs-protocol.h
@@ -87,6 +87,15 @@ struct cs_buffer_config {
__u32 reserved[4];
};
+/*
+ * struct for monotonic timestamp taken when the
+ * last control command was received
+ */
+struct cs_timestamp {
+__u32 tv_sec; /* seconds */
+__u32 tv_nsec; /* nanoseconds */
+};
+
/*
* Struct describing the layout and contents of the driver mmap area.
* This information is meant as read-only information for the application.
@@ -107,7 +116,7 @@ struct cs_mmap_config_block {
* if enabled with CS_FEAT_TSTAMP_RX_CTRL, monotonic
* timestamp taken when the last control command was received
*/
- struct timespec tstamp_rx_ctrl;
+ struct cs_timestamp tstamp_rx_ctrl;
};
#define CS_IO_MAGIC 'C'
signature.asc
Description: PGP signature
Bug#1060680: bluez: 5.71 breaks bluetooth audio
Package: bluez Version: 5.71-1 Severity: important Dear Maintainer, Upgrading to bluez 5.71 breaks bluetooth audio. The following is logged to the journal when trying to connect with a BT headset: Jan 12 16:08:01 jupiter bluetoothd[44839]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 00:00:00:00:00:00: Permission denied (13) Jan 12 16:07:58 jupiter bluetoothd[44839]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 00:00:00:00:00:00: Permission denied (13) Jan 12 16:07:56 jupiter bluetoothd[44839]: src/profile.c:record_cb() Unable to get Hands-Free Voice gateway SDP record: Connection timed out After downgrading to bluez 5.70-1.1 everything is working again. I use use a Bose QC45 headset and pipewire + wireplumber instead of pulseaudio. Greetings, -- Sebastian
Bug#1057414: kicad: Please enable EGL support
Package: kicad
Version: 7.0.9+dfsg-1
Severity: normal
Dear Maintainer,
Without EGL, KiCAD experience on Wayland can be quite bad even when
using XWayland. At least on AMD GPU based systems, there are ~10 second
lags when switching between PCB and Schematics windows on two different
Wayland workspaces.
I've seen commit 5a3af461df6fc6e4be868399277ea4134e703773 ("Revert
"d/rules: Turn option KICAD_USE_EGL on" ), but I think it would be
better to enable EGL support in libglew, libwxwidgets and KiCAD
instead of disabling it everywhere.
At the moment GLX is used on XWayland and that is missing some
workarounds for SwapBuffers(). For EGL wxwidgets already has the
necessary code to disable vsync. See also upstream bugs:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10235
https://github.com/wxWidgets/wxWidgets/issues/23512
I asked for the workaround to also be implemented for the GLX API,
but I believe it's a good idea to enable EGL in Debian even if that
happens.
P.S.: If anyone runs into the lag issue and finds this bug: You can
run KiCAD like this as a workaround: `vblank_mode=0 /usr/bin/kicad`.
Thanks,
-- Sebastian
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (250, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages kicad depends on:
ii libc62.37-12
ii libcairo21.18.0-1
ii libcurl4 8.4.0-2
ii libfontconfig1 2.14.2-6
ii libfreetype6 2.13.2+dfsg-1
ii libgcc-s113.2.0-7
ii libgl1 1.7.0-1
ii libglew2.2 2.2.0-4+b1
ii libglib2.0-0 2.78.1-4
ii libglu1-mesa [libglu1] 9.0.2-1.1
ii libgtk-3-0 3.24.38-6
ii libharfbuzz0b8.0.1-1
ii libngspice0 41+ds-1
ii libocct-data-exchange-7.67.6.3+dfsg1-7
ii libocct-foundation-7.6 7.6.3+dfsg1-7
ii libocct-modeling-algorithms-7.6 7.6.3+dfsg1-7
ii libocct-modeling-data-7.67.6.3+dfsg1-7
ii libocct-ocaf-7.6 7.6.3+dfsg1-7
ii libodbc2 2.3.12-1
ii libpixman-1-00.42.2-1
ii libpython3.113.11.6-3
ii libstdc++6 13.2.0-7
ii libwxbase3.2-1 3.2.4+dfsg-1
ii libwxgtk-gl3.2-1 3.2.4+dfsg-1
ii libwxgtk3.2-13.2.4+dfsg-1
ii python3 3.11.4-5+b1
ii python3-wxgtk4.0 4.2.1+dfsg-1
ii zlib1g 1:1.2.13.dfsg-3
Versions of packages kicad recommends:
pn kicad-demos
ii kicad-libraries 7.0.9+dfsg-1
ii xsltproc 1.1.35-1
Versions of packages kicad suggests:
pn extra-xdg-menus
pn kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-doc-es | kicad-
doc-fr | kicad-doc-id | kicad-doc-it | kicad-doc-ja | kicad-doc-pl
| kicad-doc-ru | kicad-doc-zh
ii kicad-packages3d7.0.9-1
-- no debconf information
Bug#1056616: firefox: Firefox tab freeze when using BigBlueButton
Package: firefox Version: 120.0-2 Followup-For: Bug #1056616 Hi, I see the same behaviour with https://maps.google.com, which might be an easier test-case, since no Big Blue Button instance is needed. This is a regression since 119. Greetings, -- Sebastian
Bug#1028192: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call
Hi Martin, On Tue, Jan 24, 2023 at 10:50:52PM +, Martin wrote: > Hi Sebastian, > > I wonder, if I should upload libproxy with your github patch¹ to > experimental. Then people affected (or not affected) by the bug can test > easily. Or you may upload, of course! :-) > > Cheers > > ¹ https://github.com/libproxy/libproxy/issues/199#issuecomment-1401124997 sure, feel free to upload it to experimental. FWIW I do not understand the root cause of this issue. I'm a bit worried, that the patch masks a security relevant bug. It would be great if somebody with better C++ knowledge can look into this. The bug seems quite strange considering the segmentation fault is happening due to the destruction of an empty vector from the standard library and only in combination with glib-networking. FWIW long term the problem will be solved by glib-networking removing the libproxy dependency: https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/205 Greetings, -- Sebastian signature.asc Description: PGP signature
Bug#1028638: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call
Hi, On Thu, Jan 19, 2023 at 04:12:14PM +0100, Sebastian Reichel wrote: > On Wed, Jan 18, 2023 at 09:48:33PM +, Martin wrote: > > Control: severity -1 grave > > > > Justification for grave: Crashes Gajim for some users. RC, IMHO. If I understood it correctly libproxy is only used by glib networking code when not running GNOME. > > On 2023-01-17 21:56, Sebastian Reichel wrote: > > > I just got the new package through testing and now gajim segfaults > > > ony my system with stacktrace pointing to libproxy. So this is not > > > magically solved. > > > > :-( > > > > Could you check, if a downgrade to libproxy 0.4.15-15 helps? > > That certainly helps to find the bug! > > I tried downgrading libproxy1v5 and libproxy-tools to 0.4.15-15 and > glib-networking to 2.66.0. This did not change anything. > > With libproxy from testing gajim does work when being downgraded to > 1.5.4-1 (which requires also downgrading python3-nbxmpp to > 3.2.5-1 to be functional). This has been reported upstream: https://github.com/libproxy/libproxy/issues/199 Also these apparently describe the same bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970687 https://github.com/exaile/exaile/issues/737 Both workarounds mentioned in those bug reports (removing either /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so or /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0) fix the crash and gajim successfully connects. -- Sebastian signature.asc Description: PGP signature
Bug#1028638: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call
Hi, On Wed, Jan 18, 2023 at 09:48:33PM +, Martin wrote: > Control: severity -1 grave > > Justification for grave: Crashes Gajim for some users. RC, IMHO. > > On 2023-01-17 21:56, Sebastian Reichel wrote: > > I just got the new package through testing and now gajim segfaults > > ony my system with stacktrace pointing to libproxy. So this is not > > magically solved. > > :-( > > Could you check, if a downgrade to libproxy 0.4.15-15 helps? > That certainly helps to find the bug! I tried downgrading libproxy1v5 and libproxy-tools to 0.4.15-15 and glib-networking to 2.66.0. This did not change anything. With libproxy from testing gajim does work when being downgraded to 1.5.4-1 (which requires also downgrading python3-nbxmpp to 3.2.5-1 to be functional). -- Sebastian signature.asc Description: PGP signature
Bug#1028192: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call
Hi, On Sat, 14 Jan 2023 21:53:59 + Martin wrote: > Control: severity -1 normal > > The problem disappeared magically for all users who reported it before. > I assume, that there is a hidden bug in libproxy, that only appears in > certain circumstances. Downgrading for now. I just got the new package through testing and now gajim segfaults ony my system with stacktrace pointing to libproxy. So this is not magically solved. -- Sebastian signature.asc Description: PGP signature
Bug#1006438: gr-satellites: Package is for gnuradio 3.8 instead of 3.10
Package: gr-satellites Version: 4.4.0-2+b1 Severity: important Tags: patch Dear Maintainer, In Gnuradio 3.10 some core blocks have been renamed resulting in gr-satellites no longer working properly. For example the 'sync_to_pdu' block from the gr-satellites package uses 'blocks.tagged_stream_to_pdu', which got moved from gnuradio.blocks to gnuradio.pdu in 3.10 resulting in a runtime failure when using sync_to_pdu from gr-satellites. Looking at the upstream changelog updating to 4.5 should be enough to fix the issue: https://github.com/daniestevez/gr-satellites/releases/tag/v4.5.0 Thanks, -- Sebastian
Bug#1000223: iwd: Segfaults when scanning for networks at my hackerspace
Package: iwd
Version: 1.19-1
Severity: important
Tags: upstream patch
Hi,
iwd segfaults at my hackerspace. I analyzed the stacktrace and the
problem seems to be related to an open network ("Freifunk") being
available from multiple access points. This patch is supposed to fix
the problem (I have not yet tested it):
https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/src/station.c?id=5a111ac902c1bb1dc9c3ac35bd0e19638bdc7998
The referenced commit is part of yesterday's 1.20 release.
Thanks,
-- Sebastian
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (250, 'unstable'),
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 iwd depends on:
ii libc6 2.32-4
ii libreadline8 8.1-2
Versions of packages iwd recommends:
ii dbus [dbus-system-bus] 1.12.20-3
ii wireless-regdb 2021.08.28-1
iwd suggests no packages.
-- no debconf information
Bug#994918: linux-image-5.14.0-1-amd64: Cannot load amdgpu firmware on 5.14 kernel
Hi, The amdgpu driver from Linux 5.14 seems to require IOMMU support, which was disabled by default in my system's BIOS. My system (which has a Radeon RX 5700XT GPU) successfully booted 5.14 after enabling it in the BIOS. Previous 5.10 kernel also worked with IOMMU disabled. I did not do any further investigations. In any case the missing firmware files from the original report are a red herring since the warnings either already existed for 5.10 kernel (e.g. the one about navi10_mes.bin) or are for quite recent GPUs, which were not yet supported by 5.10. Regards, -- Sebastian signature.asc Description: PGP signature
Bug#954824: chromium: Enable PipeWire support in WebRTC
Package: chromium Version: 90.0.4430.212-1 Followup-For: Bug #954824 Control: tags -1 patch Hi, The patch from Riccardo Magliocchetti works, the 'rtc_pipewire_version=0.3' is no longer needed. Building chromium with this does not add any extra build depends, since the library is loaded via ldopen. Also it is runtime disabled by default using chromium's flag system. Last but not least Debian's Firefox has this enabled. Screen sharing functionality is especially interesting while many people a working from home due to Covid-19, so IMHO this should be enabled ASAP. Thanks, -- Sebastian
Bug#988716: platformio 4.3.4 cannot download required frameworks
Package: platformio Version: 4.3.4-1 Severity: grave Dear Maintainer, Upstream changed paths for the framework manifest files in recent releases and did not maintain backward compatibility links resulting in 4.3.4 no longer being able to install the frameworks. For example this happens when I try to build the arduino-blink hello world program: $ platformio run -e d1_mini Processing d1_mini (platform: espressif8266; framework: arduino; board: d1_mini) PlatformManager: Installing espressif8266 Error: Detected unknown package 'espressif8266' But not even native build is possible: $ platformio platform install native PlatformManager: Installing native Error: Detected unknown package 'native' There does not seem to be a way to get better error messages, but using strace I can say it receives a 404 response for the following query: "GET /platforms/manifest.json". The problem is fixed by updating to latest upstream release [I tested 5.1.1], which has already been requested in #976665. This means the package is basically unusable for new installations Since it did not exist in buster, it is always a new installation in bullseye. Considering we are in late freeze phase I suggest to drop the package from Debian testing (and upload a new upstream release to sid). -- Sebastian
Bug#932924: tt-rss: Packaging work for new upstream release 21.1
Hi Sunil, On Thu, Feb 04, 2021 at 08:56:28AM +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Johannes Schauer Marin Rodrigues (2021-02-04 08:50:51) > > oh wow! Thanks a ton for all your work! This is phantastic. :) > > while this still stands Ack. > > Do you want to do the upload yourself? Just add yourself to Uploaders as > > well > > while you are at it, you seem to know what you are doing and I'd love > > somebody > > to help out with packaging. Feel free to just put your commits directly into > > the packaging repo on salsa! That's already part of the changes :) > let me retract this -- somehow I didn't read "tt-rss" and confused packages XD > > It should of course not be me but Sebastian Reichel to make this call. :) I had some pending work from last year doing some of these changes and some additional things. Back then I stopped when reaching the gettext part wondering how to be solve it (IIUIC upstream's version has some security fixes). Anyways your solution is better than doing nothing, so I merged everything together and just uploaded a new version. Your changes all looked sane and I'm mostly busy in the kernel world these days and your help is appreciated. If I saw it correctly you are not a DD, so I just gave you full permissions to the tt-rss repository. Feel free to work directly in the repository without doing pull requests. Thanks, -- Sebastian signature.asc Description: PGP signature
Bug#977450: RM: radare2-cutter -- ROM; Removal of critical dependency (radare2)
Hi, > As radare2 has been discontinued in Debian due to packaging > problems radare2-cutter should also be removed from Debian. I think you misunderstood something (or maybe it is me :)). It is true, that radare2 has been removed from Debian stable. It has not been removed from Debian, though. In fact I uploaded version 5.0 to unstable yesterday and it got accepted by an FTP master today. But I do plan to keep #950372 open, so that r2 will not transition to testing/stable anymore. Thanks, -- Sebastian signature.asc Description: PGP signature
Bug#956431: oomd: Does not work with default cgroup setup from Debian testing
Package: oomd Version: 0.3.1-1 Severity: normal Hi, With more or less default systemd configuration from Debian testing and unmodified oomd configuration the daemon fails to start with the following error: oomd[483]: /sys/fs/cgroup is not a valid cgroup2 filesystem -- Sebastian
Bug#956429: oomd: incorrect information in systemd service file
Package: oomd Version: 0.3.1-1 Severity: important Hi, The systemd service file incorrectly specifies oomd_bin instead of oomd. This basically makes the service file completly useless. -- Sebastian -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (250, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages oomd depends on: ii init-system-helpers 1.57 ii libc62.30-4 ii libgcc-s110-20200324-1 ii libjsoncpp1 1.7.4-3.1 ii libstdc++6 10-20200324-1 ii libsystemd0 244.3-1 oomd recommends no packages. oomd suggests no packages.
Bug#948019: RM: tinyos -- ROM; dead upstream, low popcon, buggy
Package: ftp.debian.org Severity: normal Hi, Please remove tinyos from Debian sid. It has low popcon and is no longer properly maintained upstreamed (nor downstream) and blocks python2 removal. This involves three source packages: tinyos-tools, tinyos and nescc. I'm the sole maintainer for all of them and there are no other reverse dependencies: $ ssh mirror.ftp-master.debian.org "dak rm -Rn tinyos-tools tinyos nescc" Will remove the following packages from unstable: nescc | 1.3.5-1.1 | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x tinyos | 2.1.2+dfsg-1 | source tinyos-source | 2.1.2+dfsg-1 | all tinyos-tools |1.4.2-3 | source tinyos-tools | 1.4.2-3+b1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x Maintainer: Sebastian Reichel --- Reason --- -- Checking reverse dependencies... No dependency problem found. Thanks, -- Sebastian
Bug#932804: terminology-data: contains invalid arch specific file also contained in terminology package
Package: terminology-data Version: 1.4.1-1 Severity: grave Justification: renders package unusable Hi, terminology-data contains /usr/lib/x86_64-linux-gnu/terminology/tytest in 1.4.1-1 and 1.5.0-1, which is also contained in terminology (so package is not installable). Obviously an arch specific file does not belong into an arch all package and should be removed from terminology-data. -- Sebastian
Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated
Hi Helmut,
On Mon, May 20, 2019 at 08:33:10PM +0200, Helmut Grohne wrote:
> On Mon, May 20, 2019 at 06:51:57PM +0200, Sebastian Reichel wrote:
> > Did you forgot to add the attachment? FWIW both changes are with me.
>
> Yes, sorry. I intend to move foward with a "maintainer acknowledged NMU"
> if you lack time for doing the upload.
Instead of creating an extra patch for the config change I would
prefer to have config.php-dist.patch updated. Regarding the NMU:
Please go ahead.
-- Sebastian
> diff --minimal -Nru tt-rss-18.12+dfsg/debian/changelog
> tt-rss-18.12+dfsg/debian/changelog
> --- tt-rss-18.12+dfsg/debian/changelog2019-02-06 00:04:47.0
> +0100
> +++ tt-rss-18.12+dfsg/debian/changelog2019-05-20 17:53:54.0
> +0200
> @@ -1,3 +1,11 @@
> +tt-rss (18.12+dfsg-1.1) UNRELEASED; urgency=medium
> +
> + * Non-maintainer upload.
> + * Cherry pick JShrink PHP 7.3 compatibility patch. (Closes: #923661)
> + * Default to using syslog as log backend rather than sql.
> +
> + -- Helmut Grohne Mon, 20 May 2019 17:53:54 +0200
> +
> tt-rss (18.12+dfsg-1) unstable; urgency=medium
>
>* New upstream release
> diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch
> tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch
> --- tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch 1970-01-01
> 01:00:00.0 +0100
> +++ tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch 2019-05-20
> 17:53:47.0 +0200
> @@ -0,0 +1,11 @@
> +--- tt-rss-18.12+dfsg.orig/config.php-dist
> tt-rss-18.12+dfsg/config.php-dist
> +@@ -166,7 +166,7 @@
> + // Disabling auth_internal in this list would automatically disable
> + // reset password link on the login form.
> +
> +-define('LOG_DESTINATION', 'sql');
> ++define('LOG_DESTINATION', 'syslog');
> + // Error log destination to use. Possible values: sql (uses internal
> logging
> + // you can read in Preferences -> System), syslog - logs to system log.
> + // Setting this to blank uses PHP logging (usually to http server
> diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch
> tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch
> --- tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 1970-01-01
> 01:00:00.0 +0100
> +++ tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 2019-05-20
> 17:49:53.0 +0200
> @@ -0,0 +1,32 @@
> +From 91105810dafedba0390608d7465abd602beb6410 Mon Sep 17 00:00:00 2001
> +From: Sergei Morozov
> +Date: Fri, 14 Sep 2018 19:55:03 -0700
> +Subject: [PATCH] Fixed test failures on PHP 7.3
> +
> +1. continue in break shoud target the while loop directly
> (php/php-src@04e3523).
> +2. strpos() doesn't longer accept non-string needles
> (https://wiki.php.net/rfc/deprecations_php_7_3#string_search_functions_with_integer_needle).
> + src/JShrink/Minifier.php | 4 ++--
> + 2 files changed, 4 insertions(+), 3 deletions(-)
> +
> +diff --git a/src/JShrink/Minifier.php b/src/JShrink/Minifier.php
> +index 8103452..ad8157f 100644
> +--- a/vendor/JShrink/Minifier.php
> b/vendor/JShrink/Minifier.php
> +@@ -183,7 +183,7 @@ protected function loop()
> + // new lines
> + case "\n":
> + // if the next line is something that can't stand alone
> preserve the newline
> +-if (strpos('(-+{[@', $this->b) !== false) {
> ++if ($this->b !== false && strpos('(-+{[@', $this->b)
> !== false) {
> + echo $this->a;
> + $this->saveString();
> + break;
> +@@ -231,7 +231,7 @@ protected function loop()
> + // check for some regex that breaks stuff
> + if ($this->a === '/' && ($this->b === '\'' ||
> $this->b === '"')) {
> + $this->saveRegex();
> +-continue;
> ++continue 3;
> + }
> +
> + echo $this->a;
> diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/series
> tt-rss-18.12+dfsg/debian/patches/series
> --- tt-rss-18.12+dfsg/debian/patches/series 2019-02-06 00:04:47.0
> +0100
> +++ tt-rss-18.12+dfsg/debian/patches/series 2019-05-20 17:52:00.0
> +0200
> @@ -1,3 +1,5 @@
> config.php-dist.patch
> remove-tt-rss-layer.patch
> fix-db-updater-script.patch
> +jshrink_php7.3_fix.patch
> +default_to_syslog.patch
signature.asc
Description: PGP signature
Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated
Hi, On Mon, May 20, 2019 at 05:59:05PM +0200, Helmut Grohne wrote: > Control: tags -1 + patch > > Hi Sebastian and Marcelo, > > On Sat, May 11, 2019 at 10:41:48AM +0200, Stefan Fritsch wrote: > > Yes, using the Minifier.php from the above commit fixes the issue (and > > another php warning that appeared in apache error log). In order to test it, > > one needs to delete the files from /var/cache/tt-rss/js/* first, or the > > minifier won't be called again. > > Thank you, Stefan. > > I've attached a .debdiff that fixes jshrink and changes the default log > destination to syslog (as this avoids the other bug). What do you think? > Only fix the jshrink part? Do both? Did you forgot to add the attachment? FWIW both changes are with me. -- Sebastian signature.asc Description: PGP signature
Bug#922777: sway: zsh completions are installed to incorrect directory
Package: sway Version: 1.0~rc2-1 Severity: normal Hi, The zsh completion files need to be installed into /usr/share/zsh/vendor-completions instead of /usr/share/zsh/site-functions. -- Sebastian
Bug#921424: libuv1-dev: Missing dependency to freebsd-glue on kfreebsd-any
Package: libuv1-dev Version: 1.24.1-1 Severity: normal Hi, libuv1-dev's pkg-config file contains -lfreebsd-glue on kfreebsd-any, so the package should have a dependency to "freebsd-glue [kfreebsd-any]". -- Sebastian -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (250, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libuv1-dev depends on: ii libuv1 1.24.1-1 libuv1-dev recommends no packages. libuv1-dev suggests no packages.
Bug#915363: RFA: aegisub -- advanced subtitle editor
Package: wnpp Severity: normal I request an adopter for the aegisub package. I don't use aegisub myself and don't find enough time to maintain it properly. The package description is: Originally created as tool to make typesetting, particularly in anime fansubs, a less painful experience, Aegisub has grown into a fully fledged, highly customizable subtitle editor. . It features a lot of convenient tools to help you with timing, typesetting, editing and translating subtitles, as well as a powerful scripting environment called Automation (originally mostly intended for creating karaoke effects, Automation can now be used much else, including creating macros and various other convenient tools). -- Sebastian
Bug#913275: iwd: 4-Way Handshake Failure
Package: iwd Version: 0.10-1 Severity: normal Tags: upstream Hi, I gave iwd (0.10-1 from Debian) a try on my notebook - It does not connect to the wireless network in my hackerspace: --- $ iwctl [iwd]# station wlp3s0 connect mainframe Type the network passphrase for mainframe psk. Passphrase: * Operation failed --- Information from journal: --- Nov 08 23:32:17 earth systemd[1]: Starting Wireless service... Nov 08 23:32:17 earth iwd[16327]: No Diffie-Hellman support found, WPS will not be available Nov 08 23:32:17 earth iwd[16327]: The following options are missing in the kernel: Nov 08 23:32:17 earth iwd[16327]: CONFIG_KEY_DH_OPERATIONS Nov 08 23:32:17 earth iwd[16327]: The following optimized implementations might be available: Nov 08 23:32:17 earth iwd[16327]: Wireless daemon version 0.10 Nov 08 23:32:17 earth iwd[16327]: Skipping optional configuration file /etc/iwd/main.conf Nov 08 23:32:17 earth systemd[1]: Started Wireless service. Nov 08 23:32:17 earth iwd[16327]: Wiphy: 0, Name: phy0 Nov 08 23:32:17 earth iwd[16327]: Bands: 2.4 GHz 5 GHz Nov 08 23:32:17 earth iwd[16327]: Ciphers: CCMP TKIP BIP Nov 08 23:32:17 earth iwd[16327]: Supported iftypes: ad-hoc station ap Nov 08 23:32:17 earth iwd[16327]: No ControlPortOverNL80211 setting, defaulting to False Nov 08 23:33:15 earth iwd[16327]: 4-Way handshake failed for ifindex: 3, reason: 1 --- The network is provided by multiple Juniper access points (wla522 & wla532) controlled by WLC-V MSS 9.1.6.2. wpa_supplicant (Debian 2:2.7~git20181004+1dd66fc-1) works as expected with the same network on the same machine: --- $ wpa_cli -i wlp3s0 status bssid=dc:38:e1:90:5b:c1 freq=5180 ssid=mainframe id=18 mode=station pairwise_cipher=CCMP group_cipher=CCMP key_mgmt=WPA2-PSK wpa_state=COMPLETED --- My understanding is, that WPA2-PSK with CCMP should be supported by iwd, so I wonder what went wrong. -- Sebastian -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (250, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-rc2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iwd depends on: ii libc6 2.27-8 ii libreadline7 7.0-5 iwd recommends no packages. iwd suggests no packages. -- no debconf information
Bug#913199: linux: Please enable CONFIG_DRM_DP_CEC on x86
Source: linux Version: 4.19~rc7-1~exp1 Severity: wishlist Hi, Please enable CONFIG_DRM_DP_CEC on x86, which can be used with some Displayport to HDMI adapters. -- Sebastian
Bug#913198: osmo-trx: Please enable LimeSDR support
Package: osmo-trx Version: 0.4.0-1 Severity: wishlist Hi, Please enable LimeSDR support (--with-lms). -- Sebastian
Bug#911998: linux: Please enable CONFIG_KEY_DH_OPERATIONS
Source: linux Version: 4.18.8-1 Severity: wishlist Hi, The new iwd wireless daemon asks for the following configuration option: # journalctl -u iwd Okt 27 03:33:40 earth systemd[1]: Starting Wireless service... Okt 27 03:33:40 earth iwd[18336]: No Diffie-Hellman support found, WPS will not be available Okt 27 03:33:40 earth iwd[18336]: The following options are missing in the kernel: Okt 27 03:33:40 earth iwd[18336]: CONFIG_KEY_DH_OPERATIONS Okt 27 03:33:40 earth iwd[18336]: The following optimized implementations might be available: Okt 27 03:33:40 earth iwd[18336]: Wireless daemon version 0.10 ... -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (250, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-rc2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#908843: terminology: Please add support for WINDOWID environment variable
Package: terminology Version: 1.2.1-1 Severity: wishlist Tags: upstream Hi, Please add support for setting the WINDOWID environment variable, which is done for example by Xterm and most libvte terminal emulators. It's a very useful feature to automatically set a nice icon with xseticon based on the running application. -- Sebastian
Bug#905768: radare2: Consolidate DEBUG_SUPPORT conditionals in debian/rules?
Hi, On Thu, Aug 09, 2018 at 10:30:54AM +0100, Chris Lamb wrote: > I just ACCEPTed radare2 from NEW Thanks. > but was wondering if you could consolidate all of the > DEBUG_SUPPORT conditionals in debian/rules: > > 21 ifeq (i386,$(DEB_HOST_ARCH_CPU)) > 22 DEBUG_SUPPORT=1 > 23 endif > 24 > 25 ifeq (amd64,$(DEB_HOST_ARCH_CPU)) > 26 DEBUG_SUPPORT=1 > 27 endif > 28 > 29 ifeq (mips,$(DEB_HOST_ARCH_CPU)) > 30 DEBUG_SUPPORT=1 > 31 endif > 32 > 33 ifeq (mips64,$(DEB_HOST_ARCH_CPU)) > 34 DEBUG_SUPPORT=1 > 35 endif > > Pretty sure there is a Make construct to do these all at once? :) Make syntax is pretty limited, but it Looks like this may work: ifeq (i386,$(DEB_HOST_ARCH_CPU)) DEBUG_SUPPORT=1 else ifeq (amd64,$(DEB_HOST_ARCH_CPU)) DEBUG_SUPPORT=1 else ifeq (mips,$(DEB_HOST_ARCH_CPU)) ... endif But it's still ugly compared to python style "if $arch in [option1, option2]". I'm open for suggestions :) Note, that it might not be needed anymore once the package switches from radare's custom autoconf-like build system to meson (upstream is currently working on supporting it in parallel). -- Sebastian signature.asc Description: PGP signature
Bug#901561: closed by Scott Kitterman (Re: RM: vala-terminal -- ROM; dead upstream, FTBFS)
Hi Scott, I think you closed this one by mistake. vala-terminal has not been removed from unstable as far as I can see. P.S.: Thanks for taking care of my other RM requests! -- Sebastian On Tue, Jun 19, 2018 at 04:03:13AM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the ftp.debian.org package: > > #901561: RM: vala-terminal -- ROM; dead upstream, FTBFS > > It has been closed by Scott Kitterman . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Scott Kitterman > by > replying to this email. > > > -- > 901561: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901561 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > Date: Tue, 19 Jun 2018 00:01:39 -0400 > From: Scott Kitterman > To: 901561-d...@bugs.debian.org > Subject: Re: RM: vala-terminal -- ROM; dead upstream, FTBFS > > On Thu, 14 Jun 2018 20:20:23 +0200 Sebastian Reichel wrote: > > Package: ftp.debian.org > > Severity: normal > > > > Hi, > > > > vala-terminal FTBFS with new vala releases and is dead upstream. Let's > > remove it from Debian together with the other parts from FSO. > > > > -- Sebastian > > > > Will remove the following packages from unstable: > > > > vala-terminal | 1.3-6 | source, hurd-i386 > > vala-terminal | 1.3-6+b1 | amd64, arm64, armel, armhf, i386, kfreebsd- > amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x > > > > Maintainer: Debian freesmartphone.org Team ma...@lists.alioth.debian.org> > > > > --- Reason --- > > > > ---------- > > > > Checking reverse dependencies... > > No dependency problem found. > > > Already removed under another bug. > > Scott K > Date: Thu, 14 Jun 2018 20:20:23 +0200 > From: Sebastian Reichel > To: Debian Bug Tracking System > Subject: RM: vala-terminal -- ROM; dead upstream, FTBFS > > Package: ftp.debian.org > Severity: normal > > Hi, > > vala-terminal FTBFS with new vala releases and is dead upstream. Let's > remove it from Debian together with the other parts from FSO. > > -- Sebastian > > Will remove the following packages from unstable: > > vala-terminal | 1.3-6 | source, hurd-i386 > vala-terminal | 1.3-6+b1 | amd64, arm64, armel, armhf, i386, > kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x > > Maintainer: Debian freesmartphone.org Team > > > --- Reason --- > > -- > > Checking reverse dependencies... > No dependency problem found. signature.asc Description: PGP signature
Bug#901561: RM: vala-terminal -- ROM; dead upstream, FTBFS
Package: ftp.debian.org Severity: normal Hi, vala-terminal FTBFS with new vala releases and is dead upstream. Let's remove it from Debian together with the other parts from FSO. -- Sebastian Will remove the following packages from unstable: vala-terminal | 1.3-6 | source, hurd-i386 vala-terminal | 1.3-6+b1 | amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x Maintainer: Debian freesmartphone.org Team --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#901560: RM: intone -- ROM; dead upstream, mainly intended for usage with removed FSO
Package: ftp.debian.org Severity: normal Hi, It no longer makes sense to maintain intone. Last upstream change is from 2012 and it's mainly intended to be used with FSO stack, which is currently removed from Debian. Also one of its build dependencies is going to be removed from Debian (#901143). There does not seem to be any reverse dependency. -- Sebastian sre@earth ~ % ssh mirror.ftp-master.debian.org "dak rm -Rn intone" Will remove the following packages from unstable: intone | 0.77+git20120308-1 | source intone | 0.77+git20120308-1+b3 | kfreebsd-amd64, kfreebsd-i386 intone | 0.77+git20120308-1+b4 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x Maintainer: Debian freesmartphone.org Team --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#901403: RM: xf86-video-glamo -- ROM; package broken since 2 years
Package: ftp.debian.org Severity: normal Hi, The source package does not build for "new" Xorg from 2016, has been removed from testing and was not part of last stable release. Upstream seems to be dead since 2011: https://github.com/openmoko/xf86-video-glamo FWIW I never worked on xf86-video-glamo myself, but I'm one of the last persons who worked on the FSO packages. I Cc'd the persons involved with glamo, so that they can intervene. -- Sebastian $ ssh mirror.ftp-master.debian.org "dak rm -Rn xf86-video-glamo" Will remove the following packages from unstable: xf86-video-glamo | 0.0.0+20110719.gitcb9ed170-2 | source xserver-xorg-video-glamo | 0.0.0+20110719.gitcb9ed170-2+b2 | amd64, armel xserver-xorg-video-glamo | 0.0.0+20110719.gitcb9ed170-2+b3 | i386 Maintainer: Debian freesmartphone.org Team --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#901396: RM: mdbus -- ROM; abandoned upstream, superseded
Package: ftp.debian.org Severity: normal Hi, mdbus is no longer needed nowadays. systemd based systems can use busctl as alternative, there is gdbus from libglib2.0-bin and d-feet. Let's drop mdbus, which is no longer actively maintained upstream since a few years. -- Sebastian sre@earth ~ % ssh mirror.ftp-master.debian.org "dak rm -Rn mdbus" Will remove the following packages from unstable: mdbus |2.3.3-2 | source mdbus2 |2.3.3-2 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x Maintainer: Debian FreeSmartphone.Org Team --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#901395: RM: FSO stack -- ROM; abandoned upstream, low popcon
Package: ftp.debian.org Severity: normal Hi, fso-audiod is the last binary remaining from the FSO stack, which lost proper upstream maintanence in 2012. I kept the audio daemon alive a bit longer due due to a downstream patch making it useful with ofonod. Unfortunately it needs quite a few FSO related build dependencies making its maintenance annoying and has a very low popcon of 2. For people interested in having working N900 voice calls I suggest to implement a smaller N900 specific daemon without all those useless build dependencies. All other phones can be made working with a some small shellcode scripts as far as I can tell. RIP ssh mirror.ftp-master.debian.org "dak rm -Rn libgsm0710 libgisi libfsoframework fso-specs libfso-glib vala-dbus-binding-tool fso-audiod" Will remove the following packages from unstable: fso-audiod | 0.12.0-3 | source fso-audiod | 0.12.0-3+b1 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x fso-audiod-dbg | 0.12.0-3+b1 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x fso-audiod-gta04 | 0.12.0-3+b1 | armel, armhf fso-audiod-n900 | 0.12.0-3+b1 | armel, armhf fso-audiod-openmoko | 0.12.0-3+b1 | armel fso-specs | 2012.07.27.2-2 | source, all libfso-glib | 2012.07.27.2-4 | source libfso-glib-dev | 2012.07.27.2-4 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libfso-glib2 | 2012.07.27.2-4 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libfsobasics3 | 0.12.0-8 | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libfsobasics3 | 0.12.0-8+b2 | mips64el libfsoframework | 0.12.0-8 | source libfsoframework-dev | 0.12.0-8 | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libfsoframework-dev | 0.12.0-8+b2 | mips64el libfsoframework3 | 0.12.0-8 | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libfsoframework3 | 0.12.0-8+b2 | mips64el libfsoresource3 | 0.12.0-8 | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libfsoresource3 | 0.12.0-8+b2 | mips64el libfsosystem3 | 0.12.0-8 | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libfsosystem3 | 0.12.0-8+b2 | mips64el libfsotest3 | 0.12.0-8 | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libfsotest3 | 0.12.0-8+b2 | mips64el libfsotransport3 | 0.12.0-8 | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libfsotransport3 | 0.12.0-8+b2 | mips64el libgisi |0.1.0-2 | source libgisi-dev |0.1.0-2 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgisi0 |0.1.0-2 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgisicomm-dev |0.1.0-2 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgisicomm0 |0.1.0-2 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgsm0710 |1.2.2-6 | source libgsm0710-0 |1.2.2-6 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgsm0710-dev |1.2.2-6 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgsm0710mux3 | 0.12.0-8 | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libgsm0710mux3 | 0.12.0-8+b2 | mips64el vala-dbus-binding-tool |0.4.0-3 | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x Maintainer: Sebastian Reichel , Debian FreeSmartphone.Org Team , Debian freesmartphone.org Team -- Sebastian
Bug#897372: ITP: jameica -- Runtime environment for Java applications like Hibiscus
Hi, On Thu, May 03, 2018 at 08:19:14PM +0200, Jochen Sprickerhof wrote: > * Sebastian Reichel [2018-05-03 15:15]: > > FYI: I started to package this some years ago and at that time the > > jameica stack combined EPL (Eclipse Public License) and GPL > > dependencies. This might have been solved in the meantime, but you > > might want to check this first. > > Thanks I found that as well :). I mailed with upstream and two depending > libraries already moved to LGPL and for the core component I proposed to add > an exception as described here: > > https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs nice! > I will reuse your repo on salsa, hope that's fine. Sure, reuse everything you find. Also feel free to take over swt-paperclips and swtcalendar, which are already in the archive. I'm no longer interested in jameica myself, but I wish you good luck! -- Sebastian signature.asc Description: PGP signature
Bug#897372: ITP: jameica -- Runtime environment for Java applications like Hibiscus
Hi, On Tue, May 01, 2018 at 06:42:35PM +0200, Jochen Sprickerhof wrote: > Package: wnpp > Severity: wishlist > Owner: Jochen Sprickerhof > > * Package name: jameica > Version : 2.6.6 > Upstream Author : Olaf Willuhn > * URL : http://www.willuhn.de/products/jameica/ > * License : GPL > Programming Lang: Java > Description : Runtime environment for Java applications like Hibiscus > > Serves as a base framework for recurring tasks on Hibiscus. > Keeps a unified look & feel. Strictly separate program and > user data. Supports synchronous and asynchronous data exchange > via between plugins (via messaging) and allows client server > communication via RMI, XML-RPC and SOAP. Comes with headless > mode (no GUI for servers) and logging. > > This project is base for Hibiscus, I ITPed in #690874. > > I'm planning to maintain jameica as part of the java-team. FYI: I started to package this some years ago and at that time the jameica stack combined EPL (Eclipse Public License) and GPL dependencies. This might have been solved in the meantime, but you might want to check this first. -- Sebastian signature.asc Description: PGP signature
Bug#895129: linux: Battery not detected on Lamina 2-in-1 tablet
Hi,
On Sat, Apr 07, 2018 at 01:04:27PM +0200, Marcus Lundblad wrote:
> Source: linux
> Severity: normal
>
> Dear Maintainer,
>
> I have a Lamina T-1016B 2-in-1 tablet where the battery is not detected
> (the top bar in GNOME shows only the power icon, like on the desktop machine).
> Checking in /var/log/messages I could see the following (grep:ing on ACPI):
>
> Apr 6 09:17:21 eridanus kernel: [5.663167] ACPI: AC: found native
> INT33F4 PMIC, not loading
> Apr 6 09:17:21 eridanus kernel: [5.956763] ACPI: AC: found native
> INT33F4 PMIC, not loading
> Apr 6 08:20:24 eridanus kernel: [5.720266] ACPI: AC: found native
> INT33F4 PMIC, not loading
> Apr 6 08:20:24 eridanus kernel: [6.020086] ACPI: AC: found native
> INT33F4 PMIC, not loading
> Apr 6 08:23:09 eridanus kernel: [5.656934] ACPI: AC: found native
> INT33F4 PMIC, not loading
> Apr 6 08:23:09 eridanus kernel: [5.979635] ACPI: AC: found native
> INT33F4 PMIC, not loading
> Apr 6 08:25:49 eridanus kernel: [5.849791] ACPI: AC: found native
> INT33F4 PMIC, not loading
> Apr 6 08:25:49 eridanus kernel: [6.150902] ACPI: AC: found native
> INT33F4 PMIC, not loading
>
> Checking in the kernel sources, I could see the following:
> In https://github.com/torvalds/linux/blob/master/drivers/acpi/battery.c
>
> There is a blacklist of ACPI HIDs at line 101:
>
> /* Lists of PMIC ACPI HIDs with an (often better) native battery driver */
> static const char * const acpi_battery_blacklist[] = {
> "INT33F4", /* X-Powers AXP288 PMIC */
> };
>
> Further down there's a section for bailing out on blacklisted HIDs at 1491:
>
> for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
> if (acpi_dev_present(acpi_battery_blacklist[i], "1", -1)) {
> pr_info(PREFIX ACPI_BATTERY_DEVICE_NAME
> ": found native %s PMIC, not loading\n",
> acpi_battery_blacklist[i]);
> return;
> }
>
> In __init acpi_battery_init_async
>
> I suppose enabling the approriate module(s) would maybe solve this.
> In the make menuconfig I could see the following drivers:
>
> AXP288_ADC, AXP288_CHARGER, and AXP288_FUEL_GAUGE
>
> I tried building a custom kernel, but upon booting in panics,
> but it seems to be because the initrams fs is not able to mount, I guess
> the image wasn't properly installed in GRUB, or something like that.
>
> By the way, the info below shows kernel 4.14, but that's because I ran
> reportbug from my desktop, and haven't rebooted into the newest kernel yet
> I hope this doesn't create a hassle.
Last year the blacklist was introduced for the ACPI battery driver:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi/battery.c?id=dccfae6d4f4c2cfa1fdc3bf55755fcad02184b99
Enabling AXP288_FUEL_GAUGE (and dependencies) should result in
proper battery information. If there are still issues with your
system after enabling the config option, send a mail to the
following addresses:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS?id=dccfae6d4f4c2cfa1fdc3bf55755fcad02184b99#n10012
-- Sebastian
signature.asc
Description: PGP signature
Bug#894206: dxf2gcode: Traceback related to empty self.geo in polyline and lwpolyline
Hi, On Tue, Mar 27, 2018 at 09:57:04AM -0600, Sebastian Kuzminsky wrote: > Hi Sebastian, thanks for the bug report and the patches! They look good to > me at first glance, I will forward them upstream and if they agree I'll > incorporate them into an updated debian package. > > Do you have an example of a DXF file that fails before these patches and > works after them? One more note - I just checked upstream's ticket system and the LwPolyline patch fixes the same issue, that is fixed by this ticket/patch, but is a bit cleaner and shorter: https://sourceforge.net/p/dxf2gcode/tickets/97/ https://sourceforge.net/p/dxf2gcode/sourcecode/ci/2bab0a200cd1643c54b6fdf5b54c3e84aee59946/ Thanks for taking care of this! -- Sebastian signature.asc Description: PGP signature
Bug#894206: dxf2gcode: Traceback related to empty self.geo in polyline and lwpolyline
Hi, On Tue, Mar 27, 2018 at 09:57:04AM -0600, Sebastian Kuzminsky wrote: > Hi Sebastian, thanks for the bug report and the patches! They look good to > me at first glance, I will forward them upstream and if they agree I'll > incorporate them into an updated debian package. > > Do you have an example of a DXF file that fails before these patches and > works after them? I attached a file, that fails in lwpolyline. I got the polyline traceback after slightly modifying it with librecad / playing with DXF version and currently don't have it at hand anymore. -- Sebastian 999 dxfrw 0.6.3 0 SECTION 2 HEADER 9 $ACADVER 1 AC1021 9 $DWGCODEPAGE 3 ANSI_1252 9 $INSBASE 10 0 20 0 30 0 9 $EXTMIN 10 -2.296212748401287e-16 20 -21.25 30 0 9 $EXTMAX 10 240 20 108.353971 30 0 9 $LIMMIN 10 0 20 0 9 $LIMMAX 10 420 20 297 9 $ORTHOMODE 70 0 9 $REGENMODE 70 1 9 $FILLMODE 70 1 9 $QTEXTMODE 70 0 9 $MIRRTEXT 70 0 9 $LTSCALE 40 1 9 $ATTMODE 70 0 9 $TEXTSIZE 40 2.5 9 $TRACEWID 40 15.68 9 $TEXTSTYLE 7 STANDARD 9 $CLAYER 8 0 9 $CELTYPE 6 BYLAYER 9 $CECOLOR 62 256 9 $CELTSCALE 40 1 9 $DISPSILH 70 0 9 $DIMSCALE 40 1 9 $DIMASZ 40 2.5 9 $DIMEXO 40 0.625 9 $DIMDLI 40 3.75 9 $DIMRND 40 0 9 $DIMDLE 40 0 9 $DIMEXE 40 1.25 9 $DIMTP 40 0 9 $DIMTM 40 0 9 $DIMTXT 40 2.5 9 $DIMCEN 40 2.5 9 $DIMTSZ 40 0 9 $DIMTOL 70 0 9 $DIMLIM 70 0 9 $DIMTIH 70 0 9 $DIMTOH 70 0 9 $DIMSE1 70 0 9 $DIMSE2 70 0 9 $DIMTAD 70 1 9 $DIMZIN 70 8 9 $DIMBLK 1 9 $DIMASO 70 1 9 $DIMSHO 70 1 9 $DIMPOST 1 9 $DIMAPOST 1 9 $DIMALT 70 0 9 $DIMALTD 70 3 9 $DIMALTF 40 0.03937 9 $DIMLFAC 40 1 9 $DIMTOFL 70 1 9 $DIMTVP 40 0 9 $DIMTIX 70 0 9 $DIMSOXD 70 0 9 $DIMSAH 70 0 9 $DIMBLK1 1 9 $DIMBLK2 1 9 $DIMSTYLE 2 Standard 9 $DIMCLRD 70 0 9 $DIMCLRE 70 0 9 $DIMCLRT 70 0 9 $DIMTFAC 40 1 9 $DIMGAP 40 0.625 9 $DIMJUST 70 0 9 $DIMSD1 70 0 9 $DIMSD2 70 0 9 $DIMTOLJ 70 0 9 $DIMTZIN 70 8 9 $DIMALTZ 70 0 9 $DIMALTTZ 70 0 9 $DIMUPT 70 0 9 $DIMDEC 70 2 9 $DIMTDEC 70 2 9 $DIMALTU 70 2 9 $DIMALTTD 70 3 9 $DIMTXSTY 7 STANDARD 9 $DIMAUNIT 70 0 9 $DIMADEC 70 0 9 $DIMALTRND 40 0 9 $DIMAZIN 70 0 9 $DIMDSEP 70 44 9 $DIMATFIT 70 3 9 $DIMFRAC 70 0 9 $DIMLDRBLK 1 STANDARD 9 $DIMLUNIT 70 2 9 $DIMLWD 70 -2 9 $DIMLWE 70 -2 9 $DIMTMOVE 70 0 9 $DIMFXL 40 1 9 $DIMFXLON 70 0 9 $DIMJOGANG 40 0.7854 9 $DIMTFILL 70 0 9 $DIMTFILLCLR 70 0 9 $DIMARCSYM 70 0 9 $DIMLTYPE 6 9 $DIMLTEX1 6 9 $DIMLTEX2 6 9 $LUNITS 70 2 9 $LUPREC 70 4 9 $SKETCHINC 40 1 9 $FILLETRAD 40 0 9 $AUNITS 70 0 9 $AUPREC 70 2 9 $MENU 1 . 9 $ELEVATION 40 0 9 $PELEVATION 40 0 9 $THICKNESS 40 0 9 $LIMCHECK 70 0 9 $CHAMFERA 40 0 9 $CHAMFERB 40 0 9 $CHAMFERC 40 0 9 $CHAMFERD 40 0 9 $SKPOLY 70 0 9 $USRTIMER 70 1 9 $ANGBASE 50 0 9 $ANGDIR 70 0 9 $PDMODE 70 34 9 $PDSIZE 40 0 9 $PLINEWID 40 0 9 $SPLFRAME 70 0 9 $SPLINETYPE 70 2 9 $SPLINESEGS 70 8 9 $HANDSEED 5 2 9 $SURFTAB1 70 6 9 $SURFTAB2 70 6 9 $SURFTYPE 70 6 9 $SURFU 70 6 9 $SURFV 70 6 9 $UCSBASE 2 9 $UCSNAME 2 9 $UCSORG 10 0 20 0 30 0 9 $UCSXDIR 10 1 20 0 30 0 9 $UCSYDIR 10 0 20 1 30 0 9 $UCSORTHOREF 2 9 $UCSORTHOVIEW 70 0 9 $UCSORGTOP 10 0 20 0 30 0 9 $UCSORGBOTTOM 10 0 20 0 30 0 9 $UCSORGLEFT 10 0 20 0 30 0 9 $UCSORGRIGHT 10 0 20 0 30 0 9 $UCSORGFRONT 10 0 20 0 30 0 9 $UCSORGBACK 10 0 20 0 30 0 9 $PUCSBASE 2 9 $PUCSNAME 2 9 $PUCSORG 10 0 20 0 30 0 9 $PUCSXDIR 10 1 20 0 30 0 9 $PUCSYDIR 10 0 20 1 30 0 9 $PUCSORTHOREF 2 9 $PUCSORTHOVIEW 70 0 9 $PUCSORGTOP 10 0 20 0 30 0 9 $PUCSORGBOTTOM 10 0 20 0 30 0 9 $PUCSORGLEFT 10 0 20 0 30 0 9 $PUCSORGRIGHT 10 0 20 0 30 0 9 $PUCSORGFRONT 10 0 20 0 30 0 9 $PUCSORGBACK 10 0 20 0 30 0 9 $USERI1 70 0 9 $USERI2 70 0 9 $USERI3 70 0 9 $USERI4 70 0 9 $USERI5 70 0 9 $USERR1 40 0 9 $USERR2 40 0 9 $USERR3 40 0 9 $USERR4 40 0 9 $USERR5 40 0 9 $WORLDVIEW 70 1 9 $SHADEDGE 70 3 9 $SHADEDIF 70 70 9 $TILEMODE 70 1 9 $MAXACTVP 70 64 9 $PINSBASE 10 0 20 0 30 0 9 $PLIMCHECK 70 0 9 $PEXTMIN 10 0 20 0 30 0 9 $PEXTMAX 10 0 20 0 30 0 9 $GRIDMODE 70 0 9 $SNAPSTYLE 70 0 9 $PLIMMIN 10 0 20 0 9 $PLIMMAX 10 297 20 210 9 $UNITMODE 70 0 9 $VISRETAIN 70 1 9 $PLINEGEN 70 0 9 $PSLTSCALE 70 1 9 $TREEDEPTH 70 3020 9 $CMLSTYLE
Bug#894206: dxf2gcode: Traceback related to empty self.geo in polyline and lwpolyline
Package: dxf2gcode
Version: 20170925-2
Severity: normal
Tags: upstream
Hi,
I managed to crash dxf2gcode in two different, but similar code paths:
Traceback (most recent call last):
File "/usr/bin/dxf2gcode", line 1198, in
window.load()
File "/usr/bin/dxf2gcode", line 844, in load
self.valuesDXF = ReadDXF(self.filename)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line
85, in __init__
self.entities = self.Read_Entities(sections_pos)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line
345, in Read_Entities
sections[section_nr - 1].end - 1)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line
360, in Get_Geo
entitie_geo = self.get_geo_entitie(len(geos), name)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line
419, in get_geo_entitie
geo = GeoentLwPolyline(geo_nr, self)
File
"/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/geoent_lwpolyline.py", line
47, in __init__
self.Read(caller)
File
"/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/geoent_lwpolyline.py", line
196, in Read
self.geo.append(LineGeo(Ps=Ps, Pe=self.geo[0].Ps))
IndexError: list index out of range
Traceback (most recent call last):
File "/usr/bin/dxf2gcode", line 1198, in
window.load()
File "/usr/bin/dxf2gcode", line 844, in load
self.valuesDXF = ReadDXF(self.filename)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line
84, in __init__
self.blocks = self.Read_Blocks(blocks_pos)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line
332, in Read_Blocks
blocks.Entities[-1].geo = self.Get_Geo(s, e)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line
360, in Get_Geo
entitie_geo = self.get_geo_entitie(len(geos), name)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/importer.py", line
405, in get_geo_entitie
geo = GeoentPolyline(geo_nr, self)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/geoent_polyline.py",
line 48, in __init__
self.Read(caller)
File "/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/geoent_polyline.py",
line 215, in Read
self.geo.append(LineGeo(Ps=Ps, Pe=self.geo[0].Ps))
IndexError: list index out of range
I attached two patches, that fixed both issues for me.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (250, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dxf2gcode depends on:
ii poppler-utils 0.62.0-2
ii pstoedit3.70-5+b1
ii python3 3.6.4-1
ii python3-opengl 3.1.0+dfsg-1
ii python3-pyqt5 5.9.2+dfsg-1
dxf2gcode recommends no packages.
dxf2gcode suggests no packages.
-- no debconf information
--- a/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/geoent_polyline.py
2018-03-27 12:40:30.372009282 +0200
+++ b/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/geoent_polyline.py
2018-03-27 12:40:33.796011445 +0200
@@ -209,7 +209,7 @@
Ps = Pe
# It is a closed polyline
-if PolyLineFlag == 1:
+if PolyLineFlag == 1 and len(self.geo) > 0:
# print("sollten �bereinstimmen: %s, %s" %(Ps,Pe))
if next_bulge == 0:
self.geo.append(LineGeo(Ps=Ps, Pe=self.geo[0].Ps))
--- a/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/geoent_lwpolyline.py
2018-03-27 12:42:15.128038514 +0200
+++ b/usr/lib/python3/dist-packages/dxf2gcode/dxfimport/geoent_lwpolyline.py
2018-03-27 12:42:19.916038148 +0200
@@ -188,7 +188,7 @@
next_bulge = bulge
Ps = Pe
-if LWPLClosed == 1 or LWPLClosed == 129:
+if (LWPLClosed == 1 or LWPLClosed == 129) and len(self.geo) > 0:
# print("sollten �bereinstimmen: %s, %s" %(Ps,Pe))
if next_bulge:
self.geo.append(self.bulge2arc(Ps, self.geo[0].Ps, next_bulge))
Bug#890283: pulseaudio-dlna: Please package newer upstream snapshot
Package: pulseaudio-dlna Version: 0.5.3+git20170406-1 Severity: wishlist Hi, Please package newer upstream release, which introduces proper chromecast volume control. Thanks, -- Sebastian -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (250, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-rc8-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pulseaudio-dlna depends on: ii flac 1.3.2-1 ii lame 3.100-2 ii opus-tools 0.1.10-1 ii python 2.7.14-4 ii python-chardet 3.0.4-1 ii python-concurrent.futures 3.2.0-1 ii python-dbus1.2.6-1 ii python-docopt 0.6.2-1 ii python-gi 3.26.1-2 ii python-lxml4.1.0-1 ii python-netifaces 0.10.4-0.1+b3 ii python-notify2 0.3-3 ii python-protobuf3.0.0-9.1 ii python-psutil 5.4.2-1 ii python-pyroute20.4.21-0.1 ii python-requests2.18.4-1 ii python-setproctitle1.1.10-1+b1 ii python-setuptools 38.4.0-1 ii python-zeroconf0.19.1-1 ii python2.7 2.7.14-6 ii sox14.4.2-3 ii vorbis-tools 1.4.0-10.1 pulseaudio-dlna recommends no packages. Versions of packages pulseaudio-dlna suggests: ii ffmpeg 7:3.4.1-1+b2 pn gir1.2-rsvg-2.0 pn gir1.2-rsvg-3.0 pn libav-tools ii python-cairo 1.15.4-2 pn python-netaddr -- no debconf information
Bug#890062: RM: valadoc -- ROM; valadoc is provided by vala source package as of 0.38
Package: ftp.debian.org Severity: normal Hi, Please remove valadoc from unstable. Upstream merged valadoc into vala as of vala 0.38. This is implemented in Debian since a few days (Thanks Jeremy!), so valadoc can be removed. -- Sebastian
Bug#884222: valabind: Fails to build with vala 0.38
On Tue, 30 Jan 2018 18:14:30 +0100 Rico Tzschichholz wrote: > On Mon, 22 Jan 2018 06:52:24 -0500 Jeremy Bicha wrote: > > https://salsa.debian.org/jbicha/valabind > > > > Sebastian, could you take a look? > > > > Afaics this looks good and should be uploaded asap. > > This is the only bit which blocks the vala 0.38 introduction in testing. I agree, based on a quick look. I'm currently too busy to take care of it, though. Jeremy, could you upload your changes? Thanks, -- Sebastian signature.asc Description: PGP signature
Bug#888430: RM: s2tc -- ROM; superseded by native s3tc support in mesa
Package: ftp.debian.org Severity: normal Hi, s2tc can be removed, since the s3tc patent is no longer valid and native s3tc support has been added to mesa 17.3. This version has already been packaged and is now available in testing + unstable. Running 'dak rm -Rn s2tc' on mirror.ftp-master.debian.org did not reveal any problems. Thanks, -- Sebastian
Bug#884222: valabind: Fails to build with vala 0.38
Hi, This has been fixed upstream, but the new bugfix release requires vala 0.40. Reading the discussion between upstream valabind and vala, it looks like vala 0.38 cannot be supported. -- Sebastian signature.asc Description: PGP signature
Bug#878332: linux-armmp-lpae: Raspberry pi 2 hangs at boot
Hi, On Fri, 13 Oct 2017 13:24:38 +0200 Philip Rinn wrote: > just to make it clear: Version 4.11.6 is the last working kernel > for me. 4.12 introduced a new mmc driver, that was not enabled in the Debian kernel resulting in rootfs not being found. It has been enabled in 4.13.4-1, which is available in sid: [armhf,arm64] mmc: Enable MMC_BCM2835 (Closes: #845422) Also your kernel cmdline is probably incorrect for early printing, which works with the Debian kernel on RPi2 (and properly displayed the rootfs could not be found problem for 4.12 kernels): earlyprintk console=ttyAMA0,115200 root=/dev/mmcblk0p2 rootwait -- Sebastian signature.asc Description: PGP signature
Bug#845422: [PATCH] Please add BCM2835 MMC driver for Raspberry Pi 3
Hi, On Thu, 05 Jan 2017 03:53:54 + Ben Hutchings wrote: > Control: tag -1 upstream > > On Wed, 2016-11-23 at 09:43 +0100, Michael Stapelberg wrote: > [...] > > However, when trying to boot linux-image-4.8.0-1-arm64 version 4.8.5-1, I > > noticed that the kernel can’t find any block devices (and hence no root file > > system). This is because the bcm2835-sdhost MMC driver has not actually > > made it > > into Linux 4.8; it is still under review: > > https://www.spinics.net/lists/arm-kernel/msg513433.html > [...] > > As this is still the case, we won't add the driver yet. Please let us > know when it is accepted upstream, and we can consider backporting that > version for stretch. > > Besides which, we already enable the sdhci-iproc driver which should > also work on the RPi 3. Looks like the driver has been upstreamed since 4.12 and is used by default for the SD card in DT. 4.9 from Debian stable boots on RPi2 for me, but 4.12 from testing and sid does not, since it does not detect the SD card. Please add CONFIG_MMC_BCM2835=m to 4.12+. -- Sebastian signature.asc Description: PGP signature
Bug#875763: sakura: Environment variable WINDOWID is no longer exported
Package: sakura Version: 3.4.0-5 Severity: normal Tags: upstream Hi, Previous versions of sakura (or libvte?) exported $WINDOWID, which is really useful, since it makes it possible to do stuff like this: xseticon -id $WINDOWID "/path/to/email.png"; mutt Please re-add the feature! -- Sebastian -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (250, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sakura depends on: ii libatk1.0-0 2.24.0-1 ii libc62.24-17 ii libcairo-gobject21.14.10-1 ii libcairo21.14.10-1 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.53.6-1 ii libgnutls30 3.5.15-2 ii libgtk-3-0 3.22.19-1 ii libpango-1.0-0 1.40.12-1 ii libpangocairo-1.0-0 1.40.12-1 ii libpcre2-8-0 10.22-3 ii libvte-2.91-00.48.3-1 ii libx11-6 2:1.6.4-3 ii zlib1g 1:1.2.8.dfsg-5 sakura recommends no packages. sakura suggests no packages. -- no debconf information
Bug#873766: Closing Bugs, for packages removed from Debian
Hi, Close open bugs in FSO related packages, that have been removed from Debian as part of removal request #873766. -- Sebastian signature.asc Description: PGP signature
Bug#873766: RM: FSO stack -- ROM; FTBFS; RC-buggy; bandoned upstream
Package: ftp.debian.org Severity: normal Hi, This is a removal request for the FSO stack, which is no longer maintained upstream. I kept it compiling with newer vala releases for quite some time, but no longer see any purpose in it (the stack recently broke again with new Vala 0.36 upload #871058, #871119). It mainly supports the old Openmoko Freerunner and requires quite some configuration effort to be useful. Also the UI parts have been broken for a few years without anyone caring enough to fix it (#853504, #773586). There is an alternative modem middle layer available in Debian, that is still actively being developed: ofono. Getting that working with telepathy-ring and some telepathy UI should be much simpler and more future-proof than trying to maintain the FSO + SHR stack. Thus I request to remove the following packages from sid. All of them are maintained by the "Debian FSO team", which is effectively me nowadays. * fso-datad * fso-deviced * fso-frameworkd * fso-gsmd * fso-usaged * libphone-ui * libphone-ui-shr * libphone-utils * libshr-glib * openbmap-logger * phonefsod * phoneui-apps * phoneuid * python-phoneutils * shr-specs * fso-common * fso-gpsd * fso-gsm0710muxd * yue-sounds-fso That leaves the following packages from the core FSO stack, since the audio daemon is still useful for providing audio support on Nokia N900 in combination with ofono. * fso-specs * libfsoframework * libfso-glib * libcmtspeechdata * libgsm0710 * fso-audiod I executed the following on mirror.ftp-master.debian.org and no dependency problems have been found: dak rm -Rn fso-datad fso-deviced fso-frameworkd fso-gsmd fso-usaged \ libphone-ui libphone-ui-shr libphone-utils libshr-glib openbmap-logger \ phonefsod phoneui-apps phoneuid python-phoneutils shr-specs fso-gpsd \ fso-common fso-gsm0710muxd yue-sounds-fso -- Sebastian
Bug#869380: limesuite: Please update to newer release
Package: limesuite Version: 17.06.0+dfsg-0.1 Severity: wishlist Hi, Please update limesuite again. It is required for newer firmware. While I do not know the exact changelog for the newer firmware it fixes a power management related issue. Before the LimeSDR reached high temperatures in no time while doing nothing. After updating the firmware it only warms up by 5-10° in idle mode. -- Sebastian
Bug#868898: libdrm: Please package test binaries
Source: libdrm Version: 2.4.81-2 Severity: wishlist Hi, Please add a new binary package with the generic test binaries from tests subdirectory. -- Sebastian
Bug#863900: Fixed in 0.10.5+dfsg-1
fixed 863900 radare2/0.10.5+dfsg-1 severity 863900 critical thanks Hi, I don't know why David though it was ok to add it. I did remove it when I started working on radare2 again without noticing the problem in the old package (I did create the copyright file from scratch, since so many things changed). Anyways this is fixed in stretch. -- Sebastian signature.asc Description: PGP signature
Bug#863175: u-boot-rpi: Please add support for "fdt apply"
Package: u-boot-rpi Version: 2016.11+dfsg1-4 Severity: wishlist Hi, Please enable support for DT overlays for the RPi U-Boot: https://github.com/u-boot/u-boot/commit/e6628ad7b99b285b25147366c68a7b956e362878 -- Sebastian
Bug#863174: device-tree-compiler: Missing support for DT overlays
Package: device-tree-compiler
Version: 1.4.2-1
Severity: normal
Hi,
Please update to a newer release, that supports DT overlays (Debian
package does not support them, git master supports them). Simple
testcase:
--
/dtc-v1/;
/plugin/;
/ { };
--
-- Sebastian
Bug#861810: ITP: virtme -- tool for disk-less Linux emulation using qemu
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: virtme Version : 0.0.3+git20170420 Upstream Author : Andy Lutomirski * URL : https://git.kernel.org/pub/scm/utils/kernel/virtme/virtme.git/ * License : GPL-2 Programming Lang: Python Description : tool for disk-less Linux emulation using qemu Virtme is a set of simple tools to run a virtualized Linux kernel that uses the host Linux distribution or a simple rootfs instead of a whole disk image. Virtme is tiny, easy to use, and makes testing kernel changes quite simple. Some day this might be useful as a sort of sandbox. Right now it's not really configurable enough for that. The tool is really useful for kernel testing.
Bug#861156: tt-rss: Needs new Dojo to render UI properly
Hi Matthew, On Tue, Apr 25, 2017 at 01:09:52AM -0400, Matthew Gabeler-Lee wrote: > Package: tt-rss > Version: 17.1+git20170410+dfsg-2 > Severity: important > > Since updating to the new 17.1 package of tt-rss, some parts of the UI no > longer render correctly. Immediately noticeable is the feed icons are all > gone, despite the usual "clear cookies, shift-reload" after updates. > > Scanning around, I find this thread that indicates upstream expects to have > Dojo 1.12, but Debian / this tt-rss package only has 1.11, so I suspect this > is the crux of the issue. > > https://tt-rss.org/oldforum/viewtopic.php?f=10&t=4024 > > For reference, with the older Dojo, the immediate problem of feed icons > seems to be placing an as a child of another , which no browser > will render AFAICT. I suspect in the newer Dojo, the node it's placing the > image into is no longer another image. I can't reproduce this. I tested the release before uploading and everything (incl. feed icons) worked and still works as expected in my installation. -- Sebastian > -- System Information: > Debian Release: 9.0 > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, > 'experimental') > Architecture: amd64 > (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-2-amd64 (SMP w/12 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages tt-rss depends on: > ii dbconfig-common 2.0.8 > ii dbconfig-mysql 2.0.8 > ii debconf [debconf-2.0] 1.5.60 > ii init-system-helpers 1.47 > ii libapache2-mod-php7.0 [libapache2-mod-php] 7.0.16-3 > ii libjs-dojo-core 1.11.0+dfsg-1 > ii libjs-dojo-dijit1.11.0+dfsg-1 > ii libjs-scriptaculous 1.9.0-2 > ii libphp-phpmailer5.2.14+dfsg-2.3 > ii lsb-base9.20161125 > ii php 1:7.0+49 > ii php-mbstring1:7.0+49 > ii php-mysql 1:7.0+49 > ii php-php-gettext 1.0.12-0.1 > ii php-xml 1:7.0+49 > ii php7.0 [php]7.0.16-3 > ii php7.0-cgi [php-cgi]7.0.16-3 > ii php7.0-cli [php-cli]7.0.16-3 > ii php7.0-json [php-json] 7.0.16-3 > ii php7.0-mbstring [php-mbstring] 7.0.16-3 > ii php7.0-pgsql [php-pgsql]7.0.16-3 > ii php7.0-xml [php-xml]7.0.16-3 > ii phpqrcode 1.1.4-2 > > Versions of packages tt-rss recommends: > ii apache2 [httpd] 2.4.25-3 > ii ca-certificates 20161130 > ii lighttpd [httpd]1.4.45-1 > ii php-curl1:7.0+49 > ii php-gd 1:7.0+49 > ii php7.0-curl [php-curl] 7.0.16-3 > ii php7.0-gd [php-gd] 7.0.16-3 > ii php7.0-mcrypt [php-mcrypt] 7.0.16-3 > > Versions of packages tt-rss suggests: > ii php-apc 4.0.10-1 > ii php5-apcu [php-apc] 4.0.10-1 > ii sphinxsearch 2.2.11-1.1 > > -- Configuration Files: > /etc/default/tt-rss changed [not included] > /etc/tt-rss/apache.conf changed [not included] > /etc/tt-rss/config.php changed [not included] > > -- debconf information excluded signature.asc Description: PGP signature
Bug#861100: chromium: Extensions from Debian packages no longer work
Hi, On Tue, Apr 25, 2017 at 07:51:33PM -0400, Michael Gilbert wrote: > control: tag -1 moreinfo, unreproducible > > This works correctly for me. What is do you see in the Command Line > field shown by chrome://version? /usr/lib/chromium/chromium --cipher-suite-blacklist=0xc007,0xc011,0x0066,0xc00c,0xc002,0x0005,0x0004 --show-component-extension-options --ignore-gpu-blacklist --no-default-browser-check --disable-pings --media-router=0 --force-device-scale-factor=1 --enable-remote-extensions --load-extension=/usr/share/chromium/extensions/lwn4chrome --load-extension=/usr/share/chromium/extensions/tt-rss-notifier --load-extension=/usr/share/chromium/extensions/ublock-origin --flag-switches-begin --flag-switches-end > Have you modified anything in /etc/chromium.d? Yes, I disabled a few ciphers (I have that for quite some time). No other modifications, but due to the package upgrade "--enable-remote-extensions" was enabled. With that commented out both extensions are functional again. Command Line field looks basically the same: /usr/lib/chromium/chromium --cipher-suite-blacklist=0xc007,0xc011,0x0066,0xc00c,0xc002,0x0005,0x0004 --show-component-extension-options --ignore-gpu-blacklist --no-default-browser-check --disable-pings --media-router=0 --force-device-scale-factor=1 --load-extension=/usr/share/chromium/extensions/lwn4chrome --load-extension=/usr/share/chromium/extensions/tt-rss-notifier --load-extension=/usr/share/chromium/extensions/ublock-origin --disable-background-networking --disable-extensions-except=/usr/share/chromium/extensions/lwn4chrome,/usr/share/chromium/extensions/tt-rss-notifier,/usr/share/chromium/extensions/ublock-origin, --flag-switches-begin --flag-switches-end -- Sebastian signature.asc Description: PGP signature
Bug#861100: chromium: Extensions from Debian packages no longer work
Package: chromium Version: 58.0.3029.81-1 Severity: important Hi, I have chromium-tt-rss-notifier and chromium-lwn4chrome installed and they stopped working with version 58.0.3029.81-1. They are no longer listed in chrome://extensions. Both were working fine with version 57.0.2987.133-1. I also have chromium-ublock-origin installed, which is still working correctly. -- Sebastian -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (1000, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii libasound2 1.1.3-5 ii libatk1.0-0 2.22.0-1 ii libavcodec57 7:3.2.4-1 ii libavformat577:3.2.4-1 ii libavutil55 7:3.2.4-1 ii libc62.24-9 ii libcairo21.14.8-1 ii libcups2 2.2.1-8 ii libdbus-1-3 1.10.18-1 ii libevent-2.0-5 2.0.21-stable-3 ii libexpat12.2.0-2 ii libflac8 1.3.2-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.1 ii libgcc1 1:6.3.0-14 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libharfbuzz0b1.4.2-1 ii libicu57 57.1-6 ii libjpeg62-turbo 1:1.5.1-2 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1 ii libpango-1.0-0 1.40.4-1 ii libpangocairo-1.0-0 1.40.4-1 ii libpng16-16 1.6.28-1 ii libpulse010.0-1 ii libre2-3 20170101+dfsg-1 ii libsnappy1v5 1.1.3-3 ii libstdc++6 6.3.0-14 ii libvpx4 1.6.1-3 ii libwebp6 0.5.2-1 ii libwebpdemux20.5.2-1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb1 1.12-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.14-1+b4 ii libxdamage1 1:1.1.4-2+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-2.2 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.29-2.1 ii libxss1 1:1.2.2-1 ii libxtst6 2:1.2.3-1 ii x11-utils7.7+3+b1 ii xdg-utils1.1.1-1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages chromium recommends: ii fonts-liberation 1:1.07.4-2 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell pn chromium-widevine -- no debconf information
Bug#860322: ITP: tt-rss-notifier-chrome -- Chromium extension providing toolbar button for TT-RSS installations
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: tt-rss-notifier-chrome Version : 0.5.2 Upstream Author : Andrew Dolgov * URL : https://tt-rss.org/gitlab/fox/tt-rss-notifier-chrome/ * License : GPLv3 Programming Lang: JS Description : Chromium extension providing toolbar button for TT-RSS installations This extension adds a toolbar button which changes color when unread articles are available in your Tiny Tiny RSS installation and displays the number of unread entries in a tooltip and, optionally, using a badge. The server's URL and the username are changeable in the extension's option page.
Bug#860283: ITP: xwallpaper -- utility for setting X wallpaper
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: xwallpaper Version : 0.2 Upstream Author : Tobias Stoeckmann * URL : https://github.com/stoeckmann/xwallpaper * License : ISC Programming Lang: C Description : utility for setting X wallpaper Hi, While reviewing feh (and imlib2 dependency) from security aspect Tobias found a few issues in it. While those were fixed upstream, imlib2 is marked as legacy and no release is expected soon. As alternative to feh Tobias decided to write an even simpler tool for setting the wallpaper, which is conveniently named xwallpaper (with xsetwallpaper already being used by NetBSD people). It has minimal dependencies (libxcb, libjpg, libpng, libxpm) and is just above 1000 lines of code. Regarding to background setting support it supports all of feh's modes while using less resources and being faster. Compared to feh unsupported features are image loading from URLs and automatic creation of a status file. Also parameter syntax is slightly different following the syntax of xrandr. -- Sebastian
Bug#860219: libjpeg62-turbo-dev: Missing Version in pkg-config file
Package: libjpeg62-turbo-dev Version: 1:1.5.1-2 Severity: normal Hi, $ grep Version /usr/lib/x86_64-linux-gnu/pkgconfig/libjpeg.pc Version: I would expect something like "Version: 1.5.1" instead. -- Sebastian
Bug#858873: radare2: CVE-2017-7274
Hi, On Tue, Mar 28, 2017 at 06:37:19AM +0200, Salvatore Bonaccorso wrote: > CVE-2017-7274[0]: > | The r_pkcs7_parse_cms function in libr/util/r_pkcs7.c in radare2 1.3.0 > | allows remote attackers to cause a denial of service (NULL pointer > | dereference and application crash) via a crafted PE file. > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. Thanks for the bug report. I just uploaded a fixed release to experimental. > AFAICS the version in sid is not affected, since the corresponding > parsers were added only in 1.3.0. Would be great if you can confirm. Ack. -- Sebastian signature.asc Description: PGP signature
Bug#858594: osmo-trx: Please update to version containing LimeSDR support
Package: osmo-trx Version: 0~20150325gitf147b17+dfsg-3 Severity: wishlist Hi, Please update package to newer git snapshot containing cbfef6e40a030a7e99c8bba49482ac53f05b803b. -- Sebastian
Bug#858591: limesuite: Please update to newer release
Package: limesuite Version: 16.12.0+dfsg-1 Severity: wishlist Hi, I received my LimeSDR yesterday and it comes with a newer FW than expected by limesuite resulting in incorrect behaviour in lots of places. The following information is printed to standard output: ## !!! Warning: firmware version mismatch !!! ## Expected firmware version 2, but found version 3 ## Follow the FW and FPGA upgrade instructions: ## http://wiki.myriadrf.org/Lime_Suite#Flashing_images ## !!! Warning: gateware version mismatch !!! ## Expected gateware version 2, revision 2 ## But found version 2, revision 6 ## Follow the FW and FPGA upgrade instructions: ## http://wiki.myriadrf.org/Lime_Suite#Flashing_images -- Sebastian -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (1000, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages limesuite depends on: ii libc6 2.24-9 ii libgcc1 1:6.3.0-10 ii libgl1-mesa-glx [libgl1] 13.0.5-1 ii libglew2.02.0.0-3+b1 ii liblimesuite16.12-1 16.12.0+dfsg-1 ii libstdc++66.3.0-10 ii libwxbase3.0-0v5 3.0.2+dfsg-3 ii libwxgtk3.0-0v5 3.0.2+dfsg-3 ii python2.7.13-2 ii python-soapysdr 0.5.4-1 limesuite recommends no packages. limesuite suggests no packages. -- no debconf information
Bug#856183: What's a safe way to have extensions in chromium in Debian?
Hi, On Wed, Mar 22, 2017 at 12:03:02PM +0100, Enrico Zini wrote: > now we have extensions disabled in Chromium by default. If I did my > homeworks correctly, that prevents Chromium from phoning home by > default, and prevents a previous scenario where extensions could be > installed but not upgraded, becoming security issues over time. > > Now, suppose I need an extension, what is the proper way to have it in > Debian, so that it gets upgraded when needed? With that proper way, what > amount of phoning home is going to happen? > > Since this looks like it's going to be a major issue with stretch, can I > have some authoritative wiki page / FAQ entry that tells me how I can > deal with it cleanly, and that I can easily send to confused people? I wonder if we could just add a boolean debconf question for this. It could setup /etc/chromium.d/remote-extensions based on the answer and provide some (dis)advantages info for selecting either option. -- Sebastian signature.asc Description: PGP signature
Bug#857205: flash-kernel: Add support for TI OMAP4 PandaBoard-ES
Hi, On Wed, Mar 08, 2017 at 08:53:50PM +, Marc Kleine-Budde wrote: > +Machine: TI OMAP4 PandaBoard-ES > +Kernel-Flavors: armmp armmp-lpae OMAP4 is Cortex A9, so no LPAE support. -- Sebastian signature.asc Description: PGP signature
Bug#854193: unblock: tint2/0.12.12-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package tint2 Hi, Please unblock tint2 0.12.12-3 (testing currently has 0.12.12-2). The only difference is one additional cherry-picked upstream patch: https://sources.debian.net/patches/tint2/0.12.12-3/0004-ignore-monitors-with-size-0.patch/ That patch fixes a use-after-free problem followed by strange tint2 behaviour. This is the related upstream bug: https://gitlab.com/o9000/tint2/issues/618 unblock tint2/0.12.12-3 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (1000, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#810392: fixed in 0xffff/0.6.1+git20160627-1
fixed 810392 0x/0.6.1+git20160627-1 thanks (While I have no problem keeping this bug open for discussion the version above does not use libusb 0.1, so the bug itself is fixed there) Regarding libusb1.0 bugs: For me it's exactly the other way around. I did have some problems with libusb0.1 on USB3 ports (I did not further analyse them, since it worked with the USB2 ports. On my current hardware it also worked with the USB3 ports). 0x linked against libusb1.0 works like a charm for me, since I cannot reproduce the bug myself I did not get involved. Maybe just report a bug on github? It looks like the issues are actively checked there: https://github.com/libusb/libusb/issues -- Sebastian signature.asc Description: PGP signature
Bug#845064: linux: please enable CONFIG_GPIO_MCP23S08
Source: linux Version: 4.7.8-1 Severity: wishlist Please enable CONFIG_GPIO_MCP23S08 on armmp. It's a common i2c gpio chip, that is used by me together with a Raspberry Pi. -- Sebastian
Bug#842298: ITP: california -- calendar application for GNOME 3
On Thu, Oct 27, 2016 at 11:36:20PM +0200, Michael Biebl wrote: > Am 27.10.2016 um 21:56 schrieb Sebastian Reichel: > > Package: wnpp > > Severity: wishlist > > Owner: Sebastian Reichel > > > > * Package name: california > > Version : 0.4.0 > > Upstream Author : Jim Campbell > > * URL : https://wiki.gnome.org/Apps/California > > * License : LGPL-2.1 > > Programming Lang: Vala > > Description : calendar application for GNOME 3 > > > > California is a calendar built for GNOME 3. It allows you to > > view and manage your online calendars with a simple and modern > > interface. It uses EDS (Evolution Data Server) as the back-end > > for managing your calendars. If you've already added calendars > > to EDS via another application (such as Evolution), you should > > be able to see those calendars in California as well. > > > > I have packaging ready at [0] and intend to upload it, if it > > turns out to be useful on small screens as found in smartphones. > > Given that we have gnome-calendar, is there a compelling reason to > have this package in the archive? gnome-calendar also looks smartphone compatible, but lacks an agenda view. I will try out both on my N900 and decide based on the results. I'm not in a hurry. > TTBOMK, this software is more or less dead upstream (most likely a > result of yorba being discontinued). I guess you need to be > prepared to be more or less upstream for it. Yes, not much development going on upstream, but it seems to be a nice replacement application for Maemo's calendar software and I'm used to more or less dead upstream. -- Sebastian signature.asc Description: PGP signature
Bug#842298: ITP: california -- calendar application for GNOME 3
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: california Version : 0.4.0 Upstream Author : Jim Campbell * URL : https://wiki.gnome.org/Apps/California * License : LGPL-2.1 Programming Lang: Vala Description : calendar application for GNOME 3 California is a calendar built for GNOME 3. It allows you to view and manage your online calendars with a simple and modern interface. It uses EDS (Evolution Data Server) as the back-end for managing your calendars. If you've already added calendars to EDS via another application (such as Evolution), you should be able to see those calendars in California as well. I have packaging ready at [0] and intend to upload it, if it turns out to be useful on small screens as found in smartphones. [0] https://anonscm.debian.org/cgit/pkg-gnome/california.git -- Sebastian
Bug#840983: bluez: Please update to 5.42 for dual mode device support
Package: bluez Version: 5.42-0.1 Severity: wishlist Hi, Please update package to 5.42, which has support for transport selection (BR/EDR vs LE) (see changelog at [0]). This is needed for proper support of Bose QC35, which has LE and BR. Audio only works over BR and bluez < 5.42 does not switch from LE to BR, so audio only works if the headphone did not connect via LE (so it's kind of random if audio works). [0] http://www.bluez.org/release-of-bluez-5-42/ -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (1000, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bluez depends on: ii dbus 1.10.12-1 ii init-system-helpers 1.45 ii kmod 22-1.1 ii libc62.24-3 ii libdbus-1-3 1.10.12-1 ii libglib2.0-0 2.50.0-2 ii libreadline7 7.0-1 ii libudev1 231-9 ii lsb-base 9.20160629 ii udev 231-9 bluez recommends no packages. bluez suggests no packages. -- Configuration Files: /etc/bluetooth/main.conf changed [not included] -- no debconf information
Bug#840746: valac: Regression in DBus gio-2.0.vapi binding
Package: valac Version: 0.34.0-1 Severity: serious Tags: patch upstream Justification: renders mdbus package completly useless Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=772902 Control: affects -1 mdbus2 Hi, vala 0.34 has updated gio-2.0.vapi file, which removed "array_null_terminated = true" annotation from a couple of DBus related objects. This results in mdbus2 package being completly useless, as it only sees empty arrays. -- Sebastian
Bug#773236: tt-rss: UI and Functional Regressions in 1.15
Hi, On Fri, Sep 30, 2016 at 01:03:40PM +0500, Andrey Rahmatullin wrote: > > It no longer remembers which categories are collapsed / open -- defaults to > > all categories open every time you load the page again. > Well, now it defaults to all categories closed every time you load the > page again. I doubt that was intended. It is. Upstream removed support to remember what categories are currently open and defaults to all closed since the following commit: https://tt-rss.org/gitlab/fox/tt-rss/commit/88918ca637d5e5d22a687ddd70ea04675577448a -- Sebastian signature.asc Description: PGP signature
Bug#839128: Web UI doesn't work: "Cannot read property 'addOnLoad' of undefined"
Hi, On Thu, Sep 29, 2016 at 11:02:02AM +0200, Andrey Rahmatullin wrote: > Package: tt-rss > Version: 16.8+git20160826+dfsg-3 > Severity: grave > > After upgrading from 15.7+git20151123+dfsg-5 to 16.8+git20160826+dfsg-3 when > I open the Web UI I get an error popup and the webpage stays at "Loading". > > """ > Exception: TypeError: Cannot read property 'addOnLoad' of undefined > Function: init()Ошибка будет зафиксирована в указанном логе. > > Additional exception caught while trying to show the error dialog. > > Exception: ReferenceError: dijit is not defined > Function: exception_error() > > The error will be reported to the configured log destination. > """ I cannot reproduce this. Have you cleared any caches and made sure, that your browser fetches newest javascript? -- Sebastian signature.asc Description: PGP signature
Bug#838829: Try to add Generics declaration to class definition
Hi,
On Tue, Sep 27, 2016 at 06:36:12AM -0500, Daniel Espinosa wrote:
> As for bug:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=770449
>
> Valac have started to check types in other places and if GitHub manual is
> used to check generic classes declaration, as for:
>
> https://github.com/valadate-project/the-vala-manual/blob/master/en/generics-examples.md
>
> then your example should be:
>
> public abstract class basecl : Object {
> public abstract void test(T parameter);
> }
>
> public class inheritcl : basecl {
> public override void test(T parameter) {
> stdout.printf("Just a test!\n");
> }
> }
>
> May you want to test this code and change this bug, as this may it is not,
> but a code update required due to recent additional checks in valac.
No. Your code also fails with valac 0.34.0. In vala 0.34.0 you can't
override generic methods. Note that it already has been fixed
upstream:
https://git.gnome.org/browse/vala/commit/?h=0.34&id=9e0e03f2ca48eeef4d16067cca21426b240cd5c5
vala 0.32.0 and vala 0.34.0 with that fix applied compiles my
testcode from above without any problems. Also the libfsoframework
no longer FTBFS.
-- Sebastian
signature.asc
Description: PGP signature
Bug#838334: fixed in valadoc 0.30.0~git20160518-1
Hi, On Mon, Sep 26, 2016 at 01:44:32AM +0200, Michael Biebl wrote: > Am 26.09.2016 um 01:28 schrieb Sebastian Reichel: > > I wonder if libvala-XY-dev should be named libvala-dev with the > > next version increase, though. This should make binnmu based > > transitions possible for valabind. > > Would a Provides: libvala-dev be sufficient? As long as it's guaranteed, that there is only one package providing libvala-dev it might work. It would be a problem if libvala-0.34-dev and libvala-0.36-dev (numbers are just examples) are both available and providing libvala-dev. Then it's unclear which build-dependency should be pulled. That could be worked around by creating a transition-style libvala-dev package, that depends on libvala-xy-dev. > I think it makes some sense to include the API version in > libvala-XY-dev. After all, the version is encoded in > libvala-XY.pc and /usr/include/vala-XY. > > Would we need to provide an unversioned libvala.pc as well? No. valabind checks which libvala-xy it has to build against based on the valac version: https://sources.debian.net/src/valabind/0.10.0-1/getvv/ valadoc has a list of supported libvala versions, that it can build against: https://sources.debian.net/src/valadoc/0.30.0~git20160518-1/configure.ac/#L83 -- Sebastian signature.asc Description: PGP signature
Bug#838334: fixed in valadoc 0.30.0~git20160518-1
Hi, On Mon, Sep 26, 2016 at 12:34:55AM +0200, Michael Biebl wrote: > Thank you for fixing valadoc and valabind so quickly You are welcome. > and sorry for the short advance notice. No harm done. I wonder if libvala-XY-dev should be named libvala-dev with the next version increase, though. This should make binnmu based transitions possible for valabind. valadoc needs code adjustments for each vala release, but I can specify Build-Depends: libvala-dev (< max-version-supported+1~). So if I upload a valadoc release with 0.36 support before valac is in the archive valadoc could also be binnmu'd once vala 0.36 arrives. > I didn't expect to get a green light on the libvala transition so > quickly. So kudos to the release team here as well. -- Sebastian signature.asc Description: PGP signature
Bug#838829: valac: Feature Regression in vala 0.34
Package: valac
Version: 0.34.0-1
Severity: serious
Tags: upstream
Justification: upstream regression causes FTBFS in other package(s)
Hi,
valac no longer supports abstract functions with generics. This
construct is used by the freesmartphone.org stack, which is
packaged for Debian and FTBFS with valac > 0.34.0-1. This has
been reported in Debian Bug #838705.
The below standalone testcase, which compiles warning free
in vala 0.32, no longer works in vala 0.34 and demonstrates the
problem.
As far as I can see the regression has been introduced by the
following change:
https://mail.gnome.org/archives/commits-list/2016-July/msg02876.html
-
public abstract class basecl : Object {
public abstract void test(T parameter);
}
public class inheritcl : basecl {
public override void test(T parameter) {
stdout.printf("Just a test!\n");
}
}
int main(string[] args) {
var obj = new inheritcl();
obj.test("test");
return 0;
}
-
-- Sebastian
Bug#838705: this is a bug in libfsoframework
reassign 838705 libfsoframework 0.12.0-7 affects 838705 + fso-datad fso-audiod fso-deviced thanks Hi, libfsoframework no longer builds with vala 0.34 due to the following newly introduced error: https://mail.gnome.org/archives/commits-list/2016-July/msg02876.html The code in libfsoframework looks correct though. I think it's a regression in the vala compiler. -- Sebastian signature.asc Description: PGP signature
Bug#815446: aegisub: Feature request: ability to load video files matching the subtitles' filename
Control: tag -1 moreinfo Hi, On Sun, 21 Feb 2016 18:31:06 +0200 Sophoklis Goumas wrote: > Package: aegisub > Version: 3.2.2+dfsg-3 > Severity: wishlist > > If aegisub had an option which would allow it to auto-load > video file that was matching the subtitles's filename > that would simplify working with it a lot. > > Just as media players do. Aegisub is used for editing subtitles in SubStation Alpha format, which has native support for referencing Video/Audio files (*). It will ask you, if you want to load the referenced files. If you still think your feature is needed feel free to report it upstream: https://aegisub.uservoice.com/forums/12642-features (*) Looks like this in the file: -- [Script Info] ... PlayResX: 1280 PlayResY: 720 Video File: ./data/video.mp4 ... -- -- Sebastian signature.asc Description: PGP signature
Bug#823373: aegisub: The audio volume leveller in aegisub doesn't work.
Control: tag -1 +moreinfo +unreproducible Hi, On Wed, 4 May 2016 00:33:17 + =?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?= wrote: > Package: aegisub > Version: 3.2.2+dfsg-3 > Severity: normal > > Dear Maintainer, > I opened an audio file to make subtitles, the audio was louder than I > liked. I tried to use the GUI for the volume leveller but it doesn't > do anything. I had to resort to Mate's volume control to fix the > loudness. > > Please fix the same. aegisub's volume control is working for me. I tried alsa, pulseaudio and oss audio player (View->Options->Advanced->Audio->Audio Player). -- Sebastian signature.asc Description: PGP signature
Bug#713065: convert 713065 into RFP
retitle 713065 RFP: tt-rss-attic-plugins -- Extra plugins for tt-rss reassign 713065 wnpp thanks Hi, I'm converting this into an wnpp bug, since it should become a separate source package. I do not intend to package tt-rss-attic, though. The contrib plugins have only limited upstream support and can be found here nowadays: https://tt-rss.org/gitlab/fox/tt-rss-attic -- Sebastian signature.asc Description: PGP signature
Bug#795550: openocd: Please add SWD support to Bus Pirate driver
Hi, On Sat, 15 Aug 2015 09:37:06 +0100 Jonathan McDowell wrote: > Package: openocd > Version: 0.9.0-1+b1 > Severity: wishlist > Tags: patch > > Please consider applying the attached patch, which is taken from > upstream's gerrit instance and adds support for Serial Wire Debugging > (SWD) to the Bus Pirate driver. I have successfully used this to program > an FST-01 device, as described at: > > http://www.earth.li/~noodles/blog/2015/08/program-fst01-with-buspirate.html Tested-By: Sebastian Reichel (using WifiMCU/EMW3165) -- Sebastian signature.asc Description: PGP signature
Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog
Hi, On Wed, Jun 15, 2016 at 01:25:53PM +, Usyskin, Alexander wrote: > It may be that fdd9b8655933 uncovered the bug in iTCO_wdt because > it actually removes iAMT watchdog and new implementation does not > creates one for not provisioned ME. > > So before that patch there was two watchdog devices and systemd > maybe worked with iAMT one. After that patch only one watchdog > exists in the system - iTCO and system works with it. Yes, looks like /dev/watchdog was iAMT watchdog on older kernels: 4.5: Jun 15 01:26:36 earth systemd[1]: Hardware watchdog 'INTCAMT', version 0 Jun 15 01:26:36 earth systemd[1]: Failed to set timeout to 30s: Invalid argument 4.6: Jun 15 01:24:49 earth systemd[1]: Hardware watchdog 'iTCO_wdt', version 0 Jun 15 01:24:49 earth systemd[1]: Set hardware watchdog to 30s. Thanks for you help. So I guess there are two bugs, which are both unrelated to iAMT watchdog, but uncovered by this change: 1. systemd's watchdog logic seems to be broken after suspend/resume, so that the watchdog times out. It must be systemd's fault, since wd_keepalive does not trigger the bug. Previous kernels worked, since operations on INTCAMT were basically no-ops without provisioned ME. 2. iTCO_wdt hangs the system instead of restarting it. -- Sebastian signature.asc Description: PGP signature
Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog
Hi, On Wed, Jun 15, 2016 at 08:00:30AM +, Usyskin, Alexander wrote: > I assume that "This happened with 4.6, but not with v4.5.", yes? Yes, sorry. > Do you have vPro system? Yes, my CPU is i7-5600U. > Have you provisioned your ME device? No, I don't think so. > If not, the iAMT watchdog should not be exposed to user-space and > should not affect systemd. Do you have /dev/watchdog* with identity > "iamt_wdt" at you system? # ls /sys/class/watchdog watchdog0 # wd_identify iTCO_wdt That's also, what was used by systemd: Jun 15 01:24:49 earth kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 Jun 15 01:24:49 earth kernel: iTCO_wdt: Found a Wildcat Point_LP TCO device (Version=2, TCOBASE=0x1860) Jun 15 01:24:49 earth kernel: iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) Jun 15 01:24:49 earth systemd[1]: Hardware watchdog 'iTCO_wdt', version 0 Jun 15 01:24:49 earth systemd[1]: Set hardware watchdog to 30s. I have checked with wd_keepalive and I have a few more observations: * The freeze did not appear when wd_keepalive is used instead of systemd * The freeze appears, if I kill wd_keepalive, so the freeze itself seems to be a bug in the iTCO_wdt driver/hardware. So looks like fdd9b8655933 somehow results in systemd being too slow to ping the watchdog in time. -- Sebastian > -Original Message- > From: Sebastian Reichel [mailto:s...@debian.org] > Sent: Wednesday, June 15, 2016 02:44 > To: Debian Bug Tracking System > Subject: Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after > suspend/resume due to iAMT watchdog > > Source: linux > Version: 4.5.5-1 > Severity: normal > > Hi, > > My Lenovo Thinkpad X250 freezes a couple of seconds after resuming > from suspend. This happened with 4.5, but not with v4.6. I > bisected the problem using mainline kernel with Debian config to > the following commit: > > sre@earth ~/src/linux (git)-[fdd9b86...|bisect] % git bisect bad > fdd9b8655933c3eb3154fe1ed351c17b654258bd is the first bad commit commit > fdd9b8655933c3eb3154fe1ed351c17b654258bd > Author: Alexander Usyskin > Date: Fri Jan 8 00:49:21 2016 +0200 > > mei: wd: drop the watchdog code from the core mei driver > > Instead of integrating the iAMT watchdog in the mei core driver > we will create a watchdog device on the mei client bus and > create a driver for it. > > This patch removes the watchdog code from the mei core driver. > > Signed-off-by: Alexander Usyskin > Signed-off-by: Tomas Winkler > Signed-off-by: Greg Kroah-Hartman > > My system was configured to use the watchdog via "RuntimeWatchdogSec=30" > in "/etc/systemd/system.conf". After disabling the feature no system freeze > happens after suspend/resume cycle. > > -- Sebastian > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (1000, 'testing'), (500, 'unstable'), (200, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, armhf > > Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > - > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > signature.asc Description: PGP signature
Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog
Source: linux Version: 4.5.5-1 Severity: normal Hi, My Lenovo Thinkpad X250 freezes a couple of seconds after resuming from suspend. This happened with 4.5, but not with v4.6. I bisected the problem using mainline kernel with Debian config to the following commit: sre@earth ~/src/linux (git)-[fdd9b86...|bisect] % git bisect bad fdd9b8655933c3eb3154fe1ed351c17b654258bd is the first bad commit commit fdd9b8655933c3eb3154fe1ed351c17b654258bd Author: Alexander Usyskin Date: Fri Jan 8 00:49:21 2016 +0200 mei: wd: drop the watchdog code from the core mei driver Instead of integrating the iAMT watchdog in the mei core driver we will create a watchdog device on the mei client bus and create a driver for it. This patch removes the watchdog code from the mei core driver. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman My system was configured to use the watchdog via "RuntimeWatchdogSec=30" in "/etc/systemd/system.conf". After disabling the feature no system freeze happens after suspend/resume cycle. -- Sebastian -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (1000, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#819540: valadoc: diff for NMU version 0.23.2~git20150422-3.1
Hi, On Sun, May 29, 2016 at 12:06:32PM +0200, Tobias Frost wrote: > Control: tags 819540 + patch > Control: tags 819540 + pending > > Dear maintainer, > > I've prepared an NMU for valadoc (versioned as 0.23.2~git20150422-3.1) and > uploaded it to DELAYED/10. Please feel free to tell me if I > should delay it longer. > > The cherry-picked patch is this one: > https://git.gnome.org/browse/valadoc/patch/?id=5863c16c6585be9e29621b1c061817fc8b4ef6d3 > > Regards. Looks fine to me, feel free to remove the delay. -- Sebastian signature.asc Description: PGP signature
Bug#824029: tt-rss: Fails with php7 due to missing php-gettext
block 824029 by 823815 thanks Hi Sunil, On Wed, May 11, 2016 at 07:36:59PM +0530, Sunil Mohan Adapa wrote: > I upgraded to php7 and installed tt-rss. Neither the tt-rss > updater daemon nor the web UI work. > > The problem is fixed after installing php-gettext package. > php-gettext is supposed to be installed along with tt-rss as the > former is a depndency for the later. However, as php-gettext is > virually provided by php7.0-common, php- gettext package is not > being installed. This is https://bugs.debian.org/823815 . Fixing it requires changes to either php-gettext or php7.0-common first. -- Sebastian signature.asc Description: PGP signature
