Bug#994184: libseat1: Libseat1 requires uninstall systemd and install seatd and systemV init. But it is compatible with logind.
On Mon, Sep 13, 2021 at 08:11:59PM +0200, Sergio Costas wrote: > Hello: > > El 13/9/21 a las 17:47, Guido Günther escribió: > > Thanks for this. > > > I had already thought this might be an issue. I think the solution is to > > > build > > > src:seatd against libsystemd-dev rather then libelogind-dev. I have > > > already > > > tested the build and there are no issues. I just want to check with the > > > Debian > > > sway packagers that this won't break their plans. > > > > > > > I think building against libsystemd-dev is even prerferable for the > > > current use cases. But i think the fact that we pull in seatd is > > > > > > Depends: libc6 (>= 2.28), libelogind0 (>= 246.9.1), seatd | logind > > > > > > We should swap that to "logind | seatd" (so we keep the common default > > > in Debian but allow for a replacement). > > > Now that I see the dependencies, I think that the problem is another: logind > package doesn't exist. I suspect that it should be elogind. But neither that > would fix the problem, because both seatd and elogind are daemons for > sysvinit. The "logind" DBus interface is offered both by elogind (for people > that don't want to use systemd) and, AFAIK, by systemd itself. > > So, if I'm right (but please, confirm this with someone else because I'm NOT > an expert), I think that the dependencies should really be: > > libc6 (>= 2.28), libelogind0 (>= 246.9.1), seatd | logind | > systemd Ah right, logind in in the systemd not the logind package so i think it should be: Depends: systemd | elogind | seatd (again keeping systemd first since that is Debian's default). It would also make sense to extend the seatd package description to indicate that seat is only needed if no other implementation (logind or elgind) is used. Cheers, -- Guido > > But, again, take this with a lot of salt. > > -- > > Nos leemos >RASTER(Linux user #228804) > rasters...@gmail.comhttps://www.rastersoft.com >
Bug#993992: i386 regression
The bugs on mips, mips64el were unrelated – a problem with the proj8.patch (headers now conflicting due to proj.h in proj8 conflicting with hdf-eos5). This was resolved in 6.6.2-9. Remaining is a definite regression with gcc, or more correctly gfortran ; testing with gfortran 10.2.1-6 from bullseye works ; regression with 10.3.0-10 (and also 11.2.0-5). The generated “Iftran” compiler created from Iftran.f fails to compile correctly. Alastair
Bug#994202: neutron: CVE-2021-40797: Routes middleware memory leak for nonexistent controllers
Source: neutron Version: 2:18.1.0-3 Severity: important Tags: security upstream Forwarded: https://bugs.launchpad.net/neutron/+bug/1942179 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for neutron. CVE-2021-40797[0]: | An issue was discovered in the routes middleware in OpenStack Neutron | before 16.4.1, 17.x before 17.2.1, and 18.x before 18.1.1. By making | API requests involving nonexistent controllers, an authenticated user | may cause the API worker to consume increasing amounts of memory, | resulting in API performance degradation or denial of service. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-40797 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40797 [1] https://bugs.launchpad.net/neutron/+bug/1942179 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#994203: fails to start with silent_jack_error_callback
Package: jackd Version: 5+nmu1 Severity: grave I have tried to use jackd in bullseye (because pipewire was giving me problems in ardour) and it seems I can't start it at all: anarcat@curie:~(main)$ jackd jackd: symbol lookup error: jackd: undefined symbol: silent_jack_error_callback I also tried to start it with the explicit "alsa" or "dummy" backends, no luck. qjackctl also fails to start jack, which it tries to run with; /usr/bin/jackd -dalsa -dhw:0 -r48000 -p1024 -n2 It fails with the same error. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jackd depends on: ii jackd2 1.9.17~dfsg-1 jackd recommends no packages. jackd suggests no packages. -- debconf-show failed
Bug#994205: Compilation of libopenshot fails with FFmpeg 4.4
Package: libopenshot Version: 0.2.5+dfsg1-5 When libopenshot (v. 0.2.5+dfsg1-5) is compiled with FFMPEG 4.4-6 (now in bookworm/sid) compilation fails. The patch in attachment (proposed here: https://github.com/OpenShot/libopenshot/pull/698) fixes the issue. I am using Ubuntu 20.04, kernel 5.11.0-34-generic and libc6 2.31-0ubuntu9.diff -Nru libopenshot-0.2.5.orig/src/FFmpegWriter.cpp libopenshot-0.2.5/src/FFmpegWriter.cpp --- libopenshot-0.2.5.orig/src/FFmpegWriter.cpp 2020-03-03 03:00:06.0 -0500 +++ libopenshot-0.2.5/src/FFmpegWriter.cpp 2021-09-11 22:05:52.0 -0400 @@ -1710,7 +1710,10 @@ audio_encoder_buffer_size, 0); // Create output frame (and allocate arrays) - frame_final->nb_samples = audio_input_frame_size; +frame_final->nb_samples = audio_input_frame_size; +frame_final->channels = info.channels; +frame_final->format = audio_codec->sample_fmt; +frame_final->channel_layout = info.channel_layout; av_samples_alloc(frame_final->data, frame_final->linesize, info.channels, frame_final->nb_samples, audio_codec->sample_fmt, 0); // Convert audio samples RUNNING ALL TESTS [libvpx @ 0x5620a7020700] v1.10.0 [libvpx @ 0x5620a7020700] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] using cpu capabilities: MMX2 SSE2 SSE3 Cache64 [libx264 @ 0x5620a7363100] profile High, level 3.1, 4:2:0, 8-bit [libx264 @ 0x5620a7363100] 264 - core 160 r3011 cde9a93 - H.264/MPEG-4 AVC codec - Copyleft 2003-2020 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=8 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=2 keyint=12 keyint_min=1 scenecut=40 intra_refresh=0 rc_lookahead=12 rc=abr mbtree=1 bitrate=5000 ratetol=1.0 qcomp=0.60 qpmin=2 qpmax=30 qpstep=4 ip_ratio=1.40 aq=1:1.00 [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it [libx264 @ 0x5620a7363100] Ignoring attempt to flush encoder that doesn't support it /home/nicola/Software/Ubuntu/openshot/test/libopenshot-0.2.5+dfsg1/tests/FFmpegWriter_Tests.cpp:116:1: error: Failure in Options_Overloads: Expected 1 but was 0 /home/nicola/Software/Ubuntu/openshot/test/libopenshot-0.2.5+dfsg1/tests/FFmpegWriter_Tests.cpp:119:1: error: Failure in Options_Overloads: Expected 2 but was 0 /home/nicola/Software/Ubuntu/openshot/test/libopenshot-0.2.5+dfsg1/tests/FFmpegWriter_Tests.cpp:120:1: error: Failure in Options_Overloads: Expected 3 but was 4 libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile FAILURE: 1 out of 93 tests failed (3 failures). Test time: 23.54 seconds.
Bug#994204: dh_installsystemd: --no-stop-on-upgrade has no effect, seemingly broken in 6067bc2f
Package: debhelper Version: 13.5.1 Severity: normal X-Debbugs-Cc: ni...@thykier.net Dear Maintainer, First let me give a bit of context: I was putting some work on the docker.io package. Right now docker.io depends on needrestart, so it's not affected by this bug. However I was working on removing the needrestart dependency, hence making it a "normal package", with regard to restarting the docker daemon when the package is upgraded. So I removed needrestart from the docker.io Depends, I rebuilt the package, and installed it again and again, to check whether the daemon was restarted during the package re-installation. And I was surprised to see that yes, dockerd was restarted all the time. However the debian/rules for docker.io explicitly states that it should not: override_dh_installsystemd: dh_installsystemd -v --name=docker --no-stop-on-upgrade --no-restart-after-upgrade The man page of dh_installsystemd says: --no-stop-on-upgrade Do not stop service on upgrade. This has the side-effect of not restarting the service as a part of the upgrade. So if I understand properly, this is a bug. We can see which postinst snippets are installed during the build of the package in eg. [1], I'll reproduce it here for convenience: dh_installsystemd -v --name=docker --no-stop-on-upgrade --no-restart-after-upgrade install -d debian/docker.io/lib/systemd/system install -p -m0644 debian/docker.io.docker.service debian/docker.io/lib/systemd/system/docker.service install -p -m0644 debian/docker.io.docker.socket debian/docker.io/lib/systemd/system/docker.socket [META] Append autosnippet "postinst-systemd-enable" to postinst [debian/.debhelper/generated/docker.io/postinst.service] [META] Append autosnippet "postinst-systemd-enable" to postinst [debian/.debhelper/generated/docker.io/postinst.service] [META] Prepend autosnippet "postrm-systemd" to postrm [debian/docker.io.postrm.debhelper.new] mv debian/docker.io.postrm.debhelper.new debian/docker.io.postrm.debhelper [META] Append autosnippet "postinst-systemd-start" to postinst [debian/.debhelper/generated/docker.io/postinst.service] [META] Prepend autosnippet "prerm-systemd-restart" to prerm [debian/.debhelper/generated/docker.io/prerm.service.new] mv debian/.debhelper/generated/docker.io/prerm.service.new debian/.debhelper/generated/docker.io/prerm.service [META] Prepend autosnippet "postrm-systemd-reload-only" to postrm [debian/docker.io.postrm.debhelper.new] mv debian/docker.io.postrm.debhelper.new debian/docker.io.postrm.debhelper Looking at the snippet postinst-systemd-start, we can see that what it does is actually "deb-systemd-invoke restart". I believe this is the problem, it should be "start" instead. And indeed, it used to be start, and was changed to restart very recently (Jul 11th), in this commit: https://salsa.debian.org/debian/debhelper/-/commit/6067bc2 I don't really know what's the proper fix here, since this commit was not trivial, and just changing it back to "start" might (or might not) break something else. Cheers, Arnaud -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debhelper depends on: ii autotools-dev20180224.1+nmu1 ii dh-autoreconf20 ii dh-strip-nondeterminism 1.12.0-1 ii dpkg 1.20.9 ii dpkg-dev 1.20.9 ii dwz 0.14-1 ii file 1:5.39-3 ii libdebhelper-perl13.5.1 ii libdpkg-perl 1.20.9 ii man-db 2.9.4-2 ii perl 5.32.1-5 ii po-debconf 1.0.21+nmu1 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 2.202101 -- no debconf information
Bug#994206: libopenshot requires deprecated libavresample-dev, leading to broken system
Package: libopenshot Version: 0.2.5+dfsg1-5 libopenshot (v. 0.2.5+dfsg1-5) requires libavresample-dev in deboan/control. However, with FFmpeg 4.4-6, libavresample-dev is not available in version 4.4-5, leaving the system broken. Replacing libavresample-dev with libswresample-dev in debian/control fixes the issue. I am using Ubuntu 20.04, kernel 5.11.0-34-generic and libc6 2.31-0ubuntu9.
Bug#994201: gitlab-workhorse: FTBFS with Go 1.17
On Mon, 13 Sep 2021 12:27:51 -0500 William 'jawn-smith' Wilson wrote: > gitlab-workhorse FTBFS with Go 1.17. There is due to a build time test failing. > There is already an upstream change to the failing test case that succeeds with > Go 1.17. This patch applies the upstream change. This issue is still present in > the experimental version of gitlab-workhorse: 8.59.0-1 gitlab-workhorse binary package is now built with src:gitlab but this is still in NEW. https://ftp-master.debian.org/new/gitlab_14.0.10-1.html So once this is accepted and we can upload it to unstable (some dependencies are only in experimental right now), we can remove the src:gitlab-workhorse package from the archive. > In Ubuntu, the attached patch was applied to achieve the following: > > Build package from source with Go 1.17 > > * Cherry pick upstream test case change to resolve FTBFS > with Go 1.17 (LP: #1943475) > > > Thanks for considering the patch.
Bug#994130: RFS: lebiniou/3.62.0-1 -- user-friendly, powerful music visualization / VJing tool
Hi Adam, How did you test it ? I usesd the instructions in https://wiki.debian.org/ContinuousIntegration/autopkgtest and didn't get an error Thanks, On September 13, 2021 2:11:59 AM GMT+02:00, Adam Borowski wrote: >On Sun, Sep 12, 2021 at 02:51:28PM +0200, Olivier Girondel wrote: >> * Package name: lebiniou >> Version : 3.62.0-1 > >> * New upstream release 3.62.0. >> * debian/control: Build-Depends: Remove htmlmin, python3-setuptools. >> * debian/control: Build-Depends: Add liblo-dev. >> * debian/copyright: Update. >> * debian/lebiniou.lintian-overrides: Update. >> * debian/rules: Remove override_dh_autoconfigure. >> * debian/source/lintian-overrides: Remove. > >Hi! >The autopkgtest fails with: > >mkdir: cannot create directory ‘/home/kilobyte/.lebiniou’: No such file or >directory >cp: cannot create regular file '/home/kilobyte/.lebiniou': No such file or >directory >cat: /home/kilobyte/.lebiniou/lebiniou.json: No such file or directory > >[!] Failed to load settings: unable to open >/home/kilobyte/.lebiniou/lebiniou.json: No such file or directory >ALSA lib confmisc.c:855:(parse_card) cannot find card '0' >ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_card_inum >returned error: No such file or directory >ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings >ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_concat returned >error: No such file or directory >ALSA lib confmisc.c:1334:(snd_func_refer) error evaluating name >ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_refer returned >error: No such file or directory >ALSA lib conf.c:5599:(snd_config_expand) Evaluate error: No such file or >directory >ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM default >O_o error opening PCM device default >/usr/share/lebiniou/test/lebiniou-test.sh: line 57: 15722 Aborted > lebiniou $OPTIONS > $AUTOPKGTEST_TMP/video1.log >[!] Failed to load settings: unable to open >/home/kilobyte/.lebiniou/lebiniou.json: No such file or directory >ALSA lib confmisc.c:855:(parse_card) cannot find card '0' >ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_card_inum >returned error: No such file or directory >ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings >ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_concat returned >error: No such file or directory >ALSA lib confmisc.c:1334:(snd_func_refer) error evaluating name >ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_refer returned >error: No such file or directory >ALSA lib conf.c:5599:(snd_config_expand) Evaluate error: No such file or >directory >ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM default >O_o error opening PCM device default >/usr/share/lebiniou/test/lebiniou-test.sh: line 62: 15723 Aborted > lebiniou $OPTIONS > $AUTOPKGTEST_TMP/video2.log >ls: cannot access '/tmp/autopkgtest.Onnpyt/autopkgtest_tmp/*.mp4': No such >file or directory > >You can't use $HOME in autopkgtests. > > >Meow! >-- >⢀⣴⠾⠻⢶⣦⠀ >⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. >⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi >⠈⠳⣄ > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Bug#994184: libseat1: Libseat1 requires uninstall systemd and install seatd and systemV init. But it is compatible with logind.
On Mon, Sep 13, 2021 at 08:11:59PM +0200, Sergio Costas wrote: > Now that I see the dependencies, I think that the problem is another: logind > package doesn't exist. I suspect that it should be elogind. But neither that > would fix the problem, because both seatd and elogind are daemons for > sysvinit. The "logind" DBus interface is offered both by elogind (for people > that don't want to use systemd) and, AFAIK, by systemd itself. logind is a virtual package provided by libpam-systemd and libpam-elogind. So I think the dependencies are fine as they are. I have just uploaded with the build dep changed to libsystemd-dev which, I think, will fix this. Thanks. Mark
Bug#994210: ITP: node-is-blob -- check if a value is Blob
On തി, സെപ്റ്റം 13 2021 at 06:12:12 വൈകു + +, mdbi...@disroot.org wrote: Package: wnpp Severity: wishlist Owner: Mohammed Bilal X-Debbugs-CC: debian-de...@lists.debian.org * Package name : node-is-blob Version : 2.1.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/is-blob#readme * License : Expat Programming Lang: JavaScript Description : Check if a value is Blob Simple module that can be used in browsers to check if a blob/file is present. . Node.js is an event-based server-side JavaScript engine. This is my first time packaging for debian. So I would need a sponsor for this package. Hi Bilal, This is a very small module and we don't create separate packages for small modules anymore. Are you packaging this as a dependency of any other packages? It can be included in other packages instead. See https://wiki.debian.org/Javascript/GroupSourcesTutorial
Bug#994212: r-cran-gprofiler: Obsolete package, replaced with r-cran-gprofiler2
Package: r-cran-gprofiler Version: 0.7.0-2 Severity: serious X-Debbugs-Cc: nil...@debian.org Dear Maintainer, r-cran-gprofiler has been replaced with r-cran-gprofiler2 and hence the former should be kept out of testing. Cheers, -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages r-cran-gprofiler depends on: ii r-base-core [r-api-4.0] 4.0.4-1 pn r-cran-plyr pn r-cran-rcurl r-cran-gprofiler recommends no packages. r-cran-gprofiler suggests no packages.
Bug#994184: libseat1: Libseat1 requires uninstall systemd and install seatd and systemV init. But it is compatible with logind.
Hi, On Mon, Sep 13, 2021 at 07:19:08PM +0100, Mark Hindley wrote: > On Mon, Sep 13, 2021 at 08:11:59PM +0200, Sergio Costas wrote: > > Now that I see the dependencies, I think that the problem is another: logind > > package doesn't exist. I suspect that it should be elogind. But neither that > > would fix the problem, because both seatd and elogind are daemons for > > sysvinit. The "logind" DBus interface is offered both by elogind (for people > > that don't want to use systemd) and, AFAIK, by systemd itself. > > logind is a virtual package provided by libpam-systemd and > libpam-elogind. > > So I think the dependencies are fine as they are. > > I have just uploaded with the build dep changed to libsystemd-dev which, I > think, will fix this. I think it would still be good to have a non-virtual package first and that match Debian's default and maybe expand on the description on the purpose of seatd a bit. We can file patches/separate issues for that though. Cheers, -- Guido > > Thanks. > > Mark >
Bug#969202: ITA: binutils-avr -- Binary utilities supporting Atmel's AVR targets
Owner: knapper...@aol.com
Bug#994209: Markdown links syntax performance issue
I am attaching here the related new patch, which is also available in
the merge request added at
https://salsa.debian.org/vim-team/vim/-/merge_requests/5.
Best,
-Marco
From: Marco Villegas
Date: Mon, 13 Sep 2021 12:42:32 -0500
Subject: Mitigate markdown syntax link performance issue
Adapted from K.Takata suggestion at
https://github.com/vim/vim/issues/6777#issuecomment-684776825
Upstream issue at https://github.com/vim/vim/issues/6777
Related issue https://github.com/vim/vim/issues/2049
Closes: #994209
Signed-off-by: Marco Villegas
---
runtime/syntax/markdown.vim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/runtime/syntax/markdown.vim b/runtime/syntax/markdown.vim
index 17b61c2..860cfe5 100644
--- a/runtime/syntax/markdown.vim
+++ b/runtime/syntax/markdown.vim
@@ -79,7 +79,7 @@ syn region markdownUrlTitle matchgroup=markdownUrlTitleDelimiter start=+"+ end=+
syn region markdownUrlTitle matchgroup=markdownUrlTitleDelimiter start=+'+ end=+'+ keepend contained
syn region markdownUrlTitle matchgroup=markdownUrlTitleDelimiter start=+(+ end=+)+ keepend contained
-syn region markdownLinkText matchgroup=markdownLinkTextDelimiter start="!\=\[\%(\%(\_[^][]\|\[\_[^][]*\]\)*]\%( \=[[(]\)\)\@=" end="\]\%( \=[[(]\)\@=" nextgroup=markdownLink,markdownId skipwhite contains=@markdownInline,markdownLineStart
+syn region markdownLinkText matchgroup=markdownLinkTextDelimiter start="!\=\[\%(\_[^][]*\%(\[\_[^][]*\]\_[^][]*\)*]\%( \=[[(]\)\)\@=" end="\]\%( \=[[(]\)\@=" nextgroup=markdownLink,markdownId skipwhite contains=@markdownInline,markdownLineStart
syn region markdownLink matchgroup=markdownLinkDelimiter start="(" end=")" contains=markdownUrl keepend contained
syn region markdownId matchgroup=markdownIdDelimiter start="\[" end="\]" keepend contained
syn region markdownAutomaticLink matchgroup=markdownUrlDelimiter start="<\%(\w\+:\|[[:alnum:]_+-]\+@\)\@=" end=">" keepend oneline
Bug#944359: neomutt: can't attach symlinked file anymore
Did you try with 20201127 in Debian 11.0? I tried and it was working. -- Stefan
Bug#994160: libmojolicious-plugin-assetpack-perl: newer upstream version (2.13) available
On Mon, 13 Sep 2021 01:38:26 +0200, Philip Hands wrote: > and here: > https://github.com/mojolicious/mojo-assetpack/commits/main > mantenance has now resumed under the aegis of the mojolicious team. 2.13-1 is already in Git but has a note in d/changelog: WAITS-FOR: libmojolicious-perl 9.0 so it's "just" waiting for someone to update Mojolicious to a new major release. (I think I even looked at it and saw that it needs update to the embedded jquery etc. handling and skipped to one of the other almost 200 packages with a new upstream release which was more straightforward. But we'll get there!) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Paco de Lucia: Camaron [Rondena] signature.asc Description: Digital Signature
Bug#994197: mirror submission for mirror.johnnybegood.fr
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.johnnybegood.fr Type: leaf Archive-architecture: amd64 i386 Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Valentin DI BETTA Country: FR France Location: Paris, France Trace Url: http://mirror.johnnybegood.fr/debian/project/trace/ Trace Url: http://mirror.johnnybegood.fr/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.johnnybegood.fr/debian/project/trace/mirror.johnnybegood.fr
Bug#945825: [cmake] cannot find development files for default Python
On Wed, 18 Nov 2020 14:30:17 +0100 Marc CHEVRIER wrote: So, for the interpreter, `python3.9’ will be searched first, after ‘python3.8’, etc… When multiple versions are installed, the most recent version of the interpreter is selected. And, after, only ‘Development’ artefacts matching this version will be searched for. Starting with CMake 3.15, the default Python_FIND_STRATEGY is LOCATION, i.e. the search will stop with the first found version (see CMP0094). Therefore, this issue can also be resolved by moving the Debian default version to the top of the list, thereby making sure that it is used by default: https://salsa.debian.org/cmake-team/cmake/-/merge_requests/8 Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#994208: "not implemented" while exporting a track from ardour
Package: pipewire Version: 0.3.19-4 Severity: normal Control: fixed -1 0.3.35-1 It seems Ardour can't export tracks when the backend is down. Or, more specifically, when it doesn't implement a ... certain something? The actual error I got is this: sep 13 13:35:38 curie ardour-6.5.0~ds0[232017]: jack-client 0x55e8be5ffaa0: not implemented If I stop Pipewire: systemctl disable pipewire.socket systemctl stop pipewire.service ... and then restart Ardour with an ALSA backend, I can actually export the track. I originally filed this as #994207 against Ardour because it stumbled upon a fairly simple job (exporting a track) when running under pipewire. But considering how Ardour works, I don't think that can be fixed there. I'll also note that this doesn't occur in bookworm. Note that this bug was filed after confirming the former, so the following metadata will look inaccurate. The version that works is 0.3.35, and the one that *does not* work (and which the bug applies on) is 0.3.19-4. A. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pipewire depends on: ii init-system-helpers 1.60 ii libpipewire-0.3-modules 0.3.35-1 ii pipewire-bin 0.3.35-1 pipewire recommends no packages. pipewire suggests no packages. -- debconf-show failed
Bug#994165: pipewire: add pipewire-alsa/pipewire-jack packages
Hi, I suppose that you have already got a look to pipewire-audio-client-libraries that gives your expectation. May be you just propose to split it into 2 separated packages? Also the long description of pipewire-audio-client-libraries mentions PulseAudio which is already entirely took-apart into pipewire-pulse. I mean that nothing in pipewire-audio-client-libraries is related to PulseAudio: $ apt-file list pipewire-audio-client-libraries pipewire-audio-client-libraries: /etc/alsa/conf.d/50-pipewire.conf pipewire-audio-client-libraries: /usr/bin/pw-jack pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_ctl_pipewire.so pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pipewire.so pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0 pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0.335.0 pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjacknet.so pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjacknet.so.0 pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjacknet.so.0.335.0 pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjackserver.so pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjackserver.so.0 pipewire-audio-client-libraries: /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjackserver.so.0.335.0 pipewire-audio-client-libraries: /usr/share/alsa/alsa.conf.d/50-pipewire.conf pipewire-audio-client-libraries: /usr/share/doc/pipewire-audio-client-libraries/README.Debian pipewire-audio-client-libraries: /usr/share/doc/pipewire-audio-client-libraries/changelog.Debian.gz pipewire-audio-client-libraries: /usr/share/doc/pipewire-audio-client-libraries/copyright pipewire-audio-client-libraries: /usr/share/doc/pipewire-audio-client-libraries/examples pipewire-audio-client-libraries: /usr/share/doc/pipewire/examples/README.audio pipewire-audio-client-libraries: /usr/share/doc/pipewire/examples/alsa.conf.d/99-pipewire-default.conf pipewire-audio-client-libraries: /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-x86_64-linux-gnu.conf pipewire-audio-client-libraries: /usr/share/lintian/overrides/pipewire-audio-client-libraries pipewire-audio-client-libraries: /usr/share/man/man1/pw-jack.1.gz Best, Patrice On Mon, 13 Sep 2021 10:45:59 +0800 Paul Wise wrote: > Source: pipewire > Severity: wishlist > > On Arch Linux, to enable forwarding of the ALSA and JACK APIs to > PipeWire you only have to install pipewire-alsa and pipewire-jack while > on Debian you have to manually copy some files around. I think it would > be better to follow the Arch Linux model and have -alsa/-jack packages > just like there is the pipewire-pulse package in Debian. > > https://archlinux.org/packages/extra/x86_64/pipewire-alsa/files/ > https://archlinux.org/packages/extra/x86_64/pipewire-jack/files/ > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise
Bug#994209: Markdown links syntax performance issue
Package: vim-runtime Version: 2:8.2.2434-3 Severity: important Tags: upstream On markdown files of a certain size, the markdown syntax regular expression to detect links can produce a E363 error. More specifically "E363: pattern uses more memory than 'maxmempattern'". This is likely expected since the regular expression is resource heavy. A sample markdown file is attached, where the problem can be reproduced. After opening with a command like the mentioned above, try to add a markdown link at the first word in the file; adding a "[" at the start of the file will produce the error. vim -u NONE -U NONE -c 'syntax enable' sample.md Gladly, there is already a work-around available to prevent the error, which improves the regular expression. More information at the upstream related issues https://github.com/vim/vim/issues/2049 and https://github.com/vim/vim/issues/6777. This is likely bug fix relevant for unstable, testing, and stable. I will provide related changes in a bit. Best, -Marco Vero iriure in dolor veniam ullamcorper ut commodo. Accumsan nisl et consectetuer dolore, nonummy duis te blandit quis duis vulputate eu. Ex wisi dolore in diam ea delenit nibh velit vero augue illum, consequat: delenit quis consequat. Nonummy dignissim feugait ullamcorper ea ut quis iusto ad in iriure! Qui duis minim ut veniam laoreet in erat. Commodo consequat nostrud zzril dolor tincidunt aliquam laoreet ad dolor magna aliquip dolore. Vero adipiscing magna vel sit consequat nulla lorem. Duis ullamcorper nulla suscipit ad vel, nulla esse. Et minim: blandit dolor molestie facilisis esse ea vulputate et adipiscing nibh. Quis ex te dolor ut duis iusto zzril, quis? Nulla dolor minim exerci, esse ea suscipit nibh autem. Zzril duis tincidunt et elit lorem commodo laoreet nibh magna luptatum delenit commodo veniam dolore! In qui -- quis eros dignissim dolore, dignissim autem lobortis ullamcorper nonummy, vero qui duis. Nonummy illum dolore lorem, vel dolor amet dignissim dolor nulla velit veniam illum minim at? Velit lobortis ut praesent lobortis molestie in eum! Erat et lobortis euismod nisl nibh -- vel dolor praesent! Praesent dolor velit, consectetuer illum facilisi suscipit volutpat ea, exerci: euismod et, minim duis facilisis, blandit. Erat dolore volutpat consequat facilisis duis, in accumsan veniam. Duis lorem praesent, odio, dolore vero dolor at enim luptatum odio nulla -- diam feugait. Volutpat, ut delenit wisi luptatum blandit illum commodo dignissim quis. Lobortis erat: eum veniam blandit vel ea dolore. Wisi ut nisl laoreet accumsan, in blandit, nisl, wisi ex consectetuer te tincidunt laoreet illum -- enim. Lorem dolore euismod aliquip eum, quis dolore vel feugait autem eu, ex vero dolore eros luptatum. Praesent nostrud consequat tation diam exerci duis luptatum eros eros hendrerit adipiscing wisi quis? Illum minim illum qui vero delenit luptatum ex ex. Quis aliquam delenit tation autem, aliquip in dignissim dolore facilisi exerci; sed esse suscipit minim. Feugait enim vel odio qui ea nisl feugiat quis aliquip in tation dolor consectetuer dolore at. Dignissim, quis praesent wisi lorem -- veniam et praesent. Nostrud ea wisi dignissim adipiscing tation; nonummy diam nulla, vel ex ut zzril in consequat. Wisi dolor iusto -- molestie, vero esse vulputate augue ex et praesent praesent enim dolor nostrud? Ut minim veniam nulla exerci veniam, exerci vel iusto dolor. Duis in dolore, amet dolore eum luptatum sit volutpat. Ut dolore feugiat zzril suscipit iriure et in, ullamcorper vulputate elit lobortis tation sit. Delenit nibh minim veniam augue suscipit consequat ut adipiscing vero nisl ex. Erat suscipit consectetuer nisl volutpat accumsan dolore iriure iusto sit in ex duis nonummy euismod. Nulla ullamcorper eum, qui feugiat accumsan duis nisl facilisis enim sed sit! Accumsan iriure dolor vel dolore blandit ut sit nonummy adipiscing elit velit, vel, nisl tation nonummy. Nisl odio sit in exerci ad dolore duis dolor duis diam veniam consectetuer diam hendrerit nulla. Ut vulputate facilisis suscipit dolore et feugait nostrud euismod iusto volutpat in praesent at commodo. Velit nulla diam autem lorem, qui qui ut volutpat duis. Ex ea illum consectetuer consequat nostrud delenit dolore tation elit dolor vel odio veniam? Elit, dolore nulla feugait quis feugiat sit et, suscipit iusto enim autem facilisi duis? Qui in aliquip, tincidunt ex sed delenit wisi. Euismod te, in facilisi illum qui minim vulputate, ut accumsan ea odio delenit minim, praesent feugait? Magna iusto qui eum at zzril at, nulla quis vel et eum suscipit dolor diam. Augue veniam in dignissim sed adipiscing ad ut dolore. Sit commodo laoreet hendrerit ad euismod exerci zzril, eros, nonummy ullamcorper autem veniam. Tation ex consectetuer nibh dignissim, vero laoreet -- ullamcorper illum. Facilisi, et, hendrerit dolor iusto vero tincidunt dolor nulla; ipsum, eros sit amet veniam? Et odio diam praesent iriure accumsan augue eum commodo facilisi lorem
Bug#994184: libseat1: Libseat1 requires uninstall systemd and install seatd and systemV init. But it is compatible with logind.
Hello: El 13/9/21 a las 17:47, Guido Günther escribió: Thanks for this. I had already thought this might be an issue. I think the solution is to build src:seatd against libsystemd-dev rather then libelogind-dev. I have already tested the build and there are no issues. I just want to check with the Debian sway packagers that this won't break their plans. I think building against libsystemd-dev is even prerferable for the current use cases. But i think the fact that we pull in seatd is Depends: libc6 (>= 2.28), libelogind0 (>= 246.9.1), seatd | logind We should swap that to "logind | seatd" (so we keep the common default in Debian but allow for a replacement). Now that I see the dependencies, I think that the problem is another: logind package doesn't exist. I suspect that it should be elogind. But neither that would fix the problem, because both seatd and elogind are daemons for sysvinit. The "logind" DBus interface is offered both by elogind (for people that don't want to use systemd) and, AFAIK, by systemd itself. So, if I'm right (but please, confirm this with someone else because I'm NOT an expert), I think that the dependencies should really be: libc6 (>= 2.28), libelogind0 (>= 246.9.1), seatd | logind | systemd But, again, take this with a lot of salt. -- Nos leemos RASTER(Linux user #228804) rasters...@gmail.comhttps://www.rastersoft.com
Bug#994184: libseat1: Libseat1 requires uninstall systemd and install seatd and systemV init. But it is compatible with logind.
Hi: El 13/9/21 a las 20:26, Guido Günther escribió: On Mon, Sep 13, 2021 at 08:11:59PM +0200, Sergio Costas wrote: Now that I see the dependencies, I think that the problem is another: logind package doesn't exist. I suspect that it should be elogind. But neither that would fix the problem, because both seatd and elogind are daemons for sysvinit. The "logind" DBus interface is offered both by elogind (for people that don't want to use systemd) and, AFAIK, by systemd itself. So, if I'm right (but please, confirm this with someone else because I'm NOT an expert), I think that the dependencies should really be: libc6 (>= 2.28), libelogind0 (>= 246.9.1), seatd | logind | systemd Ah right, logind in in the systemd not the logind package so i think it should be: Depends: systemd | elogind | seatd (again keeping systemd first since that is Debian's default). It would also make sense to extend the seatd package description to indicate that seat is only needed if no other implementation (logind or elgind) is used. As Mark Hindley commented, it seems that the problem is the dependency on libelogind0, which specifically conflicts with systemd and libsystemd0. The "logind" virtual package does exist and yes, I "have it installed" in my system. -- Nos leemos RASTER (Linux user #228804) rasters...@gmail.com https://www.rastersoft.com
Bug#994203: fails to start with silent_jack_error_callback
Control: reassign -1 jackd2 1.9.17~dfsg-1 Control: tags -1 moreinfo unreproducible On 2021-09-13 13:39:43, Antoine Beaupre wrote: > Package: jackd > Version: 5+nmu1 > Severity: grave You got the wrong package. This is the meta package that allows you to select between jackd and jackd2 > > I have tried to use jackd in bullseye (because pipewire was giving me > problems in ardour) and it seems I can't start it at all: > > anarcat@curie:~(main)$ jackd > jackd: symbol lookup error: jackd: undefined symbol: > silent_jack_error_callback This symbol is provided by libjackserver which jackd correctly links and depends on (via libjack-jackd2-0). So I suspect that you have some old libjackserver in your library search paths that interfers with jackd. So please provide a verbose error log from ld.so when it tries to resolve the symbol. Cheers > > I also tried to start it with the explicit "alsa" or "dummy" backends, > no luck. qjackctl also fails to start jack, which it tries to run > with; > > /usr/bin/jackd -dalsa -dhw:0 -r48000 -p1024 -n2 > > It fails with the same error. > -- System Information: > Debian Release: 11.0 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, > 'stable'), (1, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND > Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages jackd depends on: > ii jackd2 1.9.17~dfsg-1 > > jackd recommends no packages. > > jackd suggests no packages. > > -- debconf-show failed > -- Sebastian Ramacher
Bug#994195: RM: coyim/0.3.8+ds-6
On 2021-09-13 16:55:53, Sascha Steinbiss wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > Please remove coyim. It has an RC bug [0] that will require various new > dependencies and transitive dependencies, as upstream moved repositories and > requires new versions. Some dependencies also do not build anymore when > updated > to newer upstream versions (e.g. gotk3). > > Coyim has not made it into buster and bullseye and I as the maintainer do not > intend to invest more work into it. A RFA has been without response since > January 2021 [1]. > > Hence I suggest to remove it and, once it is gone, also get rid of the > obsolete > dependencies that coyim currently is the only reverse dependency of in > unstable. coyim is not in bookworm. Did you want request removal from unstable? Cheers > > Cheers > Sascha > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930332 > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979755 > -- Sebastian Ramacher
Bug#994213: node-matrix-js-sdk: CVE-2021-40823: E2EE vulnerability
Source: node-matrix-js-sdk Version: 9.11.0+~cs9.9.16-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for node-matrix-js-sdk. CVE-2021-40823[0]: | E2EE vulnerability If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-40823 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40823 [1] https://matrix.org/blog/2021/09/13/vulnerability-disclosure-key-sharing/ [2] https://github.com/matrix-org/matrix-js-sdk/commit/894c24880da0e1cc81818f51c0db80e3c9fb2be9 Regards, Salvatore
Bug#944772: neomutt: creating new Maildir folder does not work
Did you tried with version 20201127? I changed the FCC to a new Maildir folder and this was working in 20201127. -- Stefan
Bug#994203: fails to start with silent_jack_error_callback
On 2021-09-13 20:33:03, Sebastian Ramacher wrote: > Control: reassign -1 jackd2 1.9.17~dfsg-1 > Control: tags -1 moreinfo unreproducible > > On 2021-09-13 13:39:43, Antoine Beaupre wrote: >> Package: jackd >> Version: 5+nmu1 >> Severity: grave > > You got the wrong package. This is the meta package that allows you to > select between jackd and jackd2 > >> >> I have tried to use jackd in bullseye (because pipewire was giving me >> problems in ardour) and it seems I can't start it at all: >> >> anarcat@curie:~(main)$ jackd >> jackd: symbol lookup error: jackd: undefined symbol: >> silent_jack_error_callback > > This symbol is provided by libjackserver which jackd correctly links and > depends on (via libjack-jackd2-0). So I suspect that you have some old > libjackserver in your library search paths that interfers with jackd. > > So please provide a verbose error log from ld.so when it tries to > resolve the symbol. Interestingly, I cannot reproduce this anymore. It seems this was specifically related to the SNAFU I ran into while installing pipewire from bookworm on bullseye. So I guess this bug can be closed. a. -- The ultimate test of your knowledge is your capacity to convey it to another. - Richard Feynman
Bug#994208: Acknowledgement ("not implemented" while exporting a track from ardour)
Control: notfixed -1 0.3.35-1 > fixed -1 0.3.35-1 Actually, I'm not sure that's the case at all. I managed to make Ardour export the track with JACK, but I was mistaken: it was the real Jackd running there, not pipewire. Installing pipewire 0.3.35 on bullseye is currently... not a great idea. Things broke all the way up to gdm3 here, and I had to basically reboot to get my workstation back in order. So I'm not sure exactly how to test this further, but I can't imagine this is still a problem in newer pipewire versions. Maybe this fixed version is correct? -- What people say, what people do, and what they say they do are entirely different things. - Margaret Mead
Bug#994214: nomad FTBFS in unstable
Source: nomad Version: 0.12.10+dfsg1-3 Severity: serious Justification: FTBFS User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu impish Hi Dmitry, The nomad package fails to build from source in Ubuntu, so in the process of investigating this build failure I confirmed that it also fails to build in Debian unstable: [...] # github.com/hashicorp/nomad/drivers/shared/executor src/github.com/hashicorp/nomad/drivers/shared/executor/executor_universal_linux.go:125:36: cannot use groups (type *configs.Cgroup) as type *configs.Resources in argument to freezer.Set src/github.com/hashicorp/nomad/drivers/shared/executor/executor_universal_linux.go:137:37: cannot use groups (type *configs.Cgroup) as type *configs.Resources in argument to freezer.Set src/github.com/hashicorp/nomad/drivers/shared/executor/executor_universal_linux.go:159:36: cannot use groups (type *configs.Cgroup) as type *configs.Resources in argument to freezer.Set [...] dh_auto_build: error: cd _build && go install -trimpath -v -p 12 -a -tags "release ui nonvidia" github.com/hashicorp/nomad github.com/hashicorp/nomad/acl github.com/hashicorp/nomad/api github.com/hashicorp/nomad/api/contexts github.com/hashicorp/nomad/api/internal/testutil github.com/hashicorp/nomad/api/internal/testutil/discover github.com/hashicorp/nomad/api/internal/testutil/freeport github.com/hashicorp/nomad/client github.com/hashicorp/nomad/client/allocdir github.com/hashicorp/nomad/client/allocdir/input github.com/hashicorp/nomad/client/allochealth github.com/hashicorp/nomad/client/allocrunner github.com/hashicorp/nomad/client/allocrunner/interfaces github.com/hashicorp/nomad/client/allocrunner/state github.com/hashicorp/nomad/client/allocrunner/taskrunner github.com/hashicorp/nomad/client/allocrunner/taskrunner/getter github.com/hashicorp/nomad/client/allocrunner/taskrunner/interfaces github.com/hashicorp/nomad/client/allocrunner/taskrunner/restarts github.com/hashicorp/nomad/client/allocrunner/taskrunner/state github.com/hashicorp/nomad/client/allocrunner/taskrunner/template github.com/hashicorp/nomad/client/allocwatcher github.com/hashicorp/nomad/client/config github.com/hashicorp/nomad/client/consul github.com/hashicorp/nomad/client/devicemanager github.com/hashicorp/nomad/client/devicemanager/state github.com/hashicorp/nomad/client/dynamicplugins github.com/hashicorp/nomad/client/fingerprint github.com/hashicorp/nomad/client/interfaces github.com/hashicorp/nomad/client/lib/fifo github.com/hashicorp/nomad/client/lib/nsutil github.com/hashicorp/nomad/client/lib/streamframer github.com/hashicorp/nomad/client/logmon github.com/hashicorp/nomad/client/logmon/logging github.com/hashicorp/nomad/client/logmon/proto github.com/hashicorp/nomad/client/pluginmanager github.com/hashicorp/nomad/client/pluginmanager/csimanager github.com/hashicorp/nomad/client/pluginmanager/drivermanager github.com/hashicorp/nomad/client/pluginmanager/drivermanager/state github.com/hashicorp/nomad/client/servers github.com/hashicorp/nomad/client/state github.com/hashicorp/nomad/client/stats github.com/hashicorp/nomad/client/structs github.com/hashicorp/nomad/client/taskenv github.com/hashicorp/nomad/client/testutil github.com/hashicorp/nomad/client/vaultclient github.com/hashicorp/nomad/command github.com/hashicorp/nomad/command/agent github.com/hashicorp/nomad/command/agent/consul github.com/hashicorp/nomad/command/agent/event github.com/hashicorp/nomad/command/agent/host github.com/hashicorp/nomad/command/agent/monitor github.com/hashicorp/nomad/command/agent/pprof github.com/hashicorp/nomad/command/raft_tools github.com/hashicorp/nomad/devices/gpu/nvidia github.com/hashicorp/nomad/devices/gpu/nvidia/cmd github.com/hashicorp/nomad/devices/gpu/nvidia/nvml github.com/hashicorp/nomad/drivers/docker github.com/hashicorp/nomad/drivers/docker/cmd github.com/hashicorp/nomad/drivers/docker/docklog github.com/hashicorp/nomad/drivers/docker/docklog/proto github.com/hashicorp/nomad/drivers/docker/util github.com/hashicorp/nomad/drivers/exec github.com/hashicorp/nomad/drivers/java github.com/hashicorp/nomad/drivers/mock github.com/hashicorp/nomad/drivers/qemu github.com/hashicorp/nomad/drivers/rawexec github.com/hashicorp/nomad/drivers/shared/eventer github.com/hashicorp/nomad/drivers/shared/executor github.com/hashicorp/nomad/drivers/shared/executor/proto github.com/hashicorp/nomad/drivers/shared/resolvconf github.com/hashicorp/nomad/helper github.com/hashicorp/nomad/helper/args github.com/hashicorp/nomad/helper/boltdd github.com/hashicorp/nomad/helper/codec github.com/hashicorp/nomad/helper/constraints/semver github.com/hashicorp/nomad/helper/discover github.com/hashicorp/nomad/helper/escapingio github.com/hashicorp/nomad/helper/fields github.com/hashicorp/nomad/helper/flag-helpers github.com/hashicorp/nomad/helper/flatmap github.com/hashicorp/nomad/helper/freeport github.com/hashicorp/nomad/helper/gated-writer
Bug#993864: ITP: taskserver -- taskwarrior synchronisation server
I thought the tracker one at least is a public team, for which access shouldn't need to be approved. In any case, I don't appear to have any way to grant access. I've granted you access to the Salsa team. Welcome! Gordon On Sat, Sep 11, 2021 at 08:20:45PM +, Sergio Cipriano wrote: > Hi Gordon, > > I requested access to the Debian Tasktools Team. > May you accept my request? > > Sergio Cipriano. > > On Friday, September 10th, 2021 at 06:44, Gordon Ball > wrote: > > > Hi Sergio > > > > In that case, please take over the taskd package. Because I felt the > > > > package was abandoned, there has been a "don't migrate to testing" RC > > > > bug open for a while, so feel free to close that when you have something > > > > in better shape. > > > > I don't have a continuing interest in this package, so please remove me > > > > from the uploaders. You might want to join the tasktools team on tracker > > > > (team+taskto...@tracker.debian.org) and add that as a maintainer. > > > > Gordon > > > > On Wed, Sep 08, 2021 at 11:14:19AM +, Sergio Cipriano wrote: > > > > > Hi Gordon, > > > > > > On Wednesday, September 8th, 2021 at 02:16, Gordon Ball > > > gor...@chronitis.net wrote: > > > > > > > Hi Sergio > > > > > > > > Note that there is already `taskd` in the archive (former name of > > > > > > > > taskserver). It's not been uploaded for a number of years and I believed > > > > > > > > that it was dead upstream (and I had lost interest in using it). If > > > > > > > > you're interested you could either take over that package (and introduce > > > > > > > > a new binary name), or I can rm it in favour of taskserver. > > > > > > > > On Tue, Sep 07, 2021 at 09:24:51AM -0300, Sergio de Almeida Cipriano > > > > Junior wrote: > > > > > > > > > Package: wnpp > > > > > > > > > > Severity: wishlist > > > > > > > > > > Owner: Sergio de Almeida Cipriano Junior sergios...@protonmail.com > > > > > > > > > > X-Debbugs-Cc: debian-de...@lists.debian.org, sergios...@protonmail.com > > > > > > > > > > - Package name : taskserver > > > > > > > > > > Version : 1.1.0 > > > > > > > > > > Upstream Author : Göteborg Bit Factory > > > > > supp...@gothenburgbitfactory.org > > > > > > > > > > - URL : https://github.com/GothenburgBitFactory/taskserver > > > > > > > > > > - License : MIT > > > > > > > > > > Programming Lang: C++ > > > > > > > > > > Description : taskwarrior synchronisation server > > > > > > > > > > > > > > > Taskserver is a daemon or service that will allow you to share tasks > > > > > among > > > > > > > > > > different client applications, primarily Taskwarrior. > > > > > > I am interested in taskd and I would be glad to take over the package. > > > > > > Cheers Sergio.
Bug#785495: Bug is back on 3.38.2.1-1
On Thu, 25 Mar 2021 02:13:08 + Andre Etienne wrote: > On Sun, 28 Feb 2021 13:24:46 + Andre Etienne > wrote: > > On Sun, 28 Feb 2021 00:33:56 + Andre Etienne > > wrote: > > > On Sat, 27 Feb 2021 02:51:22 + Andre Etienne > > > wrote: > > > > Hi all, > > > > > > > > > > > > With Buster (gdm3 3.30.2-3 ) using DisallowTCP=false add the "-listen > > > > tcp" in command line and I can connect remotely. > > > > > > > > With gdm3 3.38.2.1-1, using DisallowTCP=false remove the "-nolisten > > tcp" > > > > but do not add "-listen tcp" so I can not connect remotely. > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Ok, > > > > > > I try a little trick: > > > > > > in gdm-server.c and gdm-x-session.c, I remove the conditional if: > > > > > > #ifdef HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY (and corresponding > #else > > > and #endif), leaving the remaining code. > > > > > > I compile the code and now I have the "-listen tcp" in command line. > > > > > > So the problem certainly come from the > > > HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY condition. > > > > > > Cheers > > > > > > > > > > > > > > > > Hi All, > > > > I re-download source from Debian site, and meson.build now include > > HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY condition. > > > > This solve my trouble, I have the "-listen tcp" in command line. > > > > Thanks > > > > > > > Hi, > > Well now that bullseye is in freeze stage, could you please recompile > the gdm3 package ? (as --listen tcp option is fixed) > > Thanks > Hello, Could it be possible for you to update gdm3 package (a simple recompile from source is enough) to allow "--listen tcp" flag for Debian Bullseye ? Thanks
Bug#994057: libegl-mesa0: 21.2.1-2 with intel graphic card produces artifact on firefox-esr
GLX is still the default for firefox-esr. EGL is a non-default configuration. Please report this bug to https://bugzilla.mozilla.org/enter_bug.cgi?format=__default__=1491303=Core=Graphics%3A%20WebRender and attach a screenshot. Thanks! I was not able to reproduce this bug with firefox-esr and Firefox Nightly with Basic (software rendering), WebRender (GLX=default) and MOZ_X11_EGL=1 WebRender on Debian Testing with libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 installed from unstable (Mesa 21.2.1 on Intel Iris Graphics 6100 (BDW GT3)). - Darkspirit I could not reply to this bug with my regular email address because Debian's mail server is not properly configured. "The mail system <994...@bugs.debian.org>: Server certificate not trusted" https://www.hardenize.com/report/bugs.debian.org/1631554082#email_certs
Bug#994211: libgc-source: Add ARC support
Package: libgc-source Version: 8.0.4-3 Severity: normal Tags: patch Dear Maintainer, Dear Maintainer, Please consider adding support of ARC architecture with a patch below. It's a back-port of upstream change [1] which will be a part of the next release whenever it happens. This is needed as we work on a Debian port for ARCprocessors. [1] https://github.com/ivmai/bdwgc/commit/968818a12c361a3a7fa6e8d8b851d04847335e58 -Alexey --- a/include/private/gcconfig.h +++ b/include/private/gcconfig.h @@ -658,6 +658,10 @@ EXTERN_C_BEGIN # define NONSTOP # define mach_type_known # endif +# if defined(__arc__) && defined(LINUX) +# define ARC +# define mach_type_known +# endif # if defined(__hexagon__) && defined(LINUX) #define HEXAGON #define mach_type_known @@ -2812,6 +2816,21 @@ EXTERN_C_BEGIN # endif # endif /* X86_64 */ +# ifdef ARC +# define CPP_WORDSZ 32 +# define MACH_TYPE "ARC" +# define ALIGNMENT 4 +# define CACHE_LINE_SIZE 64 +# ifdef LINUX +# define OS_TYPE "LINUX" +# define LINUX_STACKBOTTOM +# define COUNT_UNMAPPED_REGIONS +# define DYNAMIC_LOADING + extern int __data_start[] __attribute__((__weak__)); +# define DATASTART ((ptr_t)__data_start) +# endif +# endif /* ARC */ + # ifdef HEXAGON # define CPP_WORDSZ 32 # define MACH_TYPE "HEXAGON" -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal-proposed'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 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 /usr/bin/dash Init: unable to detect
Bug#989565: mergerfs: Duplicated file and directory names in Midnight Commander
Problem still exists. Bullseye has been released, please fix now. Thanks
Bug#994210: ITP: node-is-blob -- check if a value is Blob
Package: wnpp Severity: wishlist Owner: Mohammed Bilal mailto:mdbi...@disroot.org)> X-Debbugs-CC: debian-de...@lists.debian.org (mailto:debian-de...@lists.debian.org) * Package name : node-is-blob Version : 2.1.0 Upstream Author : Sindre Sorhus mailto:sindresor...@gmail.com)> (sindresorhus.com) * URL : https://github.com/sindresorhus/is-blob#readme (https://github.com/sindresorhus/is-blob#readme) * License : Expat Programming Lang: JavaScript Description : Check if a value is Blob Simple module that can be used in browsers to check if a blob/file is present. . Node.js is an event-based server-side JavaScript engine. This is my first time packaging for debian. So I would need a sponsor for this package.
Bug#994215: Enable CONFIG_FSL_MC_UAPI_SUPPORT
Package: src:linux
Version: linux/5.14.2-1~exp1
Please enable CONFIG_FSL_MC_UAPI_SUPPORT ("Management Complex (MC)
userspace support") for arm64.
This is needed to manage the onboard network interfaces on LX2160A-based
boards such as the SolidRun HoneyComb LX2. Without this configuration
option the onboard network interfaces can only be used in the state it is
handed over to Linux by the bootloader. In practice this means that while
e.g. lower speed interfaces may be set up, the faster SFP+ or QSFP28 ports
could be left deactivated and thus not usable.
If you have any questions I am happy to try to answer them.
Regards,
Chris
