Bug#997807: hyperic-sigar: FTBFS on riscv64: gcc: error: unrecognized command-line option ‘-m64’
Control: owner -1 ! Hi Aurelien, Thanks for your valuable insight into this issue. On 2021-10-25 00:31, Aurelien Jarno wrote: > The issue is that -m64 is not understood by GCC on riscv64. This is also > the case on a few other architectures, and I have noticed that you > already have a patch for that. I have tried to extend it (see attached > patch), and hyperic-sigar builds fine on riscv64. Could you please > consider applying it in the future uploads? > > Note however that instead of maintaining a long list of architectures > where -m64 is not needed might not be the best way, as this flag is > basically understood only on x86, p(ower)pc*, sparc* and s390*. In > addition this flag is basically not needed for a standard Debian > installation, where gcc already defaults to the correct bitness. You > might therefore want to simply drop those few lines. Your patch should definitely fix this. Nevertheless I am tempted to try out your suggestion to remove -m64 altogether (in experimental). Best, Andrius
Bug#997811: unbound crashes, remote dos?
Package: unbound Version: 1.13.1-1 Severity: normal Our unbound crashed a twice over the weekend, until I shut it down and replaced it with different software. Now that I'm back at work, I'm looking at the logs and found these in the kernel logs: Oct 24 04:59:27 resolver1 kernel: [3198942.847376] unbound[1211]: segfault at 108 ip 5623be4dcc39 sp 7febe13c4c40 error 4 in unbound[5623be419000+d6000] Oct 24 04:59:27 resolver1 kernel: [3198942.847414] Code: 74 62 4c 89 ef e8 97 4b f9 ff 48 89 c5 48 39 d8 74 52 48 85 c0 75 0f eb 4b 0f 1f 84 00 00 00 00 00 48 39 d8 74 3e 4c 8b 75 18 <49> 8b be 08 01 00 00 48 85 ff 74 1e e8 46 f1 f8 ff 85 c0 74 4a 49 Oct 24 07:50:14 resolver1 kernel: [ 8976.541688] unbound[1213]: segfault at 108 ip 557cb0287c39 sp 7fedf2aefc40 error 4 in unbound[557cb01c4000+d6000] Oct 24 07:50:14 resolver1 kernel: [ 8976.541756] Code: 74 62 4c 89 ef e8 97 4b f9 ff 48 89 c5 48 39 d8 74 52 48 85 c0 75 0f eb 4b 0f 1f 84 00 00 00 00 00 48 39 d8 74 3e 4c 8b 75 18 <49> 8b be 08 01 00 00 48 85 ff 74 1e e8 46 f1 f8 ff 85 c0 74 4a 49 Oct 24 08:07:33 resolver1 kernel: [10015.526326] audit: type=1400 audit(1635062853.732:8): apparmor="DENIED" operation="capable" profile="/usr/sbin/unbound" pid=1527 comm="unbound" capability=1 capname="dac_override" I upgraded all installed packages after the first crash and rebooted to the newest kernel. The capability error came after the second restart, and I've never seen unbound do that before. I don't really remember the last time unbound crashed before either. I'm afraid this might not be much help, but since it smells a little of some security issue, I thought I should still report it. Best Regards, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail
Bug#997663: general: bullseye, system freezes completely when firefox freezes
On Du, 24 oct 21, 12:25:23, jacobkoch...@gmail.com wrote: > Hello Stephan, > > > Possibly relevant: > > - Are you using X11 or Wayland? > Wayland > > > - Do you have proprietary graphics drivers installed? > $ lspci -v | grep -A 10 VGA > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 > (rev 02) (prog-if 00 [VGA controller]) > Subsystem: CLEVO/KAPOK Computer HD Graphics 620 > [...] > Kernel driver in use: i915 > Kernel modules: i915 > It seems to be the open source driver 'i915' in the package: > 'xserver-xorg-video-intel'. You can try forcing use of the 'modesetting' built-in Xorg driver, e.g. by removing xserver-xorg-video-intel. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#994725: fail2ban: Fail2ban 0.11.2 exim failregexs don't match logs from Debian's exim 4.94.2
Hm. Those are fair comments I do think I added the LOGIN line because of my specific installation. And there's are fundamental problems with using regular expressions for log parsing. I hadd also found this write up with a similar patch to what I'd proposed. https://systemadminspro.com/fail2ban-and-exim-on-ubuntu/ I think the problem with the %(pid)s optional pattern is that it leaves a unneeded space in the pattern. from https://salsa.debian.org/python-team/packages/fail2ban/-/blob/master/config/filter.d/exim.conf#L24 the pattern "^%(pid)s SMTP protocol error in ..." Wont match "2021-10-24 00:28:54 SMTP protocol error in "AUTH LOGIN" H=(User) ... because after stripping off the timestamp we're left with the pattern "SMTP protocol..." not being able to match "^ SMTP protocol..." Maybe it'd work better if filter.d/common.conf:24:__pid_re = (?:\[\d+\]) was instead something like: filter.d/common.conf:24:__pid_re = (?:\[\d+\]) ? Though maybe it needs to be a __pid_re specific to exim? or the exim.conf pattern should allow blank spaces? Something like "^%(pid)s *SMTP protocol..." Diane
Bug#973313: Is the "LC_ALL=C.UTF-8" export to forked bash child process that run man check?
在 2021/10/25 上午12:35, Felix Lechner 写道: With a Chinese default locale, you probably have a lot more experience with all this, but I do not understand. Lintian does not use en_US.UTF-8 but C.UTF-8. [1] I can reproduce this bug in my test server. My notebook use zh_CN.UTF-8 locale, ssh to the test server. 1. The test server has not any other locale except default. 2. I also already apt purge locale package on test server. 3. The ssd_config of the test server has the following config to accept my notebook locale zh_CN.UTF-8 : # Allow client to pass locale environment variables AcceptEnv LANG LC_* atzlinux@hwymini:~$ locale -a locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C C.UTF-8 POSIX atzlinux@hwymini:~$ locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=zh_CN.UTF-8 LANGUAGE= LC_CTYPE="zh_CN.UTF-8" LC_NUMERIC="zh_CN.UTF-8" LC_TIME="zh_CN.UTF-8" LC_COLLATE="zh_CN.UTF-8" LC_MONETARY="zh_CN.UTF-8" LC_MESSAGES="zh_CN.UTF-8" LC_PAPER="zh_CN.UTF-8" LC_NAME="zh_CN.UTF-8" LC_ADDRESS="zh_CN.UTF-8" LC_TELEPHONE="zh_CN.UTF-8" LC_MEASUREMENT="zh_CN.UTF-8" LC_IDENTIFICATION="zh_CN.UTF-8" LC_ALL= atzlinux@hwymini:~$ LC_ALL=C.UTF-8 atzlinux@hwymini:~$ locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=zh_CN.UTF-8 LANGUAGE= LC_CTYPE="zh_CN.UTF-8" LC_NUMERIC="zh_CN.UTF-8" LC_TIME="zh_CN.UTF-8" LC_COLLATE="zh_CN.UTF-8" LC_MONETARY="zh_CN.UTF-8" LC_MESSAGES="zh_CN.UTF-8" LC_PAPER="zh_CN.UTF-8" LC_NAME="zh_CN.UTF-8" LC_ADDRESS="zh_CN.UTF-8" LC_TELEPHONE="zh_CN.UTF-8" LC_MEASUREMENT="zh_CN.UTF-8" LC_IDENTIFICATION="zh_CN.UTF-8" LC_ALL= atzlinux@hwymini:~$ MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 -Z /usr/share/man/man1/ls.1.gz > /dev/null man: can't set the locale; make sure $LC_* and $LANG are correct The same error infos display. atzlinux@hwymini:~$ export LC_ALL=C.UTF-8 atzlinux@hwymini:~$ locale LANG=zh_CN.UTF-8 LANGUAGE= LC_CTYPE="C.UTF-8" LC_NUMERIC="C.UTF-8" LC_TIME="C.UTF-8" LC_COLLATE="C.UTF-8" LC_MONETARY="C.UTF-8" LC_MESSAGES="C.UTF-8" LC_PAPER="C.UTF-8" LC_NAME="C.UTF-8" LC_ADDRESS="C.UTF-8" LC_TELEPHONE="C.UTF-8" LC_MEASUREMENT="C.UTF-8" LC_IDENTIFICATION="C.UTF-8" LC_ALL=C.UTF-8 atzlinux@hwymini:~$ MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 -Z /usr/share/man/man1/ls.1.gz > /dev/null atzlinux@hwymini:~$ - There is not errors after export. So,my question is: Is the "LC_ALL=C.UTF-8" export to forked bash child process that run man check? BTW, "You could not reproduce the error in Docker locally with the Salsa CI Lintian image—and your host uses the default locale|en_US.UTF-8|. " I think is that the screen output of console running Docker inherit the|en_US.UTF-8| locale from your host, you may run locale to see the LANG in Docker. Is it|en_US.UTF-8|? I guess the Dcoker can use|en_US.UTF-8| locale come from your host, even the Docker itself has not the|en_US.UTF-8| locale produced. Thanks! xiao sheng wen OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#964785: I'd like to create a shutter package and add it to the Debian package.
Hi, guys! Any news here? People are asking for a Debian package and I don't know what to tell them: https://github.com/shutter-project/shutter/issues/417
Bug#996645: kodi: please add support for riscv64
Control: close -1 2:19.3+dfsg1-1 Dear Aurelien, Your patches were accepted upstream and I have uploaded 19.3 bugfix release to unstable. Let me close this bug and feel free to reopen it if build fails :) -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#995683: latexmk: diff for NMU version 1:4.75-1
Control: tags 995683 + patch Control: tags 995683 + pending Dear maintainer, I've prepared an NMU for latexmk (versioned as 1:4.75-1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards. Norbert -- PREINING Norbert https://www.preining.info Fujitsu Research + IFMGA Guide + TU Wien + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 diff -Nru latexmk-4.75/debian/changelog latexmk-4.75/debian/changelog --- latexmk-4.75/debian/changelog 2021-09-30 16:42:13.0 +0900 +++ latexmk-4.75/debian/changelog 2021-10-25 11:01:02.0 +0900 @@ -1,3 +1,16 @@ +latexmk (1:4.75-1) unstable; urgency=medium + + [ Hilmar Preusse ] + * Fixes for +I: debian-watch-uses-insecure-uri +I: older-debian-watch-file-standard + + [ Norbert Preining ] + * Change maintainer to the Debian TeX Task Force (Closes: #995683) + * Bump standards version to 4.6.0, no changes necessary. + + -- Norbert Preining Mon, 25 Oct 2021 11:01:02 +0900 + latexmk (1:4.75-0.1) unstable; urgency=medium * NMU diff -Nru latexmk-4.75/debian/control latexmk-4.75/debian/control --- latexmk-4.75/debian/control 2021-09-30 16:42:13.0 +0900 +++ latexmk-4.75/debian/control 2021-10-25 11:01:02.0 +0900 @@ -2,8 +2,10 @@ Section: tex Priority: optional Build-Depends: debhelper-compat (= 12) -Maintainer: OHURA Makoto -Standards-Version: 4.5.0 +Maintainer: Debian TeX Task Force +Uploaders: Hilmar Preusse , + Norbert Preining +Standards-Version: 4.6.0 Homepage: https://personal.psu.edu/jcc8/software/latexmk-jcc/ Vcs-Git: https://github.com/debian-tex/latexmk.git Vcs-Browser: https://github.com/debian-tex/latexmk diff -Nru latexmk-4.75/debian/watch latexmk-4.75/debian/watch --- latexmk-4.75/debian/watch 2021-09-30 16:42:13.0 +0900 +++ latexmk-4.75/debian/watch 2021-10-25 11:01:02.0 +0900 @@ -1,8 +1,8 @@ -version=3 +version=4 # In the pattern below the first digit is isolated so to have a dotted # version number in the debian packages, the upstream uses this dotted # form in the changelog but removes the dot in the file names. -http://personal.psu.edu/~jcc8/software/latexmk/versions.html \ +https://personal.psu.edu/~jcc8/software/latexmk/versions.html \ latexmk-([\d])([\d]+[a-z]*).zip \ debian uupdate
Bug#997180: samtools: FTBFS: bam_tview_curses.c:88:5: error: format not a string literal and no format arguments [-Werror=format-security]
On Sun, 24 Oct 2021 20:13:45 +0200 =?utf-8?Q?=C3=89tienne?= Mollier wrote: > This issue has been reported and fixed upstream. The recently > released samtools 1.14 fixes this issue. I'm looking that up. The samtools upgrade 1.14 requires htslib 1.14 to be available. There might be some coordination needed to have all components on par apparently. I think I will do a first upload with 1.13 plus patch to fix the RC bug as such; this should give some breathing room for focusing on the htslib upgrade later. Kind Regards, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/4, please excuse my verbosity. signature.asc Description: PGP signature
Bug#996761: kwin-x11: KWin crashes and doesn't start
Hi! I'm facing the same issue. Another workaround, is to add sid repository and install kwin_x11 from there. Best regards,
Bug#997810: RFS: rednotebook/2.22+ds-3 -- Modern desktop diary and personal journaling tool
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rednotebook": * Package name: rednotebook Version : 2.22+ds-3 Upstream Author : Jendrik Seipp * URL : https://rednotebook.app * License : GPL-3+, GPL-2+, CC0-1.0, PSF-2, LGPL-3+ * Vcs : https://github.com/jendrikseipp/rednotebook Section : text It builds those binary packages: rednotebook - Modern desktop diary and personal journaling tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rednotebook/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.22+ds-3.dsc Changes since the last upload: rednotebook (2.22+ds-3) unstable; urgency=medium . * Add upstream patches: - 001-prevent-main-window-crash-cf2970e-no-changelog.patch - 002-workaround-save-fail-on-cloud-drives-754a821-no-changelog.patch * Update standards-version to 4.6.0.1 - No changes required. * Add upstream contact to d/copyright. Regards Phil -- *** Playing the game for the games own sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#969934: cloud-init: bullseye: sources.list template should switch from /updates to -security
On Sun, 2021-10-24 at 23:49 +0200, Thomas Goirand wrote: > I agree this should be fixed in Stable. I've uploaded the fix to > unstable already. However, I'm not sure why oldstable should be > updated. Can you share your view? I forgot why I thought it should be fixed before bullseye, so I have taken a look at the code. The function generate_sources_list takes the codename to generate for as an argument, so it needs to DTRT no matter what the codename is, but then apply_apt only passes lsb_release results to it, but then lsb_release can be run in a chroot via the target parameter, but then the cloud-init subp subprocess wrapper errors if the target parameter is set, but the (unused) external subp module does not error if the target parameter is set and c-i subp later still supports using the target parameter to chroot into a directory. So it looks like cloud-init in sid at least is designed to be able to deal with a chroot, which would mean that generate_sources_list needs to generate a different sources.list depending on the codename, which could be different to the host codename, but in practice the subp function blocks using a chroot to get dpkg/apt info. I suggest you investigate if the chroot functionality works in all the releases of cloud-init in Debian and if it works in any of them, then backport the patch you added to those releases. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#972950: ncal: cal fails to highlight current date (and rejects -h flag)
Yet another person who has noticed this. Highlighting the current date is rather handy for interactive use. The basis of #904839 is incorrect. Without that change `cal` uses isatty() to determine whether output is a terminal. If not a terminal, highlighting is disabled (compare `ncal -b` and `ncal -b | cat`). As such, if the reporter for #904839 really was attempting to parse the output, that wouldn't have been effected by highlighting. There was only a single reporter for #904839 (after the feature had been in place for 5 years), there are now 5 complaints after it has been absent for less than a year. That seems like rather overwhelming support for keeping highlighting. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#995376: wsjtx: Segfault when use refspec
On Thu, Oct 21, 2021 at 08:47:57PM +0200, Benjamin Bänziger wrote: > A patch to fix this bug is available: > https://sourceforge.net/p/wsjt/mailman/message/37370468/ > > It has also been fixed in the new wsjt-x release 2.5.1 Thank you Benjamin. For some reason this bug report ended up in my spam folder and I didn't see it before my rebuild upload. I am uploading a build with the patch now and will also prepare an upload of 2.5.1. Cheers, tony signature.asc Description: PGP signature
Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator
On Sun, 2021-10-24 at 14:24 +0200, wf...@niif.hu wrote: > libraries (like libswtpm_libtpms.a) This library sounds like an embedded code copy, if it is one, please follow the advice on this wiki page. libtpms is already in Debian. https://wiki.debian.org/EmbeddedCopies -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#997382: theano FTBFS - sphinx 4.2?
Control: tags -1 patch This looks similar to #997026, and the same fix appears to work.
Bug#997162: mcabber: FTBFS: screen.c:1281:33: error: format not a string literal and no format arguments [-Werror=format-security]
Hi, Thanks for the report. I think I have fixed this issue (upstream) with the following commit: https://mcabber.com/hg/rev/64f1899ff168 (On the Github mirror: https://github.com/McKael/mcabber/commit/5a0893d69023 ) Regards, Mikael * Lucas Nussbaum [2021-10-23 21:07 +0200]: > Source: mcabber > Version: 1.1.2-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64.
Bug#997081: statsmodels FTBFS - tests fail
Reproduced here; not obviously known upstream. Autopkgtest says it started between 2021-08-30 and 2021-09-14 in unstable, between 2021-10-10 and 2021-10-18 in testing. It might be easiest to upgrade to 0.13.0 (if it fixes this - I haven't checked yet), given that we should do that anyway at some point, but that involves testing whether it breaks any rdeps.
Bug#997809: roundcube: Delay migration into testing
Source: roundcube Version: 1.5.0+dfsg.1-2 Severity: serious Given the large changelog it's probably best to let 1.5 mature in unstable and delay its entry into testing by a week or so. With the DEP8 tests urgency=medium means migration after only 2 days which is definitely too short here. Meant to upload -2 with urgency=low, my bad for not changing the default. -- Guilhem. signature.asc Description: PGP signature
Bug#997808: apparmor: widevine crashes (upstream fix)
Package: firefox
Version: 93.0-1
Severity: normal
Pages using widevine kept crashing for me … I was wondering for awhile
there if this was because my Firefox profile had been through about five
release versions of two Linux distributions. However it didn't work on a
new profile, so we dug deeper on irc to figure out if there was another
cause.
Ultimately, it appears upstream has a fix for exactly this problem,
found at the end of their AppArmor profile:
https://gitlab.com/apparmor/apparmor/-/blob/656f2103ed70387d2643ff83d510960dfd959e7f/profiles/apparmor/profiles/extras/usr.lib.firefox.firefox
Specifically:
# needed by widevine
ptrace (trace) peer=@{profile_name},
@{HOME}/.mozilla/firefox/*/gmp-widevinecdm/*/lib*so m,
The ability to ptrace itself, and the ability to mmap the libwidevine
and other .so files associated with WideVine.
This fixed a newly-created profile and my existing one.
-- Package-specific info:
-- Extensions information
Name: Add-ons Search Detection
Location:
/home/tjcarter/.mozilla/firefox/dnec3otd.tjcarter/features/{69714ef9-0c55-485a-b36b-45cc72fdebfe}/addons-search-detect...@mozilla.com.xpi
Status: enabled
Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Bitwarden - Free Password Manager
Location: ${PROFILE_EXTENSIONS}/{446900e4-71c2-419f-a6a7-df9c091e268b}.xpi
Status: enabled
Name: Buster: Captcha Solver for Humans
Location: ${PROFILE_EXTENSIONS}/buster-capt...@jeelsboobz.id.xpi
Status: enabled
Name: ClearURLs
Location: ${PROFILE_EXTENSIONS}/{74145f27-f039-47ce-a470-a662b129930a}.xpi
Status: enabled
Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: DownThemAll!
Location: ${PROFILE_EXTENSIONS}/{DDC359D1-844A-42a7-9AA1-88A850A938A8}.xpi
Status: enabled
Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: eBay
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Firefox Alpenglow theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Firefox Multi-Account Containers
Location: ${PROFILE_EXTENSIONS}/@testpilot-containers.xpi
Status: enabled
Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: HTTPS Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywh...@eff.org.xpi
Status: enabled
Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Neat URL
Location: ${PROFILE_EXTENSIONS}/neat...@hugsmile.eu.xpi
Status: enabled
Name: Picture-In-Picture
Location: /usr/lib/firefox/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Prevent Duplicate Tabs
Location: ${PROFILE_EXTENSIONS}/{e80594de-acca-4551-af7a-c9bd9d2f3388}.xpi
Status: enabled
Name: Privacy Possum
Location: ${PROFILE_EXTENSIONS}/woop-noopscoopsn...@jetpack.xpi
Status: enabled
Name: Proxy Failover
Location:
/home/tjcarter/.mozilla/firefox/dnec3otd.tjcarter/features/{69714ef9-0c55-485a-b36b-45cc72fdebfe}/proxy-failo...@mozilla.com.xpi
Status: enabled
Name: Remove Redirect
Location: ${PROFILE_EXTENSIONS}/removeredir...@hyperfekt.xpi
Status: enabled
Name: Removes Most AdBlocker Walls (DailyBeast etc)
Location: ${PROFILE_EXTENSIONS}/{cc970d2f-047a-4367-8f94-239277ef52d6}.xpi
Status: enabled
Name: Reset Search Defaults
Location:
/home/tjcarter/.mozilla/firefox/dnec3otd.tjcarter/features/{69714ef9-0c55-485a-b36b-45cc72fdebfe}/reset-search-defau...@mozilla.com.xpi
Status: enabled
Name: Search by Image
Location: ${PROFILE_EXTENSIONS}/{2e5ff8c8-32fe-46d0-9fc8-6b8986621f3c}.xpi
Status: enabled
Name: Stylus
Location: ${PROFILE_EXTENSIONS}/{7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}.xpi
Status: enabled
Name: System theme theme
Location: /usr/lib/firefox/omni.ja
Package: firefox
Status: enabled
Name: Tab Manager Plus for Firefox
Location: ${PROFILE_EXTENSIONS}/{45f2dc53-96cd-4c41-91f6-f4a73a8fb2b0}.xpi
Status: enabled
Name: Temporary Containers
Location: ${PROFILE_EXTENSIONS}/{c607c8df-14a7-4f28-894f-29e8722976af}.xpi
Status: enabled
Name: To Google Translate
Location: ${PROFILE_EXTENSIONS}/jid1-93wyvpgvxzg...@jetpack.xpi
Status: enabled
Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled
Name: Universal Bypass
Location: ${PROFILE_EXTENSIONS}/{529b261b-df0b-4e3b-bf42-07b462da0ee8}.xpi
Status: enabled
Name: Video DownloadHelper
Location:
Bug#997180: samtools: FTBFS: bam_tview_curses.c:88:5: error: format not a string literal and no format arguments [-Werror=format-security]
Control: tags -1 confirmed fixed-upstream pending Control: forwarded -1 https://github.com/samtools/samtools/pull/1509 Greetings, This issue has been reported and fixed upstream. The recently released samtools 1.14 fixes this issue. I'm looking that up. Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/5, please excuse my verbosity. signature.asc Description: PGP signature
Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)
On 10/24/21 3:24 PM, Dmitry Shachnev wrote: > Hi all! > > On Sun, Oct 24, 2021 at 01:49:30PM +0200, Lucas Nussbaum wrote: >> Source: nose >> Version: 1.3.7-7 >> Severity: serious >> Justification: FTBFS >> Tags: bookworm sid ftbfs >> User: lu...@debian.org >> Usertags: ftbfs-20211023 ftbfs-bookworm >> >> Hi, >> >> During a rebuild of all packages in sid, your package failed to build >> on amd64. >> >> [...] > > It happens because setuptools v58.0.0 removed support for 2to3 during builds, > which nose relied on (because it has a Python 2 codebase). > > Instead of spending time on a proper Python 3 port, I would prefer to simply > let nose die (it is abandoned since 2016). > > If anyone is still using nose (1.x), please port your packages to nose2, > pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF > in a few weeks when I have more time. > > -- > Dmitry Shachnev Hi, I'm referenced for 55 packages. Please don't force me to do this right away, that's too much work. I very much would prefer if we could have a smoother transition. Note that it's possible that for many packages mentioned, only removing the dependency should be enough. Still, that's some work to do... :/ Other alternative would be: help with NMU fixes (or I can add any of you in the OpenStack team if you need...). Cheers, Thomas Goirand (zigo)
Bug#969934: cloud-init: bullseye: sources.list template should switch from /updates to -security
On 9/9/20 6:57 AM, Paul Wise wrote:
> Package: cloud-init
> Severity: normal
> File: /etc/cloud/templates/sources.list.debian.tmpl
> User: debian-de...@lists.debian.org
> Usertags: bullseye-security
>
> The above sources.list template mentions {{codename}}/updates but with
> bullseye and later that should be {{codename}}-security. I'm not sure
> when this issue should get fixed but probably at minimum just before
> the bullseye freeze period it should get fixed. Also if that file is
> meant to cater to multiple releases then perhaps the use of /updates or
> -security should be conditional on the codename choice and if so then
> this bug should be upgraded from severity normal to severity serious
> and this issue should also get fixed in Debian stable and oldstable.
Hi Paul,
Thanks for this bug report.
I agree this should be fixed in Stable. I've uploaded the fix to
unstable already. However, I'm not sure why oldstable should be updated.
Can you share your view?
Cheers,
Thomas Goirand (zigo)
Bug#997807: hyperic-sigar: FTBFS on riscv64: gcc: error: unrecognized command-line option ‘-m64’
Source: hyperic-sigar
Version: 1.6.4+dfsg-5
Severity: wishlist
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
Dear maintainer,
hyperic-sigar fails to build from source on riscv64:
| jni-compile:
|
| jni-cc:
| [mkdir] Created dir:
/<>/bindings/java/build/obj/riscv64-linux/lib
| [echo] jni libname=sigar
|[cc] 13 total files to be compiled.
|[cc] gcc: error: unrecognized command-line option ‘-m64’
|
| BUILD FAILED
| /<>/bindings/java/hyperic_jni/jni-build.xml:224: The following
error occurred while executing this line:
| /<>/bindings/java/hyperic_jni/jni-build.xml:270: gcc failed with
return code 1
|
| Total time: 1 minute 21 seconds
| dh_auto_build: error: cd bindings/java && ant -Duser.name debian returned
exit code 1
| make: *** [debian/rules:6: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=hyperic-sigar=riscv64=1.6.4%2Bdfsg-5=1630049820=0
The issue is that -m64 is not understood by GCC on riscv64. This is also
the case on a few other architectures, and I have noticed that you
already have a patch for that. I have tried to extend it (see attached
patch), and hyperic-sigar builds fine on riscv64. Could you please
consider applying it in the future uploads?
Note however that instead of maintaining a long list of architectures
where -m64 is not needed might not be the best way, as this flag is
basically understood only on x86, p(ower)pc*, sparc* and s390*. In
addition this flag is basically not needed for a standard Debian
installation, where gcc already defaults to the correct bitness. You
might therefore want to simply drop those few lines.
Regards,
Aurelien
--- hyperic-sigar-1.6.4+dfsg/debian/patches/no-m64-mips-arm.diff
+++ hyperic-sigar-1.6.4+dfsg/debian/patches/no-m64-mips-arm.diff
@@ -2,13 +2,14 @@
===
---
hyperic-sigar-1.6.4+dfsg.orig/bindings/java/hyperic_jni/src/org/hyperic/jni/ArchNameTask.java
2014-11-03 13:25:30.620030459 +0800
+++
hyperic-sigar-1.6.4+dfsg/bindings/java/hyperic_jni/src/org/hyperic/jni/ArchNameTask.java
2014-11-03 13:25:30.608030459 +0800
-@@ -75,7 +75,8 @@
+@@ -75,7 +75,9 @@
if (ArchName.is64()) {
getProject().setProperty("jni.arch64", "true");
if (ArchLoader.IS_LINUX) {
-if (!osArch.equals("ia64")) {
+if (!osArch.equals("ia64") && !osArch.equals("mips64el")
-+ && !osArch.equals("mips64") &&
!osArch.equals("aarch64")) {
++ && !osArch.equals("mips64") && !osArch.equals("aarch64")
++ && !osArch.equals("riscv64")) {
getProject().setProperty("jni.gccm", "-m64");
}
}
Bug#997806: aom: possible ABI breakage; causes ffmpeg autopkgtests failures
Source: aom Version: 1.0.0-errata1.avif-1 Severity: serious X-Debbugs-Cc: sramac...@debian.org From ffmpeg's autopkgtest: | Test 31: | trying muxer 'asf' with 'v' encoder 'libaom-av1' for codec 'av1' | | ffmpeg -f lavfi -i testsrc=s=32x32:d=0.1 -strict -2 -c:v libaom-av1 -f asf /tmp/autopkgtest-lxc.bawnkh1_/downtmp/autopkgtest_tmp/test/libaom-av1.asf -y -hide_banner -nostdin | Input #0, lavfi, from 'testsrc=s=32x32:d=0.1': | Duration: N/A, start: 0.00, bitrate: N/A | Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 32x32 [SAR 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc | Stream mapping: | Stream #0:0 -> #0:0 (rawvideo (native) -> av1 (libaom-av1)) | [libaom-av1 @ 0x55ab8a773940] v1.0.0 | [libaom-av1 @ 0x55ab8a773940] Neither bitrate nor constrained quality specified, using default CRF of 32 | [libaom-av1 @ 0x55ab8a773940] Failed to initialize encoder: ABI version mismatch | *** stack smashing detected ***: terminated | /tmp/autopkgtest-lxc.bawnkh1_/downtmp/build.Vzd/src/debian/tests/encdec: line 13: 11996 Aborted $CMD 2>&1 | | | | FAILED: asf;v=av1:libaom-av1; encoding return code: 134 See https://ci.debian.net/data/autopkgtest/testing/amd64/f/ffmpeg/16162728/log.gz Combined with the changes in aom's headers, this looks like ABI breakage to me. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#997805: gbp buildpackage: wrongly thinks sbuild -A option means changes file will always be called "_all.changes" which breaks lintian
Package: git-buildpackage Version: 0.9.22 Severity: normal I ran the following command: gbp buildpackage --git-builder=sbuild -A -v -d unstable and received the following error in the postbuild hook, which runs lintian: gbp:info: Running Postbuild hook /home/jdg/debian/spyder-packages/pyxdameraulevenshtein/build-area/pyxdameraulevenshtein_1.7.0-1_all.changes is not a readable file gbp:error: Postbuild-hook 'lintian $GBP_CHANGES_FILE' failed: it exited with 2 The changes file in this case is called ..._amd64.changes. Running the build with --verbose resulted in the attached log file. It seems that for sbuild, "-A" does not stop the Architecture: any packages from being built, which is different from the "-A" option for dpkg-buildpackage. Best wishes, Julian -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-buildpackage depends on: ii devscripts 2.21.4 ii git1:2.33.0-1 ii man-db 2.9.4-2 ii python33.9.2-3 ii python3-dateutil 2.8.1-6 ii python3-pkg-resources 58.2.0-1 ii sensible-utils 0.0.17 Versions of packages git-buildpackage recommends: ii cowbuilder0.89 ii pbuilder 0.231 ii pristine-tar 1.49 ii python3-requests 2.25.1+dfsg-2 Versions of packages git-buildpackage suggests: pn python3-notify2 ii sudo 1.9.5p2-3 ii unzip6.0-26 -- no debconf information gbp-buildpackage.log.gz Description: application/gzip
Bug#997799: feynmf: Use disappeared /bin/tempfile in debian patch
On Sun, Oct 24, 2021 at 03:09:46PM -0400, Boyuan Yang wrote: > I just realized the ongoing discussion at https://bugs.debian.org/994275 , > which may mitigate the impact of this bug report. Now I believe depending on > either tempfile(1) or mktemp(1) should be ok. I would recommend switching to mktemp(1) regardless. There is no possible final outcome wherein any version of tempfile(1) would be a better choice.
Bug#997804: libstdc++-11-dev: Link error when libtbb-dev is installed
Package: libstdc++-11-dev Version: 11.2.0-9 Severity: normal If libtbb-dev is installed ( is present on the system), any program using the header from C++17 or otherwise causing to be included fails to link with this error: /usr/bin/ld: /tmp/cc8b8juf.o: in function `tbb::interface7::task_arena::current_thread_index()': foo.cpp:(.text._ZN3tbb10interface710task_arena20current_thread_indexEv[_ZN3tbb10interface710task_arena20current_thread_indexEv]+0x5): undefined reference to `tbb::interface7::internal::task_arena_base::internal_current_slot()' collect2: error: ld returned 1 exit status Adding -ltbb makes it succeed, but I would not expect the C++ stdlib to require explicitly linking additional libraries. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.11.10-k8 (SMP w/24 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libstdc++-11-dev depends on: ii gcc-11-base11.2.0-9 ii libc6-dev 2.32-4 ii libgcc-11-dev 11.2.0-9 ii libstdc++6 11.2.0-9 libstdc++-11-dev recommends no packages. Versions of packages libstdc++-11-dev suggests: pn libstdc++-11-doc -- no debconf information
Bug#997803: gnuradio: FTBFS: timeout during tests
Source: gnuradio Version: 3.8.2.0-14 Severity: serious Tags: ftbfs sid bookworm Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org gnuradio failed to build during the rebuilds for the libvolk transition: | Start 94: qa_tags_strobe | 94/237 Test #94: qa_tags_strobe ... Passed 0.78 sec | Start 95: qa_tcp_server_sink | E: Build killed with signal TERM after 150 minutes of inactivity See https://buildd.debian.org/status/fetch.php?pkg=gnuradio=amd64=3.8.2.0-14%2Bb1=1635097346=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#984342: source-highlight: diff for NMU version 3.1.9-4.1
I was unavailable for a while. Thanks for the patch, there's no need to
delay it any longer.
Regards,
Kartik
On Fri, Oct 22, 2021 at 9:33 PM Boyuan Yang wrote:
> Control: tags 984342 + patch
> Control: tags 984342 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for source-highlight (versioned as 3.1.9-4.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
>
> diff -Nru source-highlight-3.1.9/debian/changelog source-highlight-
> 3.1.9/debian/changelog
> --- source-highlight-3.1.9/debian/changelog 2020-08-02
> 16:01:04.0
> -0400
> +++ source-highlight-3.1.9/debian/changelog 2021-10-22
> 16:25:06.0
> -0400
> @@ -1,3 +1,14 @@
> +source-highlight (3.1.9-4.1) unstable; urgency=high
> +
> + * Non-maintainer upload.
> + * Apply patch from Ubuntu:
> +
> + [ Graham Inggs ]
> + * Remove "throw" specifications to fix build with GCC 11
> +(Closes: #984342)
> +
> + -- Boyuan Yang Fri, 22 Oct 2021 16:25:06 -0400
> +
> source-highlight (3.1.9-3) unstable; urgency=medium
>
>* Added VCS and will be maintained at salsa
> diff -Nru source-highlight-3.1.9/debian/gitlab-ci.yml source-highlight-
> 3.1.9/debian/gitlab-ci.yml
> --- source-highlight-3.1.9/debian/gitlab-ci.yml 1969-12-31
> 19:00:00.0
> -0500
> +++ source-highlight-3.1.9/debian/gitlab-ci.yml 2021-10-22
> 16:23:56.0
> -0400
> @@ -0,0 +1,10 @@
> +image: registry.salsa.debian.org/salsa-ci-team/ci-image-git-
> buildpackage:latest
> +
> +build:
> + artifacts:
> +paths:
> +- "*.deb"
> +expire_in: 1 day
> + script:
> +- gitlab-ci-git-buildpackage-all
> +
> diff -Nru source-highlight-3.1.9/debian/patches/gcc11.patch
> source-highlight-
> 3.1.9/debian/patches/gcc11.patch
> --- source-highlight-3.1.9/debian/patches/gcc11.patch 1969-12-31
> 19:00:00.0 -0500
> +++ source-highlight-3.1.9/debian/patches/gcc11.patch 2021-10-22
> 16:24:26.0 -0400
> @@ -0,0 +1,30 @@
> +Description: Remove "throw" specifications
> + C++ throw specifications were deprecated in C++11.
> + This patch removes them from the library.
> +Bug-Debian: https://bugs.debian.org/984342
> +Origin: upstream,
>
> https://git.savannah.gnu.org/cgit/src-highlite.git/commit/?id=904949c9026cb772dc93fbe0947a252ef47127f4
> +Author: Tom Tromey
> +Last-Update: 2020-06-10
> +
> +--- a/lib/srchilite/fileutil.cc
> b/lib/srchilite/fileutil.cc
> +@@ -48,7 +48,7 @@
> + // FIXME avoid using a global variable
> + std::string start_path;
> +
> +-string readFile(const string ) throw (IOException) {
> ++string readFile(const string ) {
> + ifstream file(fileName.c_str());
> +
> + if (!file.is_open()) {
> +--- a/lib/srchilite/fileutil.h
> b/lib/srchilite/fileutil.h
> +@@ -27,7 +27,7 @@
> + * @return the contents of the file
> + * @throw IOException
> + */
> +-string readFile(const string ) throw (IOException);
> ++string readFile(const string );
> +
> + //char *read_file(const string );
> +
> diff -Nru source-highlight-3.1.9/debian/patches/series source-highlight-
> 3.1.9/debian/patches/series
> --- source-highlight-3.1.9/debian/patches/series2020-08-02
> 16:01:04.0 -0400
> +++ source-highlight-3.1.9/debian/patches/series2021-10-22
> 16:24:26.0 -0400
> @@ -1 +1,2 @@
> fix-national-encoding.patch
> +gcc11.patch
>
Bug#772135: Processed: retitle to RFP: nodiverse -- a 3D universe library in Node.js
retitle 772135 ITP: nodiverse -- a 3D universe library in Node.js owner 772135 ! thanks The Debian package is created, upstream, I'd need a sponsor to publish the package, tho. On Fri, Mar 31, 2017 at 5:31 PM Marcos Marado wrote: > > retitle 772135 ITP: nodiverse -- a 3D universe library in Node.js > owner 772135 ! > thanks > > The Debian package is created, upstream, I'd need a sponsor to publish the > package, tho. > > > On Fri, Mar 31, 2017 at 5:29 PM Marcos Marado > wrote: >> >> retitle 772135 ITP: nodiverse -- a 3D universe library in Node.js >> owner 772135 ! >> thanks >> >> The Debian package is created, upstream, I'd need a sponsor to publish the >> package, tho. >> >> >> On Fri, Mar 31, 2017 at 5:24 PM Debian Bug Tracking System >> wrote: >>> >>> Processing commands for cont...@bugs.debian.org: >>> >>> > retitle 772135 RFP: nodiverse -- a 3D universe library in Node.js >>> Bug #772135 [wnpp] ITP: nodiverse -- a 3D universe library in Node.js >>> Changed Bug title to 'RFP: nodiverse -- a 3D universe library in Node.js' >>> from 'ITP: nodiverse -- a 3D universe library in Node.js'. >>> > noowner 772135 >>> Bug #772135 [wnpp] RFP: nodiverse -- a 3D universe library in Node.js >>> Removed annotation that Bug was owned by Marcos Marado >>> . >>> > stop >>> Stopping processing here. >>> >>> Please contact me if you need assistance. >>> -- >>> 772135: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772135 >>> Debian Bug Tracking System >>> Contact ow...@bugs.debian.org with problems
Bug#997802: ddnet: autopkgtest regression on armhf: output to stderr
Source: ddnet
Version: 15.5.4-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of ddnet the autopkgtest of ddnet fails in testing
when that autopkgtest is run with the binary packages of ddnet from
unstable. It passes when run with only packages from testing. In tabular
form:
passfail
ddnet from testing15.5.4-1
all others from testingfrom testing
I copied some of the output at the bottom of this report. It seems that
the actual test passes, but there's output on stderr and the default
behavior of autopkgtest is to fail on output to stderr. If in general
output to stderr is harmless to your test, consider adding the
allow-stderr restriction. Otherwise, please fix your test.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=ddnet
https://ci.debian.net/data/autopkgtest/testing/armhf/d/ddnet/16147062/log.gz
[ 91%] Building CXX object CMakeFiles/testrunner.dir/src/test/unix.cpp.o
[ 91%] Building CXX object CMakeFiles/testrunner.dir/src/test/uuid.cpp.o
[ 94%] Building CXX object
CMakeFiles/testrunner.dir/src/engine/client/blocklist_driver.cpp.o
[ 94%] Building CXX object
CMakeFiles/testrunner.dir/src/engine/client/http.cpp.o
[ 94%] Building CXX object
CMakeFiles/testrunner.dir/src/engine/client/serverbrowser.cpp.o
[ 97%] Building CXX object
CMakeFiles/testrunner.dir/src/engine/client/serverbrowser_http.cpp.o
In file included from /usr/include/c++/10/vector:72,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/engine/graphics.h:13,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/engine/textrender.h:8,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/game/client/ui.h:7,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/engine/serverbrowser.h:8,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/engine/client/serverbrowser_http.cpp:8:
/usr/include/c++/10/bits/vector.tcc: In member function ‘void
std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args =
{CServerBrowserHttp::CEntry}; _Tp = CServerBrowserHttp::CEntry; _Alloc =
std::allocator]’:
/usr/include/c++/10/bits/vector.tcc:426:7: note: parameter passing for
argument of type ‘std::vector::iterator’
changed in GCC 7.1
426 | vector<_Tp, _Alloc>::
| ^~~
/usr/include/c++/10/bits/vector.tcc: In static member function ‘static
bool CServerBrowserHttp::Parse(json_value*,
std::vector*, std::vector*)’:
/usr/include/c++/10/bits/vector.tcc:121:21: note: parameter passing for
argument of type
‘__gnu_cxx::__normal_iterator >’ changed in GCC 7.1
121 |_M_realloc_insert(end(), std::forward<_Args>(__args)...);
|~^~~
[ 97%] Building CXX object
CMakeFiles/testrunner.dir/src/engine/client/serverbrowser_ping_cache.cpp.o
[ 97%] Building CXX object
CMakeFiles/testrunner.dir/src/engine/client/sqlite.cpp.o
[100%] Building CXX object
CMakeFiles/testrunner.dir/src/engine/server/name_ban.cpp.o
[100%] Building CXX object
CMakeFiles/testrunner.dir/src/game/server/teehistorian.cpp.o
[100%] Linking CXX executable testrunner
[100%] Built target testrunner
[100%] tests
[...]
autopkgtest [18:23:02]: test unittest.sh: - - - - - - - - - - stderr -
- - - - - - - - -
In file included from /usr/include/c++/10/vector:72,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/engine/graphics.h:13,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/engine/textrender.h:8,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/game/client/ui.h:7,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/engine/serverbrowser.h:8,
from
/tmp/autopkgtest-lxc.6korsrvz/downtmp/build.XVn/src/src/engine/client/serverbrowser_http.cpp:8:
/usr/include/c++/10/bits/vector.tcc: In member function ‘void
std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args =
{CServerBrowserHttp::CEntry}; _Tp = CServerBrowserHttp::CEntry; _Alloc =
std::allocator]’:
/usr/include/c++/10/bits/vector.tcc:426:7: note: parameter passing for
argument of type ‘std::vector::iterator’
changed in GCC 7.1
426 | vector<_Tp, _Alloc>::
| ^~~
/usr/include/c++/10/bits/vector.tcc: In static member function ‘static
bool CServerBrowserHttp::Parse(json_value*,
std::vector*, std::vector*)’:
Bug#997801: elixir-lang: autopkgtest fails on armhf: Cannot allocate 512 bytes of memory (of type "bpd").
Source: elixir-lang Version: 1.12.2.dfsg-2.1 Severity: serious X-Debbugs-CC: debian...@lists.debian.org, erl...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:erlang Dear maintainer(s), With a recent upload of erlang the autopkgtest of elixir-lang fails in testing when that autopkgtest is run with the binary packages of erlang from unstable. This was reported and fixed, but on armhf the test still fails. It passes when run with only packages from testing. In tabular form: passfail erlang from testing1:24.1.1+dfsg-1 elixir-langfrom testing1.12.2.dfsg-2.1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of erlang to testing [1]. Of course, erlang shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in erlang was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from erlang should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=erlang https://ci.debian.net/data/autopkgtest/testing/armhf/e/elixir-lang/16175826/log.gz autopkgtest [15:45:52]: test run-all: [--- stdlib -- Excluding tags: [windows: true]
Bug#997800: Missing "--fix-broken" in apt documentation
Package: apt Version: 2.2.4 Debian version: Bullseye Cannot find any documentation about "apt --fix-broken install", not in man apt.
Bug#997085: numba: FTBFS: AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'
X-Debbugs-CC: di...@debian.org di...@ghic.org
Control: tags -1 +patch
I believe the fix should be present at
https://github.com/numba/numba/pull/7122 . I haven't verified the patch,
though.
P.S. It might be a better solution if we could just to update to new numba
version.
Thanks,
Boyuan Yang
在 2021-10-23星期六的 18:29 +0200，Lucas Nussbaum写道：
> Source: numba
> Version: 0.52.0-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211023 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_installdocs -A README.rst
> > dh_installdocs: warning: Cannot auto-detect main package for numba-doc. If
> > the default is wrong, please use --doc-main-package
> > cp -a docs CHANGE_LOG /<>/.pybuild/cpython3_3.9_numba/build
> > http_proxy='127.0.0.1:9'
> > PYTHONPATH=/<>/.pybuild/cpython3_3.9_numba/build:${PYTHONPATH}
> > python3.9 /usr/bin/sphinx-build -N -bhtml \
> >
> > /<>/.pybuild/cpython3_3.9_numba/build/docs/source/ \
> > debian/numba-doc/usr/share/doc/numba-doc/html/
> > Running Sphinx v4.2.0
> > Initializing ghfiles plugin
> > making output directory... done
> >
> > Exception occurred:
> > File
> > "/<>/.pybuild/cpython3_3.9_numba/build/docs/source/conf.py",
> > line 331, in setup
> > app.add_stylesheet('rtd-overrides.css')
> > AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'
> > The full traceback has been saved in /tmp/sphinx-err-duv_c8uh.log, if you
> > want to report the issue to the developers.
> > Please also report this if it was a user error, so that a better error
> > message can be provided next time.
> > A bug report can be filed in the tracker at
> > . Thanks!
> > make[1]: *** [debian/rules:29: override_dh_installdocs] Error 2
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2021/10/23/numba_0.52.0-4_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as 'affects'-
> ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
signature.asc
Description: This is a digitally signed message part
Bug#988597: trash-cli version too old
Dear Jonathan, I've fixed all the issues. You can see my work at https://salsa.debian.org/andreafrancia/trash-cli/-/tree/update-0.21.10.24 Ciao Il giorno mar 19 ott 2021 alle ore 20:11 Andrea Francia < and...@andreafrancia.it> ha scritto: > Il giorno lun 18 ott 2021 alle ore 20:02 Andrea Francia < > and...@andreafrancia.it> ha scritto: > >> Now I have other problems: the tests what to use "python" instead of >> "python3", I'll try to fix that upstream. >> > > Upstream [1] you can find a new version > (1412d3d8748585f422eb946a06bfe903160d3b01) of trash-cli that should use > python3 on Debian. > > diff --git a/tests/run_command.py b/tests/run_command.py > index 2e31e11..18fd7b6 100644 > --- a/tests/run_command.py > +++ b/tests/run_command.py > @@ -1,5 +1,6 @@ > import os > import subprocess > +import sys > > from trashcli import base_dir > > @@ -17,7 +18,7 @@ def run_command(cwd, command, args=None, input='', > env=None): > if args == None: > args = [] > command_full_path = os.path.join(base_dir, command) > -process = subprocess.Popen(["python", command_full_path] + args, > +process = subprocess.Popen([sys.executable, command_full_path] + args, > stdin=subprocess.PIPE, > stdout=subprocess.PIPE, > stderr=subprocess.PIPE, > > > The next problem that needs to be solved is about the new `psutil` > dependency. > > [1] https://github.com/andreafrancia/trash-cli > -- > Andrea Francia http://andreafrancia.it > -- Andrea Francia http://andreafrancia.it
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
Stable (bullseye) still contains chromium 90, which has had many security issues. Testing & unstable contain 93, and stable should really be quickly updated via stable-security to at least chromium 93 (as its already been packaged and proven to build) or ideally 95 (the latest stable chromium release).
Bug#997799: feynmf: Use disappeared /bin/tempfile in debian patch
On Sun, 24 Oct 2021 15:00:17 -0400 Boyuan Yang wrote: > Package: feynmf > Severity: grave > Version: 1.08-12 > Tags: sid bookworm > X-Debbugs-CC: alteh...@debian.org > > Dear Debian feynmf package maintainer, > > The custom patch introduced by Debian at > https://sources.debian.org/src/feynmf/1.08-12/debian/patches/docu.patch/ uses > /bin/tempfile, which has disappeared in newer Debian systems. This will likely > cause the program to crash. Please consider replacing it with "/bin/mktemp" > from coreutils instead. I just realized the ongoing discussion at https://bugs.debian.org/994275 , which may mitigate the impact of this bug report. Now I believe depending on either tempfile(1) or mktemp(1) should be ok. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#994275: Reverting breaking changes in debianutils
On Sat, Oct 16, 2021 at 05:56:17PM +0200, Thorsten Glaser wrote: > No. You’re conflating “which ”, which indeed is mostly redundant > with “command -v”, with “which -a ”, which is NOT otherwise > available, and a very useful thing to have, and one which (heh, pun > not intended) I pretty much expect to exist on a system. I can think of no reason why anyone would need to run `which -a` from a maintainer script. For interactive use, csh (and tcsh) never had -a for `which`. The reason that zsh has `which -a` is because it shares code with `whence -a`, which was taken from ksh in the '80s. Of course there's no telling whether it would have evolved later on if it had been originally csh-compatible. > I know that feeling… some package maintainers don’t seem to care about > warnings. But as something in an Essential package I fear it’s up to > you to ping them, time and time again, until they don’t depend on it > any more, instead of proactively removing it. I disagree. This is not a good system. This is how you architect an ultraconservative culture that discourages people from fixing things. On Sun, Oct 17, 2021 at 06:32:33AM -0400, James Cloos wrote: > i got hit by the removal of tepfile(1); pv-grub-menu uses it in its > postint script and its removal started blocking my apt upgrades. i had > to copy tempfile over from a virt stuck on an older deb to get around it. > > (cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101) > > it would be useful to ensure no packages rely on something before > removing it... The fix for pv-grub-menu is as follows: ---8<---snip---8<--- diff --git a/update-menu-lst b/update-menu-lst index f2ca1c7..2e01a39 100755 --- a/update-menu-lst +++ b/update-menu-lst @@ -128,7 +128,7 @@ fi # Default options to use in a new config file. This will only be used if $menu_file # doesn't already exist. Only edit the lines between the two "EOF"s. The others are # part of the script. -newtemplate=$(tempfile) +newtemplate=$(mktemp) cat > "$newtemplate" <> $buffer echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" >> $buffer echo "## by the debian update-grub script except for the default options below" >> $buffer ---8<---snip---8<--- How much effort is involved with that? I would guess that it is less than bullying me into adding a `tempfile` as a Debian-specific patch to debianutils or bullying me into uploading a `tempfile` package that I do not wish to maintain. On Sun, Oct 17, 2021 at 05:36:25AM -0700, Felix Lechner wrote: > Lintian's last remaining reference to 'tempfile' was dropped. [1] The > updated tag description is now live on our website. [2] Thanks. On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote: > I think causing build failures is enough reason to say this. I don't > suppose that mine is the only one. Yes those builds are buggy and > should not do this, and we should make efforts to find out why bazel > (or possibly the build scripts it is operating on) is/are so crappy, > but for now I agree that reverting this is the right thing to do. > > We have time to do this transition properly and quietly in the > background, without causing random breakage. A message about a binary > moving from one package to another does not need to be printed on > every usage of that binary. Indeed it is actively unhelpful to do so. Boyuan packaged GNU which and uploaded it to NEW in August. It is now October, and neither GNU which nor *BSD which nor any other which alternative is in unstable. Presumably one of these could have put a band-aid on your bazel problem, though of course any version of `which` might output things to stderr for a variety of reasons. Lots of things broke between buster and bullseye. Even in stable, people are struggling with horrible i915 driver bugs. Would it have been reasonable to demand that bullseye's kernel be reverted to Linux 4.19 and kept there for 5-10 years until someone figured out the drm issues? My DreamPlug's audio device went from being card0 to card1, breaking everything expecting it to be card0. Would it have been reasonable to revert Linux, ALSA userland, systemd/udev, and whichever other packages until I found the time to figure out what changed and why? Is the difference that these packages aren't Essential? Or that the bug is within the packages themselves instead of a reverse dependency? Or that it involves a package build instead of ordinary operation? On Mon, Oct 18, 2021 at 11:28:52AM +0200, Raphael Hertzog wrote: > Hi, > > On Wed, 13 Oct 2021, David Bremner wrote: > There have been other reports of failures due to the message on stderr, > autopkgtest is not the only one (wookey mentionned a build failure). GNU which can output things to stderr. FreeBSD which can output to stderr. There is no guarantee that cjwatson which won't output anything else to stderr. > In any case, a message saying that which is deprecated when in fact > `which` will stay around (but maintained
Bug#997799: feynmf: Use disappeared /bin/tempfile in debian patch
Package: feynmf Severity: grave Version: 1.08-12 Tags: sid bookworm X-Debbugs-CC: alteh...@debian.org Dear Debian feynmf package maintainer, The custom patch introduced by Debian at https://sources.debian.org/src/feynmf/1.08-12/debian/patches/docu.patch/ uses /bin/tempfile, which has disappeared in newer Debian systems. This will likely cause the program to crash. Please consider replacing it with "/bin/mktemp" from coreutils instead. Thanks, Boyuan Yang
Bug#997798: ITP: dedalus -- Dedalus is a framework for solving PDEs useful for astrophysical and geophysical fluid dynamics
Package: wnpp Severity: wishlist Owner: Mac Lee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dedalus Version : 2.2006 Upstream Author : Keaton Burns * URL : http://dedalus-project.org * License : GPL-3 Programming Lang: Python Description : Dedalus is a framework for solving PDEs useful for astrophysical and geophysical fluid dynamics Dedalus is a flexible framework for solving partial differential equations using spectral methods. The code is open-source and developed by a team of researchers studying astrophysical and geophysical fluid dynamics. Dedalus is written primarily in Python and features an easy-to-use interface with symbolic equation entry. Our numerical algorithm produces sparse systems for a wide variety of equations and spectrally-discretized domains. These systems are efficiently solved using compiled libraries and are automatically parallelized using MPI. This package is useful because it is commonly used by researchers in astrophysical and geophysical fields. I happen to be one of those researchers using the package. I am not aware of another package that provides similar functionalities already in Debian. I plan to maintain the package as part of the Python team and I am looking for a sponsor since this is my very first Debian package.
Bug#997709: initramfs-tools: FTBFS: shellcheck errors
Control: forcemerge 992798 997709
Hi Lucas,
On Sun, Oct 24, 2021 at 01:37:16PM +0200, Lucas Nussbaum wrote:
> Source: initramfs-tools
> Version: 0.140
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211023 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > shellcheck -e SC1090,SC1091 -s dash hook-functions $(find hooks scripts
> > -type f) $({ find . -maxdepth 1 -type f -executable; find debian -maxdepth
> > 1 -type f; find docs kernel -type f; } | xargs grep -l '^#!/bin/sh')
> >
> > In scripts/nfs line 42:
> > if [ "x${NFSROOT}" = "xauto" ]; then
> > ^---^ SC2268: Avoid x-prefix in comparisons as it no
> > longer serves a purpose.
> >
> > Did you mean:
> > if [ "${NFSROOT}" = "auto" ]; then
> >
> >
> > In ./init line 170:
> > [ "x$debug" = "xy" ] && log_output=/dev/kmsg
> > ^---^ SC2268: Avoid x-prefix in comparisons as it no
> > longer serves a purpose.
> >
> > Did you mean:
> > [ "$debug" = "y" ] && log_output=/dev/kmsg
> >
> >
> > In ./update-initramfs line 14:
> > if [ -n "$DPKG_MAINTSCRIPT_PACKAGE" ] && [ $# = 1 ] && [ x"$1" = x-u ]; then
> > ^---^ SC2268:
> > Avoid x-prefix in comparisons as it no longer serves a purpose.
> >
> > Did you mean:
> > if [ -n "$DPKG_MAINTSCRIPT_PACKAGE" ] && [ $# = 1 ] && [ "$1" = -u ]; then
> >
> >
> > In ./unmkinitramfs line 115:
> > if [ -n "$dir" ]; then
> > ^--^ SC2030: Modification of dir is local
> > (to subshell caused by (..) group).
> >
> >
> > In ./unmkinitramfs line 130:
> > xcpio "$subarchive" "${dir:+$dir/main}" -i "$@"
> > ^---^ SC2031: dir was
> > modified in a subshell. That change might be lost.
> > ^--^ SC2031: dir was modified
> > in a subshell. That change might be lost.
> >
> >
> > In ./unmkinitramfs line 133:
> > xcpio "$initramfs" "$dir" -i "$@"
> > ^--^ SC2031: dir was modified in a
> > subshell. That change might be lost.
> >
> >
> > In debian/initramfs-tools-core.postrm line 5:
> > if [ "x${1}" = "xpurge" ]; then
> > ^-^ SC2268: Avoid x-prefix in comparisons as it no longer serves a
> > purpose.
> >
> > Did you mean:
> > if [ "${1}" = "purge" ]; then
> >
> > For more information:
> > https://www.shellcheck.net/wiki/SC2030 -- Modification of dir is local
> > (to ...
> > https://www.shellcheck.net/wiki/SC2031 -- dir was modified in a subshell.
> > T...
> > https://www.shellcheck.net/wiki/SC2268 -- Avoid x-prefix in comparisons
> > as ...
> > make[1]: *** [debian/rules:28: override_dh_auto_test] Error 1
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2021/10/23/initramfs-tools_0.140_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
Merging with #992798 as this is the same underlying issue.
Regards,
Salvatore
Bug#994061: [Pkg-libvirt-maintainers] Bug#994061: libvirt: new upstream version available
Hi Andrea, On Sun, Oct 24, 2021 at 12:38:44PM +0200, Andrea Bolognani wrote: > On Fri, Oct 22, 2021 at 09:10:26AM +0200, Guido Günther wrote: > > On Fri, Sep 10, 2021 at 09:25:06PM +0200, Salvatore Bonaccorso wrote: > > > Source: libvirt > > > Version: 7.6.0-1 > > > Severity: wishlist > > > X-Debbugs-Cc: car...@debian.org > > > > > > Hi > > > > > > When feasible, there is a new upstream version 7.7.0 available. Would > > > it be possible to push it to unstable? > > > > Would be great. I keeps slipping here. Maybe Andrea has it on the list > > already? > > Right. I've been trying to stay on top of upstream releases and > import them into Debian quickly, but unfortunately real life keeps > getting in the way :( > > 7.9.0 is set to be released in about a week, so spending time on > older releases at this point feels like a waste of time. I'll try to > package 7.9.0 shorty after it's out. Thank you, much appreciated! And yes, this is sensible to skip now to 7.9.0. Thanks to you both for working on libvirt! Regards, Salvatore
Bug#885081: brasero: Can not burn cue/bin image to audio CD
tags 885081 wontfix On Sun, Oct 24, 2021 at 1:51 PM Tony Houghton wrote: > > On Sun, 24 Oct 2021 at 08:12, Mathieu Malaterre wrote: >> >> Would it be possible to post your "cue" file ? If not possible what is >> the output of: >> >> $ cdrdao simulate --device ATA:0,0,0 --driver generic-mmc --speed 16 >> brasero.cue > > > Sorry, I don't have that cue file any more, or even the same OS. If nobody > else has the same problem I guess this can be closed. OK. Thanks for the quick response.
Bug#997697: libesmtp-dev: Missing dependency on libssl-dev
Interestingly this appears to be a long-standing issue as I can't find any version since Stretch that shows libesmtp-dev depending on libssl-dev. Versions prior to 1.1.0 did not use pkg-config or Meson/Ninja build system for that matter. This was the first iteration of the new build system changes. Working on an updated version and hopefully will have it released shortly for you try. On Sun, Oct 24, 2021 at 8:09 AM Salvatore Bonaccorso wrote: > Package: libesmtp-dev > Version: 1.1.0-2 > Severity: serious > Justification: Missing dependency > X-Debbugs-Cc: car...@debian.org > > Hi > > libesmtp-1.0.pc contains > > Requires.private: openssl >= 1.1.0 > > but the libesmtp-dev binary package misses a Depends on libssl-dev > accordingly. > > Accordingly: > > $ pkg-config --print-errors --exists libesmtp-1.0 > Package openssl was not found in the pkg-config search path. > Perhaps you should add the directory containing `openssl.pc' > to the PKG_CONFIG_PATH environment variable > Package 'openssl', required by 'libesmtp-1.0', not found > > Regards, > Salvatore >
Bug#997256: rdfind: FTBFS: rdfind.cc:225:30: error: ‘numeric_limits’ is not a member of ‘std’
This is fixed by commit https://github.com/pauldreik/rdfind/commit/61877de88d782b63b17458a61fcc078391499b29 which is on branch devel but not yet master. Paul Dreik Den 2021-10-23 kl. 21:24, skrev Lucas Nussbaum: Source: rdfind Version: 1.5.0-1 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): g++ -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o Rdutil.o Rdutil.cc rdfind.cc: In function ‘Options parseOptions(Parser&)’: rdfind.cc:225:30: error: ‘numeric_limits’ is not a member of ‘std’ 225 | o.maximumfilesize = std::numeric_limits::max(); | ^~ rdfind.cc:225:45: error: expected primary-expression before ‘decltype’ 225 | o.maximumfilesize = std::numeric_limits::max(); | ^~~ make[2]: *** [Makefile:662: rdfind.o] Error 1 The full build log is available from: http://qa-logs.debian.net/2021/10/23/rdfind_1.5.0-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with mine so that we can identify if something relevant changed in the meantime.
Bug#997797: virtaal: Unable to open files
Package: virtaal
Version: 0.7.1+git20191021+ds1-2
Severity: important
Dear Maintainer,
after an upgrade from Debian 10 Buster to Debian 11 Bullseye Virtaal has
become unusable.
Using the menu point "/File/Open" does not yield the file selection window.
Clicking on the link to previously used files yields an error message on
the desktop and via console:
ERROR:root:MainController.open_file(filename="/home/hiereth/l10n/shadow/shadow_1:4.8.1-1_de.po",
uri="")
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/virtaal/controllers/maincontroller.py",
line 210, in open_file
self.store_controller.open_file(filename, uri, forget_dir=forget_dir)
File "/usr/lib/python3/dist-packages/virtaal/controllers/storecontroller.py",
line 227, in open_file
self.store = StoreModel(filename, self)
File "/usr/lib/python3/dist-packages/virtaal/models/storemodel.py", line 62,
in __init__
self.load_file(fileobj)
File "/usr/lib/python3/dist-packages/virtaal/models/storemodel.py", line 149,
in load_file
self.update_stats(filename=filename)
File "/usr/lib/python3/dist-packages/virtaal/models/storemodel.py", line 172,
in update_stats
from translate.storage import statsdb
ImportError: cannot import name 'statsdb' from 'translate.storage'
(/usr/lib/python3/dist-packages/translate/storage/__init__.py)
The programme starts with these error messages,
hiereth@lune:~$ virtaal
ERROR:root:Failed to load plugin "tm"
Could not find plug-in "tm"
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/virtaal/controllers/plugincontroller.py",
line 115, in enable_plugin
plugin_class = self._get_plugin_class(name)
File "/usr/lib/python3/dist-packages/virtaal/controllers/plugincontroller.py",
line 188, in _get_plugin_class
raise Exception('Could not find plug-in "%s"' % (name))
Exception: Could not find plug-in "tm"
ERROR:root:Failed to load plugin "spellchecker"
No module named 'gtkspell'
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/virtaal/controllers/plugincontroller.py",
line 117, in enable_plugin
self.plugins[name] = plugin_class(name, self.controller)
File "/usr/lib/python3/dist-packages/virtaal/plugins/spellchecker.py", line 70
, in __init__
import gtkspell
ModuleNotFoundError: No module named 'gtkspell'
ERROR:root:Failed to load plugin "opentran"
Could not find plug-in "opentran"
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/virtaal/controllers/plugincontroller.py",
line 115, in enable_plugin
plugin_class = self._get_plugin_class(name)
File "/usr/lib/python3/dist-packages/virtaal/controllers/plugincontroller.py",
line 188, in _get_plugin_class
raise Exception('Could not find plug-in "%s"' % (name))
Exception: Could not find plug-in "opentran"
TypeError: string argument expected, got 'bytes'
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/virtaal/views/mainview.py", line 769, in
_on_file_open
self.open_file()
File "/usr/lib/python3/dist-packages/virtaal/views/mainview.py", line 540, in
open_file
filename_and_uri = self.show_open_dialog()
File "/usr/lib/python3/dist-packages/virtaal/views/mainview.py", line 604, in
show_open_dialog
last_path = (pan_app.settings.general["lastdir"] or
"").decode(sys.getdefaultencoding())
AttributeError: 'str' object has no attribute 'decode'
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/virtaal/views/welcomescreenview.py",
line 126, in _on_button_clicked
self.controller.open_file()
File
"/usr/lib/python3/dist-packages/virtaal/controllers/welcomescreencontroller.py",
line 70, in open_file
self.main_controller.open_file(filename)
File "/usr/lib/python3/dist-packages/virtaal/controllers/maincontroller.py",
line 188, in open_file
return self.view.open_file()
File "/usr/lib/python3/dist-packages/virtaal/views/mainview.py", line 540, in
open_file
filename_and_uri = self.show_open_dialog()
File "/usr/lib/python3/dist-packages/virtaal/views/mainview.py", line 604, in
show_open_dialog
last_path = (pan_app.settings.general["lastdir"] or
"").decode(sys.getdefaultencoding())
AttributeError: 'str' object has no attribute 'decode'
It seems the problem has already been reported to the developers of Virtaal:
7.6.2021:
I'm getting the same error on debian bullseye.
(auf https://github.com/translate/virtaal/issues/3323
Best regards
Markus
-- System Information:
Debian Release: 11.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 5.10.0-9-686-pae (SMP w/1 CPU thread)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 virtaal depends on:
ii gir1.2-gtk-3.03.24.24-4
ii libjs-sphinxdoc
Bug#997370: emacs-wgrep: FTBFS: build-dependency not installable: elpa-dash-functional
reassign 997370 silversearcher-ag-el 0.48-1 affects emacs-wgrep fixed 997370 silversearcher-ag-el/0.48-1.1 thanks Lucas Nussbaum writes: > Source: emacs-wgrep > Version: 2.3.2+9.gf0ef9bf-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): >> +--+ >> | Install package build dependencies >> | >> +--+ >> >> >> Setup apt archive >> - >> >> Merged Build-Depends: debhelper-compat (= 13), dh-elpa, elpa-ag, >> build-essential, fakeroot >> Filtered Build-Depends: debhelper-compat (= 13), dh-elpa, elpa-ag, >> build-essential, fakeroot >> dpkg-deb: building package 'sbuild-build-depends-main-dummy' in >> '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. >> Ign:1 copy:/<>/apt_archive ./ InRelease >> Get:2 copy:/<>/apt_archive ./ Release [957 B] >> Ign:3 copy:/<>/apt_archive ./ Release.gpg >> Get:4 copy:/<>/apt_archive ./ Sources [388 B] >> Get:5 copy:/<>/apt_archive ./ Packages [459 B] >> Fetched 1804 B in 0s (0 B/s) >> Reading package lists... >> Reading package lists... >> >> Install main build dependencies (apt-based resolver) >> >> >> Installing build dependencies >> Reading package lists... >> Building dependency tree... >> Some packages could not be installed. This may mean that you have >> requested an impossible situation or if you are using the unstable >> distribution that some required packages have not yet been created >> or been moved out of Incoming. >> The following information may help to resolve the situation: >> >> The following packages have unmet dependencies: >> elpa-ag : Depends: elpa-dash-functional but it is not installable >> E: Unable to correct problems, you have held broken packages. >> apt-get failed. > > > The full build log is available from: > http://qa-logs.debian.net/2021/10/23/emacs-wgrep_2.3.2+9.gf0ef9bf-2_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please marking it as > 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. signature.asc Description: PGP signature
Bug#985957: Bug#987615: Bug#985957: usrmerge has 47.3MB of dependencies
On Sun, 24 Oct 2021 17:12:40 +0100, Niko Tyni wrote: > The libnumber-compare-perl and libtext-glob-perl modifications are trivial > (override dh_perl to dh_perl -d). I suggest modifying at least those > two packages instead of bundling them. Both packages uploaded with the suggested 'dh_perl -d' change. 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 `- signature.asc Description: Digital Signature
Bug#995566: RFS: golang-github-bytedance-gopkg/0.0~git20210910.e4efae9-1 [ITP] -- Universal Utilities for Go (library)
Hi Aloïs Micard, Thanks for reply, Yes, I've built it in newly created vagrant debian vm using pbuilder, and it works well. According to the failed log you provided, I wonder if your cpu has something special. Could you please provide the lscpu -v output so I can send it to upstream and find out the reason it failed to test. On Wed, Oct 13, 2021 at 3:21 PM Aloïs Micard wrote: > > On Sat, 2 Oct 2021 18:41:42 +0800 Yanhao Mo wrote: > > Package: sponsorship-requests > > Severity: wishlist > > > > Dear mentors, > > > > I am looking for a sponsor for my package "golang-github-bytedance-gopkg": > > > > * Package name: golang-github-bytedance-gopkg > >Version : 0.0~git20210910.e4efae9-1 > >Upstream Author : [fill in name and email of upstream] > > * URL : https://github.com/bytedance/gopkg > > * License : Apache-2.0 > > * Vcs : > > https://salsa.debian.org/go-team/packages/golang-github-bytedance-gopkg > >Section : golang > > > > It builds those binary packages: > > > > golang-github-bytedance-gopkg-dev - Universal Utilities for Go (library) > > > > To access further information about this package, please visit the > > following URL: > > > > https://mentors.debian.net/package/golang-github-bytedance-gopkg/ > > > > Alternatively, one can download the package with dget using this command: > > > > dget -x > > https://mentors.debian.net/debian/pool/main/g/golang-github-bytedance-gopkg/golang-github-bytedance-gopkg_0.0~git20210910.e4efae9-1.dsc > > > > Changes for the initial release: > > > > golang-github-bytedance-gopkg (0.0~git20210910.e4efae9-1) unstable; > > urgency=medium > > . > >* Initial release (Closes: #995564) > > > > Regards, > > -- > > Yanhao Mo > > > > > > Hello there! > > I have tried building your package in an up-to-date chroot (amd64) but > the build has failed during the dh_auto_test phase. > Here's the relevant output: > > ``` > === RUN TestLen0_16 > --- PASS: TestLen0_16 (0.00s) > === RUN TestLen17_128 > --- PASS: TestLen17_128 (0.00s) > === RUN TestLen129_240 > --- PASS: TestLen129_240 (0.00s) > === RUN TestLen240_1024 > --- PASS: TestLen240_1024 (0.00s) > === RUN TestLen1025_1048576_scalar > --- PASS: TestLen1025_1048576_scalar (0.00s) > === RUN TestLen1024_1048576_AVX2 > SIGILL: illegal instruction > PC=0x512f99 m=0 sigcode=2 > instruction bytes: 0xc5 0xfe 0x6f 0x8 0xc5 0xfe 0x6f 0x50 0x20 0xc4 0xe2 0x7d > 0x59 0x5 0x81 0x6e > > goroutine 23 [running]: > github.com/bytedance/gopkg/util/xxhash3.accumAVX2(0x660e80, 0xc00018, > 0x619740, 0x400) > > /<>/_build/src/github.com/bytedance/gopkg/util/xxhash3/avx2.s:30 > +0x19 fp=0xc39698 sp=0xc39690 pc=0x512f99 > github.com/bytedance/gopkg/util/xxhash3.xxh3HashLarge(0xc00018, 0x400, > 0x1ad20e5fd78cde6e) > > /<>/_build/src/github.com/bytedance/gopkg/util/xxhash3/hash.go:127 > +0x537 fp=0xc396e8 sp=0xc39698 pc=0x50f0b7 > github.com/bytedance/gopkg/util/xxhash3.Hash(0xc00018, 0x400, 0x20186a0, > 0x1ad20e5fd78cde6e) > > /<>/_build/src/github.com/bytedance/gopkg/util/xxhash3/hash.go:33 > +0x52 fp=0xc39710 sp=0xc396e8 pc=0x50e912 > github.com/bytedance/gopkg/util/xxhash3.TestLen1024_1048576_AVX2(0xc01e00) > > /<>/_build/src/github.com/bytedance/gopkg/util/xxhash3/correctness_test.go:105 > +0xb7 fp=0xc39780 sp=0xc39710 pc=0x510a77 > testing.tRunner(0xc01e00, 0x5591e8) > /usr/lib/go-1.16/src/testing/testing.go:1193 +0xef fp=0xc397d0 > sp=0xc39780 pc=0x4cd84f > runtime.goexit() > /usr/lib/go-1.16/src/runtime/asm_amd64.s:1371 +0x1 fp=0xc397d8 > sp=0xc397d0 pc=0x46c6e1 > created by testing.(*T).Run > /usr/lib/go-1.16/src/testing/testing.go:1238 +0x2b3 > > goroutine 1 [chan receive]: > testing.(*T).Run(0xc01e00, 0x553458, 0x18, 0x5591e8, 0x47f101) > /usr/lib/go-1.16/src/testing/testing.go:1239 +0x2da > testing.runTests.func1(0xc01380) > /usr/lib/go-1.16/src/testing/testing.go:1511 +0x78 > testing.tRunner(0xc01380, 0xc89de0) > /usr/lib/go-1.16/src/testing/testing.go:1193 +0xef > testing.runTests(0xc0c048, 0x62fc20, 0xe, 0xe, 0xc051c0102355a113, > 0x8bd496be5e, 0x633900, 0x550c81) > /usr/lib/go-1.16/src/testing/testing.go:1509 +0x2fe > testing.(*M).Run(0xca8000, 0x0) > /usr/lib/go-1.16/src/testing/testing.go:1417 +0x1eb > main.main() > _testmain.go:71 +0x138 > > rax0x660e80 > rbx0x619740 > rcx0xc00018 > rdx0x619740 > rdi0x18e82621e5dca703 > rsi0x400 > rbp0xc396d8 > rsp0xc39690 > r8 0x3fd7867397525a9a > r9 0x43f2905c46cd412f > r100xff7aa508c0f63fe5 > r110x9e3779b185ebca87 > r120xc39708 > r130x0 > r140x578284 > r150x0 > rip0x512f99 > rflags 0x10202 > cs 0x33 > fs 0x0 > gs 0x0 > FAILgithub.com/bytedance/gopkg/util/xxhash3 0.575s > ?
Bug#997359: Inkscape crashes when running as batch without X11
On 24.10.21 18:29, Mattia Rizzolo wrote: Since you managed to reproduce it and all, could you perhaps consider forwarding it yourself on https://gitlab.com/inkscape/inbox ? I would prefer if you could do it. I am not very familar with inkscape, and the icon creation here is almost the only case where I use it. This happend before in #959885, but was not really reproducible. And it still is not for me: (sid_amd64-dchroot)mattia@barriere ~ % inkscape --export-filename=foo.png /usr/share/inkscape/templates/about_screen.svg --export-type=png ; echo return code: $? [...] You did not use the "--batch-process" option. If you add this, you get the crash. From the man page, this option is mandatory for batch processing. Cheers Ole
Bug#997792: command-not-found: local variable 'cnf' referenced before assignment
Package: command-not-found Package version: 0.3 Python version: 3.7.3 final 0 Distributor ID: PureOS Description: PureOS Release: 9.0 Codename: amber Exception information: local variable 'cnf' referenced before assignment Traceback (most recent call last): File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in crash_guard callback() File "/usr/lib/command-not-found", line 93, in main if not cnf.advise(args[0], options.ignore_installed) and not options.no_failure_msg: UnboundLocalError: local variable 'cnf' referenced before assignment I ran "ls -l /var/lib/command-not-found" and noticed that there were no files in the directory. I then updated command-not-found, but this did not solve the problem. I suspect that missing the "command.db" file is causing a problem. Best, Arcenis Rojas -- Sent with Tutanota, the secure & ad-free mailbox.
Bug#994204: dh_installsystemd: --no-stop-on-upgrade has no effect, seemingly broken in 6067bc2f
On Tue, 21 Sep 2021 at 09:27:04 +0200, Fabian Grünbichler wrote: > also started to run into this, this breaks two not that uncommon > use-cases rather badly: > > - services that support hot-reloading (via ExecReload) without service > interruption, as opposed to restarting which does > - services that don't support hot-reloading, but where restarting has > dangerous side-effects and should be done manually (e.g., hypervisor > services where restarting means stopping all running guests, services > that have long-running tasks that would get interrupted and start over > or get lost when restarted, ...) The D-Bus well-known system bus in the dbus package is a particularly prominent example of the second use-case. As far as I can tell, next time dbus/unstable or dbus/experimental gets binNMU'd, they will break desktop systems (terminate NetworkManager, abruptly log out from GNOME, etc.) when upgraded. This seems like an unexpected time-bomb. I'm going to try to work around this in dbus by using --no-start, and starting the service from the handwritten parts of the maintainer scripts instead. smcv
Bug#997796: unicode-data: Missing emoji-data.txt since 14.0.0-1
Package: unicode-data Version: 14.0.0-1 Severity: important X-Debbugs-Cc: z...@debian.org Control: block 997701 by -1 Dear Maintainer, Since 14.0.0-1, emoji-data.txt file is no longer available. This causes src:golang-github-mattn-go-runewidth FTBFS, since it needs this file to generate emoji related information. This file is in UCD.zip, so please include it.
Bug#973313: The locales package not installed in salsa lintian Docker image
Hi, On Sun, Oct 24, 2021 at 6:45 AM xiao sheng wen wrote: > > The "LC_ALL=en_US.UTF-8" strings is outdated in this command. With a Chinese default locale, you probably have a lot more experience with all this, but I do not understand. Lintian does not use en_US.UTF-8 but C.UTF-8. [1] Should it only use LANG? How does that jibe with the recommendation here [2][3] to always use LC_ALL when running programs? Thanks! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Documentation/Manual.pm#L295 [2] https://stackoverflow.com/a/30480596 [3] https://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html
Bug#995339: [Pkg-rust-maintainers] Bug#995339: lalrpop: Incomplete license information
Bastian Germann: >> In fact there is nowhere in the d/copyright file format to put this >> information; and it would not be efficient to do so since the information >> already exists in the d/copyright of those other packages. > > Maybe there is nowhere in the DEP-5 format, which is not mandatory by now. > This inefficiency is why I suggested to contact FTP Master about it. I do not > think, there is a good mechanism for it in Debian right now. Maybe, there > should be a similar field to Built-Using that is not about source retaining > but about applicable licenses from other packages. > (Note: the name "DEP-5" refers to when the format was just a proposal, but now it is the "official" format.) The current mechanism is to look in the d/copyright of the other package. What do you think is bad or not good about it? Taking a step back for some perspective, I also suggest you might want to spend your own time on other things that are more productive and have more real-world impact. Nobody is going to get sued over this, there is no legal basis for doing so as the license information is already in an easy-to-access place, namely the d/copyright of the other package. This will be my last message in the thread because I also want to spend my time doing more constructive things. Ximin -- GPG: ed25519/56034877E1F87C35 https://github.com/infinity0/pubkeys.git
Bug#997359: Inkscape crashes when running as batch without X11
On Sun, Oct 24, 2021 at 05:14:19PM +0200, Ole Streicher wrote: > Inkscape is used during the debian-astro package to create a png icon > from the original svg image. This now crashes: :( > This is the backtrace: > > (gdb) bt Since you managed to reproduce it and all, could you perhaps consider forwarding it yourself on https://gitlab.com/inkscape/inbox ? > This happend before in #959885, but was not really reproducible. And it still is not for me: (sid_amd64-dchroot)mattia@barriere ~ % inkscape --export-filename=foo.png /usr/share/inkscape/templates/about_screen.svg --export-type=png ; echo return code: $? Unable to init server: Could not connect: Connection refused Failed to get connection ** (inkscape:15042): CRITICAL **: 16:28:52.226: dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed ** (inkscape:15042): CRITICAL **: 16:28:52.226: dbus_g_proxy_call: assertion 'DBUS_IS_G_PROXY (proxy)' failed ** (inkscape:15042): CRITICAL **: 16:28:52.226: dbus_g_connection_register_g_object: assertion 'connection != NULL' failed Background RRGGBBAA: b1b1b100 Area 0:0:750:625 exported to 750 x 625 pixels (96 dpi) return code: 0 (sid_amd64-dchroot)mattia@barriere ~ % :\ it totally is not crashing; sure it's dumping noise, but still succeeding at its job. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#994725: fail2ban: Fail2ban 0.11.2 exim failregexs don't match logs from Debian's exim 4.94.2
Hi Diane and Sylvestre, Sorry to drop in, but I was also looking into this and am actually not sure about Diane's patch. I found some completely different reasons for why some log lines get missed. I am also using fail2ban 0.11.2 with exim 4.94.2. Yes, I also see it misses some lines, but I also still see a lot of lines being matched. None of my log lines contains a `pid`, so I doubt that `%(pid)s` is the reason for missing some lines. Also, the `%(pid)s` part is actually defined as optional in /etc/fail2ban/filter.d/exim-common.conf: pid = (?: \[\d+\])? Also, what happens if someone does log `pid`, because with the patch the filter will only expect whitespace, not a `pid` anymore. Perhaps Diane is using a different log format or watching a different log file than I do? Maybe affected by something like this issue where the user had two timestamps in the log and was also able to solve it by using a custom `pid` prefix: - https://github.com/fail2ban/fail2ban/issues/3060 (exim logs from journal do not match) Furthermore, Diane's patch does two more things in addition to removing the `%(pid)s` that I have doubts about: First, the line about `SMTP call`: It seems the patch actually reverts some improvements made between fail2ban 0.10.2 and 0.11.2, such as the additional matching of `syntax or protocol errors` and `last command was`. I do not see why this is necessary. Second, Diane's patch adds a new line to the filter to also match lines containing `LOGIN authentication mechanism not supported`. I do not know if this is a good addition, I do not need it myself, but either way, as far as I can tell this is simply not in the upstream filter. I wonder if this is not a bit too big of a Debian-specific deviation from upstream. Perhaps it should better be forwarded or directly submitted upstream. Actually, I found some other reasons for why fail2ban misses some log lines: Example 1: `SMTP call` in exim 4.94.2 has a new field at the end. exim 4.92: 2021-08-28 08:40:29 SMTP call from census9.shodan.io [71.6.167.142] dropped: too many syntax or protocol errors (last command was "?") exim 4.94.2: 2021-10-14 17:20:55 SMTP call from census6.shodan.io [66.240.236.119] dropped: too many syntax or protocol errors (last command was "?", NULL) fail2ban 0.10.2 misses both, because `syntax or protocol errors` was only added in 0.11.2. fail2ban 0.11.2 matches the exim 4.92 line, but not the 4.94.2 line, because it does not expect the last field (`, NULL`). Example 2: No match on encrypted connections. Already with the previous fail2ban 0.10.2 + exim 4.92 and now still with fail2ban 0.11.2 + exim 4.94.2. exim 4.92 and 4.94.2, connection without TLS: 2021-10-01 15:27:31 H=(win2012r2RDP) [77.247.110.246] F= rejected RCPT : relay not permitted 2021-10-20 14:33:00 H=(win2012r2RDP) [77.247.110.115] F= rejected RCPT : relay not permitted Both match with fail2ban 0.10.2 and 0.11.2. exim 4.92 and 4.94.2, connection with TLS: 2021-10-01 15:08:40 H=(xhU9K1I7) [119.91.134.193] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no F= rejected RCPT <726357...@qq.com>: relay not permitted 2021-10-17 08:52:37 H=(LH5pvsWxa) [36.25.57.206] X=TLS1.2:ECDHE_SECP256R1__RSA_SHA512__AES_256_GCM:256 CV=no F= rejected RCPT <897855...@qq.com>: relay not permitted Both missed by fail2ban 0.10.2 and 0.11.2. I did not finish checking all missed lines, but I suspect there are more specific causes that need to be addressed and doubt that removing `%(pid)s` and reverting some parts to 0.10.2 is the right solution. Best regards, Peter
Bug#997658: Botan FTBFS
This test failure is a known issue which is caused by the expiration of a CA certificate which was used in the test suite. The problem will be addressed in 2.18.2, which is expected to be released within the next day or two.
Bug#995339: lalrpop: Incomplete license information
Control: reopen -1 Control: reassign -1 ftp.debian.org On Sat, 23 Oct 2021 19:11:04 +0100 Ximin Luo wrote: Source: rust-lalrpop Followup-For: Bug #995339 The d/copyright file is about the source package not the binary package, you are misinterpreting policy. In Policy 12.5, I read "Every package must be accompanied by a verbatim copy of its distribution license(s) in the file /usr/share/doc/PACKAGE/copyright." There is no indication that the d/copyright file is about the source package only. In fact quite the opposite, as in 2.3 (Copyright consideration) there is a distinction between source and binary distribution. In my interpretation, the copyright file for one specific package has to fulfill the legal obligations of its contents' distribution license(s), including binary packages with their specific obligations. How would a user who does not know about the X-Cargo-Built-Using shtick know that they are to obtain the copyright files of dozens of other packages (NOT dependencies) to get the complete distribution license information? I think, Debian manuals just point to the copyright file for license information. https://wiki.debian.org/StaticLinking mentions: "Packages can declare they were built using code from other packages by using the Built-Using header and the Debian archive keeps around old sources, marking them with the Extra-Source-Only header. Debian Policy unfortunately says that Built-Using may *only* be used for the purposes of DFSG/license compliance so tracking static linking must be done using custom headers." In fact there is nowhere in the d/copyright file format to put this information; and it would not be efficient to do so since the information already exists in the d/copyright of those other packages. Maybe there is nowhere in the DEP-5 format, which is not mandatory by now. This inefficiency is why I suggested to contact FTP Master about it. I do not think, there is a good mechanism for it in Debian right now. Maybe, there should be a similar field to Built-Using that is not about source retaining but about applicable licenses from other packages. Closing the bug report for this reason. Reopening and reassigning to FTP Master to check if they are content with the current "custom headers" over a complete d/copyright approach. If "custom headers" is enough, I request to have a complete list of their names at a prominent place to enable users to get the complete license info for a package.
Bug#997489: fonttools: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
It is caused by unicode-data updated to 14.0. The doctest is to get all
attributes of an Arabic symbol, but in 14.0 "Nkoo" attribute is added to the
list, causing the test to fail.
Yao Wei
(This email is sent from a phone; sorry for HTML email if it happens.)
>> === FAILURES
>> ===
>> ___ [doctest] fontTools.unicodedata.script_extension
>> ___
>> 071 Return the script extension property assigned to the Unicode character
>> 072 'char' as a set of string.
>> 073
>> 074 >>> script_extension("a") == {'Latn'}
>> 075 True
>> 076 >>> script_extension(chr(0x060C)) == {'Rohg', 'Syrc', 'Yezi',
>> 'Arab', 'Thaa'}
>> Expected:
>>True
>> Got:
>>False
>>
>> /<>/.pybuild/cpython3_3.9/build/fontTools/unicodedata/__init__.py:76:
>> DocTestFailure
Bug#987615: Bug#985957: usrmerge has 47.3MB of dependencies
On Thu, Oct 07, 2021 at 03:59:11AM +0200, Michael Biebl wrote: > On Mon, 16 Aug 2021 07:46:49 +0100 Niko Tyni wrote: > > On Mon, Aug 16, 2021 at 12:11:26AM +0200, Marco d'Itri wrote: > > > > > I see no reason to move the usrmerge dependencies to perl-base: usrmerge > > > is supposed to be installed, run and then removed again. > > > If something is moved to perl-base then it will use space on every > > > Debian system. > > > > My suggestion in #987615 (which I also copied to usrmerge@pdo, being > > unaware of #985957) is to introduce separate packages of the usrmerge > > dependencies, and limit their dependencies to perl-base only. This does > > not grow perl-base and can be phased out later, so it does not impose > > a permanent cost on everybody. > > Seems to me, that simply vendoring the necessary perl modules in the > usrmerge package would be a better, simpler and more lightweight approach to > packaging those all invidually as separate packages. Yeah, you're probably right, particularly as I haven't got around to doing much about this so far. I'm fine with that approach FWIW. I did try out the separate package plan at home at one point, and got things working with seven modified or introduced packages (well, eight if you count the usrmerge package too.) Here's some notes, maybe they will save somebody some work even if this is not the chosen path. There's two branches to the usrmerge dependencies: libautodie-perl (would need a separate package) libif-perl (would need a separate package) libtie-refhash-perl (would need a separate package) libfile-find-rule-perl (would need dependency modifications) libfile-find-perl (would need a separate package) libnumber-compare-perl (would need dependency modifications) libtext-glob-perl (would need dependency modifications) Happily all these modules are pure Perl, which makes things a bit easier. The libnumber-compare-perl and libtext-glob-perl modifications are trivial (override dh_perl to dh_perl -d). I suggest modifying at least those two packages instead of bundling them. I'm copying the debian-perl list for some visibility. -- Niko
Bug#997691: Acknowledgement (micro-httpd: fix for Lintian warning about missing Depends on update-inetd)
Actually, unless I'm mistaken, the dependency order in the attached
patch is closer to what's expected. It also removes alternatives that
no longer seem to be in the repository.
Martin-Éric
diff -Nru micro-httpd-20140814/debian/control
micro-httpd-20140814/debian/control
--- micro-httpd-20140814/debian/control 2020-02-06 01:14:09.0 +0200
+++ micro-httpd-20140814/debian/control 2021-10-24 12:29:38.0 +0300
@@ -11,7 +11,7 @@
Package: micro-httpd
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, openbsd-inetd | inet-superserver
| micro-inetd | netcat-traditional | systemd-sysv
+Depends: ${misc:Depends}, ${shlibs:Depends}, update-inetd | inet-superserver |
openbsd-inetd | inetutils-inetd | rlinetd | xinetd | netcat-traditional |
systemd-sysv
Suggests: micro-proxy
Provides: httpd
Description: really small HTTP server
Bug#947123: apt package list in resulting system cannot be cleared using hooks, increases the image size
Sorry for the late reply, Passing the option "--apt-indices false" to "lb config", is indeed the correct solution, confirmed by https://manpages.debian.org/bullseye/live-build/lb_config.1.en.html and my own build results (saved 178MB of APT indices in the squashfs) Thank you
Bug#993085: deluge-web: Stack traces and python errors when using the web and interacting with deluged daemon
On Fri, 27 Aug 2021 12:10:22 +0200 Jonas Andradas wrote: > Package: deluge-web > Version: 2.0.3-3.1 > Severity: important > X-Debbugs-Cc: j.andra...@gmail.com > > Dear Maintainer, > > Since the update to Debian 11 "bullseye", which updated Python to > version 3.9, I am seeing that deluge-web (and the deluged daemon) are > showing some errors. > > When using the web interface to connect to the daemon, the web appears > empty, and any attempt to modify the configuration does not seem to > persist this. Adding a torrent (from a URL or a file, for example Debian's ISO > installer [1]) errors start to appear in the console and, despite the > torrent seems added in the web interface, it never starts downloading, > and does not seem recognized by the backend deluged daemon. > > [1] > https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/debian-11.0.0-amd64-DVD-1.iso.torrent > > The errors I observe in the console are the following ones, repeated > many times: > > Temporarily disabling observer LegacyLogObserverWrapper(>) due to exception: [Failure instance: Traceback: : findCaller() takes from 1 to 2 positional arguments but 3 were given > /usr/lib/python3/dist-packages/twisted/internet/defer.py: 568:_startRunCallbacks > /usr/lib/python3/dist-packages/twisted/internet/defer.py:962:__del__ > /usr/lib/python3/dist-packages/twisted/logger/_logger.py:190:failure > /usr/lib/python3/dist-packages/twisted/logger/_logger.py:144:emit > --- --- > /usr/lib/python3/dist-packages/twisted/logger/_observer.py:131:__call__ > /usr/lib/python3/dist-packages/twisted/logger/_legacy.py:93:__call__ > /usr/lib/python3/dist-packages/deluge/log.py:204:emit > /usr/lib/python3.9/logging/__init__.py:1489:critical > /usr/lib/python3.9/logging/__init__.py:1573:_log > ] > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 568, in _startRunCallbacks > self._runCallbacks() > File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 962, in __del__ > log.failure(format, > File "/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 190, in failure > self.emit(level, format, log_failure=failure, **kwargs) > File "/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 144, in emit > self.observer(event) > --- --- > File "/usr/lib/python3/dist-packages/twisted/logger/_observer.py", line 131, in __call__ > observer(event) > File "/usr/lib/python3/dist-packages/twisted/logger/_legacy.py", line 93, in __call__ > self.legacyObserver(event) > File "/usr/lib/python3/dist-packages/deluge/log.py", line 204, in emit > getattr(LoggingLoggerClass, event_dict['log_level'].name)( > File "/usr/lib/python3.9/logging/__init__.py", line 1489, in critical > self._log(CRITICAL, msg, args, **kwargs) > File "/usr/lib/python3.9/logging/__init__.py", line 1573, in _log > fn, lno, func, sinfo = self.findCaller(stack_info, stacklevel) > builtins.TypeError: findCaller() takes from 1 to 2 positional arguments but 3 were given > > Unhandled error in Deferred: > 12:04:33 [CRITICAL][twisted:154 ] Unhandled error in Deferred: > This seems to be a known issue, cause because the logging.Logger class in Python > 3.8 has changed. There is a path for file deluge/log.py which solves the issue (I tested this locally), which is referenced in deluge's git [1] [1] diff --git a/deluge/log.py b/deluge/log.py index 75e8308..0f9877f 100644 --- a/deluge/log.py +++ b/deluge/log.py @@ -86,7 +86,7 @@ class Logging(LoggingLoggerClass): def exception(self, msg, *args, **kwargs): yield LoggingLoggerClass.exception(self, msg, *args, **kwargs) -def findCaller(self, stack_info=False): # NOQA: N802 +def findCaller(self, *args, **kwargs): # NOQA: N802 f = logging.currentframe().f_back rv = '(unknown file)', 0, '(unknown function)' while hasattr(f, 'f_code'):
Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture
Hi Justus! I have incorporated the changes recommended by Helmut to 20.x alpha build. I installed kodi:i386 in amd64 container to verify installation completes: echo "deb [trusted=yes] file:///external-repo ./" > /etc/apt/sources.list.d/local-repo.list dpkg --add-architecture i386 apt-get update apt-get install kodi:i386 kodi-eventclients-kodi-send:i386 I dont see this change feasible for 19.x because I want to keep compatibility with everything from sid to buster-backports during 19.x lifecycle. However I will be doing unofficial 20.x alpha builds and I invite you to test armhf build I will prepare tonight. You will be using the same nightlies that I do use at home. Are you ready to test the build? -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#997793: RFS: libcxx-serial/1.2.1-5 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Control: tags -1 moreinfo Hi Alec, There was a NMU of libcxx-serial [1] . This NMU is not included in your updated package --> You need to include the changed of this MMU in the package and possibly into your git repo... [1] See https://deb.debian.org/debian/pool/main/libc/libcxx-serial/libcxx-serial_1.2.1-4.1.dsc -- tobi
Bug#997663: general: bullseye, system freezes completely when firefox freezes
I just wrote an Email to the manufacturer of my "TUXEDO InfinityBook
Pro 13" and referenced this bug report. They sell specifically Linux
suited Hardware. Since they offer a Distro of their own I hope they can
shed some light on the hardware issues raised here. If there are some
special kernel parameters to be set they should know about it.
Also, I tried to provoke the system freeze with a memory bomb:
> #include
> #include
>
> #define KIB 1024
> #define MIB (KIB * KIB)
> #define ALLOC_MIB 10
> #define ALLOC_SIZE (ALLOC_MIB * MIB)
>
> int main (void)
> {
> int totalMiB = 0;
>
> printf("membomb: started\n");
> while (1)
> {
> if ( malloc(ALLOC_SIZE) == NULL )
> {
> printf("membomb: malloc() failed, exiting\n");
> return 1;
> }
> totalMiB += ALLOC_MIB;
> printf("membomb: total memory allocated: %d MiB\n", totalMiB);
> }
> return 0;
> }
I tried this on AC and on Battery to no avail I'm afraid. After some
sluggish input behaviour the system kills the process, as it should.
Maybe I need to consume the memory of the graphic chip? For Intel HD
Graphics, is that even a separate thing?
Regards,
Jacob
Bug#997425: Related to #997341
This seems to be tied to a missing build dependency on python3-sphinx-autoapi. I added that to my chroot, and now the build for cedar-backup3 succeeds. However, I don't think it adding to the build dependencies here is the right step. I believe that python3-sphinx-autoapi is missing the dependency. Bug #997341 for src:sphinx-autoapi shows the same problem, so I think the solution is just to add the dependency there, and then all downstream packages will build again. KEN -- Kenneth J. Pronovici
Bug#997359: Inkscape crashes when running as batch without X11
Control: reassign -1 inkscape 1.1.1-2 Control: affects -1 src:debian-astro Control: retitle -1 Inkscape crashes when running as batch without X11 Inkscape is used during the debian-astro package to create a png icon from the original svg image. This now crashes: --8<- $ DISPLAY= inkscape --batch-process Debian-Astro-logo.svg --export-width=25 --export-filename=Debian-Astro-logo-25x39.png Unable to init server: Could not connect: Connection refused (inkscape:187075): Gtk-CRITICAL **: 17:05:58.380: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at https://inkscape.org/report with a detailed description of the steps leading to the crash, so we can fix it. (inkscape:187075): Gtk-CRITICAL **: 17:05:58.381: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed (inkscape:187075): Gtk-CRITICAL **: 17:05:58.381: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed (inkscape:187075): Gtk-CRITICAL **: 17:05:58.381: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed Speicherzugriffsfehler (Speicherabzug geschrieben) --8<- This is the backtrace: (gdb) bt #0 0x74ac4eef in Gtk::IconTheme::prepend_search_path(Glib::ustring const&) () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgtkmm-3.0.so.1 #1 0x777ec85e in Inkscape::Application::Application(bool) () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so #2 0x777ed1c0 in Inkscape::Application::create(bool) () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so #3 0x7788a03a in InkscapeApplication::on_startup2() () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so #4 0x77896389 in InkscapeApplication::on_open(std::vector, std::allocator > > const&, Glib::ustring const&) () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so #5 0x763393ad in () at /usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1 #6 0x7546b6cf in g_closure_invoke () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0 #7 0x7547dc92 in () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0 #8 0x75483d5f in g_signal_emit_valist () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0 #9 0x754842cf in g_signal_emit () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0 #10 0x755934c8 in () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0 #11 0x7559376e in g_application_run () at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0 #12 0x75defe4a in __libc_start_main (main= 0x65e0 , argc=5, argv=0x7fffe0b8, init=, fini=, rtld_fini=, stack_end=0x7fffe0a8) at ../csu/libc-start.c:314 #13 0x6eba in _start () This happend before in #959885, but was not really reproducible. Best regards Ole
Bug#996960: scipy: FTBFS in unstable
done On Sun, Oct 24, 2021 at 3:58 AM Graham Inggs wrote: > > Hi Sandro > > On Sat, 23 Oct 2021 at 17:35, Sandro Tosi wrote: > > pydata-sphinx-theme 0.7.1 (which contains that fix) has just been > > uploaded to unstable > > Great, thanks! I see you temporarily disabled building the docs. > Would it be possible to temporarily drop the Build-Depends on > python3-jupyter-sphinx as well? I think that may unblock things. > > Regards > Graham -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#973313: The locales package not installed in salsa lintian Docker image
and concluded that Salsa's host system was probably to blame.
I guess the Salsa's host system use LANG=en_US.UTF-8.
Even lintian had set local $ENV{LC_ALL} = 'C.UTF-8'; , But if only reset
LC_ALL ,it don't reset LANG,
So, the docker still use LANG=en_US.UTF-8(inherit from Salsa's host
system), this will casue this bug.
So the other way to fix this bug is:
set LANG='C.UTF-8' in lib/Lintian/Check/Documentation/Manual.pm.
I hope has chance to do so to prove my guess.
If it fix the bug, this way will do better than that install locales-all
in docker.
Thanks!
--
肖盛文 xiao sheng wen Faris Xiao
OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Bug#997795: hplip: Make a hplip-plugin-installer package
Source: hplip Severity: wishlist X-Debbugs-Cc: bren...@quantumfurball.net Dear Maintainer, As I understand it, licensing restrictions mean that the HP plugin, necessary for some printers/scanners (including the MFC I own), cannot be packaged in the ordinary Debian way. Instead, currently, if the Debian hplip packages receive an update, the next time a user attempts to use their printer/scanner they are interrupted until they download and install the latest plugin. This ends up being a nuisance manual process which is asynchronous with the actual change that made it necessary (the package update). Moreover, such an action (choosing to install the plugin package) is arguably not appropriate for the user role, anyway - rather, it is a system administrator question (for which the user may not actually have permission to decide). (It doesn't help that the download is a single point of failure that can be triggered at this later time; see https://bugs.launchpad.net/hplip/+bug/1948555 ...) Why not create a hplip-plugin-installer package (contrib), version-matched to the other hplip packages, which downloads and installs the HP plugin in its postinst? It would solve the primary issue, taking place at the same time as the other hplip packages are updated (and therefore could fail, and be corrected or reverted, all at that time). As a bonus, it would automate most of that nuisance process while allowing the system administrator (rather than random user) to accept (or decline) the installation. Lots of precedent exists for such a package. A cursory search through the contrib section for "download" in the package description brings up many, with notable examples being ttf-mscorefonts-installer, google-android-ndk-installer (and family), the historical (now-defunct) flashplugin-nonfree, and a swarth of firmware blobs. I'm broadly familiar with the Debian packaging process, but not all of the details. Nevertheless, I am technically inclined, and for how many times this nuisance has bitten me I'm willing to help make this suggestion happen however I can. Best, Brendon -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (100, 'experimental-debug'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#997341: Typing Extensions
This problem seems to impact any package that uses python3-sphinx-autoapi as a build dependency. See also: bug #997425 for cedar-backup3. The fix seems to be as simple as adding a dependency on python3-typing-extensions. I added that to my chroot and now the build for cedar-backup3 succeeds again. KEN -- Kenneth J. Pronovici
Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)
On 2021-10-24 16:24:31 +0300 (+0300), Dmitry Shachnev wrote: [...] > If anyone is still using nose (1.x), please port your packages to > nose2, pure unittest or pytest. I am attaching a dd-list and I > intend to do a MBF in a few weeks when I have more time. Further alternatives include https://packages.debian.org/python3-testrepository or https://packages.debian.org/python3-stestr (both are subunit-emitting test runners), which pretty much all of the OpenStack projects moved to years ago as replacements for nose. -- Jeremy Stanley signature.asc Description: PGP signature
Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator
Hello Feri, Thank you for your advice. > The upstream version number should be 0.7.0~rc2 with a tilde instead of > a hyphen to ensure proper ordering (as Lintian warns about). To do such > transformations automatically, put something like this in the watch file: > > uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/ > I will update the watch file following your advice soon. > > swtpm - Libtpms-based TPM emulator > > swtpm-dev - Include files for the TPM emulator's CUSE interface > > swtpm-libs - Common libraries for TPM emulators > > Why do you deviate from the usual libswtpm-dev/libswtpm0 package names? > Including the SO version in the package name enables installing > incompatible versions side-by-side, which is useful. > > Also, shipping static libraries (like libswtpm_libtpms.a) is generally > recommended against in Debian. Does this package warrant it? The upstream version already has some debian-related files, and I changed them to adopt the package. The author of it wants to name it like libswtpm0, so I used the name. The static libraries are also involved in upstream debian files. Should I change the name like libswtpm instead of libswtpm0 and remove static libraries from the package? > > > swtpm-tools - Tools for the TPM emulator > > Why do you put swtpm-create-tpmca, swtpm-create-user-config-files and > swtpm-localca into /usr/share/swtpm instead of /usr/bin? (This emits > several Lintian information tags.) The author of the upstream project wanted to put them to /usr/share/swtpm. The files are just for the initialization and don't be used for TPM operations directly, so maybe he wanted to put /usr/share/swtpm instead of /usr/bin. Should I move them to /usr/bin? Best regards, Seunghun
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 24 October 2021 at 11:38, Sebastian Ramacher wrote: | On 2021-10-23 19:44:49 -0500, Dirk Eddelbuettel wrote: | > | > I have now 'patched' the upstream setting of GSL_AGE, this results (as kindly | > analysed by Sebastian) in new sonames '26' so I prepared a new version which | > just went out to unstable. | > | > Unless I am mistaken, I need to get the release team on board for a proper | > transition. Correct? | | Yes, the workflow is documented at | https://wiki.debian.org/Teams/ReleaseTeam/Transitions Thank you for the reminder. The last time I did this was likely for the previous libsglSO transition to 25. I also forgot, again, that a new libgslSO triggers NEW and wants a binary upload but corrected that by now so we should get some test builds. I will then reach out to the release team. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#997663: general: bullseye, system freezes completely when firefox freezes
On Sun, 24 Oct 2021 12:25:23 +0200 jacobkoch...@gmail.com wrote: > Wayland > It seems to be the open source driver 'i915' in the package: > 'xserver-xorg-video-intel'. > Does not apply. No proprietary graphics drivers installed. Also try to use Firefox without hardware acceleration. If a process brings down the kernel, I would expect the bug there. > I'm not sure. Maybe I can try the keyboard backlight function? > Or the Fn+Special-Function-Keys like: Volume or Display-Brightness ? I mean networking in the first place, like the SSH. Or when you are connected to IRC, does it time out or stay online? This is just to narrow down where the bug is. I had the experience before some time ago that the input and screen were frozen but the programs were still running. Regards
Bug#997794: xscreensaver: systemd integration leads to spurious deactivations (unblank) on desktop
Package: xscreensaver Version: 5.45+dfsg1-2 Severity: important I took the habit of running "xscreensaver-command -suspend" when leaving my desk. However, after ten(s of) seconds, xscreensaver unblanks and shows the password prompt screen. After timeout, it blanks again, and after some time, unblanks again, in a never-ending cycle. This keeps the screens on a cycle of going into sleep and waking up. My first guess was that random mouse movements were above xscreensaver's ignore threshold; however, an "xev" window having the focus shows no event at all for minutes as long as I don't touch mouse or keyboard. Killing the "xscreensaver-systemd" process fixed it. Being an always-running desktop, it is never suspended, so from reading its man page, I gather xscreensaver-systemd doesn't do anything useful for that particular machine. Let me know what else I can do to help debug the problem. -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.60 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u2 ii libcrypt11:4.4.18-4 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-2 ii libpam0g 1.4.0-9+deb11u1 ii libpango-1.0-0 1.46.2-3 ii libsystemd0 247.3-6 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.10+dfsg-6.7 ii libxmu6 2:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxt6 1:1.2.0-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.45+dfsg1-2 Versions of packages xscreensaver recommends: ii gsfonts-x110.27 ii libjpeg-turbo-progs1:2.0.6-4 ii perl 5.32.1-4+deb11u2 ii wamerican [wordlist] 2019.10.06-1 ii wamerican-huge [wordlist] 2019.10.06-1 ii wbritish-huge [wordlist] 2019.10.06-1 ii wcanadian-huge [wordlist] 2019.10.06-1 ii wfrench [wordlist] 1.2.6-1 ii wngerman [wordlist]20161207-9 ii xfonts-100dpi 1:1.0.4+nmu1.1 Versions of packages xscreensaver suggests: ii chromium [www-browser] 90.0.4430.212-1 ii firefox-esr [www-browser] 78.15.0esr-1~deb11u1 ii fortune-mod [fortune] 1:1.99.1-7.1 pn gdm3 | kdm-gdmcompat ii lynx [www-browser] 2.9.0dev.6-3~deb11u1 pn qcam | streamer ii w3m [www-browser] 0.5.3+git20210102-6 ii xdaliclock 2.44+debian-2 ii xfishtank 2.5-1+b1 pn xscreensaver-data-extra pn xscreensaver-gl pn xscreensaver-gl-extra -- no debconf information
Bug#997703: Bug#997730: plr: FTBFS: Error: debian/control needs updating from debian/control.in. Run 'pg_buildext updatecontrol'.
Control: close -1 > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Error: debian/control needs updating from debian/control.in. Run > > 'pg_buildext updatecontrol'. > > If you are seeing this message in a buildd log, a sourceful upload is > > required. > > make: *** [debian/rules:10: clean] Error 1 This has already been fixed in the new queue. Christoph
Bug#997199: libmaus2: FTBFS: ./libmaus2/avl/AVLSet.hpp:55:66: error: ‘numeric_limits’ is not a member of ‘std’
Control: tags -1 + confirmed fixed-upstream pending Good day, This issue seems fixed in the latest upstream version 2.0.806. I'm on it. Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/9, please excuse my verbosity. signature.asc Description: PGP signature
Bug#996612: 996612: patch available
Control: tags -1 + patch Control: severity -1 important Dear Maintainer, A patch fixing the bug has already been submitted [1], thus I am adding an appropriate tag. As the bug is blocking update of opencolorio, I am as well raising the severity, as already done for similar bug, #995907. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=996612;filename=fix-expat-cmake.patch;msg=32 Andrius
Bug#984148: [PATCH] Re: gcc-avr: ftbfs with GCC-11
The patch attached to this message allows the building of the gcc-avr
package against GCC 11.
It simply changes the type of member x_spill_indirect_levels of structure
target_reload, defined in file gcc/gcc/reload.h, from bool to int. This
member is only used in file gcc/gcc/reload1.c, where it is incremented as
a integer with the operator ++. In GCC 11, use of this operator on
variables with type bool is forbiden.
At any rate, this member seems to be intended to behave like an integer
elsewhere in the code. For instance, it is passed as the third argument
of the function find_reloads, defined in file gcc/gcc/reload.c, which
accepts an integer as third argument.
Caveat: I did not do extensive tests to check for side effects of this
change.
Best,
Rafael Laboissière
--- gcc-avr-5.4.0+Atmel3.6.2.orig/gcc/gcc/reload.h
+++ gcc-avr-5.4.0+Atmel3.6.2/gcc/gcc/reload.h
@@ -168,7 +168,7 @@ struct target_reload {
value indicates the level of indirect addressing supported, e.g., two
means that (MEM (MEM (REG n))) is also valid if (REG n) does not get
a hard register. */
- bool x_spill_indirect_levels;
+ int x_spill_indirect_levels;
/* True if caller-save has been reinitialized. */
bool x_caller_save_initialized_p;
Bug#973313: The locales package not installed in salsa lintian Docker image
Hi, lintian-explain-tags groff-message [...] N: You can see the warnings yourself by running the command used by Lintian: N: N: LC_ALL=en_US.UTF-8 MANROFFSEQ='' MANWIDTH=80 \ N: man --warnings -E UTF-8 -l -Tutf8 -Z >/dev/null [...] The "LC_ALL=en_US.UTF-8" strings is outdated in this command. I also suggest to update. Thanks! -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》https://www.atzlinux.com 基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x00186602339240CB OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#997488: q2cli: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Control: forwarded -1 https://github.com/qiime2/q2cli/issues/259 Control: tags -1 upstream Good day, Upstream is aware of the issue and is working on a fix [1]. This it is still a work in progress at the moment. [1]: https://github.com/qiime2/q2cli/pull/260 Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Bug#924121: 924121: ITP -> RFP
retitle 924121 RFP: libcassandra-client-perl -- Cassandra::Client - Perl library for accessing Cassandra noowner 924121 thanks I no longer have enough time and enthusiasm to work on packaging Cassandra-related code. I am starting with giving up ITPs, but I will maintain already packaged dependencies, as most of them are in decent shape and do not require too much of attention. Andrius
Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)
Hi all! On Sun, Oct 24, 2021 at 01:49:30PM +0200, Lucas Nussbaum wrote: > Source: nose > Version: 1.3.7-7 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20211023 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > [...] It happens because setuptools v58.0.0 removed support for 2to3 during builds, which nose relied on (because it has a Python 2 codebase). Instead of spending time on a proper Python 3 port, I would prefer to simply let nose die (it is abandoned since 2016). If anyone is still using nose (1.x), please port your packages to nose2, pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF in a few weeks when I have more time. -- Dmitry Shachnev Adrian Vondendriesch flask-mongoengine (U) Adrien Vergé yamllint (U) Afif Elghraoui falcon (U) optlang (U) swiglpk (U) Aggelos Avgerinos imbalanced-learn (U) py-radix (U) Agustin Henze webassets Aigars Mahinovs isbnlib python-dlt python-zipstream Alastair McKinstry metaconfig Alexandre Viau influxdb-python (U) Alvin Chen requirement-parser Ana Custura namecheap python-cymruwhois tldextract yapf Andreas Beckmann piuparts (U) Andreas Metzler libvigraimpex (U) Andreas Tille circlator (U) fastaq (U) gubbins (U) iva (U) kineticstools (U) paleomix (U) python-biom-format (U) python-colormap (U) python-hdmedians (U) python-nose-random (U) python-pbcore (U) python-pyani (U) python-pyfaidx (U) python-pymummer (U) python-pynndescent (U) python-sqlsoup (U) python-xopen (U) pyutilib (U) qiime (U) scoary (U) seqmagick (U) umap-learn (U) youtube-dl Andrej Shadura docker-compose (U) netplan.io (U) sortedcontainers (U) Andrew Chadwick mypaint (U) Andrew Starr-Bochicchio fabric pyxdg (U) Andrey Rahmatullin dateparser (U) Andrius Merkys spglib (U) Angelos Tzotsos python-osmapi (U) anonym onionshare (U) Antoine Beaupré dateparser (U) Antoine Musso python-statsd (U) voluptuous (U) Antonio Terceiro ledger-autosync python-ofxclient (U) rows (U) Antonio Valentino pykdtree (U) pysph (U) python-hdf4 (U) Apollon Oikonomopoulos ripe-atlas-cousteau (U) ripe-atlas-sagan (U) ripe-atlas-tools Arno Töll dput-ng (U) Arthur de Jong python-pskc python-stdnum Arto Jantunen python-inflect (U) Barry Warsaw lazr.delegates (U) lazr.smtptest (U) python-nose-exclude (U) Bas Couwenberg pyosmium (U) python-mapnik (U) python-osmapi (U) python-stetl (U) Bdale Garbee rocketcea Ben Finney python-lockfile Benda Xu vitables (U) Benjamin Drung ubuntu-dev-tools (U) Benjamin Drung modernize (U) python-ipmi (U) python-redmine Bernd Zeimetz flask-wtf (U) Brian May celery (U) django-nose (U) python-passlib (U) BW Keller yt (U) Carl Chenet python-memcache (U) Carlos Maddela rmlint Carsten Schoenert kicad (U) kopano-webapp (U) kopanocore (U) ChangZhuo Chen (陳昌倬) dodgy (U) prospector (U) python-requirements-detector (U) python-setoptconf (U) python-tabulate (U) voltron (U) Chris Boot nrpe-ng Chris Johnston python-flake8 (U) Chris Lamb django-assets (U) python-formencode (U) Christian Kastner imbalanced-learn (U) scikit-learn (U) tpot (U) Christian M. Amsüss rdflib (U) sparql-wrapper-python (U) Christopher Hoskin case (U) pytds (U) sphinx-celery (U) Clint Adams ledger-autosync (U) Clément Hermann onionshare (U) Colin Watson py-macaroon-bakery (U) python-libnacl (U) Colin Watson git-build-recipe Corey Bryant murano (U) Dain Nilsson python-yubico (U) Daniel Kahn Gillmor pdfminer (U) Daniele Tricoli pdfminer (U) Daniele Tricoli pywavelets (U) David Douard chaussette David Paleino python-nmap (U) uncertainties (U) David Villa Alises doublex David Watson python-anyjson (U) Debian Astro Team stsci.tools Debian Astronomy Maintainers galpy pytest-mpl Debian Astronomy Team yt Debian Authentication Maintainers python-yubico Debian Cloud Team python-boto Debian Electronics Team kicad Debian Emacsen team elpy Debian FreeIPA Team freeipa Debian FreeIPA Team python-jwcrypto Debian GIS Project pykdtree pyosmium python-descartes python-geopandas python-hdf4 python-mapnik python-osmapi python-stetl Debian Let's Encrypt Team pyrfc3339 (U) Debian Med Packaging Team ariba bcbio biomaj3 biomaj3-cli biomaj3-core biomaj3-daemon biomaj3-download biomaj3-process biomaj3-user brian circlator cwlformat cyvcf2 dipy falcon fastaq gfapy gubbins h5sparse insilicoseq
Bug#997793: RFS: libcxx-serial/1.2.1-5 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "libcxx-serial": * Package name: libcxx-serial Version : 1.2.1-5 Upstream Author : wjww...@gmail.com * URL : http://wjwwood.io/serial/ * License : Expat, BSD-3-clause * Vcs : https://gitlab.com/leamas/cxx-serial Section : libs It builds two binary packages: libcxx-serial-dev - Cross-platform, Serial Port library written in C++ (devel) libcxx-serial1 - Cross-platform, Serial Port library written in C++ (runtime) More info at: https://mentors.debian.net/package/libcxx-serial/ or using dget -x https://mentors.debian.net/debian/pool/main/libc/libcxx-serial/libcxx-serial_1.2.1-5.dsc Changes since the last upload: libcxx-serial (1.2.1-5) unstable; urgency=medium . * Handle uninstalled cmake configuration files. Closes: #997732 This is simple, bugfix release. Regards, -- Alec Leamas
Bug#997767: open-ath9k-htc-firmware: FTBFS: patching fails
The fix is currently waiting in the NEW queue. signature.asc Description: This is a digitally signed message part
Bug#997194: mtr: FTBFS: ../ui/curses.c:435:17: error: format not a string literal and no format arguments [-Werror=format-security]
On 10/24/21 4:36 AM, Rogier Wolff wrote: > > I think this is perfectly legal C code and your compiler doesn't like > it. It doesn't just warn, but gives an error. > > Roger. Rogier, that is a 100% true statement, but Debian (and most other distributions) have started using the -Werror=format-security build flag for everything everywhere because leaving all of these calls as-is means, in certain cases, leaving vulnerabilities in. Sure, you can prove that mtr's code introduces no such vulnerabilities because none of the format specs are user-supplied, but it's probably not reasonable to expect that that would be a one-time effort, whereas changing the code would be.
Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator
Seunghun Han writes: > * Package name: swtpm >Version : 0.7.0-rc2-1 Hi, The upstream version number should be 0.7.0~rc2 with a tilde instead of a hyphen to ensure proper ordering (as Lintian warns about). To do such transformations automatically, put something like this in the watch file: uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/ > swtpm - Libtpms-based TPM emulator > swtpm-dev - Include files for the TPM emulator's CUSE interface > swtpm-libs - Common libraries for TPM emulators Why do you deviate from the usual libswtpm-dev/libswtpm0 package names? Including the SO version in the package name enables installing incompatible versions side-by-side, which is useful. Also, shipping static libraries (like libswtpm_libtpms.a) is generally recommended against in Debian. Does this package warrant it? > swtpm-tools - Tools for the TPM emulator Why do you put swtpm-create-tpmca, swtpm-create-user-config-files and swtpm-localca into /usr/share/swtpm instead of /usr/bin? (This emits several Lintian information tags.) -- Thanks for you work! Regards, Feri
Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
Hello. I agree. I'm still waiting for fix and don't want to dump/drop/import data. JK On Sun, 24 Oct 2021 00:51:08 +0800 Marc Gallet wrote: > Am I to understand that the expected path forward with what is > supposed to be a minor update offered on oldstable is that everyone > shall dump their databases, delete the data folder, restore, then > upgrade??? > > Sure I can do that, not happy to, but I can.
Bug#997791: mpv: Playback from SMB shares no longer possible
Package: mpv Version: 0.33.1-1+b2 Severity: normal X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, The mpv (or possibly libav*) version provided in Debian was capable of playing directly from SMB shares in the past. This is no longer possible, instead I get error messages similar to this one: [ffmpeg] Protocol not found. Make sure ffmpeg/Libav is compiled with networking support. Failed to open smb://server/share/file.mkv I'm not sure when this stopped working, but it means I can no longer play media files on SMB shares directly from a file manager. I tried with both libavformat58 and libavformat-extra58, but neither worked. libsmbclient is installed. Please consider fixing this regression. Perhaps it's a dependency issue in mpv, caused by moving SMB support into libavformat-extra? Thanks. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mpv depends on: ii libarchive13 3.4.3-2+b1 ii libasound21.2.5.1-1 ii libass9 1:0.15.2-1 ii libavcodec58 7:4.4-6+b2 ii libavdevice58 7:4.4-6+b2 ii libavfilter7 7:4.4-6+b2 ii libavformat58 7:4.4-6+b2 ii libavutil56 7:4.4-6+b2 ii libbluray21:1.3.0-3 ii libc6 2.32-4 ii libcaca0 0.99.beta19-2.2 ii libcdio-cdda2 10.2+2.0.0-1+b2 ii libcdio-paranoia2 10.2+2.0.0-1+b2 ii libcdio19 2.1.0-2 ii libdrm2 2.4.107-8 ii libdvdnav46.1.1-1 ii libegl1 1.3.4-2+b1 ii libgbm1 20.3.5-1 ii libjack-jackd2-0 [libjack-0.125] 1.9.19~dfsg-2 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-22.12~rc1-2 ii liblua5.2-0 5.2.4-1.1+b3 ii libmujs1 1.1.3-2 ii libplacebo120 3.120.3-2 ii libpulse0 15.0+dfsg1-2 ii libsdl2-2.0-0 2.0.16+dfsg1-5 ii libsixel1 1.8.6-2 ii libswresample37:4.4-6+b2 ii libswscale5 7:4.4-6+b2 ii libuchardet0 0.0.7-1 ii libva-drm22.13.0-1 ii libva-wayland22.13.0-1 ii libva-x11-2 2.13.0-1 ii libva22.13.0-1 ii libvdpau1 1.4-3 ii libvulkan11.2.189.0-2 ii libwayland-client01.19.0-2+b1 ii libwayland-cursor01.19.0-2+b1 ii libwayland-egl1 1.19.0-2+b1 ii libx11-6 2:1.7.2-2+b1 ii libxext6 2:1.3.4-1 ii libxinerama1 2:1.1.4-2 ii libxkbcommon0 1.0.3-2 ii libxrandr22:1.5.2-1 ii libxss1 1:1.2.3-1 ii libxv12:1.0.11-1 ii libzimg2 3.0.3+ds1-1+b1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages mpv recommends: ii xdg-utils 1.1.3-4.1 ii youtube-dl 2021.06.06-1 mpv suggests no packages. -- no debconf information
Bug#997051: fakechroot: deadlock with jemalloc on arm64 and riscv64
On 2021-10-24 11:26, Aurelien Jarno wrote:
> On 2021-10-23 08:12, Johannes Schauer Marin Rodrigues wrote:
> > Package: fakechroot
> > Version: 2.20.1-1
> > Severity: normal
> > Control: affects -1 + jemalloc
> >
> > Hi,
> >
> > libjemalloc and fakechroot do not play well together on arm64 and
> > riscv64. Faidon managed to analyze the situation. It follows what they
> > found out:
> >
> > I got a backtrace (see below) by:
> > 1) attempting a normal build; killing it when it reaches t/jemalloc.t
> > 2) cd test; ./t/jemalloc.t
> > 3) gdb -p ($pidof cat)
> >
> > This is a deadlock, by malloc() being invoked in the code path for malloc().
> > Something tries to malloc(), jemalloc tries to initialize itself, which in
> > turn
> > means trying to open() /sys/kernel/mm/transparent_hugepage/enabled, but
> > open()
> > is LD_PRELOADed to fakechroot, which tries to initialize itself, which in
> > turn
> > tries to malloc memory.
> >
> > I'm not entirely sure why that happens yet, or why it only happens on
> > arm64. I
> > believe it is unrelated to the previous bug, #918742.
>
> The common point of arm64 and riscv64 (and a few new architectures) is
> that they lack the older syscalls that can be replaced by newer one. In
> that case they lack the open syscall, which can be replaced by openat.
>
> jemalloc tries to query /sys/kernel/mm/transparent_hugepage/enabled
> directly through a syscall if available, without going through glibc as
> can be seen in src/pages.c:562:
>
> | #if defined(JEMALLOC_USE_SYSCALL) && defined(SYS_open)
> | int fd = (int)syscall(SYS_open,
> | "/sys/kernel/mm/transparent_hugepage/enabled", O_RDONLY);
> | #else
> | int fd = open("/sys/kernel/mm/transparent_hugepage/enabled",
> O_RDONLY);
> | #endif
>
> I guess one fix or workaround would be to add support for the SYS_openat
> syscall as a fallback. Luckily this has already been done upstream:
>
> https://github.com/jemalloc/jemalloc/commit/6924f83cb21f75e1c892d8f469500e12f1a3f5a7#diff-e2003bd99a76acf15d071c2fd49cfaeefae69debe6fc304a86f104b662da986c
I have rebuilt jemalloc with this patch on riscv64. I confirm that it
fixes the testsuite of fakechroot.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Bug#997473: swupdate: FTBFS: dpkg-checkbuilddeps: error: Unmet build dependencies: latexmk:native
On 23.10.21 22:37, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): dpkg-buildpackage - Command: dpkg-buildpackage -us -uc -sa -rfakeroot dpkg-buildpackage: info: source package swupdate dpkg-buildpackage: info: source version 2021.04-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by SZ Lin (林上智) dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 dpkg-checkbuilddeps: error: Unmet build dependencies: latexmk:native dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) Build finished at 2021-10-23T06:31:56Z I have fixed the build in the git repo and uploaded a NMU to DELAYED/5. Debdiff is enclosed.diff -Nru swupdate-2021.04/debian/changelog swupdate-2021.04/debian/changelog --- swupdate-2021.04/debian/changelog 2021-09-15 16:44:59.0 +0200 +++ swupdate-2021.04/debian/changelog 2021-10-24 13:34:27.0 +0200 @@ -1,3 +1,12 @@ +swupdate (2021.04-1.1) unstable; urgency=medium + + * Non-maintainer upload + * Remove deprecated Salsa CI config + * latexmk without :native is alternative build dependency (Closes: #997473) + * Add tex-gyre build dependency + + -- Bastian Germann Sun, 24 Oct 2021 13:34:27 +0200 + swupdate (2021.04-1) unstable; urgency=medium [ Bastian Germann ] diff -Nru swupdate-2021.04/debian/control swupdate-2021.04/debian/control --- swupdate-2021.04/debian/control 2021-09-15 10:07:00.0 +0200 +++ swupdate-2021.04/debian/control 2021-10-24 13:34:27.0 +0200 @@ -8,7 +8,7 @@ dh-lua:native , liblua5.2-dev , libfdisk-dev, - latexmk:native , + latexmk | latexmk:native , libconfig-dev, libcurl4-openssl-dev, libarchive-dev, @@ -34,6 +34,7 @@ sphinx , texlive-latex-recommended , texlive-fonts-recommended , + tex-gyre , texlive-formats-extra Standards-Version: 4.6.0.1 Rules-Requires-Root: no diff -Nru swupdate-2021.04/debian/salsa-ci.yml swupdate-2021.04/debian/salsa-ci.yml --- swupdate-2021.04/debian/salsa-ci.yml2020-12-28 09:58:21.0 +0100 +++ swupdate-2021.04/debian/salsa-ci.yml1970-01-01 01:00:00.0 +0100 @@ -1,3 +0,0 @@ -include: - - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml - - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
Bug#997663: general: bullseye, system freezes completely when firefox freezes
Now that you mention it, often times it happened on battery power but I couldn't swear that it didn't on AC. Am Sonntag, dem 24.10.2021 um 09:13 -0300 schrieb Antonio Terceiro: > On Sun, Oct 24, 2021 at 12:25:23PM +0200, > jacobkoch...@gmail.com wrote: > > Hello Stephan, > > > > > Possibly relevant: > > > - Are you using X11 or Wayland? > > Wayland > > > > > - Do you have proprietary graphics drivers installed? > > $ lspci -v | grep -A 10 VGA > > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics > > 620 > > (rev 02) (prog-if 00 [VGA controller]) > > Subsystem: CLEVO/KAPOK Computer HD Graphics 620 > > [...] > > Kernel driver in use: i915 > > Kernel modules: i915 > > It seems to be the open source driver 'i915' in the package: > > 'xserver-xorg-video-intel'. > > > > > - Does the freeze occur without those? > > Does not apply. No proprietary graphics drivers installed. > > > > > - Can you SSH into the machine after the screen/input freezes > > Interesting idea. I will install 'openssh-server' and try this the > > next > > time. > > > > > - Do you have other indications that the machine is still > > > working? > > I'm not sure. Maybe I can try the keyboard backlight function? > > Or the Fn+Special-Function-Keys like: Volume or Display-Brightness > > ? > > Does this only happen when on battery power? > > There is https://gitlab.freedesktop.org/drm/intel/-/issues/3510 which > looks similar, and happens to me.
Bug#997788: node-react: FTBFS: Error: Command failed: npm pack build/node_modules/eslint-plugin-react-hooks
Source: node-react Version: 17.0.1+dfsg+~cs106.58.5-5 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20211023 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. The package probably tries to write stuff to $HOME during build. Relevant part (hopefully): > make[1]: Entering directory '/<>' > node scripts/rollup/build.js > BUILDING react.development.js (umd_dev) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > > The "treeshake.pureExternalModules" option is deprecated. The > "treeshake.moduleSideEffects" option should be used instead. > "treeshake.pureExternalModules: true" is equivalent to > "treeshake.moduleSideEffects: 'no-external'" > > COMPLETE react.development.js (umd_dev) > > BUILDING react.production.min.js (umd_prod) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > > The "treeshake.pureExternalModules" option is deprecated. The > "treeshake.moduleSideEffects" option should be used instead. > "treeshake.pureExternalModules: true" is equivalent to > "treeshake.moduleSideEffects: 'no-external'" > > COMPLETE react.production.min.js (umd_prod) > > BUILDING react.profiling.min.js (umd_profiling) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > > The "treeshake.pureExternalModules" option is deprecated. The > "treeshake.moduleSideEffects" option should be used instead. > "treeshake.pureExternalModules: true" is equivalent to > "treeshake.moduleSideEffects: 'no-external'" > > COMPLETE react.profiling.min.js (umd_profiling) > > BUILDING react.development.js (node_dev) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > > The "treeshake.pureExternalModules" option is deprecated. The > "treeshake.moduleSideEffects" option should be used instead. > "treeshake.pureExternalModules: true" is equivalent to > "treeshake.moduleSideEffects: 'no-external'" > > COMPLETE react.development.js (node_dev) > > BUILDING react.production.min.js (node_prod) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > > The "treeshake.pureExternalModules" option is deprecated. The > "treeshake.moduleSideEffects" option should be used instead. > "treeshake.pureExternalModules: true" is equivalent to > "treeshake.moduleSideEffects: 'no-external'" > > COMPLETE react.production.min.js (node_prod) > > BUILDING React-dev.js (fb_www_dev) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > > The "treeshake.pureExternalModules" option is deprecated. The > "treeshake.moduleSideEffects" option should be used instead. > "treeshake.pureExternalModules: true" is equivalent to > "treeshake.moduleSideEffects: 'no-external'" > > COMPLETE React-dev.js (fb_www_dev) > > BUILDING React-prod.js (fb_www_prod) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > > The "treeshake.pureExternalModules" option is deprecated. The > "treeshake.moduleSideEffects" option should be used instead. > "treeshake.pureExternalModules: true" is equivalent to > "treeshake.moduleSideEffects: 'no-external'" > > COMPLETE React-prod.js (fb_www_prod) > > BUILDING React-profiling.js (fb_www_profiling) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > > The "treeshake.pureExternalModules" option is deprecated. The > "treeshake.moduleSideEffects" option should be used instead. > "treeshake.pureExternalModules: true" is equivalent to > "treeshake.moduleSideEffects: 'no-external'" > > COMPLETE React-profiling.js (fb_www_profiling) > > BUILDING React-dev.js (rn_fb_dev) > babelHelpers: 'bundled' option was used by default. It is recommended to > configure this option explicitly, read more here: > https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers > >
Bug#997790: mdadm: Duplicate /dev/md/0 lines into /etc/mdadm/mdadm.conf at mdadm installation
Package: mdadm Version: 4.1-11 Severity: important Dear Maintainer, When installing mdadm (apt install mdadm) in presence of 2 already existing RAID arrays, the creation of /etc/mdadm/mdadm.conf goes wrong. Under the "# definitions of existing MD arrays" line, there are 2 lines for the 2 different arrays, but both are assigned to /dev/md/0 - and because of that, only the first array is automatically assembled at startup (the second one have to be assembled manually). # definitions of existing MD arrays ARRAY /dev/md/0 metadata=1.2 UUID=43c0447b:9c411b87:800d69f9:86dfe0d3 name=Pix-Server-Boutigny:0 ARRAY /dev/md/0 metadata=1.2 UUID=4042f02a:f1d2c565:91a6dacf:bb3ca761 name=VALEFORT:0 Changing to /dev/md0 and /dev/md1 for example, was able to solve the issue caused by this bug (after update-initramfs -u and reboot, both arrays are now assembled automatically). I have been able to check that I have the same issue on a second computer, in my example, having a 3 disks RAID 5 array, and another 3 disks RAID 0 array. But others kinds of RAID arrays are probably affected too. Hope this report will help, and also hope this bug will be easy to solve! Best regards, Julien ROBIN -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 mdadm depends on: ii debconf [debconf-2.0] 1.5.77 ii init-system-helpers1.60 ii libc6 2.31-13+deb11u2 ii libudev1 247.3-6 ii lsb-base 11.1.0 ii udev 247.3-6 Versions of packages mdadm recommends: ii kmod 28-1 ii msmtp-mta [mail-transport-agent] 1.8.11-2.1 Versions of packages mdadm suggests:
Bug#997787: gitbrute: FTBFS: go: go.mod file not found in current directory or any parent directory; see 'go help modules'
Source: gitbrute Version: 0~12-4 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20211023 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > dpkg-buildpackage > - > > Command: dpkg-buildpackage -us -uc -sa -rfakeroot > dpkg-buildpackage: info: source package gitbrute > dpkg-buildpackage: info: source version 0~12-4 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by Adam Borowski > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture amd64 > debian/rules clean > dh clean >dh_clean > dpkg-source -b . > dpkg-source: info: using source format '3.0 (quilt)' > dpkg-source: info: building gitbrute using existing > ./gitbrute_0~12.orig.tar.xz > dpkg-source: info: building gitbrute in gitbrute_0~12-4.debian.tar.xz > dpkg-source: info: building gitbrute in gitbrute_0~12-4.dsc > debian/rules binary > dh binary >dh_update_autotools_config >dh_autoreconf >debian/rules override_dh_auto_build > make[1]: Entering directory '/<>' > HOME="$(pwd)" go build -o gitbrute > go: go.mod file not found in current directory or any parent directory; see > 'go help modules' > make[1]: *** [debian/rules:8: override_dh_auto_build] Error 1 The full build log is available from: http://qa-logs.debian.net/2021/10/23/gitbrute_0~12-4_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with mine so that we can identify if something relevant changed in the meantime.
Bug#997785: python-sshoot: FTBFS: shellcheck error
Source: python-sshoot Version: 1.4.2-1 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20211023 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_auto_test > dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 > in use) > I: pybuild base:232: python3.9 setup.py test > running test > WARNING: Testing via this command is deprecated and will be removed in a > future version. Users looking for a generic test entry point independent of > test runner are encouraged to use tox. > running egg_info > writing sshoot.egg-info/PKG-INFO > writing dependency_links to sshoot.egg-info/dependency_links.txt > writing entry points to sshoot.egg-info/entry_points.txt > writing requirements to sshoot.egg-info/requires.txt > writing top-level names to sshoot.egg-info/top_level.txt > reading manifest file 'sshoot.egg-info/SOURCES.txt' > reading manifest template 'MANIFEST.in' > adding license file 'LICENSE.txt' > writing manifest file 'sshoot.egg-info/SOURCES.txt' > running build_ext > > -- > Ran 0 tests in 0.000s > > OK > shellcheck --shell bash -e SC2128,SC2181,SC2207 \ > debian/bash-completion > > In debian/bash-completion line 10: > local tmpfile="$(mktemp)" > ^-^ SC2155: Declare and assign separately to avoid masking > return values. > > For more information: > https://www.shellcheck.net/wiki/SC2155 -- Declare and assign separately to > ... > make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1 The full build log is available from: http://qa-logs.debian.net/2021/10/23/python-sshoot_1.4.2-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with mine so that we can identify if something relevant changed in the meantime.
