Bug#970669: EasyRSA script - 'set -o echo' causes error
Package: easy-rsa Version: 3.0.6-1 Oops the package name has a dash... :( On 21/9/20 15:36, Jeremy Davis wrote: > Package: easyrsa > Version: 3.0.6-1 > > [...] signature.asc Description: OpenPGP digital signature
Bug#970668: EasyRSA script - 'set -o echo' causes error
Package: easyrsa Version: 3.0.6-1 Under some circumstance easyrsa throws an error regarding 'set -o echo'. This has been reported upstream[1] and subsequently fixed[2]. As per Debian policy, I'm sure that the PR noted would double as a patch to fix this bug in buster. The bug has been resolved in 3.0.7[3] but (at the time of writing) the latest release is 3.0.8 so upgrading is probably the best fix for sid/bullseye?! Regards, Jeremy Davis [1] https://github.com/OpenVPN/easy-rsa/issues/308 [2] https://github.com/OpenVPN/easy-rsa/pull/315 [3] https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.7 signature.asc Description: OpenPGP digital signature
Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base
Hi Tiago, hi Julian, On Fri, Sep 18, 2020 at 01:13:55PM -0300, Tiago Daitx wrote: > Hi Tony, > > Matthias is the actual Debian Maintainer, but in my opinion the patch > is great and should be ok to go do an upload including it. Yes, that's a good point. Once the upload is ready (see below), I will upload it as an NMU to the delayed queue if we haven't heard back from Matthias. > > > On Thu, Sep 17, 2020 at 06:45:39PM +0100, Julian Gilbey wrote: > > > > affects 944738 openjdk-14-jdk > > > > thanks > > > > > > > > The same problem is still present in openjdk-14 - see > > > > https://bugs.debian.org/968991 > > > > > > I have located the source of the bug and have a patch to fix it. > > > > > > The cause is the use of dh_strip_nondeterminism late in the build > > > process. This reorganises the jmod files, which in turn changes their > > > SHA256 checksums. This would not be a problem, except that the > > > checksums are saved in java.base.jmod *before* the use of > > > dh_strip_nondeterminism. Performing this stripping immediately after > > > each jmod file is created results in the checksums being consistent > > > throughout. Julian, I applied the patch and built the package successfully, but jlink still fails with the "expected hash" error. It's (perhaps) interesting that the expected hash does differ between the patched build and the unpatched build. Disabling the invocation of 'dh_strip_nondeterminism -a' in debian/rules *does* address the problem with jlink, either with or without the jmod patch applied. Also, I had to add strip-determinism to the build-deps to build with the patch. Given that the package doesn't build reproducibly anyway, my inclination is to make the change in debian/rules to address this long-standing bug. Thanks, tony signature.asc Description: PGP signature
Bug#927996: closed by Tobias Frost (Re: RFS: diskfit/2.0.2.3 [ITP] -- Simple disk fit calculator)
On Sun, Sep 20, 2020 at 11:24 AM Heiko Schäfer wrote: > I would have to sponsor something, but if over 1.5 years later nobody wants to > sponsor it, I must accept that this tool seems to be an piece of utter > bullshit. The availability of a sponsor for software needing a sponsor is not correlated with the quality of the software needing a sponsor. There is some advice on the wiki that might help finding a sponsor: https://wiki.debian.org/DebianMentorsFaq#Sponsored_Packages -- bye, pabs https://wiki.debian.org/PaulWise
Bug#961511: [PATCH] d/xen-utils-common.xen.init: disable oom killer for xenstored
This is fun. Actually isn't too difficult to trigger, simply slowly reduce the memory Xen allocates to Dom0 and eventually the oom-killer is likely to trigger (having tried to shrink Dom0 as far as possible, believe me, I know). I had been wondering which of the Xen daemons could be safely restarted since it is handy to restart daemons instead of whole machine for security updates... Interestingly running `xenstored --help` mentions: -I, --internal-db store database in memory, not on disk There is a run/xenstored/tdb file so I end up wondering if newer versions are in fact storing everything in a file and restarting isn't so bad. The patch switches the arguments from: --exec "$try_xenstored" -- ... to: --exec /usr/bin/choom -- -n -1000 "$try_xenstored" -- ... I'm pretty sure start-stop-daemon is consuming the "--" and the second "--" shouldn't be there. -- (\___(\___(\__ --=> 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#866974: [Aptitude-devel] Bug#866974: Patch fixing 'Assertion "resman->resolver_exists()" failed.'
Hi Ahzo, Ahzo wrote: > # aptitude # select 'test-b' for installation, press g > Uncaught exception: ../../src/ui.cc:1549: void auto_fix_broken(): Assertion > "resman->resolver_exists()" failed. Bingo! There it is. Thanks again! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#945511: seabios: Structure Table Address is Correct
Package: seabios Followup-For: Bug #945511 Dear Maintainer, The encoded address is correct, even in the dump I uploaded. I made a mistake in reading it which somehow made it into my program as well. --Giancarlo -- System Information: Debian Release: 9.13 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-12-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#866974: [Aptitude-devel] Bug#866974: Patch fixing 'Assertion "resman->resolver_exists()" failed.'
Hi Axel, thanks for your quick and positive reply. Indeed, for some reason the upgrade works in the TUI. To reproduce the assertion failure in the TUI one can try to install test-b after having installed test-a version 2. That corresponds to the last four steps: # # Reproduce problem with TUI: # apt full-upgrade # sed -i 's/repo2/repo1/' /etc/apt/sources.list # apt update # aptitude # select 'test-b' for installation, press g Uncaught exception: ../../src/ui.cc:1549: void auto_fix_broken(): Assertion "resman->resolver_exists()" failed. The equivalent CLI operation looks like: # aptitude install test-b The following NEW packages will be installed: test-b 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/2164 B of archives. After unpacking 9216 B will be used. The following packages have unmet dependencies: test-a : Breaks: test-provide (< 2) which is a virtual package, provided by: - test-b (1), but 1 is to be installed *** ERROR: search aborted by fatal exception. You may continue searching, but some solutions will be unreachable. I want to resolve dependencies, but no dependency resolver was created.The following NEW packages will be installed: test-b 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/2164 B of archives. After unpacking 9216 B will be used. aptitude failed to find a solution to these dependencies. You can solve them yourself by hand or type 'n' to quit. The following packages have unmet dependencies: test-a : Breaks: test-provide (< 2) which is a virtual package, provided by: - test-b (1), but 1 is to be installed Resolve these dependencies by hand? [N/+/-/_/:/?] Regards, Ahzo
Bug#970661: RFS: htmldoc/1.9.10-1 [ITA] -- HTML processor that generates indexed HTML, PS, and PDF
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "htmldoc": * Package name: htmldoc Version : 1.9.10-1 Upstream Author : Michael R Sweet * URL : https://www.msweet.org/htmldoc/ * License : BSD-2-Clause, GPL-2 with document exception, Apache-2.0 with (L)GPL-2 exception, GPL-2, PNG, IJG, bitstream, MIT-CMU, zlib Section : web It builds those binary packages: htmldoc-common - Common arch-independent files for htmldoc htmldoc - HTML processor that generates indexed HTML, PS, and PDF To access further information about this package, please visit the following URL: https://mentors.debian.net/package/htmldoc/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/htmldoc/htmldoc_1.9.10-1.dsc Changes since the last upload: htmldoc (1.9.10-1) unstable; urgency=medium . * New upstream release. * New maintainer Closes: #854222 * d/upstream/metadata: Update Bug-Submit * d/patches - Append .patch to the remaining patches - Add include_desktop_icons.patch * d/copyright - Update years - Include myself under debian/* - Update copyright notice for png/* Regards, Håvard
Bug#970667: bpython: Documentation not shipped
Package: bpython Version: 0.19-1 Severity: normal X-Debbugs-Cc: calumlikesapple...@gmail.com Bpython includes detailed sphinx documentation, but that doesnt appear to be being shipped along with the package. I often work offline, and would appreciate having access to the documentaion files when offline. If you could ship them, either in the package itself or as a bpython-doc package, that would be much appreciated. I can attempt this if needed, but I am not a debian maintainer, and have never made a package before. Thanks! Calum -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bpython depends on: ii less 551-2 ii python33.8.2-3 ii python3-curtsies 0.3.4-1 ii python3-greenlet 0.4.15-4.2 ii python3-pkg-resources 46.1.3-1 ii python3-pygments 2.3.1+dfsg-4 ii python3-requests 2.23.0+dfsg-2 ii python3-six1.15.0-1 Versions of packages bpython recommends: ii python3-watchdog 0.9.0-3 Versions of packages bpython suggests: ii python3-jedi 0.17.0-1 -- no debconf information
Bug#970666: kcemu: Fresh installed package. Kcemu doesn't start.
Package: kcemu Version: 0.5.1+git20141014+dfsg-2+b1 Severity: important X-Debbugs-Cc: maximilian.grossm...@studium.fernuni-hagen.de Dear Maintainer, just have a fresh install of kcemu from debian repositories. Kcemu doesn't start. Error Output: "can't open file '/usr/share/kcemu/roms/kc85/'" Installed the rom-files from sourceforge Package KCemu-0.5.1.tar.gz into the Directory /usr/share/kcemu/roms Still the same Error, although the Directory /usr/share/kcemu/roms/kc85 is there with all the roms inside. when giving a path using the -d option: $ kcemu -d ** (kcemu:2547): ERROR **: 23:13:31:951: widget with name 'dialog_button_ok' not found! Trace/breakpoint trap when using any directory as , only the /usr/share/kcemu directory leads again to the first "can't open file" Error. I have no clue how to solve that problem. The file is there and it is an directory as it is shipped within the original sourceforge kcemu source package. Greets -maX-> -- System Information: Distributor ID: Kali Description:Kali GNU/Linux Rolling Release:2020.3 Codename: kali-rolling Architecture: i686 Kernel: Linux 5.7.0-kali3-686 (SMP w/2 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kcemu depends on: ii kcemu-common 0.5.1+git20141014+dfsg-2 ii libc62.31-2 ii libcairo21.16.0-4 ii libgcc-s1 [libgcc1] 10.2.0-5 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.64.4-1 ii libgtk2.0-0 2.24.32-4 ii libogg0 1.3.2-1+b1 ii libpango-1.0-0 1.46.1-1 ii libpangocairo-1.0-0 1.46.1-1 ii libpangoft2-1.0-01.46.1-1 ii libsndfile1 1.0.28-8 ii libstdc++6 10.2.0-5 ii libtheora0 1.1.1+dfsg.1-15 ii libvncclient10.9.13+dfsg-1 ii libvncserver10.9.13+dfsg-1 ii libvorbis0a 1.3.6-2 ii libvorbisfile3 1.3.6-2 ii libx11-6 2:1.6.10-3 ii libxmu6 2:1.1.2-2+b3 ii libxt6 1:1.2.0-1 ii libz80ex11.1.21-1+b1 ii zlib1g 1:1.2.11.dfsg-2 kcemu recommends no packages. kcemu suggests no packages. -- no debconf information
Bug#883194: please convert mountstats and nfsiostat scripts to Python3
Hello, recently Debian removed the binary package "python" from sid and testing, thus breaking the Recommends: for nfs-common. The affected scripts should be converted to Python 3 and the Recommend: field should be updated accordingly. Regards, Gabriele Stilli
Bug#966922: (No Subject)
Hi Scott, While resolving this bug, would you by the way bump libnitrokey to version 3.6? Szczepan released it this week. This new version introduces native support for LibremKey.
Bug#970665: Doesn't save any preferences (not even within the session)
Package: remmina Version: 1.4.8+dfsg-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I tried to enable the font smoothing capabilities via Preferences > RDP tab > Quality settings. I can choose it. But when I press the Close button there is an error shown on the command line and the setting is not being activated. This happens for all available configuration options. I also started remmina as root just to make sure I have rights to write to all locations and got the same result. The error on the command line is: (org.remmina.Remmina:158362): Gtk-CRITICAL **: 00:53:58.023: gtk_switch_get_active: assertion 'GTK_IS_SWITCH (sw)' failed This is a major limitation and should be fixed asap. Remmina cannot be configured at the moment. Regards, Daniel - -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages remmina depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-1 ii dbus-x11 [dbus-session-bus] 1.12.20-1 ii libavahi-client3 0.8-3 ii libavahi-common3 0.8-3 ii libavahi-ui-gtk3-00.8-3 ii libayatana-appindicator3-10.5.5-2 ii libc6 2.31-3 ii libcairo2 1.16.0-4 ii libgcrypt20 1.8.6-2 ii libglib2.0-0 2.66.0-2 ii libgtk-3-03.24.23-1 ii libjson-glib-1.0-01.6.0-1 ii libpango-1.0-01.46.1-1 ii libsodium23 1.0.18-1 ii libsoup2.4-1 2.70.0-1 ii libssh-4 0.9.4-1 ii libssl1.1 1.1.1g-1 ii libvte-2.91-0 0.62.0-1 ii remmina-common1.4.8+dfsg-1 Versions of packages remmina recommends: ii remmina-plugin-rdp 1.4.8+dfsg-1 pn remmina-plugin-secret pn remmina-plugin-vnc Versions of packages remmina suggests: pn remmina-plugin-exec pn remmina-plugin-kwallet pn remmina-plugin-nx pn remmina-plugin-spice pn remmina-plugin-www pn remmina-plugin-xdmcp - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl9n3gcACgkQS80FZ8KW 0F2R3g/6AqfljH/pWddSQ9mkBe3eEh0fB4lgZkzY1d2PGvOlYRbyFtjqnw0PJERj 8LmGh15u/s1Z5W47hPhBrNiT8b/RyeyG5Nvl1G/k2J5Sq3EXK8bI2T1RJ3wluK8H cYs8Vpj5ut7aM1WSk1WdL6mwNXJjkEE+0T5UeQoJLRZb/IOg6qL2vpndzbwG7CSu JRQQ0M3gS8KD921D+Q7PSvxB5xb0TZFzuyY3qF7loF0dvkYb2i+pR+syX3Z9hmrk O8rESHK+8A8edgrCoV4wiE3KN2yetJJbyJrNoBWt8NAIgZkwr5z2azMPRD81VV7N Nii9g9l25SOYv4QCZTGB7OhMpN/3wMWsds+6RmHeN262IoJkXElcVc6Xne0W9rTL 7zGtDQW+7OrARBamEOczA+Y4BvvUiSnjbt8PIHTUpYYpE4N3BEDGb8JEbX8IbDeA aNgELrA2X4lvFPvlns3Svmxp09J/cOzZFNpcdgPtbwxel++xnb9RAevantJW4YWy fvu2kWojjVI9fij51cpRKYiGKQG8gdX7U61jKON6LdgiH6t4vPXbfpfvSWZwStCt hKgpxRMXnUjWZW7xyij6Fk1NBbeB8GrDcHzRGQazQxpv09yIA77c3WnHIox0y2e9 xoVGHC3eFtk3EMyxGQCQis3rwYcyYCUXnECK0/+13y7L8M8MD5Q= =L1JV -END PGP SIGNATURE-
Bug#970635: moosic: not Python-3-compatible, so due for removal
I've done some more digging, and it looks like the delay isn't related to the new version, or to moosic at all. It happens only with WAV files played by sox; my best guess is that it's a matter of how sox handles things internally, such that when it gets SIGSTOP or suchlike it (I imagine) lets a buffer run empty before fully stopping. While investigating that, I also ran into two intermittent problems with the unpause command (and various related commands): one that occurs only with ogg123, and one that so far occurs only with MPlayer (which isn't used in the default moosic config). The latter isn't strictly moosic's problem, and I don't see anything moosic can do about it; the former isn't either, but moosic can avoid it by changing the way it handles sending SIGCONT when the target process is ogg123, so I've added a patch that does that. I haven't provided it here, since it's not related to the Python 3 transition, but it can follow later separately if appropriate. At least the MPlayer-related problem has been confirmed, with testing, to also occur with the existing 1.5.6 Python 2 version of moosic. From my understanding of the other two problems, I fully expect them to occur there as well. As best I can determine, none of them are new issues. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970471: [pkg-crosswire-devel] Bug#970471: Bug#970471: Possible ways to resolve
On Sun, Sep 20, 2020 at 07:57:59PM +0200, Bastian Germann wrote: > Am 20.09.20 um 12:35 schrieb Teus Benschop: > > The error message in this bug report is an unusual one. > > > > I managed to find one other similar report on Google, which was in Chinese. > > > > Possible solutions I could think of are these two. > > > > 1. If the error is temporary, to upload a new package that would trigger a > > rebuild. > > > > 2. To ask the FTP Masters to remove the previously build for this > > architecture, so the remaining architectures can move to testing. > > > Upstream provided a patch that I applied on salsa. Would someone please > upload the new version? > Hi Bastian, Thanks so much for taking the time to address this bug and to prepare the updated package. I have uploaded the 3.0-2 package. Note that I deleted your debian/3.0-2 tag, created a new tag signed with my GPG key, and then force pushed it. As a practice, I think we should stick to whoever upload also pushes the tag and that the tag should be signed as well. Regards, -Roberto -- Roberto C. Sánchez
Bug#970664: libvte-2.91-0: Terminal not displaying correctly
Package: libvte-2.91-0 Version: 0.62.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, After an upgrade of libvte gnome-terminal and other software using the library (gedit terminal plugin) doesn't work. Where the console should be there is some transparency and a effect similar to when you record a screen that shows what the camera sees (feedback). Reverting to 0.60.3-1 of libvte and gnome-terminal 3.36.2-3 fixes the issue. Regards. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8), LANGUAGE=es_CL:es Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvte-2.91-0 depends on: ii libatk1.0-0 2.36.0-2 ii libc62.31-3 ii libcairo21.16.0-4 ii libfribidi0 1.0.8-2 ii libgcc-s110.2.0-7 ii libglib2.0-0 2.66.0-2 ii libgnutls30 3.6.15-4 ii libgtk-3-0 3.24.23-1 ii libicu67 67.1-4 ii libpango-1.0-0 1.46.1-1 ii libpangocairo-1.0-0 1.46.1-1 ii libpcre2-8-0 10.34-7 ii libstdc++6 10.2.0-7 ii libsystemd0 246.5-1 ii libvte-2.91-common 0.62.0-1 ii zlib1g 1:1.2.11.dfsg-2 libvte-2.91-0 recommends no packages. libvte-2.91-0 suggests no packages. -- no debconf information
Bug#970662: mariadb-105: FTBFS on x32: operand size mismatch for `crc32'
Source: mariadb-10.5 Version: 1:10.5.5-1~exp1 Severity: serious Justification: fails to build from source User: debian-...@lists.debian.org Usertags: x32 After uploading the latest mariadb-10.5 I noticed it fails to build. However, mariadb-10.4 built just fine on x32. The failure is: [ 48%] Building CXX object storage/innobase/CMakeFiles/innobase_embedded.dir/ut/ut0crc32.cc.o cd /<>/builddir/storage/innobase && /usr/bin/x86_64-linux-gnux32-g++ -DBTR_CUR_ADAPT -DBTR_CUR_HASH_ADAPT -DCOMPILER_HINTS -DDBUG_TRACE -DEMBEDDED_LIBRARY -DHAVE_C99_INITIALIZERS -DHAVE_CONFIG_H -DHAVE_FALLOC_PUNCH_HOLE_AND_KEEP_SIZE=1 -DHAVE_IB_LINUX_FUTEX=1 -DHAVE_LZ4=1 -DHAVE_LZ4_COMPRESS_DEFAULT=1 -DHAVE_NANOSLEEP=1 -DHAVE_SCHED_GETCPU=1 -DHAVE_SNAPPY=1 -DLINUX_NATIVE_AIO=1 -DMUTEX_EVENT -DWITH_INNODB_DISALLOW_WRITES -D_FILE_OFFSET_BITS=64 -I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 -I/<>/builddir/include -I/<>/storage/innobase/include -I/<>/storage/innobase/handler -I/<>/libbinlogevents/include -I/<>/tpool -I/<>/include -I/<>/sql -I/<>/builddir/extra/wolfssl -I/<>/extra/wolfssl/wolfssl -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2 -fdebug-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -Wconversion -Wno-sign-conversion -O2 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -Wdate-time -D_FORTIFY_SOURCE=2 -DUNIV_LINUX -D_GNU_SOURCE=1 -DHAVE_OPENSSL -DHAVE_WOLFSSL -DWOLFSSL_USER_SETTINGS -fPIC -fvisibility=hidden -std=gnu++11 -o CMakeFiles/innobase_embedded.dir/ut/ut0crc32.cc.o -c /<>/storage/innobase/ut/ut0crc32.cc /<>/storage/innobase/ut/ut0crc32.cc: Assembler messages: /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' /<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand size mismatch for `crc32' make[4]: *** [storage/innobase/CMakeFiles/innobase_embedded.dir/build.make:1499: storage/innobase/CMakeFiles/innobase_embedded.dir/ut/ut0crc32.cc.o] Error 1 make[4]: Leaving directory '/<>/builddir' make[3]: *** [CMakeFiles/Makefile2:5499: storage/innobase/CMakeFiles/innobase_embedded.dir/all] Error 2 make[3]: *** Waiting for unfinished jobs
Bug#970663: mariadb-105: FTBFS on ppc64: InnoDB: Trying to delete tablespace 'test/bug21114_child' but there are 1 flushes and 0 pending i/o's on it
Source: mariadb-10.3 Version: 1:10.5.5-1~exp1 Severity: serious Justification: fails to build from source User: debian-powe...@lists.debian.org Usertags: ppc64 After uploading the latest mariadb-10.5 I noticed it fails to build. However, mariadb-10.4 built just fine on ppc64. The failure is this test that fails: main.parser_bug21114_innodb 'innodb' w5 [ fail ] Found warnings/errors in server log file! Test ended at 2020-09-12 17:31:51 line 2020-09-12 17:31:19 8 [Warning] InnoDB: Trying to delete tablespace 'test/bug21114_child' but there are 1 flushes and 0 pending i/o's on it. ^ Found warnings in /<>/builddir/mysql-test/var/5/log/mysqld.1.err ok
Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc
Quoting Pirate Praveen (2020-09-20 22:08:24) > > > On 2020, സെപ്റ്റംബർ 21 12:38:37 AM IST, Xavier Guimard > wrote: > >Package: rollup > >Version: 1.12.0-2 > >Severity: serious > >Tags: ftbfs > >Justification: Policy 7.7.7 > > > >node-rollup 1.12.0 can't be build with current typescript (4.0.2). It > >requires tsc 3.4.5 (tested with success). Output: > > I think the root cause is uploading major versions without > coordination. It should have been easily found out if all packages > using typescript was rebuilt before it was uploaded to unstable. I agree with the above. > I think we should create a release team within js team to handle it > like how release team works for transitions. What do you mean more concretely? That only a smaller elite group should (approve) upload to unstable, and everyone else should upload only to experimental, or...? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#968893: Acknowledgement (mariadb-10.3: FTBFS on alpha: relocation truncated to fit)
Interestingly alpha built just fine on mariadb-10.5: https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=alpha=1%3A10.5.5-1%7Eexp1=1600077822=0
Bug#967125: desmume: Unversioned Python removal in sid/bullseye
On Sun, 20 Sep 2020 23:51:22 +0200 Markus Koschany wrote: > > I believe this issue was fixed in libglade2-dev (#967157) and > monster-masher ^ should be desmume of course :-) signature.asc Description: OpenPGP digital signature
Bug#933151: mariadb-10.3: FTBFS on riscv64
Package: mariadb-10.5 Version: 1:10.5.5-1~exp1 The riscv64 builds on Debian build are still failing for latest mariadb-105: https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=riscv64=1%3A10.5.5-1%7Eexp1=1599937965=0 [ 62%] Building CXX object storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_operation.cpp.o cd /<>/builddir/storage/mroonga && /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DHAVE_CONFIG_H -DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED -DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1 -D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS -I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 -I/<>/builddir/include -I/<>/builddir/storage/mroonga -I/<>/storage/mroonga -I/<>/storage/mroonga/lib -I/<>/include -I/<>/sql -I/<>/regex -I/<> -I/<>/storage/mroonga/vendor/groonga/include -I/<>/builddir/extra/wolfssl -I/<>/extra/wolfssl/wolfssl -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -o CMakeFiles/mroonga.dir/lib/mrn_operation.cpp.o -c /<>/storage/mroonga/lib/mrn_operation.cpp /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `rocksdb::ConcurrentArena::ApproximateMemoryUsage() const': ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/memory/concurrent_arena.h:67: undefined reference to `__atomic_compare_exchange_1' /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `std::__atomic_base::compare_exchange_weak(bool&, bool, std::memory_order, std::memory_order)': /usr/include/c++/10/bits/atomic_base.h:464: undefined reference to `__atomic_compare_exchange_1' /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined reference to `__atomic_compare_exchange_1' /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined reference to `__atomic_compare_exchange_1' /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined reference to `__atomic_compare_exchange_1' /usr/bin/ld: librocksdblib.a(memtable.cc.o):/usr/include/c++/10/bits/atomic_base.h:464: more undefined references to `__atomic_compare_exchange_1' follow [ 62%] Building CXX object storage/perfschema/CMakeFiles/perfschema_embedded.dir/pfs_engine_table.cc.o cd /<>/builddir/storage/perfschema && /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DEMBEDDED_LIBRARY -DHAVE_CONFIG_H -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64 -I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 -I/<>/builddir/include -I/<> -I/<>/include -I/<>/sql -I/<>/builddir/sql -I/<>/builddir/storage/perfschema -I/<>/builddir/extra/wolfssl -I/<>/extra/wolfssl/wolfssl -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_OPENSSL -DHAVE_WOLFSSL -DWOLFSSL_USER_SETTINGS -fPIC -fvisibility=hidden -std=gnu++11 -o CMakeFiles/perfschema_embedded.dir/pfs_engine_table.cc.o -c /<>/storage/perfschema/pfs_engine_table.cc [ 62%] Building CXX object storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_database.cpp.o cd /<>/builddir/storage/mroonga && /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DHAVE_CONFIG_H -DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED -DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1 -D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS -I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 -I/<>/builddir/include -I/<>/builddir/storage/mroonga -I/<>/storage/mroonga -I/<>/storage/mroonga/lib -I/<>/include -I/<>/sql -I/<>/regex -I/<> -I/<>/storage/mroonga/vendor/groonga/include -I/<>/builddir/extra/wolfssl -I/<>/extra/wolfssl/wolfssl -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC -Wdate-time -D_FORTIFY_SOURCE=2
Bug#968914: Acknowledgement (mariadb-10.3: FTBFS on ia64: test main.func_regexp_pcre crashes server)
Seems mariadbc-10.5 built just fine on ia64: https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=ia64=1%3A10.5.5-1%7Eexp1=1599939666=0
Bug#968891: Acknowledgement (mariadb-10.4: FTBFS on sh4: Performing Test have_C__Wdeclaration_after_statement - Failed)
Interestingly mariadb-10.5 built just fine on sh4 in https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=sh4=1%3A10.5.5-1%7Eexp1=152010=0
Bug#968915: Acknowledgement (mariadb-10.4: FTBFS on hppa: test main.long_unique lost connection to server)
Package: mariadb-10.5 Version: 1:10.5.5-1~exp1 This most likely also apply for mariadb-10.5. However the mariadb-10.5 fails to build at all: https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=hppa=1%3A10.5.5-1%7Eexp1=1599943062=0
Bug#905456: Please create new list debian-clojure
On Thu, Sep 10, 2020 at 09:52:40PM +0200, Alexander Wirt wrote: > > Sorry for joining late. Could you please upgrade the list of subscribers > and provide me with the archive of the old alioth list? No problem. I'm attaching another encrypted dump of the subscriber list. The archives are publicly available at https://alioth-lists.debian.net/pipermail/pkg-clojure-maintainers/ I'd just be downloading and attaching the gzips from the link above so hopefully this is enough... unfortunately as with most public mailing lists the archives are full of spam, not sure if there's any easy way to clean that. - e -BEGIN PGP MESSAGE- hQIMAyw6FZGd0OwpAQ/+Ittoq9B2JgkGZcf717+d+zcoAqXQukFL+ycfLSe40pnR 6Kx+thGOZ0rfR9fNBSTNn4hfYhvbQrA9AOtqmyfssD4bU1oHblaq1Mdtw2214qsq LVPHi9FRecFhesmXABOG4ogpwYB6Na9r5UzRGaqEixVskhkCc67vD7czifPLxUzt fvFVOeN1BgAPsizi7tYkG8iZhThdoS/9cvTvkEa2SJXF6o0DVA0JGHvX9aG2TBSs wrTt4G3Gh9HmKd9OnCsO82hcWoffhXaDtzZIlJXJdXxH/e4fkt4o7/YfIGz324Bi Ei0VTpHoeiCJQ0iUZzOJ2OOmd/h96NZRb2umY+8gPehtxmylytv4Ag86cr7AqBba 25GLqo+rm37WybLuV22o6fdW9GZKHJCJHtGMw02vban0oWjkJh4AU0pyK/he6knH e5a0QCkh5JFewtfH0VPrt7aPX1RXy1hwMSeZPi6RqjCqI/4YBPJrJ88fVkNaPsSm U9fsy6zzpxrC2TkUoGAW6JnJrTJfBz9K/KWy4zu3pLkGkQh1rcb5WYusPPaS6+Pq 4duUOcMgKDGRX/zoXNqK9XAHdJfgLtJTFYyFs+1yNKqkQX8TDWGid+1wQDMByVmP CBFeqCGIXN2fdAPeQ1cp9BfDpQH2f3588+y4VY9zTLifC35n+5j5BHYqmeV5DTbS wDgBqA9Ol+CFoTkTvHFq3zKmQHSrWfddLPQJGOXQ/Cnm61Yh71xMLBbrNpcv4LMl rBm6UibHPASamHrmWPPBrkVHscL/XRMaOkfHvKcGiDzlUfhKgabKx5beWDzxVdMk MPw3V9DLaEoHqaQtVW7oVImHVviOKg5d1jk4kxrVxHeANwNZfEAppuCwB2cPeVDc 9eWUNJ8detQLaLnJ61ymhq47agVNL6hPIQzV8qxwdCL8wPsNi6IQ4cCKG+sglCyo w2aSozA4cqmUoBLNj+i2lhBifoEJlKbgEGumVoElk5Xv4XZDcN7Qq3kji5GPCzPL JVfg+y60nXMvoA== =Qjk2 -END PGP MESSAGE- signature.asc Description: PGP signature
Bug#970584: inetutils 1.9.4-7+deb10u1 flagged for acceptance
package release.debian.org tags 970584 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: inetutils Version: 1.9.4-7+deb10u1 Explanation: fix remote code execution issue [CVE-2020-10188]
Bug#970583: chocolate-doom 3.0.0-4+deb10u1 flagged for acceptance
package release.debian.org tags 970583 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: chocolate-doom Version: 3.0.0-4+deb10u1 Explanation: fix missing validation [CVE-2020-14983]
Bug#970660: ghdl: Please migrate to gnat-10
Package: ghdl Severity: wishlist X-Debbugs-Cc: Ludovic Brenta Hello! As discussed on the debian-ada mailing list[1], we are migrating all packages containing Ada sources to gnat-10. It is likely that gnat-9 will be removed from Debian before the freeze (and the severity of this bug will then increase). Therefore, please update ghdl to build with gnat-10 and gcc-10-source. I have checked that the simple patch below results in a successful build: [1] https://lists.debian.org/debian-ada/2020/09/msg0.html diff --git a/debian/control b/debian/control index ea850c26..9e6082ee 100644 --- a/debian/control +++ b/debian/control @@ -4,8 +4,8 @@ Priority: optional Maintainer: Debian Electronics Team Uploaders: Andreas Bombe Build-Depends: debhelper (>= 11), - gnat-9, - gcc-9-source , + gnat-10, + gcc-10-source , libisl-dev (>= 0.14) , libmpc-dev (>= 1.0) , libmpfr-dev (>= 3.0.0-9~) , diff --git a/debian/rules b/debian/rules index 81ad8ac5..ad67d6b3 100755 --- a/debian/rules +++ b/debian/rules @@ -6,17 +6,17 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-format #export DH_VERBOSE = 1 +# These variables are used to find and unpack the gcc source +GCC_VER := 10 +GCC_DIR := /usr/src/gcc-$(GCC_VER) +GCC_TARBALL := $(notdir $(wildcard $(GCC_DIR)/gcc-*.tar.*)) + include /usr/share/dpkg/default.mk -include /usr/share/ada/debian_packaging-9.mk +include /usr/share/ada/debian_packaging-$(GCC_VER).mk # This variable is used in Makefile.in to adjust src/version.in export PKG_VERSION := $(DEB_VENDOR) $(DEB_VERSION) -# These variables are used to find and unpack the gcc source -GCC_DIR := /usr/src/gcc-9 -GCC_VER := 9 -GCC_TARBALL := $(notdir $(wildcard $(GCC_DIR)/gcc-*.tar.*)) - # Get parallel option to parallelize the gcc build specifically (Ada builds # are already parallelized by code included from debian_packaging-*.mk above). ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) -- Ludovic Brenta.
Bug#970659: nspr: FTBFS on hurd-i386
Source: nspr Version: 4.28-1 Severity: Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Currently libdrm FTBFS GNU/Hurd due to a parenthesis bug in ptsync.c. Attached is a patch to fix this: nspr_pr_src_pthreads_ptsynch.c.diff. Furthermore for the tests to succeed on GNU/Hurd the following patch: debian_rules.diff, is needed, since GNU/Hurd does fully implement semaphores. This package has built properly before, the latest built package is: 4.12-2 Thanks! --- a/debian/rules 2020-09-20 17:11:23.0 +0200 +++ b/debian/rules 2020-09-20 18:26:34.0 +0200 @@ -84,7 +84,12 @@ # Skip socket because it freezes. # Skip getproto because it fails on some buildds. # Skip nblayer because it freezes on armel. +ifneq (hurd,$(shell dpkg-architecture -qDEB_HOST_ARCH_OS)) cd nspr/pr/tests && grep -v '^\(fdcach\|gethost\|getproto\|nblayer\|peek\|socket\|vercheck\)$$' ./runtests.sh | sh - $(CURDIR)/nspr/dist +else + # Skip semaphore tests: not implemented on GNU/Hurd. + cd nspr/pr/tests && grep -v '^\(sema\|semaerr\|semaping\)' ./runtests.sh | sh -s - $(CURDIR)/nspr/dist +endif cd nspr/lib/tests && LD_LIBRARY_PATH=$(CURDIR)/nspr/dist/bin$(addprefix :,$(LD_LIBRARY_PATH)) ./base64t cd nspr/lib/tests && LD_LIBRARY_PATH=$(CURDIR)/nspr/dist/bin$(addprefix :,$(LD_LIBRARY_PATH)) ./string endif Index: nspr-4.28/nspr/pr/src/pthreads/ptsynch.c === --- nspr-4.28.orig/nspr/pr/src/pthreads/ptsynch.c +++ nspr-4.28/nspr/pr/src/pthreads/ptsynch.c @@ -50,7 +50,7 @@ void _PR_InitLocks(void) rv = _PT_PTHREAD_MUTEXATTR_INIT(&_pt_mattr); PR_ASSERT(0 == rv); -#if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)) || \ +#if (defined(LINUX) && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2))) || \ (defined(FREEBSD) && __FreeBSD_version > 700055) rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP); PR_ASSERT(0 == rv);
Bug#853048: ITA: socnetv -- social network analysis and visualisation application
I intent to adopt socnetv. I have already spoken to Serafeim and he's willing to help me kindly. Cheers, Adrià signature.asc Description: PGP signature
Bug#969261: fixed in cyrus-imapd 3.2.3-2
Control: reopen -1 Control: tags -1 + moreinfo Le 20/09/2020 à 22:18, Andy Dorman a écrit : > On Sun, 13 Sep 2020 16:18:27 + Debian FTP Masters > wrote: >> Source: cyrus-imapd >> Source-Version: 3.2.3-2 >> Done: Xavier Guimard >> >> We believe that the bug you reported is fixed in the latest version of >> cyrus-imapd, which is due to be installed in the Debian FTP archive. >> >> A summary of the changes between this version and the previous one is >> attached. >> >> Thank you for reporting the bug, which will now be closed. If you >> have further comments please address them to 969...@bugs.debian.org, >> and the maintainer will reopen the bug report if appropriate. >> >> Debian distribution maintenance software >> pp. >> Xavier Guimard (supplier of updated cyrus-imapd >> package) >> >> (This message was generated automatically at their request; if you >> believe that there is a problem with it please contact the archive >> administrators by mailing ftpmas...@ftp-master.debian.org) >> > > Just FYI in case it might help someone. > > I had the same problem but simeply upgrading from 3.2.3-1 to 3.2.3-2 did > not allow cyrus-imapd to run. I had to manually recreate the /run/cyrus > dir and sub-directories with correct cyrus.mail ownership and > permissions before cyrus-imapd would start. > > ~# ls -al /run/cyrus > drwxr-xr-x 5 cyrus mail 100 Jan 18 2020 . > drwxr-xr-x 31 root root 1140 Sep 20 13:03 .. > drwx-- 5 cyrus mail 100 Jun 5 12:49 lock > drwx-- 2 cyrus mail 40 Sep 20 15:15 proc > drwxr-x--- 2 cyrus mail 60 Sep 20 13:03 socket Hi, I didn't succeed to reproduce this bug
Bug#966382: RFS: photoprint/0.4.2~pre2-3 -- Image printing utility
Hello Tobias, I've updated the package following your instructions. It's available at mentors: https://mentors.debian.net/package/photoprint/ Best Regards, François signature.asc Description: This is a digitally signed message part
Bug#970658: RM: r-other-dropbead [all] -- RoQA; NBS; renamed to r-other-rajewsky-dropbead
Package: ftp.debian.org Severity: normal Please clean up the cruft r-other-dropbead binary arch:all package. r-other-dropbead | 0.3.1+git20180221.d746c6f+ds-1 | unstable| all r-other-rajewsky-dropbead | 0.3.1+git20180221.d746c6f+ds-1 | unstable| source r-other-rajewsky-dropbead | 0.3.1+git20180221.d746c6f+ds-3 | unstable| source, all Andreas
Bug#969261: fixed in cyrus-imapd 3.2.3-2
On Sun, 13 Sep 2020 16:18:27 + Debian FTP Masters wrote: Source: cyrus-imapd Source-Version: 3.2.3-2 Done: Xavier Guimard We believe that the bug you reported is fixed in the latest version of cyrus-imapd, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 969...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Xavier Guimard (supplier of updated cyrus-imapd package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) Just FYI in case it might help someone. I had the same problem but simeply upgrading from 3.2.3-1 to 3.2.3-2 did not allow cyrus-imapd to run. I had to manually recreate the /run/cyrus dir and sub-directories with correct cyrus.mail ownership and permissions before cyrus-imapd would start. ~# ls -al /run/cyrus drwxr-xr-x 5 cyrus mail 100 Jan 18 2020 . drwxr-xr-x 31 root root 1140 Sep 20 13:03 .. drwx-- 5 cyrus mail 100 Jun 5 12:49 lock drwx-- 2 cyrus mail 40 Sep 20 15:15 proc drwxr-x--- 2 cyrus mail 60 Sep 20 13:03 socket
Bug#970583: buster-pu: package chocolate-doom/3.0.0-4+deb10u1
On Sat, Sep 19, 2020 at 06:15:22PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2020-09-19 at 13:31 +0200, Moritz Muehlenhoff wrote: > > Fix for CVE-2020-14983, which doesn't really warrant a DSA. > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Bug#970657: tcpspy FTCBFS: hard codes the build architecture compiler
Source: tcpspy Version: 1.7d-15 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs tcpspy fails to cross build from source, because the upstream Makefile hard codes the build architecture compiler gcc. Please consider applying the attached patch to make it substitutable and tcpspy cross buildable. Helmut --- tcpspy-1.7d.orig/Makefile +++ tcpspy-1.7d/Makefile @@ -22,7 +22,7 @@ all: tcpspy doc tcpspy: log.o rule_lexer.o rule_grammar.o rule.o tcpspy.o - gcc $(LDFLAGS) $(CFLAGS) $(CPPFLAGS) log.o rule_lexer.o rule_grammar.o rule.o tcpspy.o -o tcpspy + $(CC) $(LDFLAGS) $(CFLAGS) $(CPPFLAGS) log.o rule_lexer.o rule_grammar.o rule.o tcpspy.o -o tcpspy log.o: log.c
Bug#970584: buster-pu: package inetutils/2:1.9.4-7+deb10u1
On Sat, Sep 19, 2020 at 06:17:20PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2020-09-19 at 13:33 +0200, Moritz Muehlenhoff wrote: > > Fix for CVE-2020-10188, which doesn' really warrant a DSA. > > > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Bug#970656: r-cran-isospecr: missing (unversioned) Breaks+Replaces: r-cran-isospec
Package: r-cran-isospecr Version: 2.1.2-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'stable'. It installed fine in 'stable', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces This test intentionally skipped 'testing' to find file overwrite problems before packages migrate from 'unstable' to 'testing'. >From the attached log (scroll to the bottom...): Preparing to unpack .../r-cran-isospecr_2.1.2-2_amd64.deb ... Unpacking r-cran-isospecr (2.1.2-2) ... dpkg: error processing archive /var/cache/apt/archives/r-cran-isospecr_2.1.2-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/R/site-library/IsoSpecR/DESCRIPTION', which is also in package r-cran-isospec 1.9.1-5 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/r-cran-isospecr_2.1.2-2_amd64.deb cheers, Andreas r-cran-isospec=1.9.1-5_r-cran-isospecr=2.1.2-2.log.gz Description: application/gzip
Bug#970651: [Pkg-javascript-devel] Bug#970651: rollup: Unable to build with current tsc
Le 20/09/2020 à 22:08, Pirate Praveen a écrit : > > > On 2020, സെപ്റ്റംബർ 21 12:38:37 AM IST, Xavier Guimard > wrote: >> Package: rollup >> Version: 1.12.0-2 >> Severity: serious >> Tags: ftbfs >> Justification: Policy 7.7.7 >> >> node-rollup 1.12.0 can't be build with current typescript (4.0.2). It >> requires tsc 3.4.5 (tested with success). Output: > > I think the root cause is uploading major versions without coordination. It > should have been easily found out if all packages using typescript was > rebuilt before it was uploaded to unstable. > > I think we should create a release team within js team to handle it like how > release team works for transitions. +1
Bug#970651: [Pkg-javascript-devel] Bug#970651: rollup: Unable to build with current tsc
On 2020, സെപ്റ്റംബർ 21 12:38:37 AM IST, Xavier Guimard wrote: >Package: rollup >Version: 1.12.0-2 >Severity: serious >Tags: ftbfs >Justification: Policy 7.7.7 > >node-rollup 1.12.0 can't be build with current typescript (4.0.2). It >requires tsc 3.4.5 (tested with success). Output: I think the root cause is uploading major versions without coordination. It should have been easily found out if all packages using typescript was rebuilt before it was uploaded to unstable. I think we should create a release team within js team to handle it like how release team works for transitions. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#970655: buster-pu: package sleuthkit/4.6.5-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Dear Release Team, I would like to update the sleuthkit on the buster to prevent a stack buffer overflow in yaffsfs_istat, because during a review of the Debian Security Tracker, I found CVE-2020-10232. There is no DSA assigned to the bug and it was marked "no-dsa" and so I'm doing a normal upload. "This is potentially exploitable by an attacker creating a file in a yaffs image with abnormally large time values", as reported in: https://github.com/sleuthkit/sleuthkit/pull/1836 Vulnerable code follows: tsk/fs/yaffs.cpp line 2442: char timeBuf[32]; This vulnerability has been assigned the CVE id CVE-2020-10232. Upstream fixed the bug at: https://github.com/sleuthkit/sleuthkit/pull/1836/commits/459ae818fc8dae717549810150de4d191ce158f1 [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10232 [1] https://security-tracker.debian.org/tracker/CVE-2020-10232 [2] https://bugs.debian.org/953976 Sincerely, Francisco diff -Nru sleuthkit-4.6.5/debian/changelog sleuthkit-4.6.5/debian/changelog --- sleuthkit-4.6.5/debian/changelog2019-01-22 11:53:42.0 + +++ sleuthkit-4.6.5/debian/changelog2020-09-16 23:47:07.0 + @@ -1,3 +1,11 @@ +sleuthkit (4.6.5-1+deb10u1) buster; urgency=high + + * Team upload. + * Add patch to fix stack buffer overflow in yaffsfs_istat. +(Closes: #953976, CVE-2020-10232) + + -- Francisco Vilmar Cardoso Ruviaro Wed, 16 Sep 2020 23:47:07 + + sleuthkit (4.6.5-1) unstable; urgency=medium * Team upload diff -Nru sleuthkit-4.6.5/debian/patches/CVE-2020-10232.patch sleuthkit-4.6.5/debian/patches/CVE-2020-10232.patch --- sleuthkit-4.6.5/debian/patches/CVE-2020-10232.patch 1970-01-01 00:00:00.0 + +++ sleuthkit-4.6.5/debian/patches/CVE-2020-10232.patch 2020-09-16 23:47:07.0 + @@ -0,0 +1,21 @@ +Description: Fix stack buffer overflow in yaffsfs_istat. + Prevent a stack buffer overflow in yaffsfs_istat by increasing + the buffer size to the size required by tsk_fs_time_to_str. +Author: micrictor +Origin: https://github.com/sleuthkit/sleuthkit/commit/459ae818fc8dae717549810150de4d191ce158f1 +Bug: https://github.com/sleuthkit/sleuthkit/pull/1836 +Forwarded: not-needed +Reviewed-By: Francisco Vilmar Cardoso Ruviaro +Last-Update: 2020-08-28 + +--- sleuthkit-4.6.5.orig/tsk/fs/yaffs.cpp sleuthkit-4.6.5/tsk/fs/yaffs.cpp +@@ -2439,7 +2439,7 @@ static uint8_t + YAFFSFS_INFO *yfs = (YAFFSFS_INFO *)fs; + char ls[12]; + YAFFSFS_PRINT_ADDR print; +-char timeBuf[32]; ++char timeBuf[128]; + YaffsCacheObject * obj = NULL; + YaffsCacheVersion * version = NULL; + YaffsHeader * header = NULL; diff -Nru sleuthkit-4.6.5/debian/patches/series sleuthkit-4.6.5/debian/patches/series --- sleuthkit-4.6.5/debian/patches/series 2019-01-22 11:52:14.0 + +++ sleuthkit-4.6.5/debian/patches/series 2020-09-16 23:47:07.0 + @@ -3,4 +3,4 @@ 50_disable-ant-clean.patch 60_fix-FTBFS-HURD.patch 0005-Disable-test_libraries.sh.patch - +CVE-2020-10232.patch -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Bug#970654: libncarg-dev: ships libncl.a already provided by libncl-dev
Package: libncarg-dev Version: 6.6.2-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Selecting previously unselected package libncarg-dev:amd64. Preparing to unpack .../137-libncarg-dev_6.6.2-3_amd64.deb ... Unpacking libncarg-dev:amd64 (6.6.2-3) ... dpkg: error processing archive /tmp/apt-dpkg-install-vVrpbS/137-libncarg-dev_6.6.2-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libncl.a', which is also in package libncl-dev 2.1.21+git20190531.feceb81-3 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /tmp/apt-dpkg-install-vVrpbS/137-libncarg-dev_6.6.2-3_amd64.deb cheers, Andreas libncl-dev=2.1.21+git20190531.feceb81-3_libncarg-dev=6.6.2-3.log.gz Description: application/gzip
Bug#969436: closed in net-snmp 5.9+dfsg-2
Hi On 20-09-2020 21:29, Paul Gevers wrote: > On Mon, 14 Sep 2020 14:15:38 +1000 Craig Small wrote: >> Package: libsnmp-dev >> Version: 5.9+dfsg-2 > > libsnmp-dev wasn't the package that this bug filed against at the moment > you closed it. So, the bts doesn't consider the bug closed in unstable. > (Hopefully I fixed that now, if not, I'll try harder). This text is obviously nonsense about the package part. It's still true about the bts part. Paul signature.asc Description: OpenPGP digital signature
Bug#970653: ITP: vguitar -- Play Guitar in any term w/ MIDI synthesizer
Package: wnpp Severity: wishlist Owner: Nick Strauss * Package name: vguitar Version : 2.6 Upstream Author : Nick Strauss * URL : http://www.nick-strauss.com/ * License : GPL Programming Lang: C++ Description : Play Guitar in any term w MIDI synthesizer Vguitar is a MIDI instrument Guitar and is a tablature editor and can easily read existing ASCII tablature with some minor editing. Connect via ALSA to a synthesizer. Vguitar supports a six string guitar with standard and alternative tunings including relative, MIDI and Drop D tunings, supports box and strum modes. VGuitar is extremely lightweight dependent only on libasound and ncurses. It is written in C++ and is easy to read and to build. * Providing similar functionality, how does it compare? only Vguitar is a unix tool rather than a monolithic windows application with menus. only Vguitar is term window based. only Vguitar supports alternate tunings, box and strum modes. only Vguitar is written in C++ and is only dependent on libasound and ncurses. ** songwrite fairly easy to build python dependent on Lilypond and Tcl/Tk. easy learning curve ** eTktab which is a guitar tablature editor written in Tcl/Tk, simple fairly easy to build (only depends on TCL/TK) source code bulky, hard to read. no sound. ** Tuxguitar http://www.tuxguitar.com.ar/ build difficulty (dependent on Java (JVM) which is licensed, ANT, SWT, and ITEXT). steep learning curve feature rich, complicated, not term based. has note effects. ** guitarexerciser #667855 ? * I am looking for co-maintainers and a sponsor. * I am looking for suggestions for version and change control.
Bug#966028: buster-pu: package librsvg/2.44.10-2.1+deb10u1
On 20/09/2020 10:55, Emilio Pozuelo Monfort wrote:
> On 25/07/2020 12:04, Adam D. Barratt wrote:
>> Hi,
>>
>> On Wed, 2020-07-22 at 13:26 +0200, Emilio Pozuelo Monfort wrote:
>>> On 22/07/2020 13:19, Emilio Pozuelo Monfort wrote:
So I have gone with the minimal backport to 2.44.10 instead (which
I've also tested) and it's already uploaded. debdiff attached.
>>>
>>> Attached for real now.
>>
>> Unfortunately it appears that this FTBFS on ppc64el and s390x, with a
>> segmentation fault in the tests.
>
> I have uploaded a new revision, fixing this FTBFS and the one caused by the
> new
> rustc 1.41.
Shame on me, the ppc64el/s390x was good but the other, general FTBFS with rustc
1.41 wasn't sufficiently tested due to a mistake on my side.
I have done a new brown paper bug release to stable-new, hopefully this will be
the final one.
Thanks,
Emilio
diff -Nru librsvg-2.44.10/debian/changelog librsvg-2.44.10/debian/changelog
--- librsvg-2.44.10/debian/changelog2020-09-20 10:48:42.0 +0200
+++ librsvg-2.44.10/debian/changelog2020-09-20 21:21:54.0 +0200
@@ -1,3 +1,12 @@
+librsvg (2.44.10-2.1+deb10u3) buster; urgency=medium
+
+ * nalgebra-borrow-mutable-immutable.patch:
+- Update checksum for cg.rs.
+ * cssparser-dont-assign-to-borrowed-variable.patch:
+- Fix another build failure with rustc 1.41.
+
+ -- Emilio Pozuelo Monfort Sun, 20 Sep 2020 21:21:54 +0200
+
librsvg (2.44.10-2.1+deb10u2) buster; urgency=medium
* nalgebra-borrow-mutable-immutable.patch: fix build with rustc 1.41.
diff -Nru
librsvg-2.44.10/debian/patches/cssparser-dont-assign-to-borrowed-variable.patch
librsvg-2.44.10/debian/patches/cssparser-dont-assign-to-borrowed-variable.patch
---
librsvg-2.44.10/debian/patches/cssparser-dont-assign-to-borrowed-variable.patch
1970-01-01 01:00:00.0 +0100
+++
librsvg-2.44.10/debian/patches/cssparser-dont-assign-to-borrowed-variable.patch
2020-09-20 18:59:43.0 +0200
@@ -0,0 +1,92 @@
+From 3c98d22c5de3b696bf1fde2b6c90069812312aa6 Mon Sep 17 00:00:00 2001
+From: Simon Sapin
+Date: Tue, 23 Apr 2019 13:47:25 +0200
+Subject: [PATCH] Fix a future-compat warning
+
+```
+warning[E0506]: cannot assign to `self.input.cached_token` because it is
borrowed
+ --> src/parser.rs:591:17
+|
+566 | pub fn next_including_whitespace_and_comments( self) ->
Result<<'i>, BasicParseError<'i>> {
+| - let's call the
lifetime of this reference `'1`
+...
+579 | Some(ref cached_token)
+| borrow of `self.input.cached_token`
occurs here
+...
+591 | self.input.cached_token = Some(CachedToken {
+| ^^^ assignment to borrowed
`self.input.cached_token` occurs here
+...
+603 | Ok(token)
+| - returning this value requires that
`self.input.cached_token.0` is borrowed for `'1`
+|
+= warning: this error has been downgraded to a warning for backwards
compatibility with previous releases
+= warning: this represents potential undefined behavior in your code and
this warning will become a hard error in the future
+```
+---
+ src/parser.rs | 50 +++---
+ 1 file changed, 27 insertions(+), 23 deletions(-)
+
+--- a/vendor/cssparser/src/parser.rs
b/vendor/cssparser/src/parser.rs
+@@ -555,28 +555,34 @@ impl<'i: 't, 't> Parser<'i, 't> {
+ }
+
+ let token_start_position = self.input.tokenizer.position();
+-let token;
+-match self.input.cached_token {
+-Some(ref cached_token)
+-if cached_token.start_position == token_start_position => {
+-self.input.tokenizer.reset(_token.end_state);
+-match cached_token.token {
+-Token::Function(ref name) =>
self.input.tokenizer.see_function(name),
+-_ => {}
+-}
+-token = _token.token
++let using_cached_token = self
++.input
++.cached_token
++.as_ref()
++.map_or(false, |cached_token| {
++cached_token.start_position == token_start_position
++});
++let token = if using_cached_token {
++let cached_token = self.input.cached_token.as_ref().unwrap();
++self.input.tokenizer.reset(_token.end_state);
++match cached_token.token {
++Token::Function(ref name) =>
self.input.tokenizer.see_function(name),
++_ => {}
+ }
+-_ => {
+-let new_token = self.input.tokenizer.next()
+-.map_err(|()|
self.new_basic_error(BasicParseErrorKind::EndOfInput))?;
+-self.input.cached_token = Some(CachedToken {
+-token: new_token,
+-start_position: token_start_position,
+-
Bug#970639: grub-pc: Zswap disabled by default
Hi, On Sun, Sep 20, 2020 at 05:46:18PM +0100, Colin Watson wrote: > Control: reassign -1 linux > > On Sun, Sep 20, 2020 at 12:37:02PM -0400, Calum McConnell wrote: > > Simply put, I think a lot of people would benefit from zswap being > > enabled by default. Except on very low-preformance machines, it is > > always an improvment. Even on those very limited machines, zswap > > would only be a significant limitation if memory is being pushed > > close, but not past, it's limits, and Disk IO is very fast-- neither > > of which are likely true for computers with sufficently weak CPU's. > > > > >From what I can tell, enabling it should be a simple matter of > > >changing the default grub config file. > > > > I know zswap is a kernel parameter, but every guide I have seen says > > to enable it in grub config. As such, I appologize if you think this > > report is better directed elsewhere, or if it has been implemented > > already and my config files are out of date. > > I understand that guides often refer to boot loader configuration as the > path of least resistance. However, if this is going to be enabled by > default, I think it generally makes more sense for that to be done in > the Debian kernel packaging (which is generally in a better position to > determine what makes for good defaults for the kernel's behaviour), so > I'm reassigning this bug there. > > (I currently have no opinion on the change itself.) Interestingly it still contains the following note in documentation: Zswap is a new feature as of v3.11 and interacts heavily with memory reclaim. This interaction has not been fully explored on the large set of potential configurations and workloads that exist. For this reason, zswap is a work in progress and should be considered experimental. Unless this is not anymore to be considered valid, then CONFIG_ZSWAP_DEFAULT_ON could be switched on (which should be possible since 5.7-rc1). Regards, Salvatore
Bug#970651: rollup: Unable to build with current tsc
Package: rollup Version: 1.12.0-2 Severity: serious Tags: ftbfs Justification: Policy 7.7.7 node-rollup 1.12.0 can't be build with current typescript (4.0.2). It requires tsc 3.4.5 (tested with success). Output: $ tsc --esModuleInterop src/ModuleLoader.ts:59:3 - error TS2322: Type '(id: string) => boolean' is not assignable to type '(id: string, ...args: T) => boolean'. Types of parameters 'id' and 'id' are incompatible. Type '[id: string, ...args: T]' is not assignable to type '[id: string]'. Source has 2 element(s) but target allows only 1. 59 return id => ids.has(id); ~
Bug#970652: RFS: mcx/1.0-1 [ITP] -- Monte Carlo eXtreme 3D photon transport simulator
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "mcx": * Package name : mcx Version : 2020.9-1 Upstream Author : fan...@gmail.com * URL : https://github.com/fangq/mcx * License : GPL-3+, BSD-2-clause, MIT, public-domain, MPL-2, BSD-3-clause * Vcs : https://salsa.debian.org/pkg-octave-team/mcx Section : science It builds those binary packages: matlab-mcxtools - mcx photon transport simulator helper functions for MATLAB octave-mcxtools - mcx photon transport simulator helper functions for Octave matlab-mcxlab - mcx photon transport simulator for matlab octave-mcxlab - mcx photon transport simulator for octave mcxstudio - unified graphical user interface for MCX/MMC/MCXCL mcx-demos - sample simulations for Monte Carlo eXtreme (mcx) mcxphoton - unified command line interface for mcx/mmc/mcxcl libmcx1 - library for Monte Carlo eXtreme 3D photon transport simulations mcx - Monte Carlo eXtreme 3D photon transport simulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mcx/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mcx/mcx_2020.9-1.dsc Changes for the initial release: mcx (2020.9-1) unstable; urgency=medium . * Initial release (Closes: #970475) Regards, -- Qianqian Fang
Bug#968097: transmission-daemon consumes all memory
Thank you, Moritz! I installed your packages on September 15. Since then, transmission behaves fine again. See munin-graph attached. If this sample - five days on one machine from one user - is big enough to be significant, i don't know. Best Moritz Mühlenhoff: Can you please test the updated packages at https://people.debian.org/~jmm/ -- ilf If you upload your address book to "the cloud", I don't want to be in it.
Bug#970608: src:coreutils: fails to migrate to testing for too long: FTBFS on arm64
Hi Michael, On 20-09-2020 18:21, Michael Stone wrote: > I thought debports architectures weren't supposed to prevent migration > to testing so I'm confused about why the package hasn't migrated. arm64 is a release architecture, already since jessie. https://www.debian.org/releases/jessie/ Paul signature.asc Description: OpenPGP digital signature
Bug#958910: debci: 'debci setup -a armhf' fails to set up an lxc container on an amd64 host
Dear Maintainer, I am missing someone has taken a look into this issue. I'd appreciate to get some feedback. Please let me know what further input from my side may be helpful. Regards, Sven signature.asc Description: This is a digitally signed message part
Bug#970650: gnome-recipes: Translation errors in "Savory Cake" recipe
Package: gnome-recipes Version: 2.0.2-5+b1 Severity: minor Dear Maintainer, the recipe called "Bohnenkraut-Kuchen" in German locale (probably "Savory Cake" in English) provided in gnome-recipes has two issues, maybe a translation problem: - The list of ingredients shows "Backpulver" (baking powder) while the recipe mentions only yeast. Which one is it? Both? Results can be quite different. - The German title "Bohnenkraut-Kuchen" refers to the herb called savory, which is not mentioned in the recipe. I guess this is not the meaning of "savory" intended by the recipe author. A savory taste (salty etc.) should be translated as "Herzhaft", IMHO. Thanks for your work! Cheers Michael -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-recipes depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-1 ii dbus-x11 [dbus-session-bus] 1.12.20-1 ii gnome-recipes-data2.0.2-5 ii libc6 2.31-2 ii libcairo2 1.16.0-4 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-02.40.0+dfsg-5 ii libglib2.0-0 2.64.4-1 ii libgnome-autoar-0-0 0.2.4-2 ii libgoa-1.0-0b 3.36.0-1 ii libgspell-1-2 1.8.3-1 ii libgtk-3-03.24.20-1 ii libjson-glib-1.0-01.4.4-2 ii libpango-1.0-01.44.7-4 ii libpangocairo-1.0-0 1.44.7-4 ii librest-0.7-0 0.8.1-1+b1 ii libsoup2.4-1 2.70.0-1 gnome-recipes recommends no packages. gnome-recipes suggests no packages. -- no debconf information
Bug#970471: [pkg-crosswire-devel] Bug#970471: Possible ways to resolve
Am 20.09.20 um 12:35 schrieb Teus Benschop: > The error message in this bug report is an unusual one. > > I managed to find one other similar report on Google, which was in Chinese. > > Possible solutions I could think of are these two. > > 1. If the error is temporary, to upload a new package that would trigger a > rebuild. > > 2. To ask the FTP Masters to remove the previously build for this > architecture, so the remaining architectures can move to testing. > Upstream provided a patch that I applied on salsa. Would someone please upload the new version?
Bug#632438: [Popcon-developers] Bug#681721: #632438: popularity-contest: a way to exclude certain packages
On Sun, Sep 20, 2020 at 10:56:02PM +0800, Paul Wise wrote: > On Sun, 2020-09-20 at 11:04 +0200, Bill Allombert wrote: > > > Instead I would suggest to add a new dpkg control field 'X-Popcon: > > private' and have popularity-contest skip packages having this field. > > This isn't going to be useful for users who want to exclude packages > from repos that they do not control But again why would they want that ? The only thing popcon report is the package names (which would be public anyway) and some timing data. If they do not trust popcon anonymization, then it is safer to disable popcon entirely. It is a given users can mess with popcon reports in any way then want. However randomly hiding packages from popcon report is not something that should be sanctionned by the popularity-contest package. > or packages built by mk-build-deps > or other tools that do not allow adding extra dpkg control fields. I suppose mk-build-deps and other tools could then be updated to support this feature. This is not really an objection. In fact it would make this much easier. Cheers, -- Bill. Imagine a large red swirl here.
Bug#969633: transition: json-simple
Hi Emilio, Emilio Pozuelo Monfort a écrit le 20/09/2020 à 18:50 : > On 06/09/2020 13:38, Gilles Filippini wrote: >> Emilio Pozuelo Monfort a écrit le 06/09/2020 à 12:19 : >>> On 06/09/2020 11:53, Gilles Filippini wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to transition json-simple 3.1.1 surrently sitting into experimental. The name of the library doens't change, but reverse dependencies need a binnmu. >>> >>> Why is that? >> >> Upstream removed an API that was deprecated long ago and introduced a >> few backward incompatible changes. > > Then it needs a SONAME bump. There is no such thing in java. I asked the question on the debian-java list whether to change the binary package's name and it was answered that it should be avoidable [1]. I eventually chose not to change it because there are few reverse dependencies. [1] https://lists.debian.org/debian-java/2020/05/msg00025.html What do you think? _g. signature.asc Description: OpenPGP digital signature
Bug#970648: RM: haskell-termonad [armhf] -- ROM; missing build dependency
Package: ftp.debian.org Severity: normal The latest version of haskell-gi-gtk FTBFS on armhf (ghc: out of memory, see ROM #970642). Please remove haskell-termonad (build-depends on haskell-gi-gtk) from armhf. Thanks, -- Ilias
Bug#970649: RM: taffybar [armhf] -- ROM; missing build dependency
Package: ftp.debian.org Severity: normal The latest version of haskell-gi-gtk FTBFS on armhf (ghc: out of memory, see ROM #970642). Please remove taffybar (build-depends on haskell-gi-gtk) from armhf. Thanks, -- Ilias
Bug#970646: RM: haskell-gtk-strut [armhf] -- ROM; missing build dependency
Package: ftp.debian.org Severity: normal The latest version of haskell-gi-gtk FTBFS on armhf (ghc: out of memory, see ROM #970642). Please remove haskell-gtk-strut (build-depends on haskell-gi-gtk) from armhf. Thanks, -- Ilias
Bug#970647: RM: haskell-gtk-sni-tray [armhf] -- ROM; missing build dependency
Package: ftp.debian.org Severity: normal The latest version of haskell-gi-gtk FTBFS on armhf (ghc: out of memory, see ROM #970642). Please remove haskell-gtk-sni-tray (build-depends on haskell-gi-gtk) from armhf. Thanks, -- Ilias
Bug#970645: RM: haskell-gi-vte [armhf] -- ROM; missing build dependency
Package: ftp.debian.org Severity: normal The latest version of haskell-gi-gtk FTBFS on armhf (ghc: out of memory, see ROM #970642). Please remove haskell-gi-vte (build-depends on haskell-gi-gtk) from armhf. Thanks, -- Ilias
Bug#970644: RM: haskell-gi-dbusmenugtk3 [armhf] -- ROM; missing build dependency
Package: ftp.debian.org Severity: normal The latest version of haskell-gi-gtk FTBFS on armhf (ghc: out of memory, see ROM #970642). Please remove haskell-gi-dbusmenugtk3 (build-depends on haskell-gi-gtk) from armhf. Thanks, -- Ilias
Bug#970643: "pytest" command is missing
Package: python3-pytest Version: 3.10.1-2 The standard runner "pytest" command present in most pytest files shebang isn't shipped by python3-pytest package. It used to be shipped by python2 "python-pytest" package which is neither present in testing nor unstable, so there's room for shipping it in python3-pytest without a conflict, and it would prevent a scripts from failing to run with their shebang.
Bug#970642: RM: haskell-gi-gtk [armhf] -- ROM; unbuildable - OOM
Package: ftp.debian.org Severity: normal The latest version of haskell-gi-gtk FTBFS on armhf (ghc: out of memory). Please remove haskell-gi-gtk from armhf. Thanks, -- Ilias
Bug#970386: dovecot-imapd: assertion failure in message_part_finish when searching large folder
On Fri, Sep 18, 2020 at 12:05:09AM +0300, Timo Sirainen wrote: > > One of my IMAP users reports failures when trying to do full-text > > searches of a large (3G) mailbox; subject-only searches are OK. > > > > The backtrace in syslog is: > > > > Sep 15 11:51:37 aragorn dovecot: imap(atreic): Panic: file > > message-parser.c: line 174 (message_part_finish): assertion failed: > > (ctx->nested_parts_count > 0) > > The original backported patch for v2.2 was accidentally wrong. Also I'm not > sure if Debian backport had the "--" suffix boundary fix either? Attached > anyway patches for both fixes. > Thanks for looking at this, Timo. The 2.2 packages in Debian 9 (stretch LTS) should have the latest patches. See [1] and [2]. 1. https://salsa.debian.org/debian/dovecot/-/blob/stable/stretch/debian/patches/CVE-2020-12100-14.patch#L57 2. https://salsa.debian.org/debian/dovecot/-/blob/stable/stretch/debian/patches/CVE-2020-12100-16.patch Matthew, the stack trace doesn't include the most relevant symbols, so the code path isn't entirely clear. It's likely that the problem isn't specifically related to a large mailbox, as originally suggested, but rather a specific message in that mailbox. It might be interesting if we could get a copy of that message, if it can be identified and the contents aren't sensitive. Feel free to provide it to me privately if posting it to the BTS isn't desirable. It'd help track this down, and I'd be interested in testing the buster and sid dovecot packages against it. Thanks noah
Bug#970641: libqtgui4: QDialog randomly misplaced invisible in buster, patches
Package: libqtgui4
Version: 4:4.8.7+dfsg-18
Severity: normal
Tags: patch
Introduction:
After migrating a legacy application from jessie to buster without making major
changes we experienced QDialogs and QMessageBoxes randomly showing up outside
the visible area.
In most of the occurences the invisible dialog didn't have focus despite being
modal, rendering the GUI frozen from the user's perspective.
Bugs:
We finally tracked it down to QDesktopWidget::availableGeometry(int screen)
parsing the response of XGetWindowProperty(_NET_WORKAREA) as array of 4 64 bit
integers despite format==32 clearly guaranteeing 32 bit integers.
This 'compresses' the 4 good values received in the first 2 values of the QRect
workArea c'tor, x and y, and pulls random memory content in the other 2 values,
width and heigth.
As a consequence QMessageBoxPrivate::updateSize() calculated hardLimit,
softLimit, width and height to crazy negative values like -123456789.
That whole method, QMessageBoxPrivate::updateSize(), has some wild heuristics
and should not use negative values, but that's not the root cause.
Depending on the window manager and system configuration the bad code path in
QDesktopWidget::availableGeometry(int) might be used or not.
It's always used in our customer's setup that facilitates matchbox-window-
manager -use_titlebar no for a kiosk-like user experience.
Patches:
Our main patch, qdesktopwidget_fix_availableGeometry.diff, fixes the main error
described above, in src/gui/kernel/qdesktopwidget_x11.cpp:304.
Our side patch qmessagebox_ironize_updatesize.diff makes
QMessageBoxPrivate::updateSize() ignore non-positive softLimits and hardLimits.
We're not 100% sure it's a good idea to apply that. Concerns
src/gui/dialogs/qmessagebox.cpp lines 345, 349, 375, 390.
Non-Patches:
On the assumption that such code is often copied'n'change we grepped for other
uses of XGetWindowProperty() (there are 51), quickly (not too thouroghly)
checked for similar mistakes and found serveral suspicious blocks of code.
This was done after 'apt-get source qt4-x11' to *.cpp under
qt4-x11-4.8.7+dfsg/src/, i.e. after debian patches have been applied to the
source code. Line numbers in upstream tarball might differ.
In QETWidget::translatePropertyEvent(),
src/gui/kernel/qapplication_x11.cpp:5008ff
XGetWindowProperty(_KDE_NET_WM_FRAME_STRUT) seems to make a similar mistake,
but I haven't researched wether the contradiction between '// struts are 4
longs' and the check 'format == 32' is a bug or maybe a legitimate-ish hack.
Other XGetWindowProperty() calls with suspicious result processing can be found
in
src/gui/kernel/qapplication_x11.cpp:2831, which someone has thought about
with // quint32, but seems not in use
src/gui/kernel/qapplication_x11.cpp:5027
src/gui/kernel/qapplication_x11.cpp:5106
src/gui/kernel/qapplication_x11.cpp:5165
src/gui/kernel/qx11embed_x11.cpp:415
src/gui/kernel/qx11embed_x11.cpp:829
src/gui/kernel/qx11embed_x11.cpp:1673
Patched amd64 packages:
Packages that include our 2 patches can be found on
https://deb.clazzes.org/debian/pool/buster-xpkg-1/
To use them with apt or the like perform something like this:
wget -O /etc/apt/trusted.gpg.d/pba-archiver.clazzes.org.gpg
https://deb.clazzes.org/gpg/pba-archiver.clazzes.org.gpg
cd /etc/apt/sources.list.d
wget https://deb.clazzes.org/debian/sources.list.d/buster/buster-xpkg-1.list
apt-get update
apt-get upgrade
We'd be willing to add armhf packages if anyone's interested.
Our clean room build infrastructure has been relieved from i386 and we don't
support other archs.
Regards, Christoph Lechleitner
--
Christoph Lechleitner
Geschäftsführung
ITEG IT-Engineers GmbH | Salurner Straße 18, A-6020 Innsbruck
FN 365826f | Handelsgericht Innsbruck | Mobiltelefon: +43 676 3674710
Mail: christoph.lechleit...@iteg.at | Web: http://www.iteg.at/
--- qt4-x11-4.8.7+dfsg.orig/src/gui/kernel/qdesktopwidget_x11.cpp 2015-05-07 16:14:43.0 +0200
+++ qt4-x11-4.8.7+dfsg/src/gui/kernel/qdesktopwidget_x11.cpp 2020-09-20 15:49:52.089122544 +0200
@@ -301,7 +301,8 @@
QRect workArea;
if (e == Success && ret == XA_CARDINAL &&
format == 32 && nitems == 4) {
-long *workarea = (long *) data;
+//long *workarea = (long *) data;
+qint32 *workarea = (qint32 *) data;
workArea = QRect(workarea[0], workarea[1], workarea[2], workarea[3]);
} else {
workArea = screenGeometry(screen);
--- qt4-x11-4.8.7+dfsg.orig/src/gui/dialogs/qmessagebox.cpp 2015-05-07 16:14:43.0 +0200
+++ qt4-x11-4.8.7+dfsg/src/gui/dialogs/qmessagebox.cpp 2020-09-20 15:49:20.787609493 +0200
@@ -342,11 +342,11 @@
label->setWordWrap(false); // makes the label return min size
int width = layoutMinimumWidth();
-if (width >
Bug#970639: grub-pc: Zswap disabled by default
Control: reassign -1 linux On Sun, Sep 20, 2020 at 12:37:02PM -0400, Calum McConnell wrote: > Simply put, I think a lot of people would benefit from zswap being > enabled by default. Except on very low-preformance machines, it is > always an improvment. Even on those very limited machines, zswap > would only be a significant limitation if memory is being pushed > close, but not past, it's limits, and Disk IO is very fast-- neither > of which are likely true for computers with sufficently weak CPU's. > > >From what I can tell, enabling it should be a simple matter of > >changing the default grub config file. > > I know zswap is a kernel parameter, but every guide I have seen says > to enable it in grub config. As such, I appologize if you think this > report is better directed elsewhere, or if it has been implemented > already and my config files are out of date. I understand that guides often refer to boot loader configuration as the path of least resistance. However, if this is going to be enabled by default, I think it generally makes more sense for that to be done in the Debian kernel packaging (which is generally in a better position to determine what makes for good defaults for the kernel's behaviour), so I'm reassigning this bug there. (I currently have no opinion on the change itself.) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#970640: ITS: mtd-utils
Source: mtd-utils Severity: important X-Debbugs-CC: riku.voi...@linaro.org Hi! I would like to salvage the mtd-utils package. The current maintainer is unresponsive on the open issues (2014 was the last answer). His last main package action was in August 2019, packging the version 2.1.1-1. This year, he sponsored a NMU that I prepared. #965155 asks for updating the package to the new version 2.1.2 and I handed in the patches to do that two months ago. I once again filed an NMU to get this in at #969918 and was encouraged to salvage the package. Regards, Bastian
Bug#969633: transition: json-simple
On 06/09/2020 13:38, Gilles Filippini wrote: > Emilio Pozuelo Monfort a écrit le 06/09/2020 à 12:19 : >> On 06/09/2020 11:53, Gilles Filippini wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Hi, >>> >>> I'd like to transition json-simple 3.1.1 surrently sitting into >>> experimental. >>> The name of the library doens't change, but reverse dependencies need a >>> binnmu. >> >> Why is that? > > Upstream removed an API that was deprecated long ago and introduced a > few backward incompatible changes. Then it needs a SONAME bump. Emilio
Bug#970639: grub-pc: Zswap disabled by default
Package: grub-pc
Version: 2.04-8
Severity: wishlist
X-Debbugs-Cc: calumlikesapple...@gmail.com
Simply put, I think a lot of people would benefit from zswap being enabled by
default. Except on
very low-preformance machines, it is always an improvment. Even on those very
limited machines,
zswap would only be a significant limitation if memory is being pushed close,
but not past, it's
limits, and Disk IO is very fast-- neither of which are likely true for
computers with sufficently
weak CPU's.
>From what I can tell, enabling it should be a simple matter of changing the
>default grub config file.
I know zswap is a kernel parameter, but every guide I have seen says to enable
it in grub config.
As such, I appologize if you think this report is better directed elsewhere, or
if it has been
implemented already and my config files are out of date.
Thanks for your time!
Calum
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
2c7929e7-825d-453d-a064-53da2115a7a2
else
search --no-floppy --fs-uuid --set=root 2c7929e7-825d-453d-a064-53da2115a7a2
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
2c7929e7-825d-453d-a064-53da2115a7a2
else
search --no-floppy --fs-uuid --set=root 2c7929e7-825d-453d-a064-53da2115a7a2
fi
insmod png
if background_image
/usr/share/desktop-base/futureprototype-theme/grub/grub-4x3.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-2c7929e7-825d-453d-a064-53da2115a7a2' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
2c7929e7-825d-453d-a064-53da2115a7a2
else
search --no-floppy --fs-uuid --set=root
2c7929e7-825d-453d-a064-53da2115a7a2
fi
echo'Loading Linux 5.8.0-1-amd64 ...'
linux /boot/vmlinuz-5.8.0-1-amd64
root=UUID=2c7929e7-825d-453d-a064-53da2115a7a2 ro quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-5.8.0-1-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-2c7929e7-825d-453d-a064-53da2115a7a2' {
menuentry
Bug#970608: src:coreutils: fails to migrate to testing for too long: FTBFS on arm64
I thought debports architectures weren't supposed to prevent migration to testing so I'm confused about why the package hasn't migrated.
Bug#964032: smartmontools: Samsung S1 Mini 200GB: Unknown USB bridge [0x04e8:0x2f06 (0x000)]
Added upstream in r5084, r5087: https://www.smartmontools.org/changeset/5084 https://www.smartmontools.org/changeset/5087 Please update the drive database.
Bug#969446: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth)
Hi Tobi,
> > i18n debian l10n ?
>
> Can you expand what you mean?
At one point, I had Vguitar fully i18n compliant and I made a call to
bindtextdomain ("vguitar", "/usr/share/locale/"); and I had PO files, and
support in the Makefiles. Then I took this out, because I do not understand the
Debian way for supporting. Is there a translation service?
There are not many textual messages in Vguitar. Maybe it is enough to only
support English.
> I'm currently doing RFS bug triaging and it seems that you are missing an ITP
> [1] bug. Please file one ;)
What is an ITP (1) bug?
Thank you for responding. I am unfamiliar with Debian packaging,
Nick Strauss
https://www.nick-strauss.com
On Sunday, September 20, 2020, 05:51:30 AM CDT, Tobias Frost
wrote:
On Mon, 14 Sep 2020 22:34:40 + Nick Strauss wrote:
> i18n debian l10n ?
Can you expand what you mean?
I'm currently doing RFS bug triaging and it seems that you are missing an ITP
[1] bug. Please file one ;)
--
Cheers,
tobi
[1]
https://wiki.debian.org/ITP
Bug#970638: jag: cannot upgrade from 3.6-1 to 3.8-1
Package: jag Version: 0.3.6-1 Severity: serious Justification: Policy 7.6.1 Dear Maintainer, Trying to upgrade jag from 3.6-1 to 3.8-1 fails, because the upgrade tries to overwrite files of jag-data. See the following apt upgrade output: Do you want to continue? [Y/n] Reading changelogs... Done (Reading database ... 248298 files and directories currently installed.) Preparing to unpack .../archives/jag_0.3.8-1_amd64.deb ... Unpacking jag (0.3.8-1) over (0.3.6-1) ... dpkg: error processing archive /var/cache/apt/archives/jag_0.3.8-1_amd64.deb (--unpack): trying to overwrite '/usr/share/games/jag/data/bonus/clock.png', which is also in package jag-data 0.3.6-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/jag_0.3.8-1_amd64.deb Have you moved clock.png without setting Breaks+Replaces properly as mentioned in policy 7.6.1? https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (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 jag depends on: ii jag-data 0.3.6-1 ii libc62.31-3 ii libgcc-s110.2.0-9 ii libqt5core5a 5.14.2+dfsg-6 ii libqt5gui5 5.14.2+dfsg-6 ii libqt5opengl55.14.2+dfsg-6 ii libqt5widgets5 5.14.2+dfsg-6 ii libqt5x11extras5 5.14.2-2 ii libsdl2-2.0-02.0.12+dfsg1-2 ii libsdl2-mixer-2.0-0 2.0.4+dfsg1-2+b1 ii libstdc++6 10.2.0-9 ii libx11-6 2:1.6.12-1 ii libxrandr2 2:1.5.1-1 jag recommends no packages. jag suggests no packages. -- no debconf information
Bug#884910: Closing the bug report
Dear Ben, the script r.js is packaged: not in the package libjs-requirejs, but in the package nodejs-requirejs. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#970637: nvme-cli: missing dependency: postinst script uses uuidgen
Package: nvme-cli Version: 1.12-4 Severity: normal Dear Maintainer, maybe the package must depend on uuid-runtime since its postinst script may call uuidgen. Is it correct to list the now during installation generated files in the `nvme-cli.list` file? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.9 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages nvme-cli depends on: ii libc6 2.31-3 ii libuuid1 2.36-3 nvme-cli recommends no packages. nvme-cli suggests no packages.
Bug#969918: RFS: mtd-utils/1:2.1.2-0.1 [NMU] -- Memory Technology Device Utilities
On Sun, Sep 20, 2020 at 04:56:06PM +0200, Bastian Germann wrote: > On Sat, 19 Sep 2020 17:09:47 +0200 Tobias Frost wrote: > > On Sat, 19 Sep 2020 16:50:19 +0200 Bastian Germann > > > > As said, you should bundle efforts. > > If there is no reaction, you can try to follow the ITS process [2]. > > > > [1] according to tracker.d.o: > > [2020-07-06] Accepted mtd-utils 1:2.1.1-1.1 (source arm64) into unstable, > > unstable (Debian FTP Masters) (signed by: Riku Voipio) > > > > [2] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > Riku is on the LowThresholdNmu list so I guess a NMU is the better way > forward. Well, a NMU limits what you can do significantly. For this RFS this would would mean need to create a stripped down version of the work you done already; It can only fix bugs of RC and important severities. But if it is not sponsored within a week or two I might got the > salvaging route. OK. But note that the ITS takes a while, due to the mandatory waiting time of 21 days. So I would start if right away if you can imagine to be the new maintainer. NMUs can be still be done if that yields nothing. (And NMUs are not a sustainable way to maintain a package.) -- tobi
Bug#942884: RFS: zipios/2.2.5.0-1 -- small C++ library for reading zip files
On Sun, Sep 20, 2020 at 05:08:02PM +0200, François Mazen wrote: > Hello Tobias, > > > > > my 2 cents say keep the old name, but see what I've written above. > > > > thanks for your time explaining the reasons to keep the old package > name. So I'll restart the version 2 packaging with the zipios++ package > name, and I'll drop the renaming process. > > Could you please create a zipios++ repository under debian group on > salsa and grant me right to commit? Done. Albeith the repos name is zipios, as gitlab said "nooo" to the ++-suffix. > Best Regards, > François > > >
Bug#970352: unprivileged podman dies with gibberish
Control: tag -1 upstream On Sun, Sep 20, 2020 at 9:28 AM Harald Dunkel wrote: > I think there is a misunderstanding: The problem is not the error, > but the error *message*. Can you do without complaining about bad > HTTP code and URLs that don't work? Surely they don't give a hint > about what is wrong. They are just distracting. > > That was not clear to me from the initial description. In any case, I think the most efficient way to resolve this is to ask upstream. May I ask you to file an upstream report at https://github.com/containers/podman/issues/new ? I could do so on your behalf, but it'd be more efficient if you could do so yourself. Let me know how you prefer to proceed. -- regards, Reinhard
Bug#947384: ipmitool: conffile not removed: /etc/default/ipmievd
Package: ipmitool Version: 1.8.18-10 Followup-For: Bug #947384 This issue is still present in the latest version. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#970636: tracker: conffile not removed: /etc/xdg/autostart/tracker-store.desktop
Package: tracker
Version: 2.3.6-2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb
This bug report brought to you by adequate:
https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
$ p=tracker ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep obsolete
tracker: obsolete-conffile /etc/xdg/autostart/tracker-store.desktop
/etc/xdg/autostart/tracker-store.desktop cf31b8529014a032ed5715e08e7ae5cc
obsolete
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tracker depends on:
ii dbus-user-session [default-dbus-session-bus] 1.12.20-1
ii dbus-x11 [dbus-session-bus] 1.12.20-1
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1
ii libc6 2.31-3
ii libglib2.0-0 2.66.0-2
ii libglib2.0-bin2.66.0-2
ii libicu67 67.1-4
ii libsqlite3-0 3.33.0-1
ii libstemmer0d 2.0.0-2
ii libtracker-control-2.0-0 2.3.6-2
ii libtracker-sparql-2.0-0 2.3.6-2
ii shared-mime-info 1.15-1
Versions of packages tracker recommends:
ii tracker-miner-fs 2.3.3-2+b1
tracker suggests no packages.
-- no debconf information
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#970462: [RFS] Bug#970462: sweed: autopkgtest arm64 failure
Hi, On Sun, 20 Sep 2020 at 20:34, Étienne Mollier wrote: > Control: tags -1 pending > > Greetings, > > I tried to investigate the issue of running SweeD autopkgtests > on arm64. It turned out to be caused by the assumption that the > "char" type was "signed" by default, while it is "unsigned" by > default at least on arm64. The patch I added makes several > targeted changes, so that the test suite goes through without > either crashing (segfault) or hanging (infinite loop). > > I also tried to ensure test results were unchanged compared to > other CPU architectures, and as far as I could see, they the > same on arm64 (with the patch) and on amd64 (without the patch). > > Changes are available on Salsa for review: > > https://salsa.debian.org/med-team/sweed > > Thanks Paul for having reported the issue, and Thanks Nilesh for > having written the test suite that allowed to catch the bug! :) > Thanks a lot! Uploaded! Kind Regards Nilesh
Bug#942884: RFS: zipios/2.2.5.0-1 -- small C++ library for reading zip files
Hello Tobias, > > my 2 cents say keep the old name, but see what I've written above. > thanks for your time explaining the reasons to keep the old package name. So I'll restart the version 2 packaging with the zipios++ package name, and I'll drop the renaming process. Could you please create a zipios++ repository under debian group on salsa and grant me right to commit? Best Regards, François
Bug#970635: moosic: not Python-3-compatible, so due for removal
Package: moosic
Version: 1.5.6-1
Severity: normal
Tags: patch upstream
Dear Maintainer,
moosic was written in Python 2, which is due for removal from Debian. A
recent dist-upgrade against testing on my system wanted to remove it in
order to upgrade other packages.
The original moosic upstream seems not to have been active since 2011,
so there's little chance of this getting fixed there. (I seem to recall
that the author may have moved on to xmms2.) I have not reached out to
said upstream about this; it's possible that doing so might be fruitful,
but I would not expect it.
With a bit of work, I've been able to update the source from the latest
upstream release (1.5.6) so that it runs fine with the python3
interpreter. I haven't patched the shebang lines or updated the version
number, et cetera, in part because I'm not sure of the right way to
handle things in those regards. The bulk of the changes came from 2to3,
but a lot of things still had to be fixed by hand after that conversion.
The attached patch should both get this working with Python 3, except
for things like adjusting shebang lines and so forth, and fix at least
one upstream bug (the form of the 'pl-insert' command which included an
index specification didn't work). I haven't touched the Debian packaging
aspect, since I'm not sure of how best to handle that either and I also
don't want to step on any maintainer toes.
In the absence of an active upstream, please consider applying this for
Debian and updating the packaging accordingly, as an alternative to
letting the package be removed.
I've tested all aspects of program behavior that I can think of (that
being how I noticed the pl-insert bug), and the only issue that I'm
aware of is that this seems to come with a performance reduction. With
the Python 2 version that's live on my system, moosic commands like
'stop' or 'pause' seem to take effect in typically well under a second;
with the Python 3 version, I've seen times ranging from 1-2 seconds at
the low end all the way up to 5+ seconds (if not more) at the high end.
I only have a couple ideas about what might be causing this, and none of
them are fixable without extensive surgery on the program, if at all;
even if such surgery might be warranted, I would hope that it could hold
off until a later point, in favor of getting this working and avoiding
removal.
Please don't hesitate to let me know about any problems related to the
patch. I'm not really comfortable with the idea of trying to take over
as upstream (not least because I don't really know Python), but I'm
willing to do what work I can to keep this available in Debian.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages moosic depends on:
ii python 2.7.17-2
ii python2.7 2.7.18-1
Versions of packages moosic recommends:
ii mpg321 0.3.2-3.1
Versions of packages moosic suggests:
ii mikmod3.2.8-3
ii sox 14.4.2+git20190427-2
ii timidity 2.14.0-8
ii vorbis-tools 1.4.0-11
-- no debconf information
--
Andrew J. Buehler
diff --git a/moosic/client/cli/dispatcher.py b/moosic/client/cli/dispatcher.py
index 99009c3..0725790 100644
--- a/moosic/client/cli/dispatcher.py
+++ b/moosic/client/cli/dispatcher.py
@@ -29,7 +29,7 @@
__all__ = ("dispatcher", "command_categories", "get_command_docs", "check_args")
import base64, fileinput, sys, os, os.path, time, re
-import xmlrpclib, random, errno, string
+import xmlrpc.client, random, errno, string
from moosic.utilities import *
from moosic.client.factory import startServer
@@ -47,12 +47,6 @@ except ImportError:
def call_find(dir):
return os.popen('find "%s" -follow -type f -print' % sh_escape(dir)).readlines()
-# Define the True and False constants if they don't already exist.
-try: True
-except NameError: True = 1
-try: False
-except NameError: False = 0
-
command_categories = {
"add":"Adding to the song queue",
"remove":"Removing from the song queue",
@@ -115,47 +109,40 @@ def check_args(command, arglist):
# Check the number of arguments given to the command.
if dispatcher[command].num_args not in ("zero", "zero_or_one", "zero_or_many"):
if not arglist:
-print >>err, \
-'Error: the "%s" command requires at least one argument.' % command
+print('Error: the "%s" command requires at least one argument.' % command, file=err)
return False
if dispatcher[command].num_args == "zero":
if arglist:
-print >>err, \
-'Warning: the "%s" command
Bug#970634: linux-image-5.8.0-1-arm64: Kernel image misaligned at boot on raspi 4B
Package: src:linux Version: 5.8.7-1 Severity: minor Dear Maintainer, With a recent SD card image from raspi.debian.net, running on Raspberry Pi 4B 8GB (board revision 1.4), I see Sep 14 15:04:42 rpi4-20200909 kernel: [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader! I have no functional problem, though. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.8.0-1-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 (2020-09-05) ** Command line: video=HDMI-A-1:3840x2160M@30,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 dma.dmachans=0x71f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 console=ttyS1,115200 root=/dev/mmcblk1p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 rootwait ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [ 35.811564] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dxsettings-autostart.service, startup phases are not supported. [ 35.831413] systemd-xdg-autostart-generator[1975]: kde-systemd-start-condition not found: No such file or directory [ 35.844863] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dscreensaver\x2dproxy-autostart.service, startup phases are not supported. [ 35.865776] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dcolor-autostart.service, startup phases are not supported. [ 35.885280] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.PrintNotifications-autostart.service, startup phases are not supported. [ 35.910138] systemd-xdg-autostart-generator[1975]: gnome-systemd-autostart-condition not found: No such file or directory [ 35.923850] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Wwan-autostart.service, startup phases are not supported. [ 35.942947] systemd-xdg-autostart-generator[1975]: gnome-systemd-autostart-condition not found: No such file or directory [ 35.957811] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.ScreensaverProxy-autostart.service, startup phases are not supported. [ 35.977740] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-gnome\x2dkeyring\x2dsecrets-autostart.service, startup phases are not supported. [ 35.996632] systemd-xdg-autostart-generator[1975]: kde-systemd-start-condition not found: No such file or directory [ 36.010080] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-xfce4\x2dclipman\x2dplugin\x2dautostart-autostart.service, it is hidden. [ 36.032819] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dxrandr-autostart.service, startup phases are not supported. [ 36.052914] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-pulseaudio-autostart.service, startup phases are not supported. [ 36.070574] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dmouse-autostart.service, startup phases are not supported. [ 36.090536] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-at\x2dspi\x2ddbus\x2dbus-autostart.service, startup phases are not supported. [ 36.109234] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-gnome\x2dkeyring\x2dssh-autostart.service, startup phases are not supported. [ 36.127828] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Color-autostart.service, startup phases are not supported. [ 36.151803] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Keyboard-autostart.service, startup phases are not supported. [ 36.171779] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2da11y\x2dkeyboard-autostart.service, startup phases are not supported. [ 36.193418] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Power-autostart.service, startup phases are not supported. [ 36.212906] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Sound-autostart.service, startup phases
Bug#970462: [RFS] Bug#970462: sweed: autopkgtest arm64 failure
Control: tags -1 pending Greetings, I tried to investigate the issue of running SweeD autopkgtests on arm64. It turned out to be caused by the assumption that the "char" type was "signed" by default, while it is "unsigned" by default at least on arm64. The patch I added makes several targeted changes, so that the test suite goes through without either crashing (segfault) or hanging (infinite loop). I also tried to ensure test results were unchanged compared to other CPU architectures, and as far as I could see, they the same on arm64 (with the patch) and on amd64 (without the patch). Changes are available on Salsa for review: https://salsa.debian.org/med-team/sweed Thanks Paul for having reported the issue, and Thanks Nilesh for having written the test suite that allowed to catch the bug! :) Kind Regards, -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 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#969918: RFS: mtd-utils/1:2.1.2-0.1 [NMU] -- Memory Technology Device Utilities
On Sat, 19 Sep 2020 17:09:47 +0200 Tobias Frost wrote: > On Sat, 19 Sep 2020 16:50:19 +0200 Bastian Germann > > wrote: > ... > > Unfortunately, Riku did not respond to any of the referenced bugs, all > > of which are reported for quite some time. > > > OK. Seems to be a strange case. He sponsored your last NMU [1] and you hadn't > have a conversation? No, he just apologized for being unresponsive and uploaded it. > As said, you should bundle efforts. > If there is no reaction, you can try to follow the ITS process [2]. > > [1] according to tracker.d.o: > [2020-07-06] Accepted mtd-utils 1:2.1.1-1.1 (source arm64) into unstable, > unstable (Debian FTP Masters) (signed by: Riku Voipio) > > [2] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging Riku is on the LowThresholdNmu list so I guess a NMU is the better way forward. But if it is not sponsored within a week or two I might got the salvaging route.
Bug#632438: [Popcon-developers] Bug#681721: #632438: popularity-contest: a way to exclude certain packages
On Sun, 2020-09-20 at 11:04 +0200, Bill Allombert wrote: > Could you explain why you want to exclude some package ? Personally I'm excluding packages created by mk-build-deps as well as the metapackages I create for my own systems, using a simple `grep -v` in the popcon submission cron job. The patch posted by Kentaro is not sufficient for my use-case, which relies on excluding packages via regex instead of full package name. > Instead I would suggest to add a new dpkg control field 'X-Popcon: > private' and have popularity-contest skip packages having this field. This isn't going to be useful for users who want to exclude packages from repos that they do not control or packages built by mk-build-deps or other tools that do not allow adding extra dpkg control fields. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#969739: Segmentation fault on startup
Hi, This isn't a conventional setup, which is why dbus isn't there, there's no input, as I only need the output. The more unconventional part is that I'm running X11 within a docker container. As I said, this works with an older version, specifically, on the same host, a different container with 2:1.20.7-2 works. Not sure what you're looking for in the kernel logs, nothing happens when it fails to start. I'm attaching the boot sequence logs. Let me know what else you need, thanks. On Thu, Sep 17, 2020 at 9:03 AM Julien Cristau wrote: > Control: severity -1 important > Control: tag -1 moreinfo > > On Mon, Sep 07, 2020 at 11:59:34AM -0400, Christophe Kalt wrote: > > Package: xserver-xorg-core > > Version: 2:1.20.9-1 > > Severity: grave > > > > Same setup was working with 2:1.20.7-2, but with 2:1.20.9-1 crashes on > startup > > (xinit). /var/log/Xorg.0.log follows: > > > There's a number of things going wrong here... > > [...] > > [881147.372] (EE) dbus-core: error connecting to system bus: > > org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket > /run/dbus/ > > system_bus_socket: No such file or directory) > > That's not good for input but probably doesn't explain the crash in > InitOutput. > > [...] > > [881147.372] (II) xfree86: Adding drm device (/dev/dri/card0) > > [881147.372] (II) Platform probe for > /sys/devices/pci:00/:00:02.0/drm/ > > card0 > > [881147.377] (--) PCI:*(0@0:2:0) 8086:3ea5:8086:2074 rev 1, Mem @ > 0x604b00/ > > 16777216, 0x40/134217728, I/O @ 0x4000/64, BIOS @ > 0x/131072 > > That's Intel "Iris Plus Graphics 655". > > [...] > > [881147.426] (II) modeset(G0): using drv /dev/dri/card0 > > [881147.427] (II) modeset(0): Creating default Display subsection in > Screen > > section > > "Default Screen Section" for depth/fbbpp 24/32 > > [881147.427] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 > > [881147.427] (EE) > > [881147.427] (EE) Backtrace: > > [881147.428] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135) > [0x557662d21f35] > > [881147.429] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 > (funlockfile+0x50) > > [0x7f3bb952318f] > > [881147.430] (EE) 2: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x5c0) > > [0x557662c1a2b0] > > [881147.430] (EE) 3: /usr/lib/xorg/Xorg (xf86CollectOptions+0x77) > > [0x557662bfd197] > > [881147.431] (EE) unw_get_proc_name failed: no unwind info found [-10] > > [881147.431] (EE) 4: /usr/lib/xorg/modules/drivers/modesetting_drv.so > (?+0x0) > > [0x7f3bb8a25940] > > [881147.432] (EE) 5: /usr/lib/xorg/Xorg (InitOutput+0x9ae) > [0x557662c0085e] > > [881147.433] (EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x1cc) > [0x557662bc235c] > > [881147.434] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 > (__libc_start_main+0xea) > > [0x7f3bb936ecca] > > [881147.434] (EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x557662babc9a] > > [881147.434] (EE) > > [881147.435] (EE) Segmentation fault at address 0x124 > > [881147.435] (EE) > > Fatal server error: > > [881147.435] (EE) Caught signal 11 (Segmentation fault). Server aborting > > [881147.435] (EE) > > [881147.435] (EE) > > Please consult the The X.Org Foundation support > > at http://wiki.x.org > > for help. > > [881147.435] (EE) Please also check the log file at > "/var/log/Xorg.0.log" for > > additional information. > > [881147.435] (EE) > > [881147.467] (EE) Server terminated with error (1). Closing log file. > > Any details you can provide as to the setup and how you're starting Xorg? > > Please also provide a kernel log. > > Cheers, > Julien > [0.00] Linux version 5.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 (2020-09-05) [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/vg0-root ro [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x7bcdefff] usable [0.00] BIOS-e820: [mem 0x7bcdf000-0x7c149fff] reserved [0.00] BIOS-e820: [mem 0x7c14a000-0x7c1c6fff] ACPI data [0.00] BIOS-e820: [mem
Bug#970630: [Pkg-javascript-devel] Bug#970630: nodejs in backports
Quoting Jérémy Lal (2020-09-20 15:27:41) > Le dim. 20 sept. 2020 à 15:04, Kurt Roeckx a écrit : > > > On Sun, Sep 20, 2020 at 02:36:44PM +0200, Jérémy Lal wrote: > > > Le dim. 20 sept. 2020 à 12:00, Kurt Roeckx a écrit : > > > > > > > Package: nodejs > > > > Severity: wishlist > > > > > > > > Hi, > > > > > > > > Would it be possible to get a newer version of nodejs in > > > > buster-backports? > > > > > > > > > > 10.x or 12.x branch ? > > > > The 12.x branch > > > If it's okay to use some of the dependencies present in nodejs source > tarball, > it might be possible. Well, firefox-esr routinely switch to using embedded code copies when targeted stable (and older), so if ok for stable I guess it is acceptable for backports as well. Just make sure to mention any such changes in changelog. > Also installing nodejs 12 on buster will break some packages that only > work with nodejs 10.x. I don't know how to deal with that. You could add "Breaks:". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#970620: Subject: RFS: libwcat1/1.1-3 [ITA] -- Process monitoring library
Control: tags -1 - moreinfo
Hello Tobias,
> - d/copyright: 1) I saw that you say "GPL-2+" for the debian/* files,
but I am
> not sure where you got that from. AFAICS it was not specified in the old
> package. Can you explain where you got it from?
> 2) It would be better when the debian license would match upsteam, so
that
> patches can be more easily integrated there.
To be honest, I chose the license based on examples from other packaged
libraries. These files was unlicensed, so I had to chose something.
I fully agree, it will be more convenient to set LGPL2.1+, if it is
possible.
I changed the license to LGPL2.1 now. If Cyril says, I'll update it again.
> - The package needs to be adapted for multiarch: It needs to install the
> shared libaries to /usr/lib/${DEB_HOST_MULTIARCH}/
Done.
> (not a requirement for upload of this package:
> The library package has also a companion tool package: watchcatd [1].
> It is also orphaned. Would you mind adopting this too?)
Interesting. I'll take this package after I finish working on this one.
> PS: I've updated the subject and force-merged the old bug.
> Please note that it is customary NOT to open up a new RFS on the same
package
> until it has been sponsored. In this case you'd reopen only the old
one. Please
> keep that in mind for future iterations. You can avoid that the bug
is auto-
> closed by just uploading the new version to mentors; there should be
no need to
> delete the old one before.
Sorry, I make a mistake when updating my package in mentors.debian.net
for the first time. I already figured out how it works, thanks for the
explanation.
--
Best regards,
Georgy Komarov
Bug#856393: affected from this too
Hi, is there any new state? i see these message too with buster 5x. needs some time me to figure out that it is caused by cgroups (and maybe lxcfs). any way to trigger/debug/fix? regards Frank
Bug#969425: r-cran-cubelyr_1.0.0-1_amd64.changes REJECTED
Hmmm, I think that text is incorrect — NASA is a US federal agency and hence in the public domain (https://en.wikipedia.org/wiki/Copyright_status_of_works_by_the_federal_government_of_the_United_States). Not to mention that data isn't copyrightable in the US, anyway. Hadley On Sun, Sep 20, 2020 at 3:01 AM Andreas Tille wrote: > > Hi Hadley, > > I'm about to package cubelyr for Debian. Our ftpmaster was asking for > explicite copyright statement of the data imported from NASA. As far as > I know NASA is issuing data under public domain but I can not find any > explicite statement inside your download tarball. Could you please > clarify this? > > Kind regards > > Andreas. > > On Thu, Sep 17, 2020 at 09:00:09PM +, Thorsten Alteholz wrote: > > > > Hi Andreas, > > > > some note in the files imported from NASA says: "see important copyright > > terms below" > > But what are these copyright terms? > > > > Thorsten > > > > > > > > > > === > > > > Please feel free to respond to this email if you don't understand why > > your files were rejected, or if you upload new files which address our > > concerns. > > > > > > ___ > > R-pkg-team mailing list > > r-pkg-t...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team > > -- > http://fam-tille.de -- http://hadley.nz
Bug#967808: gtkgl2: appears to be unmaintained upstream
Package: src:gtkgl2 Followup-For: Bug #967808 Just in case it helps taking a decision: as author of the recent NMUs, I support the removal.
Bug#970471: [pkg-crosswire-devel] Bug#970471: Possible ways to resolve
Am 20.09.20 um 12:35 schrieb Teus Benschop: > The error message in this bug report is an unusual one. > > I managed to find one other similar report on Google, which was in Chinese. > > Possible solutions I could think of are these two. > > 1. If the error is temporary, to upload a new package that would trigger a > rebuild. > > 2. To ask the FTP Masters to remove the previously build for this > architecture, so the remaining architectures can move to testing. > > Perhaps there are more possible solutions others may think of? I do not think that 2 is a good idea. The idea of the migrating checks is that a build for each of the official architectures is available at testing. Even if the mips64el build is removed, they will not migrate.
Bug#970352: unprivileged podman dies with gibberish
On 9/15/20 5:05 PM, Reinhard Tartler wrote: I think this is the relevant error message. May I ask a couple of questions: 1. Did this work with an earlier verison of podman, i.e., is this a regression? What version worked for you before? No, I didn't try an earlier version of podman. I just found out that there is a native podman available. 2. Does the problem go away after a reboot? No. 3. Does the command 'unshare -nr id' work for you? Yes: % unshare -nr id uid=0(root) gid=0(root) groups=0(root),65534(nogroup) % id -a uid=1000(harri) gid=1000(harri) groups=1000(harri),4(adm),6(disk),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),44(video),46(plugdev),50(staff),107(haldaemon),108(powerdev),111(mythtv),112(netdev),119(kvm),123(wireshark),124(fuse),136(sbuild),999(docker) And no, docker is not installed. It was. 4. Did you read the file /usr/share/doc/podman/README.Debian, in particular the parts "User Namespaces" and "Troubleshooting rootless mode"? I did, but they are no help. I don't run a Debian kernel, i.e. there is no sysctl kernel.unprivileged_userns_clone to be set. CONFIG_USER_NS is enabled. And AFAIR it is common practice to define default subuid and subgid ranges as a fallback (at least for Docker). I think there is a misunderstanding: The problem is not the error, but the error *message*. Can you do without complaining about bad HTTP code and URLs that don't work? Surely they don't give a hint about what is wrong. They are just distracting. Thanx very much Harri
Bug#970633: tt-rss: CVE-2020-25787 CVE-2020-25788 CVE-2020-25789
Source: tt-rss Version: 19.8+dfsg-1 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerabilities were published for tt-rss. CVE-2020-25787[0]: | An issue was discovered in Tiny Tiny RSS (aka tt-rss) before | 2020-09-16. It does not validate all URLs before requesting them. CVE-2020-25788[1]: | An issue was discovered in Tiny Tiny RSS (aka tt-rss) before | 2020-09-16. imgproxy in plugins/af_proxy_http/init.php mishandles | $_REQUEST["url"] in an error message. CVE-2020-25789[2]: | An issue was discovered in Tiny Tiny RSS (aka tt-rss) before | 2020-09-16. The cached_url feature mishandles JavaScript inside an SVG | document. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-25787 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25787 [1] https://security-tracker.debian.org/tracker/CVE-2020-25788 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25788 [2] https://security-tracker.debian.org/tracker/CVE-2020-25789 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25789 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#970632: nmu: util-linux_2.36-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu util-linux doesn't know about the new capabilities from Linux 5.8 yet, e.g.: % setpriv --bounding-set -all echo test setpriv: libcap-ng is too old for "all" caps The problem is not actually libcap-ng but util-linux having picked up an old CAP_LAST_CAP when it was built. Rebuilding against linux-libc-dev 5.8 fixes this: nmu util-linux_2.36-3 . linux-any . unstable . -m "Rebuild against linux-libc-dev >= 5.8 to pick up new capabilities" --extra-depends 'linux-libc-dev (>= 5.8)' (not sure if linux-any is supported here)
Bug#970630: nodejs in backports
Le dim. 20 sept. 2020 à 15:04, Kurt Roeckx a écrit : > On Sun, Sep 20, 2020 at 02:36:44PM +0200, Jérémy Lal wrote: > > Le dim. 20 sept. 2020 à 12:00, Kurt Roeckx a écrit : > > > > > Package: nodejs > > > Severity: wishlist > > > > > > Hi, > > > > > > Would it be possible to get a newer version of nodejs in > > > buster-backports? > > > > > > > 10.x or 12.x branch ? > > The 12.x branch If it's okay to use some of the dependencies present in nodejs source tarball, it might be possible. The buster versions of libuv1 and icu are not right though and are going to require more work. For instance some new functionnalities of nodejs 12 rely on icu 64 at least. Also installing nodejs 12 on buster will break some packages that only work with nodejs 10.x. I don't know how to deal with that. Jérémy
