Bug#916746: powerpc-utils 1.3.6 is out
Source: powerpc-utils Version: 1.3.2-1 User: debian-powe...@lists.debian.org Usertags: ppc64 powerpc ppc64el Release 1.3.6 is out. Please package it. Let me know if you need help with updating the package. Thanks
Bug#916306: gitlab: Error during gitlab installation
On 12/18/18 12:20 PM, Pranith Kumar wrote: > OK, made some more progress after removing the local bundler. Now I am > getting the following error: > > Setting up gitlab (11.5.4+dfsg-1) ... > > We trust you have received the usual lecture from the local System > Administrator. It usually boils down to these three things: > > #1) Respect the privacy of others. > #2) Think before you type. > #3) With great power comes great responsibility. > > > > Your user account isn't allowed to install to the system RubyGems. > You can cancel this installation and run: > > bundle install --path vendor/bundle > > to install the gems into ./vendor/bundle/, or you can enter your password > and install the bundled gems to RubyGems using sudo. > > Password: > > > However, no matter what password I enter (tried both su and sudo > password), I am not able to proceed. > > Thanks, I think it is trying to use the previous bundler configuration. Try purging gitlab and reinstall (make sure /var/lib/gitlab and /usr/share/gitlab* are really removed). signature.asc Description: OpenPGP digital signature
Bug#916745: web2py2po and po2web2py fail to work ("convertpy() got an unexpected keyword argument 'duplicatestyle'" and "'ascii' codec can't encode character")
Package: python-translate Version: 2.0.0-1 Severity: important Forwarded: https://github.com/translate/translate/issues/3254 When trying to use web2py2po and po2web2py with the translations in https://github.com/OneZoom/OZtree >, the tools fail to work. First, trying to create a po file fail like this: % web2py2po languages/it.py languages/it-new.po processing 1 files... web2py2po: WARNING: Error processing: input languages/it.py, output languages/it-new.po, template None: convertpy() got an unexpected keyword argument 'duplicatestyle' [###] 100% % Next, after using my own tool to convert from .py to .py, converting back to py also fail like this: % po2web2py languages/it.po languages/it.py processing 1 files... po2web2py: WARNING: Error processing: input languages/it.po, output languages/it.py, template None: 'ascii' codec can't encode character u'\xf9' in position 34: ordinal not in range(128) [###] 100% % Is the web2py handling completely broken? I suspect this is the same as https://github.com/translate/translate/issues/3254 . -- Happy hacking Petter Reinholdtsen
Bug#916744: transition: pcl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to transition the new PCL to unstable. Ben only lists python-pcl, which I tested already and will upload a fixed version manually. But also there is ros-pcl-conversions build depending and integrating it. It compiles with the new version and I will request a binNMU for it. Cheers Jochen Ben file: title = "pcl"; is_affected = .depends ~ /\b(libpcl\-apps1\.8|libpcl\-common1\.8|libpcl\-features1\.8|libpcl\-filters1\.8|libpcl\-io1\.8|libpcl\-kdtree1\.8|libpcl\-keypoints1\.8|libpcl\-ml1\.8|libpcl\-octree1\.8|libpcl\-outofcore1\.8|libpcl\-people1\.8|libpcl\-recognition1\.8|libpcl\-registration1\.8|libpcl\-sample\-consensus1\.8|libpcl\-search1\.8|libpcl\-segmentation1\.8|libpcl\-stereo1\.8|libpcl\-surface1\.8|libpcl\-tracking1\.8|libpcl\-visualization1\.8)\b/ | .depends ~ "\b(libpcl\-apps1\.9|libpcl\-common1\.9|libpcl\-features1\.9|libpcl\-filters1\.9|libpcl\-io1\.9|libpcl\-kdtree1\.9|libpcl\-keypoints1\.9|libpcl\-ml1\.9|libpcl\-octree1\.9|libpcl\-outofcore1\.9|libpcl\-people1\.9|libpcl\-recognition1\.9|libpcl\-registration1\.9|libpcl\-sample\-consensus1\.9|libpcl\-search1\.9|libpcl\-segmentation1\.9|libpcl\-stereo1\.9|libpcl\-surface1\.9|libpcl\-tracking1\.9|libpcl\-visualization1\.9)\b/"; is_good = .depends ~ "\b(libpcl\-apps1\.9|libpcl\-common1\.9|libpcl\-features1\.9|libpcl\-filters1\.9|libpcl\-io1\.9|libpcl\-kdtree1\.9|libpcl\-keypoints1\.9|libpcl\-ml1\.9|libpcl\-octree1\.9|libpcl\-outofcore1\.9|libpcl\-people1\.9|libpcl\-recognition1\.9|libpcl\-registration1\.9|libpcl\-sample\-consensus1\.9|libpcl\-search1\.9|libpcl\-segmentation1\.9|libpcl\-stereo1\.9|libpcl\-surface1\.9|libpcl\-tracking1\.9|libpcl\-visualization1\.9)\b/"; is_bad = .depends ~ /\b(libpcl\-apps1\.8|libpcl\-common1\.8|libpcl\-features1\.8|libpcl\-filters1\.8|libpcl\-io1\.8|libpcl\-kdtree1\.8|libpcl\-keypoints1\.8|libpcl\-ml1\.8|libpcl\-octree1\.8|libpcl\-outofcore1\.8|libpcl\-people1\.8|libpcl\-recognition1\.8|libpcl\-registration1\.8|libpcl\-sample\-consensus1\.8|libpcl\-search1\.8|libpcl\-segmentation1\.8|libpcl\-stereo1\.8|libpcl\-surface1\.8|libpcl\-tracking1\.8|libpcl\-visualization1\.8)\b/; -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.18.0-1-armmp (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#779845: cron: Clarify warning about @reboot
Instead of showing a warning about the bug, cron should be fixed. Just add a dependency to the most important directory services (ldap, nis, whatever), making sure that cron is started *after* the directory services. Or simply start cron daemon last at boot time. Regards Harri
Bug#916306: gitlab: Error during gitlab installation
OK, made some more progress after removing the local bundler. Now I am getting the following error: Setting up gitlab (11.5.4+dfsg-1) ... We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. Your user account isn't allowed to install to the system RubyGems. You can cancel this installation and run: bundle install --path vendor/bundle to install the gems into ./vendor/bundle/, or you can enter your password and install the bundled gems to RubyGems using sudo. Password: However, no matter what password I enter (tried both su and sudo password), I am not able to proceed. Thanks, On Mon, Dec 17, 2018 at 10:41 PM Pirate Praveen wrote: > > On 12/18/18 12:07 PM, Pranith Kumar wrote: > > Thanks for the pointer. > > > > I renamed /var/lib/gems and when I run dpkg configure, I get: > > > > Setting up gitlab (11.5.4+dfsg-1) ... > > Traceback (most recent call last): > > 1: from /usr/local/bin/bundle:23:in `' > > :23:in `load': cannot load such file -- > > /usr/share/rubygems-integration/all/gems/bundler-1.16.1/exe/bundle > > (LoadError) > > dpkg: error processing package gitlab (--configure): > > installed gitlab package post-installation script subprocess returned > > error exit status 1 > > Errors were encountered while processing: > > gitlab > > > > Any idea what this error is? > > You are still using a gem installed bundler. It is trying to use bundle > from system path and finding /usr/local/bin/bundle. You should remove > it. I'm not sure if we should call /usr/bin/bundle from postinst to > avoid situations like this. > -- Pranith
Bug#882640: Uploaded dm-zoned-tools package
I saw your talk where you asked for a packaging of the dmzadm tool. I am not a debian developer but am aiming to try and become one. Anyway I created a debian package (using deb_make) and built it and uploaded it to my debian mentor account https://mentors.debian.net/packages/uploader/amworsley%40gmail.com So if you are still interested please check out the package and sponsor it. It hasn't turned up yet - it should be called dm-zoned-tools_1.0.1-6 (The .5 was missing the original source package) and I didn't upload earlier ones. This was the output from dput - showing it uploading. Andrew dput mentors dm-zoned-tools_1.0.1-6_amd64.changes Checking signature on .changes gpg: /home/amw/src/dm-zoned-tools_1.0.1-6_amd64.changes: Valid signature from D96454E2B3CB734E Checking signature on .dsc gpg: /home/amw/src/dm-zoned-tools_1.0.1-6.dsc: Valid signature from D96454E2B3CB734E Uploading to mentors (via ftp to mentors.debian.net): Uploading dm-zoned-tools_1.0.1-6.dsc: done. Uploading dm-zoned-tools_1.0.1.orig.tar.xz: done. Uploading dm-zoned-tools_1.0.1-6.debian.tar.xz: done. Uploading dm-zoned-tools-dbgsym_1.0.1-6_amd64.deb: done. Uploading dm-zoned-tools_1.0.1-6_amd64.buildinfo: done. Uploading dm-zoned-tools_1.0.1-6_amd64.deb: done. Uploading dm-zoned-tools_1.0.1-6_amd64.changes: done. Successfully uploaded packages.
Bug#916743: update bootchart2 to 0.14.8
Package: bootchart2 Version: 0.14.4-3+b1 Severity: normal Dear Maintainer, Please update bootchart2 to 0.14.8 which upstream released at least 3 years back. https://github.com/xrmx/bootchart/archive/0.14.8.tar.gz -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bootchart2 depends on: ii libc6 2.28-2 ii lsb-base 10.2018112800 Versions of packages bootchart2 recommends: ii pybootchartgui 0.14.4-3 bootchart2 suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#789008: At least on Debian testing it upgraded without an issue.
Dear all, At least here it updated without any issues - $ sudo aptitude install insserv -y The following packages will be upgraded: insserv 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/64.7 kB of archives. After unpacking 8,192 B will be used. Retrieving bug reports... Done Parsing Found/Fixed information... Done grave bugs of insserv (1.14.0-5.4+b1 → 1.18.0-1) b1 - #738775 - insserv: Insserv 1.16 tries to connect to systemd even though system is running on sysv-init Merged with: 740459 741705 b2 - #746170 - insserv: Still fails due to rpcbind/nfs Merged with: 789008 Summary: insserv(2 bugs) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] y apt-listchanges: Mailing root: apt-listchanges: changelogs for debian (Reading database ... 513126 files and directories currently installed.) Preparing to unpack .../insserv_1.18.0-1_amd64.deb ... Unpacking insserv (1.18.0-1) over (1.14.0-5.4+b1) ... Processing triggers for man-db (2.8.4-3) ... Setting up insserv (1.18.0-1) ... == How can you help? (doc: https://wiki.debian.org/how-can-i-help ) == - Show old opportunities as well as new ones: how-can-i-help --old - Scanning processes... Scanning processor microcode... Scanning linux images... Running kernel seems to be up-to-date. The processor microcode seems to be up-to-date. No services need to be restarted. No containers need to be restarted. No user sessions are running outdated binaries. Package: insserv Version: 1.18.0-1 Severity: normal -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages insserv depends on: ii libc6 2.28-2 insserv recommends no packages. Versions of packages insserv suggests: ii bootchart2 0.14.4-3+b1 -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#916306: gitlab: Error during gitlab installation
On 12/18/18 12:07 PM, Pranith Kumar wrote: > Thanks for the pointer. > > I renamed /var/lib/gems and when I run dpkg configure, I get: > > Setting up gitlab (11.5.4+dfsg-1) ... > Traceback (most recent call last): > 1: from /usr/local/bin/bundle:23:in `' > :23:in `load': cannot load such file -- > /usr/share/rubygems-integration/all/gems/bundler-1.16.1/exe/bundle > (LoadError) > dpkg: error processing package gitlab (--configure): > installed gitlab package post-installation script subprocess returned > error exit status 1 > Errors were encountered while processing: > gitlab > > Any idea what this error is? You are still using a gem installed bundler. It is trying to use bundle from system path and finding /usr/local/bin/bundle. You should remove it. I'm not sure if we should call /usr/bin/bundle from postinst to avoid situations like this. signature.asc Description: OpenPGP digital signature
Bug#916742: ITP: golang-github-namsral-flag -- Parse flags, environment variables and config files
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-namsral-flag Version : 1.7.4~alpha+git20170814.67f268f-1 Upstream Author : Lars Wiegman * URL : https://github.com/namsral/flag * License : BSD-3-clause Programming Lang: Go Description : Parse flags, environment variables and config files Flag is a drop in replacement for Go's flag package with the addition to parse files and environment variables. If you support the twelve-factor app methodology (http://12factor.net), Flag complies with the third factor; "Store config in the environment". This package is a build dependency of gitlab-pages. signature.asc Description: OpenPGP digital signature
Bug#916306: gitlab: Error during gitlab installation
Thanks for the pointer. I renamed /var/lib/gems and when I run dpkg configure, I get: Setting up gitlab (11.5.4+dfsg-1) ... Traceback (most recent call last): 1: from /usr/local/bin/bundle:23:in `' /usr/local/bin/bundle:23:in `load': cannot load such file -- /usr/share/rubygems-integration/all/gems/bundler-1.16.1/exe/bundle (LoadError) dpkg: error processing package gitlab (--configure): installed gitlab package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: gitlab Any idea what this error is? On Mon, Dec 17, 2018 at 9:32 PM Pirate Praveen wrote: > > > > On 2018, ഡിസംബർ 18 4:01:01 AM IST, Pranith Kumar > wrote: > >After starting nginx manually, the gems issue seems to be back again. > >Any idea on how to clean up gems and let the installation proceed? > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915053#67 > > > It is not a good idea to mix gems from rubygems.org and Debian. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Pranith
Bug#916376: gfortran-8-* has bad provides
Hi Matthias, On Tue, Dec 18, 2018 at 02:32:16AM +0100, Matthias Klose wrote: > doesn't this approach of dropping the provides only defers the problem? You > will > see that again when cross building packages. So it looks to me that you want > to > include in the multiarch id into these provides. My approach certainly defers the problem. For a number of other tools, what you propose is what happens indeed. I considered that option, but figured that it was not worth the effort: Nobody uses the suffixed names (as nothing provides them) and once the -for-host packages are there, they can provide these packages. On the other hand, these provides are wrong and they make diagnosing installation failures unnecessarily hard. Therefore removing them looks like an incremental step to me. As you point out, readding them later will likely be needed. > Please make sure that renaming the gfortran-mod-15 provides is coordinates > with > the people caring about gfortran (Debian Science, Alistair?). I'm still hoping that there is will be no need to rename. Helmut
Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn
[ Scott Kitterman] > The appstream-metadata-missing-modalias-provide relates to a nice to have > feature. Lintian treating this at a "Warning" level seems excessive for > something that's completely optional. Info seems right. The modalias appstream metadata provide a mechanism for users to locate the packages they need or want for their hardware. It can be compared to the package description used by 'apt search' and the file lists handled by 'apt-file search'. For this to work well, the appstream modalias data set need to be up to date, complete and correct. This make me conclude that 'warning' is the correct level for the lintian check. -- Happy hacking Petter Reinholdtsen
Bug#916345: libmodbus: FTBFS on mips, s390x: test failure
Hi, Ivo De Decker 於 2018年12月13日 週四 下午8:03寫道: > > package: src:libmodbus > version: 3.1.4-1 > severity: serious > tags: ftbfs > > Hi, > > The latest version of libmodbus in unstable fails on mips, s390x: > > https://buildd.debian.org/status/package.php?p=libmodbus > > The failure happens in the testsuite. > > Based on the failing architectures, it might be an endianess issue. I've reproduced this issue with MIPS architecture. === TEST FLOATS 1/4 Set/get float ABCD: Line 289: assertion error for 'equal_dword(tab_rp_registers, UT_IREAL_ABCD)': FAILED Set float ABCD ** === According to above information, it might be a float endianess issue and there is a potential fix for it [1]. I will continually squeeze my time to track this issue. Any feedback is welcome. [1] https://github.com/stephane/libmodbus/issues/358 SZ > > > Also, please note this error: > > ./unit-tests.sh: 17: ./unit-tests.sh: killall: not found > > This doesn't happen for the builds that succeed. I guess the killall is done > when the tests fail. This means a dependency on psmisc is missing. Now fixed, thanks, SZ > > Thanks, > > Ivo
Bug#916741: Fwd: Debian distcc
-- Forwarded message - From: Daniel Hartwig Date: Sat, 15 Dec 2018 at 15:51 Subject: Re: Debian distcc To: Adam Baxter No, I am not. On Sat, 15 Dec 2018, 12:42 Adam Baxter Hi Daniel, > Just reaching out as part of the MIA process for Debian - distcc has a > number of problems and hasn't been updated in Debian for a while. > > Could you please reply to this email if you're still around and working on > things? > > Regards, > Adam >
Bug#916306: gitlab: Error during gitlab installation
On 2018, ഡിസംബർ 18 4:01:01 AM IST, Pranith Kumar wrote: >After starting nginx manually, the gems issue seems to be back again. >Any idea on how to clean up gems and let the installation proceed? See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915053#67 It is not a good idea to mix gems from rubygems.org and Debian. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#916741: O: distcc -- simple distributed compiler client and server
Package: wnpp Severity: normal The maintainer has indicated they are no longer maintaining this. I will attempt to forward an email chain about this soon. The package description is: distcc is a program to distribute compilation of C or C++ code across several machines on a network. distcc should always generate the same results as a local compile, is simple to install and use, and is often significantly faster than a local compile. distcc does not require all machines to share a filesystem, have synchronized clocks, or to have the same libraries or header files installed.
Bug#916740: estscan: FTBFS with ld --as-needed
Package: estscan Version: 3.0.3-2 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco ubuntu-patch Dear Maintainer, estscan fails to build from source with ld --as-needed, which is enabled by default in Ubuntu. This linker options requires that libraries be placed after the objects they require. In Ubuntu, the attached patch was applied to achieve the following: * d/p/ld-as-needed.patch: Add -lm to LDLIBS instead of LDFLAGS to fix FTBFS with ld --as-needed. Thanks for considering the patch. Logan Rosen -- System Information: Debian Release: buster/sid APT prefers cosmic-updates APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-12-generic (SMP w/8 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 diff -Nru estscan-3.0.3/debian/patches/ld-as-needed.patch estscan-3.0.3/debian/patches/ld-as-needed.patch --- estscan-3.0.3/debian/patches/ld-as-needed.patch 1969-12-31 19:00:00.0 -0500 +++ estscan-3.0.3/debian/patches/ld-as-needed.patch 2018-12-17 23:08:47.0 -0500 @@ -0,0 +1,32 @@ +--- a/Makefile b/Makefile +@@ -5,7 +5,7 @@ + CFLAGS = -O2 -g + F77 = gfortran + FFLAGS = -O2 -g +- LDFLAGS = -lm ++ LDLIBS = -lm + + # Linux with Intel compilers: + # CC = icc +@@ -21,16 +21,16 @@ + \rm -f *~ $(PROGS) *.o + + maskred: maskred.o +- $(CC) $(LDFLAGS) -o $@ $< ++ $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) + + makesmat: makesmat.o +- $(CC) $(LDFLAGS) -o $@ $< ++ $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) + + estscan: estscan.o +- $(CC) $(LDFLAGS) -o $@ $< ++ $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) + + winsegshuffle: winsegshuffle.o +- $(F77) $(LDFLAGS) -o $@ $< ++ $(F77) $(LDFLAGS) -o $@ $< $(LDLIBS) + + .c.o: + $(CC) $(CFLAGS) -c $< diff -Nru estscan-3.0.3/debian/patches/series estscan-3.0.3/debian/patches/series --- estscan-3.0.3/debian/patches/series 2018-05-31 18:23:37.0 -0400 +++ estscan-3.0.3/debian/patches/series 2018-12-17 23:07:31.0 -0500 @@ -1 +1,2 @@ Makfile.patch +ld-as-needed.patch
Bug#914087: fixed in e2fsprogs 1.44.5-1
On Sun, Dec 16, 2018 at 10:35:55AM +, Simon McVittie wrote: > >* Fix mk_cmds so it works on a usrmerge system when e2fsprogs is built > > on a non-usrmerge system (Closes: #914087) > > In the interests of avoiding inaccurate information, this bug was actually > the other way round: the previous e2fsprogs version didn't work on a > non-usrmerge system if built on a usrmerge system. Oops, thanks for the correction. I'll adjust the debian changelog so it will be correct in future releases. - Ted
Bug#916536: squid FTCBFS: multiple reasons
On 17/12/18 10:39 pm, Helmut Grohne wrote: > Hi, > > On Mon, Dec 17, 2018 at 09:05:56PM +1300, Amos Jeffries wrote: >> These GCC|Clang versioned depends are to fix backport and custom build >> FTBFS. >> >> We still have quite a number of people using self-compiled Squid in >> order to gain the TLS interception features from OpenSSL. Those tend to >> be squid-4 packages on older Debian and Ubuntu machinery where GCC >> version still matters. > > Thank you for the explanation. > >> So while I would love to have fully working cross-build support the >> trade-off with lost users is not really worth it until Debian and >> derivative LTS versions move on from the outdated GCC-4.x compilers. > > This is a trade-off for sure and your reasoning makes very much sense to > me. In that case, could we annotate the dependencies with and > add a little comment to debian/control explaining them? The > will mean "this dependency is only relevant whenever you are not cross > compiling". Ah, I was not aware of that being a possibility and am not seeing anything like this (or how to add comments) in the policy manual section 7 syntax. Could you supply a patch with those changes for me to test? Amos
Bug#916739: further information on my bug report.
Dear Maintainer, I got the copy of my bug report and pushed on my link to the asus-page and everything is working after I selected the operating system What's the matter? Ok, then let us start two points earlier, URL: https://www.asus.com/us/support/ -push "Enter Download Center" under Drivers and Manuals new page --- - enter the model name on the left side of the page: Prime Z270-P, then - push on the right side Driver & Tools --- new page select OS (operating system) on the right side: e.g. Windows 10 64-bit waiting... and nothing happens OK, this is the bug! Now you can see the bug! Nothing happens, Yours sincerelly Peter
Bug#909550: possible conflict over the /usr/bin/ia namespace
On 15/12/2018 08:41, Chris Lamb wrote: > [Adding ftpmas...@debian.org to CC] > > Hi Antoine et al., > >> So anyways - irl will upload a new package now, presumably -2 or more, >> so i think << 0.242+git20151019-2~ is fine. > > I just went to process this package in NEW but this new upload does > not appear to have happened yet. Is that correct? > https://packages.qa.debian.org/p/python-duckduckgo2/news/20180925T145048Z.html Thanks, Iain. signature.asc Description: OpenPGP digital signature
Bug#916739: firefox-esr: firefox-esr 60.4.0esr on debian, stretch, stable, 9. www.asus.com page don't work!
Package: firefox-esr Version: 60.4.0esr-1~deb9u1 Severity: important Dear Maintainer, I tried to download some drivers for my motherboard on this side: https://www.asus.com/us/Motherboards/PRIME-Z270-P/HelpDesk_Download/ Driver & Tools You have to select at first the OS (operating system, e.g. Windows 10 64-bit) and then you should see the drivers which are possible to download ... but nothing happens If you do the same with google-chrome-stable 71.0.3578.98-1 (debian-paket) (web browser from Google) you can see a lot of drivers which you can download! This is really a important bug which should be correct as fast as possible! I use normally firefox for odering all my books and other computer parts and if some inputs are not working this is really a bad situation for all users! Please find this error and correct it. Thank you very much. Yours sincerelly Peter -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox-esr depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libasound21.1.3-5 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libjsoncpp1 1.7.4-3 ii libpango-1.0-01.40.5-1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libx11-6 2:1.6.4-3+deb9u1 ii libx11-xcb1 2:1.6.4-3+deb9u1 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.12-3+deb9u1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages firefox-esr recommends: ii libavcodec57 7:3.2.12-1~deb9u1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-3 ii fonts-stix [otf-stix] 1.1.1-4 ii libcanberra0 0.30-3 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libgtk2.0-02.24.31-2 ii pulseaudio 10.0-1+deb9u1 -- no debconf information
Bug#916738: nvidia-alternative: Depends on a non-existent version of glx-alternative which breaks upgrade path.
Package: nvidia-alternative Version: 410.78-2 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Attempted to upgrade from buster/sid nvidia driver 390.87 to experimental version 410.78-2 * What exactly did you do (or not do) that was effective (or ineffective)? Attempted to upgrade via version number and aptitude dependency management. * What was the outcome of this action? All attempts failed due to circular dependencies which centred around a non- existent version required for glx-alternative. * What outcome did you expect instead? Normal upgrade. -- Package-specific info: uname -a: Linux marvin 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64 GNU/Linux /proc/version: Linux version 4.18.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-30)) #1 SMP Debian 4.18.20-2 (2018-11-23) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.87 Tue Aug 21 12:33:05 PDT 2018 GCC version: gcc version 7.4.0 (Debian 7.4.0-1) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:11bf] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Dec 18 09:09 /dev/dri/card0 crw-rw+ 1 root video 226, 128 Dec 18 09:09 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 Dec 18 09:10 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 Dec 18 09:10 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Dec 18 09:10 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Dec 18 09:09 pci-:01:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Dec 18 09:09 pci-:01:00.0-render -> ../renderD128 video:x:44:ewe2 OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Dec 18 08:30 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 49 Dec 18 08:21 /etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so lrwxrwxrwx 1 root root 42 Dec 18 08:30 /etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 44 Dec 18 08:30 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 48 Dec 18 08:21 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 48 Dec 18 08:21 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 41 Dec 18 08:30 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Dec 18 08:30 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Dec 18 08:30 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Dec 18 08:30 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 55 Dec 18 08:21 /etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so lrwxrwxrwx 1 root root 55 Dec 18 08:21 /etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so lrwxrwxrwx 1 root root 55 Dec 18 08:30 /etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root 55 Dec 18 08:30 /etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root 57 Dec 18 08:30 /etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root 57 Dec 18 08:30 /etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root 52 Dec 18 08:21 /etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so lrwxrwxrwx 1 root root 52 Dec 18 08:21 /etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so lrwxrwxrwx 1 root root 52 Dec 18 08:30 /etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 52 Dec 18 08:30 /etc/alter
Bug#916716: live-wrapper: Replace vmdebootstrap usage with alternative
These are the two choices. Which is better suited and has the dependencies least conflicting? Is it possible to rewrite the packages spoken of above in Python3? Package: debootstrap (1.0.111) debootstrap is used to create a Debian base system from scratch, without requiring the availability of dpkg or apt. It does this by downloading .deb files from a mirror site, and carefully unpacking them into a directory which can eventually be chrooted into. Package: cdebootstrap (0.7.7 and others) cdebootstrap generates systems from scratch for Debian and derivates. This is implementation is different from debootstrap. It features a different package selection. The package selection is done according to the flavour. -- Rick rainbowsolutions.tech
Bug#916376: gfortran-8-* has bad provides
On 13.12.18 20:14, Helmut Grohne wrote: > Source: gcc-8 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > Control: affetcs -1 + src:gcc-8-cross src:gcc-8-cross-ports > > gfortran-8- presently Provides: gfortran-mod-15 and given > that gfortran-8- is Multi-Arch: foreign, this is provided > for any architecture. libopenmpi-dev Depends: gfortran-8 | > gfortran-mod-15. Therefore gfortran-8- satisfies > libopenmpi-dev's dependency. That's not what we want here though. The > dependency should only be satisfied by a compiler that matches > libopenmpi-dev's architecture. Therefore these provides are bad. They > result in strange solutions which are found by dose-builddebcheck, but > are not by apt. > > I propose simply removing these provides for the cross tools. The > attached patch implements that. doesn't this approach of dropping the provides only defers the problem? You will see that again when cross building packages. So it looks to me that you want to include in the multiarch id into these provides. Please make sure that renaming the gfortran-mod-15 provides is coordinates with the people caring about gfortran (Debian Science, Alistair?).
Bug#915354: RFA: sent -- simple plaintext presentation tool
Control: retitle -1 ITA: sent -- simple plaintext presentation tool Control: owner -1 emmanuelaria...@gmail.com Hello Dmitry!, I would like adopt this package. Cheers! -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Bug#916737: bcron: fails to install: installed bcron package post-installation script subprocess returned error exit status 1
Package: bcron Version: 0.11-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Selecting previously unselected package bcron. (Reading database ... (Reading database ... 4540 files and directories currently installed.) Preparing to unpack .../bcron_0.11-3_amd64.deb ... Unpacking bcron (0.11-3) ... Setting up bcron (0.11-3) ... dpkg: error processing package bcron (--configure): installed bcron package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: bcron cheers, Andreas bcron_0.11-3.log.gz Description: application/gzip
Bug#916692: RFA: cuyo -- Tetris-like game
Control: retitle -1 ITA: cuyo -- Tetris-like game Control: owner -1 emmanuelaria...@gmail.com HiBernhard! I would like adopt this package. This is on salsa? Cheers! -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Bug#916689: systemd: login at console hangs after "Last login..." displayed, ssh hangs as well
Am 17.12.18 um 18:11 schrieb Raphael Manfredi: > I quickly grepped through /etc/init.d/* files (I know systemd does > not use these anymore excepted when there is no unit and it calls > some of these scripts). There are many files that set a PATH explicitly > and which starts whith /usr/local/s?bin: I was looking for an (early) boot script which tries to access/use resources from /usr/local which might be the reason for triggering a mount requestion. > Does that help? Unfortunately not. Btw, have you made sure that you do have a working network connection? What happens if you boot into emergency mode (add emergency to the kernel command line)? This will start a very minimal system without any networking or started services. Can you successfully login? What happens if you boot into rescue mode (add rescue to the kernel command line)? This will boot into a minimal system with a few services like networking.service enabled. What's the output of "ip a" in this case? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#916736: debirf: rescue could include stress-ng
Package: debirf Version: 0.38 Severity: wishlist It would be nice if the rescue image could include the stress-ng package for system load testing. (PS there is also the stressapptest package, but at brief glance stress-ng seems to have more features) (PPS the stressant package, which is built on debirf, includes stress-ng and some other good tools. that might be a reason for/against debirf doing so) Thanks, -- Matt Taggart tagg...@debian.org
Bug#915103: Apache2 HTTP/2 connection problems with Safari clients
Hi Stefan >> On 17 Dec 2018, at 22:55, Stefan Fritsch wrote: >> >> Yes, that's the problematic patch, not the fix. >> >> I have some hope that the fix for the issue is this upstream commit: >> https://svn.apache.org/viewvc?view=revision&revision=1843468 >> >> It would be nice if you could apply the attached patch to the debian source >> package, rebuild it, and check if it fixes the issue. Thanks. > > Thanks a lot for that patch. I have applied it to apache2 2.4.25-3+deb9u6, > compiled apache2 using dpkg-buildpackage, and installed apache2-bin package > on production webserver. So far no issues. > But I cannot tell you if it improved anything. The thing is, I couldn't > reproduce the previous issue under desktop Safari right before patching > Apache. I tried hard to reproduce it the same way I was able to reproduce it > on Dec 14th. I switched back the relevant sites to HTTP/2 (Protocols h2 > http/1.1) and tested in Safari checking web inspector console on a site where > previously a bunch of jpg images were not loaded at all. > So, it seems that magically, the problem went away by itself. Could the > original issue be related to any load / buffer issues on long running apache?? > I am sorry that I cannot give you any more detailed feedback. It works fine > with your patch as it did before... I need to disappoint you. I was now able to reproduce the same issue under Apache with applied patch. It was only a Safari browser caching thing why I couldn't reproduce it before. After emptying browser cache the problem occurred again. Switching back to http/1.1 resolves the issue. So it looks like your patch did not change anything here. Looking forward for your next trick! Cheers, Philip
Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn
Package: lintian Version: 2.5.117 Severity: normal The appstream-metadata-missing-modalias-provide relates to a nice to have feature. Lintian treating this at a "Warning" level seems excessive for something that's completely optional. Info seems right. Scott K
Bug#915103: Apache2 HTTP/2 connection problems with Safari clients
Hi Stefan > On 17 Dec 2018, at 22:55, Stefan Fritsch wrote: > > Yes, that's the problematic patch, not the fix. > > I have some hope that the fix for the issue is this upstream commit: > https://svn.apache.org/viewvc?view=revision&revision=1843468 > > It would be nice if you could apply the attached patch to the debian source > package, rebuild it, and check if it fixes the issue. Thanks. Thanks a lot for that patch. I have applied it to apache2 2.4.25-3+deb9u6, compiled apache2 using dpkg-buildpackage, and installed apache2-bin package on production webserver. So far no issues. But I cannot tell you if it improved anything. The thing is, I couldn't reproduce the previous issue under desktop Safari right before patching Apache. I tried hard to reproduce it the same way I was able to reproduce it on Dec 14th. I switched back the relevant sites to HTTP/2 (Protocols h2 http/1.1) and tested in Safari checking web inspector console on a site where previously a bunch of jpg images were not loaded at all. So, it seems that magically, the problem went away by itself. Could the original issue be related to any load / buffer issues on long running apache?? I am sorry that I cannot give you any more detailed feedback. It works fine with your patch as it did before... Can you explain why this issue only occurred in Safari? If I check the mod_h2 Github issues and threads referenced in upstream changelog, there is no hint about this being related to Safari: *) mod_http2: adding defensive code for stream EOS handling, in case the request handler missed to signal it the normal way (eos buckets). Addresses github issues https://github.com/icing/mod_h2/issues/164, https://github.com/icing/mod_h2/issues/167 and https://github.com/icing/mod_h2/issues/170. [Stefan Eissing] Cheers, Philip
Bug#668354: Can probably close this report
I think this report can be closed. The issue appears to be that the program in question (or the installation steps that accompany it) do not conform to Debian's policies or the insserv/startpar approach to doing things. If someone submits a patch or writes a companion tool to scan for new, unidentified init.d scripts I'll be happy to work with it, but I'm not seeing a strong case here for adjusting behaviour to deal with scripts that do not follow Debian's installation steps (ie using update-rc.d). - Jesse
Bug#916720: upgrade-reports: stretch to buster upgrade graphics fail, ok with old kernel 4.9
On Mon, 17 Dec 2018 at 22:48, Niels Thykier wrote: > Control: tags -1 moreinfo > > max: > > Package: upgrade-reports > > Severity: important > > > > Dear Maintainer, > > > > upgraded to buster via apt-get upgrade, apt-get dist-upgrade, all worked > well up to here. > > Booting gave black screen. > > Reboot with old kernel 4.9 --> all is well. > > Set system to go into multi-user (without graphics): Same effect. > > Thus it must be related to the framebuffer screen setting at boot, > rather than xserver-xorg. > > Will attach working and non-working X.org.log below > > > > Max > > > > [...] > > Hi Max, > > Could you try to see if version 4.18.0-2 of the Debian Linux kernel > works? You can install it from snapshot.debian.org. > > I have seen some reports of 4.18.0-3 being broken or causing issues with > graphics in certain circumstances (#916510, #916134, #914967) which may > be related to your issue. > > Thanks, > ~Niels > > I installed that version and everything works great! (Just like stretch did). So from my point of view this 4.18.0-3 seems to be broken while 4.18.0-2 works. Thanks for the info! I can provide more details if that would help fixing things up. Best regards, Max
Bug#916734: rarcrack has multiple potential security issues
Package: rarcrack Version: 0.2-1+b1 Severity: normal Dear Maintainer, I had a look into rarcrack: https://bierbaumer.net/security/rarcrack/. In my opinion these issues should be patched, or the package removed as the project doesn't seem to be maintained anymore. Greetings, Bruno -- System Information: Debian Release: 9.6 Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-17763-Microsoft 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: unable to detect Versions of packages rarcrack depends on: ii libc62.24-11+deb9u3 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 rarcrack recommends no packages. rarcrack suggests no packages. -- no debconf information
Bug#534713: Can probably close this
I think this bug can probably be closed. The submitter seems to think it's Upstart-related and since Upstart isn't used anymore (so far as I know) it seems safe to close this. If the problem persists using SysV init (or another init system) then the issue can be re-opened. - Jesse
Bug#916658: closed by Bart Martens (closing RFS: apt-listbugs/0.1.26)
On Mon, 17 Dec 2018 22:25:35 + Bart Martens wrote: > Package apt-listbugs version 0.1.26 is in unstable now. > https://packages.qa.debian.org/apt-listbugs Yes, I must thank Dmitry Bogatov for kindly sponsoring my upload! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpMTZqeS10gs.pgp Description: PGP signature
Bug#916733: util-linux: missing fstrim examples
Package: util-linux Version: 2.33-0.2 Severity: minor Dear Maintainer, The wiki at https://wiki.debian.org/SSDOptimization mentions a sample fstrim service definition that should be in /usr/share/doc/util-linux/examples/ I believe I've already used this tip on the current system, yet now that I wanted to use it on another system I see the examples are no longer present. Of course, I'm going to use the copy I already have but please consider re-adding the examples or revising the documentation to match the situation, in case there is a valid reason for removing the examples. -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0-rc6-18.12.13.amdgpu (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii fdisk 2.33-0.2 ii libaudit1 1:2.8.4-2 ii libblkid1 2.33-0.2 ii libc6 2.28-2 ii libcap-ng0 0.7.9-1 ii libmount1 2.33-0.2 ii libpam0g 1.1.8-3.8 ii libselinux12.8-1+b1 ii libsmartcols1 2.33-0.2 ii libsystemd0239-15 ii libtinfo6 6.1+20181013-1 ii libudev1 239-15 ii libuuid1 2.33-0.2 ii login 1:4.5-1.1 ii zlib1g 1:1.2.11.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-2 ii kbd 2.0.4-4 pn util-linux-locales -- no debconf information
Bug#916306: gitlab: Error during gitlab installation
After starting nginx manually, the gems issue seems to be back again. Any idea on how to clean up gems and let the installation proceed? Running final rake tasks and tweaks... Initializing database... rake aborted! NoMethodError: undefined method `allow_access_with_scope' for # /usr/share/gitlab/lib/gitlab/patch/draw_route.rb:30:in `instance_eval' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/api/instance.rb:88:in `instance_eval' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/api/instance.rb:88:in `block in nest' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/api/instance.rb:88:in `each' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/api/instance.rb:88:in `nest' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/dsl/routing.rb:168:in `block in namespace' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/dsl/settings.rb:158:in `within_namespace' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/dsl/routing.rb:165:in `namespace' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/api.rb:119:in `block in add_setup' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/api.rb:118:in `each' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/api.rb:118:in `add_setup' /var/lib/gems/2.5.0/gems/grape-1.2.2/lib/grape/api.rb:40:in `block (2 levels) in override_all_methods!' /usr/share/gitlab/lib/api/events.rb:46:in `' /usr/share/gitlab/lib/api/events.rb:4:in `' /usr/share/gitlab/lib/api/events.rb:3:in `' /usr/share/gitlab/lib/api/api.rb:102:in `' /usr/share/gitlab/lib/api/api.rb:4:in `' /usr/share/gitlab/lib/api/api.rb:3:in `' (eval):6:in `draw_route' /usr/share/gitlab/lib/gitlab/patch/draw_route.rb:30:in `instance_eval' /usr/share/gitlab/lib/gitlab/patch/draw_route.rb:30:in `draw_route' /usr/share/gitlab/lib/gitlab/patch/draw_route.rb:17:in `draw_ce' /usr/share/gitlab/lib/gitlab/patch/draw_route.rb:11:in `draw' /usr/share/gitlab/config/routes.rb:111:in `block in ' /usr/share/gitlab/config/routes.rb:4:in `' /usr/share/gitlab/config/application.rb:219:in `block in ' /usr/share/gitlab/config/environment.rb:11:in `' /var/lib/gems/2.5.0/gems/rake-12.3.2/exe/rake:27:in `' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/cli/exec.rb:74:in `load' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/cli/exec.rb:74:in `kernel_load' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/cli/exec.rb:28:in `run' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/cli.rb:463:in `exec' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/cli.rb:27:in `dispatch' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/cli.rb:18:in `start' /var/lib/gems/2.5.0/gems/bundler-1.17.2/exe/bundle:30:in `block in ' /var/lib/gems/2.5.0/gems/bundler-1.17.2/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors' /var/lib/gems/2.5.0/gems/bundler-1.17.2/exe/bundle:22:in `' /usr/local/bin/bundle:23:in `load' /usr/local/bin/bundle:23:in `' Tasks: TOP => db:schema:load => environment (See full trace by running task with --trace) dpkg: error processing package gitlab (--configure): installed gitlab package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: gitlab E: Sub-process /usr/bin/dpkg returned an error code (1) On Thu, Dec 13, 2018 at 11:21 PM Pirate Praveen wrote: > > > > On 2018, ഡിസംബർ 14 1:22:52 AM IST, Pranith Kumar > wrote: > >OK. I manually copied gitlab-debian.conf from /var/lib/gitlab/ to > >/etc/gitlab/ and it was overwritten during the configure step with the > >package maintainers version. It now proceeds past the previous error > >message. > > > >Now, I am seeing a new error as follows: > > > >$ sudo dpkg --configure gitlab > >Setting up gitlab (11.3.11+dfsg-1) ... > >Creating runtime directories for gitlab... > >Updating file permissions... > >Configuring hostname and email... > >Registering /usr/lib/tmpfiles.d/gitlab.conf via ucf > >/etc/systemd/system/gitlab-mailroom.service.d/override.conf already > >exist > >/etc/systemd/system/gitlab-unicorn.service.d/override.conf already > >exist > >/etc/systemd/system/gitlab-sidekiq.service.d/override.conf already > >exist > >/etc/systemd/system/gitlab-workhorse.service.d/override.conf already > >exist > >Registering /etc/gitlab-shell/config.yml via ucf > >Registering /etc/gitlab/gitlab.yml via ucf > >Registering /etc/gitlab/gitlab-debian.conf via ucf > >Reloading nginx configuration... > >nginx.service is not active, cannot reload. > >invoke-rc.d: initscript nginx, action "reload" failed. > >dpkg: error processing package gitlab (--configure): > > installed gitlab package post-installation script subprocess returned > >error exit status 1 > >Errors were encounter
Bug#888640: Patch for gcab: FTBFS on hurd-i386: PATH_MAX undeclared
The applied patch should fix the build failure of gcab by giving NULL as the second argument to realpath and thus avoiding the need to initialize a buffer of length PATH_MAX. Could you please take a look at it? The package compiles with the patch on both Linux and Hurd. Thanks, Paul Sonnenschein Index: gcab-1.2/tests/gcab-self-test.c === --- gcab-1.2.orig/tests/gcab-self-test.c +++ gcab-1.2/tests/gcab-self-test.c @@ -30,13 +30,10 @@ static gchar * gcab_test_get_filename (const gchar *filename) { gchar *tmp; -char full_tmp[PATH_MAX]; g_autofree gchar *path = NULL; path = g_build_filename (TESTDATADIR, filename, NULL); -tmp = realpath (path, full_tmp); -if (tmp != NULL) -return g_strdup (full_tmp); -return NULL; +tmp = realpath (path, NULL); +return tmp; } static void signature.asc Description: This is a digitally signed message part
Bug#851276: (no subject)
I don't really understand how that patch could fix this bug. It is adding more conditions where exit status becomes non zero, not removing them.
Bug#914194: Please test with 0.8.3
Hi Upstream believes that this may be resolved in version 0.8.3. Do you mind testing again against that version? thanks -Jonathan
Bug#911610: eldav: files missing after upgrade from stretch: /usr/share/emacs/site-lisp/eldav/{,vc-}eldav.el
Followup-For: Bug #911610 Control: found -1 10.8+0.20120427-16 I've also observed this behavior (i.e. lost files in some package, e.g. eldav) in stretch, so it's probably apel there, too. Could you backport the fix to stretch and open a stretch-pu request? If you send a patch, I can test the fixed packages in my piuparts instance in stretch. Thanks. Andreas
Bug#916732: ITP: go-exploitdb -- builds a local copy of the Exploit-DB (OffensiveSecurity)
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu * Package name: go-exploitdb Version : 0.0~git20181130.7c961e7-1 Upstream Author : mozqnet * URL : https://github.com/mozqnet/go-exploitdb * License : Expat Programming Lang: Go Description : builds a local copy of the Exploit-DB (OffensiveSecurity) go-exploitdb is a tool for searching Exploits from Exploit-DB(OffensiveSecurity) by CVE number or Exploit Database ID. Exploits are inserted at sqlite database(go-exploitdb) from Exploit-DB and can be searched by command line interface.
Bug#905790: Patch available
I had some time to check further, there is an Ubuntu patch that makes ibus-gtk rather check whether this was an upgrade or not, and only makes the message display when upgrading from a very old version with the old hotkey. Upstream has tagged this notabug in their bug tracker: https://code.google.com/archive/p/ibus/issues/1677 The Ubuntu patch can be obtained from this tarball: https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/ibus/1.5.11-1 ubuntu2.1/ibus_1.5.11-1ubuntu2.1.debian.tar.xz DSC: https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/ibus/1.5.11-1 ubuntu2.1/ibus_1.5.11-1ubuntu2.1.dsc Here is what it does: """ Description: don't show notification if not upgrading from a previous version Author: Marc Deslauriers Bug: http://code.google.com/p/ibus/issues/detail?id=1677 Bug-Ubuntu: https://bugs.launchpad.net/ibus/+bug/1255542 Forwarded: yes Index: ibus-1.5.11/ui/gtk3/panel.vala === --- ibus-1.5.11.orig/ui/gtk3/panel.vala +++ ibus-1.5.11/ui/gtk3/panel.vala @@ -753,6 +753,7 @@ class Panel : IBus.PanelService { string current_version = null; if (compare_versions(prev_version, "1.5.3") < 0) + if (prev_version != "" && compare_versions(prev_version, "1.5.3") < 0) update_version_1_5_3(); if (compare_versions(prev_version, "1.5.8") < 0) """ Please consider adding this patch in Debian too, it's a really big papercut and a deterrent to new users. Thanks!
Bug#916731: ITS: ncmpc to be salvaged by mpd team
Source: ncmpc Version: 0.27-1 Severity: important I inted to salvage ncmpc into the mpd team. Over the last four years, this package has seen one NMU and one regular upload, both introducing new upstream versions. Since then, upstream has released six new versions, fixing crashes and other bugs: https://raw.githubusercontent.com/MusicPlayerDaemon/ncmpc/v0.33/NEWS For over eight months, ncmpc has a security bug open #894724 / CVE-2018-9240. The bug reporter provided a patch for the version of ncmpc in Debian, and Upstream released a fixed version a few days later in April 2018. However there was no reaction from the package maintainer, and the version currently in unstable remains affected. In #902699 frequent segfaults are reported; the upstream author comments that the issue has already been fixed in a new upstream version; no reaction from the maintainer for over five months. None of the new bugs reports of the last 12 months has received communications from the package maintainer. An interested New Maintainer prepared a package update on salsa and tried to contact the ncmpc maintainer several times to offer help, but got no answer. In accordance with the package salvaging process as outlined in https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#idm1880, this bug is open for comments and objections for 21 days, after which I am going to do a take-over for the mpd team and upload ncmpc to DELAYED/7. Florian
Bug#916730: wuzz: Please update to 0.4.0
Package: wuzz Version: 0.3.0-1 Severity: wishlist Dear Maintainer, A new version of wuzz has been released. Could you update it? Also, golang-github-jroimartin-gocui-dev that build dependency on wuzz has been updated to 0.4.0 and uploaded to experimental. Beat regards, Nobuhiro *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wuzz depends on: ii libc6 2.28-3 wuzz recommends no packages. wuzz suggests no packages.
Bug#916729: ITS: libmpdclient to be salvaged by mpd team
Source: libmpdclient Version: 2.11-1 Severity: important I intend to salvage libmpdclient into the mpd team. The last upload of this package was 14 months ago. At the time, the release (2.11) was already 7 months old and upstream had pushed out two releases in the meantime (2.12, 2.13). Since then, three more upstream releases have been created (2.14, 2.15, 2.16), fixing bugs and supporting features added to the MPD protocol in recent years (see https://raw.githubusercontent.com/MusicPlayerDaemon/libmpdclient/v2.16/NEWS for details). Debian bug #900513 ("libmpdclient2: New version available") was opened over six months ago, but has failed to receive a reply. There is no visible activity regarding libmpdclient since the last upload in October 2017. e-mails were sent by several interested parties to the current maintainer both in private and on public mailing lists, asking for new upstream versions and explaining that a package update is needed e.g. to enable new features in packages that depend on libmpdclient, such as mpc. No reply was received, and an attempt to contact the maintainer on IRC went unanswered. In accordance with the package salvaging process as outlined in https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#idm1880, this bug is open for comments and objections for 21 days, after which I am going to do a take-over for the mpd team and upload libmpdclient to DELAYED/7. Florian
Bug#916728: pnetcdf: force gfortran link to avoid FTBFS of reverse-deps
Package: pnetcdf User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco ubuntu-patch Version: 1.10.0-1 Severity: normal Tags: patch Please, add a --no-as-needed before lgfortran link diff -Nru pnetcdf-1.10.0/debian/rules pnetcdf-1.10.0/debian/rules --- pnetcdf-1.10.0/debian/rules 2018-12-17 16:46:42.0 +0100 +++ pnetcdf-1.10.0/debian/rules 2018-12-17 17:25:24.0 +0100 @@ -13,7 +13,7 @@ DEB_CXXFLAGS_MAINT_APPEND:= -Wall -pedantic DEB_FCFLAGS_MAINT_APPEND:= -Wall -pedantic DEB_FFLAGS_MAINT_APPEND:= -Wall -pedantic -LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) -lgfortran +LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) -Wl,--no-as-needed -lgfortran -Wl,--as-needed ifeq ($(DEB_HOST_ARCH),ppc64el) export DEB_CFLAGS_MAINT_APPEND = -O2 so the linking is not stripped on systems where as-needed is the default. thanks! Gianfranco
Bug#915103: Apache2 HTTP/2 connection problems with Safari clients
Hi Philip, On Friday, 14 December 2018 22:49:13 CET Philip Iezzi wrote: > But the patch from bee2facd9343beda10677b139cd9b2e49e986f01 > (https://salsa.debian.org/apache-team/apache2/commit/bee2facd9343beda10677b > 139cd9b2e49e986f01) was already applied to latest apache2 package in Debian > 9.6 (modules/http2/h2_bucket_beam.c). How come this should fix the problem? > Or did you rather mean this patch is the source of these issues. Yes, that's the problematic patch, not the fix. I have some hope that the fix for the issue is this upstream commit: https://svn.apache.org/viewvc?view=revision&revision=1843468 It would be nice if you could apply the attached patch to the debian source package, rebuild it, and check if it fixes the issue. Thanks. Cheers, Stefan diff --git a/debian/patches/http-EOS-handling.diff b/debian/patches/http-EOS-handling.diff new file mode 100644 index 00..501ab5a7b6 --- /dev/null +++ b/debian/patches/http-EOS-handling.diff @@ -0,0 +1,26 @@ +# https://svn.apache.org/viewvc?view=revision&revision=1843468 +# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915103 +--- apache2.orig/modules/http2/h2_session.c apache2/modules/http2/h2_session.c +@@ -1094,6 +1094,10 @@ static ssize_t stream_data_cb(nghttp2_se + case APR_SUCCESS: + break; + ++case APR_EOF: ++eos = 1; ++break; ++ + case APR_ECONNRESET: + case APR_ECONNABORTED: + return NGHTTP2_ERR_CALLBACK_FAILURE; +--- apache2.orig/modules/http2/h2_stream.c apache2/modules/http2/h2_stream.c +@@ -915,7 +915,7 @@ apr_status_t h2_stream_out_prepare(h2_st + (long)*plen, *peos); + } + else { +-status = APR_EAGAIN; ++status = (stream->output && h2_beam_is_closed(stream->output))? APR_EOF : APR_EAGAIN; + ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, c, + H2_STRM_MSG(stream, "prepare, no data")); + } diff --git a/debian/patches/series b/debian/patches/series index 014d958573..93b77b7f35 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -30,3 +30,4 @@ mod_http2_mem_usage_32bit.diff fcgi_crash.diff CVE-2018-1333-mod_http2_DoS.diff CVE-2018-11763-mod_http2_DoS-SETTINGS.diff +http-EOS-handling.diff
Bug#904404: liece-dcc: fails to install with emacs25
On 2018-12-17 22:41, Tatsuya Kinoshita wrote: > On December 17, 2018 at 9:38PM +0100, anbe (at debian.org) wrote: >> 1m16.4s ERROR: FAIL: debsums reports modifications inside the chroot: >> debsums: missing file /usr/share/emacs/site-lisp/liece/bitmap-stipple.el >> (from liece package) >> debsums: missing file /usr/share/emacs/site-lisp/liece/delegate.el (from >> liece package) > > This issue is fixed in apel 10.8+0.20120427-19. Thanks for the info, rescheduling piuparts tests with smilar failures (in my local piuparts instance). Andreas
Bug#916720: upgrade-reports: stretch to buster upgrade graphics fail, ok with old kernel 4.9
Control: tags -1 moreinfo max: > Package: upgrade-reports > Severity: important > > Dear Maintainer, > > upgraded to buster via apt-get upgrade, apt-get dist-upgrade, all worked well > up to here. > Booting gave black screen. > Reboot with old kernel 4.9 --> all is well. > Set system to go into multi-user (without graphics): Same effect. > Thus it must be related to the framebuffer screen setting at boot, rather > than xserver-xorg. > Will attach working and non-working X.org.log below > > Max > > [...] Hi Max, Could you try to see if version 4.18.0-2 of the Debian Linux kernel works? You can install it from snapshot.debian.org. I have seen some reports of 4.18.0-3 being broken or causing issues with graphics in certain circumstances (#916510, #916134, #914967) which may be related to your issue. Thanks, ~Niels
Bug#904404: liece-dcc: fails to install with emacs25
Control: tags -1 + patch On December 17, 2018 at 9:38PM +0100, anbe (at debian.org) wrote: > 1m16.4s ERROR: FAIL: debsums reports modifications inside the chroot: > debsums: missing file /usr/share/emacs/site-lisp/liece/bitmap-stipple.el > (from liece package) > debsums: missing file /usr/share/emacs/site-lisp/liece/delegate.el (from > liece package) This issue is fixed in apel 10.8+0.20120427-19. On July 24, 2018 at 5:18AM +0200, anbe (at debian.org) wrote: > Loading /usr/share/emacs25/site-lisp/liece/liece-config.el (source)... > Cannot open load file: No such file or directory, install It seems apel's install.el* is not found when byte-compiling. The following patch fixes this bug. Although liece seems to fail with Emacs 26 (not yet packaged in Debian)... ``` --- a/debian/emacsen-install +++ b/debian/emacsen-install @@ -41,6 +41,7 @@ done | sort -u) if [ ${FLAVOR} = emacs ]; then exit 0; fi +if [ ! -f "/usr/share/$FLAVOR/site-lisp/apel/install.elc" ]; then exit 0; fi # Install-info-altdir does not actually exist. # Maybe somebody will write it. @@ -104,6 +105,7 @@ done cat << EOF > path.el +(setq load-path (cons "/usr/share/$FLAVOR/site-lisp/apel" load-path)) (setq load-path (cons "." load-path) byte-compile-warnings nil) EOF if test "${APPEND_LOAD_PATH}" != "" ``` Thanks, -- Tatsuya Kinoshita pgpDNPzM9G0Uj.pgp Description: PGP signature
Bug#916727: RM: xfce4-wmdock-plugin -- ROM; unmaintained upstream
Package: ftp.debian.org Severity: normal Hi FTP team, yet another removal request for a panel plugin, this time for a compatibility layer with Window Maker applets (not really sure if they still exist to be honest). Last release was in 2013 so I guess it's better to just drop it. Thanks in advance, -- Yves-Alexis
Bug#916726: RM: xfce4-hdaps -- ROM; unmaintained upstream, hardware deprecated
Package: ftp.debian.org Severity: normal Hi, xfce4-hdaps is another Xfce panel plugin unmaintained upstream. The hardware also has evolved, there is a kernel module available for newer hardware but the panel plugin is unfortunately unlikely to be ever ported. xfce4-goodies stil suggests it but that will be removed in the next upload. Thanks in advance, -- Yves-Alexis
Bug#916640: Changes to GAP necessary for sagemath
On Mon, Dec 17, 2018 at 11:06:02AM +0100, Tobias Hansen wrote: > It migrated today. Yes! > > Do you not also need some kind of symbol mangling to avoid conflicts with > > other Sage component ? > > No, sagemath removed the "libGAP_" prefixes in order to work with the > official libgap. If there were any conflicts they were resolved. Good! > > The Sage patches change the interface to the library. However it seems > > likely libgap in Debian will only be used by Sagemath in Buster, so > > maybe we could arrange for those patches to be applied only to libgap > > and not to /usr/bin/gap. However the side effect is that each time you > > will need to update those extra patches, I will need to reupload gap. > > > > So there might be benefits to have a separate source package. > > The aim is to use upstream gap in sage and it might well be that > already the next version of gap can be used unpatched with sage. I > don't think it makes sense to set up a new package just because we > need two or three patches at the moment. OK. > > On the other hand, if we decide against a separate source package, > > then we need to get 4.10 updated as soon as possible at least in > > experimental. > > I agree, a working sagemath should also be uploaded as soon as possible. > > > > Does that answer your questions ? > > > >> + * Install libgap to /usr/lib/triplet. > > Do you need this now ? When the interface to libgap has stabilized, then > > probably we will split libgap from gap-dev and move it to > > /usr/lib/triplet, but as long as it is an experimental feature it is > > best to keep it in a subdirectory. > > I would prefer not having to apply yet another workaround to find this > library. It is possible though. Part of the issue is that we can little afford to go to the NEW queue to add extra binary packages if we want to be ready before the freeze. What do you suggest ? > Would you be ok with applying these two patches? I do not like the idea of applying SAGE-specific patches to /usr/bin/gap. However if we arrange for the patch to be applied only to libgap, then I am ready to apply whatever you need. Cheers, -- Bill. Imagine a large red swirl here.
Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout
I have started a thread on debian-devel: https://lists.debian.org/debian-devel/2018/12/msg00184.html Please participate. Cheers, Stefan
Bug#916288: kea-dhcp4-server: Segfault after running for several minutes
Hello Anton, > (gdb) print/x $rax > $7 = 0x0 > (gdb) print stmt->mysql > $8 = (MYSQL *) 0x0 > (gdb) print *stmt->mysql > Cannot access memory at address 0x0 >> (gdb) list libmysql.c:4134 >> 4134 if (stmt->mysql->options.report_data_truncation) That null pointer seems to be the problem here, as the mysql client dereferences it unconditionally. >> I looked through upstream git history and commits [1] and [2] might be >> related: they disable automatic reconnects. >> No such commit seem to have reached the stretch version of kea-dhcp: >> ./isc-kea-1.1.0/src/lib/dhcpsrv/mysql_connection.cc:138: my_bool >> auto_reconnect = MLM_TRUE; > Hmmm ... but if you disable autoreconnect, doesn't this means each time > you restart your database server for any reason your dhcp server would > become in a not working state and it would require restart also? I fear this needs to be answered by the package maintainers or upstream developers. Kind regards, Bernhard
Bug#916725: chromium: Extensions which access Google Bookmarks fail
Package: chromium Version: 71.0.3578.80-1~deb9u1 Severity: important Dear Maintainer, Extensions which attempt to access Google (not chrome) bookmarks no longer function. This is a regression introducted since 69.0.3497.92-1~deb9u1. Example extensions which now fail: * https://chrome.google.com/webstore/detail/goomarks-browser-for-goog/oknllbfkmapccinochelgmcdjhlgfnik?hl=en-GB * https://chrome.google.com/webstore/detail/%EA%B5%AC%EA%B8%80-%EB%B6%81%EB%A7%88%ED%81%AC-%ED%8A%B8%EB%A6%AC/ofppcpdgnpnmlmellfphhehmhkafbgmm?hl=en-GB I don't believe this has yet been reported upstream. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii libasound2 1.1.3-5 ii libatk1.0-0 2.22.0-1 ii libatomic1 6.3.0-18+deb9u1 ii libatspi2.0-02.22.0-6+deb9u1 ii libavcodec-extra57 7:3.2.12-1~deb9u1 ii libavformat577:3.2.12-1~deb9u1 ii libavutil55 7:3.2.12-1~deb9u1 ii libc62.24-11+deb9u3 ii libcairo21.14.8-1 ii libcups2 2.2.1-8+deb9u2 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdrm2 2.4.74-1 ii libevent-2.0-5 2.0.21-stable-3 ii libexpat12.2.0-2+deb9u1 ii libflac8 1.3.2-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libicu57 57.1-6+deb9u2 ii libjpeg62-turbo 1:1.5.1-2 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1.1+deb9u1 ii libopenjp2-7 2.1.2-1.1+deb9u2 ii libopus0 1.2~alpha2-1 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libpci3 1:3.5.2-1 ii libpng16-16 1.6.28-1 ii libpulse010.0-1+deb9u1 ii libre2-3 20170101+dfsg-1 ii libsnappy1v5 1.1.3-3 ii libstdc++6 6.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libwebp6 0.5.2-1 ii libwebpdemux20.5.2-1 ii libwebpmux2 0.5.2-1 ii libx11-6 2:1.6.4-3+deb9u1 ii libx11-xcb1 2:1.6.4-3+deb9u1 ii libxcb1 1.12-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.14-1+deb9u2 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.29-2.1 ii libxss1 1:1.2.2-1 ii libxtst6 2:1.2.3-1 ii x11-utils7.7+3+b1 ii xdg-utils1.1.1-1+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages chromium recommends: ii fonts-liberation 1:1.07.4-2 ii libgl1-mesa-dri 13.0.6-1+b2 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell pn chromium-widevine -- no debconf information
Bug#915187: netfilter-persistent: Updating netfilter-persistent results in error
Hi Gustavo, I'm sorry, but I still don't get it completely. Am 16.12.2018 um 02:31 schrieb gustavo panizzo: Is not a parsing problem, the CHAINs do not exists. You need to check your setup. Check where the ip6*tables* symlinks points to and make it consistent. ip6tables-save points to /usr/sbin/ip6tables-nft-save, the version string is ip6tables-save v1.8.2 (nf_tables). ip6tables-restore points to /usr/sbin/ip6tables-nft-restore, which is of the same version v1.8.2. I've never touched these symlinks on my own. Also remove the legacy rules before applying new rules. if ip{,6}tables-save and ip{,6}tables-restore dont work in your system, netfilter-persistent won't work either (is just a wrapper around them to start the firewall at boot time) Yeah, and that is still my point of asking here: how can it be possible that dumping the rules and importing with tools from the same package with the same version throws an error? Shouldn't the process to write the rules generate a file that is sound and can be restored? Is it possible that there are incompatibilities with other parts? For example, I'm running the kernel version 4.4.134. I'm sorry to keep asking questions rather than providing a solution on my own, but I'm not that experienced with iptables. I've seen it throwing an error during an update and this looks like a bug to me. I'd be very happy if you could guide me to the neccessary steps of providing more information to inspect this. Regards Nico
Bug#916724: nanoc: ruby-ref and ruby-hamster should be Depends
Package: nanoc Version: 4.8.10-2 Severity: normal Dear Maintainer, I recently installed nanoc with all packages which are marked as Depends:, but no Recommends: package. After the installation I tried to create a new site: `nanoc create-site FOO` which led to the following error (Later I also got a LoadError for ref): Traceback (most recent call last): 5: from /usr/bin/nanoc:4:in `' 4: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 3: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2: from /usr/lib/ruby/vendor_ruby/nanoc.rb:22:in `' 1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- hamster (LoadError) The packages ruby-hamster and ruby-ref were listed as Recommends and thus not installed. I installed both packages and ran the commands again. Now nanoc did what was expected. That's why I suggest to add ruby-hamster as well as ruby-ref as Depends: This should lead to a working nanoc installation. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nanoc depends on: ii pry 0.12.2-1 ii ruby1:2.5.1 ii ruby-addressable2.5.2-1 ii ruby-adsf 1.2.1+dfsg1-1 ii ruby-cri2.10.1-1 ii ruby-ddplugin 1.0.2-1 ii ruby-listen 3.1.5-1 ii ruby2.1 [ruby-interpreter] 2.1.5-4 ii ruby2.2 [ruby-interpreter] 2.2.4-1 Versions of packages nanoc recommends: pn asciidoc-base pn asciidoctor pn ruby-builder pn ruby-coffee-script ii ruby-erubis 2.7.0-3 ii ruby-haml 4.0.7-1 ii ruby-hamster3.0.0-2 pn ruby-kramdown pn ruby-maruku pn ruby-mime-types pn ruby-mustache ii ruby-nokogiri 1.8.4-1 pn ruby-nokogumbo pn ruby-rdiscount pn ruby-redcarpet pn ruby-redcloth ii ruby-ref2.0.0-1 pn ruby-rouge pn ruby-rubypants pn ruby-sass pn ruby-slim pn ruby-uglifier Versions of packages nanoc suggests: ii git 1:2.20.0~rc2-1 ii python-pygments 2.2.0+dfsg-2 ii rsync3.1.2-2.2 pn ruby-fog ii ruby-rack1.6.4-6 -- no debconf information
Bug#916657: qtscript-opensource-src: Segmentation fault in libQt5Script.so.5.11.2 building qbs
On Mon, Dec 17, 2018 at 10:13:31AM -0500, John David Anglin wrote: > The patch fixes the build failure: > https://buildd.debian.org/status/fetch.php?pkg=qbs&arch=hppa&ver=1.12.2%2Bdfsg-1&stamp=1545014966&raw=0 > > There are still 2 test fails. 2 test fails is much better than segfault before running tests at all. I think that is enough to justify the fix. I will apply it in Git for the next release. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#916722: r-cran-httr: autopkgtest regression
Source: r-cran-httr Version: 1.4.0-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of r-cran-httr the autopkgtest of r-cran-httr fails in testing when that autopkgtest is run with the binary packages of r-cran-httr from unstable. It passes when run with only packages from testing. In tabular form: passfail r-cran-httrfrom testing1.4.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is contributing to the delay of the migration to testing [1]. Can you please investigate the situation and fix it? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=r-cran-httr https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-httr/1530341/log.gz autopkgtest [10:41:19]: test run-unit-test: [--- R version 3.5.1 (2018-07-02) -- "Feather Spray" Copyright (C) 2018 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > library(testthat) > test_check("httr") Loading required package: httr -- 1. Failure: can not use custom oob value without enabling oob (@test-oauth.R# `check_oob(FALSE, "custom_value")` did not throw an error. == testthat results === OK: 156 SKIPPED: 2 FAILED: 1 1. Failure: can not use custom oob value without enabling oob (@test-oauth.R#118) Error: testthat unit tests failed Execution halted autopkgtest [10:41:31]: test run-unit-test: ---] signature.asc Description: OpenPGP digital signature
Bug#916723: r-cran-bold: autopkgtest regression: no package called 'vcr'
Source: r-cran-bold Version: 0.8.6+dfsg-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of r-cran-bold the autopkgtest of r-cran-bold fails in testing when that autopkgtest is run with the binary packages of r-cran-bold from unstable. It passes when run with only packages from testing. In tabular form: passfail r-cran-boldfrom testing0.8.6+dfsg-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is contributing to the delay of the migration to testing [1]. Can you please investigate the situation and fix it? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=r-cran-bold https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-bold/1532839/log.gz autopkgtest [15:12:20]: test run-unit-test: [--- R version 3.5.2 RC (2018-12-13 r75850) -- "Eggshell Igloo" Copyright (C) 2018 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > library(testthat) > test_check('bold') Loading required package: bold Error in library("vcr") : there is no package called 'vcr' Calls: test_check ... source_dir -> lapply -> FUN -> eval -> eval -> library Execution halted autopkgtest [15:12:21]: test run-unit-test: ---] signature.asc Description: OpenPGP digital signature
Bug#916716: live-wrapper: Replace vmdebootstrap usage with alternative
Hi Scott, the "something else" part is the funny one :P. Yes, there are some very generic alternatives to vmdebootstrap - you might guess them: * debootstrap * cdebootstrap Thats all, downside is that one has to write all the things that vmdebootstrap provides new - so there are only two chances: * write all the glue code and the missing parts from the scratch (should be no problem, it has be done before) * wait for the successor of vmdebootstrap and write another wrapper based on a wrapper for debootstrap. My 2 cent Alf PS: If that sounds to negative - sorry, was not my intention. But there are only two options - make a debian iso wrapper around (c)debootstrap - it's done in the former sidux/aptosid's f.u.l.l.s.t.o.r.y and is called pyfll (https://github.com/fullstory/pyfll and https://github.com/fullstory/python-fll and some other glue packages (fll-liveinitscripts and -initramfs) - downside here: It's python2 and would need to be ported and cleaned up for long time usage in debian. PPS: The code could be stripped down to the really needed functions for debian - and should provide the needed interfaces for derivatives.
Bug#916719: graphicsmagick: CVE-2018-20185
Source: graphicsmagick Version: 1.3.31-1 Severity: important Tags: patch security upstream Forwarded: https://sourceforge.net/p/graphicsmagick/bugs/582/ Hi, The following vulnerability was published for graphicsmagick. CVE-2018-20185[0]: | In GraphicsMagick 1.4 snapshot-20181209 Q8 on 32-bit platforms, there | is a heap-based buffer over-read in the ReadBMPImage function of bmp.c, | which allows attackers to cause a denial of service via a crafted bmp | image file. This only affects GraphicsMagick installations with | customized BMP limits. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-20185 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20185 [1] https://sourceforge.net/p/graphicsmagick/bugs/582/ [2] http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/648e3977a293 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#916721: graphicsmagick: CVE-2018-20184
Source: graphicsmagick Version: 1.3.31-1 Severity: important Tags: patch security upstream Forwarded: https://sourceforge.net/p/graphicsmagick/bugs/583/ Hi, The following vulnerability was published for graphicsmagick. CVE-2018-20184[0]: | In GraphicsMagick 1.4 snapshot-20181209 Q8, there is a heap-based | buffer overflow in the WriteTGAImage function of tga.c, which allows | attackers to cause a denial of service via a crafted image file, | because the number of rows or columns can exceed the pixel-dimension | restrictions of the TGA specification. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-20184 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20184 [1] https://sourceforge.net/p/graphicsmagick/bugs/583/ [2] http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/15d1b5fd003b Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#904404: liece-dcc: fails to install with emacs25
Followup-For: Bug #904404 Another recent piupart test run revealed another, probably related problem: after the installation several shipped files are missing: 1m16.4s ERROR: FAIL: debsums reports modifications inside the chroot: debsums: missing file /usr/share/emacs/site-lisp/liece/bitmap-stipple.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/delegate.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/gettext.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-000.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-200.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-300.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-400.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-500.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-channel.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-clfns.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-coding.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-commands.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-compat.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-config.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-ctcp.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-dcc.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-emacs.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-filter.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-globals.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-handle.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-handler.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-hilit.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-inlines.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-intl.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-mail.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-make.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-menu.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-message.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-minibuf.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-misc.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-modules.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-nick.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-q-ccl.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-q-el.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-tcp.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-url.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-vars.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-version.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-window.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-x-face.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece-xemacs.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece.xbm (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/liece.xpm (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/plum-support.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/queue-m.el (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/styles/bottom (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/styles/middle (from liece package) debsums: missing file /usr/share/emacs/site-lisp/liece/styles/top (from liece package) Andreas liece_2.0+0.20030527cvs-11.2.log.gz Description: application/gzip
Bug#916720: upgrade-reports: stretch to buster upgrade graphics fail, ok with old kernel 4.9
Package: upgrade-reports Severity: important Dear Maintainer, upgraded to buster via apt-get upgrade, apt-get dist-upgrade, all worked well up to here. Booting gave black screen. Reboot with old kernel 4.9 --> all is well. Set system to go into multi-user (without graphics): Same effect. Thus it must be related to the framebuffer screen setting at boot, rather than xserver-xorg. Will attach working and non-working X.org.log below Max -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Working X.org.log [13.858] X.Org X Server 1.20.3 X Protocol Version 11, Revision 0 [13.858] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [13.858] Current Operating System: Linux desktop-2t5akti 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 [13.858] Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-8-amd64 root=/dev/mapper/vg-root ro splash video=SVIDEO-1:d [13.858] Build Date: 25 October 2018 06:15:23PM [13.858] xorg-server 2:1.20.3-1 (https://www.debian.org/support) [13.858] Current version of pixman: 0.34.0 [13.859]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [13.859] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [13.859] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 17 20:45:05 2018 [13.867] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [13.871] (==) No Layout section. Using the first Screen section. [13.871] (==) No screen section available. Using defaults. [13.871] (**) |-->Screen "Default Screen Section" (0) [13.871] (**) | |-->Monitor "" [13.874] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [13.874] (==) Automatically adding devices [13.874] (==) Automatically enabling devices [13.874] (==) Automatically adding GPU devices [13.874] (==) Max clients allowed: 256, resource mask: 0x1f [13.894] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [13.894]Entry deleted from font path. [13.921] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [13.921] (==) ModulePath set to "/usr/lib/xorg/modules" [13.921] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [13.921] (II) Loader magic: 0x55aaf69f0e20 [13.921] (II) Module ABI versions: [13.921]X.Org ANSI C Emulation: 0.4 [13.921]X.Org Video Driver: 24.0 [13.921]X.Org XInput driver : 24.1 [13.921]X.Org Server Extension : 10.0 [13.922] (++) using VT number 7 [13.922] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [13.924] (II) xfree86: Adding drm device (/dev/dri/card0) [13.946] (--) PCI:*(0@0:2:0) 8086:2a02:1028:01f9 rev 12, Mem @ 0xf6e0/1048576, 0xe000/268435456, I/O @ 0xeff8/8, BIOS @ 0x/131072 [13.946] (--) PCI: (0@0:2:1) 8086:2a03:1028:01f9 rev 12, Mem @ 0xf6f0/1048576 [13.946] (II) LoadModule: "glx" [13.949] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [14.046] (II) Module glx: vendor="X.Org Foundation" [14.046]compiled for 1.20.3, module version = 1.0.0 [14.046]ABI class: X.Org Server Extension, version 10.0 [14.046] (==) Matched modesetting as autoconfigured driver 0 [14.046] (==) Matched fbdev as autoconfigured driver 1 [14.046] (==) Matched vesa as autoconfigured driver 2 [14.046] (==) Assigned the driver to the xf86ConfigLayout [14.046] (II) LoadModule: "modesetting" [14.046] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [14.050] (II) Module modesetting: vendor="X.Org Foundation" [14.050]compiled for 1.20.3, module version = 1.20.3 [14.050]Module class: X.Org Video Driver [14.050]ABI class: X.Org Video Driver, version 24.0 [14.050] (II) LoadModule: "fbdev" [14.050] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [14.051] (II) Module fbdev: vendor="X.Org Foundation" [14.051]compiled for 1.20.0, module version = 0.5.0 [14.051]Module class: X.Org Video Driver [14.051]
Bug#916718: linux-image-4.18.0-3-amd64: Booting on Thinkpad X300 leave screen black (NULL pointer dereference in i915 drm driver)
Package: linux-image-4.18.0-3-amd64 Version: 4.18.20-2 Severity: important When booting a Thinkpad X300 with the latest kernel in testing, the screen go black shortly after grub hand over the control to the kernel, and the machine become unusable. Booting from kernel linux-image-4.17.0-1-amd64 work, luckily. I found these lines in /var/log/kern.log that seem to be relevant. Dec 17 20:11:10 thinkpadx300 kernel: [3.036115] [drm] RC6 disabled, disabling runtime PM support Dec 17 20:11:10 thinkpadx300 kernel: [3.036162] BUG: unable to handle kernel NULL pointer dereference at 0008 Dec 17 20:11:10 thinkpadx300 kernel: [3.036170] PGD 0 P4D 0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036180] Oops: [#1] SMP PTI Dec 17 20:11:10 thinkpadx300 kernel: [3.036189] CPU: 1 PID: 103 Comm: systemd-udevd Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-2 Dec 17 20:11:10 thinkpadx300 kernel: [3.036196] Hardware name: LENOVO 647815G/647815G, BIOS 7TET30WW (1.04 ) 05/07/2008 Dec 17 20:11:10 thinkpadx300 kernel: [3.036307] RIP: 0010:gen4_render_ring_flush+0x55/0xf0 [i915] Dec 17 20:11:10 thinkpadx300 kernel: [3.036313] Code: 00 be 16 00 00 00 48 89 ef e8 87 fe ff ff 48 3d 00 f0 ff ff 77 69 89 18 c7 40 04 02 40 00 7a 48 8b 55 78 48 8b 92 10 02 00 00 <48> 8b 52 08 48 c7 40 0c 00 00 00 00 83 ca 04 89 50 08 48 8d 50 14 Dec 17 20:11:10 thinkpadx300 kernel: [3.036389] RSP: 0018:ab47405c3a88 EFLAGS: 00010287 Dec 17 20:11:10 thinkpadx300 kernel: [3.036396] RAX: ab4750002000 RBX: 0202 RCX: 0001ff68 Dec 17 20:11:10 thinkpadx300 kernel: [3.036403] RDX: RSI: 01a8 RDI: 0150 Dec 17 20:11:10 thinkpadx300 kernel: [3.036410] RBP: 9bb6355a1680 R08: 0001 R09: 0020 Dec 17 20:11:10 thinkpadx300 kernel: [3.036417] R10: ab47405c3a58 R11: R12: 9bb635288000 Dec 17 20:11:10 thinkpadx300 kernel: [3.036424] R13: 9bb6723d8800 R14: R15: 9bb6355a1680 Dec 17 20:11:10 thinkpadx300 kernel: [3.036432] FS: 7f3bd80938c0() GS:9bb67d50() knlGS: Dec 17 20:11:10 thinkpadx300 kernel: [3.036441] CS: 0010 DS: ES: CR0: 80050033 Dec 17 20:11:10 thinkpadx300 kernel: [3.036447] CR2: 0008 CR3: 723b8000 CR4: 06e0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036454] Call Trace: Dec 17 20:11:10 thinkpadx300 kernel: [3.036533] i915_request_alloc+0x243/0x360 [i915] Dec 17 20:11:10 thinkpadx300 kernel: [3.036607] i915_gem_init+0x284/0x480 [i915] Dec 17 20:11:10 thinkpadx300 kernel: [3.036675] i915_driver_load+0xb22/0xef0 [i915] Dec 17 20:11:10 thinkpadx300 kernel: [3.036688] ? mutex_lock+0xe/0x30 Dec 17 20:11:10 thinkpadx300 kernel: [3.036696] ? acpi_dev_found+0x5f/0x70 Dec 17 20:11:10 thinkpadx300 kernel: [3.036705] local_pci_probe+0x42/0xa0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036713] ? pci_assign_irq+0x27/0x130 Dec 17 20:11:10 thinkpadx300 kernel: [3.036721] pci_device_probe+0x146/0x1b0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036731] driver_probe_device+0x2fa/0x470 Dec 17 20:11:10 thinkpadx300 kernel: [3.036739] __driver_attach+0xdc/0x100 Dec 17 20:11:10 thinkpadx300 kernel: [3.036746] ? driver_probe_device+0x470/0x470 Dec 17 20:11:10 thinkpadx300 kernel: [3.036753] bus_for_each_dev+0x76/0xc0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036761] ? klist_add_tail+0x3b/0x70 Dec 17 20:11:10 thinkpadx300 kernel: [3.036769] bus_add_driver+0x161/0x260 Dec 17 20:11:10 thinkpadx300 kernel: [3.036776] ? 0xc07fb000 Dec 17 20:11:10 thinkpadx300 kernel: [3.036783] driver_register+0x5b/0xe0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036790] ? 0xc07fb000 Dec 17 20:11:10 thinkpadx300 kernel: [3.036798] do_one_initcall+0x46/0x1c8 Dec 17 20:11:10 thinkpadx300 kernel: [3.036806] ? _cond_resched+0x15/0x40 Dec 17 20:11:10 thinkpadx300 kernel: [3.036814] ? kmem_cache_alloc_trace+0xb5/0x1c0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036822] ? do_init_module+0x22/0x201 Dec 17 20:11:10 thinkpadx300 kernel: [3.036829] do_init_module+0x5b/0x201 Dec 17 20:11:10 thinkpadx300 kernel: [3.036837] load_module.constprop.56+0x1649/0x1d80 Dec 17 20:11:10 thinkpadx300 kernel: [3.036846] ? vfs_read+0x113/0x130 Dec 17 20:11:10 thinkpadx300 kernel: [3.036852] ? vfs_read+0x113/0x130 Dec 17 20:11:10 thinkpadx300 kernel: [3.036860] ? __do_sys_finit_module+0xe9/0x110 Dec 17 20:11:10 thinkpadx300 kernel: [3.036866] __do_sys_finit_module+0xe9/0x110 Dec 17 20:11:10 thinkpadx300 kernel: [3.036875] do_syscall_64+0x55/0x110 Dec 17 20:11:10 thinkpadx300 kernel: [3.036882] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Dec 17 20:11:10 thinkpadx300 kernel: [3.036889] RIP: 0033:0x7f3bd8afc309 Dec 17 20:11:10 thinkpadx300 kernel: [3.036893
Bug#911925: Re%3A S8195874%3A Improve jar specification adherence breaks reverse%0A depends build and runtime
Would be a nice X-Mass present to get a working jdk version in stable. On Fri%2C 30 Nov 2018 13%3A01%3A43 %2B0100 Harald Dunkel wrote%3A%0A> Would it be possible to include this fix for Stretch as well%3F%0A> %0A> Regards%0A> Harri%0A> %0A> %0A
Bug#916683: libgnutls30: breaks msmtp 1.6.7-1
Quoting Andreas Metzler (2018-12-17 19:37:05) > On 2018-12-17 Jonas Smedegaard wrote: > > I use msmtp, and it worked fine until few days ago, > > with msmtp 1.6.7-1 and libgnutls30 3.5.19-1+b1. > > > Upgrading to libgnutls30 3.6.5-2 breaks msmtp: > > Any attempt at connecting to a TLS-secured site gets disconnected. > > FWIW I have had successful connections against exim4 (gnutls 3.5 and > 3.6). Which host are you trying to connect to? Sorry for exaggerating! The hosts I experienced problems with are mail.jones.dk and mail.homebase.dk - both running Postfix on Debian stable (which made me rule out them as cause for blame, but...) both of them managed by myself with various attempts at tightening security, so I realize now that I may possibly have exposed bugs in unusual setups rather than common ones. Both systems are running in production so I am not happy doing drastic experiments on them - but on the other hand they are public accessible so available for testing this bug if needed. - 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#916717: ITP: freeboard -- dashboard builder for IoT and other web mashups
Package: wnpp Severity: wishlist Owner: Ying-Chun Liu (PaulLiu) X-Debbugs-CC: debian-de...@lists.debian.org * Package name: freeboard Version : 1.0.2 Upstream Author : ABR, just published, real autor buglabs Jim Heising * URL : http://freeboard.io * License : Expat Programming Lang: JavaScript Description : dashboard for IoT and web mashups open source real-time dashboard builder for IoT and other web mashups. A free open-source alternative to Geckoboard. -- PaulLiu (劉穎駿) E-mail: Ying-Chun Liu (PaulLiu) signature.asc Description: OpenPGP digital signature
Bug#916096: closed by Mateusz Łukasik (Bug#916096: fixed in smplayer 18.10.0~ds0-1)
Control: reopen -1 On Mon, Dec 17, 2018 at 12:09:04AM +, Debian Bug Tracking System wrote: > + Pass a cross qmake along. You only applied half of this. There now is a make variable QMAKE in debian/rules, but it is not passed along. Therefore, smplayer still fails to cross build. Helmut
Bug#916683: libgnutls30: breaks msmtp 1.6.7-1
Quoting Andreas Metzler (2018-12-17 19:37:05) > On 2018-12-17 Jonas Smedegaard wrote: > > I use msmtp, and it worked fine until few days ago, > > with msmtp 1.6.7-1 and libgnutls30 3.5.19-1+b1. > > > Upgrading to libgnutls30 3.6.5-2 breaks msmtp: > > Any attempt at connecting to a TLS-secured site gets disconnected. > > FWIW I have had successful connections against exim4 (gnutls 3.5 and > 3.6). Which host are you trying to connect to? > > > Seems liek backwards-incompatible ABI change to me, which I believe > > should be handled in coordination with its reverse dependencies. > > Hence the severity. > > It is not an API change but a side effect of different handshake with > TLS1.3, now GNUTLS_E_AGAIN can be returned for blocking sockets. > > See > https://github.com/marlam/msmtp-mirror/commit/ec043e5375d0ecd5ab987e53d0ebfecfc1de0858 Ahh, thanks a lot for digging deeper. - 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#916713: openssh-client: ssh-add still shows and uses old ED25519 keys
Hallo Frank, 17.12.18 19:44 Frank: > ssh-add remembers old keys that I am not using for weeks. They still > show up after reboot and after ssh-add -D. We already figured out that it is not ssh-agent, but gpg-agent. ssh-add doesn't store anything, it just talks to ssh-agent or something else speaking its protocol, btw. > There is a bug report about gnome-keyring which states that you can't > delete keys which are imported by i.e. gnome-keyring. Problem is that I > don't have gnome-keyring installed but maybe the keys are stored > somewhere else? > > This bug is important because it keeps me from login in with ssh to > devices that disconnect after 3 connect attempts. I have to specify the > key to use manually. You might want to use something like that in your .ssh/config: Host *.example.com IdentityFile ~/.ssh/id_example.com.pub IdentitiesOnly yes Host *.example.org IdentityFile ~/.ssh/id_example.org.pub IdentitiesOnly yes IdentitiesOnly prevents ssh offering all the keys from your agent even when you have specified the key. That way you can keep all keys in your agent. Please either close this bug or reassign to gpg-agent and perhaps rephrase what you expect gpg-agent to do. Quoting gpg-agent(1): 8<8<8< SSH Keys, which are to be used through the agent, need to be added to the gpg- agent initially through the ssh-add utility. When a key is added, ssh-add will ask for the password of the provided key file and send the unprotected key material to the agent; this causes the gpg-agent to ask for a passphrase, which is to be used for encrypting the newly received key and storing it in a gpg-agent specific directory. 8<8<8< Grüße Timo signature.asc Description: This is a digitally signed message part.
Bug#916716: live-wrapper: Replace vmdebootstrap usage with alternative
Package: live-wrapper Version: 0.7 Severity: important The vmdebootstrap maintainer has a strong preference for the package to be removed from Debian [1]. live-wrapper is the only remaining user. Pleae port it to use something else. Scott K [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907751
Bug#916715: toulbar2: missing build dependency on zlib1g-dev
Source: toulbar2 Version: 1.0.0+dfsg3-1 Severity: serious Tags: ftbfs https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/toulbar2.html ... CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: ZLIB_LIBRARY linked by target "toulbar2" in directory /build/1st/toulbar2-1.0.0+dfsg3
Bug#916392: please provide a column marker mechanism
On 12/17/18 7:55 PM, Benno Schulenberg wrote: > > Hi Arturo, > > Interesting request. But... a vertical bar across the screen is > hard to make -- it would mean having to extend shorter lines with > whitespace to reach the desired column. What is easier to make > is to color any text that exceeds a certain column. > > Attached is a proof of concept. The "limit" is baked in as 68; > it would of course have to become settable by some option. > > This doesn't give you an indication of how many columns you can > still use before reaching the limit, but this is the best I can > do with a simple patch. > Having this initial approach in place would be great! You could develop a more complex/featurerfull implementations in later iterations, if this is useful to any other people. Thanks!
Bug#916392: please provide a column marker mechanism
Hi Arturo, Interesting request. But... a vertical bar across the screen is hard to make -- it would mean having to extend shorter lines with whitespace to reach the desired column. What is easier to make is to color any text that exceeds a certain column. Attached is a proof of concept. The "limit" is baked in as 68; it would of course have to become settable by some option. This doesn't give you an indication of how many columns you can still use before reaching the limit, but this is the best I can do with a simple patch. Benno diff --git a/src/winio.c b/src/winio.c index a4a3df77..8162a3c6 100644 --- a/src/winio.c +++ b/src/winio.c @@ -2690,6 +2690,12 @@ void edit_draw(filestruct *fileptr, const char *converted, } #endif /* ENABLE_COLOR */ + const char *linetext = converted + actual_x(converted, 68);; + + wattron(edit, interface_color_pair[ERROR_MESSAGE]); + mvwaddnstr(edit, row, margin + 68, linetext, -1); + wattroff(edit, interface_color_pair[ERROR_MESSAGE]); + #ifndef NANO_TINY /* If the mark is on, and fileptr is at least partially selected, we * need to paint it. */
Bug#916713: openssh-client: ssh-add still shows and uses old ED25519 keys
Hey Niels, thanks for your idea! gpg -K: /home/hommesf/.gnupg/pubring.kbx sec> rsa4096 2018-09-24 [SC] [some private key fingerprint] Card serial no. = 0005 4FDD That's actually all I can find. seahorse didn't show the others neither. Greetings Frank
Bug#916714: plplot FTBFS: Cannot find "usr/lib/*/plplot*/drivers/cairo.*"
Source: plplot Version: 5.13.0+dfsg-9 Severity: serious Tags: ftbfs Some recent change in unstable makes plplot FTBFS: https://tests.reproducible-builds.org/debian/history/plplot.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/plplot.html ... -- WARNING: pango and/or cairo not found with pkg-config. Disabling cairo drivers. To enable these drivers you must install development versions of pango and cairo and/or set the environment variable PKG_CONFIG_PATH appropriately. ... dh_install -O-Scmake dh_install: Cannot find (any matches for) "usr/lib/*/plplot*/drivers/cairo.*" (tried in ., debian/tmp) dh_install: plplot-driver-cairo missing files: usr/lib/*/plplot*/drivers/cairo.* dh_install: missing files, aborting make: *** [debian/rules:35: binary] Error 25
Bug#916713: openssh-client: ssh-add still shows and uses old ED25519 keys
Control: tags -1 moreinfo On Mon, 17 Dec 2018 19:44:19 +0100 Frank wrote: > Package: openssh-client > Version: 1:7.9p1-4 > Severity: important > > Hey, > > ssh-add remembers old keys that I am not using for weeks. They still > show up after reboot and after ssh-add -D. > > There is a bug report about gnome-keyring which states that you can't > delete keys which are imported by i.e. gnome-keyring. Problem is that I > don't have gnome-keyring installed but maybe the keys are stored > somewhere else? > > This bug is important because it keeps me from login in with ssh to > devices that disconnect after 3 connect attempts. I have to specify the > key to use manually. > > The key is of course not in .ssh/id_ed25519 or in /etc/ssh/... > > [...] > > [hommesf@stark ~]$ echo $SSH_AUTH_SOCK > /run/user/1000/gnupg/S.gpg-agent.ssh > > I am trying to fix this for weeks but nothing is helping. > > Greetings > Frank > > [...] Hi Frank, (Not the SSH maintainer, but ...) The name of your $SSH_AUTH_SOCK implies that you are using gpg as ssh-agent. Have you tried removing the relevant keys from your gpg keyring? Thanks, ~Niels
Bug#916712: libgnutls30: Dummy bug - prevent too fast migration to testing
Package: libgnutls30 Version: 3.6.5-2 Severity: serious Justification: maintainer's opinion gnutls 3.6.5-2 would be a candidate for testing migration tomorrow ("Too young, only 1 of 2 days old"). This is too quick, the changes require more testing in sid. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' signature.asc Description: PGP signature
Bug#916713: openssh-client: ssh-add still shows and uses old ED25519 keys
Package: openssh-client Version: 1:7.9p1-4 Severity: important Hey, ssh-add remembers old keys that I am not using for weeks. They still show up after reboot and after ssh-add -D. There is a bug report about gnome-keyring which states that you can't delete keys which are imported by i.e. gnome-keyring. Problem is that I don't have gnome-keyring installed but maybe the keys are stored somewhere else? This bug is important because it keeps me from login in with ssh to devices that disconnect after 3 connect attempts. I have to specify the key to use manually. The key is of course not in .ssh/id_ed25519 or in /etc/ssh/... [hommesf@stark tmp]$ ssh-add -l 4096 SHA256:unV9TSgT3jDr3t5aq7C5QJLiGJRddMIYIFfpkx8V5kY cardno:00054FDD (RSA) 256 SHA256:33JVhwdL/E/NLhna6e4vZaj3nfjKVrfz3ss+jldSjD0 hommesf@stark (ED25519) 256 SHA256:mvQJDcAnfXfji5lq/+j2JJPH+8SbYTv3uYFL534Kx1w hommesf@stark (ED25519) 4096 SHA256:f2U9xc2Rc3L9yeIycx5LAfIbMRKNwSSUTzjCxMDGbN0 /home/hommesf/.ssh/id_rsa (RSA) 256 SHA256:L4VndWhOm1D4mJApONnyvtyGbqo2LmmjtHjnH55hsOw hommesf@stark (ED25519) [hommesf@stark tmp]$ ssh-add -D All identities removed. [hommesf@stark tmp]$ ssh-add -d Identity removed: /home/hommesf/.ssh/id_ed25519 (hommesf@stark) [hommesf@stark tmp]$ ssh-add -l 4096 SHA256:unV9TSgT3jDr3t5aq7C5QJLiGJRddMIYIFfpkx8V5kY cardno:00054FDD (RSA) 256 SHA256:33JVhwdL/E/NLhna6e4vZaj3nfjKVrfz3ss+jldSjD0 hommesf@stark (ED25519) 256 SHA256:mvQJDcAnfXfji5lq/+j2JJPH+8SbYTv3uYFL534Kx1w hommesf@stark (ED25519) 4096 SHA256:f2U9xc2Rc3L9yeIycx5LAfIbMRKNwSSUTzjCxMDGbN0 /home/hommesf/.ssh/id_rsa (RSA) 256 SHA256:L4VndWhOm1D4mJApONnyvtyGbqo2LmmjtHjnH55hsOw hommesf@stark (ED25519) [hommesf@stark ~]$ echo $SSH_AUTH_SOCK /run/user/1000/gnupg/S.gpg-agent.ssh I am trying to fix this for weeks but nothing is helping. Greetings Frank -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.19.2 ii libc6 2.27-8 ii libedit2 3.1-20180525-1 ii libgssapi-krb5-2 1.16.1-1 ii libselinux1 2.8-1+b1 ii libssl1.1 1.1.1a-1 ii passwd1:4.5-1.1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages openssh-client recommends: ii xauth 1:1.0.10-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- no debconf information
Bug#916711: only GPL-3
Package: smbmap Version: 1.0.5+git20180508-1 Severity: serious thanks Dear Maintainer, according to smbmap-master/LICENSE, the license of this software is only GPL-3. Please adapt your debian/copyright accordingly. Thanks! Thorsten
Bug#916683: libgnutls30: breaks msmtp 1.6.7-1
Control: reassign -1 msmtp 1.6.7-1 Control: tags -1 fixed-upstream On 2018-12-17 Jonas Smedegaard wrote: > Package: libgnutls30 > Version: 3.6.5-2 > Severity: serious > Justification: Policy 3.5 > I use msmtp, and it worked fine until few days ago, > with msmtp 1.6.7-1 and libgnutls30 3.5.19-1+b1. > Upgrading to libgnutls30 3.6.5-2 breaks msmtp: > Any attempt at connecting to a TLS-secured site gets disconnected. FWIW I have had successful connections against exim4 (gnutls 3.5 and 3.6). Which host are you trying to connect to? > Seems liek backwards-incompatible ABI change to me, > which I believe should be handled in coordination with its > reverse dependencies. Hence the severity. It is not an API change but a side effect of different handshake with TLS1.3, now GNUTLS_E_AGAIN can be returned for blocking sockets. See https://github.com/marlam/msmtp-mirror/commit/ec043e5375d0ecd5ab987e53d0ebfecfc1de0858 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' signature.asc Description: PGP signature
Bug#916710: info-beamer FTBFS with glew 2.1.0
Source: info-beamer Version: 1.0~pre3+dfsg-0.1 Severity: serious Tags: ftbfs buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/info-beamer.html ... In file included from main.c:25: /usr/include/GL/glext.h:12066:25: error: conflicting types for 'PFNGLFRAGMENTLIGHTFVSGIXPROC' typedef void (APIENTRYP PFNGLFRAGMENTLIGHTFVSGIXPROC) (GLenum light, GLenum pname, const GLfloat *params); ^~~~ In file included from main.c:23: /usr/include/GL/glew.h:18734:28: note: previous declaration of 'PFNGLFRAGMENTLIGHTFVSGIXPROC' was here typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTFVSGIXPROC) (GLenum light, GLenum pname, GLfloat* params); ^~~~ In file included from main.c:25: /usr/include/GL/glext.h:12068:25: error: conflicting types for 'PFNGLFRAGMENTLIGHTIVSGIXPROC' typedef void (APIENTRYP PFNGLFRAGMENTLIGHTIVSGIXPROC) (GLenum light, GLenum pname, const GLint *params); ^~~~ In file included from main.c:23: /usr/include/GL/glew.h:18736:28: note: previous declaration of 'PFNGLFRAGMENTLIGHTIVSGIXPROC' was here typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTIVSGIXPROC) (GLenum light, GLenum pname, GLint* params); ^~~~ In file included from main.c:25: /usr/include/GL/glext.h:12070:25: error: conflicting types for 'PFNGLFRAGMENTLIGHTMODELFVSGIXPROC' typedef void (APIENTRYP PFNGLFRAGMENTLIGHTMODELFVSGIXPROC) (GLenum pname, const GLfloat *params); ^ In file included from main.c:23: /usr/include/GL/glew.h:18730:28: note: previous declaration of 'PFNGLFRAGMENTLIGHTMODELFVSGIXPROC' was here typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTMODELFVSGIXPROC) (GLenum pname, GLfloat* params); ^ ...
Bug#916362: liblxc1: Missing epoch version in liblxc1 symbols file
On Fri, 14 Dec 2018 00:07:30 +0800 Shengjing Zhu wrote: > The lxc package in Debian has a epoch 1, which is missed from liblxc1's > symbols file. MR sent, https://salsa.debian.org/lxc-team/lxc/merge_requests/2 -- Shengjing Zhu
Bug#916709: fritzing: FTBFS when built with dpkg-buildpackage -A
Package: src:fritzing Version: 0.9.3b+dfsg-7 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in buster with dpkg-buildpackage -A but it failed: [...] make[2]: Entering directory '/<>/fritzing-0.9.3b+dfsg' make[2]: Nothing to be done for 'first'. make[2]: Leaving directory '/<>/fritzing-0.9.3b+dfsg' make[1]: Leaving directory '/<>/fritzing-0.9.3b+dfsg' create-stamp debian/debhelper-build-stamp fakeroot debian/rules binary-indep dh binary-indep dh_testroot -i dh_prep -i dh_auto_install -i make V=1 -j1 install DESTDIR=/<>/fritzing-0.9.3b\+dfsg/debian/tmp AM_UPDATE_INFO_DIR=no INSTALL_ROOT=/<>/fritzing-0.9.3b\+dfsg/debian/tmp make[1]: Entering directory '/<>/fritzing-0.9.3b+dfsg' make -f Makefile.Release install make[2]: Entering directory '/<>/fritzing-0.9.3b+dfsg' /usr/lib/qt5/bin/qmake -install qinstall -exe Fritzing /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/bin/Fritzing : /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/bin/Fritzing /usr/lib/qt5/bin/qmake -install qinstall /<>/fritzing-0.9.3b+dfsg/fritzing.desktop /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/applications/fritzing.desktop /usr/lib/qt5/bin/qmake -install qinstall /<>/fritzing-0.9.3b+dfsg/Fritzing.1 /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/man/man1/Fritzing.1 install -D -m 0644 /<>/fritzing-0.9.3b+dfsg/resources/images/fritzing_icon.png /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/icons/fritzing.png /usr/lib/qt5/bin/qmake -install qinstall /<>/fritzing-0.9.3b+dfsg/sketches /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/fritzing/sketches find /<>/fritzing-0.9.3b+dfsg/translations -name *.qm -size +128c -exec cp -pr {} /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/fritzing/translations \; /usr/lib/qt5/bin/qmake -install qinstall /<>/fritzing-0.9.3b+dfsg/translations/syntax/arduino.xml /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/fritzing/translations/syntax/arduino.xml /usr/lib/qt5/bin/qmake -install qinstall /<>/fritzing-0.9.3b+dfsg/translations/syntax/picaxe.xml /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/fritzing/translations/syntax/picaxe.xml /usr/lib/qt5/bin/qmake -install qinstall /<>/fritzing-0.9.3b+dfsg/translations/syntax/styles.xml /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/fritzing/translations/syntax/styles.xml /usr/lib/qt5/bin/qmake -install qinstall /<>/fritzing-0.9.3b+dfsg/help /<>/fritzing-0.9.3b+dfsg/debian/tmp/usr/share/fritzing/help make[2]: Leaving directory '/<>/fritzing-0.9.3b+dfsg' make[1]: Leaving directory '/<>/fritzing-0.9.3b+dfsg' debian/rules override_dh_install make[1]: Entering directory '/<>/fritzing-0.9.3b+dfsg' dh_install convert /<>/fritzing-0.9.3b+dfsg/debian/fritzing/usr/share/pixmaps/fritzing_icon.png -resize 32x32 \ /<>/fritzing-0.9.3b+dfsg/debian/fritzing/usr/share/pixmaps/fritzing_icon.xpm convert-im6.q16: unable to open image `/<>/fritzing-0.9.3b+dfsg/debian/fritzing/usr/share/pixmaps/fritzing_icon.png': No such file or directory @ error/blob.c/OpenBlob/2874. convert-im6.q16: no images defined `/<>/fritzing-0.9.3b+dfsg/debian/fritzing/usr/share/pixmaps/fritzing_icon.xpm' @ error/convert.c/ConvertImageCommand/3258. make[1]: *** [debian/rules:23: override_dh_install] Error 1 make[1]: Leaving directory '/<>/fritzing-0.9.3b+dfsg' make: *** [debian/rules:12: binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess returned exit status 2 Hint: Try splitting override_dh_install into override_dh_install-arch and override_dh_install-indep. While we are at it, please consider uploading in source-only form (dpkg-buildpackage -S) so that this kind of bugs never propagate to testing. Thanks.
Bug#916708: python-wicd: misleading error message "Bad password"
Package: python-wicd Version: 1.7.4+tb2-6 Severity: important Tags: patch On some wireless network with authentication, I systematically got an error "Bad password". Thus I spent hours trying to find the problem related to my password, with the impossibility to find the cause of this issue. With the wpasupplicant upgrade last week-end, it made clear that the issue (solved with this upgrade) was not the password, but the TLS version. This error message should be changed to "Authentication failed" (which covers more issues than just a bad password), or something similar. Patch attached. (Since this is a translated messages, the .po files also need to be rebuilt and updated.) -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-wicd depends on: ii net-tools 1.60+git20180626.aebd88e-1 ii python 2.7.15-3 python-wicd recommends no packages. Versions of packages python-wicd suggests: ii ethtool 1:4.19-1 ii iproute2 4.18.0-2 Versions of packages wicd depends on: ii wicd-curses [wicd-client] 1.7.4+tb2-6 ii wicd-daemon1.7.4+tb2-6 ii wicd-gtk [wicd-client] 1.7.4+tb2-6 Versions of packages wicd-gtk depends on: ii python 2.7.15-3 ii python-glade2 2.24.0-5.1+b1 ii python-gtk22.24.0-5.1+b1 ii wicd-daemon1.7.4+tb2-6 Versions of packages wicd-gtk recommends: ii menu 2.1.47+b1 ii policykit-10.105-23 ii python-notify 0.1.1-4 Versions of packages wicd-curses depends on: ii python2.7.15-3 ii python-urwid 2.0.1-2+b1 ii wicd-daemon 1.7.4+tb2-6 Versions of packages wicd-curses recommends: ii sudo 1.8.26-2 Versions of packages wicd-daemon depends on: ii adduser 3.118 ii dbus 1.12.12-1 ii debconf 1.5.69 ii iputils-ping 3:20180629-2 ii isc-dhcp-client 4.4.1-2 ii lsb-base 10.2018112800 ii psmisc23.2-1 ii python2.7.15-3 ii python-dbus 1.2.8-2+b2 ii python-gobject-2 2.28.6-13+b1 ii wireless-tools30~pre9-13 ii wpasupplicant 2:2.6-21 Versions of packages wicd-daemon recommends: ii rfkill 2.33-0.2 ii wicd-curses [wicd-client] 1.7.4+tb2-6 ii wicd-gtk [wicd-client] 1.7.4+tb2-6 Versions of packages wicd-daemon suggests: pn pm-utils -- debconf information: * wicd/users: Index: wicd-1.7.4+tb2/wicd/misc.py === --- wicd-1.7.4+tb2.orig/wicd/misc.py +++ wicd-1.7.4+tb2/wicd/misc.py @@ -86,7 +86,7 @@ _status_dict = { 'aborted': _('Connection Cancelled'), 'association_failed': _('Connection failed: Could not contact the ' + \ 'wireless access point.'), -'bad_pass': _('Connection Failed: Bad password'), +'bad_pass': _('Connection Failed: Authentication failed'), 'configuring_interface': _('Configuring wireless interface...'), 'dhcp_failed': _('Connection Failed: Unable to Get IP Address'), 'done': _('Done connecting...'),
Bug#916707: svxreflector: logrotate produces output after package removal
Package: svxreflector Version: 17.12.2-1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package's logrotate configuration causes logrotate to exit with an error after the package has been removed (*) or when logrote is run but no logfile exists. Usually the solution is to specify 'missingok' in the logrotate configuration. *) logrotate configuration files remain installed and executed after a package has been removed, they only get removed when the package is purged. >From the attached log (scroll to the bottom...): 0m23.5s DEBUG: Starting command: ['chroot', '/srv/piuparts/tmp/tmpmMauhC', '/usr/sbin/logrotate', '/etc/logrotate.d/svxreflector'] 0m23.5s DUMP: error: /etc/logrotate.d/svxreflector:5 unknown user 'svxreflector' error: found error in /var/log/svxreflector , skipping 0m23.5s DEBUG: Command ok: ['chroot', '/srv/piuparts/tmp/tmpmMauhC', '/usr/sbin/logrotate', '/etc/logrotate.d/svxreflector'] 0m23.5s ERROR: FAIL: Logrotate file exits with error or has output with package removed cheers, Andreas svxreflector_17.12.2-1.log.gz Description: application/gzip
Bug#916706: python-cobra FTBFS with python-pip 18.1
Source: python-cobra Version: 0.13.4-2 Severity: serious Tags: ftbfs https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-cobra.html ... = test session starts == platform linux -- Python 3.6.8rc1, pytest-3.10.1, py-1.7.0, pluggy-0.8.0 benchmark: 3.1.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.05 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=10) rootdir: /build/1st/python-cobra-0.13.4, inifile: setup.cfg plugins: benchmark-3.1.1 collected 0 items / 1 errors ERRORS __ ERROR collecting ___ /usr/lib/python3/dist-packages/_pytest/config/__init__.py:430: in _importconftest return self._conftestpath2mod[conftestpath] E KeyError: local('/build/1st/python-cobra-0.13.4/.pybuild/cpython3_3.6_cobra/build/cobra/test/conftest.py') During handling of the above exception, another exception occurred: /usr/lib/python3/dist-packages/pipdeptree.py:17: in from pip._internal import get_installed_distributions E ImportError: cannot import name 'get_installed_distributions' During handling of the above exception, another exception occurred: /usr/lib/python3/dist-packages/_pytest/config/__init__.py:436: in _importconftest mod = conftestpath.pyimport() /usr/lib/python3/dist-packages/py/_path/local.py:668: in pyimport __import__(modname) cobra/__init__.py:11: in from cobra import flux_analysis, io cobra/flux_analysis/__init__.py:3: in from cobra.flux_analysis.gapfilling import gapfill cobra/flux_analysis/gapfilling.py:8: in from cobra.core import Model cobra/core/__init__.py:6: in from cobra.core.gene import Gene cobra/core/gene.py:13: in from cobra.util import resettable cobra/util/__init__.py:7: in from cobra.util.util import * cobra/util/util.py:5: in from depinfo import print_dependencies /usr/lib/python3/dist-packages/depinfo/__init__.py:27: in from depinfo.info import * /usr/lib/python3/dist-packages/depinfo/info.py:24: in from pipdeptree import build_dist_index, construct_tree /usr/lib/python3/dist-packages/pipdeptree.py:20: in from pip import get_installed_distributions, FrozenRequirement E ImportError: cannot import name 'get_installed_distributions' During handling of the above exception, another exception occurred: /usr/lib/python3/dist-packages/py/_path/common.py:377: in visit for x in Visitor(fil, rec, ignore, bf, sort).gen(self): /usr/lib/python3/dist-packages/py/_path/common.py:429: in gen for p in self.gen(subdir): /usr/lib/python3/dist-packages/py/_path/common.py:418: in gen dirs = self.optsort([p for p in entries /usr/lib/python3/dist-packages/py/_path/common.py:419: in if p.check(dir=1) and (rec is None or rec(p))]) /usr/lib/python3/dist-packages/_pytest/main.py:601: in _recurse ihook = self.gethookproxy(dirpath) /usr/lib/python3/dist-packages/_pytest/main.py:418: in gethookproxy my_conftestmodules = pm._getconftestmodules(fspath) /usr/lib/python3/dist-packages/_pytest/config/__init__.py:414: in _getconftestmodules mod = self._importconftest(conftestpath) /usr/lib/python3/dist-packages/_pytest/config/__init__.py:453: in _importconftest raise ConftestImportFailure(conftestpath, sys.exc_info()) E _pytest.config.ConftestImportFailure: (local('/build/1st/python-cobra-0.13.4/.pybuild/cpython3_3.6_cobra/build/cobra/test/conftest.py'), (, ImportError("cannot import name 'get_installed_distributions'",), )) === warnings summary === cobra/flux_analysis/gapfilling.py:83 /build/1st/python-cobra-0.13.4/.pybuild/cpython3_3.6_cobra/build/cobra/flux_analysis/gapfilling.py:83: DeprecationWarning: invalid escape sequence \s """ cobra/core/gene.py:248 /build/1st/python-cobra-0.13.4/.pybuild/cpython3_3.6_cobra/build/cobra/core/gene.py:248: DeprecationWarning: invalid escape sequence \( the_gene_re = re.compile('(^|(?<=( |\()))%s(?=( |\)|$))' % cobra/core/gene.py:262 /build/1st/python-cobra-0.13.4/.pybuild/cpython3_3.6_cobra/build/cobra/core/gene.py:262: DeprecationWarning: invalid escape sequence \( other_gene_re = re.compile('(^|(?<=( |\()))%s(?=( |\)|$))' % /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:49 /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:49: DeprecationWarning: invalid escape sequence \[ /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:50 /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:50: DeprecationWarning: invalid escape sequence \] /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:49 /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colo
Bug#910465: makedumpfile: [INTL:pt] Updated Portuguese translation - debconf messages
A terça-feira, 16 de outubro de 2018 18:02:00 WEST você escreveu: > On Sat, Oct 06, 2018 at 06:16:49PM +0100, Américo Monteiro wrote: > > Package: makedumpfile > > Version: 1_1.6.4-2 > > Tags: l10n, patch > > Severity: wishlist > > > > Updated Portuguese translation for makedumpfile's debconf messages > > Translator: Américo Monteiro > > Feel free to use it. > > > > For translation updates please contact 'Last Translator' > > Hi, Américo. > > There is already an updated translation from Rui Branco. I don't see > anything wrong with it. Though I am a native Portuguese speaker as well, > I defer to you both to decide whether any update is needed. > > Thanks. > Cascardo. Olá... se outra tradução existe, não a vejo: aqui https://www.debian.org/international/l10n/po-debconf/pt diz que o pacote está por traduzir e no BTS não estava nenhuma tradução portuguesa a aguardar inclusão, por isso lancei o meu trabalho. agora https://bugs.debian.org/cgi-bin/pkgreport.cgi? dist=unstable;package=makedumpfile está lá o meu bug report e não vejo a tradução que falas melhores cumprimentos Américo
Bug#916678: systemd: Caught , dumped core as pid 2097
On Mon, 17 Dec 2018, Michael Biebl wrote: > > What's the output of > coredumpctl list # coredumpctl list No coredumps found. > ls -la /var/lib/systemd/coredump/ # ls -l /var/lib/systemd/coredump/ -rw-r- 1 root root 873282 Dec 16 17:16 core.systemd.0.829d81de299543c1a445874d1dd7660d.2097.154497696900.lz4 So, there seems to be one ;) I'll send that to your private mail, in case there's there's some private info inthe core file. Cheers, -- Cristian
Bug#910465: makedumpfile: [INTL:pt] Updated Portuguese translation - debconf messages
A terça-feira, 16 de outubro de 2018 20:02:43 WEST você escreveu: > On Tue, Oct 16, 2018 at 11:53:50PM +0100, Américo Monteiro wrote: > > A terça-feira, 16 de outubro de 2018 18:02:00 WEST você escreveu: > > > On Sat, Oct 06, 2018 at 06:16:49PM +0100, Américo Monteiro wrote: > > > > Package: makedumpfile > > > > Version: 1_1.6.4-2 > > > > Tags: l10n, patch > > > > Severity: wishlist > > > > > > > > Updated Portuguese translation for makedumpfile's debconf messages > > > > Translator: Américo Monteiro > > > > Feel free to use it. > > > > > > > > For translation updates please contact 'Last Translator' > > > > > > Hi, Américo. > > > > > > There is already an updated translation from Rui Branco. I don't see > > > anything wrong with it. Though I am a native Portuguese speaker as well, > > > I defer to you both to decide whether any update is needed. > > > > > > Thanks. > > > Cascardo. > > > > Olá... > > > > se outra tradução existe, não a vejo: > > > > aqui > > https://www.debian.org/international/l10n/po-debconf/pt > > diz que o pacote está por traduzir e no BTS não estava nenhuma tradução > > portuguesa a aguardar inclusão, por isso lancei o meu trabalho. > > agora > > https://bugs.debian.org/cgi-bin/pkgreport.cgi? > > dist=unstable;package=makedumpfile > > está lá o meu bug report e não vejo a tradução que falas > > > > > > melhores cumprimentos > > Américo > > O bug já foi arquivado, por isso não aparece na lista. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898280 > > Não sei como é rastreada o estado de tradução de um pacote. Talvez eu > tenha omitido alguma etapa pra sinalizar que a tradução foi aplicada? > > Obrigado. > Cascardo. Olá outra vez, encontrei a tradução perdida aqui https://www.debian.org/international/l10n/po-debconf/pt_PT penso que ao empacotares meteste a tradução em pt_PT em vez de apenas pt... este pt_PT está descontinuado e já deveria ter sido removido, pois estas traduções referidas de "pt" são para português original da europa e também para os países africanos de língua portuguesa (PALOP)... o pt_BR é para o Brasil que cada vez mais se diferencia do nosso português. faz assim: ignora a minha tradução e re-empacota o teu pacote colocando a tradução do Rui em "pt" em vez de "pt_PT" e o assunto fica resolvido. Obrigado e um abraço Américo
Bug#916288: kea-dhcp4-server: Segfault after running for several minutes
Hello Burnhard, On 2018-12-15 9:02 a.m., Bernhard Übelacker wrote: Hello Anton, On Fri, 14 Dec 2018 16:34:23 -0500 Anton Avramov wrote: Hello Bernhard, Well no. I've actually installed. apt install libmariadbclient18=10.1.26-0+deb9u1 libmariadbclient18-dbgsym (gdb) display/i $pc 2: x/i $pc => 0x7479eccc : movzbl 0x451(%rax),%eax At this instruction $rax seems to contain the address stored in stmt->mysql. This address seems to be invalid in your process. And therefore accessing the options member crashes. Could you please add the output of following commands, when the crash happened: print/x $rax print stmt->mysql print stmt set print pretty on print *stmt print *stmt->mysql set print pretty off up print conn_.statements_[isc::dhcp::MySqlHostDataSourceImpl::GET_HOST_SUBID4_DHCPID] up x/6xb identifier_begin Here is the output of the requested commands: (gdb) print/x $rax $7 = 0x0 (gdb) print stmt->mysql $8 = (MYSQL *) 0x0 (gdb) print stmt $9 = (MYSQL_STMT *) 0x558f6be8 (gdb) set print pretty on (gdb) print *stmt $10 = { mem_root = { free = 0x558f6f28, used = 0x558f9cb8, pre_alloc = 0x558f6f28, min_malloc = 32, block_size = 2009, block_num = 6, first_block_usage = 0, error_handler = 0x0 }, list = { prev = 0x0, next = 0x558f2c70, data = 0x558f6be8 }, mysql = 0x0, params = 0x558f9cd0, bind = 0x558f9e20, fields = 0x558f7770, result = { data = 0x0, embedded_info = 0x0, alloc = { free = 0x558f8c88, used = 0x0, pre_alloc = 0x558f8c88, min_malloc = 24, block_size = 4057, block_num = 4, first_block_usage = 0, error_handler = 0x0 }, rows = 0, fields = 0, ---Type to continue, or q to quit--- extension = 0x0 }, data_cursor = 0x0, read_row_func = 0x7479d630 , affected_rows = 18446744073709551615, insert_id = 0, stmt_id = 4269, flags = 0, prefetch_rows = 1, server_status = 2, last_errno = 2013, param_count = 3, field_count = 18, state = MYSQL_STMT_PREPARE_DONE, last_error = "Lost connection to MySQL server during query", '\000' , sqlstate = "HY000", send_types_to_server = 1 '\001', bind_param_done = 1 '\001', bind_result_done = 1 '\001', unbuffered_fetch_cancelled = 0 '\000', update_max_length = 0 '\000', extension = 0x558e7948 } (gdb) print *stmt->mysql Cannot access memory at address 0x0 (gdb) set print pretty off (gdb) up #1 0x77a9ed19 in isc::dhcp::MySqlHostDataSourceImpl::getHostCollection (this=0x558d6840, stindex=isc::dhcp::MySqlHostDataSourceImpl::GET_HOST_SUBID4_DHCPID, bind=0x7fffd340, exchange=..., result=std::vector of length 0, capacity 0, single=true) at ../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:2262 2262 ../../../../src/lib/dhcpsrv/mysql_host_data_source.cc: Няма такъв файл или директория. (gdb) print conn_.statements_[isc::dhcp::MySqlHostDataSourceImpl::GET_HOST_SUBID4_DHCPID] $11 = (st_mysql_stmt *) 0x558f6be8 (gdb) up #2 0x77a9f540 in isc::dhcp::MySqlHostDataSourceImpl::getHost (this=0x558d6840, subnet_id=@0x7fffd8ac: 1, identifier_type=@0x55883830: isc::dhcp::Host::IDENT_HWADDR, identifier_begin=0x55834300 "\b", identifier_len=6, stindex=isc::dhcp::MySqlHostDataSourceImpl::GET_HOST_SUBID4_DHCPID, exchange=...) at ../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:2345 2345 in ../../../../src/lib/dhcpsrv/mysql_host_data_source.cc (gdb) x/6xb identifier_begin 0x55834300: 0x08 0x00 0x27 0x04 0xcc 0x0e The last line should output 6 bytes showing the MAC address of the requesting client. Maybe you could check if that crash is triggered always by the same client or kind of client. Each time the identifier is different, so I would say it is not caused by a particular client. The clients are identical dhclient that is the default with debian I looked through upstream git history and commits [1] and [2] might be related: they disable automatic reconnects. No such commit seem to have reached the stretch version of kea-dhcp: ./isc-kea-1.1.0/src/lib/dhcpsrv/mysql_connection.cc:138:my_bool auto_reconnect = MLM_TRUE; Hmmm ... but if you disable autoreconnect, doesn't this means each time you restart your database server for any reason your dhcp server would become in a not working state and it would require restart also? Kind regards, Bernhard Thank you very much for all your effort. Best regards. (gdb) list libmysql.c:4134 4129 field->type, param_count); 4130 DBUG_RETURN(1); 4131} 4132 } 4133 stmt->bind_result_done= BIND_RESULT_DONE; 4134 if (stmt->mysql->options.report_data_truncation) 4135stmt->bind_result_done|= REPORT_DATA_TRUNCATION; 4136 4137 DBUG_RETURN(0); 4138} [1] https://gitlab.isc.org/isc-projects/kea/commit/9