Bug#656060: logrotate: drop compress option
retitle Move de facto "compress" default into logrotate.conf submitter 656060 ! On Wed, 22 Aug 2018 15:24:18 +0200 Christian Göttsche wrote: > I think extX is still the default for filesystems. So the compress > option makes sense in the general case. The request here is to: 1. Enable "compress" in logrotate.conf. 2. (Request that maintainers and/or NMU to) Drop "compress" in package's /etc/logrotate.d/* files. Thus, compression would still be enabled by default. But this gives users a _single_ place to toggle this globally, rather than needing to toggle it in every package's /etc/logrotate.d/* configuration file. The user might want to disable log compression for any number of reasons; some examples being: A) They have a filesystem doing copy-on-write snapshots. B) They have tons of disk space and don't need the compression. C) They want to make it easier to grep the files. In the Root-on-ZFS HOWTOs that I maintain, I recommend people turn it off for reason A. At $DAYJOB, we use ext4 but turn off log compression for reason C (and the implied B). > p.s.: @Richard Laager: I quite did not get the point with the snapshots. 1. Write a log file to disk. Let's say that's 10 MB. It takes up 10 MB on disk. 2. Take a snapshot. With copy-on-write, this takes no new space. 3. Compress the log file. Let's say the compressed version takes 1 MB. On a traditional filesystem, step 3 wrote 1 MB but freed 10 MB, for a net savings of 9 MB. On a copy-on-write filesystem with snapshots, step 3 wrote 1 MB and freed 0 MB (as the original uncompressed file exists in one or more snapshots), for a net _cost_ of 1 MB. This is the exact opposite of the goal of enabling compression. -- Richard
Bug#968194: Upgrade to getmail6 which uses python3
Please use new upstream https://github.com/getmail6 release. It uses python3. Without upgrading, the getmail package is no longer installable on sid.
Bug#968009: Warn that there is no point of installing this package if using systemd
Am 13.08.20 um 00:42 schrieb 積丹尼 Dan Jacobson: > MB> I don't think this is correct. Afaik, resolvconf has always been > MB> optional and was never installed by default in Debian. > > https://en.wikipedia.org/wiki/Resolvconf > > Yes, optional, unless one wanted to use the Internet... > Also not true. You don't need (and never needed) resolvconf if you want to use the internet. My suggestion would be, that you read up on what resolvconf actually does and then you decide if you want/need its functionality. Michael signature.asc Description: OpenPGP digital signature
Bug#968330: Errors building gtk+3.0-3.22.30 from source using debuild on ubuntu 18.04
Package: gtk+3.0 Version: 3.22.30 I am trying to accomplish the follwoing: apt-get source gtk+3.0 cd gtk+3.0-3.22.30 debuild -uc -us I have run build-dep and have installed dependencies. When I run the build it displays the following errors: make check-local Makefile:723: recipe for target 'check-recursive' failed make[2]: *** [check-recursive] Error 1 make[2]: Target 'check' not remade because of errors. dh_auto_test: cd debian/build/deb && make -j2 -O check VERBOSE=1 -k check -j1 returned exit code 2 debian/rules:177: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 25 make[1]: Leaving directory '/home/brad/build/gtk+3.0-3.22.30' debian/rules:134: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 debuild: fatal error at line 1152: dpkg-buildpackage -rfakeroot -us -uc -ui failed When I invoke `hello' without arguments from an ordinary shell prompt it prints `goodbye', rather than the expected `hello, world'. Here is a transcript: $ hello goodbye $ /usr/bin/hello goodbye $ I suggest that the output string, in hello.c, be corrected. I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13 and libc6 2.1.3-10.
Bug#968295: additional content - what may of caused the issue
I found the following notes which may explain what caused this: I installed pdftk per below (included the messages which were received and my response, left out some usual context as im typing this on mobile) sudo apt-get install pdftk You might want to run 'apt--fix-broken install' to correct these. The following packages have unmet dependencies: cryptsetup-run : depends: cryptsetup-bin (>=2:1.6.0) but it is not going to be installed pdftk: depends: pdftk-java but it is not going to be installed E: unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). so i ran sudo apt --fix-broken install returned: The following additional pakcages will be installed: cryptsetup-bin The following NEW packages will be installed cryptsetup-bin 0 upgraded, 1 newly installed, 0 to remove and 46 not upgraded. Need to get 303Kb of archives. After this operation 1,514kB of additional disk space will be used. do you want to continue? Y Get:1 downloaded /debian buster/main amd64/cryptsetup-bin (cryptsetup-bin_2%3a2.1.0-5+deb10u2_amd64.deb ... unpacked... set up processing triggers for libc-bin (2.28-10)... Processing triggers for man-db (2.8.5-2)... processing triggers for initramfs-tools (0.133+deb10u1)... Update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64 Then my notes took me into installing pdftk, which included installing and configuring pdftk-java and pdftk_2.02-5_amd64.deb and process triggers for man-db. still given the above im rather novice and unsure what needs to be done to fix it...
Bug#961300: New upstream available
Control: retitle -1 thinkfan: New upstream available (1.2.1) On Fri, 22 May 2020 23:45:39 +0200 Lee Garrett wrote: > upstream has released 1.1 of thinkfan last month, and it would be great to > package it for Debian, as it fixes the issue of changing hwmon names between > reboots. There have been a couple of new releases since then. https://github.com/vmatare/thinkfan/releases I think one of the releases might even fix the GCC 10 FTBFS. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#968231: global: does not index definitions with pygments anymore
On Wed, Aug 12, 2020 at 7:18 AM Punit Agrawal wrote: [...] > I will look into this (hopefully later today) and look for a way to > fix the regression. I looked into this some more and have a somewhat better understanding of the issue - * When used, pygments only provide reference tags (GRTAGS) not definition tags * The definitions were provided by /usr/bin/ctags (in 6.4.4-3). "ctags" is usually a symlink pointing to one of few possible ctags implementations - ctags.emacs, exuberant-ctags, universal-ctags the ones I've come across. * The pygments plugin script (/usr/share/global/gtags/script) has a dependency on exuberant ctags but may also be able compatible with other ctags implementations. It is possible to override this by using "ctagscom=" in the config file. Looking at these, the changes introduced in 6.4.4-4 seem to be headed in the right direction. Users not wanting to install exuberant-ctags can update the config file to use "ctagscom=" in the pygments fragment to point global to their preferred "ctags" implementation. This may lead to compatibility issues in some situation. I will look to improve the messages in the pygments plugin when exuberant-ctags binary is not detected in the system. Let me know if you have any other suggestions. Thanks, Punit
Bug#967917: Fix for unit file
Also seeing this problem. The issue can be fixed by editing the unit file. In the [Service] section, edit the ExecStart line so that it reads: ExecStart=/bin/true You'll then need to run: sudo systemctl daemon-reload sudo systemctl restart blk-availability.service to reload the unit file. Cheers, Aaron
Bug#968329: gbp import-orig should strip +dfsg, etc. for upstream-vcs-tag
Package: src:git-buildpackage
Version: 0.9.20
Severity: wishlist
Tags: patch
Feature request:
`gbp import-orig` should strip [~+](dfsg|ds).* or even [~+].* from the
upstream version (only) when calculating the upstream-vcs-tag.
Details:
I'm trying to get `gbp import-orig --uscan` working with a variant of
the repack-waf script from: https://wiki.debian.org/UnpackWaf
The example here is NTPsec 1.1.9.
The stock repack-waf script takes an input orig tarball of "1.1.9" and
outputs an orig tarball of "1.1.9+dfsg1". Unfortunately, in this state,
uscan is not aware that the tarball was repacked, so neither is `gbp
import-orig`. gbp gets the version from the tarball name, which it gets
from the element in the `uscan --dehs` output.
If I add oversionmangle=s/$/+dfsg1/ to the opts in debian/watch, then
uscan is aware that the output will be 1.1.9+dfsg1. This seems like the
correct thing to do from uscan's perspective, as its man page says
oversionmangle "should be used to add a suffix such as +dfsg1".
However, uscan will also symlink the upstream orig tarball with that
name, so the stock repack-waf script breaks. That can easily be
addressed by changing repack-waf to use the 1.1.9+dfsg1 name as both
input and output, which I have done.
In that configuration, gbp gets the upstream version of 1.1.9+dfsg1.
This leads to tag names like upstream/1.1.9+dfsg1, which is what I have
been using so far. DEP-14 isn't clear whether it should be
upstream/1.1.9+dfsg1 or upstream/1.1.9. However, DEP-14 does
contemplate that "The upstream/ tag would be created by the
package maintainer when needed: for example when
it does a release based on a Git snapshot". So those tags are not
expected to correspond exactly with upstream's tags. I think they
should be the "Debian upstream version", so 1.1.9+dfsg1 is correct.
Further, in bug #546598, Charles Plessy suggested
that `gbp import-orig --filter` should automatically add "~dfsg":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546598 That bug was
from 2009. Today, plessy seems to use +dfsg.1, +ds-1, and +dfsg-1
suffixes. More importantly than those minor differences in suffix
style, some of those packages currently have numbers greater than 1.
That to me shows that stripping the +dfsg1 to get just upstream/1.1.9
would be inappropriate, as that would not scale to +dfsg2 and beyond.
This is further evidence that upstream/1.1.9+dfsg1 is correct.
However, that still leaves one problem. The --upstream-vcs-tag tag
format only allows for one substitution which has to be a single
character substitution. There is no way to strip the +dfsg1. In my
case, I want to get to the NTPsec_1_1_9 format that upstream uses by
using: upstream-vcs-tag = NTPsec_%(version%.%_)s
I ran some queries against UDD to find various patterns. Based on that,
the attached patch series implements this and a bunch more. With this
change, I was able to import version 1.1.9 of NTPsec using:
gbp import-orig --uscan --upstream-vcs-tag="NTPsec_%(version%.%_)s"
The first patch is just a typo fix to a comment nearby. It's unrelated
to this change.
The second two patches are refactoring changes. Those can be squashed
together or into the last change, if you prefer. I included them to show
the refactoring steps individually, in case that helps you review this.
The third change is the meat of this. I have doctests, but I'm not sure
if those are automatically run or how I integrate them into the
git-buildpackage tests. I'm also not sure about the function name for
_upstream_version_from_debian_upstream(). In a previous version, I
called it _mangle_upstream_version().
--
Richard
From 7cc1195bac48833fa551102a114d943be2cc006b Mon Sep 17 00:00:00 2001
From: Richard Laager
Date: Wed, 12 Aug 2020 21:54:06 -0500
Subject: [PATCH 1/4] import-orig: Fix a comment typo
---
gbp/deb/git.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gbp/deb/git.py b/gbp/deb/git.py
index 596c9ff..4b52122 100644
--- a/gbp/deb/git.py
+++ b/gbp/deb/git.py
@@ -171,7 +171,7 @@ class DebianGitRepository(PkgGitRepository):
@classmethod
def _mangle_version(cls, format, version):
"""
-Basic version mangling to replce single characters
+Basic version mangling to replace single characters
>>> DebianGitRepository._mangle_version(r'%(version%-%\\%)s', "0-1.2.3")
('%(version)s', '0%1.2.3')
--
2.28.0
From 37904cdda6d4b1de4602bbf3e98baa8bb5ace42d Mon Sep 17 00:00:00 2001
From: Richard Laager
Date: Wed, 12 Aug 2020 21:58:31 -0500
Subject: [PATCH 2/4] import-orig: Refactor vcs_tag_parent
This eliminates an indentation level.
---
gbp/deb/git.py | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/gbp/deb/git.py b/gbp/deb/git.py
index 4b52122..a701589 100644
--- a/gbp/deb/git.py
+++ b/gbp/deb/git.py
@@ -375,14 +375,13 @@ class DebianGitRepository(PkgGitRepository):
def vcs_tag_parent(self, vcs_tag_format, version):
"""If
Bug#744401: snowdrop: diff for NMU 0.02b-12.1
On Wed, Aug 12, 2020 at 07:11:35PM +0200, Andreas Metzler wrote: > this bug tracks the fact that the changes in the NMU have NOT been > integrated into a maintainer upload. So it should stay open until that > has happened, afaik. > Hi Andreas, I'm not sure if I follow, but from what I see, you are worried that new maintainers will not take these NMU changes into account on the next revisions, right? I have an ITA opened and I'm working on a Debian revision of the package atm, and I have created a git repository (using gbp import-dscs --debsnap), which contains your NMU. Even if I weren't doing this revision, I think any other potential Debian contributor would be basing their work on the latest Debian revision found on the archives, which happen to be your NMU at this point, as can be seen by fetching the package sources on sid with apt source. Thus I'm not sure what the benefits are of keeping this bug open. Of course, I may be completely wrong :). So, do you think I should reopen it until I (or anyone else, for that matter) release a new Debian revision? Regards, David Polverari.
Bug#968328: transition: gloox
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a transition slot for src:gloox. This is a relatively small transition, with only 2 source packages affected (tested builds against newer gloox, currently in experimental, results are as follows): 0ad (build ok, needs binNMU) uwsgi (build ok, needs binNMU) Ben file: https://release.debian.org/transitions/html/auto-gloox.html is accurate. Regards, Vincent
Bug#968262: lintian: spare-manual-page misses .so targets
Hi Ross, On Wed, Aug 12, 2020 at 7:17 PM Ross Vandegrift wrote: > > Is that unusual or incorrect?'. I cannot answer that. From Lintian's perspective, there is no executable for the manual page, and that is how the tag works. The easiest thing would be to add an override. Alternatively, you could name the manual page after one of the utilities, but then you probably also have to change the contents to avoid 'wrong-name-for-manual-page'. You would probably end up listing the names of all utilities (although the one matching the manual page's file name is the only required). As a side note, I am not sure how helpful terminology-helpers.1 is. Why don't you just link to the main manual page terminology.1 and add a section about the helpers there? Other alternatives would be to split terminology-helper.1 into multiple files in hope that someone would get around to adding information. You could also delete terminology-helpers.1 and add overrides for each of the utilities, but that would be my least favorite option. Hope this was helpful. Kind regards Felix Lechner
Bug#318884: xfig: Xfig draws a figure 5 times on start-up
Sure, here's a video. You can see some behaviors more easily that way. https://photos.app.goo.gl/AboMENDfpf8aNGsE9 On Mon, Aug 10, 2020 at 11:29 AM Roland Rosenfeld wrote: > Hi Greg! > > On Di, 04 Aug 2020, G Kochanski wrote: > > > Well, that's a blast from the past! > > I think the originally reported problem seems to have gone away over the > > last 15 years. But there seem to be some serious X-windows bugs > remaining, > > notably some big grey areas. I've attached one of the files if you want > > to see for yourself. > > Could you please provide a screenshot of what you are talking about. > I don't notice "big grey areas" or don't understand what you mean. > > Greetings > > Roland >
Bug#968262: lintian: spare-manual-page misses .so targets
Hi Felix, On Tue, Aug 11, 2020 at 10:55:49PM -0700, Felix Lechner wrote: > On Tue, Aug 11, 2020 at 10:39 PM Ross Vandegrift > wrote: > > > > I: terminology-data: spare-manual-page > > usr/share/man/man1/terminology-helpers.1.gz > > The links are fine, but I could not find an executable named > terminology-helpers in your installation packages. Do you ship one? Nope, it's just the placeholder name that the binaries' manpages link to. Is that unusual or incorrect? I checked policy 12.1, but I didn't see anything relevant to this case. Ross
Bug#965960: AMD64 version is clean
This bug only seems to happen on x86 (i686, et. al.) 32-bit architecture. AMD64 does not exhibit this behavior.
Bug#968326: lintian no longer reading /etc/lintianrc
Package: lintian Version: 2.89.0 Severity: important X-Debbugs-Cc: eribe...@debian.org Dear Maintainer, Since 2.89.0 version, lintian no longer reads /etc/lintianrc. The manpage says the file is obsolete since Lintian/2.5.12. However the file still being provided by lintian package. Please, let me know if it is really a bug. Regards, Eriberto
Bug#367891: E-mail de l'utilisateur en ligne de Zimbra Synacor / Avis final !!
Cher utilisateur, nous mettons � jour notre installation de stockage de base de donn�es avec une nouvelle page de connexion et un meilleur serveur, d'o� la raison de la demande et de la notification. Une mise � jour automatique a �t� effectu�e sur le syst�me du serveur de s�curit� en raison d'une activit� inhabituelle qui enfreint les dispositions de notre service. Tout utilisateur de messagerie qui ne met pas � jour son compte dans les 48 heures suivant la r�ception de cette notification sera suspendu, pour �viter la suspension de son compte, veuillez cliquer ici.�
Bug#367891: E-mail de l'utilisateur en ligne de Zimbra Synacor / Avis final !!
Cher utilisateur, nous mettons � jour notre installation de stockage de base de donn�es avec une nouvelle page de connexion et un meilleur serveur, d'o� la raison de la demande et de la notification. Une mise � jour automatique a �t� effectu�e sur le syst�me du serveur de s�curit� en raison d'une activit� inhabituelle qui enfreint les dispositions de notre service. Tout utilisateur de messagerie qui ne met pas � jour son compte dans les 48 heures suivant la r�ception de cette notification sera suspendu, pour �viter la suspension de son compte, veuillez cliquer ici.�
Bug#968324: Provide /usr/bin/python
Package: python3 Version: 3.8.2-3 Some (python3) package should provide the /usr/bin/python link. No, one cannot do # aptitude install python -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64)
Bug#968323: Since conky 1.11.6-1 following error: conky: unknown variable '$tcp_portmon'
Package: conky-all
Version: 1.11.6-1
Severity: important
Tags: upstream
Works perfectly with 1.10.8-1.1, but after upgrading to 1.11.6-1, you get this
error: "conky: unknown variable '$tcp_portmon'"
(One possibility is the package maintainer forgot to build with portmon
support).
It can reproduced every time with above down/upgrade, i.e. use a simple config
like this:
conky.config = {
out_to_x = true,
};
conky.text = [[
${tcp_portmon 1 65535 rport 0}
${tcp_portmon 1 65535 rip 0}
${tcp_portmon 1 65535 count}
]]
Regards
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages conky-all depends on:
ii libaudclient2 3.5~rc2-1+b1
ii libc6 2.31-3
ii libcairo2 1.16.0-4
ii libcurl3-gnutls 7.68.0-1+b1
ii libdbus-glib-1-2 0.110-5
ii libgcc-s1 10.2.0-5
ii libglib2.0-0 2.64.4-1
ii libical3 3.0.8-2
ii libimlib2 1.6.1-2
ii libircclient1 1.9-1+b1
ii libiw30 30~pre9-13.1
ii liblua5.3-0 5.3.3-1.1+b1
ii libncurses6 6.2-1
ii libpulse0 13.0-5
ii librsvg2-22.48.7-1
ii libstdc++610.2.0-5
ii libtinfo6 6.2-1
ii libx11-6 2:1.6.10-3
ii libxdamage1 1:1.1.5-2
ii libxext6 2:1.3.3-1+b2
ii libxfixes31:5.0.3-2
ii libxft2 2.3.2-2
ii libxinerama1 2:1.1.4-2
ii libxml2 2.9.10+dfsg-5+b1
ii libxmmsclient60.8+dfsg-20
ii libxnvctrl0 450.57-1
conky-all recommends no packages.
Versions of packages conky-all suggests:
pn apcupsd
ii audacious 4.0.4-1
pn moc
pn mpd
pn xmms2
-- no debconf information
Bug#968321: ITP: prometheus-logstash-exporter -- Prometheus exporter for Logstash
Package: wnpp Severity: wishlist Owner: Martina Ferrari X-Debbugs-Cc: debian-de...@lists.debian.org, team+pkg...@tracker.debian.org * Package name: prometheus-logstash-exporter Version : 0.6.2 Upstream Author : Alexey Remizov * URL : https://gitlab.com/alxrem/prometheus-logstash-exporter * License : Apache-2.0 Programming Lang: Golang Description : Prometheus exporter for Logstash Exports Logstash metrics provided by the Node Stats API.
Bug#968009: Warn that there is no point of installing this package if using systemd
MB> I don't think this is correct. Afaik, resolvconf has always been MB> optional and was never installed by default in Debian. https://en.wikipedia.org/wiki/Resolvconf Yes, optional, unless one wanted to use the Internet...
Bug#968320: rclone: getcwd() failures with rclone mount (already fixed upstream)
Package: rclone Version: 1.50.2-3 Severity: normal Tags: upstream X-Debbugs-Cc: satw...@disjoint.net Dear Maintainer, When using rclone mount to fuse-mount a cloud filesystem, getcwd() inside the mounted filesystem frequently fails with ENOENT. This has already been fixed upstream in rclone 1.52. See https://github.com/rclone/rclone/issues/4104 for more details. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rclone depends on: ii libc6 2.31-3 rclone recommends no packages. rclone suggests no packages. -- no debconf information
Bug#965378: distcc-pump fails to start due to incorrect include_server path
Hi, I dug into this some more, and think I have a solution. The problem stems from the 01_Makefile.am.patch patch in the debian package, which has the following diff: @@ -1092,7 +1093,7 @@ install-include-server: include-server p cp -f "$(include_server_builddir)/install.log" "$(PYTHON_INSTALL_RECORD)"; \ fi; \ $(mkinstalldirs) "$(DESTDIR)$(bindir)" && \ - INCLUDE_SERVER=`grep '/include_server.py$$' "$(include_server_builddir)/install.log"` && \ + INCLUDE_SERVER="/usr/lib/distcc-pump/include_server/include_server.py" && \ sed "s,^include_server='',include_server='$$INCLUDE_SERVER'," \ pump > "$(include_server_builddir)/pump" && \ $(INSTALL_SCRIPT) "$(include_server_builddir)/pump" "$(DESTDIR)$(bindir)"; \ This is the source of the hard-coded path in the installed distcc-pump script. Removing this part of the patch and running a `make install-include-server` results in the proper path in the script (the grep still works properly). Hope this helps! Alex
Bug#968319: Don't try speech-dispatcher-festival on Ubuntu when building contrib
Package: speech-dispatcher-contrib
Version: 0.10.1-1
The Ubuntu patch applied to filter speech-dispatcher-festival from the
Ubuntu/i386 build of speech-dispatcher created an issue for the -contrib
variant. The attached patch should resolve the bug
Thanks,
diff -Nru speech-dispatcher-contrib-0.10.1/debian/changelog speech-dispatcher-contrib-0.10.1/debian/changelog
--- speech-dispatcher-contrib-0.10.1/debian/changelog 2020-08-10 01:11:53.0 +0200
+++ speech-dispatcher-contrib-0.10.1/debian/changelog 2020-08-12 23:37:23.0 +0200
@@ -1,3 +1,11 @@
+speech-dispatcher-contrib (0.10.1-2) unstable; urgency=medium
+
+ * debian/rules:
+- don't use dh_gencontrol -N on a non existant binary
+ (specific to Ubuntu)
+
+ -- Sebastien Bacher Wed, 12 Aug 2020 23:37:23 +0200
+
speech-dispatcher-contrib (0.10.1-1) unstable; urgency=medium
* New upstream release.
diff -Nru speech-dispatcher-contrib-0.10.1/debian/control speech-dispatcher-contrib-0.10.1/debian/control
--- speech-dispatcher-contrib-0.10.1/debian/control 2020-08-10 01:11:53.0 +0200
+++ speech-dispatcher-contrib-0.10.1/debian/control 2020-08-12 23:37:23.0 +0200
@@ -1,7 +1,8 @@
Source: speech-dispatcher-contrib
Section: contrib/sound
Priority: optional
-Maintainer: Debian TTS Team
+Maintainer: Ubuntu Developers
+XSBC-Original-Maintainer: Debian TTS Team
Uploaders:
Paul Gevers , Samuel Thibault
Build-Depends:
diff -Nru speech-dispatcher-contrib-0.10.1/debian/rules speech-dispatcher-contrib-0.10.1/debian/rules
--- speech-dispatcher-contrib-0.10.1/debian/rules 2020-07-24 13:55:18.0 +0200
+++ speech-dispatcher-contrib-0.10.1/debian/rules 2020-08-12 23:37:23.0 +0200
@@ -6,10 +6,12 @@
# NAS is in universe in Ubuntu
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
NAS = --with-nas=no
+ifneq (,$(filter speech-dispatcher-festival,$(shell dh_listpackages)))
ifeq (${DEB_HOST_ARCH},i386)
builddeb_overrides = -Nspeech-dispatcher-festival
endif
endif
+endif
%:
dh $@ --with python3
Bug#968301: gbp import-orig --uscan does not import signature file of component
Package: git-buildpackage
Version: 0.9.20
While importing a new version of Dovecot (with its component
pigeonhole) I noticed that gbp does not import the signature file of
the component:
dovecot $ gbp import-orig --verbose --uscan
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
gbp:debug: ['git', 'status', '--porcelain']
gbp:info: Launching uscan...
gpgv: Signature made Wed 12 Aug 2020 14:40:44 CEST
gpgv:using RSA key 2BE74AAB3EE754DFB9C80D3318A348AEED409DA1
gpgv:issuer "dovecot...@dovecot.org"
gpgv: Good signature from "Dovecot Community Edition "
gpgv: Signature made Wed 12 Aug 2020 14:41:11 CEST
gpgv:using RSA key 2BE74AAB3EE754DFB9C80D3318A348AEED409DA1
gpgv:issuer "dovecot...@dovecot.org"
gpgv: Good signature from "Dovecot Community Edition "
uupdate: debian/source/format is "3.0 (quilt)".
uupdate: Auto-generating dovecot_2.3.10.1+dfsg1-2.debian.tar.xz
uupdate: -> Copy to dovecot_2.3.11.3-1.debian.tar.xz
gbp:info: Using uscan downloaded tarball ../dovecot_2.3.11.3.orig.tar.gz
gbp:debug: Signature ../dovecot_2.3.11.3.orig.tar.gz found for
../dovecot_2.3.11.3.orig.tar.gz.asc
What is the upstream version? [2.3.11.3]
gbp:debug: ['git', 'tag', '-l', 'upstream/2.3.11.3']
gbp:debug: tar ['-C', '../tmp5mozwa8k', '-a', '-xf',
'../dovecot_2.3.11.3.orig.tar.gz'] []
gbp:debug: Unpacked '../dovecot_2.3.11.3.orig.tar.gz' to
'../tmp5mozwa8k/dovecot-2.3.11.3'
gbp:debug: tar ['-C',
'/home/christian/Downloads/test/tmp5mozwa8k/tmptnesyvj6', '-a', '-xf',
'../dovecot_2.3.11.3.orig-pigeonhole.tar.gz'] []
gbp:debug: rm ['-rf',
'/home/christian/Downloads/test/tmp5mozwa8k/tmptnesyvj6'] []
gbp:info:
gbp:info:
gbp:info: Importing '../dovecot_2.3.11.3.orig.tar.gz' to branch 'upstream'...
gbp:info: Source package is dovecot
gbp:info: Upstream version is 2.3.11.3
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
gbp:debug: ['git', 'commit-tree',
'19c85d604581301c2f866e71059cd400f30b175f', '-p',
'680e65782e2a42bcf02b404159ceb475b335023a']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version
2.3.11.3', 'refs/heads/upstream',
'5cb258901876f1d0023bd227ac08475601088b77',
'680e65782e2a42bcf02b404159ceb475b335023a']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
gbp:debug: ['git', 'ls-tree', '-z', 'upstream', '--']
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: ['git', 'ls-tree', '-z', 'upstream', '--']
gbp:debug: Creating pristine tar commit
'../dovecot_2.3.11.3.orig-pigeonhole.tar.gz' from
'caf0848265034f70e01c8dc371eb6a00731a098d'
gbp:debug: pristine-tar [] ['commit',
'../dovecot_2.3.11.3.orig-pigeonhole.tar.gz',
'caf0848265034f70e01c8dc371eb6a00731a098d']
gbp:debug: pristine-tar [] ['--help']
gbp:debug: pristine-tar [] ['commit',
'../dovecot_2.3.11.3.orig.tar.gz',
'5a563606f3a5f11a5d50b0200d1b20069589065d', '-s',
'../dovecot_2.3.11.3.orig.tar.gz.asc']
gbp:debug: ['git', 'tag', '-m', 'Upstream version 2.3.11.3', '-s',
'upstream/2.3.11.3', '5cb258901876f1d0023bd227ac08475601088b77']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/master']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'master']
gbp:debug: ['git', 'show', '--pretty=medium', 'master:debian/source/format']
gbp:debug: 3.0 (quilt) package, replacing debian/ dir
gbp:info: Replacing upstream source on 'master'
gbp:debug: ['git', 'ls-tree', '-z', 'upstream/2.3.11.3^{tree}', '--']
gbp:debug: ['git', 'ls-tree', '-z', 'master^{tree}', '--']
gbp:debug: Using 77532f57e74ffd49cf17fa1e721b5573577e1223 as debian/ tree
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: ['git', 'commit-tree',
'6471a6fd2abda08f26fb505ee3cf91681e0f3e7d', '-p', 'master^{commit}',
'-p', 'upstream/2.3.11.3^{commit}']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: Updating master after
import of upstream/2.3.11.3', 'refs/heads/master',
'cdd7b2c38ea20c27ad07bed57098f105ed8e0384']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/pigeonhole']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/pigeonhole']
gbp:debug: rm ['-rf', '../tmp5mozwa8k'] []
gbp:info: Successfully imported version 2.3.11.3 of
../dovecot_2.3.11.3.orig.tar.gz
The parent directory after the import looks like:
ls -la ..
total 11M
drwxr-x--- 4 christian christian 4.0K Aug 12 18:51 .
drwxr-x---. 4 christian christian 4.0K Aug 12 18:37 ..
drwxr-x--- 8 christian christian 12K Aug 12 18:51 dovecot
-rw-r- 1 christian
Bug#968315: dgit fails at serializing quilt patches in pam source
Steve Langasek writes ("Bug#968315: dgit fails at serializing quilt patches in
pam source"):
...
> dgit: error: quilt fixup cannot be linear. Stopped at:
> dgit: 6f4c661d..e8d14c81: changed
> .pc/007_modules_pam_unix/.timestamp,.pc/007_modules_pam_unix/modules/pam_unix/Makefile.am,.pc/007_modules_pam_unix/modules/pam_unix/README,.pc/007_modules_pam_unix/modules/pam_unix/obscure.c,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix.8,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix.8.xml,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix_passwd.c,.pc/007_modules_pam_unix/modules/pam_unix/support.h,.pc/applied-patches,debian/patches/007_modules_pam_unix,debian/patches/series
>
> dgit: Maybe you need one of --[quilt=]gbp --[quilt=]dpm --quilt=unapplied ?
> dgit: Maybe orig tarball(s) are not identical to git representation?
>
> dgit: error: quilt history linearisation failed. Search `quilt fixup' in
> dgit(7).
..
> It's not an unapplied tree; I probably would've preferred that, but
> --quilt=unapplied was useless here and I only started to make any progress
> at all when I applied the patches to the tree and committed.
I haven't actually looked at your branch or anything but just looking
at this error message:
I think if you delete the .pc directory from your git tree it will be
directly in dgitc format.
If you want to keep the .pc directory in your master branch then dgit
doesn't support that right now. I'm not sure whether there ought to
be a quilt mode for "maintainer view has .pc directory".
Ian.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: > On 21/05/2020 14.05, Matthias Klose wrote: > > On 5/20/20 10:32 PM, Andreas Beckmann wrote: > >> With the transitional packages gone in 10.1.0-2, please add versioned > >> (epoched!) provides on the old names (as already done in libgcc-s1) > >> in order to keep old packages installable along the latest gcc. > > > > I'd like to avoid that. Please build the nvidia packages using the new > > package > > names. > > This has nothing to do with nvidia. This breaks keeping old compilers > around, which so far worked fine for a long time. Seconded. I have all versions of gcc starting at 4.4 that I would like to keep, but the upgrade require to remove them. Cheers, -- Bill. Imagine a large red swirl here.
Bug#968315: dgit fails at serializing quilt patches in pam source
On Wed, Aug 12, 2020 at 09:39:58PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Bug#968315: dgit fails at serializing quilt patches
> in pam source"):
> ...
> > dgit: error: quilt fixup cannot be linear. Stopped at:
> > dgit: 6f4c661d..e8d14c81: changed
> > .pc/007_modules_pam_unix/.timestamp,.pc/007_modules_pam_unix/modules/pam_unix/Makefile.am,.pc/007_modules_pam_unix/modules/pam_unix/README,.pc/007_modules_pam_unix/modules/pam_unix/obscure.c,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix.8,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix.8.xml,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix_passwd.c,.pc/007_modules_pam_unix/modules/pam_unix/support.h,.pc/applied-patches,debian/patches/007_modules_pam_unix,debian/patches/series
> >
> > dgit: Maybe you need one of --[quilt=]gbp --[quilt=]dpm --quilt=unapplied ?
> > dgit: Maybe orig tarball(s) are not identical to git representation?
> >
> > dgit: error: quilt history linearisation failed. Search `quilt fixup' in
> > dgit(7).
> ..
> > It's not an unapplied tree; I probably would've preferred that, but
> > --quilt=unapplied was useless here and I only started to make any progress
> > at all when I applied the patches to the tree and committed.
>
> I haven't actually looked at your branch or anything but just looking
> at this error message:
>
> I think if you delete the .pc directory from your git tree it will be
> directly in dgitc format.
>
> If you want to keep the .pc directory in your master branch then dgit
> doesn't support that right now. I'm not sure whether there ought to
> be a quilt mode for "maintainer view has .pc directory".
I tried that first as well and it didn't work either (actually I think it
failed at an earlier point). I'll go back and double-check.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Bug#644430: Document the creation of a partition table (gpt / msdos)
Control: tags 644430 + pending Control: tags 691046 + pending Holger Wansing wrote: > Hi, > > Holger Wansing wrote: > > Hi all, > > > > I came across this open (and longstanding) bugs: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644430 > > and > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691046 > > which ask to document the need of a BIOS boot partition when a gpt partition > > table is used. > > > > The basic issue has been solved within partman apparently (on gpt, a 1 MB > > free > > space gets automatically created at the beginning of the disk) > > (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491376). > > > > > > Nevertheless, I think it makes sense to write some words about this in the > > installation-guide? > > > > I have prepared a patch for this and would like to receive some comments, if > > I got it all correctly. > > The additional content will be added to "Appendix C. Partitioning for > > Debian" > > https://d-i.debian.org/doc/installation-guide/en.amd64/apcs05.html#idm4025 > > Since noone objected, I will commit this shortly. Done. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#968318: pyhst2: FTBFS with CUDA 11: Unsupported gpu architecture 'compute_30'
Source: pyhst2 Version: 2020a-1 Severity: important Tags: ftbfs Justification: fails to build from source Hi, pyhst2 FTBFS with CUDA 11 in experimental: dh_auto_build -O--buildsystem=pybuild I: pybuild base:217: /usr/bin/python3 setup.py build running build running build_ext building 'PyHST2_2019b/libgputomo' extension Warning: Can't read registry to find the necessary compiler setting Make sure that Python modules winreg, win32api or win32con are installed. C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -fdebug-prefix-map=/build/pyhst2-2020a=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC creating build creating build/temp.linux-x86_64-3.8 creating build/temp.linux-x86_64-3.8/PyHST creating build/temp.linux-x86_64-3.8/PyHST/Cspace creating build/temp.linux-x86_64-3.8/PyHST/Cspace/pdwt creating build/temp.linux-x86_64-3.8/PyHST/Cspace/pdwt/src compile options: '-I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include -IPyHST/Cspace -I/usr/include/hdf5/serial/ -I/usr/include/python3.8 -c' extra options: 'gcc nvcc' nvcc: PyHST/Cspace/pdwt/src/wt.cu nvcc: PyHST/Cspace/pdwt/src/common.cu nvcc: PyHST/Cspace/pdwt/src/utils.cu nvcc: PyHST/Cspace/pdwt/src/nonseparable.cu nvcc: PyHST/Cspace/pdwt/src/separable.cu nvcc: PyHST/Cspace/pdwt/src/haar.cu nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc fatal : Unsupported gpu architecture 'compute_30' mpicc: PyHST/Cspace/pdwt/src/filters.cpp nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc: PyHST/Cspace/gputomo.cu nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc: PyHST/Cspace/cudamedianfilter.cu nvcc: PyHST/Cspace/chambollepock.cu nvcc: PyHST/Cspace/wavelets.cu nvcc: PyHST/Cspace/sinofilters.cu nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc fatal : Unsupported gpu architecture 'compute_30' nvcc fatal : Unsupported gpu architecture 'compute_30' error: Command "/usr/bin/nvcc -I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include -IPyHST/Cspace -I/usr/include/hdf5/serial/ -I/usr/include/python3.8 -c PyHST/Cspace/pdwt/src/common.cu -o build/temp.linux-x86_64-3.8/PyHST/Cspace/pdwt/src/common.o -gencode arch=compute_30,code=compute_30 -gencode arch=compute_50,code=compute_50 --compiler-options -fPIC -O3 -g -D_FORCE_INLINES" failed with exit status 1 E: pybuild pybuild:352: build: plugin distutils failed with: exit code=1: /usr/bin/python3 setup.py build dh_auto_build: error: pybuild --build returned exit code 13 make: *** [debian/rules:9: build] Error 25 Andreas
Bug#968317: RM: nvidia-cuda-doc [all] -- ROM; renamed to nvidia-cuda-toolkit-doc
Package: ftp.debian.org Severity: normal Hi, please remove the arch:all cruft package nvidia-cuda-doc, this has been renamed to nvidia-cuda-toolkit-doc nvidia-cuda-doc | 10.1.243-8 | unstable/non-free| all nvidia-cuda-toolkit-doc | 10.2.89-4 | unstable/non-free| all Andreas
Bug#957717: [Help] pvm: ftbfs with GCC-10
Control: tags -1 patch Hi Andreas, This lead to the trail: > : error: 'pvmd' undeclared (first use in this function) > /build/pvm-3.4.6/src/ddpro.c:1031:14: note: in expansion of macro 'PVMDPATH' > 1031 | pvmdpath = PVMDPATH; > | ^~~~ Definition of PVMDPATH and friends is cascaded through a tool chain from debian/rules, but double quotes went missing for some reason, maybe with the debhelper compatibility level bump. Thus, the undefined symbol _pvmd_ ended up into the C code, instead of the string _"pvmd"_. --8< diff --git a/debian/rules b/debian/rules index b1d217b..92a6247 100755 --- a/debian/rules +++ b/debian/rules @@ -11,7 +11,7 @@ soversion=3 # yes, I know this will define RSHCOMMAND twice and generate a warning. # I'm not modifying gcc. -dld # -export DEB_CPPFLAGS_MAINT_APPEND=-DRSHCOMMAND=\\\"/usr/lib/pvm3/bin/rsh\\\" -DPVMDPATH=\\\"pvmd\\\" -DPVMDFILE=\\\"/usr/bin/pvmd\\\" -DPVM_DEFAULT_ROOT=\\\"/usr/lib/pvm3\\\" -DOVERLOADHOST +export DEB_CPPFLAGS_MAINT_APPEND=-DRSHCOMMAND=\\\"/usr/lib/pvm3/bin/rsh\\\" -DPVMDPATH=\\\"pvmd\\\" -DPVMDFILE=\\\"/usr/bin/pvmd\\\" -DPVM_DEFAULT_ROOT=\\\"/usr/lib/pvm3\\\" -DOVERLOADHOST export DEB_BUILD_MAINT_OPTIONS=hardening=+all include /usr/share/dpkg/architecture.mk export DEB_HOST_MULTIARCH @@ -80,7 +80,7 @@ override_dh_auto_install: ln -s libgpvm3.so.$(version) debian/libpvm3/usr/lib/$(DEB_HOST_MULTIARCH)/libgpvm3.so.$(soversion) # pvm-examples package - mv bin/$(PVM_ARCH)/gs debian/pvm-examples/usr/bin/gs.pvm + #mv bin/$(PVM_ARCH)/gs debian/pvm-examples/usr/bin/gs.pvm mv bin/$(PVM_ARCH)/hello debian/pvm-examples/usr/bin/hello.pvm mv bin/$(PVM_ARCH)/srm debian/pvm-examples/usr/bin/srm.pvm cp bin/$(PVM_ARCH)/* debian/pvm-examples/usr/bin/ -->8 I hope this helps, but I must admit it seems rather fragile. :( 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/4, please excuse my verbosity. signature.asc Description: PGP signature
Bug#968315: dgit fails at serializing quilt patches in pam source
Package: dgit Version: 9.11 I've been working on converting the pam source package to properly use 3.0 (quilt) format where patches are in debian/patches, instead of the legacy system that uses a different directory for patches and applies them at build time with quilt. Unfortunatley, dgit is throwing errors at me about quilt serialization. I initially tried to move the entire patch series to debian/patches in one go and hit the error; then since it talked about "serialization" I tried moving them one at a time, but hit the same error again on the 4th patch. $ dgit build Format `3.0 (quilt)', need to check/update patch stack dpkg-buildpackage: info: source package pam dpkg-buildpackage: info: source version 1.4.0-1 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by Steve Langasek fakeroot debian/rules clean dh clean --with quilt,autoreconf dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_quilt_unpatch Removing patch 007_modules_pam_unix Removing modules/pam_unix/obscure.c Restoring modules/pam_unix/pam_unix.8.xml Restoring modules/pam_unix/Makefile.am Restoring modules/pam_unix/pam_unix.8 Restoring modules/pam_unix/support.h Restoring modules/pam_unix/README Restoring modules/pam_unix/pam_unix_passwd.c Removing patch make_documentation_reproducible.patch Restoring configure.ac Removing patch pam_unix_dont_trust_chkpwd_caller.patch Restoring modules/pam_unix/unix_chkpwd.c Removing patch pam_unix_fix_sgid_shadow_auth.patch Restoring modules/pam_unix/passverify.c No patches applied dh_clean dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) examining quilt state (multiple patches, linear mode) gzip: warning: GZIP environment variable is deprecated; use an alias or script Tree already contains .pc - will use it then delete it. dgit: base trees orig=058b0c4bd5049b9214d5 o+d/p=da5e6a7de7ec5d1c7619 dgit: quilt differences: src: ## orig ## gitignores: == orig == dgit: quilt differences: HEAD ## o+d/p HEAD == o+d/p starting quiltify (multiple patches, linear mode) dgit: error: quilt fixup cannot be linear. Stopped at: dgit: 6f4c661d..e8d14c81: changed .pc/007_modules_pam_unix/.timestamp,.pc/007_modules_pam_unix/modules/pam_unix/Makefile.am,.pc/007_modules_pam_unix/modules/pam_unix/README,.pc/007_modules_pam_unix/modules/pam_unix/obscure.c,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix.8,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix.8.xml,.pc/007_modules_pam_unix/modules/pam_unix/pam_unix_passwd.c,.pc/007_modules_pam_unix/modules/pam_unix/support.h,.pc/applied-patches,debian/patches/007_modules_pam_unix,debian/patches/series dgit: Maybe you need one of --[quilt=]gbp --[quilt=]dpm --quilt=unapplied ? dgit: Maybe orig tarball(s) are not identical to git representation? dgit: error: quilt history linearisation failed. Search `quilt fixup' in dgit(7). $ It's not an unapplied tree; I probably would've preferred that, but --quilt=unapplied was useless here and I only started to make any progress at all when I applied the patches to the tree and committed. I've pushed the branch to https://salsa.debian.org/vorlon/pam/-/tree/dgit-quilt-breakage for inspection if that helps. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#968316: mk-sbuild: fix a TARGET_ARCH check before outputting a message
Source: ubuntu-dev-tools
Version: 0.154
Severity: minor
Tags: patch
Hi,
Thanks a lot for maintaining ubuntu-dev-tools!
What do you think about the attached trivial patch that avoids
outputting a slightly confusing message containing empty strings if
a target architecture is not specified at all?
Thanks again, and keep up the great work!
G'luck,
Peter
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
From a3c2cde7f66c292089cb2f78e870ac6080e25dd4 Mon Sep 17 00:00:00 2001
From: Peter Pentchev
Date: Wed, 12 Aug 2020 22:58:54 +0300
Subject: [PATCH] Fix a check for TARGET_ARCH in a message.
---
mk-sbuild | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mk-sbuild b/mk-sbuild
index bf3c68e..c50fdb3 100755
--- a/mk-sbuild
+++ b/mk-sbuild
@@ -915,7 +915,7 @@ echo ""
echo " To CHANGE the golden image: sudo schroot -c source:${CHROOT_NAME} -u
root"
echo " To ENTER an image snapshot: schroot -c ${CHROOT_NAME}"
echo " To BUILD within a snapshot: sbuild -A -d ${CHROOT_NAME} PACKAGE*.dsc"
-if [ "$CHROOT_ARCH" != "$TARGET_ARCH" ] ; then
+if [ -n "$TARGET_ARCH" ] && [ "$CHROOT_ARCH" != "$TARGET_ARCH" ] ; then
echo " To BUILD for ${TARGET_ARCH}: sbuild -A -d ${CHROOT_NAME} --host
${TARGET_ARCH} PACKAGE*.dsc"
fi
echo ""
--
2.28.0
signature.asc
Description: PGP signature
Bug#968314: src:mencal: fails to migrate to testing for too long: maintainer built arch:all binaries
Source: mencal Version: 3.0-4 Severity: serious Control: close -1 3.0-5 Tags: sid bullseye pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:mencal in its current version in unstable has been trying to migrate for 64 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Normally I would do a no-changes source-only upload to DELAYED/15, however, I am extremely low on Internet bandwidth right now, so somebody else has to do it. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=mencal signature.asc Description: OpenPGP digital signature
Bug#968297: RFP: targetd -- remote configuration of a LIO-based storage appliance
Package: wnpp Severity: wishlist X-Debbugs-Cc: jfle...@arcaik.net, debian-pyt...@lists.debian.org * Package name: targetd Version : 0.8.12 Upstream Author : Tony Asleson * URL : https://github.com/open-iscsi/targetd/ * License : GPL-3.0-or-later Programming Lang: Python Description : remote configuration of a LIO-based storage appliance targetd turns Linux into a remotely-configurable storage appliance. It supports an HTTP/jsonrpc-2.0 interface to let a remote administrator allocate volumes from an LVM volume group, and export those volumes over iSCSI. This can be especially usefull in environment such as Kubernetes where storage is provisionned automatically.
Bug#968312: eztrace-contrib: FTBFS with CUDA 11: cuda_runtime.cu(92): error: function "cudaMalloc(void **, size_t)" has already been defined
Source: eztrace-contrib Version: 1.1-8-6+contrib Severity: important Tags: ftbfs Justification: fails to build from source Hi, eztrace-contrib FTBFS with CUDA 11 in experimental: ../../../../src/modules/cuda/cuda_runtime.cu(92): error: function "cudaMalloc(void **, size_t)" has already been defined Andreas
Bug#968313: simpleburn: FTBFS: libcallbacks.a(callbacks.c.o):./obj-x86_64-linux-gnu/src/./src/simpleburn.h:57: multiple definition of `ui'
Source: simpleburn Version: 1.8.0-1 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source (but built successfully in the past) | [100%] Linking C executable simpleburn | cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/simpleburn.dir/link.txt --verbose=1 | /usr/bin/cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -rdynamic CMakeFiles/simpleburn.dir/simpleburn.c.o -o simpleburn libcallbacks.a libmediainfos.a libprogress.a -lcdio -lm -lcddb -ldvdread -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -lcddb -ldvdread -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 | /usr/bin/ld: libcallbacks.a(callbacks.c.o):./obj-x86_64-linux-gnu/src/./src/simpleburn.h:57: multiple definition of `ui'; CMakeFiles/simpleburn.dir/simpleburn.c.o:./obj-x86_64-linux-gnu/src/./src/simpleburn.h:57: first defined here | /usr/bin/ld: libcallbacks.a(callbacks.c.o):./obj-x86_64-linux-gnu/src/./src/progress.h:5: multiple definition of `commandinfos'; CMakeFiles/simpleburn.dir/simpleburn.c.o:./obj-x86_64-linux-gnu/src/./src/progress.h:5: first defined here | /usr/bin/ld: libmediainfos.a(mediainfos.c.o):./obj-x86_64-linux-gnu/src/./src/simpleburn.h:57: multiple definition of `ui'; CMakeFiles/simpleburn.dir/simpleburn.c.o:./obj-x86_64-linux-gnu/src/./src/simpleburn.h:57: first defined here | /usr/bin/ld: libprogress.a(progress.c.o):./obj-x86_64-linux-gnu/src/./src/simpleburn.h:57: multiple definition of `ui'; CMakeFiles/simpleburn.dir/simpleburn.c.o:./obj-x86_64-linux-gnu/src/./src/simpleburn.h:57: first defined here | /usr/bin/ld: libprogress.a(progress.c.o):./obj-x86_64-linux-gnu/src/./src/progress.h:5: multiple definition of `commandinfos'; CMakeFiles/simpleburn.dir/simpleburn.c.o:./obj-x86_64-linux-gnu/src/./src/progress.h:5: first defined here | collect2: error: ld returned 1 exit status | make[3]: *** [src/CMakeFiles/simpleburn.dir/build.make:90: src/simpleburn] Error 1 See https://buildd.debian.org/status/fetch.php?pkg=simpleburn=amd64=1.8.0-1%2Bb6=1597254973=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#968277: mingw-w64: CVE-2018-5392 Fail to enable working ASLR on request
Hi Petter, On Wed, 12 Aug 2020 12:45:32 +0200, Petter Reinholdtsen wrote: > [Stephen Kitt] > > Builds can supply the appropriate flags, but they need to do so > > consciously, it doesn’t make sense to enable them by default. > > Why not? I would expect it made sense to enable as many security > defences as possible in the default build, and if I remember correctly, > this was the rationale behind enabling the flags by default in the first > place. > > I got the impression from the upstream commits that the default now > enable these flags by default, but might have been mistanken, as I do > not really know much about mingw. :) The upstream build doesn’t support enabling the flags by default — or rather, the test suite doesn’t support it. The upstream changes ensure that the necessary relocation section is preserved when secure flags are enabled, but this results in an empty section in many cases, which confuses other tools. The problem is really that, in the past, the flags were just flags, toggled in the binary; they were effectively an assertion that the binary had been built in such a way that the corresponding security feature could be enabled, with no checks that that was actually the case. Things are somewhat better now but I’m still not sure that all the flags are handled, I haven’t taken the time to check on Windows. > > The settings are ultimately controlled by binutils-mingw-w64. The > > security flags were set by default starting with version 7 (so > > 2.28-5+7.4 in oldstable is the first affected version that’s currently > > available), and disabled again in version 8.8, and fixed up in 8.9 (so > > 2.34-5+8.9 in testing is the first fixed version that’s currently > > available). > > OK, I've tried to adjust the starting point accordingly. We’ll have to re-assign the bug for that to work, I’ll take care of that (and of updating the CVE information). Regards, Stephen pgpnvSl2jV6gv.pgp Description: OpenPGP digital signature
Bug#968311: gnome-shell: CVE-2020-17489
Source: gnome-shell Version: 3.36.4-1 Severity: important Tags: security upstream Forwarded: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2997 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for gnome-shell. CVE-2020-17489[0]: | An issue was discovered in certain configurations of GNOME gnome-shell | through 3.36.4. When logging out of an account, the password box from | the login dialog reappears with the password still visible. If the | user had decided to have the password shown in cleartext at login | time, it is then visible for a brief moment upon a logout. (If the | password were never shown in cleartext, only the password length is | revealed.) If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-17489 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17489 [1] https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2997 [2] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1377 [3] https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/13137aad9db52223e8b62cecbd3456f4a7f66f04 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#968310: Install the Python library and tpm2_ptool.
Source: tpm2-pkcs11 Severity: wishlist Tags: patch Hi, Thanks for packaging tpm2-pkcs11! What do you think about this merge request? https://salsa.debian.org/debian/tpm2-pkcs11/-/merge_requests/8 Thanks again, and keep up the great work! G'luck, Peter -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#968281: I cannot export alarms in Kalarm
This bug description looks like https://bugs.kde.org/show_bug.cgi?id=374337. This was fixed in KDE Applications 16.12.1. (The version you are reporting about is an earlier version, 16.04.3.) -- David Jarvie. KDE developer, KAlarm author.
Bug#968309: src:austin: fails to migrate to testing for too long: FTBFS on armhf and mipsel
Source: austin Version: 1.0.0-1 Severity: serious Control: close -1 1.0.1-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:austin in its current version in unstable has been trying to migrate for 66 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=austin signature.asc Description: OpenPGP digital signature
Bug#968308: src:cgview: fails to migrate to testing for too long: autopkgtest failure
Source: cgview Version: 0.0.20100111-4 Severity: serious Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:cgview in its current version in unstable has been trying to migrate for 67 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=cgview signature.asc Description: OpenPGP digital signature
Bug#966894: faucc: FTBFS: parse.tab.c:108:10: fatal error: parse.tab.h: No such file or directory
Hi, fix is quite simple, patch attached, and already forwarded to upstream. As always, feel free to NMU. Cheers, Stefan. diff --git a/Makefile.am b/Makefile.am index 0541256..c2f7c49 100644 --- a/Makefile.am +++ b/Makefile.am @@ -35,7 +35,7 @@ cc1_SOURCES = parse.y \ cc1.c # Make sure that parse.[ch] will get built before anything else gets compiled. -BUILT_SOURCES = config.h parse.c parse.h +BUILT_SOURCES = config.h parse.tab.c parse.tab.h CLEANFILES = \ $(BUILT_SOURCES) \ scan.c @@ -46,12 +46,10 @@ DISTCLEANFILES = config.h config.h: Makefile.am echo '#define FAUCCDIR "'$(fauccdir)'"' > config.h -parse.c: parse.y +parse.tab.c: parse.y bison -d parse.y - mv parse.tab.c parse.c - mv parse.tab.h parse.h -parse.h: parse.c +parse.tab.h: parse.tab.c devel: $(top_srcdir)/scripts/install_ln.sh $(MAKE) install INSTALL=$(CURDIR)/$(top_srcdir)/scripts/install_ln.sh signature.asc Description: PGP signature
Bug#967917: Unresponsive system
I use GNU / Linux Debian testing 64-bit fully updated [kernel 5.3.0-3-amd64] and the past week or so, my entire system has become unresponsive at random times. 5 minutes ago, while I was listening to music, my system stop playing the track and became fully unresponsive. I switched to a different TTY, Ctrl+Alt+ in my case, and saw countless IO error that related to blk. Right now "systemctl status blk-availability.service" returns the following back: $ systemctl status blk-availability.service ● blk-availability.service - Availability of block devices Loaded: bad-setting (Reason: Unit blk-availability.service > Active: inactive (dead) lines 1-3/3 (END)...skipping... ● blk-availability.service - Availability of block devices Loaded: bad-setting (Reason: Unit blk-availability.service has a bad unit file setting.) Active: inactive (dead) I had to choose a different kernel, 4.17.0-1-amd64, to access my system. I'm getting quite stressed right now about this behavior. -- Stefanos Sofroniou
Bug#968307: ghcide: GHCIDE is the recommended [1] tool supporting a wide range of editors (Vim, Emacs, VSCode etc. [2]), crucial for Haskell development. [1] https://gitlab.haskell.org/ghc/ghc/-/wikis
Package: ghcide Version: GHCIDE package unavailable Severity: wishlist X-Debbugs-Cc: hyil...@gmail.com -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-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
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
On 12 Aug 2020, at 20:16, Sudip Mukherjee wrote: > > On Wed, Aug 12, 2020 at 8:04 PM Sudip Mukherjee > wrote: >> >> On Wed, Aug 12, 2020 at 7:54 PM Jessica Clarke wrote: >>> >>> On 12 Aug 2020, at 19:51, Sudip Mukherjee >>> wrote: HI Jess, On Wed, Aug 12, 2020 at 7:21 PM Jessica Clarke wrote: > > On 12 Aug 2020, at 19:15, Sudip Mukherjee > wrote: >> >> Control: tags 957380 + patch >> Control: tags 957380 + pending >> >> Dear maintainer, >> >> I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and >> uploaded it to DELAYED/2. Please feel free to tell me if I >> should cancel it. > > Thanks, I've been meaning to do this but it's just not a high enough > priority for me. Could you please however use `typedef` instead, as I > believe the intent of the code (based on how these ones are written, > and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name, > not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as > a merge request against https://salsa.debian.org/bsd-team/istgt? > > https://salsa.debian.org/bsd-team/istgt has UNRELEASED changes and the > version is 0.5~20120901-1 there. But since there is no pristine-tar or > upstream branch, I am unable to generate > istgt_0.5~20120901.orig.tar.gz to build and test with the proposed > patch. Ah, yes and that 0.5 work looks half-baked. I've created a new 0.5 feature branch for that and rewound master (yes, bad practice, I know, but I highly doubt anyone else has a clone) to the 0.4~20111008-3 release so you should be good to use it as-is now. Jess
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
On Wed, Aug 12, 2020 at 8:04 PM Sudip Mukherjee wrote: > > On Wed, Aug 12, 2020 at 7:54 PM Jessica Clarke wrote: > > > > On 12 Aug 2020, at 19:51, Sudip Mukherjee > > wrote: > > > > > > HI Jess, > > > > > > On Wed, Aug 12, 2020 at 7:21 PM Jessica Clarke wrote: > > >> > > >> On 12 Aug 2020, at 19:15, Sudip Mukherjee > > >> wrote: > > >>> > > >>> Control: tags 957380 + patch > > >>> Control: tags 957380 + pending > > >>> > > >>> Dear maintainer, > > >>> > > >>> I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and > > >>> uploaded it to DELAYED/2. Please feel free to tell me if I > > >>> should cancel it. > > >> > > >> Thanks, I've been meaning to do this but it's just not a high enough > > >> priority for me. Could you please however use `typedef` instead, as I > > >> believe the intent of the code (based on how these ones are written, > > >> and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name, > > >> not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as > > >> a merge request against https://salsa.debian.org/bsd-team/istgt? https://salsa.debian.org/bsd-team/istgt has UNRELEASED changes and the version is 0.5~20120901-1 there. But since there is no pristine-tar or upstream branch, I am unable to generate istgt_0.5~20120901.orig.tar.gz to build and test with the proposed patch. -- Regards Sudip
Bug#968305: python-django-celery-results: CVE-2020-17495
Source: python-django-celery-results Version: 1.0.4-1 Severity: important Tags: security upstream Forwarded: https://github.com/celery/django-celery-results/issues/142 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for python-django-celery-results. CVE-2020-17495[0]: | django-celery-results through 1.2.1 stores task results in the | database. Among the data it stores are the variables passed into the | tasks. The variables may contain sensitive cleartext information that | does not belong unencrypted in the database. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-17495 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17495 [1] https://github.com/celery/django-celery-results/issues/142 Regards, Salvatore
Bug#968306: python-pysnmp4-mibs: [INTL:pt] Initial Portuguese translation of manpage
Package: python-pysnmp4-mibs Version: 0.1.3-3 3ags: l10n, patch- Severity: wishlist Updated Portuguese translation for python-pysnmp4-mibs's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro python-pysnmp4-mibs_0.1.3-3_rebuild-pysnmp-mibs.pt.po.gz Description: application/gzip
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
On Wed, Aug 12, 2020 at 7:54 PM Jessica Clarke wrote:
>
> On 12 Aug 2020, at 19:51, Sudip Mukherjee wrote:
> >
> > HI Jess,
> >
> > On Wed, Aug 12, 2020 at 7:21 PM Jessica Clarke wrote:
> >>
> >> On 12 Aug 2020, at 19:15, Sudip Mukherjee
> >> wrote:
> >>>
> >>> Control: tags 957380 + patch
> >>> Control: tags 957380 + pending
> >>>
> >>> Dear maintainer,
> >>>
> >>> I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and
> >>> uploaded it to DELAYED/2. Please feel free to tell me if I
> >>> should cancel it.
> >>
> >> Thanks, I've been meaning to do this but it's just not a high enough
> >> priority for me. Could you please however use `typedef` instead, as I
> >> believe the intent of the code (based on how these ones are written,
> >> and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name,
> >> not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as
> >> a merge request against https://salsa.debian.org/bsd-team/istgt?
> >
> > I have cancelled the upload from DELAYED queue but I am not really
> > sure how you can use typedef here.
> > iiuc, ISTGT_LU_TASK_TYPE is supposed to be an enum which has
> > ISTGT_LU_TASK_RESPONSE and ISTGT_LU_TASK_REQPDU as its members where
> > ISTGT_LU_TASK_RESPONSE will have a value of 1 and ISTGT_LU_TASK_REQPDU
> > will have 0 and these enum members are used in the code to determine
> > the task type.
>
> typedef enum {
> ISTGT_LU_TASK_RESULT_IMMEDIATE = 0,
> ISTGT_LU_TASK_RESULT_QUEUE_OK = 1,
> ISTGT_LU_TASK_RESULT_QUEUE_FULL = 2,
> } ISTGT_LU_TASK_RESULT;
>
> should work, i.e. just adding typedef to the original code, instead of
> moving the ISTGT_LU_TASK_RESULT etc around.
ahh.. ofcourse. that will work.
I will raise the merge request and keep it 'UNRELEASED' in the
changelog so that you can release it later with other changes if you
want.
--
Regards
Sudip
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
On 12 Aug 2020, at 19:51, Sudip Mukherjee wrote:
>
> HI Jess,
>
> On Wed, Aug 12, 2020 at 7:21 PM Jessica Clarke wrote:
>>
>> On 12 Aug 2020, at 19:15, Sudip Mukherjee wrote:
>>>
>>> Control: tags 957380 + patch
>>> Control: tags 957380 + pending
>>>
>>> Dear maintainer,
>>>
>>> I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and
>>> uploaded it to DELAYED/2. Please feel free to tell me if I
>>> should cancel it.
>>
>> Thanks, I've been meaning to do this but it's just not a high enough
>> priority for me. Could you please however use `typedef` instead, as I
>> believe the intent of the code (based on how these ones are written,
>> and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name,
>> not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as
>> a merge request against https://salsa.debian.org/bsd-team/istgt?
>
> I have cancelled the upload from DELAYED queue but I am not really
> sure how you can use typedef here.
> iiuc, ISTGT_LU_TASK_TYPE is supposed to be an enum which has
> ISTGT_LU_TASK_RESPONSE and ISTGT_LU_TASK_REQPDU as its members where
> ISTGT_LU_TASK_RESPONSE will have a value of 1 and ISTGT_LU_TASK_REQPDU
> will have 0 and these enum members are used in the code to determine
> the task type.
typedef enum {
ISTGT_LU_TASK_RESULT_IMMEDIATE = 0,
ISTGT_LU_TASK_RESULT_QUEUE_OK = 1,
ISTGT_LU_TASK_RESULT_QUEUE_FULL = 2,
} ISTGT_LU_TASK_RESULT;
should work, i.e. just adding typedef to the original code, instead of
moving the ISTGT_LU_TASK_RESULT etc around.
Jess
Bug#968300: doesn't build without real root
Control: severity -1 normal Control: tags -1 unreproducible moreinfo Am 12.08.20 um 16:11 schrieb Marc Haber: > Package: systemd > Version: 241-7~deb10u4.1+0~zgSID+1 > Severity: serious > Tags: ftbfs > Justification: [buster] fails to build from source > The package obviously builds from source, otherwise there would be no stable or unstable uploads. > Hi, > > I am trying to do a local build of systemd 241 on buster to fix the > capabilities issue (#964026). In this process, I have found out that > systemd does need "real root" when building and is neiter satisfied with > a non-root build nor with fakeroot: I can't reproduce that. I always build packages as non-root user. > (build tail after dpkd-buildpackage) > mv debian/systemd/lib/systemd/system/tmp.mount > debian/systemd/usr/share/systemd/ > printf '\n[Install]\nWantedBy=local-fs.target\n' >> > debian/systemd/usr/share/systemd/tmp.mount > rm debian/systemd/lib/systemd/system/local-fs.target.wants/tmp.mount > # files shipped by cryptsetup > rm debian/systemd/usr/share/man/man5/crypttab.5 > # files shipped by systemd > rm debian/udev/lib/udev/rules.d/70-uaccess.rules > rm debian/udev/lib/udev/rules.d/73-seat-late.rules > rm debian/udev/lib/udev/rules.d/71-seat.rules > rm debian/udev/lib/udev/rules.d/99-systemd.rules > # remove duplicate files shipped by systemd-*/udev > echo "Removing duplicate files in systemd package:" > Removing duplicate files in systemd package: > set -e; for pkg in systemd-sysv systemd-container systemd-journal-remote > systemd-coredump systemd-tests libpam-systemd libnss-myhostname > libnss-mymachines libnss-resolve libnss-systemd libsystemd0 libsystemd-dev > udev libudev1 libudev-dev; do \ > echo "... from $pkg..."; \ > (cd debian/$pkg; find -type f -o -type l) | (cd debian/systemd; xargs > rm -f --verbose); \ > (cd debian/$pkg; find -mindepth 1 -type d | sort -r) | (cd > debian/systemd; xargs rmdir --ignore-fail-on-non-empty --verbose || true); \ > done > ... from systemd-sysv... > /srv/mh/systemd/systemd-241/debian/systemd > rm: cannot remove '/srv/mh/systemd/systemd-241/debian/systemd-sysv': Is a > directory Maybe this directory has messed up permissions? signature.asc Description: OpenPGP digital signature
Bug#961414: (no subject)
Hi, > Now 0.9.3 is available. sorry, I somehow did not get a notification mail about that bug. waybar since version 0.9.2 depends on the `date` library that is not in Debian. I asked upstream to drop the dependency and use the built in C++20 support once thats widely available [0]. I guess that can still take some time, but I think it makes more sense to wait instead of packaging date for waybar only to remove it again later. The downside is that waybar probably won't be in Bullseye. cheers, Birger [0] https://github.com/Alexays/Waybar/issues/668
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
HI Jess, On Wed, Aug 12, 2020 at 7:21 PM Jessica Clarke wrote: > > On 12 Aug 2020, at 19:15, Sudip Mukherjee wrote: > > > > Control: tags 957380 + patch > > Control: tags 957380 + pending > > > > Dear maintainer, > > > > I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and > > uploaded it to DELAYED/2. Please feel free to tell me if I > > should cancel it. > > Thanks, I've been meaning to do this but it's just not a high enough > priority for me. Could you please however use `typedef` instead, as I > believe the intent of the code (based on how these ones are written, > and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name, > not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as > a merge request against https://salsa.debian.org/bsd-team/istgt? I have cancelled the upload from DELAYED queue but I am not really sure how you can use typedef here. iiuc, ISTGT_LU_TASK_TYPE is supposed to be an enum which has ISTGT_LU_TASK_RESPONSE and ISTGT_LU_TASK_REQPDU as its members where ISTGT_LU_TASK_RESPONSE will have a value of 1 and ISTGT_LU_TASK_REQPDU will have 0 and these enum members are used in the code to determine the task type. -- Regards Sudip
Bug#968009: Warn that there is no point of installing this package if using systemd
Am 12.08.20 um 16:54 schrieb 積丹尼 Dan Jacobson: > I'm saying all machines that were around before systemd came along will > still have their resolvconf installed. I don't think this is correct. Afaik, resolvconf has always been optional and was never installed by default in Debian. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#966575: Symbol `grub_calloc' not found: AWS instance
I've been affected by this issue on an AWS EC2 instance. The particular issue with AWS is that the device names may depend on the particular instance types; on newer hardware disks appear as NVMe devices, and on older hardware as /dev/xvd? or /dev/sd?. The Debian cloud instances have unattended updates enabled and I guess that the grub update was installed while the instance was running on hardware with NVMe disks, while it had originally been installed when it was running on older hardware. My fstab refers to the disks using UUIDs; I believe that some distributions may install symlinks in /dev to avoid problems like this but Debian doesn't seem to. Rescue is not too difficult once you know how: detach the borked instance's root volume, attach it to another (temporary) instance, repair, and move it back. To make it appear as the root volume when moved back you need to give exactly the same device name as is shown as "Root Device Name" in the image's AMI details; it took me a long time to work out that I needed to enter "xvda" rather than "/dev/xvda" here (YMMV). To actually repair it I followed the advice in this bug to bind-mount /dev,proc,sys and chroot. I then tried Colin's advice in message 184 but without success: # dpkg-reconfigure grub-pc Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.19.0-10-amd64 Found initrd image: /boot/initrd.img-4.19.0-10-amd64 Found linux image: /boot/vmlinuz-4.19.0-9-amd64 Found initrd image: /boot/initrd.img-4.19.0-9-amd64 Found linux image: /boot/vmlinuz-4.9.0-5-amd64 Found initrd image: /boot/initrd.img-4.9.0-5-amd64 WARNING: Device /dev/nvme0n1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme0n1p1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme0n1p14 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme0n1p15 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme1n1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme1n1p1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme0n1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme0n1p1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme0n1p14 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme0n1p15 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme1n1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/nvme1n1p1 not initialized in udev database even after waiting 1000 microseconds. Found Debian GNU/Linux 10 (buster) on /dev/nvme0n1p1 done There were a couple of curses dialogs during that asking about kernel command lines, for which I accepted the defaults. Note that /dev/nvme0n1p1 is the rescue system's root device, not the one that needs repairing. This didn't work. So I tried again with grub-install: # grub-install /dev/nvme1n1 Installing for i386-pc platform. Installation finished. No error reported. (Note nvme1n1, not nvme1 or nvme1n1p1.) This has worked, in as much as the system now works again. I take it that I should now dpkg-reconfigure from within the restarted system (though that will not prevent future breakage if I move to hardware with different device names, right?). I hope a fix is planned for this; cloud images can have quite long uptimes so there may still be a lot of undiscovered affected systems. Regards, Phil.
Bug#957298: gom: diff for NMU version 0.30.2-9.1
Control: tags 957298 + patch
Control: tags 957298 + pending
Dear maintainer,
I've prepared an NMU for gom (versioned as 0.30.2-9.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru gom-0.30.2/debian/changelog gom-0.30.2/debian/changelog
--- gom-0.30.2/debian/changelog 2018-04-29 11:41:56.0 +0100
+++ gom-0.30.2/debian/changelog 2020-08-12 19:31:48.0 +0100
@@ -1,3 +1,10 @@
+gom (0.30.2-9.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957298)
+
+ -- Sudip Mukherjee Wed, 12 Aug 2020 19:31:48
+0100
+
gom (0.30.2-9) unstable; urgency=medium
* [aa941a0] debian/control: Update VCS URLs after salsa move.
diff -Nru gom-0.30.2/debian/patches/fix_ftbfs.patch
gom-0.30.2/debian/patches/fix_ftbfs.patch
--- gom-0.30.2/debian/patches/fix_ftbfs.patch 1970-01-01 01:00:00.0
+0100
+++ gom-0.30.2/debian/patches/fix_ftbfs.patch 2020-08-12 19:24:47.0
+0100
@@ -0,0 +1,19 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee
+Bug-Debian: https://bugs.debian.org/957298
+Forwarded: no
+
+---
+
+--- gom-0.30.2.orig/src/gom_info.h
gom-0.30.2/src/gom_info.h
+@@ -48,7 +48,7 @@
+ enum gom_info_types {GOM_INFO_ERROR=-1, GOM_INFO_QUIET, GOM_INFO_NORMAL,
GOM_INFO_VERBOSE, GOM_INFO_DEBUG};
+
+ /* shown errors count */
+-int gom_info_errors;
++extern int gom_info_errors;
+
+ /*
+ * FUNCTION PROTOTYPES
diff -Nru gom-0.30.2/debian/patches/series gom-0.30.2/debian/patches/series
--- gom-0.30.2/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ gom-0.30.2/debian/patches/series2020-08-12 19:23:54.0 +0100
@@ -0,0 +1 @@
+fix_ftbfs.patch
Bug#968304: shadow: [INTL:pt] Initial Portuguese translation of manpage
Package: shadow Version: 4.8.1-1 3ags: l10n, patch- Severity: wishlist Updated Portuguese translation for shadow's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro shadow_1_4.8.1-1_shadow-man-pages.pt.po.gz Description: application/gzip
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
On 12 Aug 2020, at 19:15, Sudip Mukherjee wrote:
>
> Control: tags 957380 + patch
> Control: tags 957380 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should cancel it.
Thanks, I've been meaning to do this but it's just not a high enough
priority for me. Could you please however use `typedef` instead, as I
believe the intent of the code (based on how these ones are written,
and what's around it) is to have `ISTGT_LU_TASK_TYPE` be the type name,
not `enum ISTGT_LU_TASK_TYPE`? Would you also be willing to file it as
a merge request against https://salsa.debian.org/bsd-team/istgt?
Jess
> --
> Regards
> Sudip
>
> diff -Nru istgt-0.4~20111008/debian/changelog
> istgt-0.4~20111008/debian/changelog
> --- istgt-0.4~20111008/debian/changelog 2012-06-26 23:25:01.0
> +0100
> +++ istgt-0.4~20111008/debian/changelog 2020-08-12 19:05:25.0
> +0100
> @@ -1,3 +1,10 @@
> +istgt (0.4~20111008-3.1) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Fix ftbfs with GCC-10. (Closes: #957380)
> +
> + -- Sudip Mukherjee Wed, 12 Aug 2020 19:05:25
> +0100
> +
> istgt (0.4~20111008-3) unstable; urgency=low
>
> * Fix "cannot determine device size from symlink" Apply patch to use stat()
> diff -Nru istgt-0.4~20111008/debian/patches/fix_ftbfs.patch
> istgt-0.4~20111008/debian/patches/fix_ftbfs.patch
> --- istgt-0.4~20111008/debian/patches/fix_ftbfs.patch 1970-01-01
> 01:00:00.0 +0100
> +++ istgt-0.4~20111008/debian/patches/fix_ftbfs.patch 2020-08-12
> 19:05:25.0 +0100
> @@ -0,0 +1,31 @@
> +Description: Fix ftbfs with GCC-10
> + The enum variable is not used, use that as the enum name to declare it.
> +
> +Author: Sudip Mukherjee
> +Bug-Debian: https://bugs.debian.org/957380
> +Forwarded: no
> +---
> +
> +--- istgt-0.4~20111008.orig/src/istgt_lu.h
> istgt-0.4~20111008/src/istgt_lu.h
> +@@ -270,16 +270,16 @@ typedef struct istgt_lu_cmd_t {
> + } ISTGT_LU_CMD;
> + typedef ISTGT_LU_CMD *ISTGT_LU_CMD_Ptr;
> +
> +-enum {
> ++enum ISTGT_LU_TASK_RESULT {
> + ISTGT_LU_TASK_RESULT_IMMEDIATE = 0,
> + ISTGT_LU_TASK_RESULT_QUEUE_OK = 1,
> + ISTGT_LU_TASK_RESULT_QUEUE_FULL = 2,
> +-} ISTGT_LU_TASK_RESULT;
> ++};
> +
> +-enum {
> ++enum ISTGT_LU_TASK_TYPE {
> + ISTGT_LU_TASK_RESPONSE = 0,
> + ISTGT_LU_TASK_REQPDU = 1,
> +-} ISTGT_LU_TASK_TYPE;
> ++};
> +
> + typedef struct istgt_lu_task_t {
> + int type;
> diff -Nru istgt-0.4~20111008/debian/patches/series
> istgt-0.4~20111008/debian/patches/series
> --- istgt-0.4~20111008/debian/patches/series 2012-06-26 22:04:42.0
> +0100
> +++ istgt-0.4~20111008/debian/patches/series 2020-08-12 19:00:39.0
> +0100
> @@ -3,3 +3,4 @@
> fix-as-needed-build.patch
> fix-autosize.patch
> add-reload.patch
> +fix_ftbfs.patch
>
Bug#957380: istgt: diff for NMU version 0.4~20111008-3.1
Control: tags 957380 + patch
Control: tags 957380 + pending
Dear maintainer,
I've prepared an NMU for istgt (versioned as 0.4~20111008-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru istgt-0.4~20111008/debian/changelog
istgt-0.4~20111008/debian/changelog
--- istgt-0.4~20111008/debian/changelog 2012-06-26 23:25:01.0 +0100
+++ istgt-0.4~20111008/debian/changelog 2020-08-12 19:05:25.0 +0100
@@ -1,3 +1,10 @@
+istgt (0.4~20111008-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957380)
+
+ -- Sudip Mukherjee Wed, 12 Aug 2020 19:05:25
+0100
+
istgt (0.4~20111008-3) unstable; urgency=low
* Fix "cannot determine device size from symlink" Apply patch to use stat()
diff -Nru istgt-0.4~20111008/debian/patches/fix_ftbfs.patch
istgt-0.4~20111008/debian/patches/fix_ftbfs.patch
--- istgt-0.4~20111008/debian/patches/fix_ftbfs.patch 1970-01-01
01:00:00.0 +0100
+++ istgt-0.4~20111008/debian/patches/fix_ftbfs.patch 2020-08-12
19:05:25.0 +0100
@@ -0,0 +1,31 @@
+Description: Fix ftbfs with GCC-10
+ The enum variable is not used, use that as the enum name to declare it.
+
+Author: Sudip Mukherjee
+Bug-Debian: https://bugs.debian.org/957380
+Forwarded: no
+---
+
+--- istgt-0.4~20111008.orig/src/istgt_lu.h
istgt-0.4~20111008/src/istgt_lu.h
+@@ -270,16 +270,16 @@ typedef struct istgt_lu_cmd_t {
+ } ISTGT_LU_CMD;
+ typedef ISTGT_LU_CMD *ISTGT_LU_CMD_Ptr;
+
+-enum {
++enum ISTGT_LU_TASK_RESULT {
+ ISTGT_LU_TASK_RESULT_IMMEDIATE = 0,
+ ISTGT_LU_TASK_RESULT_QUEUE_OK = 1,
+ ISTGT_LU_TASK_RESULT_QUEUE_FULL = 2,
+-} ISTGT_LU_TASK_RESULT;
++};
+
+-enum {
++enum ISTGT_LU_TASK_TYPE {
+ ISTGT_LU_TASK_RESPONSE = 0,
+ ISTGT_LU_TASK_REQPDU = 1,
+-} ISTGT_LU_TASK_TYPE;
++};
+
+ typedef struct istgt_lu_task_t {
+ int type;
diff -Nru istgt-0.4~20111008/debian/patches/series
istgt-0.4~20111008/debian/patches/series
--- istgt-0.4~20111008/debian/patches/series2012-06-26 22:04:42.0
+0100
+++ istgt-0.4~20111008/debian/patches/series2020-08-12 19:00:39.0
+0100
@@ -3,3 +3,4 @@
fix-as-needed-build.patch
fix-autosize.patch
add-reload.patch
+fix_ftbfs.patch
Bug#968303: fish-common: pkgconfig lists /usr/local
Package: fish-common Version: 3.1.2-3 Severity: normal The pkgconfig file fish.pc lists prefix=/usr datadir=/usr/share completionsdir=/usr/local/share/fish/vendor_completions.d functionsdir=/usr/local/share/fish/vendor_functions.d confdir=/usr/local/share/fish/vendor_conf.d I think that the /usr/local part should be replaced by /usr, otherwise packages that depend on fish.pc to get the completions directory will install into /usr/local, which is a no-go in Debian. Futhermore, the variable $fish_completion_path still lists loads of flatpak directories, which are not available in Debian, and should preferrably be removed. Thanks Norbert -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.1 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fish-common depends on: ii libjs-jquery 3.5.1+dfsg-4 Versions of packages fish-common recommends: ii fish 3.1.2-3 fish-common suggests no packages. -- no debconf information
Bug#968302: src:dovecot: multiple dovecot CVEs
Package: src:dovecot Version: 1:2.3.10.1+dfsg1-2 Severity: grave Tags: security bullseye sid Justification: user security hole Multiple security issues have been identified in dovecot. These were addressed in stable with dovecot 1:2.3.4.1-5+deb10u3 (DSA 4745-1), but need to be tracked in unstable and testing. >From the DSA: CVE-2020-12100 Receiving mail with deeply nested MIME parts leads to resource exhaustion as Dovecot attempts to parse it. CVE-2020-12673 Dovecot's NTLM implementation does not correctly check message buffer size, which leads to a crash when reading past allocation. CVE-2020-12674 Dovecot's RPA mechanism implementation accepts zero-length message, which leads to assert-crash later on.
Bug#968300: doesn't build without real root
Package: systemd Version: 241-7~deb10u4.1+0~zgSID+1 Severity: serious Tags: ftbfs Justification: [buster] fails to build from source Hi, I am trying to do a local build of systemd 241 on buster to fix the capabilities issue (#964026). In this process, I have found out that systemd does need "real root" when building and is neiter satisfied with a non-root build nor with fakeroot: (build tail after dpkd-buildpackage) mv debian/systemd/lib/systemd/system/tmp.mount debian/systemd/usr/share/systemd/ printf '\n[Install]\nWantedBy=local-fs.target\n' >> debian/systemd/usr/share/systemd/tmp.mount rm debian/systemd/lib/systemd/system/local-fs.target.wants/tmp.mount # files shipped by cryptsetup rm debian/systemd/usr/share/man/man5/crypttab.5 # files shipped by systemd rm debian/udev/lib/udev/rules.d/70-uaccess.rules rm debian/udev/lib/udev/rules.d/73-seat-late.rules rm debian/udev/lib/udev/rules.d/71-seat.rules rm debian/udev/lib/udev/rules.d/99-systemd.rules # remove duplicate files shipped by systemd-*/udev echo "Removing duplicate files in systemd package:" Removing duplicate files in systemd package: set -e; for pkg in systemd-sysv systemd-container systemd-journal-remote systemd-coredump systemd-tests libpam-systemd libnss-myhostname libnss-mymachines libnss-resolve libnss-systemd libsystemd0 libsystemd-dev udev libudev1 libudev-dev; do \ echo "... from $pkg..."; \ (cd debian/$pkg; find -type f -o -type l) | (cd debian/systemd; xargs rm -f --verbose); \ (cd debian/$pkg; find -mindepth 1 -type d | sort -r) | (cd debian/systemd; xargs rmdir --ignore-fail-on-non-empty --verbose || true); \ done ... from systemd-sysv... /srv/mh/systemd/systemd-241/debian/systemd rm: cannot remove '/srv/mh/systemd/systemd-241/debian/systemd-sysv': Is a directory removed './usr/share/man/man1/init.1' removed './usr/share/man/man8/telinit.8' removed './usr/share/man/man8/poweroff.8' removed './usr/share/man/man8/halt.8' removed './usr/share/man/man8/shutdown.8' removed './usr/share/man/man8/runlevel.8' removed './usr/share/man/man8/reboot.8' make[1]: *** [debian/rules:244: override_dh_install] Error 123 make[1]: Leaving directory '/srv/mh/systemd/systemd-241' make: *** [debian/rules:305: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Same error happens with dpkg-buildpackage -rfakeroot. only dpkg-buildpakcage -rsudo runs beyond this place to fail in the test suite. In my understanding of "rules-requires-root: no", the packages should build even without fakeroot. I currently cannot verify with the software in unstable since the build on unstable fails way earlier. How would I build stable systemd on Debian stable? Greetings Marc -- Package-specific info: -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-zgsrv20080 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-4 ii libapparmor1 2.13.2-10 ii libaudit11:2.8.4-3 ii libblkid12.33.1-0.1 ii libc62.28-10 ii libcap2 1:2.25-2 ii libcryptsetup12 2:2.1.0-5+deb10u2 ii libgcrypt20 1.8.4-5 ii libgnutls30 3.6.7-4+deb10u5 ii libgpg-error01.35-1 ii libidn11 1.33-2.2 ii libip4tc01.8.2-4 ii libkmod2 26-1 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libmount12.33.1-0.1 ii libpam0g 1.3.1-5 ii libseccomp2 2.3.3-4 ii libselinux1 2.8-1+b1 ii libsystemd0 241-7~deb10u4.1+0~zgSID+1 ii mount2.33.1-0.1 ii util-linux 2.33.1-0.1 Versions of packages systemd recommends: ii dbus1.12.20-0+deb10u1 ii libpam-systemd 241-7~deb10u4.1+0~zgSID+1 Versions of packages systemd suggests: pn policykit-1 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.133+deb10u1 ii udev 241-7~deb10u4 -- no debconf information
Bug#968299: Desktot Xfcee in English and locales in Portuguese
Package: locales Version: 2.24-11+deb9u4 Severity: normal Tags: l10n I would like to have Xfce in English and locales in Portuguese, automatically based on installation of Xfce. It is possible in Gnome to have this kind of configuration. -- 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-13-amd64 (SMP w/2 CPU cores) Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.61 ii libc-bin 2.24-11+deb9u4 ii libc-l10n 2.24-11+deb9u4 locales recommends no packages. locales suggests no packages. -- debconf information: * locales/locales_to_be_generated: en_GB.UTF-8 UTF-8, pt_PT.UTF-8 UTF-8 * locales/default_environment_locale: pt_PT.UTF-8
Bug#744401: snowdrop: diff for NMU 0.02b-12.1
On 2020-08-12 David da Silva Polverari wrote: > Version: 0.02b-12.1 > Closing this bug, as a package that contains the diff already entered > the Debian archive. David, this bug tracks the fact that the changes in the NMU have NOT been integrated into a maintainer upload. So it should stay open until that has happened, afaik. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#966649: [UDD] Upload_history table is currently empty
Hi guys, I would like to say this bug revives #922546. I hope that in the short-term a solution to it will be found. Thanks for all efforts to fix it. Regards, Eriberto
Bug#968298: bind9-libs: SEGFAULT on redundant dhcp server configuration
Source: bind9-libs
Version: 1:9.11.19+dfsg-1
Severity: important
tags: patch
Hello, I tried to setup a balanced dhcp server and the service got crashing
after some seconds (both primary and secondary)
this patch, from Ubuntu fixes the issue
(I asked to forward upstream too)
diff -Nru bind9-libs-9.11.19+dfsg/debian/changelog
bind9-libs-9.11.19+dfsg/debian/changelog
--- bind9-libs-9.11.19+dfsg/debian/changelog2020-05-19 22:19:50.0
+0200
+++ bind9-libs-9.11.19+dfsg/debian/changelog2020-08-11 15:25:14.0
+0200
@@ -1,3 +1,11 @@
+bind9-libs (1:9.11.19+dfsg-2) unstable; urgency=medium
+
+ [ Jorge Niedbalski ]
+ * debian/patches/0010-fix-1872118.patch: Check if pending_send
+if set before calling dispatch_send. Fixes LP: #1872118.
+
+ -- Gianfranco Costamagna Tue, 11 Aug 2020
15:25:14 +0200
+
bind9-libs (1:9.11.19+dfsg-1) unstable; urgency=medium
* New upstream version 9.11.19+dfsg
diff -Nru bind9-libs-9.11.19+dfsg/debian/patches/0010-fix-1872118.patch
bind9-libs-9.11.19+dfsg/debian/patches/0010-fix-1872118.patch
--- bind9-libs-9.11.19+dfsg/debian/patches/0010-fix-1872118.patch
1970-01-01 01:00:00.0 +0100
+++ bind9-libs-9.11.19+dfsg/debian/patches/0010-fix-1872118.patch
2020-08-11 15:25:08.0 +0200
@@ -0,0 +1,22 @@
+Description: Check if sock->pending_send is set
+before calling dispatch_send(). This would prevent
+the assertion failure in cases where a socket is not dead (closed)
+and its still pending to send data and the process_fd
+event gets triggered due a wakeup.
+
+Author: Jorge Niedbalski
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1872118
+Forwarded: no
+Last-Update: 2020-08-03
+
+--- bind9-libs-9.11.16+dfsg.orig/lib/isc/unix/socket.c
bind9-libs-9.11.16+dfsg/lib/isc/unix/socket.c
+@@ -4050,7 +4050,7 @@ check_write:
+ if (!SOCK_DEAD(sock)) {
+ if (sock->connecting)
+ dispatch_connect(sock);
+- else
++ else if (!sock->pending_send)
+ dispatch_send(sock);
+ }
+ unwatch_write = true;
diff -Nru bind9-libs-9.11.19+dfsg/debian/patches/series
bind9-libs-9.11.19+dfsg/debian/patches/series
--- bind9-libs-9.11.19+dfsg/debian/patches/series 2020-05-19
22:19:50.0 +0200
+++ bind9-libs-9.11.19+dfsg/debian/patches/series 2020-08-11
15:25:14.0 +0200
@@ -7,3 +7,4 @@
0007-skip-rtld-deepbind-for-dyndb.diff
0008-Use-absolute-srcdir-path-to-protoc-c-invocation.patch
0009-python-fix-for-dist-packages.patch
+0010-fix-1872118.patch
please apply if possible!
G.
Bug#968200: missing files for bblxml features
> There should be no critical changes, I'll upload. Thanks! Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#968284: ITP: node-prosemirror-schema-list -- exports schema elements and commands in a ProseMirror editor.
Package: wnpp Severity: wishlist Owner: Abraham Raji X-Debbugs-CC: debian-de...@lists.debian.org * Package name : node-prosemirror-schema-list Version : 1.1.4 Upstream Author : 2015-2017 by Marijn Haverbeke and others * URL : https://github.com/prosemirror/prosemirror-schema-list#readme * License : Expat Programming Lang: JavaScript Description : exports schema elements and commands in a ProseMirror editor. This module exports schema elements and commands for including lists in a ProseMirror editor. . Node.js is an event-based server-side JavaScript engine. This package is a dependency for the prosemirror editor. I will package this module myself. But I will require sponsorship to upload. I contribute to the Debian JS Team Abraham Raji
Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load
Hi, Just commenting on the following: On Wed, Aug 12, 2020 at 05:53:57PM +0200, Dirk Kostrewa wrote: [...] > What puzzles me, is that I've observed these oddly behaving kworker > processes also with the 5.6 kernel that I've tried from the Buster Backports > repository. The mentioned commit, is included in the following upstream versions (relevant for Debian): v4.19.119 (so in buster), v5.6.8 (and so the buster-backports kernel), v5.7-rc3. Regards, Salvatore
Bug#968296: buster-pu: calamares-settings-debian 10.0.20-1+deb10u4
package: release.debian.org thanks Dear release team, Below follows a debdiff betwewn calamares-settings-debian 10.0.20-1+deb10u3 and 10.0.20-1+deb10u4, which reverts the patch introduced in +deb10u2 to enable the displaymanager module. While it fixed the bugs on other display managers, it introduced to big regressions when using gdm3, fixes #968267. """ diff -Nru calamares-settings-debian-10.0.20/debian/changelog calamares-settings-debian-10.0.20/debian/changelog --- calamares-settings-debian-10.0.20/debian/changelog 2020-07-15 18:15:49.0 +0200 +++ calamares-settings-debian-10.0.20/debian/changelog 2020-08-05 18:33:04.0 +0200 @@ -1,3 +1,10 @@ +calamares-settings-debian (10.0.20-1+deb10u4) buster; urgency=medium + + * Disable displaymanager module, reverting the change from deb10u2 +(Closes: #968267) + + -- Jonathan Carter Wed, 05 Aug 2020 18:33:04 +0200 + calamares-settings-debian (10.0.20-1+deb10u3) buster; urgency=medium * Use xdg-user-dir to specify Desktop directory diff -Nru calamares-settings-debian-10.0.20/debian/patches/enable-displaymanagers-module calamares-settings-debian-10.0.20/debian/patches/enable-displaymanagers-module --- calamares-settings-debian-10.0.20/debian/patches/enable-displaymanagers-module 2020-07-15 17:40:59.0 +0200 +++ calamares-settings-debian-10.0.20/debian/patches/enable-displaymanagers-module 1970-01-01 02:00:00.0 +0200 @@ -1,49 +0,0 @@ -Description: Enable display manager module, allowing autologins to work - * Enable displaymanager module, fixing autologin options - (Closes: #934503, #934504) -Author: Jonathan Carter -Bug-Debian: https://bugs.debian.org/934503 -Bug-Debian: https://bugs.debian.org/934504 -Last-Update: 2020-07-15 - /dev/null -+++ calamares-settings-debian-10.0.20/calamares/modules/displaymanager.conf -@@ -0,0 +1,28 @@ -+# Configure one or more display managers (e.g. SDDM) -+# with a "best effort" approach. -+--- -+#The DM module attempts to set up all the DMs found in this list, in that precise order. -+#It also sets up autologin, if the feature is enabled in globalstorage. -+#The displaymanagers list can also be set in globalstorage, and in that case it overrides anything set up here. -+displaymanagers: -+ - slim -+ - sddm -+ - lightdm -+ - gdm -+ - mdm -+ - lxdm -+ - kdm -+ -+#Enable the following settings to force a desktop environment in your displaymanager configuration file: -+#defaultDesktopEnvironment: -+#executable: "startkde" -+#desktopFile: "plasma" -+ -+#If true, try to ensure that the user, group, /var directory etc. for the -+#display manager are set up correctly. This is normally done by the distribution -+#packages, and best left to them. Therefore, it is disabled by default. -+basicSetup: false -+ -+#If true, setup autologin for openSUSE. This only makes sense on openSUSE -+#derivatives or other systems where /etc/sysconfig/displaymanager exists. -+sysconfigSetup: false calamares-settings-debian-10.0.20.orig/calamares/settings.conf -+++ calamares-settings-debian-10.0.20/calamares/settings.conf -@@ -36,6 +36,7 @@ sequence: - - keyboard - - localecfg - - users -+ - displaymanager - - networkcfg - - hwclock - - services-systemd diff -Nru calamares-settings-debian-10.0.20/debian/patches/series calamares-settings-debian-10.0.20/debian/patches/series --- calamares-settings-debian-10.0.20/debian/patches/series 2020-07-15 18:15:49.0 +0200 +++ calamares-settings-debian-10.0.20/debian/patches/series 2020-08-05 18:33:04.0 +0200 @@ -1,3 +1,2 @@ fix-initramfs-permissions -enable-displaymanagers-module use-xdg-user-dir """ thanks, -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load
Hi Salvatore,
I just found out, that if none of the two USB ports is connected, there
are two kworker processes with permanently high CPU load, if one USB
port is connected and the other not, there is one such kworker process,
and if both USB ports are connected, there is no kworker process with
high CPU load.
I think, this supports your suspicion that these kworker processes are
connected with the overcurrent condition for both USB ports that I also
see in the dmesg output.
What puzzles me, is that I've observed these oddly behaving kworker
processes also with the 5.6 kernel that I've tried from the Buster
Backports repository.
Cheers,
Dirk.
Am 12.08.20 um 13:02 schrieb Dirk Kostrewa:
Hi Salvatore,
yesterday, I installed the kernel 5.6.0 from the Buster Backports and
saw again a kworker process with high CPU load.
Oddly, this morning, my laptop didn't boot, so I decided to do a fresh
install of Debian Buster 10.5.0 (image with non-free firmware because
of my wifi card) and installed only thunderbird and vim. There is
still one kworker process with permanently high CPU load.
I gave the dyndbg command that you told me as a kernel parameter upon
booting and have appended the dmesg output as file dmesg.txt.gz.
Cheers,
Dirk.
Am 11.08.20 um 21:21 schrieb Salvatore Bonaccorso:
Hi Dirk,
On Tue, Aug 11, 2020 at 12:58:15PM +0200, Dirk Kostrewa wrote:
Hi Salavatore,
as an additional control, I have completely uninstalled the nvidia
graphics
driver and repeated the kworker observations using the nouveau graphics
driver with the kernel 4.19.0-10-amd64. This time, there are even two
kworker processes constantly running with high CPU load:
$ top
top - 12:37:20 up 10 min, 4 users, load average: 2.79, 2.54, 1.56
Tasks: 197 total, 3 running, 194 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 24.2 sy, 0.0 ni, 74.2 id, 0.0 wa, 0.0 hi, 1.6
si, 0.0
st
MiB Mem : 15889.4 total, 13964.7 free, 626.8 used, 1297.9
buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 14849.1
avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
164 root 20 0 0 0 0 R 80.0 0.0 8:41.67
kworker/6:2+pm
455 root 20 0 0 0 0 R 80.0 0.0 8:28.23
kworker/2:2+pm
22 root 20 0 0 0 0 S 20.0 0.0 2:14.82
ksoftirqd/2
42 root 20 0 0 0 0 S 20.0 0.0 2:08.67
ksoftirqd/6
1 root 20 0 169644 10212 7796 S 0.0 0.1 0:01.52
systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00
kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00
rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00
rcu_par_gp
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00
kworker/0:0H-kblockd
7 root 20 0 0 0 0 I 0.0 0.0 0:00.05
kworker/u16:0-event+
The stacks of the two kworker processes show the same output:
[<0>] 0x
I have appended the top 5000 lines tracing as a compressed ascii file
out-cut.txt,gz and the dmesg output as compressed ascii file
dmesg.txt.gz.
I hope, this helps to find out where the problem with the high CPU
load of
the kworker processes come from.
Thanks this is very helpful.
I suspect what you are seeing is an issue with the usb hubport present
before but now uncovered due to the upstream change e9fb08d617bf
("xhci: prevent bus suspend if a roothub port detected a over-current
condition")[1], which was as well backported to v4.19.y in 4.19.119.
Can you add some dynamic debugging on the 'drivers/usb/'[2] ideally at
boot time. On runtime it is
# echo 'file drivers/usb/* +p;' >
/sys/kernel/debug/dynamic_debug/control
or as kernel parameter to have enable the debug messages at boot time
already:
dyndbg="file drivers/usb/* +p;"
Can you attach the dmesg with the enabled debugging?
Regards,
Salvatore
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9fb08d617bfae5471d902112667d0eeb9dee3c4
[2]
https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html
Bug#957837: sprng: ftbfs with GCC-10
Hi, This patch fixes the build. Let me know if something else is needed: --- a/SRC/primes_32.c +++ b/SRC/primes_32.c @@ -7,7 +7,7 @@ #define NO 0 #define NPRIMES 1000 -int primes[NPRIMES]; +extern int primes[NPRIMES]; #ifdef __STDC__ int init_prime_32(void) Kind Regards, Nilesh
Bug#968295: libc version details
results of "ls -l /lib/*/libc.so.6" from initramfs prompt: lrwxrwxrwx 1 root 0 12 Aug 12 15:19 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.28.so
Bug#968295: lvm cannot process volume group on boot
Package: lvm Version: 2.0 I have a Debian 9 XFCE system on a acer laptop with only 1 hard drive which was encrypted with LVM encryption during installation. After a recent reboot my system is stuck and no longer bootable with following messages: Volume group "acerv3-575t-vg" not found. Cannot process volume group acerv3-575-vg Save up waiting for suspend/resume device Volume group "acerv3-575t-vg" not found. Cannot process volume group acerv3-575-vg save up waiting for root file system device. Common problems: -Boot args (cat /proc/ cmdline) -check rootdelay = (did the system wait long enough?) -missing modules (cat /proc/modules; ls /dev) Alert!! /dev/mapper/acerv3-575t-vg-root does not exist. Dropping to a shell! BusyBox v1.30.1 (Debian 1:1.30.1-4) built in shell (ash) (initramfs) results of "uname -a": Linux (none) 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux results of "blkid": /dev/sda1: UUID="8c128c67-b83f-4324-8ec7-98f92d226834" TYPE="ext2" PARTUUID="067c99ad-01" /dev/sda5: UUID="fc11dfff-5424-4384-990e-26eda907f036" TYPE="crypto_LUKS" PARTUUID="067c99ad-05" I am able to use a Debian Live CD and access the system via the Advanced Options -> "Graphical Rescue mode" CLI interface: from Rescue Mode LiveCD it successfully asks my passphrase for the encrypted volume (/dev/sda5) and unlocks it. >From Rescue Mode LiveCD I am then able to login to my root file system /dev/acerv3-575t-vg/root & mount its /boot partition from this point I can successfully execute a shell in /dev/acerv3-575t-vg/root OR in the installer environment. (The below commands where executed in the shell for /dev/acerv3-575t-vg/root) root@acerv3-575t:/# nano /etc/fstab # /dev/mapper/acerv3--575t-vg-root /ext4 errors=remount-ro 0 1 #boot was on /dev/sda1 during installation UUID=8c128c67-b83f-4324-8ec7-98f92d226834 /boot ext2 defaults 0 2 /dev/mapper/acerv3--575t-vg-home /homeext4 defaults 0 2 /dev/mapper/acerv3--575t-vg-tmp /tmp ext4 defaults 0 2 /dev/mapper/acerv3--575t-vg-var /var ext4 defaults 0 2 /dev/mapper/acerv3--575t-vg-swap_1 /noneswap sw 0 0 /dev/sr0 /media/cdrom0udf,iso9660 user, noauto 0 0 root@acerv3-575t:/# nano /etc/crypttab sda5_crypt UID=fc11dfff-5424-4384-990e-26eda907f036 none luks,discard root@acerv3-575t:/# pvscan PV /dev/dm-0 VG acerv3-575t-vg lvm2 [931.25 GiB / 36.00 MiB free] Total: 1 [931.25GiB] / in use: 1 [931.25 GiB] / in no VG: 0 [0 ] root@acerv3-575t:/#pvs PV VG Fmt Attr PSize PFree /dev/dm-0 acerv3-575t-vg lvm2 a-- 931.25g 36.00m root@acerv3-575t:/#pvdisplay --- Physical Volume --- PV Name/dev/dm-0 VG Nameacerv3-575t-vg PV Size<931.26GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00MiB Total PE238401 Free PE 9 Allocated PE238392 PV UUIDX------pgLCl9 #vgck does not return any errors... root@acerv3-575t:/#vgck root@acerv3-575t:/# root@acerv3-575t:/#fdisk -l Disk /dev/sda: 931.5GiB, 1000204886016 bytes, 1953525168 Sectors Disk model: TOSHIBA MQ01ADB1 Units: secotors of 1 * 512 = 512 byes Sector Size (logical/physical): 512 bytes/ 4096 byes I/O Size (minimum/optimal: 4096 bytes/ 4096 bytes Disk label type: dos Disk Identifiver 0x067c99ad Device Boot start end sectors size id Type /dev/sda1 * 2048 499711 497664 243M 83 Linux /dev/sda2 501758 1953523711 1953021954 931.3G 5 Extended /dev/sda5 501760 1953523711 1953021952 931.3G 83 Linux Partition 2 does not start on physical sector boundry. Disk /dev/mapper/sda5_crypt: 931.3 GiB, 30462208 byes, 1952989184 sectors Units: sectors of 1 * 512 = 512 bytes Sector Size (logical/physical): 512 bytes/4096 bytes I/O size (minimum/optimal): 4096 bytes/4096 bytes Disk /dev/mapper/acerv3--575t--vg-root: 23.3GiB 24998051840 bytes, 48824320 sectors Units: sectors of 1 * 512 = 512 bytes Sector Size (logical/physical): 512 bytes/4096 bytes I/O size (minimum/optimal): 4096 bytes/4096 bytes Disk /dev/mapper/acerv3--575t--vg-var: 9.3GiB 220736 bytes, 19529728 sectors Units: sectors of 1 * 512 = 512 bytes Sector Size (logical/physical): 512 bytes/4096 bytes I/O size (minimum/optimal): 4096 bytes/4096 bytes Disk /dev/mapper/acerv3--575t--vg-tmp: 1.9GiB, 1996488704 bytes, 3899392 sectors Units: sectors of 1 * 512 = 512 bytes Sector Size (logical/physical): 512 bytes/4096 bytes I/O size (minimum/optimal): 4096 bytes/4096 bytes Disk /dev/mapper/acerv3--575t--vg-swap_1: 15.9GiB, 1703726848 bytes, 33275904 sectors Units: sectors of 1 * 512 = 512 bytes Sector Size (logical/physical): 512 bytes/4096 bytes I/O size (minimum/optimal): 4096 bytes/4096 bytes Disk /dev/mapper/acerv3--575--vg-home: 880.9 GiB, 945857495050 bytes, 1847377920 sectors Units: sectors of 1 * 512 = 512 bytes Sector Size (logical/physical): 512
Bug#968294: dpkg: [INTL:nl] Dutch po file for dselect
Package: dpkg Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch po file for dselect. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as "dselect/po/nl.po" in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#968268: debian-edu-config: wakeupclients script fail because SiteSummary.pm is missing
Hi Petter, On Mi 12 Aug 2020 09:20:40 CEST, Petter Reinholdtsen wrote: Package: debian-edu-config Version: 2.10.65+deb10u6 Severity: normal There is an issue with how three Debian Edu packages interact. It involves debian-edu-config, sitesummary and shutdown-at-night. After setting up outgoing emails on my laptop, where debian-edu-config and shutdown-at-night, but not sitesummary, is installed, I started getting cron emails like this: Subject: Cron test -x /usr/lib/shutdown-at-night/wakeupclients && /usr/lib/shutdown-at-night/wakeupclients Can't locate SiteSummary.pm in @INC (you may need to install the SiteSummary module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /etc/shutdown-at-night/clients-generator line 7. BEGIN failed--compilation aborted at /etc/shutdown-at-night/clients-generator line 7. The cause seem to be that the cron job from shutdown-at-night (/etc/cron.d/shutdown-at-night) calls the /etc/shutdown-at-night/clients-generator script from debian-edu-config, which fail to work when SiteSummary.pm from the sitesummary package is not available. I suspect some dependencies need to be adjusted to ensure the perl module is available when needed, or the script need to cope with the missing module in a better way. the client-generator script in /etc/shutdown-at-night/ shipped in d-e-c requires SiteSummary.pm. So the quick fix would be a dependency of debian-edu-config on sitesummary. However, for your notebook setup this might feel like an overload. My approach would be to split out the Perl module SiteSummary.pm into a separate bin:pkg within the sitesummary src:pkg and then let d-e-c depend on libsitesummary-perl. Feedback? Too much of a change? Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpkFO9HyEsfG.pgp Description: Digitale PGP-Signatur
Bug#968009: Warn that there is no point of installing this package if using systemd
Control: tag -1 wontfix Dan, On Wed, 12 Aug 2020, at 16:54, 積丹尼 Dan Jacobson wrote: > I'm saying all machines that were around before systemd came along will > still have their resolvconf installed. > > Just like I used to have a telegraph, but now I have a telephone, but I > never took the steps I needed to remove the telegraph, so still have > the telegraph. By all means, if you don’t like or need resolvconf, don’t install or use it. I don’t think systemd-resolvd replaces resolvconf, so I still see a use case for it; more than that, systemd-resolvd is not mandatory to use even if you use systemd. There’s nothing more to be done on this issue. -- Cheers, Andrej
Bug#957029: ax25mail-utils is marked for autoremoval from testing
Re: David Ranch > I have built up a working Debian Sid image with GCC 10 and have reproduced > the issue with the "develop" branch of ax25mail-utils. I am working on > getting these issues resolved but how long do I have to get them addressed? > > On 08/11/2020 09:39 PM, Debian testing autoremoval watch wrote: > > ax25mail-utils 0.13-1 is marked for autoremoval from testing on 2020-08-26 ^^ > > It is affected by these RC bugs: > > 957029: ax25mail-utils: ftbfs with GCC-10 > > https://bugs.debian.org/957029 ... but the counter gets reset when new info is added to the bug (like with this Cc here). Christoph
Bug#967546: udev: missing /dev/stdin etc.
On Tue, 11 Aug 2020 14:55:14 +0200 Ansgar wrote: > On Tue, 2020-08-11 at 13:42 +0200, Cristian Ionescu-Idbohrn wrote: > > Yes. What else can match the enjoyment of breaking other peoples' > > systems? > > I recommend taking unhelpful comments like this to the so called > debian-init-diversity mailing list where Debian's code of conduct > doesn't apply. You can also enjoy calling people "sheeple" over there > if you are looking for things to enjoy. > > Otherwise, I think your comment just decreases the chance such bugs > will gets fixed. But maybe that is your intention? :-) I've opened up a wishlist bug report in sysvinit-core to set up /dev/stdin and others because I assume it's easier to get them to correct or reverse a problem like that. For the future, where should one voice the annoyance when a package repeatedly breaks other packages? Regards /M
Bug#968293: crash: alsa_stream_get_position: Assertion `delay >= 0' failed.
Package: firefox-esr
Version: 68.11.0esr-1~deb10u1+rpi1
Severity: normal
Dear Maintainer,
i am using firefox-esr on my Raspberry Pi 4 with 4GB, original power-supply and
Raspberry Pi OS (Debian)
(2020-05-27-raspios-buster-armhf.zip)
the system is up-to-date (sudo apt update && sudo apt full-upgrade -y).
i installed firefox-esr by using "sudo apt install firefox-esr"
when i watch videos (e.g. Youtube, Vimeo, ...) firefox-esr crash some times
randomly.
it is not related to specific videos or specific positions in the video, nor a
specific webpage/platform.
a video that played without any issue before may bring firefox-esr to crash the
next time i play it.
but all the time firefox-esr crashes, it will show the same message to the
console as reason:
firefox-esr:
/build/firefox-esr-RgOFaD/firefox-esr-68.11.0esr/media/libcubeb/src/cubeb_alsa.c:1255:
alsa_stream_get_position: Assertion `delay >= 0' failed.
ExceptionHandler::GenerateDump cloned child 3366
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Failed to open curl lib from binary, use libcurl.so instead
unfortunately i could not find the package firefox-esr-dbg for symbols on
Raspberry Pi OS distro, so the debugging information maybe not be very usefull:
firefox-esr:
/build/firefox-esr-RgOFaD/firefox-esr-68.11.0esr/media/libcubeb/src/cubeb_alsa.c:1255:
alsa_stream_get_position: Assertion `delay >= 0' failed.
Thread 14 "AudioIPC Server" received signal SIGABRT, Aborted.
[Switching to Thread 0xa97fe440 (LWP 7199)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0 , 32, 32, 0, 2, 2, 0, 44100, 44100,
0, 4460996, 31, 3070224744, 0, 0, 2584177792}}
pid =
tid =
ret =
#1 0xb6c21230 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x382d46, sa_sigaction =
0x382d46}, sa_mask = {__val = {3067432176, 3070224744, 3070224744, 3016622388,
1255, 3016622488, 0, 2843726660, 3066451772, 3067303760, 3067328240,
3063976592,
4, 11, 3666216192, 3067423768, 3067432176, 3070224744,
2843731008, 3016622388, 1255, 193088, 2598564416, 4460544, 4262216, 1255,
3064988072, 2843726704, 2729177088, 3016622104, 3067303600, 2729177088}},
sa_flags = -1278345192, sa_restorer = 0xb6d356b0}
sigs = {__val = {32, 0 }}
#2 0xb6c2ebb8 in __assert_fail_base (fmt=0xb6d356b0 "%s%s%s:%u: %s%sAssertion
`%s' failed.\n%n", assertion=0xb3ce0198 "delay >= 0",
assertion@entry=0xa97fe440 "\001",
file=0xb3ce0134
"/build/firefox-esr-RgOFaD/firefox-esr-68.11.0esr/media/libcubeb/src/cubeb_alsa.c",
file@entry=0xb3ce0018 "alsa_stream_get_position", line=1255,
line@entry=3067303600,
function=function@entry=0xb3ce0018 "alsa_stream_get_position") at
assert.c:92
str = 0x9ae2f240 "\310\311\r\264"
total = 4096
#3 0xb6c2ec6c in __GI___assert_fail (assertion=0xa97fe440 "\001",
file=0xb3ce0018 "alsa_stream_get_position", line=3067303600,
function=0xb3ce0018 "alsa_stream_get_position") at assert.c:101
No locals.
#4 0xb23633d4 in ?? () from /usr/lib/firefox-esr/libxul.so
No symbol table info available.
#5 0xb31f4524 in ?? () from /usr/lib/firefox-esr/libxul.so
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
-- Package-specific info:
-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled
Name: Default theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled
Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: eBay
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: Firefox Monitor
Location: /usr/lib/firefox-esr/browser/features/fxmoni...@mozilla.org.xpi
Package: firefox-esr
Status: enabled
Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled
Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled
Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: h264ify
Location: ${PROFILE_EXTENSIONS}/jid1-tsgsxbhncsp...@jetpack.xpi
Status: enabled
Name: Light theme
Location:
Bug#968009: Warn that there is no point of installing this package if using systemd
I'm saying all machines that were around before systemd came along will still have their resolvconf installed. Just like I used to have a telegraph, but now I have a telephone, but I never took the steps I needed to remove the telegraph, so still have the telegraph.
Bug#968292: gnome-disk-utility: SMART monitoring switched on again after reboot
Package: gnome-disk-utility Version: 3.30.2-3 Severity: normal Dear Maintainer, * What led up to the situation? After switching off "SMART Data & Self-Tests" for a disk, it is occasionally switched back on again after reboot. I apply this setting to several disks (three), they seem to be affected independently. Thus e.g.: for all three disks SMART is switched off, after reboot it is switched on for one an remains off for two of them. The behavior seems to be randomly. (I do that switching off because otherwise the disks do not go to standby, which is different story). * What exactly did you do (or not do) that was effective (or ineffective)? I repeatedly switched SMART off. I observed this behavior since I first used gnome disks some years ago (always using Debian stable). Kind regards, Olaf -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-disk-utility depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii libatk1.0-0 2.30.0-2 ii libc62.28-10 ii libcairo21.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libdvdread4 6.0.1-1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii liblzma5 5.2.4-1 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpwquality11.4.0-3 ii libsecret-1-00.18.7-1 ii libsystemd0 241-7~deb10u4 ii libudisks2-0 2.8.1-4 ii udisks2 2.8.1-4 gnome-disk-utility recommends no packages. gnome-disk-utility suggests no packages. -- no debconf information
Bug#936336: coz-profiler: Python2 removal in sid/bullseye
[Lluís Vilanova] > Unfortunately I do not have upload privileges and couldn't find > anybody that would keep uploading them for coz. I've managed to fix my key problems, and can do the upload. Is it ready to go in? -- Happy hacking Petter Reinholdtsen
Bug#953862: #953862 : any news
I have been bitten by this one, although in a slightly different context (using Sage's Maxima). Symptoms identical : a very short TeX file, sorely lacking any references to any LaTex package, and systematic failure. Any news ? -- Emmanuel Charpentier
Bug#968291: ITP: memtier-benchmark -- NoSQL load generation and benchmarking tool
Package: wnpp Severity: wishlist Owner: Yossi Gottlieb * Package name: memtier-benchmark Version : 1.3.0 Upstream Author : Redis Labs * URL : https://github.com/RedisLabs/memtier_benchmark * License : GPLv2 Programming Lang: C++ Description : NoSQL load generation and benchmarking tool memtier_benchmark is a command line utility developed by Redis Labs for load generation and bechmarking NoSQL key-value databases such as Redis and Memcached. It offers the following: * Support for both Redis and Memcache protocols (text and binary) * Multi-threaded multi-client execution * Many dataset and workload configuration options Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
Bug#968290: please update to 3.37.90 upstream (SIXEL support added)
Package: gnome-terminal Version: 3.36.2-1 Severity: wishlist There are some really cool apps which make use of SIXEL. Some terminals (e.g. xterm) already have support for it. gnome-terminal only (very recently! apparently) recently added support for it in 3.37.90. $> git show 3.37.90 | head -n 20 tag 3.37.90 Tagger: Christian Persch Date: Sat Aug 8 22:02:09 2020 +0200 Version 3.37.90 Git-EVTag-v0-SHA512: d61e6d9e149a2ffa59f6ad9f2efeb93d2a7606697227d41ac678a13ce707c18018dae21b09a41afa6c63669f783fbdfe7735fac9e081f7faf6b2998efa723cef commit 0acb0d1d8da957ab43d73cb51d3142fc99c28ca7 Author: Christian Persch Date: Sat Aug 8 21:57:15 2020 +0200 profile: Add pref to enable SIXEL When VTE was built with SIXEL support, show a checkbox in the compatibility prefs to enable it. https://gitlab.gnome.org/GNOME/vte/-/issues/253 It would be really cool if stock (could go to experimental I guess if some concerns over stability etc) gnome-terminal in Debian gained sixel support as well. thank you very much in advance! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 'unstable-debug'), (100, 'stable-updates'), (100, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 ii dbus-x11 [dbus-session-bus] 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gnome-terminal-data 3.36.1.1-3 ii gsettings-desktop-schemas 3.36.0-1 ii libatk1.0-0 2.36.0-2 ii libc6 2.30-4 ii libdconf1 0.36.0-1 ii libglib2.0-0 2.64.2-1 ii libgtk-3-03.24.20-1 ii libpango-1.0-01.44.7-4 ii libuuid1 2.34-0.1 ii libvte-2.91-0 0.60.3-1 ii libx11-6 2:1.6.9-2 Versions of packages gnome-terminal recommends: ii gvfs 1.44.1-1 ii nautilus-extension-gnome-terminal 3.36.2-1 ii yelp 3.34.0-1 gnome-terminal suggests no packages. -- debconf-show failed
Bug#968289: python3-venv: contains a dangling soft link
Package: python3-venv Version: 3.8.2-3 Severity: normal X-Debbugs-Cc: none Dear Matthias Klose, this package contains the dangling softlink /usr/share/man/man1/pyvenv.1.gz -> pyvenv-3.8.1.gz There seems to be no package in sid containing a file named "pyvenv-3.8.1.gz". Any idea? 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.7.14 (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 python3-venv depends on: ii python33.8.2-3 ii python3-distutils 3.8.5-1 ii python3.8-venv 3.8.5-2 python3-venv recommends no packages. python3-venv suggests no packages. -- no debconf information
Bug#968288: link python man page so "man python" will find it
Package: python3.8-minimal Version: 3.8.5-2 Severity: minor File: /usr/share/man/man1/python3.8.1.gz File says python \- an interpreted, interactive, object-oriented programming language so it should be linked properly so $ man python will find it.
Bug#968286: gitlab: adding log rotation
Package: gitlab
Version: 13.1.6-1+fto10+1
Severity: wishlist
Tags: patch
Gitlab usage with tens of people specially with CI lead to huge log files which
should be rotated. This feature does not exist for instance in 13.1.6-1+fto10+1
version.
To achieve that I used the following configuration file located in
/etc/logrotate.d/gitlab:
/var/log/gitlab/*.log {
daily
rotate 15
copytruncate
delaycompress
compress
notifempty
missingok
}
As I don't know how to tell gitlab to stop writing logs during rotation, I
choose to inspire myself on postgresql configuration which handle that using
copytruncate and delaycompress options.
This configuration should rotate log every day and purge logs older than 15
days. You may want to tweak these parameters.
Hopefully this will be helpfull,
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 10.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (100,
'buster-fasttrack'), (100, 'buster-backports')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gitlab depends on:
ii asciidoctor2.0.10-2~bpo10+1
ii bc 1.07.1-2+b1
ii bundler2.1.4-2~bpo10+1
ii bzip2 1.0.6-9.2~deb10u1
ii dbconfig-pgsql 2.0.11+deb10u1
ii debconf [debconf-2.0] 1.5.71
ii exim4-daemon-light [mail-transport-agent] 4.94-7~bpo10+1
ii gitlab-common 13.1.0+dfsg-1~bpo10+1
ii gitlab-workhorse 8.37.0+debian-1~bpo10+1
ii libjs-bootstrap4 [node-bootstrap] 4.3.1+dfsg2-1
ii libjs-codemirror [node-codemirror] 5.54.0-2~bpo10+1
ii libjs-popper.js [node-popper.js] 1.14.6+ds2-1
ii libjs-uglify 2.8.29-6
ii libruby2.7 [ruby-json] 2.7.1-3+fto10+2
ii lsb-base 10.2019051400
ii nginx 1.14.2-2+deb10u2
ii nginx-full [nginx] 1.14.2-2+deb10u2
ii node-autosize 4.0.2~dfsg1-3
ii node-axios 0.17.1+dfsg-2
ii node-babel-loader 8.1.0-3~bpo10+1
ii node-babel77.4.5+~cs7.3.8-1~bpo10+1
ii node-brace-expansion 1.1.8-1
ii node-cache-loader 4.1.0-1~bpo10+1
ii node-chart.js 2.7.3+dfsg-5
ii node-clipboard 2.0.6+ds-1~bpo10+1
ii node-compression-webpack-plugin3.0.1-1~bpo10+1
ii node-core-js 3.6.1-2~bpo10+2
ii node-css-loader2.1.1-1~bpo10+1
ii node-d35.16.0-1~bpo10+1
ii node-d3-scale 2.2.2-2~bpo10+1
ii node-d3-selection 1.4.0-3~bpo10+1
ii node-dateformat3.0.0-1
ii node-exports-loader0.7.0-2~bpo10+1
ii node-fuzzaldrin-plus 0.5.0+dfsg-1
ii node-glob 7.1.6-1~bpo10+1
ii node-imports-loader0.8.0-2~bpo10+1
ii node-jed 1.1.1-1
ii node-jquery3.4.0+dfsg-1~bpo10+1
ii node-jquery-ujs1.2.2-2
ii node-js-cookie 2.2.0-2
ii node-jszip 3.2.2+dfsg-1~bpo10+1
ii node-jszip-utils 0.0.2+dfsg-1
ii node-lodash4.17.15+dfsg-2~bpo10+1
ii node-marked0.5.1+dfsg-1
ii node-mousetrap 1.6.1+ds-1
ii node-prismjs 1.11.0+dfsg-3~bpo10+1
ii node-prosemirror-model 1.9.0-3~bpo10+1
ii node-raven-js 3.22.1+dfsg-2
ii node-three-orbit-controls 82.1.0-2
ii node-three-stl-loader 1.0.6-2
ii node-timeago.js4.0.2-2~bpo10+1
ii node-underscore1.9.1~dfsg-1
ii node-url-loader3.0.0-1~bpo10+1
ii node-vue 2.6.11+dfsg-1~bpo10+1
ii
Bug#968285: pcb-rnd-export-extra: incomplete list of plugins
Package: pcb-rnd-export-extra Severity: normal Dear Maintainer, the desription lists "fidocadj, ipc-356-d, direct printing with lpr" but the package contains also other plugins tha caa be added to the list: /usr/lib/pcb-rnd/plugins/export_oldconn.pup /usr/lib/pcb-rnd/plugins/export_oldconn.so /usr/lib/pcb-rnd/plugins/export_stl.pup /usr/lib/pcb-rnd/plugins/export_stl.so thank you, Daniele
Bug#966649: [UDD] Upload_history table is currently empty
Hi again, On Mon, Aug 03, 2020 at 11:20:21AM +0200, Andreas Tille wrote: > > > 'munge_ddc.py' has the following issues: > > > [...] > > > - it doesn't support xz email archives, so it's broken for recent > > > archives > > > > It used to work some months ago because it was relying on a huge > > debian-devel-changes.current. But ullmann ran out of disk space due to > > this. > > Argh, to bad that disk space is an issue these days. > > > > Do we have a plan to fix this? I really need those Uploaders data to > > > prepare > > > my DebConf20 talk. > > > > Given your ongoing effort to port UDD to Python3, I think that the best > > plan is to do that, and port munge_dcc.py to Python3. > > I'd do some 2to3 and simply start it - but its hard to do this on a > local box here since it seems to rely on data that are stored on > ullmann. I also need to admit that I'm currently not able to spent lots > of time into it. Do you see any way I can help speeding up solving this issue? I have no idea about the actual code (not even who wrote it since its not in Git (couldn't we at least move a copy to UDD git and possibly symlink to it on ullmann to have some version control) and how to test it locally without breaking anything on ullmann? Kind regards Andreas. -- http://fam-tille.de
Bug#967954: [Pkg-rust-maintainers] Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network
It has been said in the past by the release team that the current autobuilder behaviour of only considering the first option for a build-dependency is by design to improve the determinism of the autobuilding process. I don't think you will persuade them to change it. The proper fix IMO would be to add support for version ranges to dependencies in dpkg, but even if you can get the dpkg developers to agree to do that it would not be a quick solution as any change to dependency metadata takes a long time to trickle down to the many tools used in Debian.
Bug#968257: release-notes: UpgradingToBuster: apt doesn't report how much space is needed, apt-get does
Braiam wrote: > In "4.4.3. Make sure you have sufficient space for the upgrade" the first > code bloc shows using apt with Trivial-Only option to show how much space > is needed for the operation; but buster apt command does not show this string. That is, the code-block has # apt -o APT::Get::Trivial-Only=true full-upgrade [ ... ] XXX upgraded, XXX newly installed, XXX to remove and XXX not upgraded. Need to get xx.xMB of archives. After this operation, AAAMB of additional disk space will be used. I checked this on my desktop, and indeed it didn't say anything about additional space being used; but in this particular case everything had already been updated anyway. When I booted up a spare buster test machine that *did* have a minor update due it said: $ sudo apt -o APT::Get::Trivial-Only=true full-upgrade [sudo] password for jbr: Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: libjson-c3 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/27.3 kB of archives. After this operation, 4,096 B of additional disk space will be used. E: Trivial Only specified but this is not a trivial operation. So: are you sure? Maybe when you say buster you really mean stretch, which is the release we need to test these instructions on (but I no longer have a stretch test machine handy). > Using apt-get here would be correct. Where *both* work we're trying to stick to apt. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs
can...@free.fr writes: > Thanks. However, I am not a Debian developper / maintainer, and looking for a > sponsor with a good chance of getting into prestige fights with another > developper > sounds like an unlikely path. > > Would an NMU be appropriate for the current situation ? I would still need a > sponsor I suppose, but the process seems less aggressive. If so, how should I > go about getting a sponsor ? Sure, you can do an NMU. You can get a sponsor in the same way as for any other upload. There is a general discussion at [1]; you could also get in touch with debian-emac...@lists.debian.org. See also the developer's reference on NMUs [2] [1]: https://mentors.debian.net/sponsors/ [2]: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus
Bug#957884: #957884 trousers: ftbfs with GCC-10
Control: tags -1 +patch Hello there, my simple-tpm-pk11 package is threatened by a removal of testing because of the trousers FTBFS. So here comes a patch proposal (from an upstream patch over at https://sourceforge.net/p/trousers/trousers/ci/c9b8c4434f3b11bae4f7e72c3aec5b4f3459eecc/ ). Unfortunately, it means removing two symbols from the library, but that feels safe as according to https://codesearch.debian.net/search?q=tcsd_sa_chld they are not in use. I'm likely to upload this to DELAYED/$n soon. I'll mail the bug again when I do. Cheers, Didier trousers_0.3.14+fixed1-1.1.debdiff Description: Binary data
Bug#963675: Info received (Further details)
I was able to build the source package on my computer and install it, but I still receive the same error message when trying to load compound datasets. Any advice or suggestions would be greatly appreciated. All the best, Rob On Fri, 17 Jul 2020 at 12:21, Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian R Packages Maintainers > > If you wish to submit further information on this problem, please > send it to 963...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 963675: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963675 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
