Bug#978155: transition: libqb
Control: forwarded -1 https://release.debian.org/transitions/html/auto-libqb.html Control: tags -1 confirmed On 2020-12-26 19:43:53 +0100, Ferenc Wágner wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear Release Team, > > I'd like to transition to libqb version 2. The dependency list is > fairly short, and mostly contains packages under the HA Team umbrella. > The only breakage is caused by symbols file changes, which I'm ready to > fix by sourceful uploads of corosync and pacemaker. The kronosnet > package will also receive a sourceful upload to use the new binary > package doxygen2man. Altogether I rebuilt the following packages in > preparation: > > kronosnet (with source changes) > corosync (with source changes) > corosync-qdevice > pacemaker (with source changes) > dlm > booth > fence-virt > sbd > ocfs2-tools > lvm2 > usbguard > > The auto-libqb tracker seems usable just too broad. > > Ben file: > > title = "libqb"; > is_affected = .depends ~ "libqb0" | .depends ~ "libqb100"; > is_good = .depends ~ "libqb100"; > is_bad = .depends ~ "libqb0"; > > When you see fit, I'll upload libqb, kronosnet, corosync and pacemaker > in succession, then request the necessary binNMUs. Please go ahead with the uploads to unstable. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#978730: transition: fcl
Control: forwarded -1 https://release.debian.org/transitions/html/auto-fcl.html Control: tags -1 confirmed On 2020-12-31 00:46:32 +0100, Leopold Palomo-Avellaneda wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > > Dear release team, > > I would like to ask a transition slot for the fcl library. Upstream > published a new version with a soname bump. > > We have had a lot of problems to build in many archs, but the last one, > (mipsel) finally worked with the last version of the package. > > The only package that depends on fcl is dart, and I have built it (amd64). > > Please accept the transition slot. Please go ahead with the upload to unstable. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#978499: fop: reproducible builds: Support using SOURCE_DATE_EPOCH for timestamps in PDF files
On Wed, Dec 30, 2020 at 06:23:29PM -0800, Vagrant Cascadian wrote:
> On 2020-12-30, tony mancill wrote:
> > On Tue, Dec 29, 2020 at 11:13:48AM -0800, Vagrant Cascadian wrote:
> >> Thanks for the quick upload! unfortunately...
> >>
> >> > For example, in xorg-docs:
> >> >
> >> >
> >> > https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/xorg-docs.html
> >> >
> >> > /usr/share/doc/xorg-docs/xlfd/xlfd.pdf.gz
> >> >
> >> > CreationDate:·"D:20201225182038-12'00'"
> >> > vs.
> >> > CreationDate:·"D:20220129025203+14'00'"
> >>
> >> I rescheduled various builds after fop landed in unstable, and it
> >> appears to not fully fix the issue...
> >>
> >> It clearly fixed the issue for me when building xorg-docs with reprotest
> >> locally, which does test time and timezone variations... but it uses
> >> faketime, which often behaves differently than a system with an adjusted
> >> running clock such as the tests.reproducible-builds.org infrastructure.
> >
> > Hrm indeed...
> >
> > For what it's worth, the diffoscope for bullseye (which doesn't have the
> > fix for fop in there yet) and unstable look different to me. In
> > bullseye, the "CreationDate" in the differs, as expected. But in
> > unstable, the difference is in CreateDate in the XML metadata about the
> > file.
> >
> > I think it's possible that we are falling into this block of
> > PDFMetadata.java [1]:
> >
> > //Set creation date if not available, yet
> > if (info.getCreationDate() == null) {
> > Date d = new Date();
> > info.setCreationDate(d);
> > }
> >
> > That would fit the symptoms. In any event, in for a penny, in for a pound.
> > I think we can fix this by checking for null creationDate in PDFInfo.java
> > [2] and once again using SOURCE_DATE_EPOCH if set.
> >
> > [1]
> > https://salsa.debian.org/java-team/fop/-/blob/master/fop-core/src/main/java/org/apache/fop/pdf/PDFMetadata.java#L135-139
> > [2]
> > https://salsa.debian.org/java-team/fop/-/blob/master/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java#L190-195
> >
> > I have pushed patch to wrap the original modification to PDFInfo.java in
> > a try/catch but haven't yet uploaded. I'll amend that and I do a little
> > reprotesting before uploading again.
>
> Thanks for continuing to dive into this one! :)
>
> Maybe this is a red herring, but I also noticed that in PDFInfo.java
> there are two definitions of the modified function with the same name...
>
> (snip)
>
> Or is there some java thing to handle functions with the same names?
Yes, it's a common pattern in Java. The methods vary in their arguments
and so are distinct signatures. In this case, the method that takes a
TimeZone as an argument is called by the other method of the same name
in PDFInfo *and* in PDFEmbeddedFile. So... I went looking for all of
the invocations of new Date() in the fop code and found several other
methods where SOURCE_DATE_EPOCH should be checked.
I have an updated patch for fop that addresses the issue with xorg-docs
and probably a few others too. I'm going to let ratt chew on the build
r-deps before uploading, but expect to upload tomorrow.
Cheers,
tony
Bug#978742: mmtarfilter: Slow performance with many path exclusions
Quoting Josh Triplett (2020-12-31 07:38:58) > With a large number of path exclusions specified (around 500), > mmtarfilter starts to become a noticeable performance bottleneck. > > It looks like mmtarfilter checks each file linearly against each filter > using fnmatch. > > Python's fnmatch implementation works by translating shell patterns into > regular > expressions. Python also provides a function to do that translation > separate from fnmatch. One fairly simple optimization would be to walk the > list of > patterns *once*, take each series of consecutive exclude or include > filters, turn each one into a regex, join all the regexes in > each group together using (?:...)|(?:...) , and compile the resulting > regexes once. That should provide a substantial performance improvement. Alternatively, if a rewrite in Perl is preferred, there's libarchive-tar-wrapper-perl which does not slurp the whole tarball into memory (noticing the comment in current script), and libregexp-assemble-perl to fuse regexes together. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#978731: kate: The syntax highlighting for BASH files didn't handle backticks properly
Hi, > if [ 0 -eq `id -u` ]; A simple solution is putting the `..` between double quotes, then the highlighting is correct. > This should be corrected in future packages for debian. Well, it should be corrected/improved upstream. You could help reporting these kind of non-packaging issues to the kde bug tracker, since you have most information and examples at hand. 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#978742: mmtarfilter: Slow performance with many path exclusions
Package: mmdebstrap Version: 0.7.3-1 Severity: normal File: /usr/bin/mmtarfilter X-Debbugs-Cc: j...@joshtriplett.org With a large number of path exclusions specified (around 500), mmtarfilter starts to become a noticeable performance bottleneck. It looks like mmtarfilter checks each file linearly against each filter using fnmatch. Python's fnmatch implementation works by translating shell patterns into regular expressions. Python also provides a function to do that translation separate from fnmatch. One fairly simple optimization would be to walk the list of patterns *once*, take each series of consecutive exclude or include filters, turn each one into a regex, join all the regexes in each group together using (?:...)|(?:...) , and compile the resulting regexes once. That should provide a substantial performance improvement. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 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: systemd (via /run/systemd/system) Versions of packages mmdebstrap depends on: ii apt 2.1.15 ii perl 5.32.0-6 ii python3 3.9.1-1 Versions of packages mmdebstrap recommends: pn arch-test pn fakechroot ii fakeroot 1.25.3-1.1 ii gpg 2.2.20-1 pn libdistro-info-perl ii mount2.36.1-4 pn uidmap Versions of packages mmdebstrap suggests: ii apt [apt-transport-https] 2.1.15 pn apt-transport-tor ii apt-utils 2.1.15 pn binfmt-support ii ca-certificates20200601 ii debootstrap1.0.123 ii distro-info-data 0.45 ii dpkg-dev 1.20.5 pn perl-doc pn proot pn qemu-user pn qemu-user-static pn squashfs-tools-ng -- no debconf information
Bug#978741: ITP: dde-account-faces -- Deepin Account face Images
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : dde-account-faces Version : 1.0.12 Upstream Author : Xu Fasheng * URL : https://github.com/linuxdeepin/dde-account-faces License : CC0 1.0 Universal Programming Lang: Makefile Description : Deepin Account face Images When users are ready to set their own account avatars, Deepin Account avatars provide many beautiful avatars for users to choose from . It is part of Deepin software and DDE (Deepin Desktop Environment). I intend to co-maintain this package inside pkg-deepin group.
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
>From a quick check it looks the asm for ARM is present, it's just put directly in the header x86/mips (and their 64-bit variants) have AsmGetRegs*.S arm and aarch64 has it in the header file, see: https://android.googlesource.com/platform/system/core/+/refs/tags/android-10.0.0_r1/libunwindstack/include/unwindstack/RegsGetLocal.h On Thu, Dec 31, 2020 at 5:19 AM Hans-Christoph Steiner wrote: > also, it looks like libunwindstack uses asm and there isn't any for ARM. > So if someone wants to keep the arm packages, they'll need to figure > that out. I have zero asm skills. >
Bug#972958: pipemeter FTBFS: error: format not a string literal and no format arguments
Package: pipemeter
Version: 1.1.4-1
Followup-For: Bug #972958
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* d/p/format-security-error.patch: Fix format-security error by using fputs
instead of fprintf.
* d/p/fix-make-install.patch: Fix issues with make install by using DESTDIR
and adjusting install arguments.
Thanks for considering the patch.
Logan
-- System Information:
Debian Release: bullseye/sid
APT prefers groovy-updates
APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500,
'groovy'), (100, 'groovy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-33-generic (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru pipemeter-1.1.4/debian/patches/fix-make-install.patch
pipemeter-1.1.4/debian/patches/fix-make-install.patch
--- pipemeter-1.1.4/debian/patches/fix-make-install.patch 1969-12-31
19:00:00.0 -0500
+++ pipemeter-1.1.4/debian/patches/fix-make-install.patch 2020-12-31
00:13:00.0 -0500
@@ -0,0 +1,13 @@
+--- a/Makefile.in
b/Makefile.in
+@@ -24,8 +24,8 @@
+
+
+ install: pipemeter pipemeter.1
+- install -p pipemeter $(PREFIX)/bin
+- install -p pipemeter.1 $(PREFIX)/man/man1
++ install -Dp -t $(DESTDIR)$(PREFIX)/bin pipemeter
++ install -Dp -t $(DESTDIR)$(PREFIX)/man/man1 pipemeter.1
+
+ dist: pipemeter
+ sh pkgpipemeter.sh
diff -Nru pipemeter-1.1.4/debian/patches/format-security-error.patch
pipemeter-1.1.4/debian/patches/format-security-error.patch
--- pipemeter-1.1.4/debian/patches/format-security-error.patch 1969-12-31
19:00:00.0 -0500
+++ pipemeter-1.1.4/debian/patches/format-security-error.patch 2020-12-31
00:12:44.0 -0500
@@ -0,0 +1,29 @@
+--- a/pipemeter.c
b/pipemeter.c
+@@ -397,7 +397,7 @@
+ fprintf(stderr,"\n");
+ exit(1);
+ } else {
+-fprintf(stderr,trailer);
++fputs(trailer,stderr);
+ }
+ }
+
+@@ -487,7 +487,7 @@
+ }
+
+ strncpy(progressbar+1,progressfill,progress);
+- fprintf(stderr, progressbar);
++ fputs(progressbar,stderr);
+ fprintf(stderr," %s/s",buf2);
+ formatbytes(buf2,bytes);
+ fprintf(stderr," %s",buf2);
+@@ -497,7 +497,7 @@
+ fprintf(stderr,"\n");
+ exit(0);
+ } else {
+-fprintf(stderr,trailer);
++fputs(trailer,stderr);
+ }
+ }
+
diff -Nru pipemeter-1.1.4/debian/patches/series
pipemeter-1.1.4/debian/patches/series
--- pipemeter-1.1.4/debian/patches/series 1969-12-31 19:00:00.0
-0500
+++ pipemeter-1.1.4/debian/patches/series 2020-12-31 00:13:00.0
-0500
@@ -0,0 +1,2 @@
+format-security-error.patch
+fix-make-install.patch
Bug#978740: RM: siproxd -- ROM; unmaintained, outdated, FTBFS
Package: ftp.debian.org Severity: normal siproxd has not seen a maintainer upload since 2013, and had an NMU in May 2015. It has been FTBFS since April 2020 (GCC 10), and because of that was removed from testing in 2020-08-07. The last commit in the VCS repo is from Aug 2015. Upstream is not super active, but has continued to release new upstream versions - the last one being 0.8.3 released in August 2020. The package is technically team-maintained (Maintainer is set to pkg-voip, Cc'ed here); I am listed as one of the Uploaders, but last worked on in in 2010 or thereabouts. I've left the team a long time ago (2012-2013?) and have asked to be removed as comaintainer on numerous occasions, but noone has made any uploads nor worked on it, so this hasn't happened. Mark Purcell was the person in the team that last worked on this, but has not been active in Debian for some time now. So, I suppose that technically this makes this a ROM? I don't think anyone is being served by us carrying this package in unstable. If anyone feels this is useful for them, they could step up and make a new upload. They'd likely have to start fresh anyway, given that this wasn't a super complex package and packaging standards have evolved in the time since. Regards, Faidon
Bug#978739: chardet: Upgrading python3-chardet breaks many packages
Package: chardet Version: 4.0.0-1 Severity: serious Justification: makes the package in question unusable or mostly so Control: affects -1 src:requests src:qgis Dear Maintainer, Upgrading python3-chardet causes the removal of many packages: The following packages will be REMOVED: chrome-gnome-shell gnome-music pycsw pycsw-wsgi python3-astropy-helpers python3-boto3 python3-botocore python3-cupshelpers python3-gitlab python3-numpydoc python3-owslib python3-plotly python3-pycsw python3-pywps python3-qgis python3-reportbug python3-requests python3-requests-oauthlib python3-s3transfer python3-sphinx python3-sphinx-astropy python3-sphinx-automodapi python3-sphinx-gallery pywps qgis qgis-plugin-grass reportbug system-config-printer system-config-printer-common system-config-printer-udev torbrowser-launcher The following packages will be upgraded: python3-chardet 1 upgraded, 0 newly installed, 31 to remove and 0 not upgraded. python3-requests does not support version 3.1.0 or higher: python3-chardet (<< 3.1.0) With the freeze coming in a few months it may be wise to revert back to 3.0.x for bullseye. Otherwise the python3-chardet rdeps need to fixed before that time. Kind Regards, Bas
Bug#978738: python3-requests: Dependency incompatibility when trying to install python3-requests=2.25.0+dfsg-2
Package: python3-requests Version: 2.25.0+dfsg-2 Severity: normal X-Debbugs-Cc: ntopi...@gmail.com Dear Maintainer, I tried to install the package `python3-requests` in my Debian unstable, but it failed. The error log was like this: ``` ~ » sudo apt install python3-requests Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python3-requests : Depends: python3-chardet (< 3.1.0) but 4.0.0-1 is to be installed E: Unable to correct problems, you have held broken packages. ``` Looks like one of its dependency `python3-chardet` was upgraded recently, but the dependency setup for `python3-requests` is not upgraded yet. I put the information of the package from my machine. Hope this would help. ``` ~ » apt-cache show python3-requests Package: python3-requests Source: requests Version: 2.25.0+dfsg-2 Installed-Size: 230 Maintainer: Debian Python Team Architecture: all Depends: python3-certifi, python3-chardet (<< 3.1.0), python3-idna, python3-urllib3 (<< 1.27), python3:any, ca-certificates, python3-chardet (>= 3.0.2), python3-urllib3 (>= 1.21.1) Suggests: python3-cryptography, python3-idna (>= 2.5), python3-openssl, python3-socks, python-requests-doc Breaks: awscli (<< 1.11.139) Description-en: elegant and simple HTTP library for Python3, built for human beings Requests allow you to send HTTP/1.1 requests. You can add headers, form data, multipart files, and parameters with simple Python dictionaries, and access the response data in the same way. It's powered by httplib and urllib3, but it does all the hard work and crazy hacks for you. . Features . - International Domains and URLs - Keep-Alive & Connection Pooling - Sessions with Cookie Persistence - Browser-style SSL Verification - Basic/Digest Authentication - Elegant Key/Value Cookies - Automatic Decompression - Unicode Response Bodies - Multipart File Uploads - Connection Timeouts . This package contains the Python 3 version of the library. Description-md5: c784619fd7d31bcb61523fcc12d2d199 Homepage: http://python-requests.org Section: python Priority: optional Filename: pool/main/r/requests/python3-requests_2.25.0+dfsg-2_all.deb Size: 69124 MD5sum: f491e4acbdb0a65d2f145c4b294288e4 SHA256: 02afe549651804a9051266dcb6a693ec71617acff3fda08021ca2be6f120af9e ``` -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.128-microsoft-standard (SMP w/6 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages python3-requests depends on: ii ca-certificates 20200601 ii python3 3.9.1-1 ii python3-certifi 2020.6.20-1 ii python3-chardet 3.0.4-7 ii python3-idna 2.10-1 ii python3-urllib3 1.25.11-1 python3-requests recommends no packages. Versions of packages python3-requests suggests: pn python-requests-doc pn python3-cryptography ii python3-idna 2.10-1 pn python3-openssl pn python3-socks -- no debconf information
Bug#978737: libreoffice-writer: LibreOffice Writer produces PDF with virus if there are links in the document
Package: libreoffice-writer Version: 1:7.0.4~rc2-1+b1 Severity: important Dear Maintainer, On my machine, LibreOffice Writer produces PDF with virus if there are links in the document. That PDF file is blocked by Gmail, and is detected with PDF/Downldr.F.gen!Camelot by Cyren on VirusTotal. The .odt file which produces the .pdf file with virus are both attached. Michael -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_HK.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en_HK:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-writer depends on: ii libabw-0.1-1 0.1.3-1 ii libc62.31-6 ii libe-book-0.1-1 0.1.3-2 ii libepubgen-0.1-1 0.1.1-1 ii libetonyek-0.1-1 0.1.9-4 ii libgcc-s110.2.1-3 ii libicu67 67.1-5 ii libmwaw-0.3-30.3.17-1 ii libodfgen-0.1-1 0.1.7-1 ii libreoffice-base-core1:7.0.4~rc2-1+b1 ii libreoffice-common 1:7.0.4~rc2-1 ii libreoffice-core 1:7.0.4~rc2-1+b1 ii librevenge-0.0-0 0.0.4-6+b1 ii libstaroffice-0.0-0 0.0.7-1 ii libstdc++6 10.2.1-3 ii libuno-cppu3 1:7.0.4~rc2-1+b1 ii libuno-cppuhelpergcc3-3 1:7.0.4~rc2-1+b1 ii libuno-sal3 1:7.0.4~rc2-1+b1 ii libuno-salhelpergcc3-3 1:7.0.4~rc2-1+b1 ii libwpd-0.10-10 0.10.3-1 ii libwpg-0.3-3 0.3.3-1 ii libwps-0.4-4 0.4.12-1 ii libxml2 2.9.10+dfsg-6.3+b1 ii ucf 3.0043 ii uno-libs-private 1:7.0.4~rc2-1+b1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages libreoffice-writer recommends: ii libreoffice-math 1:7.0.4~rc2-1+b1 Versions of packages libreoffice-writer suggests: ii default-jre [java8-runtime] 2:1.11-72 ii fonts-crosextra-caladea 20130214-2.1 ii fonts-crosextra-carlito 20130920-1.1 ii libreoffice-base1:7.0.4~rc2-1+b1 ii libreoffice-java-common 1:7.0.4~rc2-1 ii openjdk-11-jre [java8-runtime] 11.0.9.1+1-1 Versions of packages libreoffice-core depends on: ii fontconfig 2.13.1-4.2 ii fonts-opensymbol2:102.11+LibO7.0.4~rc2-1 ii libboost-locale1.74.0 1.74.0-3+b1 ii libc6 2.31-6 ii libcairo2 1.16.0-4 ii libclucene-contribs1v5 2.3.3.4+dfsg-1+b1 ii libclucene-core1v5 2.3.3.4+dfsg-1+b1 ii libcmis-0.5-5v5 0.5.2-2+b2 ii libcups22.3.3op1-3 ii libcurl3-gnutls 7.72.0-1 ii libdbus-1-3 1.12.20-1 ii libdconf1 0.38.0-1 ii libeot0 0.01-5+b1 ii libepoxy0 1.5.4-1 ii libexpat1 2.2.10-1 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1 ii libgcc-s1 10.2.1-3 ii libglib2.0-02.66.4-1 ii libgpgmepp6 1.14.0-1+b2 ii libgraphite2-3 1.3.14-1 ii libgstreamer-plugins-base1.0-0 1.18.2-1 ii libgstreamer1.0-0 1.18.2-1 ii libharfbuzz-icu02.6.7-1 ii libharfbuzz0b 2.6.7-1 ii libhunspell-1.7-0 1.7.0-3 ii libhyphen0 2.8.8-7 ii libice6 2:1.0.10-1 ii libicu6767.1-5 ii libjpeg62-turbo 1:2.0.5-1.1 ii liblcms2-2 2.9-4+b1 ii libldap-2.4-2 2.4.56+dfsg-1 ii libmythes-1.2-0 2:1.2.4-3+b1 ii libneon27-gnutls0.31.2-1 ii libnspr42:4.29-1 ii libnss3 2:3.60-1 ii libnumbertext-1.0-0 1.0.6-1 ii liborcus-0.16-0 0.16.1-3+b2 ii liborcus-parser-0.16-0 0.16.1-3+b2 ii libpng16-16 1.6.37-3 ii libpoppler102 20.09.0-3 ii libqrcodegencpp11.5.0-2 ii libraptor2-02.0.14-1.1 ii librdf0 1.0.17-1.1+b1 ii libreoffice-common 1:7.0.4~rc2-1 ii librevenge-0.0-00.0.4-6+b1 ii libsm6 2:1.2.3-1 ii libstdc++6 10.2.1-3 ii libuno-cppu31:7.0.4~rc2-1+b1 ii libuno-cppuhelpergcc3-3 1:7.0.4~rc2-1+b1 ii libuno-sal3 1:7.0.4~rc2-1+b1 ii libuno-salhelpergcc3-3 1:7.0.4~rc2-1+b1 ii
Bug#978615: RFS: mugshot/0.4.3-1.1 [NMU] [RC] -- lightweight user-configuration application
Hi, The package maintainer has been working on Salsa to release the new version of this package that fixes the bug and a Debian Developer after conversations offers himself to sponsor the upload by email. With this I mark as closed this RFS. -- Cheers, Leandro Cunha Debian Contributor and developer.
Bug#978736: diffutils: diff for NMU version 1:3.7-3.1
Control: tags 978736 + patch Control: tags 978736 + pending Dear maintainer, I've prepared an NMU for diffutils (versioned as 1:3.7-3.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards, Boyuan Yang diff -Nru diffutils-3.7/debian/changelog diffutils-3.7/debian/changelog --- diffutils-3.7/debian/changelog 2019-04-08 08:04:00.0 -0400 +++ diffutils-3.7/debian/changelog 2020-12-30 23:03:26.0 -0500 @@ -1,3 +1,11 @@ +diffutils (1:3.7-3.1) unstable; urgency=medium + + * Non-maintainer upload from Debian Chinese Team. + * debian/patches/03-zh_CN-translation-hotfix.patch: Add patch to fix +some critical zh_CN translation errors. (Closes: #978736) + + -- Boyuan Yang Wed, 30 Dec 2020 23:03:26 -0500 + diffutils (1:3.7-3) unstable; urgency=medium * Disable tests/colors completely for buster. Closes: #922552. diff -Nru diffutils-3.7/debian/patches/03-zh_CN-translation- hotfix.patch diffutils-3.7/debian/patches/03-zh_CN-translation- hotfix.patch --- diffutils-3.7/debian/patches/03-zh_CN-translation- hotfix.patch1969-12-31 19:00:00.0 -0500 +++ diffutils-3.7/debian/patches/03-zh_CN-translation- hotfix.patch2020-12-30 22:52:18.0 -0500 @@ -0,0 +1,31 @@ +From: Boyuan Yang +Date: Wed, 30 Dec 2020 22:50:55 -0500 +Subject: zh_CN translation hotfix + +Applied-Upstream: https://translationproject.org/team/zh_CN.html +--- + po/zh_CN.po | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/po/zh_CN.po b/po/zh_CN.po +index 05cbef6..67d30ac 100644 +--- a/po/zh_CN.po b/po/zh_CN.po +@@ -265,7 +265,7 @@ msgstr "无效的前导正则表达式" + + #: lib/regcomp.c:177 + msgid "Premature end of regular expression" +-msgstr "正则表达式过旱结束" ++msgstr "正则表达式过早结束" + + #: lib/regcomp.c:180 + msgid "Regular expression too big" +@@ -1114,7 +1114,7 @@ msgstr "软链接 %s 和 %s 不同\n" + #: src/diff.c:1460 + #, c-format + msgid "Files %s and %s are identical\n" +-msgstr "檔案 %s 和 %s 相同\n" ++msgstr "文件 %s 和 %s 相同\n" + + #. This is a proper name. See the gettext manual, section Names. + #: src/diff3.c:42 diff -Nru diffutils-3.7/debian/patches/series diffutils- 3.7/debian/patches/series --- diffutils-3.7/debian/patches/series 2019-04-08 07:00:00.0 -0400 +++ diffutils-3.7/debian/patches/series 2020-12-30 22:52:44.0 -0500 @@ -1,2 +1,3 @@ 01-fix-race-condition-in-colors-test.patch 02-disable-colors-test.patch +03-zh_CN-translation-hotfix.patch signature.asc Description: This is a digitally signed message part
Bug#978701: wireshark: Please package version 2.6.20 with GTK support
On 12/30/2020 17:14, Bálint Réczey wrote: > Control: tags -1 wontfix > > Hi Dmitry, > > Buster-backports receives backports from testing where the version is > already at 3.4.0-1, thus 2.6.x can't be uploaded there. > > Also the 2.6.x branch reached EOL on 2020.10.18: > https://www.wireshark.org/docs/relnotes/wireshark-2.6.20.html > > It is unlikely to have a newer 2.6.x version uploaded to Buster > because all the security issues are marked as not being important > enough to warrant an upload: > https://security-tracker.debian.org/tracker/source-package/wireshark Thanks, Bálint, for looking into the issue. There was a small hope that there will be a Christmas version of version 2.6.20 for those who prefer GTK to QT. I am not sure how difficult is to prepare Debian source package for self-compilation for version 2.6.20 based on 2.6.8, probably I would be able to do it myself. Thanks!
Bug#978736: diffutils: Please fix some critical zh_CN translation errors
Source: diffutils Version: 1:3.7-3 Severity: important Tags: l10n Dear Debian diffutils maintainer, I became aware of some critical zh_CN translation errors in diffutils/1:3.7-3. It would be important to get these errors fixed in Debian 11. As the upstream maintainer of diffutils zh_CN translation, these fixes are commited onto upstream translation website ( https://translationproject.org/team/zh_CN.html ) on 2020-11-19. As a member of Debian Chinese Team, I have prepared a minimal patch as well as NMU for diffutils package in Debian. Please find the patch in the attachment. I will prepare a DELAYED/7 upload later with the same patch. Regards, Boyuan Yang From: Boyuan Yang Date: Wed, 30 Dec 2020 22:50:55 -0500 Subject: zh_CN translation hotfix Applied-Upstream: https://translationproject.org/team/zh_CN.html --- po/zh_CN.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/po/zh_CN.po b/po/zh_CN.po index 05cbef6..67d30ac 100644 --- a/po/zh_CN.po +++ b/po/zh_CN.po @@ -265,7 +265,7 @@ msgstr "无效的前导正则表达式" #: lib/regcomp.c:177 msgid "Premature end of regular expression" -msgstr "正则表达式过旱结束" +msgstr "正则表达式过早结束" #: lib/regcomp.c:180 msgid "Regular expression too big" @@ -1114,7 +1114,7 @@ msgstr "软链接 %s 和 %s 不同\n" #: src/diff.c:1460 #, c-format msgid "Files %s and %s are identical\n" -msgstr "檔案 %s 和 %s 相同\n" +msgstr "文件 %s 和 %s 相同\n" #. This is a proper name. See the gettext manual, section Names. #: src/diff3.c:42 signature.asc Description: This is a digitally signed message part
Bug#978735: backintime-qt: crash and failure to create SSH profile
Package: backintime-qt Version: 1.2.1-2 Severity: normal X-Debbugs-Cc: none Dear Maintainer, Setting up a profile as follows: - Mode: SSH Host: truenas.local Port: 22 User: myuser Path: Cipher: Default Private Key: /home/myuser/.ssh/id_rsa - Password SSH private key: mypassphrase Everything else as set by default. Click OK leads to a crash/shutdown of the GUI, and the following trace at a terminal: $ backintime-qt Back In Time Version: 1.2.1 Back In Time comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type `backintime --license' for details. qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 1747, resource id: 14710889, major code: 40 (TranslateCoords), minor code: 0 kf.kio.core: "Could not enter folder tags:/." kf.kio.core: "Could not enter folder tags:/." Traceback (most recent call last): File "/usr/share/backintime/qt/settingsdialog.py", line 1754, in accept if self.validate(): File "/usr/share/backintime/qt/settingsdialog.py", line 1498, in validate if not self.saveProfile(): File "/usr/share/backintime/qt/settingsdialog.py", line 1359, in saveProfile mnt.preMountCheck(mode = mode, first_run = True, **mount_kwargs) File "/usr/share/backintime/common/mount.py", line 212, in preMountCheck backend = mounttools(cfg = self.config, File "/usr/share/backintime/common/sshtools.py", line 129, in __init__ self.unlockSshAgent() File "/usr/share/backintime/common/sshtools.py", line 309, in unlockSshAgent thread.stop() File "/usr/share/backintime/common/password_ipc.py", line 135, in stop if self.isAlive(): AttributeError: 'TempPasswordThread' object has no attribute 'isAlive' Aborted There are no problems logging into this NAS server via SSH from the terminal command line. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages backintime-qt depends on: ii backintime-common1.2.1-2 ii libnotify-bin0.7.9-2 ii policykit-1 0.105-29 ii python3 3.9.0-4 ii python3-dbus.mainloop.pyqt5 5.15.2+dfsg-1+b1 ii python3-pyqt55.15.2+dfsg-1+b1 ii x11-utils7.7+5 Versions of packages backintime-qt recommends: ii python3-secretstorage 3.3.0-1 Versions of packages backintime-qt suggests: ii kompare 4:20.12.0-2 -- no debconf information -- Seb
Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i
On Tue, Dec 29, 2020 at 02:35:11PM -0500, Justin Erenkrantz wrote: > The OpenSSL devs intended this to be a breaking change - but it's not > documented anywhere. Sigh. > > I've got a WIP patch against trunk that causes test_ssl to pass - see below. > It also seems to work with OpenSSL 1.1.1h as well as OpenSSL 1.1.1i / > 1.1.1-stable, AFAICT. > > James: can you please give it a try as well? Yes, I can confirm this fixes test_ssl_handshake on trunk. There's enough difference between trunk and branches/1.3.x that it doesn't apply cleanly there. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#960291: FTCBFS: uses the build architecture pkg-config
Hi, Verify that the problem still persists in the new upstream version that was released in unstable. Because your patch does not apply in this version. After tests performed. [1] https://tracker.debian.org/news/1207793/accepted-dhcpcd-dbus-061-1-source-into-unstable/ [2] https://tracker.debian.org/pkg/dhcpcd-dbus Cheers, Leandro Cunha
Bug#978589: systemd based startup not working
> created. With absolute path, it is created but then it's created by > lightdm user first and then maybe the user session cannot replace it. Ok, that definitely means you're running as the wrong user, which explains why .Xauthority is not readable. Though why the earlier xscreensaver log said you were running as the correct user is confusing. Unless that log was from before this problem began. > Ok. Is this supposed to be gone when user logs out? Does this interfere > with my trying different parameters (-log, --log, etc.) above, are those > cached and therefore ignored after subsequent changes? xscreensaver-systemd should be killed by xscreensaver when it exits, but it's definitely not a part of the problem that you're experiencing right now. > ## > xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec 30 > 19:08:25 2020 > ## No "running as" line in this log? > Just guessing, is this maybe some bug of xscreensaver-systemd which > makes it request an early shutdown of xscreensaver? No, all "xscreensaver-systemd" does is occasionally run "xscreensaver-command". You are not getting that far. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978734: mp3blaster: reproducible builds: example Makefile embeds buildpath, binary paths and shell
Source: mp3blaster
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath usrmerge shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
The file /usr/share/doc/mp3blaster/examples/charmap/Makefile.gz contains
the embedded build paths, binary paths and different values for SHELL:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/mp3blaster.html
MAKEINFO·=·${SHELL}·'/build/1st/mp3blaster-3.2.6/missing'·makeinfo
vs.
MAKEINFO·=·${SHELL}·'/build/2/mp3blaster-3.2.6/2nd/missing'·makeinfo
EGREP·=·/bin/grep·-E
vs.
EGREP·=·/usr/bin/grep·-E
SHELL·=·/bin/bash
vs.
SHELL·=·/bin/sh
The attached patch fixes this by not shipping this makefile, as the
Makefile.in and Makefile.am are shipped, and a user would need to
regenerate the Makefile with values appropriate to their system.
Thanks for maintaining mp3blaster!
live well,
vagrant
signature.asc
Description: PGP signature
Bug#978437: geoclue-2.0: regression in 2.5.7-1, no geolocation returned
forwarded 978437 https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/142 thanks Le 30/12/20 à 16:43, gregor herrmann a écrit : Thanks for the testing! The following line is actually the real problem, I did all my tests on laptop with wifi cards, I just tried on my desktop and I get the same error (and timeout as you) (geoclue:10479): Geoclue-WARNING **: 16:26:35.098: Failed to create query: No WiFi devices available It looks like geoclue is not doing any request to the Mozilla Location Service is there is no wifi cards (or wifi network around) anymore
Bug#978499: fop: reproducible builds: Support using SOURCE_DATE_EPOCH for timestamps in PDF files
On 2020-12-30, tony mancill wrote:
> On Tue, Dec 29, 2020 at 11:13:48AM -0800, Vagrant Cascadian wrote:
>> Thanks for the quick upload! unfortunately...
>>
>> > For example, in xorg-docs:
>> >
>> >
>> > https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/xorg-docs.html
>> >
>> > /usr/share/doc/xorg-docs/xlfd/xlfd.pdf.gz
>> >
>> > CreationDate:·"D:20201225182038-12'00'"
>> > vs.
>> > CreationDate:·"D:20220129025203+14'00'"
>>
>> I rescheduled various builds after fop landed in unstable, and it
>> appears to not fully fix the issue...
>>
>> It clearly fixed the issue for me when building xorg-docs with reprotest
>> locally, which does test time and timezone variations... but it uses
>> faketime, which often behaves differently than a system with an adjusted
>> running clock such as the tests.reproducible-builds.org infrastructure.
>
> Hrm indeed...
>
> For what it's worth, the diffoscope for bullseye (which doesn't have the
> fix for fop in there yet) and unstable look different to me. In
> bullseye, the "CreationDate" in the differs, as expected. But in
> unstable, the difference is in CreateDate in the XML metadata about the
> file.
>
> I think it's possible that we are falling into this block of
> PDFMetadata.java [1]:
>
> //Set creation date if not available, yet
> if (info.getCreationDate() == null) {
> Date d = new Date();
> info.setCreationDate(d);
> }
>
> That would fit the symptoms. In any event, in for a penny, in for a pound.
> I think we can fix this by checking for null creationDate in PDFInfo.java [2]
> and once again using SOURCE_DATE_EPOCH if set.
>
> [1]
> https://salsa.debian.org/java-team/fop/-/blob/master/fop-core/src/main/java/org/apache/fop/pdf/PDFMetadata.java#L135-139
> [2]
> https://salsa.debian.org/java-team/fop/-/blob/master/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java#L190-195
>
> I have pushed patch to wrap the original modification to PDFInfo.java in
> a try/catch but haven't yet uploaded. I'll amend that and I do a little
> reprotesting before uploading again.
Thanks for continuing to dive into this one! :)
Maybe this is a red herring, but I also noticed that in PDFInfo.java
there are two definitions of the modified function with the same name...
/**
* Formats a date/time according to the PDF specification
(D:MMDDHHmmSSOHH'mm').
* @param time date/time value to format
* @param tz the time zone
* @return the requested String representation
*/
protected static String formatDateTime(final Date time, TimeZone tz)
{
return DateFormatUtil.formatPDFDate(time, tz);
}
/**
* Formats a date/time according to the PDF
specification. (D:MMDDHHmmSSOHH'mm').
* @param time date/time value to format
* @return the requested String representation
*/
protected static String formatDateTime(final Date time) {
return formatDateTime(time, TimeZone.getDefault());
}
Or is there some java thing to handle functions with the same names?
live well,
vagrant
signature.asc
Description: PGP signature
Bug#978726: mirror submission for mirror.surf
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.surf Type: leaf Archive-architecture: amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Maintainer: mirror.surf Country: RU Russian Federation Location: Nizhny Novgorod Sponsor: Dmitry Shishkin https://shishkin.us Trace Url: http://mirror.surf/debian/project/trace/ Trace Url: http://mirror.surf/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.surf/debian/project/trace/mirror.surf
Bug#978499: #978499: fop: reproducible builds: Support using SOURCE_DATE_EPOCH for timestamps in PDF files
On Tue, Dec 29, 2020 at 11:13:48AM -0800, Vagrant Cascadian wrote:
> Thanks for the quick upload! unfortunately...
>
> > For example, in xorg-docs:
> >
> >
> > https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/xorg-docs.html
> >
> > /usr/share/doc/xorg-docs/xlfd/xlfd.pdf.gz
> >
> > CreationDate:·"D:20201225182038-12'00'"
> > vs.
> > CreationDate:·"D:20220129025203+14'00'"
>
> I rescheduled various builds after fop landed in unstable, and it
> appears to not fully fix the issue...
>
> It clearly fixed the issue for me when building xorg-docs with reprotest
> locally, which does test time and timezone variations... but it uses
> faketime, which often behaves differently than a system with an adjusted
> running clock such as the tests.reproducible-builds.org infrastructure.
Hrm indeed...
For what it's worth, the diffoscope for bullseye (which doesn't have the
fix for fop in there yet) and unstable look different to me. In
bullseye, the "CreationDate" in the differs, as expected. But in
unstable, the difference is in CreateDate in the XML metadata about the
file.
I think it's possible that we are falling into this block of
PDFMetadata.java [1]:
//Set creation date if not available, yet
if (info.getCreationDate() == null) {
Date d = new Date();
info.setCreationDate(d);
}
That would fit the symptoms. In any event, in for a penny, in for a pound. I
think we can fix this by checking for null creationDate in PDFInfo.java [2] and
once again using SOURCE_DATE_EPOCH if set.
[1]
https://salsa.debian.org/java-team/fop/-/blob/master/fop-core/src/main/java/org/apache/fop/pdf/PDFMetadata.java#L135-139
[2]
https://salsa.debian.org/java-team/fop/-/blob/master/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java#L190-195
I have pushed patch to wrap the original modification to PDFInfo.java in
a try/catch but haven't yet uploaded. I'll amend that and I do a little
reprotesting before uploading again.
> Ah well, if anyone has a suggestion for how to really fix it, that would
> be nice, since it would fix several packages...
I should have something up tomorrow.
Cheers,
tony
signature.asc
Description: PGP signature
Bug#215360: patch already merged upstream so close #215360
Please close (not only archive) this bug #215360 cos as https://sourceforge.net/p/courier/mailman/message/37186787/ was merged long time ago for sqwebmail, so any recent version is fixed now! Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#978675: libsys-hostname-long-perl: FTBFS, tests fail
On Wed, 30 Dec 2020 10:35:52 +, Holger Levsen wrote: > On Wed, Dec 30, 2020 at 06:12:55AM +0100, Axel Beckert wrote: > > gregoa: I'll leave up to you if you already want to close the bug > > report or not. Feel free to replace my fixed tag with a pending tag or > > so. > I've already closed the bug :) Thanks, Axel and Holger. So the situation is: I've uploaded -2 in order to - see what the buildds say - get more diagnostics - get a .buildinfo file And the result is: - it built on my laptop and on the buildd - we should have a .buildinfo file :) - it still fails on the reproducible build servers - and the diagnostics there failed as well (fixed in git, I got the order wrong) Taking a step back: What the very simple module does is to try and guess the FQDN of a machine, with various methods. And it seems this doesn't always work (cf. "hostname: Temporary failure in name resolution" in the logs of the failures but all other methods which are tried later apparently fail as well). So I guess we can say - that the module and the tests probably work in most "real" situations - but it can fail under "special" circumstances, which the RB hosts and Holger's build machine triggered (but nothing else or before, like Lucas' archive rebuilds). We can now - say "good enough" and forget about the issue - or reopen the bug and lower the severity (and retitle it to something like "Sys::Hostname::Long fails if there is not networking/no DNS/something"). I'm not sure if/how the bug can be fixed, or if a failing `hostname' is ultimately a bug in the package or in the environment. Hm, and after writing this mail, I think that an environment where `hostname' fails is maybe really to special in order to re-open the bug. But I'd still like to hear other opinions, that's why I started this mail in the first place even if the bug is already closed :) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Kings of Convenience: My Ship Isn't Pretty signature.asc Description: Digital Signature
Bug#978733: Runs env both inside and outside the chroot for the same variables
Package: mmdebstrap Version: 0.7.3-1 Severity: minor X-Debbugs-Cc: j...@joshtriplett.org mmdebstrap appears to be running commands like the following: env --unset=APT_CONFIG --unset=TMPDIR /usr/sbin/chroot /path/to/targetdir env --unset=TMPDIR dpkg --install Running env both inside and outside of the chroot seems unnecessary. chroot will not set TMPDIR, so the internal invocation of env can be dropped; it would be nice to not count on "env" existing inside the chroot. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 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: systemd (via /run/systemd/system) Versions of packages mmdebstrap depends on: ii apt 2.1.15 ii perl 5.32.0-6 ii python3 3.9.1-1 Versions of packages mmdebstrap recommends: pn arch-test pn fakechroot ii fakeroot 1.25.3-1.1 ii gpg 2.2.20-1 pn libdistro-info-perl ii mount2.36.1-4 pn uidmap Versions of packages mmdebstrap suggests: ii apt [apt-transport-https] 2.1.15 pn apt-transport-tor ii apt-utils 2.1.15 pn binfmt-support ii ca-certificates20200601 ii debootstrap1.0.123 ii distro-info-data 0.45 ii dpkg-dev 1.20.5 pn perl-doc pn proot pn qemu-user pn qemu-user-static pn squashfs-tools-ng -- no debconf information
Bug#978732: postinst prints debug output (set -x)
Package: ppp Version: 2.4.8-1+2 Severity: normal During the upgrade of ppp I noticed this: ppp (2.4.8-1+2) wird eingerichtet ... Neue Version der Konfigurationsdatei /etc/ppp/ip-down.d/usepeerdns wird installiert ... Neue Version der Konfigurationsdatei /etc/ppp/ip-up.d/usepeerdns wird installiert ... + dpkg --compare-versions 2.4.8-1+1 le-nl 2.4.8-1+2~ + rm -f /lib/systemd/system/pppd-dns.service.dpkg-bak + deb-systemd-helper purge pppd-dns.service + deb-systemd-helper unmask pppd-dns.service + update-rc.d -f pppd-dns remove + dpkg-maintscript-helper rm_conffile /etc/bash_completion.d/pon 2.4.7-1+2~ -- configure 2.4. 8-1+1 + dpkg-maintscript-helper rm_conffile /etc/init.d/pppd-dns 2.4.8-1+1~exp1~ -- configure 2.4.8 -1+1 + exit 0 This looks like a forgotten set -x -- 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.9.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ppp depends on: ii libc6 2.31-6 ii libcrypt1 1:4.4.17-1 ii libpam-modules 1.4.0-2 ii libpam-runtime 1.4.0-2 ii libpam0g1.4.0-2 ii libpcap0.8 1.9.1-4 ii libssl1.1 1.1.1i-1 ii libsystemd0 247.2-3 ii procps 2:3.3.16-5 ppp recommends no packages. ppp suggests no packages. -- no debconf information
Bug#978731: kate: The syntax highlighting for BASH files didn't handle backticks properly
Package: kate Version: 4:20.12.0-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! In a BASH script which I wrote long time ago I have this line: if [ 0 -eq `id -u` ]; then Backticks are old and busted in the BASH language but they are still working. When I open this script with Kate the syntax highlighting for the rest of the BASH file isn't realy conclusive. In other words: it is totally broken. This was working properly before Kate twenty something appears. Now is not so nice - or let me say: rubbish. This should be corrected in future packages for debian. - -- Yours sincerely Joerg Schiermeier - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), LANGUAGE=de:en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kate depends on: ii kate5-data 4:20.12.0-1 ii kio 5.77.0-2 ii ktexteditor-katepart 5.77.0-2 ii libc62.31-6 ii libkf5bookmarks5 5.77.0-2 ii libkf5completion55.77.0-4 ii libkf5configcore55.77.0-2 ii libkf5configgui5 5.77.0-2 ii libkf5configwidgets5 5.77.0-2 ii libkf5coreaddons55.77.0-2 ii libkf5crash5 5.77.0-2 ii libkf5dbusaddons55.77.0-2 ii libkf5guiaddons5 5.77.0-4 ii libkf5i18n5 5.77.0-2 ii libkf5iconthemes55.77.0-2 ii libkf5jobwidgets55.77.0-2 ii libkf5kiocore5 5.77.0-2 ii libkf5kiofilewidgets55.77.0-2 ii libkf5kiogui55.77.0-2 ii libkf5kiowidgets55.77.0-2 ii libkf5newstuff5 5.77.0-3 ii libkf5parts5 5.77.0-2 ii libkf5plasma55.77.0-2 ii libkf5service-bin5.77.0-2 ii libkf5service5 5.77.0-2 ii libkf5syntaxhighlighting55.77.0-2 ii libkf5texteditor55.77.0-2 ii libkf5textwidgets5 5.77.0-2 ii libkf5threadweaver5 5.77.0-2 ii libkf5wallet-bin 5.77.0-2 ii libkf5wallet55.77.0-2 ii libkf5widgetsaddons5 5.77.0-4 ii libkf5windowsystem5 5.77.0-2 ii libkf5xmlgui55.77.0-2 ii libkuserfeedbackcore11.0.0-3 ii libkuserfeedbackwidgets1 1.0.0-3 ii libqt5core5a 5.15.2+dfsg-2 ii libqt5dbus5 5.15.2+dfsg-2 ii libqt5gui5 5.15.2+dfsg-2 ii libqt5sql5 5.15.2+dfsg-2 ii libqt5widgets5 5.15.2+dfsg-2 ii libqt5xml5 5.15.2+dfsg-2 ii libstdc++6 10.2.1-3 ii plasma-framework 5.77.0-2 ii qml-module-org-kde-kquickcontrolsaddons 5.77.0-2 ii qml-module-qtquick-layouts 5.15.2+dfsg-2 ii qml-module-qtquick2 5.15.2+dfsg-2 Versions of packages kate recommends: ii sonnet-plugins 5.77.0-2 Versions of packages kate suggests: pn darcs ii exuberant-ctags 1:5.9~svn20110310-13 ii git 1:2.29.2-1 ii khelpcenter 4:20.12.0-1 ii konsole-kpart4:20.12.0-2 ii mercurial5.5.2-1+b1 ii subversion 1.14.0-3+b2 - -- no debconf information -BEGIN PGP SIGNATURE- Comment: This was created by GnuPG for Linux. iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAl/tGhgACgkQodFQ9YsO 8GMk9g/9EZwlRLbtYAk+D/jThxa2lgIfsVzULs7zWCuVaguQ5b3Hd9zq/Gbiw0NB kdNUm5q8KsCf3RxoE7W44eqHTjH1B1gWvZYZLZ/VPGysUp98lWSYC5xc6WFjqlQz qrU+o8j2R3S3MrjDz4JyjQLBbh7Qp7m+rSRgUbCqR5Sze+9MnCrwC3vIOld972vW MhJfHZNgarcuRP5cQjQr79upIjDi3/Q0/geIP7hiYgn2U22Vi4ZhxLWZMZjXOX+u 1i3HdzNN0X4RN9rOn7tCKVxuBlP13giSLrtwqFKEarxlkVZyiSnfEK5qoTu0OcSD iwPCCwxR9b+eH4kACFKLGRtiCvDAQyt64EoqyGDdro+MwH3TNkZjheNThgwcVryJ TrBl35363alPeA1+eJUphZaYIl2TpKHFPMVI3RPJv5YbzND9ms5gA26FmIv6TZZ/ PkhnQq1aucXKjWMFYAFTQFkR8++4bGomZnN9jrkxmnyYwMY73AvNpVbN1hUbXayh bLNoyk3VCp5xZK1JwPFz+v8F6LWj1Gnc1VHV+RMlHmjIsT+2Tb/99iaXOw9DKRyC 8o/9Jgb3Z0lNClWNd1FYTuVrTOgjvama8lOvhidtjBQXALekLcwgsL2WOHXIZ4wZ IbMK9jAhUmB9tjwZNR4jcCK9xFlIEDCGJCOoak+7JkN6xP8Yfx0= =b6Cu -END PGP SIGNATURE-
Bug#978703: gives strange error messages on outdated images
Am Mi., 30. Dez. 2020 um 14:57 Uhr schrieb Marc Haber : > > Package: debspawn > Version: 0.4.1-1 > Severity: minor > > Hi, > > I recently tried to use debspawn build building into a slightly outdated > image of Debian sid and received a message that dsrun didn't like the > "--suite sid" option that was given to it. Updating the image solved the > issue for me. > > I suspect that the "outside" debspawn calls things that are inside the > image, and while the outside debspawn was a 0.4.1, the inside was still > at 0.4.0 or even older and the interface between the outside and inside > code changed with the 0.4.0 to 0.4.1 transition. If my suspicion is > true, than this might also apply to images of testing or stable, but > without the possibility of just fixing this by updating the image. > > I understand that this issue is probably hard to fix, but if it doesn't > seem possible to just inject the code needed on the inside from the > outside at run time (therefore forcing them to be in sync, but possibly > introducing python version issues) then there should be at least a more > helpful error message than just bombing out with a usage message of an > internal tool. Hi! I'll probably address this properly in future by making this automatic, but this kind of issue can be fixed relatively easily by running `debspawn update ` - that will make sure older images run with newer debspawn versions. In the long run, this step should either happen in postinst for the deb package, or, even better, debspawn could auto-update older images on the first time they are used. For now though, the debspawn update command has to be run manually (or via cron scripts - on my system I have a few systemd timer units which update debspawn container automatically, which is probably why I hadn't noticed this issue immediately). Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Bug#932458: Couldn't open /etc/securetty: No such file or directory
Hey, * Bálint Réczey [201230 23:53]: > Bálint Réczey ezt írta (időpont: 2019. nov. > 7., Cs, 20:45): > > Thorsten Glaser ezt írta (időpont: 2019. nov. 6., > > Sze, 23:08): > > > > > > Hi everyone, > > > > > > when will something happen to not fill syslog with these messages > > > (unless deserved, such as if there is really something to warn about)? > > > > > > It’s not even stated yet whether the suggested change to the config > > > is safe to apply… > > > > I'm waiting for Steve's position on this. I believe the change to > > shadow was OK and all we need is removing the message in PAM. > > Since it is a trivial change I have not prepared a patch but I'm happy > > to if Steve prefers that. > > I asked upstream if they just want to silence the notice, but they > don't want to: > https://github.com/linux-pam/linux-pam/pull/158 > > It leaves us with disabling it using configuration files. IMO the > proposed patch of removing nullok_secure is safe and the desired > solution. > However it is up to the maintainers, Steve, or Sam, to accept the > patch unless someone NMUs it. > I don't plan NMU-ing it myself, but since the general NMU rules apply > any DD can NMU it via DELAYED/10. Given not much has happened so far, maybe login should remove pam_securetty from its default PAM configuration instead? Thats nothing that needs to be coordinated with the PAM maintainers, AFAICT. Best, Chris
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
also, it looks like libunwindstack uses asm and there isn't any for ARM. So if someone wants to keep the arm packages, they'll need to figure that out. I have zero asm skills.
Bug#978730: transition: fcl
Subject: transition: fcl Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Dear release team, I would like to ask a transition slot for the fcl library. Upstream published a new version with a soname bump. We have had a lot of problems to build in many archs, but the last one, (mipsel) finally worked with the last version of the package. The only package that depends on fcl is dart, and I have built it (amd64). Please accept the transition slot. Best regards, Leopold - Ben file: title = "fcl"; is_affected = .depends ~ /\b(libfcl0\.6|libfcl0\.5)\b/ is_good = .depends ~ /\b(libfcl0\.6)\b/ is_bad = .depends ~ /\b(libfcl0\.5)\b/ https://buildd.debian.org/status/package.php?p=fcl=experimental -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? OpenPGP_signature Description: OpenPGP digital signature
Bug#978589: systemd based startup not working
Hallo, * Jamie Zawinski [Tue, Dec 29 2020, 04:48:10PM]: > > Once logged in, I can see some active process of xscreensaver (this is what > > "pidof xscreensaver" tells me). > > > > But after some seconds, this process is gone. Why? Don't know. > > Dunno. Maybe it's trying to connect and timing out. Run xscreensaver with > --log log.txt I tried, but no such file gets created, even with absolute path. After RTFM and some time wasted I guess that it should be -log AND NOT --log. And then, when I use it with relative path, no such file is created. With absolute path, it is created but then it's created by lightdm user first and then maybe the user session cannot replace it. I could trick my way around it by removing the file manually, though. After some daemon-reload runs, I cannot even start it now whatsoever. Means: journalctl or "systemctl --user status xscreensaver.service" show me the last log lines from an hour ago (with the failed-to-open-DISPLAY issue). systemctl --user status | grep saver -> nothing However without --user: CGroup: / ├─user.slice │ └─user-500.slice │ ├─user@500.service │ │ ├─app.slice │ │ │ ├─pulseaudio.service │ │ │ │ └─12150 /usr/bin/pulseaudio --daemonize=no ... │ │ └─init.scope │ │ ├─2483 /lib/systemd/systemd --user │ │ └─2484 (sd-pam) │ ├─session-2.scope │ │ └─2748 xscreensaver-systemd ... The PID of xscreensaver-systemd does not fit, it's an old process, started an hour ago. /proc/2748 confirms it, this belong to the old lines in "systemctl --user status". But I did close and restart the X session severtal times now, why is that process not dead? > Or if you have an old version, -verbose -no-capture -log log.txt That said, I saw something odd, sometimes xscreensaver was started. That made me remember something, I think I had a similar problem on this same system some months ago and it did not work with systemd but I took a shortcut due to lag of time and so I have put it into the startup file of the window manager. And it seems like it had worked this way since then. So my previous statement was not fully correct. Nevertheless, the systemd way does not work even after I removed the custom startup call. > > 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd > > > > The manpage of this binary is slightly confusing. That is some kind of > > helper, fine, but who is supposed to run it? Xsession? Or systemd user > > session? It mentions "When run from ~/.xsession or equivalent" but there > > is no information on what is considered "equivalent" here. > > It is launched by xscreenasver itself. Ok. Is this supposed to be gone when user logs out? Does this interfere with my trying different parameters (-log, --log, etc.) above, are those cached and therefore ignored after subsequent changes? Anyway, I killed it now, logged out, logged in, the process is not coming back, and the picture looks like above (old status log in the "systemctl --user status" output). Also, xscreensaver process was running for some seconds and then disappeared. However, this time it created a log file. ## xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec 30 19:08:25 2020 ## xscreensaver: 19:08:26: running on display ":0.0" xscreensaver: 19:08:26: vendor is The X.Org Foundation, 1201. xscreensaver: 19:08:26: useful extensions: xscreensaver: 19:08:26: MIT Screen-Saver (disabled at compile time) xscreensaver: 19:08:26: Shared Memory (1.2) xscreensaver: 19:08:26: Double-Buffering (1.0) xscreensaver: 19:08:26: Power Management (1.2) xscreensaver: 19:08:26: GLX xscreensaver: 19:08:26: XF86 Video-Mode (2.2) xscreensaver: 19:08:26: XC Misc (disabled at compile time) xscreensaver: 19:08:26: Xinerama (1.1) xscreensaver: 19:08:26: Resize-and-Rotate (1.5) xscreensaver: 19:08:26: XInput xscreensaver: 19:08:26: libsystemd xscreensaver: 19:08:26: screen 0 non-colormapped depths: 24. xscreensaver: 19:08:26: WARNING: RANDR and Xinerama report different xscreensaver: 19:08:26: screen layouts! Believing RANDR. xscreensaver: 19:08:26: screens in use: 1 xscreensaver: 19:08:26:3/0: 1920x1080+0+0 (HDMI-1) xscreensaver: 19:08:26: rejected screens: 4 xscreensaver: 19:08:26:0/0: 1920x1080+0+0 (DVI-D-1) -- output disabled xscreensaver: 19:08:26:1/0: 1920x1080+0+0 (DP-1) -- output disabled xscreensaver: 19:08:26:2/0: 1920x1080+0+0 (DP-2) -- output disabled xscreensaver: 19:08:26:4/0: 1920x1080+0+0 (HDMI-2) -- output disabled xscreensaver: 19:08:26: selecting RANDR events xscreensaver: 19:08:26: not using XInputExtension. xscreensaver: 19:08:26: consulting /proc/interrupts for keyboard activity. xscreensaver: 19:08:26: 0: visual 0x21
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
Roger Shimizu: On Wed, Dec 30, 2020 at 3:46 AM Hans-Christoph Steiner wrote: Ok, I fixed the dependency issue, now it gets reliably to the point rosh gets to: Thanks for fixing the build dependency issue! I fixed a few other issues (operator script & mterp generation, etc), and pushed to rosh/refine branch. Current build breaking point is the same as previous one. I tried to use different c++ library, such as libstdc++-8-dev, and clang-9, but seems no help. I have android-platform-art building as a stage1 now, so I'm working again on android-platform-system-core. I haven't found where these symbols are supposed to come from: clang++ fastboot/bootimg_utils.cpp fastboot/fastboot.cpp fastboot/fastboot_driver.cpp fastboot/fs.cpp fastboot/main.cpp fastboot/socket.cpp fastboot/tcp.cpp fastboot/udp.cpp fastboot/usb_linux.cpp fastboot/util.cpp fs_mgr/liblp/builder.cpp fs_mgr/liblp/images.cpp fs_mgr/liblp/partition_opener.cpp fs_mgr/liblp/reader.cpp fs_mgr/liblp/utility.cpp fs_mgr/liblp/writer.cpp -o fastboot/fastboot -g -O2 -fdebug-prefix-map=/build/android-platform-system-core-10.0.0+r36=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -std=gnu++2a -fpermissive -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -UDEBUG -I/usr/include/android -DPLATFORM_TOOLS_VERSION='"28.0.2"' -Iinclude -Imkbootimg/include/bootimg -Iadb -Ibase/include -Idemangle/include -Idiagnose_usb/include -Ifs_mgr/include -Ifs_mgr/include_fstab -Ifs_mgr/liblp/include -I/usr/include/android -I/usr/include/android/f2fs_utils -I/usr/include/android/openssl -Ilibsparse/include -Ilibziparchive/include -Wl,-z,relro -Wl,-z,now -fPIC -Wl,-rpath=/usr/lib/x86_64-linux-gnu/android -Wl,-rpath-link=. -L. -lziparchive -lsparse -lbase -lcutils -ladb -lutils -lssl -lcrypto -L/usr/lib/x86_64-linux-gnu/android -lart -l7z -lunwind /usr/bin/ld: /tmp/utility-794e29.o: in function `android::fs_mgr::GetDescriptorSize(int, unsigned long*)': ./fs_mgr/liblp/utility.cpp:49: undefined reference to `get_block_device_size' /usr/bin/ld: ./libbacktrace.so.0: undefined reference to `typeinfo for art_api::dex::DexFile' Check my forks for the most current commits: https://salsa.debian.org/eighthave/android-platform-art https://salsa.debian.org/eighthave/android-platform-system-core .hc
Bug#978729: ERROR build/debian-cd: E: The value 'unstable' is invalid for APT::Default-Release as such a release is not available in the sources when building buster image
Package: simple-cdd Version: 0.6.7 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm trying to build a custom Buster image. The host system is a Debian Sid/unstable. When I run the build right after "make image-tree" is invoked in /usr/share/simple-cdd/tools/build/debian-cd ERROR build/debian-cd: E: The value 'unstable' is invalid for APT::Default-Release as such a release is not available in the sources when building buster image because my local apt.conf has the default value set to 'unstable'. But my local APT configuration IMHO shouldn't be of any concern to simple-cdd or debian-cd. So I have to edit this file to make it work. Maybe it should create a temporary apt.conf setting APT::Default-Release to the value used for the --dist switch? Regards, Daniel - -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages simple-cdd depends on: ii dctrl-tools 2.24-3+b1 ii debian-cd 3.1.31 ii lsb-release 11.1.0 ii python3 3.9.1-1 ii python3-simple-cdd 0.6.7 ii reprepro5.3.0-1.1 ii rsync 3.2.3-3 ii wget1.20.3-1+b3 Versions of packages simple-cdd recommends: ii dose-distcheck 5.0.1-15+b3 Versions of packages simple-cdd suggests: ii qemu-system 1:5.2+dfsg-3 ii qemu-system-x86 [qemu-kvm] 1:5.2+dfsg-3 - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl/tDr8ACgkQS80FZ8KW 0F3oDA//Zyaf+FluNKau1LSxbdKaZ9RS+a0NGNpfjavlydkAo2tUYv+6pJbPlAhM AoPlI8mC/PFkyTVWaf8nvJ49CbeGyxmtE+qRqMkOlE/dwXXRuRo2oay7udfx5Ajy q+Tbjjah1zCNgmwf8u8TwnLTero3eqrKX5aDuytNpfcqZRcMqhC7I2gqp4zws/us 0M4d9n2LF7cX559prr7l43QKLVjExxfY8dZmJJkc13N0PJWOdp1nNBJ73eL6Stau XzcV6wSocSQEtAkHOpLVHqfgMb7jx+3E6HsiVKNNC2o5BANn/kDAl/SgB3nNUOtq hy9nUL8ruZydb93g1b5SJh3WcHuyihBktsYUaDku3IIo87tBiDmYubmLtBdj875h r3pI3wC3yAnNrnRbXnFgQla75UPj19c6uFC9ACKLunKBbXMKK8vWdBADu4h5tx8G VHkoz8DIB5nPZJfjZor+GWgzgHp9alPCKbjnXaNUJWjpA4u3uV9As4Mgcd9UVhS+ ElkYDZtgy0G/LUasREtQC0WgEcakDVawxbm/ZEJ2cFwYcRj8cx/L1jini8EJzVmm ktWbCToH3T7ZLV3WA1/IpUjNAv8pdywn2YJj/hv6HaI950ZqiUEMDkR83UoLFdKr epAQDRYYC3Gh4KToMSqRpDONGUxZeGUnaX1LsSrNdizxtnT4gTU= =iVtn -END PGP SIGNATURE-
Bug#978724: RFS: dhcpcd-dbus/0.6.1-1 [QA] -- DBus bindings for dhcpcd
On 2020-12-30 18:39 -0300, Leandro Cunha wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "dhcpcd-dbus": > > * Package name: dhcpcd-dbus > Version : 0.6.1-1 > Upstream Author : Roy Marples > * URL : https://roy.marples.name/projects/dhcpcd > * License : BSD-2 > * Vcs : [fill in URL of packaging vcs] > Section : net > > It builds those binary packages: > >dhcpcd-dbus - DBus bindings for dhcpcd > > To access further information about this package, please visit the following > URL: > >https://mentors.debian.net/package/dhcpcd-dbus/ > > Alternatively, one can download the package with dget using this command: > >dget -x > https://mentors.debian.net/debian/pool/main/d/dhcpcd-dbus/dhcpcd-dbus_0.6.1-1.dsc > > Changes since the last upload: > > dhcpcd-dbus (0.6.1-1) unstable; urgency=medium > . > * QA upload. > * New upstream release. > * Fixed Lintian reports. > * debian/control: > - Bumped Standards-Version to 4.5.1. > - Added Rules-Requires-Root: no. > - Updated homepage field. > * debian/watch: > - Fixed problem to import tarball via uscan. > - Updated version of 3 to 4. > * debian/copyright: > - Updated year upstream author. > - Updated source field. > - Updated file following DEP-5. > - Added files debian/* and people involved with year of contribution. > - Added myself. > * debian/rules: > - Set ignore dh_auto_test to fix FTBFS (Fails To Build From Source) and > thanks to Simon McVitie maintainer of the dbus who helped me with > this. > * Added debian/gbp.conf. > * Added debian/upstream/metadata. > * Added debian/test/control to autopkgtest. > * Added debian/salsa-ci.yml. OK. That all looks sensible. I note that lintian complains about the dbus policy: W: dhcpcd-dbus: dbus-policy-without-send-destination etc/dbus-1/system.d/dhcpcd-dbus.conf https://lintian.debian.org/tags/dbus-policy-without-send-destination.html says: The package contains D-Bus policy configuration that uses one of the send_* conditions, but does not specify a send_destination, and is not specific to root. Rules of the form allow messages with the given interface to be sent to any service, not just the one installing the rule, which is rarely what was intended. Similarly, on the system bus, rules of the form are redundant with the system bus's default-deny policy, and have unintended effects on other services. This check ignores rules of the form which are commonly used for the "agent" pattern seen in services like BlueZ and NetworkManager: a root-privileged daemon calls out to one or more per-user user interface agent processes with no specific name, so send_destination is not easily applicable. However, such rules should still be made as specific as possible to avoid undesired side-effects. - I'm not sure if this is something that should be fixed or ignored? The config file has not changed from what is in the current version and the file _does_ seem to specify a send_destination, so is there in fact a lintian bug? http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#933059: Debian Buster with encrypted root on degraded raid1 (md-raid)
Control: tag -1 pending Thanks all for the patches and discussion, and sorry for not chiming in earlier in the release cycle. I now merged in Guilherme's patch modulo some minor fixes. My first reaction was this this was an “abuse” of initramfs-tools(7)'s interface since it clearly state that passed local-top stage the root device node is expected to be present (encouraging us to call the local-block/mdadm from local-top/cryptroot, like we're already doing for local-block/lvm2), however it also says later that if local-top fails to create the root device node the local-block scripts will be called periodically. So in the end I like Guilherme's approach to give up early at local-top stage and let the local-block caller take care of the retry and polling logic. In fact on closer look it appears initramfs-tools(7) is now discouraging to do any kind of polling: https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/ab9130667d42d0532e8f2900fa3da280dfb61f03 This should allow further simplifying the boot script: no need to loop up to $ROOTDELAY there. And I believe we can even remove the LVM hack for dm-crypt-over-LVM setups, too. Thanks again! -- Guilhem. signature.asc Description: PGP signature
Bug#978431: texlive-base: dist-upgrade buster->bullseye fails
Am 27.12.2020 um 12:42 teilte Rene Engelhard mit: Hi Rene, Many thanks for the report! dist-upgrade buster->bullseye which just caused my system to not get out of apt -f install anymore: Entpacken von texlive-base (2020.20201203-2) über (2018.20190227-2) ... dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-nSKKZq/20-texlive-base_2020.20201203-2_all.deb (--unpack): Versuch, »/usr/share/doc/texlive-doc/generic/iftex/iftex.pdf« zu überschreiben, welches auch in Paket texlive-plain-generic 2018.20190227-2 ist dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet Regenerating '/var/lib/texmf/fmtutil.cnf-DEBIAN'... done. Regenerating '/var/lib/texmf/fmtutil.cnf-TEXLIVEDIST'... done. update-fmtutil has updated the following file(s): /var/lib/texmf/fmtutil.cnf-DEBIAN /var/lib/texmf/fmtutil.cnf-TEXLIVEDIST If you want to activate the changes in the above file(s), you should run fmtutil-sys or fmtutil. [...] Did you find the conflict by chance or do you systematically do dist-upgrade test? Just a question: if I do an upload to solve this conflict I'd like to solve all conflicts of this type. Many thanks! Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#716038: knocker 0.8.0
Hi, this is just to tell you that knocker 0.8.0 has been released and it fixes those bugs. https://github.com/gabgio/knocker or https://knocker.sourceforge.io/ Maybe you can reintroduce it in unstable. Thanks. Regards.
Bug#968148: /usr/bin/apt-key: Suggestion for manpage and Warning
On Thu, Sep 03, 2020 at 09:33:07AM +0200, Vincent van Adrighem wrote: > Package: apt > Followup-For: Bug #968148 > > Dear Maintainer, > > Replacing the command is not what we want to achieve here, but a few > changes in the documentation would go a long way in resolving this. Dear Maintainers, I'd like to second this: I wanted to add a local key, and could not find out how to do so now that apt-key is deprecated. I looked in apt-secure(8), but the /etc/apt/trusted.gpg.d/ directory is not even mentioned. In the end, with some web searching, the only reference I found to the "correct" way to do it was this bug report! Please do update the manpages for apt-key and apt-secure in the way that Vincent has suggested - ideally, in time for the bullseye freeze, so that it is in the upcoming Debian stable. This makes it obvious what to do instead of using apt-key: "just add/remove GPG keys to/from the directory /etc/apt/trusted.gpg.d as desired". Best wishes, Julian
Bug#978728: ITP: kio-fuse -- FUSE Interface for KIO
Package: wnpp Severity: wishlist Owner: Norbert Preining X-Debbugs-Cc: debian-de...@lists.debian.org, debian-qt-...@lists.debian.org * Package name: kio-fuse Version : 5.0.0 Upstream Author : Fabian Vogt * URL : https://invent.kde.org/system/kio-fuse * License : GPL-3-KDEeV Programming Lang: C++ Description : FUSE Interface for KIO KIOFuse allows the possibility to mount KIO filesystems in the local system, exposing them to every application. *** Will be packaged in the Debian Qt/KDE maintainers group
Bug#978727: bpfcc: Provide separate package for libbpf-tools?
Package: bpfcc Version: 0.17.0-9 Severity: wishlist Hi! (Cc-ing the kernel team, since it might be relevant for coordination or packaging efforts, please feel free to reassign to src:linux if that should be more appropriate) With the ongoing efforts around BTF and CO-RE (see http://www.brendangregg.com/blog/2020-11-04/bpf-co-re-btf-libbpf.html), it would be nice to have a decent and working toolchain for it with our upcoming bullseye release. Given that CONFIG_DEBUG_INFO_BTF support is in the works (see #973870), it would be nice, if we could provide bcc's libbpf-tools through a separate package. Looking at e.g. libbpf-tools's compiled biolatency binary, it only depends on libc6, libelf1 + zlib1g and it's less than 250kb (stripped) total size: | % ldd ./biolatency | linux-vdso.so.1 (0x7ffcb01ef000) | libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1 (0x7f348b386000) | libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f348b369000) | libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f348b1a4000) | /lib64/ld-linux-x86-64.so.2 (0x7f348b3e6000) | % ls -lah ./biolatency | -rwxr-xr-x 1 mika mika 239K Dec 30 13:47 ./biolatency Same for all the other tools which are currently shipped via libbpf-tools (see https://github.com/iovisor/bcc/tree/master/libbpf-tools), all being below 250KB and depending only on libc6, libelf1 + zlib1g. Whereas bpfcc-tools pulls in over 200MB of of additional disk space, bpftrace still also adds ~190MB of disk space - mainly due to their dependency on libllvm11. So IMO it would be great, if it's possible to ship libbpf-tools on Debian/bullseye systems without giving it much thoughts due to dependencies and disk space requirements. regards -mika- signature.asc Description: Digital signature
Bug#978640: undefined symbol: _ZTIN3fmt2v612format_errorE
On Tue, 29 Dec 2020 23:26:38 +0530, Utkarsh Gupta said: > Hi Hubert, > On Tue, Dec 29, 2020 at 11:17 PM Hubert Chathi wrote: >> Hmm. Can you try installing libfmt7 (from sid) and see if that fixes >> it? > The issue could be fixed by rebuilding nheko against the newly updated > libfmt-dev version. I've prepared and pushed a fix to the salsa > repository. If it's okay with you, can I do the upload as well? binNMU requested at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978722 Apparently waiting for an update to spdlog. -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Bug#978194: openms: FTBFS: glpk.h:36:16: error: using typedef-name ‘glp_prob’ after ‘struct’
Package: openms
Version: 2.6.0+cleaned1-1
Followup-For: Bug #978194
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* d/p/fix-glpk-version-check.patch: Fix GLPK version check that doesn't
account for major version, fixing FTBFS against GLPK 5.
Thanks for considering the patch.
Logan
-- System Information:
Debian Release: bullseye/sid
APT prefers groovy-updates
APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500,
'groovy'), (100, 'groovy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-33-generic (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru openms-2.6.0+cleaned1/debian/patches/fix-glpk-version-check.patch
openms-2.6.0+cleaned1/debian/patches/fix-glpk-version-check.patch
--- openms-2.6.0+cleaned1/debian/patches/fix-glpk-version-check.patch
1969-12-31 19:00:00.0 -0500
+++ openms-2.6.0+cleaned1/debian/patches/fix-glpk-version-check.patch
2020-12-30 13:01:49.0 -0500
@@ -0,0 +1,11 @@
+--- a/src/openms/include/OpenMS/DATASTRUCTURES/LPWrapper.h
b/src/openms/include/OpenMS/DATASTRUCTURES/LPWrapper.h
+@@ -51,7 +51,7 @@
+ #define GLP_PROB_DEFINED
+ // depending on the glpk version
+ // define glp_prob as forward or struct
+-#if OPENMS_GLPK_VERSION_MINOR < 48
++#if OPENMS_GLPK_VERSION_MAJOR == 4 && OPENMS_GLPK_VERSION_MINOR < 48
+ typedef struct
+ {
+ double _opaque_prob[100];
diff -Nru openms-2.6.0+cleaned1/debian/patches/series
openms-2.6.0+cleaned1/debian/patches/series
--- openms-2.6.0+cleaned1/debian/patches/series 2020-12-15 08:29:00.0
-0500
+++ openms-2.6.0+cleaned1/debian/patches/series 2020-12-30 13:00:56.0
-0500
@@ -1,2 +1,3 @@
sonameAndNameLinkSkipCmakeBuildSystem.patch
installDirsSettingsCmakeBuildSystem.patch
+fix-glpk-version-check.patch
Bug#978725: ITP: ethflop -- Ethernet DOS floppy emulator
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: ethflop Version : 20191003 Upstream Author : Mateusz Viste * URL : http://ethflop.sourceforge.net * License : ISC Programming Lang: C, x86 assembly Description : Ethernet DOS floppy emulator ethflop is a network-backed floppy emulator for DOS, mapping a DOS floppy drive to a remote disk image. This package contains the server and the DOS TSR.
Bug#978724: RFS: dhcpcd-dbus/0.6.1-1 [QA] -- DBus bindings for dhcpcd
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dhcpcd-dbus": * Package name: dhcpcd-dbus Version : 0.6.1-1 Upstream Author : Roy Marples * URL : https://roy.marples.name/projects/dhcpcd * License : BSD-2 * Vcs : [fill in URL of packaging vcs] Section : net It builds those binary packages: dhcpcd-dbus - DBus bindings for dhcpcd To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dhcpcd-dbus/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dhcpcd-dbus/dhcpcd-dbus_0.6.1-1.dsc Changes since the last upload: dhcpcd-dbus (0.6.1-1) unstable; urgency=medium . * QA upload. * New upstream release. * Fixed Lintian reports. * debian/control: - Bumped Standards-Version to 4.5.1. - Added Rules-Requires-Root: no. - Updated homepage field. * debian/watch: - Fixed problem to import tarball via uscan. - Updated version of 3 to 4. * debian/copyright: - Updated year upstream author. - Updated source field. - Updated file following DEP-5. - Added files debian/* and people involved with year of contribution. - Added myself. * debian/rules: - Set ignore dh_auto_test to fix FTBFS (Fails To Build From Source) and thanks to Simon McVitie maintainer of the dbus who helped me with this. * Added debian/gbp.conf. * Added debian/upstream/metadata. * Added debian/test/control to autopkgtest. * Added debian/salsa-ci.yml. Regards, -- Leandro Cunha
Bug#978722: nmu: nheko_0.7.2-3
On 2020-12-30 15:57:32, Hubert Chathi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > It looks like there was a bug in libfmt which caused its dependent > packages to be lacking a "Depends: libfmt7". Rebuilding against the > latest libfmt-dev fixes this. So I'm requesting to rebuild nheko > 0.7.2-3 to fix #978640. > > nmu nheko_0.7.2-3 . ANY . -m "rebuild against new libfmt" This needs an upload of spdlog first. See #978471. Cheers -- Sebastian Ramacher
Bug#883300: patch added
I've added you patch with additional link to the LTS and extended LTS pages. See ccf6e79eefe5b0ce09c41d5b657645e86214a9f3 -- regards Thomas
Bug#978723: krb5-strength has lots of unsatisfiable cross Build-Depends
Source: krb5-strength Version: 3.2-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability krb5-strength cannot be cross built from source, because a lot of its build dependencies are not satisfiable. Before delving into this issue, I observe a number that look like they're used for testing and we cannot run tests during cross builds. Thus I looked into what is droppable with and a lot is. Thanks to being reproducible, I verified that dropping these yield a bit-identicial artifact. Please consider applying the attached patch to significantly reduce the problem and close this bug when doing so. Helmut diff --minimal -Nru krb5-strength-3.2/debian/changelog krb5-strength-3.2/debian/changelog --- krb5-strength-3.2/debian/changelog 2020-05-17 19:27:44.0 +0200 +++ krb5-strength-3.2/debian/changelog 2020-12-30 21:14:34.0 +0100 @@ -1,3 +1,10 @@ +krb5-strength (3.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Annotate test dependencies with . (Closes: #-1) + + -- Helmut Grohne Wed, 30 Dec 2020 21:14:34 +0100 + krb5-strength (3.2-1) unstable; urgency=medium * New upstream release. diff --minimal -Nru krb5-strength-3.2/debian/control krb5-strength-3.2/debian/control --- krb5-strength-3.2/debian/control2020-05-17 19:27:44.0 +0200 +++ krb5-strength-3.2/debian/control2020-12-30 21:14:34.0 +0100 @@ -3,25 +3,25 @@ Priority: optional Maintainer: Russ Allbery Build-Depends: - cracklib-runtime, +# cracklib-runtime, debhelper-compat (= 13), libcdb-dev, libcrack2-dev, - libcrypt-pbkdf2-perl, - libdb-file-lock-perl, + libcrypt-pbkdf2-perl , + libdb-file-lock-perl , libdbd-sqlite3-perl, libdbi-perl, - libfile-slurp-perl, - libgetopt-long-descriptive-perl, - libipc-run-perl, + libfile-slurp-perl , + libgetopt-long-descriptive-perl , + libipc-run-perl , libjson-perl, libkrb5-dev (>= 1.9), libperl6-slurp-perl, libreadonly-perl, libsqlite3-dev, - libtest-minimumversion-perl, - libtest-pod-perl, - libtest-strict-perl, + libtest-minimumversion-perl , + libtest-pod-perl , + libtest-strict-perl , perl, pkg-config, tinycdb,
Bug#912173: ring FTCBFS: multiple reasons
Hi Amin, On Wed, Dec 30, 2020 at 03:28:10PM -0500, Amin Bandali wrote: > Whoops, you're quite right, sorry! I somehow misread/misunderstood the > report. I have not tried your patch yet. Would you please share the > exact series of commands used to attempt the above build, so I could try > and do some digging locally? This particular log was produced by sbuild. In order to cross build with sbuild for arm64, you pass --host=arm64. If you prefer using pbuilder, the option becomes --host-arch arm64. If you use something else, you need to pass --host-arch arm64 to dpkg-buildpackage. Hope this helps. please let me know if this doesn't. Beware that cross building is not an expected archive feature. It is more like a port. Maintainers are supposed to apply patches on a best-effort basis and porters (like me) are supposed to supply them. So if you run into some error that you deem too difficult, don't hesitate to post a build log to debian-cr...@lists.debian.org to receive help. Making jami cross buildable will be a longer journey. My patch goes a long way, but it is insufficient. Helmut
Bug#978722: nmu: nheko_0.7.2-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu It looks like there was a bug in libfmt which caused its dependent packages to be lacking a "Depends: libfmt7". Rebuilding against the latest libfmt-dev fixes this. So I'm requesting to rebuild nheko 0.7.2-3 to fix #978640. nmu nheko_0.7.2-3 . ANY . -m "rebuild against new libfmt" Thanks
Bug#966555: fixed in tuned 2.14.0-1
Hi Evgeni, I just wanted to thank you for 2.15.0-1, and to report that my hopes were fulfilled! Tuned has finally surpassed the custom sysctls and other tunings I've been using for years. Over ~12h, I'm now seeing "3 (10)" xruns rather than "~20 (~300)"! So yeah, realtime audio reliability is much improved (finally!) which is *really* nice to see :-) So far the "latency-performance" profile has been good enough, and I haven't needed to use "realtime" one. Best, Nicholas signature.asc Description: PGP signature
Bug#978721: RFP: crdt-el -- collaborative editing for Emacs using Conflict-free Replicated Data Types
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: crdt-el Version : git master Upstream Author : Qiantan Hong * URL : https://code.librehq.com/qhong/crdt.el/ * License : GPL3 Programming Lang: Emacs Lisp Description : collaborative editing for Emacs using Conflict-free Replicated Data Types crdt.el is a real-time collaborative editing environment for Emacs using Conflict-free Replicated Data Types. Highlights: - CRDT, darling child of collaborative editing researches... - Share multiple buffer in one session - See other users’ cursor and region - (experimental) synchronize Org mode folding status - Should work with all of Org mode
Bug#978720: RFP: elpa-literate-calc-mode -- Inline calculations in any Emacs buffer
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-literate-calc-mode Version : git master Upstream Author : Robin Schroer * URL : https://github.com/sulami/literate-calc-mode.el * License : GPL3 Programming Lang: Emacs Lisp Description : Inline calculations in any Emacs buffer Displays inline results for calculations, supports variables and updates as you type (if you want). Also works in your favourite markup mode. There is both a major literate-calc-mode and a minor literate-calc-minor-mode. The major mode does some basic syntax highlighting, while the minor mode only evaluates all calc statements while typing.
Bug#912173: ring FTCBFS: multiple reasons
Hi Helmut, Helmut Grohne writes: > Hi Amin, > > On Wed, Dec 30, 2020 at 11:30:48AM -0500, Amin Bandali wrote: >> I'm inclined to close this since Jami builds fine now. > > Doesn't look like that to me: > > http://crossqa.debian.net/build/ring_20201217.1.80217fa%7Eds1-2_arm64_20201229181656.log > > Did you try applying my patch? > > Helmut > Whoops, you're quite right, sorry! I somehow misread/misunderstood the report. I have not tried your patch yet. Would you please share the exact series of commands used to attempt the above build, so I could try and do some digging locally? Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#978719: cantor: unregistered code copy of discount
Source: cantor Version: 4:20.12.0-1 Severity: important cantor contains an embedded code copy of discount (a markdown processor). The Debian policy recommends not using such copies and instead using the archive copy. Did you attempt to unembed discount? In some cases, unembedding is impossible. In such cases, embedded copies should be registered with the security tracker. Please see https://wiki.debian.org/EmbeddedCopies for details on the process. Please close this bug when either unembedding discount or registering the copy. Helmut
Bug#912173: ring FTCBFS: multiple reasons
Hi Amin, On Wed, Dec 30, 2020 at 11:30:48AM -0500, Amin Bandali wrote: > I'm inclined to close this since Jami builds fine now. Doesn't look like that to me: http://crossqa.debian.net/build/ring_20201217.1.80217fa%7Eds1-2_arm64_20201229181656.log Did you try applying my patch? Helmut
Bug#978718: readme file in courier-base still has confused lines
Package: courier-base Version: 1.0.14-1 Severity: important the courier-base README.Debian file is badly formatted and has missing important info not reflected. bug report #974585 : was closed in 1.0.14-1 but the README.DEbian file still points that the "error" are hidden! what? i pointed that also.. the file could produce confusion about if there's some problems if FAM are not running and the admin read that line! i send a pull request for that .. each pull request (stupidly) it takes so much time to work cos i have very limited connection so i hope you read all the mails too Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#900381: Fails to boot cirros QEMU image with tuned running
On Wed, Dec 30, 2020 at 01:06:45PM +0100, Evgeni Golov wrote: > > This doesn't happen on the buster cloud images, and a few "apt install" > > invocations later I could bisect the issue to be the upgrade of seabios > > from 1.12.0-1 to 1.14.0-2. > > > > I also can't repro this in vagrant (by using the buster64 box and > > upgrading it fully to testing) with libvirt/qemu as a backend instead of > > plain qemu. > > > > So there seem to be more levels of weirdness to this. > > > And the tuned line that breaks the whole thing is > > [sysctl] > kernel.sched_wakeup_granularity_ns = 1500 This also happens on seabios 1.13.0-1 from snapshot.d.o. I originally wanted to go and bisect that with upstream seabios.git, but then couldn't reproduce with upstreams 1.14.0… Until I realized that I built it with CONFIG_ATA_DMA=y (as Debians 1.12) and indeed, this is what was changed in 1.13 to n (see [1]) and also what does trigger the bug you describe: with ATA_DMA=n the boot hangs, with ATA_DMA=y it boots fine. Now understanding *why* ATA_DMA=n and sched_wakeup_granularity_ns together have this result requires more scotch than I have at hand right now. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934134
Bug#755092: soscks5 support needs hole recompilation and new package
This depends of a new package to made in debian: Courier Socks 5 Proxy client library, which allows Courier to send outgoing mail using a Socks 5 proxy. This means need to convert or merge this bug request in a RFP of the Courier Socks 5 proxy before building Courier in order to use a Socks proxy to send outgoing mail. FEATURES: 1. Courier-mta is the only suite that can use a socks5 to delivery to a different network 2. Access control: define IP address ranges allowed to proxy through the server. 3. Access control: import list of banned IP address range, in the P2P file format. A "socksify" application wrapper script, that uses shared library tricks to try to redirect network connections from standalone application through the Socks 5 proxy server. http://www.courier-mta.org/download.html#sox Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#959804: debian-security-support | Mark mozjs78 as having limited security support (!7)
On Mon, Dec 28, 2020 at 12:01:22PM +, Simon McVittie wrote as part of MR 7 to debian-security-support.git: > mozjs78 is the version of SpiderMonkey that will be in bullseye. > It's in the same situation as mozjs68 and earlier versions: it has > upstream security support right now, but the upstream security support > will finish part way through the lifetime of bullseye, and updates are > slow to prepare due to its large size. The package description > specifically calls it out as unsuitable for untrusted scripts. ack, thanks. maybe a new bug for this would have been nice(r), we'll see. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ Life is short but a sea of morons is forever. signature.asc Description: PGP signature
Bug#978717: RFS: openscad/2019.05-4 [RC] -- script file based graphical CAD environment
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for a new upload for package "openscad", which I have been maintaining for a couple years. This upload fixes a FTBFS and is needed to get openscad back into the archive. * Package name: openscad Version : 2019.05-4 Upstream Author : Clifford Wolf, Marius Kintel, and others * URL : http://openscad.org/ * License : QtCommercial or LGPL-2.1 with some exception or GPL-3, Apache-2.0, PD-trochoids or LGPL-2.1, BSD-2-clause or LGPL-2.1, PD-nefercheprure or LGPL-2.1, GPL-2+ with CGAL exception and pythonparts, AGPL-3, GPL-3+, CC or LGPL-2.1, GPL-3 or LGPL-2.1, LGPL-2.1, zlib, PD, LGPL-2 or LGPL-2.1, CC0-1.0, SIL-OFL, CC-BY-3.0 or LGPL-2.1, MIT, MIT-MCAD or LGPL-2.1, GPL-2+, GPL-2+ with CGAL exception, LGPL-3 or LGPL-2.1, CC0, CC-BY-SA-3.0 or LGPL-2 or LGPL-2.1 * Vcs : https://salsa.debian.org/knielsen-guest/openscad Section : graphics It builds those binary packages: openscad-testing-data - script file based graphical CAD environment (test suite data) openscad-testing - script file based graphical CAD environment (test suite) openscad - script file based graphical CAD environment To access further information about this package, please visit the following URL: https://mentors.debian.net/package/openscad/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/openscad/openscad_2019.05-4.dsc Changes since the last upload: openscad (2019.05-4) unstable; urgency=medium . * Make openscad-testrun default to run tests in parallel. * Limit --parallel build based on available memory (Closes: #945162). * Fix build with newer boost library (Closes: #977225). * Clean up some lintian warnings. - Kristian.
Bug#970055:
Hello Maintainer, Any chance of 2.46 making it in before the upcoming freeze? Is there an issue with archmage blocking the build again? Thanks!
Bug#883424: build-essential: Please enable Debian Ports architectures for cross-build-essential
On 12/30/20 4:55 PM, Matthias Klose wrote: > closing as won't fix. See build-essential-mipsen how it could be done. OK, I'll have a look at that in the new year. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#947272: blt builds fine with gcc-10
On Wed, Dec 30, 2020 at 06:36:23PM +0300, Sergei Golovan wrote: > There isn't Tcl/Tk 8.7 in unstable yet, only an alpha in experimantal. > After the Tcl/Tk 8.7 will be released, I'll deal with this bug in > unstable. ah, ok, makes sense. probably it would still be nicer to downgrade this bug to severity important until that tcl/tk version has reached unstable. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Bug#341205: README's highly confused and wrong configurations
Mark I have decided to send this email to all 5 bug reports at the same time because they deal with the same topic: a rather confusing reading file and a configuration out of all logic in the courier-webadmin and sqwebmail packages, i just try to make the pull request for the changes required.. PLEASE read here: first of all the new apache2 config file for sqwebmail causes problems with path for static files, sqwebmail expected to find css file in /sqwebmail/sqwebmail.css but i got a http 500 error cos xtrange cgi configurations automatically made by package.. those must be erased and admins must fine tune by is own hand in each case if want hide path in urls, that's could be the reason of the question in debconf about copy or symlink, although the apache script limits access the cgi can still be accessed and there is no real security here bug report #190725 : config web for courier-webadmin and sqwebmail are all wrong, packages assumes apache2 (most inefficient web server), a bad taste, bug that's not the problem: the sqwebmail case config file said "allow only local" but is nonsense because the security is configured by a build time configuration: https://redmine.lighttpd.net/issues/304 3 times bad made the package make this unusable by confusion bug report #190725 : in same topic: the localhost build in restriction of the courier-webadmin is another very confused setting for the admin! so we should leave this alone and provide example files as it has always been in Debian bug report #126735 and #341205 : in same topic: default installation is not explained (respect the courier documented) and there's no Debian document that points the difference.. neither a document of debian way and the differences.. same case of the #190725 about #341205 i will send that patch to upstream but a README file must sove the situation for now.. this patch is trivial and must be revised cos is old about #910527 #910529 : was merged but not property explained in NEWs or README. the current courier-base pointing about the new permissions but does not said nothing about the upgrade problem that still persist and inclusively seems is also cited in the postinst script https://salsa.debian.org/debian/courier/-/merge_requests/9 https://salsa.debian.org/debian/courier/-/merge_requests/10 Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#977538: fonts-agave: does not follow upstream's recommended build procedure
Hi Fabian, Am Dienstag, den 29.12.2020, 20:37 +0100 schrieb Gürkan Myczko: I think that's what you wanted: could you please push your changes to GIT so I can review them there? I wish I could. I'm struggling with that pipeline. Maybe you can hint me? Here's what I have: http://sid.ethz.ch/debian/fonts-agave/ dget'able source packages, and build logs, could create debriffs, and I am able to gbp clone the salsa repo at https://salsa.debian.org/fonts-team/fonts-agave and I can update it to a released/uploaded version using all I know about salsa: http://bootes.ethz.ch/salsa.txt Happy New Year! It's not over yet, but I can't wait for it, too. ;) It's not like January 01/2021 at 00:00:01 would be magically much better, but yeah :) - Fabian
Bug#943676: Re: Sponsor request for 'Open Surge'
Hi. Upstream here. > From what I've seen in Open Surge it seems this is another example of > upstream copying random files from the web and pretend to have the permission > to create derivate works from them and redistribute them Let me clarify a few things. We never "copy random files from the web". The "copyright issue" you have raised is not valid. Johan Brodd (aka jobromedia) has created the song Minds Wide Open (theme.ogg) for Open Surge. He joined our project years ago and contributed with his musical talent. Free content is very important to our project and I talk to artists about it. I have talked to Johan about his music and he has agreed to release it under the public domain. Unfortunately, Johan passed away a few years back (we have even included a RIP in our credits screen). While not directly related to musics/theme.ogg, in a forum thread dated from December 2011 I explain to Johan about free content and then he decides to release his files under the public domain: http://forum.opensurge2d.org/viewtopic.php?id=1114 Regarding musics/theme.ogg specifically, I invite you to take a look at a screenshot of a private conversation between me and Johan, where he expresses gratitude for having that music included in the game: http://forum.opensurge2d.org/misc/jobro_theme.png He is a deceased man now, but he has made that music for Open Surge, and it's free. He cared and he has provided great free music to our project. The inference that our project "copies random files from the web and pretend to have permission" sounds disrespectful to me and to everybody who has contributed content. Let me also clarify that our C source code is released under the GPLv3, but our artwork is mostly under the CC-BY 3.0. We also have a few files under the public domain and under the CC-BY-SA 3.0 (check our credits screen). In addition, we have a scripting system called SurgeScript inside the game; scripts written in SurgeScript (.ss files) are released under the MIT license. We have never re-licensed any CC-BY-SA 3.0 content to the GPLv3. Artwork is not code. Years ago I read about a claimed incompatibility between the CC-BY-SA and the GPL, but I have learned since that this doesn't hold. My understanding is that they are compatible and can be mixed in a game. The popular SuperTux mixes CC-BY-SA artwork with GPL code, as can be seen in their README https://github.com/SuperTux/supertux I hope this sorts it out. If you find any issues, I'm open and willing to help. I too would like to see our project in Debian. What has been claimed, however, is a non-issue. Finally, I would like to ask you all, and in particular Carlos Donizete, to wait until the upcoming 0.5.2.0 release before uploading the package. Happy new year, Alexandre Em qua., 30 de dez. de 2020 às 11:07, Carlos Donizete Froes escreveu: > > Mensagem encaminhada > De: Bruno Kleinert > Para: Carlos Donizete Froes > Cc: Debian Games Team > Assunto: Re: Sponsor request for 'Open Surge' > Data: Wed, 30 Dec 2020 09:22:38 +0100 > > Am Mittwoch, dem 30.12.2020 um 01:01 -0300 schrieb Carlos Donizete Froes: > > Hi Bruno, > > > Unfortunately, I found a blocker from uploading the package: The licensing and > > copyright information of the game's data is missing in debian/copyright. I > > added debian/TODO to document that issue, i.e., there's still quite some work > > ahead to gather the respective copyright holders and licenses for data files. > > I picked random samples and it seems that some graphics files have that > > information in the image, while for the audio and music files copyright > > holders and license is mostly unclear. Please get in touch with upstream to > > get this sorted out! > > > Sorry, but I didn't understand what you need and what needs to be corrected to > > have all this work and mandatory part in the licenses, since the upstream > itself > > declares in the main project directory that the license is GPLv3. > > > If upstream includes a piece of work which has a license that forbids > re-licensing, e.g., images/hydra.png is CC-BY-SA-3.0, then upstream has no > permission to re-license it under GPL-3. I'm not a lawyer, but would expect > this could only work if upstream has a written exception permission by the > original author to re-license a piece of work. Since there is no permission > released with Open Surge, we cannot assume this permission exists. > > > Is it really necessary to ask upstream to add all licenses to files such as > > audio, music and images that it has created and that declares GPLv3? > > > Yes, because Debian must make sure it does not redistribute work that was > pirated by upstream. > > It seems there's even such an example in Open Surge: > > fuddl@flutschi:~/debian/opensurge/opensurge/musics$ ogginfo theme.ogg > Processing file "theme.ogg"... > […] > TITLE=Minds wide open > ARTIST=Johan Brodd > […] > > I searched the web for that song and found it on vimeo: >
Bug#978701: wireshark: Please package version 2.6.20 with GTK support
Package: wireshark Version: 2.6.8-1.1 Severity: wishlist It would be nice if the latest Wireshark 2.6.x with GTK support appears in buster/buster-backports. -- With best regards, Dmitry
Bug#978700: RFS: apulse/0.1.13-1 -- PulseAudio emulation for ALSA
> Alas:
> [...]
> dpkg-shlibdeps: error: cannot find library libpulse.so.0 needed by
debian/apulse/usr/lib/x86_64-linux-gnu/apulse/libpulse-simple.so.0 (ELF
format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
I just uploaded a possible fix:
https://mentors.debian.net/package/apulse/
It seems to work correctly on sbuild, and produces a valid package that
does not mistakenly depend on libapulse0. Apologies for not catching that
earlier.
The fix in debian/rules reads roughly:
override_dh_shlibdeps:
dh_shlibdeps -l/usr/lib/${DEB_HOST_MULTIARCH}/apulse
Is this OK, or would there be some more portable/compatible/correct way to
do that? The path is taken from the debhelper cmake defaults (see the
comments in the package).
( Finally, I still see lintian warning about 1 library not linking to libc,
is it worth reporting that to upstream? )
Thanks!
-mk
Bug#978716: RFS: smplayer-themes/1:20.11.0-1 -- complete front-end for MPlayer - icon themes
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "smplayer-themes": * Package name: smplayer-themes Version : 1:20.11.0-1 Upstream Author : Ricardo Villalba * URL : http://smplayer.sourceforge.net/ * License : CC-BY-2.5, public-domain, GPL-1+, LGPL-3.0, MIT, LGPL-2.1+, GPL-3.0+, GPL-2.0+, GPL-3.0 * Vcs : https://salsa.debian.org/multimedia-team/smplayer-themes Section : video It builds those binary packages: smplayer-themes - complete front-end for MPlayer - icon themes To access further information about this package, please visit the following URL: https://mentors.debian.net/package/smplayer-themes/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/smplayer-themes/smplayer-themes_20.11.0-1.dsc Changes since the last upload: smplayer-themes (1:20.11.0-1) unstable; urgency=medium . * New upstream release. * Bumped compat to 13. * Bumped Standards-Version to 4.5.1, no changes needed. * Add Rules-Requires-Root. * Bump d/watch version to 4. Regards, -- Mateusz Łukasik
Bug#978715: RM: simpleburn -- ROM, dead upstream, rc-buggy
Package: ftp.debian.org Severity: normal Hi, Please remove simpleburn from archive, it is upstream dead. Homepage is no longer exists. Package is FTBFS and depends on old libs. Low popcorn and has multiple replaces. Regards, Mateusz
Bug#978714: RFS: gxkb/0.9.0-1 -- X11 keyboard indicator and switcher
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "gxkb": * Package name: gxkb Version : 0.9.0-1 Upstream Author : Dmitriy Poltavchenko * URL : https://zen-tools.github.io/gxkb * License : BSD-3-clause, GAP, PERMISSIVE, GPL-2+ * Vcs : https://github.com/mati75/gxkb.git Section : x11 It builds those binary packages: gxkb - X11 keyboard indicator and switcher To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gxkb/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gxkb/gxkb_0.9.0-1.dsc Changes since the last upload: gxkb (0.9.0-1) unstable; urgency=medium . * New upstream release. + Switch to GTK3. (Closes: #967515) * Bump Standards-Version to 4.5.1 (no changes needed) * d/control: Add Rules-Requires-Root. * Bump version d/watch. Regards, -- Mateusz Łukasik
Bug#978697: ITP: libjs-blazy -- lightweight script for lazy loading and multi-serving images
Package: wnpp Severity: wishlist Owner: James Valleroy X-Debbugs-Cc: debian-de...@lists.debian.org, jvalle...@mailbox.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libjs-blazy Version : 1.8.2 Upstream Author : Bjørn Klinggaard * URL : https://dinbror.dk/blazy/ * License : Expat Programming Lang: Javascript Description : lightweight script for lazy loading and multi-serving images bLazy is a lightweight script for lazy loading and multi-serving images, iframes, videos and more (less than 1.4KB minified and gzipped). It’s written in pure JavaScript why it doesn’t depend on 3rd-party libraries such as jQuery. It lets you lazy load and multi-serve your images so you can save bandwidth and server requests. The user will have faster load times and save data usage if he/she doesn't browse the whole page. It is a dependency for Shaarli, and will be maintained in Javascript team. -BEGIN PGP SIGNATURE- iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAl/seVgWHGp2YWxsZXJv eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICNxPEADQdztnSJH/k3gQFafmR9ujPjan kVBo68Wkcqy5IQGl63Yy1hDtjPF31ZHiGOtYVZO8cfF6xgwdD3Jlw8SQH4UjC5B2 ZfY0XQUF8oYkUXGfPq+lIfDynVDEJV1c5QEUFXh+a239MEXwOlAyzUVzM4E45LuV bK7CIPaqXYnjalXyWC2EowC1Tn1uuHpiifucHOBmpF9t/SEP8eR2P5rhGwYm7HXU wD08rdXB9UBVfoTFpwh2lfPY+0dtQK3+isJJDVS5dTmdpvHv+OIt7ETIcXzK2oOs o74KftvQg4D6G5NOL9feWzLJxAvELOooeREJ81cpXtc+hPJr/8xYz80vwerZAwSW d+AkhIvaULv+CkRqIBBfHfsn3zt+iBIUkIaV72YetYWbroPcdugGpC9BDyu7bvt9 /ng9XimPYWYhwu+qDYGKmDP5bjXprXdXIVhuHWLBdXyW9Vj+oqJuXOCr9vLoFawV 1e3IY9c3ISCmw4Ia5Q7DwmsUhL6rFG+E317FCaMvzIPghGUmqZd+dNNuvjGqQ4oL BvYr08C2AlzBgjsuq8knMYqUbdf8OoBm3tlLHpwhxtbvUub+mLXa/t+bEeLxaz5r sK/9Lfu1QuoDLC1tu6qBhGrtfuMjIzbx/V7o43gLXRmoKnwDE2dJCMIO+EHBaoYh f9K9NBDsi1EGst55JQ== =ekBC -END PGP SIGNATURE-
Bug#978661: sympa: Security update 6.2.40~dfsg-1+deb10u1 fails to install - related to bash(?)
On 12/30/20 4:57 PM, Harri Suutari wrote:
> Problem solved (sort of) by commenting out lines in /etc/profile:
>
> ## include /etc/bash.bashrc if it exists
> #if [ -f /etc/bash.bashrc ]; then
> # . /etc/bash.bashrc
> #fi
>
> I had had this inclusion in /etc/profile for at least 15 years, and this
> seemed to be the 1st time it caused a problem.
> I read "man dash" and noticed Dash also uses /etc/profile, so probably Bash
> specific configuration there is not a good
> idea anymore.
>
> Update of Debian to Buster earlier asked about changing from sh to dash, so I
> let it do it.
>
Error logs seem to be:
-sh: 11: /etc/bash.bashrc: shopt: not found
-sh: 35: /etc/bash.bashrc: shopt: not found
-sh: 26: /usr/share/bash-completion/bash_completion: Syntax error: "("
unexpected
>>> This appears to come from the following command in the postinst script:
>>>
>>> su -l sympa -s /bin/sh -c "/usr/lib/sympa/bin/sympa.pl
>>> --upgrade_config_location"
>>>
>>> Which shell is used for the Sympa user (getent passwd sympa) ?
>>>
>>> Which shell is /bin/sh on your system?
>>>
> # getent passwd sympa
> sympa:x:148:159:Sympa mailing list manager,,,:/var/lib/sympa:/bin/false
>
> # ls -al /bin/sh
> lrwxrwxrwx 1 root root 4 Feb 10 2020 /bin/sh -> dash
>
>
>> It might be a similar problem to
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737621.
>
> Yes, directly related to bash / dash / sh shells. Older systems have had
> different defaults during installation, which
> seems to backfire sometimes.
>
>
Thanks for the information. That helps me to reproduce the problem and maybe
prevent the error.
Regards
Racke
--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.
OpenPGP_signature
Description: OpenPGP digital signature
Bug#950793: blhc: Reports missing -D_FORTIFY_SOURCE=2 for libtool linking
Hello, Thomas Stewart, le jeu. 06 févr. 2020 15:21:16 +, a ecrit: > CPPFLAGS missing (-D_FORTIFY_SOURCE=2): libtool: link: (cd .libs && gcc -g > -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wall -c -fno-builtin "w1retapS.c") "me too" with the speech-dispatcher package. https://salsa.debian.org/tts-team/speech-dispatcher/-/jobs/1295146 CPPFLAGS missing (-D_FORTIFY_SOURCE=2): libtool: link: (cd .libs && gcc -g -O2 -fdebug-prefix-map=/builds/tts-team/speech-dispatcher/debian/output/source_dir=. -fstack-protector-strong -Wformat -Werror=format-security -c -fno-builtin "sd_dummyS.c") > However looking at the build log snippet[0] the full command is actually > a call to libtool in link mode. This libtool invocation generates a new > S.c file to generate dlsyms information. Looking at the internals of a > generated libtool[1], it's basing the gcc args on LTCFLAGS. > > When libtool is generated it bases its LTCFLAGS from CFLAGS[2]. Looking > at the dpkg-buildflags hardening the -D_FORTIFY_SOURCE=2 flag is for > CPPFLAGS rather than CFLAGS[3]. In the debian packaging we don't really have control over the LTCFLAGS definition, so we can't really fix it there. We'd thus need either blhc to ignore these libtool-related builds, or libtool to be patched to include CPPFLAGS in LTCFLAGS. Samuel
Bug#912173: ring FTCBFS: multiple reasons
I'm inclined to close this since Jami builds fine now. Alexandre? -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#978704: securefs: autopkgtests hard-code dependency on libcrypto++6
thanks for the reports, I will fix this in the next couple days Sebastian Ramacher writes: > On 2020-12-30 15:06:19 +0100, Sebastian Ramacher wrote: >> Source: securefs >> Version: 0.11.1+ds-1 >> Severity: serious >> X-Debbugs-Cc: sramac...@debian.org >> >> securefs' autopkgtests hard-code dependencies on a bunch of shared >> libraries: libcrypto++6, libfuse2, libjsoncpp1, and libutf8profc2. This >> is most certainly wrong when securefs is rebuilt for transitions. At >> least the dependencies on libcrypto++6 and libjsoncpp1 are no longer >> correct. >> >> Having dependencies on the -dev packages there or installing securefs >> would make more sense to get the right runtime libraries. > > On second thought, installing securefs could also give the wrong > results. So the former would make more sense. In any case, this issue > causes autopkgtest failures: > > autopkgtest [05:13:56]: test command2: cd obj-x86_64-linux-gnu && > ./securefs_test > autopkgtest [05:13:56]: test command2: [--- > ./securefs_test: error while loading shared libraries: libcrypto++.so.8: > cannot open shared object file: No such file or directory > autopkgtest [05:13:56]: test command2: ---] > autopkgtest [05:13:56]: test command2: - - - - - - - - - - results - - - - - > - - - - - > command2 FAIL non-zero exit status 127 > > See > https://ci.debian.net/data/autopkgtest/testing/amd64/s/securefs/9241910/log.gz > > Cheers
Bug#978713: libreoffice-wiki-publisher: Wrong homepage for the project
Package: libreoffice-wiki-publisher
Version: 1.2.0+LibO6.1.5-3+deb10u6
Severity: minor
Dear Maintainer,
On https://packages.debian.org/unstable/libreoffice-wiki-publisher the homepage
for the project is reported as:
http://extensions.services.openoffice.org/project/wikipublisher .
However this is not a link to the proper code, and the
https://extensions.libreoffice.org/
doesn't list the extension, as it is a part of core. I'd link to:
https://github.com/LibreOffice/core/tree/master/swext/mediawiki
which is at least linked to the right software.
Thanks, I just thought it would help knowing the package isn't a
13 year old plugin :D.
G
-- Package-specific info:
Identifier: com.sun.wiki-publisher
Version: 1.2.0
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description: The Wiki Publisher enables you to create Wiki articles on
MediaWiki servers without having to know the syntax of the MediaWiki markup
language. Publish your new and existing documents transparently with the Writer
to a wiki page.
bundled Packages: {
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/help
is registered: yes
Media-Type: application/vnd.sun.star.help
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcs
is registered: yes
Media-Type: application/vnd.sun.star.configuration-schema
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiEditor/
is registered: yes
Media-Type: application/vnd.sun.star.basic-library
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/components.rdb
is registered: yes
Media-Type: application/vnd.sun.star.uno-components
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Addons.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/ProtocolHandler.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/OptionsDialog.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Filter.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Types.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Paths.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
}
-- System Information:
Debian Release: 10.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-11-amd64 (SMP w/4 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 libreoffice-wiki-publisher depends on:
ii default-jre [java6-runtime] 2:1.11-71
ii libreoffice-core1:6.1.5-3+deb10u6
ii libreoffice-java-common 1:6.1.5-3+deb10u6
ii openjdk-11-jre [java6-runtime] 11.0.8+10-1~deb10u1
ii openjdk-8-jre [java6-runtime] 8u212-b01-1~deb9u1
libreoffice-wiki-publisher recommends no packages.
Versions of packages libreoffice-wiki-publisher suggests:
pn mediawiki
-- debconf-show failed
Bug#978616: mediastreamer2: doesn't build correct libraries with cmake?
Dear Gianfranco, Thanks for filing this bug report. I’m away for the next couple of days and could not check, but wouldn’t just patching the pkgconfig file (your second option) be a lot easier? Upstream merged both libraries and they probably just forgot to change the pkgconfig file as well. In the end linphone upstream does not seem to care much about other programs using their library. Bernhard > Am 29.12.2020 um 11:00 schrieb Gianfranco Costamagna > : > Source: mediastreamer2 > Version: 1:4.4.21-2 > Severity: serious > > Hello, looks like with autotools, the library provides libmediastreamer_base > and libmediastreamer_voip, > while with cmake it doesn't. > > the pkgconfig file is obviously wrong, but I don't know which solution you > prefer (and if you are aware of this issue). > > I propose two solutions: > 1) implement the library split in cmake, and upstream it (this might be the > preferred and easier solution to this issue) > 2) patch pkgconfig file and cmake helpers to provide only one library to link. > > if we choose 1, we should probably also change the ABI, so call it > libmediastreamer11a or similar, to trigger a rebuild of reverse dependencies. > > If you agree with 1) I can try to provide a patch as soon as possible. > > thanks > > Gianfranco
Bug#978701: wireshark: Please package version 2.6.20 with GTK support
Control: tags -1 wontfix Hi Dmitry, Dmitry Katsubo ezt írta (időpont: 2020. dec. 30., Sze, 14:27): > > Package: wireshark > Version: 2.6.8-1.1 > Severity: wishlist > > It would be nice if the latest Wireshark 2.6.x with GTK support appears in > buster/buster-backports. Buster-backports receives backports from testing where the version is already at 3.4.0-1, thus 2.6.x can't be uploaded there. Also the 2.6.x branch reached EOL on 2020.10.18: https://www.wireshark.org/docs/relnotes/wireshark-2.6.20.html It is unlikely to have a newer 2.6.x version uploaded to Buster because all the security issues are marked as not being important enough to warrant an upload: https://security-tracker.debian.org/tracker/source-package/wireshark Cheers, Balint > > -- > With best regards, > Dmitry >
Bug#978712: libneon27-gnutls: Should not treat missing OCSP stapling as error
Package: libneon27-gnutls
Version: 0.30.2-3
Severity: normal
Tags: patch
Hello maintainers!
Since a little while ago, I could no longer synchronize my laptop with
my Radicale server:
What happens:
--8<---cut here---start->8---
$ syncevolution radicale
[WARNING] radicale: ignoring username , it is not needed
[WARNING] radicale: ignoring username , it is not needed
[INFO @radicale] target side of local sync ready
[INFO @radicale] @radicale/cal-personal: using configured
database=https://butters.digitalbrains.com:5232/peter/calendars/personal.ics/
[ERROR @radicale] transport problem: REPORT 'check for items': Neon error code
1, no HTTP status: Certificate verification error: unrecognized errors (524288)
[...]
--8<---cut here---end--->8---
What should happen:
--8<---cut here---start->8---
[WARNING] radicale: ignoring username , it is not needed
[WARNING] radicale: ignoring username , it is not needed
[INFO @radicale] target side of local sync ready
[INFO @radicale] @radicale/cal-personal: using configured
database=https://butters.digitalbrains.com:5232/peter/calendars/personal.ics/
[INFO @radicale] @radicale/cal-vakanties: using configured
database=https://butters.digitalbrains.com:5232/peter/calendars/vakanties.ics/
[INFO @radicale] @radicale/con-personal: using configured
database=https://butters.digitalbrains.com:5232/peter/contacts/personal.vcf/
[INFO @radicale] @radicale/tasks-personal: using configured
database=https://butters.digitalbrains.com:5232/peter/tasks/personal.ics/
[INFO @radicale] @radicale/cal-personal: starting normal sync, two-way (peer is
server)
[INFO @radicale] @radicale/cal-vakanties: starting normal sync, two-way (peer
is server)
[INFO @radicale] @radicale/con-personal: starting normal sync, two-way (peer is
server)
[INFO @radicale] @radicale/tasks-personal: starting normal sync, two-way (peer
is server)
[...]
--8<---cut here---end--->8---
cadaver fares no better:
--8<---cut here---start->8---
$ cadaver https://butters.digitalbrains.com:5232/peter/
Could not open collection:
Certificate verification error: unrecognized errors (524288)
dav:/peter/?
--8<---cut here---end--->8---
The Radicale server is the latest from debian-oldstable/stretch:
radicale 1.1.1+20160115-4.
It turns out that GnuTLS requests OCSP stapling from the Radicale
server, but the Radicale server does not include a stapled response.
When libneon invokes GnuTLS's gnutls_certificate_verify_peers2(), it
returns a bit set in gnutls_certificate_status_t:
/**
* gnutls_certificate_status_t:
* @GNUTLS_CERT_MISSING_OCSP_STATUS: The certificate requires the server to
send the certifiate status, but no status was received.
*/
typedef enum {
GNUTLS_CERT_MISSING_OCSP_STATUS = 1 << 19,
} gnutls_certificate_status_t;
This is the 524288 (1 << 19) seen in the error messages above.
The conservative patch is simple, and has been attached. It is for
Debian stable, because I currently don't have a properly configured VM
for doing it based on unstable, and it is so trivial that I don't think
this will present any problems to you. Please let me know if I am
mistaken in this or you'd like me to do further tests.
For discussion I here include the patch:
-if (status && status != GNUTLS_CERT_INVALID) {
+if (status && status != GNUTLS_CERT_INVALID
+&& status != GNUTLS_CERT_MISSING_OCSP_STATUS) {
char *errstr = verify_error_string(status);
ne_set_error(sess, _("Certificate verification error: %s"), errstr);
ne_free(errstr);
return NE_ERROR;
}
I don't really understand why GNUTLS_CERT_INVALID does /not/ cause
certificate verification to fail. But it could be that this bit is never
set alone, always together with a more precise failure bit, and as such
it never triggers on modern GnuTLS's (since it tests that only that bit
is set). This test was introduced in neon upstream in this git commit:
https://github.com/notroj/neon/commit/b514d5b2864155431c155d051fa4aa306fd4
commit b514d5b
Author: Joe Orton
Date: Tue Aug 11 14:15:33 2009 +
With the patch applied, syncevolution again works as above in "What
should happen", and cadaver is also much happier:
--8<---cut here---start->8---
$ cadaver https://butters.digitalbrains.com:5232/peter/
Authentication required for Radicale - Password Required on server
`butters.digitalbrains.com':
Username: peter
Password:
dav:/peter/> ls
Listing collection `/peter/': succeeded.
[...]
--8<---cut here---end--->8---
Since this is something that worked fine on Debian stable until some
weeks ago, and then stopped working, I strongly suspect some Debian
stable update introduced a change causing this new
Bug#978661: sympa: Security update 6.2.40~dfsg-1+deb10u1 fails to install - related to bash(?)
Problem solved (sort of) by commenting out lines in /etc/profile:
## include /etc/bash.bashrc if it exists
#if [ -f /etc/bash.bashrc ]; then
# . /etc/bash.bashrc
#fi
I had had this inclusion in /etc/profile for at least 15 years, and
this seemed to be the 1st time it caused a problem. I read "man dash"
and noticed Dash also uses /etc/profile, so probably Bash specific
configuration there is not a good idea anymore.
Update of Debian to Buster earlier asked about changing from sh to
dash, so I let it do it.
Error logs seem to be:
-sh: 11: /etc/bash.bashrc: shopt: not found
-sh: 35: /etc/bash.bashrc: shopt: not found
-sh: 26: /usr/share/bash-completion/bash_completion: Syntax error: "("
unexpected
This appears to come from the following command in the postinst script:
su -l sympa -s /bin/sh -c "/usr/lib/sympa/bin/sympa.pl
--upgrade_config_location"
Which shell is used for the Sympa user (getent passwd sympa) ?
Which shell is /bin/sh on your system?
# getent passwd sympa
sympa:x:148:159:Sympa mailing list manager,,,:/var/lib/sympa:/bin/false
# ls -al /bin/sh
lrwxrwxrwx 1 root root 4 Feb 10 2020 /bin/sh -> dash
It might be a similar problem
tohttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737621.
Yes, directly related to bash / dash / sh shells. Older systems have
had different defaults during installation, which seems to backfire
sometimes.
Bug#931061: closing as won't fix
closing as won't fix, the packages are installable.
Bug#883424: build-essential: Please enable Debian Ports architectures for cross-build-essential
closing as won't fix. See build-essential-mipsen how it could be done.
Bug#815172: testing required ...
Control: tags -1 + moreinfo please create a few test packages in the archive to test how the current Debian infrastructure handles foreign architectures: - a source package not b-d on a foreign architecture, creating a binary package depending on one foreign architecture. The foreign architecture is a release architecture. - a source package not b-d on a foreign architecture, creating a binary package depending on more than one foreign architecture. The foreign architecture is a release architecture. - a source package not b-d on a foreign architecture, creating a binary package depending on one foreign architecture. The foreign architecture is a ports architecture. - a source package not b-d on a foreign architecture, creating a binary package depending on more than one foreign architecture. The foreign architecture is a ports architecture. - a source package b-d on a a foreign architecture, creating a binary package depending on one foreign architecture. The foreign architecture is a release architecture. - a source package b-d on a a foreign architecture, creating a binary package depending on one foreign architecture. The foreign architecture is a ports architecture.
Bug#978711: ITP: etherdfs-server -- Ethernet DOS File System server
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: etherdfs-server Version : 0~20180203 Upstream Author : Mateusz Viste * URL : http://etherdfs.sf.net/ * License : MIT Programming Lang: C Description : Ethernet DOS File System server EtherDFS is a DOS installable filesystem, mapping a DOS drive letter to a remote share. This package contains the server side of EtherDFS, a daemon exporting one or more directories for remote access by the EtherDFS DOS TSR.
Bug#978695: notepadqq: Input windows hangs so input is not possible
Package: notepadqq Version: 2.0.0~beta1-1+b1 Severity: grave Justification: renders package unusable Dear Maintainer, When notepadqq is started you expect to see an empty tab or tabs with reason files, but neither happens. Try to open a tab resolves in a frozen application and if started from command line the following is seen: js: Uncaught ReferenceError: $ is not defined js: Uncaught ReferenceError: $ is not defined Now close application and this is shown: js: Uncaught TypeError: Cannot read property 'isClean' of undefined >From here only way to actually quit the application is ^C -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages notepadqq depends on: ii coreutils8.32-4+b1 ii libc62.31-6 ii libgcc-s110.2.1-3 ii libjs-highlight.js 9.18.1+dfsg1-3 ii libjs-jquery 3.5.1+dfsg+~3.5.5-4 ii libjs-mathjax2.7.9+dfsg-1 ii libjs-modernizr 2.6.2+ds1-3 ii libjs-requirejs 2.3.6+ds-1 ii libqt5core5a 5.15.2+dfsg-2 ii libqt5gui5 5.15.2+dfsg-2 ii libqt5network5 5.15.2+dfsg-2 ii libqt5printsupport5 5.15.2+dfsg-2 ii libqt5svg5 5.15.2-2 ii libqt5webchannel55.15.2-2 ii libqt5webenginewidgets5 5.15.2+dfsg-3 ii libqt5widgets5 5.15.2+dfsg-2 ii libstdc++6 10.2.1-3 ii libuchardet0 0.0.7-1 notepadqq recommends no packages. notepadqq suggests no packages. -- no debconf information This mail was virus scanned and spam checked before delivery. This mail is also DKIM signed. See header dkim-signature.
Bug#978562: opendht: FTBFS on riscv64, linked with -lpthread instead of -pthread
Hello, Aurelien Jarno writes: > Hi, > > On 2020-12-28 18:01, Amin Bandali wrote: >> Hello Alexandre, Aurelien, >> >> Thanks for the patch. I don't have access to any riscv64 machines to >> test this. However if you confirm that it fixes the build on riscv64 >> and introduces no regressions on any arches then I'll ask for it to be >> applied upstream. > > I have tested it on riscv64, and I confirm it builds fine. As for > regression on other architectures, I have also tested this patch on > amd64 and i386. By experience, I doubt it will create any regression. I see, thank you! opendht 2.1.10 [0] has just been released including the proposed change. :-) [0]: https://github.com/savoirfairelinux/opendht/releases/tag/2.1.10 Alexandre, let's bump Debian's opendht and upload it to unstable. > Aurelien Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#978540: RFS: ancient/1.0-1 [ITP] -- decompression routines for ancient formats
On 29.12.2020 21:47, Adam Borowski wrote: On Mon, Dec 28, 2020 at 01:56:23PM +0100, Gürkan Myczko wrote: * Package name: ancient Version : 1.0-1 * URL : https://github.com/temisu/ancient Hi Adam, ancient (1.0-1) unstable; urgency=medium . * Initial release. (Closes: #978090) The copyright file lacks at least bzip2 license for src/BZIP2Table.hpp Added the licensecheck to my pipeline: https://github.com/alexmyczko/autoexec.bat/blob/master/Documents/debian-packaging.md and fixed it in the new upload to mentors.debian.net For a command-line program, I'd say a man page is a must. True that, fixed as well. Meow!
Bug#978437: geoclue-2.0: regression in 2.5.7-1, no geolocation returned
On Sun, 27 Dec 2020 16:41:54 +0100, Laurent Bigonville wrote: > > And that's it. So "something" (with system apps? or accuracy level? > > or something else?) changed which breaks how at least for me geoclue > > has worked for a couple of years. > I reintroduced a delay where the geoclue daemon will wait for the agent to > appear on the Bus if the daemon is D-Bus activated. The timeout is "dumb" > and will always wait 20s even if the agent appears earlier. The timeout for > the client should be 30s. > Can you try to start (systemctl start geoclue) the daemon before running > "where-am-i" so the agent will be connected before the 1st location request > comes in? Not easily in this way, as I don't have systemctl/systemd on this machine. (Apart from manual invocation like `G_MESSAGES_DEBUG=all runuser -u geoclue -- /usr/libexec/geoclue', I've written a quick init script; attached, in case it's of interest for others.) > If the problem was the accuracy, the client would get an AccessDenied or > something like that. Right. > I just retried again in my GNOME session (so gnome-shell is acting as the > agent) and with the demo agent in a terminal and both are working fine, so > I'm not too sure what's happening... One additional observation: With 2.5.6-1, I can * start with no geoclue-daemon and no demo-agent running * call where-am-i (or redshift -p) * and get a result (plus a running daemon) > Can you try to modify the geoclue.service file and add > Environment=G_MESSAGES_DEBUG=all to the [Service] section (and then run > systemctl daemon-reload)? That should increase the logs of the daemon Ok, so let's try again: - Upgrade the geoclue packages to 2.5.7-1. - Accept the new config (plus the redshift stanza). - Make sure no geoclue-daemon, geoclue-agent, or redshift is running. - Start the daemon. Output at this time: (geoclue:22572): Geoclue-DEBUG: 16:10:25.084: Failed to get config "wifi/url": Key file does not have key “url” in group “wifi” (geoclue:22572): Geoclue-DEBUG: 16:10:25.084: Failed to get config "wifi/submission-url": Key file does not have key “submission-url” in group “wifi” (geoclue:22572): GLib-GIO-DEBUG: 16:10:25.095: Failed to initialize portal (GNetworkMonitorPortal) for gio-network-monitor: Not using portals (geoclue:22572): GLib-GIO-DEBUG: 16:10:25.096: Failed to initialize networkmanager (GNetworkMonitorNM) for gio-network-monitor: NetworkManager not running (geoclue:22572): GLib-GIO-DEBUG: 16:10:25.096: _g_io_module_get_default: Found default implementation netlink (GNetworkMonitorNetlink) for ‘gio-network-monitor’ (geoclue:22572): Geoclue-DEBUG: 16:10:25.097: Available accuracy level from GClueWifi: 4 (geoclue:22572): Geoclue-WARNING **: 16:10:25.107: Failed to connect to avahi service: Daemon not running - Check that the daemon is running, wait a minute or three. - Start demo-agent. - Meanwhile the daemon said: Geoclue-Message: 16:11:25.043: Service not used for 60 seconds. Shutting down.. (geoclue:22572): Geoclue-DEBUG: 16:11:25.043: GClueWifi already inactive, not stopping. (geoclue:22572): Geoclue-DEBUG: 16:11:25.044: GClue3G already inactive, not stopping. (geoclue:22572): Geoclue-DEBUG: 16:11:25.044: GClueCDMA already inactive, not stopping. (geoclue:22572): Geoclue-DEBUG: 16:11:25.044: GClueModemGPS already inactive, not stopping. (geoclue:22572): Geoclue-DEBUG: 16:11:25.044: GClueNMEASource already inactive, not stopping. (geoclue:22572): Geoclue-DEBUG: 16:11:25.044: GClueLocator already inactive, not stopping. - And no more daemon in the process list, now just the demo-agent is running. - Kill demo-agent. - Start the daemon (same output as before). - Start the demo-agent 45 seconds later. - daemon says: (geoclue:31245): Geoclue-DEBUG: 16:17:48.887: New agent for user ID '1000' - and then: Geoclue-Message: 16:18:00.043: Service not used for 60 seconds. Shutting down.. (geoclue:31245): Geoclue-DEBUG: 16:18:00.044: GClueWifi already inactive, not stopping. (geoclue:31245): Geoclue-DEBUG: 16:18:00.044: GClue3G already inactive, not stopping. (geoclue:31245): Geoclue-DEBUG: 16:18:00.044: GClueCDMA already inactive, not stopping. (geoclue:31245): Geoclue-DEBUG: 16:18:00.044: GClueModemGPS already inactive, not stopping. (geoclue:31245): Geoclue-DEBUG: 16:18:00.045: GClueNMEASource already inactive, not stopping. (geoclue:31245): Geoclue-DEBUG: 16:18:00.045: GClueLocator already inactive, not stopping. - At this point (the agent is still running but) the daemon process stopped. - Next try: Start daemon, sleep 45 seconds, run where-am-i (with no agent before). - After the 45 seconds the daemon says: (geoclue:5241): Geoclue-DEBUG: 16:22:31.260: Service now in use (geoclue:5241): Geoclue-DEBUG: 16:22:31.260: Number of connected clients: 1 (geoclue:5241): Geoclue-DEBUG: 16:22:31.263: 'geoclue-where-am-i' not in configuration (geoclue:5241): Geoclue-DEBUG: 16:22:36.040: Client `:1.232` vanished. Dropping associated client objects
Bug#978710: RM: python3.8, superseded by python3.9
Package: ftp.debian.org Please remove python3.8, superseded by python3.9, and not a supported python3 version anymore.
Bug#978681: Ignore my previous message, sent by mistake
Hi, Please ignore my previous message, was sent by mistake. Apologies for the spam. Regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#978708: (no subject)
tags -1 +pending thanks -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#947272: blt builds fine with gcc-10
Hi Holger, On Wed, Dec 30, 2020 at 6:26 PM Holger Levsen wrote: > > Hi Sergei, > > On Wed, Dec 30, 2020 at 05:26:53PM +0300, Sergei Golovan wrote: > > This bug is actually about blt 2.5.3+dfsg-5 and failure to build with > > Tcl/Tk 8.7. So the serious severity is justified. The bug title is > > misleading though, so I'm changing it. Sorry for not doing it sooner. > > ah, cool! > > now I just wonder why it still builds in unstable? There isn't Tcl/Tk 8.7 in unstable yet, only an alpha in experimantal. After the Tcl/Tk 8.7 will be released, I'll deal with this bug in unstable. -- Sergei Golovan
Bug#978708: (no subject)
tags -1 +pending thanks -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#947272: blt builds fine with gcc-10
Hi Sergei, On Wed, Dec 30, 2020 at 05:26:53PM +0300, Sergei Golovan wrote: > This bug is actually about blt 2.5.3+dfsg-5 and failure to build with > Tcl/Tk 8.7. So the serious severity is justified. The bug title is > misleading though, so I'm changing it. Sorry for not doing it sooner. ah, cool! now I just wonder why it still builds in unstable? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ Never waste a crisis. signature.asc Description: PGP signature
