Bug#857184: firefox: Please compile firefox with "ac_add_options --enable-alsa"
I just found out that firefox and firefox-esr are built with the --enable-alsa switch since late October 2018, i.e. since versions 62.0.3 for firefox and 60.2.2 for firefox-esr. So I am closing this... or at least I will try.
Bug#919859: linux-image-4.19.0-1-amd64: Lost wake on lan after the upgrade to 4.19
Still nothing, even after the upgrade to 4.19.37 (package linux-image-4.19.0-5-amd64) that reached unstable some days ago.
Bug#928786: eggdrop FTCBFS: multiple minor issues
Source: eggdrop Version: 1.6.21-4 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap eggdrop fails to cross build from source for two reasons: * It uses AC_RUN_IFELSE with a wrong cross guess to check whether socklen_t exists. A better solution is using AC_CHECK_TYPE here. * It insists on running eggdrop -v during build. It simply should not do that as it does not contribute to the build in any way. The attached patch fixes both. Please consider applying it. Helmut --- eggdrop-1.6.21.orig/aclocal.m4 +++ eggdrop-1.6.21/aclocal.m4 @@ -240,33 +240,16 @@ dnl AC_DEFUN([EGG_CHECK_SOCKLEN_T], [ - AC_CACHE_CHECK([for socklen_t], egg_cv_socklen_t, [ -AC_RUN_IFELSE([AC_LANG_PROGRAM([[ + AC_CHECK_TYPE([socklen_t],[ +AC_DEFINE(HAVE_SOCKLEN_T, 1, [Define to 1 if you have the `socklen_t' type.]) + ],,[[ #include #include #include #include #include #include -]],[[ -socklen_t test = 55; - -if (test != 55) - return(1); - -return(0); -]])], [ - egg_cv_socklen_t="yes" -], [ - egg_cv_socklen_t="no" -], [ - egg_cv_socklen_t="cross" -]) - ]) - - if test "$egg_cv_socklen_t" = yes; then -AC_DEFINE(HAVE_SOCKLEN_T, 1, [Define to 1 if you have the `socklen_t' type.]) - fi + ]]) ]) --- eggdrop-1.6.21.orig/Makefile.in +++ eggdrop-1.6.21/Makefile.in @@ -205,9 +205,6 @@ modules: modtest @cd src/mod && $(MAKE_MODULES) modules @echo "" - @echo "Test run of ./eggdrop -v:" - @$(egg_test_run) - @echo "" @echo "Eggdrop successfully compiled:" @ls -l $(EGGEXEC) @echo "" @@ -323,8 +320,6 @@ exit 1; \ fi @echo "" - @$(egg_test_run) - @echo "" @echo "Installing in directory: '$(DEST)'." @echo "" @if test ! -d $(DEST); then \
Bug#928766: unblock: calibre/3.39.1+dfsg-3
Hi Norbert, On 11-05-2019 02:20, Norbert Preining wrote: [...] >> (Maybe you want to reconsider the severity of the bug you closed). [...] > Do you propose that I raise severity now post-mortem? It would make things more obvious when people check later, so if you don't mind, yes. Paul signature.asc Description: OpenPGP digital signature
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
Works very well. But how comes that this report has been marked as fixed? Its not fixed, it has just been moved out of sight to experimental to avoid a decision. :-( Sorry to say, but other distros are better in fixing bugs. Regards Harri
Bug#928784: wm2 FTCBFS: uses the build architecture compiler
Source: wm2 Version: 4+svn20090216-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap wm2 fails to cross build from source, because it uses the build architecture compiler. Using dh_auto_build doesn't fix that, because it uses a non-standard variable CCC to identify the C++ compiler. After renaming it, wm2 cross builds. Please consider applying the attached patch. Helmut diff --minimal -Nru wm2-4+svn20090216/debian/changelog wm2-4+svn20090216/debian/changelog --- wm2-4+svn20090216/debian/changelog 2019-01-27 20:08:55.0 +0100 +++ wm2-4+svn20090216/debian/changelog 2019-05-11 06:38:50.0 +0200 @@ -1,3 +1,12 @@ +wm2 (4+svn20090216-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Let dh_auto_build pass cross tools to make. ++ Rename C++ compiler to CCC. + + -- Helmut Grohne Sat, 11 May 2019 06:38:50 +0200 + wm2 (4+svn20090216-4) unstable; urgency=medium * modernize debian packaging diff --minimal -Nru wm2-4+svn20090216/debian/rules wm2-4+svn20090216/debian/rules --- wm2-4+svn20090216/debian/rules 2019-01-27 20:08:55.0 +0100 +++ wm2-4+svn20090216/debian/rules 2019-05-11 06:38:50.0 +0200 @@ -22,8 +22,8 @@ build-arch-stamp: dh_testdir # it's a C++ program, but it uses CFLAGS instead of CXXFLAGS - $(MAKE) CFLAGS='$(CXXFLAGS)' LDFLAGS='$(LDFLAGS)' \ - LIBS="-lXext -lX11" INCS='$(CPPFLAGS)' + dh_auto_build -- CFLAGS='$(CXXFLAGS)' LDFLAGS='$(LDFLAGS)' \ + LIBS="-lXext -lX11" INCS='$(CPPFLAGS)' CCC='$$(CXX)' touch build-arch-stamp clean:
Bug#928783: athena-jot FTCBFS: configures for the build architecture
Source: athena-jot Version: 9.0-7 Tags: patch User: helm...@debian.org Usertags: rebootstrap athena-jot fails to cross build from source, because it configures for the build architecture. Usually, this is fixed by using dh_auto_configure, but athena-jot already does so. As it happens, its configure is too old to understand the --host flag and needs to be told about the cross compiler via the environment. The attached patch makes athena-jot cross buildable. Please consider applying it. Helmut diff --minimal -Nru athena-jot-9.0/debian/changelog athena-jot-9.0/debian/changelog --- athena-jot-9.0/debian/changelog 2017-11-06 20:17:30.0 +0100 +++ athena-jot-9.0/debian/changelog 2019-05-11 07:06:44.0 +0200 @@ -1,3 +1,11 @@ +athena-jot (9.0-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dpkg's buildtools.mk provide a CC to ./configure. +(Closes: #-1) + + -- Helmut Grohne Sat, 11 May 2019 07:06:44 +0200 + athena-jot (9.0-7) unstable; urgency=medium * Removed autotools-dev use, now obsolete. diff --minimal -Nru athena-jot-9.0/debian/rules athena-jot-9.0/debian/rules --- athena-jot-9.0/debian/rules 2017-11-06 20:17:30.0 +0100 +++ athena-jot-9.0/debian/rules 2019-05-11 07:06:43.0 +0200 @@ -6,6 +6,9 @@ # see FEATURE AREAS in dpkg-buildflags(1) #export DEB_BUILD_MAINT_OPTIONS = hardening=+all +-include /usr/share/dpkg/buildtools.mk +export CC + %: dh $@
Bug#928785: gcc-9: cross-install-location.diff no longer applies
Source: gcc-9 Version: 9.1.0-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I noticed that cross-install-location.diff no longer applies. The attached patch fixes that. Please let me know if you'd prefer a pull request on salsa. Helmut --- a/debian/patches/cross-install-location.diff +++ b/debian/patches/cross-install-location.diff @@ -18,8 +18,8 @@ @LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = $(srcdir)/gfortran.map @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = gfortran.map-sun gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h --gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include -+gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include +-gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include ++gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ $(lt_host_flags) @@ -44,8 +44,8 @@ endif gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h --gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include -+gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include +-gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include ++gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ $(lt_host_flags)
Bug#928053: Severity of bug #928053 is too high
The severity of this bug is set too high. It is not "grave" in the context of Debian. Here is why: The Core Rule Set project explained the situation in https://coreruleset.org/20190425/regular-expression-dos-weaknesses-in-crs/ The CVEs were issues against the Regular Expression itself, not CRS running on ModSecurity. This means that ModSecurity has protection measures itself that save the WAF from this type of DoS. In the case of ModSecurity 2, it is the manual setting of the PCRE match limits that protect you and the default value is very low. ModSecurity 2 protects you from all of these RegEx weaknesses. ModSecurity 3 protects you from 4 of these 5 RegEx weaknesses. Number 5 is an issue, but only at higher Paranoia Levels which are disabled by default. Debian Stable comes wtih ModSecurity 2. Debian Testing comes with ModSecurity 3. So Debian Stable is not affected. Debian Testing is affected at PL 2 and higher. CVE-2019-11391 Not affected. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1357#issuecomment-487344464 CVE-2019-11390 Not affected. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1358#issuecomment-487344517 CVE-2019-11389 Not affected. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1356#issuecomment-487073750 CVE-2019-11388 Not affected. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1354#issuecomment-487070518 CVE-2019-11387 ModSecurity 3 and thus NGINX 3 and thus Debian Unstable is affected at Paranoia Level 2 and above. The default setting is Paranoia Level 1. -> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1359#issuecomment-487344654 The CRS project is actively solving the problems that these issues bring. However, we want to solve them without changing the behavior of the WAF that could introduce other security problems for our users. And that is very tricky. Hope this brings some clarity and you can reduce the severity of the bug until we can deliver a solution. Cheers, Christian Folini, CRS Co-Lead
Bug#852749: Bug still present, patches work on modules in kernel package 4.9.0-9
Realizing this thread is now a few years old: I had the same error (transfer buffer not dma capable, coming from usb_hcd_map_urb_for_dma) using a Line6 Pod XT through the snd-usb-pod kernel module (uses snd-usb-line6), the machine running stock kernel package 4.9.0-9. Inspecting the source, it appears the message buffers are still coming from the stack as of this kernel package. Applying Ben Hutchings' patches as of message: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852749#10 ... these moving the message buffers off the stack and adding error checks to the toneport set, doing so corrected the problem. Device is now functional; thanks much. AJM
Bug#928781: klatexformula: preview and images are cropped
Package: klatexformula Version: 4.0.0-4 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 KLaTeXFormula, recently, fails to display the entire formula in the preview with the default settings. Equations using fractions or large operators (\sum, \prod) display fine, and seem to 'expand' the window. However, this is especially problematic since it's not isolated to the preview. The output is 'cropped' in this way too when saved. In the unlikely chance it's relevant, I've included its output while running too. Warning: Failed to load translator /usr/share/qt5/translations/qtquickcontrols_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtdeclarative_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/assistant_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtlocation_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qt_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtquickcontrols2_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtquick1_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/designer_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtconnectivity_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtmultimedia_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtserialport_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtxmlpatterns_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/linguist_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtscript_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtwebengine_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtbase_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qtwebsockets_en.qm. Warning: Failed to load translator /usr/share/qt5/translations/qmlviewer_en.qm. Warning: libpng warning: iCCP: known incorrect sRGB profile Warning: libpng warning: iCCP: known incorrect sRGB profile Warning: libpng warning: iCCP: known incorrect sRGB profile Warning: libpng warning: iCCP: known incorrect sRGB profile Warning: UdevQt: unhandled device action "unbind" Warning: * In function KLFSettingsPrivate::displayUserScriptConfig() 5/10/19 9:44 PM * No value given for config widget "inkscape" Warning: libpng warning: iCCP: known incorrect sRGB profile - -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages klatexformula depends on: ii libc6 2.28-10 ii libgcc11:8.3.0-6 ii libklatexformula4 4.0.0-4 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5dbus55.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5sql5 5.11.3+dfsg1-1 ii libqt5sql5-sqlite 5.11.3+dfsg1-1 ii libqt5widgets5 5.11.3+dfsg1-1 ii libqt5xml5 5.11.3+dfsg1-1 ii libstdc++6 8.3.0-6 klatexformula recommends no packages. klatexformula suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARMIAB0WIQQd3xxna2VescxVfdXYKFckL7guMwUCXNYquQAKCRDYKFckL7gu M6d1AQDhvfVTBY4XO+T39uiJVFQB/1aoGbRX459OlPaTDyRj/QEAh44R7S0c6DiL XyOwa23aviE6njKoQ3933g3IRd9J8I8= =7C2t -END PGP SIGNATURE-
Bug#928780: bilibop-lockfs: fail to boot: mount error in case of read-only filesystem
Package: bilibop-lockfs Version: 0.5.5 Severity: important Tags: upstream A user reported me that: > After installing the package and configuring the wanted behavior over > the configuration file I have restarted my system but it ran into a > mount error. > My analysis revealed that one of my filesystems couldn't be mounted > because of the fact that the underlying tmpfs filesystem has been > mounted read-only and so the needed subdirectories ro,rw and.rw > couldn't be created to mount the different branches. The reason why > the tmpfs filesystem has been mounted read-only was the fact that the > original filesystem was marked as read-only in the fstab either. > So I have looked into the mount-helper script and I have noticed that > you apply the mount options of the original filesystem to the writable > branch and so you apply the read-only option either but this prevents > the creation of the needed subdirectories. This is reproducible. A 'ro' mount option in fstab that is applied without error when bilibop-lockfs is disabled, breaks the boot sequence (to recovery mode) when bilibop-lockfs is enabled. -- no system information -- no debconf information
Bug#928738: closed by Brian Potkin (Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)
reopen 928738 retitle 928738 Upgrading from stretch to buster leaves stretch print queue in place thanks On Fri 10 May 2019 at 16:27:14 -0500, Neil Ormos wrote: > Debian Bug Tracking System wrote: > > > This is an automatic notification regarding your Bug report > > which was filed against the printer-driver-cups-pdf package: > > > #928738: printer-driver-cups-pdf Still Produces PDF Files that Lack > > Searchable Text and are Unusable with pdftotext > > > It has been closed by Brian Potkin . [...] > > > [...] Sorry, Neil, but you are not using a > > 3.0.1-5 version of cups-pdf. I have no option > > but to close this report. > > Hi Brian: The feedback and level of detail is appreciated. > 1. Thanks for the hint. I removed and reinstalled the package. Lo and > behold, > > pdftops-renderer=pdftocairo > > now appears in the report from lpoptions, "cairo" appears in the creator > field reported by pdfinfo, and the PDF file contains searchable text. Excellent. We have spent some time and effort in getting to this stage. Let us hope it holds up for some time. > 2. BEFORE removing and reinstalling, I checked dpkg -l, which reported: > > ii printer-driver-cups-pdf 3.0.1-5 amd64 printer driver > for PDF writing via CUPS > > And I also checked /var/log/dpkg.log, which included this line from > yesterday: > > 2019-05-09 16:26:18 status installed printer-driver-cups-pdf:amd64 > 3.0.1-5 > > I saw nothing in the log that suggested that the original installation > failed. > > I have no idea why the new print queue including the > pdftops-renderer=pdftocairo option was not established, as > expected, during the original installation, by the > printer-driver-cups-pdf.postinst script. I wonder if, somehow, > the old PDF queue was not fully removed when I removed the old > printer-driver-cups-pdf (2.6.1-22) package. I can reproduce your experience on unstable. Purged printer-driver-cups-pdf. Installed the stretch package and then upgraded. The stretch print queue was left intact, so the renderer option was not applied. "Skipped automatic creation of the PDF queue" was displayed onscreen. Any fix to the package is above my pay grade and is for a maintainer to deal with. I hope it can make it into buster. Many thanks, Brian.
Bug#926215: reassign 928405 to src:glibc, notfixed 926215 in 2.6~20180302-1, tagging 926215
Control: tag -1 sid buster On 2019-05-10 16:41, Santiago Vila wrote: > I don't think "found with version, fixed without version" is a good idea. The other way around means all versions prior the fixed one are buggy. > Anyway, I finally managed to close the bug. If you agree we can keep > it that way and let it to be archived. With appropriate tagging s.t. it does not show up for stretch :-) Andreas
Bug#928779: unblock: jing-trang/20151127+dfsg-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package jing-trang In #928020 it was requested to rebuild jing-trang against unicode-data 12.1.0~pre1-2. Since this only contains an arch:all package, I had to make a source upload even if without any change, as shown in the attached debdiff. unblock jing-trang/20151127+dfsg-3 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.1.0 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Samuel * x remarque qu'avec un peu de volonté, on peut faire du code de porc dans d'importe quel langage Turing-complet -+- x sur #ens-mim - codons porc -+- diff -Nru jing-trang-20151127+dfsg/debian/changelog jing-trang-20151127+dfsg/debian/changelog --- jing-trang-20151127+dfsg/debian/changelog 2019-01-04 00:16:22.0 +0100 +++ jing-trang-20151127+dfsg/debian/changelog 2019-05-10 23:14:34.0 +0200 @@ -1,3 +1,10 @@ +jing-trang (20151127+dfsg-3) unstable; urgency=medium + + * Rebuild against unicode-data 12.1.0~pre1-2 + * No source change. + + -- Samuel Thibault Fri, 10 May 2019 23:14:34 +0200 + jing-trang (20151127+dfsg-2) unstable; urgency=medium [ Samuel Thibault ]
Bug#928778: [libqt5core5a] System Qt version no longer supported upstream
Package: libqt5core5a Version: 5.7.1+dfsg-3+deb9u1 Severity: normal Tags: security X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org --- Please enter the report below this line. --- I was aware that Qt 5.6.3 (LTS) has recently reached end-of-support (2019/03/16) but I hadn't stopped to think that 5.7.1 is well past the end-point for non-Long Term Support upstream (2017/06/16) - that being the case and for Debian "Stretch" being the current *stable* version until "Buster" gets out the door in the next few months, isn't it a good idea, at least from a security and safety point of view, for Debian to upgrade to a version, such as Qt 5.9.7 which has long-term support from Qt until 2020/05/31...? --- System information. --- Architecture: Kernel: Linux 4.9.0-8-amd64 Debian Release: 9.9 500 stable security.debian.org 500 stable ftp.uk.debian.org 500 stable apt.spideroak.com 100 stretch-backports deb.debian.org --- Package information. --- Depends (Version) | Installed ===-+-== libc6 (>= 2.14) | 2.24-11+deb9u4 libdouble-conversion1(>= 2.0.0) | 2.0.1-4 libgcc1 (>= 1:3.4) | 1:6.3.0-18+deb9u1 libglib2.0-0(>= 2.22.0) | 2.50.3-2 libicu57 (>= 57.1-1~) | 57.1-6+deb9u2 libpcre16-3 (>= 2:8.35-4) | 2:8.39-3 libstdc++6 (>= 5) | 6.3.0-18+deb9u1 zlib1g (>= 1:1.1.4) | 1:1.2.8.dfsg-5 Recommends(Version) | Installed ===-+-=== qttranslations5-l10n| 5.7.1~20161021-1 Suggests (Version) | Installed ===-+-=== libthai0| 0.1.26-1 -- To mitigate against EFAIL attacks email messages will be handled only as plain text, please do not send emails in an HTML form to this recipient! signature.asc Description: OpenPGP digital signature
Bug#921600: closed by "Arnaud Rebillout" ()
On Fri, May 10, 2019 at 02:12:04AM +, Debian Bug Tracking System wrote: > > This bug was fixed upstream already, see: > - https://github.com/docker/libnetwork/pull/2343 > - https://github.com/docker/libnetwork/pull/2339#issuecomment-487207550 Unfortunately, this requires Docker 18.09.4 or newer, and even experimental has only 18.09.3. Without an update or a patch, Docker continues to use iptables-legacy, and as a consequence things still fail to work. Could you please update to a newer version or apply a patch? It's probably better to apply a patch for buster, while uploading a newer version may be appropriate for unstable or experimental. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#928777: RFP: keepass2-plugin-keepass-rpc -- The KeePassRPC plugin that needs to be installed inside KeePass in order for Kee to be able to connect your browser to your passwords
Package: wnpp Severity: wishlist * Package name: keepass2-plugin-keepassrpc Version : 1.9.0 Upstream Author : Chris Tomlinson * URL : https://github.com/kee-org/keepassrpc * License : GPL-2.0 Programming Lang: C# Description : The KeePassRPC plugin that needs to be installed inside KeePass in order for Kee to be able to connect your browser to your passwords Kee adds free, secure and easy to use password management features to your web browser which save you time and keep your private data more secure. Login automatically, never forget another password, stay in control of your passwords and improve their security. Powered by the world-renowned KeePass Password Safe. Kee is a Firefox and Chrome add-on for linking browsers to KeePass, using the KeePassRPC KeePass plugin contained within this repository. Official website with download instructions: https://www.kee.pm Community support forum: https://forum.kee.pm Download KeePassRPC from the releases page. KeePass will notify you when updates are available but it does not support automatic updates so you will need to perform the update manually. You can find instructions on the forum. KeePassRPC supports multiple clients, although the Kee web browser add-on is the most widely used. Other known uses include Thunderbird integration and integration with old web browsers such as Firefox before version 57 was released in 2017.
Bug#928776: unblock: monkeysphere/0.43-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 src:monkeysphere Please unblock package monkeysphere monkeysphere 0.43-3 resolves a grave bug in monkeysphere, which causes the monkeysphere-host import-key subcommand to fail in newly-installed buster systems (#909700, merged with #928684). The initial monkeysphere "solution" for #909700 in 0.42-1 actually just worked around the test suite failure, and failed to fix the underlying problem, which was a mistake. #928684 pointed out that the standard use of monkeysphere-host import-key on a new install of debian buster would fail. These imported patches from the upstream development branch solve the problem correctly (and revert the test suite workaround, so that it is properly tested). The debdiff is attached. unblock monkeysphere/0.43-3 Thanks for your work on fine-tuning the debian Buster release! --dkg diff --git monkeysphere_0.43-2/debian/changelog monkeysphere_0.43-3/debian/changelog index 2948c8b..f57df6d 100644 --- monkeysphere_0.43-2/debian/changelog +++ monkeysphere_0.43-3/debian/changelog @@ -1,3 +1,10 @@ +monkeysphere (0.43-3) unstable; urgency=medium + + * fix monkeysphere-host import-key (Closes: #909700) + * update GnuPG dependency + + -- Daniel Kahn Gillmor Fri, 10 May 2019 16:55:04 -0400 + monkeysphere (0.43-2) unstable; urgency=medium * Autopkgtest should cover Ed25519 as well diff --git monkeysphere_0.43-2/debian/control monkeysphere_0.43-3/debian/control index 120cca6..6db41c0 100644 --- monkeysphere_0.43-2/debian/control +++ monkeysphere_0.43-3/debian/control @@ -11,7 +11,7 @@ Build-Depends: cpio, debhelper-compat (= 12), dpkg-dev (>= 1.17.14), - gnupg (>= 2.1.11) , + gnupg (>= 2.1.17) , gnupg-agent , libassuan-dev, libcrypt-openssl-rsa-perl , @@ -31,7 +31,7 @@ Package: monkeysphere Architecture: all Depends: adduser, - gnupg (>= 2.1.11), + gnupg (>= 2.1.17), libcrypt-openssl-rsa-perl, libdigest-sha-perl, lockfile-progs | procmail, diff --git monkeysphere_0.43-2/debian/patches/0004-tests-basic-ensure-functionality-with-output-of-stan.patch monkeysphere_0.43-3/debian/patches/0004-tests-basic-ensure-functionality-with-output-of-stan.patch new file mode 100644 index 000..a8ecd8d --- /dev/null +++ monkeysphere_0.43-3/debian/patches/0004-tests-basic-ensure-functionality-with-output-of-stan.patch @@ -0,0 +1,32 @@ +From: Daniel Kahn Gillmor +Date: Fri, 10 May 2019 12:15:00 -0400 +Subject: tests/basic: ensure functionality with output of standard OpenSSH + keygen + +Our "fix" to https://bugs.debian.org/909700 in +d8fc9f284fc9a128a174b16ad19e866f1c00bc27 just avoided testing the +actual typical default output of ssh-keygen. + +While this was fair to do in tests/keytrans, where it is exercised on +pem2openpgp (which is explicitly defined as only accepting PEM input), +this is inappropriate for testing monkeysphere in general. + +So now, the test suite breaks again, but we need to provide a proper +fix. +--- + tests/basic | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tests/basic b/tests/basic +index d5c4692..72a79a6 100755 +--- a/tests/basic b/tests/basic +@@ -275,7 +275,7 @@ fi + echo + echo "##" + echo "### import host key..." +-ssh-keygen -m PEM -b 3072 -t rsa -N '' -f "$TEMPDIR"/ssh_host_rsa_key ++ssh-keygen -b 3072 -t rsa -N '' -f "$TEMPDIR"/ssh_host_rsa_key + monkeysphere-host import-key "$TEMPDIR"/ssh_host_rsa_key ssh://testhost.example + + echo diff --git monkeysphere_0.43-2/debian/patches/0005-Use-gpg-s-reworked-quick-interface-for-adding-revoki.patch monkeysphere_0.43-3/debian/patches/0005-Use-gpg-s-reworked-quick-interface-for-adding-revoki.patch new file mode 100644 index 000..201d410 --- /dev/null +++ monkeysphere_0.43-3/debian/patches/0005-Use-gpg-s-reworked-quick-interface-for-adding-revoki.patch @@ -0,0 +1,62 @@ +From: Daniel Kahn Gillmor +Date: Fri, 10 May 2019 16:18:28 -0400 +Subject: Use gpg's reworked --quick-* interface for adding/revoking uids + +This interface stabilized in GnuPG 2.1.17, so we increase our +versioned dependency. +--- + README | 2 +- + src/share/mh/add_name| 5 + + src/share/mh/revoke_name | 10 +- + 3 files changed, 3 insertions(+), 14 deletions(-) + +diff --git a/README b/README +index b47a9bf..33f5a0d 100644 +--- a/README b/README +@@ -19,7 +19,7 @@ Dependencies + + Monkeysphere depends on: + +- * GnuPG >= 2.1.11 ++ * GnuPG >= 2.1.17 + * Perl + * Perl's Crypt::OpenSSL::RSA module + * lockfile-progs or procmail's lockfile +diff --git a/src/share/mh/add_name b/src/share/mh/add_name +index f37d9df..6357284 100644 +--- a/src/share/mh/add_name b/src/share/mh/add_name +@@ -50,10 +50,7 @@ else + fi + + # execute edit-key script +-if gpg_host --export-secret-keys "$keyID" | \ +-PEM2OPENPGP_USAGE_FLAGS=authenticate \ +-"$SYSSHAREDIR/keytrans"
Bug#928738: closed by Brian Potkin (Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)
Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the printer-driver-cups-pdf package: > #928738: printer-driver-cups-pdf Still Produces PDF Files that Lack > Searchable Text and are Unusable with pdftotext > It has been closed by Brian Potkin . [...] > [...] Sorry, Neil, but you are not using a > 3.0.1-5 version of cups-pdf. I have no option > but to close this report. Hi Brian: 1. Thanks for the hint. I removed and reinstalled the package. Lo and behold, pdftops-renderer=pdftocairo now appears in the report from lpoptions, "cairo" appears in the creator field reported by pdfinfo, and the PDF file contains searchable text. 2. BEFORE removing and reinstalling, I checked dpkg -l, which reported: ii printer-driver-cups-pdf 3.0.1-5 amd64 printer driver for PDF writing via CUPS And I also checked /var/log/dpkg.log, which included this line from yesterday: 2019-05-09 16:26:18 status installed printer-driver-cups-pdf:amd64 3.0.1-5 I saw nothing in the log that suggested that the original installation failed. I have no idea why the new print queue including the pdftops-renderer=pdftocairo option was not established, as expected, during the original installation, by the printer-driver-cups-pdf.postinst script. I wonder if, somehow, the old PDF queue was not fully removed when I removed the old printer-driver-cups-pdf (2.6.1-22) package. Anyhow, thanks for the help. Best regards, --Neil Ormos
Bug#928775: debootstrap: Misleading error message on read-only /
Package: debootstrap Version: 1.0.114 Severity: minor Hello, I used deboostrap with --arch=armhf --foreign, then booted a system with the resulting rootfs. The rootfs was mounted read-only. Then starting the second stage looks as follows: I have no name!@192:/# /debootstrap/debootstrap --second-stage mknod: //test-dev-null: Read-only file system E: Cannot install into target '/' mounted with noexec or nodev I have no name!@192:/# mount -o remount,rw / / I have no name!@192:/# /debootstrap/debootstrap --second-stage I: Installing core packages... ... While the message from mknod is right, the one from deboostrap is not. Maybe this can be improved to also mention read-only rootfs as possible error? (It could even test which of the three is the actual problem.) Best regards Uwe -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.13-ptx (SMP w/24 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE 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:en (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) Versions of packages debootstrap depends on: ii wget 1.20.1-1 Versions of packages debootstrap recommends: pn arch-test ii debian-archive-keyring 2018.1 ii gnupg 2.2.12-1 Versions of packages debootstrap suggests: pn squid-deb-proxy-client pn ubuntu-archive-keyring -- no debconf information
Bug#928774: Small but significant typo
My apologies, the working kernel is: uname -a Linux allan 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux so 4.19.0-2 not -1. Sorry again, Martin
Bug#928610: unblock: node-unicode-data/0~20190414+gitbf518e99-2
Hi yadd, On Tue, 07 May 2019 17:20:42 +0200 Xavier Guimard wrote: > unblock node-unicode-data/0~20190414+gitbf518e99-2 Unblocked, thanks Paul
Bug#928334: iputils FTCBFS: Uses the build architecture compiler
On Thu, May 02, 2019 at 04:46:06PM +0700, Nguyen Van. Hieu wrote: > iputils fails to cross build from source, because it uses the build > architecture compiler. > Using "dh_auto_build" instead of "$(MAKE)" can solve this problem. > Please consider applying the attached patch. After buster is released, I plan on rewriting the entire iputils packaging. In part this is due to upstream's change of build system, but also simply because it's long overdue. So hopefully the issue is addressed naturally in that process. noah
Bug#928429: dpkg: trigger cycle postgresql-common -> sgml-base while upgrading from stretch to buster
On 2019-05-09 06:00, Guillem Jover wrote: > awaiting trigger does not help matters, I'm not entirely sure this > might not be still a problem with dpkg itself. :/ I can also reproduce the problem in stretch -> sid upgrades, so in case you need to fix dpkg I can verify that before it migrates to testing. Andreas
Bug#928774: linux-image-4.19.0-4-amd64: X server does not start with linux kernel 4.19.0-4 (as opposed to 4.19.0-1)
Package: src:linux Version: 4.19.28-2 Severity: normal Dear Maintainer, After a kernel update, my X server (and graphical login) does not start, in the /var/log/Xorg.0.log, I can see this line: [ 8.770] (EE) modeset(0): failed to set mode: Invalid argument I have not managed to find any other relevant error in any other log, unfortunately. When I select the previous version of kernel in grub, evgerything works fine, therefore I suspect a kernel driver issue. I'll be happy to provide any further info. -- Package-specific info: ** Version: Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 root=UUID=448831a9-6bf5-4e74-b471-6b31601477d7 ro quiet ** Not tainted ** Kernel log: [4.925004] pstore: crypto_comp_decompress failed, ret = -22! [4.925010] pstore: decompression failed: -22 [4.925124] pstore: crypto_comp_decompress failed, ret = -22! [4.925129] pstore: decompression failed: -22 [4.925246] pstore: crypto_comp_decompress failed, ret = -22! [4.925252] pstore: decompression failed: -22 [4.925367] pstore: crypto_comp_decompress failed, ret = -22! [4.925372] pstore: decompression failed: -22 [4.925482] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [4.925509] pstore: crypto_comp_decompress failed, ret = -22! [4.925516] pstore: decompression failed: -22 [4.928654] pstore: crypto_comp_decompress failed, ret = -22! [4.928667] pstore: decompression failed: -22 [4.928812] pstore: crypto_comp_decompress failed, ret = -22! [4.928818] pstore: decompression failed: -22 [4.928932] pstore: crypto_comp_decompress failed, ret = -22! [4.928938] pstore: decompression failed: -22 [4.929050] pstore: crypto_comp_decompress failed, ret = -22! [4.929056] pstore: decompression failed: -22 [4.929172] pstore: crypto_comp_decompress failed, ret = -22! [4.929177] pstore: decompression failed: -22 [4.929289] pstore: crypto_comp_decompress failed, ret = -22! [4.929295] pstore: decompression failed: -22 [4.929408] pstore: crypto_comp_decompress failed, ret = -22! [4.929414] pstore: decompression failed: -22 [4.929507] pstore: crypto_comp_decompress failed, ret = -22! [4.929513] pstore: decompression failed: -22 [4.931909] pstore: crypto_comp_decompress failed, ret = -22! [4.931921] pstore: decompression failed: -22 [4.931946] pstore: Registered efi as persistent store backend [4.932199] usb 1-5.2: New USB device found, idVendor=8087, idProduct=07dc, bcdDevice= 0.01 [4.932203] usb 1-5.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [4.936325] sdb: sdb1 sdb2 [4.947600] sd 2:0:0:0: [sdb] Attached SCSI disk [5.010121] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 3160, REV=0x164 [5.031157] iwlwifi :04:00.0: base HW address: e4:02:9b:38:91:f9 [5.141590] usb 1-5.3: new low-speed USB device number 6 using xhci_hcd [5.160941] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' [5.167715] iwlwifi :04:00.0 wlp4s0: renamed from wlan0 [5.180688] intel_rapl: Found RAPL domain package [5.180692] intel_rapl: Found RAPL domain core [5.257340] [drm] Initialized i915 1.6.0 20180719 for :00:02.0 on minor 0 [5.258967] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [5.259485] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6 [5.259789] snd_hda_intel :00:1b.0: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [5.266536] fbcon: inteldrmfb (fb0) is primary device [5.331452] Adding 8788988k swap on /dev/sda3. Priority:-2 extents:1 across:8788988k SSFS [5.387027] usb 1-5.3: New USB device found, idVendor=058f, idProduct=9410, bcdDevice= 1.22 [5.387031] usb 1-5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [5.387034] usb 1-5.3: Product: KB700 Kinesis Freestyle [5.387036] usb 1-5.3: Manufacturer: KINESIS FREESTYLE KB700 [5.409159] input: KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle as /devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3:1.0/0003:058F:9410.0002/input/input7 [5.423242] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) [5.466741] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line [5.466745] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [5.466748] snd_hda_codec_realtek hdaudioC0D0:hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [5.466750] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [5.466752] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0 [5.466754] snd_hda_codec_realtek hdaudioC0D0:inputs: [5.466756] snd_hda_codec_realtek hdaudioC0D0:
Bug#928658: bilibop-lockfs: Mounting /boot fails, mount.lockfs is broken
Hi,
On 08/05/2019 14:57, Alan wrote:
>
> The system fails to boot after installing bilibop-lockfs and activating it on
> a freshly installed Debian (Buster/testing).
Yes, I reproduced it.
> Please note that this was tested on a encrypted LVM created during Debian
> installation.
It doesn't matter. As said in the bug title, mount.lockfs is broken,
you're right. A test against mount path has not been updated, and fails
on buster fresh installs - it doesn't on buster upgraded from stretch.
The culprit test in the script expects /proc/${PPID}/exe points to
/bin/mount (i.e. the parent process of mount.lockfs is /bin/mount). But
on buster, /bin is a symlink to /usr/bin so the actual executable is
/usr/bin/mount instead.
The bug is fixed upstream now, and the fix will be released soon. A
quick workaround (tested) is to turn "/bin/mount" into "/usr/bin/mount"
in /lib/bilibop/lockfs_mount_helper (line 58).
Thank you for the report,
quidame
signature.asc
Description: OpenPGP digital signature
Bug#928771: unblock: sbd/1.4.0-18-g5e3283c-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package sbd New version contains upstream fixes for some usecases and updates package tests to work with Corosync/Pacemaker versions in buster. unblock sbd/1.4.0-18-g5e3283c-1 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru sbd-1.4.0/debian/changelog sbd-1.4.0-18-g5e3283c/debian/changelog --- sbd-1.4.0/debian/changelog 2019-01-15 09:25:28.0 +0100 +++ sbd-1.4.0-18-g5e3283c/debian/changelog 2019-05-08 10:55:44.0 +0200 @@ -1,3 +1,12 @@ +sbd (1.4.0-18-g5e3283c-1) unstable; urgency=medium + + * New upstream version 1.4.0-18-g5e3283c (Closes: #925821) + * debian/sbd.lintian-overrides: update manpage line + * debian/patches: use /run for PIDFile location + * debian/tests: update for corosync v3 + + -- Valentin Vidic Wed, 08 May 2019 10:55:44 +0200 + sbd (1.4.0-1) unstable; urgency=medium * New upstream version 1.4.0 diff -Nru sbd-1.4.0/debian/patches/pidfile-in-runstatedir.patch sbd-1.4.0-18-g5e3283c/debian/patches/pidfile-in-runstatedir.patch --- sbd-1.4.0/debian/patches/pidfile-in-runstatedir.patch 1970-01-01 01:00:00.0 +0100 +++ sbd-1.4.0-18-g5e3283c/debian/patches/pidfile-in-runstatedir.patch 2019-05-08 10:55:20.0 +0200 @@ -0,0 +1,28 @@ +Description: Use /run for PIDFile location + systemd complains if PIDFile uses /var/run +Author: Valentin Vidic +Last-Update: 2019-04-26 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/src/sbd.service.in b/src/sbd.service.in +@@ -10,7 +10,7 @@ + + [Service] + Type=forking +-PIDFile=@localstatedir@/run/sbd.pid ++PIDFile=@runstatedir@/sbd.pid + EnvironmentFile=-@CONFIGDIR@/sbd + ExecStart=@sbindir@/sbd $SBD_OPTS -p @localstatedir@/run/sbd.pid watch + ExecStop=@bindir@/kill -TERM $MAINPID +--- a/src/sbd_remote.service.in b/src/sbd_remote.service.in +@@ -8,7 +8,7 @@ + + [Service] + Type=forking +-PIDFile=@localstatedir@/run/sbd.pid ++PIDFile=@runstatedir@/sbd.pid + EnvironmentFile=-@CONFIGDIR@/sbd + ExecStart=@sbindir@/sbd $SBD_OPTS -p @localstatedir@/run/sbd.pid watch + ExecStop=@bindir@/kill -TERM $MAINPID diff -Nru sbd-1.4.0/debian/patches/series sbd-1.4.0-18-g5e3283c/debian/patches/series --- sbd-1.4.0/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ sbd-1.4.0-18-g5e3283c/debian/patches/series 2019-05-08 10:55:20.0 +0200 @@ -0,0 +1 @@ +pidfile-in-runstatedir.patch diff -Nru sbd-1.4.0/debian/sbd.lintian-overrides sbd-1.4.0-18-g5e3283c/debian/sbd.lintian-overrides --- sbd-1.4.0/debian/sbd.lintian-overrides 2019-01-15 09:12:00.0 +0100 +++ sbd-1.4.0-18-g5e3283c/debian/sbd.lintian-overrides 2019-05-08 10:55:01.0 +0200 @@ -1 +1 @@ -manpage-has-errors-from-man usr/share/man/man8/sbd.8.gz 185: warning [p 1, 8.7i]: can't break line +manpage-has-errors-from-man usr/share/man/man8/sbd.8.gz 189: warning [p 1, 8.7i]: can't break line diff -Nru sbd-1.4.0/debian/tests/control sbd-1.4.0-18-g5e3283c/debian/tests/control --- sbd-1.4.0/debian/tests/control 2019-01-15 09:12:00.0 +0100 +++ sbd-1.4.0-18-g5e3283c/debian/tests/control 2019-05-08 10:55:28.0 +0200 @@ -14,10 +14,10 @@ Restrictions: needs-root, allow-stderr, isolation-machine Tests: regression -Depends: @, pacemaker, crmsh +Depends: @ Restrictions: needs-root, isolation-machine, breaks-testbed Tests: fence-external -Depends: @, pacemaker, crmsh, fence-agents +Depends: @ Restrictions: needs-root, isolation-machine, breaks-testbed Tests: fence-agents diff -Nru sbd-1.4.0/debian/tests/fence-agents sbd-1.4.0-18-g5e3283c/debian/tests/fence-agents --- sbd-1.4.0/debian/tests/fence-agents 2019-01-15 09:12:00.0 +0100 +++ sbd-1.4.0-18-g5e3283c/debian/tests/fence-agents 2019-05-08 10:55:28.0 +0200 @@ -14,21 +14,24 @@ LOOP=$(losetup --find --show $DISK) echo "=== create ===" +hostname node1 # must match corosync for fence to work sbd -d $LOOP create -echo "SBD_OPTS='-d $LOOP -W -W'" > /etc/default/sbd +sed -i "s|^#\\?\\(SBD_DEVICE=\\).*|\\1$LOOP|" /etc/default/sbd +sed -i "s|^\\(SBD_WATCHDOG_DEV=\\).*|\\1/dev/null|" /etc/default/sbd echo "=== cluster ===" -service corosync start -service pacemaker start -sleep 60 +apt-get --yes --quiet install pacemaker crmsh fence-agents service sbd status -crm status -echo "=== crm ===" -HOSTNAME=$(uname -n) -crm configure primitive sbd stonith:fence_sbd params devices=$LOOP plug=$HOSTNAME sbd_path=/usr/sbin/sbd +echo -n "Waiting for cluster to start... " +for x in `seq 60 -1 1`; do echo -n "$x "; sleep 1; done; echo +crm
Bug#928773: nabi FTCBFS: uses the wrong pkg-config
Source: nabi Version: 1.0.0-3 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap nabi fails to cross build from source, because it looks up pkg-config using AC_PATH_PROG. A better solution is to use PKG_PROG_PKG_CONFIG, but since it uses PKG_CHECK_MODULES, this is AC_REQUIREd already. We can simply drop the AC_PATH_PROG at no loss of functionality and fix the cross build. Please consider applying the attached patch. Helmut --- nabi-1.0.0.orig/configure.ac +++ nabi-1.0.0/configure.ac @@ -39,8 +39,6 @@ case $X_PRE_LIBS in esac dnl Checks for GTK+ libraries. -AC_PATH_PROG(PKG_CONFIG, pkg-config, - AC_MSG_ERROR([nabi needs pkg-config])) PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.4.0,, AC_MSG_ERROR([nabi needs GTK+ 2.4.0 or higher]))
Bug#928770: sqlite3: CVE-2019-5018: Window Function Remote Code Execution Vulnerability
Source: sqlite3 Version: 3.27.2-2 Severity: grave Tags: security Justification: user security hole Hi, The following vulnerability was published for sqlite3. CVE-2019-5018[0]: Window Function Remote Code Execution Vulnerability The issue must have been fixed upstream around 2019-03-28, but no upstream fixing commit is referenced at [1]. 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-2019-5018 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5018 [1] https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0777 Regards, Salvatore
Bug#928772: libodb-mysql FTCBFS: uses the wrong pkg-config
Source: libodb-mysql Version: 2.4.0-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap libodb-mysql fails to cross build from source, because debian/rules hard codes the wrong pkg-config. The attached patch fixes that and makes libodb-mysql cross buildable. Please consider applying it. Helmut diff --minimal -Nru libodb-mysql-2.4.0/debian/changelog libodb-mysql-2.4.0/debian/changelog --- libodb-mysql-2.4.0/debian/changelog 2019-01-15 21:20:59.0 +0100 +++ libodb-mysql-2.4.0/debian/changelog 2019-05-10 20:48:54.0 +0200 @@ -1,3 +1,10 @@ +libodb-mysql (2.4.0-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dpkg's buildtools.mk supply pkg-config. (Closes: #-1) + + -- Helmut Grohne Fri, 10 May 2019 20:48:54 +0200 + libodb-mysql (2.4.0-4) unstable; urgency=medium * Fix FTBFS with recent MariaDB (closes: #919374). diff --minimal -Nru libodb-mysql-2.4.0/debian/rules libodb-mysql-2.4.0/debian/rules --- libodb-mysql-2.4.0/debian/rules 2019-01-15 21:20:59.0 +0100 +++ libodb-mysql-2.4.0/debian/rules 2019-05-10 20:48:53.0 +0200 @@ -4,10 +4,10 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 -DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) -DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +-include /usr/share/dpkg/buildtools.mk +PKG_CONFIG ?= pkg-config -DEB_CPPFLAGS_MAINT_APPEND=`pkg-config --cflags mysqlclient` +DEB_CPPFLAGS_MAINT_APPEND=`$(PKG_CONFIG) --cflags mysqlclient` DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk
Bug#927348: unblock: salt/2018.3.4+dfsg1-2
Control: tags -1 moreinfo Hi Benjamin, On 06-05-2019 12:47, Benjamin Drung wrote: > Am Donnerstag, den 02.05.2019, 21:05 +0200 schrieb Paul Gevers: >> Control: tags -1 moreinfo >> >> Hi Benjamin, >> >> On Thu, 18 Apr 2019 13:01:31 +0200 Benjamin Drung >> wrote: >>> This version fixes the test_xen_virtual test case (bug #922352) and >>> exposes tornado4 as tornado for zmq.eventloop.ioloop (bug #924763). >>> Our >>> salt 2018.3.3+dfsg1-1 package introduced a big patch to use >>> python3-tornado4 (instead of python3-tornado) due to missing >>> support for >>> tornado version 5. Without the fix for #924763, >>> zmq.eventloop.ioloop >>> will import tornado version 5 (if python3-tornado is installed). >> >> Both bugs have severity normal. Do you really want to bother now or >> is the severity not correct (then please fix that and elaborate)? > > Bug #922352 can cause a build failure (and does on Ubuntu). Therefore I > raised it to serious. > > Determining the severity of bug #924763 is more complicated. The > reporter stumbled over a warning spit out by salt. The warning message > by itself is more or less harmless, but the underlying problem of the > wrong import might have bad effects. I haven't seen any yet, but they > might be there. IMO we shouldn't release salt with an issue introduced > by one of our patches. Ack. >>> I also included fix-various-spelling-mistakes.patch which fixes >>> several >>> spelling mistakes. Because this patch file is long, I excluded it >>> from the >>> attached debdiff. >> >> Bugs can be introduced that way. I am not going to review that diff, >> fixing spelling mistakes at this moment isn't appropriate unless >> these mistakes are crucial somewhere. > > I can drop that patch again when this is the only blocker for getting > the unblock request accepted. Please do. [...] >> You didn't even elaborate on all the (at this phase of the release >> inappropriate) changes to the packaging. There is even a newer >> version >> than the one you already mention in a follow up in this bug. > > Which changes to the packaging do you refer to? The once you discuss below. > Running the tests with LC_ALL=C.UTF-8 fixes a build failure in case the > building machine uses an ANSII locale, which would be worth another RC > bug report. Ack. > Upload 2018.3.4+dfsg1-3 repairs the documentation in salt-doc. It > ensures that the pre-built minified Javascript and CSS files are not > leaked into the salt-doc binary package and that all created symlink > are correct. Before this version, salt-doc contained broken symlinks > and the search did not work. I am very uncomfortable with these changes at this moment. > systemd 241 broke salt. Upload 2018.3.4+dfsg1-4 fixes that. There were > no bug report opened for it, but it would be worth one RC bug. Ack. > The newly opened RC bug #928337 was fixed in 2018.3.4+dfsg1-5. Ack. So, all in all, I don't want to unblock the new upstream with your packaging, we're too late in the cycle and the version really doesn't match the freeze policy. However, I am offering you an upload based on the version currently in buster via t-p-u. If you go that route, please only fix bugs 919849, 928337, 922352, 924763, the LC_ALL=C.UTF-8 item and the systemd issue. Please fix 919849 without switching your build to sphinxdoc, that isn't appropriate at this moment. You can remove the moreinfo tag when you either have a debdiff ready, or if your confident, uploaded to buster. Paul signature.asc Description: OpenPGP digital signature
Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext
Brian Potkin wrote: > Neil Ormos wrote: >> Package: printer-driver-cups-pdf >> Version: 3.0.1-5 >> Severity: important >> Dear Maintainer, >> In prior bug reports, users complained that >> CUPS-PDF or printer-driver-cups-pdf produced >> PDF files in which text was represented in >> image format, or was not searchable. [...] >> I have installed >> printer-driver-cups-pdf_3.0.1-5 (the current >> version distributed in Buster), and it appears >> that *whatever* is stored in the PDF files >> produced by printer-driver-cups-pdf, it's not >> searchable text. Also, when these files are >> processed by pdftotext, the results do not >> contain recognizable text. [...] > Thank you for your report, Neil. Hi Brian: > Please post the output of 'lpoptions -p PDF' copies=1 device-uri=cups-pdf:/ finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info=PDF printer-is-accepting-jobs=true printer-is-shared=false printer-location printer-make-and-model='Generic CUPS-PDF Printer' printer-state=3 printer-state-change-time=1557509283 printer-state-reasons=none printer-type=10678348 printer-uri-supported=ipp://localhost/printers/PDF > and, for a printed HTML > page, what 'pdfinfo gives. Results of pdfinfo on the file produced on a system running Stretch: Title: (file:///home/uuu/zzz-scratch-0510-2/foo1.html) Author: (uuu) Creator:GPL Ghostscript 926 (ps2write) Producer: GPL Ghostscript 9.26 CreationDate: Fri May 10 12:28:03 2019 CDT ModDate:Fri May 10 12:28:03 2019 CDT Tagged: no UserProperties: no Suspects: no Form: none JavaScript: no Pages: 1 Encrypted: no Page size: 612 x 792 pts (letter) Page rot: 0 File size: 12485 bytes Optimized: no PDF version:1.4 Results of pdfinfo on the file produced on a system running Squeeze: Title: file:///home/uuu/zzz-scratch-0510-4/foo1.html Producer: pdftopdf CreationDate: Fri May 10 12:31:43 2019 CDT ModDate:Fri May 10 12:31:43 2019 CDT Tagged: no UserProperties: no Suspects: no Form: none JavaScript: no Pages: 1 Encrypted: no Page size: 612 x 792 pts (letter) Page rot: 0 File size: 8922 bytes Optimized: no PDF version:1.3 Best regards, --Neil Ormos
Bug#910298: RFP: tmate-slave -- tmate-slave is the server side part of tmate.
Control: retitle 910298 RFP: tmate-ssh-server -- server side part of tmate On 2018-10-04 17:10:07, Varac wrote: > * Package name: tmate-slave > Version : 1.8 > Upstream Author : ? > * URL : https://github.com/tmate-io/tmate-slave Project was renamed to: https://github.com/tmate-io/tmate-ssh-server/ > * License : OpenBSD ? I took a look and the COPYRIGHT file declares the package as "ISC": https://opensource.org/licenses/ISC ... but then explicitely states the obvious: "THIS IS FOR INFORMATION ONLY, CODE IS UNDER THE LICENCE AT THE TOP OF ITS FILE." ... which brings us to a nice decopy run: Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Files: * Copyright: 2010-2013, Dagobert Michelsen 2011-2012, George Nachman 2003-2004, Henning Brauer 1995, International Business Machines, Inc 1996-1998, Internet Software Consortium 2015, Joerg Jung 2009, Jonathan Alvarado 2009, Joshua Elsasser 2011, Marcel P. Partap 2006-2015, Nicholas Marriott 2009, Nicholas Marriott 2008, Otto Moerbeek 2003, Peter Stuge 2006-2007, Pierre-Yves Ritschard 2006-2008, Reyk Floeter 2010, Romain Francoise 2004, Ted Unangst and Todd Miller 2013, Thiago de Arruda 2012, Thomas Adam 2008-2009, Tiago Cunha 2014, Tiago Cunha 1998-2005, Todd C. Miller 2009, Todd Carson their authors unless otherwise License: ISC Files: .mailmap .travis.yml CHANGES Dockerfile FAQ Makefile.am README README.md SYNCING TODO autogen.sh configure.ac create_keys.sh example_tmux.conf install_libssh_travis.sh install_msgpack_travis.sh monitor/* presentations/* tmate-daemon-decoder.c tmate-daemon-encoder.c tmate-daemon-legacy.c tmate-debug.c tmate-main.c tmate-msgpack.c tmate-protocol.h tmate-proxy.c tmate-ssh-client-pty.c tmate-ssh-daemon.c tmate-ssh-exec.c tmate-ssh-latency.c tmate-ssh-server.c tmate.h tools/* window-copy.h xmalloc.c xmalloc.h Copyright: 1995, Espoo, Finland 1995, Tatu Ylonen License: ISC Comment: No explicit license found, using license(s) from: COPYING Files: logo/* Copyright: 2000-2004, Apple Computer Incorporated License: ISC Comment: No explicit license found, using license(s) from: logo/LICENSE Files: compat/bitstring.h compat/daemon.c compat/getopt.c compat/queue.h compat/strcasestr.c compat/strsep.c compat/unvis.c compat/vis.c compat/vis.h Copyright: 1987-1994, The Regents of the University of California License: BSD-3-clause Files: compat/fparseln.c Copyright: 1997, Christos Zoulas License: BSD-4-clause Files: compat/tree.h Copyright: 2002, Niels Provos License: BSD-2-clause Files: logo/LICENSE Copyright: 2015, Jason Long License: ISC License: BSD-2-clause Comment: Add the corresponding license text here License: BSD-3-clause Comment: Add the corresponding license text here License: BSD-4-clause Comment: Add the corresponding license text here License: ISC Comment: Add the corresponding license text here ... which confirms it's mostly ISC with some bits of BSD in there. It otherwise seems like a fairly standard autotools kind of thing. Did anyone audit that code in any shape? At first glance it looks a little worrisome: it sure seems to me like it copies the entire tmux source code inside of there. For example, here's cmd.c in tmate-server: https://github.com/tmate-io/tmate-ssh-server/blob/master/cmd.c and tmux: https://github.com/tmux/tmux/blob/master/cmd.c I filed this as a bug in: https://github.com/tmate-io/tmate-ssh-server/issues/59 They also do not seem to be issuing new releases anymore: https://github.com/tmate-io/tmate-ssh-server/issues/33 It also looks like tmate-server needs to be running as root, even if running on a non-privileged port: https://github.com/tmate-io/tmate-ssh-server/issues/40 So, long story short, a bit of a mess? :) A. -- What this country needs is more unemployed politicians. - Angela Davis
Bug#928768: RFP: node-evacuated-buffered-spawn -- Buffered child_process
Package: wnpp Severity: wishlist * Package name: node-evacuated-buffered-spawn Version : 3.3.2 Upstream Author : IndigoUnited (http://indigounited.com) * URL : http://mpoj2jpjwpg6kujuacpjircdmiaedpatewdprjd5gkzuoub7hij263ad.onion/ * License : MIT Programming Lang: javascript Description : Buffered child_process This is a branch of buffered-spawn outside of the NSA/Microsoft walled garden. buffered-spawn is a nodejs tool which is similar to nodejs' 'spawn' but which supports callback & promise style calls. It is a prerequisite for node-evacuated-ethereum-client-binaries ( #928697 ).
Bug#928756: debian-edu-config: search domain not configured correctly on diskless workstations in subnet00
Hi, > Thanks for providing the screenshot. It's a special case to have fixed > IPs in this subnet. If you untick DNS it is supposed to work. But then I don't get a resolvable, fixed hostname, right? That was the whole idea behind adding the hosts: Have them limited to PXE booting, but still get readable hostnames in logs and for SSH access. I will still test without DNS. -nik signature.asc Description: PGP signature
Bug#928334: iputils FTCBFS: Uses the build architecture compiler
Control: forcemerge 648033 928334 Hi, On Thu, May 02, 2019 at 04:46:06PM +0700, Nguyen Van. Hieu wrote: > iputils fails to cross build from source, because it uses the build > architecture compiler. > Using "dh_auto_build" instead of "$(MAKE)" can solve this problem. > Please consider applying the attached patch. Thank you for working on cross building. Unfortunately, this issue is already reported. Merging the bugs. Your patch looks good to me, though I suggest that you prefer dh_auto_build --sourcedirectory=foo -- ... over dh_auto_build -- -C foo ... Helmut
Bug#928767: pip regression
Package: python-pip
Hello,
Debian version : 9.9
probable package : python-pip 9.0.1-2+deb9u1
I detected that since some days the install of package with pip fail
randomly with this stacktrace:
Collecting Pillow
Downloading
https://files.pythonhosted.org/packages/b6/4b/5adc1109908266554fb978154c797c7d71aba43dd15508d8c1565648f6bc/Pillow-6.0.0-cp27-cp27mu-manylinux1_x86_64.whl
(2.0MB)
Collecting moviepy<1.0
Downloading
https://files.pythonhosted.org/packages/1f/af/98b68b047c47d9430cb4c9ac899cf9d969de3936f888072991ea74da93a8/moviepy-0.2.3.5.tar.gz
(372kB)
Collecting decorator<5.0,>=4.0.2 (from moviepy<1.0)
Downloading
https://files.pythonhosted.org/packages/5f/88/0075e461560a1e750a0dcbf77f1d9de775028c37a19a346a6c565a257399/decorator-4.4.0-py2.py3-none-any.whl
Collecting imageio<3.0,>=2.1.2 (from moviepy<1.0)
Downloading
https://files.pythonhosted.org/packages/69/4a/0387d708394d5e25d95b1abe427c301614152d1bebea18d9b06fa7199704/imageio-2.5.0.tar.gz
(3.3MB)
Collecting numpy (from moviepy<1.0)
Downloading
https://files.pythonhosted.org/packages/e1/72/179a78b565ecf01fe98dab6417581d30acac15c2d93c49f93169ebea99b1/numpy-1.16.3-cp27-cp27mu-manylinux1_x86_64.whl
(17.0MB)
Collecting tqdm<5.0,>=4.11.2 (from moviepy<1.0)
Exception:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 215,
in main
status = self.run(options, args)
File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line
353, in run
wb.build(autobuilding=True)
File "/usr/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
self.requirement_set.prepare_files(self.finder)
File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 380,
in prepare_files
ignore_dependencies=self.ignore_dependencies))
File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 554,
in _prepare_file
require_hashes
File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line
278, in populate_link
self.link = finder.find_requirement(self, upgrade)
File "/usr/lib/python2.7/dist-packages/pip/index.py", line 465, in
find_requirement
all_candidates = self.find_all_candidates(req.name)
File "/usr/lib/python2.7/dist-packages/pip/index.py", line 423, in
find_all_candidates
for page in self._get_pages(url_locations, project_name):
File "/usr/lib/python2.7/dist-packages/pip/index.py", line 568, in
_get_pages
page = self._get_page(location)
File "/usr/lib/python2.7/dist-packages/pip/index.py", line 683, in
_get_page
return HTMLPage.get_page(link, session=self.session)
File "/usr/lib/python2.7/dist-packages/pip/index.py", line 792, in
get_page
"Cache-Control": "max-age=600",
File
"/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/sessions.py",
line 501, in get
return self.request('GET', url, **kwargs)
File "/usr/lib/python2.7/dist-packages/pip/download.py", line 386, in
request
return super(PipSession, self).request(method, url, *args, **kwargs)
File
"/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/sessions.py",
line 488, in request
resp = self.send(prep, **send_kwargs)
File
"/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/sessions.py",
line 630, in send
history = [resp for resp in gen] if allow_redirects else []
File
"/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/sessions.py",
line 190, in resolve_redirects
**adapter_kwargs
File
"/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/sessions.py",
line 609, in send
r = adapter.send(request, **kwargs)
File
"/usr/share/python-wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/adapter.py",
line 47, in send
resp = super(CacheControlAdapter, self).send(request, **kw)
File
"/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/adapters.py",
line 423, in send
timeout=timeout
File
"/usr/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/connectionpool.py",
line 643, in urlopen
_stacktrace=sys.exc_info()[2])
File
"/usr/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/util/retry.py",
line 315, in increment
total -= 1
After some research I found that this patch have been applied to pip :
https://sources.debian.org/patches/python-pip/9.0.1-2+deb9u1/Properly_catch_requests_HTTPError_in_index.py.patch/
I suspect that this patch break something.
I discovered this bug with the Yunohost CI
(https://ci-apps-hq.yunohost.org/jenkins/job/synapse_ynh%20PR122/1/console)
because since some days many test fail with some Yunohost apps. And if
this error happens the test fail.
0x716A6C99B04194EF.asc
Description: application/pgp-keys
0x716A6C99B04194EF.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Bug#928756: debian-edu-config: search domain not configured correctly on diskless workstations in subnet00
On Fri, May 10, 2019 at 03:10:22PM +0200, Dominik George wrote: > 1. Install a combined server like normal. > 2. Add a machine on the LTSP network 192.168.0.0/32 as in the screenshot. Thanks for providing the screenshot. It's a special case to have fixed IPs in this subnet. If you untick DNS it is supposed to work. Please test. Wolfgang signature.asc Description: PGP signature
Bug#928766: unblock: calibre/3.39.1+dfsg-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package calibre
Upgrade tests showed that the switch from hand-written *.pyc (compiled
python files) cleanup to pyclean trigger an error when upgrading from
an old version, in particular from current stable to current testing.
This happens only if calibre is once started as root, so I never tested
this one. When starting as root, python files under
/usr/lib/calibre/
will be compiled to .pyc files, which were NOT shipped in old versions
(current stable).
Then, after upgrade from stable to testing, these .pyc files are not
properly removed, in particular the .pyc files in
/usr/lib/calibre/regex
which is a directory that disappears.
To deal with this special case, I added postinst code that checks
whether we are updating from one of the affected versions, and in the
respective case manually purges .pyc (and .pyo) files and remove the
regex directory.
If this is not done, calibre fails to start as shown in #865879
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865879
The debdiff is
diff -Nru calibre-3.39.1+dfsg/debian/calibre.postinst
calibre-3.39.1+dfsg/debian/calibre.postinst
--- calibre-3.39.1+dfsg/debian/calibre.postinst 2019-02-08 17:41:17.0
+0900
+++ calibre-3.39.1+dfsg/debian/calibre.postinst 2019-05-10 11:47:37.0
+0900
@@ -2,6 +2,29 @@
set -eu
+#
+# deal with .py[co] files that are left overs from pre-pycompile switch
+# since we drop regexp etc files
+
+case "$1" in
+ configure|reconfigure)
+
+ old_version=$2
+
+ if [ -n "$old_version" ] && dpkg --compare-versions "$old_version" lt
"3.4.0+dfsg-2"; then
+find /usr/lib/calibre -name \*.pyc -o -name \*.pyo | while read file ; do
+ rm "${file}"
+done
+# regex directory was there but disappeared, try to remove it
+# now that all the pyc files should be gone.
+if [ -d /usr/lib/calibre/regex ] ; then
+ rmdir /usr/lib/calibre/regex
+fi
+ fi
+ ;;
+esac
+
+
if which pycompile >/dev/null 2>&1; then
pycompile -p calibre /usr/lib/calibre -V 2.7-2.9
fi
diff -Nru calibre-3.39.1+dfsg/debian/changelog
calibre-3.39.1+dfsg/debian/changelog
--- calibre-3.39.1+dfsg/debian/changelog2019-02-08 17:41:17.0
+0900
+++ calibre-3.39.1+dfsg/debian/changelog2019-05-10 11:47:37.0
+0900
@@ -1,3 +1,9 @@
+calibre (3.39.1+dfsg-3) unstable; urgency=medium
+
+ * remove .pyc files on upgrade from pre-pyclean versions (Closes: #865879)
+
+ -- Norbert Preining Fri, 10 May 2019 11:47:37 +0900
+
calibre (3.39.1+dfsg-2) unstable; urgency=medium
* update my email and VCS fields (Closes: #921473)
Thanks for considering
Norbert
unblock calibre/3.39.1+dfsg-3
-- System Information:
Debian Release: 10.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.1.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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)
Bug#928765: distcc: Does not install or uninstall on Squeeze
Package: distcc Version: 3.3.2-9 Severity: important This lintian warning describes the problem: https://lintian.debian.org/tags/skip-systemd-native-flag-missing-pre-depends.html Thanks, Your upstream, Shawn Landden -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ppc64el (ppc64le) Kernel: Linux 4.9.0-3-powerpc64le (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages distcc depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.72 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libc6 2.28-10 ii libgssapi-krb5-2 1.17-2 ii libpopt0 1.16-12 ii lsb-base 10.2019031300 ii netbase5.6 distcc recommends no packages. Versions of packages distcc suggests: pn ccache ii dbus 1.12.12-1 pn distcc-pump pn distccmon-gnome pn dmucs -- debconf information: distcc/daemon-allow: 127.0.0.1 distcc/daemon-jobs: distcc/daemon-nice: 10 distcc/daemon-zeroconf: false distcc/daemon-listen: 127.0.0.1 distcc/daemon: false
Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext
On Thu 09 May 2019 at 18:05:51 -0500, Neil Ormos wrote: > Package: printer-driver-cups-pdf > Version: 3.0.1-5 > Severity: important > > Dear Maintainer, > > In prior bug reports, users complained that CUPS-PDF or > printer-driver-cups-pdf produced PDF files in which text was > represented in image format, or was not searchable. > > In a message posted > > "Thu, 09 Mar 2017 13:40:21 +", > > closing bugs 658004, 813618, 847462, and 857165, there was a reference > to printer-driver-cups-pdf_3.0.1-3, and in another message there was a > suggestion that the problem is fixed in that version. > > I have installed printer-driver-cups-pdf_3.0.1-5 (the current version > distributed in Buster), and it appears that *whatever* is stored in > the PDF files produced by printer-driver-cups-pdf, it's not searchable > text. Also, when these files are processed by pdftotext, the results > do not contain recognizable text. > > This was not a problem with the cups-pdf version 2.5.0-16 in Squeeze. > > I tested using Firefox 44.0b3 to print an extremely simple HTML page > to the CUPS PDF "driver". (That particular ancient version of Firefox > runs in both Squeeze and Stretch.) > > Can this be fixed, short of installing a non-Debian version of > CUPS-PDF-to-PDF or the like, such as that advertised at > > https://github.com/alexivkin/CUPS-PDF-to-PDF > > ? Thank you for your report, Neil. Please post the output of 'lpoptions -p PDF' and, for a printed HTML page, what 'pdfinfo gives. Regards, Brian.
Bug#928764: alsa-utils does not store or restore configuration
Package: alsa-utils Version: 1.1.8-2 Severity: important Dear Maintainer, At each start of the computer the sound function is absent so that it works the only method that I found is to launch in a window the alsamixer program and to modify a parameter and the sound is restored,the most surprising is that the parameters previously saved by alsamixer are present. -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages alsa-utils depends on: ii dialog1.3-20190211-1 ii kmod 26-1 ii libasound21.1.8-1 ii libc6 2.28-10 ii libfftw3-single3 3.3.8-2 ii libncursesw6 6.1+20181013-2 ii libsamplerate00.1.9-2 ii libtinfo6 6.1+20181013-2 ii lsb-base 10.2019031300 ii whiptail 0.52.20-8 alsa-utils recommends no packages. alsa-utils suggests no packages. -- no debconf information
Bug#928763: ITP: r-other-wasabi -- prepare Sailfish and Salmon output for downstream analysis using GNU R
Package: wnpp Severity: wishlist Subject: ITP: r-other-wasabi -- prepare Sailfish and Salmon output for downstream analysis using GNU R Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-other-wasabi Version : 1.0.0 Upstream Author : Richard Smith-Unna, Rob Patro * URL : https://github.com/COMBINE-lab/wasabi * License : BSD-3-clause Programming Lang: GNU R Description : prepare Sailfish and Salmon output for downstream analysis using GNU R This GNU R package converts the output of the Sailfish and Salmon RNA-seq quantification tools so that it can be used with the Sleuth differential analysis package. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-other-wasabi
Bug#918522: No sound with PulseAudio when an NVidia GPU is installed - workaround
On Tue, 15 Jan 2019 21:11:58 -0300 Felipe Sateler wrote: > The log says: > > module-udev-detect.c: /devices/pci:00/:00:1b.0/sound/card0 is > busy: yes > > Some other program appears to be holding the device busy. Common > culprits include espeakup and timidity. You can further inspect with: > > sudo lsof /dev/snd/* Thank you so much for this. I had the same symptoms after upgrading to Buster. Removing timidity "solved" the issue. As a default behaviour, this is pretty bad. Is this a known issue? Should this be filed as another bug somewhere? -- Jérôme
Bug#787890: segmentation fault when editing two files in two terminals
Tags: fixed Version: 2.4.3-1 Oof... I hadn't read the original report closely enough. :| You wrote "nano bar foo", not "nano foo bar". And, strangely, in this case that makes a difference. Okay, I could reproduce now (with nano-2.4.1). And it is indeed the same bug as bug #787914, and is fixed since 2.4.3. Benno
Bug#926215: reassign 928405 to src:glibc, notfixed 926215 in 2.6~20180302-1, tagging 926215
On Fri, May 10, 2019 at 03:37:51PM +0200, Andreas Beckmann wrote: > The bug is now again in the bts-is-confused state: found+fixed in the > same version (which is treated as not-fixed and wont-be-archived). My > intention was to close it as invalid (found with version, fixed without > version) + unreproducible, since it is unclear which package actually > fixed it (such that a reassign+affects could be used). I don't think "found with version, fixed without version" is a good idea. Anyway, I finally managed to close the bug. If you agree we can keep it that way and let it to be archived. Thanks.
Bug#928761: ITP: r-bioc-rhdf5 -- BioConductor HDF5 interface to R
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-rhdf5 -- BioConductor HDF5 interface to R Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-bioc-rhdf5 Version : 2.26.2 Upstream Author : Bernd Fischer, * URL : https://bioconductor.org/packages/rhdf5/ * License : Artistic-2.0 Programming Lang: GNU R Description : BioConductor HDF5 interface to R This package provides an interface between HDF5 and R. HDF5's main features are the ability to store and access very large and/or complex datasets and a wide variety of metadata on mass storage (disk) through a completely portable file format. The rhdf5 package is thus suited for the exchange of large and/or complex datasets between R and other software package, and for letting R applications work on datasets that are larger than the available RAM. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5
Bug#851774: [Bug 1754075] Re: apt-setup uses apt-key but probably should not anymore
On Mon, Apr 09, 2018 at 01:14:37PM +0200, Lars Kollstedt wrote: > On Monday, 9 April 2018 12:56:12 CEST Lars Kollstedt wrote: > [...] > > This patch should IMHO work, but I have no opportunity to test it without > > your help, since we're in udeb and testing preseed issues. ;-) > > Hi again, > > 20 times looked at it and still overlooked one detail. > > This must of course be 'echo "$comment"'. The patch looks good and works fine in my tests, so I created a salsa merge request based on your patch at https://salsa.debian.org/installer-team/apt-setup/merge_requests/1 d-i people; let me know if I can help with getting that fixed for buster (like doing the unstable upload etc.), I can reliably reproduce this with the buster test hosts we've installed at work and the apt.wikimedia.org package repo. Cheers, Moritz
Bug#882386: avahi-daemon segfaults with txt-record values ending in "="
Hi, I'm the last person who changed that code, so I think I'm to blame for the crash. I was let know about this bug, so I wrote a fix. Please see the following PR on github: https://github.com/lathiat/avahi/pull/226 I suppose you could carry this patch in the package until it gets fixed upstream. Cheers, Krzesimir
Bug#928760: nxagent switches branding when resuming
Package: nxagent Version: 2:3.5.99.19-1 Severity: important The nxagent Xserver supports running under different executable names and that triggers different configuration paths and branding features (icon, splash screen, etc.). It was discovered that nxagent switches its branding from x2goagent to nxagent when user resume a suspended X2Go Session. This is problematic, because at session startup, the x2goagent reads /etc/x2go/keystrokes.cfg. When resuming, x2goagent (now nxagent) reads /etc/nxagent/keystrokes.cfg. These files can be configured differently and leads to non-expected behaviour in resumed sessions. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgp_YTDeKruRV.pgp Description: Digitale PGP-Signatur
Bug#928759: Please update InspIRCd to v3.0.1
Package: inspircd Version: 2.0.27-1 Hello, You are shipping version 2.0.27 of InspIRCd which is now outdated as version 3.0.1 of InspIRCd was recently released. The v2 branch of InspIRCd is now only receiving security updates and will be considered EOL from 2020-01-01. Please can you update your package to this version. Regards, ~ Peter Powell, InspIRCd Maintainer
Bug#928758: mariadb-server: mysql_install_db fails if basedir option isn't set, expecting resolveip to be present in /usr/sbin/
Package: mariadb-server Version: 10.1.38-0+deb9u1 Severity: important Hi, starting with mariadb-server version 10.1.38-0+deb9u1, executing /usr/bin/mysql_install_db fails if --basedir option isn't explicitly set or configured accordingly via my.cnf: | root@prx01b:~# /usr/bin/mysql_install_db --user=mysql --datadir=/tmp/foo | Neither host 'prx01b' nor 'localhost' could be looked up with | '/usr/sbin/resolveip' | Please configure the 'hostname' command to return a correct | hostname. | If you want to solve this at a later stage, restart this script | with the --force option | | The latest information about mysql_install_db is available at | https://mariadb.com/kb/en/installing-system-tables-mysql_install_db While resolveip is present in /usr/bin (instead of /usr/sbin): | root@prx01b:~# which resolveip | /usr/bin/resolveip Whereas it works fine with `--basedir` explicitly set to /usr: | root@prx01b:~# /usr/bin/mysql_install_db --basedir=/usr | Installing MariaDB/MySQL system tables in '/var/lib/mysql' ... | 2019-05-10 15:38:34 14009176920 [Note] /usr/sbin/mysqld (mysqld 10.1.38-MariaDB-0+deb9u1) starting as process 24550 ... | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB. | | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Using mutexes to ref count buffer pool pages | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: The InnoDB memory heap is disabled | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Compressed tables use zlib 1.2.8 | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Using Linux native AIO | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Using SSE crc32 instructions | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Initializing buffer pool, size = 128.0M | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Completed initialization of buffer pool | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Highest supported file format is Barracuda. | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: 128 rollback segment(s) are active. | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Waiting for purge to start | 2019-05-10 15:38:34 14009176920 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.42-84.2 started; log sequence number 1616727 | 2019-05-10 15:38:35 140091057989376 [Note] InnoDB: Dumping buffer pool(s) not yet started This breaking change was caused by the following change in between 10.1.37-0+deb9u1 and 10.1.38-0+deb9u1 (see mariadb-10.1.git): | (git)-[debian/10.1.38-0+deb9u1] % git diff debian/10.1.37-0+deb9u1.. scripts/mysql_install_db.sh | diff --git a/scripts/mysql_install_db.sh b/scripts/mysql_install_db.sh | index 0bbac8ba8..b89ea716a 100644 | --- a/scripts/mysql_install_db.sh | +++ b/scripts/mysql_install_db.sh | @@ -39,6 +39,9 @@ install_params="" | auth_root_authentication_method=normal | auth_root_socket_user='root' | | +dirname0=`dirname $0 2>/dev/null` | +dirname0=`dirname $dirname0 2>/dev/null` | + | [...] |fi | +# relative from where the script was run for a relocatable install | +elif test -n "$dirname0" -a -x "$dirname0/@INSTALL_SBINDIR@/mysqld" | +then | + basedir="$dirname0" | + bindir="$basedir/@INSTALL_SBINDIR@" | + resolveip="$bindir/resolveip" | + mysqld="$basedir/@INSTALL_SBINDIR@/mysqld" | + srcpkgdatadir="$basedir/@INSTALL_MYSQLSHAREDIR@" | + buildpkgdatadir="$basedir/@INSTALL_MYSQLSHAREDIR@" | else |basedir="@prefix@" |bindir="@bindir@" This change is causing bindir being set to bindir=/usr/sbin, while it's supposed to be bindir=/usr/bin on Debian systems, so that resolveip is used as /usr/bin/resolveip. FTR: We're using multiple sections inside /etc/mysql/my.cnf (`[mysqld1]` and `[mysqld2]`). When adding a `mysqld` section with the following configuration to /etc/mysql/my.cnf it also works without having to explicitly specify the `--basedir` option: | [mysqld] | basedir = /usr As expected it also works in our setup when we specify the `--defaults-group-suffix` option, like: | root@prx01b:~# /usr/bin/mysql_install_db --defaults-group-suffix=1 | Installing MariaDB/MySQL system tables in '/var/lib/mysql' ... | 2019-05-10 16:00:23 139685437468032 [Note] /usr/sbin/mysqld (mysqld 10.1.38-MariaDB-0+deb9u1) starting as process 25302 ... | [] But neither of this was necessary so far, and the new mysql_install_db behavior isn't as reliable as it used to be. The directory /usr/bin should be detected and assumed as sensible default for bindir (instead of relying on the base path of the «mysqld» binary inside /usr/sbin). regards -mika-
Bug#928736: initramfs-tools: With plymouth print misleading resuming from hibernation
Control: severity -1 minor Control: tag -1 wontfix On Fri, 2019-05-10 at 00:52 +0200, Cesare Leonardi wrote: > Package: initramfs-tools > Version: 0.133 > Severity: normal > > When plymouth is installed, every time I power on my notebook the following > message is printed on the screen: > Resuming from hibernation > > But I'm not resuming from hibernation, I'm doing a regular boot from power > off. > Is it possible to show that message only when actually resuming? It's not possible to do that, because the check and resume are done by the kernel outside of our control. > Or, if it not feaseable, perhaps it's better to remove it completely. Resume from hibernation may take a long time, so it is important to show this step. If you use plymouth in graphical mode, the message is erased when resume doesn't happen. Ben. > I've verified that this message appears when RESUME=auto (my current > setup) or when a swap device is specified. It goes away with "none". -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Bug#926215: reassign 928405 to src:glibc, notfixed 926215 in 2.6~20180302-1, tagging 926215
On 2019-05-10 15:07, Santiago Vila wrote: > On Tue, 7 May 2019, Andreas Beckmann wrote: > >> reassign 928405 src:glibc 2.28-10 >> notfixed 926215 2.6~20180302-1 >> tags 926215 + unreproducible >> thanks > > Hello Andreas. Sorry, I have just marked this bug as fixed, because I > didn't realize that you had the intention to reassign it. > > The bug I submitted originally was definitely reproducible, and that's > why I wanted to close it. > > If you still want to reassign the bug, please do so (apparently The reassign was for a completely different bug. > the reassign above didn't work), but I'd like to know the rationale > for doing so. The bug is now again in the bts-is-confused state: found+fixed in the same version (which is treated as not-fixed and wont-be-archived). My intention was to close it as invalid (found with version, fixed without version) + unreproducible, since it is unclear which package actually fixed it (such that a reassign+affects could be used). Andreas
Bug#928405: reassign 928405 to src:glibc, notfixed 926215 in 2.6~20180302-1, tagging 926215
On Tue, 7 May 2019, Andreas Beckmann wrote: > reassign 928405 src:glibc 2.28-10 > notfixed 926215 2.6~20180302-1 > tags 926215 + unreproducible > thanks Hello Andreas. Sorry, I have just marked this bug as fixed, because I didn't realize that you had the intention to reassign it. The bug I submitted originally was definitely reproducible, and that's why I wanted to close it. If you still want to reassign the bug, please do so (apparently the reassign above didn't work), but I'd like to know the rationale for doing so. Thanks.
Bug#928756: debian-edu-config: search domain not configured correctly on diskless workstations in subnet00
Package: debian-edu-config Version: 2.10.64 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The following misbehaviour occurs reproducibly in a new installation of Debian Edu buster. 1. Install a combined server like normal. 2. Add a machine on the LTSP network 192.168.0.0/32 as in the screenshot. 3. Boot that machine as diskless workstation. If done like that, the /etc/resolv.conf generated at boot by ltsp-init with the information provided by 08-edu-hostname is missing a search domain entry (it should probably be subnet00.intern intern). Thus, short hostnames, like used by the default Firefox start page, are not resolvable. The configuration of the search domain works perfectly on the main network 10.0.0.0/16. I only tested on (two different) combined servers, not on a dedicated terminal server. - -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debian-edu-config depends on: ii bind9-host 1:9.11.5.P4+dfsg-1 ii cfengine33.12.1-2 ii debconf [debconf-2.0]1.5.71 ii debconf-utils1.5.71 ii debian-edu-artwork 2.10.5-1 ii desktop-profiles 1.4.30 ii e2fsprogs1.44.5-1 ii education-tasks 2.10.47 ii fping4.2-1 ii isenkram-cli 0.41 ii ldap-utils 2.4.47+dfsg-3 ii ldapscripts 2.0.8-1 ii libconfig-inifiles-perl 3.01-1 ii libfilesys-df-perl 0.92-6+b4 ii libhtml-fromtext-perl2.07-1 ii libio-socket-ssl-perl2.060-3 ii libnet-ldap-perl 1:0.6500+dfsg-1 ii libnet-netmask-perl 1.9104-1 ii libnss3-tools2:3.42.1-1 ii libpacparser11.3.6-1.1+b4 ii libpam-python1.0.6-1.1 ii libproxy1-plugin-kconfig 0.4.15-5 ii libproxy1-plugin-networkmanager 0.4.15-5 ii libproxy1-plugin-webkit 0.4.15-5 ii libterm-readkey-perl 2.38-1 ii libtext-unaccent-perl1.08-1.3+b3 ii lockfile-progs 0.1.18 ii lsb-base 10.2019031300 ii lsb-release 10.2019031300 ii mime-support 3.62 ii net-tools1.60+git20180626.aebd88e-1 ii netcat-traditional [netcat] 1.10-41.1 ii ng-utils 1.0-1+b1 ii openssl 1.1.1b-1 ii patch2.7.6-3 ii python 2.7.16-1 ii python-notify0.1.1-4 ii ssl-cert 1.0.39 ii swaks20181104.0-2 ii tftp-hpa 5.2+20150808-1+b1 ii uuid 1.6.2-1.5+b7 Versions of packages debian-edu-config recommends: ii binutils 2.31.1-15 ii libnotify-bin 0.7.7-4 ii lsof 4.91+dfsg-1 ii memtest86+ 5.01-3 pn resolvconf ii syslinux 3:6.04~git20190206.bf6db5b4+dfsg1-1 debian-edu-config suggests no packages. - -- Configuration Files: /etc/sssd/sssd-debian-edu.conf [Errno 13] Keine Berechtigung: '/etc/sssd/sssd-debian-edu.conf' - -- debconf-show failed -BEGIN PGP SIGNATURE- iQJ+BAEBCABoFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlzVeD0xGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxgcbmF0dXJl c2hhZG93QGRlYmlhbi5vcmcACgkQt5o8FqDE8pazfw//RV0gY6hiwqAj0VAnjZHQ +42aDgBSII0r/TBUFXMZjAzGSlEFivoJ366Yxcww8IbJ0fk8gCD0Pz/mdI6Vc6aj 7YeMgkbXChFPSED9PaqjeiAIY6sGl++5Y6Av3X51tsP/+lOkVH8kII5CI55Ggmk1 XY+j02jgh67mstrYZbuiX5DB/bVGuOwVY06t1FO6d8Wsi/YEP4sx7IDJL4o3Ng8b H1jiCFYWUNUt/b1dOTbUhKQS0dIuyPQp0KANQk8aXQ9/VffeypASi/XZQKwAfGF/ wB2ZwYUqtWAQ0qvYsc3WqTj6fkcSqvGc2KGm9vsT3OjfuShs6xPj5Dw0qN3WV2Hk MmlDnRhmUWS8P2y1W9ItbUXMuQ3lUYrxKbpz+E6qBqsriKRIw4KiLGViAwxftrpH fLwim9hC/VPk7bwNU7w0KSWcQfvOWYf6wre4xw3aGgxrk4fuV3i9EutPSSyRNd8m 9NzP1XJRUlghxL66JcYzisKMjKT12aenyABjy3ExOCCwpuZ6L7SWYHKwAbvNQP1b x9F/N0wyEciZ81H1S0GUdEyr5/AnohFlFLrxL7JaNg8xXE/t2JVHWWbO2iCNKbgp 8iUGrvyO8/FsF42UjexiWrNHg7hKDPBEWa4DLtpCMEjvIGEF/QIP4Q/RvBOC+vQC fdI4jtonFwurGbnWV2x5wLE= =ftWv -END PGP SIGNATURE-
Bug#425337: chmod 700 on $HOME/.nano_saved-files
Hi Benno, I don't understand the original report. What is $HOME/.nano_saved-files used for? Does Debian create this directory upon installing nano? Because as far as I know, nano itself does not create it. I'm really sorry for filing this bug. It was my mistake. I use $HOME/.nano_saved-files in "set backupdir" in .nanorc . The directory is not created automatically by nano, so I must have created it myself. But months later I had forgotten about this and was surprised that the permissions were not as I would have expected them. Kind regards, Sébastien.
Bug#928387: ping
Just in case this request was over looked because of a similar request earlier. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#928755: ITP: ytcc -- Youtube channel checker
Package: wnpp Severity: wishlist ytcc is a command Line tool to keep track of your favourite YouTube channels without signing up for a Google account. ytcc manages your defined channels and lets you update, view (with mpv), download videos while keeping track of watched videos. Videos can be filtered with different criteria (date, channel name) in a batch way or within a minimal gui. License: GPL-3+ Copyright: 2019 Wolfgang Popp URL: https://github.com/woefe/ytcc pgpXzkRXLeFg1.pgp Description: PGP signature
Bug#425337: chmod 700 on $HOME/.nano_saved-files
Hello Sebastien, I don't understand the original report. What is $HOME/.nano_saved-files used for? Does Debian create this directory upon installing nano? Because as far as I know, nano itself does not create it. Regards, Benno
Bug#928657: ITP: golang-github-naegelejd-go-acl -- Golang POSIX 1e ACL bindings
Hi On Fri, May 10, 2019 at 4:06 PM Felixoid wrote: > > + submit, debian-devel, debian-go sub...@bugs.debian.org is meant for creating a new bug.. > > пт, 10 мая 2019 г. в 09:31, Felixoid : >> >> Hello. Did I miss something here? What would be the next step to submit the >> repo https://github.com/Felixoid/golang-github-naegelejd-go-acl to the >> created salsa >> https://salsa.debian.org/go-team/packages/golang-github-naegelejd-go-acl as >> well? >> >> I've created a guest user felixoid-guest and couldn't push into repo because >> of lack of permissions: >> > GitLab: You are not allowed to push code to this project. You could do it with dh-make-golang, you can get more info at https://go-team.pages.debian.net/packaging.html#_using_dh_make_golang -- Shengjing Zhu
Bug#443203: nano: broken input of ISO8859-1 text
Hi Benno, (I'm looking through the Debian list of nano bugs...) Twelve years ago you reported a problem with nano relating to using it in an ISO8859-1 locale. The oldest version of nano that I have available is 2.0.6, not the 2.0.2 that you reported it for. When, in that version, I set the locale (LC_ALL) to en_US.iso88591 and switch the charset of the terminal (Xfce4, I don't know how to do this in xterm) to ISO8859-1, then I can enter things like á and é and ë perfectly fine. (And when I look at the hex dump of the data, they are indeed one-byte ISO8859-1 characters, not multibyte UTF-8 ones.) So... I'm inclined to attribute the problem that you saw to some misconfiguration of the locale settings. But maybe you can shed some more light on this? Thanks for looking for bugs to squash :-) The problem I mentioned disappeared a long time ago. It happened when I upgraded to the then newly-released Debian Etch; it is likely that subsequent work on Debian silently fixed the issue. (Every time I upgrade to a new version of Debian, a few things stop working.) I currently use LC_ALL=en_US.iso88591 with no problem. This one can be closed! Sébastien.
Bug#928754: Compile fix with kernel 5.1
Package: broadcom-sta-source Version: 6.30.223.271-10 I use the attached patch to get this module compiled with 5.1.0. Works fine for me the last few days. Judging the kernel patch-5.1.xz, everywhere get_ds() got replaced with KERNEL_DS. Cheers, Koos Vriezen --- src/wl/sys/wl_cfg80211_hybrid.c.orig 2019-05-07 16:52:35.903359637 +0200 +++ src/wl/sys/wl_cfg80211_hybrid.c 2019-05-10 13:40:54.327109866 +0200 @@ -457,7 +457,11 @@ wl_dev_ioctl(struct net_device *dev, u32 ifr.ifr_data = (caddr_t) fs = get_fs(); +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0) set_fs(get_ds()); +#else + set_fs(KERNEL_DS); +#endif #if defined(WL_USE_NETDEV_OPS) err = dev->netdev_ops->ndo_do_ioctl(dev, , SIOCDEVPRIVATE); #else
Bug#443203: nano: broken input of ISO8859-1 text
Hello Sebastien, (I'm looking through the Debian list of nano bugs...) Twelve years ago you reported a problem with nano relating to using it in an ISO8859-1 locale. The oldest version of nano that I have available is 2.0.6, not the 2.0.2 that you reported it for. When, in that version, I set the locale (LC_ALL) to en_US.iso88591 and switch the charset of the terminal (Xfce4, I don't know how to do this in xterm) to ISO8859-1, then I can enter things like á and é and ë perfectly fine. (And when I look at the hex dump of the data, they are indeed one-byte ISO8859-1 characters, not multibyte UTF-8 ones.) So... I'm inclined to attribute the problem that you saw to some misconfiguration of the locale settings. But maybe you can shed some more light on this? Regards, Benno
Bug#928753: ITP: chibi-scheme -- embeddable Scheme interpreter
Package: wnpp Owner: Barak A. Pearlmutter Severity: wishlist * Package name: chibi-scheme Version : 0.8.0 Upstream Author : Alex Shinn * URL or Web page : https://github.com/ashinn/chibi-scheme/ * License : BSD-3-clause Description : embeddable Scheme interpreter Chibi-Scheme is a very small embeddable interpreter of R7RS Scheme, intended for use as an extension and scripting language in C programs.
Bug#922098: RFE: matrix-synapse.service should have ExecReload
On 10/05/2019 11:57, Willem Mulder wrote: > I've attached a debdiff that resolves this bug. Added closes mention as well now. diff -Nru matrix-synapse-0.99.2/debian/changelog matrix-synapse-0.99.2/debian/changelog --- matrix-synapse-0.99.2/debian/changelog 2019-05-03 22:26:41.0 +0200 +++ matrix-synapse-0.99.2/debian/changelog 2019-05-10 11:35:18.0 +0200 @@ -1,3 +1,11 @@ +matrix-synapse (0.99.2-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add reload action to systemd service to be able to reload certificates +(Closes: #922098). + + -- Willem Mulder <14mrh4...@gmail.com> Fri, 10 May 2019 11:35:18 +0200 + matrix-synapse (0.99.2-5) unstable; urgency=high * Security updates backported from 0.99.3: diff -Nru matrix-synapse-0.99.2/debian/matrix-synapse.service matrix-synapse-0.99.2/debian/matrix-synapse.service --- matrix-synapse-0.99.2/debian/matrix-synapse.service 2019-05-03 22:26:41.0 +0200 +++ matrix-synapse-0.99.2/debian/matrix-synapse.service 2019-05-10 11:34:46.0 +0200 @@ -9,6 +9,7 @@ EnvironmentFile=/etc/default/matrix-synapse ExecStartPre=/usr/bin/python3 -m synapse.app.homeserver --config-path=/etc/matrix-synapse/homeserver.yaml --config-path=/etc/matrix-synapse/conf.d/ --generate-keys ExecStart=/usr/bin/python3 -m synapse.app.homeserver --config-path=/etc/matrix-synapse/homeserver.yaml --config-path=/etc/matrix-synapse/conf.d/ +ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=3 signature.asc Description: OpenPGP digital signature
Bug#928751: cryptsetup-bin: description claims provides luksformat, which moved to cryptsetup-run
Package: cryptsetup-bin Version: 2:2.1.0-3 Severity: normal the long description for cryptsetup-bin claims it provides the luksformat binary, but that appears to have moved to the cryptsetup-run package, which doesn't mention it at all. -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-4.19.0-1-amd64 root=/dev/mapper/qusp_vg-buster ro quiet -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # # / was on /dev/sda during installation UUID=5fab5fb3-349e-4dcc-abe3-a7eb5609c268 / ext4 errors=remount-ro 0 1 UUID=c1d5f76c-1efb-4e94-9aec-8eb09806674f /boot ext2defaults 0 2 UUID=F944-299E /boot/efi vfatumask=0077 0 1 /dev/mapper/qusp_vg-home /home ext4defaults,discard,nofail 0 2 # swap was on /dev/sdb2 during installation #UUID=c614fca4-bd88-41c4-879b-387b346d8e58 noneswapsw,nofail 0 0 /dev/mapper/qusp_vg-swap noneswapsw,nofail 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/mapper/qusp_vg-root /stretch ext4 errors=remount-ro,nofail 0 1 LABEL=data /data ext4 defaults,nofail,discard 0 2 none /var/lib/schroot/union/overlay tmpfs uid=root,gid=root,mode=0750 0 0 LABEL=cevm /media/cevm ext4 defaults,nofail,discard 0 2 -- lsmod Module Size Used by veth 24576 0 cdc_acm32768 0 snd_hrtimer16384 0 snd_seq_dummy 16384 0 snd_seq81920 1 snd_seq_dummy snd_seq_device 16384 1 snd_seq vhost_net 24576 1 vhost 49152 1 vhost_net tap24576 1 vhost_net hid_lenovo 20480 0 hidp 28672 0 hid_generic16384 0 usbhid 57344 0 hid 139264 4 hidp,usbhid,hid_generic,hid_lenovo nf_conntrack_netlink49152 0 xfrm_user 40960 1 xfrm_algo 16384 1 xfrm_user iptable_nat16384 1 xt_addrtype16384 2 iptable_filter 16384 1 br_netfilter 24576 0 overlay 126976 0 fuse 122880 3 ctr16384 4 ccm20480 6 rfcomm 86016 4 nft_chain_route_ipv416384 1 xt_CHECKSUM16384 1 nft_chain_nat_ipv4 16384 4 ipt_MASQUERADE 16384 2 nf_nat_ipv416384 3 ipt_MASQUERADE,nft_chain_nat_ipv4,iptable_nat nf_nat 36864 1 nf_nat_ipv4 xt_conntrack 16384 2 nf_conntrack 163840 5 xt_conntrack,nf_nat,ipt_MASQUERADE,nf_nat_ipv4,nf_conntrack_netlink nf_defrag_ipv6 20480 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack crc32c_generic 16384 0 ipt_REJECT 16384 1 nf_reject_ipv4 16384 1 ipt_REJECT nft_counter16384 25 xt_tcpudp 16384 2 nft_compat 20480 22 tun49152 7 vhost_net bridge188416 1 br_netfilter stp16384 1 bridge llc16384 2 bridge,stp devlink77824 0 snd_hda_codec_hdmi 57344 1 snd_hda_codec_realtek 118784 1 snd_hda_codec_generic86016 1 snd_hda_codec_realtek nf_tables 143360 128 nft_chain_route_ipv4,nft_compat,nft_chain_nat_ipv4,nft_counter nfnetlink 16384 4 nft_compat,nf_conntrack_netlink,nf_tables cmac 16384 1 bnep 24576 2 arc4 16384 2 binfmt_misc20480 1 uvcvideo 118784 0 videobuf2_vmalloc 16384 1 uvcvideo videobuf2_memops 16384 1 videobuf2_vmalloc videobuf2_v4l2 28672 1 uvcvideo videobuf2_common 53248 2 videobuf2_v4l2,uvcvideo btusb 53248 0 btrtl 16384 1 btusb btbcm 16384 1 btusb btintel24576 1 btusb videodev 212992 3 videobuf2_v4l2,uvcvideo,videobuf2_common iwlmvm294912 0 media 45056 2 videodev,uvcvideo wmi_bmof 16384 0 mac80211 819200 1 iwlmvm bluetooth 643072 32 btrtl,hidp,btintel,btbcm,bnep,btusb,rfcomm nls_ascii 16384 2 snd_soc_skl 118784 0 snd_soc_skl_ipc73728 1 snd_soc_skl snd_soc_sst_ipc16384 1 snd_soc_skl_ipc nls_cp437 20480 2 snd_soc_sst_dsp36864 1 snd_soc_skl_ipc vfat 20480 2 intel_rapl 24576 0 snd_hda_ext_core 28672 1 snd_soc_skl fat86016 1 vfat x86_pkg_temp_thermal16384 0 intel_powerclamp 16384 0 drbg
Bug#928752: monitoring-plugins-basic: check_disk ignores inode thresholds after -A
Package: monitoring-plugins-basic Version: 2.2-3 Severity: normal Dear Maintainer, when speciying inode threshold after -A (--all) they are ignored. Testing with a near out of inodes disk: df -i / Filesystem Inodes IUsed IFree IUse% Mounted on root 2510032 2503586 6446 100% / Passing -A before inode settings, but after block settings leads to OK: /usr/lib/nagios/plugins/check_disk -w 10% -c 5% -A -W 10% -K 5% DISK OK - free space: ... / 25612 MB (70% inode=0%); Moving -A to the end leads to the expected CRITICAL: /usr/lib/nagios/plugins/check_disk -w 10% -c 5% -W 10% -K 5% -A DISK CRITICAL - free space: ... / 25612 MB (70% inode=0%); FWIW there seems to be some checking wrt -A position: /usr/lib/nagios/plugins/check_disk -A -w 10% -c 5% -W 10% -K 5% DISK UNKNOWN: Must set a threshold value before using -r/-R Thanks, Stefan -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') 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) Versions of packages monitoring-plugins-basic depends on: ii iputils-ping 3:20161105-1 ii libc6 2.24-11+deb9u4 ii libssl1.1 1.1.0j-1~deb9u1 ii monitoring-plugins-common 2.2-3 ii procps 2:3.3.12-3+deb9u1 ii ucf3.0036 Versions of packages monitoring-plugins-basic recommends: ii libcap2-bin 1:2.25-1 Versions of packages monitoring-plugins-basic suggests: ii icinga2 2.6.0-2+deb9u1 -- no debconf information
Bug#699496: Grüße an dich mein lieber Freund,
Grüße an dich, mein lieber Freund, Mein Name ist Mariam Abdul, ich schreibe Ihnen diese Nachricht mit Tränen in den Augen. Der andauernde Bürgerkrieg in meinem Land Syrien hat mein Leben so sehr beeinflusst. Ich habe letztes Jahr meine Familie verloren. Mein Vater war vor seinem Tod ein reicher Geschäftsmann, er machte Öl- und Gasgeschäfte, er machte auch Goldgeschäfte. Er verdiente ein großes Geld 25,3 Millionen US-Dollar, das Geld ist bei der First Gulf Bank in Dubai, Vereinigte Arabische Emirate, hinterlegt. Ich bin der nächste Angehörige, aber ich kann das Geld wegen des Krieges und der Tötung in Syrien nicht zurückbekommen oder zurückgeben . Bitte helfen Sie mir, das Geld zu erhalten, und wir können vereinbaren, dass Sie es investieren, bis ich mich von meiner Krankheit erholt habe und zu Ihnen komme. Ich möchte Sie zum Geschäftspartner meines verstorbenen Vaters ernennen, und die First Gulf Bank in Dubai überweist Ihnen das Geld. Ich werde Ihnen alle Unterlagen und Informationen zur Einzahlung des Geldes zusenden. Bitte lassen Sie mich wissen, ob Sie dies für mich tun können. Dies ist meine wahre Geschichte. Bitte, ich brauche Ihre Hilfe. Sie können mich per E-Mail kontaktieren (mariamabdul...@gmail.com) Mit freundlichen Grüßen, Mariam Abdul
Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))
On 2019-05-07 7:13 a.m., - wrote: > This morning GNOME Shell crashed again, see attached logs. > Connecting/disconecting the Thunderbolt Gen2 Dock was working fine for > 1-2 weeks, now it crashed again. > > Hope the logs help to narrow down the issue finally. It looks like it could be (related to) https://gitlab.freedesktop.org/xorg/xserver/issues/11 , which is said to be fixed with Xwayland 1.20.4. Have you tried that? -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#922098: RFE: matrix-synapse.service should have ExecReload
control: tags -1 +patch Hi, On Thu, 11 Apr 2019 22:29:29 +0200 Jörg Sommer wrote: > On Tue, 12 Feb 2019 01:50:49 +0100 Damjan Georgievski wrote: > > Package: matrix-synapse > > Version: 0.99.0-1 > > > > […] > > But Synapse doesn't reload the config on SIGHUP, esp. it does not reload > the `tls_fingerprints` which is needed when certbot updates the TLS key. > It's not, see homeserver.yaml: > # Synapse automatically adds the fingerprint of its own certificate > # to the list. So if federation traffic is handled directly by synapse > # then no modification to the list is required. I've attached a debdiff that resolves this bug. Kind regards, Willem Mulder diff -Nru matrix-synapse-0.99.2/debian/changelog matrix-synapse-0.99.2/debian/changelog --- matrix-synapse-0.99.2/debian/changelog 2019-05-03 22:26:41.0 +0200 +++ matrix-synapse-0.99.2/debian/changelog 2019-05-10 11:35:18.0 +0200 @@ -1,3 +1,10 @@ +matrix-synapse (0.99.2-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add reload action to systemd service to be able to reload certificates. + + -- Willem Mulder <14mrh4...@gmail.com> Fri, 10 May 2019 11:35:18 +0200 + matrix-synapse (0.99.2-5) unstable; urgency=high * Security updates backported from 0.99.3: diff -Nru matrix-synapse-0.99.2/debian/matrix-synapse.service matrix-synapse-0.99.2/debian/matrix-synapse.service --- matrix-synapse-0.99.2/debian/matrix-synapse.service 2019-05-03 22:26:41.0 +0200 +++ matrix-synapse-0.99.2/debian/matrix-synapse.service 2019-05-10 11:34:46.0 +0200 @@ -9,6 +9,7 @@ EnvironmentFile=/etc/default/matrix-synapse ExecStartPre=/usr/bin/python3 -m synapse.app.homeserver --config-path=/etc/matrix-synapse/homeserver.yaml --config-path=/etc/matrix-synapse/conf.d/ --generate-keys ExecStart=/usr/bin/python3 -m synapse.app.homeserver --config-path=/etc/matrix-synapse/homeserver.yaml --config-path=/etc/matrix-synapse/conf.d/ +ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=3 signature.asc Description: OpenPGP digital signature
Bug#903785: falkon: Missing dependency
Package: falkon Version: 3.0.0-3 Followup-For: Bug #903785 Dear Maintainer, I also experienced this issue until I installed qml-module-qtwebengine. On the SpeedDial page, thumbnails were not displayed. A page title also was not loaded automatically when a new page added. Please add the dependency to the package. -- System Information: Debian Release: buster/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages falkon depends on: ii libc62.28-10 ii libgcc1 1:8.3.0-6 ii libkf5wallet-bin 5.54.0-1 ii libkf5wallet55.54.0-1 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5dbus5 5.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5positioning5 5.11.3+dfsg-2 ii libqt5printsupport5 5.11.3+dfsg1-1 ii libqt5qml5 5.11.3-4 ii libqt5quick5 5.11.3-4 ii libqt5quickwidgets5 5.11.3-4 ii libqt5sql5 5.11.3+dfsg1-1 ii libqt5sql5-sqlite5.11.3+dfsg1-1 ii libqt5webchannel55.11.3-2 ii libqt5webenginecore5 5.11.3+dfsg-2+b1 ii libqt5webenginewidgets5 5.11.3+dfsg-2+b1 ii libqt5widgets5 5.11.3+dfsg1-1 ii libqt5x11extras5 5.11.3-2 ii libssl1.11.1.1b-2 ii libstdc++6 8.3.0-6 ii libxcb1 1.13.1-2 falkon recommends no packages. falkon suggests no packages. -- no debconf information
Bug#928750: [grub-efi-amd64] On EFI pxeboot grubx64.efi only loads config when loaded directly
Package: grub-efi-amd64 Version: 2.02+dfsg1-16 Severity: important --- Please enter the report below this line. --- https://d-i.debian.org/manual/en.amd64/ch04s05.html mentions that you need to configure filename "debian-installer/amd64/bootnetx64.efi"; as bootfile for booting via PXE in dhcp configs. When doing so, grubx64.efi will be loaded in the next step, but will not try to load its config files and - after 30s wait time showing the attached screen on console present the Grub shell. (As mentioned in https://lists.debian.org/debian-boot/2019/05/msg00076.html) Excerpt from logs: May 8 16:02:07 ssfnctl111 dhcpd: DHCPREQUEST for 10.45.10.32 (10.45.10.5) from 0c:c4:xxx via eth0 May 8 16:02:07 ssfnctl111 dhcpd: DHCPACK on 10.45.10.32 to 0c:c4:xxx via eth0 May 8 16:02:07 ssfnctl111 in.tftpd[21355]: RRQ from :::10.45.10.32 filename debian-installer/amd64/bootnetx64.efi May 8 16:02:07 ssfnctl111 in.tftpd[21355]: tftp: client does not accept options May 8 16:02:08 ssfnctl111 in.tftpd[21356]: RRQ from :::10.45.10.32 filename debian-installer/amd64/bootnetx64.efi May 8 16:02:08 ssfnctl111 in.tftpd[21357]: RRQ from :::10.45.10.32 filename debian-installer/amd64/grubx64.efi (Nothing re tftp afterwards) If you change the boot option in dhcp. conf to filename "debian-installer/amd64/grubx64.efi"; it changes to: May 10 10:51:20 ssfnctl111 in.tftpd[16770]: RRQ from :::10.45.10.32 filename debian-installer/amd64/grubx64.efi May 10 10:51:20 ssfnctl111 in.tftpd[16770]: tftp: client does not accept options May 10 10:51:21 ssfnctl111 in.tftpd[16771]: RRQ from :::10.45.10.32 filename debian-installer/amd64/grubx64.efi May 10 10:51:21 ssfnctl111 in.tftpd[16773]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/command.lst May 10 10:51:21 ssfnctl111 in.tftpd[16773]: sending NAK (1, File not found) to :::10.45.10.32 May 10 10:51:21 ssfnctl111 in.tftpd[16774]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/fs.lst May 10 10:51:21 ssfnctl111 in.tftpd[16774]: sending NAK (1, File not found) to :::10.45.10.32 May 10 10:51:21 ssfnctl111 in.tftpd[16775]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/crypto.lst May 10 10:51:21 ssfnctl111 in.tftpd[16775]: sending NAK (1, File not found) to :::10.45.10.32 May 10 10:51:21 ssfnctl111 in.tftpd[16776]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/terminal.lst May 10 10:51:21 ssfnctl111 in.tftpd[16776]: sending NAK (1, File not found) to :::10.45.10.32 May 10 10:51:21 ssfnctl111 in.tftpd[16777]: RRQ from :::10.45.10.32 filename /grub/grub.cfg May 10 10:51:21 ssfnctl111 in.tftpd[16777]: sending NAK (1, File not found) to :::10.45.10.32 After adding a symlink in /var/lib/tftpboot/ grub -> debian-10/debian-installer/amd64/grub (additional to debian-installer -> debian-10/debian-installer), Grub will load and we can chose a menu to start our preseeded install: May 10 10:53:55 ssfnctl111 in.tftpd[18546]: RRQ from :::10.45.10.32 filename debian-installer/amd64/grubx64.efi May 10 10:53:55 ssfnctl111 in.tftpd[18546]: tftp: client does not accept options May 10 10:53:55 ssfnctl111 in.tftpd[18547]: RRQ from :::10.45.10.32 filename debian-installer/amd64/grubx64.efi May 10 10:53:56 ssfnctl111 in.tftpd[18548]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/command.lst May 10 10:53:56 ssfnctl111 in.tftpd[18549]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/fs.lst May 10 10:53:56 ssfnctl111 in.tftpd[18550]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/fs.lst May 10 10:53:56 ssfnctl111 in.tftpd[18551]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/fs.lst May 10 10:53:56 ssfnctl111 in.tftpd[18552]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/fs.lst May 10 10:53:56 ssfnctl111 in.tftpd[18553]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/crypto.lst May 10 10:53:56 ssfnctl111 in.tftpd[18554]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/crypto.lst May 10 10:53:56 ssfnctl111 in.tftpd[18555]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/crypto.lst May 10 10:53:56 ssfnctl111 in.tftpd[18556]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/terminal.lst May 10 10:53:56 ssfnctl111 in.tftpd[18557]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/terminal.lst May 10 10:53:56 ssfnctl111 in.tftpd[18558]: RRQ from :::10.45.10.32 filename /grub/x86_64-efi/terminal.lst May 10 10:53:56 ssfnctl111 in.tftpd[18559]: RRQ from :::10.45.10.32 filename /grub/grub.cfg May 10 10:53:56 ssfnctl111 in.tftpd[18560]: RRQ from :::10.45.10.32 filename /grub/grub.cfg May 10 10:53:56 ssfnctl111 in.tftpd[18561]: RRQ from :::10.45.10.32 filename /grub/grub.cfg May 10 10:53:56 ssfnctl111 in.tftpd[18562]: RRQ from :::10.45.10.32 filename /grub/font.pf2 May 10 10:53:56 ssfnctl111 in.tftpd[18563]: RRQ from :::10.45.10.32 filename /isolinux/splash.png May 10 10:53:56 ssfnctl111 in.tftpd[18563]: sending NAK
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
severity 927667 serious thanks [ I wrote the following reply to smcv's last mail to this bug, but only sent it to -desktop: https://lists.debian.org/debian-desktop/2019/05/msg0.html ] Thanks to Simon for filing this bug in the first place and for engaging in discussion about the issue. My personal conclusion is that we, as a project, need to spend more time carefully evaluating Wayland prior to it being the default desktop technology for Debian, following the approach we have used for other major technologies adopted by default (e.g. systemd). This hasn't happened for Wayland yet, and I'm concerned that it may just not be quite ready (e.g. #928030, #928002). I want an explicit ACK or NACK on this, and so I'm bumping severity so that this bug can't languish past Buster release. Justification is the regression in behavour wrt X11 (as documented in those two bugs amongst others) break unrelated software. I'll interpret downgrading as being a NACK, but I would *really* appreciate engagement instead of just bug severity changes. Two ways of resolving this are: Either the default GNOME3 session in Debian switched back to Xorg, or the default desktop session is switched away from GNOME; but I would much prefer the former. -- Jonathan Dowland
Bug#928609: AW: [Pkg-utopia-maintainers] Bug#928609: network-manager: Invalid system-connections configuration during preseeding
Hello again, do to me using the machine currently for a longer while, I will not be able to reinstall it so I can keep the `Wired Connection 1` file. I'll try to give it to you as soon as possible though. The syslog file is something I can send you though, no issues. I hope attaching it works, if not I'll find a way to post it. Kind Regards, Yannick Schinko -Ursprüngliche Nachricht- Von: Michael Biebl Gesendet: Freitag, 10. Mai 2019 01:09 An: Cyril Brulebois ; Yannick Schinko ; 928...@bugs.debian.org Betreff: Re: [Pkg-utopia-maintainers] Bug#928609: network-manager: Invalid system-connections configuration during preseeding Am 10.05.19 um 00:55 schrieb Cyril Brulebois: > Hi, > > Michael Biebl (2019-05-08): >> Control: reassign -1 netcfg > > Thanks for forwarding this. > >> Am 08.05.19 um 14:12 schrieb Yannick Schinko: I assume this file is created by the debian installer, so you should probably talk to them. See https://qa.debian.org/developer.php?email=debian-boot%40lists.debia n.org I would guess that the netcfg part is the most likely package. >>> >>> So you suggest to recreate this report on the netcfg package instead? >> >> If netcfg is the component responsible for creating that file, yes. >> I'm not sure though, which is why I suggested to contact the >> debian-b...@lists.debian.org first. >> >> You don't need to file or recreate the bug report btw, we can just >> re-assign it. >> >> Thinking about it, I'll just do this now and let the debian-installer >> maintainers re-assign as needed. > > netcfg looks like a good candidate indeed. > > Yannick, it'd be great to see the installer's syslog, that should have > been stored under /var/log/installer. It would probably also be a good idea to share the "Wired connection 1" config file. I'm only guessing here, but I assume Yannick wants the connection profile to be bound to a certain interface. Connection profiles can apply to multiple interfaces given the conditions in the connection profile are met. If you want to bind a connection profile to a certain hardware interface, you can e.g. use mac-address=. For a wifi interface, this would be: [wifi] mac-address=00:23:5a:47:1f:71 for an ethernet connection: [802-3-ethernet] mac-address=00:23:5a:47:1f:71 See nm-settings-keyfile and nm-settings. I'm undecided whether setting mac-address= by default is a good idea or not. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? syslog.gz Description: syslog.gz
Bug#897348: Lucrative business proposal
-- Good day,I have a deal for your professional expertise. Reply to chensiiq...@outlook.jp for further details Regards Chen Siqing (Secretary)
Bug#928748: qbittorrent: new upstream 4.1.6
Package: Qbittorrent Version: 4.1.6 Please consider to upgrade to the current upstream version (4.1.6). Regards Jonatan
Bug#928684: [Pkg-privacy-maintainers] Bug#928684: monkeysphere-host import-key broken due to ssh-keygen change
On Fri, May 10, 2019 at 07:21:24AM +, Andrei Morgan wrote: > On Wed, May 08, 2019 at 06:17:03PM -0400, Daniel Kahn Gillmor wrote: > > As a workaround, if you don't care about the existing RSA hostkey on > > your server, you can just re-generate it with: > > > > rm -f /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub > > ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key > > Thanks for the advice. unfortunately, this does not work: After discussion with someone else, I figured out how to fix this workaround: ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key -m PEM This provides me with: root@server:~# grep ^- /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_ecdsa_key:-BEGIN OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_ecdsa_key:-END OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_ed25519_key:-BEGIN OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_ed25519_key:-END OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_rsa_key:-BEGIN RSA PRIVATE KEY- /etc/ssh/ssh_host_rsa_key:-END RSA PRIVATE KEY- root@server:~# And the `monkeysphere-host import-key` command also worked. root@server:~# monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key ssh://server.example.com ms: host key imported: pub rsa2048 2019-05-10 [CA] 2E66A858557528DDA4D8E1FCBB8427731FCCD81A uid [ unknown] ssh://server.example.com OpenPGP fingerprint: 2E66A858557528DDA4D8E1FCBB8427731FCCD81A ssh fingerprint: 2048 SHA256:qNes+pJ9gPZ+l6OS8ZJYc9xZhRdFV/10YaAslEwkXcU . (RSA) root@server:~# The only thing I don't know is whether this will have any future implications, but I guess that as servers being upgraded from stretch to buster will retain the old-style (i.e. PEM) format, there shouldn't be any big problems. Cheers, -- Andrei -- Andrei Morgan MRCPCH, MSc, PhD (Epidemiology / Neonatology) https://www.andreimorgan.net/info/contact signature.asc Description: PGP signature
Bug#928747: network-manager-ssh: CPU usage 100%
Package: network-manager-ssh Version: 1.2.8-1 Severity: grave File: network-manager-ssh Tags: upstream Justification: renders package unusable Dear Maintainer, using the SSH plugin for network-manager as a VPN leads to 100% CPU usage immediately. This is due to a running loop which fails to consume all output of a pipe. This bug has already been fixed upstream in version 1.2.10. Relevant: https://github.com/danfruehauf/NetworkManager-ssh/issues/88 -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-ssh depends on: ii libc6 2.28-10 ii libglib2.0-02.58.3-1 ii libnm0 1.14.6-2 ii openssh-client 1:7.9p1-10 ii sshpass 1.06-1 Versions of packages network-manager-ssh recommends: ii network-manager-ssh-gnome 1.2.8-1 network-manager-ssh suggests no packages.
Bug#925061: apache2: Cannot disabled old TLS Versions (prior to TLS1.2)
I found something in /etc/letsencrypt/options-ssl-apache.conf ... Issue can be closed now...
Bug#928657: ITP: golang-github-naegelejd-go-acl -- Golang POSIX 1e ACL bindings
+ submit, debian-devel, debian-go пт, 10 мая 2019 г. в 09:31, Felixoid : > Hello. Did I miss something here? What would be the next step to submit > the repo https://github.com/Felixoid/golang-github-naegelejd-go-acl to > the created salsa > https://salsa.debian.org/go-team/packages/golang-github-naegelejd-go-acl > as well? > > I've created a guest user felixoid-guest and couldn't push into repo > because of lack of permissions: > > GitLab: You are not allowed to push code to this project. > > Best regards, > Mikhail. > > ср, 8 мая 2019 г. в 14:48, Mikhail f. Shiryaev : > >> Package: wnpp >> Severity: wishlist >> Owner: Mikhail f. Shiryaev >> >> * Package name: golang-github-naegelejd-go-acl >> Version : 0.0~git20160113.f33f861-1 >> Upstream Author : Joseph Naegele >> * URL : https://github.com/naegelejd/go-acl >> * License : MIT >> Programming Lang: Go >> Description : Golang POSIX 1e ACL bindings >> >> go-acl Golang POSIX.1e ACL bindings. Essentially bindings to >> /usr/include/sys/acl.h notesmac os x Mac OS X does not seem to support >> basic POSIX1.e ACLs. They do provide the POSIX API for NFSv4 ACLs. It >> would be nice for this package to also support NFSv4 ACLs. freebsd By >> default, FreeBSD does not enable POSIX1.e ACLs on the root partition. To >> enable them, reboot into single-user mode and execute: $ tunefs -a enable >> $ reboot >> . >> Source: https://www.freebsd.org/doc/handbook/fs-acl.html info The >> IEEE POSIX.1e specification describes five security extensions to the >> base POSIX.1 API: Access Control Lists (ACLs), Auditing, Capabilities, >> Mandatory Access Control, and Information Flow Labels. The specificaiton >> was abandoned before finalization, however most UNIX-like operating >> systems have some form of ACL implementation. >> . >> Source: http://www.gsp.com/cgi-bin/man.cgi?section=3=posix1e >> copying Copyright (c) 2015 Joseph Naegele. See LICENSE file. >> >
Bug#928684: [Pkg-privacy-maintainers] Bug#928684: monkeysphere-host import-key broken due to ssh-keygen change
On Wed, May 08, 2019 at 06:17:03PM -0400, Daniel Kahn Gillmor wrote: > As a workaround, if you don't care about the existing RSA hostkey on > your server, you can just re-generate it with: > > rm -f /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub > ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key Thanks for the advice. unfortunately, this does not work: root@server:~# rm -f /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub root@server:~# ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key Generating public/private rsa key pair. Your identification has been saved in /etc/ssh/ssh_host_rsa_key. Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub. The key fingerprint is: SHA256:sA2Y6dG8QqCZQ3yfimLSjpSTPzZ7bq+UMmZmpyBc0tM root@server The key's randomart image is: +---[RSA 2048]+ |... | |.= o * | |= . B * | | ..o.+ * | | o+++Eo S| |+B+ | |*=oB + | |o B=*o | | .oBoo. | +[SHA256]-+ root@server:~# grep ^- /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_ecdsa_key:-BEGIN OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_ecdsa_key:-END OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_ed25519_key:-BEGIN OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_ed25519_key:-END OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_rsa_key:-BEGIN OPENSSH PRIVATE KEY- /etc/ssh/ssh_host_rsa_key:-END OPENSSH PRIVATE KEY- root@server:~# with, consequently, the same error: root@server:~# monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key ssh://server.example.com RSA.xs:194: OpenSSL error: no start line at /usr/bin/pem2openpgp line 1106, line 1. gpg: no valid OpenPGP data found. root@server:~# I'm afraid I lack the knowledge to really try and do anything else you suggested, but I will certainly keep on trying to implement any suggested fixes :) Thanks again for all the hard work in maintaining and providing this extremely useful package, -- Andrei -- Andrei Morgan MRCPCH, MSc, PhD (Epidemiology / Neonatology) https://www.andreimorgan.net/info/contact signature.asc Description: PGP signature
Bug#928657: ITP: golang-github-naegelejd-go-acl -- Golang POSIX 1e ACL bindings
Hello. Did I miss something here? What would be the next step to submit the repo https://github.com/Felixoid/golang-github-naegelejd-go-acl to the created salsa https://salsa.debian.org/go-team/packages/golang-github-naegelejd-go-acl as well? I've created a guest user felixoid-guest and couldn't push into repo because of lack of permissions: > GitLab: You are not allowed to push code to this project. Best regards, Mikhail. ср, 8 мая 2019 г. в 14:48, Mikhail f. Shiryaev : > Package: wnpp > Severity: wishlist > Owner: Mikhail f. Shiryaev > > * Package name: golang-github-naegelejd-go-acl > Version : 0.0~git20160113.f33f861-1 > Upstream Author : Joseph Naegele > * URL : https://github.com/naegelejd/go-acl > * License : MIT > Programming Lang: Go > Description : Golang POSIX 1e ACL bindings > > go-acl Golang POSIX.1e ACL bindings. Essentially bindings to > /usr/include/sys/acl.h notesmac os x Mac OS X does not seem to support > basic POSIX1.e ACLs. They do provide the POSIX API for NFSv4 ACLs. It > would be nice for this package to also support NFSv4 ACLs. freebsd By > default, FreeBSD does not enable POSIX1.e ACLs on the root partition. To > enable them, reboot into single-user mode and execute: $ tunefs -a enable > $ reboot > . > Source: https://www.freebsd.org/doc/handbook/fs-acl.html info The > IEEE POSIX.1e specification describes five security extensions to the > base POSIX.1 API: Access Control Lists (ACLs), Auditing, Capabilities, > Mandatory Access Control, and Information Flow Labels. The specificaiton > was abandoned before finalization, however most UNIX-like operating > systems have some form of ACL implementation. > . > Source: http://www.gsp.com/cgi-bin/man.cgi?section=3=posix1e > copying Copyright (c) 2015 Joseph Naegele. See LICENSE file. >
Bug#928744: u-boot: add support for the Turris Omnia and other OpenSSL reqiring hardware
On Thu, 2019-05-09 at 23:45 -0700, Vagrant Cascadian wrote: > I've thought about this as well... I've been hesitant to implement it > wondering how it would interact with the NEW queue... Only one way to find out :) > Ideally, of course, would be to fix upstream to not require OpenSSL Indeed, even with OpenSSL moving to Apache 2.0, which is compatible with GPLv3 (and thus GPLv2+), OpenSSL 3.0 will still be incompatible with the GPLv2-only code in u-boot. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#928026: security support for golang packages in Buster
Hi, On Fri, May 10, 2019 at 10:44:13AM +0800, Shengjing Zhu wrote: > Hi the security team, > > On Thu, May 9, 2019 at 1:53 AM Moritz Muehlenhoff wrote: > [...] > > > > There's the additional issue that ftp-master and security-master don't > > share tarballs; binNMUs are only possible for packages which are on > > security-master, so we'd need to do manual source uploads for every > > affected go package. > > > > I probably lack of some historical background, have you ever think of > merging ftp-master and security-master? The security team does not manage dak on security-master, this is actually ftp-masters domain. The separation has as disadantages and advantages, one which comes to my mind idepenently on the aspect of the one beeing security-master is to have a fallback updateing channel in case one or the other cannot be used. But okay that's not the point. There is #823820 for one Built-Using aspect, but the idea might be possible to generalize to have on every time orig tarballs from main archive available on security-master as well. Regards, Salvatore
Bug#928744: u-boot: add support for the Turris Omnia and other OpenSSL reqiring hardware
On 2019-05-10, Paul Wise wrote: > Please add support to the u-boot source package for building u-boot > binary packages for the Turris Omnia and other hardware where u-boot > requires OpenSSL. As I understand it, these binary packages are not > redistributable by Debian but folks could build or cross-build them > themselves for deployment on their own hardware. That's my understanding, yes. > By using dpkg's build profiles support, those packages could be added > to the u-boot source package, not be built by default but still be > able to be manually buildable using the dpkg-buildpackage > --build-profiles option. I've thought about this as well... I've been hesitant to implement it wondering how it would interact with the NEW queue... if needed I guess a workaround would be to add them to the "u-boot" package, though it's not available on all architectures, and might violate "A binary package must contain the exact same content for all profiles with which it builds" And now that we've opened the discussion... Ideally, of course, would be to fix upstream to not require OpenSSL due to the incompatibility with GPL and port to another library that was GPL-compatible... in theory it's not a lot of code. I briefly tried looking into the GNU TLS OpenSSL compatibility layer, but it did not support the needed functionality. I also brought this issue up in Guix recently, but eventually just submitted a patch to remove OpenSSL from the u-boot packaging much like Debian already does: https://issues.guix.info/issue/34717 Some past discussion upstream: https://lists.denx.de/pipermail/u-boot/2017-November/312483.html https://lists.denx.de/pipermail/u-boot/2017-December/313616.html https://lists.denx.de/pipermail/u-boot/2017-December/313742.html It didn't seem like a licensing exception was plausible upstream, as u-boot is codebase with a lot of individual contributors over the years... live well, vagrant signature.asc Description: PGP signature
Bug#908712: linux-image-4.17.0-0.bpo.3-marvell: stretch-backports kernel 4.17 breaks QNAP TS-209
Unfortuantely I'm not aware of any changes. I just saw a message from Marcus Better from January that the problem is in 4.19, so I assume it's still there. Can one of you please try the latest kernel in stretch-backports (or even 5.0.2 in experimental). If the problem is there, please show the error message. If it's still there, we have to inform Andrew Lunn who is the upstream kernel contact for Orion. * Ralf Hemberger [2019-05-09 20:11]: > Hi, I didn't do any test since reporting für issue. Has anything relevant > changed? > > Martin Michlmayr schrieb am Do., 9. Mai 2019, 10:18: > > > * Martin Michlmayr [2019-01-22 11:45]: > > > Ralf, have you been able to find out more about this issue? > > > > Ralf, is this issue still there? > > > > > > > If not, it might be worth copying Andrew Lunn who is > > > the kernel upstream expert for Orion. > > > > > > * Ralf Hemberger [2018-10-02 21:48]: > > > > Hello, > > > > > > > > > I can try this weekend whether removing systemd makes a difference. > > > > > > > > > Installing sysvinit-core made no difference. > > > > I tried the older backports-kernels and the problem exists already with > > > > linux-image-4.12.0-0.bpo.2-marvell_4.12.13-1~bpo9+1_armel.deb. > > > > (linux-image-4.11.0-0.bpo.1-marvell_4.11.6-1~bpo9+1_armel.deb crashed > > even > > > > earlier: [0.00] INITRD: 0x0080+0x0040 overlaps in-use > > > > memory region - disabling initrd) > > > > > > > > I found this bug report: > > > > https://www.spinics.net/lists/arm-kernel/msg653367.html ([PROBLEM] > > orion5x: > > > > Kernel boot panic at of_clk_get()/orion_mdio_probe() on a non DT box on > > > > linux-4.16.7). > > > > > > > > A working 4.9-kernel prints these messages: > > > > [ 24.542764] libphy: Fixed MDIO Bus: probed > > > > [ 24.586445] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver > > version 1.4 > > > > [ 24.635774] libphy: PHY orion-mdio-mii:08 not found > > > > [ 24.923918] libphy: orion_mdio_bus: probed > > > > [ 24.982809] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with > > MAC > > > > address 00:08:9b:8c:3b:8f > > > > > > > > With kernel > 4.12 you get e.g.: > > > > [ 23.588924] libphy: Fixed MDIO Bus: probed > > > > [ 41.006693] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver > > version 1.4 > > > > [ 41.082447] libphy: PHY orion-mdio-mii:08 not found > > > > [ 41.669309] libphy: PHY orion-mdio-mii:08 not found > > > > [ 41.674709] Unable to handle kernel NULL pointer dereference at > > virtual > > > > address 000c > > > > [ 41.682935] pgd = (ptrval) > > > > [ 41.685714] [000c] *pgd= > > > > [ 41.689321] Internal error: Oops: 5 [#1] ARM > > > > . > > > > . > > > > Cheers > > > > > > -- > > > Martin Michlmayr > > > https://www.cyrius.com/ > > > > -- > > Martin Michlmayr > > https://www.cyrius.com/ > > -- Martin Michlmayr https://www.cyrius.com/
