Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0
I should mention that ocrmypdf no longer has an immediate use for PyMuPDF - I went the route of creating pikepdf, Python bindings for qpdf, and this is library is now in Debian thanks to Sean's work on packaging it. I don't think I would use PyMuPDF if it were available. pikepdf overlaps the core of PyMuPDF but is not a competing library, offering low level PDF manipulation and much in the less way of content generation. As such the original basis for this ticket is gone. I just want to make sure people aren't putting effort into this ticket for ocrmypdf alone. If other people want to see PyMuPDF added to Debian for their own reasons, that's quite fine. -James On Wed, Jun 19, 2019 at 10:28 PM Sean Whitton wrote: > [updating CC to point to the newly-filed RFP] > > Hello Johannes, > > Thank you again for looking into this. > > On Sat 08 Jun 2019 at 09:52pm +0200, Johannes Schauer wrote: > > > after my struggles in #930212 I now figured out how to compile stuff > against > > the static library in libmupdf-dev. As a result I managed to package > PyMuPDF. > > You can see the result here: > > > > https://salsa.debian.org/python-team/modules/pymupdf > > > > It's mostly Lintian-clean and just waiting for somebody who feels like > > maintaining it in the future. :) > > I've had a look at your repo. I've got a few questions and comments > (relevant to whomever wants to take ownership of the ITP and upload this > to NEW). > > A tool called SWIG, with which I'm unfamiliar, was used to generate > fitz/fitz.py from the files fitz/*.i, but this tool does not get run > during the package build. There could be updates to SWIG, including > security updates, which would change fitz.py. It seems to me that we > want to run SWIG during the package build to ensure that fitz.py > reflects all improvements made to SWIG since pymupdf upstream ran that > tool when releasing pymupdf. > > Secondly, how do you foresee us triggering binNMUs to rebuild this > package when the static library in libmupdf-dev changes? We would need > to be sure that this package gets rebuilt if a security update was made > to libmupdf-dev, for example, or the vulnerable version of mupdf would > still be present in this package. PDF libraries tend to get CVEs, to > put it mildly. I'm worried we've the same sort of problem as discussed > in #928227. > > Finally, I noticed that the project looks to be GPL-3 not GPL-3+, though > I haven't looked through every file in the source. I also haven't > thought carefully about the implications of statically linking a project > that's under the AGPL. I think that we can do it, but I'm not sure > quite what license the binary package will end up with, and quite how to > document that in d/copyright. > > -- > Sean Whitton >
Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0
Hi Sean, Quoting Sean Whitton (2019-06-20 07:28:12) > [updating CC to point to the newly-filed RFP] thank you! > Thank you again for looking into this. Incidentally I'm currently writing a tool that needs PyMuPDF so I'll probably spend a bit more time on this. ;) > On Sat 08 Jun 2019 at 09:52pm +0200, Johannes Schauer wrote: > > after my struggles in #930212 I now figured out how to compile stuff > > against the static library in libmupdf-dev. As a result I managed to > > package PyMuPDF. You can see the result here: > > > > https://salsa.debian.org/python-team/modules/pymupdf > > > > It's mostly Lintian-clean and just waiting for somebody who feels like > > maintaining it in the future. :) > I've had a look at your repo. I've got a few questions and comments > (relevant to whomever wants to take ownership of the ITP and upload this to > NEW). > > A tool called SWIG, with which I'm unfamiliar, was used to generate > fitz/fitz.py from the files fitz/*.i, but this tool does not get run > during the package build. There could be updates to SWIG, including > security updates, which would change fitz.py. It seems to me that we > want to run SWIG during the package build to ensure that fitz.py > reflects all improvements made to SWIG since pymupdf upstream ran that > tool when releasing pymupdf. Agreed. https://github.com/pymupdf/PyMuPDF/issues/312 > Secondly, how do you foresee us triggering binNMUs to rebuild this package > when the static library in libmupdf-dev changes? We would need to be sure > that this package gets rebuilt if a security update was made to libmupdf-dev, > for example, or the vulnerable version of mupdf would still be present in > this package. PDF libraries tend to get CVEs, to put it mildly. I'm worried > we've the same sort of problem as discussed in #928227. We have a similar issue but a less severe one because this is only one package and not a whole ecosystem of them. Since the required tooling is currently missing, I guess any maintainer of PyMuPDF would need to closely follow mupdf development and trigger binNMUs as necessary. > Finally, I noticed that the project looks to be GPL-3 not GPL-3+, though I > haven't looked through every file in the source. Indeed there seem to be some files in it that are just GPL-3 and not GPL-3+, namely in the demo and examples directories. d/copyright has to be adjusted accordingly. > I also haven't thought carefully about the implications of statically linking > a project that's under the AGPL. I think that we can do it, but I'm not sure > quite what license the binary package will end up with, and quite how to > document that in d/copyright. d/copyright only documents the contents of the source package. As far as I know we do not yet have means to also document the inferred license of any generated binary artifacts? Thanks! cheers, josch signature.asc Description: signature
Bug#930763: vim-gtk3: After modeline fix (#930020) syntax HL is removed after safe
Package: vim-gtk3 Version: 2:8.0.0197-4+deb9u2 Severity: normal Dear Maintainer, See the upstream bug that I filed on the issue: https://github.com/fatih/vim-go/issues/2363 Abbreviated here: After a Debian Vim upgrade (2:8.1.0875-2) my vim + vim-go exhibits the following behaviour: 1.Open Go file; syntax highlighting is enabled 2.Write file 3.No syntax is available (:syntax: returns No Syntax items defined for this buffer) -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.gtk3 /usr/bin/vim is /usr/bin/vim.gtk3 /usr/bin/gvim is /usr/bin/vim.gtk3 -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vim-gtk3 depends on: ii libacl1 2.2.52-3+b1 ii libc62.24-11+deb9u4 ii libcairo21.14.8-1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgpm2 1.20.7-5 ii libgtk-3-0 3.22.11-1 ii libice6 2:1.0.9-2 ii liblua5.2-0 5.2.4-1.1+b2 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libperl5.24 5.24.1-3+deb9u5 ii libpython3.5 3.5.3-1+deb9u1 ii libruby2.3 2.3.3-1+deb9u6 ii libselinux1 2.6-3+b3 ii libsm6 2:1.2.2-1+b3 ii libtcl8.68.6.6+dfsg-1+b1 ii libtinfo56.0+20161126-1+deb9u2 ii libx11-6 2:1.6.4-3+deb9u1 ii libxt6 1:1.1.5-1 ii vim-common 2:8.0.0197-4+deb9u2 ii vim-gui-common 2:8.0.0197-4+deb9u2 ii vim-runtime 2:8.0.0197-4+deb9u2 vim-gtk3 recommends no packages. Versions of packages vim-gtk3 suggests: ii cscope15.8b-2 ii fonts-dejavu 2.37-1 ii gnome-icon-theme 3.12.0-2 pn vim-doc -- no debconf information
Bug#926884: distcc: Does not work with clang
> Package: distcc > Followup-For: Bug #926884 > > This package should not be released in Buster with this bug, > clang is an important compiler (and much easier for cross-compiling) > and not working with it is too big of a bug. I'm sorry but no. Your python script doesnt work for Debian See #920709 Christian
Bug#930762: pybigwig: autopkgtest fails because it tests non-existing python-pybigwig
Package: pybigwig Version: 0.3.16+dfsg-1 Severity: serious Tags: patch Justification: autopkgtest regression User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu eoan ubuntu-patch Hi Diane, The pybigwig package is failing its autopkgtests now in unstable, because debian/tests/control was not updated to account for the fact that the python2 binary package is no longer built: [...] autopkgtest [21:50:25]: test command1: preparing testbed Reading package lists... Building dependency tree... Reading state information... Correcting dependencies...Starting pkgProblemResolver with broken count: 1 Starting 2 pkgProblemResolver with broken count: 1 Investigating (0) autopkgtest-satdep:amd64 < 0 @iU mK Nb Ib > Broken autopkgtest-satdep:amd64 Depends on python-pybigwig:amd64 < none @un H > Removing autopkgtest-satdep:amd64 because I can't find python-pybigwig:amd64 Done Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following packages will be REMOVED: autopkgtest-satdep 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. [...] (https://ci.debian.net/packages/p/pybigwig/unstable/amd64/) The simple solution is to drop the python2 test from the package, as in the attached patch. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru pybigwig-0.3.16+dfsg/debian/tests/control pybigwig-0.3.16+dfsg/debian/tests/control --- pybigwig-0.3.16+dfsg/debian/tests/control 2019-05-03 08:55:38.0 -0700 +++ pybigwig-0.3.16+dfsg/debian/tests/control 2019-06-19 23:01:34.0 -0700 @@ -1,12 +1,4 @@ Test-Command: set -e - ; for py in $(pyversions -r 2>/dev/null) - ; do cd pyBigWigTest - ; $py test.py - ; cd .. - ; done -Depends: python-pybigwig, python-all - -Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd pyBigWigTest ; $py test.py
Bug#930666: Please document consensus on use of dh sequencer
Hello Russ, On Tue 18 Jun 2019 at 06:24PM -07, Russ Allbery wrote: > For those reading this, note that "recommended" is a documented keyword in > Policy, equivalent to "should." However, it is intentionally weakened > here with the "in the absence of a reason to use a different approach" > language. The goal here (and please judge whether I achieved it) is to > concentrate on providing default advice to people with no preference, > particularly people new to packaging, not to argue with maintainers who > are familiar with the tradeoffs and are intentionally making a different > choice. This seems like the right goal but I'm not sure your patch quite achieves it yet. > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index ee9270d..9ea2f5c 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -259,18 +259,49 @@ files, sockets or setuid or setgid files.. [#]_ > Main building script: ``debian/rules`` > -- > > -This file must be an executable makefile, and contains the > -package-specific recipes for compiling the package and building binary > -package(s) from the source. > - > -It must start with the line ``#!/usr/bin/make -f``, so that it can be > -invoked by saying its name rather than invoking ``make`` explicitly. > -That is, invoking either of ``make -f debian/rules args...`` or > ``./debian/rules args...`` must result in identical behavior. > +This file must be an executable makefile. It contains the > +package-specific recipes for compiling the source (if required) and > +constructing one or more binary packages. > + > +``debian/rules`` must start with the line ``#!/usr/bin/make -f`` so that > +it can be executed by running ``./debian/rules`` from the top of the > +source package. Invoking either of ``make -f debian/rules ...`` or > +``./debian/rules ...`` must result in identical behavior. I must admit to being sad to see the demise of "invoked by saying its name", but this is probably a sensible change. A tiny thing is that you seem to have switched "" for "", which seems wrong. > + > +In the absence of a reason to use a different approach, the recommended > +way to implement the build process of a Debian package, including the > +contents of the ``debian/rules`` building script, is the ``dh`` tool, > +which is provided by the debhelper package. This is the most common > +packaging helper tool in Debian. Using it will save effort in complying > +with the rules in this document, since it will automatically implement > +many of them without requiring explicit instructions. I would like to try to make the first sentence normatively clearer. I think that it would be difficult to understand exactly what the project consensus is from that sentence, had you not read Sam's d-d-a post. Let me try to express what I think the problem is. What the first sentence says, given the equivalence of RECOMMENDED and SHOULD noted above, is "you should use dh unless there is a reason not to use dh". However, any SHOULD requirement in Policy implicitly has that structure: "you should X unless there is reason not to X". Perhaps MUST requirements don't have that implicit structure, because perhaps the idea in such cases is that there is never reason not to X. Thus, your sentence seems to just be making explicit something which is already implicit in any SHOULD requirement, i.e., "In the absence ..." is strictly redundant. And so I don't think the sentence succeeds in expressing the nuanced project consensus which it aims to express, because the consensus is more nuanced than just the implicit structure had by any SHOULD requirement. Would it be right to say that what we are trying to express is the idea that dh should be used when there aren't *package-specific* reasons not to use dh, and for new packages, we're recommending a workflow of starting with the assumption that no such package-specific reasons exist? This captures the idea that dh makes things easier for other contributors working on your package, which seems core to the project's consensus. > + > +There are various situations in which ``dh`` is not the best choice. For > +example, the standard tools for packaging software written in some > +languages may use another tool, some rarer packaging patterns (such as > +multiple builds of the same software with different options) are easier to > +express with other tools, or the packager may be working on a new > +packaging helper and may therefore want to use that tool. Using ``dh`` is > +therefore not required. But it is a wise default choice in most > +situations. > + > +If the package uses ``dh``, the default content of ``debian/rules`` will > +be:: I find the expression "default content" odd in this context, I think because defaults are things that executable programs have, not source code. Can I suggest we talk instead about the "starting point for the content of d/rules" and say something like "this starting point is of
Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0
[updating CC to point to the newly-filed RFP] Hello Johannes, Thank you again for looking into this. On Sat 08 Jun 2019 at 09:52pm +0200, Johannes Schauer wrote: > after my struggles in #930212 I now figured out how to compile stuff against > the static library in libmupdf-dev. As a result I managed to package PyMuPDF. > You can see the result here: > > https://salsa.debian.org/python-team/modules/pymupdf > > It's mostly Lintian-clean and just waiting for somebody who feels like > maintaining it in the future. :) I've had a look at your repo. I've got a few questions and comments (relevant to whomever wants to take ownership of the ITP and upload this to NEW). A tool called SWIG, with which I'm unfamiliar, was used to generate fitz/fitz.py from the files fitz/*.i, but this tool does not get run during the package build. There could be updates to SWIG, including security updates, which would change fitz.py. It seems to me that we want to run SWIG during the package build to ensure that fitz.py reflects all improvements made to SWIG since pymupdf upstream ran that tool when releasing pymupdf. Secondly, how do you foresee us triggering binNMUs to rebuild this package when the static library in libmupdf-dev changes? We would need to be sure that this package gets rebuilt if a security update was made to libmupdf-dev, for example, or the vulnerable version of mupdf would still be present in this package. PDF libraries tend to get CVEs, to put it mildly. I'm worried we've the same sort of problem as discussed in #928227. Finally, I noticed that the project looks to be GPL-3 not GPL-3+, though I haven't looked through every file in the source. I also haven't thought carefully about the implications of statically linking a project that's under the AGPL. I think that we can do it, but I'm not sure quite what license the binary package will end up with, and quite how to document that in d/copyright. -- Sean Whitton
Bug#930659: libapache-session-perl: poor source of entropy for session id generation
Le 18/06/2019 à 09:56, Xavier a écrit : > Le 18/06/2019 à 09:46, Xavier a écrit : >> Le 17/06/2019 à 22:44, Raphael Geissert a écrit : >>> Package: libapache-session-perl >>> Version: 1.93-3 >>> Severity: important >>> Tags: security >>> >>> Hi, >>> >>> As discussed in oss-security[1], libapache-session-perl uses a poor >>> source of entropy in Apache::Session::Generate::MD5. The critical part >>> is moving away from rand (e.g. to using urandom), but it would also be >>> a good time to update the way the id is generated. >>> >>> The details are in the oss-sec thread. >>> >>> [1] https://www.openwall.com/lists/oss-security/2019/06/15/1 >>> >>> Cheers, >> >> Hi all, >> >> lemonldap-ng is not affected by this issue even if it depends on >> Apache::Session: it uses its own >> Lemonldap::NG::Common::Apache::Session::Generate::SHA256 which uses >> Crypt::URandom instead of rand(). This can be easily backported to >> Apache::Session but changes the generated id: SHA256 is longer. > > This is true for lemonldap-ng ≥ 2.0.2 (buster), 1.9.x versions (stretch) > are concerned by this issue. > > Fix is referenced here: > https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1633 I proposed a fix here: https://salsa.debian.org/perl-team/modules/packages/libapache-session-perl/merge_requests/1 Cheers, Xavier
Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x and i386
I am attaching a patch for skcms that fixes the firefox build on s390x and i386. Not submitted upstream yet. Description: work around a GCC bug that results in build failures on i386 and s390x Author: Olivier Tilloy Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930012 --- a/gfx/skia/skia/third_party/skcms/src/Transform_inl.h +++ b/gfx/skia/skia/third_party/skcms/src/Transform_inl.h @@ -559,7 +559,7 @@ SI void sample_clut_16(const skcms_A2B* // GCC 7.2.0 hits an internal compiler error with -finline-functions (or -O3) // when targeting MIPS 64, I think attempting to inline clut() into exec_ops(). -#if 1 && defined(__GNUC__) && !defined(__clang__) && defined(__mips64) +#if 1 && defined(__GNUC__) && !defined(__clang__) && (defined(__mips64) || defined(__i386) || defined(__s390x__)) #define MAYBE_NOINLINE __attribute__((noinline)) #else #define MAYBE_NOINLINE
Bug#929564: gatb-core-testdata: broken symlink: /usr/share/doc/gatb-core/test/gatb-core-cppunit -> ../../../../lib/gatb-core/gatb-core-cppunit
Hi Andreas, On Sun, May 26, 2019 at 10:45:43AM +0200, Andreas Beckmann wrote: > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > >From the attached log (scroll to the bottom...): > > 0m20.3s ERROR: FAIL: Broken symlinks: > /usr/share/doc/gatb-core/test/gatb-core-cppunit -> > ../../../../lib/gatb-core/gatb-core-cppunit (gatb-core-testdata) > > The target does not seem to exist in any package in the archive. That's actually quite strange. In local builds using pbuilder the file /usr/lib/gatb-core/gatb-core-cppunit is created and part of the package gatb-core. However, it seems the package build by the autobuilders after uploading the source package is lacking the file. I admit I have no idea how this can happen. I just observed this with the recently uploaded gatb-core_1.4.1+git20181225.44d5a44+dfsg-3. Kind regards Andreas. -- http://fam-tille.de
Bug#930761: RFP: PyMuPDF -- python bindings for MuPDF
Package: wnpp Severity: wishlist * Package name: pymupdf Version : 1.14.16 Upstream Author : Ruikai Liu and Jorj X. McKie * URL : https://github.com/pymupdf/PyMuPDF * License : GPL-3 Programming Lang: Python Description : python bindings for MuPDF josch provides this long description: Allows one to access files in PDF, XPS, OpenXPS, CBZ, EPUB, and FB2 (e-books) formats, and it is known for its top performance and high rendering quality. . PDF manipulation and generation functions are available, including metadata and bookmark maintenance, document restructuring, annotation / link handling and document or page creation. -- Sean Whitton signature.asc Description: PGP signature
Bug#930760: aoeui FTCBFS: does not pass cross tools to make
Source: aoeui Version: 1.7+20160302.git4e5dee9-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs aoeui fails to cross build from source, because it does not pass cross tools to make. The easiest way of doing so - using dh_auto_build - makes aoeui cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru aoeui-1.7+20160302.git4e5dee9/debian/changelog aoeui-1.7+20160302.git4e5dee9/debian/changelog --- aoeui-1.7+20160302.git4e5dee9/debian/changelog 2018-01-04 21:25:32.0 +0100 +++ aoeui-1.7+20160302.git4e5dee9/debian/changelog 2019-06-20 06:01:06.0 +0200 @@ -1,3 +1,10 @@ +aoeui (1.7+20160302.git4e5dee9-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Thu, 20 Jun 2019 06:01:06 +0200 + aoeui (1.7+20160302.git4e5dee9-1) unstable; urgency=medium * New upstream release diff --minimal -Nru aoeui-1.7+20160302.git4e5dee9/debian/rules aoeui-1.7+20160302.git4e5dee9/debian/rules --- aoeui-1.7+20160302.git4e5dee9/debian/rules 2018-01-04 21:25:32.0 +0100 +++ aoeui-1.7+20160302.git4e5dee9/debian/rules 2019-06-20 06:01:05.0 +0200 @@ -12,7 +12,7 @@ dh_auto_clean override_dh_auto_build: - $(MAKE) aoeui aoeui.1 asdfg.1 + dh_auto_build -- aoeui aoeui.1 asdfg.1 override_dh_auto_install: dh_auto_install
Bug#906518: qa.debian.org: Missing manpages webpage links to seemingly dead project
I contacted him and the reply was: > Thanks for contacting me, but I'm afraid those efforts > are long dead. Please remove the links. On Wed, Jun 19, 2019 at 9:05 PM Stephen Gelman wrote: > > Great point I totally missed that before. I'll contact them! > > On Wed, Jun 19, 2019 at 9:02 PM Paul Wise wrote: > > > > On Sat, Aug 18, 2018 at 5:03 AM Stephen Gelman wrote: > > > > > It seems that the "Missing Man Pages Project" [1] linked to from the > > > missing manpages qa page [2] is no longer an active project. The project > > > page linked is gone (and seems to have been gone since 2013 at least) and > > > I can't seem to find any replacement for it. Therefore, it seems that > > > the link, along with the suggestion to submit man pages to it, should be > > > removed. > > > > > > [1] http://www.netmeister.org/misc/m2p2/index.html > > > [2] http://qa.debian.org/man-pages.html > > > > The link is 403, which implies that this is caused by (umask) > > misconfiguration rather than removal. Instead of removing the link, I > > suggest contacting the maintainer of the page and asking them about > > the status. Their blog is active and they list their contact > > information on the front page of their website. > > > > -- > > bye, > > pabs > > > > https://wiki.debian.org/PaulWise
Bug#930759: mokutil(1) refers to non-existent "--enroll-validation"
Package: mokutil Version: 0.3.0+1538710437.fb6250f-1 Severity: minor mokutil(1) has this to say about "validation": mokutil [--disable-validation] mokutil [--enable-validation] [...] --disable-validation Disable the validation process in shim --enrolled-validation Enable the validation process in shim This seems like a contradiction: is it `enrolled` or `enable`? I tried `enable` and it worked, so maybe it's the first? In any case, it seems the manpage should be fixed. For some mysterious reason, `mokutil --enable-validation` is the magic thing I had to do to get secureboot working here. I have no idea what it does and the manpage doesn't really explain that beyond saying "it enables the validation, duh". It would be great if the docs would actually say what that thing actually does so I'm not totally in the dark about what i'm doing with this uber secure thing. :) Why does that thing prompt for a password anyways? A. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.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 mokutil depends on: ii libc6 2.28-10 ii libefivar1 37-2 ii libssl1.1 1.1.1c-1 mokutil recommends no packages. mokutil suggests no packages. -- debconf-show failed
Bug#906518: qa.debian.org: Missing manpages webpage links to seemingly dead project
Great point I totally missed that before. I'll contact them! On Wed, Jun 19, 2019 at 9:02 PM Paul Wise wrote: > > On Sat, Aug 18, 2018 at 5:03 AM Stephen Gelman wrote: > > > It seems that the "Missing Man Pages Project" [1] linked to from the > > missing manpages qa page [2] is no longer an active project. The project > > page linked is gone (and seems to have been gone since 2013 at least) and I > > can't seem to find any replacement for it. Therefore, it seems that the > > link, along with the suggestion to submit man pages to it, should be > > removed. > > > > [1] http://www.netmeister.org/misc/m2p2/index.html > > [2] http://qa.debian.org/man-pages.html > > The link is 403, which implies that this is caused by (umask) > misconfiguration rather than removal. Instead of removing the link, I > suggest contacting the maintainer of the page and asking them about > the status. Their blog is active and they list their contact > information on the front page of their website. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise
Bug#906518: qa.debian.org: Missing manpages webpage links to seemingly dead project
On Sat, Aug 18, 2018 at 5:03 AM Stephen Gelman wrote: > It seems that the "Missing Man Pages Project" [1] linked to from the missing > manpages qa page [2] is no longer an active project. The project page linked > is gone (and seems to have been gone since 2013 at least) and I can't seem to > find any replacement for it. Therefore, it seems that the link, along with > the suggestion to submit man pages to it, should be removed. > > [1] http://www.netmeister.org/misc/m2p2/index.html > [2] http://qa.debian.org/man-pages.html The link is 403, which implies that this is caused by (umask) misconfiguration rather than removal. Instead of removing the link, I suggest contacting the maintainer of the page and asking them about the status. Their blog is active and they list their contact information on the front page of their website. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#926884: distcc: Does not work with clang
severity -1 serious Message-ID: <156099516006.31749.3126069341315892890.reportbug@big-daddy.novalocal> X-Mailer: reportbug 7.5.2 Date: Wed, 19 Jun 2019 21:46:00 -0400 X-Debbugs-Cc: sh...@git.icu Package: distcc Followup-For: Bug #926884 This package should not be released in Buster with this bug, clang is an important compiler (and much easier for cross-compiling) and not working with it is too big of a bug. 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.19.0-5-powerpc64le (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages distcc depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.72 ii init-system-helpers1.56+nmu1 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.2019051400 ii netbase5.6 distcc recommends no packages. Versions of packages distcc suggests: ii ccache 3.7.1-1 ii dbus 1.12.16-1 pn distcc-pump pn distccmon-gnome pn dmucs
Bug#930721: vim: Syntax highlighting breaks if buffer is reopened/reused or `:syntax on` is repeated
Control: severity -1 normal Control: merge -1 930718 Control: notfound -1 2:8.0.0197-4+deb9u1 Control: tags -1 patch fixed-upstream (I believe this bug, as annoying as it is, fits the definition of a "normal" severity bug. I wouldn't have changed it, but AFAIK merging multiple bugs requires their severity to be the same.) Looks to me like patch 8.0.0066 (which was part of the mass backporting to fix CVE-2019-12735) causes this bug, and patch [8.1.0067] fixes it, but was missed. [8.1.0067] https://github.com/vim/vim/commit/a5616b0136cea2104a475d143a1685d71e9b2d3d I've built up a local copy of this package with the patch added, and the bug is gone. As an aside, are the vim unit tests fun to watch or what?
Bug#818046: cwidget: keybindings::get(std::string tag) should use tag as case-insensitive
Control: tags -1 + pending 2016-03-13 02:37 Manuel A. Fernandez Montecelo: Source: cwidget Version: 0.5.17-4 Severity: important When inserting with set() the tag it's stored as uppercase, so get() should do the same transformation, otherwise it's confusing and appears to be buggy. This has been committed for 0.5.19, marking as pending. -- Manuel A. Fernandez Montecelo
Bug#928032: Default configuration for USBGuard
On Fri, Apr 26, 2019 at 03:10:19PM +0200, Thiébaud Weksteen wrote: > Does anyone have any preference? I think minimizing the number of prompts to the user would be preferable, honestly. I would do the following changes in the Debian package: 1. PresentDevicePolicy=keep - just to avoid breaking existing setups will still providing *some* security for new devices (although the rule generation thing does that, this is easier to implement in the Debian package). Note that I am not clear on the difference between =keep and =allow, so take this with a grain of salt. Upstream says this is preferably kept to apply-policy because an attacker might crash the USBguard daemon to get their device rejected, but I'm not sure it's that much of a threat model. 2. Add `plugdev` to the IPCAllowedGroups setting. It's commonly the group that is allowed to deal with pluggable devices, and it's not a big compromise to allow them to decide what gets plugged in or not. This ensures that normal users can interact with the USBguard daemon and do stuff in case the above fails. I think enforcing new devices confirmation then becomes safe enough and meaningful, without having to otherwise prompt the user. A.
Bug#930758: runit: Add a test for switching init (systemd-->runit)
Package: runit Version: 2.1.2-31 Severity: wishlist Tags: patch -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT) Kernel taint flags: 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: runit (via /run/runit.stopit) Versions of packages runit depends on: ii libc6 2.28-10 ii runit-helper2.8.10 ii sysuser-helper 1.3.3 Versions of packages runit recommends: ii runit-init 2.1.2-30 runit suggests no packages. -- Configuration Files: /etc/runit/3 changed [not included] -- no debconf information Hi, while experimenting with autopkgtest i manage to write a small test that, starting from a systemd qemu machine, installs runit-init and reboot into it, checking if there is a working getty to login with and if essential services (syslog, udev ..) are up. While the test is very simple it could be useful to have something like this around to make sure that the compat layer in /run/initctl will not get broken (by systemd) and that some future development in stage1/2 will not break the runit-init boot. I have tested it on my pc, the last attach is the output of the test Lorenzo >From d02fbb0e7e3a66ca463bf96b9f5fb1057856fe60 Mon Sep 17 00:00:00 2001 From: Lorenzo Puliti Date: Thu, 20 Jun 2019 00:47:17 +0200 Subject: [PATCH 1/3] Provide a service for a getty on serial tty Provide a getty-ttyS0 service; this is needed by autopkgtest for connecting with the testbed (qemu), otherwise a reboot into a runit-init VM will fail the test. --- debian/getty-ttyS0/run | 8 debian/runit.install | 1 + 2 files changed, 9 insertions(+) create mode 100755 debian/getty-ttyS0/run diff --git a/debian/getty-ttyS0/run b/debian/getty-ttyS0/run new file mode 100755 index 000..31dccf6 --- /dev/null +++ b/debian/getty-ttyS0/run @@ -0,0 +1,8 @@ +#!/bin/sh +NAME=getty-ttyS0 +if pgrep -x agetty -t ttyS0; then +sv d getty-ttyS0 +echo "already another getty on ttyS0" +fi +exec 2>&1 +exec chpst -P fgetty /dev/ttyS0 diff --git a/debian/runit.install b/debian/runit.install index 40a9466..a9a72fe 100644 --- a/debian/runit.install +++ b/debian/runit.install @@ -21,5 +21,6 @@ runit-2.1.2/src/runit /sbin debian/contrib/shutdown /lib/runit debian/contrib/runlevel /lib/runit debian/sulogin/run /etc/runit/runsvdir/single/sulogin +debian/getty-ttyS0/run /etc/sv/getty-ttyS0 debian/contrib/lib/async-timeout/lib/runit debian/contrib/lib/run_sysv_scripts /lib/runit -- 2.20.1 >From 374b79ae1c811b668668f22f57e77a6d352670a4 Mon Sep 17 00:00:00 2001 From: Lorenzo Puliti Date: Mon, 17 Jun 2019 14:43:55 +0200 Subject: [PATCH 2/3] Prepare source for autopkgtest Add a stanza in debian/control and a debian/tests directory needed for autopkgtest --- debian/control | 1 + debian/tests/control | 1 + 2 files changed, 2 insertions(+) create mode 100644 debian/tests/control diff --git a/debian/control b/debian/control index 23300e5..0764231 100644 --- a/debian/control +++ b/debian/control @@ -13,6 +13,7 @@ Build-Depends: bash-completion, doc-base, Vcs-Browser: https://salsa.debian.org/debian/runit Vcs-Git: https://salsa.debian.org/debian/runit.git +Testsuite: autopkgtest Package: runit Architecture: any diff --git a/debian/tests/control b/debian/tests/control new file mode 100644 index 000..8d1c8b6 --- /dev/null +++ b/debian/tests/control @@ -0,0 +1 @@ + -- 2.20.1 >From b37238455025ca36c7795c96d934205016cde026 Mon Sep 17 00:00:00 2001 From: Lorenzo Puliti Date: Mon, 17 Jun 2019 16:05:00 +0200 Subject: [PATCH 3/3] add a test for switching to runit-init Add a smoke test for the switch systemd --> runit-init --- debian/tests/control | 8 +- debian/tests/init-switch | 60 2 files changed, 67 insertions(+), 1 deletion(-) create mode 100755 debian/tests/init-switch diff --git a/debian/tests/control b/debian/tests/control index 8d1c8b6..02565b5 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1 +1,7 @@ - +Tests: init-switch +Depends: runit, + runit-init, + getty-run, + fgetty, + psmisc, +Restrictions: needs-root, isolation-machine, breaks-testbed diff --git a/debian/tests/init-switch b/debian/tests/init-switch new file mode 100755 index 000..1e09238 --- /dev/null +++ b/debian/tests/init-switch @@ -0,0 +1,60 @@ + #!/bin/sh + set -e + + + if [ -z "$AUTOPKGTEST_REBOOT_MARK" ]; then +if [ -d /run/systemd/system ]; then +init=systemd +elif [ -e /run/initctl ]; then +init=sysv +else +init=unknown-init +fi +echo "testbed is running with $init" + +if [ -e /tmp/autopkgtest-reboot ]; then +echo "enabling the serial getty" +
Bug#896181: cwidget: [PATCH] Use %p for pointers instead of %x
Control: tags -1 + pending 2018-04-20 16:42 Manuel A. Fernandez Montecelo: Source: cwidget Version: 0.5.17-7 Severity: normal Tags: patch upstream Hi, Attaching patch from Ahmed Charles sent to the mailing list a while ago: https://alioth-lists-archive.debian.net/pipermail/cwidget-devel/2016-March/000251.html Applied now in the upstream branch for 0.5.19. -- Manuel A. Fernandez Montecelo
Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth
Ach, sigh, Steffen Nurpmeso wrote in <20190619234414.zvcpd%stef...@sdaoden.eu>: ... |Dear Ivan. If you are willing to test once again, at [1] there is |a complete ball, but you could also simply apply the attached |patch instead, which is very much smaller. | |I am sorry for the inconvenience, and i hope this fixes GSSAPI. ... the patch was reversed; here is the right one. Ciao! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) diff --git a/src/mx/obs-imap-gssapi.h b/src/mx/obs-imap-gssapi.h index 18d0844a..4a961b2b 100644 --- a/src/mx/obs-imap-gssapi.h +++ b/src/mx/obs-imap-gssapi.h @@ -299,14 +299,13 @@ jebase64: /* First octet: bit-mask with protection mechanisms (1 = no protection *mechanism). * Second to fourth octet: maximum message size in network byte order. -* Fifth and following octets: user name string. -*/ +* Fifth and following octets: user name string */ + su_mem_copy(&o[4], ccred->cc_user.s, ccred->cc_user.l +1); o[0] = 1; o[1] = 0; - o[2] = o[3] = (char)0377; - snprintf(&o[4], sizeof o - 4, "%s", ccred->cc_user.s); + o[2] = o[3] = S(char,0xFF); + send_tok.length = 4 + ccred->cc_user.l; send_tok.value = o; - send_tok.length = su_cs_len(&o[4]) -1 + 4; maj_stat = gss_wrap(&min_stat, gss_context, 0, GSS_C_QOP_DEFAULT, &send_tok, &conf_state, &recv_tok); f |= a_F_RECV_TOK;
Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth
Hello and good evening, Ivan. Ivan Vučica wrote in : |On Wed, Jun 19, 2019 at 2:56 PM Steffen Nurpmeso \ |wrote: |>> What would be further useful debugging or tracing information to |>> share? |> |> In general our -d or -vv switches would be nice. ^_^ | |Here's with -d: ... |>>> T2 AUTHENTICATE GSSAPI |>>> SERVER: + |>>> YIIFhgOMITTING-WHAT-LOOKS-LIKE-CREDENTIALS3tM= |>>> SERVER: + YIGVBOMITTING-WHAT-LOOKS-LIKE-CREDENTIALSZIXw= |[6655] 1560952720.212835: Read AP-REP, time 1560952720.212831, subkey |aes256-cts/B91D, seqnum 73895367 |>>> |>>> SERVER: + BQOMITTINGu58= |>>> BQCREDENTIALS8E= |>>> SERVER: T2 NO [AUTHENTICATIONFAILED] Authentication failed. |IMAP error: [AUTHENTICATIONFAILED] Authentication failed. | |It is really hard to follow the debug info given, and the amount of |info changed between the old and new s-nail. But eyeballing the |credentials sent in both versions, there is nothing obviously damaged |in authentication lines. I should have warned you that the password and credentials will be included in the debug output. You could of course do "set verbose" twice when in interactive mode, then the entire load phase would not be logged. Doing logging right is hard; maybe, some day, it will be possible to have some log filter, which can select by source, or so. In days where you can inspect/adjust running kernels via DTrace and BPF, almost anything is very primitive in comparison. Hm. I am sorry, but i think there was another false length calculation. Yes, the thing is that i had "implemented" SMTP GSSAPI, and that uses string buffers etc. and not (sn)printf(3) on a stack buffer to do simple string concatenations, and when i "fixed" the GSSAPI token length calculation in commit [384c8e2e] (before we included the C string terminator NUL, which is not valid according to GSSAPI standard, yet it worked for almost two decades), i did that by having the IMAP and the SMTP GSSAPI headers side-by-side. I am afraid that i got pi.s.d when seeing the snprintf()s and the string length calls (even if the length is known) in the IMAP one. Also, you know, IMAP code had been removed from the codebase for over a year, it was reinstantiated on user request only. (Again signal jumps and blocking I/O, and IMAP being the largest piece of code going that route. And that is not the way i want this software to go, as it means the entire codebase is stuck at a single place, it is entirely sequential, whereas i want the possibility to have multiple boxes open at the same time, for example. Which does not work, currently. For example.) Dear Ivan. If you are willing to test once again, at [1] there is a complete ball, but you could also simply apply the attached patch instead, which is very much smaller. I am sorry for the inconvenience, and i hope this fixes GSSAPI. It would be great if you could report success! (I will not be able to setup a GSSAPI box before the 22nd, when my internet limit is refreshed. (I have exceeded my limit and the ISDN that i should get nonetheless seems to be implemented virtually via some kind of scheduler, and that is a killer.)) [1] https://git.sdaoden.eu/cgit/s-nail.git/snapshot/s-nail-6b070335d77251308e1910f9efb2e08754a1f176.tar.xz |I could be wrong, of course. No, i think there was another mutilated length involved. |> ... |>|ivucica@myhostname:~$ klist |>|Credentials cache: FILE:/tmp/krb5cc_501 |>|Principal: ivuc...@ds.mydomainname.net |>| |>| IssuedExpires Principal |>|Jun 19 11:25:37 2019 Jun 19 21:25:37 2019 krbtgt/DS.MYDOMAINNAME.NET@D\ |>|S.MYDOMAINNAME.NET \ |> ... |> fail |> ... | |No, this is actually success. I kdestroyed the ticket cache |beforehand, and kinited. And isn't that cooler than OAUTH? And no advertising, neither yesterday nor today and very likely also tomorrow not. |This is the 'krbtgt' - 'kerberos ticket-granting-ticket' which is used |to get service-specific tickets. | |I pasted this to demonstrate that GSSAPI is invoked correctly to |obtain the service-specific ticket when launching the newly-built |s-nail. That is: GSSAPI manages to get |imap/myhostname.ds.mydomain@ds.mydomainname.net ticket, usable to |authenticate against Dovecot. Thank you. Yes, a pity. All my fault. |>|ivucica@myhostname:~$ klist |>|Credentials cache: FILE:/tmp/krb5cc_501 |>|Principal: ivuc...@ds.mydomainname.net |>| |>| IssuedExpires Principal |>|Jun 19 11:25:37 2019 Jun 19 21:25:37 2019 krbtgt/DS.MYDOMAINNAME.NET@D\ |>|S.MYDOMAINNAME.NET \ |>| |>|Jun 19 11:25:42 2019 Jun 19 21:25:37 2019 imap/myhostname.ds.mydomainn\ |>|ame@ds.mydomainname.net\ |> ... |> ok |> ... |> |> But say, the succeeding klist shows one more issued principal? |> I must admit that for the last four
Bug#930757: Acknowledgement (unblock: grub2/2.02+dfsg1-19)
I forgot to mention that there are -signed source packages that must go with this, so the unblock lines should in fact be: unblock grub2/2.02+dfsg1-19 unblock grub-efi-amd64-signed/1+2.02+dfsg1+19 unblock grub-efi-arm64-signed/1+2.02+dfsg1+19 unblock grub-efi-ia32-signed/1+2.02+dfsg1+19 (The -signed packages are a couple of days too young at the moment.) Thanks, -- Colin Watson [cjwat...@debian.org] signature.asc Description: PGP signature
Bug#930757: unblock: grub2/2.02+dfsg1-19
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock grub2.
I hope this is the final grub2 update for the buster release. It
consists mainly of a number of patches from Steve McIntyre to clean up
problems with our UEFI Secure Boot support.
diff -Nru grub2-2.02+dfsg1/debian/.git-dpm grub2-2.02+dfsg1/debian/.git-dpm
--- grub2-2.02+dfsg1/debian/.git-dpm2019-05-04 22:58:32.0 +0100
+++ grub2-2.02+dfsg1/debian/.git-dpm2019-06-14 19:04:01.0 +0100
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-9569221816a2a1a832be106440375a612e0121b7
-9569221816a2a1a832be106440375a612e0121b7
+6ee5cc98ec6ca10e00d9cd23a969f0b12ae7ab2e
+6ee5cc98ec6ca10e00d9cd23a969f0b12ae7ab2e
59aeb1cfaa3d5bfd7bb0f0d37f6d9eed51fe
59aeb1cfaa3d5bfd7bb0f0d37f6d9eed51fe
grub2_2.02+dfsg1.orig.tar.xz
diff -Nru grub2-2.02+dfsg1/debian/build-efi-images
grub2-2.02+dfsg1/debian/build-efi-images
--- grub2-2.02+dfsg1/debian/build-efi-images2019-05-04 22:58:32.0
+0100
+++ grub2-2.02+dfsg1/debian/build-efi-images2019-06-14 19:04:01.0
+0100
@@ -20,16 +20,17 @@
# Make EFI boot images for signing.
-if [ $# -lt 5 ]; then
- echo "usage: $0 GRUB-MKIMAGE GRUB-CORE OUTPUT-DIRECTORY PLATFORM
EFI-NAME [EFI-VENDOR]"
+if [ $# -lt 6 ]; then
+ echo "usage: $0 GRUB-MKIMAGE GRUB-CORE OUTPUT-DIRECTORY DEB-ARCH
PLATFORM EFI-NAME [EFI-VENDOR]"
fi
grub_mkimage="$1"
grub_core="$2"
outdir="$3"
-platform="$4"
-efi_name="$5"
-efi_vendor="${6:-$(dpkg-vendor --query vendor | tr '[:upper:]' '[:lower:]')}"
+deb_arch="$4"
+platform="$5"
+efi_name="$6"
+efi_vendor="${7:-$(dpkg-vendor --query vendor | tr '[:upper:]' '[:lower:]')}"
# mkfs.msdos may not be on the default PATH.
export PATH="$PATH:/sbin:/usr/sbin"
@@ -115,6 +116,7 @@
memdisk
minicmd
normal
+ ntfs
part_apple
part_msdos
part_gpt
@@ -141,7 +143,9 @@
case $platform in
x86_64-efi|i386-efi)
CD_MODULES="$CD_MODULES
+ cpuid
linuxefi
+ play
"
;;
esac
@@ -181,15 +185,29 @@
tftp
"
+# CD boot image
"$grub_mkimage" -O "$platform" -o "$outdir/gcd$efi_name.efi" \
-d "$grub_core" \
-c "$workdir/grub-bootstrap.cfg" -m "$workdir/memdisk.fat" \
-p /boot/grub \
$CD_MODULES
+
+# Normal disk boot image
"$grub_mkimage" -O "$platform" -o "$outdir/grub$efi_name.efi" \
-d "$grub_core" -p "/EFI/$efi_vendor" $GRUB_MODULES
+
+# Normal network boot image
"$grub_mkimage" -O "$platform" -o "$outdir/grubnet$efi_name.efi" \
-d "$grub_core" -c "$workdir/grub-bootstrap.cfg" \
- -m "$workdir/memdisk-netboot.fat" -p /grub $NET_MODULES
+ -m "$workdir/memdisk-netboot.fat" \
+ -p /grub $NET_MODULES
+
+# Special network boot image for d-i to use. Just the same as the
+# normal network boot image, but with a different value baked in for
+# the prefix setting
+"$grub_mkimage" -O "$platform" -o "$outdir/grubnet$efi_name-installer.efi" \
+ -d "$grub_core" -c "$workdir/grub-bootstrap.cfg" \
+ -m "$workdir/memdisk-netboot.fat" \
+ -p "${efi_vendor}-installer/$deb_arch/grub" $NET_MODULES
exit 0
diff -Nru grub2-2.02+dfsg1/debian/changelog grub2-2.02+dfsg1/debian/changelog
--- grub2-2.02+dfsg1/debian/changelog 2019-05-04 22:58:32.0 +0100
+++ grub2-2.02+dfsg1/debian/changelog 2019-06-14 19:04:01.0 +0100
@@ -1,3 +1,18 @@
+grub2 (2.02+dfsg1-19) unstable; urgency=medium
+
+ [ Colin Watson ]
+ * Fix format of debian/copyright.
+
+ [ Steve McIntyre ]
+ * Add the ntfs module to signed UEFI images. Closes: #923855
+ * Add the cpuid module to signed UEFI images. Closes: #928628
+ * Add the play module to signed UEFI images. Closes: #930290
+ * Add an extra di-specific version of the UEFI netboot image with a
+different baked-in prefix value. Helps to fix #928750.
+ * Deal with --force-extra-removable with signed shim too. Closes: #930531
+
+ -- Colin Watson Fri, 14 Jun 2019 19:04:01 +0100
+
grub2 (2.02+dfsg1-18) unstable; urgency=medium
* Apply patches from Alexander Graf to fix grub-efi-arm crash (closes:
diff -Nru grub2-2.02+dfsg1/debian/copyright grub2-2.02+dfsg1/debian/copyright
--- grub2-2.02+dfsg1/debian/copyright 2019-05-04 22:58:32.0 +0100
+++ grub2-2.02+dfsg1/debian/copyright 2019-06-14 19:04:01.0 +0100
@@ -1,4 +1,5 @@
-Name: GNU GRUB
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: GNU GRUB
Source: https://www.gnu.org/software/grub/
Files-Excluded: grub-core/lib/libgcrypt*/cipher/crc.c
diff -Nru grub2-2.02+dfsg1/debian/patches/grub-install-removable-shim.patch
grub2-2.02+dfsg1/debian/patches/grub-install-removable-shim.patch
--- grub2-2.02+dfsg1/debian/patches/grub-install-removable-shim.patch
1970-01-01 01:00:00.0 +0100
+++ grub2-2.02+dfsg1/debian/patches/grub-install-removable-shim.
Bug#929318: [pcp] Bug#929318: unblock: papi/5.7.0+dfsg-1
Hi Paul, Andreas, Apologies for the slow response - I'm in meetings all week this week and I'm a bit behind as a result. On Thu, Jun 20, 2019 at 9:17 AM Andreas Beckmann wrote: > > On 18/06/2019 23.05, Paul Gevers wrote: > > pcp was completely off my radar since it has (silently) dropped all papi > dependencies in unstable. The PAPI metrics in PCP have been transitioned to using perfevent - one of the several reasons for this was to help resolve this Debian bug. The best outcome for Debian PCP user base here would be to use the bugfix PCP update that has been in unstable for several weeks now - this provides a clean upgrade path for pmdapapi users, and removes the PCP dependency on PAPI completely. > I'll do a 0-day NMU of pcp on Thursday (36 hours from now) unless we > heard from Nathan till then. If we cannot use the tested, stable, upstream bugfix update provided earlier due to the release constraints, please go ahead and NMU as needed Andreas - thanks. > Just thinking ... lazy removal of libpapi5 from testing does not work, > since libpapi5.7 breaks it, and pcp-dev probably depends transitively on FWIW, the PCP development packages do not depend on any PAPI (and never have) - it is only older versions of the 'pcp' package itself, which contain the pmdapapi binary - now retired to help resolve this issue. cheers. -- Nathan
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
On Wed, 19 Jun 2019 22:16:58 +0200 Ansgar Burchardt wrote: > Jonathan Dowland writes: > > So far as I am aware there is still radio silence from active GNOME > > packaging team members regarding this issue. No comment yet on the > > patch I adapted, positive or negative; this bug (#927667) remains > > at an RC severity. > > > > I've not yet read all the thread that Samuel linked to[1] but it looks > > like it leans in favour of preserving the current default (xorg). > > > > I'm copying -release team to see if they have any (new) opinions on > > the matter. Otherwise I guess it's up to someone to prepare an NMU > > upload, which I will *try* to look at in the next few days, but can't > > make any guarantees. > > I'm just a GNOME user, but from gdm3's changelog the default was > switched to Wayland in July 2017 (or August 2017 for unstable). I > myself only noticed the switch after reading it happened somewhere on > the internet shortly after it happened. gdm was switched over to use Wayland before the main session was and in Debian we kept that default for gdm (even for stretch, and still true for buster). gdm runs in a much more limited environment though, so some of the limitations (like screen sharing) do not really affect the gdm session. I suppose the a11y issues that were pointed out for Wayland do affect the gdm wayland session though? What kind of display technology gdm is using is a separate discussion though from what kind of desktop session is started as default: GNOME on Xorg or GNOME on Wayland. When you talk about "gdm3's default", what exactly do you mean: the display technology gdm is using or the type of GNOME session that is started as default? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930756: unblock: movit/1.6.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package movit
It contains a single, focused fix for a severity=important bug that I found,
backported from upstream git.
It's a bit unclear to me whether “corrupted display” would count as appropriate
for buster unblocks, but I thought it might go under the “crashes etc.” heading
(it's technically undefined behavior with a thread race, but I don't think
there are any real GL drivers where this actually causes _crashes_ per se).
If not, please let me know.
From the upstream commit message; especially the part about ABI stability at
the end should be relevant:
Fix an issue where temporary textures could be reused too early by a
different thread.
When an EffectChain is done rendering (ie., has submitted all of the GL
rendering commands that it needs to), it releases all of the temporary
textures it's used back to a common freelist.
However, if another thread needs a texture of the same size and format,
it could be picking it off of the freelist before the GPU has actually
completed rendering the first thread's command list, and start uploading
into it. This is undefined behavior in OpenGL, and can create garbled
output depending on timing and driver. (I've seen this on at least the
classic Intel Mesa driver.)
Fix by setting fences, so that getting a texture from the freelist
will have an explicit ordering versus the previous work. This increases the
size of ResourcePool::TextureFormat, but it is only ever used in a private
std::map. std::map is node-based (it has to, since the C++ standard requires
iterators to it to be stable), and thus, sizeof(TextureFormat) does not
factor
into sizeof(ResourcePool), and thus, there is no ABI break. Verified by
checking on libstdc++.
diff -Nru movit-1.6.2/debian/changelog movit-1.6.2/debian/changelog
--- movit-1.6.2/debian/changelog2018-03-18 16:25:30.0 +0100
+++ movit-1.6.2/debian/changelog2019-06-15 20:08:45.0 +0200
@@ -1,3 +1,11 @@
+movit (1.6.2-2) unstable; urgency=high
+
+ * fix-temporary-texture-race-issue.diff: New patch backported from upstream
+git, fixes a threading issue where a thread could start reusing a temporary
+texture while it's still being used in rendering. (Closes: #930570)
+
+ -- Steinar H. Gunderson Sat, 15 Jun 2019 20:08:45 +0200
+
movit (1.6.2-1) unstable; urgency=medium
* New upstream release.
diff -Nru movit-1.6.2/debian/patches/fix-temporary-texture-race-issue.diff
movit-1.6.2/debian/patches/fix-temporary-texture-race-issue.diff
--- movit-1.6.2/debian/patches/fix-temporary-texture-race-issue.diff
1970-01-01 01:00:00.0 +0100
+++ movit-1.6.2/debian/patches/fix-temporary-texture-race-issue.diff
2019-06-15 20:08:37.0 +0200
@@ -0,0 +1,50 @@
+Index: movit-1.6.2/resource_pool.cpp
+===
+--- movit-1.6.2.orig/resource_pool.cpp
movit-1.6.2/resource_pool.cpp
+@@ -42,6 +42,7 @@ ResourcePool::~ResourcePool()
+ for (GLuint free_texture_num : texture_freelist) {
+ assert(texture_formats.count(free_texture_num) != 0);
+ texture_freelist_bytes -=
estimate_texture_size(texture_formats[free_texture_num]);
++ glDeleteSync(texture_formats[free_texture_num].no_reuse_before);
+ texture_formats.erase(free_texture_num);
+ glDeleteTextures(1, &free_texture_num);
+ check_error();
+@@ -337,7 +338,10 @@ GLuint ResourcePool::create_2d_texture(G
+ format_it->second.height == height) {
+ texture_freelist_bytes -=
estimate_texture_size(format_it->second);
+ texture_freelist.erase(freelist_it);
++ GLsync sync = format_it->second.no_reuse_before;
+ pthread_mutex_unlock(&lock);
++ glWaitSync(sync, 0, GL_TIMEOUT_IGNORED);
++ glDeleteSync(sync);
+ return texture_num;
+ }
+ }
+@@ -449,12 +453,14 @@ void ResourcePool::release_2d_texture(GL
+ texture_freelist.push_front(texture_num);
+ assert(texture_formats.count(texture_num) != 0);
+ texture_freelist_bytes +=
estimate_texture_size(texture_formats[texture_num]);
++ texture_formats[texture_num].no_reuse_before =
glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
+
+ while (texture_freelist_bytes > texture_freelist_max_bytes) {
+ GLuint free_texture_num = texture_freelist.back();
+ texture_freelist.pop_back();
+ assert(texture_formats.count(free_texture_num) != 0);
+ texture_freelist_bytes -=
estimate_texture_size(texture_formats[free_texture_num]);
++ glDeleteSync(texture_formats[free_texture_num].no_reuse_before);
Bug#930735: WireGuard: Add resolvconf as optional dependency
Control: tags 930735 + moreinfo Hi Willem-- On Wed 2019-06-19 15:01:53 +0200, Willem van den Akker wrote: > Add resolvconf as an optional dependency. > If the DNS option is used in the config file and resolvconf is not installed > wg-quick will return an > error and the interface is not created. > > [#] ip link add wg0 type wireguard > [#] wg setconf wg0 /dev/fd/63 > [#] ip -4 address add 192.168.3.21/32 dev wg0 > [#] ip link set mtu 1420 up dev wg0 > [#] resolvconf -a wg0 -m 0 -x > /usr/bin/wg-quick: line 31: resolvconf: command not found > [#] ip link delete dev wg0 Thanks for this suggestion! I'm willing to update the Suggests: of the wireguard package if i understand more about what actually works in this case. Are you certain that debian's resolvconf will work for this? Upstream has complained in the past about debian's implementation of resolvconf being broken (iirc, about the -x flag, but i'm not sure). Would openresolv's resolvconf be better? What about when resolvectl(1) from systemd is symlinked as resolvconf (see the resolvectl man page for more details) -- would that be preferable? according to its documentation, it has partial support for -x, plausible support for -a, and silently ignores -m. is that sufficient? If that's ok, maybe there are other adjustments we can make so that it integrates nicely with systemd-resolved. More details about what configurations you've tested and how well they work to do what you expect from wg-quick would help me understand how to make this system integration work better for you. all the best, --dkg signature.asc Description: PGP signature
Bug#929949: New upstream version 0.8 available, compatible with python3
Le 18/06/2019 à 20:10, Alexander Zangerl a écrit : yes. so far i can't make duplicity 0.8.0 work with python 2.7 which is still the default version in debian and hence important in my opinion. (by "does not work" i mean: the built-in test suite fails quite a lot, and after patching that part basic functionality is still very very broken.) no promises as to when i will find time and mental strength to wade through this (upstream-induced) mess. Oh, also could you share your current packaging work? It would make easier to trigger the problem and help with upstream reporting...
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
On Wed, Jun 19, 2019 at 11:33 PM Ilias Tsitsimpis wrote: > > On Mon, Jun 17, 2019 at 12:00AM, Emanuele Olivetti wrote: > > Let me know if I can help more. > > Dear Emanuele, > > Thank you for taking the time to test and verify my packages. Can I ping > you one last time to test that git-annex will work after we rebuild it? > > > Dear Ilias, Indeed, I'll be very happy to test git-annex! Looking forward to receiving your message. And thanks again for taking care of this issue. Best, Emanuele
Bug#906518: qa.debian.org: Missing manpages webpage links to seemingly dead project
Control: tag -1 confirmed Control: user -1 qa.debian@packages.debian.org Control: usertags -1 webpages Dear QA team, I confirm this bug. The link has 403 (Forbidden) return code. Regards, Alban signature.asc Description: OpenPGP digital signature
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Hey there, Le 19/06/2019 à 22:19, Simon McVittie a écrit : - Ubuntu GNOME team: which recent Ubuntu versions, if any, are using Wayland for their GNOME-based desktop? We don't have any supported Ubuntu version using Wayland by default, our motivations for sticking to Xorg were mostly desktop sharing/rdp support and the fact that under wayland a gnome-shell segfault takes the whole session down without giving user a chance to save their work. While screen sharing is being actively being worked on, our metrics show that gnome-shell errors are still quite common, even in recent versions so it's not likely that we change our default for the next LTS. Cheers, Sebastien Bacher
Bug#930754: Warnings when using bzip2 or lzma
Control: tag -1 + patch Hello, On Wed, Jun 19, 2019 at 11:09:28PM +0200, Uwe Kleine-König wrote: > I tested the different options for the COMPRESS variable in initramfs.conf > and noticed that when using bzip2 or lzma I get a warning when an > initramfs is created: > > "W: Unknown compression command bzip2" > > . It is harmless though, compression succeeds just fine. So it's just > irritating. Before someone starts fixing this bug, I already created a patch: https://deb.li/i4uby Best regards Uwe signature.asc Description: PGP signature
Bug#930755: ITP: q2-metadata -- QIIME 2 plugin for working with and visualizing Metadata
Package: wnpp Owner: Liubov Chuprikova Severity: wishlist * Package name: q2-metadata Version : 2019.4.0 Upstream Author : QIIME 2 development team * URL : https://qiime2.org/ * License : BSD-3-clause Programming Lang: Python Description : QIIME 2 plugin for working with and visualizing Metadata QIIME 2 is a powerful, extensible, and decentralized microbiome analysis package with a focus on data and analysis transparency. QIIME 2 enables researchers to start an analysis with raw DNA sequence data and finish with publication-quality figures and statistical results. Key features: * Integrated and automatic tracking of data provenance * Semantic type system * Plugin system for extending microbiome analysis functionality * Support for multiple types of user interfaces (e.g. API, command line, graphical) . QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome analysis pipeline. QIIME 2 will address many of the limitations of QIIME 1, while retaining the features that makes QIIME 1 a powerful and widely-used analysis pipeline. . QIIME 2 currently supports an initial end-to-end microbiome analysis pipeline. New functionality will regularly become available through QIIME 2 plugins. You can view a list of plugins that are currently available on the QIIME 2 plugin availability page. The future plugins page lists plugins that are being developed. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/q2-metadata
Bug#80268: net-tools: missing man page for ipmaddr
Control: tag -1 patch On Fri, 22 Dec 2000 00:28:01 -0500 c.ruf...@ieee.org wrote: > Package: net-tools > ipmaddr has no man page. Dear Maintainer, Please find attached the manpage for the ipmaddr(8) command. Best regards, Alban ipmaddr.8.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#929946: Can not reproduce anymore
Hi, I had to re-install my workstation, I can not reproduce the issue anymore: I suppose you can close this bug report. Regards, Yvan
Bug#930754: Warnings when using bzip2 or lzma
Package: initramfs-tools Version: 0.133 Severity: minor Hello, I tested the different options for the COMPRESS variable in initramfs.conf and noticed that when using bzip2 or lzma I get a warning when an initramfs is created: "W: Unknown compression command bzip2" . It is harmless though, compression succeeds just fine. So it's just irritating. Best regards Uwe -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 3.2M Nov 29 2018 /boot/initrd.img-4.18.0-2-armmp -rw-r--r-- 1 root root 3.3M Nov 29 2018 /boot/initrd.img-4.18.0-3-armmp -rw-r--r-- 1 root root0 Nov 29 2018 /boot/initrd.img-4.18.0-3.new -rw-r--r-- 1 root root 3.5M Jan 23 19:06 /boot/initrd.img-4.19.0-1-armmp -rw-r--r-- 1 root root 3.5M Apr 28 22:18 /boot/initrd.img-4.19.0-4-armmp -rw-r--r-- 1 root root 4.6M Jun 19 22:58 /boot/initrd.img-4.19.0-5-armmp -rw-r--r-- 1 root root 6.0M Jun 19 22:56 /boot/initrd.img-4.19.0-5-armmp.dpkg-bak -rw-r--r-- 1 root root 3.2M Dec 15 2018 /boot/initrd.img-4.19.0-trunk-armmp -- /proc/cmdline console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs rootflags=subvol=@ mtdparts=armada-nand:0x18@0(u-boot),0x2@0x18(u-boot-env),0x60@0x20(uImage),0x40@0x80(minirootfs),-(ubifs) reason=normal bdtype=rn104 -- resume RESUME=UUID=c56038a1-acbf-49b7-bdfc-95ffdbf6b6dc -- /proc/filesystems btrfs -- lsmod Module Size Used by 8021q 28672 0 garp 16384 1 8021q mrp20480 1 8021q stp16384 1 garp llc16384 2 garp,stp ofpart 16384 0 xhci_pci 16384 0 xhci_hcd 200704 1 xhci_pci ehci_orion 16384 0 ehci_hcd 77824 1 ehci_orion marvell20480 1 sg 32768 0 marvell_cesa 40960 0 usbcore 212992 4 ehci_orion,ehci_hcd,xhci_pci,xhci_hcd mvneta 49152 0 mvneta_bm 16384 1 mvneta des_generic28672 1 marvell_cesa marvell_nand 32768 0 phylink24576 1 mvneta mvmdio 16384 0 g762 20480 0 orion_wdt 16384 0 evdev 24576 1 leds_gpio 16384 0 nfsd 335872 13 auth_rpcgss57344 1 nfsd nfs_acl16384 1 nfsd lockd 86016 1 nfsd grace 16384 2 nfsd,lockd sunrpc307200 18 auth_rpcgss,nfsd,nfs_acl,lockd ip_tables 24576 0 x_tables 24576 1 ip_tables autofs440960 2 btrfs1224704 1 libcrc32c 16384 1 btrfs crc32c_generic 16384 1 xor16384 1 btrfs zstd_decompress61440 1 btrfs zstd_compress 159744 1 btrfs xxhash 20480 2 zstd_compress,zstd_decompress zlib_deflate 28672 1 btrfs raid6_pq 98304 1 btrfs sd_mod 49152 3 gpio_pca953x 20480 4 ahci 36864 2 libahci32768 1 ahci libata208896 2 ahci,libahci scsi_mod 196608 3 sd_mod,libata,sg i2c_mv64xxx20480 0 -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes -- /etc/initramfs-tools/initramfs.conf MODULES=dep BUSYBOX=auto KEYMAP=n COMPRESS=xz DEVICE= NFSROOT=auto RUNSIZE=10% -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- /sys/block sda -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: btrfs dmsetup flash_kernel_set_root fsck keymap klibc-utils kmod resume thermal udev zz-busybox -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (499, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-4-armmp (SMP w/1 CPU core) 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages initramfs-tools depends on: ii initramfs-tools-core 0.133 ii linux-base4.6 initramfs-tools recommends no packages. Versions of packages initramfs-tools suggests: ii bash-completion 1:2.8-6 -- no debconf information
Bug#930753: RFS: streamlink/1.1.1+dfsg-1~exp1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "streamlink" for a new upstream version 1.1.1 targeting experimental distribution which was requested by an user as twitch-gui require a newer streamlink. * Package name: streamlink Version : 1.1.1+dfsg-1~exp1 Upstream Author : Streamlink Team * URL : https://streamlink.github.io/ * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1 Section : python It builds those binary packages: livestreamer - transitional package - streamlink python3-streamlink - Python module for extracting video streams from various websites python3-streamlink-doc - CLI for extracting video streams from various websites (documentation) streamlink - CLI for extracting video streams from various websites to a video player To access further information about this package, please visit the following URL: https://mentors.debian.net/package/streamlink Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.1.1+dfsg-1~exp1.dsc More information about streamlink can be obtained at https://streamlink.github.io/ Changes since the last upload in unstable: streamlink (1.1.1+dfsg-1~exp1) experimental; urgency=low * New upstream version 1.1.1+dfsg * Update patch remove_new_version_check -- Alexis Murzeau Wed, 19 Jun 2019 21:58:59 +0200 Regards, -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#930681: stretch-backports kernel unable to execute (some) older (e.g., CentOS 6) binaries
On Wed, 2019-06-19 at 00:37 +0200, Mihai Moldovan wrote: > * On 6/18/19 3:22 PM, Bastian Blank wrote: > > See #847154 for the workaround. > Thanks. Seems to work fine. > > This triggered another question, though: can I assume that buster kernels are > also affected by that problem by default? Given that the shipped user space is > new enough, I figure that option will be disabled there as well? Yes, the configuration used in buster is the same. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: This is a digitally signed message part
Bug#930752: increases size of initrd considerably since linking with OpenSSL
Package: libkmod2 Version: 26-1 Severity: normal File: /usr/lib/arm-linux-gnueabihf/libkmod.so.2 Hello, some time ago I wanted to install a kernel update on my NAS (Netgear ReadyNAS 104/armhf). However that failed with: ... update-initramfs: Generating /boot/initrd.img-4.19.0-5-armmp Using DTB: armada-370-netgear-rn104.dtb Installing /usr/lib/linux-image-4.19.0-5-armmp/armada-370-netgear-rn104.dtb into /boot/dtbs/4.19.0-5-armmp/./armada-370-netgear-rn104.dtb Taking backup of armada-370-netgear-rn104.dtb. Installing new armada-370-netgear-rn104.dtb. Installing /usr/lib/linux-image-4.19.0-5-armmp/armada-370-netgear-rn104.dtb into /boot/dtbs/4.19.0-5-armmp/./armada-370-netgear-rn104.dtb Taking backup of armada-370-netgear-rn104.dtb. Installing new armada-370-netgear-rn104.dtb. flash-kernel: installing version 4.19.0-5-armmp The initial ramdisk is too large. This is often due to the unnecessary inclusion of all kernel modules in the image. To fix this set MODULES=dep in one or both /etc/initramfs-tools/conf.d/driver-policy (if it exists) and /etc/initramfs-tools/initramfs.conf and then run 'update-initramfs -u -k 4.19.0-5-armmp' Not enough space for initrd in MTD 'minirootfs' (need 4821508 but is actually 4194304). run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1 dpkg: error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) Looking at the difference between the working initrd for 4.19.0-4 and the to big one for 4.19.0-5: $ diff -u <(lsinitramfs /boot/initrd.img-4.19.0-4-armmp | sed s/4.19.0-4-armmp/uname-r/ | sort) <(lsinitramfs /boot/initrd.img-4.19.0-5-armmp | sed s/4.19.0-5-armmp/uname-r/ | sort) | grep ^[-+] --- /dev/fd/63 2019-06-19 22:22:31.764750895 +0200 +++ /dev/fd/62 2019-06-19 22:22:31.764750895 +0200 +usr/bin/arch +usr/bin/bc +usr/bin/svok -usr/lib/arm-linux-gnueabihf/libacl.so.1.1.0 +usr/lib/arm-linux-gnueabihf/libacl.so.1.1.2253 -usr/lib/arm-linux-gnueabihf/libattr.so.1.1.0 +usr/lib/arm-linux-gnueabihf/libattr.so.1.1.2448 +usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1 -usr/lib/arm-linux-gnueabihf/libkmod.so.2.3.3 +usr/lib/arm-linux-gnueabihf/libkmod.so.2.3.4 -usr/lib/arm-linux-gnueabihf/liblzma.so.5.2.2 +usr/lib/arm-linux-gnueabihf/liblzma.so.5.2.4 +usr/lib/arm-linux-gnueabihf/libresolv-2.28.so +usr/lib/arm-linux-gnueabihf/libresolv.so.2 +usr/lib/arm-linux-gnueabihf/libssl.so.1.1 -usr/lib/arm-linux-gnueabihf/libudev.so.1.6.12 +usr/lib/arm-linux-gnueabihf/libudev.so.1.6.13 -usr/lib/klibc-COogfK2xWPg3hPxojsQE86cGErM.so +usr/lib/klibc-Tm5Kcygh62Zsrgmh7J5q50y2Vn8.so +usr/sbin/nologin +usr/sbin/run-init Looking at the differences in more detail, the files only in the old initrd are: $ lsinitramfs -l /boot/initrd.img-4.19.0-4-armmp | grep -E 'usr/lib/arm-linux-gnueabihf/lib(acl.so.1.1.0|attr.so.1.1.0|kmod.so.2.3.3|lzma.so.5.2.2|udev.so.1.6.12)|usr/lib/klibc-COogfK2xWPg3hPxojsQE86cGErM.so' -rw-r--r-- 1 root root0 Feb 6 2016 usr/lib/arm-linux-gnueabihf/libacl.so.1.1.0 -rw-r--r-- 1 root root13884 Sep 8 2014 usr/lib/arm-linux-gnueabihf/libattr.so.1.1.0 -rw-r--r-- 1 root root62904 Nov 17 2018 usr/lib/arm-linux-gnueabihf/libkmod.so.2.3.3 -rw-r--r-- 1 root root 104260 Jun 28 2017 usr/lib/arm-linux-gnueabihf/liblzma.so.5.2.2 -rw-r--r-- 1 root root95828 Jan 12 21:49 usr/lib/arm-linux-gnueabihf/libudev.so.1.6.12 -rwxr-xr-x 1 root root53812 Jan 6 20:33 usr/lib/klibc-COogfK2xWPg3hPxojsQE86cGErM.so And the files only in the new are: $ lsinitramfs -l /boot/initrd.img-4.19.0-5-armmp | grep -E 'usr/bin/(arch|bc|svok)|usr/lib/arm-linux-gnueabihf/lib(acl.so.1.1.2253|attr.so.1.1.2448|crypto.so.1.1|kmod.so.2.3.4|lzma.so.5.2.4|resolv-2.28.so|resolv.so.2|ssl.so.1.1|udev.so.1.6.13)|usr/lib/klibc-Tm5Kcygh62Zsrgmh7J5q50y2Vn8.so|usr/sbin/(nologin|run-init)' -rw-r--r-- 1 root root21864 Mar 1 23:22 usr/lib/arm-linux-gnueabihf/libacl.so.1.1.2253 -rw-r--r-- 1 root root13632 Mar 1 23:03 usr/lib/arm-linux-gnueabihf/libattr.so.1.1.2448 -rw-r--r-- 1 root root 1708448 Apr 16 21:31 usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1 -rw-r--r-- 1 root root62904 Feb 10 00:00 usr/lib/arm-linux-gnueabihf/libkmod.so.2.3.4 -rw-r--r-- 1 root root 104220 Jan 28 02:
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On 19.06.19 22:03, Paul Gevers wrote: > Hi Tony, > > On 18-06-2019 22:14, tony mancill wrote: >> Things are looking good so far with 11.0.4+4+really11.0.3+7 in unstable, >> and so I would like to prepare the t-p-u upload. At the moment, the >> version I have is 11.0.3+7-5, since that would have been the "next" >> 11.0.3+7 Debian revision for unstable. The 11.0.3+7 orig.tar.xz already >> in the archive is the same one used for the "really" to unstable and >> this build, and this versioning makes it clear to users what they are >> getting. The resulting changelog would be: >> >>> diff -Nru openjdk-11-11.0.4+4+really11.0.3+7/debian/changelog >>> openjdk-11-11.0.3+7/debian/changelog >>> --- openjdk-11-11.0.4+4+really11.0.3+7/debian/changelog 2019-06-14 >>> 12:28:25.0 -0700 >>> +++ openjdk-11-11.0.3+7/debian/changelog2019-06-16 11:24:19.0 >>> -0700 >>> @@ -1,3 +1,10 @@ >>> +openjdk-11 (11.0.3+7-5) buster; urgency=medium >>> + >>> + * Team upload. >>> + * Upload 11.0.4+4+realy11.0.3+7-2 to buster t-p-u. >>> + >>> + -- tony mancill Sun, 16 Jun 2019 11:24:19 -0700 >> >> Is this acceptable to the Release Team? If not, (and I know there have >> been some differing opinions), how shall we version the t-p-u package? > > I think the most logical version would be 11.0.3+7-4+deb10u1, as this is > a targeted upload to buster. let's use a version which also can be nicely used for the backports upload. > I don't have a strong opinion on it. I > still don't like it we go via tpu but I understand the ranting argument. this will be very short-lived until the final 11.0.4 release to be uploaded into security. > Let's end this saga. please do.
Bug#930748: [Pkg-samba-maint] Bug#930748: samba: CVE-2019-12435: Samba AD DC Denial of Service in DNS management server (dnsserver)
Hey, On Wed, Jun 19, 2019 at 10:12:15PM +0200, Mathieu Parent wrote: > > The following vulnerability was published for samba. > > > > CVE-2019-12435[0]: > > | Samba 4.9.x before 4.9.9 and 4.10.x before 4.10.5 has a NULL pointer > > | dereference, leading to Denial of Service. This is related to the AD > > | DC DNS management server (dnsserver) RPC server process. > > > > > > 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-12435 > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12435 > > [1] https://www.samba.org/samba/security/CVE-2019-12435.html > > I've just created a pre-approval unblock request to choose between > uploading 4.9.9 (including stability fixes) or 4.9.5+patch. Ack! Thank you Mathieu. Regards, Salvatore
Bug#930552: xserver-xorg-video-radeon: X-server regularily fails to start while booting
Dear Maintainer, looks like the submitter opened in response to the last mail bug #930649 against src:linux. Therefore this one might be closed? Kind regards, Bernhard https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930649
Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"
Hi Raphael, On Tue, 11 Jun 2019 15:51:14 +0200 Raphael Hertzog wrote: > Hi, > > On Wed, 05 Jun 2019, Michael Biebl wrote: > > systemd-networkd.service in v241 is locked down more tightly then v232. > > It might be worth a try to comment out the hardening features one by one > > to see if one of them causes your problem. > > Thanks for the idea! I tried that but it did not help. I found the issue > after a few more tries tweaking the network configuration file. It's > simply that the system has IPv6 disabled in the kernel policy while the > .network file instructs to configure an IPv6 address. > > Both are contradictory but they happily lived together up-to-now. > I don't know what changed but if we don't improve systemd-networkd > to just skip IPv6 configuration when the kernel has a policy disabling > IPv6, then we will have plenty of servers broken on upgrades because > it's quite common to keep the network configuration file provided by > the hoster and just disable IPv6 at the kernel level with sysctl: > > $ grep ipv6 /etc/sysctl.conf > # Disable ipv6 > net.ipv6.conf.all.disable_ipv6 = 1 > net.ipv6.conf.default.disable_ipv6 = 1 > net.ipv6.conf.lo.disable_ipv6 = 1 Ok, thanks for figuring out the root cause. Given that this only happens under very special circumstances and networkd not being enabled by default, I'm not entirely sure if this issue should qualify as RC. Cherry-picking the 6 upstream commits leads to a merge conflict when applied on top of v241 and I haven't yet investigated if those can easily be resolved. TBH, I feel a bit uneasy doing this change so late in the release cycle and personally I would downgrade this issue to non-RC and fix this via a v243 upload to buster-backports. If you feel strongly about this though, please feel free ask the release team if the change is ok. A tested patch set would be great in this case. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930750: jackson-databind: CVE-2019-12384 CVE-2019-12814
Source: jackson-databind Version: 2.9.8-2 Severity: important Tags: security upstream Hi, The following vulnerabilities were published for jackson-databind. CVE-2019-12384[0]: | Another issue (exploitable using polymorphic deserialization), cf. | [2]. CVE-2019-12814[1]: | A Polymorphic Typing issue was discovered in FasterXML jackson- | databind 2.x through 2.9.9. When Default Typing is enabled (either | globally or for a specific property) for an externally exposed JSON | endpoint and the service has JDOM 1.x or 2.x jar in the classpath, an | attacker can send a specifically crafted JSON message that allows them | to read arbitrary local files on the server. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-12384 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12384 [1] https://security-tracker.debian.org/tracker/CVE-2019-12814 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12814 [2] https://github.com/FasterXML/jackson-databind/issues/2334 [3] https://github.com/FasterXML/jackson-databind/issues/2341 Regards, Salvatore
Bug#926501: xpdf: continuous memory leak
I experience this same problem. When browsing around the end of an 800 page PDF, xpdf will consume 250MB/sec! Also, it is very slow. I have manually downgraded xpdf from 3.04-13 several times on different computers because of this bug. Is xpdf abandoned? I understand if it's difficult to update to 4.0x but xpdf has been essentially unusable since January. If I go through the trouble of generating the one-line patch that will fix this bug, is there anyone out there that might apply it and issue 3.04-14? - Greg
Bug#930751: wpasupplicant: Please enable support for 802.11s (mesh)
Package: wpasupplicant Version: 2:2.7+git20190128+0c1e29f-6 Severity: wishlist Dear Maintainer, please enable the IEEE 802.11s (mesh networking) support in wpasupplicant by uncommenting "CONFIG_MESH=y" in the build configuration. Without this option users of authenticated mesh networks are required to compile wpasupplicant on their own or probably use no encryption at all. Thank you for considering this request. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_CRAP 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 wpasupplicant depends on: ii adduser3.118 ii libc6 2.28-10 ii libdbus-1-31.12.16-1 ii libnl-3-2003.4.0-1 ii libnl-genl-3-200 3.4.0-1 ii libnl-route-3-200 3.4.0-1 ii libpcsclite1 1.8.24-1 ii libreadline7 7.0-5 ii libssl1.1 1.1.1c-1 ii lsb-base 10.2019051400 wpasupplicant recommends no packages. Versions of packages wpasupplicant suggests: pn libengine-pkcs11-openssl pn wpagui -- no debconf information
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
On Wed, 19 Jun 2019 at 17:33:55 +0100, Jonathan Dowland wrote: > So far as I am aware there is still radio silence from active GNOME > packaging team members regarding this issue. No comment yet on the > patch I adapted, positive or negative; this bug (#927667) remains > at an RC severity. (Adding debian-gtk-gnome, debian-desktop and some people who might have useful input to Cc) In case anyone else in the GNOME team has got the wrong idea from my involvement in #927667: I don't think I am the right person to make a decision on this. So if GNOME team members are waiting for me to either make an upload changing the default back to X11, or veto such an upload: don't wait for that, it is unlikely to happen (unless the team cannot make a decision and punts this to the technical committee, but I hope we don't have to resort to that). I would very much appreciate input from the rest of the team, particularly: - Laurent: I know you've had strong opinions about using Wayland for GNOME. Do you feel strongly that Debian should be defaulting to Wayland? Are there any reasons for that default that are missing from my attempt to summarize earlier on the bug? - Ubuntu GNOME team: which recent Ubuntu versions, if any, are using Wayland for their GNOME-based desktop? I've left some comments on https://salsa.debian.org/gnome-team/gdm/merge_requests/8 regarding the technical side of the proposed change. Thanks, smcv
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Jonathan Dowland writes: > So far as I am aware there is still radio silence from active GNOME > packaging team members regarding this issue. No comment yet on the > patch I adapted, positive or negative; this bug (#927667) remains > at an RC severity. > > I've not yet read all the thread that Samuel linked to[1] but it looks > like it leans in favour of preserving the current default (xorg). > > I'm copying -release team to see if they have any (new) opinions on > the matter. Otherwise I guess it's up to someone to prepare an NMU > upload, which I will *try* to look at in the next few days, but can't > make any guarantees. I'm just a GNOME user, but from gdm3's changelog the default was switched to Wayland in July 2017 (or August 2017 for unstable). I myself only noticed the switch after reading it happened somewhere on the internet shortly after it happened. Switching the default back two weeks before the release seems too late for me. The largest issue seems to be accessibility, but as far as I understand we already recommend a different desktop environment for that. I don't think that warrants changes that would only see very little testing by now :-/ Ansgar
Bug#930749: unblock: samba/2:4.9.9+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, This is a pre-approval request about samba. A new Samba security version was released today to address CVE-2019-12435: 4.9.9. Sid/buster currently has 4.9.5. I'm tempted to upload 4.9.9 to sid (targeting buster). This would add a big diff of stability fixes. The d/changelog would look like: samba (2:4.9.9+dfsg-1) unstable; urgency=high * This is a security release in order to address the following defect: - CVE-2019-12435 zone operations can crash rpc server (Closes: #930748) * New upstream release - Remove security patches, included in release - libsamba-passdb.so bumped to 0.27.2 * Add missing Breaks+Replace found by piuparts (Closes: #929217) Thanks Andreas Beckmann! Without an ack from you, I will only add the patch for CVE-2019-12435 (and maybe #929217?) and delay the other fixes for buster-proposed-updates. What is you opinion? (not including the debdiff against the package in testing, which is huge) unblock samba/2:4.9.9+dfsg-1 -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#930748: [Pkg-samba-maint] Bug#930748: samba: CVE-2019-12435: Samba AD DC Denial of Service in DNS management server (dnsserver)
Le mer. 19 juin 2019 à 21:51, Salvatore Bonaccorso a écrit : > > Source: samba > Version: 2:4.9.5+dfsg-4 > Severity: important > Tags: security upstream > > Hi, Hi, > The following vulnerability was published for samba. > > CVE-2019-12435[0]: > | Samba 4.9.x before 4.9.9 and 4.10.x before 4.10.5 has a NULL pointer > | dereference, leading to Denial of Service. This is related to the AD > | DC DNS management server (dnsserver) RPC server process. > > > 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-12435 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12435 > [1] https://www.samba.org/samba/security/CVE-2019-12435.html I've just created a pre-approval unblock request to choose between uploading 4.9.9 (including stability fixes) or 4.9.5+patch. Regards -- Mathieu Parent
Bug#913222: journalctl: bash-completion: incorrect sorting of --priority arguments
Will be fixed in v243. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930696: [pkg-cryptsetup-devel] Bug#930696: Keyfiles specified by KEYFILE_PATTERN are not added to the initramfs
On Wed, 19 Jun 2019 01:36:22 +0200 Guilhem Moulin wrote: > Control: severity -1 minor > > Hi, > > On Tue, 18 Jun 2019 at 20:35:47 +0200, Jernej Jakob wrote: > > Any keyfiles configured in /etc/cryptsetup-initramfs/conf-hook > > KEYFILE_PATTERN are not added to the initramfs if the target in > > /etc/crypttab also has keyscript set. > > As crypttab(5) reads, > >“In case of a keyscript, the value of [the third] field is given as >argument to the keyscript.” > > This could probably be made clearer, but the behavior is intentional: it is > *not* treated as a key file, hence not compared against the KEYFILE_PATTERN > glob(7) expansion. Makes sense. Seems good to add this explanation to the documentation, maybe adding "and is *not* added to the initramfs". Otherwise it may be assumed it would still be added, since it's a file, and is passed as an argument to the keyscript (the argument of which could be a file), and the field is normally used as the path to a keyfile, which is added. It all seems very complex to understand to a novice, in particular due to the dual function of the third field. > > > This may prevent the system from booting if the target has a > > keyscript=/bin/cat set (as is in PureOS which is based on buster). > > Setting ‘keyscript=/bin/cat’ is useless for unlocking by key file, and > is discouraged as it's incompatible with setups not supporting > keyscripts, like systemd's systemd-cryptsetup@.service. The same entry > without the key script should work just fine. > > > Perhaps cryptroot should print out a warning that the keyfile set in > > crypttab wasn't added due to a set keyscript. That way the users would > > know something may be misconfigured. > > I'm reluctant to do that due to false positives. Consider a setup with > two devices unlocked at initramfs stage, one opened by key file (copied > to the initramfs image), one by key script, and KEYFILE_PATTERN set to > "*". Nothing wrong with that setup, KEYFILE_PATTERN="*" indicates that > all key files should be copied to the initramfs image; crypttab(5) > entries with a ‘keyscript=’ option are intentionally excluded from > glob(7)'ing printing any warning would be a false positive. > > Cheers, I agree. Thanks
Bug#904913: systemd: systemctl cat 'foo*' (using shellglob patterns) only lists active units
Should be fixed in v243. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#851402: failed unmounting /var during shutdown
Will be fixed in v243. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#928185: unblock: openjdk-11/11.0.3+7-4
Hi Tony, On 18-06-2019 22:14, tony mancill wrote: > Things are looking good so far with 11.0.4+4+really11.0.3+7 in unstable, > and so I would like to prepare the t-p-u upload. At the moment, the > version I have is 11.0.3+7-5, since that would have been the "next" > 11.0.3+7 Debian revision for unstable. The 11.0.3+7 orig.tar.xz already > in the archive is the same one used for the "really" to unstable and > this build, and this versioning makes it clear to users what they are > getting. The resulting changelog would be: > >> diff -Nru openjdk-11-11.0.4+4+really11.0.3+7/debian/changelog >> openjdk-11-11.0.3+7/debian/changelog >> --- openjdk-11-11.0.4+4+really11.0.3+7/debian/changelog 2019-06-14 >> 12:28:25.0 -0700 >> +++ openjdk-11-11.0.3+7/debian/changelog 2019-06-16 11:24:19.0 >> -0700 >> @@ -1,3 +1,10 @@ >> +openjdk-11 (11.0.3+7-5) buster; urgency=medium >> + >> + * Team upload. >> + * Upload 11.0.4+4+realy11.0.3+7-2 to buster t-p-u. >> + >> + -- tony mancill Sun, 16 Jun 2019 11:24:19 -0700 > > Is this acceptable to the Release Team? If not, (and I know there have > been some differing opinions), how shall we version the t-p-u package? I think the most logical version would be 11.0.3+7-4+deb10u1, as this is a targeted upload to buster. I don't have a strong opinion on it. I still don't like it we go via tpu but I understand the ranting argument. Let's end this saga. Paul signature.asc Description: OpenPGP digital signature
Bug#930120: init: Documentation error for telinit/init - does not use 'systemctl isolate xxx'
On Fri, 7 Jun 2019 17:32:00 +0200 Michael Biebl wrote: > Control: tags -1 + moreinfo > > Am 07.06.19 um 15:51 schrieb J. Pfennig: > > The man page of telinit/init says (for 'telinit N'): > > > >Change the SysV runlevel. This is translated into an activation request > > for runlevel2.target, > >runlevel3.target, ... and is equivalent to systemctl isolate > > runlevel2.target, systemctl isolate > >runlevel3.target, ... > > > > But when using telinit 2 or init 2 (or event booting the kernel with "2" > > as an argument), the effective operation is: > > > > 'systemctl start runlevel2.target' > > ### but not 'sytemctl isolate runlevel2.target' ### as documented > > > > I'm pretty sure "telinit" uses isolate. > See > https://github.com/systemd/systemd/blob/master/src/initctl/initctl.c#L101 > > So the documentation looks correct to me. > Please elaborate I still don't see the problem here, that said if you feel strongly about this and think this needs to be addressed, please raise this upstream at https://github.com/systemd/systemd/issues After all, this doesn't look like a Debian specific issue. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930748: samba: CVE-2019-12435: Samba AD DC Denial of Service in DNS management server (dnsserver)
Source: samba Version: 2:4.9.5+dfsg-4 Severity: important Tags: security upstream Hi, The following vulnerability was published for samba. CVE-2019-12435[0]: | Samba 4.9.x before 4.9.9 and 4.10.x before 4.10.5 has a NULL pointer | dereference, leading to Denial of Service. This is related to the AD | DC DNS management server (dnsserver) RPC server process. 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-12435 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12435 [1] https://www.samba.org/samba/security/CVE-2019-12435.html Regards, Salvatore
Bug#930746: bind9: CVE-2019-6471: A race condition when discarding malformed packets can cause BIND to exit with an assertion failure
Source: bind9 Version: 1:9.11.5.P4+dfsg-5 Severity: grave Tags: security upstream Control: clone -1 -2 Control: reassign -2 src:bind 1:9.13.3-1 Control: retitle -2 bind: CVE-2019-6471: A race condition when discarding malformed packets can cause BIND to exit with an assertion failure Hi, The following vulnerability was published for bind9. CVE-2019-6471[0]: |A race condition when discarding malformed packets can cause BIND to |exit with an assertion failure 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-6471 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6471 [1] https://kb.isc.org/docs/cve-2019-6471 Please adjust the affected versions in the BTS as needed, I think the version back in stretch is not affected but this needs double-checking. Regards, Salvatore
Bug#930745: new upstream (2.0)
Package: haproxy Severity: wishlist Hi, thank you for maintaining haproxy in Debian. It would be nice if you could upgrade to the current upstream version (2.0). Regards, Daniel
Bug#929720: hkl: FTBFS: ../../hkl/ccan/generator/generator.h:23:2: error: #error Generators require coroutines
Control: severity -1 important Hi Lucas, I confirm that I'm the third one who can not reproduce this issue. Can we agree that this bug is maximum of severity important (just set this - feel free to reset to serious if you have good reasons for it). Do you have any further hints how this FTBFS could be reproduced? Kind regards Andreas. -- http://fam-tille.de
Bug#930674: automatically generated menus prevent some applications from running
On 2019-06-19, at 19:39:12 +0200, Andreas Metzler wrote: > On 2019-06-19 Jeremy Sowden wrote: > [...] > > Your patch truncates any string value at the first %. I don't think > > that's the right way to go. > [...] > > https://repo.or.cz/wmaker-crm.git/commit/e037ae3684928a2fbf4a3994562a322f5d3b0c71 > > is supposed to fix this. That patch seems to be intended to stop parsing after the first section of a desktop file like this: [Desktop Entry] Name=Rxvt Color Unicode Terminal Comment=Use the command line TryExec=urxvt Exec=urxvt Icon=urxvt_48x48.xpm Type=Application Categories=Utility;TerminalEmulator; StartupNotify=true Keywords=Run; Actions=New StartupWMClass=URxvt [Desktop Action New] Name=New Rxvt Color Unicode Terminal Exec=urxvt OnlyShowIn=Unity This bug is about what to do with an Exec like this: Exec=/usr/bin/chromium %U The comments in the source file suggest trying TryExec in preference to Exec and discarding the arguments from the latter if used. However, in fact, if Exec is used, it is used as-is. For %U and %F, I think we can replace them with an empty list, i.e., "". For %u and %f, I think we can _probably_ do likewise. J. signature.asc Description: PGP signature
Bug#930674: automatically generated menus prevent some applications from running
On 6/19/19 10:20 AM, Jeremy Sowden wrote: [...] Clearly this is not what the code actually does. The quick hack would be to change xdg_to_wm() to truncate the command-line at the first instance of white-space (which is what is done to derive (*wm)->Name from (*xdg)->Exec or (*xdg)->TryExec); the right thing to do would be to implement the FDO quoting rules first: maybe something like this: else /* (*xdg)->TryExec */ (*wm)->Name = wstrdup((*xdg)->TryExec); - p = strchr((*wm)->Name, ' '); + p = strchr((*wm)->Name, '%'); if (p) *p = '\0'; } @@ -225,6 +225,11 @@ (*wm)->CmdLine = (*xdg)->Exec; else/* (*xdg)->TryExec */ (*wm)->CmdLine = (*xdg)->TryExec; + + p = strchr((*wm)->CmdLine, '%'); + if (p) + *p = '\0'; + (*wm)->SubMenu = (*xdg)->Category; (*wm)->Flags = (*xdg)->Flags; and then maybe first (*xdg)->TryExec than (*xdg)->Exec?
Bug#921347:
That's nice. Hope we can get that to unstable soon. On June 19, 2019 8:40:47 PM GMT+02:00, Peter Zahradnik wrote: >On 6/18/19 3:52 PM, Dawid Dziurla wrote: >> What's the status of packaging? >> >> I would love to see this software in Debian. >Hi, > >I've uploaded new version to mentors, there are still some lintians >warnings which needs to be fixed >https://mentors.debian.net/package/platformio > >Peter
Bug#717666: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#921347:
On 6/18/19 3:52 PM, Dawid Dziurla wrote: What's the status of packaging? I would love to see this software in Debian. Hi, I've uploaded new version to mentors, there are still some lintians warnings which needs to be fixed https://mentors.debian.net/package/platformio Peter
Bug#843050: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#654545: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#929682: libqt5qml5: QQmlEngine segfaults on ia64
Investigating now. On Wed, Jun 19, 2019 at 1:56 PM Dmitry Shachnev wrote: > Hi Jason! > > On Tue, May 28, 2019 at 11:58:38AM -0400, Jason Duerstock wrote: > > As reported in bug #894726, qtdeclarative-opensource-src has a bug on > > systems that use 64-bit pointers with any bits from 63-50 set. The > > attached patch addresses this issue on ia64 by shifting bits 63-61 > > (which are the "virtual region number" on ia64) into bits 49-47. Please > > include it in the next release. > > I have applied the patch (the version that was merged upstream), but > unfortunately most of the tests are still failing. > > In the build log, I can count 149 FAIL!s and 42 Segmentation faults. > > It is much more than 57 failures you mentioned in the upstream bug [1]. > Looking at the log, *most* of the tests are failing. Passing ones are > mostly the qmlMinify ones, which do not use the QML engine at all. > > Can you please look what happened there? > > [1]: > https://bugreports.qt.io/browse/QTBUG-56264?focusedCommentId=462440#comment-462440 > > -- > Dmitry Shachnev >
Bug#860087: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930674: automatically generated menus prevent some applications from running
On 6/19/19 7:39 PM, Andreas Metzler wrote: On 2019-06-19 Jeremy Sowden wrote: [...] Your patch truncates any string value at the first %. I don't think that's the right way to go. [...] https://repo.or.cz/wmaker-crm.git/commit/e037ae3684928a2fbf4a3994562a322f5d3b0c71 is supposed to fix this. cu Andreas this the case of my libreoffice-writer.desktop that it has two entries Exec=libreoffice --writer %U and Exec=libreoffice --writer but I also have others with just one e.g. medit.desktop Exec=medit %F and with two commands e.g. vlc.desktop Exec=/usr/bin/vlc --started-from-file %U TryExec=/usr/bin/vlc but instead of using "TryExec" for the generated menu it uses "Exec" ...
Bug#930744: linux-image-4.19.0-5-amd64: wlan/wifi not working
Package: src:linux Version: 4.19.37-4 Severity: normal Dear Maintainer, my WiFi stopped working after the kernel upgrade. When booting 4.19.0.4, I see lt-nkiesel kernel: wl: loading out-of-tree module taints kernel. lt-nkiesel kernel: wl: module license 'MIXED/Proprietary' taints kernel. lt-nkiesel kernel: wl: module verification failed: signature and/or required key missing - tainting kernel lt-nkiesel kernel: wlan0: Broadcom BCM43b1 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334) lt-nkiesel NetworkManager[771]: [1560965780.6047] wifi-nl80211: (wlan0): using nl80211 for WiFi device control When booting 4.19.0.5, I see lt-nkiesel kernel: wl: loading out-of-tree module taints kernel. lt-nkiesel kernel: wl: module license 'MIXED/Proprietary' taints kernel. lt-nkiesel kernel: wl: module verification failed: signature and/or required key missing - tainting kernel lt-nkiesel kernel: wl: disagrees about version of symbol cfg80211_inform_bss_frame_data lt-nkiesel kernel: wl: Unknown symbol cfg80211_inform_bss_frame_data (err -22) lt-nkiesel kernel: wl: disagrees about version of symbol skb_put lt-nkiesel kernel: wl: Unknown symbol skb_put (err -22) (more complaining about other symbols) -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Dell Inc. product_name: Precision M4800 product_version: 00 chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: A19 board_vendor: Dell Inc. board_name: 0WJNC2 board_version: A00 ** Network interface configuration: source /etc/network/interfaces.d/* auto lo iface lo inet loopback ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [8086:0c04] (rev 06) Subsystem: Dell Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [1028:05cc] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: ie31200_edac 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Dell 4th Gen Core Processor Integrated Graphics Controller [1028:05cc] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) Subsystem: Dell Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [1028:05cc] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Dell 8 Series/C220 Series Chipset Family USB xHCI [1028:05cc] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) Subsystem: Dell 8 Series/C220 Series Chipset Family MEI Controller [1028:05cc] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-LM [8086:153a] (rev 04) Subsystem: Dell Ethernet Connection I217-LM [1028:05cc] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: e1000e Kernel modules: e1000e
Bug#929682: libqt5qml5: QQmlEngine segfaults on ia64
Hi Jason! On Tue, May 28, 2019 at 11:58:38AM -0400, Jason Duerstock wrote: > As reported in bug #894726, qtdeclarative-opensource-src has a bug on > systems that use 64-bit pointers with any bits from 63-50 set. The > attached patch addresses this issue on ia64 by shifting bits 63-61 > (which are the "virtual region number" on ia64) into bits 49-47. Please > include it in the next release. I have applied the patch (the version that was merged upstream), but unfortunately most of the tests are still failing. In the build log, I can count 149 FAIL!s and 42 Segmentation faults. It is much more than 57 failures you mentioned in the upstream bug [1]. Looking at the log, *most* of the tests are failing. Passing ones are mostly the qmlMinify ones, which do not use the QML engine at all. Can you please look what happened there? [1]: https://bugreports.qt.io/browse/QTBUG-56264?focusedCommentId=462440#comment-462440 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#930671: libauthen-radius-perl: most basic usage stopped working
Control: severity -1 serious
On Tue, Jun 18, 2019 at 10:52:03AM +0200, Ferenc Wágner wrote:
> Package: libauthen-radius-perl
> Version: 0.29-1
> Severity: important
> I recently upgraded to buster and noticed that our RADIUS test plugin
> does not work anymore. Downgrading libauthen-radius-perl to 0.27-1
> fixes the issue. Take the first example from the top of the man page:
>
> use Authen::Radius;
> $r = new Authen::Radius(Host => 'myserver', Secret => 'mysecret');
> print "auth result=", $r->check_pwd('myname', 'mypwd'), "\n";
>
> If I substitute the correct IPv4 address, secret, user name and password
> into the above, the result is 1 (success) with 0.27-1, but upgrading to
> 0.29-1 gives an error message instead:
>
> unknown attr name 1 at /usr/share/perl5/Authen/Radius.pm line 865.
>
> There might be a workaround via using the lower level operations instead
> of the check_pwd method, but I haven't found it yet. Please advise.
Thanks for reporting this. I can reproduce this just by pointing a query
towards localhost, even with no server available.
The check_pwd() method is indeed just a small wrapper around the lower
lever operations. It looks like this wrapper calls the add_attributes()
method in a way that broke recently:
$self->add_attributes (
{ Name => 1, Value => $name, Type => 'string' },
{ Name => 2, Value => $pwd, Type => 'string' },
{ Name => 4, Value => $nas || '127.0.0.1', Type => 'ipaddr' }
);
>From the documentation of the add_attributes() method:
Adds any number of Radius attributes to the current Radius object.
Attributes are specified as a list of anon hashes. They may be
"Name"d with their dictionary name (provided a dictionary has been
loaded first), or with their raw Radius attribute-type values.
so this does not seem intentional.
This needs to be reported and fixed upstream; I'll look at it in the
next few days unless someone else beats me to it.
I'm raising the severity of this; if we cannot get it fixed in time
for the Debian Buster release, it should at least be fixed in a stable
release update later.
--
Niko Tyni nt...@debian.org
Bug#930743: ABI changed without an ABI bump
Package: src:linux Version: 4.19.37-4 Severity: important We forgot to add an ABI reference for 4.19.0-5 after the last ABI bump, and many symbol versions have changed between versions 4.19.37-3 and -4. I don't yet understand why that is, as the corresponding versions for stretch-backports have the same ABI (except in mwifiex, which is ignored). Ben. -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#930674: automatically generated menus prevent some applications from running
On 2019-06-19 Jeremy Sowden wrote: [...] > Your patch truncates any string value at the first %. I don't think > that's the right way to go. [...] https://repo.or.cz/wmaker-crm.git/commit/e037ae3684928a2fbf4a3994562a322f5d3b0c71 is supposed to fix this. cu Andreas
Bug#930314: MariaDB 10.3.16 ready for upload
Hello! I've prepared the 10.3.16 release for upload to unstable, and I will proceed with it in a couple of days. If there is something you want to have a chance to get into next stable Debian release, now is your chance to act on it. There are no new pending merge requests at https://salsa.debian.org/mariadb-team/mariadb-10.3/merge_requests nor any critical open bugs. There is however one old MR as a suggested solution to #930314 https://salsa.debian.org/mariadb-team/mariadb-10.3/merge_requests/19 but I have not merged it yet since I am unsure if this is a good fix that will also be accepted by upstream some day or if we will get stuck with delta that we need to maintain for a long time. Comments welcome.
Bug#930217: Please provide support for alternative network bootloaders
On Wed, Jun 19, 2019 at 04:54:33PM +0100, Steve McIntyre wrote: > There's a fair amount of work going on in Grub, but yes - it looks > like nobody's tending their bug tracker. :-( > > Network booting is clearly not the highest priority for the current > developers, but I'm sure that can be fixed with developer effort. It > works well enough for common cases, in my experience - I've just been > doing testing of this for #928750. Depends on the definition of "common case" I suppose... Attempting to netboot, reboot and netboot again in succession (without waiting 1-4 minutes) throws GRUB's TCP stack into an unrecoverable mayhem and results into a user-visible "connection timed out". Easily reproducible e.g. with QEMU. Not to mention the potentially exploitable overflows :/ > There's no way we're going to sign syslinux, I'm afraid - there has > been no support added for locking down boot (i.e. only booting a > signed kernel). Without that, Secure Boot would be a total joke. And > if you're worried about Grub development, I'd be even more worried > about syslinux. I'm on both mailing lists, and there's massively more > development happening in the Grub world. Right... That makes sense. > >An alternative to this proposal would be for Debian to submit e.g. iPXE > >separately to Microsoft for signatures and not use this in combination > >with shim. I believe this doesn't fit with the overall strategy that > >Debian and other distributions have chosen around Secure Boot with shim, > >but... I am really not an expert :) > > iPXE at least appears to be currently under development, but again I > don't see any obvious lockdown patches at all. Feel free to correct me > if you know of any work for that - I've only had a cursory look. SB > without restricting loading of kernels etc. is pointless. (disclaimer: I'm -at best- an SB novice) iPXE does support validating signatures[1][2] but not with the EFI signing protocol and not without using a custom embedded script. More importantly, however, I found this explanation at the iPXE mailing list[3]: > iPXE loads the binary and then calls the firmware LoadImage - meaning > that it is up to the firmware LoadImage function to validate the > signature, and return error to iPXE if the signature is not valid. > iPXE itself does not have any code to check the signature, and by > using the firmware to check it, it isn't needed. In this case it > seems that the image is not valid according to Firmware functions? > Could you validate that the kernel loads fine from the efi_shell, or > without having iPXE in between? I suppose that means that a shim -> iPXE -> Linux load would be pointless in this case, unless one were to construct a shim -> iPXE -> shim -> Linux chain. Would that even work, and would it be sensible? Upstream has mentioned that they have gotten Microsoft to sign some of their builds[4], and have included an "sb" variant in their buildsystem that disabled dubious subsystems like NFS and 802.11. So I suppose Microsoft does consider this secure enough and thus so could Debian? Thanks! Faidon 1: http://ipxe.org/crypto#code_signing 2: http://ipxe.org/cmd/imgtrust 3: http://lists.ipxe.org/pipermail/ipxe-devel/2018-September/006288.html 4: http://lists.ipxe.org/pipermail/ipxe-devel/2017-December/005924.html
Bug#690705: virtualbox-dkms: module not installed/loaded without reinstalling the package
Looks like it's still the case on Unstable. Just upgraded linux-image-4.19.0-5-amd64:amd64 4.19.37-4 and VBox'es failed to start with some NS.. error. Reinstalling -dkms fixes the issue.
Bug#930742: parted: fix MacOS boot support
Source: parted
Severity: normal
Tags: patch
Dear Maintainer,
parted does not properly handle MacOS partitions. The attached (from upstream)
fixes this.
See
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=43b061e90dcdab799ecd1e822852de110673bf7e
for more detail.
-- System Information:
Debian Release: 10.0
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable'), (1, 'experimental')
Architecture: ia64
Kernel: Linux 5.0.0-trunk-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/libparted/labels/mac.c b/libparted/labels/mac.c
index d8da941..fa4e43f 100644
--- a/libparted/labels/mac.c
+++ b/libparted/labels/mac.c
@@ -411,14 +411,14 @@ _rawpart_has_driver (const MacRawPartition* raw_part,
MacDiskData* mac_disk_data
{
MacDeviceDriver *driverlist;
uint16_t i;
- uint32_t driver_bs, driver_be, part_be;
+ uint32_t start_block, block_count;
+ start_block = PED_BE32_TO_CPU(raw_part->start_block);
+ block_count = PED_BE32_TO_CPU(raw_part->block_count);
driverlist = &mac_disk_data->driverlist[0];
for (i = 0; i < mac_disk_data->driver_count; i++) {
- driver_bs = driverlist->block;
- driver_be = driver_bs + driverlist->size;
- part_be = raw_part->start_block + raw_part->block_count;
- if (driver_bs >= raw_part->start_block && driver_be <= part_be)
+ if (start_block == PED_BE32_TO_CPU(driverlist->block) &&
+block_count == PED_BE16_TO_CPU(driverlist->size))
return 1;
driverlist++;
}
@@ -751,11 +751,12 @@ mac_read (PedDisk* disk)
if (!ped_disk_delete_all (disk))
goto error;
- if (raw_disk->driver_count && raw_disk->driver_count < 62) {
+ if (PED_BE16_TO_CPU(raw_disk->driver_count) &&
+PED_BE16_TO_CPU(raw_disk->driver_count) < 62) {
memcpy(&mac_disk_data->driverlist[0], &raw_disk->driverlist[0],
sizeof(mac_disk_data->driverlist));
- mac_disk_data->driver_count = raw_disk->driver_count;
- mac_disk_data->block_size = raw_disk->block_size;
+ mac_disk_data->driver_count =
PED_BE16_TO_CPU(raw_disk->driver_count);
+ mac_disk_data->block_size =
PED_BE16_TO_CPU(raw_disk->block_size);
}
/* If _disk_analyse_block_size has increased the sector_size,
@@ -877,17 +878,16 @@ static void
_update_driver_count (MacRawPartition* part_map_entry,
MacDiskData *mac_driverdata, const MacDiskData*
mac_disk_data)
{
- uint16_ti, count_orig, count_cur;
- uint32_tdriver_bs, driver_be, part_be;
-
- count_cur = mac_driverdata->driver_count;
- count_orig = mac_disk_data->driver_count;
- for (i = 0; i < count_orig; i++) {
- driver_bs = mac_disk_data->driverlist[i].block;
- driver_be = driver_bs + mac_disk_data->driverlist[i].size;
- part_be = part_map_entry->start_block +
part_map_entry->block_count;
- if (driver_bs >= part_map_entry->start_block
- && driver_be <= part_be) {
+ uint16_ti;
+ uint32_tstart_block, block_count;
+
+ start_block = PED_BE32_TO_CPU(part_map_entry->start_block);
+ block_count = PED_BE32_TO_CPU(part_map_entry->block_count);
+
+ for (i = 0; i < mac_disk_data->driver_count; i++) {
+ if (start_block ==
PED_BE32_TO_CPU(mac_disk_data->driverlist[i].block) &&
+ block_count ==
PED_BE16_TO_CPU(mac_disk_data->driverlist[i].size)) {
+ uint16_t count_cur = mac_driverdata->driver_count;
mac_driverdata->driverlist[count_cur].block
= mac_disk_data->driverlist[i].block;
mac_driverdata->driverlist[count_cur].size
@@ -934,7 +934,6 @@ _generate_raw_part (PedDisk* disk, PedPartition* part,
strncpy (part_map_entry->type, mac_part_data->system_name, 32);
if (mac_part_data->is_driver) {
- mac_part_data->boot_region_length = part->geom.length;
if (mac_part_data->has_driver)
_update_driver_count(part_map_entry, mac_driverdata,
mac_disk_data);
@@ -1042,7 +1041,7 @@ write_block_zero (PedDisk* disk, MacDiskData*
mac_driverdata)
raw_disk->block_size = PED_CPU_TO_BE16 (dev->sector_size);
raw_disk->block_count = PED_CPU_TO_BE32 (dev->length);
- raw_disk->driver_count = mac_driverdata->driver_count;
+ raw_disk->driver_count = PED_CPU_TO_BE16(mac_driverdata->driver_count);
memcpy(&raw_disk->driv
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Hi Andrew So far as I am aware there is still radio silence from active GNOME packaging team members regarding this issue. No comment yet on the patch I adapted, positive or negative; this bug (#927667) remains at an RC severity. I've not yet read all the thread that Samuel linked to[1] but it looks like it leans in favour of preserving the current default (xorg). I'm copying -release team to see if they have any (new) opinions on the matter. Otherwise I guess it's up to someone to prepare an NMU upload, which I will *try* to look at in the next few days, but can't make any guarantees. Further testers of the patch on this bug would be most welcome. [1] https://lists.debian.org/debian-accessibility/2019/02/threads.html#4
Bug#930042: [pkg-gnupg-maint] Bug#930042: FTBFS when building arch-dep only
On 6/19/19 2:01 PM, Daniel Kahn Gillmor wrote: > https://bugs.debian.org/930689 oh, nice.. thanks! Regards, Daniel
Bug#928758: [debian-mysql] Bug#928758: mariadb-server: mysql_install_db fails if basedir option isn't set, expecting resolveip to be present in /usr/sbin/
Hello! I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929257 a month ago to get permission to upload .40 to Stretch. If you are in favor of it, please let the release team know by replying to that issue.
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Hi, I think it is okay for those diacritics. Regards, ‐‐‐ Original Message ‐‐‐ Le mardi 18 juin 2019 22:26, Holger Wansing a écrit : > Hi, > > Samuel Thibault sthiba...@debian.org wrote: > > > Hello, > > Holger Wansing, le mar. 04 juin 2019 20:59:12 +, a ecrit: > > > > > Am Sonntag, 2. Juni 2019 schrieb Holger Wansing: > > > > > > > Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault: > > > > > > > > > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit: > > > > > > > > > > > > > "لاحقاً" > > > > > > > > > > > > This word means "later" and can be replaced by "لاحقا". > > > > > > > > > > That avoids the issue here indeed. I however see it used in various > > > > > > > > Hmm. > > > > There has been no changing in the ar.po of partman-auto > > > > for 3 years now (JFTR), thus the real problem seems to be > > > > sitting somewhere else ... > > > > > > How should we proceed here? > > > Since we are late in the freeze, and it's most probably not that > > > easy to find out what happened and what the real issue is: > > > should we go with the "work-around" proposed by > > > Butterflyoffire and confirmed to fix the issue by Samuel? > > > > Personally, I don't think I'll have the time to debug what is actually > > happening inside gtk until the release, so even if it's ugly, I guess > > the browntape fix is the least worst I can come up with. > > That looks fair. > I have committed the proposed fix now. > > @butterflyoffire: could you please take a look at > https://salsa.debian.org/installer-team/d-i/commit/fa17b7afffb2ee4888a371efa4153c5c075915e7 > to double-check if the fix is fine by you? > Thanks! > > Holger > > > - > > Holger Wansing hwans...@mailbox.org > PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#930741: unblock: debian-electronics/0.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-electronics As in every release process I have updated several Blends metapackages which needed updates due to package removals to reflect the package pool of the release. These metapackages are created using the latest blends-dev package. The changes in the debian-electronics package are to a large extend auto generated by blends-dev and the full debdiff (attached debian-electronics_0.2-0.3.diff.gz) is a bit hard to read because the files in tasks/ are serving at the same time used as documentation for the Debian Med web sentinel. There is no reasonable way to maintain this in a separate source so the diff is larger than you would usually accept these days. This was done in the same way for several previous releases. To enable you concentrating on the *relevant* changes which are caused due to changes in the package pool I added wdiff debian-electronics-0.2/debian/control debian-electronics-0.3/debian/control > debian-electronics_control_0.2-0.3.wdiff which is more easy to inspect to see what relevant changes in the dependencies have actually happended (see debian-electronics_control_0.2-0.3.wdiff.gz). Kind regards Andreas. unblock debian-electronics/0.3 -- 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-6-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) debian-electronics_0.2-0.3.diff.gz Description: application/gzip debian-electronics_control_0.2-0.3.wdiff.gz Description: application/gzip
Bug#930728: pg_cltlcluster leaks logfile descriptor into PostgreSQL backends
> 19 июня 2019 г., в 20:57, Christoph Berg написал(а):
>
> Control: tags -1 moreinfo
>
> Re: Andrey Borodin 2019-06-19
> <3fd6aec7-55c8-4129-a46c-0bb3e4296...@yandex-team.ru>
>> Package: postgresql-common
>> Version: 199
>>
>> When I execute
>> service postgresql start
>> I observe that logfile descriptor will leak into postmaster and every
>> backend. This is not fd opened by PG's syslogger.
>
> That's because we use logging to stderr.
>
>> -my $fd = POSIX::open($info{'logfile'},
>> POSIX::O_WRONLY|POSIX::O_APPEND|POSIX::O_CREAT) or error "Could not open
>> logfile $info{'logfile'}";
>> -dup2($fd, 1);
>> -dup2($fd, 2);
>> +open(STDOUT, ">>$info{logfile}") or die $!;
>> +open(STDERR, '>&STDOUT') or die $!;
>
> Does that actually do things differently? Does stderr logging still
> work with that patch?
On my observation - yes, descriptor 4 is no longer in lsof.
I looked that I see some lines of pg_ctl output like "output will be redirected
etcetc" in pglog. But not from stderr.
But I've checked only on Yandex.Cloud clusters. I think I'll do repro on fresh
Ubuntu...
I'm not an expert in Perl, these two lines were my first experience, and even
in them I needed a lot of help from colleagues with Perl background.
Best regards, Andrey Borodin.
Bug#930728: pg_cltlcluster leaks logfile descriptor into PostgreSQL backends
Control: tags -1 moreinfo
Re: Andrey Borodin 2019-06-19
<3fd6aec7-55c8-4129-a46c-0bb3e4296...@yandex-team.ru>
> Package: postgresql-common
> Version: 199
>
> When I execute
> service postgresql start
> I observe that logfile descriptor will leak into postmaster and every
> backend. This is not fd opened by PG's syslogger.
That's because we use logging to stderr.
> -my $fd = POSIX::open($info{'logfile'},
> POSIX::O_WRONLY|POSIX::O_APPEND|POSIX::O_CREAT) or error "Could not open
> logfile $info{'logfile'}";
> -dup2($fd, 1);
> -dup2($fd, 2);
> +open(STDOUT, ">>$info{logfile}") or die $!;
> +open(STDERR, '>&STDOUT') or die $!;
Does that actually do things differently? Does stderr logging still
work with that patch?
Christoph
Bug#930217: Please provide support for alternative network bootloaders
Hey Faidon, Control: tags -1 +wontfix On Sat, Jun 08, 2019 at 03:43:37PM +0300, Faidon Liambotis wrote: >Package: src:shim >Version: 15+1533136590.3beb971-7 >Severity: wishlist > >(I'm Cc'ing the syslinux and iPXE maintainers here for their information >and to seek their opinion. I haven't discussed this matter with neither >of them and do not speak for them.) > >Currently, the only way to network boot a Debian EFI system with Secure >Boot via shim is to use GRUB, as this is the only combination that's >SB-signed (bootnetx64.efi even hardcodes grubx64.efi). This is what >Debian's own netboot.tar.gz ship with as well > >However, GRUB's TCP/IP + DNS + HTTP stack is... to put it politely, >severely lacking. I've managed to crash it[1], find serious TCP[2] or >HTTP[3] implementation bugs, run into very basic limitations (e.g. on >dual-stack hostnames[5]), all within a few hours. For some reason >they've decided to build a TCP/IP stack from scratch (rather than use >EFI's, or something like lwIP), but their code, to this day, has >comments like "/* FIXME: overflow. */". I've tried to build a sane >netboot configuration with GRUB, and work around its bugs, but >ultimately failed -- it's just too buggy for anything but just booting a >kernel + initramfs, and if even that. > >1: 52408aa94604466bdd80f48fa8d68378a1ffab31 >2: https://savannah.gnu.org/bugs/?56391 >3: https://savannah.gnu.org/bugs/?49531 >4: https://savannah.gnu.org/bugs/?56390 > >Despite these having been reported upstream, I don't have high hopes; >their bug tracker is a dumpster fire. Noone is responding to old or new >bugs, no matter their severity. I was looking into SMBIOS support as >well, and it looks someone has written a working patch that other >distributions ship; that person has been submitting it once a year since >2013, and never received a response. I filed this as a bug in their bug >tracker[5] but that has not received a response either. > >5: https://savannah.gnu.org/bugs/?56164 > >All in all, I think there are two compounding issues here: 1) the GRUB >project's overall health 2) network boot not being a priority for them. There's a fair amount of work going on in Grub, but yes - it looks like nobody's tending their bug tracker. :-( Network booting is clearly not the highest priority for the current developers, but I'm sure that can be fixed with developer effort. It works well enough for common cases, in my experience - I've just been doing testing of this for #928750. >However, this being free software, there are alternatives :) The two >most popular network bootloaders are: > >1) SYSLINUX (syslinux.efi specifically): this is much more restricted in >terms of features, but good enough for many use cases and more reliable >than GRUB. syslinux.efi uses the EFI stack's TCP/IP implementation >(Tcp4ServiceBindingProtocol) and doesn't roll its own, which at least >makes it more secure than GRUB's (albeit without IPv6 support right >now). The other advantage here is that this is fully compatible with a >PXELINUX config which most people are used to. Debian's own d-i images >ship with such a configuration to this day and this could be an >out-of-the box alternative. > >2) iPXE: this is widely used in both PXE and EFI configurations. QEMU is >even using it to netboot by default. It has a flexible configuration >language, lots of features out of the box, and a much, much, much >cleaner codebase than GRUB. Their documentation is far more superior >too. They even have a page with instructions for how one can submit iPXE >to Microsoft to get it SB-signed[6] and there are reports on the web >that Microsoft has actually signed[7] of their versions. > >6: http://ipxe.org/appnote/etoken >7: https://twitter.com/ipxe/status/331176286972157953 > >The request here is for Debian w/ Shim to support an alternative to GRUB >out of the box, and to sign iPXE and/or syslinux. These are alternatives >that are clearly superior in features, stability -and, dare I say, >security- over GRUB and Debian shouldn't artificially limit our choices >to just one. There's no way we're going to sign syslinux, I'm afraid - there has been no support added for locking down boot (i.e. only booting a signed kernel). Without that, Secure Boot would be a total joke. And if you're worried about Grub development, I'd be even more worried about syslinux. I'm on both mailing lists, and there's massively more development happening in the Grub world. >An alternative to this proposal would be for Debian to submit e.g. iPXE >separately to Microsoft for signatures and not use this in combination >with shim. I believe this doesn't fit with the overall strategy that >Debian and other distributions have chosen around Secure Boot with shim, >but... I am really not an expert :) iPXE at least appears to be currently under development, but again I don't see any obvious lockdown patches at all. Feel free to correct me if you know of any work for that - I've only had a cursory look. SB wit
Bug#930356: CVE-2019-12760
Hi Piotr > Please see https://bugzilla.redhat.com/show_bug.cgi?id=1718212 > > Patch is at https://gist.github.com/dhondta/f71ae7e5c4234f8edfd2f12503a5dcc7 I know you are usually pretty quick in solving serious issues. I tried to check the issue and think the link provided for a patch is just pointing to a proof of concept exploit. When reading the discussion here https://github.com/davidhalter/parso/issues/75 I understand that it is not fixed but the authors do not consider the issue serious. Could you please give some comment from an insiders point of view (which I'm not). I'm just caring since several Debian Science dependencies are about to be removed from testing due to this bug. Kind regards Andreas. PS: Is there any reason why this package is not on Salsa and not team maintained? -- http://fam-tille.de
Bug#846935: inadyn: New upstream release available, v2.1
Package: inadyn Followup-For: Bug #846935 I was about to file a bug report about updating inadyn. The version on the repo is ~6 years old and even this bug report is ~2 years old. Today, inadyn is on v2.5. In fact, It has been at v2.5 since September 2018! So please update it. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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) Versions of packages inadyn depends on: ii adduser 3.118 ii libc62.28-10 inadyn recommends no packages. inadyn suggests no packages.
Bug#930740: unblock: debian-junior/1.29
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-junior As in every release process I have updated several Blends metapackages which needed updates due to package removals to reflect the package pool of the release. These metapackages are created using the latest blends-dev package. The changes in the debian-junior package are to a large extend auto generated by blends-dev and the full debdiff (attached debian-junior_1.28-1.29.diff.gz) is a bit hard to read because the files in tasks/ are serving at the same time used as documentation for the Debian Med web sentinel. There is no reasonable way to maintain this in a separate source so the diff is larger than you would usually accept these days. This was done in the same way for several previous releases. To enable you concentrating on the *relevant* changes which are caused due to changes in the package pool I added wdiff debian-junior-1.28/debian/control debian-junior-1.29/debian/control > debian-junior_control_1.28-1.29.wdiff which is more easy to inspect to see what relevant changes in the dependencies have actually happended (see debian-junior_control_1.28-1.29.wdiff.gz). Kind regards Andreas. unblock debian-junior/1.29 -- 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-6-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) debian-junior_1.28-1.29.diff.gz Description: application/gzip debian-junior_control_1.28-1.29.wdiff.gz Description: application/gzip
Bug#929129: [Pkg-xen-devel] Bug#929129: closed by Hans van Kranenburg (Bug#929129: fixed in xen 4.11.1+92-g6c33308a8d-1)
On 6/19/19 4:43 PM, Wiebe Cazemier wrote: > This is an update to the unstable release. What is one running Debian > stable (9), with Xen Hypervisor 4.8, to do? This is not meant as a middle finger to users of stable. All of the bug numbers will be closed twice, also by the 4.8 upload, which also has to mention them. This is confusing, however the automated behaviour after uploading any of them is to close the bug with that report. At least the 4.11 is out now, last thing I heard about 4.8 was that there are issues compiling the current 4.8-stable upstream branch in Stretch, and that's quite an important prerequisite for continuing. :| Ian needs to work on that. I will see if I can manipulate them a bit. All the other ones mentioned in the changelog should also have the info that it's found in current version in stable attached to them, so that the version graph shows both. Hans
Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth
On Wed, Jun 19, 2019 at 2:56 PM Steffen Nurpmeso wrote:
> > What would be further useful debugging or tracing information to
> > share?
>
> In general our -d or -vv switches would be nice. ^_^
Here's with -d:
```
s-nail: No such file to load: /usr/local/etc/s-nail.rc
s-nail: Loading /home/ivucica/.mailrc
s-nail: LOAD 0 bytes <>
s-nail: LOAD 22 bytes <#set imap-use-starttls>
s-nail: LOAD 0 bytes <>
s-nail: LOAD 17 bytes
s-nail: COMMAND mydomain {
s-nail: LOAD 52 bytes < set folder=imap://ivuc...@myhostname.ds.mydomain.net>
s-nail: LOAD 18 bytes < set record=+Sent>
s-nail: LOAD 22 bytes < set imap-auth=gssapi>
s-nail: LOAD 45 bytes < ##set from="myname@myisp.example (My Name)">
s-nail: LOAD 33 bytes < # #set smtp=smtp.myisp.example>
s-nail: LOAD 1 bytes <}>
s-nail: LOAD 15 bytes
s-nail: COMMAND mydomain
s-nail: MACRO 50 bytes
s-nail: COMMAND folder=imap://ivuc...@myhostname.ds.mydomain.net
s-nail: MACRO 16 bytes
s-nail: COMMAND record=+Sent
s-nail: MACRO 20 bytes
s-nail: COMMAND imap-auth=gssapi
s-nail: MACRO 43 bytes <##set from="myname@myisp.example (My Name)">
s-nail: MACRO 31 bytes <# #set smtp=smtp.myisp.example>
s-nail: LOAD 0 bytes <>
s-nail: LOAD 31 bytes <#set MAIL=/home/ivucica/Maildir>
s-nail: LOAD 16 bytes <#set folder mail>
s-nail: LOAD 0 bytes <>
s-nail: Obsoletion warning: no more expansion of *folder* in "%":
please set *inbox*
s-nail: Obsoletion warning: Use of old-style credentials, which will
vanish in v15!
Please read the manual section "On URL syntax and credential lookup"
s-nail: Credentials: host ivuc...@myhostname.ds.mydomain.net, user ivucica, pass
s-nail: Resolving host myhostname.ds.mydomain.net:imap ... done
s-nail: Connecting to 10.0.0.150:imap ... connected.
s-nail: P(seudo)R(andom)N(umber)G(enerator): *TLS RAND_*
s-nail: >>> SERVER: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR
LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=GSSAPI
AUTH=LOGIN] Dovecot ready.
>>> T1 CAPABILITY
>>> SERVER: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
>>> IDLE STARTTLS AUTH=PLAIN AUTH=GSSAPI AUTH=LOGIN
>>> SERVER: T1 OK Pre-login capabilities listed, post-login capabilities have
>>> more.
[6655] 1560952720.212825: ccselect module realm chose cache
FILE:/tmp/krb5cc_501 with client principal ivuc...@ds.mydomain.net for
server principal imap/myhostname.ds.mydomain@ds.mydomain.net
[6655] 1560952720.212826: Getting credentials ivuc...@ds.mydomain.net
-> imap/myhostname.ds.mydomain@ds.mydomain.net using ccache
FILE:/tmp/krb5cc_501
[6655] 1560952720.212827: Retrieving ivuc...@ds.mydomain.net ->
imap/myhostname.ds.mydomain@ds.mydomain.net from
FILE:/tmp/krb5cc_501 with result: 0/Success
[6655] 1560952720.212829: Creating authenticator for
ivuc...@ds.mydomain.net ->
imap/myhostname.ds.mydomain@ds.mydomain.net, seqnum 920437301,
subkey rc4-hmac/47F8, session key rc4-hmac/6715
[6655] 1560952720.212830: Negotiating for enctypes in authenticator:
aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1,
rc4-hmac, camellia128-cts, camellia256-cts
>>> T2 AUTHENTICATE GSSAPI
>>> SERVER: +
>>> YIIFhgOMITTING-WHAT-LOOKS-LIKE-CREDENTIALS3tM=
>>> SERVER: + YIGVBOMITTING-WHAT-LOOKS-LIKE-CREDENTIALSZIXw=
[6655] 1560952720.212835: Read AP-REP, time 1560952720.212831, subkey
aes256-cts/B91D, seqnum 73895367
>>>
>>> SERVER: + BQOMITTINGu58=
>>> BQCREDENTIALS8E=
>>> SERVER: T2 NO [AUTHENTICATIONFAILED] Authentication failed.
IMAP error: [AUTHENTICATIONFAILED] Authentication failed.
```
It is really hard to follow the debug info given, and the amount of
info changed between the old and new s-nail. But eyeballing the
credentials sent in both versions, there is nothing obviously damaged
in authentication lines.
I could be wrong, of course.
> ...
> |ivucica@myhostname:~$ klist
> |Credentials cache: FILE:/tmp/krb5cc_501
> |Principal: ivuc...@ds.mydomainname.net
> |
> | IssuedExpires Principal
> |Jun 19 11:25:37 2019 Jun 19 21:25:37 2019 krbtgt/DS.MYDOMAINNAME.NET@D\
> |S.MYDOMAINNAME.NET \
> ...
> fail
> ...
No, this is actually success. I kdestroyed the ticket cache
beforehand, and kinited.
This is the 'krbtgt' - 'kerberos ticket-granting-ticket' which is used
to get service-specific tickets.
I pasted this to demonstrate that GSSAPI is invoked correctly to
obtain the service-specific ticket when launching the newly-built
s-nail. That is: GSSAPI manages to get
imap/myhostname.ds.mydomain@ds.mydomainname.net ticket, usable to
authenticate against Dovecot.
> |ivucica@myhostname:~$ klist
> |Credentials cache: FILE:/tmp/krb5cc_501
> |Principal: ivuc...@ds.mydomainname.net
> |
> | IssuedExpires Principal
> |Jun 19 11:25:37 2019 Jun 19 21:25:37 2019 krbtgt/DS.MYDOMAINNAME.NET@D\
> |S.MYDOMAINNAME.NET \
> |
> |Jun 19 11:25:42 2019 Jun 19 21:25:37 2019 i
Bug#930739: unblock: debichem/0.0.8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debichem As in every release process I have updated several Blends metapackages which needed updates due to package removals to reflect the package pool of the release. These metapackages are created using the latest blends-dev package. The changes in the debichem package are to a large extend auto generated by blends-dev and the full debdiff (attached debichem_0.0.7-0.0.8.diff.gz) is a bit hard to read because the files in tasks/ are serving at the same time used as documentation for the Debian Med web sentinel. There is no reasonable way to maintain this in a separate source so the diff is larger than you would usually accept these days. This was done in the same way for several previous releases. To enable you concentrating on the *relevant* changes which are caused due to changes in the package pool I added wdiff debichem-0.0.7/debian/control debichem-0.0.8/debian/control > debichem_control_0.0.7-0.0.8.wdiff which is more easy to inspect to see what relevant changes in the dependencies have actually happended (see debichem_control_0.0.7-0.0.8.wdiff.gz). Kind regards Andreas. unblock debichem/0.0.8 -- 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-6-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#930720: Dependency "linux-headers-xyz" missing, needed for BPF compilation
On Wed, 2019-06-19 at 14:30 +, Cirujano Cuesta, Silvano wrote: > Hi Ritesh, > > Thanks for quick answers and the link to the enlightening bug report! > > I'm nevertheless the opinion, that some kind of more helpful > reporting should be used. If you care for it, you can come up with something similar to what systemtap does. It is good enough but it would still need to be documented somewhere to use the prep tool. rrs@priyasi:~$ stap-prep You need package linux-image-4.19.0-5-amd64-dbgsym but it does not seem to be available Debian -dbgsym packages are typically in a separate repository Follow https://wiki.debian.org/AutomaticDebugPackages to add this repository Be root or adduser rrs stapusr Be root or adduser rrs stapdev 20:26 ♒♒♒ ☺ 😄 PS: And now, as of today, this tool has become incorrect in its reporting. Something I need to fix again and push upstream to systemtap. One more reason why I rather prefer to document and instruct people to find the relevant files rather than hardcoding their names. > Perhaps upstream? I am not sure about upstream's view but you can check with them. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#930738: unblock: debian-science/1.10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-science As in every release process I have updated several Blends metapackages which needed updates due to package removals to reflect the package pool of the release. These metapackages are created using the latest blends-dev package. The changes in the debian-science package are to a large extend auto generated by blends-dev and the full debdiff (attached debian-science_1.9-1.10.diff.gz) is a bit hard to read because the files in tasks/ are serving at the same time used as documentation for the Debian Med web sentinel. There is no reasonable way to maintain this in a separate source so the diff is larger than you would usually accept these days. This was done in the same way for several previous releases. To enable you concentrating on the *relevant* changes which are caused due to changes in the package pool I added wdiff debian-science-1.9/debian/control debian-science-1.10/debian/control > debian-science_control_1.9-1.10.wdiff which is more easy to inspect to see what relevant changes in the dependencies have actually happended (see debian-science_control_1.9-1.10.wdiff.gz). Kind regards Andreas. unblock debian-science/1.10 -- 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-6-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) debian-science_1.9-1.10.diff.gz Description: application/gzip debian-science_control_1.9-1.10.wdiff.gz Description: application/gzip
Bug#930720: Dependency "linux-headers-xyz" missing, needed for BPF compilation
Hi Ritesh, Thanks for quick answers and the link to the enlightening bug report! I'm nevertheless the opinion, that some kind of more helpful reporting should be used. Perhaps upstream? BR, Silvano On Wed, 2019-06-19 at 17:39 +0530, Ritesh Raj Sarraf wrote: > On Wed, 2019-06-19 at 09:21 +, Cirujano Cuesta, Silvano wrote: > > IMHO it should be a "Depends" dependency, or at least a "Recommends" > > dependency. > > We can't do that. The same is explained in the following bug report: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877925 > > That is the reason I documented it into the README.Debian file. This is > similar to the case of the systemtap package. Both of which serve > similar purposes. > > Thanks, > Ritesh >
Bug#930670: unblock: rabbitmq-server/3.7.8-5
On 6/19/19 6:47 AM, Paul Gevers wrote: > Hi Thomas, > > On 18-06-2019 09:42, Thomas Goirand wrote: >> This last Debian release adds the packaging of rabbitmq-diagnostic in >> /usr/sbin, which is a very useful tool. It'd be a diss-service to our >> users to not have it in Buster, and I don't think this is controvertial >> at all. Not counting the removal of debian/gbp.conf (which we don't use >> anymore), the attached debdiff is a one-liner. >> >> unblock rabbitmq-server/3.7.8-5 > > Sorry, too late. We want to release in two weeks and adding new features > is a station long past. > > I spent quite some time thinking about it as this particular change > seems acceptable as an exception, however I fear the precedent will make > our future work more difficult as it will invite more request that don't > qualify and need careful analysis. People are reading these reports. > > Paul > I do understand it's not a nice timing for such an update, even if it's very minimal. Maybe it will be accepted as a buster-proposed-update for the first point release, then? FYI, monitoring of RabbitMQ is a mission-critical thing, and I just missed this new binary from upstream which simplifies A LOT the monitoring of RabbitMQ, which is the source of 99% of the troubles on an OpenStack cluster. I really want to bring this to Buster users. Cheers, Thomas Goirand (zigo)
