Bug#920409: splitpatch: please make the build reproducible
forwarded 920409 https://github.com/benjsc/splitpatch/pull/10 thanks I've forwarded this upstream here: https://github.com/benjsc/splitpatch/pull/10 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#920410: ldc ftbfs with ld --as-needed as the default
Package: src:ldc
Version: 1:1.12.0-1
Severity: important
Tags: sid bullseye
ldc ftbfs with ld --as-needed as the default. Apparently this is a packaging
change in 1.12, because 1.11 built.
from
https://launchpadlibrarian.net/408101762/buildlog_ubuntu-disco-amd64.ldc_1%3A1.12.0-1_BUILDING.txt.gz
make[4]: Entering directory '/<>/build-static'
[ 0%] Generating ../bin/ldc-prune-cache
cd /<> && /<>/build-temp/bin/ldmd2 -wi -fPIC -O
-inline -release -J/<>/dmd -J/<>/res
-I/<> -I/<>/build-static -version=IN_LLVM -L-lz
-I/<>/dmd -of/<>/build-static/bin/ldc-prune-cache
/<>/tools/ldc-prune-cache.d /<>/driver/cache_pruning.d
This is from debian/patches/01_no-zlib-embed.patch:
--- a/tools/CMakeLists.txt
+++ b/tools/CMakeLists.txt
@@ -9,7 +9,7 @@
function(build_d_tool output_exe compiler_args linker_args compile_deps
link_deps)
set(dflags "${D_COMPILER_FLAGS} ${DDMD_DFLAGS}")
-set(lflags "")
+set(lflags "-L-lz")
if(UNIX)
separate_arguments(dflags UNIX_COMMAND "${dflags}")
separate_arguments(lflags UNIX_COMMAND "${lflags}")
"-L-lz" is wrong. What is it supposed to do?
And passing libraries in macros known as *glags* is error prone too, as you see
here.
Bug#920411: mongo-c-driver: please make the build reproducible
Source: mongo-c-driver
Version: 1.13.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed
that mongo-c-driver could not be built reproducibly.
This/was partly due to the shipped mongoc-config.h file containing
the CFLAGS that were used to build the package, thus including the
buildpath in the calls to -f{debug,file}-prefix-map.
Patch attached, but if this file is not needed in the binary
packages, I would simply remove it.
(I think it also embeds the aforementioned CFLAGS into the resulting
libbson*.so too?)
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/rules 2019-01-25 08:33:17.364118736 +0100
--- b/debian/rules 2019-01-25 08:56:08.184184279 +0100
@@ -30,6 +30,11 @@
-DENABLE_TESTS=OFF \
-DENABLE_ZLIB=SYSTEM
+override_dh_auto_install:
+ dh_auto_install
+ find $(CURDIR)/debian/tmp/usr/include -type f -name "*.h" -print0 | \
+ xargs -0r sed -i -e 's@ [^ ]*-f\(file\|debug\)-prefix-map=[^
]*@@g'
+
#override_dh_install:
# dh_install -a -X.la -Xmongoc-stat -Xdoc/mongo-c-driver -Xdoc/libbson
-Xman/man3 -X-priv.so -X-priv.pc --fail-missing
Bug#843021: [Pkg-javascript-devel] RFS: node-yarnpkg
Le 25/01/2019 à 08:16, Paolo Greppi a écrit : > Il 25/01/19 07:18, Paolo Greppi ha scritto: >> Il 25/01/19 06:24, Pirate Praveen ha scritto: >>> On വെ, ജനു 25, 2019 at 10:22 രാവിലെ, Paolo Greppi >>> wrote: ... >>> >>> E: yarnpkg: package-contains-ancient-file >>> usr/lib/nodejs/yarn/node_modules/npm-logical-tree/CHANGELOG.md 1970-01-01 >>> (and some more) >> >> ... >> I wonder how we can fix this ! >> >> Paolo > > @yadd says: >> Remove *.orig.tar.gz and regenerate them with gbp buildpackage > > and indeed: > > rm ../node-yarnpkg_1.13.0.orig* > gbp buildpackage -uc -us > > now the npm-logical-tree tarball is different and: > > tar xf ../node-yarnpkg_1.13.0.orig-npm-logical-tree.tar.gz > ls node-yarnpkg-1.13.0/ -l > totale 28 > -rw-r--r-- 1 paolog paolog 1222 gen 25 08:09 CHANGELOG.md > -rw-r--r-- 1 paolog paolog 4919 gen 25 08:09 index.js > -rw-r--r-- 1 paolog paolog 755 gen 25 08:09 LICENSE.md > -rw-r--r-- 1 paolog paolog 1380 gen 25 08:09 package.json > -rw-r--r-- 1 paolog paolog 4563 gen 25 08:09 README.md > > Paolo Hello, I fixed some little things but looking at debian/tests/yarn, it seems that this test download packages during test. I think it's bad. Is it also possible to add a test during build (override_dh_auto_test) ? Without network access of course. Cheers, Xavier
Bug#915856: sphinx: Failed cross building with Build-Depends on python3-sphinx
On Sun, Jan 20, 2019 at 09:48:25PM +0100, Helmut Grohne wrote: > Upon closer inspection, I'm growing doubts. The autodoc extension is not > in some python3-sphinxcontrib.something package but in python3-sphinx > proper. Therefore you want a way of using a particular architecture's > sphinx anyway. Marking it M-A:foreign is likely going to cause trouble > later on. So if you split out this sphinx package, you'd likely have > python3-sphinx Depends: sphinx at least initially. Without that > dependency, lots of packages will FTBFS. Then sphinx would of course > Depends: python3-sphinx posing a circular dependency until we fix all > those FTBFS. Then any package that refers to the scripts and uses > autodoc must "Build-Depends: sphinx, python3-sphinx". This is confusing > at the very least. > > Certainly not something we want to do before buster. I agree, that would be confusing for people who are not experts in cross-building and multiarch stuff. > > Is it safe to add Multi-Arch: allowed to python-sphinx and python3-sphinx > > right now (and Multi-Arch: foreign to sphinx-common)? > > I overlooked one major issue with Multi-Arch: allowed. The value is not > permitted on Architecture: all packages. So if you trying using it, you > end up switching python3-sphinx to Architecture: any. > > Beyond that, the marking is certainly not doing any immediate harm. > Until some other package uses "python3-sphinx:any" literally nothing > changes. As soon as you get such a dependency however, reverting becomes > difficult. Removing "Multi-Arch: allowed" will make all > "python3-sphinx:any" dependencies immediately unsatisfiable (even > natively). Ack. > For Build-Depends, you can use "python3-sphinx:native" now. Until very > recently that wasn't possible as dpkg-checkbuilddeps would reject > :native annotations on Architecture: all packages, but dpkg has adjusted > behaviour to what apt and dose do now. Therefore such dependencies harm > stretch-backports. Still it might be the best thing we have at the > moment. Oh, that's a very good piece of news! Does this mean that packages that are not using autodoc (like ncmpc) can already build-depend on python3-sphinx:native to become cross-buildable? > Well, we do have some data on which packages are affected. Carefully > open this huge html file: https://bootstrap.debian.net/cross_all.html. > Then search for "python3-sphinx" and you get an overview of which > packages are affected. It currently is the #10 cross unsatisfiable cause > with 146 affected packages. Searching again will reveal the actual > source packages. Note that the list already excludes Build-Depends-Indep > as well as source packages that only build architecture-independent > binary packages. Carefully pick valuable targets here. For instance > large documentation trees, long build time, high popcon. Does cmake sound like a good start? It already has docs in a separate package, just needs the B-D adjusted. > There is a reason why I have - for a long time - not actively worked on > cross/sphinx: There is no obvious solution. I wish I could give more > encouraging answers. Ack. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#920412: package-update-indicator: Missing menu entry to force instannt cache refresh
Package: package-update-indicator Version: 2.0-1 Severity: minor Tags: upstream Menu entries to force instant cache refreshh would be handy. [ 1. using standard config 2. even over mobile connection ] -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages package-update-indicator depends on: ii dconf-gsettings-backend [gsettings-backend 0.30.1-2 ii libappindicator3-1 0.4.92-7 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-5 ii libcairo-gobject2 1.16.0-2 ii libcairo2 1.16.0-2 ii libdbusmenu-glib4 18.10.20180917~bzr490+repack1-1 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libglib2.0-02.58.2-3 ii libgtk-3-0 3.24.4-1 ii libpackagekit-glib2-18 1.1.12-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpolkit-gobject-1-0 0.105-25 ii libsqlite3-03.26.0+fossilbc891ac6b-1 ii libupower-glib3 0.99.9-2 ii packagekit 1.1.12-1 Versions of packages package-update-indicator recommends: ii gnome-packagekit 3.30.0-1 package-update-indicator suggests no packages. -- debconf-show failed
Bug#919798: closed by Matthias Klose (Bug#919798: fixed in openjdk-11 11.0.2+9-1)
so this is not an openjdk error, and should be fixed in the pacakges itself. See 8211916: Javadoc -link makes broken links if module name matches package name http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/66a53d6047d1 see the -source 8 passed in the tests.
Bug#920365: mariadb_config: improve cross compilation support
Re: Helmut Grohne 2019-01-24 <20190124190511.ga30...@alf.mars> > This is very unfortunate and we've had the exact same situation with > postgresql/pg_config. Then Christoph (Cced) came up with a crazy idea: > Run pg_config at build time, capture all of its output and generate a > shell script from it. Then he turned the packaged pg_config into a perl > script. How does that help? When running the host architecture > pg_config, it is run via /usr/bin/perl, which is a build architecture > executable. The "Exec format error" goes away. One gets the right > results. Fwiw, the PostgreSQL hack is there: https://salsa.debian.org/postgresql/postgresql/blob/11/debian/pg_config.pl The __DATA__ section there is a stub, it get replaced by the real data at build time. https://salsa.debian.org/postgresql/postgresql/blob/11/debian/rules#L187-191 Christoph
Bug#872234: mlpy: FTBFS with Sphinx 1.6: Needs build-dep on latexmk
Control: retitle -1 mlpy: FTBFS: Needs build-dep on latexmk, pngmath replaced with imgmath On Tue, Aug 15, 2017 at 12:26:45PM +0300, Dmitry Shachnev wrote: > mlpy fails to build with Sphinx 1.6, currently available in experimental: > > PYTHONPATH=/<>/build/lib.linux-x86_64-2.7 /usr/bin/make -C > docs/build/latex all-pdf > make[1]: Entering directory '/<>/docs/build/latex' > latexmk -pdf -dvi- -ps- 'mlpy.tex' > make[1]: latexmk: Command not found > Makefile:33: recipe for target 'mlpy.pdf' failed > make[1]: *** [mlpy.pdf] Error 127 > > Since Sphinx 1.6, latexmk is required to build the LaTeX documentation [1]. > Adding a build-dependency on latexmk should help. > > [1]: https://github.com/sphinx-doc/sphinx/pull/3082 With Sphinx 1.8, there is a new build failure: Running Sphinx v1.8.3 Extension error: Could not import extension sphinx.ext.pngmath (exception: No module named pngmath) The pngmath extension was deprecated in Sphinx 1.4 and has been removed [1] in Sphinx 1.8. The recommended alternative is sphinx.ext.imgmath [2] which also has SVG support in addition to PNG. [1]: https://github.com/sphinx-doc/sphinx/pull/4702 [2]: https://www.sphinx-doc.org/en/1.8/usage/extensions/math.html As both issues are related to Sphinx, I am not filing a new bug but adjusting the description of this one. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#920350: ITP: pkg-js-autopkgtest -- collection of autopktest scripts for nodejs packages
Le 24/01/2019 à 23:27, Xavier a écrit : > Le 24/01/2019 à 20:12, Paul Gevers a écrit : >> Oops, >> >> On 24-01-2019 20:09, Paul Gevers wrote: >>> Hi Xavier, >>> >>> On 24-01-2019 15:25, Xavier Guimard wrote: Packages using the tests with autopkgtests in this package will simply have to set "Testsuite: autopkgtest-pkg-js" in debian/control and write upstream test in debian/tests/pkg-js/test. This package provides also a test.mk file which can be include in debian/rule to avoid writing a override_dh_auto_test. The same test will be launched. This package is inspired from pkg-perl-autopkgtest. If accepted, a MR will be done on autodep8 project to include it. >>> >>> I am not sure if you are aware, but please make sure that anything that >>> a maintainer adds about test dependencies is recorded in >>> debian/tests/control. dpkg-source exports the content of the "Depends" >>> fields to the changes file where it is picked up by britney, the >>> migration software. > > It's inspired from pkg-perl-autopkgtest package. I'll take care of this > >> Another thing, autodep8 already has support for nodejs. If your scripts >> are smarter (which they probably are), could you please replace (instead >> of add) the current nodejs support? I.e. it would be "Testsuite: >> autopkgtest-pkg-nodejs". Let's not have two nodejs supports in autodep8. > > Yes I see that and fixed this in my package > (https://salsa.debian.org/js-team/pkg-js-tools/tree/master/doc/autopkgtest#readme) > > I'll just propose an update of autopkgtest-pkg-nodejs in autodep8 > > Thanks! > Xavier I updated my package, here is the doc: https://salsa.debian.org/js-team/pkg-js-tools/tree/master/doc/autopkgtest#readme
Bug#907080: bat
Hello My collegues would like to know if this will make it into buster or not? Best,
Bug#887399: marked as done (stretch-pu: package python-certbot/0.10.2-1)
Control: reopen -1 Control: tags -1 + pending On Thu, 2019-01-24 at 22:36 +, Debian Bug Tracking System wrote: > Your message dated Thu, 24 Jan 2019 22:32:09 + > with message-id > and subject line Bug#887399: fixed in python-certbot 0.28.0-1~deb9u1 > has caused the Debian Bug report #887399, > regarding stretch-pu: package python-certbot/0.10.2-1 > to be marked as done. A package upload shouldn't close p-u bugs - that happens once the package has been included in a point release. Re-opening. Regards, Adam
Bug#916278: qemu - CVE-2018-19665: bt subsystem mishandles negative length variables
> Anyways, given that the patch is quite large (though straightforward), that
> the subsystem doesn't seem to be very actively maintained and that the user
> base is quite small, it is maybe better to mark this no-dsa in stretch and
> jessie.
... but if we manage to trim down upstream's patch to just a few lines,
it could still be worth it.
I have taken upstream's patch and got rid of all type related changes
which don't have any security related impact. In fact they don't solve
the 'negative len' issue, these changes are just equivalent to moving the
size_t cast a few instructions earlier.
These changes might make sense in a refactoring perspective but this is
just noise in our case.
The resulting patch is tiny:
diff --git a/bt-host.c b/bt-host.c
index 2f8f631c25..b73a44d07d 100644
--- a/bt-host.c
+++ b/bt-host.c
@@ -113,6 +113,7 @@ static void vhci_host_send(void *opaque,
static uint8_t buf[4096];
buf[0] = type;
+assert((size_t) len < sizeof(buf));
memcpy(buf + 1, data, len);
while (write(s->fd, buf, len + 1) < 0)
diff --git a/hw/bt/hci-csr.c b/hw/bt/hci-csr.c
index 0341ded50c..26bd516d31 100644
--- a/hw/bt/hci-csr.c
+++ b/hw/bt/hci-csr.c
@@ -320,18 +320,18 @@ static int csrhci_write(struct Chardev *chr,
struct csrhci_s *s = (struct csrhci_s *)chr;
int total = 0;
-if (!s->enable)
+if (!s->enable || len <= 0)
return 0;
for (;;) {
int cnt = MIN(len, s->in_needed - s->in_len);
-if (cnt) {
-memcpy(s->inpkt + s->in_len, buf, cnt);
-s->in_len += cnt;
-buf += cnt;
-len -= cnt;
-total += cnt;
-}
+assert(cnt > 0);
+
+memcpy(s->inpkt + s->in_len, buf, cnt);
+s->in_len += cnt;
+buf += cnt;
+len -= cnt;
+total += cnt;
if (s->in_len < s->in_needed) {
break;
3 lines changed, omitting indentation related diff. Given that this
issue might allow host side DoS/memory corruption I don't think this is
exaggerated.
The only think which is still unclear to me is why the patch is checking
using assert(). If these assert() calls are standard ansi ones, then their
failure would stop the whole qemu process which is not exactly what we
want right?
cheers,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
signature.asc
Description: PGP signature
Bug#907080: bat
Gürkan Myczko wrote on 25/01/2019: > Hello > > My collegues would like to know if this will make it into buster or not? > > Best, Hello Gürkan, I very much doubt it will, unfortunately: there are still a lot of missing dependencies to be packaged. Paride
Bug#920413: simple-scan: unable to connect to Brother 9020-CDW that worked out of the box a few weeks ago
Package: simple-scan
Version: 3.30.1.1-1+b1
Severity: normal
I used to scan documents on my Brother DCP 9020-CDW for months.
I never had to condigure anything, it did work out of the box,
flawlessly, despite this multifunctions machine is not cited
as a sane supported device. I used it over a wifi connection.
However, today the scanner cannot be found by simple-scan anymore.
I even tried to replace the wifi connection by an ethernet connection,
but nothing worked.
The printer is accessible through WIFI so there are no hardware or
network problems, I printed successfully a test document using CUPS.
Only the scanner cannot be found, despite it was instantly recognized
for the last one or two years.
-- Package-specific info:
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
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
Versions of packages simple-scan depends on:
ii dbus-user-session [default-dbus-session-bus] 1.12.12-1
ii dbus-x11 [dbus-session-bus] 1.12.12-1
ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2
ii libc6 2.28-5
ii libcairo2 1.16.0-2
ii libcolord21.4.3-4
ii libgdk-pixbuf2.0-02.38.0+dfsg-7
ii libglib2.0-0 2.58.2-3
ii libgtk-3-03.24.4-1
ii libgusb2 0.3.0-1
ii libpackagekit-glib2-181.1.12-1
ii libsane 1.0.27-3.1
ii libwebp6 0.6.1-2
ii libwebpmux3 0.6.1-2
ii xdg-utils 1.1.3-1
ii zlib1g1:1.2.11.dfsg-1
simple-scan recommends no packages.
simple-scan suggests no packages.
-- no debconf information
[+0,00s] DEBUG: simple-scan.vala:638: Starting Simple Scan 3.30.1.1, PID=29766
[+0,13s] DEBUG: app-window.vala:1715: Loading state from
/home/luc/.cache/simple-scan/state
[+0,13s] DEBUG: app-window.vala:1672: Restoring window to 1134x799 pixels
[+0,13s] DEBUG: autosave-manager.vala:64: Loading autosave information
[+0,13s] DEBUG: autosave-manager.vala:259: Waiting to autosave...
[+0,18s] DEBUG: scanner.vala:1461: sane_init () -> SANE_STATUS_GOOD
[+0,18s] DEBUG: scanner.vala:1467: SANE version 1.0.27
[+0,18s] DEBUG: scanner.vala:1528: Requesting redetection of scan devices
[+0,19s] DEBUG: scanner.vala:806: Processing request
[+0,23s] DEBUG: autosave-manager.vala:281: Autosaving book information
[+0,33s] DEBUG: app-window.vala:1776: Saving state to
/home/luc/.cache/simple-scan/state
[+0,60s] DEBUG: app-window.vala:1776: Saving state to
/home/luc/.cache/simple-scan/state
[+4,39s] DEBUG: simple-scan.vala:455: Requesting scan at 1200 dpi from device
'(null)'
[+4,39s] DEBUG: scanner.vala:1576: Scanner.scan ("(null)", dpi=1200,
scan_mode=ScanMode.GRAY, depth=2, type=ScanType.SINGLE, paper_width=0,
paper_height=0, brightness=-21, contrast=81, delay=1ms)
[+4,71s] DEBUG: app-window.vala:1776: Saving state to
/home/luc/.cache/simple-scan/state
[+5,14s] DEBUG: app-window.vala:1776: Saving state to
/home/luc/.cache/simple-scan/state
[+6,65s] DEBUG: scanner.vala:341: sane_get_devices () -> SANE_STATUS_GOOD
[+6,65s] DEBUG: scanner.vala:806: Processing request
[+6,65s] WARNING: scanner.vala:841: No scan device available
[+6,65s] DEBUG: scanner.vala:1528: Requesting redetection of scan devices
[+6,65s] DEBUG: scanner.vala:806: Processing request
[+6,75s] DEBUG: app-window.vala:1776: Saving state to
/home/luc/.cache/simple-scan/state
[+9,04s] DEBUG: app-window.vala:1776: Saving state to
/home/luc/.cache/simple-scan/state
[+11,47s] DEBUG: autosave-manager.vala:195: Deleting autosave records
[+11,47s] DEBUG: scanner.vala:1604: Stopping scan thread
[+12,92s] DEBUG: scanner.vala:341: sane_get_devices () -> SANE_STATUS_GOOD
[+12,92s] DEBUG: scanner.vala:806: Processing request
[+12,93s] DEBUG: scanner.vala:1615: sane_exit ()
[+12,93s] CRITICAL: app_window_set_scan_devices: assertion 'self != NULL' failed
No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol
Bug#920414: tahoe-lafs: Please package new upstream version 1.13.0
Source: tahoe-lafs Version: 1.12.1-5 Severity: wishlist Dear Maintainer, I've noticed that a few months ago upstream released a new version of the package: https://tahoe-lafs.org/pipermail/tahoe-dev/2018-August/009923.html I realize that there would be very little time, but do you think it would be possible to have it in debian buster before the freeze? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#914788: Please don't enable getty services for tty devices that don't exist
On Tue, Jan 22, 2019 at 07:16:43PM +, Dmitry Bogatov wrote: Hi, > > (Alternatively, the getty run scripts could start with something like this: > > > > [ -c /dev/ttyX ] || rm /etc/service/getty-ttyX > > > > and /etc/runit/1 could re-create these symlinks, just to be absolutely sure. > > > > I don't like this approach; there is too much going on automatically.) > > I believe I found quite decent solution. Take a look at `bugfix/914788' > branch. Thanks for looking into this! I believe instead of rm /etc/service/getty-@TTY@ you should do rm "$(pwd)" because then it won't matter what the service is called and where the runsvdir root is (/etc/service or somewhere else). Also, this seems redundant: #!/usr/bin/env /lib/runit/invoke-run why not just "#!/lib/runit/invoke-run"? While invoke-run, as an interpreter, is an original idea, I'd make it a scriptlet a run script can source via ". /lib/runit/invoke-run". Then it wouldn't be necessary to export all variables the configuration sets and thereby clutter the environment of the daemon. The envdir bit could be handled by a construct like if [ -z "$1" ]; then SVDIR="$(dirname $(readlink -f "$0")" if [ -e "$SVDIR/conf" ]; then exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done" fi (But then /etc/default/foo would have to take precedence over sv/foo/conf, because the /etc/default/foo variables would be lost during the exec since we want to avoid exporting them.) > Please, > > * build it (it will build runit-2.1.2-22, sorry for version havoc) > * install bin:runit > * install bin:getty-run > * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file While this would work, it doesn't improve my situation: you're making me jump through hoops to get sensible behaviour. Creating these files isn't less effort than deleting the getty services on installation, so it just adds complexity and abstraction with no real benefit. I still think the postinst modification I suggested (not installing getty services for non-existing tty devices) would be the cleanest solution. András -- No pixels were harmed in the creation of this program.
Bug#920408: mate-utils: Dependency problem
Hi Lars, On Fr 25 Jan 2019 07:58:34 CET, Lars Skovlund wrote: Package: mate-utils Version: 1.20.2-2 Severity: important Dear Maintainer, mate-utils has a hard dependency on mate-utils-common (>= 1.20.2-2), but it has not been uploaded, breaking upgrades. The latest version of mate-utils-common is 1.20.2-1 as indicated below. I have checked in Incoming, and it is not there either. Please fix. Thanks, Current mate-utils in Debian does FTBFS at the moment. Reason still not know / uninvestigated. On my list. Help welcome! Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpBKtbURVIvA.pgp Description: Digitale PGP-Signatur
Bug#915426: git breaks git-remote-hg autopkgtest
Hi Jonathan (cc Jeremy and the bugreport), Quoting Jonathan McCrohan (2019-01-25 02:02:37) > Jeremy, Jonas, > > Please accept my apologies for the tardy response on this. I've been afk > for a couple of months due to life events. > > On Wed, Jan 23, 2019 at 07:28:55PM -0500, Jeremy Bicha wrote: > > Could you please reply to Jonas' message? The deadline for > > git-remote-hg to re-enter Testing to be in this year's Debian 10 > > "Buster" release is February 12. > > > > Wed, 02 Jan 2019 13:50:54 +0100 > > > I can do yet another NMU to fix this, but am hesitating as I worry > > > if that will masquerade a lack of responsive maintenance. > > > > > > Please tell if it is sensible that I take over maintenance of this > > > package, or join as co-maintainer, or however is appreciated. > > Thanks for the previous NMU. I am happy to work on fixing up the > FTBFS, but because I am not a DD, I would need a sponsor to upload for > me. > > Given the circumstances, and the impending freeze, it might make more > sense for you to take over as maintainer if you are willing to do so. > > Let me know what you think. First of all, great to hear from you. Life is certainly more important than anything happening in Debian! I hope all is fine on that front, and if you ever need a shoulder or an ear from a stranger then please don't hesitate to grab hold of me privately. Seriously, you are welcome, day and night - my contact info is below if needed! As for package maintenance, my preference would be that I add myself as Uploader and we maintain the package in collaboration - meaning we each work on it as much as we like and find time for (don't stress!), and nudge the other when/if needing a review or an upload. Personally I find this better than sponsoring, and hope you agree. Concretely, would you like to have a go at preparing a package release now, or do you prefer that I do that? If fine with you, then I would prefer that you do as much as possible, because I have involved myself in quite a few places, now fighting for attention here close to freeze :-) I am really happy that you responded, Jonathan, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#920415: dpkg: warning: version 'p.ci' has bad syntax: version number does not start with digit
Package: mariadb-server-10.3 Version: 1:10.3.12-2 Severity: normal Dear Maintainer, Not sure where p.ci comes from.. Setting up mariadb-common (1:10.3.12-2) ... (Reading database ... 85393 files and directories currently installed.) Preparing to unpack .../0-mariadb-server-10.3_1%3a10.3.12-2_amd64.deb ... /var/lib/mysql: found previous version 10.3 dpkg: warning: version 'p.ci' has bad syntax: version number does not start with digit Unpacking mariadb-server-10.3 (1:10.3.12-2) over (1:10.3.12-1) ... Greetings, Olaf -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server-10.3 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.70 ii galera-3 25.3.25-1 ii gawk 1:4.2.1+dfsg-1 ii iproute2 4.20.0-2 ii libc6 2.28-5 ii libdbi-perl 1.642-1+b1 ii libpam0g 1.1.8-4 ii libssl1.1 1.1.1a-1 ii libstdc++68.2.0-14 ii lsb-base 10.2018112800 ii lsof 4.91+dfsg-1 ii mariadb-client-10.3 1:10.3.12-2 ii mariadb-common1:10.3.12-2 ii mariadb-server-core-10.3 1:10.3.12-2 ii passwd1:4.5-1.1 ii perl 5.28.1-3 ii psmisc23.2-1 ii rsync 3.1.3-2 ii socat 1.7.3.2-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages mariadb-server-10.3 recommends: ii libhtml-template-perl 2.97-1 Versions of packages mariadb-server-10.3 suggests: ii mailutils [mailx] 1:3.5-2 pn mariadb-test pn netcat-openbsd pn tinyca -- debconf information: mysql-server/password_mismatch: mariadb-server-10.3/postrm_remove_databases: false mariadb-server-10.3/nis_warning: mysql-server/error_setting_password: mariadb-server-10.3/old_data_directory_saved:
Bug#920366: developers-reference: ftbfs in sid, builds fine in stable
On Thu, Jan 24, 2019 at 08:09:39PM +0100, Holger Levsen wrote: > Interestingly 3.4.21 build fine in unstable on arm64 only two days ago (see > https://tests.reproducible-builds.org/debian/history/developers-reference.html > ) > > Matching this, builds of 3.4.21 still build fine today. (also see that > last URL.) The failure is most probably due to src:texlive-base. texlive-base/2018.20190122-1 entered unstable a few days ago, replacing 2018.20181214-1 Wolfgang signature.asc Description: PGP signature
Bug#920421: ITP: icingaweb2-module-boxydash -- dashboard showing the overall view of your icinga2
Package: wnpp Owner: david.k...@dknet.ch * Package name: icingaweb2-module-boxydash Upstream Author : Jesse Morgan * License : GPL-2 Description : dashboard showing the overall view of your icinga (icingaweb2 extension) Icinga Web 2 is a very modular, fast and simple web interface for your Icinga monitoring environment. . Boxydash provides dashboard showing the overall view of your icinga instance. Greetings, David
Bug#920416: apt-key freezes.
Package: apt Version: 1.4.9 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-7-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-8-amd64$"; APT::NeverAutoRemove:: "^postgresql-"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Periodic ""; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::Unattended-Upgrade "1"; APT::Periodic::Update-Package-Lists "1"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Co
Bug#920422: ITP: icingaweb2-module-director -- Icinga Director is a web based configuration tool
Package: wnpp Owner: david.k...@dknet.ch * Package name: icingaweb2-module-director Upstream Author : Icinga Development Team * License : GPL-2+ Description : web based configuration tool for your icinga (icingaweb2 extension) Icinga Web 2 is a very modular, fast and simple web interface for your Icinga monitoring environment. . Icinga Director is a configuration tool that has been designed to make Icinga 2 configuration easy and understandable. Greetings, David
Bug#182173: lft: doesn't handle machine with multiple interfaces correctly
hi russel your bug report was against 2.0, however there's 2.2 and 3.8 which both support -D: -Dnetwork device (name or IP address) to use (e.g., "en1") can you try if that's fixing your problem? best,
Bug#920417: ITP: icingaweb2-module-statusmap -- a very basic status map for Icingaweb2
Package: wnpp Owner: david.k...@dknet.ch * Package name: icingaweb2-module-statusmap Upstream Author : Sebastian Brückner * License : GPL-2 Description : a very basic status map for Icingaweb2 (icingaweb2 extension) Icinga Web 2 is a very modular, fast and simple web interface for your Icinga monitoring environment. . This module adds a very basic status map for Icingaweb 2. Greetings, David
Bug#920418: ITP: icingaweb2-module-businessprocess -- web-based process modeler
Package: wnpp Owner: david.k...@dknet.ch * Package name: icingaweb2-module-businessprocess Upstream Author : Icinga Development Team * License : GPL-2 Description : web-based process modeler of your icinga (icingaweb2 extension) Icinga Web 2 is a very modular, fast and simple web interface for your Icinga monitoring environment. . Business Process viewer and modeler provides a web-based process modeler. Greetings, David
Bug#920420: ITP: icingaweb2-module-graphite -- adds graphite graphs to the web interface
Package: wnpp Owner: david.k...@dknet.ch * Package name: icingaweb2-module-graphite Upstream Author : Icinga Development Team * License : GPL-2+ Description : adds graphite graphs to the web interface (icingaweb2 extension) Icinga Web 2 is a very modular, fast and simple web interface for your Icinga monitoring environment. . This module adds graphite graphs to the web interface. Greetings, David
Bug#920419: ITP: icingaweb2-module-generictts -- link issue/ticket numbers in your Icinga
Package: wnpp Owner: david.k...@dknet.ch * Package name: icingaweb2-module-generictts Upstream Author : Icinga Development Team * License : GPL-2+ Description : ink issue/ticket numbers in your icinga (icingaweb2 extension) Icinga Web 2 is a very modular, fast and simple web interface for your Icinga monitoring environment. . This module allows to easily link issue/ticket numbers in your Icinga acknowledgement or downtime comments. Greetings, David
Bug#920423: sogo: Exception thrown on "rich" email view after 4.0.5 upgrade (from 3.2.6)
Package: sogo Version: 4.0.5-2 Severity: grave Justification: renders package unusable Dear Maintainer, I’ve just upgraded (and due to reasons entirely my fault, I’ve realised I have no downgrade path… backup fail) from 3.2.6 (I believe it was) to 4.0.5. It’s a Debian box, using the “official Debian sogo packages” - I’m now running on Debian Buster (due for release later this year). Everything is working a charm - upgrading the database appears to have worked perfectly - all except the “/view” URL used by the AJAX UI for retrieving a “rich” email from a folder... (So by extension, I simply cannot view emails in the SOGo webmail client.) Works using “viewsource” (as in, the SOGo 'viewsource' button works - which makes sense because I can see the IMAP debug is working properly on the backend), and the headers download properly etc. I’m seeing an exception thrown in the logs: Jan 24 22:41:11 sogod [2864]: <0x0x560efac4c220[NGImap4Client]> TLS started successfully. Jan 24 22:41:11 sogod [2864]: 10.0.90.34, 10.0.20.10, 10.0.20.11 "GET /SOGo/so/matthewhall/Mail/0/folderINBOX/64252/viewsource HTTP/1.1" 200 1584/0 0.549 4041 60% 0 (worked) Jan 24 22:41:11 sogod [2864]: <0x0x560efac4cae0[NGImap4Client]> TLS started successfully. 2019-01-24 22:41:12.503 sogod[2864:2864] EXCEPTION: NAME:NSInvalidArgumentException REASON:[NSString+stringWithString:]: NULL string INFO:(null) Jan 24 22:41:12 sogod [2864]: 10.0.90.34, 10.0.20.10, 10.0.20.11 "GET /SOGo/so/matthewhall/Mail/0/folderINBOX/64252/view HTTP/1.1" 501 0/0 0.550 - - 0 (failed) (Note it’s a “GET” request and not a “POST” because I’m reproducing it manually, not via the AJAX UI in this example.) I’ve tried with all the debugging enabled in sogo.conf and I don’t see anything unusual: IMAP works perfectly, then sogod throws the exception above. Any ideas? I’ve exhausted all my own - and I can’t see that it’s a known bug (I've also reached out to the SOGo user's mailing list on the off-chance). I’ve by-hand confirmed the database structure looks correct for a 4.0.5, but I may have overlooked something. I briefly tried it against a fresh database too, and that behaved the same (again, unless I was overlooking something silly). I cannot rule out the possibility of user error on my behalf - but I'm 90% confident it's an issue in the 4.0.5-2 package. (I've not been able to try other 4.0.x debian packages - but can do so if they are available.) No other obvious issues like missing packages etc. Very happy to provide any other information like database schemas etc if that would help. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sogo depends on: ii adduser 3.118 ii gnustep-base-runtime 1.26.0-2 ii libc6 2.28-5 ii libcurl3-gnutls 7.63.0-1 ii libgcc1 1:8.2.0-14 ii libglib2.0-0 2.58.2-3 ii libgnustep-base1.26 1.26.0-2 ii libgnutls30 3.6.5-2 ii liblasso3 2.6.0-2+b2 ii libmemcached111.0.18-4.2 ii libobjc4 8.2.0-14 ii libsbjson2.3 2.3.2-4+b1 ii libsope1 4.0.5-2 ii lsb-base 10.2018112800 ii memcached 1.5.6-1 ii sogo-common 4.0.5-2 ii systemd 240-4 ii zip 3.0-11+b1 sogo recommends no packages. Versions of packages sogo suggests: pn postgresql | default-mysql-server | virtual-mysql-server -- Configuration Files: /etc/cron.d/sogo changed: * * * * * sogo /usr/sbin/sogo-ealarms-notify > /dev/null 2>&1 /etc/default/sogo changed: PREFORK=10 /etc/sogo/sogo.conf [Errno 13] Permission denied: '/etc/sogo/sogo.conf' -- no debconf information
Bug#920424: ITP: python-flor -- efficient Bloom filter library
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-flor Version : 1.1.1 Upstream Author : Andreas Dewes * URL : https://github.com/DCSO/flor/ * License : BSD_3-clause Programming Lang: Python Description : efficient Bloom filter library Flor implements a Bloom filter class. A Bloom filter has a capacity (n) and a false positive probability (p) that gives the probability that a filter filled to capacity (i.e. with (n) distinct values inserted) will return True for an element that is not in the filter. I do plan to maintain this package as part of the DPMT. -BEGIN PGP SIGNATURE- iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlxK41ARHGZsYWRpQGRl Ymlhbi5vcmcACgkQ/9PIi5l90Wpa0AgAhpMIxNG3TaCj28HWnSYFaO6abJnzGzfm FV6QXnSxAql/+roFYP2D8VpZx5UfJt/Kn+GTtflYDNO//Cjfr5Xi+iLPzhVwLV4n a4TIXL8VHqel4oiFj3D7ejf7Iwx3RmisAD9pWgXr4+CJ/P5JVNP1tpQo3w66nzeq 41Hod83h6PROYLUHDDXPpycpiEOw8WJDn5iKt7IQ7vyyoq/bJYjCqJ3eL5UREWt1 y1c1IXYdpWDIL6drotDTavc8YAvC95iv28HVgpjH+VfVQr1yj6sI/Fw5YZed4wjg tke+1bYjHvO672Y4x9UB/b/A9+vKYC98yylOVldrYh7XoP2GdJ9f6Q== =BJLr -END PGP SIGNATURE-
Bug#920425: oakleaf has missing dependencies for the autopkg test
Package: src:oakleaf Version: 0.0.1-1 Severity: important Tags: sid buster oakleaf has missing dependencies for the autopkg test. etting up autopkgtest-satdep (0) ... Processing triggers for libc-bin (2.28-0ubuntu1) ... (Reading database ... 62146 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [00:49:51]: test command1: autoreconf -i -f && ./configure && make check autopkgtest [00:49:51]: test command1: [--- bash: autoreconf: command not found autopkgtest [00:49:52]: test command1: ---]
Bug#920426: munipack ftbfs with ld --as-needed as the default
Package: src:munipack Version: 0.5.11-1 Severity: important Tags: sid buster munipack ftbfs with ld --as-needed as the default patch at http://launchpadlibrarian.net/408186213/munipack_0.5.11-1_0.5.11-1ubuntu1.diff.gz
Bug#920398: RM: twill -- ROM; abandoned upstream
On Fri, 25 Jan 2019 14:05:40 +0900 Arnaud Fontaine wrote: > Package: ftp.debian.org > Severity: normal > > I no longer use nor have time to take care of the package but for the > following reasons I'm requesting its removal rather than orphaning it: > > * There has been no upstream release for 5 years. > * Upstream website is no longer available. > * It ships a (very old) modified copy of Python mechanize module. > * Popcon is very low. There are, however, users in the archive: Checking reverse dependencies... # Broken Build-Depends: flask-testing: python-twill trac: python-twill trac-xmlrpc: python-twill Dependency problem found. Please ask them to drop the build-depends and remove the moreinfo tag once that is done. Scott K
Bug#910295: blocked by 'python3-httpretty' bug#919599
Control: block -1 by 919599 On 18-Jan-2019, Ben Finney wrote: > The HTTPretty library is failing to correctly mock requests sent > using the standard-library `http.client.HTTPConnection` class. I have reported bug#919599 for this. (I believe that bug is already fixed in Debian now.) -- \ “Try to become not a man of success, but try rather to become a | `\ man of value.” —Albert Einstein | _o__) | Ben Finney
Bug#920415: [debian-mysql] Bug#920415: dpkg: warning: version 'p.ci' has bad syntax: version number does not start with digit
Op vr 25 jan. 2019 om 11:24 schreef Robie Basak :
>
> On Fri, Jan 25, 2019 at 11:04:28AM +0100, Olaf van der Spek wrote:
> > Not sure where p.ci comes from..
> >
> > Setting up mariadb-common (1:10.3.12-2) ...
> > (Reading database ... 85393 files and directories currently installed.)
> > Preparing to unpack .../0-mariadb-server-10.3_1%3a10.3.12-2_amd64.deb ...
> > /var/lib/mysql: found previous version 10.3
> > dpkg: warning: version 'p.ci' has bad syntax: version number does not start
> > with digit
> > Unpacking mariadb-server-10.3 (1:10.3.12-2) over (1:10.3.12-1) ...
>
> A call to "dpkg --compare-versions" perhaps?
Bingo:
https://salsa.debian.org/mariadb-team/mariadb-10.3/blob/master/debian/mariadb-server-10.3.preinst
# Automatically set version to ease maintenance of this file.
# Assume the filename is /path/to/mariadb-server-##.#.preinst
# Pick version string based on location. Python equivalent would be x[-12:-8].
VERSION=${0: -12:4}
This look hacky. Could this assumption be false?
$ ls -l debian-*.flag
-rw-r--r-- 1 root root 0 Jan 25 10:09 debian-10.3.flag
--
Olaf
Bug#920427: tzdata: [INTL:nl] Dutch translation of debconf messages
Package: tzdata Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of tzdata debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#920415: [debian-mysql] Bug#920415: dpkg: warning: version 'p.ci' has bad syntax: version number does not start with digit
> Not sure where p.ci comes from.. Funny. No results from source package with '$ grep -rF p.ci *'. And steps to reproduce is simply 'apt install mariadb-server-10.3' ? I cannot reproduce that on any of my test systems. Naturally also CI tested that and other install/upgrade scenarios and all passed: https://salsa.debian.org/mariadb-team/mariadb-10.3/pipelines/33527
Bug#904747: geotranz 3.7
Hi Roberto, I've given it a try to update, here: http://phd-sid.ethz.ch/debian/geotranz/ It builds. It opens up a window. Probably needs adjustments in debian/patches, what do you think? Cheers,
Bug#920428: minissdpd: [INTL:nl] Dutch translation of debconf messages
Package: minissdpd Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of minissdpd debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#920429: powerline: [INTL:nl] Dutch translation of debconf messages
Package: powerline Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of powerline debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#920430: nova: [INTL:nl] Dutch translation of debconf messages
Package: nova Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of nova debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#896070: gitlint FTBFS: FAIL: test_target
This issues is raised upstream as https://github.com/jorisroovers/gitlint/issues/78 and looks like it might be fixed in more recent versions. It would good to update gitlint to 0.10.0 from the current 0.9.0 and see if this fixes the issue, and then migrate from Debian Unstable to Testing.
Bug#920431: miniupnpd: [INTL:nl] Dutch translation of debconf messages
Package: miniupnpd Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of miniupnpd debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#920415: [debian-mysql] Bug#920415: Bug#920415: dpkg: warning: version 'p.ci' has bad syntax: version number does not start with digit
> Bingo:
> https://salsa.debian.org/mariadb-team/mariadb-10.3/blob/master/debian/mariadb-server-10.3.preinst
>
> # Automatically set version to ease maintenance of this file.
> # Assume the filename is /path/to/mariadb-server-##.#.preinst
> # Pick version string based on location. Python equivalent would be x[-12:-8].
> VERSION=${0: -12:4}
>
> This look hacky. Could this assumption be false?
>
> $ ls -l debian-*.flag
> -rw-r--r-- 1 root root 0 Jan 25 10:09 debian-10.3.flag
Seems to be a mistake made in
https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/6b1f48b3fafa1f1c732d313fea20b8c035c7b776
Bug#920340: 1.9 shows the same problem
The from #919972 shows the same problem after upgrading to 1.9 Subject: [package on hold] unattended-upgrades result for : SUCCESS Unattended upgrade result: All upgrades installed Packages with upgradable origin but kept back: libcurl4 As I said in #919972 1.9 shows correct message "Packages with upgradable origin but kept back", but subject is wrong: "[package on hold]" -- sergio.
Bug#920414: tahoe-lafs: Please package new upstream version 1.13.0
Hi, New version needs magic-wormhole lib in py2 but currently it's py3 package. I filed a bug but maintainer said he won't be able to do it. If some one can package python-magic-wormhole then I can package new version. Thanks and Regards On 25 January 2019 2:51:30 PM IST, Elena ``of Valhalla'' wrote: >Source: tahoe-lafs >Version: 1.12.1-5 >Severity: wishlist > >Dear Maintainer, > >I've noticed that a few months ago upstream released a new version of >the package: > >https://tahoe-lafs.org/pipermail/tahoe-dev/2018-August/009923.html > >I realize that there would be very little time, but do you think it >would be possible to have it in debian buster before the freeze? > >-- System Information: >Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') >Architecture: amd64 (x86_64) > >Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores) >Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), >LANGUAGE=en_IE:en (charmap=UTF-8) >Shell: /bin/sh linked to /bin/dash >Init: systemd (via /run/systemd/system) >LSM: AppArmor: enabled -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#894285: some progress
Am 24.01.19 um 23:51 schrieb Hans-Christoph Steiner: > > I can get some of this compiling with openjdk-11, but not all. > > Ok, here's a fun problem: looks like I can build android-platform-23 > with java11, but since it is in effect building Java core classes, the > compiler freaks. > > There seems to be something like --patch-module java.base=src to deal > with this > but that won't work with sourceCompatibility 1.8 > and Android wasn't Java9 until the most most recent release (9.0.0) > so... anyone have some ideas for alternate approaches? > > here's a build log > https://salsa.debian.org/android-tools-team/android-framework-23/-/jobs/114477 I believe the only chance to save this package in time for Buster is to use OpenJDK 8. I don't think you can fix the build failure without using a higher sourceCompatibility level. signature.asc Description: OpenPGP digital signature
Bug#920432: rhnlib: keep out of buster
Source: rhnlib Severity: serious If nobody complains, I'll file a RoM removal bug soon. So lets keep it out of Buster for now. -- Debian New Maintainer Frontdesk Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#920433: RFS: wiggle/1.1-1 [QA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wiggle" * Package name: wiggle Version : 1.1-1 Upstream Author : Neil Brown * URL : https://neil.brown.name/wiggle * License : GPL-2+ Section : vcs It builds this binary package: wiggle - apply patches with conflicting changes To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wiggle Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wiggle/wiggle_1.1-1.dsc I have also temporarily pushed my changes to https://salsa.debian.org/e7appew-guest/wiggle, which I'd like to move to https://salsa.debian.org/debian/wiggle, should my changes be accepted. Changes since the last upload: * QA upload. * Set Maintainer to Debian QA Group. (See: #920082) * New upstream release [1.1]. * Update B-D: libncurses5-dev -> libncurses-dev. * Build with Debhelper compat level 12. * Update VCS details. * Set "Rules-Requires-Root: no". * Perform wrap-and-sort on Debian source files. * Update upstream URLs. * Suppress debian-watch-does-not-check-gpg-signature lintian warning. * Add machine-readable upstream metadata. * Build verbosely and with LFS support. * Update debian/copyright. * Add typos.patch to fix some typos. * Add debian/gbp.conf. * Add gcc8-format-security.patch to fix format overflow and truncation warnings. * Relax pedantic GCC warnings, as well as warnings about unused result. * Indicate compliance with Debian Policy 4.3.0. * Indicate that the package enhances git. Regards, Carlos Maddela
Bug#920353: debian-installer configuration on alpha
On 1/24/19 4:53 PM, John Paul Adrian Glaubitz wrote: > I just never bothered tracking down the problem since I just used the standard > installer. If your particular changes makes the installer work on Debian Ports > architectures in expert mode, I am happy to commit the change for all ports > architectures. I have committed the changes for all architectures in Debian Ports: > https://salsa.debian.org/installer-team/debian-installer/commit/c36cade1787ebe8cf4438dce7227cac20c887d32 > https://salsa.debian.org/installer-team/debian-installer/commit/8c9f81fc412abcef3a8a6fa11d0a7ed2dfd26ff4 Thanks for spotting this! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#920341: RFS: pentobi/16.2-1
On Thu, 24 Jan 2019 14:27:56 +0100 Adam Borowski wrote: > [~/tmp/pkg]$ debdiff pentobi-kde-thumbnailer_16.2-1_amd64.deb > pentobi-kde-thumbnailer_16.2-1_ppc64el.deb > This means the package is perfect, right? Yeah, looks good. I did verify the alternative code path on my machine by making a non-webview build for amd64 and then using the Help menu option. > Uploaded. Thank you! -- Juhani
Bug#891957: netbeans no starting "loading module" modules.netbinox NullPointerException
Control: reassign -1 libequinox-osgi-java Control: found -1 3.9.1-1 This issue is actually caused by missing files in libequionx-osgi-java. The sources from Maven did neither contain the *.profile nor .properties files which caused a NullPointerException in Netbeans and made the program unusable. I have added those files now which will resolve this bug. Markus signature.asc Description: OpenPGP digital signature
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Fri, Jan 25, 2019 at 4:35 PM Alexander Larsson wrote: > > On Fri, Jan 25, 2019 at 5:07 AM Akira TAGOH wrote: > > > > > > > > > > as-path=... ? > > > > That sounds good to me. > > This sounds good to me to. I updated the PR: > https://github.com/flatpak/flatpak/pull/2635#issuecomment-457482239 > > Can I get an ack on this format? Sure. I started to implement it based on Keith's branch. -- Akira TAGOH
Bug#920434: ping does not round correctly
Package: iputils-ping
Version: 3:20180629-2
Usually, ping reports times like 17.1 ms, but every once in a while it
reports a trip time of, say, 17.10 ms. I expect to always get 3
significant digits, not sometimes 4. Here is a transcript:
$ ping 1.1.1.1
(...)
64 bytes from 1.1.1.1: icmp_seq=5318 ttl=53 time=16.4 ms
64 bytes from 1.1.1.1: icmp_seq=5319 ttl=53 time=17.1 ms
64 bytes from 1.1.1.1: icmp_seq=5320 ttl=53 time=13.8 ms
64 bytes from 1.1.1.1: icmp_seq=5321 ttl=53 time=17.10 ms
64 bytes from 1.1.1.1: icmp_seq=5322 ttl=53 time=13.9 ms
(...)
I traced this back to function gather_statistics in file ping_common.c.
The current rounding is in these lines:
$ grep -n 'triptime >= 1)' -B 3 -A 9 ping_common.c
855-if (timing) {
856-if (triptime >= 10)
857-printf(" time=%ld ms", (triptime+500)/1000);
858:else if (triptime >= 1)
859-printf(" time=%ld.%01ld ms", triptime/1000,
860- ((triptime%1000)+50)/100);
861-else if (triptime >= 1000)
862-printf(" time=%ld.%02ld ms", triptime/1000,
863- ((triptime%1000)+5)/10);
864-else
865-printf(" time=%ld.%03ld ms", triptime/1000,
866- triptime%1000);
867-}
The bug happens for example with triptime = 17981:
triptime/1000 = 17981/1000
= 17 (seconds)
(triptime%1000)+50)/100 = (17981%1000)+50)/100
= ( 981 +50)/100
= 1031 /100
= 10 (tenths of a second)
So, while 17981 ms should have been converted to 18.0 seconds, it is
converted to 17.10 seconds.
One way of fixing it:
if (timing) {
if (triptime >= 10 - 50)
printf(" time=%ld ms", (triptime+500)/1000);
else if (triptime >= 1 - 5)
printf(" time=%ld.%01ld ms", (triptime+50)/1000,
((triptime+50)%1000)/100);
else if (triptime >= 1000)
printf(" time=%ld.%02ld ms", (triptime+5)/1000,
((triptime+5)%1000)/10);
else
printf(" time=%ld.%03ld ms", triptime/1000,
triptime%1000);
}
I fixed the triptime thresholds so the output is consistent, added the
+50/+5 to the whole milliseconds so it gets rounded as well, and moved
the +50/+5 of the fractional milliseconds to the correct place.
The code is far less readable, so may I suggest that you consider
rewriting the code so it is better maintainable than my suggested fix?
signature.asc
Description: PGP signature
Bug#920415: [debian-mysql] Bug#920415: dpkg: warning: version 'p.ci' has bad syntax: version number does not start with digit
Op vr 25 jan. 2019 om 12:07 schreef Otto Kekäläinen : > > > Not sure where p.ci comes from.. > > Funny. No results from source package with '$ grep -rF p.ci *'. > > And steps to reproduce is simply 'apt install mariadb-server-10.3' ? Probably not. I ran `apt upgrade` -- Olaf
Bug#894285: some progress
> I believe the only chance to save this package in time for Buster is to use > OpenJDK 8. That seems to be a reasonable choice. Right now Android apps are simply not supposed to use Java 9+. But for how long will JDK8 be supported in Debian? I don't want this package be a burden of any future transition. signature.asc Description: OpenPGP digital signature
Bug#920435: ITP: mender-cli -- A general-purpose CLI for the Mender backend
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: mender-cli Version : 1.1.0-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mender-cli * License : Apache-2.0 Programming Lang: Go Description : A general-purpose CLI for the Mender backend Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . This package contains a standalone tool that makes it much easier to work with the Mender server management APIs (https://docs.mender.io/apis/management-apis). . The goal with mender-cli is to simplify integration between the Mender server and cloud services like continuous integration (CI)/build automation.
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Akira TAGOH writes: > Sure. I started to implement it based on Keith's branch. Awesome. I'll be back home "tomorrow" and able to spend some time on this next week. -- -keith signature.asc Description: PGP signature
Bug#894285: some progress
Am 25.01.19 um 13:23 schrieb seam...@debian.org: >> I believe the only chance to save this package in time for Buster is to use >> OpenJDK 8. > > That seems to be a reasonable choice. Right now Android apps are simply not > supposed to use Java 9+. > > But for how long will JDK8 be supported in Debian? I don't want this package > be a burden of any future transition. Actually we wanted to get rid of OpenJDK 8 in Buster. It is still officially supported upstream, at least until 2020, maybe even longer. However security support for two runtimes is time consuming and there is no appetite from the security team for that. However I think they can be persuaded to accept that OpenJDK 8 is only used at build time as long as the applications work with OpenJDK 11 at runtime. You could also declare certain packages as unsupported at runtime because they are only used for development purposes. signature.asc Description: OpenPGP digital signature
Bug#919859: [src:linux] Problem persists on 4.19.16 (package linux-image-4.19.0-2-amd64)
I upgraded to 4.19.16 (package linux-image-4.19.0-2-amd64 from unstable) and wol is still not working.
Bug#895472: ocaml: CVE-2018-9838
Le 21/01/2019 à 22:33, Moritz Mühlenhoff a écrit : >> The following vulnerability was published for ocaml. >> >> CVE-2018-9838[0]: >> | The caml_ba_deserialize function in byterun/bigarray.c in the standard >> | library in OCaml 4.06.0 has an integer overflow which, in situations >> | where marshalled data is accepted from an untrusted source, allows >> | remote attackers to cause a denial of service (memory corruption) or >> | possibly execute arbitrary code via a crafted object. > > What's the status? There hasn't been an upload for src:ocaml over all > of 2018? Indeed. I will upload a fix. Cheers, -- Stéphane
Bug#920436: packages.debian.org could use vcs edit information from vcswatch
Package: www.debian.org Severity: wishlist vcswatch allows users with a certificate from sso.debian.org to edit the Vcs-* information of packages. packages.d.o (and possibly other systems like tracker) could use that when showing Vcs links. Let me know if you like the idea an then I can provide a .json dump of the changed packages from vcswatch. Christoph
Bug#920055: ITA some of Jari Aalto's packages
package wnpp
retitle 920121 ITA: xonix -- game to carve up the screen whilst dodging monsters
owner 920121 !
retitle 920110 ITA: tardy -- post-processor for tar command
owner 920110 !
retitle 920076 ITA: dnstracer -- trace DNS queries to the source
owner 920076 !
retitle 920060 ITA: corkscrew -- tunnel TCP connections through HTTP proxies
owner 920060 !
retitle 920055 ITA: bbe -- sed-like editor for binary files
owner 920055 !
thanks
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#765335: ITA libexplain
package wnpp
retitle 765335 ITA: libexplain -- utility to explain system call errors
owner 765335 !
thanks
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#920263: really not workable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... -BEGIN PGP SIGNATURE- iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCXEsL9wAKCRDn6sEfJS3n C2yVAKC3gSKX4TsbxLFHoh58CGLVKRoc2QCgg99RU9lPpjpxT3IlNkDyq5hb2j8= =OJMt -END PGP SIGNATURE- build-linul-asrv-bpo-2.txt.xz Description: application/xz
Bug#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices
Package: wnpp Severity: wishlist Owner: Hanno Stock * Package name: displaylink Version : 4.4 Upstream Author : DisplayLink (UK) Ltd. * URL : https://www.displaylink.com/downloads * License : proprietary Programming Lang: binary Description : Proprietary driver for DisplayLink devices This is the proprietary binary component of the driver for DisplayLink devices. It communicates via libusb with the DisplayLink device and uses the opensource evdi kernel module for presenting a virtual graphics device to the system. - DisplayLink devices are for example USB based docking stations and USB-attachable secondary screens. Unfortunately newer DisplayLink devices are not supported by libdlo, an open source driver for older DisplayLink devices. However DisplayLink provides an Ubuntu installer for their newer drivers and allows repackaging the binary components for other distributions. According to a DisplayLink employee: "The text of the license was written to ensure the driver can be repacked by other distros and redistribute. As long as the text of license file is replicated, and binaries are redistributed as provided in the .run package (unmodified), and it is still possible to identify what component is what and where it came from, the license terms are met IMO." [1] In order for Debian to support DisplayLink devices it would make sense to package this driver for the non-free component. [1] https://www.displaylink.org/forum/showthread.php?t=64854&highlight=license
Bug#916642: golang CVE-2019-6486 (DoS in crypto/elliptic)
On Thu, Jan 24, 2019 at 03:00:22PM +0100, Dr. Tobias Quathamer wrote: > Am 24.01.2019 um 09:12 schrieb Emilio Pozuelo Monfort: > > On 24/01/2019 08:58, Michael Stapelberg wrote: > >> Last time, pochu@ (cc'ed) helpfully scheduled binNMUs. pochu, would you be > >> able to help this time, too? > > > > Sure. Can you give me a list of source packages to binNMU in unstable? If > > this > > is public already, can you do that through a binNMU bug against > > release.debian.org? > > > > Emilio > > Hi all, > > there is already an outdated binNMU list as bug report available, so > I'm reusing that report. Please ignore the previously attached > binNMU list of that bug report. > > This should be a complete and current list of needed binNMUs: > > > [‥] > nmu serf_0.8.1+git20180508.80ab4877~ds-1 . ANY . -m 'Rebuild with current > golang-1.11 (CVE-2019-6486)' This is a (common) mistake. src:serf does not use golang. src:golang-github-hashicorp-serf is the golang package, which producees bin:serf, however I just saw that src:serf was binNMUed. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit
Great, thank you for taking care of this! On Fri, Jan 25, 2019 at 2:32 PM Mariusz Gronczewski wrote: > Okay, I will just poke the upstream about it, seems that CentOS/RHEL > package have exactly same problem so no point changing it just for > Debian. > > > On Thu, 24 Jan 2019 at 18:27, Michael Stapelberg > wrote: > > > > Ah, why didn’t you open with that suggestion? :) > > > > > https://manpages.debian.org/stretch/systemd/systemd.service.5.en.html#OPTIONS > outlines that switching to Type=simple (which is the consequence of your -f > suggestion) means we won’t have start-up failure propagation anymore, and > reverse-dependencies of freeradius will not be able to reliably sequence > themselves. > > > > Now, I’m not sure whether these downsides are actually relevant in > practice, as I don’t know much about the larger freeradius ecosystem. Maybe > there are no communication channels, and no reverse dependencies of note? > I’m not sure. > > > > If you could confirm with upstream that they are blessing use of -f and > Type=simple as the default in Debian, I can make the change. > > > > Thanks, > > > > On Thu, Jan 24, 2019 at 4:49 PM Mariusz Gronczewski > wrote: > >> > >> Well, there is, adding -f option by default means it will always run > >> in foreground, regardless of whether -X is used or not > >> > >> On Thu, 24 Jan 2019 at 15:58, Michael Stapelberg > wrote: > >> > > >> > The -X option is special in that it changes the way freeradius starts > up. > >> > > >> > It’s expected that if your actions break the contract with the init > system (in this case by specifying -X), you’re responsible to rectify that. > >> > > >> > If there was a simple way to make the package work in any/all cases, > it’d be up for it, but I’m not aware of one. Hence my question for what > your suggestion is — I just don’t see a way out of this situation. > >> > > >> > My personal recommendation is to not use /etc/default, but rather > systemctl edit to do any overrides, but that’s not Debian’s official line. > >> > > >> > On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski < > xani...@gmail.com> wrote: > >> >> > >> >> In our case it was enough to add dropin changing execstart to include > >> >> -f and type to simple: > >> >> > >> >> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS > >> >> Type=simple > >> >> > >> >> What do you mean by "it is expected" ? Currently enabling debug (by > >> >> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop, > >> >> surely that isn't an expected behaviour ? > >> >> > >> >> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg < > stapelb...@debian.org> wrote: > >> >> > > >> >> > Yes, this is expected. What change are you suggesting? > >> >> > > >> >> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski < > xani...@gmail.com> wrote: > >> >> >> > >> >> >> Package: freeradius > >> >> >> Version: 3.0.12+dfsg-5+deb9u1 > >> >> >> Severity: normal > >> >> >> > >> >> >> Currently the type of systemd service is forking. > >> >> >> > >> >> >> Adding debug to cmdline causes freeradius to run in foreground > (and dump debug > >> >> >> to stdout), which means systemd timeouts on starting service > because it assumes > >> >> >> it will fork. > >> >> >> > >> >> >> Changing type to simple, and adding -f (run in foreground) option > in unit file > >> >> >> fixes that > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> Mariusz Gronczewski (XANi) > >> >> >> GnuPG: 0xEA8ACE64 > >> >> >> > >> >> >> ___ > >> >> >> Pkg-freeradius-maintainers mailing list > >> >> >> pkg-freeradius-maintain...@alioth-lists.debian.net > >> >> >> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Best regards, > >> >> > Michael > >> >> > >> >> > >> >> > >> >> -- > >> >> Mariusz Gronczewski (XANi) > >> >> GnuPG: 0xEA8ACE64 > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > Michael > >> > >> > >> > >> -- > >> Mariusz Gronczewski (XANi) > >> GnuPG: 0xEA8ACE64 > > > > > > > > -- > > Best regards, > > Michael > > > > -- > Mariusz Gronczewski (XANi) > GnuPG: 0xEA8ACE64 > -- Best regards, Michael
Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit
Okay, I will just poke the upstream about it, seems that CentOS/RHEL package have exactly same problem so no point changing it just for Debian. On Thu, 24 Jan 2019 at 18:27, Michael Stapelberg wrote: > > Ah, why didn’t you open with that suggestion? :) > > https://manpages.debian.org/stretch/systemd/systemd.service.5.en.html#OPTIONS > outlines that switching to Type=simple (which is the consequence of your -f > suggestion) means we won’t have start-up failure propagation anymore, and > reverse-dependencies of freeradius will not be able to reliably sequence > themselves. > > Now, I’m not sure whether these downsides are actually relevant in practice, > as I don’t know much about the larger freeradius ecosystem. Maybe there are > no communication channels, and no reverse dependencies of note? I’m not sure. > > If you could confirm with upstream that they are blessing use of -f and > Type=simple as the default in Debian, I can make the change. > > Thanks, > > On Thu, Jan 24, 2019 at 4:49 PM Mariusz Gronczewski wrote: >> >> Well, there is, adding -f option by default means it will always run >> in foreground, regardless of whether -X is used or not >> >> On Thu, 24 Jan 2019 at 15:58, Michael Stapelberg >> wrote: >> > >> > The -X option is special in that it changes the way freeradius starts up. >> > >> > It’s expected that if your actions break the contract with the init system >> > (in this case by specifying -X), you’re responsible to rectify that. >> > >> > If there was a simple way to make the package work in any/all cases, it’d >> > be up for it, but I’m not aware of one. Hence my question for what your >> > suggestion is — I just don’t see a way out of this situation. >> > >> > My personal recommendation is to not use /etc/default, but rather >> > systemctl edit to do any overrides, but that’s not Debian’s official line. >> > >> > On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski >> > wrote: >> >> >> >> In our case it was enough to add dropin changing execstart to include >> >> -f and type to simple: >> >> >> >> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS >> >> Type=simple >> >> >> >> What do you mean by "it is expected" ? Currently enabling debug (by >> >> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop, >> >> surely that isn't an expected behaviour ? >> >> >> >> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg >> >> wrote: >> >> > >> >> > Yes, this is expected. What change are you suggesting? >> >> > >> >> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski >> >> > wrote: >> >> >> >> >> >> Package: freeradius >> >> >> Version: 3.0.12+dfsg-5+deb9u1 >> >> >> Severity: normal >> >> >> >> >> >> Currently the type of systemd service is forking. >> >> >> >> >> >> Adding debug to cmdline causes freeradius to run in foreground (and >> >> >> dump debug >> >> >> to stdout), which means systemd timeouts on starting service because >> >> >> it assumes >> >> >> it will fork. >> >> >> >> >> >> Changing type to simple, and adding -f (run in foreground) option in >> >> >> unit file >> >> >> fixes that >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Mariusz Gronczewski (XANi) >> >> >> GnuPG: 0xEA8ACE64 >> >> >> >> >> >> ___ >> >> >> Pkg-freeradius-maintainers mailing list >> >> >> pkg-freeradius-maintain...@alioth-lists.debian.net >> >> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers >> >> > >> >> > >> >> > >> >> > -- >> >> > Best regards, >> >> > Michael >> >> >> >> >> >> >> >> -- >> >> Mariusz Gronczewski (XANi) >> >> GnuPG: 0xEA8ACE64 >> > >> > >> > >> > -- >> > Best regards, >> > Michael >> >> >> >> -- >> Mariusz Gronczewski (XANi) >> GnuPG: 0xEA8ACE64 > > > > -- > Best regards, > Michael -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#920345: [Pkg-freeradius-maintainers] Bug#920345: freeradius: running freeradius with debug(-X) option breaks systemd unit
Now that I looked, while current 3.x stable still uses forking, they have added support for Type=notify in current development ( https://github.com/FreeRADIUS/freeradius-server/blob/master/debian/freeradius.service ) of daemon itself so that should solve it. On Fri, 25 Jan 2019 at 14:31, Mariusz Gronczewski wrote: > > Okay, I will just poke the upstream about it, seems that CentOS/RHEL > package have exactly same problem so no point changing it just for > Debian. > > > On Thu, 24 Jan 2019 at 18:27, Michael Stapelberg > wrote: > > > > Ah, why didn’t you open with that suggestion? :) > > > > https://manpages.debian.org/stretch/systemd/systemd.service.5.en.html#OPTIONS > > outlines that switching to Type=simple (which is the consequence of your > > -f suggestion) means we won’t have start-up failure propagation anymore, > > and reverse-dependencies of freeradius will not be able to reliably > > sequence themselves. > > > > Now, I’m not sure whether these downsides are actually relevant in > > practice, as I don’t know much about the larger freeradius ecosystem. Maybe > > there are no communication channels, and no reverse dependencies of note? > > I’m not sure. > > > > If you could confirm with upstream that they are blessing use of -f and > > Type=simple as the default in Debian, I can make the change. > > > > Thanks, > > > > On Thu, Jan 24, 2019 at 4:49 PM Mariusz Gronczewski > > wrote: > >> > >> Well, there is, adding -f option by default means it will always run > >> in foreground, regardless of whether -X is used or not > >> > >> On Thu, 24 Jan 2019 at 15:58, Michael Stapelberg > >> wrote: > >> > > >> > The -X option is special in that it changes the way freeradius starts up. > >> > > >> > It’s expected that if your actions break the contract with the init > >> > system (in this case by specifying -X), you’re responsible to rectify > >> > that. > >> > > >> > If there was a simple way to make the package work in any/all cases, > >> > it’d be up for it, but I’m not aware of one. Hence my question for what > >> > your suggestion is — I just don’t see a way out of this situation. > >> > > >> > My personal recommendation is to not use /etc/default, but rather > >> > systemctl edit to do any overrides, but that’s not Debian’s official > >> > line. > >> > > >> > On Thu, Jan 24, 2019 at 3:37 PM Mariusz Gronczewski > >> > wrote: > >> >> > >> >> In our case it was enough to add dropin changing execstart to include > >> >> -f and type to simple: > >> >> > >> >> ExecStart=/usr/sbin/freeradius -f $FREERADIUS_OPTIONS > >> >> Type=simple > >> >> > >> >> What do you mean by "it is expected" ? Currently enabling debug (by > >> >> setting FREERADIUS_OPTIONS="-X") cause it to enter restart loop, > >> >> surely that isn't an expected behaviour ? > >> >> > >> >> On Thu, 24 Jan 2019 at 13:52, Michael Stapelberg > >> >> wrote: > >> >> > > >> >> > Yes, this is expected. What change are you suggesting? > >> >> > > >> >> > On Thu, Jan 24, 2019 at 1:45 PM Mariusz Gronczewski > >> >> > wrote: > >> >> >> > >> >> >> Package: freeradius > >> >> >> Version: 3.0.12+dfsg-5+deb9u1 > >> >> >> Severity: normal > >> >> >> > >> >> >> Currently the type of systemd service is forking. > >> >> >> > >> >> >> Adding debug to cmdline causes freeradius to run in foreground (and > >> >> >> dump debug > >> >> >> to stdout), which means systemd timeouts on starting service because > >> >> >> it assumes > >> >> >> it will fork. > >> >> >> > >> >> >> Changing type to simple, and adding -f (run in foreground) option in > >> >> >> unit file > >> >> >> fixes that > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> Mariusz Gronczewski (XANi) > >> >> >> GnuPG: 0xEA8ACE64 > >> >> >> > >> >> >> ___ > >> >> >> Pkg-freeradius-maintainers mailing list > >> >> >> pkg-freeradius-maintain...@alioth-lists.debian.net > >> >> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Best regards, > >> >> > Michael > >> >> > >> >> > >> >> > >> >> -- > >> >> Mariusz Gronczewski (XANi) > >> >> GnuPG: 0xEA8ACE64 > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > Michael > >> > >> > >> > >> -- > >> Mariusz Gronczewski (XANi) > >> GnuPG: 0xEA8ACE64 > > > > > > > > -- > > Best regards, > > Michael > > > > -- > Mariusz Gronczewski (XANi) > GnuPG: 0xEA8ACE64 -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64
Bug#920340: 1.9 shows the same problem
Hi Sergio, sergio ezt írta (időpont: 2019. jan. 25., P, 18:33): > > > The from #919972 shows the same problem after upgrading to 1.9 > > Subject: > [package on hold] unattended-upgrades result for : SUCCESS > > Unattended upgrade result: All upgrades installed > > Packages with upgradable origin but kept back: > libcurl4 > > > As I said in #919972 1.9 shows correct message "Packages with upgradable > origin but kept back", but subject is wrong: "[package on hold]" Yes, the definition of success and the subject line could be revisited as it was discussed here, too: https://github.com/mvo5/unattended-upgrades/issues/165 Cheers, Balint > > -- > sergio. >
Bug#920438: linux-image-4.19.0-1-amd64: High kswapd0 CPU usage without swap space
Package: src:linux Version: 4.19.12-1 Severity: normal Hi, While building some software.. on a VM without swap partition configured. The behaviour / CPU usage is just not right. Greetings, Olaf top - 15:03:58 up 1 day, 4:37, 3 users, load average: 1.97, 2.24, 1.98 Tasks: 132 total, 3 running, 129 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 90.3 sy, 0.0 ni, 0.0 id, 9.4 wa, 0.0 hi, 0.3 si, 0.0 st MiB Mem :963.5 total, 57.8 free,841.6 used, 64.1 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 13.7 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 37 root 20 0 0 0 0 R 99.4 0.0 26:12.41 kswapd0 14320 olaf 20 0 773044 492020 0 R 74.0 49.9 0:42.79 cc1plus 14085 olaf 20 0 225656772 0 R 1.6 0.1 0:14.43 top 706 mysql 20 0 643344 107936 0 S 1.0 10.9 3:37.31 mysqld -- Package-specific info: ** Version: Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.12-1 (2018-12-22) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 root=UUID=a7e33b21-59c0-47f5-87ac-61ebedbb2aa4 ro quiet ** Not tainted ** Kernel log: [102936.929964] dump_stack+0x5c/0x80 [102936.929991] dump_header+0x6b/0x283 [102936.954857] ? do_try_to_free_pages+0x2ec/0x370 [102936.954869] oom_kill_process.cold.29+0xb/0x1c3 [102936.954873] ? oom_badness+0x23/0x130 [102936.954877] out_of_memory+0x1a4/0x450 [102936.954881] __alloc_pages_slowpath+0xbd5/0xcb0 [102936.954886] __alloc_pages_nodemask+0x28b/0x2b0 [102936.954889] filemap_fault+0x3cc/0x770 [102936.954892] ? filemap_map_pages+0x1ed/0x3a0 [102936.955034] ext4_filemap_fault+0x2c/0x40 [ext4] [102936.955156] __do_fault+0x1f/0xf0 [102936.955161] __handle_mm_fault+0xe87/0x12a0 [102936.955167] handle_mm_fault+0xda/0x200 [102936.955173] __do_page_fault+0x249/0x4f0 [102936.955179] ? page_fault+0x8/0x30 [102936.955182] page_fault+0x1e/0x30 [102936.955294] RIP: 0033:0x7f4138231269 [102936.955631] Code: Bad RIP value. [102936.955634] RSP: 002b:7f411dffac78 EFLAGS: 00010246 [102936.955637] RAX: RBX: 7f411dffb598 RCX: 7f4138231269 [102936.955638] RDX: 0100 RSI: 0001 RDI: 7f4137d5b000 [102936.955639] RBP: 7f4137d5b000 R08: 7f411dffad80 R09: [102936.955641] R10: 7f41377f7000 R11: 0246 R12: 0001 [102936.955642] R13: R14: 0100 R15: 7f41377f7000 [102936.955757] Mem-Info: [102936.955801] active_anon:186642 inactive_anon:3178 isolated_anon:0 active_file:120 inactive_file:99 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 slab_reclaimable:12493 slab_unreclaimable:13503 mapped:1755 shmem:3375 pagetables:1985 bounce:0 free:12292 free_pcp:99 free_cma:0 [102936.955811] Node 0 active_anon:746568kB inactive_anon:12712kB active_file:480kB inactive_file:396kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:7020kB dirty:0kB writeback:0kB shmem:13500kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 163840kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [102936.955816] Node 0 DMA free:4404kB min:744kB low:928kB high:1112kB active_anon:10676kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15904kB mlocked:0kB kernel_stack:0kB pagetables:24kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [102936.955830] lowmem_reserve[]: 0 921 921 921 921 [102936.955854] Node 0 DMA32 free:44764kB min:44308kB low:55384kB high:66460kB active_anon:735892kB inactive_anon:12712kB active_file:480kB inactive_file:620kB unevictable:0kB writepending:0kB present:1032064kB managed:970740kB mlocked:0kB kernel_stack:4672kB pagetables:7916kB bounce:0kB free_pcp:396kB local_pcp:396kB fr
Bug#920439: python-watson-developer-cloud: New upstream release available
Source: python-watson-developer-cloud Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, there is a newer upstream release available: 2.6.0 It would be nice to have this available in the archive. Thanks, Michael - -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 -BEGIN PGP SIGNATURE- iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlxLGF0RHGZsYWRpQGRl Ymlhbi5vcmcACgkQ/9PIi5l90Wok1AgAxaoANcqeCAJNsuthv4Co0IhG2qKGsiIj l4lMPxwRwmnK2ozEZvq5kfAnRJHd3tXwLwJ7FsckUzz+J54VaHsp06dkAEpwD1+s pjyGYuogVbf50lHU0labkzMXdBY3LXOQ/FhvgQSd4LmtmDMSQt12MOlYQfmENqZm ZBgkarSpQMOmzwbVQ3vg8NMbn96KHkfOWaIvMmY19vpCGgrt0yH7NHxSfqhyjKFd gZ6HhohSO2z5GvBU0G7qOCB938JDpS0vtbKh3G0C3KBv7htVO4H09dMJEllWa5DF mIpWOp0d6c4EcstE0eiNT5GuzZDatsTUMVpb0LJkW9tbGK+SxXiKWA== =X5iw -END PGP SIGNATURE-
Bug#842284: closed by Markus Koschany (Bug#842284: fixed in libnb-platform18-java 10.0-2)
On Fri, Jan 25, 2019 at 12:57:03PM +, Debian Bug Tracking System wrote: >* Add AutoUpdate-NEVER.patch and set the defaultCheckInterval to NEVER to > prevent automatic updates. This can be changed by users individually. > (Closes: #842284) Hi Markus, Thanks for doing this. I very much appreciate it. Regards, -Roberto -- Roberto C. Sánchez
Bug#920440: unison-gtk: New upstream version
Package: unison-gtk Version: 2.48.4-1+b1 Severity: wishlist Tags: upstream Dear Maintainer, please package the new upstream version 2.51.2 that was released on 28 Jan 2018. https://github.com/bcpierce00/unison/releases -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (400, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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) Versions of packages unison-gtk depends on: ii libatk1.0-0 2.30.0-2 ii libc62.28-5 ii libcairo21.16.0-2 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libglib2.0-0 2.58.2-3 ii libgtk2.0-0 2.24.32-3 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpangoft2-1.0-01.42.4-6 Versions of packages unison-gtk recommends: ii lxqt-openssh-askpass [ssh-askpass] 0.13.0-1 ii openssh-client [ssh-client] 1:7.9p1-5 Versions of packages unison-gtk suggests: pn unison-all-gtk -- no debconf information
Bug#920441: libjs-cryptojs: Doesn't decrypt output from openssl enc anymore
Package: libjs-cryptojs
Version: 3.1.2+dfsg-2
Severity: normal
Dear Maintainer,
Up to jessie, one could encrypt something using openssl:
echo "This is a test" | openssl enc -aes-256-cbc -pass pass:mypassphrase -e
-base64
and decrypt it using crypto-js
var plaintext =
CryptoJS.AES.decrypt("U2FsdGVkX1+xT6Jz+c3NLK7zo1OpCBONwFRDOJaWurQ=",
"mypassphrase" );
This doesn't work with openssl from stretch onward, since openssl is no longer
using md5.
evpkdf.js contains: "hasher: MD5"
It is possible to work around by adding "-md md5" to openssl calls.
cryptojs should be compatible with openssl defaults.
-- System Information:
Debian Release: 9.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8),
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
libjs-cryptojs depends on no packages.
Versions of packages libjs-cryptojs recommends:
ii javascript-common 11
libjs-cryptojs suggests no packages.
-- no debconf information
Bug#920324: Acknowledgement (plasma-workspace: device notifier turn off the external hard disk when it is dismounted) - workaround
Dear Maintainer,
to solve the problem I wrote the following rule for udev:
file: /etc/udev/rules.d/99-usbdisk-nopoweroff.rules
# CHECK FLAG POWEROFF HARDDISK USB CONNECTED (LABEL "MOBILE")
# udisksctl info -d "$(udisksctl info -b "$(blkid -L MOBILE
2>/dev/null)"|grep -E "^\s+Drive:"|sed "s|^.*/||g;s|'||g")"|grep CanPowerOff
# TEST RULES AND FIND PROPERTIES
# drv="$(blkid -L MOBILE 2>/dev/null|sed
"s|/dev/\(.d[a-z]\)[0-9]\+|\1|g")"; udevadm info --query all --path
/sys/block/$drv/
# RELOAD RULES
# sys restart udev
# intercept and override CanPowerOff flag for generic usb disk
SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_TYPE}=="disk",
ENV{ID_BUS}=="usb", ENV{UDISKS_CAN_POWER_OFF}="0"
now the behavior is what is expected.
Thanks,
Antonio
Bug#920263: config made based on 'linux-config-4.19'-package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 see attachments, not workable either I retried the Server-Kernel build, which probably has more priority than the desktop- one, because the default (non) kernel is a desktop-kernel, config mad by 'make gconfig'. -BEGIN PGP SIGNATURE- iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCXEsfgAAKCRDn6sEfJS3n C6UqAKC0UMApVbDuZIoj7pmeEXcaAWoMcQCfYKwX6u012Z0+ZPgE/uABkARaPXc= =2GsS -END PGP SIGNATURE- .config-asrv-linul.xz Description: application/xz linul-build-asr-none.txt.xz Description: application/xz
Bug#920332: mmdebstrap: provide new upstream version for inclusion in Debian/buster
Hi Josch, (I nearly missed your bug-report update since I didn't receive a mail but only the BTS AFAICS, JFYI) * Johannes Schauer [Thu Jan 24, 2019 at 12:27:16PM +0100]: > On Thu, 24 Jan 2019 10:59:58 +0100 Michael Prokop wrote: > > I was looking into #914915 and noticed that mmdebstrap as present in current > > Debian/buster uses merged-usr by default and there doesn't seem to be any > > way > > how to disable it. > > While browsing through > > https://gitlab.mister-muffin.de/josch/mmdebstrap/commits/master > > I noticed several commits that might be useful to have in buster, > > especially the "add --merged-usr and --no-merged-usr no-op options > > for debootstrap compatibility" one. > > Would be great to see a new upstream version of mmdebstrap and > > getting that into buster! > merged-usr is completely disabled in the git master of mmdebstrap upstream. > The > --merged-usr and --no-merged-usr flags are just no-op options for > compatibility. That's why they are not documented. I'm aware (just the version being available in buster doesn't have this behavior yet, that's why I stumbled upon it) > A new upstream release of mmdebstrap is currently blocked by #909637 which in > turn is blocked by #915559. I intend to remove mmdebstrap from buster if > #915559 does not get resolved in time, because one of the main purposes of > mmdebstrap is to create a Debian chroot without being root. And the only way > to > do that on a plain Debian system right now is to use fakechroot (proot > produces > wrong ownership information). So without fakechroot, mmdebstrap is not very > useful and should rather not be part of buster. While I think mmdebstrap without requiring root permissions is great (thanks!), let me add that mmdebstrap is so fast that it would be worth having mmdebstrap in buster just for the speedup reasons, IMO! So please reconsider. :) regards, -mika- signature.asc Description: Digital signature
Bug#917827: osspd FTCBFS: uses the wrong pkg-config
Hi Helmut, sorry for this! Somehow the patch you sent me previously got un-applied in my last update. I am not entirely sure what happened. But anyway I just uploaded a new version that should fix this. Kind regards, Ralf On 30.12.18 20:29, Helmut Grohne wrote: > Source: osspd > Version: 1.3.2-10 > Tags: patch upstream > User: helm...@debian.org > Usertags: rebootstrap > > osspd fails to cross build from source, because it uses the wrong > pkg-config and thus fails to find cuse_lowlevel.h. The attached patch > makes pkg-config substitutable (dh_auto_build supplies the correct > value) and thus makes osspd cross buildable. Please consider applying > the attached patch. > > Helmut >
Bug#920442: libcaca FTBFS in unstable
Package: libcaca Version: 0.99.beta19-2 Severity: serious Justification: fails to build from source (but built successfully in the past) See: http://debomatic-amd64.debian.net/distribution#unstable/libcaca/0.99.beta19-2/buildlog
Bug#920230: capnproto: executable installed in directory which breaks rdeps
control: severity -1 serious Hello, looks like the cmake build system works, while the automake doesn't (see the mir github issue). The cmake switch might probably need some tweaks in libraries naming, but nothing unfeasible. an hacky patch has been uploaded in Ubuntu http://launchpadlibrarian.net/408213615/capnproto_0.7.0-1_0.7.0-1ubuntu1.diff.gz G.
Bug#920332: mmdebstrap: provide new upstream version for inclusion in Debian/buster
Hi mika, Quoting Michael Prokop (2019-01-25 15:35:17) > (I nearly missed your bug-report update since I didn't receive a mail but > only the BTS AFAICS, JFYI) whoops, sorry I forgot to CC you. ^^ > > A new upstream release of mmdebstrap is currently blocked by #909637 which > > in turn is blocked by #915559. I intend to remove mmdebstrap from buster if > > #915559 does not get resolved in time, because one of the main purposes of > > mmdebstrap is to create a Debian chroot without being root. And the only > > way to do that on a plain Debian system right now is to use fakechroot > > (proot produces wrong ownership information). So without fakechroot, > > mmdebstrap is not very useful and should rather not be part of buster. > While I think mmdebstrap without requiring root permissions is great > (thanks!), let me add that mmdebstrap is so fast that it would be worth > having mmdebstrap in buster just for the speedup reasons, IMO! So please > reconsider. :) If you are in for the speed, would using multistrap not work for you? Thanks! cheers, josch signature.asc Description: signature
Bug#920443: ITP: salmid -- rapid Kmer based Salmonella identifier from sequence data
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: salmid Version : 0.1.23 Upstream Author : Henk den Bakker * URL : https://github.com/hcdenbakker/SalmID * License : MIT Programming Lang: Python Description : rapid Kmer based Salmonella identifier from sequence data SalmID enables rapid confirmation of Salmonella spp. and subspp. from sequence data. This is done by checking taxonomic ID of single isolate samples. Currently only IDs Salmonella species and subspecies, and some common contaminants (Listeria, Escherichia). Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/salmid
Bug#920444: RFS: zapping/0.10~cvs6-16 [QA] [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for a QA upload of the package "zapping". * Package name: zapping Version : 0.10~cvs6-16 Upstream Author : Iñaki García Etxebarria Michael H. Schimek * URL : http://zapping.sourceforge.net/ * License : GPL-2 Section : gnome It builds this binary package: zapping- television viewer for the GNOME environment To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zapping Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zapping/zapping_0.10~cvs6-16.dsc Or use the Git repository at: https://salsa.debian.org/debian/zapping Changes since the last upload: * QA upload. * debian/patches/24-GConf-to-GSettings.patch: Assign each GSettings instance to its own unique variable; otherwise things get really messy when plugins are loaded (Closes: #919473). * debian/patches/27-zsfb-manpage.patch: New; build and install zapping_setup_fb's manpage conditionally based on the same AM_CONDITIONAL that is used for the binary. * debian/patches/series: Update. * debian/rules: Pass --disable-v4l --disable-bktr on GNU/Hurd; remove hurd-specific CPPFLAGS. (override_dh_auto_install): Conditionally move zapping_setup_fb to /usr/bin as it's only built on GNU/Linux architectures. * debian/control (Build-Depends): Remove freebsd-glue; that was a really stupid idea that I should be ashamed of. And I am. (Depends): Add gsettings-desktop-schemas -- the code loads one schema from this package which will be a hard error if it is not installed. (Standards-Version): Bump to 4.3.0; no changes needed. * debian/copyright: Update copyright years, add Jeremy Bicha.
Bug#888130: set severity to normal as 2.9.4-2 skips this test
Control: tag -1 -ftbfs Control: severity -1 normal Control: tag -1 experimental Hi, This bug does not affect experimental, as the 3.x branch removed this test (and the corresponding code). The reuse functionality has been reported upstream to cause problems in some situations in the 2.x branch. I am therefore skipping the corresponding test in 2.9.4-2, and decrease the severity to normal for now, since the possible problem does not affect the building process. Cheers, Cédric signature.asc Description: PGP signature
Bug#920332: mmdebstrap: provide new upstream version for inclusion in Debian/buster
Quoting Johannes Schauer (2019-01-25 16:10:35) > Hi mika, > > Quoting Michael Prokop (2019-01-25 15:35:17) > > (I nearly missed your bug-report update since I didn't receive a mail but > > only the BTS AFAICS, JFYI) > > whoops, sorry I forgot to CC you. ^^ > > > > A new upstream release of mmdebstrap is currently blocked by #909637 which > > > in turn is blocked by #915559. I intend to remove mmdebstrap from buster > > > if > > > #915559 does not get resolved in time, because one of the main purposes of > > > mmdebstrap is to create a Debian chroot without being root. And the only > > > way to do that on a plain Debian system right now is to use fakechroot > > > (proot produces wrong ownership information). So without fakechroot, > > > mmdebstrap is not very useful and should rather not be part of buster. > > While I think mmdebstrap without requiring root permissions is great > > (thanks!), let me add that mmdebstrap is so fast that it would be worth > > having mmdebstrap in buster just for the speedup reasons, IMO! So please > > reconsider. :) > > If you are in for the speed, would using multistrap not work for you? Compared to multistrap, mmdebstrap has a commandline interface more in line with debootstrap, making it easier to swap. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#920445: ITP: icingaweb2-module-nagvis -- NagVis is a visualization addon for Icinga or Nagios
Package: wnpp Owner: david.k...@dknet.ch * Package name: icingaweb2-module-nagvis Upstream Author : Icinga Development Team * License : GPL-2+ Description : NagVis is a visualization addon for Icinga or Nagios It can be used to visualize monitoring data in combination with all kinds of pictures or maps. This allows to show the state of your infrastructure in many different creative ways. Greetings, David
Bug#920332: mmdebstrap: provide new upstream version for inclusion in Debian/buster
* Jonas Smedegaard [Fri Jan 25, 2019 at 04:28:26PM +0100]: > Quoting Johannes Schauer (2019-01-25 16:10:35) > > Quoting Michael Prokop (2019-01-25 15:35:17) > > > While I think mmdebstrap without requiring root permissions is great > > > (thanks!), let me add that mmdebstrap is so fast that it would be worth > > > having mmdebstrap in buster just for the speedup reasons, IMO! So please > > > reconsider. :) > > If you are in for the speed, would using multistrap not work for you? > Compared to multistrap, mmdebstrap has a commandline interface more in > line with debootstrap, making it easier to swap. Exactly, I can use mmdebstrap as replacement for debootstrap within grml-debootstrap by invoking it via DEBOOTSTRAP=mmdebstrap grml-debootstrap ... and it just works (just faster :)), while multistrap doesn't have such a debootstrap-like interface. regards, -mika- signature.asc Description: Digital signature
Bug#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices
On Fri, 2019-01-25 at 14:22 +0100, Hanno Stock wrote: > Package: wnpp > Severity: wishlist > Owner: Hanno Stock > > * Package name: displaylink > Version : 4.4 > Upstream Author : DisplayLink (UK) Ltd. > * URL : https://www.displaylink.com/downloads > * License : proprietary > Programming Lang: binary > Description : Proprietary driver for DisplayLink devices > > This is the proprietary binary component of the driver for DisplayLink > devices. It communicates via libusb with the DisplayLink device and uses > the opensource evdi kernel module for presenting a virtual graphics > device to the system. [...] Please consider choosing a more specific package name. Since we have free drivers for some DisplayLink devices, we should encourage users to use those where possible. Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Bug#836770: efi-readvar: Claims 'No efivarfs filesystem is mounted', no idea why
Control: close -1 1.8.1-1 On some date Rian Hunter wrote: > This bug has been fixed in upstream for ~4 years: > Message-ID: <151726856505.17087.10846960052117422510.reportbug@tomi> > X-Mailer: reportbug 6.6.6 > Date: Mon, 29 Jan 2018 15:29:25 -0800 > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/com mit/?id=9af07a90a3e2246be5a7d01e3a037cfa731eb5dc > > This package is in dire need of an upstream update. Closing as the package has now been updated by Arnaud and this bug is fixed. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#822724: Bug#822725: Bug#822724: efitools: FTBFS on i386: efibind.h: No such file or directory
On Fri, 29 Apr 2016 18:45:19 +0100 Steve McIntyre wrote: > On Fri, Apr 29, 2016 at 07:31:11PM +0200, pollux wrote: > >On 04/29/2016 06:58 PM, Steve McIntyre wrote: > >> On Fri, Apr 29, 2016 at 06:20:55PM +0200, pollux wrote: > >>> Indeed, on PC architectures, EFI executables are 64-bits EXE files. > >> > >> Ummm, what? 32-bit i386 (ia32) should be supported just fine. If it's > >> not working, that's just a bug. > > > >I'm talking about .efi files. If your firmware (BIOS) is 64-bits, then > >your executables can only use a 64-bits ABI for boot/runtime services. > >IA32 EFI firmwares are only used by some low-end platforms, or some > >embedded platforms (Intel Atom SoCs) > > Right, but they're still valid platforms that exist in the wild. We > already support (for example) installation on Bay Trail based machines > that use ia32 UEFI. > > >Not sure for ARM, but it may have the same problems. > > UEFI is more common on arm64, but there are some 32-bit ARM machines > that will boot with UEFI, and probably more coming. We've just turned > on more UEFI support in the armmp kernels for this reason. > > >See also http://mjg59.dreamwidth.org/26734.html for more problems with > >IA32 on x86 > > It's problematic, but it exists and is growing in usage - we can't > just ignore it. > > >> Please don't do that. There are *4* Debian Linux architectures that > >> should be able to work here: amd64, i386, arm64 and armhf. > > > >I would like to, I'm just trying to find a solution that does not > >involved cross-compilation :/ The source package builds both native > >files, and .efi files. > >If you have any ideas they are welcome. > > I don't see the problem - just build the appropriate binaries for each > of the architectures natively. Am I missing something? Hi, The latest upload from December builds fine on i386, amd64, armhf and arm64, and as far as I can see it's building the EFI binaries with the right LD scripts from gnu-efi, eg: elf_aarch64_efi.lds, elf_ia32_efi.lds So I think we can close this one too? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#919249: security issue: instability and crash due to crafted message flooding
Hi, On Mon, Jan 14, 2019 at 04:53:14AM +, Chris Knadle wrote: > Package: mumble > Version: 1.2.19-3 > Severity: important > Tags: security fixed-upstream fixed-in-experimental > > > It is currently possible to cause mumble-server to freeze and/or crash by > sending specifically it crafted commands, leading to a denial of service. > The server usually automatically recovers, however it has been reported that > in some instances it can take up to an hour after the attack has ended. > The attack can be done remotely and does not need special permissions. > > All versions of mumble 1.2.x and 1.3.0 snapshots prior to 2018-08-31 are > affected. This issue has been assigned CVE-2018-20743. Regards, Salvatore
Bug#920410: ldc ftbfs with ld --as-needed as the default
Am Fr., 25. Jan. 2019 um 09:00 Uhr schrieb Matthias Klose : > [...] > "-L-lz" is wrong. What is it supposed to do? Link against zlib? The "-L" flag means "pass to the linker" for LDC, not "set linker directory" as in GCC. So this says link the target against zlib. > And passing libraries in macros known as *glags* is error prone too, as you > see > here. It's an easy way to ensure stuff is linked against zlib that wasn't before. LDC embeds a copy of zlib, which is removed, so on Debian all generated binaries have to link against zlib explicitly, instead of embedding it. I don't know why this doesn't work with --as-needed yet (and didn't look into the issue closely yet as well), if you have an idea, let me know! Cheers, Matthias --- I welcome VSRE emails. See http://vsre.info/
Bug#920447: doxygen: Version 1.8.15 released
Package: doxygen Version: 1.8.13-10 Severity: wishlist Dear Maintainer, Please consider updating to the latest version of doxygen - 1.8.15 - it contains a lot of bug fixes which would be nice to have: http://www.doxygen.nl/manual/changelog.html Regards, Stephen Quinney -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages doxygen depends on: ii libc6 2.28-5 ii libclang1-6.0 1:6.0.1-10 ii libgcc11:8.2.0-14 ii libstdc++6 8.2.0-14 ii libxapian301.4.9-1 ii zlib1g 1:1.2.11.dfsg-1 doxygen recommends no packages. Versions of packages doxygen suggests: ii doxygen-doc1.8.13-10 pn doxygen-gui ii doxygen-latex 1.8.13-10 ii graphviz 2.40.1-5+b2 -- no debconf information
Bug#920438: closed by Ben Hutchings (Re: Bug#920438: linux-image-4.19.0-1-amd64: High kswapd0 CPU usage without swap space)
Op vr 25 jan. 2019 om 17:06 schreef Debian Bug Tracking System : > kswapd is not just needed for swap partitions, but also for paging > named files. I know It's clear from the log that your VM is running out of > memory > and it is normal for kswapd to be busy in this case. What is it wasting all that CPU time on?
Bug#920366: developers-reference: ftbfs in sid, builds fine in stable
control: reassign -1 texlive-latex-recommended control: retitle -1 ftbfs causing regression in texlive-latex-recommended control: affects -1 developers-reference control: affects -1 logidee-tools control: found -1 2018.20190122-1 thanks On Fri, Jan 25, 2019 at 10:54:45AM +0100, Wolfgang Schweer wrote: > On Thu, Jan 24, 2019 at 08:09:39PM +0100, Holger Levsen wrote: > > Interestingly 3.4.21 build fine in unstable on arm64 only two days ago (see > > https://tests.reproducible-builds.org/debian/history/developers-reference.html > > ) > > > > Matching this, builds of 3.4.21 still build fine today. (also see that > > last URL.) > The failure is most probably due to src:texlive-base. > texlive-base/2018.20190122-1 entered unstable a few days ago, replacing > 2018.20181214-1 thanks, that brought me on the right track: - I booted a buster VM, installed all of developers-reference build-depends from buster - then I successfully build developers-reference 3.4.21 - then I upgraded only texlive-base to the version from sid (2018.20190122-1) and dev-ref still build fine... - same with texlive... - same with texlive-latex-base - same with texlive-xetex - same with texlive-latex-extra - same with texlive-extra-utils - finally, after installing texlive-latex-recommended (2018.20190122-1) the build failed. - then I booted another fresh buster VM, installed all of developers-reference build-depends from buster again and upgraded only texlive-latex-recommended to the sid version, and voila, *boom*, developers-reference FTBFS. (with the very same output as submitted to this bug report.) Then I went to tracker.debian.org, saw two debci regressions and indeed https://ci.debian.net/data/autopkgtest/testing/amd64/l/logidee-tools/1779974/log.gz (attached) shows the very same symptoms as we are seeing with def-ref: Paragraph ended before \ProvidesPackageRCS@i was complete. Thus, reassigning etc accordingly. -- tschüß, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C autopkgtest_testing_amd64_logidee-tools_1779974_log.g Description: Binary data signature.asc Description: PGP signature
Bug#920410: ldc ftbfs with ld --as-needed as the default
On 25.01.19 17:24, Matthias Klumpp wrote: > Am Fr., 25. Jan. 2019 um 09:00 Uhr schrieb Matthias Klose : >> [...] >> "-L-lz" is wrong. What is it supposed to do? > > Link against zlib? The "-L" flag means "pass to the linker" for LDC, > not "set linker directory" as in GCC. > So this says link the target against zlib. > >> And passing libraries in macros known as *glags* is error prone too, as you >> see >> here. > > It's an easy way to ensure stuff is linked against zlib that wasn't > before. LDC embeds a copy of zlib, which is removed, so on Debian all > generated binaries have to link against zlib explicitly, instead of > embedding it. > I don't know why this doesn't work with --as-needed yet (and didn't > look into the issue closely yet as well), if you have an idea, let me > know! because the -lz appears on the command line before the objects being linked.
Bug#920448: lighttpd: FTBFS when built with dpkg-buildpackage -A
Package: src:lighttpd
Version: 1.4.52-4
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in sid but it failed:
[...]
debian/rules build-indep
dh build-indep --with autoreconf,systemd
dh_update_autotools_config -i
dh_autoreconf -i
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*'
-o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} + -o -type l -printf "symlink %p
" > debian/autoreconf.before
grep -q ^XDT_ configure.ac
autoreconf -f -i
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
[... snipped ...]
dh_installdocs: No packages to build. Architecture mismatch: amd64, want: all
any
dh_installdocs -Nlighttpd-modules-ldap -Nlighttpd-modules-mysql
-Nlighttpd-mod-authn-pam -Nlighttpd-mod-authn-sasl -Nlighttpd-mod-vhostdb-dbi
-Nlighttpd-mod-vhostdb-pgsql
install -d debian/lighttpd-doc/usr/share/doc/lighttpd-doc
cp --reflink=auto -a ./README
debian/lighttpd-doc/usr/share/doc/lighttpd-doc
cp --reflink=auto -a ./debian/tmp/changelog
debian/lighttpd-doc/usr/share/doc/lighttpd-doc
chown -R 0:0 debian/lighttpd-doc/usr/share/doc
chmod -R u\+rw,go=rX debian/lighttpd-doc/usr/share/doc
install -p -m0644 debian/copyright
debian/lighttpd-doc/usr/share/doc/lighttpd-doc/copyright
make[1]: Leaving directory '/<>'
dh_installchangelogs -i
install -p -m0644 debian/changelog
debian/lighttpd-doc/usr/share/doc/lighttpd-doc/changelog.Debian
install -p -m0644 debian/NEWS
debian/lighttpd-doc/usr/share/doc/lighttpd-doc/NEWS.Debian
chmod 0644 -- debian/lighttpd-doc/usr/share/doc/lighttpd-doc/changelog
chown 0:0 -- debian/lighttpd-doc/usr/share/doc/lighttpd-doc/changelog
dh_installman -i
debian/rules override_dh_installinit
make[1]: Entering directory '/<>'
dh_installinit --error-handler=start_failed
make[1]: Leaving directory '/<>'
dh_perl -i
dh_link -i
dh_strip_nondeterminism -i
dh_compress -i
cd debian/lighttpd-doc
chmod a-x usr/share/doc/lighttpd-doc/NEWS.Debian
usr/share/doc/lighttpd-doc/changelog
usr/share/doc/lighttpd-doc/changelog.Debian
usr/share/doc/lighttpd/authentication.txt usr/share/doc/lighttpd/cml.txt
usr/share/doc/lighttpd/compress.txt usr/share/doc/lighttpd/configuration.txt
usr/share/doc/lighttpd/fastcgi.txt usr/share/doc/lighttpd/magnet.txt
usr/share/doc/lighttpd/performance.txt usr/share/doc/lighttpd/plugins.txt
usr/share/doc/lighttpd/state.txt
gzip -9nf usr/share/doc/lighttpd-doc/NEWS.Debian
usr/share/doc/lighttpd-doc/changelog
usr/share/doc/lighttpd-doc/changelog.Debian
usr/share/doc/lighttpd/authentication.txt usr/share/doc/lighttpd/cml.txt
usr/share/doc/lighttpd/compress.txt usr/share/doc/lighttpd/configuration.txt
usr/share/doc/lighttpd/fastcgi.txt usr/share/doc/lighttpd/magnet.txt
usr/share/doc/lighttpd/performance.txt usr/share/doc/lighttpd/plugins.txt
usr/share/doc/lighttpd/state.txt
cd '/<>'
debian/rules override_dh_fixperms
make[1]: Entering directory '/<>'
dh_fixperms
find debian/lighttpd-doc -true -print0 2>/dev/null | xargs -0r chown
--no-dereference 0:0
find debian/lighttpd-doc ! -type l -a -true -a -true -print0
2>/dev/null | xargs -0r chmod go=rX,u+rw,a-s
find debian/lighttpd-doc/usr/share/doc -type f -a -true -a ! -regex
'debian/lighttpd-doc/usr/share/doc/[^/]*/examples/.*' -print0 2>/dev/null |
xargs -0r chmod 0644
find debian/lighttpd-doc/usr/share/doc -type d -a -true -a -true
-print0 2>/dev/null | xargs -0r chmod 0755
find debian/lighttpd-doc -type f \( -name '*.so.*' -o -name '*.so' -o
-name '*.la' -o -name '*.a' -o -name '*.js' -o -name '*.css' -o -name '*.scss'
-o -name '*.sass' -o -name '*.jpeg' -o -name '*.jpg' -o -name '*.png' -o -name
'*.gif' -o -name '*.cmxs' \) -a -true -a -true -print0 2>/dev/null | xargs -0r
chmod 0644
test -d debian/lighttpd && \
chmod 0750 debian/lighttpd/var/log/lighttpd && \
chown www-data:www-data \
debian/lighttpd/var/cache/lighttpd/compress \
debian/lighttpd/var/cache/lighttpd/uploads \
debian/lighttpd/var/log/lighttpd
make[1]: *** [debian/rules:64: override_dh_fixperms] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:10: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess
returned exit status 2
The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:
https://buildd.debian.org/status/fetch.php?pkg=lighttpd&arch
